Garten Eden

#linux #programming #android #online #stuff

Sicherer und schneller Webserver mit nginx auf einem Raspberry Pi

Wer einen flinken, leichtgewichtigen Webserver betreiben möchte, greift aktuell nicht zu Apache, sondern zu nginx. Der Funktionsumfang ist ähnlich groß und längst gehört der freie HTTP-Server zu den etablierten Größen im Internetgeschäft (12% Marktanteil laut Netcraft).

Anders als ein nur im lokalen Netzwerk erreichbarer Dienst muss ein für alle Welt offener Server deutlich höhere Sicherheit garantieren. Auch in dieser Kategorie ist man mit nginx (und einigen zusätzlichen Vorkehrungen) gut aufgestellt. Da wir außerdem nicht nur statischen Content ausliefern wollen, installieren wir zusätzlich PHP, welches wir ebenfalls absichern und mittels XCache beschleunigen.

SFTP statt FTP

Das unsichere FTP hat übrigens ausgedient. Längst gibt es mit SFTP eine deutlich bessere Alternative, die auch unter allen Betriebssystemen verfügbar ist; wenn nicht mit Boardmitteln wie bei GNOME (Orte → Verbindung zu Server…), so zumindest mit dem beliebten FileZilla. SFTP verwendet dabei eine verschlüsselte Verbindung über den SSH-Dienst des Raspberrys, der sowieso für viele Aufgaben benötigt wird und standardmäßig und zu Recht aktiv ist.

Verbindung zum RPi

Da ein Monitor am RPi vertane Mühe ist, verbinden wir uns an einem anderen Computer mit dem kleinen Racker über SSH, wobei die Variablen natürlich zu ersetzen sind.

ssh IP-ADRESSE -l BENUTZERNAME

Installation und Backup

Als nächstes installieren wir den Webserver, PHP und die PHP-Beschleunigung. Beim Webserver wähle ich die light-Variante aus den Debian Packages, weil die enthaltenen Module für meine Zwecke ausreichend sind und Unnötiges nur unnötig Angriffsfläche bietet. Wer mehr braucht, installiert eben die umfangreicheren Pakete.

sudo apt-get install nginx-light php5-fpm php5-xcache

Für den Fall der Fälle legen wir noch Backups aller zu bearbeitenden Dateien an.

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bku
sudo cp /etc/nginx/fastcgi_params /etc/nginx/fastcgi_params.bku
sudo cp /etc/php5/fpm/php-fpm.conf /etc/php5/fpm/php-fpm.conf.bku
sudo cp /etc/php5/fpm/php.ini /etc/php5/fpm/php.ini.bku

Dateien bearbeiten

Um die nachfolgenden config-Dateien zu bearbeiten, empfiehlt es sich, die Dateien auf dem lokalen Rechner zu öffnen (z. B. mit gedit) und dann per Konsole und sudo in die entsprechenden Ordner zu kopieren. Die passenden Dateirechte setzen wir erst ganz zu Schluss.

Design

Alle serverspezifischen Dateien sollen sich am Ende im Verzeichnis /var/www/ befinden. Im Unterverzeichnis nginx/ die für den Webserver, in php-fpm/ die für PHP, in sockets/ sind die jeweiligen Unix-Sockets von PHP verlinkt (also sozusagen die Verbindungsports zu der PHP-Engine, auf die die jeweilige nginx-Site zugreift) und zu guter Letzt erhält jede Site ihr eigenes Verzeichnis.
In meinem Beispiel exisitiert nur die Site rpidisplay, die mein an den RPi angeschlossenes Display ansteuert.
Alle aus dem Internet erreichbaren Dateien liegen im Verzeichnis SITE/docs/, bei mir also /var/www/rpidisplay/docs/. Die zugehörigen Logdateien werden in SITE/logs/ gespeichert. Die anderen Verzeichnisse sind nur der Vollständigkeit halber aufgeführt.
Die gesamte Verzeichnisstruktur sieht also folgendermaßen aus:

/var/www/
├── nginx/
│   └── rpidisplay.conf
├── php-fpm/
│   └── rpidisplay.conf
├── rpidisplay/
│   ├── bin/
│   ├── docs/
│   │   └── index.html
│   ├── home/
│   ├── local/
│   │   └── bin
│   ├── logs/
│   │   └── access.log
│   │   └── error.log
│   ├── tmp/
│   └── usr/
│       ├── bin/
│       └── share/
└── sockets/
    └── rpidisplay.socket

nginx konfigurieren

Der Webserver selbst bekommt aus Sicherheitsgründen einen eigenen User nginx, der per se für das restliche System keine Schreibrechte erhält. Außerdem werden nicht-standardkonforme HTTP-Header ignoriert und weil der RPi nur einen Core hat, reicht ein worker_process. Was es mit der optionalen gzip-Kompression auf sich hat, steht weiter unten und dient nur der Performance. Wohlgemerkt steht in dieser Datei die Standardkonfiguration für alle Sites, die betrieben wird. Die include-Zeile lädt für jeden Virtual Host noch weitere Einstellungen nach.
Meine nginx-Konfiguration sieht nun folgendermaßen aus:
/etc/nginx/nginx.conf:

user nginx nginx;
worker_processes 1;
pid /var/run/nginx.pid;

events {
	worker_connections 768;
}

http {

	##
	# Basic
	##

	sendfile on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	server_tokens off;
	ignore_invalid_headers on;
	server_name_in_redirect off;
	tcp_nodelay off;
	tcp_nopush on;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;


	##
	# Logging 
	##

	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;


	##
	# Gzip
	##

	gzip on;
	gzip_static on;
	gzip_disable "msie6";

	gzip_vary on;
	gzip_proxied any;
	gzip_comp_level 3;
	gzip_buffers 16 8k;
	gzip_http_version 1.1;
	gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml rss text/javascript text/mathml application/atom xml application/xhtml xml image/svg xml;


	##
	# Virtual Host Configs
	##

	include /var/www/nginx/*.conf;
	#include /etc/nginx/conf.d/*.conf;
	#include /etc/nginx/sites-enabled/*;
}

FastCGI konfigurieren

FastCGI kümmert sich um die Einbindung externer Module in den Webserver, in unserem Fall das php-fpm-Modul. Bei den FastCGI Parametern sind die wichtigsten der DOCUMENT_ROOT und SCRIPT_FILENAME. Und damit nicht jeder unsere Serverversion erfahren kann, wird auch SERVER_SOFTWARE gekürzt..
/etc/nginx/fastcgi_params:

fastcgi_index index.php;

fastcgi_connect_timeout 65;
fastcgi_send_timeout    180;
fastcgi_read_timeout    180;

fastcgi_param	QUERY_STRING		$query_string;
fastcgi_param	REQUEST_METHOD		$request_method;
fastcgi_param	CONTENT_TYPE		$content_type;
fastcgi_param	CONTENT_LENGTH		$content_length;

fastcgi_param	DOCUMENT_ROOT		/docs;
fastcgi_param	SCRIPT_FILENAME		/docs$fastcgi_script_name;
fastcgi_param	SCRIPT_NAME		$fastcgi_script_name;
fastcgi_param	REQUEST_URI		$request_uri;
fastcgi_param	DOCUMENT_URI		$document_uri;
fastcgi_param	DOCUMENT_ROOT		$document_root;
fastcgi_param	SERVER_PROTOCOL		$server_protocol;

fastcgi_param	GATEWAY_INTERFACE	CGI/1.1;
fastcgi_param	SERVER_SOFTWARE		nginx;

fastcgi_param	REMOTE_ADDR		$remote_addr;
fastcgi_param	REMOTE_PORT		$remote_port;
fastcgi_param	SERVER_ADDR		$server_addr;
fastcgi_param	SERVER_PORT		$server_port;
fastcgi_param	SERVER_NAME		$server_name;

fastcgi_param	HTTPS			$https;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param	REDIRECT_STATUS		200;

Verzeichnisse und Benutzer anlegen

Erstellen wir nun die nötigen Verzeichnisse, Benutzer und Gruppen. Wir brauchen mindestens den User und die Gruppe nginx und zusätzlich für jede Site einen User und eine Gruppe. Anschließend muss nginx noch zu der Gruppe der jeweiligen Site hinzugefügt werden, damit der Webserver auch die Dateien ausliefern kann. Der Unix-Befehl adduser erstellt einen User und die dazugehörige Gruppe, sodass die nötigen Befehle wie folgt lauten:

sudo adduser --no-create-home --disabled-login nginx
sudo adduser --no-create-home --disabled-login rpidisplay
sudo usermod -G rpidisplay nginx

Nun erstellen wir die Verzeichnisse. Zuerst die für alle Sites, dann die für meinen rpidisplay-Host.

sudo mkdir /var/www/ /var/www/sockets/ /var/www/nginx/ /var/www/php-fpm/
cd /var/www/
sudo mkdir rpidisplay/ rpidisplay/bin/ rpidisplay/docs/ rpidisplay/home/ rpidisplay/logs/ rpidisplay/tmp/ rpidisplay/usr/ rpidisplay/usr/bin/ rpidisplay/usr/share/ rpidisplay/local/ rpidisplay/local/bin/

Site-spezifische Konfiguration

Wie die Site sich verhält und Inhalte ausliefert, wird in der jeweiligen Einstellungsdatei definiert. Diese wird, wie oben erwähnt, aus der Hauptdatei von nginx aufgerufen.
Dort steht auf welchem Port der Server lauscht und auf welchen Servernamen er reagiert. Außerdem sind hier die Logdateien der Site definiert und wo das Hauptverzeichnis liegt (root).
Zusätzlich möchte ich nicht, dass Dateien ausgeliefert werden, die mit einem Punkt beginnen. Der PHP-Abschnitt aktiviert die Weiterleitung an das PHP-Socket. Der letzte Teil definiert die Cache-Dauer für statische Inhalte. Da sich auf meiner Site nicht-dynamische Inhalte standardmäßig nicht ändern, ist der Wert entsprechend hoch.
/var/www/nginx/rpidisplay.conf:

server { 
	listen 80;
	server_name rpidisplay;

	access_log /var/www/rpidisplay/logs/access.log;
	error_log /var/www/rpidisplay/logs/error.log warn;

	root /var/www/rpidisplay/docs;


	# deny access to dot-files
	location ^~ /\\. {
		access_log off;
		log_not_found off;
		deny all;
	}


	# enable PHP
	location ~ ^(.*)\\.php$ {
		if (!-f $request_filename) {
			return 404;
		}

		include /etc/nginx/fastcgi_params;
		fastcgi_pass unix:/var/www/sockets/rpidisplay.socket;
	}


	# enable browser cache control for static files including html
	location ~* \\.(html|htm|jpg|jpeg|gif|png|css|js|ico|xml)$ {
		access_log off;
		log_not_found off;
		expires 360d;
	}
}

PHP konfigurieren

Auch PHP muss noch gesagt bekommen, welche Einstellungen gelten. Um einen besseren Überblick und eine schnelle Anpassbarkeit auch der PHP-Optionen zu haben, möchte ich die Einstellungsdatei im /var/www-Verzeichnis liegen haben. Weisen wir PHP-FPM (das für uns das Socket öffnet, auf dem PHP verfügbar ist) also an, dort nach einer Konfigurationsdatei zu sehen. Das geschieht in der Datei /etc/php5/fpm/php-fpm.conf durch anhängen der Zeile

include=/var/www/php-fpm/*.conf

Damit die Standardkonfigurationsdatei nicht mehr geladen wird, benennen wir sie um.

sudo mv /etc/php5/fpm/pool.d/www.conf /etc/php5/fpm/pool.d/www.conf.bku

In der neu anzulegenden FPM-Konfigurationsdatei definieren wir beginnend mit dem Site-Namen nun also den Ort des zu öffnenden Sockets, Dateirechte und ein paar Variablen. Der Socketpfad muss mit dem übereinstimmen, auf den ngnix zugreifen will (s. o.) und die Datei- und Gruppenrechte entsprechen dem neu angelegten User für unsere Site.
/var/www/php-fpm/rpidisplay.conf:

[rpidisplay]
listen = /var/www/sockets/rpidisplay.socket
listen.owner = rpidisplay
listen.group = rpidisplay
listen.mode = 0666

listen.backlog = -1
listen.allowed_clients = 127.0.0.1

user = rpidisplay
group = rpidisplay

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 500

chroot = /var/www/rpidisplay
chdir = /docs

env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
env[HOME] = /home
env[DOCUMENT_ROOT] = /docs

Nun fehlt nur noch die altbekannte php.ini, die noch abgesichert werden muss. In den neueren PHP-Versionen sind viele Einstellungen von vornherein recht sicher gewählt. Je nach Belieben kann man noch Warnung und Fehler unterdrücken, zumindest sollte man aber einige Betriebssystemfuntionen deaktivieren, um serverweite Angriffe zu erschweren.
/etc/php5/fpm/php.ini:

disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,exec,system,passthru,shell_exec,popen,escapeshellcmd,proc_open,proc_nice,ini_restore

PHP-timezone-Fehler beheben

Mit den eingeschränkten (sicheren) Rechten, mit denen PHP nun läuft, funktionieren Zugriffe auf einige Betriebssystemfuntionen nicht mehr zuverlässig, so z. B. die meisten Zeitfunktionen. Das liegt daran, dass der PHP-User nicht auf /usr/share/zoneinfo/ zugreifen kann. Das Problem ist behoben, wenn man die dort liegenden Informationen in das /usr/share/-Verzeichnis des PHP-Nutzers kopiert.

sudo cp -aR /usr/share/zoneinfo /var/www/rpidisplay/usr/share/

Abschlussarbeiten

Jetzt würde ich noch die Standardsite von nginx deaktivieren, indem ich es aus dem Hauptpfad für aktive Sites entferne. Unsere Sites liegen jetzt ja in /var/www/.

sudo rm /etc/nginx/sites-enabled/default 

Außerdem müssen nun die Zugriffsrechte für die Dateien und Ordner gesetzt werden. Sprich: Alle Dateien in dem docs/-Verzeichnis müssen vom User der Site gelesen werden können, in meinem Fall vom User rpidisplay; nginx kann es dann automatisch, weil der Server ja zur selben Gruppe gehört.

sudo chown -R rpidisplay:rpidisplay /var/www/rpidisplay/docs/

Abschließend starten wir nginx und PHP neu, damit die Änderungen geladen werden.

sudo service nginx restart
sudo service php5-fpm restart

Wenn keine Fehler ausgegeben werden, läuft auf unserem Debian-System nun ein schneller, leichtgewichtiger, dynamischer, funktionsreicher und vor allem sicherer Webserver.
Wird eine Datenbank benötigt, empfiehlt sich z. B. SQLite.

Warum gzip compression?

In der nginx-Hauptkonfigurationsdatei aktivierten wir die gzip-Kompression. Das bringt den Webserver dazu, bei einer aufgerufenen Datei immer zuerst nach einer komprimierten Version zu suchen und diese auszuliefern, sprich: Wird index.html aufgerufen, wird zuerst geschaut, ob index.html.gz vorhanden ist und wenn ja, diese an den Nutzer gesendet. Dadurch sinkt die Übertragungsgröße enorm, deshalb habe ich diese Option auch für alle statischen Dateitypen aktiviert.
Einschränkungen: nginx komprimiert nicht live, also muss man jede Datei, die man verändert, selbst komprimieren. Das erlaubt einem allerdings auch gleich die höchste Kompressionsstufe zu wählen, ohne dass der Server belastet wird. Außerdem gibt es Berichte darüber, dass es zu Fehlern kommen kann, wenn die Originaldatei und ihr gzip-Pendant nicht dasselbe Änderungsdatum haben, also empfiehlt es sich, die Dateien vorher alle zu touchen.

Quellen

Inspiration fand ich auf folgenden Quellen:

flattr

Kommentare

Dein Kommentar:






Bisher...

 
01.08.2015 16:54 Dennis sagt:
Okay, bin wieder mal weiter gekommen :)

Bin zwar nicht neu im Linux-Segment, habe aber mit chroot bspw. noch nie Erfahrungen gesammelt.

Ich habe jetzt mehrere Erkenntnisse...

(1) Der Pfad in der php.ini unter session.save_path bezieht sich auf das "Domain-Verzeichnis" /var/www/domain.tld/. Daher habe ich diesen nun auf /tmp geändert, wodurch das tmp in diesem Verzeichnis genutzt wird ... ich depp!

(2) User-spezifische php.ini-Einträge sind auch bei nginx+php-fpm möglich. session.save_path kann bspw. so Userspezifisch gesetzt werden (was aber durch (1) nicht mehr notwendig ist)
Datei: /var/www/php-fpm/domain_tld.conf
Dann folgende Zeile einfügen: php_value[session.save_path] = /not/public/path/in/chroot

(3) Auf dem Pi läuft das ganze nun, auf meinem vServer leider nicht. Ich habe jetzt zwar die Session-Datei, die Seite bleibt aber komplett weiß.
 
01.08.2015 16:31 Eduard Dopler sagt:
Dennis, okay, aber kein Fehler mehr? Dann liegt es ja jetzt nicht mehr an der Session, sondern am Rest des Codes.
 
01.08.2015 16:11 Dennis sagt:
Ok, im selben Ordner wurde anscheinend doch eine session-Datei erstellt. Die Seite bleibt aber, bis auf die "Pfadausgabe" weiß
 
01.08.2015 15:36 Dennis sagt:
Habs gerade mal getestet... ohne erfolg
 
01.08.2015 14:34 Eduard Dopler sagt:
Dennis, und mit der PHP-Direktive direkt aus der Datei heraus? Also z.B. session_save_path(getcwd());
Danach kannst du ihn dir zur Kontrolle direkt ausgeben lassen: echo session_save_path();
 
01.08.2015 14:14 Dennis sagt:
Der chroot-Ordner ist ja domain-spezifisch. Der standard Cookie-Pfad ist /var/lib/php5/. Nginx bietet mMn nicht die Möglichkeit userspez. PHP.INIs zu nutzen. Egal.. Ich habe es auch schonmal in der chroot-Umgebung getestet - vergebens (rechte "777")
 
31.07.2015 15:19 Eduard Dopler sagt:
Dennis, du versuchst es aber schon in einem Unterordner von dem chroot-Ordner, oder?
 
31.07.2015 15:16 Dennis sagt:
Danke für deine schnelle Antwort und den Hinweis mit der Benutzer- und Rechtevergabe!

Schade, dass du mir da momentan mit meinem Cookie-Problem nicht weiterhelfen kannst. Es kann ja auch sein, dass sich da durch aktuelle Software-Versionen ein Fehler o.ä. eingeschlichen hat.

Ich habe jedenfalls schon verschiedenste Pfade und Rechte für die Cookie-Ablage getestet. Leider bisher ohne Erfolg...
 
31.07.2015 14:10 Eduard Dopler sagt:
Hi Dennis,
leider habe ich die Ordnerstruktur nicht mehr vorliegen, aber ich versuche mal ins Blaue zu raten:
1. Das nginx Wiki sagt[1], dass der Standardwert für index nur index.html ist. Also gut möglich, dass man das für PHPs noch einfügen muss. Guter Hinweis.
2. Offensichtlich versucht deine PHP-Konfiguration auf den Ordner in /lib/var/... zuzugreifen. Du kannst den Speicherort für Sessions in PHP jedoch gemütlich ändern[2].
3. Während ich die Rechte für die Konfigurationsdateien nicht verändert habe, sind die Rechner für das /docs/-Verzeichnis im vorletzten Absatz beschrieben.

[1] http://nginx.org/en/docs/http/ngx_http_index_module.html#index
[2] http://www.php.net/manual/en/session.configuration.php#ini.session.save-path
 
31.07.2015 13:37 Dennis sagt:
Hi, danke für deine Anleitung zum Einrichten eines Webservers!

Leider habe ich nach befolgter Anleitung ein paar Probleme ...

(1) Der automatische Verweis auf eine "index.php" war bei mir nur möglich, indem ich index index.php index.html index.htm; in die "/var/www/nginx/domain.conf" unter "root ..." geschrieben habe.

(2) Wenn ich mit cookies ("session_start()";) arbeiten will, erhalte ich momentan die Fehlermeldung Warning: session_start(): open(/var/lib/php5/session/sess_a1b2c3, O_RDWR) failed: No such file or directory (2) in /doc/index.php on line 4
Dabei habe ich aber auch schonmal die Ordnerrechte auf "777" gestellt, ohne erfolg.

(3) Allgemein vermisse ich eine Übersicht, welche Benutzer-/Gruppenzugehörigkeiten sowie -rechte die Ordner und Dateien haben müssen.
 
10.02.2014 17:33 Timo sagt:
Auf diese Idee bin ich gar nicht gekommen. Manchmal ist die Lösung zu einfach um selbst darauf zu kommen. Habe mir dafür nun ein Skript geschrieben.

Danke für deine Hilfe :)

Gruß
Timo
 
10.02.2014 05:26 Eduard Dopler sagt:
Ja, sieh es als Sicherheitsfeature ;-)
Ich kopiere meine Dateien immer erst ins home-Verzeichnis und von da mit sudo in den passenden Ordner.
 
09.02.2014 21:36 Timo sagt:
Hallo,

ich habe deine Anleitung befolgt und alles funktioniert super. Danke dafür :).
Nun mein Problem: Wie kann ich per SFTP Dateien in den Ordner docs laden? Mit dem pi user geht es nicht da er dort keine Schreibrechte hat.

Vielen Dank für deine Hilfe :)

Gruß Timo
 
02.02.2014 21:06 Eduard Dopler sagt:
Ich kann dir leider nicht weiterhelfen.
 
02.02.2014 21:03 Michael sagt:
Hallo,
vielen Dank für die schnelle Reaktion...
Leider kein Eintrag in Log Files.
Es geht speziell um folgendes Script:

https://dl.dropboxusercontent.com/u/251095/curl.PNG

Kannst Du hier etwas erkennen?
An einem Apache Server erhalte ich; {"status":1,"request":"de8c7b2faded2542f4ed697305af5b28"}
beim Aufruf, so soll es sein..?!

Bin Dir für jeden Hinweis dankbar
 
02.02.2014 19:51 Eduard Dopler sagt:
Gibt es eine Fehlermeldung in den Logdateien von PHP und/oder nginx und/oder im syslog?
 
02.02.2014 19:38 Michael sagt:
Hi,
eine interessante und detaillierte Anleitung :-) Vielen Dank dafür!
Ich habe sqllite noch benötigt, könnte ich einfach nachinstallieren und lief - leider funktioniert das mit cURL nicht. Habe die Pakete mittels apt-get install php5-curl nachinstalliert; in der phpinfo() sehe ich curl Support enabled/yes!
Doch meine scripte laufen nicht!
Liegt dies evtl an den Sichereitseinstellungen (wie bei den timezones)!?

Könnt Ihr mit einen Tipp geben?

Vielen Dank und Gruß aus Oberbayern
 
11.11.2013 15:58 Jo sagt:
Verstanden, besten Dank für den Hintergrund. Sicherheit hat ihren Preis ;-) Obwohl sSmtp nur 8 kB groß ist, nicht zu vergleichen mit Sendmail, ist es mir bisher nicht gelungen, die "richtigen" Files zu kopieren. Wer weiß, wie es nun um die Sicherheit bestellt ist :-) Also bleibt PHP nun ohne Mail-Versand und stelle ersatzweise auf cronjob-mails um.
 
10.11.2013 21:43 Eduard Dopler sagt:
Ach so, dann liegt das Problem darin, dass php-fpm gechrootet wurde, also PHP nicht außerhalb des Server-Verzeichnisses zugreifen kann (deshalb auch der Trick mit den timezones). Für kleine externe Programme holt man sich die Inhalte in das chroot-Verzeichnis und baut quasi ein Dateisystem nach. Bei sendmail ist das ganze recht schwierig, aber anscheinend hat es jemand hinbekommen.
 
10.11.2013 12:53 Jo sagt:
Angesteuert wird ssmtp durch den Eintrag (php.ini): sendmail_path= /usr/sbin/ssmtp -t
Die Logdateien, in die ein Mailausgang protokolliert werden, sitzen unter /var/log/mail.*
alle gehören root (rw), Gruppe adm (r), andere (-). Dürfte ssmtp via php dann in diese Dateien schreiben? Sorry für die evt. dumme Frage, aber mit den Rechten unter Linux tue ich mich noch schwer. Wenn pi über die Konsole eine Mail schreibt, erfolgt hier ein Eintrag.
Wenn nicht, müsste doch wenigstens in /var/www/rpidisplay/logs/error.log ein Hinweis zu finden sein, so wenn z.B. eine nicht vorhandene Funktion aufgerufen wird, jedoch gleich welches Logfile, nirgens ein Vermerk.
 
08.11.2013 21:32 Eduard Dopler sagt:
Ich weiß leider nicht, wie ssmtp angesteuert wird. Bist du sicher, dass das über das Dateisystem läuft, also eine Datei geschrieben werden muss? Wenn das wirklich so ist, kannst du den Benutzer ja zu der Gruppe hinzufügen, der Schreibrechte in den dafür vorgesehenen Verzeichnis hat.
 
08.11.2013 18:16 Jo sagt:
Zitat: Der Webserver selbst bekommt aus Sicherheitsgründen einen eigenen User nginx, der per se für das restliche System keine Schreibrechte erhält.

Bedeutet dies, dass in dieser Form, ssmtp nicht aus einer PHP-Mail heraus angesteuert werden kann? Von der Kommando-Zeile funktioniert eine Testmail,
nicht jedoch aus einem PHP-Script.
 
04.11.2013 16:17 Jo sagt:
"Unsichtbares" Problem nun behoben :-) Nachdem alle Versuche nicht fruchteten, habe ich angeregt durch einen
Vorkommentar, aus allen config-files, Leer-Zeichen und Zeilen entfernt und durch Returns im nano-editor ersetzt,
vermute unsichtbare Steuerzeichen, die ich von einem Windows-Rechner per paste&copy "eingeschleppt" hatte.

Nun läuft PHP! Danach sSMTP installiert, um per Cron-Job Mails vom System, sowie per PHP-Formular
zu erhalten. Da mein RPi hinter einem Proxy-Server läuft, klappt dies auf Anhieb mal wieder nicht. Entweder
unterstützt sSMTP keinen Proxy oder es bedarf wieder eines gesonderten config-files, so wie auch apt-get
nicht die Einstellungen in /etc/network/interfaces berücksichtigt, sondern aus /etc/apt/apt.conf bezieht.
Jemand Erfahrung mit sSMTP in Verbindung mit einem Proxy, der den Internet-Zugang herstellt?
 
01.11.2013 13:20 Eduard Dopler sagt:
Das heißt leider nur, dass du die IP ohne den Dateinamen, also ein /index.php, angesurft hast und dass nginx dann nicht automatisch die index.php geladen hat, sondern nach einer index.html gesucht hat, sie offensichtlich nicht gefunden hat und deshalb versuchte, den Ordnerinhalt anzuzeigen, was aber in unserer Konfiguration verboten ist. Sprich: Wenn du den vollen Pfad aufrufst, müsste wieder der alte Fehler kommen.
Möchtest du mir mal die Dateirechte von allen bearbeiteten Dateien schicken? Am besten so (alles in eine Zeile):
ls -lR /var/www/ /etc/nginx/nginx.conf /etc/nginx/fastcgi_params /etc/php5/fpm/php-fpm.conf /etc/php5/fpm/php.ini
Bitte an meine E-Mail-Adresse.
 
01.11.2013 12:43 Jo sagt:
chown noch einmal ausgeführt, keine Änderung im Ergebnis.
Alle Dateien liegen in docs/
Als Variante nun eine "index.php" dort abgelegt, jetzt ein neues
Ergebnis beim Aufruf von raspi-IP: 403 Forbidden/nginx
error.log: *2 directory index of "/var/www/rpidisplay/docs/" is forbidden
Das ist bestimmt jetzt ein Hinweis zum Durchbruch ;-)
 
31.10.2013 21:11 Eduard Dopler sagt:
Also eigentlich bedeutet der Fehler, dass der FastCGI-Server die angegebene Datei nicht finden kann. Bei uns sucht er in /docs/SCRIPT_DATEINAME, also wenn test.html und test.php im selben Ordner (docs/) liegen, müsste es klappen. Eigentlich.
Welche Dateirechte haben deine Dateien? Hast du ganz am Ende erneut den chown-Befehl ausgeführt? Probier das doch noch mal.
 
31.10.2013 18:22 Jo sagt:
Danke für die schnelle Antwort. Alles wurde 1:1 von Deinen Vorgaben
kopiert, lediglich der http-port geändert, auch nun alles noch einmal
kontrolliert.
 
31.10.2013 15:16 Eduard Dopler sagt:
Hast du in der /var/www/nginx/rpidisplay.conf im PHP-Abschnitt das include für die fastcgi_params drin? Ist die dort erwähnte Datei vorhanden und ist vor allem dort der Eintrag SCRIPT_FILENAME richtig?
 
31.10.2013 15:11 Jo sagt:
Hallo Eduard,

besten Dank für die Anleitung im Netz, sehr detailiert und gut "nachbaubar",
auch für Leute wie mich, die mit Linux noch ganz am Anfang stehen.

nginx und php starten ohne Fehlermeldung, eine "test.html" wird auch angezeigt,
jedoch eine "test.php" nicht (File not found.).

Eine Datei, die tatsächlich nicht im Verzeichnis liegt wird ordnungsgemäß
mit der Fehlerseite "404 Not Found / nginx" angezeigt.

Ein Versuch mit "test.php5" z.B., wird zum Download angeboten, das ist fatal ;-)

Die Fehlermeldung im "error.log":
2013/10/31 12:51:35 [error] 6833#0: *1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: ▯.▯.▯.11, server: rpidisplay, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://unix:/var/www/sockets/rpidisplay.socket:", host: "▯.▯.▯.70:8082"

Mir sagt dies nicht viel, eventuell Dir?

Vielen Dank im voraus, viele Grüße

Jo
 
01.10.2013 15:04 René sagt:
habe den fehler gefunden in ../www/php5-fpm/rpidisplay.conf
war der fehler das jeder absatz ein leerzeichen am ende hatte
 
01.10.2013 14:39 Eduard Dopler sagt:
Nur bei PHP-Seiten?
Werden beim (Neu-)Starten der Serverdienste (nginx und php5-fpm) Fehler angezeigt?
 
30.09.2013 22:44 René sagt:
Erst mal danke für das tutorial

Leider hab ich da ein problem
undzwar wir mir der fehler 502 bad gateway aus geben wenn ich eine php seite öffnen will
bis jetzt stillstand
 
28.07.2013 15:43 Eduard Dopler sagt:
Vielen Dank.
Das ist ein guter Einwand. Ich denke, ich hielt es für eine Grundvoraussetzung, einen Server stets aktuell zu halten. Sicherlich gehört auch das Updaten vor der Installation dazu.
 
28.07.2013 15:09 Reisefoto sagt:
Hallo Herr Dopler,

habe soeben Ihr tolles Tut. durchgearbeitet. Funktioniert von oben bis unten wie beschrieben und fehlerfrei. Zum ersten Test hatte ich lediglich ein Verständnisproblem, ich habe zunächst die Dateien (index.html oder info.php) unter
/var/www/SERVER/docs/
mittels
raspi-IP/SERVER/info.php
versucht zu erreichen.

Dabei zeigt die raspi-IP ja bereits in den Ordner SERVER/docs. Es reichte also ein einfaches raspe-IP/info.php bzw raspi-IP/index.html um meine Testdateien zu erreichen.

Eine Frage noch zum Schluss: Warum fängt Ihr Tut. nicht mit
sudo apt-get update
sudo apt-get upgrade
an?

Nochmals vielen Dank für diese tolle Anleitung.
 
24.07.2013 19:08 Eduard Dopler sagt:
Leider musst du auch die anderen beschriebenen Dateien bearbeiten, sonst wird z.B. der /var/www/nginx-Ordner gar nicht gelesen. Am besten arbeitest du dich von oben nach unten durch.
 
21.07.2013 13:56 lemongrass sagt:
Vielen Dank für das tolle Tutorial!
Man merkt wirklich das Du Dir einiges dabei gedacht hast!
Leider kenne ich mich insgesamt mit der Materie noch zu wenig aus. Aber ich denke ein Raspberry ist der richtige Anfang.
Ich habe mpd auf meinen "Raspi" laufen und wollte nun, einen Webclient namens Rompr einrichten der den mpd steuert. Leider sind mir noch zu viele Dinge unklar bzw. funktioniert es nicht.
Ich habe dieses Tutorial als Vorlage genommen: http://www.pihomeserver.fr/2012/12/19/raspberry-pi-home-server-etape-13-serveur-de-musique-avec-mpd-et-rompr/
Ich habe jetzt den Rompr ordner unter /var/www/ abgelegt. Und die Datei aus dem Tutorial /etc/nginx/sites-available/rompr als /var/www/nginx/rompr.conf abgespeichert. Anschließend habe ich einfach nginx neu gestartet und erhalte dann folgende Fehlermeldung.

Restarting nginx: nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2013/07/21 13:32:41 [warn] 5330#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2013/07/21 13:32:41 [emerg] 5330#0: "fastcgi_index" directive is duplicate in /var/www/nginx/rompr.conf:21
nginx: configuration file /etc/nginx/nginx.conf test failed


Den Softlink wie im Tutorial habe ich nicht gesetzt, da ich nicht wusste von wo nach wo. Zudem bin ich mir micht ganz darüber im klaren was du in Deinem Tutorial mit Site meinst. Meinst du damit, pro Webseite ein Verzeichnis. Denn ich war mir nicht sicher ob ich den Ordner rompr in /var/www/rspidisplay/doc kopieren soll.
Vielleicht noch der link zum Wiki der Standardkonfiguration von rompr mit Apache: http://sourceforge.net/p/rompr/wiki/Installation/

Wäre über Deine Hilfe sehr dankbar!
Grüße
 
16.07.2013 15:29 Eduard Dopler sagt:
Ja, du kannst einen zweiten virtuellen Host einrichten, ähnlich wie bei Apache.

Eine Möglichkeit wäre per server_name (siehe [1], schau dir vor allem die letzten Beispiele an), die andere mittels separatem Port (einfach listen ändern). Für beide Beispiele musst du die beschriebenen Konfigurationsdateien kopieren, anpassen und ein zweites Hauptverzeichnis anlegen.

[1] http://wiki.nginx.org/HttpCoreModule#server_name
 
16.07.2013 03:29 banone sagt:
irgendwie ist mein rasberry-pi nicht im rechenzentrum sondern an meinem dsl-anschluss. Da ändert sich die ip alle 24h. Deshalb habe ich sowas wie
bla.no-ip.biz
ich möcht nu nich für jede homepage ne eigene dyn-adresse anlegen (dass eine funktioniert und erreichbar bleibt ist schon ein Krampf genug). kann man nginx auch so einstellen, das die virtuellen hosts so erreichbar sind?
bla.no-ip.biz/Host1
bla.no-ip.biz/Host2
bla.no-ip.biz/rpidisplay

oder wenigstens "by port":

bla.no-ip.biz:3333
bla.no-ip.biz:3334
bla.no-ip.biz:3335

alles Andere ist total doof
 
07.07.2013 22:35 Eduard Dopler sagt:
Heißt “keine Errorlogs”, dass du dir die Ausgaben in /var/log/ angeschaut hast und auch die Error-Logs des Servers, sprich die in /var/www/SERVER/logs/? Beobachte vor allem letzteres, wenn du versuchst die Seite anzusurfen.
 
07.07.2013 16:28 wodsen sagt:
hallo und vielen dank für dein Ausführliches HowTo, ich habe alles so gemacht wie beschrieben. Es kommen keine Errorlogs und es sollte alles funktionieren. Habe auch eine index.php im /docs abgelegt mit Hallo welt nur leider kommt immer nur die 404 Seite. In der URL Leiste gebe ich IP-Adresse/nameder/test. Was mache ich falsch eigentlich müsste es doch funktionieren.

de

Moment, lade ältere Artikel...

E-Mail (nicht öffentlich)

Homepage (optional)

Kommentar... (code-Tag erlaubt)