9.8. OPENLDAP DIRECTORY SERVICE |
373 |
# alias: :include: file of names
#
maillist: :include:/mercury/local/maillists
#
# Dump mail to a file
#
archive: /mercury/local/archive/email.archive
9.7.10Changes and updates
Sendmail is changing and developing rapidly. The details above are rudimentary, and you will have to adapt them to the current release of the software. Since this chapter was written, various restructurings have been performed:
1.A new user is required, smmsp, with a corresponding group. Sendmail is now setgid smmsp, not setuid root.
2.The default invocation of sendmail is as a Mail Submitter Program (option ‘-Ac’). This contacts port 25 on localhost in order to deliver mail. If no contact is established, mail is written to /var/spool/clientmqueue, which is owned by the new user. There is support for several queues.
3.When the daemon starts (option ‘-bd’), it is run as root and processes the usual queue /var/spool/mqueue.
4.sendmail -Ac -q flushes the MSP queue.
9.8 OpenLDAP directory service
OpenLDAP is the open source implementation of the Lightweight Directory Access Protocol server (DSA) (see section 7.12.2). Installation is straightforward: after unpacking the distribution from www.openldap.org,
configure make depend make
make test (su)
make install
The configuration file slapd.conf determines the local name space as well as the identity and password protection of the database manager. There is much that can be configured here, related to security and schema extensions. To begin with, it is important to set a password for the database manager. This password has to be encrypted manually and pasted into the configuration file.
The slappasswd command hashes passwords into ascii strings, so that they can be added to the slapd.conf file.
374 |
CHAPTER 9. APPLICATION-LEVEL SERVICES |
/usr/local/sbin/slappasswd New Password:
Repeat New Password: SSHAkDPIIA9KR5LVQthcv+zJmzpC+GVYQ4Jj
A sample configuration file thus looks like this:
#See slapd.conf(5) for details on configuration options.
#This file should NOT be world readable.
# |
|
include |
/usr/local/etc/openldap/schema/core.schema |
pidfile |
/usr/local/var/slapd.pid |
argsfile |
/usr/local/var/slapd.args |
database |
bdb |
suffix |
"dc=iu,dc=hio,dc=no" |
rootdn |
"cn=Manager,dc=iu,dc=hio,dc=no" |
#Cleartext passwords, especially for the rootdn, should
#be avoid. See slappasswd(8) and slapd.conf(5) for details.
#Use of strong authentication encouraged.
#rootpw secret
rootpw SSHAkDPIIA9KR5LVQthcv+zJmzpC+GVYQ4Jj
#The database directory MUST exist prior to running slapd AND
#should only be accessible by the slapd/tools. Mode 700 recommended.
directory /usr/local/var/openldap-data
# Indices to maintain index objectClass eq
Note that the password is checked when adding data to the database. Password credential errors are reported if either the password is incorrect, or the dc components in the suffix are incorrect. Everything in the specification has to be correct. Think of these as username and password.
Starting the server is a confusing business. At the time of writing, the OpenLDAP server did not behave as described by its documentation.
The server can now be started as follows:
daneel# /usr/local/libexec/slapd -h "ldap://0.0.0.0"
See section 7.12.2 for details about directory configuration and specialist references.
9.9 Mounting NFS disks
The sharing of disks over the network is the province of NFS (Network File System). Unix disks on one host may be accessed across the network by other Unix hosts, or by PCs running PC-NFS. A disk attached physically to a host called a server
9.9. MOUNTING NFS DISKS |
375 |
is said to be mounted on a client host. In order to maintain a certain level of security, the server must give other hosts permission to mount disks. This is called exporting or sharing disks.
9.9.1Server-side exporting
In order to mount a disk on a server we must export the disk to the client (this is done on the server) and we must tell the client to mount the disk. Permission to mount disks is given on the server in a file which is called /etc/exports or on recent SVR4 hosts /etc/dfs/dfstab. The format for information in these files differs from system to system so one should always begin by looking at the manual page for these files. Here are two examples. The first is from GNU/Linux.
#See exports(5) for a description.
#This file contains a list of all dirs exported to other computers.
#It is used by rpc.nfsd and rpc.mountd.
/iu/borg/local daystrom(rw) worf(rw) nanite(rw) *.domain.tld(ro)
In this example, a file system called /iu/borg/local is exported read–write explicitly to the client hosts daystrom, worf, and nanite. It is also exported read-only to any host in the domain domain.tld. This last feature is not available on most types of Unix.
On some brands of Unix (such as SunOS 4.1.*) one must run a command after editing this file in order to register the changes. The command is exportfs -a to export all filesystems. The command exportfs alone shows which filesystems are currently exported and to whom.
Our second example is from Solaris (SVR4). The file is called /etc/dfs/dfstab. Under Solaris, one can use the share command to export filesystems manually from the shell, using a command line of the form
share -F nfs -o rw= hostname filesystem
The /etc/dfs/dfstab file is in fact a shell script which simply executes such a command for each filesystem of interest. This has several advantages over traditional export files, since one may define variables, as in the example below.
#place share(1M) commands here for automatic execution
#on entering init state 3.
#
#share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource]
#.e.g,
#share -F nfs -o rw=engineering -d "home dirs" /export/home2
hostlist=starfleet:axis:ferengi:borg:worf:daystrom:worf.domain.tld\
:daystrom.domain.tld:nostromo:voyager:aud4:aud4.domain.tld\
:aud1:aud1.domain.tld:aud2:bajor:nostromo:galron:ds9:thistledown\
:rama
share -F nfs -o rw=$hostlist /iu/mercury/local
share -F nfs -o rw=$hostlist,root=starfleet /iu/mercury/u1
376 |
CHAPTER 9. APPLICATION-LEVEL SERVICES |
share -F nfs -o rw=$hostlist,root=starfleet /iu/mercury/u2 share -F nfs -o rw=$hostlist,root=starfleet /iu/mercury/u3 share -F nfs -o rw=$hostlist,root=starfleet /iu/mercury/u4 share -F nfs -o rw=$hostlist /var/mail
This script exports the six named filesystems, read–write to the entire list of hosts named in the variable hostlist. The command shareall runs this script, or it can be run manually by typing sh /etc/dfs/dfstab. The command share without arguments shows the currently exported filesystems. Notice that the hostname daystrom is repeated, once unqualified and again with a fully qualified hostname. This is sometimes necessary in order to make the entry recognized. The mount daemon is not particularly intelligent when it verifies hostnames. Some systems send the fully qualified name to verify and others send the unqualified name. If in doubt, list both like this.
9.9.2Client-side mounting
Clients may mount any subdirectory of the exported directory onto any local directory by becoming root and either executing a shell command of the form
mount server: remote-directory local-directory
or by adding a line to the filesystem table file, usually called /etc/fstab. On some brands of Unix, this file has been renamed as /etc/checklist or /etc/filesystems. On Solaris systems it is called /etc/vfstab. The advantage of writing the disks in the filesystem table is that the mount commands will not be lost when we reboot our system. The filesystems in the filesystem table file are mounted automatically when the system is booted. All the file systems in this file are mounted with the simple command mount -a.
We begin by looking at the manual page on the appropriate file for the system, or better still looking at examples which are already in the file. The form of a typical filesystem table is as below.3
/dev/sda2 |
swap |
swap |
rw,bg |
1 |
1 |
/dev/sda1 |
/ |
ext2 |
rw,bg |
1 |
1 |
/dev/sda3 |
/iu/borg/local |
ext2 |
rw,bg |
1 |
1 |
mercury:/iu/mercury/u1 |
/iu/mercury/u1 |
nfs |
rw,bg |
mercury:/iu/mercury/u2 |
/iu/mercury/u2 |
nfs |
rw,bg |
mercury:/iu/mercury/u3 |
/iu/mercury/u3 |
nfs |
rw,bg |
mercury:/iu/mercury/local |
/iu/mercury/local nfs |
rw,bg |
|
This example is from GNU/Linux. Notice the left-hand column. These are disks which are to be mounted. The first disks which begin with /dev are local disks, physically attached to the host concerned. Those which begin with a hostname followed by a colon (in this case host mercury) are NFS filesystems which lie physically on the named host. The second column in this table is the name of a directory on which the disk or remote filesystem is to be mounted – i.e. where the files are to appear in the local host’s file-tree. The remaining columns are
3On older HPUX systems, there is a bug which causes mysterious numbers to appear in the /etc/checklists file. These have no meaning.
9.9. MOUNTING NFS DISKS |
377 |
options and filesystem types: rw means mount for read and write access, bg means ‘background’ which tells mount to continue trying to mount a filesystem in the background if it fails on a first attempt.
Editing the /etc/fstab (or equivalent) file is a process which can be automated very nicely with the help of the system administration tool cfengine. We shall discuss this in the next chapter.
9.9.3Trouble-shooting NFS
If you get a message telling you ‘Permission denied’ when you try to mount a remote filesystem, you may like to check the following:
•Did you remember to add the name of the client to the export or dfstab file on the server?
•Some systems require a fully qualified hostname (i.e. hostname with domainname appended) in the export file. Try using this.
•Did you mis-spell the name of the client or the server?
•Are the correct network daemons running which support nfs? On the server side, you must be running mountd or rpc.mountd. This is an authentication daemon. The actual transfer of data is performed by nfsd or rpc.nfsd. On older systems there should be at least four of these daemons running to handle multiple requests. Modern systems use a multi-threaded version of the program, so that only one daemon is required.
On the client side, some systems use the block input/output daemon to make transfers more efficient. This is not strictly necessary to get NFS working. This daemon is called biod on older systems and nfsiod on newer systems like FreeBSD. Solaris no longer makes use of this daemon, its activities are now integrated into a kernel thread.
•The portmapper (portmap or rpcbind) is a strange creature. On some Unixlike systems, particularly GNU/Linux, the portmapper requires an entry in the TCP wrapper file /etc/hosts.allow in order for it to accept connections. Otherwise, you might see the error
RPC service not registered.
The portmapper requires numerical IP addresses in the TCP wrapper configuration. Host names will not do, for security reasons (see section 9.4.5).
•The exports file on GNU/Linux hosts is also somewhat unusual. If you are using a non-standard netmask, it is necessary to tell the mount daemon:
#/etc/exports: the access control list for filesystems
#which may be exported to NFS clients. See exports(5).
/site/cube/local *.college.edu/255.255.255.0(rw) /site/cube/local 192.0.2./255.255.255.0(rw)