HOWTO: Time Machine tweaking: fixing ACLs and extended attributes using fsaclctl and chflags

Posted by max on March 03, 2009

I recently needed to reinstall OS X on my laptop. Once I reinstalled, I my primary username (“max”) didn’t have the same UID that it had had on the prior install. This didn’t cause any problems until I wanted to browse my Time Machine backups while not as root.

Much to my chagrin, I wasn’t able to change ownership of the old backups of /Users/max with a simple chown -R. What was going on here?

Two things. Volumes configured for Time Machine use two mechanisms to keep users (including you too, root) from mucking around too much and making the backups un-useful.

(It’s actually fairly difficult to corrupt a Time Machine backup, due to its novel and clever use of hardlinks, described at some length in this excellent article by John Siracusa, which I actually mentioned in an earlier post. One of the great things about Time Machine is that the files are actually files, not wrapped in some gargantuan monolithic binary clump comprehensible only to a particular flavor of backup software.)

If you need to do major mucking, like I did, this is what you have to deal with:

  • Filesystem ACLs, manipulated with fsaclctl. (Yeah, it’s a damn mouthful. Think “filesystem ACL control” and you’ll be somewhat OK.
  • UFS+ extended filesystem attributes, manipulated with chflags

You might not need to do major mucking. You might want to do parts of this if, for example, you discover that Time Machine just backed up a bunch of Linux ISOs you really don’t want to waste your storage space backing up.

Naturally, you’ll need to be root or using sudo in order to actually change these.

First, you need to disable ACLs on the filesystem being managed by Time Machine. It’s easy. This doesn’t destroy any ACL metadata stored, it just stops (temporarily, if you wish) from being used or enforced.

fsaclctl -p /Volumes/backup_vol -d

where “backup_vol” is whatever the name of your Time Machine volume is.

Next, if you had the same situation as I did where you need to change ownership of a whole branch of your filesystem, you’ll want to use chflags, but probably selectively. Here’s what I did:

find /Volumes/backup_vol/Backups.backupdb/machinename/"Macintosh HD"/Users/max -flags +uchg -print0 | xargs -0 chflags -R nouchg

where machinename is the short hostname of the backed-up machine in question. “Macintosh HD” is the default main volume name, which may or may not be the case for you; don’t forget to enclose the name in quotes if it’s got spaces in it.

For those less Unix-inclined of you, that finds every file in my backed up /Users/max branch that has the “uchg” flag set (no user changes permitted) and unsets the flag. For my purposes, I don’t believe I need to reset the “uchg” flag back, so I didn’t store the changed filenames in order to do so.

Finally I changed the whole branch to belong to me again:

chown -Rh max /Volumes/backup_vol/Backups.backupdb/machinename/"Macintosh HD"/Users/max

There were a couple of symlinks that the above choked on, but they weren’t important enough to me to track down exactly why the ownership of the symlinks wasn’t changing. This may not, obviously, be the case every time. I could have programmatically found them, deleted them, and re-linked them, but it wasn’t worth the effort.

Don’t forget to turn the filesystem ACLs back on:

fsaclctl -p /Volumes/backup_vol -e

Popularity: 49% [?]

/etc/hosts entries on OS X Leopard (10.5.5)

Posted by max on November 21, 2008

I was having a hell of a time making entries in /etc/hosts in Leopard. I’d never had any issue in Tiger. Without getting into the details of the fairly complicated way that Leopard handles name resolution via DNS, directory services, and flatfiles (you can look elsewhere for that), it appears that Leopard is pretty picky aout where precisely you put entries in /etc/hosts.

A virgin /etc/hosts file looks like this in Leopard:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0     localhost

I thought it would make sense to put in my new IPv4 entries above the IPv6 entries (i.e., between the broadcasthost line and the ::1 localhost line. Right? Wrong. If you put them there, your resolver will happily go on ignoring them until the end of time.

Put them at the bottom of the file and they’ll work.

Addendum 19 May 2009: I’m reading the O’Reilly book “Mac OS X for Unix geeks,” and here’s how to do it the OS X way:

$ sudo dscl . /Hosts/www.awfultimewastingsite.com ip_address 127.0.0.1

Note that /Hosts/ is not part of the filesystem — it’s part of the Directory Services local database.

The directory entries take precedence over /etc/hosts.

Popularity: 51% [?]

/usr/bin/file rules, even when it’s wrong

Posted by max on July 11, 2008

‘file’ is a great utility. Even when it’s wrong, it can at least be good for an audible laugh:

$ dd if=/dev/urandom of=fakefile.bullshit bs=4096 count=400
400+0 records in
400+0 records out
1638400 bytes (1.6 MB) copied, 0.307462 s, 5.3 MB/s
$ file fakefile.bullshit
fakefile.bullshit: DOS executable (COM)

Popularity: 59% [?]

How to learn (and not get burned by) LVM

Posted by max on July 02, 2008

LVM2 is a very useful thingy indeed. I sort of misunderstood its utility for a while. It’s not just for managing storage on mongo SAN clusters; it can be very useful for managing storage on a workgroup box with several drives.

However, on Linux, beware: You cannot boot from an LVM logical volume. You need to have a regular filesystem (ext2/ext3/xfs/jfs/reiserfs/etc.) partition for /boot. I’m not quite sure why I didn’t grasp this when planning my first LVM layout.

The Red Hat documentation on LVM2 is excellent, but is not the first thing that comes up on searches, because it’s buried in the weirdo RHEL system documentation. There’s a similar, RedHat-generated doc which is also good at the CentOS project, available here.

It takes some getting used to to understand LVM, and if you’re like me, it doesn’t hurt to practice. There is some degree of overlap with what RAID can do for you, and using them both together makes one’s head spin at first. Drawing a map of your planned layout is extremely helpful.

For wrangling your storage layouts, the Parted Magic live CD can be very helpful. Unfortunately, not all installers want to respect what you’ve laid out with it. Fedora 9 played nice. Ubuntu 8.10 (alternate install CD — essential for RAID installs) was not; it kept not respecting the /dev/md software RAID devices that I’d previously set up, then would create some new bogus md devices.

Popularity: 60% [?]

DHCP on VMware Fusion

Posted by max on March 04, 2008

VMware Fusion is a wonderful thing. I am happily running three Linux instances at once under my MacBook with 4GB of RAM (though, as best I can tell, the mobo can actually only address 3GB of RAM).

One glitch that was driving me crazy, though, was that it seemed like DHCP leases were being allocated flakily to the guest machines. When you’re doing database replication, you can’t have master/slave IP addresses changing all the time. (And you certainly don’t want two machines with the same IP address!)

Some digging around turned this up. I don’t remember exactly where — I believe snippets of it were in an official VMware forum — but it was harder to find than it should have been. Hence my posting, to add another path to help those who need it.

On OS X, the file you need to change should be in /Library/Application Support/VMware Fusion/vmnet8/dhcpd.conf. (vmnet8 is the virtual interface for NAT networking in the guest machines.) You should have a subnet clause in it already like this:

subnet 172.16.253.0 netmask 255.255.255.0 {
    range 172.16.253.129 172.16.253.254;
    option broadcast-address 172.16.253.255;
    option domain-name-servers 172.16.253.2;
    option domain-name "localdomain";
    option routers 172.16.253.2;
}

Now, for each virtual machine, set up a new host clause, e.g. :

host ubuntu64-vm {
    hardware ethernet 00:0F:FF:EF:00:00;
    fixed-address 172.16.253.20;
}

Be sure to assign an IP address (fixed-address) outside the range specified in the subnet clause at top.

Get the Ethernet MAC address from ifconfig eth0 inside the guest machine, or from ~/Documents/Virtual Machines/GUESTMACHINENAME/GUESTMACHINENAME.vmx (it’s the line with ethernet0.generatedAddress).

Finally, restart the requisite VMware daemons by running

sudo "/Library/Application Support/VMware Fusion/boot.sh" --restart

Popularity: 100% [?]

Installing Ruby 1.8.6 on Ubuntu Feisty Fawn (7.04)

Posted by max on October 04, 2007

Ubuntu seems to be the big distro these days. (Remember all of those other “it” distros? Slackware? The original Red Hat? Mandrake? I am vaguely tired of the trendiness of distros.)

Anyway, there is no package yet for Ruby 1.8.6 on Ubuntu Feisty Fawn (7.04), which is unfortunate, since mongrel_cluster doesn’t work properly under Ruby 1.8.5.

The install steps I got at Urban Puddle (here) were nice, but Rails still wasn’t happy: I kept getting that awful `require’: no such file to load – rubygems (LoadError) error.

Here’s what I did to fix it. YMMV.

Building Ruby (from Urban Puddle):

tar xjvf ruby-1.8.6.tar.bz2
cd ruby-1.8.6
apt-get build-dep ruby1.8
./configure --prefix=/usr
make
sudo make install

Next, to fix it:

cd /usr/src/rubygems/rubygems-0.9.4
sudo ruby setup.rb

Et voilà :

max@somehost:~ $ irb
irb(main):001:0> require 'rubygems'
=> true

I’m not quite sure why the Ruby source doesn’t ship with the rubygems source. Is it because rubygems is still a < 1.0 release?

Popularity: 18% [?]