Am Donnerstag, 1. April 2004 20:22 schrieb Matthias Houdek:
Al Bogner, Donnerstag, 1. April 2004 13:07:
Am Donnerstag, 1. April 2004 01:05 schrieb Matthias Houdek:
Gut, wenn du ausschließen kannst, dass niemand auf dem Client in der Lage ist Pingantworten zu verhindern.
Ja, und wenn, selber schuld, dann gibt es keinen Zugriff mehr auf den Server :-) Im Ernst, die Nutzer sind überschaubar, haben physischen Zugang zum Server, aber kein root-PW und werden sicher keinen Unfug treiben.
Ich habe mir mal als weiteres Kriterium überlegt, wenn der Server (dial-up) online ist, wird nicht runtergefahren, sondern gewartet.
Wieso? Wenn kein Client mehr im Netz ist (Ping-Test), wer soll dann noch eine Datei offen haben? Du musst dann also nur noch checken, ob evtl. ein von cron angeschubster Job läuft, den du nicht unterbrechen willst, und dann aus die Kiste.
Genau das meinte ich. Ein User von einem client kann nicht mehr im Internet sein, aber zB fetchmail via cronjob und für diesen Fall wird gewartet.
Und welche Jobs von cron angeworfen sein können, solltest du als Admin der Server schon wissen. *g*
Klar, nachdem aber User am Server auf _ihrem_ Account per ssh cronjobs einrichten können, fetchmail läuft zB als user, kann ich da den Überblick verlieren bzw. das zu spät merken. Andererseits wird ohne meine Rückfrage kaum etwas verändert.
Nicht unbedingt, auch cron selbst könnte in diese Lücke reinschießen. Aber da sollte eine kleine Kunstpause im cronjob-Script nach dem Shutdown-Check schon ausreichen. Wenn der Server runtergefahren wird, werden keine neuen Prozesse mehr angeleiert.
Das habe ich mir mittlerweile auch überlegt. Denkst du, dass 5 Sekunden Pause reichen sollten?
Die kritischte Situation ist IMO das Abholen der emails. Und hier sollte IMO im Script, das die Mails abholt, greifen, dass nach einem shutdown abgefragt wird. Allerdings sind da wieder eine Kleinigkeit an Unsicherheiten dabei, nämlich die Bedingung und das lokale Versenden des emails vor dem Shutdown. Andererseis dauert das Aufbauen einer ISDN-Verbindung auch etwas Zeit, sodass ich im Extremfall hoffe, dass der Rechner dann bereits soweit runtergefahren ist, dass keine emails mehr empfangen werden können.
Ich denke, wenn er Online ist, soll er nicht runterfahren?
Mit der "Kunstpause" hat sich das Problem erledigt. Ich dachte an die Situation, dass der Rechner offline ist, zum Shutdown ansetzt und im selben Augenblick der cronjob online geht. Zu diesem Zeitpunkt dachte ich auch noch nicht den crond zu stoppen.
Gut, dann kannst du dir das sparen. Aber schaden kann es auch nicht, es könnte ja sein, dass ein Windoser nur mal so rebootet ;-)
Die Gefahr sehe ich weniger, schon eher das Problem, dass von einem User Linux rebootet wird (warum auch immer), doch das ist dann eben Pech, dass nur mehr 1 Client an ist und der Reboot genau in die Zeit fällt, sodass sich der Server ausschaltet. Der User kennt ja den Knopf zum Server hochfahren. Hauptzweck ist, dass nachts die Server automatisch runtergefahren werden. Im SmallOffice-Bereich macht es IMO keinen Sinn die Server 24h laufen zu lassen. Der erste User am Morgen schaltet die Server ein, nur das Runterfahren soll automatisch erledigt werden. Man kann ja nie an alles denken, aber ich vermute mal die einzige kritische Situation ist der Cronjob zum Abholen der Mails, die anderen Dinge sind reparierbar. Ich habe mal den Rechner runtergefahren, wo fetchmail zwar fertig war, spamassassin und amavis aber nicht, und ich denke es gingen keine Mails verloren, aber diese Situation soll verhindert werden.
ps -A j | grep -e ^$CRONPID
auszuwerten, ob da Zeilen zurückgegeben werden. Die PID von cron kannst du einfach aus /var/run/crond.pid auslesen.
Danke. Al