18 Dec, 2008, Asylumius wrote in the 1st comment:
Votes: 0
Another thread got me wonder what other people do on the subjects of logging, auditing, backups, and misc. administration. So..

On your server / MUD, do you have any interesting or unique ways of handling these issues?

My old ROM MUD had logs, of course, but they never went beyond big text files that looked like:
[Thu Dec 18 16:26:08 CST 2008] SomeImmGuy slayed SomeMortalGuy in room 1234.
[Thu Dec 18 16:26:08 CST 2008] SomeImmGuy loaded Crown of Awesomeness (8382).

We also had a cron job do daily backups and ftp them off site, as well as some utility scripts to delete old pfiles and clean up some data files.

Beyond that though, nothing very interesting or cool.

One-up me, please!
18 Dec, 2008, David Haley wrote in the 2nd comment:
Votes: 0
We also just log the commands that were typed. Unfortunately, this is bad for at least two reasons:
(1) it doesn't reflect what actually happened, e.g. if some kind of name completion came into play. e.g.,: "slay ge" (who did "ge" resolve to?)
(2) it doesn't reflect what actually happened because the context is missing. e.g., many commands have some kind of relative effect, but without knowing what the state was, it's hard to know how to undo the actions.

I had a cron job at one point that did daily incremental backups to a remote site, but I stopped maintaining it when our MUD went into "hibernation".

So nothing terribly interesting. It's part of why a security breach could be disastrous at worst, and very annoying at best in terms of how much time it would take to reverse it.
18 Dec, 2008, quixadhal wrote in the 3rd comment:
Votes: 0
If I were seriously developing my MUD with the idea of really having people play it, I'd put all the data files in svn version control. That way, if anyone gets whizz privs and has fun with OLC, or gets into the shell and deletes the game, I can just revert back to the last svn checkin… even if a daily job does a checkin, you can always go back further if you need to.

Of course, if someone hacks your root account, all bets are off. In that case, only offline/offsite backups will save you.

MUD's are so small, compared to most traffic these days, a cron job to tar.bz2 them up and scp/ftp/etc the archive off to another site is pretty easy to do.
18 Dec, 2008, Kline wrote in the 4th comment:
Votes: 0
I can't praise SVN enough. I first just started using it for a public development project, then later moved an actual production game into a SVN repo, too (private, though). It's perfect for not only code/area reversions if I break something horribly, but for player backups, to have a series of such small snapshots.
18 Dec, 2008, Lyanic wrote in the 5th comment:
Votes: 0
Likewise - use SVN (and Trac, though that's a different issue) on The 7th Plane. The SVN repository is also located on a different server from the production code of the game.
19 Dec, 2008, Guest wrote in the 6th comment:
Votes: 0
Never used SVN for more than source code on Alsherok, but it came in handy for that. We are using it now for everything at smaugmuds.org which I'm sure is going to make our lives easier there.

As far as automated backups, the ones I do now for server stuff are once a week for the database, and once a month for my personal sites. I just do the cheap and quick email method and then burn the older files to DVD every so often. Far cry from having not kept any kind of regular backups at all, which I paid for dearly last year.
19 Dec, 2008, Kayle wrote in the 7th comment:
Votes: 0
I use SVN for my code, and then I also dump my database and tarball my database, mud and website up and email it to myself every friday morning. I too paid dearly with the HD failure at Arthmoor last year.
19 Dec, 2008, Tyche wrote in the 8th comment:
Votes: 0
Well when I hosted remotely, I used to have a cron job locally that would run daily rsync with the entire shell.
I used to use RCS locally for the source – the Windows version.

Now days I have two hard drives.
All my source codes and website templates/html/blahblah are in SVN repositories.
With cron jobs..
I run daily SQL exports and tarballs on all my websites.
I run weekly SVN exports and tarballs.
I run monthly tarballs of other important directories.
All these tarballs go to the 2nd harddrive.

Every now and then, and not as often as I should, I insert a DVD and manually clickity click on the above stuff and various directories and thingies that aren't covered by the above…until the DVD is really really full to bursting, and let it burn.
19 Dec, 2008, Scandum wrote in the 9th comment:
Votes: 0
I kind of hacked a weekly call to a backup script into my mud's update routine and it automagically emails it to the mud's gmail account on a monthly basis.
19 Dec, 2008, Davion wrote in the 10th comment:
Votes: 0
Scandum said:
I kind of hacked a weekly call to a backup script into my mud's update routine and it automagically emails it to the mud's gmail account on a monthly basis.


Hey! Care to share this script here? That sounds like a pretty worth-while hack.
19 Dec, 2008, Scandum wrote in the 11th comment:
Votes: 0
Sure, I'll have a look at it when I have time.
19 Dec, 2008, David Haley wrote in the 12th comment:
Votes: 0
Oh yeah. I also of course use revision control (bzr in my case). I have all code files, of course, and some area files.

quixadhal said:
Of course, if someone hacks your root account, all bets are off. In that case, only offline/offsite backups will save you.

MUD's are so small, compared to most traffic these days, a cron job to tar.bz2 them up and scp/ftp/etc the archive off to another site is pretty easy to do.

Ah, but there is a much more insidious problem here. If your cron job is able to log in somewhere, e.g. using scp, to upload those files, that means that you are either storing the password as-is or have some kind of ssh key authentication. In any case, the attacker who gets root access on machine A will have the means to log into offsite machine B as the backup user.

To be truly secure, you would need to sandbox that backup user very heavily, and on the offsite machine move the backup files into some location that the backup user cannot see.

Of course, I probably wouldn't seriously recommend this level of security for anything that didn't involve money or other very important thing. It's just important to know that automated offsite backups are not a guarantee of security. (Sometimes having a dinky lock is worse than having no lock at all, because the dinky lock might make you think people can't open the door. If you know that you're unsafe, you take precautions to not leave important stuff lying around.)
20 Dec, 2008, Scandum wrote in the 13th comment:
Votes: 0
Scandum said:
Sure, I'll have a look at it when I have time.


I uploaded it to the repository: http://www.mudbytes.net/index.php?a=file...
0.0/13