* [Cluster-devel] cluster/ccs/man cluster.conf.5
@ 2006-07-25 20:20 rpeterso
0 siblings, 0 replies; 8+ messages in thread
From: rpeterso @ 2006-07-25 20:20 UTC (permalink / raw)
To: cluster-devel.redhat.com
CVSROOT: /cvs/cluster
Module name: cluster
Changes by: rpeterso at sourceware.org 2006-07-25 20:20:09
Modified files:
ccs/man : cluster.conf.5
Log message:
Switch was specified incorrectly for apc power switch.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/ccs/man/cluster.conf.5.diff?cvsroot=cluster&r1=1.4&r2=1.5
--- cluster/ccs/man/cluster.conf.5 2005/02/16 18:44:09 1.4
+++ cluster/ccs/man/cluster.conf.5 2006/07/25 20:20:09 1.5
@@ -84,7 +84,7 @@
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
- <device name="apc" port="1:1"/>
+ <device name="apc" switch="1" port="1"/>
</method>
<!-- If the "power" method fails,
try fencing through the "fabric" -->
@@ -110,7 +110,7 @@
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
- <device name="apc" port="1:1"/>
+ <device name="apc" switch="1" port="1"/>
</method>
<!-- If the "power" method fails,
try fencing through the "fabric" -->
@@ -128,7 +128,7 @@
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
- <device name="apc" port="1:2"/>
+ <device name="apc" switch="1" port="2"/>
</method>
<!-- If the "power" method fails,
try fencing through the "fabric" -->
@@ -147,7 +147,7 @@
<!-- "power" method is tried before all others -->
<method name="power">
<!-- This machine has 2 power supplies -->
- <device name="apc" port="2:1"/>
+ <device name="apc" switch="2" port="1"/>
<device name="wti" port="1"/>
</method>
<!-- If the "power" method fails,
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] cluster/ccs/man cluster.conf.5
@ 2006-11-29 16:28 rpeterso
0 siblings, 0 replies; 8+ messages in thread
From: rpeterso @ 2006-11-29 16:28 UTC (permalink / raw)
To: cluster-devel.redhat.com
CVSROOT: /cvs/cluster
Module name: cluster
Changes by: rpeterso at sourceware.org 2006-11-29 16:28:59
Modified files:
ccs/man : cluster.conf.5
Log message:
Resolves: bz217436: Several updates needed to cluster.conf man page.
1. Added required nodeid="x" to cluster.conf example.
2. Added <cman/> tag to cluster.conf example.
3. Added section on cluster.conf validation (Credit Jim Parsons)
4. Fixed spelling and grammar problems.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/ccs/man/cluster.conf.5.diff?cvsroot=cluster&r1=1.5&r2=1.6
--- cluster/ccs/man/cluster.conf.5 2006/07/25 20:20:09 1.5
+++ cluster/ccs/man/cluster.conf.5 2006/11/29 16:28:58 1.6
@@ -11,22 +11,22 @@
The \fBcluster.conf\fP file is located in the /etc/cluster directory. It
is the source of information used by the cluster products - accessed
indirectly through CCS (see \fBccs(7)\fP). This file contains all the
-information needed for the cluster to operate, such as: what nodes compose
+information needed for the cluster to operate, such as: what nodes are in
the cluster and how to I/O fence those nodes. There is generic information
-which is applicable to all cluster infrastructures, as well as specific
-information relevent for specific cluster products.
+that is applicable to all cluster infrastructures, as well as specific
+information relevant for specific cluster products.
This man page describes the generic contents of the \fBcluster.conf\fP file.
The product specific sections of \fBcluster.conf\fP are left to their
respective man pages. For example, after constructing the generic content,
-a user would look at the \fBlock_gulmd(5)\fP man page for specific instructions
+a user should look at the \fBlock_gulmd(5)\fP man page for specific instructions
if using lock_gulmd as their lock server. Conversely, a user employing
-\fBcman\fP and the \fBdlm\fP would look at \fBcman(5)\fP and \fBdlm(5)\fP for
+\fBcman\fP and the \fBdlm\fP locking protocol should look at \fBcman(5)\fP and \fBdlm(5)\fP for
further instruction.
-The \fBcluster.conf\fP file is an XML file. It has one encompasing section
+The \fBcluster.conf\fP file is an XML file. It has one encompassing section
in which everything is contained. That entity's name is \fIcluster\fP and it
-has two manditory attributes: \fIname\fP and \fIconfig_version\fP. The
+has two mandatory attributes: \fIname\fP and \fIconfig_version\fP. The
\fIname\fP attribute specifies the name of the cluster. It is important
that this name is unique from other clusters the user might set up. The
\fIconfig_version\fP attribute is a number used to identify the revision
@@ -37,7 +37,10 @@
</cluster>
-A manditory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
+The users should specify a <cman/> tag or a <gulm/> tag to indicate the
+locking protocol used for the cluster.
+
+A mandatory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
all of the I/O fencing devices at the disposal of the cluster. The I/O
fencing devices are listed as entities designated as \fIfencedevice\fP and have
attributes that describe the particular fencing device. For example:
@@ -49,11 +52,12 @@
Concerning the \fIfencedevice\fP entity, the \fIname\fP and \fIagent\fP attributes
must be specified for all I/O fence devices. The remaining attributes are
-device specific and are used to specify the neccessary information to
+device specific and are used to specify the necessary information to
access the device. The \fIname\fP attribute must be unique and is used to
reference the I/O fence device in other sections of the \fBcluster.conf\fP file. The \fIagent\fP attribute is used to specify the binary fence agent program used to communicate with the particular device. Your \fBcluster.conf\fP file might now look something like:
<cluster name="alpha" config_version="1">
+ <cman/>
<fencedevices>
<fencedevice name="apc" agent="fence_apc"
ipaddr="apc_1" login="apc" passwd="apc"/>
@@ -69,18 +73,20 @@
</fencedevices>
</cluster>
-The final manditory subsection of \fIcluster\fP is \fIclusternodes\fP. It contains
+The final mandatory subsection of \fIcluster\fP is \fIclusternodes\fP. It contains
the individual specification of all the machines (members) in the cluster.
-Each machine has it's own section, \fIclusternode\fP, which has the \fIname\fP
-attribute - this should be the name of the machine. The \fIclusternode\fP section
+Each machine has its own section, \fIclusternode\fP, which has the \fIname\fP
+attribute - this should be the name of the machine. Each machine should be
+given a unique node id number with the option \fInodeid\fP attribute.
+For example, nodeid="3". The \fIclusternode\fP section
also contains the \fIfence\fP section. Not to be confused with \fIfencedevices\fP the \fIfence\fP section is used to specify all the possible "methods" for
fencing a particular machine, as well as the device used to perform that method
-and the machine specific parameters neccessary. By example, the \fIclusternodes\fP
+and the machine specific parameters necessary. By example, the \fIclusternodes\fP
section may look as follows:
<!-- This example only contains one machine -->
<clusternodes>
- <clusternode name="nd01">
+ <clusternode name="nd01" nodeid="1">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -105,8 +111,9 @@
<cluster name="example" config_version="1">
+ <cman/>
<clusternodes>
- <clusternode name="nd01">
+ <clusternode name="nd01" nodeid="1">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -124,7 +131,7 @@
</method>
</fence>
</clusternode>
- <clusternode name="nd02">
+ <clusternode name="nd02" nodeid="2">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -142,7 +149,7 @@
</method>
</fence>
</clusternode>
- <clusternode name="nd11">
+ <clusternode name="nd11" nodeid="3">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -179,6 +186,39 @@
</fencedevices>
</cluster>
+\fBSpecial two-node cluster options:\fP
+
+Two-node clusters have special options in cluster.conf because they need to
+decide quorum between them without a majority of votes. These options are
+placed with the <cman/> tag. For example:
+
+
+ <cman two_node="1" expected_votes="1"/>
+
+
+\fBValidating your cluster.conf file:\fP
+
+While cluster.conf files produced by the system-config-cluster GUI are pretty
+certain to be well-formed, it is convenient to have a way to validate legacy
+configuration files, or files that were produced by hand in an editor. If you
+have the system-config-cluster GUI, you can validate a cluster.conf file with
+this command:
+
+xmllint --relaxng /usr/share/system-config-cluster/misc/cluster.ng /etc/cluster/cluster.conf
+
+If validation errors are detected in your conf file, the first place to start
+is with the first error. Sometimes addressing the first error will remove
+all error messages. Another good troubleshooting approach is to comment out
+sections of the conf file. For example, it is okay to have nothing beneath
+the <rm> tag. If you have services, failoverdomains and resources defined
+there, temporarily comment them all out and rerun xmllint to see if the
+problems go away. This may help you locate the problem. Errors that
+contain the string IDREF mean that an attribute value is supposed to be
+shared two places in the file, and that no other instance of the name string
+could be located. Finally, the most common problem with hand-edited
+cluster.conf files is spelling errors. Check your attribute and tag names
+carefully.
+
.SH SEE ALSO
ccs(7), ccs_tool(8), lock_gulmd(5), cman(5)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] cluster/ccs/man cluster.conf.5
@ 2006-11-29 16:30 rpeterso
0 siblings, 0 replies; 8+ messages in thread
From: rpeterso @ 2006-11-29 16:30 UTC (permalink / raw)
To: cluster-devel.redhat.com
CVSROOT: /cvs/cluster
Module name: cluster
Branch: RHEL5
Changes by: rpeterso at sourceware.org 2006-11-29 16:30:30
Modified files:
ccs/man : cluster.conf.5
Log message:
Resolves: bz217436: Several updates needed to cluster.conf man page.
1. Added required nodeid="x" to cluster.conf example.
2. Added <cman/> tag to cluster.conf example.
3. Added section on cluster.conf validation (Credit Jim Parsons)
4. Fixed spelling and grammar problems.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/ccs/man/cluster.conf.5.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.5&r2=1.5.2.1
--- cluster/ccs/man/cluster.conf.5 2006/07/25 20:20:09 1.5
+++ cluster/ccs/man/cluster.conf.5 2006/11/29 16:30:30 1.5.2.1
@@ -11,22 +11,22 @@
The \fBcluster.conf\fP file is located in the /etc/cluster directory. It
is the source of information used by the cluster products - accessed
indirectly through CCS (see \fBccs(7)\fP). This file contains all the
-information needed for the cluster to operate, such as: what nodes compose
+information needed for the cluster to operate, such as: what nodes are in
the cluster and how to I/O fence those nodes. There is generic information
-which is applicable to all cluster infrastructures, as well as specific
-information relevent for specific cluster products.
+that is applicable to all cluster infrastructures, as well as specific
+information relevant for specific cluster products.
This man page describes the generic contents of the \fBcluster.conf\fP file.
The product specific sections of \fBcluster.conf\fP are left to their
respective man pages. For example, after constructing the generic content,
-a user would look at the \fBlock_gulmd(5)\fP man page for specific instructions
+a user should look at the \fBlock_gulmd(5)\fP man page for specific instructions
if using lock_gulmd as their lock server. Conversely, a user employing
-\fBcman\fP and the \fBdlm\fP would look at \fBcman(5)\fP and \fBdlm(5)\fP for
+\fBcman\fP and the \fBdlm\fP locking protocol should look at \fBcman(5)\fP and \fBdlm(5)\fP for
further instruction.
-The \fBcluster.conf\fP file is an XML file. It has one encompasing section
+The \fBcluster.conf\fP file is an XML file. It has one encompassing section
in which everything is contained. That entity's name is \fIcluster\fP and it
-has two manditory attributes: \fIname\fP and \fIconfig_version\fP. The
+has two mandatory attributes: \fIname\fP and \fIconfig_version\fP. The
\fIname\fP attribute specifies the name of the cluster. It is important
that this name is unique from other clusters the user might set up. The
\fIconfig_version\fP attribute is a number used to identify the revision
@@ -37,7 +37,10 @@
</cluster>
-A manditory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
+The users should specify a <cman/> tag or a <gulm/> tag to indicate the
+locking protocol used for the cluster.
+
+A mandatory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
all of the I/O fencing devices at the disposal of the cluster. The I/O
fencing devices are listed as entities designated as \fIfencedevice\fP and have
attributes that describe the particular fencing device. For example:
@@ -49,11 +52,12 @@
Concerning the \fIfencedevice\fP entity, the \fIname\fP and \fIagent\fP attributes
must be specified for all I/O fence devices. The remaining attributes are
-device specific and are used to specify the neccessary information to
+device specific and are used to specify the necessary information to
access the device. The \fIname\fP attribute must be unique and is used to
reference the I/O fence device in other sections of the \fBcluster.conf\fP file. The \fIagent\fP attribute is used to specify the binary fence agent program used to communicate with the particular device. Your \fBcluster.conf\fP file might now look something like:
<cluster name="alpha" config_version="1">
+ <cman/>
<fencedevices>
<fencedevice name="apc" agent="fence_apc"
ipaddr="apc_1" login="apc" passwd="apc"/>
@@ -69,18 +73,20 @@
</fencedevices>
</cluster>
-The final manditory subsection of \fIcluster\fP is \fIclusternodes\fP. It contains
+The final mandatory subsection of \fIcluster\fP is \fIclusternodes\fP. It contains
the individual specification of all the machines (members) in the cluster.
-Each machine has it's own section, \fIclusternode\fP, which has the \fIname\fP
-attribute - this should be the name of the machine. The \fIclusternode\fP section
+Each machine has its own section, \fIclusternode\fP, which has the \fIname\fP
+attribute - this should be the name of the machine. Each machine should be
+given a unique node id number with the option \fInodeid\fP attribute.
+For example, nodeid="3". The \fIclusternode\fP section
also contains the \fIfence\fP section. Not to be confused with \fIfencedevices\fP the \fIfence\fP section is used to specify all the possible "methods" for
fencing a particular machine, as well as the device used to perform that method
-and the machine specific parameters neccessary. By example, the \fIclusternodes\fP
+and the machine specific parameters necessary. By example, the \fIclusternodes\fP
section may look as follows:
<!-- This example only contains one machine -->
<clusternodes>
- <clusternode name="nd01">
+ <clusternode name="nd01" nodeid="1">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -105,8 +111,9 @@
<cluster name="example" config_version="1">
+ <cman/>
<clusternodes>
- <clusternode name="nd01">
+ <clusternode name="nd01" nodeid="1">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -124,7 +131,7 @@
</method>
</fence>
</clusternode>
- <clusternode name="nd02">
+ <clusternode name="nd02" nodeid="2">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -142,7 +149,7 @@
</method>
</fence>
</clusternode>
- <clusternode name="nd11">
+ <clusternode name="nd11" nodeid="3">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -179,6 +186,39 @@
</fencedevices>
</cluster>
+\fBSpecial two-node cluster options:\fP
+
+Two-node clusters have special options in cluster.conf because they need to
+decide quorum between them without a majority of votes. These options are
+placed with the <cman/> tag. For example:
+
+
+ <cman two_node="1" expected_votes="1"/>
+
+
+\fBValidating your cluster.conf file:\fP
+
+While cluster.conf files produced by the system-config-cluster GUI are pretty
+certain to be well-formed, it is convenient to have a way to validate legacy
+configuration files, or files that were produced by hand in an editor. If you
+have the system-config-cluster GUI, you can validate a cluster.conf file with
+this command:
+
+xmllint --relaxng /usr/share/system-config-cluster/misc/cluster.ng /etc/cluster/cluster.conf
+
+If validation errors are detected in your conf file, the first place to start
+is with the first error. Sometimes addressing the first error will remove
+all error messages. Another good troubleshooting approach is to comment out
+sections of the conf file. For example, it is okay to have nothing beneath
+the <rm> tag. If you have services, failoverdomains and resources defined
+there, temporarily comment them all out and rerun xmllint to see if the
+problems go away. This may help you locate the problem. Errors that
+contain the string IDREF mean that an attribute value is supposed to be
+shared two places in the file, and that no other instance of the name string
+could be located. Finally, the most common problem with hand-edited
+cluster.conf files is spelling errors. Check your attribute and tag names
+carefully.
+
.SH SEE ALSO
ccs(7), ccs_tool(8), lock_gulmd(5), cman(5)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] cluster/ccs/man cluster.conf.5
@ 2006-11-29 16:33 rpeterso
0 siblings, 0 replies; 8+ messages in thread
From: rpeterso @ 2006-11-29 16:33 UTC (permalink / raw)
To: cluster-devel.redhat.com
CVSROOT: /cvs/cluster
Module name: cluster
Branch: RHEL50
Changes by: rpeterso at sourceware.org 2006-11-29 16:33:53
Modified files:
ccs/man : cluster.conf.5
Log message:
Resolves: bz217436: Several updates needed to cluster.conf man page.
1. Added required nodeid="x" to cluster.conf example.
2. Added <cman/> tag to cluster.conf example.
3. Added section on cluster.conf validation (Credit Jim Parsons)
4. Fixed spelling and grammar problems.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/ccs/man/cluster.conf.5.diff?cvsroot=cluster&only_with_tag=RHEL50&r1=1.5&r2=1.5.4.1
--- cluster/ccs/man/cluster.conf.5 2006/07/25 20:20:09 1.5
+++ cluster/ccs/man/cluster.conf.5 2006/11/29 16:33:53 1.5.4.1
@@ -11,22 +11,22 @@
The \fBcluster.conf\fP file is located in the /etc/cluster directory. It
is the source of information used by the cluster products - accessed
indirectly through CCS (see \fBccs(7)\fP). This file contains all the
-information needed for the cluster to operate, such as: what nodes compose
+information needed for the cluster to operate, such as: what nodes are in
the cluster and how to I/O fence those nodes. There is generic information
-which is applicable to all cluster infrastructures, as well as specific
-information relevent for specific cluster products.
+that is applicable to all cluster infrastructures, as well as specific
+information relevant for specific cluster products.
This man page describes the generic contents of the \fBcluster.conf\fP file.
The product specific sections of \fBcluster.conf\fP are left to their
respective man pages. For example, after constructing the generic content,
-a user would look at the \fBlock_gulmd(5)\fP man page for specific instructions
+a user should look at the \fBlock_gulmd(5)\fP man page for specific instructions
if using lock_gulmd as their lock server. Conversely, a user employing
-\fBcman\fP and the \fBdlm\fP would look at \fBcman(5)\fP and \fBdlm(5)\fP for
+\fBcman\fP and the \fBdlm\fP locking protocol should look at \fBcman(5)\fP and \fBdlm(5)\fP for
further instruction.
-The \fBcluster.conf\fP file is an XML file. It has one encompasing section
+The \fBcluster.conf\fP file is an XML file. It has one encompassing section
in which everything is contained. That entity's name is \fIcluster\fP and it
-has two manditory attributes: \fIname\fP and \fIconfig_version\fP. The
+has two mandatory attributes: \fIname\fP and \fIconfig_version\fP. The
\fIname\fP attribute specifies the name of the cluster. It is important
that this name is unique from other clusters the user might set up. The
\fIconfig_version\fP attribute is a number used to identify the revision
@@ -37,7 +37,10 @@
</cluster>
-A manditory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
+The users should specify a <cman/> tag or a <gulm/> tag to indicate the
+locking protocol used for the cluster.
+
+A mandatory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
all of the I/O fencing devices at the disposal of the cluster. The I/O
fencing devices are listed as entities designated as \fIfencedevice\fP and have
attributes that describe the particular fencing device. For example:
@@ -49,11 +52,12 @@
Concerning the \fIfencedevice\fP entity, the \fIname\fP and \fIagent\fP attributes
must be specified for all I/O fence devices. The remaining attributes are
-device specific and are used to specify the neccessary information to
+device specific and are used to specify the necessary information to
access the device. The \fIname\fP attribute must be unique and is used to
reference the I/O fence device in other sections of the \fBcluster.conf\fP file. The \fIagent\fP attribute is used to specify the binary fence agent program used to communicate with the particular device. Your \fBcluster.conf\fP file might now look something like:
<cluster name="alpha" config_version="1">
+ <cman/>
<fencedevices>
<fencedevice name="apc" agent="fence_apc"
ipaddr="apc_1" login="apc" passwd="apc"/>
@@ -69,18 +73,20 @@
</fencedevices>
</cluster>
-The final manditory subsection of \fIcluster\fP is \fIclusternodes\fP. It contains
+The final mandatory subsection of \fIcluster\fP is \fIclusternodes\fP. It contains
the individual specification of all the machines (members) in the cluster.
-Each machine has it's own section, \fIclusternode\fP, which has the \fIname\fP
-attribute - this should be the name of the machine. The \fIclusternode\fP section
+Each machine has its own section, \fIclusternode\fP, which has the \fIname\fP
+attribute - this should be the name of the machine. Each machine should be
+given a unique node id number with the option \fInodeid\fP attribute.
+For example, nodeid="3". The \fIclusternode\fP section
also contains the \fIfence\fP section. Not to be confused with \fIfencedevices\fP the \fIfence\fP section is used to specify all the possible "methods" for
fencing a particular machine, as well as the device used to perform that method
-and the machine specific parameters neccessary. By example, the \fIclusternodes\fP
+and the machine specific parameters necessary. By example, the \fIclusternodes\fP
section may look as follows:
<!-- This example only contains one machine -->
<clusternodes>
- <clusternode name="nd01">
+ <clusternode name="nd01" nodeid="1">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -105,8 +111,9 @@
<cluster name="example" config_version="1">
+ <cman/>
<clusternodes>
- <clusternode name="nd01">
+ <clusternode name="nd01" nodeid="1">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -124,7 +131,7 @@
</method>
</fence>
</clusternode>
- <clusternode name="nd02">
+ <clusternode name="nd02" nodeid="2">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -142,7 +149,7 @@
</method>
</fence>
</clusternode>
- <clusternode name="nd11">
+ <clusternode name="nd11" nodeid="3">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
@@ -179,6 +186,39 @@
</fencedevices>
</cluster>
+\fBSpecial two-node cluster options:\fP
+
+Two-node clusters have special options in cluster.conf because they need to
+decide quorum between them without a majority of votes. These options are
+placed with the <cman/> tag. For example:
+
+
+ <cman two_node="1" expected_votes="1"/>
+
+
+\fBValidating your cluster.conf file:\fP
+
+While cluster.conf files produced by the system-config-cluster GUI are pretty
+certain to be well-formed, it is convenient to have a way to validate legacy
+configuration files, or files that were produced by hand in an editor. If you
+have the system-config-cluster GUI, you can validate a cluster.conf file with
+this command:
+
+xmllint --relaxng /usr/share/system-config-cluster/misc/cluster.ng /etc/cluster/cluster.conf
+
+If validation errors are detected in your conf file, the first place to start
+is with the first error. Sometimes addressing the first error will remove
+all error messages. Another good troubleshooting approach is to comment out
+sections of the conf file. For example, it is okay to have nothing beneath
+the <rm> tag. If you have services, failoverdomains and resources defined
+there, temporarily comment them all out and rerun xmllint to see if the
+problems go away. This may help you locate the problem. Errors that
+contain the string IDREF mean that an attribute value is supposed to be
+shared two places in the file, and that no other instance of the name string
+could be located. Finally, the most common problem with hand-edited
+cluster.conf files is spelling errors. Check your attribute and tag names
+carefully.
+
.SH SEE ALSO
ccs(7), ccs_tool(8), lock_gulmd(5), cman(5)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] cluster/ccs/man cluster.conf.5
@ 2006-11-29 17:04 rpeterso
0 siblings, 0 replies; 8+ messages in thread
From: rpeterso @ 2006-11-29 17:04 UTC (permalink / raw)
To: cluster-devel.redhat.com
CVSROOT: /cvs/cluster
Module name: cluster
Changes by: rpeterso at sourceware.org 2006-11-29 17:04:32
Modified files:
ccs/man : cluster.conf.5
Log message:
Resolves: bz217436: Several updates needed to cluster.conf man page.
1. Removed references to gulm.
2. Other misc changes.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/ccs/man/cluster.conf.5.diff?cvsroot=cluster&r1=1.6&r2=1.7
--- cluster/ccs/man/cluster.conf.5 2006/11/29 16:28:58 1.6
+++ cluster/ccs/man/cluster.conf.5 2006/11/29 17:04:31 1.7
@@ -19,10 +19,8 @@
This man page describes the generic contents of the \fBcluster.conf\fP file.
The product specific sections of \fBcluster.conf\fP are left to their
respective man pages. For example, after constructing the generic content,
-a user should look at the \fBlock_gulmd(5)\fP man page for specific instructions
-if using lock_gulmd as their lock server. Conversely, a user employing
-\fBcman\fP and the \fBdlm\fP locking protocol should look at \fBcman(5)\fP and \fBdlm(5)\fP for
-further instruction.
+a user should look at the \fBcman(5)\fP man page for further information
+about the \fBcman\fP section of cluster.conf.
The \fBcluster.conf\fP file is an XML file. It has one encompassing section
in which everything is contained. That entity's name is \fIcluster\fP and it
@@ -37,8 +35,8 @@
</cluster>
-The users should specify a <cman/> tag or a <gulm/> tag to indicate the
-locking protocol used for the cluster.
+You should specify a <cman/> tag even if no special cman parameters
+are needed for the cluster.
A mandatory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
all of the I/O fencing devices at the disposal of the cluster. The I/O
@@ -220,5 +218,5 @@
carefully.
.SH SEE ALSO
-ccs(7), ccs_tool(8), lock_gulmd(5), cman(5)
+ccs(7), ccs_tool(8), cman(5)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] cluster/ccs/man cluster.conf.5
@ 2006-11-29 17:05 rpeterso
0 siblings, 0 replies; 8+ messages in thread
From: rpeterso @ 2006-11-29 17:05 UTC (permalink / raw)
To: cluster-devel.redhat.com
CVSROOT: /cvs/cluster
Module name: cluster
Branch: RHEL5
Changes by: rpeterso at sourceware.org 2006-11-29 17:05:20
Modified files:
ccs/man : cluster.conf.5
Log message:
Resolves: bz217436: Several updates needed to cluster.conf man page.
1. Removed references to gulm.
2. Other misc changes.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/ccs/man/cluster.conf.5.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.5.2.1&r2=1.5.2.2
--- cluster/ccs/man/cluster.conf.5 2006/11/29 16:30:30 1.5.2.1
+++ cluster/ccs/man/cluster.conf.5 2006/11/29 17:05:19 1.5.2.2
@@ -19,10 +19,8 @@
This man page describes the generic contents of the \fBcluster.conf\fP file.
The product specific sections of \fBcluster.conf\fP are left to their
respective man pages. For example, after constructing the generic content,
-a user should look at the \fBlock_gulmd(5)\fP man page for specific instructions
-if using lock_gulmd as their lock server. Conversely, a user employing
-\fBcman\fP and the \fBdlm\fP locking protocol should look at \fBcman(5)\fP and \fBdlm(5)\fP for
-further instruction.
+a user should look at the \fBcman(5)\fP man page for further information
+about the \fBcman\fP section of cluster.conf.
The \fBcluster.conf\fP file is an XML file. It has one encompassing section
in which everything is contained. That entity's name is \fIcluster\fP and it
@@ -37,8 +35,8 @@
</cluster>
-The users should specify a <cman/> tag or a <gulm/> tag to indicate the
-locking protocol used for the cluster.
+You should specify a <cman/> tag even if no special cman parameters
+are needed for the cluster.
A mandatory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
all of the I/O fencing devices at the disposal of the cluster. The I/O
@@ -220,5 +218,5 @@
carefully.
.SH SEE ALSO
-ccs(7), ccs_tool(8), lock_gulmd(5), cman(5)
+ccs(7), ccs_tool(8), cman(5)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] cluster/ccs/man cluster.conf.5
@ 2006-11-29 17:05 rpeterso
0 siblings, 0 replies; 8+ messages in thread
From: rpeterso @ 2006-11-29 17:05 UTC (permalink / raw)
To: cluster-devel.redhat.com
CVSROOT: /cvs/cluster
Module name: cluster
Branch: RHEL50
Changes by: rpeterso at sourceware.org 2006-11-29 17:05:36
Modified files:
ccs/man : cluster.conf.5
Log message:
Resolves: bz217436: Several updates needed to cluster.conf man page.
1. Removed references to gulm.
2. Other misc changes.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/ccs/man/cluster.conf.5.diff?cvsroot=cluster&only_with_tag=RHEL50&r1=1.5.4.1&r2=1.5.4.2
--- cluster/ccs/man/cluster.conf.5 2006/11/29 16:33:53 1.5.4.1
+++ cluster/ccs/man/cluster.conf.5 2006/11/29 17:05:35 1.5.4.2
@@ -19,10 +19,8 @@
This man page describes the generic contents of the \fBcluster.conf\fP file.
The product specific sections of \fBcluster.conf\fP are left to their
respective man pages. For example, after constructing the generic content,
-a user should look at the \fBlock_gulmd(5)\fP man page for specific instructions
-if using lock_gulmd as their lock server. Conversely, a user employing
-\fBcman\fP and the \fBdlm\fP locking protocol should look at \fBcman(5)\fP and \fBdlm(5)\fP for
-further instruction.
+a user should look at the \fBcman(5)\fP man page for further information
+about the \fBcman\fP section of cluster.conf.
The \fBcluster.conf\fP file is an XML file. It has one encompassing section
in which everything is contained. That entity's name is \fIcluster\fP and it
@@ -37,8 +35,8 @@
</cluster>
-The users should specify a <cman/> tag or a <gulm/> tag to indicate the
-locking protocol used for the cluster.
+You should specify a <cman/> tag even if no special cman parameters
+are needed for the cluster.
A mandatory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
all of the I/O fencing devices at the disposal of the cluster. The I/O
@@ -220,5 +218,5 @@
carefully.
.SH SEE ALSO
-ccs(7), ccs_tool(8), lock_gulmd(5), cman(5)
+ccs(7), ccs_tool(8), cman(5)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] cluster/ccs/man cluster.conf.5
@ 2007-08-17 18:27 teigland
0 siblings, 0 replies; 8+ messages in thread
From: teigland @ 2007-08-17 18:27 UTC (permalink / raw)
To: cluster-devel.redhat.com
CVSROOT: /cvs/cluster
Module name: cluster
Changes by: teigland at sourceware.org 2007-08-17 18:27:13
Modified files:
ccs/man : cluster.conf.5
Log message:
Vastly simplify this man page. Include no cman or fencing information
but refer to the cman and fenced pages.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/ccs/man/cluster.conf.5.diff?cvsroot=cluster&r1=1.7&r2=1.8
--- cluster/ccs/man/cluster.conf.5 2006/11/29 17:04:31 1.7
+++ cluster/ccs/man/cluster.conf.5 2007/08/17 18:27:13 1.8
@@ -1,222 +1,65 @@
.\"
.\" Copyright 2001-2003 Sistina Software, Inc.
-.\" Copyright (C) 2004 Red Hat, Inc. All rights reserved.
+.\" Copyright (C) 2004-2007 Red Hat, Inc. All rights reserved.
.TH cluster.conf 5
.SH NAME
-cluster.conf - The configuration file for cluster products
+cluster.conf - configuration file for cman, fence, dlm, gfs, rgmanager
.SH DESCRIPTION
+
The \fBcluster.conf\fP file is located in the /etc/cluster directory. It
-is the source of information used by the cluster products - accessed
-indirectly through CCS (see \fBccs(7)\fP). This file contains all the
-information needed for the cluster to operate, such as: what nodes are in
-the cluster and how to I/O fence those nodes. There is generic information
-that is applicable to all cluster infrastructures, as well as specific
-information relevant for specific cluster products.
-
-This man page describes the generic contents of the \fBcluster.conf\fP file.
-The product specific sections of \fBcluster.conf\fP are left to their
-respective man pages. For example, after constructing the generic content,
-a user should look at the \fBcman(5)\fP man page for further information
-about the \fBcman\fP section of cluster.conf.
-
-The \fBcluster.conf\fP file is an XML file. It has one encompassing section
-in which everything is contained. That entity's name is \fIcluster\fP and it
-has two mandatory attributes: \fIname\fP and \fIconfig_version\fP. The
-\fIname\fP attribute specifies the name of the cluster. It is important
-that this name is unique from other clusters the user might set up. The
-\fIconfig_version\fP attribute is a number used to identify the revision
-level of the \fBcluster.conf\fP file. Given this information, your
+is the source of information used by cman, fence, dlm, gfs and rgmanager.
+It's accessed indirectly through libccs (see \fBccs(7)\fP). This file
+contains all the information needed for the cluster to operate, such as
+what nodes are in the cluster and how to I/O fence those nodes.
+
+This man page describes the generic contents of the \fBcluster.conf\fP
+file. For other information see man pages for cman(5), fenced(8) and
+dlm_controld(8).
+
+\fBcluster.conf\fP is an XML file. It has one top-level \fIcluster\fP
+section containing everything else. The cluster section has two mandatory
+attributes: \fIname\fP and \fIconfig_version\fP. \fIname\fP can be up to
+16 characters long and specifies the name of the cluster. It is important
+that this name is unique from other clusters the user might set up.
+\fIconfig_version\fP is a number used to identify the revision level of
+the \fBcluster.conf\fP file. Given this information, your
\fBcluster.conf\fP file might look something like:
-<cluster name="alpha" config_version="1">
+ <cluster name="alpha" config_version="1">
+ </cluster>
-</cluster>
+.SS Nodes
-You should specify a <cman/> tag even if no special cman parameters
-are needed for the cluster.
+The set of nodes that make up the cluster are defined under the
+\fIclusternodes\fP section. A \fIclusternode\fP section defines each
+node. A clusternode has two mandatory attributes:
+.I name
+and
+.I nodeid
+
+The name should correspond to the hostname (the fully qualified name is
+generally not necessary) on the network interface to be used for cluster
+communication. Nodeid's must be greater than zero and unique.
+
+ <cluster name="alpha" config_version="1">
+ <clusternodes>
+ <clusternode name="node-01" nodeid="1">
+ </clusternode>
+
+ <clusternode name="node-02" nodeid="2">
+ </clusternode>
+
+ <clusternode name="node-03" nodeid="3">
+ </clusternode>
+ </clusternodes>
+ </cluster>
-A mandatory subsection of \fIcluster\fP is \fIfencedevices\fP. It contains
-all of the I/O fencing devices at the disposal of the cluster. The I/O
-fencing devices are listed as entities designated as \fIfencedevice\fP and have
-attributes that describe the particular fencing device. For example:
-
- <fencedevices>
- <fencedevice name="apc" agent="fence_apc"
- ipaddr="apc_1" login="apc" passwd="apc"/>
- </fencedevices>
-
-Concerning the \fIfencedevice\fP entity, the \fIname\fP and \fIagent\fP attributes
-must be specified for all I/O fence devices. The remaining attributes are
-device specific and are used to specify the necessary information to
-access the device. The \fIname\fP attribute must be unique and is used to
-reference the I/O fence device in other sections of the \fBcluster.conf\fP file. The \fIagent\fP attribute is used to specify the binary fence agent program used to communicate with the particular device. Your \fBcluster.conf\fP file might now look something like:
-
-<cluster name="alpha" config_version="1">
- <cman/>
- <fencedevices>
- <fencedevice name="apc" agent="fence_apc"
- ipaddr="apc_1" login="apc" passwd="apc"/>
-
- <fencedevice name="brocade" agent="fence_brocade"
- ipaddr="brocade_1" login="bro" passwd="bro"/>
-
- <!-- The WTI fence device requires no login name -->
- <fencedevice name="wti" agent="fence_wti"
- ipaddr="wti_1" passwd="wti"/>
-
- <fencedevice name="last_resort" agent="fence_manual"/>
- </fencedevices>
-</cluster>
-
-The final mandatory subsection of \fIcluster\fP is \fIclusternodes\fP. It contains
-the individual specification of all the machines (members) in the cluster.
-Each machine has its own section, \fIclusternode\fP, which has the \fIname\fP
-attribute - this should be the name of the machine. Each machine should be
-given a unique node id number with the option \fInodeid\fP attribute.
-For example, nodeid="3". The \fIclusternode\fP section
-also contains the \fIfence\fP section. Not to be confused with \fIfencedevices\fP the \fIfence\fP section is used to specify all the possible "methods" for
-fencing a particular machine, as well as the device used to perform that method
-and the machine specific parameters necessary. By example, the \fIclusternodes\fP
-section may look as follows:
-
- <!-- This example only contains one machine -->
- <clusternodes>
- <clusternode name="nd01" nodeid="1">
- <fence>
- <!-- "power" method is tried before all others -->
- <method name="power">
- <device name="apc" switch="1" port="1"/>
- </method>
- <!-- If the "power" method fails,
- try fencing through the "fabric" -->
- <method name="fabric">
- <device name="brocade" port="1"/>
- </method>
- <!-- If all else fails,
- make someone do it manually -->
- <method name="human">
- <device name="last_resort" ipaddr="nd01"/>
- </method>
- </fence>
- </clusternode>
- </clusternodes>
-
-Putting it all together, a three node cluster's \fBcluster.conf\fP file
-might look like:
-
-
-<cluster name="example" config_version="1">
- <cman/>
- <clusternodes>
- <clusternode name="nd01" nodeid="1">
- <fence>
- <!-- "power" method is tried before all others -->
- <method name="power">
- <device name="apc" switch="1" port="1"/>
- </method>
- <!-- If the "power" method fails,
- try fencing through the "fabric" -->
- <method name="fabric">
- <device name="brocade" port="1"/>
- </method>
- <!-- If all else fails,
- make someone do it manually -->
- <method name="human">
- <device name="last_resort" ipaddr="nd01"/>
- </method>
- </fence>
- </clusternode>
- <clusternode name="nd02" nodeid="2">
- <fence>
- <!-- "power" method is tried before all others -->
- <method name="power">
- <device name="apc" switch="1" port="2"/>
- </method>
- <!-- If the "power" method fails,
- try fencing through the "fabric" -->
- <method name="fabric">
- <device name="brocade" port="2"/>
- </method>
- <!-- If all else fails,
- make someone do it manually -->
- <method name="human">
- <device name="last_resort" ipaddr="nd02"/>
- </method>
- </fence>
- </clusternode>
- <clusternode name="nd11" nodeid="3">
- <fence>
- <!-- "power" method is tried before all others -->
- <method name="power">
- <!-- This machine has 2 power supplies -->
- <device name="apc" switch="2" port="1"/>
- <device name="wti" port="1"/>
- </method>
- <!-- If the "power" method fails,
- try fencing through the "fabric" -->
- <method name="fabric">
- <device name="brocade" port="11"/>
- </method>
- <!-- If all else fails,
- make someone do it manually -->
- <method name="human">
- <device name="last_resort" ipaddr="nd11"/>
- </method>
- </fence>
- </clusternode>
- </clusternodes>
-
- <fencedevices>
- <fencedevice name="apc" agent="fence_apc"
- ipaddr="apc_1" login="apc" passwd="apc"/>
-
- <fencedevice name="brocade" agent="fence_brocade"
- ipaddr="brocade_1" login="bro" passwd="bro"/>
-
- <!-- The WTI fence device requires no login name -->
- <fencedevice name="wti" agent="fence_wti"
- ipaddr="wti_1" passwd="wti"/>
-
- <fencedevice name="last_resort" agent="fence_manual"/>
- </fencedevices>
-</cluster>
-
-\fBSpecial two-node cluster options:\fP
-
-Two-node clusters have special options in cluster.conf because they need to
-decide quorum between them without a majority of votes. These options are
-placed with the <cman/> tag. For example:
-
-
- <cman two_node="1" expected_votes="1"/>
-
-
-\fBValidating your cluster.conf file:\fP
-
-While cluster.conf files produced by the system-config-cluster GUI are pretty
-certain to be well-formed, it is convenient to have a way to validate legacy
-configuration files, or files that were produced by hand in an editor. If you
-have the system-config-cluster GUI, you can validate a cluster.conf file with
-this command:
-
-xmllint --relaxng /usr/share/system-config-cluster/misc/cluster.ng /etc/cluster/cluster.conf
-
-If validation errors are detected in your conf file, the first place to start
-is with the first error. Sometimes addressing the first error will remove
-all error messages. Another good troubleshooting approach is to comment out
-sections of the conf file. For example, it is okay to have nothing beneath
-the <rm> tag. If you have services, failoverdomains and resources defined
-there, temporarily comment them all out and rerun xmllint to see if the
-problems go away. This may help you locate the problem. Errors that
-contain the string IDREF mean that an attribute value is supposed to be
-shared two places in the file, and that no other instance of the name string
-could be located. Finally, the most common problem with hand-edited
-cluster.conf files is spelling errors. Check your attribute and tag names
-carefully.
+The next step in completing cluster.conf is adding fencing information;
+see fenced(8).
.SH SEE ALSO
-ccs(7), ccs_tool(8), cman(5)
+ccs(7), ccs_tool(8), ccsd(8), cman(5), fenced(8), dlm_controld(8)
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-08-17 18:27 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-29 17:04 [Cluster-devel] cluster/ccs/man cluster.conf.5 rpeterso
-- strict thread matches above, loose matches on Subject: below --
2007-08-17 18:27 teigland
2006-11-29 17:05 rpeterso
2006-11-29 17:05 rpeterso
2006-11-29 16:33 rpeterso
2006-11-29 16:30 rpeterso
2006-11-29 16:28 rpeterso
2006-07-25 20:20 rpeterso
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).