ypxfr man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

ypxfr(8)							      ypxfr(8)

NAME
       ypxfr  -	 Transfer  a  Network Information Service (NIS) map from a NIS
       server to the local host

SYNOPSIS
       /var/yp/ypxfr [-a method] -f  [-h host] -d [domain] [-c] [-C  tid  prog
       ipadd port] mapname

OPTIONS
       Specifies  that	NIS maps are to be stored in one of the following for‐
       mats: btree -- Recommended when creating	 and  maintaining  very	 large
       maps.   dbm/ndbm	 --  For backward compatibility.  This is the default.
       hash -- A potentially quicker method for managing  small	 maps.	 Force
       the  transfer  to  occur	 even if the version at the MASTER is not more
       recent than the local version.  Do  not	send  a	 “Clear	 current  map”
       request	to  the	 local	ypserv process.	 This option should be used if
       ypserv is not running locally at the time when ypxfr is running. Other‐
       wise,  ypxfr  will report that it can not talk to the local ypserv, and
       the transfer will fail.	Get the map from host, regardless of which map
       is  the	master.	 If host is not specified, ypxfr will ask the NIS ser‐
       vice for the name of the master, and try to get	the  map  from	there.
       The  host option can be a name or an IP address in dotted numeric nota‐
       tion.  Specify a domain other than the default domain.  This option  is
       only  for  use by ypserv.  When ypserv invokes ypxfr, it specifies that
       ypxfr should call back a yppush process at the  host  with  IP  address
       ipaddr,	registered as program number prog, listening on port port, and
       waiting for a response to transaction tid.

DESCRIPTION
       The ypxfr command moves a NIS map, specified by the  mapname  argument,
       to  the	local host by making use of normal NIS services.  It creates a
       temporary map in	 the  directory	 /var/yp/domain	 (which	 must  already
       exist),	fills  it  by  enumerating  the map's entries, obtains the map
       parameters (master and order number) and loads them into the map.  Once
       ypxfr  has accomplished these tasks, it deletes any old versions of the
       map and moves the temporary map to the real mapname.

       If ypxfr is run interactively, it writes its output  to	the  terminal.
       However,	 if  it	 is invoked without a controlling terminal, and if the
       log file /var/cluster/members/{memb}/yp/ypxfr.log  exists,  it  appends
       all  its	 output	 to  that  file.   Since  ypxfr is most often run from
       /var/spool/cron/crontab/root, or by ypserv, you can use the log file to
       retain a record of what was attempted, and the results.

       For  consistency	 between servers, ypxfr should be run periodically for
       every map in the NIS  database.	Different  maps	 change	 at  different
       rates:	the  services.byname  map may not change for months at a time,
       for instance, and may therefore be checked only once a day. It is  pos‐
       sible  that mail.aliases or hosts.byname changes several times per day.
       In such a case, it is  appropriate  to  check  hourly  for  updates.  A
       cron(8)	entry should be used to perform periodic updates automatically
       on NIS server machines only.  Rather than having a separate cron	 entry
       for each map, commands can be grouped to update several maps in a shell
       script.	Examples (mnemonically named) are in  /var/yp:	ypxfr_1perday,
       ypxfr_2perday,  and ypxfr_1perhour. They can serve as models for you to
       use.

       See ypfiles(4) and ypserv(8) for an overview of NIS.

RESTRICTIONS
       You must use the same database format for each  map  in	a  domain.  In
       addition, a server serving multiple NIS domains must use the same data‐
       base format for all domains.

       Although a Tru64 UNIX NIS server that takes advantage  of  btree	 files
       will be able to store very large maps, NIS slave servers that lack this
       feature might have a much smaller limit on the number  of  map  entries
       they  can handle.  It may not be possible to distribute very large maps
       from a Tru64 UNIX NIS master server to a slave server that  lacks  sup‐
       port  for  very	large  maps.   NIS  clients  are not affected by these
       enhancements.

EXAMPLES
       The following is an example of the ypxfr command used  with  the	 btree
       database routine to store NIS maps.  ypxfr -a b group.byname

FILES
       The  ypxfr  log	file. Each cluster member has its own copy.  Script to
       transfer maps once a day.  Script to transfer maps twice a day.	Script
       to transfer maps once an hour.  The crontab script.

SEE ALSO
       Commands: cron(8), yppush(8), ypserv(8), ypsetup(8)

       Functions: btree(3), dbm(3), dbopen(3), hash(3), ndbm(3)

       Files: ypfiles(4)

								      ypxfr(8)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net