Bug 186525 - Network authentication configuration dialog box never goes away
Network authentication configuration dialog box never goes away
Status: CLOSED DUPLICATE of bug 186527
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
5
All Linux
medium Severity low
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-23 20:54 EST by Jarod Wilson
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-14 02:06:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jarod Wilson 2006-03-23 20:54:56 EST
Description of problem:

If you try to set up network authentication within firstboot, the config dialog
box never goes away after you hit okay. Seen it on several machines now and it
doesn't appear to be specific to any auth type.

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

firstboot-1.4.6-1
Comment 1 Chris Lumens 2006-03-24 16:16:47 EST
It goes away for me after a pause of a few seconds.  Nothing has changed in this
code for a while, so I'll kick it over to authconfig to see if they've done
something new.
Comment 2 Jarod Wilson 2006-03-24 16:31:11 EST
For clarification's sake, did it go away after you enabled some form of network
auth, or did you just hit okay after opening the window? I'm wondering if this
might be yet another thing related specifically to ldaps auth, where you don't
actually have the necessary pem file yet (though an attempt to configure NIS
auth hung on me too, but maybe that's because there wasn't a reachable NIS server).
Comment 3 Tomas Mraz 2006-03-27 04:17:37 EST
There is a problem that authconfig tries to restart portmap and ypbind if you
enable NIS support. If the domain server is unreachable it will take a while
before it will fail and it could look like the authconfig dialog doesn't go away.

I don't know of any other circumstances where authconfig window would stay open
after you click on OK/Cancel buttons. Could you specify what exactly was enabled
and could you try reproduce it running it from command line (authconfig-gtk) so
any error messages/exceptions can be seen?
Comment 4 Jarod Wilson 2006-04-13 19:11:14 EDT
Sorry for the delay, finally got back around to this... All I'm turning on in
firstboot is ldap user info and auth, with a remote ldap server using tls. At
the moment, the system has been sitting there for about 10 minutes and the
dialog box is still there... Ah! Okay, after about 15 minutes, it finally went
away. Testing from the command line coming shortly...

When run just authconfig-gtk from the command line after the system is up, the
dialog box goes away immediately, only spitting the following to the console:

# authconfig-gtk
setsebool:  SELinux is disabled.
Stopping nscd:                                             [FAILED]
Starting nscd: /usr/sbin/nscd: already running
                                                           [FAILED]


So it would appear there is some sort of interaction problem with firstboot...
Yup, just ran firstboot manually from the command line, and the hang is back.
Console output is as follows:

Stopping nscd:                                             [FAILED]
Starting nscd: /usr/sbin/nscd: already running
                                                           [FAILED]
Stopping system message bus:                               [  OK  ]
Starting system message bus:

and it hangs for about 15 minutes there. (But does eventually finally time out).

This actually appears to be directly related to another bug I've got open, 186527.

If I redo everything, putting the slapd.pem file in place ahead of time,
everything works perfectly as expected, no hangs anywhere.
Comment 5 Tomas Mraz 2006-04-14 02:06:55 EDT

*** This bug has been marked as a duplicate of 186527 ***

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