Bug 440067 - local logins fail on hosts configured with ipa-client-install when ipa server is down
local logins fail on hosts configured with ipa-client-install when ipa server...
Product: freeIPA
Classification: Community
Component: ipa-client (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Simo Sorce
Chandrasekar Kannan
Depends On:
Blocks: 453489
  Show dependency treegraph
Reported: 2008-04-01 12:13 EDT by Perry Myers
Modified: 2015-01-04 18:31 EST (History)
1 user (show)

See Also:
Fixed In Version: freeipa-2.0.0-1.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Perry Myers 2008-04-01 12:13:49 EDT
Description of problem:
On hosts that have been configured with ipa-client-install, if the ipa server is
down, local logins fail.  This is because the login is timing out on the
nss_ldap query.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Install/configure ipa-server and a host on the same network with ipa-client
2. Shut down ipa server
3. Try logging in on the console of the host configured with the ipa-client
   as root.
Actual results:
The root login will time out after a long delay

Expected results:
local users should be allowed to login even if the ldap/ipa server is down

Additional info:
Solution (suggested by Simo Sorce) is to set /etc/ldap.conf to have sane timeout
values.  We tried:
nss_reconnect_tries 1
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 8
nss_reconnect_maxconntries 2

And logins are delayed for a second or two while the ldap server query is
attempted, but then the local auth works and the login succeeds.
Comment 1 Simo Sorce 2008-04-01 14:27:11 EDT
I was thinking more about the general problem and I think the following
parameter alone might be enough:
nss_initgroups_ignoreusers root

can you test and see if this helps ?
Comment 2 Perry Myers 2008-04-01 14:41:24 EDT
That works for users that are specified in the list, but the entire contents of
the local /etc/passwd file would need to be put in this list so that users like
apache, haldaemon, dbus and etc are ignored as well.  Otherwise, booting causes
these services to hang indefinitely.
Comment 3 Simo Sorce 2008-04-01 15:13:59 EDT
This is what I am probably going to set by default:
timelimit 15
bind_timelimit 5
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 8
nss_initgroups_ignoreusers root,dirsrv

I am not going to set other users in there, I am probably rather going to
activate nscd by default, but these options alone should make the issue a lot
more bearable by themselves.
After all we are talking about a failure mode where no servers are available at all.
Comment 4 David O'Brien 2008-04-08 11:55:06 EDT
I added a bit of a note about this here, adding that it only happens as part of

I'm wondering if we should include what the defaults are for reference, rather
than sending admins to a RHEL or Fedora box to retrieve them and add them to
whatever OS they are configuring (they might only have non-RHEL clients).
Comment 5 Hugh Brock 2008-04-15 15:12:51 EDT
One other data point: I just came from debugging this same issue on a VM running
FreeIPA server (which installs the client as well I guess). For some reason the
network on this VM did not come up in an orderly fashion, with the result that I
couldn't log into the box at all. Adding the lines above (after having rebooted
to single user mode) not only allowed me to log in, it seemed to fix the network
issue as well (although truthfully I'm not convinced the networking issue had
anything to do with the login issue, might have been sheer luck).

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