Apache 2.4.4 released

Working without problems here too, on CentOS 6.3 64bit. Also I noticed that Apache server status page now show server load, that was a nice addition.
 
I am running custombuild 1.2. Upgraded from Apache 2.4.3 to 2.4.4, and .htaccess password protection does not work anymore. It is impossible to log in to any site protected by .htaccess password protection.
 
When trying to log into a .htaccess password protected directory, it give this error in apache error log (I have changed the ip and username):

Code: 
[Tue Feb 26 15:54:47.815992 2013] [auth_basic:error] [pid 493] [client 12.345.67.89:56886] AH01617: user USERNAME: authentication failure for "/": Password Mismatch
 
Also when using the file manager to password a new directory, it still does not work. Also when I use DirectAdmin to remove the password protection, then it give a "Internal Server Error" on the site. Then the only way to fix it is to manually delete the .htaccess file in public_html

Edit: The strange thing is that password protection of phpMyAdmin still work, and I can log in without problems. It seems it is only password protection that is created by DirectAdmin File Manager that no longer works. As said by user explosive in this post http://forum.directadmin.com/showthread.php?t=45771&p=234397#post234397 there is several changes regarding .htaccess password in changelog for Apache 2.4.4
 
Last edited:
After working directory of Eternity password protected areas will not be allowed to enter
The solution to this is
Back to 2.2.23 did not fix the problem!
 
It seems to be fixed in next version of DA http://www.directadmin.com/features.php?id=1429 - however that is not good enough for me. I have upgraded all my servers, and my shared hosting clients can no longer log into their password protected sites. I need DirectAdmin to make a fix for existing sites, or at least publish a new version of DirectAdmin immediately wich has the fix in the link. We can't wait days and weeks for this fix to be released. :(
 
Last edited:
I found the cause now. It's not related to Apache 2.4.4 at all. It's apr-util 1.5.1 related. With earlier versions it was possible to use the DA generated .htpasswd files (however, apr1 format is the one that should be used, so the bugfix in 1.43 is still important). A temporary fix for now:
Code: 
mv /etc/httpd/lib /etc/httpd/lib.back
cd /usr/local/directadmin/custombuild
./build update
perl -pi -e 's|[COLOR=#000000]apr-util:1.5.1:490c2e26e2dc95fd0983ad71112ddac6|[/COLOR][COLOR=#000000]apr-util:1.4.1:|' versions.txt[/COLOR][COLOR=#000000]
[/COLOR]./build apache

Now "httpd -V" should report apr-util 1.4.1 instead of 1.5.1.
 
Thanks. When can we expect DirectAdmin 1.43 to be released? I would then have to downgrade apr-util temporary, and then when DirectAdmin 1.43 is released, I would upgrade apr-util and contact all my customers and tell them to update their .htaccess password in DirectAdmin File Manager. This is no fun at all.
 
What shall I do? Upgrading Apache or waiting.. I don't want to use temporarily fixes, is it better to wait?
 
Hello,

1) I've changed the versions.txt back to 1.4.1 until more information can be found:
- if it's either a bug in apr-util to not allow $1$ passwords
- if there is an --configure apr-util option to allow them
- if it was an apr1 bug to allow $1$ in the first place.

so a regular apache compile will put 1.4.1 back.
Code: 
cd /usr/local/directadmin/custombuild
./build update
./build apache; ./build php n;
(may take up to 24 hours for files1 to rsync to the other mirrors)

2) If you want the DA change to use $apr1$ (which will stay), install the pre-release binaries:
http://help.directadmin.com/item.php?id=408

3) Regardless, if the passwords need to be changed to $apr1$ from $1$, there is no way to convert them, they're all one-way encoded.
If that's the final answer (if apr1 is needed), then Users will have to go back and reset them.
apr1 is actually a proprietary form of crypt.. they're very close, but not compatible (Eg: we can just swap the $1$ for $apr1$),
but for whatever reason, 1.5.1 doesn't like $1$ anymore, when it previously did... hence the issue.
I have not yet found any documentation to explain this.. so again, not sure if it's a bug, or an intended change, etc..

John
 
I would advice against doing this:
Code: 
mv /etc/httpd/lib /etc/httpd/lib.back

Because if you have installed other modules, you might loose them.

But it is needed to remove the apr-util files, if not, apr-util will not downgrade when you run ./build apache

This worked for me, and seems safe. I deleted the following from etc/httpd/lib:

Code: 
libapr-1.so.0
libaprutil-1.so.0
libapr-1.so
libaprutil-1.so
pkgconfig
libaprutil-1.so.0.4.1
libaprutil-1.so.0.5.1
libaprutil-1.so.0.3.12
libapr-1.so.0.4.5
libapr-1.so.0.4.6
libapr-1.a
libaprutil-1.a
apr.exp
aprutil.exp
libapr-1.la
libaprutil-1.la

Then I run:

Code: 
./build update
./build apache
./build php n
./build suphp

And checked with the command httpd -V and now it is apr-util 1.4.1 that is installed.
 
Hello,

Removing all of those files is even more than is needed.

What I've done to all 3 custombuilds, is added code to just remove the 1 library file:
/etc/httpd/lib/libaprutil-1.so.0.5.1

and re-link:
libaprutil-1.so.0 -> libaprutil-1.so.0.4.1

and the $1$ passwords are back in business.
It does this with several checks to ensure that the 1.4.1 library exists first, so that it doesn't just delete things without a plan.

All you need to do is update normally, and after the apache "make install" is done, the 1.5.1 library is automatically swapped out.

Eventually, down the road (not for a while), everyone should be resetting their .htpasswd values to the $apr1$ format (DA 1.43.0 will be needed for this, or use the htpasswd command).. but I understand that this may not be possible, so the day we do upgrade apr-util to 1.5.1 again, I'll ensure there is an options.conf value:
Code: 
old_apr_util=yes
so that it overrides the version back to 1.4.1, regardless of what's in the versions.txt.

Add this to your options.conf now if you want to avoid having to remember.
Code: 
./build set old_apr_util yes

I've found that Apache 2.2 is not affected by this at all, since it's got these functions bundled in.

John
 
I tried point 2 John but I get the same issue.

Server loaded: APR 1.4.6, APR-UTIL 1.5.1
Compiled using: APR 1.4.6, APR-UTIL 1.4.1

Am I under the impression I need to delete something like ditto has in order to remove the 'server loaded' version and to use the complied version?
 
If you're not using file1, I'm guessing it's just not updated with the code yet.
You can confirm by typing:
Code: 
ls -la /etc/httpd/lib/libaprutil-1.so*
which should give something like this:
Code: 
[root@es5 lib]# ls -la /etc/httpd/lib/libaprutil-1.so*
lrwxrwxrwx 1 root root     21 Feb 26 23:52 /etc/httpd/lib/libaprutil-1.so -> [COLOR=#0000ff]libaprutil-1.so.0.4.1[/COLOR]
lrwxrwxrwx 1 root root     21 Feb 26 23:52 /etc/httpd/lib/libaprutil-1.so.0 -> [COLOR=#0000ff]libaprutil-1.so.0.4.1[/COLOR]
-rwxr-xr-x 1 root root 379834 Jul 19  2011 /etc/httpd/lib/libaprutil-1.so.0.3.12
-rwxr-xr-x 1 root root 381571 Feb 26 23:52 /etc/httpd/lib/libaprutil-1.so.0.4.1
If you see the libaprutil-1.so.0 symbolic link still pointing to libaprutil-1.so.0.5.1, then it didn't stick.

The manual method is this, but first ensure you have libaprutil-1.so.0.4.1 (don't run this if you are not sure)
Code: 
cd /etc/httpd/lib
rm -f libaprutil-1.so.0
rm -f libaprutil-1.so.0.5.1
ln -s libaprutil-1.so.0.4.1 libaprutil-1.so.0
which is what the CB code does.

John
 
I guess there is a bug. Viewing a phpinfo() page shows me a lot of version numbers like "$Id: 209a1c3c98c04a5474846e7bbe8ca72054ccfd4f $".
 
You must log in or register to reply here.
Back
Top