Apache – BAFM

ViMbAdmin and mod_rewrite

December 2, 2014December 2, 2014 Christian Leave a comment

Well, I use ViMbAdmin for the mail box administration of my users (and aliases) on heimdaheim.de. After I while (well, over half a year I guess), I decided to look at it again. However it didn’t work. Well this was a multi-part problem.

ViMbAdmin has been updated to require PHP composer (which populates the vendor/ folder)
the application.ini was outdated

After I fixed all that, ViMbAdmin was working again. However I decided to replace my mod_rewrite stuff (I had in my apache config from the previous version) with the one from the Documentation and that actually made things worse. So I ended up *redigging* into mod_rewrite (again *sigh*) and rewrite the Rewrite Rules… This time I’m documenting it.

        <IfModule mod_rewrite.c>
                RewriteEngine On
                RewriteCond %{REQUEST_FILENAME} !-d
                RewriteCond %{REQUEST_FILENAME} !-f
                RewriteCond %{REQUEST_URI} !^/(img|images|css|js)/(.*)$
                RewriteRule ^(.*)$ /index.php [QSA,L]
        </IfModule>

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_URI} !^/(img|images|css|js)/(.*)$

RewriteRule ^(.*)$ /index.php [QSA,L]

</IfModule>

Keep in mind, this is part of my apache config, not a .htaccess file.

Subversion via HTTP(s) and mod_rewrite

September 28, 2008June 21, 2013 Christian Leave a comment

Well, I just finished my wild-goose chase with Apache and subversion regarding a rather weird error. I recently reinstalled our subversion box, and ever since then I was unable to commit anything new to any of the repositories.
Subversion told me this:

svn-client admin-scripts [1] &gt; svn ci -m &quot;Directories for Tivoli Storage Manager Scripts.&quot;
svn: Commit failed (details follow):
svn: MKACTIVITY of &#039;/svn/admin-scripts/!svn/act/someid&#039;: 302 Found

svn-client admin-scripts [1] > svn ci -m "Directories for Tivoli Storage Manager Scripts."

svn: Commit failed (details follow):

svn: MKACTIVITY of '/svn/admin-scripts/!svn/act/someid': 302 Found

Apache didn’t say much about it either, besides this particular line:

[25/Sep/2008:09:22:43 +0200] &quot;MKACTIVITY /svn/admin-scripts/!svn/act/someid HTTP/1.1&quot; 302 331

1	[25/Sep/2008:09:22:43 +0200] "MKACTIVITY /svn/admin-scripts/!svn/act/someid HTTP/1.1" 302 331

Today I sat down and thought really hard, what exactly was different from before.

Installed Trac instead of Redmine, but that can’t have anything to do with the error
Configured URL rewriting …

As it turns out, the following RewriteRule was the cause:

  ## mod_rewrite
  RewriteEngine On
  RewriteCond %{REQUEST_URI}  !^/(projects|svn)* [NC]
  RewriteRule ^/  http://subversion.home.barfoo.org/projects [L,R]

## mod_rewrite

RewriteEngine On

RewriteCond %{REQUEST_URI} !^/(projects|svn)* [NC]

RewriteRule ^/ http://subversion.home.barfoo.org/projects [L,R]

After changing the Rewrite Rule (as showed below, compare the difference yourself 😛 ), it works just like a charm.

  ## mod_rewrite
  RewriteEngine On
  RewriteCond %{REQUEST_URI}  !^/(projects|svn)/*$ [NC]
  RewriteRule ^/$  http://subversion.home.barfoo.org/projects [L,R]

## mod_rewrite

RewriteEngine On

RewriteCond %{REQUEST_URI} !^/(projects|svn)/*$ [NC]

RewriteRule ^/$ http://subversion.home.barfoo.org/projects [L,R]

Hint to self: whenever encountering HTTP 302 in conjunction with Subversion, check the RewriteRule’s ❗

subversion on WebDAV with Active Directory authorization on SLES10

June 29, 2008June 21, 2013 Christian Leave a comment

Okay, so I ended up toying with subversion via WebDAV on SLES today (I know, I know .. it’s bloody Sunday). It wasn’t much of a hassle though, after reading this. Sure, I made a few errors at first (simply confused the logic behind “Location” and “Directory“), but after that plain subversion commits via WebDAV (thus utilizing Apache) worked fine.

For POC or as a hint to myself, here’s where and what I needed to add/change:

Add the following modules to APACHE_MODULES in /etc/sysconfig/apache2:

dav_svn (dav_svn needs dav, thus the need to add it too)
dav
authnz_ldap (authnz_ldap needs ldap, so again we need that too!)
ldap

After that, we can add our repository (or our multi-repository folder) to /etc/apache2/conf.d/subversion.conf:

&lt;IfModule mod_dav_svn.c&gt;

&lt;Location /svn&gt;
  DAV svn
  SVNParentPath /srv/svn

  # Limit write permission to list of valid users.
  &lt;LimitExcept GET PROPFIND OPTIONS REPORT&gt;
    # Require SSL connection for password protection.
    # SSLRequireSSL

    AuthType Basic
    AuthName &quot;Subversion repositories (Domänenzugangsdaten)&quot;

    # The authentification provider is mod_ldap
    AuthBasicProvider ldap

    # mod_ldap is our *only* authentification provider for this!
    AuthzLDAPAuthoritative on

    # AD requires an authentication DN to access any records
    AuthLDAPBindDN &quot;CN=LDAP Subversion,OU=anon_accounts,OU=Users,DC=foobar,DC=org&quot;
    AuthLDAPBindPassword &quot;somethingrandom&quot;

    # The URL to search in
    AuthLDAPURL &quot;ldap://dc0.foobar.org/ou=Users,dc=foobar,dc=org?sAMAccountName?sub?(objectClass=*)&quot;

    # Search the group membership in the specified group, otherwise it&#039;s gonna
    # get searched at the binding DN&#039;s location
    AuthLDAPGroupAttributeIsDN on
    Require ldap-group CN=gr_subversion,OU=Groups,DC=foobar,DC=org

  &lt;/LimitExcept&gt;
&lt;/Location&gt;

DAV svn

SVNParentPath /srv/svn

# Limit write permission to list of valid users.

# Require SSL connection for password protection.

# SSLRequireSSL

AuthType Basic

AuthName "Subversion repositories (Domänenzugangsdaten)"

# The authentification provider is mod_ldap

AuthBasicProvider ldap

# mod_ldap is our *only* authentification provider for this!

AuthzLDAPAuthoritative on

# AD requires an authentication DN to access any records

AuthLDAPBindDN "CN=LDAP Subversion,OU=anon_accounts,OU=Users,DC=foobar,DC=org"

AuthLDAPBindPassword "somethingrandom"

# The URL to search in

AuthLDAPURL "ldap://dc0.foobar.org/ou=Users,dc=foobar,dc=org?sAMAccountName?sub?(objectClass=*)"

# Search the group membership in the specified group, otherwise it's gonna

# get searched at the binding DN's location

AuthLDAPGroupAttributeIsDN on

Require ldap-group CN=gr_subversion,OU=Groups,DC=foobar,DC=org

</LimitExcept>

</Location>

Now, as you can see, my goal was to not rely on a separate authorization database, but to use our already existing Active Directory at work. Generally this works just fine, but it didn’t. I tried various things, like trying another user, changing the group (as in the “require ldap-group“) as well as changing my own password. Zip.

All I got was this line in the error_log of Apache:

[warn] [client 10.0.0.148] [9486] auth_ldap authenticate: user foo authentication failed; URI /svn/admin-scripts/!svn/act/71f2b65f-d050-0410-b33c-3b31fbb94a00 [ldap_search_ext_s() for user failed][Operations error]

1	[warn] [client 10.0.0.148] [9486] auth_ldap authenticate: user foo authentication failed; URI /svn/admin-scripts/!svn/act/71f2b65f-d050-0410-b33c-3b31fbb94a00 [ldap_search_ext_s() for user failed][Operations error]

Now, that itself does tell you what is happening, but not why. So again, I ended up googling till I found this:

The suggested step was to add “REFERRALS off” to /etc/ldap/ldap.conf. Surprise, the file don’t exist. Heck, there’s that one in /etc/ldap.conf. I did that, still zip.

Did I get the wrong file ? Absolutely.

/etc/ldap.conf is used by nsswitch and pam_ldap, but not by openldap2 (which is what Apache is using). So reading this comment, adding the line to /etc/openldap2/ldap.conf, and *kaching*! Works.

Now I just need to install redmine (already installed ruby, rubygems and rubygem-rails from the SDK Addon), but I’ll leave that for tomorrow, today I’m gonna watch Band of Brothers.

Progress with apache-2.2

May 28, 2007May 28, 2007 Christian Leave a comment

We’re finally making some progress with apache-2.2. It left the package.mask on the 8th of May (that’s like 3 weeks from tomorrow), we split some helper scripts into a separate package (app-admin/apache-tools).

I already fixed a few screwup I did myself (like apxs missing from either apache and apache-tools, or the compatibility symlinks being missing), so we “just” need to fix all the modules in the tree before apache-2.2 is going to get the new stable version (and of course anything else depending on. What also remains to do, is committing the new-style virtuals for bug 11007.

Also apache-1* is going to get removed from the tree pretty soon now (like starting next month 12th iirc). Now if anyone is going to start again, about apache-1* being “sooo” great and “waaay” better then the 2.* series, it may be yes.

But the point is, we (as in the apache team) needs to maintain it. Some other points include:

We don’t have the manpower and/or time to maintain it any longer
We don’t have the slightest interest anymore in apache-1, which hasn’t seen a release in about a year (July 2006 was the last release)

So, if you want to keep it around, either grab it from the attic at anoncvs.gentoo.org/sources.gentoo.org or copy it to an local/whatever overlay now, as its still in the tree.

SLES-9 (once again)

March 8, 2007June 21, 2013 Christian 1 Comment

OK, so today was the highlight of the week … We updated apache2 on Tuesday (yeah, that’s still 2.0.49, so if you have some exploits – try them 😛 ) and now out of the sudden we have major performance issues. We looked nearly the whole forenoon for a reason, *why* the frackin’ apache was using 236% of the CPU’s.

In the afternoon, when my co-worker decided to go home (that was ~1500), I decided to revert back to the old patch level. But that isn’t as easy as you think (at least on SLES). The only thing I wanted to do, was something like this:

$ emerge &#039;&lt;apache2-2.0.49-r63&#039; &#039;&lt;apache2-mod_php4-2.0.49-r63&#039; &#039;&lt;apache2-mpm_prefork-2.0.49-r63&#039;

1	$ emerge '<apache2-2.0.49-r63' '<apache2-mod_php4-2.0.49-r63' '<apache2-mpm_prefork-2.0.49-r63'

Looks like SuSE (or Novell who bought SuSE sometime 3 or 4 years ago) doesn’t consider reverting to an older patch level. Which means I would have to remove apache2, apache2-prefork, apache2-mod_php4; fetch the basic RPMS from our FTP server (which sadly forbids directory listing, so I can’t exactly look for the original RPMS) and I tried to blindly to fetch them.

Foooked. Didn’t work .. now I cron’ed the POS to restart every half an hour, so at least we have *some* solution. Will see about reverting the the last patch tomorrow again, hopefully I’ll find the original RPMS.