Estamos ficando cada vez mais desenvolvedores externos (de clientes diferentes) e estamos começando a precisar de uma estratégia melhor do que adhoc adicionando ao nosso servidor e adicionando a eles nosso grupo de empresas (que possui tudo em / var / www / - nosso espaço de trabalho)
A solução ideal seria a capacidade de aninhar grupos, de modo que, se eu pudesse @sua empresa, todos seriam membros do grupo @nossaempresa.
ourcompany: xxx: joão, joe, bob guestcompany: xxx: guest1, guest2, @ ourcompany
Mas isso não é possível. Eu estou brincando com a idéia de ter um sistema de template, onde eu faço algumas coisas simples de sed para obter um substituto e criar um novo / etc / group
(A razão pela qual eu não quero guestcompany: xxx: guest1, guest2, joão, joe, bob é porque se adicionarmos ou removermos pessoas de nossa empresa do que alguém terá que passar e garantir que tudo esteja atualizado, o que provavelmente poderia cair da borda)
Eu acho que o próximo passo lógico é ACLs, mas da minha experiência passada é que eles são um pouco incômodo para lidar, então eu só queria ver se algum de vocês sabia que quaisquer outras soluções que funcionariam.
Não estou sugerindo que você faça dessa maneira, mas resolvi esse problema usando o Active Directory para gerenciar minha autenticação centralizada e implementei o Likewise Open para autenticar minhas máquinas Linux. O LWO fornece um UID e um GID consistentes em todas as máquinas porque são baseados em um hash. Isso faz coisas como o NFS e o rsync serem muito fáceis de lidar. Também resolve bem grupos aninhados.
Você está usando algum tipo de autenticação centralizada como NIS ou LDAP?
Eu recomendaria o uso de trustees do Linux . Ele é inspirado pelos curadores da Novell há muito tempo, e é (imho) superior a qualquer outra coisa que eu já vi.
Sem entrar em muitos detalhes, você tem um único arquivo de configuração para manter; Tentando usar ACLs e tal, sua visibilidade não é tão grande quanto você precisa consultar arquivos individualmente.
Com os trustees do Linux, você também pode optar por AND com permissões do Unix ou ignorá-las todas juntas.
A única desvantagem é que é um módulo do kernel (o que em si não é uma coisa ruim), mas você provavelmente precisará recompilar o kernel com o suporte apropriado (conforme os documentos de trustees). Novamente, isso não é um problema, mas se você tiver suporte, por exemplo, da Red Hat, recompilar / modificar o kernel não seria uma opção.
Eu não lhes daria acesso ao seu espaço de trabalho. Eu os configuraria com acesso a um repositório git ou subversion e, em seguida, colocaria as alterações no sistema para implantação. Você pode fazer o script de um servidor de teste para atualizar de seu repositório periodicamente para que as alterações possam ser testadas sem intervenção do desenvolvedor.
Eu sei que o ACL pode ser um problema. Eu os evito sempre que não os exijo explicitamente. Mas na sua situação eles parecem ser a melhor opção.
Eu faria o LWO se ... você já tem um Windows AD e muitas máquinas em potencial que precisam de permissões dessa maneira.
Talvez seja a hora de usar o sistema centralizado, como o LDAP? Eu gostaria de sugerir FreeIPA: muito flexível, boa interface do usuário, muitos recursos. E isso simplesmente funciona.
Tags permissions groups unix