From: "Johannes Thyssen Tishman" Subject: Re: New User Questions To: "Omar Polo" Cc: Date: Mon, 05 Jun 2023 10:30:10 +0200 Jun 4, 2023 20:58:11 Omar Polo : > On 2023/06/02 16:54:52 +0200, Johannes Thyssen Tishman > 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. Thanks Omar. Very clear explanation :)