I try to set up a delta-syncrepl configured via slapd.d. Building the configuration with Ansilbe. I got the following errormessages on my two consumers: ---------------- Sep 08 19:45:49 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:45:49 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) Sep 08 19:45:54 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:45:54 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (3 retries left) Sep 08 19:45:59 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:45:59 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (2 retries left) Sep 08 19:46:04 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:46:04 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (1 retries left) Sep 08 19:46:09 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:46:09 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying Sep 08 19:46:14 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:46:14 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying
----------------
Here is my configuration of the provider: ------------- # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapmaster-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapmaster-key.pem olcToolThreads: 1
# module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_mdb olcModuleLoad: {1}syncprov.la olcModuleLoad: {2}accesslog.la . . . # {0}mdb, config dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
# {-1}frontend, config dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500 # {0}config, config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb
# {1}mdb, config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1} to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2} to attrs=shadowLastChange by self write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824
# {0}syncprov, {1}mdb, config dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 300
# {2}mdb, config dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcAccess: {0} to dn.sub=cn=accesslog by dn.exact=cn=repl-user,ou=users,dc=exa mple,dc=net read by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net read olcDbIndex: reqStart,reqEnd,reqMod,reqResult eq # {0}accesslog, {2}mdb, config dn: olcOverlay={0}accesslog,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 01+00:00 00+04:00 olcAccessLogSuccess: TRUE ------------- As you can see, the syncrepl and accesslog overlays are configured. The database files are pressend and filepermission is ok.
Here now the configuration of the consumer ------------- # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapslave-01-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapslave-01-key.pem olcToolThreads: 1
# module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_md . . . # {0}mdb, config dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
# {-1}frontend, config dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500
# {0}config, config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb # {1}mdb, config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1} to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2} to attrs=shadowLastChange by self write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcSyncrepl: {0}rid=1 provider=ldaps://ldapmaster.example.net type=refreshAndP ersist retry="5 5 300 +" filter="(ObjectClass=*)" scope=sub bindmethod=simple searchbase="dc=example,dc=net" binddn="cn=repl-user,ou=users,dc=example,dc=n et" credentials=geheim syncdata=accesslog logbase="cn=accesslog" logfilter="( &(objectClass=auditWriteObject)(reqResult=0)) olcUpdateRef: ldaps://ldapmaster.example.net olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824 -------------
I can access the accesslog-DB with ldapsearch as repl-user: ----------------- root@ldapslave-01:~# ldapsearch -x -D cn=repl-user,ou=users,dc=example,dc=net -w geheim -b cn=accesslog -H ldaps://ldapmaster.example.net -LLL dn: cn=accesslog objectClass: auditContainer cn: accesslog
dn: reqStart=20200908174203.000008Z,cn=accesslog objectClass: auditAdd reqStart: 20200908174203.000008Z reqEnd: 20200908174203.000011Z reqType: add reqSession: 18446744073709551615 reqAuthzID: cn=accesslog reqDN: cn=accesslog reqResult: 0 reqMod: objectClass:+ auditContainer reqMod: cn:+ accesslog reqMod: structuralObjectClass:+ auditContainer -----------------
On the provider I see the following messages when accessing the accesslog: ----------------- Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 fd=14 ACCEPT from IP=192.168.56.16:52338 (IP=0.0.0.0:636) Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 fd=14 TLS established tls_ssf=256 ssf=256 Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=0 BIND dn="cn=repl-user,ou=users,dc=example,dc=net" method=128 Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=0 BIND dn="cn=repl-user,ou=users,dc=example,dc=net" mech=SIMPLE ssf=0 Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=0 RESULT tag=97 err=0 text= Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=2 UNBIND Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 fd=14 closed
----------------- I see these messages even when I restart the consumer. So I think there is no problem with the access-permissions.
any help is welcome :-)
Stefan
--On Tuesday, September 8, 2020 9:57 PM +0200 Stefan Kania stefan@kania-online.de wrote:
I try to set up a delta-syncrepl configured via slapd.d. Building the configuration with Ansilbe. I got the following errormessages on my two consumers:
Your configuration has many problems. ;)
The accesslog overlay goes on the primary DB, not the accesslog DB.
You're missing a syncprov overlay on the accesslog DB to tell it to provide a hint, etc.
I suggest carefully reading over the configs at https://mishikal.wordpress.com/2019/04/23/configuring-mmr-using-delta-syncrepl-in-openldap-updating-an-existing-standalone-configuration/
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi Quanah, thank's for the help. Up to now I did the delta-syncreple only via slapd.conf, now I'm will get it work with slapd.d AND Ansilble. After your posting I looked at my configuration and I saw it. Sometimes you need someone to bring you an the right track. Thank's, not only for this answer, you are doing a great job on this mailinglist!
Stefan
Am 08.09.20 um 21:35 schrieb Quanah Gibson-Mount:
Your configuration has many problems. ;)
I did a lot of changes to my configuration via Ansible. Here is my provider configuration:
-------------------- dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapmaster-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapmaster-key.pem olcToolThreads: 1
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_mdb olcModuleLoad: {1}syncprov.la olcModuleLoad: {2}accesslog.la olcModuleLoad: {3}back_monitor objectClass: olcSchemaConfig cn: schema ... dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 300
dn: olcDatabase={2}Monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}Monitor olcAccess: {0} to dn.subtree="cn=monitor" by dn.exact="cn=ldap-admin,ou=users, dc=example,dc=net" read
dn: olcDatabase={3}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcAccess: {0} to dn.sub=cn=accesslog by dn.exact=cn=repl-user,ou=users,dc=exa mple,dc=net read by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net read olcDbIndex: reqStart,reqEnd,reqMod,reqResult,entryCSN,entryUUID,objectClass eq
dn: olcOverlay={0}accesslog,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 01+00:00 00+04:00 olcAccessLogSuccess: TRUE
dn: olcOverlay={1}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 300 --------------------
Here the configuration of my consumer: --------------------- n: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapslave-01-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapslave-01-key.pem olcToolThreads: 1
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_mdb olcModuleLoad: {1}back_monitor
dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema ...
dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcSyncrepl: {0}rid=1 provider=ldaps://ldapmaster.example.net type=refreshAndP ersist retry="5 5 300 +" filter="(ObjectClass=*)" scope=sub bindmethod=simple searchbase="dc=example,dc=net" binddn="cn=repl-user,ou=users,dc=example,dc=n et" credentials=geheim syncdata=accesslog logbase="cn=accesslog" logfilter="( &(objectClass=auditWriteObject)(reqResult=0)) olcUpdateRef: ldaps://ldapmaster.example.net olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824
dn: olcDatabase={2}Monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}Monitor olcAccess: {0} to dn.subtree="cn=monitor" by dn.exact="cn=ldap-admin,ou=users, dc=example,dc=net" read ---------------------
When I restart my consumer I see the following logs on the consumer: ---------- Sep 15 20:42:09 ldapslave-01 systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol). Sep 15 20:42:09 ldapslave-01 slapd[2742]: slap_queue_csn: queueing 0x7f4f6011ceb0 20200915172117.549009Z#000000#000#000000 Sep 15 20:42:09 ldapslave-01 slapd[2742]: syncrepl_message_to_op: rid=001 tid 6e8d4700 Sep 15 20:42:09 ldapslave-01 slapd[2742]: syncrepl_message_to_op: rid=001 mods check (objectClass: value #0 invalid per syntax) Sep 15 20:42:09 ldapslave-01 slapd[2742]: slap_graduate_commit_csn: removing 0x7f4f6011ceb0 20200915172117.549009Z#000000#000#000000 Sep 15 20:42:09 ldapslave-01 slapd[2742]: do_syncrepl: rid=001 rc 21 retrying (4 retries left) ----------
On the provider: ---------- Sep 15 20:42:14 ldapmaster slapd[2868]: conn=1002 fd=14 ACCEPT from IP=192.168.56.16:38500 (IP=0.0.0.0:636) Sep 15 20:42:14 ldapmaster slapd[2868]: conn=1002 fd=14 TLS established tls_ssf=256 ssf=256 Sep 15 20:42:14 ldapmaster slapd[2868]: conn=1002 op=0 BIND dn="cn=repl-user,ou=users,dc=example,dc=net" method=128 Sep 15 20:42:14 ldapmaster slapd[2868]: conn=1002 op=0 BIND dn="cn=repl-user,ou=users,dc=example,dc=net" mech=SIMPLE ssf=0 Sep 15 20:42:14 ldapmaster slapd[2868]: conn=1002 op=0 RESULT tag=97 err=0 text= Sep 15 20:42:14 ldapmaster slapd[2868]: conn=1002 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Sep 15 20:42:14 ldapmaster slapd[2868]: conn=1002 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Sep 15 20:42:14 ldapmaster slapd[2868]: syncprov_search_response: cookie=rid=001,csn=20200915173214.801545Z#000000#000#000000 Sep 15 20:42:14 ldapmaster slapd[2868]: conn=1002 op=2 UNBIND Sep 15 20:42:14 ldapmaster slapd[2868]: conn=1002 fd=14 closed ---------- I'm looking at my configuration for days, at the moment "I can't see the tree in the forrest " :-) (as we say in Germany).
I comared the subschema of both consumer and provider there are the same. I try to access the accesslog with ldapsearch with my rep-user and I can access the database.
Can anyone have a look at my configuration please.
Stefan
Am 09.09.20 um 10:39 schrieb Stefan Kania:
Hi Quanah, thank's for the help. Up to now I did the delta-syncreple only via slapd.conf, now I'm will get it work with slapd.d AND Ansilble. After your posting I looked at my configuration and I saw it. Sometimes you need someone to bring you an the right track. Thank's, not only for this answer, you are doing a great job on this mailinglist!
Stefan
Am 08.09.20 um 21:35 schrieb Quanah Gibson-Mount:
Your configuration has many problems. ;)
--On Tuesday, September 15, 2020 9:50 PM +0200 Stefan Kania stefan@kania-online.de wrote:
I did a lot of changes to my configuration via Ansible. Here is my provider configuration:
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 300
You have no ACCESSLOG OVERLAY here on your primary DB, which is not a valid delta-sync configuration.
dn: olcOverlay={0}accesslog,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 01+00:00 00+04:00 olcAccessLogSuccess: TRUE
You have an ACCESSLOG OVERLAY here on your *accesslog* db, which is completely invalid.
dn: olcOverlay={1}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 300
You have an invalidly configured SYNCPROV OVERLAY on the accesslog DB. The only valid config items for the syncprov overlay on the accesslog db are:
olcSpNoPresent: TRUE olcSpReloadHint: TRUE
To summarize:
For delta-syncrepl, the PRIMARY db must have a SYNCPROV and ACCESSLOG overlay defined. The ACCESSLOG db must have a SYNCPROV overlay defined and it MUST set olcSpNoPresent to TRUE and olcSpReloadHint to TRUE.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Tuesday, September 15, 2020 1:10 PM -0700 Quanah Gibson-Mount quanah@symas.com wrote:
To summarize:
For delta-syncrepl, the PRIMARY db must have a SYNCPROV and ACCESSLOG overlay defined. The ACCESSLOG db must have a SYNCPROV overlay defined and it MUST set olcSpNoPresent to TRUE and olcSpReloadHint to TRUE.
Also, overlay order matters. For any replicated database, the SYNCPROV overlay should always be in the {0} index slot (primary or accesslog db). If it is delta-syncrepl, the ACCESSLOG overlay should be in the {1} index slot on the primary db.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi Quanah,
Am 15.09.20 um 21:12 schrieb Quanah Gibson-Mount:
Also, overlay order matters. For any replicated database, the SYNCPROV overlay should always be in the {0} index slot (primary or accesslog db). If it is delta-syncrepl, the ACCESSLOG overlay should be in the {1} index slot on the primary db.
Ok, but is it somewhere written in the documentation? BTW I'm setting up a single-master not a multi-master-replication. I couldn't find anything about it in the official documentation :-(. As soon as I finished all the changes "I'll be back" :-)
Stefan
On 9/16/20 8:52 AM, Stefan Kania wrote:
Hi Quanah,
Am 15.09.20 um 21:12 schrieb Quanah Gibson-Mount:
Also, overlay order matters. For any replicated database, the SYNCPROV overlay should always be in the {0} index slot (primary or accesslog db). If it is delta-syncrepl, the ACCESSLOG overlay should be in the {1} index slot on the primary db.
Ok, but is it somewhere written in the documentation?
https://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl
This still describes static config (aka slapd.conf) but you can easily convert the example given with
slaptest -f slapd.conf -F /etc/openldap/slapd.d
to get a complete cn=config tree.
Ciao, Michael.
Hi Michael,
Am 16.09.20 um 09:04 schrieb Michael Ströder:
This still describes static config (aka slapd.conf) but you can easily convert the example given with
slaptest -f slapd.conf -F /etc/openldap/slapd.d
to get a complete cn=config tree.
I know that, but I wanted to know if it's written somewhere that the two parts of the delta-syncrepl-setup must be in a certain order.
On 9/16/20 9:07 AM, Stefan Kania wrote:
Am 16.09.20 um 09:04 schrieb Michael Ströder:
This still describes static config (aka slapd.conf) but you can easily convert the example given with
slaptest -f slapd.conf -F /etc/openldap/slapd.d
to get a complete cn=config tree.
I know that, but I wanted to know if it's written somewhere that the two parts of the delta-syncrepl-setup must be in a certain order.
I vaguely remember that sigificance of overlay order is documented. And this of course affects syncprov and accesslog overlays. But as usual there are many opportunities to improve docs and I guess pull requests are welcome to make this more explicit.
Ciao, Michael.
--On Wednesday, September 16, 2020 9:52 AM +0200 Stefan Kania stefan@kania-online.de wrote:
Hi Quanah,
Am 15.09.20 um 21:12 schrieb Quanah Gibson-Mount:
Also, overlay order matters. For any replicated database, the SYNCPROV overlay should always be in the {0} index slot (primary or accesslog db). If it is delta-syncrepl, the ACCESSLOG overlay should be in the {1} index slot on the primary db.
Ok, but is it somewhere written in the documentation? BTW I'm setting up a single-master not a multi-master-replication. I couldn't find anything about it in the official documentation :-(. As soon as I finished all the changes "I'll be back" :-)
The above notes apply to any replication configuration on a provider, whether that is multiprovider or single node provider.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Am 16.09.20 um 09:35 schrieb Michael Ströder:
But as usual there are many opportunities to improve docs and I guess pull requests are welcome to make this more explicit.
As soon as my Ansible-script is running, I will write the documentation and if it is interesting for the project it could be part of the documentation. At least I will post it here.
Stefan
Now it works :-) Thanks for the help. Some problems had been in front of the monitor and some problem Ansible specific. Just do verify, here is my configuration:
first the provider: ------------------------- dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapmaster-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapmaster-key.pem olcToolThreads: 1
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_mdb olcModuleLoad: {1}syncprov.la olcModuleLoad: {2}accesslog.la olcModuleLoad: {3}back_monitor
dn: cn=schema,cn=config objectClass: olcSchemaConfig
....
dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 300
dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 01+00:00 00+04:00 olcAccessLogSuccess: TRUE
dn: olcDatabase={2}Monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}Monitor olcAccess: {0} to dn.subtree="cn=monitor" by dn.exact="cn=ldap-admin,ou=users, dc=example,dc=net" read
dn: olcDatabase={3}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: {3}mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcAccess: {0} to dn.sub=cn=accesslog by dn.exact=cn=repl-user,ou=users,dc=exa mple,dc=net read by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net read olcLastMod: TRUE olcReadOnly: FALSE olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbCheckpoint: 0 0 olcDbIndex: reqStart,reqEnd,reqDN,reqResult,entryCSN,objectClass eq olcDbMode: 0600 olcDbSearchStack: 16
dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE -------------------------
Now one of the consumers: ----------------------------- dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapslave-01-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapslave-01-key.pem olcToolThreads: 1
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_mdb olcModuleLoad: {1}back_monitor
dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema ...
dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcSyncrepl: {0}rid=1 provider=ldaps://ldapmaster.example.net type=refreshAndP ersist retry="5 5 300 +" filter="(ObjectClass=*)" scope=sub bindmethod=simple searchbase="dc=example,dc=net" binddn="cn=repl-user,ou=users,dc=example,dc=n et" credentials=geheim syncdata=accesslog logbase="cn=accesslog" logfilter="( &(objectClass=auditWriteObject)(reqResult=0)) olcUpdateRef: ldaps://ldapmaster.example.net olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824
dn: olcDatabase={2}Monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}Monitor olcAccess: {0} to dn.subtree="cn=monitor" by dn.exact="cn=ldap-admin,ou=users, dc=example,dc=net" read
-----------------------------
For me the biggst problem was to put the setup into Ansible-roles. Ansible is creating for every change a singe task, to setup TLS there is one task for the tls-key and one task for the tls-certificate. The first task is configuring the key and then slapd reeeds the configuriation and is running into an error because the certificate is missing then the task for putting the certificate into the configuration. So Ansible must be configured to ignore the error end then rerun the tasks.
Another problem was, that the ldap_entry module from Ansible is creating a new accesslog-db everytime the playbook is running. The module is not looking if the databes exists.
After I got it finaly running I got the slapd-error 53 that the consumer is newer then provider, that was because Ansible is running task on all ldap-server parallel so it can hppend that the consumers will be created befor the provider, so I had to stop the consumers, delete the dab-files and restart the service befor starting the replication.
Now I will put some more commends into my ansible-roles and write a litte docomentation on it. A soon as I'm finished I will post a link.
Again thank's for your help
Stefan
Am 15.09.20 um 21:12 schrieb Quanah Gibson-Mount:
--On Tuesday, September 15, 2020 1:10 PM -0700 Quanah Gibson-Mount quanah@symas.com wrote:
To summarize:
For delta-syncrepl, the PRIMARY db must have a SYNCPROV and ACCESSLOG overlay defined. The ACCESSLOG db must have a SYNCPROV overlay defined and it MUST set olcSpNoPresent to TRUE and olcSpReloadHint to TRUE.
Also, overlay order matters. For any replicated database, the SYNCPROV overlay should always be in the {0} index slot (primary or accesslog db). If it is delta-syncrepl, the ACCESSLOG overlay should be in the {1} index slot on the primary db.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Sunday, September 20, 2020 5:29 PM +0200 Stefan Kania stefan@kania-online.de wrote:
first the provider:
dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
The above block is generally unnecessary (There is one config parameter in OpenLDAP 2.5 that requires being set in this block, but nothing in 2.4).
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500
You've set a server sizelimit of 500 entries, but you don't exclude the replication user from this limit in the primary db, which is invalid. The replication user *must* be able to read both the primary and accesslog db on the provider with no sizelimit or timelimit restrictions. You have set the limits to unlimited for the accesslog db, but haven't handled this for the primary db. See the limits/olcLimits directive for how to make it so specific user(s) bypass the server limit.
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb
olcDbCheckpoint: 512 30
As documented in the slapd-mdb(5) man page, the first value in the checkpoint parameter does nothing, you can leave it at 0.
olcSpSessionlog: 300
How many total entries do you have in your database? You generally need a sessionlog that can hold as many entries as you expect to be changed in case of a REFRESH fallback to avoid ITS#8125.
olcToolThreads: 1
Unless you're on a single core, single cpu system, you should set the tool threads to 2.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Am 21.09.20 um 22:09 schrieb Quanah Gibson-Mount:
--On Sunday, September 20, 2020 5:29 PM +0200 Stefan Kania stefan@kania-online.de wrote:
first the provider:
dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
The above block is generally unnecessary (There is one config parameter in OpenLDAP 2.5 that requires being set in this block, but nothing in 2.4).
Ok, but this is from the default setting of the debian packages
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500
You've set a server sizelimit of 500 entries, but you don't exclude the replication user from this limit in the primary db, which is invalid. The replication user *must* be able to read both the primary and accesslog db on the provider with no sizelimit or timelimit restrictions. You have set the limits to unlimited for the accesslog db, but haven't handled this for the primary db. See the limits/olcLimits directive for how to make it so specific user(s) bypass the server limit.
Yes, I know, in the final playbook I will set the limit for the repl-user and ldap-admin. First step was getting the playbook with delta-syncrepl running
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb
olcDbCheckpoint: 512 30
As documented in the slapd-mdb(5) man page, the first value in the checkpoint parameter does nothing, you can leave it at 0.
Ok, I change this too. This will be a variable to change in the final version
olcSpSessionlog: 300
How many total entries do you have in your database? You generally need a sessionlog that can hold as many entries as you expect to be changed in case of a REFRESH fallback to avoid ITS#8125.
This is just a testsetup it's managed via a variable that can be changed before running the playbook
olcToolThreads: 1
Unless you're on a single core, single cpu system, you should set the tool threads to 2.
It's just a singel-core vm an my system at home, this one will also be set via a variable in the final version.
Thank you for the hints.
Stefan
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Michael Ströder michael@stroeder.com schrieb am 16.09.2020 um 09:35 in
Nachricht 247a6843-dece-64e0-3587-c00c24801337@stroeder.com:
On 9/16/20 9:07 AM, Stefan Kania wrote:
Am 16.09.20 um 09:04 schrieb Michael Ströder:
This still describes static config (aka slapd.conf) but you can easily convert the example given with
slaptest -f slapd.conf -F /etc/openldap/slapd.d
to get a complete cn=config tree.
I know that, but I wanted to know if it's written somewhere that the two parts of the delta-syncrepl-setup must be in a certain order.
I vaguely remember that sigificance of overlay order is documented. And this of course affects syncprov and accesslog overlays. But as usual there are many opportunities to improve docs and I guess pull requests are welcome to make this more explicit.
The expert asking the novice to improve the docs... ;-)
Ciao, Michael.
On 9/29/20 11:09 AM, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 16.09.2020 um 09:35 in
Nachricht 247a6843-dece-64e0-3587-c00c24801337@stroeder.com:
But as usual there are many opportunities to improve docs and I guess pull requests are welcome to make this more explicit.
The expert asking the novice to improve the docs... ;-)
Sometimes it's better if a novice points out where he/she expected to read a certain text.
Ciao, Michael.
openldap-technical@openldap.org
-
Michael Ströder -
Quanah Gibson-Mount -
Stefan Kania -
Ulrich Windl