Beiträge von aziegler

    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.


    laut meinen Test mittels ssllabs.com und dem Firefox-Plugin Calomel unterstützt die aktuelle Konfiguration aber weder im kompatiblen noch im PCI-konformen Modus Perfect Forward Secrecy aka PFS durch Key Exchange mit DH oder ECDH - Betriebssystem Debian 7, Apache 2.2.22


    Ist geplant das in naher Zukunft anzupassen oder muss man selbst tätig werden?


    Beispielhaft ist meines Erachtens die SSLCipher-Konfiguration auf facebook.com und mail.google.com - um nur zwei große Beispiele zu nennen.


    Nachtrag:
    LiveConfig selbst nutzt ECDHE - wenn auch nicht mit TLS 1.2 / AES GCM - aber immerhin besser als das, was für Apache konfiguriert wird.

    Ich nehme diesen Feature-Request aber ins den Issue-Tracker mit auf (sollte spätestens morgen mit auftauchen), damit bleibt das ganze auf dem Radar.


    Wobei dort ja auch Tickets von 2012 noch sind - evtl. kann man die Kunden in einer Art Priorisierungs-Umfrage mit einbeziehen und gegebenenfalls auch einmal Features vorerst streichen, damit die Ticketliste nicht immer nur länger wird...


    Bei den Kontakten wäre IMHO eine Übersicht, ähnlich der Kunden oder der Benutzer, recht vorteilhaft. Das würde dann "neuer Kontakt", "Kontakt editieren" sowie "Kontakt löschen" erleichtern - genau wie eine Detail-Anzeige, bei welchen Kunden bzw. Benutzern dieser Kontakt nun genau im Einsatz ist.


    Für 2014 hoffe ich eher auf Bugfixes statt auf neue Features. Wenn ich mir die Ticket-Liste unter liveconfig.com/dev so anschaue, wären die Bugfixes wichtiger als das nächste neue Feature mit u.U. noch mehr Bugs.


    Dem schließe ich mich an :)


    Bei der Migration der DB´s aus confixx, wurden auf Web´s, wo mehrere DB´s angelegt waren, auch die Benutzer übernommen. Also die gleichen, meine ich... :cool: (s. Anhang):)


    Das ist nichts neues und wurde hier auch schon angesprochen.
    Der Import aus Confixx nutzt die API - mit dieser geht es ja, nur in der GUI gibt es die Funktion nicht.
    Der erste Schritt wäre also, dass jemand ein triviales shell-php schreibt, mit dem man manuell angelegte DBs in LC einfügt via API.
    Der zweite Schritt wäre, dass es in der GUI direkt möglich wird.


    Ich nutze den MySQLDumper und der kann sich nur mit einem Benutzernamen einloggen. Für eine 2.-X. DB, die ich anlege, müßte ich jetzt so viele MySQLDumper - Installationen auf den Server setzen, wie Datenbanken vorhanden sind.


    Das stimmt so doch nicht ganz? man muss doch nur mehrere Konfigurations-Sets in einer Installation anlegen?
    (Trotzdem unnötiger Zusatzaufwand natürlich...)

    gut - wäre schön, wenn das dokumentiert wird, was in liveconfig-meta enthalten ist an Konfigurations-Sachen (inkl. changelog)


    wir z.B. nutzen das Paket nämlich nicht, da wir unnötige Paketinstallationen vermeiden wollen und z.B. suphp auf keinem Server benötigen und auf einigen nichts mail-bezogenes

    Hallo,


    wir haben das "Problem" auch gehabt.
    ClamAV-Milter setzt in der Standard-Einstellungen die E-Mails, die als Viren erkannt werden, nur auf den Status "hold" (erkennbar am Ausrufezeichen hinter der ID in mailq). Löschen kann man diese durch "postsuper -d ALL hold".
    Eine dauerhaftere Lösung ist jedoch, die Mails direkt abzuweisen. Das lässt sich relativ einfach bewerkstelligen, evtl. wäre das sogar sinnvoll als LC-Default-Setting:

    Zitat

    sed -i "s|Quarantine|Reject|" /etc/clamav/clamav-milter.conf
    /etc/init.d/clamav-milter restart


    Grüße

    Vielen Dank für die Implementierung er php.ini-Verwaltung auf Vertragsebene.
    Zwei Wünsche tauchen da aber nun schon auf ;)


    1) Man sollte als Administrator nicht nur "pro Vertrag" einzelne Einstellungen erlauben können, sondern auch pro Angebot bzw. Reseller-Vertrag.
    Ziel: Nicht jeder Reseller soll z.B. open_basedir ändern können, aber für einige System-Apps bräuchte man es :-/
    1b) alternativ könnte man das wie bei Confixx lösen, dass der Admin jegliche php.ini-Einstellungen eines Endkunden-Vertrages ändern kann, obwohl dessen Reseller dazu keine Rechte hat


    2) Man sollte als Administrator Auswahl-Werte angeben können, also z.B. für den Parameter "zend_extension" mehrere Werte mit kurzem Text dazu, sodass der Kunde hier z.B. nicht selbst den Pfad zu einer Extension kennen muss, sondern nur "IonCube für PHP 5.3" oder "ZendGuard für PHP 5.4" auswählen muss - ob man dies dann noch automatisch je nach im web aktiver PHP-Version machen kann? Luxus wäre das ;)

    Wir würden dieses Feature auch sehr begrüßen, um eine Kompatibilität zu Confixx zu haben und innerhalb eines webs nicht mit mehreren Benutzernamen hantieren zu müssen um mehr als eine DB nutzen zu können :(

    +1
    Greylisting Standardeinstellung Aktiviert/Deaktiviert pro Host/Reseller


    Momentan nutzt Greylisting ja kaum, wenn Kunden manuell E-Mail Adressen anlegen und diese Funktion manuell aktivieren müssen.


    oh ja, das wäre ein wichtiges kleines Detail...
    das gleiche gilt für die "Webanmeldung"!


    Hat vielleicht jemand die manuelle Variante parat, wie man das via sqlite beides für alle Postfächer aktivieren kann?

    Zusätzlich dazu planen wir aber auch die vorgeschlagene Rechteverwaltung einzubauen somit kann der "Oberadmin" (der der den LiveConfig-Server verwaltet) entscheiden welche Apps er generell bereitstellen will und die Reseller können ihren Kunden wiederum daraus eine Auswahl bereitstellen.


    Ist dies immer noch geplant? Dann könnte man es vielleicht in Redmine hinterlegen :)