Berkeley R Utilities the new S Utilities

1. Berkeley R Utilities & the new S Utilities The Unix (or Berkeley) r utilities provide an alternative to IP facilities telnet and ftp. Three programs: rlogin hostname remote login rsh hostname command remote command rcp [host:]file [host:]file remote copy, from to scp user1@host:file user2@host:file secure copy, from to ssh hostname remote command rdist remote distrubtuion For R family: passwords not required if .rhosts files configured friendly hosts defined for all normal users in /etc/hosts.equiv users may add to this list in $HOME/.rhosts For S family: you need to exchange keys (RedHat 9+ default) Users may add friendly hosts in $HOME/.ssh/authorized_keys Keys must be give to you from remote host $HOME/.ssh/id_rsa.pub Keys generated with ssh-keygen �t rsa Is installed by default in most Unixes nowdays (R Family is not) The classic R utilities allow the specification of trusted hosts and users on the system. A trusted user can access the local system without specifying a password. The entries in the /etc/hosts.equiv control access on a system-wide basis. If a hostname is specified in this file, then everybody from that system can access the local machine using their own name. If a user name is given in addition to the hostname, then that user can access the local system (from the corresponding host) as any local user (except root) without entering a password. The .rhosts file is used to specify trusted users on a per-user basis. It is based in user's home directory and grants permission for remote user of the same name to use local machine without knowing the password. This mechanism is convenient when someone owns user names on more than one host. Using: rlogin/rsh/rcp will try to login on remote host with your locally logged in user, if hosts.equiv or .rhosts list you, you are permitted login without password. Installing classic R-Utilities: rsh-server Rsh is enough if you dont plan to be able checking remotely who is logged in, then you need those as well: rwho rusers rusers-server Activating r-family: chkconfig rsh on ; chkconfig rlogin on ; chkconfig rusersd on ; service rusersd start The classic R utilities allow the specification of trusted hosts and users on the system. A trusted user can access the local system without specifying a password. The entries in the /etc/hosts.equiv control access on a system-wide basis. If a hostname is specified in this file, then everybody from that system can access the local machine using their own name. If a user name is given in addition to the hostname, then that user can access the local system (from the corresponding host) as any local user (except root) without entering a password. The .rhosts file is used to specify trusted users on a per-user basis. It is based in user's home directory and grants permission for remote user of the same name to use local machine without knowing the password. This mechanism is convenient when someone owns user names on more than one host. Using: rlogin/rsh/rcp will try to login on remote host with your locally logged in user, if hosts.equiv or .rhosts list you, you are permitted login without password. Installing classic R-Utilities: rsh-server Rsh is enough if you dont plan to be able checking remotely who is logged in, then you need those as well: rwho rusers rusers-server Activating r-family: chkconfig rsh on ; chkconfig rlogin on ; chkconfig rusersd on ; service rusersd start

2. Exercise - Who has Remote Access Here are three files from mash4077 Can root on seoul copy files to/from mash4077? Can hawkeye on seoul run commands on mash4077? Can hawkeye on rosies run commands on mash4077? Can root on mash4077 copy files to/from rosies? Can bfpierce on division copy files to mash4077? Can root on seoul login to mash4077?

3. Remote shells The rsh (remsh) command run a command on a named host standard I/O can be redirected as normal /etc/profile and .profile not executed requires /etc/hosts.equiv or $HOME/ .rhosts file to be configured From a02 or a03 you issue the commands below: The rsh command allows you to execute a specified command on a remote system. You can only use rsh if you are a trusted user as specified in the /etc/hosts.equiv or .rhosts files on the remote system. By default, rsh will use the name with which you logged onto the local system. Although the command given to rsh is run on the remote machine, the stdin, stdout and sdterr are connected to the local system. Consequently, any I/O redirection of the command takes place on the local machine. If you don't specify a command, then rsh defaults to the same operation as rlogin. If missmatch exist, you are asked for password. In the example below, you are logged in as root on your server a01. You want to prepare a01 to use r-family utilities from a02 and a03 to work on a01) # hostname a01 To let root from a02 and a03 login as root on a01 (assuming that you are root), then you have to do this on a01 $HOME/.rhosts: a02 root a03 root /etc/hosts: 127.0.0.1 localhost.localdomain localhost a01 192.168.0.1 a01.my-site.com a01 # This host IP address! 192.168.0.2 a02.my-site.com a02 # Other important hosts 192.168.0.3 a03.my-site.com a03 192.168.0.4 a04.my-site.com a04 192.168.0.5 a05.my-site.com a05 192.168.0.6 a06.my-site.com a06 /etc/hosts.equiv: a02 a03The rsh command allows you to execute a specified command on a remote system. You can only use rsh if you are a trusted user as specified in the /etc/hosts.equiv or .rhosts files on the remote system. By default, rsh will use the name with which you logged onto the local system. Although the command given to rsh is run on the remote machine, the stdin, stdout and sdterr are connected to the local system. Consequently, any I/O redirection of the command takes place on the local machine. If you don't specify a command, then rsh defaults to the same operation as rlogin. If missmatch exist, you are asked for password. In the example below, you are logged in as root on your server a01. You want to prepare a01 to use r-family utilities from a02 and a03 to work on a01) # hostname a01 To let root from a02 and a03 login as root on a01 (assuming that you are root), then you have to do this on a01 $HOME/.rhosts: a02 root a03 root /etc/hosts: 127.0.0.1 localhost.localdomain localhost a01 192.168.0.1 a01.my-site.com a01 # This host IP address! 192.168.0.2 a02.my-site.com a02 # Other important hosts 192.168.0.3 a03.my-site.com a03 192.168.0.4 a04.my-site.com a04 192.168.0.5 a05.my-site.com a05 192.168.0.6 a06.my-site.com a06 /etc/hosts.equiv: a02 a03

4. Remote distribution -rdist The rdist command replicating/maintain identical copies of files over multiple hosts relies on rlogin and rsh can use ssh as transport for secure mode rdist is client software and rdistd is server software the server rdistd is started via rsh or ssh on the server R-family rsh requires: /etc/hosts.equiv or $HOME/ .rhosts file to be configured S-family ssh requires: $HOME/.ssh/rsa_key.pub to be copied from remote server/client Uses a special file Distfile for updating and maintaining files Can syslog to /var/log/messages file RDIST HOME: http://www.magnicomp.com/rdist/ The rdist command is SuSE standard RDist is an open source program to maintain identical copies of files over multiple hosts. It preserves the owner, group, mode, and mtime of files if possible and can update programs that are executing. Almost all versions of UNIX include RDist. However, most that do include a very old version sometimes referred to as "4.2BSD rdist", "rdist classic", or "rdist version 3". Look after that you have rdist version 6.1 or greater! rdist �V Rdist follows with SuSE! Rdist is exellent to mass distribute configuration files and directories after installations.RDist is an open source program to maintain identical copies of files over multiple hosts. It preserves the owner, group, mode, and mtime of files if possible and can update programs that are executing. Almost all versions of UNIX include RDist. However, most that do include a very old version sometimes referred to as "4.2BSD rdist", "rdist classic", or "rdist version 3". Look after that you have rdist version 6.1 or greater! rdist �V Rdist follows with SuSE! Rdist is exellent to mass distribute configuration files and directories after installations.

5. Remote distribution �preparation Pepare a master-server and a client files to replicate Logins must be done without password on clients, or rdist fails. With R-Family: setup server and clients like in this chapter. With S-Family: Generate keys and distribute server keys to all clients, look below. S-Family: Enable ssh root-logins on all clients. Create a Distfile with files and directories to update on your clients with. Enable root logins (trusted enviroment only) on all clients: sshd config file: /etc/ssh/sshd_config: PermitRootLogin yes AuthorizedKeysFile .ssh/authorized_keys First of all, one of the available nodes should be designated as a master-server from which relevant configuration files will be replicated. The master-server does not necessarily have to be identical to the nodes. A common user filespace must be provided on a file-server somewhere in your network. Needless to say, the master-server and especially the file-server machines (which could possibly be the same machine) must be highly reliable in order to ensure the availability of the nodes. The purpose of these steps is to ensure that the superuser as well as ordinary users can communicate freely (without having to enter passwords) within the system. At the same time, this communication should be secure (i.e., encrypted). First of all, one of the available nodes should be designated as a master-server from which relevant configuration files will be replicated. The master-server does not necessarily have to be identical to the nodes. A common user filespace must be provided on a file-server somewhere in your network. Needless to say, the master-server and especially the file-server machines (which could possibly be the same machine) must be highly reliable in order to ensure the availability of the nodes. The purpose of these steps is to ensure that the superuser as well as ordinary users can communicate freely (without having to enter passwords) within the system. At the same time, this communication should be secure (i.e., encrypted).

6. Remote distribution �preparation test Generate server private and public keys: As root generate server keys on server: # ssh-keygen �t rsa Copy keys to identity files: # cd .ssh ; cp id_rsa identity ; cp id_rsa.pub identity.pub Distribute public keys to clients: Create client private and public keys: # ssh <client ip> ssh-keygen �t rsa Distribute server public key to all your clients (they need /root/.ssh catalog): # scp identity.pub <client ip>:.ssh/authorized_keys As root on the server, test root password-less login rights to all of the nodes/clients by: # ssh node01 date sat dec 12 14:52:55 CET 2004 If it does not work, then check that client have the server public key: # ls �l /root/.ssh/authorized_keys If file exist check that you can see exactly the server key, authorized_kets can contain several keys: On server, # cat /root/.ssh/identity.pub On client, # cat /root/.ssh/authorized_keys Generally, you invate the server on the client by transferring and adding the server public key to the client authorized_keys files. Also check that you allow to login as root on the clients! Server public key can be a part of client first installation!If it does not work, then check that client have the server public key: # ls �l /root/.ssh/authorized_keys If file exist check that you can see exactly the server key, authorized_kets can contain several keys: On server, # cat /root/.ssh/identity.pub On client, # cat /root/.ssh/authorized_keys Generally, you invate the server on the client by transferring and adding the server public key to the client authorized_keys files. Also check that you allow to login as root on the clients! Server public key can be a part of client first installation!

7. Remote distribution -Distfile Used to specify how replication should take place The Distfile format: <variable name> `=' <name list> [ label: ] <source list> `->' <destination list> <command list> [ label: ] <source list> `::' <time_stamp file> <command list> The label is optional. HOSTS is in our example all hosts and logins that FILES can be replicated to/from ${FILES} -> ${HOSTS} sends files to list of hosts. /usr/src/bin -> arpa sends catalog with contents to host arpa Commands list is instrcution howto install/operate with lists/files The following is a small example of Distfile: HOSTS = ( matisse root@arpa) FILES = ( /bin /lib /usr/bin /usr/games /usr/include/{*.h,{stand,sys,vax*,pascal,machine}/*.h} /usr/lib /usr/man/man? /usr/ucb /usr/local/rdist ) EXLIB = ( Mail.rc aliases aliases.dir aliases.pag crontab dshrc sendmail.cf sendmail.fc sendmail.hf sendmail.st uucp vfont ) ${FILES} -> ${HOSTS} install -oremove,chknfs ; except /usr/lib/${EXLIB} ; except /usr/games/lib ; special /usr/lib/sendmail "/usr/lib/sendmail -bz" ; srcs: /usr/src/bin -> arpa except_pat ( \\.o\$ /SCCS\$ ) ; IMAGEN = (ips dviimp catdvi) imagen: /usr/local/${IMAGEN} -> arpa install /usr/local/lib ; notify ralph ; ${FILES} :: stamp.cory notify root@cory ; The following is a small example of Distfile: HOSTS = ( matisse root@arpa) FILES = ( /bin /lib /usr/bin /usr/games /usr/include/{*.h,{stand,sys,vax*,pascal,machine}/*.h} /usr/lib /usr/man/man? /usr/ucb /usr/local/rdist ) EXLIB = ( Mail.rc aliases aliases.dir aliases.pag crontab dshrc sendmail.cf sendmail.fc sendmail.hf sendmail.st uucp vfont ) ${FILES} -> ${HOSTS} install -oremove,chknfs ; except /usr/lib/${EXLIB} ; except /usr/games/lib ; special /usr/lib/sendmail "/usr/lib/sendmail -bz" ; srcs: /usr/src/bin -> arpa except_pat ( \\.o\$ /SCCS\$ ) ; IMAGEN = (ips dviimp catdvi) imagen: /usr/local/${IMAGEN} -> arpa install /usr/local/lib ; notify ralph ; ${FILES} :: stamp.cory notify root@cory ;

8. Remote distribution �execute rdist Create some testfiles to distribute among clients. # vi /etc/my-rdist-testfile This is the rdist test file! Create a Distfile This file willl replicate the ETCFILES onto all the NODES. Replicate the files using rdist together with SSH You may want to run this command every night on your master-server by using the crontab command. A key technology in a cluster/homogenus enviroment is the ability to change a configuration file or install a software in, e.g., the /usr/local directory, and have those files automatically become available on all nodes. Recommendation is use of the server-push method implemented by the widely available rdist (Remote Distribution) technology. The Distfile, a configuration file telling rdist which files must be replicated exactly from the master-server onto all nodes. Note! that the indented lines actually must contain a leading TAB character, according to the syntax of rdist. Here is a more complete Distfile, which takes into account a number of system configuration files which we have decided to replicate: # Special files for nodes # NODEFILES = ( /etc/nodefiles ) ${NODEFILES} -> ${NODES} install /; # Files duplicated from the server ETCFILES = ( /etc/fstab /etc/passwd /etc/group /.profile /.cshrc /.login /.shosts /etc/inittab /etc/resolv.conf /etc/inetd.conf /etc/syslog.conf /etc/shells /etc/motd /etc/tcpd /etc/hosts.allow /etc/hosts.deny /etc/hosts.equiv /var/adm/sendmail/aliases* /etc/sendmail.cf /etc/ssh_known_hosts /etc/sysconfig /etc/Distfile ) ${ETCFILES} -> ${NODES} install; special /etc/syslog.conf "kill -HUP `cat /var/run/syslog.pid`"; special /etc/xinetd.conf "kill -HUP `cat /var/run/inetd.pid`"; # Files in /usr/local USRFILES = ( /usr/local/* ) ${USRFILES} -> ${NODES} install -oremove; except /usr/local/var/locatedb;A key technology in a cluster/homogenus enviroment is the ability to change a configuration file or install a software in, e.g., the /usr/local directory, and have those files automatically become available on all nodes. Recommendation is use of the server-push method implemented by the widely available rdist (Remote Distribution) technology. The Distfile, a configuration file telling rdist which files must be replicated exactly from the master-server onto all nodes. Note! that the indented lines actually must contain a leading TAB character, according to the syntax of rdist. Here is a more complete Distfile, which takes into account a number of system configuration files which we have decided to replicate: # Special files for nodes # NODEFILES = ( /etc/nodefiles ) ${NODEFILES} -> ${NODES} install /; # Files duplicated from the server ETCFILES = ( /etc/fstab /etc/passwd /etc/group /.profile /.cshrc /.login /.shosts /etc/inittab /etc/resolv.conf /etc/inetd.conf /etc/syslog.conf /etc/shells /etc/motd /etc/tcpd /etc/hosts.allow /etc/hosts.deny /etc/hosts.equiv /var/adm/sendmail/aliases* /etc/sendmail.cf /etc/ssh_known_hosts /etc/sysconfig /etc/Distfile ) ${ETCFILES} -> ${NODES} install; special /etc/syslog.conf "kill -HUP `cat /var/run/syslog.pid`"; special /etc/xinetd.conf "kill -HUP `cat /var/run/inetd.pid`"; # Files in /usr/local USRFILES = ( /usr/local/* ) ${USRFILES} -> ${NODES} install -oremove; except /usr/local/var/locatedb;

9. Internetwork demon Configuration Internet facilities controlled by the internet daemon /usr/sbin/xinetd started up from /etc/inittab xinetd controlled by configuration file /etc/xinetd.conf Tells where application to start is located Set mandatory user/group to run application Former name was inetd.conf and inetd demon Declares service name Services configuration files /etc/xinetd.d/ : Additional files to enable/disable services service names (telnet etc.) defined in /etc/services protocols (tcp etc.) defined in /etc/protocols networks defined in /etc/networks MAC level addresses defined in /etc/ethers (required by RARP) Services can work in two ways in Unix, as STAND ALONE and as INETD/XINETD controlled. STAND ALONE, the service is allways running a small monitor software itself, service has its own configuration files. INETD/XINETD services, are dependent of the internetwork demon with same name, they are configured as INETD/XINETD service and started/stopped by this service. They keep a configuration file in /etc/xinetd.d/service-name or in traditional /etc/inetd.conf First hand firewalling would be to checkout the files services and protocols, and comment out unused services. Second hand firewalling would be to look over all files in /etc/xinetd.d/ �disable=yes� o r�disable=no�.Additional files to enable/disable services service names (telnet etc.) defined in /etc/services protocols (tcp etc.) defined in /etc/protocols networks defined in /etc/networks MAC level addresses defined in /etc/ethers (required by RARP) Services can work in two ways in Unix, as STAND ALONE and as INETD/XINETD controlled. STAND ALONE, the service is allways running a small monitor software itself, service has its own configuration files. INETD/XINETD services, are dependent of the internetwork demon with same name, they are configured as INETD/XINETD service and started/stopped by this service. They keep a configuration file in /etc/xinetd.d/service-name or in traditional /etc/inetd.conf First hand firewalling would be to checkout the files services and protocols, and comment out unused services. Second hand firewalling would be to look over all files in /etc/xinetd.d/ �disable=yes� o r�disable=no�.

10. Summary Unix systems use TCP/IP for networking Every host on the network must have a unique IP address The file /etc/hosts maps names into IP addresses for network utilities Systems using DNS don't keep local host files Unix supports standard TCP/IP programs such as ping, telnet and ftp Unix provides its own equivalents (rlogin, rcp/scp, rsh and rdist) which use .rhosts files Unix uses several TCP/IP configuration files in /etc (xinetd.conf, services, etc.)