Eu tive o mesmo problema ao tentar instalar o PHP APC. Segui as instruções na parte inferior deste guia: link sobre como criar um ambiente chrooted.
Espero que isso ajude!
Estou executando o Fedora Linux no MediaTemple usando sua (virtual) caixa virtual Linux. Praticamente uma instalação limpa (Linux ************ 2.6.18-028stab089.1 # 1 SMP Qui Abr 14 13:46:04 MSD 2011 x86_64 x86_64 x86_64 GNU / Linux).
Estou tentando fazer algumas instalações do Pear e preciso que o /tmp seja remontado com a opção exec . Não tem problema, certo? Então eu estou correndo como root e eu só vou para isso:
[root@host ~]# mount -o remount,exec /tmp
mount: permission denied
[root@host ~]#
Bem, isso é bastante inesperado. O suporte do MediaTemple não fornece nenhuma assistência para isso - não está no SLA. Dado que esta é uma configuração bonita de baunilha, talvez alguém tenha uma ideia do que está errado aqui?
EDITAR:
Aqui estão algumas informações adicionais. A execução de mount mostra isso:% [root@host ~]# mount
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
/dev/simfs on /tmp type simfs (rw,noexec,relatime,usrquota,grpquota)
/dev/simfs on /var/tmp type simfs (rw,noexec,relatime,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type tmpfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
[root@host ~]#
O conteúdo de /etc/fstab é:
none /dev/pts devpts rw 0 0
Em seguida, tentei adicionar esta linha a /etc/fstab :
/dev/simfs /tmp simfs rw,exec,relatime,usrquota,grpquota 0 0
Em seguida, a execução de mount /tmp resulta em:
mount: unknown filesystem type 'simfs'
Estou um pouco confuso sobre como simfs está listado quando você executa o mount, mas quando você o adiciona a /etc/fstab ele não é reconhecido. No entanto, isso não parece resolver o meu problema, então eu ainda estou preso. Alguma idéia?
ATUALIZAÇÃO em 25/06/11
@jamiers encontrou uma solução alternativa que o MediaTemple postou (veja abaixo). No entanto, agora estou me perguntando sobre o aspecto mais fundamental deste problema. Por que você não pode remontar o tmp com opções diferentes em um ambiente virtual? Pelo que eu posso dizer, não há nada intrinsecamente restritivo em um ambiente virtual que impeça você de fazer algo assim. Alguém tem uma ideia de porque é esse o caso?
Eu tive o mesmo problema ao tentar instalar o PHP APC. Segui as instruções na parte inferior deste guia: link sobre como criar um ambiente chrooted.
Espero que isso ajude!
Tenha em mente que você está executando o kernel do MediaTemple (e você não pode mudar isso). Pode permitir ou negar o que quiser. Você pode precisar da fonte para o kernel para realmente entender. Talvez seja uma limitação do sistema de arquivos do simfs?
Para montar o tmp sem noexec você precisa remontá-lo do nó Hardware.
Para mais detalhes, consulte a seguinte documentação.
Preâmbulo
desde que eu não posso comentar, deixarei uma resposta. pessoas realmente precisam fazer suas pesquisas sobre o openVZ (entre outras tecnologias ..) antes de postar ...
Eu percebo que essa foi uma pergunta de alguns anos atrás, mas pretendo desambiguar as mentiras sobre o OpenVZ / Virtuozzo e a desinformação sobre a virtualização do sistema operacional ainda propagada hoje em dia
OpenVZ
O openVZ é uma ótima peça de tecnologia, que pode ser usada para uma infinidade de usos. Há muitos usos para a virtualização do sistema operacional, e muitas pessoas se enquadram na categoria de precisar desse nível de simulação ...
é como um Chroot on Steroids, mas com a capacidade de restringir tabelas de processos e separar a utilização de hardware, permitindo sistemas operacionais fluentes dentro de sistemas operacionais: mas com uma camada maior de segurança e privacidade ou isolamento adicional enquanto ainda permite acesso root.
infelizmente, as mesmas mentiras estão espalhadas sobre a função Chroot ... cada uma lhe dirá para usar a virtualização, e que não é um recurso de segurança. na maioria das vezes, isso não é verdade, as acusações de insegurança são totalmente falsas, pois o Chroot é diretamente integrado a uma variedade de softwares populares, geralmente como um recurso de segurança e isolamento potente (quando usado corretamente). )
uma observação importante é que nem todo administrador tem o nível de conhecimento necessário para proteger todos os parâmetros necessários do kernel em um servidor dedicado ou sob virtualização completa do sistema.
isso significa que a implantação do OpenVZ significa que seus clientes terão muito menos superfície de ataque para tentar cobrir e proteger antes de implantar seus aplicativos. um bom anfitrião fará um bom trabalho garantindo esses parâmetros, e isso, por sua vez, é melhor para todos, não só no nó, ou no data center, mas para a internet como um todo ...
Por que não mudar?
"considerando a mudança", como Michael Hampton sugere, para virtualização completa do sistema , por causa de "pequenos problemas desconhecidos" não é não só um exagero ser totalmente desnecessário. este é o sinal de alguém que não entende totalmente o propósito pretendido. simulação completa do sistema inclui tudo, como as bios e interrupções de hardware,
isso significa que você tem menos sobrecarga ao usar o OpenVZ e, portanto, em correlação direta com o que a evidência conclui (isto é, benchmarks), isso normalmente resulta em uma máquina virtual mais rápida, especialmente para alguém com um nível menor de Entendimento sobre * nix, e para não mencionar níveis mais altos de segurança .. (supor que cada usuário com uma máquina virtual entende a segurança do kernel e o patch customizado é incrédulo)
A conversão para uma nova tecnologia sempre será complicada e as tecnologias emergentes no mundo do software livre SEMPRE levarão tempo para serem aperfeiçoadas.
I'm now wondering about the more fundamental aspect of this problem. Why is it that you can't remount tmp with different options in a virtual environment?
Então, qual é o problema?
com isto dito, e para responder sua pergunta , na maioria dos Kernels OpenVZ modernos atualmente, a questão é que os módulos conectáveis dos kernels parecem estar "faltando", especialmente para comandos que dependem diretamente de eles. mas eles ainda estão .
a explicação é simples, em que o openVZ simulou o sistema operacional, e não o kernel. dar acesso de convidado a configurações relacionadas a hardware seria inseguro. você não obtém acesso direto a hardware, dispositivos ou sistemas de arquivos.
isso pode parecer incômodo, mas não é (quando você pega o jeito dele), e a troca entre segurança para novos usuários e usuários experientes terem que entender como contornar (o que um usuário experiente deve saber como fazer de qualquer maneira), sinceramente é modesto. em uma máquina dedicada verdadeiramente segura ou KVM, você desejaria implementar muitos dos títulos da camada do kernel existentes em um contêiner de qualquer maneira
finalmente, o simfs é um dispositivo de sistema de arquivos simulado para uso com o openVZ e não é reconhecido pelo comando mount file-system (AFAIK).
E como corrijo isso?
não tenho certeza se este é o caso para você, mas deve ser resolvido na maioria das versões mais recentes do kernel simplesmente editando
mount --bind -o defaults,exec /tmp /tmp
e na versão do kernel que um dos nós do host usa, eu simplesmente descartei o / dev / simfs dentro do fstab, e mount -a funciona como esperado ...
exemplo:
none /tmp simfs defaults,exec 0 0
Espero que isso ajude alguém.