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

Re: Linux Knowledge Base Project Requirements: Draft



-----BEGIN PGP SIGNED MESSAGE-----


On Sun, 1 Nov 1998, Roger Dingledine wrote:

> 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.

I don't know how viable a mirror site will be.  A lot of the content will
be dynamic, which makes standard mirroring tools like w3mir useless.
Mirroring makes things like site design and links a lot more complicated.
And if we will have a dedicated domain and server, a mirror is of
questionable value. I think that SEUL would be better utilized as a test
enviroment where we can try new things, software versions, etc without
risking the production site.  Another idea is to use it as a image server-

> >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.

I've already installed the FreeBSD enhanced webcvs on cran.  Your analysis
is right on.
 
> >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?

ACL's on the border routers.  Also the NFS server would be accessable via
a different interface/network than what www.linuxkb.net would be.
Basically that adds up to security through obscurity and clients need to
have valid static IP's.  Not what I call super security, but it may be
good enough.
 
> >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

Not going to work for us I suspect.  I suspect people will want to do
development at their home machine and easily sync it.  Standard scp is
hardly "easy" for syncing perposes of this sort.

> 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.

Hmmm... this sounds like a possibility.  What does "a couple of small
bugs" mean exactly?

> 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.

Another interesting idea.  I'll check out the CVS faq, and report back to
the group with my findings.

> >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.

Agreed.

- -- 
Aaron Turner           | Either which way, one half dozen or another. 
aturner@pobox.com      | Check out the Red Hat Linux User's FAQ Online!
www.pobox.com/~aturner | http://www.pobox.com/~aturner/RedHat-FAQ/
All emails from this account are PGP signed.  Lack of a signature is "bad".
PGP Key fingerprint = FB E1 CE ED 57 E4 AB 80  59 6E 60 BF 45 1B 20 E8



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNjz4TDM3jpXy1kJtAQHmrgQAvKSrX2+hdICNOAWC897mDptKtYXthIY/
ko272+aOjteiPUDTPnjJ5e0D+jfcxXNjNUNEWwvneYOnGiOB+aFJbF6YeFkIfYI7
bGKgkPlGhu3jEBXz+LasMUcoxG/2fgAAzVIFBgCtHoK+9KFgXwq5Ny49oxzpDu28
EDW4ZKQ8b/M=
=22eF
-----END PGP SIGNATURE-----