Networking OS X Beta
Volume Number: 17
Issue Number: 2
Column Tag: Network Management
Networking the OS X Public Beta
By John C. Welch
How well does OS X fit into the networked world
In our last look at the OS X Public Beta, we did a general overview of the operating
system, and looked a little at networking, mostly at the settings in NetInfo Manager.
This time, we'll focus almost entirely on how the Public Beta fits in to other networks,
and connects to other Operating Systems.
One of the disadvantages to trying to really exercise the networking features of a beta
is the lack of documentation. This has long been one of the real problems with being a
Mac OS network administrator, lack of Apple documentation. Almost none of my
reliable resources for administering Mac OS networks come from Apple. Instead they
come from a host of web sites, Developer TechNotes, third-party books, and 16 years
of supporting Macs. For OS X, this needs to change. Yes, third parties will always be a
supplement to Apple, but I, and my colleagues in the administration field need to be
able to get a complete set of documentation to NetInfo, OS X and NFS, etc. from Apple. In
Apple's defense, the deal they have struck with FatBrain.com is a step in the right
direction, but as of yet, I have only seen developer documentation come out of it, and
Apple has always tried to be conscientious here. There needs to be a similar flood of
administration and other similar documentation, and it needs to start happening before
the full release, so that the day OS X goes into full release, I will have had access to the
documentation I need to begin implementing it that day. If I have to wait a month, 2
months, etc. then in addition to that delay, there will be another month or so delay
while I familiarize myself with the documentation, and figure out how I can use it to
set up Mac OS X for my network. Most of my fellow administrators will probably be
doing the same.
Luckily, for now, there is a decent amount of documentation from such sources as the
Omnigroup's mailing lists, and various web sites such as MacNN, etc. But that will not
be adequate for long, and with OS X, Apple can not rely on the Mac community to make
up for a lack of manufacturer - provided documentation. I don't think they will, but a
reminder can't hurt.
NetInfo
You cannot talk about networking OS X without delving into NetInfo. In fact, you cannot
talk about administering OS X without dealing with NetInfo. So what is NetInfo? Well,
according to Apple's Tech Info Library Article 60038:
"NetInfo is a hierarchical distributed database that is used to keep track of
administrative data in NeXTSTEP, OpenStep for Mach, and Mac OS X Server. It can
store information on user and group accounts, e-mail configurations, NFS (network
filesystem), printers, computers and other resources. Since this information is
stored in NetInfo these resources are easily configurable, and can easily be shared
over in a network environment.
In other words, NetInfo is how a Mac OS X administrator would maintain their OS X -
based network, both at the machine level, and at the network level. NetInfo is also a
hierarchal domain model, which, at it's simplest, means that you can have one network
that binds together many separate and even independent subnetworks, or subdomains
into one organized super-network. With this model you can have, theoretically and
unlimited number of subdomains in a root, or '/' domain, ('/' is the NetInfo indicator
of the root of all domains on a given NetInfo network.) The machine that is running the
/ domain is the domain controller. An example of this is shown in Figure 1.
Figure 1.
As you can see, the / domain, named Computers is the root domain. It has access to all
other hosts/computers in that domain. The next levels are subdomains: eng and mktg,
or in proper notation /eng and /mktg. These are both network domains, under the
control of /, but independent of each other. They also have hosts below them. Each of
the hosts in the /eng and /mktg domains is an individual computer, or local domain.
This local domain can sometimes cause confusion, but there's a reason for it. In many
cases, the permissions for a person on their individual computer may need to be
different than their permissions on the network. You may want this person to be able
to say, change some personal parameters such as screensaver settings on their local
machine, but not for the / domain controller. So by having a separate local domain for
each machine, you can differentiate between domain and local permissions. ( The
correct NetInfo terminology in our example would be that / is the parent for /eng and
/mktg, which are its children. The hosts in those domains are the children of /eng and
/mktg, and the grandchildren of /. I don't really like to use this terminology, as it can
get unwieldy quickly, so I go with domain and subdomain. Both work.)
Each domain controller, regardless of level has a NetInfo database that has various
information for that domain only, such as users, groups, machines in that domain,
services running, printers, etc. They also know who the domain controller above them
is. However, each of these domain controllers is separate from any other domain
controller at the same level. So, while I may have administrative permissions in /eng,
I may only be a normal user in /mktg. The / controller supercedes all subdomain
controllers, so if I have administrative privileges for the / domain, then I have them
in both /eng and /mktg.
This separation of domains is important. This way, a network admin can limit / admin
permissions to only those who absolutely need it, and give /eng admin privileges to
another person who needs them for that domain, yet not for /mktg. This allows for
easier maintenance of the subdomains, by allowing for smaller sizes, without making
them so independent as to be uncontrollable. This also allows for easier user
maintenance, as then you only need to enter user information in once. This is due to
NetInfo being able to replicate needed information to not only the subdomain
controllers, but to other computers that act as backup domain controllers. Domain
separation also allows for easier management of printers, users, or any other
resource that is a part of the domain.
Even on a standalone machine, NetInfo is what is running much of the basic functions of
the OS. Things like services, network settings, user settings, etc. If you look at NetInfo
Manager, you'll eventually find the results of almost any preference setting you can
imagine.
This is also where a lot of confusion regarding NetInfo starts. NetInfo Manager is not
designed to be a general use NetInfo editor. In other words, it's a good place to change
NetInfo settings, but not such a good place to create them from scratch. Ideally, NetInfo
settings are set and changed from other applications, such as the System Preferences
control panels for system settings, Multiple Users for users settings, Print Center for
printer settings and so on. In other words, it's a somewhat organized warehouse for
preferences. The NetInfo Manager allows you to change and set not only individual
behaviors, but overall NetInfo domain settings as well. Unfortunately, the name lends
itself to thinking 'Oh, this is where I do all my NetInfo work.', and this is not normally
the case. There are occasions where you have to do this, but ideally, you, or someone
would write an application that collects input from a user in a user friendly manner,
and then uploads that information to NetInfo. This is the safe way to do it, and the
recommended way.
I finally figured this out when after six months of working with the folks on the Omni
CONTACT _Con-4AFFE0E22 OS X Server Admin list, (an excellent resource by the
way, and I highly recommend it to anyone wanting to use the OS X Public Beta in a
networked environment. Subscribe at
http://www.omnigroup.com/community/mailinglists/), and hunting down links on
the web, just why there was no real information on using NetInfo Manager. The reason
for this is because you're not supposed to. Even older NeXT documentation talks about
getting things done in terms of other applications, not NetInfo Manager. This is good,
because it is trying to keep people from mucking about in NetInfo, and really, truly
destroying their operating system. As an analogy, doing things in NetInfo manager,
without knowing what you are doing and why, is about as hazardous as using ResEdit on
your System file without knowing what your are doing and why. It's 'a bad thing'.
AppleShareIP
This is an obvious one to go over, as it should be the easiest and most completely
supported networking model in the Public Beta. Should be, but tends not to be. The
most obvious situation is the lack of support for 'pure' AppleTalk. This is not as much
of a problem as one would think, as in most cases, networks that are 100% AppleTalk
only are rare. The other issue is that the Public Beta doesn't use the Name Binding
Protocol, or NBP.
NBP is how the Chooser allowed you to see network devices. When you selected
AppleShare, and a zone, if any, in the Chooser, your Mac sent out a NBP request to that
zone, or network if zones aren't used. Any AppleShare devices that are able to respond
correctly to an NBP request send back a reply that contains, among other things like
type, and (sometimes) zone, the server name. The server name is what shows up in
the Chooser. Since the Public Beta doesn't support NBP, it does not show up in the
Chooser. Nor can it see, in the OS X network browser, any NBP - only servers.
Instead of NBP, the Public Beta uses Service Locator Protocol, or SLP to discover
network resources. Examples of SLP - enabled servers are AppleShareIP (all
file-sharing services), Mac OS 9's TCP/IP file sharing, and ExtremeZ - IP from
Group Logic. SLP is an internet standard, and Apple was the company that approached
the IETF with the idea of SLP as a way to bring over the ease of use to the TCP/IP world
that NBP had given the AppleTalk world. This is not to say that a Public Beta machine
is unreachable without SLP, it just isn't browseable. You can still connect to it via the
AFP URL mechanism, i.e. afp://thismachinenameorIPaddress, or the server IP address
button in the Chooser.
Other changes to the Apple Filing Protocol, (AFP) between versions 3.0, (the Mac OS X
version), and AFP version 2.2, introduced in AppleShareIP 5.0 include:
• Support for longer pathnames and pathnames with Unicode characters
• Support for Unix privileges
• The ability to check for Unix privileges on the server
• Checking to see if the server supports directory services
• Larger file sizes and disk drive sizes
• Authentication method queries
• Log in directory name queries
• Mapping Unicode user and group names to user and group Ids
• Reconnections
• Longer attention messages
So even though pure AppleTalk is not supported, OS X is not cut off from AppleShare
networks. But if you still have AppleTalk - only networks, or even LocalTalk
networks, now is the time to start moving them to a TCP/IP - based network.
OpenDoor, at <http://www.opendoor.com> has not only excellent products to help you
do this, but excellent information on ways to accomplish this with as little pain as
possible. In addition, there is an article in the January, 2000 MacTech, "Fitting the
Desktop into a TCP/IP Environment", that describes some real - world adventures,
(namely my own), in doing just that.
NIS