Vraag Hoe kunnen de kleine jongens Puppet effectief leren en gebruiken? [Gesloten]


Zes maanden geleden besloten we in ons non-profitproject om ons systeembeheer te migreren naar een Puppet-gecontroleerde omgeving, omdat we verwachten dat ons aantal servers tussen nu en een jaar aanzienlijk zal groeien.

Sinds de beslissing is gemaakt, zijn onze IT-jongens een beetje te veel geïrriteerd geraakt. Hun grootste bezwaren zijn:

  • "We zijn geen programmeurs, we zijn sysadmins";
  • Modules zijn online beschikbaar, maar veel verschillen van elkaar; wielen worden te vaak opnieuw uitgevonden, hoe bepaal je welke past bij de factuur;
  • De code in onze repo is niet transparant genoeg om te achterhalen hoe iets werkt dat ze moeten herverpakken door middel van manifesten en modules die ze zelf misschien al een tijdje geleden hebben geschreven;
  • Een nieuwe daemon vereist het schrijven van een nieuwe module, conventies moeten vergelijkbaar zijn met andere modules, een moeilijk proces;
  • "Laten we het gewoon uitvoeren en zien hoe het werkt"
  • Tal van nauwelijks bekende 'extensies' in community-modules: 'trocla', 'augeas', 'hiera' ... hoe kunnen onze sysadmins bijhouden?

Ik begrijp waarom een ​​grote organisatie hun sysadmins naar marionettencursussen zou sturen om marionettenmeesters te worden. Maar hoe kunnen kleinere spelers Puppet leren op een professioneel niveau als ze niet naar cursussen gaan en in principe leren via hun browser en editor?


106
2018-06-06 08:38


oorsprong




antwoorden:


Ik begon Puppet te gebruiken voor de implementatie van een nieuwe infrastructuur en kocht gewoon eengoed beschouwd) boek over het onderwerp. Ik denk niet dat de meeste mensen professionele Puppet-training krijgen. Ik werkte aan voorbeelden totdat ik het proces kon inrichten naar mijn omgeving. Dit was december 2011, dus binnen een paar weken was ik in staat om de basisprincipes te begrijpen en een productiekader te krijgen. Ik was niet nieuw voor configuratiebeheer, met een cfengine achtergrond, maar veel van de zorgen van je sysadmins resoneren. Ik heb fouten gemaakt en moest meerdere keren refactoren maken, maar ik heb de zaken naar behoren laten werken.

Een paar opmerkingen over uw punten ...

  • De traditionele rol van systeembeheer is aan het veranderen. Aanpassen of achterblijven. Ik ben een succesvolle systeemingenieur, maar moet ook een nieuwe versie maken (bijvoorbeeld Python leren). De focus op individuele servers wordt kleiner omdat hardware-abstractie door virtualisatie en publieke en private cloudservices meer grip krijgen. Dit betekent automatisering van systeemtaken en het gebruik van configuratiebeheer om de controle over een groter aantal servers te ontnemen. Toevoegen DevOps-concepten naar de mix, en je zult zien dat het klant / eindgebruiker verwachtingen en eisen veranderen.

  • Puppet-modules die online beschikbaar zijn verschillen in stijl en structuur en ja, ik zag veel overlap, redundantie en dubbele inspanningen. Een ontwikkelaar met wie ik werkte, zei: "je had je eigen tools kunnen ontwikkelen in de tijd dat je op zoek was naar iets dat werkt!" Dat gaf me een pauze, toen ik me realiseerde dat Puppet meer op ontwikkelaars lijkt te lijken dan beheerders die op zoek zijn naar een best-practices of de juiste manier nadering.

  • Documenteer zwaar om een ​​gevoel te krijgen hoe de dingen verbonden zijn. Gezien de wankele definities en het ontbreken van een standaard- manier van doen, uw configuratiemanagementstructuur is echt uniek voor uw omgeving. Die transparantie moet binnenin worden ontwikkeld.

  • Ik zou zeggen dat het redelijk gemakkelijk is om een ​​module te dupliceren om een ​​nieuwe daemon te accommoderen of een service aan een bestaand manifest toe te voegen, afhankelijk van hoe je je servers en rollen hebt georganiseerd.

  • Ik heb veel tijd besteed aan het testen van een enkel doelwit voordat ik veranderingen doorvoerde naar grotere groepen servers. Door met de hand op een representatieve server met de hand te lopen, kon ik wijzigingen opsporen en hun impact beoordelen. Misschien is dat een beetje conservatief, maar het was noodzakelijk.

  • Ik weet niet zeker hoeveel ik afhankelijk ben van community-modules. Ik moest wel gebruik Augeas voor wat werk, en betreurde het feit dat het een functionaliteit was die ik als vanzelfsprekend vond in CFEngine.

In totaal heb ik het gevoel dat er geen goed gedefinieerde standaard bestaat als het gaat om Puppet. Ik had moeite om uit te zoeken hoe de directorystructuur op mijn Puppetmaster moest worden georganiseerd, zodat ik kon begrijpen hoe ik het ondertekenen van certificaten kon beheren juiste omgekeerde DNS overal op zijn plaats, om Puppet op de juiste manier op te schalen voor het milieu en inzicht in het gebruik van communitymodules versus het bouwen van mijn eigen modules. Het is een verschuiving in denken en ik zie hoe dat een panieksyndroom zou kunnen veroorzaken. Dit was echter ook een nieuwe oplossing, dus ik had de luxe om tools te evalueren. De beslissing om deze kant op te gaan was gebaseerd op mindshare en het momentum achter Puppet. Het was de moeite waard om iets nieuws te leren.

Onthouden, deze site is ook een goede hulpbron.


101
2018-06-06 09:02



Ik ging van geen enkele ervaring met Puppet naar het feit dat mijn complete omgeving in twee weken tijd plat was. Ik ben verantwoordelijk voor ~ 40 virtuele machines, hoewel ze allemaal Ubuntu draaien. Die vereenvoudigde dingen nogal een beetje. Ik ben een ontwikkelaar van beroep. "Pas aan of laat je achter" - ik ben nu devops + sysadmin + architect. Uitstekend antwoord! - François Beausoleil
Ik zou ze aanraden om kleine services te implementeren, eerst als zelfstandige en dan te sleutelen aan meer servers. Ik hoef niet met Puppet te werken, maar ik heb een klein VPS en heb onlangs mijn eigen Puppet-modules gemaakt. Als ze de rest van de systemen in de huidige eeuw bij willen houden, kunnen ze beter ruimdenkend zijn. Ik doe het omdat ik het leuk vind, en ik denk dat niet iedereen het leuk vindt om nieuwe dingen te leren, maar één ding is zeker: tegenwoordig zijn sysadmins dichter bij ontwikkelaars dan ooit. - Sergio Galvan
Ik werk in een klein bedrijf en ik loop ook puppetd -t voor testen op een paar vakjes voordat alle servers worden gepusht. Het faalt nooit dat een paar iets unieks heeft waardoor mijn updates niet werken. Puppet is een stuk eenvoudiger als je voor het begin een gecontroleerde en consistente omgeving hebt. - jordanm
@ewwhite, ik heb mijn weg door de puppet-zelfstudie doorgewerkt in hun documenten maar vroeg me af welk boek je hebt gebruikt toen je het leerde? Ik heb het gevoel dat de tutorial in de documenten iets ontbrak waardoor ik niet kon klikken terwijl ik met Puppet aan het werken was op testhosts om te leren wat ik aan het doen ben. EDIT: Of alle aanvullende bronnen die u kunt aanbevelen. Bedankt. - Mike Keller
@MikeKeller Ik vond het leuk in mijn bericht ... Maar het is beschikbaar Hier. - ewwhite


Bij een vorige baan kreeg ik de taak om een ​​pilot-implementatie van Puppet uit te voeren. Nu heb ik een programmeerachtergrond, maar geen Ruby, dus ik heb niet zoveel problemen als anderen.

Het is echter interessant om op te merken dat programmeurs zonder ervaring met niet-traditionele paradigma's heb ik ook problemen met Puppet, omdat Puppet is verklarend, niet noodzakelijk. In deze zin werkt Puppet vrijwel zoals elk configuratiebestand: je zegt hoe dingen moeten zijn en Puppet zorgt voor de rest.

Na de pilot kreeg ik de gelegenheid om een ​​dozijn andere admins met Puppet te trainen en presentaties te geven in twee evenementen. Mijn mening uit die ervaring is dat sommige admins erover hebben gedaan, en sommige niet. Dit waren allemaal traditionele beheerders, zonder programmeerkennis en verschillende expertiseniveaus.

Een specifiek ding dat mij opviel, is dat Puppet vereist constante praktijk. Mensen die zijn opgeleid, modules hebben geschreven en vervolgens een hele maand of twee hebben gedaan om iets anders te doen, kwamen terug naar Puppet met weinig nuttige vaardigheden. Mensen die er elke week kleine dingen in bleven doen, verloren nooit het vermogen.

Op basis van deze twee observaties, raad ik je aan om ervoor te zorgen dat iedereen elke week wat Puppet-klasse, -definitie of -module toevoegt (bij voorkeur minstens twee of drie keer). Degenen die er nog steeds niet aan kunnen wennen, hebben echt niet de vaardigheid om het te doen.

Aan de andere kant, als Puppet hogerop werd opgelegd, zouden ze misschien gewoon reageren op wat ze zien als een management dat indringt in hoe ze hun werk doen - wat in feite waar zou zijn. Het kan zijn dat ze laten kiezen welke configuratiemanagementsysteem om te gebruiken, zou de dingen verbeteren. Hier zijn enkele alternatieven:

  • Ansible: Dit is nieuw, maar het is gebaseerd op shell-commando's en ssh, wat het zou kunnen verleiden tot traditionele sysadmins.
  • Chef: Misschien is hun probleem declaratieve stijl, in welk geval Chef beter zou zijn als ze Ruby-ervaring hebben.
  • SaltStack: Op Python gebaseerde en open-source
  • cfengine: oud, snel, traditioneel - het zou hen op die gronden kunnen winnen.

29
2018-06-06 15:59



Het leuke van ANSIBLE is dat het over galactische afstanden werkt met absoluut geen vertraging in de datatransmissie! - Kalamane
Bedankt voor de ANSIBLE vermelding. Ik was er tot nu toe niet van op de hoogte. - ewwhite
@ewwhite Graag gedaan. Ikzelf heb het pas recent ontdekt, maar er is veel aandacht aan besteed. Als we al niet zo veel in Puppet hadden, zou ik het zeker eens proberen. - Daniel C. Sobral


Ik gebruik Puppet al meer dan twee jaar in kleine winkels waar ik de enige beheerder was. De grootste hindernis die ik heb gehad, is leren hoe ik software op de juiste manier kan ontwikkelen. Er was geen week voorbij waarin ik niet iets verknoeide dat ik ontwikkelaars had verteld dat ze het niet een dozijn keer moesten doen. Ik heb te veel code ingecheckt, ik heb de check-ins niet verbroken, ik heb niet getagd, ik heb niet vertakt, heeft de syntax-checker niet uitgevoerd, heeft geen standaard gebruikt, etc. Als je net begint Ik zou enkele van de volgende aanbevelingen aanbevelen.

  1. Realiseer u dat u software ontwikkelt die u ofwel niet kent, of niet goed doet. Dit wordt verwacht omdat het nieuw is.
  2. Infrastructuur als code is de realiteit en als je eenmaal over de bult heen bent, is het behoorlijk krachtig. Ik nodig een aantal ontwikkelaars uit, laat ze je huidige ontwikkelingsproces zien (of het gebrek daaraan), neem geen aanstoot wanneer ze hun wenkbrauwen optillen en neem hun suggesties serieus. Ik raad je aan om het systeem en het proces dat je ontwikkelaars gebruiken te gebruiken, tenzij het volledig ongepast is.
  3. Puppet-modules van derden zuigen 90% van de tijd. Ik zou ze lezen. Ik zou ideeën van hen stelen. Ik zou ze niet zonder grote bewerkingen in mijn systeem opnemen. Ik zou echter de poppet-stdlib erbij halen die wat leuke functionaliteit toevoegt.
  4. augeas en hiera. Leer die twee. De eerste maakt complexe bewerking van bestaande bestanden mogelijk. De tweede is een extern gegevensarchief.
  5. Aparte code van gegevens. Dit is een van de moeilijkere concepten om te leren. Hardcoding-waarden zoals Monitoring Hosts in uw modulecode zijn slecht. Zet ze in een data store (db, yaml (Hiera gebruikt deze standaard), csv, wat dan ook) die je modules kunnen gebruiken, is goed. Een voorbeeld is een webapp die Mysql gebruikt. Wat dit toestaat, is de mogelijkheid om code en gegevens afzonderlijk te pushen. Dit maakt uw ontwikkelingsproces eenvoudiger.
  6. marionettenparser valideren en puppet-lint als onderdeel van het proces van pre- of postcodecontrole. Ook zijn rspec tests misschien een goed idee als je op snelheid bent.
  7. schrijf een stijlgids / codestandaard en gebruik deze. "waar is de code die Apache installeert" is een veel voorkomend probleem. Als uw modules grotendeels hetzelfde zijn, zou het eenvoudig moeten zijn.

Samenvattend heb ik al deze problemen getroffen en dus hebben de meeste van mijn sysadminvrienden. Het kost wat tijd om goed te worden in het gebruik van een configuratiebeheersysteem. Als je dat eenmaal doet, vraag je je af hoe je ooit zonder hebt geleefd. "Log in op een server en breng handmatig wijzigingen aan? Ick."


11
2018-06-06 18:04



Bedankt voor je suggesties, vooral augeas en hiera zijn twee componenten die we zijn begonnen te implementeren en dit heeft ons veel bewuster gemaakt, zelfs vol vertrouwen van de mogelijkheden van Puppet. Dus bedankt :-) - drumfire


Zes maanden geleden besloten we om in ons non-profitproject te starten   het migreren van ons systeembeheer naar een Puppet-gecontroleerde omgeving   omdat we verwachten dat ons aantal servers aanzienlijk zal groeien   tussen nu en een jaar vanaf nu.

Klinkt als een goed idee om vroeg te beginnen - Puppet is meer dan alleen configuratiebeheer, het is een vorm van documentatie.

Sinds de beslissing is gemaakt, zijn onze IT-jongens ook een beetje geworden   geërgerd een beetje te vaak.

Ze hebben een aanpassing van de houding nodig.

"We're not programmers, we're sysadmins";

Nogmaals, houding. U kunt een conf-bestand maken voor een server, toch? Je kunt het sjabloneren / 'programmeur'-spul verzachten zoals je behoeften en complexiteit evolueert.

Modules zijn online beschikbaar, maar veel verschillen van elkaar; wielen   worden te vaak opnieuw uitgevonden, hoe bepaal je welke past bij de   Bill;

Moeilijk te beantwoorden - ik heb altijd de voorkeur boven de poppentheater-modules - en zelfs daar gebruik ik niet zoveel. Oordeel van het oordeel zeker. Naar mijn mening zijn sommige modules 'te frilly'.

De code in onze repo is niet transparant genoeg om te ontdekken hoe iets werkt dat ze moeten herverpakken door middel van manifesten en modules die ze mogelijk gebruiken   hebben zichzelf zelfs een tijd geleden geschreven;

Dit klinkt niet als een marionettenprobleem, maar meer als een probleem met de organisatie of documentatie?

Een nieuwe daemon vereist het schrijven van een nieuwe module, conventies moeten zijn   vergelijkbaar met andere modules, een moeilijk proces;

Die daemon kan een klasse zijn als hij eenvoudig genoeg is om te beheren. Ik weet niet zeker wat je bedoelt met conventies, marionet dwingt conventies goed af voor jou, nietwaar? Of praten we in de trant van code-opmaak?

"Let's just run it and see how it works"

Niet zo slecht als je het langzaam en veilig aanpakt. Ik zou nog steeds met een VM beginnen om de kern van dingen te begrijpen.

Tal van nauwelijks bekende 'extensies' in community-modules: 'trocla',   'augeas', 'hiera' ... hoe kunnen onze sysadmins bijhouden?

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl modules .. Kies wat je wilt en gebruik het? Ik denk dat dit weer meer als een attitude-ding klinkt ...

Ik begrijp waarom een ​​grote organisatie hun sysadmins zou sturen   Poppencursussen om poppenspelers te worden. Maar hoe zouden kleinere spelers   Leer Puppet professioneel leren als ze dat niet doen   cursussen en eigenlijk leren via hun browser en editor?

Ik heb geen cursussen gevolgd - terwijl ik ben een programmeur meer dan een sysadmin, ik merkte dat het niet veel programmeervaardigheden nodig had om iets bereikt te krijgen.

De Puppet-documentatie, wanneer deze wordt gevolgd, is behoorlijk grondig. Let gewoon op de ingebouwde typen en besteed wat tijd aan het kijken hoe andere modules worden samengesteld. Ik zou niet zeggen dat het -super- eenvoudig is, maar het is ook niet -hard-. Het kost wat tijd om uw infrastructuur gereed te maken voor marionetten, maar de geïnvesteerde tijd is gegarandeerd goed besteed aan uw uitbreiding.


7
2018-06-06 14:04



Ter informatie: dit komt van iemand die - net - klaar was met het klaarstomen van hun infrastructuur om te rollen. Dus ik heb een frisse ervaring en kan niet zeggen dat het tijdverspilling was. - thinice
Als een recente starter zelf, herken ik mezelf volledig in je commentaar. - Martijn Heemels
In mijn geval was een mentaliteitsverandering inderdaad noodzakelijk. Ops houden van automatisering en schrijven vaak dingen, dus het is meestal een kwestie van verschillende tools gebruiken. Het is een gaaf gevoel om je Puppet manifest te zien vanaf het begin een complete machine of een nieuwe service configureren. Het feit dat een fout meerdere machines tegelijk kan beïnvloeden, is wennen aan rigoureuzere tests, wat vervelend kan zijn, maar uiteraard een goede zaak is. Experimenteer met Vagrant, rspec-puppet, puppet-lint, Geppetto, Git-takken en andere gratis tools en je zult snel je favoriete workflow ontdekken. - Martijn Heemels
Het werken met Puppet heeft me ook geholpen om Ruby te leren, wat Bash als mijn standaardtaal voor systeemtools is gaan vervangen. - Martijn Heemels


KISS (Houd het simpel dom) - Gebruik geen nieuwe technologieën alleen omdat ze er zijn, maar omdat je er een vereiste voor hebt, gebruik het absolute minimum dat voor je inzet vereist is, update indien nodig, probeer niet het bloeden bij te houden rand. Als je begint met een basisconfiguratie en daarop voortbouwt, is het gemakkelijker om het op te pakken terwijl je werkt, en ze zouden geen cursus nodig hebben (zijn deze zelfs beschikbaar?).

Het andere gebied dat je kunt bekijken zijn je sysadmins. Als ze niet zo goed kunnen programmeren, zijn ze dan geavanceerd genoeg voor een grote implementatie, waar het meeste werk moet worden gescript ongeacht welke hulpmiddelen je gebruikt?


5
2018-06-06 09:18



... omdat we verwachten dat ons aantal servers tussen nu en een jaar aanzienlijk zal groeien. Eis? - Jeff Ferland
Hangt er echt van af hoe zeker die verwachting is en of wat je hebt aangebracht nog steeds geschikt zal zijn tegen de tijd dat de behoefte zich daadwerkelijk voordoet. - JamesRyan
+1 voor "gebruik het absolute minimum dat voor je inzet vereist is" - Veel van de problemen met poppetjes die ik heb tegengekomen, komen voort uit het proberen marionetbesturing te maken van alles op het systeem. - Sirex


Ik werk ook voor non-profitorganisaties en was verantwoordelijk voor het initieel introduceren van Linux-boxen in huis en kort daarna Puppet voor het beheer ervan. Er zijn enkele specifieke dingen die we hebben gedaan werkelijk hielp dingen op rolletjes te krijgen.

Eerst en vooral heb ik geprobeerd om weg te blijven van de externe modules. De ingebouwde tools verwerken 90% van ons beheer. Het grootste hulpprogramma van derden dat ik gebruik, is de firewallmodule. Alle aangepaste feiten, enz. Worden ontwikkeld met het hele team dat erbij betrokken is. We hebben een sjabloonmodule ontwikkeld en houden het bestandsbeheer, het pakket, de services, enzovoort allemaal gestandaardiseerd buiten deze sjabloon.

Ten tweede, na het standaardiseren van het gebruik van de ingebouwde modules zijn we Git en Atlassian's Crucible gaan gebruiken - gratis voor non-profits, trouwens - voor het beoordelen van alle configuratiewijzigingen. Dit biedt de gewenste transparantie.

Ten derde heb ik de installatie voor Puppet geautomatiseerd, zodat nieuwe hosts automatisch kunnen worden toegevoegd met een standaardset opties. Er zijn verschillende manieren om dit aan te pakken. Omdat ik al een complete Kickstart-omgeving had, heb ik ervoor gekozen om daar een script toe te voegen.


5
2018-06-06 13:50





"We zijn geen programmeurs, we zijn sysadmins"

Mijn hoe de tijden zijn veranderd, erger: een grijsaard zoals ik was verwacht om een ​​betere programmeur te zijn dan professionele programmeurs, of anders nooit in staat zou zijn geweest om door te geven voor een systeem administrator.

Nu hebben we "systeembeheerders", in feite Windows-desktopgebruikers die op een gegeven moment zijn geconverteerd naar Linux en niet kunnen programmeren, en niets vinden dat daar iets mis mee is.

De olifant in de kamer is de reden waarom het management zo'n destructieve houding tolereert. Destructief voor wie of wat? Voor het bedrijf en voor de infrastructuur.

Terug naar Poppetje [, CFEngine, Chef] -onderwerp: zodra iemand zo'n oplossing instelt, verliest men. Iedereen verliest. Waarom? Omdat degene die met het idee komt niet in staat is om encapsulated configuration management te ontwerpen in de vorm van mooie, schone, Kickstart [, JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM] besturingssystemen. Wanneer u een geautomatiseerde hacktool zoals Puppet (of Chef of CFEngine) moet gebruiken, betekent dit dat u niet over de middelen beschikt om ontwerp en naar uitvoeren een proces dat, door datzelfde ontwerp, volledig ongerepte en afgedwongen beheerde systemen afdwingt, volledig geautomatiseerd en volledig niet-interactief.

Een ander belangrijk punt is, als je Puppet of een dergelijke oplossing moet hebben correct iemand hacking systeem- of applicatieconfiguratie met de hand, dat gaat ook terug naar het niet hebben van de ervaring om een ​​proces te ontwerpen, en in dat proces een raamwerk waarin de configuratie wordt verpakt in afzonderlijke componenten. Degene die Puppet en dergelijke implementeert, heeft feitelijk geen idee van eigenaars van componenten, releases, configuratiebeheer, Capability Maturity Model. Dit ontwikkelt zich snel tot een zeer ernstig probleem in de industrie.

Het werken met Puppet heeft me ook geholpen om Ruby te leren, wat Bash als mijn standaard taal voor systeemtools is gaan vervangen. "

Waarom is Ruby nodig, wanneer een alomvattend end-to-end configuratiebeheer kan worden ingekapseld in pre-installatie, post-installatie, pre-distributie en postremove-secties van besturingssystemen, gewoon door Bourne-shell-programma's, AWK en sed te gebruiken? Dat iemand de esoterische taal van Ruby gaat leren, en een dialect daarvan in de context van Puppet, is helemaal niet nodig. Het probleem van configuratiebeheer is eenvoudig op te lossen (en is opgelost) met shell-programma's en AWK, en een beetje sed (1) hier en daar als een lijm.

Het is een gaaf gevoel om je Puppet manifest te zien vanaf het begin een complete machine of een nieuwe service configureren.

Het is een nog cooler ding om het te zien gebeuren door Kickstart, AutoYaST of JumpStart, zonder een enkele regel code, en in staat zijn om het besturingssysteem te bevragen met behulp van ingebouwde tools, zonder dat esoterische of extra software nodig is, geen client-serverarchitectuur vereist (SSH is meer dan prima, veel meer dan goed), en je besturingssysteem ziet elke wijziging die er wordt aangebracht.

5. Aparte code uit gegevens. Dit is een van de moeilijkere concepten om te leren. Hardcoding-waarden zoals Monitoring Hosts in uw modulecode zijn slecht. Zet ze in een data store (db, yaml (Hiera gebruikt deze standaard), csv, wat dan ook) die je modules kunnen gebruiken, is goed. Een voorbeeld is een webapp die Mysql gebruikt. Wat dit toestaat, is de mogelijkheid om code en gegevens afzonderlijk te pushen. Dit maakt uw ontwikkelingsproces eenvoudiger.

... Of je zou gewoon kunnen sjabloon uw configuratiebestanden met shell-variabelen, zelfs backquotes (bijvoorbeeld ls -1 ...) en schrijf een shell-script dat AWK gebruikt om eval (1) aan te roepen en alle variabelen in de sjabloon uit te vouwen, daarbij gebruikmakend van exact dezelfde krachtige parser die shells hebben ingebouwd. Waarom maakt het complex, als het echt heel eenvoudig kan zijn? Waar slaat u de configuratiewaarden op? Waarom, waar je maar wilt, zoals bijvoorbeeld pkginfo (4) bestanden, of een database zoals Oracle, of eigenlijk overal. Geen behoefte aan ultracomplex oplossingen. De bibliotheek die ik hierboven noemde, zou eenvoudigweg kunnen zijn source van de preinstall of postinstall secties in de pakketten van het besturingssysteem, waardoor duplicatie wordt verwijderd en een centraal stuk code wordt gebruikt ...

Maar bovenal vind ik dat het bovenstaande citaat een voorbeeld is van de volgende generatie systeembeheerders die tutoring nodig hebben, niet door systeembeheerders, maar door systeemingenieurs. Zoek een grijsaard en meld je aan als een leerling.


4
2018-02-11 12:28



Je lijkt je antwoord op de auteursvraag te zijn kwijtgeraakt. - M. Glatki
Dit antwoord lijkt vooral een discussie te zijn over meningen, attitudes en hulpmiddelen en gaat niet echt in op de vraag die gesteld wordt. - JonathanDavidArndt