Bug 72033 - Completely broken default php.ini file
Completely broken default php.ini file
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: php (Show other bugs)
7.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Copeland
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-20 16:18 EDT by Bernd Bartmann
Modified: 2007-04-18 12:45 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-08-24 18:13:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bernd Bartmann 2002-08-20 16:18:40 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
Yes, I've read in the errata release note that the admin should take care of the
correct settings in the php.ini file. I can understand this argument but I think
you should really provide a config file which at least has some proper defaults.
The biggest problem I've found are the extension= lines. They're all made for
PHP on windows, e.g. ;extension=php_mysql.dll. On linux we don't have *.dll
files here they are called *.so. So for MySQL to work this should read
extension=mysql.so. I'm an expirienced Red Hat user since years and know how to
change this. But Joe user will never get PHP with MySql working with these
strange default settings. Every time the same problems when a new PHP errata
appears. This drives me crazy.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Apply the new PHP errata php-4.1.2-7.3.3.i386.rpm
2. Look in /etc/php.ini.rpmnew for the sample extension= lines

Additional info:
Comment 1 Bernd Bartmann 2002-08-20 16:55:39 EDT
You also should add a section to the errata release notes stating that it is
necessary to restart apache after the update with something like:
service httpd restart
Comment 2 Bernd Bartmann 2002-08-20 17:01:43 EDT
Another problem: Why is the mtime of the old php.ini changed to the update
install time. An ls gives:

[root@swextitt etc]# ls -l php*
-rw-r--r--    1 root     root        23718 Aug 20 22:58 php.ini
-rw-r--r--    1 root     root        27561 Aug  2 22:50 php.ini.rpmnew

One could think that php.ini has been updated although this is not the case.
Comment 3 Heikki Korpela 2002-08-21 08:17:55 EDT
1) the commented out .dll lines are replaced by correct .so lines by the
corresponding php-{mysql,pgsql,whatever} package install scripts. see rpm -qp
--scripts package. it does a perl -pi.

2) the mtime of your php.ini is because of the perl -pi the install/uninstall
scripts do, as I just explained. there's no way around this.

3) not restarting any services follows normal redhat update policy. your apache
isn't automatically restarted on apache update.

A REAL problem with the update php packages are that there are dependencies on
e.g. postgresql and imap packages in the main php package even though there
isn't a single executable or library in the package that would require those
packages. These dependencies should only appear on the corresponding subpackages.

 - heko
Comment 4 Bernd Bartmann 2002-08-21 14:52:02 EDT
Thanks, this gives more light to me, but:

1) Shouldn't this instead happen to php.ini.rpmnew cause here you'll find all
the new options provided by the errata?!

2) See 1) if you change php.ini.rpmnew this problem would not occur.

3) You are right here. I have no problem restarting the services manually. But I
think you should mention that it is necessary to restart the services in the
errata announcement/release notes to take the changes into effect. Otherwise Joe
user will apply the errata but is still running the old code which is still
loaded in memory.

Comment 5 Dale Stimson 2002-08-24 18:13:42 EDT
In my opinion, the errata (at least) is definitely broken.
Presumably because of the script editing of /etc/php.ini on the previous
installation I think it will always make /etc/php.ini.rpmnew, and then
I think installation of the ancillary php packages (php-pgsql, et. al.)
will always edit /etc/php.ini, thereby leaving php.ini.rpmnew unedited (and
therefore broken).

One possible solution would be for the ancilliary php package scripts
to be modified to edit php.ini.rpmnew if it's present, otherwise php.ini.

Also, referring to the earlier comment, I thought it *was* general
Red Hat practice to restart daemons modified by an update (at least, by
an up2date).  In this case, that would be apache/httpd.  Given that some
people assume their system is being *automatically* kept up to date via
up2date, failing to restart dependent daemons leaves systems running
without the update until the next reboot.  That's a bad thing.
Comment 6 Phil Copeland 2002-08-31 03:10:11 EDT
Red Hat rpm policies 101

We do NOT overwrite existing config files, ever.
(or rather if we find people doing it we take them outside and shoot them)

We do NOT restart services from rpm spec files
(or rather if we find people doing it we take them outside and feed them to the
catapillers)

The php errata is within spec although the first errata slipped through QA with
a pile of requires: where they should have been buildrequires:

see #72007 for additional details

btw: I can see where you're going with the  'well if you arn't going to do
php.ini, at least do php.ini.new. I've queued that up for another errata

Phil
=--=

Note You need to log in before you can comment on or make changes to this bug.