Beiträge von kk

Zitat von BMK-Media

Ah ok, das wusste ich nicht, habe es auch nicht in den Changelogs gefunden, das sich die bind.lua bzw dns.lua geändert hat.

Da hat sich auch nichts geändert. Wie gesagt - der genannte Code-Schnipsel kann in dieser Form noch nie funktioniert haben.

Zitat

Naja in den Optionen nicht, ich möchte am ende include "/etc/named/log.conf"; hinzufügen. Wir hatten das Logging selbst aufgeteilt und deswegen stand es bei uns auch so drin, dann wurde aber die Config von der Liveconfig neu geschrieben und ist seit dem weg.

Ich vermute vielmehr, dass die Änderung direkt in die BIND-Konfiguration eingetragen wurde und zusätzlich noch die Änderung in der custom.lua vorgenommen wurde (die faktisch aber nie funktioniert haben kann).

Tragen Sie Ihre include-Anweisung doch einfach in die named.conf.local ein, die wird von LiveConfig nicht angefasst.

Viele Grüße

-Klaus Keppler

Zitat von ap24

Seit LiveConfig 2.10 werden im Homeverzeichnis des Benutzers folgende Dateien mit angelegt:

Code

/var/www/web111
-rw-r--r--   1 web111 web111    18 Apr  1  2020 .bash_logout
-rw-r--r--   1 web111 web111   193 Apr  1  2020 .bash_profile
-rw-r--r--   1 web111 web111   231 Apr  1  2020 .bashrc

Der Fehler ist mit LiveConfig v2.10.4 behoben (Update erscheint morgen). Unter CentOS/RHEL wurde beim Aufruf von "adduser" die Option "-M" nicht mehr übergeben, dadurch wurde beim Anlegen von Systembenutzern das System-Skeleton-Verzeichnis verwendet.

Zitat von Febas

Die Option "auch 'www'-Subdomain erstellen" fehlt hier noch. Wenn man eine Domain per API anlegt, wird die www-Subdomain nicht angelegt. Wenn man per API (HostingSubdomainAdd) die www-Subdomain anlegt, dann wird die Domain und die Subdomain www separat dargestellt, so wie es sonst in der Experten-Ansicht üblich ist, obwohl Standard-Ansicht aktiv ist.

Guter Hinweis, werden wir mit einem der nächsten Updates anpassen. Auch für die automatisierte SSL-Bestellung macht das Sinn.

Hallo,

Zitat von BMK-Media

Seit dem Update geht unsere custom.lua nicht mehr

Der nachfolgend beschriebene Fehler wird so definitiv auch mit früheren LiveConfig-Versionen aufgetreten sein. Weil...:

Zitat

Beim Testen via lclua zeigt er folgendes an

Code

Can't run /usr/lib/liveconfig/lua/custom.lua: /usr/lib/liveconfig/lua/custom.lua:3: attempt to index global 'bind' (a nil value)

Das hat damit zu tun, dass die "custom.lua" automatisch durch das lclua-Programm geladen wird (lclua lädt u.a. die liveconfig.lua, und die wiederum die custom.lua)

Sie können die custom.lua also nicht direkt via lclua ausführen. Schreiben Sie ein leeres Testscript (leere Datei) und führen diese mit lclua aus - die custom.lua wird da automatisch mit geladen.

Zitat

Und in der Liveconfig -> Serververwaltung -> DNS beim neustarten von BIND steht:

Code

/usr/lib/liveconfig/lua/custom.lua:9: attempt to index global 'fh' (a nil value)
stack traceback:
    /usr/lib/liveconfig/lua/custom.lua:9: in function 'configure'
    /usr/lib/liveconfig/lua/dns.lua:228: in function

Es handelt sich um folgenden Abschnitt:

Code

3:  orig_bind_configure = bind.configure
4:  
5:  function bind.configure(cfg, opts)
6:  
7:          orig_bind_return = orig_bind_configure(cfg, opts)
8:  
9:          fh:write("include \"", configpath, "/log.conf\";\n")
10:         return orig_bind_return
11:
12: end

"fh" ist eine lokale Variable (Filehandle), die in der hier aufgerufenen Funktion gar nicht (mehr) existiert. Das wird so nicht funktionieren.
Möchten Sie eigene Einstellungen in die BIND-Konfiguration aufnehmen? Wenn es im "options"-Abschnitt sein soll, nutzen Sie die dokumentierte Tabelle. Allgemeine Einstellungen können Sie direkt in die /etc/bind/named.conf.local eintragen.

Viele Grüße

-Klaus Keppler

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.3.24, 7.4.12 und 8.0.0RC3 aktualisiert.
Für PHP 8 steht inzwischen auch die APCu-Extension bereit (php-8.0-opt-apcu)

In rund vier Wochen (am 26.11.2020) soll PHP 8 dann freigegeben werden.

Viele Grüße

-Klaus Keppler

Hallo,

ab sofort steht LiveConfig v2.10.2 zum Download bereit.

Die neue Version enthält hauptsächlich Detailverbesseungen und Fehlerbehebungen - die vollständige Liste der Änderungen finden Sie wie immer im Changelog.

Viele Grüße

-Klaus Keppler

Das Logo steckt in der Ressourcendatei von Let's-Encrypt-Modul, da kommt man nicht sooo einfach ran.
Um eine weitere CA aufzunehmen, einfach die Spalte SP_LOGO in der Datenbank leer lassen (dann wird da kein Logo angezeigt).

Die Fehlermeldung ist recht allgemein; kann z.B. auch dann auftreten wenn Kunden ihren Mailclient falsch konfiguriert haben (etwa wenn ein Kunde Port 110 auswählt, statt STARTTLS da aber SSL einstellt).
Schicken Sie uns bitte mal den Namen Ihres Mailservers an support@liveconfig.com, dann testen wir das mal soweit wie möglich von außen durch.

Viele Grüße

-Klaus Keppler

Was haben Sie denn vor? Das Let's-Encrypt-Logo als SVG-Datei finden Sie im Internet.
Modifizieren dürfen Sie das Let's-Encrypt-Logo aus rechtlichen Gründen jedenfalls nicht, und austauschen vermutlich auch nicht.

Und wie Templates in LiveConfig funktionieren ist hier beschrieben:
https://github.com/LiveConfig/templates

Viele Grüße

-Klaus Keppler

Hallo,

seit einigen Wochen stellen wir für Debian & Ubuntu die ersten PHP8-Pakete bereit (Beta bzw. Release Candidate).

Die PHP8-Pakete wurden nun auf Version 8.0.0-RC2 aktualisiert.
Allerdings sind einige PHP-Erweiterungen noch nicht für PHP 8 vorbereitet, konkret z.B. ImageMagick oder Redis. Wir werden diese Pakete nachliefern, sobald diese kompatibel sind.

PHP 8.0 soll am 26. November 2020 freigegeben werden.
Am 30. November 2020 endet wiederum der Security-Support für PHP 7.2.

Viele Grüße

-Klaus Keppler

Also, der Datenbankbenutzer wird erst dann gelöscht, wenn ihm keine Datenbanken mehr zugewiesen sind. Ist insofern also kein Problem, den selben Benutzer für mehrere Datenbanken zu verwenden.

Viele Grüße

-Klaus Keppler

Ich denke wir haben die Ursache gefunden. LiveConfig prüft über das Schema der Benutzerdatenbank, wie die Passwörter zu aktualisieren sind. Wenn z.B. MariaDB von 10.3 auf 10.4 aktualisiert wurde, dann kann das zu einer "falschen Entscheidung" führen.
Ein Update ist gerade in Arbeit, ich gebe Bescheid sobald es bereit steht.

Sie können den Status auf "Datenbank erfolgreich angelegt" setzen:

UPDATE DBS SET DB_STATUS=1 WHERE DB_NAME='usr_web30_2';

Problematisch wird es aber, wenn via LiveConfig die erstbeste Datenbank des Benutzers "web30" gelöscht wird - dann wird dieser Benutzer nämlich mit gelöscht.
Ich kläre das gleich mal ab; LiveConfig müsste vor dem Löschen eines Benutzers lediglich prüfen, ob er ggf. noch weitere Datenbanken hat.

Ich habe das eben mit LiveConfig 2.10.1 und MariaDB 10.4.14 unter CentOS 8 getestet - klappt einwandfrei.
Datenbank in LiveConfig angelegt, Anmeldung mit mysql-Cient (via SSH) getestet, klappt.
Datenbankpasswort via LiveConfig geändert, dann wieder via mysql-Client angemeldet, klappt auch.

Handelt es sich bei Ihnen um eine Multi-Server-Installation, oder läuft der Datenbankserver lokal?
Wie haben Sie die Anmeldung getestet? Nur via phpMyAdmin oder auch mal lokal (mit dem mysql-Client)?

Wir haben das Repository heute neu signiert (da der alte Schlüssel ja zum 19.09. abgelaufen ist), die Daten müssen noch synchronisiert werden.

In ca. 30 Minuten sollte wieder alles fehlerfrei funktionieren.

Wir haben das Repository eben aktualisiert, nun steht v2.10.1 zum Download bereit, welche diesen Fehler behebt. Bitte einfach das Update einspielen, dann stimmen die Berechtigungen wieder.

Hintergrund war: die Funktion, welche ggf. die OpCache-Verzeichnisse anlegt (also falls "opcache.file_cache" verwendet wurde und daraufhin ein passendes Verzeichnis angelegt werden musste), rief eine Bibliotheks-Funktion auf, welche wiederum die sogenannte "umask" des Prozesses auf einen zu großzügigen Wert gesetzt hatte. Andere Konfigurationsdateien, die danach vom selben Prozess erzeugt wurden, hatten somit möglicherweise zu offene Berechtigungen.
Das Update (v2.10.1) behebt diesen Fehler und aktualisiert automatisch in diesem Fall alle von einer v2.10.0 geschriebenen Dateien, so dass die Berechtigungen wieder passen.

Ok, danke für die Rückmeldung.
Kurzfristige Lösung: chmod 0600 /etc/logrotate.d/liveconfig-vhosts

Wir prüfen eben wo/warum diese Berechtigung gesetzt wird, ich gebe dann gleich noch mal Bescheid.

Das betrifft offenbar die Datei /etc/logrotate.d/liveconfig-vhosts. Diese hat aber schon immer den Mode 0600, daher kann das mit dem LiveConfig-Update nichts zu tun haben.
Ich höre von dieser Meldung eben auch zum ersten Mal. Was genau liefert denn der Befehl

ls -l /etc/logrotate.d/liveconfig-vhosts

und welche Linux-Distribution/-Version läuft auf dem Server?

Ich habe den Beitrag in ein neues Thema verschoben, es bringt nichts solche Fragen an 8 Jahre alte andere Beiträge anzuklemmen.

Zum Problem: nein, es gibt keine neueren Versionen. Ein lauffähiges Beispiel finden Sie in der LiveConfig-Demo (als admin/admin anmelden).
Die IFRAME-API wird von vielen Kunden aktiv genutzt, der Fehler wird also vermutlich in Ihren Scripten/Webseiten liegen.
Starten Sie als Basis einfach mit den von uns bereitgestellten Beispielen (examples-20120814.zip).

Viele Grüße

-Klaus Keppler

Ab sofort steht LiveConfig v2.10 bereit.
In den "Release Notes" gehen wir dabei auch auf den OpCache ein:

https://www.liveconfig.com/de/blog/2020/09/liveconfig-v2.10/

Viele Grüße

-Klaus Keppler