UseListenScheme proposal
Hi --
I thought I'd toss out a patch I've been working on lately; it's been
a long time since I committed directly, so if some of the "regulars"
wouldn't mind giving some feedback first, I'd appreciate it.
The idea is to introduce a non-default "UseListenScheme On" setting
which uses the scheme from the Listen directive when constructing
self-referencing URLs:
http://people.apache.org/~chrisd/patches/use_listen_scheme/
A full commit would also need patches to some of the non-Unix MPMs
(simple, winnt, netware, etc.), update-log-msg-tags needs to run,
docs need to be written, and so forth.
The impetus here came from the following situation; if you know of
better ways to address it, please describe them! We have virtual
hosts which serve both HTTP and HTTPS from behind SSL hardware, so
httpd only sees HTTP traffic, but on different ports. The preferred
configuration is:
Listen 10.0.0.0:4000
Listen 10.0.0.0:5000 https
NameVirtualHost 10.0.0.0:4000
NameVirtualHost 10.0.0.0:5000
LogFormat "... %{local}p ..." custom
ServerName www.example.com
CustomLog "|rotatelogs ... www.example.com:access.log ..." custom
...
The problem is that the vhost always constructs self-referencing URLs
for redirects, ProxyPassReverse handling, etc. using the "http://"; scheme.
We could have duplicate s, one for each port/scheme:
ServerName http://www.example.com
...
ServerName https://www.example.com
...
but then we have to duplicate all the vhost configs or split them into
out into Include files, and we end up with additional rotatelogs
processes either way.
I really just wanted httpd to notice that, according to the Listen
directive, all port 5000 traffic should use the "https://"; scheme;
I felt like I'd already supplied sufficient config data for it to
figure this out! :-)
The major caveat that I can see is that some folks might object
to having the overhead of apr_socket_data_get/set() calls after each
apr_socket_accept(). I thought perhaps a compile-time option such
as --disable-socket-data could be added to disable this proposed
new code entirely, for those who care.
Thoughts? Can anyone see a tidier way to approach this? (Any
volunteers to update the winnt and netware MPMs?)
Thanks very much,
Chris.
--
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
Re: [VOTE] The 'RM' Baton
On Wed, Jul 10, 2013 at 3:30 PM, Guenter Knauf wrote: > I was also thinking about learning how to release - but the lack of proper > documentation for the whole process holds me back; I remember how Graham > fell from one trap into another when he did his 1st APR release, and I dont > want to get same ... > so, if we want to have more folks doing more frequently releases the > startpoint would be to 1st document how a release is done: > - required auto* tools versions > - step by step description how to prepare for a release You guys may want to look at our release process over at the Subversion project: http://subversion.apache.org/docs/community-guide/releasing.html#release-creating We also have it somewhat automated. Including getting the right auto* tools versions. Of particular interest might be our release.py tool: http://svn.apache.org/repos/asf/subversion/trunk/tools/dist/release.py For actually rolling that python script ends up driving this shell script that I wrote long before the python script was developed: http://svn.apache.org/repos/asf/subversion/trunk/tools/dist/dist.sh All of this is obviously under ASLv2 so feel free to borrow and adapt. :)
Re: [VOTE] The 'RM' Baton
On 10.07.2013 15:22, Jim Jagielski wrote: Considering that I've been the only RM for 2.4.x, I can't help but assume that Bill is referring to me. As mentioned by others, by indicating a desire to T&R, it energizes people to catch up on STATUS, place their votes and propose backports. So it is *expected* that at a time when things should be the most "stable" (right before a "release"), that there is a flurry of activity. So what if it means a delay of a few weeks or even a month. The result is a *better* release for our users, which I think is even more important. well, but this concept is IMO not very efficient; often it happend that things were then backported in a rush to get things in with *this* pending release, and afterwards shows that it broke something on platforms which are not in the main focus (but that woudnt matter if we would release more often). Also it is not required for a new release to come with a ChangeLog of at least 10 entries - if we have only 5 then lets get the 5 to the users! I was also thinking about learning how to release - but the lack of proper documentation for the whole process holds me back; I remember how Graham fell from one trap into another when he did his 1st APR release, and I dont want to get same ... so, if we want to have more folks doing more frequently releases the startpoint would be to 1st document how a release is done: - required auto* tools versions - step by step description how to prepare for a release what would also help here is a way to do a test-release ... ;-) also I would be +++1 for making fix dates for releases, f.e. lets say 4 times a year which means all 3 months - and then doing the release *REGARDLESS* if we have thing hanging in STATUS or not! What doesnt go into this release does make it for the next, and that would then only be 3 months. But I would *NOT* vote for such unless I'm self able to do releases. As an example you may look at the libcurl project - we do there every ~2 months releases; one month for committing new stuff, and another month for testing and only bugfixes + looking at our autobuilds to see any regressions. Gün.
Re: apache process ps -aux
My mistake...first time on this forum. Thanks for the advice. -- View this message in context: http://apache-http-server.18135.x6.nabble.com/apache-process-ps-aux-tp5007013p5007063.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Threaded vs non-threaded dev package
I am compiling a module I have written on Ubuntu Precise. The module will always be run on apache-mpm-prefork (i.e. the non-threaded mpm), but the module itself uses threads (apr_thread*). Should I be compiling against apache2-threaded-dev or apache2-prefork-dev? Or doesn't it matter? -- Alex Bligh
Re: [discuss] The 'RM' Baton [was: VOTE]
On Wed, 10 Jul 2013 21:38:00 +0200 Graham Leggett wrote: > On 10 Jul 2013, at 9:09 PM, "William A. Rowe Jr." > wrote: > > > At what times was the tree 'open to tag' by any RM? You effectively > > placed a block on potential release activity and held STATUS hostage > > to your whims for well over 1/2 of the past 12 months, but rarely > > met a commit date, and often held it hostage with no specific > > commitment. > > I don't follow, at no point have I ever interpreted someone saying > "I'll RM" as "stand back - I have the baton and nobody is allowed to > do anything until I say so". All it means is "I'll RM", nothing more. Which is a reservation. > If someone doesn't RM when they said they would, it is probably > because something came up, or perhaps a security issue appeared and > they hope that it be resolved, or any of a number of reasons. Nothing > stops someone else stepping up to say "mind if I take over? I want to > see this out the door". And dev@ is a wonderful place for communicating both the intent to roll and offer to pick up the responsibility from another, agreed. A section titled 'Release History:' is not the place to record that back-and-forth negotiation of what should be released, and when.
Re: Whereforeartthou, 2.5.0?
On Wed, 10 Jul 2013 21:30:30 +0200 Graham Leggett wrote: > > Can you explain the current rush to release trunk a mere 18 months > after we've released v2.4? I don't see the urgency at all. Graham, thank you for reiterating my point :) /trunk/ is simply premature and an unnecessary obstacle to contributing to 2.4.x, so long as there is no plan to release 2.5.0-alpha. > I also don't see any "mental gymnastics" going on, what I see is our > Review Then Commit process under strain because of a significant > amount of activity on trunk. I believe this is not a problem, > activity is good. Except that trunk is not 2.4.x and will continue to drift. The question before us is whether such drift should be on the contributors of the patches which cause drift? Or on each and every contributor to compensate for that drift? > Stability is good. I don't want the stuff going on in trunk to hit > the stable branch without those 3 +1 votes, even if the wait is > painful. I will agree with you once 2.4 reaches adoption. IBM released 2.0.16 and of course struggled to keep it looking anything like 2.0.current, which was impossible before 2.0.36 or 2.0.42. That was a very dynamic and vibrant time period in this project's history. Others shipped around that 2.0.36-2.0.42 period and that is when reversioning rules were changed to lock in additional stability. I don't see the need for excessive votes for stability for code that is not widely adopted. Even a dud release does not concern me, we patch the regression, release and move on. This (ASF) software is non-commercial, free to the public and if it breaks, as open source, they get to keep all of the pieces. But the code under development is not being shared with the public as a release, which is not in line with the charter of the foundation. > If I could wave my magic wand I'd like to see more people get > involved, but then activity generates activity, so this is not a > problem either. And I've suggested (in another thread) that activity on 2.4.x would attract more activity and more active review of the committed code, whereas code relegated to a sandbox or an unreleased /trunk/ will not get as many eyeballs or participation. My 2c US. Bill
Re: [discuss] The 'RM' Baton [was: VOTE]
On 10 Jul 2013, at 9:09 PM, "William A. Rowe Jr." wrote: > Right, but let's just take a look at our official STATUS and how you > have treated it in the past year, and how that differed from 2.2... > > http://markmail.org/search/?q=%22.z+versions+are+Stable%2FGA+releases.%22+2.4.2+list%3Aorg.apache.httpd.cvs+order%3Adate-backward#query:%22.z%20versions%20are%20Stable%2FGA%20releases.%22%202.4.2%20list%3Aorg.apache.httpd.cvs%20order%3Adate-backward+page:1+mid:n6rwwa2jfc2of6to+state:results > > At what times was the tree 'open to tag' by any RM? You effectively > placed a block on potential release activity and held STATUS hostage > to your whims for well over 1/2 of the past 12 months, but rarely met > a commit date, and often held it hostage with no specific commitment. I don't follow, at no point have I ever interpreted someone saying "I'll RM" as "stand back - I have the baton and nobody is allowed to do anything until I say so". All it means is "I'll RM", nothing more. If someone doesn't RM when they said they would, it is probably because something came up, or perhaps a security issue appeared and they hope that it be resolved, or any of a number of reasons. Nothing stops someone else stepping up to say "mind if I take over? I want to see this out the door". Regards, Graham --
Re: Whereforeartthou, 2.5.0?
On 10 Jul 2013, at 8:19 AM, "William A. Rowe Jr." wrote: > Fellow PMC folk... > > I think everyone on this list can agree that the pace of releases has > slowed to a crawl; we are 6+ mos between releases of our active/stable > 2.4 series, which has little if any adoption, and are equally lethargic > about the actually stable-and-adopted 2.2 releases. This is a thread > which we have visited before many times, but I'd like to throw a new > spin on it and consider whether we have taken several group decisions, > and combined them into the worst results possible from the lot of them. > > My question to the group; is /repos/asf/httpd/httpd/trunk/ actually > a trunk? Or is it a sandbox? All ASF projects have one goal, which > is to release open source code to the public at no charge. What is > currently brewing as /repos/asf/httpd/httpd/trunk/ has a version # > designation, but no plan to release, and no release in several years. > > I would humbly submit that with no plan to release, /trunk/ is simply > a sandbox, and should be svn mv'ed to the appropriate svn branch for > those developers to retrieve, maintain and later advance their proposals > into an actual 2.5.0 release trunk at some future date. > > I'm watching a ton of mental gymnastics by the few who are willing to > fight with this bureaucracy to commit to a non-release trunk, plea for > backport votes, then perhaps get their code into 2.4 (which is not yet > even distributed by anyone other than the ASF and adopted by almost no > users at all). The entire model, IMHO, is broken by mixing too many > of our consensus concepts in the most inefficient manner. Can you explain the current rush to release trunk a mere 18 months after we've released v2.4? I don't see the urgency at all. I also don't see any "mental gymnastics" going on, what I see is our Review Then Commit process under strain because of a significant amount of activity on trunk. I believe this is not a problem, activity is good. Stability is good. I don't want the stuff going on in trunk to hit the stable branch without those 3 +1 votes, even if the wait is painful. If I could wave my magic wand I'd like to see more people get involved, but then activity generates activity, so this is not a problem either. Regards, Graham --
Re: apache process ps -aux
On Wed, Jul 10, 2013 at 10:52 AM, peter_bateman wrote: > Hello All, > > I know this may be a newbie question, Newbie or not, use the users@httpd mailing list for this sort of thing ;) > however when i run the following > command, all of my apache processes are listed with -k start. I have an > example listed below: > > ps -aux | grep apache | grep -v grep > apache 22397 3.5 0.3 360224 28476 ?S09:39 0:08 > /usr/sbin/httpd -k start > apache 22559 10.3 0.4 365472 34572 ?S09:39 0:23 > /usr/sbin/httpd -k start > apache 22721 4.9 0.3 363376 32588 ?S09:39 0:11 > /usr/sbin/httpd -k start > apache 22723 5.2 0.3 363692 32112 ?R09:39 0:11 > /usr/sbin/httpd -k start > apache 23059 6.0 0.3 361404 29824 ?S09:35 0:27 > /usr/sbin/httpd -k start > apache 25198 4.4 0.3 361636 29752 ?S09:36 0:19 > /usr/sbin/httpd -k start > apache 25396 5.1 0.3 360356 28736 ?S09:36 0:22 > /usr/sbin/httpd -k start > apache 28921 8.1 0.3 359324 27904 ?S09:40 0:15 > /usr/sbin/httpd -k start > apache 29474 4.6 0.3 359200 27708 ?S09:40 0:08 > /usr/sbin/httpd -k start > apache 31748 5.0 0.3 362396 31272 ?S09:32 0:33 > /usr/sbin/httpd -k start > > I was wondering if anyone has any insight as to why the process is listing > the -k start? I have never seen this on any of my other websevers, > typcially > they just show "0:33 /usr/sbin/httpd". > It was largely explained already. There's a perhaps obvious bit that didn't seem to be mentioned: Both "/usr/sbin/httpd" and "/usr/sbin/httpd -k start" are valid ways to start the server. Different scripts could be used in one environment vs. another or one start mechanism vs. another. > > I am running Centos 5.3, Server version: Apache/2.2.3 > Server built: Jan 21 2009 22:00:55 > > Any help would be appreciated :) > > Regards, > > peter_bateman > > > > -- > View this message in context: > http://apache-http-server.18135.x6.nabble.com/apache-process-ps-aux-tp5007013.html > Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com. > -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Lazy Consensus for 2.4.x backports
On Wed, Jul 10, 2013 at 3:09 PM, Eric Covener wrote: > > If I count right, 80% or more of the fixes potentially in 2.4.next are > > already there (I didn't count mod_lua.) That doesn't seem so bad. > > FWIW, I had a flurry of trivial fixes in trunk that I didn't want to > derail/delay 2.4.5 with, which inflates the remaining 20% a bit. > My set for "fixes potentially in 2.4.next" was stuff still in 2.4.x/STATUS stuff in 2.4.x/CHANGES other than mod_lua fixes There's any number of reasons why something is in trunk but never proposed for backport, so I didn't consider it. (IOW, it needs at least one proponent to potentially be in a stable release.) -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [discuss] The 'RM' Baton [was: VOTE]
On Wed, 10 Jul 2013 13:59:46 -0400
Jim Jagielski wrote:
>
> On Jul 10, 2013, at 1:34 PM, William A. Rowe Jr.
> wrote:
> >
> > Note that the release windows we are discussing have been far longer
> > than a month (or I would not have bothered to bring this up), fair?
> > For example, 2.0.65 was lingering almost a year. 2.4.5 is now into
> > its second month, you offered to RM back in May.
> >
>
> So?
> [...]
> From all that, the release cycles between 2.2 and 2.4 are NOT
> all that much out of whack, although I DO agree that going from 2-4-6
> months is a trend we want to avoid and looking for a release every 4
> months or so seems optimal. And, if you look, that is the timing that
> I've been trying to push.
Right, but let's just take a look at our official STATUS and how you
have treated it in the past year, and how that differed from 2.2...
http://markmail.org/search/?q=%22.z+versions+are+Stable%2FGA+releases.%22+2.4.2+list%3Aorg.apache.httpd.cvs+order%3Adate-backward#query:%22.z%20versions%20are%20Stable%2FGA%20releases.%22%202.4.2%20list%3Aorg.apache.httpd.cvs%20order%3Adate-backward+page:1+mid:n6rwwa2jfc2of6to+state:results
At what times was the tree 'open to tag' by any RM? You effectively
placed a block on potential release activity and held STATUS hostage
to your whims for well over 1/2 of the past 12 months, but rarely met
a commit date, and often held it hostage with no specific commitment.
I think this practice has to stop. The STATUS 2.4.{next} line should
never have become a reservation. It is a simple statement of fact
(development? tagged? released? abandoned?)
That is the practice of yours which has particularly put me off to
your 2.4 development efforts, and if you want to collaborate, it would
be best to communicate an intent to roll through the dev@ list which
you had also done, admirably. And this is probably a better solution
than designating a 10 day window or whatnot to achieve an announced
tag and roll.
Re: [VOTE] Lazy Consensus for 2.4.x backports
> If I count right, 80% or more of the fixes potentially in 2.4.next are > already there (I didn't count mod_lua.) That doesn't seem so bad. FWIW, I had a flurry of trivial fixes in trunk that I didn't want to derail/delay 2.4.5 with, which inflates the remaining 20% a bit.
Re: Hey Steinar... Re: Revisiting the pre_htaccess hook
On Wed, Jul 10, 2013 at 2:30 PM, Stefan Fritsch wrote: > On Wednesday 10 July 2013, Steinar H. Gunderson wrote: > > I don't like all that much having to duplicate the “official” hook > > (in particular the ap_make_full_path() call), but I guess it's > > better than what used to be there, and it's only two lines. > > Yes, that's the price to pay for the more flexible hook which supports > additional use cases. I think these two lines are acceptable. > I think this issue was the original objection to solving the problem with this particular API (voiced or unvoiced), but I agree that the additional use cases make it worthwhile. I guess "it seems to work" in the earlier e-mail is the validation that the API is sufficient for MPM-ITK. > Cheers, > Stefan > -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Lazy Consensus for 2.4.x backports
On Wed, Jul 10, 2013 at 2:03 PM, Jim Jagielski wrote: > Pulling this out as a proposal: > > I propose that we track all backports in 2.4 STATUS as we currently > do. Each backport is time-tagged and we operate under a lazy > consensus. Assuming no -1 votes within 96 hours, the backport > can be applied to 2.4.x. If the backport gets 3 +1 votes sooner > than that, then it can be applied asap... > > As with ALL patches, any commit can be reverted for good > technical (or legal) reasons. > > [ ] +1: Agree with this proposal (to start post 2.4.5 release) > [ ] -1: Disagree with this proposal (and why) > > -1 The current process * works well/appropriately IMO; to me that means pretty good stream of fixes to 2.4.x without too high a risk of regressions * has demonstrably resulted in a reasonably small number of regressions so far across 2.4.x and earlier releases (definitely not zero regressions, but pretty darn low). I think that it is a safe assumption that there will be code changes in stable releases that have had less review if we make this change. Largely regression-free stable releases are of crucial importance for infrastructure software like httpd, more so than getting another window-size worth of fixes into the release, especially if they've been looked at less than the others. If I count right, 80% or more of the fixes potentially in 2.4.next are already there (I didn't count mod_lua.) That doesn't seem so bad. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Lazy Consensus for 2.4.x backports
On Wed, 10 Jul 2013 14:03:53 -0400 Jim Jagielski wrote: > Pulling this out as a proposal: > > I propose that we track all backports in 2.4 STATUS as we currently > do. Each backport is time-tagged and we operate under a lazy > consensus. Assuming no -1 votes within 96 hours, the backport > can be applied to 2.4.x. If the backport gets 3 +1 votes sooner > than that, then it can be applied asap... > > As with ALL patches, any commit can be reverted for good > technical (or legal) reasons. > > [X] -1: Disagree with this proposal (and why) Agreed in part, that *major* backports (or activity, if we did set aside /trunk/ for the near-term) are tracked in STATUS with lazy consensus. I actually thought the 72 hours was not a bad window. I would think a +/-0 with discussion would be enough to add some days for deeper consideration of a proposal. Disagree in part, that minor backports (or activity, if we did set aside /trunk/ for the near-term) do not need STATUS and should not have the obstacle of STATUS tracking.
Re: Whereforeartthou, 2.5.0?
On Wed, 10 Jul 2013 20:20:22 +0200 Stefan Fritsch wrote: > On Wednesday 10 July 2013, William A. Rowe Jr. wrote: > > > What I am asking, is whether that trunk is a sandbox to hack in, or > > whether is is approaching a releasable state? I'm asking, whether > > trunk is a worthwhile exercise or a distraction and complication to > > fixing and enhancing the shared, released project code, > > branches/2.4.x? > > trunk is needed for changes that break API/ABI compatibility. And I > think it is also very useful for complex changes that take time to > get into a releasable state. If you take that away, the result will > be that branches/2.4.x-renamed-to-trunk will not be always in a > releasable state, because it will contain unfinished/broken changes. I am not proposing to eliminate these. I am proposing that these be parceled into sandboxes, until such time as we are ready to create a 2.5.0-alpha release. That time doesn't seem to be right now. The advantage is that each change can be reviewed and enhanced in its own right by anyone (literally, we have opened the sandbox to all ASF committers, right?) By ensuring each developer who is either breaking changes or offering a complex patch shepherds the change into 2.4.x or a future 2.5.0-alpha trunk candidate, we will ensure they don't languish and become troublesome debugging efforts when they are finally noticed by the -alpha testing community, some year or years after they are first committed. These can certainly be tracked in STATUS. Sandboxes are useful things (as I suggested, this could become a whole svn vs. git debate, but the mechanics are similar enough to avoid that discussion for now). I'd maintain that working around 'future ABI breaking proposals' today by all of the committers, rather than simply by the patch's champion(s), is imposing unnecessary complexity on the rest of the project. > This may deter people from volunteering as RM because they would > first have to clean up the mess by fixing open issues or reverting > changes. And the quality of 2.4 releases will probably suffer, too. The converse is also true. If 2.4 is 'broken', that is where most of our eyes are at (that, and 2.2, hopefully everyone has fun rm -rf'ing their 2.0 checkouts this week :) Such breakage is unlikely to last. The rules of CTR are pretty specific about big breaking changes - we propose them to the list first. Better yet, submit them as a sandbox where others can debug them. Then svn cp them into place when the devs agree we are ready for the change. But discussing the small changes, were it simply CTR, then that review simply happens. If you don't like the change, you need to respond and watch development. While the changes sit in a non-release /trunk/ they are ignored at the time they are authored. Even the author may forget where they were going with a patch by the time feedback arrives. With CTR there is an immediacy for reviewers to follow-along with the effort which may revive some participation. Committers are protective of the code they use (or hope to use soon, in the case of the widely-unadopted 2.4), but less so of some intangible code tree that may have little relevance for the next 1-3 years. > The same is true if we make 2.4 completely CTR or the 72 hour scheme > proposed by Jim. But I would be open to CTR 2.4 for some classes of > changes, maybe simple bug fixes with no (public or private) API > change, or for changes that have reasonable test coverage in the test > framework. That is pretty much what I am suggesting, and believe that STATUS for every minor change is quite a bit of overkill. STATUS is great to point people at major refactorings, new works, ap_mmn bumping changes and the like. > WRT 2.5/2.6, I very much hope that it will not take as long as the > 2.2->2.4 cycle. I am pretty sure that we cannot reasonably support > SPDY/HTTPbis/HTTP2.0 in 2.4, so we will need a 2.6 in the forseeable > future. Almost agree, I suspect that would become 3.0 though. But since that is in the distant-foreseeable future and we may be facing new competing solutions to these problems, sandboxes seem like a better solution till some -alpha release is more than a far-off possibility. Once we are rowing together on an -alpha for a near-term 2.6 or 3.0 major release, the current /trunk/ -> backport strategy once again will make good sense. But the code in 2.4.x, while released, is simply not adopted. We don't have the frustrations of 2.0 or 2.2 where they are widely deployed and consumed by many downstream packagers, at least not yet. Bill
Re: Whereforeartthou, 2.5.0?
> WRT 2.5/2.6, I very much hope that it will not take as long as the > 2.2->2.4 cycle. I am pretty sure that we cannot reasonably support > SPDY/HTTPbis/HTTP2.0 in 2.4, so we will need a 2.6 in the forseeable > future. I think as big/disruptive as that will be, and as unlikely as a meaningful release w/o HTTP/2.0, 2.4 will have a "full" life.
Re: Whereforeartthou, 2.5.0?
All good points... IMO, if people consider themselves a 2.4 developer, their *primary* repo to be working on MUST be trunk... all their work and *testing* must be on that codebase. Yes, trunk exists for sandbox type of work, but it also is the ONLY way that code gets backported to 2.4, so at present it's serving dual roles. Which may not be optimal. On Jul 10, 2013, at 2:20 PM, Stefan Fritsch wrote: > On Wednesday 10 July 2013, William A. Rowe Jr. wrote: >> Jim Jagielski wrote: >>> In any case, I *am* concerned that w seem to have quite a bit of >>> difficulty in getting 3 +1s a lot of the time and that the >>> backport process from trunk to 2.4 is becoming more and more >>> painful. [...] > > Jim, I think you are particularily affected by that problem because > you hack a lot on mod_proxy, which is a complex beast. Of the few > active committers, not all are comfortable reviewing changes there. > The same is probably true for Graham and mod_cache. > >> What I am asking, is whether that trunk is a sandbox to hack in, or >> whether is is approaching a releasable state? I'm asking, whether >> trunk is a worthwhile exercise or a distraction and complication to >> fixing and enhancing the shared, released project code, >> branches/2.4.x? > > trunk is needed for changes that break API/ABI compatibility. And I > think it is also very useful for complex changes that take time to get > into a releasable state. If you take that away, the result will be > that branches/2.4.x-renamed-to-trunk will not be always in a > releasable state, because it will contain unfinished/broken changes. > This may deter people from volunteering as RM because they would first > have to clean up the mess by fixing open issues or reverting changes. > And the quality of 2.4 releases will probably suffer, too. > > The same is true if we make 2.4 completely CTR or the 72 hour scheme > proposed by Jim. But I would be open to CTR 2.4 for some classes of > changes, maybe simple bug fixes with no (public or private) API > change, or for changes that have reasonable test coverage in the test > framework. > > WRT 2.5/2.6, I very much hope that it will not take as long as the > 2.2->2.4 cycle. I am pretty sure that we cannot reasonably support > SPDY/HTTPbis/HTTP2.0 in 2.4, so we will need a 2.6 in the forseeable > future. >
Re: Letting 2.5.x sit idle? [Was: The 'RM' Baton]
On Jul 10, 2013, at 2:18 PM, William A. Rowe Jr. wrote: > > I found these comments from STATUS rather ironic; > > -0.5: sf: I would prefer if this sat in trunk for a few months first > to receive more testing. > > +0.5: jj: I would prefer if this sat in trunk for a few months first > to receive more testing. > > What testing? With no (-alpha or -beta) release, there will be few > (if any) testers. Only committers. > > Heck, why would a user check out /trunk/? The code they are running > is likely 2.2.x with a hope to upgrade to 2.4.x. For any real world > user, our /trunk/ is a rather distant place. > Bill, how is ANY of this new and different? Are you saying that in the "old days" people did checkout and test trunk and that they aren't now (or pulled HEAD)? Or that we now do beta or RC releases between 2.4.x and 2.4.x+1 ? Or that stuff in trunk goes immediately into 2.4? Or what? IMO, we need more people to follow the code instead of (or in addition to) posting bikeshed email threads.
Re: Hey Steinar... Re: Revisiting the pre_htaccess hook
On Wednesday 10 July 2013, Steinar H. Gunderson wrote: > I don't like all that much having to duplicate the “official” hook > (in particular the ap_make_full_path() call), but I guess it's > better than what used to be there, and it's only two lines. Yes, that's the price to pay for the more flexible hook which supports additional use cases. I think these two lines are acceptable. Cheers, Stefan
Re: The 'RM' Baton
Am 10.07.2013 20:18, schrieb William A. Rowe Jr.: > Precisely. With mod_perl, they can pick it up in their next cycle. It > has been a very long time since 2.4.0, certainly within some of the > bleed releases, but without mod_perl nobody would make the jump. > > It isn't inconcievable that 2.4.x is replaced by 2.6.x before any of > the packagers jump up beyond 2.2, and that isn't necessarily a bad > thing, IMHO. not really Fedora 18 has Apache 2.4 since 6 months RHEL7 will be based on F18/F19 and also replaces MySQL with MariaDB it is not a must but most likely that it will also ship Apache 2.4 and new setups from RH customers most likely will install RHEL7 after it is available because the longer LTS signature.asc Description: OpenPGP digital signature
Re: Whereforeartthou, 2.5.0?
On Wednesday 10 July 2013, William A. Rowe Jr. wrote: > Jim Jagielski wrote: > > In any case, I *am* concerned that w seem to have quite a bit of > > difficulty in getting 3 +1s a lot of the time and that the > > backport process from trunk to 2.4 is becoming more and more > > painful. [...] Jim, I think you are particularily affected by that problem because you hack a lot on mod_proxy, which is a complex beast. Of the few active committers, not all are comfortable reviewing changes there. The same is probably true for Graham and mod_cache. > What I am asking, is whether that trunk is a sandbox to hack in, or > whether is is approaching a releasable state? I'm asking, whether > trunk is a worthwhile exercise or a distraction and complication to > fixing and enhancing the shared, released project code, > branches/2.4.x? trunk is needed for changes that break API/ABI compatibility. And I think it is also very useful for complex changes that take time to get into a releasable state. If you take that away, the result will be that branches/2.4.x-renamed-to-trunk will not be always in a releasable state, because it will contain unfinished/broken changes. This may deter people from volunteering as RM because they would first have to clean up the mess by fixing open issues or reverting changes. And the quality of 2.4 releases will probably suffer, too. The same is true if we make 2.4 completely CTR or the 72 hour scheme proposed by Jim. But I would be open to CTR 2.4 for some classes of changes, maybe simple bug fixes with no (public or private) API change, or for changes that have reasonable test coverage in the test framework. WRT 2.5/2.6, I very much hope that it will not take as long as the 2.2->2.4 cycle. I am pretty sure that we cannot reasonably support SPDY/HTTPbis/HTTP2.0 in 2.4, so we will need a 2.6 in the forseeable future.
Re: Letting 2.5.x sit idle? [Was: The 'RM' Baton]
On Wed, 10 Jul 2013 19:54:00 +0200 Stefan Fritsch wrote: > On Wednesday 10 July 2013, William A. Rowe Jr. wrote: > > > > In practice, 2.2 is the stable release, from what users experience. > > This stems in part from the > 5 years between 2.2 and 2.4. 2.4 simply > takes some time to stabilize. 2.2 did so, too (at the company I was > working for at the time, we started adoption with 2.2.8 or so). I think 2.2.4 was the first I found to be usable (or 2.2.3 with lots of band-aids and bubblegum). But what of 2.6? This was the "wrong thread", again, but if /trunk/ drifts along for 2 years, are we going to have an equally horrid experience? Or should we set aside /trunk/ and re-fork it only once we are truly committed to putting 2.5.0-alpha in users hands for real testing, and feedback? I found these comments from STATUS rather ironic; -0.5: sf: I would prefer if this sat in trunk for a few months first to receive more testing. +0.5: jj: I would prefer if this sat in trunk for a few months first to receive more testing. What testing? With no (-alpha or -beta) release, there will be few (if any) testers. Only committers. Heck, why would a user check out /trunk/? The code they are running is likely 2.2.x with a hope to upgrade to 2.4.x. For any real world user, our /trunk/ is a rather distant place. So I'd argue that /trunk/ is an unhealthy place right now which does not have testing. If we want /trunk/ to become 2.6, we have to start by releasing 2.5.0-alpha and offering it up to users. If we don't believe it's ready, why does it exist at all? Why not relegate it to the sandbox and move 2.4.x back to trunk, which it effectively is? > > The post from the modperl project relayed by Jim this past week is > > very welcome news, for getting 2.4 adopted by downstream packagers! > > And the other part of the problems is distributions not picking 2.4 > up early because of mod_perl missing and/or because of 2.4 being > released at an unfortunate point of time in the distribution's own > release cycle. Precisely. With mod_perl, they can pick it up in their next cycle. It has been a very long time since 2.4.0, certainly within some of the bleed releases, but without mod_perl nobody would make the jump. It isn't inconcievable that 2.4.x is replaced by 2.6.x before any of the packagers jump up beyond 2.2, and that isn't necessarily a bad thing, IMHO.
[VOTE] Lazy Consensus for 2.4.x backports
Pulling this out as a proposal: I propose that we track all backports in 2.4 STATUS as we currently do. Each backport is time-tagged and we operate under a lazy consensus. Assuming no -1 votes within 96 hours, the backport can be applied to 2.4.x. If the backport gets 3 +1 votes sooner than that, then it can be applied asap... As with ALL patches, any commit can be reverted for good technical (or legal) reasons. [ ] +1: Agree with this proposal (to start post 2.4.5 release) [ ] -1: Disagree with this proposal (and why)
Re: [discuss] The 'RM' Baton [was: VOTE]
On Jul 10, 2013, at 1:34 PM, William A. Rowe Jr. wrote: > > Note that the release windows we are discussing have been far longer > than a month (or I would not have bothered to bring this up), fair? > For example, 2.0.65 was lingering almost a year. 2.4.5 is now into > its second month, you offered to RM back in May. > So? Let's look at 2.2.x: 2.2.24 : Released February 25, 2013 2.2.23 : Released September 13, 2012 5 months 2.2.22 : Released January 31, 2012. 8 months 2.2.21 : Released September 13, 2011. 4 months 2.2.20 : Released August 30, 2011. 1 month 2.2.19 : Released May 21, 2011. ABI restored. 3 months 2.2.18 : Released May 11, 2011. ABI broken. 2.2.17 : Released October 19, 2010. 7 months 2.2.16 : Released July 25, 2010. 3 months 2.2.15 : Released March 6, 2010. 4 months 2.2.14 : Released October 3, 2009. 5 months 2.2.13 : Released August 8, 2009. 2 months 2.2.12 : Released July 28, 2009. 1 month 2.2.11 : Released December 14, 2008. 7 months 2.2.10 : Released October 14, 2008. 2 months 2.2.9 : Released June 14, 2008. 4 months 2.2.8 : Released January 19, 2008. 5 months 2.2.6 : Released September 7, 2007. 4 months 2.2.4 : Released on January 9, 2007 as GA. 8 months 2.2.3 : Released on July 28, 2006 as GA. 6 months 2.2.2 : Released on May 1, 2006 as GA. 2 months 2.2.0 : Released on December 1, 2005 as GA. 5 months Now 2.4: 2.4.4 : Tagged on February 18, 2013. Released Feb 25, 2013 2.4.3 : Tagged on August 17, 2012. Released Aug 18, 2012 6 months 2.4.2 : Tagged on April 5, 2012. Released Apr 17, 2012. 4 months 2.4.1 : Tagged on February 13, 2012. Released Feb 21, 2012. 2 months 2.4.0 : Tagged on January 16, 2012, not released. With 2.4.5 being ~ 5 months. From all that, the release cycles between 2.2 and 2.4 are NOT all that much out of whack, although I DO agree that going from 2-4-6 months is a trend we want to avoid and looking for a release every 4 months or so seems optimal. And, if you look, that is the timing that I've been trying to push.
Re: [discuss] The 'RM' Baton [was VOTE]
On Wednesday 10 July 2013, William A. Rowe Jr. wrote: > On Wed, 10 Jul 2013 21:18:06 +1000 > > Noel Butler wrote: > > on holiday with a dog slow 3G vpn tonight, so I'll be brief (and > > wont see any replies until I return on Sunday...) > > > > I have never agreed with any "release often" principle, a project > > that releases often (more than a few times a year) to me says > > "immature instability" compared to a project that releases once > > or twice a year (barring critical bug resolutions) - IOW, > > release when necessary not just because its a "cool thing to > > do". Take dovecot for instance, we stayed on the stable 1.2 > > series for more than a year after it was EOL, because its 2.0.x > > kept having fixes and releases every couple of weeks for a > > while, admins dont like that, it gives them no warm feelings > > towards stability. > > On the other hand, waiting 6 mos for a 'complete' release also > implies that users are waiting for other fixes for 5 months. > Reviewing CHANGES helps admins to determine if those fixes in a > more frequent release cadence do address specific needs of each > specific admin. > > > WRT slow take up of 2.4.x, I agree, the incentive (as was > > discussed 2 years or so ago) was to EOL 2.0, and what needs > > doing now, is starting the countdown to EOL of 2.2 - if there's > > no incentive to move, twenty years of history proves most admins > > wont. > > Please keep an eye out, as Steffan has, for anywhere we are still > presenting the 2.2 branch as 'stable' or implying that it is > current. > > In practice, 2.2 is the stable release, from what users experience. This stems in part from the > 5 years between 2.2 and 2.4. 2.4 simply takes some time to stabilize. 2.2 did so, too (at the company I was working for at the time, we started adoption with 2.2.8 or so). > The post from the modperl project relayed by Jim this past week is > very welcome news, for getting 2.4 adopted by downstream packagers! And the other part of the problems is distributions not picking 2.4 up early because of mod_perl missing and/or because of 2.4 being released at an unfortunate point of time in the distribution's own release cycle. > But the thread is largely about how long an offer to RM should be > considered 'valid', vs. having another prospective RM pick up the > baton and run with a new release. We all get busy, and as active > volunteers we tend to over-commit and under-deliver. If STATUS > were devoid of 'Bill claims the baton' messages, will others step > up to RM more frequently? You are asking the question, 'should we > RM more frequently or avoid frequent releases?' Based on the > history and early adoption of both 2.0 and 2.2, I'd suggest that > frequent releases do contribute to adoption. I would also prefer more frequent releases, at least 4 per year. But I agree with other answers that the problem is lack of time of committers and not that one person has claimed the baton. Cheers, Stefan
T&R 2.4.5 on Thurs
I'll be T&Ring 2.4.5 tomorrow (thur July 10th).
Re: [discuss] The 'RM' Baton [was: VOTE]
Bill, all you had to say was "We really need to get 2.4.5 out". That's it. I agree. In fact I've been pushing for it quite a bit, and for a longer time, including those long periods when you've been completely off the grid.
Re: Whereforeartthou, 2.5.0?
On Jul 10, 2013, at 1:12 PM, "William A. Rowe Jr." wrote: > > What does the question of how long can a prospective RM hold that baton > before it becomes an excessive period of time (being the act of one > committer, whether that is you or I or another, which prevents others > from offering to do so in a more timely manner)... > That is total hogwash. If someone wants to take on the RM position and someone has currently "volunteered" for it, then raise the question on the list. Example: Bill: Jim, I see you have volunteered to release 2.4.5 but it's not out yet. Jim: Yes, I was hoping for a more "complete" 2.4.5. release. Bill: I see. But I think we should have it out now. Would you mind pushing one out or if I take over as RM for this release. Jim: Not at all. I'll do a T&R in 24hr (or whatever). Whatever it's worth, I've been trying to push a 2.4.5 out since late May, and if you look at the threads, you'll see that it resulted in a suite of work done in pushing code from trunk to 2.4, including security stuff. It's not like it wasn't released because someone "dropped the ball" but instead because I was waiting for the balls to settle down. And, imo, the 2.4.5 that we will release now is much better than the one we would have released ~1 month ago. What ever happened to "We release when it's ready"? And trusting the RM to make that determination. If your idea of "its ready" is different than mine, then there are ways of handling that (it's called "communication") other than adding layers of procedures. And I must say again, the "problem" isn't the RM or the RM process itself; it's the backporting process which is currently holding things back. (imo of course).
Re: [discuss] The 'RM' Baton [was: VOTE]
On Wed, 10 Jul 2013 09:22:06 -0400
Jim Jagielski wrote:
> Considering that I've been the only RM for 2.4.x, I can't help but
> assume that Bill is referring to me.
Please be aware that I'm speaking of all recent RMs (the few of us,
as Eric hinted, which includes myself) and future RMs, and not solely
yourself or myself.
> As mentioned by others, by indicating a desire to T&R, it energizes
> people to catch up on STATUS, place their votes and propose backports.
> So it is *expected* that at a time when things should be the most
> "stable" (right before a "release"), that there is a flurry of
> activity. So what if it means a delay of a few weeks or even a month.
> The result is a *better* release for our users, which I think is
> even more important.
Note that the release windows we are discussing have been far longer
than a month (or I would not have bothered to bring this up), fair?
For example, 2.0.65 was lingering almost a year. 2.4.5 is now into
its second month, you offered to RM back in May.
If you are suggesting simply a longer window for an RM (you, I or
any committer) holding the baton of a release for a specific longer
period, I'd be happy to entertain that discussion. And yet another
approach would be to issue a timed baton ('if the tree is ready, I
plan to T&R at the end of this week') passing on the baton to any
other prospective RM if they either have a different sense of the
tree's readiness, or if they have more availability the week after.
> Sure it would be nice to have releases more often, but that is due,
> IMO at least, to the difficulty in getting 3 +1 votes on anything
> but the most trivial of backports...
Agreed, and my other proposal addresses this. Where backports have
not been readily sped to adoption, perhaps those need to sit out for
a release? That would be little hardship if the subsequent release
were a couple months out. It's a great hardship when that release
isn't expected for another half a year.
> I'm not gonna mention the irony of this whole proposal coming from
> the person it is coming from...
Refer to my first response, above :)
Re: [discuss] The 'RM' Baton [was VOTE]
On Wed, 10 Jul 2013 21:18:06 +1000 Noel Butler wrote: > on holiday with a dog slow 3G vpn tonight, so I'll be brief (and wont > see any replies until I return on Sunday...) > > I have never agreed with any "release often" principle, a project that > releases often (more than a few times a year) to me says "immature > instability" compared to a project that releases once or twice a year > (barring critical bug resolutions) - IOW, release when necessary not > just because its a "cool thing to do". Take dovecot for instance, we > stayed on the stable 1.2 series for more than a year after it was EOL, > because its 2.0.x kept having fixes and releases every couple of weeks > for a while, admins dont like that, it gives them no warm feelings > towards stability. On the other hand, waiting 6 mos for a 'complete' release also implies that users are waiting for other fixes for 5 months. Reviewing CHANGES helps admins to determine if those fixes in a more frequent release cadence do address specific needs of each specific admin. > WRT slow take up of 2.4.x, I agree, the incentive (as was discussed 2 > years or so ago) was to EOL 2.0, and what needs doing now, is starting > the countdown to EOL of 2.2 - if there's no incentive to move, twenty > years of history proves most admins wont. Please keep an eye out, as Steffan has, for anywhere we are still presenting the 2.2 branch as 'stable' or implying that it is current. In practice, 2.2 is the stable release, from what users experience. The post from the modperl project relayed by Jim this past week is very welcome news, for getting 2.4 adopted by downstream packagers! At minimum, presenting 4+ packages to downstream for their evaluation and inclusion in distributions seems sensible, particularly in the early adoption phase. Without frequent fix releases, we are pushing those admins back to 2.2 for stability, whether it's warranted or not. But the thread is largely about how long an offer to RM should be considered 'valid', vs. having another prospective RM pick up the baton and run with a new release. We all get busy, and as active volunteers we tend to over-commit and under-deliver. If STATUS were devoid of 'Bill claims the baton' messages, will others step up to RM more frequently? You are asking the question, 'should we RM more frequently or avoid frequent releases?' Based on the history and early adoption of both 2.0 and 2.2, I'd suggest that frequent releases do contribute to adoption.
Re: [VOTE] The 'RM' Baton
As someone who's done most of the 2.4 releases, my goal has always been to ensure that whatever we release has as much trunk-goodness as possible. The more deviation there is between trunk and 2.4 the worse it is, imo, because it makes 2.4 less appealing. We are now currently using trunk pretty much as a clearing center for 2.4.x code and not so much as a place for "new" development (except for some things), and so it makes little sense to have trunk and 2.4 deviate much. At least, that's my PoV. On Jul 10, 2013, at 1:13 PM, Daniel Ruggeri wrote: > On 7/10/2013 7:13 AM, Eric Covener wrote: >> So my concern with the proposal -- are there really wiling/able RM's >> waiting in the wings in these periods? If they're there -- are they >> afraid of stepping on an RM's toes, or of drawing a line in the sane >> for the half-approved backports? >> >> (I have personally never RM'ed. To me it's intimidating and unknown >> and with a log of competing work it's hard to step up and tackle. >> Maybe we should make it make a condition of PMC membership at least >> once per decade?) > > Sure, I can do this if it's a time thing. The doc [1] seems straight > forward enough and I can make the time to roll a release (though I > wouldn't mind a practice swing or two first). The guts of the procedure > itself seems like it could easily be scripted. > > To get back on the topic, I don't see a lot of firm "no, you can't > release now because I'm not done working" messages. My perception is > that it boils down to a matter of time (or lack thereof) for the RM's. > There also isn't a guideline set forth that states exactly when to > release so that all too familiar > this-product-has-to-ship-on-July-8th-or-our-company-is-sunk pressure > that "motivates" devs isn't quite there. > > [1] http://httpd.apache.org/dev/release.html#how-to-do-a-release > > -- > Daniel Ruggeri >
Re: Whereforeartthou, 2.5.0?
On Jul 10, 2013, at 11:54 AM, William A. Rowe Jr. wrote: > > So reverting branches/2.4.x/ to trunk is my first suggestion to make > this easier, and it seems that the list would like to make things a > bit easier on committers and contributors. Reverting to CTR on 2.4.x > would be my second suggestion. Are there other suggestions that may > also simplify this process? > I propose that we track all backports in STATUS as we currently do. Each backport is time-tagged and we operate under a lazy consensus. Assuming no -1 votes within 72 hours, the backport can be applied to 2.4.x. If the backport gets 3 +1 votes sooner than that, then it can be applied asap...
Re: [VOTE] The 'RM' Baton
On 7/10/2013 7:13 AM, Eric Covener wrote: > So my concern with the proposal -- are there really wiling/able RM's > waiting in the wings in these periods? If they're there -- are they > afraid of stepping on an RM's toes, or of drawing a line in the sane > for the half-approved backports? > > (I have personally never RM'ed. To me it's intimidating and unknown > and with a log of competing work it's hard to step up and tackle. > Maybe we should make it make a condition of PMC membership at least > once per decade?) Sure, I can do this if it's a time thing. The doc [1] seems straight forward enough and I can make the time to roll a release (though I wouldn't mind a practice swing or two first). The guts of the procedure itself seems like it could easily be scripted. To get back on the topic, I don't see a lot of firm "no, you can't release now because I'm not done working" messages. My perception is that it boils down to a matter of time (or lack thereof) for the RM's. There also isn't a guideline set forth that states exactly when to release so that all too familiar this-product-has-to-ship-on-July-8th-or-our-company-is-sunk pressure that "motivates" devs isn't quite there. [1] http://httpd.apache.org/dev/release.html#how-to-do-a-release -- Daniel Ruggeri
Re: Whereforeartthou, 2.5.0?
On Wed, 10 Jul 2013 12:43:58 -0400 Jim Jagielski wrote: > > On Jul 10, 2013, at 2:19 AM, William A. Rowe Jr. > wrote: > > > So my proposal to be presented shortly as a vote would be to > > abandon the trunk into a sandbox to be mined for good changes, once > > 30 days after a vote is concluded without a release, and to revert > > the 2.4.x trunk to CTR. Comments and suggestions are welcome > > before I frame this as an actual policy vote... > > From what I can see, the above was sent at > >Received: from [173.201.193.104] (HELO > p3plsmtpa08-03.prod.phx3.secureserver.net) (173.201.193.104) by > apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jul 2013 06:19:53 + > > and the [VOTE] The 'RM' Baton was sent at: > >Received: from [68.178.252.110] (HELO > p3plsmtpa11-09.prod.phx3.secureserver.net) (68.178.252.110) by > apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jul 2013 06:41:51 + > > My math may be off, but that seems like a "wait" of ~22 minutes for > the "welcome" comments and suggestions. :) What does the question of how long can a prospective RM hold that baton before it becomes an excessive period of time (being the act of one committer, whether that is you or I or another, which prevents others from offering to do so in a more timely manner)... have to do with the question of what obstacles are in the way of commit activity today, particularly a /trunk/ which has no release plans, and a cumbersome RTC process (being policy impacting each committer who attempts to improve the 2.4.x active release branch)? They are two separate matters to consider, and the second has a number of possible solutions and improvements. The former is a straightforward question, are you or I impeding others from stepping up to RM in some timely manner to offer more releases to users, based on announcing to tag and roll when no tag and roll is forthcoming? I've offered nothing to vote on with respect to the second question, because we need more input from committers about what really impedes their ability to efficiently commit to the code base. Does that clarify the distinction for you?
Re: Whereforeartthou, 2.5.0?
On 10/07/2013 19:43, Jim Jagielski wrote: > > On Jul 10, 2013, at 2:19 AM, William A. Rowe Jr. wrote: > >> >> So my proposal to be presented shortly as a vote would be to abandon the >> trunk into a sandbox to be mined for good changes, once 30 days after a >> vote is concluded without a release, and to revert the 2.4.x trunk to >> CTR. Comments and suggestions are welcome before I frame this as an >> actual policy vote... >> > > From what I can see, the above was sent at > >Received: from [173.201.193.104] (HELO > p3plsmtpa08-03.prod.phx3.secureserver.net) (173.201.193.104) by apache.org > (qpsmtpd/0.29) with ESMTP; Wed, 10 Jul 2013 06:19:53 + > > and the [VOTE] The 'RM' Baton was sent at: > >Received: from [68.178.252.110] (HELO > p3plsmtpa11-09.prod.phx3.secureserver.net) (68.178.252.110) by apache.org > (qpsmtpd/0.29) with ESMTP; Wed, 10 Jul 2013 06:41:51 + > > > My math may be off, but that seems like a "wait" of ~22 minutes for > the "welcome" comments and suggestions. :) I saw a vote thread for changing the RM time, not a vote thread for changing how we deal with /trunk/ Issac
Re: Hey Steinar... Re: Revisiting the pre_htaccess hook
On 10.07.2013 13:14, Steinar H. Gunderson wrote: > On Tue, Jul 09, 2013 at 08:53:03AM -0400, Jeff Trawick wrote: >> Do you have time to test with this patch on top of 2.4.x and report back? >> >> http://people.apache.org/~sf/open_htaccess_hook.patch > > Hi, > > I've tried this, adjusted mpm-itk, and it seems to work. Why do I need to > return AP_DECLINED and not DECLINED from this hook, though? http://mail-archives.apache.org/mod_mbox/httpd-dev/201307.mbox/%3calpine.deb.2.00.1307031352000.14...@eru.sfritsch.de%3E Regards, Rainer
Re: Whereforeartthou, 2.5.0?
On Jul 10, 2013, at 2:19 AM, William A. Rowe Jr. wrote: > > So my proposal to be presented shortly as a vote would be to abandon the > trunk into a sandbox to be mined for good changes, once 30 days after a > vote is concluded without a release, and to revert the 2.4.x trunk to > CTR. Comments and suggestions are welcome before I frame this as an > actual policy vote... > From what I can see, the above was sent at Received: from [173.201.193.104] (HELO p3plsmtpa08-03.prod.phx3.secureserver.net) (173.201.193.104) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jul 2013 06:19:53 + and the [VOTE] The 'RM' Baton was sent at: Received: from [68.178.252.110] (HELO p3plsmtpa11-09.prod.phx3.secureserver.net) (68.178.252.110) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jul 2013 06:41:51 + My math may be off, but that seems like a "wait" of ~22 minutes for the "welcome" comments and suggestions. :) How about instead of us wasting time with these sort of naval gazing exercises, we test and vote? Isn't that the real problem?
Re: [PATCH] mod_unique_id: use ap_random_insecure_bytes() to get unique ID
On Tue, Jul 09, 2013 at 11:02:18PM +0200, Stefan Fritsch wrote: > On Tuesday 09 July 2013, Joe Orton wrote: > > On Tue, Jul 09, 2013 at 10:00:19AM +0200, Jan Kaluza wrote: > > > I agree 20 bytes could be too much. I have changed my patch to > > > have only 10 bytes long root. I will check the Daniel's ideas > > > mentioned in another mail in this thread and try to implement > > > it, but if we are going to do it my way, I think this patch > > > should be OK. > > > > +1 here, this looks good to me. > > +1 Thanks for the review Stefan & thanks for the patch Jan! => http://svn.apache.org/viewvc?view=revision&revision=1501827 This patch actually removes the noticeable delay when running the test suite, while A::T waits for httpd to start serving requests! I had no idea that was caused by mod_unique_id. Very cool :) Regards, Joe
Re: How is 2.2.25 called ?
On Wed, 10 Jul 2013 15:10:13 +0200 Steffen wrote: > > A bit puzzling with words. > > In 2.0.65 announce: > > ...legacy release 2.2 ... > > In 2.2.25 announce: > > ...This 2.2 maintenance release ... > > and > > .. a security and bug fix maintenance release .. > > I prefer the word legacy only, like was used with 2.0. I will use the word historical to refer to 2.0.65, meaning we are no longer maintaining that release branch. Agree that maintenance is ambiguous, and will apply legacy to the 2.2.25 release. The only branch which should be referred to as current / stable would be the 2.4.5 release. Thanks for the observation!
Re: apache process ps -aux
On Wed, Jul 10, 2013 at 8:25 AM, peter_bateman wrote: > I just haven't seen the apache processes listing with the -k start option on > any of my other servers, and wasn't sure why it was being displayed here... If you've been using a platform where the ps command doesn't list the command arguments you might not have even though it's still there.
Re: Whereforeartthou, 2.5.0?
On Wed, 10 Jul 2013 09:14:16 -0400 Jim Jagielski wrote: > According to STATUS: > > 2.4.5 : In development. Jim proposes a release ~July 4, 2013 > and offers to RM. > 2.4.4 : Tagged on February 18, 2013. Released Feb 25, 2013 > 2.4.3 : Tagged on August 17, 2012. Released Aug 18, 2012 > 2.4.2 : Tagged on April 5, 2012. Released Apr 17, 2012. > 2.4.1 : Tagged on February 13, 2012. Released Feb 21, 2012. > 2.4.0 : Tagged on January 16, 2012, not released. > > So I have no idea where you get "6+ mos between releases" of 2.4.x I stand corrected, only 2.4.4 has taken 6+ mos, as 2.4.5 will only take 6+ mos if this release stretches to August. > In any case, I *am* concerned that w seem to have quite a bit of > difficulty in getting 3 +1s a lot of the time and that the backport > process from trunk to 2.4 is becoming more and more painful. [...] What I am asking, is whether that trunk is a sandbox to hack in, or whether is is approaching a releasable state? I'm asking, whether trunk is a worthwhile exercise or a distraction and complication to fixing and enhancing the shared, released project code, branches/2.4.x? It seems we might be diagnosing the same problem. Everyone can agree there is further good code in /trunk/ right now, what I don't know is whether we are at a point in time where the apply-to-trunk/backport to 2.4 is the right model to encourage development and commits? > And we don't release 2.5.0... We only do even releases, remember? We don't? I count 10 alpha (or beta) tags during the 2.1.x cycle, and 16 during the 2.3.x cycle, including the vast majority of 2.3.x tagged and rolled by yourself. These do become releases; they are simply alpha/beta development and testing releases rather than GA releases. As things have stood since 2.4.0 arrived, we are asking developers to test /trunk/, but not asking so effectively, IMHO. It appears that trunk exists more as a sandbox for applying patches and obtaining feedback (which can happen in a sandbox, or the live tree, or a bug ticket, or the dev list, IMHO) to present a backport in STATUS (which is too complex at the present time, IMHO). So reverting branches/2.4.x/ to trunk is my first suggestion to make this easier, and it seems that the list would like to make things a bit easier on committers and contributors. Reverting to CTR on 2.4.x would be my second suggestion. Are there other suggestions that may also simplify this process? And throughout these comments, when I say 'developers' - I mean far more individuals than the handful of active, or even inactive httpd committers.
Re: apache process ps -aux
Thank you for the information, I really appreciate your reply. This was very helpful. -- View this message in context: http://apache-http-server.18135.x6.nabble.com/apache-process-ps-aux-tp5007013p5007016.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: apache process ps -aux
I just haven't seen the apache processes listing with the -k start option on any of my other servers, and wasn't sure why it was being displayed here... -- View this message in context: http://apache-http-server.18135.x6.nabble.com/apache-process-ps-aux-tp5007013p5007015.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: apache process ps -aux
Am 10.07.2013 16:52, schrieb peter_bateman: > I know this may be a newbie question, however when i run the following > command, all of my apache processes are listed with -k start. I have an > example listed below: > > ps -aux | grep apache | grep -v grep > apache 22397 3.5 0.3 360224 28476 ?S09:39 0:08 > /usr/sbin/httpd -k start > apache 22559 10.3 0.4 365472 34572 ?S09:39 0:23 > /usr/sbin/httpd -k start > > I was wondering if anyone has any insight as to why the process is listing > the -k start? because these are forks which means they are a 1:1 copy of the parent process including file handles and whatever I have never seen this on any of my other websevers, typcially > they just show "0:33 /usr/sbin/httpd". i have never seen this in a different from with http://httpd.apache.org/docs/current/mod/prefork.html > I am running Centos 5.3, Server version: Apache/2.2.3 > Server built: Jan 21 2009 22:00:55 > > Any help would be appreciated :) help in what? this is normal behavior and if it ain't broken simply don't fix it signature.asc Description: OpenPGP digital signature
apache process ps -aux
Hello All, I know this may be a newbie question, however when i run the following command, all of my apache processes are listed with -k start. I have an example listed below: ps -aux | grep apache | grep -v grep apache 22397 3.5 0.3 360224 28476 ?S09:39 0:08 /usr/sbin/httpd -k start apache 22559 10.3 0.4 365472 34572 ?S09:39 0:23 /usr/sbin/httpd -k start apache 22721 4.9 0.3 363376 32588 ?S09:39 0:11 /usr/sbin/httpd -k start apache 22723 5.2 0.3 363692 32112 ?R09:39 0:11 /usr/sbin/httpd -k start apache 23059 6.0 0.3 361404 29824 ?S09:35 0:27 /usr/sbin/httpd -k start apache 25198 4.4 0.3 361636 29752 ?S09:36 0:19 /usr/sbin/httpd -k start apache 25396 5.1 0.3 360356 28736 ?S09:36 0:22 /usr/sbin/httpd -k start apache 28921 8.1 0.3 359324 27904 ?S09:40 0:15 /usr/sbin/httpd -k start apache 29474 4.6 0.3 359200 27708 ?S09:40 0:08 /usr/sbin/httpd -k start apache 31748 5.0 0.3 362396 31272 ?S09:32 0:33 /usr/sbin/httpd -k start I was wondering if anyone has any insight as to why the process is listing the -k start? I have never seen this on any of my other websevers, typcially they just show "0:33 /usr/sbin/httpd". I am running Centos 5.3, Server version: Apache/2.2.3 Server built: Jan 21 2009 22:00:55 Any help would be appreciated :) Regards, peter_bateman -- View this message in context: http://apache-http-server.18135.x6.nabble.com/apache-process-ps-aux-tp5007013.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: Ready for 2.4.5 ??
On Jul 9, 2013, at 10:59 AM, Jim Jagielski wrote: > So, are we ready for 2.4.5?? > Let's look thru STATUS with an eye on things that really should be in 2.4.5 or, at least, people could review: * mod_auth_basic: Add a generic mechanism to fake basic authentication using the ap_expr parser. This allows the administrator to construct their own username and password for basic authentication based on their needs. Alternative fix for PR52616. trunk patch: http://svn.apache.org/r1457471 http://svn.apache.org/r1457504 http://svn.apache.org/r1462266 http://svn.apache.org/r1468581 2.4.x patch: http://people.apache.org/~minfrin/httpd-mod_auth_basic-fake4.patch +1: minfrin, jim No idea why this doesn't have 3 +1s * core, mod_ssl: Lift the restriction that prevents mod_ssl taking full advantage of the event MPM. Enable the ability for a module to reverse the sense of a poll event from a read to a write or vice versa. trunk patches: http://svn.apache.org/r1470679 http://svn.apache.org/r1477094 2.4.x patch: http://people.apache.org/~minfrin/httpd-event-ssl.patch +1: minfrin, jim -0.5: sf: I would prefer if this sat in trunk for a few months first to receive more testing. No idea why this doesn't have 3 +1s * mod_proxy_http: Make the proxy-interim-response environment variable effective by formally overriding origin server behaviour. trunk patch: http://svn.apache.org/r1483027 2.4.x patch: trunk works +1: minfrin, jim No idea why this doesn't have 3 +1s * core: Add pre_htaccess hook. trunk patch: http://svn.apache.org/r1389339 2.4.x patch: trunk patch works modulo CHANGES and mmn bump +1: minfrin, jim trawick: I like sf's idea on the list for a different API to solve the same problem. We shouldn't proceed with this patch. On hold waiting for open_access feedback. Alternate proposal: core: Add open_htaccess hook. trunk patch: http://svn.apache.org/r1389339 http://svn.apache.org/r1498880 2.4.x patch: http://people.apache.org/~sf/open_htaccess_hook.patch +1: sf, jorton, +0.5: jj: I would prefer if this sat in trunk for a few months first to receive more testing. +/-0: trawick: I would prefer if Steinar verifies that it is fine for him (however simple that verification would be). There's no need to proceed until he is ready to use it anyway. Assuming positive feedback, no idea why this doesn't have 3 +1s * mod_proxy: Connection header clearing issues trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1481891 https://svn.apache.org/viewvc?view=revision&revision=1482075 https://svn.apache.org/viewvc?view=revision&revision=1482170 https://svn.apache.org/viewvc?view=revision&revision=1482555 2.4.x patch: trunk patch works modulo CHANGES and ap_mmn +1: jim ?? Anyone else interested in proxy? * core: Stop the HTTP_IN filter from attempting to write error buckets to the output filters trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1482522 2.4.x patch: trunk patch works modulo CHANGES and ap_mmn +1: jim ?? Anyone else interested in proxy? * mod_proxy: support Unix domain sockets trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1451633 https://svn.apache.org/viewvc?view=revision&revision=1451905 https://svn.apache.org/viewvc?view=revision&revision=1451921 https://svn.apache.org/viewvc?view=revision&revision=1452259 https://svn.apache.org/viewvc?view=revision&revision=1453981 2.4.x patch: trunk patch works modulo CHANGES and ap_mmn +1: jim ?? Anyone else interested in proxy? * mod_proxy: save DNS lookups trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1462269 https://svn.apache.org/viewvc?view=revision&revision=1463455 2.4.x patch: trunk patch works +1: jim ?? Anyone else interested in proxy? * mod_socache_shmcb.c: Remove arbitrary restriction on shared memory size previously limited to 64MB. trunk patch: http://svn.apache.org/r1493921 http://svn.apache.org/r1493925 2.4.x patch: trunk patch works modulo CHANGES +1: minfrin, jim sf notes: I think a number of variables need to be changed from int to apr_size_t, including subcache_size, subcache_data_offset, subcache_data_size, total, cache_total. AIUI, especially cache_total starts to go wrong if the cache gets larger than 4GB (UINT_MAX). Maybe set the limit at MIN(APR_SIZE_MAX,UINT_MAX) until this is fixed? minfrin: Surely we should just fix these unsigned ints? Not sure what value there wou
Re: [VOTE] The 'RM' Baton
Considering that I've been the only RM for 2.4.x, I can't help but assume that Bill is referring to me. As mentioned by others, by indicating a desire to T&R, it energizes people to catch up on STATUS, place their votes and propose backports. So it is *expected* that at a time when things should be the most "stable" (right before a "release"), that there is a flurry of activity. So what if it means a delay of a few weeks or even a month. The result is a *better* release for our users, which I think is even more important. Sure it would be nice to have releases more often, but that is due, IMO at least, to the difficulty in getting 3 +1 votes on anything but the most trivial of backports... I'm not gonna mention the irony of this whole proposal coming from the person it is coming from... On Jul 10, 2013, at 8:13 AM, Eric Covener wrote: > I think the problem with no-one picking up the baton on a stalled > release is just a different angle on the same participation problem -- > what little resource there is gobbled up by non-RM activities (some of > it self imposed overhead as you outlined in the other thread). > > So my concern with the proposal -- are there really wiling/able RM's > waiting in the wings in these periods? If they're there -- are they > afraid of stepping on an RM's toes, or of drawing a line in the sane > for the half-approved backports? > > (I have personally never RM'ed. To me it's intimidating and unknown > and with a log of competing work it's hard to step up and tackle. > Maybe we should make it make a condition of PMC membership at least > once per decade?) >
Re: [VOTE] The 'RM' Baton
-1. On Jul 10, 2013, at 2:41 AM, William A. Rowe Jr. wrote: > Fellow httpd devs, > > A major problem which has occurred repeatedly, since the rapid pace of > release candidates in the 2.0 series, is that the RM baton has been > announced and dropped on the ground for weeks, if not many months. The > prime directive of open source at the ASF is to release early and to > release often, and the Apache HTTP Project is failing that directive. > > Refer to http://httpd.apache.org/dev/release.html on our project's > RM rights and responsibilities. Anyone, at any time, can propose > a release candidate. No individual should ever be able to hijack > the project with the promise to do something they can't/won't actually > accomplish. > > While we all get busy, and derailed by nice-to-have additions, the > activity 10:59 and 11:01 EDT Tuesday is a prime example of where the > desire to release the code conflicts with the desire to include even > more changes. The pattern must be broken if we are to release code > to the public often and early, which brings us to a concrete proposal... > > Proposed: An RM intent-to-tag announcement is valid for 10 days. If > no prospective release has been tagged in those 10 days, the 'baton' > has been dropped, the RM's intent is nullified, and any committer is > encouraged to pick up that baton and proceed to tag a candidate for > release. > > +/-1 > [ ] An intent-to-tag is valid for only 10 days > >
Re: Whereforeartthou, 2.5.0?
According to STATUS: 2.4.5 : In development. Jim proposes a release ~July 4, 2013 and offers to RM. 2.4.4 : Tagged on February 18, 2013. Released Feb 25, 2013 2.4.3 : Tagged on August 17, 2012. Released Aug 18, 2012 2.4.2 : Tagged on April 5, 2012. Released Apr 17, 2012. 2.4.1 : Tagged on February 13, 2012. Released Feb 21, 2012. 2.4.0 : Tagged on January 16, 2012, not released. So I have no idea where you get "6+ mos between releases" of 2.4.x In any case, I *am* concerned that w seem to have quite a bit of difficulty in getting 3 +1s a lot of the time and that the backport process from trunk to 2.4 is becoming more and more painful. After all, I *assume* people hack trunk so that their code and patches actually get released and used by people, and not just to bump their Ohloh ratings or whatever. And we don't release 2.5.0... We only do even releases, remember? On Jul 10, 2013, at 2:19 AM, William A. Rowe Jr. wrote: > Fellow PMC folk... > > I think everyone on this list can agree that the pace of releases has > slowed to a crawl; we are 6+ mos between releases of our active/stable > 2.4 series, which has little if any adoption, and are equally lethargic > about the actually stable-and-adopted 2.2 releases. This is a thread > which we have visited before many times, but I'd like to throw a new > spin on it and consider whether we have taken several group decisions, > and combined them into the worst results possible from the lot of them. > > My question to the group; is /repos/asf/httpd/httpd/trunk/ actually > a trunk? Or is it a sandbox? All ASF projects have one goal, which > is to release open source code to the public at no charge. What is > currently brewing as /repos/asf/httpd/httpd/trunk/ has a version # > designation, but no plan to release, and no release in several years. > > I would humbly submit that with no plan to release, /trunk/ is simply > a sandbox, and should be svn mv'ed to the appropriate svn branch for > those developers to retrieve, maintain and later advance their proposals > into an actual 2.5.0 release trunk at some future date. > > I'm watching a ton of mental gymnastics by the few who are willing to > fight with this bureaucracy to commit to a non-release trunk, plea for > backport votes, then perhaps get their code into 2.4 (which is not yet > even distributed by anyone other than the ASF and adopted by almost no > users at all). The entire model, IMHO, is broken by mixing too many > of our consensus concepts in the most inefficient manner. > > Here's my proposal... > > In 30 days, if there is no release of 2.5.0, we move /trunk/ over to the > sandbox, and restore 2.4.x as the /trunk/. No RTC, simply fix it, or if > it is a complex change, propose it in that sandbox, in it's own sandbox, > or to the dev list. > > If anyone wishes to start a clock on 2.5.0, they have 30 days to produce > a release. While our policy states they can do anything they like, the > simplest history would be to start from 2.4.x trunk, append the patches > from the sandbox 2.5 that they believe should survive, and tag and roll > a candidate. If rejected, no damage. If accepted, that sandbox then > becomes /trunk/ with /trunk/ relegated to /branches/2.4.x/ > > More importantly, during the transition, the *RM* is responsible for > keeping the sandbox in sync, not the entire body of httpd committers. > > I'm at a loss why a half dozen active committers need to do 2x the work > to maintain a single branch. And I have no question in my mind why it > is down to nothing but a half dozen committers... the process and flow > of the project is painful. We could launch into a whole debate over the > advantages of svn vs git, but the tool isn't the problem, it is the mess > of process which we have created for ourselves. > > So my proposal to be presented shortly as a vote would be to abandon the > trunk into a sandbox to be mined for good changes, once 30 days after a > vote is concluded without a release, and to revert the 2.4.x trunk to > CTR. Comments and suggestions are welcome before I frame this as an > actual policy vote... > > Cheers, > > Bill >
How is 2.2.25 called ?
A bit puzzling with words. In 2.0.65 announce: ...legacy release 2.2 ... In 2.2.25 announce: ...This 2.2 maintenance release ... and .. a security and bug fix maintenance release .. I prefer the word legacy only, like was used with 2.0. Steffen
RE: [VOTE] The 'RM' Baton
> -Original Message- > From: Graham Leggett [mailto:] > Sent: Mittwoch, 10. Juli 2013 10:12 > To: dev@httpd.apache.org > Subject: Re: [VOTE] The 'RM' Baton > > On 10 Jul 2013, at 8:41 AM, William A. Rowe Jr. > wrote: > > > Proposed: An RM intent-to-tag announcement is valid for 10 days. If > > no prospective release has been tagged in those 10 days, the 'baton' > > has been dropped, the RM's intent is nullified, and any committer is > > encouraged to pick up that baton and proceed to tag a candidate for > > release. > > > > +/-1 > > [ ] An intent-to-tag is valid for only 10 days > > -1: We don't need more process, another RM can step up at any time. Agreed. I don't think that further processes will resolve this issue and if they are of no use we should not introduce them. IMHO the issue is as pointed out by others too few active committers (which includes me as well, which I regret, but that's how live is going). Regards Rüdiger
Re: [PATCH] Fix "LDAPReferrals off"
> attached patch changes LDAPReferrals to tri-state logic. > > - "on" - default. Calls apr_ldap_set_option to set referrals on. > - "off" - Calls apr_ldap_set_option to turn referrals off. > - "unset" - Does not call apr_ldap_set_option at all. +1, will let it stew here first and commit soon. PR54358 followup will maybe provide something to further control how unset (== enabled on openldap) will chase referrals but w/o rebind callback.
Re: [VOTE] The 'RM' Baton
I think the problem with no-one picking up the baton on a stalled release is just a different angle on the same participation problem -- what little resource there is gobbled up by non-RM activities (some of it self imposed overhead as you outlined in the other thread). So my concern with the proposal -- are there really wiling/able RM's waiting in the wings in these periods? If they're there -- are they afraid of stepping on an RM's toes, or of drawing a line in the sane for the half-approved backports? (I have personally never RM'ed. To me it's intimidating and unknown and with a log of competing work it's hard to step up and tackle. Maybe we should make it make a condition of PMC membership at least once per decade?)
Re: [VOTE] The 'RM' Baton
On Wed, Jul 10, 2013 at 2:41 AM, William A. Rowe Jr. wrote: > Fellow httpd devs, > > A major problem which has occurred repeatedly, since the rapid pace of > release candidates in the 2.0 series, is that the RM baton has been > announced and dropped on the ground for weeks, if not many months. The > prime directive of open source at the ASF is to release early and to > release often, and the Apache HTTP Project is failing that directive. > > Refer to http://httpd.apache.org/dev/release.html on our project's > RM rights and responsibilities. Anyone, at any time, can propose > a release candidate. No individual should ever be able to hijack > the project with the promise to do something they can't/won't actually > accomplish. > > While we all get busy, and derailed by nice-to-have additions, the > activity 10:59 and 11:01 EDT Tuesday is a prime example of where the > desire to release the code conflicts with the desire to include even > more changes. The pattern must be broken if we are to release code > to the public often and early, which brings us to a concrete proposal... > > Proposed: An RM intent-to-tag announcement is valid for 10 days. If > no prospective release has been tagged in those 10 days, the 'baton' > has been dropped, the RM's intent is nullified, and any committer is > encouraged to pick up that baton and proceed to tag a candidate for > release. > > +/-1 > [ ] An intent-to-tag is valid for only 10 days > > > If someone needs a release and they don't see any activity they should step up. It would probably help to be gracious about it. If this creates a conflict (very unlikely if RM #2 is gracious) then RM #2 should solicit opinions from PMC members on the private list for how to proceed. This should be business as usual for any number of potential conflicts, and there's no need to define this as part of the release process. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [PATCH] Fix "LDAPReferrals off"
On 07/10/2013 07:22 AM, Jan Kaluža wrote:
On 07/09/2013 07:17 PM, Rainer Jung wrote:
On 09.07.2013 17:47, Joe Orton wrote:
On Thu, Jun 20, 2013 at 08:41:04AM -0400, Eric Covener wrote:
I'm only concerned with someone who was getting by with LDAPReferrals
OFF because the default gave their SDK an error. Now OFF would be
fatal too.
Just revisiting this... at least it seems clear that the docs do not
match the code here, in that "LDAPRerrals off" does something
surprising. So what are the choices?
a) Jan's suggestion: offer a tri-state option on/off/default where
"default" is equivalent to current "off".
Hi,
attached patch changes LDAPReferrals to tri-state logic.
- "on" - default. Calls apr_ldap_set_option to set referrals on.
- "off" - Calls apr_ldap_set_option to turn referrals off.
- "unset" - Does not call apr_ldap_set_option at all.
The "unset" option behaves like current "off" value (as implemented in
trunk) and can be used by admins who use LDAP implementation without
LDAP_OPT_REFERRALS support.
b) change the docs so that it is not implied that "LDAPReferrals off"
really disables referral processing.
c) ...something else?
But it's not so easy to do a separate "default" option because other
parts of the code need to know if referrals are being chased.
I don't follow that: if the intent here is retaining the current
behaviour of "LDAPReferrals off" for users who want that, then we can do
that easily.
Sorry I didn't yet really follow this discussion, but see PR 54358 for a
maybe related issue (platform on which ldap referrals are not
implemented in apr and default "On" leads to status 500).
Having tri-state logic (on/off/default) would fix this. If ldap
referrals are not supported, you would to set it to "default" in config
file and mod_ldap wouldn't try to do anything with ldap referrals.
I'm going to submit a patch here later today.
Regards,
Rainer
Regards,
Jan Kaluza
Regards,
Jan Kaluza
Index: modules/ldap/util_ldap.c
===
--- modules/ldap/util_ldap.c (revision 1501672)
+++ modules/ldap/util_ldap.c (working copy)
@@ -60,6 +60,7 @@
#endif
#define AP_LDAP_HOPLIMIT_UNSET -1
+#define AP_LDAP_CHASEREFERRALS_UNSET -1
#define AP_LDAP_CHASEREFERRALS_OFF 0
#define AP_LDAP_CHASEREFERRALS_ON 1
@@ -371,7 +372,7 @@
ldap_option = ldc->deref;
ldap_set_option(ldc->ldap, LDAP_OPT_DEREF, &ldap_option);
-if (ldc->ChaseReferrals == AP_LDAP_CHASEREFERRALS_ON) {
+if (ldc->ChaseReferrals != AP_LDAP_CHASEREFERRALS_UNSET) {
/* Set options for rebind and referrals. */
ap_log_error(APLOG_MARK, APLOG_TRACE4, 0, r->server, APLOGNO(01278)
"LDAP: Setting referrals to %s.",
@@ -391,7 +392,9 @@
uldap_connection_unbind(ldc);
return(result->rc);
}
+}
+if (ldc->ChaseReferrals == AP_LDAP_CHASEREFERRALS_ON) {
if ((ldc->ReferralHopLimit != AP_LDAP_HOPLIMIT_UNSET) && ldc->ChaseReferrals == AP_LDAP_CHASEREFERRALS_ON) {
/* Referral hop limit - only if referrals are enabled and a hop limit is explicitly requested */
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server, APLOGNO(01280)
@@ -2574,15 +2577,25 @@
static const char *util_ldap_set_chase_referrals(cmd_parms *cmd,
void *config,
- int mode)
+ const char *arg)
{
util_ldap_config_t *dc = config;
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, cmd->server, APLOGNO(01311)
- "LDAP: Setting referral chasing %s",
- (mode == AP_LDAP_CHASEREFERRALS_ON) ? "ON" : "OFF");
+ "LDAP: Setting referral chasing %s", arg);
-dc->ChaseReferrals = mode;
+if (0 == strcasecmp(arg, "on")) {
+dc->ChaseReferrals = AP_LDAP_CHASEREFERRALS_ON;
+}
+else if (0 == strcasecmp(arg, "off")) {
+dc->ChaseReferrals = AP_LDAP_CHASEREFERRALS_OFF;
+}
+else if (0 == strcasecmp(arg, "unset")) {
+dc->ChaseReferrals = AP_LDAP_CHASEREFERRALS_UNSET;
+}
+else {
+return "LDAPReferrals must be On, Off or Unset";
+}
return(NULL);
}
@@ -3106,9 +3119,9 @@
"Specify the LDAP socket connection timeout in seconds "
"(default: 10)"),
-AP_INIT_FLAG("LDAPReferrals", util_ldap_set_chase_referrals,
+AP_INIT_TAKE1("LDAPReferrals", util_ldap_set_chase_referrals,
NULL, OR_AUTHCFG,
- "Choose whether referrals are chased ['ON'|'OFF']. Default 'ON'"),
+ "Choose whether referrals are chased ['ON'|'OFF'|'UNSET']. Default 'ON'"),
AP_INIT_TAKE1("LDAPReferralHopLimit", util_ldap_set_referral_hop_limit,
NULL, OR_AUTHCFG,
Re: [discuss] The 'RM' Baton [was VOTE]
On Wed, 2013-07-10 at 03:24 -0500, William A. Rowe Jr. wrote: > > Because the project is incapable of releasing more than two minor > subversions, per year, at present. on holiday with a dog slow 3G vpn tonight, so I'll be brief (and wont see any replies until I return on Sunday...) I have never agreed with any "release often" principle, a project that releases often (more than a few times a year) to me says "immature instability" compared to a project that releases once or twice a year (barring critical bug resolutions) - IOW, release when necessary not just because its a "cool thing to do". Take dovecot for instance, we stayed on the stable 1.2 series for more than a year after it was EOL, because its 2.0.x kept having fixes and releases every couple of weeks for a while, admins dont like that, it gives them no warm feelings towards stability. WRT slow take up of 2.4.x, I agree, the incentive (as was discussed 2 years or so ago) was to EOL 2.0, and what needs doing now, is starting the countdown to EOL of 2.2 - if there's no incentive to move, twenty years of history proves most admins wont.
Re: Hey Steinar... Re: Revisiting the pre_htaccess hook
On Tue, Jul 09, 2013 at 08:53:03AM -0400, Jeff Trawick wrote:
> Do you have time to test with this patch on top of 2.4.x and report back?
>
> http://people.apache.org/~sf/open_htaccess_hook.patch
Hi,
I've tried this, adjusted mpm-itk, and it seems to work. Why do I need to
return AP_DECLINED and not DECLINED from this hook, though?
FWIW, here's my hook:
ap_hook_open_htaccess(itk_open_htaccess, NULL, NULL, APR_HOOK_REALLY_FIRST);
[...]
static apr_status_t itk_open_htaccess(request_rec *r,
const char *dir_name, const char
*access_name,
ap_configfile_t **conffile, const
char **full_name)
{
int status;
if (!ap_has_irreversibly_setuid || r->main != NULL) {
return AP_DECLINED;
}
*full_name = ap_make_full_path(r->pool, dir_name, access_name);
status = ap_pcfg_openfile(conffile, r->pool, *full_name);
if (APR_STATUS_IS_EACCES(status)) {
ap_log_rerror(APLOG_MARK, APLOG_WARNING, errno, r,
"Couldn't read %s, closing connection.",
*full_name);
ap_lingering_close(r->connection);
exit(0);
}
return status;
}
I don't like all that much having to duplicate the “official” hook
(in particular the ap_make_full_path() call), but I guess it's better than
what used to be there, and it's only two lines.
/* Steinar */
--
Homepage: http://www.sesse.net/
Re: svn commit: r1500108 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS modules/ssl/ssl_engine_io.c
On 10.07.2013 10:32, William A. Rowe Jr. wrote: > If you frame this as a fast vote for adoption, and correct the text > in https://dist.apache.org/repos/dist/release/httpd/Announcement2.2.txt > as well as the .html version, I'll post that in my morning (which is > still stuck on PDT from my travels). Done (thanks to Rüdiger for the third +1). Apparently svn.eu.apache.org doesn't have r1501712 yet, but I assume this will happen soon. Kaspar
RE: svn commit: r1500108 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS modules/ssl/ssl_engine_io.c
+1 on the patch for backporting.
Regards
Rüdiger
> -Original Message-
> From: Kaspar Brand [mailto: > Sent: Mittwoch, 10. Juli 2013 10:45
> To: dev@httpd.apache.org
> Cc: William A. Rowe Jr.
> Subject: Re: svn commit: r1500108 - in /httpd/httpd/branches/2.2.x:
> CHANGES STATUS modules/ssl/ssl_engine_io.c
>
> On 10.07.2013 10:32, William A. Rowe Jr. wrote:
> > If you frame this as a fast vote for adoption, and correct the text
> > in
> https://dist.apache.org/repos/dist/release/httpd/Announcement2.2.txt
> > as well as the .html version, I'll post that in my morning (which is
> > still stuck on PDT from my travels).
>
> Ok, so after some further offlist discussion, here's the proposal for
> 2.2.26, and the patch to be referenced in the 2.2.25 announcement:
>
> - backout r1500108
>
> - apply the attached patch for fixing PR55194
>
> I think we only need one more +1 here on @dev to apply this to 2.2.x.
>
> Kaspar
>
>
> For the sake of reference, here are some more bits about the gory
> details:
>
> > Let me explain the purpose of the
> > if block with these conditions:
> >
> > if (hostname_note &&
> > sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
> > apr_ipsubnet_create(&ip, hostname_note, NULL,
> > c->pool) != APR_SUCCESS) {
> >
> > The second and the third condition are only needed for SSLv3 and TLS
> > handshakes, as only in this case, OpenSSL will call
> > ssl/t1_lib.c:ssl_add_clienthello_tlsext()... which is the place where
> a
> > potentially improper SNI extension could be added.
> >
> > In 2.2.x, if sc->proxy->protocol is equal to SSL_PROTOCOL_SSLV2 and
> > we're omitting the "sc->proxy->protocol != SSL_PROTOCOL_SSLV2" check,
> > then SSL_set_tlsext_host_name() will be called, yes, but the name set
> in
> > OpenSSL's respectve SSL struct is simply ignored later on, as
> > ssl/s2_clnt.c - which implements SSLv2_client_method() and
> ssl2_connect
> > - never calls ssl_add_clienthello_tlsext(). Compare this to
> > SSLv3_client_method(), TLSv1_client_method() etc., which do call
> > ssl_add_clienthello_tlsext().
> >
> > Or, looking at it from the spec point of view: in a pure SSLv2
> > connection (sc->proxy->protocol == SSL_PROTOCOL_SSLV2), there isn't
> any
> > way for OpenSSL to put any extensions into the ClientHello - the
> > original SSL 2.0 specification simply doesn't provide any such field
> in
> > its protocol definition.
Re: svn commit: r1500108 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS modules/ssl/ssl_engine_io.c
On 10.07.2013 10:32, William A. Rowe Jr. wrote:
> If you frame this as a fast vote for adoption, and correct the text
> in https://dist.apache.org/repos/dist/release/httpd/Announcement2.2.txt
> as well as the .html version, I'll post that in my morning (which is
> still stuck on PDT from my travels).
Ok, so after some further offlist discussion, here's the proposal for
2.2.26, and the patch to be referenced in the 2.2.25 announcement:
- backout r1500108
- apply the attached patch for fixing PR55194
I think we only need one more +1 here on @dev to apply this to 2.2.x.
Kaspar
For the sake of reference, here are some more bits about the gory details:
> Let me explain the purpose of the
> if block with these conditions:
>
> if (hostname_note &&
> sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
> apr_ipsubnet_create(&ip, hostname_note, NULL,
> c->pool) != APR_SUCCESS) {
>
> The second and the third condition are only needed for SSLv3 and TLS
> handshakes, as only in this case, OpenSSL will call
> ssl/t1_lib.c:ssl_add_clienthello_tlsext()... which is the place where a
> potentially improper SNI extension could be added.
>
> In 2.2.x, if sc->proxy->protocol is equal to SSL_PROTOCOL_SSLV2 and
> we're omitting the "sc->proxy->protocol != SSL_PROTOCOL_SSLV2" check,
> then SSL_set_tlsext_host_name() will be called, yes, but the name set in
> OpenSSL's respectve SSL struct is simply ignored later on, as
> ssl/s2_clnt.c - which implements SSLv2_client_method() and ssl2_connect
> - never calls ssl_add_clienthello_tlsext(). Compare this to
> SSLv3_client_method(), TLSv1_client_method() etc., which do call
> ssl_add_clienthello_tlsext().
>
> Or, looking at it from the spec point of view: in a pure SSLv2
> connection (sc->proxy->protocol == SSL_PROTOCOL_SSLV2), there isn't any
> way for OpenSSL to put any extensions into the ClientHello - the
> original SSL 2.0 specification simply doesn't provide any such field in
> its protocol definition.
Index: STATUS
===
--- STATUS (revision 1500107)
+++ STATUS (revision 1500108)
@@ -93,12 +93,6 @@
RELEASE SHOWSTOPPERS:
- * mod_ssl: Fix "SNI for backend" when compiled against OpenSSL without
-support for SSLv2. Followup to r1497466. PR 55194.
-trunk patch: Does not apply to trunk
-2.4.x patch: Does not apply to 2.4
-2.2.x patch:
http://people.apache.org/~rjung/patches/sni-backend-fix-r1497466-2_2.patch
-+1: rjung, covener, trawick
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
Index: CHANGES
===
--- CHANGES (revision 1500107)
+++ CHANGES (revision 1500108)
@@ -1,8 +1,10 @@
-*- coding: utf-8 -*-
Changes with Apache 2.2.26
+ *) mod_ssl: Fix compilation error when OpenSSL does not contain
+ support for SSLv2. Problem was introduced in 2.2.25. PR 55194.
+ [Rainer Jung]
-
Changes with Apache 2.2.25
*) SECURITY: CVE-2013-1862 (cve.mitre.org)
Index: modules/ssl/ssl_engine_io.c
===
--- modules/ssl/ssl_engine_io.c (revision 1497466)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -1073,13 +1073,16 @@
#ifndef OPENSSL_NO_TLSEXT
/*
* Enable SNI for backend requests. Make sure we don't do it for
- * pure SSLv2 or SSLv3 connections, and also prevent IP addresses
+ * pure SSLv3 connections, and also prevent IP addresses
* from being included in the SNI extension. (OpenSSL would simply
* pass them on, but RFC 6066 is quite clear on this: "Literal
* IPv4 and IPv6 addresses are not permitted".)
+ * We can omit the check for SSL_PROTOCOL_SSLV2 as there is
+ * no way for OpenSSL to screw up things in this case (it's
+ * impossible to include extensions in a pure SSLv2 ClientHello,
+ * protocol-wise).
*/
if (hostname_note &&
-sc->proxy->protocol != SSL_PROTOCOL_SSLV2 &&
sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
apr_ipsubnet_create(&ip, hostname_note, NULL,
c->pool) != APR_SUCCESS) {
Re: svn commit: r1500108 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS modules/ssl/ssl_engine_io.c
If you frame this as a fast vote for adoption, and correct the text
in https://dist.apache.org/repos/dist/release/httpd/Announcement2.2.txt
as well as the .html version, I'll post that in my morning (which is
still stuck on PDT from my travels).
Otherwise, I'll post the existing text, which seems to solve the issue,
even if it is overkill.
+1 for such a change, please do a revert and apply the correct patch
in order for users to see a single patch which solves the 2.2.25 .tar
image, thanks.
Bill
On Wed, 10 Jul 2013 08:04:44 +0200
Kaspar Brand wrote:
> On 10.07.2013 07:53, William A. Rowe Jr. wrote:
> > Color me confused. Where SSLv2 alone is dropped from the stock
> > OpenSSL build, 2.2.25 would not compile. The
> > www.a.o/dist/httpd/Announcement file calls out this patch as a
> > workaround, which I will publish once I have sorted why the binary
> > win32 dbd drivers don't correspond to the prior release.
> >
> > Could you rephrase what you are getting at so we can correct the ANN
> > message? http://www.apache.org/dist/httpd/Announcement2.2.txt para
> > 5.
>
> Apologies for having been confusing... let code speak, that should
> hopefully make things clear. Here's what I would suggest for
> ssl_engine_io.c in 2.2.26:
>
> --- snip ---
>
> #ifndef OPENSSL_NO_TLSEXT
> /*
> * Enable SNI for backend requests. Make sure we don't do it
> for
> * pure SSLv3 connections, and also prevent IP addresses
> * from being included in the SNI extension. (OpenSSL would
> simply
> * pass them on, but RFC 6066 is quite clear on this: "Literal
> * IPv4 and IPv6 addresses are not permitted".)
> */
> if (hostname_note &&
> sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
> apr_ipsubnet_create(&ip, hostname_note, NULL,
> c->pool) != APR_SUCCESS) {
> if (SSL_set_tlsext_host_name(filter_ctx->pssl,
> hostname_note)) { ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, c,
> "SNI extension for SSL Proxy request
> set to '%s'", hostname_note);
> } else {
> ap_log_cerror(APLOG_MARK, APLOG_WARNING, 0, c,
> "Failed to set SNI extension for SSL
> Proxy " "request to '%s'", hostname_note);
> ssl_log_ssl_error(APLOG_MARK, APLOG_WARNING, server);
> }
> }
> #endif
>
> --- snip ---
>
> Kaspar
Re: [discuss] The 'RM' Baton [was VOTE]
On Wed, 10 Jul 2013 10:11:58 +0200 Graham Leggett wrote: > On 10 Jul 2013, at 8:41 AM, William A. Rowe Jr. > wrote: > > > > While we all get busy, and derailed by nice-to-have additions, the > > activity 10:59 and 11:01 EDT Tuesday is a prime example of where the > > desire to release the code conflicts with the desire to include even > > more changes. The pattern must be broken if we are to release code > > to the public often and early, > > Can you explain why the pattern needs to be broken? Because the project is incapable of releasing more than two minor subversions, per year, at present. I certainly count you amoung the half dozen rare active committers. I'd argue that a half-dozen is insufficent. > An imminent release has the effect of incentivising people to get > their changes in, it is normal. If someone else wants a release, > nothing stops them from politely asking the group whether they can > perform the release themselves. Absolutely. And 45-150 days does not qualify as imminent. There is no need to ask; the point is that anyone is free to T&R at any point, without asking permission at all. But we've had this newer concept of 'reservations' (frequently added to STATUS) with very little to show for the practice. Courtesies extended to such reservations appear to prevent anyone else from stepping up to actually produce any releases, which is unhealthy for the project.
Re: [VOTE] The 'RM' Baton
On 10 Jul 2013, at 8:41 AM, William A. Rowe Jr. wrote: > A major problem which has occurred repeatedly, since the rapid pace of > release candidates in the 2.0 series, is that the RM baton has been > announced and dropped on the ground for weeks, if not many months. The > prime directive of open source at the ASF is to release early and to > release often, and the Apache HTTP Project is failing that directive. > > Refer to http://httpd.apache.org/dev/release.html on our project's > RM rights and responsibilities. Anyone, at any time, can propose > a release candidate. No individual should ever be able to hijack > the project with the promise to do something they can't/won't actually > accomplish. > > While we all get busy, and derailed by nice-to-have additions, the > activity 10:59 and 11:01 EDT Tuesday is a prime example of where the > desire to release the code conflicts with the desire to include even > more changes. The pattern must be broken if we are to release code > to the public often and early, Can you explain why the pattern needs to be broken? An imminent release has the effect of incentivising people to get their changes in, it is normal. If someone else wants a release, nothing stops them from politely asking the group whether they can perform the release themselves. > which brings us to a concrete proposal... > > Proposed: An RM intent-to-tag announcement is valid for 10 days. If > no prospective release has been tagged in those 10 days, the 'baton' > has been dropped, the RM's intent is nullified, and any committer is > encouraged to pick up that baton and proceed to tag a candidate for > release. > > +/-1 > [ ] An intent-to-tag is valid for only 10 days -1: We don't need more process, another RM can step up at any time. Regards, Graham --
