Beiträge von antondollmaier

Zitat von weltmeister

Nun die Frage: kann man nicht eine Funktion einbauen, die Weiterleitungen nur bei aktiven Spamfilter erlaubt um solche Überraschungen künftig möglichst zu vermeiden?

Nö, ja, nein.

mit dem aktuellen Postfix-Setup? Nein. Weiterleitungen gehen vor Spamfilter.

Mit Dovecot könnte man mit Sieve-Regeln arbeiten, die dann nen redirect machen. Braucht dann aber Postfächer.

Und nein: neben dem Aspekt, dass du Mails nicht als Spam erkennst, Google etc aber schon ... kommt noch das Problem SPF dazu (geht mir weg mit SRS).

Wir haben die großen Anbieter und alle, die rumzicken, daher als Weiterleitungsziele gesperrt und lösen die bestehenden Weiterleitungen konsequent auf.

Zitat von WebService4U

Mich hat es heute getroffen. 350 Euro NETTO monatliche Servicegebühr, 5400 Domains.

https://www.smart-nic.services/

Grüße von mir ausrichten. Migration-Script InterNetX->Domain-Bestellsystem liegt hier

Alternativvorschlag:

Was spricht dagegen, direkt die LiveConfig-URL ohne die zusätzliche URL, zu verwenden? Läuft bei uns (und den Kunden) super. Ja, nicht so "schick" wie die direkte End-URL, dem Endkunden dürfte es aber ziemlich egal sein, welche URL einmalig in den Router geworfen wird.

Alternativvorschlag: Weiterleitung auf:

http://127.0.0.1:82/liveconfig/hosting/

Und dann über "https://ddns.example.com/dnsupdate?hostname=" ansprechen?

Yay for SSH-Key-Verwaltung! Yay OAuth! Schade, dass es erst auf Grund des MCP-Servers kam

Guter Ansatz, aber Achtung: das bricht bei Microsoft dann SPF. Du musst unbedingt dann deine IP(s) in die SPF-Ausnahme stecken, damit Microsoft die Weiterleitungen nicht wegen SPF-Fail rejected.

Das ist (derzeit) nicht lösbar.

Dafür müsste LiveConfig die Domain aus der Postfix-Konfiguration (`virtual_domains`) rausnehmen. Das ist derzeit aber nicht vorgesehen.

Unsere Kunden haben regelmäßig das selbe Problem, schaffen sich aber dann nochmals eigene oben drauf (SMTP-Postfächer, die sie dann nachträglich auf der Office365-Domain in LiveConfig erstellen und sich wundern, warum plötzlich die Mails aus dem Web-Formular nicht mehr ankommen).

Betrifft die Domain-Reseller. Wird vermutlich bei kleineren erstmal probiert, bevor es dann alle erwischt.

Wir sind seit 2013 bei http://www.smart-nic.services und sehr zufrieden.

Der Transfer des Bestands ist aber so oder so ein riesen Aufwand, egal, wohin gewechselt werden soll - noch mehr, sobald ihr selbst noch Reseller habt.

LiveConfig macht hier nichts anderes, als "/usr/bin/crontab -u web25" aufzurufen.

Gibt es da ggf. eine cron.allow/cron.deny?

Zitat

Look into the files "/etc/cron.allow" and "/etc/cron.deny"

Bei LiveConfig2 lässt sich der Mailserver nicht nachträglich über die GUI/SOAP ändern. Ich befürchte, das hat sich mit LiveConfig3 nicht geändert.

=> entweder manuell in der Datenbank anpassen und die System-Änderungen selbst nachziehen, oder den Vertrag komplett neu erstellen.

Was genau soll da unterstützt werden?

Zitat von kk

Nuja, das Debian-Team in allen Ehren - aber "verdammt schnell" wäre ein Datum zwischen dem Mainline-Patch (01.04.2026) und dem CVE-Assignment (22.04.2026) gewesen. Zudem patcht dieses Kernel-Update 303 (!) CVEs.

Keine Frage, das wäre besser gegangen.

Was ich aber mitbekommen habe, war, dass lediglich das Kernel-Team über die Schwere der Lücke und die Responsible Disclosure informiert wurde, aber keines der Distri-Teams. Und da finde ich Donnerstag Vormittag bis Freitag Abend schon schnell. Feiertag war ja auch (in DE) auch noch.

Das Debian-Team war verdammt schnell: inzwischen sind offizielle Kernel-Updates für Bullseye, Bookworm, und Trixie verfügbar:

https://security-tracker.debian.org/tracker/CVE-2026-31431

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to system scope bus via local transport: Der Rechner ist nicht aktiv

Ist das ein Debian-System, das von Debian 9 aus hochgezogen wurde?

Da scheint mehr im Argen zu sein. Das fehlende /run/liveconfig-Verzeichnis hätte ich jetzt adhoc noch als LiveConfig-Problem abtun können, aber mit dem zweiten Fehler ist das sowas von kein LiveConfig-Problem mehr...

Bitte prüfe dringend dein System. Da scheint Systemd große Probleme zu haben.

Zitat von informant

Hallo, wie bei mir oben im Post ersichtlich habe ich das bei uns bereits getan, es erscheint dennoch nirgends im v2 Web-Interface eine Option zum einstellen. Habe es auf 3 eMail Servern die in der großen Lizenz höngen mit v2 getestet. Nirgends erscheint es bei mir.

Der Screenshot von Klaus ist aus LiveConfig v3. In v2 scheint es nicht mehr integriert worden zu sein.

Zitat von weltmeister

Wann gibt es diese Funktion? Das wäre eine große Hilfe, vor allem bei Kunden, die immer wieder anfragen... wäre das eine sorge weniger.

Geht doch schon: lcphp:

Thema

PHP-CLI Version einstellen

Ich würde gerne meine Default-PHP-CLI Version umstellen und habe nun folgendes gemacht:

(Quelltext, 1 Zeile)


Damit meine php-7.4-opt automatisch als CLI genommen wird, habe ich einen Symlink /usr/bin/php.default nach /opt/php-7.4/bin/php erstellt:

(Quelltext, 1 Zeile)


Es funktioniert - aber ist das der gedachte Weg oder hab ich irgendwo was übersehen?

clickpress

6. Januar 2021

Das dürfte vorrangig an den Hetzner-IPs liegen. Wir haben aktuell keine Probleme.

Zitat von weltmeister

Das wäre schlecht. Wie gesagt, 99,99% aller Kunden wissen wirklich nicht, das man erst den Haken in LiveConfig setzen muss

Wir haben die Selbstverwaltung der Postfächer über den LCDEFAULTS "mail.weblogin.enabled=1" pauschal aktiv. Es gibt, IMHO, nur wenige Gründe, weshalb sich die Postfach-Nutzer nicht selbst anmelden können dürfen.

https://xkcd.com/936/

Tut es.

Wir trennen in unseren Cloud-Umgebungen unter Debian die Mount-Punkte auf:

• das Betriebssystem mit Logs, Konfiguration etc (/boot hat keine Relevanz)
• /var/www für die Webseiten. Das Dateisystem-Quota kann bequem im laufenden Betrieb aktiviert werden.
• /var/lib/mysql für ... mySQL.
• /var/mail für Mail

Quotas sind somit effektiv nur auf /var/www notwendig.

Nebeneffekt: ein voller /var/www-Mountpunkt macht der Datenbank nichts aus.

Ich freue mich natürlich über eine Rückmeldung, ob die Anleitung bei dir funktioniert.

Wir haben ein (Python-)Script mit Cache, das Mails ähnlich dem Mail-Quota rausschickt. Wäre aber dennoch schön, wenn das integriert wäre, auch wenn die Mailadresse nicht für jeden Endkunden verpflichtend ist.