5

I have installed Bacula 7.4.4 on an openSUSE Leap 42.3 System from the repository https://build.opensuse.org/package/show/home%3AXimi1970%3AopenSUSE%3AExtra/bacula recommended on https://software.opensuse.org/package/bacula. Those packages use openSUSE's alternatives mechanism to configure the DMBS to use for the catalog - in my case, MySQL. Unfortunately, the package is a bit buggy. After installation of the bacula-director and bacula-mysql packages, the symlinks for the libbaccats library in /usr/lib64 look like this:

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

The last two are obviously nonsense and cause any attempts to run the director or the dbcheck utility to fail with the error message:

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

This is of course easily fixed by issuing the commands:

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

to produce the desired result:

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

which allows the symlinks in /etc/alternatives:

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

to correctly direct libbaccats references to the MySQL variant.

However, each time the ldconfig(8) command is run it resets the /usr/lib64/libbaccats-7.4.4.so symlink to point to libbaccats-stub-7.4.4.so again, breaking Bacula. Since ldconfig is run automatically by the system on various occasions this is pretty annoying.

The same problem exists with Bacula 9.0.6 from the repository https://download.opensuse.org/repositories/home:/cristyde/openSUSE_Leap_42.3/.

How can I fix ldconfig's idea where that symlink should point?

Tilman Schmidt
  • 3,778
  • 10
  • 23
  • Did you try to symlink the files into `/usr/local/lib64`? That palce is intended for doing stuff without affecting the standard paths and should be skipped by `ldconfig`. – Thomas Dec 24 '17 at 15:52
  • No, I didn't try anything involving `/usr/local`. What exactly do you propose? Which symlinks should I place in `/usr/local/lib64`? Should I remove any or all of the symlinks in `/usr/lib64`? – Tilman Schmidt Dec 25 '17 at 00:10

1 Answers1

2

According to my research, the (mis-)behaviour of ldconfig is triggered by the content of the file libbaccats-stub-9.0.6.so, specifically its 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

Apparently that header tells ldconfig to create a symlink with that name.

Proof: If I rename libbaccats-stub-9.0.6.so to libbaccats-stub-9.0.6.so.BAD then ldconfig duly creates a symlink

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

and if I compress libbaccats-stub-9.0.6.so with gzip instead then ldconfig complains

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

and leaves my libbaccats-7.4.4.so symlink alone.

So while I haven't found a way to make ldconfig create the correct symlink, there's at least a way to prevent it from recreating the wrong one: delete, compress or otherwise mangle the file /usr/lib64/libbaccats-stub-9.0.6.so.

Of course the real solution would be to set the SONAME field in libbaccats-stub-9.0.6.so correctly, but that would have to happen in the build process of the bacula-director package.

Tilman Schmidt
  • 3,778
  • 10
  • 23