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

[DirectAdmin Support]

Hello,

I'm currently working on adding support for suPhp and php5 to our build script, but figured it would be a good time to see if these changes should be default for the installer.

The question is, what php setup do you want to have for the default installs: php4, php5, php4+suPhp, php5+suPhp?

Note that suPhp will require 2 full php compiles at install time as DA and plugins require the non-cgi version of php.. (the suPhp binary will be compiled to it's own path)

I would like to move to php 5 anyway, as php 4 is getting old, so any feedback if you might see any issues with scripts that don't work on php 5, or things like that.

Dovecot will likely also be integrated into the default install (compiled) and vm-pop3d/imapd dropped.

John

[The_cobra666]

I would prefer plain PHP 5 and dovecot.

I don't know the advantage of suPhp so.

Greetings

[DirectAdmin Support]

The advantage of suPhp is that the php processes are run as the user instead of as "apache". This means that the security on the box will be greatly increased. Also, suPhp has a chroot option, so everything on the box can be chrooted finally. But, suPhp requires php to be run in cgi mode, which doesn't have the same perforance as the compiled-in version (without suPhp).

John

[roelp]

plain php5 + the option to install suphp :cool:

[hehachris]

how about php4 + (php5+SuPHP) ?

[directuser]

How about apache 2.2 by default in new build script? And removing mod_frontpage.

[ozcorp]

Prefer php5 plain with the option of suPHP.

[koh]

I would vote on php5+ suphp, if possible like the guy above apache to 2.20

[Chrysalis]

I will be quite upset if you start having an option that is low compatability as default, for instance having php5 and suphp as default you can expect more support tickets complaining of apps not working.

I voted for plain php4 but why not have a choice on install, does it have to be fixed to one version? likewise with mysql there should be a choice on that between 4.1 and 5.x.

[DirectAdmin Support]

An install option wouldn't be too difficult to add. It might be good to have one global type file (like the directadmin.conf) that knows what version of what is on the system, then the build script "knows", so the simple "./build all d" will make exactly what you currently have on your system, a bit more work on my end, but the time savings for everyone would likely be worth it.

John

[redeye]

I voted php5 and suphp as option for some clients needed ;)


Apache 2.2 is welcome aswell, mod_security and mod_evasive would be handy for some as option allthough it's easy to setup.

[Pascal]

Why not running apache under the username? Then you don't have PHP in CGI mode...

I vote only for PHP5

[Chrysalis]

Originally posted by DirectAdmin Support
An install option wouldn't be too difficult to add. It might be good to have one global type file (like the directadmin.conf) that knows what version of what is on the system, then the build script "knows", so the simple "./build all d" will make exactly what you currently have on your system, a bit more work on my end, but the time savings for everyone would likely be worth it.

John

thats great thanks, if you pull that off it would be very good.

[DamnSkippy]

I would like the options available but like Chrysalis I do not want to have suphp as default because of script issues.

If you could put it together so that it would have the options that would be great. It would be even better if we could edit one conf file and recompile and have a different setup and even better still if it could be set on a per account (maybe even domain) basis. :)

[DirectAdmin Support]

The discussion doesn't seem to be matching the poll results, but either way, here's where I'm leaning.

1) Setup.sh will ask you a few questions as to what you want:
- apache 1 or 2
- php 4 or 5
- suPhp or not

should be a command line version available as well.. will be backwards compatible, so the current command line setup.sh will install just same stuff (1.3, 4, no suphp)

2) all that data will be saved into a file in the customapache directory. "./build all" will read it and compile the right stuff.. so that you can just do the update, clean, all commands to get updated with whatever you have.

3) you'll get dovecot, no options ;)

So, let me know your thoughts, if we like that or not.

John

[empowering]

keeping php4 is important for customers who still need it.

I vote for suphp (default) that installed php4 and php5. You can have both with suphp.

With the option for mod_php4, mod_php5 if needed.

On our dedicated servers I don't care if they use mod_php but on shared suphp is the way to go.

[DirectAdmin Support]

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

[GranTW]

Also I would to see maybe the peruser apache ( http://directadmin.com/forum/showthread.php?s=&threadid=12794 ) thing as an beta option ( like dovecot now ) obviously once what you have outlined above is done.

This would allow another method of securing the system further like suPHP does and also allow install/setup code to be in place for when peruser becomes better developed and "stable".

Thanks,
Grant

[empowering]

Originally posted by DirectAdmin Support
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

In reality very few are incompatible. Most comes down to either minor script variable changes OR changing .htacess php_value entries to php.ini entries.

[DamnSkippy]

I think the system you outlined above sounds pretty good John. It gives people options and lets you change later if you need to.

[jmstacey]

I accidentally voted for Php 5 and suPhp, I'd prefer just plain PHP5 with suphp as an option, such as zend is.

Although customapache may be more convenient for DirectAdmin I'd prefer everything to go through the OS distribution's package system. Efficiency tends to improve when you don't have to worry about any loose programs.

[Chrysalis]

Originally posted by DirectAdmin Support
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

On a shared server its probable that at least one person will have something that wont work with suphp, problems are common which is probably why not everyone out there is using suphp, please dont make this a default.

I think the reason why the poll is different to the discussion is because people are voting assuming newer is always better and suphp is all singing and dancing addon that will solve all their security problems.

[Chrysalis]

Originally posted by DirectAdmin Support
The discussion doesn't seem to be matching the poll results, but either way, here's where I'm leaning.

1) Setup.sh will ask you a few questions as to what you want:
- apache 1 or 2
- php 4 or 5
- suPhp or not

should be a command line version available as well.. will be backwards compatible, so the current command line setup.sh will install just same stuff (1.3, 4, no suphp)

2) all that data will be saved into a file in the customapache directory. "./build all" will read it and compile the right stuff.. so that you can just do the update, clean, all commands to get updated with whatever you have.

3) you'll get dovecot, no options ;)

So, let me know your thoughts, if we like that or not.

John

Sounds good to me, if dovecot is a no choice will it still be possible to import old email data from pre dovecot? example, you move form a older DA server which hasnt got dovecot on and install DA on the new server, restore the backups which of course are not right format for dovecot. What would happen then?

[empowering]

What problems??

Can someone be specific with what problems they have with suphp? Any "problems" we've had are simple fixes/workarounds.

[Chrysalis]

Originally posted by jmstacey
I accidentally voted for Php 5 and suPhp, I'd prefer just plain PHP5 with suphp as an option, such as zend is.

Although customapache may be more convenient for DirectAdmin I'd prefer everything to go through the OS distribution's package system. Efficiency tends to improve when you don't have to worry about any loose programs.

customapache is one thing I like since even on none DA servers I compile php and apache from src, not keen on using them from within ports.

[Chrysalis]

Originally posted by empowering
What problems??

Can someone be specific with what problems they have with suphp? Any "problems" we've had are simple fixes/workarounds.

may be simple fixes workarounds to you, but if suddenly 20 users have broken websites it builds up. Choice is king how can choosing suphp be worse then having to install it?

[empowering]

Originally posted by Chrysalis
customapache is one thing I like since even on none DA servers I compile php and apache from src, not keen on using them from within ports.

for rpms distros keeping them as rpms is best. Not the distro's rpms but DA rpms would be best.

When you have 20+ servers to manage customapache complies sucks.

[empowering]

Originally posted by Chrysalis
may be simple fixes workarounds to you, but if suddenly 20 users have broken websites it builds up. Choice is king how can choosing suphp be worse then having to install it?

Ok so the issue is not the issues per say but getting around to resolving the things suphp does break?

[Chrysalis]

Originally posted by empowering
Ok so the issue is not the issues per say but getting around to resolving the things suphp does break?

well the issues are the problem also since it upsets users, the issues are an issue to users and fixing them is an issue for me.

[Chrysalis]

Originally posted by empowering
for rpms distros keeping them as rpms is best. Not the distro's rpms but DA rpms would be best.

When you have 20+ servers to manage customapache complies sucks.

personally I am not a fan of precompiled binaries I always like to compile, it takes longer but you dont have to sit there watching it.

[justahost]

The whole shebang I say - I have seen problems with scripts when swapping to PHP5, so if people have options of 4 or 5 they would be happy - I like the security side of suPHP

[DamnSkippy]

Hey John, is it even possible to be able to select the version of php, apache on a per account or per domain basis? It sounds like a great thing but I am not even sure it is possible.

Plus having different versions running on the server sounds a bit like a nightmare to me.

[jmstacey]

It's not the compiling that bugs me, it's the disorganized management. Instead of having all currently installed versions vs. available versions for the entire server on one screen you've got to keep track seperately.

Who said anything about ports? Use dpkg :P

[schristm]

John,

I think that mod_php4, mod_php5, suphp + php4, suphp + php5, etc. should all be options of the customapache build script. I don't really have a preference for the default install. I think that it's probably safe to leave the default install the way it currently works and allow people to rebuild using customapache if they want to enable php5 or suphp.

I, personally, would prefer to have php4 and php5 compiled as CGI's and wrap them both with suphp so that by default, .php files use the php4 suphp binary, and .php5 scripts use the php5 suphp binary. I'm sure others would prefer things completely different. In this case I believe the best thing you can do is just provide the flexibility to have it however you want it without forcing any changes on anyone by default. An ideal solution, in my opinion, is simply an easy-to-use customapache build script to help to automate the installation of suphp and php 4/5.

Thanks!

[jbw]

Originally posted by DirectAdmin Support
The discussion doesn't seem to be matching the poll results, but either way, here's where I'm leaning.

1) Setup.sh will ask you a few questions as to what you want:
- apache 1 or 2
- php 4 or 5
- suPhp or not

should be a command line version available as well.. will be backwards compatible, so the current command line setup.sh will install just same stuff (1.3, 4, no suphp)

2) all that data will be saved into a file in the customapache directory. "./build all" will read it and compile the right stuff.. so that you can just do the update, clean, all commands to get updated with whatever you have.

3) you'll get dovecot, no options ;)

So, let me know your thoughts, if we like that or not.

John

Dovecot should have option of mbox or Maildir format.

[DirectAdmin Support]

our setup of dovecot only works with Maildir. We haven't setup any mbox options for it.

John

[ccto]

We have running Dovecot (since its beta 3) plus suPHP 0.5 + PHP 4.3.11, it is working fine for a few months already.

If possible, it would be great if it can compile both PHP 4 and 5 in CGI and CLI mode,
CGI mode is for user http/php program, CLI mode is for DA execution.
and then let the end-user choose which PHP version to run in DA control panel. Then, it would be best.

I have seen this feature in Netfirms, their panel can allow end-user to choose which php to execute.

[Chrysalis]

ccto idea I would accept php4+5 with 5 been available for .php5 extension but with suphp optional.

[Maniak]

I gave my vote to Php 4 + ( Php 5 + suPhp )

Simply because PHP can't be discontinued because of a lot of scripts and PHP5 as to to be able for people who wants to use it.

It's a great feature.

Originally posted by Chrysalis
ccto idea I would accept php4+5 with 5 been available for .php5 extension but with suphp optional.

I don't believe that it's possible to run both PHP without suPHP using only one version of apache, and the same port ;-)

Originally posted by DirectAdmin Support


1) Setup.sh will ask you a few questions as to what you want:
- apache 1 or 2
- php 4 or 5
- suPhp or not


And why not the complete list like :

Apache 1 + PHP 4
Apache 1 + PHP 5
Apache 1 + PHP 4 + PHP5 + suPHP

Apache 2 + PHP 4
Apache 2 + PHP 5
Apache 2 + PHP 4 + PHP5 + suPHP

and one bolded "recommanded" ?

[empowering]

Originally posted by Maniak
I don't believe that it's possible to run both PHP without suPHP using only one version of apache, and the same port ;-)


Nope is possible. Do it now.

http://www.pookey.co.uk/wiki/php/suphp_mod_php

[Maniak]

Originally posted by empowering
Nope is possible. Do it now.

http://www.pookey.co.uk/wiki/php/suphp_mod_php

Yes, I know that we can do it so, I wrote it in my HOW TO (http://www.directadmin.com/forum/showthread.php?s=&threadid=13953) but, it requires DA to handle it...

Then why not to propose an option for reseller/admin at account creation time about which PHP we wants to use for him?

So many possibilites...

[Maniak]

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...).

[wdv]

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.

[empowering]

Originally posted by wdv
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.

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.

[empowering]

Originally posted by Maniak

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]

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.

[wdv]

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.

[empowering]

Originally posted by wdv
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.

That is another option but may not be viable depending upon the scripts customers want to use.

[wdv]

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

[IT_Architect]

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?/archives/54-Do-the-New-Features-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.

[Chrysalis]

Originally posted by empowering
That is another option but may not be viable depending upon the scripts customers want to use.

I have found open_basedir and disable to be rarely intrusive.

suphp and safe mode both more intrusive.

[Chrysalis]

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.

[wdv]

Originally posted by Chrysalis
I have found open_basedir and disable to be rarely intrusive.

suphp and safe mode both more intrusive.

I have the same experience. Open_basedir+disable_functions is a really good option.

[geskorup]

Quoting http://www.squirrelmail.org/wiki/SquirrelMailRequirements ...

You need at least PHP 4.1.2. If you are using PHP 4.1.2 or 4.1.4, please upgrade to the latest version ( >= 4.1.2.11, >= 4.1.4.1 final). Current stable versions of SquirrelMail do not work with PHP5, but the CVS version contains fixes which get it working.

[Handyman]

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.

[IT_Architect]

geskorup: Current stable versions of SquirrelMail do not work with PHP5 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.

[resolveit]

Originally posted by DirectAdmin Support
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

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,

[Maniak]

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.

Originally posted by empowering
Nope is possible. Do it now.

http://www.pookey.co.uk/wiki/php/suphp_mod_php

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

[empowering]

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.

[jlasman]

The feature is built in to Linux/Unix.

Jeff

[Chrysalis]

Originally posted by empowering
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.

Thats a very good idea.

[Maniak]

Originally posted by empowering
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.

Hello,

Just wanted to inform you, that no, it does not break that. I made few tests following my own how-to.

But yeah, your idea kicks !

[empowering]

Originally posted by Maniak
Hello,

Just wanted to inform you, that no, it does not break that. I made few tests following my own how-to.

But yeah, your idea kicks !

Ok fill me in... how do you not break this?

[Maniak]

Hello,

have a look here, suPHP HOWTO (http://www.directadmin.com/forum/showthread.php?s=&threadid=13953).

Once it's done, it still works.

[Icheb]

John,

Do you have any idea when these changes are going to be available?
I'd like all our new servers with some of these options, but if it's going to be available soon, I'm willing to wait with installing DA on at least one new server ;).

Furthermore to make this post not entirely useless:


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 understand that changing the ~user feature will be something some of you want. However, I don't know how your DNS system works but, for my company, I really don't want to have to create *.<serverid>.sebsoft.nl A name DNS records in our DNS system.
Personally I like the <ip>/~user feature, but have removed it from the welcome mail, due to abuse in the past, like <anotherdomain on the server>/~newuser/ which was possible with one of the early versions of DA.


I also think that it would be a very good idea to have the open_basedir as a domain creation option, but we do have to think about complexity here. DA has always been a system that's powerfull, but doesn't have all the buttons a control panel like cPanel does. I wouldn't want to do that to our customers ;).
Furthermore I tend to agree with Maniak. It would be nice to be able to change those options, however, I don't think it will be possible in the near future, due to the amount of changes that have to be done directly to DA. I've got no idea on how complex it is, but aren't we heading to a kind of cPanel package if you introduce all these choices on user creation, and not on server setup ?

[DirectAdmin Support]

Hello,

It will likely be at least a few months off, we're still going all of the input to decide exactly what we're going to do.

If we added open_basedir as an option, it would likely be something like the safemode option.. only crontrolled by admin (security is something the Admin's worry about, not Resellers), hence it wouldn't be a package option, maintaining a decent level of cleanliness.

John

[keefe007]

My vote is for dovecot.

[Icheb]

Originally posted by DirectAdmin Support
Hello,

Hi John,


It will likely be at least a few months off, we're still going all of the input to decide exactly what we're going to do.

Ok, than I won't wait for this, for this server batch... ;).


If we added open_basedir as an option, it would likely be something like the safemode option.. only crontrolled by admin (security is something the Admin's worry about, not Resellers), hence it wouldn't be a package option, maintaining a decent level of cleanliness.

John

Great :).
Exactly what I wanted to know

[Wido]

Why suPHP?

Why not mod_ruid (http://websupport.sk/~stanojr/projects/mod_ruid/) and Apache 2?

[empowering]

Originally posted by Wido
Why suPHP?

Why not mod_ruid (http://websupport.sk/~stanojr/projects/mod_ruid/) and Apache 2?

Here is one good reason NOT to use apache2

http://www.directadmin.com/forum/showthread.php?s=&threadid=14237

[Wido]

Originally posted by empowering
Here is one good reason NOT to use apache2

http://www.directadmin.com/forum/showthread.php?s=&threadid=14237 Well, i run a Apache 2 server with more than 5000 VirtualHosts, runs without any troubles.

[empowering]

Originally posted by Wido
Well, i run a Apache 2 server with more than 5000 VirtualHosts, runs without any troubles.

With DA's setup for apache???

Then what did you do to modify your apache2 config to get around the file handles. The stock config with DA will not work.

[Wido]

Originally posted by empowering
With DA's setup for apache???

Then what did you do to modify your apache2 config to get around the file handles. The stock config with DA will not work. It is not a DA-server, it is a Apache 2 in a cluster i made.

I did not modify the source in any way.

I got the Apache through apt-get in Ubuntu.

[empowering]

Originally posted by Wido
It is not a DA-server, it is a Apache 2 in a cluster i made.

I did not modify the source in any way.

I got the Apache through apt-get in Ubuntu.

That's why then. DA has much more file handles per virtual site. Never will happen with a stock DA config.

[hehachris]

Maniak's idea is great, here is an idea based on Maniak's one and ccto's posts (page2)


Admin can choose to install PHP4 and/or PHP5 in CLI and/or CGI mode.

setup.sh
Which PHP4 mode to install?
[1] CLI (mod_php)
[2] CGI (suPHP)
[3] Both
[4] no PHP4, thanks

Which PHP5 mode to install?
[1] CLI (mod_php)
[2] CGI (suPHP)
[3] Both
[4] no PHP5 , thanks


So there will be 16 opportunities (may be compel to install at least 1 option)


for example, i installed option 3 for both PHP 4 & 5. there will be 4 options for admin and user:

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


Admin:
- ability to set which php options are available for each domain/user


User:
- ability to choose which available php version to use


That could solve our worries and the security-vs-performance fight. why not to have more choices?

Admins concern about security, disable the mod_php options. but still able to enable if a trusted user requests.

users concern performance, allow them to choose which php version to use. No script compatibility issue occurs again.




Originally posted by Maniak
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)



Originally posted by ccto
If possible, it would be great if it can compile both PHP 4 and 5 in CGI and CLI mode,

and then let the end-user choose which PHP version to run in DA control panel. Then, it would be best.
[/B]

[pcoeman]

I like the question for new ways to make DA more atractive but I like it more that some basic thing as update a installation is a option. Now we see that update a installation is as playing with the lottery.

Originally posted by DirectAdmin Support
Hello,

I'm currently working on adding support for suPhp and php5 to our build script, but figured it would be a good time to see if these changes should be default for the installer.

The question is, what php setup do you want to have for the default installs: php4, php5, php4+suPhp, php5+suPhp?

Note that suPhp will require 2 full php compiles at install time as DA and plugins require the non-cgi version of php.. (the suPhp binary will be compiled to it's own path)

I would like to move to php 5 anyway, as php 4 is getting old, so any feedback if you might see any issues with scripts that don't work on php 5, or things like that.

Dovecot will likely also be integrated into the default install (compiled) and vm-pop3d/imapd dropped.

John

[Ryders]

Originally posted by hehachris
Admin can choose to install PHP4 and/or PHP5 in CLI and/or CGI mode.
[...]
So there will be 16 opportunities (may be compel to install at least 1 option)
[...]
Admin:
- ability to set which php options are available for each domain/user

User:
- ability to choose which available php version to use

Admins concern about security, disable the mod_php options. but still able to enable if a trusted user requests.

users concern performance, allow them to choose which php version to use. No script compatibility issue occurs again.

I entirely agree with this;

if you force php4 AND php5 to run, not everybody will be happy, security, performance, whatever,

php5 needs to get in at some point and so no way only php4 should run,

too many php4 scripts are still running, so php 4 cannot go.

The best is to have flexibility; hard to implement, but much better once done!

For instance I'd love my users to run phpX by default, and they can change that themselves to phpY, if I granted them the opportunity, like any other user option!

my 2 c!

[intercybernet]

plain php4 + the option to install suphp

[Maniak]

Hi all,

I am sorry to ask this question, but, I do not understand why nobody wants suPHP by default.

Here my reason why to use suPHP.

- As far as I saw online, suPHP is not working slower than PHP working on mod_php.

- suPHP is more secure than mod_php, just see what has hapended with this (http://www.directadmin.com/forum/showthread.php?s=&threadid=14836) any suPHP haven't even seen a problem like this.

- there is some script not working well with suPHP, I am still waiting for a list. Most of the scripts that had problems, has also offered a solution. I heard about some caddy system. Feedbacks are welcome.

- Not needed to recompile all each time you upgrade MySQL for example, as some people say for when you update some libraries in PHP.

- Possibility to set a good security policy on any system with the php.ini file per user.

- Possibility to allow some functions for a trusted user since you can customize php.ini files.

- You can use libraries, accelerators, and more.

- You can follow who run which script.

- You don't have to chown files in galleries scripts for your users because he cannot delete them (because owned by apache).

- Ability to offer PHP4 and PHP5 on the same servers.

Please send here which softwares does not work with suPHP, we will maybe find a solution for.

[vandal]

I would prefer php4 by default and the .htaccess method for using php5. (users would create an .htaccess file in their dir to tell apache to parse php files under the php5 processor).

But of course the best option would be to adjust the build script to do whichever way the admin prefers.

[Daredevil]

Any news on how far the development on idea's posted here is?

[DirectAdmin Support]

Hello,

Current order of projects:

1) admin level backup (reseller backup in the admin section for all users, and easy server-to-server transfers of everything)

2) build script with dovecot

3) build script with php5, suPhp, apache 2 as install time options.

John

[Chrysalis]

I like option 1 alot, I assume it comes with admin restore?

[DirectAdmin Support]

Yup. That's the intention. I'm also going to try and add a simple 1 click server transfer in there (not sure yet).

John

[jlasman]

Hooray!

:)

Jeff

[albatroz]

Amazing!

[netswitch]

damn it, I am just migrating servers with the old and painfull method right now :D


good news for the future tough

[eger]

I just wanted to say that these are the 3 biggest options for me to start using DA in place of cPanel. suPHP, backups, apache 2.x, and php 4 OR 5.

I am glad to see these 3 options being worked on. Keep up the good work. I am amazed at how much better this control panel is compared to cPanel and not sure why I didn't find this earlier. The control panel loads as fast as static HTML pages!

[jjma]

Admin restore fantastic...

Jon

[PauGasol]

Originally posted by DirectAdmin Support
Hello,

Current order of projects:

1) admin level backup (reseller backup in the admin section for all users, and easy server-to-server transfers of everything)

2) build script with dovecot

3) build script with php5, suPhp, apache 2 as install time options.

John

4) Full translation , plz dont forget the nonenglish customers.

Thanks

[olivier]

4) Full translation , plz dont forget the nonenglish customers.

+1 customer can choice the langage

[vincenzobar]

is there an ETA on no. 3

We are in dire need of the suPHP+PHP4+PHP5 and a Subversion plugin. All with easy user controls

[DirectAdmin Support]

still working on #1. No ETA at this time. This upcoming release will likely only have the backup portion of the admin level backups. The restore... knowing which IPs to assign to who, and why, will take more thought. I might just add a "pick you own IP" restore (similar to reseller restore), using the master IP list... it just causes problems for things like... if it's not yet assigned to a Reseller, it can't yet be shared, thus admin's have to setup all the IP's ahead of time, before restoring users...etc..

John

[jjma]

I would be happy with that solution if it means a full admin restore feature can be released now.

Jon

[Chrysalis]

probably better to have it make you choose ips like the reseller restore I think. :)

[DirectAdmin Support]

we also get into the question.. if the reseller has 5 IPs on the old system.. 4 are unused and free.. will DA give it to them, or will the admin do it. That kind of kills the 1 click transfer idea.

John

[jjma]

If the ips are free, allocate them to the admin. He can always free them at a later date for a reseller.

The main concern for the admin is getting the system retored as fast as possible, as easy as possible.

regards

Jon

[Maniak]

Hello,

with suPHP 0.6.2 it is now possible to run all apache version with PHP4 and PHP5.

As soon as PHP6 is officially released, it will be possible to include it with only 3 lines in all configuration files.

PHP6 must not be like PHP5, included only over 2 years after it is released...

Moreover, it is possible to make tighter security rules based on individual virtualhost.

It is also possible to allocate more or less freedom and ressource to a special user with per-user php.ini customization.

Please this time don't miss the train, and take advantage from the competition :D

[xemaps]

I like apache 1.3.37 with php 4.4.4 and stability DA/centos 4.4 and exim.
So i need nothing more than today for this case.
I don't want to spend time to debug or whatelse.
Propose all other options as supplement can be a good idea, but stay with stable default.

And before proposing option there is lot of work to have an excellent panel, just look at FeedBack & Feature Requests.

[TheBear]

Hello,

This thread seems to have died out. I wonder when the mentioned changes will be implemented? I moved my DA server to a new box not too long about (about 2 months) and none of the mentioned options were there in the install.

I suspect most of you are more knowledgeable than I on issues between php4 and phph5. Currently I am the only person on this server using any php - and that is on very simple pages for includes and such only.

That said, there is a php based helpdesk that I am interested in that requires php5 so I would like to see php5 available as at least an option at install time (as well as a built in way to upgrade to php5 on an existing install).

Thanks!

Dale

(hmm... seems the thread hadn't died out - for some reason I didn't initially see any posts past July of 2006)

[DirectAdmin Support]

For a vanilla php 5 install, you can use this:
http://help.directadmin.com/item.php?id=135

The above mentioned features will come in time, right now were trying to finish up the administrator backup system.

John

[jlasman]

Originally posted by TheBear
That said, there is a php based helpdesk that I am interested in that requires php5
I'm interested in the same helpdesk :) .

But that doesn't mean I'm interested in forcing all my clients to switch to PHP 5.

Which is what will happen, because you get your choice:

PHP4

PHP5

PHP5 running in PHP4 compatibility mode (in which case the helpdesk won't run, and other PHP programs requiring PHP5 probably won't run either)

PHP5 running as module, PHP4 running as CGI (which will require all users who require PHP4 to make a lot of changes)

PHP4 running as module, PHP5 running as CGI (which will mean the helpdesk won't run, and other PHP programs requiring PHP5 probably won't run either, at least not in default installations)

I think our next server will offer PHP5/Apache 2, but we just put one in and that's going to be a while before we put in another.

I'm thinking of putting a server into our office to run PHP5/Apache 2 now, in the meantime. We have static IPs and a fast enough connection to use just for helpdesk/billing.

And I don't have to use an expensive 1U server.

Jeff

[Senad]

Do tell what helpdesk this might be? I'm curious now :).

[eger]

I'm just taking a guess here that it might be http://auraclesupport.com/. It has a growing popularity and also requires php 5.

[jlasman]

That's the one I'm thinking of. Their new billing system (out soon) also requires PHP5.

The same people who wrote whois.cart.

Jeff

[Senad]

Originally posted by jlasman
That's the one I'm thinking of. Their new billing system (out soon) also requires PHP5.

The same people who wrote whois.cart.

Jeff

So a new version of whois.cart?

[Senad]

Also for that helpdesk. It DOES seem to work with PHP4 + PHP5 setup under suPHP (http://www.directadmin.com/forum/showthread.php?threadid=13953)

[jlasman]

Originally posted by Senad
So a new version of whois.cart?
No, a completely separate product.
Also for that helpdesk. It DOES seem to work with PHP4 + PHP5 setup under suPHP
Thanks for that info.

Jeff

[jlasman]

Replying again after reading that thread.

I still want php4 as standard builtin to apache.

I'd also like suPHP php5.

Is there an easy How-To somewhere on how to add that? If there is I'll try it on a testbed.

Jeff

[Senad]

Yeah I'm looking for this as well (or even PHP5 as apache and 4 as suphp). I'm willing to be the testing duck if necessary.

[wylde]

This addition would be excellent Auracle looks prefect

[TheBear]

Originally posted by eger
I'm just taking a guess here that it might be http://auraclesupport.com/. It has a growing popularity and also requires php 5.

Hello,

yep, that is the one.

Unrelated, but funny thing, I only today got an email that there had been updates to this thread!

Also waiting on the new product that is replacing whois.cart, especially since I have owned modernbill for over 2 years and have yet to be able to setup a single customer in it. And their support (modernbill that is) sucks royally!

[jjma]

There is 'lite' version to try which is free. I might try this.

Jon

[freshmint]

Dovecot sounds good.

I think I'd go for php4 default plus php5 and suPHP optional. I'm concerned about the high loads suPHP might bring after I read this thread.

[pluk]

Dovecot means good. Php 5 is fine by me. no idea about suPHP

[Senad]

AuracleSupport is pretty nice but after having tried both kayako and auracle I must admit my preference is with kayako even though I dread that they don't support mac osx for the insta-alert.

[klaver]

Most DirectAdmin customers are running a shared webserver for their customers and have little control what kind of crappy insecure scripts their customers upload to the server.

When possible, you should protect your systems against possible abuse, that would reduce the risk for being blacklisted or getting your business a bad name ;)

Therefore I would stronly suggest the use of suPHP, the latest version 0.6.2 is not noticable slower using PHP version 5.2.0 than a plain php 5.2.0

I would also suggest the use of the PHP hardened patch, that adds some extra protection and logging options to PHP without affecting functionality. More information:
http://www.hardened-php.net/hphp/index.html (http://www.hardened-php.net/suhosin/index.html)
(Do not use the Suhosin patch on the same website, that WILL break some php applications like Gallery and phpBB :mad: )

If DirectAdmin would like to be a modern admin panel, you should choose PHP version 5.2.0 and Apache 2.2 with an option to add PHP version 4 support via CGI. I hope the majority of all other webhosting companies using DirectAdmin agrees with me, but you cannot satisfy everybody's wish for a set of configuration options. (And I think DirectAdmin support desk would get crazy if they have to support 16 or more different configuration sets :( ).


With kind regards,

Michiel Klaver
GrafiX Internet B.V.

Stationsplein 20
2907 MJ Capelle a/d IJssel
The Netherlands

- In-house Internet datacenter facility in Capelle a/d IJssel, Holland -

[jlasman]

AuracleSupport is pretty nice but after having tried both kayako and auracle I must admit my preference is with kayako even though I dread that they don't support mac osx for the insta-alert.
Have you looked at the eTicket (http://eticket.sourceforge.net/) open source solution?

Jeff

[Chrysalis]

Most DirectAdmin customers are running a shared webserver for their customers and have little control what kind of crappy insecure scripts their customers upload to the server.

When possible, you should protect your systems against possible abuse, that would reduce the risk for being blacklisted or getting your business a bad name ;)

Therefore I would stronly suggest the use of suPHP, the latest version 0.6.2 is not noticable slower using PHP version 5.2.0 than a plain php 5.2.0

I would also suggest the use of the PHP hardened patch, that adds some extra protection and logging options to PHP without affecting functionality. More information:
http://www.hardened-php.net/hphp/index.html (http://www.hardened-php.net/suhosin/index.html)
(Do not use the Suhosin patch on the same website, that WILL break some php applications like Gallery and phpBB :mad: )

If DirectAdmin would like to be a modern admin panel, you should choose PHP version 5.2.0 and Apache 2.2 with an option to add PHP version 4 support via CGI. I hope the majority of all other webhosting companies using DirectAdmin agrees with me, but you cannot satisfy everybody's wish for a set of configuration options. (And I think DirectAdmin support desk would get crazy if they have to support 16 or more different configuration sets :( ).


With kind regards,

Michiel Klaver
GrafiX Internet B.V.

Stationsplein 20
2907 MJ Capelle a/d IJssel
The Netherlands

- In-house Internet datacenter facility in Capelle a/d IJssel, Holland -

I have implemented the other way php 4 dso module and a php 5 cgi using suphp.

Php5 may be the all new singing and dancing version but very few people are requesting it and the number of people using old script still exceeds people requiring php5 for new code.

apache 2.2 defenitly isnt as stable as 1.3 yet either, 1.3 just works under heavy workloads whilst I have witnessed 2.2 lock up a few times.

[neorder]

So what is the conclude and when will it be released? i don't care if it's php4 as cgi, php 5 as module, or the other way round. but i do need both php.

[smtalk]

neorder, we are working on it, but no release date set. There will be some chooses what and how to install.

[Chrysalis]

check the suphp how to in the guides section that is workable, I have it setup so php4 is a module and works completely normal and php5 as cgi. It is possible with htaccess files as well to make .php use php5.

[smtalk]

This thread is like a dead now, why? :) Keep posting... You suggestions are really useful.

[Paulius]

I'd really really love PHP5 with suPHP!

[agnivo007]

Is this possible ?

Php 5 cli + ( Php 4 cgi-fcgi + suPhp )

[smtalk]

agnivo007, yes it's possible and very easy to do.

[mattb]

Okay this has been talked about for a while... :p

So where are we at? :confused:

I think with the current GoPHP5 campaign (http://www.gophp5.org/) -- DirectAdmin should also assist and commit to dropping php4.

The majority known and supported apps are committed to going to php5. It's the old/unsupported apps that are likely to get left with php4. That in itself is enough of a security risk that the apps also die a cruel death.

Sure run php4 for the next 6 months.. .but it's needing to die so developers of PHP4 can bury the thing.

Let's help 'em along the way! :D

[hostpc.com]

I definately agree with mattb

[DirectAdmin Support]

Hello,

We've got a new build script here, which installs apache 2.2 and php5 by default. We're working on adding install time options in the setup.sh to give admins the option of installing it. Right now you already can by simply typing:touch /root/.custombuildprior to running the setup.sh, and the installer will find it and take care of the rest.

Upgrade guides for existing servers is here:
http://files.directadmin.com/services/custombuild/beta
http://www.directadmin.com/forum/forumdisplay.php?f=61

John

[Biken]

My small sugestion

Php Safe Mode Settings
Enable Open BaseDir also with - Default for new domains on off

[robj]

It is my understanding that php5 has nearly full support of all php4 functionality.

Riddle me this.

Why keep php4 installed, when php5 is quicker, better functionality, and more stable, and with php6 quickly approaching?

-rob

[eger]

Why keep php4 installed, when php5 is quicker, better functionality, and more stable, and with php6 quickly approaching?


While php5 does have all the capabilities of php4, in the beginning there were incompatibilities and caveats which caused php5 not able to just drop in place of php4 and keep everything running.

This may not be so much the case anymore. Though I still hear all the time about hosts going from php4 to 5 and many users scripts breaking in the process. Usually only needing small tweaks if any... But none the less not 100% backwards compatible IMHO

[Chrysalis]

It depends on circumstances but if one has customers needing php4 which they cant afford to lose then that is a reason to keep php4. I dont see any harm in a configuration that has both php5 and php4.