Top Mud Sites Forum - View Single Post

Traithe · 10-28-2004, 01:37 PM

It's funny that this came up when it did. We've not encountered any problems of this sort just yet (well, on the staff side of things, anyway), but I just finished implementing a completely rewritten logging system on our MUD which should in theory make the validation of any such allegations fairly simple.

Our problem before was that, due to the nature of our log system, our logs tended to completely cycle through every week or so. The logs were standard text flatfiles, which the server searched through for any specified terms using grep and then piped the output to the staffer. The reason the logs had to cycle out every so often was that since the newest entries are appended to the end of the files, if the files became too large it was simply impossible to access recent entries, since the output buffers piping the results were only so large - allow the files to become too large, and with a search term returning a lot of results (many of them very old), you wouldn't be able to access a log entry that was just generated five minutes ago! (How's that for brilliant design?)

The new system is completely database-driven. In addition to being much more intelligent about searching, it also gives us the ability to store logs for an indefinite period. So, instead of rather dumbly searching for a given term or combination of terms in a text file, you can tell it to only search for your term(s) within certain entries that fall within a date range, were generated by a specific PC, account or NPC, generated by a given command, generated on the specified server port or in the specified room, etc. In addition, the output defaults to showing the newest entries FIRST - so no matter how long we keep the logs around, the problem above won't arise. Finally, you can specify as part of the command an option to reverse the order - showing the oldest entries first. This is useful if you need to retrieve very old log entries - you could tell it to search all entries within the last 6 months, for example, and then use that option to quickly find what you need in the output.

Everything on the server is logged, albeit in separate areas. There's a database for player commands, staff commands, and guest login commands. All staffers can access the player and guest databases; as a nod to respecting the other admins' privacy, only myself and the lead admin can access the staff database. Everyone online, whether a guest, player, or staff member, is informed that everything they do is logged and stored indefinitely. I haven't had any complaints about it yet - but, of course, people who aren't comfortable with that sort of thing likely won't play long enough to complain.

Even under the old system we were able to catch cheating players fairly easily (though since we lost our logs every week or so it's hard to say how many got away), so I imagine the new setup will help cut down on that sort of behavior even further.

10-28-2004, 01:37 PM	#7
Traithe Member Join Date: Jan 2003 Name: Kite Posts: 131	It's funny that this came up when it did. We've not encountered any problems of this sort just yet (well, on the staff side of things, anyway), but I just finished implementing a completely rewritten logging system on our MUD which should in theory make the validation of any such allegations fairly simple. Our problem before was that, due to the nature of our log system, our logs tended to completely cycle through every week or so. The logs were standard text flatfiles, which the server searched through for any specified terms using grep and then piped the output to the staffer. The reason the logs had to cycle out every so often was that since the newest entries are appended to the end of the files, if the files became too large it was simply impossible to access recent entries, since the output buffers piping the results were only so large - allow the files to become too large, and with a search term returning a lot of results (many of them very old), you wouldn't be able to access a log entry that was just generated five minutes ago! (How's that for brilliant design?) The new system is completely database-driven. In addition to being much more intelligent about searching, it also gives us the ability to store logs for an indefinite period. So, instead of rather dumbly searching for a given term or combination of terms in a text file, you can tell it to only search for your term(s) within certain entries that fall within a date range, were generated by a specific PC, account or NPC, generated by a given command, generated on the specified server port or in the specified room, etc. In addition, the output defaults to showing the newest entries FIRST - so no matter how long we keep the logs around, the problem above won't arise. Finally, you can specify as part of the command an option to reverse the order - showing the oldest entries first. This is useful if you need to retrieve very old log entries - you could tell it to search all entries within the last 6 months, for example, and then use that option to quickly find what you need in the output. Everything on the server is logged, albeit in separate areas. There's a database for player commands, staff commands, and guest login commands. All staffers can access the player and guest databases; as a nod to respecting the other admins' privacy, only myself and the lead admin can access the staff database. Everyone online, whether a guest, player, or staff member, is informed that everything they do is logged and stored indefinitely. I haven't had any complaints about it yet - but, of course, people who aren't comfortable with that sort of thing likely won't play long enough to complain. Even under the old system we were able to catch cheating players fairly easily (though since we lost our logs every week or so it's hard to say how many got away), so I imagine the new setup will help cut down on that sort of behavior even further.