Perhaps "worthless" is an exaggeration, but I certainly agree that a
timestamp is worthy of inclusion in a newly updated logging specification.
The term "client" means the emitter of syslog packets, and the term "server"
refers to the logging agent. I understand that for many purposes, a two-way
communication may not be possible, or desirable.
The proposed specification might state that the server should include a
timestamp in xxx format; client should emit a timestamp at suchandsuch
position within the syslog packet; client should implement a lightweight
universal time service/client etc.). A logged record might include both the
time of emission by the client, and the time of receipt by the server.
A bigger issue here will be a clear definition of our objectives beyond
documenting the existing syslog(s). These clearly include
(1) integrity of the logfile;
(2) validity of data in the logfile;
(3) networking issues, such as encryption and authentication of syslog
clients and communication paths.
(4) Is UTP the right way to go? (flame suit on).
But we do need objectives.
In my case, I am more involved with non-Unix systems (e.g., OpenVMS and
WindowsNT) but I need a reliable network logging service (I only know about
this because of several boxes that emit syslog messages). Of course, much of
the world has gone over to building network appliances which included http
servers, so we don't want to go over that ground...
I will be glad to help in any way I can, but I don't have a lot of time to
give.
Carl Friedberg, comet & company, [EMAIL PROTECTED], New York City usa
-----Original Message-----
From: Chad Schieken [mailto:[EMAIL PROTECTED]]
---snippage---
>>>1. Logs without accurate timestamps are worthless
---snippage---
>>I guess it comes down to what problem - or set of problems
>> - we're trying to solve.
>>dan
