1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

php.ini

Discussion in 'Plesk for Linux - 8.x and Older' started by freaky@, May 14, 2007.

  1. freaky@

    freaky@ Regular Pleskian

    26
     
    Joined:
    May 2, 2006
    Messages:
    104
    Likes Received:
    0
    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...
     
  2. breun

    breun Golden Pleskian

    29
     
    Joined:
    Jun 28, 2005
    Messages:
    1,647
    Likes Received:
    0
    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.
     
  3. freaky@

    freaky@ Regular Pleskian

    26
     
    Joined:
    May 2, 2006
    Messages:
    104
    Likes Received:
    0
    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.
     
  4. breun

    breun Golden Pleskian

    29
     
    Joined:
    Jun 28, 2005
    Messages:
    1,647
    Likes Received:
    0
    Plesk install instructions explicitly tell you to disable SELinux before installing Plesk. You should be able to turn it back on afterwards.
     
  5. freaky@

    freaky@ Regular Pleskian

    26
     
    Joined:
    May 2, 2006
    Messages:
    104
    Likes Received:
    0
    Now that you mention it, we did disable it during the install if I remember correctly. Otherwise the install couldn't complete IIRC.
     
  6. nerbonne

    nerbonne Guest

    0
     
    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.
     
  7. breun

    breun Golden Pleskian

    29
     
    Joined:
    Jun 28, 2005
    Messages:
    1,647
    Likes Received:
    0
    The binary is where php.ini is pointing to. This is not the problem.
     
  8. jverbogt

    jverbogt Guest

    0
     
    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.
     
  9. TellUsMore

    TellUsMore Guest

    0
     
    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...
     
  10. freaky@

    freaky@ Regular Pleskian

    26
     
    Joined:
    May 2, 2006
    Messages:
    104
    Likes Received:
    0
    I disabled selinux and set the sendmail_path (php.ini) to /var/qmail/bin/qmail-inject

    That was it...
     
  11. freaky@

    freaky@ Regular Pleskian

    26
     
    Joined:
    May 2, 2006
    Messages:
    104
    Likes Received:
    0
    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').
     
  12. jverbogt

    jverbogt Guest

    0
     
    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.
     
  13. TellUsMore

    TellUsMore Guest

    0
     
  14. freaky@

    freaky@ Regular Pleskian

    26
     
    Joined:
    May 2, 2006
    Messages:
    104
    Likes Received:
    0
    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.
     
Loading...