ich möchte mich zunächst vorstellen:
Ich heiße Michael, bin Systemadministrator bei einer Consulting Firma, deren Kunde eine größere Berufsschule demnächst Linuxmuster.net 7 einführen will.
Im Testbetrieb mit ein paar Hardwareklassen bin ich auf folgende Probleme gestoßen. (Stand 22.05.20)
linuxmuster-import-devices unterscheidet was DHCP (filename) angeht nur zwischen opsi und nicht opsi jedoch nicht zwischen opsi BIOS und opsi UEFI.
entspreched definiert /usr/lib/linuxmuster/constants.py nur OPSIPXEFILE=‚linux/pxelinux.0‘ und nicht
linux/pxelinux.cfg/elilo.efi wie es für UEFI + opsi richtig wäre.
Als dirty Hack habe ich constants.py entsprechend modifiziert (es gibt für den Moment nur UEFI opsi Clients), so daß dann
filename „linux/pxelinux.cfg/elilo.efi“ für das entsprechende Gerät in /etc/dhcp/devices.conf gesetzt wird.
Da die Schule einige Hardwareklassen hat, die NUR noch via UEFI booten können wäre eine Anpassung von linuxmuster-import-devices die diese Differenzierung durchführt für uns sehr hilfreich.
Auch im Hinblick darauf das BIOS Geräte in naher Zukunft aussterben werden.
Außerdem fällt auf, dass die Integration zwischen Schulkonsole und opsi nicht 100%ig funktioniert.
Bei 2 TestVM hat das bestens funktioniert, (opsi pxe einstellen - Gerät taucht als Client in opsi auf).
Bei meinen physikalischen Testgeräten allerdings nicht mehr. Ich mußte die Geräte manuell in opsi aufnehmen. Die Ursache dafür habe ich leider noch nicht gefunden.
linuxmuster-import-devices unterscheidet was DHCP (filename) angeht
nur zwischen opsi und nicht opsi jedoch nicht zwischen opsi BIOS und
opsi UEFI.
entspreched definiert /usr/lib/linuxmuster/constants.py nur
OPSIPXEFILE=‚linux/pxelinux.0‘ und nicht
linux/pxelinux.cfg/elilo.efi wie es für UEFI + opsi richtig wäre.
Als dirty Hack habe ich constants.py entsprechend modifiziert (es gibt
für den Moment nur UEFI opsi Clients), so daß dann
filename „linux/pxelinux.cfg/elilo.efi“ für das entsprechende Gerät in
/etc/dhcp/devices.conf gesetzt wird.
Da die Schule einige Hardwareklassen hat, die NUR noch via UEFI booten
können wäre eine Anpassung von linuxmuster-import-devices die diese
Differenzierung durchführt für uns sehr hilfreich.
Auch im Hinblick darauf das BIOS Geräte in naher Zukunft aussterben werden.
ich habe das mal an den Entwickler weitergeleitet.
Außerdem fällt auf, dass die Integration zwischen Schulkonsole und opsi
nicht 100%ig funktioniert.
Bei 2 TestVM hat das bestens funktioniert, (opsi pxe einstellen - Gerät
taucht als Client in opsi auf).
Bei meinen physikalischen Testgeräten allerdings nicht mehr. Ich mußte
die Geräte manuell in opsi aufnehmen. Die Ursache dafür habe ich leider
noch nicht gefunden.
ich meine, die „Fernsteuerung“ der opsi maschine läuft per ssh mittels
sshkeiy (passwordless).
Kommst du vom server asu mittels
ssh root@ip.der.opsi.maschine
ohne Passwortabfrage auf die OPSI Maschine?
Der umgekehrte Fall war allerdings ohne ssh key. Nachdem ich einen ssh key für root@opsi ohne Passphrase angelegt habe funktioniert es wie erwartet. Warum der key nicht da war, bzw. ob der gelöscht wurde kann ich gerne nicht nachvollziehen.
Gerade festgestellt:
Bei unregistrierten Clients wird nun fälschlicherweise linux/pxelinux.cfg/elilo.efi ausgeliefert, so daß neue Geräte nicht mehr in linbo booten.
Vermutlich wurde versäumt einen default Wert zu setzen.
Kann ich hier nicht nachvollziehen. Unregistrierte Clients booten bei
mir standardmäßig das vorgesehene Grub-Bootimage boot/grub//core. vom
lmn7-Server.
Gerade festgestellt:
Bei unregistrierten Clients wird nun fälschlicherweise
linux/pxelinux.cfg/elilo.efi ausgeliefert, so daß neue Geräte nicht mehr
in linbo booten.
Vermutlich wurde versäumt einen default Wert zu setzen.
läuft ein
linuxmuster-import-workstations
ohne Fehler durch?
Taucht die Gruppe als „present“ auf?
Oder als „not yet configured“?
