David Lesher writes:
> I've never been clear on what Xemacs uses/needs on their side of
> the box.
XEmacs currently uses the following Tux services. On which box they
are going to reside in the future I don't know, so I'm just going to
list them all, with the box where we *currently* access them in parens.
1. Several XEmacs developers have unprivileged user shell accounts.
These have always been treated as "property" of the individual,
based on an introduction via XEmacs, though. I don't know what
others use them for. (gwyn)
2. An xemacadm group for the XEmacs developers. (gwyn)
3. An xemacweb shell account for the httpd and for shell access by
the webmaster. This is also currently used by our Mailman setup.
(gwyn)
4. Distributions (accessible through FTP and maybe HTTP) and website
static pages (HTTP). We've discussed a wiki but never done
anything about it. Distributions are uploaded via shell accounts
of the release engineers (currently myself, Vin Shelton, and
Norbert Koch). The website configuration (search etc) is done
using shell access, the content is automatically updated via ssh
to xemacweb triggering a CVS update and site rebuild from a commit
hook script in our CVS repository at dotsrc.org.
5. Primary DNS for the xemacs.org domain. This is updated by shell
on gwyn plus a restricted sudo for a couple of hostmasters (me and
Adrian, I think) to reload BIND. (gwyn) Secondaries are provided
outside of Tux by dotsrc.org and somebody else. It is proposed to
move to the stealth master + multiple Tux nameservers model that
tux.org domain uses.
6. Mail forwarding via virtusertable for XEmacs developers. (gwyn)
Maintenance of the virtusertable and MTA aliases table are done by
shell, with a couple of postmasters having restricted sudo access
to run newaliases and make -f /etc/mail/Makefile.
7. Mailman mailing lists. (gwyn, calypso) gwyn is the primary MX for
xemacs.org. Mail sent to LIST at xemacs.org gets an identifying
header inserted, then is delivered to xemacweb at gwyn, which
processes it with procmail, and forwards anything not determined
to be spam to LIST at calypso, where it is processed normally by
Mailman. I'd like to clean this up, but the last time I checked
we really needed some of our own recipes, and the powers that were
didn't allow us to write our own SpamAssassin rules. (Could have
run a separate instance of SA but that seemed too wasteful.) I
have pretty broad sudo authorization on calypso I think, but I've
only ever used it to restart Mailman and access some private
archives we have, so I'm not exactly sure how far it extends.
Other services that have been proposed but never followed up are a
wiki, read-only mirrors of our source repos, and an issue tracker.
> Do we need to have a separate Linux vm for you? How much of your
> CPU and storage space is straight archive serving vs. interactive?
Currently all of our public services from gwyn are static. However,
I'd like to provide more dynamic content as described above.