Beiträge von Marco

Hallo,

mal eine Frage in die Runde, da ich mich gerade mit einem Problem herum plage.

Ein Kunde hat in seinem Vertrag die Funktion "Passwort-geschützte Verzeichnisse" verwendet. Nun kommt die Aussage, dass diese Funktion nach gewisser Zeit die Möglichkeit des Logins verliert.

Eine erste Kontrolle ergab, dass nach gewisser Zeit ein Anmelden wirklich nicht mehr möglich ist. Apache meldet als Fehler "AH01631: user BENUTZER1: authorization failure for /UNTERORDNER/:".

In LiveConfig eingestellt ist folgende Konfiguration:

- Verzeichnis: /htdocs/ORDNER/UNTERORDNER

- Titel: eine Beschreibung

- Benutzer: BENUTZER1, BENUTZER2, BENUTZER3

Dies existiert 4x für verschiedene UNTERORDNER mit teilweise wechselnden Benutzern. In der Datei .htpasswd existieren diese Benutzer auch alle.

Die weitere Suche führt dann zu der Webserverkonfiguration für diesen Vertrag. Dort stehen die vier geschützten Bereiche unter dem Kommentar "password-protected directories". Teilweise fehlen aber in der Zeile "Require user" die angelegten Benutzer. Bei einem Verzeichnis werden die beiden aktiven Benutzer aufgeführt, bei den anderen wird nur ein Benutzer aufgeführt, obwohl dort zwei oder drei Benutzer stehen sollten.

Nächste Stelle ist die LiveConfig Datenbank, dort die Einträge bei PWUSERS, PWPATHS und PWPATHUSERS. Dort sind alle angelegten Benutzer eingetragen. Ebenso die zu schützenden Verzeichnisse. Auch das Mapping unter PWPATHUSERS stimmt mit den Einstellungen überein. Somit scheint hier das Problem nicht zu liegen.

Letzter Ort meiner Suche, die Datei apache.lua von LiveConfig, die das Anlegen der Konfigurationsdatei übernimmt. Diese hab ich mit einer einfachen Ausgabe erweitert, die mir die Werte für "pwpath" und "[pwpath].users[i]" ins Logfile ausgeben.

Das Ergebnis dort:

[LUA] PWPATH /htdocs/ORDNER/UNTERORDNER4
[LUA] PWUSER BENUTZER3

[LUA] PWPATH /htdocs/ORDNER/UNTERORDNER3
[LUA] PWUSER BENUTZER1
[LUA] PWUSER BENUTZER2

[LUA] PWPATH /htdocs/ORDNER/UNTERORDNER1
[LUA] PWUSER BENUTZER4

[LUA] PWPATH /htdocs/ORDNER/UNTERORDNER2
[LUA] PWUSER BENUTZER1

Somit fehlen bei UNTERORDNER1 zwei weitere Benutzer und bei UNTERORDNER4 ein weiterer Benutzer beim Durchlauf der Konfigurationserstellung.

Die Aussage des Kunden mit dem Vergessen ist auch stimmig. Ändere ich einen Benutzer (Entfernen, Anlegen oder Kennwortänderung), dann ändern sich auch die verwendeten Benutzer in der Konfigurationsdatei. Der bearbeitete Benutzer kann sich dann anmelden, der vorherige nicht mehr.Änderungen an sonstigen Einstellungen, z.B. Domaineinstellungen, führen zu keinen anderen verwendeten Benutzern.

Sitzen wir hier seit ewiger Zeit auf einem Bug? Oder habe ich hier etwas übersehen?

Hallo,

mit einer Partition namens sda1 sollte es keine Probleme geben. Das Prinzip bei der Datei fstab ist immer das selbe. Bei der betroffenen Partition das vorhandene "defaults" oder "errors=remount-ro" gegen ein "errors=remount-ro,grpjquota=aquota.group,jqfmt=vfsv0" austauschen.

Zusammengefasst steht auch alles unter https://www.liveconfig.com/de/kb/quota/

Hallo,

die erste Zeile sollte dann lauten

/dev/vda2 / ext4 errors=remount-ro,grpjquota=aquota.group,jqfmt=vfsv0  1  1

Bedingung ist aber, das das Paket "quota" auf dem System installiert ist. Nach Änderung der Datei fstab dann den Befehl ausführen.

mount -vo remount /dev/vda2

Hallo,

die Einrichtung eines Mailsystems unter Debian Bookworm und LiveConfig läuft eigentlich problemlos. Damit meine ich Postfix und Dovecot. Roundcube ist dann ein weiterer Schritt, den man vornehmen müsste, wenn der Bedarf vorhanden ist.

Postfix/Dovecot

Nach der Installation von LiveConfig muss man alle benötigten Dienste aktivieren. Dies geschieht unter dem Login "admin" im Menüpunkt "Serververwaltung", hier dann das Register "E-Mail". Sobald man Postfix bzw. Dovecot aktiviert hat, kann man die Feineinstellung vornehmen. Unter Postfix wäre hier z.B. ausgehende IP Adresse, SSL Zertifikat oder Funktionen wie Spamassassin, ClamAV oder DKIM ratsam. Bei Dovecot dann ebenso SSL Zertifikat.

lcsam lässt sich nur aktivieren, wenn unter Postfix die Verwendung von ClamAV oder Spamassassin aktiv ist. Dazu auf der Kommandozeile folgende Befehle ausführen.

systemctl enable spamd 
systemctl enable clamav-daemon
systemctl enable lcsam

Danach sind zumindest bei mir immer alle Funktionen für E-Mails gegeben.

Roundcube

Die Webmailfunktion wird nicht direkt in LiveConfig eingebunden, sondern muss in einem Vertrag wie eine normale Webseite eingerichtet werden. Dort lässt es sich dann einfach als Anwendung installieren. Unter Umständen muss man nach der Installation noch in der Konfiguration Einstellungen anpassen. Dies könnte dann vor allem die Werte für "smtp_server" und "smtp_port" betreffen.

Zugriff über https lässt sich hier wie bei jeder Webseite einfach über "Domains" steuern. Ist für die Domain ein SSL Zertifikat vorab schon eingerichtet, dann kann sich LiveConfig bei der Installation von Anwendungen etwas widerspenstig verhalten. Mir ist es schon häufiger passiert, dass LiveConfig dann nur die Anwendung für http aktiviert hat, aber die Einstellungen für https auf Webspace stehen ließ. Hier also nach der Installation sicherheitshalber die Domaineinstellungen kontrollieren.

Ich hoffe, dass dies deine Probleme beheben wird.

Das Problem dürfte weniger vom Server selbst stammen.

repo.liveconfig.com wird im Regelfall zweimal angesprochen. Einmal mit dem Zusatz "main" für die Liveconfig Pakete, einmal mit dem Zusatz "bullseye" für die optionalen PHP Pakete.

In der Fehlermeldung tritt das Problem aber nur beim Zugriff auf "http://repo.liveconfig.com/debian main" auf, während der Zugriff auf "http://repo.liveconfig.com/debian bullseye" erfolgreich war.

Meine Vermutung ist, dass hier ein Problem bei der Signierung der allgemeinen Pakete vorliegt. Und das kann dann wohl nur Keppler IT lösen.

Das Problem wird auch unter Aktualisierung/Modernisierung des Repository-Keys geschildert. Vielleicht sollte man dies auch dort weiterführen.

Hallo,

nach dem Einspielen des Paketes "liveconfig-keyring" wurde auf dem System die Datei wie folgt geändert:

deb [signed-by=/usr/share/keyrings/liveconfig-keyring.gpg] http://repo.liveconfig.com/debian/ main main

# For Debian Linux 11 ("bullseye"):
deb [arch=amd64 signed-by=/usr/share/keyrings/liveconfig-keyring.gpg] http://repo.liveconfig.com/debian/ bullseye php

Damit erfolgt bei einem "apt update" keine Fehlerausgabe.

Hallo,

ich meine, etwas ähnliches schon mal erlebt zu haben. Dabei handelte es sich um einen Vertrag, der unter einem Resellervertrag erstellt wurde. Im Resellervertrag war dann selbst kein PHP ausgewählt.

Ansonsten müsste man die Grundkonfiguration von LiveConfig kontrollieren, ob hier überhaupt PHP richtig eingebunden ist. Unter dem Adminlogin bei Serververwaltung - Web sollte bei PHP-Versionen zumindest eine Version gelistet sein. Alternativ auf der Kommandozeile "liveconfig --diag" ausführen und nachsehen, ob PHP Versionen erkannt werden.

Ebenso kontrollieren sollte man unter Serververwaltung - Web die eingerichteten Module des Webservers. Evtl. ist hier ein benötigtes Modul gar nicht aktiv.

Hallo,

das Problem liegt an unterschiedlichen Ausgaben bei Aufruf von "getBinaryVersion(bin)".

Debian:

:~# /usr/bin/mariadb -V
/usr/bin/mariadb  Ver 15.1 Distrib 10.11.4-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper

MariaDB:

:~# /usr/bin/mariadb -V
/usr/bin/mariadb from 11.2.2-MariaDB, client 15.2 for debian-linux-gnu (x86_64) using  EditLine wrapper

Da in der Funktion "getBinaryVersion(bin)" nach "Distrib" bzw. "Ver" geschaut wird, liefert die Ausgabe bei MariaDB keinen Treffer.

Quick and Dirty Lösung:

In der Datei mysql.lua in der Funktion "getBinaryVersion(bin)" das "Ver " entfernen. Dann sollte die Erkennung funktionieren.

Sinnvoller wäre, wenn dieser Unterschied der Textausgabe von den Entwicklern sauberer eingepflegt wird.

Hallo,

der AppInstaller für ownCloud hat auf Debian 11 (Bullseye) einen Fehler. Beim Versuch der Einrichtung kommt am Ende immer Status "Fehler: failed execute installer (errorcode: 1)".

Ursache ist eine fehlerhafte Erkennung der PHP Version in der Datei "/var/cache/liveconfig/installer/wai-owncloud-10.12.2-1.php". Dort ist ein Array enthalten, das Fundstellen für PHP vorgibt. Dieses Array wird Schritt für Schritt abgearbeitet, bei Fund einer vorgegebenen Version wird die Routine abgebrochen.

Auf dem System ist Debian 11 (Bullseye) eingerichtet, welches PHP 7.4 von Haus aus mitbringt. Daher ist auf dem System unter "/opt" kein php-7.4 eingerichtet. Bei der Erkennung kommt dann das unter "/opt" eingerichtete php-7.3 zum Zuge, welches zu ownCloud nicht mehr kompatibel ist. Die unter "/usr/bin/php7.4" installierte PHP Version wird dabei gar nicht mehr berücksichtigt.

Lösung: Da ownCloud nur mit PHP 7.4 lauffähig ist, sollten andere Versionen gar nicht erkannt werden.

  $phpSearch = array(
    '/opt/php-7.4/bin/php',
    '/usr/bin/php74',
    '/usr/bin/php7.4',
    '/usr/bin/php7',
    '/usr/bin/php',
  );

Eben aufgefallen.

Datei /usr/share/doc/liveconfig/db-mysql.sql.gz
Zeile 1627

ist:
RRA_MBID INTEGER NOT NULL,
soll:
RRA_MBID INTEGER UNSIGNED NOT NULL,

Hallo an alle,

besteht eigentlich die Möglichkeit, LiveConfig so zu konfigurieren, dass alle LiveConfig eigenen Mails über ein SMTP Konto versendet werden? Aktuell scheint LiveConfig diese Nachrichten ja nur direkt über eine interne Funktion zu versenden.

Und zur Klarstellung. Es geht nicht um E-Mails von Kunden auf dem System. Sondern um LiveConfig eigenen Nachrichten, die bei Kennwort zurücksetzen oder Zugangsdaten anfallen.

liveconfig.conf lässt ja nur Einstellungen im Bezug auf Datenbank oder HTTP/HTTPS zu, aber nicht für SMTP. Und gerade im Hinblick auf DKIM benötigt man ja die SMTP Unterstützung.

Die Reparatur hat es nun gelöst.

Beim Dienststart wurden dann auch die letzten Schritte der Aktualisierung durchlaufen.

Danke für die Unterstützung.

Zitat von kk

SQL

SELECT RRD_ARCHIVEID, RRD_SLOTID, COUNT(*)
FROM RRD_TRAFFIC
GROUP BY RRD_ARCHIVEID, RRD_SLOTID
HAVING COUNT(*) > 1

Die Ausgabe der Query ist leer.

Ich hatte auch vor dem Foreneintrag ähnliches versucht, um doppelte Einträge zu finden. Aber war ebenso ergebnislos.

Zitat von kk

SQL

DELETE r1 FROM RRD_TRAFFIC r1
JOIN RRD_TRAFFIC r2 ON (r1.RRD_ARCHIVEID = r2.RRD_ARCHIVEID AND r1.RRD_SLOTID=r2.RRD_SLOTID AND r1.RRD_TIMESTAMP < r2.RRD_TIMESTAMP);

Rückgabe: Error: near "r1": syntax error

Scheinbar gibt es auch unter SQLite manchmal Probleme mit dem Upgrade:

Upgrading database schema...
- /usr/sbin/liveconfig: Database driver loaded: SQLite (3.37.0)
- /usr/sbin/liveconfig: Upgrading database schema (r214002 -> 2.14.0-3)
- /usr/sbin/liveconfig: - migrating RRD_TRAFFIC
- /usr/sbin/liveconfig: Database connection failed: UNIQUE constraint failed: RRD_TRAFFIC_new.RRD_ARCHIVEID, RRD_TRAFFIC_new.RRD_SLOTID
dpkg: Fehler beim Bearbeiten des Paketes liveconfig (--configure):

Die vorliegende Datenbank habe ich schon überprüft, ob es hier Dupletten gibt. Soweit ich das sagen kann, sind die Werte UNIQUE.

Betraf auch nur einen von ca. 30 Servern, die aktualisiert wurden. Aber mit dem Problem lässt sich LiveConfig auch nicht mehr starten.

Hallo,

das ganze dient der Erweiterung des open_basedir.

Ich hab hier Systeme, da wird ein externer Datenspeicher eingebunden, der über Symlinks angesprochen wird. Nur kann PHP nicht darauf zugreifen, weil der Pfad mittels Symlink nicht frei gegeben ist.

Danke für die Antwort. Ich vermute, die web.lua wird dann bei Updates überschrieben?

Hallo an die Allgemeinheit,

vielleicht kann mir hier einer helfen. Ich suche eine Übersicht der Variablen, die in der php.ini gesetzt werden können.

Bekannt sind mir
%PHP% für die PHP Version
%HOME% für den absoluten Pfad, z.B. /var/www/web1

Gesucht wird speziell die Variable, die den Vertrag alleine kennzeichnet, als z.B. web321. %SUBSCRIPTION% ist es schon mal nicht

In der Doku und im Forum hab ich mit meiner Suche nichts gefunden.

Wäre es nicht ratsam, die von LC verwalteten Zertifikate unter z.B. /etc/liveconfig/certs abzulegen? Dann bleibt der /etc/ssl Ordner sauber und es kann nichts versehentlich gehasht werden.

Betrifft aber nicht nur das genannte 8d33f237.0, sondern viele weitere Dateien.
Aktuelles System bei mir:

lrwxrwxrwx 1 root root 20 Sep 24 2018 364f1228.0 -> 78db1beb7a05e7ca.crt
lrwxrwxrwx 1 root root 20 Sep 24 2018 4dad6171.0 -> 78db1beb7a05e7ca.crt
lrwxrwxrwx 1 root root 23 Sep 24 2018 4a0a35c0.0 -> 1056ded49ebf7fb0-ca.crt
lrwxrwxrwx 1 root root 23 Sep 24 2018 4f06f81d.0 -> 1056ded49ebf7fb0-ca.crt
lrwxrwxrwx 1 root root 20 Sep 24 2018 6547a221.0 -> fbfa1a8a4bd536ca.crt
lrwxrwxrwx 1 root root 20 Sep 24 2018 d426f497.0 -> fbfa1a8a4bd536ca.crt
lrwxrwxrwx 1 root root 20 Sep 24 2018 7ab1dbe1.0 -> ea542ef395cb04ca.crt
lrwxrwxrwx 1 root root 20 Sep 24 2018 b617eeea.0 -> ea542ef395cb04ca.crt

Zusätzlich kann auch 8d33f237.0 und 8d33f237.1 usw. vorliegen.

TCRserver

Das alte Zertifikat hast du auf deinen Systemen auch deaktiviert? Oder ist das noch in der Kette eingebunden?

sed -i 's/mozilla\/DST_Root_CA_X3.crt/!mozilla\/DST_Root_CA_X3.crt/g' /etc/ca-certificates.conf
update-ca-certificates

TCRserver

Auf den System hier habe ich keine Problem mit openssl. Nach Löschung der Verlinkungen konnte dies wieder problemlos verwendet werden.

Welche Begründung weist openssl bei einem Fehlschlag aus? Sollte bei "Verify return code" am Ende der Ausgabe oder bei "verify error" am Anfang stehen.