http://bugzilla.suse.com/show_bug.cgi?id=939829 http://bugzilla.suse.com/show_bug.cgi?id=939829#c1 Petr Gajdos changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pgajdos@suse.com Assignee|bnc-team-apache@forge.provo |lars.vogdt@suse.com |.novell.com | --- Comment #1 from Petr Gajdos --- (In reply to Thomas Wagner from comment #0)

Solution 1) is IMHO the way to go. However it's incompatible with apache 2.2 and server:monitoring builds for lots of distributions. Is any of these still using apache 2.2?

Yes, there are, for example 13.1. But a patch can be applied depending for which distro is nagios building. Ideally, the old and new syntax should be used depending if access_compat module is loaded, see https://build.opensuse.org/package/view_file/devel:tools:scm/git/apache2-git... for example. Lars, it seems you are maintaining nagios, aren't you? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=939829 http://bugzilla.suse.com/show_bug.cgi?id=939829#c3 --- Comment #3 from Thomas Wagner --- (In reply to Petr Gajdos from comment #1)

Ideally, the old and new syntax should be used depending if access_compat module is loaded, see

https://build.opensuse.org/package/view_file/devel:tools:scm/git/apache2- gitweb.conf

How does this config file work with apache 2.2? IMHO would resolve to "True" and the "Require" part is included in apache 2.2 instead of the "Order/Allow" part. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=939829 http://bugzilla.suse.com/show_bug.cgi?id=939829#c5 Lars Vogdt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED CC| |lars.vogdt@suse.com, | |wagner-thomas@gmx.at Flags| |needinfo?(wagner-thomas@gmx | |.at) --- Comment #5 from Lars Vogdt --- FYI: I accepted request 319692 - but shortly after that I noticed that Nagios Enterprises released a newer nagios version (4.1.0) containing a slightly different configuration that uses mod_version to determine if the old or new options should be used. To follow upstream a bit more, I decided to remove the nagios-apache24.patch and instead rely more on the upstream sample configuration (and load mod_version in apache2). Nevertheless I added a small patch that brings kohanna back into the game if it is available. @Thomas: can you please test if the latest nagios package works for you? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=939829 http://bugzilla.suse.com/show_bug.cgi?id=939829#c8 --- Comment #8 from Petr Gajdos --- (In reply to Andrew Daugherity from comment #7)

This happens if your are using mod_access_compat. When that is enabled, you *must* use the 2.2 syntax and you'll get a 403 if trying to use the 2.4

*Generally*, that is not exactly true as far as I know. If both authz_core and access_compat are loaded, you can use either system you want.

Require ... syntax. It might work to use both at once but that gets confusing (and possibly undefined if they conflict!).

You can even use both of them together, but the result has to be consistent, that is: access is allowed if both systems allow. If at least one forbids, access is forbidden. See 881506 comment 18.

Because of this, relying on a version check is insufficient, as 2.4

Yes, thats true (because of access_compat), nevertheless ..

w/mod_access_compat behaves like 2.2. Adding wrappers like <IfModule mod_access_compat.c> Order allow,deny Allow from all </IfModule> Require all granted </IfModule>

.. whether this will work depends also on which syntax is used previously. If mod_access is loaded but new syntax forbid into this dir, this won't work. Also note that access_compat is not present in sle11. So I would disclaim my comment 1 for distros older than Tumbleweed.

e.g. default-server.conf. I would suggest backporting the fix to 13.1/13.2, but that's beyond the scope of this bug, and the other one is closed, so ???

In my opinion, this is too invasive change to backport, I am afraid. The situation on newly installed distros (not upgrades!) is as follows: sle11 no access_compat httpd.conf (Deny for /): old syntax 13.1 access_compat static httpd.conf (Deny for /): new syntax 13.2 access_compat static httpd.conf (Deny for /): new syntax Tumbleweed access_compat shared, not loaded by default httpd.conf (Deny for /): old syntax when access_compat loaded, new syntax otherwise So everywhere in supported openSUSEs we can assume that new syntax should be preferred. I tend to agree with Lars to use upstream solution. Currently I do not se a way to catch all possibilities. -- You are receiving this mail because: You are on the CC list for the bug.