forked from sky-big/RabbitMQ
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrabbitmqctl.1.xml
1899 lines (1845 loc) · 86.5 KB
/
rabbitmqctl.1.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.docbook.org/xml/4.5/docbookx.dtd">
<!--
There is some extra magic in this document besides the usual DocBook semantics
to allow us to derive manpages, HTML and usage messages from the same source
document.
Examples need to be moved to the end for man pages. To this end, <para>s and
<screen>s with role="example" will be moved, and with role="example-prefix"
will be removed.
The usage messages are more involved. We have some magic in usage.xsl to pull
out the command synopsis, global option and subcommand synopses. We also pull
out <para>s with role="usage".
Finally we construct lists of possible values for subcommand options, if the
subcommand's <varlistentry> has role="usage-has-option-list". The option which
takes the values should be marked with role="usage-option-list".
-->
<refentry lang="en">
<refentryinfo>
<productname>RabbitMQ Server</productname>
<authorgroup>
<corpauthor>The RabbitMQ Team <<ulink url="mailto:info@rabbitmq.com"><email>info@rabbitmq.com</email></ulink>></corpauthor>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>rabbitmqctl</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">RabbitMQ Service</refmiscinfo>
</refmeta>
<refnamediv>
<refname>rabbitmqctl</refname>
<refpurpose>command line tool for managing a RabbitMQ broker</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>rabbitmqctl</command>
<arg choice="opt">-n <replaceable>node</replaceable></arg>
<arg choice="opt">-q</arg>
<arg choice="req"><replaceable>command</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>command options</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
RabbitMQ is an implementation of AMQP, the emerging standard for high
performance enterprise messaging. The RabbitMQ server is a robust and
scalable implementation of an AMQP broker.
</para>
<para>
<command>rabbitmqctl</command> is a command line tool for managing a
RabbitMQ broker. It performs all actions by connecting to one of the
broker's nodes.
</para>
<para>
Diagnostic information is displayed if the broker was not
running, could not be reached, or rejected the connection due to
mismatching Erlang cookies.
</para>
</refsect1>
<refsect1>
<title>Options</title>
<variablelist>
<varlistentry>
<term><cmdsynopsis><arg choice="opt">-n <replaceable>node</replaceable></arg></cmdsynopsis></term>
<listitem>
<para role="usage">
Default node is "rabbit@server", where server is the local host. On
a host named "server.example.com", the node name of the RabbitMQ
Erlang node will usually be rabbit@server (unless RABBITMQ_NODENAME
has been set to some non-default value at broker startup time). The
output of <command>hostname -s</command> is usually the correct suffix to use after the
"@" sign. See rabbitmq-server(1) for details of configuring the
RabbitMQ broker.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><arg choice="opt">-q</arg></cmdsynopsis></term>
<listitem>
<para role="usage">
Quiet output mode is selected with the "-q" flag. Informational
messages are suppressed when quiet mode is in effect.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Commands</title>
<refsect2>
<title>Application and Cluster Management</title>
<variablelist>
<varlistentry>
<term><cmdsynopsis><command>stop</command> <arg choice="opt"><replaceable>pid_file</replaceable></arg></cmdsynopsis></term>
<listitem>
<para>
Stops the Erlang node on which RabbitMQ is running. To
restart the node follow the instructions for <citetitle>Running
the Server</citetitle> in the <ulink url="http://www.rabbitmq.com/install.html">installation
guide</ulink>.
</para>
<para>
If a <option>pid_file</option> is specified, also waits
for the process specified there to terminate. See the
description of the <option>wait</option> command below
for details on this file.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl stop</screen>
<para role="example">
This command instructs the RabbitMQ node to terminate.
</para>
</listitem>
</varlistentry>
<varlistentry id="stop_app">
<term><cmdsynopsis><command>stop_app</command></cmdsynopsis></term>
<listitem>
<para>
Stops the RabbitMQ application, leaving the Erlang node
running.
</para>
<para>
This command is typically run prior to performing other
management actions that require the RabbitMQ application
to be stopped, e.g. <link
linkend="reset"><command>reset</command></link>.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl stop_app</screen>
<para role="example">
This command instructs the RabbitMQ node to stop the
RabbitMQ application.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>start_app</command></cmdsynopsis></term>
<listitem>
<para>
Starts the RabbitMQ application.
</para>
<para>
This command is typically run after performing other
management actions that required the RabbitMQ application
to be stopped, e.g. <link
linkend="reset"><command>reset</command></link>.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl start_app</screen>
<para role="example">
This command instructs the RabbitMQ node to start the
RabbitMQ application.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>wait</command> <arg choice="req"><replaceable>pid_file</replaceable></arg></cmdsynopsis></term>
<listitem>
<para>
Wait for the RabbitMQ application to start.
</para>
<para>
This command will wait for the RabbitMQ application to
start at the node. It will wait for the pid file to
be created, then for a process with a pid specified in the
pid file to start, and then for the RabbitMQ application
to start in that process. It will fail if the process
terminates without starting the RabbitMQ application.
</para>
<para>
A suitable pid file is created by
the <command>rabbitmq-server</command> script. By
default this is located in the Mnesia directory. Modify
the <command>RABBITMQ_PID_FILE</command> environment
variable to change the location.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl wait /var/run/rabbitmq/pid</screen>
<para role="example">
This command will return when the RabbitMQ node has
started up.
</para>
</listitem>
</varlistentry>
<varlistentry id="reset">
<term><cmdsynopsis><command>reset</command></cmdsynopsis></term>
<listitem>
<para>
Return a RabbitMQ node to its virgin state.
</para>
<para>
Removes the node from any cluster it belongs to, removes
all data from the management database, such as configured
users and vhosts, and deletes all persistent
messages.
</para>
<para>
For <command>reset</command> and <command>force_reset</command> to
succeed the RabbitMQ application must have been stopped,
e.g. with <link linkend="stop_app"><command>stop_app</command></link>.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl reset</screen>
<para role="example">
This command resets the RabbitMQ node.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>force_reset</command></cmdsynopsis></term>
<listitem>
<para>
Forcefully return a RabbitMQ node to its virgin state.
</para>
<para>
The <command>force_reset</command> command differs from
<command>reset</command> in that it resets the node
unconditionally, regardless of the current management
database state and cluster configuration. It should only
be used as a last resort if the database or cluster
configuration has been corrupted.
</para>
<para>
For <command>reset</command> and <command>force_reset</command> to
succeed the RabbitMQ application must have been stopped,
e.g. with <link linkend="stop_app"><command>stop_app</command></link>.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl force_reset</screen>
<para role="example">
This command resets the RabbitMQ node.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>rotate_logs</command> <arg choice="req"><replaceable>suffix</replaceable></arg></cmdsynopsis></term>
<listitem>
<para>
Instruct the RabbitMQ node to rotate the log files.
</para>
<para>
The RabbitMQ broker appends the contents of its log
files to files with names composed of the original name
and the suffix, and then resumes logging to freshly
created files at the original location. I.e. effectively
the current log contents are moved to the end of the
suffixed files.
</para>
<para>
When the target files do not exist they are created.
When no <option>suffix</option> is specified, the empty
log files are simply created at the original location;
no rotation takes place.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl rotate_logs .1</screen>
<para role="example">
This command instructs the RabbitMQ node to append the contents
of the log files to files with names consisting of the original logs'
names and ".1" suffix, e.g. rabbit@mymachine.log.1 and
rabbit@mymachine-sasl.log.1. Finally, logging resumes to
fresh files at the old locations.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect2>
<refsect2>
<title>Cluster management</title>
<variablelist>
<varlistentry id="join_cluster">
<term><cmdsynopsis><command>join_cluster</command> <arg choice="req"><replaceable>clusternode</replaceable></arg> <arg choice="opt">--ram</arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>clusternode</term>
<listitem><para>Node to cluster with.</para></listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><arg choice="opt">--ram</arg></cmdsynopsis></term>
<listitem>
<para>
If provided, the node will join the cluster as a RAM node.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Instruct the node to become a member of the cluster that the
specified node is in. Before clustering, the node is reset, so be
careful when using this command. For this command to succeed the
RabbitMQ application must have been stopped, e.g. with <link
linkend="stop_app"><command>stop_app</command></link>.
</para>
<para>
Cluster nodes can be of two types: disc or RAM. Disc nodes
replicate data in RAM and on disc, thus providing redundancy in
the event of node failure and recovery from global events such
as power failure across all nodes. RAM nodes replicate data in
RAM only (with the exception of queue contents, which can reside
on disc if the queue is persistent or too big to fit in memory)
and are mainly used for scalability. RAM nodes are more
performant only when managing resources (e.g. adding/removing
queues, exchanges, or bindings). A cluster must always have at
least one disc node, and usually should have more than one.
</para>
<para>
The node will be a disc node by default. If you wish to
create a RAM node, provide the <command>--ram</command> flag.
</para>
<para>
After executing the <command>cluster</command> command, whenever
the RabbitMQ application is started on the current node it will
attempt to connect to the nodes that were in the cluster when the
node went down.
</para>
<para>
To leave a cluster, <command>reset</command> the node. You can
also remove nodes remotely with the
<command>forget_cluster_node</command> command.
</para>
<para>
For more details see the <ulink
url="http://www.rabbitmq.com/clustering.html">clustering
guide</ulink>.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl join_cluster hare@elena --ram</screen>
<para role="example">
This command instructs the RabbitMQ node to join the cluster that
<command>hare@elena</command> is part of, as a ram node.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>cluster_status</command></cmdsynopsis></term>
<listitem>
<para>
Displays all the nodes in the cluster grouped by node type,
together with the currently running nodes.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl cluster_status</screen>
<para role="example">
This command displays the nodes in the cluster.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>change_cluster_node_type</command> <arg choice="req">disc | ram</arg></cmdsynopsis>
</term>
<listitem>
<para>
Changes the type of the cluster node. The node must be stopped for
this operation to succeed, and when turning a node into a RAM node
the node must not be the only disc node in the cluster.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl change_cluster_node_type disc</screen>
<para role="example">
This command will turn a RAM node into a disc node.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>forget_cluster_node</command> <arg choice="opt">--offline</arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term><cmdsynopsis><arg choice="opt">--offline</arg></cmdsynopsis></term>
<listitem>
<para>
Enables node removal from an offline node. This is only
useful in the situation where all the nodes are offline and
the last node to go down cannot be brought online, thus
preventing the whole cluster from starting. It should not be
used in any other circumstances since it can lead to
inconsistencies.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Removes a cluster node remotely. The node that is being removed
must be offline, while the node we are removing from must be
online, except when using the <command>--offline</command> flag.
</para>
<para>
When using the <command>--offline</command> flag
rabbitmqctl will not attempt to connect to a node as
normal; instead it will temporarily become the node in
order to make the change. This is useful if the node
cannot be started normally. In this case the node will
become the canonical source for cluster metadata
(e.g. which queues exist), even if it was not
before. Therefore you should use this command on the
latest node to shut down if at all possible.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl -n hare@mcnulty forget_cluster_node rabbit@stringer</screen>
<para role="example">
This command will remove the node
<command>rabbit@stringer</command> from the node
<command>hare@mcnulty</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>rename_cluster_node</command> <arg choice="req">oldnode1</arg> <arg choice="req">newnode1</arg> <arg choice="opt">oldnode2</arg> <arg choice="opt">newnode2 ...</arg></cmdsynopsis></term>
<listitem>
<para>
Supports renaming of cluster nodes in the local database.
</para>
<para>
This subcommand causes rabbitmqctl to temporarily become
the node in order to make the change. The local cluster
node must therefore be completely stopped; other nodes
can be online or offline.
</para>
<para>
This subcommand takes an even number of arguments, in
pairs representing the old and new names for nodes. You
must specify the old and new names for this node and for
any other nodes that are stopped and being renamed at
the same time.
</para>
<para>
It is possible to stop all nodes and rename them all
simultaneously (in which case old and new names for all
nodes must be given to every node) or stop and rename
nodes one at a time (in which case each node only needs
to be told how its own name is changing).
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl rename_cluster_node rabbit@misshelpful rabbit@cordelia</screen>
<para role="example">
This command will rename the node
<command>rabbit@misshelpful</command> to the node
<command>rabbit@cordelia</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>update_cluster_nodes</command> <arg choice="req">clusternode</arg></cmdsynopsis>
</term>
<listitem>
<variablelist>
<varlistentry>
<term>clusternode</term>
<listitem>
<para>
The node to consult for up to date information.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Instructs an already clustered node to contact
<command>clusternode</command> to cluster when waking up. This is
different from <command>join_cluster</command> since it does not
join any cluster - it checks that the node is already in a cluster
with <command>clusternode</command>.
</para>
<para>
The need for this command is motivated by the fact that clusters
can change while a node is offline. Consider the situation in
which node A and B are clustered. A goes down, C clusters with B,
and then B leaves the cluster. When A wakes up, it'll try to
contact B, but this will fail since B is not in the cluster
anymore. <command>update_cluster_nodes -n A C</command> will solve
this situation.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>force_boot</command></cmdsynopsis></term>
<listitem>
<para>
Ensure that the node will start next time, even if it
was not the last to shut down.
</para>
<para>
Normally when you shut down a RabbitMQ cluster
altogether, the first node you restart should be the
last one to go down, since it may have seen things
happen that other nodes did not. But sometimes
that's not possible: for instance if the entire cluster
loses power then all nodes may think they were not the
last to shut down.
</para>
<para>
In such a case you can invoke <command>rabbitmqctl
force_boot</command> while the node is down. This will
tell the node to unconditionally start next time you ask
it to. If any changes happened to the cluster after this
node shut down, they will be lost.
</para>
<para>
If the last node to go down is permanently lost then you
should use <command>rabbitmqctl forget_cluster_node
--offline</command> in preference to this command, as it
will ensure that mirrored queues which were mastered on
the lost node get promoted.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl force_boot</screen>
<para role="example">
This will force the node not to wait for other nodes
next time it is started.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>sync_queue</command> <arg choice="req">queue</arg></cmdsynopsis>
</term>
<listitem>
<variablelist>
<varlistentry>
<term>queue</term>
<listitem>
<para>
The name of the queue to synchronise.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Instructs a mirrored queue with unsynchronised slaves to
synchronise itself. The queue will block while
synchronisation takes place (all publishers to and
consumers from the queue will block). The queue must be
mirrored for this command to succeed.
</para>
<para>
Note that unsynchronised queues from which messages are
being drained will become synchronised eventually. This
command is primarily useful for queues which are not
being drained.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>cancel_sync_queue</command> <arg choice="req">queue</arg></cmdsynopsis>
</term>
<listitem>
<variablelist>
<varlistentry>
<term>queue</term>
<listitem>
<para>
The name of the queue to cancel synchronisation for.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Instructs a synchronising mirrored queue to stop
synchronising itself.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>set_cluster_name</command> <arg choice="req">name</arg></cmdsynopsis></term>
<listitem>
<para>
Sets the cluster name. The cluster name is announced to
clients on connection, and used by the federation and
shovel plugins to record where a message has been. The
cluster name is by default derived from the hostname of
the first node in the cluster, but can be changed.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl set_cluster_name london</screen>
<para role="example">
This sets the cluster name to "london".
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect2>
<refsect2>
<title>User management</title>
<para>
Note that <command>rabbitmqctl</command> manages the RabbitMQ
internal user database. Users from any alternative
authentication backend will not be visible
to <command>rabbitmqctl</command>.
</para>
<variablelist>
<varlistentry>
<term><cmdsynopsis><command>add_user</command> <arg choice="req"><replaceable>username</replaceable></arg> <arg choice="req"><replaceable>password</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>username</term>
<listitem><para>The name of the user to create.</para></listitem>
</varlistentry>
<varlistentry>
<term>password</term>
<listitem><para>The password the created user will use to log in to the broker.</para></listitem>
</varlistentry>
</variablelist>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl add_user tonyg changeit</screen>
<para role="example">
This command instructs the RabbitMQ broker to create a
(non-administrative) user named <command>tonyg</command> with
(initial) password
<command>changeit</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>delete_user</command> <arg choice="req"><replaceable>username</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>username</term>
<listitem><para>The name of the user to delete.</para></listitem>
</varlistentry>
</variablelist>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl delete_user tonyg</screen>
<para role="example">
This command instructs the RabbitMQ broker to delete the
user named <command>tonyg</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>change_password</command> <arg choice="req"><replaceable>username</replaceable></arg> <arg choice="req"><replaceable>newpassword</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>username</term>
<listitem><para>The name of the user whose password is to be changed.</para></listitem>
</varlistentry>
<varlistentry>
<term>newpassword</term>
<listitem><para>The new password for the user.</para></listitem>
</varlistentry>
</variablelist>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl change_password tonyg newpass</screen>
<para role="example">
This command instructs the RabbitMQ broker to change the
password for the user named <command>tonyg</command> to
<command>newpass</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>clear_password</command> <arg choice="req"><replaceable>username</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>username</term>
<listitem><para>The name of the user whose password is to be cleared.</para></listitem>
</varlistentry>
</variablelist>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl clear_password tonyg</screen>
<para role="example">
This command instructs the RabbitMQ broker to clear the
password for the user named
<command>tonyg</command>. This user now cannot log in with a password (but may be able to through e.g. SASL EXTERNAL if configured).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>set_user_tags</command> <arg choice="req"><replaceable>username</replaceable></arg> <arg choice="req"><replaceable>tag</replaceable> ...</arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>username</term>
<listitem><para>The name of the user whose tags are to
be set.</para></listitem>
</varlistentry>
<varlistentry>
<term>tag</term>
<listitem><para>Zero, one or more tags to set. Any
existing tags will be removed.</para></listitem>
</varlistentry>
</variablelist>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl set_user_tags tonyg administrator</screen>
<para role="example">
This command instructs the RabbitMQ broker to ensure the user
named <command>tonyg</command> is an administrator. This has no
effect when the user logs in via AMQP, but can be used to permit
the user to manage users, virtual hosts and permissions when the
user logs in via some other means (for example with the
management plugin).
</para>
<screen role="example">rabbitmqctl set_user_tags tonyg</screen>
<para role="example">
This command instructs the RabbitMQ broker to remove any
tags from the user named <command>tonyg</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>list_users</command></cmdsynopsis></term>
<listitem>
<para>
Lists users. Each result row will contain the user name
followed by a list of the tags set for that user.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl list_users</screen>
<para role="example">
This command instructs the RabbitMQ broker to list all
users.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect2>
<refsect2>
<title>Access control</title>
<para>
Note that <command>rabbitmqctl</command> manages the RabbitMQ
internal user database. Permissions for users from any
alternative authorisation backend will not be visible
to <command>rabbitmqctl</command>.
</para>
<variablelist>
<varlistentry>
<term><cmdsynopsis><command>add_vhost</command> <arg choice="req"><replaceable>vhostpath</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>vhostpath</term>
<listitem><para>The name of the virtual host entry to create.</para></listitem>
</varlistentry>
</variablelist>
<para>
Creates a virtual host.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl add_vhost test</screen>
<para role="example">
This command instructs the RabbitMQ broker to create a new
virtual host called <command>test</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>delete_vhost</command> <arg choice="req"><replaceable>vhostpath</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>vhostpath</term>
<listitem><para>The name of the virtual host entry to delete.</para></listitem>
</varlistentry>
</variablelist>
<para>
Deletes a virtual host.
</para>
<para>
Deleting a virtual host deletes all its exchanges,
queues, bindings, user permissions, parameters and policies.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl delete_vhost test</screen>
<para role="example">
This command instructs the RabbitMQ broker to delete the
virtual host called <command>test</command>.
</para>
</listitem>
</varlistentry>
<varlistentry role="usage-has-option-list">
<term><cmdsynopsis><command>list_vhosts</command> <arg choice="opt" role="usage-option-list"><replaceable>vhostinfoitem</replaceable> ...</arg></cmdsynopsis></term>
<listitem>
<para>
Lists virtual hosts.
</para>
<para>
The <command>vhostinfoitem</command> parameter is used to indicate which
virtual host information items to include in the results. The column order in the
results will match the order of the parameters.
<command>vhostinfoitem</command> can take any value from
the list that follows:
</para>
<variablelist>
<varlistentry>
<term>name</term>
<listitem><para>The name of the virtual host with non-ASCII characters escaped as in C.</para></listitem>
</varlistentry>
<varlistentry>
<term>tracing</term>
<listitem><para>Whether tracing is enabled for this virtual host.</para></listitem>
</varlistentry>
</variablelist>
<para>
If no <command>vhostinfoitem</command>s are specified
then the vhost name is displayed.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl list_vhosts name tracing</screen>
<para role="example">
This command instructs the RabbitMQ broker to list all
virtual hosts.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>set_permissions</command> <arg choice="opt">-p <replaceable>vhostpath</replaceable></arg> <arg choice="req"><replaceable>user</replaceable></arg> <arg choice="req"><replaceable>conf</replaceable></arg> <arg choice="req"><replaceable>write</replaceable></arg> <arg choice="req"><replaceable>read</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>vhostpath</term>
<listitem><para>The name of the virtual host to which to grant the user access, defaulting to <command>/</command>.</para></listitem>
</varlistentry>
<varlistentry>
<term>user</term>
<listitem><para>The name of the user to grant access to the specified virtual host.</para></listitem>
</varlistentry>
<varlistentry>
<term>conf</term>
<listitem><para>A regular expression matching resource names for which the user is granted configure permissions.</para></listitem>
</varlistentry>
<varlistentry>
<term>write</term>
<listitem><para>A regular expression matching resource names for which the user is granted write permissions.</para></listitem>
</varlistentry>
<varlistentry>
<term>read</term>
<listitem><para>A regular expression matching resource names for which the user is granted read permissions.</para></listitem>
</varlistentry>
</variablelist>
<para>
Sets user permissions.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl set_permissions -p /myvhost tonyg "^tonyg-.*" ".*" ".*"</screen>
<para role="example">
This command instructs the RabbitMQ broker to grant the
user named <command>tonyg</command> access to the virtual host
called <command>/myvhost</command>, with configure permissions
on all resources whose names starts with "tonyg-", and
write and read permissions on all resources.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>clear_permissions</command> <arg choice="opt">-p <replaceable>vhostpath</replaceable></arg> <arg choice="req"><replaceable>username</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>vhostpath</term>
<listitem><para>The name of the virtual host to which to deny the user access, defaulting to <command>/</command>.</para></listitem>
</varlistentry>
<varlistentry>
<term>username</term>
<listitem><para>The name of the user to deny access to the specified virtual host.</para></listitem>
</varlistentry>
</variablelist>
<para>
Sets user permissions.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl clear_permissions -p /myvhost tonyg</screen>
<para role="example">
This command instructs the RabbitMQ broker to deny the
user named <command>tonyg</command> access to the virtual host
called <command>/myvhost</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>list_permissions</command> <arg choice="opt">-p <replaceable>vhostpath</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>vhostpath</term>
<listitem><para>The name of the virtual host for which to list the users that have been granted access to it, and their permissions. Defaults to <command>/</command>.</para></listitem>
</varlistentry>
</variablelist>
<para>
Lists permissions in a virtual host.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl list_permissions -p /myvhost</screen>
<para role="example">
This command instructs the RabbitMQ broker to list all
the users which have been granted access to the virtual
host called <command>/myvhost</command>, and the
permissions they have for operations on resources in
that virtual host. Note that an empty string means no
permissions granted.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><cmdsynopsis><command>list_user_permissions</command> <arg choice="req"><replaceable>username</replaceable></arg></cmdsynopsis></term>
<listitem>
<variablelist>
<varlistentry>
<term>username</term>
<listitem><para>The name of the user for which to list the permissions.</para></listitem>
</varlistentry>
</variablelist>
<para>
Lists user permissions.
</para>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl list_user_permissions tonyg</screen>
<para role="example">
This command instructs the RabbitMQ broker to list all the
virtual hosts to which the user named <command>tonyg</command>
has been granted access, and the permissions the user has
for operations on resources in these virtual hosts.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect2>
<refsect2>
<title>Parameter Management</title>
<para>
Certain features of RabbitMQ (such as the federation plugin)
are controlled by dynamic,
cluster-wide <emphasis>parameters</emphasis>. Each parameter
consists of a component name, a name and a value, and is
associated with a virtual host. The component name and name are
strings, and the value is an Erlang term. Parameters can be
set, cleared and listed. In general you should refer to the
documentation for the feature in question to see how to set
parameters.
</para>
<variablelist>
<varlistentry>
<term><cmdsynopsis><command>set_parameter</command> <arg choice="opt">-p <replaceable>vhostpath</replaceable></arg> <arg choice="req"><replaceable>component_name</replaceable></arg> <arg choice="req"><replaceable>name</replaceable></arg> <arg choice="req"><replaceable>value</replaceable></arg></cmdsynopsis></term>
<listitem>
<para>
Sets a parameter.
</para>
<variablelist>
<varlistentry>
<term>component_name</term>
<listitem><para>
The name of the component for which the
parameter is being set.
</para></listitem>
</varlistentry>
<varlistentry>
<term>name</term>
<listitem><para>
The name of the parameter being set.
</para></listitem>
</varlistentry>
<varlistentry>
<term>value</term>
<listitem><para>
The value for the parameter, as a
JSON term. In most shells you are very likely to
need to quote this.
</para></listitem>
</varlistentry>
</variablelist>
<para role="example-prefix">For example:</para>
<screen role="example">rabbitmqctl set_parameter federation local_username '"guest"'</screen>
<para role="example">
This command sets the parameter <command>local_username</command> for the <command>federation</command> component in the default virtual host to the JSON term <command>"guest"</command>.
</para>