ITEF Download and Installation

Site Configuration

User Accounts

Secure Logins

Holdings

Deployment

• Hook up the new PC; insert the v1.1.1 boot floppy.
• Power up the PC; press F2 to enter the BIOS setup
• In the |Advanced| menu, set Plug & Play OS to NO
• In the |Power| menu, set Auto Suspend Timeout to OFF
• Exit and Save changes to the BIOS setup
• As the PC boots off the v1.1.1 floppy, insert the v1.1.1 installation CD

The floppy/CD installation takes about ten minutes. When complete, and the final confirmation screen displays with the OK button, DO NOT press the OK button yet. First:

1. Press Alt-<right-arrow> to bring up a new console screen and the bash prompt
2. Type chip to run the changeIP script
3. Update the IP data for the FC network
   

   Host Name:	use the name of the site, e.g., notredame
   Domain:	fc.iacnet.com
   IP Address:	140.244.150.9[0-9] (pick one not already used)
   Net Mask:	255.255.248.0 (CIDR /21)
   Broadcast:	140.244.150.255
   Def Route:	140.244.150.204
   DNS servers:	140.244.15.150
   	140.244.2.34
   	140.244.1.69

   Exit the chip application

4. Press Alt-<left-arrow> to return to the installation screen; press OK

The system will now reboot with the current IP settings. The machine should be able communicate through the IAC network. Test this by telneting to itef-demo.iacenter.com (198.112.160.10) or other host (note: ping is not enabled past the default router on the FC 140.244 segment) .

(Note: It is not necessary to run chip at the first time around. If the installer does not run the chip application at this stage of the setup, the changeIP console login can be used at any time to run the same application script, and set the machine's IP configuration.)

The next two steps install the latest EF client (CPS) and mirror the current configuration of the customer’s black box.

1. Log on to Linux at the console using
   
           username: ITadmin
           password: makeTracs
   
2. FTP anon to the server at ftp.iacenter.com
   
           [ITadmin@hostname]$ ftp ftp.iacenter.com
           FTP>username: anonymous
           FTP>password: youremail@address
   
3. At the FTP prompt, set the file transfer mode to binary
   
           FTP> binary
   
4. Get the file itef_linux_260b.tar-z and save it as itef260b.tar.Z in the /home/itef directory
   
       FTP> get /pub/iac/distribution/itef_linux_260b.tar-z /home/itef/itef260b.tar.Z
   
5. Exit the FTP app
   
           FTP> quit
   
6. Set the current directory to /home/itef
   
        [ITadmin@hostname]$ cd /home/itef
   
7. Uncompress and unwind the tar file
   
           [ITadmin@hostname]$ uncompress itef260b.tar.Z
           [ITadmin@hostname]$ tar –xvf itef260b.tar
   
   Note: At this point, verify the version number listed in the /home/itef/installation_version file. Earlier cuts of the v2.60b build do not update this file correctly. If the version listed in the file is not 2.60b, edit the line in the file to read 2.60b.
   
8. Run the ITinstall script
   
           [ITadmin@hostname]$ ./ITinstall
   
9. When prompted for the Installation ID, use the site name and a number 2; e.g.,
   
           Enter installation id:
           columbus2
   
10. . When prompted for the Location ID, enter the Location ID (found in RLIS) for the site (if more than one is used, enter the main LID); e.g.,
    
            Enter location:
            cml_main
    
    (Note: this location ID is only recorded as part of the alias defined in the .profile for the ITadmin account, and will not affect customer access; see shells installation section below)

1. Recreate the user accounts and replicate startup shells for each; replicate other scripts used to launch the EF client
2. Configure any secure login daemons (e.g., rlogin), passwordless login accounts, and/or TCPWrappers
3. Download any holdings files used on the old system
4. Test and debug startup shells and scripts; stage any special terminfo files from the customer's current impementation*

Completion of these steps depends on reaching the customer's current system over the internet. If the customer's system is behind a firewall and unreachable, final deployment of the new system may require onsite installation. If the customer prefers to complete the installation on their own, these instructions can be used to as a guide.

1. On the new system, logon at the console
   
      username:        root
       password:        bbox.root
   
2. Change to the ITadmin home directory
   
       [root@hostname]$ cd /home/ITadmin
   
3. FTP to the system at the customer site, and login as ITadmin
   
       [root@hostname]$ ftp <host_IP_address>
       FTP>username:     ITadmin
       FTP>password:     makeTracs
   
4. Set the file transfer mode to ASCII (the default on Linux' FTP client is BINARY)
   
       FTP> ascii
   
5. Get the password and shadow file from the /etc directory
   
       FTP> get /etc/passwd passwd
       FTP> get /etc/shadow shadow
   
   It is very important that you specify the file destination (in this case, the current .../ITadmin directory), otherwise, Linux' FTP client will write the file to the same directory, i.e., /etc, on the new system, overwriting the current /etc/passwd file. If this happens, it will be necessary to reinstall the v1.1.1 package CD.
   
   Note: It will be necessary, in most cases, to change the file permissions on the remote system's /etc/shadow file before downloading. To do this:
   
       -   switch to a new console on the local machine (use function keys or Alt-arrow)
       -   log on as either root or ITadmin
       -   telnet to the remote system and log on as ITadmin
       -   su to the root account
       -   change the file permissions
   
               $ chmod 444 /etc/shadow
   
   Switch back to the previous console and proceed with the download. Once completed, return to the second console and set the remote system's /etc/shadow file permissions back to their original settings.
   
6. Change to the local shells directory, and get all shell files from the remote machine
   
       FTP> lcd /home/itef/shells
       FTP> mget *.shell
   
   The latter will produce prompts to confirm the transfer of each file; respond to each with 'y' for yes.
   
7. Exit FTP
   
       FTP> quit
   
8. In the shells directory, change the shell files' mode, owner and group attributes
   
       $  chmod 755 /home/itef/shells/*.shell
       $  chown ITadmin /home/itef/shells/*.shell
       $  chgrp admin /home/itef/shells/*.shell
   
9. Change to the ITadmin home directory
   
       $  cd /home/ITadmin
   
10. Scan the passwd file to determine which user accounts will need to be created
    
        $  more passwd
    
    The tail of the file output should look something like this (here we use Notre Dame's system as an example):
    
        ...
        batchdb:x:0:3::/:/sbin/sh
        changeIP:x:0:3::/usr/local/etc:/usr/local/etc/interface.perl
        ithold:x:103:101::/home/itef/release2/holdings:/usr/bin/true
        ITmaint:x:0:3::/home/ITmaint:/home/ITmaint/dobackup
        iteftest:x:104:101::/home/iteftest:/usr/bin/sh
        infotrac:x:105:100::/home/itef/release2:/home/itef/shells/infotrac.shell
    
    User accounts are usually listed after the 'iteftest' account. Here, there is only one. The procedures below can be repeated for multiple user accounts identified in the /etc/passwd file.
    
11. Create the user account(s) on the new system; the entry in the passwd file gives you the home directory and startup shell file name
    
        $  useradd -d /home/itef/release2 -s /home/itef/shells/infotrac.shell infotrac
    
12. Recreate the password; to do this, scan the shadow file for the account being created
    
        $  grep infotrac shadow
    
    The output record might resemble
    
           infotrac:2dvWubC1KMwqw:10304::::::
    
    Each field in the record is delimited by a ":" character. The contents of the second field in this record, 2dvWubC1KMwqw, is the encrypted password (this will be unique for each account). The Linux implementation on the new machines requires that this password be recorded in the /etc/passwd file. To do this, execute the following command
    
        $  echo "infotrac:2dvWubC1KMwqw" | chpasswd -e
    
    (where | is the pipe character). Repeat steps 1.j through 1.l for each user account in the passwd file.
    
    Notes: (1) If no password value is present in that field of the shadow file's record, it is necessary to remove the password field's placeholder in the new /etc/password file. (2) If a large number of user accounts are required, a perl script can be used to loop the useradd command through the passwd file; subsequently, the shadow file can be manipulated and fed (piped) to the chpasswd -e command. A complete script that performs both tasks can be viewed here.

Rlogin. If the current host contains a .rlogin file in the /home/itef/release2 directory, chances are good that an rlogin client is being used to reach teh black box. To deploy rlogin on the new black box, the following steps are required:

• copy the .rhosts file from the old host to the new one
• if more than one account account is used on the new host, create separate home directories on the new host, and distribute copies of the .rhosts file to each
• edit each .rhosts file as required and assign ownership to the account

Note a: some new Linux boxes shipped with the rlogin daemon disabled. To remedy this, edit the /etc/inetd.conf (or /etc/inet/inetd.conf) file and uncomment the 'login' service line.

Note b: be sure that all .rhosts files include the following, for test purposes

localhost    ITadmin
localhost    root

Note c: in the Linux implementation, rlogin cannot be used anonymously. That is, entries such as

opac.library.net    +

are not permitted. It will be necessary to obtain the list of remote host usernames and list them individually in the new .rhosts file.

Example 1. On the current host, there is one user account (e.g., 'itef') listed in the /etc/passwd file. Assume that the account has been recreated on the new system.

1. copy the /home/itef/release2/.rhosts file from the old machine to the new machine as /home/itef/release2/.rhosts
2. change the file ownership to the user account ('itef'); this user account's home directory should be /home/itef/release2
3. test the configuration from the ITadmin account (see note b: above) -- assume the local user account is 'itef'

$ rlogin -l itef localhost

Example 2. On the current host, there are multiple user accounts (e.g., foo, bar, lart) listed in the /etc/passwd file. Assume these accounts have been recreated on the new system.

1. create separate home directories for each user account; e.g., from root
   
   $ cd /home/itef; mkdir foo; mkdir bar; mkdir lart
   
2. move a copy of the current hosts /home/itef/release2/.rhosts file to each of the new home directories; .rhosts files must be owned by the user account, and file modes should be set to 644
   
   $ chown .rhosts foo
   $ chgrp .rhosts admin
   $ chmod 644 .rhosts
   
3. modify each account's home directory specification, e.g.:
   
   $ usermod -d /home/itef/foo foo
   
4. test the configuration from the ITadmin account (se note b: above) -- ssume the local user account is itef.

$ rlogin localhost -l foo

Passwordless logins. If used on the current system, password logins show up as account records in /etc/shadow that have no encrypted password. For example:

    cmlpres:Ad594jzEgqyfk:9330::::::
    health::9443::::::

The first of these two entries contains an encrypted password, the second does not -- note the empty second field. Passwordless logins should only be implemented when TCPWrappers have been configured to allow logins only from trusted hosts/networks.

The Linux/PAM enabled applications use hosts.allow and hosts.deny to implement TCP wrapper like functionality. No changes to the inetd.conf file are required; standard nomenclature is used to specify host/protocol in each file. This configuration should mirror that used (if any) on the current system.

1. Logon at the console as ITadmin
   
       username:    ITadmin
       password:    makeTracs
   
2. Change to the holdings directory
   
       $  cd /home/itef/release2/holdings
   
3. Connect with FTP to the current system and download any holdings files in the corresponding directory
   
      FTP> ftp <remotehost>
       username:    ITadmin
       password:    makeTracs
   
      FTP> cd /home/itef/release2/holdings
   
      FTP> ASCII
   
      FTP> mget *.dat
   
   If one or more holdings files exists, the last command above will produce prompts for confirmation before downloading; respond to each with 'Y' for yes.

Experience to date reveals that many sites are bringing up the new machines along side the old ones; that is, both systems must be running on the same network while tests are performed on the new box. This suggests a deployment strategy that includes the following steps:

• Use the changeIP console login to modify the IP address of the new box
• Bring the new box up on the network
• Test the new machine from OPAC gateways or telnet clients

In this way, additional configuration work may be performed, especially that requiring access to both systems.

Once testing and configuration are complete, the library may choose to

(a) permanently reconfigure the OPAC gateway or telnet client(s) to reach the new machine on its current (new) IP address, or

(b) restore the new machine's IP configuration to match that of the original system, and simply replace one with the other.

If the library chooses option (a) above, it is not unreasonable to leave the original machine running in case backup is required, or in case the new system must be brought down for further configuration or maintenance. A library may opt to leave the original system running for a spell while confidence in the new system is reaches levels approaching that with the original system.

Choosing option (b) assumes that all components of the new system have been tested; restoring the original system could lead to down time during active periods. Timing of the event may be critical; system administrators are implored to perform the swap when users are least likely to be affected (e.g., early mornings during the week).

Documentation: a copy of LinuxBBox.doc should be filled out and forwarded to the library's system administrator.

NOTE: New Linux terminfos should work with current customer terminal hardware, however if modifications were made to terminfos currently deployed on the customer's machine, these should be copied to the new system and available for testing once the new system is connected at the customer site.