On Wed, 21 Jul, 2004 at 14:37:24 -0700, Peter Mueller wrote:
> > Hmmm... Maybe I should just go with CF/DOM or something else, 
> > solid state,
> > and set up a server to move the logs to $whenever, accepting 
> > the fact that
> > chips get worn out aftesr so-and-so-many rewrites...
> 
> Yes, this is what I would (have) done.  CF is badass, it boots so fast.

Indeed. I'm very happy with the CF setup. (In case you missed my original
post, the machine does boot from CF. The idea was to have a harddisk only
for logging)
 
> > I find it sort of ironic, having spent much time in order to 
> > put the logs on
> > disk (so they would survive powercuts etc), that those same 
> > logs are now
> > lost because the disk died... :P
> 
> Well why don't you set up a remote syslog server instead?

I will, eventually. It's just that I don't *have* a server for the job, yet.
 
> /etc/syslog.conf:
> *.*                                                     @10.0.0.1
> 
> Then /etc/init.d/sysklogd restart.
> 
> On the remote server, you will need to allow firewall rules (if
> necessary) and configure syslogd to accept remote logs.  This is done on
> redhat via /etc/sysconfig/syslog:
> SYSLOGD_OPTIONS="-m 0 -r"
> On other distributions you can probably modify the Sys-V script
> directly.

Thing is, having (a) server(s) on location(s) is not always an option and
I'm not very fond of the idea of logging across the Internet, for a couple
of reasons:

- Clear text.
- Both lines must be up, always
- Opening udp/514 is a potential risk @server

to name a few.

I would much rather have something like:

Logging done on router
Logs get compressed
Compressed logs get traferred via encrypted mechanisn (scp f.x.) to server

At this point I'm in the discovery/research phase. In the not too distant
future legislation will be passed, that will require logging of *all*
traffic, as part of the Danish government's anti-terror measures.

This means that I have to make reasonably sure that the logs are kept

- private
- secure 
- available

etc...

I'm leaning towards logrotate as the first part of the process, on the
router(s). Partly because logrotate acts on filesizes, and hence introduces
a semi-randomness in the compression/transfer-to-server process. (Since the
size of the logs are a function of the traffic volume, which varies)

What this means is that the router should have a capacity for storing the
logs, until such a time when they can be moved to the server (in the event
that either line is down, when the router wants to initiate a transfer).

Hence the introduction of NV-media.

Pointers welcome.

Cheers,
/Jon

BTW: No need to Cc: me, I'm on the list :)
-- 
Just say "know!"


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to