Práticas recomendadas para configurar o ambiente de desenvolvimento do LAMP

5

Estou tendo um pesadelo para criar um ambiente decente para desenvolver o Wordpress em uma máquina local.

  1. Estou constantemente aprimorando manualmente as permissões de arquivo sempre que adiciono um plug-in.
  2. Não consigo instalar temas ou plug-ins através da interface do Wordpress.
  3. Eu preciso manter sudo -ing toda vez que eu precisar modificar o conteúdo da pasta do site em que estou trabalhando (arquivos de tema, etc.)
  4. Eu tentei usar o XAMPP, que vem com uma configuração de FTP integrada, mas todos os arquivos enviados por meio da interface da Web recebem as permissões do usuário nobody .

Quais são algumas das melhores práticas para configurar um ambiente LAMP decente que simula - pelo menos parcialmente - a conveniência de um ambiente hospedado?

Eu acho que pode começar com a modificação da configuração do apache para apontar para uma pasta de desenvolvimento na minha pasta ~/ , mas tive problemas terríveis com permissões lá.

Para o registro, estou executando o Xubuntu 9.10 em um sistema e o Ubuntu-netbook 9.10 no outro.

Algum conselho ou guia para o qual eu possa me referir?

[editar] Eu não sou totalmente contra o uso de uma VM (como visto aqui , mas apenas como último recurso, o netbook provavelmente não é poderoso o suficiente, e eu geralmente me refiro ao trabalho em uma cópia local das coisas. [/ edit]

    
por Jono 20.03.2017 / 11:17

5 respostas

1

Parece que o seu apache (e, portanto, o XAMPP) está sendo executado como usuário 'nobody', enquanto sua instalação do Wordpress é de propriedade do seu ID de usuário de login. Eu estou supondo que é um servidor de desenvolvimento não acessível pela Internet, em cujo caso a coisa mais fácil é mudar o usuário run-as do httpd.conf do apache para o seu ID de usuário de login.

Melhor prática seria instalar suPHP ou suexec, mas configurá-los é um pouco mais difícil do que o acima.

    
por 15.01.2010 / 13:28
1

Para começar, não é uma boa ideia colocar tudo em / var / www e apontar o navegador para o link . Por um lado, complica as coisas quando você se muda para um novo servidor mais tarde. É melhor criar um host virtual no seu computador, criando um novo arquivo chamado somesite (o nome do seu site) em

/etc/apache2/conf/sites-available/

Crie um VirtualHost para o URL completo. Dessa forma, quando você migra um banco de dados wordpress, não precisa editar o endereço do site. Em nosso exemplo, seria um host virtual para www.somesite.com.

Veja um exemplo desse arquivo:

<VirtualHost somesite:80>
ServerAdmin username@localhost
ServerName somesite
DocumentRoot /var/www/somesite
<Directory />
    AllowOverride All
    Options FollowSymLinks
</Directory>

ErrorLog /var/log/apache2/error.log

LogLevel debug

</VirtualHost>

Em seguida, execute os seguintes comandos:

$ sudo a2ensite somesite
$ sudo /etc/init.d/apache2 reload

Você também precisará atualizar seu arquivo /etc/hosts alterando a primeira linha de

127.0.0.1    localhost

para

127.0.0.1    localhost, somesite, www.somesite.com

mas depois me deparo com um problema:

Gostaria de colocar os arquivos em minha pasta pessoal, onde tenho permissões completas, em vez de colocá-los em / var / www. Desta forma, eu não tenho que sudo toda vez que eu quero fazer algo, nem arrisco atrapalhar o sistema quando eu faço. Eu também posso trabalhar com o SVN mais facilmente.

Mas se eu criar essa configuração, quando eu apontar o navegador para http://www.somesite.com/ , acabo recebendo um erro 403, sem permissões.

Mesmo quando eu defino a pasta somesite inteira para as permissões 777, ainda recebo esse erro. O que mais eu deveria estar fazendo?

    
por 17.01.2010 / 11:47
1

Eu usaria uma VM e usaria a mesma distribuição que o host de destino usará. Isso poderia eliminar muitas frustrações depois. No que diz respeito à VM e ao netbook, achei que o ponto principal do "NETbook" era que o armazenamento local era apenas um cache, e a maior parte do trabalho deveria ser feito remotamente na "nuvem".

Você pode encontrar um antigo desktop batedor para configurar como um host temporário e desenvolvê-lo. Se você fizer seu site funcionar lá, movê-lo para um host só melhorará o desempenho, e se você estiver usando hospedagem compartilhada (a maioria das pessoas o faz), os resultados da máquina antiga corresponderão mais ao que você pode esperar do seu serviço de hospedagem de qualquer maneira.

    
por 22.01.2010 / 21:19
0

Parece que você está descompactando os suplementos como a si mesmo, e então tem que chmod-los para o usuário que o apache está rodando. Isso é normal, não se preocupe com isso.

A questão é que você está usando o apache como um usuário com poucos privilégios que só tem permissões para algumas coisas, como acessar apenas seus arquivos e nenhum deles no seu diretório pessoal (porque você d ficar chateado se Sam Hacker pudesse baixar seus arquivos privados). Seja qual for o diretório em que você esteja executando seus sites, ele precisa ser legível (e gravável em alguns casos) pelo usuário do Apache.

Isso permitirá que você instale plugins dentro do Wordpress - já que ele (isto é, o Apache) terá acesso de gravação aos diretórios de que precisa. Seu usuário de FTP será configurado corretamente, já que ninguém é o uso que o rapache executa como em algumas distros.

Agora, para tornar as coisas um pouco mais fáceis para você, adicione seu usuário ao grupo wheel para que você possa su, execute uma carga de comandos e faça logout para o usuário normal.

    
por 22.01.2010 / 23:47
0

(Isto é específico para querer um ambiente de desenvolvimento Wordpress , não funcionaria como um sistema LAMP genérico).

Experimente as VMs do wordpress bitnami pré-construídas. Eles são executados no VirtualBox e no VMWare. link

Você tem que ser um pouco cuidadoso para não acabar com uma instalação do Bitnami LAMP em sua máquina, o download parece quase o mesmo.

Quando a VM estiver ativa, você pode fazer a maior parte do seu trabalho através do wordpress gui. Você também pode personalizar via criança theme-ing (requer um editor em sua máquina local e, em seguida, fechando-se). Se necessário, você pode configurar um login SSH para a VM.

Eu configurei duas VMs para testar o fluxo de trabalho de preparação / produção (gravar configuração / conteúdo no teste, exportar para prod). Muito melhor do que mexer no cpanel do meu provedor de hospedagem.

Não muitas surpresas até agora. Gostando disso.

    
por 12.09.2017 / 04:39