Beiträge von mjk

  • Veraltete Standard PHP-Version entfernen / aktualisieren

    Das Problem mit der installierten Version 5.6.40 bzw. liveconfig-meta Paket wurde zwischenzeitlich gelöst:



    Hier mussten lediglich vorab die angegebenen "php-*" Pakete installiert werden, bevor die veralteten Versionen entfernt werden konnten:


    Code
    apt install php-cgi php-curl php-gd php-imagick php-imap php-mysql php-sqlite3
apt remove php5-cli php5-cgi php5-common
apt auto-remove


    Jetzt taucht in LiveConfig die PHP-Version 7.4.33 als Standard-Version auf. Da das PHP-Paket innerhalb des liveconfig-meta Pakets als Abhängigkeit definiert ist, kommt man um die Installation wohl nicht herum. Gibt es denn zumindest die Möglichkeit, dieses in der Oberfläche für den Kunden auszublenden? Eine Checkbox wie bei den opt-Varianten ist in den Einstellungen leider nicht vorhanden.

  • Veraltete Standard PHP-Version entfernen / aktualisieren

    Wir haben heute einen Kundenserver auf einen aktuelleren OS-Stand gebracht (aktuell noch Debian 11). php-8.1-opt und php-8.2-opt sind über das LiveConfig Repository installiert, ältere opt-Pakete wurden entfernt. Allerdings hat dieses System seine ursprüngliche Standard PHP-Version bis heute beibehalten (5.6.40):


    Code
    - PHP 5.6.40 [DEFAULT] (code='php5')
CGI/FastCGI: /usr/bin/php-cgi
default php.ini: '/etc/php5/cgi/php.ini'
- default PHP CLI: /usr/bin/php


    Diese würden wir gerne am besten aus der LiveConfig-Auswahlliste sowie vom System entfernen. In einem Artikel aus der Wissensdatenbank (https://www.liveconfig.com/de/kb/debian-upgrade-8/) wurde eine Aktualisierung zwar beschrieben, stößt aber auf Probleme:



    Aus welchem Grund würde an dieser Stelle das Paket "liveconfig-meta" entfernt werden? Gibt es dort Abhängigkeiten, welche wir vorab auflösen müssen?


    Am besten wäre natürlich, wenn man zukünftig die PHP-Varianten ausschließlich über das LiveConfig-Repo beziehen und dort dann eine Standard-Variante bestimmen kann. Letzteres funktioniert ja bereits, allerdings taucht dann die vom Betriebssystem installierte Variante immer noch auf (welche bei Debian prinzipbedingt meist älter ist). Ein "switchen" der Standard-Version über die Oberfläche oder Config-Datei wäre ebenfalls wünschenswert, scheint aber aktuell wohl nur manuell mit SQL-Queries über die Datenbank direkt zu laufen - zumindest soweit ich das im Forum recherchieren konnte.

  • Sicherheitsabfrage vor Löschung / Undo-Funktion

    Hallo Herr Keppler,
    danke für die Anpassung der Maske, so schaut das schon wesentlich besser und eindeutiger für den Kunden aus! :)


    Zitat von kk

    Wir überarbeiten die gesamte GUI derzeit (weitere Infos dazu spätestens Anfang Oktober), da können wir sicher noch die eine oder andere Anregung aufnehmen.


    Wird es die Möglichkeit geben, die neue GUI vorab zu testen (z.B. auf einem Demo-Server bei Ihnen oder über eine eigene Installation z.B. per Beta-Repository)?

  • Sicherheitsabfrage vor Löschung / Undo-Funktion

    Hallo,
    wir hatten heute leider den Fall, das ein Kunde versehentlich ein komplettes Email-Postfach gelöscht hat. Aufgrund der oben ausgewählten Reiter war es ihm nicht bewusst gewesen, das er über den entsprechenden Button das Postfach entfernt, anstatt nur eine entsprechende Funktion (z.B. den Autoresponder). Mir ist bewusst, das LiveConfig nach dem Button-Klick eine weitere Rückfrage tätigt, allerdings sind die Leute manchmal mit der Maus beim Klicken schneller als mit dem Lesen ;) Vorteilhafter fände ich in so einem Fall z.B. eine Rückfrage:


    Code
    Möchten Sie das Postfach "adresse@domain.de" wirklich UNWIDERRUFLICH löschen?
Bitte bestätigen Sie dies mit der Eingabe der Email-Adresse und einem Klick auf OK:


Email-Adresse: __________________________________


                                                                    [  OK  ]  [  ABBRECHEN  ]


    Ähnliches könnte im Bereich der Datenbanken umgesetzt werden, also allen Funktionen, welche unmittelbar nicht nur eine Einstellung in der Oberfläche, sondern auch Daten auf dem Server betreffen (eine gelöschte Subdomain lässt sich z.B. problemlos erneut konfigurieren).


    Eine weitere Absicherung könnte eine Art Warteschleife sein: Ein Nutzer löscht ein Konto, dies wird in der Oberfläche auch entsprechend als "zur Löschung" markiert und nach einem gewissen Zeitraum auch durchgeführt. Hat man fälschlicherweise das falsche Konto gelöscht, könnte man dies entsprechend rückgängig machen. Der bessere Weg führt in so einem Fall natürlich über Backups, welche in LiveConfig zumindest über die GUI noch nicht zur Verfügung stehen. Der Optimalfall wäre heute gewesen, wenn der Kunde das betroffene Postfach in einer GUI-Auflistung ausgewählt und auf "Wiederherstellung" hätte klicken können - so musste eben alternativ der Techniker das ganze aus den stündlichen Backups manuell zurücksichern ;)

  • Automatisches Backup auf Externen Backup Space

    Zitat von stefanos


    Gibt den Eintrag auf eine Beta (ab v2.10.0). Aktivierbar mit beta.backup.enabled auf 1 setzen.
    Siehe https://www.liveconfig.com/de/…omization/lcdefaults.html und https://www.liveconfig.com/de/…n/first-steps/backup.html


    Webspace, E-Mails und Datenbanken sind in der manuellen Sicherung enthalten.


    Danke für den Hinweis, die Funktion war mir bis dato ebenfalls noch nicht bekannt. Hierzu allerdings eine kleine Anmerkung:

    Zitat


    Die Backupdaten werden lokal auf dem jeweiligen Server unter /var/backups/liveconfig gespeichert.


    Ich fände es vorteilhafter, wenn man den Backup-Serverdienst auf einem separaten System installieren und dann in den Server-Cluster einbinden könnte. Ansonsten ließe sich nur schwer abschätzen, zu wann der Speicherplatz auf einem Einzelsystem zu knapp würde, gleichzeitig verschwendet man möglicherweise wertvollen SSD-Speicher für die Backup-Lagerung.

  • Upgrade LiveConfig Cluster (Reihenfolge & PHP-Versionen)

    Als Zusatzinfo:


    Das Problem mit dem Autoremove trat bisher immer bei den Systemen auf, welche seit Debian 8 mit dem "liveconfig-meta" Paket installiert wurden. Beim Upgrade von Debian 8 -> 9 läuft alles einwandfrei, von 9 -> 10 möchte das System die Einzelpakete deinstallieren. Wenn vor dem "apt-get autoremove" ein "apt install liveconfig-meta" nochmals ausgeführt wird, bleiben die Pakete erhalten und es wird wirklich nur nicht mehr benötigtes deinstalliert. Auf unserem Liveconfig-Cluster wurden die Pakete gezielt und ohne Meta-Paket installiert, daher gehe ich davon aus das es dort nicht zu diesem Problem kommen wird.

  • Upgrade LiveConfig Cluster (Reihenfolge & PHP-Versionen)

    Vielen Dank für die Rückmeldung! Wir haben die Upgrade-Vorgänge nun einmal an einem Einzelsystem getestet (Debian 8 -> 9 -> 10). Das Update auf Stretch verlief völlig problemlos. Nach dem Update auf Debian Buster und dem abschließenden "apt-get autoremove" möchte das System allerdings eine ganze Menge an Paketen deinstallieren, welche aber natürlich noch benötigt werden:


    Code
    The following packages will be REMOVED:
  apache2 apache2-bin apache2-data apache2-suexec-pristine apache2-utils clamav clamav-base clamav-daemon clamav-freshclam clamav-milter clamdscan default-mysql-server dh-python dns-root-data
  g++-6 galera-3 gnupg-agent imagemagick imagemagick-6-common imagemagick-6.q16 libaio1 libapache2-mod-fcgid libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libargon2-0 libbind9-140
[...]
linux-image-3.16.0-11-amd64 mariadb-client-10.3 mariadb-client-core-10.3 mariadb-common mariadb-server-10.3 mariadb-server-core-10.3 mysql-common netpbm opendkim php-common php-imagick php5-cgi
  php5-cli php5-gd php5-imap php5-json php5-mcrypt php5-mysql php5-readline php5-sqlite php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-phpdbg php7.0-readline php7.3-cli php7.3-common
  php7.3-json php7.3-opcache php7.3-readline proftpd-basic proftpd-doc python-pyasn1 python3-distutils python3-lib2to3 python3.5 python3.5-minimal quota


    Ist dieses Verhalten normal bzw. warum landen die Pakete im Autoremove? Mittels "apt-get install [Paketnamen]" wechseln diese auf "manually installed" und verschwinden aus der Autoremove-Warteschlange, daher gehe ich davon aus das es sich hierbei um mitinstallierte Abhängigkeiten handeln muss (vom Liveconfig-Metapaket?). Im Prinzip sind wir so vorgegangen wie hier beschrieben:


    https://www.liveconfig.com/de/kb/debian-upgrade-9/


    Code
    apt-get upgrade && apt-get dist-upgrade
/etc/apt/sources.list (stretch durch buster ersetzt)
/etc/apt/sources.list.d/liveconfig.list (stretch durch buster ersetzt)
apt update
apt install apt dpkg
apt upgrade
apt full-upgrade
apt-get autoremove (hier tritt das Problem dann auf)

  • Upgrade LiveConfig Cluster (Reihenfolge & PHP-Versionen)

    Hallo,


    da wir auf unsere Anfrage vom 15.12.2020 (Ticket LC#2020121534000027) leider noch immer keine Rückmeldung erhalten haben, versuche ich es diesmal direkt hier im Forum.


    Wir betreiben einen LiveConfig Cluster bestehend aus mehreren Debian-Systemen (Business-Lizenz in Kombination mit getrennten Webservern, Mailservern, Datenbankservern und ein gesondertes System für den LiveConfig-Zugang) und würden diesen gerne auf die jeweils nächste Debian-Version aktualisieren. Dazu zwei Fragen:


    1)
    Spielt die Reihenfolge der Upgrades eine Rolle, sollte beispielsweise der Server mit der Business-Lizenz zuerst an die Reihe kommen? Oder ist das nicht relevant und wir können das beliebig durchgehen? Gibt es sonst etwas in Bezug auf Liveconfig zu beachten?


    2)
    Zum Thema PHP gibt es hier im Forum z.B. diesen Topic:
    https://www.liveconfig.com/de/…%C3%A4nderung-PHP-Version
    Wir würden im Rahmen der Upgrades natürlich auch bei den PHP-Versionen ein wenig "aufräumen" wollen. Gehe ich richtig in der Annahme, das LiveConfig als Default-Version immer die installierte PHP-Basisversion von Debian nutzt? Wenn man ein älteres php-opt Paket entfernen möchte, müssen die jeweiligen Domains immer noch manuell in der MySQL-Datenbank von LiveConfig entsprechend abgeändert werden, oder gibt es hierzu bereits einen anderen Mechanismus?

  • PHP Upload Probleme seit Upgrade auf Debian Buster/Liveconfig 2.9.1

    Wir haben einen Kunden, welcher einen eigenen Server für sein Shop-System nutzt auf welchem derzeit (leider) noch PHP 5.6 zwingend notwendig ist. Gibt es eine Möglichkeit, den Upload-Check an anderer Stelle zu deaktivieren (außer als Quick&Dirty-Variante wie im ersten Posting beschrieben? Mit einem Einfügen von "echo 1", "exit" am Dateianfang des Prüfscriptes läuft der Upload problemlos durch, allerdings wird "/usr/lib/liveconfig/uploadscan.sh" bei LiveConfig-Updates überschrieben. Daher wäre eine dauerhafte Deaktivierung wünschenswert, solange die Shop-Software noch nicht mit höheren PHP-Versionen läuft.

  • Kunden Domains fehlen

    Das kann ich als Ursache bei uns definitiv ausschließen, allerdings habe ich folgendes bemerkt:
    Menüpunkt "Mein Hosting" -> Paket ausgewählt, "Vertrag bearbeiten" -> bei "Webspace" ein Häkchen machen und somit aktivieren. Danach wird die Domain bei "Mein Hosting -> Domains" auch wieder korrekt angezeigt. Wenn der Webspace nicht aktiv ist, erscheint die Domain nicht in der Liste und läßt sich auch nicht über die Suche auffinden.


    Das ganze ist etwas irritierend, da man auch unter keinem anderen Menüpunkt mehr die angelegten Domains angezeigt bekommt und somit auch die Zuordnung zu den Verträgen nicht mehr sieht.

  • Kunden Domains fehlen

    Gleiches Problem bei uns. LiveConfig 2.9.3-release über SQLite 3.30.1, über den Menüpunkt "Mein Hosting" -> "Domains" in der Basic-Lizenz taucht nur eine angelegte Domain in der Liste auf, die übrigen fehlen. Die Domains sind aber in der Datenbank definitiv vorhanden und die konfigurierten Email-Konten funktional. Der Server lief bisher unter Debian 9 und wurde am gestrigen Abend auf Debian 10 upgedatet, um einen Fehler in dieser Hinsicht auszuschließen. Bei beiden Versionen allerdings dasselbe Problem.

  • Domain in Postfix blockieren (Blacklist)

    Hallo Ralf,


    das wäre jetzt auch meine bevorzugte Variante gewesen. Aber wenn ich das in die main.cf reinnehme, dann würde LiveConfig das ganze doch bei der nächsten Speicherung/Konfig-Änderung wieder überschreiben, oder? Wenn es keine andere Variante gibt, würde ich das als temporäre Lösung nutzen. Allerdings weiss ich nicht, wie lange die Spammails noch anhalten werden, daher wäre eine dauerhafte Einstellung natürlich vorteilhafter, welche man später manuell wieder deaktivieren kann.

  • Domain in Postfix blockieren (Blacklist)

    Hallo,


    einer unserer Kunden wird seit Tagen bereits mit Spam-Mails zugemüllt, jeweils immer mit der gleichen Absenderdomain (aber unterschiedlichen IP-Adressen). Auf einem anderen Serversystem haben wir die Konfiguration bereits so angepasst, das es für "check_sender_access" eine eigene Datei gibt und dort die Domain eingetragen wurde:


    Code
    smtpd_sender_restrictions = permit_mynetworks,
        check_sender_access hash:/etc/postfix/reject_domains


domain.com DISCARD


    Unter Liveconfig gibt es hingegen bereits diese Datei:


    Code
    check_sender_access hash:/etc/postfix/sender_access


    Wie/wo wird diese befüllt? Oder erfüllt diese einen anderen Zweck (z.B. User-Sperren)? Falls letzteres, was wäre der beste Weg um eine eigene Datei in der main.cf einzufügen? Da LiveConfig die Konfigurationsdatei sicherlich irgendwann überschreibt, wäre ein manuelles ändern sicherlich nicht sinnvoll. Optimal wäre natürlich, wenn man die Blackliste direkt für das jeweilige Postfach setzen könnte und nicht Server-Weit.

  • Migration LiveConfig -> Liveconfig

    Ich hänge mich hier mal mit meiner Frage dran:
    Gibt es mittlerweile Planungen, interne Migrationen im LiveConfig-Cluster durchführen zu können? Also beispielsweise einen Vertrag von Webserver1 auf Webserver2 zu verschieben, identisches mit Datenbanken, Emails usw.?

  • LiveConfig v2.7.1

    Vielen Dank für die schnelle Fehlerbehebung - das Update wurde heute auf allen Systemen eingespielt, nun funktioniert wieder alles wie gewohnt.

  • LiveConfig v2.7.1

    Ich habe hier seit dem Update auf r5120 leider den Fehler, das beim Löschen einer Subdomain der Serverprozess (Business-Lizenz von LiveConfig) sich verabschiedet:



    Ist das ein bereits bekannter Fehler?


    Edit:
    Debian Jessie 8.11

  • Filezilla Verbindungsprobleme

    aziegler: Danke für das Angebot, mir ging es allerdings primär erstmal darum, ob die Sache mit Debian 9 behoben ist bzw. ob es eine temporäre Lösung vorab gegeben hätte. In diesem Fall werden wir die Server-Upgrades entsprechend vorziehen.

  • Filezilla Verbindungsprobleme

    Ich muss das Thema leider doch nochmal hervorholen. Insbesondere aufgrund der aktuellen Situation in Hinsicht der DSGVO sollten ja nun alle Dienste wenn möglich auf Verschlüsselung setzen. Wenn nur verschlüsselte Verbindungen erlaubt sind (SSL Session reuse aber deaktiviert) dann bestehen die Probleme nach wie vor - langsame Verbindungen, abgebrochene Connects usw... leider nicht nur mit FileZilla, sondern so wie es aussieht auch mit anderen Clients (z.B. WinSCP). proftpd-basic hat in Debian 8 die Version "1.3.5-1.1+deb8u2" - sind dort die aktuellen Patches noch immer nicht enthalten? Welche Lösungsvarianten hätten wir in der Sache, ausser einem Upgrade zu Debian 9 (funktioniert dort denn FTP über TLS einwandfrei?) ? Kennt jemand einen FTP-Client, welcher mit SSL und Debian 8 einwandfrei läuft?

  • DSGVO-Frage

    Zusatzfragen:


    1.
    Soweit mir bekannt, kann der Kunde derzeit in seinem eigenen Zugang nicht selbst einstellen, wie lange die Logs aufbewahrt werden oder ob diese anonymisiert werden sollen. Habe ich da etwas übersehen, wird das noch implementiert oder wird auch zukünftig nur in den Vertragseinstellungen diese Möglichkeit gegeben sein?


    2.
    Wenn die Speicherzeit der Logs noch auf dem Standard-Wert (100 Tage) steht, es bereits Verträge mit diesem Wert gibt und man diesen Wert in den Angeboten nun nachträglich anpasst - wird dies von LiveConfig für alle angelegten Verträge übernommen und anschließend beim nächsten Logrotate berücksichtigt?