Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.25 und 7.3.12 aktualisiert.
Zudem ändern sich damit ab sofort die Versionierung der Pakete. Statt bisher z.B. "7.2.25-1+stretch1" lautet die Nummer nun "1:7.2.25-1+deb9u1".
Damit wird ein mögliches Problem beim Dist-Upgrade umgangen (die alphabetische Sortierung von "stretch"/"buster" ist problematisch, "deb9" und "deb10" wird von Debian dagegen korrekt sortiert).
Viele Grüße
-Klaus Keppler
Hallo,
nein - eine Begrenzung auf einzelne Kunden gibt es leider nicht.
Wenn nur der Zugriff auf *einen* einzelnen Kunden gewünscht wird, könnte man innerhalb dieses Kunden einen zusätzlichen LiveConfig-Benutzer angelegen.
Außerdem ist es möglich, einem Benutzer zwar die Berechtigung zur Kundenverwaltung zu geben, nicht aber für "eigene" Webspaces des admin-Accounts. (ich weiß ja nicht um welchen Use-Case es da geht - vielleicht hilft das...)
Viele Grüße
-Klaus Keppler
Nutzen Sie LiveConfig mit der standardmäßigen SQLite-Datenbank?
Ein anderer Kunde hat ein ähnliches Problem berichtet. Wir vermuten, dass ein Thread, der die Let's-Encrypt-Sachen bearbeitet, die Datenbankverbindung zu lange offen hält und somit andere Zugriffe blockiert.
Schicken Sie uns bitte mal die Ausgabe von "ps aux -L | grep liveconfig" (entweder hier posten, oder per Mail an support@liveconfig.com). Zudem wäre interessant, ob es regelmäßige Meldungen in /var/log/liveconfig/liveconfig.log gibt.
Viele Grüße
-Klaus Keppler
laut Fehlermeldung würde ich sagen das das Modul mod_filter.c unter PHP 7.1 nicht zur Verfügung steht.
Äh - Apache-Module (wie mod_deflate) haben mit PHP absolut nichts zu tun.
Ich vermute eher einen Tippfehler in der .htaccess-Datei. Vergleichen Sie diese beiden Dateien (von Domain A und B) mal mit dem "diff"-Befehl.
LiveConfig speichert alle Daten über die gesamte Multiserver-Installation nur auf dem "Master".
Wenn der "Hauptserver" also nur auf eine andere Maschine umgezogen wird (d.h. alle Daten usw. werden mit übernommen), dann ist da nichts zu beachten.
Was allerdings nicht ohne Weiteres geht ist, einen LiveConfig-Server in einen LiveConfig-Client umzuwandeln. Wenn Sie so etwas vorhaben, setzen Sie sich bitte mit uns in Verbindung (support@liveconfig.com); mit einer Hand voll SQL-Befehle ist das meistens machbar.
Viele Grüße
-Klaus Keppler
Fehler gefunden. die lcclient.conf stand auf Auslieferungswerte... warum auch immer...
Eigentlich auch ganz einfach: weil entweder der LiveConfig-Client zwischenzeitlich komplett vom Server gelöscht wurde ("purge") oder weil z.B. während eines Upgrades die Konfigurationsdatei ausdrücklich überschrieben werden sollte (APT fragt da vorher immer nach, ob er das auch wirklich machen soll).
Welchen DNS Namen versucht Liveconfig dort aufzulösen ??
Äh - genau den Namen der in der Fehlermeldung angezeigt wird...
Das hat nicht unbedingt etwas mit DNS zu tun.
Wenn in /etc/hosts was unbrauchbares drin steht, dann hat das Vorrang.
Daher hatte ich ja die Frage gestellt, was "ping -c 1 <servername>" ergibt.
Dort wo diese Fehlermeldung ausgegeben wird macht LiveConfig eine Adressauflösung (mittels "getaddrinfo").
Die Fehlermeldung lässt eigentlich keinen Spielraum zur Interpretation offen: die Namensauflösung klappt einfach nicht - und der Grund dafür liegt außerhalb von LiveConfig.
Vielleicht steht in /etc/hostname noch ein veralteter Eintrag zu dem Servernamen drin?
Was liefert der Befehl "ping -c 1 <servername>" genau?
Das sieht nach einer Multi-Server-Umgebung aus. Wird die Meldung auf dem LiveConfig-Server oder dem -Client protokolliert?
Im Prinzip deutet das darauf hin, dass sich der LiveConfig-Client nicht mit dem Server verbinden kann, weil die DNS-Auflösung (vom System) keinen brauchbaren Namen geliefert hat. Sehr viel mehr kann ich ohne weitere Infos leider auch nicht sagen...
Danke für den Hinweis. Der Installer für RoundCube wurde eben für Version 1.4.0 aktualisiert (und erfolgreich getestet ;))
Dieser Text ist im LiveConfig-Spamassassin-Milter ("lcsam") fest verdrahtet:
https://github.com/LiveConfig/lcsam/blob/master/lcsam.c#L68
Ich weiß sponan nicht, ob oder wie man im Postfix die Fehlermeldung modifizieren könnte (theoretisch müsste man dem Postfix sagen, dass beim entsprechenden Fehlercode eine andere Meldung übermittelt wird...)
Viele Grüße
-Klaus Keppler
Ab sofort stehen für PHP 7.1/7.2/7.3 die Pakete "php-7.x-opt-pgsql" bereit, welche die PostgreSQL-Module (pgsql und pdo-pgsql) enthalten.
PHP 7.4 folgt in Kürze.
Viele Grüße
-Klaus Keppler
Hallo,
ab sofort steht die erste größere Preview für v2.9.0 zum Download bereit (20191112.2).
Die wichtigsten Änderungen sind:
Die vollständige Liste findet sich wie immer im Changelog.
Wir führen diese Woche noch den "Feature Freeze" für v2.9.0 durch, voraussichtlich noch Ende November erfolgt dann das Release.
Viele Grüße
-Klaus Keppler
Bei Schritt 4 stand ich jetzt plötzlich vor einem Problem. Ich hatte plötzlich die Auswahl zwischen 14 LE Konten, die alle gleich heißen und ich kann nicht erkennen welcher Account zu welchem Kunden gehört.
Die LE-Accounts gehören doch rein technisch keinen Kunden, sondern Ihnen?
(sprich: unter "SSL-Zertifikate" -> "SSL-Anbieter" tauchen die auch alle auf)
Welchen Grund hat es, so viele separate LE-Accounts zu nutzen?
Ich könnte mir vorstellen, dass wir in dem Popup zum Bearbeiten eines Let's-Encrypt-Accounts einen Tab einführen, bei dem man in einer Tabelle alle mit diesem Account verwalteten SSL-Zertifikate einsehen kann (die Anzahl der Zertifkate sieht man bereits in der Liste der Accounts).
Im nächsten Schritt wäre eine Art "Account-Konsolidierung" denkbar (á la "ab jetzt alle Verlängerungen bitte mit folgendem Account durchführen...").
Nutzen Sie unsere PHP-Pakete für Debian/Ubuntu?
Die enthalten derzeit keine PostgreSQL-Treiber. Können wir aber bei Bedarf gerne mit aufnehmen.
Eventuell sollte man wegen der Übersichtlichkeit im Admin-Bereich zwei Tabellen (oder einen Filter [Checkbox etc.]) vorfinden können:
Mit der v2.9 haben wir beim Tabellen-Objekt nun ein Dropdown zur Filterung von Einträgen. Ich nehme das für die SSL-Zertifikate gleich mal so mit auf.
Um alle Verträge zu finden, bei denen PHP in der Standardversion konfiguriert ist:
grep '/php7/' /etc/apache2/sites-enabled/*.conf
Alternativ geht das über eine Datenbankabfrage:
SELECT SD_HOST, D_NAME, WR_VERSION
FROM SUBDOMAINS, DOMAINS, WEBRUNTIMES
WHERE SD_DOMAINID=D_ID AND SD_PHPVERSIONID=WR_ID
ORDER BY D_NAME, SD_HOSTViele Grüße
-Klaus Keppler
Eventuell sollte man die Entscheidung selbst fällen können.
Immerhin gibt es doch schon das Dropdown-Feld, dort müsste nur der LE-Account
des Kunden mit rein und noch die Option geschaffen werden, den default-Wert zu wählen.
Das sehen wir etwas kritischer.
Wenn der Kunde eine eigene (ggf. externe) Domain oder eine Subdomain anlegt, dann soll er dafür einen ggf. eigenen Let's-Encrypt-Account auswählen können.
Wenn Sie als Admin aber eine Domain dem Vertrag des Kunden hinzufügen, dann dürfen Sie nicht einfach dessen Account nutzen (oder - mal überspitzt gesagt - liegt Ihnen eine Nutzungsgenehmigung vor, dass Sie über dessen LE-Account Zertifikate einrichten dürfen?)
Anders gesagt: Sie legen als Admin dort eine Domain an, dann sollte das Zertifikat auch über den LE-Account des Admins angefordert werden.
Ist also keine technische Einschränkung, sondern administrativ so gewollt.
Und noch einmal: wenn ein Kunde enen eigenen LE-Account hat, dann liegt es in dessen Verantwortung, wenn es Probleme damit gibt.
Wir hatten tatsächlich schon Fälle, wo Kunden einen LE-Account mal generiert hatten, den auf mehreren Server genutzt und dann irgendwo den Account mal dicht gemacht hatten (ich glaube via Certbot). Das hat dann Stunden gedauert um herauszufinden, warum die SSL-Zertifikate dieses Kunden auf einem völlig anderen Server nicht mehr verlängert werden konnten.
Stunden, die man sich ganz bequem ersparen kann. 
Ich denke das ist derzeit eher verwirrend für den Kunden. Sieht er unter SSL kein Zertifkat, wundert er sich --> und wieder kommen Support-Mails, wie: "Wo ist das Zertifikat?" "Warum ist kein Zertifikat sichtbar" ...
Wo "unter SSL" meinen Sie? Bei den Subdomain-Einstellungen?
Dann würde es da evtl. Sinn machen, wenn LiveConfig das entweder gar nicht erst anzeigt, oder wir irgendeine Bestellmöglichkeit schaffen.
Das Ziel ist ganz klar, dass der Endkunde eigentlich gar nichts mehr von irgendwelchen "Zertifikaten" sieht. Wir (Tekkies, Admins, Entwickler usw.) wissen was ein SSL-Zertifikat ist. Die meisten Hosting-Endkunden wissen das nicht und wollen damit auch nichts zu tun haben - "die Website soll verschlüsselt sein".
An Let's-Encrypt-Zertifikaten ist nichts verdient (die Kunden wissen schließlich, dass diese Zertifikate kostenfrei sind). Aber das bedeutet nicht, dass diese Zertifikate keine Arbeit machen (= also doch Kosten verursachen!)!
Sobald Kunden die Möglichkeit haben, selber irgendwie Zertifikate (über eigene LE-Accounts) anzulegen, werden zwangsläufig Support-Anfragen kommen.
Es gibt immer die Möglichkeit, über die Berechtigung "SSL-Verwaltung" dem Kunden diesen Bereich zur Verfügung zu stellen. Ich denke aber es ist wesentlich sinnvoller, die Verarbeitung der kostenlosen und automatisierten Zertifikate für die "restlichen" 99% der Kunden so zu gestalten, dass weder der Admin damit irgendeine Arbeit hat noch der Endkunde da irgendeinen Quatsch anstellen und somit Supportanfragen generieren kann.
(und glaubt mit - Quatsch gibt es genug - ich bin selber überrascht, was für Sachen uns in den letzten zwei Jahren da so berichtet wurden...)
Übrigens gab es auch mit der CA diese Diskussion (soll man lieber pro Kunde oder lieber pro Server einen LE-Account einrichten). Fazit war ganz klar: Account pro Server. Es gibt Accounts-Limits pro Server, aber keine Zertifikats-Limits pro Account.
Trotzdem vielen Dank für die Rückmeldungen - einige Sachen werden noch weiter verbessert.
Viele Grüße
-Klaus Keppler
