+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.
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to