xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2025-06-13 01:40:26 +00:00
Code Issues Releases Wiki Activity

Synclist doc fixes (#6012)

Browse Source 
* Synclist doc fixes

* Review fixes
This commit is contained in:
Mark Gurevich
2019-02-21 21:18:35 -05:00
committed by yangsong
parent ba4aa7fd94
commit 2de616520b
11 changed files with 287 additions and 514 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_install.rst
View File

@ -1,9 +1,7 @@
Synchronizing Files during the installation process
----------------------------------------------------
---------------------------------------------------
The policy table must have the entry to allow syncfiles postscript to access the Management Node. Make sure this entry is in your table:
``tabdump policy`` ::
The **policy** table must have the entry to allow **syncfiles** postscript to access the Management Node. Make sure this entry is in your **policy** table: ::
#priority,name,host,commands,noderange,parameters,time,rule,comments,disable
.
@ -15,23 +13,21 @@ The policy table must have the entry to allow syncfiles postscript to access the
Hierarchy and Service Nodes
~~~~~~~~~~~~~~~~~~~~~~~~~~~
If using Service nodes to manage you nodes, you should make sure that the service nodes have been synchronized with the latest files from the Management Node before installing. If you have a group of compute nodes (compute) that are going to be installed that are serviced by SN1, then run the following before the install to sync the current files to SN1. Note: the noderange is the compute node names, updatenode will figure out which service nodes need updating.
If using Service nodes to manage you nodes, you should make sure that the service nodes have been synchronized with the latest files from the Management Node before installing. If you have a group of compute nodes **compute** that are going to be installed that are serviced by SN1, then run the following before the install to sync the current files to SN1.::
``updatenode compute -f``
updatenode compute -f
.. note:: ``updatenode`` will figure out which service nodes need updating.
Diskful installation
~~~~~~~~~~~~~~~~~~~~
The 'syncfiles' postscript is in the defaults section of the postscripts table. To enable the syn files postscript to sync files to the nodes during install the user need to do the following:
The **syncfiles** postscript is in the defaults section of the **postscripts** table. To enable the **syncfiles** postscript to sync files to the nodes during install the user need to do the following:
* Create the synclist file with the entries indicating which files should be synced. (refer to :ref:`The_Format_of_synclist_file_label` )
* Put the synclist into the proper location for the node type (refer to :ref:`the_localtion_of_synclist_file_for_updatenode_label`)
Make sure your postscripts table has the syncfiles postscript listed
``tabdump postscripts`` ::
Make sure your **postscripts** table has the syncfiles postscript listed::
#node,postscripts,postbootscripts,comments,disable
"xcatdefaults","syslog,remoteshell,syncfiles","otherpkgs",,
@ -39,9 +35,8 @@ Make sure your postscripts table has the syncfiles postscript listed
Diskless Installation
~~~~~~~~~~~~~~~~~~~~~
The diskless boot is similar with the diskful installation for the synchronizing files operation, except that the packimage commands will sync files to the root directories of image during the creating image process.
The diskless boot is similar with the diskful installation for the synchronizing files operation, except that the ``packimage`` command will sync files to the root directories of image during the creating image process.
Creating the synclist file as the steps in Diskful installation section, then the synced files will be synced to the os image during the packimage and mkdsklsnode commands running.
Creating the synclist file as the steps in Diskful installation section, then the synced files will be synced to the os image during the ``packimage`` and ``mkdsklsnode`` commands running.
Also the files will always be re-synced during the booting up of the diskless node.

20
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_overview.rst
View File

@ -1,24 +1,26 @@
Overview
--------
Synchronizing (sync) files to the nodes is a feature of xCAT used to distribute specific files from the management node to the new-deploying or deployed nodes.
Synchronizing (sync) files to the nodes is a feature of xCAT used to distribute specific files from the management node to the newly-deploying or deployed nodes.
This function is supported for diskful or RAMdisk-based diskless nodes. Generally, the specific files are usually the system configuration files for the nodes in the **/etc/directory**, like **/etc/hosts**, **/etc/resolve.conf**; it also could be the application programs configuration files for the nodes. The advantages of this function are: it can parallel sync files to the nodes or nodegroup for the installed nodes; it can automatically sync files to the newly-installing node after the installation. Additionally, this feature also supports the flexible format to define the synced files in a configuration file, called **'synclist'**.
This function is supported for diskful or RAMdisk-based diskless nodes. Generally, the specific files are usually the system configuration files for the nodes in the **/etc** directory, like **/etc/hosts**, **/etc/resolve.conf**; it also could be the application programs configuration files for the nodes. The advantages of this function are: it can parallel sync files to the nodes or nodegroup for the installed nodes; it can automatically sync files to the newly-installing node after the installation. Additionally, this feature also supports the flexible format to define the files to be synced in a configuration file, called "synclist".
The synclist file can be a common one for a group of nodes using the same profile or osimage, or can be the special one for a particular node. Since the location of the synclist file will be used to find the synclist file, the common synclist should be put in a given location for Linux nodes or specified by the osimage.
The synclist file can be a common one for a group of nodes using the same profile or osimage, or can be the unique for each particular node. Since the location of the synclist file will be used to find the synclist file, the common synclist should be put in a given location for Linux nodes or specified by the osimage.
``xdcp`` command supplies the basic Syncing File function. If the **'-F synclist'** option is specified in the ``xdcp`` command, it syncs files configured in the synclist to the nodes. If the **'-i PATH'** option is specified with **'-F synclist'**, it syncs files to the root image located in the PATH directory. (**Note: the '-i PATH' option is only supported for Linux nodes**)
``xdcp`` command supplies the basic Syncing File function. If the **-F synclist** option is specified in the ``xdcp`` command, it syncs files configured in the synclist to the nodes. If the **-i <install image path>** option is specified with **-F synclist**, it syncs files to the root image located in the <install image path> directory.
``xdcp`` supports hierarchy where service nodes are used. If a node is serviced by a service node, ``xdcp`` will sync the files to the service node first, then sync the files from service node to the compute node. The files are place in an intermediate directory on the service node defined by the SNsyncfiledir attribute in the site table. The default is **/var/xcat/syncfiles**.
.. note:: The **-i <install image path>** option is only supported for Linux nodes
``xdcp`` supports hierarchy where service nodes are used. If a node is serviced by a service node, ``xdcp`` will sync the files to the service node first, then sync the files from service node to the compute node. The files are placed in an intermediate directory on the service node defined by the **SNsyncfiledir** attribute in the **site** table. The default is **/var/xcat/syncfiles**.
Since ``updatenode -F`` calls the ``xdcp`` to handle the Syncing File function, the ``updatenode -F`` also supports the hierarchy.
For a new-installing nodes, the Syncing File action will be triggered when performing the postscripts for the nodes. A special postscript named **'syncfiles'** is used to initiate the Syncing File process.
For a new-installing nodes, the Syncing File action will be triggered when running the postscripts for the nodes. A special postscript named **syncfiles** is used to initiate the Syncing File process.
The postscript **'syncfiles'** is located in the **/install/postscripts/**. When running, it sends a message to the xcatd on the management node or service node, then the xcatd figures out the corresponding synclist file for the node and calls the ``xdcp`` command to sync files in the synclist to the node.
The postscript **syncfiles** is located in the **/install/postscripts/**. When running, it sends a message to the **xcatd** on the management node or service node, then the **xcatd** figures out the corresponding synclist file for the node and calls the ``xdcp`` command to sync files in the synclist to the node.
**If installing nodes in a hierarchical configuration, you must sync the Service Nodes first to make sure they are updated. The compute nodes will be sync'd from their service nodes. You can use the** ``updatenode <computenodes> -f`` **command to sync all the service nodes for range of compute nodes provided.**
If installing nodes in a hierarchical configuration, you must sync the service nodes first to make sure they are updated. The compute nodes will be synced from their service nodes. You can use the ``updatenode <computenodes> -f`` command to sync all the service nodes for range of compute nodes provided.
For an installed nodes, the Syncing File action happens when performing the ``updatenode -F`` or ``xdcp -F synclist`` command to update a nodes. If performing the ``updatenode -F``, it figures out the location of the synclist files for all the nodes and classify the nodes which using same synclist file and then calls the ``xdcp -F synclist`` to sync files to the nodes.
For an installed nodes, the Syncing File action happens when performing the ``updatenode -F`` or ``xdcp -F synclist`` command to update a nodes. While performing the ``updatenode -F``, it figures out the location of the synclist files for all the nodes and groups the nodes which will be using the same synclist file and then calls the ``xdcp -F synclist`` to sync files to the nodes.

15
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_periodically.rst
View File

@ -1,24 +1,15 @@
Run the Syncing File action periodically
-----------------------------------------
----------------------------------------
If the admins want to run the Syncing File action automatically or periodically, the ``xdcp -F``, ``xdcp -i -F`` and ``updatenode -F`` commands can be used in the script, crontab or FAM directly.
For example:
Use the cron daemon to sync files in the **/install/custom/<inst_type>/<distro>/<profile>.<os>.synclist** to the nodegroup 'compute' every 10 minutes by the xdcp command by adding this to crontab. : ::
Use the **cron** daemon to sync files in the **/install/custom/<inst_type>/<distro>/<profile>.<os>.synclist** to the nodegroup **compute** every 10 minutes with the **xdcp** command by adding this to **crontab**. : ::
*/10 * * * * root /opt/xcat/bin/xdcp compute -F /install/custom/<inst_type>/<distro>/<profile>.<distro>.synclist
Use the cron daemon to sync files for the nodegroup 'compute' every 10 minutes by updatenode command. ::
Use the **cron** daemon to sync files for the nodegroup **compute** every 10 minutes with ``updatenode`` command. ::
*/10 * * * * root /opt/xcat/bin/updatenode compute -F
** Related To do**
Add reference

41
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.rst
View File

@ -33,15 +33,15 @@ sync file **/etc/file2** to the file **/etc/file3** on the node (with different
/etc/file2 -> /etc/file3
sync file **/etc/file4** to the file **/etc/tmp/file5** on the node( different file name and directory). The directory will be automatically created for you. ::
sync file **/etc/file4** to the file **/etc/tmp/file5** on the node (different file name and directory). The directory will be automatically created for you. ::
/etc/file4 -> /etc/tmp/file5
sync the multiple files **/etc/file1**, **/etc/file2**, **/etc/file3**, ... to the directory **/tmp/etc** (**/tmp/etc** must be a directory when multiple files are synced at one time). If the directory does not exist, **xdcp** will create it. ::
sync the multiple files **/etc/file1**, **/etc/file2**, **/etc/file3**, ... to the directory **/tmp/etc** (**/tmp/etc** must be a directory when multiple files are synced at one time). If the directory does not exist, it will be created. ::
/etc/file1 /etc/file2 /etc/file3 -> /tmp/etc
sync file **/etc/file2** to the file /etc/file2 on the node ::
sync file **/etc/file2** to the file **/etc/file2** on the node ::
/etc/file2 -> /etc/
@ -49,7 +49,7 @@ sync all files in **/home/mikev** to directory **/home/mikev** on the node ::
/home/mikev/* -> /home/mikev/
Note: Don't try to sync files to the read only directory on the target node.
.. note:: Don't try to sync files to the read only directory on the target node.
An example of synclist file
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -59,7 +59,7 @@ Sync the file **/etc/common_hosts** to the two places on the target node: put on
/etc/common_hosts -> /etc/hosts
/etc/common_hosts -> /tmp/etc/hosts
Sync files in the directory **/tmp/prog1** to the directory **/prog1** on the target node, and the postfix **'.tmpl'** needs to be removed on the target node. (directory **/tmp/prog1/** contains two files: **conf1.tmpl** and **conf2.tmpl**) Following configuration entries should be added ::
Sync files in the directory **/tmp/prog1** to the directory **/prog1** on the target node, and the postfix **.tmpl** needs to be removed on the target node. (directory **/tmp/prog1/** contains two files: **conf1.tmpl** and **conf2.tmpl**) Following configuration entries should be added ::
/tmp/prog1/conf1.tmpl -> /prog1/conf1
/tmp/prog1/conf2.tmpl -> /prog1/conf2
@ -78,7 +78,7 @@ Sample synclist file ::
/tmp/* -> /tmp/
/etc/testfile -> /etc/
If the above syncfile is used by the **updatenode/xdcp** commands, or used in a node installation process, the following files will exist on the target node with the following contents. ::
If the above syncfile is used by the ``updatenode``/``xdcp`` commands, or used in a node installation process, the following files will exist on the target node with the following contents. ::
/etc/hosts(It has the same content with /etc/common_hosts on the MN)
/tmp/etc/hosts(It has the same content with /etc/common_hosts on the MN)
@ -104,29 +104,24 @@ The noderange can have several formats. Following examples show that **/etc/host
/etc/hosts -> (group1) /etc/hosts # The /etc/hosts file is synced to nodes in group1
/etc/hosts -> (group1,group2) /etc/hosts # The /etc/hosts file is synced to nodes in group1 and group2
postscript support
~~~~~~~~~~~~~~~~~~
Putting the filename.post in the **rsyncfile** to ``rsync`` to the node is required for hierarchical clusters. It is optional for non-hierarchical cluster.
Advanced synclist file features
'''''''''''''''''''''''''''''''
**EXECUTE**
The **EXECUTE** clause is used to list all the postscripts you would like to run after the files are sync'd, only if the file is updated. The files in this list must be added to the list of files to rsync. If noderange is used in the synclistfor the file listed in the **EXECUTE** clause, the script will only be exectuted on the nodes in that noderange.
The **EXECUTE** clause is used to list all the postsync scripts (<filename>.post) you would like to run after the files are synced, only if the file <filename> is updated. For hierarchical clusters, the postsync files in this list must also be added to the list of files to sync. It is optional for non-hierarchical clusters. If noderange is used in the synclist for the file listed in the **EXECUTE** clause, the postsync script will only be executed on the nodes in that noderange. The **EXECUTE** clause is not supported oif ``-r /usr/bin/scp`` option is used with ``xdcp`` or ``updatenode`` command.
**EXECUTEALWAYS**
The **EXECUTEALWAYS** clause is used to list all the postscripts you would like to run after the files are sync'd, whether or not any file is actually updated. The files in this list must be added to the list of files to rsync. If noderange is used in the synclist for the file listed in the **EXECUTEALWAYS** clause, the script will only be exectuted on the nodes in that noderange.
The **EXECUTEALWAYS** clause is used to list all the postsync scripts you would like to run after the files are synced, whether or not any file is actually updated. The files in this list must be added to the list of files to sync. If noderange is used in the synclist for the file listed in the **EXECUTEALWAYS** clause, the script will only be exectuted on the nodes in that noderange.
.. note:: The path to the file to EXECUTE or EXECUTEALWAYS, is the location of the file on the MN.
For example, your rsyncfile may look like this.::
For example, your syncfile may look like this.::
/tmp/share/file2 -> /tmp/file2
/tmp/share/file2.post -> /tmp/file2.post (required for hierarchical clusters)
/tmp/share/file3 -> /tmp/file3
/tmp/share/file3 -> /tmp/filex
/tmp/share/file3.post -> /tmp/file3.post (required for hierarchical clusters)
/tmp/myscript1 -> /tmp/myscript1
/tmp/myscript2 -> /tmp/myscript2
@ -138,7 +133,7 @@ For example, your rsyncfile may look like this.::
/tmp/myscript1
/tmp/myscript2
If **/tmp/file2** is updated on the node in **/tmp/file2**, then **/tmp/file2**.post is automatically run on that node. If **/tmp/file3** is updated on the node in **/tmp/filex**, then **/tmp/file3**.post is automatically run on that node.
If **/tmp/file2** is updated on the node in **/tmp/file2**, then **/tmp/file2.post** is automatically executed on that node. If **/tmp/file3** is updated on the node in **/tmp/filex**, then **/tmp/file3.post** is automatically executed on that node.
**APPEND**
@ -163,11 +158,11 @@ For example, your synclist file may look like this: ::
When you use the **APPEND** clause, the source file to the left of the arrow is appended to the file to the right of the arrow. In this example, **/etc/myappenddir/appendfile** is appended to **/etc/mysetup/setup** file, which must already exist on the node. The **/opt/xcat/share/xcat/scripts/xdcpappend.sh** is used to accomplish this.
The script creates a backup of the original file on the node in the directory defined by the site table `nodesyncfiledir` attribute, which is **/var/xcat/node/syncfiles** by default. To update the original file when using the function, you need to rsync a new original file to the node, removed the old original from the **/var/xcat/node/syncfiles/org** directory. If you want to cleanup all the files for the append function on the node, you can use ``xdsh -c`` flag. See man page for ``xdsh``.
The script creates a backup of the original file on the node in the directory defined by the **site** table **nodesyncfiledir** attribute, which is **/var/xcat/node/syncfiles** by default. To update the original file when using the function, you need to sync a new original file to the node, removed the old original from the **/var/xcat/node/syncfiles/org** directory. If you want to cleanup all the files for the append function on the node, you can use ``xdsh -c`` command. See man page for ``xdsh``.
**MERGE** (supported on Linux only).
The **MERGE** clause is used to append the contents of the input file to either the **/etc/passwd**, **/etc/shadow** or **/etc/group** files. They are the only supported files. You must not put the **/etc/passwd**, **/etc/shadow**, **/etc/group** files in an **APPEND** clause if using a **MERGE** clause. For these three files you should use the **MERGE** clause. The **APPEND** will add the information to the end of the file. The **MERGE** will add or replace the information and insure that there are no duplicate entries in these files.
The **MERGE** clause is used to append the contents of the input file to either the **/etc/passwd**, **/etc/shadow** or **/etc/group** files. They are the only supported files. You must not put the **/etc/passwd**, **/etc/shadow**, **/etc/group** files in an **APPEND** clause if using a **MERGE** clause. For these three files you should use the **MERGE** clause. The **APPEND** will add the information to the end of the file. The **MERGE** will add or replace the information and ensure that there are no duplicate entries in these files.
For example, your synclist file may look like this ::
@ -187,7 +182,7 @@ For example, your synclist file may look like this ::
/etc/mydir/mergeshadow -> /etc/shadow
/etc/mydir/mergegroup -> /etc/group
When you use the **MERGE** clause, the source file to the left of the arrow is merged into the file to the right of the arrow. It will replace any common userid's found in those files and add new userids. The **/opt/xcat/share/xcat/scripts/xdcpmerge.sh** is used to accomplish this.
When you use the **MERGE** clause, the source file to the left of the arrow is merged into the file to the right of the arrow. It will replace any common userids found in those files and add new userids. The **/opt/xcat/share/xcat/scripts/xdcpmerge.sh** is used to accomplish this.
.. note:: no order of execution may be assumed by the order of **EXECUTE, EXECUTEALWAYS, APPEND and MERGE** clauses in the synclist file.
@ -198,7 +193,7 @@ The location of synclist file for updatenode and install process
In the installation process or **updatenode** process, xCAT needs to figure out the location of the synclist file automatically, so the synclist should be put into the specified place with the proper name.
If the provisioning method for the node is an osimage name, then the path to the synclist will be read from the osimage definition `synclists` attribute. You can display this information by running the following command, supplying your osimage name. ::
If the provisioning method for the node is an osimage name, then the path to the synclist will be read from the osimage definition **synclists** attribute. You can display this information by running the following command, supplying your osimage name. ::
lsdef -t osimage -l <os>-<arch>-netboot-compute
@ -216,7 +211,7 @@ If the provisioning method for the node is an osimage name, then the path to the
rootimgdir=/install/netboot/<os>/<arch>/compute
**synclists=/install/custom/netboot/compute.synclist**
You can set the `synclist` path using the following command ::
You can set the synclist path using the following command ::
chdef -t osimage -o <os>-<arch>-netboot-compute synclists="/install/custom/netboot/compute.synclist
@ -229,11 +224,11 @@ If the provisioning method for the node is `install`, or `netboot` then the path
<profile>, <os> and <arch> are what you set for the node
For example:
The location of synclist file for the diskful installation of RedHat 7.5 with 'compute' as the profile ::
The location of synclist file for the diskful installation of RedHat 7.5 with **compute** as the profile ::
/install/custom/install/rh/compute.rhels7.5.synclist
The location of synclist file for the diskless netboot of SLES 12.3 with 'service' as the profile ::
The location of synclist file for the diskless netboot of SLES 12.3 with **service** as the profile ::
/install/custom/netboot/sles/service.sles12.3.synclist

8
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_updatenode.rst
View File

@ -1,7 +1,7 @@
Run the Syncing File action in the updatenode process
------------------------------------------------------
-----------------------------------------------------
If run ``updatenode`` command with -F option, it syncs files which configured in the synclist to the nodes. ``updatenode`` does not sync images, use ``xdcp -i -F`` option to sync images.
Running ``updatenode`` command with **-F** option, will sync files configured in the synclist file to the nodes. ``updatenode`` does not sync images, use ``xdcp -i -F`` command to sync images.
``updatenode`` can be used to sync files to to diskful or diskless nodes. ``updatenode`` cannot be used to sync files to statelite nodes.
@ -9,7 +9,7 @@ Steps to make the Syncing File working in the ``updatenode -F`` command:
#. Create the synclist file with the entries indicating which files should be synced. (refer to :ref:`The_Format_of_synclist_file_label`)
#. Put the synclist into the proper location (refer to :ref:`the_localtion_of_synclist_file_for_updatenode_label`).
#. Run the ``updatenode node -F`` command to initiate the Syncing File action.
#. Run the ``updatenode <noderange> -F`` command to initiate the Syncing File action.
Note: Since Syncing File action can be initiated by the ``updatenode -F`` flag, the ``updatenode -P`` does NOT support to re-run the **'syncfiles'** postscript, even if you specify the **'syncfiles'** postscript in the ``updatenode`` command line or set the **'syncfiles'** in the **postscripts.postscripts** attribute.
.. note:: Since Syncing File action can be initiated by the ``updatenode -F``, the ``updatenode -P`` does NOT support to re-run the **syncfiles** postscript, even if you specify the **syncfiles** postscript on the ``updatenode`` command line or set the **syncfiles** in the **postscripts.postscripts** attribute.

23
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_xdcp.rst
View File

@ -1,30 +1,31 @@
Run xdcp command to perform Syncing File action
------------------------------------------------
``xdcp`` command supplies three options **'-F' , -s, and '-i'** to support the Syncing File function.
``xdcp`` command supplies three options **-F** , **-s**, and **-i** to support the Syncing File function.
* -F|--File rsync input file
* -F|--File <synclist input file>
Specifies the full path to the synclist file that will be used to build the ``rsync`` command
Specifies the full path to the synclist file
* -s
* -s
Specifies to rsync to the service nodes only for the input compute noderange.
Specifies to sync to the service nodes only for the input compute noderange.
* -i|--rootimg install image for Linux
* -i | --rootimg <install image for Linux>
Specifies the full path to the install image on the local node. By default, if the -F option is specified, the **'rsync'** command is used to perform the syncing file function. For the ``rsync`` in ``xdcp``, only the ***ssh** remote shell is supported for ``rsync``. ``xdcp`` uses the **'-Lpotz'** as the default flags to call the rsync command. More flags for rsync command can be specified by adding **'-o'** flag to the call to ``xdcp``.
Specifies the full path to the install image on the local node.
For example: ::
By default, if the **-F** option is specified, the ``rsync`` command is used to perform the syncing file function. Only the **ssh** remote shell is supported for ``rsync``. ``xdcp`` uses the **-Lpotz** as the default flags to call the ``rsync`` command. More flags for ``rsync`` command can be specified by adding **-o** flag to the call to ``xdcp``.
For example you can use ``xdcp`` **-F** option to sync files which are listed in the **/install/custom/commonsyncfiles/<profile>.synclist** file to the node group named **compute**. If the node group **compute** is serviced by servicenodes, then the files will be automatically staged to the correct service nodes, and then synced to the compute nodes from those service nodes. The files will be stored in **/var/xcat/syncfiles** directory on the service nodes by default, or in the directory indicated in the **site.SNsyncfiledir** attribute. See **-s** option below. ::
Using xdcp '-F' option to sync files which are listed in the /install/custom/commonsyncfiles/<profile>.synclist directory to the node group named 'compute'. If the node group compute is serviced by servicenodes, then the files will be automatically staged to the correct service nodes, and then synced to the compute nodes from those service nodes. The files will be stored in /var/xcat/syncfiles directory on the service nodes by default, or in the directory indicated in the site.SNsyncfiledir attribute. See -s option below.
xdcp compute -F /install/custom/commonsynfiles/<profile>.synclist
For Linux nodes, using **xdcp '-i'** option with **'-F'** to sync files created in the **/install/custom/<inst_type>/<os><profile>.synclist** to the osimage in the directory **/install/<inst_type>/<os>/<arch>/<profile>/rootimg**: ::
For Linux nodes, you can use ``xdcp`` command **-i** option with **-F** to sync files specified in the **/install/custom/<inst_type>/<os><profile>.synclist** file to the osimage in the directory **/install/<inst_type>/<os>/<arch>/<profile>/rootimg**: ::
xdcp -i /install/<inst_type>/<os>/<arch>/<profile>/rootimg -F /install/custom/<inst_type>/<os>/<profile>.synclist
Using the **xdcp '-s'** option to sync the files only to the service nodes for the node group named 'compute'. The files will be placed in the default **/var/xcat/syncfiles** directory or in the directory as indicated in the **site.SNsyncfiledir** attribute. If you want the files synched to the same directory on the service node that they come from on the Management Node, set **site.SNsyncfiledir=/**. This can be setup before a node install, to have the files available to be synced during the install: ::
You can use the ``xdcp`` **-s** option to sync the files only to the service nodes for the node group named **compute**. The files will be placed in the default **/var/xcat/syncfiles** directory or in the directory as indicated in the **site.SNsyncfiledir** attribute. If you want the files synched to the same directory on the service node that they come from on the Management Node, set **site.SNsyncfiledir=/** attribute. This can be setup before a node install, to have the files available to be synced during the install: ::
xdcp compute -s -F /install/custom/<inst_type>/<os>/<profile>.synclist

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

@ -22,12 +22,12 @@ SYNOPSIS
\ **lsdef**\ [\ **-h | -**\ **-help**\ ] [\ **-t**\ \ *object-types*\ ] [\ **-i**\ \ *attr-list*\ ]
\ **lsdef**\ [\ **-V | -**\ **-verbose**\ ] [\ **-a | -**\ **-all**\ ] [\ **-S**\ ]
[\ **-t**\ \ *object-types*\ ] [\ **-o**\ \ *object-names*\ ] [\ **-z | -**\ **-stanza**\ ] [\ [\ **-i**\ \ *attr-list*\] | [\ **-l | -**\ **-long**\ ] | [\ **-s | -**\ **-short**\ ]]
[\ **-t**\ \ *object-types*\ ] [\ **-o**\ \ *object-names*\ ] [\ **-z | -**\ **-stanza**\ ] [\ **-i**\ \ *attr-list*\ | [\ **-l | -**\ **-long**\ ] | [\ **-s | -**\ **-short**\ ]]
[\ **-c | -**\ **-compress**\ ] [\ **-**\ **-osimage**\ ] [\ **-**\ **-nics**\ ] [[\ **-w**\ \ *attr*\ ==\ *val*\ ]
[\ **-w**\ \ *attr*\ =~\ *val*\ ] ...] [\ *noderange*\ ]
\ **lsdef**\ [\ **-a | -**\ **-all**\ ] [\ **-t**\ \ *object-types*\ ] [\ **-z | -**\ **-stanza**\ ]
[\ [\ **-i**\ \ *attr-list*\] | [\ **-l | -**\ **-long**\ ] | [\ **-s | -**\ **-short**\ ]] [\ **-**\ **-template**\ [\ *template-object-name*\ ]]
[\ **-i**\ \ *attr-list*\ | [\ **-l | -**\ **-long**\ ] | [\ **-s | -**\ **-short**\ ]] [\ **-**\ **-template**\ [\ *template-object-name*\ ]]
***********
@ -155,7 +155,7 @@ OPTIONS
\ **-z|-**\ **-stanza**\
Display output in stanza format. See the "xcatstanzafile" man page for details on using xCAT stanza files.
Display output in stanza format. See the "xcatstanzafile" man page for details on using xCAT stanza files. And default is to list complete object definition, use \ **-i**\ to specify the attribute scope.

52
docs/source/guides/admin-guides/references/man1/updatenode.1.rst
View File

@ -19,7 +19,7 @@ SYNOPSIS
********
\ **updatenode**\ \ *noderange*\ [\ **-V | -**\ **-verbose**\ ] [\ **-F | -**\ **-sync**\ ] [\ **-f | -**\ **-snsync**\ ] [\ **-r | -**\ **-node-rcp**\ [\ *full_path_to_remote_copy_command*\ ]] [\ **-S | -**\ **-sw**\ ] [\ **-l**\ \ *userID*\ ] [\ **-P | -**\ **-scripts**\ [\ *script1,script2...*\ ]] [\ **-s | -**\ **-sn**\ ] [\ **-A | -**\ **-updateallsw**\ ] [\ **-c | -**\ **-cmdlineonly**\ ] [\ **-d**\ \ *alt_source_dir*\ ] [\ **-**\ **-fanout**\ =\ *fanout_value*\ ] [\ **-t**\ \ *timeout*\ } [\ *attr=val*\ [\ *attr=val...*\ ]] [\ **-n | -**\ **-noverify**\ ]
\ **updatenode**\ \ *noderange*\ [\ **-V | -**\ **-verbose**\ ] [\ **-F | -**\ **-sync**\ ] [\ **-f | -**\ **-snsync**\ ] [\ **-r | -**\ **-node-rcp**\ [\ *node_remote_copy_command*\ ]] [\ **-S | -**\ **-sw**\ ] [\ **-l**\ \ *userID*\ ] [\ **-P | -**\ **-scripts**\ [\ *script1,script2...*\ ]] [\ **-s | -**\ **-sn**\ ] [\ **-A | -**\ **-updateallsw**\ ] [\ **-c | -**\ **-cmdlineonly**\ ] [\ **-d**\ \ *alt_source_dir*\ ] [\ **-**\ **-fanout**\ =\ *fanout_value*\ ] [\ **-t**\ \ *timeout*\ } [\ *attr=val*\ [\ *attr=val...*\ ]] [\ **-n | -**\ **-noverify**\ ]
\ **updatenode**\ \ **noderange**\ [\ **-k | -**\ **-security**\ ] [\ **-t**\ \ *timeout*\ ]
@ -37,7 +37,7 @@ DESCRIPTION
***********
The updatenode command is run on the xCAT management node and can be used
The \ **updatenode**\ command is run on the xCAT management node and can be used
to perform the following node updates:
@ -58,9 +58,9 @@ Update the ca and credentials for the service nodes.
The default behavior when no options are input to updatenode will be to run
The default behavior when no options are input to \ **updatenode**\ will be to run
the following options \ **-S**\ , \ **-P**\ and \ **-F**\ options in this order.
If you wish to limit updatenode to specific
If you wish to limit \ **updatenode**\ to specific
actions you can use combinations of the \ **-S**\ , \ **-P**\ , and \ **-F**\ flags.
For example, If you just want to synchronize configuration file you could
@ -74,7 +74,7 @@ The flag \ **-f**\ (\ **-**\ **-snsync**\ ) can NOT be used together with \ **-
Note: In a large cluster environment the updating of nodes in an ad hoc
manner can quickly get out of hand, leaving the system administrator with
a very confusing environment to deal with. The updatenode command is
a very confusing environment to deal with. The \ **updatenode**\ command is
designed to encourage users to handle cluster updates in a manner that
is recorded and easily repeatable.
@ -93,14 +93,14 @@ The basic process for distributing and synchronizing nodes is:
\* Run the updatenode command to update the nodes.
\* Run the \ **updatenode**\ command to update the nodes.
Files may be distributed and synchronized for both diskless and
diskful nodes. Syncing files to NFS-based statelite nodes is not supported.
More information on using the synchronization file function is in the following doc: Using_Updatenode.
More information on using the synchronization file function is in the following document: <https://xcat-docs.readthedocs.io/en/stable/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_updatenode.html>
Create the synclist file
------------------------
@ -111,9 +111,7 @@ where the files should be synced to. In the synclist file, each
line is an entry which describes the location of the source files
and the destination location for the files on the target node.
For more information on creating your synclist files and where to put them, read:
Sync-ing_Config_Files_to_Nodes
For more information on creating your synclist files and where to put them, read here: <https://xcat-docs.readthedocs.io/en/stable/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.html>
Run updatenode to synchronize the files
@ -382,12 +380,12 @@ OPTIONS
\ **-F|-**\ **-sync**\
Specifies that file synchronization should be
performed on the nodes. rsync/scp and ssh must
performed on the nodes. \ **rsync/scp**\ and \ **ssh**\ must
be installed and configured on the nodes.
The function is not supported for NFS-based statelite installations.
For NFS-based statelite installations to sync files, you should use the
read-only option for files/directories listed in
litefile table with source location specified in the litetree table.
\ **litefile**\ table with source location specified in the \ **litetree**\ table.
@ -396,33 +394,33 @@ OPTIONS
Specifies that file synchronization should be
performed to the service nodes that service the
nodes in the noderange. This updates the service
nodes with the data to sync to the nodes. rsync/scp and ssh must
nodes with the data to sync to the nodes. \ **rsync/scp**\ and \ **ssh**\ must
be installed and configured on the service nodes.
For hierarchy, this optionally can be done before syncing the files
to the nodes with the -F flag. If the -f flag is not used, then
the -F flag will sync the servicenodes before the nodes automatically.
to the nodes with the \ **-F**\ flag. If the \ **-f**\ flag is not used, then
the \ **-F**\ flag will sync the service nodes before the nodes automatically.
When installing nodes in a hierarchical cluster, this flag should be
used to sync the service nodes before the install, since the files will
be sync'd from the service node by the syncfiles postscript during the
be synced from the service node by the \ **syncfiles**\ postscript during the
install.
The function is not supported for NFS-based statelite installations.
For statelite installations to sync files, you should use the
read-only option for files/directories listed in
litefile table with source location specified in the litetree table.
\ **litefile**\ table with source location specified in the \ **litetree**\ table.
[\ **-r | -**\ **-node-rcp**\ [\ *full_path_to_remote_copy_command*\ ]]
[\ **-r | -**\ **-node-rcp**\ [\ *node_remote_copy_command*\ ]]
Specifies the full path of the remote copy command used for syncing files to node targets, such as "/usr/bin/rsync" or "/usr/bin/scp". If not specified, rsync will be used by default.
Specifies the full path of the remote copy command used for syncing files to node targets, such as \ **/usr/bin/rsync**\ or \ **/usr/bin/scp**\ . If not specified, \ **rsync**\ will be used by default.
Notice: The synclist for "-r /usr/bin/scp" has some differences with "-r /usr/bin/rsync":
Note: The synclist processing for \ **-r /usr/bin/scp**\ has some differences with \ **-r /usr/bin/rsync**\ :
1) the \`\`EXECUTE\`\` clause is not supported in "-r /usr/bin/scp"
1) the \ **EXECUTE**\ clause in synclist file is not supported with \ **-r /usr/bin/scp**\ flag
2) if the destination directory specified in synclist is an existing file on target node, "updatenode -r /usr/bin/scp" will fail with \`\`scp: <destination directory>: Not a directory\`\`
2) if the destination directory specified in synclist file is an existing file on target node, \ **updatenode -r /usr/bin/scp**\ will fail with "scp: <destination directory>: Not a directory"
3) if the destination file specified in synclist is an existing directory on target node, "updatenode -r /usr/bin/scp" will fail with \`\`scp: <destination file>: Is a directory\`\`
3) if the destination file specified in synclist file is an existing directory on target node, \ **updatenode -r /usr/bin/scp**\ will fail with "scp: <destination file>: Is a directory"
@ -461,8 +459,8 @@ OPTIONS
\ **-P|-**\ **-scripts**\
Specifies that postscripts and postbootscripts should be run on the nodes.
updatenode -P syncfiles is not supported. The syncfiles postscript can only
be run during install. You should use updatenode <noderange> -F instead.
File sync with \ **updatenode -P syncfiles**\ is not supported. The \ **syncfiles**\ postscript can only
be run during install. You should use \ **updatenode -F**\ instead.
@ -546,14 +544,14 @@ EXAMPLES
3. Running updatenode -P with the syncfiles postscript is not supported. You should use updatenode -F instead.
3. Running \ **updatenode -P**\ with the \ **syncfiles**\ postscript is not supported. You should use \ **updatenode -F**\ instead.
Do not run:
.. code-block:: perl
updatenode clstrno1 -P syncfiles
updatenode clstrn01 -P syncfiles
Run:

325
docs/source/guides/admin-guides/references/man1/xdcp.1.rst
View File

@ -11,7 +11,7 @@ xdcp.1
************
\ **xdcp**\ - Concurrently copies files to or from multiple nodes. In addition, provides an option to use rsync to update the files on the nodes, or to an installation image on the local node.
\ **xdcp**\ - Concurrently copies files to or from multiple nodes. In addition, provides an option to use \ **rsync**\ to update the files on the managed nodes, or to an installation image on the local node.
****************
@ -19,13 +19,13 @@ xdcp.1
****************
\ **xdcp**\ \ *noderange*\ [[\ **-B**\ | \ **-**\ **-bypass**\ ] [\ **-f**\ \ *fanout*\ ] [\ **-L**\ ] [\ **-l**\ \ *userID*\ ] [\ **-o**\ \ *node_options*\ ] [\ **-p**\ ] [\ **-P**\ ] [\ **-r**\ \ *node_remote_shell*\ ] [\ **-R**\ ] [\ **-t**\ \ *timeout*\ ] [\ **-T**\ ] [\ **-v**\ ] [\ **-q**\ ] [\ **-X**\ \ *env_list*\ ] \ *sourcefile.... targetpath*\
\ **xdcp**\ \ *noderange*\ [[\ **-B**\ | \ **-**\ **-bypass**\ ] [\ **-f**\ \ *fanout*\ ] [\ **-L**\ ] [\ **-l**\ \ *userID*\ ] [\ **-o**\ \ *node_options*\ ] [\ **-p**\ ] [\ **-P**\ ] [\ **-r**\ \ *node remote copy command] [\ \*\*-R\*\*\ ] [\ \*\*-t\*\*\ \ \*timeout\*\ ] [\ \*\*-T\*\*\ ] [\ \*\*-v\*\*\ ] [\ \*\*-q\*\*\ ] [\ \*\*-X\*\*\ \ \*env_list\*\ ] \ \*sourcefile.... targetpath\*\ *\
\ **xdcp**\ \ *noderange*\ [\ **-F**\ \ *rsync input file*\ ]
\ **xdcp**\ \ *noderange*\ [\ **-F**\ Irsynclist input file>] [\ **-r**\ \ *node remote copy command*\ ]
\ **xdcp**\ \ *computenoderange*\ [\ **-s**\ \ **-F**\ \ *rsync input file*\ ]
\ **xdcp**\ \ *computenoderange*\ [\ **-s**\ \ **-F**\ \ *synclist input file*\ ] [\ **-r**\ \ *node remote copy command*\ ]
\ **xdcp**\ [\ **-i**\ \ *path to install image*\ ] [\ **-F**\ \ *rsync input file*\ ]
\ **xdcp**\ [\ **-i**\ \ *install image*\ ] [\ **-F**\ \ *synclist input file*\ ] [\ **-r**\ \ *node remote copy command*\ ]
\ **xdcp**\ [\ **-h**\ | \ **-V**\ | \ **-q**\ ]
@ -36,33 +36,32 @@ xdcp.1
The \ **xdcp**\ command concurrently copies files to or from remote target
nodes. The command issues a remote copy command for each node or device specified. When files are pulled from a target, they are placed into the target_path with the name of the
remote node or device appended to the copied source_file name. The
/usr/bin/rcp command is the model for syntax and security.
If using hierarchy, then xdcp runs on the service node that is servicing the compute node. The file will first be copied to the path defined in the site table, SNsyncfiledir attribute, or the default path /var/xcat/syncfiles on the service node, if the attribute is not defined. The -P flag will not automatically copy
nodes. The command issues a remote copy command for each node or device specified. When files are pulled from a target, they are placed into the \ *targetpath*\ with the name of the
remote node or device appended to the copied \ *sourcefile*\ name. The
\ **/usr/bin/rcp**\ command is the model for syntax and security.
If using hierarchy, then \ **xdcp**\ runs on the service node that is servicing the compute node. The file will first be copied to the path defined in the site table, \ **SNsyncfiledir**\ attribute, or the default path \ **/var/xcat/syncfiles**\ on the service node, if the attribute is not defined. The \ **-P**\ flag will not automatically copy
the files from the compute node to the Management node, hierarchically. There
is a two step process, see \ **-P**\ flag.
If the Management Node is target node, it must be defined in the xCAT database with nodetype=mn. When the \ **xdcp**\ command runs the Management Node as the target, it does not use remote commands but uses the local OS copy (\ **cp**\ ) command.
If the Management Node is target node, it must be defined in the xCAT database with \ **nodetype=mn**\ . When the \ **xdcp**\ command runs with the Management Node as the target, it does not use remote commands but uses the local OS copy (\ **cp**\ ) command.
\ **REMOTE**\ \ **USER**\ :
A user_ID can be specified for the remote copy command. Remote user
specification is identical for the \ **xdcp**\ and \ **xdsh**\ commands. See the \ **xdsh**\
command for more information.
A user_ID can be specified for the remote copy command. Remote user
specification is identical for the \ **xdcp**\ and \ **xdsh**\ commands.
See the \ **xdsh**\ command for more information.
\ **REMOTE**\ \ **COMMAND**\ \ **COPY**\ :
The \ **xdcp**\ command uses a configurable remote copy command to execute
remote copies on remote targets. Support is explicitly provided for
Remote Shell rcp command, the OpenSSH scp command and the
/usr/bin/rsync command.
Remote Shell \ **rcp**\ command, the OpenSSH \ **scp**\ command and the
\ **/usr/bin/rsync**\ command.
For node targets, the remote copy command is determined by the follow-
ing order of precedence:
For node targets, the remote copy command is determined by the following order of precedence:
1. The \ **-r**\ flag.
2. The \ **/usr/bin/scp**\ command.
2. The \ **/usr/bin/rsync**\ command.
\ **COMMAND**\ \ **EXECUTIONS**\ :
@ -75,10 +74,10 @@ appropriate.
A timeout value for remote copy command execution can be specified with
the \ **-t**\ flag or DSH_TIMEOUT environment variable. If any remote target
does not respond within the timeout value, the xdcp command displays an
does not respond within the timeout value, the \ **xdcp**\ command displays an
error message and exits.
The \ **-T**\ flag provides diagnostic trace information for dcp command execution. Default settings and the actual remote copy commands that are executed to the remote targets are displayed.
The \ **-T**\ flag provides diagnostic trace information for \ **xdcp**\ command execution. Default settings and the actual remote copy commands that are executed to the remote targets are displayed.
The \ **xdcp**\ command can be executed silently using the \ **-Q**\ flag; no target
standard output or standard error is displayed.
@ -94,170 +93,45 @@ standard output or standard error is displayed.
Specifies the complete path for the file to be copied to or
from the target. Multiple files can be specified. When used
with the -R flag, only a single directory can be specified.
When used with the -P flag, only a single file can be specified.
with the \ **-R**\ flag, only a single directory can be specified.
When used with the \ **-P**\ flag, only a single file can be specified.
\ *targetpath*\
If one source_file file, then it specifies the file to copy the source_file
file to on the target. If multiple source_file files, it specifies
the directory to copy the source_file files to on the target.
If the -P flag is specified, the target_path is the local host location
If one source file, then it specifies the file to copy the source
file to on the target. If multiple source files, it specifies
the directory to copy the source files to on the target.
If the \ **-P**\ flag is specified, the \ *targetpath*\ is the local host location
for the copied files. The remote file directory structure is recreated
under target_path and the remote target name is appended
to the copied source_file name in the target_path directory.
Note: the targetpath directory must exist.
under \ *targetpath*\ and the remote target name is appended
to the copied \ *sourcefile*\ name in the \ *targetpath*\ directory.
Note: the \ *targetpath*\ directory must exist.
\ **-B | -**\ **-bypass**\
Runs in bypass mode, use if the xcatd daemon is hung.
Runs in bypass mode, use if the \ **xcatd**\ daemon is not responding.
\ **-f | -**\ **-fanout**\ \ *fanout_value*\
Specifies a fanout value for the maximum number of concur-
rently executing remote shell processes. Serial execution
Specifies a fanout value for the maximum number of concurrently executing remote shell processes. Serial execution
can be specified by indicating a fanout value of \ **1**\ .
If \ **-f**\ is not specified, a default fanout value of \ **64**\ is used.
\ **-F | -**\ **-File**\ \ *rsync input file*\
\ **-F | -**\ **-File**\ \ *synclist input file*\
Specifies the path to the file that will be used to
build the \ **rsync**\ command.
The format of the input file is as follows, each line contains:
The format of the input file is described here: <https://xcat-docs.readthedocs.io/en/stable/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.html>
.. code-block:: perl
<path to source file1> <path to source file2> ... -> < path to destination file/directory>
or
.. code-block:: perl
<path to source file> -> <path to destination file>
or
.. code-block:: perl
<path to source file> -> <path to destination directory ( must end in /)>
For example:
.. code-block:: perl
/etc/password /etc/hosts -> /etc
/tmp/file2 -> /tmp/file2
/tmp/file2 -> /tmp/
/tmp/filex -> /tmp/source/filey
/etc/* -> /etc/
\ **Running postscripts after files are sync'd to the nodes**\ :
After you define the files to rsync, you can add an \ **EXECUTE:**\ clause in the synclist file. The \ **EXECUTE:**\ clause will list all the postscripts that you would like to run after the files are sync'd to the node.
The postscript file must be of the form \ **filename.post**\ , where the <filename>
is the <filename> is the from <filename>, reside in the same
directory as \ **filename**\ , and be executable.
If the file \ **filename**\ is rsync'd to the node, then the \ **filename.post**\
will automatically be run on the node.
If the file \ **filename**\ is not updated on the node, the \ **filename.post**\ will not be run.
Putting the \ **filename.post**\ in the file list to rsync to the node is required
for hierarchical clusters. It is optional for non-hierarchical clusters.
Another option is the \ **EXECUTEALWAYS:**\ clause in the synclist file. The \ **EXECUTEALWAYS:**\ will list all the postscripts that you would like to run after the files are sync'd to the nodes. These scripts will run whether or not any files are sync'd to the nodes. The scripts have no special format, but must contain the fully qualified path.
The scripts must be also added to the file list to rsync to the node for hierarchical clusters. It is optional for non-hierarchical clusters.
For example, your rsynclist file may look like this:
.. code-block:: perl
/tmp/share/file2 -> /tmp/file2
/tmp/share/file2.post -> /tmp/file2.post
/tmp/share/file3 -> /tmp/filex
/tmp/share/file3.post -> /tmp/file3.post
/tmp/myscript -> /tmp/myscript
# the below are postscripts
EXECUTE:
/tmp/share/file2.post
/tmp/share/file3.post
EXECUTEALWAYS:
/tmp/myscript
If /tmp/file2 and /tmp/file3 update /tmp/file2 and /tmp/filex on the node, then the postscripts /tmp/file2.post and /tmp/file3.post are automatically run on
the node. /tmp/myscript will always be run on the node.
Another option is the \ **APPEND:**\ clause in the synclist file. The \ **APPEND:**\ clause is used to append the contents of the input file to an existing file on the node. The file to append \ **must**\ already exist on the node and not be part of the synclist that contains the \ **APPEND:**\ clause.
For example, your rsynclist file may look like this:
.. code-block:: perl
/tmp/share/file2 -> /tmp/file2
/tmp/share/file2.post -> /tmp/file2.post
/tmp/share/file3 -> /tmp/filex
/tmp/share/file3.post -> /tmp/file3.post
/tmp/myscript -> /tmp/myscript
# the below are postscripts
EXECUTE:
/tmp/share/file2.post
/tmp/share/file3.post
EXECUTEALWAYS:
/tmp/myscript
APPEND:
/etc/myappenddir/appendfile -> /etc/mysetup/setup
/etc/myappenddir/appendfile2 -> /etc/mysetup/setup2
When you use the append script, the file (left) of the arrow is appended to the file right of the arrow. In this example, /etc/myappenddir/appendfile is appended to /etc/mysetup/setup file, which must already exist on the node. The /opt/xcat/share/xcat/scripts/xdcpappend.sh is used to accomplish this.
Another option is the \ **MERGE:**\ clause in the synclist file. The \ **MERGE:**\ clause is used to append the contents of the input file to /etc/passwd, /etc/group, or /etc/shadow on a Linux node. It is only supported for those files and only on Linux. You must not use both the APPEND and MERGE funcion for these three files. The processing could end up not creating the file you desire. The MERGE function is the preferred method, because APPEND only adds to the file. MERGE will add to the file but also insure there are no duplicate entries.
For example, your rsynclist file may look like this:
/tmp/share/file2 -> /tmp/file2
/tmp/share/file2.post -> /tmp/file2.post
/tmp/share/file3 -> /tmp/filex
/tmp/share/file3.post -> /tmp/file3.post
/tmp/myscript -> /tmp/myscript
# the below are postscripts
EXECUTE:
/tmp/share/file2.post
/tmp/share/file3.post
EXECUTEALWAYS:
/tmp/myscript
APPEND:
/custom/mypasswd -> /etc/passwd
/custom/mygroups -> /etc/group
/custom/myshadow -> /etc/shadow
Note: no order can be assumed by the order that the EXECUTE,EXECUTEALWAYS and APPEND clause fall in the synclist file.
For more information on syncing files to node, read Sync-ing_Config_Files_to_Nodes
On Linux rsync always uses ssh remoteshell. On AIX, ssh or rsh is used depending on the site.useSSHonAIX attribute.
On Linux \ **rsync**\ always uses ssh remoteshell. On AIX, \ **ssh**\ or \ **rsh**\ is used depending on the \ **site.useSSHonAIX**\ table attribute.
@ -269,7 +143,7 @@ standard output or standard error is displayed.
\ **-i | -**\ **-rootimg**\ \ *install image*\
Specifies the path to the install image on the local Linux node.
Specifies the path to the install image on the local Linux node.
@ -277,7 +151,7 @@ standard output or standard error is displayed.
Specifies options to pass to the remote shell command for
node targets. The options must be specified within double
quotation marks ("") to distinguish them from \ **xdsh**\ options.
quotation marks ("") to distinguish them from \ **xdcp**\ options.
@ -291,14 +165,14 @@ standard output or standard error is displayed.
\ **-P | -**\ **-pull**\
Pulls (copies) the files from the targets and places them in
the target_path directory on the local host. The target_path
the \ *targetpath*\ directory on the local host. The \ *targetpath*\
must be a directory. Files pulled from remote machines have
._target appended to the file name to distinguish between
them. When the \ **-P**\ flag is used with the \ **-R**\ flag, ._target is
\ **._target**\ appended to the file name to distinguish between
them. When the \ **-P**\ flag is used with the \ **-R**\ flag, \ **._target**\ is
appended to the directory. Only one file per invocation of the
xdcp pull command can be pulled from the specified targets.
Hierarchy is not automatically support yet. You must first pull
the file to the Service Node and then pull the file to the Management
\ **xdcp**\ pull command can be pulled from the specified targets.
In hierarchy, you must first pull
the file to the service node and then pull the file to the management
node.
@ -313,10 +187,17 @@ standard output or standard error is displayed.
\ **-r | -**\ **-node-rcp**\ \ *node_remote_copy*\
\ **-r | -**\ **-node-rcp**\ \ *node remote copy command*\
Specifies the full path of the remote copy command used
for remote command execution on node targets.
Specifies the full path of the remote copy command used for syncing files to node targets, such as \ **/usr/bin/rsync**\ or \ **/usr/bin/scp**\ . If not specified, \ **rsync**\ will be used by default.
Note: The synclist processing for \ **-r /usr/bin/scp**\ has some differences with \ **-r /usr/bin/rsync**\ :
1) the \ **EXECUTE**\ clause in synclist file is not supported with \ **-r /usr/bin/scp**\ flag
2) if the destination directory specified in synclist file is an existing file on target node, \ **xdcp -r /usr/bin/scp**\ will fail with "scp: <destination directory>: Not a directory"
3) if the destination file specified in synclist file is an existing directory on target node, \ **xdcp -r /usr/bin/scp**\ will fail with "scp: <destination file>: Is a directory"
@ -325,8 +206,7 @@ standard output or standard error is displayed.
Recursively copies files from a local directory to the remote
targets, or when specified with the \ **-P**\ flag, recursively pulls
(copies) files from a remote directory to the local host. A
single source directory can be specified using the source_file
parameter.
single source directory can be specified using the \ *sourcefile*\ parameter.
@ -334,8 +214,8 @@ standard output or standard error is displayed.
Will only sync the files listed in the synclist (\ **-F**\ ), to the service
nodes for the input compute node list. The files will be placed in the
directory defined by the site.SNsyncfiledir attribute, or the default
/var/xcat/syncfiles directory.
directory defined by the \ **site.SNsyncfiledir**\ table attribute, or the default
\ **/var/xcat/syncfiles**\ directory.
@ -447,9 +327,8 @@ standard output or standard error is displayed.
\ **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.
@ -463,13 +342,12 @@ Exit values for each remote copy command execution are displayed in
messages from the xdcp command, if the remote copy command exit value is
non-zero. A non-zero return code from a remote copy command indicates
that an error was encountered during the remote copy. If a remote copy
command encounters an error, execution of the remote copy on that tar-
get is bypassed.
command encounters an error, execution of the remote copy on that target is bypassed.
The xdcp command exit code is 0, if the xdcp command executed without
The \ **xdcp**\ command exit code is 0, if the \ **xdcp**\ command executed without
errors and all remote copy commands finished with exit codes of 0. If
internal xdcp errors occur or the remote copy commands do not complete
successfully, the xdcp command exit value is greater than 0.
internal \ **xdcp**\ errors occur or the remote copy commands do not complete
successfully, the \ **xdcp**\ command exit value is greater than 0.
****************
@ -530,7 +408,7 @@ host as /var/log._target, enter:
3. To copy /localnode/smallfile and /tmp/bigfile to /tmp on node1
3. To copy /localnode/smallfile and /tmp/bigfile to B/tmp on node1
using rsync and input -t flag to rsync, enter:
@ -587,15 +465,23 @@ from the local host to node1 in the cluster, enter:
8. To rsync the /etc/hosts file to your compute nodes:
Create a rsync file /tmp/myrsync, with this line:
First create a syncfile /tmp/myrsync, with this line:
.. code-block:: perl
/etc/hosts -> /etc/hosts
/etc/hosts -> /etc/hosts
or
/etc/hosts -> /etc/ (last / is required)
Run:
.. code-block:: perl
/etc/hosts -> /etc/ (last / is required)
Then run:
.. code-block:: perl
@ -607,11 +493,15 @@ from the local host to node1 in the cluster, enter:
9. To rsync all the files in /home/mikev to the compute nodes:
Create a rsync file /tmp/myrsync, with this line:
First create a rsync file /tmp/myrsync, with this line:
/home/mikev/\* -> /home/mikev/ (last / is required)
Run:
.. code-block:: perl
/home/mikev/* -> /home/mikev/ (last / is required)
Then run:
.. code-block:: perl
@ -621,18 +511,25 @@ from the local host to node1 in the cluster, enter:
10. To rsync to the compute nodes, using service nodes, the command will first
rsync the files to the /var/xcat/syncfiles directory on the service nodes and then rsync the files from that directory to the compute nodes. The /var/xcat/syncfiles default directory on the service nodes, can be changed by putting a directory value in the site table SNsyncfiledir attribute.
10. To rsync to the compute nodes, using service nodes:
Create a rsync file /tmp/myrsync, with this line:
First create a rsync file /tmp/myrsync, with this line:
.. code-block:: perl
/etc/hosts /etc/passwd -> /etc
/etc/hosts /etc/passwd -> /etc
or
/etc/hosts /etc/passwd -> /etc/
Run:
.. code-block:: perl
/etc/hosts /etc/passwd -> /etc/
Then run:
.. code-block:: perl
@ -640,18 +537,20 @@ rsync the files to the /var/xcat/syncfiles directory on the service nodes and t
xdcp compute -F /tmp/myrsync
to update the Compute Nodes
11. To rsync to the service nodes in preparation for rsyncing the compute nodes
during an install from the service node.
Create a rsync file /tmp/myrsync, with this line:
First create a rsync file /tmp/myrsync, with this line:
/etc/hosts /etc/passwd -> /etc
Run:
.. code-block:: perl
/etc/hosts /etc/passwd -> /etc
Then run:
.. code-block:: perl
@ -659,19 +558,21 @@ during an install from the service node.
xdcp compute -s -F /tmp/myrsync
to sync the service node for compute
12. 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:
First create a rsync file /tmp/myrsync, with these line:
/etc/file1 -> /etc/filex
/etc/file2 -> /etc/filey
.. code-block:: perl
Run:
/etc/file1 -> /etc/filex
/etc/file2 -> /etc/filey
Then run:
.. code-block:: perl
@ -685,11 +586,15 @@ during an install from the service node.
13. To rsync files in the Linux image at /install/netboot/fedora9/x86_64/compute/rootimg on the MN:
Create a rsync file /tmp/myrsync, with this line:
First create a rsync file /tmp/myrsync, with this line:
/etc/hosts /etc/passwd -> /etc
Run:
.. code-block:: perl
/etc/hosts /etc/passwd -> /etc
Then run:
.. code-block:: perl

38
xCAT-client/pods/man1/updatenode.1.pod
View File

@ -18,7 +18,7 @@ B<updatenode> [B<-h>|B<--help>] [B<-v>|B<--version>]
=head1 DESCRIPTION
The updatenode command is run on the xCAT management node and can be used
The B<updatenode> command is run on the xCAT management node and can be used
to perform the following node updates:
=over 3
@ -38,9 +38,9 @@ Update the ca and credentials for the service nodes.
=back
The default behavior when no options are input to updatenode will be to run
The default behavior when no options are input to B<updatenode> will be to run
the following options B<-S>, B<-P> and B<-F> options in this order.
If you wish to limit updatenode to specific
If you wish to limit B<updatenode> to specific
actions you can use combinations of the B<-S>, B<-P>, and B<-F> flags.
For example, If you just want to synchronize configuration file you could
@ -55,7 +55,7 @@ The flag B<-f> (B<--snsync>) can NOT be used together with B<-S>, B<-P>, and B<-
Note: In a large cluster environment the updating of nodes in an ad hoc
manner can quickly get out of hand, leaving the system administrator with
a very confusing environment to deal with. The updatenode command is
a very confusing environment to deal with. The B<updatenode> command is
designed to encourage users to handle cluster updates in a manner that
is recorded and easily repeatable.
@ -72,14 +72,14 @@ Create a synclist file.
Indicate the location of the synclist file.
=item *
Run the updatenode command to update the nodes.
Run the B<updatenode> command to update the nodes.
=back
Files may be distributed and synchronized for both diskless and
diskful nodes. Syncing files to NFS-based statelite nodes is not supported.
More information on using the synchronization file function is in the following doc: Using_Updatenode.
More information on using the synchronization file function is in the following document: <https://xcat-docs.readthedocs.io/en/stable/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_updatenode.html>
=head3 Create the synclist file
@ -88,9 +88,7 @@ where the files should be synced to. In the synclist file, each
line is an entry which describes the location of the source files
and the destination location for the files on the target node.
For more information on creating your synclist files and where to put them, read:
Sync-ing_Config_Files_to_Nodes
For more information on creating your synclist files and where to put them, read here: <https://xcat-docs.readthedocs.io/en/stable/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.html>
=head3 Run updatenode to synchronize the files
@ -289,12 +287,12 @@ Used to specify a source directory other than the standard lpp_source directory
=item B<-F|--sync>
Specifies that file synchronization should be
performed on the nodes. rsync/scp and ssh must
performed on the nodes. B<rsync/scp> and B<ssh> must
be installed and configured on the nodes.
The function is not supported for NFS-based statelite installations.
For NFS-based statelite installations to sync files, you should use the
read-only option for files/directories listed in
litefile table with source location specified in the litetree table.
B<litefile> table with source location specified in the B<litetree> table.
=item B<-f|--snsync>
@ -302,19 +300,19 @@ litefile table with source location specified in the litetree table.
Specifies that file synchronization should be
performed to the service nodes that service the
nodes in the noderange. This updates the service
nodes with the data to sync to the nodes. rsync/scp and ssh must
nodes with the data to sync to the nodes. B<rsync/scp> and B<ssh> must
be installed and configured on the service nodes.
For hierarchy, this optionally can be done before syncing the files
to the nodes with the -F flag. If the -f flag is not used, then
the -F flag will sync the servicenodes before the nodes automatically.
to the nodes with the B<-F> flag. If the B<-f> flag is not used, then
the B<-F> flag will sync the service nodes before the nodes automatically.
When installing nodes in a hierarchical cluster, this flag should be
used to sync the service nodes before the install, since the files will
be sync'd from the service node by the syncfiles postscript during the
be synced from the service node by the B<syncfiles> postscript during the
install.
The function is not supported for NFS-based statelite installations.
For statelite installations to sync files, you should use the
read-only option for files/directories listed in
litefile table with source location specified in the litetree table.
B<litefile> table with source location specified in the B<litetree> table.
=item [B<-r>|B<--node-rcp> [I<full_path_to_remote_copy_command>]]
@ -359,8 +357,8 @@ See the document Granting_Users_xCAT_privileges for required xcat/sudo setup.
=item B<-P|--scripts>
Specifies that postscripts and postbootscripts should be run on the nodes.
updatenode -P syncfiles is not supported. The syncfiles postscript can only
be run during install. You should use updatenode <noderange> -F instead.
File sync with B<updatenode -P syncfiles> is not supported. The B<syncfiles> postscript can only
be run during install. You should use B<updatenode -F> instead.
=item B<-S|--sw>
@ -417,11 +415,11 @@ To run postscripts,postbootscripts and file synchronization only on the node "cl
updatenode clstrn01 -F -P
=item 3.
Running updatenode -P with the syncfiles postscript is not supported. You should use updatenode -F instead.
Running B<updatenode -P> with the B<syncfiles> postscript is not supported. You should use B<updatenode -F> instead.
Do not run:
updatenode clstrno1 -P syncfiles
updatenode clstrn01 -P syncfiles
Run:

248
xCAT-client/pods/man1/xdcp.1.pod
View File

@ -1,6 +1,6 @@
=head1 B<NAME>
B<xdcp> - Concurrently copies files to or from multiple nodes. In addition, provides an option to use rsync to update the files on the nodes, or to an installation image on the local node.
B<xdcp> - Concurrently copies files to or from multiple nodes. In addition, provides an option to use B<rsync> to update the files on the managed nodes, or to an installation image on the local node.
=head1 B<SYNOPSIS>
@ -11,7 +11,7 @@ B<xdcp> I<noderange> [B<-F> I<rsync input file>]
B<xdcp> I<computenoderange> [B<-s> B<-F> I<rsync input file>]
B<xdcp> [B<-i> I<path to install image>] [B<-F> I<rsync input file>]
B<xdcp> [B<-i> I<install image>] [B<-F> I<rsync input file>]
B<xdcp> [B<-h> | B<-V> | B<-q>]
@ -20,29 +20,28 @@ B<xdcp> [B<-h> | B<-V> | B<-q>]
=head1 B<DESCRIPTION>
The B<xdcp> command concurrently copies files to or from remote target
nodes. The command issues a remote copy command for each node or device specified. When files are pulled from a target, they are placed into the target_path with the name of the
remote node or device appended to the copied source_file name. The
/usr/bin/rcp command is the model for syntax and security.
If using hierarchy, then xdcp runs on the service node that is servicing the compute node. The file will first be copied to the path defined in the site table, SNsyncfiledir attribute, or the default path /var/xcat/syncfiles on the service node, if the attribute is not defined. The -P flag will not automatically copy
nodes. The command issues a remote copy command for each node or device specified. When files are pulled from a target, they are placed into the I<targetpath> with the name of the
remote node or device appended to the copied I<sourcefile> name. The
B</usr/bin/rcp> command is the model for syntax and security.
If using hierarchy, then B<xdcp> runs on the service node that is servicing the compute node. The file will first be copied to the path defined in the site table, B<SNsyncfiledir> attribute, or the default path B</var/xcat/syncfiles> on the service node, if the attribute is not defined. The B<-P> flag will not automatically copy
the files from the compute node to the Management node, hierarchically. There
is a two step process, see B<-P> flag.
If the Management Node is target node, it must be defined in the xCAT database with nodetype=mn. When the B<xdcp> command runs the Management Node as the target, it does not use remote commands but uses the local OS copy (B<cp>) command.
If the Management Node is target node, it must be defined in the xCAT database with B<nodetype=mn>. When the B<xdcp> command runs with the Management Node as the target, it does not use remote commands but uses the local OS copy (B<cp>) command.
B<REMOTE> B<USER>:
A user_ID can be specified for the remote copy command. Remote user
specification is identical for the B<xdcp> and B<xdsh> commands. See the B<xdsh>
command for more information.
A user_ID can be specified for the remote copy command. Remote user
specification is identical for the B<xdcp> and B<xdsh> commands.
See the B<xdsh> command for more information.
B<REMOTE> B<COMMAND> B<COPY>:
The B<xdcp> command uses a configurable remote copy command to execute
remote copies on remote targets. Support is explicitly provided for
Remote Shell rcp command, the OpenSSH scp command and the
/usr/bin/rsync command.
Remote Shell B<rcp> command, the OpenSSH B<scp> command and the
B</usr/bin/rsync> command.
For node targets, the remote copy command is determined by the follow-
ing order of precedence:
For node targets, the remote copy command is determined by the following order of precedence:
1. The B<-r> flag.
@ -60,10 +59,10 @@ appropriate.
A timeout value for remote copy command execution can be specified with
the B<-t> flag or DSH_TIMEOUT environment variable. If any remote target
does not respond within the timeout value, the xdcp command displays an
does not respond within the timeout value, the B<xdcp> command displays an
error message and exits.
The B<-T> flag provides diagnostic trace information for dcp command execution. Default settings and the actual remote copy commands that are executed to the remote targets are displayed.
The B<-T> flag provides diagnostic trace information for B<xdcp> command execution. Default settings and the actual remote copy commands that are executed to the remote targets are displayed.
The B<xdcp> command can be executed silently using the B<-Q> flag; no target
standard output or standard error is displayed.
@ -76,28 +75,27 @@ standard output or standard error is displayed.
Specifies the complete path for the file to be copied to or
from the target. Multiple files can be specified. When used
with the -R flag, only a single directory can be specified.
When used with the -P flag, only a single file can be specified.
with the B<-R> flag, only a single directory can be specified.
When used with the B<-P> flag, only a single file can be specified.
=item I<targetpath>
If one source_file file, then it specifies the file to copy the source_file
file to on the target. If multiple source_file files, it specifies
the directory to copy the source_file files to on the target.
If the -P flag is specified, the target_path is the local host location
If one source file, then it specifies the file to copy the source
file to on the target. If multiple source files, it specifies
the directory to copy the source files to on the target.
If the B<-P> flag is specified, the I<targetpath> is the local host location
for the copied files. The remote file directory structure is recreated
under target_path and the remote target name is appended
to the copied source_file name in the target_path directory.
Note: the targetpath directory must exist.
under I<targetpath> and the remote target name is appended
to the copied I<sourcefile> name in the I<targetpath> directory.
Note: the I<targetpath> directory must exist.
=item B<-B>|B<--bypass>
Runs in bypass mode, use if the xcatd daemon is hung.
Runs in bypass mode, use if the B<xcatd> daemon is not responding.
=item B<-f>|B<--fanout> I<fanout_value>
Specifies a fanout value for the maximum number of concur-
rently executing remote shell processes. Serial execution
Specifies a fanout value for the maximum number of concurrently executing remote shell processes. Serial execution
can be specified by indicating a fanout value of B<1>.
If B<-f> is not specified, a default fanout value of B<64> is used.
@ -105,110 +103,9 @@ If B<-f> is not specified, a default fanout value of B<64> is used.
Specifies the path to the file that will be used to
build the B<rsync> command.
The format of the input file is as follows, each line contains:
The format of the input file is described here: <https://xcat-docs.readthedocs.io/en/stable/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.html>
<path to source file1> <path to source file2> ... -> < path to destination file/directory>
or
<path to source file> -> <path to destination file>
or
<path to source file> -> <path to destination directory ( must end in /)>
For example:
/etc/password /etc/hosts -> /etc
/tmp/file2 -> /tmp/file2
/tmp/file2 -> /tmp/
/tmp/filex -> /tmp/source/filey
/etc/* -> /etc/
B<Running postscripts after files are sync'd to the nodes>:
After you define the files to rsync, you can add an B<EXECUTE:> clause in the synclist file. The B<EXECUTE:> clause will list all the postscripts that you would like to run after the files are sync'd to the node.
The postscript file must be of the form B<filename.post>, where the <filename>
is the <filename> is the from <filename>, reside in the same
directory as B<filename>, and be executable.
If the file B<filename> is rsync'd to the node, then the B<filename.post>
will automatically be run on the node.
If the file B<filename> is not updated on the node, the B<filename.post> will not be run.
Putting the B<filename.post> in the file list to rsync to the node is required
for hierarchical clusters. It is optional for non-hierarchical clusters.
Another option is the B<EXECUTEALWAYS:> clause in the synclist file. The B<EXECUTEALWAYS:> will list all the postscripts that you would like to run after the files are sync'd to the nodes. These scripts will run whether or not any files are sync'd to the nodes. The scripts have no special format, but must contain the fully qualified path.
The scripts must be also added to the file list to rsync to the node for hierarchical clusters. It is optional for non-hierarchical clusters.
For example, your rsynclist file may look like this:
/tmp/share/file2 -> /tmp/file2
/tmp/share/file2.post -> /tmp/file2.post
/tmp/share/file3 -> /tmp/filex
/tmp/share/file3.post -> /tmp/file3.post
/tmp/myscript -> /tmp/myscript
# the below are postscripts
EXECUTE:
/tmp/share/file2.post
/tmp/share/file3.post
EXECUTEALWAYS:
/tmp/myscript
If /tmp/file2 and /tmp/file3 update /tmp/file2 and /tmp/filex on the node, then the postscripts /tmp/file2.post and /tmp/file3.post are automatically run on
the node. /tmp/myscript will always be run on the node.
Another option is the B<APPEND:> clause in the synclist file. The B<APPEND:> clause is used to append the contents of the input file to an existing file on the node. The file to append B<must> already exist on the node and not be part of the synclist that contains the B<APPEND:> clause.
For example, your rsynclist file may look like this:
/tmp/share/file2 -> /tmp/file2
/tmp/share/file2.post -> /tmp/file2.post
/tmp/share/file3 -> /tmp/filex
/tmp/share/file3.post -> /tmp/file3.post
/tmp/myscript -> /tmp/myscript
# the below are postscripts
EXECUTE:
/tmp/share/file2.post
/tmp/share/file3.post
EXECUTEALWAYS:
/tmp/myscript
APPEND:
/etc/myappenddir/appendfile -> /etc/mysetup/setup
/etc/myappenddir/appendfile2 -> /etc/mysetup/setup2
When you use the append script, the file (left) of the arrow is appended to the file right of the arrow. In this example, /etc/myappenddir/appendfile is appended to /etc/mysetup/setup file, which must already exist on the node. The /opt/xcat/share/xcat/scripts/xdcpappend.sh is used to accomplish this.
Another option is the B<MERGE:> clause in the synclist file. The B<MERGE:> clause is used to append the contents of the input file to /etc/passwd, /etc/group, or /etc/shadow on a Linux node. It is only supported for those files and only on Linux. You must not use both the APPEND and MERGE funcion for these three files. The processing could end up not creating the file you desire. The MERGE function is the preferred method, because APPEND only adds to the file. MERGE will add to the file but also insure there are no duplicate entries.
For example, your rsynclist file may look like this:
/tmp/share/file2 -> /tmp/file2
/tmp/share/file2.post -> /tmp/file2.post
/tmp/share/file3 -> /tmp/filex
/tmp/share/file3.post -> /tmp/file3.post
/tmp/myscript -> /tmp/myscript
# the below are postscripts
EXECUTE:
/tmp/share/file2.post
/tmp/share/file3.post
EXECUTEALWAYS:
/tmp/myscript
APPEND:
/custom/mypasswd -> /etc/passwd
/custom/mygroups -> /etc/group
/custom/myshadow -> /etc/shadow
Note: no order can be assumed by the order that the EXECUTE,EXECUTEALWAYS and APPEND clause fall in the synclist file.
For more information on syncing files to node, read Sync-ing_Config_Files_to_Nodes
On Linux rsync always uses ssh remoteshell. On AIX, ssh or rsh is used depending on the site.useSSHonAIX attribute.
On Linux B<rsync> always uses ssh remoteshell. On AIX, B<ssh> or B<rsh> is used depending on the B<site.useSSHonAIX> table attribute.
=item B<-h>|B<--help>
@ -218,15 +115,14 @@ Displays usage information.
=item B<-i>|B<--rootimg> I<install image>
Specifies the path to the install image on the local Linux node.
Specifies the path to the install image on the local Linux node.
=item B<-o>|B<--node-options> I<node_options>
Specifies options to pass to the remote shell command for
node targets. The options must be specified within double
quotation marks ("") to distinguish them from B<xdsh> options.
quotation marks ("") to distinguish them from B<xdcp> options.
=item B<-p>|B<--preserve>
@ -236,14 +132,14 @@ the configured remote copy command.
=item B<-P>|B<--pull>
Pulls (copies) the files from the targets and places them in
the target_path directory on the local host. The target_path
the I<targetpath> directory on the local host. The I<targetpath>
must be a directory. Files pulled from remote machines have
._target appended to the file name to distinguish between
them. When the B<-P> flag is used with the B<-R> flag, ._target is
B<._target> appended to the file name to distinguish between
them. When the B<-P> flag is used with the B<-R> flag, B<._target> is
appended to the directory. Only one file per invocation of the
xdcp pull command can be pulled from the specified targets.
Hierarchy is not automatically support yet. You must first pull
the file to the Service Node and then pull the file to the Management
B<xdcp> pull command can be pulled from the specified targets.
In hierarchy, you must first pull
the file to the service node and then pull the file to the management
node.
=item B<-q>|B<--show-config>
@ -266,16 +162,15 @@ for remote command execution on node targets.
Recursively copies files from a local directory to the remote
targets, or when specified with the B<-P> flag, recursively pulls
(copies) files from a remote directory to the local host. A
single source directory can be specified using the source_file
parameter.
single source directory can be specified using the I<sourcefile> parameter.
=item B<-s> I<synch service nodes>
Will only sync the files listed in the synclist (B<-F>), to the service
nodes for the input compute node list. The files will be placed in the
directory defined by the site.SNsyncfiledir attribute, or the default
/var/xcat/syncfiles directory.
directory defined by the B<site.SNsyncfiledir> table attribute, or the default
B</var/xcat/syncfiles> directory.
=item B<-t>|B<--timeout> I<timeout>
@ -361,9 +256,8 @@ variable is overridden by the B<-S> flag.
=item B<DSH_TIMEOUT>
Specifies the time, in seconds, to wait for output from
each remote target. This variable is overridden by the B<-t>
flag.
Specifies the time, in seconds, to wait for output from
each remote target. This variable is overridden by the B<-t> flag.
=back
@ -374,13 +268,12 @@ Exit values for each remote copy command execution are displayed in
messages from the xdcp command, if the remote copy command exit value is
non-zero. A non-zero return code from a remote copy command indicates
that an error was encountered during the remote copy. If a remote copy
command encounters an error, execution of the remote copy on that tar-
get is bypassed.
command encounters an error, execution of the remote copy on that target is bypassed.
The xdcp command exit code is 0, if the xdcp command executed without
The B<xdcp> command exit code is 0, if the B<xdcp> command executed without
errors and all remote copy commands finished with exit codes of 0. If
internal xdcp errors occur or the remote copy commands do not complete
successfully, the xdcp command exit value is greater than 0.
internal B<xdcp> errors occur or the remote copy commands do not complete
successfully, the B<xdcp> command exit value is greater than 0.
@ -424,7 +317,7 @@ host as /var/log._target, enter:
xdcp NodeGroup1 -f 12 -RP /var/log/testlogdir /var/log
=item 3.
To copy /localnode/smallfile and /tmp/bigfile to /tmp on node1
To copy /localnode/smallfile and /tmp/bigfile to B/tmp on node1
using rsync and input -t flag to rsync, enter:
xdcp node1 -r /usr/bin/rsync -o "-t" /localnode/smallfile /tmp/bigfile /tmp
@ -456,72 +349,67 @@ To copy the /etc/hosts file from node1 and node2 to the
=item 8.
To rsync the /etc/hosts file to your compute nodes:
Create a rsync file /tmp/myrsync, with this line:
First create a syncfile /tmp/myrsync, with this line:
/etc/hosts -> /etc/hosts
/etc/hosts -> /etc/hosts
or
/etc/hosts -> /etc/ (last / is required)
/etc/hosts -> /etc/ (last / is required)
Run:
Then run:
xdcp compute -F /tmp/myrsync
=item 9.
To rsync all the files in /home/mikev to the compute nodes:
Create a rsync file /tmp/myrsync, with this line:
First create a rsync file /tmp/myrsync, with this line:
/home/mikev/* -> /home/mikev/ (last / is required)
/home/mikev/* -> /home/mikev/ (last / is required)
Run:
Then run:
xdcp compute -F /tmp/myrsync
=item 10.
To rsync to the compute nodes, using service nodes, the command will first
rsync the files to the /var/xcat/syncfiles directory on the service nodes and then rsync the files from that directory to the compute nodes. The /var/xcat/syncfiles default directory on the service nodes, can be changed by putting a directory value in the site table SNsyncfiledir attribute.
To rsync to the compute nodes, using service nodes:
First create a rsync file /tmp/myrsync, with this line:
Create a rsync file /tmp/myrsync, with this line:
/etc/hosts /etc/passwd -> /etc
/etc/hosts /etc/passwd -> /etc
or
/etc/hosts /etc/passwd -> /etc/
/etc/hosts /etc/passwd -> /etc/
Run:
Then run:
xdcp compute -F /tmp/myrsync
to update the Compute Nodes
=item 11.
To rsync to the service nodes in preparation for rsyncing the compute nodes
during an install from the service node.
Create a rsync file /tmp/myrsync, with this line:
First create a rsync file /tmp/myrsync, with this line:
/etc/hosts /etc/passwd -> /etc
/etc/hosts /etc/passwd -> /etc
Run:
Then run:
xdcp compute -s -F /tmp/myrsync
to sync the service node for compute
=item 12.
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:
First create a rsync file /tmp/myrsync, with these line:
/etc/file1 -> /etc/filex
/etc/file1 -> /etc/filex
/etc/file2 -> /etc/filey
/etc/file2 -> /etc/filey
Run:
Then run:
xdcp compute -F /tmp/myrsync
@ -530,11 +418,11 @@ to update the Compute Nodes
=item 13.
To rsync files in the Linux image at /install/netboot/fedora9/x86_64/compute/rootimg on the MN:
Create a rsync file /tmp/myrsync, with this line:
First create a rsync file /tmp/myrsync, with this line:
/etc/hosts /etc/passwd -> /etc
/etc/hosts /etc/passwd -> /etc
Run:
Then run:
xdcp -i /install/netboot/fedora9/x86_64/compute/rootimg -F /tmp/myrsync