weirdly named ssh key files

[anarcat]

The ssh keys are not named correctly. It would make way more sense for the plugin to use the regular naming convention. This would alleviate the need for a special configuration and keys could just be generated with sudo -u www ssh-keygen instead of the current method of copying files around.

[kubitron]

Can you elaborate a bit? Which keys are you talking about?

[anarcat]

Oh sorry, the README says this:

cd REDMINE_ROOT
mkdir .ssh
cp [somewhere-or-other]/gitolite_admin_id_rsa     .ssh/gitolite_admin_id_rsa
cp [somewhere-or-other]/gitolite_admin_id_rsa.pub .ssh/gitolite_admin_id_rsa.pub

I would reverse that process: I would create the SSH keys for the redmine user and then put them in gitolite:

sudo -u redmine ssh-keygen
cp ~redmine/.ssh/id_rsa.pub ~gitolite/keydir/redmine.pub
vi ~gitolite/conf/gitolite.conf
git commit -m"add redmine admin to gitolite" ~gitolite

... or similar.

[kubitron]

Hello. One thing to note here, is that many (most?) configurations don't have a separate redmine user. (for instance, I just have an apache user, with my redmine installation in a directory configured in my httpd.conf file....).

[kubitron]

What if we recommend that one generates the key for the git user, then copies to the redmine directory?

i.e.

sudo -u git ssh-keygen
sudo -u git gl-setup ~git/.ssh/id_rsa.pub
cp ~git/.ssh/id_rsa REDMINE_ROOT/.ssh/gitolite_admin_id_rsa
cp ~git/.ssh/id_rsa.pub REDMINE_ROOT/.ssh/gitolite_admin_id_rsa.pub
chown -R www-data REDMINE_ROOT/.ssh
chmod 700 REDMINE_ROOT/.ssh
chmod 600 REDMINE_ROOT/.ssh/*

[anarcat]

the redmine user doesn't matter, in my opinion - you should just create a key for it, regardless of whether it's called "redmine" or "www-data", and then add it to gitolite. So I would say:

sudo -u www-data ssh-keygen
sudo -u git gl-setup ~www-data/.ssh/id_rsa.pub

Then this package should look for the SSH key in ~/.ssh/id_rsa.pub...

How could it be any simpler? :)

[kubitron]

The downside here is that the key is really associated with gitolite, not www-data (imagine 12 plugins to 12 different services, each of which has a key).

[anarcat]

No, it's not. A key is associated to the user, and added to gitolite. I don't see why different plugins should have different keys.

[kubitron]

I'm not disagreeing with your previous statement, just which user we are talking about. You are thinking of this as the "redmine" user. I think of the user as the "gitolite administrator". The reason I don't think of this as associated exclusively with redmine, is that I use this key to interact manually with the gitolite configuration. A number of users have asked that the redmine use of gitolite play nicely with other uses of the same gitolite repo, so I believe that they think of this key in that way as well.

I agree that more help for gitolite configuration should be in the README. I think that I am going to go with the view that this is the gitolite administrator key that we are generating. Postitive side-effect is that you can su to the git user and easily clone and modify the administrative configuration. Bottom line is that we need instructions that people can clearly follow, no? Since you are clearly a sophisticated user, you can configure things as you want. :-).

[kubitron]

Ok. Check out the new instructions on the README. In particular, step #1 and #4 of the "step-by-step configuration instructions" are now updated. It doesn't quite have the philosophical angle that you like, but it is still much better than what was there before...

[anarcat]

The problem here is that you are overriding the install instructions of gitolite, basically, yet still assuming that the user has installed gitolite in the first place.

When I installed this plugin, I had already installed gitolite, in fact it's what step #1 says: "Install gitolite.". :P Now when you install gitolite, it sets up an SSH key for you, using the gl-setup steps you outline. I feel those steps are confusing and duplicate the steps documented in the gitolite install instructions.

Plus they assume the gitolite admin is Redmine and that it's the only admin. I found it very useful (to say the least) to have a separate admin (myself!!) as being the owner of the gitolite install to diagnose issues with this plugin.

So i would suggest telling users the following:

1. install gitolite, no way around that - this includes running gl-setup with some key
2. create a key for redmine
3. add that key to the admin section of the gitolite config

[kubitron]

So -- more than one key for the gitolite admin? This is problematic because there seem to be race conditions in which the gitolite admin key gets removed. I've had to add code (still tweaking it) to allow the gitolite admin configuration to be reconstructed. This code only uses the key that Redmine knows about...

[kubitron]

(um... I take it that the difference between "Install" and "configure" made in the new README step #1 is not sufficient?).

[kubitron]

Looking back at this solution you posted earlier:

sudo -u www-data ssh-keygen
sudo -u git gl-setup ~www-data/.ssh/id_rsa.pub

This will not really work in the way you want, if you want multiple administrative keys. The problem, I discovered, is that gl-setup will refuse to update the configuration file if it already has an administrative key present. There are two possibilities here:

1. Either you previously set up gitolite with an administrative key called "id_rsa.pub", in which case this will leave the configuration alone and overwrite the id_rsa.pub in keydir.
2. Or -- you have previously put a different key in for yourself, say "anarcat.pub" as the administrative key. They, the above command will not alter gitolite.conf, but will put the new key in keydir. You will get a complaint about the fact that there is a key called "id_rsa.pub" in the keydir which is not in the config file.

The approach that I took in the new README is to assume that you hadn't run gl-setup yet and it takes you through generating a unique "gitolite admin key".

[kubitron]

Incidentally -- what do you think of the request to use ssh infrastructure for keys/users, i.e. #39.

My thought is that this adds more overhead than it is worth, but it is certainly related to what we are talking about here...

[anarcat]

My stance on this is that if the keys were named properly, -i wouldn't be necessary, nor the configuration file. :)

Failing that, I do not think that adding a config file to the mix will help, especially since the user can already use this to customize his environment. Overwriting that file feels like a bad idea.

[kubitron]

OK. I'm going to close this for now. As far as I can tell, this is only an issue with the README file (although there is a potential bug in the reinitialization code if you have multiple administrative keys).

[kubitron]

Hey--@anarcat long time now talk.

I just uploaded a new feature that permits you to have a separate redmine-managed config file (which you would include into the main one with an include statement). The key between Redmine and gitolite can appear there, leaving it possible for you to have one or more other admin keys in the main gitolite file. This is currently on my 'testing' branch, and might be of interest to you.