Alias Nginx-Proxy vs. Apache2 Alias
Simone
- apache
- nginx
- webserver
Hi,
Ich bin dabei mir einen (Web-Entwicklung) Nginx(als http2-Proxy) + Apache2 Server aufzusetzen.
Wie bekomme ich das hin das Apache Alias Module ohne Anpassung der Nginx Conf korrekt eingebunden werden?
Beispiel:
# apachectl -M | grep autoindex
autoindex_module (shared)
# apachectl -M | grep alias
alias_module (shared)
vhost_alias_module (shared)
-> Autoindex + Alias Module sind "aktiv"
#cat /etc/apache2/mods-available/alias.conf
<IfModule alias_module>
# Aliases: Add here as many aliases as you need (with no limit). The format is
# Alias fakename realname
#
# Note that if you include a trailing / on fakename then the server will
# require it to be present in the URL. So "/icons" isn't aliased in this
# example, only "/icons/". If the fakename is slash-terminated, then the
# realname must also be slash terminated, and if the fakename omits the
# trailing slash, the realname must also omit it.
#
# We include the /icons/ alias for FancyIndexed directory listings. If
# you do not use FancyIndexing, you may comment this out.
Alias /icons/ "/usr/share/apache2/icons/"
<Directory "/usr/share/apache2/icons">
Options FollowSymlinks
AllowOverride None
Require all granted
</Directory>
</IfModule>
Und genau diese "geladenen" Regel:
Alias /icons/ "/usr/share/apache2/icons/"
funktioniert so nicht!
Natürlich funktioniert die ganze Sache wenn ich in der Nginx Conf die Regel festlege.
#Alias /icons/ "/usr/share/apache2/icons/"
location ~ ^/icons/.*
{
root /usr/share/apache2/;
}
Gibt es einen Trick um den Alias vom Apache2 nutzen zu können.
Danke
Hello,
ich habe zwar nicht eindeutig verstanden, was Du wünschst, aber nach meiner momentanen Interpretation könnte Dir diese Vorgehensweise vielleicht helfen?
Glück Auf
Tom vom Berg
Hi Tom,
ist vielleicht auch etwas "tricky" von mir ausgedrückt.
Ich versuche es nochmal besser:
Der Alias sagt ja z.B.: das sich das Bild image2.gif nicht im Stammverzeichnis befindet sondern an einer anderen Stelle auf dem Server und von dort geladen werden soll. Diese Regel wird in der /etc/apache2/mods-available/alias.conf formuliert.
Alias /icons/ "/usr/share/apache2/icons/"
Leider kennt der Proxy diese Regel nicht ... und erzeugt somit eine 404 für das Bild image2.gif
es sei denn ich formuliere einen Alias in der Nginx-Proxy-conf
#Alias /icons/ "/usr/share/apache2/icons/"
location ~ ^/icons/.*
{
root /usr/share/apache2/;
}
durch diese Regel wird das entsprechende Bild angesprochen
2019/12/11 15:31:59 [debug] 1791#1791: *486 http filename: "/usr/share/apache2/icons/image2.gif"
Ziel sollte sein das der mods-available Alias dem Nginx-Proxy den korrekten Bild-Path weitergibt.
Mir ist nicht bekannt ob das überhaupt möglich ist.
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "Host: webserver.test"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "Connection: keep-alive"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "Cache-Control: max-age=0"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "Upgrade-Insecure-Requests: 1"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "Referer: http://webserver.test/img/"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "Accept-Encoding: gzip, deflate"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "Cookie: io=w-quB5IH0D_WiLSaAAAC"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "If-None-Match: "419fa618-135""
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header: "If-Modified-Since: Sat, 20 Nov 2004 20:16:24 GMT"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http header done
2019/12/11 15:32:39 [debug] 1791#1791: *486 generic phase: 0
2019/12/11 15:32:39 [debug] 1791#1791: *486 rewrite phase: 1
2019/12/11 15:32:39 [debug] 1791#1791: *486 http script var
2019/12/11 15:32:39 [debug] 1791#1791: *486 http script var: "GET"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http script value: "OPTIONS"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http script equal
2019/12/11 15:32:39 [debug] 1791#1791: *486 http script equal: no
2019/12/11 15:32:39 [debug] 1791#1791: *486 http script if
2019/12/11 15:32:39 [debug] 1791#1791: *486 http script if: false
2019/12/11 15:32:39 [debug] 1791#1791: *486 test location: "/"
2019/12/11 15:32:39 [debug] 1791#1791: *486 test location: ~ "^/icons/.*"
2019/12/11 15:32:39 [debug] 1791#1791: *486 using configuration "^/icons/.*"
2019/12/11 15:32:39 [debug] 1791#1791: *486 http cl:-1 max:1048576
2019/12/11 15:32:39 [debug] 1791#1791: *486 rewrite phase: 3
2019/12/11 15:32:39 [debug] 1791#1791: *486 post rewrite phase: 4
2019/12/11 15:32:39 [debug] 1791#1791: *486 generic phase: 5
2019/12/11 15:32:39 [debug] 1791#1791: *486 generic phase: 6
2019/12/11 15:32:39 [debug] 1791#1791: *486 generic phase: 7
2019/12/11 15:32:39 [debug] 1791#1791: *486 access phase: 8
2019/12/11 15:32:39 [debug] 1791#1791: *486 access phase: 9
2019/12/11 15:32:39 [debug] 1791#1791: *486 access phase: 10
2019/12/11 15:32:39 [debug] 1791#1791: *486 access phase: 11
2019/12/11 15:32:39 [debug] 1791#1791: *486 post access phase: 12
2019/12/11 15:32:39 [debug] 1791#1791: *486 generic phase: 13
2019/12/11 15:32:39 [debug] 1791#1791: *486 generic phase: 14
2019/12/11 15:32:39 [debug] 1791#1791: *486 generic phase: 15
2019/12/11 15:32:39 [debug] 1791#1791: *486 content phase: 16
2019/12/11 15:32:39 [debug] 1791#1791: *486 content phase: 17
2019/12/11 15:32:39 [debug] 1791#1791: *486 content phase: 18
2019/12/11 15:32:39 [debug] 1791#1791: *486 content phase: 19
2019/12/11 15:32:39 [debug] 1791#1791: *486 content phase: 20
2019/12/11 15:32:39 [debug] 1791#1791: *486 content phase: 21
2019/12/11 15:32:39 [debug] 1791#1791: *486 http filename: "/usr/share/apache2/icons/image2.gif"
2019/12/11 15:32:39 [debug] 1791#1791: *486 add cleanup: 00005577ED489D50
2019/12/11 15:32:39 [debug] 1791#1791: *486 http static fd: 14
2019/12/11 15:32:39 [debug] 1791#1791: *486 http set discard body
2019/12/11 15:32:39 [debug] 1791#1791: *486 http ims:1100981784 lm:1100981784
2019/12/11 15:32:39 [debug] 1791#1791: *486 http im:""419fa618-135"" etag:"419fa618-135"
Hello Simone,
ich bin ja 'n bisschen blöd: was hat der NGINX-Proxy mit der inneren Dateiorganisation des Apache-Webservers zu tun?
Ich gehe davon aus, dass es sich hier um zwei separate Hosts handelt, oder lässt Du einen NGINX und einen Apachen auf demselben Host laufen?
Glück Auf
Tom vom Berg
Hm, @NGINX und einen Apachen auf demselben Host laufen?
genau so funktioniert ein "Reverse Proxy" für das http2 Protokoll
Hello Simone,
Du hast auch bestimmt beide Server auf unterschiedliche Ports lauschen lassen und bei der Proxy-Umleitung auch daran gedacht, dass der Zielport der des Apachen sein muss? Sonst befragt der Proxy nämlich seine eigene DocumentRoot, was zu dem von Dir beschriebenen Effekt führen könnte.
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
proxy_pass http://localhost:8000;
include /etc/nginx/proxy_params;
}
}
Beachte die Zeile proxy_pass http://localhost:8000;
Und wenn Du das alles beachtet hast, teste zuerst den Apachen ohne Proxy. Frage also direct localhost:8000/icons
ab.
Glück Auf
Tom vom Berg
Hi,
Danke für Dein Feedback!
Der Proxy läuft und antwortet korrekt
Request URL: http://192.168.4.1:9090/icons/image2.gif
Request Method: GET
Status Code: 200 OK
Remote Address: 192.168.4.1:9090
Referrer Policy: no-referrer-when-downgrade
Accept-Ranges: bytes
Connection: Keep-Alive
Content-Length: 309
Content-Type: image/gif
Date: Wed, 11 Dec 2019 16:54:03 GMT
ETag: "135-3e9564c23b600"
Keep-Alive: timeout=5, max=100
Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT
Server: Apache/2.4.38 (Debian)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Host: 192.168.4.1:9090
Pragma: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1
Meine Ng-conf sieht so aus
map $http_origin $cors_origin_header
{
default "";
"~(^|^http:\/\/)(localhost$|localhost:[0-9]{1,4}$)" "$http_origin";
"https://webserver.test" "$http_origin";
}
map $http_origin $cors_cred
{
default "";
"~(^|^http:\/\/)(localhost$|localhost:[0-9]{1,4}$)" "true";
"https://webserver.test" "true";
}
# Expires map
map $sent_http_content_type $expires {
default off;
text/html epoch;
text/css max;
application/javascript max;
~image/ max;
}
#server_tokens off;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
proxy_pass_header Server;
server
{
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
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 application/javascript;
listen 80;
listen 443 ssl http2;
server_name ~^(www\.)?(?<domain>.+)$;
error_log /home/web/www/html/webserver.test/nginx/error_log.log debug;
access_log /home/web/www/html/webserver.test/nginx/access_log.log combined;
root /home/web/www/html/$domain/dist;
index index.php index.htm index.html;
ssl_certificate /home/web/www/html/webserver.test/ssl/webserver.test+1.pem;
ssl_certificate_key /home/web/www/html/webserver.test/ssl/webserver.test+1-key.pem;
ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:MEDIUM:!aNULL:!MD5;
add_header Access-Control-Allow-Origin $cors_origin_header always;
add_header Access-Control-Allow-Credentials $cors_cred;
add_header "Access-Control-Allow-Methods" "GET, POST, OPTIONS, HEAD";
add_header "Access-Control-Allow-Headers" "Authorization, Origin, X-Requested-With, Content-Type, Accept";
if ($request_method = 'OPTIONS')
{
return 204 no-content;
}
#Alias /icons/ "/usr/share/apache2/icons/"
location ~ ^/icons/.*
{
root /usr/share/apache2/;
}
location /
{
try_files $uri @proxy;
}
location ~* \.(js|css|jpg|jpeg|gif|png|svg|ico|pdf|html|htm)$
{
add_header X-Test-header static;
}
location ~ \.php$
{
proxy_pass http://192.168.4.1:9090;
include /etc/nginx/proxy_params;
add_header X-Test-header php;
}
location @proxy
{
proxy_pass http://192.168.4.1:9090;
include /etc/nginx/proxy_params;
add_header X-Test-header proxy;
}
location ~ /\.ht
{
deny all;
}
expires $expires;
}
Hi,
Der URL-Aufruf:
http://localhost:9090/icons/image2.gif
führt zu einer Nichterreichbarkeit !
Ich habe versucht die Apache conf dynamisch zu halten
<VirtualHost *:9090>
VirtualDocumentRoot /home/web/www/html/%0/dist/
ServerName %0
LogFormat "%V (Intranet host: %h) %{X-Forwarded-For}i %l %u %t \"%r\" %s %b" vcommon
CustomLog /var/log/apache2/access.log vcommon
<Directory "/home/web/www/html/*/dist">
Options Indexes FollowSymLinks MultiViews
AllowOverride all
Require all granted
</Directory>
</VirtualHost>
Hello,
unter welchen Usern laufen denn die Webserverzugriffe?
Dürfen die alle dort lesen, wohin der Alias zeigt?
Glück Auf
Tom vom Berg
Hi,
ich habe das mit bindfs gelöst
adduser web
apt-get -y install bindfs
mkdir -p /home/web/www
chown web:web /home/web/www
chmod 755 /home/web/www
mcedit /etc/fstab
cat /etc/fstab
###### web user ######
bindfs#/var/www /home/web/www fuse force-user=web,force-group=web,create-for-user=www-data,create-for-group=www-data,create-with-perms=0755,chgrp-ignore,chown-ignore,chmod-ignore 0 0
Hello,
☆grins☆
Welche Überraschung kommt als nächstes? Kommt mir inzwischen so vor, wie ein Wickelpaket oder eine Babuschka ;-P
Du hast bestimmt parallel zu dieser Entwicklung auch immer die passenden Test/Debug-Strategien aufgebaut und schrittweise ausprobiert?
Liste doch mal die Zwiebelschalen nebst Tests in der Reihenfolge der Abhängigkeiten auf :-)
Dann wird vielleicht klar, wo die Transparenz kaputt gegangen ist.
Glück Auf
Tom vom Berg
hm,
Überraschung : der Server läuft auf ein PI ;o)
Portiere aber gerade die Sache auf einen Erwachsenen .... und mache die Doku
Über ap0 gibt es eine virtuelle Schnittstelle nicht erreichbar für den Rest der Welt..iptables
Naja nur wenn man den Wlan Zugang hat darf man auf den Server und arbeiten als max 150 Meter ..
# ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:1d:ef:16:54:a1 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.83/24 brd 192.168.0.255 scope global dynamic enp1s0
valid_lft 863975sec preferred_lft 863975sec
inet 192.168.0.80/24 brd 192.168.0.255 scope global secondary dynamic enp1s0
valid_lft 863978sec preferred_lft 863978sec
inet6 fe80::6a1d:efff:fe16:54a1/64 scope link
valid_lft forever preferred_lft forever
3: wlp2s0: mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 50:eb:71:7f:94:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.0.82/24 brd 192.168.0.255 scope global dynamic wlp2s0
valid_lft 863980sec preferred_lft 863980sec
inet6 fe80::52eb:71ff:fe7f:942d/64 scope link
valid_lft forever preferred_lft forever
4: ap0: mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 50:eb:71:7f:94:2e brd ff:ff:ff:ff:ff:ff
inet 192.168.4.1/24 brd 192.168.4.255 scope global ap0
valid_lft forever preferred_lft forever
inet6 fe80::52eb:71ff:fe7f:942e/64 scope link
valid_lft forever preferred_lft forever
@Rechte
sudo chown -R www-data:www-data /var/www/
sudo find /var/www -type d -exec chmod g+s {} +
Hm, mir ist nicht so ganz klar ob der Apache-Alias funktioniert oder eben nicht.
.htaccess Regeln greifen auch mod_rewrite
Muss mir das evtl. noch mal richtig in den Logfiles ansehen
Hello,
wie sieht's aus mit der Installation?
Was ich aber nicht verstehe:
wozu einen NGINX-Proxy auf demselben Host, wie den Apache-Webserver? Eine Abgrenzung zwischen DMZ und Secure-LAN kann man damit doch nicht wirklich erreichen. Und Performance-Gewinn ist doch auch nicht zu erwarten, oder!?
Glück Auf
Tom vom Berg
Hi,
Naja, der Performance-Gewinn sollte mal getestet werden... Ich denke dennoch das es hochperforant sein kann (-wenn richtig eingerichtet-)
siehe hierzu: https://docs.plesk.com/de-DE/obsidian/administrator-guide/70837/
Ich versuche als Entwicklungsoberfläche das nachzubauen was ich im realen Server-Betrieb wirklich nutze. Und Strato macht das eben so.
@Installation
Bin jetzt bei:
sudo a2enmod remoteip
systemctl restart apache2
@Eine Abgrenzung zwischen DMZ und Secure-LAN kann man damit doch nicht wirklich erreichen.
Hm,eine komplette Sicherheit gibt es natürlich nicht... "Entwicklungs-Server" ist nur über Wlan erreichbar SSH binde ich an die virtuelle Schnittstelle incl. IP(Bereich).
# Port 22 nur vom virtuellen Wlan
iptables -A INPUT -i ap0 -p tcp --dport 22 --source 192.168.4.128/25 -j ACCEPT
#ausgehende Netzwerk-Traffic wird zugelassen, aber der gesamte TCP/IP-Traffic von außen einfach ignoriert.
iptables -A INPUT -i wlp2s0 -p tcp -m multiport --destination-port 21,22,53,443,80,9090 -j DROP
iptables -A INPUT -i enp1s0 -p tcp -m multiport --destination-port 21,22,53,443,80,9090 -j DROP
#ausgehende Netzwerk-Traffic wird zugelassen, aber der gesamte udp/IP-Traffic von außen einfach ignoriert.
iptables -A INPUT -i wlp2s0 -p udp -m multiport --destination-port 53,67,68,137,138,5355 -j DROP
iptables -A INPUT -i enp1s0 -p udp -m multiport --destination-port 53,67,68,137,138,5355 -j DROP