Bind 9.9 – Binary DNS Slave file format

With BIND 9.9.x, the slave zone files are now saved in a default raw binary format.  This was done to improve performance, but at the sacrifice of being able to easily view the contents of the files.

With the combination of caching software solutions (sssd, nscd, cached zone files, ttl’s, etc), it can make debugging more difficult.  In order to view the raw binary content, it must be converted to text first:

named-compilezone -f raw -F text -o

It’s an added layer of complexity, but if you need the microscopic performance boost, that’s the way to go. For those of us that don’t see any issues with the text file format, simply update the named.conf files for your slave zones to include the line:

masterfile-format text;

For example:

        zone "" in {
                type slave;
                notify no;
                file "data/";
                masterfile-format text;
                masters {; };

sudo + sssd + ldap

In my quest to implement sssd, my focus turned towards sudo.  Centralizing the sudo rules to an LDAP server (or cluster) simplifies management of users and access.  Rather than /etc/sudoers files on each machine, sudo can look in to LDAP for a specific user’s rules.

The path of a query is:
sudo command requested -> network service switch -> sssd -> sssd_sudo -> ldap

OpenLDAP does not have the schema installed by default, and many have converted to the slapd.d configuration file format which leaves a lot to be desired. You have to take the sudoers.schema file and convert it to slapd.d format (I’ve converted it, so if you just want to use this file, feel free), which comes out like this (name your file accordingly) /etc/openldap/slapd.d/cn=config/cn=schema/cn={6}sudoers.ldif.

Of course, with any schema change you need to restart ldap:

systemctl restart slapd

Next, the local /etc/sudoers file needs to be converted and then imported.  There’s a helpful utility that comes with the sudo rpm called sudoers2ldif.  It does a good job at getting your started, and you must keep in mind that the resulting ldif file will need manual adjusting before importing:

sudo SUDOERS_BASE=ou=SUDOers,dc=company,dc=com perl
/usr/share/doc/sudo*/sudoers2ldif /etc/sudoers > /tmp/sudoers.ldif

Again, be sure to look the file over and remove any unusual entries.  Also, add the SUDOers ou definition to the top of the file:

dn: ou=SUDOers,dc=company,dc=com
description: SUDOers
objectclass: organizationalUnit
objectclass: top
ou: SUDOers

With the file cleaned up and the ou defined, import the ldif file.  With it imported, the data is there, but nothing is using it.

Update /etc/sssd/sssd.conf to include “sudo” in the services line for the [sssd] stanza, and at the end of the file create a blank [sudo] stanza.  Restart sssd.

systemctl restart sssd

Update nsswitch.conf to include the line:

sudoers: files sss

Remove all sudo entries from /etc/sudoers for users with a UID >= 1000. Those are now handled via LDAP ,and all of the other entries (for users with a UID < 1000) will be managed by the local /etc/sudoers file.  This is a limitation hardcoded in sssd that cannot be overridden.

sssd and tmpfs

After my previous efforts to migrate to sssd, it was discovered after a reboot that sssd and a tmpfs /var/log did not play well together.  sssd has a couple of minor faults:

  • If the default /var/log/sssd directory does not exist, sssd will not start
  • It does not create the default /var/log/sssd directory if one does not exist first.
  • You cannot change the default log directory location (without recompiling the binary, and those of us with packaged based distributions don’t want to be doing that custom step if not necessary)

Searching the web, there are a number of discussions surrounding this very issue, with the majority of them dying off with responses like “Why would you want to run tmpfs for /var/log?” “What would be the benefit?” “Seems like this isn’t a good idea”, and other useless responses.  I say useless because those types of responses are far from helpful, distract from the original question/problem, and don’t address the problem at hand that the individual is asking about.

Systemd installations (such as RHEL7 and the current Fedora tree) use the file /usr/lib/systemd/system/sssd.service as part of the sssd rpm.  Sure, you can try modifying that file, but “Type = forking” only allows for a single command in “ExecStart”.  You can go down the path of tinkering with it, writing another systemd script to create the directory structure for you, but, as I found out, that would be re-inventing the wheel.

Thankfully, I found one reference elsewhere to tmpfiles.d which is part of the systemd.  It plugs the gap where programs don’t or can’t build the directory structure you require.  Simply create the file /etc/tmpfiles.d/sssd.conf with the following contents:

# sssd needs a directory in /var/log/sssd to store its log files
d /var/log/sssd 0755 root root

The tmpfiles process is kicked off at the systemd “sysinit” level, which happens after the filesystems are mounted but before services are started.  So, you are all set.

You might ask: Why run /var/log on tmpfs?

I happen to run a number of mythtv frontend systems that are not much more than dummy clients, all of which have ssd internal drives (to limit the power usage at the TV).  I’ve done some basic optimizations to preserve the life of the SSD while still retaining debugging functionality (it is mythtv after all, which requires a lot of TLC).  Having /var/log contents can be very helpful in a pinch when logging on to the box, but I understand that both the logs and the machines are relatively disposable and I’m ok with losing the logs after a reboot.