[bf1942] Linux server status update 2003-04-28

[Reinder Gerritsen]

Some time ago, with the halflife server, there was this bug that a
malicious player could crash the server with a say command, and some wild
characters.

Because of the cashing of this within the same process, the server
process crashed without flushing the very info that was causing the crash.

Now I'm not a programmer, not even a beginner at it, but wouldn't it be so
that this information, when piped out on a socket to a second process to
do the compressing and writing to disk thingy, was preserved because the
process generating the logging info is different from the process that is
doing the logging and compression jobs on it?

As for logging to another server, NFS might be a
solution, sure, but... I've got this thing about running anything that
isn't absolutely neccesary. NFS had some history on nasty security bugs...

my guess is dat a UDP parser on the recieving end, be it the same server,
or a totally different one is the most flexible and easy-est to implement.


Just a rookie thought, nothing more, but it sounds rather nice, this Net
piping thingy.


On Tue, 29 Apr 2003, Fredriksson, Andreas wrote:

>
> I'm making the compression an option right now. If you need remote
> logging you could use NFS or other means of transferring the files,
> or just install a daemon on the bf server machine to snoop for new
> files, tail -f them and remove them as new files appear.
>
> // Andreas
>
> > -----Original Message-----
> > From: Scratch Monkey [mailto:ScratchMonkey at SewingWitch.com]
> > Sent: Tuesday, April 29, 2003 11:44 AM
> > To: bf1942 at icculus.org
> > Subject: RE: Re[2]: [bf1942] Linux server status update 2003-04-28
> >
> >
> > --On Tuesday, April 29, 2003 11:29 AM +0200 "Fredriksson, Andreas"
> > <andreas.fredriksson at dice.se> wrote:
> >
> > > I'm thinking about making the compression optional, but it
> > > really is needed because the log files easily reach several
> > > megabytes of size for a single round without compression.
> >
> > This calls for plumbing! Feed the output to a socket ("named pipe" for
> > Windows) and use another process to do real-time stats processing and
> > compression. If you use a TCP socket, the stats need not be
> > stored on the same
> > machine. Not sure how the Windows guys could deal with that,
> > but a Linux
> > script could capture with netcat and feed it to both the
> > stats engine and
> > one's choice of compressor. On an SMP machine, the compressor
> > will migrate to
> > the CPU not being used for the game.
> >
>