Beiträge von kk

  • LiveConfig v1.8.2 freigegeben

    Zitat von WebService4U

    LiveConfig 1.8.2-3447 starting...
    Database driver loaded: MySQL (5.5.41)
    License is valid.
    Can't open any socket for address (null), port 8443


    Auf welcher Distribution tritt das auf?
    Wenn Sie "/etc/init.d/liveconfig stop" ausführen - wird LiveConfig dann gestoppt? Wenn nicht: welche PID steht in /var/run/liveconfig.pid? Entspricht die dem "Hauptprozess" von LiveConfig (siehe "ps auwfx | grep liveconfig)


    Hintergrund: wir halten uns eigentlich an die jeweiligen Distributions-Richtlinien was die Prozessverwaltung betrifft. Bei Debian/Ubuntu heißt das: den "start-stop-daemon" verwenden. Bei manchen Konfigurationen arbeitet der jedoch anscheinend nicht zuverlässig (hier bei uns läuft das alles rund - auf den Test-VMs wird zig mal am Tag so LiveConfig korrekt beendet und gestartet).


    Viele Grüße


    -Klaus Keppler

  • LiveConfig v1.8.2 freigegeben

    OK, gefunden... Bei arithmetischen Operationen mit mindestens einem UNSIGNED-Wert ist das Ergebnis in MySQL immer UNSIGNED (siehe Handbuch). Seit Version 5.5.5 läuft MySQL standardmäßig im "strict mode". Dort führt ein mögliches negatives Ergebnis (wie hier: x * -1) bei gleichzeitigem UNSIGNED-Attribut zu einem Fehler.
    Bei uns ist das nicht aufgetaucht, weil unsere Entwicklungsumgebung im Büro noch mit MySQL 5.0.x läuft (Debian 6.0.10 LTS). Auf den virtuellen Servern testen wir mittels Jenkins/Selenium das MySQL-Backend bislang auch nur auf einer Debian 6 VM, alle anderen VMs (Debian 7, CentOS 5/6/7, Ubuntu 12/14, OpenSUSE 13) laufen mit dem SQLite-Backend. Wir werden das nun erweitern, um das MySQL-Backend auch mit "aktuellen" Versionen zu testen.


    Ich bitte um Entschuldigung für die Unannehmlichkeiten; ein Update läuft eben durch's Build-System und steht in ca. 30-45 Minuten online.


    Viele Grüße


    -Klaus Keppler

  • LiveConfig v1.8.2 freigegeben

    Zitat von sTeaLth
    Code
    mysql_stmt_execute: (1690) BIGINT UNSIGNED value is out of range in '(`LIVECONFIG`.`RRA_CPU`.`RRA_STEP` * `LIVECONFIG`.`RRA_CPU`.`RRA_SIZE`)'


    Ah, danke... da liegt der Hund begraben. Der Wert in RRA_SIZE kann -1 sein, was natürlich Probleme mit BIGINT UNSIGNED macht. Ich verstehe nur MySQL an dieser Stelle noch nicht so recht - auf unseren Entwicklungssystemen läuft das nämlich komischerweise problemlos. Scheint mit der Version des MySQL-Servers zusammen zu hängen.
    Wir prüfen das gerade genauer...

  • LiveConfig v1.8.2 freigegeben

    Danke für die Rückmeldungen - Fehler gefunden. Eine Variable wird dort falsch initialisiert (bzw. der Vergleich wird mit der falschen Variable durchgeführt). Wir haben hier einen Server mit 20 SSL-Zertifikaten, bei denen alle korrekt angezeigt werden, daher fiel das leider nicht vorher schon auf. :( Update kommt gleich...
    (zumindest ist das nur eine Anzeigefehler, hat also keine Aufwirkung auf die Konfiguration o.ä.)

  • LiveConfig v1.8.2 freigegeben

    Zitat von Lite

    Bei mir in LiveConfig Basic werden alle Zertifikate, die im Jahr 2016 und später ablaufen, bereits mit einem Warndreieck als abgelaufen markiert. Bei 2015ern scheint der Datumsvergleich zu funktionieren.


    Sehr schräg... kann ich hier nicht reproduzieren (wir haben hier Zertifikate mit Ablaufdatum 2017, die ganz normal angezeigt werden). Stimmt Ihr Serverdatum? (bei "Einstellungen" -> "Zeitzone" wird Ihre aktuelle Zeit angezeigt).

  • LiveConfig v1.8.2 freigegeben

    Das LiveConfig-Team freut sich, die Verfügbarkeit von LiveConfig v1.8.2 (r3444) bekanntgeben zu dürfen.


    Zu den wichtigsten Verbesserungen und neuen Funktionen gehören:

    • Prüfung des Zertifizierungspfads von CA-Zwischenzertifikaten
      somit sorgen ungültige oder überflüssige Zwischenzertifikate nicht mehr zu Konfigurationsfehlern oder unnötigem Ballast beim SSL-Handshake
    • Caching und automatische Konfiguration von CA-Zwischenzertifikaten
      LiveConfig speichert CA-Zwischenzertifikate und richtet diese bei weiteren SSL-Zertifikaten automatisch ein. Bei identischen SSL-Produkten muss somit nicht mehr jedes Mal separat das "ca-bundle" entpackt und eingerichtet werden.
    • abgelaufene SSL-Zertifikate werden in der Übersicht (Zertifikatsverwaltung) markiert
    • Vertragsnamen dürfen nun bis zu 63 Zeichen lang sein (statt bisher 10 Zeichen)
    • TSIG-Schlüssel für signierte Zonentransfers dürfen nun bis zu 512 Bit lang sein (statt bisher 128 Bit)
    • Voraussetzungen für DNSSEC werden besser geprüft (DNSSEC kann nur aktiviert werden, wenn auch mindestens ein KSK-Schlüssel vorhanden ist)
    • DNS-Vorlagen können nun an Reseller zugewiesen werden (damit können auch Wiederverkäufer Domains in einem von LiveConfig verwalteten DNS anlegen)
    • SNI/SSL-Konfiguration von NGINX verbessert (damit sollte SSL und insbes. SNI mit NGINX nun ohne manuelle Eingriffe funktionieren)


    Zudem gab es einige Verbesserungen und Fehlerbeseitigungen - die vollständige Liste finden Sie im Änderungsverlauf.


    Das Update lässt sich wie immer reibungslos über die Repositories einspielen.


    Im Namen des LiveConfig-Teams


    -Klaus Keppler

  • SpeicherplatzQuota nach Realverbrauch

    Kurze Antwort: geht technisch nicht*.

    • Webspace-Quota wird auf Datei-Ebene (Filesystem-Quota) realisiert.
    • Mailbox-Quota wird über Maildir-Quota realisiert, so dass z.B. IMAP-Clients auch anzeigen können wie viel Platz noch im Postfach ist, oder auch Postfix vor Annahme einer E-Mail weiß ob noch genug Platz zum Speichern vorhanden ist.
    • MySQL-Datenbanken "kennen" kein Quota. Hier wird es mittelfristig eine Lösung auf Basis der INSERT/UPDATE-Berechtigung geben (die wird dann entzogen wenn eine Datenbank "zu groß" wird)


    Würde man Datenbanken mit ins Filesystem-Quota aufnehmen, dann gäbe es einen sehr großen Konfigurationsaufwand (so müsste man z.B. zwingend InnoDB-Datenbanken pro Kunde aufsplitten etc.) und die latente Gefahr von Inkonsistenzen, sobald MySQL aufgrund von aufgebrauchtem Quota eine Datei nicht mehr committen kann.
    Würde man E-Mails mit ins Filesystem-Quota aufnehmen, dann könnte das System nicht* herausfinden wann es sinnvoll ist, eine "Quota-Warnung" per E-Mail zu versenden, um den Kunden über den drohenden Speichermangel zu informieren. Zudem müsste diese Mail ja an alle Postfächer zugestellt werden. IMAP-Clients wüssten nicht* mehr, wie viel Platz noch im Postfach ist, bzw. würden für alle Postfächer den selben Wert anzeigen.


    Ich sehe nur einen minimalen Vorteil (vertragliche Festlegung von nur einem einzigen Quota-Wert) und eine groooße Menge Nachteile. Unsererseits ist also eine Umsetzung nicht vorgesehen.


    *) "nicht" im Sinne von "der Aufwand hierfür wäre unverhältnismäßig"

  • PREVIEW: LiveConfig v1.8.2

    Die Preview für v1.8.2 wurde eben aktualisiert (v1.8.2-r3443). Die produktive Freigabe erfolgt voraussichtlich heute Nachmittag.


    Die Änderungen sind:

    • Fehler bei der Neuzuordnung einer IP-Gruppe an einen anderen Wiederverkäufer behoben
    • Fehler bei Auswahl des Webspace-Startverzeichnisses bei bislang deaktivierten Subdomains behoben
    • Fehler bei Anzeige der 24h/7d-Graphen beseitigt (Anzeige des "großen" Graphen)
    • Anzeige des im Hosting-Vertrag enthaltenen Datenverbrauchs (Traffic)
    • Unterstützung von TSIG-Schlüsseln bis 512 Bit (statt bislang 128 Bit)
    • Erlaube Zuweisung von DNS-Templates an Wiederverkäufer-Verträge (geht aus Sicherheitsgründen aber nur mit "Resellern 1. Grades", also nicht bei Resellern von Resellern...)
    • Parameter "dnstemplate" zur SOAP-Funktion HostingDomainAdd() hinzugefügt


    Die automatische Übertragung von Backtraces bei Programmfehlern wurde (wie angekündigt) wieder entfernt.


    Viele Grüße


    -Klaus Keppler

  • Domains löschen, Datenbanken löschen

    Alle verfügbaren API-Funktionen sind jeweils im Handbuch beschrieben (SOAP-Referenz).
    Derzeit hat LiveConfig lediglich das Löschen von kompletten Verträgen implementiert (HostingSubscriptionDelete). Die SOAP-API wird bislang hauptsächlich für den Import aus Fremdsystemen sowie die Anbindung an eigene Bestellsysteme genutzt - da spielt das Löschen keine Rolle.


    Bei Bedarf können wir LiveConfig natürlich Schritt für Schritt auch um Funktionen zum Löschen einzelner Objekte erweitern. Da das tatsächliche Löschen aber asynchron stattfindet, muss eine Anwendung auch mit dem notwendigen "Timing" zurecht kommen. Konkret also: wenn z.B. ein Vertrag gelöscht wird, dann kann das bei vielen Dateien im Webspace eine Weile dauern bis die Aktion abgeschlossen ist. Würde man dann eine Funktion "CustomerDelete()" aufrufen so lange der Vertrag noch nicht vollständig gelöscht ist, dann würde das zu einer Fehlermeldung führen (da der Vertrag ja noch existiert).


    Der Fokus liegt jedenfalls ganz klar auf der Funktionalität der "eigenen" GUI. Wenn einzelne SOAP-Funktionen benötigt werden, geben Sie gerne Bescheid - wir nehmen die dann der Reihe nach mit auf.


    Viele Grüße


    -Klaus Keppler

  • Apache (internal dummy connection) in access.log

    Diese Log-Meldungen werden ausschließlich durch Apache selbst erzeugt, mit LiveConfig hat das rein gar nichts zu tun. Wer das genau nachlesen möchte: es ist alles ausführlich dokumentiert.


    Zudem dürften diese Einträge ausschließlich in den zentralen Apache-Logs (/var/log/apache2/) auftauchen, und nicht in webspace-spezifischen Logdateien (/var/www/###/logs/).


    Die Log-Konfiguration wird durch LiveConfig in die Datei /etc/apache2/conf.d/liveconfig geschrieben. Wenn Sie diese Einstellung "überschreiben" möchten, legen Sie eine Datei an die (alphabetisch) zum Schluß geladen wird - also z.B. /etc/apache2/conf.d/ZZZ-log
    In die schreiben Sie dann die CustomLog-Anweisung wie sie in der "liveconfig"-Datei steht und erweitern diese entsprechend:

    Code
    [B]SetEnvIf Remote_Addr "127\.0\.0\.1" loopback
SetEnvIf [...IPv6-Adressen...][/B]
CustomLog "||/usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats" LiveConfig [B]env=!loopback[/B]


    Ach ja, ich rate übrigens von solchen Bastellösungen ab, sofern es keinen dringenden Grund für die Vermeidung dieser Log-Einträge gibt. Es erhöht die Komplexität der Konfiguration, erschwert die Fehlersuche, macht eventuell Probleme bei Updates (weder die Apache-Pakete noch LiveConfig "weiß" etwas von der manuellen Konfiguration) und - last but not least - sorgt für unnötige Zusatzlast bei der Verarbeitung von Log-Einträgen.

  • PREVIEW: LiveConfig v1.8.2

    Die Preview für Version 1.8.2 wurde soeben aktualisiert (v1.8.2-r3427).


    Die Änderungen sind:

    • Anzeige der DNS-Vorlage in Domain-Tabelle
    • zeigt Hinweis wenn eine neue LiveConfig-Version verfügbar ist
      (hierfür wird lediglich ab sofort mit dem AppInstaller-Update auch die aktuellste LiveConfig-Versionsnummer übermittelt - es findet also keine zusätzliche Anfrage statt, weiterhin werden dabei keine Daten an uns übermittelt)
    • Prüfung des Zertifizierungspfads bei CA-Zwischenzertifikaten
      (damit werden künftig "falsche" CA-Zwischenzertifikate abgelehnt um Fehlkonfigurationen zu vermeiden)
    • Caching und automatische Konfiguration von CA-Zwischenzertifikaten
      (damit muss man künftig nicht für jedes einzelne Zertifikat die Zwischenzertifikate importieren - es genügt das einmal pro Zwischenzertifikat gemacht zu haben)
    • Prüfung der DNSSEC-Vorausetzungen verbessert
    • Markierung abgelaufener SSL-Zertifikate in Zertifikats-Liste
    • SNI/SSL-Konfiguration für NGINX korrigiert
    • Eingabelängen für Kontaktdaten-Felder vergrößert (für Multibyte-UTF8)
    • maximale Länge für Vertragsnamen von 10 auf 63 Zeichen vergrößert
    • Verzeichnis-Passwortschutz mit NGINX verbessert
      (Begrenzung der erlaubten Benutzer, bessere Unterstützung von Subdomains in Unterverzeichnissen mit Passwortschutz)


    Mit v1.8.2 befinden wir uns nun im "Feature Freeze" - die neuen Funktionen werden nun noch ausführlichst durchgetestet und dann in Kürze produktiv freigegeben. Die Arbeiten an der nächsten Version (v1.8.3) umfassen u.a. das CLI, das Backup und eine bequemere DNS-Verwaltung.


    Die Funktion zur automatischen Übermittlung von Stacktraces bei Programmfehlern wird vor der produktiven Freigabe vorerst wieder deaktiviert (in dieser Preview ist das noch aktiv).


    Viele Grüße


    -Klaus Keppler

  • PREVIEW: LiveConfig v1.8.2

    Zitat von easynetwork

    Und nach einem kurzem Check beim SSL Zertifikat ist SSL3 auch noch aktiviert ;(.


    In frühen LiveConfig-Versionen hatten wir in der OpenSSL-API statt "SSLv23_method()" die Funktion "SSLv3_method()" verwendet. War "damals" (vor POODLE) kein Thema, inzwischen aber ein Problem, da mit "SSLv3_method()" keine TLS-Verbindungen möglich sind (ja, die OpenSSL-API ist an dieser Stelle etwas !$#%&...)
    Kurzum: wenn wir SSLv3 abschalten, werden ältere LiveConfig-Versionen keine Lizenz mehr verlängern können. Aktuelle Versionen verbinden sich aber ohnehin via TLS1.2 mit dem Lizenz- und Updateserver.


    Last but not least: um POODLE auszunutzen müsste man in der Lage sein, die Kommunikation zwischen Client und Server zu beeinflussen (z.B. via Javascript in einer Website). LiveConfig führt ausschließlich einen einzigen GET-Request aus. Ich bin kein Experte auf diesem Gebiet, soweit ich das verstanden habe ist die Verbindung so aber nicht anfällig.


    Zitat

    Naja, (in)direkt schon. In meiner Lizenzübersicht steht zu jeder verwendeten Lizenz die IP-Adresse des Servers. Somit ist über diese Zuordnung klar, welcher Lizenznehmer mit welcher Lizenz und ggf. mit welcher Domain der Fehler aufgetreten ist.


    Das betrifft bestenfalls die Lizenzen, welche direkt über unseren Shop bestellt wurden. Bei allen über LiveConfig-Partner bestellten Lizenzen (und das ist der Großteil) wissen wir nicht, wer der Kunde ist. Und Domains kennen wir in keinem Fall (es wird nirgendwo ein Domainname übermittelt).


    Für uns hat eine offene Kommunikation der an uns übermittelten Daten seit Anfang an größte Priorität. Bei "anderen" Control-Panels muss man ja bereits während der Erst-Installation seine vollständigen Kontaktdaten angeben (fragt mich bitte nicht, wozu...).
    Ein Highlight ist es dann, wenn Betroffene gleich mittels iPhone bei Facebook posten, wie unverschämt es ist, dass irgendwelche Daten im Hintergrund übertragen werden... ;)

  • Multi-Server-Setup?

    Nachtrag: oh... das nachträgliche Umstellen von einem Einzel- auf Multiserver-Setup geht derzeit noch nicht so ohne weiteres (erfordert einige Handarbeit). Da bei einem Multiserver-Setup alle Daten zentral auf dem Server mit der Business-Lizenz gespeichert werden, müssten alle bislang separaten LiveConfig-Datenbanken zusammengeführt werden. Hierfür existiert noch kein Migrationspfad bzw. Import-Mechanismus, steht aber schon auf unserer ToDo-Liste.
    Ein manueller Import durch uns ist unter bestimmten Umständen möglich; wenden Sie sich bei Interesse bitte direkt an support@liveconfig.com