Firefox Can’t Reach The Internet

With great standards-compliance and cross-platform support, Firefox is becoming the browser of choice not just for end-users but for internet and intranet developers as well. Once it's deployed on corporate networks, however, the Macintosh edition often can't see past the firewall.

Firefox may be an excellent internet citizen, it turns out, but it doesn't follow Macintosh standards too closely. Among the conventions it ignores are the Proxy settings in the Network pane of System Preferences. Instead, Firefox keeps it's own proxy settings hidden, three levels down in its own preferences and uncearly labeled. This is the most common reason Firefox can't seem to load web sites when Safari can.

To solve the problem, go to the Firefox menu and select "Preferences...", choosing the "Advanced" button at the top of the resulting window. Then from the row of tabs, select "Network" and click "Settings..." to bring up the proxy configuration panel. From there it's easy to fill in your proxy addresses, and your Firefox users will be back online.

Share Files Through WebDAV

Your biggest client's firewall blocks FTP, your Macs can't follow Outlook's backslash-style file links, and that hotel promising "free internet in every room" really only offers web browsing. So how can co-workers trade information from diverse locations, update their calendars from on the road, or just exchange file addresses for multiple operating systems? It can be difficult to find an easily accessible, relatively secure, and fully cross-platform method to host shared documents.

WebDAV (Distributed Authoring and Versioning) meets all three criteria, allowing authorized users to read and write network files natively from both Macintosh and Windows systems. Packaged as a set of web extensions built directly into Mac OS X Server, it's designed to allow transfer of a wide range of data using only standard web ports and protocols. It's also extremely easy to set up, requiring nothing more than the graphical server administration tool.

The instructions below were originally written for Mac OS X 10.4. So while some of the buttons and windows (and in particular the "Sites" settings) have been rearranged or redecorated in version 10.5, their functionality has stayed identical for these purposes.

Open Server Admin on the machine you'd like to host shared files, then select the "Web" service from the list down the left hand side. Choose "Modules" from the row of buttons on the right, and scroll down the window until you find dav_module. It should be enabled by default, but if it isn't, do so using the check box to the left. Then click the "Save" button at the bottom right.

Now proceed briefly to the "Sites" pane (four buttons to the left of "Modules" in 10.4). Just click the plus sign at the bottom left, and the window will transform to the "General" configuration pane for your new domain.

In this instance we're hosting only the sub-domain webdav for the larger example.com domain. The default settings will suit most purposes, though you may wish to change the "Web folder" setting if you'd like to store your documents in another location. If you do so, be sure the new directory is owned by the web server's user and group www, and that read and write permissions are enabled for both.

Next, in the "Options" pane, check "WebDAV" from the list of features, then move on to the "Realms" pane where you'll set access controls to your site.

Click the plus sign in the bottom left to create a new realm, which will define the security settings on your network share. You can name the realm anything you like, but be sure to choose "Digest" as the "Authorization" method (as it provides the best balance of security and support for general use), and that the "Folder" setting matches the "Web Folder" you chose in the "General" preferences pane. This approach won't encrypt all the data transfered, but it will use the Mac OS X encrypted password mechanism to prevent unauthorized access.

Now click the "Users & Groups" button at the bottom right, and select the pre-existing users and groups you'd like to allow access to the WebDAV realm (or create them in Workgroup Manager if they don't yet exist, then add them here when you're done). Select the appropriate permissions using the "Can Browse" (read) and "Can Author" (write) check boxes, then uncheck those boxes for the built-in "Everyone" user (unless you'd like the whole world to have access to your files).

With all your settings configured, click "Save", then use the rounded "back" button at the top to return to the "Sites" pane. Check the "Enabled" box to the left of your new domain, then click the big green "Start Service" button at the top of the window. Your server should now allow reading and writing documents over a normal web connection.

To attach to your new file share from a Macintosh client, simply select "Connect to Server..." from the "Go" menu in the Finder. Type in the full internet URL for the WebDAV realm, in this case http://webdav.example.com, and hit "Connect". You'll be asked for a username and password, after which the share will mount on your desktop like any other network volume. The procedure is even easier from Windows XP and Vista, where you can simply type the URL into any Explorer address bar.

With your WebDAV-enabled site online, your users can exchange large files, publish and subscribe to iCal calendars, and collaborate on remote documents using nothing but a World Wide Web connection.

Server Crashes When Searched

Out of the blue, your server stops responding. The screen goes gray for a moment, the machine restarts, and by the time you even know it happened everything is fine. Then it crashes again. This time you hear, "I just did a Spotight search on the XServe, and then everyone was disconnected..."

There is a known issue with OS X Server 10.4.7-11, where client machines can crash the server by remotely searching network volumes. The problem lies in how the operating system sets the memory buffer for disk usage. In servers with less than 4GB of RAM, the buffer is set higher than the amount of physical memory, so that searching a volume can fill the buffer and crash the machine.

You can see this happen on effected systems when Spotlight is used on their network shares. Open Activity Monitor in the Utilities folder (or usetop on the command line) and watch the main OS process (called kern_task) quickly take all the available memory.

The solution is simple, though it requires the use of a Terminal-based text editor and some familiarity with the underlying OS X file system. Open /etc/rc.server, and set the buffer to a smaller value, replacing 90000 with 20000 in the line below:

sysctl -w kern.maxnbuf=90000

You can also use the Unix "stream editor" to make the change with a single command. From the Terminal, simply type:

sudo sed -i.bak 's/maxnbuf=90000/maxnbuf=20000/' \
/etc/rc.server

Here sed searches for the phrase between the first set of slashes and replaces it with the phrase between the second. The -i option edits the file in place, backing up the original contents to a separate file in case there's a problem. This approach works particularly well if you're administering multiple servers with Apple Remote Desktop, as it can be sent to a list of machines using the "Send Unix Command" feature.

Once the file is changed, reboot your system to reset the buffer. This will solve the issue for the time being, but you'll want to check after each Software Update to make sure the fix is still in place. Although Apple has reported this problem in it's knowledge base since February, subsequent updates to 10.4 have all changed an edited /etc/rc.server file back to it's original values.

Startup Processes With Launchd

Some jobs are too important to be left to users. While native services like file and print sharing begin when Macintosh systems first boot, third party applications are often left to start as Login Items, configured out of System Preferences on a single account. For essential services, this method can range from unreliable to disastrous.

Introduced in OS X 10.4, launchd allows you to easily convert any program into an automated process. The method can be used for everything from simple shell scripts, like those handling routine maintenance tasks, to full-fledged commercial applications, replacing the legacy startup methods for products like Backup Exec 11d and Oracle 10g.

Upon boot, launchd utilizes configuration files in the plist format, xml-based preferences that can be built in any text editor to store system or application configurations. These files can dictate scheduling, watch file paths for changes, or define network sockets and system resources dedicated to a specific job. At its most basic, however, just a couple of parameters can safely start administrative processes.

<?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>JOB-NAME</string>
<key>ProgramArguments</key>
<array>
<string>APPLICATION-PATH</string>
</array>
<key>OnDemand</key>
<false/>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

In the example above, JOB-NAME should be replaced with a unique identifier in reverse-DNS format (like com.domain.job), while APPLICATION-PATH should be the absolute (full UNIX) path to the command you're launching. If there are additional command line options, they should be listed one at a time, directly underneath the APPLICATION-PATH and inside additional string tags.

With your plist built, save it in /Library/LaunchDaemons with a reverse-DNS filename (such as com.domain.job.plist). Then change it's ownership and permissions to run as the root superuser:

sudo chown root:wheel /Library/LaunchDaemons/FILENAME
sudo chmod 700 /Library/LaunchDaemons/FILENAME

If your process should run as another user or group for security reasons (such as an application-specific account), simply include the UserName and GroupName key after ProgramArguments in your plist file:

<key>UserName</key>
<string>APPLICATION-USER</string>
<key>GroupName</key>
<string>APPLICATION-GROUP</string>

Now applications can launch as any user at startup, run continuously in the background, and automatically restart as needed. There's syntax for reoccurring tasks, intended run order, file permissioning, and an overwhelming host of other options.

For those administering customized or complex OS X installations, a thorough understanding of launchd is essential to a well-designed and well-maintained system.

Recommended Reading: For more information on configuring launchd for advanced tasks, you can read the full launchd.plist manual at Apple's Developer Connection.