Migration from osixia to bitnami

[EugenMayer]

i have seen https://github.com/jp-gouin/helm-openldap?tab=readme-ov-file#to-400 but i'am not sure what the migration aspect is.

A assume the data-folder is not compatible at all, thus my suggestion would be

1. create an ldif of the current production server (bootstrap.ldif)
2. extract SSL/TLS keys
3. spawn this chart (in parallel to the current deployment as a new deployment) while:
   • using bootstrap.ldif as the bootstrap in /ldifs
     • one might need to add the creation of the main dcObject to the very top
   • adding the memberOf schem to /schema
   • configure the SSL/TLS certs and enable it
   • set LDAP_ROOT to the root used in your boostrap.lidf

Would that be your suggestion too? I assume this could be something that we could link to in the changelog guide as a starting point.

Thanks in any way

[jp-gouin]

Hi @EugenMayer , I've never tried it , maybe someone in the community has and can assist you.

I would recommend to do what you suggested but to manually load your bootstrap.ldif either by connecting into one pod or by using phpldapadmin. You initiate the openldap using the same global.ldapDomain has your previous instance from Osixia and that should be good.

Other idea is to separate schemas and data and to bootstrap the chart using customSchemaFiles and customLdifFiles depending on the size of your current base of course

[jp-gouin]

In any case, feel free to document your approach and add it as a migration guide , that would be very appreciated and helpful for anyone who need to perform the migration

[EugenMayer]

I will see what works best and try to update this ticket so other can have a blueprint or an idea of an blueprint/starting point. Thanks for your ideas, makes sense!

[EugenMayer]

I finished the migration today, so here is my roadmap:

1. Deploy this chart on alternative ports and get the base aspects working :

• Ensure the TLS setup works
• Ensure the schema is correctly deployed (memberOf based on unqiueMember, additional schema mailAccount which i was using)

2. I used Apache Directory Studio [be sure to notice the bug Problems with Apache Ldap Studio (bug) #212] to export an entire dump of the production LDAP as ldif

• tried to import that dump and learned about missing schemas and so forth and fixed those in the chart bootstrap. Be sure to always remove and redeploy the entire chart, since some aspects are only adopted during initial boostrap
• ensure computed attributes like memberOf match your prod expectation

3. Validation: Try some applications you run against LDAP on the new server on the alternative ports and ensure you get the right counts / connection is working
4. Final export/import of the LDIF and the deploy the old prod server on an alt port, then redeploy the new ldap server on the prod ports 389/636

I would keep the old prod server around until the new one has been battle proven and the remove the deployment entirely.

Hint: You should notice, if applications used the UUID of the entries for the relation, importing an LDIF will change those. So you might want to export the LDIF with operational attributes if you rely on those