Hi Richard, Thank you for your email - I had re-added the missing modules and added all the vhosts/siteXX files but missed the conf.d/*.conf line below.
Time to go back over the mailing list. All the best, DD > -----Original Message----- > From: Blueonyx <blueonyx-boun...@mail.blueonyx.it> On Behalf Of Richard > Morgan > Sent: 07 March 2018 10:20 > To: 'BlueOnyx General Mailing List' <email@example.com> > Subject: [BlueOnyx:21818] Re: 5207R/5208R/5209R: Apache/SSL related updates - > URGENT > > Hi, there should be a few BX support messages that explain the problem from > Friday/Saturday and Sunday. > > I had the same problem and drew the same conclusion as you, then added > mod_perl and mod_ssl. > > It turns out the Include commands were missing from the end of httpd.conf. I > have something like: > > Include conf.d/*.conf > Include /etc/httpd/conf/vhosts/site1 > Include /etc/httpd/conf/vhosts/site2 > ... > > Then the line PerlConfigRequire ... should follow. > > I suggest you look at the support emails from a few days back but I'm sorry I > do not have the message numbers. > > Richard > > -----Original Message----- > From: Blueonyx [mailto:blueonyx-boun...@mail.blueonyx.it] On Behalf Of DD > Sent: 07 March 2018 09:45 > To: 'BlueOnyx General Mailing List' > Subject: [BlueOnyx:21817] Re: 5207R/5208R/5209R: Apache/SSL related updates > - URGENT > > Replying to myself, but... > > For whatever reason, LoadModule for mod_perl and mod_ssl were missing from > httpd.conf - I added those and can now save settings via the admin GUI > without it killing httpd. > > However, all sites still redirect to the BlueOnyx Login Page, even those > without SSL. > > > > DD > > > > -----Original Message----- > > From: Blueonyx <blueonyx-boun...@mail.blueonyx.it> On Behalf Of DD > > Sent: 07 March 2018 08:33 > > To: 'BlueOnyx General Mailing List' <firstname.lastname@example.org> > > Subject: [BlueOnyx:21816] Re: 5207R/5208R/5209R: Apache/SSL related > updates - > > URGENT > > > > Hi Michael / all. > > > > This morning all of my sites are unavailable - secure or otherwise. > > > > Restarting https gave me the following error: > > > > >[root@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@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-boun...@mail.blueonyx.it> On Behalf Of > > > Michael Stauber > > > Sent: 05 March 2018 22:36 > > > To: BlueOnyx General Mailing List <email@example.com> > > > 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@mail.blueonyx.it > > > http://mail.blueonyx.it/mailman/listinfo/blueonyx > > > > _______________________________________________ > > Blueonyx mailing list > > Blueonyx@mail.blueonyx.it > > http://mail.blueonyx.it/mailman/listinfo/blueonyx > > _______________________________________________ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it > http://mail.blueonyx.it/mailman/listinfo/blueonyx > > > _______________________________________________ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it > http://mail.blueonyx.it/mailman/listinfo/blueonyx _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx