Ao trabalhar com código-fonte (por exemplo, um projeto python) que precisa ser acessado por vários usuários, existe um local padrão para manter esses projetos?
Eu encontrei esta resposta que sugere /usr/local/ para a instalação de aplicativos, mas não tenho certeza se esse seria um local apropriado manter o código fonte para programar projetos em andamento.
Não há um diretório padrão atribuído no FHS para essa finalidade, mas você pode criar um subdiretório em /opt . Basta atribuir o modo 770 e colocar os usuários no grupo apropriado.
No entanto, eu altamente recomendo que, para esse tipo de atividade, você instale um sistema de controle de revisão, como git . Dessa forma, o git cuidará do repositório de origem e cada desenvolvedor trabalhará em seu repositório privado em seu homedir.
A resposta que você se refere a discutir sobre a instalação de um programa, não o compartilhamento de dados entre usuários. Não importa se esses dados são arquivos do Excel, uma grande coleção de filmes ou código-fonte que está sendo desenvolvido localmente, ele nunca deve ser colocado em lugar nenhum em /usr . O mesmo vale para /opt .
Diretórios /usr , /opt e /var todos têm uso semântico bem definido, definido em um nome de documento o Filesystem Hierarchy Standard (ou FHS para abreviar). A versão mais recente está hospedada lá: link . Respeitar essa semântica é importante porque seu sistema operacional (ou, para ser mais específico, vários programas incluídos em sua distribuição Linux, bem como outros programas que você pode instalar por conta própria) tem um comportamento específico em relação ao uso desses diretórios. Por exemplo, se você criar um subdiretório em /usr/share
e acontece que o nome daquele diretório está em conflito com o nome de um programa que você tenta instalar mais tarde, então é possível que o instalador sobrescreva, altere, renomeie ou apague o conteúdo daquele diretório. Se isso facilitar a perspectiva, considere que colocar os arquivos de dados de sua equipe em /usr ou /opt seria comparável a armazená-los em C:\Windows\ ou C:\Program Files em um computador baseado no Windows.
Uma coisa a ser observada é que o FHS aborda questões em que os canais de arquivos precisam ser coordenados entre várias partes, como sites locais, distribuições, aplicativos, documentação, etc. . O FHS não tenta definir regras para cada situação que você possa ter: a colocação local de arquivos locais é um problema local (FHS, seção 1.1).
Então, voltando à sua pergunta original, vamos considerar algumas opções aceitáveis:
/home/<projectname> ou /home/<someprefix>/<projectname> - O FHS diz: /home é um conceito bastante padrão, mas é claramente um sistema de arquivos específico do site . Não há absolutamente nenhum requisito de que cada diretório em /home seja o nome de um usuário real; A criação de subdiretórios para grupos ou projetos é, portanto, aceitável, embora isso exija algumas precauções manuais para evitar eventuais conflitos, caso um novo usuário seja criado, cujo nome corresponda ao nome de um projeto existente.
/srv/<projectname> ou /srv/<someprefix>/<projectname> - De acordo com o FHS, /srv contém dados específicos do site que são servidos por este sistema . A FHS então continua explicando que a metodologia usada para nomear subdiretórios de / srv não é especificada , e dá um exemplo incluindo /srv/compsci/cvs (que é provavelmente o próprio repositório CVS para o compsci grupo de trabalho). Pela minha experiência pessoal, a maioria dos administradores que exploram o diretório /srv
continua com um subdiretório por cliente, por site ou por projeto (ou, em algum momento, subdiretórios por cliente e depois por projeto) e, em seguida, coloca diretórios de dados nesse nível.
/<someprefix>/<projectname> ou /media/<volumename>/<someprefix><projectname> - Eu sinceramente não sei porque essa opção é raramente mencionada no mundo Linux, mas vamos deixar isso claro: este é realmente o seu sistema, e o FHS diz que você é livre para criar novos diretórios no nível da raiz, desde que você não entre em conflito com nada para o qual tenha semânticas bem estabelecidas. Você poderia, por exemplo, criar um diretório /projects ou /team e organizar os arquivos como achar melhor. Eu sei que alguns administradores preferem que estes sejam um pouco isolados do resto do sistema de arquivos, então monte um volume distinto (abaixo de /media/volumename ). De volta à analogia do Windows, isso seria semelhante a criar um novo diretório diretamente sob C:\ ou a configurar um volume distinto, digamos D:\ ; ambas as estratégias devem ser aceitáveis para a maioria dos administradores (embora com preferências variadas em relação a uma ou outra dessas opções).
Quanto a mim, minha preferência vai para uma estrutura /srv/<client>/<project>/ em todos os servidores da minha empresa, porque facilita a localização de todos os serviços de um determinado projeto. Dentro de um desses diretórios, geralmente terei subdiretórios orientados a serviços e orientados a funções; por exemplo, eu posso ter etc , htdocs , logs , git ... O diretório git é subdividido no nome do repositório git (isto é, eu posso ter vários repositórios git para um projeto).
Tags directory-structure