Best way two update a full OpenLDAP database from LDIF file
by Prunk Dump
Hello !
My network infrastructure uses some special database not compatible
with LDAP. But I need an OpenLDAP server to administer my Web Services
accounts on my DMZ.
So I have written a script to export our "special" database to an LDIF
file. This works pretty well. I've successfully loaded it on my
OpenLDAP server.
But now I don't know how to update my OpenLDAP database from the new
generated LDIF files (when users are added, updated or removed)
without disturbing the whole LDAP service (it's not a very good idea
to delete the entire database and recreate it from the new LDIF file
as it stop the service completely during the operation).
Is there a way to update an OpenLDAP database to fit a new given LDIF file ?
-> Updating/deleting the OUs
-> Deleting the objects that are not present.
-> Deleting the attributes removed.
-> Updating the attributes that have changed without deleting the object.
Doing this step by step to disturb as little as possible the OpenLDAP service.
Thanks for the help.
Regards,
Baptiste.
1 year, 3 months
Re: Upgrade from 2.4.44 to 2.4.55
by Quanah Gibson-Mount
--On Friday, February 5, 2021 10:51 AM -0800 rammohan ganapavarapu
<rammohanganap(a)gmail.com> wrote:
>
>
> We use centOS 7 and rely on base repo.
>
>
> openldap-servers-2.4.44-22.el7.x86_64 : LDAP server
> Repo : base
>
>
>
> openldap-servers-2.4.44-21.el7_6.x86_64 : LDAP server
> Repo : @base
Symas provides free drop in replacments for the ancient version of OpenLDAP
shipped with RHEL7:
<https://repo.symas.com/sofl/rhel7/>
I suggest using them.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1 year, 3 months
Re: Upgrade from 2.4.44 to 2.4.55
by Quanah Gibson-Mount
--On Friday, February 5, 2021 10:20 AM -0800 rammohan ganapavarapu
<rammohanganap(a)gmail.com> wrote:
>
>
> Quanah,
>
>
> We use binaries from OS distribution / repos, i mean do say can i
> directly do an inplace upgrade from 2.4.44 to latest version or do i need
> to worry about OS related libraries?. Since 2.4.57 is a very young
> release I wanted to play safe :) but eventually we will upgrade to .57.
> Also if my current installation is using bdb/hdb can i still continue
> with those backends with the latest version? If i want to migrate from
> bdb/hdb to mdb when upgrading, are there any migration processes for that?
What distribution are you using?
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1 year, 3 months
Context CSN timestamp
by Frédéric Goudal
Hello,
I have a strange problem of synchronization, since yesterday my slave servers have a small difference of 2 or 3 minutes with the master. I mean the context CSN of the slave is 3 mn earlier than contextCSN of the master.
My first question is the following : how the timestamp of the contextCSN of the slave is computed ? Is it a copy of the tilmestamp from the master ? Or is it based on the localtime of the slaves ?
My second question is that maybe such a small difference is « normal » (as the contextCSN of slave is progressing that means that replication is not fully stopped just a bit delayed) and I should only worry for a greater difference of time than one minute.
Thanks in advance.
Fred
1 year, 3 months
Re: Upgrade from 2.4.44 to 2.4.55
by Quanah Gibson-Mount
--On Thursday, February 4, 2021 5:03 PM -0800 rammohan ganapavarapu
<rammohanganap(a)gmail.com> wrote:
>
>
> Is there any upgrade process to upgrade from 2.4.44 to 2.4.55 ?
You should upgrade to 2.4.57. I'm not sure what you mean as far as
"upgrade process". Are you using binaries you built yourself? Binaries
from a distribution? etc.
Generally new dot releases are simply a drop in replacement.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1 year, 3 months
ldapmodify: wrong attributeType at line N
by Harri T.
Hi
Updating the user attribute "shadowWarning" works fine:
# cat tmp4.ldif
dn: uid=john,ou=People,dc=example,dc=com
changetype: modify
replace: shadowWarning
shadowWarning: 7
# ldapmodify -H ldapi:/// -D cn=admin,dc=example,dc=com -w ******** -f tmp4.ldif
modifying entry "uid=john,ou=People,dc=example,dc=com"
When I add the attribute "mail" into ldif the update fails:
# cat tmp3.ldif
dn: uid=john,ou=People,dc=example,dc=com
changetype: modify
replace: shadowWarning
shadowWarning: 7
replace: mail
mail: john.doe(a)example.com
# ldapmodify -H ldapi:/// -D cn=admin,dc=example,dc=com -w ******** -f tmp3.ldif
ldapmodify: wrong attributeType at line 5, entry "uid=john,ou=People,dc=example,dc=com"
What's wrong with the file tmp3.ldif?
Kind regards,
Harri
1 year, 3 months
Multi-master provider and delta syncrepl
by paul.jc＠yahoo.com
Hi all,
We are setting up multi-master (3 providers) and are curious if it is recommended to use delta syncrepl between the providers vs standard sync.
Currently, we have delta-sync set up between consumers and our single provider. Are there any gotchas with using delta syncrepl for provider-provider replication?
I am curious if a new provider is added, does/should the accesslog db get sync'd as well, or does each provider get its own unique accesslog db? And if each accesslog db is unique, how do consumers using delta syncrepl deal with a provider that has sync'd the change in its main db but not in the accesslog? Is this a non-issue if all consumers are aware of all providers and would that mean all consumers have to sync from all providers? I'm sure the answer to this is clear but I am missing it in the docs. Any input or clarification is appreciated.
Thanks!
Paul
1 year, 3 months
Unable to bind with LDAP DN having encoded chars
by radiatejava
I am using openldap client library 2.4.44 on Centos 7.3, LDAP v3
setting. I am having an issue with LDAP bind when the DN has encoded
representation of special characters like é (e acute). Actual DN is
CN=mithun,OU=Groupes de Sécurité,DC=mytest,DC=net and when it is sent
by the app (frontend) to our backend, it is coming as
CN=mithun,OU=Groupes de S\u00e9curit\u00e9,DC=insaaadev,DC=net.
Basically, é comes encoded as \u00e9 which is as per the encoding
mentioned here https://www.fileformat.info/info/unicode/char/e9/index.htm
To further try out, I directly hardcoded the DN to
CN=mithun,OU=Groupes de S\u00e9curit\u00e9,DC=mytest,DC=net and that
worked fine. I want to understand why it fails when the DN in the same
format comes from the frontend app. Appreciate your help, thanks.
1 year, 3 months
Backup/Restore Overlays MemberOf
by Lars Päßler
Hello,
I am running OpenLDAP 2.4.47 on Debian 10 for a while and now I enabled
the overlay for memberOf. Is there any good option for backup and
restore, because slapcat and slapadd aren't working.
Thanks and kind regards
Lars
1 year, 3 months
