[389-users] Proxied Authorization Control (RFC 4370)
Hi all, Does 389DS support Proxied Authorization Control (RFC 4370)? Some googling and manual reading suggests it doesn’t, but need to confirm if I am missing something? Regards, Graham — -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] 389ds + Java getAttributeSyntaxDefinition() == NameNotFoundException
Hi all,
I have some Java code that is attempting to read the schema of returned LDAP
attributes from a 389ds server in an effort to work out what object to parse
the attribute as. This is being done generically, I don’t know the data types I
will be getting in the search result.
String numericoid = at.getAttributeSyntaxDefinition()
.getAttributes("").get("numericoid").get()
.toString();
The above code is throwing a javax.naming.NameNotFoundException inside the
getAttributeSyntaxDefinition() call:
javax.naming.NameNotFoundException: 1.3.6.1.4.1.1466.115.121.1.15{256}
at
com.sun.jndi.toolkit.dir.HierMemDirCtx.doLookup(HierMemDirCtx.java:127)
at
com.sun.jndi.toolkit.dir.HierMemDirCtx.doLookup(HierMemDirCtx.java:121)
at com.sun.jndi.toolkit.dir.HierMemDirCtx.lookup(HierMemDirCtx.java:95)
at com.sun.jndi.toolkit.dir.HierMemDirCtx.lookup(HierMemDirCtx.java:91)
at
com.sun.jndi.ldap.LdapAttribute.getAttributeSyntaxDefinition(LdapAttribute.java:199)
The suspicious bit is the {256} at the end, which as I understand is a length
limitation (?), and I suspect this extra bit is causing the syntax lookup to
fail. 1.3.6.1.4.1.1466.115.121.1.15 is DirectoryString, and I would definitely
expect that to be valid syntax.
Am I doing this correctly, or does 389DS and JDK8 not see eye to eye on the
getAttributeSyntaxDefinition() call?
Can anyone confirm whether I am making any obvious mistakes?
Regards,
Graham
—
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)
On 5 May 2014, at 17:57, Mark Reynolds wrote: >> You're kidding. Zero actually means 2MB. Intuitive. > I agree, I don't think we should even allow "0" as a valid value, but > then again that's what the docs are for. That's what the principal of least astonishment is for. > I understand your frustration. Not that it helps now, but this logging > has been fixed/improved. However, it's not in the version you are > running(1.2.11) - it's in 1.3.1 and up. You mean to say this issue was entirely avoidable had the fix been backported to the version that real people with real servers actually use? I recognise that 389ds is corporate code written by Netscape ages ago, and I have contributed back a whole lot of the same kind of fixes to the NSS project that also suffers from the same dire error handling. Short of security fixes fixing broken error handling is probably the most important change anyone can make to code. Regards, Graham -- -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] nsds5replicaLastInitStatus: -2 Total update abortedSystem error
Hi all, I have two LDAP servers in a multimaster replication setup that has worked fine for a while. Recently it was reported to me that the two LDAP servers had somehow gone out of sync and refused to replicate. I am trying to fix this by triggering an initialisation from what I've chosen to be authoritative source of data to the other using the instructions here: http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Configuring-Replication-cmd.html#Configuring-Replication-InitializingConsumers-cmd When the replication is triggered, a few thousand lines appear on the remote side's log that look like this: [23/Nov/2013:15:00:07 +] conn=4402 op=0 BIND dn="cn=Replication Manager,cn=config" method=128 version=3 [23/Nov/2013:15:00:07 +] conn=4402 op=0 RESULT err=0 tag=97 nentries=0 etime=1 dn="cn=replication manager,cn=config" [23/Nov/2013:15:00:07 +] conn=4402 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [23/Nov/2013:15:00:07 +] conn=4402 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [23/Nov/2013:15:00:07 +] conn=4402 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [23/Nov/2013:15:00:07 +] conn=4402 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [23/Nov/2013:15:00:07 +] conn=4402 op=3 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [23/Nov/2013:15:00:07 +] conn=4402 op=3 RESULT err=0 tag=120 nentries=0 etime=0 [23/Nov/2013:15:00:08 +] conn=4402 op=4 EXT oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update Entry" [23/Nov/2013:15:00:08 +] conn=4402 op=4 RESULT err=0 tag=120 nentries=0 etime=0 [23/Nov/2013:15:00:08 +] conn=4402 op=5 EXT oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update Entry" [23/Nov/2013:15:00:08 +] conn=4402 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [snip a few thousand log entries all saying err=0] The side that I initialised the replication from lists this message as the status, which is too vague to be useful: nsds5replicaLastInitStatus: -2 Total update abortedSystem error Does anyone know what the error "-2" means? Does anyone have any clear and unambiguous instructions for re-initialising two LDAP servers that have gone out of sync? Regards, Graham -- -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
