Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Sat, Mar 31, 2012 at 1:50 AM, Remi Collet fed...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On 04/02/2012 09:08 PM, Miloslav Trmač wrote: 2012/3/27 Jóhann B. Guðmundsson johan...@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 .008065817067$ 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
2012/3/27 Jóhann B. Guðmundsson johan...@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 .008065817067$ 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
-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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
Le Lun 26 mars 2012 22:09, Chris Adams a écrit : Once upon a time, Nicolas Mailhot nicolas.mail...@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). 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote: Once upon a time, Nicolas Mailhot nicolas.mail...@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. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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.mail...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Tue, Mar 27, 2012 at 11:56 AM, Jason L Tibbitts III ti...@math.uh.edu wrote: JO == Joe Orton jor...@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 -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
2012/3/27 Joe Orton jor...@redhat.com: On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote: Once upon a time, Nicolas Mailhot nicolas.mail...@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. 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 -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
Once upon a time, Nicolas Mailhot nicolas.mail...@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). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On 03/26/2012 10:10 PM, Michał Piotrowski wrote: 2012/3/26 Nicolas Mailhot nicolas.mail...@laposte.net: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn denni...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On 03/27/2012 03:54 AM, Ken Dreyer wrote: On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn denni...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
httpd 2.4 is coming, RFC on module packaging draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Fri, Mar 23, 2012 at 5:19 PM, Joe Orton jor...@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: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
Hi, 2012/3/23 Joe Orton jor...@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: 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@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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
