This is part two in a series on my experiences in setting up an
Xserve for classroom use. It's not
intended as a tutorial or abbreviated manual; as a first-timer,
undoubtedly there are things that I did which can be done more
efficiently. If you want more information, start by reading the manual
- there are hundreds of pages of documentation on how to use OS X
Server (the OS) and the Xserve (the machine).
I think there are still things worth reading here for folks
considering purchasing the Xserve and OS X, because some fraction
of the customer base is going to be a person who has never set up a
"real" server before, like myself.
Most of this installment is about setting up OS X Server. This
can be done on any machine that runs OS X, but it is obvious to me
comparing OS X 10.2 on a G3 and OS X Server 10.2 on an Xserve
that you're better off with a G4 if you have one. You could install it
on a G4 tower, for
example. The Xserve is just a configuration that gives you more drive
bays, two ethernet ports, etc.
Why use an Xserve in the classroom? It's primarily an issue of
capacity. We are planning to have hundreds of student accounts using
many GB of storage eventually; so we'll grow into it at some point.
Xserve Considerations
I mentioned last time that the
Xserve is not meant as a desktop computer. That's true enough. It's not
designed to be put on a desk. It's not designed to have things stacked
on it.
I thought I'd be in good stead when I discovered that the cabinet on
my lecture table (which has internal power and ethernet ports) let the
Xserve fit inside. It fits, all right; the problem is the heat. Two
powerful (and loud) fans pump air through the Xserve to keep it cool.
However, if the air supply is just hot air trapped in the cabinet, the
Xserve will begin to overheat. I discovered this when I started the
Server Monitor application. It provides a number of statistics about
the server including processor load and temperature - it even graphs
temperature over times so you can see a spike in temperature when the
air conditioning shuts off, for example.
Inside a closed cabinet, the Xserve will overheat. With the
cabinet doors open, it's loud enough that I can't hear students ask
questions - seems like these days many of them are timidly soft-spoken
beyond reason - or maybe I'm just getting old.
Anyway, the thing is meant to be mounted in a rack. We have a rack.
Directly downstairs beneath my room, there's a nice rack holding the
switches for our wing of the school. Problem is, (a) it's downstairs
and (b) they leave the door wide open all the time because they also
store junk in the room. At least I can lock my cabinet.
Guess I'll have to install a ventilation fan in the cabinet - or put
the server elsewhere.
Setting up OS X Server
Setting up OS X Server is not like setting up small group file
sharing on a consumer Mac, or even like setting up AppleShare IP, the
server software Apple produced for OS 9 and below. It's another
level of complexity beyond that, undoubtedly due to the fact that
OS X Server is merely a set of user interface controls for the
Unix-based services you are controlling. What it amounts to in use is
that the machine looks and feels like an OS X user machine -
complete with eye candy - but several additional applications allow you
to set up, configure, and manage server functions such as file sharing,
booting from a network volume, email and Web hosting services,
passwords, and so on.
So far, I've concentrated on just two tasks: setting up shared
folders for student work and creating a uniform login and standardized
privileges setup for my computers. Since I'm on a LAN behind a
firewall, there's not much sense in setting up Web services or
email.
If you followed the setup sequence and answered all the questions as
you set up the Xserve (or any OS X Server machine) for the first
time, you will need to get familiar with several applications in order
to get started. And each time you launch one, you will have to log in
to the application using your Admin settings. One thing: Since I don't
have a fixed IP address for my server and my clients are not OS X
machines, I opted to enable AppleTalk. If I expand beyond a classroom
set of machines and get some OS X clients, I might want to revisit
that decision. For now, go with what you know.
The first application is the Workgroup Manager. This program is sort
of like Users and Groups and File Sharing on a consumer machine. It
lets you define users, give them passwords, cluster them into
workgroups, and assign privileges to the workgroups. You also set up
privileges for individual shared folders (called Share Points - a
generic term that includes folders and volumes). If all you want to do
is set up a server volume that can be logged into with the Chooser,
then this is all you need to figure out.
- The primary thing that is not obvious during setup is that the
access privileges of folders are managed on a group basis, not on an
individual basis. Everyone must be in a group in order to have access
to a folder. The admin is automatically assigned to the admin
group.
The second application you will need to use is the Macintosh
Manager. This program lets you control login settings, application
access, desktop protection, and so on. It is required for using
OS 8 and 9 machines connected to your server - if you have a mixed
lab of old and new, like I do, you'll need to use this program. The
tricky thing here is that you must bring users and groups from the
Workgroup Manager into this application to allow them to use the
software, a process which is not obvious (at least to me).
Eventually, I resorted to the manual and discovered you have to drag
users from the Workgroup Manager window to the Macintosh Manager window
to assign them to login groups. I remember figuring out a similar thing
in ASIP; whereas my intuition said I would be looking for a dialog box
or check list or menu item, the only way to add users to a login group
was to drag them from one window to another. It seems like that would
be a pain if you had to do hundreds of them; obviously I need to read
more of the manual.
The Macintosh manager lets you control which applications a user can
access. Think of it as a master control panel for Multiple Users (which
is exactly what it is). In fact, on an OS 8.6 machine and higher, you
can activate the server functions simply by opening Multiple Users,
clicking on the "Other" tab, and selecting "Use Macintosh Manager."
On an OS 8.1 machine, Multiple Users didn't exist, but the
technology has been retrofitted and can be installed with the Macintosh
Manager CD. The catch is that it took me two weeks to figure out -
thanks to a couple of readers who corresponded with me on this point
along the way - is that if you use the built-in Multiple Users control
panel on OS 8.6 to 9.1, the users will be able to change their
password even if you have that function disabled on the server. If
you ask me, that sounds like a security flaw. Fortunately, installing
the included Macintosh Manager client on top of any machine from OS 8.1
and up will eliminate the loophole and prevent users from being able to
change their password.
Now it is a relatively simple matter to add a computer to the lab: I
have to register the computer with the Computers tab in Macintosh
manager, then install the client on the computer and turn it on. Presto
- another identical machine on the network. Now this isn't
Netboot; if the client computer doesn't have an application, this isn't
going to give it to them. But, interestingly enough, it does locate the
applications wherever they reside and provide correct aliases for them
in the "Items for User" folder upon login. So you don't even have to go
back and clean up the hard drives when you set it up. Sweet.
The only other significant issue I had to work through came early
on. When I first started up the Workgroup Manager, I got an error that
said, "You are working in a node which is not visible to the network,"
which I foolishly dismissed without trying to find out exactly what it
meant. What it meant was that you can make all the changes you want for
the local computer, but if they aren't set up for the network, they
won't be visible. It's sort of like playing with Multiple Users and
expecting to get Users and Groups type effects. You have to tell the
Workgroup Manager to look at the network via a little popup in the
lower left corner before you start assigning privileges,
passwords, and so on.
If you make changes to the Workgroup Manager setups, such as
changing privileges, I have noticed that sometimes these changes are
not enabled until you restart the server. I haven't done this as a test
to consistently define which changes require restart and which don't.
The point is that the software, which makes the system respond via a
GUI instead of command lines, doesn't tell you "changes take effect
when you restart." That seems odd to me; according to what I've read on
Slashdot and elsewhere, one of the big advantages of Unix-based servers
over Windows is that they don't need to be restarted every time you
make a change; just restart the services and the change is made while
the server's other services continue to run. But I'm not the best
person to ask about this; all I know is what I read on the Web.
One of the nicer features I'm taking advantage of with Macintosh
Manager is that I can automount server volumes. With access to system
level programs and the Apple Menu Items disabled, my student clients
now automatically get a shared group folder into which they deposit
work, enabling them to work on any machine in the room (including a
wireless laptop) without concern about remembering the last machine
they used. Also, the classroom printer is automatically set up as the
desktop printer du jour so they can't accidentally switch the printer
to a Color StyleWriter or something.
One other tip: Make sure you know the admin password or local
computer's password in case you have a dropped network connection or
the server is down. If the Multiple Users control panel cannot find the
server, it asks for one of these passwords to allow the machine to
finish starting up in its default "unlocked" mode.
There are still a million little things I haven't figured out; how
to import names and passwords into a configuration so I can give
individual students logins rapidly; how to create a drop box for turn
in that is read only - the function seems to be there for automatic
configuration, but I don't yet know how to turn it on; and something
has happened to make my Macintosh Manager declare that "an error has
been found in your database" when the program starts, but upon scanning
it, "no errors were found." I don't know how to clear that up yet.
But all in all, it's starting to make sense. I can see how a person
who thinks you need to have a degree in computer science to operate a
server would think that OS X Server is a piece of cake; coming
from the user direction, it's a significant challenge for an average
user - but not impossible to handle. The real tip I have for you is
this: Read the Friendly Manual. There's a quickstart guide, an
illustrated example that includes how to set up the Xserve for a
classroom (obviously Apple thinks the Xserve is targeted at education),
and hundreds of pages of instructions written in the clear, well-laid
out style we've always enjoyed as Apple users. Writing that manual must
have been a significant investment in developing OS X Server.
I'll put together another article about my experiences when I've
learned enough to have more to say.
is a longtime Mac user. He was using digital sensors on Apple II computers in the 1980's and has networked computers in his classroom since before the internet existed. In 2006 he was selected at the California Computer Using Educator's teacher of the year. His students have used NASA space probes and regularly participate in piloting new materials for NASA. He is the author of two books and numerous articles and scientific papers. He currently teaches astronomy and physics in California, where he lives with his twin sons, Jony and Ben.< And there's still a Mac G3 in his classroom which finds occasional use.
