On 6/27/17 4:55 PM, Quanah Gibson-Mount wrote:
> --On Tuesday, June 27, 2017 5:35 PM -0400 btb <btb(a)bitrate.net> wrote:
>
>> On 6/27/17 10:27 AM, Quanah Gibson-Mount wrote:
>>> --On Tuesday, June 27, 2017 10:37 AM -0400 btb <btb(a)bitrate.net> wrote:
>>>> i'm using 2.4.44 on freebsd, built from ports. i can provide any
>>>> config
>>>> details etc - i just didn't want to inundate the post with guesses on
>>>> detail that might not be relevant.
>>>
>>> What is your accesslog purge setting? Do you have long periods of time
>>> with no write activity?
>>
>> there are some extended periods of time with no write activity, yes.
>
> That's one form of a known issue then with using accesslog (ITS#8100).
> I've made a suggestion on how it could be fixed, and Howard agreed that
> would be the correct solution. Just need the fix. :)
>
> In the meantime, you can set up a cronjob that does a modify once a day
> on some object that doesn't really do anything, like if you had:
>
> dn: cn=someobject,dc...
> objectClass: ...
> cn: someobject
> description: blah
>
> you could have a job that does:
> dn: cn=someobject,dc...
> changetype: modify
> replace: description
> description: blah
>
> So it in effect does nothing, but it keeps an active change in the
> accesslog alive.
>
> Basically what happens with the accesslog empty is that it'll end up
> generating its own new contextCSN that differs for that server than the
> one stored in the rootDB, and will be /newer/ than it as well, which is
> why you get that message. You can also fix the problem simply by doing
> a modify on each master, and it'll reset the contextCSNs and things will
> flow (i.e., no need to do a dump/reload, etc).
i see, thanks. i tested this, and did a modify on each, but didn't see
replication resume. emulating the syncrepl connection with a manual
search against each master, there do seem to be accesslog entries now,
on both masters:
ldapsearch -ZZxWLLLH 'ldap://dsa1.example.org/' -D
'uid=dsa2_slapd-repl-content,ou=dsa2.example.org,ou=services,ou=accounts,cd=example,dc=org'
-b 'cn=accesslog' '(&(objectClass=auditWriteObject)(reqResult=0))' reqDN
reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Enter LDAP Password:
dn: reqStart=20170628033755.000000Z,cn=accesslog
reqType: add
reqDN: cn=project_management_users,ou=general,ou=groups,cd=example,dc=org
reqMod: member:+ uid=jdoe,ou=People,cd=example,dc=org
reqMod: member:+ uid=mkline,ou=People,cd=example,dc=org
reqMod: member:+ uid=astavins,ou=People,cd=example,dc=org
reqMod: cn:+ project_management_users
reqMod: objectClass:+ groupOfNames
reqMod: objectClass:+ top
reqMod: structuralObjectClass:+ groupOfNames
reqMod: entryUUID:+ ea9a8246-effe-1036-966a-9d166400a934
reqMod: creatorsName:+
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=or
g
reqMod: createTimestamp:+ 20170628033755Z
reqMod: entryCSN:+ 20170628033755.410123Z#000000#001#000000
reqMod: modifiersName:+
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o
rg
reqMod: modifyTimestamp:+ 20170628033755Z
entryCSN: 20170628033755.410123Z#000000#001#000000
dn: reqStart=20170628033931.000000Z,cn=accesslog
reqType: modify
reqDN: uid=jdoe,ou=People,cd=example,dc=org
reqMod: givenName:+ john
reqMod: entryCSN:= 20170628033931.892952Z#000000#001#000000
reqMod: modifiersName:=
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o
rg
reqMod: modifyTimestamp:= 20170628033931Z
entryCSN: 20170628033931.892952Z#000000#001#000000
dn: reqStart=20170628034017.000000Z,cn=accesslog
reqType: modify
reqDN: uid=jdoe,ou=People,cd=example,dc=org
reqMod: sn:= doe
reqMod: entryCSN:= 20170628034017.532972Z#000000#001#000000
reqMod: modifiersName:=
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o
rg
reqMod: modifyTimestamp:= 20170628034017Z
entryCSN: 20170628034017.532972Z#000000#001#000000
dn: reqStart=20170628034119.000000Z,cn=accesslog
reqType: modify
reqDN: uid=mkline,ou=People,cd=example,dc=org
reqMod: givenName:+ michael
reqMod: entryCSN:= 20170628034119.327974Z#000000#001#000000
reqMod: modifiersName:=
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o
rg
reqMod: modifyTimestamp:= 20170628034119Z
entryCSN: 20170628034119.327974Z#000000#001#000000
but the same log messages persist. what can i look at next? are these
the relevant contextcsn values?
dsa1 cn=accesslog:
20161019002438.652359Z#000000#000#000000
20170521175113.974560Z#000000#002#000000
20170530214415.204052Z#000000#001#000000
dsa1 dc=example,dc=org:
20170520031415.276678Z#000000#000#000000
20170530214231.171959Z#000000#002#000000
20170530214415.204052Z#000000#001#000000
dsa2 cn=accesslog:
20170520031415.276678Z#000000#000#000000
20170521175113.974560Z#000000#002#000000
20170628034119.327974Z#000000#001#000000
dsa2 dc=example,dc=org:
20170520031415.276678Z#000000#000#000000
20170619014933.531051Z#000000#002#000000
20170628034119.327974Z#000000#001#000000
if it might be of value, here are the olcsyncrepl attributes from each
master:
dsa1:
{0}rid=000
provider=ldap://dsa2.example.org/
starttls=critical
tls_cacert=/usr/local/etc/pki/trusted_root_authorities/root_ca-cert.pem
bindmethod=simple
binddn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,cd=example,dc=org"
credentials="xxxxxxxxxxxxxxxxxxxxxx"
searchbase="dc=example,dc=org"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="15 +"
syncdata=accesslog
dsa2:
{0}rid=000
provider=ldap://dsa1.example.org/
starttls=critical
tls_cacert=/usr/local/etc/pki/trusted_root_authorities/root_ca-cert.pem
bindmethod=simple
binddn="uid=dsa2_slapd-repl-content,ou=dsa2.example.org,ou=services,ou=accounts,cd=example,dc=org"
credentials="xxxxxxxxxxxxxxxxxxxxxx"
searchbase="dc=example,dc=org"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="15 +"
syncdata=accesslog
thanks
-ben
Cool, I'm getting there! Unfortunately and for good reasons the creator
of ae-dir.com
has restricted modifying access for config (in order to tightly control
runtime config state).
So this is how far as I get:
```
[nix-shell] ➜ aedir-ldap.k8s git:(da-openldap-base) ✗ just mprovider
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /var/run/certs/svid.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /var/run/certs/svid_key.pem
modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
additional info: operation restricted
command terminated with exit code 53
error: Recipe `mprovider` failed with exit code 5
```
Furthermore, would this dummy change also reload the certificates that
are configured for the syncrepls?
See:
```
dn: olcDatabase={2}mdb,cn=config
olcSyncrepl: rid=001
provider=<ldaps://aedir-0.aedir.aedir-provider.svc.cluster>
.local bindmethod=sasl timeout=5 network-timeout=5 saslmech=EXTERNAL
keepaliv
e=240:10:30 starttls=no tls_cert="/var/run/certs/svid.pem"
tls_key="/var/run/
certs/svid_key.pem" tls_cacert="/var/run/certs/svid_bundle.pem"
tls_reqcert=d
emand
tls_cipher_suite=ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:
ECDH-RSA-AES256-GCM-SHA384:!ADH tls_protocol_min=3.3 tls_crlcheck=none
filter
="(objectClass=*)" searchbase="ou=ae-dir" scope=sub attrs="*,+"
schemacheckin
g=on type=refreshAndPersist retry="30 +"
```
I'm starting to think plain process signalling for reloading the TLS
context would actually be a cleaner, more elegant and stable solution.
Would you be ok if I opened an issue for that?
On Fri, Aug 21, 2020 at 12:00, Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
>
>
> --On Friday, August 21, 2020 2:56 PM -0500 David Arnold
> <dar(a)xoe.solutions <mailto:dar@xoe.solutions>> wrote:
>
>> Since the paths don't actually change (and I have no means to make
>> them
>> change), can I do a dummy modification that would trigger cert
>> reloading?
>
> Yeah, just do a replace op, like:
>
> ldapmodify ...
> dn: cn=config
> changetype: modify
> replace: olcTLS..
> olcTLS...: original value
>
> For the slapd.conf configuration to enable the cn=config db just have:
>
> database config
> rootpw somepassword
>
> and then you can bind to it w/ that password. Alternatively, you can
> set up an authz-regexp, etc.
>
>
> Regards,
> Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com <http://www.symas.com/>>
Forgive me if pasting here is bad etiquette.
<consumer slapd.conf>
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/samba.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
TLSCACertificateFile /etc/openldap/cacerts/cavictory2.crt
TLSCertificateFile /etc/openldap/keys/victory3cert.pem
TLSCertificateKeyFile /etc/openldap/keys/victory3key.pem
database hdb
suffix "dc=srg,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=srg,dc=com"
rootpw {MD5}blah
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
syncrepl rid=0
provider=ldap://victory2.srg.com:389
bindmethod=simple
starttls=critical
binddn="cn=replicator,dc=srg,dc=com"
credentials=blah
searchbase="dc=srg,dc=com"
logbase="cn=accesslog"
schemachecking=on
type=refreshAndPersist
retry="60 +"
syncdata=accesslog
updateref ldaps://victory2.srg.com
database monitor
access to *
by dn.exact="cn=Manager,dc=srg,dc=com" write
by * none
</consumer slapd.conf>
--- On Thu, 8/20/09, Jonathan Clarke <jonathan(a)phillipoux.net> wrote:
> From: Jonathan Clarke <jonathan(a)phillipoux.net>
> Subject: Re: top-level data entries not replicating, 2.4.15
> To: "Brian Neu" <proclivity76(a)yahoo.com>
> Cc: openldap-technical(a)openldap.org
> Date: Thursday, August 20, 2009, 8:02 AM
> On 19/08/2009 19:29, Brian Neu
> wrote:
> > Even with no logfilter on the consumer,
> >
> cn=replicator,dc=domain,dc=com&
> >
> sambaDomainName=SRG,dc=domain,dc=com
> >
> > don't replicate, even after wiping the database and
> restarting. Everything else seems to replicate fine.
> >
> > How do I get top-level data entries to replicate?
>
> This really depends on your syncrepl configuration on the
> consumer.
> If you provide it here, maybe we can take a look.
>
> Aside from that, the latest version, 2.4.17, contains a few
> fixes that
> might help with this problem.
>
> Jonathan
>
Openldap version 2.4.35
Our global ldap server has the following naming contexts:
namingContexts: o=global,ou=studios,dc=methodstudios,dc=net
namingContexts: o=chi01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=det01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=la01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=ny01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=lon01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=van01,ou=studios,dc=methodstudios,dc=net
namingContexts: ou=studios,dc=methodstudios,dc=net
namingContexts: ou=login,dc=methodstudios,dc=net
ou=studio,dc=methodstudios,dc=net is the superior database and global,
chi01, det01, la01, ny01, lon01, van01 are all have "subordinate
advertise" and are all sync providers.
The sync provider:
database mdb
suffix "ou=studios,dc=methodstudios,dc=net"
rootdn ...
rootpw ...
directory /var/lib/ldap/studios.methodstudios.net
maxsize 17179869184
serverID 201
overlay glue
overlay syncprov
syncprov-reloadhint TRUE
syncprov-checkpoint 100 5
sync_use_subentry true
...
The sync consumer only has a database for
ou=studios,dc=methodstudios,dc=net.
database mdb
suffix "ou=studios,dc=methodstudios,dc=net"
rootdn ...
rootpw ...
directory /var/lib/ldap/studios.methodstudios.net
maxsize 17179869184
serverID 202
syncrepl rid=201 provider=ldap://<providor host name>
type=refreshAndPersist retry="60 10 300 +"
searchbase="ou=studios,dc=methodstudios,dc=net"
bindmethod=simple starttls=yes
binddn="..."
credentials=... schemachecking=off
sizelimit=unlimited timelimit=unlimited
updateref ldap://<providor host name>
It seems to be only syncing ou=studios,dc=methodstudios,dc=net and
o=global,ou=studios,dc=methodstudios,dc=net. If I change the order of
the provider server so that chi01 comes before global then only syncing
ou=studios,dc=methodstudios,dc=net and
o=chi01,ou=studios,dc=methodstudios,dc=net get sync.
Am I doing anything obviously wrong?
--
Robert Minsk
Systems and Software Engineer
WWW.METHODSTUDIOS.COM <http://www.methodstudios.com>
730 Arizona Ave, Santa Monica, CA 90401
O:+1 310 434 6500 <tel:+13104346500> // F:+1 310 434 6501
<tel:+13104346501>
Los Angeles
<http://www.methodstudios.com/signature/url/los-angeles><http://www.methodstudios.com/signature/url/los-angeles>
This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.
Hi all,
Wow, it seems to be done ;-)
To put it in a nutshell:
- apt-get purge MIT-Kerberos*
- apt-get install Heimdal*
- tried and failed, tried and failed, ...
- apt-get purge heimdal*, cyrus*, openldap*
- apt-get libssl-dev and libdb dev packages
- got cyrus, openldap and heimdal tarballs
- configured, compiled, tested, failed, configured, compiled,
tested, failed, conf.......... ...... ......
... --- ... ... --- ...
configured, compiled, succeeded!
- Followed well known configuration instructions
Voila!
ldapsearch -Y GSSAPI works
ldaps works
(without client verification, did not solve that yet,
server verification works fine)
login with kerberos authentication works
(with proxy ticket for the machine, this way I
avoid having PLAIN username/password send to slapd)
su, id, etc. works
Seems, as if doing it by hand is still the best way ;-)
Thanks again for your help,
Hauke
----- Ursprüngliche Mail -----
Von: "Quanah Gibson-Mount" <quanah(a)zimbra.com>
An: "Hauke Coltzau" <hauke.coltzau(a)FernUni-Hagen.de>
CC: openldap-software(a)openldap.org
Gesendet: Montag, 8. September 2008 21:44:16 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: Re: AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
--On Monday, September 08, 2008 9:26 PM +0200 Hauke Coltzau
<hauke.coltzau(a)FernUni-Hagen.de> wrote:
> ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-18ubuntu2 \\
> Cyrus SASL - pluggable authentication module
I would highly recommend using Heimdal on the master side. But that's up
to you. ;)
> - In the first approach, the user already has a TGT and asks the KDC for
> a "ldap/fqdn@REALM-ticket"? This is done by ldapsearch, not by slapd?
> Hence, slapd "only" needs access to its keytab to be able to decrypt the
> clients messages?
I believe that is correct, yes. At Stanford, I had to point slapd at the
keytab in a shell script, but I believe that was because I was using
SASL/GSSAPI to do replication as well. It's been a while. ;)
> - And in the second one, the user provides username and password (plain),
> slapd converts the username into a principle (user@REALM) and forwards
> this to saslauthd? So this should be secured via TLS?
You can try securing it via startTLS, but nothing blocks a user from still
doing it in the clear, unfortunately (i.e., you can reject the non-secured
bind, but they'll have already sent their credentials, so anyone sniffing
would be able to get them).
> There used to be a well-known howto for all this at
> http://www.bayour.com/LDAPv3-HOWTO.html but the site is offline for some
> days now.
This howto is completely wrong, and the various folks have asked the author
to take it down for years. I'm glad to hear it is not accessible.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
Hello,
To start with, this is my very first post on a mailing list of this kind.
I've read much about how to do things right, like here:
https://www.openldap.org/doc/admin24/troubleshooting.html or here:
https://www.openldap.org/faq/data/cache/59.html
Nonetheless, please do tell me if I'm not following the standards.
I'm facing an issue with my OpenLDAP servers that I struggle to fix or even
find info about.
To summarize:
We have an architecture of 2 providers with mirror mode replication for
their configuration. They are LXC's hosted in a datacenter.
We have 2 consumers with mirror mode replication for their config also, and
they get the DB (mdb backend) from the above providers. They are VMs hosted
in a different hypervisor and datacenter than the providers.
We have a loadbalancing architecture in front that sends requests evenly to
the 4 servers. The writes requests directed to the consumers are forwarded
to the providers using the chain overlay.
The slapd process of those 2 consumers randomly hangs. When it happens, the
slapd service is still running and listening, but not a single query can go
through, even the logging stops. Like a complete freeze. The service comes
back to life after some time (several minutes, different every time)
without any manual intervention. Trying to manually restart the process
during such even obviously fails, unless I kill -9, which is not something
I want to do.
My observations so far :
- The hangs appear only during business hours (nothing during nights or
week-end).
- Only the consumers hang. The providers are always fine.
- CPU / RAM / Disks are fine before / during the crashes.
- The hangs seem random and I could not find a way to trigger them at will.
- strace shows the following lines in an infinite loop during hangs.
```
[pid 1082] gettimeofday({tv_sec=1726669191, tv_usec=694473}, NULL) = 0
[pid 1082] poll([{fd=18, events=POLLIN|POLLPRI}], 1, 100) = 0 (Timeout)
[pid 1082] sched_yield()
```
It seems that the process is waiting for some data that never comes.
The fd=18 is referencing to a TCP socket connected to provider1. So it
would suggests that the provider is not sending what the consumer wants.
This has led me to several suppositions:
1. Network issues
Unlikely, since only those 2 servers in the DC are experiencing
misbehavior, and I can telnet / ldapsearch from the faulty consumer to the
provider with no problem during hangs.
2. Syncrepl / slapo-chain misconfiguration
I might have a configuration problem, but no matter how much I review it, I
don't see what's wrong. I've provided the syncrepl / slapo-chain conf in
the config.ldif attachment.
I've also provided several other attachments that I thought would be
helpful:
- log.txt => The slapd logs in trace level that show the last bind before
the service hangs.
- ldaps_request.log => An ldapsearch performed against the faulty consumer
during hang.
- starttls_request.log => Same as above, but using StartTLS => the
connection seems successful and stops at the server hello TLS exchange.
Versions :
- slapd: 2.5.18 LTS
- Server: Ubuntu 22.04 LTS
I am a bit out of ideas on things I could try to fix the issues. Hence this
email.
I thank you for your time and I am very grateful for any help you could
give me.
Regards,
Pierre-Jean
On 24/08/2009 14:16, Jonathan Clarke wrote:
> On 20/08/2009 14:39, Brian Neu wrote:
>> Forgive me if pasting here is bad etiquette.
>>
>>
>> <consumer slapd.conf>
>>
>> include /etc/openldap/schema/corba.schema
>> include /etc/openldap/schema/core.schema
>> include /etc/openldap/schema/cosine.schema
>> include /etc/openldap/schema/duaconf.schema
>> include /etc/openldap/schema/dyngroup.schema
>> include /etc/openldap/schema/inetorgperson.schema
>> include /etc/openldap/schema/java.schema
>> include /etc/openldap/schema/misc.schema
>> include /etc/openldap/schema/nis.schema
>> include /etc/openldap/schema/openldap.schema
>> include /etc/openldap/schema/ppolicy.schema
>> include /etc/openldap/schema/collective.schema
>> include /etc/openldap/schema/samba.schema
>>
>> allow bind_v2
>>
>> pidfile /var/run/openldap/slapd.pid
>> argsfile /var/run/openldap/slapd.args
>>
>> TLSCACertificateFile /etc/openldap/cacerts/cavictory2.crt
>> TLSCertificateFile /etc/openldap/keys/victory3cert.pem
>> TLSCertificateKeyFile /etc/openldap/keys/victory3key.pem
>>
>> database hdb
>> suffix "dc=srg,dc=com"
>> checkpoint 1024 15
>> rootdn "cn=Manager,dc=srg,dc=com"
>>
>> rootpw {MD5}blah
>>
>> directory /var/lib/ldap
>>
>> index objectClass eq,pres
>> index ou,cn,mail,surname,givenname eq,pres,sub
>> index uidNumber,gidNumber,loginShell eq,pres
>> index uid,memberUid eq,pres,sub
>> index nisMapName,nisMapEntry eq,pres,sub
>>
>> syncrepl rid=0
>> provider=ldap://victory2.srg.com:389
>> bindmethod=simple
>> starttls=critical
>> binddn="cn=replicator,dc=srg,dc=com"
>> credentials=blah
>> searchbase="dc=srg,dc=com"
>> logbase="cn=accesslog"
>> schemachecking=on
>> type=refreshAndPersist
>> retry="60 +"
>> syncdata=accesslog
>
> I don't see anything wrong with this - although I'm not very familiar
> with accesslog configuration.
>
> Does the "cn=replicator,dc=srg,dc=com" have full access on the provider
> to read necessary data?
Please ignore this post - I hadn't seen that the discussion continued
already. My mailer displayed it in a separate post, got me confused on a
Monday morning :/