samba, libidn, and dnf

So, I encountered an interesting mystery.

My system whose sole purpose in life is to run Plex Media Server (plexmediaserver-0.9.15.2.1663-7efd046.x86_64.rpm at the time this issue was encountered) somehow wound up with an utterly broken dnf package manager.  Now, I have experimented with Samba (groan..) on the system recently, and given that Plex has run for a long while without modification prior to this issue, I’m inclined to blame something related to my work with Samba, but I didn’t do anything crazy..

Fortunately, this is the reason I use individual VMs (or jails in FreeBSD) for my services; the establishment of proper security and administrative boundaries, even if solely considered for the sake of risk management, is very important.

Now, I could just revert to my last snapshot of the VM, but let’s see if we can dig our way out of this for the sake of education (and anyone who’s not so fortunate).  It’s not clear what happened here, but I went to install updates prior to loading the new version of Plex Media Server on my Fedora 23 VM, I was met with this:

[root@PlexSystem ~]# dnf upgrade

Traceback (most recent call last):
  File "/usr/bin/dnf", line 56, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.4/site-packages/dnf/__init__.py", line 31, in <module>
    import dnf.base
  File "/usr/lib/python3.4/site-packages/dnf/base.py", line 26, in <module>
    from dnf.comps import CompsQuery
  File "/usr/lib/python3.4/site-packages/dnf/comps.py", line 29, in <module>
    import dnf.util
  File "/usr/lib/python3.4/site-packages/dnf/util.py", line 31, in <module>
    import librepo
  File "/usr/lib64/python3.4/site-packages/librepo/__init__.py", line 1001, in <module>
    import librepo._librepo
ImportError: libidn.so.11: cannot open shared object file: No such file or directory

Well that’s just great.  Nothing like a broken package manager to make your life as a system administrator worse.  So what the hell happened to my libidn.so.11 file?

[root@PlexSystem ~]# locate libidn.so.11
/usr/lib/plexmediaserver/libidn.so.11
/usr/lib64/libidn.so.11
/usr/lib64/libidn.so.11.6.15

Interesting – Plex has its own libidn.so.11 file.  What do those other files look like?

[root@PlexSystem ~]# ll /usr/lib64/libid*
lrwxrwxrwx. 1 root root     17 Jun 17  2015 /usr/lib64/libidn2.so.0 -> libidn2.so.0.0.10
-rwxr-xr-x. 1 root root 225200 Jun 17  2015 /usr/lib64/libidn2.so.0.0.10

Well that ain’t good; no libidn.so.11 files at all.  Not even a broken symlink!  Looks kinda clean-uninstall-ish…  Almost like some package manager gave itself a lobotomy… (but why!?)

Well, let’s see what the package that provides that file looks like on our system using the rpm package manager:

[root@PlexSystem ~]# rpm -q libidn
error: Failed to initialize NSS database

Egad.  Neither dnf nor rpm work, eh?  Man.  Well..maybe we can replace the missing files with symlinks to /usr/lib/plexmediaserver/libidn.so.11?

[root@PlexSystem ~]# ln -s /usr/lib/plexmediaserver/libidn.so.11 /usr/lib64/libidn.so.11
[root@PlexSystem ~]# ln -s /usr/lib/plexmediaserver/libidn.so.11 /usr/lib64/libidn.so.11.6.15
[root@PlexSystem ~]# dnf history

Here, I forgot to capture my output (damn it), but I received another Traceback informing me that libiconv.so.2 was missing, so:

[root@PlexSystem ~]# ln -s /usr/lib/plexmediaserver/libiconv.so.2 /usr/lib64/libiconv.so.2
[root@PlexSystem ~]# dnf history
Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/dnf/yum/sqlutils.py", line 24, in <module>
    import sqlite3 as sqlite
  File "/usr/lib64/python3.4/sqlite3/__init__.py", line 23, in <module>
    from sqlite3.dbapi2 import *
  File "/usr/lib64/python3.4/sqlite3/dbapi2.py", line 27, in <module>
    from _sqlite3 import *
ImportError: /usr/lib64/python3.4/lib-dynload/_sqlite3.cpython-34m.so: undefined symbol: sqlite3_transfer_bindings

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/dnf", line 57, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.4/site-packages/dnf/__init__.py", line 31, in <module>
    import dnf.base
  File "/usr/lib/python3.4/site-packages/dnf/base.py", line 29, in <module>
    from dnf.yum import history
  File "/usr/lib/python3.4/site-packages/dnf/yum/history.py", line 27, in <module>
    from .sqlutils import sqlite, executeSQL, sql_esc_glob
  File "/usr/lib/python3.4/site-packages/dnf/yum/sqlutils.py", line 26, in <module>
    import sqlite
ImportError: No module named 'sqlite'

Geez, whatever this was, it totally ate my system.  Well, that one’s a bit more of a quandary.. I wonder if rpm is working yet?

[root@PlexSystem ~]# rpm -q python
python-2.7.11-3.fc23.x86_64

Score!  At least I can now use THAT to fix stuff:

[root@PlexSystem ~]# wget ftp://195.220.108.108/linux/fedora/linux/releases/23/Workstation/x86_64/os/Packages/l/libidn-1.32-1.fc23.x86_64.rpm
[root@PlexSystem ~]# rpm -ivh libidn-1.32-1.fc23.x86_64.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:libidn-1.32-1.fc23        ################################# [ 50%]
[root@PlexSystem ~]# wget ftp://195.220.108.108/linux/fedora/linux/updates/23/x86_64/s/sqlite-3.11.0-3.fc23.x86_64.rpm
[root@PlexSystem ~]# wget ftp://195.220.108.108/linux/fedora/linux/updates/23/x86_64/s/sqlite-libs-3.11.0-3.fc23.x86_64.rpm
[root@PlexSystem ~]# rpm -ivh sqlite-*
Preparing...                          ################################# [100%]
Updating / installing...
   1:sqlite-libs-3.11.0-3.fc23        ################################# [ 50%]
   2:sqlite-3.11.0-3.fc23             ################################# [100%]

Ok…now does it work?

[root@PlexSystem ~]# dnf upgrade
Fedora 23 - x86_64 - Updates                                                                                                                    1.9 MB/s |  22 MB     00:11    
Last metadata expiration check: 0:00:16 ago on Mon May 16 22:59:06 2016.
Dependencies resolved.
...

Yay!!!  And I can resume installing packages.  Oy!  What a mess.  So what the hell happened?  Well, it didn’t take long to locate the problem:

[root@PlexSystem ~]# dnf history info 41
Transaction ID : 41
Begin time     : Wed May  4 17:33:19 2016
Begin rpmdb    : 600:d14912e9a5dc5682d9996e433dd0f8a34d35a295
End time       :            17:33:20 2016 (1 seconds)
End rpmdb      : 593:ce0b85ea8ada9fed23ebd9e2e074acd6a141f9ee
User           : root <root>
Return-Code    : Success
Command Line   : erase samba samba-common-libs samba-common-tools samba-libs
Transaction performed with:
    Installed     dnf-1.1.8-1.fc23.noarch         @updates
    Installed     rpm-4.13.0-0.rc1.13.fc23.x86_64 @updates
Packages Altered:
    Erase libidn-1.32-1.fc23.x86_64                @@commandline
    Erase python-talloc-2.1.6-1.fc23.x86_64        @updates
    Erase sqlite-libs-3.11.0-3.fc23.x86_64         @updates
    Erase samba-2:4.3.8-0.fc23.x86_64              @updates
    Erase samba-common-libs-2:4.3.8-0.fc23.x86_64  @updates
    Erase samba-common-tools-2:4.3.8-0.fc23.x86_64 @updates
    Erase samba-libs-2:4.3.8-0.fc23.x86_64         @updates

You see, my experimentation with Samba left a bad taste in my mouth, so I decided to can that project.  Removing Samba apparently provoked dnf to erase libidn.

Thatis not good.  I’ll have to figure out exactly what causes that one and see if I can report it.

Advertisements
This entry was posted in Information Technology and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s