For many, many, years, DICE desktops and servers have submitted a daily report to the Informatics inventory system. This report, known as ‘clientreport’, includes details such as the model type, the running kernel, the amount of physical memory, the time of the last successful updaterpms run and the details of any attached monitor.
In the current inventory system, clients submit their report directly to the database using an SQL UPDATE, secured by a ‘secret’ shared password. This is not exactly considered “best practice” and it was decided that, for the new Inventory system, we should update the ‘clientreport’ script to use 21st century technologies!
The proposed system is to serialise the report data using JSON and submit the JSON using an HTTPS POST to a CGI script running on the Inventory system. The POST will be made over a kerberos authenticated connection, using the client’s host principal. The CGI script can then deserialise the JSON and update the database as necessary.
You might expect such an architecture to be in common use in DICE, but surprisingly this turns out not to be the case. Certainly I failed to find any example of a Perl implementation. Fortunately Stephen had some proof-of-code snippets to start from, and a prototype was (reasonably) soon produced.
On the client side this uses Authen::Krb5 to effectively ‘kinit’ using the client’s host principal. LWP::UserAgent is then used to make the HTTPS POST, with LWP::Authen::Negotiate providing the GSSAPI connection.
On the server side is a standard lcfg-apacheconf managed web server, using mod_auth_kerb for authentication. (Obviously, a service keytab needs to be created using the lcfg-kerberos component – and this keytab needs to be owned by the apache user).
A couple of problems were encountered. Firstly, the documentation for LWP::Authen::Negotiate fails to mention that it expects the kerberos service name to be ‘HTTP@hostname’. On consideration, it’s obvious that it must make such an assumption, but it would have been nice for the documentation to state it. Secondly the documentation for mod_auth_kerb states incorrect default values for some resources. The following resources were found to work.
AuthType Kerberos KrbServiceName HTTP Krb5KeyTab /etc/httpd.keytab KrbMethodK5Passwd On KrbVerifyKDC On require valid-user