Klappt leider nicht. Habe 5 Minuten gewartet:
root@vmhost02:/var/lib/libvirt/images# host tux.sterdy.local 192.168.1.5
Using domain server:
Name: 192.168.1.5
Address: 192.168.1.5#53
Aliases:
Host tux.sterdy.local not found: 2(SERVFAIL)
Im DNS gibt es noch einen Eintrag:
Host: ucs-sso / IP: 192.168.1.5
Für was ist der gut bzw. soll der raus?
Moin,
Klingt, als würde auf dem Master etwas klemmen, z.B. mit der Synchronisation zwischen OpenLDAP und Samba4. Bitte posten Sie die Ausgabe der folgenden Befehle:
ucr get dns/backend
univention-s4connector-list-rejected
univention-ldapsearch '(&(relativeDomainName=tux)(objectClass=dNSZone))'
univention-s4search --cross-ncs '(&(dc=tux)(objectClass=dnsNode))'
Auf keinen Fall! Das Univention-SSO ( = Single Sign-On) ist das System, mit dem domänenweite Anmeldungen an den einzelnen Servern überhaupt erst möglich ist. Auch andere Anwendungen nutzen SSO zur Anmeldung.
Sie schrieben irgendwo weiter oben, dass Sie den Master mal »in eine VM verfrachtet haben«. Haben Sie damals auch die IP-Adresse geändert? Wie haben Sie die damals geändert?
Gruß,
mosu
Nachdem ich den Eintrag 192.168.1.5 auch in der Revers-Zone geändert habe ist mir noch aufgefallen das der Eintrag unter Geräte/Rechner der IP-Eintrag für tux (Master) ebenfalls auf der .2 stand. Das habe ich auch geändert -> Neustart.
Nun komme ich zumindest mal ins Webinterface des Members. Bei den Fehlermeldungen bei:
hat sich allerdings nichts geändert. Im WebUI des Members -> Software-Updates zeigt er mit:
Achtung: Sie verwenden aktuell UCS 4.2-0. Für diese Version werden keine Sicherheitsupdates mehr veröffentlicht. Bitte aktualisieren Sie das System auf eine neuere UCS Version!
Enterprise Subskriptionen bieten für einige Versionen längere Aktualisierungszeiträume. Informationen dazu finden Sie auf der Univention Webseite.
root@tux:~# ucr get dns/backend
ldap
root@tux:~# univention-s4connector-list-rejected
-bash: univention-s4connector-list-rejected: Kommando nicht gefunden.
root@tux:~# univention-ldapsearch ‘(&(relativeDomainName=tux)(objectClass=dNSZone))’
dn: relativeDomainName=tux,zoneName=stedry.local,cn=dns,dc=stedry,dc=local
objectClass: dNSZone
objectClass: top
objectClass: univentionObject
univentionObjectType: dns/host_record
relativeDomainName: tux
zoneName: stedry.local
aRecord: 192.168.1.5
search: 3
result: 0 Success
root@tux:~# nivention-s4search --cross-ncs ‘(&(dc=tux)(objectClass=dnsNode))’
-bash: nivention-s4search: Kommando nicht gefunden.
root@tux:~# univention-s4search --cross-ncs ‘(&(dc=tux)(objectClass=dnsNode))’
-bash: univention-s4search: Kommando nicht gefunden.
Ja, habe auf mei geschaut und gesehen dass der Eintrag da auch drin ist und ihn somit für notwendig erachtet.
Ich habe das Problem wohl gefunden. Da ja tux.stedry.local mal auf die 192.168.1.2 zeigte wurde zu irgend einem Zeitpunkt von vmhost02 (192.168.1.10) ein SSH-Key-Exchange mit 192.168.1.2 vollzogen.
Die Fehlermeldung dass das Passwort falsch wäre hat mich in die Irre geführt. Nachdem ich vom Client problemlos perr SSH als Administrator auf den Master kam habe ich selbiges mal vom Member aus probiert:
root@vmhost02:~# ssh -l Administrator tux.stedry.local
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for tux.stedry.local has changed,
and the key for the corresponding IP address 192.168.1.5
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
8f:73:7b:c3:f6:84:19:52:40:1e:1b:2c:d9:b8:1d:1b.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:2
remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R tux.stedry.local
ECDSA host key for tux.stedry.local has changed and you have requested strict checking.
Host key verification failed.
und anschließend:
root@vmhost02:~# ssh-keygen -f "/root/.ssh/known_hosts" -R tux.stedry.local
Danach hat der Join gekplappt. Jetzt habe ich nur noch ein Problem beim Upgrade des Members.
Da der Member der KVM-Host ist und der Master als VM darauf läuft kann ich das Upgrade auf 4.2-1 nicht machen. Beende ich den Master (VM) erhalte ich die Fehlermeldung:
31.08.17 09:26:09.244 DEBUG_INIT **** Starting univention-updater with parameter=['/usr/share/univention-updater/univention-updater', 'net', '--updateto', '4.2-1', '--ignoressh', '--ignoreterm'] Version=4.2 Patchlevel=0 starting net mode --->DBG:update_available(mode=net, cdrom_mount_point=/media/cdrom, iso=None) Checking network repository Update to = 4.2-1 **** Downloading scripts at Thu Aug 31 09:26:10 2017 **** Starting actual update at Thu Aug 31 09:26:12 2017 Running preup.sh script Do 31. Aug 09:26:12 CEST 2017 HINT: Please check the release notes carefully BEFORE updating to UCS 4.2-1: English version: https://docs.software-univention.de/release-notes-4.2-1-en.html German version: https://docs.software-univention.de/release-notes-4.2-1-de.html Please also consider documents of following release updates and 3rd party components. Do you want to continue [Y/n]? Custom preupdate script /var/lib/local-preup.sh not found Checking for space on /var/cache/apt/archives: OK Checking for space on /boot: OK Checking for space on /: OK Checking for package status: Traceback (most recent call last): File "<string>", line 3, in <module> File "/usr/lib/pymodules/python2.7/univention/lib/ucs.py", line 23, in __init__ self.set(version) File "/usr/lib/pymodules/python2.7/univention/lib/ucs.py", line 55, in set raise ValueError('string does not match UCS version pattern') ValueError: string does not match UCS version pattern WARNING: Your domain controller master is still on version -. It is strongly recommended that the domain controller master is always the first system to be updated during a release update. This check can be skipped by setting the UCR variable update42/ignore_version to yes. Error: Update aborted by pre-update script of release 4.2-1
Ich weiß schon dass ich noch einen Backup brauche. Allerdings kann ich diesen erst installieren wenn die “alte” Server-Maschine komplett frei migriert ist.
Ist das Problem mit:
This check can be skipped by setting the UCR variable update42/ignore_version to yes.
zu lösen? Wo setze ich diese Variable?
Da ich so ein Setup nicht habe, kann ich dazu nicht viel sagen. Haben Sie’s denn mit laufendem Master probiert? Kam da eine Fehlermeldung?
Es kann gut sein, dass das in diesem Falle hilft. UCR-Variablen setzt man wie folgt:
ucr set variable=wert
Als in diesem Fall (auf dem Member):
ucr set update42/ignore_version=yes
Man kann solche Variablen auch via Web-Browser setzen, wenn man sich in der Univention Management Console auf dem jeweiligen Server anmeldet.
Ja, ich habe sie im Webinterface eingetragen, die VM’s beendet und das Upgrade per Konsole angestoßen. Hat funktioniert. Habe die Variable anschließend wieder entfernt.
Vielen Vielen Dank für die Hilfe!!!