backup and restore LDAP with samba and tls

I’ve a small number of servers with samba & ldap (amongst other stuff) and I had a difficult job getting the two working together when I upgraded to 13.1 (mainly because of TLS stopping smooth communication - some services connected some didn’t). The switch to 13.2 was fairly smooth, but now I need to go to Leap 42.2, which is a big step :frowning:

I think the simplest route is going to be to backup the LDAP database, save a copy of the samba configs, delete those config files / directories / databases, do the upgrade (and if necessary reinstall LDAP & samba & associated bits to force creating of empty config files), then reload LDAP from the first backup and recreate the samba shares by hand.

Can anyone comment / advise, especially on two points:

  1. the right / best software to dump and restore the LDAP database and
  2. where is the LDAP database so i can whack it before upgrading?

I assume I need to do the LDAP server before anything else.

Should I be forcing a password change after the move to Leap 42.2, i.e. is the encryption improved (or the old encryption insecure)?

Thanks for any advice / guidance …


I don’t know whether your approach can be recommended.

The way I was taught is that if you want to “backup” anything related to LDAP, you simply create a new instance/machine which has that role…

So, just add a new DC.
Or a new DNS.
Or, a new DHCP.
Or a new machine with those file shares… Although typically the IDs change so that you have to re-make connections to resources even if they have the same names (Hint: Don’t even try to use the same name because it can create confusion. Just re-create the clients’ shares with the new locations).

If you have a specific role or resource you’re concerned about, post the details.

And, don’t be afraid to use virtual machines instead of installing directly on metal.
Virtualization eases everything, including management, configuration, replication, migration, more. because you can turn on new machines (or join to the network) as you retire the old machines.

The alternative for very few machines is to just do in-place upgrades, but there is a lot more risk and recovery involved, and likely downtime which wouldn’t be the case if you do the “Add and join more machines” approach I described.

Whichever approach you decide on, if you decide also to upgrade your LDAP, there will likely be unique issues involved there as well.

Remember also that if your network is extremely tiny (eg 1 or 2 servers with few configured resources), then it might even be easier to forget about any upgrading and migration, just build new and then join your clients to your new LDAP network. In this case file shares should not be that big a deal but you may need to take a very close look at applications (like a mail server or proxy firewall that uses LDAP authentication), particularly if LDAP accounts are tied to data in a database (like a mail store).


Thanks. I think that, as part of the upgrade 13.2 -> 42.2, I’m going to get a new version of LDAP :slight_smile:

I’ve been moving towards VMs, so maybe now’s the right time to bite the bullet. As you suggest, create a new VM rather than upgrade the old server …