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
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/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 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? -- 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 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 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 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) 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 -- 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/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 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 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? -- 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
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 ? Ludwig On 07/18/2014 08:18 PM, Anthony Messina wrote: On Friday, July 18, 2014 10:29:07 AM Ludwig Krispenz wrote: 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 ? When I diff between the newly installed 10dns-plugin.ldif and the one that was created for my FreeIPA instance, I can see the difference. However, i'm not sure how to reconcile the two such that both FreeIPA & 389 DS are happy. ~]# diff -u /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif /etc/dirsrv/schema/10dna-plugin.ldif --- /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif 2013-08-06 04:14:33.72600 -0500 +++ /etc/dirsrv/schema/10dna-plugin.ldif2014-07-03 13:31:44.0 -0500 @@ -170,6 +170,38 @@ # # +attributeTypes: ( 2.16.840.1.113730.3.1.2157 NAME 'dnaRemoteBindCred' + DESC 'Remote bind credentials' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + X-ORIGIN '389 Directory Server' ) +# + +# +attributeTypes: ( 2.16.840.1.113730.3.1.2158 NAME 'dnaRemoteBindDN' + DESC 'Remote bind DN' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE + X-ORIGIN '389 Directory Server' ) +# + +# +attributeTypes: ( 2.16.840.1.113730.3.1.2159 NAME 'dnaRemoteConnProtocol' + DESC 'Connection protocol: LDAP, TLS, or SSL' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + X-ORIGIN '389 Directory Server' ) +# + +# +attributeTypes: ( 2.16.840.1.113730.3.1.2160 NAME 'dnaRemoteBindMethod' + DESC 'Remote bind method: SIMPLE, SSL, SASL/DIGEST-MD5, or SASL/GSSAPI' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + X-ORIGIN '389 Directory Server' ) +# + +# objectClasses: ( 2.16.840.1.113730.3.2.324 NAME 'dnaPluginConfig' DESC 'DNA plugin configuration' SUP top @@ -185,7 +217,9 @@ dnaSharedCfgDN $ dnaThreshold $ dnaNextRange $ -dnaRangeRequestTimeout $ +dnaRangeRequestTimeout $ +dnaRemoteBindDN $ +dnaRemoteBindCred $ cn ) X-ORIGIN '389 Directory Server' ) @@ -199,6 +233,8 @@ MAY ( dnaHostname $ dnaPortNum $ dnaSecurePortNum $ +dnaRemoteBindMethod $ +dnaRemoteConnProtocol $ dnaRemainingValues ) X-ORIGIN '389 Directory Server' ) -- 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 18, 2014 10:29:07 AM Ludwig Krispenz wrote: > 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 ? When I diff between the newly installed 10dns-plugin.ldif and the one that was created for my FreeIPA instance, I can see the difference. However, i'm not sure how to reconcile the two such that both FreeIPA & 389 DS are happy. ~]# diff -u /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif /etc/dirsrv/schema/10dna-plugin.ldif --- /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif 2013-08-06 04:14:33.72600 -0500 +++ /etc/dirsrv/schema/10dna-plugin.ldif2014-07-03 13:31:44.0 -0500 @@ -170,6 +170,38 @@ # # +attributeTypes: ( 2.16.840.1.113730.3.1.2157 NAME 'dnaRemoteBindCred' + DESC 'Remote bind credentials' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + X-ORIGIN '389 Directory Server' ) +# + +# +attributeTypes: ( 2.16.840.1.113730.3.1.2158 NAME 'dnaRemoteBindDN' + DESC 'Remote bind DN' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE + X-ORIGIN '389 Directory Server' ) +# + +# +attributeTypes: ( 2.16.840.1.113730.3.1.2159 NAME 'dnaRemoteConnProtocol' + DESC 'Connection protocol: LDAP, TLS, or SSL' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + X-ORIGIN '389 Directory Server' ) +# + +# +attributeTypes: ( 2.16.840.1.113730.3.1.2160 NAME 'dnaRemoteBindMethod' + DESC 'Remote bind method: SIMPLE, SSL, SASL/DIGEST-MD5, or SASL/GSSAPI' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + X-ORIGIN '389 Directory Server' ) +# + +# objectClasses: ( 2.16.840.1.113730.3.2.324 NAME 'dnaPluginConfig' DESC 'DNA plugin configuration' SUP top @@ -185,7 +217,9 @@ dnaSharedCfgDN $ dnaThreshold $ dnaNextRange $ -dnaRangeRequestTimeout $ +dnaRangeRequestTimeout $ +dnaRemoteBindDN $ +dnaRemoteBindCred $ cn ) X-ORIGIN '389 Directory Server' ) @@ -199,6 +233,8 @@ MAY ( dnaHostname $ dnaPortNum $ dnaSecurePortNum $ +dnaRemoteBindMethod $ +dnaRemoteConnProtocol $ dnaRemainingValues ) X-ORIGIN '389 Directory Server' ) -- 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/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
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