• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

php.ini

freaky@

Regular Pleskian
Anyone know where to find the php.ini? I mean... phpinfo(); says:

Configuration File (php.ini) Path /etc
Scan this dir for additional .ini files /etc/php.d
additional .ini files parsed /etc/php.d/dom.ini, /etc/php.d/gd.ini, /etc/php.d/imap.ini, /etc/php.d/ioncube-loader.ini, /etc/php.d/mbstring.ini, /etc/php.d/mysql.ini, /etc/php.d/mysqli.ini, /etc/php.d/xsl.ini

Ok... so we edit /etc/php.ini and set sendmail_path to what it should be (/var/qmail/bin/sendmail, instead of /usr/sbin/sendmail which is a symlink, pointing to something that doesn't exist...)

reload httpd, err no wait restart httpd, err reboot entire server.

sendmail_path still is /usr/sbin/sendmail. Nothing under /etc/php.d contains anything with sendmail in it and I'm going slightly insane by now.

There _should_ be no other config files. I can't seem to find them anyways. Customers however are unable to send mail through PHP as the sendmail path isn't correct.

Anyone know where to solve it? This is on fedora core 4 btw and something tells me it's in the package or something. I remember having issues with php.ini not picking up changes before, don't remember what the solution was tho'. It isn't really workable to override the php settings in /var/www/vhosts/*/conf/vhost.conf for each domain...
 
The default /usr/sbin/sendmail should work just fine. On our systems it's a symlink to /etc/alternatives/mta, which in turn is a symlink to /var/qmail/bin/sendmail.

Also, in /etc/php.ini this default should be fine:

Code:
sendmail_path = /usr/sbin/sendmail -t -i

Never had to change this on any server.
 
Yea sendmail was a link to mta here too, only mta didn't exist.

The problem wasn't only that tho'. Appearantly there was something wrong with the php.ini. In phpinfo() it said the main config file was located in /etc (note it did NOT say /etc/php.ini).

I trashed the php.ini and recreated a new one with only sendmail_path in it. Then it worked. So copied back the old php.ini and removed all comment lines and such. There must have been an error in the parsing of comments or something else (afaik I only removed comment lines). That solved it. It also says /etc/php.ini for the main config now... strange...

Next to those, selinux was a problem as well. Had to disable it (still figuring out how to allow apache access to the qmail executable) and now all is fine.

So symlink was broken, php.ini was screwed and selinux was blocking stuff. Very nice combo :D. One wonders tho', why the installer of plesk didn't solve most of these issues.

We never changed /etc/php.ini before, it must have been screwed up by the distribution (fedora core 4) or probably the plesk installer (selinux issues?? :D).
Plesk installed qmail judging by the package name (it has psa in there) which makes me wonder why they didn't warn/modify selinux and broke the symlink.

Anyways thanks for the re.
 
Plesk install instructions explicitly tell you to disable SELinux before installing Plesk. You should be able to turn it back on afterwards.
 
Now that you mention it, we did disable it during the install if I remember correctly. Otherwise the install couldn't complete IIRC.
 
Why don't you just put the sendmail binaries where the php.ini thinks they should be? If it's giving you so much trouble, that sounds easier to me.
 
SELinux is the bad guy here, or actually, the Plesk installer is. Upon installation, it modifies your php.ini and sets its security context type to 'tmp_t'.

A simple '/usr/bin/chcon -t etc_t /etc/php.ini' should do the trick.

Don't forget to restart your Apache.
 
close

seems a solution is on the horizon?

selinux - permissive or disabled?
php.ini - needs modified?
then etc/alternatives/mta this thing

this seems a very active problem. quite a few posts... my forms still aren't sending past my server...
 
Oh, please also note something was screwed up as the php.ini appearantly wasn't parsed. I copied it, removed it all comment lines, and then copied it back to the original location (overwrote /etc/php.ini).

I posted this before, I think it also was that phpinfo() gave /etc as configuration path. After I modified the config (stripped comments and such) it all of a sudden gave /etc/php.ini as config path. This probably explain why earlier tries from me to change the sendmail_path didn't succeed (as appearantly php screwed up parsing the config file or something, no errors that I found tho').
 
Not good.

First of all, you disabled selinux, so of course Apache now sees the php.ini. With selinux enabled, Apache will only see files within a specific security context.

Second, because of disabling selinux, you throw away a lot of useful security measures for your server. Assuming you are going to use this in a production environment, you would benefit greatly from these selinux policies. Now, it's as if you're just chmod'ing your entire filesystem to 777 so you will never have any file permission problems. But that's of course entirely up to you.

Please read my previous post on how to change the security type and let me know if it helps.
 
Sorry for the late re', been quite busy and holidays n such :)

Anyways I reenabled selinux. It worked straight away (using ls -Z appearantly because I move php.ini to php.ini.old and recreated php.ini which automatically assigned it etc_t instead of tmp_t).

So I'd like to report it works :) Thanks a bunch.

One more question tho'. We used to have trouble with open_basedir in PHP. Appearantly it considered all paths (say you included bla.inc) with / prefixed. So it made bla.inc look like /bla.inc and ofcourse / isn't in the open_basedir for obvious reasons. These issues seem gone now, albeit I have to do some more testing (not really sure where they turned up again and I'll have to modify some vhost.conf's to not turn open_basedir off).

The question ofcourse is if you know what might have solved it (it being able to read php.ini might help ofcourse but it might have been a plesk update)

Thanks again.
 
Back
Top