'Re: [ntp:hackers] [ntpwg] Proposal for multiple log file capability'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    Re: [ntp:hackers] [ntpwg] Proposal for multiple log file capability
From:       Rob Neal <hundoj () comcast ! net>
Date:       2009-10-21 16:20:51
Message-ID: 20091021101005.G12868 () bulldog ! localhost ! org
[Download RAW message or body]

On Mon, 19 Oct 2009, tglassey wrote:

> David Mills wrote:
>> Tod,
>>
>> All the events produce a trap which you can configure any way you
>> choose.
> Within the NTP environment I agree but there is nothing to configure
> that trap from the ntp.conf file For instance we should allow policy
> controls to send out traps and possibly emails under policy controls.
 	There is the "trap" configuration keyword, which allows
 	specification of destination address and port.
 	That would seem to me to be adequate - the trap recipient
 	could run whatever notification chain one wished, based
 	on the content of the trap datagram.
 	Granted, no trap listener program comes with the NTP
 	distro, but shouldn't that function be divorced from
 	the delivery agent? It's not especially hard to write
 	that sort of thing, even for a netnoob like me.

 	My biggest concern here is configuration complexity
 	being added to the ntp.conf file, to sort out event/dest/distro
 	list stuff. That could grow real hair, quickly. At the very least,
 	that sort of policy should be stuffed off in another config
 	grotto, away from ntp.conf. IMHO. 
>
> Remember that most people dont run their internal NTP Services wide open
> to the world and so they will not have bazillions of systems in their
> logs only the ones they expect. So the log management on non-public
> servers is no where near the pain of managing the logs on an open system.
>> Creating a new filegen fileset is easy, but sorting through the
>> probable thousand syslog and event calls and clasifying them as to which
>> log/file to update is a truly time consuming effort.
> I agree this used to be true but today its the case only if its done
> manually which no one in the security world really does anymore.
>> You are invited to
>> scan the source and make a case for hou you would like to classify each
>> case for each old or new fileset.
>>
> OK - I will have that in by this weekend. Thanks for considering the
> changes.
>
> Todd
>> Dave
>>
>> Todd Glassey wrote:
>>
>>
>>> David Mills wrote:
>>>
>>>
>>>> Todd,
>>>>
>>>> You might get more traction if you include this to hackers@ntp.org.
>>>>
>>>>
>>> That implies that the list management will allow me to post - they
>>> don't allow me to post on QUESTIONS so maybe not.
>>>
>>>
>>>> The reference implementation already has multiple log files using the
>>>> filegen facility. You probably already know about the peerstats,
>>>> loopstats and clockstats files. Now there are the systats file that
>>>> logs system statistics of interest to administrators, the protostats
>>>> file that logs protocol events of interest to sysadmins and the
>>>> cryptostats file that logs events of initerest to security folks. We
>>>> can add more or retarget the existing ones.
>>>>
>>> Thanks - I agree with you that the stats files are pretty much the
>>> cats meow for creating reliable plotting but I think we need to also
>>> put a time-management daemon into the mix (in addition to NTPD) so
>>> that the policies can optionally trigger other events like SNMP Traps
>>> or RMON events and the like.
>>>
>>>
>>>> Personally I find the protostats file the most useful for everyday
>>>> watching.
>>>>
>>>>
>>> The protostats are a good start but as I said - I want to re-target
>>> the logging and policy controls.
>>>
>>> Todd
>>>
>>>
>>>> Dave
>>>>
>>>> Todd Glassey wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> I want to propose that we add a new level of logging to the NTP
>>>>> Suite and that allows us to specify different logs for different
>>>>> types of events. Today all the events are in one log and that means
>>>>> it has to be searched at real time continuously which can be a pain
>>>>> to separate and track the different types of alarm events in a time
>>>>> management practice.
>>>>>
>>>>> That said we might consider adding the ability to also add multiple
>>>>> logging stream capability to this service...
>>>>>
>>>>> Just a thought.
>>>>>
>>>>> Todd Glassey
>>>>> _______________________________________________
>>>>> ntpwg mailing list
>>>>> ntpwg@lists.ntp.org
>>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> ntpwg mailing list
>>>> ntpwg@lists.ntp.org
>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com Version: 8.5.422 / Virus Database:
>>>> 270.14.20/2444 - Release Date: 10/18/09 09:04:00
>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> hackers mailing list
>> hackers@lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/hackers
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.422 / Virus Database: 270.14.21/2445 - Release Date: 10/19/09 06:40:00
>>
>>
>
> _______________________________________________
> hackers mailing list
> hackers@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers
>
_______________________________________________
hackers mailing list
hackers@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/hackers
[prev in list] [next in list] [prev in thread] [next in thread] 