Dracut unlocker + tang pin cannot perform DNS lookups on Fedora 31

[bviktor]

If I bind to the tang server by hostname, e.g.

sudo clevis luks bind -d /dev/sda3 tang '{"url": "http://tang.foobar.com"}'

The boot log shows these errors:

[  OK  ] Reached target Paths.
[  OK  ] Found device Samsung_SSD_850_PRO_512GB 3.
         Starting Cryptography Setu…f146-4155-a920-5fe04b92f239...
[    2.672507] dracut-initqueue[534]: Error communicating with the server!
[   11.051097] dracut-initqueue[534]: Error communicating with the server!
[   11.709899] dracut-initqueue[534]: Error communicating with the server!
[   17.854970] dracut-initqueue[534]: Error communicating with the server!
[   18.508582] dracut-initqueue[534]: Error communicating with the server!
[   24.661555] dracut-initqueue[534]: Error communicating with the server!
[   25.324365] dracut-initqueue[534]: Error communicating with the server!
[...]

And it repeats until I manually enter the passphrase. If I bind with an IP address, like so (plus the changes in #147 necessary to make it work until Dracut in Fedora receives the updates):

sudo clevis luks bind -d /dev/sda3 tang '{"url": "http://1.2.3.4"}'

It works as expected.

---

Ad-hoc encrypt-decrypt pairs like this:

echo hi | clevis encrypt tang '{"url": "http://tang.foobar.com"}' > hi.jwe
clevis decrypt < hi.jwe

Do work in a started up session, so I'd rule out server errors. Come to think of it, the bind would also fail if it didn't work after boot.

Required libs and binaries are built as explained in #136

[sergio-correia]

I opened https://bugzilla.redhat.com/show_bug.cgi?id=1779394 for tracking this issue. I also added a possible solution in there (adding /usr/lib64/libnss_dns.so.2 to the initramfs).

[bviktor]

Thanks for the report and the pointers!

Unfortunately that library is already included in the initramfs, at least according to lsinitrd. Nevertheless, I added /usr/lib64/libnss_dns* to module-setup.sh, but it didn't change a thing.

[bviktor]

Uh, or maybe it did change, let me test this a little further.

[sergio-correia]

Thanks for the report and the pointers!

Unfortunately that library is already included in the initramfs, at least according to lsinitrd. Nevertheless, I added /usr/lib64/libnss_dns* to module-setup.sh, but it didn't change a thing.

I have this here:

sudo lsinitrd /boot/initramfs-$(uname -r).img | grep libnss
-rwxr-xr-x   1 root     root        82056 Jul 24 19:24 usr/lib64/libnss_files-2.30.so
lrwxrwxrwx   1 root     root           20 Jul 24 19:24 usr/lib64/libnss_files.so.2 -> libnss_files-2.30.so

[bviktor]

Indeed. Sorry, it was a brainfart I guess. Adding /usr/lib64/libnss_dns.so* solved the issue. Shall I submit a PR to tang's module-setup.sh, or is this something that should also be resolved in dracut instead?

[sergio-correia]

Let's see how that issue progresses, what the dracut maintainers have to say on the matter. At a first glance, it seems like something that should be fixed by dracut.

[aneagoe]

Well, unfortunately they don't seem to care much. I've bumped that ticket but I doubt they'll react fast on it. I'm not sure of what else we can do to get the upstream fedora to act on this.

[jmarcelletti]

Probably not related but I am having the exact same issue on Ubuntu 18.04, except I already have libnss_dns in my initramfs:

lsinitramfs -l /boot/initrd.img-4.15.0-22-generic  | grep -i dns
lrwxrwxrwx   1 root     root           18 Mar 23 22:16 lib/i386-linux-gnu/libnss_dns.so.2 -> libnss_dns-2.27.so
-rw-r--r--   1 root     root        22032 Apr 16  2018 lib/i386-linux-gnu/libnss_dns-2.27.so
lrwxrwxrwx   1 root     root           25 Mar 23 22:16 lib/x86_64-linux-gnu/libdns-export.so.1100 -> libdns-export.so.1100.1.1
-rw-r--r--   1 root     root      2211824 Apr 13  2018 lib/x86_64-linux-gnu/libdns-export.so.1100.1.1

I'm testing this on Clevis 12 but with the PR I have in for the initramfs changes (if that did anything).

EDIT: I can confirm that I simply can't curl by dns even though my /etc/resolv.conf appears to be fine (I can query those servers from local) so even though things are still broken, it's not a clevis related problem.

[jmarcelletti]

My team found the solution internally and it is related to what Sergio said - In our case the dns module was present but it was the 32bit version because this system happened to have libc6:i386 installed. Apparently the initramfs builder preferences 32 bit over 64 bit (which is backwards imo). We didn't catch this early because we were looking for the libdns/libnss files and mentally autocompleted on the i386 vs x86_64 stuff. There are 2 solutions for this.

1 - uninstall libc6:i386 and rebuild initramfs

2 - Add in your own hook that just blanket copies it as so:
/etc/initramfs-tools/hooks/fix_add_dns

#!/bin/sh
. /usr/share/initramfs-tools/hook-functions
function fix_add_dns() {
        local libdir="/lib/x86_64-linux-gnu"
        local found="" lib="" f=""
        for lib in libnss_files libnss_dns libresolv; do
                found=""
                for f in "$libdir/$lib.so".?; do
                        [ -e "$f" ] || continue
                        [ "$verbose" = "y" ] && echo "dns: $lib: $f"
                        copy_file library "$f"
                        found="$f"
                done
                [ -n "$found" ] || echo "WARNING: no $libdir/$lib.? file" 1>&2
        done
        return 0
}
fix_add_dns

[bviktor]

Thanks a lot for the comment, @jmarcelletti ! Oddly, I ran into this on 18.04 too, although I thought it already worked on Ubuntu. In any case, your hook complained about various syntax errors, so I ended up using something like this:

#!/bin/sh
. /usr/share/initramfs-tools/hook-functions

local_libdir="/lib/x86_64-linux-gnu"
local_found="" lib="" f=""
for lib in libnss_files libnss_dns libresolv; do
    local_found=""
    for f in "$local_libdir/$lib.so".?; do
        [ -e "$f" ] || continue
        [ "$verbose" = "y" ] && echo "dns: $lib: $f"
        copy_file library "$f"
        local_found="$f"
    done
    [ -n "$local_found" ] || echo "WARNING: no $local_libdir/$lib.? file" 1>&2
done

One more note: the hook needs to be executable, otherwise update-initramfs conveniently ignores it.