From ee026089c397ba6c931cdbb40c0e2db5e79c5b43 Mon Sep 17 00:00:00 2001 From: Mark Gurevich Date: Thu, 7 Nov 2019 16:18:43 -0500 Subject: [PATCH] Fix broken doc links --- .../advanced/hierarchy/configure_dhcp.rst | 5 +- .../hierarchy/define_service_node.rst | 178 +++++++++--------- .../performance_tuning/httpd_tuning.rst | 8 +- .../restapi/restapi_usage/restapi_usage.rst | 5 +- .../developers/guides/docs/doc_guidelines.rst | 4 +- .../common/deployment/cfg_partition.rst | 2 +- .../common/deployment/enable_kdump.rst | 23 ++- .../diskful/customize_image/cfg_partition.rst | 10 +- 8 files changed, 113 insertions(+), 122 deletions(-) diff --git a/docs/source/advanced/hierarchy/configure_dhcp.rst b/docs/source/advanced/hierarchy/configure_dhcp.rst index 06fe9e258..bd61f2450 100644 --- a/docs/source/advanced/hierarchy/configure_dhcp.rst +++ b/docs/source/advanced/hierarchy/configure_dhcp.rst @@ -3,10 +3,9 @@ Configure DHCP Add the relevant networks into the DHCP configuration, refer to: :ref:`Setup-dhcp` -Add the defined nodes into the DHCP configuration, refer to: -`XCAT_pLinux_Clusters/#configure-dhcp `_ +Add the defined nodes into the DHCP configuration, refer to :doc:`Manually define nodes ` -In the large cluster, the size of dhcp lease file "/var/lib/dhcpd/dhcpd.leases" on the DHCP server will grow over time. At around 100MB in size, the DHCP server will take a long time to respond to DHCP requests from clients and cause DHCP timeouts: :: +In the large cluster, the size of dhcp lease file ``/var/lib/dhcpd/dhcpd.leases`` on the DHCP server will grow over time. At around 100MB in size, the DHCP server will take a long time to respond to DHCP requests from clients and cause DHCP timeouts: :: ... Mar 2 01:59:10 c656ems2 dhcpd: DHCPDISCOVER from 00:0a:f7:73:7d:d0 via eth0 diff --git a/docs/source/advanced/hierarchy/define_service_node.rst b/docs/source/advanced/hierarchy/define_service_node.rst index 81e6c8557..3c2d8ec1f 100644 --- a/docs/source/advanced/hierarchy/define_service_node.rst +++ b/docs/source/advanced/hierarchy/define_service_node.rst @@ -11,41 +11,41 @@ be adding the information to the database that will tell xCAT which service nodes (SN) will service which compute nodes (CN). For this example, we have two service nodes: **sn1** and **sn2**. We will call -our Management Node: **mn1**. Note: service nodes are, by convention, in a +our Management Node: **mn1**. Service nodes are, by convention, in a group called **service**. Some of the commands in this document will use the group **service** to update all service nodes. -Note: a Service Node's service node is the Management Node; so a service node -must have a direct connection to the management node. The compute nodes do not -have to be directly attached to the Management Node, only to their service -node. This will all have to be defined in your networks table. +.. note:: a Service Node's service node is the Management Node; so a service node + must have a direct connection to the management node. The compute nodes do not + have to be directly attached to the Management Node, only to their service + node. This will all have to be defined in your networks table. Add Service Nodes to the nodelist Table --------------------------------------- Define your service nodes (if not defined already), and by convention we put -them in a **service** group. We usually have a group compute for our compute +them in a **service** group. We usually have a group **compute** for our compute nodes, to distinguish between the two types of nodes. (If you want to use your -own group name for service nodes, rather than service, you need to change some -defaults in the xCAT db that use the group name service. For example, in the -postscripts table there is by default a group entry for service, with the +own group name for service nodes, rather than **service**, you need to change some +defaults in the xCAT db that use the group name **service**. For example, in the +postscripts table there is by default a group entry for **service**, with the appropriate postscripts to run when installing a service node. Also, the default ``kickstart/autoyast`` template, pkglist, etc that will be used have -files names based on the profile name service.) :: +files names based on the profile name **service**.) :: mkdef sn1,sn2 groups=service,ipmi,all Add OS and Hardware Attributes to Service Nodes ----------------------------------------------- -When you ran copycds, it creates several osimage definitions, including some +When you ran ``copycds``, it creates several osimage definitions, including some appropriate for SNs. Display the list of osimages and choose one with -"service" in the name: :: +**service** in the name: :: lsdef -t osimage For this example, let's assume you chose the stateful osimage definition for -rhels 7: rhels7-x86_64-install-service . If you want to modify any of the +rhels 7: ``rhels7-x86_64-install-service`` . If you want to modify any of the osimage attributes (e.g. ``kickstart/autoyast`` template, pkglist, etc), make a copy of the osimage definition and also copy to ``/install/custom`` any files it points to that you are modifying. @@ -60,19 +60,19 @@ Now set some of the common attributes for the SNs at the group level: :: primarynic=mac \ provmethod=rhels7-x86_64-install-service -Add Service Nodes to the servicenode Table +Add Service Nodes to the ``servicenode`` Table ------------------------------------------ -An entry must be created in the servicenode table for each service node or the -service group. This table describes all the services you would like xcat to +An entry must be created in the ``servicenode`` table for each service node or the +**service** group. This table describes all the services you would like xcat to setup on the service nodes. (Even if you don't want xCAT to set up any -services - unlikely - you must define the service nodes in the servicenode +services - unlikely - you must define the service nodes in the ``servicenode`` table with at least one attribute set (you can set it to 0), otherwise it will not be recognized as a service node.) -When the xcatd daemon is started or restarted on the service node, it will +When the ``xcatd`` daemon is started or restarted on the service node, it will make sure all of the requested services are configured and started. (To -temporarily avoid this when restarting xcatd, use "service xcatd reload" +temporarily avoid this when restarting ``xcatd``, use ``service xcatd reload`` instead.) To set up the minimum recommended services on the service nodes: :: @@ -82,23 +82,21 @@ To set up the minimum recommended services on the service nodes: :: setupnameserver=1 \ setupconserver=1 -.. TODO - See the ``setup*`` attributes in the :doc:`node manpage ` for the services available. (The HTTP server is also started when setupnfs is set.) -If you are using the setupntp postscript on the compute nodes, you should also -set setupntp=1. For clusters with subnetted management networks (i.e. the +If you are using the ``setupntp`` postscript on the compute nodes, you should also +set ``setupntp=1``. For clusters with subnetted management networks (i.e. the network between the SN and its compute nodes is separate from the network -between the MN and the SNs) you might want to also set setupipforward=1. +between the MN and the SNs) you might want to also set ``setupipforward=1``. .. _add_service_node_postscripts_label: Add Service Node Postscripts ---------------------------- -By default, xCAT defines the service node group to have the "servicenode" +By default, xCAT defines the **service** node group to have the ``servicenode`` postscript run when the SNs are installed or diskless booted. This -postscript sets up the xcatd credentials and installs the xCAT software on +postscript sets up the ``xcatd`` credentials and installs the xCAT software on the service nodes. If you have your own postscript that you want run on the SN during deployment of the SN, put it in ``/install/postscripts`` on the MN and add it to the service node postscripts or postbootscripts. For example: :: @@ -113,7 +111,7 @@ Notes: * Make sure that the servicenode postscript is set to run before the otherpkgs postscript or you will see errors during the service node deployment. - * The -p flag automatically adds the specified postscript at the end of the + * The ``-p`` flag automatically adds the specified postscript at the end of the comma-separated list of postscripts (or postbootscripts). If you are running additional software on the service nodes that need **ODBC** @@ -125,43 +123,42 @@ the xCAT supplied postbootscript called "odbcsetup". :: Assigning Nodes to their Service Nodes -------------------------------------- -The node attributes **servicenode** and **xcatmaster** define which SN -services this particular node. The servicenode attribute for a compute node -defines which SN the MN should send a command to (e.g. xdsh), and should be +The node attributes ``servicenode`` and ``xcatmaster`` define which SN +services this particular node. The ``servicenode`` attribute for a compute node +defines which SN the MN should send a command to (e.g. ``xdsh``), and should be set to the hostname or IP address of the service node that the management -node contacts it by. The xcatmaster attribute of the compute node defines +node contacts it by. The ``xcatmaster`` attribute of the compute node defines which SN the compute node should boot from, and should be set to the hostname or IP address of the service node that the compute node contacts it -by. Unless you are using service node pools, you must set the xcatmaster +by. Unless you are using service node pools, you must set the ``xcatmaster`` attribute for a node when using service nodes, even if it contains the same -value as the node's servicenode attribute. +value as the node's ``servicenode`` attribute. Host name resolution must have been setup in advance, with ``/etc/hosts``, DNS or dhcp to ensure that the names put in this table can be resolved on the Management Node, Service nodes, and the compute nodes. It is easiest to have a node group of the compute nodes for each service node. For example, if all the -nodes in node group compute1 are serviced by sn1 and all the nodes in node -group compute2 are serviced by sn2: +nodes in node group **compute1** are serviced by sn1 and all the nodes in node +group **compute2** are serviced by sn2: :: chdef -t group compute1 servicenode=sn1 xcatmaster=sn1-c chdef -t group compute2 servicenode=sn2 xcatmaster=sn2-c -Note: in this example, sn1 and sn2 are the node names of the service nodes -(and therefore the hostnames associated with the NICs that the MN talks to). -The hostnames sn1-c and sn2-c are associated with the SN NICs that communicate -with their compute nodes. +.. note:: In this example, sn1 and sn2 are the node names of the service nodes + (and therefore the hostnames associated with the NICs that the MN talks to). + The hostnames sn1-c and sn2-c are associated with the SN NICs that communicate + with their compute nodes. -Note: if not set, the attribute tftpserver's default value is xcatmaster, -but in some releases of xCAT it has not defaulted correctly, so it is safer -to set the tftpserver to the value of xcatmaster. +.. note:: If not set, the attribute tftpserver's default value is ``xcatmaster``, + but in some releases of xCAT it has not defaulted correctly, so it is safer + to set the tftpserver to the value of ``xcatmaster``. These attributes will allow you to specify which service node should run the conserver (console) and monserver (monitoring) daemon for the nodes in the group specified in the command. In this example, we are having each node's -primary SN also act as its conserver and monserver (the most typical setup). -:: +primary SN also act as its conserver and monserver (the most typical setup). :: chdef -t group compute1 conserver=sn1 monserver=sn1,sn1-c chdef -t group compute2 conserver=sn2 monserver=sn2,sn2-c @@ -176,22 +173,22 @@ for work-load balancing on the service nodes. But note that the selection of which SN will service which compute node is made at compute node boot time. After that, the selection of the SN for this compute node is fixed until the compute node is rebooted or the compute node is explicitly moved to another SN -using the `snmove `_ command. +using the :doc:`snmove ` command. To use Service Node pools, you need to architect your network such that all of the compute nodes and service nodes in a particular pool are on the same flat network. If you don't want the management node to respond to manage some of the compute nodes, it shouldn't be on that same flat network. The -site, dhcpinterfaces attribute should be set such that the SNs' DHCP daemon +``site`` table, ``dhcpinterfaces`` attribute should be set such that the SNs' DHCP daemon only listens on the NIC that faces the compute nodes, not the NIC that faces the MN. This avoids some timing issues when the SNs are being deployed (so that they don't respond to each other before they are completely ready). You -also need to make sure the `networks `_ table +also need to make sure the :doc:`networks ` table accurately reflects the physical network structure. To define a list of service nodes that support a set of compute nodes, set the -servicenode attribute to a comma-delimited list of the service nodes. When -running an xCAT command like xdsh or updatenode for compute nodes, the list +``servicenode`` attribute to a comma-delimited list of the service nodes. When +running an xCAT command like ``xdsh`` or ``updatenode`` for compute nodes, the list will be processed left to right, picking the first service node on the list to run the command. If that service node is not available, then the next service node on the list will be chosen until the command is successful. Errors will @@ -201,10 +198,10 @@ service nodes as we do below. When using service node pools, the intent is to have the service node that responds first to the compute node's DHCP request during boot also be the -xcatmaster, the tftpserver, and the NFS/http server for that node. Therefore, -the xcatmaster and nfsserver attributes for nodes should not be set. When -nodeset is run for the compute nodes, the service node interface on the -network to the compute nodes should be defined and active, so that nodeset +``xcatmaster``, the ``tftpserver``, and the NFS/http server for that node. Therefore, +the ``xcatmaster`` and ``nfsserver`` attributes for nodes should not be set. When +``nodeset`` is run for the compute nodes, the service node interface on the +network to the compute nodes should be defined and active, so that ``nodeset`` will default those attribute values to the "node ip facing" interface on that service node. @@ -213,30 +210,29 @@ For example: :: chdef -t node compute1 servicenode=sn1,sn2 xcatmaster="" nfsserver="" chdef -t node compute2 servicenode=sn2,sn1 xcatmaster="" nfsserver="" -You need to set the sharedtftp site attribute to 0 so that the SNs will not -automatically mount the ``/tftpboot`` directory from the management node: -:: +You need to set the ``sharedtftp`` site attribute to ``0`` so that the SNs will not +automatically mount the ``/tftpboot`` directory from the management node: :: chdef -t site clustersite sharedtftp=0 -For stateful (diskful) installs, you will need to use a local ``/install`` directory on each service node. The ``/install/autoinst/node`` files generated by nodeset will contain values specific to that service node for correctly installing the nodes. :: +For stateful (diskful) installs, you will need to use a local ``/install`` directory on each service node. The ``/install/autoinst/node`` files generated by ``nodeset`` will contain values specific to that service node for correctly installing the nodes. :: chdef -t site clustersite installloc="" -With this setting, you will need to remember to rsync your ``/install`` +With this setting, you will need to remember to ``rsync`` your ``/install`` directory from the xCAT management node to the service nodes anytime you change your ``/install/postscripts``, custom osimage files, os repositories, or other directories. It is best to exclude the ``/install/autoinst`` directory -from this rsync. +from this ``rsync``. :: rsync -auv --exclude 'autoinst' /install sn1:/ -Note: If your service nodes are stateless and site.sharedtftp=0, if you reboot -any service node when using servicenode pools, any data written to the local -``/tftpboot`` directory of that SN is lost. You will need to run nodeset for -all of the compute nodes serviced by that SN again. +.. note:: If your service nodes are stateless and ``site.sharedtftp=0``, if you reboot + any service node when using servicenode pools, any data written to the local + ``/tftpboot`` directory of that SN is lost. You will need to run ``nodeset`` for + all of the compute nodes serviced by that SN again. For additional information about service node pool related settings in the networks table, see ref: networks table, see :ref:`setup_networks_table_label`. @@ -246,13 +242,13 @@ Conserver and Monserver and Pools The support of conserver and monserver with Service Node Pools is still not supported. You must explicitly assign these functions to a service node using -the nodehm.conserver and noderes.monserver attribute as above. +the ``nodehm.conserver`` and ``noderes.monserver`` attribute as above. Setup Site Table ---------------- If you are not using the NFS-based statelite method of booting your compute -nodes, set the installloc attribute to ``/install``. This instructs the +nodes, set the ``installloc`` attribute to ``/install``. This instructs the service node to mount ``/install`` from the management node. (If you don't do this, you have to manually sync ``/install`` between the management node and the service nodes.) :: @@ -261,25 +257,25 @@ the service nodes.) :: For IPMI controlled nodes, if you want the out-of-band IPMI operations to be done directly from the management node (instead of being sent to the -appropriate service node), set site.ipmidispatch=n. +appropriate service node), set ``site.ipmidispatch=n``. If you want to throttle the rate at which nodes are booted up, you can set the following site attributes: -* syspowerinterval -* syspowermaxnodes -* powerinterval (system p only) +* ``syspowerinterval`` +* ``syspowermaxnodes`` +* ``powerinterval`` (system p only) -See the `site table man page `_ for details. +See the :doc:`site table man page ` for details. .. _setup_networks_table_label: Setup networks Table -------------------- -All networks in the cluster must be defined in the networks table. When xCAT -is installed, it runs makenetworks, which creates an entry in the networks +All networks in the cluster must be defined in the ``networks`` table. When xCAT +is installed, it runs ``makenetworks``, which creates an entry in the ``networks`` table for each of the networks the management node is on. You need to add entries for each network the service nodes use to communicate to the compute nodes. @@ -288,28 +284,27 @@ For example: :: mkdef -t network net1 net=10.5.1.0 mask=255.255.255.224 gateway=10.5.1.1 -If you want to set the nodes' xcatmaster as the default gateway for the nodes, -the gateway attribute can be set to keyword "". In this case, xCAT -code will automatically substitute the IP address of the node's xcatmaster for -the keyword. Here is an example: -:: +If you want to set the nodes' ``xcatmaster`` as the default gateway for the nodes, +the ``gateway`` attribute can be set to keyword ````. In this case, xCAT +code will automatically substitute the IP address of the node's ``xcatmaster`` for +the keyword. Here is an example: :: mkdef -t network net1 net=10.5.1.0 mask=255.255.255.224 gateway= -The ipforward attribute should be enabled on all the xcatmaster nodes that -will be acting as default gateways. You can set ipforward to 1 in the -servicenode table or add the line "net.ipv4.ip_forward = 1" in file -``/etc/sysctl.conf`` and then run "sysctl -p /etc/sysctl.conf" manually to +The ``ipforward`` attribute should be enabled on all the ``xcatmaster`` nodes that +will be acting as default gateways. You can set ``ipforward`` to ``1`` in the +``servicenode`` table or add the line ``net.ipv4.ip_forward = 1`` in file +``/etc/sysctl.conf`` and then run ``sysctl -p /etc/sysctl.conf`` manually to enable the ipforwarding. -Note:If using service node pools, the networks table dhcpserver attribute can -be set to any single service node in your pool. The networks tftpserver, and -nameserver attributes should be left blank. +.. note:: If using service node pools, the ``networks`` table ``dhcpserver`` attribute can + be set to any single service node in your pool. The networks ``tftpserver``, and + ``nameserver`` attributes should be left blank. Verify the Tables -------------------- -To verify that the tables are set correctly, run lsdef on the service nodes, +To verify that the tables are set correctly, run ``lsdef`` on the service nodes, compute1, compute2: :: lsdef service,compute1,compute2 @@ -318,22 +313,21 @@ Add additional adapters configuration script (optional) ------------------------------------------------------------ It is possible to have additional adapter interfaces automatically configured -when the nodes are booted. XCAT provides sample configuration scripts for +when the nodes are booted. xCAT provides sample configuration scripts for ethernet, IB, and HFI adapters. These scripts can be used as-is or they can be modified to suit your particular environment. The ethernet sample is ``/install/postscript/configeth``. When you have the configuration script that -you want you can add it to the "postscripts" attribute as mentioned above. Make +you want you can add it to the ``postscripts`` attribute as mentioned above. Make sure your script is in the ``/install/postscripts`` directory and that it is executable. -Note: For system p servers, if you plan to have your service node perform the -hardware control functions for its compute nodes, it is necessary that the SN -ethernet network adapters connected to the HW service VLAN be configured. +.. note:: For system p servers, if you plan to have your service node perform the + hardware control functions for its compute nodes, it is necessary that the SN + ethernet network adapters connected to the HW service VLAN be configured. Configuring Secondary Adapters ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -To configure secondary adapters, see `Configuring_Secondary_Adapters -`_ +To configure secondary adapters, see :doc:`Configure Additional Network Interfaces ` diff --git a/docs/source/advanced/performance_tuning/httpd_tuning.rst b/docs/source/advanced/performance_tuning/httpd_tuning.rst index 867fdb036..adb7f5f5a 100644 --- a/docs/source/advanced/performance_tuning/httpd_tuning.rst +++ b/docs/source/advanced/performance_tuning/httpd_tuning.rst @@ -6,9 +6,9 @@ In xCAT, the Operation System provisioning over network is heavily relying on th #. Tuning MaxRequestWorkers directive -By default, httpd is configured to use ``prefork`` module for **MPM**, which has a limit of 256 simultaneous requests. If any slow httpd response issue was hit during OS provisioning, you can increase **MaxRequestWorkers** directive for greater performance. +By default, httpd is configured to use ``prefork`` module for **MPM**, which has a limit of 256 simultaneous requests. If slow httpd response observed during OS provisioning, you can increase **MaxRequestWorkers** directive for better performance. -For example, to avoid some nodes provisioning failure when rebooting all nodes in a large hierarchy stateless cluster ( one service node is serving 270 compute nodes ). It is suggested to increased the value from 256 to 1000. +For example, to avoid some nodes provisioning failure when rebooting all nodes in a large hierarchy stateless cluster ( one service node is serving 270 compute nodes ), increase the value from 256 to 1000. On Red Hat, change (or add) these directives in :: @@ -24,9 +24,9 @@ For example, to avoid some nodes provisioning failure when rebooting all nodes i #. Having httpd Cache the Files It Is Serving -Note: this information was contributed by Jonathan Dye and is provided here as an example. The details may have to be changed for distro or apache version. +.. note:: this information was contributed by Jonathan Dye and is provided here as an example. The details may have to be changed for distro or apache version. -This is simplest if you set noderes.nfsserver to a separate apache server, and then you can configure it to reverse proxy and cache. For some reason mod_mem_cache doesn't seem to behave as expected, so you can use mod_disk_cache to achieve a similar result: make a tmpfs on the apache server and configure its mountpoint to be the directory that CacheRoot points to. Also tell it to ignore /install/autoinst since the caching settings are really aggressive. Do a recursive wget to warm the cache and watch the tmpfs fill up. Then do a bunch of kickstart installs. Before this, the apache server on the xcat management node may have been a bottleneck during kickstart installs. After this change, it no longer should be. +This is simplest if you set ``noderes.nfsserver`` to a separate apache server, and then you can configure it to reverse proxy and cache. For some reason ``mod_mem_cache`` doesn't seem to behave as expected, so you can use ``mod_disk_cache`` to achieve a similar result: make a ``tmpfs`` on the apache server and configure its mountpoint to be the directory that ``CacheRoot`` points to. Also tell it to ignore ``/install/autoinst`` since the caching settings are really aggressive. Do a recursive ``wget`` to warm the cache and watch the ``tmpfs`` fill up. Then do a bunch of kickstart installs. Before this, the apache server on the xcat management node may have been a bottleneck during kickstart installs. After this change, it no longer should be. Here is the apache config file: :: diff --git a/docs/source/advanced/restapi/restapi_usage/restapi_usage.rst b/docs/source/advanced/restapi/restapi_usage/restapi_usage.rst index ecca3b8e8..58d4f13f2 100644 --- a/docs/source/advanced/restapi/restapi_usage/restapi_usage.rst +++ b/docs/source/advanced/restapi/restapi_usage/restapi_usage.rst @@ -217,9 +217,9 @@ It can be used as an example script to access and control xCAT resources. From t ./xcatws-test.sh -u root -p cluster -h -t ./xcatws-test.sh -u root -p cluster -h -c -t -But for exploration and experimentation, you can make API calls from your browser or by using the **curl** command. +But for exploration and experimentation, you can make API calls from your browser or by using the ``curl`` command. -To make an API call from your browser, use the desired URL from this document. To simplify the test step, all the examples for the resources use 'curl -k' for unsecure http connection and use the 'username+password' to authenticate the user. :: +To make an API call from your browser, use the desired URL from this document. To simplify the test step, all the examples for the resources use ``curl -k`` for unsecure http connection and use the 'username+password' to authenticate the user. :: curl -X GET -k 'https://myserver/xcatws/nodes?userName=xxx&userPW=xxx&pretty=1' @@ -276,5 +276,4 @@ References * General JSON: http://www.json.org/ * JSON wrapping: http://search.cpan.org/~makamaka/JSON-2.27/lib/JSON.pm * Apache CGI: http://httpd.apache.org/docs/2.2/howto/cgi.html - * Perl CGI: http://perldoc.perl.org/CGI.html diff --git a/docs/source/developers/guides/docs/doc_guidelines.rst b/docs/source/developers/guides/docs/doc_guidelines.rst index ce121d4f5..1c07bdf39 100644 --- a/docs/source/developers/guides/docs/doc_guidelines.rst +++ b/docs/source/developers/guides/docs/doc_guidelines.rst @@ -137,9 +137,9 @@ Add links to refer other web page is a very common way in writing document, it' * **Add an External Link** - Link to an external web page: `google `_: :: + Link to an external web page: `google `_: :: - `google `_ + `google `_ .. diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_partition.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_partition.rst index 9f3ad3ec8..cc170bd82 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_partition.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_partition.rst @@ -38,7 +38,7 @@ The partition file must follow the partitioning syntax of the respective install * Use yast2 autoyast in GUI or CLI mode to customize the installation options and create autoyast file * Use yast2 clone_system to create autoyast configuration file /root/autoinst.xml to clone an existing system - * Ubuntu: `Preseed documentation `_ + * Ubuntu: `Preseed documentation `_ * For detailed information see the files ``partman-auto-recipe.txt`` and ``partman-auto-raid-recipe.txt`` included in the debian-installer package. Both files are also available from the debian-installer source repository. diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/enable_kdump.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/enable_kdump.rst index 17b8ea5cb..cc639b4b0 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/enable_kdump.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/enable_kdump.rst @@ -4,7 +4,7 @@ Enable kdump Over Ethernet Overview -------- -kdump is an feature of the Linux kernel that allows the system to be booted from the context of another kernel. This second kernel reserves a small amount of memory and its only purpose is to capture the core dump in the event of a kernel crash. The ability to analyze the core dump helps to determine causes of system failures. +``kdump`` is an feature of the Linux kernel that allows the system to be booted from the context of another kernel. This second kernel reserves a small amount of memory and its only purpose is to capture the core dump in the event of a kernel crash. The ability to analyze the core dump helps to determine causes of system failures. xCAT Interface @@ -22,7 +22,7 @@ The following attributes of an osimage should be modified to enable ``kdump``: Configure the ``pkglist`` file ------------------------------ -The ``pkglist`` for the osimage needs to include the appropriate RPMs. The following list of RPMs are provided as a sample, always refer to the Operating System specific documentataion to ensure the required packages are there for ``kdump`` support. +The ``pkglist`` for the osimage needs to include the appropriate RPMs. The following list of RPMs are provided as a sample, always refer to the Operating System specific documentation to ensure the required packages are there for ``kdump`` support. * **[RHELS]** :: @@ -53,7 +53,7 @@ Run ``packimage`` to update the diskless image with the changes. The ``postinstall`` file ------------------------ -The kdump will create a new initrd which used in the dumping stage. The ``/tmp`` or ``/var/tmp`` directory will be used as the temporary directory. These 2 directory only are allocated 10M space by default. You need to enlarge it to 200M. Modify the postinstall file to increase ``/tmp`` space. +The ``kdump`` will create a new initrd which is used in the dumping stage. The ``/tmp`` or ``/var/tmp`` directory will be used as the temporary directory. These two directories are only allocated 10M space by default. You need to enlarge it to 200M. Modify the postinstall file to increase ``/tmp`` space. * **[RHELS]** :: @@ -70,7 +70,7 @@ The kdump will create a new initrd which used in the dumping stage. The ``/tmp`` The ``dump`` attribute ---------------------- -To support kernel dumps, the ``dump`` attribute **must** be set on the osimage definition. If not set, kdump service will not be enabled. The ``dump`` attribute defines the NFS remote path where the crash information is to be stored. +To support kernel dumps, the ``dump`` attribute **must** be set in the osimage definition. If not set, ``kdump`` service will not be enabled. The ``dump`` attribute defines the NFS remote path where the crash information is to be stored. Use the ``chdef`` command to set a value of the ``dump`` attribute: :: @@ -80,7 +80,7 @@ If the NFS server is the Service Node or Management Node, the server can be left chdef -t osimage dump=nfs:/// -**Note:** Only NFS is currently supported as a storage location. Make sure the NFS remote path(``nfs:///``) is exported and it is read-writeable to the node where kdump service is enabled. +.. note:: Only NFS is currently supported as a storage location. Make sure the NFS remote path (``nfs:///``) is exported and it is read-writeable on the node where ``kdump`` service is enabled. The ``crashkernelsize`` attribute @@ -102,18 +102,18 @@ For setting specific sizes, use the following example: chdef -t osimage crashkernelsize=@32M -**Notes**: the value of the ``crashkernelsize`` depends on the total physical memory size on the machine. For more about size, refer to `Appedix`_ +.. note:: The value of the ``crashkernelsize`` depends on the total physical memory size on the machine. For more about size, refer to `Appedix`_ -If kdump start error like this: :: +If ``kdump`` start displays error like this: :: Your running kernel is using more than 70% of the amount of space you reserved for kdump, you should consider increasing your crashkernel -The ``crashkernelsize`` is not large enough, you should change the ``crashkernelsize`` larger until the error message disappear. +The ``crashkernelsize`` is not large enough, you should increase the ``crashkernelsize`` until the error message disappears. The ``enablekdump`` postscript ------------------------------ -xCAT provides a postscript ``enablekdump`` that can be added to the Nodes to automatically start the ``kdump`` service when the node boots. Add to the nodes using the following command: :: +xCAT provides a postscript ``enablekdump`` that can be added to the node definition to automatically start the ``kdump`` service when the node boots. :: chdef -t node -p postscripts=enablekdump @@ -147,13 +147,13 @@ Once the system has returned from recovering the crash, you can analyze the kern #. Locate the recent vmcore dump file. -#. Locate the kernel file for the crash server. The kernel is under ``/tftpboot/xcat/netboot////kernel`` on the managenent node. +#. Locate the kernel file for the crash server. The kernel is under ``/tftpboot/xcat/netboot////kernel`` on the management node. #. Once you have located a vmcore dump file and kernel file, call ``crash``: :: crash -**Note:** If ``crash`` cannot find any files, make sure you have the ``kernel-debuginfo`` package installed. +.. note:: If ``crash`` cannot find any files, make sure you have the ``kernel-debuginfo`` package installed. Appedix ------- @@ -170,4 +170,3 @@ Appedix * http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/s1-kdump-crash.htmlRHELdocument - * http://www.novell.com/support/kb/doc.php?id=3374462SLESdocument diff --git a/docs/source/guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/cfg_partition.rst b/docs/source/guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/cfg_partition.rst index b4aeccd6b..f8a6f5b30 100644 --- a/docs/source/guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/cfg_partition.rst +++ b/docs/source/guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/cfg_partition.rst @@ -31,7 +31,7 @@ Partitioning disk file(For Ubuntu only) .. include:: ../../../common/deployment/cfg_partition.rst :start-after: BEGIN_Partition_Disk_File_ubuntu_only :end-before: END_Partition_Disk_File_ubuntu_only - + Additional preseed configuration file(For Ubuntu only) `````````````````````````````````````````````````````` .. include:: ../../../common/deployment/cfg_partition.rst @@ -64,14 +64,14 @@ Associate partition script with osimage :start-after: BEGIN_Partition_Definition_Script_Associate_partition_script_with_osimage_common :end-before: END_Partition_Definition_Script_Associate_partition_script_with_osimage_common -Partitioning disk script(For Ubuntu only) -````````````````````````````````````````` +Partitioning disk script (For Ubuntu only) +`````````````````````````````````````````` .. include:: ../../../common/deployment/cfg_partition.rst :start-after: BEGIN_Partition_Disk_Script_ubuntu_only :end-before: END_Partition_Disk_Script_ubuntu_only -Additional preseed configuration script(For Ubuntu only) -```````````````````````````````````````````````````````` +Additional preseed configuration script (For Ubuntu only) +````````````````````````````````````````````````````````` .. include:: ../../../common/deployment/cfg_partition.rst :start-after: BEGIN_Additional_preseed_configuration_script_ubuntu_only :end-before: END_Additional_preseed_configuration_script_ubuntu_only