Kein PXE-Boot / DHCP nach IT@school installation

UCS@school
#1

Hallo,

vor der Kauf-Entscheidung habe ich eine UCS-Demo-Umgebung (mit dem VM-Image) für unsere Schule aufgesetzt.
Auf dem UCS habe ich noch Zarafa über das App-Center installiert und einen weiteren Rechner als UCC-Terminalserver hinzugenommen.
User können sich von ihrem PC mit krdc an den Terminalserver verbinden, bekommen ihren Desktop und können das Zarafa webapp nutzen.
Soweit wunderbar.

Ich habe dann im nächsten Schritt UCS@school auf den UCS-Server installiert.
Danach kann der Terminalserver, der über PXE-Boot seine Daten vom UCS bekommt, aber nicht mehr gebootet werden.
Der Terminalserver setzt DHCP-Anfragen ab, bekommt aber offensichtlich nichts zurück und geht nach einer bestimmten Zeit
wieder ins Boot-Menü zurück.
Auf dem UCS-Server ist der DHCP-Dienst aktiviert, habe ihn auch mal neu gestartet bzw. auch mal komplett neu gestartet, erfolglos.

Wenn ich den UCS in der Virtuellen Maschine auf den Sicherungspunkt vor der UCS@school Instalation zurücksetze, geht noch alles.
Nach UCS@school nicht mehr. Ist reproduzierbar.

Wo kann ich noch suchen?
Hätte ich zuerst UCS@school und dann den Terminalserver einrichten müssen?

Viele Grüße
Waldi

#2

Update:

Ich habe nun die Umgebung nochmal in anderer Reihenfolge aufgesetzt, also erst die
UCS-Gundinstallation und danach gleich UCS@School.
Direkt im Nachgang dann den UCC als Terminalserver (nach Anleitung und exakt so
wie in der ersten lauffähigen Variante ohne UCS@school) eingerichtet.

Auch in dieser Konstellation funktioniert der Netzwerk-Boot des Terminalservers nicht.
Er bekommt keine Antwort auf seine DHCP-Anfrage.
Der DHCP-Dienst auf dem UCS-Server ist gestartet.

Vielleicht liest ja der Hersteller mit und kann eine Aussage treffen, ob generell
UCS@school und ein UCC-Terminalserver sich ausschließen.

Das wäre sehr schade, denn UCS wäre ansonsten das Produkt unserer Wahl gewesen.

Viele Grüße
Waldi

#3

Hallo,

UCS@school und UCC schließen sich nicht aus, im Gegenteil. Der Terminalserver sollte da keine Außnahme sein. Könnten Sie einmal in der UMC im DHCP-Modul (blaue Domänen-Kategorie) den passenden Eintrag für den UCC-Terminalserver raussuchen, öffnen und dann im Reiter Richtlinien prüfen was bei DHCP Boot, DHCP DNS und DHCP Routing hinterlegt ist? Falls da nichts drin steht, ist das vermutlich das Problem.

Parallel könnten Sie in der Logdatei /var/log/daemon.log nachschauen, was der DHCP-Server so zu sagen hat, wenn der UCC-Terminalserver DHCP-Anfragen rausschickt.

Schönen Gruß,
Michael Grandjean

#4

Hallo Herr Grandjean,

danke für die Rückmeldung.
In der ersten Konfiguration (noch ohne UCS@school) ist beim Eintrag für den Terminalserver lediglich bei DHCP Routing etwas hinterlegt (die Gateway-Adresse), alle anderen
Richtlinien sind leer (auch DHCP Boot, DHCP DNS usw. ).
Der Terminalserver bootet damit aber ordnungsgemäß, in /var/log/dhcp/daemon.log kann man den boot nachvollziehen:
(vom Datum nicht stören lassen, der Sicherungspunkt in der VM ist schon ein paar Tage her)
Apr 3 18:47:12 ucs-1113 dhcpd: DHCPDISCOVER from f0:de:f1:89:49:eb via eth0
Apr 3 18:47:12 ucs-1113 dhcpd: DHCPOFFER on 172.16.2.90 to f0:de:f1:89:49:eb via eth0
Apr 3 18:47:20 ucs-1113 dhcpd: DHCPREQUEST for 172.16.2.90 (172.16.2.100) from f0:de:f1:89:49:eb via eth0
Apr 3 18:47:20 ucs-1113 dhcpd: DHCPACK on 172.16.2.90 to f0:de:f1:89:49:eb via eth0
Apr 3 18:47:20 ucs-1113 in.tftpd[15702]: connect from 172.16.2.90 (172.16.2.90)
Apr 3 18:47:20 ucs-1113 atftpd[15702]: Advanced Trivial FTP server started (0.7)
Apr 3 18:47:20 ucs-1113 atftpd[15702]: Serving pxelinux.0 to 172.16.2.90:2070
Apr 3 18:47:20 ucs-1113 atftpd[15702]: Serving pxelinux.0 to 172.16.2.90:2071
Apr 3 18:47:20 ucs-1113 atftpd[15702]: Serving pxelinux.cfg/0138d000-1551-cb11-94a9-d650cd41de91 to 172.16.2.90:49152
Apr 3 18:47:20 ucs-1113 atftpd[15702]: Serving pxelinux.cfg/01-f0-de-f1-89-49-eb to 172.16.2.90:49153
Apr 3 18:47:20 ucs-1113 atftpd[15702]: Serving pxelinux.cfg/AC10025A to 172.16.2.90:49154
Apr 3 18:47:20 ucs-1113 atftpd[15702]: Serving ucc-2.1-desktop-image.img.kernel to 172.16.2.90:49155
Apr 3 18:47:22 ucs-1113 atftpd[15702]: Serving ucc-2.1-desktop-image.img.initrd to 172.16.2.90:49156

Bei der IT@school Installation wurde dann ein weiterer Eintrag bei den DHCP-Diensten generiert, dorthin wurde der DHCP-Server verschoben.
(Das Handbuch beschreibt das auch so, scheint also ok)
Im Eintrag für den Terminalserver hat danach keine der Richtlinien einen Wert, auch das DHCP-Routing nicht.

Die /var/log/dhcp/daemon.log erzählt nun:
Apr 3 14:51:23 ucs-1113 dhcpd: DHCPDISCOVER from f0:de:f1:89:49:eb via eth0: network 172.16.2.0/24: no free leases
Apr 3 14:51:25 ucs-1113 dhcpd: DHCPDISCOVER from f0:de:f1:89:49:eb via eth0: network 172.16.2.0/24: no free leases
Apr 3 14:51:29 ucs-1113 dhcpd: DHCPDISCOVER from f0:de:f1:89:49:eb via eth0: network 172.16.2.0/24: no free leases

Ich habe dann die Richtlinien zunächst des Terminalservers mit den angebotenen Default-Einträgen bei DHCP-Boot, DHCP-DNS und DHCP-Routing belegt.
Fehlerbild bleibt gleich.
Auch für die Objekte Subnetz und DHCP-Server habe ich dann die angebotenen Default-Einträge gesetzt.
Hilft aber alles nicht.

Leider habe ich mich ganz neu auf UCS gestürzt und muss gestehen, ich blicke noch nicht so recht durch was ich da mit den ganzen Einträgen genau mache :frowning:
Ich habe dann auch mal versucht, die /var/lib/dhcp/dhcp.leases neu anzulegen (alte Datei umbenannt, mit touch eine neue erzeugt) dann konnte ich
in der UMC aber den DHCP-Dienst gar nicht mehr starten und habe es zurückgenommen.
(Aus meinen alten Linux-Tagen kannte ich es noch so, dass dhcp dann die lease-Datenbank neu baut)

Vielleicht können Sie ja mit meiner Rückmeldung etwas anfangen und haben noch eine Idee…

Viele Grüße
Waldi

#5

Um es nochmal zu konkretisieren, als nur das UCS Basissystem und der UCC-Terminalserver installiert waren
gab es nur ein DHCP-Objekt und darin wiederum
-ein Objekt “Subnetz”
-ein Objekt “tserv” (so hatte ich den Terminalserver genannt)
-ein Objekt UCS1113 Server (der dhcp server)

Nach der UCS@school Installation gibt es zwei DHCP-Objekte
Im ersten, schon vorher bestehenden, fehlt nun das Objekt UCS1113 Server (der dhcp server), die
Objekte Subnetz und tserv sind noch da.
Im zweiten, neu entstandenen, gibt es
-ein Objekt “Subnetz”
-ein Objekt UCS1113 Server (der dhcp server, welcher hierhin automatisch umgezogen wurde)

Mein Terminalserver hängt also in einem DHCP-Objekt, in dem es zwar einen Eintrag für ihn
gibt aber keinen Eintrag mehr für den dhcp-Server.

Ich weiß ja nicht, ob das überhaupt eine Relevanz hat.
Der erste Zustand hatte für mich als Laien noch etwas logisches, warum dann der dhcp-Server
in ein anderes Objekt zieht, der Terminalserver aber im alten bleibt erschließt sich mir nicht so ganz.

Hat jemand ein Konfiguration mit UCS, UCS@School und einem UCC-Terminalserver erfolgreich am Laufen?

Viele Grüße
Klaus

#6

Moin,

ich gehe davon aus, dass die UCS@school-Installation schlicht davon ausgeht, dass eine jungfräuliche Installation in eine @school-Installation umgewandelt wird. Die beteiligten Domänenserver werden dabei automatisch an die neue Struktur angepasst, die vorhandenen anderen Rechnerobjekte hingegen nicht. Das ergibt für mich auch durchaus Sinn, da UCS@school Konzepte wie getrennte Netze für Lehre und Verwaltung vorsieht und multiple Standorte unterstützt – alle mit je eigenen Netzbereichen.

Somit sollten Sie bei Ihrem Terminalserver mal in den Einstellungen des Rechnerobjektes nachschauen, in welchem Netz er momentan registriert ist und das dann gegebenenfalls umstellen.

Gruß,
mosu

#7

Hallo,
ausgehend von dem Tip mit dem richtigen Netzwerk konnte ich nach vielen Versuchen den Terminalserver nun installieren.

Ich habe dazu einen neuen Rechner in UCS@school eingerichtet und über dessen Richtlinien es hinbekommen, dass
er nun als xrdp-Terminalserver fungiert.
Ich habe einige Versuche unternommen und kann nun leider aber nicht mehr konkret sagen, welche der Einstallung
die wirklich entscheidende gewesen ist. Anfangs habe ich zwar noch fleißig mitprotokolliert, aber irgendwann
hat der Eifer nachgelassen :wink:

Jetzt kämpfe ich nur noch damit, dass sich auf dem Terminalserver keiner der in UCS@school angelegten User
per rdp-client anmelden kann. Auch ein direkt am Domaincontroller (im UCS) angelegter User kann es nicht.
Direkt am Rechner auf dem der Terminalserver installiert ist, können sich die User anmelden, nicht jedoch per
rdp-Client.
Da probiere ich noch ein Wenig herum. Notfalls wende ich mich in einem separaten Beitrag nochmals an das Forum.

Grüße und vielen Dank
Waldi

Mastodon