ldconfig criando o symlink incorreto

Question

Instalei o Bacula 7.4.4 em um sistema openSUSE Leap 42.3 do repositório link recomendado no link . Esses pacotes usam o mecanismo de alternativas do openSUSE para configurar DMBS para usar no catálogo - no meu caso, MySQL. Infelizmente, o pacote é um pouco buggy. Após a instalação do bacula-diretor e pacotes bacula-mysql, os links simbólicos para a biblioteca libbaccats em / usr / lib64 se parece com isso:

libbaccats.so -> /etc/alternatives/libbaccats.so
libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so
libbaccats-stub.so -> libbaccats-7.4.4.so
libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so

Os dois últimos são obviamente absurdos e causam qualquer tentativa de executar o diretor ou o utilitário dbcheck para falhar com a mensagem de erro:

Fatal error: Please replace this null libbaccats library with a proper one.

É claro que isso é facilmente corrigido emitindo os comandos:

ln -sf libbaccats-stub-7.4.4.so libbaccats-stub.so
ln -sf /etc/alternatives/libbaccats-7.4.4.so libbaccats-7.4.4.so

para produzir o resultado desejado:

libbaccats.so -> /etc/alternatives/libbaccats.so
libbaccats-7.4.4.so -> /etc/alternatives/libbaccats-7.4.4.so
libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so
libbaccats-stub.so -> libbaccats-stub-7.4.4.so

que permite os links simbólicos em / etc / alternatives:

libbaccats.so -> /usr/lib64/libbaccats-mysql.so
libbaccats-7.4.4.so -> /usr/lib64/libbaccats-mysql-7.4.4.so

para direcionar corretamente as referências de libbaccats para a variante do MySQL.

No entanto, cada vez que o comando ldconfig(8) é executado, ele redefine o link simbólico /usr/lib64/libbaccats-7.4.4.so para apontar para libbaccats-stub-7.4.4.so novamente, quebrando Bacula. Como ldconfig é executado automaticamente pelo sistema em várias ocasiões, isso é muito irritante.

O mesmo problema existe com o Bacula 9.0.6 do repositório link .

Como posso corrigir a ideia de ldconfig onde esse link simbólico deve apontar?

    

Answer 1

De acordo com minha pesquisa, o (des) comportamento de ldconfig é acionado pelo conteúdo do arquivo libbaccats-stub-9.0.6.so , especificamente seu SONAME field:

ts@xenon:~> objdump -p /usr/lib64/libbaccats-stub-9.0.6.so

/usr/lib64/libbaccats-stub-9.0.6.so:     file format elf64-x86-64
[...]
Dynamic Section:
  NEEDED               libc.so.6
  SONAME               libbaccats-9.0.6.so

Aparentemente, esse cabeçalho diz ldconfig para criar um link simbólico com esse nome.

Prova: se eu renomear libbaccats-stub-9.0.6.so para libbaccats-stub-9.0.6.so.BAD , então ldconfig criará um link simbólico

libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so.BAD

e se eu comprimir libbaccats-stub-9.0.6.so com gzip , então ldconfig reclama

ldconfig: /usr/lib64/libbaccats-stub-9.0.6.so.gz is not an ELF file - it has the wrong magic bytes at the start.

e deixa meu symlink libbaccats-7.4.4.so sozinho.

Portanto, embora eu não tenha encontrado uma maneira de fazer o ldconfig criar o symlink correto, há pelo menos uma maneira de impedir que ele crie o erro errado: delete, comprima ou manipule o arquivo /usr/lib64/libbaccats-stub-9.0.6.so .

É claro que a solução real seria definir o campo SONAME em libbaccats-stub-9.0.6.so corretamente, mas isso teria que acontecer no processo de compilação do pacote bacula-director .