Migration Apache 2.2 auf 2.4

[Havusilta]

Hallo zusammen

Bevor ich den DSM auf 6.1 update, wollte ich noch meine beiden Webseiten von Apache 2.2 auf 2.4 bringen. Die kompliziertere (Dynamische Seite mit PHP, MariaDB und Rewriting in einem .htaccess File) funktionierte auf Anhieb. Die einfachere brachte auf einer Unterseite ein Internal Server Error 500. Diese Unterseite ist mittels .htaccess und .htpasswd mit einem Passwort geschützt. Wenn man die .htaccess Datei umbenennt funktioniert alles aber ohne Passwort. Das Problem ist also in der .htaccess / .htpasswd. Habe schon verschiedenes probiert (z.B. anderer Pfad usw.) komme aber nicht weiter. Im Moment sieht das .htaccess File so aus

AuthUserFile /volume1/www.xxxxxx.de/.htpasswd
AuthType Basic
AuthName "My restricted Area"
Require valid-user

Weiss jemand warum das mit Apache 2.2 funktioniert nicht aber mit 2.4 ? Funktioniert das bei jemandem mit Apache 2.4 ?

Danke für alle Infos.

 

[xelarep]

Hallo, ich häng mich hier mal an

Bin nach DS Migration auch gerade an der Umstellung Apache 2.2 nach 2.4. Die Apache Doku bringt mich hier nicht weiter, und den Apachen per AllowOverride zentral zu konfigurieren hab ich noch nicht gefunden :-(
Wer erleuchtet uns?

Alexander

PS: da ist der Einsprungpunkt https://httpd.apache.org/docs/2.4/de/howto/htaccess.html

 

[xelarep]

Hier nochmal als Aufschlag meine unter Apache 2.2 lauffähige .htaccess/.htpasswd Kombi

# .htaccess-Datei fuer Internen Bereich 
AuthType Digest
AuthName "Privater Bereich (SVN)"
AuthUserFile /volume1/web/websvn/.htpasswd
Require valid-user
Order deny,allow
Deny from all
Allow from 192.168
Satisfy any

DirectoryIndex index.php

Alle Anfragen innerhalb meines Netzwerks zu Hause gehen ohne Abfrage durch, wenn ich mich von extern auf meine DS aufschalte kommt eine Passwortabfrage.
Funktioniert unter Apache 2.2 seit Jahren problemslos. Bekomme ich mit Anpassungen unter 2.4 nicht zum Spielen :-(

Nachtrag: ich verwende wegen Safari seit DSM 5.2 die Digest Methode...

Alexander

 

[buzter]

Stehe vor ähnlichen Problemen. Hier gibt es noch ein paar Erklärungen zur neuen Syntax bzw. den Unterschieden. Habe aber selbst noch nichts ausprobieren können.

 

[John Hawk]

DANKE butzer! Der Link hat mir weiter geholfen.

Meine .htaccess sieht jetzt wie folgt aus:

Require all denied
Require ip 192.168.4.0/24

Damit ist meine Internetseite nun nur noch aus dem lokalen Netz erreichbar. Möglicherweise reicht auch nur die 2. Zeile. Das habe ich wiederum noch nicht ausprobiert.

 

[Havusilta]

Habe mich wieder einmal mit diesem Problem beschäftigt, bin aber nicht weitergekommen. Es stimmt 'Require all denied' und 'Require ip 192.168.4.0/24' funktioniert, aber sobald irgend etwas von Auth... dazu kommt gibt es einen Internal Server Error 500. Das Beispiel von Apache (Danke butzer) funktioniert auch nicht:

AuthBasicProvider File
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user

gibt auch einen Internal Server Error 500. Irgend etwas in der Konfiguration 'oder fehlendes Modul' stimmt nicht.

 

[xelarep]

Hallo,

vier Wochen Schonzeit sind um. Hat schon jemand neue Erkenntnisse?

Gruß,
Alexander

 

[buzter]

Hallo, habe nach meinen Fehlversuchen das Thema erst einmal auf Eis gelegt. Hatte auch auf Erkenntnisse hier gehofft.

Habe heute die Aktualisierung des Apache 2.4-Paketes von Synology auf der DS installiert. Vielleicht geht da jetzt was? Mal sehen, ob ich am WE dazu komme.

Viele Grüße

 

[xelarep]

Lustig, das apache Update habe ich kurz nach meinem letzten Post gesehen. Vor dem nächsten WE komme ich aber wahrscheinlich auch nicht zu nem neuen Test

 

[xelarep]

Hmmm keine Änderung: sobald ein "AuthType Digest" in der .htaccess kommt wirft der Apache 2.4 einen Server Error :-(

Hier mal mein aktueller Stand

# .htaccess MyDokuWiki Apache 2.4 (not working)
#
#AllowOverride All
#AllowOverride AuthConfig
#AuthType Digest
AuthName "Privater Bereich (wiki)"
AuthUserFile /volume1/web/dokuwiki/.htpasswd
Require all denied
Require ip 192.168.1.0/24
Require valid-user

Sobald ich AllowOverride oder AuthType die Kommentare wegnehme knallt's...

 

[Lux007]

Hallo,
ich habe mich auchmal mit dem Apache 2.4 und der .htaccess beschäftigt.

Hier mal ein Lösungsweg:
In der httpd24.conf (unter /usr/local/etc/apache24/config) folgende Zeile einfügen:

LoadModule authn_core_module modules/mod_authn_core.so

Danach den Apache 2.4 neu starten (z.B. über das Paketzentrum)!

Damit läuft eine normale .htaccess im Format:

AuthUserFile    /var/services/web/.htpasswd
#AuthUserFile    /volume1/web/.htpasswd
AuthType       Basic
AuthName       "Bitte Benutzername und Passwort eingeben"
require valid-user

Mit dem Pfad unter "AuthUserFile" probieren. Ich habe vHosts laufen, und da wird das Homedir aus irgend einem Grund umgemappt auf den Pfad /var/services/web/...

Gruß
Lux007

 

[xelarep]

Hallo,

Rückmeldung meinerseits: da bei mir mit Providerwechseln nun auch zusätzlich IPv6 ins Haus gezogen ist, musste ich mich mit diesem Thema nochmal beschäftigen. Die Browser auf meinen Rechnern wollen nun per IPv6 auf die Webseiten der DS...
Also nochmal die .htaccess für den Apachen 2.4 umgebaut/erweitert und hochgeladen/umgeschaltet.

Inzwischen (also Ende April 2017 / nach einigen DSM & Apache Paket Updates...) funktioniert nun auch AuthDigest auf meiner DS. Mein .htaccess sieht nun etwa so aus

AuthType Digest
AuthName "Privater Bereich!"
AuthUserFile /volume1/web/privat/.htpasswd

Require all denied
Require ip 192.168.1.0/24
Require ip fe80::/10
Require ip fc00::/7
Require ip 2a02:xxx:xxxx:xxxx::/56

Ich hadere noch mit dem letzten IPv6 Präfix (IA_PD) - scheint aber momentan die einzige Möglichkeit zu sein, in meinem LAN die Passwortabfrage zu unterdrücken?! Der Apache ignoriert, bzw. bekommt nicht die Link local, bzw. Unique Local Adressen zur Auswertung?!

Hat das wer von euch anders gelöst?

 

[xelarep]

Hm, ich habe zurecht gehadert: der IPv6 Präfix hat sich erwartungsgemäss geändert :-(
Zwischenzeitlich habe ich mit

Require host RECHNERNAME

bzw.

Require host RECHNERNAME.fritz.box

oder

Require host .fritz.box

weiter getestet, aber der DSM Apache 2.4 scheint sich dafür nicht zu interessieren :-(

Anderer Ansatz wäre jetzt die .htaccess Datei nach einem IPv6 Präfix-Wechsel automatisch neu zu schreiben. Aber wie könnte ich das denn aufsetzen? Event gesteuert ja eher weniger, zeitgesteuert einmal nachts/morgens? Wie bekomme ich den Präfix raus? Einfach die eigene DS Adresse abschneiden?

 

[Fusion]

Ansatz für Apache
https://github.com/holodyn/dyndns-htaccess

Ansatz für nginx
https://guides.wp-bullet.com/auto-whitelist-multiple-dynamic-dns-addresses-for-nginx-security/

Ist ja allerdings für dynDNS von extern. Aber für die eine global scope IPv6 mit variablem Präfix vielleicht zu gebrauchen.
Ich benutze das um beim externen Zugriff nur Zugriffe auf ausgewählte Hosts/Pfade von ausgewählten externen Anschlüssen zu erlauben.

Intern, vermute ich, dass die Namensauflösung nicht sauber geht und deshalb "Require host name" nicht erfolgreich ist.
Müsstest du aber eigentlich im webserver log sehen können. Oder unter /var/log/messages vielleicht sogar.

 

[xelarep]

Hallo Fusion,

danke! Ich war zwischenzeitlich wohl zu ungeduldig, und hab daher selber was für Apache 2.4 gebastelt:

#!/bin/bash
# Dynamic IPv6 .htaccess file generator
#
# Usage: ./updhtaccess.sh <directory>
# <directory> without trailing slash!
# example: ./updhtaccess.sh /volume1/web/private

hta_folder="$1"
hta_file="$1/.htaccess"
hta_tmpl="$hta_file.tmpl"

#check if template available
if [ -f "$hta_tmpl" ]
then
	echo "$hta_tmpl found."
else
	echo "$hta_tmpl not found. updhtaccess.sh terminated!"
	exit
fi

# DSM implementation
hta_ipv6=$(ifconfig eth0 | grep Scope:Global | awk '/inet6/{print $3}')
# macOS for testing
#hta_ipv6=$(ifconfig en0 | grep 'autoconf secured' | awk '/inet6/{print $2}')

hta_prefix="Require ip $hta_ipv6"

# create new .htaccess file based on template
cp $hta_tmpl $hta_file
echo "$hta_prefix" >> $hta_file 2>&1
echo "Require valid-user" >> $hta_file 2>&1
echo "$hta_file written."

Dieses Shellskript erwartet im Zielvezeichnis eine .htaccess.tmpl die beispielsweise so aussieht

# .htaccess dynamic Apache 2.4 
# host based, as IPv6 prefixes are changing...

AuthType Digest
AuthName "Privater Bereich"
AuthUserFile /volume1/web/private/.htpasswd

Require all denied
Require ip 192.168.1.0/24
Require ip fe80::/10
Require ip fc00::/7

Der Aufgabenplaner wird diese nun einmal täglich ausführen Dazu liegt das script im home des Admin users, und in dessen Kontext wird das Skript auch ausgeführt. Bei mir sind's mehrere Ordner in denen ich mit .htaccess arbeite, daher dann gleich mehrere Aufgaben...

Funktionsweise ist vielleicht nicht der eleganteste Weg - aber was mach ich überhaupt? Ich hole mir per ifconfig/grep/awk die IPv6 Adresse meiner DS. Diese ist 'glücklicherweise' schon soweit aufbereitet (/64), dass ich sie meinem IPv6 Präfix entspricht und kann nun einfach eingesetzt (genauer: ans template angefügt )werden und letztendlich kommt noch für extern die Nutzerabfrage dran. Fertig!

Fehlerüberprüfung momentan nur auf Vorhandensein eines templates.

Alexander

 

[Fusion]

Sehr schön, danke fürs Teilen.

 

[xelarep]

Bitteschön

Hab's zur weiteren Diskussion, Hege und Pflege mal auf GitHub gestellt: https://github.com/xelarep/updhtaccess

 

[xelarep]

Kurzer Nachschlag: heute morgen hat sich eine ULA Adresse mit in die Suchergebnisse von grep gemogelt, und damit die .htaccess unbrauchbar gemacht. Ich hab gerade die 'Adressbauzeile' entsprechend angepasst, und dabei auch gleich die Prefixlänge korrigiert (mein ISP vergibt /56, das Script hat /64 durchgewunken...)

hta_ipv6=$(ifconfig eth0 | grep 2a02 | awk '/inet6/{print $3}' | sed 's/\/64/\/56/g')

2a02 bitte durch den Adressanfang eures ISPs ersetzen... Alles komplett unter https://github.com/xelarep/updhtaccess

 

[xelarep]

Nach nem halben Jahr ein kleines Update: manchmal spuckt ifconfig noch zwei Adressen aus dem Bereich 2a02 aus. Ich hab mal den 50:50 Joker gesetzt und unterdrücke nun die zweite, das sonst das file insgesamt ungültig wird. Endlösung ist das noch nicht, aber hilft ist mal weiter
Ich müsste noch rausbekommen, wie man die ungültige Adresse in der Synology los wird, oder ob ich einfach meine Adresse noch später nach der Zwangstrennung aktualisiere.

hta_ipv6=$(ifconfig eth0 | grep 2a02 -m 1 | awk '/inet6/{print $3}' | sed 's/\/64/\/56/g')

Update wie gehabt auf GitHub https://github.com/xelarep/updhtaccess