- Mitglied seit
- 15. Mai 2008
- Beiträge
- 21.900
- Punkte für Reaktionen
- 14
- Punkte
- 0
HINWEIS: Viele der hier beschriebenen Änderungen am System erledigt mittlerweile das Paket "init_3rdparty.spk"! Dieses ist deutlich einfacher zu installieren.
hi leutz,
nachdem doch nun schon eine Reihe von Beispielen existieren, möchte ich mal zusammenfassen, was man beim Einbau einer 3rd-party-Application bedenken muss. Unter anderem, weil es doch paar Voraussetzungen gibt, deren Wiederholung nicht bei jedem Beitrag nötig wäre.
(1) Die Integration in den Disk Station Manager einer 3rd-party-apps macht nur Sinn für den User admin. Meldet man sich mit einem anderem User an, sieht man die 3rd-party-apps nicht (vielleicht ändert sich das mal).
(2) Der User admin sollte sich immer über https anmelden (freischalten im Menü Netzwerkdienste->Webdienste), also über Port 5001. Es kann sein, dass sonst irgendwelche Nebeneffekte auftreten, die unerwünscht wären oder die bisherigen Beispielen angepasst werden müssten oder dass auch Dritte auf die Skripte zugreifen könnten oder oder oder ...
Hintergrundinformation: Der Apache-Webserver (httpd), der die Disk Station Oberfläche ausgibt, läuft mit den Rechten des root-Benutzers, was normalerweise eher unüblich ist. Aber es muss halt sein, weil sonst keine Systemadministration möglich wäre.
(3) Die Öffnung von Port 5000 und 5001 auf dem Router, um den Disk Station Manager auch aus dem Web her zu bedienen, sollte gut überlegt werden. Es ist prinzipiell ein Sicherheitsrisiko damit verbunden. (Diese Diskussion wurde schon/sollte an anderer Stelle weitergeführt werden)
(4) Die Konfigurations-Eintragungen für die 3rd-party-Applications werden im Verzeichnis /usr/syno/synoman/webman/3rdparty vorgenommen. Für jeden 3rdparty-Eintrag braucht man ein Verzeichnis. In diesem Verzeichnis muss mindestens eine application.cfg angelegt werden. Weitere Dateien, wie Bilder, cgi-Dateien usw. sind möglich. Eine genaue Anleitung findet man hier bzw. hier. Eine minimale application.cfg kann so aussehen:
test = My app
description = This is my app
type = embedded
path = /phpsrc/my_app/index.php
Anmerkung: Mit der Anlegen der ersten 3rd-party-apps-application.cfg-Datei erscheint automatisch das 3rd-party-Menü im Disk Station Manager (neu laden im Browser natürlich). Es muss also nichts besonderes installiert sein - außer Firmware 637 und größer.
(5) Die 3rd-party-Application läuft in einem HTML-iframe; kann man sich in der Datei /usr/syno/synoman/webman/modules/appebd.html ansehen. Die integrierte 3rd-party-Application wird demnach wie ein ganz normaler Link auf einer Seite aufgerufen. Alles was man sonst in einem Browser-Fenster aufrufen könnte, geht hier auch.
(6) Eine Möglichkeit, interaktiv mit Web-(Apache-)Anwendungen umzugehen, sind Skript-Programme, die der Apache-Webserver versteht. Was der Apache alles verstehen kann und könnte, wird per Konfigurationsdatei beschrieben. In diesem speziellen Fall (sys-Apache) ist es folgende Datei: /usr/syno/apache/conf/httpd.conf-sys. Wann immer man dort etwas ändert und hinzufügt, muss der Apache es lernen. Dafür muss er neu gestartet werden mit /usr/syno/etc/rc.d/S97apache-sys.sh restart.
(7) Damit der sys-Apache auch PHP-Skripte verstehen kann, muss er in der /usr/syno/apache/conf/httpd.conf-sys zwei zusätzliche Einträge erhalten:
AddType application/x-httpd-php .php
LoadModule php5_module /lib/libphp5.so
(8) Damit der sys-Apache auch auf alle Linux-Systemkommandos und alle Dateien zugreifen kann, sind weitere Veränderungen in der /usr/syno/apache/conf/httpd.conf-sys nötig (bitte die Zeilen suchen und genau vergleichen):
<Directory />
Options ExecCGI FollowSymLinks MultiViews Indexes
AllowOverride All
</Directory>
<Directory "/usr/syno/synoman">
Options ExecCGI FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>
<IfModule dir_module>
DirectoryIndex index.html index.htm index.cgi index.php
</IfModule>
<IfModule mime_module>
...
AddHandler cgi-script .cgi
...
</IfModule>
Das Einrichten von httpd-Konfigurationen hat nichts mit Linux zu tun, das wäre auf einem Windows-Rechner genauso. Da es viele Einstellmöglichkeiten gibt, kann man auch schnell was Falsches eintragen. Dann läuft der Apache nicht mehr beim Restart. Deshalb die Empfehlung, immer erst eine lauffähige Sicherung von der httpd.conf-sys anzulegen, bevor man was macht. Ansonsten gibt es gute Doku zum Apache, ist aber eben nicht gerade dünn
(9) .cgi-Dateien (common gateway interface) werden vom Apache über eine sogenannte Sub-Shell gestartet, d.h. binär-kompilierte Programme (C-Programme), oder Skripte (Shell, Perl usw.) sind möglich. Alle CGI-Programme müssen die Endung .cgi haben, weil sie sonst nicht ausgeführt werden (siehe vorherigen Punkt, wo das ja definiert wurde [theoretisch könnte man beliebige Endungen definieren]). In Skripten ist in der ersten Zeile als Kommentar-Eintrag der jeweilige Interpreter einzutragen, der von der Sub-Shell für die weitere Ausführung geladen werden soll:
#!/bin/ash
(10) .cgi-Skripte/Programme können so ziemlich alles enthalten, was man auch sonst mit der Shell oder Perl oder was-weiß-ich geht. Sie müssen allerdings, damit sie vom Apache auch ausgeführt werden als allererstes einen gültigen Header ausgeben. Dieser kann in einem .cgi-Shell-Skript so aussehen:
echo "Content-type: text/html"
echo ""
oder auch so:
cat <<EOT
Content-type: text/html
EOT
Der Apache will unbedingt die Leerzeile nach dem Text-Header, sonst mag er nicht. Der Rest in dem Skript sollte/muss Zeugs ausgeben, was der Browser verknusern kann und das ist in der Regel gültiges HTML.
(11) Für PHP-Skripte muss eine weitere Konfigurations-Datei angepasst werden: /usr/syno/etc/php.ini. Da diese Konfigurations-Datei auch für den Nicht-sys-Apache verwendet wird und sich dort Änderungen auch auf das Verhalten der normalen PHP-Skripte auswirkt, ist höchste Aufmerksamkeit bei Änderungen gefordert. Eine Sicherung der php.ini vor Änderungen ist angebracht! Auch hier gilt, nach jeder Änderung muss der/die Apache(s) wieder neu gestartet werden (siehe Punkt 6). Folgende Änderungen sind bei einigen 3rd-party-Application notwendig, damit sie auf das Linux-Dateisystem richtig zugreifen können bzw. auch Linux-Kommandos ausführen können:
safe_mode = Off
safe_mode_exec_dir =
open_basedir =
doc_root =
allow_url_fopen = On
register_globals = On
Einige dieser Eintragungen sind wahrscheinlich schon richtig gesetzt gewesen
So dass war es erstmal. Vielleicht habe ich noch das ein oder andere vergessen. Dann postet es einfach. Und wenn ich Fehler hier drin habe, natürlich auch
hi leutz,
nachdem doch nun schon eine Reihe von Beispielen existieren, möchte ich mal zusammenfassen, was man beim Einbau einer 3rd-party-Application bedenken muss. Unter anderem, weil es doch paar Voraussetzungen gibt, deren Wiederholung nicht bei jedem Beitrag nötig wäre.
(1) Die Integration in den Disk Station Manager einer 3rd-party-apps macht nur Sinn für den User admin. Meldet man sich mit einem anderem User an, sieht man die 3rd-party-apps nicht (vielleicht ändert sich das mal).
(2) Der User admin sollte sich immer über https anmelden (freischalten im Menü Netzwerkdienste->Webdienste), also über Port 5001. Es kann sein, dass sonst irgendwelche Nebeneffekte auftreten, die unerwünscht wären oder die bisherigen Beispielen angepasst werden müssten oder dass auch Dritte auf die Skripte zugreifen könnten oder oder oder ...
Hintergrundinformation: Der Apache-Webserver (httpd), der die Disk Station Oberfläche ausgibt, läuft mit den Rechten des root-Benutzers, was normalerweise eher unüblich ist. Aber es muss halt sein, weil sonst keine Systemadministration möglich wäre.
(3) Die Öffnung von Port 5000 und 5001 auf dem Router, um den Disk Station Manager auch aus dem Web her zu bedienen, sollte gut überlegt werden. Es ist prinzipiell ein Sicherheitsrisiko damit verbunden. (Diese Diskussion wurde schon/sollte an anderer Stelle weitergeführt werden)
(4) Die Konfigurations-Eintragungen für die 3rd-party-Applications werden im Verzeichnis /usr/syno/synoman/webman/3rdparty vorgenommen. Für jeden 3rdparty-Eintrag braucht man ein Verzeichnis. In diesem Verzeichnis muss mindestens eine application.cfg angelegt werden. Weitere Dateien, wie Bilder, cgi-Dateien usw. sind möglich. Eine genaue Anleitung findet man hier bzw. hier. Eine minimale application.cfg kann so aussehen:
test = My app
description = This is my app
type = embedded
path = /phpsrc/my_app/index.php
Anmerkung: Mit der Anlegen der ersten 3rd-party-apps-application.cfg-Datei erscheint automatisch das 3rd-party-Menü im Disk Station Manager (neu laden im Browser natürlich). Es muss also nichts besonderes installiert sein - außer Firmware 637 und größer.
(5) Die 3rd-party-Application läuft in einem HTML-iframe; kann man sich in der Datei /usr/syno/synoman/webman/modules/appebd.html ansehen. Die integrierte 3rd-party-Application wird demnach wie ein ganz normaler Link auf einer Seite aufgerufen. Alles was man sonst in einem Browser-Fenster aufrufen könnte, geht hier auch.
(6) Eine Möglichkeit, interaktiv mit Web-(Apache-)Anwendungen umzugehen, sind Skript-Programme, die der Apache-Webserver versteht. Was der Apache alles verstehen kann und könnte, wird per Konfigurationsdatei beschrieben. In diesem speziellen Fall (sys-Apache) ist es folgende Datei: /usr/syno/apache/conf/httpd.conf-sys. Wann immer man dort etwas ändert und hinzufügt, muss der Apache es lernen. Dafür muss er neu gestartet werden mit /usr/syno/etc/rc.d/S97apache-sys.sh restart.
(7) Damit der sys-Apache auch PHP-Skripte verstehen kann, muss er in der /usr/syno/apache/conf/httpd.conf-sys zwei zusätzliche Einträge erhalten:
AddType application/x-httpd-php .php
LoadModule php5_module /lib/libphp5.so
(8) Damit der sys-Apache auch auf alle Linux-Systemkommandos und alle Dateien zugreifen kann, sind weitere Veränderungen in der /usr/syno/apache/conf/httpd.conf-sys nötig (bitte die Zeilen suchen und genau vergleichen):
<Directory />
Options ExecCGI FollowSymLinks MultiViews Indexes
AllowOverride All
</Directory>
<Directory "/usr/syno/synoman">
Options ExecCGI FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>
<IfModule dir_module>
DirectoryIndex index.html index.htm index.cgi index.php
</IfModule>
<IfModule mime_module>
...
AddHandler cgi-script .cgi
...
</IfModule>
Das Einrichten von httpd-Konfigurationen hat nichts mit Linux zu tun, das wäre auf einem Windows-Rechner genauso. Da es viele Einstellmöglichkeiten gibt, kann man auch schnell was Falsches eintragen. Dann läuft der Apache nicht mehr beim Restart. Deshalb die Empfehlung, immer erst eine lauffähige Sicherung von der httpd.conf-sys anzulegen, bevor man was macht. Ansonsten gibt es gute Doku zum Apache, ist aber eben nicht gerade dünn
(9) .cgi-Dateien (common gateway interface) werden vom Apache über eine sogenannte Sub-Shell gestartet, d.h. binär-kompilierte Programme (C-Programme), oder Skripte (Shell, Perl usw.) sind möglich. Alle CGI-Programme müssen die Endung .cgi haben, weil sie sonst nicht ausgeführt werden (siehe vorherigen Punkt, wo das ja definiert wurde [theoretisch könnte man beliebige Endungen definieren]). In Skripten ist in der ersten Zeile als Kommentar-Eintrag der jeweilige Interpreter einzutragen, der von der Sub-Shell für die weitere Ausführung geladen werden soll:
#!/bin/ash
(10) .cgi-Skripte/Programme können so ziemlich alles enthalten, was man auch sonst mit der Shell oder Perl oder was-weiß-ich geht. Sie müssen allerdings, damit sie vom Apache auch ausgeführt werden als allererstes einen gültigen Header ausgeben. Dieser kann in einem .cgi-Shell-Skript so aussehen:
echo "Content-type: text/html"
echo ""
oder auch so:
cat <<EOT
Content-type: text/html
EOT
Der Apache will unbedingt die Leerzeile nach dem Text-Header, sonst mag er nicht. Der Rest in dem Skript sollte/muss Zeugs ausgeben, was der Browser verknusern kann und das ist in der Regel gültiges HTML.
(11) Für PHP-Skripte muss eine weitere Konfigurations-Datei angepasst werden: /usr/syno/etc/php.ini. Da diese Konfigurations-Datei auch für den Nicht-sys-Apache verwendet wird und sich dort Änderungen auch auf das Verhalten der normalen PHP-Skripte auswirkt, ist höchste Aufmerksamkeit bei Änderungen gefordert. Eine Sicherung der php.ini vor Änderungen ist angebracht! Auch hier gilt, nach jeder Änderung muss der/die Apache(s) wieder neu gestartet werden (siehe Punkt 6). Folgende Änderungen sind bei einigen 3rd-party-Application notwendig, damit sie auf das Linux-Dateisystem richtig zugreifen können bzw. auch Linux-Kommandos ausführen können:
safe_mode = Off
safe_mode_exec_dir =
open_basedir =
doc_root =
allow_url_fopen = On
register_globals = On
Einige dieser Eintragungen sind wahrscheinlich schon richtig gesetzt gewesen
So dass war es erstmal. Vielleicht habe ich noch das ein oder andere vergessen. Dann postet es einfach. Und wenn ich Fehler hier drin habe, natürlich auch
Zuletzt bearbeitet von einem Moderator:
