cvs-nserver-devel Mailing List for CVS with rewritten network layer (Page 10)
Brought to you by:
tyranny
Menu
▾
▴
cvs-nserver-devel — Developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(25) |
Sep
(7) |
Oct
(10) |
Nov
(14) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
(1) |
Mar
(3) |
Apr
(29) |
May
(41) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2003 |
Jan
(3) |
Feb
(3) |
Mar
(3) |
Apr
(5) |
May
(12) |
Jun
(68) |
Jul
(75) |
Aug
(56) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
|
From: Alberto D. <al...@ur...> - 2002-04-17 12:25:06
|
On Wed, 17 Apr 2002, Alexey Mahotkin wrote: > AD> Also in the next days I hope to send you patches to integrate OpenBSD > AD> changes made to cvs into cvs-nserver. Actually I have made a single > AD> patch yet and I tested it. But I want to separate it in single patches > AD> for each bugfix/feature made by the OpenBSD team, before submitting > AD> them to you. > > Wonderful! Btw, why don't you simply submit those patches to a stock CVS? > That way we'll catch them up automatically on next CVS release. Although, > sure, if you think that those patches are needed for nserver -- I agree. My impression is that cvs development is too slow, and that they are reclutant to add patches/improvements. Wasn't this one of the reasons the cvs-nserver project was started ? For example look at: http://www.cvshome.org/cyclic/cvs/dev-keywords.txt The improvement to add an optional custom "Id"-like RCS identifier was proposed years ago. It is used by *BSD guys since years. Right in the link above you can read that development team judged it a good thing, but nothing has been done. Also I'm not the original author of these improvements, and my guess is that patches have been sent to cvs/Cyclic by OpenBSD team , as this is the usual behaviour when making ports. I like the idea of cvs-nserver, and I think it can be improved and may be it could be distributed with OpenBSD in the future. The network code rewriting and the ssl support could be two major points for it to be approved by OpenBSD [note that I'm not currently connected in any way to the OpenBSD team, so these are my guesses] . Greets, Alberto. ------------------------------------------------------------------- Alberto Dainotti URIZEN - Internetworking & Digital Security al...@ur... http://www.urizen.it PGP Key available at: http://www.urizen.it/pgp Key Fingerprint: 87CF D95A CE0F 3188 3950 4B1F 3B56 DE69 D05F B8F5 ------------------------------------------------------------------- |
|
From: Alexey M. <al...@hs...> - 2002-04-16 21:56:54
|
>>>>> "AD" == Alberto Dainotti <al...@ur...> writes: AD> Hello, I'm doing some work to make cvs-nserver full OpenBSD compliant AD> :-) It's nice to hear! AD> Basically there are three things to do to successfully build AD> cvs-nserver on OpenBSD: AD> 1) Cut out the line below from src/server.c : #define _POSIX_SOURCE 1 Ok, this whole idea with _*_SOURCE was not that brilliant. Removed. AD> (server.c includes <sys/socket.h> which has some non posix AD> declarations, and also uses FD_SETSIZE which is declared in AD> sys/types.h only when _POSIX_SOURCE is not declared) Actually, I think that eventually those headers and the appropriate code would be removed from cvs-nserver altogether, and moved to one of the *-client.c (hopefully more cleanly). Also, I don't think that FD_SETSIZE usage is that critical. I think it could be removed too (select() will return appropriate error, if this number is too high for it). But that's orthogonal to a current question. AD> 2) Install gnu-m4 which is not supported by OpenBSD (gnu m4 is not AD> even present in to the ports tree of release 3.0). It seems that AD> OpenBSD's m4 can substitute gnu m4 in almost every situation , but the AD> following autoconf rule which checks for gnu m4 fails: AD> AC_PROG_GNU_M4 AD> (it fails checking for frozen files support) I believe that this should be directed towards Autoconf guys. Could you please write a message to aut...@gn... with the description of failure? We'll catch up when the corresponding Autoconf release will be out. AD> 3) Compile with GNU Make. I believe that *BSD people are already used to type 'gmake' right after './configure' :) AD> Now, point (1) is a suggestion to patch source code. Point (3) is no AD> problem. About point (2) is not clear to me if the AC_PROG_GNU_M4 rule AD> was inserted in configure.in by some automatic tool like autoscan or AD> was manually inserted by cvs-nserver coders , and why it was inserted. AD> Do you think it is strictly needed ? I think that it is needed for the Autotest stuff. I've looked at the M4-related stuff in configure.in, and I think I'll try to remove it and see if it's still works. I think that's remnants from the days of Autoconf 2.52 betas. AD> Also in the next days I hope to send you patches to integrate OpenBSD AD> changes made to cvs into cvs-nserver. Actually I have made a single AD> patch yet and I tested it. But I want to separate it in single patches AD> for each bugfix/feature made by the OpenBSD team, before submitting AD> them to you. Wonderful! Btw, why don't you simply submit those patches to a stock CVS? That way we'll catch them up automatically on next CVS release. Although, sure, if you think that those patches are needed for nserver -- I agree. Thanks, --alexm |
|
From: Alberto D. <al...@ur...> - 2002-04-15 15:06:05
|
Hello, I'm doing some work to make cvs-nserver full OpenBSD compliant :-) Basically there are three things to do to successfully build cvs-nserver on OpenBSD: 1) Cut out the line below from src/server.c : #define _POSIX_SOURCE 1 (server.c includes <sys/socket.h> which has some non posix declarations, and also uses FD_SETSIZE which is declared in sys/types.h only when _POSIX_SOURCE is not declared) 2) Install gnu-m4 which is not supported by OpenBSD (gnu m4 is not even present in to the ports tree of release 3.0). It seems that OpenBSD's m4 can substitute gnu m4 in almost every situation , but the following autoconf rule which checks for gnu m4 fails: AC_PROG_GNU_M4 (it fails checking for frozen files support) 3) Compile with GNU Make. Now, point (1) is a suggestion to patch source code. Point (3) is no problem. About point (2) is not clear to me if the AC_PROG_GNU_M4 rule was inserted in configure.in by some automatic tool like autoscan or was manually inserted by cvs-nserver coders , and why it was inserted. Do you think it is strictly needed ? Also in the next days I hope to send you patches to integrate OpenBSD changes made to cvs into cvs-nserver. Actually I have made a single patch yet and I tested it. But I want to separate it in single patches for each bugfix/feature made by the OpenBSD team, before submitting them to you. Greets, Alberto. ------------------------------------------------------------------- Alberto Dainotti URIZEN - Internetworking & Digital Security al...@ur... http://www.urizen.it PGP Key available at: http://www.urizen.it/pgp Key Fingerprint: 87CF D95A CE0F 3188 3950 4B1F 3B56 DE69 D05F B8F5 ------------------------------------------------------------------- |
|
From: Michael K. <ka...@fi...> - 2002-04-15 12:59:56
|
Hi. >>>>> Alexey Morozov <mo...@no...> writes: AM> =F7 =F7=D3=CB, 14.04.2002, =D7 18:34, Michael Kazakov wrote: Hmm, co= uld you AM> tell how did you try to start the server when it sigsegv'ed. I AM> suspect, you tried to run it with totally wrong arguments. Could AM> you tell the [x]inetd line etc etc etc?... $ grep pserver /etc/inetd.conf 2401 stream tcp nowait root /usr/local/cvs-nserver/bin/repos1pserver = cvs-pserver $ cat /usr/local/cvs-nserver/bin/repos1pserver=20 #!/bin/sh ulimit -c unlimited CVSPASSWD=3D/usr/local/cvs-nserver/bin/cvspasswd \ exec /usr/local/cvs-nserver/bin/cvs-pserver /home/Kazakov/heap/CVSROOT --= \ /usr/local/cvs-nserver/bin/cvschkpw /usr/local/cvs-nserver/bin/cvs pserve= r $ ls -l /home/Kazakov/heap/CVSROOT =C9=D4=CF=C7=CF 3 drwxrwsr-x 17 cvsadmin cvs 1471 =E1=D0=D2 10 18:51 cvs-nserver drwxr-xr-x 3 cvsadmin cvsadmin 973 =E1=D0=D2 10 17:46 CVSROOT $ sudo find /tmp/cvs-serv19280/ -name core -ls Password: 6065 2135 -rw------- 1 cvsadmin cvsadmin 2723840 =E1=D0=D2 10 18:51 = /tmp/cvs-serv19280/cvs-nserver/windows-NT/core With this settings I tried import and checkout from directory what contai= ns cvs-nserver. At first time it falls with SIGSEGV, but second try ends successfully. --=20 WBR, Michael Kazakov. |
|
From: Alexey M. <mo...@no...> - 2002-04-15 06:52:13
|
=F7 =F0=CE=C4, 15.04.2002, =D7 01:41, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC= : > I'm in favor for doing this that way. I think that dull string > manipulations are really the client issue. There're two issues as I stated already. First of all, we give every project manager in a given repository to manipulate _all_ the groups inside this particular repository (2Marod: read this twice and think carefully if this convenient for NS) The second issue is portability. Currently I implement everything in perl. It means there will be need either in web interface or in perl runtime on every manager's WS. Is it Ok? > I think that's really going to be much better. Otherwise, we'll have the > temptation of adding all kinds of various text file manipulations to a > server, the need to bother with locking, etc.... I hate this. Basically I agree with that. The simplicity and modularity is the power :-) |
|
From: Alexey M. <mo...@no...> - 2002-04-15 06:33:05
|
=F7 =F0=CE=C4, 15.04.2002, =D7 01:54, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC= : >=20 > No, that's ok:=20 >=20 > >> This GDB was configured as "i386-suse-linux"... Core was generated b= y > >> `/usr/local/cvs-nserver/bin/cvs pserver'. Oh, that's my fault... >=20 > Given that the segfault is in free(), I don't think that would be easy to > debug remotely... Hmm, well we really need the proper logging facility. BTW, Alex, did you consider smth I call multilevel logging as it's done in repcheck utility? I.e. when server logs every little step it does but w/ different logging level. At first look there could be 'fatal', 'security', 'normal', 'debug' levels and there would be a filter that specify how much information should go into logs. I think this would ease the setup, maintaince and incidents recovery processes. > I'll try to re-run the test... Hmm... I also will, as soon as I complete maintainance utilities... |
|
From: Alexey M. <al...@hs...> - 2002-04-14 18:54:47
|
>>>>> "AM" == Alexey Morozov <mo...@no...> writes: AM> В Вск, 14.04.2002, в 18:34, Michael Kazakov wrote: Hmm, could you tell AM> how did you try to start the server when it sigsegv'ed. I suspect, you AM> tried to run it with totally wrong arguments. Could you tell the AM> [x]inetd line etc etc etc?... AM> I also noticed that you're using 'cvs' w/ core file from cvs-pserver AM> :-). No, that's ok: >> This GDB was configured as "i386-suse-linux"... Core was generated by >> `/usr/local/cvs-nserver/bin/cvs pserver'. Given that the segfault is in free(), I don't think that would be easy to debug remotely... I'll try to re-run the test... --alexm |
|
From: Alexey M. <al...@hs...> - 2002-04-14 18:51:23
|
>>>>> "AM" == Alexey Morozov <mo...@no...> writes: AM> It seems that currently cvsgroup file can't contain empty groups, I AM> got smth like AM> E Error reading the cvsgroup file, line 3 AM> line 3 is %smscmgmt_readers: <cr> Humm, never thought of that :) Fixed. It was even considered a special case of brokenness. :) AM> BTW, Alex, do you plan to implement 'cvs group' command as stated in AM> acl-cli.txt? I think it's an important task, really... For now I just AM> perform a perl workarounds (well, the works in progress) including cvs AM> co CVSROOT, edit CVSROOT/cvsgroup and check things in back to AM> repository. This may be the way (especially when we talk about core AM> simplicity) but the we should cleanly state this in our docs. I'm in favor for doing this that way. I think that dull string manipulations are really the client issue. Maybe you're going to change a little the procedure of modifying user groups? I.e., in the web-interface there's going to be "start editing the cvsgroups file", "add/remove group/user to group", "commit the cvsgroups file"? With an optional window of directly-editing that checked out cvsgroup using <textarea>? I think that's really going to be much better. Otherwise, we'll have the temptation of adding all kinds of various text file manipulations to a server, the need to bother with locking, etc.... I hate this. AM> But this seems to be a security issue... Huh? Where is the security issue? --alexm |
|
From: Alexey M. <al...@hs...> - 2002-04-14 18:31:38
|
>>>>> "AM" == Alexey Morozov <mo...@no...> writes:
>> - are there any more logging objects?
AM> Probably we should add not objects, but some kind of
AM> "state"/"stage" to loggin', i.e. when a user logs in (just logs
AM> in, right in checkpassword, an appropriate line goes to log, smth
AM> like this: %U (%I) logs in (status: [success/failure]
This particular case is going to be handled from the 'cvs-pserver', I
believe.
(I have to note that there is a strong trend towards making :pserver:
in all of its varieties the de-facto only access method.) Local
repositories are out of scope for cvs-nserver project, and the :ext:
method is not that different from the local repository.
The more I think about it, the more I like the idea to use syslog()
everywhere, and not bother about log file synchronizations, etc. I
believe that syslog-ng could provide more than adequate filtering for
the cvs server messages. What do you think? I really don't want to
bother with my own logging, because I don't see any rationale for
that.
As for logins: I proposed separate format of authentication log
entries:
login vasya from 123.45.67.89 in /repos
or
LOGIN-FAILURE bad-guy from 10.9.8.7 in /top-secret-repos
ACL violations are logged like that:
access-denied vasya from 1.2.3.4 in /top-secret-repos to module/sdir/foo.c for access
All the operations are logged "as always":
checkout module/sdir/bar.c (rev 1.14) in /repos, etc, etc.
--alexm
|
|
From: Alexey M. <mo...@no...> - 2002-04-14 13:41:35
|
It seems that currently cvsgroup file can't contain empty groups, I got smth like E Error reading the cvsgroup file, line 3 line 3 is %smscmgmt_readers: <cr> BTW, Alex, do you plan to implement 'cvs group' command as stated in acl-cli.txt? I think it's an important task, really... For now I just perform a perl workarounds (well, the works in progress) including cvs co CVSROOT, edit CVSROOT/cvsgroup and check things in back to repository. This may be the way (especially when we talk about core simplicity) but the we should cleanly state this in our docs. But this seems to be a security issue... |
|
From: Alexey M. <mo...@no...> - 2002-04-14 12:33:43
|
=F7 =F7=D3=CB, 14.04.2002, =D7 18:34, Michael Kazakov wrote: Hmm, could you tell how did you try to start the server when it sigsegv'ed. I suspect, you tried to run it with totally wrong arguments. Could you tell the [x]inetd line etc etc etc?... I also noticed that you're using 'cvs' w/ core file from cvs-pserver :-). BTW, in the attachment you may find a [hopefully] correct example (at least it works for me:-)) how to set up an ncvs-pserver in xinetd environment. inetd line should be constructed in similar way :-).=20 In a really near future (hopefully a day or two) I will provide a set of tools for creating repositories, starting projects etc... In fact there's a draft of doc (in texinfo) :-)). And finally, Alex will fix cvs-admin-guide.texi so we'll have a proper and much more accurate documentation :-) > $ gdb -c core.pserver /usr/local/cvs-nserver/bin/cvs >=20 > GNU gdb 5.0 > Copyright 2000 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-suse-linux"... > Core was generated by `/usr/local/cvs-nserver/bin/cvs pserver'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libcrypt.so.1...done. > Loaded symbols for /lib/libcrypt.so.1 > Reading symbols from /lib/libz.so.1...done. > Loaded symbols for /lib/libz.so.1 > Reading symbols from /lib/libc.so.6...done. > Loaded symbols for /lib/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...done. > Loaded symbols for /lib/ld-linux.so.2 > #0 0x400dd17d in chunk_free () from /lib/libc.so.6 > (gdb) bt > #0 0x400dd17d in chunk_free () from /lib/libc.so.6 > #1 0x400dd064 in free () from /lib/libc.so.6 > #2 0x805970d in Entnode_Destroy (ent=3D0x820e7b8) at entries.c:74 > #3 0x805a2a5 in Entries_delproc (node=3D0x81b4c38) at entries.c:598 > #4 0x805f217 in freenode_mem (p=3D0x81b4c38) at hash.c:188 > #5 0x805f273 in freenode (p=3D0x81b4c38) at hash.c:210 > #6 0x805f1ee in delnode (p=3D0x81b4c38) at hash.c:177 > #7 0x805f0f4 in dellist (listp=3D0xbffff434) at hash.c:93 > #8 0x805a284 in Entries_Close (list=3D0x80eb310) at entries.c:582 > #9 0x8080e32 in do_recursion (frame=3D0xbffff4f4) at recurse.c:768 > #10 0x808162b in do_dir_proc (p=3D0x80ec678, closure=3D0xbffff590) > at recurse.c:1091 > #11 0x805f4fd in walklist (list=3D0x80ebac8, proc=3D0x8081000 <do_dir_pro= c>,=20 > closure=3D0xbffff590) at hash.c:370 > #12 0x8080e0c in do_recursion (frame=3D0xbffff614) at recurse.c:758 > #13 0x808162b in do_dir_proc (p=3D0x80da800, closure=3D0xbffff6b0) > at recurse.c:1091 > #14 0x805f4fd in walklist (list=3D0x80eb008, proc=3D0x8081000 <do_dir_pro= c>,=20 > closure=3D0xbffff6b0) at hash.c:370 > #15 0x8080e0c in do_recursion (frame=3D0xbffff744) at recurse.c:758 > #16 0x8080901 in start_recursion (fileproc=3D0x80908c0 <update_fileproc>,= =20 > filesdoneproc=3D0x8090e40 <update_filesdone_proc>,=20 > direntproc=3D0x8090f40 <update_dirent_proc>,=20 > dirleaveproc=3D0x80912d0 <update_dirleave_proc>, callerdat=3D0x0, arg= c=3D0,=20 > argv=3D0x80da648, local=3D0, which=3D3, aflag=3D0, readlock=3D1,=20 > update_preload=3D0x80dac58 "cvs-nserver", dosrcs=3D1) at recurse.c:35= 5 > #17 0x809088a in do_update (argc=3D0, argv=3D0x0, xoptions=3D0x0, xtag=3D= 0x0,=20 > xdate=3D0x0, xforce=3D1, local=3D0, xbuild=3D1, xaflag=3D0, xprune=3D= 0, xpipeout=3D0,=20 > which=3D3, xjoin_rev1=3D0x0, xjoin_rev2=3D0x0,=20 > preload_update_dir=3D0x80dac58 "cvs-nserver", xdotemplate=3D1) at upd= ate.c:515 > #18 0x8051e35 in checkout_proc (argc=3D1, argv=3D0x80daff0, where_orig=3D= 0x0,=20 > mwhere=3D0x0, mfile=3D0x0, shorten=3D0, local_specified=3D0,=20 > omodule=3D0x80daae8 "cvs-nserver", msg=3D0x80b5417 "Updating") > at checkout.c:1075 > #19 0x806f273 in do_module (db=3D0x80da7b8, mname=3D0x80daae8 "cvs-nserve= r",=20 > m_type=3DCHECKOUT, msg=3D0x80b5417 "Updating",=20 > callback_proc=3D0x8050e10 <checkout_proc>, where=3D0x0, shorten=3D0,=20 > local_specified=3D0, run_module_prog=3D1, build_dirs=3D1, extra_arg= =3D0x0) > at modules.c:299 > #20 0x8050b82 in checkout (argc=3D1, argv=3D0x80da630) at checkout.c:373 > #21 0x8088925 in do_cvs_command (cmd_name=3D0x80cb599 "checkout",=20 > command=3D0x8050450 <checkout>) at server.c:2782 > #22 0x808a462 in serve_co (arg=3D0x80daafa "") at server.c:3738 > #23 0x808c12f in server (argc=3D1, argv=3D0xbffffc78) at server.c:5104 > #24 0x806dab7 in main (argc=3D1, argv=3D0xbffffc78) at main.c:1122 > #25 0x40085c6f in __libc_start_main () from /lib/libc.so.6 > (gdb)=20 >=20 > $ uname -rs > Linux 2.2.19 >=20 > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs > gcc version 2.95.3 20010315 (SuSE) >=20 > $ rpm -q glibc > glibc-2.2.2-38 >=20 > --=20 > WBR, Michael Kazakov. >=20 > _______________________________________________ > Cvs-nserver-devel mailing list > Cvs...@li... > https://lists.sourceforge.net/lists/listinfo/cvs-nserver-devel |
|
From: Michael K. <ka...@fi...> - 2002-04-14 11:34:18
|
Hi.
$ gdb -c core.pserver /usr/local/cvs-nserver/bin/cvs
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-suse-linux"...
Core was generated by `/usr/local/cvs-nserver/bin/cvs pserver'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libz.so.1...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x400dd17d in chunk_free () from /lib/libc.so.6
(gdb) bt
#0 0x400dd17d in chunk_free () from /lib/libc.so.6
#1 0x400dd064 in free () from /lib/libc.so.6
#2 0x805970d in Entnode_Destroy (ent=0x820e7b8) at entries.c:74
#3 0x805a2a5 in Entries_delproc (node=0x81b4c38) at entries.c:598
#4 0x805f217 in freenode_mem (p=0x81b4c38) at hash.c:188
#5 0x805f273 in freenode (p=0x81b4c38) at hash.c:210
#6 0x805f1ee in delnode (p=0x81b4c38) at hash.c:177
#7 0x805f0f4 in dellist (listp=0xbffff434) at hash.c:93
#8 0x805a284 in Entries_Close (list=0x80eb310) at entries.c:582
#9 0x8080e32 in do_recursion (frame=0xbffff4f4) at recurse.c:768
#10 0x808162b in do_dir_proc (p=0x80ec678, closure=0xbffff590)
at recurse.c:1091
#11 0x805f4fd in walklist (list=0x80ebac8, proc=0x8081000 <do_dir_proc>,
closure=0xbffff590) at hash.c:370
#12 0x8080e0c in do_recursion (frame=0xbffff614) at recurse.c:758
#13 0x808162b in do_dir_proc (p=0x80da800, closure=0xbffff6b0)
at recurse.c:1091
#14 0x805f4fd in walklist (list=0x80eb008, proc=0x8081000 <do_dir_proc>,
closure=0xbffff6b0) at hash.c:370
#15 0x8080e0c in do_recursion (frame=0xbffff744) at recurse.c:758
#16 0x8080901 in start_recursion (fileproc=0x80908c0 <update_fileproc>,
filesdoneproc=0x8090e40 <update_filesdone_proc>,
direntproc=0x8090f40 <update_dirent_proc>,
dirleaveproc=0x80912d0 <update_dirleave_proc>, callerdat=0x0, argc=0,
argv=0x80da648, local=0, which=3, aflag=0, readlock=1,
update_preload=0x80dac58 "cvs-nserver", dosrcs=1) at recurse.c:355
#17 0x809088a in do_update (argc=0, argv=0x0, xoptions=0x0, xtag=0x0,
xdate=0x0, xforce=1, local=0, xbuild=1, xaflag=0, xprune=0, xpipeout=0,
which=3, xjoin_rev1=0x0, xjoin_rev2=0x0,
preload_update_dir=0x80dac58 "cvs-nserver", xdotemplate=1) at update.c:515
#18 0x8051e35 in checkout_proc (argc=1, argv=0x80daff0, where_orig=0x0,
mwhere=0x0, mfile=0x0, shorten=0, local_specified=0,
omodule=0x80daae8 "cvs-nserver", msg=0x80b5417 "Updating")
at checkout.c:1075
#19 0x806f273 in do_module (db=0x80da7b8, mname=0x80daae8 "cvs-nserver",
m_type=CHECKOUT, msg=0x80b5417 "Updating",
callback_proc=0x8050e10 <checkout_proc>, where=0x0, shorten=0,
local_specified=0, run_module_prog=1, build_dirs=1, extra_arg=0x0)
at modules.c:299
#20 0x8050b82 in checkout (argc=1, argv=0x80da630) at checkout.c:373
#21 0x8088925 in do_cvs_command (cmd_name=0x80cb599 "checkout",
command=0x8050450 <checkout>) at server.c:2782
#22 0x808a462 in serve_co (arg=0x80daafa "") at server.c:3738
#23 0x808c12f in server (argc=1, argv=0xbffffc78) at server.c:5104
#24 0x806dab7 in main (argc=1, argv=0xbffffc78) at main.c:1122
#25 0x40085c6f in __libc_start_main () from /lib/libc.so.6
(gdb)
$ uname -rs
Linux 2.2.19
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
gcc version 2.95.3 20010315 (SuSE)
$ rpm -q glibc
glibc-2.2.2-38
--
WBR, Michael Kazakov.
|
|
From: Alexey M. <mo...@no...> - 2002-04-13 10:35:51
|
> - are there any more logging objects?
Probably we should add not objects, but some kind of "state"/"stage" to
loggin', i.e. when a user logs in (just logs in, right in checkpassword,
an appropriate line goes to log, smth like this:
%U (%I) logs in (status: [success/failure]
>
> - should we have additional functionality beyond simply
> substituting the variables? I can't imagine any.
>
> - what are the exact points where log file format could be
> overriden? per-repository (ok)? per-module (oh, no!)?
> per-branch???
>
>
>
> ======================================================================
>
> COMMON LOGGING FORMAT
> ======================
>
>
> Logging objects
> ----------------
>
> There are the following variables that are associated with each server
> action:
>
>
> Timestamp (T):
>
> time of the operation
>
>
> Username (U):
>
> name of the user working with server
>
> IP-Address (I):
>
> IP-address of user working with server (or "<local>", if
> working with
>
>
> Repository (R):
>
> path to the repository
>
>
> Module (M):
>
> CVS module name
>
>
> Subcommand (S):
>
> CVS sub-command ('checkin', 'add', etc.)
>
>
> Branch (B):
>
> branch we are working on
>
>
> Filename (F):
>
> file we are working with
>
>
> Revision (r):
>
> revision we are working with (or "-" if not applicable).
>
> Info (i):
>
> additional information specific for particular sub-command.
>
>
>
>
> Log file format
> ----------------
>
> Log file format is specifed a-la mod_log_config, using the
> /etc/cvs-server.conf:
>
> # This will output all the information
> CustomLog /var/log/cvs-server.log "%T %R %U %I %M %S %B %F %r %i"
>
>
> This could be overriden on a per-repository basis from the
> CVSROOT/config file.
>
>
>
> Log file filtering
> -------------------
>
> Someday we could implement the logfile filtering, using the following
> notation:
>
> # for all 'cvs rtag' commands, output the brief tag information
> FilterLog /var/log/branches.log "%{S=rtag} "%T %U %I %M %B %i"
>
>
> Probably we should not bother with it currently, because it could be
> easily done with a one-line Perl script. But maybe there could really
> be the rationale for actually doing it on a server side.
>
>
>
> --alexm
>
> _______________________________________________
> Cvs-nserver-devel mailing list
> Cvs...@li...
> https://lists.sourceforge.net/lists/listinfo/cvs-nserver-devel
>
> Sponsored by http://www.ThinkGeek.com/
>
|
|
From: Alexey M. <al...@hs...> - 2002-04-08 22:15:27
|
Questions:
- are there any more logging objects?
- should we have additional functionality beyond simply
substituting the variables? I can't imagine any.
- what are the exact points where log file format could be
overriden? per-repository (ok)? per-module (oh, no!)?
per-branch???
======================================================================
COMMON LOGGING FORMAT
======================
Logging objects
----------------
There are the following variables that are associated with each server
action:
Timestamp (T):
time of the operation
Username (U):
name of the user working with server
IP-Address (I):
IP-address of user working with server (or "<local>", if
working with
Repository (R):
path to the repository
Module (M):
CVS module name
Subcommand (S):
CVS sub-command ('checkin', 'add', etc.)
Branch (B):
branch we are working on
Filename (F):
file we are working with
Revision (r):
revision we are working with (or "-" if not applicable).
Info (i):
additional information specific for particular sub-command.
Log file format
----------------
Log file format is specifed a-la mod_log_config, using the
/etc/cvs-server.conf:
# This will output all the information
CustomLog /var/log/cvs-server.log "%T %R %U %I %M %S %B %F %r %i"
This could be overriden on a per-repository basis from the
CVSROOT/config file.
Log file filtering
-------------------
Someday we could implement the logfile filtering, using the following
notation:
# for all 'cvs rtag' commands, output the brief tag information
FilterLog /var/log/branches.log "%{S=rtag} "%T %U %I %M %B %i"
Probably we should not bother with it currently, because it could be
easily done with a one-line Perl script. But maybe there could really
be the rationale for actually doing it on a server side.
--alexm
|
|
From: Alexey M. <al...@hs...> - 2002-03-31 20:55:20
|
> That way, the repository policy gets used correctly, and all tests > still pass (except for the > 9: acl.at:338 FAILED near `acl.at:353' > which I'll fix shortly (it has to do with CVSROOT/default-deny, which > is not yet implemented). Done. ## ----------------------------- ## ## All 18 tests were successful. ## ## ----------------------------- ## --alexm |
|
From: Alexey M. <al...@hs...> - 2002-03-31 20:28:23
|
I've implemented directory semantics described in the corresponding chapter of acl-rfc.txt (which I posted here yesterday). The only thing that was incorrectly stated: - proposal was talking about "directory without ACLs at all"; - it should really talk about "directory without an ACE (Access Control Entry) for the user in question; That way, the repository policy gets used correctly, and all tests still pass (except for the 9: acl.at:338 FAILED near `acl.at:353' which I'll fix shortly (it has to do with CVSROOT/default-deny, which is not yet implemented). --alexm |
|
From: Alexey M. <al...@hs...> - 2002-03-30 18:38:27
|
This message is a conclusion to a discussion that happened in private
during the initial testing deployment.
In short, I believe that we have missed an important case regarding
the distinction between the "directory has an associated Access
Control List" and "directory does not have an associated Access
Control List". This concept, being supplemented with an idea of
"repository policy", gives an answer to all the incoherency reports
that we have seen.
Below is an appropriate new chapter in acl-rfc.txt. It also gives the
detailed sequence of steps we take when calculating the directory
permissions. I shall implement that, and then we'll reconsider the
code in NCLI-1-11-1-NEWACL branch.
======================================================================
Basic Semantics
================
The ACLs for a particular directory or a file are generated traversing
from the "top-level directory", i.e., repository directory, towards
the particular directory or a file.
The basic semantics is restrictive-only. You cannot give additional
rights to user in a directory, if parent directory prohibits those
rights. E.g., if the module directory grants only "access" rights to
user, she could not in any way get a "modify" or "checkin" rights in
that module.
We must strictly differentiate between two cases:
- the directory itself does not have an associated Access Control
List (i.e., there is no file DIRACL in that directory, or it is
empty: this is rather common case);
- the directory has an associated Acess Control List.
Repository policy
------------------
"Repository policy" is an "allow"/"deny" decision which is used when
there were no associated ACLs in all of the directories along the
particular path. Repository policy is controlled by the
`CVSROOT/default-deny' file:
- if this file exists (its contents is ignored), the repository
policy is "deny";
- if this file does not exist, the repository policy is "allow".
Directory permissions semantics
--------------------------------
Here is how the permissions are checked for the particular directory:
- we set the current effective permissions to 'all';
- for each of the the parent directories down from the top-level
directory:
- if the parent directory does not have an ACL, it is skipped;
- if the parent directory has an ACL, we AND-mask the current
effective permissions with the permissions we get for that parent
directory;
[ E.g., those permissions could still be "all", or become
"access", or become completely restrictive, "none".
Note that there is no way for the effective permissions to
become less restrictive while traversing the list of [parent
directories. ]
- if none of the parent directories did have an associated ACL (i.e.,
this could happen in a pre-ACL repository), we look at an ACL for
the target directory. Again, there are two cases: either the
target directory has an associated ACL, or it doesn't have one.
So, we have four cases:
- parent directories did not have ACLs; target directory does not
have ACL:
we check the requested permissions against the repository
policy;
- parent directories did not have ACLs; target directory does have
ACL:
we check the requested permissions against the target directory
ACL;
- parent directories did have ACLs; target directory does not have
ACL:
we check the requested permissions agains combined permissions
of parent directories;
- parent directories did have ACLs; target directory does have ACL:
we check the requested permissions agains combined permissions
of parent directories combined with permissions of target
directory;
That's all.
--alexm
|
|
From: Alexey M. <al...@hs...> - 2002-02-10 22:29:30
|
hello, I've finally beaten the Zlib-client. It successfully checked out stock CVS from cvs.cvshome.org using compression. The checked out files compile ;) There is one glitch left: it sometimes hangs forever at the end of the checkout. I'll just need to set O_NONBLOCK and fix that (tomorrow). Thing to note about ncli: now any read() method could return -1, and set errno = EAGAIN (that's the only value of errno that could possibly appear). I thought about adding this long ago, but with zlib-client I was forced to. Enjoy, --alexm |
|
From: Alexey M. <al...@hs...> - 2002-01-20 20:56:36
|
>>>>> "PJS" == Patric J Stiffel <Pat...@xt...> writes: PJS> Hi, first: I am sorry to post to the developper list, but the userlist PJS> doesn't seem to be a crowded place, because the archive is empty. Feel PJS> free to tell me to use another forum for my questions. mailto: cvs...@hs... PJS> I just came across your sourceforge project, and I am in the middle of PJS> some tests whether we could use it to replace our current "regular" PJS> cvs. We are very interested in that acl-feature, and that's where my PJS> problems start. PJS> I tried to create a group, but cvs-nserver doesn't recognize the PJS> group-command. Isn't that implemented yet? Yes, it's not implemented. You should simply edit the CVSROOT/cvsgroup file. PJS> Also, I tried to PJS> establish different acl's on the same file for one user but on PJS> different branches and I experienced that there's always only one acl PJS> per file and per user, which means, that a existing acl will be PJS> deleted with a new acl, even when it's on another branch. Bug? cvs-nserver from CVS (on the NCLI-1-11-1 branch) has (working) support for branches. If there is any misbehaviour with regard to that, I'd like to hear. PJS> I am using version 1.11.1.51 both client/server on Solaris8/x86. PJS> Thanks for any help and comments. --alexm |
|
From: Patric J S. <Pat...@xt...> - 2002-01-18 15:39:48
|
Hi, first: I am sorry to post to the developper list, but the userlist does= n't seem to be a crowded place, because the archive is empty. Feel free to tell = me to use another forum for my questions. I just came across your sourceforge project, and I am in the middle of = some tests whether we could use it to replace our current "regular" cvs. We = are very interested in that acl-feature, and that's where my problems start= . I tried to create a group, but cvs-nserver doesn't recognize the group-command. Isn't that implemented yet? Also, I tried to establish different acl's on the same file for one use= r but on different branches and I experienced that there's always only one acl per file and per use= r, which means, that a existing acl will be deleted with a new acl, even when it's on anothe= r branch. Bug? I am using version 1.11.1.51 both client/server on Solaris8/x86. Thanks for any help and comments. Ciao, Patric -- Patric Stiffel mailto: st...@xt... Xtramind Technologies GmbH Telefon: ++49 681 302 5100 Stuhlsatzenhausweg 3 Telefax: ++49 681 302 5109 D-66123 Saarbr=FCcken Web: http://www.xtramind.com= |
|
From: Alexey M. <al...@hs...> - 2002-01-09 23:09:34
|
Please comment.
@node Repository access policy
@section Repository access policy
In most cases you simply set up single repository on a machine, and
there is only access policy: either the repository is online, or it is
offline. When the repository is put offline, the cvs server entry is
simply commented out of the @file{/etc/inetd.conf}, and that's all.
@cindex access policy
@cindex repository, access policies
@cindex policy
However, sometimes you manage lots of repositories on a single machine,
and you need to easily and conveniently manage access policy on for each
particular repository. Moreover, there is more than two simplest
policies. CVS-Nserver allows the following access policies:
@table @dfn
@item disabled
@cindex disabled repository
The repository is not available for logins. When login is attempted,
the generic "Access denied" message is returned, as if the repository
does not exist.
@item offline
@cindex offline repository
The repository is available for logins, but is not available for any
activity inside the repository. The explanation message is provided to
client after successful login.
@item read-only
@cindex read-only repository
The repository is available for logins, but only actions that do not
change the repository state are allowed.
@item online
@cindex online repository
The repository is fully functional. This is the default access policy
for the simplest case.
@end table
@cindex @samp{cvs-pserverx}
Repository access policies are managed by a special protocol front-end,
called @samp{cvs-pserverx}.
@quotation
@emph{Note: }Currently only the @samp{:pserver:} protocol allows policy
management.
@end quotation
@cindex @file{/etc/repositories}
@samp{cvs-pserverx} uses a special configuration file, usually called
@file{/etc/repositories}. This file contains human-readable description
of each repository, together with its status, and, probably, many other
parameters. Probably, there could be an indexed version of this file
lying near.
When the connection request arrives, @samp{inetd} accepts it and passes
control to the @samp{cvs-pserverx}, which reads the
@file{/etc/repositories}, receives repository access request from the
client, and decides what to do with this request, as described above.
@node Format of /etc/repositories
@section Format of @file{/etc/repositories}
@cindex @file{/etc/repositories}
The @file{/etc/repositories} is a human-readable text file. Its format
somewhat resembles the RFC822 format of Internet mail messages.
Below we'll show example entries for each type of repository.
Online repository is specified simply like this:
@example
Repository: /repos
Status: online
@end example
Read-only repository is specified together with the warning, that is
emitted to client before other messages:
@example
Repository: /repos
Status: read-only
Warning: This repository is temporarily in read-only mode.
@end example
Offline repository is specified together with explanation message, which
is emitted after the successful login:
@example
Repository: /repos
Status: offline
Message: This repository is temporarily put offline for maintenance.
Please contact the administrator at (555) 123-4567 if you have
any questions concerning this.
@end example
Disabled repository is specified simply:
@example
Repository: /repos
Status: disabled
@end example
There could be many more various fields in the description of each
repository. Obvious example that first comes to mind is the
@samp{Description} field.
--alexm
|
|
From: Wang J. <la...@li...> - 2002-01-06 11:11:58
|
Hello Alexey, OK, now I can use ACL. But the effect I want to get can't be got. For example, I have a module 'testmodule', and have user 'usera', 'userb', 'userc' $ cvs co testmodule $ cd testmodule $ cvs acl %nobody access,modify ./ $ cvs acl usera,userb access,modify ./ But 'userc' can checkout testmodule. And the acl subcommand has puzzling behaviours. Look at this, 'agent' and 'uspclient' are both modules. [lark@sw2 uspclient]$ /usr/local/bin/cvs acl %all access ./ Setting 'access' permissions for '%all' on directory uspclient/ [lark@sw2 uspclient]$ cd - /home/lark/cvsadmin/agent [lark@sw2 agent]$ /usr/local/bin/cvs acl %all access ./ cvs [server aborted]: Invalid branch permissions 'access' Monday, December 24, 2001, 6:46:09 AM, you wrote: >>>>>> "WJ" == Wang Jian <la...@li...> writes: WJ>> Hello, I test ACL on cvs-nserver but WJ>> [lark@sw2 foobar]$ /usr/local/bin/cvs acl access,modify . cvs [server WJ>> aborted]: admin is not allowed to manage ACLs AM> Create the CVSROOT/acl-admins file and add a line with 'admin' in it. WJ>> And I notice that cvs-nserver/acl/ is now empty in CVS repository in WJ>> cvs.sourceforge.net. AM> You've probably forgot about the -r NCLI-1-11-1. Or, if you're looking AM> through "Browse CVS repository", choose the appropriate tag. WJ>> cvs-nserver will not support builtin ACLs any more? AM> Why ever? :) AM> --alexm AM> _______________________________________________ AM> Cvs-nserver-devel mailing list AM> Cvs...@li... AM> https://lists.sourceforge.net/lists/listinfo/cvs-nserver-devel -- lark |
|
From: Alexey M. <al...@hs...> - 2001-12-26 23:10:37
|
>>>>> "l" == linuxx <li...@ja...> writes: l> Hi .. i have setup a stunnel cvs server ..that aparently start l> correct ... but Who you can connect to it ??? .. I try ... l> stunnel -c -d localhost:22222 -r server.remote:22401 & cvs login l> then it ask me for a password .. i suply it and it hang .. l> errors in log ... l> Dec 25 22:41:32 jaya stunnel[30531]: cvs-pserver connected from l> 192.168.0.2:3105 Dec 25 22:41:32 jaya stunnel[30531]: SSL_accept: l> error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol Humm, the ssl-client.c uses SSLv3_client_method(). Try to change it to SSLv23_client_method() and recompile. Does it work? l> i know im doings somethings bad... really bad... -- I think that's my fault wrt compatibility. --alexm |
|
From: Alexey M. <al...@hs...> - 2001-12-24 09:46:50
|
>>>>> "WJ" == Wang Jian <la...@li...> writes: WJ> Hello, I test ACL on cvs-nserver but WJ> [lark@sw2 foobar]$ /usr/local/bin/cvs acl access,modify . cvs [server WJ> aborted]: admin is not allowed to manage ACLs Create the CVSROOT/acl-admins file and add a line with 'admin' in it. WJ> And I notice that cvs-nserver/acl/ is now empty in CVS repository in WJ> cvs.sourceforge.net. You've probably forgot about the -r NCLI-1-11-1. Or, if you're looking through "Browse CVS repository", choose the appropriate tag. WJ> cvs-nserver will not support builtin ACLs any more? Why ever? :) --alexm |
|
From: Alexey M. <al...@hs...> - 2001-12-23 21:53:33
|
>>>>> "AM" == Alexey Morozov <mo...@us...> writes:
AM> Modified Files: Tag: NCLI-1-11-1 ls.c Log Message: Non-recursive
AM> directory listing seems to be fixed now. I need Alex's comments
AM> though...
AM> Index: ls.c
AM> RCS file: /cvsroot/cvs-nserver/cvs-nserver/src/Attic/ls.c,v
Looks ok. If it works ok -- then it's more thank ok, since you're the
target auditory of this subcommand.
Tiny comment: is that on purpose? Isn't the
static int local_only = 1;
enough?
@@ -167,6 +195,7 @@
if (argc < 0)
usage (ls_usage);
+ local_only = 1; /* Set the default */
optind = 0;
while ((c = getopt (argc, argv, "D:fRr:")) != -1)
{
--alexm
|
71 messages has been excluded from this view by a project administrator.
