Error:
Failed to connect to repository : Command "/usr/bin/git ls-remote -h file:///home/myuser/path/to/project HEAD" returned status code 128:
stdout:
stderr: fatal: 'home/myuser/path/to/project' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
I have tried the following:
chmod 777 to the repo folder(folder containing .git directory)
chowned to jenkins:jenkins on the repo folder
tried to clone into another folder from this local repo folder: this works!
When I run the above command: /usr/bin/git ls-remote -h file:///home/myuser/path/to/project HEAD on cmd I get the branches.
My questions are:
why is git ls-remote -h ... command called when it should be git clone ...?
How to configure jenkins git plugin to fetch code from local repo
My environment:
RHEL 5.9
Jenkins 1.519 installed as a service(no Web container)
Git plugin
When installing Jenkins as a service, by default, Jenkins does not create a user directory as in: /home/jenkins. Jenkins default home directory is set to /var/lib/jenkins. From my work-around, as you would expect, jenkins has trouble accessing local resources from other users directory.
I moved my cloned repo under Jenkins default home directory i.e. under /var/lib/jenkins so my Repository URLin Jenkins Project configuration looks like: file:///${JENKINS_HOME}/repo/<myprojectname>
UPDATE:
The above works fine ...but I found a better way to do it from this blog
The steps are outlined here:
look up /etc/init.d/jenkins script. There are a few $JENKINS variables defined
. This should lead you to the sysconfig for jenkins i.e. /etc/sysconfig/jenkins.
Stop your jenkins instance:
sudo /sbin/service jenkins stop
Take a backup
cp /etc/sysconfig/jenkins /etc/sysconfig/jenkins.bak
In this file, change the following property:
$JENKINS_USER="<your desired user>"
Change ownership of all related Jenkins directories:
chown -R <your desired user>:<your user group> /var/lib/jenkins
chown -R <your desired user>:<your user group> /var/cache/jenkins
chown -R <your desired user>:<your user group> /var/log/jenkins
Restart jenkins and that error should disappear
sudo /sbin/service jenkins start
This error should go away now!
It's been a while since this question was asked, but I had this problem today and there are very few resources. Most probably, because people tend to connect to git repositories remotely.
I checked using strace what exactly jenkins was doing and yes, it was a problem with permissions.
But I solved it in a simpler way than answer #2 - by adding jenkins to the git server group - in my case, git1:
root# gpasswd -a jenkins git1
root# service jenkins restart
I'm running Jenkins on Windows and had the same problem. I was able to solve this by having the Jenkins service log in as my user on my laptop.
(Windows 7)
Open Task Manager (Ctrl + Shift + Escape)
(Windows 10 only) Click on More Details in the lower left corner of the pop up window
Go to the Services tab
Click the Services... button
Find "Jenkins" in the list of services
Right-click "Jenkins" and click on Properties
Click the Log On tab in the Jenkins Properties window
Choose This account: under Log on as:
Enter your username and password
Click OK
Restart the Jenkins service
Then Bob's your uncle.
Jenkins uses git clone command only for the first time when a workspace is configured for a project. Further instances uses the git ls-remote command.
I had the same issue when I configured Jenkins. It was resolved by playing around with the SSH Keys. This looks like a configuration issue as well. Check if SSH Keys are setup for the Jenkins account.
Also, see the step by step procedure of configuration of SSH in the link provided. This might not give you exact solution, but can point you to the solution.
http://oodlestechnologies.com/blogs/How-to-setup-Jenkins-With-Grails-on-Ubuntu
I find that the other solutions are a bit "hacky" for me. What I did was move the Jenkins Home folder from /Users/Shared/ to /Users/[myacccount]/. This way, my Jenkins will have access to my repos and to my Android SDK (because that's where I use Jenkins for). Then change the JENKINS_HOME environment variable. I did this by entering the JENKINS_HOME in my .bash_profile (but there are other ways to do this).
Note: I use OSX
Instead of file:/// you can also use ssh:// as in this answer:
ssh://YOUR_USER#localhost/PATH_TO_YOUR_PROJECT
Note that you need to do the standard ssh setup:
Generate a keypair using ssh-keygen if you don't already have one in ~/.ssh
Paste private key (default ~/.ssh/id_rsa) into Jenkins (project settings, git repo, credentials)
Paste public key into ~/.ssh/authorized_keys
Related
The title is general, but I have more specific questions. I am deep in a permissions nightmare trying to set up a "push-to-deploy" system using Git.
From my local machine, I push by SSH to the server (Ubuntu 14.04). I have the server set up as the remote
git remote add development devuser#development.server:/home/dummyuser/bare/repo.git
This bare repository is within the home folder of a dummy user dummyuser that we use to handle deployment tasks. devuser is my own account on the development server.
I have a post-receive hook set up within the remote repository (development.server:/home/dummyuser/bare/repo.git/hooks/post-receive) that's intended to deploy files via git checkout to a web server directory on the same server, call it webfolder/. That folder currently has permissions
drwxr-xr-x dummyuser www-data webfolder/
where www-data is the group associated with the Apache user.
If I have the post-receive hook script use the command
git --work-tree=/var/www/webfolder --git-dir=/home/dummyuser/bare/repo.git checkout -f
I get errors that it can't write to webfolder/, which is predictable since I assume the script is running as me (devuser) since I did the instigating push via SSH, and devuser doesn't have any permissions on webfolder/.
However, if I change the script to act as dummyuser,
sudo -u dummyuser git --work-tree=/var/www/webfolder --git-dir=/home/dummyuser/bare/repo.git checkout -f
just to see what happens, I have the error
warning: unable to access '/home/devuser/.config/git/attributes': Permission denied
There's a couple of things I don't understand about this:
1) Neither /home/devuser/.config/ nor /home/dummyuser/.config/ exist. That's fine, but if Git needs to access a .config/ folder, why wasn't it complaining before when I was setting up bare repos and executing hooks as devuser?
2) Now that I'm trying to act as dummyuser, why is Git looking in ~devuser/ for a .config/ folder? Why isn't it looking in ~dummyuser/?
I've been working on this tiny slice of one single problem in the maddening shitshow that is "using Git" for coming up on four hours now, and my brain is fuzzy, so please use small words.
The problem is something involving sudo -u dummyuser not setting the environment variables that Git expects. If I add HOME=/home/dummyuser to the post-receive hook, the deployment works as expected.
If anyone can provide more details about what's happening or a better solution, write it as an answer and I'll accept it. Couple of notes:
dummyuser doesn't have a login, so using sudo -iu dummyuser in the post-receive script won't work
After setting HOME=/home/dummyuser manually and successfully executing the script, I find that echo $HOME from the terminal returns /home/devuser, so there's no permanent change to $HOME
After successfully executing the hook script, neither ~devuser/ nor ~dummyuser/ nor /root/ have a .config/ folder. So... I still have no idea why Git was hung up on it.
Git expects a .config folder in the user's home directory. If $HOME isn't set correctly, e.g. if it points to a different user's home, Git will try to access $HOME/.config, not knowing that it actually doesn't even exist. However, since the user, and thus Git, doesn't have access to that $HOME, you will receive an error saying Permission denied.
To test that, try to run as dummyuser:
[ -d /home/devuser/.config ] && echo '.config exists!'
You're trying to test if the directory /home/devuser/.config exists. However, since you don't have the needed permissions, you get Permission denied, and you still don't know whether the directory exists or not.
Instead of setting $HOME manually, you could possibly use -H or --set-home:
sudo -Hu dummyuser git --work-tree=/var/www/webfolder --git-dir=/home/dummyuser/bare/repo.git checkout -f
I have a jenkins running on my local centos machine.
I have configured my local jenkins and was able to run a successful local build .
Now, i want to run remote tests which are python scripts on a remote centos machine which is not having jenkins installed. also, i dont want to install any jenkins process on the remote linux system as it is "like a" production server and am advised not to install any apps on it.
How do i use my local jenkins to run a build to execute those remote tests and report/output on my local jenkins console.
Do i need to use jenkins master-slave architecture ? if yes, how do i configure that given my above requirement.
You might want to have a look at this:
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds
for you req, precisely this part:
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-Launchslaveagentheadlessly
However, i believe you still have to have java on your slave unix node to run the slave.jar on it
This answer is assuming the scripts are in GitHub. May it helps to think in your case.
So.. First you need to install Git in you server machine by:
$ sudo apt-get update
$ sudo apt-get install git
Now you need to get the path of Git by $ which git
it will give like "/usr/local/bin/git"
copy that path into ManageJenkins->Global Tool Configuration-> in the git section, paste into "Path to Git executable".
it will allows you to access git sources.
Now you need to provive SSH keys.
Type sudo su- jenkins in you remote machine.You have to generate ssh key for "jenkins" user.
Now add public key to GitHub account(You can see https://www.youtube.com/watch?v=Vi-WqFKYpnw).
and add the private key to Jenkins by
Go to Credentials
Click in Global in Stores scoped
Add Credentials
Kind: SSH Username with private key
Username: your server username
Private Key: give the private key of user "Jenkins"
Specify ID as "jenkins-private-key" or anything else to identify
Now
Go to job configuration->select credentials that you have created and
Copy the ssh url of repository(Where you scripts are stored) Now you can run the scripts which are stored in Git.
I have done the following steps to setup ssh deployment keys with our git repo for it to be able to git pull without a username and password:
Note: I am on AWS EC2 / Ubuntu 14.04.3
Run ssh-keygen -t rsa -b 4096 -C "ownersEmail#gmail.com" these are then saved as id_rsa and id_rsa.pub in ~/.ssh/
The deployment public key (id_rsa.pub) is added on the GitHub online UI in the deployment keys section
The directory is already cloned in /var/www/ directory, this is working all good via HTTPS for pulling
Try sudo git pull git#github.com:ownersUsername/OurRepo.git and get the following error
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Another Note: This repository is private under another users account.
Also, when I try ssh git#github.com I get:
Hi userName/Repo! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.
And the deployment key comes up as being used. Have been on this issue for greater than 4 hours now and any would would be very much appreciated, thanks.
The problem is you're using sudo, which runs the command as root, and it will try to use the root's keys not your user's keys.
What you want to do is:
give your user/group write access to /var/www
run the pull/clone as the user, not the root user.
When you do a git pull you don't need the link.
git pull <remote> <branch>
You need the full url for the clone command
sudo git clone git#github.com:ownersUsername/OurRepo.git
To test if your ssh key is good use this:
git fetch --all --prune
I've installed GitLab on Google Compute Engine using "Click to Deploy" from the project interface. The deployment is successful after a few minutes. I can SSH into the instance, and muck around with it as expected.
I can also log in to GitLab using the web interface, and add SSH keys to my profile. So far, so good. However, when I attempt to push or pull to a new example repository, I receive this message:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I've removed my local SSH config so it doesn't interfere. Do I need to setup an SSH tunnel of some sort? What am I missing?
UPDATE: Wiping out my local ~/.ssh folder, and regenerating an SSH key (which I've added to my profile in GitLab) produces the following error:
Received disconnect from {GITLAB_IP_ADDRESS}: 2: Too many authentication failures for git
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
UPDATE 2: It seems GitLab may already have a solution: run sudo gitlab-ctl reconfigure. See here: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#git-ssh-access-stops-working-on-selinux-enabled-systems
You need to create an SSH tunnel to communicate with GitLab.
1. Log into your development server as your user, and create a key.
ssh-keygen -t rsa
Follow the steps, and create a passcode (that you can remember) as you'd need this to pull and push code from/to GitLab.
2. Now that you've created your key, we can copy it;
cat id_rsa.pub
Copy the output of that command (including ssh-rsa), and add it to your GitLab profile. (http://my-gitlab-server.com/profile/keys/new).
3. Ensure you have the correct privilege to the project(s)
Ensure you are at role developer at the very least. (Screengrab of roles: http://i.stack.imgur.com/DSSvl.jpg)
4. Now, copy the project link
Go into your project, and find the SSH link in the top right;
5. Now back to your development server
Navigate to your directory where you'd like to work, and run the following;
$ git init
$ git remote add origin <<project_url>>
$ git fetch
Where <<project_url>> is the link we copied in step 4.
You will be prompted your password (this is your ssh key password, not your server password) and to add the host to your known_hosts file. After that, the project will start to download and you can enjoy development.
I did these steps on a CentOS 6.4 machine with Digital Ocean. But they shouldn't differ from using Google CE.
Edit
Quote from Marty Penner answer as per this comment
Solved it! Thanks to #sxleixer and #Alexander Wenzowski for figuring this out.
Apparently, SELinux was interfering with a non-standard location for the .ssh directory. I needed to run the following commands on the Compute Engine instance:
sudo yum -y install policycoreutils-python # Install the `semanage` tool
sudo semanage fcontext -a -t ssh_home_t "/var/opt/gitlab/.ssh/authorized_keys" # Allow the nonstandard ssh_home_t
See the full thread here:
Google Cloud Engine. Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
Solved it! Thanks to #sxleixer and #Alexander Wenzowski for figuring this out.
Apparently, SELinux was interfering with a non-standard location for the .ssh directory. I needed to run the following commands on the Compute Engine instance:
sudo yum -y install policycoreutils-python # Install the `semanage` tool
sudo semanage fcontext -a -t ssh_home_t "/var/opt/gitlab/.ssh/authorized_keys" # Allow the nonstandard ssh_home_t
See the full thread here:
Google Cloud Engine. Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
UPDATE: It seems GitLab may already have a solution: run sudo gitlab-ctl reconfigure. See here: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#git-ssh-access-stops-working-on-selinux-enabled-systems
In my situation the git user wasn´t set up completely. If you get in your log files messages like "User git not allowed because account is locked" (Under Centos or Redhat it´s /var/log/secure) than you simply need to activate the user via "passwd -d git"
I have this problem when i try to push in git:
error: insufficient permission for adding an object to repository database ./objects
fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://<repo url>/<repo dir>
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'ssh://<repo url>/<repo dir>'
I've had this before sporadically and we've always had to solve it by each user sshing to the repo and setting group permissions on all the files therein with
chmod -R g+w *
This was never a satisfactory solution and now it's bitten us in the arse as one of the guys is away and no-one knows his repo user's password. So, i'm trying to solve it properly.
The error seems to occur when someone tries to push up a change that will alter a repo dir that is owned by another user (hence setting the group write option above). I've done a bit of googling around this and have found a couple of solutions being discussed (neither of which worked for me)
1) make sure that the group that the repo dirs are shared with is each users' primary group (i believe that is the case already: each user has only one group so that must be their primary group, right?)
2) git repo core.sharedRepository setting, as detailed here: Git: Can't push from one computer
I changed this but it didn't make any difference. Do i need to reload the config or something to actually effect the change?
Here's what my repo config looks like atm:
[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedRepository = all
[receive]
denyNonFastForwards = True
Grateful for any advice or suggestions!
max
I had this error for two weeks, and the majority of the solutions stated 'chmod -R' as the the answer, unfortunately for me my git repos (local / remote / shared - with team) were all on Windows OS, and even though chmod -Rv showed all the files changed to 'rwxrwxrwx', a subsequent 'ls -l' still showed all files as 'rwxr-xr-x' and the error repeated itself. I eventually saw this solution by Ariejan de Vroom. It worked and we were all able to pull and push again.
On both local (the local that is having trouble pushing) and remote repos, run the following commands:
$ git fsck
$ git prune
$ git repack
$ git fsck
On a side note, I tried using Windows' native file permissions / ACL and even resorted to elevating the problem user to Administrator, but none of that seemed to help. Not sure if the environment is important, but it may help someone with a similar setup - problem team member and remote (Windows Server 2008 R2 Standard), my local (Windows 7 VM).
A simpler way to do this is to add a post-receive script which runs the chmod command
after every push to the 'hub' repo on the server. Add the following line to hooks/post-receive inside your git folder on the server:
chmod -Rf u+w /path/to/git/repo/objects
It is a permission error. The way that was most appropriate and secure for me was adding users to a supplementary group that the repo. is owned by (or vice versa):
groupadd git
chgrp -R git .git
chgrp -R git ./
usermod -G -a git $(whoami)
In case anyone else is stuck with this: it just means the write
permissions are wrong in the repo that you’re pushing to. Go and chmod
-R it so that the user you’re accessing the git server with has write access.
For me, this error occurred when I was out of space on my remote.
I just needed to read the rest of the error message:
error: file write error (No space left on device)
fatal: unable to write sha1 file
error: unpack failed: unpack-objects abnormal exit
For the permission error using git repository on AWS instance, I successfully solved it by creating a group, and assigning it to the repository folder recursively(-R), and give the written right to this group, and then assign the default aws instance user(ec2-user or ubuntu) to this group.
1. Create a goup name share_group or something else
sudo groupadd share_group
2. change the repository folder from 'root' group to 'share_group'
sudo chgrp -R share_group /path/to/your/repository
3. add the write authority to share_group
sudo chmod -R g+w /path/to/your/repository
4. The last step is to assign current user--default user when login (by default ec2 is 'ec2-user', user of ubuntu instance is 'ubuntu' in ubuntu on aws) to share_group. I am using ubuntu insance on aws, so my default user is ubuntu.
sudo usermod -a -G share_group ubuntu
By the way, to see the ownership of the folder or file just type:
ls -l /path/to/your/repository
'
Output:
drwxr-x--x 2 root shared_group
(explanation please see:https://wiki.archlinux.org/index.php/File_permissions_and_attributes).
After step 3, you will see
drwx--x--x 2 root root
changed to
drwxr-x--x 2 root share_group
In this case, I did not assign user 'ubuntu' to root group, for the consideration of security. You can just try to assign you default user to root according to step 4 (just skip the first 3 steps
In another way, tried the solution by :
chmod -Rf u+w /path/to/git/repo/objects
It did not work for me, I think it should be the reason that my repository folder belong to the root user, not to Ubuntu user, and 'git' by default use the default user(ec2-user or Ubuntu user. You can try to change the user and test it.
Finally, below code definitely work for me, but 777 is not good for security
sudo chmod -R 777 /path/to/your/repo
I use gitosis for managing this kind of stuff. Gitosis has a single user (usually called "git") that owns all the repositories, and it uses public-key-based access control to each repo. It might not suit your setup but is probably worth checking out (no pun intended).
This problem can also occur after Ubuntu upgrades that require a reboot.
If the file /var/run/reboot-required exists, do or schedule a restart.
I was getting similar error and please see below how I resolved it.
My directory structure:
/opt/git/project.git
and git user is git
$ cd /opt/git/project.git
$ sudo chown -R git:git .
chown with -R option recursively changes the ownership and and group (since i typed git:git in above command) of the current directory. chown -R is necessary since git changes many files inside your git directory when you push to the repository.
I was having trouble with this too, thinking my remote gitolite-admin was corrupted or something wrong.
My setup is Mac OS X (10.6.6) laptop with remote Ubuntu 10 server with gitolite.
It turned out that the problem was with my local checkout of gitolite-admin.
Despite the "unpack failed" error, it turned out the the problem was local.
I figured this out by checking it out again as gitolite-admin2, making a change, and the pushing.
Voila! It worked!
For what it worth, I had the same problem over my own VPS and it was caused by my low hard disk space on VPS. Confirmed by df -h command and after i cleaned up my VPS' hard disk; the problem was gone.
Cheers.
Where I work we have been using this method on all of our repositories for a few years without any problems (except when we create a new repository and forget to set it up this way):
Set 'sharedRepository = true' in the config file's '[core]' section.
Change the group id of the repository to a group shared by all users who are allowed to push to it:
chgrp -R shared_group /git/our_repos
chmod -R g+w /git/our_repos
Set the setgid bit on all directories in the repository so that new files/directories keep the same group:
find /git/our_repos -type d -exec chmod g+s {} +
Add this line to the pre-receive hook in the repository to ensure new file permissions allow group read/write:
umask 007
For me its a permissions issue:
On the git server run this command on the repo directory
sudo chmod -R 777 theDirectory/
A git configuration mistake can also product this error. I give my students and example of configuration like this:
git config --global user.name "John Doe"
git config --global user.email johndoe#example.com
One of my students was getting the unpacker error. Other students were fine, but I still did a double check on the git server's permissions and to be sure the student was in proper group.
Finally, I had the student do a git log and saw that he had John Doe for his configuration, but his branch was his own name.
Setting up his configuration properly eliminated the error .
I had similar problem like this before:
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'https://mywebsite.com/my-git-directory.git'
In my case, I have checked wrong directory ownership with ls -l. I change the directory owner to www-data to solve the problem like this:
sudo chown -R www-data:www-data my-git-directory.git/
But in this case I not use SSH method, I use HTTP method.
Maybe when we make sure the directory owner is correct, it can solve the problem.