Use native ssh alias configuration instead of path-configuration (key, port..)

[EugenMayer]

Thanks for keeping your eye / time on this project! Very appritiated

Instead of using -i ... and asking for the absolute ssh-key path for the gitolite admin...or even the port or what ever, let people use aliases.

.ssh/config

e.g.

Host host.tld Port 2201 PasswordAuthentication no IdentityFile ~/.ssh/git-admin-key HostName host.tld User git

otherwise you will need to add "port" in the future, or whatever people use. I undestand, that the "user" ( git ) needs to be know by the plugin, but all the other things should be left to the proper setup of such an alias.

[EugenMayer]

would like to mark this as a feature request, but i cant :)

[kubitron]

I'm not sure I understand -- are you saying that you want to take the various parameters on the settings page and put them in a file? (You can currently add a port to both the http server and git server hostnames).

[EugenMayer]

no, the way you git clone can be eased up a lot by simply letting people define proper ssh aliases. e.g. the alias above can be used for

git clone host.tld:somepreo

which basically will use the identity file above, on the specific port, on that host etc. You could then remove that sepcial ENV var -i, the defintion of which key to use for gitolite ( as this will be part of the alias ), you dont need to provide port informations. Not sure, but i cases, you could even remove the "gitolite user" configuration file ( while i think, you need this on different places)

[kubitron]

Are you talking about the external interface (i.e. the "git" URL presented on repository page)? Or, are you talking about internals of the plugin?

If you are talking about the external interface, there doesn't seem to be any reason someone cannot go ahead and produce (and use) that file on the client side...

If you are talking about changing the internals of the plugin, I'm afraid that I don't quite understand the advantage of changing things this way. There is a settings page that lets you change all of these parameters. Is there some reason that changing the internals to use such a configuration file would be easier (better?) than changing settings on the settings page?

[EugenMayer]

The code would be easier ( internal ) and it would be much more convinient to handle all ssh related things on the place were it belongs, and thats the alias file. It would shrink the code and make it simpler, while keeping the good standard of ssh-aliases.

[kubitron]

I'm not entirely sure how much easier it would be. I can think of at least three reasons not to do this:

1. For one thing, all the parameters that you care about are on the settings page already. If you go to an external file, then this one more thing that has to be explained to naive installers (and believe me, there are a lot of them).
2. Further, it would still be useful (necessary) for the plugin to know what the user-name is for gitolite, since it uses this to disambiguate multi-gitolite installations (tmp directory is /tmp/redmine_git_hosting/git-user/....., which works when multiple git users are running at the same time).
3. Finally--this plugin+gitolite combination seems to have a failure mode which removes the gitolite admin key on occassion (look in the issues on Eric's page, some of which I answered before taking on this plugin). In that instance, the plugin needs to know where the key is in order to go through a reestablishment protocol.

In order to deal with nos 2 and 3 above, you would need to either enter information about the ssh connection into the plugin or (worse), make it able to parse the file you are talking about.

I'm going to close this for now. As far as I can tell, you are only talking about changing the internals of the code (which works well, at least with respect to connecting with gitolite) and the configuration procedure (which would get more complex!).