[ja_JP] Tutorials / Updating a channel configuration

Open shimos opened this issue 2 years ago • 0 comments
Original HTML: https://hyperledger-fabric.readthedocs.io/en/release-2.5/config_update.html Original Source: https://github.com/hyperledger/fabric/blob/e1e8e2e52aa4fc543360d245fe6554a0eaf81183/docs/source/config_update.md
diff --git a/docs/source/config_update.md b/docs/source/config_update.md
index 88faf1fb2..b7d76b8a6 100644
--- a/docs/source/config_update.md
+++ b/docs/source/config_update.md
@@ -2,6 +2,8 @@
 
 *Audience: network administrators, node administrators*
 
+Note: this topic describes the process for updating a channel on a network that does not have a system channel. For a version of this topic that includes information about the system channel, check out [Updating a channel configuration](https://hyperledger-fabric.readthedocs.io/en/release-2.2/config_update.html).
+
 ## What is a channel configuration?
 
 Like many complex systems, Hyperledger Fabric networks are comprised of both **structure** and a number related of **processes**.
@@ -9,7 +11,7 @@ Like many complex systems, Hyperledger Fabric networks are comprised of both **s
 * **Structure**: encompassing users (like admins), organizations, peers, ordering nodes, CAs, smart contracts, and applications.
 * **Process**: the way these structures interact. Most important of these are [Policies](./policies/policies.html), the rules that govern which users can do what, and under what conditions.
 
-Information identifying the structure of blockchain networks and the processes governing how structures interact are contained in **channel configurations**. These configurations are collectively decided upon by the members of channels and are contained in blocks that are committed to the ledger of a channel. Channel configurations can be built using a tool called `configtxgen`, which uses a `configtx.yaml` file as its input. You can look at a [sample `configtx.yaml` file here](http://github.com/hyperledger/fabric/blob/release-2.2/sampleconfig/configtx.yaml).
+Information identifying the structure of blockchain networks and the processes governing how structures interact are contained in **channel configurations**. These configurations are collectively decided upon by the members of channels and are contained in blocks that are committed to the ledger of a channel. Channel configurations can be built using a tool called `configtxgen`, which uses a `configtx.yaml` file as its input. You can look at a [sample `configtx.yaml` file here](http://github.com/hyperledger/fabric/blob/{BRANCH}/sampleconfig/configtx.yaml).
 
 Because configurations are contained in blocks (the first of these is known as the genesis block with the latest representing the current configuration of the channel), the process for updating a channel configuration (changing the structure by adding members, for example, or processes by modifying channel policies) is known as a **configuration update transaction**.
 
@@ -33,11 +35,9 @@ In this section, we'll look a sample channel configuration and show the configur
 
 To see what the configuration file of an application channel looks like after it has been pulled and scoped, click **Click here to see the config** below. For ease of readability, it might be helpful to put this config into a viewer that supports JSON folding, like atom or Visual Studio.
 
-Note: for simplicity, we are only showing an application channel configuration here. The configuration of the orderer system channel is very similar, but not identical, to the configuration of an application channel. However, the same basic rules and structure apply, as do the commands to pull and edit a configuration, as you can see in our topic on [Updating the capability level of a channel](./updating_capabilities.html).
-
 <details>
   <summary>
-    **Click here to see the config**. Note that this is the configuration of an application channel, not the orderer system channel.
+    **Click here to see the config**
   </summary>
   ```
   {
@@ -880,8 +880,6 @@ A config might look intimidating in this form, but once you study it you’ll se
 
 For example, let's take a look at the config with a few of the tabs closed.
 
-Note that this is the configuration of an application channel, not the orderer system channel.
-
 ![Sample config simplified](./images/sample_config.png)
 
 The structure of the config should now be more obvious. You can see the config groupings: `Channel`, `Application`, and `Orderer`, and the configuration parameters related to each config grouping (we'll talk more about these in the next section), but also where the MSPs representing organizations are. Note that the `Channel` config grouping is below the `Orderer` group config values.
@@ -906,7 +904,7 @@ Governs the configuration parameters unique to application channels (for example
 
 #### `Channel/Orderer`
 
-Governs configuration parameters unique to the ordering service or the orderer system channel, requires a majority of the ordering organizations’ admins (by default there is only one ordering organization, though more can be added, for example when multiple organizations contribute nodes to the ordering service).
+Governs configuration parameters unique to the ordering service and requires a majority of the ordering organizations’ admins (by default there is only one ordering organization, though more can be added, for example when multiple organizations contribute nodes to the ordering service).
 
 * **Batch size**. These parameters dictate the number and size of transactions in a block. No block will appear larger than `absolute_max_bytes` large or with more than `max_message_count` transactions inside the block. If it is possible to construct a block under `preferred_max_bytes`, then a block will be cut prematurely, and transactions larger than this size will appear in their own block.
 
@@ -930,14 +928,6 @@ Governs configuration parameters that both the peer orgs and the ordering servic
 
 * **Hashing algorithm**. The algorithm used for computing the hash values encoded into the blocks of the blockchain. In particular, this affects the data hash, and the previous block hash fields of the block. Note, this field currently only has one valid value (`SHA256`) and should not be changed.
 
-#### System channel configuration parameters
-
-Certain configuration values are unique to the orderer system channel.
-
-* **Channel creation policy.** Defines the policy value which will be set as the mod_policy for the Application group of new channels for the consortium it is defined in. The signature set attached to the channel creation request will be checked against the instantiation of this policy in the new channel to ensure that the channel creation is authorized. Note that this config value is only set in the orderer system channel.
-
-* **Channel restrictions.** Only editable in the orderer system channel. The total number of channels the orderer is willing to allocate may be specified as `max_count`. This is primarily useful in pre-production environments with weak consortium `ChannelCreation` policies.
-
 ## Editing a config
 
 Updating a channel configuration is a three step operation that's conceptually simple:
@@ -957,7 +947,7 @@ In this topic, we'll show the process of editing a channel configuration indepen
 
 ### Set environment variables for your config update
 
-Before you attempt to use the sample commands, make sure to export the following environment variables, which will depend on the way you have structured your deployment. Note that the channel name, `CH_NAME` will have to be set for every channel being updated, as channel configuration updates only apply to the configuration of the channel being updated (with the exception of the ordering system channel, whose configuration is copied into the configuration of application channels by default).
+Before you attempt to use the sample commands, make sure to export the following environment variables, which will depend on the way you have structured your deployment. Note that the channel name, `CH_NAME` will have to be set for every channel being updated, as channel configuration updates only apply to the configuration of the channel being updated.
 
 * `CH_NAME`: the name of the channel being updated.
 * `TLS_ROOT_CA`: the path to the root CA cert of the TLS CA of the organization proposing the update.
@@ -988,7 +978,7 @@ configtxlator proto_decode --input config_block.pb --type common.Block --output
 Finally, we'll scope out all of the unnecessary metadata from the config, which makes it easier to read. You are free to call this file whatever you want, but in this example we'll call it `config.json`.
 
 ```
-jq .data.data[0].payload.data.config config_block.json > config.json
+jq ".data.data[0].payload.data.config" config_block.json > config.json
 ```
 
 Now let's make a copy of `config.json` called `modified_config.json`. **Do not edit ``config.json`` directly**, as we will be using it to compute the difference between ``config.json`` and ``modified_config.json`` in a later step.
@@ -1004,7 +994,7 @@ At this point, you have two options of how you want to modify the config.
 1. Open ``modified_config.json`` using the text editor of your choice and make edits. Online tutorials exist that describe how to copy a file from a container that does not have an editor, edit it, and add it back to the container.
 2. Use ``jq`` to apply edits to the config.
 
-Whether you choose to edit the config manually or using `jq` depends on your use case. Because `jq` is concise and scriptable (an advantage when the same configuration update will be made to multiple channels), it's the recommend method for performing a channel update. For an example on how `jq` can be used, check out [Updating channel capabilities](./updating_a_channel.html#Create-a-capabilities-config-file), which shows multiple `jq` commands leveraging a capabilities config file called `capabilities.json`. If you are updating something other than the capabilities in your channel, you will have to modify your `jq` command and JSON file accordingly.
+Whether you choose to edit the config manually or using `jq` depends on your use case. Because `jq` is concise and scriptable (an advantage when the same configuration update will be made to multiple channels), it's the recommend method for performing a channel update. For an example on how `jq` can be used, check out [Updating channel capabilities](./updating_capabilities.html#Create-a-capabilities-config-file), which shows multiple `jq` commands leveraging a capabilities config file called `capabilities.json`. If you are updating something other than the capabilities in your channel, you will have to modify your `jq` command and JSON file accordingly.
 
 For more information about the content and structure of a channel configuration, check out our [sample channel config](#Sample-channel-configuration) above.
 
@@ -1054,5 +1044,5 @@ The other option is to submit the update to every Admin on a channel and wait fo
 
 Once the config has been added to the ledger, it will be a best practice to pull it and convert it to JSON to check to make sure everything was added correctly. This will also serve as a useful copy of the latest config.
 
-<!--- Licensed under Creative Commons Attribution 4.0 International License
+<!--- Licensed under Creative Commons Attribution 4.0 Interne
 https://creativecommons.org/licenses/by/4.0/ -->
Sep 28 '23 00:09 shimos