Chapter 17: Sharing System Files Stephen Workman

Sharing System Files Tens (or hundreds) of configuration files per host Many hosts on network How do you manage these thousands of configuration files?

File Copying Systems A master copy of each configuration file is kept in one place and is distributed to members of the group. this solution is simple it works on every Linux (and UNIX) system easy to set up and maintain clients can miss updates ANY change must propagate to EVERY host

Central Database Server Each machine obtains its configuration information from a central database clients can't miss updates, even if they are down when a change is made entire network can hang if server goes down quite a few files are not supported by any of the common database services; copying files may still be needed NIS and LDAP are a few examples (more on this later)

Commonly Shared Files /etc/passwd /etc/shadow /etc/group /etc/hosts /etc/networks /etc/services /etc/protocols /etc/ethers /etc/mail/aliases /etc/rpc /etc/netgroup /etc/cups/printcap /etc/printcap.cups /etc/termcap

File Copying Systems Push Model master server periodically distributes the freshest files to each client Files can be pushed when a change is made or on a regular schedule Pull Model client responsible for updating itself less centralized, but more adaptable and secure

rdist pushes files easiest way to distribute files from a central server rdist uses a control file to manage changes distfile or Distfile

rdist Server Side: Distfile label: pathnames -> destination commands label associates name with the statement rdist label distributes only files described in line pathnames and destinations are lists of files to be copied hosts to copy them to by default rdist copies the files and directories listed in pathnames to the equivalent paths on each destination machine

Supported Commands install options [destdir]; notify namelist; except pathlist; except_pat patternlist; special [pathlist] string; cmdspecial [pathlist] string; p507

Distfile Example

Client Side you must tell sshd on the clients to trust the host from which you are distributing files generate a plaintext key for the master host and store a copy of the public portion in the file ~root/.ssh/authorized_keys

rsync similar to rdist, but can run as a pull or push doesn't use a file-copying control file transmits differences in files instead of whole files main advantage is that receiving machine can run the remote side as a server process out of xinetd or inetd you cannot rsync to multiple hosts at once or execute arbitrary commands on the client

rsync Server Side rsync -gopt --password-file=/etc/rsync.pwd /etc/passwd boulder::sysfiles -gopt: preserves group, owner, permissions, and modification times the password in /etc/rsync.pwd authenticates the connection the '::' makes rsync contact the remote rsync directly on port 873 instead of using ssh /etc/passwd is transfered to boulder

Client Side: rsyncd.conf

rdist vs. rsync rdist more flexible and configurable can execute arbitrary commands on clients push only rsync more secure push or pull can't execute arbitrary commands on clients can't rsync to multiple hosts at once

Pulling Files Easiest way is to use ftp wget ftp transmits data in plain text bad bad bad rsync can be set up to pull as well slightly more complex than ftp, but all the benefits of rsync

NIS: Network Information Service A little history released in the 1980s originally called the Sun Yellow Pages commands still begin with yp supported by every Linux distribution

NIS: The record record unit of sharing is not a file, but a record record corresponds to one line in a config file master server maintains the authoritative copies of system files in their original locations data files (stored in /var/yp) preprocessed into hash library after files are edited, running make will convert them into their hashed formats only one key per entry (several maps per file) /etc/passwd into passwd.byname and passwd.byuid

NIS: Slave Servers NIS allows you to replicate maps on a set of slave servers relieves the load on the master clients can still work even if some servers are down a change on the master is propagated down to the slave servers clients cannot distinguish between master and slaves NIS domains listed under /etc/yp.conf one line for each server

Important NIS Commands and Daemons Daemons ypserv ypbind ypxfrd yppasswdd Commands domainname ypxfr yppush ypset yppoll ypcat yppasswd

Slave Servers Map ypservers contains a list of all the servers in the domain automatically constructed when the domain is set up (by ypinit) examined when master needs to distribute maps to slaves

NIS: How it Works NIS's data files are stored in /var/yp 1 map for each key by which a file can be searched /var/yp/cssuns/passwd.byname /var/yp/cssuns/passwd.byuid A makefile in /var/yp generates all the common NIS maps after modifying a system file cd to /var/yp and run make

Moving Maps to Slave Servers ypxfr this is a pull command and must be run from the slave usually run every so often to ensure most recent maps cron yppush instructs a slave server to execut ypxfr

Server Side: Setting up NIS domain Master Server cd /var/yp /*The NIS directory*/ domainname foo/*Name the new domain*/ /usr/lib/yp/ypinit -m/*Initialize as master server*/ ypserv/*Start the NIS server*/ Slave Server cd /var/yp /usr/lib/yp/ypinit -s master ypserv

Access Control Options /etc/ypserv.conf

Configuring NIS clients Need to inform clients that they are a member of the new domain (servers are generally clients too) domainname name command sets a machine's NIS domain edit /etc/nsswitch.conf chkconfig ypbind on There are some distribution differences...

LDAP: Lightweight Directory Access Protocol data takes the form of property lists (entries) LDAP specifications don't really speak to the database itself, jut the way it's accessed entry consists of a set of named attributes along with those attributes' values an attribute can have several values similar to windows registry

LDAP entry: /etc/passwd line

OpenLDAP slapd is the standard server daemon after editing this file you should be able to start the server with slapd (no arguments)

NIS replacement by LDAP RFC2307 describes converting NIS mapping to LDAP very long story short, just use a pearl script like migrate_group to convert to LDAP standard verify by running slapcat, which displays the entire database