Lightbulb Moment
Context: my desktop computer died just before Christmas (fortunately I had backups). When I got back from visiting family, I ordered a new computer, and it arrived and it is pretty.
Before the new computer arrived, I had been able to set up my laptop as a server, and I have decided to leave it that way, as it was working fine in that capacity; it doesn't matter if a server doesn't have a working soundcard (oh boy have I been missing listening to music while I pecked away at the computer). I don't feel an urgent need for a replacement laptop, because the three things I've been using the laptop for, I don't necessarily need it for right now. The first, reading fanfic, I've been doing a lot more comfortably with my ebook reader. The other two, writing fic and coding while on the bus to work... well, I've been doing things like crocheting instead. And I still have my netbook, which could be used for that too.
Anyway... so the context is, new computer, and setting up new computer, bit by bit, not in a hurry.
And tonight I was trying to run a php script on the webserver on the new computer (so that I could mess with it without breaking it on the actual server) and I couldn't get it to run. Lots of uninformative error messages and googling later... very frustrated. Because I have a semi-complicated setup with Apache and SuExec and FastCGI in order to get PHP to run as my user, so that when it writes to files, they aren't owned by Apache, because that is a pain when I try to sync stuff between computers. And increasing frustration as I came across things like mpm-itk (which is supposed to be better than SuExec) and could not figure out how to install it on Sabayon Linux (which is what I use), and thinking "What am I doing all this for? I just want Apache to run as a given user!"
So, I started googling about Apache running as user.
Well.
Lightbulb moment.
My googling reminded me that there is a setting in the normal Apache config to set the user and group that Apache runs as - it's usually set to something like "nobody" or "apache"; and this is done for security reasons; the user needs to be a user that isn't root.
A user that isn't root.
Would it break anything if I set those values to my user and group? After all, I already run all my vhosts as my user and group anyway. Would it break the server to just set that directly, rather than using complicated workarounds such as SuExec and FCGI? I mean, obviously, one needs those things for a multi-user system with virtual hosts for different people, but I'm the only one using this system, so those considerations don't apply. So, would it break anything?
The answer to that was "yes and no".
Things that broke:
1. Logging. I anticipated this one; needed to set the owner of /var/log/apache2 to my user.
2. SuExec. This was a doozy.
See... at least on Sabayon Linux, when you turn off SuExec... you don't quite turn off SuExec. I mean, the obvious assumption is that when you change the configuration settings in the right places, it will turn off SuExec. So I did that.
But for some reason I don't understand, even though it wasn't loading the suexec module, apache was trying to run the /usr/sbin/suexec program. It complained that it didn't have the right permissions to run it (which it didn't because it was running as me instead of apache). So I tweaked some settings so that it did have permission... and then it complained that there were SuExec violations. Um. I thought it wasn't supposed to be running suexec since I'd turned it off in the config?
Well.
It seems that Apache in all its wisdom, decides whether it is running suexec NOT from the config, but from whether the program /usr/sbin/suexec exists on the system. If it does exist, it tries to run it, and if it runs, then suexec is enabled. (!?)
Now, with many Linux systems, one could solve that by uninstalling the suexec package and thereby removing the /usr/sbin/suexec program, but Sabayon doesn't have a separate suexec package; it seems that it is installed as part of the Apache package, whether one wants it or not. I could be mistaken, but I certainly couldn't find a separate suexec package to remove. Which means that, despite things like "-D SUEXEC" options in the apache config... on Sabayon Linux, SuExec is ALWAYS enabled; all that the -D SUEXEC stuff does is enable SuExec to be configured. (*headdesk*)
So I performed unsanctioned surgery on my system: I renamed the /usr/sbin/suexec file to something else. That seemed to do the trick. No more complaints about suexec violations, and the PHP scripts all worked.
So tomorrow (or next week, anyway) I'll do the same thing to the server and the netbook so they are all compatible again.
This entry was originally posted at http://kerravonsen.dreamwidth.org/1056341.html. (Comments
) Respond here, or respond on the Dreamwidth post, as you prefer. You can use your DW login or OpenId there.
Before the new computer arrived, I had been able to set up my laptop as a server, and I have decided to leave it that way, as it was working fine in that capacity; it doesn't matter if a server doesn't have a working soundcard (oh boy have I been missing listening to music while I pecked away at the computer). I don't feel an urgent need for a replacement laptop, because the three things I've been using the laptop for, I don't necessarily need it for right now. The first, reading fanfic, I've been doing a lot more comfortably with my ebook reader. The other two, writing fic and coding while on the bus to work... well, I've been doing things like crocheting instead. And I still have my netbook, which could be used for that too.
Anyway... so the context is, new computer, and setting up new computer, bit by bit, not in a hurry.
And tonight I was trying to run a php script on the webserver on the new computer (so that I could mess with it without breaking it on the actual server) and I couldn't get it to run. Lots of uninformative error messages and googling later... very frustrated. Because I have a semi-complicated setup with Apache and SuExec and FastCGI in order to get PHP to run as my user, so that when it writes to files, they aren't owned by Apache, because that is a pain when I try to sync stuff between computers. And increasing frustration as I came across things like mpm-itk (which is supposed to be better than SuExec) and could not figure out how to install it on Sabayon Linux (which is what I use), and thinking "What am I doing all this for? I just want Apache to run as a given user!"
So, I started googling about Apache running as user.
Well.
Lightbulb moment.
My googling reminded me that there is a setting in the normal Apache config to set the user and group that Apache runs as - it's usually set to something like "nobody" or "apache"; and this is done for security reasons; the user needs to be a user that isn't root.
A user that isn't root.
Would it break anything if I set those values to my user and group? After all, I already run all my vhosts as my user and group anyway. Would it break the server to just set that directly, rather than using complicated workarounds such as SuExec and FCGI? I mean, obviously, one needs those things for a multi-user system with virtual hosts for different people, but I'm the only one using this system, so those considerations don't apply. So, would it break anything?
The answer to that was "yes and no".
Things that broke:
1. Logging. I anticipated this one; needed to set the owner of /var/log/apache2 to my user.
2. SuExec. This was a doozy.
See... at least on Sabayon Linux, when you turn off SuExec... you don't quite turn off SuExec. I mean, the obvious assumption is that when you change the configuration settings in the right places, it will turn off SuExec. So I did that.
But for some reason I don't understand, even though it wasn't loading the suexec module, apache was trying to run the /usr/sbin/suexec program. It complained that it didn't have the right permissions to run it (which it didn't because it was running as me instead of apache). So I tweaked some settings so that it did have permission... and then it complained that there were SuExec violations. Um. I thought it wasn't supposed to be running suexec since I'd turned it off in the config?
Well.
It seems that Apache in all its wisdom, decides whether it is running suexec NOT from the config, but from whether the program /usr/sbin/suexec exists on the system. If it does exist, it tries to run it, and if it runs, then suexec is enabled. (!?)
Now, with many Linux systems, one could solve that by uninstalling the suexec package and thereby removing the /usr/sbin/suexec program, but Sabayon doesn't have a separate suexec package; it seems that it is installed as part of the Apache package, whether one wants it or not. I could be mistaken, but I certainly couldn't find a separate suexec package to remove. Which means that, despite things like "-D SUEXEC" options in the apache config... on Sabayon Linux, SuExec is ALWAYS enabled; all that the -D SUEXEC stuff does is enable SuExec to be configured. (*headdesk*)
So I performed unsanctioned surgery on my system: I renamed the /usr/sbin/suexec file to something else. That seemed to do the trick. No more complaints about suexec violations, and the PHP scripts all worked.
So tomorrow (or next week, anyway) I'll do the same thing to the server and the netbook so they are all compatible again.
This entry was originally posted at http://kerravonsen.dreamwidth.org/1056341.html. (Comments
) Respond here, or respond on the Dreamwidth post, as you prefer. You can use your DW login or OpenId there.