Beiträge von mjk

    Naja... gSales erstellt ja nur Rechnungen und verwaltet die Kundendaten und Verträge. Aber irgendwie muss ja eine Buchhaltung, Lohn, Steuer, etc. gemacht werden.

    Das macht bei uns der Steuerberater. Ich wäre in Zukunft aber natürlich auch nicht abgeneigt, das ganze aufzuteilen: LexOffice für Rechnungsversand / Buchhaltung / Lastschrift-Einzüge / Mahnwesen etc., darauf hätte der Steuerberater ebenfalls Zugriff. Und für die Verwaltung der Kundendaten / Server / Domains / Webspace-Pakete mit zugehörigen Schnittstellen ein separates System. Für letzteres gibt es aber scheinbar noch kein fertiges Produkt bzw. nur individuell programmierte Lösungen.

    Zum Thema: wir haben lange Zeit g*Sales eingesetzt. Konzeptuell unschlagbar - die aktuelle Version kenne ich aber nicht mehr. Wir setzen ein eigenes System ein, das die Buchhaltungsdaten dann nach Lexoffice kippt. Lexoffice läuft gut - für Hosting mit schnell ändernden Produkt-Lebenszyklen sind die Serienrechnungen IMHO aber nur schwerlich brauchbar.

    Ich hatte im Topic zu gSales bereits gesehen, das einige eine solche Kombination mit LexOffice wohl gebaut haben, z.B. hier:


    Darf man fragen, warum in dieser Kombi und nicht direkt gSales? Warum hattet ihr das damals umgestellt?

    Warum nicht das liveconfig-meta-Paket deinstallieren und die (benötigten) Abhängigkeiten manuell installieren?

    Das wäre eine mögliche Option. Allerdings ist das Meta-Paket ja genau für den Fall gedacht, das man alle benötigten Dienste "in einem Rutsch" auf einem Einzelsystem installieren kann. Auf den Cluster-Systemen nutzen wir dieses natürlich nicht. Eigentlich würde schon eine Option ausreichen, um die vom OS installierte PHP-Version in LiveConfig auszublenden und für die Zukunft die Standard-Version automatisch heraufsetzen zu können.

    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.

    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.

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


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

    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 ;)


    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.

    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.

    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)

    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?

    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.

    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.

    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.

    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.

    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.

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

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