*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> ypxfr (8)              



NAME    [Toc]    [Back]

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

SYNOPSIS    [Toc]    [Back]

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

OPTIONS    [Toc]    [Back]

       Specifies  that  NIS  maps  are to be stored in one of the
       following formats: 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.  Otherwise,  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 service 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 notation.  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    [Toc]    [Back]

       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 possible 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    [Toc]    [Back]

       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 database 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 support for very large maps.  NIS  clients  are  not
       affected by these enhancements.

EXAMPLES    [Toc]    [Back]

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

FILES    [Toc]    [Back]

       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    [Toc]    [Back]

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

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

       Files: ypfiles(4)

[ Back ]
 Similar pages
Name OS Title
ypbind HP-UX Network Information Service (NIS) server, binder, and transfer processes
ypxfrd HP-UX Network Information Service (NIS) server, binder, and transfer processes
ypserv HP-UX Network Information Service (NIS) server, binder, and transfer processes
yppoll Tru64 determine which version of a Network Information Service (NIS) map is at a master NIS server host
ypxfr FreeBSD transfer NIS database from remote server to local host
ypxfr Linux transfer NIS database from remote server to local host
ypset HP-UX bind to particular Network Information Service server
ypbind Tru64 Network Information Service (NIS) server and binder processes
ypserv Tru64 Network Information Service (NIS) server and binder processes
ypwhich HP-UX list which host is Network Information System server or map master
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service