Upgrading a Samba AD DC

Revision as of 05:16, 25 July 2019 by Timbeale (talk | contribs) (Before you upgrade)

Run the following steps when you are updating a Samba Active Directory (AD) domain controller (DC).


Before you upgrade

  • Read the release notes of skipped versions. They contain important information, such as new features, changed parameter, and bug fixes. In case you switch to new major release, read the release notes of the initial version (x.y.0) and the ones from minor versions up to the new version you will update to. For example, if you update from 4.4.4 to 4.6.2, read the 4.5.0, 4.6.0, 4.6.1, and 4.6.2 release notes.
  • Get the latest version of Samba:
    • If you compile Samba from the sources, use the same configure options as used for your previous version. For more information, see Build Samba From the Sources.
    • If you update using packages, read the distribution documentation for information how to update.


Upgrading in-place

  • Stop all Samba services.
  • Install the latest packages over your existing ones.
  • Start the samba daemon.
  • Check your Samba log files for errors.
  • Test the Samba services work on your updated installation, e.g. verify users can login successfully via the upgraded DC.


Updating Multiple Samba Domain Controllers

If you are updating multiple Samba AD DCs, it's recommended to mitigate the risk of data loss by following this process:

  • Update one Samba AD DC that does not hold any flexible single master operations (FSMO) role, or else the DC with the least roles.
    • For upgrading to a new minor release, simply use the 'in-place upgrade' steps above.
    • For upgrading to a new major release, we recommend using the 'DC rejoin' steps below.
  • Start Samba on the updated DC.
  • Verify that the directory replication between all DCs is working correctly using: samba-tool drs showrepl
  • Test the installation to ensure that the new version works correctly.
  • Upgrade all other Samba DCs one at a time, with those holding FSMO roles last, and always verify that the replication is working correctly.

This method ensures that if any of the DCs have issues with the new version, you can find out with a joined DC rather than the master. If the issue can't be fixed easily, you can return to an earlier version on the joined DC without network downtime or risk of data loss.

Rejoining the upgraded DC

For major Samba version upgrades (e.g. v4.10 to v4.11) we recommend rejoining the upgraded DC. This is the most reliable approach for AD database compatibility. The steps are:

  • Stop all Samba services.
  • Install the latest packages over your existing ones.
  • Run the samba-tool domain join <realm> dc command to rejoin the upgraded DC to the domain. This uses DRS replication to completely rebuild the DC's local database.
    • Try to use the same command options as you did when you originally joined the DC.
  • Start the samba daemon.
  • Check your Samba log files for errors.
  • Test your updated installation, e.g. verify users can login successfully.


Downgrading

If you need to downgrade between major Samba releases (e.g. v4.11 to v4.10) please read Downgrading an Active Directory DC carefully.

Samba AD DC Database Check

The samba-tool utility enables you to detect and fix problems in the Samba AD database. For example, if a previous Samba version stored an attribute incorrectly and the updated version fixes the problem. You must run the check and fix command on every Samba AD DC locally, because some fixes apply to non-replicated attributes and modifications are not replicated to other DCs.

To check the AD database, run:

# samba-tool dbcheck --cross-ncs

To fix reported errors, run:

# samba-tool dbcheck --cross-ncs --fix

If you pass the --yes parameter to the command, all questions are automatically answered with yes. Note that if you omit the --yes parameter, the database check executes three fsync() calls for each object. This can result in a longer run duration. For example, passing the --yes parameter to the command fixed 3500 objects in 10 seconds in our test environment. Without this parameter, the command required 4:50 minutes for the same operation.

After a repair, re-check the database to verify a successful operation.