Re: cron und seccheck
Am Mittwoch, 1. Januar 2003 14:26 schriebst Du:
Hi,
0n 03/01/01@16:30 Jürgen Fahnenschreiber told me:
Könntest Du mir bitte mal Deine /usr/lib/cron/run-crons zusenden? Vielleicht entdecke ich da beim Vergleichen einen Fehler bei meiner. Vielen Dank schon mal!
Sorry, aber ich glaube, dass hilf Dir nicht viel, denn ich benutze debian woody und statt seccheck laeuft hier aide.
Wenn Der Eintrag nicht direkt in der crontab steht, schau Dir auch die Verzeichnisse unterhalb von /etc/cron.(daily|weekly|monthly) an sowie /etc/cron.d. Irgendwo muss SuSE sein seccheck ja starten und die Ausgabe umleiten. Unter /etc/cron.d habe ich folgendes:
linux:/etc/cron.d # ls
. .. seccheck seccheck~
linux:/etc/cron.d #
Folgendes steht in der /etc/cron.d/seccheck :
IW seccheck
Row 1 Col 1 7:11 Ctrl-K H for help
#
# SuSE Security Checks
#
0 0 * * * fahnenju test -x
/usr/lib/secchk/security-control.sh &&
/usr/lib/secchk/security-control.sh daily &
0 1 * * 1 fahnenju test -x
/usr/lib/secchk/security-control.sh &&
/usr/lib/secchk/security-control.sh weekly &
0 4 1 * * fahnenju test -x
/usr/lib/secchk/security-control.sh &&
/usr/lib/secchk/security-control.sh monthly &
Unter /etc/cron.daily stehen folgende Dateien:
linux:/etc/cron.daily # ls
. faxcron suse.de-clean-tmp
.. logrotate suse.de-clean-vi
clean_catman suse.de-backup-rc.config suse.de-cron-local
clean_core suse.de-backup-rpmdb tetex
do_mandb suse.de-check-battery updatedb
linux:/etc/cron.daily #
Unter /etc/cron.w eekly stehen folgende Dateien:
linux:/etc/cron.weekly # ls
. ..
linux:/etc/cron.weekly #
Unter /etc/cron.mounthly stehen folgende Dateien:
linux:/etc/cron.monthly # ls
. ..
linux:/etc/cron.monthly #
Hier mal die Ausgabe von /usr/lib/secchk/security-control.sh :
IW security-control.sh
Row 1 Col 1 7:14 Ctrl-K H for help
#!/bin/sh
####
#
# SuSE master control security mechanism for the
daily/weekly/monthly
# security checks, by Marc Heuse
Hallo Jürgen, hallo Leute, Am Mittwoch, 1. Januar 2003 19:16 schrieb Jürgen Fahnenschreiber:
Am Mittwoch, 1. Januar 2003 14:26 schriebst Du: ^^ Wer ist "Du"?
0n 03/01/01@16:30 Jürgen Fahnenschreiber told me:
Könntest Du mir bitte mal Deine /usr/lib/cron/run-crons zusenden? [...] Wenn Der Eintrag nicht direkt in der crontab steht, schau Dir auch die Verzeichnisse unterhalb von /etc/cron.(daily|weekly|monthly) an sowie /etc/cron.d. Irgendwo muss SuSE sein seccheck ja starten und die Ausgabe umleiten.
Fällt mir jetzt erst auf: wenn das Ganze über run-crons läuft, dann steht die Ausgabeumleitung vermutlich schon beim Aufruf von /usr/lib/cron/run-crons in der /etc/crontab (ist zumindest bei mir so) Gruß Christian Boltz -- Bevor es Mißverständnisse gibt: Ja, ich bin willenloser Lustsklave der Göttin "Versionitis", und für ein 'ß' hinter der Versionsnummer tue ich _alles_ [Ratti in suse-linux]
Hi, 0n 03/01/01@22:40 Christian Boltz told me:
Am Mittwoch, 1. Januar 2003 19:16 schrieb Jürgen Fahnenschreiber:
Am Mittwoch, 1. Januar 2003 14:26 schriebst Du:
0n 03/01/01@16:30 Jürgen Fahnenschreiber told me:
Könntest Du mir bitte mal Deine /usr/lib/cron/run-crons zusenden? [...] Wenn Der Eintrag nicht direkt in der crontab steht, schau Dir auch die Verzeichnisse unterhalb von /etc/cron.(daily|weekly|monthly) an sowie /etc/cron.d. Irgendwo muss SuSE sein seccheck ja starten und die Ausgabe umleiten.
Fällt mir jetzt erst auf: wenn das Ganze über run-crons läuft, dann steht die Ausgabeumleitung vermutlich schon beim Aufruf von /usr/lib/cron/run-crons in der /etc/crontab (ist zumindest bei mir so)
[3] Ja, Du schriebst Dein syslog haette das gelogt (aus Deiner 1. mail): ---schnipp--- Dec 30 01:15:00 linux /USR/SBIN/CRON[27860]: (fahnenju) CMD ( test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1) ---schnapp--- in Deiner crontab steht jedoch folgendes (aus einer anderen mail in diesem thread) [1]: ---schnipp--- -*/15 * * * * fahnenju test -x /usr/lib/cron/run-crons && /usr/lib/cron/run- ---schnapp--- und damit habe ich schon mal ein Problem, denn: 1. AFAIK findet man eine cron Zeile die mit '-' beginnt nicht im syslogd 2. Dein syslog meldet, dass die Zeile dort anders stuende. Weiter steht dann noch in der crontab (wieder aus der anderen;)): ---schnipp--- /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh daily & 0 1 * * 1 fahnenju test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh weekly & 0 4 1 * * fahnenju test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh monthly & ---schnapp--- und in schriebst Du jetzt, das in /etc/cron.d die Datei seccheck zu finden sei und dort die gleichen Eintraege drin staenden, die schon in der crontab direkt drinstehen. *HM* Ich vermute mal da ist beim Update estwas daneben gekangen, weil sich vielleicht der Aufruf Mechanismus geaendert hat? Zum script vielleicht soviel: ---schnipp--- test -z "$SECCHK_USER" && SECCHK_USER="root" ---schnapp--- [2] Ist die Variable gesetzt (env | grep SECCHK_USER). Sollte sie wohl nicht oder [2]? Es wird sendmail zum Versand aufgerufen, AFAIK ist unter 8.1 der default mta postfix, ob dessen sytax 100%ig zu sendmail passt weiss ich nicht:(. [1] Hatte ich auf den ersten Blick auch nicht registriert, sorry. [2] Was soll das? [3] Mit Du meine Juergen ist jetzt so einfacher ;)
Am Donnerstag, 2. Januar 2003 00:02 schrieb Maik Holtkamp:
Hi,
0n 03/01/01@22:40 Christian Boltz told me:
Am Mittwoch, 1. Januar 2003 19:16 schrieb Jürgen Fahnenschreiber:
Am Mittwoch, 1. Januar 2003 14:26 schriebst Du:
0n 03/01/01@16:30 Jürgen Fahnenschreiber told me:
Könntest Du mir bitte mal Deine /usr/lib/cron/run-crons zusenden?
[...]
Wenn Der Eintrag nicht direkt in der crontab steht, schau Dir auch die Verzeichnisse unterhalb von /etc/cron.(daily|weekly|monthly) an sowie /etc/cron.d. Irgendwo muss SuSE sein seccheck ja starten und die Ausgabe umleiten.
Fällt mir jetzt erst auf: wenn das Ganze über run-crons läuft, dann steht die Ausgabeumleitung vermutlich schon beim Aufruf von /usr/lib/cron/run-crons in der /etc/crontab (ist zumindest bei mir so)
[3]
Folgendes steht bei mir in der /etc/crontab : SHELL=/bin/sh PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin MAILTO=fahnenju # # check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly # #-*/15 * * * * fahnenju test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 59 * * * * fahnenju rm -f /var/spool/cron/lastrun/cron.hourly 14 0 * * * fahnenju rm -f /var/spool/cron/lastrun/cron.daily 29 0 * * 6 fahnenju rm -f /var/spool/cron/lastrun/cron.weekly 44 0 1 * * fahnenju rm -f /var/spool/cron/lastrun/cron.monthly 0 0 * * * fahnenju test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh daily & 0 1 * * 1 fahnenju test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh weekly & 0 4 1 * * fahnenju test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh monthly &
Ja, Du schriebst Dein syslog haette das gelogt (aus Deiner 1. mail):
---schnipp--- Dec 30 01:15:00 linux /USR/SBIN/CRON[27860]: (fahnenju) CMD ( test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons
/dev/null 2>&1) ---schnapp---
in Deiner crontab steht jedoch folgendes (aus einer anderen mail in diesem thread) [1]:
---schnipp--- -*/15 * * * * fahnenju test -x /usr/lib/cron/run-crons && /usr/lib/cron/run- ---schnapp---
und damit habe ich schon mal ein Problem, denn:
1. AFAIK findet man eine cron Zeile die mit '-' beginnt nicht im syslogd 2. Dein syslog meldet, dass die Zeile dort anders stuende.
Weiter steht dann noch in der crontab (wieder aus der anderen;)):
---schnipp--- /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh daily & 0 1 * * 1 fahnenju test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh weekly & 0 4 1 * * fahnenju test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh monthly & ---schnapp---
und in schriebst Du jetzt, das in /etc/cron.d die Datei seccheck zu finden sei und dort die gleichen Eintraege drin staenden, die schon in der crontab direkt drinstehen. *HM*
Ich vermute mal da ist beim Update estwas daneben gekangen, weil sich vielleicht der Aufruf Mechanismus geaendert hat?
Zum script vielleicht soviel:
---schnipp--- test -z "$SECCHK_USER" && SECCHK_USER="root" ---schnapp--- [2]
Ist die Variable gesetzt (env | grep SECCHK_USER). Sollte sie wohl nicht oder [2]?
Es wird sendmail zum Versand aufgerufen, AFAIK ist unter 8.1 der default mta postfix, ob dessen sytax 100%ig zu sendmail passt weiss ich nicht:(.
[1] Hatte ich auf den ersten Blick auch nicht registriert, sorry. [2] Was soll das? [3] Mit Du meine Juergen ist jetzt so einfacher ;)
So. Vielleicht kommen wir dem Problem jetzt etwas näher. In /etc/crontab habe ich die Zeile von #-*/15 * * * * fahnenju test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 auf 15 * * * * fahnenju test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 geändert. Vielleicht bringt's ja etwas. sendmail ist bei mir deaktiviert (aber installiert)! Postfix ist bei mir nicht installiert. sendmail hatte ich damals deaktiviert um Port 25/tcp smtp und Port 512/tcp exec zu schließen. Jürgen
Hi, 0n 03/01/02@09:40 Jürgen Fahnenschreiber told me:
Am Donnerstag, 2. Januar 2003 00:02 schrieb Maik Holtkamp:
So. Vielleicht kommen wir dem Problem jetzt etwas näher. In /etc/crontab habe ich die Zeile von
#-*/15 * * * * fahnenju test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1
auf
15 * * * * fahnenju test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1
Hier wuerde ich noch einen Schritt weiter gehen und vor dem '>/dev/null...' ein # einfuegen, sonst bekommst Du nicht mit, wenn bei diesem run-crons was in die Hose geht.
geändert. Vielleicht bringt's ja etwas. sendmail ist bei mir deaktiviert (aber installiert)! Postfix ist bei mir nicht installiert.
Ich habe das script (seccheck.sh) nur ueberflogen, aber ich glaube es versendet direkt mit dem sendmail Befehl, so das dadurch wohl keine Probleme zu befuerchten sind, aber ich wuerde sendmail nicht deaktivieren. Wenn Du sendmail ansonsten nicht brauchst wuerde ich es entweder ueber inetd starten und den Zugriff dicht machen oder dazu ueberreden sich nur an ein internes device bzw. loopback zu binden. Es gehen zuviele Mechanismen davon aus, dass ein mta laeuft (u.a cron AFAIK). Hier unter debian laeuft exim ueber inetd: ---schnipp--- root@syl:/home/maik $ lsof -i inetd 351 root 4u IPv4 966 TCP *:smtp (LISTEN) root@syl:/home/maik $ grep exim /etc/inetd.conf smtp stream tcp nowait mail /usr/sbin/exim exim -bs ---schnapp--- -- bye maik
Am Donnerstag, 2. Januar 2003 10:30 schrieb Maik Holtkamp:
Hi,
0n 03/01/02@09:40 Jürgen Fahnenschreiber told me:
Am Donnerstag, 2. Januar 2003 00:02 schrieb Maik Holtkamp:
So. Vielleicht kommen wir dem Problem jetzt etwas näher. In /etc/crontab habe ich die Zeile von
#-*/15 * * * * fahnenju test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1
auf
15 * * * * fahnenju test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1
Hier wuerde ich noch einen Schritt weiter gehen und vor dem '>/dev/null...' ein # einfuegen, sonst bekommst Du nicht mit, wenn bei diesem run-crons was in die Hose geht.
geändert. Vielleicht bringt's ja etwas. sendmail ist bei mir deaktiviert (aber installiert)! Postfix ist bei mir nicht installiert.
Ich habe das script (seccheck.sh) nur ueberflogen, aber ich glaube es versendet direkt mit dem sendmail Befehl, so das dadurch wohl keine Probleme zu befuerchten sind, aber ich wuerde sendmail nicht deaktivieren.
Wenn Du sendmail ansonsten nicht brauchst wuerde ich es entweder ueber inetd starten und den Zugriff dicht machen oder dazu ueberreden sich nur an ein internes device bzw. loopback zu binden. Es gehen zuviele Mechanismen davon aus, dass ein mta laeuft (u.a cron AFAIK). Hier unter debian laeuft exim ueber inetd:
---schnipp--- root@syl:/home/maik $ lsof -i inetd 351 root 4u IPv4 966 TCP *:smtp (LISTEN) root@syl:/home/maik $ grep exim /etc/inetd.conf smtp stream tcp nowait mail /usr/sbin/exim exim -bs ---schnapp--- Sendmail ist aktiviert und ich hatte kurz darauf gleich 620 Mails für den User! Allerdings hab ich da immer noch ein Problem. Ich krieg nur folgende Mails:
Cron
Hi, 0n 03/01/02@12:15 Jürgen Fahnenschreiber told me:
Cron
rm -f /var/spool/cron/lastrun/cron.daily Datum: Thu, 2 Jan 2003 00:14:00 +0100 Von: root@linux.local (Cron Daemon) An: fahnenju@linux.local rm: cannot remove `/var/spool/cron/lastrun/cron.daily': Permission denied
Die Datei einmailg von Hand umbenennen? Ich kenne mich aber damit nicht besonders aus. Wenn sie dennoch gebraucht wird, kannst Du sie ja wieder zurueckschieben.
An /var/mail/root werden aber die "richtigen" Mails geschickt. Was muss ich jetzt einstellen, das mein User -Account meine root -Mails bekommt?
Bei 8.1 bin ich nicht sicher wo es steht, frueher war es mal /etc/mail/aliases. Da kannst Du sagen, dass root = user ist, die syntax wird dort erklaert. Bei sendmail achte darauf, dass der Trenner zwischen den Feldern ein tab ist, ein 'leer' hilft da nicht.
Übrigens habe ich vor dem /dev/null habe ich jetzt mal ein # gesetzt.
Wenn alles laeuft kannst Du es wieder einkommentieren. Ich sehe aber nichts was dagegen spricht zumindest das 2>&1, was den Fehlerkanal umbiegt auskommentiert zu lassen. Wenn dort Fehler auftreten, so will man das ja schliesslich wissen. -- bye maik
Am Donnerstag, 2. Januar 2003 12:58 schrieb Maik Holtkamp:
Hi,
0n 03/01/02@12:15 Jürgen Fahnenschreiber told me:
Cron
rm -f /var/spool/cron/lastrun/cron.daily Datum: Thu, 2 Jan 2003 00:14:00 +0100 Von: root@linux.local (Cron Daemon) An: fahnenju@linux.local rm: cannot remove `/var/spool/cron/lastrun/cron.daily': Permission denied
Die Datei einmailg von Hand umbenennen? Ich kenne mich aber damit nicht besonders aus. Wenn sie dennoch gebraucht wird, kannst Du sie ja wieder zurueckschieben.
An /var/mail/root werden aber die "richtigen" Mails geschickt. Was muss ich jetzt einstellen, das mein User -Account meine root -Mails bekommt?
Bei 8.1 bin ich nicht sicher wo es steht, frueher war es mal /etc/mail/aliases. Da kannst Du sagen, dass root = user ist, die syntax wird dort erklaert. Bei sendmail achte darauf, dass der Trenner zwischen den Feldern ein tab ist, ein 'leer' hilft da nicht.
Übrigens habe ich vor dem /dev/null habe ich jetzt mal ein # gesetzt.
Wenn alles laeuft kannst Du es wieder einkommentieren. Ich sehe aber nichts was dagegen spricht zumindest das 2>&1, was den Fehlerkanal umbiegt auskommentiert zu lassen.
Wenn dort Fehler auftreten, so will man das ja schliesslich wissen. So. Das habe ich jetzt mal alles so gemacht. Mein user bekam jetzt folgende Meldung:
Cron
Hi, 0n 03/01/03@09:41 Jürgen Fahnenschreiber told me:
Am Donnerstag, 2. Januar 2003 12:58 schrieb Maik Holtkamp:
Hi,
0n 03/01/02@12:15 Jürgen Fahnenschreiber told me:
Cron
rm -f /var/spool/cron/lastrun/cron.daily Datum: Thu, 2 Jan 2003 00:14:00 +0100 Von: root@linux.local (Cron Daemon) An: fahnenju@linux.local rm: cannot remove `/var/spool/cron/lastrun/cron.daily': Permission denied
Die Datei einmailg von Hand umbenennen? Ich kenne mich aber damit nicht besonders aus. Wenn sie dennoch gebraucht wird, kannst Du sie ja wieder zurueckschieben.
An /var/mail/root werden aber die "richtigen" Mails geschickt. Was muss ich jetzt einstellen, das mein User -Account meine root -Mails bekommt?
Bei 8.1 bin ich nicht sicher wo es steht, frueher war es mal /etc/mail/aliases. Da kannst Du sagen, dass root = user ist, die syntax wird dort erklaert. Bei sendmail achte darauf, dass der Trenner zwischen den Feldern ein tab ist, ein 'leer' hilft da nicht.
Übrigens habe ich vor dem /dev/null habe ich jetzt mal ein # gesetzt.
Wenn alles laeuft kannst Du es wieder einkommentieren. Ich sehe aber nichts was dagegen spricht zumindest das 2>&1, was den Fehlerkanal umbiegt auskommentiert zu lassen.
Wenn dort Fehler auftreten, so will man das ja schliesslich wissen. So. Das habe ich jetzt mal alles so gemacht. Mein user bekam jetzt folgende Meldung:
Cron
test -x /usr/lib/secchk/security-control.sh && Datum: Fri, 3 Jan 2003 00:00:00 +0100 Von: root@linux.local (Cron Daemon) An: fahnenju@linux.local /bin/sh: -c: line 2: syntax error: unexpected end of file
In der /var/log/ messages habe ich dazu folgenden Eintrag:
Jan 3 00:00:00 linux /USR/SBIN/CRON[19066]: (fahnenju) CMD ( test -x /usr/lib/secchk/security-control.sh &&) Jan 3 00:00:00 linux /USR/SBIN/CRON[19067]: (fahnenju) CMD ( test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh daily &)
Da fehlt auch was. Das && verknuepft 2 Befehle. Das text -x prueft ob eine Datei da und ausfuerhbar ist. Der obige Befehl (der auf && endet) wuerde also auf Deutsch heissen: ---Übersetzung--- Wenn /usr/lib/secchk/security-control.sh exsistiert und ausfuehrbar ist, dann ---Übersetzung--- Ja, was dann? Dieser Befehl sollte im script (entweder direkt in der crontab oder in /etc/cron.d/seccheck) so aussehen: (angaben zu Zeiten) (user) test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh <Zeitangabe> > /dev/null Wobei <zeitangabe> wahrscheinlich fuer daily, weekly, monthly oder aehnliches steht. Ich weiss es zwar nicht genau, aber ich wuerd vermuten, Du hast irgendwo in der langen Zeile hinter dem && ein Enter gesetzt, so dass der 2. Teil des Aufrufs abgeschitten wird. Mit > /dev/null wird die Standardausgabe des Befehls in den Muelleimer gepackt. Das 2>&1 was urspruenglich dort hinter noch stand, sorgt dafuer das der Fehlerkanal (2) auch dorthin geht wohin der Standardkanal (1) geht, also in den Muelleimer und _das_ wuerde ich so nicht machen. BTW: Bitte nicht PM und auf Liste, ich lese mit, TIA. Jetzt hast Du es 2*, aber doppelt gemoppelt haelt ja auch besser. Wenigstens hat man so noch die Chance groesbste Grammatikfehler auszubuegeln ;) -- bye maik
Am Freitag, 3. Januar 2003 13:22 schrieb Maik Holtkamp:
Hi,
0n 03/01/03@09:41 Jürgen Fahnenschreiber told me:
Am Donnerstag, 2. Januar 2003 12:58 schrieb Maik Holtkamp:
Hi,
0n 03/01/02@12:15 Jürgen Fahnenschreiber told me:
Cron
rm -f /var/spool/cron/lastrun/cron.daily Datum: Thu, 2 Jan 2003 00:14:00 +0100 Von: root@linux.local (Cron Daemon) An: fahnenju@linux.local rm: cannot remove `/var/spool/cron/lastrun/cron.daily': Permission denied
Die Datei einmailg von Hand umbenennen? Ich kenne mich aber damit nicht besonders aus. Wenn sie dennoch gebraucht wird, kannst Du sie ja wieder zurueckschieben.
An /var/mail/root werden aber die "richtigen" Mails geschickt. Was muss ich jetzt einstellen, das mein User -Account meine root -Mails bekommt?
Bei 8.1 bin ich nicht sicher wo es steht, frueher war es mal /etc/mail/aliases. Da kannst Du sagen, dass root = user ist, die syntax wird dort erklaert. Bei sendmail achte darauf, dass der Trenner zwischen den Feldern ein tab ist, ein 'leer' hilft da nicht.
Übrigens habe ich vor dem /dev/null habe ich jetzt mal ein # gesetzt.
Wenn alles laeuft kannst Du es wieder einkommentieren. Ich sehe aber nichts was dagegen spricht zumindest das 2>&1, was den Fehlerkanal umbiegt auskommentiert zu lassen.
Wenn dort Fehler auftreten, so will man das ja schliesslich wissen.
So. Das habe ich jetzt mal alles so gemacht. Mein user bekam jetzt folgende Meldung:
Cron
test -x /usr/lib/secchk/security-control.sh && Datum: Fri, 3 Jan 2003 00:00:00 +0100 Von: root@linux.local (Cron Daemon) An: fahnenju@linux.local /bin/sh: -c: line 2: syntax error: unexpected end of file
In der /var/log/ messages habe ich dazu folgenden Eintrag:
Jan 3 00:00:00 linux /USR/SBIN/CRON[19066]: (fahnenju) CMD ( test -x /usr/lib/secchk/security-control.sh &&) Jan 3 00:00:00 linux /USR/SBIN/CRON[19067]: (fahnenju) CMD ( test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh daily &)
Da fehlt auch was. Das && verknuepft 2 Befehle. Das text -x prueft ob eine Datei da und ausfuerhbar ist.
Der obige Befehl (der auf && endet) wuerde also auf Deutsch heissen:
---Übersetzung--- Wenn /usr/lib/secchk/security-control.sh exsistiert und ausfuehrbar ist, dann ---Übersetzung---
Ja, was dann? Dieser Befehl sollte im script (entweder direkt in der crontab oder in /etc/cron.d/seccheck) so aussehen:
(angaben zu Zeiten) (user) test -x /usr/lib/secchk/security-control.sh && /usr/lib/secchk/security-control.sh <Zeitangabe> > /dev/null
Wobei <zeitangabe> wahrscheinlich fuer daily, weekly, monthly oder aehnliches steht.
Ich weiss es zwar nicht genau, aber ich wuerd vermuten, Du hast irgendwo in der langen Zeile hinter dem && ein Enter gesetzt, so dass der 2. Teil des Aufrufs abgeschitten wird.
Mit > /dev/null wird die Standardausgabe des Befehls in den Muelleimer gepackt. Das 2>&1 was urspruenglich dort hinter noch stand, sorgt dafuer das der Fehlerkanal (2) auch dorthin geht wohin der Standardkanal (1) geht, also in den Muelleimer und _das_ wuerde ich so nicht machen.
DATA <<< 550 5.7.1 ... Cannot mail
DATA <<< 550 5.7.1 ... Cannot mail
OK. Jetzt passt was neues nicht, aber so langsam wirds.
Ich bekomme jetzt solche Meldungen an den User:
Returned mail: see transcript for details
Datum: Fri, 3 Jan 2003 11:00:00 +0100
Von: Mail Delivery Subsystem
participants (3)
-
Christian Boltz
-
Jürgen Fahnenschreiber
-
Maik Holtkamp