Description of problem: ypwhich fails giving the error: "Error: unsupported version (-1) from ypbind on 'localhost'" This causes the systemctl start-up script /usr/lib/ypbind/ypbind-post-waitbind to fail, meaning that the service fails. Version-Release number of selected component (if applicable): yp-tools-4.2.3-2 How reproducible: Always Steps to Reproduce: 1. Install system. 2. Configure to use NIS 3. Run 'ypbind' and then run 'ypwhich'
Thank you for the report. yp-tools includes: /usr/bin/ypcat /usr/bin/ypchfn /usr/bin/ypchsh /usr/bin/ypmatch /usr/bin/yppasswd /usr/bin/ypwhich It would be interesting to know whether these all provoke errors or run OK. ypbind (required for the client programs; could it be the culprit?) & ypserv (required once in the network) are packages on their own. The 'yp*' packages have no maintainer, so assigning this bug globally.
Assignee: bugsquad => pkg-bugs
All the commands work except for ypwhich.
Looking through the source I think I've found the problem. By default the latest (2016) version of yp-tools is defaulting to the version 3 protocol and I think ypbind (or Solaris NIS) only supports versions 1 and 2. Using 'ypwhich -V 2' or 'ypwhich -V 1' work. So, the code needs to be modified so that version 2 is the default and not version 3, which is probably a recent Linux-only invention.
OK, here's a patch for the ypwhich.c source. It seems that there's a combination of issues, the default version is not armoured by '#ifdef HAVE_YPBIND3' and the compiler isn't properly inserting the test '(vers==-1)?3:vers' so that the value '-1' is being sent to clnt_create().
Created attachment 11285 [details] ypwhich.c patch
Maybe our ypbind package should be updated to latest 2.6.1 release?
CC: (none) => geiger.david68210
Well, it is a bug in yp-tools' ypwhich.c code which should be fixed and fed back to the authors. Moving to the newer ypbind would be a work-around too but may break more things and involve a lot more work.
Has there been any progress with this bug? Unfortunately this is preventing the roll-out of Mageia 7 on our network as it's a bit of a show stopper.
P.S. I've raised an issue on the yp-tools Github site but it's not been taken up by the author as yet.
Please could someone action this. It's not as if I've not provided the patch to fix the issue, it merely needs applying to the SRPM and pushing out the build. I'm concerned that I won't be able to roll out Mageia 7 before support for Mageia 6 lapses.
Done with yp-tools-4.2.3-2.1.mga7 in Core/Updates_testing repo! Please test it, thanks in advance.
Assigning to QA, Advisory: ======================== ypwhich from yp-tools package fails giving an error: "Error: unsupported version (-1) from ypbind on 'localhost'", this come from an incompatibility between ypwhich and our current ypbind version. So this update fixes this issue. ======================== Packages in 7/core/updates_testing: ======================== yp-tools-4.2.3-2.1.mga7.i586.rpm yp-tools-4.2.3-2.1.mga7.x86_64.rpm Source RPM: ======================== yp-tools-4.2.3-2.1.mga7.src.rpm
Assignee: pkg-bugs => qa-bugs
MGA7-64 Plasma on Lenovo B50 No installation issues At CLI: $ ypwhich ypwhich: can't get local yp domain: Lokale domeinnaam is niet ingesteld english: local domain name not set. That is correct , no NIS present in this LAN, so the error is gone. OK for me, leaving for others for more extensive tests if needed.
CC: (none) => herman.viaene
I can confirm that the updated package works: [root@testmga7 ~]# ypwhich terra The system boots correctly with ypbind operational.
Sounds like enough to me. Giving it a 64-bit OK and Validating. Advisory in Comment 12.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugsWhiteboard: (none) => MGA7-64-OK
CC: (none) => tmbKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2019-0186.html
Status: NEW => RESOLVEDResolution: (none) => FIXED