Fwd: Servidor Django sem acesso por Shell

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Servidor Django sem acesso por Shell

Robson Eisinger
Oi pessoal,

Eu enviei a seguinte duvida ao pessoal do Django Brasil, mas como a pergunta
não se restringe ao django e sim a infra-estrutura necessaria para prover
serviço de hosting aqui na minha faculdade, decidi encaminhar a pergunta
aqui para o python-brasil.

Em resumo, estou verificando a viabilidade de "hostear" projetos que usem
django, sem acesso a um shell de qualquer tipo. Até o momento, consegui
simplificar a configuração, eliminando por completo o acesso do usuário aos
arquivos de configuração do servidor, mas ainda é necessário o uso de touch
no wsgi, vi em alguns sites que é possivel contornar isso verificando por
modificações nos arquivos dos usuarios, mas considerando a queda de
desempenho, decidi buscar ajuda dos colegas.

Segue abaixo o email original com minhas dúvidas.

Abraços,

Robson.

Analista TI/Redes

Subject: Servidor Django sem acesso por Shell
To: Django Brasil <[hidden email]>


Oi pessoal,

Estou avaliando o django como uma opção para web-hosting aqui na
faculdade que trabalho, basicamente hospedamos pequenas paginas com
fins academicos, mas encalhei em alguns pontos, como segue:


1) Restrições de Segurança: Não tenho como mudar este ponto, o acesso
do usuário só pode ser feito por ftp. O problema é que em alguns
casos, quando modifiquei alguns arquivos, fui obrigado a executar um
"touch" no arquivo de configuração wsgi ou ele continuava apresentando
o conteudo antigo.

2) Aproveitei e testei dois cms diferentes, o Django CMS e o Django-
Fiber, fiz a instalação "global" de ambos e vi que ao instalar o
Django-Fiber, o Django-CMS parou de funcionar como antes. Existe algum
modo de instalar CMS diferentes em uma maquina de produção sem correr
o risco disso acontecer?

3) Outra restrição de segurança, não tão critica, é o uso do sqlite3,
é possivel barrar seu uso?

Todos os testes foram realizados em uma maquina virtual com a seguinte
configuração: Ubuntu 10.04 LTS 64 bits (512 mega de RAM), mas é bem
provavel que a instalação final, caso consiga cumprir os requisitos,
será em um servidor Debian ou RedHat/CentOS. Por conveniência, optei
por um servidor cuja instalação fosse simples e rápida, sem sustos.

Para este estudo, estou usando o seguinte tutorial:

http://blog.stannard.net.au/2010/12/11/installing-django-with-apache-and-mod_wsgi-on-ubuntu-10-04/

Lista de CMS usando o framework Django:

http://djangopackages.com/grids/g/cms/

Desde já obrigado.

Abraços,

Robson.

Analista TI/Network.



--
Abraços,

Robson Eisinger.

Twitter: http://twitter.com/papilobr (de vez em quando posto links e
bobagens que acho ou acham pra mim)

Blog: http://animecare.blogspot.com/
(Reviews, Notícias e muito papo furado)


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Servidor Django sem acesso por Shell

Marco Carvalho
Robson, posso fazer uma sugestão?

Porque em vez de trabalhar com vhosts, que é um pesadelo, você não trabalha
com máquinas virtuais em Xen?
Vantagens:
1 - Cada hospedagem vai ter sua própria máquina com memória e disco
limitados, ou seja, qualquer abuso de recursos irá afetar somente ele mesmo
e não todos os outros como em um vhost
2 - Não precisa se preocupar com restrições disso e daquilo, cada um será
responsável pela sua máquina
3 - Você pode criar um template de máquina virtual com tudo o que precisa e
criar as máquinas a partir desse template e se alguma máquina for
irremediavelmente comprometida, simplesmente destrua e crie novamente a
partir do template.

Você poderia usar o KVM ao invés do Xen, mas nunca trabalhei com KVM então
não posso afirmar que seja tão leve e eficiente quanto o Xen.


Marco Carvalho (macs) | marcoacarvalho(a)gmail.com
Maceio - Alagoas - Brazil
Linux Mint 10 Debian Edition 64 bits
GNU-PG ID:30FA1DBD
Linux Registered User #141545


Em 24 de agosto de 2011 15:49, Robson Eisinger <[hidden email]>escreveu:

> **
>
>
> Oi pessoal,
>
> Eu enviei a seguinte duvida ao pessoal do Django Brasil, mas como a
> pergunta
> não se restringe ao django e sim a infra-estrutura necessaria para prover
> serviço de hosting aqui na minha faculdade, decidi encaminhar a pergunta
> aqui para o python-brasil.
>
> Em resumo, estou verificando a viabilidade de "hostear" projetos que usem
> django, sem acesso a um shell de qualquer tipo. Até o momento, consegui
> simplificar a configuração, eliminando por completo o acesso do usuário aos
> arquivos de configuração do servidor, mas ainda é necessário o uso de touch
> no wsgi, vi em alguns sites que é possivel contornar isso verificando por
> modificações nos arquivos dos usuarios, mas considerando a queda de
> desempenho, decidi buscar ajuda dos colegas.
>
> Segue abaixo o email original com minhas dúvidas.
>
> Abraços,
>
> Robson.
>
> Analista TI/Redes
>
> Subject: Servidor Django sem acesso por Shell
> To: Django Brasil <[hidden email]>
>
>
> Oi pessoal,
>
> Estou avaliando o django como uma opção para web-hosting aqui na
> faculdade que trabalho, basicamente hospedamos pequenas paginas com
> fins academicos, mas encalhei em alguns pontos, como segue:
>
> 1) Restrições de Segurança: Não tenho como mudar este ponto, o acesso
> do usuário só pode ser feito por ftp. O problema é que em alguns
> casos, quando modifiquei alguns arquivos, fui obrigado a executar um
> "touch" no arquivo de configuração wsgi ou ele continuava apresentando
> o conteudo antigo.
>
> 2) Aproveitei e testei dois cms diferentes, o Django CMS e o Django-
> Fiber, fiz a instalação "global" de ambos e vi que ao instalar o
> Django-Fiber, o Django-CMS parou de funcionar como antes. Existe algum
> modo de instalar CMS diferentes em uma maquina de produção sem correr
> o risco disso acontecer?
>
> 3) Outra restrição de segurança, não tão critica, é o uso do sqlite3,
> é possivel barrar seu uso?
>
> Todos os testes foram realizados em uma maquina virtual com a seguinte
> configuração: Ubuntu 10.04 LTS 64 bits (512 mega de RAM), mas é bem
> provavel que a instalação final, caso consiga cumprir os requisitos,
> será em um servidor Debian ou RedHat/CentOS. Por conveniência, optei
> por um servidor cuja instalação fosse simples e rápida, sem sustos.
>
> Para este estudo, estou usando o seguinte tutorial:
>
>
> http://blog.stannard.net.au/2010/12/11/installing-django-with-apache-and-mod_wsgi-on-ubuntu-10-04/
>
> Lista de CMS usando o framework Django:
>
> http://djangopackages.com/grids/g/cms/
>
> Desde já obrigado.
>
> Abraços,
>
> Robson.
>
> Analista TI/Network.
>
> --
> Abraços,
>
> Robson Eisinger.
>
> Twitter: http://twitter.com/papilobr (de vez em quando posto links e
> bobagens que acho ou acham pra mim)
>
> Blog: http://animecare.blogspot.com/
> (Reviews, Notícias e muito papo furado)
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Servidor Django sem acesso por Shell

Robson Eisinger
Marco valeu pela resposta, a maquina em si ja seria virtual, usamos vmware,
mas temos uma blade com xen. Curioso vc comentar de kvm, estivemos testando
openstack, um servidor cloud que automatiza a criacao de maquinas virtuais e
a interface web usa django. Ele eh todo em python, se alguem tiver
curiosidade, pesquisem no google.

Em todo caso, a intencao eh ver se possivel com vhost e as restricoes.
Liberar a maquina virtual implica em deixar a responsabilidade da seguranca
com quem for usar, o que foge um pouco da nossa proposta de trabalho. Mas
essa possibilidade esta sendo considerada, no entanto, sempre eh bom
conhecer todas as possiveis solucoes.

Obrigado pelas ideias. =)
Em 28/08/2011 13:38, "Marco Carvalho" <[hidden email]> escreveu:
> Robson, posso fazer uma sugestão?
>
> Porque em vez de trabalhar com vhosts, que é um pesadelo, você não
trabalha
> com máquinas virtuais em Xen?
> Vantagens:
> 1 - Cada hospedagem vai ter sua própria máquina com memória e disco
> limitados, ou seja, qualquer abuso de recursos irá afetar somente ele
mesmo
> e não todos os outros como em um vhost
> 2 - Não precisa se preocupar com restrições disso e daquilo, cada um será
> responsável pela sua máquina
> 3 - Você pode criar um template de máquina virtual com tudo o que precisa
e

> criar as máquinas a partir desse template e se alguma máquina for
> irremediavelmente comprometida, simplesmente destrua e crie novamente a
> partir do template.
>
> Você poderia usar o KVM ao invés do Xen, mas nunca trabalhei com KVM então
> não posso afirmar que seja tão leve e eficiente quanto o Xen.
>
>
> Marco Carvalho (macs) | marcoacarvalho(a)gmail.com
> Maceio - Alagoas - Brazil
> Linux Mint 10 Debian Edition 64 bits
> GNU-PG ID:30FA1DBD
> Linux Registered User #141545
>
>
> Em 24 de agosto de 2011 15:49, Robson Eisinger <[hidden email]
>escreveu:
>
>> **
>>
>>
>> Oi pessoal,
>>
>> Eu enviei a seguinte duvida ao pessoal do Django Brasil, mas como a
>> pergunta
>> não se restringe ao django e sim a infra-estrutura necessaria para prover
>> serviço de hosting aqui na minha faculdade, decidi encaminhar a pergunta
>> aqui para o python-brasil.
>>
>> Em resumo, estou verificando a viabilidade de "hostear" projetos que usem
>> django, sem acesso a um shell de qualquer tipo. Até o momento, consegui
>> simplificar a configuração, eliminando por completo o acesso do usuário
aos
>> arquivos de configuração do servidor, mas ainda é necessário o uso de
touch

>> no wsgi, vi em alguns sites que é possivel contornar isso verificando por
>> modificações nos arquivos dos usuarios, mas considerando a queda de
>> desempenho, decidi buscar ajuda dos colegas.
>>
>> Segue abaixo o email original com minhas dúvidas.
>>
>> Abraços,
>>
>> Robson.
>>
>> Analista TI/Redes
>>
>> Subject: Servidor Django sem acesso por Shell
>> To: Django Brasil <[hidden email]>
>>
>>
>> Oi pessoal,
>>
>> Estou avaliando o django como uma opção para web-hosting aqui na
>> faculdade que trabalho, basicamente hospedamos pequenas paginas com
>> fins academicos, mas encalhei em alguns pontos, como segue:
>>
>> 1) Restrições de Segurança: Não tenho como mudar este ponto, o acesso
>> do usuário só pode ser feito por ftp. O problema é que em alguns
>> casos, quando modifiquei alguns arquivos, fui obrigado a executar um
>> "touch" no arquivo de configuração wsgi ou ele continuava apresentando
>> o conteudo antigo.
>>
>> 2) Aproveitei e testei dois cms diferentes, o Django CMS e o Django-
>> Fiber, fiz a instalação "global" de ambos e vi que ao instalar o
>> Django-Fiber, o Django-CMS parou de funcionar como antes. Existe algum
>> modo de instalar CMS diferentes em uma maquina de produção sem correr
>> o risco disso acontecer?
>>
>> 3) Outra restrição de segurança, não tão critica, é o uso do sqlite3,
>> é possivel barrar seu uso?
>>
>> Todos os testes foram realizados em uma maquina virtual com a seguinte
>> configuração: Ubuntu 10.04 LTS 64 bits (512 mega de RAM), mas é bem
>> provavel que a instalação final, caso consiga cumprir os requisitos,
>> será em um servidor Debian ou RedHat/CentOS. Por conveniência, optei
>> por um servidor cuja instalação fosse simples e rápida, sem sustos.
>>
>> Para este estudo, estou usando o seguinte tutorial:
>>
>>
>>
http://blog.stannard.net.au/2010/12/11/installing-django-with-apache-and-mod_wsgi-on-ubuntu-10-04/

>>
>> Lista de CMS usando o framework Django:
>>
>> http://djangopackages.com/grids/g/cms/
>>
>> Desde já obrigado.
>>
>> Abraços,
>>
>> Robson.
>>
>> Analista TI/Network.
>>
>> --
>> Abraços,
>>
>> Robson Eisinger.
>>
>> Twitter: http://twitter.com/papilobr (de vez em quando posto links e
>> bobagens que acho ou acham pra mim)
>>
>> Blog: http://animecare.blogspot.com/
>> (Reviews, Notícias e muito papo furado)
>>
>> [As partes desta mensagem que não continham texto foram removidas]
>>
>>
>>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Servidor Django sem acesso por Shell

Allison Vollmann
Se a idéia é usar virtualização e todos os nós executarão o mesmo OS você pode, ao invés de virtualização utilizar chroot limitando o acesso cada usuário a sua home.

Ou utilizar virtualização a nível de kernel (muito mais eficiente, quase não tem perca de desempenho em comparação com maquinas físicas) porém te limita a utilizar o mesmo OS e a mesma versão do kernel (pode ser outra distribuição, apenas o kernel deve ser o mesmo) [1][2]. A vantagem é que o HOST tem acesso ao sistema de arquivos das outras instâncias como um diretório qualquer, facilita para backups centralizados e o mesmo para processos do sistema.

Se você tem apenas 1 ip público, pode subir um server na maquina principal apenas para fazer proxy que redireciona para as instâncias de acordo com o host.

[1] http://linux-vserver.org/Welcome_to_Linux-VServer.org
[2] http://wiki.openvz.org/Main_Page


________________________________
De: Robson Eisinger <[hidden email]>
Para: [hidden email]
Enviadas: Segunda-feira, 29 de Agosto de 2011 1:10
Assunto: Re: [python-brasil] Fwd: Servidor Django sem acesso por Shell


 
Marco valeu pela resposta, a maquina em si ja seria virtual, usamos vmware,
mas temos uma blade com xen. Curioso vc comentar de kvm, estivemos testando
openstack, um servidor cloud que automatiza a criacao de maquinas virtuais e
a interface web usa django. Ele eh todo em python, se alguem tiver
curiosidade, pesquisem no google.

Em todo caso, a intencao eh ver se possivel com vhost e as restricoes.
Liberar a maquina virtual implica em deixar a responsabilidade da seguranca
com quem for usar, o que foge um pouco da nossa proposta de trabalho. Mas
essa possibilidade esta sendo considerada, no entanto, sempre eh bom
conhecer todas as possiveis solucoes.

Obrigado pelas ideias. =)
Em 28/08/2011 13:38, "Marco Carvalho" <[hidden email]> escreveu:
> Robson, posso fazer uma sugestão?
>
> Porque em vez de trabalhar com vhosts, que é um pesadelo, você não
trabalha
> com máquinas virtuais em Xen?
> Vantagens:
> 1 - Cada hospedagem vai ter sua própria máquina com memória e disco
> limitados, ou seja, qualquer abuso de recursos irá afetar somente ele
mesmo
> e não todos os outros como em um vhost
> 2 - Não precisa se preocupar com restrições disso e daquilo, cada um será
> responsável pela sua máquina
> 3 - Você pode criar um template de máquina virtual com tudo o que precisa
e

> criar as máquinas a partir desse template e se alguma máquina for
> irremediavelmente comprometida, simplesmente destrua e crie novamente a
> partir do template.
>
> Você poderia usar o KVM ao invés do Xen, mas nunca trabalhei com KVM então
> não posso afirmar que seja tão leve e eficiente quanto o Xen.
>
>
> Marco Carvalho (macs) | marcoacarvalho(a)gmail.com
> Maceio - Alagoas - Brazil
> Linux Mint 10 Debian Edition 64 bits
> GNU-PG ID:30FA1DBD
> Linux Registered User #141545
>
>
> Em 24 de agosto de 2011 15:49, Robson Eisinger <[hidden email]
>escreveu:
>
>> **
>>
>>
>> Oi pessoal,
>>
>> Eu enviei a seguinte duvida ao pessoal do Django Brasil, mas como a
>> pergunta
>> não se restringe ao django e sim a infra-estrutura necessaria para prover
>> serviço de hosting aqui na minha faculdade, decidi encaminhar a pergunta
>> aqui para o python-brasil.
>>
>> Em resumo, estou verificando a viabilidade de "hostear" projetos que usem
>> django, sem acesso a um shell de qualquer tipo. Até o momento, consegui
>> simplificar a configuração, eliminando por completo o acesso do usuário
aos
>> arquivos de configuração do servidor, mas ainda é necessário o uso de
touch

>> no wsgi, vi em alguns sites que é possivel contornar isso verificando por
>> modificações nos arquivos dos usuarios, mas considerando a queda de
>> desempenho, decidi buscar ajuda dos colegas.
>>
>> Segue abaixo o email original com minhas dúvidas.
>>
>> Abraços,
>>
>> Robson.
>>
>> Analista TI/Redes
>>
>> Subject: Servidor Django sem acesso por Shell
>> To: Django Brasil <[hidden email]>
>>
>>
>> Oi pessoal,
>>
>> Estou avaliando o django como uma opção para web-hosting aqui na
>> faculdade que trabalho, basicamente hospedamos pequenas paginas com
>> fins academicos, mas encalhei em alguns pontos, como segue:
>>
>> 1) Restrições de Segurança: Não tenho como mudar este ponto, o acesso
>> do usuário só pode ser feito por ftp. O problema é que em alguns
>> casos, quando modifiquei alguns arquivos, fui obrigado a executar um
>> "touch" no arquivo de configuração wsgi ou ele continuava apresentando
>> o conteudo antigo.
>>
>> 2) Aproveitei e testei dois cms diferentes, o Django CMS e o Django-
>> Fiber, fiz a instalação "global" de ambos e vi que ao instalar o
>> Django-Fiber, o Django-CMS parou de funcionar como antes. Existe algum
>> modo de instalar CMS diferentes em uma maquina de produção sem correr
>> o risco disso acontecer?
>>
>> 3) Outra restrição de segurança, não tão critica, é o uso do sqlite3,
>> é possivel barrar seu uso?
>>
>> Todos os testes foram realizados em uma maquina virtual com a seguinte
>> configuração: Ubuntu 10.04 LTS 64 bits (512 mega de RAM), mas é bem
>> provavel que a instalação final, caso consiga cumprir os requisitos,
>> será em um servidor Debian ou RedHat/CentOS. Por conveniência, optei
>> por um servidor cuja instalação fosse simples e rápida, sem sustos.
>>
>> Para este estudo, estou usando o seguinte tutorial:
>>
>>
>>
http://blog.stannard.net.au/2010/12/11/installing-django-with-apache-and-mod_wsgi-on-ubuntu-10-04/

>>
>> Lista de CMS usando o framework Django:
>>
>> http://djangopackages.com/grids/g/cms/
>>
>> Desde já obrigado.
>>
>> Abraços,
>>
>> Robson.
>>
>> Analista TI/Network.
>>
>> --
>> Abraços,
>>
>> Robson Eisinger.
>>
>> Twitter: http://twitter.com/papilobr (de vez em quando posto links e
>> bobagens que acho ou acham pra mim)
>>
>> Blog: http://animecare.blogspot.com/
>> (Reviews, Notícias e muito papo furado)
>>
>> [As partes desta mensagem que não continham texto foram removidas]
>>
>>
>>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>

[As partes desta mensagem que não continham texto foram removidas]


 

[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Servidor Django sem acesso por Shell

Robson Eisinger
No momento, prefiro centrar em uma maquina só, mesmo que virtualizada, com
os vhosts, depois devo me preocupar com a virtualização e como seria
acessado isso, mas até o ip v6 sair de fato, temos sim um limite de IPs para
uso. Limitar o acesso já faz parte, o grande dilema é, como disse, bloquear
o acesso a shell, o usuario teria que implementar o sitio em outra
plataforma (de testes), e fazer o upload por sftp (melhor usar o termo
correto, para não confundir com o velho ftp).

Eu ainda estou fechando as pontas aqui, mas não consegui eliminar 100%, as
vezes é necessário dar um touch no arquivo wsgi de configuração do projeto
django, e deixar esse arquivo nas mãos do usuário pode ser uma falha de
segurança, mesmo restringindo bem o acesso a sua home.

Isso me lembra de uma duvida que surgiu aqui em relação ao wsgi, o texto
abaixo tem como origem uma discussão interna com um colega aqui do meu
trabalho.

"Se o mod_wsgi precisar ativar alguma regra/reescrita de URL/URI mesmo que
seja via mod_wsgi, você estará dando acesso ao mod_rewrite para a aplicação.
O medo é que qualquer falha na aplicação ou exploit de alguma coisa que
o usuario do django faça muito inocentemente possa abrir uma brecha
muito grande.
Se pudessemos contar com desenvolvedores funcionários que são treinados ou
profissionais com experiencia em django não há problema, mas sempre temos
que contar que pessoas sem noção nenhuma vão tentar aplicar alguma receita
pronta de revista ou dica de blog, ou até mesmo um estagiário para aprender,
para colocar um site no ar em produção. E o django é uma plataforma de
desenvolvimento, e não um CMS que se instala uma vez e vai preenchendo com
informação.
Se o django blindado e impedisse que o usuario fizesse furos de segurança
seria ótimo."

O modo como implementei, que pede atualização com touch não parece usar o
mod_rewrite, mas é melhor algum feedback da comunidade. Meu interesse é
tornar viavel o uso de django aqui na faculdade, dentro das normas de
segurança daqui. Existe alguma resistência considerando o framework inseguro
por usar o mod_rewrite, por isso esse meu trabalho de avaliação tem uma
certa importância.

Abraços,

Robson.

2011/8/29 Allison Vollmann <[hidden email]>

> **
>
>
> Se a idéia é usar virtualização e todos os nós executarão o mesmo OS você
> pode, ao invés de virtualização utilizar chroot limitando o acesso cada
> usuário a sua home.
>
> Ou utilizar virtualização a nível de kernel (muito mais eficiente, quase
> não tem perca de desempenho em comparação com maquinas físicas) porém te
> limita a utilizar o mesmo OS e a mesma versão do kernel (pode ser outra
> distribuição, apenas o kernel deve ser o mesmo) [1][2]. A vantagem é que o
> HOST tem acesso ao sistema de arquivos das outras instâncias como um
> diretório qualquer, facilita para backups centralizados e o mesmo para
> processos do sistema.
>
> Se você tem apenas 1 ip público, pode subir um server na maquina principal
> apenas para fazer proxy que redireciona para as instâncias de acordo com o
> host.
>
> [1] http://linux-vserver.org/Welcome_to_Linux-VServer.org
> [2] http://wiki.openvz.org/Main_Page
>
> ________________________________
> De: Robson Eisinger <[hidden email]>
> Para: [hidden email]
> Enviadas: Segunda-feira, 29 de Agosto de 2011 1:10
> Assunto: Re: [python-brasil] Fwd: Servidor Django sem acesso por Shell
>
>
>
> Marco valeu pela resposta, a maquina em si ja seria virtual, usamos vmware,
> mas temos uma blade com xen. Curioso vc comentar de kvm, estivemos testando
> openstack, um servidor cloud que automatiza a criacao de maquinas virtuais
> e
> a interface web usa django. Ele eh todo em python, se alguem tiver
> curiosidade, pesquisem no google.
>
> Em todo caso, a intencao eh ver se possivel com vhost e as restricoes.
> Liberar a maquina virtual implica em deixar a responsabilidade da seguranca
> com quem for usar, o que foge um pouco da nossa proposta de trabalho. Mas
> essa possibilidade esta sendo considerada, no entanto, sempre eh bom
> conhecer todas as possiveis solucoes.
>
> Obrigado pelas ideias. =)
> Em 28/08/2011 13:38, "Marco Carvalho" <[hidden email]> escreveu:
> > Robson, posso fazer uma sugestão?
> >
> > Porque em vez de trabalhar com vhosts, que é um pesadelo, você não
> trabalha
> > com máquinas virtuais em Xen?
> > Vantagens:
> > 1 - Cada hospedagem vai ter sua própria máquina com memória e disco
> > limitados, ou seja, qualquer abuso de recursos irá afetar somente ele
> mesmo
> > e não todos os outros como em um vhost
> > 2 - Não precisa se preocupar com restrições disso e daquilo, cada um será
> > responsável pela sua máquina
> > 3 - Você pode criar um template de máquina virtual com tudo o que precisa
> e
> > criar as máquinas a partir desse template e se alguma máquina for
> > irremediavelmente comprometida, simplesmente destrua e crie novamente a
> > partir do template.
> >
> > Você poderia usar o KVM ao invés do Xen, mas nunca trabalhei com KVM
> então
> > não posso afirmar que seja tão leve e eficiente quanto o Xen.
> >
> >
> > Marco Carvalho (macs) | marcoacarvalho(a)gmail.com
> > Maceio - Alagoas - Brazil
> > Linux Mint 10 Debian Edition 64 bits
> > GNU-PG ID:30FA1DBD
> > Linux Registered User #141545
> >
> >
> > Em 24 de agosto de 2011 15:49, Robson Eisinger <[hidden email]
> >escreveu:
> >
> >> **
> >>
> >>
> >> Oi pessoal,
> >>
> >> Eu enviei a seguinte duvida ao pessoal do Django Brasil, mas como a
> >> pergunta
> >> não se restringe ao django e sim a infra-estrutura necessaria para
> prover
> >> serviço de hosting aqui na minha faculdade, decidi encaminhar a pergunta
> >> aqui para o python-brasil.
> >>
> >> Em resumo, estou verificando a viabilidade de "hostear" projetos que
> usem
> >> django, sem acesso a um shell de qualquer tipo. Até o momento, consegui
> >> simplificar a configuração, eliminando por completo o acesso do usuário
> aos
> >> arquivos de configuração do servidor, mas ainda é necessário o uso de
> touch
> >> no wsgi, vi em alguns sites que é possivel contornar isso verificando
> por
> >> modificações nos arquivos dos usuarios, mas considerando a queda de
> >> desempenho, decidi buscar ajuda dos colegas.
> >>
> >> Segue abaixo o email original com minhas dúvidas.
> >>
> >> Abraços,
> >>
> >> Robson.
> >>
> >> Analista TI/Redes
> >>
> >> Subject: Servidor Django sem acesso por Shell
> >> To: Django Brasil <[hidden email]>
> >>
> >>
> >> Oi pessoal,
> >>
> >> Estou avaliando o django como uma opção para web-hosting aqui na
> >> faculdade que trabalho, basicamente hospedamos pequenas paginas com
> >> fins academicos, mas encalhei em alguns pontos, como segue:
> >>
> >> 1) Restrições de Segurança: Não tenho como mudar este ponto, o acesso
> >> do usuário só pode ser feito por ftp. O problema é que em alguns
> >> casos, quando modifiquei alguns arquivos, fui obrigado a executar um
> >> "touch" no arquivo de configuração wsgi ou ele continuava apresentando
> >> o conteudo antigo.
> >>
> >> 2) Aproveitei e testei dois cms diferentes, o Django CMS e o Django-
> >> Fiber, fiz a instalação "global" de ambos e vi que ao instalar o
> >> Django-Fiber, o Django-CMS parou de funcionar como antes. Existe algum
> >> modo de instalar CMS diferentes em uma maquina de produção sem correr
> >> o risco disso acontecer?
> >>
> >> 3) Outra restrição de segurança, não tão critica, é o uso do sqlite3,
> >> é possivel barrar seu uso?
> >>
> >> Todos os testes foram realizados em uma maquina virtual com a seguinte
> >> configuração: Ubuntu 10.04 LTS 64 bits (512 mega de RAM), mas é bem
> >> provavel que a instalação final, caso consiga cumprir os requisitos,
> >> será em um servidor Debian ou RedHat/CentOS. Por conveniência, optei
> >> por um servidor cuja instalação fosse simples e rápida, sem sustos.
> >>
> >> Para este estudo, estou usando o seguinte tutorial:
> >>
> >>
> >>
>
> http://blog.stannard.net.au/2010/12/11/installing-django-with-apache-and-mod_wsgi-on-ubuntu-10-04/
> >>
> >> Lista de CMS usando o framework Django:
> >>
> >> http://djangopackages.com/grids/g/cms/
> >>
> >> Desde já obrigado.
> >>
> >> Abraços,
> >>
> >> Robson.
> >>
> >> Analista TI/Network.
> >>
> >> --
> >> Abraços,
> >>
> >> Robson Eisinger.
> >>
> >> Twitter: http://twitter.com/papilobr (de vez em quando posto links e
> >> bobagens que acho ou acham pra mim)
> >>
> >> Blog: http://animecare.blogspot.com/
> >> (Reviews, Notícias e muito papo furado)
> >>
> >> [As partes desta mensagem que não continham texto foram removidas]
> >>
> >>
> >>
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > ------------------------------------
> >
> > Python-Brasil
> > http://www.python.org.br/wiki/AntesDePerguntar
> > Links do Yahoo! Grupos
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>



--
Abraços,

Robson Eisinger.

Twitter: http://twitter.com/papilobr (de vez em quando posto links e
bobagens que acho ou acham pra mim)

Blog: http://animecare.blogspot.com/
(Reviews, Notícias e muito papo furado)


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Servidor Django sem acesso por Shell

Carlos Ribeiro
2011/8/29 Robson Eisinger <[hidden email]>

> No momento, prefiro centrar em uma maquina só, mesmo que virtualizada, com
> os vhosts, depois devo me preocupar com a virtualização e como seria
> acessado isso, mas até o ip v6 sair de fato, temos sim um limite de IPs
> para
> uso. Limitar o acesso já faz parte, o grande dilema é, como disse, bloquear
> o acesso a shell, o usuario teria que implementar o sitio em outra
> plataforma (de testes), e fazer o upload por sftp (melhor usar o termo
> correto, para não confundir com o velho ftp).
>

Correndo o risco de ficar muito offtopic, tive uma idéia aqui, acho que é
uma alternativa razoável para pensar em termos de arquitetura.

1) Instale as instâncias de Django em VMs separadas, mas usando IPs
privativos.

2) Instale um proxy reverso no seu único IP público, que possa fazer o
redirecionamento interno usando o nome de domínio.

Esta proposta tem algumas vantagens:

- Mais segurança, pois os servidores não ficam diretamente expostos.
- Possibilidade de criar mecanismos de caching mais eficientes.
- Se eu não tiver esquecido nada, a URL não precisa ser "reescrita", basta
repassar a mesma URL original para o IP interno.

As desvantagens seriam em termos de overhead, que talvez possa ser
compensada pelo caching no front-end; e algum possível impacto devido aos
endereços privativos, mas que eu realmente acho que não vai ter problema.

Obs: o SSH também precisa ser redirecionado, mas isso pode ser resolvido
também...

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: [hidden email]


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Servidor Django sem acesso por Shell

Allison Vollmann
Com o Linux-VServer/OpenVZ teria menos overhead, quase nenhum (pois seria apenas virtualizado o ambiente e não o sistema todo).

E para SSH provavelmente daria para usar apenas o daemon da maquina física principal (sem direcionar), pois se deixar o filesystem exposto bastaria configurar o daemon para trabalhar com chroot.

O interessante dessa metodologia é que se utilizar um sistema de arquivos distribuídos você consegue montar uma cloud de alta disponibilidade facilmente, apenas replicando os heads, ou então em um cluster a nível de sistema.

O OpenVZ é utilizado pelo Virtuozzo[1] uma ferramenta proprietária completa que oferece diversos tipos de virtualização.

[1] http://www.parallels.com/products/pvc46/


________________________________
De: Carlos Ribeiro <[hidden email]>
Para: [hidden email]
Enviadas: Segunda-feira, 29 de Agosto de 2011 11:44
Assunto: Re: [python-brasil] Fwd: Servidor Django sem acesso por Shell


 
2011/8/29 Robson Eisinger <[hidden email]>

> No momento, prefiro centrar em uma maquina só, mesmo que virtualizada, com
> os vhosts, depois devo me preocupar com a virtualização e como seria
> acessado isso, mas até o ip v6 sair de fato, temos sim um limite de IPs
> para
> uso. Limitar o acesso já faz parte, o grande dilema é, como disse, bloquear
> o acesso a shell, o usuario teria que implementar o sitio em outra
> plataforma (de testes), e fazer o upload por sftp (melhor usar o termo
> correto, para não confundir com o velho ftp).
>

Correndo o risco de ficar muito offtopic, tive uma idéia aqui, acho que é
uma alternativa razoável para pensar em termos de arquitetura.

1) Instale as instâncias de Django em VMs separadas, mas usando IPs
privativos.

2) Instale um proxy reverso no seu único IP público, que possa fazer o
redirecionamento interno usando o nome de domínio.

Esta proposta tem algumas vantagens:

- Mais segurança, pois os servidores não ficam diretamente expostos.
- Possibilidade de criar mecanismos de caching mais eficientes.
- Se eu não tiver esquecido nada, a URL não precisa ser "reescrita", basta
repassar a mesma URL original para o IP interno.

As desvantagens seriam em termos de overhead, que talvez possa ser
compensada pelo caching no front-end; e algum possível impacto devido aos
endereços privativos, mas que eu realmente acho que não vai ter problema.

Obs: o SSH também precisa ser redirecionado, mas isso pode ser resolvido
também...

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: [hidden email]

[As partes desta mensagem que não continham texto foram removidas]


 

[As partes desta mensagem que não continham texto foram removidas]