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"
- yet another script syntax
- Sample of a SCRI "rdist" script:
HOSTS=(
sp2-1.scri.fsu.edu
sp2-2.scri.fsu.edu
sp2-3.scri.fsu.edu
sp2-4.scri.fsu.edu
.
.
.
)
FILES=(/etc/passwd
/.rhosts
/etc/hosts
/etc/motd.master
.
.
)
# ibms50 (www) is the Web server and has different file requirements
IBMS50FILES=(/etc/passwd
/.rhosts
/etc/hosts
/etc/motd.master
)
${FILES} -> ${HOSTS}
install;
special /etc/motd.master "touch /etc/motd.local 2> /dev/null";
# ibms50 (www) is the Web server and has different file requirements
${IBMS50FILES} -> ibms50
install;
special /etc/motd.master "touch /etc/motd.local 2> /dev/null";
2. It can be easier to write your own scripts using "rcp"
3. "distrib" - home-grown distribution shell script
- must be trusted as root by each machine in list
- /.rhosts contains "nu" on each machine
- if all remote execution scripts reference the same
file lists then you only have to update these lists
when adding a new machine
-------------------------------------------------
#!/bin/csh
echo "distribute $2 to machine list $1"
set hosts=" `cat $1` "
foreach i ( $hosts )
if ( { set x=`/usr/etc/ping $i 5` } ) then
if ( $#argv == 2 ) then
rcp $2 $i\:$2
echo "-------$i copied $2"
else if ($#argv == 3) then
rcp $2 $i\:$3
echo "-------$i copied $2 to $3"
else
echo "Error in arguments"
exit 0
endif
else
echo "-------$i dead"
endif
end
-------------------------------------------------
- Example invocation: "distrib /tmp/newmotd /etc/motd"
4. "rc" - remote command home-grown script
- execute a command for named machine list
-------------------------------------------------
#!/bin/csh
#
set hosts=" `cat $1` "
foreach i ( $hosts )
if ( { set x=`ping $i 5` } ) then
echo "$i--------------------------- "
rsh $i $argv[2-]
else
echo "-------$i dead"
endif
end
-------------------------------------------------
- example: rc solaris 'df -k | grep 0s0'
C. Centralized tables - pull copies
1. simple methods
- Use "rcp" - remote copy
example: "rcp xi:/etc/motd /etc/motd"
- would like to be able to copy from non-trusted machines
- for example, would like to use FTP or other programs
that are written for interactive use...how?
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 "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: ftp.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 boyd-thesis.ps.Z\n"}
expect "ftp>" {send "quit\n"}
send_user "Got the file..\n"
exit 0
things "expect" can do:
+ Cause your computer to dial you back, so that you
can login without paying for the call.
+ Run fsck, and in response to its questions, answer
"yes", "no" or give control back to you, based on
predetermined criteria.
+ Connect to another network or BBS (e.g., MCI Mail,
CompuServe) and automatically retrieve your mail so
that it appears as if it was originally sent to
your local system.
+ Carry environment variables, current directory, or
any kind of information across rlogin, telnet, tip,
su, chgrp, etc.
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. 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)
3. clients
ypbind
> binds client machine to a server
> must have "domainname" set
> usually broadcasts for a server with "domainname"
> security hole, why? (see bottom of pg. 395)
> should specifically request service from a machine
> must be supporting RPC services
> this means must have portmapper running
> the server must also run ypbind
4. netgroups - grouping mechanism
where member is a triple (hostname, username, domainname)
lpdaemon2 (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
- (,,csdept) - the domain field is the domain that the triple is
valid, not the trusted domain, the above example is universal
5. user commands
see list on page 398 of USA
Linux "ypbind" package comes with:
ypcat - ypcat passwd | grep kuncick
ypmatch - ypmatch kuncick passwd
yppasswd - not implemented here
yppoll - yppoll passwd
ypset - forces ypbind to connect to a particular server
ypwhich - should return nu
6. functions
- a number of programmer's functions making use of
NIS are in section 3 of the "man" pages.
7. advantages and disadvantages
- no subdomains
> would like
(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
- 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 (see
"OPTIONS" below). Using the
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!