new server migration

Keith Packard keithp at
Tue Sep 2 23:45:50 EEST 2003

Around 14 o'clock on Sep 2, Havoc Pennington wrote:

>  1. write down a process for making sysadmin changes
>     so it isn't mass chaos - admin changes should be logged, 
>     posted to a list, or something along those lines. 

I've been keeping a commentary about changes I've made in ~root/blog on  It's got passwords for lots of stuff in it, so it
can't just be posted.  Perhaps a regular blog would work better, and a
separate place for passwords.  tikiwiki (oddly) has a fine blog module.

>  2. get backups running and verified

That's my first priority this week.  PSU has backup services that we might
be able to borrow, although it would be nice to get something far off site
so we can bring up a mirror if something really bad happens. If we can get
another host connected via I2, bandwidth would be free. Suggestions on
suitable sites would be welcome.

>  4. move the current web site, unmodified. Move cron jobs
>     to the new server.

I've pulled the current web site from CVS and have it running at just to see if it works.  I added pointers to 
the dynamic content (tikiwiki), but otherwise it's the same old bits.

> 6. add Wiki functionality, taking care to preserve existing URLs 
>    and content

TThat may take quite a bit of work in the apache rewrite code; wiki's have 
weird URLs.

>  8. create a bugzilla instance (I'd like to see some of the
>     bugzilla changes, too, the kde bugzilla is much simpler to use)

Bugzilla is installed at, but it's the vanilla 
code from the debian distro.  Running upstream code does make tracking 
changes easier, but if someone has bandwidth to maintain improved bits, we 
should look at that as well.


More information about the xdg mailing list