Beiträge von kk

  • SSL Cipher

    Zitat von aziegler

    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


    Welchen Cipher genau vermissen Sie?
    Der Befehl "openssl ciphers <Liste>" liefert eine vollständige Liste aller unterstützten Algorithmen; die Cipher-List die LiveConfig hierbei im Apache konfiguriert steht in /etc/apache2/sites-available/default".
    In der aktuellen Einstellung (!aNULL:!eNULL:!EXPORT:!ADH:!DES:!DSS:!LOW:!SSLv2:RC4-SHA:RC4-MD5:ALL) erhalte ich auch einen ganzen Schwung PFS-fähiger DH-Algorithmen.
    Ich tippe also mal darauf, dass in diesem Fall einfach keine DH-Parameter generiert wurden bzw. konfiguriert sind - das werden wir uns gleich noch mal genauer anschauen. (#131)


    Zitat

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


    Die o.g. Cipher-Liste ist "future-proof", da nur die unsicheren Ciphers deaktiviert werden. Der Rest ist Sache von OpenSSL und dem Client-Handshake.


    Zitat

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


    Die verwenden leider kein LiveConfig zur Serverkonfiguration. ;)
    Ich kenne mich zufällig etwas mit der SSL-Konfiguration hinter den Google-Services aus - das ist alles andere als trivial (die machen u.a. SNI mit Fallback auf Multi-Domain-Zertifikate...).


    Zitat

    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.


    LC verwendet OpenSSL 1.0.1 und unterstützt somit auch TLS 1.2. In unserer internen Cipher-Konfiguration räumen wir ECDHE eine höhere Priorität ein als AES-GCM, Letzter wird aber auch unterstützt (mit ssllabs getestet).

  • 2. Benutzer bei geschützten Verzeichnissen

    Hallo,


    diese Benutzer werden in der Datei ~/conf/.htpasswd angelegt (z.B. /var/www/webXY/conf/.htpasswd). Wenn Sie einen Benutzer hinzufügen oder das Passwort ändern, sollte diese Änderung unmittelbar auch in dieser Datei erfolgen.
    Falls das nicht geschieht, dann stimmt etwas mit dem LiveConfig-Prozess nicht, der dafür zuständig ist - in diesem Fall prüfen Sie bitte, ob es Fehlermeldungen in /var/log/liveconfig/liveconfig.log gibt und starten LiveConfig am besten mal neu.

  • Ablauf-Schwierigkeiten SOAP-API

    Zitat von antondollmaier

    Ein einziges Mini-Improvement habe ich für die Installation des Repositories:


    Code
    sudo wget -O/etc/apt/sources.list.d/liveconfig.list http://repo.liveconfig.com/debian-test/liveconfig.list


    (oder gab es einen Grund für die Aufteilung auf 2 Befehle (cd; sudo wget)?)


    Ist etwas übersichtlicher in zwei Zeilen; außerdem ist mit dem "cd" sichergestellt, dass man keinen Tippfehler im Pfad hat.


    Zitat

    - beim Anlegen des Vertrages wird die Angabe der Server-Namen gefordert, obwohl überhaupt nur einer (Standard-Lizenz) vorhanden ist. Macht jetzt nicht soo viel aus, da zukünftig ja expandiert werden könnte bzw. es eh in der API so dokumentiert ist. Sinn macht es aber trotzdem bei einem einzigen vorhandenem Server nur wenig :)


    Die API ist an sich auf das Maximum - also den Multi-User-Betrieb - ausgelegt. Im Falle einer Standardlizenz den Servernamen wegzulassen wäre eine sinnvolle Optimierung.


    Zitat

    - Im Angebot ist "FTP: nein" definiert. Nach dem Anlegen des Vertrages per SOAP steht aber in der GUI "FTP-Zugänge: 1 (max. 0)" mit einem grünen Balken. Der Auslastungsbalken bei Datenbanken "1 (von max 1)" ist hingegen rot gefärbt.
    - Auch wird trotz "FTP: nein" der Systembenutzer so angelegt (muss für den Apachen / das Linux logischerweise eh), dass sich der Kunde, wenn ihm das Passwort bekannt wäre, per FTP anmelden könnte (das soll widerrum nicht). Habe ich nun dahingehend gelöst, dass beim Anlegen des Vertrages ein Zufallspasswort gesetzt wird. Per GUI ist die Passwort-Änderung eh nicht möglich, das passt letztendlich doch irgendwie.


    Bei Webspace ist technisch bedingt immer ein Systemaccount (und somit implizit ein "FTP-User" im weitesten Sinne) erforderlich. Ich verstehe aber Ihr Einsatzszenario; ich denke es dürfte keine große Sache sein, in so einem Fall einen gesperrten FTP-Account einzurichten. Wird aufgenommen.[/quote]


    Zitat

    - Dadurch, dass der Kunde ohne LiveConfig-Benutzer-Account angelegt wird, wird die Steuerung des Accounts deutlich schwieriger. Es lässt sich im Nachhinein im LiveConfig für diesen Kunden unter Kunden -> Details -> "Übersicht" kein neuer Benutzer anlegen, so dass auch die Verwaltung der Domains/Datenbanken nicht mehr möglich ist. Der Button "Verbindung starten" fehlt ohne Benutzer ja komplett. Wurde dahingehend gelöst, dass zusätzlich noch "UserAdd" mit einem Random-Passwort aufgerufen wird.


    Das ist auch das normale Vorgehen: erst CustomerAdd(), dann UserAdd(). Accounts ohne LiveConfig-User sind bislang nicht vorgesehen.


    Zitat

    - Nach Ablauf der Demo-Phase kann zwar per SOAP-API der Hosting-Vertrag gelöscht werden, aber der Kunde nicht. Auch die Kontakte verbleiben als Leiche im System. Der Kunde könnte sich also noch weiterhin anmelden, sieht nur keine Daten mehr. Löschung müsste also per GUI manuell abgeschlossen werden.


    CustomerDelete() und ConactDelete() stehen bereits auf der ToDo-Liste. Diese setzen aber noch den Abschluß der Kontaktverwaltung vorraus (LC muss schließlich vor dem Löschen eines Kontaktes erst noch prüfen, ob dieser noch in irgendeinem Objekt (z.B. Vertrag oder Kunde) verwendet wird).


    Zitat

    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.


    S.o. - genau das befindet sich derzeit in Entwicklung (zum Thema "Kontakte verwalten" gibt es schon einige Wünsche hier im Forum).


    Viele Grüße


    -Klaus Keppler

  • Ablauf-Schwierigkeiten SOAP-API

    Zitat von bfal

    Es ist somit ein würdiger Confixx Nachfolger. Denn dort habe ich auch selten erlebt das es eine Antwort gab :D


    Nun mal langsam... wir können sicher nicht jeden einzelnen Forumsbeitrag individuell kommentieren; wir lesen aber jeden Beitrag, und alle offenen Themen sind bei uns intern auch markiert. Dringende Anliegen werden jederzeit über den Support (support@liveconfig.com bzw. Telefon) bearbeitet. Das müssten Sie eigentlich auch schon mitbekommen haben.

  • BoxBilling

    Moin,


    für solche Produkte stellt LiveConfig eine SOAP-API zur Verfügung. Wir selber halten uns aus der Entwicklung solcher Plugins heraus und konzentrieren uns lieber auf LiveConfig. Wer mag, kann gerne ein BoxBilling-Plugin entwickeln; für Fragen während der Entwicklung und "Promotion" des fertigen Plugins gibt's ja dieses Forum. :)


    Viele Grüße


    -Klaus Keppler

  • mysql: eigener datenbankserver - keine dienste gefunden

    In der o.g. Konfiguration (liveconfig.conf) ist lediglich eingestellt, dass LiveConfig selbst auf eine (externe?) MySQL-Datenbank zugreift.


    Damit Sie in Webspaces MySQL nutzen können (Datenbanken/Benutzer/Passwörter anlegen/verwalten), müssen Sie entweder
    - lokal einen MySQL-Server installieren (taucht dann unter "Serververwaltung" -> "Datenbanken" auf); oder
    - LiveConfig mit einer Business-Lizenz aktivieren, sowie auf dem "externen" MySQL-Server einen LiveConfig-Client mit einer Standard-Lizenz aktivieren und letzteren am LiveConfig-"Hauptserver" (Businesslizenz) anmelden lassen.


    Viele Grüße


    -Klaus Keppler

  • Datenbank + Benutzer

    Ja, Feiertage sind vorbei, wir sind hier im Büro auch wieder vollzählig (sofern die "Hacker-Pest" hier nicht für weitere Ausfälle sorgt ;)).
    Beim nächsten Update (1.7.1/1.7.2) wird diese Funktion leider noch nicht mit drin sein können, dafür sind zu viele Änderungen an der Oberfläche und DB-Struktur notwendig (nicht daß das sooo irre aufwendig wäre, aber es stecken aktuell noch zu viele andere Sachen in der Pipeline). 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.


    Gaaanz vorsichtig würde ich als Zeitpunkt für dieses Feature mal etwa März 2014 (in ca. 8 Wochen) in Aussicht stellen.

  • Umstellung auf eigene DNS-Verwaltung

    Per SQL ist das leider nicht möglich, da bei der Umstellung eine ganze Menge Datenbankeinträge (pro Domain) erzeugt werden müssen.
    Wäre jedoch über die SOAP-API machbar (HostingDomainEdit() - kommt in den nächsten Wochen)


    Viele Grüße


    -Klaus Keppler

  • Subdomainberechnung failed

    Fehler wurde mit v1.7.1-r2714 behoben (im betroffenen SQL wurden nur unterschiedliche Subdomain-Hostnamen berücksichtigt). Der "leere" Hostname sowie "www" werden übrigens nicht mitgezählt (das ist so beabsichtigt).

  • Bei Confixx-Import: Invalid mailbox quota

    Laut Doku darf das Feld quota nur aus bis zu 6 Ziffern bestehen - der zu importierende Wert hat aber 7 Stellen (1048576 - entspricht 1024 GB). Bitte prüfen Sie mal im Confixx, welcher Wert dort als Postfach-Quota hinterlegt ist und setzen diesen wahlweise herunter (z.B. auf "nur" 100 GB) oder auf "unbegrenzt".

  • Bei Confixx-Import: Invalid mailbox quota

    Hallo,


    löschen Sie im LiveConfig den angelegten Vertrag (web0) einfach und importieren diesen danach noch einmal. Rufen Sie das Importscript dabei aber mit dem Parameter "--fixmailquota" auf.


    Ich tippe darauf, dass der als res0 importierte Resellervertrag das gewünschte Postfachquota nicht erlaubt - mit "--fixquota" passt LiveConfig das ggf. an.


    Viele Grüße


    -Klaus Keppler

  • Ankündigung: Änderungen im AppInstaller

    Hallo,


    wir haben ja schon vor längerer Zeit Änderungen im AppInstaller versprochen, damit man z.B. sein eigenes Repository nutzen kann (um z.B. eigene Apps anbieten zu können). In anderen Threads wurde zudem vorgeschlagen, die Pflege des App-Repos zu entkoppeln oder "offener" zu gestalten.


    Wir möchten das nun als Nächstes in Angriff nehmen. Unsere Idee wäre, das komplette AppInstaller-Repository bei GitHub zu veröffentlichen und die Update-URL (also die Adresse, bei der LiveConfig nach Änderungen im Repo fragt) konfigurierbar zu machen.
    Auf diese Art schlagen wir mehrere Fliegen mit einer Klappe: wer möchte, kann sich dann einfach "unser" Repo klonen und beliebig anpassen. Über Pull-Requests wiederum können Änderungswünsche schnell und kurzfristig berücksichtigt werden. Nicht zuletzt können wir auch weiteren "eingefleischten" LC-Usern Schreibrechte für das Repo geben.
    (zur Qualitätssicherung würden wir in diesem Fall aber für jede einzelne App eine Testinstallation durch unser Jenkins-CI durchführen lassen).


    Fragen/Meinungen/Anregungen?


    Mit der Umsetzung werden wir voraussichtlich Mitte Februar starten (bis dahin sind noch viele andere Punkte zu erledigen).


    Viele Grüße


    -Klaus Keppler