Bug 430018 - dhcp changing resolv.conf should not make it impossible to ssh to an IPA client machine which had the install script run on it
dhcp changing resolv.conf should not make it impossible to ssh to an IPA clie...
Status: CLOSED WONTFIX
Product: freeIPA
Classification: Community
Component: ipa-server (Show other bugs)
1.0
All Linux
high Severity high
: ---
: ---
Assigned To: Simo Sorce
Chandrasekar Kannan
:
Depends On:
Blocks: freeipa10 429034
  Show dependency treegraph
 
Reported: 2008-01-24 01:54 EST by Chandrasekar Kannan
Modified: 2015-01-04 18:30 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-29 13:35:28 EST
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 Chandrasekar Kannan 2008-01-24 01:54:57 EST
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 13:35:28 EST
Can't really control this, the network need ot be properly configured if you
want to use an IPA server.

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