Page 2 of 2 FirstFirst 12
Results 26 to 49 of 49
  1. #26
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    Yes, for sure. If you just have 10 websites, 8GB should be plenty.
    In most cases, mod_fcgid will run as fast as DSO.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  2. #27
    Join Date
    Sep 2008
    Location
    NL,IR
    Posts
    1,491
    is there any technical issue on server which handle with fastcgi - suphp ?
    because i havent test fast cgi yet and still searching for review

    suphp + nginxcp is the most configuration i have work on servers

  3. #28
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    fast cgi cannot read parameters from .htaccess files for PHP. suPHP can.
    Otherwise -- it would map one to one without any issues.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  4. #29
    Join Date
    Sep 2004
    Location
    Aveiro - PORTUGAL
    Posts
    68
    Quote Originally Posted by iseletsk View Post
    fast cgi cannot read parameters from .htaccess files for PHP. suPHP can.
    Otherwise -- it would map one to one without any issues.
    SUPHP can read Apache directives from .htaccess files, but PHP configuration must be placed in php.ini files. If you put PHP configuration on .htaccess files, suPHP will generate error 500.

    by default FASTCGI not read php.ini files - need some trick to read users php.ini files (like this: http://forums.cpanel.net/f5/individu...gi-160398.html)
    Alvaro

  5. #30
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    suPHP can read PHP directives from .htaccess using this extension:
    http://pecl.php.net/package/htscanner

    The problem is that with mod_fcgid -- it is one php.ini for the whole account.
    With suPHP -- you can get it to use different php.ini per directory.
    I am not saying it is a big deal/important, but I have talked to some hosts that needed it.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  6. #31
    Join Date
    Mar 2008
    Location
    Lisbon, Portugal
    Posts
    271
    Igor, cPanel recommend DSO + mod_ruid2 what is your opinion about this setup?

    https://forums.cpanel.net/f189/reduc...hm-275962.html

  7. #32
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    I hope they stopped recommending it by now. At least that is what I was told at cPanel conference.
    mod_ruid2 is architecturally insecure, and any arbitrary code execution in PHP or one of its modules can turn into a hacker being able to run code as any regular user on the system.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  8. #33
    Join Date
    Mar 2005
    Location
    Ten1/0/2
    Posts
    2,529
    Found some further resources that might be of benefit on describing the PHP handlers.

    http://www.thecpaneladmin.com/overview-php-handlers/



    Quote Originally Posted by iseletsk View Post
    fast cgi cannot read parameters from .htaccess files for PHP. suPHP can.
    Otherwise -- it would map one to one without any issues.
    Quote Originally Posted by mindnetcombr View Post
    SUPHP can read Apache directives from .htaccess files, but PHP configuration must be placed in php.ini files. If you put PHP configuration on .htaccess files, suPHP will generate error 500.

    by default FASTCGI not read php.ini files - need some trick to read users php.ini files (like this: http://forums.cpanel.net/f5/individu...gi-160398.html)
    Quote Originally Posted by iseletsk View Post
    suPHP can read PHP directives from .htaccess using this extension:
    http://pecl.php.net/package/htscanner

    The problem is that with mod_fcgid -- it is one php.ini for the whole account.
    With suPHP -- you can get it to use different php.ini per directory.
    I am not saying it is a big deal/important, but I have talked to some hosts that needed it.

    So, there is no "perfect" PHP handler that will do everything!

    It is a case of picking the most suitable handler that has the features that you desire the most.


    DSO - while it is the fastest, it is probably not a good option for a shared envionment mainly because everyhting runs as a single user - which makes it very difficult to find who is doing what (think spamming with a php mailer)

    CGI - slow and not really secure, not recommended.

    suPHP - Small Memory Footprint, Larger CPU Usage, Runs as a User, No Op-code caching available, .htaccess for Apache Configs, errors if php directives in .htaccess, php directives in a php.ini file in the directory for per directory php configs. Can be a bit slow.

    fCGI - Large Memory footprint, Smaller CPU Usage, Runs as User, Op-code Caching available, Fast, Op-code caching, uses a lot of RAM.


    So, in a shared envionment, it probably comes down to suPHP or fCGI. RAM v's CPU usage, OP-code Caching (accelerators) or not, How you apply per-user Apache and PHP directives. With the Tips as per above, some of these lines can be blurred between fCGI and suPHP default behaviours.
    CPanel Shared and Reseller Hosting, OpenVZ VPS Hosting. West Coast (LA) Servers and Nodes
    Running Linux since 1.0.8 Kernel!
    Providing Internet Services since 1995 and Hosting Since 2004

  9. #34
    Join Date
    Mar 2009
    Posts
    3,700
    Hi,

    about "Op-code Caching available",is it important ? and would you recommend/choose using which cache function for fcgi under easyapache ?


    thanx

  10. #35
    Join Date
    Mar 2005
    Location
    Ten1/0/2
    Posts
    2,529
    Op-code caching refers to php accelerators - They only work with DSN and fCGI and not spPHP. So if this is important to you, then this narrows down your choices.
    CPanel Shared and Reseller Hosting, OpenVZ VPS Hosting. West Coast (LA) Servers and Nodes
    Running Linux since 1.0.8 Kernel!
    Providing Internet Services since 1995 and Hosting Since 2004

  11. #36
    Join Date
    May 2012
    Location
    east st.paul
    Posts
    19

    my vote

    Quote Originally Posted by iseletsk View Post
    I hope they stopped recommending it by now. At least that is what I was told at cPanel conference.
    mod_ruid2 is architecturally insecure, and any arbitrary code execution in PHP or one of its modules can turn into a hacker being able to run code as any regular user on the system.
    I would vote mod_ruid2 + DSO to cut down on memory footprints, I don't beleive its any less secure than suphp, if you hack that still be able to run code as user as well, point is you want to run as that user so they can upgrade their wordpress or whatever else on the fly.

  12. #37
    Join Date
    Nov 2012
    Location
    India
    Posts
    19
    Basically for best performance you can go with FCGI + Eaccelarator or maybe use xcache+suphp , they works good together .

  13. #38
    Join Date
    Dec 2011
    Location
    India
    Posts
    19
    You can also use nginxcp plugin with FCGI , it also works better .

  14. #39
    Join Date
    May 2012
    Location
    east st.paul
    Posts
    19
    Quote Originally Posted by PSADeepak View Post
    You can also use nginxcp plugin with FCGI , it also works better .
    NOrmally what I do to, but if you gonna FCGI php, then you gonna have to FCGI perl, then FCGI this language and that language, seems easier to maintain mod_perl and php built in DSO, as they get hit alot less than nginx serving images anyways.

  15. #40
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    Quote Originally Posted by ********* View Post
    Basically for best performance you can go with FCGI + Eaccelarator or maybe use xcache+suphp , they works good together .
    suPHP doesn't work with xcache (plz, prove me wrong, it would be great if it did), nor with any other opcode caching. The problem is that to "share" recompiled php (opcode) between requests, they have to come to children of the same PHP process. suPHP starts a new PHP process on each requests.
    If you enable opcode caching for suPHP -- you are just wasting memory.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  16. #41
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    Quote Originally Posted by syleishere View Post
    NOrmally what I do to, but if you gonna FCGI php, then you gonna have to FCGI perl, then FCGI this language and that language, seems easier to maintain mod_perl and php built in DSO, as they get hit alot less than nginx serving images anyways.
    Not sure if there is FCGI extension to Perl to use it without rewritting CGI scripts, but while it is easier, mod_perl and PHP as DSO are dangerous in shared hosting.
    Of course your luck might vary based on number of customers. If you are small, there is a good chance you will never be hacked using this approach.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  17. #42
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    Quote Originally Posted by syleishere View Post
    I would vote mod_ruid2 + DSO to cut down on memory footprints, I don't beleive its any less secure than suphp, if you hack that still be able to run code as user as well, point is you want to run as that user so they can upgrade their wordpress or whatever else on the fly.
    If you hack with suPHP/FastCGI, you will be able to run code as user, and do whatever you want with that user's site.

    If you hack with mod_ruid, and if hack involves arbitrary code execution in php/php extensions (not that difficult), you can run code AS ANY & ALL regular users on the site, defacing ALL sites on the server, and getting all the info, from all their databases, etc... Not just one site, ALL SITES.

    The only reason it hasn't happened is because mod_ruid is not popular. If it starts to be popular, it will get abused.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  18. #43
    Join Date
    May 2012
    Location
    east st.paul
    Posts
    19
    Quote Originally Posted by iseletsk View Post
    If you hack with suPHP/FastCGI, you will be able to run code as user, and do whatever you want with that user's site.

    If you hack with mod_ruid, and if hack involves arbitrary code execution in php/php extensions (not that difficult), you can run code AS ANY & ALL regular users on the site, defacing ALL sites on the server, and getting all the info, from all their databases, etc... Not just one site, ALL SITES.

    The only reason it hasn't happened is because mod_ruid is not popular. If it starts to be popular, it will get abused.
    Then I hope it gets popular so it does get hacked so it can get fixed, a DSO with user capabilities, its a blessing to administrators trying to control memory on VPS's and amount of processes running. I would however like to see an example exploit where you can hack it to become any user, as far as I know the very first thing it is suppose to do after the website request, is fork and setuid to that user, reason for the fork is so that it cannot go back to root then to another user.

    Dan.

  19. #44
    Join Date
    Jul 2009
    Posts
    126
    Quote Originally Posted by iseletsk View Post
    If you hack with suPHP/FastCGI, you will be able to run code as user, and do whatever you want with that user's site.

    If you hack with mod_ruid, and if hack involves arbitrary code execution in php/php extensions (not that difficult), you can run code AS ANY & ALL regular users on the site, defacing ALL sites on the server, and getting all the info, from all their databases, etc... Not just one site, ALL SITES.

    The only reason it hasn't happened is because mod_ruid is not popular. If it starts to be popular, it will get abused.
    Well, in DirectAdmin Custombuild 2.0 (still beta), mod_ruid2 is now the default. Here is Custombuild 2.0 faq: http://www.directadmin.com/forum/showthread.php?t=44743

    More information here: http://www.directadmin.com/forum/showthread.php?t=44982 "CustomBuild 2.0 BETA with mod_ruid2 by default..."
    Last edited by hb9aj4fn; 11-18-2012 at 11:12 AM.

  20. #45
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    Quote Originally Posted by syleishere View Post
    Then I hope it gets popular so it does get hacked so it can get fixed, a DSO with user capabilities, its a blessing to administrators trying to control memory on VPS's and amount of processes running. I would however like to see an example exploit where you can hack it to become any user, as far as I know the very first thing it is suppose to do after the website request, is fork and setuid to that user, reason for the fork is so that it cannot go back to root then to another user.

    Dan.
    Dan,

    It cannot get fixed. It is not a bug, it is a feature. The architecture of mod_ruid allows it. The way it works:
    setuid(uid);
    process_request
    setuid(apache_user);

    This is done via linux capabilities and by setting it so that httpd process could become any user (above some number).
    There is no fork/die (like in MPM ITK), as that really degrades the performance.
    And because process_request for PHP would be a php DSO (meaning it runs in the s
    ame process space), and all the php extensions that are written by lots of devel
    opers of various skill levels -- there is no way you can protect against them all. They are often found, though rarely abused - as today benefits are low (limit
    ed to single site that you can exploit). With mod_ruid2, all you need is one site on a server -- to abuse them all.
    More then that, hacker can 'buy' a site from from you using stolen credit card,
    and create perfect conditions to abuse the DSO/run arbitrary code... and that is all they have to do.

    That is the type of vulnerability that would allow such abuse:
    http://www.securityfocus.com/bid/51830
    But it doesn't have to be PHP itself, one of its extensions would be enough.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  21. #46
    Join Date
    May 2012
    Location
    east st.paul
    Posts
    19
    Quote Originally Posted by iseletsk View Post
    Dan,

    It cannot get fixed. It is not a bug, it is a feature. The architecture of mod_ruid allows it. The way it works:
    setuid(uid);
    process_request
    setuid(apache_user);

    This is done via linux capabilities and by setting it so that httpd process could become any user (above some number).
    There is no fork/die (like in MPM ITK), as that really degrades the performance.
    And because process_request for PHP would be a php DSO (meaning it runs in the s
    ame process space), and all the php extensions that are written by lots of devel
    opers of various skill levels -- there is no way you can protect against them all. They are often found, though rarely abused - as today benefits are low (limit
    ed to single site that you can exploit). With mod_ruid2, all you need is one site on a server -- to abuse them all.
    More then that, hacker can 'buy' a site from from you using stolen credit card,
    and create perfect conditions to abuse the DSO/run arbitrary code... and that is all they have to do.

    That is the type of vulnerability that would allow such abuse:
    http://www.securityfocus.com/bid/51830
    But it doesn't have to be PHP itself, one of its extensions would be enough.
    I think its a simple enough fix then, we need to make it fork
    and use same security model as ITK, yes its a performance penalty, but its the only way to ensure its not a risk. I am am very surprised to hear this code is not doing exactly what ITK is, I have talked to author of ITK multiple times on fork issue for performance and in the end, it was decided that was the most secure method to avoid problem your talking about. Only reason I just assume it to be doing that to begin with was CPANEL was offering it, I assumed their C developers would have checked into this and would have offered ITK instead just for that reason over mod_ruid2, its alarming for sure, thank-you for bringing that to my attention, I'll have a look over c code.


    Dan.

  22. #47
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    The performance penalty of fork/die in MPM ITK is rather small for PHP, but HUGE if you do it for static pages. Hence mod_ruid2 and their approach.
    Also, mod_fcgid outperforms MPM ITK both in speed & CPU usage for PHP (of course at the cost of memory footprint).
    TBH: the best model that I have seen is PHP SAPI from LiteSpeed. http://www.litespeedtech.com/lsapi-l...interface.html
    The approach allows for memory footprint similar to DSO, security model similar to suPHP and performance similar to mod_fcgid.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  23. #48
    Join Date
    May 2012
    Location
    east st.paul
    Posts
    19
    Quote Originally Posted by iseletsk View Post
    The performance penalty of fork/die in MPM ITK is rather small for PHP, but HUGE if you do it for static pages. Hence mod_ruid2 and their approach.
    Also, mod_fcgid outperforms MPM ITK both in speed & CPU usage for PHP (of course at the cost of memory footprint).
    TBH: the best model that I have seen is PHP SAPI from LiteSpeed. http://www.litespeedtech.com/lsapi-l...interface.html
    The approach allows for memory footprint similar to DSO, security model similar to suPHP and performance similar to mod_fcgid.
    Yes your thinking about it from a programming perspective and not a system administration perspective however. If we start putting php under FCGI , then we'll have to put perl there, then we'll have to put this and that language there and have a ton of different new services to monitor separate instead of just apache. Here is what I think is best, we DSO php, perl, and any other language into apache itself to cut down on administration, then for static pages(jpg, html, jscript, css and whatever else) , we put nginx using epoll up front for static image serving. Just using epoll over fork to begin with with images and allowing php/perl/etc apache processes to fork should be decent performance. Now this way in effect the administrator only has 2 processes to watch, nginx and apache, and nginx can server as load balancer as well solving most www needs.


    Dan.

  24. #49
    Join Date
    May 2012
    Location
    east st.paul
    Posts
    19
    I can just say the system administration headache of FCGI for programming languages is a headache in general, I've had almost every setup from FCGI, ITK, FPM, DSO , suphp or whatever else you can think of, if going the taking languages outside apache route gains popularity so will the burden of administration. I remember a setup I had for FCGI I had php under it, perl under another, and 2 other languages under another FCGI and a few other custom libraries I wrote under another FCGI to cut down on load times, while I agree this is best route for a custom website, I do not beleive it meets expectations of shared hosting industry. Other issue with separating them is you start X amount of processes for each language, and most of them probably are never getting used, and no real garbage collection on half the crappy FCGI implementations I've seen. So in reality by time your putting your 4th language under FCGI you probably have increased your memory footprints needlessly, added massive administration work for yourself having to check more logs, have more monitoring processes. Only real benefit in it was being able to isolate and debug issues more efficiently, but like I said I don't think the administration burder for this belongs in shared hosting, only custom website setups.

    Dan.

Page 2 of 2 FirstFirst 12

Similar Threads

  1. cpanel Exim suPHP & suExec - web emails going out as server host vs. domain name
    By pmabraham in forum Hosting Security and Technology
    Replies: 4
    Last Post: 08-30-2013, 04:50 PM
  2. cPanel install SuPHP
    By KMyers in forum Hosting Software and Control Panels
    Replies: 4
    Last Post: 12-28-2009, 05:18 AM
  3. migrating non-suphp server to suphp server
    By sharmaine1111 in forum Hosting Security and Technology
    Replies: 4
    Last Post: 09-06-2009, 12:03 PM
  4. cPanel -- suPHP for spam?
    By Calibur747 in forum Hosting Software and Control Panels
    Replies: 4
    Last Post: 12-31-2007, 04:45 PM
  5. Setting up suPHP with Cpanel Server, Apache 1
    By CymraegWalesHosting in forum Hosting Security and Technology
    Replies: 3
    Last Post: 01-03-2007, 04:57 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •