I have tried looking for an answer to this problem for over a month. Apparently I am the only one in the world who ever had this issue... Here's the console commands I am giving over ssh. I am logged into the only account with permissions and it has FULL permissions over the project... I am stumped.
sudo gcloud compute copy-files /home/lestado/trs.key adminuser#the-real-strategy-vm:/etc/ssl/private/
This is the response I am getting:
Did you mean zone [us-central1-f] for instances:
[['[the-real-strategy-vm]']]?
Do you want to continue (Y/n)? y
ERROR: (gcloud.compute.copy-files) Could not fetch instance:
- Insufficient Permission
Set your project name before you start copying files.
gcloud config set project <project_name>
Complete process will be:
Login: gcloud init
Set project: gcloud config set project <project_name>
Upload using root user for instance: gcloud compute copy-files ./ root#instance:/etc/ssl/pvt
Related
I am trying to follow these instructions to log correctly from java to logback to cloudrun...
https://cloud.google.com/logging/docs/setup/java
If I used jdk8, I get alpn missing jetty issues so I moved to a Docker image openjdk:10-jre-slim
and my DockerFile is simple
FROM openjdk:10-jre-slim
RUN mkdir -p ./webpieces
COPY . ./webpieces/
COPY config/logback.cloudrun.xml ./webpieces/config/logback.xml
WORKDIR "/webpieces"
ENTRYPOINT ./bin/customerportal -http.port=:$PORT -hibernate.persistenceunit=cloud-production
AND the only difference is I switched the image from openjdk:8-jdk-alpine which worked fine!!!
When I deploy to google cloud I get this error...
Deploying container to Cloud Run service [staging-customerportal] in project [orderly-gcp] region [us-west1]
⠏ Deploying... Cloud Run error: Invalid argument error. Invalid ENTRYPOINT. [name: "gcr.io/orderly-gcp/customerportal2#sha256:6c1c2e7531684d8f50a3120f1de60cade841ab1d9069b
704ee3fd8499c5b7779"
error: "Invalid command \"/bin/sh\": file not found"
].
X Deploying... Cloud Run error: Invalid argument error. Invalid ENTRYPOINT. [name: "gcr.io/orderly-gcp/customerportal2#sha256:6c1c2e7531684d8f50a3120f1de60cade841ab1d9069b
704ee3fd8499c5b7779"
error: "Invalid command \"/bin/sh\": file not found"
].
. Routing traffic...
Deployment failed
ERROR: (gcloud.run.deploy) Cloud Run error: Invalid argument error. Invalid ENTRYPOINT. [name: "gcr.io/orderly-gcp/customerportal2#sha256:6c1c2e7531684d8f50a3120f1de60cade841ab1d9069b704ee3fd8499c5b7779"
error: "Invalid command \"/bin/sh\": file not found"
].
However, when I run locally to test, I get this error on project ID being required so it seems it is working. SIDE QUESTION: How to simulate this project ID so I can still run locally?
03:10:08,650 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [CLOUD]
03:10:09,868 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter#14:13 - RuntimeException in Action for tag [appender] java.lang.IllegalArgumentException: A project ID is required for this service but could not be determined from the builder or the environment. Please set a project ID using the builder.
at java.lang.IllegalArgumentException: A project ID is required for this service but could not be determined from the builder or the environment. Please set a project ID using the builder.
at at com.google.common.base.Preconditions.checkArgument(Preconditions.java:142)
at at com.google.cloud.ServiceOptions.<init>(ServiceOptions.java:285)
at at com.google.cloud.logging.LoggingOptions.<init>(LoggingOptions.java:98)
at at com.google.cloud.logging.LoggingOptions$Builder.build(LoggingOptions.java:92)
at at com.google.cloud.logging.LoggingOptions.getDefaultInstance(LoggingOptions.java:52)
at at com.google.cloud.logging.logback.LoggingAppender.getLoggingOptions(LoggingAppender.java:246)
at at com.google.cloud.logging.logback.LoggingAppender.getProjectId(LoggingAppender.java:209)
at at com.google.cloud.logging.logback.LoggingAppender.start(LoggingAppender.java:194)
at at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:90)
at at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309)
at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193)
at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179)
at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:165)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:152)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:110)
The Java 10 version is EOL, and the official images has been removed. More detail here
Prefer a Java 11 version.
Anyway, when you use version, some are optimized and does not install bash by default (for reducing their size) and you have to install it by yourselves.
For a local run, I don't recommend to use a JSON key file (in general, don't use JSON key file, except for automated system out of GCP) due to security constraint, key rotation, secure storage,...
For setting the project, simply perform this command gcloud config set project MY_PROJECT. You don't need credential for this.
Since your current question is how to simulate the project ID for local testing:
You should download service account key file from https://console.cloud.google.com/iam-admin/serviceaccounts/project?project=MY_PROJECT, make it accessible inside docker container and activate it via
gcloud auth activate-service-account --key-file my_service_account.json
gcloud config set project MY_PROJECT
This problem may be due to the fact that alpine doesn't have bash:
"/bin/sh" therefore a solution could be to remove the dependency on bash itself by not using bash or by using exec instead of bash.
in my case I solved the problem by using a more complete base image, instead of alpine for instance.
HTH
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.
I have previously had Serverless installed on a server, and then when I tried to edit the function and package it back up to edit the zip file I broke it, so I have to start all over. So to begin this issue: I had Serverless running and was using it with this package - https://github.com/adieuadieu/serverless-chrome/tree/master/examples/serverless-framework/aws
When I sudo npm run deploy, I get the ServerlessError:
ServerlessError: User: arn:aws:sts::XXX:assumed-role/EC2CodeDeploy/i-268b1acf is not authorized to perform: cloudformation:DescribeStackResources on resource: arn:aws:cloudformation:us-east-1:YYY:stack/aws-dev/*
I'm not sure why it is trying to connect to a Role and not an IAM. So I check the Role, and it is in an entirely different AWS account than the account I've configured. Let's call this Account B.
When it comes to configuration, I've installed AWS CLI and entered in the key, id, and region in my Account A in AWS. Not touching Account B whatsoever. When I run aws s3 ls I see the correct s3 buckets of the account with the key/id/regioin, so I know CLI is working with the correct account. Sounds good. I check the ~/.aws/creditionals file and just has one profile [default] which seems normal. No other profiles are in here. I copied this over to the ~/.aws/config file so now both files are same. Works great.
I then go into my SSH where I've installed serverless, and run npm run deploy and it gives me the same message above. I think maybe somehow it is not using the correct account for whatever reason. So I manually set the access key and secret with the following commands:
serverless config credentials --provider aws --key XXX --secret YYY
It tells me there already is a profile in the aws creds file, so I then add --o to the end to overwrite. I run sudo npm run deploy and still same error.
I then run this command to manually set a profile in the creds for serverless, with the profile name matching the IAM user name:
serverless config credentials --provider aws --key XXX --secret YYY --profile serverless-agent
Where "serverless-agent" is the name of my IAM user I've been trying to use to deploy. I run this, it tells me there already is an existing profile in the aws creds file so I run it with --o and it tells me the aws file is now updated. In bash I go to Vim the file and I only see the single "[default]" settings, as if nothing has changed. I run sudo npm run deploy and it gives me the same Error.
I then go and manually set the access and secret:
export AWS_ACCESS_KEY_ID=XXX
export AWS_SECRET_ACCESS_KEY=YYY
I run sudo npm run deploy and it gives me the same Error.
I even removed AWS CLI, and the directory that holds the creditionals and config files - and when I manually set my account creds via serverless config it tells me there already is a profile set up in my aws file, prompting me to use the overwrite command - how is this possible when the file is literally not on my computer?
So I then think that serverless itself has a cache or something, calling the wrong file or whatever for creds, so I uninstall serverless via sudo npm uninstall -g serverless so that I can start from zero again. I then do all of the above steps and more all over again, and nothing has changed. Same error message.
I do have Apex.run set up, but that should be using my AWS CLI config file so I'm not sure if that is causing any problems. But then again I've no clue of anything deep on this subject, and I can't find any ability to remove Apex itself in their docs.
In the package I am trying to deploy, I do not have a profile:XXX set in the serverless.yml file, because I've read if you do not then it just defaults to the [default] profile you have set in the aws creds file on your computer. Just to check, I go into the serverless.yml file and set the profile: default, and the error I now get when I run npm run deploy is
Profile default does not exist
How is that possible when I have the "default" profile set in my creds file? So I remember that previously I ran the serverless config creditionals command and added the profile name of serverless-agent to it (yet didn't save in the aws creds file as I mentioned above), so I add that profile name to the serverless.yml file just to see if this works, and same error of "Profile default does not exist".
So back to the error message. The Role is an account not even related to the IAM user I'm using in my aws creds. Without knowing a lot about this, it's as if the config in serverless via ssh isn't correct or something. Is it using old creds I had set up in Apex.run? Why is the aws creds file not updated with the profile when I manually set it in serverless config command? I am using the same user account (but with new key and secret) that I used a few weeks ago when I correctly deployed and my Lambda and API was set up for me on AWS. Boy do I miss those time and wish I didn't mess up my existing Lambda functions, without setting version number prior, forcing me to start all over.
I am so confused. Any help would be greatly appreciated.
If you are using IAM role then you have to use that IAM role through assume role using powershell.
I was also facing same issue earlier, when we moved from from user to role.
I have been following this for setting up a fabric-ca server in my network of 2 organizations, 4 peers (2 in each).
I have two questions:
In the documentation, it says that we can start server locally. When I try to do the same, I'm not able to do it and getting the following error :
fabric-ca-server: command not found . So I tried using a docker image and the server now works as a docker image.
Now when I try to run the fabric-ca-client command, it cannot find the client configuration in the fabric-ca-client home. The FABRIC_CA_HOME environment variable is set as `/etc/hyperledger/fabric-ca-server' in the container. I'm confused as to what I might be missing here.
If you followed the instructions, then the fabric-ca-server executable will be under $GOPATH/bin, you will need to add this to your PATH, via export PATH=$PATH:$GOPATH/bin. Remember to also set FABRIC_CA_HOME.
Assuming you're also using the client natively, it should also be under $GOPATH/bin. In a separate terminal, set FABRIC_CA_HOME to a different path. Then you can enroll the admin user, for example: fabric-ca-client enroll -u http://admin:password#localhost:7054.
The issue is coming because you have not set the GOPATH path.
After cloning the CA repo set the GOPATH to the given directory.
For setting up GOPATH:
(Ubuntu)
If you don’t set a GOPATH, the default will be used.
You have to add $GOPATH/bin to your PATH to execute any binary installed in $GOPATH/bin, or you need to type $GOPATH/bin/the-command.
Add this to your ~/.bash_profile
export PATH=$GOPATH/bin:$PATH
Current GOPATH command:
go env GOPATH
Changing the GOPATH command:
export GOPATH=$HOME/your-desired-path
So. change the 'your-desired-path' to your Fabric-CA repo directory.
You will be facing issue with certain versions of golang. Set the flags explicitly using CGO_LDFLAGS_ALLOW='-Wl,--no-as-needed'
Reference -
Error while running make command using Fabric 1.0.6 after all the 15 steps
https://github.com/golang/go/issues/23739
➜ fabric-ca git:(release-1.0) go get -u github.com/hyperledger/fabric-ca/cmd/...
go build github.com/hyperledger/fabric-ca/vendor/github.com/miekg/pkcs11: invalid flag in #cgo LDFLAGS: -I/usr/local/share/libtool
➜ fabric-ca git:(release-1.0) export CGO_LDFLAGS_ALLOW='-Wl,--no-as-needed'
➜ fabric-ca git:(release-1.0) make
I downloaded and installed Jenkins for Mac OSX on my Macbook Pro (OS: Mountain Lion). I now want to set it up to pull down a project from bitbucket and do an automatic build.
I created the ssh key, added it to bitbucket and tried to setup a build job. However, I get the error:
Failed to connect to repository : Command "git ls-remote -h HEAD" returned status code 128:
stdout:
stderr: Host key verification failed.
fatal: The remote end hung up unexpectedly
I tried to remove the domain causing the problem from known_hosts but am still getting this error.
Please advise.
I think I've found a possible solution in this post: http://colonelpanic.net/2011/06/jenkins-on-mac-os-x-git-w-ssh-public-key/
Jenkins on Mac OS X I just finished setting up a build server on Mac
OS X using Jenkins (formerly Hudson). The company I’m working for
(GradeCam) uses git and gitolite for our source control and so I
expected no trouble using Jenkins to build our tools using the git
plugin.
However, I quickly ran into a snag: the source control server is on a
public address and so our source code is not available except via ssh,
and gitolite ssh access uses private key authentication. Well, I’m an
experience unix sysadmin, so that didn’t sound like a big issue —
after all, setting up public key authentication is childs play, right?
Default install
The default installation of Jenkins on Mac OS X (at the time of this
writing) installs a Launch Agent plist to
/Library/LaunchAgents/org.jenkins-ci.plist. This plist file causes
Jenkins to load as user “daemon”, which sounds fine — except that the
home directory for the “daemon” user is /var/root, same as for user
root. This means that the .ssh dir in there will never have the right
permissions for a private key to be used.
Creating a new hidden user
My solution was to create a new “hidden” user for Jenkins to run
under. Following instructions I found on a blog post, I created a user
“jenkins” with a home directory “/Users/Shared/Jenkins/Home”:
sudo dscl . create /Users/jenkins
sudo dscl . create /Users/jenkins PrimaryGroupID 1
sudo dscl . create /Users/jenkins UniqueID 300
sudo dscl . create /Users/jenkins UserShell /bin/bash
sudo dscl . passwd /Users/jenkins $PASSWORD
sudo dscl . create /Users/jenkins home /Users/Shared/Jenkins/Home/
I then stopped Jenkins: “sudo launchctl unload -w
/Library/LaunchAgents/org.jenkins-ci.plist” and edited the plist file
to set the username to jenkins instead of daemon.
“chown -R jenkins: /Users/Shared/Jenkins/Home”
sets the permissions how they need to be, and then “sudo launchctl
load -w /Library/LaunchAgents/org.jenkins-ci.plist” should get you up
and running!
To get git over ssh running, “sudo su – jenkins” to get a console as
the jenkins user and set up the ssh keys and such. Make sure you can
ssh to where you want to go (or even do a test git clone) because you
need to save the keys so it doesn’t ask for them when jenkins tries to
do the clone.
That should do you! Hope it helps someone.