A. Introduction
Several general methods of distributing information:
1. Centralized
a. "push" copies (server to multiple clients)
b. "pull" copies (multiple clients to server)
c. Access on each lookup (NIS) (a form of "pulling")
2. Distributed
- There is no one global map
- DNS is an example, Web service is another
B. Centralized UNIX-based tables - push copies
1. "rdist"
2. Write your own scripts using "rcp"
C. Centralized tables - pull copies
1. Write your own scripts using "rcp"
2. Use "expect"
- A regular script allows you to simply fork()-exec() a
subprocess
- Many interactive programs think that they are manipulating a real
terminal
- They can't be run from a shell script
- The "expect" program runs its subprocesses using pseudo-terminals
- The "expect" program is a set of extensions to TCL (the Tool
Command Language)
- "expect" differs from other scripting languages in that it
allows for incremental step-by-step control of subprocesses
- Three basic "expect" commands are:
spawn - start up a subprocess to control
send - feed input to a subprocess
expect - take action depending on a subprocess's output
Example:
#!/usr/local/bin/expect -f
spawn /usr/ucb/ftp ftp.cs.fsu.edu
expect "Name*: " {send "anonymous\n"}
expect "Password:" {send "[exec whoami]@.cs.fsu.edu\n"}
expect "ftp>" {send "cd /pub/thesis\n"}
expect "ftp>" {send "binary\n"}
expect "ftp>" {send "get my-thesis.ps.Z\n"}
expect "ftp>" {send "quit\n"}
send_user "Got the file..\n"
exit 0
A good book on expect is Exploring Expect
D. Centralized tables - access on each lookup
1. NIS
- The flat files (usually in /etc)
automount tables, passwd, ethers, netgroup, aliases
> The "real" copy sits on the servers, the clients have
copies with "+" signs in them
- the maps (/var/yp/)
> Served to clients (nu:/var/yp/csdept)
2. NIS servers
ypinit -m
> Creates a master yp server
> Creates the maps from scratch
> Uses a Makefile in /var/yp
ypmake
> Updates the maps
> Use this when you have modified a flat file
cd /var/yp
ypmake
ypserv
> The server daemon
> One important flag (-d) says go to DNS if /etc/hosts
can't resolve name; interesting that YP predates DNS!
3. NIS clients
ypbind
> Binds client machine to a server
> Must have "domainname" set
> Usually broadcasts for a server with "domainname"
> Should specifically request service from a machine
> Requires Sun's RPC services to operate
--> this means you must have portmapper running
--> the server must also run ypbind
4. netgroups - grouping mechanism
Where member is a triple (hostname, username, domainname),
for example:
lpdaemon (mary,daemon,) (export,daemon,) (touch,daemon,)\
(awk,daemon,) (look,daemon,) (listen,daemon,) (nice,daemon,)\
(biff,daemon,) (close,daemon,) (sleep,daemon,) (wall,daemon,)\
(ping,daemon,) (click,daemon,) (omega,daemon,)
(awk,daemon,) (look,daemon,) (listen,daemon,) (nice,daemon,)\
(biff,daemon,) (close,daemon,) (sleep,daemon,) (wall,daemon,)\
(ping,daemon,) (click,daemon,) (omega,daemon,)
- this allows user daemon on named host to be trusted
- (,,) is a universal (wildcard matching anything)
- (,,csdept) - the domain field is the domain that the triple is
valid, not the trusted domain, the above example is universal
- Note the backslashes to continue the line
5. NIS user commands
Linux "ypbind" package comes with:
ypcat - "ypcat passwd | grep jtbauer"
ypmatch - "ypmatch jtbauer passwd"
yppasswd - not implemented here
yppoll - "yppoll passwd"
ypset - forces ypbind to connect to a particular server
ypwhich - should return nu
6. NIS functions
- A number of programmer's functions making use of
NIS are in section 3 of the "man" pages.
7. Advantages and disadvantages of NIS
- No subdomains
> Would like, but can't do under NIS:
(class of users, class of machines) setup
passwd.grads gradlab
passwd.majors faculty
passwd.staff majorslab
(passwd.grads: gradlab, majorslab)
- Performance hog
> Look at nu's load
> Can use slave servers
> Consistency problems
- Security holes
8. NIS+
- Totally rewritten from the ground up
- Borrows the DNS style of hierarchy
- Supposedly more secure
- Complex, not discussed here
9. Finally, some vendor-specific solutions exist for sharing files
among machines from the same vendor. Too detailed to cover here,
but check your vendor's specifics! Example - HP-UX has the
concept of a "cluster" that can be managed by "sam".
UNIX and Windows NT File Compatability
Interoperability between many networked operating systems is possible. The general approach is to either have both sides agree to use a set of open standards and exchange information (example - an NFS client package installed on a Windows PC interacting with an UNIX-based NFS server) or to have one side "pretend" to be something recognizable to the other operating system. A popular UNIX-based example of this is Samba.
Samba
Samba is used within the department, where NT users' home directories are
really their UNIX home directories that are Samba-mounted as network drives
on the NT machines.
On xi, the Samba daemons (smbd and nmbd) are started from /etc/rc2.d/S86samba:
#!/bin/sh
# Start xdm for the xterminals
if [ -f /usr/samba/lib/smb.conf ]; then
/usr/samba/bin/smbd -D
/usr/samba/bin/nmbd -D
echo "samba"
fi
The smbd daemon, to quote from the man page:
smbd is a server that can provide most SMB services. The server provides filespace and
printer services to clients using the SMB protocol. This is compatible with the LanManager
protocol, and can service LanManager clients.
The nmbd daemon:
nmbd is a server that understands and can reply to netbios name service requests, like
those produced by LanManager clients. It also controls browsing.
LanManager clients, when they start up, may wish to locate a LanManager server.
That is, they wish to know what IP number a specified host is using.
This program simply listens for such requests, and if its own name is specified it will
respond with the IP number of the host it is running on. "Its own name" is by default the
name of the host it is running on, but this can be overriden with the -n option.
Nmbd can also be used as a WINS (Windows Internet Name Server) server. It will
do this automatically by default. What this basically means is that it will respond to all
name requests that it receives that are not broadcasts, as long as it can resolve the
name.
Operation of Samba is controlled by the "smb.conf" file, which contains Windows-style
stanzas. An example, from the INSTALL.txt file:
The simplest useful configuration file would be something like this:
workgroup = MYGROUP
[homes]
guest ok = no
read only = no
which would allow connections by anyone with an account on the server,
using either their login name or "homes" as the service name. The options
available in smb.conf are, unfortunately, quite complex -- read the "smb.conf"
man page for all the details!
Samba version 2 has better support for NT domains as well.