[BlueOnyx:21818] Re: 5207R/5208R/5209R: Apache/SSL related updates - URGENT
Richard Morgan
richard at diamond-discovery.com
Wed Mar 7 05:20:29 -05 2018
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-bounces at 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-bounces at mail.blueonyx.it> On Behalf Of DD
> Sent: 07 March 2018 08:33
> To: 'BlueOnyx General Mailing List' <blueonyx at 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 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
>
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
More information about the Blueonyx
mailing list