Folks
I'm having file-access problems in Apache 2.4 under Centos 7. In particular:
- I have a file that's readable to every user and every application, (writeable by only one user), but my CGI scripts cannot read it.
- Some of my CGI scripts need temporary storage for some files. They are, for example, some internal log files, tnat get cleaned up over time, but I want to be able to look at them (as root). Where would you suggest they be placed? I've tried /tmp/my_private_files/, and /var/tmp/my_private_files/, but Apache fails to find even the directory.
Any suggestions?
PS: Centos 6 had no such problems, and the file locations worked just fine.
David
On Mon, 2017-11-20 at 18:19 -0800, david wrote:
Folks
I'm having file-access problems in Apache 2.4 under Centos 7. In particular:
- I have a file that's readable to every user and every application,
(writeable by only one user), but my CGI scripts cannot read it.
- Some of my CGI scripts need temporary storage for some files. They
are, for example, some internal log files, tnat get cleaned up over time, but I want to be able to look at them (as root). Where would you suggest they be placed? I've tried /tmp/my_private_files/, and /var/tmp/my_private_files/, but Apache fails to find even the directory.
Any suggestions?
What is the status of selinux on your system? If it is on try switching to permissive mode.
Any error messages in /var/log/messages or your apache logs or audit logs?
Finally, have a look through the list archives as I seem to remember some discussion of this recently - specifically threads like:
https://lists.centos.org/pipermail/centos/2017-September/166000.html
P.
Hi David,
On Tue, Nov 21, 2017 at 3:19 AM, david david@daku.org wrote:
I'm having file-access problems in Apache 2.4 under Centos 7. In particular:
- I have a file that's readable to every user and every application,
(writeable by only one user), but my CGI scripts cannot read it.
- Some of my CGI scripts need temporary storage for some files. They are,
for example, some internal log files, tnat get cleaned up over time, but I want to be able to look at them (as root). Where would you suggest they be placed? I've tried /tmp/my_private_files/, and /var/tmp/my_private_files/, but Apache fails to find even the directory.
in the /usr/lib/systemd/system/httpd.service file change PrivateTmp=true to PrivateTmp=false and then "systemctl daemon-reload" and "systemctl restart httpd"
Regards Alex
On 23.11.2017 13:02, Alexander Farber wrote:
in the /usr/lib/systemd/system/httpd.service file change PrivateTmp=true to PrivateTmp=false and then "systemctl daemon-reload" and "systemctl restart httpd"
Please don't modifications in /usr/lib/systemd/system/. System updates will overwrite your changes.
official way is to copy the unit file to /etc/systemd/system and edit this copy.
best regards Ulf
official way is to copy the unit file to /etc/systemd/system and edit this copy.
that's one way to do it. It has the disadvantage of overriding *all* settings in the vendor-supplied unit files, which may be changed or extended in later releases.
I prefer the other supported way (see https://www.freedesktop.org/software/systemd/man/systemd.unit.html):
1. Create a directory named after the unit in /etc/systemd/system, /etc/systemd/system/httpd.service.d/
2. Create an override file within that directory, for instance private-tmp.conf, with the following contents:
[Service] PrivateTmp=false
3. Run "systemd daemon-reload" and "systemd restart httpd"
You can verify that the override file has been loaded with
[root@master1 ~]# systemctl status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/httpd.service.d └─private-tmp.conf
This will override only the setting you want to override and still survive updates.
Hi Gordon,
Or you could just run "systemctl edit httpd.service" like I suggested two days ago. :)
... which is a nice way of doing it quickly, indeed. Thanks for the hint, I didn't know that command.
However there is one disadvantage: All changes go into a file named 'override.conf', and if one wants to separate them it's still necessary to know where the configuration change is actually stored.
I do a lot of stuff with tools like Ansible these days and have made it a custom to keep separate configuration changes in separate files (and 'systemctl edit ...' wouldn't work well for that purpose anyway).
Cheers,
Peter.
-
Alexander Farber -
david -
Gordon Messmer -
Pete Biggs -
Peter Eckel -
Ulf Volmer