26.06.2025
2696
23
0Openthinclient Boot time issue
Guten Tag in die Runde,
ich habe ein Problem mit unseren Openthinclients, und nachdem ich nun schon einiges ohne Erfolg analysieren konnte, kann mir hier vielleicht jemand helfen.
Kennt das Problem jemand, oder hat jemand gar eine Lösung dafür?
Vielen Dank und viele Grüße
Stefan
ich habe ein Problem mit unseren Openthinclients, und nachdem ich nun schon einiges ohne Erfolg analysieren konnte, kann mir hier vielleicht jemand helfen.
Grundsätzlich fahren die Devices hoch, allerdings dauert dies mehrere Minuten
Nach Einschalten des Bootlogs konnte ich feststellen dass das Problem replizierbar an der gleichen Stelle beim Bootvorgang liegt
"Enter Auth Username: [ 9.881778 Generic FE-GE Realtek PHY r8169-0-100:00:99: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC)"
Erster Verdacht: OpenVPN, da hier die Einstellung Usereingabe abfragen aktiv ist
Quercheck: OPENVPN herausgenommen: Gleiches Ergebnis
Nach Einschalten des Bootlogs konnte ich feststellen dass das Problem replizierbar an der gleichen Stelle beim Bootvorgang liegt
"Enter Auth Username: [ 9.881778 Generic FE-GE Realtek PHY r8169-0-100:00:99: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC)"
Erster Verdacht: OpenVPN, da hier die Einstellung Usereingabe abfragen aktiv ist
Quercheck: OPENVPN herausgenommen: Gleiches Ergebnis
Kennt das Problem jemand, oder hat jemand gar eine Lösung dafür?
Vielen Dank und viele Grüße
Stefan
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673561
Url: https://administrator.de/forum/openthinclient-boot-problem-dauer-673561.html
Ausgedruckt am: 18.07.2025 um 14:07 Uhr
23 Kommentare
Neuester Kommentar
Moin,
wäre vielleicht sinnvoll zu ein paar mehr Details zu nennen, etwa wie deine Thinclients denn den OpenThinClient booten => USB/SSD/Network(PXE) und wie deren OpenThinClient denn initial konfiguriert wurde.
Gruß
wäre vielleicht sinnvoll zu ein paar mehr Details zu nennen, etwa wie deine Thinclients denn den OpenThinClient booten => USB/SSD/Network(PXE) und wie deren OpenThinClient denn initial konfiguriert wurde.
Gruß
1
Hi Biberman,
da hast Du natürlich recht.
Die Geräte booten über PXE.
Es gibt auch die Option eines Localboot. Dann booten die Devices über ein lokales Image. Im lokalen Netzwerk wird das aber übersprungen, wenn PXE eingerichtet ist und funktioniert. (Werde aber mal einen Test machen und die Localboot-Option herausnehmen.)
Viele Grüße
Stefan
da hast Du natürlich recht.
Die Geräte booten über PXE.
Es gibt auch die Option eines Localboot. Dann booten die Devices über ein lokales Image. Im lokalen Netzwerk wird das aber übersprungen, wenn PXE eingerichtet ist und funktioniert. (Werde aber mal einen Test machen und die Localboot-Option herausnehmen.)
Viele Grüße
Stefan
OK.
Wenn das nicht den Erfolg bringt, auch mal den Debug Modus verwenden und den Bootvorgang verfolgen um zu sehen welcher Prozess da abfragt
Wenn das nicht den Erfolg bringt, auch mal den Debug Modus verwenden und den Bootvorgang verfolgen um zu sehen welcher Prozess da abfragt
Startoptionen > Debugmodus für Startvorgang > Debugge init-script (für Experten)
(An den Debug-Breakpoints "exit" eintippen um im Bootvorgang weiter zu machen)1
Localboot kann ich ausschliessen.
Allerdings steht nach dem Eintrag oben im Bootlog:
[***] Job openvpn@openvpn.service/start running (30s / 1min 31s).
Das sieht dann doch eher danach aus, als würde der Dienst openvpn nicht starten können, da ihm keine Zugangsdaten bekannt sind.
Allerdings steht nach dem Eintrag oben im Bootlog:
[***] Job openvpn@openvpn.service/start running (30s / 1min 31s).
Das sieht dann doch eher danach aus, als würde der Dienst openvpn nicht starten können, da ihm keine Zugangsdaten bekannt sind.
Zitat von @SFischer:
Allerdings steht nach dem Eintrag oben im Bootlog:
[***] Job openvpn@openvpn.service/start running (30s / 1min 31s).
Das sieht dann doch eher danach aus, als würde der Dienst openvpn nicht starten können, da ihm keine Zugangsdaten bekannt sind.
Ja, dann liegt es offensichtlich an OpenVPN. Wie und was habt ihr für OpenVPN denn für eine Auth konfiguriert (User:Pass / Zertifikat)?Allerdings steht nach dem Eintrag oben im Bootlog:
[***] Job openvpn@openvpn.service/start running (30s / 1min 31s).
Das sieht dann doch eher danach aus, als würde der Dienst openvpn nicht starten können, da ihm keine Zugangsdaten bekannt sind.
Und gibt es das Problem schon länger oder wurde evt. etwas am OpenVPN Server geändert?
1
OpenVPN gibt es schon länger hier, wir haben bislang IGEL Clients eingesetzt, die sich beim Booten dann mit einem Watchguard-Cluster verbinden. Nach VPN-Aufbau wird dann eine RDP-Session aufgebaut. Das klappt gut, ist aber relativ teuer.
Die Openthinclients sollen das gleiche machen. Ähnlich wie bei den IGEL-Geräten ist Openvpn teil des OS und wird über eine Management GUI mitverwaltet. Ich vermute, dass hier das Problem zu suchen ist. Anscheinend wir der Openvpn-Dienst immer mitgeladen, wenn einmal hinzugefügt, auch wenn man den später wieder aus der Konfig entfernt.
Das Problem gibt es auch in einer ähnlichen Konstellation mit Ubuntu:
askubuntu.com/questions/627842/what-does-the-form-field-enter-au ...
Nachdem das ganz dann doch relativ schnell komplex wird, dachte ich, ich frage mal hier nach.
Die Openthinclients sollen das gleiche machen. Ähnlich wie bei den IGEL-Geräten ist Openvpn teil des OS und wird über eine Management GUI mitverwaltet. Ich vermute, dass hier das Problem zu suchen ist. Anscheinend wir der Openvpn-Dienst immer mitgeladen, wenn einmal hinzugefügt, auch wenn man den später wieder aus der Konfig entfernt.
Das Problem gibt es auch in einer ähnlichen Konstellation mit Ubuntu:
askubuntu.com/questions/627842/what-does-the-form-field-enter-au ...
Nachdem das ganz dann doch relativ schnell komplex wird, dachte ich, ich frage mal hier nach.
Zitat von @SFischer:
Anscheinend wir der Openvpn-Dienst immer mitgeladen, wenn einmal hinzugefügt, auch wenn man den später wieder aus der Konfig entfernt.
Kann ich hier im Test nicht nachvollziehen, wenn ich den Autostart nachträglich wieder deaktiviere und das Profil aktualisiere, startet der Dienst auch nicht mehr von selbst.Anscheinend wir der Openvpn-Dienst immer mitgeladen, wenn einmal hinzugefügt, auch wenn man den später wieder aus der Konfig entfernt.
docs.openthinclient.com/2025/books/openthinclient-management-ser ...
Im Zweifel nimmt man halt den Link für den Start von Hand raus aus dem Image.
Hi BiberMan.
vielen Dank für den Input und die Hilfe.
Der Hinweis mit dem Debuggen war super, das Ergebnis ist aufschlussreich:
Gibt man im Bootscreen bei der auth-Eingabe einfach enter ein, dann erscheint:
Es erscheint damit für mich also so, dass schon beim Booten Credentials abgefragt werden.
vielen Dank für den Input und die Hilfe.
Der Hinweis mit dem Debuggen war super, das Ergebnis ist aufschlussreich:
2025-06-26 15:52:11,963 ERROR 00:e0:c5:1f:12:88 192.168.10.199 user openvpn Failed to run application.
Traceback (most recent call last):
File "/opt/openvpn/tcos/launcher", line 232, in <module>
run_app(app_config)
File "/opt/openvpn/tcos/launcher", line 125, in run_app
if result.get('code') != tcos.dialog.OK:
^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
2025-06-26 15:52:11,967 WARN 00:e0:c5:1f:12:88 192.168.10.199 user openvpn Failed to connect to dialog socket: Connection refused
Retrying... (Attempt 1/30)Gibt man im Bootscreen bei der auth-Eingabe einfach enter ein, dann erscheint:
2025-06-26 16:09:58,523 INFO 00:e0:c5:1f:12:88 192.168.10.199 daemon systemd-tty-ask-password-agent Password query on /dev/tty1 finished successfully.
2025-06-26 16:09:58,552 INFO 00:e0:c5:1f:12:88 192.168.10.199 daemon systemd-tty-ask-password-agent Starting password query on /dev/tty1.
2025-06-26 16:09:59,831 INFO 00:e0:c5:1f:12:88 192.168.10.199 daemon systemd-tty-ask-password-agent Password query on /dev/tty1 finished successfully.
2025-06-26 16:09:59,833 ERROR 00:e0:c5:1f:12:88 192.168.10.199 daemon ovpn-openvpn ERROR: Auth username is empty
2025-06-26 16:09:59,833 INFO 00:e0:c5:1f:12:88 192.168.10.199 daemon ovpn-openvpn Exiting due to fatal errorEs erscheint damit für mich also so, dass schon beim Booten Credentials abgefragt werden.
if result.get('code') != tcos.dialog.OK:
^^
AttributeError: 'NoneType' object has no attribute 'get'
Das klingt sehr nach Programmier-Fehler, da hier offensichtlich die Variable "result" nicht auf Inhalt geprüft wird. Ist das Image des ThinClient up to date?^^
AttributeError: 'NoneType' object has no attribute 'get'
Prüfe auch folgendes:
- Wenn du den Dienst nur gestoppt oder deaktiviert und die OpenVPN Config entfernt hast ohne das Profil zu aktualisieren kann das vorkommen das der Dienst weiterhin beim Boot startet und dann natürlich fehl schlägt.
- Auf dem ThinClient-Dateisystem prüfe im launcher script
/opt/openvpn/tcos/launcherob dort OpenVPN fest eingebaut wurde. - Schau in eventuell noch vorhandene *.xml oder *.conf Dateien auf Referenzen zu deiner alten OpenVPN Konfiguration
- Ansonsten erstelle das Boot-Image mit deinem bereinigten Profil neu (regenerate/redeploy).
Erst einmal vielen Dank für Deine Zeit und die Hilfe:
Was ich nun gemacht habe:
Patchlevel geprüft >Ist ok
Localboot Image neu erstellt
Test mit localboot und PXE liefern allerdings immer noch das gleiche Ergebnis.
client
proto tcp
<ca>
BEGIN CERTIFICATE-----
*
END CERTIFICATE-----
</ca>
<cert>
BEGIN CERTIFICATE-----
*
END CERTIFICATE-----
</cert>
<key>
BEGIN PRIVATE KEY-----
***
END PRIVATE KEY-----
</key>
remote-cert-eku "TLS Web Server Authentication"
remote IP.IP.IP.IP 443
persist-key
persist-tun
verb 3
mute 20
keepalive 10 60
data-ciphers AES-256-CBC
auth SHA256
float
reneg-sec 28800
nobind
mute-replay-warnings
auth-user-pass
tls-version-min 1.2
;remember_connection 0
;auto_reconnect 1
Meine nächste Idee wäre das OTC komplett zu resetten und mit einem blanken Gerät zu beginnen, die Konfig Zug um Zug auszurollen...
Was ich nun gemacht habe:
Patchlevel geprüft >Ist ok
Localboot Image neu erstellt
Test mit localboot und PXE liefern allerdings immer noch das gleiche Ergebnis.
Im /opt/openvpn/tcos/launcher ist openvpn fester Bestandteil
openvpv.conf ist sauber, da ist wenig drin:
dev tunopenvpv.conf ist sauber, da ist wenig drin:
client
proto tcp
<ca>
BEGIN CERTIFICATE-----
*
END CERTIFICATE-----
</ca>
<cert>
BEGIN CERTIFICATE-----
*
END CERTIFICATE-----
</cert>
<key>
BEGIN PRIVATE KEY-----
***
END PRIVATE KEY-----
</key>
remote-cert-eku "TLS Web Server Authentication"
remote IP.IP.IP.IP 443
persist-key
persist-tun
verb 3
mute 20
keepalive 10 60
data-ciphers AES-256-CBC
auth SHA256
float
reneg-sec 28800
nobind
mute-replay-warnings
auth-user-pass
tls-version-min 1.2
;remember_connection 0
;auto_reconnect 1
Meine nächste Idee wäre das OTC komplett zu resetten und mit einem blanken Gerät zu beginnen, die Konfig Zug um Zug auszurollen...
auth-user-pass
Das würde ne Eingabe für Username und Password triggern, oder liegt da nen Plaintext file mit den Creds rum.Meine nächste Idee wäre das OTC komplett zu resetten und mit einem blanken Gerät zu beginnen, die Konfig Zug um Zug auszurollen...
Clean ist immer gut. 
.1
Ich vermute auch das auth-user-pass das auslöst.
ja, beim Booten in der command line macht das doch kaum Sinn, zumal es auch noch einen Schalter "Autostart" gibt, der aber zumindest in meiner Umgebung keine Auswirkung hat..
Ich mach mal eine frische Konfig...
Vielen, vielen DANK einstweilen!
ja, beim Booten in der command line macht das doch kaum Sinn, zumal es auch noch einen Schalter "Autostart" gibt, der aber zumindest in meiner Umgebung keine Auswirkung hat..
Ich mach mal eine frische Konfig...
Vielen, vielen DANK einstweilen!
Keine Ursache, abschließendes Feedback ist wie immer gerne gesehen. Good luck.
1
Vielen Dank!
Leider ist das Problem auch mit einer neuen Konfig vorhanden.
Ich werde das jetzt mal eskalieren und sehen, dass ich ein Budget für ein Supportkontingent beim Hersteller bekomme. Sobald ich eine Lösung habe, melde ich mich hier nochmal!
Leider ist das Problem auch mit einer neuen Konfig vorhanden.
Ich werde das jetzt mal eskalieren und sehen, dass ich ein Budget für ein Supportkontingent beim Hersteller bekomme. Sobald ich eine Lösung habe, melde ich mich hier nochmal!
Vielleicht hilft das hiesige OpenVPN Tutorial noch zu einem Lösungsansatz?!
Hi aqui,
OpenVPN selbst ist nicht das Problem. Das funktioniert einwandfrei. Es ist wohl eher die Implementierung in das OS, das zu einer Abfrage von Credentails beim Booten führt. Danach sieht es zumindest derzeit aus.
OpenVPN selbst ist nicht das Problem. Das funktioniert einwandfrei. Es ist wohl eher die Implementierung in das OS, das zu einer Abfrage von Credentails beim Booten führt. Danach sieht es zumindest derzeit aus.
Zitat von @SFischer:
Es ist wohl eher die Implementierung in das OS, das zu einer Abfrage von Credentails beim Booten führt. Danach sieht es zumindest derzeit aus.
Ähm, wenn du mit deiner oben gelisteten Config zur erzwungenen Abfrage von Benutzername und Kennwort (durch die "auth-user-pass" Direktive) aufforderst, was erwartest du, das er das überspringt?!Es ist wohl eher die Implementierung in das OS, das zu einer Abfrage von Credentails beim Booten führt. Danach sieht es zumindest derzeit aus.
Also Config richtig stellen dann lüppt dat auch 😁.
OpenThinClient ist Debian basiert, also ehrlich gesagt Standard-Ware.
Just read the manuals ...
openvpn.net/community-resources/reference-manual-for-openvpn-2-6 ...
--auth-user-pass
Authenticate with server using username/password.
Valid syntaxes:
auth-user-pass
auth-user-pass up
If up is present, it must be a file containing username/password on 2 lines. If the password line is missing, OpenVPN will prompt for one.
If up is omitted, username/password will be prompted from the console
Authenticate with server using username/password.
Valid syntaxes:
auth-user-pass
auth-user-pass up
If up is present, it must be a file containing username/password on 2 lines. If the password line is missing, OpenVPN will prompt for one.
If up is omitted, username/password will be prompted from the console
1
Jein. Denn der Prompt erscheint auch, wenn ich z.B. "Autostart" herausnehme, oder OpenVpn komplett aus der Konfig herausnehme. Damit sollte imho auch kein auth-prompt erfolgen.
Zitat von @SFischer:
Jein. Denn der Prompt erscheint auch, wenn ich z.B. "Autostart" herausnehme, oder OpenVpn komplett aus der Konfig herausnehme. Damit sollte imho auch kein auth-prompt erfolgen.
Jein. Denn der Prompt erscheint auch, wenn ich z.B. "Autostart" herausnehme, oder OpenVpn komplett aus der Konfig herausnehme. Damit sollte imho auch kein auth-prompt erfolgen.
Dann wurde das Profil nicht richtig gespeichert und angewendet.
Funktioniert hier wie gesagt im Test einwandfrei, du musst in eurem Workflow/System also irgendwo nen eigenen Fehler eingebaut haben wenn OpenVPN trotzdem noch den Dienst startet.
1
Ich konnte das Problem lösen.
Falls jemand das gleiche Phänomen hat, dann einfach eine PM an mich.
Falls jemand das gleiche Phänomen hat, dann einfach eine PM an mich.
Zitat von @SFischer:
Ich konnte das Problem lösen.
Falls jemand das gleiche Phänomen hat, dann einfach eine PM an mich.
Ich konnte das Problem lösen.
Falls jemand das gleiche Phänomen hat, dann einfach eine PM an mich.
Ähm, das ist nicht der Sinn eines Forums... Warum schreibst du deine Lösung nicht hier rein ?🤔👎. Wir haben dich hier ja auch in der Lösungsfindung unterstützt.
Und dann bitte als gelöst markieren nicht vergessen. Dankeschön!
2
Ich habe meine konkreten Gründe, das jetzt hier nicht zu tun.
Ich werde auch nicht den Sinn eines Forums an dieser Stelle diskutieren.
Wie oben bereits geschrieben jeder, der das gleiche Problem hat, kann sich gerne an mich wenden.
Danke Dir für Deine Beiträge, die allerdings nicht Teil der Lösung waren.
Ich werde auch nicht den Sinn eines Forums an dieser Stelle diskutieren.
Wie oben bereits geschrieben jeder, der das gleiche Problem hat, kann sich gerne an mich wenden.
Danke Dir für Deine Beiträge, die allerdings nicht Teil der Lösung waren.
