In short: - keep current way of determining what modules to build and install Doesn't really hurt that much and managing split ebuilds for modules generates some maintenance cost for ebuild devs. - introduce /etc/apache2/mods-available (or similar name) containing info about all installed modules in format: "${module_name}.load" file containing "LoadModule ${module_name} ${module_absolute_path}" optional "${module_name}.conf" file global configuration of this module, for instance Alias /icons "<path>" and Directory access control and Options for this <path>. This gives fine grained control over global configuration with nice association of module and corresponding configuration. - introduce /etc/apache2/mods-enabled (or similar) containing relative symlinks to all .load and .conf files of modules that are meant to be enabled. Debian perl script a2enmod (APACHE License) can be used to mangle those symlinks (there is bash completion available for it so it's extremely handy). - introduce /etc/apache2/sites-{available,enabled} Similar scheme as above, this time one file for one vhost, for instance "default" containing complete example <VirtualHost *:80> entry with DocumentRoot, ACL and Options for Directory /, same for ScriptAlias, entry ErrorLog and maybe /doc/ alias if not set globally in alias module config. Another example could be "default-ssl" with <VirtualHost _default_:443> and similar settings like above + some SSL options (some maybe commented out) that are to be set in VirtualHost context. sites-enabled would contain relative symlinks to those that are supposed to be enabled, preferably managed by a2ensite Debian script (also with bash completion available). To make this all work, toplevel httpd.conf would contain: Include /etc/apache2/mods-enabled/*.load Include /etc/apache2/mods-enabled/*.conf Include /etc/apache2/sites-enabled/ Personally I've found Debian layout to be superior and out of the box for real life application, while Gentoo default the most irritating as: - most people usually add own vhosts definitions in vhosts.d as default_vhost.include thing is impractical as one usually keeps separate web contents for HTTP and HTTPS so it means rewriting whole setup from scratch - and if it in most cases useless - why bother providing it at all? - on apache reinstall Gentoo supplied sites are being installed again (if were removed, see case ^) and then they shadow those user supplied - unnecessary maintenance task to restore it back. - maintaining modules in /etc/conf.d is troublesome as dispatch-conf uses diff tool - and this way one can merge differences at line level - but enabled modules are already listed in one line! Besides one needs to carefully adjust nicknames for modules (like WEBDAV_SVN, PHP5) - another unnecessary maintenance cost. There is also concept of webapp-specific .conf files in /etc/apache/conf.d but let's leave it for now. Summary - I've set up a few WWW servers (and I'm NOT typical administrator so note my knowledge is rather limited) - every time I tried it on Gentoo it dealt me significant amount of pain of writing virtualhost definitons from scratch and caused breakages on apache updates. Debian layout on the other side proved well thought (they don't need to care of compilation like we do, so they can afford spending more time on tweaking user experience), easy to maintain and relatively breakage-free on updates - so superior in any case in my opinion. Please consider shameless copying Debian apache2 layout to Gentoo. Looking at typical Debian installation is enough to get a grip how it works, don't hesitate to ask me anyway.
(In reply to comment #0) > Personally I've found Debian layout to be superior and out of the box for real > life application, while Gentoo default the most irritating as: > - most people usually add own vhosts definitions in vhosts.d as > default_vhost.include thing is impractical as one usually keeps separate web > contents for HTTP and HTTPS i don't know which "most people" you are refering to, but in my case almost all machines (that's about 40 machines) have the same content on ssl. > so it means rewriting whole setup from scratch - > and if it in most cases useless - why bother providing it at all? if you need a custom setup, you have to write it yourself, the ebuild just provides a good default behaviour > - on apache reinstall Gentoo supplied sites are being installed again (if were > removed, see case ^) and then they shadow those user supplied - unnecessary > maintenance task to restore it back. you're not supposed to remove these files, instead remove DEFAULT_VHOST/DEFAULT_SSL_VHOST from APACHE2_OPTS > - maintaining modules in /etc/conf.d is troublesome as dispatch-conf uses diff > tool - and this way one can merge differences at line level - but enabled > modules are already listed in one line! what are you talking about? > Besides one needs to carefully adjust > nicknames for modules (like WEBDAV_SVN, PHP5) - another unnecessary maintenance > cost. again, what are you talking about? > There is also concept of webapp-specific .conf files in /etc/apache/conf.d but > let's leave it for now. yuo can happily provide global app specific data in your own /etc/apache2/modules.d/myapp.conf > Summary - I've set up a few WWW servers (and I'm NOT typical administrator so > note my knowledge is rather limited) - every time I tried it on Gentoo it dealt > me significant amount of pain of writing virtualhost definitons from scratch > and caused breakages on apache updates. you're doing it wrong then ... > Debian layout on the other side proved > well thought (they don't need to care of compilation like we do, so they can > afford spending more time on tweaking user experience), easy to maintain and > relatively breakage-free on updates - so superior in any case in my opinion. well, in my opinion the whole symlink hell in debian just freaks me out :) > Please consider shameless copying Debian apache2 layout to Gentoo. nope, won't do.
(In reply to comment #1) > (In reply to comment #0) > > Personally I've found Debian layout to be superior and out of the box for real > > life application, while Gentoo default the most irritating as: > > - most people usually add own vhosts definitions in vhosts.d as > > default_vhost.include thing is impractical as one usually keeps separate web > > contents for HTTP and HTTPS > > i don't know which "most people" you are refering to, but in my case almost all > machines (that's about 40 machines) have the same content on ssl. What machines are those and what web applications are supposed to be run in such way (same contents for HTTP and HTTPS)? Well, if you're talking about web servers that provide only directory listing (mirroring service) for files, then you're clearly missing the point of using SSL... > > so it means rewriting whole setup from scratch - > > and if it in most cases useless - why bother providing it at all? > > if you need a custom setup, you have to write it yourself, the ebuild just > provides a good default behaviour Yes, it provides good (but a bit impractical imho) behavior. In Debian I don't need custom setup to host distribution provided web application the way I want. > > - on apache reinstall Gentoo supplied sites are being installed again (if were > > removed, see case ^) and then they shadow those user supplied - unnecessary > > maintenance task to restore it back. > > you're not supposed to remove these files, instead remove > DEFAULT_VHOST/DEFAULT_SSL_VHOST from APACHE2_OPTS right > > - maintaining modules in /etc/conf.d is troublesome as dispatch-conf uses diff > > tool - and this way one can merge differences at line level - but enabled > > modules are already listed in one line! > > what are you talking about? /etc/conf.d/apache2 contains APECHE2_OPTS (a'ka "what modules are enabled"), and /etc/conf.d/apache2 is subject of dispatch-conf (as it's in COLLISION_PROTECT area), right? And dispatch-conf is diff/merge tool and those tools work on line level. And APACHE2_OPTS is variable defined in ONE line. Which means dispatch-conf won't merge your custom changes with incoming changes - it will only allow you to keep your setting or dump your setting - won't merge it. That being said specifying what modules are to be enabled in this way is broken concept imho. Besides Gentoo apache layout does not allow to disable unwanted modules in persistent manner with no user intervention on reemerge (and please don't come up with APACHE2_MODULES thing). > > Besides one needs to carefully adjust > > nicknames for modules (like WEBDAV_SVN, PHP5) - another unnecessary maintenance > > cost. > > again, what are you talking about? (again, if you don't know what I'm talking about why bother replying? :P) APACHE2_OPTS contains symbolic names (defined by Gentoo apache devs) corresponding to either apache modules or ... something arbitrary like vhosts or anything else. So to enable some module one needs to scan all apache config files looking for this module (LoadModule code), see, whether it's guarded by some IfDefine directive, remember that name and enable it in APACHE2_OPTS. That's the very definition of unnecessary maintenance cost. What when you decide to rename some variable? Current layout is very breakage prone (see APACHE2_OPTS point earlier) and wrong syntax prone (easy to misspell variable name). > > There is also concept of webapp-specific .conf files in /etc/apache/conf.d but > > let's leave it for now. > > yuo can happily provide global app specific data in your own > /etc/apache2/modules.d/myapp.conf "webapp-specific" (webapp persistent) configuration, not module configuration. For instance to set up some webapp specific php options, but that's not directly related to apache I think so not a place for such discussion. > > Summary - I've set up a few WWW servers (and I'm NOT typical administrator so > > note my knowledge is rather limited) - every time I tried it on Gentoo it dealt > > me significant amount of pain of writing virtualhost definitons from scratch > > and caused breakages on apache updates. > > you're doing it wrong then ... No, you're doing it wrong because emerge -1 apache (exact same release or even minor patch release upgrade) should not break my setup nor need *any* manual intervention (see dispatch-conf points earlier). > > Debian layout on the other side proved > > well thought (they don't need to care of compilation like we do, so they can > > afford spending more time on tweaking user experience), easy to maintain and > > relatively breakage-free on updates - so superior in any case in my opinion. > > well, in my opinion the whole symlink hell in debian just freaks me out :) Well, apparently you've never used it then. Try it, it's not that scary ;) Actually with bash-completion it's extremely convenient and those issues with apache configs and modules on upgrades are virtually not existing there. I wouldn't bother elaborating with you if I wasn't convinced myself. While I understand well and myself follow the idea of "who does the work - decides", I don't understand that you prefer to WONTFIX it without giving it any thought or just out of boredom (and of course decrease bugs count so one can say - "no bugz C? we rulz :P") I'm quite busy with Gentoo KDE releases already (~250 packages mind you) so cannot help Gentoo Apache team in this regard right now, just wanted to waste my time proposing some improvements in Gentoo apache2 area which is handled in abysmal way comparing to Debian for instance (and it's not just my opinion mind you). While I have wrangling powers, I won't stop you from shuffling the problem under the carpet, it's your call.
Discussing configuration updates issues (in general) this morning on #-desktop, this bug was braught to my attention. I have to say, being a long time user of gentoo-style apache configuration and just having used debian-style layout for a year, I think reavertm has a point. The cost of maintaining apache configuration in gentoo makes me delay those updates until I have a large chunk of free time to take care of it which is a bit annoying. In debian, there is a clear place for all modules available for the system (just like gentoo you'll say), they are as easy to enable as in gentoo, it's just that keeping them enabled is zero cost while in gentoo, you get the chill each time you edit /etc/conf.d/apache2. If you don't like importing a2* scripts (which are just ln + a few checks), it's easy to write an eselect module doing the same, and it's more gentoo-y. Please consider that's we are not asking a full copy of what debian does, but at least giving some thoughts on making apache even more seemless to upgrade in gentoo.
(In reply to comment #2) > I don't understand that you prefer to WONTFIX it without giving it any thought i have given it many thoughts, and i really don't like symlink hell. i agree that defines are not the best solution either. the best thing would be to just add the wanted modules to the config file, but this is not "out-of-the-box" enough for our poor users who cannot be bothered with some config file editing ... and, btw, if someone would change the way apache works in gentoo, probably the other half of users will scream to have the old way back, so all this is pointless
(In reply to comment #3) > Please consider that's we are not asking a full copy of what debian does, but > at least giving some thoughts on making apache even more seemless to upgrade in > gentoo. well, nobody has time for such useless refactoring, but i will reopen this bug, so maybe we can think about something for apache 2.4
Hello, I do not know if this is a solution, but a simple change to /etc/apache2/vhosts.d/default_vhost.include makes my life much easier... I added at the end of the file: Include /etc/apache2/vhosts.d/conf.d/*.conf And manages the site specific configuration within the conf.d structure. One line addition and that's it. Maybe this can be an intermediate solution.
