Error: endorsement failure during invoke. response: status:500 message:"error in simulation: failed to execute transaction [duplicate] - hyperledger

I just reinstalled Fabric Samples v2.2.0 from Hyperledger Fabric repository according to the documentation.
But when I try to run asset-transfer-basic application located in fabric-samples/asset-transfer-basic/application-javascript directory by running node app.js the wallet is created and an admin and user is registered. But then it tries to invoke the function as given in app.js and shows this error
error: [Transaction]: Error: No valid responses from any peers. Errors:
peer=peer0.org1.example.com:7051, status=500, message=error in simulation: failed to execute transaction
aa705c10403cb65cecbd360c13337d03aac97a8f233a466975773586fe1086f6: could not launch chaincode basic_1.0:b359a077730d7
f44d6a437ad49d1da951f6a01c6d1eed4f85b8b1f5a08617fe7: error starting container: error starting container:
API error (404): network _test not found
Response of a transaction to invoke a function
This error never occured before. But somehow after reinstalling docker and Hyperledger Fabric fabric-samples it never seems to find the network _test.
N.B. : Before reinstalling name of the network was net_test. But now when I try docker network ls it shows a network called docker_test. I am using Windows Subsystem for Linux (WSL) version 1.
NETWORK ID NAME DRIVER SCOPE
b7ac05456f46 bridge bridge local
acaa5856b871 docker_test bridge local
866f58b9078d host host local
4812f94efb15 none null local
How can I fix the issue occurring when I try to run the application?

In my opinion, the CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE setting seems to be wrong.
you can check docker-compose.yaml or core.yaml
1. docker-compose.yaml
I will explain fabric-samples/test-network as targeting according to your current situation.
You can check in CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE in docker-compose.yaml
Perhaps in your case(fabric-samples/test-network), the value of ${COMPOSE_PROJECT_NAME} was not set properly, so it was set to _test.
Make sure the value is set correctly and change it to your network name.
# hyperledger/fabric-samples/test-network/docker/docker-compose-test-net.yaml
# based v2.2
...
peer0.org1.example.com:
container_name: peer0.org1.example.com
image: hyperledger/fabric-peer:2.2
environment:
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
# - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_test
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=docker_test
...
2. core.yaml
If you have not set the value in the docker-compose.yaml peer, you need to check the core.yaml referenced by the peer.
you can find the networkMode parameter in core.yaml
# core.yaml
...
vm:
docker:
hostConfig:
# NetworkMode: host
NetworkMode: docker_test
...
If neither is set, it will be set to the default value. However, as you see _test being logged, the wrong value have been set in one of the two section, and you need to correct the value to the value you intended.

This issue is related to docker networking. In complete to #nezuko-response.
Create a file and name it ".env" in the same directory where your docker-compose file exists.
Add the following line in it:
COMPOSE_PROJECT_NAME=net
Use docker-compose up to update the container with the new configurations.
Or bring the HL network down (./network.sh down) and up (./network.sh up), restarting the test-nework.
Otherwise you'll still get the same error even after creating ".env" file.
More explanation about docker networking

run ./network down
then
export COMPOSE_PROJECT_NAME=net
afterwards
./network start

I copied this from someone .This one worked for me !!
Please create a file named ".env" in the same directory where your docker-compose file exists. Add the following line in ".env" file:-
COMPOSE_PROJECT_NAME=net

This worked for me
export COMPOSE_PROJECT_NAME=net

Related

How to use RABBITMQ_DEFAULT_USER and RABBITMQ_DEFAULT_PASS with defined rabbitmq-conf.json

I am facing an issue while trying to run RabbitMQ docker container.
It says user does not exist (https://i.stack.imgur.com/SOeqq.png).
I am passing userid and password to RabbitMQ docker-compose file as environment variables during runtime.(user and password wont be fix)
docker-compose file
I have created rabbitmq-conf.json as i need to use some predefined queues.
rabbitmq-conf.json file
It was working fine with RabbitMQ:3.8.14-management-alpine image but not working with Rabbitmq:3.11.3-management-alpine
rabbitmq.conf file contains:-
management.load_definitions = /etc/rabbitmq/rabbitmq-conf.json

Deploying Cloud Run via YAML gives error spec.template.spec.containers should contain exactly 1 container

When deploying a Cloud Run service via a YAML file from the command line, it fails with this error.
ERROR: (gcloud.run.services.replace) spec.template.spec.containers should contain exactly 1 container
This is because the documentation for adding an environment variable is wrong, or confusing at best.
The env node should be a child of the image and not the containers node as it says here.
https://cloud.google.com/run/docs/configuring/environment-variables#yaml
This is correct:
- image: us-east1-docker.pkg.dev/proj/repo/image:r1
env:
- name: SOMETHING
value: Xyz

VS Code Remote Container unable to get local issuer certificate

VSCode Version:
1.62.2
Local OS Version:
Windows 10.0.18363
Reproduces in: Remote - Containers
Name of Dev Container Definition with Issue:
/vscode/devcontainers/typescript-node
In our company we use a proxy which terminates the SSL connections. When I now try to start any devcontainer (the workspace is in the WSL2 filesystem), I get the following error message:
Installing VS Code Server for commit 3a6960b964327f0e3882ce18fcebd07ed191b316
[2021-11-12T17:01:44.400Z] Start: Downloading VS Code Server
[2021-11-12T17:01:44.400Z] 3a6960b964327f0e3882ce18fcebd07ed191b316 linux-x64 stable
[2021-11-12T17:01:44.481Z] Stop (81 ms): Downloading VS Code Server
[2021-11-12T17:01:44.499Z] Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (_tls_wrap.js:1497:34)
at TLSSocket.emit (events.js:315:20)
at TLSSocket._finishInit (_tls_wrap.js:932:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:706:12)
In the dockerfile I copy the company certificates and update them:
ADD ./certs /usr/local/share/ca-certificates
RUN update-ca-certificates 2>/dev/null
The proxy environment variables are also set correctly. Out of desperation I also tried to disable the certificate check for wget:
RUN su node -c "echo check_certificate=off >> ~/.wgetrc"
Even in the devcontainer configuration I have disabled the proxy and the security check for VS code via the settings:
// Set *default* container specific settings.json values on container create.
"settings": {
"http.proxy": "http://<proxy.url>:8080",
"http.proxyStrictSSL": false
},
I have tried many other things, like setting NODE_TLS_REJECT_UNAUTHORIZED=0 as env variable inside the dockerfile, unfortunately without any success. Outside the company network, without the proxy, it works wonderfully.
Maybe one of you has an idea how I can solve this problem?
A working if not so nice solution to the problem is to add HTTPS exceptions for the following domains:
https://update.code.visualstudio.com
https://az764295.vo.msecnd.net
A list of common hostnames can be found here:
https://code.visualstudio.com/docs/setup/network

docker-compose service list changes among branches: Service has neither an image nor a build context specified. At least one must be provided

I'm working on a new service on my stack.
So when I work on the new-service branch, I have in docker-compose.yml:
version: "3.6"
services:
app:
image: whatever
new_service:
image: whatever
I do docker-compose up and start working.
But then I sometimes need to make hot fixes on the master branch, where new_service is not there.
When I try to do docker-compose up, I get the following error:
ERROR: The Compose file is invalid because:
Service new_service has neither an image nor a build context specified. At least one must be provided.
I guess, I could edit my docker-compose.yml file to add fake new_service entry only to start my server, but that's not an acceptable solution to me.
Shouldn't docker-compose re-read the service list on every start? Or can't I at least force the refresh like docker-compose up --reset?
Ok my bad.
docker-compose does work as expected, but I had a
service:
new_service:
command: yarn dev
entry in my docker-compose.override.yml which is .gitignored, hence the error.
I wanted to delete the question, but then I considered others may do the mistake, and landing here would help them too.
We'll see. :-)

Can't attach CircleCI Workspace from Windows to Linux due to "Cannot change ownership to uid 3434"

I am using CircleCI's persistent workspace feature to run jobs with the same build folder between Linux and Windows executor types. I was able to go from Linux to Windows but when I went from Windows to Linux I got this error when CircleCI attempted to attach the workspace.
Applying workspace layers:
9ba3eddc-3658-43c2-858b-aea39250af3e
25c476af-8804-4125-b979-05a62a9ac204
Error applying workspace layer for job 25c476af-8804-4125-b979-05a62a9ac204: Error extracting tarball /tmp/workspace-layer-25c476af-8804-4125-b979-05a62a9ac204854634413 : tar: project/.circleci/config.yml: Cannot change ownership to uid 3434, gid 197121: Invalid argument
Looking at the error it's clear that the UIDs are not existing on the system. I attempted to run commands to create the same UID/GID it was erroring on but I still got an unable to change owner issue.
I was expecting CircleCI to move the files and ignore the user: group part when it was extracted as you can't guarantee the UID/GID exists.
I opened a support ticket but hoping for a faster solution to this issue.
I found a solution to this issue and it's forcing CircleCI to use TAR_OPTIONS environment variable to force the options to ignore the owner/group.
Here is what I added to my jobs steps that attach the workspace when the previous job run was Window.
build-app:
build:
docker:
- image: Dockerhub.com/myrepo/myimage:1.0.0
environment:
TAR_OPTIONS: --no-same-owner
using TAR_OPTIONS environment to inject the option --no-same-owner allowed CircleCI to extract the tarball without issue.

Resources