ViMbAdmin and mod_rewrite

Well, I use ViMbAdmin for the mail box administration of my users (and aliases) on 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.

  1. ViMbAdmin has been updated to require PHP composer (which populates the vendor/ folder)
  2. 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.

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

Subversion via HTTP(s) and mod_rewrite

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:

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

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

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

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

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

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

subversion on WebDAV with Active Directory authorization on SLES10

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:

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

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

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:

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

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:

  1. We don’t have the manpower and/or time to maintain it any longer
  2. 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 or copy it to an local/whatever overlay now, as its still in the tree.

SLES-9 (once again)

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:

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.