+1 to Noels comments. We have a ton of servers running Apache 2.4 with our control panel. Doing this in a point release will cause us to have to change our product instead of doing a regular Apache release.
When you have a server with 10k+ SSL vhosts, this can cause massive, unexpected problems. I have a feeling that this will cause massive headaches with all those running Apache 2.4. — Jacob Perkins Product Owner cPanel Inc. jacob.perk...@cpanel.net <mailto:jacob.perk...@cpanel.net> Office: 713-529-0800 x 4046 Cell: 713-560-8655 > On Jun 11, 2015, at 8:37 PM, Noel Butler <noel.but...@ausics.net> wrote: > > On 12/06/2015 00:08, Jim Jagielski wrote: > >> >> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA. >> >> [ ] +1: Good to go >> [ ] +0: meh >> [ ] -1: Danger Will Robinson. And why. >> > -1 > > "The SSLCertificateChainFile directive () is deprecated, SSLCertificateFile > should be used instead" > > The constant warnings on start, stop, and even reload for every single SSL > host is unacceptable. > > This should never have been contemplated for a "point" release anyway. > > Clearly no consideration has been given to the headaches and collateral > damage this will cause, some hosts have tens of thousands of SSL hosts, even > a server reload will flood the hell out of them, most system/CP scripts look > for a specific, or no output, after reload, this results in unexpected output > and will trigger alarms, likely causing many systems to think " oh there was > a problem adding this host, so I wont continue adding them into anything else > and fail the entire new customer process" again, creating serious problems > for those required to maintain these things. > > > It might be fine and dandy for a stand alone single SSL host server that is > manually managed, but dont forget many hosts run up to 2+K hosts on a single > server with many of them SSL, that is a lot of change when you have a server > room half full of them, not to mention any inhouse scripting or control > panels that will need to be modified to cater for such changes to create the > new certs and deal with it all. > > > I for one will not place this release on any production servers. My > recommendation is that chainfile remain as it is - at the very least for the > 2.4 series, and if it is not enough to stop or delay this release to revert, > then I sincerely hope it is changed in trunk for the next. > >
signature.asc
Description: Message signed with OpenPGP using GPGMail