HideAUser is a little tool for hiding a user. Once run, the loginwindow of Mac OS X will not show the user(s) specified. For multiple users, simply type the short name of each seperated by a space. Then attempt to login and see if the list shows the user you indicated not to show.

Click Here to Download HideAUser
Yesterday I looked at using diskutil to repair the permissions on a boot volume. You can also use diskutil to repair the permissions on a non-booted volume provided that there is a valid Mac OS X installation on that volume. To do so you would simply provide the path to that volume rather than to the blessed boot volume. For example, if the disk that we mentioned in the previous article were called Seldon and it was in a host booted to target disk mode then you would simply provide the path /Volumes/Seldon as before:
diskutil repairPermissions /Volumes/Seldon
In the event that you are scripting and want to take into account a dynamic target you can use a positional parameter or create the script on the fly. If you will then be using a package to choose a destination folder you can send a variable to the script and you would then use $1 in the place of /Volumes/Seldon, indicating a positional parameter. For example, a script might appear as follows:
#!/bin/bash
diskutil repairPermissions $1
This is how Mike Bombich used to summon repair permissions in NetRestore (if memory serves then his script is practically identical to the one I list here but I’m on a flight can’t cross-reference ’cause I’m still too cheap to get a GoGo account). In watching his scripts mature, I picked up running a repairPermissions as a post-flight deployment task. Since doing so I’ve noticed a slight decrease in the amount of troublesome hosts deployed to the tune of maybe 1 out of 40 imaging projects per year. If the volume name is identical across all hosts then this can be as simple as listing the first command above. If the volume will be a boot volume then you can use the bless command, as indicated yesterday, to grab the volume name.
Disk Utility has a nifty little button to Verify Disk Permissions and another to Repair Disk Permissions. Many use this frequently over the course of basic Mac OS X troubleshooting.

The underlying functionality is also exposed at the command line. Diskutil (located in /usr/sbin) has the verifyPermissions and repairPermissions, which roughly correspond to the buttons in Disk Utility. Because these can be run against different disks, each will need the volume indicated following the verb. For example, to run a Verify Disk Permissions against a volume called Seldon, you would use the following command:
diskutil verifyPermissions /Volumes/Seldon
To then run a Repair Disk Permissions on that same volume, you would use:
diskutil repairPermissions /Volumes/Seldon
In most cases, repairPermissions is done to the currently booted volume. To find this volume, you can use the bless command along with the –getBoot option. For example:
bless –getBoot
Bless will then respond with the device that comprises your boot volume. To convert this into a path that can be used with diskutil, you would use the diskutil command followed by info followed by the output of the bless command. For example, if the device were /dev/disk0s2 then you would run the following:
diskutil info /dev/disk0s2
You could then script a repair permission of the boot volume using the following, which would also dump the output into a log file:
declare tmp=/disk
declare boot=/disk
bless –getBoot > $tmp
mkdir /var/log/318
diskutil info $tmp | grep “Media Name:” | cut -c 30-100 > $boot
/usr/sbin/diskutil repairPermissions $boot >> /var/log/318/fixperm.log
echo “Repair Permisssions completed at `date` >> /var/log/318/fixperm.log
Placing this script into a package would then allow for sending a Repair Disk Permissions command to client computers though, let’s say, ARD or even allow a user to run it themselves using the JAMF self-service client. All without having to leave ones chair or provide an administrative password to a user (having said this the script will require local administrative privileges).
When the iTunes Store came out if you had told me that they would end up selling 10 billion songs you might have come across like a bit of an Austin Powers skit. But Apple has crossed 10 billion now in “staggering” fashion: http://www.apple.com/pr/library/2010/02/25itunes.html
When new versions of operating systems come out sometimes articles need to be updated. It’s always nice when someone else does the hard part. Recently, Ben Levy, an Apple Consultant from Los Angeles, did some work on an article I did awhile back. To quote Ben, the new procedure is to:
1. Boot from something other than your intended RAIDed boot drive, open Terminal and use diskutil list to identify the relevant disks and partitions.
2. diskutil appleRAID enable mirror disk0s2 – (assuming correctly identified slice, yours may be different) This command turns your primary disk into a RAID mirror without a mirror
3. Reboot back to your boot drive
4. diskutil checkRAID and diskutil list just so you know where and what everything is…
5. diskutil AppleRAID add member disk2 8014A446-E10D-4BC9-A199-67362E54FB7C – (assuming disk2 is in fact the drive you are adding) the UUID is the UUID of the RAID as discovered in checkRAID
6. diskutil checkRAID should now show it rebuilding the RAID. This could take hours. You can check on the progress again using the same command.
Thanks to Ben for the hard work. Now, I think it’s about time I wrapped this into a GUI app…
One of those security things that pops up every now and then is to use the secure erase feature of Mac OS X, located in Disk Utility. But you can access this same feature from the command line using the secureErase option in diskutil followed by the freespace option.
The format of the command is:
diskutil secureErase freespace [level] [device]
The levels are as follows (per the man page as not all of these are specified in Disk Utility):
- Single-pass zero-fill erase
- Single-pass random-fill erase
- US DoD 7-pass secure erase
- Gutmann algorithm 35-pass secure erase
- US DoE algorithm 3-pass secure erase
So for example, let’s say you had a volume called Seldon and you wanted to do a standard Single-pass zero-fill erase. In this example you would use the following:
diskutil secureErase freespace 0 /Volumes/Seldon
If you were to automate the command then you would want to dump the output into a log file. For example:
diskutil secureErase freespace 0 /Volumes/Seldon > /var/log/secureeraselog.tmp
As my most recent information seems to now be on Amazon I have wrapped that into an easy link with links back to this site. It can be found at http://krypted.com/amazon.
The 8th annual Southern California Linux Expo (SCALE) is being held at the Westin by LAX in Los Angeles this weekend. It starts today (so I should have posted this sooner) and sports sessions on open source topics ranging from Zenoss to Sugar to Fedora. For more on the schedule check out the conference schedule at http://www.socallinuxexpo.org/scale8x/conference-schedule-feb-19-2010.
This is one of those conferences that I’ve had to miss the last couple of years. But prior to that I was at the first few. The topics were mostly technical in nature, other than me the speakers/conference faculty were all top notch and the organization of the show is impressive. Given all the sessions and work that goes into it, it’s modestly priced and I’m sure to be a blast while also being a great chance to get a little inexpensive technical training. If I were in LA this weekend I would be there (and much warmer no doubt).
So swing by and check it out. You can register here.
Brace yourself, ’cause I’m a tool (or don’t brace yourself if you’ve read much of my writing or met me since you already knew this to be the case). Classic cedge-fail moment that I just had to share. What do you do when you have a variable before a string of text but cannot have any spaces? You brace your variable. Basically, place the $ followed by the variable that is wrapped in the braces. For example, if I was going to put cedge as the content of a variable and then write a file called cedge.plist from the contents then I would use the following.
user=cedge
touch “${user}.plist”
Big script, took 10 minutes to figure out I had forgotten to brace the variable.
←Older