siehe https://www.liveconfig.com/de/lab:
Zitat[dev20200522.1] iOS MobileConfig unterstützt nun mehrere Postfächer mit der selben Domain auf dem selben Endgerät
siehe https://www.liveconfig.com/de/lab:
Zitat[dev20200522.1] iOS MobileConfig unterstützt nun mehrere Postfächer mit der selben Domain auf dem selben Endgerät
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
Direkt über die LiveConfig-Oberfläche geht das nicht (ist ja eher ein Sonderfall).
Sie können aber die notwendigen Postfix-Einstellungen in einer .lua-Datei einrichten, so dass diese in die von LiveConfig generierte Postfix-Konfiguration mit aufgenommen werden.
Legen Sie eine Datei namens /etc/liveconfig/lua.d/postfix.lua an, mit folgendem Inhalt:
Oder - falls Sie sich per SMTP-Authentifikation (also wie ein SMTP-Client) am Relayhost anmelden müssen:
postfix.LOCALCONFIG = {
['relayhost'] = "[relay.example.org]:587",
['smtp_sasl_auth_enable'] = "yes",
['smtp_sasl_password_maps'] = "static:SMTPUSER:SMTPPASSWORT",
['smtp_sasl_security_options'] = "noanonymous"
}
(ungetestet, müsste aber eigentlich funktionieren)
Anschließend LiveConfig neu starten (damit diese .lua-Datei eingelesen wird) und danach unter "Serververwaltung" -> "EMail" die Postfix-Konfiguration neu speichern lassen, damit die Einstellungen in die Konfiguration übernommen werden.
Viele Grüße
-Klaus Keppler
Hallo,
weil uns derzeit immer wieder Anfragen dazu erreichen: am 30.05.2020 ist das weit verbreitete Root-CA-Zertifikat "AddTrust External CA Root" abgelaufen.
In zwei Fällen ist das eventuell ein Problem:
Wer Debian 8 oder Ubuntu 16 einsetzt, sollte das (abgelaufene) Root-CA-Zertifikat aus dem Trust-Store entfernen, damit cURL etc. serverseitig keine Probleme machen. Hierzu die Datei /etc/ca-certificates.conf öffnen und ein Ausrufezeichen ("!") an den Beginn der Zeile von "mozilla/AddTrust_External_Root.crt" setzen:
Anschließend den Befehl update-ca-certificates ausführen.
Zu den falsch konfigurierten Zwischenzertifikaten: wir erweitern LiveConfig aktuell, dass es beim Start alle SSL-Intermediates prüft und auf abgelaufene Zwischenzertifikate oder fälschlicherweise konfigurierte Root-CA-Zertifikate hinweist.
Ursprünglich wollten wir diese auch automatisch löschen, das ist aber nicht ganz trivial, da eventuelle Ketten damit ungewollt unterbrochen werden könnten. Wir lassen uns da aber auch etwas einfallen.
Viele Grüße
-Klaus Keppler
Guten Morgen,
Ende letzter Woche informierten uns Hosting-Kunden über Spam-Mails, die mit deren Absendernamen versendet wurden. An sich (leider) nichts Besonderes - wäre es nicht so, dass die Spammails als Antwort auf tatsächliche E-Mails versendet wurden.
(also so, als wenn man eine Mail im Postfach herholt, auf "Antworten" klickt und dann noch einen Trojaner-Anhang dazupackt).
Wir haben dank umfangreicher Unterstützung zweier betroffener Postfachinhaber die Fälle analysieren können und sind zu folgenden Erkenntnissen gekommen:
Wir gehen daher davon aus, dass es irgendeinen deutschprachigen Shop o.ä. gab/gibt, von dem die E-Mail-Adressen und Passwörter der Benutzer entweder im Klartext oder nur unzureichend geschützt abhanden gekommen sind.
Der Versand der Spam/Trojaner-Mails erfolgt übrigens über andere SMTP-Server, sogar mit anderen (nicht passenden) Absenderadressen. Darüber lassen sich die Mails auch erkennen. Verfasst sind diese in deutscher Sprache, meist mit so etwas wie
[INDENT]Sie müssen sich diese Berechnungen ansehen und überprüfen, ob sie korrekt sind.
[/INDENT]
oder
[INDENT]Hier sind die Informationen, die Sie angefordert haben.
[/INDENT]
Um das eigene Mail-Log auf Auffälligkeiten zu untersuchen:
Vor allem Einträge mit nur 1 oder 2 Zugriffen aus "isolierten" Netzbereichen sollten überprüft werden (z.B. mit WhoIs). Stellt sich dann heraus, dass dieser Zugriff aus einem "fremden" Netz war, sollte man mit grep alle IMAP-Zugriffe auf dieses Postfach heraussuchen, die IPs extrahieren und das dann noch mal prüfen. Achtet darauf, dass es auch legitime Kunden in Hongkong, Kasachstan usw. geben kann die auf ihr Postfach zugreifen.
Viele Grüße
-Klaus Keppler
Unsere Testumgebung für Ubuntu 20.04 LTS steht nun auch.
Wie sich in den letzten Tagen herausgestellt hat ist der mit LiveConfig mitgelieferte MariaDB-Client (MariaDB Connector/C 3.1.8) leider nicht mit der auth_socket-Authentifizierung von MySQL 8 kompatibel. Wir klären das gerade mit MariaDB ab.
Für Ubuntu 20 ist das also erstmal ein Showstopper, da der root-Account dort standardmäßig mit auth_socket eingerichtet ist (was ja prinzipiell nicht verkehrt ist). Workaround ist vorerst also die root-Authentifizierung umzustellen (wie in Beitrag #1 beschrieben).
Mit LiveConfig v2.10.0-dev20200522.1 (aktuelle Preview, geht gleich online) funktioniert die Erkennung von MySQL 8 sowie das Anlegen/Bearbeiten/Löschen von Datenbanken. Hier waren aufgrund von Änderungen im Authentifizierungssystem ebenfalls Anpassungen erforderlich.
Viele Grüße
-Klaus Keppler
ZitatWARNING: No clamd server appears to be available
Ganz einfach: der ClamAV-Daemon (meist "clamd") läuft vermutlich nicht.
Also: prüfen ob "clamd" läuft. Wenn nicht, Logs prüfen.
Die häufigsten Ursachen sind:
- zu wenig RAM (ClamAV ist äußerst speicherhungrig)
- kaputte ClamAV-Datenbank
Diese URL soll ja auch nicht vom Browser aufgerufen werden.
Daher noch mal meine Frage: welche Fehlermeldung erzeugt LiveConfig?
(wir nutzen hierfür ein internes CA-Zertifikat mit CA-Pinning)
Was für eine Fehlermeldung wird denn genau erzeugt?
Kurz gesagt: Ubuntu 20.04 wird aktuell von LiveConfig (v2.9.x) noch nicht unterstützt.
Mit den Anpassungen für CentOS 8 sind wir durch, Ubuntu 20 startet diese Woche. Es dürfte also in den nächsten 1-2 Tagen ein Update der Preview-Version geben, mit dem dann zumindest die MySQL-Anbindung schon mal getestet wurde.
Viele Grüße
-Klaus Keppler
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.31, 7.3.18 und 7.4.6 aktualisiert (Repository).
Viele Grüße
-Klaus Keppler
Wie heißt denn Ihr CGI-Ordner?
Weil /cgi-bin/ für alle Domains innerhalb des selben Vertrags immer auf /var/www/<Vertrag>/htdocs/cgi-bin/ gemapped wird (ScriptAlias-Anweisung). Um dieses Verhalten abzuschalten, müssten Sie im LiveConfig in den Vertrags-Einstellungen CGI deaktivieren.
(nicht irritieren lassen; die Einstellung in ~/conf/httpd.conf erlaubt ja CGI dann wieder in den gewünschten Verzeichnissen)
Ob die httpd.conf eingebunden wird sehen Sie z.B. durch einen Blick in /etc/apache2/sites-enabled/<Vertrag>.conf - da gibt es irgendwo dann eine include-Anweisung (einfach in der Datei mal nach "httpd.conf" suchen)
Viele Grüße
-Klaus Keppler
So etwas fällt unter "exotische Sonderfälle". Man kann das einrichten, allerdings nicht über die Oberfläche.
Legen Sie im Kunden-Home-Verzeichnis eine Datei namens "conf/httpd.conf" an (also z.B. /var/www/<Vertrag>/conf/httpd.conf). Tragen Sie da folgende Zeilen ein
Danach (!) speichern Sie im LiveConfig irgendeine Webspace-Einstellung dieses Vertrages neu (z.B: irgendeine Domaineinstellung mal kurz bearbeiten), damit die Apache-vHost-Konfiguration aktualisiert wird. Da wird diese httpd.conf dann mit eingebunden.
Soll heißen das die Blackliste die der User unter der E-Mailadresse eingibt garnicht alle Einträge die dort drinn stehen abweist?
Das wäre ja Fatal! Wenn also SpammAssassin die Adresse als gut befindet geht sie durch und wird zugestellt?
Nein. Die Blacklist/Whitelist-Einträge werden natürlich vom SpamAssassin mit oberster Priorität verarbeitet.
Wenn der Absender auf der Blacklist steht bekommt die Mail praktisch 999 Spam-Punkte, bei der Whitelist -999 Punkte.
Die Blacklist- und Whitelist-Einstellungen werden im LiveConfig unterhalb des Spamfilters konfiguriert und sind nur bearbeitbar, wenn die Checkbox beim Spamfilter gesetzt ist (=Spamfilter aktiviert ist).
Wenn Mails dennoch durch kommen hat das definitiv einen Grund, den man am einfachsten anhand der Log-Einträge in /var/log/mail.log herausfinden kann.
Wenn Sie sich bei der Interpretation der Meldungen unsicher sind, schicken Sie bitte mal von einer "geblacklisteten" Absenderadresse aus mal eine E-Mail und senden uns *alle* Log-Meldungen, die während der Mailzustellung in der mail.log protokolliert werden, an support@liveconfig.com
Das Blacklisting/Whitelisting betrifft SpamAssassin, d.h. die Mail wird ggf. im Rahmen der Spam-Analyse abgelehnt.
Eine Möglichkeit wenn "nichts" passiert wäre, dass SpamAssassin nicht läuft. Prüfen Sie daher bitte mal, ob die Prozesse "lcsam" und "spamd" existieren.
Das Feature mit den TLD-Wildcards ist in v2.10 enthalten (aktuelle Preview-Version).
Zum o.g. Beispiel: es kann z.B. sein dass die betroffenen Spam-Mails über irgendeine andere Adresse ins System kommen (also quasi über eine lokale Weiterleitung); es wird praktisch nur der "erste" Spamfilter ausgewertet.
Beispiel: Weiterleitung von a@example.org an b@example.org. Wenn nun eine E-Mail an a@example.org eintrifft ist egal was bei b@example.org im Spamfilter konfiguriert ist.
In /var/log/mail.log wird eigentlich ziemlich ausführlich protokolliert, was während einer Zustellung passiert. Ggf. müsste man anhand der Message-ID (die man in den Mailheadern auslesen kann) im Maillog suchen, was genau während der Zustellung gelaufen ist.
In der Datei /etc/dovecot/passwd sehen Sie die Zuordnung von E-Mail-Adresse (Postfach) zu Verzeichnisname (/var/mail/<Vertrag>/<Postfach-ID>/). Sie müssen also die Postfächer im LiveConfig neu anlegen, danach können Sie die Postfachinhalte aus dem Backup in die entsprechenden Verzeichnisse zurück verschieben.
Ihnen ist schon bewusst, dass das unnötige Ressourcen kostet wenn wir Ihnen die Frage erst am Telefon beantworten und Sie danach die exakt selbe Frage noch mal im Forum stellen...?
ZitatEin API Komando hat einen Vertrag in die ewigen Jagdgründe befördert.
Was für ein API-Kommando soll das denn überhaupt gewesen sein?
ZitatWir haben bei dieser Gelegenheit festgestellt, das dass Backup der LC Datenbank nicht so läuft wie es soll, somit ist dass keine Option.
Wie genau sichern Sie Ihre LiveConfig-Datenbank aktuell?
Und zur eigentlichen Frage (wie auch am Telefon schon so beantwortet): wenn Sie Daten in LiveConfig löschen, dann sind diese weg. Wenn Sie kein Backup der LiveConfig-Datenbank haben, gibt es nur die Möglichkeit, den betroffenen Vertrag wieder neu anzulegen.
Viele Grüße
-Klaus Keppler
Natürlich.
Ich halte persönlich überhaupt nichts davon, Mails automatisch in einen Spam-Ordner zu verschieben - das macht garantiert nur mehr Ärger. Die Zeit sollte man viel lieber in die Pflege & Tuning der Spamfilterung stecken, damit das Zeug überhaupt nicht erst rein kommt.