Czy powinienem edytować / etc / crontab lub uruchomić crontab -e jako root?

43

Konfiguruję regularne zadania konserwacji systemu, które muszą być uruchamiane jako root. Planuję użyć smaku crona, który jest domyślnie wyposażony w Ubuntu 14.04 LTS.

Widzę, że poprzedni administrator (który odszedł z firmy) bezpośrednio edytował / etc / crontab. Rozumiem jednak, że innym możliwym podejściem byłoby użycie crontab -ejako root. Czy są jakieś przekonujące argumenty przemawiające za jednym lub drugim, czy zależy to od preferencji?

linux cron ubuntu-14.04

— marcv81
źródło

9

Dla mnie wygląda to na uzasadnione pytanie dotyczące najlepszych praktyk i mam nadzieję, że nie zostanie zamknięte. Widzę już istotne, oparte na faktach odpowiedzi w odpowiedziach i komentarze do nich.

— MadHatter obsługuje Monikę

1

Kiedyś poszedłem wpisać crontab -l (aby wyświetlić listę crontab), ale napisałem crontab -; przez pomyłkę, która zamiast tego usunęła mój plik crontab. Tego dnia wiele się nauczyłem.

— Drwal

64

Warto zauważyć, że zadania w osobistym crontab ( crontab -e) są zawsze wykonywane jako ich właściciele, w których /etc/crontabznajduje się dodatkowe <user>pole obowiązkowe pozwalające administratorowi skonfigurować zadanie do uruchamiania jako użytkownik inny niż root.

Edycja systemowego pliku crontab lub konfiguracja osobistego pliku crontab dla roota jest prawdopodobnie nieco bardziej przenośna, nie jest specyficzna dla niektórych dystrybucji Linuksa i jest prawdopodobnie wygodniejsza w utrzymaniu, z wszystkimi zadaniami w jednym pliku, ale:

Osobiście preferuję trzecią opcję : dla każdego zaplanowanego zadania upuść albo

plik /etc/cron.d/z fragmentem crona
plik wykonywalny (skrypt) w odpowiednim /etc/cron.[hourly |daily |weekly |monthly]katalogu.

Jest to łatwiejsze do skryptu (możesz po prostu tworzyć / nadpisywać / usuwać takie pliki i nie musisz grzebać w zawartości pojedynczego pliku crontab) i działa dobrze z narzędziami do zarządzania konfiguracją i to właśnie menedżerowie pakietów już są i tak robić.

Zadania / skrypty /etc/cron.[hourly |daily |weekly |monthly]są zawsze wykonywane jako root, gdzie fragmenty crona /etc/cron.d/umożliwiają zarówno ustawienie niestandardowego harmonogramu, jak i uruchamianie jako inny użytkownik z tym samym obowiązkowym <user>polem znalezionym w /etc/crontab.

— HBruijn
źródło

18

Wadą edycji /etc/crontabjest to, że scalanie będzie wymagane przy każdej aktualizacji cronpakietu. Nie masz tego problemu, jeśli po prostu dodasz nowy plik do jednego z /etc/cron.*katalogów.

— kasperd

1

Należy dodać, że w większości dystrybucji /etc/cron.[hourly |daily |weekly |monthly]zawiera pliki wykonywalne, podczas gdy /etc/cron.dzawiera pliki crontab. Poza tym +1.

— GnP

Jestem zdecydowanie fanem katalogów cron. [Timing], rzadko potrzebuję niczego bardziej szczegółowego niż opcje commn. Należy jednak pamiętać, że niektóre dystrybucje, szczególnie Ubuntu, po cichu ignorują skrypty z rozszerzeniami plików w tych folderach (dość oburzający błąd internetowy, biorąc pod uwagę, że większość osób dodałoby .sh, który mógł zostać naprawiony w ostatnich dystrybucjach). Bardzo trudno jest ustalić, dlaczego skrypty nie działały w tej sytuacji - przynajmniej dodanie do pliku crontab gwarantuje wykonanie.

— Gargravarr,

15

Jak najlepiej pamiętam, crontab -ema tę dodatkową zaletę, że weryfikuje składnię crontab przed jej zainstalowaniem, a jeśli popełni błąd, popełni błąd i przywróci poprzednie. W ten sposób wszystko, co wcześniej działało, nie zatrzyma się nagle, jeśli źle zrozumiesz składnię. Myślę, że najlepszą praktyką jest używanie narzędzi, takich jak uruchamianie, visudoa nie edycja /etc/sudoersbezpośrednio.

— Gargravarr
źródło

2

+1 Dobry punkt na temat sprawdzania poprawności składni, chociaż rozpoznaje pewne błędy składniowe, jest również daleki od głupoty (tj. Z przyjemnością pozwoli ci wprowadzić /etc/crontabwiersz z nazwą użytkownika w szóstej kolumnie). - Chociaż chciałbym argumentować, że używanie interaktywnych narzędzi nie jest „najlepszą praktyką” , powinieneś zautomatyzować za pomocą narzędzi takich jak Puppet / Salt / Ansible itp. I nie powinieneś już konfigurować serwerów ręcznie. Z drugiej strony, jeśli jesteś oldschoolowy, to rzeczywiście używaj swoich narzędzi.

— HBruijn,

Ansible i inne są dobre, jeśli skonfigurujesz ponad 5 serwerów, ale nie jest to kłopotliwe za zaledwie 1. Można argumentować, że przy zaledwie 1 serwerze skrypt Ansible daje możliwość jego identycznej odbudowy, gdy nie powiedzie się 2 lata później, ale w tym momencie skrypt prawdopodobnie przestanie działać z powodu zmian dystrybucji / repozytoriów.

— marcv81,

To jest powód, dla którego zdecydowanie nie zgadzam się z przyjętą odpowiedzią. Bez względu na to, jakie zmiany są wprowadzane, proces weryfikacji powinien zostać przeprowadzony przynajmniej raz. Jeśli następnie skopiujesz linię z nowego crontabu i dostarczysz ją do zautomatyzowanego narzędzia do propagacji na inne serwery, to jest to najlepsze z obu światów.

— Monty Harder

Ani nie pomóż, jeśli uruchomisz skrypt, aw skrypcie występują błędy, więc testowanie na sucho jest wymagane w obu przypadkach.

— mckenzm

@mckenzm zgodził się, ale można zastosować tylko tyle dowodu na idiotę :)

— Gargravarr,

2

To naprawdę stylowe pytanie, istnieje powód, dla którego system operacyjny oferuje wiele metod. Po prostu bądź konsekwentny i nie mieszaj i nie dopasowuj, jeśli nie chcesz mylić nikogo (lub siebie po pewnym czasie braku kontaktu z systemem) - jeśli trudno jest zobaczyć, jakie zadania są faktycznie zaplanowane na całym hoście, zwykle kończyć się paskudnymi niespodziankami.

— rackandboneman
źródło

2

Aby mieć pewność dodania zadania cron wymagającego uprawnień określonego użytkownika, osobiście używam następującego polecenia:

 # crontab -u <user> -e

Możesz sudoteż dodać .

Jak stwierdził @rackandboneman, nie ma potrzeby mieszania się z plikami /etc/cron.d/. Jeśli chodzi o zadania crona użytkownika, użyj funkcji crontabpolecenia.

— aesnak
źródło

3

-1 Dużą wadą wykonania powyższego jest to, że użytkownik może teraz modyfikować / usuwać / również przerywać cronjob, co zwykle nie jest pożądane, gdy jako administrator spędziłeś swój cenny czas na konfigurowaniu ... Również gdy użytkownik jest kontem usługi i to konto jest zablokowane / wygasło, usługa będzie nadal działać, ale osobiste karty cron dla zablokowanych kont zwykle się wyłączają.

— HBruijn,

Jeśli podany tutaj użytkownik jest użytkownikiem publicznym, takim jak członek publicznego środowiska usług terminalowych, masz rację. Jeśli jednak chodzi o użytkownika usługi / agenta ... po zastanowieniu, naprawdę chodzi o styl.

— aesnak