Re: 2.4.38
On Fri, Nov 09, 2018 at 02:15:07PM +1000, Noel Butler wrote: > even those distro package maintainers get sick to F'n death of it after > a while and skip updates. I do not see any reason I should get distinguished by it. Frequent version updates are even better for me. Petr
Re: 2.4.38
I’m all for this as well, because people want the new hotness. That said, for people downstream that have to support httpd, y’all are releasing really fast. I get it, and we haven’t really had any problems (minus a weird semaphore issue we haven’t tracked down yet), I’m noticing an increase of releases lately. Just curious what is the rush lately? Is this all a build up to 2.6 coming out or something else? > On Nov 8, 2018, at 3:11 AM, Stefan Eissing > wrote: > > >> Am 07.11.2018 um 16:15 schrieb Jim Jagielski : >> >> Now that we have a 2.4.37 out, one in which the number of enhancements and >> fixes and feature were limited, it makes sense to consider having a 2.4.38 >> release somewhat "soonish", esp considering the number of backports that >> lack only a single vote. >> >> Comments? > > I am all for it. And I have reasons! :-) > > 1. We are well on track to automate the whole thing nicely. We need some more > iterations to make it tight. This is easier done in short intervals. > 2. I think regular releases are good for the people here and motivate people > from outside to contribute. > 3. h2 and Let's Encrypt still get attention and there are some small > improvements I'd like to throw out there. Nothing serious, just would be nice. > > Cheers, > > Stefan Super off topic but this is one of the best communities I deal with in my day to day, even when y’all are mad you’re good to each other, means a lot to those of us that just need to follow the feed. Thank you all for that. Thanks, Cory McIntire Release Manager - EasyApache cPanel, L.L.C. smime.p7s Description: S/MIME cryptographic signature
Re: 2.4.38
On 08/11/2018 19:11, Stefan Eissing wrote: > 2. I think regular releases are good for the people here and motivate people > from outside to contribute. For people here.. what about the people not here, you know them, 99.9% of them, the system admins responsible for all those servers out there, they do not appreciate having to update shit every 2 weeks. 1/ they have better things to do 2/ it gives impression of immature and buggy software - this gives thoughts towards alternatives, IRC shows many admins have no loyalty todays much of todays software (well, windows fanbois excepted) 3/ As a consequence of 1 & 2, they will not upgrade, this might be trivial for little thigs, but when a nasty bug comes out, this is what comes to mind" oh fsck it, we just upgraded httpd last week, screw it, we'll wait" - they get bitten, CIOs demand heads, remaining souls dump httpd and install nginx or some other alternative 4/ dont be fooled into thinking its the package managers role, many networks run on RedHat EL, SuseEL, and debian, but far from all - and even those distro package maintainers get sick to F'n death of it after a while and skip updates. Do not be delusional - this has happened many times before. I give you dovecot as example, it wasnt that long ago a new release was coming out weekly, sometimes only a few days apart, people get sick of updating, some people are still today running versions a year old because of it, I know of a few who moved to "courier", an oldy but a goody. The release often mentality might be good for a new nurturing project, but that is not httpd. System admins want stability. flame away. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument
Re: 2.4.38
> Am 07.11.2018 um 16:15 schrieb Jim Jagielski : > > Now that we have a 2.4.37 out, one in which the number of enhancements and > fixes and feature were limited, it makes sense to consider having a 2.4.38 > release somewhat "soonish", esp considering the number of backports that lack > only a single vote. > > Comments? I am all for it. And I have reasons! :-) 1. We are well on track to automate the whole thing nicely. We need some more iterations to make it tight. This is easier done in short intervals. 2. I think regular releases are good for the people here and motivate people from outside to contribute. 3. h2 and Let's Encrypt still get attention and there are some small improvements I'd like to throw out there. Nothing serious, just would be nice. Cheers, Stefan
Exposing SSL certificates on SNI mismatch
Hi all, I have a customer asking about whether the SSL handshake can be made to fail in case the SNI from the "Client Hello" message doesn't match at all any server name of the configured virtual hosts. E.g. consider a setup like this DNS records: domain-a.tld resolves to domain-b.tld also resolves to Listen :443 https Listen :80 http :80> ServerName domain-a.tld ... :80> ServerName domain-b.tld :443> ServerName domain-b.tld SSLEngine On SSLCertificateFile <...a certificate file only valid for domain-b.tld> ... I.e. no virtual host with SSL enabled for domain-a.tld exists. In this setup the customer wants the server to not expose the SSL certificate of other, unrelated virtual hosts in case a client/browser tries to access https:/domain-a.tld/ (which isn't configured in Apache). Is this currently possible? If yes, in 2.4.x or only trunk? I remember a discussion thread of this topic floating by, but I can't find it anymore. Does anybody else maybe have a pointer to some public mail archive? Thanks a lot in advance for any comment, Micha
Re: 2.4.38
I like the idea. I even have a reminder in my calendar for Sunday titled "check if release is ready to roll" :-) I can RM again, even. -- Daniel Ruggeri On November 7, 2018 9:15:06 AM CST, Jim Jagielski wrote: >Now that we have a 2.4.37 out, one in which the number of enhancements >and fixes and feature were limited, it makes sense to consider having a >2.4.38 release somewhat "soonish", esp considering the number of >backports that lack only a single vote. > >Comments?
Re: Load balancing and load determination
I have a semi-working implementation that I'll be committing to trunk in a bit... > On Nov 8, 2018, at 1:33 AM, Mladen Turk wrote: > > On 30.10.2018. 13:53, Jim Jagielski wrote: >> As some of you know, one of my passions and area of focus is >> on the use of Apache httpd as a reverse proxy and, as such, load >> balancing, failover, etc are of vital interest to me. > > Been a while, but seems I'm back :D > Love the idea to have more intelligent then "lets guess" > way of deducting the load balancer score. > > What we did for heartbeat/heartmonitor/watchdog can be used > for collecting backend data. > > The thing I'm trying to do is the way that backend can > register or remove itself as node inside load balancer. > That would also require some sort of backend-server communication, > shared memory management (mod_slotmem maybe), and a way to > survive graceful restart. > > Backend sending its load status at regular intervals would > be addition to "I'm here, count me in" or > "I'm out, bye, good luck with other nodes". > > What do you think? > > > > Regards > -- > ^TM
