"developer services" development update

[Erik Walthinsen <omega@omegacs.net>]

For the last few weeks I've been hacking on dev1 here trying to get all the 
various SEUL developer services (cvs, mail, web, etc) both integrated and 
separated.</paradox>  What I really mean is that everything is well on its 
way to becoming a unified system, where everything is properly integrated, 
but in a manner such that things can be split off as necessary, for new 
hosts.

For instance, if things go as planned, cran (or it's equiv) will be running 
majordomo, using belegost simply for bulk_mailer and mail handling.  This
will make having <user>@seul.org almost a trivial matter of maintaining 
.forward files, plus all the majordomo maintainence can be done on a central 
machine without permissions worries (other than those imposed by overly 
paranoid majordomo...).

As of last night, I now have the repository set up with appropriate CVS traps 
so that the public_html tree is now truly auto-updating.  Any commit into the 
repo will automatically update a development copy of the tree, which is 
currently virthosted as www-test.seul.org.  A rtag (release tag) to the 
public_html module will do an update of the real tree, which is currently 
running as test.seul.org.

The other part of the process that's working is the group documentation 
updating.  Any file checked into a directory in the repository with 'doc' in 
the pathname is automatically copied, on commit, to the public_html tree.  
This allows people to read all project documentation without people having to 
have perms to the public_html module.  Note that this also includes things 
like doc/ subdirectories from various packages that we put under CVS control. 
This may or may not be a good thing, that remains to be decided.  Comments on 
that would be welcome.

The next few things I'll be implementing are a user (developer) database, to 
deal with mail forwarding and so on, and permissions in the CVS repository.  
Luka and I have found out the hard way that normal filesystem permissions 
just don't cut it, so I'm going to develop a script that (dis)allows commits 
to files based on where they are and who the person is.  We can create 
arbitrary groups, with each directory granting any number of groups write 
access.

I'll also be working on splitting the e-mail archives into weekly or monthly 
sub-archives, and getting the search mechanisms to deal with this without 
getting too hosed.  Anyone with experience in MHonArc or (web)glimpse out 
there?

Oh yeah, by the end of the week I should be able to hand out test accounts on 
the machine (it's behind a 33.6 PPP, though) so you can all try things out.  
Ken, that'd include you, with your helpd code... :)

Anyway, back to work.  (oh, and I suppose I should do my calc homework, too)

TTYL,
    Omega

      Erik Walthinsen - SEUL Project infrastructure/system architecture
        __
       /  \           omega@sequent.com         Work: (503)578-5314
      |    | M E G A  omega@omegacs.net         Home: (503)281-4281
      _\  /_          psu12113@odin.cc.pdx.edu  Majoring in CS

       SEUL: Simple End-User Linux - creating a Linux distribution
     http://www.seul.org/            for the average home/office user



===
SEUL-Leaders list, seul-leaders-request@seul.mit.edu
===