Atualmente, tenho um servidor Ubuntu básico executando um site. O site é para alguns alunos que aprendem HTML / PHP e cada aluno tem sua própria conta com um link simbólico para a pasta do site compartilhado. Como os alunos estão trabalhando juntos no site, cada usuário precisa poder modificar todos os arquivos (index.html, por exemplo). Então eu criei um grupo Webdev contendo todos os alunos com o umask padrão de 0002 definido em seus .bashrc (Isso permite que arquivos recém-criados sejam 774). A pasta compartilhada pertence ao grupo Webdev com um chmod g + s para que novos arquivos / pastas também pertençam ao grupo Webdev.
O problema é que os alunos estão usando um IDE (Coda 2) e quando criam um novo arquivo ou pasta usando o IDE, o arquivo tem as permissões do 644 no servidor (não pode ser escrito em grupo). No entanto, quando eu faço um novo arquivo através da conexão com o Cyberduck (cliente SFTP), as permissões de arquivo são 664 (como deveriam ser). Então eu não entendo porque Coda seria diferente.
No entanto, após algumas tentativas e erros, acredito que o Coda primeiro crie o arquivo no disco local e, em seguida, carregue esse arquivo no servidor. Em um mac por padrão, um arquivo recém-criado é 644. Quando o cliente faz upload de um arquivo que já é 644, ele fica 644 no lado do servidor (umask é inútil nessa situação). Eu também tentei criar permissões de ACL para essa pasta, mas um arquivo enviado do meu mac via SCP não obtém as permissões de ACL padrão.
No Coda há uma opção para alterar as permissões de arquivo em uma transferência. No entanto, esta opção parece aplicar um chmod a todos os arquivos que estão sendo carregados ou salvos. Quando um dos alunos está modificando um arquivo criado por outra pessoa quando ele tenta fazer o upload do arquivo ou salvá-lo, o Coda tenta também fazer um chmod, mas falha porque esse usuário não é o proprietário do arquivo.
Minha solução atual está usando bindfs ... Eu montei a pasta compartilhada da web e as permissões de conjuntos de bindfs e a propriedade de grupo de arquivos recém-criados. No entanto, bindfs parece ser um pouco lento e tenho certeza que existe uma solução melhor.
Mesmo se os alunos abandonassem o Coda 2 e usassem o Mac vim com scp, os arquivos recém-criados no servidor se comportariam da mesma forma (644), que é o padrão no mac.
Outras opções ...
1) Ou eu ensino os alunos a usar (ssh / chmod) com seu IDE para alterar suas próprias permissões de arquivo ao fazer o upload.
2) Eu faço todos os Macs dos alunos tem umask padrão de 0002, que faria o upload de arquivos com as permissões certas.
3) Escreva um script de milho para corrigir as permissões de arquivo a cada 5 a 15 minutos ... (Essa opção é a pior, se os alunos estiverem trabalhando juntos ao mesmo tempo).
Existe alguma maneira que eu poderia fazer todos os arquivos que são enviados via SCP têm as permissões de arquivo padrão de 664, embora o arquivo enviado tenha uma permissão menor? (Depois de horas de pesquisa eu não acho que isso é possível) Eu acho que um script de milho é a minha melhor opção para usuários iniciantes. Como os desenvolvedores da Web trabalham juntos em sites maiores?
semelhante a isto: link
Também similar: link