pseudo-tty liefert keine Daten aus LXC container #38

DrBakterius · 2022-09-06T15:28:38Z

Sowohl ioBroker als auch WireGuard laufen in zwei unterschiedlichen LXC-Containern (beide debian 11) unter Proxmox auf dem selben PC.

Ich schaffe es nicht die Instanz zum Laufen zu bringen.

Im debug-LOG ist auch nichts zu finden.

2022-09-06 17:12:00.995 - info: wireguard.0 (1607420) Got terminate signal TERMINATE_YOURSELF
2022-09-06 17:12:00.996 - info: wireguard.0 (1607420) Clearing interval for host [MEINHOST]
2022-09-06 17:12:00.997 - info: wireguard.0 (1607420) terminating
2022-09-06 17:12:00.998 - debug: wireguard.0 (1607420) Plugin sentry destroyed
2022-09-06 17:12:00.999 - info: wireguard.0 (1607420) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2022-09-06 17:12:05.603 - debug: wireguard.0 (1615446) Redis Objects: Use Redis connection: 127.0.0.1:9001
2022-09-06 17:12:05.683 - debug: wireguard.0 (1615446) Objects client ready ... initialize now
2022-09-06 17:12:05.685 - debug: wireguard.0 (1615446) Objects create System PubSub Client
2022-09-06 17:12:05.687 - debug: wireguard.0 (1615446) Objects create User PubSub Client
2022-09-06 17:12:05.814 - debug: wireguard.0 (1615446) Objects client initialize lua scripts
2022-09-06 17:12:05.822 - debug: wireguard.0 (1615446) Objects connected to redis: 127.0.0.1:9001
2022-09-06 17:12:05.879 - debug: wireguard.0 (1615446) Redis States: Use Redis connection: 127.0.0.1:9000
2022-09-06 17:12:05.932 - debug: wireguard.0 (1615446) States create System PubSub Client
2022-09-06 17:12:05.934 - debug: wireguard.0 (1615446) States create User PubSub Client
2022-09-06 17:12:06.020 - debug: wireguard.0 (1615446) States connected to redis: 127.0.0.1:9000
2022-09-06 17:12:06.324 - debug: wireguard.0 (1615446) Plugin sentry Initialize Plugin (enabled=true)
2022-09-06 17:12:06.959 - info: wireguard.0 (1615446) starting. Version 1.3.1 in /opt/iobroker/node_modules/iobroker.wireguard, node: v16.17.0, js-controller: 4.0.23
2022-09-06 17:12:07.020 - info: wireguard.0 (1615446) There is 1 wireguard host to monitor.
2022-09-06 17:12:07.021 - info: wireguard.0 (1615446) Started 60 seconds monitoring interval for host [MEINHOST]
2022-09-06 17:13:07.022 - debug: wireguard.0 (1615446) Retrieving WireGuard status of host [MEINHOST] on address [192.168.1.105]
2022-09-06 17:13:07.024 - debug: wireguard.0 (1615446) Executing command [sudo wg show all dump] on host 192.168.1.105.

Ich habe den erstellten user wie beschrieben in der sudoer-Datei die Rechte gegeben (aber auch mal mit dem root-Zugang getestet). Ich habe in der Config einen beliebigen Hostnamen (MEINHOST) vergeben, die IP auf der WireGuard läuft, den user-Namen und sein Passwort eingegeben und 'sudo' angehakt (aber auch ohne probiert).

Auf der zweiten Seite den öffentlichen Schlüssel des Client und seine Bezeichnung eingegeben.

Auf der dritte Seite den gleichen Hostnamen wie auf der ersten Seite angegeben, bei 'Schnittstellenname' habe ich 'wg0' eingetragen (was gehört da genau rein?) und dann den korrekten Pfad zur Konfigurationsdatei.

Also was läuft hier falsch?

The text was updated successfully, but these errors were encountered:

Grizzelbee · 2022-09-06T15:45:38Z

Also was läuft hier falsch?

Das kann ich so pauschal leider nicht beantworten. Zumal und vor vor allem weil ich keine Ahnung von LXC Containern habe und wie sie funktionieren.

Was der Adapter macht schreibt er eigentlich ganz klar raus:

Executing command [sudo wg show all dump] on host 192.168.1.105.

Er versucht als der konfigurierte Benutzer das genannte Kommando auf der genannten Maschine auszuführen - und die Rückmeldung von Linux loggt er ebenfalls raus.

Die Frage ist also: Wenn Du dich als root oder als der konfigurierte User an der Maschine anmeldest - kannst Du dann mit dem gezeigten Kommando den Status von WireGuard auslesen? Oder sind (ähnlich wie für Docker) spezielle Container-befehle nötig um eine executable in dem Container auszuführen? Ich würde das zumindest mal erwarten.

DrBakterius · 2022-09-06T15:49:17Z

Wenn ich mich mit dem angelegten User per SSH anmelde und den Befehl 'sudo wg show all dump' ausführe, wird der Status ausgegeben. Ohne 'sudo' kommt ein Fehler. Und den Schnittstellenname habe ich in der Ausgabe auch gesehen - der passt schon mit 'wg0'. Spezielle Befehle sind für Proxmox-Container nicht nötig.

Edit: ich habe mich mal von der Console des ioBroker-Rechners mittels 'ssh [email protected]' verbunden. Erst musste ich dem fingerprint zustimmen und dann hat er sich nach Eingabe des Passwort verbunden. Allerdings dauert der Verbindungsaufbau recht lange (ca. 25 Sekunden).

Edit2: Den langen Verbindungsaufbau konnte ich beheben. Trotzdem wird die Instanz nicht grün... :-(

Grizzelbee · 2022-09-06T17:25:52Z

Wenn ich mich mit dem angelegten User per SSH anmelde und den Befehl 'sudo wg show all dump' ausführe, wird der Status ausgegeben.

Das ist doch schon mal super. Mit Passwortabfrage, oder ohne?
Schick doch am besten mal ein komplettes Log - dann sieht man, was der Server so sagt. Denn wie gesagt: Man müsste eigentlich im Log sehen, was dem Server nicht passt.

Auf der dritte Seite den gleichen Hostnamen wie auf der ersten Seite angegeben,

Das ist genau richtig so.

bei 'Schnittstellenname' habe ich 'wg0' eingetragen (was gehört da genau rein?)

Das hängt von deiner WireGuard-Konfig ab. Laut deinen Angaben scheint das aber richtig so zu sein. wg0 ist auch defaut.
Aber das kann halt jeder so nennen, wie er gerne mag. Die WG-Konfig Datei könnte ja auch yippdidi.conf oder trallala.conf heißen. dann wäre halt yippdidi oder trallala richtig.

und dann den korrekten Pfad zur Konfigurationsdatei.

Okay. Das ist aber auch nur für das wiederherstellen suspendierter peers von Interesse. das hindert den Adapter nicht daran grün zu werden.
BTW: Wie lange wartest Du darauf ob der Grün wird? Denn der wird erst nach der ersten erfolgreichen Abfrage grün - also frühestens nach Ablauf des ersten Poll-Intervalls (default: 2 Minuten).

Meine Konfig sieht zum Beispiel so aus:
Um den Adapter grün zu bekommen, reicht aber die erste Seite vollkommen aus.
Die zweite braucht es nur um im adapter Klarnamen an den Peers zu haben unb die Dritte ist, wie gesagt, nur für den restore suspendierter Peers nötig.

DrBakterius · 2022-09-06T19:35:12Z

Erstmal danke für deine Unterstützung!

Wenn ich mich mit dem angelegten User per SSH anmelde und den Befehl 'sudo wg show all dump' ausführe, wird der Status ausgegeben.

Das ist doch schon mal super. Mit Passwortabfrage, oder ohne? Schick doch am besten mal ein komplettes Log - dann sieht man, was der Server so sagt. Denn wie gesagt: Man müsste eigentlich im Log sehen, was dem Server nicht passt.

Also die Abfrage funktioniert ohne Passwort. Also habe ich die sudoers-Datei richtig angepasst. Welches Log meinst du?

BTW: Wie lange wartest Du darauf ob der Grün wird? Denn der wird erst nach der ersten erfolgreichen Abfrage grün - also frühestens nach Ablauf des ersten Poll-Intervalls (default: 2 Minuten).

Ich habe mehrere Abfragen abgewartet. Hat leider nichts geändert. Meine Einstellungen sehen auch so aus wie bei dir.

Ich habe sogar den WireGuard-Server neu aufgesetzt und neu installiert. Und mal mein ganzes System neu gestartet. Leider bekomme ich den Adapter nicht zum Laufen.

Könnte ich die Punkte die dein Adapter abarbeitet auch mal auf der Console nachstellen und schauen ob so überhaupt etwas retour kommt?

Grizzelbee · 2022-09-06T20:24:04Z

Also die Abfrage funktioniert ohne Passwort. Also habe ich die sudoers-Datei richtig angepasst.

Sieht so aus, ja.

Welches Log meinst du?

Das, was du schon in deinem ersten Post geschickt hast (aslo ein ioBroker debug-Log), nur eben nicht bei "Executing command ..." abbrechen, sondern bis zum eigentlichen Lauf warten und erst danach den Adapter stoppen und dann alles hier posten. Du kannst für die Tests ja den POll-Intervall auf 30 oder so setzen, dann musst Du nicht so lange warten.

2022-09-06 17:12:06.324 - debug: wireguard.0 (1615446) Plugin sentry Initialize Plugin (enabled=true)
2022-09-06 17:12:06.959 - info: wireguard.0 (1615446) starting. Version 1.3.1 in /opt/iobroker/node_modules/iobroker.wireguard, node: v16.17.0, js-controller: 4.0.23
2022-09-06 17:12:07.020 - info: wireguard.0 (1615446) There is 1 wireguard host to monitor.
2022-09-06 17:12:07.021 - info: wireguard.0 (1615446) Started 60 seconds monitoring interval for host [MEINHOST]
2022-09-06 17:13:07.022 - debug: wireguard.0 (1615446) Retrieving WireGuard status of host [MEINHOST] on address [192.168.1.105]
2022-09-06 17:13:07.024 - debug: wireguard.0 (1615446) Executing command [sudo wg show all dump] on host 192.168.1.105.

ch habe sogar den WireGuard-Server neu aufgesetzt und neu installiert. Und mal mein ganzes System neu gestartet. Leider bekomme ich den Adapter nicht zum Laufen.

Das knobeln wir schon raus. Keine Sorge.

Könnte ich die Punkte die dein Adapter abarbeitet auch mal auf der Console nachstellen und schauen ob so überhaupt etwas retour kommt?

Ja. Kannst Du. Im Grunde hast Du das auch schon. Wenn ich mich recht entsinne habe ich das auch schon in der Readme dokumentiert.

Was der Adater macht:

Öffnen eines Terminals (aka console) mittels einer SSH-Verbindung zum WireGuard Server => ssh 192.168.1.105 (auf Port 22 - default ssh port) .
Login mittels des Users und Passwortes, die im Adapter konfiguriert sind.
Ausführen des Kommandos: wg show all dump (je nach aktivierten Optionen mit/ohne sudo und oder Docker Kommandos. In deinem Fall: sudo wg show all dump (siehe auch den Log-eintrag dazu - unterste Zeile)

Dann erwartet der Adapter einen Output aus dem wg Kommando. Das sollte so aussehen:

Das wird dann geparst und in Datenpunkte übernommen.

Am besten loggst Du dich auf einer Console an deinem ioBroker Server ein. Damit Du von genau diesem Server eine ssh-Verbindung zum WireGuard Server aufbauen kannst - weil der Adapter genau das ja auch tut.
Also: ssh [email protected]; dann passwort eingeben und dann sudo wg show all dump - WICHTIG! bei diesem Aufruf darf KEINE Passworteingabe nötig sein!! Wenn das alles funktioniert sollte der Adapter auch laufen. Aber wie gesagt: Im Debug-Log sollten wir sehen können was quer geht.

EDIT:
Moment mal ... aus der Readme:

info.connection of the adapter is used to indicate that at least one WireGuard interface is online and reported by wg show all. If no Wireguard interface is online - nothing is reported. In that case an error gets logged and the adapters' traffic light turns yellow.

Dein WireGuard ist aber schon gestartet - also up & running, oder?

DrBakterius · 2022-09-07T15:36:12Z

Vielen Dank für deine Mühe. Alles hat funktioniert wie du es beschrieben hast (ssh-Verbindung aufbauen, Kommando absetzen (kein Passwort notwendig, Output wird korrekt angezeigt). Aber leider wird der Adapter nicht grün.

Im Log wiederholen sich die beiden Zeilen jede Minute:

2022-09-06 17:13:07.022 - debug: wireguard.0 (1615446) Retrieving WireGuard status of host [MEINHOST] on address [192.168.1.105]
2022-09-06 17:13:07.024 - debug: wireguard.0 (1615446) Executing command [sudo wg show all dump] on host 192.168.1.105.
2022-09-06 17:14:07.025 - debug: wireguard.0 (1615446) Retrieving WireGuard status of host [MEINHOST] on address [192.168.1.105]
2022-09-06 17:14:07.027 - debug: wireguard.0 (1615446) Executing command [sudo wg show all dump] on host 192.168.1.105.

usw. Da kommt sonst nichts.

Ich habe mir jetzt aber so beholfen, dass ein Bash-Skript das per cron jede Minute ausgeführt wird, die verbundenen Peers in einen Datenpunkt auf ioBroker schreibt. Das funktioniert ohne Probleme. Mach dir also keine weitere Arbeit... ;-)

Falls es interessiert:

#!/bin/bash

###################################
#                                 #
# Skript ermittelt die aktuell    #
# verbundenen WireGuard Peers     #
# und übergibt sie an ioBroker.   #
#                                 #
###################################

# Timestamp
	time=`date +%s`

# Hier neue Geräte mit Namen und fortlaufender Nummer eintragen
	namen[0]=Handy
	geraete[0]=lkhshJKJHSAjk438hGC5****************u3Otk04=

	namen[1]=Tablet
	geraete[1]=HzbgFF654fJz4FvVoHehtx****************nUT14=
	
	namen[2]=PC
	geraete[2]=iO+hGb85ZzU62bF9DVf+T8U****************VnEM=
	
	namen[3]=Laptop
	geraete[3]=5GhdE9h6l*bBvh93SC****************bq/ysDmwU=
	
		
# Verbindungsdaten einlesen
	wg=`wg show all dump`

# Abfragen abarbeiten
	anzahl=${#geraete[*]}	# Anzahl feststellen
	i=0
	while [ $i -lt $anzahl ]; do
		# wann war das Gerät zuletzt verbunden?
		verbunden=$(echo "$wg" | grep "${geraete[$i]}" | awk '{print $6}')
		verbunden=$[$time-$verbunden]
		# wenn es weniger als 130 Sekunden her ist
		if (( $verbunden < 130 )); then
			Clients="$Clients${namen[$i]}|"
			echo "${namen[$i]} -> $verbunden Sekunden"
		fi
		i=$[$i+1]
	done
# In Datenpunkt von ioBroker schreiben und
# dabei das letzte Zeichen (|) entfernen
	Erg=$(curl -s http://192.168.200.10:8082/set/javascript.0.WireGuard-Clients?value=${Clients%?})

Kommt dann z.B. als Tablet|Laptop im Datenpunkt an und kann bei Bedarf weiterverarbeitet werden...

Grizzelbee · 2022-09-07T16:15:04Z

Alles Klar. Ich denke ich habe jetzt die Lösung - das Log bringt es an den Tag!
Ich bin da im Zusammenhang mit Docker schon drüber gestolpert. Das Schlüsselwort lautet: Pseudo-tty (denke ich).

Das Problem ist, dass der ssh Client die Daten (die Textausgaben von wg show ...) aus dem Container nicht empfängt.
Die Terminals (ssh client an ssh server) sind unter Linux über sogenannte pseudo-ttys miteinander verbunden und tauschen darüber die Daten aus - und das ist auch der Unterschied zwischen deiner manuell geöffneten Konsole und der des Adapters.
Das habe ich bei der Erweiterung für Docker schon einmal umstellen müssen, weil die Daten aus den Container ebenfalls nciht ankamen - genau wie bei dir.

Ich muss jetzt nur noch rausbekommen, welche Einstellung die richtige für LXC ist.
Da gibt es nämlich einen ganzen Schwung von: ssh2#pseudo-tty-settings

EDIT:
kannst Du dich bitte mal gegen deinen WireGuard Container connecten, env eingeben und mir sagen was bei den beiden Variablen TERMund SSH_TTY steht?

DrBakterius · 2022-09-07T16:42:36Z

kannst Du dich bitte mal gegen deinen WireGuard Container connecten, env eingeben und mir sagen was bei den beiden Variablen TERMund SSH_TTY steht?

Per ssh über den ioBroker-Container beim WireGuard-Container eingeloggt und mit env folgendes erhalten:
TERM=xterm
SSH_TTY=/dev/pts/3

fixes #38 pseudo-tty settings

Grizzelbee · 2022-09-07T19:17:03Z

Danke für die infos.

Ich habe mal eine neue vesion gebaut.
Probiere die doch bitte mal aus. Ich hoffe das es mit der klappt.

DrBakterius · 2022-09-08T05:39:38Z

Sorry, gleiches Verhalten. :-(

2022-09-08 07:34:49.761 - debug: wireguard.0 (1208001) Redis Objects: Use Redis connection: 127.0.0.1:9001
2022-09-08 07:34:49.854 - debug: wireguard.0 (1208001) Objects client ready ... initialize now
2022-09-08 07:34:49.856 - debug: wireguard.0 (1208001) Objects create System PubSub Client
2022-09-08 07:34:49.859 - debug: wireguard.0 (1208001) Objects create User PubSub Client
2022-09-08 07:34:49.968 - debug: wireguard.0 (1208001) Objects client initialize lua scripts
2022-09-08 07:34:49.976 - debug: wireguard.0 (1208001) Objects connected to redis: 127.0.0.1:9001
2022-09-08 07:34:50.032 - debug: wireguard.0 (1208001) Redis States: Use Redis connection: 127.0.0.1:9000
2022-09-08 07:34:50.071 - debug: wireguard.0 (1208001) States create System PubSub Client
2022-09-08 07:34:50.073 - debug: wireguard.0 (1208001) States create User PubSub Client
2022-09-08 07:34:50.147 - debug: wireguard.0 (1208001) States connected to redis: 127.0.0.1:9000
2022-09-08 07:34:50.495 - debug: wireguard.0 (1208001) Plugin sentry Initialize Plugin (enabled=true)
2022-09-08 07:34:50.999 - info: wireguard.0 (1208001) starting. Version 1.3.2 (non-npm: Grizzelbee/ioBroker.wireguard) in /opt/iobroker/node_modules/iobroker.wireguard, node: v16.17.0, js-controller: 4.0.23
2022-09-08 07:34:51.056 - info: wireguard.0 (1208001) There is 1 wireguard host to monitor.
2022-09-08 07:34:51.057 - info: wireguard.0 (1208001) Started 20 seconds monitoring interval for host [Test]
2022-09-08 07:35:11.059 - debug: wireguard.0 (1208001) Retrieving WireGuard status of host [Test] on address [192.168.1.105]
2022-09-08 07:35:11.061 - debug: wireguard.0 (1208001) Executing command [sudo wg show all dump] on host 192.168.1.105.
2022-09-08 07:35:31.069 - debug: wireguard.0 (1208001) Retrieving WireGuard status of host [Test] on address [192.168.1.105]
2022-09-08 07:35:31.070 - debug: wireguard.0 (1208001) Executing command [sudo wg show all dump] on host 192.168.1.105.
2022-09-08 07:35:51.071 - debug: wireguard.0 (1208001) Retrieving WireGuard status of host [Test] on address [192.168.1.105]
2022-09-08 07:35:51.072 - debug: wireguard.0 (1208001) Executing command [sudo wg show all dump] on host 192.168.1.105.
2022-09-08 07:35:54.976 - info: wireguard.0 (1208001) Got terminate signal TERMINATE_YOURSELF
2022-09-08 07:35:54.977 - info: wireguard.0 (1208001) Clearing interval for host [Test]
2022-09-08 07:35:54.978 - info: wireguard.0 (1208001) terminating
2022-09-08 07:35:54.979 - debug: wireguard.0 (1208001) Plugin sentry destroyed
2022-09-08 07:35:54.980 - info: wireguard.0 (1208001) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

Grizzelbee · 2022-09-08T15:29:25Z

Schade - ich dachte ich hätte es gefunden. Nachdem ich habe heute noch einmal in den Code geschaut und ein bisschen gelesen habe, konnte das auch nicht die Lösung sein.

Ich habe dabei aber im ioBroker-Forum etwas wieder gefunden:
https://forum.iobroker.net/topic/52647/tester-f%C3%BCr-wireguard-adapter-gesucht/50

Es kann also nicht am LXC als solchem liegen. Und der Blick in den Code hat mir verraten, dass gar keine ssh Verbindung zustande kommt. Die geht einfach so kaputt, ohne das es eine (sichtbare) Fehlermeldung gibt - warum? Keine Ahnung. Aber das Fazit ist erst einmal: Es liegt nicht am Adater, sondern irgendwie in der Konfig deines Servers.

DrBakterius · 2022-09-08T18:18:06Z

Das mit den 30 Sekunden habe ich ja gelöst bekommen (nesting eingeschalten). Jetzt wird per ssh sofort und ohne Verzögerung die Verbindung hergestellt.

Aber wie schon geschrieben, ich habe für mich eine Lösung gefunden. Mit einem Adapter wäre die Verwaltung zwar einfacher, aber damit kann ich auch leben. So oft ändern sich bei mir die Peers nicht.

Doch vielleicht findest du noch eine Lösung, dann teste ich gerne wieder. Vielleicht per Public Key? Dann bräuchte man nur den username und die IP aber kein Passwort. Ich mache das erfolgreich per Shell-Skript vom ioBroker-LXC auf einen anderen LXC.

DrBakterius closed this as completed Sep 7, 2022

Grizzelbee reopened this Sep 7, 2022

Grizzelbee changed the title ~~Die Instanz wird nicht grün~~ pseudo-tty liefert keine Daten aus LXC container Sep 7, 2022

Grizzelbee added bug Something isn't working Fixed It's a bug has been fixed. This feature has been implemented. labels Sep 7, 2022

Grizzelbee closed this as completed in e7260f9 Sep 7, 2022

Grizzelbee added a commit that referenced this issue Sep 7, 2022

Merge pull request #39 from Grizzelbee/fix_pseudo_tty_bug

cf6e916

fixes #38 pseudo-tty settings

Grizzelbee reopened this Sep 7, 2022

Grizzelbee closed this as completed Apr 25, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

pseudo-tty liefert keine Daten aus LXC container #38

pseudo-tty liefert keine Daten aus LXC container #38

DrBakterius commented Sep 6, 2022 •

edited

Loading

Grizzelbee commented Sep 6, 2022

DrBakterius commented Sep 6, 2022 •

edited

Loading

Grizzelbee commented Sep 6, 2022

DrBakterius commented Sep 6, 2022

Grizzelbee commented Sep 6, 2022 •

edited

Loading

DrBakterius commented Sep 7, 2022

Grizzelbee commented Sep 7, 2022 •

edited

Loading

DrBakterius commented Sep 7, 2022

Grizzelbee commented Sep 7, 2022

DrBakterius commented Sep 8, 2022

Grizzelbee commented Sep 8, 2022

DrBakterius commented Sep 8, 2022

pseudo-tty liefert keine Daten aus LXC container #38

pseudo-tty liefert keine Daten aus LXC container #38

Comments

DrBakterius commented Sep 6, 2022 • edited Loading

Grizzelbee commented Sep 6, 2022

DrBakterius commented Sep 6, 2022 • edited Loading

Grizzelbee commented Sep 6, 2022

DrBakterius commented Sep 6, 2022

Grizzelbee commented Sep 6, 2022 • edited Loading

DrBakterius commented Sep 7, 2022

Grizzelbee commented Sep 7, 2022 • edited Loading

DrBakterius commented Sep 7, 2022

Grizzelbee commented Sep 7, 2022

DrBakterius commented Sep 8, 2022

Grizzelbee commented Sep 8, 2022

DrBakterius commented Sep 8, 2022

DrBakterius commented Sep 6, 2022 •

edited

Loading

DrBakterius commented Sep 6, 2022 •

edited

Loading

Grizzelbee commented Sep 6, 2022 •

edited

Loading

Grizzelbee commented Sep 7, 2022 •

edited

Loading