[BlueOnyx:21811] 5207R/5208R/5209R: Apache/SSL related updates

[Michael Stauber]

Hi all,

I just published another set of updates that's supposed to get us closer
to the bottom of the strange SSL error that we're all sporadically
seeing. Namely that a HTTPS request to one Vsite is answered with the
SSL certificate of another Vsite (or the GUI itself).

This update moves all SSL related Apache settings from
/etc/httpd/conf.d/ssl_bx.conf to
/etc/httpd/conf.perl/00-default-vsite.pl in order to make sure these
settings are loaded earlier than anything else from /etc/httpd/conf.d/

I've also tweaked the settings some more to follow best practices as
suggested by the Apache documentation.

Lastly this update brings yet another perl-handler-utils update, in
which I modified Sauce::Service::Daemon(). This is a function which the
GUI uses to restart services.

This function has some special provisions in it for "problematic"
services that require some extra care. Such as Apache as well as the
AV-SPAM, but also for Xinetd.

Restarting Apache interactively in a script is - at best - a trick
undertaking. Regardless if the init service is InitV or Systemd. Ideally
we want as few Apache restarts as possible and we want them fast and
reliable if they cannot be avoided. The last thing we want is Apache
failing a restart and then being dead until Active Monitor picks up the
pieces.

Ideally an Apache restart would mean issuing a "reload" (because it's
faster), but an Apache "reload" will do exactly nothing if Apache is
already dead, has detached children or if it had locked up completely
for one reason or other.

Even a "restart" is unreliable in such cases, although it would give it
a honest try, which "reload" wouldn't.

We already had a bunch of checks looking for detached Apache children,
provisions to kill them off and then use "/sbin/service" or "systemctl"
to do a restart. Even then it sometimes didn't restart or came up askew.

For that reason I redesigned the procedure yet again: If Apache is asked
to do a "reload" or "restart" by the GUI, we do this:

1.) We check for detached Apache children. If present, we kill them off.

2.) If we had to kill off orphans, we use "/sbin/service" or "systemctl"
    to do a a clean Apache restart.

3.) If no orphans were present and Apache was running fine, we use ...
    5207R/5208R: pkill -HUP -x -f /usr/sbin/httpd
    5209R:       pkill -HUP -x -f "/usr/sbin/httpd -DFOREGROUND"
    .. to do a soft restart that reloads the config.

4.) After the restart or HUP we run three checks:

    - Orphanded Apache children present?
    - Do InitV or Systemd report that Apache is up?
    - Can we do a successful GET request to http://127.0.0.1/ ?

5.) If one of the three checks fail, we do another restart and check
    again.

You can spot these GET requests in your /var/log/httpd/access_log and
they look like this:

<server-name> 127.0.0.1 - - [05/Mar/2018:17:00:54 -0500] "GET /
HTTP/1.1" 200 182 "-" "BlueOnyx
Sauce::Service::Daemon(_check_apache_state) - Apache Check"

That is the restart mechanism trying to figure out if your Apache is
really up and responding with a "200" response code.

Under most normal conditions (no detached children, Apache not already
dead) running a HUP is less disruptive, yet it accomplishes a reliable
reload of the Apache configuration.

-- 
With best regards

Michael Stauber