Beiträge von kk

    Am besten mal beim eigenen Domainregistrar anfragen, die haben sich sicherlich intensiv mit dem Thema auseinandergesetzt und vielleicht auch schon ein paar Argumentationshilfen bei Hand.


    Wir sehen das so: [PERSÖNLICHE MEINUNG - KEINE STEUER-/RECHTSBERATUNG!] eine Domainregistrierung ist eine wiederholende Leistung, aber keine Dauerleistung. Die Dienstleistung an sich ist die Registrierung bzw. Verlängerung der Domain zum jeweiligen Stichtag - maßgeblich ist also die Ausführung der Leistung. Etwas anderes gilt, wenn eine Domain gemietet wird (separater Mietvertrag) bzw. anderweitige Lizenz- oder Nutzungsgebühren vereinbart sind - dann könnte das tatsächlich eine Dauerleistung sein. Aber auch bei Dauerleistungen gilt nur, dass die USt zum Ende des Leistungszeitraums fällig wird - wenn eine jährliche Abrechnung vereinbart ist muss hier also nicht monatlich abgegrenzt werden.


    Komplizierter wird es beim Webhosting. Wenn die Hostinggebühr z.B. monatlich berechnet ("xx,xx €/Monat), aber nur alle 3 Monate abgerechnet wird, dann muss hier nach unserem Verständnis tatsächlich eine Abgrenzung stattfinden. Wird die Gebühr aber quartalsweise berechnet ("xx,xx € für 3 Monate") dann wiederum nicht.


    Bei vorsteuerabzugsberechtigten Kunden ist die gesamte Diskussion i.d.R. komplett überflüssig, da die ja die gesamte ausgewiesene USt zurückholen können, sofern die Rechnung formal korrekt ist.


    Viele Grüße


    -Klaus Keppler

    WIrd es auch noch die bisherigen Wiki Beiträge zum Beispiel zu Multi-PHP und Autodiscover wieder geben?
    Da fehlen im Moment ja einige nützliche Beiträge oder habe ich die nur nicht gefunden?


    Ja, die werden beide derzeit inhaltlich überarbeitet und in Kürze auch wieder online stehen.

    Hallo!


    die Umstellung der Website ist nun zum größten Teil abgeschlossen, lediglich am Shop wird aktuell noch gearbeitet.
    Das Forum ist nun auch wieder online - hier wird im Laufe der nächsten Tage die Ausgabe/Darstellung (CSS) noch angepasst.


    Viele Grüße


    -Klaus Keppler

    Das Problem mit dem RoundCube-Installer sollte inzwischen behoben sein. Bitte bei Gelegenheit noch mal testen (LiveConfig aktualisiert das Repository automatisch alle 24 Std, notfalls LC einfach mal kurz neu starten)


    Viele Grüße


    -Klaus Keppler

    Hallo,


    heute Nacht und morgen im Laufe des Tages werden an der LiveConfig-Website umfangreiche Änderungen vorgenommen (u.a. aufgrund der neuen MwSt. in Deutschland ab dem 01.07.).
    Der Lizenz-Shop ist vorübergehend deaktiviert und soll voraussichtlich spätestens morgen Abend um 18:00 wieder online sein.
    Die Backend-Systeme für LiveConfig-Partner sind hiervon nicht betroffen.


    Das Forum wird morgen im Laufe des Tages für mehrere Stunden ebenfalls nicht erreichbar sein - auch das soll bis 18:00 abgeschlossen sein. Also bitte nicht wundern.


    Die Änderungen werden nicht zu übersehen sein. ;)


    Viele Grüße!


    -Klaus Keppler

    Stimmt, ist tatsächlich die Überlegung ob man den Einsatz von PHP 5.5 mit FPM noch "schmackhaft" machen sollte. ;)
    Letztendlich gibt es ja nicht nur Sicherheits- sondern auch Geschwindigkeitsvorteile durch aktuellere PHP-Versionen.


    Das Löschen der Verzeichnisse ist vermutlich dem systemd geschuldet, LiveConfig macht sowas nicht.


    Viele Grüße


    -Klaus Keppler

    Wir erleben häufig das Problem, dass Kunden die Server einfach überhaupt nicht regelmäßig aktualisieren. Das Schöne an LiveConfig ist ja, dass es mit einem normalen Aufruf von z.B. "apt upgrade" mit aktualisiert wird ohne dass man sich um irgendwas kümmern muss.
    Es gibt Kunden, die Probleme mit LiveConfig 2.1.x melden und auf Debian 7 laufen, weil der Admin "im Urlaub ist und noch keine Zeit für ein Update hatte". ;)


    Auf der Wunschliste steht bereits ein Check nach verfügbaren Distributionsupdates und einer entsprechenden Warnung im Dashboard. Das ist zwar nicht primäre Aufgabe eines Hosting-Controlpanels (daher bislang nur Wunschliste und nicht ToDo-Liste), aber ich merke schon dass der Bedarf doch groß ist...


    Viele Grüße


    -Klaus Keppler

    Klingt auch für uns alles vernünftig und ohne großen Aufwand umsetzbar. Wir nehmen das in unsere Arbeitsliste auf (dürfte in einem der kommenden Updates drin landen).


    Zu Punkt 4: das prüft nicht LiveConfig, sonder die DNS-Software (BIND). Irgendwo im BIND-Log wird sich ein Hinweis finden, dass sich der gewünschte MX-Eintrag einen ungültigen Zielhost enthält.
    Inzwischen "kann" LiveConfig auch DNS-Abfragen durchführen, daher wäre es möglich, beim Anlegen von DNS-Records mit Ziel innerhalb der selben Zone zu prüfen, ob der jeweilige Host schon existiert.
    Das ist nicht ganz so trivial wie die anderen genannten GUI-Änderungen, aber im Sinne der Kunden und auch kein Ding der Unmöglichkeit. Wird in der Umsetzung aber leider ein wenig länger brauchen als die anderen Punkte.


    Viele Grüße


    -Klaus Keppler

    Eine Idee wäre ein separater "View" auf die DNS-Daten (auch wir haben häufiger Anfragen hierzu).
    Es besteht ja ohnehin auch ein Wunsch nach Import und Export von DNS-Daten, das ließe sich über eine separate Maske eleganter lösen als das auch bei der Subdomainverwaltung unterzubringen.

    für eventuelle Mitleser: vermutlich war das o.g. Verhalten eine Nebenwirkung aus der Umstellung der PHP-Version via update-alternatives.

    Hallo,


    zu Frage 1: welcher PHP-Interpreter genau liefert diese Fehlermeldung?
    führen Sie nacheinander mal folgende Befehle aus:

    Code
    php -v
    /opt/php-5.6/bin/php -v
    /opt/php-7.0/bin/php -v
    /opt/php-7.1/bin/php -v
    /opt/php-7.2/bin/php -v
    /opt/php-7.3/bin/php -v
    /opt/php-7.4/bin/php -v


    zu Frage 2: update-alternatives hat hiermit nichts zu tun (das betrifft nur Debian selbst, nicht aber LiveConfig).
    Haben Sie manuell irgendetwas in einer .lua-Datei (/etc/liveconfig/lua.d/*.lua oder in /usr/lib/liveconfig/lua/custom.lua eingestellt?
    Schicken Sie uns bitte ggf. mal die gesamte Ausgabe der PHP-Erkennung von "liveconfig --diag" an support@liveconfig.com


    Viele Grüße


    -Klaus Keppler

    Eigentlich sollte das funktionieren (werden wir bei Gelegenheit mal testen).


    Es sollte genügen, folgenden SQL-Befehl in der LiveConfig-Datenbank auszuführen:


    SQL
    INSERT INTO SSLPROVIDERS (SP_NAME, SP_LOGO, SP_MODULE, SP_DESCRIPTION, SP_DATA) VALUES ("BuyPass.com", "logo-letsencrypt.svg", "ssl-letsencrypt", "Free domain-validated Buypass Go SSL certificates", "https://api.buypass.com/acme/directory");


    bzw. für die Test-Umgebung von Buypass:


    SQL
    INSERT INTO SSLPROVIDERS (SP_NAME, SP_LOGO, SP_MODULE, SP_DESCRIPTION, SP_DATA) VALUES ("BuyPass.com TEST", "logo-letsencrypt.svg", "ssl-letsencrypt", "Free domain-validated Buypass Go SSL certificates - TEST ENVIRONMENT", "https://api.test4.buypass.no/acme/directory");


    Wildcard steht auf unserer ToDo-Liste (genauer Zeitpunkt steht aber noch nicht fest).


    Viele Grüße


    -Klaus Keppler


    [UPDATE] Es muss zwingend ein Logo (SP_LOGO) hinterlegt werden, ansonsten zerschießt das in LiveConfig 2.9.x die Darstellung. In v2.10.x kann man auch einen Anbieter ohne Logo hinterlegen.

    Hallo zusammen,


    aktuell kann man ja davon ausgehen, dass die Mehrwersteuer vom 01.07.2020-31.12.2020 von 19% auf 16% reduziert wird.
    Wir bereiten unser Abrechnungssystem derzeit darauf vor (für Geschäftskunden ändert sich aufgrund des Vorsteuerabzugs bilanziell nichts, bei Endkunden kommt die Steuersenkung somit aber auch effektiv an).


    Diesen Thread möchte ich aber nutzen, um das auch im gesamten Hosting-Kontext zu diskutieren.


    Ein paar Kollegen erinnern sich ja vielleicht noch an den 01.01.2007, als die MwSt von damals 16% auf 19% erhöht wurde. Das Problem damals (wie heute) ist, dass Hosting-Verträge und Domaingebühren allgemein als "Dauerleistungen" und steuerlich somit als "sonstige Leistungen (Dienstleistungen)" klassifiziert werden. Das bedeutet, dass die Umsatzsteuer mit Ablauf des Leistungszeitraums entsteht.


    Beispiel: eine Domain kostet 10 € brutto (inkl. 19% MwSt) pro Jahr.
    Ein Kunde registriert die Domain am 01.08.2019 (wird also vom 01.08.2019-31.07.2020 in Rechnung gestellt).


    Nun gilt vom 01.07.-31.12.2020 aber der neue Steuersatz von 16%. Somit ist nach aktuellem Stand dem Kunden die Differenz (3%) zurück zu erstatten.
    Bei 10 € brutto wurden also 8,40 netto und 1,60 MwSt (19%) berechnet. Bei 16% beträgt die MwSt aber nur noch 1,34 € (bezogen auf 8,40), somit sind 0,26 € zurück zu erstatten (die müssen auf dem jeweiligen Beleg auch als USt-Rückerstattung ausgewiesen werden).


    Je nach Rechnungssystem gibt es da verschiedene Ansätze: die einen stornieren alle Leistungen die mit einem Enddatum zwischen 01.07.-31.12.2020 erfasst sind und stellen diese mit 16% neu in Rechnung; die Differenz wird dann einfach als Gutschrift verrechnet.
    Andere Systeme berechnen die gesamte MwSt aller zwischen dem 01.07.-31.12.2020 endenden Leistungen die vor dem 01.07. in Rechnung gestellt wurden, und weisen daraus dann 3% als USt-Rückerstattung aus.


    Lustig daran: wer aktuell eine Domain mit einer Laufzeit von 12 Monaten verkauft, muss diese weiterhin mit 19% berechnen (Domainlaufzeit endet ja nach dem 31.12.2020). Wer eine Domain oder z.B. auch das Webhosting monatlich berechnet müsste das mit 16% versteuern. Praktisch geht das aber aus zwei Gründen aktuell noch nicht: zum einen ist das Gesetz noch nicht rechtskräftig (bzw. noch nicht mal vorhanden), zum anderen sind die Steuerformulare dafür auch noch gar nicht vorbereitet.


    Bei der MwSt-Erhöhung 2007 gab es den Trick, die 3%-Nachforderung einfach aus der eigenen Betiebskasse zu bezahlen statt die den Kunden nachzuberechnen. Bei einer Rückerstattung ist es aber nicht so einfach - die darf man nicht einfach so einbehalten.


    Am einfachsten dürfte es sein, die MwSt-Rückerstattung zu berechnen und dem Kunden auf einer der nächsten Rechnungen separat auszuweisen (sofern das Abrechnungssystem das mitmacht) und somit zu verrechnen.
    Hässlich wird das dann in Fällen von Rücklastschriften/Forderungen etc.


    So lange das Gesetz noch nicht erlassen ist, besteht noch kein akuter Handlungsbedarf, aber jeder Webhoster sollte jetzt schon mal prüfen inwiefern die Abrechnung angepasst werden muss.


    LiveConfig-Lizenzen werden aktuell bei uns im Shop also weiterhin mit 19% MwSt beworben. Sobald die MwSt-Änderung rechtsgültig wird, aktualisieren wir das und werden allen betroffenen Kunden ggf. eine entsprechende Gutschrift erstellen, die dann (je nachdem) ausgezahlt oder mit der nächsten Rechnung verrechnet wird.
    Wir prüfen zudem ob es auch möglich sein wird, diesen (kleinen) Betrag freiwillig spenden zu können.


    Viele Grüße


    -Klaus Keppler

    Hmm, die Idee über "Authority Information Access" die Zwischenzertifikate abzurufen ist interessant. Werden wir mal im Auge behalten.


    LiveConfig hat ja ohnehin einen Mechanismus, um Zertifikatsketten selbständig zu erkennen (Tabelle SSLINTERMEDIATES). Bis v2.8 war das automatisch aktiviert, mit dem komplett neuen SSL-Backend in v2.8 war das leider inaktiv, mit v2.10 schalten wir das aber wieder ein. Wenn man ein Zertifikat manuell hinzufügt, prüft LC ob die erforderlichen Zwischenzertifikate schon bekannt sind, und holt diese ggf automatisch aus dessen Cache. Neu ist, dass abgelaufene Intermediate-Zertifikate im Cache nun nicht mehr berücksichtigt werden (eigentlich logisch, aber offenbar gab's diesen Fall bislang noch nicht wirklich).


    Zu jedem SSL-/TLS-Zertifikat prüft LiveConfig in v2.10 nun den frühesten Ablauf-Zeitpunkt aller hinterlegten Chain-Zertifikate. Ist dieser erreicht, wird das Zertifikat in LC auch als "abgelaufen" markiert; in der SSL-Verwaltung kann man über die Filter-Option "abgelaufene Zertifikate" eine entsprechende Liste abrufen. Mit Klick auf das Zertifikat wird dann bei den Zwischenzertifikaten auch angezeigt, welches Zertifikat abgelaufen ist.


    Beim ersten Start von LiveConfig v2.10 wird in /var/log/liveconfig/liveconfig.log auch protokolliert, welche Zertifikate ein abgelaufenes Intermediate enthalten.


    Das Update (v2.10.0-dev20200603) wird im Laufe des Nachmittags bereitgestellt, voraussichtlich morgen soll die v2.10 dann auch als "stable" rausgehen.


    Viele Grüße


    -Klaus Keppler