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' <blueonyx@mail.blueonyx.it> > 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 <blueonyx@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@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