Managing cron.d with chef

I have recently been playing with the chef configuration management system. I was looking for a way to manage files in a directory such that any that were created by chef would be cleaned up again when they were no longer needed. A classic use case is the /etc/cron.d directory which may be populated by files from multiple sources. There appeared to be no established pattern for this but since chef allows the use of ruby in its recipes, I was able to construct the following. It assumes the use of the cron cookbook.

[code language=”ruby”]
cron_d ‘usercron.chef’ do
minute 0
hour 23
command ‘/bin/true’
user ‘myuser’
end

Dir.glob("/etc/cron.d/*.chef") do |f|
name = f.split(‘/’)[-1]
begin
t = resources("cron_d[#{name}]")
rescue Chef::Exceptions::ResourceNotFound
cron_d name do
action :delete
end
end
end
[/code]

OS X Terminal.app, bash and UK Keyboards

On an Apple UK keyboard, the # symbol is accessed by pressing ⌥-3 (pronounced option 3). Unfortunately the terminal application is only useable when option has been mapped to the UNIX meta-key, which takes precedence over “special” characters such as #. Thanks to this tumblr post, it is possible to work around this problem:

$ cat .inputrc
"\e3": "#"

Unfortunately .inputrc is a bash-specific configuration file and this does not solve the problem for terminal-based applications.

Postfix and SMTP AUTH on OS X Lion

The standard instructions for configuring postfix to use authenticated SMTP to use authentication when forwarding to a relay host did not work for me on OS X Lion. For future searchers here is how I made it work.

  1. Create the file /etc/postfix/sasl_passwd as described in the standard docs, i.e. at least one line containing:
    server username:password
    and set the permissions using sudo chmod 600 /etc/postfix/sasl_passwd.
  2. Make the db version used by postfix: sudo postmap /etc/postfix/sasl_passwd (the new file will inherit the permissions of the original file).
  3. If you have upgraded from a previous version of OS X, particularly if you modified your postfix configs, follow the advice in the section below before continuing.
  4. To tell postfix to use authenticated SMTP, add the following lines to /etc/postfix/main.cf:

    mydomain = <<your.mail.domain>>
    mydomain_fallback = localhost
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

    If your domain’s MX records do not specify your relayhost then you must also set the relayhost line.
  5. postfix on OS X runs “on demand” so there is no need to instruct it to reload its configuration. The log file is in the standard UNIX location, /var/log/mail.log.

Upgrading from Snow Leopard

I had previously had this postfix setup working under Snow Leopard, and the upgrade process appeared to have preserved my configuration settings so I was surprised to see that after upgrading to Lion, my smarthost was not accepting mail.

Examining the files in /etc/postfix I noticed that in addition to my customised main.cf there was also a file called main.cf.default which was modified the date I had upgraded to Lion. Comparing the two files showed a number of subtle differences but after being unable to determine why postfix was not authenticating to my upstream server, I decided to copy it over my customised main.cf and re-apply my changes.

Having done this, the mailq command gave me the following error:
postfix[17922]: fatal: bad string length 0 < 1: setgid_group =
Setting setgid_group = _postdrop in main.cf fixed that but then I hit another error:
fatal: file /etc/postfix/main.cf: parameter mail_owner: user postfix has same user ID as _postfix
Resolving this required me to change the value of mail_owner from postfix to _postfix but I don’t know if this is a bug in Apple’s supplied main.cf or an artefact of my user and group information evolving from a 10.6 install to 10.7.

A Personal History of UNIX Tool Management on OS X

When I first switched to Mac from Linux I used fink to provide the simple software installation (and removal!) to which I had become addicted while using Debian. In addition to being command line compatible, fink also shipped the software as binaries which on the relatively slow CPUs of the day meant the software was able to be used much more immediately than if it had to be compiled.

About three years ago, I noticed that the fink binary distribution no longer had all the packages I wanted to use. The website would indicate the package was available but actually it would be only available in source code form and my aging laptop did not have the CPU or disk space available to compile not just the package but all its dependencies. When I upgraded that old laptop, and compiling everything from source seemed feasible, I decided that the MacPorts project had more community activity and jumped ship.

MacPorts worked very well. The initial install took time, and worked the fan of my MacBook quite hard, but once the base packages were compiled, subsequent software installs and updates were mostly painless. MacPorts also made it vary easy to tweak installs using its variants mechanism. However MacPorts’ downfall, in my opinion, is that it is not content to be just a way of augmenting the existing UNIX tools on my Mac but that it wants to be a self-contained operating system itself. For example, in order to install the git-svn tool MacPorts was going to download, compile and install not only an older version of Perl than is shipped with 10.6 but also a second version of the subversion tool that Apple have already provided. I am sure this is a good way to deliver a powerful and stable system, but it felt like MacPorts was taking over.

I am not the first to think this since someone has developed homebrew. It has the explicit goals of playing nicely with the OS defaults and programming language specific distribution systems such as RubyGems, CPAN and PyPi. I am pleased to be report that homebrew was very quick to setup and install the few remaining UNIX packages to which I remain addicted. The installer makes the assertion that every user on your system should be in the staff group,1 but the script was very simple to modify and I have submitted my version back to the maintainer.

The one package where I do not find homebrew satisfactory is LaTeX. homebrew uses the TeX Live distribution rather than the tetex package I have used in the past. However TeX Live is a humungous 1GB download and some quick research showed that it was very much a kitchen sink package with many sub-packages that were completely unnecessary for me. Instead I highly recommend the 85MB download (234MB installed) BasicTeX package which has proved to be entirely adequate for my needs, even if it does have softie GUI installer!

  1. I noticed that on a fresh install of 10.6 no one is a member of the staff group. It appears that all Administrator users are members of the admin group though, and since it seems to only allow admins to change the machine’s homebrew install, I forked this gist and replaced all the instances of staff with admin. [back]