[C] Web GUI

[KillerPinockel]

Hallo,

ich möchte gern ein UI bauen, welches zur Steuerung meines C Programms dienen soll.

Der Nutzer soll die Website öffnen und dann per Formular seine Parameter eingeben. Nach dem Klick auf senden, soll das C Programm mit den Parametern starten.
Entwickelt wurde unter Linux (OpenSuse) und XAMPP ist bereits installiert. Webserserver, Programm und DB-Server laufen alles auf einer Maschine.
Jetzt weiß ich aber nicht so richtig, wie ich weiter machen soll. Das Formular habe ich erstmal per HTML erstellt. Später soll auch ein kleiner DB Zugriff folgen um bspw. Parameter als Vorgabe zu speichern.

Ich hoffe Ihr könnt mir weiterhelfen.

Danke und viele Grüße!

 

[blöderidiot]

Der Nutzer soll die Website öffnen und dann per Formular seine Parameter eingeben. Nach dem Klick auf senden, soll das C Programm mit den Parametern starten. Entwickelt wurde unter Linux (OpenSuse) und XAMPP ist bereits installiert. Webserserver, Programm und DB-Server laufen alles auf einer Maschine.
Jetzt weiß ich aber nicht so richtig, wie ich weiter machen soll. Das Formular habe ich erstmal per HTML erstellt. Später soll auch ein kleiner DB Zugriff folgen um bspw. Parameter als Vorgabe zu speichern.

Am einfachsten ist es mit PHP. See also: exec().

 

[Valhal]

Für dein Problem gibt es eine perfekte Technologie Common Gateway Interface https://de.wikipedia.org/wiki/Common_Gateway_Interface

 

[KillerPinockel]

Danke für die Antworten.

Ich habe es mit exec() probiert und das klappt auch aber nun kam mir eine weitere Idee. Ich kann zwar mehrmals das Programm aufrufen, jedoch teilen dies beiden Prozesse dann die Leistung des Rechners.
Ist es möglich so etwas wie eine Warteschlange zu bauen? Man kann beliebig oft das Programm zum starten animieren, jedoch läuft immer nur eine Instanz gleichzeitig, Ist das mit CGI möglich oder sogar mit php?

 

[Baumfaust]

Merk dir doch einfach in PHP in einer Variable (möglichweise diesen Wert in eine datei schreiben), ob dein Programm mit exec() ausgeführt wurde. Wenn ja, dann push den neuen Aufruf in eine queue, falls nicht, dann starte exec(). Dann musst du nur noch herausfinden, wann der erste Aufruf beendet wird (Rückgabewert?) und du kannst den nächsten Befehl aus der queue poppen. Bin kein PHP Entwickler, weiß nicht ob exec() blockiert, aber nur mal so als Brainstorming.

 

[Valhal]

Ich würde die Logik in ein C Programm einbauen... Ein C Programm zur Steuerung deines echten Programms mit Warteschlange, Eingabevalidierung, HTML Ausgabe, usw.

 

[Daaron]

Bin kein PHP Entwickler, weiß nicht ob exec() blockiert....

Kann ich aus der Kalten auch nicht sagen, aber es spielt auch keine Rolle.
Wenn man nicht gerade einen PHP-basierten Socket schreibt, sondern ein klassisches PHP-Script, dass im Webserver läuft, dann wird es beim Formular-Submit aufgerufen, läuft durch und terminiert sich rückstandslos. PHP ist zustandslos, jeder Request an ein PHP-Script findet dieses unwissend wie ein Neugeborenes vor. Lediglich Session-Variablen und externe Speichermedien überdauern.

Für diesen Fall hier, und das "Queue-Konzept", bedeutet das: Die Warteschlange muss irgendwo extern gelagert werden, z.B. in einer Datenbank. Da wir nicht mit Kanonen auf Spatzen schießen wollen, verwenden wir doch einfach SQLite. Reicht vollkommen.

Ich würde das Ganze in 2 Teile Splittern:
1.) Ein Script für den Webserver, dass das Formular darstellt und nach Submit verarbeitet. Dieses Script schreibt den durch das Formular angeforderten Befehl in eine Warteschlangen-Tabelle in der SQL-Datenbank.
2.) Ein PHP-CLI Commandline-Script (braucht keinen Webserver & unterliegt quasi keinem Memory- oder Zeitlimit), dass die Queue Stück für Stück abarbeitet. Dieses PHP-Skript darf, weil es eben für PHP-CLI ist, eine Endlosschleife sein. Das Skript geht jetzt die Warteschlangen-Tabelle von oben nach unten durch, ruft den jeweils ersten Befehl per exec() auf und wartet, bis exec() die Antwort des Befehls zurück gibt (also fertig ist). Jetzt löscht es den Eintrag aus der Tabelle und holt sich den nächsten "ersten". Ist kein Befehl vorhanden, dreht das Script halt als Endlosschleife hirnlos Däumchen.

 

[KillerPinockel]

Danke für eure vielen Ideen. Haben mir sehr weitergeholfen.
Nun sitzt ich aber seit 2 Tagen an einem etwas kniffligen Problem.

Der Start des Programms klappt super. Leider gibt es einen Haken. In dem Programm wird ein Linux Befehl genutzt, der Root Rechte braucht. Natürlich hat der User "daemon" von Apache diese Rechte nicht. Somit kann dieser Befehl nicht ausgeführt werden.
Gibt es da ein Work-around?

 

[Daaron]

wenn du meine PHP-CLI - Lösung verwendet hast, kannst du die natürlich als Root laufen lassen.

 

[KillerPinockel]

Ah Sorry hab vergessen zu erwähnen, dass ich mit der Warteschlange noch gar nicht weiter gemacht habe. Mein Code sieht erstmal so aus:

$size = ob_get_length();
header("Content-Length: $size");
header('Connection: close');
ob_end_flush();
ob_flush();
flush();
if (session_id()) session_write_close();

exec("PROGRAMM");
exec("pgrep PROGRAMM", $pids);

if(empty($pid)) {

$nachricht = "Laufzeit beendet!";
$nachricht = wordwrap($nachricht, 70);
mail($email, "Ende!", $nachricht);
}

 

[Daaron]

Dann wird das eher nix, ohne wirklich kritische Sicherheitsprobleme ins System zu bringen.

 

['cuda]

Was willst Du überhaupt machen?

Ein exec() auf das BS ist absolut hässlich und macht man einfach nicht. Damit reißt Du ein sehr großes Sicherheitsloch rein.

Wegen der Warteschlange: Du könntest eine Queue implementieren, in die Deine GUI Aufgaben reinstopft. Parallel dazu läuft ein Worker und nimmt aus der Queue die Aufgaben und arbeitet sie ab. Das ist klassische Implementierung für sowas.

 

[westef]

Der Start des Programms klappt super. Leider gibt es einen Haken. In dem Programm wird ein Linux Befehl genutzt, der Root Rechte braucht. Natürlich hat der User "daemon" von Apache diese Rechte nicht. Somit kann dieser Befehl nicht ausgeführt werden.
Gibt es da ein Work-around?

Entweder per sudo Rechte für das entsprechende Programm verteilen oder das SUID-Bit setzen und root als Dateiowner setzen.