|
Re: Getting error when invoke external chaincode
Kavin Arumugam
Hi Kumari, I have tried the tutorial in the following link which was working out-of-the-box. (Used Fabric v2.2.5) Thanks & Regards Kavin Arumugam LinkedIn: @karthikkavina On Thu, Feb 17, 2022 at 10:13 PM Matthew White <whitemat@...> wrote:
|
||||
|
|
||||
|
Re: Getting error when invoke external chaincode
Matthew White
Hello;
The external chaincode – and specifically the external chaincode-as-a-service is a very valuable feature, and makes deployment into a cloud environment so much easier.
The latest Peer packaging, includes a pre-packaged core.yaml that points to a set of pre-packaged external builders. I would strongly suggest to look at the `deployCCAAS.sh` script – and specifically read this tutorial here https://github.com/hyperledger/fabric-samples/blob/main/test-network/CHAINCODE_AS_A_SERVICE_TUTORIAL.md
(aside we do need to move that into the docs).
Thanks Matthew
From: fabric@... <fabric@lists
From: fabric@... <fabric@...>
On Behalf Of Kumari Shweta via lists.hyperledger.org
Hi Team, I am implementing external chaincode service using sample chaincode (asset-transfer-basic/chaincode-external). I have hlf 2.2 multi host setup. step1: tar czf code.tar.gz connection.json tar czf asset-transfer-basic.tar.gz metadata.json ZjQcmQRYFpfptBannerStart
ZjQcmQRYFpfptBannerEnd |
||||
|
|
||||
|
Re: External chaincode implementation
Matthew White
Hello;
The external chaincode – and specifically the external chaincode-as-a-service is a very valuable feature, and makes deployment into a cloud environment so much easier.
The latest Peer packaging, includes a pre-packaged core.yaml that points to a set of pre-packaged external builders. I would strongly suggest to look at the `deployCCAAS.sh` script – and specifically read this tutorial here https://github.com/hyperledger/fabric-samples/blob/main/test-network/CHAINCODE_AS_A_SERVICE_TUTORIAL.md
(aside we do need to move that into the docs).
Thanks Matthew
From: fabric@... <fabric@...>
On Behalf Of jeff.jo95z@...
hello, I was trying to implement an external chaincode.But got the following errors. Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: dock er build failed: ZjQcmQRYFpfptBannerStart
ZjQcmQRYFpfptBannerEnd Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: dock er build failed: platform builder failed: Failed to generate a Dockerfile: Unknown chaincodeType: EXTERNAL |
||||
|
|
||||
|
Event: Documentation Workgroup monthly call - 02/18/2022
#cal-reminder
fabric@lists.hyperledger.org Calendar <noreply@...>
Reminder: Documentation Workgroup monthly call When: Where: Organizer: Josh Horton joshh@... Description: |
||||
|
|
||||
|
Re: how core peer address works
jkneubuh@...
Hi Nikos,
Gateway applications can run either locally on the host OS or within the K8s as a container. In development cycles you can build/edit/test your application locally (e.g. in a debugger) on the host OS, and then over time migrate your application to run within Kubernetes as a container. Both cases are supported, and encouraged! When running a gateway application "locally" you will need to either open a port forward to the target Gateway peer Service, or set up an Ingress to tunnel over the Nginx controller into the peers. When running within Kubernetes, the application can reach the gateway peers via the Kube internal network. Depending on your preference both the port forward and Ingress routes work really well. We haven't done a good job of documenting this, but our team frequently uses the *.vcap.me and *.<ip-address-with-dash>.nip.io DNS wildcard aliases to access the nginx ingress controller for access into the test network. For instance, you can add the host alias "my-gateway-service.vcap.me" to the peer Certificate requests (see the SAN sections in the kube/../orgX-peerY.yaml), then set up a k8s Ingress to route traffic to the Gateway peer Service. When you open a TCP connection from your host OS, you can open a connection to grpcs://my-gateway-service.vcap.me, which in turn resolves to 127.0.0.1 and routes through the Ingress. This is too "fiddly" for inclusion in the CI test suite, so on that path we use a temporary port forward and accesse the gateways via a localhost URL. Once in production (or at least in a container), your application can be set up via Deployment and then reference the gateway service directly within Kubernetes. E.g. grpcs://my-gateway-service. Regarding the shell scripting and administration, I agree that the preferred approach is to set up the network without any scripting. For kube test network we tried to keep this as simple as possible, and map to the existing patterns based on the Docker Compose test network. If you are looking for a more "production-ready" deployment for working with Fabric, it is highly recommended to use a software-based approach such as the Fabric Operations Console, Hyperledger Ansible Playbooks, Blockchain Automation Framework, IBM Hyperledger Support, etc. to reduce complexity for your network installation and administration tasks. -josh |
||||
|
|
||||
|
Expired certificates and orderers not running using handshake time shift
#fabric-questions
#hyperledger-fabric
#tls
#signcerts
afrancoc2000@...
Hy everyone,
I'm having a problem with expired certificates, I'm running a cluster with several channels and I updated the certificates on time for most of them, but I forgot about a channel that was created and used only during the first initialization of the cluster. So today in my test environment the orderers got restarted and now they don't start, my production environment has the same problem but as they haven't been restarted they are running as if nothing has changed, for now.
So, I did as it is said, in this issue and changed these environment variables:
- ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS: "true"
- ORDERER_GENERAL_CLUSTER_TLSHANDSHAKETIMESHIFT: 96h - ORDERER_GENERAL_TLS_TLSHANDSHAKETIMESHIFT: 96h - ORDERER_OPERATIONS_TLS_TLSHANDSHAKETIMESHIFT: 96h - ORDERER_ADMIN_TLS_TLSHANDSHAKETIMESHIFT: 96h The only handshake time shift still missing is the one from kafta that I don't use, I'm using Raft, but still, I'm getting this error trying to run the orderers:
PANI 00d Error creating ledger resources: error creating channelconfig bundle: initializing channelconfig failed: could not create channel Orderer sub-group config: setting up the MSP manager failed: CA Certificate is not valid, (SN: 512917139581241201287378615618194486727802882): could not obtain certification chain: the supplied identity is not valid: x509: certificate has expired or is not yet valid: current time 2022-02-17T14:28:20Z is after 2022-02-16T16:41:01Z
I didn't change the public keys of any of the certificates, just created new ones with a new expiration date, and I have already updated them in the msp folders, the thing was that my ICA certificate was also updated, but the old one in the channel configuration is still valid, the ones that expired are not any of the CA ones.
Things were working yesterday even restarted the environment a couple of times so a time shift of 96 hours should work, I'm not sure what else to change.
What else can I change to be able to update the channel configuration and at least be able to run my orderers? Thank you very much Ana Maria Franco Tech Leader Ceiba Software |
||||
|
|
||||
|
Re: how core peer address works
Nikos Karamolegkos
About k8s where the typescript application runs? I had the impression that is running inside the k8s cluster. Am I wrong? Is it running locally?
In general, I prefer to use the Gateway client to connect to the fabric network however I have understand that the client application are used for query and updating the ledger. So my question was 1) how to setup the entire network without using any bash script (which is the ideal occasion) 2) how to manage the network (add new channels, and installing/updating chaincodes) after creating it (even if the deployment has take place using bash) |
||||
|
|
||||
|
Re: Hyperledger Fabric Gateway fails with certificate signed by unknown authority but certificates pass an openssl test
#hyperledger-fabric
#tls
#fabric-sdk-go
afrancoc2000@...
So the issue was resolved with the help of the Hyperledger team here
Thank you, all |
||||
|
|
||||
|
External chaincode implementation
jeff.jo95z@...
hello,
I was trying to implement an external chaincode.But got the following errors. Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: dock
er build failed: platform builder failed: Failed to generate a Dockerfile: Unknown chaincodeType: EXTERNAL
Adding core.yaml and docker-compose file along with this I have executed chmod 777 -R bin/ on building scripts |
||||
|
|
||||
|
Getting error when invoke external chaincode
Kumari Shweta
Hi Team,
I am implementing external chaincode service using sample chaincode (asset-transfer-basic/chaincode-external). I have hlf 2.2 multi host setup. step1: tar czf code.tar.gz connection.json tar czf asset-transfer-basic.tar.gz metadata.json code.tar.gz cp chaincode.env ../hlf_setup step2: Added external builders into core.yaml and provided dokcer container path of external builder step3: modify peer docker-compose and mount chaincode and core.yaml folder. step4: up network step5: install asset-transfer-basic.tar.gz chaincode step 6: update chaincode id in chaincode.env step7: create docker container for chaincode server on host1 step8: approve chaincode by all orgs step9: commit chaincode step10 -invoke chaincode I am getting error when invoking chaincode ."endorserment failure during invoke.chaincode defintion exist but not installed" Kindly suggest. Regards, Shweta |
||||
|
|
||||
|
Re: Consenter Certificate Updates When Using a Third-Party CA
Robert Broeckelmann
Yacov, Thanks for responding. As I noted in my last post, I was able to fix my problem. I saw your response. I tried updating my Issuing CA certificates for the OrdererOrg to have OU=orderer. THere was no difference. I also tried no OU and a completely random OU on the Issuing CA certificate. It didn't seem to matter. I tried this on both the TLS Issuing CA and the digital signature Issuing CA certificates. All Issuing CA certificates (both original and new) were from a third-party CA and had no OU defined in my original solution. What I'm planning to move forward with has no OU in the Issuing CA DNs for any org.
------- Original Message -------
On Tuesday, February 1st, 2022 at 11:47 AM, Yacov Manevich <YACOVM@...> wrote:
|
||||
|
|
||||
|
Re: Consenter Certificate Updates When Using a Third-Party CA
Robert Broeckelmann
Good news. I was able to succesfully update the consenter certificates for all five of my RAFT orderer nodes. I got this working a couple of days ago. I wanted to share what I found. Mainly because I'm very curious if there is a more straightforward way of doing this. Before I attempt to update the consenter certificates in the application channel, I do the following: I generate a new Digital Signature CA certificate/key and TLS CA certificate/key. For testing purposes, I'm using openssl to do this. I generate all the new certificates (signed by the corresponding CA certs from the last step) needed for the orderers. This includes a dsig cert, tls cert, and admin cert for each orderer. The private keys are regenerated as well. All of these certs/keys are placed in the appropriate places in the crypto-config directory for each orderer. The system-channel configuration is updated successfully without issue. Then, I update the application channel configuration with the Issuing CAs and certs I generated. I originally, was updating the application channel at this step with the following JQ expression: '.channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.root_certs += ["'${DSIG_CA_ENCODED}'"] | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.admins += ["'${ADMIN_CERT_ENCODED}'"] | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.client_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.orderer_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.peer_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.admin_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.tls_root_certs += ["'${TLS_CA_ENCODED}'"]' After enabling debug on the protoutils module, I got the following log entries (note, I have trimmed out the full certificate and channel name): 2022-02-16 09:44:06.431 UTC [gossip.privdata] StoreBlock -> INFO 05e Received block [13] from buffer channel=app-channel 2022-02-16 09:44:06.431 UTC [protoutils] ValidateTransaction -> DEBU 05f ValidateTransactionEnvelope starts for envelope 0xc004d30410 2022-02-16 09:44:06.431 UTC [protoutils] ValidateTransaction -> DEBU 060 Header is channel_header:"\010...\"\r..." signature_header:"\n\321\n\n\nOrdererMSP\022\302\n-----BEGIN CERTIFICATE-----\nMIIDt...-----END CERTIFICATE-----\n\022...365" 2022-02-16 09:44:06.431 UTC [protoutils] validateChannelHeader -> DEBU 061 validateChannelHeader info: header type 1 2022-02-16 09:44:06.431 UTC [protoutils] checkSignatureFromCreator -> DEBU 062 begin 2022-02-16 09:44:06.432 UTC [protoutils] checkSignatureFromCreator -> DEBU 063 creator is &{OrdererMSP 956707729a2593b00cc66ca1ca8c9978c9304a2c3219c6c21cad9fce656c6c98} 2022-02-16 09:44:06.432 UTC [protoutils] ValidateTransaction -> ERRO 064 checkSignatureFromCreator returns err creator certificate is not valid: could not validate identity's OUs: certifiersIdentifier does not match: [orderer(65EE5DB1234EEE0E)], MSP: [OrdererMSP] 2022-02-16 09:44:06.432 UTC [committer.txvalidator] validateTx -> ERRO 065 Invalid transaction with index 0 So, the "creator certificate" in this case is the original digital signature certificate for our orderer0 node, which makes sense since the original certificate is still being used and this is the transaction that is supposed to introduce the new certificates to the channel configuration. Among the configuration elements being updated in this transaction is "fabric_node_ous.orderer_ou_identifier.certificate". So, I'm introducing the new digital signature CA certificate there. If I remove the update to this configuration element from the transaction and wait until the last orderer consenter certificate update to add it, then things start working as desired. I found this by temperarily removing each field update being made to the channel configuration that references the digital signature CA for the OrdererOrg (one at a time). So, the application channel configuration update now looks like: '.channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.root_certs += ["'${DSIG_CA_ENCODED}'"] | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.admins += ["'${ADMIN_CERT_ENCODED}'"] | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.client_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.peer_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.admin_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.tls_root_certs += ["'${TLS_CA_ENCODED}'"]' So, now the original ordererOrg digital signature CA cert is still trusted when the consenter certificates are being updated. So, the original error about BAD_CREATOR_SIGNATURE goes away and the new consenter certificate is accepted by each peer. In the final consenter certificate update transaction, I add the orderer OU CA certificate update as well with: if [ ${ELEMENT} -eq 4 ]; then cat ${TMP_DIR}/config.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].client_tls_cert = "'${ENCODED_CERT}'" | .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.orderer_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" | .channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].server_tls_cert = "'${ENCODED_CERT}'"' \ > ${TMP_DIR}/modified-${neworg}-root.json else cat ${TMP_DIR}/config.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].client_tls_cert = "'${ENCODED_CERT}'" | .channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].server_tls_cert = "'${ENCODED_CERT}'"' \ > ${TMP_DIR}/modified-${neworg}-root.json fi This completes the updates required to change out the Issuing CAs for the OrdererOrg. Is there an easier way to do this? There are several non-obvious steps here.
------- Original Message ------- On Tuesday, February 1st, 2022 at 10:45 AM, Robert Broeckelmann <robert@...> wrote:
|
||||
|
|
||||
|
Re: Fabric protobuf upgrade PR
Antoine Toulme <atoulme@...>
Hi everyone,
toggle quoted message
Show quoted text
The PR is ready for another round of review. The tests pass and Param has checked off the migration scenarios. Please take a good look. Cheers, Antoine
|
||||
|
|
||||
|
Re: how core peer address works
jkneubuh@...
Hi Nikos,
By all means please use the new Gateway client when connecting an application to a Fabric network. The new SDKs provide a single URL for access to the ledger, making for a very convenient bridge into the network. Good examples of the gateway SDK in action can be found at application-gateway-go and application-gateway-typescript. For discovery in K8s, the typescript application is also set up to read input parameters (cert paths, host names, etc.) from the incoming environment. It's still a little rough but an example that runs the typescript application locally with the Kube test network is at ci/scripts/run-k8s-test-network-basic.sh. When connecting the gateway client in Kubernetes, we can set up a kube Service instance fronting multiple peers in the network. See @charalarg 's recent PR #639 and Issue #635 to see this in action, and HIGH_AVAILABILITY for a little additional context. Cheers and happy coding, -josh |
||||
|
|
||||
|
Re: how core peer address works
Nikos Karamolegkos
Any information on that?
|
||||
|
|
||||
|
Fabric Contributor Meeting - February 16, 2022 - CANCELLED
David Enyeart
Fabric contributor meeting cancelled this week, no agenda topics.
Please send any agenda topics for March 2nd meeting to this mail list.
|
||||
|
|
||||
|
Cancelled Event: Fabric Contributor Meeting - Wednesday, February 16, 2022
#cal-cancelled
fabric@lists.hyperledger.org Calendar <noreply@...>
Cancelled: Fabric Contributor Meeting This event has been cancelled. When: Where: Organizer: Dave Enyeart enyeart@... Description: Join Zoom Meeting
https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09
Meeting ID: 518 494 7650
Passcode: 475869
|
||||
|
|
||||
|
Fabric Documentation workgroup monthly call Friday 2/18
11:00am to 12:00pm (UTC-05:00) Eastern Time - New York (EST) |
||||
|
|
||||
|
Now: Private Chaincode Lab - 02/15/2022
#cal-notice
fabric@lists.hyperledger.org Calendar <noreply@...>
Private Chaincode Lab When: Where: Organizer: Marcus Brandenburger bur@... Description: |
||||
|
|
||||
|
Virtual meetup about using Kubernetes with Hyperledger Fabric on Feb 23 at 16:00 UTC
David Boswell <dboswell@...>
On Wednesday, Feb 23 @ 16:00 UTC you're invited to a virtual meetup that will look at the possibilities of using Hyperledger Fabric with Kubernetes. Since this is a virtual meetup, anyone anywhere is welcome to dial-in. Details are at: And if anyone here is interested in speaking about the work you're doing with Fabric at a meetup, let me know and I'll be happy to help you organize and promote an event. Thanks, David |
||||
|
|