Sure you found already lots of guides on how to set up gitosis, but here I wanna focus on something I required as I wanted to use a ssh-key different from the usual ~/.ssh/id_rsa. As hardly any page mentioned how to do it, I thought I show the different ways to do so and how to install gitosis in general. So lets begin, I use for the guide a Ubuntu 10.04 LTS but switch package manager/package name and it should work on your Linux distro too, as the rest is the same as far as I can tell.
First off we start with installation of gitosis:
$# sudo apt-get install gitosis
Now we need a ssh-key. Unless you already prepared one, you can produce one like this on your local machine and upload it to the server via scp after you created it:
$# ssh-keygen -t rsa -C "admin@gitosis" -f ~/.ssh/gitosis_on_server
$# scp ~/.ssh/gitosis_on_server.pub master@myserver.de:/home/master/
I add here the “-f ” parameter of ssh-keygen, as this is the point which my installation guide wanna go on, specifically to use a ssh-keyfile that not have the usual name id_rsa. Feel free to change the filename to your like, and not forget to set the proper user/server etc. for scp 
. I will go on with the key called “gitosis_on_server”. The -C option is for setting the name we use later to refer to this specific key in the options.
That done we’re good for initializing gitosis master repository which will serve us as place for the auth-keys and configuration for the repository to come. To do so, we issue the following command on our server:
$# sudo -H -u gitosis gitosis-init < ~/gitosis_on_server.pub
That creates the master repository, and once that’s done we come to the interesting part. Now we either set the $GIT_SSH environment variable to a ssh command line that give your git the identify key, or like I did, edit our /etc/ssh/ssh_config a bit. Basically we define a hostentry and on the side we save us some typing that way later on, so I go here for this solution.
$# sudo nano /etc/ssh/ssh_config
Scroll down there until you reached the end, and then add the following (with your data added of course, only let the user stay as “gitosis”! :
Host gitosis-host
HostName myserver.com
IdentityFile ~/.ssh/gitosis_at_server
User gitosis
With that git knows when we give it the server gitosis-host that it should use the data from this entry in the ssh_config (also makes it easy for normal ssh connection, less typing). Anyway, back to gitosis. Now we clone the repository we just created to our local machine:
$# git clone ssh://gitosis-host/gitosis-admin.git
Then he ask you for the password for the ssh-key we created earlier (if you set one, and you should to improve security!). If you should encounter an error during this that’s like this:
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Then you most likely restricted ssh access on the server to specific groups/users, so add gitosis to the list of allowed users or add the gitosis user to the required group. If all went ok, then we can add new users/repositorys using the repository we just created. To do so, open the gitosis.conf in the folder we cloned and add entrys like this:
[group myrepo]
writable = myrepo
members = admin@gitosis
Then commit and push (!!). Do not forget the pushing, otherwise it don’t work and yea, I forgot it too and was quite irritated until I realized it. Once it’s pushed and so on the server, lets clone it and push some files into it.
$# git clone ssh://gitosis-host/myrepo.git
$# echo 'testing here' > testfile.txt
$# git add .
$# git commit -m 'adding testfile'
$# git push origin master
$# git push
So, now we want to add another user? No problem, just generate a new key with a different user@computer (here we do user1@desktop). Then we add it to the gitosis.conf in our admin repository clone like this:
[group myrepo]
writable = myrepo
members = admin@gitosis user1@desktop
And now we copy over the public keyfile. Pay attention, the public keyfile must be named like the user we just added plus “.pub”. The keyfile gets copied into/keydir/. In the example it looks like/keydir/user1@desktop.pub. That done, push it and you’re done. Now the new user can checkout it, and if thats you, just make another entry in the ssh_config, and then use the new host to clone it.
Hope I didn’t confuse you too much on the way. This guide uses parts from Ivan Kuznetsov’s guide, the help with the ssh came from the ssh manpage.
Today I learned a few things on postfix and how to set it up cleaner. So I want to share this insights with you, especially the part how to clean up the mail header since it helps a lot and improves your privacy quite a bit. So let’s get started, shouldn’t we ? Lets start by adding a limitation on the SASL authenticated clients which address they can to send out mail. This gets archived by setting up “smtpd_sender_login_maps =” and adding “reject_authenticated_sender_login_missmatch” to smtpd_recipient_restrictions, so he check the map we setup in smtpd_sender_login_maps and if the SASL authenticated client fails rejects the mail. The map is looking like this:
Today I read in the current issue of the 
