RS812 und Crontab

[lopo_ch]

Hallo zusammen,

seit vorige Woche hab ich eine RS812, damit wollte ich meinen Debian-Server ersetzen und etwas Strom zu sparen.
Mit Linux habe ich in jedem Falle viel Erfahrung.
Soweit klappt eigentlich alles recht gut, nur eine Sache bring mich zur Verzweiflung.

Bisher habe ich die Emails per fetchmail von externen Mailkonten abholen lassen.
Nachdem ich mich etwas eingelesen habe, habe ich dies Howto abgearbeitet:
http://www.synology-wiki.de/index.php/Externe_Accounts_abrufen
Auch das hat soweit geklappt.
Die Userscripts unter /volume1/homes/EUER_USER/.getmail holen die Mails ab und sind per Roundcube bzw Mailclient verfügbar.
Doch die cronjobs klappen auf keine Art und Weise. Auch nicht unter Berücksichtigung der Tips des Howtos.
Nachdem ich seit ein paar Tagen mich mit dem Problem rumschlage, wollte ich am vergangenen Sonntag ganz besonders clever sein.
Nach dem ich das funktionierende getmail.sh nach /usr/local/bin kopiert habe, wollte ich mit dem Cronjob Editor den Job hinzufügen.
Rechte dabei auf den User gesetzt und auch darauf geachtet, dass /usr/local/bin/getmail.sh auf diesen User gesetzt ist.
Nun klappt erst einmal das abholen der Mail von Extern.
Aber: Nur bis zu nächsten Neustart. Dann ist der Cronjob wieder weg.

Hat jemand für diese Phänomen eine Erklärung?

Vielen Dank für Eure Hilfe

 

[jahlives]

geht denn das Abholen wenn du das getmail direkt aufrufst? Wenn ja und es im cron nicht geht, dann würde ich mal auf nicht komplette Pfadangaben zu den Kommandos tippen. Ist aber schwierig ohne deinen Quellcode des getmail Scriptes zu sehen.
Wenn cronjobs "verschwinden" kann es sein, dass du Leerzeichen in der crontab verwendet hast. Korrekt für den Syno crontab wären aber TABS als Whitespaces

 

[lopo_ch]

Hi jahlives

im /usr/local/bin/getmail.sh steht
#!/bin/sh
PATH=/opt/bin:/opt/sbin:/opt/sbin:/opt/bin:/usr/sbin:/usr/bin:/sbin:/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin
pid_getmail='/tmp/getmail.pid'
if [ -s "$pid_getmail" ]; then
exit
else
touch $pid_getmail
/opt/bin/getmail -q -l --getmaildir /volume1/homes/test.user/.getmail -r test.user@pop.hispeed.rc (Mailserver des Provider)
rm $pid_getmail
exit
fi

Ohne irgendwelche Pfade, nur nach dem ssh-Login als root:
RackStation> getmail.sh
holt er sofort die Mails.

Den Cronjob füge ich per Cronjob Editor dazu und der sollte die Tabs statt Leerzeichen verwenden.

Im Moment habe ich den Cronjob mal wieder hinzugefügt, diesmal zum testen als root und alle 2 Minuten. Siehe da: der job ist noch drin.
Irgendwo habe ich aber gelesen, dass root das nicht machen soll, weil es sich mit irgend etwas anderem hackt.
Scheint aber auch keine Mails abzuholen *seuftz*

 

[jahlives]

hm also für mich macht der -s check keinen wirklichen Sinn. Der prüft ob ein File mehr als 0 Bytes hat. touch legt jedoch ein leeres File an, welches auch 0 Grösse hat. imho wird dieser Check nicht greifen, wenn getmail bereits am laufen ist

if [ -e "$pid_getmail" ] ; then
exit
else
....

würde prüfen ob das File existiert anabhängig von der Grösse

 

[fpo4711]

Hallo,

ich glaube hier sucht jahlives mal ausnahmsweise an der falschen Stelle

Aber: Nur bis zu nächsten Neustart. Dann ist der Cronjob wieder weg.

Wenn ich das richtig verstanden habe läuft das Script doch, ist aber nach einem Neustart aus der crontab verschwunden. Ohne das jetzt geprüft zu haben, glaube ich das Synology hier den Ablauf etwas geändert hat, weshalb der Crontab Editor hier glaube ich nicht zum Erfolg führt. Viel mehr ist das jetzt über den Aufgabenplaner im DSM zu regeln. Wie schon gesagt bin mir aber nicht sicher und kann das jetzt auch nicht prüfen.

Gruß Frank

 

[jahlives]

@frank
dann sag mir was passiert wenn getmail bei diesem Script läuft. Wird eine weitere Instanz gestartet wenn das Script das nächste Mal ausgeführt wird? Ja? Nein?

touch test.txt && [ -s test.txt ] && echo 'Inhalt'
touch test.txt && echo 'Test' > test.txt && [ -s test.txt ] && echo 'Inhalt'

welche der beiden Zeilen gibt eine Ausgabe?`Das kann ganz hässliche Race-Conditions geben

Das mit dem crontab wusste ich ned, dass da was geändert wurde mea culpa

 

[lopo_ch]

Hi Frank,

den Aufgabenplaner hab ich mal die Aufgabe "Mails abholen" gegeben.
Nachteil von diesem: die Frequenz geht nicht kleiner als 1x pro Stunde.
Aber ich beobachte das mal, was der tut oder nicht.

Bei den Crontab's scheint es so zu sein, dass alles, was nicht unter dem Account "root" ist nach einem Neustart wieder gelöscht wird, selbst "admin" bleibt nicht drin.
Ich schau mir mal heute Nachmittag / Abend an, ob irgendwo in /etc.defaults die "default"-crontab eine Einstellung zu finden ist.

Trotz intensiver Suche hab ich im Internet kaum Hinweise auf die RS812 bezüglich crontab gefunden.
Ist die relativ neu? Aber das DSM 4.2 müsste doch dann bei ähnlichen Geräte etwa ähnlich sein, oder?

viele Grüsse aus der kleinen Schweiz

 

[fpo4711]

@jahlives
Ich hab mich ehrlich gesagt überhaupt nicht mit dem Script auseinander gesetzt. Hier wirst Du sicherlich recht haben. Ich hatte nur im Kopf das sich bei dem Handling mit der Crontab was geändert hat. Mein Gedanke war hier das die /etc/crontab vieleicht bei einem Neustart überschrieben wird.

Gruß Frank

 

[jahlives]

@jahlives
Ich hab mich ehrlich gesagt überhaupt nicht mit dem Script auseinander gesetzt.

und ich habe nur den Code gesehen und der cron ausser acht gelassen ;-)

 

[fpo4711]

Herrlich ja zusammen sind wir eben alle unschlagbar.

Gruß Frank

 

[lopo_ch]

@jahlives
@Frank

na, Ihr seid mir Helden
Aber so rum wird's vielleicht doch noch was!

Hab mal das Script, was von root ausgeführt wird, so geändert: (meintest Du es so,jahlives?)
#!/bin/sh
PATH=/opt/bin:/opt/sbin:/opt/sbin:/opt/bin:/usr/sbin:/usr/bin:/sbin:/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin
pid_getmail='/tmp/getmail.pid'
if
touch $pid_getmail
/opt/bin/getmail -q -l --getmaildir /volume1/homes/test.user/.getmail -r test.user@pop.hispeed.ch.rc
rm $pid_getmail
exit
fi

13:08 hat mal eines von den Script automatisch etwas abgeholt, weiss jetzt nur nicht, ob es crontab oder der Aufgabenplaner war.
Beides läuft noch.....

 

[lopo_ch]

Also, nun klappt mit dem root-Account und crontab
Das Script unter /usr/local/bin/getmail.sh:

#!/bin/sh
PATH=/opt/bin:/opt/sbin:/opt/sbin:/opt/bin:/usr/sbin:/usr/bin:/sbin:/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin
pid_getmail='/tmp/getmail.pid'
# date >> /var/log/getmail_as_root # zur Kontrolle einen Zeitstempel

touch $pid_getmail
/opt/bin/getmail -q -l --getmaildir /volume1/homes/test.user/.getmail -r test.user@pop.hispeed.ch.rc
rm $pid_getmail
exit

Holt alle 5 Minuten die Mails ab.

Danke für die Hilfe!!!

 

[jahlives]

da es mit dem crontab ja jetzt zu funzen scheint, kann ich mich gänzlich über den Code auslassen
1. du solltest den eigentlichen Abholprozess möglichst nicht als root laufen lassen, sondern mittels su zu deinem User wechseln so z.B

su DEIN_USER -c '/opt/bin/getmail -q -l --getmaildir /volume1/homes/test.user/.getmail -r test.user@pop.hispeed.ch.rc'

Hintergrund: der getmail Prozess interagiert mit dem CC Mailserver. Wenn getmail eine Lücke hätte, die sich z.B. durch eine speziell präparierte Mail ausnutzen lässt, dann passiert dies im Kontext des aufrufenden Users. Wenn dies dann root ist, dann wäre es u.U. möglich den gesamten Server zu kompromittieren oder zu übernehmen. Wenn du getmail aber mit einem eigeschränkten User aufrufst, dann kann man nichts wirklich schlimmes anstellen auf deinem System

2. die Prüfung ob getmail bereits läuft solltest du unbedingt drin lassen, einfach so angepasst, dass getmail sicher nicht aufgerufen wird, wenn bereits eine getmail Instanz läuft. Wenn du den Test so lassen willst, also mit -s dann kannst du z.B. dies machen

#das ! negiert die Bedingung d.h. hier kommt man nur rein wenn die Filegrösse 0 Bytes ist  
if [ ! -s "$pid_getmail" ] ; then  
 #das schreibt die PID (ProcessID) des Scriptes in das File, damit ist es grösser als 0 Bytes  
 echo $$ > $pid_getmail  
 su DEIN_USER -c '/opt/bin/getmail -q -l --getmaildir /volume1/homes/test.user/.getmail -r test.user@pop.hispeed.ch.rc'  
 #hier leerst du das File wieder, damit der nächste Aufruf wieder ein leeres File vorfindet  
 echo > $pid_getmail 
else  
 exit 0 
fi

 

[lopo_ch]

Hi jahlives,

öhm, Du hast natürlich recht!!!
Als Linuxuser sollte ich auf sowas achten! Ich war erstmal froh, dass überhaupt etwas funktioniert.
Jetzt hab ich das mit Deinen Vorschlägen geändert und hoffe, dass die Mail noch immer abgeholt werden

Morgen früh schau ich mal.

Viele Grüsse und schönen Abend!

 

[lopo_ch]

Hi jahlives,

heute morgen hat es nun doch noch nicht oder wieder nicht funktioniert.
Bin über su gestolpert, das war noch nicht installiert:
su: can't run /sbin/nologin: No such file or directory

Dann noch in der /etc/passwd den Eintrag user:x:1026:100:user:/var/services/homes/user:/bin/sh

Im Moment hat er noch gemotzt, dass das Verzeichnis /.getmail und log nicht beschreibbar sind.
Nun auch das noch abgestellt und jetzt macht er erst mal wieder.

Wäre es nicht eventuell von Vorteil, einen User "getmail" anzulegen, der nur die Mails abholt?
Das Problem wären wohl dann wieder die Mailsverzeichnisse unter /volume1/homes/user/.Maildir.
Dann müsste wohl auch eine neue Gruppe erstellt werden, die darauf Schreibrechte hat.


Grüsschen
lopo

 

[jahlives]

grundsätzlich sollte der Abholjob immer unter demjenigen User laufen in dessen Home auch die Mailbox liegt. So sollten die Rechte dann immer stimmen. Sonst kann es dir passieren, dass in der Mailbox von Hans plötzlich Files/Verzeichnisse liegen welche dem User getmail gehören und das wäre nicht unbe3dingt ideal
Afaik hättest du für deinen User den passwd Eintrag nicht anpassen müssen, du kannst bei su auch eine Shell mitgeben

su DEIN_USER -s /bin/sh -c '/opt/bin/getmail -q -l --getmaildir /volume1/homes/test.user/.getmail -r test.user@pop.hispeed.ch.rc'

 

[lopo_ch]

Na supi, und das funktioniert sogar

Ich hoffe, irgendwann verstehen ich "dieses" Linux.

Nun kann kann ich mich langsam um das nächste Thema kümmern: digitemp - läuft aber noch auf dem "alten" Server.

Vielen Dank für Deine Hilfe!