Re: [Freeipa-users] attribute dnaremotebindmethod not allowed
On Friday, July 25, 2014 01:43:04 PM Anthony Messina wrote: On Friday, July 25, 2014 11:00:05 AM Rich Megginson wrote: On 07/25/2014 10:43 AM, Anthony Messina wrote: On Friday, July 25, 2014 10:26:55 AM Rich Megginson wrote: On 07/25/2014 01:46 AM, Anthony Messina wrote: On Thursday, July 24, 2014 08:44:34 AM Martin Kosek wrote: On 07/23/2014 06:38 PM, Anthony Messina wrote: On Monday, July 21, 2014 01:09:43 PM Ludwig Krispenz wrote: Looks like the schema file was changed, but not added to the list of files to be replaced at upgrade, I will open a 389 ticket and have it in the next release. Could you try t copy file manually for now ? Manually copying the file from /etc/dirsrv/schema/10dna-plugin.ldif to /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif on both of my IPA masters and restarting seems to have eliminated the error. Is there anything else that needs to be done? That should be all. BTW, the schema upgrade error is now fixed in https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20 With that update, my dirsrv error logs on both of my masters are flooded with the following errors. Issuing 'ipactl restart' several times seems to reduce the incidence: - Connection is NULL and hence cannot access SLAPI_CONN_ID Sorry about that - this will be fixed in 1.3.2.21. Thank you, Rich. Also, I'm not sure if it's related to the above error, but the following are what I find related to the originally reported dnaremotebindmethod issue after upgrading both of my masters. Should the dnaRemoteBindMethod and dnaRemoteConnProtocol have something other than (null) as a value? Should they be the same on each master? ~]# ldapsearch -Y GSSAPI -LLL -s sub -b cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com SASL/GSSAPI authentication started SASL username: ad...@example.com SASL SSF: 56 SASL data security layer installed. dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com objectClass: nsContainer objectClass: top cn: posix-ids dn: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com objectClass: dnaSharedConfig objectClass: top dnaHostname: ipa1.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 199972 dnaRemoteBindMethod: (null) dnaRemoteConnProtocol: (null) This looks wrong. Please file a ticket. I'm having trouble understanding the problem in order to file a ticket... I first upgraded to 389-ds-base-1.3.2.19-1.fc20.x86_64 where I received the schema errors as well as dna-plugin - dna_update_shared_config: Unable to update shared config entry: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com [error 65] I then upgraded to 389-ds-base-1.3.2.20-1.fc20. Unfortunately, I cannot be sure what *should* be present for each of dnaRemoteBindMethod and dnaRemoteConnProtocol *or* if any original values were deleted when I first installed 389-ds-base-1.3.2.19-1.fc20.x86_64. If so, how would I know what the values were? I'm not sure. What I think is that these should not be present at all - I think they are just copied from the replication agreement configuration. Also, should the ticket be filed against 389, or against FreeIPA? 389 Ticket filed: https://fedorahosted.org/389/ticket/47866 dn: dnaHostname=ipa2.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com objectClass: dnaSharedConfig objectClass: top dnaHostname: ipa2.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 0 Shouldn't the second master also have values for dnaRemoteBindMethod and dnaRemoteConnProtocol? For others who may be looking into this issue, I copied the values from the FreeIPA replication agreement: nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicaTransportInfo: LDAP and ldapmodify-d as follows: dn: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com changetype: modify replace: dnaRemoteBindMethod dnaRemoteBindMethod: SASL/GSSAPI - replace: dnaRemoteConnProtocol dnaRemoteConnProtocol: LDAP -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] attribute dnaremotebindmethod not allowed
On 07/25/2014 01:46 AM, Anthony Messina wrote: On Thursday, July 24, 2014 08:44:34 AM Martin Kosek wrote: On 07/23/2014 06:38 PM, Anthony Messina wrote: On Monday, July 21, 2014 01:09:43 PM Ludwig Krispenz wrote: Looks like the schema file was changed, but not added to the list of files to be replaced at upgrade, I will open a 389 ticket and have it in the next release. Could you try t copy file manually for now ? Manually copying the file from /etc/dirsrv/schema/10dna-plugin.ldif to /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif on both of my IPA masters and restarting seems to have eliminated the error. Is there anything else that needs to be done? That should be all. BTW, the schema upgrade error is now fixed in https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20 With that update, my dirsrv error logs on both of my masters are flooded with the following errors. Issuing 'ipactl restart' several times seems to reduce the incidence: - Connection is NULL and hence cannot access SLAPI_CONN_ID Sorry about that - this will be fixed in 1.3.2.21. Also, I'm not sure if it's related to the above error, but the following are what I find related to the originally reported dnaremotebindmethod issue after upgrading both of my masters. Should the dnaRemoteBindMethod and dnaRemoteConnProtocol have something other than (null) as a value? Should they be the same on each master? ~]# ldapsearch -Y GSSAPI -LLL -s sub -b cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com SASL/GSSAPI authentication started SASL username: ad...@example.com SASL SSF: 56 SASL data security layer installed. dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com objectClass: nsContainer objectClass: top cn: posix-ids dn: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com objectClass: dnaSharedConfig objectClass: top dnaHostname: ipa1.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 199972 dnaRemoteBindMethod: (null) dnaRemoteConnProtocol: (null) This looks wrong. Please file a ticket. dn: dnaHostname=ipa2.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com objectClass: dnaSharedConfig objectClass: top dnaHostname: ipa2.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 0 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] attribute dnaremotebindmethod not allowed
On Friday, July 25, 2014 10:26:55 AM Rich Megginson wrote: On 07/25/2014 01:46 AM, Anthony Messina wrote: On Thursday, July 24, 2014 08:44:34 AM Martin Kosek wrote: On 07/23/2014 06:38 PM, Anthony Messina wrote: On Monday, July 21, 2014 01:09:43 PM Ludwig Krispenz wrote: Looks like the schema file was changed, but not added to the list of files to be replaced at upgrade, I will open a 389 ticket and have it in the next release. Could you try t copy file manually for now ? Manually copying the file from /etc/dirsrv/schema/10dna-plugin.ldif to /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif on both of my IPA masters and restarting seems to have eliminated the error. Is there anything else that needs to be done? That should be all. BTW, the schema upgrade error is now fixed in https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20 With that update, my dirsrv error logs on both of my masters are flooded with the following errors. Issuing 'ipactl restart' several times seems to reduce the incidence: - Connection is NULL and hence cannot access SLAPI_CONN_ID Sorry about that - this will be fixed in 1.3.2.21. Thank you, Rich. Also, I'm not sure if it's related to the above error, but the following are what I find related to the originally reported dnaremotebindmethod issue after upgrading both of my masters. Should the dnaRemoteBindMethod and dnaRemoteConnProtocol have something other than (null) as a value? Should they be the same on each master? ~]# ldapsearch -Y GSSAPI -LLL -s sub -b cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com SASL/GSSAPI authentication started SASL username: ad...@example.com SASL SSF: 56 SASL data security layer installed. dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com objectClass: nsContainer objectClass: top cn: posix-ids dn: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com objectClass: dnaSharedConfig objectClass: top dnaHostname: ipa1.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 199972 dnaRemoteBindMethod: (null) dnaRemoteConnProtocol: (null) This looks wrong. Please file a ticket. I'm having trouble understanding the problem in order to file a ticket... I first upgraded to 389-ds-base-1.3.2.19-1.fc20.x86_64 where I received the schema errors as well as dna-plugin - dna_update_shared_config: Unable to update shared config entry: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com [error 65] I then upgraded to 389-ds-base-1.3.2.20-1.fc20. Unfortunately, I cannot be sure what *should* be present for each of dnaRemoteBindMethod and dnaRemoteConnProtocol *or* if any original values were deleted when I first installed 389-ds-base-1.3.2.19-1.fc20.x86_64. If so, how would I know what the values were? Also, should the ticket be filed against 389, or against FreeIPA? dn: dnaHostname=ipa2.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com objectClass: dnaSharedConfig objectClass: top dnaHostname: ipa2.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 0 Shouldn't the second master also have values for dnaRemoteBindMethod and dnaRemoteConnProtocol? -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] attribute dnaremotebindmethod not allowed
On Friday, July 25, 2014 11:00:05 AM Rich Megginson wrote: On 07/25/2014 10:43 AM, Anthony Messina wrote: On Friday, July 25, 2014 10:26:55 AM Rich Megginson wrote: On 07/25/2014 01:46 AM, Anthony Messina wrote: On Thursday, July 24, 2014 08:44:34 AM Martin Kosek wrote: On 07/23/2014 06:38 PM, Anthony Messina wrote: On Monday, July 21, 2014 01:09:43 PM Ludwig Krispenz wrote: Looks like the schema file was changed, but not added to the list of files to be replaced at upgrade, I will open a 389 ticket and have it in the next release. Could you try t copy file manually for now ? Manually copying the file from /etc/dirsrv/schema/10dna-plugin.ldif to /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif on both of my IPA masters and restarting seems to have eliminated the error. Is there anything else that needs to be done? That should be all. BTW, the schema upgrade error is now fixed in https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20 With that update, my dirsrv error logs on both of my masters are flooded with the following errors. Issuing 'ipactl restart' several times seems to reduce the incidence: - Connection is NULL and hence cannot access SLAPI_CONN_ID Sorry about that - this will be fixed in 1.3.2.21. Thank you, Rich. Also, I'm not sure if it's related to the above error, but the following are what I find related to the originally reported dnaremotebindmethod issue after upgrading both of my masters. Should the dnaRemoteBindMethod and dnaRemoteConnProtocol have something other than (null) as a value? Should they be the same on each master? ~]# ldapsearch -Y GSSAPI -LLL -s sub -b cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com SASL/GSSAPI authentication started SASL username: ad...@example.com SASL SSF: 56 SASL data security layer installed. dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com objectClass: nsContainer objectClass: top cn: posix-ids dn: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com objectClass: dnaSharedConfig objectClass: top dnaHostname: ipa1.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 199972 dnaRemoteBindMethod: (null) dnaRemoteConnProtocol: (null) This looks wrong. Please file a ticket. I'm having trouble understanding the problem in order to file a ticket... I first upgraded to 389-ds-base-1.3.2.19-1.fc20.x86_64 where I received the schema errors as well as dna-plugin - dna_update_shared_config: Unable to update shared config entry: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com [error 65] I then upgraded to 389-ds-base-1.3.2.20-1.fc20. Unfortunately, I cannot be sure what *should* be present for each of dnaRemoteBindMethod and dnaRemoteConnProtocol *or* if any original values were deleted when I first installed 389-ds-base-1.3.2.19-1.fc20.x86_64. If so, how would I know what the values were? I'm not sure. What I think is that these should not be present at all - I think they are just copied from the replication agreement configuration. Also, should the ticket be filed against 389, or against FreeIPA? 389 Ticket filed: https://fedorahosted.org/389/ticket/47866 dn: dnaHostname=ipa2.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com objectClass: dnaSharedConfig objectClass: top dnaHostname: ipa2.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 0 Shouldn't the second master also have values for dnaRemoteBindMethod and dnaRemoteConnProtocol? -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] attribute dnaremotebindmethod not allowed
On 07/17/2014 04:56 PM, Anthony Messina wrote: After upgrading to Fedora 20's stable 389-ds-base-1.3.2.19-1.fc20.x86_64, I noticed the following errors during the restart cycle. I have a simple 2 host MMR setup. Should I be concerned about these? If so, I'd be open to recommendations. Thanks. -A [17/Jul/2014:07:51:50 -0500] - Entry dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com -- attribute dnaremotebindmethod not allowed [17/Jul/2014:07:51:50 -0500] dna-plugin - dna_update_shared_config: Unable to update shared config entry: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com [error 65] CC-ing Ludwig and Thierry. Is it possible that 389 DS schema was not updated during it's upgrade? (Maybe related to https://fedorahosted.org/389/ticket/47779?) FreeIPA itself does not touch these attributes (yet). Thanks, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] attribute dnaremotebindmethod not allowed
On 07/18/2014 09:50 AM, Martin Kosek wrote: On 07/17/2014 04:56 PM, Anthony Messina wrote: After upgrading to Fedora 20's stable 389-ds-base-1.3.2.19-1.fc20.x86_64, I noticed the following errors during the restart cycle. I have a simple 2 host MMR setup. Should I be concerned about these? If so, I'd be open to recommendations. Thanks. -A [17/Jul/2014:07:51:50 -0500] - Entry dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com -- attribute dnaremotebindmethod not allowed [17/Jul/2014:07:51:50 -0500] dna-plugin - dna_update_shared_config: Unable to update shared config entry: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com [error 65] CC-ing Ludwig and Thierry. Is it possible that 389 DS schema was not updated during it's upgrade? (Maybe related to https://fedorahosted.org/389/ticket/47779?) FreeIPA itself does not touch these attributes (yet). the dnaremotebindmethod was added in June2013 to schema/10dna-plugin.ldif and the dnaSharedConfig objectclass - so it should be there. And in my 1.3.219 installation it is. Are you sure the entry you want to add has dnaSharedConfig and not (only) dnaPluginConfig ? Thanks, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
