Я установил Bacula 7.4.4 в систему openSUSE Leap 42.3 из репозитория https://build.opensuse.org/package/show/home%3AXimi1970%3AopenSUSE%3AExtra/bacula рекомендуется на https://software.opensuse.org/package/bacula. Эти пакеты используют альтернативный механизм openSUSE для настройки DMBS для использования в каталоге - в моем случае MySQL. К сожалению, пакет немного глючный. После установки пакетов bacula-Director и bacula-mysql символические ссылки на библиотеку libbaccats в / usr / lib64 выглядят следующим образом:
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
Последние два, очевидно, бессмысленны и приводят к сбою любых попыток запустить директор или утилиту dbcheck с сообщением об ошибке:
Неустранимая ошибка: замените эту нулевую библиотеку libbaccats на подходящую.
Это, конечно, легко исправить с помощью команд:
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
для получения желаемого результата:
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
что позволяет использовать символические ссылки в / etc / alternatives:
libbaccats.so -> /usr/lib64/libbaccats-mysql.so
libbaccats-7.4.4.so -> /usr/lib64/libbaccats-mysql-7.4.4.so
чтобы правильно направлять ссылки libbaccats на вариант MySQL.
Однако каждый раз ldconfig(8)
Команда запускается, она сбрасывает символическую ссылку /usr/lib64/libbaccats-7.4.4.so, чтобы снова указывать на libbaccats-stub-7.4.4.so, нарушая Bacula. поскольку ldconfig
автоматически запускается системой в различных случаях, это довольно раздражает.
Та же проблема существует с Bacula 9.0.6 из репозитория https://download.opensuse.org/repositories/home:/cristyde/openSUSE_Leap_42.3/.
Как я могу исправить ldconfig
есть идея, куда должна указывать эта символическая ссылка?
Согласно моим исследованиям, (неправильное) поведение ldconfig
запускается содержание файла libbaccats-stub-9.0.6.so
особенно его SONAME
поле:
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
Очевидно, этот заголовок говорит ldconfig
чтобы создать символическую ссылку с этим именем.
Доказательство: если я переименую libbaccats-stub-9.0.6.so
к libbaccats-stub-9.0.6.so.BAD
затем ldconfig
должным образом создает символическую ссылку
libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so.BAD
и если я сжимаю libbaccats-stub-9.0.6.so
с участием gzip
вместо этого ldconfig
жалуется
ldconfig: /usr/lib64/libbaccats-stub-9.0.6.so.gz не является файлом ELF - у него в начале неправильные магические байты.
и оставляет мой libbaccats-7.4.4.so
только символическая ссылка.
Итак, пока я не нашел способа сделать ldconfig
создать правильную символическую ссылку, есть, по крайней мере, способ предотвратить повторное создание неправильной: удалить, сжать или иным образом изменить файл /usr/lib64/libbaccats-stub-9.0.6.so
.
Конечно настоящий решением было бы установить SONAME
поле в libbaccats-stub-9.0.6.so
правильно, но это должно произойти в процессе сборки bacula-director
пакет.