From abokovoy at redhat.com Thu Sep 1 03:25:39 2016
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 1 Sep 2016 06:25:39 +0300
Subject: [Freeipa-users] pfSense/FreeIPA LDAP Extended Query Fails
In-Reply-To: <34BE6DEF-B105-45E0-BA21-EEC47416FE2A@flowjo.com>
References: <34BE6DEF-B105-45E0-BA21-EEC47416FE2A@flowjo.com>
Message-ID: <20160901032538.xmw4gkidnkf54gnu@redhat.com>
On Wed, 31 Aug 2016, Mike Jacobacci wrote:
>Hi,
>
>I have just got authentication against my FreeIPA system working by
>following this: https://ask.fedoraproject.org/en/que...uthentication/
>
>
>The only change I had to make was to set the Search Scope level to
>"entire subtree" and I also left the extended query unchecked... With
>that setup I am able to authenticate using
>"Diagnostics->Authentication".
>
>I really want to restrict access so I can use FreeIPA for our VPN auth
>so I tried using the following extended query but it fails:
>&(memberOf=cn=admins,cn=groups,cn=accounts,dc=doma in,dc=com)
>
>Looking in pfSense logs, using the extended query (fails):
>
>[24/Aug/2016:11:07:16 -0700] conn=1396 fd=116 slot=116 SSL connection from * to *
>[24/Aug/2016:11:07:16 -0700] conn=1396 TLS1.2 256-bit AES-GCM
>[24/Aug/2016:11:07:16 -0700] conn=1396 op=0 BIND dn="" method=128 version=3
>[24/Aug/2016:11:07:16 -0700] conn=1396 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
>[24/Aug/2016:11:07:16 -0700] conn=1396 op=1 SRCH base="cn=accounts,dc=domain,dc=com" scope=2 filter="(&(uid=user)(&(memberOf=cn=admins,cn=group s,cn=accounts,dc=domain,dc=com)))" attrs=ALL
>[24/Aug/2016:11:07:16 -0700] conn=1396 op=1 RESULT err=0 tag=101 nentries=0 etime=0
>[24/Aug/2016:11:07:16 -0700] conn=1396 op=2 UNBIND
>[24/Aug/2016:11:07:16 -0700] conn=1396 op=2 fd=116 closed - U1
>
>Without the query (success):
>[30/Aug/2016:10:23:25 -0700] conn=6432 fd=110 slot=110 SSL connection from * to *
>[30/Aug/2016:10:23:25 -0700] conn=6432 TLS1.2 256-bit AES-GCM
>[30/Aug/2016:10:23:25 -0700] conn=6432 op=0 BIND dn="" method=128 version=3
>[30/Aug/2016:10:23:25 -0700] conn=6432 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
>[30/Aug/2016:10:23:25 -0700] conn=6432 op=1 SRCH base="cn=compat,dc=domain,dc=com" scope=2 filter="(uid=user1)? attrs=ALL
>[30/Aug/2016:10:23:25 -0700] conn=6432 op=1 RESULT err=0 tag=101 nentries=1 etime=0
>[30/Aug/2016:10:23:25 -0700] conn=6432 op=2 BIND dn="uid=user1,cn=users,cn=compat,dc=domain,dc=com " method=128 version=3
>[30/Aug/2016:10:23:25 -0700] conn=6432 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=user1,cn=users,cn=accounts,dc=domain,dc=co m"
>[30/Aug/2016:10:23:25 -0700] conn=6433 fd=118 slot=118 SSL connection from * to *
>[30/Aug/2016:10:23:25 -0700] conn=6432 op=3 UNBIND
>[30/Aug/2016:10:23:25 -0700] conn=6432 op=3 fd=110 closed - U1
>[30/Aug/2016:10:23:25 -0700] conn=6433 TLS1.2 256-bit AES-GCM
>[30/Aug/2016:10:23:25 -0700] conn=6433 op=0 BIND dn="" method=128 version=3
>[30/Aug/2016:10:23:25 -0700] conn=6433 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
>[30/Aug/2016:10:23:25 -0700] conn=6433 op=1 SRCH base="uid=user1,cn=users,cn=compat,dc=domain,dc=co m" scope=2 filter="(uid=user1)? attrs="memberOf"
>[30/Aug/2016:10:23:25 -0700] conn=6433 op=1 RESULT err=0 tag=101 nentries=1 etime=0
>[30/Aug/2016:10:23:25 -0700] conn=6433 op=2 UNBIND
>[30/Aug/2016:10:23:25 -0700] conn=6433 op=2 fd=118 closed - U1
>
>I changed the cn from accounts to compat for the auth container, but
>that doesn't make a difference. The last search shows attrs="memberOf",
>but anytime I add an extended query the logs show attrs="all", not sure
>if that means anything. I tried adding the full memberOf path under the
>group member attribute, but that didn't restrict access although the
>auth is still success.
>
>[30/Aug/2016:10:42:12 -0700] conn=6460 op=1 SRCH base="uid=user3,cn=users,cn=compat,dc=domain,dc=co m" scope=2 filter="(uid=user3)" attrs="memberof=cn=admins,cn=groups,cn=compat,dc=d omain,dc=com"
>[30/Aug/2016:10:42:12 -0700] conn=6460 op=1 RESULT err=0 tag=101 nentries=1 etime=0
>
>When doing an ldapsearch, I can see the group:
>
># admins, groups, compat, domain.com
>dn: cn=admins,cn=groups,cn=compat,dc=domain,dc=com
>ipaAnchorUUID::
>gidNumber: 50000
>memberUid: admin
>memberUid: user1
>memberUid: user2
>objectClass: posixGroup
>objectClass: ipaOverrideTarget
>objectClass: ipaexternalgroup
>objectClass: top
>cn: admins
>
>Any help would be greatly appreciated.
FreeIPA 4.x requires authenticated bind to be able to see member
attributes of the groups in the main subtree. Your pfSense is using
anonymous bind, thus not being able to see them.
Also, don't use cn=compat,$suffix subtree, it does not help for your task.
Your pfSense device expects different schema than the one provided by
the Compatibility Tree.
--
/ Alexander Bokovoy
From a.rogovsky at gmail.com Thu Sep 1 03:55:50 2016
From: a.rogovsky at gmail.com (Andrey Rogovsky)
Date: Thu, 1 Sep 2016 06:55:50 +0300
Subject: [Freeipa-users] Command-line replication is not works in
FreeIPA-Master
In-Reply-To: <4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
References:
<4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
Message-ID:
Hi!
Thanks for your advices!
I'm try start replica and get this errors in log:
[01/Sep/2016:03:24:23 +0000] slapi_ldap_bind - Error: could not bind id
[cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error
32 (No such object) errno 0 (Success)
[01/Sep/2016:03:24:23 +0000] NSMMReplicationPlugin -
agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
failed: LDAP error 32 (No such object) ()
This is my current replica:
filter: (objectclass=nsds5replica)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=nsds5replica)
# requesting: ALL
#
# replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replica
objectClass: extensibleObject
cn: replica
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaId: 7
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsState:: BwAAAAAAAADqnMdXAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
nsDS5ReplicaName: 496dba82-6f7a11e6-9d5ba359-5196ffe4
nsds5ReplicaChangeCount: 118
nsds5replicareapactive: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
This is my current agreement:
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=nsds5ReplicationAgreement)
# requesting: ALL
#
# ExampleAgreement, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
dn: cn=ExampleAgreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,
cn=config
objectClass: top
objectClass: nsds5replicationagreement
cn: ExampleAgreement
nsDS5ReplicaHost: ldap2
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaRoot: dc=example,dc=com
description: agreement between supplier1 and consumer1
nsDS5ReplicaUpdateSchedule: 0000-0500 1
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE
authorityRevocationLis
t
nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
RERBNEJDUmxPVFl4TlRsbU5DMWtaV0UyTXpZeA0KTVMxaU1UYzFaREF3Wmkwek5qRmxNalkxWkFBQ
0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQU1Dc25vTkVzZVJ4b3
N2WVlEMXRpbQ==}a21h3uqnbcAZ1cX+NheCeg==
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 19700101000000Z
nsds5replicaLastUpdateEnd: 19700101000000Z
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: 0 No replication sessions started since
server s
tartup
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 20160901032423Z
nsds5replicaLastInitEnd: 19700101000000Z
nsds5replicaLastInitStatus: 32 - LDAP error: No such object
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
I'm try delete agreement, replica, user, changelog and create again. This
not help, same error:
[01/Sep/2016:03:42:37 +0000] NSMMReplicationPlugin - agmt_delete: begin
[01/Sep/2016:03:45:35 +0000] NSMMReplicationPlugin - replica_config_delete:
Warning: The changelog for replica dc=example,dc=com is no longer valid
since the replica config is being deleted. Removing the changelog.
[01/Sep/2016:03:53:18 +0000] slapi_ldap_bind - Error: could not bind id
[cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error
32 (No such object) errno 0 (Success)
[01/Sep/2016:03:53:18 +0000] NSMMReplicationPlugin -
agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
failed: LDAP error 32 (No such object) ()
2016-08-31 20:09 GMT+03:00 Mark Reynolds :
>
>
> On 08/31/2016 12:39 PM, Andrey Rogovsky wrote:
>
> Hi, Mark!
>
> Thanks for explain. Now I create replication manager: (I hope)
> [root at ldap1 ~]# ldapsearch -h ldap1.example.com -p 389 -xLLL -D
> "cn=directory manager" -W -b cn=config "cn=replication manager"
> Enter LDAP Password:
> dn: cn=replication manager,cn=config
> objectClass: inetorgperson
> objectClass: person
> objectClass: top
> objectClass: organizationalPerson
> cn: replication manager
> sn: RM
> userPassword:: e1NTSEF9N1JiRmNXWTFXNDA1cmdYSU
> dCNWJtV3RzOElNQXBhakhXam94WlE9PQ=
> =
>
> What is next? I use manual from 8 version and this a bit obsoleted.
>
> Now you should be able to initialize your standalone server by updating
> the agreement on the ipa DS:
>
> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
> tree,cn=config
> changetype: modify
> replace: nsds5beginreplicarefresh
> nsds5beginreplicarefresh: start
>
> If something goes wrong let us know what's in the errors log again.
>
> Mark
>
>
>
> 2016-08-31 19:30 GMT+03:00 Mark Reynolds :
>
>> Hi Andrey,
>>
>> It looks like you still did not create the replication manager entry.
>> You must create that manager entry on the standalone server. Please read
>> the link I sent you:
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Direct
>> ory_Server/10/html/Administration_Guide/Creating_the_Supplie
>> r_Bind_DN_Entry.html
>>
>> You can verify its existence by doing this search against the standalone
>> server:
>>
>> ldapsearch -h ldap1.example.com -p 389 -xLLL -D "cn=directory manager"
>> -W -b cn=config "cn=replication manager"
>>
>> Mark
>>
>>
>> On 08/31/2016 11:50 AM, Andrey Rogovsky wrote:
>>
>> Hi!
>> Thank you for fast reply.
>> Yes, I want use standalone 389DS to replica from FreeIPA.
>> There is my replica:
>> filter: (objectclass=nsds5replica)
>> requesting: All userApplication attributes
>> # extended LDIF
>> #
>> # LDAPv3
>> # base with scope subtree
>> # filter: (objectclass=nsds5replica)
>> # requesting: ALL
>> #
>>
>> # replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
>> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
>> objectClass: top
>> objectClass: nsds5replica
>> objectClass: extensibleObject
>> cn: replica
>> nsDS5ReplicaRoot: dc=example,dc=com
>> nsDS5ReplicaId: 7
>> nsDS5ReplicaType: 3
>> nsDS5Flags: 1
>> nsds5ReplicaPurgeDelay: 604800
>> nsDS5ReplicaBindDN: cn=replication manager,cn=config
>> nsState:: BwAAAAAAAABZ98ZXAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
>> nsDS5ReplicaName: 496dba82-6f7a11e6-9d5ba359-5196ffe4
>> nsds5ReplicaChangeCount: 22
>> nsds5replicareapactive: 0
>>
>> # search result
>> search: 2
>> result: 0 Success
>>
>> # numResponses: 2
>> # numEntries: 1
>>
>> So, my replica have entry "cn=replication manager"
>>
>> But I try add entry in agreement. Unforthunalty this is not help, error
>> is present:
>> [root at ldap1 ~]# ldapmodify -v -h ldap1.example.com -p 389 -D
>> "cn=directory manager" -w ...
>> ldap_initialize( ldap://ldap1.example.com:389 )
>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>> tree,cn=config
>> changetype: modify
>> replace: nsds5ReplicaBindDN
>> nsds5ReplicaBindDN: cn=replication manager,cn=config
>> replace nsds5ReplicaBindDN:
>> cn=replication manager,cn=config
>> modifying entry "cn=ExampleAgreement,cn=replic
>> a,cn="dc=example,dc=com",cn=mapping tree,cn=config"
>> modify complete
>>
>> [root at ldap1 ~]# tail -f /var/log/dirsrv/slapd-EXAMPLE-COM/errors
>> [31/Aug/2016:11:11:09 +0000] schema-compat-plugin - schema-compat-plugin
>> tree scan will start in about 5 seconds!
>> [31/Aug/2016:11:11:09 +0000] - slapd started. Listening on All
>> Interfaces port 389 for LDAP requests
>> [31/Aug/2016:11:11:09 +0000] - Listening on All Interfaces port 636 for
>> LDAPS requests
>> [31/Aug/2016:11:11:09 +0000] - Listening on /var/run/slapd-EXAMPLE-COM.socket
>> for LDAPI requests
>> [31/Aug/2016:11:11:13 +0000] schema-compat-plugin - warning: no entries
>> set up under ou=sudoers,dc=example,dc=com
>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>> set up under cn=ng, cn=compat,dc=example,dc=com
>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>> set up under cn=computers, cn=compat,dc=example,dc=com
>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - Finished plugin
>> initialization.
>> [31/Aug/2016:13:38:01 +0000] slapi_ldap_bind - Error: could not bind id
>> [cn=replication manager] authentication mechanism [SIMPLE]: error 32 (No
>> such object) errno 0 (Success)
>> [31/Aug/2016:13:38:01 +0000] NSMMReplicationPlugin -
>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>> failed: LDAP error 32 (No such object) ()
>> ^C
>> [root at ldap1 ~]# ldapmodify -v -h ldap1.example.com -p 389 -D
>> "cn=directory manager" -w ...
>> ldap_initialize( ldap://ldap1.example.com:389 )
>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>> tree,cn=config
>> changetype: modify
>> replace: nsds5beginreplicarefresh
>> nsds5beginreplicarefresh: start
>> replace nsds5beginreplicarefresh:
>> start
>> modifying entry "cn=ExampleAgreement,cn=replic
>> a,cn="dc=example,dc=com",cn=mapping tree,cn=config"
>> modify complete
>>
>> [root at ldap1 ~]# tail -f /var/log/dirsrv/slapd-EXAMPLE-COM/errors
>> [31/Aug/2016:11:11:09 +0000] - slapd started. Listening on All
>> Interfaces port 389 for LDAP requests
>> [31/Aug/2016:11:11:09 +0000] - Listening on All Interfaces port 636 for
>> LDAPS requests
>> [31/Aug/2016:11:11:09 +0000] - Listening on /var/run/slapd-EXAMPLE-COM.socket
>> for LDAPI requests
>> [31/Aug/2016:11:11:13 +0000] schema-compat-plugin - warning: no entries
>> set up under ou=sudoers,dc=example,dc=com
>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>> set up under cn=ng, cn=compat,dc=example,dc=com
>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>> set up under cn=computers, cn=compat,dc=example,dc=com
>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - Finished plugin
>> initialization.
>> [31/Aug/2016:13:38:01 +0000] slapi_ldap_bind - Error: could not bind id
>> [cn=replication manager] authentication mechanism [SIMPLE]: error 32 (No
>> such object) errno 0 (Success)
>> [31/Aug/2016:13:38:01 +0000] NSMMReplicationPlugin -
>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>> failed: LDAP error 32 (No such object) ()
>> [31/Aug/2016:15:48:36 +0000] slapi_ldap_bind - Error: could not bind id
>> [cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error
>> 32 (No such object) errno 0 (Success)
>> ^C
>> [root at ldap1 ~]#
>>
>>
>> 2016-08-31 18:15 GMT+03:00 Mark Reynolds :
>>
>>>
>>>
>>> On 08/31/2016 09:50 AM, Andrey Rogovsky wrote:
>>>
>>> Hi!
>>>
>>> I try configure manual replica from FreeIPA DS to 389 DS.
>>> I have two VM: ldap1.example.com and ldap2.example.com
>>> I was used this manual https://www.centos.org/
>>> docs/5/html/CDS/ag/8.0/Managing_Replication-Configuring-Repl
>>> ication-cmd.html for configure relica
>>>
>>> There was replica agreement before starting:
>>>
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base with scope subtree
>>> # filter: (objectclass=nsds5ReplicationAgreement)
>>> # requesting: ALL
>>> #
>>>
>>> # ExampleAgreement, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree,
>>> config
>>> dn: cn=ExampleAgreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
>>> tree,
>>> cn=config
>>> objectClass: top
>>> objectClass: nsds5replicationagreement
>>> cn: ExampleAgreement
>>> nsDS5ReplicaHost: ldap2
>>> nsDS5ReplicaPort: 389
>>> nsDS5ReplicaBindDN: cn=replication manager
>>> nsDS5ReplicaBindMethod: SIMPLE
>>> nsDS5ReplicaRoot: dc=example,dc=com
>>> description: agreement between supplier1 and consumer1
>>> nsDS5ReplicaUpdateSchedule: 0000-0500 1
>>> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE
>>> authorityRevocationLis
>>> t
>>> nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQ
>>> m1NRVVHQ1NxR1NJYjNEUUVG
>>> RERBNEJDUmxPVFl4TlRsbU5DMWtaV0UyTXpZeA0KTVMxaU1UYzFaREF3Wmk
>>> wek5qRmxNalkxWkFBQ
>>> 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJC
>>> QUVJckpINmE0S3RFYl
>>> NhLzkxL01qZg==}Wo+c0XfBnaDhg/a36yguXg==
>>> nsds5replicareapactive: 0
>>> nsds5replicaLastUpdateStart: 19700101000000Z
>>> nsds5replicaLastUpdateEnd: 19700101000000Z
>>> nsds5replicaChangesSentSinceStartup:
>>> nsds5replicaLastUpdateStatus: 0 No replication sessions started since
>>> server s
>>> tartup
>>> nsds5replicaUpdateInProgress: FALSE
>>> nsds5replicaLastInitStart: 19700101000000Z
>>> nsds5replicaLastInitEnd: 19700101000000Z
>>>
>>> # search result
>>> search: 2
>>> result: 0 Success
>>>
>>> # numResponses: 2
>>> # numEntries:
>>>
>>>
>>> There is errors which I get when start replica:
>>>
>>>
>>> [root at ldap1 ~]# ldapmodify -v -h ldap1.example.com -p 389 -D
>>> "cn=directory manager" -w ...
>>> ldap_initialize( ldap://ldap1.example.com:389 )
>>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>>> tree,cn=config
>>> changetype: modify
>>> replace: nsds5beginreplicarefresh
>>> nsds5beginreplicarefresh: start
>>> replace nsds5beginreplicarefresh:
>>> start
>>> modifying entry "cn=ExampleAgreement,cn=replic
>>> a,cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>> modify complete
>>>
>>> [root at ldap1 ~]# tail -f /var/log/dirsrv/slapd-EXAMPLE-COM/errors
>>> [31/Aug/2016:11:11:09 +0000] schema-compat-plugin - schema-compat-plugin
>>> tree scan will start in about 5 seconds!
>>> [31/Aug/2016:11:11:09 +0000] - slapd started. Listening on All
>>> Interfaces port 389 for LDAP requests
>>> [31/Aug/2016:11:11:09 +0000] - Listening on All Interfaces port 636 for
>>> LDAPS requests
>>> [31/Aug/2016:11:11:09 +0000] - Listening on
>>> /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests
>>> [31/Aug/2016:11:11:13 +0000] schema-compat-plugin - warning: no entries
>>> set up under ou=sudoers,dc=example,dc=com
>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>> set up under cn=ng, cn=compat,dc=example,dc=com
>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>> set up under cn=computers, cn=compat,dc=example,dc=com
>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - Finished plugin
>>> initialization.
>>> [31/Aug/2016:13:38:01 +0000] slapi_ldap_bind - Error: could not bind id
>>> [cn=replication manager] authentication mechanism [SIMPLE]: error 32 (No
>>> such object) errno 0 (Success)
>>> [31/Aug/2016:13:38:01 +0000] NSMMReplicationPlugin -
>>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>>> failed: LDAP error 32 (No such object) ()
>>> ^C
>>>
>>> I'm assuming this is just a standalone 389 Directory Server you are
>>> trying to replicate to(not a freeIPA installation). If it is a freeipa
>>> installation, then you should use the freeipa CLI for setting up
>>> replication.
>>>
>>> The error 32 (no such object) you are getting is because the replica
>>> does not have an entry "cn=replication manager". Looking at the
>>> replication agreement:
>>>
>>> nsDS5ReplicaBindDN: cn=replication manager
>>>
>>> This is not a valid DN as there is no base suffix: For example, I would
>>> expect to see something like "cn=replication manager,cn=config"
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Direct
>>> ory_Server/10/html/Administration_Guide/Creating_the_Supplie
>>> r_Bind_DN_Entry.html
>>>
>>> Regards,
>>> Mark
>>>
>>>
>>> Please help me fix this
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From abokovoy at redhat.com Thu Sep 1 04:14:56 2016
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 1 Sep 2016 07:14:56 +0300
Subject: [Freeipa-users] Command-line replication is not works in
FreeIPA-Master
In-Reply-To:
References:
<4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
Message-ID: <20160901041455.4xsgwvv5duxloi6g@redhat.com>
On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>Hi!
>Thanks for your advices!
>I'm try start replica and get this errors in log:
>[01/Sep/2016:03:24:23 +0000] slapi_ldap_bind - Error: could not bind id
>[cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error
>32 (No such object) errno 0 (Success)
>[01/Sep/2016:03:24:23 +0000] NSMMReplicationPlugin -
>agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>failed: LDAP error 32 (No such object) ()
You've been told already that you should have replication manager object
created at both sides. Your 'cn=replicaton manager,cn=config' does not
exist at the replica.
You should read RHDS Administration Guide, at least the part about
supplier bind DN entry, but preferrably the whole chapter it is part of:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Creating_the_Supplier_Bind_DN_Entry.html
>
>This is my current replica:
>filter: (objectclass=nsds5replica)
>requesting: All userApplication attributes
># extended LDIF
>#
># LDAPv3
># base with scope subtree
># filter: (objectclass=nsds5replica)
># requesting: ALL
>#
>
># replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
>dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
>objectClass: top
>objectClass: nsds5replica
>objectClass: extensibleObject
>cn: replica
>nsDS5ReplicaRoot: dc=example,dc=com
>nsDS5ReplicaId: 7
>nsDS5ReplicaType: 3
>nsDS5Flags: 1
>nsds5ReplicaPurgeDelay: 604800
>nsDS5ReplicaBindDN: cn=replication manager,cn=config
>nsState:: BwAAAAAAAADqnMdXAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
>nsDS5ReplicaName: 496dba82-6f7a11e6-9d5ba359-5196ffe4
>nsds5ReplicaChangeCount: 118
>nsds5replicareapactive: 0
>
># search result
>search: 2
>result: 0 Success
>
># numResponses: 2
># numEntries: 1
>
>This is my current agreement:
>
># extended LDIF
>#
># LDAPv3
># base with scope subtree
># filter: (objectclass=nsds5ReplicationAgreement)
># requesting: ALL
>#
>
># ExampleAgreement, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
>dn: cn=ExampleAgreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
>tree,
> cn=config
>objectClass: top
>objectClass: nsds5replicationagreement
>cn: ExampleAgreement
>nsDS5ReplicaHost: ldap2
>nsDS5ReplicaPort: 389
>nsDS5ReplicaBindDN: cn=replication manager,cn=config
>nsDS5ReplicaBindMethod: SIMPLE
>nsDS5ReplicaRoot: dc=example,dc=com
>description: agreement between supplier1 and consumer1
>nsDS5ReplicaUpdateSchedule: 0000-0500 1
>nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE
>authorityRevocationLis
> t
>nsDS5ReplicaCredentials:
>{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
> RERBNEJDUmxPVFl4TlRsbU5DMWtaV0UyTXpZeA0KTVMxaU1UYzFaREF3Wmkwek5qRmxNalkxWkFBQ
> 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQU1Dc25vTkVzZVJ4b3
> N2WVlEMXRpbQ==}a21h3uqnbcAZ1cX+NheCeg==
>nsds5replicareapactive: 0
>nsds5replicaLastUpdateStart: 19700101000000Z
>nsds5replicaLastUpdateEnd: 19700101000000Z
>nsds5replicaChangesSentSinceStartup:
>nsds5replicaLastUpdateStatus: 0 No replication sessions started since
>server s
> tartup
>nsds5replicaUpdateInProgress: FALSE
>nsds5replicaLastInitStart: 20160901032423Z
>nsds5replicaLastInitEnd: 19700101000000Z
>nsds5replicaLastInitStatus: 32 - LDAP error: No such object
>
># search result
>search: 2
>result: 0 Success
>
># numResponses: 2
># numEntries: 1
>
>I'm try delete agreement, replica, user, changelog and create again. This
>not help, same error:
>
>[01/Sep/2016:03:42:37 +0000] NSMMReplicationPlugin - agmt_delete: begin
>[01/Sep/2016:03:45:35 +0000] NSMMReplicationPlugin - replica_config_delete:
>Warning: The changelog for replica dc=example,dc=com is no longer valid
>since the replica config is being deleted. Removing the changelog.
>[01/Sep/2016:03:53:18 +0000] slapi_ldap_bind - Error: could not bind id
>[cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error
>32 (No such object) errno 0 (Success)
>[01/Sep/2016:03:53:18 +0000] NSMMReplicationPlugin -
>agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>failed: LDAP error 32 (No such object) ()
>
>
>
>2016-08-31 20:09 GMT+03:00 Mark Reynolds :
>
>>
>>
>> On 08/31/2016 12:39 PM, Andrey Rogovsky wrote:
>>
>> Hi, Mark!
>>
>> Thanks for explain. Now I create replication manager: (I hope)
>> [root at ldap1 ~]# ldapsearch -h ldap1.example.com -p 389 -xLLL -D
>> "cn=directory manager" -W -b cn=config "cn=replication manager"
>> Enter LDAP Password:
>> dn: cn=replication manager,cn=config
>> objectClass: inetorgperson
>> objectClass: person
>> objectClass: top
>> objectClass: organizationalPerson
>> cn: replication manager
>> sn: RM
>> userPassword:: e1NTSEF9N1JiRmNXWTFXNDA1cmdYSU
>> dCNWJtV3RzOElNQXBhakhXam94WlE9PQ=
>> =
>>
>> What is next? I use manual from 8 version and this a bit obsoleted.
>>
>> Now you should be able to initialize your standalone server by updating
>> the agreement on the ipa DS:
>>
>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>> tree,cn=config
>> changetype: modify
>> replace: nsds5beginreplicarefresh
>> nsds5beginreplicarefresh: start
>>
>> If something goes wrong let us know what's in the errors log again.
>>
>> Mark
>>
>>
>>
>> 2016-08-31 19:30 GMT+03:00 Mark Reynolds :
>>
>>> Hi Andrey,
>>>
>>> It looks like you still did not create the replication manager entry.
>>> You must create that manager entry on the standalone server. Please read
>>> the link I sent you:
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Direct
>>> ory_Server/10/html/Administration_Guide/Creating_the_Supplie
>>> r_Bind_DN_Entry.html
>>>
>>> You can verify its existence by doing this search against the standalone
>>> server:
>>>
>>> ldapsearch -h ldap1.example.com -p 389 -xLLL -D "cn=directory manager"
>>> -W -b cn=config "cn=replication manager"
>>>
>>> Mark
>>>
>>>
>>> On 08/31/2016 11:50 AM, Andrey Rogovsky wrote:
>>>
>>> Hi!
>>> Thank you for fast reply.
>>> Yes, I want use standalone 389DS to replica from FreeIPA.
>>> There is my replica:
>>> filter: (objectclass=nsds5replica)
>>> requesting: All userApplication attributes
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base with scope subtree
>>> # filter: (objectclass=nsds5replica)
>>> # requesting: ALL
>>> #
>>>
>>> # replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
>>> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
>>> objectClass: top
>>> objectClass: nsds5replica
>>> objectClass: extensibleObject
>>> cn: replica
>>> nsDS5ReplicaRoot: dc=example,dc=com
>>> nsDS5ReplicaId: 7
>>> nsDS5ReplicaType: 3
>>> nsDS5Flags: 1
>>> nsds5ReplicaPurgeDelay: 604800
>>> nsDS5ReplicaBindDN: cn=replication manager,cn=config
>>> nsState:: BwAAAAAAAABZ98ZXAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
>>> nsDS5ReplicaName: 496dba82-6f7a11e6-9d5ba359-5196ffe4
>>> nsds5ReplicaChangeCount: 22
>>> nsds5replicareapactive: 0
>>>
>>> # search result
>>> search: 2
>>> result: 0 Success
>>>
>>> # numResponses: 2
>>> # numEntries: 1
>>>
>>> So, my replica have entry "cn=replication manager"
>>>
>>> But I try add entry in agreement. Unforthunalty this is not help, error
>>> is present:
>>> [root at ldap1 ~]# ldapmodify -v -h ldap1.example.com -p 389 -D
>>> "cn=directory manager" -w ...
>>> ldap_initialize( ldap://ldap1.example.com:389 )
>>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>>> tree,cn=config
>>> changetype: modify
>>> replace: nsds5ReplicaBindDN
>>> nsds5ReplicaBindDN: cn=replication manager,cn=config
>>> replace nsds5ReplicaBindDN:
>>> cn=replication manager,cn=config
>>> modifying entry "cn=ExampleAgreement,cn=replic
>>> a,cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>> modify complete
>>>
>>> [root at ldap1 ~]# tail -f /var/log/dirsrv/slapd-EXAMPLE-COM/errors
>>> [31/Aug/2016:11:11:09 +0000] schema-compat-plugin - schema-compat-plugin
>>> tree scan will start in about 5 seconds!
>>> [31/Aug/2016:11:11:09 +0000] - slapd started. Listening on All
>>> Interfaces port 389 for LDAP requests
>>> [31/Aug/2016:11:11:09 +0000] - Listening on All Interfaces port 636 for
>>> LDAPS requests
>>> [31/Aug/2016:11:11:09 +0000] - Listening on /var/run/slapd-EXAMPLE-COM.socket
>>> for LDAPI requests
>>> [31/Aug/2016:11:11:13 +0000] schema-compat-plugin - warning: no entries
>>> set up under ou=sudoers,dc=example,dc=com
>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>> set up under cn=ng, cn=compat,dc=example,dc=com
>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>> set up under cn=computers, cn=compat,dc=example,dc=com
>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - Finished plugin
>>> initialization.
>>> [31/Aug/2016:13:38:01 +0000] slapi_ldap_bind - Error: could not bind id
>>> [cn=replication manager] authentication mechanism [SIMPLE]: error 32 (No
>>> such object) errno 0 (Success)
>>> [31/Aug/2016:13:38:01 +0000] NSMMReplicationPlugin -
>>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>>> failed: LDAP error 32 (No such object) ()
>>> ^C
>>> [root at ldap1 ~]# ldapmodify -v -h ldap1.example.com -p 389 -D
>>> "cn=directory manager" -w ...
>>> ldap_initialize( ldap://ldap1.example.com:389 )
>>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>>> tree,cn=config
>>> changetype: modify
>>> replace: nsds5beginreplicarefresh
>>> nsds5beginreplicarefresh: start
>>> replace nsds5beginreplicarefresh:
>>> start
>>> modifying entry "cn=ExampleAgreement,cn=replic
>>> a,cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>> modify complete
>>>
>>> [root at ldap1 ~]# tail -f /var/log/dirsrv/slapd-EXAMPLE-COM/errors
>>> [31/Aug/2016:11:11:09 +0000] - slapd started. Listening on All
>>> Interfaces port 389 for LDAP requests
>>> [31/Aug/2016:11:11:09 +0000] - Listening on All Interfaces port 636 for
>>> LDAPS requests
>>> [31/Aug/2016:11:11:09 +0000] - Listening on /var/run/slapd-EXAMPLE-COM.socket
>>> for LDAPI requests
>>> [31/Aug/2016:11:11:13 +0000] schema-compat-plugin - warning: no entries
>>> set up under ou=sudoers,dc=example,dc=com
>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>> set up under cn=ng, cn=compat,dc=example,dc=com
>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>> set up under cn=computers, cn=compat,dc=example,dc=com
>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - Finished plugin
>>> initialization.
>>> [31/Aug/2016:13:38:01 +0000] slapi_ldap_bind - Error: could not bind id
>>> [cn=replication manager] authentication mechanism [SIMPLE]: error 32 (No
>>> such object) errno 0 (Success)
>>> [31/Aug/2016:13:38:01 +0000] NSMMReplicationPlugin -
>>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>>> failed: LDAP error 32 (No such object) ()
>>> [31/Aug/2016:15:48:36 +0000] slapi_ldap_bind - Error: could not bind id
>>> [cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error
>>> 32 (No such object) errno 0 (Success)
>>> ^C
>>> [root at ldap1 ~]#
>>>
>>>
>>> 2016-08-31 18:15 GMT+03:00 Mark Reynolds :
>>>
>>>>
>>>>
>>>> On 08/31/2016 09:50 AM, Andrey Rogovsky wrote:
>>>>
>>>> Hi!
>>>>
>>>> I try configure manual replica from FreeIPA DS to 389 DS.
>>>> I have two VM: ldap1.example.com and ldap2.example.com
>>>> I was used this manual https://www.centos.org/
>>>> docs/5/html/CDS/ag/8.0/Managing_Replication-Configuring-Repl
>>>> ication-cmd.html for configure relica
>>>>
>>>> There was replica agreement before starting:
>>>>
>>>> # extended LDIF
>>>> #
>>>> # LDAPv3
>>>> # base with scope subtree
>>>> # filter: (objectclass=nsds5ReplicationAgreement)
>>>> # requesting: ALL
>>>> #
>>>>
>>>> # ExampleAgreement, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree,
>>>> config
>>>> dn: cn=ExampleAgreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
>>>> tree,
>>>> cn=config
>>>> objectClass: top
>>>> objectClass: nsds5replicationagreement
>>>> cn: ExampleAgreement
>>>> nsDS5ReplicaHost: ldap2
>>>> nsDS5ReplicaPort: 389
>>>> nsDS5ReplicaBindDN: cn=replication manager
>>>> nsDS5ReplicaBindMethod: SIMPLE
>>>> nsDS5ReplicaRoot: dc=example,dc=com
>>>> description: agreement between supplier1 and consumer1
>>>> nsDS5ReplicaUpdateSchedule: 0000-0500 1
>>>> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE
>>>> authorityRevocationLis
>>>> t
>>>> nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQ
>>>> m1NRVVHQ1NxR1NJYjNEUUVG
>>>> RERBNEJDUmxPVFl4TlRsbU5DMWtaV0UyTXpZeA0KTVMxaU1UYzFaREF3Wmk
>>>> wek5qRmxNalkxWkFBQ
>>>> 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJC
>>>> QUVJckpINmE0S3RFYl
>>>> NhLzkxL01qZg==}Wo+c0XfBnaDhg/a36yguXg==
>>>> nsds5replicareapactive: 0
>>>> nsds5replicaLastUpdateStart: 19700101000000Z
>>>> nsds5replicaLastUpdateEnd: 19700101000000Z
>>>> nsds5replicaChangesSentSinceStartup:
>>>> nsds5replicaLastUpdateStatus: 0 No replication sessions started since
>>>> server s
>>>> tartup
>>>> nsds5replicaUpdateInProgress: FALSE
>>>> nsds5replicaLastInitStart: 19700101000000Z
>>>> nsds5replicaLastInitEnd: 19700101000000Z
>>>>
>>>> # search result
>>>> search: 2
>>>> result: 0 Success
>>>>
>>>> # numResponses: 2
>>>> # numEntries:
>>>>
>>>>
>>>> There is errors which I get when start replica:
>>>>
>>>>
>>>> [root at ldap1 ~]# ldapmodify -v -h ldap1.example.com -p 389 -D
>>>> "cn=directory manager" -w ...
>>>> ldap_initialize( ldap://ldap1.example.com:389 )
>>>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>>>> tree,cn=config
>>>> changetype: modify
>>>> replace: nsds5beginreplicarefresh
>>>> nsds5beginreplicarefresh: start
>>>> replace nsds5beginreplicarefresh:
>>>> start
>>>> modifying entry "cn=ExampleAgreement,cn=replic
>>>> a,cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>>> modify complete
>>>>
>>>> [root at ldap1 ~]# tail -f /var/log/dirsrv/slapd-EXAMPLE-COM/errors
>>>> [31/Aug/2016:11:11:09 +0000] schema-compat-plugin - schema-compat-plugin
>>>> tree scan will start in about 5 seconds!
>>>> [31/Aug/2016:11:11:09 +0000] - slapd started. Listening on All
>>>> Interfaces port 389 for LDAP requests
>>>> [31/Aug/2016:11:11:09 +0000] - Listening on All Interfaces port 636 for
>>>> LDAPS requests
>>>> [31/Aug/2016:11:11:09 +0000] - Listening on
>>>> /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests
>>>> [31/Aug/2016:11:11:13 +0000] schema-compat-plugin - warning: no entries
>>>> set up under ou=sudoers,dc=example,dc=com
>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>>> set up under cn=ng, cn=compat,dc=example,dc=com
>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>>> set up under cn=computers, cn=compat,dc=example,dc=com
>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - Finished plugin
>>>> initialization.
>>>> [31/Aug/2016:13:38:01 +0000] slapi_ldap_bind - Error: could not bind id
>>>> [cn=replication manager] authentication mechanism [SIMPLE]: error 32 (No
>>>> such object) errno 0 (Success)
>>>> [31/Aug/2016:13:38:01 +0000] NSMMReplicationPlugin -
>>>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>>>> failed: LDAP error 32 (No such object) ()
>>>> ^C
>>>>
>>>> I'm assuming this is just a standalone 389 Directory Server you are
>>>> trying to replicate to(not a freeIPA installation). If it is a freeipa
>>>> installation, then you should use the freeipa CLI for setting up
>>>> replication.
>>>>
>>>> The error 32 (no such object) you are getting is because the replica
>>>> does not have an entry "cn=replication manager". Looking at the
>>>> replication agreement:
>>>>
>>>> nsDS5ReplicaBindDN: cn=replication manager
>>>>
>>>> This is not a valid DN as there is no base suffix: For example, I would
>>>> expect to see something like "cn=replication manager,cn=config"
>>>>
>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Direct
>>>> ory_Server/10/html/Administration_Guide/Creating_the_Supplie
>>>> r_Bind_DN_Entry.html
>>>>
>>>> Regards,
>>>> Mark
>>>>
>>>>
>>>> Please help me fix this
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>--
>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
--
/ Alexander Bokovoy
From a.rogovsky at gmail.com Thu Sep 1 04:25:44 2016
From: a.rogovsky at gmail.com (Andrey Rogovsky)
Date: Thu, 1 Sep 2016 07:25:44 +0300
Subject: [Freeipa-users] Command-line replication is not works in
FreeIPA-Master
In-Reply-To: <20160901041455.4xsgwvv5duxloi6g@redhat.com>
References:
<4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
<20160901041455.4xsgwvv5duxloi6g@redhat.com>
Message-ID:
Hi, Alexander!
Thank for fast reply.
I have replication manager object:
filter: (objectclass=organizationalPerson)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=organizationalPerson)
# requesting: ALL
#
# replication manager, config
dn: cn=replication manager,cn=config
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword::
e1NTSEF9d281RGZOTTlCSEVWTEhxY1lTcGs0WHdjRXplemU4S280S3EwWnc9PQ=
=
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
But error is present.
2016-09-01 7:14 GMT+03:00 Alexander Bokovoy :
> On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>
>> Hi!
>> Thanks for your advices!
>> I'm try start replica and get this errors in log:
>> [01/Sep/2016:03:24:23 +0000] slapi_ldap_bind - Error: could not bind id
>> [cn=replication manager,cn=config] authentication mechanism [SIMPLE]:
>> error
>> 32 (No such object) errno 0 (Success)
>> [01/Sep/2016:03:24:23 +0000] NSMMReplicationPlugin -
>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>> failed: LDAP error 32 (No such object) ()
>>
> You've been told already that you should have replication manager object
> created at both sides. Your 'cn=replicaton manager,cn=config' does not
> exist at the replica.
>
> You should read RHDS Administration Guide, at least the part about
> supplier bind DN entry, but preferrably the whole chapter it is part of:
> https://access.redhat.com/documentation/en-US/Red_Hat_Direct
> ory_Server/10/html/Administration_Guide/Creating_the_
> Supplier_Bind_DN_Entry.html
>
>
>
>
>> This is my current replica:
>> filter: (objectclass=nsds5replica)
>> requesting: All userApplication attributes
>> # extended LDIF
>> #
>> # LDAPv3
>> # base with scope subtree
>> # filter: (objectclass=nsds5replica)
>> # requesting: ALL
>> #
>>
>> # replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
>> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
>> objectClass: top
>> objectClass: nsds5replica
>> objectClass: extensibleObject
>> cn: replica
>> nsDS5ReplicaRoot: dc=example,dc=com
>> nsDS5ReplicaId: 7
>> nsDS5ReplicaType: 3
>> nsDS5Flags: 1
>> nsds5ReplicaPurgeDelay: 604800
>> nsDS5ReplicaBindDN: cn=replication manager,cn=config
>> nsState:: BwAAAAAAAADqnMdXAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
>> nsDS5ReplicaName: 496dba82-6f7a11e6-9d5ba359-5196ffe4
>> nsds5ReplicaChangeCount: 118
>> nsds5replicareapactive: 0
>>
>> # search result
>> search: 2
>> result: 0 Success
>>
>> # numResponses: 2
>> # numEntries: 1
>>
>> This is my current agreement:
>>
>> # extended LDIF
>> #
>> # LDAPv3
>> # base with scope subtree
>> # filter: (objectclass=nsds5ReplicationAgreement)
>> # requesting: ALL
>> #
>>
>> # ExampleAgreement, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
>> dn: cn=ExampleAgreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
>> tree,
>> cn=config
>> objectClass: top
>> objectClass: nsds5replicationagreement
>> cn: ExampleAgreement
>> nsDS5ReplicaHost: ldap2
>> nsDS5ReplicaPort: 389
>> nsDS5ReplicaBindDN: cn=replication manager,cn=config
>> nsDS5ReplicaBindMethod: SIMPLE
>> nsDS5ReplicaRoot: dc=example,dc=com
>> description: agreement between supplier1 and consumer1
>> nsDS5ReplicaUpdateSchedule: 0000-0500 1
>> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE
>> authorityRevocationLis
>> t
>> nsDS5ReplicaCredentials:
>> {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
>> RERBNEJDUmxPVFl4TlRsbU5DMWtaV0UyTXpZeA0KTVMxaU1UYzFaREF3Wmkw
>> ek5qRmxNalkxWkFBQ
>> 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ
>> U1Dc25vTkVzZVJ4b3
>> N2WVlEMXRpbQ==}a21h3uqnbcAZ1cX+NheCeg==
>> nsds5replicareapactive: 0
>> nsds5replicaLastUpdateStart: 19700101000000Z
>> nsds5replicaLastUpdateEnd: 19700101000000Z
>> nsds5replicaChangesSentSinceStartup:
>> nsds5replicaLastUpdateStatus: 0 No replication sessions started since
>> server s
>> tartup
>> nsds5replicaUpdateInProgress: FALSE
>> nsds5replicaLastInitStart: 20160901032423Z
>> nsds5replicaLastInitEnd: 19700101000000Z
>> nsds5replicaLastInitStatus: 32 - LDAP error: No such object
>>
>> # search result
>> search: 2
>> result: 0 Success
>>
>> # numResponses: 2
>> # numEntries: 1
>>
>> I'm try delete agreement, replica, user, changelog and create again. This
>> not help, same error:
>>
>> [01/Sep/2016:03:42:37 +0000] NSMMReplicationPlugin - agmt_delete: begin
>> [01/Sep/2016:03:45:35 +0000] NSMMReplicationPlugin -
>> replica_config_delete:
>> Warning: The changelog for replica dc=example,dc=com is no longer valid
>> since the replica config is being deleted. Removing the changelog.
>> [01/Sep/2016:03:53:18 +0000] slapi_ldap_bind - Error: could not bind id
>> [cn=replication manager,cn=config] authentication mechanism [SIMPLE]:
>> error
>> 32 (No such object) errno 0 (Success)
>> [01/Sep/2016:03:53:18 +0000] NSMMReplicationPlugin -
>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE auth
>> failed: LDAP error 32 (No such object) ()
>>
>>
>>
>> 2016-08-31 20:09 GMT+03:00 Mark Reynolds :
>>
>>
>>>
>>> On 08/31/2016 12:39 PM, Andrey Rogovsky wrote:
>>>
>>> Hi, Mark!
>>>
>>> Thanks for explain. Now I create replication manager: (I hope)
>>> [root at ldap1 ~]# ldapsearch -h ldap1.example.com -p 389 -xLLL -D
>>> "cn=directory manager" -W -b cn=config "cn=replication manager"
>>> Enter LDAP Password:
>>> dn: cn=replication manager,cn=config
>>> objectClass: inetorgperson
>>> objectClass: person
>>> objectClass: top
>>> objectClass: organizationalPerson
>>> cn: replication manager
>>> sn: RM
>>> userPassword:: e1NTSEF9N1JiRmNXWTFXNDA1cmdYSU
>>> dCNWJtV3RzOElNQXBhakhXam94WlE9PQ=
>>> =
>>>
>>> What is next? I use manual from 8 version and this a bit obsoleted.
>>>
>>> Now you should be able to initialize your standalone server by updating
>>> the agreement on the ipa DS:
>>>
>>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>>> tree,cn=config
>>> changetype: modify
>>> replace: nsds5beginreplicarefresh
>>> nsds5beginreplicarefresh: start
>>>
>>> If something goes wrong let us know what's in the errors log again.
>>>
>>> Mark
>>>
>>>
>>>
>>> 2016-08-31 19:30 GMT+03:00 Mark Reynolds :
>>>
>>> Hi Andrey,
>>>>
>>>> It looks like you still did not create the replication manager entry.
>>>> You must create that manager entry on the standalone server. Please
>>>> read
>>>> the link I sent you:
>>>>
>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Direct
>>>> ory_Server/10/html/Administration_Guide/Creating_the_Supplie
>>>> r_Bind_DN_Entry.html
>>>>
>>>> You can verify its existence by doing this search against the standalone
>>>> server:
>>>>
>>>> ldapsearch -h ldap1.example.com -p 389 -xLLL -D "cn=directory manager"
>>>> -W -b cn=config "cn=replication manager"
>>>>
>>>> Mark
>>>>
>>>>
>>>> On 08/31/2016 11:50 AM, Andrey Rogovsky wrote:
>>>>
>>>> Hi!
>>>> Thank you for fast reply.
>>>> Yes, I want use standalone 389DS to replica from FreeIPA.
>>>> There is my replica:
>>>> filter: (objectclass=nsds5replica)
>>>> requesting: All userApplication attributes
>>>> # extended LDIF
>>>> #
>>>> # LDAPv3
>>>> # base with scope subtree
>>>> # filter: (objectclass=nsds5replica)
>>>> # requesting: ALL
>>>> #
>>>>
>>>> # replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
>>>> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
>>>> objectClass: top
>>>> objectClass: nsds5replica
>>>> objectClass: extensibleObject
>>>> cn: replica
>>>> nsDS5ReplicaRoot: dc=example,dc=com
>>>> nsDS5ReplicaId: 7
>>>> nsDS5ReplicaType: 3
>>>> nsDS5Flags: 1
>>>> nsds5ReplicaPurgeDelay: 604800
>>>> nsDS5ReplicaBindDN: cn=replication manager,cn=config
>>>> nsState:: BwAAAAAAAABZ98ZXAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
>>>> nsDS5ReplicaName: 496dba82-6f7a11e6-9d5ba359-5196ffe4
>>>> nsds5ReplicaChangeCount: 22
>>>> nsds5replicareapactive: 0
>>>>
>>>> # search result
>>>> search: 2
>>>> result: 0 Success
>>>>
>>>> # numResponses: 2
>>>> # numEntries: 1
>>>>
>>>> So, my replica have entry "cn=replication manager"
>>>>
>>>> But I try add entry in agreement. Unforthunalty this is not help, error
>>>> is present:
>>>> [root at ldap1 ~]# ldapmodify -v -h ldap1.example.com -p 389 -D
>>>> "cn=directory manager" -w ...
>>>> ldap_initialize( ldap://ldap1.example.com:389 )
>>>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>>>> tree,cn=config
>>>> changetype: modify
>>>> replace: nsds5ReplicaBindDN
>>>> nsds5ReplicaBindDN: cn=replication manager,cn=config
>>>> replace nsds5ReplicaBindDN:
>>>> cn=replication manager,cn=config
>>>> modifying entry "cn=ExampleAgreement,cn=replic
>>>> a,cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>>> modify complete
>>>>
>>>> [root at ldap1 ~]# tail -f /var/log/dirsrv/slapd-EXAMPLE-COM/errors
>>>> [31/Aug/2016:11:11:09 +0000] schema-compat-plugin - schema-compat-plugin
>>>> tree scan will start in about 5 seconds!
>>>> [31/Aug/2016:11:11:09 +0000] - slapd started. Listening on All
>>>> Interfaces port 389 for LDAP requests
>>>> [31/Aug/2016:11:11:09 +0000] - Listening on All Interfaces port 636 for
>>>> LDAPS requests
>>>> [31/Aug/2016:11:11:09 +0000] - Listening on
>>>> /var/run/slapd-EXAMPLE-COM.socket
>>>> for LDAPI requests
>>>> [31/Aug/2016:11:11:13 +0000] schema-compat-plugin - warning: no entries
>>>> set up under ou=sudoers,dc=example,dc=com
>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>>> set up under cn=ng, cn=compat,dc=example,dc=com
>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>>> set up under cn=computers, cn=compat,dc=example,dc=com
>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - Finished plugin
>>>> initialization.
>>>> [31/Aug/2016:13:38:01 +0000] slapi_ldap_bind - Error: could not bind id
>>>> [cn=replication manager] authentication mechanism [SIMPLE]: error 32 (No
>>>> such object) errno 0 (Success)
>>>> [31/Aug/2016:13:38:01 +0000] NSMMReplicationPlugin -
>>>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE
>>>> auth
>>>> failed: LDAP error 32 (No such object) ()
>>>> ^C
>>>> [root at ldap1 ~]# ldapmodify -v -h ldap1.example.com -p 389 -D
>>>> "cn=directory manager" -w ...
>>>> ldap_initialize( ldap://ldap1.example.com:389 )
>>>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>>>> tree,cn=config
>>>> changetype: modify
>>>> replace: nsds5beginreplicarefresh
>>>> nsds5beginreplicarefresh: start
>>>> replace nsds5beginreplicarefresh:
>>>> start
>>>> modifying entry "cn=ExampleAgreement,cn=replic
>>>> a,cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>>> modify complete
>>>>
>>>> [root at ldap1 ~]# tail -f /var/log/dirsrv/slapd-EXAMPLE-COM/errors
>>>> [31/Aug/2016:11:11:09 +0000] - slapd started. Listening on All
>>>> Interfaces port 389 for LDAP requests
>>>> [31/Aug/2016:11:11:09 +0000] - Listening on All Interfaces port 636 for
>>>> LDAPS requests
>>>> [31/Aug/2016:11:11:09 +0000] - Listening on
>>>> /var/run/slapd-EXAMPLE-COM.socket
>>>> for LDAPI requests
>>>> [31/Aug/2016:11:11:13 +0000] schema-compat-plugin - warning: no entries
>>>> set up under ou=sudoers,dc=example,dc=com
>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>>> set up under cn=ng, cn=compat,dc=example,dc=com
>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>>> set up under cn=computers, cn=compat,dc=example,dc=com
>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - Finished plugin
>>>> initialization.
>>>> [31/Aug/2016:13:38:01 +0000] slapi_ldap_bind - Error: could not bind id
>>>> [cn=replication manager] authentication mechanism [SIMPLE]: error 32 (No
>>>> such object) errno 0 (Success)
>>>> [31/Aug/2016:13:38:01 +0000] NSMMReplicationPlugin -
>>>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE
>>>> auth
>>>> failed: LDAP error 32 (No such object) ()
>>>> [31/Aug/2016:15:48:36 +0000] slapi_ldap_bind - Error: could not bind id
>>>> [cn=replication manager,cn=config] authentication mechanism [SIMPLE]:
>>>> error
>>>> 32 (No such object) errno 0 (Success)
>>>> ^C
>>>> [root at ldap1 ~]#
>>>>
>>>>
>>>> 2016-08-31 18:15 GMT+03:00 Mark Reynolds :
>>>>
>>>>
>>>>>
>>>>> On 08/31/2016 09:50 AM, Andrey Rogovsky wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> I try configure manual replica from FreeIPA DS to 389 DS.
>>>>> I have two VM: ldap1.example.com and ldap2.example.com
>>>>> I was used this manual https://www.centos.org/
>>>>> docs/5/html/CDS/ag/8.0/Managing_Replication-Configuring-Repl
>>>>> ication-cmd.html for configure relica
>>>>>
>>>>> There was replica agreement before starting:
>>>>>
>>>>> # extended LDIF
>>>>> #
>>>>> # LDAPv3
>>>>> # base with scope subtree
>>>>> # filter: (objectclass=nsds5ReplicationAgreement)
>>>>> # requesting: ALL
>>>>> #
>>>>>
>>>>> # ExampleAgreement, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree,
>>>>> config
>>>>> dn: cn=ExampleAgreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,
>>>>> cn=mapping
>>>>> tree,
>>>>> cn=config
>>>>> objectClass: top
>>>>> objectClass: nsds5replicationagreement
>>>>> cn: ExampleAgreement
>>>>> nsDS5ReplicaHost: ldap2
>>>>> nsDS5ReplicaPort: 389
>>>>> nsDS5ReplicaBindDN: cn=replication manager
>>>>> nsDS5ReplicaBindMethod: SIMPLE
>>>>> nsDS5ReplicaRoot: dc=example,dc=com
>>>>> description: agreement between supplier1 and consumer1
>>>>> nsDS5ReplicaUpdateSchedule: 0000-0500 1
>>>>> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE
>>>>> authorityRevocationLis
>>>>> t
>>>>> nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQ
>>>>> m1NRVVHQ1NxR1NJYjNEUUVG
>>>>> RERBNEJDUmxPVFl4TlRsbU5DMWtaV0UyTXpZeA0KTVMxaU1UYzFaREF3Wmk
>>>>> wek5qRmxNalkxWkFBQ
>>>>> 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJC
>>>>> QUVJckpINmE0S3RFYl
>>>>> NhLzkxL01qZg==}Wo+c0XfBnaDhg/a36yguXg==
>>>>> nsds5replicareapactive: 0
>>>>> nsds5replicaLastUpdateStart: 19700101000000Z
>>>>> nsds5replicaLastUpdateEnd: 19700101000000Z
>>>>> nsds5replicaChangesSentSinceStartup:
>>>>> nsds5replicaLastUpdateStatus: 0 No replication sessions started since
>>>>> server s
>>>>> tartup
>>>>> nsds5replicaUpdateInProgress: FALSE
>>>>> nsds5replicaLastInitStart: 19700101000000Z
>>>>> nsds5replicaLastInitEnd: 19700101000000Z
>>>>>
>>>>> # search result
>>>>> search: 2
>>>>> result: 0 Success
>>>>>
>>>>> # numResponses: 2
>>>>> # numEntries:
>>>>>
>>>>>
>>>>> There is errors which I get when start replica:
>>>>>
>>>>>
>>>>> [root at ldap1 ~]# ldapmodify -v -h ldap1.example.com -p 389 -D
>>>>> "cn=directory manager" -w ...
>>>>> ldap_initialize( ldap://ldap1.example.com:389 )
>>>>> dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping
>>>>> tree,cn=config
>>>>> changetype: modify
>>>>> replace: nsds5beginreplicarefresh
>>>>> nsds5beginreplicarefresh: start
>>>>> replace nsds5beginreplicarefresh:
>>>>> start
>>>>> modifying entry "cn=ExampleAgreement,cn=replic
>>>>> a,cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>>>> modify complete
>>>>>
>>>>> [root at ldap1 ~]# tail -f /var/log/dirsrv/slapd-EXAMPLE-COM/errors
>>>>> [31/Aug/2016:11:11:09 +0000] schema-compat-plugin -
>>>>> schema-compat-plugin
>>>>> tree scan will start in about 5 seconds!
>>>>> [31/Aug/2016:11:11:09 +0000] - slapd started. Listening on All
>>>>> Interfaces port 389 for LDAP requests
>>>>> [31/Aug/2016:11:11:09 +0000] - Listening on All Interfaces port 636 for
>>>>> LDAPS requests
>>>>> [31/Aug/2016:11:11:09 +0000] - Listening on
>>>>> /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests
>>>>> [31/Aug/2016:11:11:13 +0000] schema-compat-plugin - warning: no entries
>>>>> set up under ou=sudoers,dc=example,dc=com
>>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>>>> set up under cn=ng, cn=compat,dc=example,dc=com
>>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - warning: no entries
>>>>> set up under cn=computers, cn=compat,dc=example,dc=com
>>>>> [31/Aug/2016:11:11:14 +0000] schema-compat-plugin - Finished plugin
>>>>> initialization.
>>>>> [31/Aug/2016:13:38:01 +0000] slapi_ldap_bind - Error: could not bind id
>>>>> [cn=replication manager] authentication mechanism [SIMPLE]: error 32
>>>>> (No
>>>>> such object) errno 0 (Success)
>>>>> [31/Aug/2016:13:38:01 +0000] NSMMReplicationPlugin -
>>>>> agmt="cn=ExampleAgreement" (ldap2:389): Replication bind with SIMPLE
>>>>> auth
>>>>> failed: LDAP error 32 (No such object) ()
>>>>> ^C
>>>>>
>>>>> I'm assuming this is just a standalone 389 Directory Server you are
>>>>> trying to replicate to(not a freeIPA installation). If it is a freeipa
>>>>> installation, then you should use the freeipa CLI for setting up
>>>>> replication.
>>>>>
>>>>> The error 32 (no such object) you are getting is because the replica
>>>>> does not have an entry "cn=replication manager". Looking at the
>>>>> replication agreement:
>>>>>
>>>>> nsDS5ReplicaBindDN: cn=replication manager
>>>>>
>>>>> This is not a valid DN as there is no base suffix: For example, I
>>>>> would
>>>>> expect to see something like "cn=replication manager,cn=config"
>>>>>
>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Direct
>>>>> ory_Server/10/html/Administration_Guide/Creating_the_Supplie
>>>>> r_Bind_DN_Entry.html
>>>>>
>>>>> Regards,
>>>>> Mark
>>>>>
>>>>>
>>>>> Please help me fix this
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
> --
>> 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
>>
>
>
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From abokovoy at redhat.com Thu Sep 1 05:57:24 2016
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 1 Sep 2016 08:57:24 +0300
Subject: [Freeipa-users] Command-line replication is not works in
FreeIPA-Master
In-Reply-To:
References:
<4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
<20160901041455.4xsgwvv5duxloi6g@redhat.com>
Message-ID: <20160901055724.lph3h65eequi4x44@redhat.com>
On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>Hi, Alexander!
>
>Thank for fast reply.
>I have replication manager object:
>filter: (objectclass=organizationalPerson)
>requesting: All userApplication attributes
># extended LDIF
>#
># LDAPv3
># base with scope subtree
># filter: (objectclass=organizationalPerson)
># requesting: ALL
>#
>
># replication manager, config
>dn: cn=replication manager,cn=config
>objectClass: inetorgperson
>objectClass: person
>objectClass: top
>objectClass: organizationalPerson
>cn: replication manager
>sn: RM
>userPassword::
>e1NTSEF9d281RGZOTTlCSEVWTEhxY1lTcGs0WHdjRXplemU4S280S3EwWnc9PQ=
> =
>
># search result
>search: 2
>result: 0 Success
>
># numResponses: 2
># numEntries: 1
>
>But error is present.
You have two LDAP servers. If you have replication going in both
directions, you need to have the replication bind entry defined on both
servers.
If you have replication going in one direction, then the target server
should have this replication bind entry defined.
Where do you have this entry?
--
/ Alexander Bokovoy
From a.rogovsky at gmail.com Thu Sep 1 06:50:59 2016
From: a.rogovsky at gmail.com (Andrey Rogovsky)
Date: Thu, 1 Sep 2016 09:50:59 +0300
Subject: [Freeipa-users] Command-line replication is not works in
FreeIPA-Master
In-Reply-To: <20160901055724.lph3h65eequi4x44@redhat.com>
References:
<4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
<20160901041455.4xsgwvv5duxloi6g@redhat.com>
<20160901055724.lph3h65eequi4x44@redhat.com>
Message-ID:
Hi, Alexander!
I have ldap1 - FreeIPA (master) and ldap2 - 389DS (slave)
I want one-way replica from ldap1 to ldap2
On ldap1 I was define dn replication user, replica and agreement
On ldap2 I was define replica only:
filter: (objectclass=nsds5replica)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=nsds5replica)
# requesting: ALL
#
# replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replica
objectClass: extensibleObject
cn: replica
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaType: 2
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5Flags: 0
nsDS5ReplicaId: 65535
nsState:: //8AAAAAAABY2sZXAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
nsDS5ReplicaName: 06154b02-6f7e11e6-b236be05-3db8a3e8
nsds5ReplicaChangeCount: 0
nsds5replicareapactive: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Does I need define DN replication user on ldap2?
2016-09-01 8:57 GMT+03:00 Alexander Bokovoy :
> On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>
>> Hi, Alexander!
>>
>> Thank for fast reply.
>> I have replication manager object:
>> filter: (objectclass=organizationalPerson)
>> requesting: All userApplication attributes
>> # extended LDIF
>> #
>> # LDAPv3
>> # base with scope subtree
>> # filter: (objectclass=organizationalPerson)
>> # requesting: ALL
>> #
>>
>> # replication manager, config
>> dn: cn=replication manager,cn=config
>> objectClass: inetorgperson
>> objectClass: person
>> objectClass: top
>> objectClass: organizationalPerson
>> cn: replication manager
>> sn: RM
>> userPassword::
>> e1NTSEF9d281RGZOTTlCSEVWTEhxY1lTcGs0WHdjRXplemU4S280S3EwWnc9PQ=
>> =
>>
>> # search result
>> search: 2
>> result: 0 Success
>>
>> # numResponses: 2
>> # numEntries: 1
>>
>> But error is present.
>>
> You have two LDAP servers. If you have replication going in both
> directions, you need to have the replication bind entry defined on both
> servers.
>
> If you have replication going in one direction, then the target server
> should have this replication bind entry defined.
>
> Where do you have this entry?
>
>
>
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From abokovoy at redhat.com Thu Sep 1 07:01:26 2016
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 1 Sep 2016 10:01:26 +0300
Subject: [Freeipa-users] Command-line replication is not works in
FreeIPA-Master
In-Reply-To:
References:
<4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
<20160901041455.4xsgwvv5duxloi6g@redhat.com>
<20160901055724.lph3h65eequi4x44@redhat.com>
Message-ID: <20160901070126.xxb4u3iyqllll2oy@redhat.com>
On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>Hi, Alexander!
>
>I have ldap1 - FreeIPA (master) and ldap2 - 389DS (slave)
>I want one-way replica from ldap1 to ldap2
>On ldap1 I was define dn replication user, replica and agreement
>On ldap2 I was define replica only:
This is what you are doing wrong. Your ldap1 server will attempt to
connect to ldap2 server using the replication user credentials. It is
ldap2 which will be authenticating this request. Where would it take
information about the replication user?
>filter: (objectclass=nsds5replica)
>requesting: All userApplication attributes
># extended LDIF
>#
># LDAPv3
># base with scope subtree
># filter: (objectclass=nsds5replica)
># requesting: ALL
>#
>
># replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
>dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
>objectClass: top
>objectClass: nsds5replica
>objectClass: extensibleObject
>cn: replica
>nsDS5ReplicaRoot: dc=example,dc=com
>nsDS5ReplicaType: 2
>nsDS5ReplicaBindDN: cn=replication manager,cn=config
>nsDS5Flags: 0
>nsDS5ReplicaId: 65535
>nsState:: //8AAAAAAABY2sZXAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
>nsDS5ReplicaName: 06154b02-6f7e11e6-b236be05-3db8a3e8
>nsds5ReplicaChangeCount: 0
>nsds5replicareapactive: 0
>
># search result
>search: 2
>result: 0 Success
>
># numResponses: 2
># numEntries: 1
>
>Does I need define DN replication user on ldap2?
>
>
>2016-09-01 8:57 GMT+03:00 Alexander Bokovoy :
>
>> On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>>
>>> Hi, Alexander!
>>>
>>> Thank for fast reply.
>>> I have replication manager object:
>>> filter: (objectclass=organizationalPerson)
>>> requesting: All userApplication attributes
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base with scope subtree
>>> # filter: (objectclass=organizationalPerson)
>>> # requesting: ALL
>>> #
>>>
>>> # replication manager, config
>>> dn: cn=replication manager,cn=config
>>> objectClass: inetorgperson
>>> objectClass: person
>>> objectClass: top
>>> objectClass: organizationalPerson
>>> cn: replication manager
>>> sn: RM
>>> userPassword::
>>> e1NTSEF9d281RGZOTTlCSEVWTEhxY1lTcGs0WHdjRXplemU4S280S3EwWnc9PQ=
>>> =
>>>
>>> # search result
>>> search: 2
>>> result: 0 Success
>>>
>>> # numResponses: 2
>>> # numEntries: 1
>>>
>>> But error is present.
>>>
>> You have two LDAP servers. If you have replication going in both
>> directions, you need to have the replication bind entry defined on both
>> servers.
>>
>> If you have replication going in one direction, then the target server
>> should have this replication bind entry defined.
>>
>> Where do you have this entry?
>>
>>
>>
>> --
>> / Alexander Bokovoy
>>
>--
>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
--
/ Alexander Bokovoy
From a.rogovsky at gmail.com Thu Sep 1 07:13:49 2016
From: a.rogovsky at gmail.com (Andrey Rogovsky)
Date: Thu, 1 Sep 2016 10:13:49 +0300
Subject: [Freeipa-users] Command-line replication is not works in
FreeIPA-Master
In-Reply-To: <20160901070126.xxb4u3iyqllll2oy@redhat.com>
References:
<4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
<20160901041455.4xsgwvv5duxloi6g@redhat.com>
<20160901055724.lph3h65eequi4x44@redhat.com>
<20160901070126.xxb4u3iyqllll2oy@redhat.com>
Message-ID:
Hi, Alexander!
Than you very much for help. Now I able to start replica, but have one
issue - schemes is not replicated:
[01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Warning: unable to
replicate schema to host ldap2, port 389. Continuing with total update
session.
[01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Beginning total update
of replica "agmt="cn=ExampleAgreement" (ldap2:389)".
[01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Need to create
replication keep alive entry
[01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - add dn: cn=repl keep
alive 7,dc=example,dc=com
objectclass: top
objectclass: ldapsubentry
objectclass: extensibleObject
cn: repl keep alive 7
[01/Sep/2016:07:04:58 +0000] NSMMReplicationPlugin - Finished total update
of replica "agmt="cn=ExampleAgreement" (ldap2:389)". Sent 415 entries.
Can you help me with schemes?
2016-09-01 10:01 GMT+03:00 Alexander Bokovoy :
> On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>
>> Hi, Alexander!
>>
>> I have ldap1 - FreeIPA (master) and ldap2 - 389DS (slave)
>> I want one-way replica from ldap1 to ldap2
>> On ldap1 I was define dn replication user, replica and agreement
>> On ldap2 I was define replica only:
>>
> This is what you are doing wrong. Your ldap1 server will attempt to
> connect to ldap2 server using the replication user credentials. It is
> ldap2 which will be authenticating this request. Where would it take
> information about the replication user?
>
>
> filter: (objectclass=nsds5replica)
>> requesting: All userApplication attributes
>> # extended LDIF
>> #
>> # LDAPv3
>> # base with scope subtree
>> # filter: (objectclass=nsds5replica)
>> # requesting: ALL
>> #
>>
>> # replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
>> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
>> objectClass: top
>> objectClass: nsds5replica
>> objectClass: extensibleObject
>> cn: replica
>> nsDS5ReplicaRoot: dc=example,dc=com
>> nsDS5ReplicaType: 2
>> nsDS5ReplicaBindDN: cn=replication manager,cn=config
>> nsDS5Flags: 0
>> nsDS5ReplicaId: 65535
>> nsState:: //8AAAAAAABY2sZXAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
>> nsDS5ReplicaName: 06154b02-6f7e11e6-b236be05-3db8a3e8
>> nsds5ReplicaChangeCount: 0
>> nsds5replicareapactive: 0
>>
>> # search result
>> search: 2
>> result: 0 Success
>>
>> # numResponses: 2
>> # numEntries: 1
>>
>> Does I need define DN replication user on ldap2?
>>
>>
>> 2016-09-01 8:57 GMT+03:00 Alexander Bokovoy :
>>
>> On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>>>
>>> Hi, Alexander!
>>>>
>>>> Thank for fast reply.
>>>> I have replication manager object:
>>>> filter: (objectclass=organizationalPerson)
>>>> requesting: All userApplication attributes
>>>> # extended LDIF
>>>> #
>>>> # LDAPv3
>>>> # base with scope subtree
>>>> # filter: (objectclass=organizationalPerson)
>>>> # requesting: ALL
>>>> #
>>>>
>>>> # replication manager, config
>>>> dn: cn=replication manager,cn=config
>>>> objectClass: inetorgperson
>>>> objectClass: person
>>>> objectClass: top
>>>> objectClass: organizationalPerson
>>>> cn: replication manager
>>>> sn: RM
>>>> userPassword::
>>>> e1NTSEF9d281RGZOTTlCSEVWTEhxY1lTcGs0WHdjRXplemU4S280S3EwWnc9PQ=
>>>> =
>>>>
>>>> # search result
>>>> search: 2
>>>> result: 0 Success
>>>>
>>>> # numResponses: 2
>>>> # numEntries: 1
>>>>
>>>> But error is present.
>>>>
>>>> You have two LDAP servers. If you have replication going in both
>>> directions, you need to have the replication bind entry defined on both
>>> servers.
>>>
>>> If you have replication going in one direction, then the target server
>>> should have this replication bind entry defined.
>>>
>>> Where do you have this entry?
>>>
>>>
>>>
>>> --
>>> / Alexander Bokovoy
>>>
>>>
> --
>> 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
>>
>
>
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From abokovoy at redhat.com Thu Sep 1 08:10:50 2016
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 1 Sep 2016 11:10:50 +0300
Subject: [Freeipa-users] Command-line replication is not works in
FreeIPA-Master
In-Reply-To:
References:
<4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
<20160901041455.4xsgwvv5duxloi6g@redhat.com>
<20160901055724.lph3h65eequi4x44@redhat.com>
<20160901070126.xxb4u3iyqllll2oy@redhat.com>
Message-ID: <20160901081050.txeakqy2ag4t7u3i@redhat.com>
On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>Hi, Alexander!
>
>Than you very much for help. Now I able to start replica, but have one
>issue - schemes is not replicated:
>
>[01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Warning: unable to
>replicate schema to host ldap2, port 389. Continuing with total update
>session.
>[01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Beginning total update
>of replica "agmt="cn=ExampleAgreement" (ldap2:389)".
>[01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Need to create
>replication keep alive entry
>[01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - add dn: cn=repl keep
>alive 7,dc=example,dc=com
>objectclass: top
>objectclass: ldapsubentry
>objectclass: extensibleObject
>cn: repl keep alive 7
>[01/Sep/2016:07:04:58 +0000] NSMMReplicationPlugin - Finished total update
>of replica "agmt="cn=ExampleAgreement" (ldap2:389)". Sent 415 entries.
>
>Can you help me with schemes?
I'm afraid I cannot help with that. You need to read RHDS documentation
and design your own mechanism to make schema compatible on both sides.
Replicating schema between IPA and plain RHDS is not really supported as
nobody did that before, so you are on your own research and exploration
path to see what configuration should be.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Deployment_Guide/Designing_the_Replication_Process-Using_Replication_with_Other_DS_Features.html#Using_Replication_with_Other_DS_Features-Schema_Replication
--
/ Alexander Bokovoy
From a.rogovsky at gmail.com Thu Sep 1 10:01:03 2016
From: a.rogovsky at gmail.com (Andrey Rogovsky)
Date: Thu, 1 Sep 2016 13:01:03 +0300
Subject: [Freeipa-users] Command-line replication is not works in
FreeIPA-Master
In-Reply-To: <20160901081050.txeakqy2ag4t7u3i@redhat.com>
References:
<4e37eb09-8c96-114a-aee1-3c6ee568194f@redhat.com>
<20160901041455.4xsgwvv5duxloi6g@redhat.com>
<20160901055724.lph3h65eequi4x44@redhat.com>
<20160901070126.xxb4u3iyqllll2oy@redhat.com>
<20160901081050.txeakqy2ag4t7u3i@redhat.com>
Message-ID:
Hi, Alexander!
Thank for your reply
I was read your link, but it not related my issue. I will start new thread,
couse replica problem is resloved.
2016-09-01 11:10 GMT+03:00 Alexander Bokovoy :
> On Thu, 01 Sep 2016, Andrey Rogovsky wrote:
>
>> Hi, Alexander!
>>
>> Than you very much for help. Now I able to start replica, but have one
>> issue - schemes is not replicated:
>>
>> [01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Warning: unable to
>> replicate schema to host ldap2, port 389. Continuing with total update
>> session.
>> [01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Beginning total
>> update
>> of replica "agmt="cn=ExampleAgreement" (ldap2:389)".
>> [01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Need to create
>> replication keep alive entry
>> [01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - add dn: cn=repl keep
>> alive 7,dc=example,dc=com
>> objectclass: top
>> objectclass: ldapsubentry
>> objectclass: extensibleObject
>> cn: repl keep alive 7
>> [01/Sep/2016:07:04:58 +0000] NSMMReplicationPlugin - Finished total update
>> of replica "agmt="cn=ExampleAgreement" (ldap2:389)". Sent 415 entries.
>>
>> Can you help me with schemes?
>>
> I'm afraid I cannot help with that. You need to read RHDS documentation
> and design your own mechanism to make schema compatible on both sides.
> Replicating schema between IPA and plain RHDS is not really supported as
> nobody did that before, so you are on your own research and exploration
> path to see what configuration should be.
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Direct
> ory_Server/10/html/Deployment_Guide/Designing_the_
> Replication_Process-Using_Replication_with_Other_DS_Features
> .html#Using_Replication_with_Other_DS_Features-Schema_Replication
>
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From a.rogovsky at gmail.com Thu Sep 1 10:13:10 2016
From: a.rogovsky at gmail.com (Andrey Rogovsky)
Date: Thu, 1 Sep 2016 13:13:10 +0300
Subject: [Freeipa-users] Replication scheme problem
Message-ID:
Hi!
I have 2 servers - ldap1 is FreeIPA (master) and ldap2 is 389 DS (slave).
One way replication ldap1 -> ldap2 is enabled but scheme is not replicated:
Log file ldap1 have this line:
[01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Warning: unable to
replicate schema to host ldap2, port 389. Continuing with total update
session.
There is current status:
filter: (objectclass=nsds5replicationagreement)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=nsds5replicationagreement)
# requesting: ALL
#
# ExampleAgreement, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
dn: cn=ExampleAgreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,
cn=config
objectClass: top
objectClass: nsds5replicationagreement
cn: ExampleAgreement
nsDS5ReplicaHost: ldap2
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaRoot: dc=example,dc=com
description: agreement between supplier1 and consumer1
nsDS5ReplicaUpdateSchedule: 0000-0500 1
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE
authorityRevocationLis
t
nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
RERBNEJDUmxPVFl4TlRsbU5DMWtaV0UyTXpZeA0KTVMxaU1UYzFaREF3Wmkwek5qRmxNalkxWkFBQ
0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQURJbjhNUWpLM1VqU1
M1SGZEUTY0TA==}mwxKHUYWXjNeyo1AGRWe9A==
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 19700101000000Z
nsds5replicaLastUpdateEnd: 19700101000000Z
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: 0 No replication sessions started since
server s
tartup
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 20160901070452Z
nsds5replicaLastInitEnd: 20160901070455Z
nsds5replicaLastInitStatus: 0 Total update succeeded
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
After execute schema-reload.pl on ldap2 I have this lines in log:
Failed to add task entry "cn=schema_reload_2016_9_1_10_6_17, cn=schema
reload task, cn=tasks, cn=config" error (49)
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - Error: This ((targetattr =
"gidnumber || krbprincipalname || uidnumber")(version 3.0;acl
"permission:System: Read system trust accounts";allow (compare,read,search)
groupdn = "ldap:///cn=System: Read system trust
accounts,cn=permissions,cn=pbac,dc=example,dc=com";)) ACL will not be
considered for evaluation because of syntax errors.
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - __aclp__init_targetattr:
targetattr "ipaanchoruuid" does not exist in schema. Please add
attributeTypes "ipaanchoruuid" to schema if necessary.
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - ACL PARSE ERR(rv=-5):
(targetattr = "cn
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - Error: This ((targetattr = "cn
|| createtimestamp || description || entryusn || gidnumber || ipaanchoruuid
|| modifytimestamp || objectclass")(targetfilter =
"(objectclass=ipaGroupOverride)")(version 3.0;acl "permission:System: Read
Group ID Overrides";allow (compare,read,search) userdn = "ldap:///all";))
ACL will not be considered for evaluation because of syntax errors.
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - __aclp__init_targetattr:
targetattr "ipaanchoruuid" does not exist in schema. Please add
attributeTypes "ipaanchoruuid" to schema if necessary.
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - ACL PARSE ERR(rv=-5):
(targetattr = "createtimestamp
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - Error: This ((targetattr =
"createtimestamp || description || entryusn || gecos || gidnumber ||
homedirectory || ipaanchoruuid || ipaoriginaluid || ipasshpubkey ||
loginshell || modifytimestamp || objectclass || uid ||
uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl
"permission:System: Read User ID Overrides";allow (compare,read,search)
userdn = "ldap:///all";)) ACL will not be considered for evaluation because
of syntax errors.
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - __aclp__init_targetattr:
targetattr "a6record" does not exist in schema. Please add attributeTypes
"a6record" to schema if necessary.
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - ACL PARSE ERR(rv=-5):
(targetattr = "a6record
[01/Sep/2016:07:04:59 +0000] NSACLPlugin - Error: This ((targetattr =
"a6record || aaaarecord || afsdbrecord || aplrecord || arecord ||
certrecord || cn || cnamerecord || dhcidrecord || dlvrecord || dnamerecord
|| dnsclass || dnsttl || dsrecord || hinforecord || hiprecord ||
idnsallowdynupdate || idnsallowquery || idnsallowsyncptr ||
idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname ||
idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname ||
idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial ||
idnsupdatepolicy || idnszoneactive || ipseckeyrecord || keyrecord ||
kxrecord || locrecord || mdrecord || minforecord || mxrecord || naptrrecord
|| nsecrecord || nsec3paramrecord || nsrecord || nxtrecord || ptrrecord ||
rprecord || rrsigrecord || sigrecord || spfrecord || srvrecord ||
sshfprecord || tlsarecord || txtrecord || unknownrecord ")(target =
"ldap:///idnsname=*,cn=dns,dc=example,dc=com")(version 3.0;acl "Update DNS
entries in a zone";allow (write) userattr =
"parent[0,1].managedby#GROUPDN";)) ACL will not be considered for
evaluation because of syntax errors.
Looks, like ipaanchoruuid is missing. There is ldap scheme update:
filter: (objectclass=*)
requesting: 00core.ldif 01core389.ldif 02common.ldif 05rfc2927.ldif
05rfc4523.ldif 05rfc4524.ldif 06inetorgperson.ldif 10automember-plugin.ldif
10dna-plugin.ldif 10mep-plugin.ldif 10rfc2307.ldif 20subscriber.ldif
25java-object.ldif 28pilot.ldif 30ns-common.ldif 50ns-admin.ldif
50ns-certificate.ldif 50ns-directory.ldif 50ns-mail.ldif 50ns-value.ldif
50ns-web.ldif 60acctpolicy.ldif 60autofs.ldif 60eduperson.ldif
60mozilla.ldif 60nss-ldap.ldif 60pam-plugin.ldif
60posix-winsync-plugin.ldif 60pureftpd.ldif 60rfc2739.ldif 60rfc3712.ldif
60sabayon.ldif 60sudo.ldif 60trust.ldif 99user.ldif
No one scheme files from ldap2 have no entry for ipaanchoruuid. But from
ldap1 they have:
root at ldap1 schema]# grep -i ipaanchoruuid *
71idviews.ldif:attributeTypes: (2.16.840.1.113730.3.8.11.62 NAME
'ipaAnchorUUID' DESC 'Unique Anchor Identifier' EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'IPA v4')
71idviews.ldif:objectClasses: (2.16.840.1.113730.3.8.12.30 NAME
'ipaOverrideAnchor' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) MAY (
description ) X-ORIGIN 'IPA v4' )
71idviews.ldif:objectClasses: (2.16.840.1.113730.3.8.12.35 NAME
'ipaOverrideTarget' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA
v4' )
[root at ldap1 schema]#
How to resolve this issue? Just copy schemes files from ldap1 to ldap2?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rcritten at redhat.com Thu Sep 1 13:47:09 2016
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 1 Sep 2016 09:47:09 -0400
Subject: [Freeipa-users] IPA port 80
In-Reply-To:
References:
<459142cb-4db3-3158-2b43-6e85d147736a@0xc0dedbad.com>
Message-ID: <57C8315D.6010903@redhat.com>
Sean Hogan wrote:
> Thanks Peter,
>
>
> So the set up is each vlan has an IPA replica within the firewall
> boundary acting as its primary auth/policy server. If it goes down..
> then the clients can reach back thru the firewall to our backup IPAs. So
> I am trying to pinpoint the actual ports required to be open on the
> firewall to allow the clients the ability to get back to the back up IPAs.
>
> It comes down to opening ports thru the firewalls back to our IPA backup
> servers. If port 80 is not required for the clients or servers to get to
> IPA behind the firewall then there is no need in opening more ports than
> required and getting 443 open adheres more to our security policy than
> 80. So if everything is redirected to 443 and 80 is not required as it
> is all redirected then the docs I am using are not correct.
>
> I am hoping Simo can weigh in on this
Peter is right about OCSP/CRL. If you don't need them, and don't want a
user-friendly redirect if your users don't specify https then yeah, you
can probably do without port 80, assuming none of your clients REQUIRE
an OCSP response (e.g. security.OCSP.require in Firefox, false by default).
Another, rarely used path for port 80 is retrieval of the CA certificate
when enrolling clients. Normally it is retrieved over authenticated LDAP
but if that fails, and one isn't pre-positioned, it will fall back to
trying to get it over port 80 (last because this isn't exactly safe).
rob
>
>
> Redhat link shows this for firewall port openings
> _https://access.redhat.com/solutions/357673_
> with <-> seeming to indicate bidirectional. Not sure why NTP requires
> that for the clients.
>
> *Resolution**
> IdM Server <-> Clients*
> *Name*
>
> *Destination-port / Type*
>
> *Purpose*
> HTTP/HTTPS 80 / 443 TCP WebUI and IPA CLI admin tools communication.
> LDAP/LDAPS 389 / 636 TCP directory service communication.
> Kerberos 88 / 464 TCP and UDP communication for authentication
> DNS 53 TCP and UDP nameservice, used also for autodiscovery,
> autoregistration and High Availability Authentication(sssd), optional
> NTP 123 UDP network time protocol, optional
> kadmind 464 / 749 TCP used for principal generation, password changes etc.
>
> *
> IdM Server <-> IdM Server (i.e. Replica)*
> *Name*
>
> *Destination-port/Type*
>
> *Purpose*
> HTTP/HTTPS 80 / 443 TCP WebUI and IPA CLI admin tools communication.
> LDAP/LDAPS 389 / 636 TCP directory service communication.
> Kerberos 88 / 464 TCP and UDP communication for authentication
> DNS 53 / TCP and UDP nameservice, used also for autodiscovery,
> autoregistration and High Availability Authentication(sssd), *optional*
> NTP 123 UDP network time protocol, *optional*
> kadmind 464 / 749 TCP used only via localhost
> dogtag 7389 TCP Server and replica communication
> replica conf 9443 / 9444 / 9445 TCP Recplica configuration, only needed
> during initial replica installation -- IPAv3/RHEL6 only (not required at
> all in IPAv4/RHEL7)
>
> *Note:* In RHEL 7, 389 port is used for replication instead of 7389 port.
>
>
> Sean Hogan
>
>
>
>
>
> Inactive hide details for Peter Fern ---08/31/2016 04:01:30 PM---You
> need to serve CRLs and OCSP via HTTP to avoid clients failPeter Fern
> ---08/31/2016 04:01:30 PM---You need to serve CRLs and OCSP via HTTP to
> avoid clients failing to verify the cert of the host ser
>
> From: Peter Fern
> To: freeipa-users
> Date: 08/31/2016 04:01 PM
> Subject: Re: [Freeipa-users] IPA port 80
> Sent by: freeipa-users-bounces at redhat.com
>
> ------------------------------------------------------------------------
>
>
>
> You need to serve CRLs and OCSP via HTTP to avoid clients failing to
> verify the cert of the host serving the CRL/OCSP when the cert on that
> host needs to be verified at itself.
>
> I'm not sure why you'd particularly care though - reading the Apache
> configs and you should see that other than a couple of exceptions, all
> HTTP traffic is redirected to HTTPS.
>
> On 01/09/16 07:22, Sean Hogan wrote:
>
> Hi all,
>
> Been reading a lot about Port 80 for IPA and firewalls but have
> not found a concrete answer. I know the redhat docs indicate
> port 80 is required bidirectional however I need to investigate
> if it is truly needed.
>
> GUI only responds to 443 so not sure what else would be
> utilizing port 80. I have seen some references that dogtag
> proxies its ports to 80 and 443 but if the gui is running on 443
> does that mean dogtag is proxying via 443 only? Or is there a
> way to tell? Has anyone attempted not opening port 80 from IPA
> Server to IPA Server and clients to IPA server?
> ipa-server-3.0.0-50.el6.1.x86_64
>
>
>
>
> Sean Hogan
>
>
>
>
> --
> 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
>
>
>
>
From simo at redhat.com Thu Sep 1 13:56:06 2016
From: simo at redhat.com (Simo Sorce)
Date: Thu, 01 Sep 2016 09:56:06 -0400
Subject: [Freeipa-users] IPA port 80
In-Reply-To:
References:
<1472682951.5257.166.camel@redhat.com>
Message-ID: <1472738166.10392.13.camel@redhat.com>
On Thu, 2016-09-01 at 09:33 +1000, Peter Fern wrote:
> On 01/09/16 08:35, Simo Sorce wrote:
> > Port 80 is not required, the only thing you'll find there is a redirect
> > to the HTTPS port.
>
> What about CRL/OCSP (and possibly others)? The Apache configs
> explicitly do not redirect to HTTPS except for the /ipa path for this
> reason.
Oh right Peter, you are completely right.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
From schogan at us.ibm.com Thu Sep 1 15:16:42 2016
From: schogan at us.ibm.com (Sean Hogan)
Date: Thu, 1 Sep 2016 08:16:42 -0700
Subject: [Freeipa-users] IPA port 80
In-Reply-To: <57C8315D.6010903@redhat.com>
References:
<459142cb-4db3-3158-2b43-6e85d147736a@0xc0dedbad.com>
<57C8315D.6010903@redhat.com>
Message-ID:
Thank You for the clarification all.
Sean Hogan
From: Rob Crittenden
To: Sean Hogan/Durham/IBM at IBMUS, Peter Fern
Cc: freeipa-users
Date: 09/01/2016 06:47 AM
Subject: Re: [Freeipa-users] IPA port 80
Sean Hogan wrote:
> Thanks Peter,
>
>
> So the set up is each vlan has an IPA replica within the firewall
> boundary acting as its primary auth/policy server. If it goes down..
> then the clients can reach back thru the firewall to our backup IPAs. So
> I am trying to pinpoint the actual ports required to be open on the
> firewall to allow the clients the ability to get back to the back up
IPAs.
>
> It comes down to opening ports thru the firewalls back to our IPA backup
> servers. If port 80 is not required for the clients or servers to get to
> IPA behind the firewall then there is no need in opening more ports than
> required and getting 443 open adheres more to our security policy than
> 80. So if everything is redirected to 443 and 80 is not required as it
> is all redirected then the docs I am using are not correct.
>
> I am hoping Simo can weigh in on this
Peter is right about OCSP/CRL. If you don't need them, and don't want a
user-friendly redirect if your users don't specify https then yeah, you
can probably do without port 80, assuming none of your clients REQUIRE
an OCSP response (e.g. security.OCSP.require in Firefox, false by default).
Another, rarely used path for port 80 is retrieval of the CA certificate
when enrolling clients. Normally it is retrieved over authenticated LDAP
but if that fails, and one isn't pre-positioned, it will fall back to
trying to get it over port 80 (last because this isn't exactly safe).
rob
>
>
> Redhat link shows this for firewall port openings
> _https://access.redhat.com/solutions/357673_
> with <-> seeming to indicate bidirectional. Not sure why NTP requires
> that for the clients.
>
> *Resolution**
> IdM Server <-> Clients*
> *Name*
>
> *Destination-port / Type*
>
> *Purpose*
> HTTP/HTTPS 80 / 443 TCP WebUI and IPA CLI admin
tools communication.
> LDAP/LDAPS 389 / 636 TCP directory service
communication.
> Kerberos 88 / 464 TCP and UDP communication for
authentication
> DNS 53 TCP and UDP nameservice, used also for
autodiscovery,
> autoregistration and High Availability Authentication(sssd), optional
> NTP 123 UDP network time protocol, optional
> kadmind 464 / 749 TCP used for principal generation,
password changes etc.
>
> *
> IdM Server <-> IdM Server (i.e. Replica)*
> *Name*
>
> *Destination-port/Type*
>
> *Purpose*
> HTTP/HTTPS 80 / 443 TCP WebUI and IPA CLI admin
tools communication.
> LDAP/LDAPS 389 / 636 TCP directory service
communication.
> Kerberos 88 / 464 TCP and UDP communication for
authentication
> DNS 53 / TCP and UDP nameservice, used also for
autodiscovery,
> autoregistration and High Availability Authentication(sssd), *optional*
> NTP 123 UDP network time protocol, *optional*
> kadmind 464 / 749 TCP used only via localhost
> dogtag 7389 TCP Server and replica communication
> replica conf 9443 / 9444 / 9445 TCP Recplica
configuration, only needed
> during initial replica installation -- IPAv3/RHEL6 only (not required at
> all in IPAv4/RHEL7)
>
> *Note:* In RHEL 7, 389 port is used for replication instead of 7389 port.
>
>
> Sean Hogan
>
>
>
>
>
> Inactive hide details for Peter Fern ---08/31/2016 04:01:30 PM---You
> need to serve CRLs and OCSP via HTTP to avoid clients failPeter Fern
> ---08/31/2016 04:01:30 PM---You need to serve CRLs and OCSP via HTTP to
> avoid clients failing to verify the cert of the host ser
>
> From: Peter Fern
> To: freeipa-users
> Date: 08/31/2016 04:01 PM
> Subject: Re: [Freeipa-users] IPA port 80
> Sent by: freeipa-users-bounces at redhat.com
>
> ------------------------------------------------------------------------
>
>
>
> You need to serve CRLs and OCSP via HTTP to avoid clients failing to
> verify the cert of the host serving the CRL/OCSP when the cert on that
> host needs to be verified at itself.
>
> I'm not sure why you'd particularly care though - reading the Apache
> configs and you should see that other than a couple of exceptions, all
> HTTP traffic is redirected to HTTPS.
>
> On 01/09/16 07:22, Sean Hogan wrote:
>
> Hi all,
>
> Been reading a lot about Port 80 for IPA and firewalls but have
> not found a concrete answer. I know the redhat docs indicate
> port 80 is required bidirectional however I need to investigate
> if it is truly needed.
>
> GUI only responds to 443 so not sure what else would be
> utilizing port 80. I have seen some references that dogtag
> proxies its ports to 80 and 443 but if the gui is running on 443
> does that mean dogtag is proxying via 443 only? Or is there a
> way to tell? Has anyone attempted not opening port 80 from IPA
> Server to IPA Server and clients to IPA server?
> ipa-server-3.0.0-50.el6.1.x86_64
>
>
>
>
> Sean Hogan
>
>
>
>
> --
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
From mbasti at redhat.com Thu Sep 1 16:27:15 2016
From: mbasti at redhat.com (Martin Basti)
Date: Thu, 1 Sep 2016 18:27:15 +0200
Subject: [Freeipa-users] Announcing FreeIPA 4.4.1
Message-ID: <13e4828e-bfcd-6bc7-6dde-52a9902be9b6@redhat.com>
The FreeIPA team would like to announce FreeIPA v4.4.1 release!
It can be downloaded from http://www.freeipa.org/page/Downloads.
Builds for Fedora 24 will be available in the official COPR repository
.
== Highlights in 4.4.1 ==
=== Enhancements ===
* Kerberos KDC now takes Authentication Indicators into account when
issuing service tickets. This allows, for example, to require two-factor
authenticated Kerberos credentials prior to obtaining tickets to a VPN
service.
* FreeIPA Certificate Authority now is able to create subordinate CAs to
issue certificates with a specific scope
* Web UI and API end-points now can be configured to log-in with client
certificates and smart cards. Additional configuration details are
described in the External Authentication design page
.
* Web UI now suggests to have redundancy in Certificate Authority topology
* Custom FreeIPA plugins can now be built without modifying core FreeIPA
code
* When establishing trust to an Active Directory forest, FreeIPA now is
capable on automatically resolving DNS namespace conflicts with another
Active Directory forest.
=== Known Issues ===
* Interactive CLI input for dnsrecord-* commands does not work properly
for multipart records
* ipa-ca-install fails on replica when master is CA-less
* Lightweight sub-CA certs are not tracked by certmonger after
`ipa-replica-install`
* Certificate revocation in service-del and host-del isn't aware of Sub
CAs and causes command to fail when Sub CA cert is used
=== Bug fixes ===
FreeIPA 4.4.1 is a stabilization release for the features delivered as a
part of 4.4.0. There are more than 140 bug-fixes which details can be
seen in the list of resolved tickets below.
== Upgrading ==
Upgrade instructions are available on [[Upgrade]] page.
== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users
mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or
#freeipa channel on Freenode.
== Detailed changelog since 4.4.0 ==
=== Abhijeet Kasurde (4) ===
* Minor fix in ipa-replica-manage MAN page
* Corrected minor spell check in AD Trust information doc messages
* Removed unwanted line break from RefererError Dialog message
* Handled empty hostname in server-del command
=== Alexander Bokovoy (9) ===
* service: add flag to allow S4U2Self
* support schema files from third-party plugins
* ipaserver/dcerpc: reformat to make the code closer to pep8
* trust: automatically resolve DNS trust conflicts for triangle trusts
* trust: make sure external trust topology is correctly rendered
* trust: make sure ID range is created for the child domain even if it
exists
* ipa-kdb: simplify trusted domain parent search
* support multiple uid values in schema compatibility tree
* freeipa.spec.in: move ipa CLI utility to freeipa-client
=== Ben Lipton (3) ===
* Fix several small typos
* Use existing HostKey config to test sshd
* Silence sshd messages during install
=== Christian Heimes (5) ===
* Correct path to HTTPD's systemd service directory
* RedHatCAService should wait for local Dogtag instance
* Remove Custodia server keys from LDAP
* Secure permissions of Custodia server.keys
* Require httpd 2.4.6-31 with mod_proxy Unix socket support
=== David Kupka (21) ===
* schema: Fix subtopic -> topic mapping
* help: Add dnsserver commands to help topic 'dns'
* vault: Catch correct exception in decrypt
* schema: Speed up schema cache
* frontend: Change doc, summary, topic and NO_CLI to class properties
* schema: Introduce schema cache format
* schema: Generate bits for help load them on request
* help: Do not create instances to get information about commands and topics
* compat: Save server's API version in for pre-schema servers
* schema cache: Do not reset ServerInfo dirty flag
* schema cache: Do not read fingerprint and format from cache
* Access data for help separately
* frontent: Add summary class property to CommandOverride
* schema cache: Read server info only once
* schema cache: Store API schema cache in memory
* client: Do not create instance just to check isinstance
* schema cache: Read schema instead of rewriting it when SchemaUpToDate
* schema check: Check current client language against cached one
* compat: Fix ping command call
* schema cache: Fallback to 'en_us' when locale is not available
* otptoken, permission: Convert custom type parameters on server
=== Florence Blanc-Renaud (4) ===
* Show full error message for selinuxusermap-add-hostgroup
* server uninstall fails to remove krb principals
* Fix session cookies
* Fix ipa hbactest output
=== Fraser Tweedale (11) ===
* uninstall: untrack lightweight CA certs
* caacl: expand plugin documentation
* spec: require Dogtag >= 10.3.3-3
* Create server and host certs with DNS altname
* caacl: fix regression in rule instantiation
* cert-revoke: fix permission check bypass (CVE-2016-5404)
* Move GeneralName parsing code to ipalib.x509
* x509: fix SAN directoryName parsing
* x509: use NSS enums and OIDs to identify SAN types
* x509: include otherName DER value in GeneralNameInfo
* cert-show: show subject alternative names
=== Ganna Kaihorodova (2) ===
* Fix conflict between "got" and "expected" values
* Fix for integration tests replication layouts
=== Jan Cholasta (19) ===
* frontend: copy command arguments to output params on client
* Revert "Enable vault-* commands on client"
* client: fix hiding of commands which lack server support
* compat: fix ping call
* install: fix external CA cert validation
* vault: add missing salt option to vault_mod
* Revert "spec: add conflict with bind-chroot to freeipa-server-dns"
* parameters: move the `confirm` kwarg to Param
* client: add missing output params to client-side commands
* cert: speed up cert-find
* cert: do not crash on invalid data in cert-find
* server install: do not prompt for cert file PIN repeatedly
* tests: fix test_ipalib.test_frontend.test_Object
* custodia: include known CA certs in the PKCS#12 file for Dogtag
* cert: add missing param values to cert-find output
* cert: include CA name in cert command output
* rpcserver: assume version 1 for unversioned command calls
* custodia: force reconnect before retrieving CA certs from LDAP
* rpcserver: fix crash in XML-RPC system commands
=== Lenka Doudova (26) ===
* Tests: Tracker class for services
* Tests: Authentication indicators xmlrpc tests
* Tests: Authentication indicators integration tests
* Tests: External trust
* Tests: Support of UPN for trusted domains
* Tests: Improve handling of rename operation by user tracker
* Tests: IPA user can kinit using enterprise principal with IPA domain
* Tests: Removing manipulation with /etc/hosts file from integration tests
* Tests: Remove has_keytab from list of expected keys of update command
* Tests: Add data attribute to messages
* Tests: test_ipalib/test_output fails due to change of Output behaviour
* Fix malformed or missing docstrings in ipalib/messages
* Tests: Fix failing tests in test_ipalib/test_parameters
* Tests: Fix failing tests in test_ipalib/test_frontend
* Tests: ID views tests do not recognize ipakrboktoauthasdelegate sttribute
* Tests: Duplicate declaration on variables in ID views tests
* Tests: ID views tests do not recognize krbcanonicalname attribute
* Tests: Host tracker does not recognize 'ipakrboktoauthasdelegate'
attribute
* Tests: Service tracker and tests don't recognize
'ipakrboktoauthasdelegate' attribute
* Tests: Failing test_ipalib/test_rpc
* Tests: Failing test_ipaserver/test_ldap test
* Tests: Failing tests in test_ipalib/test_plugable
* Raise error when running ipa-adtrust-install with empty netbios--name
* Tests: Random issuer certificate can be added to a service
* Tests: Add missing attributes to test_xmlrpc/test_trust tests
* Tests: Avoid skipping tests due to missing files
=== Luk?? Slebodn?k (4) ===
* ipa_pwd_extop: Fix warning declaration shadows previous local
* ipa-pwd-extop: Fix warning assignment discards ?const? qualifier from
pointer
* ipa-kdb: Allow to build with samba 4.5
* ipa-kdb: Fix unit test after packaging changes in krb5
=== Martin Babinsky (20) ===
* Fix incorrect check for principal type when evaluating CA ACLs
* ipa-nis-manage: Use server API to retrieve plugin status
* ipa-compat-manage: use server API to retrieve plugin status
* ipa-advise: correct handling of plugin namespace iteration
* vault-add: set the default vault type on the client side if none was given
* Preserve user principal aliases during rename operation
* messages: specify message type for ResultFormattingError
* DNS install: Ensure that DNS servers container exists
* Use server API in com.redhat.idm.trust-fetch-domains oddjob helper
* allow 'value' output param in commands without primary key
* allow multiple dashes in the components of server hostname
* expose `--secret` option in radiusproxy-* commands
* prevent search for RADIUS proxy servers by secret
* trust-add: handle `--all/--raw` options properly
* baseldap: Fix MidairCollision instantiation during entry modification
* Create indexes for krbCanonicalName attribute
* harden the check for trust namespace overlap in new principals
* re-set canonical principal name on migrated users
* add python-libsss_nss_idmap and python-sss to BuildRequires
* do not use trusted forest name to construct domain admin principal
=== Martin Ba?ti (18) ===
* Enable vault-* commands on client
* host-find: do not show SSH key by default
* CI: DNS locations
* Host-del: fix behavior of --updatedns and PTR records
* DNS Locations: fix update-system-records unpacking error
* Use copy when replacing files to keep SELinux context
* CI tests: improve log collecting
* CI tests: fix SSSD log collecting
* idrange: fix unassigned global variable
* Do not initialize API in ipa-client-automount uninstall
* Increase default length of auto generated passwords
* ipa-backup: backup /etc/tmpfiles.d/dirsrv-.conf
* Fix: container owner should be able to add vault
* Remove forgotten print from DN.__str__ implementation
* Raise DuplicatedEnrty error when user exists in delete_container
* Update translations
* Print to debug output answer from CA
* Revert "Enable LDAPS in replica promotion"
=== Milan Kub?k (12) ===
* ipatests: Tracker implementation for Sub CA feature
* ipatests: Extend CAACL suite to cover Sub CA members
* ipatests: Test Sub CA with CAACL and certificate profile
* ipatests: remove ipacertbase option from test CSR configuration
* ipatests: Add tracker class for kerberos principal aliases
* ipatests: Extend the MockLDAP utility class
* ipatests: Provide a context manager for mocking a trust in RPC tests
* ipatests: Move trust mock helper functions to a separate module
* ipapython: Extend kinit_password to support principal canonicalization
* ipatests: Allow change_principal context manager to use canonicalization
* ipatests: Add kerberos principal alias tests
* ipatests: Fix wrong fixture in kerberos principal alias test
=== Oleg Fayans (7) ===
* Test for incorrect client domain
* Fixed import error
* Fixed incorrect return code assert
* Fixed incorrect domainlevel determination in tests
* Fixed incorrect sequence of method calls in tasks.py
* Added a sleep interval after domainlevel raise in tests
* Disabled raiseonerr in kinit call during topology level check
=== Pavel Vomacka (12) ===
* Close host adder dialog before showing 4304 dialog
* Remove navigation using breadcrumb menus
* Fix test_navigation tests
* Fix test which checks removing of user
* Set default delete action name to 'delete'
* Remove full name from adding user to user group dialog
* Add function which check whether the field is empty
* Add jslint into Makefile
* Fix unicode characters in ca and domain adders
* Add warning about only one existing CA server
* Set servers list as default facet in topology facet group
* Add 'trusted to auth as user' checkbox
=== Peter Lacko (1) ===
* Test URIs in certificate.
=== Petr Voborn?k (2) ===
* unite log file name of ipa-ca-install
* ca-less tests: fix getting cert in pem format from nssdb
=== Petr ?pa?ek (15) ===
* client-install: log exceptions from certmonger.request_cert
* replica-install: Fix --domain
* Fix ipa-replica-prepare's error message about missing local CA instance
* client: RPM require initscripts to get *-domainname.service
* server-install: Fix --hostname option to always override api.env values
* install: Call hostnamectl set-hostname only if --hostname option is used
* DNS server upgrade: do not fail when DNS server did not respond
* server upgrade: do not start BIND if it was not running before the upgrade
* DNS: allow to add forward zone to already broken sub-domain
* adtrust-install: Mention AD GC port 3286 in list of required ports.
* config-mod: normalize attribute names for --usersearch/--groupsearch
* migrate-ds: Mention --enable-migration in error message about
migration mode
* Fix man page ipa-replica-manage: remove duplicate -c option from
--no-lookup
* Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin
* Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin
=== Simo Sorce (4) ===
* Simplify date manipulation in pwd plugin
* Regenerate asn1 code
* Additional coverity fixes.
* Fix CA ACL Check on SubjectAltNames
=== Stanislav Laznicka (7) ===
* Removed unused method parameter from migrate-ds
* Improvements for the ipa-cacert-manage man and help
* Removed objectclass from LDAP*ReverseMember based tests
* Don't show --force-ntpd option in replica install
* Remove sys.exit from install modules and scripts
* Fail on topology disconnect/last role removal
* Don't ignore --ignore-last-of-role for last CA
=== Sumit Bose (1) ===
* kdb: check for local realm in enterprise principals
=== Thierry Bordaz (2) ===
* Heap corruption in ipapwd plugin
* ipa-pwd-extop memory leak during passord update
=== Tiboris (1) ===
* Added new authentication method
=== Tomas Krizek (5) ===
* Update ipa-replica-install documentation
* Fix ipa-caalc-add-service error message
* Validate key in otptoken-add
* Fix ipa-server-install in pure IPv6 environment
* Enable LDAPS in replica promotion
=== gkaihoro (1) ===
* Test for caacl-add-service
=== tester (4) ===
* Add possibility to choose parent element by css
* TEST: managing user certificates
* TEST: managing host certificates
* TEST: managing service certificates
From william.muriithi at gmail.com Thu Sep 1 19:20:13 2016
From: william.muriithi at gmail.com (William Muriithi)
Date: Thu, 1 Sep 2016 15:20:13 -0400
Subject: [Freeipa-users] openLDAP to FreeIPA user migration
Message-ID:
Afternoon,
I have an openLDAP system that lack a required attribute. This result
in the migration script rejecting all the user import.
I have googled externsively, read ever line of ipa migration --help
doc and it doesn't seem I will be able to use this migration script.
I wonder if there is anybody here who have been able to overcome this
problem in the past.
[root at hydrogen ~]# ipa -v migrate-ds --with-compat
--bind-dn="cn=admin,dc=eng.example,dc=com"
--user-ignore-attribute="sn"
--user-container="ou=People,dc=eng.example,dc=com"
--group-container="ou=Group,dc=eng.example,dc=com"
--group-objectclass="posixGroup" --user-objectclass="account"
ldap://192.168.20.18:389
ipa: INFO: trying https://hydrogen.eng.example.com/ipa/session/json
Password:
ipa: INFO: Forwarding 'migrate_ds' to json server
'https://hydrogen.eng.example.com/ipa/session/json'
-----------
migrate-ds:
-----------
Migrated:
Failed user:
aagrim: missing attribute "sn" required by object class "organizationalPerson"
acctemp: missing attribute "sn" required by object class
"organizationalPerson"
...........
Regards,
William
From abokovoy at redhat.com Thu Sep 1 19:26:57 2016
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 1 Sep 2016 22:26:57 +0300
Subject: [Freeipa-users] openLDAP to FreeIPA user migration
In-Reply-To:
References:
Message-ID: <20160901192657.mamcazshrv2ircb6@redhat.com>
On Thu, 01 Sep 2016, William Muriithi wrote:
>Afternoon,
>
>I have an openLDAP system that lack a required attribute. This result
>in the migration script rejecting all the user import.
>
>I have googled externsively, read ever line of ipa migration --help
>doc and it doesn't seem I will be able to use this migration script.
>I wonder if there is anybody here who have been able to overcome this
>problem in the past.
>
>[root at hydrogen ~]# ipa -v migrate-ds --with-compat
>--bind-dn="cn=admin,dc=eng.example,dc=com"
>--user-ignore-attribute="sn"
>--user-container="ou=People,dc=eng.example,dc=com"
>--group-container="ou=Group,dc=eng.example,dc=com"
>--group-objectclass="posixGroup" --user-objectclass="account"
>ldap://192.168.20.18:389
>ipa: INFO: trying https://hydrogen.eng.example.com/ipa/session/json
>Password:
>ipa: INFO: Forwarding 'migrate_ds' to json server
>'https://hydrogen.eng.example.com/ipa/session/json'
>-----------
>migrate-ds:
>-----------
>Migrated:
>Failed user:
> aagrim: missing attribute "sn" required by object class "organizationalPerson"
> acctemp: missing attribute "sn" required by object class
>"organizationalPerson"
> ...........
This looks like a common problem. I had recently made a small 'hack' to
solve this problem.
Following small fixup plugin could be used to affect how entries are
generated. If you add it to /usr/lib/python2.7/site-packages/ipalib/plugins
on IPA master and restart httpd service, the plugin would modify migrate-ds command so
that 'sn' attribute would be set to a 'Migrated User Last Name' for all
entries that miss 'sn' attribute before they actually get added into IPA
LDAP.
This is an experimental hack, of course, but it should work. Once
migration is finished, don't forget to remove the file and restart httpd
service again.
--
/ Alexander Bokovoy
-------------- next part --------------
from .migration import migrate_ds
_fixup_pre_callback_user = None
def _pre_callback_user(ldap, pkey, dn, entry_attrs, failed, config, ctx, **kwargs):
dn = _fixup_pre_callback_user(ldap, pkey, dn, entry_attrs, failed, config, ctx, **kwargs)
if entry_attrs.get('sn', None) is None:
entry_attrs['sn'] = [u'Migrated User Last Name']
return dn
_fixup_pre_callback_user = migrate_ds.migrate_objects['user']['pre_callback']
migrate_ds.migrate_objects['user']['pre_callback'] = _pre_callback_user
From kashmancy at gmail.com Fri Sep 2 00:05:28 2016
From: kashmancy at gmail.com (Harry Kashouli)
Date: Thu, 1 Sep 2016 17:05:28 -0700
Subject: [Freeipa-users] Remote users and passwords
Message-ID:
Hi all,
I have FreeIPA set up on my home server (Fedora 24), and I would like for
remote users to be able to set up new passwords, after I set them up with a
default one. Most likely, they will be running Windows.
What is the best/suggested/correct method to do this?
Thanks,
-Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lslebodn at redhat.com Fri Sep 2 07:27:57 2016
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Fri, 2 Sep 2016 09:27:57 +0200
Subject: [Freeipa-users] SUDO and group lookup in AD trust
In-Reply-To: <20160826055407.sok4s6c7ehtwoe3q@hendrix>
References: <2050149863.1012561.1471958268423.JavaMail.zimbra@casalogic.dk>
<20160824075009.rj73yous3ptypj54@hendrix>
<1433616466.7119.1472107348774.JavaMail.zimbra@casalogic.dk>
<1121029446.9457.1472109874936.JavaMail.zimbra@casalogic.dk>
<260135086.10187.1472112336235.JavaMail.zimbra@casalogic.dk>
<20160825084820.GB30315@10.4.128.1>
<1042341051.13710.1472117452652.JavaMail.zimbra@casalogic.dk>
<20160825204152.GA6360@10.4.128.1>
<20160826055407.sok4s6c7ehtwoe3q@hendrix>
Message-ID: <20160902072757.GA6086@10.4.128.1>
On (26/08/16 07:54), Jakub Hrozek wrote:
>On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
>> On (25/08/16 11:30), Troels Hansen wrote:
>> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>> >getting a version 1.14.1, clean cache DB (complaing about cache being
>> >old version),
>> Upgrade to 1.14.1 should not require puring sssd cache.
>> If you are able to reproduce then please provide steps.
>> Or file a sssd bug https://fedorahosted.org/sssd/newticket
>>
>> >I can getent users, but log log in for no obvious reason (system error in secure.log).
>> >
>> system error sounds bad. Please provide log files with
>> high debug level in domain section sssd.conf
>>
>> https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs
>
>We were debugging this yesterday with Troels and the logs said it's:
> https://fedorahosted.org/sssd/ticket/3127
>
Fixed version is in 1.14 copr
LS
From jhrozek at redhat.com Fri Sep 2 07:56:29 2016
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Fri, 2 Sep 2016 09:56:29 +0200
Subject: [Freeipa-users] SUDO and group lookup in AD trust
In-Reply-To: <20160902072757.GA6086@10.4.128.1>
References: <2050149863.1012561.1471958268423.JavaMail.zimbra@casalogic.dk>
<20160824075009.rj73yous3ptypj54@hendrix>
<1433616466.7119.1472107348774.JavaMail.zimbra@casalogic.dk>
<1121029446.9457.1472109874936.JavaMail.zimbra@casalogic.dk>
<260135086.10187.1472112336235.JavaMail.zimbra@casalogic.dk>
<20160825084820.GB30315@10.4.128.1>
<1042341051.13710.1472117452652.JavaMail.zimbra@casalogic.dk>
<20160825204152.GA6360@10.4.128.1>
<20160826055407.sok4s6c7ehtwoe3q@hendrix>
<20160902072757.GA6086@10.4.128.1>
Message-ID: <20160902075629.djs3yy22zk4p3kiz@hendrix>
On Fri, Sep 02, 2016 at 09:27:57AM +0200, Lukas Slebodnik wrote:
> On (26/08/16 07:54), Jakub Hrozek wrote:
> >On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
> >> On (25/08/16 11:30), Troels Hansen wrote:
> >> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
> >> >getting a version 1.14.1, clean cache DB (complaing about cache being
> >> >old version),
> >> Upgrade to 1.14.1 should not require puring sssd cache.
> >> If you are able to reproduce then please provide steps.
> >> Or file a sssd bug https://fedorahosted.org/sssd/newticket
> >>
> >> >I can getent users, but log log in for no obvious reason (system error in secure.log).
> >> >
> >> system error sounds bad. Please provide log files with
> >> high debug level in domain section sssd.conf
> >>
> >> https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs
> >
> >We were debugging this yesterday with Troels and the logs said it's:
> > https://fedorahosted.org/sssd/ticket/3127
> >
> Fixed version is in 1.14 copr
Thank you, btw another affected user confirmed that the patch fixes the
problem.
From rene.trippen at gmail.com Fri Sep 2 09:39:00 2016
From: rene.trippen at gmail.com (Rene Trippen)
Date: Fri, 2 Sep 2016 11:39:00 +0200
Subject: [Freeipa-users] Migrate users with password from one IPA to
another
In-Reply-To:
References:
<57BF2E8C.80800@redhat.com>
Message-ID:
Hi,
is it possible to transfer the Kerberos Master Key to the new IPA Server?
- rene
On 31.08.2016 10:57, Rene Trippen wrote:
> On 25.08.2016 19:44, Rob Crittenden wrote:
>> Rene Trippen wrote:
>>> Hi,
>>>
>>> I`ve got an IPA with a broken CA infrastructure (don`t know what
>>> happened, but new clients cannot be registered)
>>> It is even not possible to setup a new replica.
>>
>> It may be fairly straightforward to getting the CA back up. How is it
>> broken?
>>
> I don't know how that happened exactly, we had an IPA 3.x Server, then
> we migrated it to another machine and upgraded to IPA 4.1, later, we
> upgraded (on the same machine) to IPA 4.2.
> The IPA Server is basically working, but when I want to register a new
> machine, the registration process fails with following (I think these
> are the relevant lines) error
>
> 2016-08-30T22:40:25Z DEBUG flushing ldap://ipa.internal.domain:389
> from SchemaCache
> 2016-08-30T22:40:25Z DEBUG retrieving schema for SchemaCache
> url=ldap://ipa.internal.domain:389
> conn=
> 2016-08-30T22:40:26Z DEBUG Adding CA certificates to the IPA NSS
> database.
> 2016-08-30T22:40:26Z DEBUG Starting external process
> 2016-08-30T22:40:26Z DEBUG args='/usr/bin/certutil' '-d'
> '/etc/ipa/nssdb' '-A' '-n' 'INTERNAL.DOMAIN IPA CA' '-t' 'CT,C,C'
> 2016-08-30T22:40:26Z DEBUG Process finished, return code=0
> 2016-08-30T22:40:26Z DEBUG stdout=
> 2016-08-30T22:40:26Z DEBUG stderr=
> 2016-08-30T22:40:26Z DEBUG Starting external process
> 2016-08-30T22:40:26Z DEBUG args='/usr/bin/certutil' '-d'
> '/etc/ipa/nssdb' '-A' '-n' 'INTERNAL.DOMAIN IPA CA' '-t' 'CT,C,C'
> 2016-08-30T22:40:26Z DEBUG Process finished, return code=255
> 2016-08-30T22:40:26Z DEBUG stdout=
> 2016-08-30T22:40:26Z DEBUG stderr=certutil: could not add certificate
> to token or database: SEC_ERROR_ADDING_CERT: Error adding certificate
> to database.
>
> 2016-08-30T22:40:26Z ERROR Failed to add INTERNAL.DOMAIN IPA CA to the
> IPA NSS database.
> 2016-08-30T22:40:26Z ERROR Installation failed. Rolling back changes.
>
>
> The client tries to add 2 certificates, but fails with the second, I
> think, it is because we have 2 CA certificates (one from the old IPA
> 3.x server and one from the new 4.x server). My current workaround is
> to register the client with an ipa3.x client, then I do an upgrade to
> the 4.x client
>
> I've tried many ways to setup a new CA:
> - tried ipa-cacert-manage renew
> - tried to setup a new replica with new CA, but the setup failed with
> the same problems described above
> - tried to remove all old certificates refering to the old ipa server
> (but I think I failed somewhere)
>
> My thoughts are, the CA is in a bad condition, and I spent much time
> in trying to fix it, with no success. And, my fears are, if I find
> some crude, not documented workaround for the CA problem, the problem
> maybe pops up at the next update. So, setting up a fresh IPA and
> migrating everything (except the clients), was my hope to get an IPA
> running without all the CA problems. Migrating the clients is not the
> problem, that can be done by script (spacewalk or ansible), but
> migrating the users is not that easy, because the users cannot be
> scripted :)
>
>
>>> So, I wanted to setup a new IPA Server with new CA, and I want to move
>>> all users with their passwords to the new IPA instance.
>>> I`ve tried with 'ipa migrate-ds'
>>>
>>> ipa migrate-ds --continue --bind-dn="cn=Directory Manager"
>>> --user-container=cn=users,cn=accounts
>>> --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup
>>> --group-overwrite-gid --with-compat ldap://
>>>
>>> The output is OK
>>> =======
>>> Passwords have been migrated in pre-hashed format.
>>> IPA is unable to generate Kerberos keys unless provided
>>> with clear text passwords. All migrated users need to
>>> login at https://your.domain/ipa/migration/ before they
>>> can use their Kerberos accounts.
>>> ========
>>>
>>> But the ipa/migration website is not working for me.
>>> Anyway, is there a way to export the users with passwords? I think I
>>> have to export some kerberos specific stuff from the old IPA?
>>
>> The log file /var/log/httpd/error_log may have details on what isn't
>> working.
>
> Sorry, that was not clearly described:
>
> The site is basically working, but when I enter the password, nothing
> happens in the backend (I cannot login with my user on the ipa login
> site).
>
> - rene
>
>>
>> The way to export users with passwords is the method you've already
>> tried. To not have to change a password at all would require the same
>> Kerberos master key and these are generated randomly at install time.
>>
>> rob
>>
>
From ezajko at root.ba Fri Sep 2 10:24:17 2016
From: ezajko at root.ba (Ernedin Zajko)
Date: Fri, 2 Sep 2016 12:24:17 +0200
Subject: [Freeipa-users] openLDAP to FreeIPA user migration
In-Reply-To: <20160901192657.mamcazshrv2ircb6@redhat.com>
References:
<20160901192657.mamcazshrv2ircb6@redhat.com>
Message-ID:
Hi Alexander,
thank you for this - i think this should even work for missing some
mandatory (gid) attributes...
regards,
--- Ernedin ZAJKO
ezajko at root.ba
> 340282366920938463463374607431768211456
On Thu, Sep 1, 2016 at 9:26 PM, Alexander Bokovoy wrote:
> On Thu, 01 Sep 2016, William Muriithi wrote:
>>
>> Afternoon,
>>
>> I have an openLDAP system that lack a required attribute. This result
>> in the migration script rejecting all the user import.
>>
>> I have googled externsively, read ever line of ipa migration --help
>> doc and it doesn't seem I will be able to use this migration script.
>> I wonder if there is anybody here who have been able to overcome this
>> problem in the past.
>>
>> [root at hydrogen ~]# ipa -v migrate-ds --with-compat
>> --bind-dn="cn=admin,dc=eng.example,dc=com"
>> --user-ignore-attribute="sn"
>> --user-container="ou=People,dc=eng.example,dc=com"
>> --group-container="ou=Group,dc=eng.example,dc=com"
>> --group-objectclass="posixGroup" --user-objectclass="account"
>> ldap://192.168.20.18:389
>> ipa: INFO: trying https://hydrogen.eng.example.com/ipa/session/json
>> Password:
>> ipa: INFO: Forwarding 'migrate_ds' to json server
>> 'https://hydrogen.eng.example.com/ipa/session/json'
>> -----------
>> migrate-ds:
>> -----------
>> Migrated:
>> Failed user:
>> aagrim: missing attribute "sn" required by object class
>> "organizationalPerson"
>> acctemp: missing attribute "sn" required by object class
>> "organizationalPerson"
>> ...........
>
> This looks like a common problem. I had recently made a small 'hack' to
> solve this problem.
>
> Following small fixup plugin could be used to affect how entries are
> generated. If you add it to /usr/lib/python2.7/site-packages/ipalib/plugins
> on IPA master and restart httpd service, the plugin would modify migrate-ds
> command so
> that 'sn' attribute would be set to a 'Migrated User Last Name' for all
> entries that miss 'sn' attribute before they actually get added into IPA
> LDAP.
>
> This is an experimental hack, of course, but it should work. Once
> migration is finished, don't forget to remove the file and restart httpd
> service again.
>
> --
> / Alexander Bokovoy
>
> --
> 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
From abokovoy at redhat.com Fri Sep 2 10:31:11 2016
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 2 Sep 2016 13:31:11 +0300
Subject: [Freeipa-users] openLDAP to FreeIPA user migration
In-Reply-To:
References:
<20160901192657.mamcazshrv2ircb6@redhat.com>
Message-ID: <20160902103111.hs6ww45kfpc72iyw@redhat.com>
On Fri, 02 Sep 2016, Ernedin Zajko wrote:
>Hi Alexander,
>
>thank you for this - i think this should even work for missing some
>mandatory (gid) attributes...
Yes, this fixup module can be used for anything to inject.
>
>regards,
>
>--- Ernedin ZAJKO
> ezajko at root.ba
>
>> 340282366920938463463374607431768211456
>
>
>
>On Thu, Sep 1, 2016 at 9:26 PM, Alexander Bokovoy wrote:
>> On Thu, 01 Sep 2016, William Muriithi wrote:
>>>
>>> Afternoon,
>>>
>>> I have an openLDAP system that lack a required attribute. This result
>>> in the migration script rejecting all the user import.
>>>
>>> I have googled externsively, read ever line of ipa migration --help
>>> doc and it doesn't seem I will be able to use this migration script.
>>> I wonder if there is anybody here who have been able to overcome this
>>> problem in the past.
>>>
>>> [root at hydrogen ~]# ipa -v migrate-ds --with-compat
>>> --bind-dn="cn=admin,dc=eng.example,dc=com"
>>> --user-ignore-attribute="sn"
>>> --user-container="ou=People,dc=eng.example,dc=com"
>>> --group-container="ou=Group,dc=eng.example,dc=com"
>>> --group-objectclass="posixGroup" --user-objectclass="account"
>>> ldap://192.168.20.18:389
>>> ipa: INFO: trying https://hydrogen.eng.example.com/ipa/session/json
>>> Password:
>>> ipa: INFO: Forwarding 'migrate_ds' to json server
>>> 'https://hydrogen.eng.example.com/ipa/session/json'
>>> -----------
>>> migrate-ds:
>>> -----------
>>> Migrated:
>>> Failed user:
>>> aagrim: missing attribute "sn" required by object class
>>> "organizationalPerson"
>>> acctemp: missing attribute "sn" required by object class
>>> "organizationalPerson"
>>> ...........
>>
>> This looks like a common problem. I had recently made a small 'hack' to
>> solve this problem.
>>
>> Following small fixup plugin could be used to affect how entries are
>> generated. If you add it to /usr/lib/python2.7/site-packages/ipalib/plugins
>> on IPA master and restart httpd service, the plugin would modify migrate-ds
>> command so
>> that 'sn' attribute would be set to a 'Migrated User Last Name' for all
>> entries that miss 'sn' attribute before they actually get added into IPA
>> LDAP.
>>
>> This is an experimental hack, of course, but it should work. Once
>> migration is finished, don't forget to remove the file and restart httpd
>> service again.
>>
>> --
>> / Alexander Bokovoy
>>
>> --
>> 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
--
/ Alexander Bokovoy
From william.muriithi at gmail.com Fri Sep 2 11:44:38 2016
From: william.muriithi at gmail.com (William Muriithi)
Date: Fri, 2 Sep 2016 07:44:38 -0400
Subject: [Freeipa-users] openLDAP to FreeIPA user migration
Message-ID:
Morning Alexander,
>>Failed user:
>> aagrim: missing attribute "sn" required by object class "organizationalPerson"
>> acctemp: missing attribute "sn" required by object class
>>"organizationalPerson"
>> ...........
> This looks like a common problem. I had recently made a small 'hack' to
> solve this problem.
>
> Following small fixup plugin could be used to affect how entries are
> generated. If you add it to /usr/lib/python2.7/site-packages/ipalib/plugins
> on IPA master and restart httpd service, the plugin would modify migrate-ds command so
> that 'sn' attribute would be set to a 'Migrated User Last Name' for all
> entries that miss 'sn' attribute before they actually get added into IPA
> LDAP.
>
> This is an experimental hack, of course, but it should work. Once
> migration is finished, don't forget to remove the file and restart httpd
> service again.
Worked for me, thank you. Curious, would this qualify for inclusion
in future IPA release considering its a common problem that show up
often?
>
Regards,
William
From mareynol at redhat.com Fri Sep 2 13:41:38 2016
From: mareynol at redhat.com (Mark Reynolds)
Date: Fri, 2 Sep 2016 09:41:38 -0400
Subject: [Freeipa-users] Replication scheme problem
In-Reply-To:
References:
Message-ID:
On 09/01/2016 06:13 AM, Andrey Rogovsky wrote:
> Hi!
> I have 2 servers - ldap1 is FreeIPA (master) and ldap2 is 389 DS (slave).
> One way replication ldap1 -> ldap2 is enabled but scheme is not
> replicated:
What version of 389-ds-base are you using?
rpm -qa | grep 389-ds-base
>
> Log file ldap1 have this line:
> [01/Sep/2016:07:04:53 +0000] NSMMReplicationPlugin - Warning: unable
> to replicate schema to host ldap2, port 389. Continuing with total
> update session.
Is there anything in ldap2's errors/access log from this time
(01/Sep/2016:07:04:53)?
>
> There is current status:
> filter: (objectclass=nsds5replicationagreement)
> requesting: All userApplication attributes
> # extended LDIF
> #
> # LDAPv3
> # base with scope subtree
> # filter: (objectclass=nsds5replicationagreement)
> # requesting: ALL
> #
>
> # ExampleAgreement, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
> dn:
> cn=ExampleAgreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,
> cn=config
> objectClass: top
> objectClass: nsds5replicationagreement
> cn: ExampleAgreement
> nsDS5ReplicaHost: ldap2
> nsDS5ReplicaPort: 389
> nsDS5ReplicaBindDN: cn=replication manager,cn=config
> nsDS5ReplicaBindMethod: SIMPLE
> nsDS5ReplicaRoot: dc=example,dc=com
> description: agreement between supplier1 and consumer1
> nsDS5ReplicaUpdateSchedule: 0000-0500 1
> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE
> authorityRevocationLis
> t
> nsDS5ReplicaCredentials:
> {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
> RERBNEJDUmxPVFl4TlRsbU5DMWtaV0UyTXpZeA0KTVMxaU1UYzFaREF3Wmkwek5qRmxNalkxWkFBQ
> 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQURJbjhNUWpLM1VqU1
> M1SGZEUTY0TA==}mwxKHUYWXjNeyo1AGRWe9A==
> nsds5replicareapactive: 0
> nsds5replicaLastUpdateStart: 19700101000000Z
> nsds5replicaLastUpdateEnd: 19700101000000Z
> nsds5replicaChangesSentSinceStartup:
> nsds5replicaLastUpdateStatus: 0 No replication sessions started since
> server s
> tartup
> nsds5replicaUpdateInProgress: FALSE
> nsds5replicaLastInitStart: 20160901070452Z
> nsds5replicaLastInitEnd: 20160901070455Z
> nsds5replicaLastInitStatus: 0 Total update succeeded
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
> After execute schema-reload.pl on ldap2 I
> have this lines in log:
> Failed to add task entry "cn=schema_reload_2016_9_1_10_6_17, cn=schema
> reload task, cn=tasks, cn=config" error (49)
Error 49 = invalid credentials. You entered the wrong password - this
prevented the schema reload task from taking place. You can also
restart the directory server which will do the same thing as the schema
reload task. The schema reload task is just so you can reload new
schema files without having to restart the server.
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - Error: This ((targetattr =
> "gidnumber || krbprincipalname || uidnumber")(version 3.0;acl
> "permission:System: Read system trust accounts";allow
> (compare,read,search) groupdn = "ldap:///cn=System: Read system trust
> accounts,cn=permissions,cn=pbac,dc=example,dc=com";)) ACL will not be
> considered for evaluation because of syntax errors.
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - __aclp__init_targetattr:
> targetattr "ipaanchoruuid" does not exist in schema. Please add
> attributeTypes "ipaanchoruuid" to schema if necessary.
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - ACL PARSE ERR(rv=-5):
> (targetattr = "cn
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - Error: This ((targetattr =
> "cn || createtimestamp || description || entryusn || gidnumber ||
> ipaanchoruuid || modifytimestamp || objectclass")(targetfilter =
> "(objectclass=ipaGroupOverride)")(version 3.0;acl "permission:System:
> Read Group ID Overrides";allow (compare,read,search) userdn =
> "ldap:///all";)) ACL will not be considered for evaluation because of
> syntax errors.
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - __aclp__init_targetattr:
> targetattr "ipaanchoruuid" does not exist in schema. Please add
> attributeTypes "ipaanchoruuid" to schema if necessary.
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - ACL PARSE ERR(rv=-5):
> (targetattr = "createtimestamp
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - Error: This ((targetattr =
> "createtimestamp || description || entryusn || gecos || gidnumber ||
> homedirectory || ipaanchoruuid || ipaoriginaluid || ipasshpubkey ||
> loginshell || modifytimestamp || objectclass || uid ||
> uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version
> 3.0;acl "permission:System: Read User ID Overrides";allow
> (compare,read,search) userdn = "ldap:///all";)) ACL will not be
> considered for evaluation because of syntax errors.
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - __aclp__init_targetattr:
> targetattr "a6record" does not exist in schema. Please add
> attributeTypes "a6record" to schema if necessary.
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - ACL PARSE ERR(rv=-5):
> (targetattr = "a6record
> [01/Sep/2016:07:04:59 +0000] NSACLPlugin - Error: This ((targetattr =
> "a6record || aaaarecord || afsdbrecord || aplrecord || arecord ||
> certrecord || cn || cnamerecord || dhcidrecord || dlvrecord ||
> dnamerecord || dnsclass || dnsttl || dsrecord || hinforecord ||
> hiprecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr
> || idnsallowtransfer || idnsforwarders || idnsforwardpolicy ||
> idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum ||
> idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname ||
> idnssoaserial || idnsupdatepolicy || idnszoneactive || ipseckeyrecord
> || keyrecord || kxrecord || locrecord || mdrecord || minforecord ||
> mxrecord || naptrrecord || nsecrecord || nsec3paramrecord || nsrecord
> || nxtrecord || ptrrecord || rprecord || rrsigrecord || sigrecord ||
> spfrecord || srvrecord || sshfprecord || tlsarecord || txtrecord ||
> unknownrecord ")(target =
> "ldap:///idnsname=*,cn=dns,dc=example,dc=com")(version 3.0;acl "Update
> DNS entries in a zone";allow (write) userattr =
> "parent[0,1].managedby#GROUPDN";)) ACL will not be considered for
> evaluation because of syntax errors.
>
> Looks, like ipaanchoruuid is missing. There is ldap scheme update:
> filter: (objectclass=*)
> requesting: 00core.ldif 01core389.ldif 02common.ldif 05rfc2927.ldif
> 05rfc4523.ldif 05rfc4524.ldif 06inetorgperson.ldif
> 10automember-plugin.ldif 10dna-plugin.ldif 10mep-plugin.ldif
> 10rfc2307.ldif 20subscriber.ldif 25java-object.ldif 28pilot.ldif
> 30ns-common.ldif 50ns-admin.ldif 50ns-certificate.ldif
> 50ns-directory.ldif 50ns-mail.ldif 50ns-value.ldif 50ns-web.ldif
> 60acctpolicy.ldif 60autofs.ldif 60eduperson.ldif 60mozilla.ldif
> 60nss-ldap.ldif 60pam-plugin.ldif 60posix-winsync-plugin.ldif
> 60pureftpd.ldif 60rfc2739.ldif 60rfc3712.ldif 60sabayon.ldif
> 60sudo.ldif 60trust.ldif 99user.ldif
>
> No one scheme files from ldap2 have no entry for ipaanchoruuid. But
> from ldap1 they have:
> root at ldap1 schema]# grep -i ipaanchoruuid *
> 71idviews.ldif:attributeTypes: (2.16.840.1.113730.3.8.11.62 NAME
> 'ipaAnchorUUID' DESC 'Unique Anchor Identifier' EQUALITY
> caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v4')
> 71idviews.ldif:objectClasses: (2.16.840.1.113730.3.8.12.30 NAME
> 'ipaOverrideAnchor' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) MAY (
> description ) X-ORIGIN 'IPA v4' )
> 71idviews.ldif:objectClasses: (2.16.840.1.113730.3.8.12.35 NAME
> 'ipaOverrideTarget' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) X-ORIGIN
> 'IPA v4' )
> [root at ldap1 schema]#
>
> How to resolve this issue? Just copy schemes files from ldap1 to ldap2?
That will work, but you need to restart the server for it to take effect.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mike.driscoll at oracle.com Fri Sep 2 14:15:57 2016
From: mike.driscoll at oracle.com (Mike Driscoll)
Date: Fri, 2 Sep 2016 07:15:57 -0700
Subject: [Freeipa-users] Password change rights
In-Reply-To:
References:
Message-ID: <0A9933C5-F686-40BC-94D5-725AE0A68A4C@oracle.com>
Hello. I want to script the new user creation process. I read in section 9.4 that "any user who has password change rights can change a password and no password policies are applied, but the other user must reset the password at the next login.? I want to create an account with this limited capability for inclusion in a script. But I can?t figure out how to configure an account to have this capability without being a full admin. How can I create new user accounts and set initial passwords in a script?
Mike
From abokovoy at redhat.com Fri Sep 2 14:59:23 2016
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 2 Sep 2016 17:59:23 +0300
Subject: [Freeipa-users] Password change rights
In-Reply-To: <0A9933C5-F686-40BC-94D5-725AE0A68A4C@oracle.com>
References:
<0A9933C5-F686-40BC-94D5-725AE0A68A4C@oracle.com>
Message-ID: <20160902145923.oer6wy3z5czo35ph@redhat.com>
On Fri, 02 Sep 2016, Mike Driscoll wrote:
>Hello. I want to script the new user creation process. I read in
>section 9.4 that "any user who has password change rights can change a
>password and no password policies are applied, but the other user must
>reset the password at the next login.? I want to create an account
>with this limited capability for inclusion in a script. But I can?t
>figure out how to configure an account to have this capability without
>being a full admin. How can I create new user accounts and set initial
>passwords in a script?
You need to create a permission that allows to write to password
attributes. Then create a privilege and role that utilize this
permission.
Then you would assign the user that is capable to reset passwords to
that role and it should be enough.
I recently wrote an article how to create new permissions:
https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/
You only need to look at selfservice 'Self can write own
password' and create a normal permission with similar effective
attributes:
# ipa selfservice-show 'Self can write own password'
Self-service name: Self can write own password
Permissions: write
Attributes: userpassword, krbprincipalkey, sambalmpassword, sambantpassword
Note the difference between selfservice and permission -- the former is
always executed against SELFDN of a bind identity, e.g. those who
authenticate, the latter can take care of both the target and the bind
identity.
--
/ Alexander Bokovoy
From rcritten at redhat.com Fri Sep 2 15:17:49 2016
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 2 Sep 2016 11:17:49 -0400
Subject: [Freeipa-users] Password change rights
In-Reply-To: <20160902145923.oer6wy3z5czo35ph@redhat.com>
References:
<0A9933C5-F686-40BC-94D5-725AE0A68A4C@oracle.com>
<20160902145923.oer6wy3z5czo35ph@redhat.com>
Message-ID: <57C9981D.6010502@redhat.com>
Alexander Bokovoy wrote:
> On Fri, 02 Sep 2016, Mike Driscoll wrote:
>> Hello. I want to script the new user creation process. I read in
>> section 9.4 that "any user who has password change rights can change a
>> password and no password policies are applied, but the other user must
>> reset the password at the next login.? I want to create an account
>> with this limited capability for inclusion in a script. But I can?t
>> figure out how to configure an account to have this capability without
>> being a full admin. How can I create new user accounts and set initial
>> passwords in a script?
> You need to create a permission that allows to write to password
> attributes. Then create a privilege and role that utilize this
> permission.
>
> Then you would assign the user that is capable to reset passwords to
> that role and it should be enough.
>
> I recently wrote an article how to create new permissions:
> https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/
>
> You only need to look at selfservice 'Self can write own
> password' and create a normal permission with similar effective
> attributes:
> # ipa selfservice-show 'Self can write own password'
> Self-service name: Self can write own password
> Permissions: write
> Attributes: userpassword, krbprincipalkey, sambalmpassword,
> sambantpassword
>
> Note the difference between selfservice and permission -- the former is
> always executed against SELFDN of a bind identity, e.g. those who
> authenticate, the latter can take care of both the target and the bind
> identity.
There already is such a permission, "System: Change User password"
rob
From abokovoy at redhat.com Fri Sep 2 15:55:08 2016
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 2 Sep 2016 18:55:08 +0300
Subject: [Freeipa-users] Password change rights
In-Reply-To: <57C9981D.6010502@redhat.com>
References:
<0A9933C5-F686-40BC-94D5-725AE0A68A4C@oracle.com>
<20160902145923.oer6wy3z5czo35ph@redhat.com>
<57C9981D.6010502@redhat.com>
Message-ID: <20160902155508.m6vu5iidmyxtcnwn@redhat.com>
On Fri, 02 Sep 2016, Rob Crittenden wrote:
>Alexander Bokovoy wrote:
>>On Fri, 02 Sep 2016, Mike Driscoll wrote:
>>>Hello. I want to script the new user creation process. I read in
>>>section 9.4 that "any user who has password change rights can change a
>>>password and no password policies are applied, but the other user must
>>>reset the password at the next login.? I want to create an account
>>>with this limited capability for inclusion in a script. But I can?t
>>>figure out how to configure an account to have this capability without
>>>being a full admin. How can I create new user accounts and set initial
>>>passwords in a script?
>>You need to create a permission that allows to write to password
>>attributes. Then create a privilege and role that utilize this
>>permission.
>>
>>Then you would assign the user that is capable to reset passwords to
>>that role and it should be enough.
>>
>>I recently wrote an article how to create new permissions:
>>https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/
>>
>>You only need to look at selfservice 'Self can write own
>>password' and create a normal permission with similar effective
>>attributes:
>># ipa selfservice-show 'Self can write own password'
>> Self-service name: Self can write own password
>> Permissions: write
>> Attributes: userpassword, krbprincipalkey, sambalmpassword,
>>sambantpassword
>>
>>Note the difference between selfservice and permission -- the former is
>>always executed against SELFDN of a bind identity, e.g. those who
>>authenticate, the latter can take care of both the target and the bind
>>identity.
>
>There already is such a permission, "System: Change User password"
Thank you, Rob. My bad: we have so many permissions now that default
size limit kicks in and I don't see it:
# ipa permission-find --sizelimit=0 |grep -i 'permission name:'|wc -l
237
# ipa permission-find --sizelimit=0 |grep -i 'permission name:'|grep -i 'change user password'
Permission name: System: Change User password
--
/ Alexander Bokovoy
From deepak_dimri at hotmail.com Fri Sep 2 18:06:52 2016
From: deepak_dimri at hotmail.com (Deepak Dimri)
Date: Fri, 2 Sep 2016 14:06:52 -0400
Subject: [Freeipa-users] General query regarding nameserver enrtry
Message-ID:
Hi All,
My ipa-client-install fails until etc/resolve.conf gets updated with IPA nameserver entry. I want to avoid a task of updating resolve.conf in my automation script. Is there a way i can get my IPA client installation successful without updating resolve.conf? what options do i have?
Many Thanks,Deepak
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coy.hile at coyhile.com Fri Sep 2 18:56:42 2016
From: coy.hile at coyhile.com (Coy Hile)
Date: Fri, 2 Sep 2016 14:56:42 -0400
Subject: [Freeipa-users] Question about ID views
Message-ID: <006C1C38-0365-425D-8DEF-1AE5A6EB3001@coyhile.com>
In looking at the ID Views functionality in FreeIPA, it looks like I can accomplish overrides (such as users? shell in LDAP is /bin/bash, but on a certain subset of hosts, users get /some/restrictive/shell instead? (Use case #1: a bastion host or jump box where admins might want to validate that users are only attempting to access authorized internal destinations.)
However, it looks like one has to list each user individually?
Is it possible to do things like this?
*:::::/usr/bin/restricted_shell override EVERY user en masse
some_ldap_group:::newGid::: ? Override *EVERYONE* in some_ldap_group en masse
ldap_group_2:::newGid::/somepath/home/%s:/usr/bin/restricted_shell
? Override members of ldap_group_2 overriding each individual user?s home directory as well from, e.g. , /home/jdoe -> /somepath/home/jdoe
--
Coy Hile
coy.hile at coyhile.com
From orion at cora.nwra.com Fri Sep 2 19:12:16 2016
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 2 Sep 2016 13:12:16 -0600
Subject: [Freeipa-users] Default gid for AD trust users
In-Reply-To:
References:
Message-ID: <656bfc4e-b802-f2ac-8d7e-db0d156db137@cora.nwra.com>
FWIW - I've filed https://fedorahosted.org/freeipa/ticket/6293 to request the
ability to set the primary group for AD trust users.
On 08/24/2016 11:42 AM, Orion Poplawski wrote:
> While that is definitely *a* convention, it's not the one we've used which
> puts users by default in shared groups (nwra, visitors, etc). For example:
>
> uid=2941(user) gid=1991(nwra)
>
> We may be fine changing conventions, but I'm researching whether or not we
> have to.
>
> Thanks.
>
> On 08/24/2016 11:19 AM, Justin Stephenson wrote:
>> Could you please explain further what you are trying to accomplish with an AD
>> trust default group? I believe we are following the standard linux convention
>> of creating a user private group using the ID number which matches the uid
>> number for AD trust users.
>>
>> Kind regards,
>>
>> Justin Stephenson
>>
>>
>> On 08/23/2016 06:27 PM, Orion Poplawski wrote:
>>> Is there any way to control the default gid for AD trust users? At the moment
>>> each user has it's own default group, e.g.:
>>>
>>> uid=22603(user at ad.domain) gid=22603(user at ad.domain)
>>>
>>> It would be nice to be able to set this to an actual group.
>>>
>>> Thanks.
>>>
>>
>
>
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion at nwra.com
Boulder, CO 80301 http://www.nwra.com
From tjyang2001 at gmail.com Fri Sep 2 20:28:12 2016
From: tjyang2001 at gmail.com (T.J. Yang)
Date: Fri, 2 Sep 2016 15:28:12 -0500
Subject: [Freeipa-users] freeip-4.4.1 on CentOS 7.x ?
Message-ID:
Hi
I was able to try out freeipa-4.4.1 on fedora 24 server by quick dnf enable
at
https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-4/
But for production, I am hoping to run 4.4.1 on CentOS 7
Where is the doc explaining on this howto for CentOS 7 ?
tj
--
T.J. Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rcritten at redhat.com Fri Sep 2 20:34:01 2016
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 2 Sep 2016 16:34:01 -0400
Subject: [Freeipa-users] freeip-4.4.1 on CentOS 7.x ?
In-Reply-To:
References:
Message-ID: <57C9E239.90908@redhat.com>
T.J. Yang wrote:
> Hi
>
> I was able to try out freeipa-4.4.1 on fedora 24 server by quick dnf
> enable at
>
> https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-4/
>
> But for production, I am hoping to run 4.4.1 on CentOS 7
>
> Where is the doc explaining on this howto for CentOS 7 ?
It hasn't been released for RHEL/CentOS 7 yet. There is a beta though AFAIU.
rob
From lslebodn at redhat.com Fri Sep 2 21:15:37 2016
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Fri, 2 Sep 2016 23:15:37 +0200
Subject: [Freeipa-users] Default gid for AD trust users
In-Reply-To:
References:
Message-ID: <20160902211536.GA29320@10.4.128.1>
On (24/08/16 11:42), Orion Poplawski wrote:
>While that is definitely *a* convention, it's not the one we've used which
>puts users by default in shared groups (nwra, visitors, etc). For example:
>
>uid=2941(user) gid=1991(nwra)
>
The user "user" should be a member "nwra" group.
If no then you have other issues.
Why does it matter whether it is a primary group or no?
LS
From rakesh.rajasekharan at gmail.com Sun Sep 4 12:04:26 2016
From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan)
Date: Sun, 4 Sep 2016 17:34:26 +0530
Subject: [Freeipa-users] Freeipa 4.2.0 hangs intermittently
In-Reply-To:
References:
<7850c6f9-f79a-355e-4730-93bb67fbacf1@redhat.com>
<57BEB0AB.2090506@redhat.com>
<57C44AC6.1030402@redhat.com>
Message-ID:
I have again got the issue of IPA hanging.. The issue came up when i tried
to run ipa-client-isntall on 142 clients simultaneously
None of the IPA commands are responding, and I see this error
ipa user-find p-testipa
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (KDC
returned error string: PROCESS_TGS)
KRB5_TRACE=/dev/stdout kinit admin
[41178] 1472984115.233214: Getting initial credentials for admin at XYZ.COM
[41178] 1472984115.235257: Sending request (167 bytes) to XYZ.COM
[41178] 1472984115.235419: Initiating TCP connection to stream 10.1.3.36:88
[41178] 1472984115.235685: Sending TCP request to stream 10.1.3.36:88
[41178] 1472984120.238914: Received answer (174 bytes) from stream
10.1.3.36:88
[41178] 1472984120.238925: Terminating TCP connection to stream 10.1.3.36:88
[41178] 1472984120.238993: Response was from master KDC
[41
Running an ldapsearch to see the db.. does not give any results and just
hangs there
ldapsearch -x -D 'cn=Directory Manager' -W -s one -b
'cn=kerberos,dc=xyz,dc=com'
Enter LDAP Password:
even an ldapsearch -x does not respond
At this point, am sure that slapd is the one causing issues
Running an strace against the hung slapd itself seems to get stuck does not
proceed after saying "attaching to process"
>From some others posts I read Thierry suggesting to increase the
nsslapd-threadnumber value
It was set to 30, I think that might be too low.
I have raised it to 500
Now after restarting the service .. ldapsearch starts responding.
But running the test to add a sudden high number of clients again left
ns-slapd to hung state
When i attempted adding the clients.. the ns-slapd cpu usage shot up to
340% and after that ns-slapd stopped responding
So now, atleast I know what might be causing the issue and I can now easily
reproduce it.
Is there a way I can make ns-slapd handle a sudden bump in incoming request
for ipa-client-install
Thanks
Rakesh
On Mon, Aug 29, 2016 at 11:18 PM, Rich Megginson
wrote:
> On 08/29/2016 10:53 AM, Rakesh Rajasekharan wrote:
>
> Hi Thierry,
>
> My machine has 30GB RAM ..and 389-ds version is 1.3.4
>
> ldapsearch shows the values for nsslapd-cachememsize updated to 200MB.
>
> ldapsearch -LLL -o ldif-wrap=no -D "cn=directory manager" -w 'mypassword'
> -b 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config'|grep
> nsslapd-cachememsize
> nsslapd-cachememsize: 209715200
>
>
> So, it seems to have updated though seeing that warning(WARNING: ipaca:
> entry cache size 10485760B is less than db size 11599872B) in the log
> confuses me a bit.
>
> Thers one more entry that I found from the ldapsearch to be bit low
>
> nsslapd-dncachememsize: 10485760
> maxdncachesize: 10485760
>
> Should I update these as well to a higher value
>
> At the time when the issue happened, the memory usage as well as the
> overall load of the system was very low .
> I will try reproducing the issue atleast in my QA env..probably by trying
> to mock simultaneous parallel logins to a large number of hosts
>
>
> To monitor your cache sizes, please use the dbmon.sh tool provided with
> your distro. If that is not available with your particular distro, see
> https://github.com/richm/scripts/wiki/dbmon.sh
>
>
>
>
> thanks
> Rakesh
>
>
>
>
> On Mon, Aug 29, 2016 at 8:16 PM, thierry bordaz
> wrote:
>
>> Hi Rakesh,
>>
>> Those tuning may depend on the memory available on your machine.
>> nsslapd-cachememsize allows the entry cache to consume up to 200Mb but
>> its memory footprint is known to go above.
>> 200Mb both looks pretty good to me. How large is your machine ? What is
>> your version of 389-ds ?
>>
>> Those warnings do not change your settings. It just raise that entry
>> cache of 'ipaca' and 'retrocl' are small but it is fine. The size of the
>> entry cache is important mostly in userRoot.
>> You may double check the actual values, after restart, with ldapsearch on
>> 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' and 'cn=config,cn=ldbm
>> database,cn=plugins,cn=config'.
>>
>> A step is to know what will be response time of DS to know if it is
>> responsible of the hang or not.
>> The logs and possibly pstack during those intermittent hangs will help to
>> determine that.
>>
>> regards
>> thierry
>>
>>
>>
>>
>>
>> On 08/29/2016 04:25 PM, Rakesh Rajasekharan wrote:
>>
>> I tried increasing the nsslapd-dbcachesize and nsslapd-cachememsize in my
>> QA envs to 200MB.
>>
>> However, in my log files, I still see this message
>> [29/Aug/2016:04:34:37 +0000] - WARNING: ipaca: entry cache size 10485760B
>> is less than db size 11599872B; We recommend to increase the entry cache
>> size nsslapd-cachememsize.
>> [29/Aug/2016:04:34:37 +0000] - WARNING: changelog: entry cache size
>> 2097152B is less than db size 441647104B; We recommend to increase the
>> entry cache size nsslapd-cachememsize.
>>
>> these are my ldif files that i used to modify the values
>> modify entry cache size
>> cat modify-cache-mem-size.ldif
>> dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>> changetype: modify
>> replace: nsslapd-cachememsize
>> nsslapd-cachememsize: 209715200
>>
>> modify db cache size
>> cat modfy-db-cache-size.ldif
>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>> changetype: modify
>> replace: nsslapd-dbcachesize
>> nsslapd-dbcachesize: 209715200
>>
>> After modifying , i restarted IPA services
>>
>> Is there anything else that I need to take care of as the logs suggest
>> its still not getting the updated values
>>
>> Thanks
>> Rakesh
>>
>> On Mon, Aug 29, 2016 at 6:07 PM, Rakesh Rajasekharan <
>> rakesh.rajasekharan at gmail.com> wrote:
>>
>>> Hi Thierry,
>>>
>>> Coz of the issues we had to revert back to earlier running openldap in
>>> production.
>>>
>>> I have now done a few TCP related changes in sysctl.conf and have also
>>> increased the nsslapd-dbcachesize and nsslapd-cachememsize to 200MB
>>>
>>> I will again start migrating hosts back to IPA and see if I face the
>>> earlier issue.
>>>
>>> I will update back once I have something
>>>
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>>
>>> On Thu, Aug 25, 2016 at 2:17 PM, thierry bordaz
>>> wrote:
>>>
>>>>
>>>>
>>>> On 08/25/2016 10:15 AM, Rakesh Rajasekharan wrote:
>>>>
>>>> All of the troubleshooting seems fine.
>>>>
>>>>
>>>> However, Running libconv.pl gives me this output
>>>>
>>>> ----- Recommendations -----
>>>>
>>>> 1. You have unindexed components, this can be caused from a search on
>>>> an unindexed attribute, or your returned results exceeded the
>>>> allidsthreshold. Unindexed components are not recommended. To refuse
>>>> unindexed searches, switch 'nsslapd-require-index' to 'on' under your
>>>> database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config)
>>>> .
>>>>
>>>> 2. You have a significant difference between binds and unbinds. You
>>>> may want to investigate this difference.
>>>>
>>>>
>>>> I feel, this could be a pointer to things going slow.. and IPA hanging.
>>>> I think i now have something that I can try and nail down this issue.
>>>>
>>>> On a sidenote, I was earlier running openldap and migrated over to
>>>> Freeipa,
>>>>
>>>> Thanks
>>>> Rakesh
>>>>
>>>>
>>>>
>>>> On Wed, Aug 24, 2016 at 12:38 PM, Petr Spacek
>>>> wrote:
>>>>
>>>>> On 23.8.2016 18:44, Rakesh Rajasekharan wrote:
>>>>> > I think thers something seriously wrong with my system
>>>>> >
>>>>> > not able to run any IPA commands
>>>>> >
>>>>> > klist
>>>>> > Ticket cache: KEYRING:persistent:0:0
>>>>> > Default principal: admin at XYZ.COM
>>>>> >
>>>>> > Valid starting Expires Service principal
>>>>> > 2016-08-23T16:26:36 2016-08-24T16:26:22 krbtgt/XYZ.COM at XYZ.COM
>>>>> >
>>>>> >
>>>>> > [root at prod-ipa-master-1a :~] ipactl status
>>>>> > Directory Service: RUNNING
>>>>> > krb5kdc Service: RUNNING
>>>>> > kadmin Service: RUNNING
>>>>> > ipa_memcached Service: RUNNING
>>>>> > httpd Service: RUNNING
>>>>> > pki-tomcatd Service: RUNNING
>>>>> > ipa-otpd Service: RUNNING
>>>>> > ipa: INFO: The ipactl command was successful
>>>>> >
>>>>> >
>>>>> >
>>>>> > [root at prod-ipa-master :~] ipa user-find p-testuser
>>>>> > ipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code
>>>>> may
>>>>> > provide more information', 851968)/("Cannot contact any KDC for
>>>>> realm '
>>>>> > XYZ.COM'", -1765328228)
>>>>>
>>>>
>>>> Hi Rakesh,
>>>>
>>>> Having a reproducible test case would you rerun the command above.
>>>> During its processing you may monitor DS process load (top). If it is
>>>> high, you may get some pstacks of it.
>>>> Also would you attach the part of DS access logs taken during the
>>>> command.
>>>>
>>>> regards
>>>> thierry
>>>>
>>>> >
>>>>>
>>>>> This is weird because the server seems to be up.
>>>>>
>>>>> Please follow
>>>>> http://www.freeipa.org/page/Troubleshooting#Authentication.2FKerberos
>>>>>
>>>>> Petr^2 Spacek
>>>>>
>>>>> >
>>>>> >
>>>>> > Thanks
>>>>> >
>>>>> > Rakesh
>>>>> >
>>>>> > On Tue, Aug 23, 2016 at 10:01 PM, Rakesh Rajasekharan <
>>>>> > rakesh.rajasekharan at gmail.com> wrote:
>>>>> >
>>>>> >> i changed the loggin level to 4 . Modifying nsslapd-accesslog-level
>>>>> >>
>>>>> >> But, the hang is still there. though I dont see the sigfault now
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Tue, Aug 23, 2016 at 9:02 PM, Rakesh Rajasekharan <
>>>>> >> rakesh.rajasekharan at gmail.com> wrote:
>>>>> >>
>>>>> >>> My disk was getting filled too fast
>>>>> >>>
>>>>> >>> logs under /var/log/dirsrv was coming around 5 gb quickly filling
>>>>> up
>>>>> >>>
>>>>> >>> Is there a way to make the logging less verbose
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> On Tue, Aug 23, 2016 at 6:41 PM, Petr Spacek
>>>>> wrote:
>>>>> >>>
>>>>> >>>> On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
>>>>> >>>>> I was able to fix that may be temporarily... when i checked the
>>>>> >>>> network..
>>>>> >>>>> there was another process that was running and consuming a lot of
>>>>> >>>> network (
>>>>> >>>>> i have no idea who did that. I need to seriously start
>>>>> restricting
>>>>> >>>> people
>>>>> >>>>> access to this machine )
>>>>> >>>>>
>>>>> >>>>> after killing that perfomance improved drastically
>>>>> >>>>>
>>>>> >>>>> But now, suddenly I started experiencing the same hang.
>>>>> >>>>>
>>>>> >>>>> This time , I gert the following error when checked dmesg
>>>>> >>>>>
>>>>> >>>>> [ 301.236976] ns-slapd[3124]: segfault at 0 ip 00007f1de416951c
>>>>> sp
>>>>> >>>>> 00007f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
>>>>> >>>>> [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on
>>>>> port 88.
>>>>> >>>>> Sending cookies. Check SNMP counters.
>>>>> >>>>> [11831.397037] ns-slapd[22550]: segfault at 0 ip
>>>>> 00007f533d82251c sp
>>>>> >>>>> 00007f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
>>>>> >>>>> [11832.727989] ns-slapd[22606]: segfault at 0 ip
>>>>> 00007f6231eb951c sp
>>>>> >>>>> 00007f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00
>>>>> >>>>
>>>>> >>>> Okay, this one is serious. The LDAP server crashed.
>>>>> >>>>
>>>>> >>>> 1. Make sure all your packages are up-to-date.
>>>>> >>>>
>>>>> >>>> Please see
>>>>> >>>> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#d
>>>>> >>>> ebugging-crashes
>>>>> >>>> for further instructions how to debug this.
>>>>> >>>>
>>>>> >>>> Petr^2 Spacek
>>>>> >>>>
>>>>> >>>>>
>>>>> >>>>> and in /var/log/dirsrv/example-com/errors
>>>>> >>>>>
>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>> delete_changerecord:
>>>>> >>>> could
>>>>> >>>>> not delete change record 3291138 (rc: 32)
>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>> delete_changerecord:
>>>>> >>>> could
>>>>> >>>>> not delete change record 3291139 (rc: 32)
>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>> delete_changerecord:
>>>>> >>>> could
>>>>> >>>>> not delete change record 3291140 (rc: 32)
>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>> delete_changerecord:
>>>>> >>>> could
>>>>> >>>>> not delete change record 3291141 (rc: 32)
>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>> delete_changerecord:
>>>>> >>>> could
>>>>> >>>>> not delete change record 3291142 (rc: 32)
>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>> delete_changerecord:
>>>>> >>>> could
>>>>> >>>>> not delete change record 3291143 (rc: 32)
>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>> delete_changerecord:
>>>>> >>>> could
>>>>> >>>>> not delete change record 3291144 (rc: 32)
>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>> delete_changerecord:
>>>>> >>>> could
>>>>> >>>>> not delete change record 3291145 (rc: 32)
>>>>> >>>>> [23/Aug/2016:12:49:50 +0000] - Retry count exceeded in delete
>>>>> >>>>> [23/Aug/2016:12:49:50 +0000] DSRetroclPlugin -
>>>>> delete_changerecord:
>>>>> >>>> could
>>>>> >>>>> not delete change record 3292734 (rc: 51)
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> Can i do something about this error.. I treid to restart ipa a
>>>>> couple
>>>>> >>>> of
>>>>> >>>>> time but that did not help
>>>>> >>>>>
>>>>> >>>>> Thanks
>>>>> >>>>> Rakesh
>>>>> >>>>>
>>>>> >>>>> On Mon, Aug 22, 2016 at 2:27 PM, Petr Spacek >>>> >
>>>>> >>>> wrote:
>>>>> >>>>>
>>>>> >>>>>> On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
>>>>> >>>>>>> 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
>>>>> >>>>>>
>>>>> >>>>>> Possibly, I'm not sure. If you want to dig into this, I would
>>>>> do this:
>>>>> >>>>>> 1. look what process hangs on client (using pstree command or
>>>>> so)
>>>>> >>>>>> $ pstree
>>>>> >>>>>>
>>>>> >>>>>> 2. look to what server and port is the hanging client connected
>>>>> to
>>>>> >>>>>> $ lsof -p
>>>>> >>>>>>
>>>>> >>>>>> 3. jump to server and see what process is bound to the target
>>>>> port
>>>>> >>>>>> $ netstat -pn
>>>>> >>>>>>
>>>>> >>>>>> 4. see where the process if hanging
>>>>> >>>>>> $ strace -p
>>>>> >>>>>>
>>>>> >>>>>> I hope it helps.
>>>>> >>>>>>
>>>>> >>>>>> Petr^2 Spacek
>>>>> >>>>>>
>>>>> >>>>>>> On Fri, Aug 19, 2016 at 7:24 PM, Rakesh Rajasekharan <
>>>>> >>>>>>> rakesh.rajasekharan at 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 <
>>>>> pspacek at redhat.com>
>>>>> >>>>>> 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.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rakesh.rajasekharan at gmail.com Sun Sep 4 18:40:43 2016
From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan)
Date: Mon, 5 Sep 2016 00:10:43 +0530
Subject: [Freeipa-users] Freeipa 4.2.0 hangs intermittently
In-Reply-To:
References:
<7850c6f9-f79a-355e-4730-93bb67fbacf1@redhat.com>
<57BEB0AB.2090506@redhat.com>
<57C44AC6.1030402@redhat.com>
Message-ID:
starce on the slapd process actually had this in the output..
FUTEX_WAIT_PRIVATE
and checking for the number of threads slapd had.. there were 5015 threads
ps -efL|grep slapd|wc -l
5015
strace on most of the threads gave this output
strace -p 67411
Process 67411 attached
futex(0x7f3f0226b41c, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0x7f3f0226b41c, FUTEX_WAIT_PRIVATE, 2, NULL^CProcess 67411 detached
On Sun, Sep 4, 2016 at 5:34 PM, Rakesh Rajasekharan <
rakesh.rajasekharan at gmail.com> wrote:
> I have again got the issue of IPA hanging.. The issue came up when i tried
> to run ipa-client-isntall on 142 clients simultaneously
>
>
> None of the IPA commands are responding, and I see this error
>
> ipa user-find p-testipa
> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure. Minor code may provide more information (KDC
> returned error string: PROCESS_TGS)
>
> KRB5_TRACE=/dev/stdout kinit admin
> [41178] 1472984115.233214: Getting initial credentials for admin at XYZ.COM
> [41178] 1472984115.235257: Sending request (167 bytes) to XYZ.COM
> [41178] 1472984115.235419: Initiating TCP connection to stream
> 10.1.3.36:88
> [41178] 1472984115.235685: Sending TCP request to stream 10.1.3.36:88
> [41178] 1472984120.238914: Received answer (174 bytes) from stream
> 10.1.3.36:88
> [41178] 1472984120.238925: Terminating TCP connection to stream
> 10.1.3.36:88
> [41178] 1472984120.238993: Response was from master KDC
> [41
>
>
> Running an ldapsearch to see the db.. does not give any results and just
> hangs there
>
> ldapsearch -x -D 'cn=Directory Manager' -W -s one -b
> 'cn=kerberos,dc=xyz,dc=com'
> Enter LDAP Password:
>
> even an ldapsearch -x does not respond
> At this point, am sure that slapd is the one causing issues
>
> Running an strace against the hung slapd itself seems to get stuck does
> not proceed after saying "attaching to process"
>
> From some others posts I read Thierry suggesting to increase the
> nsslapd-threadnumber value
>
> It was set to 30, I think that might be too low.
>
> I have raised it to 500
>
> Now after restarting the service .. ldapsearch starts responding.
> But running the test to add a sudden high number of clients again left
> ns-slapd to hung state
>
> When i attempted adding the clients.. the ns-slapd cpu usage shot up to
> 340% and after that ns-slapd stopped responding
>
> So now, atleast I know what might be causing the issue and I can now
> easily reproduce it.
>
> Is there a way I can make ns-slapd handle a sudden bump in incoming
> request for ipa-client-install
>
> Thanks
> Rakesh
>
>
>
>
>
>
> On Mon, Aug 29, 2016 at 11:18 PM, Rich Megginson
> wrote:
>
>> On 08/29/2016 10:53 AM, Rakesh Rajasekharan wrote:
>>
>> Hi Thierry,
>>
>> My machine has 30GB RAM ..and 389-ds version is 1.3.4
>>
>> ldapsearch shows the values for nsslapd-cachememsize updated to 200MB.
>>
>> ldapsearch -LLL -o ldif-wrap=no -D "cn=directory manager" -w 'mypassword'
>> -b 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config'|grep
>> nsslapd-cachememsize
>> nsslapd-cachememsize: 209715200
>>
>>
>> So, it seems to have updated though seeing that warning(WARNING: ipaca:
>> entry cache size 10485760B is less than db size 11599872B) in the log
>> confuses me a bit.
>>
>> Thers one more entry that I found from the ldapsearch to be bit low
>>
>> nsslapd-dncachememsize: 10485760
>> maxdncachesize: 10485760
>>
>> Should I update these as well to a higher value
>>
>> At the time when the issue happened, the memory usage as well as the
>> overall load of the system was very low .
>> I will try reproducing the issue atleast in my QA env..probably by trying
>> to mock simultaneous parallel logins to a large number of hosts
>>
>>
>> To monitor your cache sizes, please use the dbmon.sh tool provided with
>> your distro. If that is not available with your particular distro, see
>> https://github.com/richm/scripts/wiki/dbmon.sh
>>
>>
>>
>>
>> thanks
>> Rakesh
>>
>>
>>
>>
>> On Mon, Aug 29, 2016 at 8:16 PM, thierry bordaz
>> wrote:
>>
>>> Hi Rakesh,
>>>
>>> Those tuning may depend on the memory available on your machine.
>>> nsslapd-cachememsize allows the entry cache to consume up to 200Mb but
>>> its memory footprint is known to go above.
>>> 200Mb both looks pretty good to me. How large is your machine ? What is
>>> your version of 389-ds ?
>>>
>>> Those warnings do not change your settings. It just raise that entry
>>> cache of 'ipaca' and 'retrocl' are small but it is fine. The size of the
>>> entry cache is important mostly in userRoot.
>>> You may double check the actual values, after restart, with ldapsearch
>>> on 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config' and
>>> 'cn=config,cn=ldbm database,cn=plugins,cn=config'.
>>>
>>> A step is to know what will be response time of DS to know if it is
>>> responsible of the hang or not.
>>> The logs and possibly pstack during those intermittent hangs will help
>>> to determine that.
>>>
>>> regards
>>> thierry
>>>
>>>
>>>
>>>
>>>
>>> On 08/29/2016 04:25 PM, Rakesh Rajasekharan wrote:
>>>
>>> I tried increasing the nsslapd-dbcachesize and nsslapd-cachememsize in
>>> my QA envs to 200MB.
>>>
>>> However, in my log files, I still see this message
>>> [29/Aug/2016:04:34:37 +0000] - WARNING: ipaca: entry cache size
>>> 10485760B is less than db size 11599872B; We recommend to increase the
>>> entry cache size nsslapd-cachememsize.
>>> [29/Aug/2016:04:34:37 +0000] - WARNING: changelog: entry cache size
>>> 2097152B is less than db size 441647104B; We recommend to increase the
>>> entry cache size nsslapd-cachememsize.
>>>
>>> these are my ldif files that i used to modify the values
>>> modify entry cache size
>>> cat modify-cache-mem-size.ldif
>>> dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>>> changetype: modify
>>> replace: nsslapd-cachememsize
>>> nsslapd-cachememsize: 209715200
>>>
>>> modify db cache size
>>> cat modfy-db-cache-size.ldif
>>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>>> changetype: modify
>>> replace: nsslapd-dbcachesize
>>> nsslapd-dbcachesize: 209715200
>>>
>>> After modifying , i restarted IPA services
>>>
>>> Is there anything else that I need to take care of as the logs suggest
>>> its still not getting the updated values
>>>
>>> Thanks
>>> Rakesh
>>>
>>> On Mon, Aug 29, 2016 at 6:07 PM, Rakesh Rajasekharan <
>>> rakesh.rajasekharan at gmail.com> wrote:
>>>
>>>> Hi Thierry,
>>>>
>>>> Coz of the issues we had to revert back to earlier running openldap in
>>>> production.
>>>>
>>>> I have now done a few TCP related changes in sysctl.conf and have also
>>>> increased the nsslapd-dbcachesize and nsslapd-cachememsize to 200MB
>>>>
>>>> I will again start migrating hosts back to IPA and see if I face the
>>>> earlier issue.
>>>>
>>>> I will update back once I have something
>>>>
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>>
>>>> On Thu, Aug 25, 2016 at 2:17 PM, thierry bordaz
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 08/25/2016 10:15 AM, Rakesh Rajasekharan wrote:
>>>>>
>>>>> All of the troubleshooting seems fine.
>>>>>
>>>>>
>>>>> However, Running libconv.pl gives me this output
>>>>>
>>>>> ----- Recommendations -----
>>>>>
>>>>> 1. You have unindexed components, this can be caused from a search
>>>>> on an unindexed attribute, or your returned results exceeded the
>>>>> allidsthreshold. Unindexed components are not recommended. To refuse
>>>>> unindexed searches, switch 'nsslapd-require-index' to 'on' under your
>>>>> database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config)
>>>>> .
>>>>>
>>>>> 2. You have a significant difference between binds and unbinds. You
>>>>> may want to investigate this difference.
>>>>>
>>>>>
>>>>> I feel, this could be a pointer to things going slow.. and IPA
>>>>> hanging. I think i now have something that I can try and nail down this
>>>>> issue.
>>>>>
>>>>> On a sidenote, I was earlier running openldap and migrated over to
>>>>> Freeipa,
>>>>>
>>>>> Thanks
>>>>> Rakesh
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 24, 2016 at 12:38 PM, Petr Spacek
>>>>> wrote:
>>>>>
>>>>>> On 23.8.2016 18:44, Rakesh Rajasekharan wrote:
>>>>>> > I think thers something seriously wrong with my system
>>>>>> >
>>>>>> > not able to run any IPA commands
>>>>>> >
>>>>>> > klist
>>>>>> > Ticket cache: KEYRING:persistent:0:0
>>>>>> > Default principal: admin at XYZ.COM
>>>>>> >
>>>>>> > Valid starting Expires Service principal
>>>>>> > 2016-08-23T16:26:36 2016-08-24T16:26:22 krbtgt/XYZ.COM at XYZ.COM
>>>>>> >
>>>>>> >
>>>>>> > [root at prod-ipa-master-1a :~] ipactl status
>>>>>> > Directory Service: RUNNING
>>>>>> > krb5kdc Service: RUNNING
>>>>>> > kadmin Service: RUNNING
>>>>>> > ipa_memcached Service: RUNNING
>>>>>> > httpd Service: RUNNING
>>>>>> > pki-tomcatd Service: RUNNING
>>>>>> > ipa-otpd Service: RUNNING
>>>>>> > ipa: INFO: The ipactl command was successful
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > [root at prod-ipa-master :~] ipa user-find p-testuser
>>>>>> > ipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code
>>>>>> may
>>>>>> > provide more information', 851968)/("Cannot contact any KDC for
>>>>>> realm '
>>>>>> > XYZ.COM'", -1765328228)
>>>>>>
>>>>>
>>>>> Hi Rakesh,
>>>>>
>>>>> Having a reproducible test case would you rerun the command above.
>>>>> During its processing you may monitor DS process load (top). If it is
>>>>> high, you may get some pstacks of it.
>>>>> Also would you attach the part of DS access logs taken during the
>>>>> command.
>>>>>
>>>>> regards
>>>>> thierry
>>>>>
>>>>> >
>>>>>>
>>>>>> This is weird because the server seems to be up.
>>>>>>
>>>>>> Please follow
>>>>>> http://www.freeipa.org/page/Troubleshooting#Authentication.2FKerberos
>>>>>>
>>>>>> Petr^2 Spacek
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> > Thanks
>>>>>> >
>>>>>> > Rakesh
>>>>>> >
>>>>>> > On Tue, Aug 23, 2016 at 10:01 PM, Rakesh Rajasekharan <
>>>>>> > rakesh.rajasekharan at gmail.com> wrote:
>>>>>> >
>>>>>> >> i changed the loggin level to 4 . Modifying nsslapd-accesslog-level
>>>>>> >>
>>>>>> >> But, the hang is still there. though I dont see the sigfault now
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Tue, Aug 23, 2016 at 9:02 PM, Rakesh Rajasekharan <
>>>>>> >> rakesh.rajasekharan at gmail.com> wrote:
>>>>>> >>
>>>>>> >>> My disk was getting filled too fast
>>>>>> >>>
>>>>>> >>> logs under /var/log/dirsrv was coming around 5 gb quickly filling
>>>>>> up
>>>>>> >>>
>>>>>> >>> Is there a way to make the logging less verbose
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> On Tue, Aug 23, 2016 at 6:41 PM, Petr Spacek
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>>> On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
>>>>>> >>>>> I was able to fix that may be temporarily... when i checked the
>>>>>> >>>> network..
>>>>>> >>>>> there was another process that was running and consuming a lot
>>>>>> of
>>>>>> >>>> network (
>>>>>> >>>>> i have no idea who did that. I need to seriously start
>>>>>> restricting
>>>>>> >>>> people
>>>>>> >>>>> access to this machine )
>>>>>> >>>>>
>>>>>> >>>>> after killing that perfomance improved drastically
>>>>>> >>>>>
>>>>>> >>>>> But now, suddenly I started experiencing the same hang.
>>>>>> >>>>>
>>>>>> >>>>> This time , I gert the following error when checked dmesg
>>>>>> >>>>>
>>>>>> >>>>> [ 301.236976] ns-slapd[3124]: segfault at 0 ip
>>>>>> 00007f1de416951c sp
>>>>>> >>>>> 00007f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
>>>>>> >>>>> [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on
>>>>>> port 88.
>>>>>> >>>>> Sending cookies. Check SNMP counters.
>>>>>> >>>>> [11831.397037] ns-slapd[22550]: segfault at 0 ip
>>>>>> 00007f533d82251c sp
>>>>>> >>>>> 00007f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
>>>>>> >>>>> [11832.727989] ns-slapd[22606]: segfault at 0 ip
>>>>>> 00007f6231eb951c sp
>>>>>> >>>>> 00007f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00
>>>>>> >>>>
>>>>>> >>>> Okay, this one is serious. The LDAP server crashed.
>>>>>> >>>>
>>>>>> >>>> 1. Make sure all your packages are up-to-date.
>>>>>> >>>>
>>>>>> >>>> Please see
>>>>>> >>>> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#d
>>>>>> >>>> ebugging-crashes
>>>>>> >>>> for further instructions how to debug this.
>>>>>> >>>>
>>>>>> >>>> Petr^2 Spacek
>>>>>> >>>>
>>>>>> >>>>>
>>>>>> >>>>> and in /var/log/dirsrv/example-com/errors
>>>>>> >>>>>
>>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>>> delete_changerecord:
>>>>>> >>>> could
>>>>>> >>>>> not delete change record 3291138 (rc: 32)
>>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>>> delete_changerecord:
>>>>>> >>>> could
>>>>>> >>>>> not delete change record 3291139 (rc: 32)
>>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>>> delete_changerecord:
>>>>>> >>>> could
>>>>>> >>>>> not delete change record 3291140 (rc: 32)
>>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>>> delete_changerecord:
>>>>>> >>>> could
>>>>>> >>>>> not delete change record 3291141 (rc: 32)
>>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>>> delete_changerecord:
>>>>>> >>>> could
>>>>>> >>>>> not delete change record 3291142 (rc: 32)
>>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>>> delete_changerecord:
>>>>>> >>>> could
>>>>>> >>>>> not delete change record 3291143 (rc: 32)
>>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>>> delete_changerecord:
>>>>>> >>>> could
>>>>>> >>>>> not delete change record 3291144 (rc: 32)
>>>>>> >>>>> [23/Aug/2016:12:49:36 +0000] DSRetroclPlugin -
>>>>>> delete_changerecord:
>>>>>> >>>> could
>>>>>> >>>>> not delete change record 3291145 (rc: 32)
>>>>>> >>>>> [23/Aug/2016:12:49:50 +0000] - Retry count exceeded in delete
>>>>>> >>>>> [23/Aug/2016:12:49:50 +0000] DSRetroclPlugin -
>>>>>> delete_changerecord:
>>>>>> >>>> could
>>>>>> >>>>> not delete change record 3292734 (rc: 51)
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> Can i do something about this error.. I treid to restart ipa a
>>>>>> couple
>>>>>> >>>> of
>>>>>> >>>>> time but that did not help
>>>>>> >>>>>
>>>>>> >>>>> Thanks
>>>>>> >>>>> Rakesh
>>>>>> >>>>>
>>>>>> >>>>> On Mon, Aug 22, 2016 at 2:27 PM, Petr Spacek <
>>>>>> pspacek at redhat.com>
>>>>>> >>>> wrote:
>>>>>> >>>>>
>>>>>> >>>>>> On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
>>>>>> >>>>>>> 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
>>>>>> >>>>>>
>>>>>> >>>>>> Possibly, I'm not sure. If you want to dig into this, I would
>>>>>> do this:
>>>>>> >>>>>> 1. look what process hangs on client (using pstree command or
>>>>>> so)
>>>>>> >>>>>> $ pstree
>>>>>> >>>>>>
>>>>>> >>>>>> 2. look to what server and port is the hanging client
>>>>>> connected to
>>>>>> >>>>>> $ lsof -p
>>>>>> >>>>>>
>>>>>> >>>>>> 3. jump to server and see what process is bound to the target
>>>>>> port
>>>>>> >>>>>> $ netstat -pn
>>>>>> >>>>>>
>>>>>> >>>>>> 4. see where the process if hanging
>>>>>> >>>>>> $ strace -p
>>>>>> >>>>>>
>>>>>> >>>>>> I hope it helps.
>>>>>> >>>>>>
>>>>>> >>>>>> Petr^2 Spacek
>>>>>> >>>>>>
>>>>>> >>>>>>> On Fri, Aug 19, 2016 at 7:24 PM, Rakesh Rajasekharan <
>>>>>> >>>>>>> rakesh.rajasekharan at 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 <
>>>>>> pspacek at redhat.com>
>>>>>> >>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> --
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From th at casalogic.dk Mon Sep 5 07:02:04 2016
From: th at casalogic.dk (Troels Hansen)
Date: Mon, 5 Sep 2016 09:02:04 +0200 (CEST)
Subject: [Freeipa-users] SUDO and group lookup in AD trust
In-Reply-To: <20160902075629.djs3yy22zk4p3kiz@hendrix>
References: <2050149863.1012561.1471958268423.JavaMail.zimbra@casalogic.dk>
<260135086.10187.1472112336235.JavaMail.zimbra@casalogic.dk>
<20160825084820.GB30315@10.4.128.1>
<1042341051.13710.1472117452652.JavaMail.zimbra@casalogic.dk>
<20160825204152.GA6360@10.4.128.1>
<20160826055407.sok4s6c7ehtwoe3q@hendrix>
<20160902072757.GA6086@10.4.128.1>
<20160902075629.djs3yy22zk4p3kiz@hendrix>
Message-ID: <793201723.148000.1473058924080.JavaMail.zimbra@casalogic.dk>
----- On Sep 2, 2016, at 9:56 AM, Jakub Hrozek jhrozek at redhat.com wrote:
>> >We were debugging this yesterday with Troels and the logs said it's:
>> > https://fedorahosted.org/sssd/ticket/3127
>> >
>> Fixed version is in 1.14 copr
>
> Thank you, btw another affected user confirmed that the patch fixes the
> problem.
>
Hi, one question. I can see that ticket 2919 targeted for 1.14.0 and 3127 which fixes our problem is targeted for SSSD 1.14.2 and RHEL 7.3beta currently runs 1.14.0
Will RHEL7.3 have the currently working SSSD 1.14.1 from jhrozek's COPR repo (test build https://copr.fedorainfracloud.org/coprs/jhrozek/sssd-principal-test/)
From mbasti at redhat.com Mon Sep 5 07:12:08 2016
From: mbasti at redhat.com (Martin Basti)
Date: Mon, 5 Sep 2016 09:12:08 +0200
Subject: [Freeipa-users] General query regarding nameserver enrtry
In-Reply-To:
References:
Message-ID: <4d9223c9-216b-d79d-5c93-ec81466c75c6@redhat.com>
On 02.09.2016 20:06, Deepak Dimri wrote:
> Hi All,
>
> My ipa-client-install fails until etc/resolve.conf gets updated with
> IPA nameserver entry. I want to avoid a task of updating
> resolve.conf in my automation script. Is there a way i can get my IPA
> client installation successful without updating resolve.conf? what
> options do i have?
>
>
> Many Thanks,
> Deepak
>
>
Hello,
do you have proper zone delegation? With proper zone delegation it
should be able to resolve IPA from every nameserver.
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jhrozek at redhat.com Mon Sep 5 07:26:39 2016
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Mon, 5 Sep 2016 09:26:39 +0200
Subject: [Freeipa-users] SUDO and group lookup in AD trust
In-Reply-To: <793201723.148000.1473058924080.JavaMail.zimbra@casalogic.dk>
References: <2050149863.1012561.1471958268423.JavaMail.zimbra@casalogic.dk>
<260135086.10187.1472112336235.JavaMail.zimbra@casalogic.dk>
<20160825084820.GB30315@10.4.128.1>
<1042341051.13710.1472117452652.JavaMail.zimbra@casalogic.dk>
<20160825204152.GA6360@10.4.128.1>
<20160826055407.sok4s6c7ehtwoe3q@hendrix>
<20160902072757.GA6086@10.4.128.1>
<20160902075629.djs3yy22zk4p3kiz@hendrix>
<793201723.148000.1473058924080.JavaMail.zimbra@casalogic.dk>
Message-ID: <20160905072639.ifofnqwuvcxv54tx@hendrix>
On Mon, Sep 05, 2016 at 09:02:04AM +0200, Troels Hansen wrote:
>
>
> ----- On Sep 2, 2016, at 9:56 AM, Jakub Hrozek jhrozek at redhat.com wrote:
> >> >We were debugging this yesterday with Troels and the logs said it's:
> >> > https://fedorahosted.org/sssd/ticket/3127
> >> >
> >> Fixed version is in 1.14 copr
> >
> > Thank you, btw another affected user confirmed that the patch fixes the
> > problem.
> >
>
>
> Hi, one question. I can see that ticket 2919 targeted for 1.14.0 and 3127 which fixes our problem is targeted for SSSD 1.14.2 and RHEL 7.3beta currently runs 1.14.0
>
> Will RHEL7.3 have the currently working SSSD 1.14.1 from jhrozek's COPR repo (test build https://copr.fedorainfracloud.org/coprs/jhrozek/sssd-principal-test/)
Not 1.14.1, but 7.3 will have the patch I put in my COPR repo (that's in
general how RHEL works, we can rebase only up to a certain point and then
we cherry-pick selected approved patches to avoid breaking RHEL with some
unrelated upstream change..)
From tbordaz at redhat.com Mon Sep 5 07:33:48 2016
From: tbordaz at redhat.com (thierry bordaz)
Date: Mon, 5 Sep 2016 09:33:48 +0200
Subject: [Freeipa-users] Freeipa 4.2.0 hangs intermittently
In-Reply-To:
References:
<57BEB0AB.2090506@redhat.com>
<57C44AC6.1030402@redhat.com>
Message-ID: <57CD1FDC.2010109@redhat.com>
Hi Rakesh,
Were you able to get a pstack or full stack with gdb
(http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes) when
the server hangs ?
If it happens with 500 threads as well as with 30, using 30 threads is a
better choice to debug this issue.
I will try to reproduce using 150 parallel 'ipa user-find p-testipa'
commands
Something I am unsure is if the CPU consumption stays high (you
mentioned 340% CPU usage) as long as the hang happens or if after a
suddent shot up to 340% (that marks the beginning of the hang) it drops
and stay hanging ?
thanks
thierry
On 09/04/2016 08:40 PM, Rakesh Rajasekharan wrote:
> starce on the slapd process actually had this in the output..
> FUTEX_WAIT_PRIVATE
>
> and checking for the number of threads slapd had.. there were 5015 threads
>
> ps -efL|grep slapd|wc -l
> 5015
>
> strace on most of the threads gave this output
>
> strace -p 67411
> Process 67411 attached
> futex(0x7f3f0226b41c, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN
> (Resource temporarily unavailable)
> futex(0x7f3f0226b41c, FUTEX_WAIT_PRIVATE, 2, NULL^CProcess 67411 detached
>
>
>
>
>
> On Sun, Sep 4, 2016 at 5:34 PM, Rakesh Rajasekharan
> >
> wrote:
>
> I have again got the issue of IPA hanging.. The issue came up when
> i tried to run ipa-client-isntall on 142 clients simultaneously
>
>
> None of the IPA commands are responding, and I see this error
>
> ipa user-find p-testipa
> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI
> Error: Unspecified GSS failure. Minor code may provide more
> information (KDC returned error string: PROCESS_TGS)
>
> KRB5_TRACE=/dev/stdout kinit admin
> [41178] 1472984115.233214: Getting initial credentials for
> admin at XYZ.COM
> [41178] 1472984115.235257: Sending request (167 bytes) to XYZ.COM
>