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