Bug 457697 - livecd-creator borks nis clients
livecd-creator borks nis clients
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
 
Reported: 2008-08-03 19:40 EDT by Wart
Modified: 2008-09-10 03:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-10 03:13:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wart 2008-08-03 19:40:54 EDT
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
Comment 1 Jeremy Katz 2008-08-04 15:02:20 EDT
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?
Comment 2 Wart 2008-08-04 23:05:02 EDT
(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
Comment 3 Jeremy Katz 2008-08-04 23:28:59 EDT
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.
Comment 4 Fedora Update System 2008-08-05 05:04:32 EDT
authconfig-5.4.4-1.fc9 has been submitted as an update for Fedora 9
Comment 5 Fedora Update System 2008-08-07 19:55:24 EDT
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
Comment 6 Wart 2008-08-09 21:04:52 EDT
(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!
Comment 7 Fedora Update System 2008-09-10 03:13:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.