existe uma extensão do sistema para / etc / services que não seja substituída nas atualizações de pacotes?

Question

Eu sei como usar /etc/services , mas se eu alterá-lo e o pacote inetd for atualizado posteriormente via apt-get para um novo padrão, minhas alterações desaparecerão (aconteceu comigo em um apt-get dist-upgrade do Debian Wheezy para Jessie). Eles são salvos em um backup, mas eu ainda tenho que reintegrar minhas alterações ou alternativamente perder os novos padrões do gerenciador de pacotes (ignorando a instalação da nova versão padrão).

Existe uma maneira de ter uma "extensão" do sistema gerada pelo usuário para /etc/services que também é carregada e contém apenas minhas alterações para que a configuração não seja destruída com uma atualização de pacote?

Estou trabalhando no Debian Jessie, se for relevante.

    

Answer 1

/etc/services é um conffile , então, se você modificá-lo localmente e uma nova versão do pacote for instalada com uma versão modificada, o dpkg perguntará se você deve manter sua versão ou instalar a nova. Infelizmente, isso não lhe dará uma maneira fácil de mesclar suas alterações.

Você pode desviar o pacote fornecido por /etc/services e fornecer o seu próprio.

dpkg-divert --add --local --rename --divert /etc/services.debian /etc/services

Se você quiser concatenar suas próprias entradas ou transformar o arquivo Debian, você pode executar um script de gancho quando o APT terminar seu trabalho. Declare o script em /etc/apt/apt.conf.d/local-etc-merge

DPkg::Post-Invoke {"cat /etc/services.local /etc/services.debian >/etc/services"}

Como alternativa, você pode tornar /etc/services invocar um comando quando lido (isso é um exagero, a menos que você modifique /etc/services.local com muita frequência).

    

Answer 2

Isso parece surgir de tempos em tempos em vários bugtrackers: Debian # 46049 , Debian # 711001 , RH # 133683 . Mas nada disso parece ser implementado.

Para recapitular: o Interruptor de serviço de nome lê /etc/nsswitch.conf onde procurar, por exemplo, services informação:

$ strace -f -e open,stat getent services > /dev/null
[...]
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libnss_db.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libdb-5.3.so", O_RDONLY|O_CLOEXEC) = 3
open("/var/lib/misc/DB_CONFIG", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/var/lib/misc/services.db", 0x7ffd79d77060) = -1 ENOENT (No such file or directory)
open("/etc/services", O_RDONLY|O_CLOEXEC) = 3
+++ exited with 0 +++

Esse libnss_db.so.2 só pôde ser encontrado porque eu instalei libnss-db mais cedo. Assim, se alguém conseguir criar um banco de dados Berkeley DB em /var/lib/misc/services.db com nomes de serviço adicionais, isso pode funcionar .

Atualização: com libnss-db (Debian / instável aqui), isso é realmente possível:

$ grep ^[A-Z] /etc/default/libnss-db 
ETC = /etc/local
DBS = services
VAR_DB = /var/lib/misc
AWK = awk
MAKEDB = makedb --quiet

$ cat /etc/local/services
# Local services
foobar          1234/tcp                        # Foo
barbaz          4321/udp

$ make
services... done.

$ getent services | wc -l
559

$ getent services foobar barbaz
foobar                1234/tcp
barbaz                4321/udp

E como /etc/local é não um diretório de configuração registrado , não deve ser tocado por qualquer processo de atualização

Caso contrário, esses nomes de caminho parecem ser codificados e só podem ser alterados / estendidos em uma recompilação, por isso os tickets listados acima.

$ strings /lib/x86_64-linux-gnu/libnss_files.so.2 | grep services /etc/services

Observação: há também um pacote libnss-extrausers , que parece fornecer arquivos adicionais para o NSS, mas apenas para passwd , shadow e group information.

    

Answer 3

Infelizmente, não há como fazer isso. Uma opção seria "Manter" o pacote netbase para que ele não seja atualizado automaticamente.

echo "netbase hold" | dpkg --set-selections

Outra opção pode ser declarar um /etc/services.local e enviar um patch ao mantenedor netbase que mesclou esse arquivo e seu próprio /etc/services . Não vejo que isso seja muito difícil, exceto que uma classificação / mesclagem modificada seria necessária para entender as linhas de comentário # .