Issue #16
Permission denied in /var/lib/mailmain/archieves
Ao tentar criar uma lista no Beta, ocorria um erro de permissão, no link abaixo o log do erro:
http://paste.debian.net/180516/
Onde não era possível criar o link simbólico do public para o private. O diretório /var/lib/mailman/archieves tem como dono root:mailman.
Ao alterar o dono do diretório para mailman:mailman volta a ocorrer normalmente a criação dos links e consequentemente a criação de novas listas. Acredito que talvez o processo esteja sendo executado pelo usuário nginx e não o mailman, adicionando o grupo mailman o usuário nginx passa a ter permissão, já que o mesmo faz parte do grupo mailman.
Deve-se investigar se realmente é necessário a alteração na permissão do diretório ou se existe algum outro problema por trás.
Obs.: O binário check_perms não encontrou problemas de permissão em nenhum momento dos testes (antes e depois da alteração das permissoes)
-
Bom dia @kanashiro, obrigado pela descrição detalhada. Vou descrever como temos isso implementado pra servir de referência posterior.
Temos dois principais processos rodando para servir a parte Web do Mailman o
fcgi
e onginx
. Ofcgi
é responsável por servir/modificar o conteúdo dinâmico do mailman enquanto onginx
é responsável pela parte estática. O nginx roda com usernginx
groupnginx
e ofcgi
com usermailman
e groupapache
.apache
?! Sim,apache
.Pode parecer estranho (e na verdade é) mas o mailman 2 precisa ser compilado com uma flag dizendo com qual grupo o processo Web dele será executado. Como estamos utilizando um pacote pronto que já veio compilado com o grupo
apache
nós teríamos duas saídas: recompilar o mailman e gerar nosso pacote ou trabalhar com esse grupoapache
. Até o momento estamos trabalhando com a segunda opção. Isso pode ser visto no arquivo de configuração do fcgi.Ao executar o processo do
fcgi
commailman:apache
tínhamos um problema de que onginx
não conseguia acessar os dados gerados por ele. Por isso colocamos o usuárionginx
no grupomailman
. Isso foi feito no commit d3e49a24.Agora o problema que estamos tendo é novo porém relacionado. Aparentemente o
nginx
também precisa escrever nas pastas de archives (precisamos entender através de que chamada e em que momento) e por isso estamos tendo este problema. Colocar o nginx no grupo do mailman me parece uma solução coerente com o caminho que estamos seguindo mas isso teoricamente já foi feito em 2272ba4e. Notem que a forma correta de adicionar um usuário à um grupo usando o chef é utilizando o resourcegroup
ao invés deexecute
.Eu dividiria a resolução deste bug em duas partes:
1- Entender como o
nginx
está tentando criar o link. Através de fcgi? cgi puro? Qual o user:group que está sendo usado no processo? (aparentemente o user énginx
).2- Corrigir o commit anônimo do 2272ba4e e entender porque ele não funciona.
-
comentando aqui só pra receber as novidades desse bug ;-)
-
Milestone changed to Checklist/bugfixes c/ testes passando
-
Tentei reporduzir este problema e não ocorreu nenhum problema na criação de listas utilizando a master e destruindo uma instancia da vm e subindo sem modificações.Conversando com o sergio estamos fechando esta issue, mas caso o problema apareça novamente esta será reaberta.
-
Status changed to closed