Arquivo problemas de permissão (UID: 99)
Atenção esta informação pode estar desatualizada. Por favor, consulte o fórum para adquirir RevMax ajuda e instruções. http://www.openxpayments.com .
Chegou ao meu conhecimento que algum host parecer um pouco fora datado e talvez um pouco inseguro como usuários por arquivos e permissões. Ainda estou pesquisando isso sozinho e à procura de uma solução que pudesse possível encaixar todo o exército. Até então se você encontrar problemas de permissões de arquivos espero que isso ajude.
Php instalação padrão como módulo mod_php é um buraco maior segurança na web software servidores.
Vamos considerar o porquê. Se você tiver o PHP instalado como mod_php então todos os aplicativos são executados em php 'nobody' usuário comum ou 'www' ou 'apache'. Isso significa que se 'Smith' um usuário tem arquivos localizados em seu diretório home, todo mundo que tem uma conta no mesmo servidor pode ler (e modificar) os seus arquivos usando o gerenciador de arquivos baseado em PHP regular.Para evitar esse problema apache fornece tecnologia 'suexec' para executar o software dos usuários em suas contas do próprio sistema. Significa 'smith' usuário tem 'my_secure_data.txt' chowned para 'Smith' e ele vai trabalhar porque suas aplicações são executadas sob a conta 'Smith' sistema em ambiente suexec. Basicamente, a tecnologia suexec é fornecida para aplicativos executados como scripts CGI.
Em não-suPHP ambiente de servidor, se um script php tem que enviar um arquivo em uma pasta, (por exemplo: plugins OpenX), a fim de obtê-lo carregado para a pasta, ele precisa ter permissões globais graváveis (777).
Como plugins são carregados pelo php, Não-suPHP ambiente de servidor é normalmente atribuído ID de usuário de 99. Isso fará com que todos os arquivos php enviados não devem ser propriedade do usuário ftp e incapaz de alterar as permissões, ou excluí-los.
O PROBLEMA: Por conveniência RevMax define todos os diretórios (755) e arquivo (644) permissões de instalação e pode causar erros Você deve, contudo, definir manualmente as permissões para os clientes da pasta / openx / clientes, após o upload..
Você pode testar o seu servidor para esta questão. Se você pode usar phpinfo () você pode criar um arquivo php com o seguinte conteúdo:
( ) ; ?> <? Phpinfo ();?>
Enviá-lo para uma pasta da Web acessível no servidor e procure por ele em um navegador, em seguida, procure onde diz Server API. Se o valor diz Apache, então, não a sua execução PHP usando suPHP. Se ele diz CGI, então ele está sendo executado suPHP.
Se você conhece ou pode ver este (uid: 99) para ser o problema, você pode chown todas as pastas e arquivos do pacote, e chmod conforme necessário. para restaurar a funcionalidade. Aqui estão algumas informações mais sobre "chown" e comandos do shell que podem ajudar.
Se você saber isso antes de instalar você pode descompactar o pacote e fazer o upload dos arquivos com ftp e definir permissões em conformidade, em seguida, fazer login para OpenX e instalar o plugin. Você deve então ter a propriedade de todos os arquivos e pastas do plugin RevMax. Arquivos do plugin e pastas devem ser enviados para o diretório OpenX como pode ser visto no pacote descompactado.
OpenX / clientes ....
openx / plugins / etc ....
openx / www / admin / plugins ...
Para corrigir esse problema permanentemente, você pode querer seguir este link e proteger o servidor e instalar o módulo suPHP para apache. Isto, claro, fazer você passar por todos os plugins e propriedade do arquivo de reset e permissões como eles são criados na instalação com php e causará erros como visto na instalação openxmarket em um servidor cpanel.
Eu estou trabalhando atualmente em script para verificar se há variações de servidor, e espero corrigir esse problema para estes ambientes.
Como sempre, você pode me contactar diretamente ou enviar para o fórum se você tiver dúvidas ou precisar de ajuda.
















