successful lease event trigger

[Hans Liss]

Terry L. Inzauro wrote:
> Niall O'Reilly wrote:
>   
>> Terry L. Inzauro wrote:
>>     
>>> List,
>>>
>>> Whats the best way to keep/record ALL lease activity?
>>>       
>>     It's not clear to me what your requirements are:
>>     "best" for what purpose, "activity" in what sense?
>>
>>     The leases file shows the current state of all known dynamic
>>     leases, but not that of leases which are unknown.  IIUC, a lease
>>     becomes unknown which has at some time been, but no longer
>>     remains, in the  server's configuration, as it is not written to
>>     the leases file when this is updated.  If you need to record
>>     leases from before the last significant configuration change,
>>     you need to take account of this.
>>
>>     The logs show the recent history of lease activity, according
>>     to how long you keep them.  This history will show transaction-
>>     -level detail of activity relating to fixed addresses and to
>>     unknown (no longer known) leases.  It will also show activity
>>     relating to earlier history of currently known leases.
>>
>>     I think you'll find discussions both on processing logs and on
>>     parsing the leases file in the archives of this list.
>>
>>     If you can express your purpose more clearly, you may find
>>     either that a well-known solution is available or that there
>>     are people on this list who are interested in working with you
>>     to solve an outstanding problem.
>>
>>     Best regards,
>>
>>     Niall O'Reilly
>>     University College Dublin IT Services
>>     
>
>
> Well put.
>
> I would define best as "most efficient and easy to maintain". I like to keep configuration as simple and close to standards
> as possible.
>
> -----
>
> I am trying to derive a method of retaining the MAC/IP combinations (and maybe other information) for all successful leases
> for compliance and auditing  purposes.  Basically, in the public sector, I have to be able to tell law enforcement who (which
> mac addres) had obtained an address and at what time (to the best of my knowledge).
>
> At first I envisioned a script being ran upon a successful lease that would log various info to SQL or something like that.
> I thought this method would be possible based on the section called 'REFERENCE: EVENTS' (in man 5 dhcpd.conf) but I am
> finding a lack of documentation or examples on that particular subject.
>
> Perhaps I am making something out of nothing. Is this problem simply a matter tuning syslog-ng to log all DHCPD related
> messages to a log that is later archived indefinitely?
>   
I and a friend of mine spent a lot of time considering the options for 
doing exactly this, and we decided that there was really only one way to 
make it truly reliable, especially when running multiple dhcp servers in 
failover and standalone configurations. Tricks like keeping track of 
syslog entries or reading from the dhcpd.leases file just don't cut it 
in a production environment.

Instead, we opted for a small patch to dhcpd, to log all grants and 
releases to a small local database (using sqlite for performance and 
reliability), and then using a separate daemon to read those events and 
maintain lease entries in a central MySQL database, which means we can 
save lease information, including Option-82 data, for as long as we like.

This solution is very reliable and scalable, since nothing gets lost 
even if the daemon or the MySQL database is temporarily inaccessible - 
the events just get queued up in the sqlite database until they are 
processed. And since dhcpd iself produces the data, there is no text 
parsing whatsoever involved.

If you want to try this out, check out 
http://hans.liss.pp.se/software/gluff - there's much more info there, as 
well as the source code and patch.

/Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2222 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090612/117731a5/attachment.bin>