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
On Fri, Mar 23, 2012 at 5:19 PM, Joe Orton jorton@redhat.com 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:
- 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.
- Loadable MPMs! MPMs are now loadable modules, so we only need to
ship one httpd binary again. Changing MPM is a config tweak.
- 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.
- 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
Hi,
2012/3/23 Joe Orton jorton@redhat.com:
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:
- 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
- Loadable MPMs! MPMs are now loadable modules, so we only need to
ship one httpd binary again. Changing MPM is a config tweak.
- 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.
- 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@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 :)
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
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
Once upon a time, Nicolas Mailhot nicolas.mailhot@laposte.net said:
The following is going to kill pretty much every packaged webapp unless they are changed now:
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).
Le Lun 26 mars 2012 22:09, Chris Adams a écrit :
Once upon a time, Nicolas Mailhot nicolas.mailhot@laposte.net said:
The following is going to kill pretty much every packaged webapp unless they are changed now:
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.
On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote:
Once upon a time, Nicolas Mailhot nicolas.mailhot@laposte.net said:
The following is going to kill pretty much every packaged webapp unless they are changed now:
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
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 Mailhotnicolas.mailhot@laposte.net said:
The following is going to kill pretty much every packaged webapp unless they are changed now:
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
"JO" == Joe Orton jorton@redhat.com 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<
On Tue, Mar 27, 2012 at 11:56 AM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"JO" == Joe Orton jorton@redhat.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
2012/3/27 Joe Orton jorton@redhat.com:
On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote:
Once upon a time, Nicolas Mailhot nicolas.mailhot@laposte.net said:
The following is going to kill pretty much every packaged webapp unless they are changed now:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
2012/3/26 Nicolas Mailhot nicolas.mailhot@laposte.net:
The following is going to kill pretty much every packaged webapp unless they are changed now:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 03/26/2012 10:10 PM, Michał Piotrowski wrote:
2012/3/26 Nicolas Mailhot nicolas.mailhot@laposte.net:
The following is going to kill pretty much every packaged webapp unless they are changed now:
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
On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn dennisml@conversis.de 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>
On 03/27/2012 03:54 AM, Ken Dreyer wrote:
On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn dennisml@conversis.de 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
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
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
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
-----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.
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
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.
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.
On Sat, Mar 31, 2012 at 1:50 AM, Remi Collet Fedora@famillecollet.com 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
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
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
2012/3/27 "Jóhann B. Guðmundsson" johannbg@gmail.com:
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
On 04/02/2012 09:08 PM, Miloslav Trmač wrote:
2012/3/27 "Jóhann B. Guðmundsson" johannbg@gmail.com:
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
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
devel@lists.stg.fedoraproject.org