Beiträge von kk

Nutzen Sie unsere PHP-Pakete für Debian/Ubuntu?
Die enthalten derzeit keine PostgreSQL-Treiber. Können wir aber bei Bedarf gerne mit aufnehmen.

Zitat von Febas

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_HOST

Viele Grüße

-Klaus Keppler

Zitat von tfi

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.

Zitat von weltmeister

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

Zitat von WebOscar

Die würde aber - gäbe es sie - einen expliziten Eintrag in den DNS-Einstellungen des Kunden nötig machen. Und das soll so nicht sein.

Hmm, verstehe.
Haben denn ausnahmslos *alle* Domains einen externen MX vorgeschaltet? Wenn wir keine Ausnahmen für einzelne Domains brauchen, könnte ich mir eine Lösung via LCDEFAULTS vorstellen.

Zitat von antondollmaier

Die bei den A/AAAA-Records vorhandene Checkbox gibt es für den MX-Eintrag (noch) nicht.

Wird im kommenden Release (v2.9.0) enthalten sein. Diesen Request gibt es inzwischen von weiteren anderen Seiten.

Zum Autodiscover: wir sind dabei die bisherige Anleitung etwas zu vereinfachen - an der grundsätzlichen Anforderung einer quasi "dedizierten" IP-Adresse ohne Programm auf Port 443 lässt sich aber nichts ändern (nicht so lange man noch mit "alten" Outlook-Clients zu tun hat).

Eine Support-Anfrage hat uns bislang nicht erreicht.

Die o.g. Fehlerbeschreibung deutet darauf hin, dass der PHP-CLI-Umgebung irgendetwas fehlt, um die Installation abschließen zu können.
Gibt es eine Log-Datei /var/www/<vertrag>/logs/appinstall.log mit weiteren Informationen, oder steht evtl. etwas in /var/log/liveconfig/liveconfig.log, wenn eine Anwendung installiert wird?

Viele Grüße

-Klaus Keppler

Hallo,

unsere Debian-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.1.33, 7.2.24 und 7.3.11 aktualisiert.

Die Download-Links im Wiki werden wir in Kürze übrigens entfernen, da diese bislang noch nicht automatisiert aktualisiert werden können (die Pflege ist dann recht mühselig).
Zum Jahresende planen wir da eine neue Lösung - Details folgen.

Viele Grüße

-Klaus Keppler

Das wird mit der nächsten Version (2.9.0) korrigiert - da gibt es dann auch bei den automatisch verwalteten SSL-Zertifikaten (wieder) die Checkboxen, um HTTPS automatisch zu konfigurieren.

Viele Grüße

-Klaus Keppler

Die sauberste Lösung wäre der jeweils eigene Ordner pro Postfach.
Wir können das relativ einfach ins LiveConfig mit aufnehmen, so dass das Verzeichnis beim Erstellen/Bearbeiten eines Postfachs automatisch erzeugt und beim Löschen entsprechend entfernt wird.
Ich nehme das gleich als Change Request auf, dürfte im nächsten Preview-Update enthalten sein (steht dann im Changelog).

Viele Grüße

-Klaus Keppler

PS: nach wie vor bin ich der Überzeugung, dass Bayes-Filter wesentlich überbewertet sind - Mails die erst mal so weit gekommen sind, können nur relativ unscharf klassifiziert werden.

LiveConfig arbeitet da eigentlich mit "UPDATE user SET authentication_string=...".
Wir werden das mal durchtesten - ich melde mich dann noch mal.

Viele Grüße

-Klaus Keppler

Zitat von BMK-Media

Das kann so ja nicht stimmen, denn die Verträge, bzw. Kunden sind doch nicht separate Partitionen. (/var/www/web1, /var/www/web2 ....)
Denn dann müsste die Liveconfig ja bei jedem neuen Kunden die Systempartition anfassen um zu verkleinern. Und solche eingriffe wären zu gefährlich, daher glaube ich nicht das es so gelöst ist.

Es hat doch niemand behauptet, dass jeder Vertrag eine eigene Partition hat.
Das Quota wird pro Partition verwaltet. Je nach Partitionierung des Systems ist das also z.B. global, oder nur für /var/ oder /var/www/ usw...
Führen Sie einfach mal den Befehl "repquota -ag" aus. Sie erhalten dann eine Liste aller Partitionen mit den dort jeweils gesetzten Quotas.

Zitat

Ja aber die wenigsten interessieren sich für die LOG, aber beschwären sich dann wenn die Seite wegen Error 500 (OPCACHE) nicht mehr erreichbar ist.

Der Opcache ist eine Sache, die im User-Space läuft. Wenn dieser Dateien erzeugt, dann sind die logischerweise auch dem Kunden zuzurechnen.
Wenn der Platz ein Problem ist, muss der Kunde eben entweder mehr Platz buchen, oder das Caching abschalten (oder die Caching-Dauer verringern).

Zitat

Außerdem bin ich der Meinung, sollten die Logs nicht den Speicherplatz verbrauchen die der Kunde gebucht hat.

Die vom System erzeugten Logs (access.log, error.log) gehören dem root-Benutzer und werden dem Kunden somit auch nicht zugerechnet.
Wenn der Kunde darüber hinaus weitere Logs erzeugt (entweder von seiner eigenen Anwendung, oder z.B. das php_error.log), dann sind das auch wieder Sachen die der Kunde zu verantworten hat und die somit legitim seinem Speicherplatz zugeordnet werden müssen.

Viele Grüße

-Klaus Keppler

Ab LiveConfig 2.9.0 kann man nun über eine Lua-Variable LC.web.PHPCLI den PHP-Interpreter ändern, den der AppInstaller verwendet.
Bei Bedarf also eine Datei wie z.B. "/etc/liveconfig/lua.d/phpcli.lua" anlegen, und dort folgende Zeile eintragen:

LC.web.PHPCLI = '/opt/php-7.3/bin/php'

Die entsprechende v2.9.0-Preview wird Anfang kommender Woche bereitgestellt.

Viele Grüße

-Klaus Keppler

Zitat von antondollmaier

Kann der Post so ins Handbuch?

Hmm, guter Hinweis - ich gebe das gleich weiter.

Zitat

Und: danke für die Preview - auch wenn ich den Versions-Sprung auf 2.9 (im Vergleich zu den gravierenden Änderungen 2.7->2.8) nicht so ganz nachvollziehen kann.

Mit v2.9 gab es auf unserer Seite gravierende Änderungen, u.a. haben wir die komplette Codeverwaltung von SVN auf Git umgestellt - an den Build-Prozessen hat sich also viel geändert. Details dazu plane ich nächste Woche (mit dem nächsten Preview-Update) ausführlicher zu beschreiben.
Und 'n paar weitere nette Features stecken auch gerade in der Release-Pipeline für v2.9.

Viele Grüße

-Klaus Keppler

Zitat von lchel

<ADDRESS> ist eine IPv6 Adresse. Der Server hat eine IPv4 und eine IPv6 Adresse. Wenn ich die IPv6-Adresse auf dem DNS lösche, funktioniert die automatische Verlängerung. Aber das ist nicht der wahre Jakob. Schließlich soll auch IPv6 funktionieren und hat auch bis vor ca. einem Monat funktioniert.

Da wird es höchstwahrscheinlich eine Inkonsistenz gegeben haben.
Am einfachsten Fall können Sie das prüfen, indem Sie im LiveConfig (als "Kunde") auf "Hosting" -> "Domains" gehen und dort die betroffene (Sub)Domain anklicken.
Es öffnet sich das Popup mit den (Sub)Domain-Einstellungen. Dort wird angezeigt, mit welchen IP-Adressen die Domain im LiveConfig konfiguriert ist (über die entsprechenden IP-Gruppen). Eventuell war die IPv6-Adresse nicht in der gewählten IP-Gruppe enthalten.

Zitat von lchel

<ADDRESS> ist eine IPv4 Adresse und der Server ist eine AWS EC2 Instanz. <ADDRESS> ist die externe IP-Adresse des Servers, die aber naturgemäß nicht der lokalen IP des Servers entspricht.

Das lässt sich über die LiveConfig-Datenbank (Tabelle IPS, Spalte IP_NAT) lösen. Wir werden das Verhalten mit LiveConfig v2.9 aber so ändern, dass bei erkanntermaßen "privaten" IPv4-Adressen kein DNS-Check mehr ausgeführt wird, sofern keine NAT-IP konfiguriert ist.

Falls Sie aktuell noch Probleme haben, schicken Sie uns bitte mal einen betroffenen Domainnamen samt exakter Fehlermeldung an support@liveconfig.com, dann werfen wir da auch mal ein Auge drauf.

Viele Grüße

-Klaus Keppler

Zitat von TCRserver

Aber gegen welche IP Adresse validiert LC es, also welche http-Server Adresse?

Wenn LiveConfig ein automatisiertes SSL-Zertifikat für "example.org" einrichten soll, passiert Folgendes:

• LiveConfig prüft, ob die Domain "example.org" überhaupt angelegt ist (also irgendein Vertrag mit dieser Domain existiert).
• Wenn ja, dann wird geprüft, ob der zugehörige Kunde/Vertrag/Webspace auch aktiviert ist.
• Wenn ja, dann sucht LiveConfig die IP-Adressen dieses Webspaces heraus (also die Adressen, mit denen effektiv die vHost-Konfiguration erzeugt wird).
• dann macht LiveConfig eine "externe" DNS-Abfrage (sprich: nutzt den eingebauten Resolver oder - falls nicht möglich - den Resolver des Servers) um herauszufinden, mit welchen IPs denn der verantwortliche DNS-Server tatsächlich antwortet.
• Zum Schluß wird abgeglichen, ob die Liste der tatsächlichen IPs mit der Liste der konfigurierten IPs (bzw. der NAT-IPs) übereinstimmt. Wenn nicht, dann gibt es eine entsprechende Fehlermeldung.

Der durch LiveConfig durchgeführte DNS-Check hat mehrere Vorteile, u.a.:

• sollte eine Domain falsch konfiguriert sein (die Klassiker: falsche IP-Adresse hinterlegt, Domain inzwischen umgezogen, Tippfehler im Domainnamen, ...) dann hat man gleich eine brauchbare Fehlermeldung
• die Anzahl der ungültigen Domainvalidierungen bleibt somit gering, die Gefahr in Probleme seitens Let's Encrypt zu rauschen wird somit verringert.

Viele Grüße

-Klaus Keppler

Mit LiveConfig v2.9.0 gibt es bei den SSL-Zertifikaten (Tab "Optionen") nun eine Checkbox, um die DNS-Prüfung in Einzelfällen zu deaktivieren - z.B. eben wenn ein CDN zum Einsatz kommt.

Die Preview wird voraussichtlich am Montag entsprechend aktualisiert.

Viele Grüße

-Klaus Keppler

Zitat von TCRserver

Meine Vermutung war, dass der LC DNS-Resolver bei Servern mit NAT gegen die interne IP-Adresse geprüft hat und nicht gegen die öffentliche Adresse.
Ich habe es aber nicht weiter verfolgt, da wir eh umstellen wollten.

LC führt ein ungecachtes Resolving (also ohne "externe" DNS-Resolver) durch, um die öffentlich hinterlegte IP einer Domain herauszufinden.
Wenn LC keine eigenen DNS-Anfragen ausführen kann (z.B. weil Port 53 outbound blockiert), dann nutzt es den im System konfigurierten DNS-Resolver.

Eine mögliche Erklärung wäre natürlich, dass der DNS-Resolver andere Daten zurückliefert als erwartet - in diesem Fall also z.B. die private statt der öffentlichen IP-Adresse. Das müsste man mal im konkreten Einzelfall prüfen.