Bug 457697

Summary:	livecd-creator borks nis clients
Product:	[Fedora] Fedora	Reporter:	Wart <wart>
Component:	authconfig	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9	CC:	davidz, katzj
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-09-10 07:13:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	438943

Description Wart 2008-08-03 23:40:54 UTC

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 19:02:20 UTC

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-05 03:05:02 UTC

(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-05 03:28:59 UTC

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 09:04:32 UTC

authconfig-5.4.4-1.fc9 has been submitted as an update for Fedora 9

Comment 5 Fedora Update System 2008-08-07 23:55:24 UTC

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-10 01:04:52 UTC

(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 07:13:38 UTC

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.