InformIT: Mac OS X Unleashed > Using the NetInfo Database to Share Resources

Table of Contents

Using the NetInfo Database to Share Resources

In this section we will demonstrate ways that your OS X machine can share resources with other Unix machines using NFS, Network File System. We will demonstrate two ways to set up your OS X machine as an NFS client and one way to use it as an NFS server.

A Common Way to Set Up an NFS Client in OS X

In this section, we will demonstrate a common method for setting up an NFS client on an OS X machine. We show you this method because you will see references to this type of code, for this and other NetInfo-related activities, regularly on the Internet. Sometimes this type of method is the only method you can choose, so you need to be familiar with it. Sometimes, though, an alternative method might work better. For your OS X machine to be a client machine, there has to be another Unix machine that is an NFS server. In other words, there has to be a Unix machine (Mac OS X or another flavor of Unix) on your network that is willing to export one of its file systems to your OS X machine. So, you cannot just set up your machine as a client and assume that everything will work fine. Discuss your interest in being able to use your OS X machine to access a file system on another Unix machine with that machine's system administrator. There is a security risk involved, particularly for the other machine, when it shares its resources with your machine. Therefore, in that machine's interest, the system administrator might not be willing to export its file systems to your machine.

There might be some additional details to work out with your NFS server system administrator that we will not discuss in depth here, assuming that he feels you will responsibly control your machine and your use of the NFS server's resources. To avoid confusion on the remote host machine, it would be a good idea for users that are accessing the other machine's file system from your machine to have the same user and group IDs that they might already have on the remote host machine. Depending on how the remote host is set up, there might not be much confusion. For example, if the remote host does not have user IDs in the same range as the users on your machine, the unusual user IDs might not be a problem. However, if users on your machine have user IDs in the same range as users on the remote host, files you create on the remote host with your user ID might be viewed by the remote host as being owned by a different user with the same user ID on its system. At any rate, if the system administrator of the remote machine agrees to export to your machine whichever file system you are interested in using, be aware that you still might have to work out some additional details with the system administrator. As your understanding of how to update the NetInfo database continues to improve in this chapter, any changes the system administrator of the remote host might request for your OS X machine should not be difficult to change.

With that said, let's continue to the details of setting up an NFS client on your OS X machine. To be an NFS client, your machine needs to be running the right services. If you did not turn off any of the major default services, you do not need to worry about this. If you turned off NFS in the /System/Library/StartupItems/ directory, you will have to turn it back on to be able to run your NFS client.

It would also be a good idea to read the man pages for mount, mount_nfs, and fstab. The information that you will be adding to the NetInfo database is information where your machine should mount a particular file system that resides on a remote host. When you are done updating the NetInfo database, the remote host's file system will appear to be local to your own machine.

To add a file system from a remote host to your OS X machine, do the following:

Back up your NetInfo database.
Plan where you want your OS X machine to mount the remote host's file system. The purpose of the remote file system might guide you in how to mount it on your machine. For example, it is common practice, when a file system with a users' home directories are involved, that a machine mounting such a file system frequently does so in a directory hierarchy of /net/ <remote_host> /home. If the remote file system is simply a file system used for storage, any way you want to mount it is probably suitable. Of course, you can change the name of the mount point if you find that you do not like what you picked. Extra thought is particularly important when the remote file system is used for users' home directories. In our example, we are going to mount a file system used for storage. On our machine we want it to be mounted in a directory called /morespace. If we were to decide later to mount a number of storage file systems from remote hosts, we might consider a hierarchy similar to the user hierarchy, and choose something like /net/<remote_host>/morespace or /morespace/<remote_host>/, where the mount point clearly includes the host of origin. After you have decided what to call the mount point, make it:
```
[localhost:/] root# mkdir morespace
```
Using your favorite text editor, create a file with the contents of the following form:
```
{
"opts" = ( "w" );
"dir" = ( "/<mountpoint>/" );
"name" = ( "<remote_host>:<remote_filesystem>");
"type" = ( "nfs" );
}
```
Although many options are available for mounting, the one you will probably find most important is the read/write option. On most systems, that option is rw. In OS X, that option is w, although using the traditional rw also appears to work. Here is a copy of the file we used:
```
{
"opts" = ( "w" );
"dir" = ( "/morespace/" );
"name" = ( "rosalyn:/mnt2");
"type" = ( "nfs" );
}
```
Run niutil to create a new directory in the mounts directory of the NetInfo database:
```
[localhost:~joray/nfs] root# niutil -create . /mounts/new1
```
Run niload to load the file into the NetInfo database:
```
[localhost:~joray/nfs] root# niload -r /mounts/new1 . < mount-test.txt
```
If you type as well as we do, you might have to run that statement a few times before it works. You might get messages indicating that there is an error at some line number. Just look at your file carefully and fix whatever needs to be fixed.
Look at the updates in the mounts section of the NetInfo database either using the command line or the NetInfo Manager. If you are using the command line, you might find it easier to see the values by directory number rather than directory name. Here are the command-line results in our example as seen using niutil:
```
[localhost:~] joray% niutil -list . /mounts
167      rosalyn:/mnt2

[localhost:~] joray% niutil -read . 167

opts: w
dir: /morespace/
name: rosalyn:/mnt2
type: nfs
```
After you have verified that the updates to your NetInfo database are correct, reboot the machine and ztest the results.

It might seem like it takes your machine a little longer to reboot. This is to be expected.

First, check whether the file system mounted. You could run mount to see what is mounted where:

[localhost:~] joray% mount

     /dev/disk1s6 on / (local)
     devfs on /dev (local)
     fdesc on /dev (union)
     <volfs> on /.vol (read-only)
     /dev/disk0s5 on /Volumes/Macintosh HD (local)
     /dev/disk1s7 on /Volumes/Blank2 (local)
     /dev/disk1s8 on /Volumes/Blank3 (local)
     /dev/disk1s9 on /Volumes/huge (local)
     rosalyn:/mnt2 on /morespace
     automount -fstab [259] on /Network/Servers

You could even skip running mount and directly run ls:

[localhost:~] joray% ls /morespace

     0012129-unison.tar installed          patches-0104       restoresymtable
     deleted_web_pages  lost+found         public             unison

Now you can access a remote file system as if it were local to your machine.

As we mentioned earlier, you might have to work out some details with the system administrator of the remote machine. One of the details you might have to work out is making sure that there is a directory on that file system that you are allowed to write to. In our example, there is a public directory on the remote file system that we are allowed to use.

An Easier Way to Set Up an NFS Client in OS X

As you might recall from the section on adding a printer through the command line, the niload command can recognize some regular Unix flat-file formats. The format we saw earlier, printcap, is one of them. It turns out the file that controls mount points, fstab, is another of those formats.

We recommend that, where possible, you use niload in combination with formats it might already recognize rather than having it load in raw NetInfo format. Because the Unix flat-file formats are easier to type, you will make fewer typos. In addition, if you take the time to familiarize yourself with the regular Unix flat files, you will be even better prepared to understand information that relates to other Unix platforms. Always be sure to check the NetInfo database results, not only to confirm that everything was done properly, but also to learn the OS X formats.

In this section, we will show you an easier way to enter the mounts information into the NetInfo database. Although this is easier, be aware that you still have to coordinate with the system administrator of the remote host.

To set up an NFS client on an OS X machine, you can also do the following:

Back up the NetInfo database.
Create the local mount point for the remote file system.

Create a one-line file containing the mount information. The one-line file has these fields, which can be separated by spaces or tabs:

Field	Value
`1`	Remote file system to be mounted
`2`	Local `mount` point
`3`	File system type
`4`	`mount` options
`5`	Interval between dumps
`6`	Order in which `fsck` is run at boot time

Fields 5 and 6 do not apply to remote file systems. Those values can either not be present or can be 0.

Here is the fstab used in these examples:

rosalyn:/space /extraspace  nfs rw 0 0

Run niload to load the fstab format file into the NetInfo database. In our example, we used "fstab-test" as the fstab formatted file:
```
[localhost:/Users/joray/nfs] root# niload fstab . < fstab-test
```
Verify that the data was loaded properly into the NetInfo database using either the command line or the NetInfo Manager. Figure 23.25 shows the results of this load.

Figure 23.25 The fstab format file was successfully loaded into the NetInfo database.
Reboot the machine, and then test the results. Run the same sorts of command-line tools you ran in the previous section, such as mount and ls. But you might also want to check system disk in your OS X desktop, as you will hopefully find a pleasant surprise there too. Figure 23.26 shows the remote file systems as they appear on our OS X system disk. Unfortunately, choosing a mount point of /Volumes/ <mount_point> / does not result in the remote file system appearing in the lineup on the desktop.

Figure 23.26 The remote file systems appear on our OS X disk, exactly as we specified in the NetInfo database.

You can open the remote file systems in the graphical interface as well, as shown in Figure 23.27.

Figure 23.27 Here are the contents of the remote file system mounted as /extraspace on our OS X machine. This is not obvious from the title bar.

Any changes you make to the NFS mounts by just restarting the NetInfo domain servers will be available immediately via the command line. If you want to make the NFS mounts available via the graphical interface immediately as well, be sure to reboot after making your changes to the mounts in the NetInfo database.

Setting Up Your OS X Machine to Be an NFS Server

As the prices of IDE storage continue to drop, you might be interested in serving one of your file systems to another Unix machine. You might, for example, want to export one of your file systems to another Unix machine you use regularly, so as to have some of your storage conveniently available.

Just as setting up your machine to be an NFS client requires coordination with the system administrator of the remote Unix machine, so does serving a file system to a remote Unix machine. Remember, this reduces security on both systems, especially yours. Do not consider doing this unless you can trust the remote host.

Depending on the system setups, coordination between user IDs might be necessary, especially if you want to make the drive available to users other than yourself. The other system administrator should be able to guide you through any additional details that might need to be coordinated.

The other Unix system administrator will set up the remote host to be able to mount your file system. You will have to set up your machine to export a file system to a remote host. At this time, you should read the exports man page.

If you plan to create your exports through the command line, you might want to take this opportunity to look at the nidump command. As the name suggests, nidump dumps information from the NetInfo database to standard output. It can dump information to a flat file, if you should have a need for the information in the format of a traditional flat file. It can also dump information in a format that can be understood by the NetInfo database. You might find running nidump on one of the NetInfo directories to be a useful way of seeing the syntax that is used to create a new directory and directories under it.

Here is what the nidump output from the mount examples in the previous section looks like:

[localhost:~] software% nidump -r /mounts .

     {
       "name" = ( "mounts" );
       CHILDREN = (
         {
           "vfstype" = ( "nfs" );
           "passno" = ( "0" );
           "dir" = ( "/extraspace" );
           "dump_freq" = ( "0" );
           "name" = ( "rosalyn:/space" );
           "opts" = ( "w" );
         } ,
         {
           "opts" = ( "w" );
           "dir" = ( "/morespace" );
           "name" = ( "rosalyn:/mnt2" );
           "type" = ( "nfs" );
         }
       )
     }

Not only does nidump provide an example of the syntax used to create a directory and subdirectories, but the output from an nidump command can also provide the basis for a file that you could edit for setting up your exports. This would already provide much of the complicated part of the syntax, and enable you to just edit values suitable for exports instead.

The complete documentation for nidump is in Table 23.3.

Table 23.3. The `nidump` Utility Can Export NetInfo Data to Plain Text Formats

`nidump`	Extracts text or flat-file-format data from NetInfo
`nidump [-t] { -r` `<directory>` `\|` `<format>` `}` `<domain>`
`nidump` reads the specified NetInfo domain and dumps a portion of its contents to standard output. When a flat-file administration format is specified, `nidump` provides output in the syntax of the corresponding flat file. Allowed values for `<format>` are `aliases`, `bootparams`, `bootptab`, `exports`, `fstab`, `group`, `hosts`, `networks`, `passwd`, `printcap`, `protocols`, `rpc`, and `services`.
If `-r` is used, the first argument is interpreted as a NetInfo directory path, and its contents are dumped in a generic NetInfo format.
`-t`	Interprets the domain as a tagged name.
`-r`	Dumps the specified directory in raw format. Directories are delimited in curly brackets. Properties within a directory are listed in the form `property = value;`. Parentheses introduce a comma-separated list of items. The special property name `CHILDREN` is used to hold a directory's children, if any. Spacing and line breaks are significant only within double quotes, which might be used to protect any names with meta characters.

To set up your OS X machine to export a file system to a remote Unix host, do the following:

Back up the NetInfo database.
If you plan to export a file system that currently contains a space in the name, change its name to something that does not have a space. The remote host will understand a file system name that does not contain a space in its name.
Enter exports information into the NetInfo database. Unfortunately, despite what the man page says, the niload command currently does not understand the typical exports format. So, in this case, you cannot make an exports format file and load that into NetInfo. You must either make a file that follows the same kind of format we saw in the first mount example, the format with braces, parentheses, and quotes, or you must enter the information into the NetInfo database using the NetInfo Manager. Because I am so poor at typing all the appropriate characters needed to make one of the raw NetInfo files, I prefer to do this through the NetInfo Manager. Our instructions are specifically for the NetInfo Manager. However, you should choose whichever method you are most comfortable with. Open the NetInfo Manager, and select the local domain. Click in the lock to make changes, and enter the administrator username and password. With the root directory selected, select New Subdirectory under the Directory menu. Change the name of new_directory to be exports, and save the change.
Click the exports directory. Select New Subdirectory from the Directory menu. Give this subdirectory the name of the file system you want to export. Add a clients property whose value is a list of clients that the file system should be exported to. Add an opts property with any options you want to specify, based on the exports man page.

Figure 23.28 shows the settings that we used for exporting our file system.

Figure 23.28 Keep /Volumes/huge on one line preffered, or divide at a sensible location, such as starting the next line with huge.

Save your changes to the exports directory, and then restart the NetInfo servers for your local domain. Click the lock to prevent further changes.
Reboot the machine and then test the results. You might find that the exports are exported right away after restarting the NetInfo servers; however, we have found that rebooting the machine consistently works. A quick test you can do on your OS X machine is to run mount:
```
[localhost:~] joray% mount

/dev/disk1s6 on / (local)
devfs on /dev (local)
fdesc on /dev (union)
<volfs> on /.vol (read-only)
/dev/disk0s5 on /Volumes/Macintosh HD (local)
/dev/disk1s7 on /Volumes/Blank2 (local)
/dev/disk1s8 on /Volumes/Blank3 (local)
/dev/disk1s9 on /Volumes/huge (NFS exported, local)
rosalyn:/space on /extraspace
rosalyn:/mnt2 on /morespace
automount -fstab [259] on /Network/Servers
```
Note that the OS X machine indicates that /Volumes/huge is being served as an NFS export as well as mounted locally. Test that the remote host agrees with the OS X machine:
```
Rosalyn joray 87 > ls /net/ryoohki/huge

AppleShare PDS           TheFindByContentFolder   osx-misc.tar
Desktop DB               TheVolumeSettingsFolder  test
Desktop DF               Trash                    â¢T+â¢It's HUUUGE
Desktop Folder           lpd-spool-working.tar
```
If we check the file system locally, we find the same ls listing:
```
[localhost:~] joray% ls /Volumes/huge

AppleShare PDS               TheFindByContentFolder       osx-misc.tar
Desktop DB                   TheVolumeSettingsFolder      test
Desktop DF                   Trash                        ???T+???It's HUUUGE
Desktop Folder               lpd-spool-working.tar
```
After you are satisfied that the export is working properly, you should remember that your machine is now serving data to another machine. Consequently, it might seem like it takes a little longer for it to shut down at shutdown or reboot time. Do not panic. This is expected. If you plan for your exported file system to be of regular use, try to keep the number of reboots to a minimum. After your machine starts serving data to another machine, it is not just your machine or a machine for your local users, it is a machine that users on a remote host could come to rely on.

If the basic ways available to you in OS X for sharing resources seem a bit overwhelming, you might be interested in a shareware product called NFS Manager, available at http://www.bresink.de/osx/. It provides GUI interface controls for both NFS mounts and exports. A sample of the interface is shown in Figure 23.29.

Figure 23.29 Here is a sample of what the interface for the shareware product called NFS Manager looks like.

Restoring the Local NetInfo Database | Next Section

Previous Section

Using the NetInfo Database to Share Resources

A Common Way to Set Up an NFS Client in OS X

An Easier Way to Set Up an NFS Client in OS X

Setting Up Your OS X Machine to Be an NFS Server

Table 23.3. The nidump Utility Can Export NetInfo Data to Plain Text Formats

Table 23.3. The `nidump` Utility Can Export NetInfo Data to Plain Text Formats