Description of problem:
Nis client does not work in Mageia 2.
Steps to Reproduce:
1. Set nis client in Mageia control centre or manually (/etc/yp.conf)
2.reboot - Nis client does not work;
Tests with yptest:
Test 1: domainname
ERROR: domainname is not set!
But domainname really set in yp.conf
After domainname set by ypdomainname, failed Test 2: Not communicate with ypbind
after reboot again - domainname is not set!
Where is problem?
systemd! On 50 PC with Mageia 1 in my school all is OK. ypbind package in Cauldron repo is old (without systemd patches), I found fedora 16 rpm with systemd patches.
Link to this rpm: http://rpm.pbone.net/index.php3/stat/4/idpl/17680844/dir/fedora_16/com/ypbind-1.33-11.fc16.i686.rpm.html
Hi, thanks for reporting this bug.
This bug was filed against cauldron, but we do not have cauldron at the moment.
Please report whether this bug is still valid for Mageia 2.
yes, this bug is still valid for Mageia 2.
i builded new rpm ypbind-1.33 with Fedora 16 patches and all is OK now.
Link to SRPM: http://mandrake.zstenis.org/rpms/mag2/SRPMS/ypbind-1.33-3.mga2.src.rpm
Link to 32bit rpm: http://mandrake.zstenis.org/rpms/mag2/RPMS/32bit/ypbind-1.33-3.mga2.i586.rpm
but the bug is still valid for our rpms :/
I'm teacher in computer science in a french highschool and I also use NIS for managing the Linux user account of my students.
I have also encountered the same problem with Mageia 2 : the NIS domain name still remains "(none)" after installation and configuration...
If someone wants to create the x68_64 package, it is quite simple :
1) download and install the SRPM with the link given by Jaroslav Krejci ;
2) go to the SPECS directory (/root/rpmbuild/SPECS) and edit the ypbond.spec file;
3) modify the 2 "BuildRequires" lines to put "lib64" instead of "lib" for the libdbus-glib requirement;
4) install (if necessary) the "lib64dbus-glib" package;
5) Build the RPM package with the "rpmbuild -bb ypbind.spec" command;
6) go the RPMS directory (/root/rpmbuild/RPMS/x86_64) and find the new RPM file (ypbind-1.33-3.mga2.x86_64.rpm)
7) Install this new package in "update mode" with the "rpm -Uvh" command ;
Everything is ok with this new 1.33-3 package... but the ypbind service is not enabled in the default configuration. You have to enable it by the hand with the "systemctl enable ypbind.service" command.
You can now retrieve and enjoy your NIS configuration !
I updated rpms.
Changelog: x86_64 specfile fixes.
Link to SRPM:
Link to 32bit rpm:
Link to 64bit rpm:
Your rpms does not follow mageia policy (buildrequires must works with all archs), then cannot be taken as reference.
Feel free to first test rpms from cauldron, I'll backports them to mageia 2 after testing.
You can provide patches over existing rpms too.
the last "ypbind-1.33-4.mga2.src.rpm" given by Jaroslav Krejci is Ok, the "BuilRequires" directives works well with all archs...
New srpm from Cauldron is buged. In patch ypbind-post-waitbind is:
if /usr/sbin/rpcinfo -p | LC_ALL=C fgrep -q ypbind
but must be
if /sbin/rpcinfo -p | LC_ALL=C fgrep -q ypbind
There is a problem with the yppasswd command too !!
When I'm trying to change my password from a client, I obtain these messages :
$ yppasswd -p
Changing NIS account information for MY_USER on NIS_SERVER
Please enter old password : OLD_PASSWORD
Changing NIS password for MY_USER on NIS_SERVER
Please enter new password: NEW_PASSWORD
You cannot reuse the old password.
Please enter new password:...
My new password is really different from the old one !!!
And It is impossible to change the password !!
Any idea about this serious problem ?
Thanks a lot for your help !
Yes, i can confirm this bug - but package is yp-tools. It is an old bug - exist in Fedora too. I build rpm with Fedora`s patches - but problem is still same.
It is not important, beacause i tested "passwd", which works with NIS users too.
I opened a new bug (7471) about this problem 6 days ago.
I also tested the "passwd" command to try to change tha password of a NIS user... but I'm not sure that it worked well : everything seemed to be OK when changing the password but this new password was not accepted on the next login !!
The password was unchanged on the NIS server and I had to use the old one to log in.
But if you say that you obtained good results on NIS passwords with the basic "passwd" command, I'm going to test it again...
I tested again 5 minutes ago the basic passwd command to change the password of a NIS user from a NIS client host...
and I can confirm the result : it does NOT work, everything seems going ok during the change but the password remains unchanged !!
And when you try to log in with the same account, you have to enter the old password.
So I think the new bug I reported (7471) is really important...
But I you let me know another idea to work around the problem, it will be great !
Created attachment 2906 [details]
Patch for /etc/rc.d/init.d/ypbind to set the domain name if not already set.
The issue with NIS not working on Mageia 2 is due to there being nothing in the systemd start-up scripts which sets the domainname.
When using the old rc scripts /etc/rc.d/rc.sysinit checked /etc/sysconfig/network for the environment variable NISDOMAIN and if it existed and was not zero length it would run domainname(8) to set the NIS domain.
I've added a patch for /etc/rc.d/ypbind
This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.
The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.
Thank you for reporting this bug and we are sorry it could not be fixed.
The Mageia Bugsquad