Документ взят из кэша поисковой машины. Адрес оригинального документа : http://hea-www.harvard.edu/~fine/OSX/current_setup.html
Дата изменения: Unknown
Дата индексирования: Sun Apr 10 08:02:40 2016
Кодировка:

Поисковые слова: mercury
Our Current Supported Mac Setup Novermber 2008 - WORK IN PROGRESS

Our Current Supported Mac Setup

Installation

We are currently using the (just announced end-of-life) Netrestore software to install our systems. We build an image with all of our customizations, and run a fairly straightforward netrestore installation.

We use the machine_specific_data.csv file to provide identity information at boot time. This turns out not to be such a hard step, as we have to enter all of this information somewhere anyway. I've just set up scripts so that we enter it once, into this file, and everything is automated. The file is installed into the netrestore install image, and it is also read and used to tell netboot filters that all the hosts listed there are ok to netboot.

We've made a few minor additions through scripting to the netrestore. We run my warranty script to fill in the Apple Remote Desktop Text1 information field with the warranty expiration date. We've also added a script which sets the hostame, as the this is not set by the script that sets the computer name.

Home Directories

We automount our NFS-based home directories. Users use the same home directory for logging into all platforms including OS X. This is set up by turning on NIS in the Directory Utility application. It's quick to set up and mostly works fine.

I've seen many reports out on that InterWeb thingy that they have slow NFS performance. I can only report that in a fairly standard setup, I'm not seeing it in simple tests, and the users aren't complaining. A quick test copying a 13 Meg file both in and out of my home directory (served by a NetApp) shows that it completes in about 1.2 seconds, which is about as fast as anyone is going to see on a 100 Mbit connection. Another test copied a 282 Meg file in 26 seconds, this time from a Linux server to a local hard drive. Again, this is so close to maximum that no one could complain.

We have other automounted directories besides home directories, for various projects, and data directories (lots of data in astrophysics). Some served by Linux and some by Solaris. There are some problems with default settings for reserved ports. Things are fine on Suns and NetApps (in our configurations at least; I can't really tell you without looking if they're actually the default). But the default on Linux servers is to require a reserved port, while the default on OS X is to not use a reserved port, so you get "Operation not permitted" (note that this is not the same as "Permission Denied").

You can fix this problem on either end. On the Mac end, edit /etc/autofs.conf, and add ",resvport" to the AUTOMOUNTD_MNTOPTS.

Software

We use automounted directories for /sw and /opt/local, so we can install fink and macports packages in one place and have them show up everywhere. There's one machine with permission to write there, and that's where we do the builds. This seems to work fine. However, we also wanted to have a central repository for clickable applications so we don't have to install on every server. This is more of a problem, because Finder is a busybody, sticking it's nose in business it shouldn't. Simply symlinking to an autmounted directory failed abysmally. Finder would know there's nothing there and wouldn't even try to mount it. It might work if it's mounted already, but then when that automount unmounted, it would leave Finder even more confused. The Finder knows too much about what's going on underneath, primarily because Apple can't let go of old ideas.

To make Finder happy, we don't automount the applications directory with NIS maps. We use fstab, and we mount it under /Network, where Finder expects things to be mounted. Then a symlink from /Applications/whatever to /Network/Applications makes it extra easy for our users. Of course there's still a Finder bug where the contents don't always show up until you click a second time, but at least it's mostly consistent so users can get used to it.

Maintainence and Setup

We use a script called "fix-setup" which can do most of the system setup on a new install, and fix setups on machines that are out of date with our current configuration, or perhaps that had some file change as a result of a software update.

fix-setup lives in a directory with a bunch of files to be installed, and it knows what the permissions and ownership should be on everything. It only changes files if they need to be changed, comparing contents, and permissions.

Specific hosts can have their own custom copy of a file, by making a subdirectory with the hostname, and putting the file in there. You can grab a blank copy of the script here. Edit one line near the top, and add your setup commands at the bottom.

Here's our current list of files we change, and why:

/usr/libexec/automountd We install our own version to fix a bug with automounting replicated filesystems.
/usr/libexec/ntpd-wrapper We don't use the authentication option, and we initialize to a local server
/etc/ntp.conf We use multicast ntp. Works fine, but something keeps sticking apple back in as a time server every now and then.
/etc/auto_master Our Mac installation has some custom maps not used by our Solaris and Linux
/etc/auto_opt This is a custom map just for the Macs. It's for MacPorts.
/etc/fstab This mounts our centralized application directory into /Network/Applications
/etc/autofs.conf Set the resvport option so that aotomounting plays nice with the systems that expect that (Linux).
/etc/hostconfig I think the change we make here is MAILSERVER=-YES-
/etc/ssh_config, sshd_config Local changes to match our other systems
/etc/postfix/main.cf Local mail configuration, so command-line mail works properly.
/etc/pam.d/su Allow our local admin group to su straight to root. We haven't resolved differences in groups between Solaris, Linux, and OS X. It's a somewhat daunting problem at this point, but we'll get to it.
/etc/paths We take out the sbin directories from general users.
/etc/paths.d/*, /etc/manpaths.d/* We add f_MacPorts and t_Fink files into these directories to add appropriate paths and manpaths for macports and fink. The f_ and the t_ are arbitrary letters to get the path elements in the order we want (and after the X11 that's already in that directory).


More Mac OS X Stuff


Tom Fine's Home Send Me Email