Site Local Gconf Customizations

I’ve been customizing the Gnome Gconf defaults for my local site for quite some time now. The Gnome manuals are quite clear about how to use gconf.xml.mandatory and gconf.xml.defaults to alter the default Gnome settings. For example, I like the weather applet included in RHEL 6′s default desktop but I’d much rather it show the weather for Raleigh, NC rather than Boston, MA. My user base also really appreciates having a terminal launcher on the Gnome panel in their default desktop.

Until our RHEL 6.0 upgrade to 6.1 completely reverted a lot of my customizations.  Sure enough, the gnome-panel package now somehow believes that it can use a %post script to nuke the panel settings in gconf.xml.defaults and replace them with its pristine versions. Its a lot cooler in Boston than it is here in Raleigh.

I filed a bug in Red Hat’s Bugzilla to be told that I should put my site local customizations in the gconf.xml.system tree. That was the first I’d heard of this new Gconf configuration source. Its not in the Gnome manuals which indicate that you should add site local stuff to the gconf.xml.defaults tree. This appears to be a Fedora or Red Hat -ism.

If Red Hat can make new random Gconf configuration sources then so can I. Also, they wont be wiped out by some package upgrade. Here’s how its done.

First I added the following files to my configuration management tool, Bcfg2

  • /etc/gconf/2/path
  • /etc/gconf/2/local-defaults.path

I didn’t modify the contents of the path file but I stored the versions I had for RHEL 5 and RHEL 6. That file references the /etc/gconf/2/local-defaults.path file which is what I was interested in.

In /etc/gconf/2/local-defaults.path I added a new and unique location of my site local configuration source. (Making sure to do so after any reference to includes from the user’s home directory as is present in RHEL 5.) Gconf parses these files from top to bottom. I want to customize the local defaults not prevent the users from changing them.

xml:readonly:/etc/gconf/gconf.xml.ncsu

Next I made sure that directory was created by enforcing its existence with Bcfg2. (If that directory doesn’t exist the following step will create it, but the access permissions will be incorrect rendering it unreadable by users.)

Now I run an Action with Bcfg2 that loads my local customizations into the new Gconf source. Here’s the scriptlet I’m using. (Which references all the XML files I manage that contain Gconf bits.)

for f in `ls /usr/share/realmconfig/data/*.xml`  ; do
/usr/bin/gconftool-2 --direct \
   --config-source xml:readwrite:/etc/gconf/gconf.xml.ncsu \
   --load $f
done

Now I have my own Gconf configuration source that I can completely manage with Bcfg2.

Teaching Bcfg2

I’ve been putting together a class series for my fellow system administrators at my place of employment.  I need to teach them how to deploy our RHEL 6 and Bcfg2 platform.  The presentations are under the GNU Free Documentation License and if others might find them useful here they are:

Managing Local User Accounts with Bcfg2

Although I have LDAP managed users and Kerberos authentication, occasionally I need to make local system accounts on my servers.  With the deployment of Bcfg2 on RHEL 6 surely I could do this.  Well, not without some searching.

I came across this:

That turned out to be a fantastic way to examine the local accounts and create them if needed.  You’ll need a “passwd” Probe that’s not mentioned on the pastebin that does nothing more than “cat /etc/passwd”.

Looking closer, you’ll notice that its not using Red Hat style tools.  Fortunately, it was easy to port.  My version is here:

Mostly, I’ve corrected paths and some command options.  I’m also using “–non-unique” which seems strange.  However, I have over 100,000 accounts in LDAP and the LDAP servers limit queries to 500 responses.  I don’t want useradd to attempt to iterate through all the LDAP accounts.

Creating SHA512 Password Hashes

Need to generate password hashes?  Perhaps to distribute the hash of the root password to all your machines?  Easy, just whip out openssl.  Until you realize that there is no support for SHA2 password hashes.

I hate re-inventing the wheel, but my searching did not turn up a good way to generate SHA512 password hashes reasonably.  So I wrote a bit of Python to do it.  It will output crypt(), MD5, and SHA512 hashes for a given password.

http://linuxczar.net/code/hashpw.py

This takes advantage of GNU libc extensions, so it may not be uber portable.  Also, I had to write my own salt generation method.  It provides 8 character random salts but could be better.

All semi-modern Linux distributions support SHA512 password hashes now.  Red Hat has backported the support to RHEL 4.7 and RHEL 5.3.  So any reasonably updated RHEL/CentOS machine will work.

OpenAFS 1.4.14

A couple CVEs about OpenAFS came across my radar today.

  • CVE-2011-0430
  • CVE-2011-0431

Both site OpenAFS 1.4.14 as affected.  However, the OpenAFS community has confirmed that the security issues were fixed in 1.4.14.  Expect an official announcement from the OpenAFS folks soon to confirm this.

RRDTool Backups

I use RRDTool quite a bit in some of my code.  Not to mention its heavy use in other open source projects.  But backing up my RRD files was a pain.  I can’t keep them in our network filesystem (OpenAFS) that has regular backups because the database files become corrupt.  I can’t move the files from one machine to another because they are very platform/architecture specific. Further, I’ve got a whole directory tree full of RRD files.

I wanted a tool that would scan a directory tree full of RRDs, create a mirror image of that tree elsewhere, and dump out the RRD files to XML.  So, each rlmtools/global/foo.rra file gets dumped out to /tmp/test/rlmtools/global/foo.xml.

So, I wrote it

The first argument is the directory tree to copy, the next argument is where to root the newly created tree.  A -b or -r argument is required for backup or restore mode, respectively.

In a similar vein I wrote a bash script that wraps the above for use with cron.  The srcipt runs the above script, tars and compresses the output, and places the file (with a date in the file name) at a specifc directory.  That directory is then pruned so that all backups are no older than about 2 weeks.

Programming Kerberos 5

The Kerberos 5 protocol is a beautiful thing, and not too horribly difficult to figure out.  However, using the Kerberos 5 APIs in your code is another matter.  Documentation is sparse and figuring out what logical steps need to happen with the API to get to your end goal isn’t very clear.  At least, its always frustrated me.

The below is an example C program that asks for a username and password and authenticates them against your KDC.  You’ll need a correctly configured /etc/krb5.conf, of course.  The logical steps here are 1) setup your kerberos context, 2) parse the username into a principal, and 3) obtain the initial TGT for that principal.

Comments?  Would you like to help improve the example?