[KLUG Members] Authentication in Apache 2.0 (Joys of Upgrading)

[Adam Williams]

>>I was using Apache 2.x with htaccess files and it work.
>Version?
>Were you loading the PHP load module? (Just curious, this just occured
>to me).

I did all of my testing with the binary modules provided with RH8.
Unable to compile a PHP module I had no other choice. :)

>>However,  the  loading of the authentication modules did initially fail;
>>evidenced by  so-and-so has seg faulted messages in /var/log/httpd/error.log.
>Yeah, mine all loooked like:
>[notice] child pid 2032 exit signal Segmentation fault (11)
>fter the timestamp stuff. No module or anything identified. Not 
>really the greatest diagnostic. I'd prefer even a cryptic error message.
>I've even considered debugging this (can't be worse than MY code! :).

Yes this is very similiar to what I had.  I no longer have the logs
around, but for me every seg fault was preceded by a line about not
being able to create LDAP client cache, so it was pretty obvious that it
was mod_auth_ldap, especially since authentication wasn't working.
 
>>While apache seemed to work fine.  That may or may not have to do with the 
>>particular apache module I was using for authenticaion (mod_auth_ldap),  
>>recompiling fixed it (odd?).
>Maybe odd.. maybe library linking problems, maube headers outta synch with 
>binaries ... were there lots of warnings in the build?

It was RH8's binary module.  Rebuilding proceeded without errors and the
module installed and worked as expected.  This is all with RH8's ldap
libraries, ldap auth module, etc...  But then their QC still misses some
LDAP and Kerberos related items, and has done so for the past few
releases, so I wasn't that terribly surprised; and it was easy enough to
fix.

>But overall, I tend to agree; it's a module-by-module problem. Either the
>module is working with the new API, or it probably isn't. I haven't taken

I don't know how much the API changed, but I did read that everything
now had to be thread safe (reentrant) and that that was the big hold
up.  I'd imagine existing in a reentrant environment while not being
reentrant could result in some pretty bizarre behavior. My sneaking
suspicion is that all the little modules aren't quite into tune with the
orchestra yet.

>the time to study the new API specification, so I won't comment yet on how
>big the change is, but my understanding is that a lot of things have changed.
>It does boggle my mind more than a little to think that a module as commonly
>used as mod_auth is not released in tip-top shape, if in fact that is the
>problem.
>>But due to various problems (unable to compile PHP) I've abandoned and 
>>gone back to apache 1.3.27
>Interesting! I know you do not abandon this kind of thing easily...
>Did you find the rollback difficult? I'm considering unwinding all
>those dependencies...try any shortcuts?

It was trivial.  I never had to mod my config files.  So I just rpm -e'd
and rpm -Uvh'd.  I built Apache 1.2.27 from the source RPM for 7.3. 
Then rebuild PHP, which went forward effortlessly.

>>>There are advisories against using Apache 2 and PHP on a "production"
>>>server; this server will not be considered production until those is-
>>>sues are resolved... It is useful to configure and test this migration
>>>NOW, rather than wait...
>>We've tested and been beaten senseless.
>Oh? Please describe waht you mean by "beaten senseless"... sonething I
>can look for in volume testing?

Well, the mod_ldap_auth took a good deal of time to fix, although once I
saw the seg faults it was obvious.  I just didn't expect that kind of
problem with a distributed module, although in hind sight I'm not that
surprised.  I spent almost a whole day attempting to build PHP, checking
to make sure headers were in the right place, checking developement RPMs
were installed and valid, defining environment variables so that
header/libraries were found in a particular order, etc...  Compiling
always worked,  but linking died with both symbol unresolved messages
and others which I'm just not compiler savy enough to understand (they
included hexadecimal strings...blech).

>>Actually we never really tested since compiling PHP against Apache 2.x
>>requires magic beyond our abilities.
>Please, details. Versions, problems with compiling? Seems like the 

Linking actually, as I recall.

>problems are pretty severe if one can't build this stuff...I wonder
>how it was built to start with... Need a Sourceware[sm] CD set? :)

I did compile apache from the RH8 source RPM, just to see if it would
work.  That went fine.

But I have to have an uber-PHP module - Informix support, Epinions
XML-RPC support, mcrypt/mhash support...   I end up with a PHP configure
line like -

./configure --with-informix --with-unixODBC --with-gd=/usr --with-ttf
--with-zlib --enable-ftp --with-imap --with-ldap --enable-sockets
--enable-sysvsem --enable-sysvshm --enable-track-vars --with-kerberos
--with-imap-ssl --with-xml --with-dom --with-jpeg-dir=/usr
--with-png-dir=/usr --with-mcal=/usr --enable-wddx --with-zlib-dir=/usr
--without-mysql --enable-gd-native-ttf -with-freetype-dir=/usr
--with-gettext --with-pgsql --with-apxs --with-mcrypt --with-mhash
--with-xmlrpc

>>>Do others have the same experience? Is there some terrible flaw in
>>>authentication, or something really radically new? Why is this 
>>>aspect of migration (after checking file permissions, ownerships, 
>>>paths, etc.) proving to be so difficult? I would think that as this
>>>is a fairly direct port from a working 1.3.x server, the problems
>>>would be fairly easily resolved, especially as there are no notes
>>>that related to this in moving from 1.3.x to 2.0.x....
>>Yes, the documentation on moving from 1.3.x to 2.0.x is scant to
>>say the least.
>Scant to the point that one might hink the migration to be almost
>trivial, or the bulk of the documentation is unwriiten, or unposted.
>Status of each module might be nice...as would a minimal module 
>configuration, in addition to/insteas of rebulding...

Centralized consistent documentation?!  I've been nearly cussed out by
freshmeat moderators for even suggesting it.

>Overall, it looks like you are verifying/validating my experience (I
>don't relish being right about these things). Please verify this and
>supply a bit more detail (in your copious free time, of course! :).

If I get a moment I'll try a PHP build on an Apache 2 box (if I can
still find any :) and send you the copious error messages.

>One workaround I am thinking about is moving off mod_auth and writing
>my own user authentication/password scheme as part of the login of the
>website/application. Really, using SSL, one can do more secure logins
>than any of the mod_auths provide. A possible excpetion to this is the
>new mod_auth_digest, which is support by what clients??

I just got done doing some research with http authentication between
client and proxy (squid).  Digest is recommended and sounds nice, and
claims support from Mozilla/Galeon.  But documentation - Nil.  I
actually just enabled M$-NTLM in squid, because documentation existed
and it worked very straight forward.  My goal was/is as always to
eliminate password prompts for users.  Digest theoretically can do that
- how?   Beats me.  The only documentation I could find was the RFC,
which doesn't help in actually using it with existing software packages.