Solution to modules not loading with art's php 4.4.0-3

breun · Unread post by **breun** » Wed Sep 28, 2005 7:14 pm

I just upgraded to art's php 4.4.0-3 packages on FC2 and FC3 servers, because it was reported that mail() was working again (was broken in the last couple of art php releases). But this time MySQL (amongst others) was not working with php.

I found the solution was setting extension_dir in /etc/php.ini to "/usr/lib/php4" instead of art php's default "./". Scott, could you maybe fix the php.ini you're shipping?

Unread post by **scott** » Thu Sep 29, 2005 7:24 am

when you upgrade php, it should not replace your existing php.ini. It should instead create /etc/php.ini.rpmnew.

breun · Unread post by **breun** » Thu Sep 29, 2005 7:45 am

That's right, but shouldn't that php.ini.rpmnew be a working php.ini?

Unread post by **scott** » Thu Sep 29, 2005 9:10 am

Generally the php.ini is one of the more frequently modified configs (zend, ioncube, register_globals, etc) so its rarely replaced. Because of that, I do what I can to stay far away from it on the rpm side.

dmoses · Unread post by **dmoses** » Mon Oct 24, 2005 8:24 pm

What determines if the php.ini file would get overridden? If it was modified since the original base install than it is kept otherwise it is overwritten? I think that is the basic policy of how rpms work, would arts rpms be the same?

I happened to loose my php.ini while testing the new php rpm on a non production server. I think it is always best to make backups of config files before updating. Seems like good policy...just in case.

breun · Unread post by **breun** » Tue Oct 25, 2005 8:37 am

dmoses wrote:What determines if the php.ini file would get overridden? If it was modified since the original base install than it is kept otherwise it is overwritten? I think that is the basic policy of how rpms work, would arts rpms be the same?

I don't know, but if the art rpms are the first php rpms you're installing on your server you also have non-working modules.

dmoses wrote:I happened to loose my php.ini while testing the new php rpm on a non production server. I think it is always best to make backups of config files before updating. Seems like good policy...just in case.

Sure thing.

Unread post by **scott** » Tue Oct 25, 2005 3:55 pm

the php.ini file is designated as a "config" file by the rpm. That means when a new rpm comes in to upgrade it, internally the rpm package will instead install the new file as <original filename>.rpmnew. You could force that file to be overwritten inside the rpm, in which case it will back up the old config file as <original filename>.rpmsave.