Because it's more than just pure configuration, but a fpm pool
definition, I've changed the following variables in Ansible :
- php_fpm_defaults_conf_file to replaced by php_fpm_default_pool_file
- php_fpm_custom_conf_file to php_fpm_default_pool_custom_file.
On the FPM side, I've also changed the files names of the pool to make
them more explicit. No more z and zzz. It's the www pool, so let's put
www in the file name for coherence :
- z-evolinux-defaults.conf changes to www-evolinux-defaults.conf
- zzz-evolinux-custom.conf changes to www-evolinux-zcustom.conf
The default behavior for ansible template is to overwrite the
targeted file. Since we dont always want to overwrite a file when
we play this role, we set `force` to `False` by default. This means
that if the `dest` already exists, ansible will not overwrite it
with it's given template.
This is fine for most of the tasks in this role, but in the case
of `{{ evoadmin_scripts_dir }}/web-mail.tpl`,the file is created
by a task that runs prior to the template task, so setting it to
`False` by default means it never gets updated and clients dont get
notified when they create new websites.
Every 3 mins, systemd complain that the service file is marked as
executable, and asks the executable bit to be remove.
Nov 27 01:35:11 foo systemd[1]: Configuration file /etc/systemd/system/alert5.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Checking the existence of /etc/apache2 is not enough as a condition to
validate the presence of apache.
Indeed, some packages (including certbot!!!), put some files in
/etc/apache2/conf-available even if apache isn't installed.
In those cases, the check is not correct, and we'll enter in the apache
block, and fail when we try to enable the configuration.
With this commit, we now validate the presence apache with the presence
of /usr/sbin/apachectl
I've noticed that some log files, especially /var/log/syslog were empty.
After investigating, I've realized that it was happening after a log
rotation by logrotate.
The old mechanism, `invoke-rc.d rsyslog rotate` isn't working anymore on
Debian 10. It will fail with a not so explicit message :
[FAIL] Closing open files: rsyslogd failed!
Long story short, it seems that the pid file (`/run/rsyslogd.pid`) isn't
created any more, so start-stop-daemon as used by /etc/init.d/rsyslog
will fail. Explaining the error message.
Debian 10 rsyslog now brings `/usr/lib/rsyslog/rsyslog-rotate` that is
used by logrotate. It will send the signal HUP the 'right' way, so
rsyslog will be aware of the log rotation.
Sadly, this script isn't present in Debian 9 nor 8, so the logrotate
configuration for rsyslog is now a template, using the right command for
the right version.
Jérémy Lecour
Ludovic Poujol
Patrick Marchand
Victor LABORIE