[TriLUG] Apache2 / PHP / MySQL Help?

Justis Peters jtrilug at indythinker.com
Wed Mar 26 13:23:38 EDT 2008


Brian McCullough wrote:
>>> Unfortunately, it is a client machine, in a rack in San Jose, installed
>>> with Debian Sarge.  
>>>       
>> Well, my suggestion to avoid the problem and use virtualization was 
>> before I knew that it was for an existing client on an existing server.  
>>
>> Based on the current machine setup, though, you're not going to be happy 
>> with virtualization as the solution, unless you move all the virtual 
>> hosts into one or two VMs.  You generally don't want to give each 
>> website its own virtual machine, unless there are compelling security or 
>> scalability reasons to do so.  
>>     
>
> Which I don't.  I don't have much experience with VMware, having started
> with Xen, and generally liking it.  However, it means completely
> rebuilding the machine, which the client isn't too enthusiastic about,
> since he is here on the right coast, with me, and the machine is on the
> left.
>   
Don't forget that my original suggestion was to use a LAMP appliance 
from rPath.  They have domU versions for Xen, too.  So, you can stay in 
your familiar territory.  I still think it's within reach to fix the 
existing installation, though.  I'm just suggesting that you keep the 
domU LAMP appliance in your back pocket in case that doesn't work out.
>> I don't know how a 
>> standard Debian system gets setup, but I know that many distros have 
>> modularized popular packages like Apache and PHP in order to make 
>> package management easier.  
>>     
> Which Debian-based and Debian-like systems do, too.  I even have an old
> machine here that has been ( mostly ) retired, running an early Ubuntu,
> which seems very like the Fedora server that you described.  What was
> very interesting about this Debian system is that it seems to be getting
> information from somewhere else.  When I commented out the
> "extension_dir" statement in the "official" php.ini file, a value showed
> up in the phpinfo() output which was correct, but which I had not put
> there!   Similarly, when I installed the "php4-gd" package, gd.so showed
> up under /usr/lib/php4, "extension=gd.so" is NOT enabled, and there is 
> no "gd.ini" file under /etc/php.d, but GD shows up in phpinfo()! In
> fact, there is no php.d directory, like my Ubuntu system, which also
> seems to magically get its information from somewhere else.  Neither
> system seems to have an "/etc/sysconfig" directory, which Red Hat-like
> systems do.  There is only /etc/php4, not /etc/php.d, and /etc/php4 only
> contains apache2/php.ini, which is generally comments, not the commands
> that we both expect.
>   
Perhaps PHP is loading from a different php.ini somewhere.  There could 
be lots of other things going on, too.
>> To find that shared object, it probably goes and looks in the directory 
>> set for "extension_dir".  If it doesn't find it there, it might go 
>> searching through LD_LIBRARY_PATH (but I don't know that for sure).  
>>     
>
> No, it _appears_ to depend on the "extension_dir" directive, I just
> don't know where that value is coming from.
>   
>> You 
>> might want to output that from PHP to find out what its value is in that 
>> environment and make sure it includes the path to your mysql.so.  You 
>> should also be making sure you've got mysqli.so.
>>     
> No mysqli.so, just mysql.so, which was installed automatically by
> "apt-get install php4-mysql".  
>   
I'm guessing that "extension_dir" has a default value, which is compiled 
into the binary.  You could find it by using xxd and grep, I imagine.  
It probably can be overridden at compile time (./configure) and at run 
time (php.info).
>> Don't bother with the HTTP redirect.  For the record, you would probably 
>> want "301 Moved Permanently". The 302 code has been deprecated and 
>>     
> Thanks for the correction.  I didn't have my chart in front of me, and
> the wetware memory isn't necessarily the best solution.
>   
I hope this tip didn't seem either pedantic or didactic.  My wetware 
memory is extremely volatile and, thus, I sympathize.  I just happened 
to have O'Reilly's "HTTP Pocket Reference" sitting next to my keyboard 
from earlier in the day and thought I'd lend you a hand.
> Once again, thank you for the very detailed responses,
>   
You're quite welcome.  I think you were the beneficiary of my insomnia.  
I tend to be rather verbose late at night.

As one more tip, I'd like to point out that your sysadmin may have done 
something previously that has brought this system out of compliance with 
the normal distro settings.  Perhaps he installed the binaries from apt 
the first time and then used "make install" with a hand-built version 
that clobbered the original binaries?  No need for finger pointing, but 
a few tactful questions could save you a wild goose chase or two.

Best of luck.

Kind regards,
Justis




More information about the TriLUG mailing list