Re: Some openldap 2.4 questions
On Fri, Jan 15, 2010 at 08:44:47AM +0100, Radosław Antoniuk wrote: On Fri, Jan 15, 2010 at 2:01 AM, Howard Chu h...@symas.com wrote: Radosław Antoniuk wrote: Hi, Three quick issues about slapd 2.4. 1. I'm setting up a syncrepl replication. In the process of testing, I had added three syncprov overlays instead of one, and I ended up with: The thing is, that I cannot delete any of them because cn=config does not support delete operation. I have been able to delete (I had the same problem as you). but i used the rootdn of the config db Is this ok to leave it as is? or any workaround to get rid of the unwanted ones? [snip] 3. Assuming a running normal replication(master-slave) with refreshAndPersist, is there any method of checking of the status of the replication? like I believe you can look at the CSN cookie - not sure how though signature.asc Description: Digital signature
Re: Openldap installation problem
2010/1/15 Murat Uğur Eminoğlu mu...@murat.ws On 01/15/2010 12:33 AM, Michael Ströder wrote: Murat Uğur Eminoğlu wrote: Thanks all replys. But i have problem now. debian 5, dpkg-buildpackage -b errors cp: cannot stat `./debian/tmp/etc/ldap/schema': No such file or directory dh_install: command returned error code 256 make: *** [binary-arch] Error 1 dpkg-buildpackage: failure: debian/rules binary gave error exit status 2 If you really built OpenLDAP yourself it seems something's messed up with the Debian packages already installed on your system. I'd recommend to user a different --prefix to install to and create a custom slapd.conf from scratch. Ciao, Michael. Dear Michael, same errors. How i can solve this problem? Hi Murat, Does the package build correctly before the changes ( I mean, just after apt-get source slapd) ? Best regards, Radek Antoniuk
Re: Some openldap 2.4 questions
The thing is, that I cannot delete any of them because cn=config does not support delete operation. I have been able to delete (I had the same problem as you). but i used the rootdn of the config db Hi Alex, Hmm, that's interesting. RooDN of the configdb? you mean 'cn=admin,cn=config' ? If so, I've obviously tried to do it with exactly this DN :) But, as documentation states , cn=config deletion is not supported now (experimental). I'm thinking. Maybe shutting down the daemon and removing it manually from the slapd.d config files is enough? Or will that brake the database? I did a change of RootDN password like that and it worked, but... Regards, Radek Antoniuk
Re: Server-Side Sort Overlay ordering problems
Diego,
You and I have the same issue. UID and CN are not in the schema they
are compiled into LDAP some how, so there is no way to apply an
ordering rule. I can not find if this is possible, or what is involved
in making it happen.
As you can see uid is commented in the schema file as is cn
#attributetype ( 0.9.2342.19200300.100.1.1
# NAME ( 'uid' 'userid' )
# DESC 'RFC1274: user identifier'
# EQUALITY caseIgnoreMatch
# SUBSTR caseIgnoreSubstringsMatch
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
In the past this was possible, or the attributes had an ordering. I do
not know when this changed.
On Fri, Jan 15, 2010 at 8:27 AM, Diego Lima li...@diegolima.org wrote:
Hello,
I have enabled the server-side sorting overlay and I received the following
error on a search:
sssvlv: no ordering rule specified and no default ordering rule for
attribute uid
= get_ctrls: n=1 rc=18 err=serverSort control: No ordering rule
send_ldap_result: conn=1000 op=7 p=3
send_ldap_response: msgid=8 tag=101 err=18
ber_flush2: 50 bytes to sd 13
ldap_write: want=50, written=50
: 30 30 02 01 08 65 2b 0a 01 12 04 00 04 24 73 65 00...e+..$se
0010: 72 76 65 72 53 6f 72 74 20 63 6f 6e 74 72 6f 6c rverSort control
0020: 3a 20 4e 6f 20 6f 72 64 65 72 69 6e 67 20 72 75 : No ordering ru
0030: 6c 65 le
conn=1000 op=7 do_search: get_ctrls failed
Where should I specify the ordering rule for the uid attribute? The core
schema?
Thank you
--
Diego Lima
Re: how to use ipv6 addresses in olcaccess statements
Alex Samad writes: I am trying to build a olcaccess statement and I am wondering how to implement a ipv6 network I haven't tried, but a look at slapd.access(5) and aclparse.c suggests by peername.ipv6=address%mask where address and mask are hex IPv6 addresses. Default mask is :::::::. -- Hallvard
Re: Server-Side Sort Overlay ordering problems
--On Friday, January 15, 2010 12:06 PM -0500 Edward Capriolo
edlinuxg...@gmail.com wrote:
Diego,
You and I have the same issue. UID and CN are not in the schema they
are compiled into LDAP some how, so there is no way to apply an
ordering rule. I can not find if this is possible, or what is involved
in making it happen.
As you can see uid is commented in the schema file as is cn
# attributetype ( 0.9.2342.19200300.100.1.1
# NAME ( 'uid' 'userid' )
# DESC 'RFC1274: user identifier'
# EQUALITY caseIgnoreMatch
# SUBSTR caseIgnoreSubstringsMatch
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
In the past this was possible, or the attributes had an ordering. I do
not know when this changed.
You can find these attributes defined in the code in servers/slapd.
However, I will note, the definitions of these attributes are RFC defined.
They have no ORDERING rule on purpose.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Re: Some openldap 2.4 questions
Radosław Antoniuk wrote: *Clearly* the provider SHOULD provide information, if it has pushed all the updates to the slaves. Ok, your excuse is that this is due to the fact, that the provider does not keep track of slaves. Ergo? The slaves are wrongly implemented. And *they* should provide the information if they have the connection and are up2date or not. This is of course totally implementation-dependent (in this case, I'd even risk the statement that it is quite wrongly implemented), when we have *no idea* if the slave copy is up2date or not. Obviously the consumer knows what its replication status is, but you can only determine whether a consumer is up to date or not when you have simultaneous access to both the consumer and the provider, to compare their status. If you sever the network connection, nothing can be inferred on either side about the other. Since you haven't bothered to read the design of syncrepl or the motivation behind it, you're in no position to judge the correctness of it. Answers like those, make me think that open-source is a waste of time comparing to paid solutions (even though I am a strong evangelist of Debian and other open source solutions, which I think the writer does not care about). The defining characteristic of open source is that the code is openly shared amongst developers and users. There is nothing implied about costs of operating it. If you believe there's a distinction between paid solutions and open source you're quite mistaken, the two are completely orthogonal. If you have a commercial enterprise, and you have even half a brain, you pay for support for your solutions, whether they are open or closed source. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Some openldap 2.4 questions
--On Saturday, January 16, 2010 01:40:30 AM +0100 Radosław Antoniuk radek.anton...@gmail.com wrote: Answers like those, make me think that open-source is a waste of time comparing to paid solutions (even though I am a strong evangelist of Debian and other open source solutions, which I think the writer does not care about). Well, we clearly have decended to questioning other's motives. Once a discussion gets to that point it is fairly useless continue to talk. I am reminded of a passage from William Faulkner's Light in August. Man knows so little about his fellows. In his eyes all men or women act upon what he believes would motivate him if he were mad enough to do what that other man or woman is doing. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University
Re: Auth access for search-based mappings?
Hi all, My OpenLDAP 2.4 test system uses Kerberos, SASL and GSSAPI. I've got person objects located in two different org. units and want to search both of them for a potential match, so I included these two statements in slapd.conf: authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=eng,dc=example,dc=com??one?((uid=$1)(objectClass=person)) authz-regexp uid=([^,].*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=bio,dc=example,dc=com??one?((uid=$1)(objectClass=person)) Unfortunately, it's not working as I hoped. If I have two test users, uid=john in ou=eng and uid=pete ou=bio, then after first authenticating them with the Kerberos kinit command, in this situation a subsequent ldapwhoami command for each will give: dn:uid=john,ou=eng,dc=example,dc=com dn:uid=pete,cn=example.com,cn=gssapi,cn=auth The second result is, of course, completely useless. However, if I change the order of two authz-regexp statements I get: dn:uid=john,cn=example.com,cn=gssapi,cn=auth dn:uid=pete,ou=bio,dc=example,dc=com Now the first result is useless. In other words, both authz-regexp statements work, but the second statement is being ignored. Why? How can I get slapd to also process the second authz-regexp statement? Thanks, Jaap
Re: Auth access for search-based mappings?
Jaap Winius wrote: Hi all, My OpenLDAP 2.4 test system uses Kerberos, SASL and GSSAPI. I've got person objects located in two different org. units and want to search both of them for a potential match, so I included these two statements in slapd.conf: authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=eng,dc=example,dc=com??one?((uid=$1)(objectClass=person)) authz-regexp uid=([^,].*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=bio,dc=example,dc=com??one?((uid=$1)(objectClass=person)) Unfortunately, it's not working as I hoped. If I have two test users, uid=john in ou=eng and uid=pete ou=bio, then after first authenticating them with the Kerberos kinit command, in this situation a subsequent ldapwhoami command for each will give: dn:uid=john,ou=eng,dc=example,dc=com dn:uid=pete,cn=example.com,cn=gssapi,cn=auth The second result is, of course, completely useless. However, if I change the order of two authz-regexp statements I get: dn:uid=john,cn=example.com,cn=gssapi,cn=auth dn:uid=pete,ou=bio,dc=example,dc=com Now the first result is useless. In other words, both authz-regexp statements work, but the second statement is being ignored. Why? How can I get slapd to also process the second authz-regexp statement? You can't. As the slapd.conf(5) manpage states, the matching process stops at the first rule that matches the incoming SASL name. If you want to use multiple authz-regexp statements, they must each have unique match portions because any duplicates will be ignored. For your case, you need to come up with a single search specification that will handle both branches of your search. One possible solution would be to use entryDN in the filter: ldap:///dc=example,dc=com??sub? ((|(entryDN:dnSubtree:=ou=eng,dc=example,dc=com) (entryDN:dnSubtree:ou=bio,dc=example,dc=com)) (uid=$1)(objectclass=person)) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
