Description of problem: After running livecd-creator on a system that is also a nis client on the local network, nis stops working. ypwhich reports that the connection to the nis server is lost. After restarting ypbind on the local system, nis starts working again. Version-Release number of selected component (if applicable): livecd-tools-017.1-1.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Verify that ypwhich is working 2. run livecd-creator to create a live image (such as the games live cd) 3. Verify that ypwhich is still working Actual results: ypwhich fails Expected results: ypwhich succeeds Additional info: Here are the results from running this on my system: # id wart uid=500(wart) gid=500(wart) groups=500(wart),511(apachelog),508(mp3),600(thomas) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 # ypwhich foobar.kobold.org # livecd-creator -c fedora-livedvd-games.ks --cache=../cache/ -t /space/src/fedora/livecd/tmp [...lots of output deleted...] # id wart id: wart: No such user # ypwhich ypwhich: can't get local yp domain: Local domain name not set # service ypbind restart Shutting down NIS service: [ OK ] Setting NIS domain: domain is 'Kobold' [ OK ] Starting NIS service: [ OK ] Binding NIS service: [ OK ] # ypwhich foobar.kobold.org # id wart uid=500(wart) gid=500(wart) groups=500(wart),511(apachelog),508(mp3),600(thomas) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
This has been sporadically reported by people from time to time, but I can't reproduce it (well, I hit it _once_... but that was a while ago, and not doing anything weird or different) Do you hit this reliably? If so, can you try removing ypbind from your package manifest? And if it still happens, ypbind + rpcbind + nfs-utils?
(In reply to comment #1) > This has been sporadically reported by people from time to time, but I can't > reproduce it (well, I hit it _once_... but that was a while ago, and not doing > anything weird or different) > > Do you hit this reliably? If so, can you try removing ypbind from your package > manifest? And if it still happens, ypbind + rpcbind + nfs-utils? Yes, this seems to happen very reliably. Even after removing ypbind, yp-tools, rpcbind, and nfs-utils, the problem still appears. Interestingly, it appears that something is clearing the NIS domain name: # domainname Kobold # livecd-creator ... [...lots of output...] # domainname (none) This seems to happen sometime after the last package is installed, and when restorecon is run. If I run 'ypwhich' while 'Installing: bolzplatz2006', it works, but as soon as the restorecon output appears, ypwhich fails: Installing: anaconda ##################### [954/955] Installing: bolzplatz2006 ##################### [955/955]/sbin/restorecon reset /etc/pam.d/system-auth context unconfined_u:object_r:etc_t:s0->system_u:object_r:etc_t:s0 /sbin/restorecon reset /etc/pam.d/system-auth-ac context unconfined_u:object_r:etc_t:s0->system_u:object_r:etc_t:s0 /sbin/restorecon reset /etc/pam.d/smtp context unconfined_u:object_r:etc_t:s0->system_u:object_r:etc_t:s0
Aha! I see what it is (finally) We run authconfig --nostart --update --useshadow --enablemd5 to set up the system to have an encrypted root pass, etc. In authconfig, it unconditionally sets the yp domainname whether or not you've passed --nostart or not. Which, since you're not setting up your live image for nis, means there's no domainname and thus it gets unset.
authconfig-5.4.4-1.fc9 has been submitted as an update for Fedora 9
authconfig-5.4.4-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update authconfig'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7081
(In reply to comment #5) > authconfig-5.4.4-1.fc9 has been pushed to the Fedora 9 testing repository. If Works for me. Thanks!
authconfig-5.4.4-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.