"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Omar Polo <op@omarpolo.com>
Subject:
Re: New User Questions
To:
Johannes Thyssen Tishman <lists@thyssentishman.com>
Cc:
gameoftrees@openbsd.org
Date:
Sun, 04 Jun 2023 20:58:11 +0200

Download raw body.

Thread
On 2023/06/02 16:54:52 +0200, Johannes Thyssen Tishman <lists@thyssentishman.com> wrote:
> On Fri, Jun 02, 2023 at 02:11:13PM +0200, Stefan Sperling wrote:
> > On Fri, Jun 02, 2023 at 12:17:59PM +0200, Johannes Thyssen Tishman wrote:
> > > [...]
> > > Having all repos stored in /var/git, what are the correct permissions
> > > for these if I have multiple developers with read-write permissions
> > > working on them? Does gotd handle the permissions of these as specified
> > > in the /etc/gotd.conf and can I simply have them be owned by
> > > maindev:maindev for example? Or do I have to do 'chown -R :developers
> > > repo && chmod g+w repo' for all the repos that need write access by the
> > > developers group?
> >
> > The standard approach for a "main-hub" style server is to have _gotd
> > own all repositories on disk and add your developers to gotd.conf.
> 
> How would one create a new repository in this case? As root and then
> chown _gotd:_gotd?

or as a local user and then move and chown to _gotd.  whatever works
best for you.

> > There are cases where using a UID other than _gotd can be useful.
> > For example, I sometimes run gotd as my own user when I just want to
> > push changes repos on another system such as a VM and I don't have
> > Git installed in the VM. The same makes sense for single-user servers
> > where the user also runs scripts that synchronize repositories in
> > the background.
> 
> Ah I see. My server is indeed a single-user server, however if I run
> gotd as my user, would others still be able to contribute if given rw
> permissions in /etc/gotd.conf?

Yes, as long as the repositories are RW for the gotd user and you add
a 'permit' in gotd.conf for the user (or groups) you want to allow.
gotd would then assert that the user attempting to do the operation is
allowed and then do it on their behalf.  that's why the user gotd is
running as needs to own the repositories.

> > For now, I would recommend running -current for gotd servers.
> > OpenBSD 7.3 does not have gitwrapper(1) yet which makes deployment
> > of gotd a lot easier when used in parallel to Git.
> 
> Actually my plan is to completely replace git on the server.

not hard to do :-)

> Would you
> still recommend -current when not working in parallel to Git?

Yeah.  gotd is still wip (well, all got is still wip but some parts
are more stable than others) and updates are not usually backported to
previous OpenBSD releases.  Luckily it's easy to compile.  That's what
I do on my server for example, it's running -STABLE but I compile
gotd/gotwebd from the main branch.  (I also do it to test diffs
though.)

> Also out
> of curiosity, why would someone want to work both with got and git at
> the same time on a server?

gitwrap is handy for multiple reasons.  You may have a temporary
repository somewhere, say in your home, and wanting to push to it
directly.  Or, more likely, you don't want your remote user shell to
be gotsh.  This last one is gitwrapper' biggest win for me.

> > > Regarding /etc/gotd.conf, is it in the developers plans to allow for
> > > per-directory/wildcard configurations. E.g:
> > >
> > >     repository ".*" {
> > > 	path "/var/git/*"
> > > 	permit rw :devs
> > > 	permit ro anonymous
> > >     }
> >
> > No, because then gitwrapper won't know which repositories are supposed
> > to be managed by gotd.
> 
> So gitwrapper determines the repos that are to be managed by gotd by
> parsing /etc/gotd.conf?

exactly.  it's all documented in gitwrapper(1).

> [...]
> Awesome, this will do! Question though: I couldn't find how to configure
> a remote repository for a local repository in the man pages aside from
> manually adding it to got.conf. Is this the only way?

The only way to add/remove/change a remote is editing the got.conf
file.  got doesn't provide commands to automatically change the
configuration.