Chapter 18 Administering NIS+ Directories

This chapter describes NIS+ directory objects and how to administer them.

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). For more information, visit http://www.sun.com/directory/nisplus/transition.html.

NIS+ Directories

NIS+ directory objects are used to store information related to an NIS+ domain. For each NIS+ domain, there is a corresponding NIS+ directory structure. See Chapter 2, NIS+: An Introduction, for more information about NIS+ directories.

For a complete description of NIS+ directory-related commands and their syntax and options, see the NIS+ man pages.

Using the niscat Command With Directories

The niscat -o command can be used to list the object properties of an NIS+ directory. To use it, you must have read access to the directory object itself.

Listing the Object Properties of a Directory

To list the object properties of a directory, use niscat -o and the directory's name:

niscat -o directory-name

For example:

rootmaster# niscat -o doc.com.
Object Name : doc
Owner : rootmaster.doc.com.
Group :
Domain : Com.
Access Rights : r---rmcdr---r---
Time to Live : 24:0:0
Object Type : DIRECTORY
.
.

Using the nisls Command With Directories

The nisls command lists the contents of an NIS+ directory. To use it, you must have read rights to the directory object.

To display in terse format, use:

nisls [-dgLmMR] directory-name

To display in verbose format, use:

nisls -l [-gm] [-dLMR] directory-name

Listing the Contents of a Directory—Terse

To list the contents of a directory in the default short format, use one or more of the options listed below and a directory name. If you don't supply a directory name, NIS+ will use the default directory.

nisls [-dLMR] directory-name

or

nisls [-dLMR]

For example, this instance of nisls is entered from the root master server of the root domain doc.com.:

rootmaster% nisls doc.com.:
org_dir
groups_dir

Here is another example entered from the root master server:

rootmaster% nisls -R sales.doc.com.
sales.doc.com.:
org_dir
groups_dir
groups_dir.sales.doc.com.: 
admin
org_dir.sales.doc.com.:
auto_master
auto_home
bootparams
cred
.

Listing the Contents of a Directory—Verbose

To list the contents of a directory in the verbose format, use the -l option and one or more of the options listed below. The -g and -m options modify the attributes that are displayed. If you don't supply a directory name, NIS+ will use the default directory.

nisls -l [-gm] [-dLMR] directory-name

or

nisls -l [-gm] [-dLMR]

Here is an example, entered from the master server of the root domain doc.com.:

rootmaster% nisls -l
doc.com.
D r---rmcdr---r--- rootmaster.doc.com. date org_dir
D r---rmcdr---r--- rootmaster.doc.com. date groups_dir

The nismkdir Command

This section describes how to add a nonroot server to an existing domain using the nismkdir command. An easier way to do this is with the nisserver script as described in Chapter 4, Configuring NIS+ With Scripts

The nismkdir command creates a nonroot NIS+ directory and associates it with a master server. (To create a root directory, use the nisinit -r command, described in The nisinit Command. The nismkdir command can also be used to add a replica to an existing directory.

There are several prerequisites to creating an NIS+ directory, as well as several related tasks.

To create a directory, use:

nismkdir [-m master-server] \
 directory-name

To add a replica to an existing directory, use:

nismkdir -s replica-server \
 directory-name
nismkdir -s replica-server \
 org_dir.directory-name
nismkdir -s replica-server \
 groups_dir.directory-name

Creating a Directory

To create a directory, you must have create rights to its parent directory on the domain master server. First use the -m option to identify the master server and then the -s option to identify the replica, use:

nismkdir -m master directory
nismkdir -s replica directory

Always run nismkdir on the master server. Never run nismkdir on the replica machine. Running nismkdir on a replica creates communications problems between the master and the replica.

This example creates the sales.doc.com. directory and specifies its master server, smaster.doc.com. and its replica, rep1.doc.com.. It is entered from the root master server.

rootmaster% nismkdir -m smaster.doc.com. sales.doc.com.
rootmaster% nismkdir -m smaster.doc.com. org_dir.sales.doc.com.
rootmaster% nismkdir -m smaster.doc.com. groups_dir.sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. org_dir.sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. groups_dir.sales.doc.com.

The nismkdir command allows you to use the parent directory's servers for the new directory instead of specifying its own. However, this should not be done except in the case of small networks. Here are two examples:

• The first example creates the sales.doc.com. directory and associates it with its parent directory's master and replica servers.

  rootmaster% nismkdir sales.doc.com

The second example creates the sales.doc.com. directory and specifies its own master server, smaster.doc.com.

rootmaster% nismkdir -m smaster.doc.com. sales.doc.com.

Since no replica server is specified, the new directory will have only a master server until you use nismkdir again to assign it a replica. If the sales.doc.com. domain already existed, the nismkdir command as shown above would have made salesmaster.doc.com. its new master server and would have relegated its old master server to a replica.

Adding a Replica to an Existing Directory

This section describes how to add a replica server to an existing system using the nismkdir command. An easier way to do this is with the nisserver script.

Keep in mind the following principles:

• Root domain servers reside in (are part of) the root domain.

• Subdomain servers reside in (are part of) the parent domain immediately above the subdomain in the hierarchy. For example, if a namespace has one root domain named prime and a subdomain named sub1:

  • The master and replica servers that serve the prime domain are themselves part of the prime domain because prime is the root domain.

  • The master and replica servers that serve the sub1 subdomain are also part of the prime domain because prime is the parent of sub1.

• While it is possible for a master or replica server to serve more than one domain, doing so is not recommended.

To assign a new replica server to an existing directory, use nismkdir on the master server with the -s option and the name of the existing directory, org_dir, and groups_dir:

nismkdir -s replica-server existing-directory-name
nismkdir -s replica-server org_dir. existing-directory-name
nismkdir -s replica-server groups_dir. existing-directory-name

The nismkdir command realizes that the directory already exists, so it does not recreate it. It only assigns it the additional replica. Here is an example with rep1 being the name of the new replica machine:

rootmaster% nismkdir -s rep1.doc.com. doc.com.
rootmaster% nismkdir -s rep1.doc.com. org_dir.doc.com.
rootmaster% nismkdir -s rep1.doc.com. groups_dir.doc.com.

Always run nismkdir on the master server. Never run nismkdir on the replica machine. Running nismkdir on a replica creates communications problems between the master and the replica.

After running the three iterations of nismkdir as shown above, you need to run nisping from the master server on the three directories:

rootmaster# nisping doc.com.
rootmaster# nisping org_dir.doc.com.
rootmaster# nisping group_dir.doc.com.

You should see results similar to these:

rootmaster# nisping doc.com.
Pinging replicas serving directory doc.com. :
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 18 19:54:38 1995
Replica server is rep1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1995
 Pinging ... rep1.doc.com

It is good practice to include nisping commands for each of these three directories in the master server's cron file so that each directory is “pinged” at least once every 24 hours after being updated.

The nisrmdir Command

The nisrmdir command can remove a directory or simply dissociate a replica server from a directory. (When a directory is removed or disassociated from a replica server, that machine no longer functions as an NIS+ replica server for that NIS+ domain.)

When it removes a directory, NIS+ first disassociates the master and replica servers from the directory, and then removes the directory.

• To remove the directory, you must have destroy rights to its parent directory.

• To dissociate a replica server from a directory, you must have modify rights to the directory.

If problems occur, see Removal or Disassociation of NIS+ Directory from Replica Fails.

Removing a Directory

To remove an entire directory and dissociate its master and replica servers, use the nisrmdir command without any options:

nisrmdir directory-name
nisping domain

This example removes the manf.doc.com. directory from beneath the doc.com. directory:

rootmaster% nisrmdir manf.doc.com.
rootmaster% nisping doc.com.

Disassociating a Replica From a Directory

To disassociate a replica server from a directory, you must first remove the directory's org_dir and groups_dir subdirectories. To do this, use the nisrmdir command with the -s option. After each of the subdirectories are removed, you must run nisping on parent domain.

nisrmdir -s replicanameorg_dir.domain
nisrmdir -s replicanamegroups_dir.domain
nisrmdir -s replicaname domain
nisping domain

This example disassociates the manfreplica1 server from the manf.doc.com. directory:

rootmaster% nisrmdir -s manfreplica1 org_dir.manf.doc.com.
rootmaster% nisrmdir -s manfreplica1 groups_dir.manf.doc.com.
rootmaster% nisrmdir -s manfreplica1 manf.doc.com.
rootmaster% nisping manf.doc.com.

If the replica server you are trying to dissociate is down or out of communication, the nisrmdir -s command returns a Cannot remove replicaname: attempt to remove a non-empty table error message. In such cases, you can run nisrmdir -f -s replicaname on the master to force the dissociation. Note, however, that if you use nisrmdir -f -s to dissociate an out-of-communication replica, you must run nisrmdir -f -s again as soon as the replica is back on line in order to clean up the replica's /var/nis file system. If you fail to rerun nisrmdir -f -s replicaname when the replica is back in service, the old out-of-date information left on the replica could cause problems.

The nisrm Command

The nisrm command is similar to the standard rm system command. It removes any NIS+ object from the namespace, except directories and nonempty tables. To use the nisrm command, you must have destroy rights to the object. However, if you don't, you can use the -f option, which tries to force the operation in spite of permissions.

You can remove group objects with the nisgrpadm -d command (see Deleting an NIS+ Group), and you can empty tables with nistbladm -r or nistbladm -R (see Deleting a Table).

To remove a nondirectory object, use:

nisrm [-if] object-name

Removing Nondirectory Objects

To remove nondirectory objects, use the nisrm command and provide the object names:

nisrm object-name...

This example removes a group and a table from the namespace:

rootmaster% nisrm -i admins.doc.com. groups.org_dir.doc.com.
Remove admins.doc.com.? y
Remove groups.org_dir.doc.com.? y

The rpc.nisd Command

The rpc.nisd command starts the NIS+ daemon. The daemon can run in NIS-compatibility mode, which enables it to answer requests from NIS clients as well. You don't need any access rights to start the NIS+ daemon, but you should be aware of all its prerequisites and related tasks. They are described in Prerequisites to Running rpc.nisd.

By default, the NIS+ daemon starts with security level 2.

To start the daemon, use:

rpc.nisd

To start the daemon in NIS-compatibility mode, use:

rpc.nisd -Y [-B]

To start an NIS-compatible daemon with DNS forwarding capabilities, use:

rpc.nisd -Y -B

To start the NIS+ daemon on any server, use the command without options:

rpc.nisd

The daemon starts with security level 2, which is the default.

To start the daemon with security level 0, use the -S flag:

rpc.nisd -S 0

Starting an NIS-Compatible Daemon

You can start the NIS+ daemon in NIS-compatibility mode in any server, including the root master. Use the -Y (uppercase) option:

rpc.nisd -Y

If the server is rebooted, the daemon will not restart in NIS-compatibility mode unless you also uncomment the line that contains EMULYP=Y in the server's /etc/init.d/rpc file.

Starting a DNS-Forwarding NIS-Compatible Daemon

You can add DNS forwarding capabilities to an NIS+ daemon running in NIS-compatibility mode by adding the -B option to rpc.nisd:

rpc.nisd -Y -B

If the server is rebooted, the daemon will not restart in DNS-forwarding NIS-compatibility mode unless you also uncomment the line that contains EMULYP=-Y in the server's /etc/init.d/rpc file and change it to:

EMULYP -Y -B

Stopping the NIS+ Daemon

To stop the NIS+ daemon, whether it is running in normal or NIS-compatibility mode, kill it as you would any other daemon: first find its process ID, then kill it:

rootmaster# ps -e | grep rpc.nisd
root 1081 1 61 16:43:33 ? 0:01 rpc.nisd -S 0
root 1087 1004 11 16:44:09 pts/1 0:00 grep rpc.nisd
rootmaster# kill 1081

The nisinit Command

This section describes how to initialize a machine client using the nisinit command. An easier way to do this is with the nisclient script as described in Setting Up NIS+ Client Machines.

The nisinit command initializes a machine to be an NIS+ client or server. As with the rpc.nisd command, you don't need any access rights to use the nisinit command, but you should be aware of its prerequisites and related tasks. These are described in Initializing an NIS+ Client.

Initializing a Client

You can initialize a client in three different ways:

• By host name

• By broadcast

• By cold-start file

Each way has different prerequisites and associated tasks. For instance, before you can initialize a client by host name, the client's /etc/hosts or /etc/inet/ipnodes file must list the host name you will use and nsswitch.conf file must have files as the first choice on the hosts line. For IPv6 addresses, specify ipnodes as the first choice on the hosts line. Following is a summary of the steps that use the nisinit command.

To initialize a client by host name, use the -c and -H options, and include the name of the server from which the client will obtain its cold-start file:

nisinit -c -H hostname

To initialize a client by cold-start file, use the -c and -C options, and provide the name of the cold-start file:

nisinit -c -C filename

To initialize a client by broadcast, use the -c and -B options:

nisinit -c -B

Initializing the Root Master Server

To initialize the root master server, use the nisinit -rcommand:

nisinit -r

You will need the following information

• The superuser password of the machine that will become the root master server.

• The name of the new root domain. The root domain name must have at least two elements (labels) and end in a dot (for example, something.com.). The last element must be either an Internet organizational name (as shown in Table 18–4), or a two or three character geographic identifier such as .jp. for Japan.

The nis_cachemgr Command

The nis_cachemgr command starts the NIS+ cache manager program, which should run on all NIS+ clients. The cache manager maintains a cache of location information about the NIS+ servers that support the most frequently used directories in the namespace, including transport addresses, authentication information, and a time-to-live value.

At start-up the cache manager obtains its initial information from the client's cold-start file, and downloads it into the /var/nis/NIS_SHARED_DIRCACHE file.

The cache manager makes requests as a client machine. Make sure the client machine has the proper credentials, or instead of improving performance, the cache manager will degrade it.

Starting and Stopping the Cache Manager

To start the cache manager, enter the nis_cachemgr command (with or without the -i option):

client% nis_cachemgr
client% nis_cachemgr -i

Without the -i option, the cache manager is restarted but it retains the information in the /var/nis/NIS_SHARED_DIRCACHE file. The information in the cold-start file is simply appended to the existing information in the file. The -i option clears the cache file and re-initializes it from the contents of the client's cold-start file.

To stop the cache manager, kill it as you would any other process.

The nisshowcache Command

The nisshowcache command displays the contents of a client's directory cache.

Displaying the Contents of the NIS+ Cache

The nisshowcache command is located in /usr/lib/nis. It displays only the cache header and the directory names. Here is an example entered from the root master server:

rootmaster# /usr/lib/nis/nisshowcache -v
Cold Start directory:
Name : doc.com.
Type : NIS
Master Server :
 Name : rootmaster.doc.com.
 Public Key : Diffie-Hellman (192 bits)
 Universal addresses (3)
 . .
Replicate:
 Name : rootreplica1.doc.com.
 Public Key : Diffie-Hellman (192 bits)
 Universal addresses (3)
 .
 .
 .
Time to live : 12:0:0
Default Access Rights :

Pinging and Checkpointing

When a change is made to the NIS+ data set, that change is made in the memory of the master server for the NIS+ domain (or subdomain). A record of the change is also logged in the master server's transaction log (/var/nis/data/trans.log).

Normally, the master server transfers a change in the NIS+ data set to the domain's replica servers 120 seconds (2 minutes) after the change was made. This transfer process is called pinging. When the master server pings a replica, it updates the replica's data set with the change. The changed NIS+ data now resides in memory of the master and replica servers.

If the automatic ping process fails to update one or more replica servers, you need to manually force a ping as described in Forcing a Ping. If you suspect that a replica has not been correctly updated with the most current NIS+ data, you can check when the replica was last updated as described in Displaying When Replicas Were Last Updated.

Changes to the NIS+ data set stored in server memory and recorded in the transaction log need to be written into the NIS+ tables stored on disk. The process of updating the NIS+ tables is called checkpointing.

Checkpointing is not an automatic process. You must issue the checkpoint command as described in Checkpointing a Directory.

The nisping Command

The nisping command is used to:

• Display when a replica was last pinged as described in Displaying When Replicas Were Last Updated.

• Force the master server to ping a replica if the automatic ping cycle has not been successful as described in Forcing a Ping.

• Checkpoint servers as described in Checkpointing a Directory.

Displaying When Replicas Were Last Updated

When used with the -u option, the nisping command displays the update times for the master and replicas of the local domain.

/usr/lib/nis/nisping -u [domain]

To display the last updates in some other domain, specify the domain name in the command line. Note that when used with the -u option, the nisping command does not actually ping any replicas.

For example, to display the most recent replica update times for the local doc.com. domain, you would enter:

rootmaster# /usr/lib/nisping -u
Last updates for directory doc.com.:
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 25 10:53:37 1992
Replica server is rootreplica1.doc.com.
 Last update seen was Wed Nov 25 10:53:37 1992

Forcing a Ping

If the nisping -u command reveals that a replica has not been properly updated, you can use the nisping command to force the master server to ping all the replicas in a domain, or one replica in particular.

To ping all the replicas, use the nisping command without options:

/usr/lib/nis/nisping

This forces the master server to ping all the replicas in the domain. Here is an example that pings all the replicas of the local doc.com. domain:

rootmaster# /usr/lib/nis/nisping
Pinging replicas serving directory doc.com.:
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 25 10:53:37 1992
Replica server is rootreplica1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1992
 Pinging ... rootreplica1.doc.com.

To ping all the replicas in a domain other than the local domain, append a domain name:

/usr/lib/nis/nisping domainname

You can also ping all the tables in all the directories on a single specified host. To ping all the tables in all the directories of a particular host, us the -a option:

/usr/lib/nis/nisping -a hostname

Checkpointing a Directory

Each domain and subdomain should be checkpointed at least once every 24 hour, or more often if the transaction log grows too large in relationship to swap space or total disk space.

Checkpointing large domains, or any domain with a large transaction log, is a time-consuming process which ties up NIS+ servers and slows NIS+ service. While a server is checkpointing, it will still answer requests for service, but it will be unavailable for updates. If possible, checkpoint operations should be scheduled for times when system use is low. You can use the cron file to schedule checkpoint operations.

To perform a checkpoint operation, run nisping -C on the domain's master server. It is good practice to first ping all replicas before checkpointing. This ensures that the replicas are checkpointing data that is current and up to date.

• To checkpoint a particular directory, run the nisping command with the -C directoryname option. For example,

  rootmaster# /usr/lib/nis/nisping rootmaster# /usr/lib/nis/nisping -C org_dir

• To checkpoint all the directories in the local domain, run the nisping command with the -C -a options. For example,

rootmaster# /usr/lib/nis/nisping
rootmaster# /usr/lib/nis/nisping -C -a

Once a server has transferred information from the server's transaction log to the appropriate NIS+ tables, the transactions in the log file are erased to conserve disk space.

For example, to checkpoint all of the directories in the doc.com. domain, you would enter:

rootmaster# /usr/lib/nis/nisping -C -a
Checkpointing replicas serving directory doc.com. :
Master server is rootmaster.doc.com.
 Last update occurred at Wed May 25 10:53:37 1995
Master server is rootmaster.doc.com.
checkpoint has been scheduled with rootmaster.doc.com.
Replica server is rootreplica1.doc.com.
 Last update seen was Wed May 25 10:53:37 1995
Replica server is rootreplica1.doc.com.
checkpoint has been scheduled with rootmaster.doc.com.

The nislog Command

The nislog command displays the contents of the transaction log.

/usr/sbin/nislog 
/usr/sbin/nislog -h [number]
/usr/sbin/nislog -t [number]

Displaying the Contents of the Transaction Log

Each transaction consists of two parts: the particulars of the transaction and a copy of an object definition.

Here is an example that shows the transaction log entry that was made when the doc.com. directory was first created. “XID” refers to the transaction ID.

rootmaster# /usr/sbin/nislog -h 1
NIS Log printing facility.
NIS Log dump:
 Log state : STABLE
Number of updates : 48
Current XID : 39
Size of log in bytes : 18432
***UPDATES***
@@@@@@@@@@@@@@TRANSACTION@@@@@@@@@@@@@@
#00000, XID : 1
Time : Wed Nov 25 10:50:59 1992
Directory : doc.com.
Entry type : ADD Name
Entry timestamp : Wed Nov 25 10:50:59 1992
Principal : rootmaster.doc.com.
Object name : org_dir.doc.com.
...................Object......................
Object Name : org_dir
Owner : rootmaster.doc.com.
Group : admin.doc.com.
Domain : doc.com.
Access Rights : r---rmcdr---r---
Time to Live : 24:0:0
Object Type : DIRECTORY
Name : `org_dir.doc.com.'
Type: NIS
Master Server : rootmaster.doc.com.
.
.
................................................
@@@@@@@@@@@@@@TRANSACTION@@@@@@@@@@@@@@
#00000, XID : 2

The nischttl Command

The nischttl command changes the time-to-live value of objects or entries in the namespace. This time-to-live value is used by the cache manager to determine when to expire a cache entry. You can specify the time-to-live in total number of seconds or in a combination of days, hours, minutes, and seconds.

The time-to-live values you assign objects or entries should depend on the stability of the object. If an object is prone to frequent change, give it a low time-to-live value. If it is steady, give it a high one. A high time-to-live is a week; a low one is less than a minute. Password entries should have time-to-live values of about 12 hours to accommodate one password change per day. Entries in tables that don't change much, such as those in the RPC table, can have values of several weeks.

To change the time-to-live of an object, you must have modify rights to that object. To change the time-to-live of a table entry, you must have modify rights to the table, entry, or columns you wish to modify.

To display the current time-to-live value of an object or table entry, use the nisdefaults -t command, described in Chapter 15, Administering NIS+ Access Rights.

To change the time-to-live value of objects, use:

nischttl time-to-live object-name

or

nischttl [-L] time-to-live object-name

To change the time-to-live value of entries, use:

nischttl time-to-live \
 [column=value,...], \
 table-name

or

nischttl [-ALP] time-to-live \
 [column=value,...], \
 table-name

Where time-to-live is expressed as:

• Number of seconds. A number with no letter is interpreted as a number of seconds. Thus, 1234 for TTL would be interpreted as 1,234 seconds. A number followed by the letter s is also interpreted as a number of seconds. Thus, 987s for TTL would be interpreted as 987 seconds. When seconds are specified in combination with days, hours, or minutes, you must use the letter s to identify the seconds value.

• Number of minutes. A number followed by the letter m is interpreted as a number of minutes. Thus, 90m for TTL would be interpreted as 90 minutes.

• Number of hours. A number followed by the letter h is interpreted as a number of hours. Thus, 9h for TTL would be interpreted as 9 hours.

• Number of days. A number followed by the letter d is interpreted as a number of days. Thus, 7d for TTL would be interpreted as 7 days.

These values may be used in combination. For example, a TTL value of 4d3h2m1s would specify a time to live of four days, three hours, two minutes, and one second.

The following flags may also be used with the nischttl command:

Changing the Time-to-Live of an Object

To change the time-to-live of an object, type the nischttl command with the time-to-live value and the object-name. You can add the -L command to extend the change to linked objects.

nischttl -L time-to-live object-name

You can specify the time-to-live in seconds by typing the number of seconds. Or you can specify a combination of days, hours, minutes, and seconds by using the suffixes s, m, h, and d to indicate the number of seconds, minutes, days, and hours. For example:

client% nischttl 86400 sales.doc.com.
client% nischttl 24h sales.doc.com.
client% nischttl 2d1h1m1s sales.doc.com.

The first two commands change the time-to-live of the sales.doc.com. directory to 86,400 seconds, or 24 hours. The third command changes the time-to-live of all the entries in a hosts table to 2 days, 1 hour, 1 minute, and 1 second.

Changing the Time-to-Live of a Table Entry

To change the time-to-live of entries, use the indexed entry format. You can use any of the options, -A, -L, or -P.

nischttl [-ALP] time-to-live \
 [column=value,...], \
 table-name

C-shell users should use quotes to prevent the shell from interpreting the square brackets ([]) around the column value as a meta character.

These examples are similar to those above, but they change the value of table entries instead of objects:

client% nischttl 86400 '[uid=99],passwd.org_dir.doc.com.'
client% nischttl 24h `[uid=99],passwd.org_dir.doc.com.'
client% nischttl 2d1h1m1s `[name=fred],hosts.org_dir.doc.com.'