You are not logged in.
Solution:
In /etc/gitea/app.ini, change
SSH_ROOT_DIR = /home/git/.ssh
to
SSH_ROOT_DIR =
==================================================
I updated my system today and gitea was one of the packages that was updated. I don't remember what it was at, but it is now at 1.7.0.
Status shows as:
$ systemctl status gitea
...
Jan 29 01:35:00 harleypig.com gitea[17175]: 2019/01/29 01:35:00 [...s/setting/setting.go:882 NewContext()] [E] Failed to create '/home/git/.ssh': mkdir /home/git: permission denied
This issue gave me some pointers, but I don't think it's the same problem.
If, as root, I run
USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea sudo -u gitea --preserve-env='USER,HOME,GITEA_WORK_DIR' /usr/bin/gitea web -c /etc/gitea/app.ini
gitea starts just fine.
I don't understand service files well enough to understand what's happening, and I'll keep looking, but I'm hoping someone has a quick fix.
Edit: Pressed submit too soon.
Last edited by harleypig (2019-01-30 07:32:37)
Offline
Hello there,
Out of curiosity, is that a custom systemd service unit?
Regards
Offline
While I've experimented with settings in the service file, I'm using the service file included in the gitea package.
The sudo command is what I'm running as root to verify gitea is installed and configured correctly.
Though, after having slept some, I realized that the following works just as well.
GITEA_WORK_DIR=/var/lib/gitea sudo -u gitea --preserve-env='GITEA_WORK_DIR' /usr/bin/gitea web -c /etc/gitea/app.ini
Offline
After running the above sudo command just now I tried to clone one of my repos and had issues with ssh.
I tried to delete and ssh pubkey but got an error message about not having permission to /home/git/.ssh. When I reloaded the page the key was gone. Nothing about permission denied was in the logs.
I tried to add a new ssh pubkey and got a 500 error. In the logs I found the following line:
2019/01/29 06:44:13 [...user/setting/keys.go:96 KeysPost()] [E] AddPublicKey: addKey: open /home/git/.ssh/authorized_keys: permission denied
So, I guess gitea is still not configured correctly. I'm still trying to figure out what's going on, but it appears I wasn't as successful as I thought I was.
Offline
Hi
I had a similar problem.
see the post upgrade remark from version 1.6.0 to 1.6.1:
https://git.archlinux.org/svntogit/comm … 11d68d281b
+gitea now uses its own user/group instead of the git ones.
+Ownership of /var/lib/gitea tree has been changed accordingly.
+You need to update your /etc/gitea/app.ini file to change the
+RUN_USER variable at the top.
+
+Next step is fixing the SSH configuration. If you have:
+ AllowUsers git
+in /etc/ssh/sshd_config, you need to change that to gitea.
+Then restart sshd.service.
+You will need to tell all your users that they have to change
+git@ to gitea@ in their repos clones using git remote set-url.
+
+If you use a PostgreSQL DB upon Unix socket, you need to fix
+your [database] configuration and switch USER to gitea.
+Then, you need to change it also in /var/lib/data/pg_hba.conf.
+Finally, as postgres user, run psql and inside it type:
+ ALTER USER git RENAME TO gitea;
+ \q
+Then restart postgresql.service.
+
+In all cases, you then need to reload systemd units and
+restart gitea.service.
By the way, my solution was to clean up /var/log/gitea.
There the change of the user rights didn't work for me.
Maybe this will help you.
Offline
That's a good point, and I should have included that I followed those steps.
RUN_USER is set to gitea in /etc/gitea/app.ini.
AllowUsers has gitea in /etc/ssh//sshd_config.
I'm the only user for my repo and I wasn't trying to work with an already checked out repo.
I don't use PostgreSQL.
I chown'd /var/log/gitea/* to the gitea user.
I restarted each service and even rebooted.
None of these steps made any difference.
Offline
Hello,
What puzzles me, you want gitea to run in '/home/git/' or '/var/lib/gitea'?
Regards
Offline
As far as I can tell, it's running in /var/lib/gitea. I have no idea how it's getting to /home/git.
I made the relevant changes in the install file, and chown'd the files in /var/log/gitea to gitea.
I don't see /home/git in the service file, the configuration file or anything else I've touched. I haven't grep'd through the gitea code though.
Last edited by harleypig (2019-01-29 19:41:52)
Offline
What is the $HOME for gitea user? Eg. grep gitea /etc/passwd
Offline
# grep gitea /etc/passwd
gitea:x:975:975:Gitea daemon user:/var/lib/gitea:/usr/bin/bash
Offline
And systemctl status gitea.service ? Full output, no minification please.
EDIT: You don't have any overrides for gitea.service? Eg. /etc/systemd/system/gitea.service.overide.d ?
EDIT: journalctl -b -u gitea.service could be helpful too.
Last edited by bugsmanagement (2019-01-29 19:53:06)
Offline
# pwd;echo;cat gitea.service
/etc/systemd/system/multi-user.target.wants
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=mysqld.service
After=postgresql.service
After=memcached.service
After=redis.service
[Service]
User=gitea
Group=gitea
Type=simple
WorkingDirectory=/var/lib/gitea
RuntimeDirectory=gitea
LogsDirectory=gitea
StateDirectory=gitea
Environment=USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea
ExecStart=/usr/bin/gitea web -c /etc/gitea/app.ini
Restart=always
RestartSec=2s
CapabilityBoundingSet=
NoNewPrivileges=True
PrivateUsers=true
PrivateDevices=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict
ProtectControlGroups=yes
ProtectKernelTunables=true
ProtectKernelModules=yes
ReadWritePaths=/etc/gitea/app.ini
LockPersonality=true
MemoryDenyWriteExecute=true
RestrictRealtime=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
[Install]
WantedBy=multi-user.target
Offline
If this helps:
# systemctl stop gitea; sleep 5; export STRTGT=$(date +'%Y-%m-%d %H:%M:%S'); echo $STRTGT; systemctl start gitea; sleep 10; journalctl -u gitea --since="$STRTGT"
2019-01-29 13:02:34
-- Logs begin at Tue 2019-01-22 04:50:52 MST, end at Tue 2019-01-29 13:02:44 MST. --
Jan 29 13:02:34 harleypig.com systemd[1]: Started Gitea (Git with a cup of tea).
Jan 29 13:02:34 harleypig.com gitea[28391]: 2019/01/29 13:02:34 [...s/setting/setting.go:882 NewContext()] [E] Failed to create '/home/git/.ssh': mkdir /home/git: permission denied
Jan 29 13:02:34 harleypig.com systemd[1]: gitea.service: Main process exited, code=exited, status=1/FAILURE
Jan 29 13:02:34 harleypig.com systemd[1]: gitea.service: Failed with result 'exit-code'.
Jan 29 13:02:36 harleypig.com systemd[1]: gitea.service: Service RestartSec=2s expired, scheduling restart.
Jan 29 13:02:36 harleypig.com systemd[1]: gitea.service: Scheduled restart job, restart counter is at 1.
Jan 29 13:02:36 harleypig.com systemd[1]: Stopped Gitea (Git with a cup of tea).
Jan 29 13:02:36 harleypig.com systemd[1]: Started Gitea (Git with a cup of tea).
Jan 29 13:02:37 harleypig.com gitea[28405]: 2019/01/29 13:02:37 [...s/setting/setting.go:882 NewContext()] [E] Failed to create '/home/git/.ssh': mkdir /home/git: permission denied
Jan 29 13:02:37 harleypig.com systemd[1]: gitea.service: Main process exited, code=exited, status=1/FAILURE
Jan 29 13:02:37 harleypig.com systemd[1]: gitea.service: Failed with result 'exit-code'.
Jan 29 13:02:39 harleypig.com systemd[1]: gitea.service: Service RestartSec=2s expired, scheduling restart.
Jan 29 13:02:39 harleypig.com systemd[1]: gitea.service: Scheduled restart job, restart counter is at 2.
Jan 29 13:02:39 harleypig.com systemd[1]: Stopped Gitea (Git with a cup of tea).
Jan 29 13:02:39 harleypig.com systemd[1]: Started Gitea (Git with a cup of tea).
Jan 29 13:02:39 harleypig.com gitea[28418]: 2019/01/29 13:02:39 [...s/setting/setting.go:882 NewContext()] [E] Failed to create '/home/git/.ssh': mkdir /home/git: permission denied
Jan 29 13:02:39 harleypig.com systemd[1]: gitea.service: Main process exited, code=exited, status=1/FAILURE
Jan 29 13:02:39 harleypig.com systemd[1]: gitea.service: Failed with result 'exit-code'.
Jan 29 13:02:41 harleypig.com systemd[1]: gitea.service: Service RestartSec=2s expired, scheduling restart.
Jan 29 13:02:41 harleypig.com systemd[1]: gitea.service: Scheduled restart job, restart counter is at 3.
Jan 29 13:02:41 harleypig.com systemd[1]: Stopped Gitea (Git with a cup of tea).
Jan 29 13:02:41 harleypig.com systemd[1]: Started Gitea (Git with a cup of tea).
Jan 29 13:02:41 harleypig.com gitea[28432]: 2019/01/29 13:02:41 [...s/setting/setting.go:882 NewContext()] [E] Failed to create '/home/git/.ssh': mkdir /home/git: permission denied
Jan 29 13:02:41 harleypig.com systemd[1]: gitea.service: Main process exited, code=exited, status=1/FAILURE
Jan 29 13:02:41 harleypig.com systemd[1]: gitea.service: Failed with result 'exit-code'.
Jan 29 13:02:43 harleypig.com systemd[1]: gitea.service: Service RestartSec=2s expired, scheduling restart.
Jan 29 13:02:43 harleypig.com systemd[1]: gitea.service: Scheduled restart job, restart counter is at 4.
Jan 29 13:02:43 harleypig.com systemd[1]: Stopped Gitea (Git with a cup of tea).
Jan 29 13:02:43 harleypig.com systemd[1]: Started Gitea (Git with a cup of tea).
Jan 29 13:02:44 harleypig.com gitea[28445]: 2019/01/29 13:02:44 [...s/setting/setting.go:882 NewContext()] [E] Failed to create '/home/git/.ssh': mkdir /home/git: permission denied
Jan 29 13:02:44 harleypig.com systemd[1]: gitea.service: Main process exited, code=exited, status=1/FAILURE
Jan 29 13:02:44 harleypig.com systemd[1]: gitea.service: Failed with result 'exit-code'.
Offline
Just show the output of
systemctl cat gitea.service
as this will show the contents of all service files that systemd knows about, e.g. if you had overridden the file it would show:
# /usr/lib/systemd/system/gitea.service
[...]
# /etc/systemd/system/gitea.service.d/override.conf
[...]
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
# systemctl cat gitea.service
# /usr/lib/systemd/system/gitea.service
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=mysqld.service
After=postgresql.service
After=memcached.service
After=redis.service
[Service]
User=gitea
Group=gitea
Type=simple
WorkingDirectory=/var/lib/gitea
RuntimeDirectory=gitea
LogsDirectory=gitea
StateDirectory=gitea
Environment=USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea
ExecStart=/usr/bin/gitea web -c /etc/gitea/app.ini
Restart=always
RestartSec=2s
CapabilityBoundingSet=
NoNewPrivileges=True
PrivateUsers=true
PrivateDevices=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict
ProtectControlGroups=yes
ProtectKernelTunables=true
ProtectKernelModules=yes
ReadWritePaths=/etc/gitea/app.ini
LockPersonality=true
MemoryDenyWriteExecute=true
RestrictRealtime=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
[Install]
WantedBy=multi-user.target
[root@harleypig gitea]#
Offline
Sorry, I didn't see your edits. 'journalctl -b -u gitea.service' didn't show anything different than what I replied with.
Offline
Your gitea.service is the one in /usr/lib/ but it is not the same as that packaged by the file. You've modified WorkingDirectory=~ to be WorkingDirectory=/var/lib/gitea
Granted that should not matter as they amount to the same thing here.
EDIT: removed redundant information dealt with above.
Last edited by eschwartz (2019-01-29 20:21:15)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I went ahead and deployed gitea on my local machine: installed -> created a user -> uploaded a ssh key. WORKSFORME
Offline
Good point. I did mention above that I had been experimenting with settings, but I thought I had changed them all back.
sha256sum now matches what is listed in PKGBUILD for gitea.
After running
systemctl daemon-reload
the results are the same.
Offline
This is not a new install. This is an update to an existing system, after the change mentioned by goldey above.
Edit: It would seem to me that if you were able to install a new instance of it, and it worked, that the problem isn't with gitea, but with the changes made to the package where existing installs are concerned.
Last edited by harleypig (2019-01-29 20:30:49)
Offline
Still waiting for a response to
And systemctl status gitea.service ? Full output, no minification please.
You never showed the full systemctl status output -- just the sample of the logs which systemctl status would show. This is useless -- please post the whole output for things.
More generally: the error comes from https://github.com/go-gitea/gitea/blob/ … ng.go#L880 which is braindead code that relies on the contents of the $HOME environment variable.
Last edited by eschwartz (2019-01-29 20:33:11)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I'm sorry, I thought I'd included that.
# systemctl start gitea.service; for n in 1 2; do systemctl status gitea.service --full; sleep 1;done
● gitea.service - Gitea (Git with a cup of tea)
Loaded: loaded (/usr/lib/systemd/system/gitea.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2019-01-29 13:44:14 MST; 11ms ago
Main PID: 10610 ((gitea))
Tasks: 1 (limit: 4915)
Memory: 256.0K
CGroup: /system.slice/gitea.service
└─10610 (gitea)
Jan 29 13:44:14 harleypig.com systemd[1]: Started Gitea (Git with a cup of tea).
● gitea.service - Gitea (Git with a cup of tea)
Loaded: loaded (/usr/lib/systemd/system/gitea.service; enabled; vendor preset: disabled)
Active: activating (auto-restart) (Result: exit-code) since Tue 2019-01-29 13:44:15 MST; 817ms ago
Process: 10610 ExecStart=/usr/bin/gitea web -c /etc/gitea/app.ini (code=exited, status=1/FAILURE)
Main PID: 10610 (code=exited, status=1/FAILURE)
[root@harleypig gitea]#
Offline
The HOME variable is set in the service file. Th fact that it is working for bugsmanagement on a new install but not mine on an upgrade still suggests to me that the problem lies in either the package for existing instances, or something with my setup.
I did not do anything but 'pacman -S gitea' when initially installing. But I don't have a problem taking the blame for my system. I just don't know where else to look.
Offline
What is your /etc/gitea/app.ini?
Looking further into the code, it looks like this is overridden here: https://github.com/go-gitea/gitea/blob/ … ng.go#L853
Which points to the gitea setting:
; Root path of SSH directory, default is '~/.ssh', but you have to use '/home/git/.ssh'.
SSH_ROOT_PATH =
So if this is not empty then I expect it to not matter what $HOME is.
Last edited by eschwartz (2019-01-29 21:19:45)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
That was it. I missed that when searching for instances of git. I claim sleepiness when I searched, and laziness for not checking it again when I woke up.
Changing that entry to 'SSH_ROOT_PATH = ' and turning off git-lfs support (a separate issue with gitea) allowed gitea service to start and I was able to add a key and clone.
Thank you.
Checking my initial install, that was there in my initial setup. I don't remember if I changed that, or it that was the way it came. Should this tip be included in the install file? Or am I a special case?
Offline