Dirk.Net

The repo info is here (click and expand that page’s silly javascript widgets), so for OpenSuse 11.4 (use sudo for all commands that need it):

zypper addrepo http://download.opensuse.org/repositories/home:elvigia/openSUSE_11.4/home:elvigia.repo

zypper refresh

zypper install gitosis

Then continue as outlined here, slightly adjusted for OpenSuse with user creation:

groupadd git

useradd git -d /home/git -c ‘git version control’ -s /bin/sh -g git -r -m

sudo -H -u git gitosis-init < /tmp/id_rsa.pub

Then just proceed with

git clone git@YOUR_SERVER_HOSTNAME:gitosis-admin.git

on your local machine etc. etc.

To host your private gems you have several options. The cheapest and most scalable solution will likely be to run your own gitosis server. Then you build your gems as described in this railscast and push them up to your gitosis repo. But how to deploy and install these gems when the gem is updated?

Installing a gem from Git involves four steps:

1. Clone the Git repository.
2. Change to the new directory.
3. Build the gem.
4. Install the gem.

Git post-receive Hook

One way is to implement a Git post-receive hook. This hook is in the hooks directory of your repo, and it has to be edited on the server. You cannot edit a hook locally and push it to the remote server. So ssh into your remote server and create a hook named post-receive (with 755 permissions) to look as so (Update: because of a “Permission denied - /tmp/stdout.echoe” error rm has to be run with sudo and visudo permissions for the git user has to be extended to ALL):

#! /bin/sh
cd /home/git
unset GIT_DIR
sudo rm -rf mygem
git clone /home/git/repositories/mygem.git
cd mygem && sudo rake manifest && sudo rake build_gemspec && sudo rake install 

Be sure to have the following in your visudo on the remote server:

git ALL=NOPASSWD: ALL

That’s it. Very easy.

Of course you can now setup different remote servers and push to them as needed.

Capistrano

For rails you could use capistrano and run these task only when deploying a Rails project, by putting this into your deploy.rb fild:

namespace :gems do

desc “Install gem”
  task :install_mygem, :roles => :app do
    run “cd /home/git && sudo rm -rf mygem”
    run “git clone git@yourserver.com:mygem.git“
    run “cd /home/git/mygem && sudo rake manifest && sudo rake build_gemspec && sudo rake install”
  end

end

Hope it helps. If you have a simpler or more effective way, please post in the comments.

If you get

! [rejected] gh-pages -> gh-pages (non-fast forward)

when following the instructions to create a github project page, you might just try to delete the gh-pages branch

git push origin :gh-pages

and then push the gh-pages branch again

git push origin gh-pages

Hope it helps.

If you get errors such as

fatal: Out of memory, malloc failed
error: pack-objects died with strange error
error: failed to push some refs to ‘git@myserver.com:foo.git’

when running

git push

first, upgrade git to the latest version on both ends, then check if

git repack

still works. If not, you might have a local issue.

If repack still works, your remote server (the server you push to) might actually run out of memory, which can easily happen with for example smallish VPS slices. So, just increase your swap file as Linus suggests, like this and it might start working again. Hope it helps.

Update: Two hours after this post I discovered that the system clock on the remote server, just recently booked from my reliable hosting company, was off by about eight hours. On a server set up by them just a few days ago. Anyway, the clock issue might be the actual underlying reason for the failed authentication.  So check your clock and sync it. I guess the name of the lone horseman is Crystaltech. Duh.

Original post:

Ok, the title may be a bit harsh, but that’s how I felt at times over the last two days: Some evil forces slicing days out of my life without me getting much in return – besides learning a lot. 

So if you follow the instructions here and here  with perhaps a little sprinkling or CentOS you set up the most powerful web app deployment solution available today, a combination of your own git repository server (gitosis) and powerful deployment scripts (Capistrano). Then, after gitosis administration via gitosis-admin.git works like magic and cap deploy:setup runs without issues, you run cap deploy:cold.

And you need old git’s password?!! The gitosis user you’ve painstakingly set up without as password, i.e. the —disabled-password option (-r in CentOS), so who is positively devoid of a password, and you still get

 ** [myhost.com :: out]
 ** [myhost.com :: out] Permission denied, please try again.
 ** [myhost.com :: out] git@myhost.com’s password:
Password:
 ** [myhost.com :: out]
 ** [myhost.com :: out] Permission denied (publickey,gssapi-with-mic,password).
 ** [myhost.com :: out] fatal: The remote end hung up unexpectedly
    command finished

ad nauseam. And in your log (/var/log/secure for CentOS) you’ll have

Mar  1 04:27:25 HOST1 sshd[12653]: Postponed publickey for git from 210.11.11
.11 port 25409 ssh2
Mar  1 04:27:26 HOST1 sshd[12652]: Accepted publickey for git from 210.11.11.
11 port 25409 ssh2
Mar  1 04:27:30 HOST1 sshd[12657]: Accepted publickey for deploy from 210.11.1
1.11 port 25412 ssh2
Mar  1 04:28:15 HOST1 sshd[12663]: Failed password for git from 63.22.22.22
 port 34759 ssh2
Mar  1 04:28:16 HOST1 sshd[12663]: Failed password for git from 63.22.22.22
 port 34759 ssh2

where the 210.11.11.11 is the ip of your development machine, and 63.22.22.22 is the ip of your server running gitosis which is also the deployment target server (This ip-difference made me think of iptables, oh well.).

Now, before you mess with

• iptables
• ssh-agent
• sshd_config
• authorized_keys and .ssh permissions
• reinstalling and upgrading gitosis and other stuff

and anything else you might try, first, simply add

on :start do
    `ssh-add`
end

(mind the backquotes) to your deploy.rb file. And it might just start working. Here’s the solution, with the original suggestion here. I re-discovered it as I was calling it a night, closing one of the 132 Firefox tabs I had opened in this effort.

The issue is probably not Capistrano’s fault but has to do with the specific ssh setup on the server. I had no such problems with an Ubuntu slice as now on a dedicated CentOS, perhaps due to a more severe security lockdown on this “Enterprise” distro.  However, it didn’t make any difference for me if ssh-agent was running or if I had

default_run_options[:pty] = true

in my deploy.rb file or or or…. YMMV.