On 02/20/09 20:35, Jeff Trawick wrote: > (a simple diversion I hope from the other thread; I'll get back to that > as soon as practical, and I appreciate the contributions there) > > We're getting pretty late in the 2009.06 cycle, so big changes for > Apache configuration aren't likely to be introduced until post-2009.06 > development builds begin. I think we should consider attacking one > aspect of the existing configs in the very short term: extraordinary > virtual memory use. > > Our basic philosophy is that installed features should be immediately > consumable with no additional configuration. As an example, simply > installing Apache and PHP allows you to plop a PHP application in a > reasonable location on the filesystem and it just works, because of the > default configuration which is delivered. You don't have to know much > at all about Apache and PHP, and you can quickly get a real application > running. > > Some of the default Apache configuration doesn't provide such immediate > value. Here are just a few examples, all of which do nothing but > consume memory and limited CPU cycles until you change the Apache > configuration: > > mem_cache and disk_cache are loaded by default, but > * the vast majority of Apache configurations don't use either > * those that do almost always use only one of them (and mem_cache is > relatively unloved) > * anybody who can figure out their configuration will have no problems > uncommenting out the necessary LoadModule directives > > all the proxy modules are loaded by default, but > * most Apache configurations don't use any of it > * some of the protocol modules, such as connect and ftp, are used very > rarely > * figuring out which LoadModule directives to uncomment isn't difficult > ** they'll quickly determine that they need to enable mod_proxy.so, and > commentary in the config file next to that directive could explain when > the others are needed, as the error messages for missing protocol > support require a search engine for interpretation IIRC > > all the authn/authz modules are loaded by default, but > * some of the database-specific modules are almost never used > * when Apache auth other than host-based is used, usually only one of > the database-specific authn and corresponding authz modules is used > * host-based is commonly used, and some of the modules for the > authn/authz infrastructure are error prone to determine so they should > remain loaded by default, but the database-specific modules are > relatively easy for a user to determine (the directives you add are > specific to those modules) >
+ 1 > (more examples upon request) > > Any concerns/objections, or comments on the practicality of getting this > changed in time for 2009.06? > Should be possible to address it in b111 if not in b110. > One obvious concern is during an OpenSolaris upgrade. I don't know what > happens with conf files during that operation. If a user has to > manually maintain their own httpd.conf (where they may have added > directives which utilize some of these modules) then they also have to > to preserve their modules-32.load/modules-64.load, even if they didn't > modify it; if a modified httpd.conf would be retained automatically but > an unmodified modules-nn.load would not, then their configuration could > be broken. If we are providing new modules-*.load files, then during upgrade, if the user has modified the existing httpd.conf but not modified modules-*.load files, then all of them (user's copy) will be preserved and the newly installed ones will be installed with .new extension. [ Our class action script, renamenew, does a "cmp -s $old $new" which in the above case will return non-zero status for httpd.conf and modules-*.conf files. ] Regards, Seema.
