Problem mit Backup-DC bei Samba-4-Installation

german

#1

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.


#2

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


#3

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.


#4

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!


#5

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


#6

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