4

I have two issues. I have Ubuntu 10.10 and I have installed git server with gitolite tool. Everything worked quite good. The gl-setup command of gitolite created 2 repositories: gitolite-admin and testing.

1) QUESTION 1

My default gitolite admin user is called "git" and already created.

First, I had to clone the gitolite-admin repo, make some changes to let's say conf/gitolite.conf to add some new repo and a new user (I added the root user and I created and private/public key before and also added the public key to keydir folder), then I had to add/commit and push changes back.3

Info: I have my ~git/.ssh/authorized_keys file fine, starting with command= and having only one value - the public key of the git user I created first.

DIDN'T WORK:

git@vs1:~/$ git clone git@<<SERVER_IP>>:gitolite-admin.git
Initialized empty Git repository in /home/git/ga/gitolite-admin/.git/
git@<<SERVER_IP>>'s password:
fatal: 'gitolite-admin.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

WORKED:

touch ~/.ssh/config

with content:

host gitolite
     user git
     hostname <<SERVER_IP>>
     identityfile ~/.ssh/git.pub

git@vs1:~/$ git clone gitolite:gitolite-admin
Initialized empty Git repository in /home/git/ga/gitolite-admin/.git/
Enter passphrase for key '/home/git/.ssh/git.pub':
Enter passphrase for key '/home/git/.ssh/git.pub':
Enter passphrase for key '/home/git/.ssh/git.pub':
git@89.35.160.243's password:
remote: Counting objects: 23, done.
remote: Compressing objects: 100% (18/18), done.
remote: Total 23 (delta 4), reused 0 (delta 0)
Receiving objects: 100% (23/23), done.
Resolving deltas: 100% (4/4), done.

Why I didn't work at all the first variant? All the tutorials say that it should work without any problems. I had to use the second variant with creating that host configuration in ~/.ssh/config file. This is a bit frustrating. The repo path is /home/git/repositories and the ssh is default port 22.

2) QUESTION 2

Using user root on the same server, I created an empty folder in let's say /var/www/example.com/www. I ran git init, then added a file (.gitignore), ran git add -A and git commit -m "...".

Then I created the remote path for origin:

git remote add origin git@<<SERVER_IP>>:myrepo.git

I ran git push origin master and this is what I got:

fatal: 'myrepo.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

I tried various things to change, like putting the whole path to the repository (even I didn't see that nowhere, so it isn't correct) and I got:

Counting objects: 3, done.
Writing objects: 100% (3/3), 243 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: ENV GL_RC not set
remote: BEGIN failed--compilation aborted at hooks/update line 20.
remote: error: hook declined to update refs/heads/master
To git@<<SERVER_IP>>:/home/git/repositories/myrepo.git
 ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'git@<<SERVER_IP>>:/home/git/repositories/myrepo.git'

What I doing wrong? This is getting frustrating since for such basic task I experience this unusual difficulties. I have great experience with SVN, these are the first plays with GIT.

Thank you in advance for your help!

Valentin Tudor
  • 43
  • 1
  • 4

1 Answers1

1

Note for 1/: That could have worked if the identityfile was a default name (id_rsa.pub and id_rsa). Since it wasn't the case, a config file was mandatory.

Note for 2/ you have created a git repo, but did you let gitolite know about it?
You should declare the new repo in the config file of the gitolite-admin repo.

If you are pushing through ssh as root, that means that use has its own ~/.ssh/id_rsa(.pub) keys, and those keys were registered for Gitolite.

Note for repo paths: never use the full local path of a repo for the push/pull address: that would circumvent Gitolite completely.

A gazillon comments laters, it appears that:

  • all remote addresses should start with git@somehostname:arepo.git: you want your user to execute git commands on somehostname as 'git' (the account in charge of git and gitolite).
    That means the public key of 'myuser' needs to be registered on the somehostname:~git/.ssh/authorized_keys

  • any time an ssh connection doesn't go your way, you can start by looking those ssh debugging tips.
    For instance: ssh -vvv git:somehostname can go a long way to illustrate what is going on

  • if you want to avoid a config file, then you need to use the standard naming convention for those public/private keys (~myuser/.ssh/id_rsa, and ~myuser/.ssh/id_rsa.pub)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    1) Ok, but this is strange, all tutorials (almost) and even their documentation does not mention about the necessity of creating that ~/.ssh/config file to user git. Right now I cleaned up all the installation and reinstalled everything. I recreated the user "git" with no password since I think it's ok since we are using a private/public key login to ssh (and also using that ~/.ssh/authorized_keys file). And now, when I try to clone the gitolite-admin repo if tails because it keeps requested me a password (instead of using the public key). – Valentin Tudor Jan 28 '12 at 15:19
  • 2) Yes, the repo was created before, it is available in repositories folder and the user root was added to that repos with RW+ permissions. – Valentin Tudor Jan 28 '12 at 15:23
  • @ValentinTudor 1) should mean the ssh keys are somehow not found (wrong home, wrong path or wrong name): see http://sitaramc.github.com/gitolite/sts.html – VonC Jan 28 '12 at 21:45
  • @ValentinTudor 2) that error message (`fatal: 'myrepo.git' does not appear to be a git repository`) means that your pubkey (for root) is bypassing gitolite and going straight to a shell (again http://sitaramc.github.com/gitolite/sts.html#ssh_troubleshooting_common_ssh_problems_) – VonC Jan 28 '12 at 21:48
  • Thank you for your answer! 1) I resolved this by recreating the ~/.ssh/config file on user "git" and worked perfect the clone and all (I had to use either Host "gitolite" and use only git clone gitolite:gitolite-admin syntax OR use "somehostname" and use only git clone git@somehostname:gitolite-admin. I guess this is how it should be working. – Valentin Tudor Jan 28 '12 at 22:54
  • 2) I read these documentation you pointed. So this is the last problem. Let's say I have a user called "myuser" on the same machine which is both server/client. I created the new repo called "myrepo", added the user to the repo - all good. But when do cd somedir, git init, <>, git remote add origin myuser@somehostname:myrepo.git and git push origin master, it fails. So it bypasses the gitolite, it requests me the myuser@somehostname password (which is shouldn't, since I have a public key with the same name installed). What I do wrong? I have to deal again with the config file? – Valentin Tudor Jan 28 '12 at 23:02
  • I have to mention that user "myuser" is assigned successfully to repo "myrepo" (with RW+ permissions) and the public key myuser.pub was copied and pushed back on keydir folder, all the before trying to git init and push the first files to the newly created repo. – Valentin Tudor Jan 28 '12 at 23:09
  • @ValentinTudor that seems normal. You are asking Git to execute something in `somehostname` as `myuser`: as in `myuser@somehostname`. That is wrong. The only user authorized to perform any git command is the '`git`' user. `myuser` is authorized to perform git command as git on `somehostname` because his/her public key is registered in `somehostname:~git/.ssh/authorized_keys`. Your remote address should always start with `git@somehostname`. – VonC Jan 28 '12 at 23:12
  • @ValentinTudor The current `$HOME` (of `myuser`) will contain the id_rsa needed by the ssh transaction to complete (and by gitolite to authenticate you, allowing gitolite to perform its "authorization"). So again: **`git remote add git@somehostname:myrepo.git`** (as in, for instance, http://blog.tenak.net/2010/02/2010-02-gitolite_adding_new_repositories.html) – VonC Jan 28 '12 at 23:13
  • You are right, I should use git@somehostname:myrepo.git, thank you. I copied the id_rsa file (private key) - which is called here myuser - to the $HOME directory of myuser. So it is /home/myuser/myuser - the private key. I tried again to run git remote add origin git@somehostname:myrepo.git and git push origin master, then again the server requests me the git@somehostname's password this time. I'm kind of stuck. Should I add more stuff to the /home/git/.ssh/config file or this isn't the problem? – Valentin Tudor Jan 28 '12 at 23:21
  • Later edit: I also left a copy of the private key (the public is left there too) on ~/.ssh/id_rsa (which is actually myuser). This is the last step and I'm done. – Valentin Tudor Jan 28 '12 at 23:41
  • @ValentinTudor: "I copied the id_rsa file (private key) - which is called here `myuser` - to the `$HOME` directory of myuser. So it is `/home/myuser/myuser`": a ssh daemon will look for, by default, `~myuser/.ssh/id_rsa` (and `id_rsa.pub`). If you name those files otherwise, you need to specify it in a `config` file. If not, ssh will ask for a password because it doesn't find those public/private key files. – VonC Jan 28 '12 at 23:54
  • @ValentinTudor when an ssh session doesn't go your way, don't forget those ssh debug tips: http://stackoverflow.com/questions/922210/unable-to-git-push-master-to-github/922461#922461. In particular, `ssh -vvv git@somehostname` can go a long way to show you what actually happens. – VonC Jan 28 '12 at 23:56
  • Yes, you are right, I just figured the id_rsa thing just before, tried and it worked! Also, the debugging with -vvv is very helpful indeed. Thank you very much, I appreciate, you helped a lot and your answers were very detailed! Wish you all the best! – Valentin Tudor Jan 29 '12 at 00:12
  • @ValentinTudor: you are welcome. I have extracted a few key points from those comments and have edited my answer to make them more visible. – VonC Jan 29 '12 at 00:41