CachyOS Update bringt Info dovecot 2.4 Eingriff erforderlich

BxBender

F@H-Team-Member (m/w)
Hallo.

Habe gerade mein CachyOS aktualisiert.
Da kommt die Nachricht siehe unten.
Soll da jetzt jeder User aktiv werden?
Das Programm kenne ich nicht.
Hat das was mit Mail- und Webserver zu tun?
Scheint so, als wenn 2.3er Konfiguratinsdateien nicht mehr mit 2.4 kompatibel sind und umgeändert werden müssen.
Würde man irgendwann mal in Zukunft mit dem Programm etwas machen wollen oder müssen, dann ist das doch jetzt egal und er nimmt automatisch die Konfigurationsdatei der neuen überarbeiteten Datei als Ausgangspunkt, korrekt?
Ich werde sicherlich später deswegen auch von meinem Arbeitskollegen per Telegram penetriert.
Wäre gut, wenn jemand mit Ahnung für uns Vollpfosten da draußen eine kurze Statusmeldung und Entwarnung raushauen könnte.
Danke schön. :-)

Arch Linux Nachrichten​


  • dovecot >= 2.4 requires manual intervention

Fri, 31 Oct 2025 21:20:51

https://archlinux.org/news/dovecot-24-requires-manual-intervention/

The dovecot 2.4 release branch has made breaking changes which result in it being incompatible with any <= 2.3 configuration file.


Thus, the dovecot service will no longer be able to start until the configuration file was migrated, requiring manual intervention.


For guidance on the 2.3-to-2.4 migration, please refer to the following upstream documentation: Upgrading Dovecot CE from 2.3 to 2.4


Furthermore, the dovecot 2.4 branch no longer supports their replication feature, it was removed.


For users relying on the replication feature or who are unable to perform the 2.4 migration right now, we provide alternative packages available in [extra]:


  • dovecot23
  • pigeonhole23
  • dovecot23-fts-elastic
  • dovecot23-fts-xapian

The dovecot 2.3 release branch is going to receive critical security fixes from upstream until stated otherwise.
 
Interessanterweise hatte ich diesen Hinweis bzw. Software-Update nicht. Womöglich ist es bei mir nicht installiert gewesen. Kann ja gut sein, wenn ich keine Software nutze, die darauf zurückgreifen würde.
Dafür habe ich mal wieder (temporär) diesen AMDGPU bedingten Overdrive-Bug, der für eine Verlängerung des Bootvorgangs sorgt ... :-|
 
Zuletzt bearbeitet:
Auch kannst Du den RPC port 111 schliessen @BxBender wenn Du ihn nicht benötigst.

RPC Dienst stoppen und deaktivieren. (Befehle Funktionieren in Debian und Forks wie auch unter Arch und Forks.)

Im Terminal folgende Befehle eingeben als sudo:

systemctl stop rpcbind

systemctl disable rpcbind

systemctl mask rpcbind

systemctl stop rpcbind.socket

systemctl disable rpcbind.socket

:daumen:

 
Zuletzt bearbeitet:
Warum ist denn rpc überhaupt aktiv, wenn man den nicht explizit eingerichtet hat?
Ist in der heutigen Zeit eigentlich nicht der Standardfall.
 
Es gibt Dienste, die bei einer Standartinstallation mitinstalliert werden und dann schlummern, dann gilt es, dass eigene System einmal zu überprüfen und nicht benötigte Dienste wie auch offene Ports zu schliessen.
 
Zuletzt bearbeitet:
Warum ist denn rpc überhaupt aktiv, wenn man den nicht explizit eingerichtet hat?
Ist in der heutigen Zeit eigentlich nicht der Standardfall.
Kommt vielleicht drauf an. Ich habe schon "Post" bekommen, weil er offen war. Ich bekomme das Szenario nicht mehr ganz zusammen, aber ich denke, dass das im Zusammenhang mit neu installierten Proxmox- oder Debiansystemen stand, bevor die Firewall eingerichtet war. Wenn "heutige Zeit" innerhalb des letzten Jahres ist, dann kann das bei diesen Systemen, die einen zweijährigen Zyklus haben, schon sein, dass das da noch nicht angekommen ist. Könnte sein, dass das bei Debian 13 und PVE 9 nicht mehr der Fall ist, aber ich bin gerade zu faul, das auszutesten. ;)
 
Der Befehl funktioniert auch bei anderen Distris.
Na fein, ich habe ein paar Distros in VMs. Tatsächlich sogar ein Debian 13, hatte ich nicht mehr auf dem Schirm.

rpcinfo ist wohl standardmäßig nur auf Fedora installiert, fehlt aber bei Debian, Kubuntu, Ubuntu, Mint und LMDE.

Aber laut ss wird in keiner der Distros auf Port 111 gelauscht. Also vielleicht doch nur ein PVE-Ding und vielleicht auch da inzwischen geändert. Eventuell setze ich demnächst ein neues PVE-System auf, vielleicht denke ich da mal daran, das zu prüfen.
 
In Siduction z.B, basiert ja auf Debian sid, habe ich den Dienst ausgeschaltet, auch den ssh Dienst, brauche ich schlicht und ergreifend nicht, wer ihn braucht, lässt ihn halt laufen.

Den ssh Dienst löschen z.B unter Debian und Forks:

sudo apt-get --purge remove openssh-client openssh-server
 
Zuletzt bearbeitet:
Zurück