Dear all,
I just upgraded one of my Tumbleweed workstations, and after the upgrade NIS is failing.
Unfortunately I am not very experienced with NIS, however, I think I was able to pin down the problem to the fact, that ypbind does not get the shadow.byname map anymore after the upgrade.
On a not updated, working machine running:
ypbind -debug -verbose
yppoll shadow.byname
produces:
29209: ypbindproc_domain_3_svc (xxx) from 127.0.0.1 port 980
29209: Ping active server for 'xxx'
29209: YPBINDPROC_DOMAIN: server 'xxx', port 961
29209: Status: YPBIND_SUCC_VAL
Domain xxx is supported.
Map shadow.byname has order number 1522320534. [Thu Mar 29 12:48:54 2018]
The master server is xxx
After upgrading:
1653: ypbindproc_domain_3_svc (xxx) from 127.0.0.1 port 55951
1653: Ping active server for 'xxx'
1653: YPBINDPROC_DOMAIN: server 'xxx', port 961
1653: Status: YPBIND_SUCC_VAL
Can't get any map parameter information.
Can't get order number for map shadow.byname.
Reason: No such map in server's domain
Can't get master for map shadow.byname.
Reason: No such map in server's domain
So I think the problem is related to the unprivileged port after the upgrade (55951).
Does anyone has an idea why this has changed?
Regards,
Tobias
I don’t pretend to know the answer to this, but as per this reference…
https://doc.opensuse.org/documentation/leap/security/html/book.security/cha.nis.html#sec.nis.client
I note the following…
If you do not want other hosts to be able to query which server your client is using, go to the Expert settings and disable Answer Remote Hosts. By checking Broken Server, the client is enabled to receive replies from a server communicating through an unprivileged port. For further information, see man ypbind.
I also tried -broken-server but as the NIS server is unchanged it did not change anything.
There must be a local change introduced by the upgrade that results in this strange behavior. I hope that I have some spare time to nail it down to a specific packe that was upgraded, I just had hopes that anyone has encountered this problem as well.
I would check that it is not a client firewall issue at play perhaps.
IIRC there was something about this on the factory mailing list. It’s a bug in libtirpc. Try if downgrading that package is still possible. And, a fix is on the way, see https://bugzilla.redhat.com/show_bug.cgi?id=1560736
Good find Gertjan. I’d had a quick search of recent likely bug reports but missed this.
Sheer coincedence, I read dimstar’s reviews of the week on Tumbleweed once in a while, Read last week’s an hour before logging in here,