Vraag Moet ik / etc / crontab bewerken of crontab -e als root uitvoeren?


Ik stel regelmatig systeemonderhoudstaken op die als root moeten worden uitgevoerd. Ik ben van plan om de smaak van cron te gebruiken die standaard wordt meegeleverd met Ubuntu 14.04 LTS.

Ik zie de vorige beheerder (die sinds het verlaten van het bedrijf) / etc / crontab rechtstreeks heeft bewerkt. Ik begrijp echter dat een andere mogelijke aanpak zou zijn om te gebruiken crontab -e als root. Zijn er overtuigende argumenten om het een of het ander te gebruiken of gaat het om voorkeur?


42
2017-09-06 06:51


oorsprong


Voor mij lijkt dit een legitieme best practice-vraag, en ik hoop dat het niet wordt afgesloten. Ik zie nu al relevante, feitelijke punten in de antwoorden en opmerkingen daarover. - MadHatter
Ik ben een keer naar crontab -l gegaan (om de crontab op te sommen) maar ik typte crontab -; per ongeluk die mijn crontab heeft verwijderd. Ik heb die dag veel geleerd. - Lumberjack


antwoorden:


Het kan handig zijn om te weten dat banen in een persoonlijk crontab (crontab -e) worden altijd uitgevoerd als hun eigenaar, waar /etc/crontab bevat een extra verplicht <user> veld waarmee een beheerder de taak kan configureren om als een niet-rootgebruiker te worden uitgevoerd.

Het crontab van het systeem bewerken of een persoonlijke crontab voor root instellen zijn waarschijnlijk een beetje draagbaarder, niet specifiek voor bepaalde Linux-distributies en aantoonbaar handiger voor een persoon onderhouden, met alle taken in één bestand, maar:

Persoonlijk ben ik voor een derde optie: ook voor elke geplande taakdruppel

  • een bestand in /etc/cron.d/ met een cron-fragment
  • een uitvoerbaar bestand (script) in de relevante /etc/cron.[hourly |daily |weekly |monthly] directory.

Dat is gemakkelijker om te manoeuvreren (je kunt eenvoudig zulke bestanden maken / overschrijven / verwijderen en je hoeft niet te rotzooien in de inhoud van één crontab-bestand) en dat werkt goed met tooling voor configuratiemanagement en dat is wat pakketbeheerders al zijn hoe dan ook.

Jobs / scripts in /etc/cron.[hourly |daily |weekly |monthly] worden altijd als root uitgevoerd, waar de cron-fragmenten in voorkomen /etc/cron.d/ staat zowel het instellen van een aangepaste planning toe als het uitvoeren als een andere gebruiker met dezelfde verplichte <user> veld gevonden in /etc/crontab.


58
2017-09-06 07:13



Een nadeel van bewerken /etc/crontab is dat een samenvoeging vereist is wanneer u de update uitvoert cron pakket. U hebt dat probleem niet als u gewoon een nieuw bestand toevoegt aan een van de /etc/cron.* directories. - kasperd
Dit is een heel goed antwoord, heel erg bedankt. - marcv81
Je zou dat in de meeste distro's moeten toevoegen /etc/cron.[hourly |daily |weekly |monthly] houdt executables terwijl /etc/cron.d houdt crontabs vast. Anders dan dat, +1. - GnP
Ik ben absoluut een fan van de cron. [Timing] directories, ik heb zelden iets meer korrelig nodig dan de commn-opties. Houd er echter rekening mee dat sommige distro's, in het bijzonder Ubuntu, scripts met bestandsuitbreidingen in deze mappen stilletjes negeren (gezien de meeste mensen .sh zouden toevoegen, die mogelijk in recente distributies zijn opgelost). Heel moeilijk om uit te zoeken waarom scripts in die situatie niet werkten - in elk geval wordt het toevoegen aan de crontab gegarandeerd uitgevoerd. - Gargravarr


Zo goed als ik me goed herinner, crontab -e heeft als extra voordeel dat het de crontab-syntaxis verifieert voordat het wordt geïnstalleerd en dat het fout zal gaan en het vorige zal herstellen als u een fout maakt. Op deze manier stopt alles wat eerder werkte niet plotseling als de syntaxis verkeerd was. Ik denk dat het beste is om de hulpprogramma's te gebruiken, zoals hardlopen visudo in plaats van bewerken /etc/sudoers direct.


16
2017-09-06 15:12



+1 Goed punt over de syntaxisvalidatie, hoewel het enkele syntaxisfouten herkent, is het ook verre van onfeilbaar (dat wil zeggen dat het je graag een /etc/crontab regel met een gebruikersnaam in de zesde kolom). - Hoewel ik zou willen argumenteren dat het gebruik van interactieve tools dat niet is "beste oefening", je zou met tools zoals Puppet / Salt / Ansible enz. moeten automatiseren en zou servers niet meer handmatig hoeven te configureren. Aan de andere kant, als je old-school bent, gebruik dan inderdaad je gereedschap. - HBruijn
Ansible en anderen zijn goed als je 5+ servers configureert, maar niet de moeite waard voor slechts 1. Je zou kunnen betogen dat met slechts 1 server een Ansible-script je de mogelijkheid geeft om het identiek te herbouwen wanneer het 2 jaar later faalt, maar op dat moment zal het script waarschijnlijk niet meer werken vanwege wijzigingen in repro's / repo's. - marcv81
Dit is de reden dat ik fel het oneens ben met het geaccepteerde antwoord. Welke veranderingen er ook worden aangebracht, moet dit validatieproces minstens één keer doorlopen. Als men vervolgens een regel kopieert van de nieuwe crontab en deze aan een geautomatiseerd hulpmiddel verstrekt om door te geven aan andere servers, dan is het het beste van beide werelden. - Monty Harder
Geen hulp bij het starten van een script en er zijn fouten in het script, dus op beide manieren is een drooglooptest vereist. - mckenzm
@mckenzm overeengekomen, maar er is alleen zoveel idioot-proofing die u kunt toepassen :) - Gargravarr


Het is echt een stijlvraag, er is een reden dat het OS meerdere methoden biedt. Wees gewoon consistent en mix en match niet als u niemand anders wilt verwarren (of uzelf nadat u enige tijd niet met het systeem hebt gewerkt) - als het moeilijk is om te zien welke taken daadwerkelijk in de hele host zijn gepland, heeft dit de neiging om te eindigen in vervelende verrassingen.


2
2017-09-06 14:58





Om zeker te zijn van het toevoegen van een cron-taak waarvoor specifieke gebruikersrechten vereist zijn, gebruik ik persoonlijk de volgende opdracht:

 # crontab -u <user> -e

Je kan toevoegen sudo te.

Zoals @rackandboneman al zei, is het niet nodig om te knoeien met /etc/cron.d/ bestanden. Als de kwestie betrekking heeft op de cron-taken van de gebruiker, gebruikt u de functies van crontabcommando.


2
2017-09-06 15:10



-1 Het grote nadeel van het bovenstaande is dat de gebruiker nu ook de cronjob kan wijzigen / verwijderen / verbreken, wat meestal niet wenselijk is wanneer u als beheerder uw waardevolle tijd besteedde aan het instellen van dingen ... Ook wanneer de gebruiker is een serviceaccount en dat account is vergrendeld / verlopen, de service blijft actief, maar persoonlijke cron-tabbladen voor vergrendelde accounts worden meestal uitgeschakeld. - HBruijn
Als de hier opgegeven gebruiker een openbare gebruiker is, zoals een lid van een openbare-eindserviceomgeving, hebt u gelijk. Echter, als het gaat om de gebruiker van een service / agent ... bij nader inzien gaat het echt om stijl. - aesnak