Re: access
Am Tue, 28 Jun 2011 15:10:00 -0300 schrieb Friedrich Locke friedrich.lo...@gmail.com: How may i know i setted SASL/GSSAPI correctly ? Here is how i executed saslauthd: saslauthd -a kerberos5 -cd -t 60 -n 2 -s 128 Here is a test: sioux@gustav$ testsaslauthd -u sioux -p XYZ 0: OK Success. sioux@gustav$ Is there something more i need to do ? [...] Do not use saslauthd, just make use of openldap's own SASL framework. -Dieter -- Dieter Klünter | Systemberatung sip: 7770...@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
chaining through proxy and slave
Hello list, With the following scenario Client (A) - back_ldap Proxy (B) - syncrepl Slave (C) - Master (D) and B and C use a binddn that only has full read permissions on the database, except for a couple of attributes, on which it has full write permissions. Also, Each of the represented nodes can only talk to the nodes to which there is a represented connection, so (A) and (B) cannot chase a configured referral to (D). What would be the proper way to setup (B) and (C) so that (A) could push updates for the couple of attributes into the master (D) node? At the Slave level, i've already setup chaining and making it use (D) as updateref, but then any push on (B) would not propagate. I also noticed that in although i used mode=self, in the chaining, i had to configure a binddn which had full write permissions. Wouldn't it be sufficient to have a full read enabled binddn or even no binddn at all since the bind would then be made using the clients credentials? Thanks in advance, Hugo Monteiro. -- fct.unl.pt:~# cat .signature Hugo Monteiro Email: hugo.monte...@fct.unl.pt Telefone : +351 212948300 Ext.15307 Web : http://hmonteiro.net Divisão de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.fct.unl.ptap...@fct.unl.pt fct.unl.pt:~# _
Loading LDAP schema files into cn=config
Hi all, Having started to look at the changes required to migrate from a slapd.conf setup to a cn=config setup, one of things I'm struggling with is how to load new LDAP schemas into cn=config. I've seen the guides similar to this one here: http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html which suggest hacking together a temporary slapd.conf file containing just the include directives, run slaptest, and then hack the output so that it can be loaded into cn=config using ldapadd. Given that this is a quite a common task, is there no way of generating the LDIF directly to be loaded into the directory, e.g. slaptest -s /etc/ldap/schema/myschema.schema [ -n schemanum ] -l myschema.ldif Or then again, is this functionality already there but I just haven't managed to find it yet? I'd be grateful if someone could point me in the right direction and/or give me some hints as to the best way to manage schemas in the new regime. Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Re: Loading LDAP schema files into cn=config
Mark Cave-Ayland wrote: Hi all, Having started to look at the changes required to migrate from a slapd.conf setup to a cn=config setup, one of things I'm struggling with is how to load new LDAP schemas into cn=config. I've seen the guides similar to this one here: http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html which suggest hacking together a temporary slapd.conf file containing just the include directives, run slaptest, and then hack the output so that it can be loaded into cn=config using ldapadd. His step 1 and 2 were fine. Everything after that is garbage. 1: schemaConvert.conf include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include samba.schema 2: slaptest mkdir config slaptest -f schemaConvert.conf -F config 3: slapcat slapcat -F config -n0 -s cn=schema,cn=config and all of your converted schema will pop out, ready to be slapadd'd or ldapadd'd anywhere else. Given that this is a quite a common task, is there no way of generating the LDIF directly to be loaded into the directory, e.g. slaptest -s /etc/ldap/schema/myschema.schema [ -nschemanum ] -l myschema.ldif Or then again, is this functionality already there but I just haven't managed to find it yet? I'd be grateful if someone could point me in the right direction and/or give me some hints as to the best way to manage schemas in the new regime. -- -- 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: Loading LDAP schema files into cn=config
On 29/06/11 11:59, Howard Chu wrote: Having started to look at the changes required to migrate from a slapd.conf setup to a cn=config setup, one of things I'm struggling with is how to load new LDAP schemas into cn=config. I've seen the guides similar to this one here: http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html which suggest hacking together a temporary slapd.conf file containing just the include directives, run slaptest, and then hack the output so that it can be loaded into cn=config using ldapadd. His step 1 and 2 were fine. Everything after that is garbage. 1: schemaConvert.conf include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include samba.schema 2: slaptest mkdir config slaptest -f schemaConvert.conf -F config 3: slapcat slapcat -F config -n0 -s cn=schema,cn=config and all of your converted schema will pop out, ready to be slapadd'd or ldapadd'd anywhere else. Hi Howard, Thanks for the response - this makes a bit more sense now. Just to clarify another point: when you generate schemaConvert.conf, I guess that you need to include *all* schemas in your current cn=config matching the existing order, as well as the new one you are trying to add? Also that begs another question: what happens if you want to modify an existing schema, e.g. if I need to hack a schema by hand and reload it into openldap so that it takes effect? Normally I would change the schema file on disk, restart slapd and it would just work. With cn=config, I'm guessing I can't just delete the relevant schema entry from LDAP and re-add it since there would be a small window whereby the schema would be missing/invisible to slapd. This could cause all sorts of issues, such as pushing the incremental deletion out to any slaves, as well as breaking any concurrent lookups... :( ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Re: Loading LDAP schema files into cn=config
Mark Cave-Ayland wrote: On 29/06/11 11:59, Howard Chu wrote: Having started to look at the changes required to migrate from a slapd.conf setup to a cn=config setup, one of things I'm struggling with is how to load new LDAP schemas into cn=config. I've seen the guides similar to this one here: http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html which suggest hacking together a temporary slapd.conf file containing just the include directives, run slaptest, and then hack the output so that it can be loaded into cn=config using ldapadd. His step 1 and 2 were fine. Everything after that is garbage. 1: schemaConvert.conf include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include samba.schema 2: slaptest mkdir config slaptest -f schemaConvert.conf -F config 3: slapcat slapcat -F config -n0 -s cn=schema,cn=config and all of your converted schema will pop out, ready to be slapadd'd or ldapadd'd anywhere else. Hi Howard, Thanks for the response - this makes a bit more sense now. Just to clarify another point: when you generate schemaConvert.conf, I guess that you need to include *all* schemas in your current cn=config matching the existing order, as well as the new one you are trying to add? Obviously the config file has to be valid; any schema that the ones you're converting depend on must be loaded. Also that begs another question: what happens if you want to modify an existing schema, e.g. if I need to hack a schema by hand and reload it into openldap so that it takes effect? Normally I would change the schema file on disk, restart slapd and it would just work. I frankly can't believe that you just asked that question. cn=config is an LDAP database. When you want to change its contents, you use ldapmodify. It takes effect immediately and there is no need to restart the server. -- -- 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: Loading LDAP schema files into cn=config
On 29/06/11 12:59, Howard Chu wrote:
Thanks for the response - this makes a bit more sense now. Just to
clarify another point: when you generate schemaConvert.conf, I guess
that you need to include *all* schemas in your current cn=config
matching the existing order, as well as the new one you are trying to
add?
Obviously the config file has to be valid; any schema that the ones
you're converting depend on must be loaded.
I understand that part; however when installing the packages for Debian
Squeeze the post-installation process preloads the following schemas
into cn=schema,cn=config:
{0}core
{1}cosine
{2}nis
{3}inetorgperson
So what I wanted to verify was that if I want to add a new
sirius-custom.schema file into the directory I would need to setup
schemaConvert.conf to look like this:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/sirius-custom.schema
The previous entries are required to ensure that the
sirius-custom.schema LDIF would be generated as {4}sirius-custom ready
for using ldapadd to load into the directory.
However when I then run:
mkdir config slaptest -f slapd.conf.tmp -F config
Then I get my {4}sirius-custom.ldif but the top lines look like this:
dn: cn={4}sirius-custom
...
cn: {4}sirius-custom
...which then means I still can't add it directly using ldapadd without
further processing.
Also that begs another question: what happens if you want to modify an
existing schema, e.g. if I need to hack a schema by hand and reload it
into openldap so that it takes effect? Normally I would change the
schema file on disk, restart slapd and it would just work.
I frankly can't believe that you just asked that question. cn=config is
an LDAP database. When you want to change its contents, you use
ldapmodify. It takes effect immediately and there is no need to restart
the server.
Oh I understand that part - my question was perhaps badly asked. What I
really want to know is what should my workflow be when designing new
LDAP schemas to be distributed as .schema files? Based upon what you are
saying, I guess it should be either:
1) Update .schema file
2) Generate .ldif using slaptest
3) Manually update the relevant attribute in cn=schema using an LDAP
browser to be the new value generated within the .ldif
4) Test
or:
1) Update .schema file
2) Generate .ldif using slaptest
3) Hack the dn within the .ldif to add cn=schema,cn=config suffix
4) Remove the entire cn={x}sirius-custom section
5) Reload the entire cn={x}sirius-custom section using ldapadd
6) Test
Does that sound correct?
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
Re: Loading LDAP schema files into cn=config
Mark Cave-Ayland wrote:
On 29/06/11 12:59, Howard Chu wrote:
Thanks for the response - this makes a bit more sense now. Just to
clarify another point: when you generate schemaConvert.conf, I guess
that you need to include *all* schemas in your current cn=config
matching the existing order, as well as the new one you are trying to
add?
Obviously the config file has to be valid; any schema that the ones
you're converting depend on must be loaded.
I understand that part; however when installing the packages for Debian
Squeeze the post-installation process preloads the following schemas
into cn=schema,cn=config:
{0}core
{1}cosine
{2}nis
{3}inetorgperson
So what I wanted to verify was that if I want to add a new
sirius-custom.schema file into the directory I would need to setup
schemaConvert.conf to look like this:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/sirius-custom.schema
The previous entries are required to ensure that the
sirius-custom.schema LDIF would be generated as {4}sirius-custom ready
for using ldapadd to load into the directory.
You only need to load those 4 schema files if your sirius-custom.schema file
actually depends on all of them. The ordering prefix only needs to be {4} if
you really need those others to be parsed first. Otherwise the prefix can be
deleted and the config backend will generate it automatically. This is all in
the documentation. You should try reading it sometime.
http://www.openldap.org/doc/admin24/slapdconf2.html
However when I then run:
mkdir config slaptest -f slapd.conf.tmp -F config
Then I get my {4}sirius-custom.ldif but the top lines look like this:
No.
No.
No.
You're not paying attention. You skipped step 3 of my reply.
And apparently you need to be flamed too.
http://www.openldap.org/lists/openldap-technical/201106/msg00085.html
I frankly can't believe that you just asked that question. cn=config is
an LDAP database. When you want to change its contents, you use
ldapmodify. It takes effect immediately and there is no need to restart
the server.
Oh I understand that part - my question was perhaps badly asked. What I
really want to know is what should my workflow be when designing new
LDAP schemas to be distributed as .schema files? Based upon what you are
saying, I guess it should be either:
1) Update .schema file
2) Generate .ldif using slaptest
3) Manually update the relevant attribute in cn=schema using an LDAP
browser to be the new value generated within the .ldif
4) Test
or:
1) Update .schema file
2) Generate .ldif using slaptest
3) Hack the dn within the .ldif to add cn=schema,cn=config suffix
4) Remove the entire cn={x}sirius-custom section
5) Reload the entire cn={x}sirius-custom section using ldapadd
6) Test
Does that sound correct?
No.
As soon as you use the word hack you should realize you're doing something
wrong. As soon as you use the words manually update you should realize
you're doing something wrong.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
pcache + back-sql
Does anyone have an example of using the pcache overlay with back-sql?
Here's the relevant section of my slapd.config:
database sqlsuffix ..rootdn ...rootpw
dbname MySQLdbuser .subtree_cond ldap_entries.dn
like CONCAT('%',?)insentry_stmt INSERT INTO ldap_entries
(dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)has_ldapinfo_dn_ru
nobaseobjectupper_func UPPERautocommit yes
pcache bdb 1 1 50 100pcacheAttrset 0 * +pcacheTemplate (objectClass=) 0
60...pcache-directory /var/tmp/cachepcache-cachesize 100
What I'm unclear about is how to configure the private bdb database used for
the cache.
When use this config, slapd starts up ok, but crashes with a SEGV when (I
assume) it tries to cache a result:
(I am running slapd built from the latest code in HEAD from git)
slap_queue_csn: queing 0xb7a52efa 20110629132038.554471Z#00#000#00
Program received signal SIGSEGV, Segmentation fault.[Switching to Thread
0xb7a55b90 (LWP 26226)]0x080f3844 in slap_queue_csn (op=0xb7a53378,
csn=0xb7a52f60) at ctxcsn.c:199199 LDAP_TAILQ_INSERT_TAIL(
be-be_pending_csn_list,(gdb) where#0 0x080f3844 in slap_queue_csn
(op=0xb7a53378, csn=0xb7a52f60) at ctxcsn.c:199#1 0x080f38e0 in slap_get_csn
(op=0xb7a53378, csn=0xb7a52f60, manage_ctxcsn=1) at ctxcsn.c:214#2 0x08079f33
in slap_add_opattrs (op=0xb7a53378, text=0xb7a53214, textbuf=0xb7a53074 ,
textlen=256, manage_ctxcsn=1) at add.c:609#3 0x0814187b in bdb_add
(op=0xb7a53378, rs=0xb7a53200) at add.c:107#4 0x081a144e in merge_entry
(op=0xb7a53378, e=0x9f56e4c, dup=0, query_uuid=0xa040848) at pcache.c:865#5
0x081a4d1c in cache_entries (op=0x9fdbfc8, query_uuid=0xa040848) at
pcache.c:2325#6 0x081a5244 in pcache_op_cleanup (op=0x9fdbfc8, rs=0xb7a550e4)
at pcache.c:2430#7 0x08084697 in slap_cleanup_play (op=0x9fdbfc8,
rs=0xb7a550e4) at result.c:539#8 0x08084dd3 in send_ld!
ap_response (op=0x9fdbfc8, rs=0xb7a550e4) at result.c:724#9 0x0808554e in
slap_send_ldap_result (op=0x9fdbfc8, rs=0xb7a550e4) at result.c:851#10
0x0813e4a3 in backsql_search (op=0x9fdbfc8, rs=0xb7a550e4) at search.c:2493#11
0x0807402e in fe_op_search (op=0x9fdbfc8, rs=0xb7a550e4) at search.c:402#12
0x080f1aaa in overlay_op_walk (op=0x9fdbfc8, rs=0xb7a550e4, which=op_search,
oi=0x9f3dc80, on=0x0) at backover.c:671#13 0x080f1c5f in over_op_func
(op=0x9fdbfc8, rs=0xb7a550e4, which=op_search) at backover.c:723#14 0x080f1d0e
in over_op_search (op=0x9fdbfc8, rs=0xb7a550e4) at backover.c:750#15 0x0807397d
in do_search (op=0x9fdbfc8, rs=0xb7a550e4) at search.c:247#16 0x08070704 in
connection_operation (ctx=0xb7a551d0, arg_v=0x9fdbfc8) at connection.c:1138#17
0x08070c44 in connection_read_thread (ctx=0xb7a551d0, argv=0xd) at
connection.c:1274#18 0x081e04a5 in ldap_int_thread_pool_wrapper
(xpool=0x9f11f78) at tpool.c:685#19 0x004be5ab in start_thread () from
/lib/libpthread.so.0#20 !
0x003b2cfe in clone () from /lib/libc.so.6
It crashes because be-be_pending_csn_list is zero, presumably
because backend_startup_one() has not been called for this backend. This leads
me to believe that I need something in slapd.conf to get the private bdb
database initialised, but what?
Chris
Re: Loading LDAP schema files into cn=config
On 11-06-29 9:26 AM, Mark Cave-Ayland wrote:
On 29/06/11 12:59, Howard Chu wrote:
Thanks for the response - this makes a bit more sense now. Just to
clarify another point: when you generate schemaConvert.conf, I guess
that you need to include *all* schemas in your current cn=config
matching the existing order, as well as the new one you are trying to
add?
Obviously the config file has to be valid; any schema that the ones
you're converting depend on must be loaded.
I understand that part; however when installing the packages for
Debian Squeeze the post-installation process preloads the following
schemas into cn=schema,cn=config:
{0}core
{1}cosine
{2}nis
{3}inetorgperson
So what I wanted to verify was that if I want to add a new
sirius-custom.schema file into the directory I would need to setup
schemaConvert.conf to look like this:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/sirius-custom.schema
The previous entries are required to ensure that the
sirius-custom.schema LDIF would be generated as {4}sirius-custom ready
for using ldapadd to load into the directory.
However when I then run:
mkdir config slaptest -f slapd.conf.tmp -F config
Then I get my {4}sirius-custom.ldif but the top lines look like this:
dn: cn={4}sirius-custom
...
cn: {4}sirius-custom
...which then means I still can't add it directly using ldapadd
without further processing.
Not sure if it is the same on Debian but on Fedora I only copied the
workplace output schema file (autofs.schema in my case) to
/etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I
restarted slapd after that and everything worked for me. Surprisingly
easy although I had to do a restart.
pcache + back-sql
[Let's try that again. Hotmail/Chrome managed to screw up the formatting before]
Does anyone have an example of using the pcache overlay with back-sql?
Here's the relevant section of my slapd.config:
database sql
suffix ..
rootdn ...
rootpw
dbname MySQL
dbuser .
subtree_cond ldap_entries.dn like CONCAT('%',?)
insentry_stmt INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES
(?,?,?,?)
has_ldapinfo_dn_ru no
baseobjectupper_func UPPER
autocommit yes
pcache bdb 1 1 50 100
pcacheAttrset 0 * +
pcacheTemplate (objectClass=) 0 60
...
pcache-directory /var/tmp/cache
pcache-cachesize 100
What I'm unclear about is how to configure the private bdb database used for
the cache.
When use this config, slapd starts up ok, but crashes with a SEGV when (I
assume) it tries to cache a result:
(I am running slapd built from the latest code in HEAD from git)
slap_queue_csn: queing 0xb7a52efa 20110629132038.554471Z#00#000#00
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7a55b90 (LWP 26226)]
0x080f3844 in slap_queue_csn (op=0xb7a53378, csn=0xb7a52f60) at ctxcsn.c:199
199 LDAP_TAILQ_INSERT_TAIL( be-be_pending_csn_list,
(gdb) where
#0 0x080f3844 in slap_queue_csn (op=0xb7a53378, csn=0xb7a52f60) at ctxcsn.c:199
#1 0x080f38e0 in slap_get_csn (op=0xb7a53378, csn=0xb7a52f60, manage_ctxcsn=1)
at ctxcsn.c:214
#2 0x08079f33 in slap_add_opattrs (op=0xb7a53378, text=0xb7a53214,
textbuf=0xb7a53074 , textlen=256, manage_ctxcsn=1) at add.c:609
#3 0x0814187b in bdb_add (op=0xb7a53378, rs=0xb7a53200) at add.c:107
#4 0x081a144e in merge_entry (op=0xb7a53378, e=0x9f56e4c, dup=0,
query_uuid=0xa040848) at pcache.c:865
#5 0x081a4d1c in cache_entries (op=0x9fdbfc8, query_uuid=0xa040848) at
pcache.c:2325
#6 0x081a5244 in pcache_op_cleanup (op=0x9fdbfc8, rs=0xb7a550e4) at
pcache.c:2430
#7 0x08084697 in slap_cleanup_play (op=0x9fdbfc8, rs=0xb7a550e4) at
result.c:539
#8 0x08084dd3 in send_ldap_response (op=0x9fdbfc8, rs=0xb7a550e4) at
result.c:724
#9 0x0808554e in slap_send_ldap_result (op=0x9fdbfc8, rs=0xb7a550e4) at
result.c:851
#10 0x0813e4a3 in backsql_search (op=0x9fdbfc8, rs=0xb7a550e4) at search.c:2493
#11 0x0807402e in fe_op_search (op=0x9fdbfc8, rs=0xb7a550e4) at search.c:402
#12 0x080f1aaa in overlay_op_walk (op=0x9fdbfc8, rs=0xb7a550e4,
which=op_search, oi=0x9f3dc80, on=0x0) at backover.c:671
#13 0x080f1c5f in over_op_func (op=0x9fdbfc8, rs=0xb7a550e4, which=op_search)
at backover.c:723
#14 0x080f1d0e in over_op_search (op=0x9fdbfc8, rs=0xb7a550e4) at backover.c:750
#15 0x0807397d in do_search (op=0x9fdbfc8, rs=0xb7a550e4) at search.c:247
#16 0x08070704 in connection_operation (ctx=0xb7a551d0, arg_v=0x9fdbfc8) at
connection.c:1138
#17 0x08070c44 in connection_read_thread (ctx=0xb7a551d0, argv=0xd) at
connection.c:1274
#18 0x081e04a5 in ldap_int_thread_pool_wrapper (xpool=0x9f11f78) at tpool.c:685
#19 0x004be5ab in start_thread () from /lib/libpthread.so.0
#20 0x003b2cfe in clone () from /lib/libc.so.6
It crashes because be-be_pending_csn_list is zero, presumably because
backend_startup_one() has not been called for this backend. This leads me to
believe that I need something in slapd.conf to get the private bdb database
initialised, but what?
Chris
Re: Loading LDAP schema files into cn=config
On 29/06/11 14:42, Howard Chu wrote:
You only need to load those 4 schema files if your sirius-custom.schema
file actually depends on all of them. The ordering prefix only needs to
be {4} if you really need those others to be parsed first. Otherwise the
prefix can be deleted and the config backend will generate it
automatically. This is all in the documentation. You should try reading
it sometime.
http://www.openldap.org/doc/admin24/slapdconf2.html
(cut)
You're not paying attention. You skipped step 3 of my reply.
And apparently you need to be flamed too.
http://www.openldap.org/lists/openldap-technical/201106/msg00085.html
Okay - I consider myself flamed on this occasion :) But that still
doesn't quite get me there:
echo include /etc/ldap/schema/sirius-custom.schema slapd.conf.tmp
mkdir config slaptest -f slapd.conf.tmp -F config
slapcat -F config/ -n0 -s cn=schema,cn=config sirius-custom.ldif
That gives me a sirius-custom.ldif which contains both dn:
cn=schema,cn=config and dn: cn={0}sirius-custom,cn=schema,cn=config
which is better - but it's still not something I can directly run
through ldapadd:
zeno:/tmp# ldapadd -D 'cn=admin,dc=siriusit,dc=co,dc=uk' -f
sirius-custom.ldif -xW
Enter LDAP Password:
adding new entry cn=schema,cn=config
ldap_add: Constraint violation (19)
additional info: structuralObjectClass: no user modification
allowed
I don't get much further even if I remove cn=schema,cn=config leaving
just dn: cn={0}sirius-custom,cn=schema,cn=config within the output.
And also the slapcat command above always generates a {0} index for the
output, so how can I alter the above command so that it omits the index
so that slapd generates it automatically? And what happens if I
accidentally add the same schema but with a different index? Does slapd
consider them to be two different entries?
Does that sound correct?
No.
As soon as you use the word hack you should realize you're doing
something wrong. As soon as you use the words manually update you
should realize you're doing something wrong.
I have been honest enough during this thread to admit that I felt I may
have missed something obvious. But I have to point out that all of the
Google searches I have done on this topic have returned posts similar to
the one I pointed you to, which you are saying are wrong.
There is a lot of mis-information out there regarding cn=config but I at
least I understand that I need to come to the project itself to get some
answers.
I understand your frustration here, but it will also take some effort on
behalf of the project to ensure that the documentation can answer
questions such as mine - I've been using openldap for 3 years now, and
cn=config still takes some getting used to.
Once we have figured out a basic schema workflow, I am happy to submit a
documentation patch to help other people such as myself in return for
your assistance.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
Re: Loading LDAP schema files into cn=config
On 29/06/11 15:15, Daniel Qian wrote: Not sure if it is the same on Debian but on Fedora I only copied the workplace output schema file (autofs.schema in my case) to /etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I restarted slapd after that and everything worked for me. Surprisingly easy although I had to do a restart. Right, that is one option. But indeed the primary advantage of cn=config is that it doesn't need a restart, and that's really where I want to be :) ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Re: Loading LDAP schema files into cn=config
On 11-06-29 10:49 AM, Mark Cave-Ayland wrote: On 29/06/11 15:15, Daniel Qian wrote: Not sure if it is the same on Debian but on Fedora I only copied the workplace output schema file (autofs.schema in my case) to /etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I restarted slapd after that and everything worked for me. Surprisingly easy although I had to do a restart. Right, that is one option. But indeed the primary advantage of cn=config is that it doesn't need a restart, and that's really where I want to be :) ATB, Mark. In that case you can slapcat it into the db after trimming the schema file I guess. But then the cn=config directory structure on file system will be inconsistent with the actual running config. Actually I have been wondering for a while if this will be an issue and would like to hear some words if anyone have about this.
Re: Loading LDAP schema files into cn=config
On 29/06/2011 16:46, Mark Cave-Ayland wrote: I have been honest enough during this thread to admit that I felt I may have missed something obvious. But I have to point out that all of the Google searches I have done on this topic have returned posts similar to the one I pointed you to, which you are saying are wrong. There is a lot of mis-information out there regarding cn=config but I at least I understand that I need to come to the project itself to get some answers. I understand your frustration here, but it will also take some effort on behalf of the project to ensure that the documentation can answer questions such as mine - I've been using openldap for 3 years now, and cn=config still takes some getting used to. I think that putting the cn=config backend in some other directory instead of /etc/ldap/slapd.d (that's for Debian, don't know for other distributions) could help a lot. Most sysadmin expect to find text configuration files under /etc, not a kind of testual DB. I already filed a bug for Debian because that choice is like looking for trouble. Having it in a binary format could be even better, so people will not mislead thinking they are some kind of split configuration files. Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Loading LDAP schema files into cn=config
On 29/06/2011 16:15, Daniel Qian wrote: Not sure if it is the same on Debian but on Fedora I only copied the workplace output schema file (autofs.schema in my case) to /etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I restarted slapd after that and everything worked for me. Surprisingly easy although I had to do a restart. Then I think you must be flamed too... But if you did so, then why just not to stay with slapd.conf? It still work and is far easier to understand and manage. Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
RE: pcache + back-sql
Does anyone have an example of using the pcache overlay with back-sql? Here's the relevant section of my slapd.config: I've found the problem I think, I had the overlay pcache in the global section, rather than in the database sql section.At least it's not crashing now, I'm still trying to convince myself that repeated requests are being served from the cache. Chris
Re: Loading LDAP schema files into cn=config
On 29/06/11 16:50, Simone Piccardi wrote: I think that putting the cn=config backend in some other directory instead of /etc/ldap/slapd.d (that's for Debian, don't know for other distributions) could help a lot. Most sysadmin expect to find text configuration files under /etc, not a kind of testual DB. I already filed a bug for Debian because that choice is like looking for trouble. Having it in a binary format could be even better, so people will not mislead thinking they are some kind of split configuration files. Hmmm - that's an interesting thought. It probably should be under /var/lib/slapd-config or similar as it is effectively a database rather than a configuration file. My understanding is that touching the files in /etc/ldap/slapd.d is a definite no-no once the LDAP directory has been initialised, which is why I'm interested in Howard showing us his workflow for working on schemas so I can document it. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Re: Loading LDAP schema files into cn=config
On 11-06-29 11:56 AM, Simone Piccardi wrote: On 29/06/2011 16:15, Daniel Qian wrote: Not sure if it is the same on Debian but on Fedora I only copied the workplace output schema file (autofs.schema in my case) to /etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I restarted slapd after that and everything worked for me. Surprisingly easy although I had to do a restart. Then I think you must be flamed too... But if you did so, then why just not to stay with slapd.conf? It still work and is far easier to understand and manage. Regards Simone I want to stay with the cn=config but to be frank there are some items that need to be clarified, perhaps in the documentation of the distribution so that end users like myself won't has so much frustration when it comes to setting it up the new way.
Re: Loading LDAP schema files into cn=config
On 29/06/11 16:56, Simone Piccardi wrote: Then I think you must be flamed too... But if you did so, then why just not to stay with slapd.conf? It still work and is far easier to understand and manage. Because slapd.conf is deprecated and going away in openldap 2.5. So I'd like to get familiar with it now before this happens :) Although I'm not sure exactly how this is going to work since elements of slapd.conf are still required to bootstrap the directory from LDAP .schema files. Hmmm. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Re: Loading LDAP schema files into cn=config
On 11-06-29 12:28 PM, Mark Cave-Ayland wrote: On 29/06/11 16:50, Simone Piccardi wrote: I think that putting the cn=config backend in some other directory instead of /etc/ldap/slapd.d (that's for Debian, don't know for other distributions) could help a lot. Most sysadmin expect to find text configuration files under /etc, not a kind of testual DB. I already filed a bug for Debian because that choice is like looking for trouble. Having it in a binary format could be even better, so people will not mislead thinking they are some kind of split configuration files. Hmmm - that's an interesting thought. It probably should be under /var/lib/slapd-config or similar as it is effectively a database rather than a configuration file. My understanding is that touching the files in /etc/ldap/slapd.d is a definite no-no once the LDAP directory has been initialised, which is why I'm interested in Howard showing us his workflow for working on schemas so I can document it. ATB, Mark. Question is why the /etc/openldap/slapd.d file structure is there for users to edit in the first place? Wouldn't it be even more misleading if the running one is modified on the fly while the one in slapd.d/ is not? A bunch of online tutorials and howtos are actually asking people to touch those files, such as cn=config file at least for initial setup.
Re: kerberos ldap/host.my.domain
On 28/06/11 16:05 -0300, Friedrich Locke wrote: Hi folks, i have just installed openldap and i am facing a situation i would like to share with you. In OpenBSD (the OS i am using) i have the keytab file inside /etc/kerberosV. Its access mode is 600, its ownership is root:wheel. But OpenBSD specifies a user and group the slapd daemon should run as; the user is u and group g. In order to get SASL/GSSAPI working i need to add to the keytab the principal ldap/host.my.domain. I did it; now the keytab has the principals host/x.y.z and ldap/x.y.z But since slapd runs as another user it is prevented from accessing the keytab file. So i thought the following possible solutions: 0) Run slapd as root 1) change the permission of the keytab Any of those options above makes security less secure. I known there should be some more approaches, but i cannot think it right now. If your GSSAPI mechanism is compiled against heimdal, you should be able to specify an alternate location for your keytab file. Create/edit /usr/lib/sasl2/slapd.conf (or the location specified by --with-configdir at sasl compile time), and customize the location with: keytab: /etc/kerberosV-ldap with read permissions for your slapd user. Another option is to create a new system group (e.g. 'keytab'), and set ownership of /etc/kerberosV to 'root:keytab', with read permissions for keytab, and add your slapd user (and other necessary members) to that group. Write permissions should not be necessary. -- Dan White
Re: Loading LDAP schema files into cn=config
--On Wednesday, June 29, 2011 5:30 PM +0100 Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk wrote: On 29/06/11 16:56, Simone Piccardi wrote: Then I think you must be flamed too... But if you did so, then why just not to stay with slapd.conf? It still work and is far easier to understand and manage. Because slapd.conf is deprecated and going away in openldap 2.5. So I'd like to get familiar with it now before this happens :) Although I'm not sure exactly how this is going to work since elements of slapd.conf are still required to bootstrap the directory from LDAP .schema files. Hmmm. Zimbra puts cn=config in the same location as any other LDAP database we use (/opt/zimbra/data/ldap/, which has cn=config, hdb, and accesslog databases). As for the *.ldif schema, OpenLDAP ships both .ldif and .schema files for the schemas it has always shipped. If a project is not shipping a .ldif version, file a bug with the project (I did this for Amavis, for example). If you have your own schema, change your schema generation process to generate an LDIF formatted schema instead of the old .schema format. That's also what we did at Zimbra (In fact, we generate both .schema and .ldif versions of the ZCS schema). --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: Loading LDAP schema files into cn=config
--On Wednesday, June 29, 2011 12:51 PM -0400 Daniel Qian dan...@up247solution.com wrote: Question is why the /etc/openldap/slapd.d file structure is there for users to edit in the first place? Wouldn't it be even more misleading if the running one is modified on the fly while the one in slapd.d/ is not? A bunch of online tutorials and howtos are actually asking people to touch those files, such as cn=config file at least for initial setup. The OpenLDAP project has no control over how Linux distributions decide to deploy their configurations, or any control over online tutorials or how-NOT-to's. Feel free to file bugs with Debian, etc, to fix their cn=config layout. Feel free to email people who have posted online tutorials and how-NOT-tos to either correct them or take them offline. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: kerberos ldap/host.my.domain
--On Wednesday, June 29, 2011 11:56 AM -0500 Dan White dwh...@olp.net wrote: If your GSSAPI mechanism is compiled against heimdal, you should be able to specify an alternate location for your keytab file. Create/edit /usr/lib/sasl2/slapd.conf (or the location specified by --with-configdir at sasl compile time), and customize the location with: You shouldn't require a sasl2/slapd.conf at all. Just do something like: export KRB5_KTNAME=/etc/ldap.keytab --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
RE: pcache + back-sql
Does anyone have an example of using the pcache overlay with back-sql? Here's the relevant section of my slapd.config: I've found the problem I think, I had the overlay pcache in the global section, rather than in the database sql section.At least it's not crashing now, I'm still trying to convince myself that repeated requests are being served from the cache. did you read (and understand) slapo-pcache(5)? only queries matching configured templates (filter + requested attributes) are cached. Use pcache logging subsystem to track whether caching occurs. p.
Re: chaining through proxy and slave
Hello list, With the following scenario Client (A) - back_ldap Proxy (B) - syncrepl Slave (C) - Master (D) and B and C use a binddn that only has full read permissions on the database, except for a couple of attributes, on which it has full write permissions. Also, Each of the represented nodes can only talk to the nodes to which there is a represented connection, so (A) and (B) cannot chase a configured referral to (D). What would be the proper way to setup (B) and (C) so that (A) could push updates for the couple of attributes into the master (D) node? At the Slave level, i've already setup chaining and making it use (D) as updateref, but then any push on (B) would not propagate. I also noticed that in although i used mode=self, in the chaining, i had to configure a binddn which had full write permissions. Wouldn't it be sufficient to have a full read enabled binddn or even no binddn at all since the bind would then be made using the clients credentials? This is not going to work, because using mode=self, idassert authc's as the proxy identity, and then proxyauthz's as the user's identity. As a consequence, when the slave tries to chain a modification, it finds the proxyauthz control already in use, and cannot assert the original identity. Distributed procedures (distproc, currently not implemented) would be needed to fit your needs. p.
RE: pcache + back-sql
Does anyone have an example of using the pcache overlay with back-sql? Here's the relevant section of my slapd.config: I've found the problem I think, I had the overlay pcache in the global section, rather than in the database sql section.At least it's not crashing now, I'm still trying to convince myself that repeated requests are being served from the cache. did you read (and understand) slapo-pcache(5)? only queries matching configured templates (filter + requested attributes) are cached. Use pcache logging subsystem to track whether caching occurs. p. Yes, I've read that manual page and configured templates. I've also got the monitoring backend working, and I can see that caching is happening. Can you point me to documentation about the pcache logging subsystem? Chris
RE: pcache + back-sql
Does anyone have an example of using the pcache overlay with back-sql? Here's the relevant section of my slapd.config: I've found the problem I think, I had the overlay pcache in the global section, rather than in the database sql section.At least it's not crashing now, I'm still trying to convince myself that repeated requests are being served from the cache. did you read (and understand) slapo-pcache(5)? only queries matching configured templates (filter + requested attributes) are cached. Use pcache logging subsystem to track whether caching occurs. p. Yes, I've read that manual page and configured templates. I've also got the monitoring backend working, and I can see that caching is happening. Can you point me to documentation about the pcache logging subsystem? slapd -d pcache Indeed, I can't find any mention of it in obvious places (slapo-pcache(5), admin guide under pcache overlay, loglevel directive in slapd.conf(5) or slapd-config(5)). I suggest you file a request for documentation update. p.
Connections
I would like to see how many connections openldap is serving on a given momment. I am trying this: sioux@gustav$ ldapsearch -LLL -W -D cn=oldap,dc=ufv,dc=br -b cn=current,cn=connections,cn=monitor -H ldap://gustav.cpd.ufv.br/ objectclass=* Enter LDAP Password: dn: cn=Current,cn=Connections,cn=Monitor objectClass: monitorCounterObject cn: Current sioux@gustav$ I cannot see the number of connections. Where is my mistake ? Thanks a lot.
Re: Connections
--On Wednesday, June 29, 2011 5:05 PM -0300 Friedrich Locke friedrich.lo...@gmail.com wrote: I would like to see how many connections openldap is serving on a given momment. I am trying this: sioux@gustav$ ldapsearch -LLL -W -D cn=oldap,dc=ufv,dc=br -b cn=current,cn=connections,cn=monitor -H ldap://gustav.cpd.ufv.br/ objectclass=* Enter LDAP Password: dn: cn=Current,cn=Connections,cn=Monitor objectClass: monitorCounterObject cn: Current sioux@gustav$ I cannot see the number of connections. Where is my mistake ? You didn't request the operational attributes back. Try adding + to your search. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
fetching information
I am planing using openldap to fetch user/group information. Below my main tree there will be ou=people and ou=group, and below those the regular user or group information. It happens that a program (ypserv) will fetch information from tree binding as cn=ypserv just below my main tree. This binding should be authenticated, so what should cn=ypserv attributes be? What about access rules for it ? Thanks a lot for your time and cooperation. Best regards! Fried.
protected entry
Dear list users, i would like to have an entry in my openldap server thats needs to have a password so that it would be able to permit clients to bind as it providing its password. For instance: cn=x,ou=y,dc=a,dc=b So anyone knowing cn=x,ou=y,dc=a,dc=b 's password could bind as it. Any ideia? Thanks.
Re: fetching information
Friedrich Locke wrote: I am planing using openldap to fetch user/group information. Below my main tree there will be ou=people and ou=group, and below those the regular user or group information. It happens that a program (ypserv) will fetch information from tree binding as cn=ypserv just below my main tree. This binding should be authenticated, so what should cn=ypserv attributes be? Probably use applicationProcess and simpleSecurityObject classes. -- -- 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: protected entry
--On Wednesday, June 29, 2011 8:00 PM -0300 Friedrich Locke friedrich.lo...@gmail.com wrote: Dear list users, i would like to have an entry in my openldap server thats needs to have a password so that it would be able to permit clients to bind as it providing its password. For instance: cn=x,ou=y,dc=a,dc=b So anyone knowing cn=x,ou=y,dc=a,dc=b 's password could bind as it. Add a userPassword value to that entry. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: protected entry
To which objectclass should the entry belongs to ? What about access rules ? Thanks On Wed, Jun 29, 2011 at 8:14 PM, Quanah Gibson-Mount qua...@zimbra.com wrote: --On Wednesday, June 29, 2011 8:00 PM -0300 Friedrich Locke friedrich.lo...@gmail.com wrote: Dear list users, i would like to have an entry in my openldap server thats needs to have a password so that it would be able to permit clients to bind as it providing its password. For instance: cn=x,ou=y,dc=a,dc=b So anyone knowing cn=x,ou=y,dc=a,dc=b 's password could bind as it. Add a userPassword value to that entry. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: fetching information
Where may i download those objectclass from ? Thanks in advance On Wed, Jun 29, 2011 at 8:14 PM, Howard Chu h...@symas.com wrote: Friedrich Locke wrote: I am planing using openldap to fetch user/group information. Below my main tree there will be ou=people and ou=group, and below those the regular user or group information. It happens that a program (ypserv) will fetch information from tree binding as cn=ypserv just below my main tree. This binding should be authenticated, so what should cn=ypserv attributes be? Probably use applicationProcess and simpleSecurityObject classes. -- -- 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: Connections
Am Wed, 29 Jun 2011 17:05:15 -0300 schrieb Friedrich Locke friedrich.lo...@gmail.com: I would like to see how many connections openldap is serving on a given momment. I am trying this: sioux@gustav$ ldapsearch -LLL -W -D cn=oldap,dc=ufv,dc=br -b cn=current,cn=connections,cn=monitor -H ldap://gustav.cpd.ufv.br/ objectclass=* Enter LDAP Password: dn: cn=Current,cn=Connections,cn=Monitor objectClass: monitorCounterObject cn: Current sioux@gustav$ I cannot see the number of connections. Where is my mistake ? Most of monitor attribute types are operational, the attribute type that stores information on connections is monitorCounter. -Dieter -- Dieter Klünter | Systemberatung sip: 7770...@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
