• R/O
  • SSH

doc: Commit

※ リポジトリは、https://github.com/linux-ha-japan/doc-ja に移行しました。

日本語翻訳ドキュメント用リポジトリ


Commit MetaInfo

Revisión9186c700c60408d70840eacc57031cc9d6c155c6 (tree)
Tiempo2012-01-25 08:31:22
AutorJunko IKEDA <ikedaj@inte...>
CommiterJunko IKEDA

Log Message

Initial commit for pacemaker-1.0-crm-cli

Cambiar Resumen

Diferencia incremental

diff -r 000000000000 -r 9186c700c604 pacemaker-1.0-crm-cli/glossary/glossary.utf8
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/pacemaker-1.0-crm-cli/glossary/glossary.utf8 Wed Jan 25 08:31:22 2012 +0900
@@ -0,0 +1,6 @@
1+constrain 制約
2+ordering 順序制約
3+location 配置制約
4+colocation 同居制約
5+apply 適用
6+commit 反映
\ No newline at end of file
diff -r 000000000000 -r 9186c700c604 pacemaker-1.0-crm-cli/omegat.project
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/pacemaker-1.0-crm-cli/omegat.project Wed Jan 25 08:31:22 2012 +0900
@@ -0,0 +1,13 @@
1+<?xml version="1.0" encoding="UTF-8" ?>
2+<omegat>
3+ <project version="1.0">
4+ <source_dir>__DEFAULT__</source_dir>
5+ <target_dir>__DEFAULT__</target_dir>
6+ <tm_dir>__DEFAULT__</tm_dir>
7+ <glossary_dir>__DEFAULT__</glossary_dir>
8+ <dictionary_dir>__DEFAULT__</dictionary_dir>
9+ <source_lang>EN-US</source_lang>
10+ <target_lang>JA</target_lang>
11+ <sentence_seg>true</sentence_seg>
12+ </project>
13+</omegat>
diff -r 000000000000 -r 9186c700c604 pacemaker-1.0-crm-cli/omegat/project_save.tmx
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/pacemaker-1.0-crm-cli/omegat/project_save.tmx Wed Jan 25 08:31:22 2012 +0900
@@ -0,0 +1,30 @@
1+<?xml version="1.0" encoding="UTF-8"?>
2+<!DOCTYPE tmx SYSTEM "tmx11.dtd">
3+<tmx version="1.1">
4+ <header
5+ creationtool="OmegaT"
6+ creationtoolversion="2.3.0_5"
7+ segtype="sentence"
8+ o-tmf="OmegaT TMX"
9+ adminlang="EN-US"
10+ srclang="EN-US"
11+ datatype="plaintext"
12+ >
13+ </header>
14+ <body>
15+ <tu>
16+ <tuv lang="EN-US">
17+ <seg>CRM CLI (command line interface) tool
18+======================================
19+Dejan_Muhamedagic,_Yan_Gao dejan@suse.de,ygao@novell.com
20+v0.94, Februar 18, 2010:</seg>
21+ </tuv>
22+ <tuv lang="JA" changedate="20120124T090356Z" changeid="ikedaj">
23+ <seg>CRM CLI (command line interface) tool
24+======================================
25+Dejan_Muhamedagic,_Yan_Gao dejan@suse.de,ygao@novell.com
26+v0.94, Februar 18, 2010:</seg>
27+ </tuv>
28+ </tu>
29+ </body>
30+</tmx>
diff -r 000000000000 -r 9186c700c604 pacemaker-1.0-crm-cli/omegat/project_save.tmx.201201241810.bak
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/pacemaker-1.0-crm-cli/omegat/project_save.tmx.201201241810.bak Wed Jan 25 08:31:22 2012 +0900
@@ -0,0 +1,30 @@
1+<?xml version="1.0" encoding="UTF-8"?>
2+<!DOCTYPE tmx SYSTEM "tmx11.dtd">
3+<tmx version="1.1">
4+ <header
5+ creationtool="OmegaT"
6+ creationtoolversion="2.3.0_5"
7+ segtype="sentence"
8+ o-tmf="OmegaT TMX"
9+ adminlang="EN-US"
10+ srclang="EN-US"
11+ datatype="plaintext"
12+ >
13+ </header>
14+ <body>
15+ <tu>
16+ <tuv lang="EN-US">
17+ <seg>CRM CLI (command line interface) tool
18+======================================
19+Dejan_Muhamedagic,_Yan_Gao dejan@suse.de,ygao@novell.com
20+v0.94, Februar 18, 2010:</seg>
21+ </tuv>
22+ <tuv lang="JA" changedate="20120124T090356Z" changeid="ikedaj">
23+ <seg>CRM CLI (command line interface) tool
24+======================================
25+Dejan_Muhamedagic,_Yan_Gao dejan@suse.de,ygao@novell.com
26+v0.94, Februar 18, 2010:</seg>
27+ </tuv>
28+ </tu>
29+ </body>
30+</tmx>
diff -r 000000000000 -r 9186c700c604 pacemaker-1.0-crm-cli/omegat/project_stats.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/pacemaker-1.0-crm-cli/omegat/project_stats.txt Wed Jan 25 08:31:22 2012 +0900
@@ -0,0 +1,14 @@
1+12/01/24 18:10
2+プロジェクトの翻訳状況
3+
4+ 分節数 単語数 文字数(空白を除く) 文字数(空白を含む)
5+合計: 1025 7768 49257 55630
6+未翻訳: 1024 7752 49108 55472
7+繰り返しを除いた: 855 7378 44884 51051
8+繰り返しを除いた未翻訳: 854 7362 44735 50893
9+
10+
11+ファイルごとの翻訳状況:
12+
13+ファイル名 すべての分節数 未翻訳分節数 繰り返しを除いた分節数 繰り返しを除いた未翻訳分節数 すべての単語数 未翻訳単語数 繰り返しを除いた単語数 繰り返しを除いた未翻訳単語数 すべての文字数(空白を除く) 未翻訳文字数(空白を除く) 繰り返しを除いた文字数(空白を除く) 繰り返しを除いた未翻訳文字数(空白を除く) すべての文字数(空白を含む) 未翻訳文字数(空白を含む) 繰り返しを除いた文字数(空白を含む) 繰り返しを除いた未翻訳文字数(空白を含む)
14+crm_cli.txt 1025 1024 855 854 7768 7752 7378 7362 49257 49108 44884 44735 55630 55472 51051 50893
diff -r 000000000000 -r 9186c700c604 pacemaker-1.0-crm-cli/source/crm_cli.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/pacemaker-1.0-crm-cli/source/crm_cli.txt Wed Jan 25 08:31:22 2012 +0900
@@ -0,0 +1,2011 @@
1+CRM CLI (command line interface) tool
2+======================================
3+Dejan_Muhamedagic,_Yan_Gao dejan@suse.de,ygao@novell.com
4+v0.94, Februar 18, 2010:
5+
6+The CRM (a.k.a Pacemaker) is a Cluster Resource Manager which
7+implements the cluster configuration provided by the user in CIB
8+(Cluster Information Base). The CIB is a set of instructions
9+coded in XML. Editing the CIB is a challenge, not only due to its
10+complexity and a wide variety of options, but also because XML is
11+more computer than user friendly.
12+
13+.Note
14+**************************
15+I do understand that there are people capable of
16+dealing with XML without an intermediary.
17+**************************
18+
19+There are currently three options to manage the CIB, listed here
20+in a decreasing order of user-friendliness:
21+
22+- the GUI (`hb_gui`)
23+- a set of command line tools
24+- `cibadmin(8)`
25+
26+The GUI is very popular and it has recently seen a lot of good
27+development. For some it is going to be (or remain) the first
28+choice in cluster management.
29+
30+The command line tools, lead by `crm_resource(8)`, are capable of
31+performing almost any kind of CIB transformation. The usage is,
32+however, plagued by the notorious weakness common to all UNIX
33+tools: a multitude of options, necessary for operation and yet
34+very hard to remember. Usage is also inconsistent at times.
35+
36+The `cibadmin` is the ultimate CIB management tool: it applies
37+chunks of XML written by the user or generated by another tool to
38+the CIB. Very difficult to use without extensive training. Or
39+should I say drill. May be unnerving as well, in particular due
40+to sometimes cryptic error messages.
41+
42+== Design goals
43+
44+The CLI provides a consistent and unified interface to
45+CIB/cluster management. It uses the command line tools where
46+possible and may resort to XML and `cibadmin` when there is no
47+other option. That is the easiest way to ensure compatibility
48+between different management tools.
49+
50+It may be used either as an interactive shell or for single
51+commands directly on the shell's command line. It is also
52+possible to feed it a set of commands from standard input or a
53+file, thus turning it into a scripting tool. Templates with ready
54+made configurations may help people to learn about the cluster
55+configuration or facilitate testing procedures.
56+
57+The CLI may also be used for the CIB description and generation.
58+A file containing a set of CLI instructions may be applied to the
59+CLI tool to generate a complete CIB.
60+
61+The new shadow CIB feature may also be put to use. The user may
62+work on one of the shadow CIBs and then apply (or commit) it in a
63+single step to the cluster.
64+
65+It should also allow deployment of raw XML which may come either
66+from files or network.
67+
68+Several modes of operation are available to restrict the set of
69+features depending on the user's proficiency.
70+
71+The CLI is line oriented: every command must start and finish
72+on the same line. It is possible to use a continuation character
73+(`\`) to write one command in two or more lines.
74+
75+The CLI has to be run on one of the cluster nodes.
76+
77+.Note
78+**************************
79+Even though all sensible configurations (and most of those that
80+are not) are going to be supported by the CLI, I suspect that it
81+may still happen that certain XML constructs may confuse the
82+tool. When that happens, please file a bug report.
83+
84+The CLI will not try to update the objects it does not
85+understand. Of course, it is always possible to edit such objects
86+in the XML format.
87+**************************
88+
89+== Introduction to the user interface
90+
91+Arguably the most important aspect of such a program is the user
92+interface. We begin with an informal introduction so that the
93+reader may get acquainted with it and get a general feeling of
94+the tool. It is probably best just to give some examples:
95+
96+1. Command line (one-shot) use:
97+
98+ # crm resource stop www_app
99+
100+2. Interactive use:
101+
102+ # crm
103+ crm(live)# resource
104+ crm(live) resource# unmanage tetris_1
105+ crm(live) resource# up
106+ crm(live)# node standby node4
107+
108+3. Cluster configuration:
109+
110+ # crm<<EOF
111+ configure
112+ erase
113+ #
114+ # resources
115+ #
116+ primitive disk0 iscsi \
117+ params portal=192.168.2.108:3260 target=iqn.2008-07.com.suse:disk0
118+ primitive fs0 Filesystem \
119+ params device=/dev/disk/by-label/disk0 directory=/disk0 fstype=ext3
120+ primitive internal_ip IPaddr params ip=192.168.1.101
121+ primitive apache apache \
122+ params configfile=/disk0/etc/apache2/site0.conf
123+ primitive apcfence stonith:apcsmart \
124+ params ttydev=/dev/ttyS0 hostlist="node1 node2" \
125+ op start timeout=60s
126+ primitive pingd pingd \
127+ params name=pingd dampen=5s multiplier=100 host_list="r1 r2"
128+ #
129+ # monitor apache and the UPS
130+ #
131+ monitor apache 60s:30s
132+ monitor apcfence 120m:60s
133+ #
134+ # cluster layout
135+ #
136+ group internal_www \
137+ disk0 fs0 internal_ip apache
138+ clone fence apcfence \
139+ meta globally-unique=false clone-max=2 clone-node-max=1
140+ clone conn pingd \
141+ meta globally-unique=false clone-max=2 clone-node-max=1
142+ location node_pref internal_www \
143+ rule 50: #uname eq node1 \
144+ rule pingd: defined pingd
145+ #
146+ # cluster properties
147+ #
148+ property stonith-enabled=true
149+ commit
150+ EOF
151+
152+If you've ever done a CRM style configuration, you should be able
153+to understand the above examples without much difficulties. The
154+CLI should provide a means to manage the cluster efficiently or
155+put together a configuration in a concise manner.
156+
157+The `(live)` string in the prompt signifies that the current CIB
158+in use is the cluster live configuration. It is also possible to
159+work with the so-called shadow CIBs, i.e. configurations which
160+are stored in files and aren't active, but may be applied at any
161+time to the cluster.
162+
163+Since the CIB is hierarchical such is the interface too. There
164+are several levels and entering each of them enables the user to
165+use a certain set of commands.
166+
167+=== Shadow CIB usage
168+
169+Shadow CIB is a new feature. Shadow CIBs may be manipulated in
170+the same way like the _live_ CIB, but these changes have no
171+effect on the cluster resources. The administrator may choose to
172+apply any of them to the cluster, thus replacing the running
173+configuration with the one which is in the shadow. The `crm`
174+prompt always contains the name of the configuration which is
175+currently in use. Note that, for obvious reasons, only commands
176+at the `configure` level make sense while working with a shadow
177+CIB.
178+
179+No changes take place before the `configure commit` command.
180+Sometimes though, the administrator may start working with the
181+running configuration, but change mind and instead of committing
182+the changes to the cluster save them to a shadow CIB. This
183+short `configure` session excerpt shows how:
184+...............
185+ crm(live)configure# cib new test-2
186+ INFO: test-2 shadow CIB created
187+ crm(test-2)configure# commit
188+...............
189+
190+=== Templates
191+
192+Templates are ready made configurations created by cluster
193+experts. They are designed in such a way, so that users may
194+generate valid cluster configurations with minimum effort.
195+If you are new to Pacemaker/CRM, templates may be the best way to
196+start.
197+
198+We will show here how to create a simple yet functional Apache
199+configuration:
200+...............
201+ # crm configure
202+ crm(live)configure# template
203+ crm(live)configure template# list templates
204+ apache filesystem virtual-ip
205+ crm(live)configure template# new web <TAB><TAB>
206+ apache filesystem virtual-ip
207+ crm(live)configure template# new web apache
208+ INFO: pulling in template apache
209+ INFO: pulling in template virtual-ip
210+ crm(live)configure template# list
211+ web2-d web2 vip2 web3 vip web
212+...............
213+
214+We enter the `template` level from `configure`. Use the `list`
215+command to show templates available on the system.
216+The `new` command creates a configuration from the `apache`
217+template. You can use tab completion to pick templates. Note that
218+the apache template depends on a virtual IP address which is
219+automatically pulled along. The `list` command shows the just
220+created `web` configuration, among other configurations (I hope
221+that you, unlike me, will use more sensible and descriptive names).
222+
223+The `show` command, which displays the resulting configuration,
224+may be used to get an idea about the minimum required changes
225+which have to be done. All `ERROR` messages show the line numbers
226+in which the respective parameters are to be defined:
227+...............
228+ crm(live)configure template# show
229+ ERROR: 23: required parameter ip not set
230+ ERROR: 61: required parameter id not set
231+ ERROR: 65: required parameter configfile not set
232+ crm(live)configure template# edit
233+...............
234+
235+The `edit` command invokes the preferred text editor with the
236+`web` configuration. At the top of the file, the user is advised
237+how to make changes. A good template should require from the user
238+to specify only parameters. For example, the `web` configuration
239+we created above has the following required and optional
240+parameters (all parameter lines start with `%%`):
241+...............
242+ $ grep -n ^%% ~/.crmconf/web
243+ 23:%% ip
244+ 31:%% netmask
245+ 35:%% lvs_support
246+ 61:%% id
247+ 65:%% configfile
248+ 71:%% options
249+ 76:%% envfiles
250+...............
251+
252+These lines are the only ones that should be modified. Simply
253+append the parameter value at the end of the line. For instance,
254+after editing this template, the result could look like this (we
255+used tabs instead of spaces to make the values stand out):
256+...............
257+ $ grep -n ^%% ~/.crmconf/web
258+ 23:%% ip 192.168.1.101
259+ 31:%% netmask
260+ 35:%% lvs_support
261+ 61:%% id websvc
262+ 65:%% configfile /etc/apache2/httpd.conf
263+ 71:%% options
264+ 76:%% envfiles
265+...............
266+
267+As you can see, the parameter line format is very simple:
268+...............
269+ %% <name> <value>
270+...............
271+
272+After editing the file, use `show` again to display the
273+configuration:
274+...............
275+ crm(live)configure template# show
276+ primitive virtual-ip ocf:heartbeat:IPaddr \
277+ params ip="192.168.1.101"
278+ primitive apache ocf:heartbeat:apache \
279+ params configfile="/etc/apache2/httpd.conf"
280+ monitor apache 120s:60s
281+ group websvc \
282+ apache virtual-ip
283+...............
284+
285+The target resource of the apache template is a group which we
286+named `websvc` in this sample session.
287+
288+This configuration looks exactly as you could type it at the
289+`configure` level. The point of templates is to save you some
290+typing. It is important, however, to understand the configuration
291+produced.
292+
293+Finally, the configuration may be applied to the current
294+crm configuration (note how the configuration changed slightly,
295+though it is still equivalent, after being digested at the
296+`configure` level):
297+...............
298+ crm(live)configure template# apply
299+ crm(live)configure template# cd ..
300+ crm(live)configure# show
301+ node xen-b
302+ node xen-c
303+ primitive apache ocf:heartbeat:apache \
304+ params configfile="/etc/apache2/httpd.conf" \
305+ op monitor interval="120s" timeout="60s"
306+ primitive virtual-ip ocf:heartbeat:IPaddr \
307+ params ip="192.168.1.101"
308+ group websvc apache virtual-ip
309+...............
310+
311+Note that this still does not commit the configuration to the CIB
312+which is used in the shell, either the running one (`live`) or
313+some shadow CIB. For that you still need to execute the `commit`
314+command.
315+
316+We should also define the preferred node to run the service:
317+...............
318+ crm(live)configure# location websvc-pref websvc 100: xen-b
319+...............
320+
321+If you are not happy with some resource names which are provided
322+by default, you can rename them now:
323+...............
324+ crm(live)configure# rename virtual-ip intranet-ip
325+ crm(live)configure# show
326+ node xen-b
327+ node xen-c
328+ primitive apache ocf:heartbeat:apache \
329+ params configfile="/etc/apache2/httpd.conf" \
330+ op monitor interval="120s" timeout="60s"
331+ primitive intranet-ip ocf:heartbeat:IPaddr \
332+ params ip="192.168.1.101"
333+ group websvc apache intranet-ip
334+ location websvc-pref websvc 100: xen-b
335+...............
336+
337+To summarize, working with templates typically consists of the
338+following steps:
339+
340+- `new`: create a new configuration from templates
341+- `edit`: define parameters, at least the required ones
342+- `show`: see if the configuration is valid
343+- `apply`: apply the configuration to the `configure` level
344+
345+=== Tab completion
346+
347+The `crm` makes extensive use of the tab completion of
348+`readline`. The completion is both static (i.e. for `crm`
349+commands) and dynamic. The latter takes into account the current
350+status of the cluster or information from installed resource
351+agents. Sometimes, completion may also be used to get short help
352+on resource parameters. Here a few examples:
353+...............
354+ crm(live)# resource <TAB><TAB>
355+ bye exit manage param show unmanage
356+ cd failcount meta quit start unmigrate
357+ cleanup help migrate refresh status unmove
358+ end list move reprobe stop up
359+ crm(live)# configure
360+ crm(live)configure# primitive fence-1 <TAB><TAB>
361+ heartbeat: lsb: ocf: stonith:
362+ crm(live)configure# primitive fence-1 stonith:ipmilan params <TAB><TAB>
363+ auth= hostname= ipaddr= login= password= port= priv=
364+ crm(live)configure# primitive fence-1 stonith:ipmilan params auth=<TAB><TAB>
365+ auth* (string)
366+ The authorization type of the IPMI session ("none", "straight", "md2", or "md5")
367+ crm(live)configure# primitive fence-1 stonith:ipmilan params auth=
368+...............
369+
370+[[SEMCHK]]
371+=== Configuration semantic checks
372+
373+Resource definitions may be checked against the meta-data
374+provided with the resource agents. These checks are currently
375+carried out:
376+
377+- are required parameters set
378+- existence of defined parameters
379+- timeout values for operations
380+
381+The parameter checks are obvious and need no further explanation.
382+Failures in these checks are treated as configuration errors.
383+
384+The timeouts for operations should be at least as long as those
385+recommended in the meta-data. Too short timeout values are a
386+common mistake in cluster configurations and, even worse, they
387+often slip through if cluster testing was not thorough. Though
388+operation timeouts issues are treated as warnings, make sure that
389+the timeouts are usable in your environment. Note also that the
390+values given are just _advisory minimum_---your resources may
391+require longer timeouts.
392+
393+User may tune the frequency of checks and the treatment of errors
394+by the <<cmdhelp_options_check-frequency,`check-frequency`>> and
395+<<cmdhelp_options_check-mode,`check-mode`>> preferences.
396+
397+Note that if the `check-frequency` is set to `always` and the
398+`check-mode` to `strict`, errors are not tolerated and such
399+configuration cannot be saved.
400+
401+== Reference
402+
403+We define a small and simple language. Most commands consist of
404+just a list of simple tokens. The only complex constructs are
405+found at the `configure` level.
406+
407+The syntax is described in a somewhat informal manner: `<>`
408+denotes a string, `[]` means that the construct is optional, the
409+ellipsis (`...`) signifies that the previous construct may be
410+repeated, `|` means pick one of many, and the rest are literals
411+(strings, `:`, `=`).
412+
413+=== `status`
414+
415+Show cluster status. The status is displayed by `crm_mon`. Supply
416+additional arguments for more information or different format.
417+See `crm_mon(8)` for more details.
418+
419+Usage:
420+...............
421+ status [<option> ...]
422+
423+ option :: bynode | inactive | ops | timing | failcounts
424+...............
425+
426+[[cmdhelp_cib,CIB shadow management]]
427+=== `cib` (shadow CIBs)
428+
429+This level is for management of shadow CIBs. It is available both
430+at the top level and the `configure` level.
431+
432+All the commands are implemented using `cib_shadow(8)` and the
433+`CIB_shadow` environment variable. The user prompt always
434+includes the name of the currently active shadow or the live CIB.
435+
436+[[cmdhelp_cib_new,create a new shadow CIB]]
437+==== `new`
438+
439+Create a new shadow CIB. The live cluster configuration and
440+status is copied to the shadow CIB. Specify `withstatus` if you
441+want to edit the status section of the shadow CIB (see the
442+<<cmdhelp_cibstatus,cibstatus section>>). Add `force` to force overwriting the
443+existing shadow CIB.
444+
445+To start with an empty configuration that is not copied from the live
446+CIB, specify the `empty` keyword. (This also allows a shadow CIB to be
447+created in case no cluster is running.)
448+
449+Usage:
450+...............
451+ new <cib> [withstatus] [force] [empty]
452+...............
453+
454+[[cmdhelp_cib_delete,delete a shadow CIB]]
455+==== `delete`
456+
457+Delete an existing shadow CIB.
458+
459+Usage:
460+...............
461+ delete <cib>
462+...............
463+
464+[[cmdhelp_cib_reset,copy live cib to a shadow CIB]]
465+==== `reset`
466+
467+Copy the current cluster configuration into the shadow CIB.
468+
469+Usage:
470+...............
471+ reset <cib>
472+...............
473+
474+[[cmdhelp_cib_commit,copy a shadow CIB to the cluster]]
475+==== `commit`
476+
477+Apply a shadow CIB to the cluster.
478+
479+Usage:
480+...............
481+ commit <cib>
482+...............
483+
484+[[cmdhelp_cib_use,change working CIB]]
485+==== `use`
486+
487+Choose a CIB source. If you want to edit the status from the
488+shadow CIB specify `withstatus` (see <<cmdhelp_cibstatus,`cibstatus`>>).
489+Leave out the CIB name to switch to the running CIB.
490+
491+Usage:
492+...............
493+ use [<cib>] [withstatus]
494+...............
495+
496+[[cmdhelp_cib_diff,diff between the shadow CIB and the live CIB]]
497+==== `diff`
498+
499+Print differences between the current cluster configuration and
500+the active shadow CIB.
501+
502+Usage:
503+...............
504+ diff
505+...............
506+
507+[[cmdhelp_cib_list,list all shadow CIBs]]
508+==== `list`
509+
510+List existing shadow CIBs.
511+
512+Usage:
513+...............
514+ list
515+...............
516+
517+[[cmdhelp_cib_import,import a CIB or PE input file to a shadow]]
518+==== `import`
519+
520+At times it may be useful to create a shadow file from the
521+existing CIB. The CIB may be specified as file or as a PE input
522+file number. The shell will look up files in the local directory
523+first and then in the PE directory (typically `/var/lib/pengine`).
524+Once the CIB file is found, it is copied to a shadow and this
525+shadow is immediately available for use at both `configure` and
526+`cibstatus` levels.
527+
528+If the shadow name is omitted then the target shadow is named
529+after the input CIB file.
530+
531+Note that there are often more than one PE input file, so you may
532+need to specify the full name.
533+
534+Usage:
535+...............
536+ import {<file>|<number>} [<shadow>]
537+...............
538+Examples:
539+...............
540+ import pe-warn-2222
541+ import 2289 issue2
542+...............
543+
544+[[cmdhelp_cib_cibstatus,CIB status management and editing]]
545+==== `cibstatus`
546+
547+Enter edit and manage the CIB status section level. See the
548+<<cmdhelp_cibstatus,CIB status management section>>.
549+
550+[[cmdhelp_ra,Resource Agents (RA) lists and documentation]]
551+=== `ra`
552+
553+This level contains commands which show various information about
554+the installed resource agents. It is available both at the top
555+level and at the `configure` level.
556+
557+[[cmdhelp_ra_classes,list classes and providers]]
558+==== `classes`
559+
560+Print all resource agents' classes and, where appropriate, a list
561+of available providers.
562+
563+Usage:
564+...............
565+ classes
566+...............
567+
568+[[cmdhelp_ra_list,list RA for a class (and provider)]]
569+==== `list`
570+
571+List available resource agents for the given class. If the class
572+is `ocf`, supply a provider to get agents which are available
573+only from that provider.
574+
575+Usage:
576+...............
577+ list <class> [<provider>]
578+...............
579+Example:
580+...............
581+ list ocf pacemaker
582+...............
583+
584+[[cmdhelp_ra_meta,show meta data for a RA]]
585+==== `meta` (`info`)
586+
587+Show the meta-data of a resource agent type. This is where users
588+can find information on how to use a resource agent.
589+
590+Usage:
591+...............
592+ meta [<class>:[<provider>:]]<type>
593+ meta <type> <class> [<provider>] (obsolete)
594+...............
595+Example:
596+...............
597+ meta apache
598+ meta ocf:pacemaker:Dummy
599+ meta stonith:ipmilan
600+...............
601+
602+[[cmdhelp_ra_providers,show providers for a RA and a class]]
603+==== `providers`
604+
605+List providers for a resource agent type. The class parameter
606+defaults to `ocf`.
607+
608+Usage:
609+...............
610+ providers <type> [<class>]
611+...............
612+Example:
613+...............
614+ providers apache
615+...............
616+
617+[[cmdhelp_resource,Resource management]]
618+=== `resource`
619+
620+At this level resources may be managed.
621+
622+All (or almost all) commands are implemented with the CRM tools
623+such as `crm_resource(8)`.
624+
625+[[cmdhelp_resource_status,show status of resources]]
626+==== `status` (`show`, `list`)
627+
628+Print resource status. If the resource parameter is left out
629+status of all resources is printed.
630+
631+Usage:
632+...............
633+ status [<rsc>]
634+...............
635+
636+[[cmdhelp_resource_start,start a resource]]
637+==== `start`
638+
639+Start a resource by setting the `target-role` attribute. If there
640+are multiple meta attributes sets, the attribute is set in all of
641+them. If the resource is a group or a clone, all `target-role`
642+attributes are removed from the children resources.
643+
644+Usage:
645+...............
646+ start <rsc>
647+...............
648+
649+[[cmdhelp_resource_stop,stop a resource]]
650+==== `stop`
651+
652+Stop a resource using the `target-role` attribute. If there
653+are multiple meta attributes sets, the attribute is set in all of
654+them. If the resource is a group or a clone, all `target-role`
655+attributes are removed from the children resources.
656+
657+Usage:
658+...............
659+ stop <rsc>
660+...............
661+
662+[[cmdhelp_resource_restart,restart a resource]]
663+==== `restart`
664+
665+Restart a resource. This is essentially a shortcut for resource
666+stop followed by a start. The shell is first going to wait for
667+the stop to finish, that is for all resources to really stop, and
668+only then to order the start action. Due to this command
669+entailing a whole set of operations, informational messages are
670+printed to let the user see some progress.
671+
672+Usage:
673+...............
674+ restart <rsc>
675+...............
676+Example:
677+...............
678+ # crm resource restart g_webserver
679+ INFO: ordering g_webserver to stop
680+ waiting for stop to finish .... done
681+ INFO: ordering g_webserver to start
682+ #
683+...............
684+
685+[[cmdhelp_resource_promote,promote a master-slave resource]]
686+==== `promote`
687+
688+Promote a master-slave resource using the `target-role`
689+attribute.
690+
691+Usage:
692+...............
693+ promote <rsc>
694+...............
695+
696+[[cmdhelp_resource_demote,demote a master-slave resource]]
697+==== `demote`
698+
699+Demote a master-slave resource using the `target-role`
700+attribute.
701+
702+Usage:
703+...............
704+ demote <rsc>
705+...............
706+
707+[[cmdhelp_resource_manage,put a resource into managed mode]]
708+==== `manage`
709+
710+Manage a resource using the `is-managed` attribute. If there
711+are multiple meta attributes sets, the attribute is set in all of
712+them. If the resource is a group or a clone, all `is-managed`
713+attributes are removed from the children resources.
714+
715+Usage:
716+...............
717+ manage <rsc>
718+...............
719+
720+[[cmdhelp_resource_unmanage,put a resource into unmanaged mode]]
721+==== `unmanage`
722+
723+Unmanage a resource using the `is-managed` attribute. If there
724+are multiple meta attributes sets, the attribute is set in all of
725+them. If the resource is a group or a clone, all `is-managed`
726+attributes are removed from the children resources.
727+
728+Usage:
729+...............
730+ unmanage <rsc>
731+...............
732+
733+[[cmdhelp_resource_migrate,migrate a resource to another node]]
734+==== `migrate` (`move`)
735+
736+Migrate a resource to a different node. If node is left out, the
737+resource is migrated by creating a constraint which prevents it from
738+running on the current node. Additionally, you may specify a
739+lifetime for the constraint---once it expires, the location
740+constraint will no longer be active.
741+
742+Usage:
743+...............
744+ migrate <rsc> [<node>] [<lifetime>] [force]
745+...............
746+
747+[[cmdhelp_resource_unmigrate,unmigrate a resource to another node]]
748+==== `unmigrate` (`unmove`)
749+
750+Remove the constraint generated by the previous migrate command.
751+
752+Usage:
753+...............
754+ unmigrate <rsc>
755+...............
756+
757+[[cmdhelp_resource_param,manage a parameter of a resource]]
758+==== `param`
759+
760+Show/edit/delete a parameter of a resource.
761+
762+Usage:
763+...............
764+ param <rsc> set <param> <value>
765+ param <rsc> delete <param>
766+ param <rsc> show <param>
767+...............
768+Example:
769+...............
770+ param ip_0 show ip
771+...............
772+
773+[[cmdhelp_resource_meta,manage a meta attribute]]
774+==== `meta`
775+
776+Show/edit/delete a meta attribute of a resource. Currently, all
777+meta attributes of a resource may be managed with other commands
778+such as `resource stop`.
779+
780+Usage:
781+...............
782+ meta <rsc> set <attr> <value>
783+ meta <rsc> delete <attr>
784+ meta <rsc> show <attr>
785+...............
786+Example:
787+...............
788+ meta ip_0 set target-role stopped
789+...............
790+
791+[[cmdhelp_resource_failcount,manage failcounts]]
792+==== `failcount`
793+
794+Show/edit/delete the failcount of a resource.
795+
796+Usage:
797+...............
798+ failcount <rsc> set <node> <value>
799+ failcount <rsc> delete <node>
800+ failcount <rsc> show <node>
801+...............
802+Example:
803+...............
804+ failcount fs_0 delete node2
805+...............
806+
807+[[cmdhelp_resource_cleanup,cleanup resource status]]
808+==== `cleanup`
809+
810+Cleanup resource status. Typically done after the resource has
811+temporarily failed. If a node is omitted, cleanup on all nodes.
812+If there are many nodes, the command may take a while.
813+
814+Usage:
815+...............
816+ cleanup <rsc> [<node>]
817+...............
818+
819+[[cmdhelp_resource_refresh,refresh CIB from the LRM status]]
820+==== `refresh`
821+
822+Refresh CIB from the LRM status.
823+
824+Usage:
825+...............
826+ refresh [<node>]
827+...............
828+
829+[[cmdhelp_resource_reprobe,probe for resources not started by the CRM]]
830+==== `reprobe`
831+
832+Probe for resources not started by the CRM.
833+
834+Usage:
835+...............
836+ reprobe [<node>]
837+...............
838+
839+[[cmdhelp_node,Nodes management]]
840+=== `node`
841+
842+Node management and status commands.
843+
844+[[cmdhelp_node_status,show nodes' status]]
845+==== `status`
846+
847+Show nodes' status. If the node parameter is omitted then all
848+nodes are shown.
849+
850+Usage:
851+...............
852+ status [<node>]
853+...............
854+
855+[[cmdhelp_node_show,show node]]
856+==== `show`
857+
858+Show a node definition. If the node parameter is omitted then all
859+nodes are shown.
860+
861+Usage:
862+...............
863+ show [<node>]
864+...............
865+
866+[[cmdhelp_node_standby,put node into standby]]
867+==== `standby`
868+
869+Set a node to standby status. The node parameter defaults to the
870+node where the command is run. Additionally, you may specify a
871+lifetime for the standby---if set to `reboot`, the node will be
872+back online once it reboots. `forever` will keep the node in
873+standby after reboot.
874+
875+Usage:
876+...............
877+ standby [<node>] [<lifetime>]
878+
879+ lifetime :: reboot | forever
880+...............
881+
882+[[cmdhelp_node_online,set node online]]
883+==== `online`
884+
885+Set a node to online status. The node parameter
886+defaults to the node where the command is run.
887+
888+Usage:
889+...............
890+ online [<node>]
891+...............
892+
893+[[cmdhelp_node_fence,fence node]]
894+==== `fence`
895+
896+Make CRM fence a node. This functionality depends on stonith
897+resources capable of fencing the specified node. No such stonith
898+resources, no fencing will happen.
899+
900+Usage:
901+...............
902+ fence <node>
903+...............
904+
905+[[cmdhelp_node_clearstate,Clear node state]]
906+==== `clearnodestate`
907+
908+Resets and clears the state of the specified node. This node is
909+afterwards assumed clean and offline. This command can be used to
910+manually confirm that a node has been fenced (e.g., powered off).
911+
912+Be careful! This can cause data corruption if you confirm that a node is
913+down that is, in fact, not cleanly down - the cluster will proceed as if
914+the fence had succeeded, possibly starting resources multiple times.
915+
916+Usage:
917+...............
918+ clearstate <node>
919+...............
920+
921+[[cmdhelp_node_delete,delete node]]
922+==== `delete`
923+
924+Delete a node. This command will remove the node from the CIB
925+and, in case the heartbeat stack is running, run hb_delnode too.
926+
927+Usage:
928+...............
929+ delete <node>
930+...............
931+
932+[[cmdhelp_node_attribute,manage attributes]]
933+==== `attribute`
934+
935+Edit node attributes. This kind of attribute should refer to
936+relatively static properties, such as memory size.
937+
938+Usage:
939+...............
940+ attribute <node> set <attr> <value>
941+ attribute <node> delete <attr>
942+ attribute <node> show <attr>
943+...............
944+Example:
945+...............
946+ attribute node_1 set memory_size 4096
947+...............
948+
949+[[cmdhelp_node_status-attr,manage status attributes]]
950+==== `status-attr`
951+
952+Edit node attributes which are in the CIB status section, i.e.
953+attributes which hold properties of a more volatile nature. One
954+typical example is attribute generated by the `pingd` utility.
955+
956+Usage:
957+...............
958+ status-attr <node> set <attr> <value>
959+ status-attr <node> delete <attr>
960+ status-attr <node> show <attr>
961+...............
962+Example:
963+...............
964+ status-attr node_1 show pingd
965+...............
966+
967+[[cmdhelp_options,user preferences]]
968+=== `options`
969+
970+The user may set various options for the CLI program itself.
971+
972+[[cmdhelp_options_skill-level,set skill level]]
973+==== `skill-level`
974+
975+Based on the skill-level setting, the user is allowed to use only
976+a subset of commands. There are three levels: operator,
977+administrator, and expert. The operator level allows only
978+commands at the `resource` and `node` levels, but not editing
979+or deleting resources. The administrator may do that and may also
980+configure the cluster at the `configure` level and manage the
981+shadow CIBs. The expert may do all.
982+
983+Usage:
984+...............
985+ skill-level <level>
986+
987+ level :: operator | administrator | expert
988+...............
989+
990+[[cmdhelp_options_user,set the cluster user]]
991+==== `user`
992+
993+Sufficient privileges are necessary in order to manage a
994+cluster: programs such as `crm_verify` or `crm_resource` and,
995+ultimately, `cibadmin` have to be run either as `root` or as the
996+CRM owner user (typically `hacluster`). You don't have to worry
997+about that if you run `crm` as `root`. A more secure way is to
998+run the program with your usual privileges, set this option to
999+the appropriate user (such as `hacluster`), and setup the
1000+`sudoers` file.
1001+
1002+Usage:
1003+...............
1004+ user system-user
1005+...............
1006+Example:
1007+...............
1008+ user hacluster
1009+...............
1010+
1011+[[cmdhelp_options_editor,set preferred editor program]]
1012+==== `editor`
1013+
1014+The `edit` command invokes an editor. Use this to specify your
1015+preferred editor program. If not set, it will default to either
1016+the value of the `EDITOR` environment variable or to one of the
1017+standard UNIX editors (`vi`,`emacs`,`nano`).
1018+
1019+Usage:
1020+...............
1021+ editor program
1022+...............
1023+Example:
1024+...............
1025+ editor vim
1026+...............
1027+
1028+[[cmdhelp_options_pager,set preferred pager program]]
1029+==== `pager`
1030+
1031+The `view` command displays text through a pager. Use this to
1032+specify your preferred pager program. If not set, it will default
1033+to either the value of the `PAGER` environment variable or to one
1034+of the standard UNIX system pagers (`less`,`more`,`pg`).
1035+
1036+[[cmdhelp_options_sort-elements,sort CIB elements]]
1037+==== `sort-elements`
1038+
1039+`crm` by default sorts CIB elements. If you want them appear in
1040+the order they were created, set this option to `no`.
1041+
1042+Usage:
1043+...............
1044+ sort-elements {yes|no}
1045+...............
1046+Example:
1047+...............
1048+ sort-elements no
1049+...............
1050+
1051+[[cmdhelp_options_wait,synchronous operation]]
1052+==== `wait`
1053+
1054+In normal operation, `crm` runs a command and gets back
1055+immediately to process other commands or get input from the user.
1056+With this option set to `yes` it will wait for the started
1057+transition to finish. In interactive mode dots are printed to
1058+indicate progress.
1059+
1060+Usage:
1061+...............
1062+ wait {yes|no}
1063+...............
1064+Example:
1065+...............
1066+ wait yes
1067+...............
1068+
1069+[[cmdhelp_options_output,set output type]]
1070+==== `output`
1071+
1072+`crm` can adorn configurations in two ways: in color (similar to
1073+for instance the `ls --color` command) and by showing keywords in
1074+upper case. Possible values are `plain`, `color`, and
1075+'uppercase'. It is possible to combine the latter two in order to
1076+get an upper case xmass tree. Just set this option to
1077+`color,uppercase`.
1078+
1079+[[cmdhelp_options_colorscheme,set colors for output]]
1080+==== `colorscheme`
1081+
1082+With `output` set to `color`, a comma separated list of colors
1083+from this option are used to emphasize:
1084+
1085+- keywords
1086+- object ids
1087+- attribute names
1088+- attribute values
1089+- scores
1090+- resource references
1091+
1092+`crm` can show colors only if there is curses support for python
1093+installed (usually provided by the `python-curses` package). The
1094+colors are whatever is available in your terminal. Use `normal`
1095+if you want to keep the default foreground color.
1096+
1097+This user preference defaults to
1098+`yellow,normal,cyan,red,green,magenta` which is good for
1099+terminals with dark background. You may want to change the color
1100+scheme and save it in the preferences file for other color
1101+setups.
1102+
1103+Example:
1104+...............
1105+ colorscheme yellow,normal,blue,red,green,magenta
1106+...............
1107+
1108+[[cmdhelp_options_check-frequency,when to perform semantic check]]
1109+==== `check-frequency`
1110+
1111+Semantic check of the CIB or elements modified or created may be
1112+done on every configuration change (`always`), when verifying
1113+(`on-verify`) or `never`. It is by default set to `always`.
1114+Experts may want to change the setting to `on-verify`.
1115+
1116+The checks require that resource agents are present. If they are
1117+not installed at the configuration time set this preference to
1118+`never`.
1119+
1120+See <<SEMCHK,Configuration semantic checks>> for more details.
1121+
1122+[[cmdhelp_options_check-mode,how to treat semantic errors]]
1123+==== `check-mode`
1124+
1125+Semantic check of the CIB or elements modified or created may be
1126+done in the `strict` mode or in the `relaxed` mode. In the former
1127+certain problems are treated as configuration errors. In the
1128+`relaxed` mode all are treated as warnings. The default is `strict`.
1129+
1130+See <<SEMCHK,Configuration semantic checks>> for more details.
1131+
1132+[[cmdhelp_options_show,show current user preference]]
1133+==== `show`
1134+
1135+Display all current settings.
1136+
1137+[[cmdhelp_options_save,save the user preferences to the rc file]]
1138+==== `save`
1139+
1140+Save current settings to the rc file (`$HOME/.crm.rc`). On
1141+further `crm` runs, the rc file is automatically read and parsed.
1142+
1143+[[cmdhelp_configure,CIB configuration]]
1144+=== `configure`
1145+
1146+This level enables all CIB object definition commands.
1147+
1148+The configuration may be logically divided into four parts:
1149+nodes, resources, constraints, and (cluster) properties and
1150+attributes. Each of these commands support one or more basic CIB
1151+objects.
1152+
1153+Nodes and attributes describing nodes are managed using the
1154+`node` command.
1155+
1156+Commands for resources are:
1157+
1158+- `primitive`
1159+- `monitor`
1160+- `group`
1161+- `clone`
1162+- `ms`/`master` (master-slave)
1163+
1164+There are three types of constraints:
1165+
1166+- `location`
1167+- `colocation`
1168+- `order`
1169+
1170+Finally, there are the cluster properties, resource meta
1171+attributes defaults, and operations defaults. All are just a set
1172+of attributes. These attributes are managed by the following
1173+commands:
1174+
1175+- `property`
1176+- `rsc_defaults`
1177+- `op_defaults`
1178+
1179+The changes applied to the current CIB only on ending the
1180+configuration session or using the `commit` command.
1181+
1182+[[cmdhelp_configure_node,define a cluster node]]
1183+==== `node`
1184+
1185+The node command describes a cluster node. Nodes in the CIB are
1186+commonly created automatically by the CRM. Hence, you should not
1187+need to deal with nodes unless you also want to define node
1188+attributes. Note that it is also possible to manage node
1189+attributes at the `node` level.
1190+
1191+Usage:
1192+...............
1193+ node <uname>[:<type>]
1194+ [attributes <param>=<value> [<param>=<value>...]]
1195+
1196+ type :: normal | member | ping
1197+...............
1198+Example:
1199+...............
1200+ node node1
1201+ node big_node attributes memory=64
1202+...............
1203+
1204+[[cmdhelp_configure_primitive,define a resource]]
1205+==== `primitive`
1206+
1207+The primitive command describes a resource. It may be referenced
1208+only once in group, clone, or master-slave objects. If it's not
1209+referenced, then it is placed as a single resource in the CIB.
1210+
1211+Operations may be specified in three ways. "Anonymous" as a
1212+simple list of "op" specifications. Use that if you don't want to
1213+reference the set of operations elsewhere. That's by far the most
1214+common way to define operations. If reusing operation sets is
1215+desired, use the "operations" keyword along with the id to give
1216+the operations set a name and the id-ref to reference another set
1217+of operations.
1218+
1219+Operation's attributes which are not recognized are saved as
1220+instance attributes of that operation. A typical example is
1221+`OCF_CHECK_LEVEL`.
1222+
1223+Usage:
1224+...............
1225+ primitive <rsc> [<class>:[<provider>:]]<type>
1226+ [params attr_list]
1227+ [meta attr_list]
1228+ [operations id_spec]
1229+ [op op_type [<attribute>=<value>...] ...]
1230+
1231+ attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
1232+ id_spec :: $id=<id> | $id-ref=<id>
1233+ op_type :: start | stop | monitor
1234+...............
1235+Example:
1236+...............
1237+ primitive apcfence stonith:apcsmart \
1238+ params ttydev=/dev/ttyS0 hostlist="node1 node2" \
1239+ op start timeout=60s \
1240+ op monitor interval=30m timeout=60s
1241+
1242+ primitive www8 apache \
1243+ params configfile=/etc/apache/www8.conf \
1244+ operations $id-ref=apache_ops
1245+
1246+ primitive db0 mysql \
1247+ params config=/etc/mysql/db0.conf \
1248+ op monitor interval=60s \
1249+ op monitor interval=300s OCF_CHECK_LEVEL=10
1250+...............
1251+
1252+[[cmdhelp_configure_monitor,add monitor operation to a primitive]]
1253+==== `monitor`
1254+
1255+Monitor is by far the most common operation. It is possible to
1256+add it without editing the whole resource. Also, long primitive
1257+definitions may be a bit uncluttered. In order to make this
1258+command as concise as possible, less common operation attributes
1259+are not available. If you need them, then use the `op` part of
1260+the `primitive` command.
1261+
1262+Usage:
1263+...............
1264+ monitor <rsc>[:<role>] <interval>[:<timeout>]
1265+...............
1266+Example:
1267+...............
1268+ monitor apcfence 60m:60s
1269+...............
1270+
1271+Note that after executing the command, the monitor operation may
1272+be shown as part of the primitive definition.
1273+
1274+[[cmdhelp_configure_group,define a group]]
1275+==== `group`
1276+
1277+The `group` command creates a group of resources.
1278+
1279+Usage:
1280+...............
1281+ group <name> <rsc> [<rsc>...]
1282+ [meta attr_list]
1283+ [params attr_list]
1284+
1285+ attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
1286+...............
1287+Example:
1288+...............
1289+ group internal_www disk0 fs0 internal_ip apache \
1290+ meta target_role=stopped
1291+...............
1292+
1293+[[cmdhelp_configure_clone,define a clone]]
1294+==== `clone`
1295+
1296+The `clone` command creates a resource clone. It may contain a
1297+single primitive resource or one group of resources.
1298+
1299+Usage:
1300+...............
1301+ clone <name> <rsc>
1302+ [meta attr_list]
1303+ [params attr_list]
1304+
1305+ attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
1306+...............
1307+Example:
1308+...............
1309+ clone cl_fence apc_1 \
1310+ meta clone-node-max=1 globally-unique=false
1311+...............
1312+
1313+[[cmdhelp_configure_ms,define a master-slave resource]]
1314+==== `ms` (`master`)
1315+
1316+The `ms` command creates a master/slave resource type. It may contain a
1317+single primitive resource or one group of resources.
1318+
1319+Usage:
1320+...............
1321+ ms <name> <rsc>
1322+ [meta attr_list]
1323+ [params attr_list]
1324+
1325+ attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
1326+...............
1327+Example:
1328+...............
1329+ ms disk1 drbd1 \
1330+ meta notify=true globally-unique=false
1331+...............
1332+
1333+.Note on `id-ref` usage
1334+****************************
1335+Instance or meta attributes (`params` and `meta`) may contain
1336+a reference to another set of attributes. In that case, no other
1337+attributes are allowed. Since attribute sets' ids, though they do
1338+exist, are not shown in the `crm`, it is also possible to
1339+reference an object instead of an attribute set. `crm` will
1340+automatically replace such a reference with the right id:
1341+
1342+...............
1343+ crm(live)configure# primitive a2 www-2 meta $id-ref=a1
1344+ crm(live)configure# show a2
1345+ primitive a2 ocf:heartbeat:apache \
1346+ meta $id-ref="a1-meta_attributes"
1347+ [...]
1348+...............
1349+It is advisable to give meaningful names to attribute sets which
1350+are going to be referenced.
1351+****************************
1352+
1353+[[cmdhelp_configure_location,a location preference]]
1354+==== `location`
1355+
1356+`location` defines the preference of nodes for the given
1357+resource. The location constraints consist of one or more rules
1358+which specify a score to be awarded if the rule matches.
1359+
1360+Usage:
1361+...............
1362+ location <id> <rsc> {node_pref|rules}
1363+
1364+ node_pref :: <score>: <node>
1365+
1366+ rules ::
1367+ rule [id_spec] [$role=<role>] <score>: <expression>
1368+ [rule [id_spec] [$role=<role>] <score>: <expression> ...]
1369+
1370+ id_spec :: $id=<id> | $id-ref=<id>
1371+ score :: <number> | <attribute> | [-]inf
1372+ expression :: <simple_exp> [bool_op <simple_exp> ...]
1373+ bool_op :: or | and
1374+ simple_exp :: <attribute> [type:]<binary_op> <value>
1375+ | <unary_op> <attribute>
1376+ | date <date_expr>
1377+ type :: string | version | number
1378+ binary_op :: lt | gt | lte | gte | eq | ne
1379+ unary_op :: defined | not_defined
1380+
1381+ date_expr :: lt <end>
1382+ | gt <start>
1383+ | in_range start=<start> end=<end>
1384+ | in_range start=<start> <duration>
1385+ | date_spec <date_spec>
1386+ duration|date_spec ::
1387+ hours=<value>
1388+ | monthdays=<value>
1389+ | weekdays=<value>
1390+ | yearsdays=<value>
1391+ | months=<value>
1392+ | weeks=<value>
1393+ | years=<value>
1394+ | weekyears=<value>
1395+ | moon=<value>
1396+...............
1397+Examples:
1398+...............
1399+ location conn_1 internal_www 100: node1
1400+
1401+ location conn_1 internal_www \
1402+ rule 50: #uname eq node1 \
1403+ rule pingd: defined pingd
1404+
1405+ location conn_2 dummy_float \
1406+ rule -inf: not_defined pingd or pingd number:lte 0
1407+...............
1408+
1409+[[cmdhelp_configure_colocation,colocate resources]]
1410+==== `colocation` (`collocation`)
1411+
1412+This constraint expresses the placement relation between two
1413+or more resources. If there are more than two resources, then the
1414+constraint is called a resource set. Collocation resource sets have
1415+an extra attribute to allow for sets of resources which don't depend
1416+on each other in terms of state. The shell syntax for such sets is
1417+to put resources in parentheses.
1418+
1419+Usage:
1420+...............
1421+ colocation <id> <score>: <rsc>[:<role>] <rsc>[:<role>] ...
1422+...............
1423+Example:
1424+...............
1425+ colocation dummy_and_apache -inf: apache dummy
1426+ colocation c1 inf: A ( B C )
1427+...............
1428+
1429+[[cmdhelp_configure_order,order resources]]
1430+==== `order`
1431+
1432+This constraint expresses the order of actions on two resources
1433+or more resources. If there are more than two resources, then the
1434+constraint is called a resource set. Ordered resource sets have an
1435+extra attribute to allow for sets of resources whose actions may run
1436+in parallel. The shell syntax for such sets is to put resources in
1437+parentheses.
1438+
1439+Usage:
1440+...............
1441+ order <id> score-type: <rsc>[:<action>] <rsc>[:<action>] ...
1442+ [symmetrical=<bool>]
1443+
1444+ score-type :: advisory | mandatory | <score>
1445+...............
1446+Example:
1447+...............
1448+ order c_apache_1 mandatory: apache:start ip_1
1449+ order o1 inf: A ( B C )
1450+...............
1451+
1452+[[cmdhelp_configure_property,set a cluster property]]
1453+==== `property`
1454+
1455+Set the cluster (`crm_config`) options.
1456+
1457+Usage:
1458+...............
1459+ property [$id=<set_id>] <option>=<value> [<option>=<value> ...]
1460+...............
1461+Example:
1462+...............
1463+ property stonith-enabled=true
1464+...............
1465+
1466+[[cmdhelp_configure_rsc_defaults,set resource defaults]]
1467+==== `rsc_defaults`
1468+
1469+Set defaults for the resource meta attributes.
1470+
1471+Usage:
1472+...............
1473+ rsc_defaults [$id=<set_id>] <option>=<value> [<option>=<value> ...]
1474+...............
1475+Example:
1476+...............
1477+ rsc_defaults failure-timeout=3m
1478+...............
1479+
1480+[[cmdhelp_configure_op_defaults,set resource operations defaults]]
1481+==== `op_defaults`
1482+
1483+Set defaults for the operations meta attributes.
1484+
1485+Usage:
1486+...............
1487+ op_defaults [$id=<set_id>] <option>=<value> [<option>=<value> ...]
1488+...............
1489+Example:
1490+...............
1491+ op_defaults record-pending=true
1492+...............
1493+
1494+[[cmdhelp_configure_show,display CIB objects]]
1495+==== `show`
1496+
1497+The `show` command displays objects. It may display all objects
1498+or a set of objects. The user may also choose to see only objects
1499+which were changed.
1500+Optionally, the XML code may be displayed instead of the CLI
1501+representation.
1502+
1503+Usage:
1504+...............
1505+ show [xml] [<id> ...]
1506+ show [xml] changed
1507+...............
1508+
1509+[[cmdhelp_configure_edit,edit CIB objects]]
1510+==== `edit`
1511+
1512+This command invokes the editor with the object description. As
1513+with the `show` command, the user may choose to edit all objects
1514+or a set of objects.
1515+
1516+If the user insists, he or she may edit the XML edition of the
1517+object. If you do that, don't modify any id attributes.
1518+
1519+Usage:
1520+...............
1521+ edit [xml] [<id> ...]
1522+ edit [xml] changed
1523+...............
1524+
1525+[[cmdhelp_configure_delete,delete CIB objects]]
1526+==== `delete`
1527+
1528+Delete one or more objects. If an object to be deleted belongs to
1529+a container object, such as a group, and it is the only resource
1530+in that container, then the container is deleted as well. Any
1531+related constraints are removed as well.
1532+
1533+Usage:
1534+...............
1535+ delete <id> [<id>...]
1536+...............
1537+
1538+[[cmdhelp_configure_rename,rename a CIB object]]
1539+==== `rename`
1540+
1541+Rename an object. It is recommended to use this command to rename
1542+a resource, because it will take care of updating all related
1543+constraints and a parent resource. Changing ids with the edit
1544+command won't have the same effect.
1545+
1546+If you want to rename a resource, it must be in the stopped state.
1547+
1548+Usage:
1549+...............
1550+ rename <old_id> <new_id>
1551+...............
1552+
1553+[[cmdhelp_configure_refresh,refresh from CIB]]
1554+==== `refresh`
1555+
1556+Refresh the internal structures from the CIB. All changes made
1557+during this session are lost.
1558+
1559+Usage:
1560+...............
1561+ refresh
1562+...............
1563+
1564+[[cmdhelp_configure_erase,erase the CIB]]
1565+==== `erase`
1566+
1567+The `erase` clears all configuration. Apart from nodes. To remove
1568+nodes, you have to specify an additional keyword `nodes`.
1569+
1570+Note that removing nodes from the live cluster may have some
1571+strange/interesting/unwelcome effects.
1572+
1573+Usage:
1574+...............
1575+ erase [nodes]
1576+...............
1577+
1578+[[cmdhelp_configure_ptest,show cluster actions if changes were committed]]
1579+==== `ptest`
1580+
1581+Show PE (Policy Engine) motions using `ptest(8)`.
1582+
1583+A CIB is constructed using the current user edited configuration
1584+and the status from the running CIB. The resulting CIB is run
1585+through `ptest` to show changes which would happen if the
1586+configuration is committed.
1587+
1588+The status section may be loaded from another source and modified
1589+using the <<cmdhelp_cibstatus,`cibstatus`>> level commands. In that case, the
1590+`ptest` command will issue a message informing the user that the
1591+Policy Engine graph is not calculated based on the current status
1592+section and therefore won't show what would happen to the
1593+running but some imaginary cluster.
1594+
1595+If you have graphviz installed and X11 session, `dotty(1)` is run
1596+to display the changes graphically.
1597+
1598+Add a string of `v` characters to increase verbosity. `ptest`
1599+can also show allocation scores.
1600+
1601+Usage:
1602+...............
1603+ ptest [nograph] [v...] [scores]
1604+...............
1605+Examples:
1606+...............
1607+ ptest scores
1608+ ptest vvvvv
1609+...............
1610+
1611+[[cmdhelp_configure_cibstatus,CIB status management and editing]]
1612+==== `cibstatus`
1613+
1614+Enter edit and manage the CIB status section level. See the
1615+<<cmdhelp_cibstatus,CIB status management section>>.
1616+
1617+[[cmdhelp_configure_template,edit and import a configuration from a template]]
1618+==== `template`
1619+
1620+The specified template is loaded into the editor. It's up to the
1621+user to make a good CRM configuration out of it. See also the
1622+<<cmdhelp_template,template section>>.
1623+
1624+Usage:
1625+...............
1626+ template [xml] url
1627+...............
1628+Example:
1629+...............
1630+ template two-apaches.txt
1631+...............
1632+
1633+[[cmdhelp_configure_commit,commit the changes to the CIB]]
1634+==== `commit`
1635+
1636+Commit the current configuration to the CIB in use. As noted
1637+elsewhere, commands in a configure session don't have immediate
1638+effect on the CIB. All changes are applied at one point in time,
1639+either using `commit` or when the user leaves the configure
1640+level. In case the CIB in use changed in the meantime, presumably
1641+by somebody else, the CLI will refuse to apply the changes. If
1642+you know that it's fine to still apply them add `force`.
1643+
1644+Usage:
1645+...............
1646+ commit [force]
1647+...............
1648+
1649+[[cmdhelp_configure_verify,verify the CIB with crm_verify]]
1650+==== `verify`
1651+
1652+Verify the contents of the CIB which would be committed.
1653+
1654+Usage:
1655+...............
1656+ verify
1657+...............
1658+
1659+[[cmdhelp_configure_upgrade,upgrade the CIB to version 1.0]]
1660+==== `upgrade`
1661+
1662+If you get the `CIB not supported` error, which typically means
1663+that the current CIB version is coming from the older release,
1664+you may try to upgrade it to the latest revision. The command
1665+to perform the upgrade is:
1666+...............
1667+ # cibadmin --upgrade --force
1668+...............
1669+
1670+If we don't recognize the current CIB as the old one, but you're
1671+sure that it is, you may force the command.
1672+
1673+Usage:
1674+...............
1675+ upgrade [force]
1676+...............
1677+
1678+[[cmdhelp_configure_save,save the CIB to a file]]
1679+==== `save`
1680+
1681+Save the configuration of the current level to a file.
1682+Optionally, as XML.
1683+
1684+Usage:
1685+...............
1686+ save [xml] <file>
1687+...............
1688+Example:
1689+...............
1690+ save myfirstcib.txt
1691+...............
1692+
1693+[[cmdhelp_configure_load,import the CIB from a file]]
1694+==== `load`
1695+
1696+Load a part of configuration (or all of it) from a local file or
1697+a network URL. The `replace` method replaces the current
1698+configuration with the one from the source. The `update` tries to
1699+import the contents into the current configuration.
1700+The file may be a CLI file or an XML file.
1701+
1702+Usage:
1703+...............
1704+ load [xml] <method> URL
1705+
1706+ method :: replace | update
1707+...............
1708+Example:
1709+...............
1710+ load xml update myfirstcib.xml
1711+ load xml replace http://storage.big.com/cibs/bigcib.xml
1712+...............
1713+
1714+[[cmdhelp_configure_xml,raw xml]]
1715+==== `xml`
1716+
1717+Even though we promissed no xml, it may happen, but hopefully
1718+very very seldom, that an element from the CIB cannot be rendered
1719+in the configuration language. In that case, the element will be
1720+shown as raw xml, prefixed by this command. That element can then
1721+be edited like any other. If the shell finds out that after the
1722+change it can digest it, then it is going to be converted into
1723+the normal configuration language. Otherwise, there is no need to
1724+use `xml` for configuration.
1725+
1726+Usage:
1727+...............
1728+ xml <xml>
1729+...............
1730+
1731+[[cmdhelp_template,edit and import a configuration from a template]]
1732+=== `template`
1733+
1734+User may be assisted in the cluster configuration by templates
1735+prepared in advance. Templates consist of a typical ready
1736+configuration which may be edited to suit particular user needs.
1737+
1738+This command enters a template level where additional commands
1739+for configuration/template management are available.
1740+
1741+[[cmdhelp_template_new,create a new configuration from templates]]
1742+==== `new`
1743+
1744+Create a new configuration from one or more templates. Note that
1745+configurations and templates are kept in different places, so it
1746+is possible to have a configuration name equal a template name.
1747+
1748+If you already know which parameters are required, you can set
1749+them directly on the command line.
1750+
1751+The parameter name `id` is set by default to the name of the
1752+configuration.
1753+
1754+Usage:
1755+...............
1756+ new <config> <template> [<template> ...] [params name=value ...]"
1757+...............
1758+Examples:
1759+...............
1760+ new vip virtual-ip
1761+ new bigfs ocfs2 params device=/dev/sdx8 directory=/bigfs
1762+...............
1763+
1764+[[cmdhelp_template_load,load a configuration]]
1765+==== `load`
1766+
1767+Load an existing configuration. Further `edit`, `show`, and
1768+`apply` commands will refer to this configuration.
1769+
1770+Usage:
1771+...............
1772+ load <config>
1773+...............
1774+
1775+[[cmdhelp_template_edit,edit a configuration]]
1776+==== `edit`
1777+
1778+Edit current or given configuration using your favourite editor.
1779+
1780+Usage:
1781+...............
1782+ edit [<config>]
1783+...............
1784+
1785+[[cmdhelp_template_delete,delete a configuration]]
1786+==== `delete`
1787+
1788+Remove a configuration. The loaded (active) configuration may be
1789+removed by force.
1790+
1791+Usage:
1792+...............
1793+ delete <config> [force]
1794+...............
1795+
1796+[[cmdhelp_template_list,list configurations/templates]]
1797+==== `list`
1798+
1799+List existing configurations or templates.
1800+
1801+Usage:
1802+...............
1803+ list [templates]
1804+...............
1805+
1806+[[cmdhelp_template_apply,process and apply the current configuration to the current CIB]]
1807+==== `apply`
1808+
1809+Copy the current or given configuration to the current CIB. By
1810+default, the CIB is replaced, unless the method is set to
1811+"update".
1812+
1813+Usage:
1814+...............
1815+ apply [<method>] [<config>]
1816+
1817+ method :: replace | update
1818+...............
1819+
1820+[[cmdhelp_template_show,show the processed configuration]]
1821+==== `show`
1822+
1823+Process the current or given configuration and display the result.
1824+
1825+Usage:
1826+...............
1827+ show [<config>]
1828+...............
1829+
1830+[[cmdhelp_cibstatus,CIB status management and editing]]
1831+=== `cibstatus`
1832+
1833+The `cibstatus` section of the CIB keeps the current status of nodes
1834+and resources. It is modified _only_ on events, i.e. when some
1835+resource operation is run or node status changes. For obvious
1836+reasons, the CRM has no user interface with which it is possible
1837+to affect the status section. From the user's point of view, the
1838+status section is essentially a read-only part of the CIB. The
1839+current status is never even written to disk, though it is
1840+available in the PE (Policy Engine) input files which represent
1841+the history of cluster motions. The current status may be read
1842+using the `cibadmin -Q` command.
1843+
1844+It may sometimes be of interest to see how status changes would
1845+affect the Policy Engine. The set of `cibstatus` level commands
1846+allow the user to load status sections from various sources and
1847+then mimic resource operations or node changes. The effect of
1848+those changes may then be observed by running the
1849+<<cmdhelp_configure_ptest,`ptest`>> command.
1850+
1851+[[cmdhelp_cibstatus_load,load the CIB status section]]
1852+==== `load`
1853+
1854+Load a status section from a file, a shadow CIB, or the running
1855+cluster. By default, the current (`live`) status section is
1856+modified. Note that if the `live` status section is modified it
1857+is not going to be updated if the cluster status changes, because
1858+that would overwrite the user changes. To make `crm` drop changes
1859+and resume use of the running cluster status, run `load live`.
1860+
1861+All CIB shadow configurations contain the status section which is
1862+a snapshot of the status section taken at the time the shadow was
1863+created. Obviously, this status section doesn't have much to do
1864+with the running cluster status, unless the shadow CIB has just
1865+been created. Therefore, the `ptest` command by default uses the
1866+running cluster status section.
1867+
1868+Usage:
1869+...............
1870+ load {<file>|shadow:<cib>|live}
1871+...............
1872+Example:
1873+...............
1874+ load bug-12299.xml
1875+ load shadow:test1
1876+...............
1877+
1878+[[cmdhelp_cibstatus_save,save the CIB status section]]
1879+==== `save`
1880+
1881+The current internal status section with whatever modifications
1882+were performed can be saved to a file or shadow CIB.
1883+
1884+If the file exists and contains a complete CIB, only the status
1885+section is going to be replaced and the rest of the CIB will
1886+remain intact. Otherwise, the current user edited configuration
1887+is saved along with the status section.
1888+
1889+If the argument is omitted, the status is saved to wherever the
1890+status section originated. Unless, of course, the origin is the
1891+running cluster.
1892+
1893+Usage:
1894+...............
1895+ save [<file>|shadow:<cib>]
1896+...............
1897+Example:
1898+...............
1899+ save bug-12299.xml
1900+...............
1901+
1902+[[cmdhelp_cibstatus_origin,display origin of the CIB status section]]
1903+==== `origin`
1904+
1905+Show the origin of the status section currently in use. This
1906+essentially shows the latest `load` argument.
1907+
1908+Usage:
1909+...............
1910+ origin
1911+...............
1912+
1913+[[cmdhelp_cibstatus_show,show CIB status section]]
1914+==== `show`
1915+
1916+Show the current status section in the XML format. Brace yourself
1917+for some unreadable output. Add `changed` option to get a human
1918+readable output of all changes.
1919+
1920+Usage:
1921+...............
1922+ show [changed]
1923+...............
1924+
1925+[[cmdhelp_cibstatus_node,change node status]]
1926+==== `node`
1927+
1928+Change the node status. It is possible to throw a node out of
1929+the cluster, make it a member, or set its state to unclean.
1930+
1931+`online`:: Set the `node_state` `crmd` attribute to `online`
1932+and the `expected` and `join` attributes to `member`. The effect
1933+is that the node becomes a cluster member.
1934+
1935+`offline`:: Set the `node_state` `crmd` attribute to `offline`
1936+and the `expected` attribute to empty. This makes the node
1937+cleanly removed from the cluster.
1938+
1939+`unclean`:: Set the `node_state` `crmd` attribute to `offline`
1940+and the `expected` attribute to `member`. In this case the node
1941+has unexpectedly disappeared.
1942+
1943+Usage:
1944+...............
1945+ node <node> {online|offline|unclean}
1946+...............
1947+Example:
1948+...............
1949+ node xen-b unclean
1950+...............
1951+
1952+[[cmdhelp_cibstatus_op,edit outcome of a resource operation]]
1953+==== `op`
1954+
1955+Edit the outcome of a resource operation. This way you can
1956+tell CRM that it ran an operation and that the resource agent
1957+returned certain exit code. It is also possible to change the
1958+operation's status. In case the operation status is set to
1959+something other than `done`, the exit code is effectively
1960+ignored.
1961+
1962+Usage:
1963+...............
1964+ op <operation> <resource> <exit_code> [<op_status>] [<node>]
1965+
1966+ operation :: probe | monitor[:<n>] | start | stop |
1967+ promote | demote | notify | migrate_to | migrate_from
1968+ exit_code :: <rc> | success | generic | args |
1969+ unimplemented | perm | installed | configured | not_running |
1970+ master | failed_master
1971+ op_status :: pending | done | cancelled | timeout | notsupported | error
1972+
1973+ n :: the monitor interval in seconds; if omitted, the first
1974+ recurring operation is referenced
1975+ rc :: numeric exit code in range 0..9
1976+...............
1977+Example:
1978+...............
1979+ op start d1 xen-b generic
1980+ op start d1 xen-b 1
1981+ op monitor d1 xen-b not_running
1982+ op stop d1 xen-b 0 timeout
1983+...............
1984+
1985+=== `end` (`cd`, `up`)
1986+
1987+The `end` command ends the current level and the user moves to
1988+the parent level. This command is available everywhere.
1989+
1990+Usage:
1991+...............
1992+ end
1993+...............
1994+
1995+=== `help`
1996+
1997+The `help` command prints help for the current level or for the
1998+specified topic (command). This command is available everywhere.
1999+
2000+Usage:
2001+...............
2002+ help [<topic>]
2003+...............
2004+
2005+=== `quit` (`exit`, `bye`)
2006+
2007+Leave the program.
2008+
2009+//////////////////////
2010+ vim:ts=4:sw=4:expandtab:
2011+//////////////////////
Show on old repository browser