Xsan can have up to 64 clients all sharing up to eight volumes. Remember that metadata controllers also count as client systems accessing the SAN. Realistically, that means up to 62 editors can be editing material, and two Xserve G5 metadata controllers will be hosting the volume(s).
There are two general ways to build your SAN:
1. NetInfo
In this implementation, client nodes are locally authenticated. This means that clients log in to their local directory, and each individual system is in charge of granting access to its own CPUs. The benefit to this implementation is that it is fairly easy to configure, but it is viable only on small SANs of up to six clients. As the SAN grows in size, a NetInfo-configured SAN can be difficult to manage. This is because all users should have consistent user IDs. Since there is no centralized directory, the NetInfo database must essentially be “cloned” on all client systems as the number of users increases.
2. Centralized Directory
A centralized directory, such as Open Directory, allows the user database to be centralized in one location. Since the authentication occurs on the server, all clients must be bound to the server and able to access the common directory. When a user logs in to a client machine, the user name and password are verified with the server and the user is granted access to the local computer. This method also allows for unique user IDs as well as making it simple to add users as the SAN grows in size.
In configurations where you will be authenticating to local client machines, the order in which the user is added determines the UID (user ID) and GID (group ID) for that user. The SAN volume follows the UID/GID only when determining access to files and folders. This means that three clients might have conflicting UIDs and be given read/write access to the same file or folder. This may be desired, but it can cause problems if two users write to the same project simultaneously.
Since the UID and GID are automatically assigned when you create a new user on a local machine (System Preferences > Accounts), you will need a way to replicate the UID information across all local client machines. This will make it easier for the SAN to resolve UIDs to actual named users accessing the SAN.
The main way to make sure UIDs are identical across your SAN client nodes is to create all users in the exact same order on all machines. This will insure that Albert, for example, is assigned a UID of 502 (the first Admin user is assigned 501 at initial configuration). Bonnie, the second user created, will be assigned a UID of 503. If you are consistent across all machines, you will have replicated the user list properly.
You can use the NetInfo Manager application to view and update the user and group ID for any user.
You will find it in Applications>Utilities>NetInfo Manager.
Changing the UID is helpful, for example, if two users have conflicting UID numbers and you must change one of them. Updating this information requires two steps:
Changing the UID and GID in Netinfo Manager (Applications > Utilities > NetInfo Manager)
Updating the permissions of the users previously created Home folder (we will use the Terminal application for this).
If you have to change the UID and GID of a user, you will have to update the ownership of their previously created Home folder (Users > username). If this information is not updated, the user will not have access to his or her own Home folder. This modification is done in the Terminal (Applications > Utilities > Terminal).
Run the Terminal application
Change the directory to the Users directory
$ cd /Users $ ls -l
This will give a detailed list of the folders as well as user and group information.
Notice that Alberts UID says 502 instead of his proper name. This is because Albert has been changed to UID 511 in NetInfo Manager. The user with ID 502 now has ownership of /Users/albert, and not Albert himself. Let’s fix that- Type:
Enter an admin password, and the folder and its contents will be modified. The chown command changes ownership of files or folders. The -R option changes the ownership of the file hierarchies as well. You can do a ls -l to verify that Albert now is the owner of his folder.
When configuring a centralized directory, all of the clients authenticate through the server. In Server Admin, the Open Directory service will be promoted from Standalone Server to Open Directory Master. Once enabled, the user and group list can be configured in Workgroup Manager. The group list will allow you to place one or more users in a particular group, giving you control over numerous parameters for a given set of users.
As clients log into the directory, they will have to enter a username and password to access their local machine. This centralized list of users is stored and managed on the LDAP server using Workgroup Manager.
Using Directory Access (Applications > Utilities) you can bind a client to a centralized directory such as Open Directory.
You can enter the Terminal Application (Applications > Utilities) and check for a successful client binding.
Type:
$ lookupd -d > userWithName: albert
Enter the username of any user in your central directory. In this case, albert. If you are not bound, you will get a return of “nil.” If your binding was successful, you will see:
Dictionary: "DS: user albert" _lookup_agent: DSAgent _lookup_validation: 1108602456 gid: 1026 home: /Users/albert name: albert Albert passwd: ******** ******** realname: Albert shell: /bin/bash uid: 1025 + Category: user + Time to live: 43200 + Age: 0 (expires in 43200 seconds) + Negative: No + Cache hits: 0 + Retain count: 4