You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2013/08/21 14:27:56 UTC
DefaultRuntimeDir
The 2.4 STATUS file has:
* opinion on more complete DefaultRuntimeDir use in 2.4.x?
o If a module has a config directive for the run-time file that
treats the configured path as relative to server root, preserve
that behavior but change the location when not configured to
respect DefaultRuntimeDir. With these changes, users with no
per-runtime-file configuration directives can control
everything with DefaultRuntimeDir.
BUT: Existing users of DefaultRuntimeDir might get a short-term scare
when some unconfigured run-time file starts respecting their
DefaultRuntimeDir directive after an upgrade.
+1: trawick, jim, rjung
rjung: applicable trunk revisions WITHOUT the compatibility tweaks
described above:
scoreboard r1369477
core/pid file r1369808
core/mutex r1370288
mod_socache_XXX r1370225, r1407385
mod_ldap r1371684
mod_cache r1407381
mod_slotmem_plain r1370763
igalic: We have three votes, what's the status here?
Independently, backport any doc tweaks to 2.4 API migration page.
To be honest, I also wonder what the status of this is...
I'd like to have the 1st 3 in 2.4, but am unsure what is
required, if anything, to make it acceptable. Is it just
the "preserve" line?
Re: DefaultRuntimeDir
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Aug 24, 2013 at 5:50 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Wed, Aug 21, 2013 at 9:05 AM, Jeff Trawick <tr...@gmail.com> wrote:
>
>> On Wed, Aug 21, 2013 at 8:27 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>>> The 2.4 STATUS file has:
>>>
>>> * opinion on more complete DefaultRuntimeDir use in 2.4.x?
>>> o If a module has a config directive for the run-time file that
>>> treats the configured path as relative to server root, preserve
>>> that behavior but change the location when not configured to
>>> respect DefaultRuntimeDir. With these changes, users with no
>>> per-runtime-file configuration directives can control
>>> everything with DefaultRuntimeDir.
>>> BUT: Existing users of DefaultRuntimeDir might get a short-term
>>> scare
>>> when some unconfigured run-time file starts respecting their
>>> DefaultRuntimeDir directive after an upgrade.
>>> +1: trawick, jim, rjung
>>> rjung: applicable trunk revisions WITHOUT the compatibility tweaks
>>> described above:
>>> scoreboard r1369477
>>> core/pid file r1369808
>>> core/mutex r1370288
>>> mod_socache_XXX r1370225, r1407385
>>> mod_ldap r1371684
>>> mod_cache r1407381
>>> mod_slotmem_plain r1370763
>>> igalic: We have three votes, what's the status here?
>>> Independently, backport any doc tweaks to 2.4 API migration page.
>>>
>>> To be honest, I also wonder what the status of this is...
>>> I'd like to have the 1st 3 in 2.4, but am unsure what is
>>> required, if anything, to make it acceptable. Is it just
>>> the "preserve" line?
>>>
>>
>>
>> I think that we've already backported everything we can without risking a
>> change in the meaning of someone's configuration. DefaultRuntimeDir
>> can/should be used for new additions to 2.4 when appropriate, but these
>> remaining ones are dangerous without some 2.4-specific mitigation.
>>
>> I'll try to look through this in the next day to see if there is some
>> mitigation we can do to allow the feature without breaking any current 2.4
>> behavior. I fear that a "safe" implementation would require some explicit
>> opt-in for these remaining features, and a config that did the opt-in could
>> then move all the runtime files just by changing DefaultRuntimeDir.
>>
>
> Wow, days go by quick if you're learning cmake and shaking the rust off
> your Windows-ability...
>
> Here's the best I could come up with:
>
> In 2.4.x branch, DefaultRuntimeDir could take an optional additional
> parameter, "full", which means that it applies even to the half-dozen items
> that it didn't apply to in 2.4.0-2.4.6. Those half-dozen modules in 2.4.x
> that didn't consult ap_runtime_dir_relative() before would check the global
> "full" setting to know whether to start using it like in trunk. If "full"
> isn't specified, those modules would use the same logic they use in
> 2.4.0-2.4.6.
>
I guess it could instead be a ./configure/cmake option, which distributors
might want to enable if they haven't yet distributed a 2.4[-based] server.
That would be cleaner implementation-wise but wouldn't be an obvious
choice for current 2.4 users.
> Configure "DefaultRuntimeDir non-default-value full" but don't separately
> configure those half-dozen items, and suddenly the scoreboard file and pid
> and (usually) some less interesting objects move to the "right" place.
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: DefaultRuntimeDir
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Aug 21, 2013 at 9:05 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Wed, Aug 21, 2013 at 8:27 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> The 2.4 STATUS file has:
>>
>> * opinion on more complete DefaultRuntimeDir use in 2.4.x?
>> o If a module has a config directive for the run-time file that
>> treats the configured path as relative to server root, preserve
>> that behavior but change the location when not configured to
>> respect DefaultRuntimeDir. With these changes, users with no
>> per-runtime-file configuration directives can control
>> everything with DefaultRuntimeDir.
>> BUT: Existing users of DefaultRuntimeDir might get a short-term
>> scare
>> when some unconfigured run-time file starts respecting their
>> DefaultRuntimeDir directive after an upgrade.
>> +1: trawick, jim, rjung
>> rjung: applicable trunk revisions WITHOUT the compatibility tweaks
>> described above:
>> scoreboard r1369477
>> core/pid file r1369808
>> core/mutex r1370288
>> mod_socache_XXX r1370225, r1407385
>> mod_ldap r1371684
>> mod_cache r1407381
>> mod_slotmem_plain r1370763
>> igalic: We have three votes, what's the status here?
>> Independently, backport any doc tweaks to 2.4 API migration page.
>>
>> To be honest, I also wonder what the status of this is...
>> I'd like to have the 1st 3 in 2.4, but am unsure what is
>> required, if anything, to make it acceptable. Is it just
>> the "preserve" line?
>>
>
>
> I think that we've already backported everything we can without risking a
> change in the meaning of someone's configuration. DefaultRuntimeDir
> can/should be used for new additions to 2.4 when appropriate, but these
> remaining ones are dangerous without some 2.4-specific mitigation.
>
> I'll try to look through this in the next day to see if there is some
> mitigation we can do to allow the feature without breaking any current 2.4
> behavior. I fear that a "safe" implementation would require some explicit
> opt-in for these remaining features, and a config that did the opt-in could
> then move all the runtime files just by changing DefaultRuntimeDir.
>
Wow, days go by quick if you're learning cmake and shaking the rust off
your Windows-ability...
Here's the best I could come up with:
In 2.4.x branch, DefaultRuntimeDir could take an optional additional
parameter, "full", which means that it applies even to the half-dozen items
that it didn't apply to in 2.4.0-2.4.6. Those half-dozen modules in 2.4.x
that didn't consult ap_runtime_dir_relative() before would check the global
"full" setting to know whether to start using it like in trunk. If "full"
isn't specified, those modules would use the same logic they use in
2.4.0-2.4.6.
Configure "DefaultRuntimeDir non-default-value full" but don't separately
configure those half-dozen items, and suddenly the scoreboard file and pid
and (usually) some less interesting objects move to the "right" place.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: DefaultRuntimeDir
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Aug 21, 2013 at 8:27 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> The 2.4 STATUS file has:
>
> * opinion on more complete DefaultRuntimeDir use in 2.4.x?
> o If a module has a config directive for the run-time file that
> treats the configured path as relative to server root, preserve
> that behavior but change the location when not configured to
> respect DefaultRuntimeDir. With these changes, users with no
> per-runtime-file configuration directives can control
> everything with DefaultRuntimeDir.
> BUT: Existing users of DefaultRuntimeDir might get a short-term
> scare
> when some unconfigured run-time file starts respecting their
> DefaultRuntimeDir directive after an upgrade.
> +1: trawick, jim, rjung
> rjung: applicable trunk revisions WITHOUT the compatibility tweaks
> described above:
> scoreboard r1369477
> core/pid file r1369808
> core/mutex r1370288
> mod_socache_XXX r1370225, r1407385
> mod_ldap r1371684
> mod_cache r1407381
> mod_slotmem_plain r1370763
> igalic: We have three votes, what's the status here?
> Independently, backport any doc tweaks to 2.4 API migration page.
>
> To be honest, I also wonder what the status of this is...
> I'd like to have the 1st 3 in 2.4, but am unsure what is
> required, if anything, to make it acceptable. Is it just
> the "preserve" line?
>
I think that we've already backported everything we can without risking a
change in the meaning of someone's configuration. DefaultRuntimeDir
can/should be used for new additions to 2.4 when appropriate, but these
remaining ones are dangerous without some 2.4-specific mitigation.
I'll try to look through this in the next day to see if there is some
mitigation we can do to allow the feature without breaking any current 2.4
behavior. I fear that a "safe" implementation would require some explicit
opt-in for these remaining features, and a config that did the opt-in could
then move all the runtime files just by changing DefaultRuntimeDir.
--
Born in Roswell... married an alien...
http://emptyhammock.com/