[Eisfair] Eisfair Apache als reverse proxy

[Ansgar Püster]

Hallo Stefan,

Danke für dein Tests und natürlich die Fragen.
Meine Antworten bzw. Vermutungen siehe unten.

Am 10.04.2015 um 10:53 schrieb Stefan Heidrich:
> Hallo Uwe, hallo Ansgar, hallo NG,
>
>> verwende doch mal (testhalber !) meine config (hab sie grad auf Dein
>> Netz angepasst) und das von mir kompilierte (etwas ältere) ninx-Binary
>> ... das läuft auf meinem eis1 (Base 2.4.0, Kernel 2.8.0).
>
> Danke für die Bereitstellung. Auf einem frisch aufgesetzten Eis kommt beim
> Start Deiner Binary diese Meldung:

Hier mischt du also das eisfair-1 Paket von mir mit dem Binary
von Uwe.

> # /etc/init.d/nginx start
>   * Starting nginx daemon ...
> /usr/local/nginx/sbin/nginx: error while loading shared libraries:
> libgd.so.2: cannot open shared object file: No such file or directory
> [ FAIL ]

Das Binary von Uwe nutzt offensichtlich die libgd.
Dies benötigt "mein" Binary nicht:

ansgar at eis350:~/psource/nginx-1.7.11 > ldd ./objs/nginx
         linux-gate.so.1 =>  (0xb7702000)
         libpthread.so.0 => /lib/libpthread.so.0 (0xb76e4000)
         libcrypt.so.1 => /lib/libcrypt.so.1 (0xb76b0000)
         libpcre.so.1 => /usr/lib/libpcre.so.1 (0xb7645000)
         libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0xb75f5000)
         libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0xb7477000)
         libdl.so.2 => /lib/libdl.so.2 (0xb7472000)
         libz.so.1 => /usr/lib/libz.so.1 (0xb745d000)
         libc.so.6 => /lib/libc.so.6 (0xb731f000)
         /lib/ld-linux.so.2 (0xb7703000)

libgd ist meines Wissens eine Bibliothek um Grafiken zu erzeugen.
Bei nginx 1.7.11 steht in auto/options:USE_LIBGD=NO.
Daher der Unterschied.

> Also libgd nachinstalliert. Dann kommt folgendes:
>
> # /etc/init.d/nginx start
>   * Starting nginx daemon ...
> nginx: [alert] could not open error log file: open()
> "/var/log/nginx/error.log" failed (2: No such file or directory)
> 2015/04/10 07:29:34 [emerg] 5319#0: open() "/etc/nginx/nginx.conf" failed
> (2: No such file or directory)

Ja, das ist klar. Die ./configure Options der beiden Binaries
haben "heftige" Unterschiede. Das eisfair-1 Paket ist für diese
anderen Pfade etc. _nicht_ gebaut. Es nutzt bis auf
--with-http_ssl_module
--with-ipv6
die Defaults von nginx 1.7.11.

Warum ggf. die ./configure Options von nginx 1.6.2 angepasst
wurde, müsste Uwe beantworten können.

> Also ein Verzeichnis /etc/nginx angelegt und dort die conf hinkopiert. Dann
> kommt:
>
> # /etc/init.d/nginx start
>   * Starting nginx daemon ...
> nginx: [alert] could not open error log file: open()
> "/var/log/nginx/error.log" failed (2: No such file or directory)
> 2015/04/10 07:31:24 [emerg] 5328#0: open() "/etc/nginx/mime.types" failed
> (2: No such file or directory) in /etc/nginx/nginx.conf:6
> [ FAIL ]
>
> Jetzt das Verzeichnis /var/log/nginx angelegt und restlichen Dateien von
> Ansgar aus /usr/local/nginx/conf nach /etc/nginx kopiert. Jetzt kommt:
>
> # /etc/init.d/nginx start
>   * Starting nginx daemon ...
> nginx: [emerg] mkdir() "/tmp/nginx/http-client" failed (2: No such file or
> directory)
> [ FAIL ]
>
> Also auch noch das Verzeichnis /tmp/nginx/http-client angelegt und jetzt
> startet nginx.

Siehe oben.

> Beim Aufruf von https://192.168.132.40 kommt jetzt folgendes:
>
> Fehler: Gesicherte Verbindung fehlgeschlagen
> Ein Fehler ist während einer Verbindung mit 192.168.132.40 aufgetreten. SSL
> hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten
> hat. (Fehlercode: ssl_error_rx_record_too_long)
> Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen
> Daten nicht verifiziert werden konnte.
> Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem
> zu informieren.
>
>
> Also Konfuguration angepasst und SSL hinzugefügt / Kommentare entfernt.
>
> Jetzt bekomme ich bei Aufruf von https://192.168.132.40:
>
> 502 Bad Gateway
>
>
> Dann hab ich im Internet das Suchen angefangen und bin auf diese Webseite
> gestoßen:
> https://blog.friedlandreas.net/2013/07/reverseproxy-fur-eas-exchange-activesync-und-owa-outlookwebapp-mit-nginx/

Sehr interessant, ich habe allerdings keine Umgebung, in der
ich mit EAS oder OWA "spielen" kann.

> Und mit einer Mischung der Konfigurationen hab ich das intern ans Laufen
> bekommen. Auch der Zugriff von außen funktioniert.
>
> Hier noch der Vollständigkeit halber meine funktionierende Konfiguration,
> die aber jetzt mit Ansgars Paket am Laufen ist:
>
>
> worker_processes  auto;
>
> events {
>          worker_connections   1024;
> }
>
> http {
>          include       mime.types;
>          default_type  application/octet-stream;
>          sendfile      on;
>          tcp_nopush    on;
>          keepalive_timeout  65;
>
>          #Abschnitt 1
>          server {
>                 listen       80;
>                 server_name owa.firmenname.tld;
>
>                 # Redirect any HTTP request to HTTPS
>                 return 301 https://$server_name$request_uri;
>
>                 error_log  logs/error.log debug;
>                 access_log logs/access.log;
>          }
>
>          #Abschnitt 2
>          server {
>                listen       443;
>                 server_name owa.firmenname.tld;
>
>                 # Redirect from "/" to "/owa" by default
>                 location / {return 301 https://owa.firmenname.tld/owa;}
>
>                 # Enable SSL
>                 ssl                     on;
>                 ssl_certificate         /usr/local/nginx/cert/OWA.pem;
>                 ssl_certificate_key     /usr/local/nginx/cert/OWA.key;
>                 ssl_session_timeout     5m;
>
>                 # Set global proxy settings
>                 proxy_read_timeout      360;
>
>                 proxy_pass_header       Date;
>                 proxy_pass_header       Server;
>
>                 proxy_set_header        Host $host;
>                 proxy_set_header        X-Real-IP $remote_addr;
>                 proxy_set_header        X-Forwarded-For
> $proxy_add_x_forwarded_fo
> r;
>                 proxy_set_header        Accept-Encoding "";
>
>                 location /owa  { proxy_pass
> https://ex-mgh-css1.root.lan/owa; }
>                 location /ews  { proxy_pass
> https://ex-mgh-css1.root.lan/ews; }
>                 location /Microsoft-Server-ActiveSync { proxy_pass
> https://ex-mgh
> -css1.root.lan/Microsoft-Server-ActiveSync; }
>
>                 error_log logs/sslerror.log debug;
>                 access_log logs/sslaccess.log;
>          }
> }
>
>
> Ansgar, kannst Du damit etwas anfangen um Dein Paket weiter zu entwickeln?
> Jetzt wo ich weiß was nginx macht und kann bin ich auch gerne als Tester
> bereit. :)

Wow, das ist ja eine etwas umfangreichere Konfiguration.

Genau für diese Zwecke hatte ich
NGINX_MAN_CONFIG='yes'
was du ja wohl nutzt, gedacht.

Die nginx-Konfig ist höchst komplex und meines Erachtens
nicht wirklich über die Eisfair-1 Konfigurationsschicht
abbildbar. Zumindest nicht bei einer solchen Konfiguration.

Mein Ziel war daher zunächst eine stimmige Umgebung bezüglich
der Pfade, Bibliotheken und die grundlegenden Services, zu
denen unter anderem auch das von Uwe vorgeschlagene
"Test nginx configuration" gehört. Siehe Menü.

Ich werde das Paket unter den oben genannten Prämissen
selbstverständlich weiter entwickeln. Bei Fehlern und
Erweiterungswünschen bitte melden.

Gruß,
Ansgar

> Viele Grüße und ganz herzlichen Dank
> Stefan