[BlueOnyx:21816] Re: 5207R/5208R/5209R: Apache/SSL related updates - URGENT

[DD]

Hi Michael / all.

This morning all of my sites are unavailable - secure or otherwise.

Restarting https gave me the following error:

>[root at server admin]# service httpd restart
>Stopping httpd:                                            [  OK  ]
>Starting httpd: Syntax error on line 1003 of /etc/httpd/conf/httpd.conf:
>Invalid command 'PerlConfigRequire', perhaps misspelled or defined by a
module not included in the server configuration
                                                           [FAILED]

I can get into the admin console by commenting out the PerlConfigRequire
lines in httpd.conf and restarting httpd but the sites now redirect to the
BO login, and the first instance of PerlConfigRequire that I commented out
is rewritten, so any changes in Admin that restart Apache break the whole
thing again.

There are two lines of PerConfigRequite in httpd.conf, both reading:

	PerlConfigRequire /etc/httpd/conf.perl/00-default-vsite.pl

The file referenced is present.

Version info:
>[root at server admin]# cat /etc/redhat-release /etc/build
>CentOS release 6.9 (Final)
>build 20140909 for a 5208R in en_US

Obviously urgently requesting any info you can provide.,



Dick Dolby




> -----Original Message-----
> From: Blueonyx <blueonyx-bounces at mail.blueonyx.it> On Behalf Of Michael
> Stauber
> Sent: 05 March 2018 22:36
> To: BlueOnyx General Mailing List <blueonyx at mail.blueonyx.it>
> Subject: [BlueOnyx:21811] 5207R/5208R/5209R: Apache/SSL related updates
> 
> 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
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx