Re: Git Repository for WITH RECURSIVE and others - Mailing list pgsql-hackers

David Fetter wrote:
> On Mon, Jun 30, 2008 at 01:50:26PM +0200, Magnus Hagander wrote:
>> David Fetter wrote:
> [gitosis]
>>> It *would* be good, if the author seemed even vaguely interested
>>> in packaging up so much as a tarball, but he is not.  His attitude
>>> is (paraphrasing from conversations with him the past few days),
>>> "it's good enough as a git repository, and everybody who's using
>>> it is a git administrator, so they should know how to wrangle git
>>> repositories." While he may someday outgrow this, we really should
>>> not put him and his attitude in critical paths for our project.
>>>
>>> Let's go with git-shell, which is supported and packaged software
>>> on just about every platform, and stop waiting for Godot^Wgitosis.
>> I'm not sure I agree that this is a big problem, but sure, we should
>> at least consider git-shell.
> 
> Please explain your reasoning here.  The project has taken nasty hits
> on its infrastructure already (pgfoundry) because the author of the
> software had a go-it-alone, I-know-best attitude that sooner than
> later forced us to fork.  As a direct consequence, pgfoundry now needs
> a redo that will take a pgfoundry administrator many of work in their
> "ample spare time."

If the reason for this is that the software isn't usable, that's one
thing. If it's just the author that considers "a git snapshot is my
release packaging, not a tarball", I don't see how that in itself has
any effect on the quality of the software.

If that's the only thing it's saying, I don't think that in itself is
enough to disqualify gitosis.


>> Is there any product out there that makes it possible to admin a
>> git-shell based system without having all the admins being root on
>> the server?  Because that's simply not an option if you want
>> anything remotely scalable.
> 
> I don't know what you mean by "remotely scalable," but it's clearly
> not the same definition I have.  A sudo wrapper which only allows
> creation, editing and deletion of accounts restricted to git-shell
> will scale just fine.

A properly working sudo wrapper that will let you do *everything needed*
is good enough for me.


>>> Here's an even simpler implementation: git-ssh and public keys.  Yes,
>>> it involves work by administrators, which I'd be delighted to do.
>> Are you referring to git-shell, or is this a different product? If so,
>> reference to said product, please?
> 
> Same.

Ok, good.


>> And it must not require root.
> 
> This is what sudo is built to do :)

Yes.


>> Show me such a solution, and I'll be happy to consider it :-)
> 
> 1. Create a (set of) program(s) which does exactly the following things:
> 
>     * Create an account with git-ssh as its shell.
>     * Manipulate the contact information, ssh keys and groups of said account.
>     * Delete the account.

Rght. Is there a product out there already that lets us do this, or is
it something we need to write ourselves?

You'll also need scripts to create and modify the GIT responsitories
themselves, no?

Since it's sudo, it has to be secure after all, so it's not necessarily
a 2 minute hack.


> 2. Create a unix group and corresponding sudo role that accesses the above.
> 
> 3. Create shell accounts as needed with the above group.  Yes, that's
> a root-only task, but it's a short one.

Um, not following that step. What account are you talking about here?
Creating the accounts for the admins? That's not an issue, since I
assume that's not something that would be done very often :-)



> I believe that the above takes care of 90% or more of tasks.  If it
> turns out that we need to automate more, we can add that
> (semi)automation to the capabilities above :)

As long as it allows it. For example, having a webserver do sudo is not
something that makes me feel very safe (and yes, I've seen solutions
that do that claiming to be secure. And sure, you *can* build them
secure, it's just a lot harder than most people who choose to do it are
aware of)

//Magnus