Interessefrage: warum crontabs in /var?
Thomas Rachel
ich min mir nicht ganz sicher, ob ich in dieser NG richtig bin, aber ich
habe eine rein interessehalber eine Frage:
Aus welchem Grund befinden sich die Crontabs der User unter /var/spool/cron?
Eine Datei ~/.crontab o.ä. hätte es mit Sicherheit auch getan, oder? Der
Vorteil wäre zudem eine besser Backupbarkeit...
Thomas
Rainer Koenig
> Aus welchem Grund befinden sich die Crontabs der User unter /var/spool/cron?
FHS?
> Eine Datei ~/.crontab o.ä. hätte es mit Sicherheit auch getan, oder? Der
> Vorteil wäre zudem eine besser Backupbarkeit...
Inwiefern unterscheidet sich die "Backupbarkeit" (schauder) einer Datei
unter $HOME von der einer Datei unter /var?
Have fun!
Rainer
--
Please send NO spam to my mail addresses.
Thomas Rachel
> Thomas Rachel <thra...@stud.uni-saarland.de> writes:
>
>> Aus welchem Grund befinden sich die Crontabs der User unter
>> /var/spool/cron?
>
> FHS?
Hm, ja, gut. Aber die Festlegung in diesem Standard hat ja sicherlich einen
Grund.
IMHO ist die crontab eine genauso userbezogene Datei wie jede andere
unter /home auch. Irgendwie sagt mir mein Gefühl, daß sie dort besser
hinpaßt...
> Inwiefern unterscheidet sich die "Backupbarkeit" (schauder) einer Datei
^^^^^^^^^^ :-}
> unter $HOME von der einer Datei unter /var?
Naja, wenn ich genau $HOME backuppe, um bspw. meine eigenen Daten von einem
auf den anderen Rechner zu übertragen (oder was auch immer), übersehe ich
die crontab nun mal...
Hatte die Tage den Fall, daß eine Festplatte abgeraucht ist und die wirklich
überlebensnotwenigen Dateien waren zwar gesichert, aber ide zugehörige
crontab fürs Backup nicht :-/ (Nicht weiter schlimm ,die war innerhalb von
10 Minuten wiederhergestellt, aber trotzdem ärgerlich...)
Thomas
Hubert Feyrer
> Aus welchem Grund befinden sich die Crontabs der User unter /var/spool/cron?
> Eine Datei ~/.crontab o.ä. hätte es mit Sicherheit auch getan, oder? Der
> Vorteil wäre zudem eine besser Backupbarkeit...
Beim starten des crond liest dieser saemtliche Crontabs durch.
Wenn diese alle in einem Verzeichnis liegen geht das wohl schneller als
wenn er erst durch die ganzen Homes laufen muss.
Zumal man wohl nix gewinnen wuerde, weil man dem crond immer noch sagen
muesste, dass er die Datei neu einliesst wenn man sie veraendert hat (was
crontab(8) ja wohl macht).
- Hubert
Klaus Wacker
> Hallo,
>
> ich min mir nicht ganz sicher, ob ich in dieser NG richtig bin, aber ich
> habe eine rein interessehalber eine Frage:
>
> Aus welchem Grund befinden sich die Crontabs der User unter /var/spool/cron?
> Eine Datei ~/.crontab o.ä. hätte es mit Sicherheit auch getan, oder?
Noch ein Grund: $HOME liegt bei größeren Installationen gerne mal auf
einem NFS- oder AFS-Server. Auf welcher Maschine soll das laufen?
> Der
> Vorteil wäre zudem eine besser Backupbarkeit...
/var/spool sollte man im Backup haben.
--
Klaus Wacker wac...@Physik.Uni-Dortmund.DE
51°29'9"N 7°25'9"E http://www.physik.uni-dortmund.de/~wacker
Simon Krahnke
> Aus welchem Grund befinden sich die Crontabs der User unter /var/spool/cron?
> Eine Datei ~/.crontab o.ä. hätte es mit Sicherheit auch getan, oder? Der
> Vorteil wäre zudem eine besser Backupbarkeit...
Der Standard-Mailordner liegt auch unter /var/spool, das finde ich noch
weniger angebracht.
Richtige Homeverzeichnisse aber nur Login-User. Aber auch für
Dienst-Accounts kann es sinnvoll sein, eine Crontab zu haben.
mfg, simon .... l
Martin Vaeth
>
> Naja, wenn ich genau $HOME backuppe, um bspw. meine eigenen Daten von einem
> auf den anderen Rechner zu übertragen (oder was auch immer), übersehe ich
> die crontab nun mal...
Vielleicht hilft da meine Strategie: Alle händisch editierten
Config-Dateien schon gleich beim ersten Editieren in ein eigenes
Verzeichnis packen und das "Original" mit einen symbolischen Link
darauf verweisen lassen. Geht zumindest bei allen Programmen, die
symbolische Links vernünftig behandeln...
Rainer Koenig
> Hatte die Tage den Fall, daß eine Festplatte abgeraucht ist und die wirklich
> überlebensnotwenigen Dateien waren zwar gesichert, aber ide zugehörige
> crontab fürs Backup nicht :-/
Dann solltest Du Dein Backup-Konzept überarbeiten. :-)
Have fun!
Rainer
--
* Der obenstehende Newsbeitrag spiegelt eine persönliche Meinung *
* des Authors wieder, basierend auf dessen Wissen und Erfahrung. *
* Diese Meinung wird nicht notwendigerweise vom Arbeitgeber des *
* Verfassers dieser Nachricht geteilt. Irrtum vorbehalten :-) *
Juergen P. Meier
> Hallo,
>
> ich min mir nicht ganz sicher, ob ich in dieser NG richtig bin, aber ich
> habe eine rein interessehalber eine Frage:
>
> Aus welchem Grund befinden sich die Crontabs der User unter /var/spool/cron?
> Eine Datei ~/.crontab o.ä. hätte es mit Sicherheit auch getan, oder? Der
Nein.
Spaetestens, wenn dein Homeverzeichnis auf einem AFS liegt, geht das
in die Hose. So wie die anderen ~/.blafasel Mechanismen auch.
> Vorteil wäre zudem eine besser Backupbarkeit...
Ganz bestimmt nicht. Es ist eher ein gravierender Nachteil, wenn nicht
alle Crontabeintraege aller User an einer Stelle liegen wuerden.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Thomas Rachel
> Vielleicht hilft da meine Strategie: Alle händisch editierten
> Config-Dateien schon gleich beim ersten Editieren in ein eigenes
> Verzeichnis packen und das "Original" mit einen symbolischen Link
> darauf verweisen lassen. Geht zumindest bei allen Programmen, die
> symbolische Links vernünftig behandeln...
Gute Idee, muß ich mir merken :-)
Thomas
Thomas Rachel
> Der Standard-Mailordner liegt auch unter /var/spool, das finde ich noch
> weniger angebracht.
Stimmt...
> Richtige Homeverzeichnisse aber nur Login-User. Aber auch für
> Dienst-Accounts kann es sinnvoll sein, eine Crontab zu haben.
Richtig, aber die Dienst-Accounts haben bei mir auch all Home-Verzeichnisse,
wenn auch nicht unter /home. Die Dateien könnten ja dann dort angesiedelt
sein...
Aber die anderen Begründungen leuchten mir ein.
Thomas
Jörg Sommer
Weil $HOME nicht verfügbar seien muss, wenn der Benutzer ausgeloggt ist.
Und dann hat Cron auch ein Interesse daran, dass der Benutzer nicht
einfach so die Datei verändern kann. In der crontab steht in der Regel im
Kopf auch ein fetter Warnung die Datei von Hand zu editieren. Die
Wahrscheinlichkeit, dass es denoch im Home geschieht, ist ziemlich groß.
Und es sagt auch keiner, dass die Crontab unter /v/s/c eine Datei pro
Benutzer seinen muss. Das kann auch eine Monsterdatei sein, in der alle
Crontabs zusammengemischt sind. Es sind einfach an der Stelle die
Informationen eines Programms und nicht die Dateien eines Benutzers.
Schöne Nacht, Jörg.
--
Viele Leute glauben, daß sie denken, wenn sie lediglich
ihre Vorurteile neu ordnen.
Markus Raab
> Geht zumindest bei allen Programmen, die
> symbolische Links vernünftig behandeln...
Meinst du: Programme die symbolische Links nicht gesondert behandeln?
mfg Markus
--
http://www.markus-raab.org | Es gibt keine einfachen Lösungen für sehr
-o) | komplizierte Probleme. Man muß den Faden
Kernel 2.6.11.10 /\ | geduldig entwirren, damit er nicht reißt.
on a i686 _\_v | -- Michail Sergejewitsch Gorbatschow
Martin Vaeth
> Martin Vaeth wrote:
>
>> Geht zumindest bei allen Programmen, die
>> symbolische Links vernünftig behandeln...
>
> Meinst du: Programme die symbolische Links nicht gesondert behandeln?
Ja, aber nicht nur.
Beispielsweise können einige (X)Emacs-Versionen die ~/.emacs
nicht "sehen", wenn sie ein symbolischer Link ist.
Probleme können aber auch Programme machen, die die Konfiguration
selbst nochmal abspeichern, und zwar, indem sie zuerst die Datei
löschen und dann speichern (deswegen sind - je nach Distribution -
/etc/passwd /etc/group /etc/shadow /etc/resolv.conf keine guten
Kandidaten).
Und /etc/fstab als Link auf die /home/meine_configs/fstab zu setzen
kommt beim Booten auch nicht so gut, wenn /home auf einer anderen
Partition liegt... :)
Rocco Rutte
>Vielleicht hilft da meine Strategie: Alle händisch editierten
>Config-Dateien schon gleich beim ersten Editieren in ein eigenes
>Verzeichnis packen und das "Original" mit einen symbolischen Link
>darauf verweisen lassen. Geht zumindest bei allen Programmen, die
>symbolische Links vernünftig behandeln...
Und man kann es von da prima in eine Versionsverwaltung schieben.
bye, Rocco
--
:wq!
Maurice
> Naja, wenn ich genau $HOME backuppe, um bspw. meine eigenen Daten
> von einem auf den anderen Rechner zu übertragen (oder was auch
> immer), übersehe ich die crontab nun mal...
>
> Hatte die Tage den Fall, daß eine Festplatte abgeraucht ist und
> die wirklich überlebensnotwenigen Dateien waren zwar gesichert,
> aber ide zugehörige crontab fürs Backup nicht :-/ (Nicht weiter
> schlimm ,die war innerhalb von 10 Minuten wiederhergestellt, aber
> trotzdem ärgerlich...)
Um die cronjobs festzulegen, muss man sie doch ohnehin in eine Datei
schreiben und dem crontab-Programm geben. Ich lasse diese Datei
immer in ~/.crontab. Ist auch praktischer wenn man mal nur temporär
die jobs deaktivieren will.
Rainer Weikusat
> Thomas Rachel <thra...@stud.uni-saarland.de> wrote:
>> Naja, wenn ich genau $HOME backuppe, um bspw. meine eigenen Daten
>> von einem auf den anderen Rechner zu übertragen (oder was auch
>> immer), übersehe ich die crontab nun mal...
>>
>> Hatte die Tage den Fall, daß eine Festplatte abgeraucht ist und
>> die wirklich überlebensnotwenigen Dateien waren zwar gesichert,
>> aber ide zugehörige crontab fürs Backup nicht :-/ (Nicht weiter
>> schlimm ,die war innerhalb von 10 Minuten wiederhergestellt, aber
>> trotzdem ärgerlich...)
>
> Um die cronjobs festzulegen, muss man sie doch ohnehin in eine Datei
> schreiben und dem crontab-Programm geben.
Muss man nicht. Man kann auch 'crontab -e' benutzen und das file dann
direkt mit $EDITOR (dh dem Inhalt dieser environment-Variablen)
editieren.