Beiträge von kk

    Hallo,


    eben wurde die Preview auf Version 1.7.0-r2685 aktualisiert. Mit diesem Update wurde die DNS-Verwaltung auch auf OpenSUSE und CentOS (inkl. SELinux) erfolgreich durchgetestet, sowie einige Konfigurationsprobleme auf Gentoo beseitigt.


    Wir rollen diese Version nun schrittweise auf unseren eigenen Servern produktiv aus; sofern keine Probleme auftreten wird diese dann morgen (27.11.) produktiv freigegeben.


    Parallel dazu wird an den nächsten Features gearbeitet (u.a. bessere Mail-Konfiguration, E-Mail-Rundschreiben, mehrere PHP-Versionen), die dann auch in deutlich kürzeren Abständen freigeben werden.


    Viele Grüße


    -Klaus Keppler

    Hallo, kurz eine Frage wurde das Ticket #86 PHP Version Wechsel mit integrieret? Wir können es in der Preview leider nicht sehen.


    Wenn das Ticket noch offen ist, dann ist es noch offen. Der PHP-Switch wird für 1.7.0 leider nicht mehr ganz fertig. Bis dahin kann man nach wie vor nur manuell über .htaccess zwischen verschiedenen PHP-Versionen wählen, indem man serverseitig verschiedene PHP-Handler in Apache konfiguriert.

    Hallo,


    die Preview wurde nun noch mal aktualisiert (v1.7.0-r2675). Die Builds sind nun wieder für alle Plattformen verfügbar - allerdings wurde die DNS-Verwaltung für .rpm-Systeme noch nicht angepasst! (hierfür gibt es morgen noch ein Update, da wir noch nicht alle Änderungen in den Test-Zweig zusammenführen konnten).


    Auf Debian-Systemen sollte nun aber soweit alles "fertig" sein - insbesondere also auch die DNS-Verwaltung. Alle Standardfälle konnten wir fehlerfrei durchtesten (Anlegen einer Zone auf eigenen DNS-Servern; Anlegen, Bearbeiten und Löschen von Subdomains; Löschen von Domains). Alle DNS-Änderungen werden mittels dynamischer Updates sofort auf dem Master-Server ausgeführt, es gibt also keine Wartezeiten (außer 10-60 Sekunden nach dem Anlegen einer neuen Zone).


    Zudem ist nun auch die php.ini-Verwaltung für Endkunden mit enthalten (Hosting -> Webspace).


    Bitte beachten Sie beim Update, dass historische RRD-Daten (Älter als ca. 7 Tage) während des Updates zurückgesetzt werden, da es einen Berechnungsfehler beim Aufaggregieren der Daten gab (diese wurden mehrfach gezählt, was zu auffällig hohen Werten führte).


    Heute und morgen werden lediglich noch die DNS-Sachen auf CentOS, OpenSUSE und Gentoo getestet und angepasst, danach steht dem Release nichts mehr im Wege.


    Viele Grüße


    -Klaus Keppler

    Dass RC4 in Echtzeit decodiert werden kann ist derzeit reine Spekulation (wobei dies durchaus im Bereich des Möglich liegt). Wer so etwas machen möchte, benötigt aber einen erheblichen Aufwand - mehr als beispielsweise bei einem BEAST-Angriff.


    Daher noch mal: wenn Sie alle (theoretisch) knackbaren Algorithmen deaktivieren (DES, 3DES, AES, RC4), dann bleibt für die meisten Besucher gar kein Verschlüsselungsalgoithmus mehr übrig.


    Wenn Sie die Chiffres dennoch manuell einschränken möchten, modifizieren Sie einfach die entsprechenden Vorgaben in /usr/lib/liveconfig/lua/apache.lua.


    Die von uns voreingestellten Werte bieten den besten Kompromiss aus Sicherheit und Kompatibilität. Gerade bei Online-Shops geht es mehr darum, nicht versehentlich 5 von 1000 Kunden aufgrund inkompatibler Chiffres zu verlieren als theoretisch von der NSA abgeschnüffelt zu werden.

    Sehr geehrter Herr Linde,


    welcher Algorithmus letztendlich zwischen Browser und Server verwendet wird, hängt davon ab, auf welchen "kleinsten gemeinsamen Nenner" sich Server und Client einigen können. Standardmäßig versuchen beide Seiten selbstverständlich die bestmögliche Verschlüsselung zu verwenden (und da zählt RC4 sicher nicht dazu). Nur bei Endgeräten, die sonst nichts Anderes (z.B. AES) unterstützen, findet ein Fallback auf RC4 statt.


    Wenn Sie alle Blockchiffren (DES, AES etc.) gemäß PCI ausschließen und gleichzeitig RC4 verbieten, bleiben bei SSLv3/TLS1.0 übrigens keine anderen Verschlüsselungsalgorithmen mehr übrig. ;)
    Erst ab TLS 1.2 stehen mit Elliptic Curves ausreichend starke Alternativen zur Verfügung; diese sind z.B. erst mit OpenSSL 1.0 (also ab Debian 7.0) verwendbar.


    Kurzum: lassen Sie sich durch die Medien nicht scheu machen. Es handelt sich hier definitiv nicht um ein "kritisches Problem", da ja nicht nur RC4 erlaubt ist.


    Mit freundlichen Grüßen


    -Klaus Keppler

    Confixx lässt dann zumindest nicht mehr zu das neue Dateien (Webspeicher) hochgeladen bzw. erstellt werden können


    Dann können die Datenbanken ja aber trotzdem noch wachsen, oder? Was ist dann der Unterschied zu LiveConfig, außer, dass der Webspace "früher" voll ist?


    Wie gesagt: es ist nicht ganz trivial, ein Datenbank-Quota zu realisieren, weil das rein technisch eben nicht über ein Filesystem-Quota erledigt werden kann. LiveConfig zeigt die Datenbankgrößen an, kann diese aber nicht begrenzen.
    Wir haben bereits eine Lösung hierfür (vereinfacht gesagt wird beim Erreichen einer festzulegenden Datenbank-Größe das Recht für INSERT vorübergehend entfernt). Noch ist das aber nicht umgesetzt.


    Zitat

    Die Version 1.7.0 ist für openSUSE leider nicht verfügbar...


    Ja, darauf haben wir hingewiesen, weil wir größere Änderungen an unserer Build- und Testumgebung durchgeführt haben. Voraussichtlich ab heute Abend werden auch die restlichen Builds wieder bereitgestellt.


    Viele Grüße


    -Klaus Keppler

    Was für eine Antwort erwarten Sie bei Ihrer Fragestellung?


    Die Datenbankgröße kann schon rein technisch nicht zum Webspace dazugezählt werden, da Webspace-Quota per Filesystemquota realisiert wird. Die Datenbanken werden aber nicht auf einzelne Dateien pro Benutzer abgebildet (InnoDB) bzw. können nicht einfach dem User übereignet und per Quota limitiert werden (MyISAM) da es sonst gewaltige Inkonsitenzen beim Erreichen des Quotas gibt.


    Wir werden aber ein Datenbankquota in einer der nächsten Versionen realisieren - dieses muss aber (genauso wie das Mailquota) separat definiert werden.

    root@testserver:~# gpg -a --export 7AFC07EA649BE239 | sudo apt-key add -
    -bash: sudo: command not found
    gpg: [stdout]: write error: Broken pipe
    gpg: iobuf_flush failed on close: file write error


    Ähem, die Fehlermeldung ist doch recht eindeutig: "sudo" ist nicht vorhanden (was übrigens auch nicht benötigt wird, wenn Sie bereits als root angemeldet sind):


    Code
    gpg -a --export 7AFC07EA649BE239 | apt-key add -

    1.) über welche Ausführungsmethode nutzen Sie PHP - suPHP, mod_php oder FastCGI?
    2.) steht der korrekte ("gewünschte") Wert für max_execution_time in /var/www/web###/conf/php5/php.ini, oder steht da ein anderer Wert?


    Unabhängig davon: max_execution_time steuert nicht, wie lange ein PHP-Script laufen (im Sinne von: im Speicher vorhanden sein) darf, sondern wie lange es arbeiten darf. Wenn das Script ein externes Programm aufruft, das dann irgendwo hängt, wirkt sich das nicht auf max_execution_time aus.

    Ohne SSL-Zertifikat geht HTTPS rein technisch nicht. Eine Zertifikatswarnung würde dann kommen, wenn der Name im Zertifikat nicht mit dem Namen der aufgerufenen Website übereinstimmt. So lange aber kein Zertifikat angelegt ist, kann grundsätzlich kein HTTPS-Zugriff konfiguriert werden.
    Und HTTPS ohne gültiges Zertifikat macht in der Regel auch keinen Sinn, denn wenn der Besucher erst mal eine Zertifikatswarnung wegklicken muss, dann ist ohne jeden Aufwand ein Man-in-the-Middle-Angriff möglich.


    Sollte mit dem eben online gestellten Preview-Update (v1.7.0-r2661) erledigt sein.


    Viele Grüße


    -Klaus Keppler

    Aber das soeben erstellte DNS-Template können wir bei der Anlage von Domains dennoch nicht auswählen. Es ist ausgegraut und somit nicht wählbar!


    Das funktioniert ab Version 1.7.0 (derzeit als Preview verfügbar). Die Details zur DNS-Konfiguration (insbes. zu den Templates) sind im Handbuch in Kapitel 4.15 (Seite 80) beschrieben.


    Die DNS-Verwaltung in der aktuellen Preview ist aber noch etwas eingeschränkt (da werden aktuell nur NS- und A-Records angelegt); MX kommt mit dem Update heute Nachmittag.


    Viele Grüße


    -Klaus Keppelr

    Mir geht die Entwicklung derzeit viel zu schleppend voran. Das muss sich endlich ändern..


    Auch wenn's ganz klein geschrieben ist :) möchte ich doch kurz was dazu anmerken: auf unserer Seite tut sich ziemlich viel (was man vermutlich nur hier im Büro mitbekommt, da sich noch nicht alles in der Preview wiederspiegelt). Einige Funktionen bringen einen großen peripheren Aufwand mit sich (Anpassung der Tests, Einbindung neuer Testplattformen, weitreichende Änderungen im LiveConfig-Kern etc.). Sobald der aktuelle "Brocken" aber geschafft ist, geloben wir wieder Updates in kürzeren Intervallen bereitzustellen.

    Welche Linux-Distribution & -Version setzen Sie ein?


    Zitat

    Antwort des Servers: 451 4.7.1 Service unavailable - try again later


    Was steht unmittelbar nach so einer Fehlermeldung im Postfix-Log? (meist /var/log/mail.log)

    Sie können in LiveConfig FTPS (via TLS) aktivieren, sobald ein SSL-Zertifikat konfiguriert ist.
    SFTP kann jeder Benutzer mit SSH-Zugriff nutzen; wer das weiter einschränken möchte, müsste das ggf. in /etc/ssh/sshd_config konfigurieren.

    Can't get group quota for 'aci1000' (path '/var/www/xxxx'): No such process


    Die Fehlermeldung selbst stammt vom Betriebssystem und nicht von LiveConfig, daher ist die leider recht kryptisch. Übersetzt heißt das so viel wie "Group Quota ist nicht aktiviert".
    (Führen Sie einfach mal den Befehl "repquota -ag" aus - vermutlich bekommen Sie da keine Werte angezeigt)


    Zitat

    Außerdem zeigt mit LC nicht an, das mod-suPHP installiert ist. Ist ein rotes X, obwohl es drauf ist.
    Ich nutze Ubuntu 64 Bit 12.04


    Bitte starten Sie LiveConfig neu, nachdem Sie zusätzliche Apache-Module installiert oder deinstalliert haben.


    Viele Grüße


    -Klaus Keppler