[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linux Knowledge Base Project Requirements: Draft



In message <Pine.BSF.4.05.9810311344560.11265-100000@shell5.ba.best.com>,
aturner@best.com writes:
>http://linuxkb.seul.org/project.html
>
>Maintainer: No one.
>
>Means that nobody has offered to "own" it.  Feel free to make an offer.
>:-)  Hopefully everything will be owned soon.  

I tentatively claimed the Mirroring..this is something I mess with
quite a bit as it is, so I should be able to extend that to cover the
linuxkb.

>Speaking of which, does anyone have any multi-user source control
>experiance over remote systems?  I see three options:
>
>1) Some kind of web based CVS system.  I know they are out there, but I
>haven't been able to find anything useful and easy to use.  Should allow
>minimally to checkin, checkout, and get history logs.  Diffs would be also
>nice.  

webcvs is a nice program, but it's entirely passive -- you can view
histories, diffs, etc in a nice graphical form, but you can't authenticate
or checkin/out. I haven't run across a good fully functional web cvs 
implementation.

>2) NFS.  Obviously there are security and performance issues associated
>with this, not to mention the issue of sync'ing UID/GID on systems.  But
>it would be really easy to use.

NFS is pretty scary from a security point of view. I will not install it
on the seul computers without some internal hacks to confuse attackers
(which I don't currently have time for). What's the firewall status for
your proposed 'production' servers?

>3) Someone is smarter than me and has another idea.

At seul, we run cvs on cran, and people either
a) store their repositories on cran, and connect there via ssh and do
work locally
b) store their repositories on their home machines, set their CVSROOT
to ':ext:seul@cvs.seul.org:/home/seul/cvsroot', set their CVS_RSH to 'ssh',
and run cvs normally from their home machines. It works pretty well, though
cvs has a couple small bugs in its code for this.

Another alternative is what the gEDA project is using:
[root@cran /etc]# grep pserver *
inetd.conf:cvspserver stream tcp nowait root /usr/bin/cvs cvs pserver
services:cvspserver     2401/tcp

I don't know how it works, but apparently it does. In any case, the
cvs faq has several answers to this question, particularly focusing
on the authentication issues.

>Due to the fact that every page, form, CGI, DB, etc interacts with so much
>and no one person is going to be able to control all aspects of a single
>project, we're going to need something to prevent people from stepping on
>each others toes and manage the history of changes to aid with bug fixing.

CVS is what you want.

--Roger