Skip to content

Commit aba7591

Browse files
ODOWDAIBMdenyeart
ODOWDAIBM
authored and
denyeart
committedFeb 25, 2018
[FAB-8409] Peer command reference updates
Includes: Command reference TOC changes Peer command topic Peer channel command Addresses review comments JIRA https://jira.hyperledger.org/browse/FAB-8179 Staged on http://fabricdocs1.readthedocs.io/en/issue-fab-8179/ Change-Id: I86bf37b1ad3239ccd2ea89c2ebf959f1b2ec4349 Signed-off-by: Anthony O'Dowd <a_o-dowd@uk.ibm.com> Signed-off-by: David Enyeart <enyeart@us.ibm.com>
·
v3.1.0v1.1.0-rc1
1 parent 3bb392a commit aba7591

File tree

4 files changed

+728
-2
lines changed

4 files changed

+728
-2
lines changed
 

‎docs/source/channels.rst

-1
Original file line numberDiff line numberDiff line change
@@ -40,4 +40,3 @@ on the same blockchain network.
4040

4141
.. Licensed under Creative Commons Attribution 4.0 International License
4242
https://creativecommons.org/licenses/by/4.0/
43-

‎docs/source/commands/peerchannel.md

+601
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,601 @@
1+
# peer channel
2+
3+
## Description
4+
5+
The `peer channel` command allows administrators to perform channel related
6+
operations on a peer, such as joining a channel or listing the channels to which
7+
a peer is joined.
8+
9+
## Syntax
10+
11+
The `peer channel` command has the following syntax:
12+
13+
```
14+
peer channel create [flags]
15+
peer channel fetch [flags]
16+
peer channel getinfo [flags]
17+
peer channel join [flags]
18+
peer channel list [flags]
19+
peer channel signconfigtx [flags]
20+
peer channel update [flags]
21+
```
22+
23+
For brevity, we often refer to a command (`peer`), a subcommand (`channel`), or
24+
subcommand option (`fetch`) simply as a **command**.
25+
26+
The different command options (`create`, `fetch`...) relate to the different
27+
channel operations that are relevant to a peer. For example, use the `peer
28+
channel join` command to join a peer to a channel, or the `peer channel list`
29+
command to show the channels to which a peer is joined.
30+
31+
Each peer channel subcommand is described together with its options in its own
32+
section in this topic.
33+
34+
## Flags
35+
36+
Each `peer channel` command option has a set of flags specific to it, and these
37+
are described with the relevant subcommand option.
38+
39+
All `peer channel` command options also have a set of global flags that can be
40+
applied to `peer channel` command options.
41+
42+
The global flags are as follows:
43+
44+
* `--cafile <string>`
45+
46+
where `<string>` is a fully qualified path to a file containing a PEM-encoded
47+
certificate chain of the Certificate Authority of the orderer with whom the
48+
peer is communicating. Use in conjunction with the `--tls` flag.
49+
50+
* `--certfile <string>`
51+
52+
where `<string>` is a fully qualified path to a file containing a PEM-encoded
53+
X.509 certificate used for mutual authentication with the orderer. Use in
54+
conjunction with the `--clientauth` flag.
55+
56+
* `--clientauth`
57+
58+
Use this flag to enable mutual TLS communication with the orderer. Use in
59+
conjunction with the `--certfile` and `--keyfile` flags.
60+
61+
* `--keyfile <string>`
62+
63+
where `<string>` is a fully qualified path to a file containing a PEM-encoded
64+
X.509 private key used for mutual authentication with the orderer. Use in
65+
conjunction with the `--clientauth` flag.
66+
67+
* `-o, --orderer <string>`
68+
69+
where `<string>` is the fully qualified address and port of the orderer
70+
with whom the peer is communicating. If the port is not specified, it will
71+
default to port 7050.
72+
73+
* `--ordererTLSHostnameOverride <string>`
74+
75+
where `<string>` is the hostname override to use when using TLS to communicate
76+
with the orderer specified by the `--orderer` flag. It is necessary to use
77+
this flag when the TLS handshake phase of communications between the peer and
78+
the orderer uses a different hostname than the subsequent message exchange
79+
phase. Use in conjunction with the `--tls` flag.
80+
81+
* `--tls`
82+
83+
Use this flag to enable TLS communications with an orderer. The certificates
84+
identified by `--cafile` will be used by TLS to authenticate the orderer.
85+
86+
## Usage
87+
88+
Here's an example that uses the `--orderer` global flag on the `peer channel
89+
create` command.
90+
91+
* Create a sample channel `mychannel` defined by the configuration transaction
92+
contained in file `./createchannel.txn`. Use the orderer at `orderer.example.com:7050`.
93+
94+
```
95+
peer channel create -c mychannel -f ./createchannel.txn --orderer orderer.example.com:7050
96+
97+
2018-02-25 08:23:57.548 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
98+
2018-02-25 08:23:57.626 UTC [channelCmd] InitCmdFactory -> INFO 019 Endorser and orderer connections initialized
99+
2018-02-25 08:23:57.834 UTC [channelCmd] readBlock -> DEBU 020 Received block: 0
100+
2018-02-25 08:23:57.835 UTC [main] main -> INFO 021 Exiting.....
101+
102+
```
103+
104+
Block 0 is returned indicating that the channel has been successfully created.
105+
106+
## peer channel create
107+
108+
### Create Description
109+
110+
The `peer channel create` command allows administrators to create a
111+
new channel. This command connects to an orderer to perform this function -- it
112+
is not performed on the peer, even though the `peer` command is used.
113+
114+
To create a channel, the administrator uses the command to submit a
115+
configuration update transaction to the orderer. This transaction describes the
116+
configuration changes required to create a new channel. Moreover, this
117+
transaction must be be signed by the required organizations as defined by the
118+
current orderer configuration. Configuration transactions can be generated by
119+
the [`configtxgen` command](.configtxgen.html) and signed by the `peer channel signconfigtx` command.
120+
121+
### Create Syntax
122+
123+
The `peer channel create` command has the following syntax:
124+
125+
```
126+
peer channel create [flags]
127+
```
128+
129+
### Create Flags
130+
131+
The `peer channel create` command has the following command specific
132+
flags:
133+
134+
* `-c, --channelID <string>`
135+
136+
**required**, where `<string>` is the name of the channel which is to be
137+
created.
138+
139+
* `-f, --file <string>`
140+
141+
**required**, where `<string>` identifies a file which
142+
contains the configuration transaction required to create this channel. It
143+
can be generated by [`configtxgen` command](./configtxgen.html).
144+
145+
* `-t, --timeout <integer>`
146+
147+
**optional**, where `<integer>` specifies channel creation timeout in
148+
seconds. If not specified, the default is 5 seconds. Note that if the
149+
command times out, then the channel may or may not have been created.
150+
151+
The global `peer` command flags also apply as follows:
152+
153+
* `-o, --orderer` **required**
154+
* `--cafile` **optional**
155+
* `--certfile` **optional**
156+
* `--clientuth` **optional**
157+
* `--keyfile` **optional**
158+
* `--ordererTLSHostnameOverride` **optional**
159+
* `--tls` **optional**
160+
161+
### Create Usage
162+
163+
Here's an example of the `peer channel create` command option.
164+
165+
* Create a new channel `mychannel` for the network, using the orderer at ip
166+
address `orderer.example.com:7050`. The configuration update transaction
167+
required to create this channel is defined the file `./createchannel.txn`.
168+
Wait 30 seconds for the channel to be created.
169+
170+
```
171+
peer channel create -c mychannel --orderer orderer.example.com:7050 -f ./createchannel.txn -t 30
172+
173+
2018-02-23 06:31:58.568 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
174+
2018-02-23 06:31:58.669 UTC [channelCmd] InitCmdFactory -> INFO 019 Endorser and orderer connections initialized
175+
2018-02-23 06:31:58.877 UTC [channelCmd] readBlock -> DEBU 020 Received block: 0
176+
2018-02-23 06:31:58.878 UTC [main] main -> INFO 021 Exiting.....
177+
178+
ls -l
179+
180+
-rw-r--r-- 1 root root 11982 Feb 25 12:24 mychannel.block
181+
182+
```
183+
184+
You can see that channel `mychannel` has been successfully created, as
185+
indicated in the output where block 0 (zero) is added to the blockchain for
186+
this channel and returned to the peer, where it is stored in the local
187+
directory as `mychannel.block`.
188+
189+
Block zero is often called the *genesis block* as it provides the starting
190+
configuration for the channel. All subsequent updates to the channel will be
191+
captured as configuration blocks on the channel's blockchain, each of which
192+
supersedes the previous configuration.
193+
194+
## peer channel fetch
195+
196+
### Fetch Description
197+
198+
The `peer channel fetch` command allows a client to fetch a block
199+
from the orderer. The block may contain a configuration transaction or
200+
user transactions.
201+
202+
The client must have read access to the channel. This command connects to an
203+
orderer to perform this function -- it is not performed on the peer, even
204+
though the `peer` client command is used.
205+
206+
### Fetch Syntax
207+
208+
The `peer channel fetch` command has the following syntax:
209+
210+
```
211+
peer channel fetch [newest|oldest|config|(block number)] [<outputFile>] [flags]
212+
```
213+
214+
where
215+
216+
* `newest`
217+
218+
returns the most recent block available at the orderer for the channel. This
219+
may be a user transaction block or a configuration block.
220+
221+
This option will also return the block number of the most recent block.
222+
223+
* `oldest`
224+
225+
returns the oldest block available at the orderer for the channel. This may
226+
be a user transaction block or a configuration block.
227+
228+
This option will also return the block number of the oldest available block.
229+
230+
* `config`
231+
232+
returns the most recent configuration block available at the orderer for the
233+
channel.
234+
235+
This option will also return the block number of the most recent
236+
configuration block.
237+
238+
* `(block number)`
239+
240+
returns the requested block for the channel. This may be a user transaction
241+
block or a configuration block.
242+
243+
Specifying 0 will result in the genesis block for this channel being
244+
returned (if it is still available to the network orderer).
245+
246+
* `<outputFile>`
247+
248+
specifies the name of the file where the fetched block is written. If
249+
`<outputFile>` is not specified, then the block is written to the local
250+
directory in a file named as follows:
251+
252+
* `<channelID>_newest.block`
253+
* `<channelID>_oldest.block`
254+
* `<channelID>_config.block`
255+
* `<channelID>_(block number).block`
256+
257+
### Fetch Flags
258+
259+
The `peer channel fetch` command has the following command specific
260+
flags:
261+
262+
* `-c, --channelID <string>`
263+
264+
**required**, where `<string>` is the name of the channel for which the
265+
blocks are to be fetched from the orderer.
266+
267+
The global `peer` command flags also apply:
268+
269+
* `-o, --orderer` **required**
270+
* `--cafile` **optional**
271+
* `--certfile` **optional**
272+
* `--clientuth` **optional**
273+
* `--keyfile` **optional**
274+
* `--ordererTLSHostnameOverride` **optional**
275+
* `--tls` **optional**
276+
277+
### Fetch Usage
278+
279+
Here's some examples of the `peer channel fetch` command.
280+
281+
* Using the `newest` option to retrieve the most recent channel block, and store it in the file `mychannel.block`.
282+
283+
```
284+
peer channel fetch newest mychannel.block -c mychannel --orderer orderer.example.com:7050
285+
286+
2018-02-25 13:10:16.137 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
287+
2018-02-25 13:10:16.144 UTC [channelCmd] readBlock -> DEBU 00a Received block: 32
288+
2018-02-25 13:10:16.145 UTC [main] main -> INFO 00b Exiting.....
289+
290+
ls -l
291+
292+
-rw-r--r-- 1 root root 11982 Feb 25 13:10 mychannel.block
293+
294+
```
295+
296+
You can see that the retrieved block is number 32, and that the information
297+
has been written to the file `mychannel.block`.
298+
299+
* Using the `(block number)` option to retrieve a specific block -- in this
300+
case, block number 16 -- and store it in the default block file.
301+
302+
```
303+
peer channel fetch 16 -c mychannel --orderer orderer.example.com:7050
304+
305+
2018-02-25 13:46:50.296 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
306+
2018-02-25 13:46:50.302 UTC [channelCmd] readBlock -> DEBU 00a Received block: 16
307+
2018-02-25 13:46:50.302 UTC [main] main -> INFO 00b Exiting.....
308+
309+
ls -l
310+
311+
-rw-r--r-- 1 root root 11982 Feb 25 13:10 mychannel.block
312+
-rw-r--r-- 1 root root 4783 Feb 25 13:46 mychannel_16.block
313+
314+
```
315+
316+
You can see that the retrieved block is number 16, and that the information
317+
has been written to the default file `mychannel_16.block`.
318+
319+
For configuration blocks, the block file can be decoded using the
320+
[`configtxlator` command](./configtxlator.html). See this command for an example
321+
of decoded output. User transaction blocks can also be decoded, but a user
322+
program must be written to do this.
323+
324+
## peer channel getinfo
325+
326+
### GetInfo Description
327+
328+
The `peer channel getinfo` command allows administrators to retrieve information
329+
about the peer's local blockchain for a particular channel. This includes the
330+
current blockchain height, and the hashes of the current block and previous
331+
block. Remember that a peer can be joined to more than one channel.
332+
333+
This information can be useful when administrators need to understand the
334+
current state of a peer's blockchain, especially in comparison to other peers in
335+
the same channel.
336+
337+
### GetInfo Syntax
338+
339+
The `peer channel getinfo` command has the following syntax:
340+
341+
```
342+
peer channel getinfo [flags]
343+
```
344+
345+
### GetInfo Flags
346+
347+
The `peer channel getinfo` command has no specific flags.
348+
349+
None of the global `peer` command flags apply, since this command does not interact with an orderer.
350+
351+
### GetInfo Usage
352+
353+
Here's an example of the `peer channel getinfo` command.
354+
355+
* Get information about the local peer for channel `mychannel`.
356+
357+
```
358+
peer channel getinfo -c mychannel
359+
360+
2018-02-25 15:15:44.135 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
361+
Blockchain info: {"height":5,"currentBlockHash":"JgK9lcaPUNmFb5Mp1qe1SVMsx3o/22Ct4+n5tejcXCw=","previousBlockHash":"f8lZXoAn3gF86zrFq7L1DzW2aKuabH9Ow6SIE5Y04a4="}
362+
2018-02-25 15:15:44.139 UTC [main] main -> INFO 006 Exiting.....
363+
364+
```
365+
366+
You can see that the latest block for channel `mychannel` is block 5. You can also
367+
see the crytographic hashes for the most recent blocks in the channel's blockchain.
368+
369+
## peer channel join
370+
371+
### Join Description
372+
373+
The `peer channel join` command allows administrators to join a peer to an
374+
existing channel. The administrator achieves this by using the command to
375+
provide a channel genesis block to the peer. The peer will then automatically
376+
retrieve the channel's blocks from other peers in the network, or the
377+
orderer, depending on the configuration, and the availability of
378+
other peers.
379+
380+
The administrator can create a local genesis block for use by this command by
381+
retrieving block 0 from an existing channel using the `peer channel fetch`
382+
command option. The `peer channel create` command will also return a local
383+
genesis block when a new channel is created.
384+
385+
### Join Syntax
386+
387+
The `peer channel join` command has the following syntax:
388+
389+
```
390+
peer channel join [flags]
391+
```
392+
393+
### Join Flags
394+
395+
The `peer channel join` command has the following command specific
396+
flags:
397+
398+
* `-b, --blockpath <string>`
399+
400+
**required**, where `<string>` identifies a file containing the channel
401+
genesis block. This block can be retrieved using the `peer channel
402+
fetch` command, requesting block 0 from the channel, or using the `peer
403+
channel create` command.
404+
405+
None of the global `peer` command flags apply, since this command does not interact with an orderer.
406+
407+
### Join Usage
408+
409+
Here's an example of the `peer channel join` command.
410+
411+
* Join a peer to the channel defined in the genesis block identified by the file
412+
`./mychannel.genesis.block`. In this example, the channel block was
413+
previously retrieved by the `peer channel fetch` command.
414+
415+
```
416+
peer channel join -b ./mychannel.genesis.block
417+
418+
2018-02-25 12:25:26.511 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
419+
2018-02-25 12:25:26.571 UTC [channelCmd] executeJoin -> INFO 006 Successfully submitted proposal to join channel
420+
2018-02-25 12:25:26.571 UTC [main] main -> INFO 007 Exiting.....
421+
422+
```
423+
424+
You can see that the peer has successfully made a request to join the channel.
425+
426+
## peer channel list
427+
428+
### List Description
429+
430+
The `peer channel list` command allows administrators list the channels to which
431+
a peer is joined.
432+
433+
### List Syntax
434+
435+
The `peer channel list` command has the following syntax:
436+
437+
```
438+
peer channel list [flags]
439+
```
440+
441+
### List Flags
442+
443+
The `peer channel list` command has no specific flags.
444+
445+
None of the global `peer` command flags apply, since this command does not interact with an orderer.
446+
447+
### List Usage
448+
449+
Here's an example of the `peer channel list` command.
450+
451+
* List the channels to which a peer is joined.
452+
453+
```
454+
peer channel list
455+
456+
2018-02-25 14:21:20.361 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
457+
Channels peers has joined:
458+
mychannel
459+
2018-02-25 14:21:20.372 UTC [main] main -> INFO 006 Exiting.....
460+
461+
```
462+
463+
You can see that the peer is joined to channel `mychannel`.
464+
465+
## peer channel signconfigtx
466+
467+
### SignConfigTx Description
468+
469+
The `peer channel signconfigtx` command helps administrators sign a
470+
configuration transaction with the peer's identity credentials prior to
471+
submission to an orderer. Typical configuration transactions include creating a
472+
channel or updating a channel configuration.
473+
474+
The administrator supplies an input file to the `signconfigtx` command which
475+
describes the configuration transaction. The command then adds the peer's public
476+
identity to the file, and signs the entire payload with the peer's private key.
477+
The command uses the peer's public and private credentials stored in its local
478+
MSP. A new file is not generated; the input file is updated in place.
479+
480+
`signconfigtx` only signs the configuration transaction; it does not create it,
481+
nor submit it to the orderer. Typically, the configuration transaction has been
482+
already created using the [`configtxgen` command](.configtxgen.html), and is
483+
subsequently submitted to the orderer by an appropriate command such as `peer
484+
channel update`.
485+
486+
### SignConfigTx Syntax
487+
488+
The `peer channel signconfigtx` command has the following syntax:
489+
490+
```
491+
peer channel signconfigtx [flags]
492+
```
493+
494+
### SignConfigTx Flags
495+
496+
The `peer channel signconfigtx` command has the following command specific
497+
flags:
498+
499+
* `-f, --file <string>`
500+
501+
**required**, where `<string>` identifies a file containing the channel
502+
configuration transaction to be signed on behalf of the peer.
503+
504+
None of the global `peer` command flags apply, since this command does not interact with an orderer.
505+
506+
### SignConfigTx Usage
507+
508+
Here's an example of the `peer channel signconfigtx` command.
509+
510+
* Sign the `channel update` transaction defined in the file
511+
`./updatechannel.txn`. The example lists the configuration transaction file
512+
before and after the command.
513+
514+
```
515+
ls -l
516+
517+
-rw-r--r-- 1 anthonyodowd staff 284 25 Feb 18:16 updatechannel.tx
518+
519+
peer channel signconfigtx -f updatechannel.tx
520+
521+
2018-02-25 18:16:44.456 GMT [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
522+
2018-02-25 18:16:44.459 GMT [main] main -> INFO 002 Exiting.....
523+
524+
ls -l
525+
526+
-rw-r--r-- 1 anthonyodowd staff 2180 25 Feb 18:16 updatechannel.tx
527+
528+
```
529+
530+
You can see that the peer has successfully signed the configuration
531+
transaction by the increase in the size of the file `updatechannel.tx` from 284 bytes to 2180 bytes.
532+
533+
## peer channel update
534+
535+
### Update Description
536+
537+
The `peer channel update` command allows administrators to update an
538+
existing channel.
539+
540+
To update a channel, the administrator uses the command to submit a
541+
configuration transaction to the orderer which describes the required channel
542+
configuration changes. This transaction must be signed by the required
543+
organizations as defined in the current channel configuration. Configuration
544+
transactions can be generated by the [`configtxgen` command](.configtxgen.html) and signed by the `peer channel signconfigtx` command.
545+
546+
The update transaction is sent by the command to the orderer, which validates
547+
the change is authorized, and then distributes a configuration block to every
548+
peer on the channel. In this way, every peer on the channel maintains a
549+
consistent copy of the channel configuration.
550+
551+
### Update Syntax
552+
553+
The `peer channel update` command has the following syntax:
554+
555+
```
556+
peer channel update [flags]
557+
```
558+
559+
### Update flags
560+
561+
The `peer channel update` command has the following command specific
562+
flags:
563+
564+
* `-c, --channelID <string>`
565+
566+
**required**, where `<string>` is the name of the channel which is to be updated.
567+
568+
* `-f, --file <string>`
569+
570+
**required**, where `<string>` identifies a transaction configuration file.
571+
This file contains the configuration change required to this channel, and
572+
it can be generated by [`configtxgen` command](./configtxgen.html).
573+
574+
The global `peer` command flags also apply as follows:
575+
576+
* `-o, --orderer` **required**
577+
* `--cafile` **optional**
578+
* `--certfile` **optional**
579+
* `--clientuth` **optional**
580+
* `--keyfile` **optional**
581+
* `--ordererTLSHostnameOverride` **optional**
582+
* `--tls` **optional**
583+
584+
### Update Usage
585+
586+
Here's an example of the `peer channel update` command.
587+
588+
* Update the channel `mychannel` using the configuration transaction defined in
589+
the file `./updatechannel.txn`. Use the orderer at ip address
590+
`orderer.example.com:7050` to send the configuration transaction to all peers
591+
in the channel to update their copy of the channel configuration.
592+
593+
```
594+
peer channel update -c mychannel -f ./updatechannel.txn -o orderer.example.com:7050
595+
596+
2018-02-23 06:32:11.569 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
597+
2018-02-23 06:32:11.626 UTC [main] main -> INFO 010 Exiting.....
598+
599+
```
600+
601+
At this point, the channel `mychannel` has been successfully updated.

‎docs/source/commands/peercommand.md

+124
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,124 @@
1+
# peer command
2+
3+
## Description
4+
5+
The `peer` command has five different subcommands, each of which allows
6+
administrators to perform a specific set of tasks related to a peer. For
7+
example, you can use the `peer channel` subcommand to join a peer to a channel,
8+
or the `peer chaincode` command to deploy a smart contract chaincode to a
9+
peer.
10+
11+
## Syntax
12+
13+
The `peer` command has five different subcommands within it:
14+
15+
```
16+
peer chaincode [option] [flags]
17+
peer channel [option] [flags]
18+
peer logging [option] [flags]
19+
peer node [option] [flags]
20+
peer version [option] [flags]
21+
```
22+
23+
Each subcommand has different options available, and these are described in
24+
their own dedicated topic. For brevity, we often refer to a command (`peer`), a
25+
subcommand (`channel`), or subcommand option (`fetch`) simply as a **command**.
26+
27+
If a subcommand is specified without an option, then it will return some high
28+
level help text as described in the `--help` flag below.
29+
30+
## Flags
31+
32+
Each `peer` subcommand has a specific set of flags associated with it, many of
33+
which are designated *global* because they can be used in all subcommand
34+
options. These flags are described with the relevant `peer` subcommand.
35+
36+
The top level `peer` command has the following flags:
37+
38+
* `--help`
39+
40+
Use `--help` to get brief help text for any `peer` command. The `--help` flag
41+
is very useful -- it can be used to get command help, subcommand help, and
42+
even option help.
43+
44+
For example
45+
```
46+
peer --help
47+
peer channel --help
48+
peer channel list --help
49+
50+
```
51+
See individual `peer` subcommands for more detail.
52+
53+
* `--logging-level <string>`
54+
55+
This flag sets the logging level for a peer when it is started.
56+
57+
There are six possible values for `<string>` : `debug`, `info`, `notice`,
58+
`warning`, `error`, and `critical`.
59+
60+
If `logging-level` is not explicitly specified, then it is taken from the
61+
`CORE_LOGGING_LEVEL` environment variable if it is set. If
62+
`CORE_LOGGING_LEVEL` is not set then the file `sampleconfig/core.yaml` is used
63+
to determined the logging level for the peer.
64+
65+
You can find the current logging level for a specific component on the peer by
66+
running `peer logging getlevel <component-name>`.
67+
68+
* `--version`
69+
70+
Use this flag to show detailed information about how the peer was built. This
71+
flag cannot be applied to `peer` subcommands or their options.
72+
73+
## Usage
74+
75+
Here's some examples using the different available flags on the `peer` command.
76+
77+
* Using the `--help` flag on the `peer channel join` command.
78+
79+
```
80+
peer channel join --help
81+
82+
Joins the peer to a channel.
83+
84+
Usage:
85+
peer channel join [flags]
86+
87+
Flags:
88+
-b, --blockpath string Path to file containing genesis block
89+
90+
Global Flags:
91+
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
92+
--certfile string Path to file containing PEM-encoded X509 public key to use for mutual TLS communication with the orderer endpoint
93+
--clientauth Use mutual TLS when communicating with the orderer endpoint
94+
--keyfile string Path to file containing PEM-encoded private key to use for mutual TLS communication with the orderer endpoint
95+
--logging-level string Default logging level and overrides, see core.yaml for full syntax
96+
-o, --orderer string Ordering service endpoint
97+
--ordererTLSHostnameOverride string The hostname override to use when validating the TLS connection to the orderer.
98+
--tls Use TLS when communicating with the orderer endpoint
99+
-v, --version Display current version of fabric peer server
100+
101+
```
102+
This shows brief help syntax for the `peer channel join` command.
103+
104+
* Using the `--version` flag on the `peer` command.
105+
106+
```
107+
peer --version
108+
109+
peer:
110+
Version: 1.1.0-alpha
111+
Go version: go1.9.2
112+
OS/Arch: linux/amd64
113+
Experimental features: false
114+
Chaincode:
115+
Base Image Version: 0.4.5
116+
Base Docker Namespace: hyperledger
117+
Base Docker Label: org.hyperledger.fabric
118+
Docker Namespace: hyperledger
119+
120+
```
121+
122+
This shows that this peer was built using an alpha of Hyperledger Fabric
123+
version 1.1.0, compiled with GOLANG 1.9.2. It can be used on Linux operating
124+
systems with AMD64 compatible instruction sets.

‎docs/source/index.rst

+3-1
Original file line numberDiff line numberDiff line change
@@ -73,7 +73,6 @@ Business:
7373
endorsement-policies
7474
error-handling
7575
logging-control
76-
peer-commands
7776
cryptogen-commands
7877
enable_tls
7978
kafka
@@ -82,6 +81,9 @@ Business:
8281
:maxdepth: 2
8382
:caption: Command Reference
8483

84+
commands/peercommand.md
85+
commands/peerchannel.md
86+
commands/peerlogging.md
8587
commands/configtxgen.md
8688
commands/configtxlator.md
8789

0 commit comments

Comments
 (0)
Please sign in to comment.