Fedora 20

Geschiedene Leute - Cron mit Sendmail neu verheiraten

Seit dem Fedora Release 20 wird Sendmail nicht mehr standardmäßig installiert. Diese Maßnahme ist auf https://fedoraproject.org/wiki/Changes/NoDefaultSendmail detailliert begründet und ist im Ergebnis voll und ganz nachvollziehbar. Dennoch hat es mich schmerzhaft getroffen, denn ich setze bei der Überwachung meiner Rechner voll und ganz auf das Medium E-Mail. Und das funktioniert nun auf einmal nicht mehr wie gewohnt.

In grauen Vorzeiten habe ich meine Rechner mit der Monitoring-Software „Big Brother“ überwacht, doch dann wurde „Big Brother“ nicht mehr weiterentwickelt (zumindest nicht als open source, wenngleich die Firma Quest noch länger eine kommerzielle Variante pflegte). Den Schritt zu „Nagios“ habe ich nicht vollzogen, denn das schien mir damals für meine Zwecke ein bißchen oversized. Heute habe ich eine Menge selbst geschriebener bash-Scripte, die meine Rechner genauer unter die Lupe nehmen und sich regelmäßig durch die Verzeichnisbäume kämpfen, um nach dem Rechten zu schauen. Diese Scripte werden zu klar definierten Zeitpunkten vom Cron-Daemon, der dafür zuständig ist, abgearbeitet. Das Ergebnis bekomme ich dann als E-Mail zugestellt. Da ist es natürlich schlecht, wenn Fedora keine E-Mails mehr zustellen kann.

Im Prinzip ist es ja eine Kleinigkeit Sendmail nach zu installieren. Denn es ist ja nach wie vor in den Fedora-Repositorys vorhanden. Auch ist Sendmail bei weitem einfacher zu konfigurieren als gemeinhin nachgesagt. So weit, so gut. Doch diesmal gab es Schwierigkeiten, denn trotz korrekt funktionierendem Sendmail war Cron nicht in der Lage seine E-Mails über Sendmail zu versenden. Und die Ursache hierfür war wider Erwarten nicht Sendmail, sondern Cron.

Eigentlich logisch: Cron verwendet für seine Ausgaben standardmäßig einen MTA (Mail Transport Agent, also z.B. Sendmail). Da dieser aber nun fehlt, haben die Fedora Entwickler Cron dahingehend umgestrickt, keinen MTA mehr zu verwenden. Aber weil sie schlau sind, haben sie dem Benutzer die Möglichkeit eingeräumt Cron anzuweisen doch einen MTA zu verwenden, nur leider ein klein wenig undokumentiert. Da kann man den Fedora-Leuten aber keinen Vorwurf machen, denn eigentlich ist immer alles vorzüglich dokumentiert. Vieleicht habe ich es auch einfach nicht gefunden. Um anderen ähnliche Qualen wie mir zu ersparen, zeige ich hier, wie es geht:

Schauen wir uns zunächst den Status eines bereits laufenden Cron-Daemons in der Fedora 20 Standardeinstellung an:

[root@tmp1 ~]# systemctl status crond.service 
crond.service - Command Scheduler 
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled) 
   Active: active (running) since Mo 2014-04-28 14:35:13 CEST; 7s ago 
 Main PID: 16333 (crond) 
   CGroup: /system.slice/crond.service 
           └─16333 /usr/sbin/crond -n 

Apr 28 14:35:13 tmp1 systemd[1]: Started Command Scheduler. 
Apr 28 14:35:13 tmp1 crond[16333]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 97% if used.) 
Apr 28 14:35:13 tmp1 crond[16333]: (CRON) INFO (running with inotify support) 
Apr 28 14:35:13 tmp1 crond[16333]: (CRON) INFO (@reboot jobs will be run at computer's startup.) 
[root@tmp1 ~]#

Nun editieren wir die Datei /etc/sysconfig/crond, so daß sie wie folgt aussieht:

# Settings for the CRON daemon. 
# CRONDARGS= :  any extra command-line startup arguments for crond 
CRONDARGS=-m '/usr/sbin/sendmail -t'

Vergessen Sie keinesfalls die einfachen Anführungszeichen um /usr/bin/sendmail -t. Das ist deshalb wichtig, weil die t-Option eine Sendmail-Option und keine Cron-Option ist. Die m-Option gehört allerdings sehr wohl zu Cron. Sie ist genau die Option, die Cron anweist einen MTA zu verwenden.

Mit systemctl restart crond.service starten wir nun Cron neu und schauen uns anschließen erneut den Systemstatus von Cron an:

[root@tmp1 ~]# systemctl status crond.service 
crond.service - Command Scheduler 
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled) 
   Active: active (running) since Mo 2014-04-28 14:37:33 CEST; 6s ago 
 Main PID: 16343 (crond) 
   CGroup: /system.slice/crond.service 
           └─16343 /usr/sbin/crond -n -m /usr/sbin/sendmail -t 

Apr 28 14:37:33 tmp1 systemd[1]: Started Command Scheduler. 
Apr 28 14:37:33 tmp1 crond[16343]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 59% if used.) 
Apr 28 14:37:33 tmp1 crond[16343]: (CRON) INFO (running with inotify support) 
Apr 28 14:37:33 tmp1 crond[16343]: (CRON) INFO (@reboot jobs will be run at computer's startup.) 
[root@tmp1 ~]#

Nun erkennt man sehr schön den Unterschied. Während zuvor der Cron-Aufruf /usr/sbin/crond -n lautete, ist nun, nach dem Neustart, /usr/sbin/crond -n -m /usr/sbin/sendmail -t daraus geworden. Auch wenn bei dieser Darstellung die einfachen Anführungszeichen fehlen, so funktioniert Cron doch nun wieder wie erwartet.

Wer Spaß am experimentieren hat, kann ja mal die einfachen Anführungszeichen weglassen, um dann zu sehen, daß Cron in diesem Fall nicht startet, weil es das -t dann als eigene Option interpretiert. Und die kennt es nicht. Wer nicht gerne experimentiert, muß es mir halt einfach glauben.