Beiträge von antondollmaier

  • App Installation in Verzeichnis

    Zitat von Mogwais

    Das heisst trotzdem alles nochmal anzufassen.


    yep.


    Zitat

    Warum dann nicht gleich richtig?


    Weil da noch Abhängigkeiten berücksichtigt werden müssen, die - zumindest so spontan auf die Schnelle - nur schwer lösbar sein dürften:


    - Wordpress nach "/" installieren -> passt.
    - Magento nach "/shop" installieren -> ok.


    Allerdings muss dann noch mod_rewrite angepasst werden, damit es keine Probleme gibt:


    - in der .htaccess von Magento muss die RewriteBase entsprechend dem Setup gesetzt werden - via Installer noch lösbar.
    - die .htaccess von Wordpress muss alle URLs, die mit "^shop" beginnen, von der weiteren Verarbeitung ausschließen (RewriteRule ^shop - [L]). Das wird schon eher interessant, immerhin sollte der App-Installer von Magento ja keine Zeilen löschen...


    Von zusätzlichen Problemen / Anpassungen, um das ganze dann auch noch mit Nginx hinzubiegen, red ich noch gar nicht (schon mal einen Shopware-Shop in ein Unterverzeichnis gepackt? Mir reichte die normale Installation schon).


    Richtig lustig wird es dann, wenn da noch mehr Anwendungen parallel genutzt werden (WP auf /, OC auf /cloud, Shopware auf /shop, eventuell noch ne Gallery oder sonstwas) - oder diese dann auch noch auf mehrere Unterordner-Hierarchien aufgeteilt werden ("/intern/cloud", ...).



    Werden die mod_rewrite-Anpassungen nicht gemacht, gibt es sicher Probleme - die Ottonormal nicht auf die schnelle finden kann.


    Also lieber auf (Sub-)Domains aufteilen und man hat Ruhe.



    Oder bin ich hier komplett auf dem falschen Dampfer und habe was übersehen?


    Wie macht es denn die Confixx Special Edition von Cyberwebhosting?

  • App Installation in Verzeichnis

    Zitat von ManDal

    Also wertlos ist es definitiv nicht, für den 0815 Kunden reicht so etwas vollkommen und alle anderen installieren sich ihre "App" selber und nicht über den installer...


    Full ACK.


    Außerdem:


    apps/wp
    apps/magento
    htdocs/www -> apps/wp
    htdocs/www/shop -> apps/magento


    Installation der Apps auf Dummy-Subdomains, Docrot der Haupt-Domain auf "www". .htaccess-Anpassungen bzgl. Subdomain nicht vergessen. Sollte klappen.

  • htaccess Datei

    Zitat

    Mittels "a2enconf php5-cgi" kann dies natürlich geändert werden, da PHP als FastCGI-Variante derzeit aber einwandfrei läuft stelle ich mir die Frage, ob dies überhaupt aktiviert werden muss?


    nein, muss - und darf - nicht.

  • Statistik per Domain, nicht per Vertrag

    Zitat von mhagge

    Einzelne Webs aka einzelne Logfiles würden das Problem denke ich insofern nicht lösen, als dass ich damit in das Problem der zu vielen offenen Dateien für den Apachen rennen würde - da ist ein einziges "großes" Logfile durchaus sympathisch


    Das ist eine Lösung.


    Alternativ würde es auch reichen, das LogFormat anzupassen, damit der tatsächlich übertragene Hostname mit in der Log-Zeile steht.


    AWStats könnte diesen Wert - mit geänderter LogFormat-Anweisung - ebenfalls berücksichtigen.


    Der Verwaltungs- bzw. Umsetzungsaufwand in LiveConfig ist aber deutlich höher als bei nur einer AWStats-Config je Vertrag.

  • Statistik per Domain, nicht per Vertrag

    Empfehlung: Piwik installieren und das nutzen.


    Bessere Statistiken (ja, kein tatsächliches Access Log, es fallen also durchaus Requests runter), schönere GUI, mehr Details.


    Hauptgrund: die Daten liegen in einer MySQL-DB und können daher schön migriert werden. Das ist bei AWStats-Daten schwerer.


    Außerdem kann für jede Webseite eine einzelne Site angelegt und so die Zugriffe getrennt geloggt werden.

  • Test mit ACME

    Zitat von kk

    Diese Adresse wird per Alias direkt in die Apache-Konfiguration geschrieben, so dass LiveConfig nicht im Webspace-Verzeichnis herumpfuschen muss.


    geil.


    Zitat

    Künftig ist auch eine DNS-Validierung geplant, Let's Encrypt unterstützt die aber noch nicht (soll Anfang kommenden Jahres kommen).


    Finde ich - mit LiveConfig - schlechter, da ja der Nameserver über LiveConfig benötigt wird.

  • Installation

    Zitat von andreas

    Bleibt mir also nichts weiter übrig als den LE-Client zu installieren.


    oder 7€ mehr in die Hand zu nehmen - für "SSL-Certs flat" ein guter Preis.


    Zitat

    Generell müsste das doch irgendwie in Verbindung mit LC funktionieren?


    Ja, mit der Webroot-methode sollte die Validierung klappen. Die Zertifikate müssen dann halt manuell ins LiveConfig integriert werden.

  • Reset DNS

    Zitat von kk

    Sie kennen den. ;)


    ah. :)


    Zitat

    Um dessen Ehre etwas zu retten: ich vermute, dass es am PowerDNS liegt, der dort zum Einsatz kommt. 255 Zeichen klingt für mich nach der typischen "varchar"-Grenze, und ein Datenbankschema mit zig Millionen von Einträge auf "text" umstellen ist meistens keine gute Idee...


    oh, nett. Wusste nicht, dass dort PowerDNS zum Einsatz kommt.


    Zitat

    Wir werden uns in Kürze auch intensiver mit PowerDNS beschäftigen.


    Halte ich - insbesondere wegen DNSSEC - für sehr sinnvoll.


    Bei Fragen einfach melden :)

  • Reset DNS

    Zitat von marinal

    Und ja, sie haben mit den 255 Zeichen recht ... ich war einen Moment sprachlos ... Änderungen sind hier nicht geplant.


    Oh Mann.


    Da wäre jetzt gut zu wissen, wer das ist, um zukünftig einen großen Bogen drumrum machen zu können :)

  • Transparenter Proxy für HTTPS-Verbindungen

    Zitat von WebOscar

    antondollmaier: Hasse rääsch! Ich hatte mich mit der Problematik schon einmal befasst und erfolgreich verdrängt, dass der Host erst dann aufgelöst wird, wenn eine HTTPS-Verbindung hergestellt wurde. Bis dahin gibt es das Standard-SSL-Zertifikat und danach erst kann mit SNI das richtige, passende Zertifikat ausgeliefert werden.


    Mit SNI sendet der Client im TLS-Handshake den Hostname mit, für den er eine TLS-Verbindung aufbauen will - somit kann der Server (soweit der die SNI-Erweiterung unterstützt) _direkt_ das richtige SSL-Zertifikat selektieren und verwenden.


    Das "Standard-Zertifikat" kommt nur noch zum Einsatz, wenn ein Client kein SNI kann:


    > https://sni.velox.ch/




    Zitat

    Darum habe ich erstmal ein Wildcard-Zertifikat auf dem entsprechenden Server und wenn ein Kunde eine eigene Domain wünscht, dann muss er halt eine eigene IP bekommen und für das passende Zertifikat halt selbst bezahlen.


    Genau.


    Kunden haben zwei Optionen:


    - SNI nutzen
    - eigene IP zusätzlich bezahlen


    Beides ist ja vom SSL-Zertifikat an sich unabhängig.



    Zitat

    In meinem wirren Programmierer-Hirn habe ich eine unscharfe Idee, die ich aber aufgrund der Auftragslage in diesem Leben wohl nicht mehr umsetzen kann:


    Ein Deamon, der HTTPS Anfragen entgegennimmt und cached. Anhand einer Liste interner IPs wird diese Anfrage nacheinander an alle internen IPs gesendet und der Handshake wird getestet. Passt das ausgelieferte Zertifikat, sorgt der Deamon fur ein Forwarding (via iptables oder so) des Clients zum richtigen Zielhost für die Dauer der Session...


    Ok, das ist ... spooky.


    Aber wie gesagt: wird nicht klappen. Woher weiß dein "Proxy" denn, nur anhand der Client-IP(!), was denn nun das "richtige" Zertifikat auf der "richtigen" Backend-IP sein soll?


    Ich bin mir sicher: wenn das Problem gelöst wäre, wäre kein (großer...) Bedarf für SNI gewesen.

  • Berechtigungsfehler bei FastCGI

    Mit ProFTPd werden die Rechte per Default korrekt gesetzt:


    Code
    # Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
Umask                           022  022
# Normally, we want files to be overwriteable.
AllowOverwrite                  on


    Umask 022 ergibt chmod 0755.

  • Berechtigungsfehler bei FastCGI

    Zitat von leepfrog

    ./htdocs/ hat web1:www-data
    sämtliche Unterordner (sowie /blog/ als auch die Unterordner von WP darunter) haben aber web1:web1


    was so auch korrekt ist.


    Zitat

    Da stimmt wohl etwas nicht bei der Gruppenzuweisung beim Upload durch den ProFTPd oder es fehlt Gruppenmitgliedschaft für www-data in web1.


    Nach einem manuellen chgrp -R www-data ./htdocs/ funktioniert es - aber das kann ja nicht die Lösung sein - auch ein Kunde kann ja mal Unterordner hochladen.


    Ordner-Rechte prüfen. Unterhalb von htdocs darf nicht 0750 verwendet werden, sondern es muss auf 0755 gesetzt werden - sonst darf der Apache ja nicht in den Ordner.

  • Transparenter Proxy für HTTPS-Verbindungen

    Ergänzung:


    Einzige Abhilfe, wenn mehrere Domains abgedeckt werden soll: ein Zertifikat erwerben, das alle Domains beinhaltet (Multi-Domain-Zertifikat).


    Ist natürlich nur möglich, wenn es finanzierbar ist (die kosten mehr als Single-Domain-Zertifikate) und vom Datenschutz her machbar ist (da die anderen abgedeckten Domains im Zertifikat aufgelistet werden müssen).

  • Transparenter Proxy für HTTPS-Verbindungen

    Zitat

    Hat vielleich jemand eine Idee?



    Ja: lass es. Man kann so keine IPs "sparen", es geht schlichtweg nicht.


    Kurz: der TLS-Handshake mit Zertifikats-Austausch erfolgt bei Clients, die kein SNI können, auf dem Server nur anhand der Server-IP, bevor der Server überhaupt eine Unterscheidung auf den HTTP-Hostname durchführen kann.



    Länger:


    Ohne SNI wird der erste vHost (sowohl Nginx als auch Apache) selektiert, dessen IP/Port-Kombination zur Anfrage passt (bei nginx: "listen ... default").


    Aus diesem vHost wird dann das SSL-Zertifikat genommen und dem Client präsentiert, der dann daraufhin den TLS-Handshake durchführt.


    Zu diesem Zeitpunkt ist dem Webserver über die tatsächlich gewählte Domain ("ServerName") nichts bekannt, die Auswahl erfolgt wirklich nur anhand von Server-IP/Port. Erst nach dem erfolgreichen TLS-Handshake sendet der non-SNI-Browser dann den HTTP-Request, der im "Host:"-Header den letztendlichen vHost/Server-Name enthält. Dessen SSL-Konfiguration ist dann aber hinfällig, da ja die Verbindung bereits verschlüsselt wurde.


    Somit kann - ob nun "Proxy" oder nicht - nur ein einziges SSL-Zertifikat je IP/Port überhaupt an Clients ausgeliefert werden, die kein SNI können.


    => es wird auch weiterhin für jedes SSL-Zertifikat eine eigene IP benötigt, sobald SNI nicht eingesetzt werden kann.



    Weitere Details siehe Wikipedia:


    - OSI-Layer:
    - TCP
    - TLS
    - HTTP
    - RFC 3546