Resize HFS+ and NTFS Volumes

When you blew last year's budget on a brand new SAN, its potential seemed second only to its simplicity: As demand grows, add capacity from a huge storage pool, and never have to worry about individual hard drives again. When you increase the allocation to the Mac share, however, your workstations still see the same amount of space. Unlike Leopard, Mac OS X 10.4 can't natively or dynamically increase partition size, and no version of Apple's Disk Utility can resize NTFS or Linux partitions.

As files grow larger and storage more decentralized, managing Macintosh volumes on a shared network can be a significant challenge. Coriolis Systems' iPartition meets that challenge by resizing populated file systems, growing and shrinking partitions without damaging their contents.

Simply select the "disk" you need to modify from the list on the left side of iPartition's main window. This can be a literal disk, a local RAID array, or a designated slice from a logical volume device. Then grab the textured handle on your existing colored partition and drag it around until it eclipses the gray empty area entirely (or use the "Inspector" panel to specify the partition size down to the byte). Since this is a major disk operation, you'll want to have a current backup of the partition just in case. You'll also want to turn off network sharing to the volume before you proceed, since resizing it in this manner will unmount it momentarily.

Once you're happy with your changes, hit the bright green "Go" button, and your changes will commit to disk (often instantaneously). If you assign too much space, you can shrink volumes in the same manner, though the process is much slower in reverse (you'd probably want to leave a 500GB volume overnight). There are a number of other disk management features (including a limited version of Coriolis' iDefrag utility) in iPartition, but it's ability to change filesystems of al types that makes the program invaluable part of any administrator's toolkit.

Update: Although Leopard added the ability resize HFS+ partitions dynamically, iPartition has only improved since our initial review, handling all categories of Volume beautifully on multi-OS storage systems. We wouldn't maintain a network of any complexity without it.

iPartition retails for $49.95.

Customize Access By Service

The sales team need VPN for travel. The finance department needs Windows File Sharing. Freelancers need to deliver work via FTP, but they shouldn't ever be able to log in from the console. Your server needs to offer a variety of services, but you don't want to offer every service to every user with an account. Using the access panel built into the Server Admin application, you can set finely grained controls over which users and groups can utilize which services.

While these restrictions can be determined on a user-by-user basis, this approach can quickly become hard to manage. The more scalable option is to utilize groups, either from existing directory services or created specifically for this purpose on the local machine. Even if departmental groups like "human resources" and "customer care" exist in your management scheme, you may wish to consider nesting these into service-based groups like "AFP Users".

With your access model planned, open Server Admin as an administrative user and highlight your server name in the left column. Then choose the Access button from the strip along the top right, and you'll see a list of the services available to regulate.

Simply uncheck "Use same access for all services" then choose a service on the left, adding users and groups to the list on the right with the plus button. When you've configured the services to your satisfaction, hit "Save" to enforce your policy.

The procedure is deceptively straightforward, so it is worth pointing out its pitfalls. Login Window can easily be configured to lock all users out of the machine, and controlling Mail this way completely tramples the per-user email settings in Workgroup Manager (including address forwarding and disk quotas). For reasons like these, it's best to have a strategy for each service individually.

Finally, there's one service Server Admin doesn't control access to at all. Just like individual client machines, the ability to remotely control your server is regulated in the System Preferences under the Sharing pane. Select "Apple Remote Desktop" from the list presented, then click "Access Privileges..." for the full complement of options.

Reset Administrative Passwords

Anyone who's ever worked the help desk knows how easily people can forget their account credentials. In a managed environment, it just takes a couple of mouse clicks and the problem is solved. In a workgroup where machines were set up independently (and often by their users), locking out the only administrative user could mean wasting hours migrating user data to an entirely new installation.

A complicated problem, though, doesn't always require a complicated solution. With an OS X install disk (like the one that comes with each Macintosh computer) you can easily reset any account password.

Now restart the computer holding down the "C" key with the install disk in the optical drive. When the installer starts, choose your language, and you'll proceed to the welcome dialog. Go to the "Utilities" menu at the top of the screen, and choose Reset Password. At the top of the window, select the boot volume, then the appropriate user from the pulldown menu. Enter a new password, click "Save", then restart.

Be careful with this method if File Vault, the OS X encrypted home directory system, is enabled. Preventing easy data access is what it's designed to do, and without the master password (set when File Vault is first set up) you'll be locked out of the user's files forever.

Once you've logged back in with your new password, you'll want to remove the user's old "login" keychain, since without the original password it can't be unlocked and used. Open Keychain Access (in the "Utilities" folder), click "Show Keychains" from the bottom left of the window, and choose "Delete Keychain login" from the "File" menu. Then "Delete References & Files" when asked, leaving the account ready for use once again.

Control Software Update

It's the middle of a sleepy summer afternoon, when suddenly that dual-T1 you fought so hard for feels like dial-up. Apple's released another OS update, and now each and every Macintosh in the company is trying to suck down several hundred megabytes of "improved performance and stability". To make matters worse, this is brand-new software, untested in your environment and released just minutes before. If it breaks essential workflow or impacts network functionality, there's no uninstall or roll-back feature built into OS X.

In Open Directory installations, managed clients can be configured to use a local server to download and install only updates you've approved. Without a directory server, though, it's still possible to take advantage of this functionality, reserving all that bandwidth and protecting the integrity of your install base. All it takes is your existing OS X Server and a little knowledge of the command line.

Deploying the Software Update service:

To get some control over the Software Update process, the first step is to configure and enable the service locally. Open the Server Admin tool on your OS X Server (or pointed at your server if you work remotely), and select Software Update from the list of services along the left hand side of the window. Select "Settings" from the choices at the bottom left of the right hand panel, then "General" from the choices at the top center. This will present the Software Update configuration options.

Uncheck the boxes to "Automatically mirror updates from Apple" and "Automatically enable mirrored updates". This will allow you to decide on a case-by-case basis which updates are available to your machines. You may wish to regulate the amount of bandwidth used for updates on your local network, in which case simply check this box and set your preferred limit. Leopard Server even contains an option to automatically purge unused and legacy updates. Save your settings, then start the service with the enormous green button in the toolbar.

Now select the "Updates" pane. Click the "Check Now" button to receive the update listings, then choose which updates you'd like to mirror and which you'd like to enable your client machines to download and install. If you aren't sure which software to offer, you can always get updates manually at the Apple Support Downloads page and test them prior to deployment.

Assigning a local Software Update server:

Once your local server is offering updates, it's simply a matter of directing your workstations to use it. This makes very little sense for medium to large sized installations, which can utilize Open Directory managed preferences instead, but can be a valuable tool for administrators with just a small number of Macintoshes on a larger network. On each machine, open the Terminal as an administrative user and type:

defaults write /Library/Preferences/com.apple.SoftwareUpdate \
CatalogURL "SERVER-URL"

When you do so, replace SERVER-URL with the catalog URL of the local server, so that if your server's name is xserve.example.com, the SERVER-URL would be http://xserve.example.com:8088/.

With very little administrative work, users can now download and install approved updates from your server using the graphical Software Update tool. When you run Software Update from the Apple menu (though not the System Preferences), the name of your local update server should now appear in the menu bar above.

Triggering the Software Update process:

Finally, some administrators may wish to take this process one step further, controlling when updates are applied to each machine. This requires a deeper level of knowledge than one short article can cover, but is included here for those who wish to manage the update process beginning to end.

While updates can't be "pushed" to clients, it is possible to initiate updates using the softwareupdate command. In these circumstances, you'll first want to disable "Check for updates" under System Preferences in the Apple menu, or remove the Preference pane at /System/Library/PreferencePanes/SoftwareUpdate.prefPane/ entirely. Then you'll need to set the update preferences for the root user on each machine, replacing SERVER-URL as you did above:

defaults write com.apple.SoftwareUpdate CatalogURL "SERVER-URL"

Once this is in place, any available updates from your server can be installed on client machines from the command line:

sudo softwareupdate --install --all

You can accomplish this by logging into each machine individually using SSH, as a scheduled task preformed on a list of computers using the "Send UNIX Command" feature in Apple Remote Desktop, or even as a periodic script run out of launchd.

If you take this more advanced route, be sure to run the script at a time when the machines won't be in use, and provide a mechanism to restart after the update process.

Now for a small additional investment of time, you can manage the entire Software Update process beginning to end, freeing up your internet connection and preventing update-related failures in the future.

Secure Finder Permissions

File permissions are something systems administrators deal with every day. Usually when somebody can't read something on the server, and they need you to figure out why. In multi-user environments, however, what people can't read is often as important as what they can, and by default the Mac OS X Finder may allow people to read far more than your users expect.

A complex explanation of Unix permissions:

In cross-platform deployments, permissions may most often be Windows-style ACLs (access control lists), allowing a wide variety of context-sensitive settings but requiring a degree of administrative overhead to set up and maintain. On native Mac OS X systems, you'll most likely be dealing with POSIX-style permissions (also known as Unix permissions) which define file access as granted to the owner, the group, and others. This information is available for every file and folder in the Finder by highlighting an item and choosing "Get Info" in the "File" menu, then selecting "Ownership and Permissions" in the window that appears.

The underlying Unix operating system keeps track of those file permissions as numeric values, where 4 represents read, 2 represents write, and 1 represents execute (which the Finder doesn't report). These values are additive, so that a file which allows read and write access to it's owner and read-only access to it's group and others is denoted as 644, with the 6 being the sum of 4 for read and 2 for write. For a directory these read and write permissions are denoted as 755 (without execute permissions a user is unable to interact with or even list directory contents, so an additional 1 is added to each position). It's these numeric values that are used by Unix commands like chown and chmod, which change ownership and permissions mode respectively.

When you create a new file the default permissions are defined by a value called the umask. This value is subtracted from 666 for regular files (and 777 for directories) to determine their access privileges. So when creating a new folder, a umask of 022 would yield permissions of 755, allowing the owner to both read and write enclosed files while the group and others are able to read them. Unfortunately, these are the settings used by the Finder in a new OS X installation.

A simple way to improve Finder security:

By default, the Finder creates folders with permissions that allow read access to anyone who can log in to your machine. This isn't a problem if users only save files in the pre-existing folders in their home directory (like Documents), as their permissions already prevent access by anyone but the user.

When users create additional directories, however, the documents stored inside them can be accessed by other users on that computer (or in the case of servers and when file-sharing is enabled, by anyone on the network). This is seldom the behavior that users expect, and in many settings it can present a serious security problem.

The easy way to solve this issue is to adjust the Finder's umask settings by creating a new preferences file on the command line. While logged in as an administrative user, open the Terminal and type:

defaults write /Library/Preferences/com.apple.finder \
umask -int 077

On their next login, users who create new folders in the Finder will have their permissions set automatically to 700 -- allowing them to read and write the contents but preventing access by any other users entirely.