• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

SLES 11 - crontab sendet immer mails

Rumak18

Member
Hallo,

ich habe seit dem Upgrade auf Patchlevel 1 das Problem, dass mein Linux AB UND AN (mal sind es zwei, mal drei Tage unterschied) IMMER UM 13:00 ein Mail von root@SLESS11hostname an die hinterlegene E-Mail Adresse unter aliases bei root versucht zu senden. Die etc/crontab sieht aber so aus:
Code:
SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=root
#
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
#
-*/15 * * * *   root  test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1
45 20 * * 4 root /temp/sicherung.sh >/dev/null 2>&1
Es läuft sozusagen nur wöchentlich der Backup Job und das um 20:45 und nicht um 13:00.
Hat Jemand eine Idee, woher diese E-Mail rühren kann?
 

HBtux

Member
.
Hinweis Nr. 1
Code:
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
Schaue mal nach den cron.daily usw....


Was steht denn überhaupt in dem E-Mail drinnen?
Aus dem E-Mail müsste sich doch ein Hinweis auf das ausgeführte Programm ergeben.....

In der Log-Datei /var/log/messages steht übrigens auch, welche Cron-Jobs wann ausgeführt wurden......
 
OP
R

Rumak18

Member
Also,
"crontab -l" liefert erst mal nichts (no crontab for root).

Und unter den anderen crontabs habe ich folgendes gefunden:
Code:
cron.daily:
total 48
drwxr-xr-x   2 root root  4096 Jun 17 14:15 .
drwxr-xr-x 102 root root 12288 Aug  9 08:46 ..
-rwxr-xr-x   1 root root   587 Feb 21  2009 logrotate
-rwxr--r--   1 root root   948 Feb 21  2009 suse-clean_catman
-rwxr--r--   1 root root  1693 Feb 21  2009 suse-do_mandb
-rwxr-xr-x   1 root root  1875 Sep  1  2003 suse.de-backup-rc.config
-rwxr-xr-x   1 root root  2059 Sep  8  2003 suse.de-backup-rpmdb
-rwxr-xr-x   1 root root   566 Jul 23  2004 suse.de-check-battery
-rwxr-xr-x   1 root root  1314 Jul 27  2005 suse.de-clean-tmp
-rwxr-xr-x   1 root root   371 Sep  1  2003 suse.de-cron-local
Aber ich sehe ja hier nicht wirklich , wann diese Jobs laufen. Wo wird denn definiert wann die "daily", "monthly" und "yearly" jobs laufen?
 
OP
R

Rumak18

Member
Hallo,
in /var/spool/cron/lastrun/ existiert der Eintrag "cron.daily" und er wurde auch genau um die Uhrzeit ausgeführt. Doch was macht er denn? Wo wurde er konfiguriert und vor allem, wie kann ich ihn wieder deaktivieren?
 

HBtux

Member
noch mal meine Frage....
Was steht denn in der Mail bzw. in der Log-Datei /var/log/messages drinnen?

Über den Inhalt der Mail müsstest Du doch herausbekommen, welches Script über z.B. cron.daily gestartet wurde.....
 

Tooltime

Advanced Hacker
Rumak18 schrieb:
Hallo,
in /var/spool/cron/lastrun/ existiert der Eintrag "cron.daily" und er wurde auch genau um die Uhrzeit ausgeführt. Doch was macht er denn? Wo wurde er konfiguriert und vor allem, wie kann ich ihn wieder deaktivieren?
Schau mal unter /etc/cron.daily nach, dort sollte man den Übeltäter finden.
 
OP
R

Rumak18

Member
@HBtux:
Da steht irgendwie nicht wirklich was zu cron. Wenn ich mir das Log ansehen, zu welcher Uhrzeit die Mail losgeschickt worden ist, dann steht dort:
Aug 14 13:00:02 svr-linux syslog-ng[1729]: Configuration reload request received, reloading configuration;
Aug 14 13:00:02 svr-linux syslog-ng[1729]: New configuration initialized;
Aug 14 13:00:03 svr-linux xinetd[2814]: Starting reconfiguration
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/chargen [file=/etc/xinetd.conf] [line=26]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/chargen-udp [file=/etc/xinetd.d/chargen-udp] [line=14]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/cups-lpd [file=/etc/xinetd.d/cups-lpd] [line=15]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/daytime [file=/etc/xinetd.d/daytime] [line=11]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/daytime-udp [file=/etc/xinetd.d/daytime-udp] [line=14]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/discard [file=/etc/xinetd.d/discard] [line=15]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/discard-udp [file=/etc/xinetd.d/discard-udp] [line=14]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo] [line=15]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/echo-udp [file=/etc/xinetd.d/echo-udp] [line=14]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/netstat [file=/etc/xinetd.d/netstat] [line=15]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/rsync [file=/etc/xinetd.d/rsync] [line=16]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/sane-port [file=/etc/xinetd.d/sane-port] [line=12]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/servers [file=/etc/xinetd.d/servers] [line=14]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/services [file=/etc/xinetd.d/services] [line=14]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/swat [file=/etc/xinetd.d/swat] [line=14]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/systat [file=/etc/xinetd.d/systat] [line=12]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=17]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/time-udp [file=/etc/xinetd.d/time-udp] [line=15]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/vnc [file=/etc/xinetd.d/vnc] [line=15]
Aug 14 13:00:03 svr-linux xinetd[2814]: Reading included configuration file: /etc/xinetd.d/vsftpd [file=/etc/xinetd.d/vsftpd] [line=90]
Aug 14 13:00:03 svr-linux xinetd[2814]: Swapping defaults
Die E-Mail selber erhalte ich leider nicht, weil der MTA, der sie zuerst empfängt sie dann an das Ziel versucht zu verschicken , die E-Mail aber gebounct wird weil der Absender root@svr-linux.localdomain lautet. Ich sehe nur in den Logs des MTAs, dass der Ziel Mailserver diese Mail abgelehnt hat.

@Tooltime:
Wie schon erwähnt, es liegen hier mehrere Scripte vor, weiß aber nicht welches denn nun die E-Mail auslöst und vor allem, warum um 13:00. Cron.daily sollte doch standardmäßig um 00:00 laufen oder nicht ?
-rwxr-xr-x 1 root root 587 Feb 21 2009 logrotate
-rwxr--r-- 1 root root 948 Feb 21 2009 suse-clean_catman
-rwxr--r-- 1 root root 1693 Feb 21 2009 suse-do_mandb
-rwxr-xr-x 1 root root 1875 Sep 1 2003 suse.de-backup-rc.config
-rwxr-xr-x 1 root root 2059 Sep 8 2003 suse.de-backup-rpmdb
-rwxr-xr-x 1 root root 566 Jul 23 2004 suse.de-check-battery
-rwxr-xr-x 1 root root 1314 Jul 27 2005 suse.de-clean-tmp
-rwxr-xr-x 1 root root 371 Sep 1 2003 suse.de-cron-local
 

Tooltime

Advanced Hacker
Ups, hatte ich nicht gesehen das du das Verzeichnis schon gefunden hast. Prinzipiell kann jedes der Scripte schuld sein, sobald es eine Ausgabe via Standartausgabe oder Standartfehlerausgabe macht. Cron schickt diese dann per Mail an den Besitzer der crontab, solange man nicht ein anderes Ziel definiert. Damit könnte die Mail eine normale Statusmeldung von einem Script sein, oder ein temporärer Fehler bei der Ausführung.

Mit SLES kenne ich mich nicht aus, bei openSUSE wird crondaily aber nicht zu einer bestimmten Zeit, sondern alle 24 Stunden ausgeführt. Es wird alle 15 Minuten kontrolliert ob das letzte Ende eines crondaily-Lauf schon länger als 24 Stunden her ist. So das bei einem Rechner der durchläuft, jeder crondaily-Lauf um (mindestens) 15 Minuten weiter wandert.

Zurück zu deinem Problem, ich würde ersteinmal dafür sorgen das die Mail einen sinnvollen Empfänger erreicht. Wenn das System schon mal meint root sollte eine bestimmte Information erhalten, dann sollte man dafür sorgen das diese nicht irgendwo stecken bleibt. Entweder gehört sie ins lokale Postfach des Rechners, oder besser in das reale Postfach vom Admin. Alles andere macht meiner Meinung keinen Sinn.
 
OP
R

Rumak18

Member
Code:
Zurück zu deinem Problem, ich würde ersteinmal dafür sorgen das die Mail einen sinnvollen Empfänger erreicht. Wenn das System schon mal meint root sollte eine bestimmte Information erhalten, dann sollte man dafür sorgen das diese nicht irgendwo stecken bleibt. Entweder gehört sie ins lokale Postfach des Rechners, oder besser in das reale Postfach vom Admin. Alles andere macht meiner Meinung keinen Sinn.
Ja, das würde ich ja gerne. Aber ich weiß nicht genau wie... Wie kann ich dafür sorgen, dass es in das lokale Postfach gelangt bzw. einen korrekten Absender enthält?
Ersteres wird wohl in der alias zu lösen sein, in der ich einfach den Eintrag
root: externe@emailadresse.de
auf
root: root
ändere oder?

Bei der zweiten Möglichkeit habe ich keinen Schimmer.
 

Tooltime

Advanced Hacker
Rumak18 schrieb:
Ja, das würde ich ja gerne. Aber ich weiß nicht genau wie... Wie kann ich dafür sorgen, dass es in das lokale Postfach gelangt bzw. einen korrekten Absender enthält?Ersteres wird wohl in der alias zu lösen sein, in der ich einfach den Eintragroot: externe@emailadresse.deauf root: rootändere oder?
Interessante Idee einen Alias von root auf root zu legen, ich würde den Alias einfach löschen bzw. auskommentieren.

Um bei ausgehenden Mails die Adressen zu ändern, fällt mir spontan /etc/postfix/sender_canonical ein. Es sei denn du musst nur die Absenderdömäne kürzen, Rechner.Domäne.Tld auf Domäne.Tld, dafür gibt es Masquerading. Wie muss denn die Absenderadresse verändert werden?

PS:
Momentan habe ich nicht soviel Zeit, von daher kann das immer ein bischen dauern bis ich mich wieder melde.
 
OP
R

Rumak18

Member
Ich habe mir schon fast gedacht, dass DAS
Um bei ausgehenden Mails die Adressen zu ändern, fällt mir spontan /etc/postfix/sender_canonical ein.
kommt. Ich hätte das selber auch so gemacht oder über /etc/postfix/virtual, doch WIESO ist hier postfix daran beteiligt bzw. wie kommst DU da drauf ohne meinen Server gesehen zu haben? Was wäre, wenn postfix deinstalliert wäre? Hätte es hier nicht einen anderen Daemon geben KÖNNEN, der die Mails verschickt?
Ich werde das mit canonical mal testen und berichten. Habe aber selber nicht sehr viel Zeit.... :D
 

Tooltime

Advanced Hacker
Rumak18 schrieb:
doch WIESO ist hier postfix daran beteiligt bzw. wie kommst DU da drauf ohne meinen Server gesehen zu haben? Was wäre, wenn postfix deinstalliert wäre? Hätte es hier nicht einen anderen Daemon geben KÖNNEN, der die Mails verschickt?
a) Bis jetzt habe ich noch nie gesehen, das man die Versandart oder so etwas wie einen speziellen MTA bei CRON einstellen kannn, anderseits ein Standalone-Maschiene seine User nur über den lokalen MTA erreicht. Und der ganze Mechanisnus schon ziemlich alt ist und daher wahrscheinlich den guten alten sendmail-Befehl nutzt.
b) /etc/aliases ist eine Konfigurationsdatei für den lokalen MTA.

Ich versuche prinzipiell Fragen zur MTA-Konfiguration zu vermeiden, da mir meistens etwas auffällt was ich für absoluten Murks halte, dessen Behebung mir zu anstregend ist. Seien wir doch mal ehrlich. Wieso hast du bis jetzt noch nicht erzählt auf welche Weise die Mail auf deine Wunschadresse umgeleitet wird? Warum hat der Kollege, der das verzapft hat nicht mal die Funktion getestet. Und wenn es schon nicht funktioniert wenigstens alles wieder zurück gebaut, damit die Mails lokal verfügbar sind? Jedenfalls klingt das ganze für mich schon ein bisschen merkwürdig, so in der Art, zuviele Leute haben schon an zuvielen Schrauben gedreht.
 
OP
R

Rumak18

Member
Wieso hast du bis jetzt noch nicht erzählt auf welche Weise die Mail auf deine Wunschadresse umgeleitet wird?
Weil ich es nicht genau weiß! Weil ich die Installation als Linux Newbie mitgemacht habe und somit mich einer klaren Aussage enthalte, weil ich es nicht weiß! Es muss ja nicht immer gleich ein Komplott hinter einem Forenbeitrag stecken ;)

Warum hat der Kollege, der das verzapft hat nicht mal die Funktion getestet.
Er hat es wohl getestet, nur dieses "Versenden" , welches fehlschlägt, tritt erst seit dem Update auf SP1 auf. Davor gab es diese Phänomen ja nicht. Habe ich aber auch bereits geschrieben.

Jedenfalls klingt das ganze für mich schon ein bisschen merkwürdig, so in der Art, zuviele Leute haben schon an zuvielen Schrauben gedreht.
Es waren genau zwei Leute und versuche mich eben, in diese Thematik einzuarbeiten.
 

Tooltime

Advanced Hacker
Vielleicht habe ich ein bischen übertrieben, aber solange wie die Geschichte schon läuft hatte ich schon vergessen was in den vorherigen Beiträgen steht. Was mir so ein bischen fehlt sind halt die konkreten Fakten zu der ganzen Kette, z.B. wir haben in der /etc/aliases folgendes eingetragen, der Hostname sieht so aus, .... Die realen Namen sind nicht so wichtig, aber z.B. offizielle oder interner Domänenname, bei internen Domänennamen wie lautet die TLD. Aber egal.

Ich gehe jetzt mal davon aus, das die Umleitung in der /etc/aliases geschieht. Dann splitten wir erst einmal die Probleme. Ändere den Eintrag in /etc/aliases in
  • root: name@mail.adresse, \root
Dann bekommt root eine Kopie ins lokale Postfach, aber nicht den Backslash vergessen. Damit die Änderungen wirksam werden musst du den Befehl newaliases ausführen. Testen kannst du das ganze mit dem mail Befehl.
  • mail -s "Test Mailweiterleitung" root@localhost
    Text
    .
Wichtig ist der einzelne Punkt in der letzten Zeile dem direkt ein Zeilenvorschub folgen muss, er beendet die Maileingabe.

Zum gewünschten Mailempfänger:
  • Ist das ein interner (eventuell mit Zugriff) oder externer Mailserver?
    Hat der SuSE-Server einen offiziellen Hostnamen?
    Hast du eine Ahnung wie die Absenderadresse aussehen muss?
    Funktioniert das Umschreiben des Absenders?
    Beobachte mal /var/log/mail (tail -f /var/log/mail), schicke eine Testmail wie oben beschrieben, welche Meldungen laufen auf?
 
OP
R

Rumak18

Member
Also,
ich habe deine Anweisungen befolgt.
root hat nun eine Kopie erhalten. Es handelt sich hierbei um eine E-Mail von cron.daily und zwar genauergesagt, das logrotate Script. Anscheinend gibt es da ab und an Probleme mit vsftpd und dann wird eben die E-Mail generiert. So... nun habe ich also noch das Problem, dass eine "falsche" E-Mail Adresse als Absender benutzt wird, die sofort von Providern gebounced wird, weil es die Domain im DNS gar nicht gibt. Diese würde ich also gerne umschreiben. Ich habe auch gleich direkt unter /etc/postifx/sender_canonical den Eintrag hinzugefügt:
root@SLESS11hostname.slesdomain benutzer@registrierteDomain

Ich hoffe das das so klappen wird. Aber was mich irritiert ist, dass "canonical" anscheinend auch die "Header" einer E-Mail umschreibt, was ich aber nicht wirklich möchte. Virtual und alias sind ja hierfür wohl auch ungeeignet. Wie könnte ich NUR den "envelope" der Versender E-Mail Adresse ändern und die Header belassen?
 
OP
R

Rumak18

Member
So: Nun habe ich dank der /etc/postfix/sender_canonical die E-Mail zugestellt bekommen.
Der genau Inhalt lautet:

running daily cronjob scripts
SCRIPT: output (stdout && stderr) follows
Reload INET services (xinetd)...done
SCRIPT: logrotate
------- END OF OUTPUT
Weiß somit an sich auch nicht , wie ich das abstellen könnte, denn so wie es aussieht, ist ja alles korrekt verlaufen. HELP!

P.S.: Das logrotate Script unter cron.daily sieht so aus:
if checkproc /usr/sbin/logrotate; then
/bin/logger -t logrotate "ALERT another instance of logrotate is running - exiting"
exit 1;
fi;

TMPF=`mktemp /tmp/logrotate.XXXXXXXXXX`

/usr/sbin/logrotate /etc/logrotate.conf 2>&1 | tee $TMPF
EXITVALUE=${PIPESTATUS[0]}

if [ $EXITVALUE != 0 ]; then
# wait a sec, we might just have restarted syslog
sleep 1
# tell what went wrong
/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
/bin/logger -t logrotate -f $TMPF
fi

rm -f $TMPF
exit 0
~
~
 

Tooltime

Advanced Hacker
Rumak18 schrieb:
Wie könnte ich NUR den "envelope" der Versender E-Mail Adresse ändern und die Header belassen?
Gibt es denn überhaupt einen Absender im envelop? Ich kenne nur die Möglichkeit das Ziel einer Mail durch den Envelope zu ändern.

Rumak18 schrieb:
Weiß somit an sich auch nicht , wie ich das abstellen könnte, denn so wie es aussieht, ist ja alles korrekt verlaufen. HELP!
Habe zwar kein Sled zur Hand, aber bei einer openSUSE würde ich wie folgt vorgehen:

  • YaST --> System --> Editor für /etc/sysconfig
    Buttun Suche --> nach cron suchen
und siehe da /etc/sysconfig/cron
Code:
## Type:	yesno
## Default:	no
#
# send status email even if all scripts in 
# cron.{hourly,daily,weekly,monthly} 
# returned without error? (yes/no)
#
SEND_MAIL_ON_NO_ERROR="no"
Steht bei dir dort zufällig ein yes? Ach ja das soll kein gemecker sein, sondern ich finde es viel wichtiger zu wissen wie man so ein Problem angeht, als wie ein allwissendes Orakel einfach ein Lösung zu präsentieren.

Dann dürfte da wohl nur noch das Problem mit vsftp und logrotate bleiben. Da stellt sich mir die Frage ob vsftp direkt in das Logfile schreibt, oder über syslog. Da wäre ein Blick in die vsftpd.conf interessant und natürlich in die manpage von vsftpd. Vielleicht habe ich in den nächsten Tagen einwenig Zeit um mich damit zu beschäftigen.
 
Oben