On 09/07/2016 03:19 PM, Rick Stevens wrote:
That didn't help either:
Sep 07 14:19:51 horse-magazine.info systemd[1]: Reloaded The Apache HTTP Server.
Sep 07 16:35:47 horse-magazine.info systemd[1]:
[/usr/lib/systemd/system/httpd.service:10]
Executable path is not absolute, ignoring: umask 002;/usr/sbin/httpd $OPTIONS
-DFOREGROUND
Sep 07 16:35:47 horse-magazine.info systemd[1]:
[/usr/lib/systemd/system/httpd.service:11]
Executable path is not absolute, ignoring: umask 002;/usr/sbin/httpd $OPTIONS -k
graceful
Sep 07 16:35:47 horse-magazine.info systemd[1]:
[/usr/lib/systemd/system/httpd.service:20]
Unknown lvalue 'umask' in section 'Service'
Sep 07 16:35:47 horse-magazine.info systemd[1]: httpd.service has no ExecStart= setting,
which is only allowed for Type=oneshot services. Refusing.
Emmett
On 09/07/2016 03:19 PM, Rick Stevens wrote:
That didn't help either:
Sep 07 14:19:51 horse-magazine.info systemd[1]: Reloaded The Apache HTTP Server.
Sep 07 16:35:47 horse-magazine.info systemd[1]:
[/usr/lib/systemd/system/httpd.service:10]
Executable path is not absolute, ignoring: umask 002;/usr/sbin/httpd $OPTIONS
-DFOREGROUND
Sep 07 16:35:47 horse-magazine.info systemd[1]:
[/usr/lib/systemd/system/httpd.service:11]
Executable path is not absolute, ignoring: umask 002;/usr/sbin/httpd $OPTIONS -k
graceful
Sep 07 16:35:47 horse-magazine.info systemd[1]:
[/usr/lib/systemd/system/httpd.service:20]
Unknown lvalue 'umask' in section 'Service'
Sep 07 16:35:47 horse-magazine.info systemd[1]: httpd.service has no ExecStart= setting,
which is only allowed for Type=oneshot services. Refusing.
Emmett
I finally figured out how to get the umask set for apache. Well actually
php-fpm.
In /usr/lib/systemd/system/php-fpm.server, add the line:
UMask=002
under the [Service] section. If you have other PHP versions running, like vis remi, yu
may want to add that line for those php-fpm.service files. Like
/usr/lib/systemd/system/php74-php-fpm.server for any site that requires PHP 7.4. Though
it is mostly Laravel sites where we need a specific PHP version, at least temporarily.
Now all files and directories created by my web server have group write set. This
supports wordpress sites as I enable local FTP for plugins and wordpress to use for
updates, and I set all directories to g+ws and set the group to the FTP user. In my case
I create a system user for each wordpress site, then cause proftp to allow local FTP
access to their home directory, which is sym linked to the wordpress site's root.
So wordpress automaticaly has the ability to write all files in the root directory. I
suppose we have to trust that wordpress will not write hacked files to the server's
root. So it behoovs our site webmasters to not unstall untrusted plugins. At least,
using local ftp prevents any access outside that site's web root.
Emmett