So I was tearing my hair out trying to figure out why attempts to push via DAV to a git repo were failing.
Eventually I succeeded in stracing the httpd process sto capture the request. It was getting an EROFS when it tried to write to the git repo.
Amusing.
To make a long story short, the culprit was:
ProtectHome=read-only
in /lib/systemd/system/httpd.service,(the git repo was in a directory inside a mounted /home partition).
I tried using
systemctl edit httpd
And putting this in there:
[Service] ProtectHome=
However this apparently did not work. I threw in the towel and just edited /lib/systemd/system/httpd.service and commented this setting out, entirely, to finally fix this issue, and happy git pushing resumed.
But how do I fix this so that the next apache update doesn't clobber this?
The easy solution is chattr +i <filename> and that will block all further changes to the file forever.
It is kind of a last resort.
On Tue, Jun 4, 2024 at 6:24 PM Sam Varshavchik mrsam@courier-mta.com wrote:
So I was tearing my hair out trying to figure out why attempts to push via DAV to a git repo were failing.
Eventually I succeeded in stracing the httpd process sto capture the request. It was getting an EROFS when it tried to write to the git repo.
Amusing.
To make a long story short, the culprit was:
ProtectHome=read-only
in /lib/systemd/system/httpd.service,(the git repo was in a directory inside a mounted /home partition).
I tried using
systemctl edit httpd
And putting this in there:
[Service] ProtectHome=
However this apparently did not work. I threw in the towel and just edited /lib/systemd/system/httpd.service and commented this setting out, entirely, to finally fix this issue, and happy git pushing resumed.
But how do I fix this so that the next apache update doesn't clobber this?
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jun 4, 2024 at 6:24 PM Sam Varshavchik mrsam@courier-mta.com wrote:
So I was tearing my hair out trying to figure out why attempts to push via DAV to a git repo were failing.
Eventually I succeeded in stracing the httpd process sto capture the request. It was getting an EROFS when it tried to write to the git repo.
Amusing.
To make a long story short, the culprit was:
ProtectHome=read-only
in /lib/systemd/system/httpd.service,(the git repo was in a directory inside a mounted /home partition).
I tried using
systemctl edit httpd
And putting this in there:
[Service] ProtectHome=
However this apparently did not work. I threw in the towel and just edited /lib/systemd/system/httpd.service and commented this setting out, entirely, to finally fix this issue, and happy git pushing resumed.
But how do I fix this so that the next apache update doesn't clobber this?
Copy the file to /etc/systemd/system and it will override the package provided file in /lib/systemd/system
Thanks, Richard
On Tue, Jun 4, 2024 at 7:24 PM Sam Varshavchik mrsam@courier-mta.com wrote:
So I was tearing my hair out trying to figure out why attempts to push via DAV to a git repo were failing.
Eventually I succeeded in stracing the httpd process sto capture the request. It was getting an EROFS when it tried to write to the git repo.
Amusing.
To make a long story short, the culprit was:
ProtectHome=read-only
in /lib/systemd/system/httpd.service,(the git repo was in a directory inside a mounted /home partition).
I tried using
systemctl edit httpd
And putting this in there:
[Service] ProtectHome=
However this apparently did not work. I threw in the towel and just edited /lib/systemd/system/httpd.service and commented this setting out, entirely, to finally fix this issue, and happy git pushing resumed.
But how do I fix this so that the next apache update doesn't clobber this?
I think a better choice is to leave the systemd unit files alone. Then you don't have to worry about your changes getting reverted on updates and system upgrades.
I also think it is better to avoid serving files from your home directory. Instead, use /var. Install your Git-managed project in /var/git (and your Subversion projects in /var/svn). Add a git user, and make ownership of /var/git as root:git. Finally, change the server's document root to /var/git/<project>.
This setup works well for me. The only problem I have encountered is Git's fix for CVE-2022-24765 a/k/a safe directories. Safe directories caused a big DoS at my site. Also see https://github.com/git/git/commit/8959555cee7e.
Jeff
Sam Varshavchik composed on 2024-06-04 19:24 (UTC-0400):
So I was tearing my hair out trying to figure out why attempts to push via DAV to a git repo were failing.
Eventually I succeeded in stracing the httpd process sto capture the request. It was getting an EROFS when it tried to write to the git repo.
Amusing.
To make a long story short, the culprit was:
ProtectHome=read-only
in /lib/systemd/system/httpd.service,(the git repo was in a directory inside a mounted /home partition).
I tried using
systemctl edit httpd
And putting this in there:
[Service] ProtectHome=
However this apparently did not work.
Please show us the override file in /etc/systemd* that resulted from your edits. Using systemctl edit for for over a year had me baffled.
I threw in the towel and just edited /lib/systemd/system/httpd.service and commented this setting out, entirely, to finally fix this issue, and happy git pushing resumed.
But how do I fix this so that the next apache update doesn't clobber this?
Get the override to work. I have several working.
Felix Miata writes:
I tried using
systemctl edit httpd
And putting this in there:
[Service] ProtectHome=
However this apparently did not work.
Please show us the override file in /etc/systemd* that resulted from your edits. Using systemctl edit for for over a year had me baffled.
Exactly that:
[root@monster ~]# cat /etc/systemd/system/httpd.service.d/override.conf [Service] ProtectHome= [root@monster ~]#
This did not work.
I threw in the towel and just edited /lib/systemd/system/httpd.service and commented this setting out, entirely, to finally fix this issue, and happy git pushing resumed.
But how do I fix this so that the next apache update doesn't clobber this?
Get the override to work. I have several working.
Above is what I tried first, based on all the available documentation.
Eventually, by guessing, and staring at each word in the man page, I came up with:
ProtectHome=false
instead, and this worked. Good luck finding where this is documented in the man pages, for overrides. There were barrels of laughs in systemd.exec(5). First, there are several instances of "ProtectHome=yes" sprinkled in random places. Then, when you get to the actual description:
ProtectHome= Takes a boolean argument or the special values "read-only" or "tmpfs". If true, the directories /home/, /root, and /run/user are made inaccessible and empty for processes invoked by this unit.
What does "true" mean here? Does it refer to the setting existence, overall? Or, boolean as "true" and "false", but if so, what's "ProtectHome=yes" is all about?
Just by a random guess I tried an override of "ProtectHome=false", and this was the magic incantation:
[root@monster conf.d]# cat /etc/systemd/system/httpd.service.d/override.conf [Service] ProtectHome=false [root@monster conf.d]#
On Wed, 2024-06-05 at 06:41 -0400, Sam Varshavchik wrote:
Good luck finding where this is documented in the man pages, for overrides. There were barrels of laughs in systemd.exec(5). First, there are several instances of "ProtectHome=yes" sprinkled in random places. Then, when you get to the actual description:
ProtectHome= Takes a boolean argument or the special values "read-only" or "tmpfs". If true, the directories /home/, /root, and /run/user are made inaccessible and empty for processes invoked by this unit.
What does "true" mean here? Does it refer to the setting existence, overall? Or, boolean as "true" and "false", but if so, what's "ProtectHome=yes" is all about?
I'd suggest reporting a documentation bug. It's the only way this will ever be clarified. I think people generally don't bother reporting this kind of thing (and I include myself in that) but it's important.
poc
Patrick O'Callaghan wrote:
On Wed, 2024-06-05 at 06:41 -0400, Sam Varshavchik wrote:
Then, when you get to the actual description:
ProtectHome= Takes a boolean argument or the special values "read-only" or "tmpfs". If true, the directories /home/, /root, and /run/user are made inaccessible and empty for processes invoked by this unit.
What does "true" mean here? Does it refer to the setting existence, overall? Or, boolean as "true" and "false", but if so, what's "ProtectHome=yes" is all about?
I'd suggest reporting a documentation bug. It's the only way this will ever be clarified. I think people generally don't bother reporting this kind of thing (and I include myself in that) but it's important.
Is it really surprising that systemd (like many other tools) accepts values of yes/no, 1/0, and on/off in addition to true/false for boolean settings?
It is documented in systemd.syntax(7), though I imagine many people don't read all of the docs (which are already sprawling and massive). Adding more to it may not help.
FWIW, the documentation says:
Boolean arguments used in configuration files can be written in various formats. For positive settings the strings 1, yes, true and on are equivalent. For negative settings, the strings 0, no, false and off are equivalent.
-
Felix Miata -
Jeffrey Walton -
Patrick O'Callaghan -
Richard Shaw -
Roger Heflin -
Sam Varshavchik -
Todd Zullinger