Poll for new default install options: php5/suPhp/dovecot

What php / suPhp setup do you want for the default install?

  • Plain Php 4

    Votes: 8 6.5%

  • Plain Php 5

    Votes: 19 15.4%

  • Php 4 and suPhp

    Votes: 9 7.3%

  • Php 5 and suPhp

    Votes: 32 26.0%

  • Php 4 + ( Php 5 + suPhp )

    Votes: 55 44.7%
  • Total voters
    123
  • Poll closed .
I would just make a little remark to everybody.

OVH which is nevertheless number one of hosting in France (http://www.webhosting.info/webhosts/tophosts/Country/FR) run on their servers PHP4 and PHP5 as CGI with suPHP. (http://60gp.ovh.net/test.php / http://60gp.ovh.net/test.php5).

In Switzerland, net4all which is number 4 thru their brand "Oxito" (http://www.webhosting.info/webhosts/tophosts/Country/CH) run as well php4/5 as CGI.

So which script does not work with suPHP, can someone make the list ?

I don't believe that suPHP is something bad, and the performance of PHP as CGI can be certainly not so bad, and even better with a cache system (eAccelerator etc...).
 
I am against suPHP. Sure, it has some nice security advantages. But it really has a serious impact on load. It's not that one site loads slower with suPHP, but you can put a lot less sites on one server with suPHP, A LOT. If you want sky-high loads, put a few sites on suPHP.
 
Last edited:
wdv said:
I am against suPHP. Sure, it has some nice security advantages. But it really has a serious impact on load. It's not that one site loads slower with suPHP, but you can put a lot less sites on one server with suPHP, A LOT. If you want sky-high loads, put a few sites on suPHP.
Click to expand...

On a shared server (dedicated customer is a different story) I wouldn't trust the users have kept their software updated. We manage over 3000 domains and php breakins is a weekly occurance. This is probally why the larger providers are starting and already changed to not use mod_php. Insecure php code these days is the #1 method hackers gain access to servers.

IMHO, while the load is higher it's not that bad for the better security.
 
Maniak said:
So which script does not work with suPHP, can someone make the list ?

I don't believe that suPHP is something bad, and the performance of PHP as CGI can be certainly not so bad, and even better with a cache system (eAccelerator etc...). [/B]
Click to expand...

As far as scripts outright not compatible. We haven't found one yet. We just did 1500 domain migration from other provider we purchased who use using mod_php. No issues that couldn't be solved.

The issue I believe with other admins are rasing is the change over to suphp is the issue. Not the fact it's used.

Performance of suphp is better than straight cgi but obviously not as good as mod_php. Since PHP SAFE mode is not safe, apache MPM is not yet an option for PHP, and the #1 method to break into a server is insecure PHP, what other options does a shared host have with PHP?

Use mod_PHP and stay insecure worring about any file that's apache owned can be read and worry about world writable folders. suPHP at least sandboxes the hacked account better.
 
Last edited:
I certainly do not deny the security advantages of mod_suphp, but my experience is that a good set of open_basedir and disable_functions does the trick too.
 
Last edited:
wdv said:
I certainly do not deny the security advantages of mod_suphp, but my experience is that a good set of open_basedir and disable_functions does the trick too.
Click to expand...

That is another option but may not be viable depending upon the scripts customers want to use.
 
Well, I think you'll agree with me that open_basedir is not a problem, since clients shouldn't stick there noses where they don't belong anyway. I can understand that some users want to use ImageMagick for example with exec(), this can be arranged by using a modification for PHP. See http://kyberdigi.cz/projects/execdir/english.html
 
Last edited:
I'm with Chrysalis on the choices on MySQL install. Currently, DA ships with MySQL 5. Its only advantages are under conditions probably never encountered in web apps. It is it slower an more resource intensive. http://www.jpipes.com/index.php?/ar...of-MySQL-5-Cause-Performance-Degradation.html

If we can't have a choice, then 4.1 is the fastest version that runs across all of your platforms well. If we can have a choice, make 4.1 the default.

You may have other reasons for using MySQL 5.x, but if we don't know what they are, we are stuck with upgrading from MySQL 5 to MySQL 4 on every install to avoid a 12% decrease in performance and throwing away resources.
 
empowering said:
That is another option but may not be viable depending upon the scripts customers want to use.
Click to expand...

I have found open_basedir and disable to be rarely intrusive.

suphp and safe mode both more intrusive.
 
Good post, I usually stick with 4.1 unless a developer requests it due to them needing features that mysql5 has brought to the table.
 
Chrysalis said:
I have found open_basedir and disable to be rarely intrusive.

suphp and safe mode both more intrusive.
Click to expand...

I have the same experience. Open_basedir+disable_functions is a really good option.
 
Last edited:
Please make this compatible with the Debian 3.1 system.

It takes an entire 3 minutes to get Debian running with php5, php4-cgi and mysql 5.

Which now that I'm running directadmin, they are still on my system but not being used... I had to comile a brand new php5 and suphp to get php5 back.
 
geskorup: Current stable versions of SquirrelMail do not work with PHP5
Click to expand...
That may be out-of-date information on their web site. That has been there since 1.46 was beta. Current stable for SquirrelMail is 1.47. I was concerned about that just like you. However, I gave it a try anyway because SquirrelMail was not worth losing out on the huge advantages of PHP 5.1. I've been running Nutsmail! 1.46, which is always behind SquirrelMail since it is based on it. It has been running on a server running PHP 5.1.2 for four months. I have two customers who use it, and for one it is their only access to email. They get a lot of mail every day and most of it with large CAD file attachments. I have had zero problems with stability on a MP server running under the extreame dynamic content load of the world's 6th largest weather site, and another very busy site used by many hotel chains to book rooms. I would think that if anyone could come up with a way to kill it, it would be us.<g> SquirrelMail/Nutsmail! has been the least of our worries.
 
Last edited:
DirectAdmin Support said:
I like the idea of having suPhp as default, but it was mentioned this might cause script problems.. can anyone elaborate on exactly why this would cause a problem? Some examples, etc..

If it's an install time option anyway, it doesn't matter.. there isn't really a "default" with choice.

John
Click to expand...

John,

It would be great to have this as a domain level option like Safe-Mode.
Also Open_basedir as a domain level option would be briliant.

Give the option to set these default on/off during install that would be a great help ;)

Regards,
 
I think, I have a pretty great solution for each people here. This solution should make everybody happy.

This my idea

When an user setup is server he get few possibilites.

At setup time

Option :

[1] - PHP4 (mod_php) only
[2] - PHP5 (mod_php) only
[3] - PHP4 (mod_php) / PHP5 (suPHP)
[4] - PHP4 (suPHP) / PHP5 (mod_php)
[5] - PHP4 (suPHP) / PHP5 (suPHP)

We can imagine to use it with a paramaters when we launch setup.sh.

If no paramaters has been set, it install default PHP4 ? ...

At user account creation time

Before to propose options, the system check which option can be used.

Then, why not to create an option called "php_type" {1|2|3|4|5} that would appear in the creation form in directadmin and API system ?

Option :

[1] - Offer PHP4 only
[2] - Offer PHP5 only
[3] - Offer PHP4 (mod_php) / PHP5 (suPHP)
[4] - Offer PHP4 (suPHP) / PHP5 (mod_php)
[5] - Offer PHP4 (suPHP) / PHP5 (suPHP)


HTTPD configuration files

Option 1 - httpd.conf
Normal virtualhost. All is unchanged.

Option 2 - httpd.conf
Normal virtualhost. All is unchanged.

Option 3 - httpd.conf
Normal virtualhost with this :

# Handle PHP5 with suPHP
AddHandler x-httpd-php5 .php5

# suPHP with PHP5
<Location />
suPHP_Engine on
suPHP_ConfigPath /usr/local/etc/php5/cgi/
suPHP_AddHandler x-httpd-php5
</Location>

Option 4 - httpd.conf
Normal virtualhost with this :

# Handle PHP4 with suPHP
AddHandler x-httpd-php .php

# suPHP with PHP4
<Location />
suPHP_Engine on
suPHP_ConfigPath /usr/local/etc/php4/cgi/
suPHP_AddHandler x-httpd-php4
</Location>

Option 5 - httpd.conf
All is changed.

# Handle PHP4+5 with suPHP
AddHandler x-httpd-php .php
AddHandler x-httpd-php5 .php5

# suPHP with PHP5
<Location />
suPHP_Engine on
suPHP_ConfigPath /usr/local/etc/php5/cgi/
suPHP_AddHandler x-httpd-php
suPHP_AddHandler x-httpd-php5
</Location>


----

I just would like to correct something.

empowering said:
Nope is possible. Do it now.

http://www.pookey.co.uk/wiki/php/suphp_mod_php
Click to expand...

You cannot run both PHP with mod_php. You can only run ONE php version with mod_php, the other one has to ne handled by mod_suphp.

---

Enjoy
 
Last edited:
suphp will break /~username setup

Just be aware that suphp WILL break the

http://ip/~username setup to access a site if suphp is setup to only run the php files as the user.group (which it should)

I personally would like to get rid of this feature since you can easly offer the same option by offering http://username.servername.com and have it map up to the specific <Virtual> setup and will run as the specific user.group.

I think it's a bad idea to even mention a specific IP address to a shared hosting customer who doesn't have a dedicated IP address.
 
Re: suphp will break /~username setup

empowering said:
Just be aware that suphp WILL break the

http://ip/~username setup to access a site if suphp is setup to only run the php files as the user.group (which it should)

I personally would like to get rid of this feature since you can easly offer the same option by offering http://username.servername.com and have it map up to the specific <Virtual> setup and will run as the specific user.group.

I think it's a bad idea to even mention a specific IP address to a shared hosting customer who doesn't have a dedicated IP address.
Click to expand...

Thats a very good idea.
 
You must log in or register to reply here.
Back
Top