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

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 !
 
Re: Re: suphp will break /~username setup

Maniak said:
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 !
Click to expand...

Ok fill me in... how do you not break this?
 
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.
Click to expand...
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 ?
 
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
 
DirectAdmin Support said:
Hello,
Click to expand...
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.
Click to expand...
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
Click to expand...

Great :).
Exactly what I wanted to know
 
Wido said:
Well, i run a Apache 2 server with more than 5000 VirtualHosts, runs without any troubles.
Click to expand...

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.
 
empowering said:
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.
Click to expand...
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.
 
Wido said:
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.
Click to expand...

That's why then. DA has much more file handles per virtual site. Never will happen with a stock DA config.
 
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.




Maniak said:
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)
Click to expand...


ccto said:
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]
Click to expand...
 
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.

DirectAdmin Support said:
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
Click to expand...
 
hehachris said:
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.
Click to expand...

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!
 
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 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.
 
Last edited:
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.
 
You must log in or register to reply here.
Back
Top