Ignite-UX Reference (March 2010, B3921-90005)

bootsys(1M) bootsys(1M)
Blocking bootsys Attempts
For computing environments in which the server has .rhosts permission to all systems, it is sometimes
desirable to block the bootsys command from being able to execute on critical systems. This helps to
prevent users from accidentally targeting the wrong system or a system that is actively in use and not yet
ready to be installed.
bootsys may be blocked by creating the file /.bootsys_block on the clients that you do not want
to be reinstalled. This file may either be empty, contain the word confirm, and/or it may contain a mes-
sage that explains why the client is blocking bootsys. If the file is empty, bootsys refuses to execute
on the target. If the first line of the file contains the word confirm, the user running bootsys on the
Ignite-UX server is asked if client installation should continue. If the file contains any other text, that text
is displayed to the console when the bootsys command was executed. Typically this text is used to
explain why the client is blocking any bootsys attempts.
International Code Set Support
Ignite-UX uses a variety of system commands to accomplish its functionality. Because the output of many
of these commands is parsed, Ignite-UX ensures that the POSIX locale is normally used by modifying envi-
ronment variables. Help text and some command output not parsed by Ignite-UX will be left in the user’s
specified locale.
Using SSH with bootsys
The bootsys command remotely executes a series of commands on the client system from the Ignite-UX
server, some of which are protected from waiting for an indefinite period of time. For these reasons,
bootsys must use an access method that does not require the user to repeatedly enter the client system’s
root password. In remsh mode, this is accomplished using the .rhosts file. In SSH mode, boot-
sys must use public/private key authentication in conjunction with an ssh-agent process. This allows
bootsys to automatically perform its tasks without intervention.
When bootsys is invoked with the -S flag, it verifies that the user has created a public RSA or DSA
key, and checks the SSH_AGENT_PID environment variable to determine whether an ssh-agent pro-
cess has been started. If this check shows no ssh-agent process has been started, bootsys starts the
ssh-agent and uses ssh-add to register the user’s private key with the agent. If the private key is
protected with a passphrase, the user is prompted for the passphrase.
The bootsys command then attempts to execute commands on the client via ssh. If the user’s public
key has not been placed in the ˜/.ssh/authorized_keys file on the client, bootsys prompts the
user asking whether to copy the public key files ˜/.ssh/id_rsa.pub and ˜/.ssh/id_dsa.pub
files to the client’s ˜/.ssh/authorized_keys file using ssh.Ifbootsys starts an ssh-agent
process, that process will be killed before bootsys exits.
Important: The bootsys command does not attempt to determine if you have modified the value for Autho-
rizedKeysFile in the sshd configuration file /etc/opt/ssh/sshd_config on the client system. If
you modify this value Ignite-UX ssh support will not work. Also, the bootsys command does not
attempt to locate non-default locations for the user’s public/private key files.
Tw o public/private key pairs are involved when communicating with a remote system: a host key and a user
key. The host key identifies the computer systems involved in the communication, and the user key identi-
fies the specific user. The first time ssh is used to communicate with a remote system, unless your system
administrator has already registered the remote system in the file /etc/ssh/ssh_known_hosts, the
user is prompted with a message similar to:
The authenticity of host ’test4 (10.1.48.124)’ can’t
be established. RSA key fingerprint is
3d:6b:c6:ce:b0:58:60:2a:53:c1:19:b5:ec:84:77:b1.
Are you sure you want to continue connecting (yes/no)?
This prompt is asking the user to accept the key identifying the remote host. Answer "yes" to this question
if you are certain that you are connected to the intended client system. For more information about host
keys, see the VERIFYING HOST KEYS section of ssh(1).
4