1. 25 Apr, 2017 1 commit
  2. 24 Apr, 2017 7 commits
    • Greg Haskins's avatar
      Merge "FAB-3153 Whitespace fixes (docs)" · 7f114bba
      Greg Haskins authored
    • Yacov Manevich's avatar
    • Greg Haskins's avatar
      Merge "[FAB-2537] Fix configtxgen doc" · 0e0deacd
      Greg Haskins authored
    • Christopher Ferris's avatar
    • Kostas Christidis's avatar
      [FAB-3287] Fix debug statements in orderer package · 1dfd0aa4
      Kostas Christidis authored
      Change-Id: If8fd43e256bfcf6a8d3f21a3262707ccc5e3c134
      Signed-off-by: default avatarKostas Christidis <kostas@christidis.io>
    • Gregory Haskins's avatar
      [FAB-3160] Provide config-relative path feature · 8ce10737
      Gregory Haskins authored
      The primary goal of this patch is to create the notion of a
      "config-relative" path reference.  For example, a configuration file
      "/etc/foo/bar.yaml" that contains a key "bat" with a value
      "baz/blaz/blamo" can be used to specify that "baz/blaz/blamo" should
      be considered relative to the configuration file itself.  In this case,
      it would be expected to be found at /etc/foo/baz/blaz/blamo.  FAB-2037
      does a much more thorough job of explaining the rationale on why
      config-relative is considered important/good-form.
      This is in stark contrast to what we have today, which is a jumbled
      mess of assumed GOPATH relative, CWD relative, ENVVAR absolute and
      sometimes even ENVVAR relative.  Therefore, an additional positive
      side-effect of this endeavor is that this patch also substantially
      cleans up some technical debt that had been accumulating in the tree
      for some time related to ad-hoc pathing, DRY violations, and just
      general inconsistencies in how configuration files were managed.
      Design Details
      This patch refactors the basic configuration system into the notion of
      a tree rooted at a configuration-path.  By default, this path is
      $GOROOT/..../fabric/sampleconfig during dev/test and
      /etc/hyperledger/fabric during runtime.  The root may be overridden
      at any time by specifying the environment variable FABRIC_CFG_PATH.
      (Note that this variable unifies and replaces the former PEER_CFG_PATH
      and ORDERER_CFG_PATH).
      The dev/test environment will operate out of the ./fabric/sampleconfig
      configuration root.  The build-system will package that root into
      /etc/hyperledger/fabric in the runtime context with the intention of
      the end-user/admin/deployer replacing parts or all of the sampleconfig
      to suit their application.
      Since configuration-relative paths are now possible, the configuration
      files may reference other relative files and they will behave
      appropriately regardless of the context in which they are executed.
      For example, consider the files ./sampleconfig/tls/server.[crt|key].
      A configuration file may contain a key "tls/server.key" and the system
      will properly resolve this relative file even at runtime. This is (IMO)
      far more natural than assuming a path is relative to the CWD of where
      the command is executed, which is how most of the system behaves today
      (or requires awkward and very specific ENVVAR overrides).
      This will be conducive to something like a package-installer
      (e.g. RPM/DEB) or a docker environment to augment/replace elements
      of the configuration root and to freely move the configuration around
      as the package/deployer sees fit.
      As an example, a deployment on Kubernetes might opt to volume mount
      /etc/hyperledger/fabric to replace the entire config, or it might just use
      a secrets mount on /etc/hyperledger/fabric/peer/tls.  An RPM packager
      might opt to install the configuration files in the default
      /etc/hyperledger/fabric, whereas an unprivledged user might install them
      in ~/hyperledger.  The point is, it shouldn't matter where they are and the
      user shouldn't need a PhD in CORE_* variables to get it to work.
      This is part of an overall effort to improve the user-experience as we
      march towards a v1.0 release.
      Fixes FAB-3169 as part of FAB-2037
      Change-Id: I5f47f554c2f956ec2e1afebd9bd82b0bbb62892a
      Signed-off-by: default avatarGreg Haskins <gregory.haskins@gmail.com>
    • Jim Zhang's avatar
      Merge "[FAB-3245] Use crypto rand in gossip" · 6ab17992
      Jim Zhang authored
  3. 23 Apr, 2017 19 commits
  4. 22 Apr, 2017 13 commits
    • YACOVM's avatar
      [FAB-2963] Gossip inter-org confidentiality - P4 · 43bcc9a3
      YACOVM authored
      In gossip, AliveMessages of peers that have no external endpoints
      are only gossiped among peers of the same organization.
      However, no such restriction exists for StateInfo messages and for
      Identities. Therefore- foreign organizations know of peers
      that they can't communicate with, and that the organization had no
      intention of exposing.
      This commit addresses this by filtering out StateInfo messages
      of peers without external endpoints when gossiping to peers of foreign
      organizations, and the same for identity messages.
      Change-Id: Idf7953b9fa5efd1415ac294ff63e7ea321762a3f
      Signed-off-by: default avatarYacov Manevich <yacovm@il.ibm.com>
    • YACOVM's avatar
      [FAB-2061] Gossip inter-org confidentiality - P3 · 9d042696
      YACOVM authored
      In the previous commit, I extended the pull mechanism to support
      filtering based on the remote peer.
      The goal was to ensure that peers only gossip identities of either
      their own organization, or of organizations they are gossiping with.
      (Meaning- if A gossips with B identities, the identities that are sent
      are either identities of A or of B).
      In this commit I hook a filter to the constructor of the identity puller
      that extracts the organization of the remote peer, and based on the
      organization of the digest (which is the PKI-ID of the identity),
      the filter ensures the confidentiality explained above.
      I also extended the test of the first commit in the series, to inspect
      identities that travel between organizations, to make sure
      that the confidentiality rules are preserved.
      I also did the following test, to make sure that state transfer between
      peers still works:
      network_setup.sh: Overided the docker-compose file with docker-compose-no-tls
      peer-base/peer-base-no-tls.yaml: I made both options:
            - CORE_PEER_GOSSIP_ORGLEADER=false
      And in docker-compose-no-tls.yaml I made ONLY peer0 to be ORGLEADER-true
      Then I ran network_setup.sh up and it passed, so this proves that
      peer2 and peer3 got their blocks from peer0 (or peer1).
      Change-Id: Ied4979dd5cfc24ef7b0d1bc092653e9f037a64f2
      Signed-off-by: default avatarYacov Manevich <yacovm@il.ibm.com>
    • Christopher Ferris's avatar
    • manish's avatar
      [FAB-3270] Cleanup a TODO in Ledger queryHelper done() · 8638813c
      manish authored
      In this cleanup done() exits on first error
      and closes all the open iterators in a defer function
      Change-Id: Ifdc0771f13efc0d5b968429a2f207bf0fdf2ad54
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
    • Gari Singh's avatar
    • Gari Singh's avatar
    • Gari Singh's avatar
    • Yacov Manevich's avatar
    • Christopher Ferris's avatar
    • YACOVM's avatar
      [FAB-3335] Gossip pull may send zero-length digests · 9b5c1800
      YACOVM authored
      The bug was introduced in a recent commit that added filtering capability.
      Basically when the gossip puller gets a hello from a peer,
      it iterates over the items it has, and applies a filter on each of them.
      If the filter doesn't permit, it skips to the next iteration,
      but the returned slice then contains an "empty-string"
      digest in the response to the remote peer.
      While this isn't dangerous, this causes un-necessary messages
      to be sent so this should be fixed.
      Also added an optimization that if there are no digests/items to send,
      we don't return any response to the sender.
      Change-Id: Ic455413dc9e040ea98ef3bb0ee3531f2c6cfc32c
      Signed-off-by: default avatarYacov Manevich <yacovm@il.ibm.com>
    • Gari Singh's avatar
      Merge changes I9205e007,I772424dd · 16efdea5
      Gari Singh authored
      * changes:
        [FAB-3342] fix vagrant up on Windows
        [FAB-3340] fix broken link to contributing doc
    • Gari Singh's avatar
    • Arnaud J Le Hors's avatar
      [FAB-3342] fix vagrant up on Windows · e2401b08
      Arnaud J Le Hors authored
      Fix [FAB-3342] by specifying the host ip in config.wm.network commands.
      Here is the trace of the launch after applying this fix:
      $ vagrant up
      Bringing machine 'default' up with 'virtualbox' provider...
      ==> default: Checking if box 'hyperledger/fabric-baseimage' is up to date...
      ==> default: Clearing any previously set network interfaces...
      ==> default: Preparing network interfaces based on configuration...
          default: Adapter 1: nat
      ==> default: Forwarding ports...
          default: 7050 (guest) => 7050 (host) (adapter 1)
          default: 7051 (guest) => 7051 (host) (adapter 1)
          default: 7053 (guest) => 7053 (host) (adapter 1)
          default: 7054 (guest) => 7054 (host) (adapter 1)
          default: 5984 (guest) => 15984 (host) (adapter 1)
          default: 22 (guest) => 2222 (host) (adapter 1)
      ==> default: Running 'pre-boot' VM customizations...
      ==> default: Booting VM...
      ==> default: Waiting for machine to boot. This may take a few minutes...
          default: SSH address:
          default: SSH username: vagrant
          default: SSH auth method: private key
      ==> default: Machine booted and ready!
      ==> default: Checking for guest additions in VM...
          default: The guest additions on this VM do not match the installed version of
          default: VirtualBox! In most cases this is fine, but in rare cases it can
          default: prevent things such as shared folders from working properly. If you see
          default: shared folder errors, please make sure the guest additions within the
          default: virtual machine match the version of VirtualBox you have installed on
          default: your host and reload your VM.
          default: Guest Additions Version: 5.0.24
          default: VirtualBox Version: 5.1
      ==> default: Mounting shared folders...
          default: /vagrant => C:/Users/lehors/Documents/Projects/Go/src/github.com/hyperledger/fabric/devenv
          default: /local-dev => C:/Users/lehors/Documents/Projects/Go/src/github.com/hyperledger/fabric
          default: /hyperledger => C:/Users/lehors/Documents/Projects/Go/src/github.com/hyperledger/fabric
          default: /opt/gopath/src/github.com/hyperledger/fabric => C:/Users/lehors/Documents/Projects/Go/src/github.com/hyperledger/fabric
          default: /opt/gopath/src/github.com/hyperledger/fabric-ca => C:/Users/lehors/Documents/Projects/Go/src/github.com/hyperledger/fabric-ca
      ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
      ==> default: flag to force provisioning. Provisioners marked to run always will still run.
      Change-Id: I9205e00725e7a00d40bf731f5fc645df3061e778
      Signed-off-by: default avatarArnaud J Le Hors <lehors@us.ibm.com>