httpd 2.4 is coming, RFC on module packaging draft

[Joe Orton]

httpd 2.4.1 packages are ready for dist-f18 and will be built early next 
week.  Rebuilds will be required for all packages containing httpd 
modules.  There are API changes in 2.4, so module packages may need 
patches if upstream has not done that work already:

http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html

There are some significant changes in the packaging, also:

1) Config changes: I've moved to a minimal default httpd.conf which is 
very close to what we're shipping upstream.

a) I'm proposing to split out packaged config snippets from mutable 
config, with the former in /etc/httpd/conf.modules.d/, containing only 
LoadModule lines, and ordered to avoid load-ordering issues.

b) /etc/httpd/conf.d/*.conf should contain no LoadModules for packaged 
modules, and only any reasonable default configurations.

2) Loadable MPMs!  MPMs are now loadable modules, so we only need to 
ship one httpd binary again.  Changing MPM is a config tweak.

3) Content.  Putting unmutable content in /var was bad practice, so I've 
moved the /var/www/manual and /var/www/icons to into /usr/share/httpd.  
We now ship /var/www/* as empty directories.

4) Filesystem locations have moved in-line with upstream, e.g. apxs is 
now in /usr/bin.  /etc/rpm/httpd.macros has macros for everything module 
packages should need.

Since much of the above requires packaging changes for module packages, 
I've prepared a draft packaging guideline to document best practice:

https://fedoraproject.org/wiki/PackagingDrafts/ApacheHTTPModules

If anything there looks stupid, needs fixing, is missing, or there's any 
other feedback, please shout!

Regards, Joe

[Peter Robinson]

On Fri, Mar 23, 2012 at 5:19 PM, Joe Orton <jorton(a)redhat.com&gt; wrote:
>  httpd 2.4.1 packages are ready for dist-f18 and will be built early
> next
>  week.  Rebuilds will be required for all packages containing httpd
>  modules.  There are API changes in 2.4, so module packages may need
>  patches if upstream has not done that work already:
>
>  http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
>
>  There are some significant changes in the packaging, also:
>
>  1) Config changes: I've moved to a minimal default httpd.conf which is
>  very close to what we're shipping upstream.
>
>  a) I'm proposing to split out packaged config snippets from mutable
>  config, with the former in /etc/httpd/conf.modules.d/, containing only
>  LoadModule lines, and ordered to avoid load-ordering issues.
>
>  b) /etc/httpd/conf.d/*.conf should contain no LoadModules for packaged
>  modules, and only any reasonable default configurations.
>
>  2) Loadable MPMs!  MPMs are now loadable modules, so we only need to
>  ship one httpd binary again.  Changing MPM is a config tweak.
>
>  3) Content.  Putting unmutable content in /var was bad practice, so I've
>  moved the /var/www/manual and /var/www/icons to into /usr/share/httpd.
>  We now ship /var/www/* as empty directories.
>
>  4) Filesystem locations have moved in-line with upstream, e.g. apxs is
>  now in /usr/bin.  /etc/rpm/httpd.macros has macros for everything module
>  packages should need.
>
>  Since much of the above requires packaging changes for module packages,
>  I've prepared a draft packaging guideline to document best practice:
>
>  https://fedoraproject.org/wiki/PackagingDrafts/ApacheHTTPModules
>
>  If anything there looks stupid, needs fixing, is missing, or there's any
>  other feedback, please shout! 
There should likely be a feature request for it as well with links for
various changes.

Peter

[Michał Piotrowski]

Hi,

2012/3/23 Joe Orton <jorton(a)redhat.com&gt;:
>  httpd 2.4.1 packages are ready for dist-f18 and will be built early
> next
>  week.  Rebuilds will be required for all packages containing httpd
>  modules.  There are API changes in 2.4, so module packages may need
>  patches if upstream has not done that work already:
>
>  http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
>
>  There are some significant changes in the packaging, also:
>
>  1) Config changes: I've moved to a minimal default httpd.conf which is
>  very close to what we're shipping upstream.
>
>  a) I'm proposing to split out packaged config snippets from mutable
>  config, with the former in /etc/httpd/conf.modules.d/, containing only
>  LoadModule lines, and ordered to avoid load-ordering issues.
>
>  b) /etc/httpd/conf.d/*.conf should contain no LoadModules for packaged
>  modules, and only any reasonable default configurations. 
+1 for configuration changes

>  2) Loadable MPMs!  MPMs are now loadable modules, so we only need to
>  ship one httpd binary again.  Changing MPM is a config tweak.
>
>  3) Content.  Putting unmutable content in /var was bad practice, so I've
>  moved the /var/www/manual and /var/www/icons to into /usr/share/httpd.
>  We now ship /var/www/* as empty directories.
>
>  4) Filesystem locations have moved in-line with upstream, e.g. apxs is
>  now in /usr/bin.  /etc/rpm/httpd.macros has macros for everything module
>  packages should need.
>
>  Since much of the above requires packaging changes for module packages,
>  I've prepared a draft packaging guideline to document best practice:
>
>  https://fedoraproject.org/wiki/PackagingDrafts/ApacheHTTPModules
>
>  If anything there looks stupid, needs fixing, is missing, or there's any
>  other feedback, please shout!
>
>  Regards, Joe
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
Do you know if the new version of httpd has major changes in modules
API? I'm trying to cobble together spec file for mod_spdy
https://github.com/eventhorizonpl/mod_spdy/blob/master/mod_spdy.spec
and I hope to finish it for F18 :)

-- 
Best regards,
Michal

http://eventhorizon.pl/

[Joe Orton]

On Fri, Mar 23, 2012 at 06:39:25PM +0100, Michał Piotrowski wrote:
>  Do you know if the new version of httpd has major changes in modules
>  API? I'm trying to cobble together spec file for mod_spdy
>  https://github.com/eventhorizonpl/mod_spdy/blob/master/mod_spdy.spec
>  and I hope to finish it for F18 :) 
Hi Michal, yes, there are changes in the 2.4 module API, though mostly 
relatively small - details are here:

http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html

Regards, Joe

[Nicolas Mailhot]

The following is going to kill pretty much every packaged webapp unless they
are changed now:

https://httpd.apache.org/docs/2.4/upgrading.html#access

-- 
Nicolas Mailhot

[Chris Adams]

Once upon a time, Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt; said:
>  The following is going to kill pretty much every packaged webapp
> unless they
>  are changed now:
>  
>  https://httpd.apache.org/docs/2.4/upgrading.html#access 
Did you read this part:

  "The old access control idioms should be replaced by the new
   authentication mechanisms, although for compatibility with old
   configurations, the new module mod_access_compat is provided."

It would be easy to include mod_access_compat in the Fedora default
config for a release or two while the compat config is deprecated (and
noted in the release notes as such).

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Michał Piotrowski]

2012/3/26 Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt;:
>  The following is going to kill pretty much every packaged webapp
> unless they
>  are changed now:
>
>  https://httpd.apache.org/docs/2.4/upgrading.html#access 
IMHO mod_access_compat should be enabled by default
https://httpd.apache.org/docs/2.4/mod/mod_access_compat.html

>  --
>  Nicolas Mailhot
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 


-- 
Best regards,
Michal

http://eventhorizon.pl/

[Dennis Jacobfeuerborn]

On 03/26/2012 10:10 PM, Michał Piotrowski wrote:
>  2012/3/26 Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt;:
> > The following is going to kill pretty much every packaged webapp unless they
> > are changed now:
> >
> > https://httpd.apache.org/docs/2.4/upgrading.html#access
>  
>  IMHO mod_access_compat should be enabled by default
>  https://httpd.apache.org/docs/2.4/mod/mod_access_compat.html 
I disagree. Since this is a major update that gets introduced together with
a new Fedora version this opportunity should be used to make switches like
these. Otherwise you'll be forced to either keep this compat stuff around
for a long time (given the long apache release cycles) or remove it with a
minor update when people least expect it.

Regards,
  Dennis

[Ken Dreyer]

On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn
<dennisml(a)conversis.de&gt; wrote:
>  I disagree. Since this is a major update that gets introduced
> together with
>  a new Fedora version this opportunity should be used to make switches like
>  these. 
In principle I agree with what you're saying, but this is still going
to require changing lots of packages, and it should be properly scoped
on the httpd 2.4 feature page.

Here's what I plan to use in Cacti.

<Directory /usr/share/cacti/>
  <IfVersion > 2.2>
    Require host localhost
  </IfVersion>
  <IfVersion <= 2.2>
    Order deny,allow
    Deny from all
    Allow from localhost
  </IfVersion>
</Directory>

[Dennis Jacobfeuerborn]

On 03/27/2012 03:54 AM, Ken Dreyer wrote:
>  On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn
>  <dennisml(a)conversis.de&gt; wrote:
> > I disagree. Since this is a major update that gets introduced together with
> > a new Fedora version this opportunity should be used to make switches like
> > these.
>  
>  In principle I agree with what you're saying, but this is still going
>  to require changing lots of packages, and it should be properly scoped
>  on the httpd 2.4 feature page. 
All the more reason for making this change now with a major version change
and early in the F18 release cycle rather than being forced to go through
this in a later supposedly minor update.

>  Here's what I plan to use in Cacti.
>  
>  <Directory /usr/share/cacti/>
>    <IfVersion > 2.2>
>      Require host localhost
>    </IfVersion>
>    <IfVersion <= 2.2>
>      Order deny,allow
>      Deny from all
>      Allow from localhost
>    </IfVersion>
>  </Directory> 
I don't think making this a runtime configuration is a good idea. Most
people only run either 2.2 or 2.4 but not both so having this in their
config is really unnecessary and makes things more complicated then it
needs to be.
Why not make this distinction in the spec file and include one of two
configuration files in the rpm depending on the release version? That way
F18+ users get a clean config for 2.4 and older version get a clean config
for 2.2.

Regards,
  Dennis

[Jóhann B. Guðmundsson]

On 03/27/2012 12:53 AM, Dennis Jacobfeuerborn wrote:
>  I disagree. Since this is a major update that gets introduced
> together with
>  a new Fedora version this opportunity should be used to make switches like
>  these. Otherwise you'll be forced to either keep this compat stuff around
>  for a long time (given the long apache release cycles) or remove it with a
>  minor update when people least expect it. 
I agree on you disagreement.

We are very good at inventing and implementing the latest and the 
greatest but terribly at removing the legacy cruff at the same time, 
which results in half baked implementation leaving various things in 
"compat" mode and half removed from the distribution/install.

JBG

[Nicolas Mailhot]

Le Lun 26 mars 2012 22:09, Chris Adams a écrit :
>  Once upon a time, Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt;
> said:
> > The following is going to kill pretty much every packaged webapp unless they
> > are changed now:
> >
> > https://httpd.apache.org/docs/2.4/upgrading.html#access
>
>  Did you read this part:
>
>    "The old access control idioms should be replaced by the new
>     authentication mechanisms, although for compatibility with old
>     configurations, the new module mod_access_compat is provided."
>
>  It would be easy to include mod_access_compat in the Fedora default
>  config for a release or two while the compat config is deprecated (and
>  noted in the release notes as such). 
Sure. But right now there does not seem to be a plan one way or the other, so
now that http 2.4 is built rawhide webapps are broken.

-- 
Nicolas Mailhot

[Joe Orton]

On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote:
>  Once upon a time, Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt;
> said:
>  > The following is going to kill pretty much every packaged webapp unless they
>  > are changed now:
>  > 
>  > https://httpd.apache.org/docs/2.4/upgrading.html#access
>  
>  Did you read this part:
>  
>    "The old access control idioms should be replaced by the new
>     authentication mechanisms, although for compatibility with old
>     configurations, the new module mod_access_compat is provided."
>  
>  It would be easy to include mod_access_compat in the Fedora default
>  config for a release or two while the compat config is deprecated (and
>  noted in the release notes as such). 
Yup - the default config in the f18 httpd does load mod_access_compat, 
and I don't see a problem with shipping like that.

It would be good to convert webapps over for f18, having said that.

Regards, Joe

[Pavel Alexeev]

27.03.2012 20:18, Joe Orton написал:
>  On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote:
> > Once upon a time, Nicolas Mailhot<nicolas.mailhot(a)laposte.net>  said:
> >> The following is going to kill pretty much every packaged webapp unless they
> >> are changed now:
> >>
> >> https://httpd.apache.org/docs/2.4/upgrading.html#access
> > Did you read this part:
> >
> >    "The old access control idioms should be replaced by the new
> >     authentication mechanisms, although for compatibility with old
> >     configurations, the new module mod_access_compat is provided."
> >
> > It would be easy to include mod_access_compat in the Fedora default
> > config for a release or two while the compat config is deprecated (and
> > noted in the release notes as such).
>  Yup - the default config in the f18 httpd does load mod_access_compat,
>  and I don't see a problem with shipping like that.
>
>  It would be good to convert webapps over for f18, having said that. 
Shouldn't
be it the Future?
>  Regards, Joe

[Jason L Tibbitts III]

> >>>> "JO" == Joe Orton <jorton(a)redhat.com&gt;
> writes: 
JO> Yup - the default config in the f18 httpd does load
JO> mod_access_compat, and I don't see a problem with shipping like
JO> that.

This is good news, because even if we convert the httpd.conf.d files in
all of the packages, they're all marked %config(noreplace) so a package
update won't magically fix 

JO> It would be good to convert webapps over for f18, having said that.

It would be great to have a short document about this (even though I
know the conversion is largely trivial).  Would it be reasonable to have
something should be added to the packaging guidelines at some point so
that new packages don't rely on the compatibility module?

 - J<

[Jon Ciesla]

On Tue, Mar 27, 2012 at 11:56 AM, Jason L Tibbitts III
<tibbs(a)math.uh.edu&gt; wrote:
> >>>>> "JO" == Joe Orton
> <jorton(a)redhat.com&gt; writes:
>
>  JO> Yup - the default config in the f18 httpd does load
>  JO> mod_access_compat, and I don't see a problem with shipping like
>  JO> that.
>
>  This is good news, because even if we convert the httpd.conf.d files in
>  all of the packages, they're all marked %config(noreplace) so a package
>  update won't magically fix
>
>  JO> It would be good to convert webapps over for f18, having said that.
>
>  It would be great to have a short document about this (even though I
>  know the conversion is largely trivial).  Would it be reasonable to have
>  something should be added to the packaging guidelines at some point so
>  that new packages don't rely on the compatibility module? 
Probably, and the release notes as well, if it's not already there.

-J

>   - J<
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 


-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie

[Kevin Kofler]

Jóhann B. Guðmundsson wrote:
>  We are very good at inventing and implementing the latest and the
>  greatest but terribly at removing the legacy cruff at the same time,
>  which results in half baked implementation leaving various things in
>  "compat" mode and half removed from the distribution/install. 
I think "removing the legacy cruft" just for the goal of removing it is not 
helpful at all and is actually the main cause of "half baked", "half 
removed" stuff in Fedora.

I assume that that mod_access_compat module only requires a few bytes, so I 
don't see why it should not be loaded by default forever (or at least as 
long as upstream supports it, which hopefully will be for the whole 2.4 
cycle).

Of course, web app packages in Fedora itself SHOULD be updated to the new 
directives, but that's not a reason to gratuitously break the old ones.

        Kevin Kofler

[Michał Piotrowski]

2012/3/27 Joe Orton <jorton(a)redhat.com&gt;:
>  On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote:
> > Once upon a time, Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt; said:
> > > The following is going to kill pretty much every packaged webapp unless they
> > > are changed now:
> > >
> > > https://httpd.apache.org/docs/2.4/upgrading.html#access
> >
> > Did you read this part:
> >
> >   "The old access control idioms should be replaced by the new
> >    authentication mechanisms, although for compatibility with old
> >    configurations, the new module mod_access_compat is provided."
> >
> > It would be easy to include mod_access_compat in the Fedora default
> > config for a release or two while the compat config is deprecated (and
> > noted in the release notes as such).
>
>  Yup - the default config in the f18 httpd does load mod_access_compat,
>  and I don't see a problem with shipping like that. 
Great.

Backward compatibility is a good thing.

>  It would be good to convert webapps over for f18, having said that.
>
>  Regards, Joe
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 


-- 
Best regards,
Michal

http://eventhorizon.pl/

[Nicolas Mailhot]

Le Mar 27 mars 2012 18:18, Joe Orton a écrit :

>  Yup - the default config in the f18 httpd does load
> mod_access_compat,
>  and I don't see a problem with shipping like that. 
However, this module does not seem to be installed on http yum updates

-- 
Nicolas Mailhot

[Remi Collet]

Le 27/03/2012 18:18, Joe Orton a écrit :

>  Yup - the default config in the f18 httpd does load
> mod_access_compat, 
>  and I don't see a problem with shipping like that.
>  
>  It would be good to convert webapps over for f18, having said that. 
It seems that mod_access_compat doesn't really work as expected.

> From my first test, it allow to reduce the default right not to
> increase it. 
I Will take phpMyAdmin for example, stock config.

By default, access is denied.

So even with

<Directory /usr/share/phpMyAdmin/>
   order deny,allow
   deny from all
   allow from 127.0.0.1
   allow from ::1
</Directory>

I got an "access denied" (from authz_core)

[authz_core:error] [pid 10848] [client ::1:59237] AH01630: client denied
by server configuration: /usr/share/phpMyAdmin/, referer: http://localhost/

After adding a trivial default access with

	<Directory />
		Require all granted
	</Directory>

phpMyAdmin works, and mod_access_compat allow to protect some folders

Example, with

<Directory /usr/share/phpMyAdmin/setup/lib>
    Order Deny,Allow
    Deny from All
    Allow from None
</Directory>


I got the expected "access denied" (from access_compat)

[access_compat:error] [pid 11130] [client ::1:59330] AH01797: client
denied by server configuration:
/usr/share/phpMyAdmin/setup/lib/common.inc.php


So I mainly see 2 options

1/ allow default access
	seems really uggly...

2/ fix all web app in fedora 18
	just a big job...


Perhaps there is another solution... any idea ?


Regards,
Remi

[Jóhann B. Guðmundsson]

On 03/27/2012 05:15 PM, Kevin Kofler wrote:
>  I think "removing the legacy cruft" just for the goal of
> removing it is not
>  helpful at all and is actually the main cause of "half baked", "half
>  removed" stuff in Fedora. 
Interesting how did you come to that conclusion?

>  I assume that that mod_access_compat module only requires a few bytes, so I
>  don't see why it should not be loaded by default forever (or at least as
>  long as upstream supports it, which hopefully will be for the whole 2.4
>  cycle). 
Few bytes for mod_access_compat here, few bytes for something else 
there....

>  Of course, web app packages in Fedora itself SHOULD be updated to the new
>  directives, but that's not a reason to gratuitously break the old ones. 
It's my experience that things dont seem to get fixed unless they are 
broken and what "compat" does is just delaying the inevitable...

Those web app maintainers that actually bother to monitor upstream have 
already made the necessary changes to their relevant component and did 
so as soon as 2.4 got release and probably are just waiting until we 
start shipping 2.4.

It's those that dont and they will drag their feets in doing so until 
that compatibility is removed...

JBG

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/27/2012 03:19 PM, "Jóhann B. Guðmundsson" wrote:
>  On 03/27/2012 05:15 PM, Kevin Kofler wrote:
> > I think "removing the legacy cruft" just for the goal of removing it is not
> helpful at all and is actually the main cause of "half baked", "half
> removed" stuff in Fedora.
>  
>  Interesting how did you come to that conclusion?
>  
> > 
> > I assume that that mod_access_compat module only requires a few bytes, so I don't
> see why it should not be loaded by default forever (or at least as long as upstream
> supports it, which hopefully will be for the whole 2.4 cycle).
>  
>  Few bytes for mod_access_compat here, few bytes for something else there....
>  
> > 
> > Of course, web app packages in Fedora itself SHOULD be updated to the new directives,
> but that's not a reason to gratuitously break the old ones.
>  
>  It's my experience that things dont seem to get fixed unless they are broken and what
> "compat" does is just delaying the inevitable...
>  
>  Those web app maintainers that actually bother to monitor upstream have already made the
> necessary changes to their relevant component and did so as soon as 2.4 got release and
> probably are just waiting until we start shipping 2.4.
>  
>  It's those that dont and they will drag their feets in doing so until that
> compatibility is removed...
>  
>  JBG 
Joe, I am not sure how this effects SELinux labeling, if it does at all.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9zCnIACgkQrlYvE4MpobO+TwCg5vmaymeSPFTnGYMuhcPGsaOG
> G0IAnRWrJ1zyyn6lvffkb1kzbb2UdCGu
> =VNnY
> -----END PGP SIGNATURE-----

[Jóhann B. Guðmundsson]

On 03/28/2012 12:56 PM, Daniel J Walsh wrote:
>  Joe, I am not sure how this effects SELinux labeling, if it does at
> all. 
Afaikt this does not affect selinux in anyway since these are 
configuration syntax changes for the most part.

If we take this example which is common as an default in various web 
applications...

What used to be...

<Directory "/var/www/example">
     Options Indexes FollowSymLinks
     Order allow,deny
     Allow from all
</Directory>

Will become...||

<Directory "/var/www/example">
     Options Indexes FollowSymLinks
     Require all granted
</Directory>

etc...

So what we as an project will need to do, is to update our documentation 
and maintainers will have to update default apache configuration  to 
reflect the new configuration syntax for the application/package they 
maintain.

Administrators will have to updated their apache configuration(s) 
accordingly and or install the mod_access_compat module.

The new api changes can be found here [1].

JBG

http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html

[Kevin Kofler]

Jóhann B. Guðmundsson wrote:

>  On 03/27/2012 05:15 PM, Kevin Kofler wrote:
> > I think "removing the legacy cruft" just for the goal of removing it is
> > not helpful at all and is actually the main cause of "half baked",
> "half
> > removed" stuff in Fedora.
>  
>  Interesting how did you come to that conclusion? 
See e.g. how removing ConsoleKit just for the sake of removing it (when it 
had been coexisting with systemd just fine in F16) caused several issues, 
the worst being:
https://bugzilla.redhat.com/show_bug.cgi?id=794690
which has now been worked around by disabling the relevant PulseAudio 
functionality. (Not even the systemd author has managed to port his own 
daemon to the systemd API everyone is expected to use now!)

This is not the first time that functionality regressed due to an 
incompatible change which could have been avoided.

        Kevin Kofler

[Remi Collet]

Le 28/03/2012 20:32, "Jóhann B. Guðmundsson" a écrit :
>  So what we as an project will need to do, is to update our
> documentation
>  and maintainers will have to update default apache configuration  to
>  reflect the new configuration syntax for the application/package they
>  maintain. 
Yes

>  Administrators will have to updated their apache configuration(s)
>  accordingly  
Yes

>  or install the mod_access_compat module. 
No, as mod_access_compat module can't grant any access when default
access is denied by authz_core (see my previous message).

For upstream, this is a nightmare :

Couldn't rely on mod_access_compat (when some distro are used to not
enable optionnal module)

Couldn't rely on mod_version (the <IfVersion..> work-around for the same
reason

I'm still searching for a good solution I can submit to upstream for
packages I maintained (ok, this is mainly an issue on debian-like distro).

Remi.

[Remi Collet]

Le 29/03/2012 07:40, Remi Collet a écrit :
>  I'm still searching for a good solution I can submit to upstream
> for
>  packages I maintained (ok, this is mainly an issue on debian-like distro). 
What do you think of

	<IfModule mod_authz_core.c>
		Require all denied
	</IfModule>
	<IfModule !mod_authz_core.c>
		deny from all
	</IfModule>

mod_authz_core is only present in httpd >= 2.4
IfModule is part of "Core", so should be present in all case.


Remi.

[Miloslav Trmač]

2012/3/27 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
>  On 03/27/2012 05:15 PM, Kevin Kofler wrote:
> > I assume that that mod_access_compat module only requires a few bytes, so> I
> > don't see why it should not be loaded by default forever (or at least as
> > long as upstream supports it, which hopefully will be for the whole 2.4
> > cycle).
>
>
>  Few bytes for mod_access_compat here, few bytes for something else there.... 
I suppose this needs repeating from time to time.  One byte of disk
space costs .00000000008065817067$ on the best-selling hard drive
around here.  Even if there were 100 million Fedora users (which is a
huge overestimate AFAIK), that is $0.008 for all Fedora users
together.  Compare to a tens of minutes, or hours, per affected user
that needs to update their system.  Disk space at this scale just
cannot be a reason to drop legacy interfaces.  (There might be other
arguments, such as maintenance manpower.)

> > Of course, web app packages in Fedora itself SHOULD be updated to
> the new
> > directives, but that's not a reason to gratuitously break the old ones.
>
>  It's my experience that things dont seem to get fixed unless they are broken 
Is that another way of saying that "only broken things need fixing"? :)
    Mirek

[Dennis Jacobfeuerborn]

On 04/02/2012 09:08 PM, Miloslav Trmač wrote:
>  2012/3/27 "Jóhann B. Guðmundsson"
> <johannbg(a)gmail.com&gt;:
> > On 03/27/2012 05:15 PM, Kevin Kofler wrote:
> >> I assume that that mod_access_compat module only requires a few bytes, so> I
> >> don't see why it should not be loaded by default forever (or at least as
> >> long as upstream supports it, which hopefully will be for the whole 2.4
> >> cycle).
> >
> >
> > Few bytes for mod_access_compat here, few bytes for something else there....
>  
>  I suppose this needs repeating from time to time.  One byte of disk
>  space costs .00000000008065817067$ on the best-selling hard drive
>  around here.  Even if there were 100 million Fedora users (which is a
>  huge overestimate AFAIK), that is $0.008 for all Fedora users
>  together.  Compare to a tens of minutes, or hours, per affected user
>  that needs to update their system.  Disk space at this scale just
>  cannot be a reason to drop legacy interfaces.  (There might be other
>  arguments, such as maintenance manpower.)
>  
> >> Of course, web app packages in Fedora itself SHOULD be updated to the new
> >> directives, but that's not a reason to gratuitously break the old ones.
> >
> > It's my experience that things dont seem to get fixed unless they are broken
>  
>  Is that another way of saying that "only broken things need fixing"? :)
>      Mirek 
Upstream apparently wants to establish a new interface for this so I think
it would be a good idea to promote this too if possible.

Is there a way to only pull in mod_access_compat only on updates but not on
new installs? That would be the best option I think as it would not break
existing installations that get updated but allows new setups to either not
have to deal with the legacy stuff at all or at least see that there are
some changes going on there.

Regards,
  Dennis

[Remi Collet]

Le 03/04/2012 13:50, Dennis Jacobfeuerborn a écrit :
>  Is there a way to only pull in mod_access_compat only on updates but
> not on
>  new installs? That would be the best option I think as it would not break
>  existing installations that get updated but allows new setups to either not
>  have to deal with the legacy stuff at all or at least see that there are
>  some changes going on there. 
Once again : mod_access_compat is not the solution.

mod_access_compat doesn't work as expected,
see my other posts in this thread.



Remi

[Kevin Kofler]

Remi Collet wrote:
>  Once again : mod_access_compat is not the solution.
>  
>  mod_access_compat doesn't work as expected,
>  see my other posts in this thread. 
We need to get this fixed upstream, a compatibility module which is not 
compatible is quite broken.

        Kevin Kofler

[Ken Dreyer]

On Sat, Mar 31, 2012 at 1:50 AM, Remi Collet <Fedora(a)famillecollet.com&gt; wrote:
>  Le 29/03/2012 07:40, Remi Collet a écrit :
> > I'm still searching for a good solution I can submit to upstream for
> > packages I maintained (ok, this is mainly an issue on debian-like distro).
>
>  What do you think of
>
>         <IfModule mod_authz_core.c>
>                 Require all denied
>         </IfModule>
>         <IfModule !mod_authz_core.c>
>                 deny from all
>         </IfModule>
>
>  mod_authz_core is only present in httpd >= 2.4
>  IfModule is part of "Core", so should be present in all case. 
I like this, and I'm thinking of using it in my own package. Have you
seen any problems so far?

- Ken

[Remi Collet]

Le 05/04/2012 01:42, Ken Dreyer a écrit :
> > What do you think of
> >
> >        <IfModule mod_authz_core.c>
> >                Require all denied
> >        </IfModule>
> >        <IfModule !mod_authz_core.c>
> >                deny from all
> >        </IfModule>
> >
> > mod_authz_core is only present in httpd >= 2.4
> > IfModule is part of "Core", so should be present in all case.
>  
>  I like this, and I'm thinking of using it in my own package. Have you
>  seen any problems so far? 
As upstream, I will use this solution which have been testing on
- httpd 2.0.52 (RHEL-4)
- httpd 2.2.3 (RHEL-5)
- httpd 2.2.22 (fedora)
- httpd 2.4.1 (fedora)

And also on others distro (Debian-like)

Remi