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.

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. Login Window can easily be configured to lock all users out of the machine, for instance, so it’s best to have a strategy for each service individually.

There’s also 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.

With this approach, you can get some granular control over which services are available to which individuals, improving your security while diminishing your workload.

Listening For Syslog Data:

Like all Unix systems, Mac OS X logs it’s system activity through syslogd, the system logging daemon. This facility keeps track of all the system activity specified in /etc/syslog.conf, which details the kind of information to log (based on its process of origin) and its level of priority (set by its parent process). This system is well documented by simply typing “man syslog” at the command line. What isn’t so easy to find is how to configure OS X clients to send this data to a central collection server for analysis.

The secret is hidden in /System/Library/LaunchDaemons/com.apple.syslogd.plist. The last item in the file is a key named NetworkListener, and by removing the comment characters around it you can tell your Mac server to listen for any and all logging information sent to it via UDP port 514. Once that’s done, you’ll need to restart the syslog mechanism by opening the Terminal and typing:

sudo launchctl unload \
/System/Library/LaunchDaemons/com.apple.syslogd.plist
sudo launchctl load \
/System/Library/LaunchDaemons/com.apple.syslogd.plist

With syslogd restarted, your server can now receive and store remote logging data from Macintosh clients, networking devices, and other Unix-compatible systems.

Sending Remote Syslog Data:

Now you’ve got a brand new syslog server. It’s listening, but nothing’s talking to it yet. For that, we’ll need to edit /etc/syslog.conf on your client machines, telling them what (and where) to report.

Open the file in any text editor, and you’ll see the following format on the very first line:

auth.info;authpriv.*;remoteauth.crit /var/log/secure.log

On the left side are a series of “selectors”, each separated by a semi-colon. Each selector is made up of a “facility” (before the period), which indicates the category being logged to, and a “level” (after the period), which indicates the level of importance that a message from that category needs to reach before it’s logged. An asterisk acts as a wildcard, including any possible facility or level.

On the right side is an “action”, preformed when syslogd receives a message matching the specified selector. This is most often expressed as a local log file, but can also be another machine listening for syslog data.

So if you wanted to log every possible message to the syslog server, you could simply add the following line (replacing server.example.com with the name of your local server):

*.* @server.example.com

That would send all that messages from any facility at any level of priority to your new syslog server. That configuration’s fine for testing a single machine, but unless your goal is to completely flood your local network with logging traffic, you’ll need to narrow down your selectors significantly before you push your revised file out to all your client machines.

Once you determine what information is important to your organization, you can build a custom syslog.conf file to install across your whole network, and begin collecting system log information for all your machines.

Recommended Reading: For in-depth information on configuring remote logging, check the manpages for syslogd, syslog, syslog.conf, and logger.

Configuring Secondary DNS:

Now that you’ve got a functioning DNS server inside your network, the next thing to do is consider what happens if that server is interrupted. Once your internal DNS becomes the center of your network, it’s hard to make an argument against the importance of providing redundancy. Unless you expect your main server will never go down for even a second, you’ll want a backup plan.

Fortunately, a second OS X Server can act as a secondary DNS source with little configuration. This secondary server will provide the same information as the primary (synchronized periodically to catch any changes), and

First, on the primary server you’ve just configured, go back to the “Zones” pane in the “DNS” settings of Server Admin and highlight your domain. Then further down the window, check the box marked “Allows Zone Transfer”. With the default DNS settings Apple provides, other servers within your network should now be able to inherit and host the zone file for this domain.

Now, on the server that will act as your secondary DNS, open Server Admin, and browse to the same “Zones” pane. This should be empty on an unconfigured machine. Click the “Add Zone” button at the middle of the window, and select “Add Secondary Zone (Slave)”. Enter the domain you’ll be handling secondary DNS for, and the IP address of your primary DNS server. Save, then start the DNS server.

DNS Client Configuration:

In order to get the domain information your new servers provide, client machines need to be told where to look. And since the DNS servers at your ISP likely see an external server as authoritative for your domain, you’ll need to make sure your internal clients (including your server itself) look to the internal server first.

For a single machine, this is as easy as opening the “Network” pane of the System Preferences application and replacing the current setting with your DNS server’s IP. When you’ve got to make this change on a couple hundred machines, though, even a minute each will make for hours of work. In most cases, this means some kind of network settings deployment.

If you’re already utilizing DHCP (that’s Dynamic Host Configuration Protocol) to distribute IPs on your LAN, it makes sense to use the same mechanism to distribute DNS settings as well. If, instead, your network setup somehow precludes this, Mac OS X has an easy way to push DNS settings out to your machines. Using Apple Remote Dektop’s “Send UNIX Command” feature, just select your new client machines and enter:

networksetup -setdnsservers "NETWORKSERVICE" PRIMARY SECONDARY

In this setup, NETWORKSERVICE describes the network interface on the client machine. It’s typically “Ethernet 1″ (or just “Ethernet” for laptops), but you may wish to run networksetup -listallnetworkservices if you’ve got an unusual configuration, just to see what options are available to you. PRIMARY and SECONDARY are simply the IPs for your new DNS server(s).

This will reset the servers your client machines look to for DNS information, and allow them to find domain information specific to your internal network.

Recommended Reading: For a complete understanding of the BIND software that runs Mac OS X DNS, there isn’t a more definitive text than the venerable DNS and BIND, now in it’s fifth edition by Paul Albitz and Cricket Liu.

Before we begin, a quick word of warning: If you don’t already understand DNS, you really shouldn’t be allowed to make changes to it. Nothing will screw up your day, or your employment situation, faster than taking your whole network down. So if you’ve found yourself in the unenviable position of having to set up DNS without experience or guidance, do yourself a favor and practice the procedure on a test network first. The job you save could be your own.

Basic DNS Configuration:

To start your setup, select the server you’d like to configure, and choose “DNS” from the list of available services in Server Admin. Choose “Zones” from the toolbar, then press the “Add Zone” button in the center of the window and select “Add Primary Zone”. An entry for the example.com zone will appear at the top of the window.

At this point, you’ll be tempted to hit “Save” before proceeding, but doing so triggers a terrible bug in some versions of Leopard that will break the configuration file that Server Admin edits (leaving it to permanently believe example.com is in fact your real domain). Instead, immediately change the “Primary Zone Name” to the name of your own domain, followed by a period to indicate that the entry is “fully-qualified”. A fully-qualified domain name is one that doesn’t require the host’s domain to be appended to it.

You’ll also want to change the name and IP of the first machine record (also known as an A record) to those of the server you’re configuring, this time without a period after it to indicate that it’s part of the larger domain.

You’ll then need to add what’s called an MX record, indicating the host (or hosts) to which mail is sent for your domain. Do so by clinking the plus symbol beneath the “Mail Exchangers” field, and input each hostname followed by it’s priority (traditionally 10 for the first mail server, 20 for the second). Then, and only then, will you want to save your work.

Now that there’s a record of your domain, and one of its primary server, you’ll need to tell client machines where to look for information on other domains. Click “Settings” in the toolbar at the top of the window, then click the plus symbol beneath the section marked “Forwarder IP Addresses”. Add the IP addresses of the DNS servers at your internet service provider (those pictured are mine from Comcast here in Seattle), then hit “Save” once more. This will allow your client machines to receive DNS information for the remainder of the internet.

If your domain exists only within your own network, you’re ready to click “Start DNS” and configure your client machines to use your new DNS server. If your company has any kind of internet presence, however, you’ve got a little more work ahead of you.

Split DNS Configuration:

When DNS was originally designed, every machine on the internet used a static IP, and address translation from internal to external networks didn’t exist. Twenty-five years later, the internet is a very different place, and most corporate servers are well protected from it. This can create a problem when you try to use the same domain name both inside your own network and outside on the internet, as local users won’t be able to find externally hosted services like email or websites.

The most common solution is configuring a “split” DNS, where servers both inside and outside your network control customized resolution of your domain for only those machines that can see them. This would, were I hosting my own email for instance, let internet machines find mail.makemacwork.com at an external IP of 64.13.192.203 routed through my firewall, while still pointing internal clients at 192.168.0.250 on their local network. In this case, both IPs would be the same machine, but with the external record on the DNS server at my ISP and the internal record on my own internal server.

Even if you’re not hosting any internet-available services, though, your internal machines will see your new DNS server as the authoritative source of information on your domain. So if you’ve outsourced any kind of hosting with the same domain name, you’ll need to put that information in your internal zone record as well.

Go back to “Zones” in the Server Admin toolbar, highlight your domain, and choose “Add Machine (A)” again from the “Add Record” button. Repeat this until each external server has it’s own listing. If more than one hostname resolves to the same IP, all but one should be configured using the “Add Alias (CNAME)” option instead.

With all the hostnames on your domain configured, you can finally start the DNS service.

Next week in part two, we’ll look at configuring your client machines to find your new DNS server, and setting up a secondary DNS server for redundancy.

Recommended Reading: For a simple overview of How Domain Name Servers Work, there’s a great (if slightly web-centric) synopsis at the appropriately named “How Stuff Works”.

So imagine the surprise when you’ve configured and started the service, but your client machines simply won’t connect. In fact, they complain there’s a username or password error, when the username and password work fine for other services. Check the logs in Server Admin, and all you’ll find is an ominous message:

The selected logfile does not exist.

In some Leopard Server installations, the iCal Server logfiles aren’t ever created properly. The result is that the server process starts, but doesn’t do anything because it has no place to log its actions. It’s the sort of problem you’d usually figure out by digging through log files, but because they don’t exist, iCal Server just sits there dumbly, unable to provide any clues.

The easy way to stop this serpent from eating its own tail is to create and properly permission the files, then restart the iCal service. Open the Terminal, and type:

cd /var/log/caldavd/
sudo touch access.log error.log
sudo chmod 640 access.log
sudo chmod 644 error.log

The touch command creates the required logs, while chmod is used to set their permissions. With the log files now in their expected place, client machines should have no trouble connecting to iCal Server.

The most basic method to controlling applications is to use the defaults command to write directly to the application preference list, as we’ve demonstrated repeatedly. This approach works fine for some settings, but there’s a problem: It permanently disables lockable preferences only for standard users (since administrative users can just unlock them) and most application preferences can’t be locked at all (so users can change them any time they like).

For any application that uses Apple’s .plist format, there’s a far better way to manage preferences across your network. A properly configured Open Directory domain can use MCX (Managed Client for OS X) settings to control any available user setting.

In Workgroup Manager, select the group for whom you’d like to manage an application’s preferences (in our example, that group includes all of our Macintosh users). First select “Preferences” from the toolbar above, then the “Details” tab on the right. Using the plus button, browse to the preferences file you’d like to control and click “Add”, selecting to manage imported preferences “Always” from the drop-down menu.

Double-click the preference name, and an editing window will open. Typically, you’ll wind up deleting the most of existing preferences from the editing window, keeping (or adding) only those you wish to manage.

Using this approach, you can take fine-grained control of most user-level settings, including managing application preferences more effectively. The result is preference settings that apply to standard and administrative users alike, controlled centrally through Open Directory even for third-party applications.

There are a variety of reasons your network Time Machine setup might start excluding certain machines. Rather than address them each individually, the following is a general troubleshooting approach for the full gamut of issues. Follow these guidelines, and your Time Machine setup should be working again in no time.

First, turn off Time Machine on the misbehaving client machine. With the large, decorative switch now in the “off” position, remove the preferences file at Library/Preferences/com.apple.TimeMachine.plist. If you’re dealing with a corrupt preference file, that should resolve the issue immediately.

Next, remove the Time Machine “cookie” from your network share. These invisible files are named with a period, followed by the MAC address (also called the ethernet id) of the “Ethernet 1″ interface on each client machine (not necessarily the network interface you’re actually using). If the machine has a primary MAC address of a1:b2:c3:d4:e5:f6, then you’re looking for a file called .a1b2c3d4e5f6 at the root of the share. Get rid of it, and any identification issues with your Time Machine client should disappear.

Finally, you’ll need to reintroduce your client machine to the Time Machine server. In order to access your share every hour, Time Machine stores authentication data in a keychain when it’s first configured. Delete all references to your Time Machine server from the “System” keychain (most simply with Keychain Access in the Utility folder). Once no memory of the name or IP of the server remains, you can reconfigure Time Machine to back up to your server again.

These steps won’t solve every Time Machine server problem, but this quick checklist can often get your users backing up again, and get you back to working on larger problems.

Recommended Reading: For more information about common backup problems, take a look at Apple’s own Knowledge Base on troubleshooting Time Machine issues.

The issues inherit in a Leopard Server upgrade can be addressed quickly and easily if you know what to look for. With a little advance preparation, and this article as a checklist, you can make sure the process is safe and successful for most OS X installations.

You’ll want to have checked in advance that any third-party applications you need run on Leopard, and you’ll definitely need a known-good backup in case something goes awry. Now let’s get started.

Document Server Settings:

The big problem with the Leopard upgrade isn’t that it loses data. In fact, it’s the opposite, with the newly upgraded volume turning on new services, adding duplicate users, or even sharing out random (and sometimes private) directories. The most important part of the process, then, is to document all your Server Admin settings prior to upgrade. You’ll want to have notes (or screenshots) detailing all your DNS zones, web sites, firewall configuration, etc. If your team doesn’t already document all their server settings in a change log, now’s the time to catch up on the paperwork.

Archive Open Directory:

The next step you’ll want to take is to export all your Open Directory settings. This includes not just your users and groups, their passwords, their managed preferences, but also all your Kerberos and Password Server data. After you’ve upgraded your server, you’ll restore this information to insure nothing’s been corrupted in the upgrade process.

You can do this easily by using the “Archive” pane in the “Open Directory” options of Server Admin. Simply click the “Choose…” button to set the location the collected data should be saved to, then click the “Archive…” button to set the name and password for the disk image that’s created. Type very carefully, and since the password isn’t verified before the image is created, test that you can open it before you proceed.

Install Leopard Server:

With your preparations made, you can run the Leopard Server install normally. You’ll be asked to enter your new Leopard serial number, but otherwise the process shouldn’t require any configuration. The upgrade takes about a half hour on the current generation of XServe, and you can fill the time by downloading any recent updates you plan on installing. When your server reboots, it’ll likely have a host of services you don’t want turned on, so it’s best to restart it with the network cable unplugged.

Reconfigure Services:

If all went well (or at least as expected), you should now have a fully functional Leopard Server. Maybe a little too functional, even. Leopard tends to turn on a bunch of undesired services during the upgrade process. Was your XServe an email or NFS server previously? There’s a good chance it might be now.

Open Server Admin, and select the your local machine from the left column. Now take a good, hard look at the services listed below it. Turn off the services you weren’t running prior to upgrade, then check your remaining service settings to make sure nothing unexpected has been added or changed. If you don’t need Apache 1.3, it’s a good time to upgrade to version 2.2 in the Web options as well. Now it’s time to plug back in the network cable and wrap up the job.

Restore Open Directory:

Now that the rest of the damage has been undone, you’ll want to clean up your account information. If your server remained an OD master through this process, you’re in luck. Otherwise, you’ll need to promote it in the “Settings” pane of the Open Directory options, then return to the “Archive” pane.

Choose the archive disk image you made earlier, and click “Restore…” to return your Open Directory domain to it’s pre-upgrade state. Once you’ve confirmed Open Directory accounts work locally, test each of the services you’re offering over the network as well, making sure that everything functions as it did prior to the upgrade process.

And voila! While not exactly fast or automatic, you should now have a newly upgraded and properly functioning Leopard Server. Now you can go find out what’s going to break when you upgrade your client machines…

Recommended Reading: While it may contradict some real-world experience, Apple nonetheless publishes an excellent guide on Upgrading and Migrating 10.5, essential reading for anyone planning a complex upgrade to Leopard Server.

As much time as this saves, however, you’re still cloning one machine at a time. What if you have tens or even hundreds of machines in your organization? Fortunately, there’s a built-in system to handle that as well. All you have to do is deploy NetInstall.

Creating NetInstall Images:

Ten years ago, when Apple’s administrative tools were aimed more squarely at academia, schools began using NetBoot to deploy their lab machines. By booting workstations off a central server-side system image, machines could run custom configurations that reset cleanly for each user. NetInstall was built on that same technology, allowing your servers to host similar custom images, but install them over the network onto each machine’s local disk.

Creating that image is now done with the System Image Utility, found on OS X Server in the /Applications/Server directory. While an image can be built directly from the OS X installation DVD, they’re hard to customize and seldom up-to-date. You’re better off creating a customized installation on an external drive (or saved as a disk image), then mounting it on your server. While Leopard theoretically allows network installation onto both Intel and PowerPC hardware from the same image, preparing separate images can save time and frustration in the long run.

When you’re ready, launch System Image Utility, and in the “Create an Image” window select “NetInstall Image”. Click “Continue”, then on the next screen enter a name and description of the image you’re preparing. For basic deployment just click “Create”, and save the image in the default location of /Library/NetBoot/NetBootSP0. For more complex configurations, click “Customize” to add post-install scripts, filtering by hardware type, or allow more client-side installation options.

You may want to go take lunch while your image builds, but when it’s done you can repeat the process for each image you’ll need to deploy over your network.

Configuring The NetBoot Service:

Once your images are prepared, the next step is to configure NetInstall on your network. Launch Server Admin and select the NetBoot service from the left column. Click the “Settings” icon in the toolbar, then choose the “General” pane. Here you’ll choose the network interface for NetInstall to run on (typically Ethernet 1), and the volume to store images and client data (the system array, in this example, though you may prefer another volume if you’re mixing NetBoot and NetInstall).

Now move to the “Images” pane. Check “default” if you’ve got a single image, or there’s an image you’d like to force if one isn’t specified. Next check “enable” for each of the images you’re planning to deploy, and choose the protocol over which you’ll offer them.

The NetBoot service can run over either HTTP or NFS. Given that most companies filter HTTP traffic, or engage some kind of web proxy for port 80, utilizing NFS is usually the better choice. In these circumstances, be sure to allow traffic over port 1049 on your internal network.

With these options set, click “Save”, then click “Start NetBoot” to take the service live.

Configuring Clients For NetInstall:

Once NetInstall is running happily on your network, all that’s left is to boot your client machines. If you’re only offering one image (and you’ve marked it as the “default” in the “Images” pane), you can simply restart your machines while holding down the “n” key. If you’re offering multiple NetInstall images, open System Preferences on your client machines, and choose the appropriate image to install from the “Startup Disk” pane. When you restart, the computer will boot into the installer automatically. You’ll need each computer connected to the network during this procedure, and you’ll save yourself a world of trouble if they’re using ethernet rather than wireless.

That’s all there is to it. Allowing you to save hours, if not days, of work on every rollout, NetInstall is one of the most powerful, and easiest, tricks up the Macintosh administrator’s sleeve.

Recommended Reading: There’s no better, or more extensive, explanation of BSDP (the protocol on which NetInstall is built) than the amazing How NetBoot Works by the even more amazing Mike Bombich.

First, select a group from your Open Directory domain in the “Accounts” pane of Workgroup Manager. Then click the “Group Folders” button, and select a share point under which you’d like the group folders to appear. By default, Mac OS X uses /Groups, which comes pre-configured as a share on a new installation. Next, you’ll need to choose an owner for your new folder. Your directory administrator account makes the most sense here, as you’ll be using the group (not owner) attribute to determine access permissions. With these options configured, hit “Save”.

For whatever reason, you can’t actually use Workgroup Manager to create the folder you’ve just configured (as you can with user’s home directories). Instead, you’ll need to open the Terminal and type:

sudo CreateGroupFolder

This will build a folder for every group assigned a share point, not just the most recent, so if you’re deploying multiple group folders it makes sense to run this command after they’ve all been set up in Workgroup Manager. This also sets the permissions for each group folder as read-only to the group itself, and only read-write to the individual user defined as it’s owner. To remedy this in the Terminal, type the following, replacing PATH-TO-FOLDER with the full Unix path to each group folder:

cd PATH-TO-FOLDER
sudo chmod 770 Documents/ Library/

This will allow access by workgroups to their own group folders with a simple permissions scheme. For more complex sharing setups, you may wish to add an access control list as well, in the sharing pane of Server Admin.

Finally, if you’re utilizing managed preferences in an Open Directory environment, you can set group folders to automatically mount when a member of that group logs in to their workstation. Moving to the “Preferences” pane of Workgroup Manager, click the “Login” icon, then the Items button on the far right. Check “Mount share point with user’s name and password” and “Add group share point”, then click “Apply Now”.

Not only can each workgroup have their own private file share, but users will connect to those shares automatically when logging in to their Open Directory account.