Was steht in /etc/apt/sources.list?
Beiträge von kk
-
-
Für Postfächer muss in LiveConfig immer ein Quota angegeben werden (die Gesamtgröße aller Postfächer kann in einem Vertrag zwar unbegrenzt sein, ein Postfach braucht aber immer ein Limit).
Eine pauschale Antwort, was in diesem Fall zu machen ist, kann man nur schwer geben - das kommt zu sehr auf den Einzelfall an. Die einfachste Lösung könnte sein, in der Confixx-Datenbank für die Postfächer einen Quota-Wert festzulegen (kann ja auch ein großer Wert sein, z.B. 10 GB).
-
Die Preview wurde nun zum voraussichtlich letztem Mal aktualisiert (v1.8.3-r3569). Damit werden nun u.a. für DKIM die notwendigen Resource-Records automatisch im DNS angelegt (wenn die Domain auf "eigenen" Nameservern verwaltet wird).
Letzte Baustelle sind noch die OpenDKIM-Init-Scripte für CentOS - dann sollte dem Release nichts mehr im Wege stehen.
Viele Grüße
-Klaus Keppler
-
k=rsa stimmt (bei meiner Aussage mit rsa-sha256 hatte ich was verwechselt - das betrifft nur die OpenDKIM-Konfiguration).
-
Kurzer Hinweis: das lcdbdump-Utility (siehe KB#15) wurde überarbeitet - der erzeugte SQL-Dump lässt sich nun ca. 46x schneller in MySQL importieren.

Die Download-Links sind die selben geblieben; ob man die "neue" Version hat sieht man durch Aufruf des Programms ohne Parameter - in der neuen Version wird dann das Release-Datum angezeigt.Viele Grüße
-Klaus Keppler
Code
Alles anzeigen$ ./lcdbdump _ _ ___ __ _ (R) | | (_)_ _____ / __|___ _ _ / _(_)__ _ | |__| \ V / -_) (__/ _ \ ' \| _| / _` | |____|_|\_/\___|\___\___/_||_|_| |_\__, |_____________________________________ |___/ LiveConfig dump utility for SQLite/MySQL migration ([B][COLOR=#b22222]version 2015-05-04[/COLOR][/B]) Usage: lcdbdump <sourcedb> <dump> sourcedb database file to dump dump dump file ______________________________________________________________________________ Copyright (c) 2009-2015 Keppler IT GmbH. http://www.liveconfig.com -
Hallo,
wenn möglich führen Sie den SELECT-Befehl aus dem Slow-Query-Log mal mit dem Befehl "EXPLAIN " (als Präfix) aus. Das Ergebnis schicken Sie uns am besten per Mail (support@liveconfig.com).
Ich tippe darauf, dass es eni großes "Ungleichgewicht" in der Schlüsselverteilung gibt, was zu der langen Ausführungszeit führt.
Unabhängig davon sollten aber auf einer SSD Abfragen mit 10 Mio durchsuchten Records trotzdem keine 22 Sekunden dauern...Viele Grüße
-Klaus Keppler
-
Ja, der Flaschenhals dürfte bei SQLite liegen. Genaue "Grenzwerte" bis wann SQLite ausreicht gibt es nicht, da es zu sehr auf die jeweilige Maschine ankommt (I/O-Leistung, tatsächliche Auslastung, etc.). Wichtiger als die Zahl der Domains ist eher die Zahl der Verträge und Postfächer - für diese werden regelmäßig Statistikdaten eingesammelt (insbes. Quota), was die Datenbank ziemlich beschäftigt.
Eine Umstellung von SQLite auf MySQL ist aber problemlos möglich, siehe http://www.liveconfig.com/de/kb/15
Auf die SQLite-Datenbank können Sie mit dem Tool "sqlite3" zugreifen (ist in jeder Distribution über den Paketmanager installierbar).Viele Grüße
-Klaus Keppler
-
Aha. Der Ursprung würde mich ja mal interessieren.

Fakt ist, dass zumindest ich keinen "Showstopper" kenne, warum LiveConfig nicht mit Debian Jessie zurecht kommen würde. Die Versionen der zu verwaltenden Software sind unspektakulär, und da Jessie auch mit systemd noch "klassische" Init-Scripte unterstützt klappt soweit alles.
Unsere automatisierten Tests laufen inzwischen auch unter Debian Jessie, dort waren keinerlei Anpassungen notwendig. Einen Demoserver haben wir vorgestern von Debian 7 auf 8 aktualisiert, lief einwandfrei durch.Lediglich das Paket "liveconfig-meta" ließ sich in v0.3.4 nicht unter Jessie installieren, da dieses noch eine Abhängigkeit zu suPHP hatte. Mit Version 0.4.0 (inzwischen im Test-Repository sowie im Source unter https://github.com/liveconfig/meta) klappt das dann aber auch reibungslos.
Viele Grüße
-Klaus Keppler
-
CentOS 7 wird bereits seit einiger Zeit von LC unterstützt. CentOS 7.0 hatte allerdings noch einige Kinderkrankheiten (konkret hatten wir in unserer Xen-Testumgebung einen reproduzierbaren Crash von ProFTPd aufgrund eines längst in RedHat gepatchten Kernel-Bugs; mit CentOS 7.1 sollte das aber behoben sein. Bei Interesse kann ich die Fehlernummer mal heraussuchen)
ZitatCentOS mit seinen 10 Jahren Laufzeit ist da sehr interessant.
Hmm, unsere Begeisterung zur Unterstützung von CentOS 5 bis 01.04.2017 hält sich in Grenzen.
Manchmal ist es schon eine echte Herausforderung, uralte Softwarepakete halbwegs brauchbar zu konfigurieren. -
Preview wurde eben von r3555 auf 1.8.3-r3560 aktualisiert - darin wurde der Fehler mit dem ungültigen DKIM-Key behoben. Außerdem werden DKIM-Daten nun auch automatisch im DNS eingetragen/aktualisiert.
Nun werden noch die Übersetzungen aktualisiert und ein paar weitere Änderungen/Features gemerged, morgen wir dann der "release candidate" freigegeben.Viele Grüße
-Klaus Keppler
-
ich dachte dieses Problem wäre schon beseitigt ?
Sollte es auch...
Die Frage ist:
- von welcher LC-Version wurde aktualisiert?
- was steht um den Neustart-Zeitraum herum in /var/log/liveconfig/liveconfig.log? (ggf. großzügigen Ausschnitt aus dem Log an support@liveconfig.com schicken)Viele Grüße
-Klaus Keppler
-
Ich persönlich halte absolut gar nichts davon, Besucher auf Basis des Quell-Landes auszuschließen (das bringt uns dann nämlich auf die selbe Ebene wie China, Saudi-Arabien, Nordkorea etc...). Wenn es konkrete Angriffe gibt empfehle ich eine individuelle IP-Filterung (z.B. fail2ban auf eine zentrale Log-Datei einrichten). Spätestens mit IPv6 ist GeoIP derzeit ohnehin nur sehr begrenzt brauchbar. Und bei dem zunehmenden IPv4-Handel und -Partitionierung ist auch da die Gefahr von "false positives" steigend.
Unabhängig davon kenne ich die CSF-Firewall nicht im Detail und kann daher auch nichts dazu sagen.
Individuelle Änderungen an der Apache-Konfiguration können sonst direkt in apache.lua vorgenommen werden (wird aber bei jedem Update überschrieben), oder man biegt die betroffene Funktion per custom.lua auf eine eigene Funktion um.Viele Grüße
-Klaus Keppler
-
Einen Fehler habe ich eben gefunden: im angezeigten DNS-Schnipsel steht "k=rsa", der OpenDKIM selbst wird aber mit "rsa-sha256" konfiguriert. Richtig wäre im DNS also "k=rsa-sha256".
Am Nachmittag kommen die "großen" Tests (bislang prüfen wir nur ob die Dateien alle richtig erzeugt wurden und eine DKIM-Signatur vorhanden ist), da wissen wir dann sicher mehr.Viele Grüße
-Klaus Keppler
-
Lass ich von Liveconfig ein Schlüsselpaar erzeugen ist der Public Key immer ungültig.
Wie äußert sich das, dass der Public Key ungültig ist?
ZitatHabe ich ein Denkfehler? Müssten die Public Keys nicht identisch sein?
Nicht unbedingt - das was da angezeigt wird ist nur die Base64-codierte Darstellung des RSA-Public-Keys. Dessen Codierung (ich glaube TASN.1) ist nicht eindeutig (soll heißen, es gibt verschiedene Codierungsmöglichkeiten für die selben Ausgangsdaten). Da macht es schon einen Unterschied ob man mit OpenSSL 0.9.8 oder 1.0.0 arbeitet.
Bei unseren Tests gab es bislang noch keine Auffälligkeiten, wir haben aber noch nicht für alle Fälle die Tests fertig programmiert. Ich prüfe den oben beschriebenen Fall in Kürze mal manuell durch.
Viele Grüße
-Klaus Keppler
-
Ab Version 1.8.3-r3555 (aktuelle Preview) werden das Hochkomma ('), Anführungszeichen (") und Backslash (\) nicht mehr in automatisch erzeugten Passwörtern verwendet. Komma und Semikolon dürften eigentlich kein Problem darstellen.
Viele Grüße
-Klaus Keppler
-
Die Preview wurde eben aktualisiert (v1.8.3-r3555).
Neben ein paar kleineren Features (Anzeige des Plattenplatzes, HTTP-Traffic-Graph für Endkunden, etc.) wurde insbesondere die DKIM-Unterstützung verbessert. Wir schließen derzeit nur noch die DNS-Integration von DKIM ab, dann erfolgt die Freigabe. Ein weiteres Preview-Update ist für nächste Woche geplant.Viele Grüße
-Klaus Keppler
-
Der "Bad Gateway"-Fehler tritt auf, wenn (vereinfacht gesagt) alle PHP-Instanzen voll beschäftigt sind auch auch deren Warteschlangen (Backlog) voll sind. In diesem Fall lehnen die weitere Verbindungen von NGINX ab, was dann zum "Bad Gateway" führt.
Die Lösung ist prinzipiell recht einfach: Anzahl der PHP-Instanzen erhöhen. Das Problem ist nur, dass sich diese Option derzeit noch nicht über LiveConfig steuern lässt (ich denke wir werden das kurzfristig als weiteren Konfigurationsparameter mit aufnehmen).Um das vorerst mal manuell zu lösen, bearbeiten Sie die Datei /etc/nginx/sites-available/web10.conf. Am Ende der Datei steht folgende Zeile:
Ändern Sie die "5" in z.B. "50" und führen danach "/etc/init.d/nginx-php-fcgi restart" aus - damit sollte dieser User bis zu 50 PHP-Instanzen erhalten.Aber Vorsicht - dieser Wert wird wieder auf "5" zurückgesetzt, sobald was im LiveConfig im Vertrag "web10" neu gespeichert wird. Ggf setzen Sie das "+i"-Attribut (chattr +i web10.conf), damit die Datei nicht versehentlich überschrieben werden kann.
-
Ab sofort stehen die aktualisierten PHP-Pakete in den Versionen 5.4.40, 5.5.24 und 5.6.8 für Debian 6 (Squeeze) und Debian 7 (Wheezy) bereit (siehe KB#22).
Ab sofort sind auch die Module "intl" und "shmop" enthalten (Letzteres ist standardmäßig aber deaktiviert - ggf. muss man also die Datei /opt/php-5.x/conf.d/shmop.ini.disabled entsprechend umbenennen und anpassen)
Wir planen auch für das in Kürze erscheinende Debian 8 ("Jessie") entsprechende PHP-Pakete bereitzustellen.
Viele Grüße
-Klaus Keppler
-
Ja, auch hallo?
Noch einmal: welche OpenSUSE-Version nutzen Sie? Was genau ist das Problem? "No such file or directory" wird ja wohl kaum im Log auftauchen können, wenn Sie in der clamav-milter.conf einen anderen Socket-Pfad angeben.Für individuelle Hilfe wenden Sie sich ansonsten bitte an support@liveconfig.com (bitte unter Angabe Ihrer Lizenznummer - wir finden hier keinen Kundendatensatz mit Ihrer E-Mail-Adresse).
-
Bearbeiten Sie bitte mal den Hosting-Vertrag. Dort gibt es unter "Subdomains" eine Dropdown-Box "eigene DNS-Einträge erlauben: ...". Stellen Sie diese ggf. auf "erlauben".
