Disclaimer: This is not an official guide and in no way represents best practices for FreeIPA. It is ugly and involves the digital equivalent of bashing on screws with a hammer. Having said that, when nobody has invented the right screwdriver yet, sometimes you just have to hammer away.

First, some history. We’ve been running separate DHCP, DNS and LDAP servers since we switched from static IP addresses and a Windows NT domain somewhere around ten years ago. The DHCP server was loosely connected with the DNS server, and I had written this beautifully complex (read: messily unreadable) script that would allow you to quickly add a system to both DHCP and DNS. A few months ago, we migrated all of our users over to FreeIPA, and I started the process of migrating our DNS database over. Unfortunately, this meant that our DHCP fixed addresses were being configured separately from our DNS entries.

Last week I investigated what it would take to integrate our DHCP leases into FreeIPA. First I checked on the web to see if something like this had already been written, but the closest thing I could find was a link to a design page for a feature that’s due to appear in FreeIPA 4.x.

So here’s my (admittedly hacky) contribution:

1. sync_dhcp – A bash script (put in /srv, chmod +x)that constantly checks whether the DNS zone’s serial number has changed, and, if it has, runs…
2. generate_dhcp.py – A python script (put in /srv, chmod +x) that regenerates a list of fixed-addresses in /etc/dhcp/hosts.conf
3. dhcpd.conf – A sample dhcpd.conf (put in /etc/dhcp) that uses the list generated by generate_dhcp.py
4. sync-dhcp.service – A systemd service (put in /etc/systemd/system) to run sync_dhcp on bootup
5. make_dns – A script (chmod +x) that allows the sysadmin to easily add new dns entries with a mac address

sync_dhcp does need to know your domain so it knows which DNS zone serial to check, but other than that, the first four files should work with little or no modification. You will need to create a dnsserver user in FreeIPA, give the user read access to DNS entries, and put its password in /etc/dhcp/dnspasswd (readable only by root).

make_dns makes a number of assumptions that are true of our network, but may not be true of yours. It first assumes that you’re using a 10.10.0.0/16 network (yes, I know that’s not right; it’s long story) and that 10.10.9.x and 10.10.10.x IPs are for unrecognized systems. It also requires that you’ve installed freeipa-admintools and run kinit for a user with permissions to change DNS entries, as it’s just basically a fancy wrapper around the IPA cli tools.

Bent Screw Hole Backyard Metal Macros by Steven Depolo used under a CC BY 2.0 license

On Thursday, my family and I departed beautiful Lebanon and started the long trek (at least as far as sitting in an airplane can be considered trekking) back home to Washington State. We were greeted with some rain when we arrived, which was definitely proof that we were home.

We’ll be here until the beginning of September, and then it’s back to sunny Beirut. I’m looking forward to the kids getting to celebrate the 4th of July for the first time.

I’m also hoping to get some time to look into making applydeltarpm more efficient. If you’ve been following the conversation on the fedora-devel list, you’ll have noticed that, oddly enough, some people don’t like deltarpms, and the reasons given are definitely valid.

At the moment, recreating an rpm from a deltarpm includes recompressing it so that signatures match, and that recompression is *very* expensive in terms of CPU time. If you’re on a slow computer with decent storage, it might make more sense to rebuild uncompressed rpms, but if we did this, then signatures would no longer match. I’d like to see if there’s some way that we can reasonably store the signature of the uncompressed payload as well as the compressed payload in the rpm. Ideally, this will be done in such a way so as to require minimal (if any) changes to the buildsystem.

If I can manage a proof-of-concept that works without too much trouble for the infrastructure guys, then we might just be able to pull off much faster deltarpm rebuilds.