Predictable gitolite usernames

[castedmo]

Is is possible to have predictable (and probably friendly) users in gitolite being generated by this plugin? This will be useful for scenarios in which this plugin should be bypassed (Like user created repos in gitolite. )

[n-rodriguez]

If you want to do that I would suggest you to use an other file to store Redmine repos in Gitolite and use includes.
You can do that by setting an other name for the Gitolite config file in the plugin settings, like 'redmine.conf', then make your 'gitolite.conf' look like this :

repo    gitolite-admin
RW+ =   redmine_git_hosting_admin_key

repo    testing
RW+ =   @all

include "redmine.conf"

[castedmo]

Thanks for the tip, but thats not what i want to do. Take a look at this: http://gitolite.com/gitolite/wild.html
for something like git clone git@server:assignments/u4/a12 (where u4 is a user), the user has to know the real name git is knowing him with. With current name pattern redmine_user_int_int there is no way to achieve this.
Of course the ideal solution is for this plugin to support user created repos.

[n-rodriguez]

Of course the ideal solution is for this plugin to support user created repos.

This can not be done since a repo must be linked to a project.

[castedmo]

Ok, then is it possible to have a persistent user name? something like redmine_username (without current number additions)?

[forouher]

I hacked up a patch that makes usernames more predictable. I didn't test it thoroughly, but it seems to work for me.

forouher@9fb303f

With that patch, keyfiles will be named e.g. "keydir/username@1376320733_603897.pub"
This will cause the gitolite username to be "username".

[rchady]

Just wondering, why is there a need to have a timestamp on the identifier at all? I am not familiar with any way that there is an issue having static gitolite and keyfile names across the board. I've run a modified version of John Kubitron's plugin for years now with this exact thing done and have had no issues. For my own knowledge, I'd like to know what issue is trying to be resolved by adding those.

[forouher]

On 30/08/13 15:06, Robert Chady wrote:

Just wondering, why is there a need to have a timestamp on the
identifier at all? I am not familiar with any way that there is an issue
having static gitolite and keyfile names across the board. I've run a
modified version of John Kubitron's plugin for years now with this exact
thing done and have had no issues. For my own knowledge, I'd like to
know what issue is trying to be resolved by adding those.

I don't see a reason either. You could probably just as well use the
"identifier" given by the user as she named the key
("user_identifier.pub" or "[email protected]"). Although
implementation of key renaming would probably be a bit more difficult.

[rchady]

This is exactly what I had done in the past. In my version I had made it possible to configure a prefix and suffix to the identifier, but in my installation I left both blank and just ran it that way. In effect, it allowed me to use Redmine as the front-end for my users to manage their SSH keys. Was afraid I was missing some key reason for the current logic.

Thanks!

[n-rodriguez]

I think the timestamps are here to avoid conflicts with existing SSH keys, specially if you are in 'shared' configuration, for example if you store Gitlab projects and Redmine projects within the same Gitolite install.
What would happen if you had 2 different users with the same key identifier and you want to delete one of these keys?

[n-rodriguez]

On 30/08/13 15:06, Robert Chady wrote: Just wondering, why is there a need to have a timestamp on the identifier at all? I am not familiar with any way that there is an issue having static gitolite and keyfile names across the board. I've run a modified version of John Kubitron's plugin for years now with this exact thing done and have had no issues. For my own knowledge, I'd like to know what issue is trying to be resolved by adding those.

Because this plugin supports multiple keys per user http://gitolite.com/gitolite/users.html#multi-key
But the only use case is for deployer keys.

[rchady]

After messing with this some more, my next question is... why use timestamps instead of using something like user@redmine_#{key.identifier}.pub ? Seems like that would be easier to deal with than long timestamps?

[n-rodriguez]

After messing with this some more, my next question is... why use timestamps instead of using something like user@redmine_#{key.identifier}.pub ?

To avoid key overwrite between users :)
By the way, in the new plugin the new key format is : redmine_nicolas@redmine_1378084302_740798.pub

Try it, have fun!

[forouher]

By the way, in the new plugin the new key format is : redmine_nicolas@redmine_1378084302_740798.pub

It would be great to have an option to remove the "redmine_" prefix. I use a construct like

repo users/CREATOR/[a-zA-Z0-9].*
C = @ALL
RW+ = CREATOR

where CREATOR gets replaced by the username. It would be much nicer if the username would be identical to the username of the redmine account.

[forouher]

Because this plugin supports multiple keys per user http://gitolite.com/gitolite/users.html#multi-key
But the only use case is for deployer keys.

Uhm, no. Some people use multiple ssh private keys (one for every workstation/laptop, Windows/Linux etc). I've seen users with up to 4 keys in our gitolite installation.

[rchady]

forouher, for what you want, I would suggest changing the keyfiles to be user@redmine_#{key.identifier}.pub. To make this work though, you have to make the configuration file entries be just user -- this will cause issues if you have the plugin trying to manage a single config file for all of the gitolite installation as it won't be able to tell which users are "its own". For me, this is a non-issue as I always put the managed configuration in a separate file so the plugin can own its own file and do whatever it wants with it and I can manage other files as I see fit.

[forouher]

On 12/09/13 22:00, Robert Chady wrote:

forouher, for what you want, I would suggest changing the keyfiles to be
user@redmine_#{key.identifier}.pub. To make this work though, you have
to make the configuration file entries be just user -- this will cause
issues if you have the plugin trying to manage a single config file for
all of the gitolite installation as it won't be able to tell which users
are "its own". For me, this is a non-issue as I always put the managed
configuration in a separate file so the plugin can own its own file and
do whatever it wants with it and I can manage other files as I see fit.

Yeah, that might work. I think I'll do this and give n-rodriguez'
version a try. :)

thanks
Dariush

[n-rodriguez]

Uhm, no. Some people use multiple ssh private keys (one for every workstation/laptop, Windows/Linux etc). I've seen users with up to 4 keys in our gitolite installation.

You're right and the plugin (both version) supports it :)

[n-rodriguez]

For me, this is a non-issue as I always put the managed configuration in a separate file so the plugin can own its own file and do whatever it wants with it and I can manage other files as I see fit.

I do the same, maybe this sould be the default configuration?

[n-rodriguez]

Note that the new key format (redmine_nicolas@redmine_1378084302_740798.pub) is also the key identifier : redmine_nicolas@redmine_1378084302_740798 (without the .pub)

[rchady]

Unfortunately, when you use the key identifier in the configuration file like that, you no longer can easily access it manually from other parts of the config. This is why I made the identifier become just the username in my installation. The keyfiles are all unique, but I can also use 'rchady' elsewhere in the system, for wildcard repos for example, and it all works.

[n-rodriguez]

Can you show me an example please? because I don't really understand

[rchady]

I store all of my redmine managed projects in "managed.conf". With the way the plugin is currently, if you look in there you will see entries like:

repo /foo/bar
RW+ = redmine_n-rodriguez@redmine_2134234_23423

With that form, it relates to a keyfile of the same name. Now, if you want to use that elsewhere in the system... for example "unmanaged.conf", you can't.

With the changes I run locally, which now that I look back are similar to what is in forouher@9fb303 above, you can have:

repo /foo/bar
RW+ = n-rodriguez

This relates to a keyfile of n-rodriguez@redmine_23423_234.

Does that help?

[n-rodriguez]

Ok! I have been misunderstood ^^
In the new version you will have :

repo    jbox-tests/test-nico
  RW+                            = redmine_nicolas
  RW                             = redmine_deployer
  config hooks.redmine_gitolite.projectid = test-nico
  config hooks.redmine_gitolite.repositoryid = 
  config hooks.redmine_gitolite.key = xxxx

repo    jbox-tests/test-nico/test
  RW+                            = redmine_nicolas
  RW                             = redmine_deployer
  config hooks.redmine_gitolite.projectid = test-nico
  config hooks.redmine_gitolite.repositoryid = test
  config hooks.redmine_gitolite.key = xxxx
  config hooks.mailinglist = [email protected], [email protected]
  config hooks.senderemail = [email protected]
  config hooks.emailprefix = [REDMINE]

Is that good for you?

[rchady]

Not really... there is another underlying issue here and that is redmine_git_hosting (RGH) expects to have full control over any keys in the configuration file that match its syntax. This means it is not possible to re-use the keys managed by RGH in any configuration file that RGH manages, period. If that is the case, then adding the extra redmine_ prefix buys you nothing other than the very limited case of you having extra keys that you add to the same managed configuration file.

[n-rodriguez]

This means it is not possible to re-use the keys managed by RGH in any configuration file that RGH manages

You mean 'that RGH does not manage'?

[xSmurf]

Is there currently a fix for this? I'm looking to do precisely what @rchady was doing.

[n-rodriguez]

@xSmurf yes : use a separate Gitolite config file for Redmine and set it in plugin settings.

[xSmurf]

@n-rodriguez that still has the _\d suffix.

[n-rodriguez]

@xSmurf : can you be more specific?

[xSmurf]

After I changed the gitolite config file and removed the redmine_ preffix, adding a key to a user ends up as username_123, where 123 is the redmine user id. I fully understand the potential conflicts with removing this suffix as explained in this thread and would still like this behavior to be configurable.