Firefox URL Bar for Mac Users

The fact that John Gruber is trying and writing about the latest Firefox betas — which, by the way, I am frickin' loving — is a testament to how good this release will be. Though he's not switching for a variety of reasons, his review is still quite complimentary.

Most of Gruber's Firefox complaints either don't bother me or don't affect me, but there is one that has always bugged the crap out of me: a single-click in the URL field of the browser highlights the entire URL. This is almost never what I want to do. If I want to highlight the entire URL, I'll just hit Command-L and be done with it. If I'm clicking in the URL field it's because I mean to edit that thing, and I want my click to place the cursor right where I clicked, damnit. Despite Firefox 3's attempt — and, I should mention, general success — to integrate better with your platform of choice, it gets it wrong here.

Fortunately, Gruber's posted a link to a dude who has the skinny on the fix. Here it is in my own words, if you don't feel like following the links:

  • Type "about:config" in the URL field
  • Filter by "clickSelectsAll"
  • Change the "browser.urlbar.clickSelectsAll" to "true" (just double-click it)


Firefox 3 Beta 5: Fix the URL Bar
(click image for larger view)

From now on clicking in the URL bar in Firefox will behave as it does in Safari: single-click places the cursor; double-click highlights the word; triple-click highlights the whole URL.

Oh, sweet merciful heaven, that's good stuff.

NetBoot Part 4

So this is going great. I have a really solid Base OS Install, and a whole buttload of packages now. Packages that set everything from network settings to custom and specialized users. I can build a typical system in about 45 minutes, and I can do most of the building from my office (or any other computer in the lab that has ARD installed).

I'm also getting fairly adept at making packages. A good many of my packages are just scripts that make settings to the system, so I'm getting pretty handy with the bash and quite intimate with dscl. But, perhaps most importantly, I'm learning how to make all sorts of settings in Leopard via the command-line that I never knew how to do.

The toughest one so far has been file sharing. In our lab we share all our Work partitions to the entire internal network over AFP and SMB. In the past we used SharePoints to modify the NetInfo database to do so, but this functionality has all been moved over to Directory Services. To complicate matters, SAMBA no longer relies simply on standard SMB configuration files in standard locations, and the starting and stopping of the SMB daemon is handled completely by launchd. So figuring this all out has been a headache. But I think I've got it!

Setting Up AFP

Our first step in this process is setting up the share point for AFP (AppleFileshareProtocol) sharing. This wasn't terribly difficult to figure out, especially now that I've been using Directory Services to create new users. To create an AFP share in Leopard, you use dscl. Once you grok the syntax of dscl it's fairly easy to use. It basically goes like this:

command node -action Data/Source value

The "Data Source" is the thing you're actually operating on. I like to think of it as a plist entry in the database — like a hierarchically structured file — which it basically is, or sometimes I envision the old-style NetInfo structures. To get the needed values for my new share, I used dscl to look at a test share I'd created in the Sharing Preferences:

dscl . -read SharePoints/TEST

The output looked like this:

dsAttrTypeNative:afp_guestaccess: 1

dsAttrTypeNative:afp_name: TEST

dsAttrTypeNative:afp_shared: 1

dsAttrTypeNative:directory_path: /Volumes/TEST

dsAttrTypeNative:ftp_name: TEST

dsAttrTypeNative:sharepoint_group_id: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX

dsAttrTypeNative:smb_createmask: 644

dsAttrTypeNative:smb_directorymask: 755

dsAttrTypeNative:smb_guestaccess: 1

dsAttrTypeNative:smb_name: TEST

dsAttrTypeNative:smb_shared: 1

AppleMetaNodeLocation: /Local/Default

RecordName: TEST

RecordType: dsRecTypeStandard:SharePoints

Okay. So I needed to use dscl to create a record in the SharePoints data source with all these values. Fortunately, the "sharepoint_group_id" is not required for the share to work, because I'm not yet sure how to generate that number. But create the share with all the other values and you should be okay:

sudo dscl . -create SharePoints/my-share

sudo dscl . -create SharePoints/my-share afp_guestaccess 1

sudo dscl . -create SharePoints/my-share afp_name My-Share

sudo dscl . -create SharePoints/my-share afp_shared 1

sudo dscl . -create SharePoints/my-share directory_path /Volumes/HardDrive

sudo dscl . -create SharePoints/my-share ftp_name my-share

sudo dscl . -create SharePoints/my-share smb_createmask 644

sudo dscl . -create SharePoints/my-share smb_directorymask 755

sudo dscl . -create SharePoints/my-share smb_guestaccess 1

sudo dscl . -create SharePoints/my-share smb_name my-share

sudo dscl . -create SharePoints/my-share smb_shared 1

This series of commands will create a share called "My-Share" out of the drive called "HardDrive."

After modifying the Directory Services database, it's always smart to restart it:

sudo killall DirectoryService

And we need to make sure AFP is running by starting the daemon and reloading the associated Launch Daemons:

sudo AppleFileServer

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.AppleFileServer.plist

sudo launchctl load -F /System/Library/LaunchDaemons/com.apple.AppleFileServer.plist

Not the easiest process, but not too bad. SMB was much tougher to figure out.

Setting Up SMB

Setting up SMB works similarly, but everything is in a completely different and not-necessarily standard place. To wit, Leopard has two different smb.conf files: one that's auto-generated (and which you should not touch) in /var/db, and one in the standard /etc location. Fortunately, it turned out, I didn't have to modify either of these. But still, it led to some confusion. The way SMB is managed in Leopard is rather roundabout and interdependent. Information about SMB share is stored in flat files — one per share — in /var/samba/shares. So, to create our "my-share" share, we need a file named for the share (but all lower-case):

sudo touch /var/samba/shares/my-share

And in that file we need some basic SMB info to describe the share:

#VERSION 3

path=/Volumes/HardDrive

comment=HardDrive

usershare_acl=S-1-1-0:F

guest ok=yes

directory mask=755

create mask=644

Next — and this was the tough part to figure out — we need to modify one, single, very important preference file that basically informs Launch Services that SMB should now be running:

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server "EnabledServices" '(disk)'

This command modifies the file com.apple.smb.server.plist in our /Library/Preferences/SystemConfiguration folder. That file is watched by launchd such that when it is modified thusly, launchd knows to start and run the smbd daemon in the appropriate fashion. Still, for good measure, I like to reload the LaunchDaemon for the SMB server by hand. Don't need to, but it's a nice idea:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.smb.server.preferences.plist

sudo launchctl load -F /System/Library/LaunchDaemons/com.apple.smb.server.preferences.plist

That's pretty much it! There are a few oddities: For one, the new share will not initially appear in the Sharing Preferences pane, nor will the Finder show it as a Shared Folder when you open the window.

Shared Folder: This Won't Show Without a Reboot

(click image for larger view)

But the share will be active, and all will be right with the world after a simple reboot. (Isn't it always!) Also, if you haven't done it already, you may have to set permissions on your share using chmod in order for anyone to see it.

I was kind of surprised at how hard it was to set up file sharing via the command-line. But I'm glad I stuck with it and figured it out. It's good knowledge to have.

Hopefully someone else will find it useful as well.

NetBoot Part 3

I've become quite the package whiz, if I do say so myself. Actually, I'm probably doing something ass-backwards, but still, I wanted to share some of my working methods as they seem to be, well... Um... Working...

One of the things I'm doing is using packages to run shell scripts that make computer settings (like network settings and user-creation) rather than actually installing files.

PackageMaker: I Prefer the 10.4 Version of Packages
(click image for larger view)

This can be done in PackageMaker by taking some creative liberties with preflight and/or postflight scripts. The only hitch is that PackageMaker insists that you install at least some files onto the target system.

PackageMaker: Installing Scripts to /tmp
(click image for larger view)

So the majority of my packages contain only a single script. That script first gets installed to /tmp, thus fulfilling PackageMaker's "must install files" directive.

PackageMaker: A Postflight Script
(click image for larger view)

The script then runs as a posflight script, and the last line of the script deletes the instance of the script in /tmp, just for good measure.

Shell Script: Removing the Script from /tmp
(click image for larger view)

It could be argued that there's no reason to create packages from scripts, that you could just as easily run the scripts directly in ASR, but packages offer a couple of advantages. For one, packages leave receipts, so it's easy to check and see if something's been set on a computer. For two, packages are easy to deal with; assistants and other SysAdmins know how they work and can easily understand how to use them. Need to change a machine's settings? Don't run a script. Hell, don't even bother opening System Preferences. Just open and run a package. What could be easier (and less error-prone, I might add)? From an ease-of-use perspective, packages have a huge advantage. And ease-of-use adds efficiency. Which is why I not-so-suddenly find myself in the envious position of being able to build systems in about half the time (or less!) it used to take. That's a huge improvement!

Using this method (and sound DNS) I've been able to write packages that configure network settings, create computer-specific users, set custom disk and file permissions, set up autofs, bind to our authentication server and set up SSH for password-less login.

Next on the list: File Sharing!

Should be fun.

Firmware Goodness

I don't usually get too excited about firmware updates, mainly because the things they fix rarely tend to affect me, for whatever reason. But the last Leopard Graphics Update from a few weeks ago has actually caused me some problems. Two, I believe, to be precise.

The first problem I've had may or may not be related to the Leopard Graphics Update: occasionally my machine — my brand new, fresh-out-of-the-box machine — just locks up, requiring a force reboot. I don't remember where, but I do remember reading that people were associating this with the Leopard Graphics Update, and it definitely started happening to me immediately after that update, so I'm fairly sure the update was the cause. The second problem has been cosmetic: when typing in the Spotlight menubar the drop-down sheet flickers in and out, causing a really annoying strobe effect until the window stops updating. Very irritating!

The good news is, Apple's latest ATI Radeon HD 2600 XT Firmware Update fixes the second problem. Here's hoping it fixes the first one as well. Only time will tell.

UPDATE 3-28-07:
Yep. All fixed. Since applying this update my machine has not locked up. Nice.

A Rift in the Space-Time Continuum

I did it. Yes, I finally did it: I went and pissed off Time Machine.

I've been using the Staff Backup drive for my Time Machine backups, see. And that drive needs a certain amount of free space for any large chunks of data that staff might create during any given day. So when Time Machine finally ate up all the disk space on the drive, I decided to see what would happen if I cleared some space up by hand, the old fashioned way. And so I deleted the first month's worth of data from my Time Machine backupdb folder.

Now, I'm not totally stupid, and I have at least a good enough understanding of how Time Machine works to know that this would cause problems, but I was curious, and I wanted to see what those problems would be and how they would manifest themselves.

The first thing I got was a generic Time Machine failure:

Time Machine Failure
(click image for larger view)

Clicking the red info button revealed surprising details, considering my drive showed 200GB free:

Time Machine Error: Really? How do You Figure?
(click image for larger view)

So I decided to run a backup and see what happened. The backup appeared to start smoothly, but eventually I wound up getting this message:

Time Machine Error: Funny Math
(click image for larger view)

Hmmm... I think I broke it.

It makes sense, really. I mean, it stands to reason that, in Time Machine, the first and oldest backup actually contains the most actual data. It's the base for all the other data. Subsequent backups only copy changes, but the first backup is kind of the Mother of All Backups, if you will. Deleting that first backup will, unsurprisingly, wreak all sort of havoc on your backups.

Havoc that is, as far as I can tell, irreversible. The only way I've found to fix this is to start the backups fresh. That is, turn off Time Machine, delete the old backups (or at least move the old backupdb folder out of the way), and then set Time Machine up again.

Bummer.

Oh well.

UPDATE:
Ahhh! That's more like it.

Time Machine: Back Up and Running
(click image for larger view)