Package: nis
Version: 3.17.1-3+b1
Severity: important
This is a very irritating bug.
It may not be worth fixing but it should be recorded.
Between stretch and buster, something subtle changed in makedbm.
A map produced by the makedbm in stretch starts with the byte 0xCE.
A map produced by the nakedbm in buster starts with the byte 0xCF.
This makes it impossible for stretch clients to understand the
contents of the map file, they just give up.
Steps to reproduce:
run the comamds below on a stretch & a buster host
1. cat >test.source
one
two
three
^D
2. awk -F: '{printf "%s\t%s\n",$1,$1}' test.source | \
/usr/lib/yp/makedbm --no-limit-check -c \
-m testhost -i /tmp/test.source -o /tmp/test.map - test.map
3. xxd -l 10 test.map
00000000: ce9a 5713 0010 0000 0010 ..W.......
On a stretch host you get the result above.
On a buster host you get
xxd -l 10 test.map
00000000: cf9a 5713 0010 0000 0010 ..W.......
On a buster host, makedbm is happy with the new format
buster$ /usr/lib/yp/makedbm -u test.map
one one
three three
YP_INPUT_NAME /tmp/test.source
YP_LAST_MODIFIED 1614914067
YP_MASTER_NAME testhost
two two
YP_OUTPUT_NAME /tmp/test.map
On a stretch host, not so much
stretch$ scp buster:/tmp/test.map buster.map
stretch$ makedbm -u buster.map
makedbm: Cannot open buster.map
stretch's ypxfr is also unimpressed with the shiny new format.
This poses a problem when you are upgrading a mix of
stretch & buster hosts. The problem can likely be avoided
if you upgrade any NIS slave servers before the master,
but can create a significant issue if you do the master first.
The change might have occurred because makedbm, ypxfr etc on buster
are making use of libgdbm6 while stretch uses libgdbm3.
sretch$ ldd /usr/lib/yp/makedbm
linux-vdso.so.1 (0x00007ffd474f8000)
libgdbm.so.3 => /usr/lib/x86_64-linux-gnu/libgdbm.so.3
(0x00007f535fc5e000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f535fa46000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f535f6a7000)
buster$ ldd /usr/lib/yp/makedbm
linux-vdso.so.1 (0x00007ffc95de3000)
libgdbm.so.6 => /lib/x86_64-linux-gnu/libgdbm.so.6 (0x00007f5d78069000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f5d78050000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5d77e8f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5d78091000)
Suggested fix: a nice fat NEWS entry explaining the change in
libgdm depenency and admonishing people to update slaves first.
(Assuming my theory is right, of course...)
Kind regards
Vince
Extra info:
affected release: buster
linux kernel: 4.19.0-14-amd64 4.19.171-2 (2021-01-30) x86_64
Related packages: libgdbm3 1.8.3-14, libgdbm6 1.18.1-4
