On 10/29/2014 06:45 PM, Dmitri Pal wrote:
On 10/29/2014 02:40 PM, Craig White wrote:
-----Original Message-----
From: Rob Crittenden [mailto:[email protected]]
Sent: Tuesday, October 28, 2014 5:34 PM
To: Craig White; [email protected]; [email protected]
Subject: Re: [Freeipa-users] getent passwd / group [SOLVED]
Craig White wrote:
*From:*Dmitri Pal [mailto:[email protected]]
*Sent:* Tuesday, October 28, 2014 5:10 PM
*To:* Craig White; [email protected]
*Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED]
On 10/28/2014 04:41 PM, Craig White wrote:
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of *Craig
White
*Sent:* Tuesday, October 28, 2014 1:28 PM
*To:* [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*Subject:* Re: [Freeipa-users] getent passwd / group [SOLVED]
*From:*Dmitri Pal [mailto:[email protected]]
*Sent:* Tuesday, October 28, 2014 10:04 AM
*To:* Craig White; [email protected]
<mailto:[email protected]>
*Subject:* Re: [Freeipa-users] getent passwd / group
On 10/28/2014 12:11 PM, Craig White wrote:
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of
*Dmitri Pal
*Sent:* Monday, October 27, 2014 5:32 PM
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [Freeipa-users] getent passwd / group
On 10/27/2014 07:38 PM, Craig White wrote:
RHEL 6.5 - new install
ipa-server-3.0.0-42.el6.x86_64
389-ds-base-1.2.11.15-47.el6.x86_64
On the master, I get nothing
[root@ipa001 log]# getent passwd admin
[root@ipa001 log]#
But it works on the replica as expected
[root@ipa002nadev01 ~]# getent passwd admin
admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash
I am used to using PADL / NSSWITCH with OpenLDAP and I am
rather surprised that on both, 'getent passwd' and 'getent
group' return only entries from local files but then
again,
I've never used sssd before.
REJECT all -- 0.0.0.0/0 0.0.0.0/0
reject-with icmp-host-prohibited
Then we need SSSD logs with the debug_level in the right
sections as
Jakub mentioned in his mail.
----
Sorry - I had a long meeting and should have noted that after
restarting SSSD, it all started working again as expected. Clearly
something I have to watch for and indeed, I moved the debug to the
domain section for future.
I should add - came to the realization that restarting sssd and
went to long meeting, then came back and couldn't log into ipa
console or Kerberos and had to restart IPA service to restart Kerberos.
IPA is logging nothing.
This is not the first time I have had to go through this cycle
- it seems that somehow, the IPA server is sensitive to the SSSD
daemon and if the SSSD goes haywire, when I restart SSSD, IPA is not
functioning and must be restarted too.
Thanks
Craig
Is this on the same server?
----
Yes, same server... the one I call the master. The first one I set up.
I'm getting tuned in to the checking the status of dirsrv and ipa but
now I know to check the status of the sssd too.
Seems like it crashes a little too easily - I doubt I did much to
harm it... I am fairly experienced with OpenLDAP and in fact used
389-server back when it was called FedoraDS.
But it is running now, and seemingly will stay running for some time
and I am upping the logging and watching for a crash like Richard
said to provide some debug logs if possible. Sort of wish I could
have just started with RHEL 7 and the updated IPA.
Ok, and to be clear if it crashes again Rich needs to get a stacktrace.
Logs won't be enough.
rob
----
OK - just after I left work last night - IPA crashed.
Oct 28 17:17:11 ipa001 kernel: ns-slapd[1219]: segfault at 0 ip
00007f86cd04e572 sp 00007f86a2bf7f10 error 4 in
libslapd.so.0.0.0[7f86cd009000+fd000]
Required a 'service ipa restart' to get up and running again ;-(
Now Rich directed me to the 'debugging crashes' section which would
have me installing debuginfo for 389.
I can't find it...
# yum search 389-ds-base-debuginfo
Loaded plugins: product-id, rhnplugin, subscription-manager
This system is receiving updates from RHN Classic or RHN Satellite.
rackspace-rhel-x86_64-server-6-common | 871 B 00:00
rackspace-rhel-x86_64-server-6-ius | 871 B 00:00
rhel-x86_64-server-6 | 1.5 kB 00:00
rhel-x86_64-server-optional-6 | 1.5 kB 00:00
rhel-x86_64-server-supplementary-6 | 1.5 kB 00:00
rhn-tools-rhel-x86_64-server-6 | 1.3 kB 00:00
epel/pkgtags | 1.3 MB 00:00
Warning: No matches found for: 389-ds-base-debuginfo
No Matches found
Which sort of makes sense in that we are forced to use Rackspace
mirrors and can't use any public repos.
I can probably get around it by separately downloading to my desktop,
using SCP to transfer the packages over and installing but that is
quite a hassle.
I do not think there is another option. Sorry.
Do I have any other options? Is the only debuginfo package I need
the 389-ds-base?
AFAIU yes.
You need the ipa-server and slapi-nis debuginfo packages. And all of
the dependencies of 389 and ipa . . . Grr - I wish the debuginfo
packages were in the default channels . . .
See below - if none of these work because you are on Satellite and you
cannot configure your Satellite with the correct channels/packages, let
me know.
With the release of RHEL 6 the debuginfo packages are no longer provided
via the Red Hat public FTP site. They have instead moved to Red Hat
Network (RHN) classic or Red Hat Satellite for download.
Each base Red Hat channel now has a debug child channel. For example,
rhel-x86_64-server-6
rhel-x86_64-server-6-debuginfo
For RHEL 6 systems registered via subscription-manager:
yum install yum-utils
yum repolist all | grep debug
yum-config-manager --enable rhel-6-server-debug-rpms
If the system is registered via subscription-manager, the associated
repostory label ends in "debug-rpms". Enable it with yum-config-manager
or subscription-manager, e.g.,
# yum-config-manager --enable rhel-6-client-debug-rpms
# subscription-manager repos --enable rhel-6-client-debug-rpms
# yum-config-manager --enable rhel-6-server-debug-rpms
# subscription-manager repos --enable rhel-6-server-debug-rpms
If the system is registered to RHN Classic, add the channel to the
system profile in the Customer Portal, or with rhn-channel:
# rhn-channel -a -c rhel-`uname -i`-client-6-debuginfo -u <Red Hat
login> -p <Password>
# rhn-channel -a -c rhel-`uname -i`-server-6-debuginfo -u <Red Hat
login> -p <Password>
Note: if rhn-channel states that the channel does not exist, use
the following command to verify the correct channel label in the list of
available channels:
# rhn-channel -L
to verify the correct channel name in the list of available channels.
Additionally, the RHN user interface has been changed to link to the
debuginfo packages from the corresponding binary RPMs. For example:
https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=590664
Note that the "Associated Debug Info Package(s)" link at the bottom goes
straight to the debuginfo package instead of to ftp.redhat.com.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
