Beiträge von antondollmaier

  • 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

  • Fragen zur API

    Zitat von Steinweber

    Hat man einen eigenen Datenstand, kann man jede API anbinden. Verwendet man aber LC und fügt dort die Funktionen ein, hat man keinen "eigenen" Datenbestand und man könnte nicht einfach wechseln.


    Warum implementierst du den letzten Teil deines Verwaltungs-Systems, nämlich die tatsächliche Konfiguration auf den Servern, nicht auch noch?


    Dovecot mit MySQL-Backend ist ziemlich easy. Einzig beim Apache hätte ich persönlich Bauchschmerzen bei der Implementierung (da einige Abhängigkeiten, vgl. System-Accounts, php.ini, FastCGI, ...).


    Ergebnis: komplette Unabhängigkeit von LiveConfig oder sonstigen Panels.

  • Fragen zur API

    Sehe ich teilweise auch so. Kunden neu anlegen und löschen sollte vollständig via API realisierbar sein.


    Ansonsten gibt es ja die Möglichkeit, die Rechnungen etc direkt im LiveConfig zu integrieren. Da mehrere Hosting-Accounts ja eh dem gleichen Kunden zugeordnet werden, hat jeder _Kunde_ auch eigentlich nur einen Login.

  • PHP 5.4.45, 5.5.29, 5.6.13 und 7.0.0rc2

    Zitat von Nosxxx

    Kommen denn auch 32bit Packete für Jessie =) ?


    Warum sollte man heute noch ein OS als 32Bit nutzen?


    Alle CPUs sind schon seit knapp 10 Jahren 64bit-tauglich. Auch unterhalb von 4GB gibt es eigentlich keinen Grund, 32Bit einzusetzen - erst Recht auf skalierbaren Plattformen, wo jederzeit auf >3,3GB hochskaliert werden könnte.



    Oder hab ich einen riesigen Denkfehler und es gibt tatsächlich Gründe "pro 32Bit"?

  • Länge von Datenbanknamen/benutzern

    Zitat von HBO

    Nun bestehen hier Datenbanknamen und Benutzer die mehr als 16 Zeichen lang sind.



    Nein:


    Zitat von https://dev.mysql.com/doc/refman/5.6/en/user-names.html

    MySQL user names can be up to 16 characters long. Operating system user names may be of a different maximum length. For example, Unix user names typically are limited to eight characters.
    Warning


    The limit on MySQL user name length is hard-coded in MySQL servers and clients, and trying to circumvent it by modifying the definitions of the tables in the mysql database does not work.


    *10z*

  • Dist-Upgrade von Squeeze über Wheezy auf Jessy

    Zitat von aziegler

    1) Natürlich gibt es 5.3 noch unter Jessie.


    nicht über das Liveconfig-PHP-Repository.


    Zitat

    alles was auf Standard steht (5.4) ist danach der neue Standard 5.6 und was explizit vorher schon auf 5.6 war muss nach dem Upgrade auf Jessie meist manuell auf Standard umgestellt werden.


    Hier würde es nützen, wenn LC beim Start die Domains auf fehlerhafte / fehlende FastCGI-Konfiguration prüft und das im Fehlerfall loggt ("Domain example.com is using PHP 5.6, which is not present ATM") sowie die Domain dann auf den Default zurücksetzt.


    Gebe zu, nicht perfekt: bei "temporär nicht vorhandener PHP-Version" wären dann alle (Kunden-)Einstellungen dazu weg. Sowas darf aber eigentlich auch nicht auftreten.

  • Fragen zur API

    Zitat

    Meine aktuellste Frage betrifft HostingMailboxEdit. Dort kann man keinen Parameter "forward" angeben. Fehlt dieser oder ist er nur nicht in der Doku enthalten?


    Schau in die WSDL. Was dort nicht enthalten ist, geht definitiv - schon Clientseitig - nicht.



    Zitat

    Je mehr ich mit der API arbeite, desto mehr habe ich den Eindruck, dass die API nicht dazu gedacht ist, die Verwaltung über ein anderes System zu gestalten, sondern lediglich die einmalige Erstellung von Kunden/Reseller ermöglichen soll.


    sehe ich auch so.