Problem mit Backup-DC bei Samba-4-Installation

Hi,

ich habe auf einem Backup-DC das Paket “AD kompatibler DC” installiert und erhalte nun bei 2 Join-Skripten diese Fehler:

RUNNING 96univention-samba4.inst 2016-06-17 16:03:57.035527337+02:00 (in joinscript_init) ERROR: It is not possible to install a samba 4 domaincontroller into a samba 3 environment. EXITCODE=1 RUNNING 97univention-s4-connector.inst EXITCODE=already_executed RUNNING 98univention-pkgdb-tools.inst EXITCODE=already_executed RUNNING 98univention-samba4-dns.inst 2016-06-17 16:03:57.548040186+02:00 (in joinscript_init) Samba4 backend database not available yet, exiting joinscript 98univention-samba4-dns. EXITCODE=1

Ich weiß nicht, wieso er glaubt, dass es sich um eine Samba-3-Domäne handelt.
Auf dem Master war ursprünglich Samba 3 installiert, aber es wurde vor ca. einem Jahr erfolgreich auf Samba 4 migriert.

Woran könnte das liegen?

Am Master ist der Join-Status ok.

LG,
Roland.

Hallo,

die entsprechende Stelle im Join-Skript 96univention-samba4.inst sieht so aus:

s3setup="$(ldapsearch -x -ZZ -D "$ldap_hostdn" -y /etc/machine.secret \
                   '(&(univentionService=Samba 3)(objectClass=univentionDomainController))' -LLL dn \
                   | ldapsearch-wrapper | sed -ne 's|dn: ||p')"
if [ -n "$s3setup" ] && is_domain_controller; then

[...]
                # Try to install a S4 DC in a S3 environment ...
                echo "ERROR: It is not possible to install a samba 4 domaincontroller "
                echo "       into a samba 3 environment."
                exit 1
[...]
fi

Ich gehe davon aus, dass an einem der Domain Controller noch Samba 3 als Dienst hinterlegt ist (univentionService=Samba 3). Wenn die Migration auf Samba/AD erfolgreich war, sollte es ausreichen den Dienst “Samba 3” am Rechnerobjekt zu entfernen.
Das zweite Join-Skript 98univention-samba4-dns.inst setzt voraus, dass 96univention-samba4.inst erfolgreich durchgelaufen ist und sollte dann im Anschluss auch keine Probleme mehr machen.

Schönen Gruß,
Michael Grandjean

Danke für den Hinweis.
Ich habe es inzwischen in einer Testumgebung mit diesem Befehl hinbekommen:

ucr set samba4/ignore/mixsetup=yes

Danach liefen die Join-Skripte problemlos durch.

Ich werde ihre Variante auch noch ausprobieren.

Mit dem Löschen des Samba-3-Dienstes hat es ebenfalls funktioniert.

Dennoch werde ich in der Produktiv-Umgebung die Mix-Setup-Variable verwenden. Bei dem Kunden haben wir ziemlich lange gebraucht, um seine SLES-Maschine mit Samba an unser UCS anzubinden.
Da möchte ich keine Experimente machen …

Danke!

Hallo,

Bitte :slight_smile:

Eine Anmerkung allerdings noch: Weder das eine noch das andere sollte Auswirkungen auf das SLES-System haben, da beides UCS-eigene Mechanismen sind, um bestimmte Sachverhalte festzustellen.

“univentionService=Samba 3” markiert das jeweilige UCS System im LDAP mit der Information “Hier läuft Samba 3”. Das wird bspw. von Join-Skripten abgefragt. Nach einer erfolgreichen Migration von Samba/NT (“Samba 3”) zu Samba/AD (“Samba 4”) sollte der Eintrag gelöscht werden, da er ein Überbleibsel ist. Genau genommen sogar eine Fehlinformation, die dann zu dem hier genannten Fehlerbild führt.

Die UCR-Variable samba4/ignore/mixsetup hat nach meinem Kenntnisstand lediglich die Funktion den unbeabsichtigten Parallelbetrieb von Samba/AD- und Samba/NT-Domaincontrollern in der selben UCS-Domäne zu verhindern. Das ist nämlich etwas, was man nur in bestimmten Situationen möchte, bspw. während der Migration von Samba/NT zu Samba/AD, und dazu muss die Variable explizit auf “yes” gesetzt werden. Das ist also eher als temporärer Workaround gedacht und weniger als Dauerlösung.

Dem SLES-System dürften diese “UCS-Meta-Informationen” herzlich egal sein :slight_smile:

Schönen Gruß,
Michael Grandjean

Dann nochmal danke für die ausführliche Erklärung.
:slight_smile:

Mastodon