Re: Functional test of KDC for monitoring?
On Feb 13, 2013, at 11:21 AM, Nico Williams n...@cryptonector.com wrote: On Wed, Feb 13, 2013 at 6:12 AM, John Devitofranceschi j...@optonline.net wrote: One thing that we do is monitor propagation. Something like: lpc=get_last_princ_changed; master_lpc_kvno=get_kvno(master_kdc, lpc); init_error_state; foreach kdc (@slave_kdc_list) ; do slave_lpc_kvno= get_kvno(kdc, lpc); if (master_lpc_kvno != slave_lpc_kvno) then set_error_state; fi done report_error_state; Note that this will fail to detect failures to iprop other principals. Yes, I know. The intention is to insure that the slave kpropd services are running and not obviously blocked rather than making certain that every update occurs. I recall is that in the old NetInfo system, you could say niutil -statistics -t host-tagged-domain-spec and get lots of information about the state of the database on a specified host, including a database checksum. Being able to query the kdc's for that kind of thing would be most useful to efficiently insure that propagation is working properly from a remote monitoring system jd Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Functional test of KDC for monitoring?
On Jan 15, 2013, at 9:58 AM, Nico Williams n...@cryptonector.com wrote: On Tue, Jan 15, 2013 at 12:38 AM, Roland C. Dowdeswell el...@imrryr.org wrote: And [to the MIT developers], I think that it would be nice if there were either (1) functionality within Kerberos which allowed for the writing of programs such as this without overriding functions, i.e. allow library users to tell the libs to use a particular KDC; or (2) if k5ping or a similar program were integrated into MIT Kerberos to aid in monitoring as this is a need that all enterprise deployments of Kerberos need. I second this. k5ping is much too useful and conceptually simple to be so difficult to implement. One thing that we do is monitor propagation. Something like: lpc=get_last_princ_changed; master_lpc_kvno=get_kvno(master_kdc, lpc); init_error_state; foreach kdc (@slave_kdc_list) ; do slave_lpc_kvno= get_kvno(kdc, lpc); if (master_lpc_kvno != slave_lpc_kvno) then set_error_state; fi done report_error_state; The challenge that I see is getting the last princ changed. You can scrape the logs or run the monitor on the master and use kproplog. What would be nice is if kadmin had client-visible requests that gave you visibility into iprop status. jd Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Functional test of KDC for monitoring?
On Wed, Feb 13, 2013 at 6:12 AM, John Devitofranceschi j...@optonline.net wrote: One thing that we do is monitor propagation. Something like: lpc=get_last_princ_changed; master_lpc_kvno=get_kvno(master_kdc, lpc); init_error_state; foreach kdc (@slave_kdc_list) ; do slave_lpc_kvno= get_kvno(kdc, lpc); if (master_lpc_kvno != slave_lpc_kvno) then set_error_state; fi done report_error_state; Note that this will fail to detect failures to iprop other principals. Ideally there'd be a cheap, constant-time way compare DBs. Something like having a Merkle hash tree so we need only compare root hashes. But changing the KDB to have such a form is involved, and it implies some additional trade-offs (e.g., can't possibly have higher write concurrency without at least serializing the last part of each commit). The challenge that I see is getting the last princ changed. You can scrape the logs or run the monitor on the master and use kproplog. Yup! What would be nice is if kadmin had client-visible requests that gave you visibility into iprop status. Interesting idea. Basically an RPC for getting the ulog. In fact, the kadmin server has this -- it's the kadmin client that lacks a UI to it. Also, we really should want to keep complete ulogs on the slaves as well so we can inspect them and see if any changes were missed. Among other things it would make it easier to write thorough tests! Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Functional test of KDC for monitoring?
On Tue, Jan 15, 2013 at 12:38 AM, Roland C. Dowdeswell el...@imrryr.org wrote: And [to the MIT developers], I think that it would be nice if there were either (1) functionality within Kerberos which allowed for the writing of programs such as this without overriding functions, i.e. allow library users to tell the libs to use a particular KDC; or (2) if k5ping or a similar program were integrated into MIT Kerberos to aid in monitoring as this is a need that all enterprise deployments of Kerberos need. I second this. k5ping is much too useful and conceptually simple to be so difficult to implement. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Functional test of KDC for monitoring?
On Sat, Jan 12, 2013 at 11:19:03AM +0100, Jan-Piet Mens wrote: How are folks performing functional testing of KDCs (without PKINIT)? We have a very primitive Nagios/Icinga plugin (loosely based on [1]) which invokes `kinit' with a keytab. This verifies that the round-trip principal-KDC-OpenLDAP is possible. I have used: http://oskt.secure-endpoints.com/k5ping.html http://oskt.secure-endpoints.com/gitweb.cgi?p=k5ping;a=tree in the past. I have last compiled it against MIT Kerberos 1.4, I think, so it may need a little fixing. It provides a certain number of critical advantages over simply using kinit -k: 1. individually test KDCs, 2. test AS and TGS, and 3. UDP and TCP testing. Command line usage is simple: $ k5ping kdc1 [kdc2 ...] With a few flags to change behaviour, like -t to only test TCP or -u to only test UDP. I have found in the past that the testing of both TCP and UDP would have saved me a fair bit of frustration at a prior environment as it is possible for a KDC to have only one of the two services running and there are also clients that can only use one or the other. In addition to monitoring the KDCs, I would also strongly recommend that the scripts that you use to upgrade KDCs operate in this sort of way (shell script syntax used to aid readability but this is not actually a script): #!/bin/sh KDCS=your KDC list set -e for i in $KDCS; do upgrade_kdc $i k5ping $i sleep 10 done Or something along those lines. It's always good to ensure that your process terminates quickly if things start to progress in an unexpected fashion... If you are interested in using this, I can work with you to bring the code up to date for the current release of MIT Kerberos (it may just work, I haven't tried it...) And [to the MIT developers], I think that it would be nice if there were either (1) functionality within Kerberos which allowed for the writing of programs such as this without overriding functions, i.e. allow library users to tell the libs to use a particular KDC; or (2) if k5ping or a similar program were integrated into MIT Kerberos to aid in monitoring as this is a need that all enterprise deployments of Kerberos need. -- Roland Dowdeswell http://Imrryr.ORG/~elric/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Functional test of KDC for monitoring?
How are folks performing functional testing of KDCs (without PKINIT)? We have a very primitive Nagios/Icinga plugin (loosely based on [1]) which invokes `kinit' with a keytab. This verifies that the round-trip principal-KDC-OpenLDAP is possible. -JP [1] http://exchange.nagios.org/directory/Plugins/Security/check_kdc/details Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Functional test of KDC for monitoring?
How are folks performing functional testing of KDCs (without PKINIT)? Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Functional test of KDC for monitoring?
Jeff Blaine jbla...@kickflop.net writes: How are folks performing functional testing of KDCs (without PKINIT)? Attached -- old and not horribly well-designed, but it works for us. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
