Running composer-rest-server on a different port? - hyperledger-composer

By default it is starting on 3000 which is being used by another process.
Is there a way to make it run on a different port?
~/git/my-test-network$ composer-rest-server -p hlfv1 -n my-test-network -i admin -s adminpw -N never
Discovering types from business network definition ...
Discovered types from business network definition
Generating schemas for all types in business network definition ...
Generated schemas for all types in business network definition
Adding schemas for all types to Loopback ...
Added schemas for all types to Loopback
events.js:160
throw er; // Unhandled 'error' event
^
Error: listen EADDRINUSE 0.0.0.0:3000
at Object.exports._errnoException (util.js:1018:11)
at exports._exceptionWithHostPort (util.js:1041:20)
at Server._listen2 (net.js:1258:14)
at listen (net.js:1294:10)
at net.js:1404:9
at _combinedTickCallback (internal/process/next_tick.js:83:11)
at process._tickCallback (internal/process/next_tick.js:104:9)

Use the -P flag.
daniels-mbp-2:composer-common dselman$ composer-rest-server --help
Usage: composer-rest-server [options]
Options:
-p, --connectionProfileName The connection profile name [string]
-n, --businessNetworkName The business network identifier [string]
-i, --enrollId The enrollment ID of the user [string]
-s, --enrollSecret The enrollment secret of the user [string]
-N, --namespaces Use namespaces if conflicting types exist [string] [choices: "always", "required", "never"] [default: "always"]
-P, --port The port to serve the REST API on [number]
-S, --security Enable security for the REST API [boolean] [default: false]
-h, --help Show help [boolean]
-v, --version Show version number [boolean]

Following command will work on latest version 0.20^
composer-rest-server -c admin#mynetwork -n never -w true -p 3001

From version 0.20 the port flag is -p (lower case)

Related

composer-rest-server Error: throw er; // Unhandled 'error' event

I installed and startet my business network. Now I want to do composer-rest-server -c admin#test-network but I get the following output:
Discovering types from business network definition ...
Discovering the Returning Transactions..
Discovered types from business network definition
Generating schemas for all types in business network definition ...
Generated schemas for all types in business network definition
Adding schemas for all types to Loopback ...
Added schemas for all types to Loopback
events.js:183
throw er; // Unhandled 'error' event
^
Error: listen EADDRINUSE :::3000
at Server.setupListenHandle [as _listen2] (net.js:1360:14)
at listenInCluster (net.js:1401:12)
at Server.listen (net.js:1485:7)
at module.exports.promise.then.then (/home/dany/.nvm/versions/node/v8.15.0/lib/node_modules/composer-rest-server/cli.js:143:19)
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:189:7)
The funny thing is, that everything worked fine before. Then I restarted the fabric and reinstalled the bna file and now I get this error. Thanks for your help
It seems you have not stopped your script properly that's why this error is coming. This error comes when your port is already occupied and you are trying to start something on same port. So you can kill process on this port then it should work fine.
If you are using linux OS then this command might help you.
fuser -n tcp -k 3000

Error starting hyperledger-composer network after Fabric and Composer version upgrade

I've come across an error starting the hyperledger-composer network that isn't answered in the composer-wiki.
✖ Starting business network definition. This may take a minute...
Error: Error trying to start business network. Error: No valid responses from any peers.
Response from attempted peer comms was an error: Error: transaction returned with failure: can't find PEM header: undefined
Command failed
Checking pre-requisites,
Fabric 1.2
Composer 0.20.4
Node 8.12.0
Docker 18.01.1
"composer network install" was successful, with file appearing in the docker peer at /var/hyperleder/production/chaincodes
After running the "composer network start" command, a "docker ps" shows new docker instance with name:
dev-peer0.org1.example.com-<<business-network-name>>-0.0.7
But any attempt to ping this results in a failure like this:
Error: Error trying to ping. Error: make sure the chaincode <<business-network-name>> has been successfully instantiated and try again: getccdata composerchannel/<<business-network-name>> responded with error: could not find chaincode with name '<<business-network-name>>'
Checking the log of the dev-peer0, it ends with the following:
2018-11-05T05:03:18.227Z [4264161f] ERROR :Composer :Init() can't find PEM header: undefined
2018-11-05T05:03:18.227Z [4264161f] VERBOSE :Composer :#PERF Init() Total (ms) duration for txnID [4264161fc30a61c70884d4c7efb460fea6a755d07bc4852875c393346795227a]: 929.00
2018-11-05T05:03:18.228Z ERROR [lib/handler.js] [composerchannel-4264161f]Calling chaincode Init() returned error response [can't find PEM header: undefined]. Sending ERROR message back to peer
The corresponding error in the peer0 log is a big larger:
2018-11-05 05:03:18.229 UTC [endorser] SimulateProposal -> ERRO 439d [composerchannel][4264161f] failed to invoke chaincode name:"lscc" , error: transaction returned with failure: can't find PEM header: undefined
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:202
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:131
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:173
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
2018-11-05 05:03:18.229 UTC [endorser] SimulateProposal -> DEBU 439e [composerchannel][4264161f] Exit
Since this last worked I have updated composer from 0.19 to 0.20.4, and taken Fabric from 1.1 to 1.2.
Googling suggests that this kind of error "can't find PEM header: undefined" is associated with a change in key signing. After tearing down Fabric I re-ran ./createPeerAdminCard.sh - is there another card or similar that needs to be re-created to accomodate the latest versions?
Thanks to #R Thatcher for putting me onto the right direction. This was all down to mismatching cards, and was resolved by clearing out everything and starting again.
Specifically, in /fabric-dev-servers:
./stopFabric.sh
./teardownFabric.sh
composer card list
composer card delete -c admin#<business-network-name>
composer card delete -c PeerAdmin#hlfv1
./startFabric.sh
./createPeerAdminCard.sh
Then changing into the composer/business-network-name directory:
composer network install --card PeerAdmin#hlfv1 --archiveFile business-network-name\#0.0.7.bna
composer network start -c PeerAdmin#hlfv1 -n business-network-name -V 0.0.7 -A admin -S adminpw --file networkadmin.card
composer card import --file networkadmin.card --card admin#business-network-name
composer network ping -c admin#business-network-name
So yes, it was about mismatching cards and not cleaning these up as part of a new deployment.
Although not part of the original problem, it's also worth noting that the -A and -S parameters of the composer network start command HAD to be set to admin and adminpw respectively. See composer issue #3781.
Answering the the last remark from #Capn Sparrow
"the -A and -S parameters of the composer network start command HAD to be set to admin and adminpw respectively."
This is the correct and expected behaviour :-)
with the composer network start command the -A and -S are specifying an existing user in the CA that we want a new set of Credentials (certificate and keys) for which is then bound to a Composer System participant.
When you use the 'standard development fabric' this has a CA configured with a user called 'admin' with a secret of 'adminpw'. If you had build your own Fabric from scratch you could choose the name and secret of your first default user. Alternatively you could work with the fabric-ca client software to create additional users in the CA.

Postgraphile - "Query Root must be provided" error message

We have an existing postgresql database with data and we are experimenting with postgraphile as a graphql API. We are running into an error that is leaving us scratching our head. the server runs fine but we get the following:
postgraphile -c postgres://username:password#localhost:5432/my_db
PostGraphile server listening on port 5000
‣ Connected to Postgres instance postgres://localhost:5432/my_db
‣ Introspected Postgres schema(s) public
‣ GraphQL endpoint served at http://localhost:5000/graphql
‣ GraphiQL endpoint served at http://localhost:5000/graphiql
* * *
An error occurred, it might be okay but it doesn't look like the error we were expecting... run with envvar 'DEBUG="graphile-build:warn"' to view the error
An error occurred, it might be okay but it doesn't look like the error we were expecting... run with envvar 'DEBUG="graphile-build:warn"' to view the error
Error: Query root type must be provided.
at assertValidSchema (C:\Users\user\AppData\Roaming\npm\node_modules\postgraphile\node_modules\graphql\type\validate.js:78:11)
at Object.validate (C:\Users\user\AppData\Roaming\npm\node_modules\postgraphile\node_modules\graphql\validation\validate.js:61:35)
at parseQuery (C:\Users\user\AppData\Roaming\npm\node_modules\postgraphile\build\postgraphile\http\createPostGraphileHttpRequestHandler.js:208:48)
at Promise.all.paramsList.map (C:\Users\user\AppData\Roaming\npm\node_modules\postgraphile\build\postgraphile\http\createPostGraphileHttpRequestHandler.js:469:63)
at Array.map (<anonymous>)
at requestHandler (C:\Users\user\AppData\Roaming\npm\node_modules\postgraphile\build\postgraphile\http\createPostGraphileHttpRequestHandler.js:435:52)
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:188:7)
and when we navigate to localhost:500/graphiql we see a a "no schema available" in the documentation explorer.
is the query root the publicschema? or what are we missing?
Newer versions of PostGraphile have much more helpful error messages, often including a suggested solution. The "An error occurred" errors like those above now also contain a preview of the underlying error which helps with diagnosis.
There are instructions here on how to set the DEBUG environmental variable here: https://www.graphile.org/postgraphile/debugging/#debug-envvars
Here's how you might do it in Linux, macOS or Windows:
# Bash (Linux, macOS, etc)
export DEBUG="graphile-build:warn" postgraphile -c postgres://username:password#localhost:5432/my_db
# Windows Console
set DEBUG=graphile-build:warn & postgraphile -c postgres://username:password#localhost:5432/my_db
# Windows PowerShell
$env:DEBUG = "graphile-build:warn"; postgraphile -c postgres://username:password#localhost:5432/my_db

Unable to instantiate chaincode on peer, connection reset by peer

I am trying to get started with Hyperledger Fabric. I managed to run the "build your first network"-tutorial from the samples, and I followed the "write your first application"-tutorial as well, which also worked.
As a next step, I wanted to create my own network more or less from scratch, by adjusting the .yaml files from the samples and running cryptogen and configtxgen manually. I managed to build a network with three organisations, two peers per org and a solo ordering service. I now want to install some basic chaincode on one of the peers, but I'm stuck, as I get a couple of weird errors:
2018-03-01 22:27:30.525 UTC [grpc] Printf -> DEBU 003 transport: http2Client.notifyError got notified that the client transport was broken read tcp 172.20.0.9:45178->172.20.0.3:7050: read: connection reset by peer.
Error: Error getting broadcast client: Error connecting to orderer.rle.de:7050 due to rpc error: code = Internal desc = transport: write tcp 172.20.0.9:45178->172.20.0.3:7050: write: broken pipe
2018-03-01 22:27:30.525 UTC [grpc] Printf -> DEBU 004 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp: lookup orderer.rle.de on 127.0.0.11:53: dial udp 127.0.0.11:53: operation was canceled"; Reconnecting to {orderer.rle.de:7050 <nil>}
2018-03-01 22:27:30.525 UTC [grpc] Printf -> DEBU 005 grpc: addrConn.transportMonitor exits due to: grpc: the connection is closing
After that, I get the usage information for peer chaincode instantiate
If you could provide any insight into what might be causing this error, I would be super grateful. I don't even know if it is caused by the network config or by the chaincode itself (I don't think so, since I tried two different chaincodes, one of which was "sacc" from the samples) but the installation of the chaincode seems to be working. My problem is that I have no idea what I'm doing, so after googling and fooling around with the arguments for peer chaincode instantiate, I'm all out of ideas.
My command (I run it from a .sh file) is:
peer chaincode instantiate -o orderer.rle.de:7050 -C driverlogschannel -n test -v 1.0 -c '{"Args":["John","0"]}' -P "OR ('rleMSP.member')"
The chaincode is taken from the sacc example installed via
peer chaincode install -n test -v 1.0 -p sacc
Thanks a lot! If you need more logs or other info, I can provide them.
Solved it. The problem had to do with the fact that I was not submitting a cafile. Basically, what I did is going back to this tutorial and trying it with their chaincode again:
peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
but I adjusted it to
peer chaincode install -n mycc -v 1.0 -p chaincode_example02
(I put the chaincode_example02.go file from fabric-samples/chaincode/ into my $GOPATH/src/chaincode_example02 folder and adjusted my docker-compose-cli.yaml by adding this line to cli -->volumes)
- $GOPATH/src/chaincode_example02:/opt/gopath/src/chaincode_example02
Then, the crucial point:
peer chaincode instantiate -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.member','Org2MSP.member')"
although I adjusted this line again so that it matched my folder structure (exchanging example.com for my domain and so on.)
That solved the issue.

Hyperledger Composer:: Error: The current identity must be activated (ACTIVATION_REQUIRED)

Any one came across hyperledger composer's chaincode error like : Error: The current identity must be activated (ACTIVATION_REQUIRED)?? The identity which I am using showing ISSUED in composer-playground. But once I am using System/ping through REST server, chaincode log showing this error. I hope at the time when a participant submits a transaction using an enrollment certificate, the Composer chaincode extracts the enrollment ID from the enrollment certificate, and uses it to look up the participant instance that the identity was issued to. I issued identity through CLI and then I am using it in REST server without doing anything in CLI. I am not sure how to overcome this error. Appreciate! any help.
I updated all composer components to 0.12.2. I used the following CLI commands to issue identity:
composer participant add -p jiyababa -n 'digitalproperty-network' -i PeerAdmin -s adminpw -d '{"$class":"net.biz.digitalPropertyNetwork.Person","personId":"dcsen#abc.com","firstName":"Dul","lastName":"Sen"}'
composer identity issue -p jiyababa -n 'digitalproperty-network' -i admin -s adminpw -u dcsen1 -a "resource:net.biz.digitalPropertyNetwork.Person#dcsen#abc.com"
Still getting the same error at composer chaincode.
2017-09-17 14:56:12.599 UTC [Composer] Error -> ERRO 01e #JS : IdentityManager :getIdentity() Error: The current identity has not been registered:admin 2017-09-17 14:56:12.682 UTC [Composer] Error -> ERRO 01f #JS : IdentityManager :getIdentity() Error: The current identity has not been registered:admin 2017-09-17 15:09:58.641 UTC [Composer] Error -> ERRO 020 #JS : IdentityManager :validateIdentity() Error: The current identity must be activated (ACTIVATION_REQUIRED)
I also tried using "admin" user to add participant and issue identity but no luck: getting composer chaincode error::
Error: Unhandled promise rejection {activationRequired:true} at [anon] (/chaincode/input/src/composer/vendor/gopkg.in/olebedev/go-duktape.v3/duk_console.c:55) internal
#JS : IdentityManager :validateIdentity() Error: The current identity must be activated (ACTIVATION_REQUIRED)
But I can ACTIVATE the identity through composer CLI using the following command:
composer network ping -n digitalproperty-network -p jiyababa -i dcsen1 -s BEkeKFlLVnBL
Once I ACTIVATED through CLI, I could NOT use the identity in REST Server. That means, first transaction request from REST server not activating the identity in identity registry.
This can happen if you are using an old version of the CLI/Client Application/Rest Server trying to connect to a much newer version of the composer runtime that is deployed when you deploy the business network.
It sounds like you deployed a business network and issued identities using a newver version of the CLI, but haven't updated the Rest Server to the same version.
Information about updating can be found at
https://hyperledger.github.io/composer/managing/updating-composer.html
A temporary work around is to ACTIVATE the card yourself:
$ composer identity list -c admin#basic-sample-network
✔ List all identities in the business network
-
$class: org.hyperledger.composer.system.Identity
identityId: 8dc315997a5ad0ade3b4343c6b81ae37a3c2c7f22eddab90dd09717e7459772e
name: admin
issuer: ac3dbcbe135ba48b29f97665bb103f8260c38d3872473e584314392797c595f3
certificate:
"""
-----BEGIN CERTIFICATE-----
MIICAjCCAaigAwIBAgIUOA7RAw1TbKo2UjwkeS9YRCSFupowCgYIKoZIzj0EAwIw
czELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNh
biBGcmFuY2lzY28xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHDAaBgNVBAMT
E2NhLm9yZzEuZXhhbXBsZS5jb20wHhcNMTgwODA4MDYzODAwWhcNMTkwODA4MDY0
MzAwWjAhMQ8wDQYDVQQLEwZjbGllbnQxDjAMBgNVBAMTBWFkbWluMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAEeBeSqbzishSi0Q0+f0HavwPsN1240zIxuL12iWUR
U9aEO/cLusEr9fg44UUh3xzp4VQGChJ5TNRu4s/uBbuFxqNsMGowDgYDVR0PAQH/
BAQDAgeAMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFF1ZYXNpBsGXEomhlTBT9NeJ
CUqIMCsGA1UdIwQkMCKAIBmrZau7BIB9rRLkwKmqpmSecIaOOr0CF6Mi2J5H4aau
MAoGCCqGSM49BAMCA0gAMEUCIQCMuttwm6sSCjtwl8xk4FZM4PHH0F5YGxJvNUjn
SeeCCQIgAmmD9aabcY7jHttdfAZ2zNepihdRKjN1xsxy4i7KaQ4=
-----END CERTIFICATE-----
"""
state: ACTIVATED
participant: resource:org.hyperledger.composer.system.NetworkAdmin#admin
Command succeeded

Resources