nicht angemeldet
Rolf B
Rolf B
Tabellenkalk
Rolf B
Rolf B
Hallo Forum,
ich lese mir gerade ein paar dinge über Symlinks durch, weil es sein, kann, dass sie mein Problem lösen, bin abe rnicht sicher, ob ich Symlinks richtig verstehe.
Ich habe in Verzeichnis V7 ein Unterverzeichnis U12.
V7 ist ein php7-Verzeichnis, folglich läuft auch der U12 auf php7, ganz egal, was ich für U12 separat eingestellt habe. (wird von oben quasi rekursiv gebügelt)
Nun möchte ich aber U12 gerne mal auf php8 ausprobieren.
Hierzu habe ich ein Verzeichnis V8 erstellt, dass unter php8 läuft.
Hier herein habe ich den U12 Verzeichnis kopiert. Auch dieses läuft unter php8.
Der Test wäre ja easy, wenn ich einfach den U12 unterhalb des V8 aufrufe, aber darum geht es mir nicht. Mir geht es darum, dass ich den V7/U12 wie immer aufrufen kann, er aber komplett die V8/U12 nutzt.
Kann ich hierfür Symlinks nutzen?
Ich bin auch ansderen Vorschlägegn gegenüber aufgeschlossen.
Einzig der Aufruf der U12/index.php muss so bestehen bleiben, wie immer.
Denn wenn ich einfach im Server den Startpfad ändere, klappt zwar mein Vorhaben, aber das SSL-Zertifikat gilt dann nicht mehr.
Ich habe den Eindruck, den Server grad irgendwie überlisten zu müssen.
Aufruf ist bisher:
U12.my-domain.de
.htaccess macht daraus:
RewriteEngine on
rewriteCond %{HTTP_HOST} U12.my-domain.de
RewriteRule (.*)$ https://my-domain.de/U12/$1
Das ist wichtig, weil das SSL-Zertifikat kein Wildcard-Zertifikat ist.
Startpfad auf dem Server ist für die Subdomain U12.my-domain auf /V7/U12 eingestellt und für V7.my-domain auf /V7.
Ziel ist, wie schon gesagt, dass ich mit dem Aufruf
U12.my-domain.de
SSL-zertifiziert arbeiten kann, aber unterm Strich das V8/U12 Verzeichnis nutze.
Hoffe, ich habe mein Vorhaben einigermaßen schlüssig rüber gebracht.
Das V7-Verzeichnis einfach auf php8 umstellen, wäre natürlich die einfachste Lösung, aber dann habe ich das gleich für alle User umgestellt.
Wenns also Probleme gibt, dann sofort für alle User, die bisher unter V7 gut unterwegs sind.
Deshalb möchte ich es erstmal für einen einzigen User (U12) umstellen, aber ohne, dass er dazu neue Logindaten benötigt oder plötzlich eine "nicht sichere Verbindung" angezeigt bekommt.
Jörg
Generell erscheint das Vorgehen sinnvoll.
Aber pass auf:
Nehmen wir also an, Du hast die Verzeichnisse
/var/www/v7
/var/www/v8
und eine Datei /var/www/v7/test.php.
Jetzt legst Du mit
ln -s /var/www/var/www/v7/test.php /var/www/var/www/v8/test.php
einen symbolischen Link an. Soweit, so gut...
Wenn da nur nicht die Software wäre...
nano /var/www/var/www/v8/test.php
Dann bearbeitest Du /var/www/var/www/v7/test.php also die echte Datei.
Wenn Du Dich aber unter Windows via WinSCP & Co verbindest und /var/www/var/www/v8/test.php bearbeitest, dann wird aus dem symbolischen Link zur neuen echte Datei. Darüber bin ich mal verzweifelt…
Noch mehr Überraschungen dieser Art kann es geben, wenn Du ganze Unterordner symbolisch verlinkst... Es kann also gute Gründe geben, statt mit Symlinks mit Kopien zu arbeiten. Eben weil klarer ist, was Du bearbeitest.
Noch ein Hinweis:
Bei PHP fallen manchmal heftige Änderungen bei kleineren Versionssprüngen an. Nicht alles, was unter PHP 7.0 noch lief läuft unter PHP 7.4. „et visa versa“.
→ Nenne die Ordner also gleich php7.4, php8.0, php8.1, php8.2 (u.s.w.)
Hallo Raketenwilli,
Generell erscheint das Vorgehen sinnvoll.
Ich bin ja kein Apache, sondern ein windoofer IISiot. Deswegen entziehen sich hier bestimmte Dinge vielleicht meinem Verständnis.
Wenn man /var/www/V8/U12 nach /var/www/V7 hinein symlinkt, dann kann ich doch mit zwei Pfaden auf diesen Ordner zugreifen. Einmal als /var/www/V7/U12, und einmal als /var/www/V8/U12.
Die Vererbung von Apache Konfigurationen (sprich: .htaccess Dateien oder Directory-Direktiven in der httpd.conf) sollte sich aber doch an dem Pfad orientieren, auf dem ich den Ordner erreiche. Das heißt für mich: Wenn ich auf /var/www/V8/U12 zugreife, erbt U12 die Einstellungen von V8. Und wenn ich auf /var/www/V7/U12 zugreife, erbt es die Einstellungen von V7.
Ist das ein Mistverständnis?
Mein Ansatz wäre bei der Frage: Wie ist dem /var/www/V8 Ordner denn zugewiesen, dass er PHP8 verwenden soll? Da steht doch bestimmt irgendwo
<Directory /var/www/V7>
// nimm PHP 7
</Directory>
<Directory /var/www/V8>
// nimm PHP 8
</Directory>
in einer Config-Datei. Ich weiß jetzt nicht, wie der Apache seine Directory-Direktiven Organisiert, aber da müsste man doch etwas in dieser Art schreiben können:
<Directory /var/www/V7/U12>
// nimm PHP 8
</Directory>
Ob man das vor oder nach den bestehenden Regeln machen muss, hängt davon ab, wie Apache das priorisiert.
Rolf
Hallo Raketenwilli,
Generell erscheint das Vorgehen sinnvoll.
Ich bin ja kein Apache, sondern ein windoofer IISiot. Deswegen entziehen sich hier bestimmte Dinge vielleicht meinem Verständnis.
Wenn man /var/www/V8/U12 nach /var/www/V7 hinein symlinkt, dann kann ich doch mit zwei Pfaden auf diesen Ordner zugreifen. Einmal als /var/www/V7/U12, und einmal als /var/www/V8/U12.
Ja. Wobei letztendlich die Frage im Raum steht, ob die Ordner oder aber die Dateisystemobjekte in den Ordnern verlinkt werden.
Die Vererbung von Apache Konfigurationen (sprich: .htaccess Dateien oder Directory-Direktiven in der httpd.conf) sollte sich aber doch an dem Pfad orientieren, auf dem ich den Ordner erreiche.
Ja. Bei PHP als FPM oder cgi. AddHandler und SetHandler haben beide den Context „server config → virtual host → directory → .htaccess“ und das wird in der Reihenfolge abgearbeitet. Wer also im Obigen zuletzt etwas wie
AddHandler application/x-httpd-php82 .php
oder
<FilesMatch ".+\.ph(?:ar|p|tml)$">
SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost"
</FilesMatch>
setzt, hat Recht.
Das heißt für mich: Wenn ich auf /var/www/V8/U12 zugreife, erbt U12 die Einstellungen von V8. Und wenn ich auf /var/www/V7/U12 zugreife, erbt es die Einstellungen von V7.
Ist das ein Mistverständnis?
Nein. Ist goldrichtig.
Mein Ansatz wäre bei der Frage: Wie ist dem /var/www/V8 Ordner denn zugewiesen, dass er PHP8 verwenden soll? Da steht doch bestimmt irgendwo
Siehe oben. Auch für den Rest.
Hi Willi,
- Noch mehr Überraschungen dieser Art kann es geben, wenn Du ganze Unterordner symbolisch verlinkst... **
Ja, aber ganu das hatte ich ja vor...
Es kann also gute Gründe geben, statt mit Symlinks mit Kopien zu arbeiten. Eben weil klarer ist, was Du bearbeitest.**
Was mir viel lieber wäre.
Aber ich habe Sorge, dann genau in das Problem zu rennen, dass das SSL-Zertifikat dann nicht mehr greift.
Jörg
Hallo Jörg,
Ja, aber ganz das hatte ich ja vor...
Und ich glaube, das solltest Du lassen.
Mit Symlinks findest Du nach meinem Dafürhalten keine Lösung. Auch Raketenwilli ist in seiner ersten Antwort nicht darauf eingegangen, ob ein Symlink Dich überhaupt zum Ziel führt.
Bitte prüfe, ob Du lokal für /var/www/V7/U12 PHP8 setzen kannst. Oder warum das nicht geht, wenn Du es bereits probiert hast. Über Gründe, weshalb Symlinks nicht helfen, und über Mechanismen für PHP Zuordnungen habe ich mit Raketenwilli diskutiert.
Rolf
Hallo,
Ja, aber ganz das hatte ich ja vor...
Und ich glaube, das solltest Du lassen.
Und ich halte es für verwirrend, Zitate unkommentiert zu verändern. Wenn man auf Tippfehler stößt, kann man das im Zitat mit „[sic!]“ kenntlich machen.
Jörg schrieb „ganu“ und meinte vermutlich „genau“. Sagt zumindest meine nuschelnde Glasmurmel.
In diesem Fall ist es letztlich egal, aber es kann schonmal sinnentstellend werden…
Gruß
Kalk
Hallo Tabellenkalk,
soviel zu meinem Talent zur Spracherkennung...
Rolf
Hallo Rolf,
Bitte prüfe, ob Du lokal für /var/www/V7/U12 PHP8 setzen kannst. Oder warum das nicht geht, wenn Du es bereits probiert hast. Über Gründe, weshalb Symlinks nicht helfen, und über Mechanismen für PHP Zuordnungen habe ich mit Raketenwilli diskutiert.
Nein, ich kann das nicht local auf php8 setzen, weil /var/www/V7/ nicht auf php8 steht. Stünde /var/www/V7/ auf php8, dann würde auch /var/www/V7/U12 auf php8 stehen, denn immer das höher liegende verzeichnis bestimmt bei meinem Provide die php-Version.
Und genau das ist auch das Problem, weil ich damit die User nicht sukkzessive auf php8 umstellen kann, sondern nur alle auf einmal. Jedenfalls unter der Voraussetzung, dass die User keine neuen Logindaten brauchen oder aber plötzlich ohne SSL-Zertifikat da stehen.
Jörg
Hallo Jörg,
Nein, ich kann das nicht local auf php8 setzen, weil /var/www/V7/ nicht auf php8 steht.
Eine kühne Behauptung.
Würdest Du die Freundlichkeit besitzen, uns mitzuteilen, wie dieses "auf PHP 8 stehen" realisiert ist? Ist das etwas, das im Admin-Panel des Hosters gesetzt wird?
Ist das die einzige Chance, die Dir dein Hoster gibt, um eine PHP Version zuzuordnen? Denn wir hatten (ahem - Raketenwilli hat) auch andere Wege genannt.
Rolf
Hallo Jörg,
Nein, ich kann das nicht local auf php8 setzen, weil /var/www/V7/ nicht auf php8 steht.
Eine kühne Behauptung.
Leider aber auch inkl. Beweis.
Würdest Du die Freundlichkeit besitzen, uns mitzuteilen, wie dieses "auf PHP 8 stehen" realisiert ist? Ist das etwas, das im Admin-Panel des Hosters gesetzt wird?
Sehr gerne.
Alle Domains und Subdomains kann ich über das Admin-Panel getrennt auf eine php-Version setzen.
V7 steht bei mir auf 7.4
u12 steht auf 8.1
phpinfo() im u12 sagt mir, dass php 7.4 läuft.
Ist das die einzige Chance, die Dir dein Hoster gibt, um eine PHP Version zuzuordnen? Denn wir hatten (ahem - Raketenwilli hat) auch andere Wege genannt.
Ja, ich kann es nur im Admin-Panel schalten.
Ist halt ein gemanageder Server, insofern habe ich begrenzte Berechtigungen.
Hallo Jörg,
Ja, ich kann es nur im Admin-Panel schalten.
Ist halt ein gemanageder Server, insofern habe ich begrenzte Berechtigungen.
Ja ok. Hast Du deinen Support mal gefragt, ob es eine Möglichkeit gibt?
Rolf
HI Rolf,
Ja ok. Hast Du deinen Support mal gefragt, ob es eine Möglichkeit gibt?
Mehrfach schon. Bisher aber keine Lösung.
Jörg
Ja, ich kann es nur im Admin-Panel schalten. Ist halt ein gemanageder Server, insofern habe ich begrenzte Berechtigungen.
dann überprüfe bzw. korrigiere den Eintrag, der sich ggf. außerdem noch in der .htaccess des jeweiligen virtuellen Hosts finden könnte. Dort kann man einen solchen auch einbauen. Möglicherweise macht Dich ein Blick in den Ordner /etc/php, oder, wenn Du ein Debian-artiges Linux hast, nach /etc/apache2/([conf|mods)_(available|enabled] auch schlauer.
Nein, ich kann das nicht local auf php8 setzen, weil /var/www/V7/ nicht auf php8 steht.
Eine kühne Behauptung.
Möglicherweise meint der Rolf, dass Du die PHP-Version ja auch in der .htaccess setzen kannst (2. Hälfte).
Dazu muss man aber wissen, wie PHP installiert ist. (Modul, fpm-cgi, cgi-fcgi, …)
Das kann man sich anschauen (Beispiel - Future-Requests sind willkommen):
<?php
$pattern='/[0-9]+\.[0-9]+/';
preg_match ( $pattern , phpversion(), $matches );
?>
<p>PHP <?=$matches[0]; ?> läuft als <?=php_sapi_name(); ?></p>
<p>Geladene PHP-Erweiterungen: <?=implode(", ", get_loaded_extensions());?></p>
Alles weitere kann man die allwissende Datenmüllhalde fragen.
Ja ok. Hast Du deinen Support mal gefragt, ob es eine Möglichkeit gibt?
Mehrfach schon. Bisher aber keine Lösung.
Hallo Raketenwilli,
dass der Support keine Ahnung hat, ist Möglichkeit 1. Und nicht unwahrscheinlich.
Möglichkeit 2 ist, dass der Hoster die entsprechende Apache Direktive nicht für .htaccess zulässt. Das kann diverse Gründe haben. Als sparsamer Anbieter stellt man lieber weniger als mehr Features bereit, denn jedes Knöpfchen, an dem der Kunde drehen kann, ist auch eins, zu dem der Kunde Fragen stellen könnte oder mit dem er das System so gründlich verstellen kann, dass nichts mehr geht. In beiden Fällen ist Support gefragt. Womit wir wieder bei Möglichkeit 1 wären…
Rolf
dass der Support keine Ahnung hat, ist Möglichkeit 1. Und nicht unwahrscheinlich.
Jörg schreibt, er habe einen managed server. Wenn der Support Ahnung hätte, hätte er in Nullkommanix herausbekommen, wie er auch ohne Adminpaneel (eine Verwaltung des Servers via Webseite) die PHP-Version für einen virtHost ändert…
Wenn er das nicht rausbekommt, dann sollte er nicht mit der USER_ID 0 tätig werden…
Hallo Raketenwilli,
was ein Adminpanel (oder -paneel) ist, weiß sogar ich 😉
Ich meinte ja nur, dass die erforderliche Direktive möglicherweise nicht für .htaccess freigeschaltet ist. Das kann man doch - meine ich - in der httpd.conf festlegen.
Ein Adminpanel läuft mit Adminrechten des Hosters und kann deshalb vermutlich auch die höherrangigen .conf Dateien ändern.
Rolf
was ein Adminpanel (oder -paneel) ist, weiß sogar ich 😉
Klar. Jeder mit Hirn im Kopf weiß, was Admin-Panele sind.
Das kann man doch - meine ich - in der httpd.conf festlegen.
Oder in einer der laut httpd.conf zu includierten Dateien…
(je nach Admin-Panel wird das aber vorliegend „verpfuscht“ sein.)
Wenn aber der wohl teuer mit gemietete Admin(root) das nicht herausbekommt und selbst nur mit dem Panel arbeiten kann, dann ist das nicht nur „sowas von Level 1 - Support“ sondern ein Armutszeugnis und der Anbieter kann den Geschäftsführer losschicken um im Christian-Lindner-Chor das Lied vom Fachkräftemangel mit zu singen.
Aber ich habe Sorge, dann genau in das Problem zu rennen, dass das SSL-Zertifikat dann nicht mehr greift.
Du hast einen Webserver. In dem ist der oder die Servername(n) konfiguriert. Und dass dieser bei einem Request nach einer Ressource unterhalb von „example.org“ oder „www.example.org“ eine bestimmte SSL-Konfiguration, also ein bestimmtes Zertifikat benutzt. Aber auch jeweils ein Verzeichnis, in dem der Webserver die Ressourcen erwartet. (DOCUMENT_ROOT)
Da Du kein Wildcard-Zertifikat hast, sendest Du, wenn Du Subdomains (eg. php72.example.org, php74.example.org, php80.example.org, ... ) einrichtest, entweder gar kein Zertifikat - oder das falsche. Denn dann sendest Dein Server (je nach Konfiguration) womöglich das für die Hauptdomain gültige.
Wenn Du (notlos) für Testzwecke Subdomains einrichtest, hast Du also entweder kein HTTPS oder ein für die Subdomain ungültiges Zertifikat (noch kannst Du dem Browser „sagen“, dass er das akzeptieren soll, in Zukunft wird das aus Sicherheitsgründen aufwendiger, „normalen“ Benutzern (erst recht den Admins!), z.B. in einer Windows-Domain, wahrscheinlich sogar gar nicht mehr erlaubt).
Daran ändert kein Link der Welt etwas!
Die Idee, mittels Links die Zuordnung ServerName ←→ Zertifikat ändern zu wollen, erschien mir so fern liegend, dass ich mich bisher dazu nicht geäußert habe. Ich dachte, das hätte ich falsch verstanden.
Willst Du für Deine Tests gültige Zertifikate, dann musst Du „Unterverzeichnisse“ der Domain
nutzen oder ein gültiges (Wildcard-)Zertifikat besorgen.
Und in den Ordnern dann Kopien des Auftritts - damit Du nicht versehentlich die falsche Datei „mit“ umschreibst, so dass diese nun zwar mit PHP8.2, aber nicht mehr mit PHP7.2 funktioniert. (Das kann Deinen eigentlichen Webauftritt kaputt machen!) Natürlich muss der Webserver so konfiguriert sein, dass er für die Ordner die entsprechende PHP-Version benutzt. Ich würde hier sehr ernsthaft vorschlagen, die PHP-Version für die Test-Verzeichnisse in der .htaccess zu konfigurieren. Wäre blöd, wenn die ein Link ist.
Sorge dafür, dass alles unter https://example.org/tests/ bzw. /var/www/example.org/tests/ nur für Berechtigte abgerufen werden kann.
Ja. Es ist richtig, dass dann alle Links in den Webseiten und alle Zugriffe von PHP auf Dateien mit relativen Adressen gebaut werden müssen. Das ist aber ohnehin die weitaus bessere Idee.
Etwas anderes sind Libarys, die mit PHP nichts zu schaffen haben. Ordner wie (DOCUMENT_ROOT)/images, (DOCUMENT_ROOT)/fonts, (DOCUMENT_ROOT)/js, (DOCUMENT_ROOT)/data, (DOCUMENT_ROOT)/templates kannst Du natürlich verlinken, aber auch für diese würde ich erst mal eine Kopie haben wollen:
cp -r /var/www/example.org/images /var/www/example.org/tests/static
und erst dann verlinken:
ln -s /var/www/example.org/tests/static/images /var/www/example.org/tests/php72/images
# …
ln -s /var/www/example.org/tests/static/images /var/www/example.org/tests/php80/images
Hi Willi,
Da Du kein Wildcard-Zertifikat hast, sendest Du, wenn Du Subdomains (eg. php72.example.org, php74.example.org, php80.example.org, ... ) einrichtest, entweder gar kein Zertifikat - oder das falsche. Denn dann sendest Dein Server (je nach Konfiguration) womöglich das für die Hauptdomain gültige.
Na, genau das soller auch senden.
Willst Du für Deine Tests gültige Zertifikate, dann musst Du „Unterverzeichnisse“ der Domain
- https://example.org/tests/php72 z.B. mit dem Ordner /var/www/example.org/tests/php72
- https://example.org/tests/php74 z.B. mit dem Ordner /var/www/example.org/tests/php74
- https://example.org/tests/php80 z.B. mit dem Ordner /var/www/example.org/tests/php80
- https://example.org/tests/php81 z.B. mit dem Ordner /var/www/example.org/tests/php81
- https://example.org/tests/php82 z.B. mit dem Ordner /var/www/example.org/tests/php82
nutzen oder ein gültiges (Wildcard-)Zertifikat besorgen.
Na, aber genau das mache ich doch, denn ich leite doch per .htaccess eine eventuell aufgerufene Subdomain u12.my-domain.de auf https://my-domain.de/u12 um. Hattest Du das in meinem Ausgangspost womöglich überlesen?
- Ja. Es ist richtig, dass dann alle Links in den Webseiten und alle Zugriffe von PHP auf Dateien mit relativen Adressen gebaut werden müssen. Das ist aber ohnehin die weitaus bessere Idee.
Undramatisch, denn so ist das bei mir ohnehin.
- Etwas anderes sind Libarys, die mit PHP nichts zu schaffen haben. Ordner wie (DOCUMENT_ROOT)/images, (DOCUMENT_ROOT)/fonts, (DOCUMENT_ROOT)/js, (DOCUMENT_ROOT)/data, (DOCUMENT_ROOT)/templates kannst Du natürlich verlinken, aber auch für diese würde ich erst mal eine Kopie haben wollen:
Wäre mir auch am liebsten.
- Libarys, die in PHP geschrieben sind, solltest Du in diesen Szenario als Kopie vorhalten, denn es gibt keine Garantie, dass jede Version von diesen mit jeder Version von PHP benutzt werden kann - eher die gegenteilige Vermutung.
Bei mir 50-50. Einige musste ich updaten oder selber umschreiben, anderen funktionieren einfach weiter.
Jörg
Hallo Jörg,
Na, genau das soller auch senden.
Nö. Wenn der Browser einen Request an u12.example.com schickt, will er ein valides Zertifikat für u12.example.com haben. Und nicht für www.example.com.
denn ich leite doch per .htaccess eine eventuell aufgerufene Subdomain u12.my-domain.de auf https://my-domain.de/u12 um
my-domain.de bitte nicht verwenden, die existiert real. Nimm example.com oder example.org
Aber - nein. Du leitest die Anfrage serverintern dorthin um. Aber davon weiß der Brauser nichts, denn dann müsste da - es sei denn meine Apache-Unkenntnisse werden wieder mal grell beleuchtet - noch ein R stehen (was Dir aber nichts nützt, weil das den Browser dazu bringt, eine neue Anfrage mit der umgeschriebenen URL zu senden). D.h. der Browser fragt u12.example.com, dein Apache beantwortet das im Kontext von v7.example.com oder v8.example.com und schickt ein Zertifikat für example.com.
Rolf
Dann hab ich wohl an dem
Ziel ist, wie schon gesagt, dass ich mit dem Aufruf
U12.my-domain.deSSL-zertifiziert arbeiten kann, aber unterm Strich das V8/U12 Verzeichnis nutze.
zu sehr fest gehalten.
https://U12.example.org kannst Du nicht nutzen, hast ja kein Zertifikat.
Aber Du kannst http://u12.example.org/ in der Konfiguration des virtuellen Hosts so einstellen, dass der Benutzer zu https://www.example.org/U12 weiter geschickt wird und dann wird freilich das Zertifikat für www.example.org benutzt.
Nur verwirrt mich dann die Frage nach den Links.
Bitte benutze für Beispiele example.org. Das ist aus gutem Grund genormt.
Hallo Rolf, hallo Willi,
nur nochmal für Euch zitiert:
Aufruf ist bisher:
U12.my-domain.de
.htaccess macht daraus:
RewriteEngine on
rewriteCond %{HTTP_HOST} U12.my-domain.de
RewriteRule (.*)$ https://my-domain.de/U12/$1Das ist wichtig, weil das SSL-Zertifikat kein Wildcard-Zertifikat ist.
Also ok, ab jetzt dann example.org...
Was ich aber sagen wollte:
Es gibt defacto keinen (jedenfalls nicht für das SSL-Zertifikat) Aufruf von subdomain.example.org, weil per .htaccess immer daraus https://example.org/subdomain/ gemacht wird.
Jörg
Hab den Thread hier teils verfolgt und mich hat auch stutzig gemacht, was Du eigentlich erreichen willst, bzw. was Dein Thema ist. Symlinks in dem Zusammenhang klingen echt schräg.
Vielleicht bringt Dir ja das konkrete Beispiel Erkenntnis:
Es gibt defacto keinen (jedenfalls nicht für das SSL-Zertifikat) Aufruf von subdomain.example.org, weil per .htaccess immer daraus https://example.org/subdomain/ gemacht wird.
Da könnte der Denkfehler liegen. Wenn ich zum ersten Mal "subdomain.example.org" abrufen möchte, dann findet VOR Deiner .htaccess der SSL-Handshake & Co statt. Erst DANACH greift Dein Rewrite.
Du kannst lt. Rakentfleischwurst pro Domains eigene Zertifikate hinterlegen, Wildcard... oder m.E. auch einfach die entsprechenden Alternativnamen hinterlegen.
Es gibt defacto keinen (jedenfalls nicht für das SSL-Zertifikat) Aufruf von subdomain.example.org, weil per .htaccess immer daraus https://example.org/subdomain/ gemacht wird.
Äh. Nein. Ich zeig Dir mal GENAU das:
RewriteCond %{HTTP_HOST} !^www\.fastix\.org
RewriteRule ^(.*)$ https://www.fastix.org/$1 [R=permanent,L]
Ok? Run:
wget -d https://fastix.org
DEBUG output created by Wget 1.21.2 on linux-gnu.
Reading HSTS entries from /home/fastix/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2022-08-25 16:49:43-- https://fastix.org/
Auflösen des Hostnamens fastix.org (fastix.org) … 81.28.228.47
Caching fastix.org => 81.28.228.47
Verbindungsaufbau zu fastix.org (fastix.org)|81.28.228.47|:443 … verbunden.
Created socket 3.
Releasing 0x00000055a33833f0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x00000055a3385120
certificate:
subject: CN=fastix.org
issuer: CN=R3,O=Let's Encrypt,C=US
X509 certificate successfully verified and matches host fastix.org
---request begin---
GET / HTTP/1.1
Host: fastix.org
User-Agent: Wget/1.21.2
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive
---request end---
HTTP-Anforderung gesendet, auf Antwort wird gewartet …
---response begin---
HTTP/1.1 301 Moved Permanently
Date: Thu, 25 Aug 2022 14:49:43 GMT
Server: Apache
Location: https://www.fastix.org/
Die Übertragung des Request-Headers und die Weiterleitung per Antwort-Header erfolgen nach der Überprüfung des Zertifikats. Warum zum Teufel sollte denn der Browser einem womöglich gefakten Server die Weiterleitungsadresse glauben - den Inhalt einer Webseite hingegen nicht?
Wäre es anders, wüsste der Server auf der IP 81.28.228.47 nicht, welches der zig Zertifikate (da sind viele Webauftritte drauf...) er vorweisen soll.
Versuch mit ungültigem Hostname:
~> echo 81.28.228.47 foo.fastix.org | sudo tee -a /etc/hosts
81.28.228.47 foo.fastix.org
Und dann ...
tmp$ wget -d https://foo.fastix.org
DEBUG output created by Wget 1.21.2 on linux-gnu.
Reading HSTS entries from /home/fastix/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2022-08-25 17:05:19-- https://foo.fastix.org/
Auflösen des Hostnamens foo.fastix.org (foo.fastix.org) … 81.28.228.47
Caching foo.fastix.org => 81.28.228.47
Verbindungsaufbau zu foo.fastix.org (foo.fastix.org)|81.28.228.47|:443 … verbunden.
Created socket 3.
Releasing 0x00000055a7ae72c0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x00000055a7ae9100
certificate:
subject: CN=web.vrmd.de
issuer: CN=R3,O=Let's Encrypt,C=US
FEHLER: Keiner der alternativen Namen des Zertifikats stimmt mit dem angefragten Maschinennamen ‘foo.fastix.org’ überein.
Verwenden Sie »--no-check-certificate«, um zu dem Server foo.fastix.org eine nicht gesicherte Verbindung aufzubauen.
Closed 3/SSL 0x00000055a7ae9100
Hallo,
ich habe eine praktikable Lösung gefunden, ich kann doch einfach alle Aufrufe per .htaccess an eine andere Domain (die ein eigenes SSL hat) weiterleiten, dann bleibt für den user der Aufruf identisch und sein Browser meckert keine fehlendes SSl an. Und die andere Domain nutzt eben php8.
Und jetzt die Frage:
Meine .htacess-rewrite-Versuche decken schon ein paar Aufrufvariationen ab, aber nicht alle.
Variationen:
Wie bringe ich das der .htaccess bei?
Denn dann wäre ich im Prinzip genau dort, wo ich sein möchte. Im v8-Verzeichnis, mit php8 und der User bekommt im Browser eine SSL-zetrifizierte Seite angezeigt.
Oder spricht etwas gegen diese Lösung (außer der noch fehlenden .htacces-Einträge)?
Jörg
Variationen:
- u12.example.org soll https://new_example.org/u12/ ergeben
- u12.example.org/test.php soll https://new_example.org/u12/test.php ergeben
- example.org/u12/dir soll https://new_example.org/u12/ ergeben
- usw.
- u12.ex-ample.org soll https://new_example.org/u12/ ergeben
- u12.ex-ample.org/test.php soll https://new_example.org/u12/test.php ergeben
- ex-ample.org/u12/dir soll https://new_example.org/u12/ ergeben
- sollte jemand www. nutzen, solls ersatzlos gestrichen werden
Wie bringe ich das der .htaccess bei?
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.org/$1 [R=permanent,L]
RewriteCond %{HTTP_HOST} !^www\.example\.org
RewriteRule ^(.*)$ https://www.example.org/$1 [R=permanent,L]
RewriteRule ^/foo/(.*)$ https://www.example.org/bar/$1 [R=permanent]
RewriteRule ^/bar/(.*)$ /tok/$1 [R=permanent]
Ist „englisch für Arme“. Übersetze es Dir, dann kannst Du das anpassen.
Das muss natürlich in der Konfiguration des Hosts stehen, der jeweils „antelefoniert“ wird…
Hallo Willi,
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.org/$1 [R=permanent,L]RewriteCond %{HTTP_HOST} !^www.example.org
RewriteRule ^(.*)$ https://www.example.org/$1 [R=permanent,L]Ist „englisch für Arme“. Übersetze es Dir, dann kannst Du das anpassen.
Bist Du sicher? Ich will ja gerade nicht zu https://www. geleitet werden, im Gegenteil.
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.org/$1 [R=permanent,L]
RewriteCond %{HTTP_HOST} ^www\.example\.org
RewriteRule ^(.*)$ https://example.org/$1 [R=permanent,L]
Schaust du mal drüber?
Ich will ja gerade nicht zu https://www. geleitet werden, im Gegenteil.
Ich schrieb ja: Übersetzen → Anpassen,
RewriteEngine on RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://example.org/$1 [R=permanent,L] RewriteCond %{HTTP_HOST} ^www\.example\.org RewriteRule ^(.*)$ https://example.org/$1 [R=permanent,L]Schaust du mal drüber?
Wenn es das ist, was Du willst (sieht so aus) - dann hast Du gewonnen.
Hallo Willi,
- Was auch immer bei http://example.org (also nicht per https ankommt) geht zu https://example.org mit der selben Ressource.
- Was auch immer bei https://www.example.org/ ankommt geht zu https://example.org/ mit der selben Ressource.
Wenn es das ist, was Du willst (sieht so aus) - dann hast Du gewonnen.
Ja, so hätte ich das gerne.
Danke für Deine Hilfe.
Und auch danke an Rolf und den Mitleser für Eure Hilfe.
GRuß, Jörg