Logikbaustein - 19001240 - Internet Speedtest

[DustinR]

Naja, aber genau das könnte das Problem sein.
In einer VM ohne sudo sehe ich dasselbe Verhalten wie bei dir.
Daher könnte es daran liegen. Warum gibt es sudo im Container nicht?

Warum es sudo nicht gibt, da bin ich nicht ganz sicher. Die Grundlage von Proxmox ist glaube ich Debian, wo es das so nicht gibt. Auch wenn es ein Centos7-Container am Ende ist.

Aber wenn ich auf der Konsole auch ohne sudo das korrekte Ergebnis bekomme, dann müsste es ja in der Theorie funktionieren? Da sehe ich ja auch das JSON, was mir zurückgegeben wird.

[jonofe]

Die Grundlage von Proxmox ist glaube ich Debian, wo es das so nicht gibt.

Auch in Debian gibt es sudo.

Aber wenn ich auf der Konsole auch ohne sudo das korrekte Ergebnis bekomme, dann müsste es ja in der Theorie funktionieren? Da sehe ich ja auch das JSON, was mir zurückgegeben wird.

In der Theorie ja, aber in der Praxis leider nicht. Ist bei mir genauso, d.h. in der VM funktioniert es, aber aus EDOMI heraus nicht ohne sudo. Hab da lange rumgesucht, aber die Ursache nicht gefunden.

[DustinR]

Ja, aber das ist doch grundsätzlich nicht mein Problem? Es gibt ja hier auch schon andere, die deinen Baustein ohne sudo einsetzen.

Und wenn ich auf der Konsole in der VM ein korretes Ergebnis bekomme, dann liegt das Problem doch eher im PHP und dem Verhalten von shell_exec? Oder bin ich in der falschen Richtung unterwegs?

[jonofe]

die deinen Baustein ohne sudo einsetzen.

Aber nur im Docker Container, soweit hier diskutiert.

Und wenn ich auf der Konsole in der VM ein korretes Ergebnis bekomme, dann liegt das Problem doch eher im PHP und dem Verhalten von shell_exec?

Nein, denn in einem PHP Skript mit shell_exec, welches am von der Konsole startet, funktioniert es, d.h. es liegt weder an php noch an shell_exec().
Es liegt irgendwie daran, wie die PHP Prozesse von EDOMI gestartet werden. Und da dasselbe Problem bereits in einer normalen VM (und vermutlich auch bare metal) auftritt und sich mit sudo beheben lässt, liegt die Vermutung doch nahe, dass es beim LXC Container dieselbe Ursache ist. Da ich da schon ziemlich viel Aufwand in die Ursachenforschung gesteckt habe, ist halt die Frage, ob es nicht einfach ist, "sudo" in deinem Container verfügbar zu machen, als die Ursache in EDOMI zu finden. Ich für meinen Teil stecke keinen Aufwand mehr in die Ursachenforschung, würde mich aber natürlich freuen, wenn du die Ursache findest.

[DustinR]

Das Problem kommt nicht von Edomi. Ich habe ja meine PHP-Testdatei:

$output = shell_exec('/usr/bin/speedtest --accept-license --accept-gdpr -p no -f json');
echo "<pre>$output</pre>"; 

Und die gibt mir ja auch kein Ergebnis.

Ein einfaches:

$output = shell_exec('ls');
echo "<pre>$output</pre>"; 

funktioniert aber wieder ohne Probleme.

Es muss also irgendwie am PHP liegen. Bzw. kann es ja vielleicht wirklich sein, dass der PHP-Prozess nicht ausreichend Rechte hat, um den Speedtest auszuführen. Da werde ich auch mal wieter testen.

[jonofe]

Und die gibt mir ja auch kein Ergebnis.

Mir aber. Du darfst es nicht aus dem Browser machen, denn EDOMI führt dass auch nicht über den Browser aus, sondern via php-cli.

[root@edomi-test ~]# cat speed.php
<?php

$output = shell_exec('/usr/bin/speedtest --accept-license --accept-gdpr -p no -f json');
echo $output;

?>
[root@edomi-test ~]# php speed.php
{"type":"result","timestamp":"2022-02-17T13:53:27Z","ping":{"jitter":0.33300000000000002 ,"latency":10.948},"download":{"bandwidth":6637651 ,"bytes":69340320,"elapsed":10609},"upload":{"band width":1452932,"bytes":5823360,"elapsed":4009},"is p":"O2 Deutschland","interface":{"internalIp":"10.0.80.23 ","name":"ens192","macAddr":"00:50:56:00:00:12","i sVpn":false,"externalIp":"85.182.220.191"},"server ":{"id":33397,"host":"speedtest.philunet.de","port ":8080,"name":"PHILUNET GmbH","location":"Dusseldorf","country":"Germany", "ip":"185.232.100.189"},"result":{"id":"853d03 2f-f2e7-45d3-94fb-9e043837b378","url":"https://www.speedtest.net/result/c/853d032f-f2e7-45d3-94fb-9e043837b378","persisted":true}}

Daran kann man sehen, dass das Binary grundsätzlich via php und shell_exec() ausführbar ist.
Nur macht EDOMI das irgendwie anders. Es liegt an der Kombination EDOMI und dem speedtest Binary.

[DustinR]

Sehr spannend.... EDOMI ist schon irgendwie magisch. :-)

Hab mal in meinem Container etwas mit SUDO gespielt und dann geht es auch tatsächlich.

yum install sudo
nano /etc/sudoers
apache ALL=NOPASSWD:/usr/bin/speedtest

Also erst sudo installieren und dann in der sudoers dem Apache die Möglichkeit gegeben, dass er auch den Speedtest ausführen darf. Edomi macht quasi alles als root und im Container passiert viel über den Apache.... der natürlich nicht alles darf. ;-)

[jonofe]

Also erst sudo installieren und dann in der sudoers dem Apache die Möglichkeit gegeben, dass er auch den Speedtest ausführen darf.

Das ist aber nur für dein spezielles Testskript notwendig, nicht um den Speedtest als LBS laufen zu lassen. Denn das mach EDOMI als root.
Nur die Aktionen in der VISU laufen als apache: Die einfache Installation von sudo würde also reichen, um den LBS im LXC mit E6=1 lauffähig zu haben.

Dem apache User sudo Rechte zu geben ist aus Security Gesichtspunkten auch keine besonders gute Idee. (auch wenn es nur für ein Binary ist)

[DustinR]

Das ist aber nur für dein spezielles Testskript notwendig, nicht um den Speedtest als LBS laufen zu lassen. Denn das mach EDOMI als root.
Nur die Aktionen in der VISU laufen als apache: Die einfache Installation von sudo würde also reichen, um den LBS im LXC mit E6=1 lauffähig zu haben.

Dem apache User sudo Rechte zu geben ist aus Security Gesichtspunkten auch keine besonders gute Idee. (auch wenn es nur für ein Binary ist)

DANKE! :-) Das war auch nochmal ein guter Hinweis. Meine Geduld ist nun auch am Ende. Ich hab auf meinem Produktivsystem nun auch SUDO installiert und nun läuft das.

Schönen Abend noch

[starwarsfan]

Guten Abend miteinander,

bevor ich hier ins Detail gehe: Wenn jemand hier ein Edomi-Standard-Setup hat, also "echt" installiert nach Edomi-Docu, ist da dann sudo installiert oder nicht? Ich gehe schwer davon aus, dass es da kein sudo gibt, da ich das Setup des Image damals nach dem Schema einer nativen Installation aufgebaut habe.

Alles weitere hängt dann von der Antwort auf die obige Frage ab...

[DustinR]

Hey starwarsfan ,

ich bin fast sicher, dass SUDO normalerweise im Standard dabei ist. Ich habe mir nun 2 meiner Standardinstallationen angesehen, was das Centos7Minimal-Image als Grundlage hat, und bei beiden ist SUDO installiert.

Ich bin mir eigentlich sicher, dass ich das nie nachinstalliert habe.

Viele Grüße
Dustin

[starwarsfan]

Hallo miteinander,

ich habe nun mal testweise eine VM mit dem 7.6er Iso von der Edomi-Seite aufgesetzt und dort ist tatsächlich sudo installiert. Das kann ich in den Images und Templates natürlich auch noch installieren, daran soll's nicht scheitern.

Ich habe sowohl in der VM als auch im Container Speedtest installiert. Da das als Root passiert, ist sudo für die Installation nicht notwendig. Also geht das auch so:

curl -s https://install.speedtest.net/app/cli/install.rpm.sh | bash
yum install speedtest

Warum sich das im Container anders verhält, ist mir gestern auf der Skipiste in den Sinn gekommen. Ich gehe schwer davon aus, dass es einen Unterschied bei den Prozess-IDs im Container gibt. In einem Container werden normalerweise keine unterschiedlichen PIDs verwendet, da nach "der reinen Lehre" im Container nur genau ein Dienst laufen soll(te). Dieser Dienst soll(te) mit genau der richtigen PID laufen, was normalerweise nicht root ist. Edomi ist nun dahingehend "speziell", da im Container verschiedene Dienste laufen und der Webserver als der Herr im Hause das System auch noch herunterfahren kann. Wenn nun im Container der ausführende httpd-Prozess als root und nicht als httpd läuft, dann kann er "speedtest" natürlich ohne sudo aufrufen. Und genau hier muss der Unterschied zwischen VM und Container sein...

Aber wie auch immer, in der nächsten Version des Containers wird sudo installiert sein und das Verhalten aus Sicht des LBS ist wieder identisch.

[jonofe]

Da das als Root passiert, ist sudo für die Installation nicht notwendig.

Das hab ich auch gedacht. Ist aber nicht so. Auch nicht in einer VM. Da geht es nur mit sudo. Das ist wohl für VM als auch für LXC so.
Nur mit docker scheint es auch ohne sudo zu funktionieren. Frag mich nicht warum. Das Problem gibts auch nur für dieses spezielle Binary "speedtest". Bei allen anderen Befehlen funktioniert es wie erwartet. Hab alles was mir einfiel probiert, aber am Ende gings nur mit sudo auch wenn es als User root aus edomi startet.

[starwarsfan]

Hoi André

Das hab ich auch gedacht. Ist aber nicht so. Auch nicht in einer VM. Da geht es nur mit sudo. Das ist wohl für VM als auch für LXC so.

Ähm, jetzt haust Du hier aber was durcheinander. Mein Zitat spricht ausschliesslich von der Installation und die geht sehr wohl ohne sudo. Ich hätte das nicht geschrieben, wenn ich's nicht genau so gemacht hätte, sowohl im Container als auch in der VM. Das wäre ja übel, wenn man als root noch zwingend sudo brauchen müsste...

Nur mit docker scheint es auch ohne sudo zu funktionieren. Frag mich nicht warum. Das Problem gibts auch nur für dieses spezielle Binary "speedtest". Bei allen anderen Befehlen funktioniert es wie erwartet. Hab alles was mir einfiel probiert, aber am Ende gings nur mit sudo auch wenn es als User root aus edomi startet.

Da wäre die Frage, wie genau Du sichergestellt hast, dass es in der VM aus Edomi heraus als root gestartet wurde!? Denn als "echter" root, also auf der Cmdline, funktionierts ja ohne sudo:

VM:

[root@edomi ~]# speedtest

   Speedtest by Ookla
...

Container:

[root@e9f98e9a57fb /]# speedtest

   Speedtest by Ookla
...

[jonofe]

Dein Zitat spricht zwar von der Installation, aber das war ja nicht wirklich das Problem. Es ging eigentlich immer um die Ausführung von speedtest aus Edomi heraus, denn das ist das Problem. Die Installation geht natürlich als root ohne sudo.

Welche Optionen gibt es denn etwas als root auszuführen? Die php Logik Engine läuft ja als echter root und von dort habe ich per system(), exec(), shell_exec() (you name it, I tried it) ausprobiert (auch mit verschiedenen shells) speedtest zu starten. Alles ohne Erfolg. Mit sudo geht es dann. Warum auch immer. Im docker Container gehts offensichtlich nur ohne sudo. Ich vermute es liegt irgendwie an einer abweichenden Umgebungskonfiguration, wenn ich es aus Edomi starte, aber da hat auch ein Start in einer expliziten bash nichts geholfen. Wenn dir noch was einfällt wäre das super, ansonsten halt optional per sudo...