Bug 430018

Summary: dhcp changing resolv.conf should not make it impossible to ssh to an IPA client machine which had the install script run on it
Product: [Retired] freeIPA Reporter: Chandrasekar Kannan <ckannan>
Component: ipa-serverAssignee: Simo Sorce <ssorce>
Status: CLOSED WONTFIX QA Contact: Chandrasekar Kannan <ckannan>
Severity: high Docs Contact:
Priority: high    
Version: 1.0CC: benl, mgregg, rcritten, shillman, ssorce, yzhang
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-01-29 18:35:28 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: 246164, 429034    

Description Chandrasekar Kannan 2008-01-24 06:54:57 UTC
Ticket #118 (new defect)

Opened 2 months ago

Last modified 1 month ago
dhcp changing resolv.conf should not make it impossible to ssh to an IPA client machine which had the install script run on it
Reported by: 	shillman 	Assigned to: 	simo
Priority: 	major 	Milestone: 	release-1
Component: 	other 	Version: 	1.0
Keywords: 		Cc: 	
Description (Last modified by shillman) ¶

I realize that the IPA server will not be run using DHCP in production, but clients might be. And if the clients are running using DHCP, and their resolv.conf is changed out from under them, suddenly not being able to ssh in to that machine at _all_, due to a "sshd: ldap-nss.c:1312: do_init: Assertion `cfg->ldc_uris[session.ls_current_uri] != ((void *)0)' failed." error is just bad.

FWIW, putting 'PEERDNS=no' in the relevant /etc/sysconfig/network-scripts/ifcfg-eth0 file will prevent resolv.conf from being modified.

[This is apparently an nss_ldap bug, but there is no such component in trac]

At the least, one should be able to log into the client machine as a non-IPA user. And there should not be such a scary error if they try to login as an IPA user.
Change History
2007-11-21 14:16:57 changed by shillman ¶

    * owner deleted.
    * component changed from ipa-client to other.
    * description changed.

2007-12-05 10:31:32 changed by kmacmill ¶

    * owner set to simo.

Simo - is this something we can control at all? I assume no. If not please close.
2007-12-05 10:53:00 changed by simo ¶

No we can't, correct network configuration is a pre-requisite to run a network wide authentication mechanism. That said, the nss_ldap bug is something that need investigation, as lack of network should never prevent login for local users, delays are ok but nothing more than that.

Leaving open just as a tracker to test nss_ldap behavior.
2007-12-20 15:14:42 changed by kmacmill ¶

    * milestone changed from milestone-6 to release-1.

Comment 1 Simo Sorce 2008-01-29 18:35:28 UTC
Can't really control this, the network need ot be properly configured if you
want to use an IPA server.