KANIF.CONF(5) kanif.conf configuration file for kanif KANIF.CONF(5)NAME
kanif.conf - configuration file for kanif
SYNOPSIS
$HOME/.kanif.conf, /etc/kanif.conf or /etc/c3.conf
DESCRIPTION
kanif.conf is the configuration file for kanif. It is optional and only helps the management of static clusters (configurations that do not
change much over time). It mimics the syntax of C3 configuration file.
It is composed of a sequence of one or more cluster definitions. Each cluster definition is made of the word "cluster" followed by the
cluster name and, enclosed in a pair of curly braces :
o the front node specification. This is either:
o a simple hostname which can be reached from the inside of the cluster (compute nodes).
o two names separated by a colon. The first name is the name used from the outside to log on the front node (not used by kanif). The
second is the name used from the cluster compute nodes to reach the front node.
o an hostname with a colon prepended. This is used for indirect clusters. These are not supported by kanif at this time.
o zero or more compute nodes specifications:
o a simple hostname (anything that is not of the following form)
o an host set made of a prefix, a range and a suffix.
o an exclude directive that must follow an host set or another exclude directive. This is made of the word "exclude" followed on the
same line by either a single number or an interval between brackets. This applies to the range of the preceding host set. If the
exclusion is an interval, the separator between the word "exclude" and this exclusion is optional.
o a dead node. The word "dead" followed by the name of the dead node on the same line.
Notice that all nodes excluded (using exclude directives or dead nodes) will not take part of the deployment, but are still taken into
account in cluster ranges when giving machines specifications to kanif (they are kind of placeholders). This is the interest of specifying
nodes as dead or excluded rather than dropping them from the definitions.
EXAMPLE
cluster megacluster { # The # character introduce comments
megacluster-dev
megacluster0[1-9]
megacluster[10-64]
}
cluster supercluster {
super-ext:super-int
exclude # The host "exclude"
super[01-99]
exclude 02 # "super02" is excluded
exclude[90-95] # "super90" to "super95" are excluded
dead # The host "dead"
dead othernode # "othernode" is dead
}
SEE ALSO kanif(1), taktuk(1)AUTHOR
The author of kanif and current maintainer of the package is Guillaume Huard. Acknowledgements to Lucas Nussbaum for the idea of the name
"kanif".
COPYRIGHT
kanif is provided under the terms of the GNU General Public License version 2 or later.
perl v5.14.2 2012-06-22 KANIF.CONF(5)
Check Out this Related Man Page
CLUSTER.CONF(5) cluster CLUSTER.CONF(5)NAME
cluster.conf - configuration file for cman and related daemons
SYNOPSIS
/etc/cluster/cluster.conf
DESCRIPTION
When cman_tool(8) starts the corosync(8) daemon, the cluster.conf data is read into the corosync in-memory database (confdb). The configu-
ration is used by corosync, cman and other related cluster daemons and programs. When cman configures corosync with cluster.conf, the
corosync.conf(5) file is not used.
A basic cluster configuration is described below. Configuration options for other daemons/programs are described in their own man pages.
ccs_tool(8) can be used to do some basic cluster.conf editing.
The cluster.rng schema is used to validate cluster.conf. Unrecognized items will produce a warning during cluster startup, and invalid xml
structure will cause the cluster startup to fail. See ccs_config_validate(8) and ccs_config_dump(8).
Cluster
The top level cluster section contains all other sections and has two required attributes:
name The name of the cluster can be up to 15 characters long (16 including terminating null). It is important that this name be unique
among clusters on the same network.
config_version
The config_version specifies the revision level of the file and should be increased each time the file is updated.
<cluster name="alpha" config_version="1">
</cluster>
Cluster Nodes
The set of nodes that make up the cluster are defined in the clusternodes section which contains multiple clusternode sections. A clus-
ternode has two required attributes:
name The node name should correspond to the hostname on the network interface to be used for cluster communication.
nodeid The node id 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>
Logging
Cluster daemons use a common logging section to configure their loggging behavior.
<cluster name="alpha" config_version="1">
<logging/>
</cluster>
Global settings apply to all:
<logging debug="on"/>
Per-daemon logging_daemon subsections override the global settings. Daemon names that can be configured include: corosync, qdiskd, groupd,
fenced, dlm_controld, gfs_controld, rgmanager.
<logging>
<logging_daemon name="qdiskd" debug="on"/>
<logging_daemon name="fenced" debug="on"/>
</logging>
Corosync daemon settings apply to all corosync subsystems by default, but subsystems can also be configured individually. These include
CLM, CPG, MAIN, SERV, CMAN, TOTEM, QUORUM, CONFDB, CKPT, EVT.
<logging>
<logging_daemon name="corosync" subsys="QUORUM" debug="on"/>
<logging_daemon name="corosync" subsys="CONFDB" debug="on"/>
</logging>
The attributes available at global, daemon and subsystem levels are:
to_syslog
enable/disable messages to syslog (yes/no), default "yes"
to_logfile
enable/disable messages to log file (yes/no), default "yes"
syslog_facility
facility used for syslog messages, default "daemon"
syslog_priority
messages at this level and up will be sent to syslog, default "info"
logfile_priority
messages at this level and up will be written to log file, default "info"
logfile
the log file name, default /var/log/cluster/<daemon>.log
debug="on"
a shortcut for logfile_priority="debug"
EXAMPLE
An explicit configuration for the default settings would be:
<logging to_syslog="yes" to_logfile="yes" syslog_facility="daemon"
syslog_priority="info" logfile_priority="info">
<logging_daemon name="qdiskd"
logfile="/var/log/cluster/qdiskd.log"/>
<logging_daemon name="fenced"
logfile="/var/log/cluster/fenced.log"/>
<logging_daemon name="dlm_controld"
logfile="/var/log/cluster/dlm_controld.log"/>
<logging_daemon name="gfs_controld"
logfile="/var/log/cluster/gfs_controld.log"/>
<logging_daemon name="rgmanager"
logfile="/var/log/cluster/rgmanager.log"/>
<logging_daemon name="corosync"
logfile="/var/log/cluster/corosync.log"/>
</logging>
To include debug messages (and above) from all daemons in their default log files, either of the following which are equivalent:
<logging debug="on"/>
<logging logfile_priority="debug"/>
To exclude all log messages from syslog:
<logging to_syslog="no"/>
To disable logging to all log files:
<logging to_file="no"/>
To include debug messages (and above) from all daemons in syslog:
<logging syslog_priority="debug"/>
To limit syslog messages to error (and above), keeping info (and above) in log files (this logfile_priority setting is the default so could
be omitted):
<logging syslog_priority="error" logfile_priority="info"/>
FILES
/etc/cluster/cluster.conf
standard location of cluster configuration file
/usr/share/cluster/cluster.rng
standard location of cluster.conf schema
SEE ALSO ccs_tool(8), ccs_config_dump(8), ccs_config_validate(8), cman_tool(8), cman(5), qdisk(5), fenced(8), fence_node(8), dlm_controld(8),
gfs_controld(8), rgmanager(8)cluster 2010-01-12 CLUSTER.CONF(5)