Hyperledger Fabric first-network执行./byfn.sh -m up报BAD_REQUEST授权错误

我经常碰到开发者在Ubuntu 18.04 LTS上跑first-network时遇到这个问题——./byfn.sh -m generate成功了，但启动网络就报签名策略不满足的BAD_REQUEST错误：

2018-05-08 10:41:55.901 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized Error: got unexpected status: BAD_REQUEST -- error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: Faile...

这个问题核心是通道配置更新时，签名数量没达到预设的策略要求，大概率是旧环境残留或者配置/证书生成出了问题，下面是几个实测有效的解决步骤：

• 彻底清理旧网络残留
  之前运行过的容器、临时镜像或者生成的配置文件很可能干扰新部署。先执行这套清理命令，把所有相关资源清干净：

  ./byfn.sh -m down
  docker rm -f $(docker ps -aq)
  docker rmi -f $(docker images | grep dev-peer | awk '{print $3}')
  rm -rf crypto-config/ channel-artifacts/
  

  这会移除旧网络容器、peer节点的开发镜像，以及之前生成的证书和通道配置文件，确保从完全干净的状态开始。

• 重新生成配置与证书
  清理完成后，重新执行生成命令：

  ./byfn.sh -m generate
  

  注意观察生成过程的输出，如果有证书生成失败的提示，可能需要检查你的openssl版本（Ubuntu 18.04默认的openssl版本一般没问题，但如果是自定义安装的可能有兼容问题），或者确认你拉取的Fabric镜像版本和first-network脚本要求一致。

• 验证Fabric镜像版本一致性
  镜像版本不匹配是很多奇怪错误的根源。用docker images查看本地的Fabric镜像（比如fabric-orderer、fabric-peer、fabric-tools等），确保它们的版本和first-network脚本里指定的版本完全一致。如果版本不对，重新拉取对应版本的镜像：

  curl -sSL https://bit.ly/2ysbOFE | bash -s -- 1.4.9
  

  把1.4.9换成你教程里指定的版本号即可。

• 调整通道配置的签名策略（备选方案）
  如果上面的步骤都没解决，可能是通道配置里的签名策略要求太严格。打开channel-artifacts/configtx.yaml，找到Application下的Policies部分：

  Policies:
      Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
      Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
      Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
  

  比如如果你的网络是两个组织，MAJORITY Admins要求至少一个组织签名，但如果脚本里的签名逻辑有问题，你可以暂时把Admins的Rule改成ANY Admins，然后重新生成配置再启动网络，看是否能解决。

内容的提问来源于stack exchange，提问作者Prakash P