Beiträge von mjk

  • 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?

  • Doppelte IPv4/IPv6 Adressen

    Kurze Rückinfo von meiner Seite aus in der Sache:
    Der Fehler ist bis dato nicht mehr bei uns aufgetreten. Die doppelten IP-Adressen habe ich bestehen lassen, wir hatten allerdings vor kurzem eine Migration aller Serversysteme. LiveConfig hat in diesem Zusammenhang wohl automatisch die geänderte Netzwerkkonfiguration erkannt, die alten IPs entfernt und die neuen Adressen in der Datenbank eingetragen, nun stimmt die Auflistung wieder.

  • Serverzeit in LiveConfig-Oberfläche

    Hallo,


    einigen Kunden von uns ist aufgefallen, dass die Uhrzeit auf der LiveConfig-Oberfläche "falsch" angezeigt wird, nämlich genau 1 Stunde zurück. Die Uhrzeit scheint aber nicht falsch zu sein, sondern derzeit lediglich im CET-Format angezeigt zu werden (statt CEST). Auf dem Serversystem selbst ist die Timezone richtig konfiguriert und in Liveconfig in den Einstellungen auch "Europe/Berlin (CEST) [GMT +02:00]" ausgewählt worden. Das scheint also lediglich eine kosmetische Sache zu sein, welche allerdings die Kunden irritiert - oder habe ich eine Einstellungsmöglichkeit übersehen?

  • Doppelte IPv4/IPv6 Adressen

    Eine Tabelle "SERVERIPS" existiert nicht, dafür aber eine Tabelle "IPS":



    Doppelte IPs:
    ID 5 + 11, 6 + 12
    ID 7 + 13, 8 + 14


    Diese werden unter "Server" -> "Serververwaltung" dann ebenfalls doppelt angezeigt:


    [Blockierte Grafik: http://fs5.directupload.net/images/160730/ttmgerex.png]


    Genügt in der Sache ein einfaches

    Code
    delete from IPS where ID > 10;


    oder sollten zur Sicherheit zuvor noch andere Dinge geprüft werden? Welche Tabellen nutzen derzeit die IPS Tabelle, dann könnte ich einmal nachsehen ob die doppelten IDs dort aufgeführt sind?

  • Doppelte IPv4/IPv6 Adressen

    Hallo,


    bei der Durchsicht in Liveconfig (Bereich Server) ist mir soeben aufgefallen, dass bei unserem Datenbank- und Mailserver-System 2 IP-Adressen für IPv4/IPv6 angezeigt wurden. Bei Aufruf des Servers in der Auflistung stellte sich heraus, dass die jeweiligen Adressen exakt identisch sind, also doppelt angezeigt werden. In der Liveconfig-Datenbank tauchen die Adressen ebenfalls in der Tabelle "IPS" mit anderer ID auf (jeder Server hat normalerweise 1x IPv4 + 1x IPv6, jetzt hat jeder Server allerdings 4 Einträge).


    LiveConfig Version: 2.2.0 (r4254), Business Edition
    Auf dem Mail-/Datenbankserver ist lcclient installiert und aktiv, genauso wie bei den Webserver-Systemen. Bei den letzteren ist aber keine doppelte IP vorhanden. In den Logs konnte ich auf die schnelle ebenfalls nichts finden.


    Irgendwelche Ideen?


    Grüsse,


    Michael