Automatic setup of own repo-space for every user

[Jonathan Vorndamme]

Hello,

I want that every user, I add a key for, automatically gets control over it's own namespace of repos (e.g. <username>/..*) and is able to configure those repos in a subconf "<username>.conf" that only this specific user can edit. Is there a way to set this up?

Best regards

Jonathan

[Sitaram Chamarty]

Apologies for the delay; as I grow older work only seems to
increase :(

In short, this is not possible. Sorry about that. I'll think
on this some more as I find time.

A lot of the functionality can be achieved by a custom VREF, but
the part that cannot be "wildcarded" is the one that needs

@alice = alice/.*
@bob = bob/.*
...

for each user.

Sorry!

You could probably create a custom "sugar" module (see
https://gitolite.com/gitolite/dev-notes#sugar) to help you
generate those lines.

(Note: sugar scripts must be in perl; it's one of the only 2
places in gitolite which can't be implemented externally, the
other one being the INPUT trigger)

- look up contents of ~/.gitolite/keydir, derive list of users
from it, assuming all your users are coming in via ssh.
(This won't work if you're using http mode for example,
because there the authentication step is completely opaque
to gitolite)

- generate lines like the alice, bob, example above

In your conf you'd have

subconf "myusers/*.conf"

Next, you need the equivalent of the VREF lines you see in
https://gitolite.com/gitolite/deleg.html#example.

You can get around that by writing a custom VREF instead of the
built-in "NAME" VREF given in the example.

I'm traveling right now but next weekend (16th) I should be
back, and I can look into writing these if you wish.

Sorry again for the delay in replying to your previous messages;
things have been hectic!

regards
sitaram

[Jonathan Vorndamme]

Thanks a lot for your answer and no worries about the delay. It's not super urgent,

but would simplify my life as an admin a lot in the long run. It would be super

nice, if you could have a go on that. I was also thinking about my own VREF for

the access control, but was unsure about how to get the current gitolite users

name - via environment variable $GL_USER?

Also it would be super nice to be able to write something like this in the conf:

@USER = USER/.*

such that user is evaluated to the current gitolite user name. Or maybe even

@group = USER/*

such that this wrks only for members of group.

Now that I think about it, it reminds me a lot of how the wild repos work. Would

it make sense to allow users in general to control their wild repos in the conf file

additionally to the control via perms command? The reasoning for this is that

my users like GUIs a lot and are kind of shy when it gets to bash. And in addition,

personally, I think that the conf files give a better overview and, of course, more

flexibility.

Best regards

Jonathan

[Jan Vales]

Hello,

quite a little bit delayed. ;)

Im using wild-repos for that and I have completely abandoned non-wild-repos by now.
Here is the config i am successfully using.

repo priv/CREATOR/[a-zA-Z0-9_-]*

C = @all

RW+ = CREATOR

RW = MANAGER

- master$ = @all

RW = WRITERS

R = READERS


It allows users to create a repo in their name on the path priv/$USERNAME/$REPONAME

Hope it helps.

br,
Jan

> https://gitolite.com/gitolite/dev-notes#sugar <https://gitolite.com/gitolite/dev-notes#sugar>) to help you

> generate those lines.
>
> (Note: sugar scripts must be in perl; it's one of the only 2
> places in gitolite which can't be implemented externally, the
> other one being the INPUT trigger)
>
> - look up contents of ~/.gitolite/keydir, derive list of users
> from it, assuming all your users are coming in via ssh.
> (This won't work if you're using http mode for example,
> because there the authentication step is completely opaque
> to gitolite)
>
> - generate lines like the alice, bob, example above
>
> In your conf you'd have
>
> subconf "myusers/*.conf"
>
> Next, you need the equivalent of the VREF lines you see in

> https://gitolite.com/gitolite/deleg.html#example <https://gitolite.com/gitolite/deleg.html#example>.

>
> You can get around that by writing a custom VREF instead of the
> built-in "NAME" VREF given in the example.
>
> I'm traveling right now but next weekend (16th) I should be
> back, and I can look into writing these if you wish.
>
> Sorry again for the delay in replying to your previous messages;
> things have been hectic!
>
> regards
> sitaram
>

> --
> You received this message because you are subscribed to the Google Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com
> <mailto:gitolite+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gitolite/255ef290-f93f-4744-9003-9c75e439fc3an%40googlegroups.com
> <https://groups.google.com/d/msgid/gitolite/255ef290-f93f-4744-9003-9c75e439fc3an%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jonathan Vorndamme]

Hello,

thanks for your answer. Having a good set of roles might make this feasible. But for me a few problems arise:

1. I won't be able to get my useers to use the perms command - the text-file seems just so much easier

2. People here come and go frequently and the knowledge about the existence of the wild repo will be gone with the creator/last user leaving

3. We need to spread the knowledge about what we have, so that we can do good cooperation and don't do things twice, being able to see the repos in the text-file would be very helpful

So I would really like to be able to do this without having to control everything myself.

Best regards

Jonathan

[Sitaram Chamarty]

Hi

Not sure if you're still interested in this, but it's been on
the backburner for a while and I finally got some time.

Just to recap, the question was "can you give every user pretty
much his own namespace of repositories, _without_ the onus of
adding even one line per user" -- i.e., it should just work for
all users. (Put another way, the effort should be O(1) not O(n)
in the number of users!) That precluded the obvious solution I
mentioned in one of those long ago emails.

Another factor was that I agree with Jan Vales -- giving all
users full read access to the conf file seems unwise.

Good challenge...

Now, I've always tried, when looking for solutions to problems
that seem like only a few people would have them, to find a way
to do it without having to touch gitolite code itself in any
way. It should be possible, because I've often said gitolite is
not so much a tool as it is a tool-enabler.

Anyway, I found a relatively simple means of doing this. If you
are able to test this out and confirm it works, I'll add it to
the "contrib" directory for future users. Please note I have
only minimally smoke-tested it.

Here's how it works.

1. Your main "conf/gitolite.conf" should contain the following
lines:

repo userconf/CREATO[R]
# sorry that is a bit of a kludge; we never expected
# to use this mechanism to create just ONE repo per
# user!
C = @all
# here you can restrict the "C" permission to some smaller group
# if you do not want absolutely every user to have his own
# namespace. But that's your call; as is, it is O(1) in users!
RW+ = CREATOR

include "../userconf-groupdef[s].conf"
subconf "../userconf/*.conf"

2. read up on "local commands" and create and enable a command
called "userconf".

(Or just do these:
- edit ~/.gitolite.rc and uncomment one of the LOCAL_CODE
definitions, based on your preference
- in the directory you picked, create a subdirectory
called "commands" and copy the script attached to that
subdirectory. Don't forget to `chmod +x` it
- back in the gitolite RC file, go to the ENABLE list and
add the below entry so that users can run the command:
'userconf',
(note the trailing comma!)
)

3. Instructions to your users:

Assuming your username is "alice", do the following:

1. run "git clone git@server:userconf/alice.git" the first
time; this will auto-create the repo and clone it.
(Subsequent changes can be done by simply going to that
directory and doing the usual).

2. in that clone, add "alice.conf", containing repo
definitions and rules for repos starting with "alice/";
e.g., alice/foo, alice/bar, ...

3. save, git add, commit, push

4. run "ssh git@server userconf"

Rate limiting users is left as an exercise for the reader :)

[Jonathan Vorndamme]

Hi,

thanks a lot for having  a go at this. If I read the script correctly, the user needs to use the userconf command after each change to his personal config and the configs reside in the personal repos, correct? While I get why it is in general bad to give everybody read access to the conf-file, it kind of contradicts the wish for transparency. So based on your suggestion, I was thinking to do the following:

1. My main "conf/gitolite.conf" should contain the following
lines:

include "../userconf-groupdefs.conf" # why did it have the "[]", also for CREATO[R]?
subconf "../userconf/*.conf"

2. Use the following skript as a hook after every commit before the gitolite compile:

#!/bin/bash
die() { echo >&2 "$@"; exit 1; }
#set -x

cd $GL_ADMIN_BASE || die "cd GL_ADMIN_BASE ('$GL_ADMIN_BASE') failed"

rm -f $GL_ADMIN_BASE/userconf-groupdefs.tmp

for user in $(git show HEAD:keydir | tail -n +3)
do
    user=${user%.pub}
    (
        echo "@$user = $user/..*" >> $GL_ADMIN_BASE/userconf-groupdefs.tmp
    )
done
echo "repo    gitolite-admin" >> $GL_ADMIN_BASE/userconf-groupdefs.tmp
for user in $(git show HEAD:keydir | tail -n +3)
do
    user=${user%.pub}
    (
        echo "         RW  VREF/NAME/conf/subconfs/$user = $user" >> $GL_ADMIN_BASE/userconf-groupdefs.tmp
    )
done
echo "         -   VREF/NAME/ = @all" >> $GL_ADMIN_BASE/userconf-groupdefs.tmp

mv $GL_ADMIN_BASE/userconf-groupdefs.tmp $GL_ADMIN_BASE/userconf-groupdefs.conf

The remaining question would be how to call that hook. As a post-receive hook? Would that have the correct environment variables set? Or would it be better to make this a POST_GIT hook in gitolite for the admin-repo only?

[Sitaram Chamarty]

On Fri, Jun 23, 2023 at 06:24:41AM -0700, Jonathan Vorndamme wrote:
> Hi,
>
> thanks a lot for having a go at this. If I read the script correctly, the
> user needs to use the userconf command after each change to his personal
> config and the configs reside in the personal repos, correct? While I get
> why it is in general bad to give everybody read access to the conf-file, it
> kind of contradicts the wish for transparency. So based on your suggestion,
> I was thinking to do the following:

I don't see transparency as the main goal I was going for, or
most of the people who use it are going for.

But if I'm going to say things like "gitolite is a tool enabler
more than just a tool", I can't then fault someone for using it
how they want.

In that light, I am compelled to say "if it works for you, go
for it" :)

> include "../userconf-groupdefs.conf" # why did it have the "[]", also for
> CREATO[R]?

quirk. Or hack if you will.

Wild repos (ad hoc user created repos) needs a regex there.
Normally it'd be "foo/CREATOR/..*, meaning they'd get an entire
namespace but in this case we were only going to give them
"alice.git" not "alice/<anything>.git"

[snipped the rest]

[Jonathan Vorndamme]

Thanks for the explanation of the hack and for being so understanding, it's something that cannot be observed very often these days, I highly appreciate it.

"[snipped the rest]" - I feel like something went wrong here and the answer was longer initially, is that correct? If so, I'd love to see the missing part :)