Re: [Freeipa-users] replica_generate_next_csn messages in dirsrv error logs
Ludwig, > you still only grep the replication connection, but before being replicated > the entry has to be added by some client connection, can you get all > references to the entry ? > the log snippet you provide shows also csns with tag=103, which indicate a > MOD, are these MODs for the added entries ? or other mods ? . I can't believe I did that! Ok, so the logs have been rotated (I didn't think to adjust logrotate..), so there aren't any logs to peruse for the case I've presented so far. However, I was able to reproduce the errors by "bulk" deleting 39 DNS entries, and only the MASTER reported "replica_generate_next_csn" entries. Given the size of the logs, I think it would be pointless to do any kind of sanitization. I'll go ahead and gzip them for you and email you off-list. I've labeled them as MASTER and REPLICA. John DeSantis 2016-08-19 9:18 GMT-04:00 Ludwig Krispenz : > > On 08/18/2016 05:28 PM, John Desantis wrote: >> >> Ludwig, >> >>> unfortunately this is not enough to determine what is going on. The >>> intersting generated/used csn is only logged in the >>> corresponding RESULT message and these are only the replication >>> connections, >>> it would be necessary to see the >>> original ADD operation, was it added once or twice by a client ? >>> you could pick one entry eg server-6-3-sp and grep for all references in >>> the >>> access logs of both servers (maybe there are mods as well) and then >>> get also get the RESULT line for the ops found >> >> Here are the updated log snippets looking for ADD and RESULT: > > you still only grep the replication connection, but before being replicated > the entry has to be added by some client connection, can you get all > references to the entry ? > the log snippet you provide shows also csns with tag=103, which indicate a > MOD, are these MODs for the added entries ? or other mods ? > >> >> PROD:11:20:13-root@REPLICA:/var/log/dirsrv/slapd-DOM-DOM-DOM >> # grep -E '17/Aug/2016:13:50:4.*conn=602.*(RESULT|ADD)' access.2016081* >> access.20160817-124811:[17/Aug/2016:13:50:41 -0400] conn=602 op=4139 >> RESULT err=0 tag=120 nentries=0 etime=0 >> access.20160817-124811:[17/Aug/2016:13:50:41 -0400] conn=602 op=4140 >> RESULT err=0 tag=120 nentries=0 etime=0 >> access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4141 >> RESULT err=0 tag=120 nentries=0 etime=0 >> access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4142 >> RESULT err=0 tag=120 nentries=0 etime=0 >> access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4143 >> ADD >> dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom" >> access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4143 >> RESULT err=0 tag=105 nentries=0 etime=0 csn=57b4a4bb00030004 >> access.20160817-124811:[17/Aug/2016:13:50:44 -0400] conn=602 op=4144 >> RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4bb00040004 >> access.20160817-124811:[17/Aug/2016:13:50:44 -0400] conn=602 op=4145 >> RESULT err=0 tag=103 nentries=0 etime=0 >> access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4146 >> RESULT err=0 tag=120 nentries=0 etime=0 >> access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4147 >> RESULT err=0 tag=120 nentries=0 etime=0 >> access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4148 >> ADD >> dn="idnsname=server-6-4-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom" >> access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4148 >> RESULT err=0 tag=105 nentries=0 etime=0 csn=57b4a4bb00080004 >> access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4149 >> RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4bc00010004 >> access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4150 >> RESULT err=0 tag=103 nentries=0 etime=0 >> access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4151 >> ADD >> dn="idnsname=server-6-5-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom" >> access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4151 >> RESULT err=0 tag=105 nentries=0 etime=0 csn=57b4a4c100050004 >> access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4152 >> RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4c100060004 >> >> PROD:11:19:54-root@MASTER:/var/log/dirsrv/slapd-DOM-DOM-DOM >> # grep -E '17/Aug/2016:13:50:4.*conn=1395.*(RESULT|ADD)' access.2016081* >> access.20160817-111940:[17/Aug/2016:13:50:41 -0400] conn=1395 op=4148 >> RESULT err=0 tag=120 nentries=0 etime=0 >> access.20160817-111940:[17/Aug/2016:13:50:41 -0400] conn=1395 op=4149 >> RESULT err=0 tag=120 nentries=0 etime=0 >> access.20160817-111940:[17/Aug/2016:13:50:41 -0400] conn=1395 op=4150 >> RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4b900050016 >> access.20160817-111940:[17/Aug/2016:13:50:43 -0400] conn=1395 op=4151 >> ADD >> dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom" >> access.20160817-111940:[17/Aug/2016:13:50:43 -0400]
Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently
I am running my set up on AWS cloud, and entropy is low at around 180 . I plan to increase it bu installing haveged . But, would low entropy by any chance cause this issue of intermittent hang . Also, the hang is mostly observed when registering around 20 clients together On Fri, Aug 19, 2016 at 7:24 PM, Rakesh Rajasekharan < rakesh.rajasekha...@gmail.com> wrote: > yes there seems to be something thats worrying.. I have faced this today > as well. > There are few hosts around 280 odd left and when i try adding them to IPA > , the slowness begins.. > > all the ipa commands like ipa user-find.. etc becomes very slow in > responding. > > the SYNC_RECV are not many though just around 80-90 and today that was > around 20 only > > > I have for now increased tcp_max_syn_backlog to 5000. > For now the slowness seems to have gone.. but I will do a try adding the > clients again tomorrow and see how it goes > > Thanks > Rakesh > > The issues > > On Fri, Aug 19, 2016 at 12:58 PM, Petr Spacek wrote: > >> On 18.8.2016 17:23, Rakesh Rajasekharan wrote: >> > Hi >> > >> > I am migrating to freeipa from openldap and have around 4000 clients >> > >> > I had openned a another thread on that, but chose to start a new one >> here >> > as its a separate issue >> > >> > I was able to change the nssslapd-maxdescriptors adding an ldif file >> > >> > cat nsslapd-modify.ldif >> > dn: cn=config >> > changetype: modify >> > replace: nsslapd-maxdescriptors >> > nsslapd-maxdescriptors: 17000 >> > >> > and running the ldapmodify command >> > >> > I have now started moving clients running an openldap to Freeipa and >> have >> > today moved close to 2000 clients >> > >> > However, I have noticed that IPA hangs intermittently. >> > >> > running a kinit admin returns the below error >> > kinit: Generic error (see e-text) while getting initial credentials >> > >> > from the /var/log/messages, I see this entry >> > >> > prod-ipa-master-int kernel: [104090.315801] TCP: request_sock_TCP: >> > Possible SYN flooding on port 88. Sending cookies. Check SNMP counters. >> >> I would be worried about this message. Maybe kernel/firewall is doing >> something fishy behind your back and blocking some connections or so. >> >> Petr^2 Spacek >> >> >> > Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Started Session 4885 of >> > user root. >> > Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Starting Session 4885 of >> > user root. >> > Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Started Session 4886 of >> > user root. >> > Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Starting Session 4886 of >> > user root. >> > Aug 18 13:02:40 prod-ipa-master-int python[28984]: ansible-command >> Invoked >> > with creates=None executable=None shell=True args= removes=None >> warn=True >> > chdir=None >> > Aug 18 13:04:37 prod-ipa-master-int sssd_be: GSSAPI Error: Unspecified >> GSS >> > failure. Minor code may provide more information (KDC returned error >> > string: PROCESS_TGS) >> > >> > Could it be possible that its due to the initial load of adding the >> clients >> > or is there something else that I need to take care of. >> > >> > Thanks, >> > >> > Rakesh >> >> -- >> 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 >> > > -- 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
[Freeipa-users] Announcing SSSD 1.14.1
=== SSSD 1.14.1 ===
The SSSD team is proud to announce the release of version 1.14.1 of
the System Security Services Daemon.
As always, the source is available from https://fedorahosted.org/sssd
RPM packages will be made available for Fedora shortly.
== Feedback ==
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
== Highlights ==
* The IPA provider now supports logins with enterprise principals (also
known as additional UPN suffixes). This functionality also enabled Active
Directory users from trusted AD domains who use an additional UPN suffix
to log in. Please note that this feature requires a recent IPA server.
* When a user name is overriden in an IPA domain, resolving a group these
users are a member of now returns the overriden user names
* Users can be looked up by and log in with their e-mail address as an
identifier. In order to do so, an attribute that represents the user's
e-mail address is fetched by default. This attribute can by customized
by setting the ldap_user_email configuration option.
* A new ad_enabled_domains option was added. This option lets the
administrator select domains that SSSD should attempt to reach in the
AD forest SSSD is joined to. This option is useful for deployments where
not all domains are reachable on the network level, yet the administrator
needs to access some trusted domains and therefore disabling the subdomains
provider completely is not desirable.
* The sssctl tool has two new commands active-server and servers that
allow the administrator to observe the server that SSSD is bound to and
the servers that SSSD autodiscovered
* SSSD used to fail to start when an attribute name is present in both
the default SSSD attribute map and the custom ldap_user_extra_attrs map
* GPO policy procesing no longer fails if the gPCMachineExtensionNames
attribute only contains whitespaces
* Several commits fix regressions related to switching all user and group
names to fully qualified format, such as running initgroups for a user
who is only a member of a primary group
* Several patches fix regressions caused by splitting the database into
two ldb files, such as when user attributes change without increasing
the modifyTimestamp attribute value
* systemd unit files are now shipped for the sssd-secrets responder,
allowing the responder to be socket-activated. To do so, administrators
should enable the sssd-secrets.socket and sssd-secrets.service systemd
units.
* The sssd binary has a new switch --disable-netlink that lets sssd skip
messages from the kernel's netlink interface.
* A crash when entries with special characters such as '(' were requested
was fixed
* The ldap_rfc_2307_fallback_to_local_users option was broken in the
previous version. This release fixes the functionality.
== Packaging Changes ==
* The NFS ID-mapping plugin was moved to its own subpackage
== Documentation Changes ==
* A new option ad_enabled_domains was added
* A new LDAP attribute mapping for e-mail addresses called ldap_user_email
was added
== Tickets Fixed ==
https://fedorahosted.org/sssd/ticket/2789
Warn if ad_server contains IP address
https://fedorahosted.org/sssd/ticket/2828
Add an option to disable checking for trusted domains in the subdomains
provider
https://fedorahosted.org/sssd/ticket/2856
[RFE] Allow users to authenticate with alternative names
https://fedorahosted.org/sssd/ticket/2860
Add support for disabling netlink use
https://fedorahosted.org/sssd/ticket/2948
Handle overriden name of members in the memberUid attribute
https://fedorahosted.org/sssd/ticket/2958
Support multiple principals for IPA users
https://fedorahosted.org/sssd/ticket/2978
pid file name decalration is duplicated
https://fedorahosted.org/sssd/ticket/2987
Improve information about krb5_keytab & ldap_krb5_keytab option in sssd man
pages
https://fedorahosted.org/sssd/ticket/3009
sssd fails to mark a connection as bad on searches that time out
https://fedorahosted.org/sssd/ticket/3018
Detect of IPA server can handle enterprise principals
https://fedorahosted.org/sssd/ticket/3024
sssd-common brings in nfs-utils
https://fedorahosted.org/sssd/ticket/3064
incorrect dataExpireTimestamp setting in the timestamps cache
https://fedorahosted.org/sssd/ticket/3068
fixes to the initial config schema implementation
https://fedorahosted.org/sssd/ticket/3069
The sssctl tool should provide information about active and available
servers
https://fedorahosted.org/sssd/ticket/3072
task: Add a 1.14 upstream repo
https://fedorahosted.org/sssd/ticket/3077
sssd does not work under non-root user
https://fedorahosted.org/sssd/ticket/3084
DP: Don't pass empty string, but NULL to provi
Re: [Freeipa-users] dns/ldap failing after temporary storage problem
On 19.8.2016 16:13, Tiemen Ruiten wrote: > I did actually use a local dse.ldif in the end, but I forgot to stop dirsrv > while replacing it, so maybe the nsslapd-localhost line got updated by the > running dirsrv? Yes, that is possible. dirsrv can write to dse.ldif at run-time. > > On 19 August 2016 at 15:59, Petr Spacek wrote: > >> On 19.8.2016 15:26, Tiemen Ruiten wrote: >>> Managed to fix it: had to stop dirsrv@IPA-RDMEDIA-COM and put the >> server's >>> hostname on the line with nsslapd-localhost >> >> Uh, this is quite brutal. There might be some other server-specific >> options. >> >> If you can dig up older dse.ldif from the same server, I would rather >> restore >> that version. You never know what will silently break. >> >> Petr^2 Spacek >> >>> >>> Then run ipa-replica-manage re-initialize --from >>> other-master.ipa.rdmedia.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
Re: [Freeipa-users] dns/ldap failing after temporary storage problem
I did actually use a local dse.ldif in the end, but I forgot to stop dirsrv
while replacing it, so maybe the nsslapd-localhost line got updated by the
running dirsrv?
On 19 August 2016 at 15:59, Petr Spacek wrote:
> On 19.8.2016 15:26, Tiemen Ruiten wrote:
> > Managed to fix it: had to stop dirsrv@IPA-RDMEDIA-COM and put the
> server's
> > hostname on the line with nsslapd-localhost
>
> Uh, this is quite brutal. There might be some other server-specific
> options.
>
> If you can dig up older dse.ldif from the same server, I would rather
> restore
> that version. You never know what will silently break.
>
> Petr^2 Spacek
>
> >
> > Then run ipa-replica-manage re-initialize --from
> > other-master.ipa.rdmedia.com
> >
> > On 19 August 2016 at 12:14, Tiemen Ruiten wrote:
> >
> >> I see lots of messages /var/log/dirsrv/slapd-IPA-RDMEDIA-COM/errors,
> >> looks definitely like an issue with dirsrv.
> >>
> >> On 19 August 2016 at 11:43, Tiemen Ruiten wrote:
> >>
> >>> I see I didn't use the right terminology: all four of my FreeIPA
> servers
> >>> are masters.
> >>>
> >>> On 19 August 2016 at 11:36, Tiemen Ruiten
> wrote:
> >>>
> Hello,
>
> I need some help getting one of my replica's to work. Assistance would
> be much appreciated.
>
> After the iSCSI volumes of two replicas of were briefly unavailable,
> on
> one of them DNS and LDAP stopped working and replication seems to have
> stopped. The ipa service failed with a message that an upgrade was
> required, so I ran ipa-server-upgrade, but it failed due to an empty
> dse.ldif.
>
> Then I probably made a mistake by copying a dse.ldif from another
> replica and trying to run the upgrade. It worked more or less, but DNS
> still didn't work.
>
> Next I replaced it with an older backup file (from Aug 4) ran the
> upgrade command again and after some fiddling all services started
> normally, except ipa-dnskeysyncd:
>
> journalctl -u ipa-dnskeysyncd
>
> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]:
> ipa-dnskeysyncd.service holdoff time over, scheduling restart.
> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Started IPA
> key
> daemon.
> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Starting IPA
> key
> daemon...
> Aug 19 11:28:52 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> ipa:
> WARNING: session memcached servers not running
> Aug 19 11:28:53 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
> : INFO LDAP bind...
> Aug 19 11:28:53 promethium.ipa.rdmedia.com python2[3756]: GSSAPI
> client
> step 1
> Aug 19 11:28:54 promethium.ipa.rdmedia.com python2[3756]: GSSAPI
> client
> step 1
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
> : ERRORLogin to LDAP server failed: {'info': 'SASL(-1):
> generic
> failure: GSSAPI Error: Unspecified GSS failure. Minor code may
> provide
> more information (No key table entry found matching
> ldap/praseodymium.ipa.rdmedia.com@)', 'desc': 'Invalid credentials'}
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> Traceback (most recent call last):
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> File
> "/usr/libexec/ipa/ipa-dnskeysyncd", line 92, in
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> ldap_connection.sasl_interactive_bind_s("", ipaldap.SASL_GSSAPI)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> File
> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 850, in
> sasl_interactive_bind_s
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> res =
> self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_
> s,*args,**kwargs)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> File
> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 818, in
> _apply_method_s
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> return func(self,*args,**kwargs)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> File
> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
> sasl_interactive_bind_s
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,Req
> uestControlTuples(serverctrls),RequestControlTuples(clientct
> rls),sasl_flags)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> File
> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
> _ldap_call
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> result = func(*args,**kwargs)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysync
Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently
yes there seems to be something thats worrying.. I have faced this today as well. There are few hosts around 280 odd left and when i try adding them to IPA , the slowness begins.. all the ipa commands like ipa user-find.. etc becomes very slow in responding. the SYNC_RECV are not many though just around 80-90 and today that was around 20 only I have for now increased tcp_max_syn_backlog to 5000. For now the slowness seems to have gone.. but I will do a try adding the clients again tomorrow and see how it goes Thanks Rakesh The issues On Fri, Aug 19, 2016 at 12:58 PM, Petr Spacek wrote: > On 18.8.2016 17:23, Rakesh Rajasekharan wrote: > > Hi > > > > I am migrating to freeipa from openldap and have around 4000 clients > > > > I had openned a another thread on that, but chose to start a new one here > > as its a separate issue > > > > I was able to change the nssslapd-maxdescriptors adding an ldif file > > > > cat nsslapd-modify.ldif > > dn: cn=config > > changetype: modify > > replace: nsslapd-maxdescriptors > > nsslapd-maxdescriptors: 17000 > > > > and running the ldapmodify command > > > > I have now started moving clients running an openldap to Freeipa and have > > today moved close to 2000 clients > > > > However, I have noticed that IPA hangs intermittently. > > > > running a kinit admin returns the below error > > kinit: Generic error (see e-text) while getting initial credentials > > > > from the /var/log/messages, I see this entry > > > > prod-ipa-master-int kernel: [104090.315801] TCP: request_sock_TCP: > > Possible SYN flooding on port 88. Sending cookies. Check SNMP counters. > > I would be worried about this message. Maybe kernel/firewall is doing > something fishy behind your back and blocking some connections or so. > > Petr^2 Spacek > > > > Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Started Session 4885 of > > user root. > > Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Starting Session 4885 of > > user root. > > Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Started Session 4886 of > > user root. > > Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Starting Session 4886 of > > user root. > > Aug 18 13:02:40 prod-ipa-master-int python[28984]: ansible-command > Invoked > > with creates=None executable=None shell=True args= removes=None warn=True > > chdir=None > > Aug 18 13:04:37 prod-ipa-master-int sssd_be: GSSAPI Error: Unspecified > GSS > > failure. Minor code may provide more information (KDC returned error > > string: PROCESS_TGS) > > > > Could it be possible that its due to the initial load of adding the > clients > > or is there something else that I need to take care of. > > > > Thanks, > > > > Rakesh > > -- > 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 > -- 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
Re: [Freeipa-users] dns/ldap failing after temporary storage problem
On 19.8.2016 15:26, Tiemen Ruiten wrote:
> Managed to fix it: had to stop dirsrv@IPA-RDMEDIA-COM and put the server's
> hostname on the line with nsslapd-localhost
Uh, this is quite brutal. There might be some other server-specific options.
If you can dig up older dse.ldif from the same server, I would rather restore
that version. You never know what will silently break.
Petr^2 Spacek
>
> Then run ipa-replica-manage re-initialize --from
> other-master.ipa.rdmedia.com
>
> On 19 August 2016 at 12:14, Tiemen Ruiten wrote:
>
>> I see lots of messages /var/log/dirsrv/slapd-IPA-RDMEDIA-COM/errors,
>> looks definitely like an issue with dirsrv.
>>
>> On 19 August 2016 at 11:43, Tiemen Ruiten wrote:
>>
>>> I see I didn't use the right terminology: all four of my FreeIPA servers
>>> are masters.
>>>
>>> On 19 August 2016 at 11:36, Tiemen Ruiten wrote:
>>>
Hello,
I need some help getting one of my replica's to work. Assistance would
be much appreciated.
After the iSCSI volumes of two replicas of were briefly unavailable, on
one of them DNS and LDAP stopped working and replication seems to have
stopped. The ipa service failed with a message that an upgrade was
required, so I ran ipa-server-upgrade, but it failed due to an empty
dse.ldif.
Then I probably made a mistake by copying a dse.ldif from another
replica and trying to run the upgrade. It worked more or less, but DNS
still didn't work.
Next I replaced it with an older backup file (from Aug 4) ran the
upgrade command again and after some fiddling all services started
normally, except ipa-dnskeysyncd:
journalctl -u ipa-dnskeysyncd
Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]:
ipa-dnskeysyncd.service holdoff time over, scheduling restart.
Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Started IPA key
daemon.
Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Starting IPA key
daemon...
Aug 19 11:28:52 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa:
WARNING: session memcached servers not running
Aug 19 11:28:53 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
: INFO LDAP bind...
Aug 19 11:28:53 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
step 1
Aug 19 11:28:54 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
step 1
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
: ERRORLogin to LDAP server failed: {'info': 'SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more information (No key table entry found matching
ldap/praseodymium.ipa.rdmedia.com@)', 'desc': 'Invalid credentials'}
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
Traceback (most recent call last):
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/libexec/ipa/ipa-dnskeysyncd", line 92, in
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
ldap_connection.sasl_interactive_bind_s("", ipaldap.SASL_GSSAPI)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 850, in
sasl_interactive_bind_s
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: res =
self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_
s,*args,**kwargs)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 818, in
_apply_method_s
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
return func(self,*args,**kwargs)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
sasl_interactive_bind_s
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,Req
uestControlTuples(serverctrls),RequestControlTuples(clientct
rls),sasl_flags)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
_ldap_call
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
result = func(*args,**kwargs)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
INVALID_CREDENTIALS: {'info': 'SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (No key
table entry found matching ldap/praseodymium.ipa.rdmedia.com@)',
'desc': 'Invalid credentials'}
praseodymium.ipa.rdmedia.com is the replica I copied the dse.ldif from.
DNS and logins to the webinterface on this host are still not working.
Wha
Re: [Freeipa-users] dns/ldap failing after temporary storage problem
Managed to fix it: had to stop dirsrv@IPA-RDMEDIA-COM and put the server's
hostname on the line with nsslapd-localhost
Then run ipa-replica-manage re-initialize --from
other-master.ipa.rdmedia.com
On 19 August 2016 at 12:14, Tiemen Ruiten wrote:
> I see lots of messages /var/log/dirsrv/slapd-IPA-RDMEDIA-COM/errors,
> looks definitely like an issue with dirsrv.
>
> On 19 August 2016 at 11:43, Tiemen Ruiten wrote:
>
>> I see I didn't use the right terminology: all four of my FreeIPA servers
>> are masters.
>>
>> On 19 August 2016 at 11:36, Tiemen Ruiten wrote:
>>
>>> Hello,
>>>
>>> I need some help getting one of my replica's to work. Assistance would
>>> be much appreciated.
>>>
>>> After the iSCSI volumes of two replicas of were briefly unavailable, on
>>> one of them DNS and LDAP stopped working and replication seems to have
>>> stopped. The ipa service failed with a message that an upgrade was
>>> required, so I ran ipa-server-upgrade, but it failed due to an empty
>>> dse.ldif.
>>>
>>> Then I probably made a mistake by copying a dse.ldif from another
>>> replica and trying to run the upgrade. It worked more or less, but DNS
>>> still didn't work.
>>>
>>> Next I replaced it with an older backup file (from Aug 4) ran the
>>> upgrade command again and after some fiddling all services started
>>> normally, except ipa-dnskeysyncd:
>>>
>>> journalctl -u ipa-dnskeysyncd
>>>
>>> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]:
>>> ipa-dnskeysyncd.service holdoff time over, scheduling restart.
>>> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Started IPA key
>>> daemon.
>>> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Starting IPA key
>>> daemon...
>>> Aug 19 11:28:52 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa:
>>> WARNING: session memcached servers not running
>>> Aug 19 11:28:53 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
>>> : INFO LDAP bind...
>>> Aug 19 11:28:53 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
>>> step 1
>>> Aug 19 11:28:54 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
>>> step 1
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
>>> : ERRORLogin to LDAP server failed: {'info': 'SASL(-1): generic
>>> failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
>>> more information (No key table entry found matching
>>> ldap/praseodymium.ipa.rdmedia.com@)', 'desc': 'Invalid credentials'}
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
>>> Traceback (most recent call last):
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>>> "/usr/libexec/ipa/ipa-dnskeysyncd", line 92, in
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
>>> ldap_connection.sasl_interactive_bind_s("", ipaldap.SASL_GSSAPI)
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 850, in
>>> sasl_interactive_bind_s
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: res =
>>> self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_
>>> s,*args,**kwargs)
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 818, in
>>> _apply_method_s
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
>>> return func(self,*args,**kwargs)
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
>>> sasl_interactive_bind_s
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
>>> return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,Req
>>> uestControlTuples(serverctrls),RequestControlTuples(clientct
>>> rls),sasl_flags)
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
>>> _ldap_call
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
>>> result = func(*args,**kwargs)
>>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
>>> INVALID_CREDENTIALS: {'info': 'SASL(-1): generic failure: GSSAPI Error:
>>> Unspecified GSS failure. Minor code may provide more information (No key
>>> table entry found matching ldap/praseodymium.ipa.rdmedia.com@)',
>>> 'desc': 'Invalid credentials'}
>>>
>>> praseodymium.ipa.rdmedia.com is the replica I copied the dse.ldif from.
>>> DNS and logins to the webinterface on this host are still not working.
>>>
>>> What can I do to get this replica in working order again?
>>>
>>> --
>>> Tiemen Ruiten
>>> Systems Engineer
>>> R&D Media
>>>
>>
>>
>>
>> --
>> Tiemen Ruiten
>> Systems Engineer
>> R&D Media
>>
>
>
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
>
--
Tiemen Ruiten
Systems Engineer
R&D Media
--
Manage your subscription for the Freeipa-users mailing list:
https://ww
Re: [Freeipa-users] replica_generate_next_csn messages in dirsrv error logs
On 08/18/2016 05:28 PM, John Desantis wrote: Ludwig, unfortunately this is not enough to determine what is going on. The intersting generated/used csn is only logged in the corresponding RESULT message and these are only the replication connections, it would be necessary to see the original ADD operation, was it added once or twice by a client ? you could pick one entry eg server-6-3-sp and grep for all references in the access logs of both servers (maybe there are mods as well) and then get also get the RESULT line for the ops found Here are the updated log snippets looking for ADD and RESULT: you still only grep the replication connection, but before being replicated the entry has to be added by some client connection, can you get all references to the entry ? the log snippet you provide shows also csns with tag=103, which indicate a MOD, are these MODs for the added entries ? or other mods ? PROD:11:20:13-root@REPLICA:/var/log/dirsrv/slapd-DOM-DOM-DOM # grep -E '17/Aug/2016:13:50:4.*conn=602.*(RESULT|ADD)' access.2016081* access.20160817-124811:[17/Aug/2016:13:50:41 -0400] conn=602 op=4139 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-124811:[17/Aug/2016:13:50:41 -0400] conn=602 op=4140 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4141 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4142 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4143 ADD dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom" access.20160817-124811:[17/Aug/2016:13:50:42 -0400] conn=602 op=4143 RESULT err=0 tag=105 nentries=0 etime=0 csn=57b4a4bb00030004 access.20160817-124811:[17/Aug/2016:13:50:44 -0400] conn=602 op=4144 RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4bb00040004 access.20160817-124811:[17/Aug/2016:13:50:44 -0400] conn=602 op=4145 RESULT err=0 tag=103 nentries=0 etime=0 access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4146 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4147 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4148 ADD dn="idnsname=server-6-4-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom" access.20160817-124811:[17/Aug/2016:13:50:47 -0400] conn=602 op=4148 RESULT err=0 tag=105 nentries=0 etime=0 csn=57b4a4bb00080004 access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4149 RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4bc00010004 access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4150 RESULT err=0 tag=103 nentries=0 etime=0 access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4151 ADD dn="idnsname=server-6-5-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom" access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4151 RESULT err=0 tag=105 nentries=0 etime=0 csn=57b4a4c100050004 access.20160817-124811:[17/Aug/2016:13:50:49 -0400] conn=602 op=4152 RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4c100060004 PROD:11:19:54-root@MASTER:/var/log/dirsrv/slapd-DOM-DOM-DOM # grep -E '17/Aug/2016:13:50:4.*conn=1395.*(RESULT|ADD)' access.2016081* access.20160817-111940:[17/Aug/2016:13:50:41 -0400] conn=1395 op=4148 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-111940:[17/Aug/2016:13:50:41 -0400] conn=1395 op=4149 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-111940:[17/Aug/2016:13:50:41 -0400] conn=1395 op=4150 RESULT err=0 tag=103 nentries=0 etime=0 csn=57b4a4b900050016 access.20160817-111940:[17/Aug/2016:13:50:43 -0400] conn=1395 op=4151 ADD dn="idnsname=server-6-3-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom" access.20160817-111940:[17/Aug/2016:13:50:43 -0400] conn=1395 op=4151 RESULT err=0 tag=105 nentries=0 etime=0 access.20160817-111940:[17/Aug/2016:13:50:44 -0400] conn=1395 op=4152 RESULT err=0 tag=103 nentries=0 etime=1 csn=57b4a4bc0016 access.20160817-111940:[17/Aug/2016:13:50:46 -0400] conn=1395 op=4153 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-111940:[17/Aug/2016:13:50:47 -0400] conn=1395 op=4154 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-111940:[17/Aug/2016:13:50:47 -0400] conn=1395 op=4155 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-111940:[17/Aug/2016:13:50:47 -0400] conn=1395 op=4156 RESULT err=0 tag=120 nentries=0 etime=0 access.20160817-111940:[17/Aug/2016:13:50:48 -0400] conn=1395 op=4157 RESULT err=0 tag=103 nentries=0 etime=1 csn=57b4a4c100010016 access.20160817-111940:[17/Aug/2016:13:50:49 -0400] conn=1395 op=4158 ADD dn="idnsname=server-6-5-sp,idnsname=dom.dom.dom,cn=dns,dc=dom,dc=dom,dc=dom" access.20160817-111940:[17/Aug/2016:13:50:49 -0400] conn=1395 op=4158 RESULT err=0 tag=105 nentries=0 etime=0 access.20160817-111940:[17/Aug/2016:13:50:49 -0400] conn=1395 op=4159 RESULT err=0 tag=103 nentries
Re: [Freeipa-users] Login problems
Hi Jakub, The web UI, and also services that are connected to FreeIPA via LDAP gave me an invalid credentials error. I have this 2-3 times in the past days. I can not see anything in error log or any other log for the times i tried to connect. I have no idea what could go wrong…. Thanks, > On 19 Aug 2016, at 13:24, Jakub Hrozek wrote: > > On Fri, Aug 19, 2016 at 10:20:48AM +, Christophe TREFOIS wrote: >> Hi, >> >> We have a 3 way replica against one master. So there is only agreements >> between 1 and 2 and 1 and 3. >> >> Since recently sometimes the master does not allow me to login anymore, >> whereas I can login fine to 2 and 3. After a few minutes everything comes >> back to normal and it works. >> >> The master is on centos 7 v4.2 and is still connected to an old 3 replica >> running F21. We plan to disconnect this agreement in the coming weeks. >> >> Does anybody have seen this before or have a clue what could be going on >> here? > > Login where, the web UI or to the machine itself? > > -- > 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 -- 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
Re: [Freeipa-users] Login problems
On Fri, Aug 19, 2016 at 10:20:48AM +, Christophe TREFOIS wrote: > Hi, > > We have a 3 way replica against one master. So there is only agreements > between 1 and 2 and 1 and 3. > > Since recently sometimes the master does not allow me to login anymore, > whereas I can login fine to 2 and 3. After a few minutes everything comes > back to normal and it works. > > The master is on centos 7 v4.2 and is still connected to an old 3 replica > running F21. We plan to disconnect this agreement in the coming weeks. > > Does anybody have seen this before or have a clue what could be going on here? Login where, the web UI or to the machine itself? -- 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
[Freeipa-users] Login problems
Hi, We have a 3 way replica against one master. So there is only agreements between 1 and 2 and 1 and 3. Since recently sometimes the master does not allow me to login anymore, whereas I can login fine to 2 and 3. After a few minutes everything comes back to normal and it works. The master is on centos 7 v4.2 and is still connected to an old 3 replica running F21. We plan to disconnect this agreement in the coming weeks. Does anybody have seen this before or have a clue what could be going on here? Any help is welcome. Thank you, Christophe Sent from my iPhone smime.p7s Description: S/MIME cryptographic signature -- 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
Re: [Freeipa-users] dns/ldap failing after temporary storage problem
I see lots of messages /var/log/dirsrv/slapd-IPA-RDMEDIA-COM/errors, looks
definitely like an issue with dirsrv.
On 19 August 2016 at 11:43, Tiemen Ruiten wrote:
> I see I didn't use the right terminology: all four of my FreeIPA servers
> are masters.
>
> On 19 August 2016 at 11:36, Tiemen Ruiten wrote:
>
>> Hello,
>>
>> I need some help getting one of my replica's to work. Assistance would be
>> much appreciated.
>>
>> After the iSCSI volumes of two replicas of were briefly unavailable, on
>> one of them DNS and LDAP stopped working and replication seems to have
>> stopped. The ipa service failed with a message that an upgrade was
>> required, so I ran ipa-server-upgrade, but it failed due to an empty
>> dse.ldif.
>>
>> Then I probably made a mistake by copying a dse.ldif from another replica
>> and trying to run the upgrade. It worked more or less, but DNS still didn't
>> work.
>>
>> Next I replaced it with an older backup file (from Aug 4) ran the upgrade
>> command again and after some fiddling all services started normally, except
>> ipa-dnskeysyncd:
>>
>> journalctl -u ipa-dnskeysyncd
>>
>> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]:
>> ipa-dnskeysyncd.service holdoff time over, scheduling restart.
>> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Started IPA key
>> daemon.
>> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Starting IPA key
>> daemon...
>> Aug 19 11:28:52 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa:
>> WARNING: session memcached servers not running
>> Aug 19 11:28:53 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
>> : INFO LDAP bind...
>> Aug 19 11:28:53 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
>> step 1
>> Aug 19 11:28:54 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
>> step 1
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
>> : ERRORLogin to LDAP server failed: {'info': 'SASL(-1): generic
>> failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
>> more information (No key table entry found matching
>> ldap/praseodymium.ipa.rdmedia.com@)', 'desc': 'Invalid credentials'}
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
>> Traceback (most recent call last):
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>> "/usr/libexec/ipa/ipa-dnskeysyncd", line 92, in
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
>> ldap_connection.sasl_interactive_bind_s("", ipaldap.SASL_GSSAPI)
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 850, in
>> sasl_interactive_bind_s
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: res =
>> self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_
>> s,*args,**kwargs)
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 818, in
>> _apply_method_s
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: return
>> func(self,*args,**kwargs)
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
>> sasl_interactive_bind_s
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: return
>> self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,Req
>> uestControlTuples(serverctrls),RequestControlTuples(clientct
>> rls),sasl_flags)
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
>> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
>> _ldap_call
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: result
>> = func(*args,**kwargs)
>> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
>> INVALID_CREDENTIALS: {'info': 'SASL(-1): generic failure: GSSAPI Error:
>> Unspecified GSS failure. Minor code may provide more information (No key
>> table entry found matching ldap/praseodymium.ipa.rdmedia.com@)', 'desc':
>> 'Invalid credentials'}
>>
>> praseodymium.ipa.rdmedia.com is the replica I copied the dse.ldif from.
>> DNS and logins to the webinterface on this host are still not working.
>>
>> What can I do to get this replica in working order again?
>>
>> --
>> Tiemen Ruiten
>> Systems Engineer
>> R&D Media
>>
>
>
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
>
--
Tiemen Ruiten
Systems Engineer
R&D Media
errors.gz
Description: GNU Zip compressed data
--
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
Re: [Freeipa-users] dns/ldap failing after temporary storage problem
I see I didn't use the right terminology: all four of my FreeIPA servers
are masters.
On 19 August 2016 at 11:36, Tiemen Ruiten wrote:
> Hello,
>
> I need some help getting one of my replica's to work. Assistance would be
> much appreciated.
>
> After the iSCSI volumes of two replicas of were briefly unavailable, on
> one of them DNS and LDAP stopped working and replication seems to have
> stopped. The ipa service failed with a message that an upgrade was
> required, so I ran ipa-server-upgrade, but it failed due to an empty
> dse.ldif.
>
> Then I probably made a mistake by copying a dse.ldif from another replica
> and trying to run the upgrade. It worked more or less, but DNS still didn't
> work.
>
> Next I replaced it with an older backup file (from Aug 4) ran the upgrade
> command again and after some fiddling all services started normally, except
> ipa-dnskeysyncd:
>
> journalctl -u ipa-dnskeysyncd
>
> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]:
> ipa-dnskeysyncd.service holdoff time over, scheduling restart.
> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Started IPA key
> daemon.
> Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Starting IPA key
> daemon...
> Aug 19 11:28:52 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa:
> WARNING: session memcached servers not running
> Aug 19 11:28:53 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
> : INFO LDAP bind...
> Aug 19 11:28:53 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
> step 1
> Aug 19 11:28:54 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
> step 1
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
> : ERRORLogin to LDAP server failed: {'info': 'SASL(-1): generic
> failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
> more information (No key table entry found matching
> ldap/praseodymium.ipa.rdmedia.com@)', 'desc': 'Invalid credentials'}
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> Traceback (most recent call last):
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
> "/usr/libexec/ipa/ipa-dnskeysyncd", line 92, in
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> ldap_connection.sasl_interactive_bind_s("", ipaldap.SASL_GSSAPI)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 850, in
> sasl_interactive_bind_s
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: res =
> self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_s,*args,**
> kwargs)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 818, in
> _apply_method_s
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: return
> func(self,*args,**kwargs)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
> sasl_interactive_bind_s
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: return
> self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,
> RequestControlTuples(serverctrls),RequestControlTuples(
> clientctrls),sasl_flags)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
> "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
> _ldap_call
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: result
> = func(*args,**kwargs)
> Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
> INVALID_CREDENTIALS: {'info': 'SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure. Minor code may provide more information (No key
> table entry found matching ldap/praseodymium.ipa.rdmedia.com@)', 'desc':
> 'Invalid credentials'}
>
> praseodymium.ipa.rdmedia.com is the replica I copied the dse.ldif from.
> DNS and logins to the webinterface on this host are still not working.
>
> What can I do to get this replica in working order again?
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
>
--
Tiemen Ruiten
Systems Engineer
R&D Media
--
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
[Freeipa-users] dns/ldap failing after temporary storage problem
Hello,
I need some help getting one of my replica's to work. Assistance would be
much appreciated.
After the iSCSI volumes of two replicas of were briefly unavailable, on one
of them DNS and LDAP stopped working and replication seems to have stopped.
The ipa service failed with a message that an upgrade was required, so I
ran ipa-server-upgrade, but it failed due to an empty dse.ldif.
Then I probably made a mistake by copying a dse.ldif from another replica
and trying to run the upgrade. It worked more or less, but DNS still didn't
work.
Next I replaced it with an older backup file (from Aug 4) ran the upgrade
command again and after some fiddling all services started normally, except
ipa-dnskeysyncd:
journalctl -u ipa-dnskeysyncd
Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]:
ipa-dnskeysyncd.service holdoff time over, scheduling restart.
Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Started IPA key
daemon.
Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Starting IPA key
daemon...
Aug 19 11:28:52 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa:
WARNING: session memcached servers not running
Aug 19 11:28:53 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
: INFO LDAP bind...
Aug 19 11:28:53 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
step 1
Aug 19 11:28:54 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
step 1
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
: ERRORLogin to LDAP server failed: {'info': 'SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more information (No key table entry found matching
ldap/praseodymium.ipa.rdmedia.com@)', 'desc': 'Invalid credentials'}
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: Traceback
(most recent call last):
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/libexec/ipa/ipa-dnskeysyncd", line 92, in
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
ldap_connection.sasl_interactive_bind_s("", ipaldap.SASL_GSSAPI)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 850, in
sasl_interactive_bind_s
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: res =
self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_s,*args,**kwargs)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 818, in
_apply_method_s
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: return
func(self,*args,**kwargs)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
sasl_interactive_bind_s
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
_ldap_call
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: result =
func(*args,**kwargs)
Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
INVALID_CREDENTIALS: {'info': 'SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (No key
table entry found matching ldap/praseodymium.ipa.rdmedia.com@)', 'desc':
'Invalid credentials'}
praseodymium.ipa.rdmedia.com is the replica I copied the dse.ldif from. DNS
and logins to the webinterface on this host are still not working.
What can I do to get this replica in working order again?
--
Tiemen Ruiten
Systems Engineer
R&D Media
--
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
Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently
On 18.8.2016 17:23, Rakesh Rajasekharan wrote: > Hi > > I am migrating to freeipa from openldap and have around 4000 clients > > I had openned a another thread on that, but chose to start a new one here > as its a separate issue > > I was able to change the nssslapd-maxdescriptors adding an ldif file > > cat nsslapd-modify.ldif > dn: cn=config > changetype: modify > replace: nsslapd-maxdescriptors > nsslapd-maxdescriptors: 17000 > > and running the ldapmodify command > > I have now started moving clients running an openldap to Freeipa and have > today moved close to 2000 clients > > However, I have noticed that IPA hangs intermittently. > > running a kinit admin returns the below error > kinit: Generic error (see e-text) while getting initial credentials > > from the /var/log/messages, I see this entry > > prod-ipa-master-int kernel: [104090.315801] TCP: request_sock_TCP: > Possible SYN flooding on port 88. Sending cookies. Check SNMP counters. I would be worried about this message. Maybe kernel/firewall is doing something fishy behind your back and blocking some connections or so. Petr^2 Spacek > Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Started Session 4885 of > user root. > Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Starting Session 4885 of > user root. > Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Started Session 4886 of > user root. > Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Starting Session 4886 of > user root. > Aug 18 13:02:40 prod-ipa-master-int python[28984]: ansible-command Invoked > with creates=None executable=None shell=True args= removes=None warn=True > chdir=None > Aug 18 13:04:37 prod-ipa-master-int sssd_be: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (KDC returned error > string: PROCESS_TGS) > > Could it be possible that its due to the initial load of adding the clients > or is there something else that I need to take care of. > > Thanks, > > Rakesh -- 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
Re: [Freeipa-users] Admin password no more working
On 08/18/2016 04:16 PM, Deepak Dimri wrote: > Hi All, > > While trying to automate IPA client registration programatically, i seems > have > made my admin password out of sync between KDC and > /etc/krb5.keytab. This looks confusing, admin password and /etc/krb5.keytab do not look related. The keytab is for host keytab. > Now when i try login into ipa GUI via admin i am getting "The > password or username is incorrect" - though i am trying with the correct > password that i have been using. Is there anyway i can login to GUI in this > situation? Is there anyway i can get my admin password reseted or something? > i > can run my ansible playbooks w/out any issues on the linux host but cannot > login > to GUI any more... Can you log in to GUI with other logins. If not, then check this page: http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI Martin -- 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
