Since this was a fairly important repo to convert, I did a few trial runs first and ended up scripting it since there isn’t just a single command to do what I needed. Essentially, we are doing a git clone from a subversion repository (a standard one with trunk/, tags/, branches/ this time), but excluding one directory (we’ll call it private). I also wanted to convert the svn branches to tags since that’s effectively what they were. Also, since the git repository was not local, and for the sake of expediency I didn’t want to tar something up and email it, we’re taking our converted-and-cleaned-up new git repo, changing the upstream, and then pushing the whole thing to a remote bare repository.

Ready? (Note: a few lines are manually wrapped with ‘\’ below)


#!/bin/sh
WORKDIR="/srv/svn2git/git"
REMOTE="git+ssh://remote.git.host/myrepo.git"
mkdir -p ${WORKDIR}

cd ..
git clone bare.git myrepo
cd myrepo
git remote rm origin
git remote add origin ${REMOTE}
git config remote.origin.push 'refs/remotes/*:refs/heads/*'
git config master.remote origin
git config master.merge refs/head/master
git push --set-upstream origin master


And that is all there was too it. The svn authors file was created ny using:


$ svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); \
print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt


in the existing copy of the subversion repository that I had (and then mangling it to suit my needs, particularly changing it to add the committers’ real names and email addresses as well).

Does anyone know of a similar service? I’ve gotten so used to using Google Reader (not the web interface, but the actual syncing and being able to connect to the account with all my various RSS readers whether I’m on my phone or the desktop or the laptop and be able to just pick up where I left off).

I get that Google needs to sunset things that don’t make sense, but it would be nice if they could maybe let the code go so others can setup their own implementations that’s basically compatible with all the Google Reader-friendly RSS readers out there.

Or they could just get rid of Orkut…

This is was re-lining and darkening of my existing cross, and I think the flames look pretty darn sweet.

This is re-lining and darkening of my tribal Jesus, and fixing the J (the ticks it used to have were too thick, making it look odd):

And as I looked at my Flickr album, I realized I never took any pics of the work done last year. =( Since I can’t take those pics on my own, I’ll have to get Ang to take some tonight.

The next step will be finishing filling in the forearm, and then need to get the concept for the top done, which will include re-working the flaming skull I got 19 years ago. Looking forward to getting the sleeve finished this year!

So normally I do my updates from one version of Fedora to the next using yum, in particular the Upgrading Fedora using yum guide. Usually it works pretty good. I didn’t really have much good experience with PreUpgrade the few times I tried it, so I wanted to give FedUp a try.

In my Parallels Fedora 17 VM it worked amazingly well. So decided to try it on my laptop, which is also running Fedora 17. I think it makes sense to do a little bit of house-keeping before running it though, and the FedUp page doesn’t mention any of this (perhaps it’s no longer needed?). Anyways, a few steps:

* yum install rpmconf; rpmconf -a (review any .rpmnew/.rpmsave files, merge changes as required)
* find /etc /var -name '*?.rpm?*' (find any other old .rpmnew/.rpmsave files)
* yum install yum-utils; package-cleanup --leaves (review and remove any unused packages, not all will be removable)
* package-cleanup --orphans (find and remove any orphan packages no longer in the repositories)

Now you can run FedUp:

* yum install fedup
* fedup-cli --network 18 --debuglog /root/fedupdebug.log

If this completes without error (check the log), you can reboot. At grub you’ll see a “System Upgrade” entry. When that’s done, it’ll reboot into Fedora 18.

The wiki page talks about upgrading GRUB2 since you’ll be booting from Fedora 17′s GRUB2. If you’ve got a BIOS-based system, you can use the Updating GRUB2 configuration on BIOS systems instructions. For those using UEFI, instructions are on the same page.

You may also want to run package-cleanup --orphans after you do the upgrade as well, just to get rid of any other leftovers. The only issue I discovered so far with the upgrade is that Google Chrome didn’t work out-of-the-box. However, doing a yum remove google-chrome-stable; yum install google-chrome got that sorted out (although it did install the unstable version; the stable version had issues with missing libraries and wouldn’t load).

All in all, upgrading from Fedora 17 to 18 went a heck of a lot smoother than a fresh install did. I also got to see what the new GDM/GNOME looks like (quite nice, actually, although I think I’ll give MATE a try on the laptop as well because, while GNOME3 is pretty, I definitely preferred GNOME2).

Good job, Fedora-folks! Now I just have to upgrade my main workstation, but I think I’m going to play on the laptop for a bit before taking that step. Just in case I find any other gotchya’s.

A few times.

First I have to say that I’m not a big fan of the new Anaconda UI. One of the things I appreciated about Anaconda in the past is that it was easy to use, but didn’t prevent me from doing “power things”, like partitioning disks the way I wanted to partition them. This seems to no longer be the case, and Anaconda does a lot of hand-holding. It has been a habit to go through the list of packages to be installed (select a group, then go through and weed out the stuff I don’t want), so things I don’t want don’t even touch the disk. Doesn’t seem like I can do this anymore either. I don’t agree with some reviewers who seem to think the UI change is to make it look/feel more mobile or “touchscreen-like”, but I do feel it’s dumbed down quite a bit which makes me unhappy. I lived with it, until trying to change the partition layout killed Anaconda. Twice. After that I decided to let it do what it wanted since it was just a VM and I didn’t care enough to fight it.

So Fedora gets installed and lo! A nice blue screen where I can do absolutely nothing. No icons, no text, no login box, nothing. Afterwards I read this has to do with having 3D graphics enabled in VMware (but at that point I had already reinstalled to use LXDE rather than GNOME, so I’ve not tried anything regarding that, however I did find this blog posting about Fedora 18 in VMware Fusion 5/VMware Workstation 9 which explains things a bit).

On my home network I run IPA on Red Hat Enterprise Linux 6 to handle my Kerberos/LDAP auth duties. This means when I install an operating system, no matter what it is, I don’t create local users. So when I installed Fedora 18, I only have the root user and the rest come from IPA. A few problems with that:

• Setting up IPA in Anaconda does not work
• Post-install, logging in as root at the GUI is not permitted
• I have a grub error on tty2, not a login (and nothing on tty3 for that matter)
• I have to reboot and edit grub to add systemd.unit=multi-user.target to boot into the console to get a tty (see Systemd: Boot Kernel Command Line)
• After I install freeipa-client, I can enroll in the domain
• SSSD is not enabled when you install it! Once again I have to reboot to the console
• Enable SSSD and reboot, only to find that once again I cannot login as a user in the GUI (that I could login as on the console)
• Head-scratching moment when I realize I know next to nothing about systemd and can only conclude that perhaps NetworkManager starts upon login in the graphical boot and not at system start, which prevents SSSD from talking to IPA to confirm my login
• Looking at /etc/sysconfig/network-scripts/ifup-eth0 tells me that perhaps that is not the case
• Big WTF moment and go to bed

Currently I am unhappy with Fedora 18. I suppose that on bare metal it probably works better. I also suppose that with a real user account it works better. At this point I don’t want to do yet another reinstall because then I have to remove the host from IPA and re-enroll, which is annoying (and I really don’t want to revisit Anaconda either — I’ll get to do that when I create the 64bit Fedora 18 VM later).

Ok, after a few days I tried a few other things. The first was getting rid of NetworkManager thinking that perhaps it would only start when I login (which I can’t, if there is no network, because my login is IPA-based). So I had to do:

# systemctl disable NetworkManager.service
# systemctl enable network.service

The most annoying thing, however, is that when I boot into graphical mode, I get no gettys. I’m pretty sure I told systemd that I want three of them (I have three symlinks in /etc/systemd/system/getty.target.wants: getty@tty1.service through getty@tty3.service; sadly when I boot into graphical mode and switch to TTY2, I get a grub error message and nothing on TTY3… what the heck?)

Another thing I did was disable SELinux. In multi-user.target, I can login as my IPA-user no problem. With LXDM, however, I never could (assuming, perhaps incorrectly, that network initialization was delayed). But upon further inspection I see a lot of:

lxdm-binary: pam_selinux(lxdm:session): Setting key creation contect guest_u:guest_r:oddjob_mkhomedir_t:s0 failed: Permission denied

I have zero interest and zero time in making SELinux work with LXDM and since this is a virtual machine, I don’t care if SELinux is disabled.

Lo and behold, I can now log into LXDM. In light of the SELinux thing, I’m thinking that NetworkManager is not to blame (silly me, I made two changes then rebooted — it could be either one, but I strongly suspect SELinux). Maybe it would have worked better with GNOME (will try that on the next VM I install).

On another side note, since I use VMWare Fusion for the VM, for the tools install (probably the same for the latest VMware Workstation as well, etc.), you may want to check out this thread. In particular, seems like linux/version.h is missing and makes the tools angry. The fix is easy though:

# cd /usr/src/kernels/[current_version]/include
# cp generated/uapi/linux/version.h linux/

Then you can compile the tools. IIRC, you’ll also not want to use the i686 PAE kernel (doesn’t seem to work on older versions, I suspect the same may be true with F18). Easy enough to yum remove the PAE kernels and install the regular kernel. YMMV.

Finally, the next day I installed Fedora 18 64-bit in VMWare Fusion. With the lessons learned above, it was a lot less painful. I still am not a big fan of Anaconda… I like the look of it, but the practical “working” bits of it definitely need some work. I don’t like that you can pick only one group of packages. What if I want both GNOME desktop and a working web server? Doesn’t seem like it can be done. I also like picking through individual packages and sorely miss that — makes for having to install a bunch of stuff later. Also not sure why vim isn’t installed by default… I think this is the first time ever I’ve seen “vim: command not found”.

Also, despite getting the VMware tools installed, if you want GDM to present you with anything, you need to disable 3D graphics. I have it enabled on my 32-bit VM (which is using LXDM, works fine), but on the 64-bit VM (using GDM), even with vmware-tools compiled and running, I needed to disable 3D graphic acceleration. I suppose there is a bug in the driver and/or X there. Not a big deal to disable since I’ve done “yum groupinstall ‘MATE Desktop’” (what need do I have for 3D graphics? BTW, MATE is sweet!) and now GDM loads.

IPA still would not work to configure from Anaconda. Definitely a bug to be filed there.

Anyways, time to end this. This entry has been in the works for about two weeks (sadly, I’ve not had time to finish it or get my Fedora VM’s running until yesterday, and finished up the 64-bit install this morning). So far the install of Fedora 18, in VMware, has been a bit of a PITA. Next order of business is to see how the upgrade works… I’ve got a Fedora 17 install in Parallels to upgrade to make sure all my work-related bits work, before attempting to upgrade on bare metal. I’m quite certain that a lot of this can be attributed to the virtual machines and it’ll work better on bare metal. I’m also happy that those won’t be fresh installs, so I don’t have to deal with Anaconda.

Not to be redundant on the steps noted in the other blog post, but to be a bit more explicit, we’ll just go through the steps as I did notice a few errors (I’m assuming that blog post was written on some version of Ubuntu; I’m of course using a Red Hat Enterprise Linux 6 host).

The blog notes to run the qemu-img convert command on the non-wildcard vmdk file; however, I found that I needed to convert the multi-file image into a single disk image first, before it could be converted. This may be the case for VMware Workstation disk images as well, however keep in mind we’re using VMware Fusion 5 on OS X, so the tool we want is inside the VMware Fusion application bundle (specifically, we want the vmware-vdiskmanager program).

Before converting, however, I strongly recommend removing any existing snapshots of the virtual machine. The first time I did this, I got the original snapshot which had the guest running CentOS 5.6 (and I updated it to 5.9 this morning before starting this). So before converting anything, you probably need to remove any existing snapshots first. Then, on the mac, convert this multi-file image into a single image:

$ cd /Applications/VMware\ Fusion.app/Contents/Library
$ ./vmware-vdiskmanager -r ~/Documents/nagiosxi.vmwarevm/nagiosxi.vmdk \
    -t 0 ~/Desktop/nagiosxi.vmdk

This also gets rid of all of the extra VMware stuff like snapshots, etc. Copy this new vmdk file, as well as the vmx file in the container, to the Linux box.

Next, convert the new image file to QCOW2 format (the original blog post didn’t specify the output format; qemu-img defaults to a raw file which we don’t want, we want QCOW2).

#  qemu-img convert nagiosxi.vmdk -O qcow2 /srv/virt/images/nagiosxi.img
# ls /srv/virt/images/nagiosxi.img -l
-rw-r--r--. 1 root root 10737418240 Jan 27 08:33 /srv/virt/images/nagiosxi.img

Seems more reasonable. But we need to change permissions so that libvirt can read it:

# chown qemu:qemu /srv/virt/images/nagiosxi.img
# chmod 600 /srv/virt/images/nagiosxi.img

The next step is to use the vmware2libvirt script to convert the vmx file to an XML file for libvirt. Unfortunately, this only seems to ship with Ubuntu. Fortunately, we can grab the script from here. It’s just a python script with no dependencies, so run:

# python vmware2libvirt -f nagiosxi.vmwarevm/nagiosxi.vmx >~/nagiosxi.xml

Then we use virsh to import it. Unfortunately, in this step, virsh is looking for /usr/bin/kvm and the binary is actually installed as /usr/libexec/qemu-kvm, so we need to make a symlink first:

#  ln -s /usr/libexec/qemu-kvm /usr/bin/kvm
# virsh -c qemu:///system define ~/nagiosxi.xml

This will import the nagiosxi.xml file to /etc/libvirt/qemu/nagiosxi.xml.

The original blog post talked about using the virt-manager GUI to finalize things, and since I’m lazy and don’t know libvirt well enough to do all this on the commandline, we’ll do the same thing. Since that machine runs headless without a GUI, I need to ssh in as root with X forwarding and run virt-manager.

In the GUI, I can see my nagiosxi VM defined, so I select it and edit the virtual machine details. I need to remove the existing IDE Disk 1 (which points to the vmdk file) and add my converted image file. Essentially:

• “Add Hardware” -> “Storage” -> “Managed or other existing storage” -> Pick your new file
• Select “Storage Format” -> Pick qcow2
• Click “Finish”

You will also want to add a few more bits of hardware:

• Serial: Device type: pty
• Network: Host device: br0, Device model: virtio

In my case, there was no network device, and the serial console is useful for using commands like “virsh console” (but you have to setup the serial getty inside the VM for this to work).

Now you should be able to startup the new virtual machine. Once you have gotten it up and running, you’ll want to remove the vmware-tools that were installed.

I’ve been using Kerberos and LDAP at home for years, largely because I have to do a lot of testing of things in virtual machines, so when a new version of something comes out (new Fedora, new major version of RHEL, etc.), I spin up a new VM and install it. Using Kerberos and LDAP make the setup a breeze, and if I change my password, I’m not changing it on 20-odd systems/virtual machines.

I’m happy to say that FreeIPA exceeded my expectations, despite a bit of a rocky start (due to my not reading enough of the docs, annoyingly enough). I’ve now got it in place, it’s doing Kerberos+LDAP on the Linux clients and also on the Macs! I have, for the first time ever (not counting OS X server 10.4 or something, and using OpenDirectory), gotten to login to an OS X system with network credentials. I’ve also made use of the DogTag CA and had my internal mediawiki instance (which used mod_auth_kerb for SSO authentication) also use HTTPS now with mod_nss and my shiny new IPA CA.

There’s a bunch more about FreeIPA than what I’ve done so far. I’ve just scratched the surface (and even that, not entirely as I’ve still got a dozen or so systems/vms to switch from the old Kerberos+LDAP setup to using FreeIPA), but I’m looking forward to playing with the other things like a hopefully much easier kerberized NFSv4, storing sudo configs in the directory, auto-mounted home directories (don’t care too much about that for the workstations but that will be sweet for the virtual machines), and so on. FreeIPA has a really really nice package that takes care of all this stuff and I’m kinda kicking myself that I didn’t play with it sooner.

And, because of my really odd love for this sort of thing, I’ve written an article on my wiki: Using FreeIPA for User Authentication which goes into the whole setup and enrolment. A lot of it is covered in the upstream docs, but the upstream docs only got to OS X 10.4, so my 10.7/10.8 setup required a bit more futzing and research. While I’m “officially” calling this article done, as I spend time over the Christmas holidays playing around with it, I will no doubt be adding more info as I discover it.

Anyways, I decided to use git-notifier to send an email to bugzilla (while gitzilla uses XMLRPC, which would have been preferable, I also have incoming email support enabled in bugzilla). It took some trial and error, but I got it working (although I suspect there are easier ways to do it).

The first thing I had to do was patch git-notifier to accept a bug id, because bugzilla needs to know what bug to route the incoming email to. This was very easy to do (I’ll be sending this upstream to see if they want to include it, but I may also change it to pull more info from the git config so that the post-receive hook doesn’t have to be so obscene:

--- git-notifier.orig	2012-09-21 10:04:21.283442085 -0600
+++ git-notifier	2012-09-21 10:25:04.811307023 -0600
@@ -37,6 +37,7 @@
     ("link", True, None, "Link to insert into mail, %s will be replaced with revision"),
     ("updateonly", False, False, "update state file only, no mails"),
     ("users", True, None, "location of a user-to-email mapping file"),
+    ("bug_id", True, False, "bug ID (for sending email to bugzilla)"),
     ]
 
 class State:
@@ -250,6 +251,11 @@
 
     repo = Config.repouri
 
+    if Config.bug_id:
+        bzid = "@bug_id = %s\n\n" % Config.bug_id
+    else:
+        bzid = ""
+
     if not repo:
 
         if gitolite:
@@ -269,10 +275,10 @@
 X-Git-Repository: %s
 X-Mailer: %s %s
 
-%s
+%s%s
 
 """ % (Config.sender, Config.mailinglist, Config.emailprefix, subject, repo,
-       Name, Version, mailTag("Repository", repo)),
+       Name, Version, bzid, mailTag("Repository", repo)),
 
     return (out, fname)

This works, and works well, but the post-receive hook is messy. What used to just be:

#!/bin/sh
/srv/git/hooks/git-notifier $@ --link="http://[url];a=commitdiff;h=%s" \
  --emailprefix="[git: [repo]]"

Has now turned into this monstrosity:

#!/bin/sh
while read oldrev newrev refname
do
    commit=$(git rev-parse $newrev)
done

bzemail="bugzilla-daemon@bugzilla.me.com"

/srv/git/hooks/git-notifier $@ --link="http://[url];a=commitdiff;h=%s" \
  --emailprefix="[git: [repo]]"

for BUG in $(git log ${commit} -n 1 | sed 's/bug #/bug#/g' | \
  egrep -i -o 'bug#[0-9]*'); do
    BUGID=$(echo "${BUG}" | sed 's/bug#//i')
    EMAIL=$(git log ${commit} -n 1 --pretty=format:"%ae")
    test=$(echo "$BUGID" | sed 's/[0-9]*//g')
    if [ "${test}x" = "x" ]; then
    # make sure it is a digit
        /srv/git/hooks/git-notifier $@ --link="http://[url];a=commitdiff;h=%s" \
  --emailprefix="[git: [repo]]" --bug_id=${BUGID} --mailinglist=${bzemail} \
  --sender=${EMAIL} --manual=${commit}
    fi
done

(lines wrapped for readability)

So while it’s fugly, there’s quite a bit of magic to it. Seems that when you call git-notifier again, it won’t send an email because it knows it’s already been sent, which is why we need the commit hash, and feed it to it with the –manual option. The –mailinglist option is used to point to bugzilla (again, the git-notifier config is pointing to another email address to receive the commits already, so we need to override it). The –sender option takes the committer’s email address as the value (the $EMAIL variable), which also overrides the default git-notifier sender (which is the local user on the system unless you’re using gitolite (which I’m not)). The –bug_id is a digit to reference the bug in the commit (this should also send multiple mails if more than one bug is referenced in the commit, but I’ve not tested that yet). The end result is you get a copy of the git commit directly into bugzilla, in the same format that you would get it via email.

I may spend some time later on trying to make gitzilla play nicely with the newer version of pybugz, but for now this scratches my itch. Like I said, not the prettiest solution, but it works as a quick-n-dirty hack. The inspiration for using email to send this to bugzilla was from Gentoo’s Bugzilla Email wiki entry (the subversion integration part in particular).

Note that since the email is being sent as the committer, the committer needs to have an account with that email address in your bugzilla. If not, bugzilla’s email_in.pl will bounce it back. So you may want to have a bugzilla “commits” account as a dummy account from which you can email these things if not all of your committers have bugzilla access or use the same email address in bugzilla that they do in git.

If anyone has any suggestions on a better way to do this (particularly via XMLRPC which I think would be a nicer way to go), I’m all ears. (Short of writing my own — I could do this, having worked with bugzilla and lately with XMLRPC access, quite a bit — I’m too lazy to write something from scratch)

First, you need (Mountain) Lion Server, and you need the Server Admin application, from where you can enable SUS (Software Update Server). I attempted to do it transparently because I control DNS on the local network, but while this seemed to work with Lion, it doesn’t seem to work with Mountain Lion… not quite sure why yet.

I followed this tutorial: Transparent Software Update Server using Mac OS X Lion Server 10.7 to get me up and running. I did notice, however, that I was not getting any updates downloaded that had been posted after May 2012, and eventually tracked it down to the IP address it recommends putting in /etc/hosts. Do NOT use 17.250.248.95 for swscan.apple.com! The line to add to the SUS server’s /etc/hosts file is this:


17.164.1.22 swscan.apple.com


That will get you all current updates, including Mountain Lion updates. A few other things to note (since I need SUS to handle OS X 10.6, 10.7, and 10.8). The mod_rewrite section on /etc/swupd/swupd.conf should look like this:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} Darwin/9
    RewriteRule ^/index\.sucatalog$ http://%{HTTP_HOST}/cgi-bin/SoftwareUpdateServerGetCatalog?/index-leopard.merged-1.sucatalog
    RewriteCond %{HTTP_USER_AGENT} Darwin/10
    RewriteRule ^/index\.sucatalog$ http://%{HTTP_HOST}/cgi-bin/SoftwareUpdateServerGetCatalog?/index-leopard-snowleopard.merged-1.sucatalog
    RewriteCond %{HTTP_USER_AGENT} Darwin/11
    RewriteRule ^/index\.sucatalog$ http://%{HTTP_HOST}/cgi-bin/SoftwareUpdateServerGetCatalog?/index-lion-snowleopard-leopard.merged-1.sucatalog
    RewriteCond %{HTTP_USER_AGENT} Darwin/12
    RewriteRule ^/index\.sucatalog$ http://%{HTTP_HOST}/cgi-bin/SoftwareUpdateServerGetCatalog?/index-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog
</IfModule>

(Sorry, the above looks a bit messed up, but you should be able to copy-n-paste it). And my /etc/swupd/swupd.plist looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PurgeUnused</key>
    <true/>
    <key>autoEnable</key>
    <true/>
    <key>autoMirror</key>
    <true/>
    <key>autoMirrorOnlyNew</key>
    <false/>
    <key>limitBandwidth</key>
    <false/>
    <key>otherCatalogs</key>
    <array>
        <string>index-leopard.merged-1.sucatalog</string>
        <string>index-leopard-snowleopard.merged-1.sucatalog</string>
        <string>index-lion-snowleopard-leopard.merged-1.sucatalog</string>
        <string>index-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog</string>
    </array>
    <key>portToUse</key>
    <integer>8088</integer>
    <key>syncBandwidth</key>
    <integer>0</integer>
    <key>updatesDocRoot</key>
    <string>/var/db/swupd/</string>
    <key>valueBandwidth</key>
    <integer>0</integer>
</dict>
</plist>

With those changes, I can serve the updates to my mac clients, but not on Mountain Lion. On Mountain Lion clients you need to run this command to explicitly point to the SUS server:


$ sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://[SUS_SERVER]:8088/index.sucatalog


Now when you launch the App Store and check for updates, it will find any new Mountain Lion updates.

For transparent updates on earlier versions of OS X, I added the following to my DNS server’s named.conf:

zone "swscan.apple.com" {
	type master;
	file "master/swscan.apple.com.zone";
};

and the swscan.apple.com.zone file contains:

$TTL	86400
@		IN SOA	swscan.apple.com. root.mydomain.com. (
					2012060201      ; serial (d. adams)
					12H		; refresh
					15M		; retry
					1W		; expiry
					1D )		; minimum
	        IN NS		dns.mydomain.com.
		IN MX		10 smtp.mydomain.com.

localhost	IN A		127.0.0.1
swscan.apple.com. IN A		192.168.0.10

I suspect there is another domain name that needs to be resolved somewhere in addition to swscan.apple.com, but I’ve not had the time to track it down as of yet. An easy way to check is on Lion and earlier if you run “sudo softwareupdate -l” and watch the logs on your SUS, you’ll see the connections from that client. The same does not happen with Mountain Lion clients unless you do the “defaults write” command noted earlier.

If anyone knows how to make Mountain Lion clients connect to the SUS transparently, I would love to hear about how you got it to work.