Beiträge von kk

    Edit: Sofern das kein Limit durch MariaDB/SQL ist: Bitte längere Namen ermöglichen :)


    Das ist leider tatsächlich ein historisch bedingtes Limit von MySQL selbst: bis v5.7.8 sind nur 16 Zeichen für Benutzernamen erlaubt, ab 5.7.8 liegt das Limit immerhin bei 32 Zeichen.


    Da der Wunsch schon mehrfach von anderer Seite geäußert wurde, werden wir das in einem der kommenden Updates angehen.
    (ist nicht ganz trivial, weil LiveConfig somit prüfen und "wissen" muss, welche DB-Version zum Einsatz kommt und welche Limits die jeweils hat).
    Das selbe gilt übrigens auch für IP-Limits bei den Zugriffsberechtigungen (nur neuere DBs unterstützen etwa IPv6-Adressen).


    Viele Grüße


    -Klaus Keppler

    Mit v2.10.0 wird das Limit von 512 auf 4096 Zeichen erhöht (gilt für alle Text-Einstellungen in php.ini) - das sollte das Problem also beheben.


    Eine eigene php.ini kann man derzeit nicht anlegen/einbinden (bei FPM sind die php.ini-Einstellungen zudem ja in der Pool-Konfigurationdatei).


    Workarounds wären:
    - wenn Sie FPM einsetzen: die Änderung direkt in der FPM-Pool-Konfiguration vornehmen (z.B. /etc/php-fpm/php73-fpm.d/<Vertrag>.conf) und diese Datei mittels "chattr +i" gegen Überschreiben schützen
    - im Datenbankschema mittels "ALTER TABLE ..." die Zeichenbegrenzung von 512 auf 4096 vergrößern und die gewünschten Daten direkt in der Datenbank bearbeiten (wie immer bei Datenbankeingriffen: bitte seeehr sorgfältig arbeiten)
    Beide Varianten "beißen" sich nicht mit dem anstehenden v2.10-Update.


    Viele Grüße


    -Klaus Keppler

    Guten Morgen,


    sehr merkwürdig - das klingt danach dass irgendwie ältere Dateien zurückgespielt wurden (evtl. eine häßliche Nebenwirkung eines korrupten Journaling-Filesystems?)


    Am besten nehmen Sie sich testweise mal irgendeine der betroffenen Domains her. Bearbeiten Sie im LiveConfig einfach den zugehörigen Vertrag (d.h. den Vertrag oder irgendeine Domain/Subdomain dieses Vertrags neu speichern) - das führt dazu, dass LiveConfig die vHost-Konfiguration und alle zugehörigen Zertifikate neu schreibt. Nach 60 Sekunden einfach mal ausprobieren ob die Zertifikate dann stimmen.


    Wenn das geklappt hat, bearbeiten Sie unter Server -> Serververwaltung -> Web die IP-Gruppe(n) (es genügt z.B. an den Namen der IP-Gruppen z.B. einen Punkt anzufügen). Das führt dazu, dass alle vHost-Konfigurationen neu geschrieben werden.


    Viele Grüße


    -Klaus Keppler

    Durchaus möglich dass das allgemein PHP 7.4 betrifft. Ohne weitere Log-Infos zum eigentlich Fehler wird man da aber nicht weiter kommen.

    Mein Verhältnis zum OpCache ist etwas zwiegespalten (die Tatsache, dass bei FPM der Shared Memory zwischen allen Pools geteilt wird, ist einfach unterirdisch und weltfremd).


    Wenn's mit PHP 7.3 funktioniert und mit 7.4 nicht mehr (ich nehme an, bei der selben Website?), dann deutet das wohl auf ein Problem in PHP selbst hin. LiveConfig hat damit tatsächlich nichts am Hut. ;)


    Was Sie machen können:

    • opcache.error_log setzen (z.B. auf /tmp/opcache.log - die Datei sollte kurzzeitig mode=0777 haben, damit die von allen PHP-Instanzen beschrieben werden darf)
      Am besten direkt in /opt/php-7.4/etc/conf.d/opcache.ini eintragen
    • opcache.log_verbosity_level setzen (am besten auf "2")
    • in den php.ini-Einstellungen des betroffenen Vertrags log_errors auf "on" setzen (damit sollten dann Fehler in ~/logs/priv/php_errors.log protokolliert werden


    ... und dann mal schauen ob irgendwelche weiteren Informationen in den Logs auftauchen.


    Die Apache-Meldung "Connection reset by peer" bedeutet i.d.R. dass der PHP-Prozess während der Verarbeitung der Anfrage abgeraucht ist. Das sollte prinzipiell auch nicht ohne Log-Einträge passieren. Manchmal taucht auch was in den System-Logs auf (/var/log/messages, /var/log/syslog; insbes. wenn ein SEGFAULT aufgetreten ist).

    Eine vielleicht "blöde" Frage: wo findet man diese PHP-Paket und bedeutet dies, das man IonCube nicht mehr manuell (in die php.ini) einbinden muss?


    So blöd ist die Frage gar nicht, ich sehe dass das noch gar nicht dokumentiert ist. Wird gleich nachgeholt.


    Die Pakete nennen sich "php-x.y-opt-ioncube" und sind in unseren "normalen" PHP-Repositories enthalten. Mit der Installation werden diese auch automatisch in die php.ini mit aufgenommen (via /opt/php-x.y/etc/conf.d/ioncube.ini).

    Hallo Herr Kretzschmar,


    auch wenn Sie verärgert sind würde ich mich über einen etwas objektiveren Ton freuen.


    Wir haben zum 01.07. die Website komplett relaunched. Gerne hätten wir uns dafür etwas mehr Zeit gelassen, die äußerst kurzfristige Absenkung der Umsatzsteuer hat den Zeitplan aber etwas durcheinander gebracht.


    Was das Handbuch betrifft: das bisherige Handbuch war eher eine Mischung aus Admin- und Anwender-Handbuch. Die fehlende Fokussierung hat zur Entscheidung geführt, das künftig aufzuteilen. Ein reines Endanwender-Handbuch gab es also noch nie.
    Auch waren viele Screenshots inzwischen veraltet und einige Anleitungen sind inzwischen überholt. Daher wird das Handbuch derzeit Kapitel für Kapitel überarbeitet - alles was fertig ist wird schrittweise online gestellt.
    Das Vorgehen ist dabei übrigens so, dass das Handbuch (wie auch die Software) zuerst in Englisch geschrieben und dann ins Deutsche übersetzt werden, damit alle Inhalte nun immer synchron sind.


    Gerne können wir ihnen das bisherige Handbuch als PDF zur Verfügung stellen.
    Wenn Sie bestimmte Wünsche/Anregungen bzgl. des Handbuchs haben, sind wir immer für Vorschläge offen.


    Das neue Handbuch ist übrigens komplett "White-Labeled", so dass Hostinganbieter das problemlos auch den eigenen Kunden zur Verfügung stellen können.


    Bei weiteren Fragen stehe ich gerne zur Verfügung.


    Viele Grüße


    -Klaus Keppler

    Als erstes wird ja die /etc/proftpd/modules.conf eingebunden. Wenn Sie Ihre Einstellungen da mit einfügen, werden diese als erste geladen.


    Die include-Reihenfolge zu ändern wäre nicht mehr abwärtskompatibel (könnte also unerwünschte Nebenwirkungen bei bestehenden Installationen haben). Wir könnten ggf. über die Lua-API auch eigene Einstellungen ermöglichen (bzw. das "Override" von Einstellungen die LiveConfig vornimmt).


    Viele Grüße


    -Klaus Keppler

    Was für eine Webserver-Version meinen Sie? Und wo soll die angezeigt werden...? :confused:


    Mit "liveconfig --diag" sehen Sie alle Pakete (inkl. Version), die LiveConfig auf dem Server erkannt hat.

    Ab sofort stehen die PHP-Pakete für Debian 8 und Debian 9 in den Versionen 7.2.32-2, 7.3.20-2 und 7.4.8-2 im Test-Repository zum Download bereit. Diese sind mit libsodium-1.0.18 compiliert und beherrschen somit die ARGON2ID-Hashes.


    Mit dem nächsten regulären PHP-Update (voraussichtlich in 2 Wochen) werden die Pakete dann auch in unser Stable-Repo übernommen.


    Viele Grüße


    -Klaus Keppler

    Danke für die ausführliche Problembeschreibung! :)


    Klingt plausibel, eben wurde ein PHP 7.2 Build mit libsodium 1.0.18 für Debian 8/9 gestartet; ich gebe morgen Bescheid sobald der im Test-Repo bereit steht.


    Viele Grüße


    -Klaus Keppler

    Hoppla. Eben kam hier eine Rechnungskorrektur eines größeren Domainanbieters rein, bei dem die im Juli 2020 zu 16% MwSt verlängerten Domains nun doch zu 19% berechnet werden. Ich gebe Bescheid sobald wir weitere Infos dazu haben.

    Hallo,


    unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.32, 7.3.20 und 7.4.8 aktualisiert.
    Außerdem stehen PHP 5.6.40, 7.2.32, 7.3.20 und 7.4.8 ab sofort auch für Ubuntu 20.04 LTS ("Focal Fossa") bereit.
    Last but not least gibt es nun auch fertige PHP-Pakete mit dem IonCube-Loader (aktuellste Version) für PHP 5.6-7.4.


    Die Anleitung zur Installation weiterer PHP-Versionen unter Debian/Ubuntu wurde komplett überarbeitet:
    https://www.liveconfig.com/de/…an-mehrere-php-versionen/


    Für "neue" Distributionen (in diesem Fall also Ubuntu 20) stellen wir keine EOL-Versionen von PHP mehr bereit - einzige Ausnahme bildet PHP 5.6, weil es doch noch eine Menge Legacy-Anwendungen gibt die das benötigen.


    Debian 8 ist seit Ende Juni 2020 auch "End of Life". Die o.g. PHP-Versionen sind die letzten PHP-Updates, die wir hierfür bereitstellen.


    Viele Grüße


    -Klaus Keppler

    Kurzer Hinweis noch an die Bundesregierung: wenn bei der nächsten Pandemie wieder 20 Mrd € unter's Volk gebracht werden sollen, bitte lieber unkompliziert an alle komplett eingefrorenen Berufsgruppen verteilen (Kunst, Kultur, Messebau, ...) statt die MwSt abzusenken. Danke.

    Heute hatten wir den ersten Rechnungslauf mit den neuen Steuersätzen (und einer neuen Buchungsssoftware übrigens...).
    Da schon die ersten Rückfragen aufgetreten sind, hier nochmal ein kurzer Hinweis:


    LiveConfig-Lizenzen ("Softwaremiete") sind eine sogenannte Dauerleistung. Die Umsatzsteuer entsteht somit zum Ende des jeweiligen Leistungszeitraums.
    In den neuen Rechnungen ist nun überall der exakte Abrechnungszeitraum sekundengenau aufgeführt (ab Seite 2). Alle Lizenzen, deren Abrechnungszeiträume nach dem 31.06.2020 23:59:59 enden, unterliegen somit schon der Umsatzsteuer von 16%.
    Lizenzen mit jährlicher Abrechnung, die somit erst nach dem 31.12.2020 23:59:59 enden, wurden bereits wieder mit 19% abgerechnet.


    Da das der erste Rechnungslauf mit einem neuen Buchungssystem war mag ich Fehler nicht grundsätzlich ausschließen, wir haben aber die letzte Woche über sehr ausführlich getestet und hoffentlich auch alle Sonderfälle korrekt abgefangen.
    Für Fragen zu Rechnungen am besten unter Angabe der Rechnungsnummer eine kurze Mail an buchhaltung@liveconfig.com schicken.


    Viele Grüße


    -Klaus Keppler

    Im liveconfig.log gibt es nur diese Info: "Error while connecting to MySQL server: SSL connection error: wrong version number"


    Den Fehler hatten wir selbst noch nicht erlebt, im Forum gab's aber vor längerer Zeit einen ähnlichen Fall.
    Welche Versionen exakt von LiveConfig und von MariaDB setzen Sie denn ein?
    Haben Sie irgendwelche SSL-Einstellungen an MariaDB vorgenommen? Wenn ja, welche? (damit wir das mal versuchen können zu rekonstruieren)

    Ja.


    Aber: Rechnung im August 2019 für ein Jahr Webhosting (ggf. inkl. Domain) im Voraus. Geld fließt im August 2019. Da Webhosting eine Dauerleistung ist, gilt die USt zum Ende des Leistungszeitraums (=August 2020). Also wäre (theoretisch?) eine USt-Korrektur erforderlich. Aber wo kein Kläger da wohl auch kein Richter - dem Staat/Finanzamt entsteht ja in diesem Fall kein Schaden.
    Der Kunde hat aber in diesem skizzierten Fall einen Anspruch auf Erstattung, das kann man im Einzelfall aber sicher auch einfacher lösen als mit einer Korrekturbuchungs-Orgie.