Open RyanGibb opened 1 year ago
But this would only fail if you change services.gitea.user
to something other than "gitea"
, no? When changing away from the default that other user of course has to exist.
But this would only fail if you change
services.gitea.user
to something other than"gitea"
, no?
Indeed.
When changing away from the default that other user of course has to exist.
What if a user wanted to automatically create a user with a different name? I.e., git
. Perhaps the creation of a system user should be behind a different flag?
What if a user wanted to automatically create a user with a different name? I.e.,
git
.
then ... just do it?
{
services.gitea.user = "git";
users.users.git = {
description = "Git Service";
home = "/var/lib/git";
useDefaultShell = true;
group = "git";
isSystemUser = true;
};
What if a user wanted to automatically create a user with a different name? I.e.,
git
.then ... just do it?
While this if of course possible, it's unintuitive to new users. The descriptions of serivces.gitea.user
only says "User account under which gitea runs", which does not lead one to realise that this will create a user account only with the default value.
If you don't want to change this behaviour, perhaps instead the cfg.user == "gitea"
check could be changed to cfg.createUser
with a new boolean flag that defaults to cfg.user == "gitea"
.
Alternatively the documentation could be improved, adding the line A user account with this name will be created if left with the default value of "gitea"
.
This is not a support issue, but rather my trying to improve the experience of using this module for the first time.
using this module
all services work like this ... each service creates a user with the same name as the service
the nginx service creates user nginx, the ftp service creates user ftp, ...
improve the experience of using this module for the first time.
maybe the docs could be improved
the nixos docs mention users.users.
in some places
All users that should have permission to change network settings must belong to the networkmanager group:
users.users.alice.extraGroups = [ "networkmanager" ];
# /var/lib/acme/.challenges must be writable by the ACME user # and readable by the Nginx user. The easiest way to achieve # this is to add the Nginx user to the ACME group. users.users.nginx.extraGroups = [ "acme" ];
so maybe you can use
users.users.gitea.extraGroups = [ "git" ];
... or whatever it is youre actually trying to do
why should gitea
not run under the gitea user?
why should /var/lib/gitea
not be owned by the gitea user?
why should gitea not run under the gitea user?
Personally, I want the urls to my git repositories to be git@<domain>:<user>/<repo>
in case I want to switch to another git hosting service in the future.
all services work like this ...
Fair enough, but I think this is a slightly different case because the user is exposed in the ssh URLs (whereas for nginx, it really doesn't matter)
I want the urls to my git repositories to be
git@<domain>:<user>/<repo>
the user is exposed in the ssh URLs
makes sense
still, you will have to configure this manually because "all services work like this" (services are isolated by system users)
simple: services.gitea.user = "git";
etc
complex: find a way to alias the virtual user "git" to the internal user "gitea"
https://askubuntu.com/a/1211837/877276
have a single user serve as a redirector based on SSH key. This is how source control repositories that use SSH typically work.
Lets call the user me. Everyone will use this alias.
ssh me@ip_address
Now the user me has all of users public keys in their ~/.ssh/authorized_keys.
command="sudo -i -u user-mapped-to-key" ssh-rsa key
You will need to make the user me have the ability to sudo as the other users and you will need to manage me authorized keys file.
Anyway I haven't tested this but in theory something like this should work.
https://serverfault.com/a/570736/499621
if using ssh key files is let everyone login as user site but with their own keys, then in the authorized_keys file add the following to the start of each different key line:
environment="SITEID=site123" ssh-rsa AAAAB3NzaC environment="SITEID=site111" ssh-rsa AAAAJ2Oqka
that way they will still all have different site id's
typically, the "git@" user isn't just used by itself but together with a "smart" backend such as Gitolite (or Gitea/Gogs/GitLab), which applies different access levels depending on which SSH key was used (via command=".." tricks in the authorized_keys file).
https://github.com/go-gitea/gitea/issues/3631 https://github.com/go-gitea/gitea/issues/8955 https://docs.gitea.io/en-us/authentication/ https://wiki.archlinux.org/title/Gitea#Enable_SSH_Support https://git-scm.com/book/ms/v2/Git-on-the-Server-Setting-Up-the-Server https://dmitrybogomolov.github.io/notes/content/ssh-setup
happy reading ^^ feel free to share your results
simple: services.gitea.user = "git"; etc
This is what I'm doing now:
users.users.git = {
description = "Git Service";
home = config.services.gitea.stateDir;
useDefaultShell = true;
group = "gitea";
isSystemUser = true;
};
services.gitea = {
...
user = "git";
...
database = {
...
user = "git";
name = "git";
...
};
But it's not the most ergonomic.
still, you will have to configure this manually because "all services work like this" (services are isolated by system users)
I don't think just because all the other services work like this doesn't mean this one has to. We could still isolate the service with a system user while customizing the name of said user.
complex: find a way to alias the virtual user "git" to the internal user "gitea"
This sounds horrible :-) And I believe gitea is already doing some of this magic behind the scenes, so I'm loath to add more on top of this. I'm already proxying the public port 22 to the internal gitea ssh server (and using a vpn interface for shell access):
iptables -A PREROUTING -t nat -i enp1s0 -p tcp --dport 22 -j REDIRECT --to-port ${builtins.toString giteaSshPort}
ip6tables -A PREROUTING -t nat -i enp1s0 -p tcp --dport 22 -j REDIRECT --to-port ${builtins.toString giteaSshPort}
# proxy locally originating outgoing packets
iptables -A OUTPUT -d <local ipv4> -t nat -p tcp --dport 22 -j REDIRECT --to-port ${builtins.toString giteaSshPort}
ip6tables -A OUTPUT -d <local ipv6> -t nat -p tcp --dport 22 -j REDIRECT --to-port ${builtins.toString giteaSshPort}
Describe the bug
The deployment will fail due to a user not existing, because of this line: https://github.com/NixOS/nixpkgs/blob/814f8f3363cecee7cce314286846e4da5e92d689/nixos/modules/services/misc/gitea.nix#L605
Additional context
This is the configuration I'm using: https://github.com/RyanGibb/nixos/blob/master/modules/services/gitea.nix
Notify maintainers
@srhb @ma27
Metadata