I have two pis running osmc, which are supposed to access videos from my main NAS via NFS.
The NFS mounts happen via autofs, which in turn gets configured via NIS.
Since “a few days” nis does not start anymore… all I see in the system journal is this:
root@osmcdownstairs:~# journalctl -u nis.service
-- Logs begin at Fri 2020-10-23 14:12:09 CEST, end at Fri 2020-10-23 15:38:33 CEST. --
Okt 23 14:13:44 osmcdownstairs systemd[1]: Starting LSB: Start NIS client and server daemons....
Okt 23 14:14:07 osmcdownstairs nis[339]: Starting NIS services: ypbindbinding to YP server...........................................failed (backgrounded).
Okt 23 14:14:07 osmcdownstairs nis[339]: .
Okt 23 14:14:07 osmcdownstairs systemd[1]: Started LSB: Start NIS client and server daemons..
Needless to say that “systemctl restart nis” does not work.
Here’s the fun part: just starting ypbind without any arguments from a root shell works.
This only happens on the two pis running osmc - two other pis running “vanilla” raspbian buster, several openSUSE installations, a Fedora32 and a RHEL8 all work fine.
Any ideas?
one detail:
on the osmc pis the nis package is 3.17.1-3+b1, on the two other pis its 3.17.1-3+b2 …
hm… digging deeper:
/etc/apt/sources.list was last modified on oct. 20, and in my apt logs I see that there was a HUGE number of updates around that time. Could it be that that was a migration from stretch to buster?
All my hosts are managed via puppet and/or ansible so updates are automatic…
NIS is a blast from the past, though I can’t claim to remember much about it.
Perhaps something will show up in the logs: grab-logs -A
well, the other way to have a centralized “repository” for useraccounts, configuration files, and such, would be to set up a LDAP directory … so i’ll stick with NIS. I’m NOT migrating from nis to ldap+kerberos just because it is (slightly) newer.
I haven’t forgotten about you. After a few early config issues, I was able to reproduce the problem on a NIS client. The server at least ran ypserv, though nothing else, but ypbind on the client gave that error when run from systemd. Nevertheless ypbind does seem to be doing something (as evidenced from tshark) and rpcinfo -p shows it has bound to ports.
However… you mention that RaspiOS does work. I have RaspiOS 64-bit running on a newly-acquired Pi4, which uses the Debian repo for its arm64 code. Here’s what I see:
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.4.51-v8+ #1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020 aarch64 GNU/Linux
pi@raspberrypi:~ $ dpkg -l nis
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=============================================================
ii nis 3.17.1-3+b1 arm64 clients and daemons for the Network Information Service (NIS)
pi@raspberrypi:~ $ systemctl status nis
● nis.service - LSB: Start NIS client and server daemons.
Loaded: loaded (/etc/init.d/nis; generated)
Active: active (running) since Fri 2020-10-23 22:27:25 BST; 10min ago
Docs: man:systemd-sysv-generator(8)
Process: 863 ExecStart=/etc/init.d/nis start (code=exited, status=0/SUCCESS)
Tasks: 3 (limit: 1915)
CGroup: /system.slice/nis.service
└─876 /usr/sbin/ypbind
Oct 23 22:24:29 raspberrypi systemd[1]: Starting LSB: Start NIS client and server daemons....
Oct 23 22:27:25 raspberrypi nis[863]: Starting NIS services: ypbindbinding to YP server...........................................failed (backgrounded
Oct 23 22:27:25 raspberrypi nis[863]: .
Oct 23 22:27:25 raspberrypi systemd[1]: Started LSB: Start NIS client and server daemons..
pi@raspberrypi:~ $ rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100007 2 udp 628 ypbind
100007 1 udp 628 ypbind
100007 2 tcp 629 ypbind
100007 1 tcp 629 ypbind
It’s also running 3.17.1-3+b1 and failing in the same way. Right now, I’d guess that it’s an upstream (Debian) problem.
it seems top be already fixed upstream, my two “non osmc” raspis are running the nis package version 3.17.1-3+b2 and it works fine…
on closer investigation there is a significant difference between debian buster on my OSMC pis and on the two other pis…
The OSMC2 pis use the arm repositories on debian.org - the other two (where nis works ok) use the repositories from raspberrypi.org:
root@osmcupstairs:/etc/apt# cat sources.list
deb http://ftp.debian.org/debian buster main contrib non-free
deb http://ftp.debian.org/debian/ buster-updates main contrib non-free
deb http://security.debian.org/ buster/updates main contrib non-free
deb http://apt.osmc.tv buster main
root@osmcupstairs:/etc/apt# cat /etc/debian_version
10.6
root@osmcupstairs:/etc/apt#
root@campi:/etc/apt# cat sources.list
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free rpi
root@campi:/etc/apt# cat /etc/debian_version
10.6
root@campi:/etc/apt#
“campi” is a pi zero W, “osmcupstairs” is a Pi 3 running OSMC.
Would it be safe (as in, would OSMC still work) if I were to replace the debian repos on my osmc pis with the ones from raspberrypi.org and ran an update?
No this is not recommended and will almost certainly cause issues.
Pi0/1 have different repos because we use Raspbian as a base.
Pi2/3 use upstream Debian.
I finally figured that one out…
there’s a file /etc/default/nis with all kind of variables in it, and one of them holds parameters that are passed to ypbind on start… and that one had “–no-dbus” in it which is not supported (anymore?).
Took it out, all is well.