This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Table of Contents
Background
xCAT framework supports to use the SSL to secure the communication messages among Login node, Management Node and Service Node, it also supports to use the SSH as the secure remote shell to execute command on remote node. All the security related keys and certificates are created during the installation of xCAT packages on Management node, and the security configuration for the nodes (both service node and compute node) are done during the installation process of the nodes .
After the installation of nodes, sometimes, the security configuration would be lost or messed up for some reason, but xCAT has not an effective approach to reconfigure the security configuration for the whole cluster. Therefore, this security update function is developed to handle these scenarios.
Interface (added for updatenode command)
--security
Setup the SSH or RSH for the target nodes; Copy the host keys from management node to the target nodes; Update the SSL RSA private key, certificate and Certificate Authorities files from management node to service node. If working with --user or --devicetype flag, the --security flag only setup the SSH key for target nodes;
--user user_ID
Specify the user id which setup the SSH keys for. This flag only can be used with --security and --devicetype flags.
--devicetype type_of_device
Specify a user-defined device type that references the location of relevant device configuration file. This flag only can be used with --security and --user flag.
So only following two cases will be supported, and them cannot be used together with other options of updatenode command:
updatenode <noderange> --security
updatenode <noderange> --security --user --devicetype
Implementation
--security
1. Setup the SSH or RSH for the target nodes;
If attribute 'useSSHonAIX' = no or 0 is set in site table, only the RSH would be set for the AIX target nodes, otherwise, the SSH would be set on the AIX nodes. For Linux nodes, always setup SSH.
RSH setup: Add the master IP and root into the /.rhosts on target nodes. For example 4.445.5.1 root
SSH setup: Since the SSH key setup has already been implemented in ‘xdsh –K’ command, the updatenode will call the 'xdsh -K' through the runxcmd function to complete SSH setup. If the --user flag is also specified with --security, the value of --user will be transported to 'xdsh -K --user' command to complete the function that setup SSH key for non-root user. If the --devicetype is specified with -security flag, the value of --devicetype will be transported to 'xdsh -K --devicetype' command to complete the function that setup SSH key with specific configuration file.
If specifying the --user or --devicetype flag with --security, the function of --security will be stopped here and return a succeeded message.
If need to update the host keys for a node with service node then the hostkeys must be updated on the service node first.
2. Copy the host keys from management node to the target nodes;
Copy the keys /etc/xcat/hostkeys/ssh_host_dsa_key, /etc/xcat/hostkeys/ssh_host_rsa_key and ~/.ssh/id_rsa from management node to target nodes. Since the copy action has been implemented in the remoteshell (for linux) and aixremoteshell (for AIX) postscript, updatenode command could call the run postscript function 'updatenode -P remoteshell(aixremoteshell)' to rerun this remoteshell postscript on target nodes. Note: as of xCAT 2.8, we no longer put aixremoteshell in the postscripts table. remoteshell is used for both AIX and Linux nodes. aixremoteshell is called by remoteshell on AIX nodes.
These keys should be copied from service node if there is, so updatenode needs to figure out and update the service node firstly, then update the compute nodes. If the update of service node failed, then stop the update of compute nodes.
3. Update the SSL RSA private key, certificate and CA files to the service node.
Since these SSL keys only needed by service node, this part of code will only run for service target nodes.
Copy the keys /etc/xcat/cert/server-cred.pem, /root/.xcat/client-cred.pem, /etc/xcat/cert/ca.pem, ~/.xcat/ca.pem from management node to the service node. Since the copy action has already been implemented in the postscripts servicenode, xcatserver and xcatclient, updatenode command could call the run postscript function 'updatenode -P servicenode,xcatserver,xcatclient' to rerun these postscripts on the target nodes. The xcatserver and xcatclient are only needed to run for Linux node.
Only part of the servicenode postscript code is used to update the SSL keys, so an option is needed to be added to make the servicenode postscript only do the SSL key update things.
4. misc things
4.1. Setup the /etc/ssh/sshd_config and /etc/ssh/ssh_configon configuration files on the target nodes;
This will be done in remoteshell or aixremoteshell postscript.
4.2. Update the ~/.ssh/known_hosts on management node and service node;
Remove the target node entries from the ~/.ssh/known_hosts before setting up the SSH key.
4.3. Transfer /etc/xcat/cfgloc to the service nodes
This will be done in servicenode postscript.
4.4. Restart the xcatd and sshd on the target node;
The sshd will be restarted in the remoteshell postscript and the xcatd will be restarted in the servicenode postscript.
4.5. Test the keys and certificates after the redelivering.
SSH setup has already been tested in the 'xdsh -K'.
--user user_ID
--devicetype type_of_device
The value will be transferred to 'xdsh' command directly.
Implementation details:
1. If a target node is served by a service node, the service node will be updated before updating the target node. All the operations which will be done against the target nodes will be done on the service node firstly. That means if just trying to set up the ssh key, then set up ssh keys on service node; if trying to set up ssh keys and delivering the certificates, then do both of them on service node firstly.
2. Since --security option needs to get the enter of user for password which is used for ssh key setup, a updatenode command needs to be added to replace the link of /opt/xcat/bin/xcatclient.
News
- Apr 22, 2016: xCAT 2.11.1 released.
- Mar 11, 2016: xCAT 2.9.3 (AIX only) released.
- Dec 11, 2015: xCAT 2.11 released.
- Nov 11, 2015: xCAT 2.9.2 (AIX only) released.
- Jul 30, 2015: xCAT 2.10 released.
- Jul 30, 2015: xCAT migrates from sourceforge to github
- Jun 26, 2015: xCAT 2.7.9 released.
- Mar 20, 2015: xCAT 2.9.1 released.
- Dec 12, 2014: xCAT 2.9 released.
- Sep 5, 2014: xCAT 2.8.5 released.
- May 23, 2014: xCAT 2.8.4 released.
- Jan 24, 2014: xCAT 2.7.8 released.
- Nov 15, 2013: xCAT 2.8.3 released.
- Jun 26, 2013: xCAT 2.8.2 released.
- May 17, 2013: xCAT 2.7.7 released.
- May 10, 2013: xCAT 2.8.1 released.
- Feb 28, 2013: xCAT 2.8 released.
- Nov 30, 2012: xCAT 2.7.6 released.
- Oct 29, 2012: xCAT 2.7.5 released.
- Aug 27, 2012: xCAT 2.7.4 released.
- Jun 22, 2012: xCAT 2.7.3 released.
- May 25, 2012: xCAT 2.7.2 released.
- Apr 20, 2012: xCAT 2.7.1 released.
- Mar 19, 2012: xCAT 2.7 released.
- Mar 15, 2012: xCAT 2.6.11 released.
- Jan 23, 2012: xCAT 2.6.10 released.
- Nov 15, 2011: xCAT 2.6.9 released.
- Sep 30, 2011: xCAT 2.6.8 released.
- Aug 26, 2011: xCAT 2.6.6 released.
- May 20, 2011: xCAT 2.6 released.
- Feb 14, 2011: Watson plays on Jeopardy and is managed by xCAT!
- xCAT Release Notes Summary
- xCAT OS And Hw Support Matrix
- xCAT Test Environment Summary
History
- Oct 22, 2010: xCAT 2.5 released.
- Apr 30, 2010: xCAT 2.4 is released.
- Oct 31, 2009: xCAT 2.3 released.
xCAT's 10 year anniversary! - Apr 16, 2009: xCAT 2.2 released.
- Oct 31, 2008: xCAT 2.1 released.
- Sep 12, 2008: Support for xCAT 2
can now be purchased! - June 9, 2008: xCAT breaths life into
(at the time) the fastest
supercomputer on the planet - May 30, 2008: xCAT 2.0 for Linux
officially released! - Oct 31, 2007: IBM open sources
xCAT 2.0 to allow collaboration
among all of the xCAT users. - Oct 31, 1999: xCAT 1.0 is born!
xCAT started out as a project in
IBM developed by Egan Ford. It
was quickly adopted by customers
and IBM manufacturing sites to
rapidly deploy clusters.