fabric

在使用Fabric创建通道的时候，通常我们执行一条命令完成，这篇文章就解析一下执行这条命令后Fabric源码中执行的流程。 peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile $ORDERER_CA 整个流程的切入点在 fabric/peer/main.go 文件中的 main() 方法 (本文中使用的是Fabric1.4版本，不同版本中内容可能不同) 。这个方法中也定义了Peer节点可以执行的命令，有关于版本的: version.Cmd() ,关于节点状态的: node.Cmd() ，关于链码的: chaincode.Cmd(nil) ，关于客户端日志的: clilogging.Cmd(nil) ，最后一个就是关于通道的: channel.Cmd(nil) 。所以我们就从这里入手，看一下创建通道的整体流程是什么样的。 点进行后，转到了 peer/channel/channel.go 文件中第49行,其中定义了Peer节点可以执行的对通道进行操作的相关命令： func Cmd(cf *ChannelCmdFactory) *cobra.Command { AddFlags(channelCmd) #创建通道

FC SWITCH配置（HP/博科）如有错误，敬请指正 HP 默认用户名admin/password，admin权限对于配置完全足够。 只要存储或者HBA卡端口使用尾纤连接到FC交换，端口起来正常，使用switchshow命令即可查看到当前domain id以及对应物理端口连接的HBA_PORT的wwpn。 第一步：建立别名 1.根据端口建立别名：alicreate "别名"，“1，2” 别名随便起，1为该交换机的domain id，2 为 实际物理接口。 2.根据wwpn建立别名：alicreate “别名”，“50:01:43:80:05:67:01:c3” 别名参数：alicreate创建别名；aliremove从别名中删除某个映射；aliadd增加一映射个到已有的别名 alishow查看已经创建好的别名 第二步：创建zone 1.创建zone zonecreate "zone名"，“别名” zone名可以随便起，自己知道代表什么就行，别名就是刚刚上一步创建的。 zone参数：zonecreate创建zone；zoneremove删除已有zone；zoneadd增加别名到已有的zone中；zoneshow查看已创建的zone名。 第三步：创建配置文件 1.创建配置文件： cfgcreate "配置文件名"，“zone名1；zone名2；zone名3” 2.是配置文件生效

内容简介: 《Python自动化运维：技术与最佳实践》一书在中国运维领域将有“划时代”的重要意义：一方面，这是国内第一本从纵、深和实践角度探讨Python在运维领域应用的著作；一方面本书的作者是中国运维领域的“偶像级”人物，本书是他在天涯社区和腾讯近10年工作经验的结晶。因为作者实战经验丰富，所以能高屋建瓴、直指痛处，围绕Python自动化运维这个主题，不仅详细介绍了系统基础信息、服务监控、数据报表、系统安全等基础模块，而且深入讲解了自动化操作、系统管理、配置管理、集群管理及大数据应用等高级功能。最重要的是，完整重现了4个来自实际生产环境的不同功能运维平台的综合案例，展示了完整的平台架构及开发流程。 全书一共16章：基础篇（1-4章）详细介绍了系统基础信息、业务服务监控、定制业务质量报表、系统安全等基础和常用模块；高级篇（5-12章）深入讲解了批量运维管理器pexpect、paramiko、Fabric，集中化管理平台Ansible、Saltstack，统一网络控制器Func等高级功能，涵盖自动化操作、系统管理、配置管理、集群管理及大数据应用等主题；案例篇（13-16章）详细介绍了4个来自不同平台的运维案例，如何从零开始打造一个B/S自动化运维平台、如何打造Linux系统安全审计功能、如何构建分布式质量监控平台、如何构建桌面版C/S自动化运维平台，这4个案例均来自实际生产环境。

Hyperledger Fabric 1.4.6网络搭建实例(raft) 近期在帮其他部门搭建fabric测试网络，采用1.4.1的配置文件、1.4.6的核心模块，在创建通道的时候爆出了以下错误： Error: got unexpected status: BAD_REQUEST -- error validating channel creation transaction for new channel 'mychannel', could not succesfully apply update to template configuration: error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied 在网上查询的时候，很多帖子说是历史数据没有清理干净，但是我可以保证我的历史数据绝对是清理干净了。 但是，当我把 bin 目录下的核心模块换回1

BSN“官方指定区块链应用”（简称“指定应用”）的征集活动已一月有余，活动的目的是为了“把最合适的区块链应用，展示给最需要的用户”。 活动推出伊始，BSN发展联盟收到了来自众多开发者提交的优秀作品，BSN开发者委员会根据应用准入机制对作品进行了认真审核及综合考量，本次优先选出共9种分类的12个区块链应用，作为第一批入选BSN的指定应用，这批应用已经接入BSN服务网络，分别使用了Fabric或FISCO BCOS底层框架，后续接入应用随着BSN适配底层框架的增加可选择更多框架进行部署。请至BSN官网查看全部指定应用，点击官网导航菜单“发展联盟”-“BSN指定应用”，目前只支持PC端查看。 访问bsnbase.com查看指定应用 如果您对某个应用感兴趣，可以点击查看详情来了解产品的详细说明、特性、上链方式、基本报价等。如果您是企业用户，对产品的使用或购买有兴趣，可以直接通过网站公布的联系方式来与应用提供方直接沟通，BSN在此过程中不收取任何费用。 指定应用详情页 如果您对公布的指定应用有任何意见或建议，欢迎发邮件反馈给我们： developer@bsnbase.com 第一批官方指定应用名单 （排名不分先后） BSN指定应用根据服务领域共分为十五大类，开发者委员会将根据市场需求反馈对分类进行调整。目前，指定应用正在火热招募中，每个分类下的指定应用数量名额有限，当加入应用达到名额上限后

在这篇文章中，使用 fabric-samples/first-network 中的文件进行fabric网络(solo类型的网络)搭建全过程的解析。如有错误欢迎批评指正。 至于Fabric网络的搭建这里不再介绍，可以参考这一篇文章 Hyperledger Fabric环境搭建过程 fabric网络：单机，solo类型，两个组织，分别有两个节点 首先看一下该文件夹内有哪些文件： base connection-org2.json docker-compose-cli.yaml docker-compose-org3.yaml byfn.sh connection-org2.yaml docker-compose-couch-org3.yaml eyfn.sh channel-artifacts connection-org3.json docker-compose-couch.yaml org3-artifacts configtx.yaml connection-org3.yaml docker-compose-e2e-template.yaml README.md connection-org1.json crypto-config.yaml docker-compose-etcdraft2.yaml scripts connection-org1.yaml docker

作者：Umberto Manferdini 译者：TF编译组 如果你看过任何有关Tungsten Fabric（ 附注：原文为Contrail，在本系列文章中，Tungsten Fabric的功能与Contrail一致，文中出现Contrail之处均以Tungsten Fabric替换）的演示，可能都会碰到“服务链（service chain ）”这个热词。现在，是时候对这个功能好好动手研究一番了。 那么什么是服务链？简而言之，就是使流量在两个虚拟网络之间流动的过程中，经过一项或多项“服务”。 让我们举个例子吧！这里有2个虚拟网络：pippo和pluto。我们希望这两个网络互相通信。在Tungsten Fabric中，只需在两个虚拟网络上配置相同的RT（route target）即可实现（虚拟网络是vrfs，还记得吗？）。（ 附注：Route target 即RT，在Tungsten Fabric用来作为路由的标记，也是MPLS中常用的路由更新标记。 ） 还有一个选择，我们可以构建一个网络策略，同时适用于两个网络，就是“允许这些虚拟网络之间的任何流量”。而在幕后，Tungsten Fabric仍然依赖于路由route target（隐藏和自动生成目标）。 因此我们可以说，这两种方法是相同的。 这看起来是正确的，但从根本上是错误的！使用网络策略，使我们可以指定在虚拟网络之间移动时

智能合约（链码） 1、概述 链码的编写需要自定义struct，实现shim包Chaincode接口的两个方法: type Chaincode interface { Init ( stub ChaincodeStubInterface ) pb . Response Invoke ( stub ChaincodeStubInterface ) pb . Response } 链码的生命周期包括链码安装、实例化、升级等。其中链码的实例化和升级都会调用Init()方法，链码的invoke、query调用方式都只会调用Invoke()方法。 在shim包中，fabric给我们提供了ChaincodeStubInterface接口，在该接口中，我们可以使用接口中的方法实现具体的链码业务。 特别说明一句，如果链码方法最后返回的pb.Response是shim.Error()，那么所有的操作，包括数据插入、数据删除、创建复合键、发送事件、调用其他链码等都是无效的，即一次链码的调用具有事务性，如果返回shim.Success()则所有操作都成功，否则所有操作都失败。 2、接口描述 1）参数解析 直接获取所有参数 字节数组[]byte形式 /* args := stub.GetArgs() - args 所有参数的[]byte形式 */ GetArgs ( ) [ ] [ ] byte

Fabric SDK调用流程 1、文字描述 获取FabricSDK sdk , err := fabsdk . New ( config . FromFile ( sdkConfig ) ) 加入Org、User信息 rcp := sdk . Context ( fabsdk . WithOrg ( orgName ) , fabsdk . WithUser ( userName ) ) 获取指定Channel的Channel Provider ccp := sdk . ChannelContext ( channelID , fabsdk . WithUser ( userName ) ) 获取该Channel的Channel Client cc , err := channel . New ( ccp ) 封装channel.Request var req = & channel . Request { ChaincodeID : chaincodeID , Fcn fcn , Args args , TransientMap transientMap , } 封装channel.RequestOption var opts = [ ] channel . RequestOption opts = append ( opts , channel .

D:\apache-tomcat-8.0.53>docker pull alfresco/alfresco-search-services Using default tag: latest Error response from daemon: manifest for alfresco/alfresco-search-services:latest not found: manifest unknown: manifest unknown D:\apache-tomcat-8.0.53>docker pull alfresco/alfresco-search-services:1.4.2 1.4.2: Pulling from alfresco/alfresco-search-services 5ad559c5ae16: Pull complete a3847211b487: Pull complete 0af14da8955f: Pull complete 83eff5906732: Pull complete b0c9817ed91f: Pull complete aa785bca0d0f: Pull complete fc834c111e51: Pull complete b92af92df14a: Pull complete 13ca005c9406: Pull