|
||
|
|
|
Introduction
A custom installation of q-Status™ can be created which does not use shared disk systems or the automounter to collect data. In this case, SSH or SSH2 can be used in its place.
pkgadd Module
Use of the SSH transfer requires that portions of the q-Status™ program be installed on the servers individually. A special pkgadd modules is provide for just this purpose, already pre-configured except for the transfer infromation. It is called LQWq-Status.pkg and is located in the main q-Status/Goodies directory. This package contains the SSHxfr script. Simply transfer this package over to the server (s) and preform a pkgadd.
# ls LQWq-Status.pkg # pkgadd -d LQWq-Status.pkg The following packages are available: 1 LQWq-Status q-Status server client collection sub module (sparc,i386) release 5.00 Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]: all Processing package instance <LQWq-Status> from ...... q-Status server client collection sub module (sparc,i386) release 5.00 LogiQwest Using </var> as the package base directory. ## Processing package information. ## Processing system information. ## Verifying disk space requirements. ## Checking for conflicts with packages already installed. ## Checking for setuid/setgid programs. Installing q-Status server client collection sub module as <LQWq-Status> ## Installing part 1 of 1. /var/q-Status/bin/.DS_Store /var/q-Status/bin/CFGDIR /var/q-Status/bin/FTPxfr /var/q-Status/bin/NFSxfr /var/q-Status/bin/README /var/q-Status/bin/SSHget /var/q-Status/bin/SSHget_paraphase /var/q-Status/bin/SSHreceiveXREF /var/q-Status/bin/SSHxfr /var/q-Status/bin/Telnet.pm /var/q-Status/bin/current_configs /var/q-Status/bin/list.E10KStatus /var/q-Status/bin/list.bpClasses /var/q-Status/bin/list.bpMediaAvailable /var/q-Status/bin/list.bpStatus /var/q-Status/bin/list.disks /var/q-Status/bin/list.etcSystem /var/q-Status/bin/list.ifconfig /var/q-Status/bin/list.instantImage /var/q-Status/bin/list.mdstat /var/q-Status/bin/list.os /var/q-Status/bin/list.patchadd /var/q-Status/bin/list.patches /var/q-Status/bin/list.pkginfo /var/q-Status/bin/list.prtconf /var/q-Status/bin/list.prtdiag /var/q-Status/bin/list.prtdiagv /var/q-Status/bin/list.scluster /var/q-Status/bin/list.scmdstat /var/q-Status/bin/list.starcat /var/q-Status/bin/list.vcluster /var/q-Status/bin/list.vxprint /var/q-Status/bin/list.vxprintht /var/q-Status/bin/list.vxprintrht /var/q-Status/bin/listSunfire.pl /var/q-Status/bin/listT3.pl /var/q-Status/bin/list_configs /var/q-Status/bin/list_netbackup /var/q-Status/bin/sunfire_params /var/q-Status/bin/t3_params [ verifying class <none> ] Installation of <LQWq-Status> was successful. # |
This will install these sub modules in a directory called /var/q-Status. Data will be collected in /var/q-Status/data. You will need to configure the transfer script as discussed below. You will also need to create an qStatus user on both the <server> and <web server> where data will be collected and transferred. It assumes that SSH or SSH2 is installed on both systems.
Note: If the packages were previously installed, you must remove them with pkgrm prior to installing the new version of the package. Prior to deleting the package, remove all entries from the /var/q-Status/data directory.
Setting Up the SSH Script
To use the SSH transfer script, SSH software must be installed and configured on the client server and the q-Status™ Web server. ssh services are part of standard Solaris since Solaris 8. For more information about SSH, see http://www.ssh.com.
Directions of the transfer is configured in only one way in the secure transfer model. SSHxfr script located in the q-Status/bin directory uses a push process to transfer data from the client-server to the q-Status web server. This is initiated through a root crontab entry but using a transfer user that is not root (e.g. qstatus). In this model, the q-Status web server is not configured to login to the client-server, whereas the client server is configured to login to the q-Status™ web server to deliver data. When configured properly, transfer of data to the collecting q-Status™ web server from the client server will use secure copy (e.g. scp) without any prompt for a password.
Note: The script SSHget also located in the the q-Status/bin directory uses a pull process to collect data. In its case, the q-Status™ web server executes this script and collects data from the client-server. This script requires that the qstatus transfer user (e.g. qstatus) can secure shell into the client-server with no password prompt.
The SSHxfr must be edited on all servers and the following parameters assigned:
|
TARGETHOST |
name of q-Status™ web server. |
|
TARGETDIR |
Directory on q-Status™ web server were files are to be sent |
|
SSHUSER |
ssh user |
|
SCP |
complete path of the scp command. |
The easiest way to implement the SSH transfer is to set up the public and private keys as root since data is collected as root.
SSH Process
Estaqblishing an ssh process that does not require a password for a login or shell execution relies on creation of a public and private key on the transfer server. Creation of these keys is through using the ssh command "ssh-keygen". Depending on the type of encryption algorithm selected (e.g. dsa, rsa, etc.), the public key is copied to the receiving server that requires a login with no password. A set of public keys are then established on the receiving server in a file called "authorized_keys".
Setting Up the SSH 1
The following instructions need to be followed to be able to use ssh1 for data transfer:
- Run ssh-keygen on the source host where the user will be the initiator of the transfer. You can play with the options to make it hands off (-f and -P). To make it automated, use a null ('') passphrase. This will generate the identity and identity.pub files.
- On the target host (q-Status™ web server), as the user that will be the recipient of the transfer, append the identity.pub file from the source user to the ~/.ssh/authorized_keys file.
- Do the scp once manually. This will prompt you for a yes or no to define the known hosts, then after that it will be automatic. Ensuing runs should not prompt you for anything.
Setting Up the SSH 2
The following instructions need to be followed to be able to use ssh2 for data transfer. The example given is uses DSA (digital signature algorithm developed by the NSA). This method can also be used other public algorithms including RSA (Rivest-Shamir-Adleman) depending on the security requirements:
1. Login on as the transfer user to the client-server where the data will be created. Create private and public keys on the server where the data is being generated by the SSHxfr program. Do this by executing the ssh-keygen command on the server where the transfer will be initiated.
-bash-3.00$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/export/home/qstatus/.ssh/id_dsa): <just enter a return>Enter passphrase (empty for no passphrase): <just enter a return>Enter same passphrase again: <just enter a return>Your identification has been saved in /export/home/qstatus/.ssh/id_dsa. Your public key has been saved in /export/home/qstatus/.ssh/id_dsa.pub. The key fingerprint is: a5:60:e4:93:35:93:18:d4:f0:e2:ac:85:af:4f:72:0d qstatus@lqwtest -bash-3.00$ cd .ssh -bash-3.00$ ls authorized_keys id_dsa id_dsa.pub |
ssh-keygen will ask you for a passphrase for the new key, just select return. ssh-keygen creates a ".ssh" directory in your home directory of the q-Status™ user, and stores a new authentication key in two separate files. One is the private key and thus it must NOT be opened to anyone but you. In the above example id_dsa is the private key. The id_dsa.pub is a public key that is safe to be opened and to be distributed to other computers.
| 2. | Create an identification file in the ".ssh" directory on the same server that references the private key. |
bash-3.00$ echo "IdKey id_dsa" > identification bash-3.00$ ls id_dsa id_dsa.pub identification bash-3.00$ |
This identification file in your ".ssh" directory has one line that denotes which file contains your identification. You can create multiple identifications by executing ssh-keygen again, but do so infrequently.
| 3. | Repeat step 1 and optionally 2 from SSH setup on the q-Status™ web server if it does not already exist already. |
q-Status Web Server (hostname:utility)
4. Make a copy of the public key generated on the client-server host. Copy this public key to the ".ssh" directory of <q-Status web server> using another name.
-bash-3.00$ cp id_dsa.pub lqwtest_dsa.pub -bash-3.00$ scp lqwtest_dsa.pub utility:/export/home/qstatus/.ssh The authenticity of host 'utility (192.168.3.37)' can't be established. RSA key fingerprint is 10:ee:83:ca:89:be:cb:cb:66:7c:59:df:27:1d:2b:68. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'utility,192.168.3.37' (RSA) to the list of known hosts. Password: xxxxxx id_dsa.pub 100% |*****************************************| 605 00:00 |
Note: If you are adding multiple servers with ssh, it is adviced that you name each key directory with the server host name (e.g. myhost_key.pub). You will then have a collection of public key files installed on the web server ssh directory for the q-Status transfer user.
bash-3.00$ ls id_dsa id_dsa.pub lqwtest_dsa.pub |
5. On the q-Status web server, copy the contents of the public key from the client-server into the file "authorized_keys".
q-Status Web Server (hostname:utility)
Note: The "authorized_keys" file will contain all the keys for each server-client that can transfer data without requiring a password. Therefore server-client server public key will be concatenated to the "authorized_keys" file.
To test the connect, login to <q-Status web server> from transfer server using ssh command.
$ ssh <q-Status web server> |
If you are not prompted for a password, everything is configured correctly.
Setting Up the SSHxfr Script
To use this script, after assigning the parameters, comment the line out in the list_configs script in the bin/ directory.
#!/bin/sh
# Copyright LogiQwest 2004
# Name: CFGDIR/bin/list_configs
# Version 1.00:21 Dec 2004 Created by Michael Barto
# Purpose: Master programs to call all listing scripts to generate
# an q-Status database.
DIR=`/usr/bin/dirname $0`
CFGDIR=`/bin/cat $DIR/CFGDIR`
${CFGDIR}/bin/list.os
${CFGDIR}/bin/list.patches
: : : :
: : : :
: : : :
# These item are collected for cluster
${CFGDIR}/bin/list.scluster
${CFGDIR}/bin/list.vcluster
# The following scripts are used for either FTP or SSH file transfer
# to the q-Status data directory from a system. Note these scripts
# must be edited prior to using. Comment out the appropriate
# script to use. See "FTPsetup.html" or "SSHsetup.html"
# for more information.
# ${CFGDIR}/bin/FTPxfr >/dev/null
${CFGDIR}/bin/SSHxfr >/dev/null
|
Data will then automatically be transferred each time the daemon is run to collect data.
Note: The CFGDIR parameters have already been assigned in the pkgadd program for /var/q-Status/ directory.
You can also run the SSHxfr program as another user besides root. This is set by the variable SSHUSER in the SSHxfr script. Be advised that this script must be executed by a separate user from crontab. If you make the transfer as root, execution of the SSHxfr program can be from commenting out the entry in the list_configs from one crontab.
Data collected by root on the servers in the list_configs program must be run as root to work properly. You cannot change users for the transfer like the SSHxfr program. You can create a special transfer user for ssh like the ftp transfer, say qStatus. If you do this you must have two crontab entries in for the server performing the transfer. The first entry for collection of the data (as root):
0 4,6,8,10,12,14,16,18 * * 1-5 /net/<web server>/var/apache/htdocs/q-Status/bin/list_configs >/dev/null 2>&1 |
The second entry is for the "qstatus" transfer user which is executed an hour latter:
1 5,6,9,11,13,15,17,19 * * 1-5 /var/q-Status/bin/SSHxfer >/dev/null 2>&1 |
This "qstatus" user must be added on the web server and to the servers where date is collected with the pkgadd program. On the web server the transfer home directory should be named the same as the data/ directory for q-Status™. For the server where the data is collected, this should be /var/q-Status/data. Each one of these directories will contain a .ssh directory where the public and private keys are located.
The scp command used in the SSHxfr can be used with a -p option. This will preserve the creation date of the data files when transferred to the server an hour latter.
/bin/su ${SSHUSER} -c '${SCP} -pq ${file} ${TARGETHOST}:${TARGETDIR}
|
Note: When you run the list_configs files created in the /var/q-Status/data directory, they may only be read by root (e.g. -rw-r----). To transfer using the "q-Status" user with ssh, all the files created in the data/ directory must be read by other (e.g. -rw-r--rw-). Use chmod a+rw * on these newly created file names once. After which these files will be overwritten each time the crontab is run retaining the updated protection.