Upon rebooting the Google Compute Engine VM instance, I see these errors:
startupscript: Finished running startup script /var/run/google.startup.script
xxxx accounts-from-metadata: WARNING error while trying to update accounts: <urlopen error [Errno 101] Network is unreachable>
xxxx accounts-from-metadata: WARNING error while trying to update accounts: <urlopen error [Errno 101] Network is unreachable>
What could be the problem?
Update: Upon viewing the original question and reformatting it, it looks like there's a network error at bootup (was hidden due to the text in <...> being treated as HTML and not viewable), so my earlier answer (below) may not be applicable. Leaving it here for future reference.
Please check your network settings, firewalls, etc. in the meantime.
Original text:
You may have a syntax error in the sshKeys metadata key. The format is:
<username>:<protocol> <key-blob> <username#example.com>
The right hand side of the : is essentially the contents of your public key, e.g., ~/.ssh/google_compute_engine.pub.
To see your current metadata key:
ssh into the instance, e.g., via gcloud compute ssh, or via the SSH button in Developers Console
Load this key via:
curl http://metadata/computeMetadata/v1/project/attributes/sshKeys \
-H "Metadata-Flavor: Google"
and check the formatting.
You can then change the metadata on your instance.
Related
I am following a get started tutorial for gRPC, specifically the "Getting Started" example. I have created the image per ReadMe. I created the server image locally using Docker for Windows.
I create the Endpoint, I see it in the Console. I also created a VPC. I should be able to deploy now. I am attempting to use the GCE steps in ReadMe. I am stuck on:
gcloud compute instances create grpc-host --image-family gci-stable --image-project google-containers --tags=http-server --network=default --image-project
I get this error:
ERROR: (gcloud.compute.instances.create) Could not fetch resource:
The resource 'projects/debian-cloud/global/images/family/gci-stable' was not found
I don't think I missed a step. But, the error message appears to hint at some missing step.
Thanks.
Loading NaCl plugin... done.
Connecting to user#172.27.0.31...
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:C11asdfasdfxY6asdfasdfIUfadsfasdRB4.
Please contact your system administrator.
Add correct host key in /.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /.ssh/known_hosts:21
ECDSA host key for 172.27.0.31 has changed and you have requested strict checking.
Host key verification failed.
NaCl plugin exited with status code 255.
(R)econnect, (C)hoose another connection, or E(x)it?
This error is related to Chrome Secure Shell App extension.
This error may happen if you are under man in the middle attack or due to certificate change on the server side.
Previous fix to this was to delete local entry from known hosts by using Chrome console:
term_.command.removeKnownHostByIndex(21)
But produces error:
VM237:1 Uncaught TypeError: term_.command.removeKnownHostByIndex is not a function
at <anonymous>:1:15
Now (my chrome Version 85.0.4183.83 (Official Build) (64-bit)) an entry can be deleted manually in extension settings. 3 dots (chrome right upper corner) > More tools > Extensions > Secure Shell App Details > Extensions > options > SSH Files > Delete specific entry (whole row) in ~/.ssh/known_hosts
now that the app is discouraged in favour of the extension,
in the top-left corner of the terminal you may click the icon,
and delve into terminal settings and SSH.
~/.ssh/known_hosts is there.
good luck!
Here's my problem :
I would like to connect to a gcp instance. When I run the Google Cloud SDK shell as an administrator with the command :
gcloud compute ssh my_instance --zone=europe-west1-b -- -L=8081:locahost:8081
..I get this error : ERROR (gcloud.compute.ssh) [..../putty.exe] exited with return code [1]
My instance is running with the metadata enable-oslogin as TRUE, as the project.
Do you have an idea of what is the problem ?
When using -- in the command, you are passing SSH flags after the dashes and not gcloud command flags. To explain, gcloud compute ssh is a thin wrapper around the ssh(1) command that takes care of authentication and the translation of the instance name into an IP address.
In this case, -- is equivalent to --ssh-flag as per this SDK reference. It seems that putty is outputting an error that is not passed into the command line (SDK shell). The actual error should be visible in the dialog window before putty exits.
I have tried the command myself on Windows and the exact error was unknown option "L=8081:localhost:8081". The SSH flag is not accepted as you have an = sign there (typo).
According to linuxcommand.org manual, the flag should be in this format:
-L [bind_address:]port:host:hostport
Hence, you should run the command like this:
gcloud compute ssh my_instance --zone=europe-west1-b -- -L 8081:locahost:8081
Note also that you may have to create a firewall rule to allow Ingress to the instance on port 8081.
Im trying to learn Hyperledger Composer but seems to be a relatively new technology, i mean there are few tutorials and few solutions to a lot of questions, tutorial does not mention possible error case when following the commands and which means there are is also no solution for those errors.
I have joined the composer channel in their community chat, looks like its running in Discord or something, and asked the same question without a response, i have a better experience here in SO.
This is the problem: I have deployed my business network, installed it, started it, created my network admin card and imported it, then to test if everything is ok i have to command composer network ping --card NAME-OF-MY-ADMIN-CARD
And this error comes:
juan#JuanDeDios:~/proyectos/inovacion/a3-poliza-microservice$ composer network ping --card admin#a3-policy-microservice
Error: transaction returned with failure: AccessException: Participant 'org.hyperledger.composer.system.NetworkAdmin#admin' does not have 'READ' access to resource 'org.hyperledger.composer.system.Network#a3-policy-microservice#0.0.1'
Command failed
I think that it has to do something with the permission.acl file, and gave permission to everyone to everything so there would not be any restrictions to anyone, and tryied again, but failed.
So i thought i had to uninstall my business network and create it again, i deleted my .bna and my network.card files also so everything would be created again, but the same error result.
My other attempt was to update the business network, but didn't work, the same error happened and I'm sure i didn't miss any step from the tutorial. I do also followed the playground tutorial. What i have not done its to create another app with the Yeoman but i will do if i don't find a solution to this problem which would not require me to create another app.
This were my steps:
1-. Created my app with Yeoman
yo hyperledger-composer:businessnetwork
2-. Selected Apache-2.0 for my license
3-. Created a3-policy-microservice as the name of the business network
4-. Created org.microservice.policy (Yeah i switched names but Im totally aware)
5-. Generated my app with a template selecting the NO option
6-. Created my assets, participants and transactions
7-. Changed my permission rules to mine
8-. I generated the .bna file
composer archive create -t dir -n .
9-. Then installed my bna file
composer network install --card PeerAdmin#hlfv1 --archiveFile a3-policy-microservice#0.0.1.bna
10-. Then started my network and created my networkadmin card
composer network start --networkName a3-policy-network --networkVersion 0.0.1 --networkAdmin admin --networkAdminEnrollSecret adminpw --card PeerAdmin#hlfv1 --file networkadmin.card
11-. Imported my card
composer card import --file networkadmin.card
12-. Tried to ping my network
composer network ping --card admin#a3-poliza-microservice
And the error happens
Later i tried to create everything again shutting down my fabric and started it again and creating the network from the first step.
My other attempt was to change the permissions and upgrade my bna network, but it failed too. Im running out of options
Hope this description its not too long to ignore it. Thanks in advance
thanks for the question!
First possibility is that your network name is a3-policy-network but you're pinging a network called a3-poliza-microservice - once you do get the correct ACLs in place (currently, that's the error you're trying to resolve).
The procedure for upgrade would normally be the procedure below:
After your step 12 (where you can't ping the business network due to restrictive ACL conditions, assuming you are using the right network name) you would have:
Make the changes to to include your System ACLs this time eg.
/**
* Sample access control list.
*/
rule SystemACL {
description: "System ACL to permit all access"
participant: "org.hyperledger.composer.system.Participant"
operation: ALL
resource: "org.hyperledger.composer.system.**"
action: ALLOW
}
rule NetworkAdminUser {
description: "Grant business network administrators full access to user resources"
participant: "org.hyperledger.composer.system.NetworkAdmin"
operation: ALL
resource: "**"
action: ALLOW
}
rule NetworkAdminSystem {
description: "Grant business network administrators full access to system resources"
participant: "org.hyperledger.composer.system.NetworkAdmin"
operation: ALL
resource: "org.hyperledger.composer.system.**"
action: ALLOW
}
Update the "version" field in your existing package.json in your Business Network project directory (ie need to change it next increment - eg. update the version property from 0.0.1 to 0.0.2.)
From the same directory, run the following command:
composer archive create --sourceType dir --sourceName . -a a3-policy-network#0.0.2.bna
Now install the new business network code firstly:
composer network install --card PeerAdmin#hlfv1 --archiveFile a3-policy-network#0.0.2.bna
Then perform the requisite upgrade step (single '-' for short form of the parameter):
composer network upgrade -c PeerAdmin#hlfv1 -n a3-policy-network -V 0.0.2
After a few seconds, ping the network again to see ACL changes are now in effect:
composer network ping -c a3-policy-network
I am programatically launching a new instance using the Compute Engine API for Go [1], and a tool I made called vmproxy [2].
The problem I have is that if I launch a preemptible VM using a startup-script-url pointing to https://bitbucket.org/ronoaldo/debian-custom/raw/tip/tools/autobuild, the build script fails to download. I can see in the serial console output that the the startup script metadata is there, and that it attempts to be downloaded with curl, but that part fails.
However, if I reset the instance via the developers console, the script is properly downloaded and runs nicelly.
The code I am using to setup the instance is:
// Ronolinux is a VM Proxy that runs an live systems build on Compute Engine
var (
Ronolinux = &vmproxy.VM{
Path: "/",
Instance: vmproxy.Instance{
Name: "ronolinux-buildd",
Zone: "us-central1-f",
Image: vmproxy.ResourcePrefix + "/debian-cloud/global/images/debian-8-jessie-v20150915",
MachineType: "n1-standard-1",
Metadata: map[string]string{
"startup-script-url": "https://bitbucket.org/ronoaldo/debian-custom/raw/tip/tools/autobuild",
"shutdown-script": `!#/bin/bash
gsutil cp /var/log/startupscript.log gs://ronoaldo/ronolinux/build-$(date +%Y%m%d%H%M%S).log
`,
},
Scopes: []string{ storageReadWrite },
},
}
)
[1] https://godoc.org/google.golang.org/api/compute/v1
[2] https://godoc.org/ronoaldo.gopkg.net/aetools/vmproxy
If your startup script is not hosted on Cloud Storage, there is a random chance the download will fail. If you look at the serial console output, make sure to scroll horizontally, as it will not wrap long lines. In my case, the error line was very long, and this hidded the real end of the message:
(... long curl on-line progress output )
curl: (7) Failed to connect to bitbucket.org port 443: Connection timed out
(...)
Your host must respond within a 10s timeout. In my case, the first boot usually failed to contact Bitbucket, hence failing to download the script; a VM reset also made things work, as the network latency outside Google Cloud were probably better.
I ended up moving to host the script on cloud storage to avoid these issues.