Devo usar suphp ou mod_php para hospedagem compartilhada?

Question

Estou pensando em usar o suphp. Parece que os arquivos recém-criados no php obtêm a propriedade apache.apache e isso pode se tornar um problema. Também parece que o monitoramento de spam enviado e uso de carga por scripts php é mais fácil de monitorar com suphp.

No entanto, receio que isso reduza o desempenho nos servidores. Eu uso o painel de controle Plesk e DirectAdmin para servidores e hospedo cerca de 200 domínios por servidor, mas não quero ver um alto aumento na carga com o suphp. Também não tenho certeza se suphp é apenas um nome fantasia para php via cgi.

suphp

• quase 10 vezes mais lento?
• isto é apenas php sob cgi? como fizemos há 10 anos atrás?
• mais fácil de monitorar, todos os scripts são executados com o nome de usuário.
• permissões mínimas = 640.

mod_php

• muito mais rápido
• melhor integração com o apache?
• scripts são executados sob o apache: apache.
• permissões mínimas = 64 4 (!), leitura de arquivos de senhas restritos apenas pelo open_basedir, não pelo sistema de permissões padrão do linux em si?

Então ... o suphp oferece maior segurança? e oferece muitos benefícios no monitoramento de ameaças (spam), benchmarking (spiking php scripts), etc? E quão grande é o dreno no desempenho?

    

Answer 1

suphp não é a mesma coisa que PHP, existem várias diferenças funcionais.

A execução de uma interface CGI padrão é muito mais lenta que o módulo fastCGI / webserver. AFAIK suphp não suporta fastCGI - mas agora existe uma versão do módulo do apache. Ele fornece alguns ajustes de segurança que não estão disponíveis no PHP padrão, no entanto, o último não é exatamente pobre a esse respeito. As perguntas mais importantes são se você está feliz em manter o software a partir de tarballs e se seus usuários ficarão satisfeitos com uma versão do PHP que fica atrás da versão oficial em sua funcionalidade.

Qualquer que seja a versão escolhida, ela fornecerá a mesma segurança que você configura. Se você decidir sobre o PHP padrão, certifique-se de que:

1) você define open_basedir para restringir os usuários a seus próprios diretórios

2) você pode querer desativar o allow_url_fopen

3) você deve definitivamente desativar o allow-url-include

4) se você quer um sistema muito restritivo então desabilite eval e create_function

5) defina um include_path por usuário

6) altere sendmail_path para apontar para um script wrapper que registra a conta que está sendo usada (você deve conseguir resolver isso a partir do cwd) e imple- menta as cotas

7) defina o session.save_path como um local por usuário

Não estou ciente de nada no suphp que lide especificamente com spam, mas você pode adicionar facilmente seu próprio script de wrapper conforme descrito acima. Observe que a maioria das etapas acima se aplicará ao suphp to - apenas facilita a queda de parâmetros nas diretivas do arquivo de configuração, em vez de substituí-las na configuração do apache ou via .htaccess.

    

Answer 2

Eu recomendo usar o ITK MPM . Você terá que executar um VirtualHost separado para cada usuário, mas você pode estar fazendo isso de qualquer maneira. No entanto, se você estiver executando o mod_userdir, você está sem sorte e precisa usar o suphp para obter uma separação adequada.