Опубликован: 06.08.2012 | Доступ: свободный | Студентов: 1189 / 25 | Оценка: 5.00 / 5.00 | Длительность: 53:41:00
Лекция 24:

Basic network access: clients

Using an rsync server

The use of rsync that we've seen so far doesn't require a server, but it does require an ssh. rsync also offers a different means of access that uses a server, rsyncd. This method is intended more for access to systems for which you don't have a password, something like anonymous ftp.

We'll look at setting up an rsync server on page 454. The client side is relatively simple. Use two colons when referring to the remote system. For example, you might enter:

$ rsync freebie::
This is freebie.example.org.  Be gentle.

groggy  Greg's web pages
tivo    TiVo staging area

The first line is simply an identification message, referred to as a message of the day in the documentation. The others represent directory hierarchies that the server makes available, along with a comment about their purpose. The documentation calls them modules. As we'll see on page 454, they correspond to directories on the server machine, though the names don't need to be related.

To find out what is in these directories, you can use the following kind of command, which specifies a particular module, but no destination:

$ rsync freebie::groggy
This is freebie.example.org.   Be gentle.
drwxr-xr-x    5632 2002/10/24 12:40:38 .
-rw-r--r--    3855 2002/03/16 13:51:12 20feb99.html
-rw-r--r--    2363 2002/03/16 13:51:12 7mar1999.html
-rw-r--r--    8345 2002/03/16 13:51:12 AOSS-programme-orig.html
-rw-r--r--   11590 2002/03/16 13:51:12 AOSS-programme.html
-rw-r--r--    1798 2002/03/16 13:51:12 BSDCon-2002.html
-rw-r--r--    1953 2002/03/16 13:51:12 Essey-20020222.html
...etc

To transfer a file, specify its name and a destination:

$ rsync -v freebie::groggy/AOSS-programme.html .
This is freebie.example.org.  Be gentle.

AOSS-programme.html
wrote 98 bytes  read 11744 bytes  23684.00 bytes/sec
total size is 11590  speedup is 0.98

This example uses the -v option to show what rsync has done; without it, there would be no output.

If you want to transfer the entire module, use the -r or -a options we looked at above:

$ rsync -r -v freebie::groggy .
This is freebie.example.org.   Be gentle.

receiving file list ... done
skipping non-regular file "Images/20001111"
20feb99.html
7mar1999.html
AOSS-programme-orig.html
AOSS-programme.html
BSDCon-2002.html
...etc

The Network File System

The Network File System, or NFS, is the standard way to share UNIX files across a network.

We've already seen that UNIX file systems are accessible in a single tree by mounting them on a specific directory. NFS continues this illusion across the network.

From a user point of view, there is little difference: you use the same mount command, and it performs what looks like the same function. For example, if system presto's system administrator wants to mount freebie's file systems, /usr and /home, he could enter:

# mkdir    /freebie
# mount    freebie:/  /freebie
# mount    freebie:/usr  /freebie/usr
# mount    freebie:/home  /freebie/home

You'll note how to specify the file systems: the system name, a colon (:), and the file system name. This terminology predates URIs; nowadays, people would probably write nfs://freebie/usr.

Note also that you don't need to create /freebie/usr and /freebie/home :assuming that the directories /usr and /home exist on once you have mounted /freebie, they will become visible.

If you look at NFS more closely, things don't look quite as similar to disks as they do at first sight. You access local file systems via the disk driver, which is part of the kernel. You access NFS file systems via the NFS processes.

Older implementations of NFS had a plethora of processes. If you're used to such systems, don't let the lack of processes make you think that there's something missing.

NFS client

You don't need any particular software to run as an NFS client, but the program nfsiod greatly improves performance. It's started at boot up time if you specify nfs_client_enable="YES" in your /etc/rc.conf, but you can also start it manually if it's not running:

# nfsiod -n 6

The parameter -n 6 tells nfsiod how many copies of itself to start. The default is four. Each nfsiod can handle a concurrent I/O request, so if you find that your performance isn't what you would like it to be, and the CPU time used by each nfsiod is similar, then you might like to increase this value. To ensure it's done automatically at boot time, add the following to /etc/sysctl.conf:

vfs.nfs.iothreads=6

We'll look at /etc/rc.conf and /etc/sysctl.conf in more detail in "Starting and stopping the system" .

Mounting remote file systems

As we've seen, we mount NFS files with the same mount command that we use for local file systems. This is another illusion: mount is just a front-end program that determines which program to start. In the case of local file systems, it will start mount_ufs, and for NFS file systems it will start mount_nfs.

There are a number of options you may wish to use when mounting NFS file systems. Unfortunately, the options that mount_nfs uses are not the same as the options you would use in /etcfstab. Here's an over view:

Таблица 24.1. NFS mount options
fstab option mount_nfs option Meaning
bg -b Continue attempting the mount in the background if it times out on the initial attempt. This is a very good idea in /etc/ftab, because otherwise the boot process waits until all mounts have completed. If you've just had a power failure, this can cause deadlocks otherwise.
nfsv2 -2 Use NFS Version 2 protocol. By default, mount_nfs tries NFS Version 3 protocol first, and falls back to Version 2 if the other end can't handle Version 3. Don't use NFS Version 2 unless you have to.
retry=num -Rnum Retry up to num times before aborting an I/O operation.
-o ro -o ro Mount the file system for read-only access.
-o rw -o rw Mount the file system for read and write access.
-R num -R num Retry the mount operation up to num times. If you have chosen soft mounting, fail I/O operations after num retries. The default value is 10.
-r .size -r .size Set the read data block size to size bytes. size should be a power of 2 between 1024 and 32768. The default value is 8192. Use smaller block sizes for UDP mounts if you have frequent fragments dropped due to timeout messages on the client.
soft -s If operations on the file system time out, don't retry forever. Instead, give up after Retry timeouts. See option -R.
-t num -t num Time out and retry an operation if it doesn't complete with in num 10 seconds. The default value is 10 (1 second).
tcp -T Use TCP instead of UDP for mounts. This is more reliable, but slightly slower. In addition, not all implementations of NFS support TCP transport.
-w .size - .size Set the write data block size to size bytes. size should be a power of 2 between 1024 and 32768. The default value is 8192. Use smaller block sizes for UDP mounts if you have frequent "fragments dropped due to timeout" messages on the server.

Normally, the only options that are of interest are -o ro, if you specifically want to restrict write access to the file system, and soft, which you should always use.

Purists claim that soft compromises data integrity, because it may leave data on the server machine in an unknown state. That's true enough, but in practice the alternative to soft mounting is to reboot the client machine. This is not only a nuisance, it also compromises data integrity. The only solution that doesn't always compromise data integrity is to wait for the server machine to come back online. It's unlikely that anybody will wait more than a few hours at the outside for a server to come back.

A typical mount operation might be:

# mount -o soft presto:/usr /presto/usr

Where to mount NFS file systems

You can mount an NFS file system just about anywhere you would mount a local file system. Still, a few considerations will make life easier. In this discussion, we'll assume that we have a large number of file systems mounted on freebie, and we want to make them accessible to presto.

  • If you have a "special" file system that you want to mount on multiple systems, it makes sense to mount it on the same mount point on every system. freebie has two file systems, /S and /src, which contain source files and are shared between all systems on the network. It makes sense to mount the file system on the same directory.
  • freebie has a CD-ROM changer, and mounts the disks on /cdrom/1 to /cdrom/7. presto finds that too confusing, and mounts one of them on /cdrom.
  • Some other file systems can't be mounted in the same place. For example, freebie:/usr can't be mounted on /usr. Mount them on directories that match the system name. For example, mount freebie:/usr on /freebie/usr.

After doing this, you might find the following file systems mounted on freebie:

# df
Filesystem   1024-blocks     Used   Avail  Capacity  Mounted on
/dev/ad0s1a        30206    26830     960     97%    /
/dev/ad0s1e      1152422  1016196   44034     96%    /usr
/dev/da0h         931630   614047  243052     72%    /src
/dev/dalh        2049812  1256636  629192     67%    /home
procfs                 4        4       0    100%    /proc
/dev/cd0a         656406   656406       0    100%    /cdrom/1
/dev/cdla         664134   664134       0    100%    /cdrom/2
/dev/cd2a         640564   640564       0    100%    /cdrom/3
/dev/cd3a         660000   660000       0    100%    /cdrom/4
/dev/cd4a         525000   525000       0    100%    /cdrom/5
/dev/cd5a         615198   615198       0    100%    /cdrom/6
/dev/cd6a         278506   278506       0    100%    /cdrom/7

On presto, you might see:

# df
Filesystem    1024-blocks     Used    Avail  Capacity    Mounted on
/dev/da0s1a         29727    20593     6756     75%      /
/dev/da0s1e       1901185   742884  1006207     42%      /usr
procfs                  4        4        0    100%      /proc
freebie:/           30206    26830      960     97%      /freebie
freebie:/usr      1152422  1016198    44032     96%      /freebie/usr
freebie:/home     2049812  1256638   629190     67%      /home
freebie:/src       931630   614047   243052     72%      /src
freebie:/S        3866510  1437971  2119219     40%      /S
freebie:/cdrom/1   656406   656406        0    100%      /cdrom

Mounting NFS file systems automatically

If you want to mount NFS files automatically at boot time, make an entry for them in the file /etc/fstab. You can even do this if you don't necessarily want to mount them: just add the keyword noauto, and mountall will ignore them at boot time. The advantage is that you then just need to specify, say,

# mount /src

instead of:

# mount -s freebie:/src /src

See the description of /etc/fstab on page 566 for more information.

NFS strangenesses

NFS mimics a local file system across the network. It does a pretty good job, but it's not perfect. Here are some things that you should consider.

No devices

NFS handles disk files and directories, but not devices. Actually, it handles devices too, but not the way you would expect.

In a UNIX file system, a device is more correctly known as a device node: it's an inode that describes a device in terms of its major and minor numbers (see page 195). The device itself is implemented by the device driver. NFS exports device nodes in UFS file systems, but it doesn't interpret the fact that these devices are on another system. If you refer to the devices, one of three things will happen:

  • If a driver for the specified major number exists on your local system, and the devices are the same on both systems, you will access the local device. Depending on which device it is, this could create some subtle problems that could go undetected for quite awhile.
  • If a driver for the specified major number exists on your local system, and the devices are different on the two systems, you will still access the local device with the same major and minor numbers, if such a device exists. The results could be very confusing.
  • If no driver for the specified major number exists on your local system, the request will fail. This can still cause considerable confusion.

If the NFS server system runs devfs, the device nodes are not exported. You won't see anything unless there are left over device nodes from before the time of migration to devfs.

Just one file system

NFS exports file systems, not directory hierarchies. Consider the example on page 444. presto has mounted both freebie:/ and freebie:/usr. If it were just to mount freebie:/, we would see the directory /freebie/usr, but it would be empty.

Things can get even stranger: you can mount a remote file system on a directory that is not empty. Consider the following scenario:

  • You install FreeBSD on system feebie. In single-user mode, before mounting the other file systems, you create a directory /usr/bin and a file /usr/bin/vi. Since the /usr file system isn't mounted, this file goes onto the root file system.
  • You go to multi-user mode and mount the other file systems, including the file system for /usr. You can no longer see the /usr/bin/vi you put there in single-user mode. It hasn't gone away, it's just masked.
  • On presto, you mount the file system freebie:/ on freebie. If you list the contents of the directory /freebie/usr, you will see the original file vi, and not the contents that the users on freebie will see.
Владимир Шишкин
Владимир Шишкин
Россия, Киров
Олег Страхов
Олег Страхов
Россия