Beiträge von kk

Zitat von andreas

Ja, das ist schon längst fällig! Schade das dies seit über 1 Jahr nicht berücksichtigt wird.

Ja, unbedingt! Zumal es die neue Passwort-Eingabemaske (mit der "Passwort anzeigen"-Checkbox) erst seit Version 1.8.0 (22.12.2014) gibt... :p

Bei den Datenbanken steht links von dem Passwortfeld: Neues Passwort:
Wenn ein Endkunde dort ein neues Passwort eingibt und auf den "Speichern"-Button klickt, dann passiert eben genau das, was er beauftragt hat. Es wird ein neues Passwort gesetzt.

Passwörter werden serverseitig in der Regel gehashed, nur in seltensten Fällen verschlüsselt. Und selbst verschlüsselte (und somit "rekonstruierbare") Passwörter würden wir niemals an den Browser senden. Es wird in LiveConfig also keine Funktion "Passwort anzeigen" für bestehende Passwörter geben (auch wenn sich das manche "Provider" gerne wünschen).
Unser UI-Kollege wird sich aber mal um die "Passwort zeigen"-Checkbox kümmern (die in der Tat nur bei Eingabe eines neuen Passworts Sinn macht).

Mit v1.8.2-r3457 steht ab sofort ein kleines Update bereit. Dieses behebt folgende Fehler:

• Fehler bei bei SSL-Konfiguration von NGINX mit mehr als einer IP-Adresse behoben
  (betraf die default-vHost-Konfiguration von IP-Gruppen mit mehr als einer IP und mit aktiviertem SSL)
• Fehler bei Verwendung von syslog für LiveConfig-Meldungen behoben
  (syslog wurde zwar "geöffnet", Log-Meldungen wurden vorher aber alle herausgefiltert...)
• Fehler bei Änderung der Bemerkung für Datenbanken beseitigt (ohne dabei auch das Passwort zu ändern)
• Parameter "webserver", "mailserver" und "dbserver" zu SOAP-Funktion HostingSubscriptionEdit() hinzugefügt (wird benötigt wenn Ressourcen erstmals einem Vertrag zugeordnet werden)

Das Update steht wie immer in den Repositories und auf der Website zum Download bereit.
(und um den unzähligen "gibt's nun auch das Feature XY"-Fragen vorzugreifen: nein - außer dem was in der Liste aufgeführt wurde hat sich mit dem Update nichts geändert).

Viele Grüße

-Klaus Keppler

Zitat von andreas

Lag der Fehler nun an meiner Seite oder seitens LC ?
Eine kurze Antwort wäre nett...

Leider ist die Glaskugel kaputt.
Ich weiß nicht was auf Ihrem System passiert ist (woher auch). Normalerweise startet "lclogparse" ganz normal, öffnet und liest (kontinuierlich) die Postfix-Logdatei (meist /var/log/mail.log) und schreibt die gesammelten Statistiken alle 15 Minuten in die smtp.stats
Wenn Sie durch Neustart des Prozesses das Problem lösen konnten, aber ein Neustart des Servers nichts geändert hat, kann ich mir da keinen Reim drauf machen.

Zitat von RB-Media-Group

Nun muss ich nur noch TLS1.2 aktiviert bekommen, das scheint bei NGINX ja ne Kunst zu sein.

Das kann NGINX eigentlich automatisch, sofern es mit einer aktuellen OpenSSL-Version (ab v1.0.1c) compiliert wurde.

Bei Debian Wheezy läuft das "out of the box". Wer das prüfen möchte: auf unserer Demo-Installation (demo.liveconfig.com) haben wir SSL mit SNI auf NGINX unter der Domain https://nginxdemo.de aktiviert (mit selbstsigniertem Zertifikat). via SSLLabs sieht das so aus: https://www.ssllabs.com/ssltes…inxdemo.de&hideResults=on

Zitat von andreas

die Datei /var/lib/liveconfig/smtp.stats ist aktuell nicht vorhanden!

Na, da kommen wir der Sache ja schon näher. Läuft denn ein Programm namens "lclogparse"?
Wenn nein, lässt es sich mittels "/etc/init.d/lclogparse start" starten?
Welche Distribution genau verwenden Sie?

Zitat von andreas

seit edem letzten Update auf die LiveConfig 1.8.2-r3451 wird komischerweise bei den Emails die (I/O-24Std) nicht mehr angezeigt, also die Anzahl der Mails.

Relevant ist hierfür die Datei /var/lib/liveconfig/smtp.stats

• Ist diese Datei bei Ihnen aktuell?
• Ändern sich die Werte nach dem Empfang/Versand von Mails? (Datei wird alle 15 Minuten aktualisiert)
• welches Datenbank-Backend nutzen Sie für LiveConfig? (MySQL oder SQlite)
• was für Meldungen tauchen in /var/log/liveconfig/liveconfig.log nach einem LiveConfig-Neustart auf?

Das Update (r3451) steht ab sofort auf der Website und in den Repositories bereit.
Die Änderungen sind:

• Datenbankfehler beim Bearbeiten von Webstatistik-Einstellungen behoben
• Fehler bei Eingabe einer Website-Adresse bei Kontaktdaten behoben
• Detailgenauigkeit im 7d-HTTP-Traffic-Graph verbessert
• Neustart von LiveConfig mittels start-stop-daemon robuster gestaltet

Bei diesem Update kann es sein, dass der oben beschriebene Fehler beim Neustart (via start-stop-daemon) noch auftritt. Unseren Untersuchen nach könnte es sich da um ein Timing-Problem handeln, bei dem die "liveconfig.pid" während der Deinstallation (für das Upgrade) gelöscht wird noch bevor der start-stop-daemon dem LiveConfig-Prozess das kill-Signal gesendet hat).
Das mit r3451 ausgelieferte init-Script ist jedenfalls robuster gestaltet - sollte es bei künftigen Updates noch mal Probleme geben, melden Sie sich bitte kurz bei uns (am besten mitsamt der Bildschirmausgaben während des Update-Vorgangs, so wie weiter oben von WebService4U).

Viele Grüße

-Klaus Keppler

Zitat von thomas16

beim Anlegen eines neuen Kontakts wird eine eingetragene Website als "ungültige Website-Adresse" abgewiesen.

Danke für den Hinweis - der Fehler ist mit dem Update (r3450) behoben.

Viele Grüße

-Klaus Keppler

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

Uha... das scheint eine Nebenwirkung des neuen SQL-Parsers zu sein.
Wir werden morgen Vormittag ein Bugfix-Update bereitstellen.

Viele Grüße

-Klaus Keppler

r3447 wurde in diesen Minuten freigegeben und ist die aktuelle Version (welche die beiden in diesem Thread behandelten Anzeigefehler behebt)

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

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...

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.ä.)

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).

Zitat von thomas16

Die Graphen für CPU/Netzwerk werden nach Klick garnicht angezeigt - also keine vergrößerte Ausgabe.

Machen Sie bitte mal einen "sicheren" Reload (<Strg>+<R>). Falls danach noch immer keine Graphen erscheinen: welchen Browser verwenden Sie?

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

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"

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

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