Here's a transcript so far:
$ sbt new lagom/lagom-scala.g8
[info] Loading global plugins from /Users/abrahma/.sbt/1.0/plugins
[info] Set current project to lagomlife (in build file:/Users/abrahma/Bitbucket/Practice-Scala/LagomLife/)
[info] Set current project to lagomlife (in build file:/Users/abrahma/Bitbucket/Practice-Scala/LagomLife/)
ssh://git#github.com/lagom/lagom-scala.g8.git: Auth fail
I've verified authentication with
GitHub:
$ ssh -T git#github.com
Hi agam! You've successfully authenticated, but GitHub does not provide shell access.
Also verified that I can access the repo in question (i.e. I can do the following, in a separate location):
git clone ssh://git#github.com/lagom/lagom-scala.g8.git
Edit: fwiw I'm able to work around whatever the root cause is here:
git clone ssh://git#github.com/lagom/lagom-scala.g8.git
g8 file:///Users/abrahma/tmp/lagom-scala.g8
I ran into this problem as well, and solved it by removing the following from my ~/.gitconfig:
[url "git#github.com:"]
insteadOf = https://github.com/
Are you using OpenSSH 7.8 or newer, and have you recently created your private key?
If so you might be running into the issue described in “Invalid privatekey” when using JSch aka jsch#129.
The root cause was discovered to be the ssh private key mismatch.
The question has a workaround to convert the key file to an older format if that's the error you're seeing.
You need to add your SSH key to the agent:
ssh-add ~/.ssh/id_rsa
Related
I'm trying to use Concourse to grab a dockerfile defintion from a git repository, do some work, build the docker image, and push the new image to Artifactory. See below for the pipeline definition. At this time I have all stages up to the artifactory stage (the one that pushes to Artifactory) working. The artifactory stage exits with error with the following output:
waiting for docker to come up...
sha256:c6039bfb6ac572503c8d97f42b6a419b94139f37876ad331d03cb7c3e8811ff2
The push refers to repository [artifactory.server.com:2077/base/golang/alpine]
a4ab5bf94afd: Preparing
unauthorized: The client does not have permission to push to the repository.
This would seem straight-forward as an Artifactory permissions issue, except that I've tested locally with the docker cli and am able to push using the same user/pass as specified within destination_username and destination_password. I double checked the credentials to make sure I'm using the same ones and find that I am.
Question #1: is there any other known cause for getting this error? I've scoured the resource github page without finding anything. Any ideas why I may be getting the permissions error?
Without having an answer to the above question, I'd really like to dig deeper into troubleshooting the problem. To do so I use fly hijack to get a shell in the corresponding container. I notice that docker is installed on the container, so next step I think would be to do a docker import on the tarball for the image I'm trying to push and then perform a docker push to push it to the repo. When attempting to run the import I get the error:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is
the docker daemon running?
Question #2: Why can't I use docker commands from within the container? Perhaps this has something to do with the issue I'm seeing with pushing to repo when running the pipeline (I don't think so)? Is it because the container isn't running with privilege? I thought that the privileged argument would be supplied in the resource type definition, but if not, how can I run with privilege?
resources:
- name: image-repo
type: git
source:
branch: master
private_key: ((private_key))
uri: ssh://git#git-server/repo.git
- name: artifactory
type: docker-image
source:
repository: artifactory.server.com:2077/((repo))
tag: latest
username: ((destination_username))
password: ((destination_password))
jobs:
- name: update-image
plan:
- get: image-repo
- task: do-stuff
file: image-repo/scripts/do-stuff.yml
vars:
repository-directory: ((repo))
- task: build-image
privileged: true
file: image-repo/scripts/build-image.yml
- put: artifactory
params:
import_file: image/image.tar
Arghhhh. Found after much troubleshooting that the destination_password wasn't being picked up properly due to special characters and a lack of quotes. Fixed the issue by properly setting the password within yaml file being included with the --load-vars flag.
I'm setting up SBT on our buildserver (bamboo) for multiple buildagents. For this I created for each agent a separate directory which contains the agent specific config and the .ivy home to make sure agent isolation is fullfilled.
The build itself is call like this:
/sbt-launcher-packaging-0.13.13/bin/sbt -java-home /usr/lib/jvm/jdk1.7.0_79 -Dsbt.override.build.repos=true -Dsbt.repository.config=/data/bamboo/localbuildagents/${bamboo.agentId}/sbt/sbt.conf -Dsbt.ivy.home=/data/bamboo/localbuildagents/${bamboo.agentId}/.ivy2 clean compile dist
The credentials (basic realm) are store under the user home which is starting the bamboo server (~/.sbt/.credentials and ~/.sbt/0.13/plugins/credentials.sbt)
Each sbt.conf contains the agent-specific repos e.g the agent specific local maven repo and urls for the remote artifactory.
[repositories]
local-buildagent-mvn: file:///data/bamboo/home/.m2/AGENT-xxxxxxxx/repository/
ivy-release: http://xxx/artifactory/ivy-release/, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
mvn-release: http://xxx/artifactory/libs-release/
mvn-snapshot: http://xxx/artifactory/libs-snapshot/
[ivy]
ivy-home: file:///data/bamboo/localbuildagents/xxxxxxxx/.ivy2/
I'm encountering login problems while sbt is checking the remote artifactory repos (first http error 401 and then surprisingly 403). A curl with the same credentials and repo url is working as expected (first 401 and then 200).
I guess, that if -D switches are used for sbt startup, the credentials are not considered. I'm really stuck any advise warmly welcome...
From your question I don't see if you specified where your credentials are defined. In case you didn't do it, you must add something like this to your build definition (documentation):
// inline
credentials += Credentials("Some Nexus Repository Manager", "my.artifact.repo.net", "admin", "admin123")
// file
credentials += Credentials(Path.userHome / ".ivy2" / ".credentials")
I am coding a Java project and I'm automating the build and the publishing to JFrog Artifactory using SBT.
Whenever it's time to publish to Artifactory I want to do it using the Ivy directory layout and obviously publish the Ivy XML file along with the jar. I managed to achieve this by using the following lines in the build.sbt file:
crossPaths := false
publishTo := Some("Artifactory Realm" at "http://<Artifactory IP>:<Artifactory Port>/artifactory/org.project.my")
credentials += Credentials(Path.userHome / ".ivy2" / ".credentials")
publishMavenStyle := false
However it only works when anonymous users are allowed to deploy into Artifactory. I realized that sbt is not really passing my credentials to Artifactory but, instead, logging in as anonymous.
My $HOME/.ivy2/.credentials file looks like this:
realm=Artifactory Realm
host=http://<Artifactory IP>:<Artifactory Port>/artifactory/org.project.my
user=<my user name>
password=<my user name>
However, if I change the Artifactory configuration in order to prevent anonymous users from deploying new Artifacts, when I run "sbt publish" I get the following output:
[error] Unable to find credentials for [Artifactory Realm # <Artifactory IP>].
java.io.IOException: Access to URL http://<Artifactory IP>:<Artifactory Port>/artifactory//org.project.my/org/project/my/project-my/1.0.0/project-my-1.0.0.jar was refused by the server: Unauthorized
The Artifactory request.log file then contains:
20160219011657|319|REQUEST|10.0.2.2|anonymous|PUT|/org.project.my/org/project/my/project-my/1.0.0/project-my-1.0.0.jar|HTTP/1.1|401|24978
I have also tried passing the credentials manually instead of using a file:
credentials += Credentials("Artifactory Realm", "localhost", "<USERNAME>", "<PASS>")
But I am getting the same result.
Any idea what I might be missing?
try:
host=<Artifactory IP>
old answer (doesn't work):
host=<Artifactory IP>:<Artifactory port>
I had a different problem: I had the wrong realm set on my .credentials file.
Looking at the error output from sbt, I was able to figure out that I should use:
realm=Artifactory Realm
Error shows the expected values for realm and host:
[error] Unable to find credentials for [Artifactory Realm # myhost].
As part of our chef infrastructure I'm trying to set up and configure a berks-api server. I have created an Ubuntu server in azure and i have bootstrapped it and it appears as a node in my chef-server.
I have followed the instructions at github - bekshelf-api installation to install the berks-api via a cookbook. I have run
sudo chef-client
on my node and the cookbook appears to have been run successfully.
The problem is that the berks-api doesn't appear to run. My Linux terminology isn't great so sorry if I'm making mistakes in what I say but it appears as if the berks-api service isn't able to run. If I navigate to /etc/service/berks-api and run this command
sudo berks-api
I get this error
I, [2015-07-23T11:56:37.490075 #16643] INFO -- : Cache manager starting...
I, [2015-07-23T11:56:37.491006 #16643] INFO -- : Cache Builder starting...
E, [2015-07-23T11:56:37.493137 #16643] ERROR -- : Actor crashed!
Errno::EACCES: Permission denied # rb_sysopen - /etc/chef/client.pem
/opt/berkshelf-api/v2.1.1/vendor/bundle/ruby/2.1.0/gems/ridley-4.1.2/lib/ridley/client.rb:144:in `read'
/opt/berkshelf-api/v2.1.1/vendor/bundle/ruby/2.1.0/gems/ridley-4.1.2/lib/ridley/client.rb:144:in `initialize'
If anyone could help me figure out what is going on, I'd really appreciate it. If you need to explain the setup any more let me know.
It turns out I misunderstood the configuration of the berks-api. I needed to get a new private key for my client (berkshelf) from manage.chef.io for our organization. I then needed to upload the new key (berkshelf.pem) to /etc/berkshelf/api-server and reconfigure the berks-api to use the new key. so my config for the berks-api now looks like below:
{
"home_path":"/etc/berkshelf/api-server",
"endpoints":[
{
"type":"chef_server",
"options":
{
"url":"https://api.opscode.com/organizations/my-organization",
"client_key":"/etc/berkshelf/api-server/berkshelf.pem",
"client_name":"berkshelf"
}
}
],
"build_interval":5.0
}
I couldn't upload berkshelf.pem directly to the target location, i had to upload it to my home location, then copy it from within linux.
Having done this, the service starts and works perfectly.
I am trying to create an OpenShift application using the --from-code option to grab the application code from GitHub. I've created two different OpenShift QuickStarts -- with one, the --from-code option works, and with the other, it doesn't work.
So clearly I'm doing something wrong in the QuickStart that isn't working. But I can't see what I'm doing wrong. I either get error 504 or an error occurred, neither of which tells me what the problem is, and there doesn't seem to be a verbose flag to get more details on the error.
Tests-Mac:~ testuser$ rhc app create sonr diy-0.1 http://cartreflect-claytondev.rhcloud.com/reflect?github=smarterclayton/openshift-redis-cart --from-code https://github.com/citrusbyte/SONR.git
The cartridge 'http://cartreflect-claytondev.rhcloud.com/reflect?github=smarterclayton/openshift-redis-cart' will be downloaded and installed
Application Options
-------------------
Domain: schof
Cartridges: diy-0.1, http://cartreflect-claytondev.rhcloud.com/reflect?github=smarterclayton/openshift-redis-cart
Source Code: https://github.com/citrusbyte/SONR.git
Gear Size: default
Scaling: no
Creating application 'sonr' ... Server returned an unexpected error code: 504
Tests-Mac:~ testuser$ rhc app create sonr diy-0.1 http://cartreflect-claytondev.rhcloud.com/reflect?github=smarterclayton/openshift-redis-cart --from-code https://github.com/citrusbyte/SONR.git
The cartridge 'http://cartreflect-claytondev.rhcloud.com/reflect?github=smarterclayton/openshift-redis-cart' will be downloaded and installed
Application Options
-------------------
Domain: schof
Cartridges: diy-0.1, http://cartreflect-claytondev.rhcloud.com/reflect?github=smarterclayton/openshift-redis-cart
Source Code: https://github.com/citrusbyte/SONR.git
Gear Size: default
Scaling: no
Creating application 'sonr' ...
An error occurred while communicating with the server. This problem may only be temporary. Check that you have correctly specified your
OpenShift server 'https://openshift.redhat.com/broker/rest/domain/schof/applications'.
Tests-Mac:~ testuser$
That's creating an application with --from-code using this repo: https://github.com/citrusbyte/SONR . If I use this repo it works flawlessly: https://github.com/citrusbyte/openshift-sinatra-redis
The code itself seems to be good, as I can create an empty new application, merge the SONR code in, and it works flawlessly.
What am I doing wrong?
UPDATE: I've worked around this issue by creating the app in two stages instead of doing it in one stage:
rhc app create APPNAME diy-0.1 http://cartreflect-claytondev.rhcloud.com/reflect?github=smarterclayton/openshift-redis-cart
cd APPNAME
git remote add github -f https://github.com/citrusbyte/SONR.git
git merge github/master -s recursive -X theirs
git push origin master
I'd still love to know why doing it in one step was failing, though.
#developercorey had the right idea.
I tried with a ridiculous timeout of 99999, and then got a different timeout error that I don't think I can change:
$ rhc app create APPNAME diy-0.1 http://cartreflect-claytondev.rhcloud.com/reflect?github=smarterclayton/openshift-redis-cart --from-code https://github.com/citrusbyte/SONR.git --timeout 99999
...
Creating application 'APPNAME' ...
The initial build for the application failed: Shell command '/sbin/runuser -s /bin/sh 5328a9385973ca70150002af -c "exec /usr/bin/runcon 'unconfined_u:system_r:openshift_t:s0:c5,c974' /bin/sh -c \"gear postreceive --init >> /tmp/initial-build.log 2>&1\""' exceeded timeout of 229
The fix I mentioned in my earlier update is working perfectly, and that's what I recommend anyone with a similar problem try -- I'm creating the app as empty without the --from-code option, and then merging in the code I wanted to use in a separate step:
rhc app create APPNAME diy-0.1 http://cartreflect-claytondev.rhcloud.com/reflect?github=smarterclayton/openshift-redis-cart
cd APPNAME
git remote add github -f https://github.com/citrusbyte/SONR.git
git merge github/master -s recursive -X theirs
git push origin master
It could be that the application takes to long to clone/setup, and the creation is timing out. Something you can try is to create the application without the --from-code, then clone it locally, and merge in your code from github, then do a git push. This operation has a much longer timeout period, and will also let you see what, if any, errors that you get since the application won't disappear if it doesn't succeed, unlike an app create.