☰

Quando foi introduzido o conceito de usar /etc/*.d/ como mecanismo de configuração no Linux e como é chamado?

tag-icon • tag-icon linux
Quando foi introduzido o conceito de usar /etc/*.d/ como mecanismo de configuração no Linux e como é chamado?

Esta é uma pergunta super básica, mas uma daquelas coisas que é difícil para o Google. Parece que a configuração /etc/*.dnão é suportada em todos os kernels do Linux. Gostaria de entender, primeiro, como me referir adequadamente ao .dparadigma e, segundo, (provavelmente além do escopo deste site) a história por trás dele e por que diferentes estratégias de configuração foram escolhidas.

Obrigado.

Responder1

Esta é aparentemente uma pergunta muito comum. Pelo que eu sei, o seu é o primeiro no Stack Exchange a perguntar sobre os benefícios e/ou histórico, em vez de apenas perguntar o que isso significa, então responderei aqui diretamente.

Então .dsignifica apenas "diretório". Pelo que eu sei, isso se tornou uma coisa com o sysvinit, com as pastas /etc/init.d/ou /etc/rc.d. Eles sempre contêm arquivos de configuração separados que são analisados ​​ou invocados por algum outro processo.

Quanto ao motivo pelo qual isso é feito, alguns motivos:

  1. Imagine se o seu processo init fosse controlado por um único arquivo de configuração. Esse arquivo se tornaria grande e pesado. Os serviços da Web nginxusam esse paradigma para incentivar a separação de sites ou vhosts individuais em seus próprios arquivos de configuração. (Esta pasta é chamada sites-availablena maioria dos pacotes Nginx das distros, mas também possui uma conf.dpasta que geralmente se aplica a configurações que se aplicam a todos os lugares)

  2. Separação de segurança (um pouco). Arquivos de configuração separados permitem permissões diferentes em cada arquivo. Se fosse confiável que um usuário modificasse um serviço ou configuração relevante para ele, ele poderia modificar apenas os arquivos aos quais tem direitos, em vez de conceder-lhe os direitos de "um arquivo para governar todos eles"

  3. Facilidade de solução de problemas/reconfiguração. Voltando ao nginx, digamos que você precisava desabilitar um subdomínio específico. Com cada site dividido em seu próprio arquivo de configuração, você pode simplesmente renomear ou remover esse arquivo em vez de entrar em um único arquivo grande e comentar as coisas. O mesmo se aplica ao init - geralmente em sistemas sysv, os scripts de inicialização são colocados e desativados adicionando ou removendo links simbólicos. Isso lida com níveis de execução e assim por diante. Não há necessidade de invocar um editor de texto.

Todos esses benefícios são obtidos com um aumento ínfimo na complexidade.

Terminologia? Não creio que haja algo oficial para esse design, todo mundo apenas os chama de "pastas ponto d".

Algumas leituras adicionais:

informação relacionada