In order to backup our Mac OS X server to our central backup host and tape library, we installed amanda via pkgsrc. Since pkgsrc needs a case-sensitive filesystem, it lives and installs into a separate volume from the root volume. That is, we have / and /Volumes/pkgsrc, with the amanda daemon installed in /Volumes/pkgsrc/pkg/libexec/amandad. The backup server is set to use tar(1) on this host, since apparently ump(8) does not actually work on OS X (resource forks?). (Note that tar(1) only supports resource forks on OS X since Tiger.) So far, so good.

Now we need to get the amanda daemon to start at boot time automatically. On all other hosts, this is done via inetd:

192.168.0.8:amanda          dgram   udp     wait    backup  /Volumes/pkgsrc/pkg/libexec/amandad amandad

This can easily be converted into an xinetd(8) file:

service amanda {
	socket_type	= dgram
	protocol	= udp
	wait		= yes
	user		= backup
	group		= operator
	groups		= yes
	server		= /Volumes/pkgsrc/pkg/libexec/amandad
	bind		= 192.168.0.8
	only_from	= 192.168.0.1
}

So far, so good. Starting this manually by kill -HUPing xinetd works fine. However, after rebooting the machine, it no longer works. If I log in and restart xinetd manually, it works. Alright, so I think I'll go the way that Apple really wants me to anyway, and convert this to launchd(8). I create the following /System/Library/LaunchDaemons/amanda.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>org.amanda.amanda</string>
	<key>OnDemand</key>
	<true/>
	<key>ProgramArguments</key>
	<array>
		<string>/Volumes/pkgsrc/pkg/libexec/amandad</string>
	</array>
	<key>ServiceDescription</key>
	<string>Amanda Backup Daemon</string>
	<key>Sockets</key>
	<dict>
		<key>Listeners</key>
		<dict>
			<key>SockNodeName</key>
			<string>192.168.0.8</string>
			<key>SockServiceName</key>
			<string>amanda</string>
			<key>SockType</key>
			<string>dgram</string>
		</dict>
	</dict>
	<key>UserName</key>
	<string>backup</string>
	<key>GroupName</key>
	<string>operator</string>
	<key>InitGroups</key>
	<true/>
	<key>inetdCompatibility</key>
	<dict>
		<key>Wait</key>
		<true/>
	</dict>
	<key>StandardOutPath</key>
	<string>/var/amanda/logs/amandad.stdout.log</string>
	<key>StandardErrorPath</key>
	<string>/var/amanda/logs/amandad.stderr.log</string>
</dict>
</plist>

I launchctl load /Library/LaunchDaemons/amanda.plist. I see it's listed via launchctl list. I see it's listening via netstat(1). I think I'm golden.

I reboot, and launchd did not start amanda. launchctl list does show it, though. If I launchctl unload it and then launchctl load it again, everything's working.

So after toying around with this for a while, I realize that the problem is that executable (/Volumes/pkgsrc/pkg/libexec/amandad) is located on a different volume than the root volume. And apparently there is no way to tell launchd(8) to mount certain filesystems first the way one might do it using critical_filesystems_local under NetBSD.

So... to get around this, I created a short script called startamanda:

#!/bin/sh
/bin/launchctl unload /System/Library/LaunchDaemons/amanda.plist
/bin/launchctl load /System/Library/LaunchDaemons/amanda.plist

and add the following entry to root's crontab:

@reboot /var/root/bin/startamanda

This actually seems to work, even though it ain't pretty.

If Garritan Personal Orchestra is installed on workstations using NFS home directories, it may require different license keys. These are generally stored on each workstation in '/Library/Preferences/GARRITAN PERSONAL ORCHESTRA.plist'). Starting Garritan works just fine for any regular user, but Garritan then creates the file '~/Library/Preferences/GARRITAN PERSONAL ORCHESTRA.plist' in which it copies the licensing information (including the hardware key) for the version installed on that machine.

This has the side effect that if the user logs out and logs in on another machine and starts Garritan there, it will claim that it is not licensed (since it finds another machines key in the preferences file).

Removing the file '~/Library/Preferences/GARRITAN PERSONAL ORCHESTRA.plist' then allows you to start Garritan on that machine as well.

Native Instruments (which handles the licensing for Garritan) confirmed this problem, and admits there is at the moment no bugfix available.

Solution/Workaround:
Add a ``LoginHook'' to the LoginWindows preferences that removes the file for each user upon login:

/Library/Management/login.sh:

#!/bin/sh

if [ x"$1" = x ]; then
        return 1
fi

sudo su - $1 -c 'rm ~/Library/Preferences/GARRITAN\ PERSONAL\ ORCHESTRA.plist'

Lines added to /Library/Preferences/com.apple.loginwindow.plist:

        <key>LoginHook</key>
        <string>/Library/Management/login.sh</string>

See also http://www.bombich.com/mactips/loginhooks.html.

Problem:
A number of cluster nodes ('node's) are connected to an extreme networks switch ('Summit'), netbooting off a fileserver ('doppelbock') connected to the same switch. So far so good. I now have added a number of new nodes ('NNode's), but since the Summit switch is full, I connected the Summit switch to a Cisco Catalyst 4506 ('cat4506'), to which the NNodes are connected. cat4506 has three vlans.

This looks like so:

[ node ]+                                           +[ NNode ]
[ node ]+                                           +[ NNode ]
[ node ]+----- [ Summit ] ------- [ cat4506 ] ------+[ NNode ]
[ node ]+          |                                +[ NNode ]
[ node ]+          |                                +[ NNode ]
             [ doppelbock ]

Summit has all nodes on one vlan, cat4506 has all NNodes on one vlan, and the connection between the two switches is on the same vlan, as is the connection to doppelbock.

The nodes can netboot off doppelbock just fine, but the NNodes can't. They pxeboot and get the right IP address from doppelbock, they tftp the kernel and all's well, but when the kernel tries to DHCP, it times out. If the NNodes are connected directly to the Summit, they netboot fine.

Solution:
no spanning-tree vlan vlanid
The NNodes flutter the link signal, and the cat4506 switch will sit there not forwarding packets until it's sure you don't have a switch connected. Turning off spanning-tree on the vlan in question solves the problem.

1 pound of boneless pork chop center cut
1 red pepper
1 green pepper
1 tomato
1 onion
1 garlic clove
Chow Mein noodles

Cut pork in strips, peppers in thin long strips. Coarsely chop onion and tomato. Mix a little bit of sesame oil, fish sauce and rice vinegar together and marinate pork in it. Season with pepper and salt.

Bring water to a boil and add chow mein noodles.

Slice garlic and sautee in canola oil. Add pork. Add pepper strips and onion, then tomato. Add drained chow mein noodles and remaining sauce mix.

After adding https to the mailman webserver, and after redirecting all requests from plain http to https, the mailman web frontend seemed to work just fine. That is, until one tries to use the admin interface to make any changes. All submitted changes would simply not take effect, even though no errors are given. To fix this, add the following lines to your mm_config.py:

DEFAULT_URL_PATTERN = 'https://%s/mailman/'
PUBLIC_ARCHIVE_URL = 'https://%(hostname)s/pipermail/%(listname)s'

Remember to run withlist -l -a -r fix_url afterwards, or else the change won't take effect.