xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2025-08-14 23:30:21 +00:00
Code Issues Releases Wiki Activity

Merge branch 'master' into ZVM_XCAT_DEV

Browse Source
This commit is contained in:
zVMopenstack
2017-04-24 09:39:38 -04:00
committed by GitHub
parent 7274ad6baa f503fb991f
commit 7487c0322a
292 changed files with 9635 additions and 3020 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@@ -2,3 +2,6 @@
docs/build
# Ignore the temporary file for creating the Release version
Release.save*
# ignore the old generated man pages and html pages
xCAT-client/share/man
xCAT-client/share/doc

12
README.rst
View File

@@ -8,7 +8,7 @@ Documentation
xCAT documentation is available at: http://xcat-docs.readthedocs.io/en/latest/
|docs_latest| |docs_2131| |docs_2130| |docs_212| |docs_211|
|docs_latest| |docs_2133| |docs_2132| |docs_2131| |docs_2130| |docs_212| |docs_211|
Open Source License
-------------------
@@ -22,6 +22,16 @@ Developers
Developers and prospective contributors are encouraged to read the `Developers Guide <http://xcat-docs.readthedocs.io/en/latest/developers/>`_
In particular the `GitHub <http://xcat-docs.readthedocs.io/en/latest/developers/github/>`_ related subsection.
.. |docs_2133| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.3
:alt: 2.13.3 documentation status
:scale: 100%
:target: http://xcat-docs.readthedocs.io/en/2.13.3/
.. |docs_2132| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.2
:alt: 2.13.2 documentation status
:scale: 100%
:target: http://xcat-docs.readthedocs.io/en/2.13.2/
.. |docs_2131| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.1
:alt: 2.13.1 documentation status
:scale: 100%

2
Version
View File

@@ -1 +1 @@
2.13.2.1
2.13.4

106
build-ubunturepo
View File

@@ -6,10 +6,10 @@
#
#
# Getting Started:
# - Clone the xcat-core git repository int a directory called <rel>/src/xcat-core, where <rel>
# is the same name as the release dir it is uploaded to xcat.org (e.g devel, 2.9, 2.10)
# - Clone the xcat-core git repository under a directory named "xcat-core/src"
# - make sure reprepro is installed on the build machine
# - Run this script from the local git repository you just created. It will create the other directories that are needed.
# - Run this script from the local git repository you just created.
# ./build-ubunturepo -c BUILDALL=1
# Usage: attr=value attr=value ... ./build-ubunturepo { -c | -d }
# PROMOTE=1 - if the attribute "PROMOTE" is specified, means an official dot release. This does not
@@ -22,7 +22,6 @@
# When you are ready to release this build, use PROMOTE=1 without PREGA
# BUILDALL=1 - build all rpms, whether they changed or not. Should be used for snap builds that are in
# prep for a release.
# UP=0 or UP=1 - override the default upload behavior
# LOG=<filename> - provide an LOG file option to redirect some output into log file
#
# For the dependency packages 1. All the xcat dependency deb packages should be uploaded to
@@ -96,13 +95,6 @@ if [ -z "$c_flag" -a -z "$d_flag" ];then
exit 2
fi
USER="xcat"
SERVER="xcat.org"
FILES_PATH="files"
FRS="/var/www/${SERVER}/${FILES_PATH}"
APT_DIR="${FRS}/xcat"
APT_REPO_DIR="${APT_DIR}/repos/apt"
if [ "$c_flag" -a "$d_flag" ];then
printusage
exit 2
@@ -118,7 +110,7 @@ curdir=`pwd`
local_core_repo_path="$curdir/../../xcat-core"
local_dep_repo_path="$curdir/../../xcat-dep/xcat-dep"
#use flock to only one person build at the same time
# Use flock to only one person build at the same time
# Get a lock, so can not do 2 builds at once
exec 8>/var/lock/xcatbld.lock
if ! flock -n 8; then
@@ -146,51 +138,46 @@ done
if [ "$c_flag" ]
then
# strip the /src/xcat-core from the end of the dir to get the next dir up and use as the release
#
# The format of the directory for Ubuntu builds needs to be "xcat-core/src/xcat-core" so
# that the output build files are created under "xcat-core".
# TODO: This should be fixed in the future....
#
if [ -z "$REL" ]; then
t=${curdir%/src/xcat-core}
REL=`basename $t`
fi
if [ "$REL" != "xcat-core" ]; then
echo "ERROR: REL='$REL'needs to be 'xcat-core'. Ensure the path is 'xcat-core/src/xcat-core'"
exit 1
fi
ver=`cat Version`
if [ "$PROMOTE" != 1 ]; then
code_change=0
update_log=''
#get the version
if [ "$REL" = "xcat-core" ];then
git_flag=1
REL=`git rev-parse --abbrev-ref HEAD`
if [ "$REL" = "master" ]; then
REL="devel"
fi
if [ -z "$GITUP" ];then
update_log=../coregitup
echo "git pull > $update_log"
git pull > $update_log
else
update_log=$GITUP
fi
if ! grep -q 'Already up-to-date' $update_log; then
code_change=1
fi
# get the version
git_flag=1
REL=`git rev-parse --abbrev-ref HEAD`
if [ "$REL" = "master" ]; then
REL="devel"
fi
if [ -z "$GITUP" ];then
update_log=../coregitup
echo "git pull > $update_log"
git pull > $update_log
else
git_flag=0
if [ -z "$SVNUP" ]; then
update_log=../coresvnup
echo "svn up > $update_log"
svn up > $update_log
else
update_log=$SVNUP
fi
update_log=$GITUP
fi
if ! grep -q 'At revision' $update_log;then
code_change=1
fi
if ! grep -q 'Already up-to-date' $update_log; then
code_change=1
fi
ver=`cat Version`
short_ver=`cat Version|cut -d. -f 1,2`
short_short_ver=`cat Version|cut -d. -f 1`
build_time=`date`
build_machine=`hostname`
commit_id=`git rev-parse --short HEAD`
package_dir_name=debs$REL
#TODO: define the core path and tarball name
@@ -206,11 +193,10 @@ then
echo "###############################"
#the package type: local | snap | alpha
#the build introduce stirng
pkg_type="snap"
#the build introduce string
build_string="Snap_Build"
cur_date=`date +%Y%m%d%H%M`
pkg_version="${ver}-${pkg_type}${cur_date}"
xcat_release="snap$(date '+%Y%m%d%H%M')"
pkg_version="${ver}-${xcat_release}"
if [ ! -d ../../$package_dir_name ];then
mkdir -p "../../$package_dir_name"
@@ -229,8 +215,6 @@ then
do
if grep -q $file $update_log || [ "$BUILDALL" == 1 -o "$file" = "perl-xCAT" ]; then
rm -f ../../$package_dir_name/${file_low}_*.$target_arch.deb
#genesis scripts package, don't remove genesis amd64 files
#rm -f ../../$package_dir_name/${file_low}-amd64_*.deb
cd $file
CURDIR=$(pwd)
dch -v $pkg_version -b -c debian/changelog $build_string
@@ -377,6 +361,16 @@ __EOF__
chmod 775 mklocalrepo.sh
#
# Add a buildinfo file under xcat-core to track information about the build
#
buildinfo=$local_core_repo_path/buildinfo
echo "VERSION=$ver" > $buildinfo
echo "RELEASE=$xcat_release" >> $buildinfo
echo "BUILD_TIME=$build_time" >> $buildinfo
echo "BUILD_MACHINE=$build_machine" >> $buildinfo
echo "COMMIT_ID=$commit_id" >> $buildinfo
#create the xcat-core.list file
cd ../
@@ -501,7 +495,15 @@ __EOF__
chgrp root $dep_tar_name
chmod g+w $dep_tar_name
# Decide whether to upload or not (default NOT to upload)
USER="xcat"
SERVER="xcat.org"
FILES_PATH="files"
FRS="/var/www/${SERVER}/${FILES_PATH}"
APT_DIR="${FRS}/xcat"
APT_REPO_DIR="${APT_DIR}/repos/apt"
# Decide whether to upload the xcat-dep package or NOT (default is to NOT upload xcat-dep
if [ "$UP" != "1" ]; then
echo "Upload not specified, Done! (rerun with UP=1, to upload)"
cd $old_pwd
@@ -527,7 +529,7 @@ __EOF__
while [ $((i+=1)) -le 5 ] && ! rsync -v --force README $USER@${SERVER}:${APT_DIR}/xcat-dep/2.x_Ubuntu/
do : ; done
cd $old_pwd
exit 0
fi
cd $old_pwd
exit 0

1
docs/source/advanced/cluster_maintenance/compute_node/index.rst
View File

@@ -5,3 +5,4 @@ Compute Node
:maxdepth: 2
changing_hostname_ip.rst
replace/index.rst

7
docs/source/advanced/cluster_maintenance/compute_node/replace/index.rst Normal file
View File

@@ -0,0 +1,7 @@
Replacing Nodes
===============
.. toctree::
:maxdepth: 2
openpower.rst

38
docs/source/advanced/cluster_maintenance/compute_node/replace/openpower.rst Normal file
View File

@@ -0,0 +1,38 @@
OpenPower Nodes
===============
When compute nodes are physically replaced in the frame, leverage xCAT to re-discover the compute nodes. The following guide can be used for:
* IBM OpenPower S822LC for HPC
#. Identify the machine(s) to be replaced: ``frame10cn02``.
#. [**Optional**] It's recommended to set the BMC IP address back to DHCP, if it was set to STATIC. ::
rspconfig frame10cn02 ip=dhcp
#. Set the outgoing machine to ``offline`` and remove attributes of the machine: ::
nodeset frame10cn02 offline
chdef frame10cn02 mac=""
#. If using **MTMS**-based discovery, fill in the Model-Type and Serial Number for the machine: ::
chdef frame10cn02 mtm=8335-GTB serial=<NEW SERIAL NUMBER>
#. If using **SWITCH**-based discovery, go on to the next step. The ``switch`` and ``switch-port`` should already be set in the compute node definition.
Node attributes will be replaced during the discovery process (mtm, serial, mac, etc.)
#. Search for the new BMC in the open range: ::
bmcdiscover --range <IP open range> -w -z
#. When the BMC is found, start the discovery with the following commands: ::
rsetboot /node-8335.* net
rpower /node-8335.* boot

64
docs/source/advanced/cluster_maintenance/mgmt_node/changing_hostname_ip.rst
View File

@@ -52,7 +52,7 @@ Change the Management Hostname
hostname <new_MN_name>
* Edit hostname configuration file
* Update the hostname configuration files:
| Add hostname in ``/etc/hostname``
| Add HOSTNAME attribute in ``/etc/sysconfig/network`` (only for [RHEL])
@@ -60,29 +60,29 @@ Change the Management Hostname
Update Database Files
---------------------
You need to update the new MN hostname or IP address in several database
configuration files.
You need to update the new MN hostname or IP address in several database configuration files.
SQLite
^^^^^^
Nothing to do.
Postgresql
PostgreSQL
^^^^^^^^^^
- Edit ``/etc/xcat/cfgloc`` file, replace ``Pg:dbname=xcatdb;host=<old_MN_ip>|xcatadm|xcat20``
with ``Pg:dbname=xcatdb;host=<new_MN_ip>|xcatadm|xcat20``.
- Edit ``/etc/xcat/cfgloc`` file...
- Edit config database config file ``/var/lib/pgsql/data/pg_hba.conf``,
replace ``host all all <old_MN_ip>/32 md5``
with ``host all all <new_MN_ip>/32 md5``.
Replace ``Pg:dbname=xcatdb;host=<old_MN_ip>|xcatadm|xcat20`` with ``Pg:dbname=xcatdb;host=<new_MN_ip>|xcatadm|xcat20``.
Mysql
- Edit config database config file ``/var/lib/pgsql/data/pg_hba.conf``...
Replace ``host all all <old_MN_ip>/32 md5`` with ``host all all <new_MN_ip>/32 md5``
MySQL
^^^^^
Edit ``/etc/xcat/cfglooc``, replace ``mysql:dbname=xcatdb;host=<old_MN_ip>|xcatadmin|xcat20``
with ``mysql:dbname=xcatdb;host=<new_MN_ip>|xcatadmin|xcat20``.
- Edit ``/etc/xcat/cfglooc``...
Replace ``mysql:dbname=xcatdb;host=<old_MN_ip>|xcatadmin|xcat20`` with ``mysql:dbname=xcatdb;host=<new_MN_ip>|xcatadmin|xcat20``
Start the database
------------------
@@ -116,12 +116,12 @@ Change the site table master attribute
Change all IP address attribute relevant to the MN IP address
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For example, old address was "10.6.0.1"
For example, the old IP address was "10.6.0.1"
* Query the attributes with old address ::
* Query all the attributes with old address ::
lsdef -t node -l | grep "10.6.0.1"
# the output may looks like
...
conserver=10.6.0.1
conserver=10.6.0.1
conserver=10.6.0.1
@@ -138,26 +138,23 @@ For example, old address was "10.6.0.1"
servicenode=10.6.0.1
xcatmaster=10.6.0.1
* As the attribute with the old IP address is list above, take conserver as
a example, query the nodes with ``conserver=10.6.0.1``.
::
* Looking at the list above, taking ``conserver`` as an example, query the nodes with ``conserver=10.6.0.1``: ::
lsdef -t node -w conserver="10.6.0.1"
# the output looks like
...
cn1 (node)
cn2 (node)
cn3 (node)
cn4 (node)
* Change the conserver address for cn1,cn2,cn3,cn4 ::
* Change the conserver address for nodes ``cn1,cn2,cn3,cn4`` ::
chdef -t node cn1-cn4 conserver=<new_ip_address>
Repeat the same process for the other attributes.
* Repeat the same process for the other attributes containing the old IP address.
Change networks table
^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^
Check your networks table to see if the network definitions are still correct,
if not edit accordingly ::
@@ -166,7 +163,7 @@ if not edit accordingly ::
chdef -t network <key=value>
Check Result
^^^^^^^^^^^^^
^^^^^^^^^^^^
You can check whether all the old address has been changed using ::
@@ -174,25 +171,24 @@ You can check whether all the old address has been changed using ::
cd <new database backup path>
fgrep "10.6.0.1" *.csv
If the old address still exists in the ``*.csv` file, you can edit this file,
then use the following command to restore the records ::
If the old address still exists in the ``*.csv`` file, you can edit this file, then use the following command to restore the records ::
tabrestore <xxx.csv>
Generate SSL credentials(optional)
----------------------------------
If you do not generate new credentials, skip this section.
If you decide generate new credentials, then you will use the following
command.
Use the following command to generate new SSL credentials: ``xcatconfig -c``.
* Generate new credentials ::
Then update the following in xCAT:
xcatconfig -c
* Update the policy table with new management node name and replace: ::
* Update the policy table with new MN name,
replace ``"1.4","old_MN_name",,,,,,"trusted",,`` with
``"1.4","new_MN_name",,,,,,"trusted",,``
"1.4","old_MN_name",,,,,,"trusted",,
with: ::
"1.4","new_MN_name",,,,,,"trusted",,``
* Setup up conserver with new credentials ::

6
docs/source/advanced/cluster_maintenance/service_node/changing_hostname_ip.rst
View File

@@ -36,11 +36,7 @@ Database Connection Changes
Granting or revoking access privilege in the database for the service node.
* For mysql, refer to :ref:`grante_revoke_mysql_access_label`.
.. There is no procedure in old document on sourceforge for postgress to
grant or revoke the access privilege for service node.
* For postgress, refer to `TODO <https://localhost/todo>`_.
* For MySQL, refer to :ref:`grante_revoke_mysql_access_label`.
Update Provision Environment on Service Node
--------------------------------------------

13
docs/source/advanced/domain_name_resolution/domain_name_resolution.rst
View File

@@ -459,19 +459,6 @@ You can either specify the base nic* attribute name or the expanded name for a s
nicips.eth1=11.1.89.7
nichostnamesuffixes.eth1=-lab
"otherinterfaces" vs. nic* attributes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For now the "otherinterfaces" attribute will still be supported but it may be dropped in future releases.Any new network interface information should be provided using the new nic attributes.
If you are currently using the "otherinterfaces" node attribute you do not have to move it to the nic* attributes at this time. However, be careful to avoid any overlap or conflict with the information provided for each.
If you are using "otherinterfaces" and add additional interfaces using the nic* attributes the makehosts command will add both to the /etc/hosts table.
When both the "otherinterfaces" and nic attributes are used the "otherinterfaces" attribute is processed before the nic attributes.
To do more nic introduce (refer to :ref:`confignics_label` ).
Setting addition interface information using the xCAT tabedit command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

10
docs/source/advanced/hamn/setup_ha_mgmt_node_with_shared_data.rst
View File

@@ -56,7 +56,7 @@ The configuration procedure will be quite different based on the shared data mec
/<dbdirectory>
``Note``:For mysql, the database directory is ``/var/lib/mysql``; for postgresql, the database directory is ``/var/lib/pgsql``; for DB2, the database directory is specified with the site attribute databaseloc; for sqlite, the database directory is /etc/xcat, already listed above.
``Note``:For MySQL, the database directory is ``/var/lib/mysql``; for PostGreSQL, the database directory is ``/var/lib/pgsql``; for DB2, the database directory is specified with the site attribute databaseloc; for sqlite, the database directory is /etc/xcat, already listed above.
Here is an example of how to make directories be shared data through NFS: ::
@@ -125,7 +125,7 @@ Setup xCAT on the Primary Management Node
service dhcpd stop
chkconfig --level 2345 dhcpd off
#. Stop Database and prevent the database from auto starting at boot time, use mysql as an example: ::
#. Stop Database and prevent the database from auto starting at boot time, use MySQL as an example: ::
service mysqld stop
chkconfig mysqld off
@@ -180,7 +180,7 @@ Setup xCAT on the Standby Management Node
service dhcpd stop
chkconfig --level 2345 dhcpd off
#. Stop Database and prevent the database from auto starting at boot time. Use mysql as an example: ::
#. Stop Database and prevent the database from auto starting at boot time. Use MySQL as an example: ::
service mysqld stop
chkconfig mysqld off
@@ -303,7 +303,7 @@ If the management node is still available and running the cluster, perform the f
#. Stop database
Use mysql as an example: ::
Use MySQL as an example: ::
service mysqld stop
@@ -346,7 +346,7 @@ On the new primary management node:
mount /.xcat
mount /db2database
#. Start database, use mysql as an example: ::
#. Start database, use MySQL as an example: ::
service mysql start

74
docs/source/advanced/hierarchy/appendix/appendix_b_diagnostics.rst
View File

@@ -1,66 +1,18 @@
Appendix B: Diagnostics
=======================
* **root ssh keys not setup** -- If you are prompted for a password when ssh to
the service node, then check to see if /root/.ssh has authorized_keys. If
the directory does not exist or no keys, on the MN, run xdsh service -K,
to exchange the ssh keys for root. You will be prompted for the root
password, which should be the password you set for the key=system in the
passwd table.
* **XCAT rpms not on SN** --On the SN, run rpm -qa | grep xCAT and make sure
the appropriate xCAT rpms are installed on the servicenode. See the list of
xCAT rpms in :ref:`setup_service_node_stateful_label`. If rpms
missing check your install setup as outlined in Build the Service Node
Stateless Image for diskless or :ref:`setup_service_node_stateful_label` for
diskful installs.
* **otherpkgs(including xCAT rpms) installation failed on the SN** --The OS
repository is not created on the SN. When the "yum" command is processing
the dependency, the rpm packages (including expect, nmap, and httpd, etc)
required by xCATsn can't be found. In this case, check whether the
``/install/postscripts/repos/<osver>/<arch>/`` directory exists on the MN.
If it is not on the MN, you need to re-run the "copycds" command, and there
will be some file created under the
``/install/postscripts/repos/<osver>/<arch>`` directory on the MN. Then, you
need to re-install the SN, and this issue should be gone.
* **Error finding the database/starting xcatd** -- If on the Service node when
you run tabdump site, you get "Connection failure: IO::Socket::SSL:
connect: Connection refused at ``/opt/xcat/lib/perl/xCAT/Client.pm``". Then
restart the xcatd daemon and see if it passes by running the command:
service xcatd restart. If it fails with the same error, then check to see
if ``/etc/xcat/cfgloc`` file exists. It should exist and be the same as
``/etc/xcat/cfgloc`` on the MN. If it is not there, copy it from the MN to
the SN. The run service xcatd restart. This indicates the servicenode
postscripts did not complete successfully. Check to see your postscripts
table was setup correctly in :ref:`add_service_node_postscripts_label` to the
postscripts table.
* **Error accessing database/starting xcatd credential failure**-- If you run
tabdump site on the servicenode and you get "Connection failure:
IO::Socket::SSL: SSL connect attempt failed because of handshake
problemserror:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
at ``/opt/xcat/lib/perl/xCAT/Client.pm``", check ``/etc/xcat/cert``. The
directory should contain the files ca.pem and server-cred.pem. These were
suppose to transfer from the MN ``/etc/xcat/cert`` directory during the
install. Also check the ``/etc/xcat/ca`` directory. This directory should
contain most files from the ``/etc/xcat/ca`` directory on the MN. You can
manually copy them from the MN to the SN, recursively. This indicates the
the servicenode postscripts did not complete successfully. Check to see
your postscripts table was setup correctly in
:ref:`add_service_node_postscripts_label` to the postscripts table. Again
service xcatd restart and try the tabdump site again.
* **Missing ssh hostkeys** -- Check to see if ``/etc/xcat/hostkeys`` on the SN,
has the same files as ``/etc/xcat/hostkeys`` on the MN. These are the ssh
keys that will be installed on the compute nodes, so root can ssh between
compute nodes without password prompting. If they are not there copy them
from the MN to the SN. Again, these should have been setup by the
servicenode postscripts.
* **root ssh keys not setup** -- If you are prompted for a password when ssh to the service node, then check to see if ``/root/.ssh`` directory on MN has ``authorized_keys`` file. If the directory does not exist or no keys, run ``xdsh service -K``, to exchange the ssh keys for root. You will be prompted for the root password, which should be the password you set for the ``key=system`` in the passwd table.
* **Errors running hierarchical commands such as xdsh** -- xCAT has a number of
commands that run hierarchically. That is, the commands are sent from xcatd
on the management node to the correct service node xcatd, which in turn
processes the command and sends the results back to xcatd on the management
node. If a hierarchical command such as xcatd fails with something like
"Error: Permission denied for request", check ``/var/log/messages`` on the
management node for errors. One error might be "Request matched no policy
rule". This may mean you will need to add policy table entries for your
xCAT management node and service node:
* **XCAT rpms not on SN** -- On the SN, run ``rpm -qa | grep xCAT`` and make sure the appropriate xCAT rpms are installed on the servicenode. See the list of xCAT rpms in :ref:`setup_service_node_stateful_label`. If rpms are missing, check your install setup as outlined in :ref:`setup_service_node_stateless_label` for diskless or :ref:`setup_service_node_stateful_label` for diskful installs.
* **otherpkgs(including xCAT rpms) installation failed on the SN** -- The OS repository is not created on the SN. When the "yum" command is processing the dependency, the rpm packages (including expect, nmap, and httpd, etc) required by xCATsn can't be found. In this case, check whether the ``/install/postscripts/repos/<osver>/<arch>/`` directory exists on the MN. If it is not on the MN, you need to re-run the ``copycds`` command, and there will be files created under the ``/install/postscripts/repos/<osver>/<arch>`` directory on the MN. Then, you need to re-install the SN.
* **Error finding the database/starting xcatd** -- If on the Service node when you run tabdump site, you get "Connection failure: IO::Socket::SSL: connect: Connection refused at ``/opt/xcat/lib/perl/xCAT/Client.pm``". Then restart the xcatd daemon and see if it passes by running the command ``service xcatd restart``. If it fails with the same error, then check to see if ``/etc/xcat/cfgloc`` file exists. It should exist and be the same as ``/etc/xcat/cfgloc`` on the MN. If it is not there, copy it from the MN to the SN. The run ``service xcatd restart``. This indicates the servicenode postscripts did not complete successfully. Run ``lsdef <service node> -i postscripts -c`` and verify ``servicenode`` postscript appears on the list..
* **Error accessing database/starting xcatd credential failure**-- If you run ``tabdump site`` on the service node and get "Connection failure: IO::Socket::SSL: SSL connect attempt failed because of handshake problemserror:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown at ``/opt/xcat/lib/perl/xCAT/Client.pm``", check ``/etc/xcat/cert``. The directory should contain the files ``ca.pem`` and ``server-cred.pem``. These were suppose to transfer from the MN ``/etc/xcat/cert`` directory during the install. Also check the ``/etc/xcat/ca`` directory. This directory should contain most files from the ``/etc/xcat/ca`` directory on the MN. You can manually copy them from the MN to the SN, recursively. This indicates the the servicenode postscripts did not complete successfully. Run ``lsdef <service node> -i postscripts -c`` and verify ``servicenode`` postscript appears on the list. Run ``service xcatd restart`` again and try the tabdump site again.
* **Missing ssh hostkeys** -- Check to see if ``/etc/xcat/hostkeys`` on the SN, has the same files as ``/etc/xcat/hostkeys`` on the MN. These are the ssh keys that will be installed on the compute nodes, so root can ssh between compute nodes without password prompting. If they are not there copy them from the MN to the SN. Again, these should have been setup by the servicenode postscripts.
* **Errors running hierarchical commands such as xdsh** -- xCAT has a number of commands that run hierarchically. That is, the commands are sent from xcatd on the management node to the correct service node xcatd, which in turn processes the command and sends the results back to xcatd on the management node. If a hierarchical command such as xcatd fails with something like "Error: Permission denied for request", check ``/var/log/messages`` on the management node for errors. One error might be "Request matched no policy rule". This may mean you will need to add policy table entries for your xCAT management node and service node.
* **/install is not mounted on service node from managemen mode** -- If service node does not have ``/install`` directory mounted from management node, run ``lsdef -t site clustersite -i installloc`` and verify ``installloc="/install"``

23
docs/source/advanced/hierarchy/define_service_nodes.rst
View File

@@ -28,6 +28,11 @@ The following table illustrates the cluster being used in this example:
| | r2n10 |
+----------------------+----------------------+
#. Modify ``site`` table attribute to include **service** group's postscripts in compute node definition: ::
chdef -t site hierarchicalattrs="postscripts"
#. Select the compute nodes that will become service nodes
The first node in each rack, ``r1n01`` and ``r2n01``, is selected to become the xCAT service nodes and manage the compute nodes in that rack
@@ -53,7 +58,7 @@ The following table illustrates the cluster being used in this example:
setupconserver=1
**Tips/Hint**
* Even if you do not want xCAT to configure any services, you must define the service nodes in the ``servicenode`` table with at least one attribute, set to 0, otherwise xCAT will not recognize the node as a service node**
* Even if you do not want xCAT to configure any services, you must define the service nodes in the ``servicenode`` table with at least one attribute, set to 0, otherwise xCAT will not recognize the node as a service node
* See the ``setup*`` attributes in the node definition man page for the list of available services: ``man node``
* For clusters with subnetted management networks, you might want to set ``setupupforward=1``
@@ -82,4 +87,20 @@ The following table illustrates the cluster being used in this example:
chdef -t group -o rack1 conserver=r1n01 monserver=r1n01
chdef -t group -o rack2 conserver=r2n01 monserver=r2n01
#. Choose location of ``/install`` and ``/tftpboot`` directories (optional).
The ``site`` table attributes ``installloc`` and ``sharedtftp`` control mounting of ``/install`` and ``/tftpboot`` directories from Management Node to Service node.
To mount ``/install`` and ``/tftpboot`` directories from Management node to each Service Node: ::
chdef -t site clustersite sharedtftp=1
chdef -t site clustersite installloc="/install"
To make ``/install`` and ``/tftpboot`` directories local on each Service Node, set ``site`` table attributes and "sync" ``/install`` and ``/tftpoot`` directory contents from Management Node to Service Nodes: ::
chdef -t site clustersite sharedtftp=0
chdef -t site clustersite installloc=
rsync -auv --exclude 'autoinst' /install r1n01:/
rsync -auv --exclude 'autoinst' /install r2n01:/
rsync -auv --exclude 'autoinst' /tftpboot r1n01:/
rsync -auv --exclude 'autoinst' /tftpboot r2n01:/

78
docs/source/advanced/hierarchy/provision/diskful_sn.rst
View File

@@ -6,33 +6,51 @@ Diskful (Stateful) Installation
Any cluster using statelite compute nodes must use a stateful (diskful) Service Nodes.
**Note: All xCAT Service Nodes must be at the exact same xCAT version as the xCAT Management Node**. Copy the files to the Management Node (MN) and untar them in the appropriate sub-directory of ``/install/post/otherpkgs``
**Note:** All xCAT Service Nodes must be at the exact same xCAT version as the xCAT Management Node.
**Note for the appropriate directory below, check the ``otherpkgdir=/install/post/otherpkgs/rhels7/x86_64`` attribute of the osimage defined for the servicenode.**
For example, for osimage rhels7-x86_64-install-service ::
Configure ``otherpkgdir`` and ``otherpkglist`` for service node osimage
-----------------------------------------------------------------------
mkdir -p /install/post/otherpkgs/**rhels7**/x86_64/xcat
cd /install/post/otherpkgs/**rhels7**/x86_64/xcat
* Create a subdirectory ``xcat`` under a path specified by ``otherpkgdir`` attribute of the service node os image, selected during the :doc:`../define_service_nodes` step.
For example, for osimage *rhels7-x86_64-install-service* ::
[root@fs4 xcat]# lsdef -t osimage rhels7-x86_64-install-service -i otherpkgdir
Object name: rhels7-x86_64-install-service
otherpkgdir=/install/post/otherpkgs/rhels7/x86_64
[root@fs4 xcat]# mkdir -p /install/post/otherpkgs/rhels7/x86_64/xcat
* Download or copy `xcat-core` and `xcat-dep` .bz2 files into that `xcat` directory ::
wget https://xcat.org/files/xcat/xcat-core/<version>_Linux/xcat-core/xcat-core-<version>-linux.tar.bz2
wget https://xcat.org/files/xcat/xcat-dep/<version>_Linux/xcat-dep-<version>-linux.tar.bz2
* untar the `xcat-core` and `xcat-dep` .bz2 files ::
cd /install/post/otherpkgs/<os>/<arch>/xcat
tar jxvf core-rpms-snap.tar.bz2
tar jxvf xcat-dep-*.tar.bz2
Next, add rpm names into your own version of service.<osver>.<arch>.otherpkgs.pkglist file. In most cases, you can find an initial copy of this file under ``/opt/xcat/share/xcat/install/<platform>`` . Or copy one from another similar platform. ::
* Verify the following entries are included in the package file specified by the ``otherpkglist`` attribute of the service node osimage. ::
mkdir -p /install/custom/install/rh
cp /opt/xcat/share/xcat/install/rh/service.rhels7.x86_64.otherpkgs.pkglist \
/install/custom/install/rh
vi /install/custom/install/rh/service.rhels7.x86_64.otherpkgs.pkglist
xcat/xcat-dep/<os>/<arch>/xCATsn
xcat/xcat-dep/<os>/<arch>/conserver-xcat
xcat/xcat-dep/<os>/<arch>/perl-Net-Telnet
xcat/xcat-dep/<os>/<arch>/perl-Expect
Make sure the following entries are included in the
/install/custom/install/rh/service.rhels7.x86_64.otherpkgs.pkglist: ::
For example, for the osimage *rhels7-x86_64-install-service* ::
xCATsn
conserver-xcat
perl-Net-Telnet
perl-Expect
[root@fs4 ~]# lsdef -t osimage rhels7-x86_64-install-service -i otherpkglist
Object name: rhels7-x86_64-install-service
otherpkglist=/opt/xcat/share/xcat/install/rh/service.rhels7.x86_64.otherpkgs.pkglist
[root@fs4 ~]# cat /opt/xcat/share/xcat/install/rh/service.rhels7.x86_64.otherpkgs.pkglist
xcat/xcat-core/xCATsn
xcat/xcat-dep/rh7/x86_64/conserver-xcat
xcat/xcat-dep/rh7/x86_64/perl-Net-Telnet
xcat/xcat-dep/rh7/x86_64/perl-Expect
[root@fs4 ~]#
**Note: you will be installing the xCAT Service Node rpm xCATsn meta-package on the Service Node, not the xCAT Management Node meta-package. Do not install both.**
**Note:** you will be installing the xCAT Service Node rpm xCATsn meta-package on the Service Node, not the xCAT Management Node meta-package. Do not install both.
Update the rhels6 RPM repository (rhels6 only)
----------------------------------------------
@@ -69,26 +87,18 @@ Update the rhels6 RPM repository (rhels6 only)
createrepo \
-g repodata /98462d05248098ef1724eddb2c0a127954aade64d4bb7d4e693cff32ab1e463c-comps-rhel6-Server.xml
**Note:** you should use comps-rhel6-Server.xml with its key as the group file.
**Note:** you should use ``comps-rhel6-Server.xml`` with its key as the group file.
Set the node status to ready for installation
---------------------------------------------
Run nodeset to the osimage name defined in the provmethod attribute on your Service Node. ::
nodeset service osimage="<osimagename>"
For example ::
nodeset <service_node> osimage="rhels7-x86_64-install-service"
Initialize network boot to install Service Nodes
------------------------------------------------
Install Service Nodes
---------------------
::
rsetboot <service_node> net
rpower <service_node> boot
rinstall <service_node> osimage="<osimagename>"
For example ::
rinstall <service_node> osimage="rhels7-x86_64-install-service"
Monitor the Installation
------------------------

2
docs/source/advanced/hierarchy/provision/diskless_sn.rst
View File

@@ -1,3 +1,5 @@
.. _setup_service_node_stateless_label:
Diskless (Stateless) Installation
=================================

14
docs/source/advanced/hierarchy/provision/verify_sn.rst
View File

@@ -2,10 +2,10 @@ Verify Service Node Installation
================================
* ssh to the service nodes. You should not be prompted for a password.
* Check to see that the xcat daemon xcatd is running.
* Run some database command on the service node, e.g tabdump site, or nodels,
and see that the database can be accessed from the service node.
* Check that ``/install`` and ``/tftpboot`` are mounted on the service node
from the Management Node, if appropriate.
* Make sure that the Service Node has Name resolution for all nodes, it will
service.
* Check to see that the xcat daemon ``xcatd`` is running.
* Run some database command on the service node, e.g ``tabdump site``, or ``nodels``, and see that the database can be accessed from the service node.
* Check that ``/install`` and ``/tftpboot`` are mounted on the service node from the Management Node, if appropriate.
* Make sure that the Service Node has name resolution for all nodes it will service.
* Run ``updatenode <compute node> -V -s`` on management node and verify output contains ``Running command on <service node>`` that indicates the command from management node is sent to service node to run against compute node target.
See :doc:`Appendix B <../appendix/appendix_b_diagnostics>` for possible solutions.

1
docs/source/advanced/index.rst
View File

@@ -15,6 +15,7 @@ Advanced Topics
kit/index.rst
mixed_cluster/index.rst
networks/index.rst
pdu/index.rst
ports/xcat_ports.rst
probe/index.rst
raid/index.rst

7
docs/source/advanced/networks/edgecore_switches/index.rst
View File

@@ -1,7 +0,0 @@
ONIE Compatible Bare Metal Switches
===================================
.. toctree::
:maxdepth: 2
onie_switches.rst

135
docs/source/advanced/networks/edgecore_switches/onie_switches.rst
View File

@@ -1,135 +0,0 @@
ONIE compatible bare metal switch
=================================
The ONIE [1]_. compatible bare metal switches(abbreviated as "ONIE switch") from vendors such as Mellanox or Edgecore are often used as top-of-rack switches in the cluster. Usually, the switches are shipped with a Cumulus Network OS(https://cumulusnetworks.com) and a license pre-installed. In some cases, user may get whitebox switch hardware with a standalone Cumulus installer and license file. This documentation presents a typical workflow on how to setup ONIE switch from white box, then configure and manage the switch with xCAT.
.. [1] Open Network Install Environment: Created by Cumulus Networks, Inc. in 2012, the Open Network Install Environment (ONIE) Project is a small operating system, pre-installed as firmware on bare metal network switches, that provides an environment for automated operating system provisioning.
Create an ONIE switch object
-------------------------------
The ONIE switch object can be created with the "onieswitch" template shipped in xCAT, the ip address and mac of the switch management ethernet port should be specified : ::
mkdef edgecoresw1 --template onieswitch arch=armv71 ip=192.168.5.191 mac=8C:EA:1B:12:CA:40
Provision the Cumulus OS on ONIE switch
---------------------------------------
To provision Cumulus OS, the Cumulus installation file, a binary shipped with the switch, should be saved in a directory exported in the http server.
Run ``chdef`` to specify the "provmethod" attribute of the switch object to the full path of the installation file: ::
chdef edgecoresw1 netboot=onie provmethod="/install/custom/sw/edgecore/cumulus-linux-3.1.0-bcm-armel-1471981017.dc7e2adzfb43f6b.bin"
Run ``makedhcp`` to prepare the DHCP/BOOTP lease. ::
makedhcp -a edgecoresw1
The command or operation to start the provision dependes on the status of switch:
1. If the switch is a white box without Cumulus OS installed, simply connect the management ethernet port of the switch to xCAT management node, then power on the switch.
2. If a Cumulus OS has been installed on the switch, you need to login to the switch(the default user is ``cumulus`` and the password is ``CumulusLinux!``) and run a batch of commands: ::
sudo onie-select -i
sudo reboot
If the passwordless-ssh of "root" has been enabled, the commands can be issued with: ::
xdsh edgecoresw1 "/usr/cumulus/bin/onie-select -i -f;reboot"
After reboot, the switch will enter ONIE install mode and begin the installation. The provision might take about 50 minutes.
Switch Configuration
--------------------
Enable the passwordless ssh for "root"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In a newly installed Cumulus OS, a default user ``cumulus`` will be created, the switch can be accessed via ssh with the default password ``CumulusLinux!``.
The passwordless ssh access of "root" should be enabled with the script ``/opt/xcat/share/xcat/scripts/configonie`` ::
/opt/xcat/share/xcat/scripts/configonie --switches edgecoresw1 --ssh
After the passwordless access for "root" is setup successfully, the switch can be managed with the node management commands such as ``xdsh``, ``xdcp`` and ``updatenode``, etc.
Licence file installation
~~~~~~~~~~~~~~~~~~~~~~~~~
On the newly installed switch, only the serial console and the management ethernet port are enabled. To activate the data ports, the licence file shipped with the switch should be installed: ::
xdcp edgecoresw1 /install/custom/sw/edgecore/licensefile.txt /tmp
xdsh edgecoresw1 "/usr/cumulus/bin/cl-license -i /tmp/licensefile.txt"
To check whether the license file is installed successfully: ::
~: xdsh edgecoresw1 /usr/cumulus/bin/cl-license
edgecoresw1: xxx@xx.com|xxxxxxxxxxxxxxx
Reboot the switch to apply the licence file: ::
xdsh edgecoresw1 reboot
Enable SNMP
~~~~~~~~~~~
The snmpd in the switch is not enabled by default, xCAT ships a postscript to enable it: ::
updatenode edgecoresw1 -P enablesnmp
Switch Discovery
----------------
The ONIE switch can be scaned and discovered with ``switchdiscover`` ::
~: switchdiscover --range 192.168.23.1-10
Discovering switches using nmap for 192.168.23.1-10. It may take long time...
ip name vendor mac
------------ ------------ ------------ ------------
192.168.23.1 edgecoresw1 Edgecore switch 8C:EA:1B:12:CA:40
Switch discovered: edgecoresw1
Once SNMP on the ONIE switch is enabled, the ONIE switch can be discovered with "snmp" method: ::
~: switchdiscover --range 192.168.23.1-10 -s snmp
Discovering switches using snmpwalk for 192.168.23.1-10 ....
ip name vendor mac
------------ ------------ ------------ ------------
192.168.23.1 edgecoresw1 Linux edgecoresw1 4.1.0-cl-2-iproc #1 SMP Debian 4.1.25-1+cl3u4 (2016-08-13) armv7l 8c:ea:1b:12:ca:40
Switch discovered: edgecoresw1
Switch Management
-----------------
File Dispatch
~~~~~~~~~~~~~
The files can be dispatched to ONIE switches with ``xdcp`` ::
xdcp edgecoresw1 <path of file to dispatch> <destination path of the file on switch>
Refer to :doc:`xdcp manpage </guides/admin-guides/references/man1/xdcp.1>` for details.
Remote Commands
~~~~~~~~~~~~~~~
Commands can be run on ONIE switches remotely with ``xdsh`` ::
xdsh edgecoresw1 <remote commands>
Refer to :doc:`xdsh manpage </guides/admin-guides/references/man1/xdsh.1>` for details.
Run scripts remotely
~~~~~~~~~~~~~~~~~~~~
The scripts under "/install/postscripts" can be run on ONIE switches with ``updatenode -P`` ::
updatenode edgecoresw1 -P <script name>
Refer to :doc:`updatenode manpage </guides/admin-guides/references/man1/updatenode.1>` for details.

2
docs/source/advanced/networks/index.rst
View File

@@ -5,7 +5,7 @@ Networks
:maxdepth: 2
ethernet_switches/index.rst
onie_switches/index.rst
switchdiscover/index.rst
infiniband/index.rst
ipv6/index.rst
edgecore_switches/index.rst

11
docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskful.rst
View File

@@ -24,14 +24,12 @@ Diskful Installation
-p postscripts="mlnxofed_ib_install -p /install/<path-to>/<MLNX_OFED_LINUX.iso> \
-m --add-kernel-support -end-"
#. Provision the node
#. Provision the node ::
rinstall <node> osimage=
#. Verification
* The Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter
* Check the status of ``openibd`` service
sysVinit: ::
@@ -42,3 +40,6 @@ Diskful Installation
systemctl status openibd.service
* Verify that the Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter.

11
docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskless.rst
View File

@@ -44,14 +44,12 @@ Diskless Installation
packimage <osimage>
#. Provision the node
#. Provision the node ::
rinstall <node> osimage=rhels7.2-ppc64le-netboot-compute
#. Verification
* The Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter
* Check the status of ``openibd`` service
sysVinit: ::
@@ -62,3 +60,6 @@ Diskless Installation
systemctl status openibd.service
* Verify that the Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter.

12
docs/source/advanced/networks/onie_switches/index.rst Normal file
View File

@@ -0,0 +1,12 @@
Open Network Install Environment Switches
=========================================
The Open Network Install Environment, or "ONIE" [1]_. is an open source project definining an **install environment** for bare metal switches. This environment allows choice for the end users when selecting a network operating system to install onto these bare metal switches.
.. toctree::
:maxdepth: 2
os_cumulus/index.rst
.. [1] Open Network Install Environment: Created by Cumulus Networks, Inc. in 2012, the Open Network Install Environment (ONIE) Project is a small operating system, pre-installed as firmware on bare metal network switches, that provides an environment for automated operating system provisioning.

12
docs/source/advanced/networks/onie_switches/os_cumulus/index.rst Normal file
View File

@@ -0,0 +1,12 @@
Cumulus Linux OS
================
This documentation will focus on installing the Cumulus Network Operating System (https://www.cumulusnetworks.com/) onto a "white-box" Edgecore switch but the same concepts should apply to other ONIE enabled switches using other network operating systems.
.. toctree::
:maxdepth: 2
prepare.rst
install.rst
manage.rst

112
docs/source/advanced/networks/onie_switches/os_cumulus/install.rst Normal file
View File

@@ -0,0 +1,112 @@
Installation and Configuration
==============================
Cumulus OS Installtion
----------------------
**Note:** *The following assumes that the physical switches have power and have obtained a DHCP IP address from the xCAT open range.*
xCAT provides support for detecting and installing the Cumulus Linux OS into ONIE enabled switches by utilizing DHCP to detect "**onie_vendor**" from the ``vendor-class-identifier`` string and then send it the Cumulus Linux OS installer.
#. Create a pre-defined switch definition for the ONIE switch using the ``onieswitch`` template.
The mac address of the switch management port is required for xCAT to configure the DHCP information and send over the OS to install on the switch.
**[small clusters]** If you know the mac address of the management port on the switch, create the pre-defined switch defintion providing the mac address. ::
mkdef frame01sw1 --template onieswitch arch=armv71 \
ip=192.168.1.1 mac="aa:bb:cc:dd:ee:ff"
**[large clusters]** xCAT's :doc:`switchdiscover </guides/admin-guides/references/man1/switchdiscover.1>` command can be used to discover the mac address and fill in the predefined switch definitions based on the switch/switchport mapping.
#. Define all the switch objects providing the switch/switchport mapping: ::
mkdef frame01sw1 --template onieswitch arch=armv71 \
ip=192.168.1.1 switch=coresw1 switchport=1
mkdef frame02sw1 --template onieswitch arch=armv71 \
ip=192.168.2.1 switch=coresw1 switchport=2
mkdef frame03sw1 --template onieswitch arch=armv71 \
ip=192.168.3.1 switch=coresw1 switchport=3
mkdef frame04sw1 --template onieswitch arch=armv71 \
ip=192.168.4.1 switch=coresw1 switchport=4
...
#. Leverage ``switchdiscover`` over the DHCP range to automatically detect the MAC address and write them into the predefined swtiches above. ::
switchdiscover --range <IP range>
#. Set the ``provmethod`` attribute of the target switch(es) to the Cumulus Linux install image: ::
chdef frame[01-04]sw1 \
provmethod="/install/custom/sw_os/cumulus/cumulus-linux-3.1.0-bcm-armel.bin"
#. Run ``makedhcp`` to prepare the DHCP/BOOTP lease information for the switch: ::
makedhcp -a frame[01-04]sw1
Executing the ``makedhcp`` command will kick off the network install of the ONIE enabled switch. If there is no OS pre-loaded on the switch, the switch continues to send a DHCPREQUEST out to the network. After ``makedhcp`` is run against the switch, an entry is added to the leases file that will respond to the request with the Cumulus Linux installer file. ::
host frame1sw1 {
dynamic;
hardware ethernet 8c:ea:1b:12:ca:40;
fixed-address 192.168.3.200;
supersede server.ddns-hostname = "frame1sw1";
supersede host-name = "frame1sw1";
if substring (option vendor-class-identifier, 0, 11) = "onie_vendor" {
supersede www-server = "http://192.168.27.1/install/custom/sw_os/cumulus/cumulus-linux-3.1.0-bcm-armel.bin";
}
}
*Typical installation time is around 1 hour*
Configure xCAT Remote Commands
------------------------------
After Cumulus Linux OS is installed, a default user ``cumulus`` will be created with default password: ``CumulusLinux!``.
To ease in the management of the switch, xCAT provides a script to help configure password-less ssh as the ``root`` user. This script sends over the xCAT ssh keys so that the xCAT remote commands (``xdsh``, ``xdcp``, etc) can be run against the ONIE switches.
Execute the following to sync the xCAT keys to the switch: ::
/opt/xcat/share/xcat/scripts/configonie --switches frame01sw1 --ssh
Validate the ssh keys are correctly configured by running a ``xdsh`` command: ::
xdsh frame01sw1 uptime
Activate the License
--------------------
After Cumulus Linux OS is installed onto the ONIE switch, only the serial port console and the management ethernet port is enabled. To activate the rest of the switch ports, the license file needs to be installed onto the switch.
#. Copy the license file to the switch: ::
xdcp frame01sw1 /install/custom/sw_os/cumulus/licensefile.txt /root/
#. Activate the license: ::
xdsh frame01sw1 "/usr/cumulus/bin/cl-license -i /root/licensefile.txt"
#. Verify that the license file is successfully installed: ::
xdsh frame01sw1 /usr/cumulus/bin/cl-license
Output should be similar to: ``frame01sw1 xxx@xx.com|xxxxxxxxxxxxxxx``
#. Reboot the switch to apply the license file: ::
xdsh frame01sw1 reboot
Enable SNMP
------------
In order to utilize ``xcatprobe switch_macmap``, snmp needs to be enabled. To enable, run the ``enablesnmp`` postscript on the switch: ::
updatenode frame01sw1 -P enablesnmp

28
docs/source/advanced/networks/onie_switches/os_cumulus/manage.rst Normal file
View File

@@ -0,0 +1,28 @@
Switch Management
=================
VLAN Configuration
------------------
xCAT ships a simple configuration script that will set all the ports on the switch to be part of VLAN 1. See the Cumulus Networks documentation for more information regarding advanced networking configuration. ::
updatenode <switch> -P configinterface
Re-install OS
-------------
There may be occasions where a re-install of the OS is required. Assuming the files are available on the xCAT management node, the following commands will invoke the install process:
* **[use xCAT]** ``xdsh`` can be used to invoke the reinstall of the OS: ::
# to clear out all the previous configuration, use the -k option (optional)
xdsh <switch> "/usr/cumulus/bin/onie-select -k
# to invoke the reinstall of the OS
xdsh <switch> "/usr/cumulus/bin/onie-select -i -f;reboot"
* **[manually]** Log into the Cumulus OS switch and run the following commands: ::
sudo onie-select -i
sudo reboot

19
docs/source/advanced/networks/onie_switches/os_cumulus/prepare.rst Normal file
View File

@@ -0,0 +1,19 @@
Preparation
===========
Prepare the Cumulus Linux files on the xCAT Management Node.
#. Obtain a valid Cumulus Linux License and download the Cumulus Linux OS installer.
#. Copy the above files into a location under the xCAT ``/install`` directory. ::
# Create a directory to hold the cumulus linux files
mkdir -p /install/custom/sw_os/cumulus/
# copy the license file
cp licensefile.txt /install/custom/sw_os/cumulus/
# copy the installer
cp cumulus-linux-3.1.0-bcm-armel.bin /install/custom/sw_os/cumulus/

91
docs/source/advanced/networks/switchdiscover/switch_based_switch_discovery.rst
View File

@@ -8,34 +8,28 @@ Pre-requirement
In order to do switch-based switch discovery, the admin
1. Needs to manually setup and configure core-switch, SNMP v3 needs to be enabled in order for xCAT access to it. **username** and **userpassword** attributes are for the remote login. It can be for **ssh** or **telnet**. If it is for **telnet**, set protocol to “telnet”. If the **username** is blank, the **username** and **password** will be retrieved from the passwd table with “switch” as the key. SNMP attributes will used for SNMPv3 communication. **nodetype** has to be set to "switch" to differentiate between switch-based node discovery or switch-based switch discovery. Refer to switches table attributes. Example of core-switch definition:
1. Needs to manually setup and configure core-switch, SNMP v3 needs to be enabled in order for xCAT access to it. **username** and **userpassword** attributes are for the remote login. It can be for **ssh** or **telnet**. If it is for **telnet**, set protocol to “telnet”. If the **username** is blank, the **username** and **password** will be retrieved from the passwd table with “switch” as the key. SNMP attributes will used for SNMPv3 communication. **nodetype** has to be set to "switch" to differentiate between switch-based node discovery or switch-based switch discovery. Refer to switches table attributes. Example of core-switch definition: ::
::
lsdef switch-10-5-23-1
Object name: switch-10-5-23-1
groups=switch
ip=10.5.23.1
mac=ab:cd:ef:gh:dc
mgt=switch
nodetype=switch
password=admin
postbootscripts=otherpkgs
postscripts=syslog,remoteshell,syncfiles
protocol=telnet
snmpauth=sha
snmppassword=userpassword
snmpusername=snmpadmin
snmpversion=3
switchtype=BNT
usercomment=IBM
username=root
lsdef switch-10-5-23-1
Object name: switch-10-5-23-1
groups=switch
ip=10.5.23.1
mac=ab:cd:ef:gh:dc
mgt=switch
nodetype=switch
password=admin
postbootscripts=otherpkgs
postscripts=syslog,remoteshell,syncfiles
protocol=telnet
snmpauth=sha
snmppassword=userpassword
snmpusername=snmpadmin
snmpversion=3
switchtype=BNT
usercomment=IBM
username=root
2. Predefine all top-rack switches which connect to core-switch. The attribute **ip** is static ip address for the switch. When ``switchdiscover --setup`` command is issued, this ip address will replace dhcp IP address on the switch. **nodetype=switch** needs to be set to differentiate between switch-based node discovery or switch-based switch discovery during discovery process. the attribute **switch** is hostname of core-switch and **switchport** is the port number in the core-switch that top-rack switch is connected to.
::
2. Predefine all top-rack switches which connect to core-switch. The attribute **ip** is static IP address for the switch. When ``switchdiscover --setup`` command is issued, this IP address will replace dhcp IP address on the switch. **nodetype=switch** needs to be set to differentiate between switch-based node discovery or switch-based switch discovery during discovery process. the attribute **switch** is hostname of core-switch and **switchport** is the port number in the core-switch that top-rack switch is connected to. ::
lsdef switch-192-168-5-22
objtype=node
@@ -50,13 +44,13 @@ In order to do switch-based switch discovery, the admin
3. Add switches to /etc/hosts for hostname lookup and xdsh command. ::
makehosts switch-192-168-5-23
makehosts switch-192-168-5-22
makehosts switch-192-168-5-23
makehosts switch-192-168-5-22
4. Setup Dynamic IP range in network table for discovered switches to use. ::
# tabdump networks
# tabdump networks
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,mtu,comments,disable
"192_168_0_0-255_255_0_0","192.168.0.0","255.255.0.0","enP4p1s0f2","<xcatmaster>",,"192.168.3.29",,,,"192.168.5.150-192.168.5.170",,,,,,,,,
@@ -67,7 +61,7 @@ dhcp should be restarted after seting up dynamic IP range.
Discover Switches
~~~~~~~~~~~~~~~~~
xCAT supports **switchdiscover** command to discover the switches that are attached to the subnets on xCAT management node. Refer to http://xcat-docs.readthedocs.io/en/latest/advanced/networks/switchdiscover/switches_discovery.html for more info.
xCAT supports **switchdiscover** command to discover the switches that are attached to the subnets on xCAT management node. Refer to :doc:`/advanced/networks/switchdiscover/switches_discovery` for more info.
For the switch-based switch discovery, we add **–setup** flag: ::
@@ -125,13 +119,11 @@ if **--setup** flag is specified, the command will perform following steps:
Configure switches
~~~~~~~~~~~~~~~~~~
The **switchdiscover** command with ``--setup`` flag will set up switches with static ip address, change the hostname from predefine switches and enable snmpv3 configuration. For other switches configuration, Refer to http://xcat-docs.readthedocs.io/en/latest/advanced/networks/ethernet_switches/ethernet_switches.html and http://xcat-docs.readthedocs.io/en/latest/advanced/networks/infiniband/switch_configuration.html
The **switchdiscover** command with ``--setup`` flag will set up switches with static IP address, change the hostname from predefine switches and enable snmpv3 configuration. For other switches configuration, refer to :doc:`/advanced/networks/ethernet_switches/ethernet_switches` and :doc:`/advanced/networks/infiniband/switch_configuration`.
These two config files are located in the **/opt/xcat/share/xcat/scripts**. The **switchdiscover** process will call the config files with ``--all`` option. User can call these scripts to setup one of options manually.
These two config files are located in the **/opt/xcat/share/xcat/scripts** directory. The **switchdiscover** process will call the config files with ``--all`` option. User can call these scripts to setup one of options manually.
1. **configBNT** is for configure BNT switches.
::
1. **configBNT** is for configure BNT switches. ::
./configBNT --help
Usage:
@@ -142,21 +134,22 @@ These two config files are located in the **/opt/xcat/share/xcat/scripts**. The
configBNT [--switches switchnames] [--snmp] [--user snmp_user] [--password snmp_password] [--group snmp_group]
configBNT [--switches switchnames] [--port port] [--vlan vlan]
2. **configMellanox** is for configuring Mellanox switch. The script will configure ntp service on the switch with xCAT MN and will use rspconfig command to
* enable ssh
* enable snmp function on the switch
* enable the snmp trap
* set logging destination to xCAT MN
2. **configMellanox** is for configuring Mellanox switch. The script will configure ntp service on the switch with xCAT MN and will use rspconfig command to
::
* enable ssh
* enable snmp function on the switch
* enable the snmp trap
* set logging destination to xCAT MN
./configMellanox --help
Usage:
configMellonax [-?│-h│--help]
configMellonax [--switches switchnames] [--all]
configMellonax [--switches switchnames] [--ip]
configMellonax [--switches switchnames] [--name]
configMellonax [--switches switchnames] [--config]
::
./configMellanox --help
Usage:
configMellonax [-?│-h│--help]
configMellonax [--switches switchnames] [--all]
configMellonax [--switches switchnames] [--ip]
configMellonax [--switches switchnames] [--name]
configMellonax [--switches switchnames] [--config]
Switch Status
@@ -166,7 +159,7 @@ During the switch-based switch discovery process, there are four states displaye
**Matched** --- Discovered switch is matched to predefine switch, **otherinterfaces** attribute is updated to dhcp IP address, and mac address, **switch type** and **usercomment** also updated with vendor information for the predefined switch.
**ip_configed** --- switch is set up to static ip address based on predefine switch IP address. If failure to set up IP address, the status will stay as **Matched**.
**ip_configed** --- switch is set up to static IP address based on predefine switch IP address. If failure to set up IP address, the status will stay as **Matched**.
**hostname_configed** -- switch host name is changed based on predefine switch hostname. If failure to change hostname on the switch, the status will stay as **ip_configed**.

10
docs/source/advanced/pdu/index.rst Normal file
View File

@@ -0,0 +1,10 @@
PDUs
====
Power Distribution Units (PDUs) are devices that distribute power to servers in a frame. Intelligent PDUs have the capability of monitoring the amount of power that is being used by devices plugged into it.
.. toctree::
:maxdepth: 2
pdu.rst

147
docs/source/advanced/pdu/pdu.rst Normal file
View File

@@ -0,0 +1,147 @@
PDU
===
xCAT provides basic remote management for each power outlet plugged into the PDUs using SNMP communication. This documentation will focus on configuration of the PDU and Node objects to allow xCAT to control power at the PDU outlet level.
Define PDU Objects
------------------
#. Define pdu object ::
mkdef f5pdu3 groups=pdu ip=50.0.0.8 mgt=pdu nodetype=pdu
#. Add hostname to /etc/hosts::
makehosts f5pdu3
#. Verify the SNMP command responds against the PDU: ::
snmpwalk -v1 -cpublic -mALL f5pdu3 .1.3.6.1.2.1.1
Define PDU Attribute
--------------------
Administrators will need to know the exact mapping of the outlets to each server in the frame. xCAT cannot validate the physical cable is connected to the correct server.
Add a ``pdu`` attribute to the compute node definition in the form "PDU_Name:outlet": ::
#
# Compute server cn01 has two power supplies
# connected to outlet 6 and 7 on pdu=f5pdu3
#
chdef cn01 pdu=f5pdu3:6,f5pdu3:7
Verify the setting: ``lsdef cn01 -i pdu``
PDU Commands
------------
The following commands are supported against a compute node:
* Check the pdu status for a compute node: ::
# rpower cn01 pdustat
cn01: f5pdu3 outlet 6 is on
cn01: f5pdu3 outlet 7 is on
* Power off the PDU outlets on a compute node: ::
# rpower cn01 pduoff
cn01: f5pdu3 outlet 6 is off
cn01: f5pdu3 outlet 7 is off
* Power on the PDU outlets on a compute node: ::
# rpower cn01 pduon
cn01: f5pdu3 outlet 6 is on
cn01: f5pdu3 outlet 7 is on
* Power cycling the PDU outlets on a compute node: ::
# rpower cn01 pdureset
cn01: f5pdu3 outlet 6 is reset
cn01: f5pdu3 outlet 7 is reset
The following commands are supported against a PDU:
* Check the status of the full PDU: ::
# rinv f5pdu3
f5pdu3: outlet 1 is on
f5pdu3: outlet 2 is on
f5pdu3: outlet 3 is on
f5pdu3: outlet 4 is on
f5pdu3: outlet 5 is on
f5pdu3: outlet 6 is off
f5pdu3: outlet 7 is off
f5pdu3: outlet 8 is on
f5pdu3: outlet 9 is on
f5pdu3: outlet 10 is on
f5pdu3: outlet 11 is on
f5pdu3: outlet 12 is on
* Power off the full PDU: ::
# rpower f5pdu3 off
f5pdu3: outlet 1 is off
f5pdu3: outlet 2 is off
f5pdu3: outlet 3 is off
f5pdu3: outlet 4 is off
f5pdu3: outlet 5 is off
f5pdu3: outlet 6 is off
f5pdu3: outlet 7 is off
f5pdu3: outlet 8 is off
f5pdu3: outlet 9 is off
f5pdu3: outlet 10 is off
f5pdu3: outlet 11 is off
f5pdu3: outlet 12 is off
* Power on the full PDU: ::
# rpower f5pdu3 on
f5pdu3: outlet 1 is on
f5pdu3: outlet 2 is on
f5pdu3: outlet 3 is on
f5pdu3: outlet 4 is on
f5pdu3: outlet 5 is on
f5pdu3: outlet 6 is on
f5pdu3: outlet 7 is on
f5pdu3: outlet 8 is on
f5pdu3: outlet 9 is on
f5pdu3: outlet 10 is on
f5pdu3: outlet 11 is on
f5pdu3: outlet 12 is on
* Power reset the full PDU: ::
# rpower f5pdu3 reset
f5pdu3: outlet 1 is reset
f5pdu3: outlet 2 is reset
f5pdu3: outlet 3 is reset
f5pdu3: outlet 4 is reset
f5pdu3: outlet 5 is reset
f5pdu3: outlet 6 is reset
f5pdu3: outlet 7 is reset
f5pdu3: outlet 8 is reset
f5pdu3: outlet 9 is reset
f5pdu3: outlet 10 is reset
f5pdu3: outlet 11 is reset
f5pdu3: outlet 12 is reset
**Note:** For BMC based compute nodes, turning the PDU outlet power on does not automatically power on the compute side. Users will need to issue ``rpower <node> on`` to power on the compute node after the BMC boots.

63
docs/source/advanced/security/certs.rst Normal file
View File

@@ -0,0 +1,63 @@
The SSL Certificates in xCAT
----------------------------
The xCAT daemon on the management node and service node listens on a SSL socket on port 3001, the communications on the SSL socket include:
1. the xCAT requests from xCAT Clients
2. the xCAT requests forwarded from other xCAT daemons, for example, the requests forwarded between xCAT daemons on management node and service nodes
3. some special xCAT requests from compute nodes, such as ``getcredentials``, ``getpostscript``, ``litefile``, etc.
xCAT creates 1 CA certificate and 2 credentials (private key and certificate pairs):
1. xCAT CA certificate(ca.pem):
* a self-signed certificate used as Certificate Authority in xcatd SSL communication;
* generated by ``/opt/xcat/share/xcat/scripts/setup-xcat-ca.sh`` script on xCAT installation;
* will be generated (or updated) on xCAT management node when:
* install or update xCAT when "/etc/xcat/ca" directory does not exist
* or run ``xcatconfig -f|--force``
* or run ``xcatconfig -c|--credentials``
* files on management node:
* ``/etc/xcat/ca/ca-cert.pem``
* ``/etc/xcat/cert/ca.pem`` ,copied by ``/opt/xcat/share/xcat/scripts/setup-server-cert.sh``
* ``/root/.xcat/ca.pem`` ,copied by ``/opt/xcat/share/xcat/scripts/setup-local-client.sh``
* file on service node: ``/root/.xcat/ca.pem``
* distribution path:
**/etc/xcat/cert/ca.pem (MN)** ===(run ``xcatconfig`` command)===> **/install/postscripts/_xcat/ca.pem (MN)** ===(node provision/updatenode)==> **/xcatpost/_xcat/ca.pem (SN and CN)** ==(run "servicenode" postscript)==> **/root/.xcat/ca.pem (SN)**
2. xCAT server credential(server-cred.pem):
* a concatenation of server private key and certificate(signed with xCAT CA certificate)
* generated by ``/opt/xcat/share/xcat/scripts/setup-server-cert.sh`` on xCAT installation;
* will be generated (or updated) on xCAT management node when:
* install or update xCAT when ``/etc/xcat/cert`` directory does not exist
* or run ``xcatconfig -f|--force``
* or run ``xcatconfig -c|--credentials``
* file on management node: ``/etc/xcat/cert/server-cred.pem``
* file on service node: ``/etc/xcat/cert/server-cred.pem``
* distribution path:
**/etc/xcat/cert/server-cred.pem (MN)** ==(run ``xcatserver`` script called by ``servicenode`` postscript)===> **/etc/xcat/cert/server-cred.pem(SN)**
3. xCAT client credential(client-cred.pem):
* a concatenation of client private key and certificate (signed with xCAT CA certificate)
* generated by ``/opt/xcat/share/xcat/scripts/setup-local-client.sh`` on xCAT installation
* will be generated (or updated) on xCAT management node when:
* install or update xCAT when ``/root/.xcat/client-key.pem`` does not exist;
* or run ``xcatconfig -f|--force``
* or run ``xcatconfig -c|--credentials``
* file on management node: ``/root/.xcat/client-cred.pem``
* file on service node: ``/root/.xcat/client-cred.pem``
* distribution path:
**/root/.xcat/client-cred.pem (MN)** ===(run ``xcatclient`` script called by ``servicenode`` postscript")===> **/root/.xcat/client-cred.pem(SN)**
The usage of the credentials in the xCAT SSL communication is:
.. image:: ./imgs/certs.png
:height: 500 px
:width: 600 px
:scale: 100 %
:alt: alternate text
:align: center

BIN
docs/source/advanced/security/imgs/certs.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 218 KiB

42
docs/source/advanced/security/security.rst
View File

@@ -4,52 +4,40 @@ Transmission Channel
The xCAT daemon uses SSL to only allow authorized users to run xCAT commands. All xCAT commands are initiated as an xCAT **client**, even when run commands from the xCAT management node. This **client** opens an SSL socket to the xCAT daemon, sends the command and receives responses through this one socket. xCAT has configured the certificate for root, if you nee to authorize other users, refer to the section below.
Create SSL Certificate So That User Can Be Authenticated By xCAT
````````````````````````````````````````````````````````````````
Running the following command on the Management node as root: ::
/opt/xcat/share/xcat/scripts/setup-local-client.sh <username>
By running this command you'll see SSL certificates are creating, enter ``yes`` where prompted and take the defaults.
This will create the following files in the <username> 's ``$HOME/.xcat`` directory: ::
ca.pem
client-cert.pem
client-cred.pem
client-key.pem
client-req.pem
.. toctree::
:maxdepth: 2
certs.rst
Commands Access Control
-----------------------
Except SSL channel, xCAT only authorize root on the management node to run **xCAT** commands by default. But xCAT can be configured to allow both **non-root users** and **remote users** to run limited xCAT commands. For remote users, we mean the users who triggers the xCAT commands from other nodes and not have to login to the management node. xCAT uses the **policy** table to control who has authority to run specific xCAT commands. For a full explanation of the **policy** table, refer to :doc:`policy </guides/admin-guides/references/man5/policy.5>` man page.
.. _granting_xcat_privileges:
Granting Users xCAT Privileges
``````````````````````````````
To give a non-root user all xCAT commands privileges, run ``tabedit policy`` and add a line: ::
To give a non-root user all xCAT command privileges, run ``tabedit policy`` and add a line: ::
"6","<username>",,,,,,"allow",,
Where <username> is the name of the user that you are granting privileges to. In the above case, this user can now perform all xCAT commands, including changing the ``policy`` table to grant right to other users, so this should be used with caution.
Where <username> is the name of the user that you are granting privileges to. This user can now perform all xCAT commands, including changing the ``policy`` table to grant rights to other users, so this should be used with caution.
You may only want to grant users limited access. One example is that one user may only be allowed to run ``nodels``. This can be done as follows: ::
To grant a user ability to run ``nodels`` command: ::
"6","<username>",,"nodels",,,,"allow",,
If you want to grant all users the ability to run nodels, add this line: ::
To grant all users the ability to run ``nodels``: ::
"6.1","*",,"nodels",,,,"allow",,
You also can do this by running: ::
CLI can also be used: ::
chdef -t policy -o 6.1 name=* commands=nodels rule=allow
**Note** Make sure the directories that contain the xCAT commands are in the user's ``$PATH``. If not, add them to ``$PATH`` as appropriate way in your system. ::
**Note** Make sure the directories that contain the xCAT commands are in the user's ``$PATH``. If not, add them to ``$PATH`` as appropriate in your system. ::
echo $PATH | grep xcat
/opt/xcat/bin:/opt/xcat/sbin: .......
@@ -57,18 +45,18 @@ You also can do this by running: ::
Extra Setup for Remote Commands
```````````````````````````````
To give a user the ability to run remote commands (xdsh, xdcp, psh, pcp) in some node, except above steps, also need to run below steps: ::
To give a user the ability to run remote commands (``xdsh``, ``xdcp``, ``psh``, ``pcp``) in some node, in addition to above steps, also need to run below steps: ::
su - <username>
xdsh <noderange> -K
This will setup the user and root ssh keys for the user under the ``$HOME/.ssh`` directory of the user on the nodes. The root ssh keys are needed for the user to run the xCAT commands under the xcatd daemon, where the user will be running as root. **Note**: the uid for the user should match the uid on the management node and a password for the user must have been set on the nodes.
This will setup the user and root ssh keys for the user under the ``$HOME/.ssh`` directory of the user on the nodes. The root ssh keys are needed for the user to run the xCAT commands under the xcatd daemon, where the user will be running as root. **Note**: the uid and the password for the user on the management node, should match the uid and password on the managed nodes.
Set Up Login Node (Remote Client)
`````````````````````````````````
In some cases, you don't want your **non-root** user login to management node but still can run some xCAT commands. This time, you need setup a login node(i.e. remote client) for these users.
In some cases, you don't want your **non-root** user login to management node but still can run some xCAT commands. This time, you need setup a login node (i.e. remote client) for these users.
Below are the steps of how to set up a login node.
@@ -78,9 +66,9 @@ Below are the steps of how to set up a login node.
* :doc:`Configure xCAT Software Repository in RHEL</guides/install-guides/yum/configure_xcat>`
* `Configure the Base OS Repository in SUSE <http://xcat-docs.readthedocs.org/en/latest/guides/install-guides/zypper/prepare_mgmt_node.html#configure-the-base-os-repository>`_
* :ref:`Configure the Base OS Repository in SUSE <zypper_configure_the_base_os_repository>`
* `Configure the Base OS Repository in Ubuntu <http://xcat-docs.readthedocs.org/en/latest/guides/install-guides/apt/prepare_mgmt_node.html#configure-the-base-os-repository>`_
* :ref:`Configure the Base OS Repository in Ubuntu <apt_configure_the_base_os_repository>`
Then install ``xCAT-client``.

34
docs/source/advanced/sysclone/sysclone.rst
View File

@@ -35,16 +35,16 @@ List of Supported Arch and OS
Using Sysclone to Install Nodes
-------------------------------
This document describes how to install and configure a template node (called golden client), capture an image from this template node. Then using this image to deploy other same nodes (called target nodes) quickly.
This document describes how to install and configure a template node (called golden client), capture an image from this template node, then using this image to deploy other nodes (called target nodes) quickly.
Prepare the xCAT Management Node for Support Sysclone
`````````````````````````````````````````````````````
To configure xCAT management node refer to section :ref:`install_guides`
For support Sysclone, we need to install some extra rpms on management node and the golden client.
To support Sysclone, we need to install some extra rpms on management node and the golden client.
1. Download the xcat-dep tarball (xcat-dep-XXX.tar.bz2) which includes extra rpms needed by Sysclone. (You might already have the xcat-dep tarball on management node. If not, go to `xcat-dep <http://xcat.org/files/xcat-dep/2.x_Linux>`_ and get the latest xCAT dependency tarball.)
1. Download the xcat-dep tarball (xcat-dep-XXX.tar.bz2) which includes extra rpms needed by Sysclone. (You might already have the xcat-dep tarball on management node. If not, go to `xcat-dep <http://xcat.org/files/xcat/xcat-dep/2.x_Linux>`_ and get the latest xCAT dependency tarball.)
2. Install systemimager server on management node
@@ -56,7 +56,7 @@ For support Sysclone, we need to install some extra rpms on management node and
zypper -n install systemimager-server
*[Note] Maybe you will encounter below failed message when you install systemimager-server, just ignore it.*::
*[Note] You may ignore the following messages when installing systemimager-server.*::
Can't locate AppConfig.pm in @INC (@INC contains: /usr/lib/systemimager/perl /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/lib/systemimager/perl/SystemImager/Config.pm line 13.
BEGIN failed--compilation aborted at /usr/lib/systemimager/perl/SystemImager/Config.pm line 13.
@@ -65,7 +65,7 @@ For support Sysclone, we need to install some extra rpms on management node and
Compilation failed in require at /usr/sbin/si_mkrsyncd_conf line 28.
BEGIN failed--compilation aborted at /usr/sbin/si_mkrsyncd_conf line 28.
3. Do some preparation for install and configure golden client in management node. Copy the xcat-dep-XXX.tar.bz2 file to directory ``/install/post/otherpkgs/<os>/<arch>/xcat/`` of the management node according your golden client's OS version and system architecture, then decompression it. For example:
3. Copy the xcat-dep-XXX.tar.bz2 file to directory ``/install/post/otherpkgs/<os>/<arch>/xcat/`` of the management node according your golden client's OS version and system architecture, then decompress it:
* **[CentOS6.3 and x86_64]**::
@@ -91,15 +91,15 @@ For support Sysclone, we need to install some extra rpms on management node and
Install and Configure the Golden Client
```````````````````````````````````````
The Golden Client acts as a regular node for xCAT, just have some extra rpms to support clone. When you deploy golden client with xCAT, you just need to add a few additional definitions to the image which will be used to deploy golden client.
The Golden Client acts as a regular node for xCAT, it just has some extra rpms to support clone. When you deploy golden client with xCAT, you just need to add a few additional definitions to the image which will be used to deploy golden client.
For information of how to install a regular node, refer to section :ref:`Diskful Installation <diskful_installation>`
For support clone, add 'otherpkglist' and 'otherpkgdir' attributes to the image definition which will be used to deploy golden client, then deploy golden client as normal. then the golden client will have extra rpms to support clone. If you have deployed your golden client already, using 'updatenode' command to push these extra rpms to golden client. CentOS share the same pkglist file with RHEL. For example:
To support clone, add 'otherpkglist' and 'otherpkgdir' attributes to the image definition which will be used to deploy golden client, then deploy golden client as normal. Once deployed, the golden client will have extra rpms to support cloning. If you have deployed your golden client already, use **updatenode** command to push these extra rpms to golden client. CentOS shares the same pkglist file with RHEL. For example:
* **[RH6.4 and x86_64]**::
chdef -t osimage -o <osimage-name> otherpkglist=/opt/xcat/share/xcat/instal/rh/sysclone.rhels6.x86_64.otherpkgs.pkglist
chdef -t osimage -o <osimage-name> otherpkglist=/opt/xcat/share/xcat/install/rh/sysclone.rhels6.x86_64.otherpkgs.pkglist
chdef -t osimage -o <osimage-name> -p otherpkgdir=/install/post/otherpkgs/rhels6.4/x86_64
updatenode <golden-cilent> -S
@@ -121,23 +121,23 @@ For support clone, add 'otherpkglist' and 'otherpkgdir' attributes to the image
chdef -t osimage -o <osimage-name> -p otherpkgdir=/install/post/otherpkgs/rhels6.3/ppc64
updatenode <golden-cilent> -S
*[Note]: If you install systemimager RPMs on CentOS 6.5 node by above steps, you maybe hit failure. this is a known issue because some defect of CentOS6.5 itself. Refer to known issue section for help.*
*[Note]: If you install systemimager RPMs on CentOS 6.5 node by above steps, you maybe hit a failure. This is a known issue with CentOS6.5. Refer to known issue section for help.*
Capture Image from Golden Client
````````````````````````````````
On Management node, use xCAT command 'imgcapture' to capture an image from the golden-client.::
On Management node, use xCAT command **imgcapture** to capture an image from the golden-client.::
imgcapture <golden-client> -t sysclone -o <mycomputeimage>
When imgcapture is running, it pulls the image from the golden-client, and creates a image files system and a corresponding osimage definition on the xcat management node. You can use below command to check the osimage attributes.::
When **imgcapture** is running, it pulls the image from the golden-client, and creates an image files system and a corresponding osimage definition on the xcat management node. You can use command below to check the osimage attributes.::
lsdef -t osimage <mycomputeimage>
Install the target nodes with the image from the golden-client
``````````````````````````````````````````````````````````````
following below commands to install the target nodes with the image captured from golden client.
To install the target nodes with the image captured from golden client.
* **[x86_64]**::
@@ -155,11 +155,11 @@ following below commands to install the target nodes with the image captured fro
Update Nodes Later On
---------------------
If, at a later time, you need to make changes to the golden client (install new rpms, change config files, etc.), you can capture the changes and push them to the already cloned nodes without need to restart cloned nodes. This process will only transfer the deltas, so it will be much faster than the original cloning.
If, at a later time, you need to make changes to the golden client (install new rpms, change config files, etc.), you can capture the changes and push them to the already cloned nodes without a need to restart cloned nodes. This process will only transfer the deltas, so it will be much faster than the original cloning.
**[Limitation]**: In xcat2.8.5, this feature has limitation in RHEL and CentOS. when your delta changes related bootloader, it would encounter error. This issue will be fixed in xcat higher version. So up to now, in RHEL and CentOS, this feature just update files not related bootloader.
**[Limitation]**: In xcat2.8.5, this feature has limitation on RHEL and CentOS. When your delta changes related bootloader, it would encounter error. This issue will be fixed in xcat higher version. So up to now, in RHEL and CentOS, this feature just update files not related bootloader.
Update delta changes follow below steps:
Update delta changes:
1. Make changes to your golden node (install new rpms, change config files, etc.).
@@ -199,7 +199,7 @@ Known Issue
Can not install systemimager RPMs in CentOS6.5 by yum
``````````````````````````````````````````````````````
If you install systemimager RPMs on CentOS 6.5 node using yum, you may experience some problems due to CentOS6.5 itself. If that happens, copy related RPMs to CentOS 6.5 node and install them by hand.
If you install systemimager RPMs on CentOS 6.5 node using **yum**, you may experience some problems due to CentOS6.5 itself. If that happens, copy related RPMs to CentOS 6.5 node and install them by hand.
* **On management node**::
@@ -220,4 +220,4 @@ If you install systemimager RPMs on CentOS 6.5 node using yum, you may experienc
Kernel panic at times when install target node with rhels7.0 in Power 7 server
``````````````````````````````````````````````````````````````````````````````
When you clone rhels7.0 image to target node which is Power 7 server lpar, maybe you will hit Kernel panic problem at times after boot loader grub2 download kernel and initrd. This is an known issue but without resolve yet. up to now, we recommend you try again.
When you clone rhels7.0 image to target node which is Power 7 server lpar, you may hit Kernel panic problem at times after boot loader grub2 download kernel and initrd. This is an known issue but without a resulution. For now, we recommend you try again.

5
docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/ubuntu_os_other_pkg.rst
View File

@@ -32,5 +32,8 @@ Compute nodes can access the internet
Compute nodes can not access the internet
------------------------------------------
If compute nodes cannot access the internet, there are two ways to install additional packages:use apt proxy or use local mirror according to :ref:`ubuntu-install-non-internet`
If compute nodes cannot access the internet, there are two ways to install additional packages
* use apt proxy
* use local mirror

125
docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_network.rst
View File

@@ -1,121 +1,10 @@
Advanced Networking Configuration
=================================
The ``confignetwork`` postscript can be used to configure the network interfaces on the compute nodes to support VLAN, BONDs, and BRIDGES. In order to use the ``confignetwork`` postscript, the following attributes must be configured for the node in the ``nics`` table:
* ``nicips``
* ``nictypes``
* ``nicnetworks``
* ``nicdevices`` - resolves the relationship among the physical network intereface devices
The following example set the xCAT properties for compute node ``cn1`` to achieve the following network configuration using the ``confignetwork`` postscript:
* Compute node ``cn1`` has two physical NICs: eth2 and eth3
* Bond eth2 and eth3 as ``bond0``
* From ``bond0``, create 2 VLANs: ``bond0.1`` and ``bond0.2``
* Make bridge ``br1`` using ``bond0.1`` with IP (10.0.0.1)
* Make bridge ``br2`` using ``bond0.2`` with IP (20.0.0.1)
Define attributes in the ``nics`` table
---------------------------------------
#. Using the ``mkdef`` or ``chdef`` commands
a. Compute node ``cn1`` has two physical NICs: ``eth2`` and ``eth3`` ::
chdef cn1 nictypes.eth2=ethernet nictypes.eth3=ethernet
b. Define ``bond0`` and bond ``eth2`` and ``eth3`` as ``bond0`` ::
chdef cn1 nictypes.bond0=bond \
nicdevices.bond0="eth2|eth3"
c. Fom ``bond0``, create 2 VLANs: ``bond0.1`` and ``bond0.2`` ::
chdef cn1 nictypes.bond0.1=vlan \
nictypes.bond0.2=vlan \
nicdevices.bond0.1=bond0 \
nicdevices.bond0.2=bond0
d. Create bridge ``br1`` using ``bond0.1`` with IP (10.0.0.1) ::
chdef cn1 nictypes.br1=bridge \
nicdevices.br1=bond0.1 \
nicips.br1=10.0.0.1 \
nicnetworks.br1="net10"
e. Create bridge ``br2`` using ``bond0.2`` with IP (20.0.0.1) ::
chdef cn1 nictypes.br2=bridge \
nicdevices.br2=bond0.2 \
nicips.br2=20.0.0.1 \
nicnetworks.br2="net20"
#. Using an xCAT stanza file
- Prepare a stanza file ``<filename>.stanza`` with content similiar to the following: ::
# <xCAT data object stanza file>
cn1:
objtype=node
arch=x86_64
groups=kvm,vm,all
nicdevices.br1=bond0.1
nicdevices.br2=bond0.2
nicdevices.bond0.1=bond0
nicdevices.bond0.2=bond0
nicdevices.bond0=eth2|eth3
nictypes.eth2=ethernet
nictypes.eth3=ethernet
nictypes.bond0=bond
nictypes.bond0.1=vlan
nictypes.bond0.2=vlan
nictypes.br1=bridge
nictypes.br2=bridge
nicips.br1=10.0.0.1
nicips.br2=20.0.0.1
nicnetworks.br1=net10
nicnetworks.br2=net20
- Using the ``mkdef -z`` option, define the stanza file to xCAT: ::
cat <filename>.stanza | mkdef -z
#. Using ``tabedit`` to edit the ``nics`` database table directly
The ``tabedit`` command opens the specified xCAT database table in a ``vi`` like editor and allows the user to edit any text and write the changes back to the database table.
After changing the content of the ``nics`` table, here is the result from ``tabdump nics`` ::
# tabdump nics
#node,nicips,nichostnamesuffixes,nichostnameprefixes,nictypes,niccustomscripts,nicnetworks,nicaliases,nicextraparams,nicdevices,comments,disable
"cn1","br1!10.0.0.1,br2!20.0.0.1",,,"br1!bridge,eth2!ethernet,eth3!ethernet,bond0.2!vlan,bond0!bond,br2!bridge,bond0.1!vlan",,"br1!net10,br2!net20",,,"br1!bond0.1,bond0!eth2|eth3,bond0.2!bond0,bond0.1!bond0,br2!bond0.2",,
Add network object into the networks table
------------------------------------------
The ``nicnetworks`` attribute only defines the nic that uses the IP address.
Other information about the network should be defined in the ``networks`` table.
Use the ``chdef`` command to add/modify the networks in the ``networks`` table ::
chdef -t network net10 net=10.0.0.0 mask=255.0.0.0 mgtifname=eth0
chdef -t network net20 net=20.0.0.0 mask=255.0.0.0 mgtifname=eth1
Add ``confignetwork`` into the node's postscripts list
------------------------------------------------------
Using below command to add ``confignetwork`` into the node's postscripts list ::
chdef cn1 -p postscripts=confignetwork
During OS deployment on compute node, ``confignetwork`` will be run in postscript.
If the compute node has OS, use ``updatenode`` command to run ``confignetwork`` ::
updatenode cn1 -P confignetwork
Advanced Networking Configuration - confignetwork
=================================================
**Note:** ``confignetwork`` postscript is only supported on RHEL releases.
.. toctree::
:maxdepth: 2
.. include:: ../../../common/deployment/cfg_network_vlan.rst
.. include:: ../../../common/deployment/cfg_network_bond.rst

58
docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_network_bond.rst Normal file
View File

@@ -0,0 +1,58 @@
Configure Two Bonded Adapters
-----------------------------
The following example set the xCAT properties for compute node ``cn1`` to create:
* Compute node ``cn1`` has two physical NICs: eth2 and eth3
* Bond eth2 and eth3 as ``bond0``
* Assign ip ``40.0.0.1`` to the bonded interface ``bond0``
Define attributes in the ``nics`` table
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Using the ``mkdef`` or ``chdef`` commands
a. Compute node ``cn1`` has two physical NICs: ``eth2`` and ``eth3`` ::
chdef cn1 nictypes.eth2=ethernet nictypes.eth3=ethernet
b. Define ``bond0`` and bond ``eth2`` and ``eth3`` as ``bond0`` ::
chdef cn1 nictypes.bond0=bond nicdevices.bond0="eth2|eth3"
chdef cn1 nicips.bond0=40.0.0.1
Add network object into the networks table
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the ``chdef`` command to add/modify the networks in the ``networks`` table ::
chdef -t network net40 net=40.0.0.0 mask=255.0.0.0
chdef cn1 nicnetworks.bond0=net40
Add ``confignetwork`` into the node's postscripts list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use command below to add ``confignetwork`` into the node's postscripts list ::
chdef cn1 -p postscripts=confignetwork
During OS deployment on compute node, ``confignetwork`` postscript will be executed.
If the compute node is already running, use ``updatenode`` command to run ``confignetwork`` postscript without rebooting the node::
updatenode cn1 -P confignetwork
Verify bonding mode
~~~~~~~~~~~~~~~~~~~
Login to compute node cn1 and check bonding options in ``/etc/sysconfig/network-scripts/ifcfg-bond0`` file ::
BONDING_OPTS="mode=802.3ad xmit_hash_policy=layer2+3"
* ``mode=802.3ad`` requires additional configuration on the switch.
* ``mode=2`` can be used for bonding without additional switch configuration.
If changes are made to ``/etc/sysconfig/network-scripts/ifcfg-bond0`` file, restart network service.

109
docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_network_vlan.rst Normal file
View File

@@ -0,0 +1,109 @@
Configure BOND, VLAN and BRIDGES
--------------------------------
The ``confignetwork`` postscript can be used to configure the network interfaces on the compute nodes to support VLAN, BONDs, and BRIDGES. In order for the ``confignetwork`` postscript to run successfully, the following attributes must be configured for the node in the ``nics`` table:
* ``nicips``
* ``nictypes``
* ``nicnetworks``
* ``nicdevices`` - resolves the relationship among the physical network interface devices
The following example set the xCAT properties for compute node ``cn1`` to achieve the following network configuration using the ``confignetwork`` postscript:
* Compute node ``cn1`` has two physical NICs: ``eth2`` and ``eth3``
* Bond ``eth2`` and ``eth3`` as ``bond0``
* From ``bond0``, create 2 VLANs: ``bond0.1`` and ``bond0.2``
* Make bridge ``br1`` using ``bond0.1`` with IP (10.0.0.1)
* Make bridge ``br2`` using ``bond0.2`` with IP (20.0.0.1)
Define attributes in the ``nics`` table
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chose one of two methods described below:
#. Using the ``mkdef`` or ``chdef`` commands
a. Compute node ``cn1`` has two physical NICs: ``eth2`` and ``eth3`` ::
chdef cn1 nictypes.eth2=ethernet nictypes.eth3=ethernet
b. Define ``bond0`` and bond ``eth2`` and ``eth3`` as ``bond0`` ::
chdef cn1 nictypes.bond0=bond \
nicdevices.bond0="eth2|eth3"
c. From ``bond0``, create 2 VLANs: ``bond0.1`` and ``bond0.2`` ::
chdef cn1 nictypes.bond0.1=vlan \
nictypes.bond0.2=vlan \
nicdevices.bond0.1=bond0 \
nicdevices.bond0.2=bond0
d. Create bridge ``br1`` using ``bond0.1`` with IP (10.0.0.1) ::
chdef cn1 nictypes.br1=bridge \
nicdevices.br1=bond0.1 \
nicips.br1=10.0.0.1 \
nicnetworks.br1="net10"
e. Create bridge ``br2`` using ``bond0.2`` with IP (20.0.0.1) ::
chdef cn1 nictypes.br2=bridge \
nicdevices.br2=bond0.2 \
nicips.br2=20.0.0.1 \
nicnetworks.br2="net20"
#. Using an xCAT stanza file
- Prepare a stanza file ``<filename>.stanza`` with content similiar to the following: ::
# <xCAT data object stanza file>
cn1:
objtype=node
arch=x86_64
groups=kvm,vm,all
nicdevices.br1=bond0.1
nicdevices.br2=bond0.2
nicdevices.bond0.1=bond0
nicdevices.bond0.2=bond0
nicdevices.bond0=eth2|eth3
nictypes.eth2=ethernet
nictypes.eth3=ethernet
nictypes.bond0=bond
nictypes.bond0.1=vlan
nictypes.bond0.2=vlan
nictypes.br1=bridge
nictypes.br2=bridge
nicips.br1=10.0.0.1
nicips.br2=20.0.0.1
nicnetworks.br1=net10
nicnetworks.br2=net20
- Using the ``mkdef -z`` option, define the stanza file to xCAT: ::
cat <filename>.stanza | mkdef -z
Define the additional networks to xCAT
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If this is a new network being created on the compute nodes, an entry needs to be created into the xCAT database.
The ``nicnetworks`` attribute only defines the nic that uses the IP address.
Other information about the network should be defined in the ``networks`` table.
Use the ``chdef`` command to add/modify the networks in the ``networks`` table ::
chdef -t network net10 net=10.0.0.0 mask=255.0.0.0
chdef -t network net20 net=20.0.0.0 mask=255.0.0.0
Add ``confignetwork`` into the node's postscripts list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the following command to add ``confignetwork`` into postscript list to execute on reboot: ::
chdef cn1 -p postscripts=confignetwork
If the compute node is already running, use ``updatenode`` command to run ``confignetwork`` postscript without rebooting the node::
updatenode cn1 -P confignetwork

13
docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_second_adapter.rst
View File

@@ -1,5 +1,5 @@
Configure Additional Network Interfaces
=======================================
Configure Additional Network Interfaces - confignics
====================================================
The **nics** table and the **confignics** postscript can be used to automatically configure additional network interfaces (mutltiple ethernets adapters, InfiniBand, etc) on the nodes as they are being deployed.
@@ -47,7 +47,7 @@ There are 3 ways to complete this operation.
The ``tabedit`` command opens the specified xCAT database table in a vi like editor and allows the user to edit any text and write the changes back to the database table.
*WARNING* Using the ``tabedit`` command is not the recommended method because it is tedious and error prone.
*WARNING:* Using the ``tabedit`` command is not the recommended method because it is tedious and error prone.
After changing the content of the ``nics`` table, here is the result from ``tabdump nics`` ::
@@ -70,7 +70,7 @@ After you have defined the configuration information in any of the ways above, r
Add confignics into the node's postscripts list
-----------------------------------------------
Using below command to add confignics into the node's postscripts list ::
Use command below to add confignics into the node's postscripts list ::
chdef cn1 -p postscripts=confignics
@@ -78,7 +78,7 @@ By default, confignics does not configure the install nic. if need, using flag "
chdef cn1 -p prostscripts="confignics -s"
Option "-s" write the install nic's information into configuration file for persistance. All install nic's data defined in nics table will be written also.
Option "-s" writes the install nic's information into configuration file for persistance. All install nic's data defined in nics table will be written also.
Add network object into the networks table
@@ -103,6 +103,7 @@ Option -r to remove the undefined NICS
If the compute node's nics were configured by ``confignics`` and the nics configuration changed in the nics table, user the ``confignics -r`` to remove the undefined nic.
For example, if on a compute node the ``eth0``, ``eth1``, and ``eth2`` nics were configured: ::
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:14:5e:d9:6c:e6
...
@@ -114,7 +115,7 @@ For example, if on a compute node the ``eth0``, ``eth1``, and ``eth2`` nics were
Delete the eth2 definition in nics table using the ``chdef`` command.
Then run the following to remove the undefined ``eth2`` nic on the compute node: ::
# updatenode <noderange> -P "confignics -r"
updatenode <noderange> -P "confignics -r"
The result should have ``eth2`` disabled: ::

16
docs/source/guides/admin-guides/manage_clusters/common/parallel_cmd.rst
View File

@@ -25,11 +25,11 @@ Examples for xdsh
xdsh node1 -K
- To run the ps -ef command on node targets node1 and node2, enter: ::
- To run the ``ps -ef`` command on node targets node1 and node2, enter: ::
xdsh node1,node2 "ps -ef"
- To run the ps command on node targets node1 and run the remote command with the -v and -t flag, enter: ::
- To run the ``ps`` command on node targets node1 and run the remote command with the ``-v`` and ``-t`` flag, enter: ::
xdsh node1,node2 -o"-v -t" ps =item *
@@ -37,15 +37,15 @@ Examples for xdsh
xdsh node1,node2 -f 1 -e myfile
- To run the ps command on node1 and ignore all the dsh environment variable except the DSH_NODE_OPTS, enter: ::
- To run the ``ps`` command on node1 and ignore all the dsh environment variable except the DSH_NODE_OPTS, enter: ::
xdsh node1 -X `DSH_NODE_OPTS' ps
- To run on Linux, the xdsh command "dpkg | grep vim" on the node ubuntu diskless image, enter: ::
- To run on Linux, the ``xdsh`` command ``dpkg -l| grep vim`` on the node ubuntu diskless image, enter: ::
xdsh -i /install/netboot/ubuntu14.04.2/ppc64el/compute/rootimg "dpkg -l|grep vim"
- To run xdsh with the non-root userid "user1" that has been setup as an xCAT userid and with sudo on node1 and node2 to run as root, do the following, see xCAT doc on Granting_Users_xCAT_privileges: ::
- To run ``xdsh`` with the non-root userid "user1" that has been setup as an xCAT userid and with sudo on node1 and node2 to run as root, do the following, see :ref:`Granting users xCAT privileges <granting_xcat_privileges>`: ::
xdsh node1,node2 --sudo -l user1 "cat /etc/passwd"
@@ -70,7 +70,7 @@ Examples for xdcp
xdcp all /etc/hosts /etc/hosts
- To rsync the /etc/hosts file to your compute nodes:
- To ``rsync`` the /etc/hosts file to your compute nodes:
Create a rsync file /tmp/myrsync, with this line: ::
@@ -84,7 +84,7 @@ Examples for xdcp
xdcp compute -F /tmp/myrsync
- To rsync the /etc/file1 and file2 to your compute nodes and rename to filex and filey:
- To ``rsync`` the /etc/file1 and file2 to your compute nodes and rename to filex and filey:
Create a rsync file /tmp/myrsync, with these line: ::
@@ -96,7 +96,7 @@ Examples for xdcp
xdcp compute -F /tmp/myrsync to update the Compute Nodes
- To rsync files in the Linux image at /install/netboot/ubuntu14.04.2/ppc64el/compute/rootimg on the MN:
- To ``rsync`` files in the Linux image at /install/netboot/ubuntu14.04.2/ppc64el/compute/rootimg on the MN:
Create a rsync file /tmp/myrsync, with this line: ::

1
docs/source/guides/admin-guides/manage_clusters/index.rst
View File

@@ -11,3 +11,4 @@ The sections are organized based on hardware architecture.
ppc64le/index.rst
x86_64/index.rst
openbmc/index.rst

9
docs/source/guides/admin-guides/manage_clusters/openbmc/configure.rst Normal file
View File

@@ -0,0 +1,9 @@
Configure passwords
===================
Configure the passwords for Management modules of the compute nodes.
* For OpenBMC managed systems: ::
chtab key=openbmc passwd.username=root passwd.password=0penBMC

11
docs/source/guides/admin-guides/manage_clusters/openbmc/index.rst Normal file
View File

@@ -0,0 +1,11 @@
OpenPOWER (OpenBMC managed)
===========================
The following sections document the procedures in managing OpenPOWER servers in an xCAT cluster.
OpenPower servers are machines that use IBM Power Architecture and are **OpenBMC** managed.
.. toctree::
:maxdepth: 2
configure.rst
openbmc.rst

60
docs/source/guides/admin-guides/manage_clusters/openbmc/openbmc.rst Normal file
View File

@@ -0,0 +1,60 @@
Manually Define Nodes
=====================
If admin knows the detailed information of the physical server, ``mkdef`` command can be used to manually define it into xCAT database.
In this document, the following configuration is used as an example
Compute Node info::
CN Hostname: cn1
BMC Address: 50.0.101.1
OpenBMC username: root
OpenBMC Password: 0penBMC
Run ``mkdef`` command to define the node: ::
mkdef -t node cn1 groups=openbmc,all mgt=openbmc cons=openbmc bmc=50.0.101.1 bmcusername=root bmcpassword=0penBmc
The manually defined node will be ::
# lsdef cn1
Object name: cn1
bmc=50.0.101.1
bmcpassword=0penBmc
bmcusername=root
cons=openbmc
groups=openbmc,all
mgt=openbmc
postbootscripts=otherpkgs
postscripts=syslog,remoteshell,syncfiles
Hardware Management
===================
Remote Power Control
````````````````````
``rpower`` command can be used to control the power of a remote physical machine. ::
rpower cn1 on
rpower cn1 off
rpower cn1 boot
rpower cn1 reset
To get the current rpower state of a machine: ::
# rpower cn1 state
cn1: on
Remote Console
``````````````
``rcons`` command can be used to get command line remote console.
#. Make sure the ``conserver`` is configured by running ``makeconservercf cn1``.
#. Start command line remote console: ::
rcons cn1

24
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/discovery_using_defined.rst
View File

@@ -27,27 +27,17 @@ The BMC IP address is obtained by the open range dhcp server and the plan in thi
#. Detect the BMCs and add the node definitions into xCAT.
Use the ``bmcdiscover`` command to discover the BMCs responding over an IP range and automatically write the output into the xCAT database. You **must** use the ``-w`` option to automatically write the output into the xCAT database.
Use the :doc:`bmcdiscover </guides/admin-guides/references/man1/bmcdiscover.1>` command to discover the BMCs responding over an IP range and write the output into the xCAT database. This discovered BMC node is used to control the physical server during hardware discovery and will be deleted after the correct server node object is matched to a pre-defined node. You **must** use the ``-w`` option to write the output into the xCAT database.
To discover the BMC with an IP address of 172.30.0.1, use the command: ::
To discover the BMC with an IP address range of 50.0.100.1-100: ::
bmcdiscover --range 172.30.0.1 -z -w
bmcdiscover --range 50.0.100.1-100 -z -w
The discovered nodes will be written to xCAT database: ::
The discovered nodes will be written to xCAT database. The discovered BMC nodes are in the form **node-model_type-serial**. To view the discovered nodes: ::
# lsdef node-8247-22l-10112ca
Object name: node-8247-22l-10112ca
bmc=172.30.0.1
cons=ipmi
groups=all
hwtype=bmc
mgt=ipmi
mtm=8247-22L
nodetype=mp
postbootscripts=otherpkgs
postscripts=syslog,remoteshell,syncfiles
serial=10112CA
nodetype=mp
lsdef /node-.*
**Note:** The ``bmcdiscover`` command will use the username/password from the ``passwd`` table corresponding to ``key=ipmi``. To overwrite with a different username/password use the ``-u`` and ``-p`` option to ``bmcdiscover``.
#. **Pre-define** the compute nodes:

27
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/pbmc_discovery_with_bmcdiscover.rst
View File

@@ -3,31 +3,18 @@ Discover server and define
After environment is ready, and the server is powered, we can start server discovery process. The first thing to do is discovering the FSP/BMC of the server. It is automatically powered on when the physical server is powered.
The following command can be used to discovery BMC within an IP range and write the discovered node definition into xCAT database::
Use the :doc:`bmcdiscover </guides/admin-guides/references/man1/bmcdiscover.1>` command to discover the BMCs responding over an IP range and write the output into the xCAT database. This discovered BMC node is used to control the physical server during hardware discovery and will be deleted after the correct server node object is matched to a pre-defined node. You **must** use the ``-w`` option to write the output into the xCAT database.
bmcdiscover -s nmap --range 50.0.100.1-100 -z -w
To discover the BMC with an IP address range of 50.0.100.1-100: ::
The discovered BMC node will be like this::
bmcdiscover --range 50.0.100.1-100 -z -w
# lsdef node-8247-42l-10112ca
Object name: node-8247-42l-10112ca
bmc=50.0.100.1
cons=ipmi
groups=all
hwtype=bmc
mgt=ipmi
mtm=8247-42L
nodetype=mp
postbootscripts=otherpkgs
postscripts=syslog,remoteshell,syncfiles
serial=10112CA
The discovered nodes will be written to xCAT database. The discovered BMC nodes are in the form **node-model_type-serial**. To view the discovered nodes: ::
**Note**:
1. The BMC node is just used to control the physical during hardware discovery process, it will be deleted after the correct server node object is found.
2. bmcdiscover will use username/password pair set in ``passwd`` table with **key** equal **ipmi**. If you'd like to use other username/password pair, you can use ::
lsdef /node-.*
**Note:** The ``bmcdiscover`` command will use the username/password from the ``passwd`` table corresponding to ``key=ipmi``. To overwrite with a different username/password use the ``-u`` and ``-p`` option to ``bmcdiscover``.
bmcdiscover -s nmap --range 50.0.100.1-100 -z -w -u <username> -p <password>
Start discovery process
-----------------------

1
docs/source/guides/admin-guides/manage_clusters/ppc64le/index.rst
View File

@@ -13,6 +13,7 @@ These are machines use the IBM Power Architecture and is **IPMI** managed.
management.rst
diskful/index.rst
diskless/index.rst
statelite/index.rst
updatenode.rst
parallel_cmd.rst
virtual_machines/index.rst

266
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/advanced_features.rst Normal file
View File

@@ -0,0 +1,266 @@
Advanced features
=================
Both directory and its child items coexist in litefile table
------------------------------------------------------------
As described in the above chapters, we can add the files/directories to litefile table. Sometimes, it is necessary to put one directory and also its child item(s) into the litefile table. Due to the implementation of the statelite on Linux, some scenarios works, but some doesn't work.
Here are some examples of both directory and its child items coexisting:
Both the parent directory and the child file coexist: ::
"ALL","/root/testblank/",,,
"ALL","/root/testblank/tempfschild","tempfs",,
One more complex example: ::
"ALL","/root/",,,
"ALL","/root/testblank/tempfschild","tempfs",,
Another more complex example, but we don't intend to support such one scenario: ::
"ALL","/root/",,,
"ALL","/root/testblank/",,,
"ALL","/root/testblank/tempfschild","tempfs",,
For example, in scenario 1, the parent is ``/root/testblank/``, and the child is ``/root/testblank/tempfschild``.
In scenario 2, the parent is ``/root/``, and the child is ``/root/testblank/tempfschild``.
In order to describe the hierarchy scenarios we can use , ``P`` to denote parent, and ``C`` to denote child.
+--------------+-----------------------------------------------------+-------------------------------------------------+
| Option | Example | Remarks |
+==============+=====================================================+=================================================+
| P:tmpfs | "ALL","/root/testblank/",,, | Both the parent and the child are mounted to |
| | "ALL","/root/testblanktempfschild","tempfs",, | tmpfs on the booted node following their |
| | | respective options. Only the parent are mounted |
| | | to the local file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:tmpfs | "ALL","/root/testblank/",,, | Both parent and child are mounted to tmpfs |
| C:persistent | "ALL","/root/testblank/testpersfile","persistent",, | on the booted node following their respective |
| | | options. Only the parent is mounted to the local|
| | | file |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:persistent | "ALL","/root/testblank/","persistent",, | Not permitted now. But plan to support it. |
| C:tmpfs | "ALL","/root/testblank/tempfschild",,, | |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:persistent | "ALL","/root/testblank/","persistent",, | Both parent and child are mounted to tmpfs |
| C:persistent | "ALL","/root/testblank/testpersfile","persistent",, | on the booted node following their respective |
| | | options. Only the parent is mounted to local |
| | | file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:ro C:any | | Not permitted |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:tmpfs C:ro | | Both parent and child are mounted to tmpfs |
| | | on the booted node following their respective |
| | | options. Only the parent is mounted to local |
| | | file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:tmpfs | | Both parent and child are mounted to tmpfs |
| C:con | | on the booted node following their respective |
| | | options. Only the parent is mounted to local |
| | | file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:link | "ALL","/root/testlink/","link",, | Both parent and child are created in tmpfs |
| C:link | "ALL","/root/testlink/testlinkchild","link",, | on the booted node following their respective |
| | | options; there's only one symbolic link of |
| | | the parent is created in the local file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P: link C: | "ALL","/root/testlinkpers/","link",, | Both parent and child are created in tmpfs |
| link, | "ALL","/root/testlink/testlinkchild",, | on the booted node following their respective |
| persistent | "link,persistent" | options; there's only one symbolic link of |
| | | the parent is created in the local file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:link, | "ALL","/root/testlinkpers/","link,persistent",, | NOT permitted |
| persistent | | |
| C: link | "ALL","/root/testlink/testlinkchild","link" | |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:link, | "ALL","/root/testlinkpers/","link,persistent",, | Both parent and child are created in tmpfs |
| persistent | "ALL","/root/testlink | on the booted node following "link,persistent" |
| C:link, | | way; there's only one symbolic link of the |
| persistent | | parent is created in the local file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:link | "ALL","/root/testlink/","link",, | Both parent and child are created in tmpfs |
| C:link,ro | "ALL","/root/testlink/testlinkro","link,ro",, | on the booted node, there's only one symbolic |
| | | link of the parent is created in the local |
| | | file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:link | "ALL","/root/testlink/","link",, | Both parent and child are created in tmpfs |
| C:link,con | "ALL","/root/testlink/testlinkconchild","link,con",,| on the booted node, there's only one symbolic |
| | | link of the parent in the local file system. |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:link, | | NOT Permitted |
| persistent | | |
| C:link,ro | | |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:link, | | NOT Permitted |
| persistent | | |
| C:link,con | | |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:tmpfs | | NOT Permitted |
| C:link | | |
+--------------+-----------------------------------------------------+-------------------------------------------------+
| P:link | | NOT Permitted |
| C:persistent | | |
+--------------+-----------------------------------------------------+-------------------------------------------------+
litetree table
--------------
The litetree table controls where the initial content of the files in the litefile table come from, and the long term content of the ``ro`` files. When a node boots up in statelite mode, it will by default copy all of its tmpfs files from the ``/.default`` directory of the root image, so there is not requirement to setup a litetree table. If you decide that you want some of the files pulled from different locations that are different per node, you can use this table.
See litetree man page for description of attributes.
For example, a user may have two directories with a different ``/etc/motd`` that should be used for nodes in two locations: ::
10.0.0.1:/syncdirs/newyork-590Madison/rhels5.4/x86_64/compute/etc/motd
10.0.0.1:/syncdirs/shanghai-11foo/rhels5.4/x86_64/compute/etc/motd
You can specify this in one row in the litetree table: ::
1,,10.0.0.1:/syncdirs/$nodepos.room/$nodetype.os/$nodetype.arch/$nodetype.profile
When each statelite node boots, the variables in the litetree table will be substituted with the values for that node to locate the correct directory to use. Assuming that ``/etc/motd`` was specified in the litefile table, it will be searched for in all of the directories specified in the litetree table and found in this one.
You may also want to look by default into directories containing the node name first: ::
$noderes.nfsserver:/syncdirs/$node
The litetree prioritizes where node files are found. The first field is the priority. The second field is the image name (ALL for all images) and the final field is the mount point.
Our example is as follows: ::
1,,$noderes.nfsserver:/statelite/$node
2,,cnfs:/gpfs/dallas/
The two directories ``/statelite/$node`` on the node's $noderes.nfsserver and the ``/gpfs/dallas`` on the node cnfs contain root tree structures that are sparsely populated with files that we want to place in those nodes. If files are not found in the first directory, it goes to the next directory. If none of the files can be found in the litetree hierarchy, then they are searched for in ``/.default`` on the local image.
Installing a new Kernel in the statelite image
----------------------------------------------
Obtain you new kernel and kernel modules on the MN, for example here we have a new SLES kernel.
#. Copy the kernel into /boot : ::
cp **vmlinux-2.6.32.10-0.5-ppc64**/boot
#. Copy the kernel modules into ``/lib/modules/<new kernel directory>`` ::
/lib/modules # ls -al
total 16
drwxr-xr-x 4 root root 4096 Apr 19 10:39 .
drwxr-xr-x 17 root root 4096 Apr 13 08:39 ..
drwxr-xr-x 3 root root 4096 Apr 13 08:51 2.6.32.10-0.4-ppc64
**drwxr-xr-x 4 root root 4096 Apr 19 10:12 2.6.32.10-0.5-ppc64**
#. Run genimage to update the statelite image with the new kernel ::
genimage -k 2.6.32.10-0.5-ppc64 <osimage_name>
#. Then after a nodeset command and netbooti, shows the new kernel::
uname -a
Enabling the localdisk Option
-----------------------------
``Note``: You can skip this section if not using the ``localdisk`` option in your litefile table.
Several things need to be done to enable the 'localdisk' support:
Define how to partition the local disk
``````````````````````````````````````
When a node is deployed, the local hard disk needs to be partitioned and formatted before it can be used. This section explains how provide a configuration file that tells xCAT to partition a local disk and make it ready to use for the directories listed in the litefile table with the ``localdisk`` option.
The configuration file needs to be specified in the ``partitionfile`` attribute of the osimage definition. The configuration file includes several parts:
* Global parameters to control enabling or disabling the function
* [disk] part to control the partitioning of the disk
* [localspace] part to control which partition will be used to store the localdisk directories listed in the litefile table
* [swapspace] part to control the enablement of the swap space for the node.
An example localdisk configuration file: ::
enable=yes
enablepart=no
[disk]
dev=/dev/sdb
clear=yes
parts=100M-200M,1G-2G
[disk]
dev=/dev/sda
clear=yes
parts=10,20,30
[disk]
dev=/dev/sdc
clear=yes
parts=10,20,30
[localspace]
dev=/dev/sda1
fstype=ext3
[swapspace]
dev=/dev/sda2
The two global parameters ``enable`` and ``enablepart`` can be used to control the enabling/disabling of the functions:
* enable: The localdisk feature only works when ``enable`` is set to *yes*. If it is set to *no*, the localdisk configuration will not be run.
* enablepart: The partition action (refer to the ``[disk]`` section) will be run only when ``enablepart=yes``.
The ``[disk]`` section is used to configure how to partition a hard disk:
* dev: The path of the device file.
* clear: If set to ``yes`` it will clear all the existing partitions on this disk.
* fstype: The file system type for the new created partitions. ``ext3`` is the default value if not set.
* parts: A comma separated list of space ranges, one for each partition that will be created on the device. The valid format for each space range is ``<startpoint>-<endpoint>`` or ``<percentage of the disk>``. For example, you could set it to ``100M-10G`` or ``50``. If you set it to ``50``, that means 50% of the disk space will be assigned to that partition.
The ``[localspace]`` section is used to specify which partition will be used as local storage for the node.
* dev: The path of the partition.
* fstype: The file system type on the partition.
the ``[swapspace]`` section is used to configure the swap space for the statelite node.
* dev: The path of the partition file which will be used as the swap space.
To enable the local disk capability, create the configuration file (for example in ``/install/custom``) and set the path in the partitionfile attribute for the osimage: ::
chdef -t osimage partitionfile=/install/custom/cfglocaldisk
Now all nodes that use this osimage (i.e. have their provmethod attribute set to this osimage definition name), will have its local disk configured.
Configure the files in the litefile table
`````````````````````````````````````````
For the files/directories that you would like xCAT to store on the local disk, add an entry in the litefile table like this: ::
"ALL","/tmp/","localdisk",,
``Note``: you do not need to specify the swap space in the litefile table. Just putting it in the partitionfile config file is enough.
Add an entry in policy table to permit the running of the ``getpartitioin`` command from the node ::
chtab priority=7.1 policy.commands=getpartition policy.rule=allow
If Using the RAMdisk-based Image
````````````````````````````````
If you want to use the local disk option with a RAMdisk-based image, remember to follow the instructions in :doc:`Switch to the RAMdisk based solution <./provision_statelite>`.
If your reason for using a RAMdisk image is to avoid compute node runtime dependencies on the service node or management node, then the only entries you should have in the litefile table should be files/dirs that use the localdisk option.
Debugging techniques
--------------------
When a node boots up in statelite mode, there is a script that runs called statelite that is in the root directory of ``$imageroot/etc/init.d/statelite``. This script is not run as part of the rc scripts, but as part of the pre-switch root environment. Thus, all the linking is done in this script. There is a ``set x`` near the top of the file. You can uncomment it and see what the script runs. You will then see lots of mkdirs and links on the console.
You can also set the machine to shell. Just add the word ``shell`` on the end of the pxeboot file of the node in the append line. This will make the init script in the initramfs pause 3 times before doing a switch_root.
When all the files are linked they are logged in ``/.statelite/statelite.log`` on the node. You can get into the node after it has booted and look in the ``/.statelite`` directory.

137
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/config_statelite.rst Normal file
View File

@@ -0,0 +1,137 @@
Configuration
=============
Statelite configuration is done using the following tables in xCAT:
* litefile
* litetree
* statelite
* policy
* noderes
litefile table
--------------
The litefile table specifies the directories and files on the statelite nodes that should be read/write, persistent, or read-only overlay. All other files in the statelite nodes come from the read-only statelite image.
#. The first column in the litefile table is the image name this row applies to. It can be an exact osimage definition name, an osimage group (set in the groups attribute of osimages), or the keyword ``ALL``.
#. The second column in the litefile table is the full path of the directory or file on the node that you are setting options for.
#. The third column in the litefile table specifies options for the directory or file:
#. tmpfs - It provides a file or directory for the node to use when booting, its permission will be the same as the original version on the server. In most cases, it is read-write; however, on the next statelite boot, the original version of the file or directory on the server will be used, it means it is non-persistent. This option can be performed on files and directories.
#. rw - Same as Above.Its name "rw" does NOT mean it always be read-write, even in most cases it is read-write. Do not confuse it with the "rw" permission in the file system.
#. persistent - It provides a mounted file or directory that is copied to the xCAT persistent location and then over-mounted on the local file or directory. Anything written to that file or directory is preserved. It means, if the file/directory does not exist at first, it will be copied to the persistent location. Next time the file/directory in the persistent location will be used. The file/directory will be persistent across reboots. Its permission will be the same as the original one in the statelite location. It requires the statelite table to be filled out with a spot for persistent statelite. This option can be performed on files and directories.
#. con - The contents of the pathname are concatenated to the contents of the existing file. For this directive the searching in the litetree hierarchy does not stop when the first match is found. All files found in the hierarchy will be concatenated to the file when found. The permission of the file will be "-rw-r--r--", which means it is read-write for the root user, but readonly for the others. It is non-persistent, when the node reboots, all changes to the file will be lost. It can only be performed on files. Do not use it for one directory.
#. ro - The file/directory will be overmounted read-only on the local file/directory. It will be located in the directory hierarchy specified in the litetree table. Changes made to this file or directory on the server will be immediately seen in this file/directory on the node. This option requires that the file/directory to be mounted must be available in one of the entries in the litetree table. This option can be performed on files and directories.
#. tmpfs,rw - Only for compatibility it is used as the default option if you leave the options column blank. It has the same semantics with the link option, so when adding new items into the _litefile table, the link option is recommended.
#. link - It provides one file/directory for the node to use when booting, it is copied from the server, and will be placed in tmpfs on the booted node. In the local file system of the booted node, it is one symbolic link to one file/directory in tmpfs. And the permission of the symbolic link is "lrwxrwxrwx", which is not the real permission of the file/directory on the node. So for some application sensitive to file permissions, it will be one issue to use "link" as its option, for example, "/root/.ssh/", which is used for SSH, should NOT use "link" as its option. It is non-persistent, when the node is rebooted, all changes to the file/directory will be lost. This option can be performed on files and directories.
#. link,ro - The file is readonly, and will be placed in tmpfs on the booted node. In the local file system of the booted node, it is one symbolic link to the tmpfs. It is non-persistent, when the node is rebooted, all changes to the file/directory will be lost. This option requires that the file/directory to be mounted must be available in one of the entries in the litetree table. The option can be performed on files and directories.
#. link,con - Similar to the "con" option. All the files found in the litetree hierarchy will be concatenated to the file when found. The final file will be put to the tmpfs on the booted node. In the local file system of the booted node, it is one symbolic link to the file/directory in tmpfs. It is non-persistent, when the node is rebooted, all changes to the file will be lost. The option can only be performed on files.
#. link,persistent - It provides a mounted file or directory that is copied to the xCAT persistent location and then over-mounted to the tmpfs on the booted node, and finally the symbolic link in the local file system will be linked to the over-mounted tmpfs file/directory on the booted node. The file/directory will be persistent across reboots. The permission of the file/directory where the symbolic link points to will be the same as the original one in the statelite location. It requires the statelite table to be filled out with a spot for persistent statelite. The option can be performed on files and directories.
#. localdisk - The file or directory will be stored in the local disk of the statelite node. Refer to the section To enable the localdisk option to enable the 'localdisk' support.
Currently, xCAT does not handle the relative links very well. The relative links are commonly used by the system libraries, for example, under ``/lib/`` directory, there will be one relative link matching one ``.so`` file. So, when you add one relative link to the litefile table (Not recommend), make sure the real file also be included, or put its directory name into the litefile table.
**Note**: It is recommended that you specify at least the entries listed below in the litefile table, because most of these files need to be writeable for the node to boot up successfully. When any changes are made to their options, make sure they won't affect the whole system.
Sample Data for Redhat statelite setup
``````````````````````````````````````
This is the minimal list of files needed, you can add additional files to the litefile table. ::
#image,file,options,comments,disable
"ALL","/etc/adjtime","tmpfs",,
"ALL","/etc/securetty","tmpfs",,
"ALL","/etc/lvm/","tmpfs",,
"ALL","/etc/ntp.conf","tmpfs",,
"ALL","/etc/rsyslog.conf","tmpfs",,
"ALL","/etc/rsyslog.conf.XCATORIG","tmpfs",,
"ALL","/etc/udev/","tmpfs",,
"ALL","/etc/ntp.conf.predhclient","tmpfs",,
"ALL","/etc/resolv.conf","tmpfs",,
"ALL","/etc/yp.conf","tmpfs",,
"ALL","/etc/resolv.conf.predhclient","tmpfs",,
"ALL","/etc/sysconfig/","tmpfs",,
"ALL","/etc/ssh/","tmpfs",,
"ALL","/etc/inittab","tmpfs",,
"ALL","/tmp/","tmpfs",,
"ALL","/var/","tmpfs",,
"ALL","/opt/xcat/","tmpfs",,
"ALL","/xcatpost/","tmpfs",,
"ALL","/etc/systemd/system/multi-user.target.wants/","tmpfs",,
"ALL","/root/.ssh/","tmpfs",,
"ALL","/etc/rc3.d/","tmpfs",,
"ALL","/etc/rc2.d/","tmpfs",,
"ALL","/etc/rc4.d/","tmpfs",,
"ALL","/etc/rc5.d/","tmpfs",,
Sample Data for SLES statelite setup
````````````````````````````````````
This is the minimal list of files needed, you can add additional files to the litefile table. ::
#image,file,options,comments,disable
"ALL","/etc/lvm/","tmpfs",,
"ALL","/etc/ntp.conf","tmpfs",,
"ALL","/etc/ntp.conf.org","tmpfs",,
"ALL","/etc/resolv.conf","tmpfs",,
"ALL","/etc/hostname","tmpfs",,
"ALL","/etc/ssh/","tmpfs",,
"ALL","/etc/sysconfig/","tmpfs",,
"ALL","/etc/syslog-ng/","tmpfs",,
"ALL","/etc/inittab","tmpfs",,
"ALL","/tmp/","tmpfs",,
"ALL","/etc/init.d/rc3.d/","tmpfs",,
"ALL","/etc/init.d/rc5.d/","tmpfs",,
"ALL","/var/","tmpfs",,
"ALL","/etc/yp.conf","tmpfs",,
"ALL","/etc/fstab","tmpfs",,
"ALL","/opt/xcat/","tmpfs",,
"ALL","/xcatpost/","tmpfs",,
"ALL","/root/.ssh/","tmpfs",,
"ALL","/etc/systemd/system/","tmpfs",,
"ALL","/etc/adjtime","tmpfs",,
litetree table
--------------
The litetree table controls where the initial content of the files in the litefile table come from, and the long term content of the ``ro`` files. When a node boots up in statelite mode, it will by default copy all of its tmpfs files from the ``.default`` directory of the root image, for example ``/install/netboot/rhels7.3/x86_64/compute/rootimg/.default``, so there is not required to set up a litetree table. If you decide that you want some of the files pulled from different locations that are different per node, you can use this table.
You can choose to use the defaults and not set up a litetree table.
statelite table
---------------
The statelite table specifies location on an NFS server where a nodes persistent files are stored. This is done by entering the information into the statelite table.
In the statelite table, the node or nodegroups in the table must be unique; that is a node or group should appear only once in the first column table. This makes sure that only one statelite image can be assigned to a node. An example would be: ::
"compute",,"<nfssvr_ip>:/gpfs/state",,
Any nodes in the compute node group will have their state stored in the ``/gpfs/state`` directory on the machine with ``<nfssvr_ip>`` as its IP address.
When the node boots up, then the value of the ``statemnt`` attribute will be mounted to ``/.statelite/persistent``. The code will then create the following subdirectory ``/.statelite/persistent/<nodename>``, if there are persistent files that have been added in the litefile table. This directory will be the root of the image for this node's persistent files. By default, xCAT will do a hard NFS mount of the directory. You can change the mount options by setting the mntopts attribute in the statelite table.
Also, to set the ``statemnt`` attribute, you can use variables from xCAT database. It follows the same grammar as the litetree table. For example: ::
#node,image,statemnt,mntopts,comments,disable
"cn1",,"$noderes.nfsserver:/lite/state/$nodetype.profile","soft,timeo=30",,
``Note``: Do not name your persistent storage directory with the node name, as the node name will be added in the directory automatically. If you do, then a directory named ``/state/cn1`` will have its state tree inside ``/state/cn1/cn1``.
Policy
------
Ensure policies are set up correctly in the Policy Table. When a node boots up, it queries the xCAT database to get the litefile and litetree table information. In order for this to work, the commands (of the same name) must be set in the policy table to allow nodes to request it. This should happen automatically when xCAT is installed, but you may want to verify that the following lines are in the policy table: ::
chdef -t policy -o 4.7 commands=litefile rule=allow
chdef -t policy -o 4.8 commands=litetree rule=allow
noderes
-------
``noderes.nfsserver`` attribute can be set for the NFSroot server. If this is not set, then the default is the Management Node.
``noderes.nfsdir`` can be set. If this is not set, the the default is ``/install``

43
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/hierarchy_support.rst Normal file
View File

@@ -0,0 +1,43 @@
Hierarchy Support
-----------------
In the ``statelite`` environment, the service node needs to provide NFS service for the compute node with ``statelite``, the service nodes must to be setup with diskfull installation.
Setup the diskfull service node
```````````````````````````````
#. Setup one diskfull service node at first.
#. Since statelite is a kind of NFS-hybrid method, you should remove the installloc attribute in the site table. This makes sure that the service node does not mount the ``/install`` directory from the management node on the service node.
Generate the statelite image
````````````````````````````
To generate the statelite image for your own profile follow instructions in :doc:`Customize your statelite osimage <./provision_statelite>`.
``NOTE``: if the NFS directories defined in the litetree table are on the service node, it is better to setup the NFS directories in the service node following the chapter.
Sync the ``/install`` directory
```````````````````````````````
The command prsync is used to sync the ``/install`` directory to the service nodes.
Run the following: ::
cd /
prsync install <sn>:/
``<sn>`` is the hostname of the service node you defined.
Since the ``prsync`` command will sync all the contents in the ``/install`` directory to the service nodes, the first time will take a long time. But after the first time, it will take very short time to sync.
``NOTE``: if you make any changes in the ``/install`` directory on the management node, and the changes can affect the statelite image, you need to sync the ``/install`` directory to the service node again.
Set the boot state to statelite
```````````````````````````````
You can now deploy the node: ::
rinstall <noderange> osimage=rhel5.3-x86_64-statelite-compute
This will create the necessary files in ``/tftpboot`` for the node to boot correctly.

45
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/index.rst Normal file
View File

@@ -0,0 +1,45 @@
Statelite Installation
======================
**Overview**
This document details the design and setup for the statelite solution of xCAT. **Statelite** is an intermediate mode between **diskful** and **diskless**.
Statelite provides two kinds of efficient and flexible solutions, most of the OS image can be NFS mounted read-only, or the OS image can be in the ramdisk with tmpfs type. Different from the stateless solution, statelite provides a configurable list of directories and files that can be read-write. These read-write directories and files can be configured to either persist or not persist across reboots.
**Solutions**
There are two solutions: ``NFSROOT-based`` and ``RAMdisk-based``.
#. NFSROOT-based(default):
#. rootfstype in the osimage xCAT data objects is left as blank, or set to ``nfs``, the ``NFSROOT-base`` statelite solution will be enabled.
#. the ROOTFS is NFS mounted read-only.
#. RAMdisk-based:
#. rootfstype in the osimage xCAT data objects is set to ``ramdisk``.
#. one image file will be downloaded when the node is booting up, and the file will be extracted to the ramdisk, and used as the ROOTFS.
**Advantages**
``Statelite`` offers the following advantages over xCAT's stateless (RAMdisk) implementation:
#. Some files can be made persistent over reboot. This is useful for license files or database servers where some state is needed. However, you still get the advantage of only having to manage a single image.
#. Changes to hundreds of machines can take place instantly, and automatically, by updating one main image. In most cases, machines do not need to reboot for these changes to take affect. This is only for the ``NFSROOT-based`` solution.
#. Ease of administration by being able to lock down an image. Many parts of the image can be read-only, so no modifications can transpire without updating the central image.
#. Files can be managed in a hierarchical manner. For example: Suppose you have a machine that is in one lab in Tokyo and another in London. You could set table values for those machines in the xCAT database to allow machines to sync from different places based on their attributes. This allows you to have one base image with multiple sources of file overlay.
#. Ideal for virtualization. In a virtual environment, you may not want a disk image (neither stateless nor stateful) on every virtual node as it consumes memory and disk. Virtualizing with the statelite approach allows for images to be smaller, easier to manage, use less disk, less memory, and more flexible.
**Disadvantages**
However, there're still several disadvantages, especially for the ``NFSROOT-based`` solution.
#. NFS Root requires more network traffic to run as the majority of the disk image runs over NFS. This may depend on your workload, but can be minimized. Since the bulk of the image is read-only, NFS caching on the server helps minimize the disk access on the server, and NFS caching on the client helps reduce the network traffic.
#. NFS Root can be complex to set up. As more files are created in different places, there are greater chances for failures. This flexibility is also one of the great virtues of Statelite. The image can work in nearly any environment.
.. toctree::
:maxdepth: 2
config_statelite.rst
provision_statelite.rst
hierarchy_support.rst
advanced_features.rst

257
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/provision_statelite.rst Normal file
View File

@@ -0,0 +1,257 @@
Provision statelite
===================
Show current provisioning method
--------------------------------
To determine the current provisioning method of your node, execute: ::
lsdef <noderange> -i provmethod
``Note``: syncfiles is not currently supported for statelite nodes.
Generate default statelite image from distoro media
---------------------------------------------------
In this example, we are going to create a new compute node osimage for ``rhels7.3`` on ``ppc64le``. We will set up a test directory structure that we can use to create our image. Later we can just move that into production.
Use the copycds command to copy the appropriate iso image into the ``/install`` directory for xCAT. The copycds commands will copy the contents to ``/install/rhels7.3/<arch>``. For example: ::
copycds RHEL-7.3-20161019.0-Server-ppc64le-dvd1.iso
The contents are copied into ``/install/rhels7.3/ppc64le/``
The configuration files pointed to by the attributes are the defaults shipped with xCAT. We will want to copy them to the ``/install`` directory, in our example the ``/install/test`` directory and modify them as needed.
Statelite Directory Structure
-----------------------------
Each statelite image will have the following directories: ::
/.statelite/tmpfs/
/.default/
/etc/init.d/statelite
All files with link options, which are symbolic links, will link to ``/.statelite/tmpfs``.
tmpfs files that are persistent link to ``/.statelite/persistent/<nodename>/``, ``/.statelite/persistent/<nodename>`` is the directory where the node's individual storage will be mounted to.
``/.default`` is where default files will be copied to from the image to tmpfs if the files are not found in the litetree hierarchy.
Customize your statelite osimage
--------------------------------
Create the osimage definition
`````````````````````````````
Setup your osimage/linuximage tables with new test image name, osvers,osarch, and paths to all the files for building and installing the node. So using the above generated ``rhels7.3-ppc64le-statelite-compute`` as an example, I am going to create my own image. The value for the provisioning method attribute is osimage in my example.::
mkdef rhels7.3-custom-statelite -u profile=compute provmethod=statelite
Check your setup: ::
lsdef -t osimage rhels7.3-custom-statelite
Customize the paths to your ``pkglist``, ``syncfile``, etc to the osimage definition, that you require. ``Note``, if you modify the files on the ``/opt/xcat/share/...`` path then copy to the appropriate ``/install/custom/...`` path. Remember all files must be under ``/install`` if using hierarchy (service nodes).
Copy the sample ``*list`` files and modify as needed: ::
mkdir -p /install/test/netboot/rh
cp -p /opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.pkglist \
/install/test/netboot/rh/compute.rhels7.ppc64le.pkglist
cp -p /opt/xcat/share/xcat/netboot/rh/compute.exlist \
/install/test/netboot/rh/compute.exlist
chdef -t osimage -o rhels7.3-custom-statelite \
pkgdir=/install/rhels7.3/ppc64le \
pkglist=/install/test/netboot/rh/compute.rhels7.ppc64le.pkglist \
exlist=/install/test/netboot/rh/compute.exlist \
rootimgdir=/install/test/netboot/rh/ppc64le/compute
Setup pkglists
``````````````
In the above example, you have defined your pkglist to be in ``/install/test/netboot/rh/compute.rhels7.ppc64le.pkglist``.
Edit ``compute.rhels7.ppc64le.pkglist`` and ``compute.exlist`` as needed. ::
vi /install/test/netboot/rh/compute.rhels7.ppc64le.pkglist
vi /install/test/netboot/rh/compute.exlist
Make sure nothing is excluded in compute.exlist that you need.
Install other specific packages
```````````````````````````````
Make the directory to hold additional rpms to install on the compute node. ::
mkdir -p /install/test/post/otherpkgs/rh/ppc64le
Now copy all the additional OS rpms you want to install into ``/install/test/post/otherpkgs/rh/ppc64le``.
At first you need to create one text file which contains the complete list of files to include in the repository. The name of the text file is rpms.list and must be in ``/install/test/post/otherpkgs/rh/ppc64le`` directory. Create rpms.list: ::
cd /install/test/post/otherpkgs/rh/ppc64le
ls *.rpm > rpms.list
Then, run the following command to create the repodata for the newly-added packages: ::
createrepo -i rpms.list /install/test/post/otherpkgs/rh/ppc64le
The ``createrepo`` command with -i rpms.list option will create the repository for the rpm packages listed in the rpms.list file. It won't destroy or affect the rpm packages that are in the same directory, but have been included into another repository.
Or, if you create a sub-directory to contain the rpm packages, for example, named other in ``/install/test/post/otherpkgs/rh/ppc64le``. Run the following command to create repodata for the directory ``/install/test/post/otherpkgs/rh/ppc64le``. ::
createrepo /install/post/otherpkgs/<os>/<arch>/**other**
``Note``: Replace other with your real directory name.
Define the location of of your otherpkgs in your osimage: ::
chdef -t osimage -o rhels7.3-custom-statelite \
otherpkgdir=/install/test/post/otherpkgs/rh/ppc64le \
otherpkglist=/install/test/netboot/rh/compute.otherpkgs.pkglist
There are examples under ``/opt/xcat/share/xcat/netboot/<platform>`` of typical ``*otherpkgs.pkglist`` files that can used as an example of the format.
Set up Post scripts for statelite
`````````````````````````````````
The rules to create post install scripts for statelite image is the same as the rules for stateless/diskless install images.
There're two kinds of postscripts for statelite (also for stateless/diskless).
The first kind of postscript is executed at genimage time, it is executed again the image itself on the MN . It was setup in The postinstall file section before the image was generated.
The second kind of postscript is the script that runs on the node during node deployment time. During init.d timeframe, ``/etc/init.d/gettyset`` calls ``/opt/xcat/xcatdsklspost`` that is in the image. This script uses wget to get all the postscripts under ``mn:/install/postscripts`` and copy them to the ``/xcatpost`` directory on the node. It uses openssl or stunnel to connect to the xcatd on the mn to get all the postscript names for the node from the postscripts table. It then runs the postscripts for the node.
Setting up postinstall files (optional)
```````````````````````````````````````
Using postinstall files is optional. There are some examples shipped in ``/opt/xcat/share/xcat/netboot/<platform>``.
If you define a postinstall file to be used by genimage, then ::
chdef -t osimage -o rhels7.3-custom-statelite postinstall=<your postinstall file path>.
Generate the image
------------------
Run the following command to generate the image based on your osimage named ``rhels7.3-custom-statelite``. Adjust your genimage parameters to your architecture and network settings. See man genimage. ::
genimage rhels7.3-custom-statelite
The genimage will create a default ``/etc/fstab`` in the image, if you want to change the defaults, on the management node, edit fstab in the image: ::
cd /install/netboot/rhels7/ppc64le/compute/rootimg/etc
cp fstab fstab.ORIG
vi fstab
``Note``: adding ``/tmp`` and ``/var/tmp`` to ``/etc/fstab`` is optional, most installations can simply use ``/``. It was documented her to show that you can restrict the size of filesystems, if you need to. The indicated values are just and example, and you may need much bigger filessystems, if running applications like OpenMPI.
Pack the image
--------------
Execute liteimg ::
liteimg rhels7.3-custom-statelite
Boot the statelite node
-----------------------
Execute ``rinstall`` ::
rinstall node1 osimage=rhels7.3-custom-statelite
Switch to the RAMdisk based solution
------------------------------------
It is optional, if you want to use RAMdisk-based solution, follow this section.
Set rootfstype
``````````````
If you want the node to boot with a RAMdisk-based image instead of the NFS-base image, set the rootfstype attribute for the osimage to ``ramdisk``. For example: ::
chdef -t osimage -o rhels7.3-custom-statelite rootfstype=ramdisk
Run liteimg command
```````````````````
The ``liteimg`` command will modify your statelite image (the image that ``genimage`` just created) by creating a series of links. Once you are satisfied with your image contains what you want it to, run ``liteimg <osimagename>``: ::
liteimg rhels7.3-custom-statelite
For files with link options, the ``liteimg`` command creates two levels of indirection, so that files can be modified while in their image state as well as during runtime. For example, a file like ``$imageroot/etc/ntp.conf`` with link option in the litefile table, will have the following operations done to it:
In our case ``$imageroot`` is ``/install/netboot/rhels5.3/x86_64/compute/rootimg``
The ``liteimg`` script, for example, does the following to create the two levels of indirection. ::
mkdir -p $imageroot/.default/etc
mkdir -p $imageroot/.statelite/tmpfs/etc
mv $imgroot/etc/ntp.conf $imgroot/.default/etc
cd $imgroot/.statelite/tmpfs/etc
ln -sf ../../../.default/etc/ntp.conf .
cd $imgroot/etc
ln -sf ../.statelite/tmpfs/etc/ntp.conf .
When finished, the original file will reside in ``$imgroot/.default/etc/ntp.conf``. ``$imgroot/etc/ntp.conf`` will link to ``$imgroot/.statelite/tmpfs/etc/ntp.conf`` which will in turn link to ``$imgroot/.default/etc/ntp.conf``.
But for files without link options, the ``liteimg`` command only creates clones in ``$imageroot/.default/`` directory, when the node is booting up, the mount command with ``--bind`` option will get the corresponding files from the ``litetree`` places or ``.default`` directory to the sysroot directory.
``Note``: If you make any changes to your litefile table after running ``liteimg`` then you will need to rerun ``liteimg`` again. This is because files and directories need to have the two levels of redirects created.
Boot the statelite node
```````````````````````
Make sure you have set up all the attributes in your node definitions correctly following the node installation instructions corresponding to your hardware:
You can now deploy the node by running the following commmands: ::
rinstall <noderange>
You can then use ``rcons`` or ``wcons`` to watch the node boot up.
Adding/updating software and files for the running nodes
--------------------------------------------------------
Make changes to the files which configured in the litefile table
````````````````````````````````````````````````````````````````
During the preparation or booting of node against statelite mode, there are specific processes to handle the files which configured in the litefile table. The following operations need to be done after made changes to the statelite files.
#. Run ``liteimg`` against the osimage and reboot the node : Added, removed or changed the entries in the litefile table.
#. Reboot the node :
* Changed the location directory in the litetree table.
* Changed the location directory in the statelite table.
* Changed, removed the original files in the location of litetree or statelite table.
``Note``: Thing should not do:
* When there are node running on the nfs-based statelite osimage, do not run the packimage against this osimage.
Make changes to the common files
````````````````````````````````
Because most of system files for the nodes are NFS mounted on the Management Node with read-only option, installing or updating software and files should be done to the image. The image is located under ``/install/netboot/<os>/<arch>/<profile>/rootimg`` directory.
To install or update an rpm, do the following:
* Install the rpm package into rootimg ::
rpm --root /install/netboot/<os>/<arch>/<profile>/rootimg -ivh rpm_name
* Restart the software application on the nodes ::
xdsh <noderange> <restart_this_software_command>
It is recommended to follow the section (Adding third party softeware) to add the new rpm to the otherpkgs.pkglist file, so that the rpm will get installed into the new image next time the image is rebuilt.
``Note``: The newly added rpms are not shown when running ``rpm -qa`` on the nodes although the rpm is installed. It will shown next time the node is rebooted.
To create or update a file for the nodes, just modify the file in the image and restart any application that uses the file.
For the ramdisk-based node, you need to reboot the node to take the changes.

9
docs/source/guides/admin-guides/references/man1/getadapter.1.rst
View File

@@ -33,12 +33,11 @@ Traditionally, network interfaces in Linux are enumerated as eth[0123...], but t
\ **getadapter**\ use genesis to collect network adapters information, so that mean it need to restart the target node.
\ **getadapter**\ follows below scheme:
\ **getadapter**\ For each node within the <noderange>, follows below scheme:
If the target node is scaned for the first time, \ **getadapter**\ will trigger genesis to collect information then save the information at local.
If the target node has ever been scaned, i.e. this node has network device information in local, \ **getadapter**\ use the local information first.
If user doesn't want to use local information, can use \ **-f**\ option to force to trigger new round scan process.
if part nodes of \ *noderange*\ don't have network device information in local and the rest have, \ **getadapter**\ only trigger real scan process for these nodes which don't have local information, the nodes have network device information in local, \ **getadapter**\ still use the local information first.
If the target node is scaned for the first time, \ **getadapter**\ will trigger genesis to collect information then save the information at the \ **nicsadapter**\ column of nics table.
If the target node has ever been scaned, \ **getadapter**\ will use the information from nics table first.
If user hopes to scan the adapter information for the node but these information already exist, \ **-f**\ option can be used to start rescan process.
\ **getadapter**\ tries to collect more information for the target network device, but doesn't guarantee collect same much information for every network device.

4
docs/source/guides/admin-guides/references/man1/pping.1.rst
View File

@@ -25,7 +25,7 @@ DESCRIPTION
\ **pping**\ is a utility used to ping a list of nodes in parallel.
\ **pping**\ will return an unsorted list of nodes with a ping or noping status.
\ **pping**\ front-ends nmap or fping if available.
\ **pping**\ front-ends \ **nmap**\ or \ **fping**\ if available.
This command does not support the xcatd client/server communication. It must be run on the management node.
@@ -48,7 +48,7 @@ OPTIONS
\ **-f | -**\ **-use_fping**\
Use fping instead of nmap
Use \ **fping**\ instead of \ **nmap**\

13
docs/source/guides/admin-guides/references/man1/prsync.1.rst
View File

@@ -21,7 +21,7 @@ prsync - parallel rsync
\ **prsync**\ \ *filename*\ [\ *filename*\ \ *...*\ ] \ *noderange:destinationdirectory*\
\ **prsync**\ [\ **-o**\ \ *rsync options*\ ] [\ **-f**\ \ *fanout*\ ] [\ *filename*\ \ *filename*\ \ *...*\ ] [\ *directory*\ \ *directory*\ \ *...*\ ]
\ **prsync**\ [\ **-o**\ \ *rsyncopts*\ ] [\ **-f**\ \ *fanout*\ ] [\ *filename*\ \ *filename*\ \ *...*\ ] [\ *directory*\ \ *directory*\ \ *...*\ ]
\ *noderange:destinationdirectory*\
\ **prsync**\ {\ **-h | -**\ **-help | -v | -**\ **-version**\ }
@@ -32,11 +32,9 @@ prsync - parallel rsync
*******************
\ **prsync**\ is a front-end to rsync for a single or range of nodes and/or
groups in parallel.
\ **prsync**\ is a front-end to rsync for a single or range of nodes and/or groups in parallel.
Note: this command does not support the xcatd client/server communication and therefore must be run on the management node. It does not support hierarchy, use xdcp -F to run rsync from the
management node to the compute node via a service node
Note: this command does not support the xcatd client/server communication and therefore must be run on the management node. It does not support hierarchy, use \ **xdcp -F**\ to run rsync from the management node to the compute node via a service node
\ **prsync**\ is NOT multicast, but is parallel unicasts.
@@ -47,7 +45,7 @@ management node to the compute node via a service node
\ *rsyncopts*\
\ **-o**\ \ *rsyncopts*\
rsync options. See \ **rsync(1)**\ .
@@ -55,8 +53,7 @@ management node to the compute node via a service node
\ **-f**\ \ *fanout*\
Specifies a fanout value for the maximum number of concur-
rently executing remote shell processes.
Specifies a fanout value for the maximum number of concurrently executing remote shell processes.

28
docs/source/guides/admin-guides/references/man1/rflash.1.rst
View File

@@ -11,7 +11,7 @@ Name
****
\ **rflash**\ - Performs Licensed Internal Code (LIC) update support for HMC-attached POWER5 and POWER6 Systems, and POWER7 systems using Direct FSP management. rflash is also able to update firmware for NextScale Fan Power Controllers (FPC).
\ **rflash**\ - Performs Licensed Internal Code (LIC) update support for HMC-attached POWER5 and POWER6 Systems, and POWER7 systems using Direct FSP management. \ **rflash**\ is also able to update firmware for NextScale Fan Power Controllers (FPC).
****************
@@ -25,7 +25,7 @@ PPC (with HMC) specific:
========================
\ **rflash**\ \ *noderange*\ \ **-p**\ \ *directory*\ {\ **-**\ **-activate**\ \ **concurrent | disruptive**\ } [\ **-V | -**\ **-verbose**\ ]
\ **rflash**\ \ *noderange*\ \ **-p**\ \ *directory*\ [\ **-**\ **-activate**\ {\ **concurrent | disruptive**\ }] [\ **-V | -**\ **-verbose**\ ]
\ **rflash**\ \ *noderange*\ {\ **-**\ **-commit | -**\ **-recover**\ } [\ **-V | -**\ **-verbose**\ ]
@@ -34,7 +34,7 @@ PPC (without HMC, using Direct FSP Management) specific:
========================================================
\ **rflash**\ \ *noderange*\ \ **-p**\ \ *directory*\ \ **-**\ **-activate**\ \ **disruptive | deferred**\ [\ **-d**\ \ *data_directory*\ ]
\ **rflash**\ \ *noderange*\ \ **-p**\ \ *directory*\ [\ **-**\ **-activate**\ {\ **disruptive | deferred**\ }] [\ **-d**\ \ *data_directory*\ ]
\ **rflash**\ \ *noderange*\ {\ **-**\ **-commit | -**\ **-recover**\ }
@@ -43,14 +43,14 @@ NeXtScale FPC specific:
=======================
\ **rflash**\ \ *noderange*\ \ *http directory*\
\ **rflash**\ \ *noderange*\ \ *http_directory*\
OpenPOWER BMC specific:
=======================
\ **rflash**\ \ *noderange*\ \ *hpm file path*\ [\ **-c | -**\ **-check**\ ] [\ **-V**\ ]
\ **rflash**\ \ *noderange*\ \ *hpm_file_path*\ [\ **-c | -**\ **-check**\ ] [\ **-**\ **-retry=**\ \ *count*\ ] [\ **-V**\ ]
@@ -59,13 +59,13 @@ OpenPOWER BMC specific:
*******************
\ **rflash**\ The \ **rflash**\ command initiates Firmware updates on supported xCAT nodes. Licensed Internal Code (also known as microcode) updates are performed on supported HMC-attached POWER5 and POWER6 pSeries nodes, and POWER7 systems using Direct FSP management.
The \ **rflash**\ command initiates Firmware updates on supported xCAT nodes. Licensed Internal Code (also known as microcode) updates are performed on supported HMC-attached POWER5 and POWER6 pSeries nodes, and POWER7 systems using Direct FSP management.
The command scans the specified directory structure for Firmware update package files applicable to the given nodes and components. And then it will \ **automatically**\ select the \ **latest**\ version for the upgrade. The firmware update files include the Microcode update package and associated XML file. They can be downloaded from the IBM Web site: \ *http://www-933.ibm.com/support/fixcentral/*\ .
The POWER5 and POWER6 systems contain several components that use Licensed Internal Code. The \ **rflash**\ command supports two of these components: the managed system (also known as the Central Electronics Complex, or CEC) and the power subsystem (also known as the Bulk Power Assembly (BPA) or Bulk Power Controller (BPC)). Some POWER5 managed systems can be attached to a power subsystem. These power subsystems can support multiple managed systems. When the \ **rflash**\ command is invoked, xCAT will determine the managed system or power subsystem associated with that CEC and perform the update.
The \ **noderange**\ can be an CEC or CEC list, a Lpar or Lpar list and a Frame or Frame list. But CEC (or Lpar) and Frame \ **can't**\ be used at the same time. When the \ *noderange*\ is an CEC or CEC list, \ **rflash**\ will upgrade the firmware of the CEC or CECs in the cec list. If \ *noderange*\ is a Lpar or Lpar list, \ **rflash**\ will update Licensed Internal Code (LIC) on HMC-attached POWER5 and POWER6 pSeries nodes, and POWER7 systems using Direct FSP management. If \ *noderange*\ is a Frame or Frame list, \ **rflash**\ will update Licensed Internal Code (LIC) of the power subsystem on HMC-attached POWER5 and POWER6 pSeries nodes. The \ *noderange*\ can also be the specified node groups. You can specify a comma or space-separated list of node group ranges. See the \ *noderange*\ man page for detailed usage information.
The \ *noderange*\ can be an CEC or CEC list, a Lpar or Lpar list and a Frame or Frame list. But CEC (or Lpar) and Frame \ **can't**\ be used at the same time. When the \ *noderange*\ is an CEC or CEC list, \ **rflash**\ will upgrade the firmware of the CEC or CECs in the cec list. If \ *noderange*\ is a Lpar or Lpar list, \ **rflash**\ will update Licensed Internal Code (LIC) on HMC-attached POWER5 and POWER6 pSeries nodes, and POWER7 systems using Direct FSP management. If \ *noderange*\ is a Frame or Frame list, \ **rflash**\ will update Licensed Internal Code (LIC) of the power subsystem on HMC-attached POWER5 and POWER6 pSeries nodes. The \ *noderange*\ can also be the specified node groups. You can specify a comma or space-separated list of node group ranges. See the \ *noderange*\ man page for detailed usage information.
The command will update firmware for NeXtScale FPC when given an FPC node and the http information needed to access the firmware.
@@ -102,11 +102,11 @@ In currently Direct FSP/BPA Management, our \ **rflash**\ doesn't support \ **c
The \ **deferred**\ option will load the new firmware into the T (temp) side, but will not activate it like the disruptive firmware. The customer will continue to run the Frames and CECs working with the P (perm) side and can wait for a maintenance window where they can activate and boot the Frame/CECs with new firmware levels. Refer to the doc to get more details: XCAT_Power_775_Hardware_Management
In Direct FSP/BPA Management, there is -d <data_directory> option. The default value is /tmp. When do firmware update, rflash will put some related data from rpm packages in <data_directory> directory, so the execution of rflash will require available disk space in <data_directory> for the command to properly execute:
In Direct FSP/BPA Management, there is \ **-d**\ \ *data_directory*\ option. The default value is /tmp. When doing firmware update, \ **rflash**\ will put some related data from rpm packages in <data_directory> directory, so the execution of \ **rflash**\ will require available disk space in <data_directory> for the command to properly execute:
For one GFW rpm package and one power code rpm package , if the GFW rpm package size is gfw_rpmsize, and the Power code rpm package size is power_rpmsize, it requires that the available disk space should be more than: 1.5\*gfw_rpmsize + 1.5\*power_rpmsize
For Power 775, the rflash command takes effect on the primary and secondary FSPs or BPAs almost in parallel.
For Power 775, the \ **rflash**\ command takes effect on the primary and secondary FSPs or BPAs almost in parallel.
For more details about the Firmware Update using Direct FSP/BPA Management, refer to: XCAT_Power_775_Hardware_Management#Updating_the_BPA_and_FSP_firmware_using_xCAT_DFM
@@ -156,7 +156,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node
\ **-**\ **-activate**\ \ **concurrent**\ | \ **disruptive**\
\ **-**\ **-activate**\ {\ **concurrent**\ | \ **disruptive**\ }
Must be specified to activate the new Licensed Internal Code. The "disruptive" option will cause the target systems to be recycled. Without this flag, LIC updates will be installed only, not activated.
@@ -174,6 +174,12 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node
\ **-**\ **-retry=**\ \ *count*\
Specify number of times to retry the update if failure is detected. Default value is 2. Value of 0 can be used to indicate no retries.
\ **-v|-**\ **-version**\
Displays the command's version.
@@ -251,7 +257,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node
rflash fs3 /firmware/8335_810.1543.20151021b_update.hpm
Print verbose message to rflash log file per node when updading firmware:
Print verbose message to rflash log file (/var/log/xcat/rflash/fs3.log) when updading firmware:
.. code-block:: perl

9
docs/source/guides/admin-guides/references/man1/rinv.1.rst
View File

@@ -25,7 +25,7 @@ BMC/MPA specific:
=================
\ **rinv**\ \ *noderange*\ {\ **pci | model | serial | asset | vpd | mprom | deviceid | guid | firm | diag | bios | mparom | mac | all**\ }
\ **rinv**\ \ *noderange*\ {\ **pci | model | serial | asset | vpd | mprom | deviceid | guid | firm | diag | dimm | bios | mparom | mac | all**\ }
OpenPOWER server specific:
@@ -65,6 +65,13 @@ VMware specific:
\ **rinv**\ \ *noderange*\ [\ **-t**\ ]
pdu specific:
=============
\ **rinv**\ \ *noderange*\
zVM specific:
=============

29
docs/source/guides/admin-guides/references/man1/rmdef.1.rst
View File

@@ -22,7 +22,7 @@ SYNOPSIS
\ **rmdef**\ [\ **-h | -**\ **-help**\ ] [\ **-t**\ \ *object-types*\ ]
\ **rmdef**\ [\ **-V | -**\ **-verbose**\ ] [\ **-a | -**\ **-all**\ ] [\ **-t**\ \ *object-types*\ ] [\ **-o**\ \ *object-names*\ ]
[\ **-f | -**\ **-force**\ ] [\ *noderange*\ ]
[\ **-f | -**\ **-force**\ ] [\ **-C | -**\ **-cleanup**\ ] [\ *noderange*\ ]
***********
@@ -41,17 +41,26 @@ OPTIONS
\ **-a|-**\ **-all**\
Clear the whole xCAT database. A backup of the xCAT definitions should be saved before using this option. Once all the data is removed the xCAT daemon will no longer work. Most xCAT commands will fail.
In order to use xCAT commands again, you have two options. You can restore your database from your backup by switching to bypass mode, and running the restorexCATdb command.
You switch to bypass mode by setting the XCATBYPASS environmant variable. (ex. "export XCATBYPASS=yes")
A second option is to run xcatconfig -d. This will restore the initial setup of the database as when xCAT was initially installed.
You can then restart xcatd and run xCAT commands.
Clear the whole xCAT database. A backup of the xCAT definitions should be saved before using this option as the xCAT daemons will no longer work once cleared.
To restore:
1. \ **export XCATBYPASS=1**\ and run the \ **restorexCATdb**\ command.
or
2. Run \ **xcatconfig -d**\ which initializes the database the same as when xCAT was installed.
\ **-f|-**\ **-force**\
Use this with the all option as an extra indicator that ALL definitions are to be removed.
Use this with the \ **-**\ **-all**\ option as an extra indicator that ALL definitions are to be removed.
@@ -79,6 +88,12 @@ OPTIONS
\ **-C|-**\ **-cleanup**\
Perform additional cleanup by running \ **nodeset offline**\ on the objects specified in the \ *noderange*\ .
\ **-V|-**\ **-verbose**\
Verbose mode.

16
docs/source/guides/admin-guides/references/man1/rpower.1.rst
View File

@@ -29,6 +29,15 @@ BMC (using IPMI) specific:
\ **rpower**\ \ *noderange*\ [\ **on | off | softoff | reset | boot | stat | state | status | wake | suspend**\ [\ **-w**\ \ *timeout*\ ] [\ **-o**\ ] [\ **-r**\ ]]
\ **rpower**\ \ *noderange*\ [\ **pduon | pduoff | pdustat | pdureset**\ ]
OpenBMC specific:
=================
\ **rpower**\ \ *noderange*\ [\ **off | on | reset | boot | stat | state | status**\ ]
PPC (with IVM or HMC) specific:
===============================
@@ -102,6 +111,13 @@ docker specific:
\ **rpower**\ \ *noderange*\ [\ **start | stop | restart | pause | unpause | state**\ ]
pdu specific:
=============
\ **rpower**\ \ *noderange*\ [\ **stat | off | on | reset**\ ]
***********
DESCRIPTION

6
docs/source/guides/admin-guides/references/man1/rvitals.1.rst
View File

@@ -142,14 +142,16 @@ Processor for a single or range of nodes and groups.
\ **powertime**\
Retrieves total power uptime. This value only increases, unless
the Service Processor flash gets updated.
the Service Processor flash gets updated. This option is not valid
for x86 architecture systems.
\ **reboot**\
Retrieves total number of reboots. This value only increases,
unless the Service Processor flash gets updated.
unless the Service Processor flash gets updated. This option
is not valid for x86 architecture systems.

35
docs/source/guides/admin-guides/references/man1/xdsh.1.rst
View File

@@ -264,7 +264,7 @@ running commands, are terminated (SIGTERM).
xdsh will chroot (xcatchroot for AIX) to this path and run the xdsh command against the
install image. No other xdsh flags, environment variables apply with
this input. A noderange is not accepted. Only runs on the local host,
normally the Management Node. The command you run must not prompt for input, the prompt will not be returned to you, and it will appear that xdsh hangs.
normally the Management Node. The command you run must not prompt for input, the prompt will not be returned to you, and it will appear that \ **xdsh**\ hangs.
@@ -381,8 +381,8 @@ running commands, are terminated (SIGTERM).
displays an error and terminates execution for the remote
targets that failed to respond. If \ *timeout*\ is not specified,
\ **xdsh**\ waits indefinitely to continue processing output from
all remote targets. The exception is the -K flag which defaults
to 10 seconds.
all remote targets. The exception is the \ **-K**\ flag which defaults
to 10 seconds.
@@ -512,23 +512,28 @@ running commands, are terminated (SIGTERM).
If \ **DSH_REMOTE_PASSWORD**\ is set to the password of the
userid (usually root) that will ssh to the node, then when
you use the -K flag, you will not be prompted for a password.
you use the \ **-K**\ flag, you will not be prompted for a password.
\ **DSH_SYNTAX**\
Specifies the shell syntax to use on remote targets; \ **ksh**\ or
\ **csh**\ . If not specified, the \ **ksh**\ syntax is assumed. This
\ **csh**\ . If not specified, the \ **ksh**\ syntax is assumed. This
variable is overridden by the \ **-S**\ flag.
\ **DSH_TIMEOUT**\
Specifies the time, in seconds, to wait for output from
each remote target. This variable is overridden by the \ **-t**\
flag.
Specifies the time, in seconds, to wait for output from
each remote target. This variable is overridden by the \ **-t**\ flag.
\ **DSH_VERIFY**\
Verifies each target before executing any remote commands on the target. If a target is not responding, execution of remote commands for the target is canceled. This variable is overridden by the \ **-v**\ flag.
@@ -538,10 +543,10 @@ running commands, are terminated (SIGTERM).
**********************************
To provide backward compatibility for scripts written using dsh in
To provide backward compatibility for scripts written using \ **dsh**\ in
AIX and CSM, a tool has been provided \ **groupfiles4dsh**\ ,
which will build node group files from the
xCAT database that can be used by dsh. See \ **man groupfiles4dsh**\ .
xCAT database that can be used by \ **dsh**\ . See \ **man groupfiles4dsh**\ .
****************
@@ -567,7 +572,7 @@ userdefined.
*******************
The dsh command exit code is 0 if the command executed without errors and all remote shell commands finished with exit codes of 0. If internal dsh errors occur or the remote shell commands do not complete successfully, the dsh command exit value is greater than 0. The exit value is increased by 1 for each successive instance of an unsuccessful remote command execution. If the remotely issued command is run in the background, the exit code of the remotely issued command is 0.
The \ **xdsh**\ command exit code is 0 if the command executed without errors and all remote shell commands finished with exit codes of 0. If internal dsh errors occur or the remote shell commands do not complete successfully, the dsh command exit value is greater than 0. The exit value is increased by 1 for each successive instance of an unsuccessful remote command execution. If the remotely issued command is run in the background, the exit code of the remotely issued command is 0.
****************
@@ -663,7 +668,7 @@ on the service node fedora9 diskless image, enter:
To define the QLogic IB switch as a node and to set up the SSH keys for IB switch
\ **qswitch**\ with device configuration file
\ **/var/opt/xcat/IBSwitch/Qlogic/config**\ and user name \ **username**\ , Enter
\ **/var/opt/xcat/IBSwitch/Qlogic/config**\ and user name \ **username**\ , enter
.. code-block:: perl
@@ -675,7 +680,7 @@ on the service node fedora9 diskless image, enter:
10. To define the Management Node in the database so you can use xdsh, Enter
10. To define the Management Node in the database so you can use \ **xdsh**\ , enter
.. code-block:: perl
@@ -686,7 +691,7 @@ on the service node fedora9 diskless image, enter:
11. To define the Mellanox switch as a node and run a command to show the ssh keys.
\ **mswitch**\ with and user name \ **username**\ , Enter
\ **mswitch**\ with and user name \ **username**\ , enter
.. code-block:: perl
@@ -724,7 +729,7 @@ on the service node fedora9 diskless image, enter:
13.
To run xdsh with the non-root userid "user1" that has been setup as an xCAT userid and with sudo on node1 and node2 to run as root, do the following, see xCAT doc on Granting_Users_xCAT_privileges:
To run \ **xdsh**\ with the non-root userid "user1" that has been setup as an xCAT userid and with sudo on node1 and node2 to run as root, do the following, see xCAT doc on Granting_Users_xCAT_privileges:
.. code-block:: perl

12
docs/source/guides/admin-guides/references/man1/xdshbak.1.rst
View File

@@ -19,7 +19,7 @@ NAME
****************
\ **xdshbak**\ [\ **-c**\ | \ **-x**\ | \ **-h**\ | \ **-q**\ ]
\ **xdshbak**\ [\ **-c**\ | \ **-x**\ [ \ **-b**\ ] | \ **-h**\ | \ **-q**\ ]
***********
@@ -93,6 +93,9 @@ the output by hostname for easier viewing:
.
If the \ **-b**\ flag is specified in addition to \ **-x**\ , the hostname at the beginning
of each line is stripped.
Standard Error
==============
@@ -109,6 +112,13 @@ OPTIONS
\ **-b**\
Strip the host prefix from the beginning of the lines. This only
works with the \ **-x**\ option.
\ **-c**\
If the output from multiple nodes is identical it will be collapsed

2
docs/source/guides/admin-guides/references/man5/nodehm.5.rst
View File

@@ -50,7 +50,7 @@ nodehm Attributes:
\ **mgt**\
The method to use to do general hardware management of the node. This attribute is used as the default if power or getmac is not set. Valid values: ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm. See the power attribute for more details.
The method to use to do general hardware management of the node. This attribute is used as the default if power or getmac is not set. Valid values: openbmc, ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm. See the power attribute for more details.

82
docs/source/guides/admin-guides/references/man5/openbmc.5.rst Normal file
View File

@@ -0,0 +1,82 @@
#########
openbmc.5
#########
.. highlight:: perl
****
NAME
****
\ **openbmc**\ - a table in the xCAT database.
********
SYNOPSIS
********
\ **openbmc Attributes:**\ \ *node*\ , \ *bmc*\ , \ *username*\ , \ *password*\ , \ *comments*\ , \ *disable*\
***********
DESCRIPTION
***********
Setting for nodes that are controlled by an on-board OpenBmc.
*******************
openbmc Attributes:
*******************
\ **node**\
The node name or group name.
\ **bmc**\
The hostname of the BMC adapter.
\ **username**\
The BMC userid.
\ **password**\
The BMC password.
\ **comments**\
Any user-written notes.
\ **disable**\
Set to 'yes' or '1' to comment out this row.
********
SEE ALSO
********
\ **nodels(1)**\ , \ **chtab(8)**\ , \ **tabdump(8)**\ , \ **tabedit(8)**\

4
docs/source/guides/admin-guides/references/man5/passwd.5.rst
View File

@@ -50,13 +50,13 @@ passwd Attributes:
\ **password**\
The default password for this type of component
The default password for this type of component. On Linux, a crypted form could be provided. Hashes starting with $1$, $5$ and $6$ (md5, sha256 and sha512 respectively) are supported.
\ **cryptmethod**\
Indicates the method that was used to encrypt the password attribute. On AIX systems, if a value is provided for this attribute it indicates that the password attribute is encrypted. If the cryptmethod value is not set it indicates the password is a simple string value. On Linux systems, the cryptmethod can be set to md5, sha256 or sha512. If not set, sha256 will be used as default.
Indicates the method to use to encrypt the password attribute. On AIX systems, if a value is provided for this attribute it indicates that the password attribute is encrypted. If the cryptmethod value is not set it indicates the password is a simple string value. On Linux systems, the cryptmethod can be set to md5, sha256 or sha512. If not set, sha256 will be used as default to encrypt plain-text passwords.

94
docs/source/guides/admin-guides/references/man5/pdu.5.rst Normal file
View File

@@ -0,0 +1,94 @@
#####
pdu.5
#####
.. highlight:: perl
****
NAME
****
\ **pdu**\ - a table in the xCAT database.
********
SYNOPSIS
********
\ **pdu Attributes:**\ \ *node*\ , \ *nodetype*\ , \ *outlet*\ , \ *machinetype*\ , \ *modelnum*\ , \ *serialnum*\ , \ *comments*\ , \ *disable*\
***********
DESCRIPTION
***********
Parameters to use when interrogating pdus
***************
pdu Attributes:
***************
\ **node**\
The hostname/address of the pdu to which the settings apply
\ **nodetype**\
The node type should be pdu
\ **outlet**\
The pdu outlet count
\ **machinetype**\
The pdu machine type
\ **modelnum**\
The pdu model number
\ **serialnum**\
The pdu serial number
\ **comments**\
Any user-written notes.
\ **disable**\
Set to 'yes' or '1' to comment out this row.
********
SEE ALSO
********
\ **nodels(1)**\ , \ **chtab(8)**\ , \ **tabdump(8)**\ , \ **tabedit(8)**\

70
docs/source/guides/admin-guides/references/man5/pduoutlet.5.rst Normal file
View File

@@ -0,0 +1,70 @@
###########
pduoutlet.5
###########
.. highlight:: perl
****
NAME
****
\ **pduoutlet**\ - a table in the xCAT database.
********
SYNOPSIS
********
\ **pduoutlet Attributes:**\ \ *node*\ , \ *pdu*\ , \ *comments*\ , \ *disable*\
***********
DESCRIPTION
***********
Contains list of outlet numbers on the pdu each node is connected to.
*********************
pduoutlet Attributes:
*********************
\ **node**\
The node name or group name.
\ **pdu**\
a comma-separated list of outlet number for each PDU, ex: pdu1:outlet1,pdu2:outlet1
\ **comments**\
Any user-written notes.
\ **disable**\
Set to 'yes' or '1' to comment out this row.
********
SEE ALSO
********
\ **nodels(1)**\ , \ **chtab(8)**\ , \ **tabdump(8)**\ , \ **tabedit(8)**\

22
docs/source/guides/admin-guides/references/man5/xcatdb.5.rst
View File

@@ -288,6 +288,10 @@ osimage(7)|osimage.7
pdu(7)|pdu.7
policy(7)|policy.7
@@ -561,6 +565,12 @@ notification(5)|notification.5
openbmc(5)|openbmc.5
Setting for nodes that are controlled by an on-board OpenBmc.
osdistro(5)|osdistro.5
Information about all the OS distros in the xCAT cluster
@@ -585,6 +595,18 @@ passwd(5)|passwd.5
pdu(5)|pdu.5
Parameters to use when interrogating pdus
pduoutlet(5)|pduoutlet.5
Contains list of outlet numbers on the pdu each node is connected to.
performance(5)|performance.5
Describes the system performance every interval unit of time.

58
docs/source/guides/admin-guides/references/man7/group.7.rst
View File

@@ -19,7 +19,7 @@ SYNOPSIS
********
\ **group Attributes:**\ \ *addkcmdline*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groupname*\ , \ *grouptype*\ , \ *hcp*\ , \ *height*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *membergroups*\ , \ *members*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *wherevals*\ , \ *xcatmaster*\
\ **group Attributes:**\ \ *addkcmdline*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groupname*\ , \ *grouptype*\ , \ *hcp*\ , \ *height*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *machinetype*\ , \ *membergroups*\ , \ *members*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *modelnum*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialnum*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *wherevals*\ , \ *xcatmaster*\
***********
@@ -57,16 +57,24 @@ group Attributes:
\ **bmc**\ (ipmi.bmc)
\ **bmc**\ (ipmi.bmc, openbmc.bmc)
The hostname of the BMC adapter.
or
The hostname of the BMC adapter.
\ **bmcpassword**\ (ipmi.password)
\ **bmcpassword**\ (ipmi.password, openbmc.password)
The BMC password. If not specified, the key=ipmi row in the passwd table is used as the default.
or
The BMC password.
\ **bmcport**\ (ipmi.bmcport)
@@ -115,10 +123,14 @@ group Attributes:
\ **bmcusername**\ (ipmi.username)
\ **bmcusername**\ (ipmi.username, openbmc.username)
The BMC userid. If not specified, the key=ipmi row in the passwd table is used as the default.
or
The BMC userid.
\ **bmcvlantag**\ (ipmi.taggedvlan)
@@ -435,6 +447,12 @@ group Attributes:
\ **machinetype**\ (pdu.machinetype)
The pdu machine type
\ **membergroups**\ (nodegroup.membergroups)
This attribute stores a comma-separated list of nodegroups that this nodegroup refers to. This attribute is only used by PCM.
@@ -455,7 +473,7 @@ group Attributes:
\ **mgt**\ (nodehm.mgt)
The method to use to do general hardware management of the node. This attribute is used as the default if power or getmac is not set. Valid values: ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm. See the power attribute for more details.
The method to use to do general hardware management of the node. This attribute is used as the default if power or getmac is not set. Valid values: openbmc, ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm. See the power attribute for more details.
@@ -501,6 +519,12 @@ group Attributes:
\ **modelnum**\ (pdu.modelnum)
The pdu model number
\ **monserver**\ (noderes.monserver)
The monitoring aggregation point for this node. The format is "x,y" where x is the ip address as known by the management node and y is the ip address as known by the node.
@@ -651,10 +675,14 @@ group Attributes:
\ **nodetype**\ (nodetype.nodetype)
\ **nodetype**\ (nodetype.nodetype, pdu.nodetype)
A comma-delimited list of characteristics of this node. Valid values: ppc, blade, vm (virtual machine), osi (OS image), mm, mn, rsa, switch.
or
The node type should be pdu
\ **ondiscover**\ (chain.ondiscover)
@@ -695,6 +723,12 @@ group Attributes:
\ **outlet**\ (pdu.outlet)
The pdu outlet count
\ **parent**\ (ppc.parent)
For LPARs: the CEC; for FSPs: the CEC; for CEC: the frame (if one exists); for BPA: the frame; for frame: the building block number (which consists 1 or more service nodes and compute/storage nodes that are serviced by them - optional).
@@ -749,6 +783,12 @@ group Attributes:
\ **pdu**\ (pduoutlet.pdu)
a comma-separated list of outlet number for each PDU, ex: pdu1:outlet1,pdu2:outlet1
\ **postbootscripts**\ (postscripts.postbootscripts)
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list.
@@ -866,6 +906,12 @@ group Attributes:
\ **serialnum**\ (pdu.serialnum)
The pdu serial number
\ **serialport**\ (nodehm.serialport)
The serial port for this node, in the linux numbering style (0=COM1/ttyS0, 1=COM2/ttyS1). For SOL on IBM blades, this is typically 1. For rackmount IBM servers, this is typically 0.

58
docs/source/guides/admin-guides/references/man7/node.7.rst
View File

@@ -19,7 +19,7 @@ SYNOPSIS
********
\ **node Attributes:**\ \ *addkcmdline*\ , \ *appstatus*\ , \ *appstatustime*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groups*\ , \ *hcp*\ , \ *height*\ , \ *hidden*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *node*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *primarysn*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *status*\ , \ *statustime*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *updatestatus*\ , \ *updatestatustime*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *xcatmaster*\ , \ *zonename*\
\ **node Attributes:**\ \ *addkcmdline*\ , \ *appstatus*\ , \ *appstatustime*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groups*\ , \ *hcp*\ , \ *height*\ , \ *hidden*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *machinetype*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *modelnum*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *node*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *primarysn*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialnum*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *status*\ , \ *statustime*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *updatestatus*\ , \ *updatestatustime*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *xcatmaster*\ , \ *zonename*\
***********
@@ -69,16 +69,24 @@ node Attributes:
\ **bmc**\ (ipmi.bmc)
\ **bmc**\ (ipmi.bmc, openbmc.bmc)
The hostname of the BMC adapter.
or
The hostname of the BMC adapter.
\ **bmcpassword**\ (ipmi.password)
\ **bmcpassword**\ (ipmi.password, openbmc.password)
The BMC password. If not specified, the key=ipmi row in the passwd table is used as the default.
or
The BMC password.
\ **bmcport**\ (ipmi.bmcport)
@@ -127,10 +135,14 @@ node Attributes:
\ **bmcusername**\ (ipmi.username)
\ **bmcusername**\ (ipmi.username, openbmc.username)
The BMC userid. If not specified, the key=ipmi row in the passwd table is used as the default.
or
The BMC userid.
\ **bmcvlantag**\ (ipmi.taggedvlan)
@@ -447,6 +459,12 @@ node Attributes:
\ **machinetype**\ (pdu.machinetype)
The pdu machine type
\ **memory**\ (hwinv.memory)
The size of the memory for the node in MB.
@@ -455,7 +473,7 @@ node Attributes:
\ **mgt**\ (nodehm.mgt)
The method to use to do general hardware management of the node. This attribute is used as the default if power or getmac is not set. Valid values: ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm. See the power attribute for more details.
The method to use to do general hardware management of the node. This attribute is used as the default if power or getmac is not set. Valid values: openbmc, ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm. See the power attribute for more details.
@@ -501,6 +519,12 @@ node Attributes:
\ **modelnum**\ (pdu.modelnum)
The pdu model number
\ **monserver**\ (noderes.monserver)
The monitoring aggregation point for this node. The format is "x,y" where x is the ip address as known by the management node and y is the ip address as known by the node.
@@ -657,10 +681,14 @@ node Attributes:
\ **nodetype**\ (nodetype.nodetype)
\ **nodetype**\ (nodetype.nodetype, pdu.nodetype)
A comma-delimited list of characteristics of this node. Valid values: ppc, blade, vm (virtual machine), osi (OS image), mm, mn, rsa, switch.
or
The node type should be pdu
\ **ondiscover**\ (chain.ondiscover)
@@ -701,6 +729,12 @@ node Attributes:
\ **outlet**\ (pdu.outlet)
The pdu outlet count
\ **parent**\ (ppc.parent)
For LPARs: the CEC; for FSPs: the CEC; for CEC: the frame (if one exists); for BPA: the frame; for frame: the building block number (which consists 1 or more service nodes and compute/storage nodes that are serviced by them - optional).
@@ -755,6 +789,12 @@ node Attributes:
\ **pdu**\ (pduoutlet.pdu)
a comma-separated list of outlet number for each PDU, ex: pdu1:outlet1,pdu2:outlet1
\ **postbootscripts**\ (postscripts.postbootscripts)
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list.
@@ -878,6 +918,12 @@ node Attributes:
\ **serialnum**\ (pdu.serialnum)
The pdu serial number
\ **serialport**\ (nodehm.serialport)
The serial port for this node, in the linux numbering style (0=COM1/ttyS0, 1=COM2/ttyS1). For SOL on IBM blades, this is typically 1. For rackmount IBM servers, this is typically 0.

85
docs/source/guides/admin-guides/references/man7/pdu.7.rst Normal file
View File

@@ -0,0 +1,85 @@
#####
pdu.7
#####
.. highlight:: perl
****
NAME
****
\ **pdu**\ - a logical object definition in the xCAT database.
********
SYNOPSIS
********
\ **pdu Attributes:**\ \ *machinetype*\ , \ *modelnum*\ , \ *node*\ , \ *nodetype*\ , \ *outlet*\ , \ *serialnum*\
***********
DESCRIPTION
***********
Logical objects of this type are stored in the xCAT database in one or more tables. Use the following commands
to manipulate the objects: \ **mkdef**\ , \ **chdef**\ , \ **lsdef**\ , and \ **rmdef**\ . These commands will take care of
knowing which tables the object attributes should be stored in. The attribute list below shows, in
parentheses, what tables each attribute is stored in.
***************
pdu Attributes:
***************
\ **machinetype**\ (pdu.machinetype)
The pdu machine type
\ **modelnum**\ (pdu.modelnum)
The pdu model number
\ **node**\ (pdu.node)
The hostname/address of the pdu to which the settings apply
\ **nodetype**\ (pdu.nodetype)
The node type should be pdu
\ **outlet**\ (pdu.outlet)
The pdu outlet count
\ **serialnum**\ (pdu.serialnum)
The pdu serial number
********
SEE ALSO
********
\ **mkdef(1)**\ , \ **chdef(1)**\ , \ **lsdef(1)**\ , \ **rmdef(1)**\

6
docs/source/guides/admin-guides/references/man8/makeknownhosts.8.rst
View File

@@ -29,7 +29,7 @@ DESCRIPTION
***********
\ **makeknownhosts**\ Replaces or removes in the known_hosts file in the $ROOTHOME/.ssh directory, the enties for the nodes from the noderange input to the command.
\ **makeknownhosts**\ Replaces or removes entries for the nodes in the known_hosts file in the $ROOTHOME/.ssh directory.
The known_hosts file entry is built from the shared ssh host key that xCAT distributes to the installed nodes.
HMCs, AMM, switches, etc., where xCAT does not distribute the shared ssh host key, should not be put in the noderange.
@@ -37,7 +37,7 @@ HMCs, AMM, switches, etc., where xCAT does not distribute the shared ssh host ke
To build the known_hosts entry for a node, you are only required to have the node in the database, and name resolution working for the node. You do not have to be able to access the node.
Having this file with correct entries, will avoid the ssh warning when nodes are automatically added to the known_hosts file.
The file should be distributed using xdcp to all the nodes, if you want node to node communication not to display the warning.
The file should be distributed using \ **xdcp**\ to all the nodes, if you want node to node communication not to display the warning.
*******
@@ -49,7 +49,7 @@ OPTIONS
\ *noderange*\
A set of comma delimited node names and/or group names.
See the "noderange" man page for details on supported formats.
See the \ *noderange*\ man page for details on supported formats.

2
docs/source/guides/install-guides/apt/prepare_mgmt_node.rst
View File

@@ -10,6 +10,8 @@ Install an OS on the Management Node
:start-after: BEGIN_install_os_mgmt_node
:end-before: END_install_os_mgmt_node
.. _apt_configure_the_base_os_repository:
Configure the Base OS Repository
--------------------------------

2
docs/source/guides/install-guides/zypper/prepare_mgmt_node.rst
View File

@@ -10,6 +10,8 @@ Install an OS on the Management Node
:start-after: BEGIN_install_os_mgmt_node
:end-before: END_install_os_mgmt_node
.. _zypper_configure_the_base_os_repository:
Configure the Base OS Repository
--------------------------------

18
docs/source/overview/xcat2_release.rst
View File

@@ -14,10 +14,26 @@ xCAT 2.13.x
|xCAT |New OS |New |New Feature |
|Version | |Hardware | |
+=================================+===============+=============+==================================+
|| xCAT 2.13.3 |- RHEL 6.9 | |- rpower for OpenBMC(experimental)|
|| 2017/4/7 | | |- Add -C for rmdef to run nodeset |
|| | | | nodeset offline |
| `2.13.3 Release Notes <https:// | | | |
| github.com/xcat2/xcat-core/wiki | | | |
| /XCAT_2.13.3_Release_Notes>`_ | | | |
| | | | |
+---------------------------------+---------------+-------------+----------------------------------+
|| xCAT 2.13.2 | | |- Refine ONIE switch support doc |
|| 2017/2/24 | | |- Add -p for xcatprobe osdeploy |
|| | | | to support performance calculate|
| `2.13.2 Release Notes <https:// | | |- To support PDU |
| github.com/xcat2/xcat-core/wiki | | | |
| /XCAT_2.13.2_Release_Notes>`_ | | | |
| | | | |
+---------------------------------+---------------+-------------+----------------------------------+
|| xCAT 2.13.1 | | |- ONIE switch support |
|| 2017/1/13 | | |- refine xcatprobe subcommand: |
|| | | | xcatmn, osdeploy |
| `2.13.1 Release Notes <https:// | | |- add utp-wait for genesis-base |
| `2.13.1 Release Notes <https:// | | |- add ntp-wait for genesis-base |
| github.com/xcat2/xcat-core/wiki | | | |
| /XCAT_2.13.1_Release_Notes>`_ | | | |
| | | | |

27
docs/source/security/2017/20170126_openssl.rst Normal file
View File

@@ -0,0 +1,27 @@
2017-01-27 - OpenSSL Vulnerabilities
====================================
*Jan 26, 2017*, OpenSSL announced the following security advisories: https://www.openssl.org/news/secadv/20170126.txt
Advisory CVEs
-------------
* CVE-2017-3731 - **Truncated packet could crash via OOB read** (Severity:Moderate)
* CVE-2017-3730 - **Bad (EC)DHE parameters cause a client crash** (Severity: Moderate)
* CVE-2017-3732 - **BN_mod_exp may produce incorrect results on x86_64** (Severity: Moderate)
* CVE-2016-7055 - **Montgomery multiplication may produce incorrect results** (Severity: Low)
Please see the security bulletin above for patch, upgrade, or suggested work around information.
Action
------
xCAT uses OpenSSL for client-server communication but **does not** ship it.
It is highly recommended to keep your OpenSSL levels up-to-date with the indicated versions in the security bulletins to prevent any potential security threats. Obtain the updated software packages from your Operating system distribution channels.

25
docs/source/security/2017/20170216_openssl.rst Normal file
View File

@@ -0,0 +1,25 @@
2017-02-16 - OpenSSL Vulnerabilities
====================================
*Feb 16, 2017*, OpenSSL announced the following security advisories: https://www.openssl.org/news/secadv/20170216.txt
Advisory CVEs
-------------
* CVE-2017-3733 - **Encrypt-Then-Mac renegotiation crash** (Severity:High)
OpenSSL 1.1.0 users should upgrade to 1.1.0e
This issue does not affect OpenSSL version 1.0.2.
Please see the security bulletin above for patch, upgrade, or suggested work around information.
Action
------
xCAT uses OpenSSL for client-server communication but **does not** ship it.
It is highly recommended to keep your OpenSSL levels up-to-date with the indicated versions in the security bulletins to prevent any potential security threats. Obtain the updated software packages from your Operating system distribution channels.

8
docs/source/security/2017/index.rst Normal file
View File

@@ -0,0 +1,8 @@
2017 Notices
============
.. toctree::
:maxdepth: 1
20170216_openssl.rst
20170126_openssl.rst

1
docs/source/security/index.rst
View File

@@ -4,5 +4,6 @@ Security Notices
.. toctree::
:maxdepth: 2
2017/index.rst
2016/index.rst
2015/index.rst

13
perl-xCAT/xCAT/DBobjUtils.pm
View File

@@ -424,7 +424,6 @@ sub getobjdefs
# get the key to look for, for this object type
my $objkey = $datatype->{'objkey'};
# go through the list of valid attrs
foreach my $this_attr (@{ $datatype->{'attrs'} }) {
my $ent;
@@ -487,10 +486,11 @@ sub getobjdefs
my $intabhash = 0;
my $notsearched = 0;
foreach my $lookup_attr (keys %{ $tabentry{'lookup_attrs'} }) {
# Check whether the attribute is already in %tabhash
# The %tabhash is for performance considerations
if (($lookup_attr eq 'node') && ($objtype eq 'node')) {
my $tabspec = $xCAT::Schema::tabspec{$lookup_table};
my $nodecol = $tabspec->{'nodecol'} if defined($tabspec->{'nodecol'});
if (($lookup_attr eq 'node' && $objtype eq 'node') || (defined($nodecol) && $objtype eq 'node' && $lookup_table ne 'ppcdirect')) {
if (defined($tabhash{$lookup_table}{$objname}{$tabattr})) {
if ($verbose == 1) {
$objhash{$objname}{$attr} = "$tabhash{$lookup_table}{$objname}{$tabattr}\t(Table:$lookup_table - Key:$lookup_attr - Column:$tabattr)";
@@ -513,7 +513,6 @@ sub getobjdefs
# Not in tabhash,
# Need to lookup the table
if ($intabhash == 0 && $notsearched == 1) {
# look up attr values
my @rows = xCAT::DBobjUtils->getDBtable($lookup_table);
if (@rows) {
@@ -2502,6 +2501,7 @@ sub judge_node
Arguments:
nicsattr value, like niccsips=eth0!1.1.1.1|2.1.1.1,eth1!3.1.1.1|4.1.1.1
node name, like frame10node10
nicnames: only return the value for specific nics, like "eth0,eth1"
Returns:
expanded format, like:
@@ -2524,8 +2524,8 @@ sub expandnicsattr()
if (($nicstr) && ($nicstr =~ /xCAT::/)) {
$nicstr = shift;
}
my $node = shift;
my $nicnames = shift;
my $ret;
$nicstr =~ /^(.*?)=(.*?)$/;
@@ -2547,7 +2547,6 @@ sub expandnicsattr()
#$nicval Value: node(d+)|eth0!192.1.1.($1+10)
if (($nicval) && ($nicval =~ /\|/)) {
my ($str1, $str2) = split('\|', $nicval);
#$nivval Value: eth0!192.1.1.($1+10)
$nicval = $str2;
}
@@ -2576,6 +2575,7 @@ sub expandnicsattr()
}
}
$nicv[1]= xCAT::Table::transRegexAttrs($node, $nicv[1]);
# ignore the line that does not have nicname or value
if ($nicv[0] && $nicv[1]) {
$ret .= " $nicattr.$nicv[0]=$nicv[1]\n";
@@ -2628,7 +2628,6 @@ sub collapsenicsattr()
$nodeattrhash = shift;
}
my $objname = shift;
my %nicattrs = ();
foreach my $nodeattr (keys %{$nodeattrhash}) {

28
perl-xCAT/xCAT/DSHCLI.pm
View File

@@ -50,7 +50,7 @@ our @dsh_valid_env = (
'DSH_REMOTE_PASSWORD', 'DSH_TO_USERID',
'DSH_FROM_USERID', 'DEVICETYPE',
'RSYNCSN', 'DSH_RSYNC_FILE',
'RSYNCSNONLY',
'RSYNCSNONLY', 'DSH_VERIFY',
);
select(STDERR);
$| = 1;
@@ -979,8 +979,9 @@ sub fork_fanout_dsh
)
= @_;
#get username and passeword for ether net switches (EthSwitch type)
if ($$options{'devicetype'} =~ /EthSwitch/) {
#get username and passeword for switches
if (($$options{'devicetype'} =~ /EthSwitch/) ||
(($$options{'devicetype'} =~ /IBSwitch/) && !($$options{'user'})) ){
if (@$targets_waiting > 0) {
if ($ENV{'DSH_REMOTE_PASSWORD'}) {
foreach my $t (keys(%$resolved_targets)) {
@@ -1010,13 +1011,15 @@ sub fork_fanout_dsh
if (defined($entry->[0]->{protocol})) {
$protocol = $entry->[0]->{protocol};
}
if ((!$username) && (!$password) && (!$protocol)) { #use passwd table as default
if ((!$username) && (!$password)) { #use passwd table as default
if (defined($passwd_ent[0]->{username})) {
$username = $passwd_ent[0]->{username};
}
if (defined($passwd_ent[0]->{password})) {
$password = $passwd_ent[0]->{password};
}
}
if (!$protocol){
if (defined($passwd_ent[0]->{comments}) && ($passwd_ent[0]->{comments} eq "telnet")) {
$protocol = $passwd_ent[0]->{comments};
}
@@ -2489,6 +2492,12 @@ sub config_dsh
$dsh_trace
&& xCAT::MsgUtils->message("I", $rsp, $::CALLBACK);
$$options{'verify'} = $$options{'verify'} || $ENV{'DSH_VERIFY'} || undef;
my $rsp = {};
$rsp->{data}->[0] = "TRACE: Verify value is $$options{'verify'} ";
$dsh_trace
&& xCAT::MsgUtils->message("I", $rsp, $::CALLBACK);
# Check if $$options{'pre-command'} has been overwritten
# Mellanox uses pre-command = cli
if (!$$options{'pre-command'})
@@ -4448,6 +4457,17 @@ sub parse_and_run_dcp
return 0;
}
unless ($options{'user'})
{
# user was not specified with -l flag, check it user calling the command
# was saved in DSH_FROM_USERID environment variable
my $current_userid = $ENV{'DSH_FROM_USERID'};
if (defined($current_userid)) {
# Set userid from value in DSH_FROM_USERID environment variable
$options{'user'} = $current_userid;
}
}
if (defined($options{'rootimg'}))
{
if (xCAT::Utils->isAIX())

4
perl-xCAT/xCAT/FSPvm.pm
View File

@@ -2037,7 +2037,7 @@ sub query_cec_info {
if (scalar(@$rethash)) {
push @result, @$rethash;
} else {
push @result, [ $name, "No information got", -1 ];
push @result, [ $name, "No information obtained.", -1 ];
last;
}
$lpar_hash{$name} = \%tmp_hash;
@@ -2048,7 +2048,7 @@ sub query_cec_info {
if (scalar(@$rethash)) {
push @result, @$rethash;
} else {
push @result, [ @td[3], "No information got", -1 ];
push @result, [ @td[3], "No information obtained.", -1 ];
last;
}

6
perl-xCAT/xCAT/MacMap.pm
View File

@@ -329,14 +329,14 @@ sub dump_mac_info {
foreach my $switch (keys %{ $self->{switchparmhash} }) {
if ($dump_all_switches or defined($switches_to_dump{$switch})) {
if ($self->{show_verbose_info}) {
xCAT::MsgUtils->message("I", { data => ["<INFO>$switch: Start to get information"] }, $self->{callback});
xCAT::MsgUtils->message("I", { data => ["<INFO>$switch: Attempting to refresh switch information..."] }, $self->{callback});
}
$self->refresh_switch(undef, $community, $switch);
if ($self->{show_verbose_info}) {
xCAT::MsgUtils->message("I", { data => ["<INFO>$switch: Finish to get information"] }, $self->{callback});
xCAT::MsgUtils->message("I", { data => ["<INFO>$switch: Finished refreshing switch information."] }, $self->{callback});
}
if (!defined($self->{macinfo}->{$switch})) {
$ret{$switch}->{ErrorStr} = "No information get";
$ret{$switch}->{ErrorStr} = "No switch information obtained.";
foreach my $defportname (keys %{ $self->{switches}->{$switch} }) {
$ret{$switch}->{$defportname}->{Node} = $self->{switches}->{$switch}->{$defportname};
}

4
perl-xCAT/xCAT/NetworkUtils.pm
View File

@@ -1471,7 +1471,7 @@ sub nodeonmynet
my $nettab = xCAT::Table->new("networks");
my @vnets = $nettab->getAllAttribs('net', 'mgtifname', 'mask');
foreach (@vnets) {
if ((defined $_->{mgtifname}) && ($_->{mgtifname} eq '!remote!'))
if ((defined $_->{mgtifname}) && ($_->{mgtifname} =~ /!remote!/))
{
if (xCAT::NetworkUtils->ishostinsubnet($nodeip, $_->{mask}, $_->{net}))
{
@@ -1508,7 +1508,7 @@ sub nodeonmynet
my $nettab = xCAT::Table->new("networks");
my @vnets = $nettab->getAllAttribs('net', 'mgtifname', 'mask');
foreach (@vnets) {
if ((defined $_->{mgtifname}) && ($_->{mgtifname} eq '!remote!'))
if ((defined $_->{mgtifname}) && ($_->{mgtifname} =~ /!remote!/))
{ #global scoped network
my $curm = unpack("N", inet_aton($_->{mask}));
my $bits = 32;

147
perl-xCAT/xCAT/Schema.pm
View File

@@ -443,6 +443,19 @@ passed as argument rather than by table value',
disable => "Set to 'yes' or '1' to comment out this row.",
},
},
openbmc => {
cols => [qw(node bmc username password comments disable)],
keys => [qw(node)],
table_desc => 'Setting for nodes that are controlled by an on-board OpenBmc.',
descriptions => {
node => 'The node name or group name.',
bmc => 'The hostname of the BMC adapter.',
username => 'The BMC userid.',
password => 'The BMC password.',
comments => 'Any user-written notes.',
disable => "Set to 'yes' or '1' to comment out this row.",
},
},
iscsi => {
cols => [qw(node server target lun iname file userid passwd kernel kcmdline initrd comments disable)],
keys => [qw(node)],
@@ -559,7 +572,7 @@ passed as argument rather than by table value',
ddnsdomain => 'A domain to be combined with nodename to construct FQDN for DDNS updates induced by DHCP. This is not passed down to the client as "domain"',
vlanid => 'The vlan ID if this network is within a vlan.',
domain => 'The DNS domain name (ex. cluster.com).',
mtu => 'The default MTU for the network',
mtu => 'The default MTU for the network, If multiple networks are applied to the same nic on the SN and/or CN, the MTU shall be the same for those networks.',
comments => 'Any user-written notes.',
disable => "Set to 'yes' or '1' to comment out this row.",
},
@@ -586,7 +599,7 @@ passed as argument rather than by table value',
descriptions => {
node => 'The node name or group name.',
power => 'The method to use to control the power of the node. If not set, the mgt attribute will be used. Valid values: ipmi, blade, hmc, ivm, fsp, kvm, esx, rhevm. If "ipmi", xCAT will search for this node in the ipmi table for more info. If "blade", xCAT will search for this node in the mp table. If "hmc", "ivm", or "fsp", xCAT will search for this node in the ppc table.',
mgt => 'The method to use to do general hardware management of the node. This attribute is used as the default if power or getmac is not set. Valid values: ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm. See the power attribute for more details.',
mgt => 'The method to use to do general hardware management of the node. This attribute is used as the default if power or getmac is not set. Valid values: openbmc, ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm. See the power attribute for more details.',
cons => 'The console method. If nodehm.serialport is set, this will default to the nodehm.mgt setting, otherwise it defaults to unused. Valid values: cyclades, mrv, or the values valid for the mgt attribute.',
termserver => 'The hostname of the terminal server.',
termport => 'The port number on the terminal server that this node is connected to.',
@@ -678,6 +691,22 @@ passed as argument rather than by table value',
disable => "Set to 'yes' or '1' to comment out this row.",
},
},
pdu => {
cols => [qw(node nodetype outlet machinetype modelnum serialnum comments disable)],
keys => [qw(node)],
nodecol => "node",
table_desc => 'Parameters to use when interrogating pdus',
descriptions => {
node => 'The hostname/address of the pdu to which the settings apply',
nodetype => 'The node type should be pdu ',
outlet => 'The pdu outlet count',
machinetype => 'The pdu machine type',
modelnum => 'The pdu model number',
serialnum => 'The pdu serial number',
comments => 'Any user-written notes.',
disable => "Set to 'yes' or '1' to comment out this row.",
},
},
switches => {
cols => [qw(switch snmpversion username password privacy auth linkports sshusername sshpassword protocol switchtype comments disable)],
keys => [qw(switch)],
@@ -831,8 +860,8 @@ passed as argument rather than by table value',
descriptions => {
key => 'The type of component this user/pw is for. Valid values: blade (management module), ipmi (BMC), system (nodes), omapi (DHCP), hmc, ivm, cec, frame, switch.',
username => 'The default userid for this type of component',
password => 'The default password for this type of component',
cryptmethod => 'Indicates the method that was used to encrypt the password attribute. On AIX systems, if a value is provided for this attribute it indicates that the password attribute is encrypted. If the cryptmethod value is not set it indicates the password is a simple string value. On Linux systems, the cryptmethod can be set to md5, sha256 or sha512. If not set, sha256 will be used as default.',
password => 'The default password for this type of component. On Linux, a crypted form could be provided. Hashes starting with $1$, $5$ and $6$ (md5, sha256 and sha512 respectively) are supported.',
cryptmethod => 'Indicates the method to use to encrypt the password attribute. On AIX systems, if a value is provided for this attribute it indicates that the password attribute is encrypted. If the cryptmethod value is not set it indicates the password is a simple string value. On Linux systems, the cryptmethod can be set to md5, sha256 or sha512. If not set, sha256 will be used as default to encrypt plain-text passwords.',
authdomain => 'The domain in which this entry has meaning, e.g. specifying different domain administrators per active directory domain',
comments => 'Any user-written notes.',
disable => "Set to 'yes' or '1' to comment out this row.",
@@ -1255,6 +1284,17 @@ passed as argument rather than by table value',
disable => "Set to 'yes' or '1' to comment out this row.",
},
},
pduoutlet => {
cols => [qw(node pdu comments disable)],
keys => [qw(node)],
table_desc => 'Contains list of outlet numbers on the pdu each node is connected to.',
descriptions => {
node => 'The node name or group name.',
pdu => 'a comma-separated list of outlet number for each PDU, ex: pdu1:outlet1,pdu2:outlet1',
comments => 'Any user-written notes.',
disable => "Set to 'yes' or '1' to comment out this row.",
}
},
switch => {
cols => [qw(node switch port vlan interface comments disable)],
keys => [qw(node switch port)],
@@ -1840,6 +1880,7 @@ foreach my $tabname (keys(%xCAT::ExtTab::ext_tabspec)) {
zvmivp => { attrs => [], attrhash => {}, objkey => 'id' },
firmware => { attrs => [], attrhash => {}, objkey => 'cfgfile' },
taskstate => { attrs => [], attrhash => {}, objkey => 'node' },
pdu => { attrs => [], attrhash => {}, objkey => 'node' },
);
@@ -2445,6 +2486,26 @@ my @nodeattrs = (
tabentry => 'mpa.urlpath',
access_tabentry => 'mpa.mpa=attr:node',
},
#########################
# openbmc table #
##########################
{ attr_name => 'bmc',
only_if => 'mgt=openbmc',
tabentry => 'openbmc.bmc',
access_tabentry => 'openbmc.node=attr:node',
},
{ attr_name => 'bmcusername',
only_if => 'mgt=openbmc',
tabentry => 'openbmc.username',
access_tabentry => 'openbmc.node=attr:node',
},
{ attr_name => 'bmcpassword',
only_if => 'mgt=openbmc',
tabentry => 'openbmc.password',
access_tabentry => 'openbmc.node=attr:node',
},
######################
# nodepos table #
######################
@@ -2723,6 +2784,14 @@ my @nodeattrs = (
tabentry => 'websrv.password',
access_tabentry => 'websrv.node=attr:node',
},
######################
# pduoutlet table #
######################
{ attr_name => 'pdu',
tabentry => 'pduoutlet.pdu',
access_tabentry => 'pduoutlet.node=attr:node',
},
######################
# switch table #
######################
@@ -2841,6 +2910,35 @@ my @nodeattrs = (
access_tabentry => 'hwinv.node=attr:node',
},
#########################
## pdu table #
#########################
{ attr_name => 'nodetype',
only_if => 'nodetype=pdu',
tabentry => 'pdu.nodetype',
access_tabentry => 'pdu.node=attr:node',
},
{ attr_name => 'outlet',
only_if => 'nodetype=pdu',
tabentry => 'pdu.outlet',
access_tabentry => 'pdu.node=attr:node',
},
{ attr_name => 'machinetype',
only_if => 'nodetype=pdu',
tabentry => 'pdu.machinetype',
access_tabentry => 'pdu.node=attr:node',
},
{ attr_name => 'modelnum',
only_if => 'nodetype=pdu',
tabentry => 'pdu.modelnum',
access_tabentry => 'pdu.node=attr:node',
},
{ attr_name => 'serialnum',
only_if => 'nodetype=pdu',
tabentry => 'pdu.serialnum',
access_tabentry => 'pdu.node=attr:node',
},
#########################
## switches table #
#########################
@@ -4043,6 +4141,47 @@ push(@{ $defspec{group}->{'attrs'} }, @nodeattrs);
},
);
#############################
# pdu object #
#############################
#############################
# pdu table #
#############################
@{ $defspec{pdu}->{'attrs'} } =
(
{ attr_name => 'node',
only_if => 'nodetype=pdu',
tabentry => 'pdu.node',
access_tabentry => 'pdu.node=attr:node',
},
{ attr_name => 'nodetype',
only_if => 'nodetype=pdu',
tabentry => 'pdu.nodetype',
access_tabentry => 'pdu.node=attr:node',
},
{ attr_name => 'outlet',
only_if => 'nodetype=pdu',
tabentry => 'pdu.outlet',
access_tabentry => 'pdu.node=attr:node',
},
{ attr_name => 'machinetype',
only_if => 'nodetype=pdu',
tabentry => 'pdu.machinetype',
access_tabentry => 'pdu.node=attr:node',
},
{ attr_name => 'modelnum',
only_if => 'nodetype=pdu',
tabentry => 'pdu.modelnum',
access_tabentry => 'pdu.node=attr:node',
},
{ attr_name => 'serialnum',
only_if => 'nodetype=pdu',
tabentry => 'pdu.serialnum',
access_tabentry => 'pdu.node=attr:node',
},
);
###################################################

162
perl-xCAT/xCAT/Table.pm
View File

@@ -2299,6 +2299,95 @@ $evalcpt->permit('require');
#--------------------------------------------------------------------------
=head3 transRegexAttrs
Description: Transform the regular expression attribute to the target value
based on the node name.
Arguments:
Node
Attribute value (may have regular expression)
Returns:
Attribute value
undef
Globals:
Error:
Example:
if (defined($retval = transRegexAttrs($node, $datum->{$attrib}))) {
$datum->{$attrib} = $retval;
} else {
delete $datum->{$attrib};
}
Comments:
none
=cut
#---------------------------------------------------------------------------
sub transRegexAttrs
{
my ($node, $attr) = @_;
my $retval = $attr;
if ($attr =~ /^\/[^\/]*\/[^\/]*\/$/) {
my $exp = substr($attr, 1);
chop $exp;
my @parts = split('/', $exp, 2);
$retval = $node;
$retval =~ s/$parts[0]/$parts[1]/;
} elsif ($attr =~ /^\|.*\|$/) {
my $exp = substr($attr, 1);
chop $exp;
my @parts = split('\|', $exp, 2);
my $arraySize = @parts;
if ($arraySize < 2) { # easy regx, generate lhs from node
my $lhs;
my @numbers = $node =~ m/[\D0]*(\d+)/g;
$lhs = '[\D0]*(\d+)' x scalar(@numbers);
$lhs .= '.*$';
unshift(@parts, $lhs);
}
my ($curr, $next, $prev);
$retval = $parts[1];
($curr, $next, $prev) =
extract_bracketed($retval, '()', qr/[^()]*/);
unless ($curr) { #If there were no paramaters to save, treat this one like a plain regex
undef $@; #extract_bracketed would have set $@ if it didn't return, undef $@
$retval = $node;
$retval =~ s/$parts[0]/$parts[1]/;
if ($retval =~ /^$/) {
return undef;
}
return $retval;
}
while ($curr)
{
my $value = $node;
$value =~ s/$parts[0]/$curr/;
$value = $evalcpt->reval('use integer;' . $value);
$retval = $prev . $value . $next;
($curr, $next, $prev) =
extract_bracketed($retval, '()', qr/[^()]*/);
}
undef $@;
#At this point, $retval is the expression after being arithmetically contemplated, a generated regex, and therefore
#must be applied in total
my $answval = $node;
$answval =~ s/$parts[0]/$retval/;
$retval = $answval;
}
if ($retval =~ /^$/) {
$retval = undef;
}
return $retval;
}
#--------------------------------------------------------------------------
=head3 getNodeAttribs
Description: Retrieves the requested attribute
@@ -2392,77 +2481,10 @@ sub getNodeAttribs
#skip undefined values, save time
next;
}
if ($datum->{$attrib} =~ /^\/[^\/]*\/[^\/]*\/$/)
{
my $exp = substr($datum->{$attrib}, 1);
chop $exp;
my @parts = split('/', $exp, 2);
my $retval = $node;
$retval =~ s/$parts[0]/$parts[1]/;
my $retval;
if (defined($retval = transRegexAttrs($node, $datum->{$attrib}))) {
$datum->{$attrib} = $retval;
}
elsif ($datum->{$attrib} =~ /^\|.*\|$/)
{
#Perform arithmetic and only arithmetic operations in bracketed issues on the right.
#Tricky part: don't allow potentially dangerous code, only eval if
#to-be-evaled expression is only made up of ()\d+-/%$
#Futher paranoia? use Safe module to make sure I'm good
my $exp = substr($datum->{$attrib}, 1);
chop $exp;
my @parts = split('\|', $exp, 2);
my $arraySize = @parts;
if ($arraySize < 2) { # easy regx, generate lhs from node
my $lhs;
my @numbers = $node =~ m/[\D0]*(\d+)/g;
$lhs = '[\D0]*(\d+)' x scalar(@numbers);
$lhs .= '.*$';
unshift(@parts, $lhs);
}
my $curr;
my $next;
my $prev;
my $retval = $parts[1];
($curr, $next, $prev) =
extract_bracketed($retval, '()', qr/[^()]*/);
unless ($curr) { #If there were no paramaters to save, treat this one like a plain regex
undef $@; #extract_bracketed would have set $@ if it didn't return, undef $@
$retval = $node;
$retval =~ s/$parts[0]/$parts[1]/;
$datum->{$attrib} = $retval;
if ($datum->{$attrib} =~ /^$/) {
#If regex forces a blank, act like a normal blank does
delete $datum->{$attrib};
}
next; #skip the redundancy that follows otherwise
}
while ($curr)
{
#my $next = $comps[0];
my $value = $node;
$value =~ s/$parts[0]/$curr/;
$value = $evalcpt->reval('use integer;' . $value);
$retval = $prev . $value . $next;
($curr, $next, $prev) =
extract_bracketed($retval, '()', qr/[^()]*/);
}
undef $@;
#At this point, $retval is the expression after being arithmetically contemplated, a generated regex, and therefore
#must be applied in total
my $answval = $node;
$answval =~ s/$parts[0]/$retval/;
$datum->{$attrib} = $answval; #$retval;
#print Data::Dumper::Dumper(extract_bracketed($parts[1],'()',qr/[^()]*/));
#use text::balanced extract_bracketed to parse earch atom, make sure nothing but arith operators, parans, and numbers are in it to guard against code execution
}
if ($datum->{$attrib} =~ /^$/) {
#If regex forces a blank, act like a normal blank does
} else {
delete $datum->{$attrib};
}
}

13
perl-xCAT/xCAT/Usage.pm
View File

@@ -26,6 +26,8 @@ my %usage = (
"rpower" =>
"Usage: rpower <noderange> [--nodeps] [on|onstandby|off|suspend|reset|stat|state|boot] [-V|--verbose] [-m table.colum==expectedstatus][-m table.colum==expectedstatus...] [-r <retrycount>] [-t <timeout>]
rpower [-h|--help|-v|--version]
OpenBMC specific:
rpower noderange [on|off|reset|boot|stat|state|status]
KVM Virtualization specific:
rpower <noderange> [boot] [ -c <path to iso> ]
PPC (with IVM or HMC) specific:
@@ -44,12 +46,17 @@ my %usage = (
rpower <noderange> [on|onstandby|off|cycle|state|sms]
Blade(using AMM) specific:
rpower <noderange> [cycle|softoff] [-V|--verbose]
Lenovo high-density server specific:
rpower <noderange> [on|off|reset|boot|reseat]
zVM specific:
rpower noderange [on|off|reset|stat|softoff]
MIC specific:
rpower noderange [stat|state|on|off|reset|boot]
docker specific:
rpower noderange [start|stop|restart|pause|unpause|state]
pdu specific:
rpower noderange [off|on|stat|status|reset]
rpower noderange [pduoff|pduon|pdustat|pdustatus|pdureset]
",
"rbeacon" =>
"Usage: rbeacon <noderange> [on|off|stat] [-V|--verbose]
@@ -81,7 +88,7 @@ my %usage = (
rinv <noderange> [all|model|serial] [-V|--verbose]
rinv [-h|--help|-v|--version]
BMC specific:
rinv <noderange> [mprom|deviceid|uuid|guid|vpd|all]
rinv <noderange> [mprom|deviceid|uuid|guid|vpd|dimm|all]
OpenPOWER server specific:
rinv <noderange> [model|serial|deviceid|uuid|guid|vpd|mprom|firm|all]
MPA specific:
@@ -100,7 +107,9 @@ my %usage = (
zVM specific:
rinv noderange [all|config]
MIC specific:
rinv noderange [system|ver|board|core|gddr|all]",
rinv noderange [system|ver|board|core|gddr|all]
pdu specific:
rinv noderange ",
"rsetboot" =>
"Usage: rsetboot <noderange> [net|hd|cd|floppy|def|stat] [-V|--verbose] [-u] [-p]
rsetboot [-h|--help|-v|--version]",

11
perl-xCAT/xCAT/Yum.pm
View File

@@ -9,12 +9,16 @@ my $distname;
my $arch;
my $installpfx;
my $distrepopfx="/install/postscripts/repos";
sub localize_yumrepo {
my $self = shift;
my $pkgdir = shift;
$distname=shift;
$arch=shift;
open($yumrepofile, ">", "$pkgdir/local-repository.tmpl");
mkpath("$distrepopfx/$pkgdir");
open($yumrepofile, ">", "$distrepopfx/$pkgdir/local-repository.tmpl");
my %options = (
wanted => \&check_tofix,
follow_fast => 1
@@ -27,7 +31,7 @@ sub localize_yumrepo {
sub remove_yumrepo {
my $self = shift;
my $pkgdir = shift;
rmtree("$pkgdir/local-repository.tmpl");
rmtree("$distrepopfx/$pkgdir/local-repository.tmpl");
}
sub check_tofix {
@@ -50,8 +54,9 @@ sub generate_repo
my $dirlocation = shift;
my @dircomps = File::Spec->splitdir($dirlocation);
pop(@dircomps);
my $reponame = join("-",@dircomps);
my $yumurl = File::Spec->catdir(@dircomps);
my $reponame = $dircomps[$#dircomps];
print $yumrepofile "[local-$distname-$arch-$reponame]\n";
print $yumrepofile "name=xCAT configured yum repository for $yumurl\n";
print $yumrepofile "baseurl=$yumurl\n";

53
perl-xCAT/xCAT/data/discinfo.pm
View File

@@ -12,34 +12,42 @@ require Exporter;
@EXPORT_OK = qw(distnames numdiscs);
%distnames = (
"1310229985.226287" => "centos6",
"1323560292.885204" => "centos6.2",
"1341569670.539525" => "centos6.3", #x86
"1362445555.957609" => "centos6.4", #x86_64
"1385726732.061157" => "centos6.5", #x86_64
"1438724467.511049" => "centos6.7", #x86_64
"1463897259.552895" => "centos6.8", #x86_64
"1404489053.504589" => "centos7.0",
"1427495138.035654" => "centos7.1",
my %distnames = (
"1480943823.812754" => "centos7.3", #x86_64
"1450147276.351714" => "centos7.2", #ppc64le
"1449699925.561114" => "centos7.2", #x86_64
"1427495138.035654" => "centos7.1",
"1404489053.504589" => "centos7.0",
"1463897259.552895" => "centos6.8", #x86_64
"1438724467.511049" => "centos6.7", #x86_64
"1414159991.958686" => "centos6.6",
"1385726732.061157" => "centos6.5", #x86_64
"1362445555.957609" => "centos6.4", #x86_64
"1341569670.539525" => "centos6.3", #x86
"1323560292.885204" => "centos6.2",
"1310229985.226287" => "centos6",
"1381776971.473332" => "centos5.10", #x86_64
"1357930415.252042" => "centos5.9", #x86_64
"1330913492.861127" => "centos5.8", #x86_64
"1301444731.448392" => "centos5.6",
"1272326751.405938" => "centos5.5",
"1254416275.453877" => "centos5.4", #x86_64
"1237641529.260981" => "centos5.3",
"1214240246.285059" => "centos5.2",
"1213888991.267240" => "centos5.2",
"1195929637.060433" => "centos5.1",
"1195929648.203590" => "centos5.1",
"1176234647.982657" => "centos5",
"1156364963.862322" => "centos4.4",
"1178480581.024704" => "centos4.5",
"1195929648.203590" => "centos5.1",
"1195929637.060433" => "centos5.1",
"1213888991.267240" => "centos5.2",
"1214240246.285059" => "centos5.2",
"1237641529.260981" => "centos5.3",
"1272326751.405938" => "centos5.5",
"1330913492.861127" => "centos5.8", #x86_64
"1357930415.252042" => "centos5.9", #x86_64
"1381776971.473332" => "centos5.10", #x86_64
"1195488871.805863" => "centos4.6",
"1195487524.127458" => "centos4.6",
"1301444731.448392" => "centos5.6",
"1414159991.958686" => "centos6.6",
"1170973598.629055" => "rhelc5",
"1170978545.752040" => "rhels5",
"1192660014.052098" => "rhels5.1",
"1192663619.181374" => "rhels5.1",
@@ -87,6 +95,7 @@ require Exporter;
"1446216863.790260" => "rhels7.2", #x86_64
"1446216863.764721" => "rhels7.2", #ppc64
"1446216863.771788" => "rhels7.2", #ppc64le
"1285193176.593806" => "rhelhpc6", #x86_64
"1305067719.718814" => "rhelhpc6.1", #x86_64
"1321545261.599847" => "rhelhpc6.2", #x86_64
@@ -99,6 +108,7 @@ require Exporter;
"1399449226.140088" => "rhelhpc7.0", #x86_64, RHEL ComputeNode
"1424360759.772760" => "rhelhpc7.1", #x86_64, RHEL ComputeNode
"1446216863.725127" => "rhelhpc7.2", #x86_64, RHEL ComputeNode
"1194015916.783841" => "fedora8",
"1194015385.299901" => "fedora8",
"1210112435.291709" => "fedora9",
@@ -113,6 +123,7 @@ require Exporter;
"1372355769.065812" => "fedora19", #x86_64 DVD ISO
"1372402928.663653" => "fedora19", #ppc64 DVD ISO
"1386856788.124593" => "fedora20", #x86_64 DVD ISO
"1194512200.047708" => "rhas4.6",
"1194512327.501046" => "rhas4.6",
"1241464993.830723" => "rhas4.8", #x86-64

5
xCAT-client/bin/pping
View File

@@ -162,6 +162,11 @@ sub fping_pping {
}
else
{
if (!-x '/usr/bin/fping')
{
print "fping is not available, please install missing package fping.\n";
exit 1;
}
open(FPING, "fping " . join(' ', @$nodes) . " 2>&1 |") or die("Cannot open fping pipe: $!");
}
while (<FPING>) {

4
xCAT-client/bin/rcons
View File

@@ -73,7 +73,7 @@ fi
if [ $USE_CONFLUENT == "1" ] && ([ -x "/opt/confluent/bin/confetty" ] || [ -x "/usr/bin/confetty" ] || [ -x "/usr/local/bin/confetty" ]); then
# use confluent, make sure conserver is not also running
CONSERVER_RC=`service conserver status >> /dev/null; echo $?`
CONSERVER_RC=`pidof conserver >> /dev/null; echo $?`
if [[ ${CONSERVER_RC} == 0 ]]; then
echo "Error: consoleservice is set to 'confluent' but conserver is running. Stop conserver, run makeconfluentcfg, and retry..."
exit 1
@@ -107,7 +107,7 @@ elif [ -f "/usr/bin/console" ] || [ -f "/bin/console" ]; then
# use conserver
# make sure confluent is not also running, only if confluent is installed
if [[ -f "/etc/init.d/confluent" ]]; then
CONFLUENT_RC=`service confluent status >> /dev/null; echo $?`
CONFLUENT_RC=`service confluent status >& /dev/null; echo $?`
if [[ ${CONFLUENT_RC} == 0 ]]; then
echo "Error: consoleservice is set to 'conserver' but confluent is running. Stop confluent, run makeconservercf, and retry..."
exit 1

2
xCAT-client/bin/wcons
View File

@@ -17,7 +17,7 @@ unless ($ENV{DISPLAY}) {
my $mydir = dirname($0);
my $sb;
my $tilefact;
my $xrm = "-xrm xterm.mainMenu.*.font:fixed -xrm xterm.vtMenu.*.font:fixed -xrm xterm.fontMenu.*.font:fixed -xrm xterm -xrm xterm.vt100.font6:grvga.737";
my $xrm = "-xrm xterm.mainMenu.*.font:fixed -xrm xterm.vtMenu.*.font:fixed -xrm xterm.fontMenu.*.font:fixed -xrm xterm -xrm xterm.vt100.font6:grvga.737 -xrm xterm.vt100.color0:#000000 -xrm xterm.vt100.color1:#AA0000 -xrm xterm.vt100.color2:#00AA00 -xrm xterm.vt100.color3:#AA5500 -xrm xterm.vt100.color4:#0000AA -xrm xterm.vt100.color5:#AA00AA -xrm xterm.vt100.color6:#00AAAA -xrm xterm.vt100.color7:#AAAAAA -xrm xterm.vt100.color8:#555555 -xrm xterm.vt100.color9:#FF5555 -xrm xterm.vt100.color10:#55FF55 -xrm xterm.vt100.color11:#FFFF55 -xrm xterm.vt100.color12:#5555FF -xrm xterm.vt100.color13:#FF55FF -xrm xterm.vt100.color14:#55FFFF -xrm xterm.vt100.color15:#FFFFFF";
my $font = "5x7";
my $sizegeometry;
GetOptions(

23
xCAT-client/bin/xdsh
View File

@@ -190,6 +190,11 @@ if ($ENV{'DSH_ENVIRONMENT'})
push(@{ $cmdref->{env} }, "DSH_ENVIRONMENT=$ENV{'DSH_ENVIRONMENT'}");
}
if ($ENV{'DSH_VERIFY'})
{
push(@{ $cmdref->{env} }, "DSH_VERIFY=$ENV{'DSH_VERIFY'}");
}
xCAT::Client::submit_request($cmdref, \&xCAT::Client::handle_response);
exit $xCAT::Client::EXITCODE;
@@ -666,6 +671,24 @@ sub parse_args_xdcp
$::NODE_RCP = 1;
}
my $to_userid;
if ($options{'user'}) # if -l option
{
$to_userid = $options{'user'};
}
else
{
# find out who is the current user running xdcp
my $current_userid = getpwuid($>);
$ENV{DSH_FROM_USERID} = $current_userid;
$to_userid = $current_userid;
}
# Save userid running this command in ENV variable.
# It will be later extraced by DSHCLI.pm
$ENV{DSH_TO_USERID} = $to_userid;
if ($options{'bypass'})
{
$ENV{XCATBYPASS} = "yes"; # bypass xcatd

9
xCAT-client/pods/man1/getadapter.1.pod
View File

@@ -14,12 +14,11 @@ Traditionally, network interfaces in Linux are enumerated as eth[0123...], but t
B<getadapter> use genesis to collect network adapters information, so that mean it need to restart the target node.
B<getadapter> follows below scheme:
B<getadapter> For each node within the <noderange>, follows below scheme:
If the target node is scaned for the first time, B<getadapter> will trigger genesis to collect information then save the information at local.
If the target node has ever been scaned, i.e. this node has network device information in local, B<getadapter> use the local information first.
If user doesn't want to use local information, can use B<-f> option to force to trigger new round scan process.
if part nodes of I<noderange> don't have network device information in local and the rest have, B<getadapter> only trigger real scan process for these nodes which don't have local information, the nodes have network device information in local, B<getadapter> still use the local information first.
If the target node is scaned for the first time, B<getadapter> will trigger genesis to collect information then save the information at the B<nicsadapter> column of nics table.
If the target node has ever been scaned, B<getadapter> will use the information from nics table first.
If user hopes to scan the adapter information for the node but these information already exist, B<-f> option can be used to start rescan process.
B<getadapter> tries to collect more information for the target network device, but doesn't guarantee collect same much information for every network device.

4
xCAT-client/pods/man1/pping.1.pod
View File

@@ -16,7 +16,7 @@ B<pping> {B<-v>|B<--version>}
B<pping> is a utility used to ping a list of nodes in parallel.
B<pping> will return an unsorted list of nodes with a ping or noping status.
B<pping> front-ends nmap or fping if available.
B<pping> front-ends B<nmap> or B<fping> if available.
This command does not support the xcatd client/server communication. It must be run on the management node.
@@ -34,7 +34,7 @@ If more than one interface is specified, each interface will be combined with th
=item B<-f>|B<--use_fping>
Use fping instead of nmap
Use B<fping> instead of B<nmap>
=item B<-h>|B<--help>

13
xCAT-client/pods/man1/prsync.1.pod
View File

@@ -6,18 +6,16 @@ prsync - parallel rsync
B<prsync> I<filename> [I<filename> I<...>] I<noderange:destinationdirectory>
B<prsync> [B<-o> I<rsync options>] [B<-f> I<fanout>] [I<filename> I<filename> I<...>] [I<directory> I<directory> I<...>]
B<prsync> [B<-o> I<rsyncopts>] [B<-f> I<fanout>] [I<filename> I<filename> I<...>] [I<directory> I<directory> I<...>]
I<noderange:destinationdirectory>
B<prsync> {B<-h>|B<--help>|B<-v>|B<--version>}
=head1 B<Description>
B<prsync> is a front-end to rsync for a single or range of nodes and/or
groups in parallel.
B<prsync> is a front-end to rsync for a single or range of nodes and/or groups in parallel.
Note: this command does not support the xcatd client/server communication and therefore must be run on the management node. It does not support hierarchy, use xdcp -F to run rsync from the
management node to the compute node via a service node
Note: this command does not support the xcatd client/server communication and therefore must be run on the management node. It does not support hierarchy, use B<xdcp -F> to run rsync from the management node to the compute node via a service node
B<prsync> is NOT multicast, but is parallel unicasts.
@@ -25,14 +23,13 @@ B<prsync> is NOT multicast, but is parallel unicasts.
=over 7
=item I<rsyncopts>
=item B<-o> I<rsyncopts>
rsync options. See B<rsync(1)>.
=item B<-f> I<fanout>
Specifies a fanout value for the maximum number of concur-
rently executing remote shell processes.
Specifies a fanout value for the maximum number of concurrently executing remote shell processes.
=item I<filename>

26
xCAT-client/pods/man1/rflash.1.pod
View File

@@ -1,6 +1,6 @@
=head1 Name
B<rflash> - Performs Licensed Internal Code (LIC) update support for HMC-attached POWER5 and POWER6 Systems, and POWER7 systems using Direct FSP management. rflash is also able to update firmware for NextScale Fan Power Controllers (FPC).
B<rflash> - Performs Licensed Internal Code (LIC) update support for HMC-attached POWER5 and POWER6 Systems, and POWER7 systems using Direct FSP management. B<rflash> is also able to update firmware for NextScale Fan Power Controllers (FPC).
=head1 B<Synopsis>
@@ -8,33 +8,33 @@ B<rflash> [B<-h>|B<--help> | B<-v>|B<--version>]
=head2 PPC (with HMC) specific:
B<rflash> I<noderange> B<-p> I<directory> {B<--activate> B<concurrent>|B<disruptive>} [B<-V>|B<--verbose>]
B<rflash> I<noderange> B<-p> I<directory> [B<--activate> {B<concurrent>|B<disruptive>}] [B<-V>|B<--verbose>]
B<rflash> I<noderange> {B<--commit>|B<--recover>} [B<-V>|B<--verbose>]
=head2 PPC (without HMC, using Direct FSP Management) specific:
B<rflash> I<noderange> B<-p> I<directory> B<--activate> B<disruptive>|B<deferred> [B<-d> I<data_directory>]
B<rflash> I<noderange> B<-p> I<directory> [B<--activate> {B<disruptive>|B<deferred>}] [B<-d> I<data_directory>]
B<rflash> I<noderange> {B<--commit>|B<--recover>}
=head2 NeXtScale FPC specific:
B<rflash> I<noderange> I<http directory>
B<rflash> I<noderange> I<http_directory>
=head2 OpenPOWER BMC specific:
B<rflash> I<noderange> I<hpm file path> [B<-c>|B<--check>] [B<-V>]
B<rflash> I<noderange> I<hpm_file_path> [B<-c>|B<--check>] [B<--retry=>I<count>] [B<-V>]
=head1 B<Description>
B<rflash> The B<rflash> command initiates Firmware updates on supported xCAT nodes. Licensed Internal Code (also known as microcode) updates are performed on supported HMC-attached POWER5 and POWER6 pSeries nodes, and POWER7 systems using Direct FSP management.
The B<rflash> command initiates Firmware updates on supported xCAT nodes. Licensed Internal Code (also known as microcode) updates are performed on supported HMC-attached POWER5 and POWER6 pSeries nodes, and POWER7 systems using Direct FSP management.
The command scans the specified directory structure for Firmware update package files applicable to the given nodes and components. And then it will B<automatically> select the B<latest> version for the upgrade. The firmware update files include the Microcode update package and associated XML file. They can be downloaded from the IBM Web site: I<http://www-933.ibm.com/support/fixcentral/>.
The POWER5 and POWER6 systems contain several components that use Licensed Internal Code. The B<rflash> command supports two of these components: the managed system (also known as the Central Electronics Complex, or CEC) and the power subsystem (also known as the Bulk Power Assembly (BPA) or Bulk Power Controller (BPC)). Some POWER5 managed systems can be attached to a power subsystem. These power subsystems can support multiple managed systems. When the B<rflash> command is invoked, xCAT will determine the managed system or power subsystem associated with that CEC and perform the update.
The B<noderange> can be an CEC or CEC list, a Lpar or Lpar list and a Frame or Frame list. But CEC (or Lpar) and Frame B<can't> be used at the same time. When the I<noderange> is an CEC or CEC list, B<rflash> will upgrade the firmware of the CEC or CECs in the cec list. If I<noderange> is a Lpar or Lpar list, B<rflash> will update Licensed Internal Code (LIC) on HMC-attached POWER5 and POWER6 pSeries nodes, and POWER7 systems using Direct FSP management. If I<noderange> is a Frame or Frame list, B<rflash> will update Licensed Internal Code (LIC) of the power subsystem on HMC-attached POWER5 and POWER6 pSeries nodes. The I<noderange> can also be the specified node groups. You can specify a comma or space-separated list of node group ranges. See the I<noderange> man page for detailed usage information.
The I<noderange> can be an CEC or CEC list, a Lpar or Lpar list and a Frame or Frame list. But CEC (or Lpar) and Frame B<can't> be used at the same time. When the I<noderange> is an CEC or CEC list, B<rflash> will upgrade the firmware of the CEC or CECs in the cec list. If I<noderange> is a Lpar or Lpar list, B<rflash> will update Licensed Internal Code (LIC) on HMC-attached POWER5 and POWER6 pSeries nodes, and POWER7 systems using Direct FSP management. If I<noderange> is a Frame or Frame list, B<rflash> will update Licensed Internal Code (LIC) of the power subsystem on HMC-attached POWER5 and POWER6 pSeries nodes. The I<noderange> can also be the specified node groups. You can specify a comma or space-separated list of node group ranges. See the I<noderange> man page for detailed usage information.
The command will update firmware for NeXtScale FPC when given an FPC node and the http information needed to access the firmware.
@@ -66,11 +66,11 @@ In currently Direct FSP/BPA Management, our B<rflash> doesn't support B<concurre
The B<deferred> option will load the new firmware into the T (temp) side, but will not activate it like the disruptive firmware. The customer will continue to run the Frames and CECs working with the P (perm) side and can wait for a maintenance window where they can activate and boot the Frame/CECs with new firmware levels. Refer to the doc to get more details: XCAT_Power_775_Hardware_Management
In Direct FSP/BPA Management, there is -d <data_directory> option. The default value is /tmp. When do firmware update, rflash will put some related data from rpm packages in <data_directory> directory, so the execution of rflash will require available disk space in <data_directory> for the command to properly execute:
In Direct FSP/BPA Management, there is B<-d> I<data_directory> option. The default value is /tmp. When doing firmware update, B<rflash> will put some related data from rpm packages in <data_directory> directory, so the execution of B<rflash> will require available disk space in <data_directory> for the command to properly execute:
For one GFW rpm package and one power code rpm package , if the GFW rpm package size is gfw_rpmsize, and the Power code rpm package size is power_rpmsize, it requires that the available disk space should be more than: 1.5*gfw_rpmsize + 1.5*power_rpmsize
For Power 775, the rflash command takes effect on the primary and secondary FSPs or BPAs almost in parallel.
For Power 775, the B<rflash> command takes effect on the primary and secondary FSPs or BPAs almost in parallel.
For more details about the Firmware Update using Direct FSP/BPA Management, refer to: XCAT_Power_775_Hardware_Management#Updating_the_BPA_and_FSP_firmware_using_xCAT_DFM
@@ -102,7 +102,7 @@ Specifies the directory where the packages are located.
Specifies the directory where the raw data from rpm packages for each CEC/Frame are located. The default directory is /tmp. The option is only used in Direct FSP/BPA Management.
=item B<--activate> B<concurrent> | B<disruptive>
=item B<--activate> {B<concurrent> | B<disruptive>}
Must be specified to activate the new Licensed Internal Code. The "disruptive" option will cause the target systems to be recycled. Without this flag, LIC updates will be installed only, not activated.
@@ -114,6 +114,10 @@ Used to commit the flash image in the temporary side of the chip to the permanen
Used to recover the flash image in the permanent side of the chip to the temporary side for both managed systems and power subsystems.
=item B<--retry=>I<count>
Specify number of times to retry the update if failure is detected. Default value is 2. Value of 0 can be used to indicate no retries.
=item B<-v|--version>
Displays the command's version.
@@ -159,7 +163,7 @@ To update the firmware on OpenPOWER machine specify the node name and the file p
rflash fs3 /firmware/8335_810.1543.20151021b_update.hpm
Print verbose message to rflash log file per node when updading firmware:
Print verbose message to rflash log file (/var/log/xcat/rflash/fs3.log) when updading firmware:
rflash fs3 /firmware/8335_810.1543.20151021b_update.hpm -V

7
xCAT-client/pods/man1/rinv.1.pod
View File

@@ -8,7 +8,7 @@ B<rinv> [B<-h>|B<--help>|B<-v>|B<--version>]
=head2 BMC/MPA specific:
B<rinv> I<noderange> {B<pci>|B<model>|B<serial>|B<asset>|B<vpd>|B<mprom>|B<deviceid>|B<guid>|B<firm>|B<diag>|B<bios>|B<mparom>|B<mac>|B<all>}
B<rinv> I<noderange> {B<pci>|B<model>|B<serial>|B<asset>|B<vpd>|B<mprom>|B<deviceid>|B<guid>|B<firm>|B<diag>|B<dimm>|B<bios>|B<mparom>|B<mac>|B<all>}
=head2 OpenPOWER server specific:
@@ -32,6 +32,11 @@ B<rinv> I<noderange> {B<mtm>|B<serial>|B<mac>|B<bios>|B<diag>|B<mprom>|B<mparom>
B<rinv> I<noderange> [B<-t>]
=head2 pdu specific:
B<rinv> I<noderange>
=head2 zVM specific:
B<rinv> I<noderange> [B<config>|B<all>]

26
xCAT-client/pods/man1/rmdef.1.pod
View File

@@ -8,7 +8,7 @@ B<rmdef> - Use this command to remove xCAT data object definitions.
B<rmdef> [B<-h>|B<--help>] [B<-t> I<object-types>]
B<rmdef> [B<-V>|B<--verbose>] [B<-a>|B<--all>] [B<-t> I<object-types>] [B<-o> I<object-names>]
[B<-f>|B<--force>] [I<noderange>]
[B<-f>|B<--force>] [B<-C>|B<--cleanup>] [I<noderange>]
=head1 DESCRIPTION
@@ -22,15 +22,23 @@ This command is used to remove xCAT object definitions that are stored in the xC
=item B<-a|--all>
Clear the whole xCAT database. A backup of the xCAT definitions should be saved before using this option. Once all the data is removed the xCAT daemon will no longer work. Most xCAT commands will fail.
In order to use xCAT commands again, you have two options. You can restore your database from your backup by switching to bypass mode, and running the restorexCATdb command.
You switch to bypass mode by setting the XCATBYPASS environmant variable. (ex. "export XCATBYPASS=yes")
A second option is to run xcatconfig -d. This will restore the initial setup of the database as when xCAT was initially installed.
You can then restart xcatd and run xCAT commands.
Clear the whole xCAT database. A backup of the xCAT definitions should be saved before using this option as the xCAT daemons will no longer work once cleared.
To restore:
=over 5
=item 1. B<export XCATBYPASS=1> and run the B<restorexCATdb> command.
or
=item 2. Run B<xcatconfig -d> which initializes the database the same as when xCAT was installed.
=back
=item B<-f|--force>
Use this with the all option as an extra indicator that ALL definitions are to be removed.
Use this with the B<--all> option as an extra indicator that ALL definitions are to be removed.
=item B<-h|--help>
@@ -48,6 +56,10 @@ A set of comma delimited object names.
A set of comma delimited object types.
=item B<-C|--cleanup>
Perform additional cleanup by running B<nodeset offline> on the objects specified in the I<noderange>.
=item B<-V|--verbose>
Verbose mode.

20
xCAT-client/pods/man1/rpower.1.pod
View File

@@ -12,6 +12,12 @@ B<rpower> [B<-h>|B<--help>|B<-v>|B<--version>]
B<rpower> I<noderange> [B<on>|B<off>|B<softoff>|B<reset>|B<boot>|B<stat>|B<state>|B<status>|B<wake>|B<suspend> [B<-w> I<timeout>] [B<-o>] [B<-r>]]
B<rpower> I<noderange> [B<pduon>|B<pduoff>|B<pdustat>|B<pdureset>]
=head2 OpenBMC specific:
B<rpower> I<noderange> [B<off>|B<on>|B<reset>|B<boot>|B<stat>|B<state>|B<status>]
=head2 PPC (with IVM or HMC) specific:
B<rpower> I<noderange> [B<--nodeps>] {B<of>}
@@ -44,7 +50,11 @@ B<rpower> I<noderange> [B<on>|B<onstandby>|B<off>|B<stat>|B<state>|B<sms>]
=head2 Blade specific:
B<rpower> I<noderange> [B<cycle>|B<softoff>]
B<rpower> I<noderange> [B<cycle>|B<softoff>]
=head2 Lenovo High-Density Server specific:
B<rpower> I<noderange> [B<on>|B<off>|B<reset>|B<boot>|B<reseat>]
=head2 zVM specific:
@@ -54,6 +64,10 @@ B<rpower> I<noderange> [B<on>|B<off>|B<reset>|B<stat>|B<softoff>]
B<rpower> I<noderange> [B<start>|B<stop>|B<restart>|B<pause>|B<unpause>|B<state>]
=head2 pdu specific:
B<rpower> I<noderange> [B<stat>|B<off>|B<on>|B<reset>]
=head1 DESCRIPTION
B<rpower> controls the power for a single or range of nodes, via the out-of-band path.
@@ -163,6 +177,10 @@ This option is recommended over B<cycle>.
Power off, then on.
=item B<reseat>
For Lenovo high-density servers, simulates unplugging and replugging the node into the chassis.
=item B<of>
Boot the node to open firmware console mode.

Some files were not shown because too many files have changed in this diff Show More