Vraag Hoe server veranderingen op te nemen?


Dus we hebben allemaal waarschijnlijk deze situatie gehad: je debugt een probleem, alleen om je te realiseren dat het is veroorzaakt door een configuratiewijziging die je zes maanden geleden hebt gemaakt, en je kunt je niet herinneren waarom je het hebt gedaan. Dus je maakt het ongedaan en lost het probleem op, en nu komt er een ander probleem terug. Oh ja, dat herinner ik me! Dan repareer je het goed.

Het is omdat je geen goede aantekeningen hebt gemaakt, idioot! Maar wat is een goede manier om dit te doen?

In engineering hebben we heel veel software die bedoeld is om ons te helpen wijzigingen te detecteren en op te volgen. Bronbeheer, codereviews, enzovoort. Elke wijziging wordt bijgehouden, elke wijziging vereist een opmerking over wat het is. En typische engineeringafdelingen vereisen goede opmerkingen, zodat je in zes maanden, wanneer je uitzoekt waarom je het zo hebt gebroken, een historische 'blame'-functie of binaire zoekacties kunt gebruiken om het probleem op te sporen. Deze tools zijn zeer effectieve communicatiehulpmiddelen en historische records.

Maar in serverland hebben we 500 verschillende services, allemaal met verschillende manieren om ze te configureren. En ze hebben niet altijd een tekstindeling (denk aan het instellen van rechten op een map of het wijzigen van de locatie van het paginabestand) hoewel ze een tekstuele weergave kunnen hebben.

In onze omgeving controleren we in welke configuratiebestanden we Perforce kunnen gebruiken, maar er zijn er maar heel weinig. Kan de Active Directory DB niet precies checken ... hoewel er misschien een puinhoop is die anders zou kunnen zijn ...

In het verleden heb ik geprobeerd een logboek voor handmatige wijzigingen bij te houden in onze wiki, maar het is super moeilijk om de discipline te handhaven om dit te doen (ik weet het, geen goed excuus, maar het is echt moeilijk).

MIJN VRAAG: Welke strategieën en hulpmiddelen gebruik je om dit probleem op te lossen door configuratiewijzigingen bij te houden naar je servers?

-- Bijwerken --

Opmerking: ik ben niet op zoek naar tools voor het maken van gedeelde notities (ik ben bekend met OneNote, enzovoort), maar ook met geautomatiseerde hulpprogramma's die specifiek zijn bedoeld om te helpen bij het bijhouden van serverwijzigingen. Er is geen uitgebreide tool voor het bijhouden van serverconfiguratiewijzigingen, maar misschien zijn er enkele voor specifieke toepassingen zoals GPO's.

Ook ben ik erg geïnteresseerd in specifieke strategieën die je nuttig hebt gevonden. "We delen aantekeningen in Sharepoint" is vrij vaag. Hoe onderhoud je de discipline? Welke indeling gebruikt u om uw wijzigingen bij te houden? Hoe organiseert u uw wijzigingsgegevens? Ik zou echt graag voorbeelden en ideeën willen.


49


oorsprong




antwoorden:


In Linuxland volgen mensen een aantal verschillende strategieën:

  • Configuratiebeperkingssystemen, net zoals cfengine of marionet of chef. Deze zijn vergelijkbaar met Windows-groepsbeleidsobjecten. Een punt is dat alle serverconfiguraties opzettelijk op één plek zijn gedocumenteerd en u weet op welke granulariteit (serverruimte, groep, specifieke server) het beleid van toepassing is. Dit zal je niet echt redden van "wat was er in godsnaam zes maanden geleden anders?" maar het laat je gewoon een serverconfiguratie wijzigen en opnieuw opbouwen. U kunt het cfengine- en marionettenbeleid onder revisiecontrole plaatsen om de vraag te beantwoorden.
  • Revisie controlling / etc. Over het algemeen slaan Linux-programma's hun configuratie op één plaats op, enz. De durf begint scripts te schrijven om / etc in revisiecontrole te plaatsen. Een dergelijk programma dat ik ken is etckeeper:
Beschrijving: store / etc in git, mercurial, bzr of darcs
 Het etckeeper-programma is een hulpmiddel om / etc te laten opslaan in een git, mercurial,
 bzr of darcs repository. Het haakt in APT om wijzigingen automatisch vast te leggen
 gemaakt naar / etc tijdens pakketupgrades. Het volgt bestandsmetadata die versie
 besturingssystemen ondersteunen normaal niet, maar dat is belangrijk voor / etc, dus
 als de machtigingen van / etc / shadow. Het is vrij modulair en configureerbaar, terwijl
 ook eenvoudig te gebruiken als je de basis van het werken met versie begrijpt
 controle.

19



+1 voor het vermelden van beide soorten systemen, en specifiek etckeeper, wat dit vrij eenvoudig maakt - werkt met git of hg. - RichVel
Ik gebruik er een om de andere te installeren, en dus beide. - Dan Garthwaite
Ter info: de cfengine link verwijst naar www.cfengine.org, die nu is verbroken. De officiële site bevindt zich nu op www.cfengine.com. Ook ectkeeper heeft nu een startpagina op etckeeper.branchable.com - e_i_pi
@e_i_pi en ook poppen zijn geen poppetjes meer. - jldugger


Een van de problemen in deze situatie is dat het eigenlijk een combinatie is van een bedrijfsproces / technologisch probleem. En het is absoluut groter dan alleen bijhouden welke wijzigingen een admin heeft aangebracht. U moet ook opletten voor onverwachte wijzigingen en een goede coördinatie tussen beheerders of eenheden, zodat een wijziging in een AD-controller de machtiging van een database op sommige afdelingsservers niet verbreekt. Dat wil zeggen, je vraag is een gigantisch blikje wormen :)

In mijn organisatie zijn we ongeveer een jaar bezig met het uitrollen van processen en systemen om dit aan te pakken. Voor de bedrijfsproceskant vormden we een team voor verandermanagement. Volgens SOP worden alle veranderingen in productieomgevingen via hen gecoördineerd. Ze compileren alle wijzigingen, samen met de reikwijdte, getroffen systemen, getroffen services, enz. Doen goede documentatie over de wijzigingen aan, evenals zowel de roll-out als de roll-back plannen. Organiseer wekelijkse (open) vergaderingen om de komende veranderingen in de omgeving te bespreken en stuur vervolgens e-mails met informatie over al deze wijzigingen. Het einddoel van dit proces is dat iedereen in IT alles weet wat er gaande is. Dit helpt bij het stoppen van het probleem van bijvoorbeeld een SysAdmin die een kernel-patch installeert en een systeem herstart dat de tijdklokdatabase zal uitschakelen.

Wat de technologische kant betreft, kan ik alleen maar spreken van de Unix / Linux-gebruikers, aangezien ik niet met Windows te maken heb. Ze hebben Puppet, door Reductive Labs, uitgerold voor configuratiebeheer van al deze systemen. Simpel gezegd, is een client / server-systeem waarbij een computerconfiguratie op de server wordt gedefinieerd en de client deze af en toe af en toe haalt (standaard 30 minuten). Bovendien, als er lokaal kansen worden gemaakt op beheerde bestanden, worden ze ook op dat moment teruggezet. We gebruiken het voor het beheren van hardloopdiensten, firewallconfiguraties, gebruikersautorisatie, etc.

Ik zou ook aanraden om naar iets als TippingPoint te kijken. Het is een clientservice die de systeemconfiguratie bekijkt en waarschuwingen over wijzigingen verzendt. Het maakt ons beveiligingsmensen het meest gelukkig. Het wordt grotendeels gebruikt voor het volgen van kwaadwillende of niet-gepubliceerde wijzigingen.


9



Wanneer u popconfiguratiebestanden opslaat in een VCS, krijgt u een volledige geschiedenis en logboek van uw serverconfiguraties, erg netjes :) Maar voor het converteren van alles naar een marionetten-script is een andere discipline vereist: D - hayalci
Ik heb nooit gezegd dat het gemakkelijk was, alleen nuttig :) De truc met marionet is om veelvuldig gebruik te maken van modules, een om te onthouden dat je inspanningen zullen beloond worden. Nu, als alleen RSA enVision een parser had voor de logs ... - Scott Pack
U hebt absoluut gelijk dat het probleem groter is dan alleen de technologie van het registreren van wijzigingen. Maar laten we het probleem ook niet uitbreiden naar het rijk van het onoplosbare. Het hebben van een effectieve tool kan je team focussen en niet het vernietigen van het moreel van het proberen een verandering in hun manier van denken te bewerkstelligen. Ik heb een paar verschillende systemen geïmplementeerd, het beste is waarschijnlijk nog steeds de wiki-pagina met een tabel met wijzigingen, maar het is nog steeds niet perfect. / etckeeper is absoluut een voordeel, maar moeilijk te schalen over systemen. en het belangrijkste: Active Directory! Dit is de belangrijkste behoefte. - ckg


Ik ben bij 4 of 5 bedrijven geweest die ik me niet echt herinner.

We hadden allemaal dit probleem. Niemand van ons heeft het voor honderd procent opgelost, maar bij het bedrijf waar ik nu ben, hebben we volgens mij de beste strategie tot nu toe.

Sharepoint / Wiki / Evernote / pincodes

  • Deel punt
    • kreunen alles wat je wilt ... het heeft een aantal zeer mooie lijst functies.
    • IP-adreslijsten
    • inventaris
    • serviceaccounts en gebruik
    • wijzig notificatie logs
  • wiki
    • How-to's
    • lange afstand takenlijsten
  • Evernote
    • mijn partner en ik gebruik dit om alles wat we niet willen in Wiki te plaatsen
    • meer how-to's die technisch van aard zijn
    • scratch notities die we allebei moeten zien
    • taakaccounting voor de week
    • opdrachtlijsten voor aannemers
    • Evernote Clipper maakt het gemakkelijk om de opname AD / rechten-instellingen te screenen
    • overal beschikbaar
  • pincodes
    • Wachtwoord repository

3





Er zijn waarschijnlijk betere tools voor sommige hiervan, maar dit is wat we gebruiken:

  • Houd configuratiewijzigingen en upgrades / patches per server bij in a privé wiki
  • Houd ook howtos en een overzicht van problemen / oplossingen in de wiki
  • Gebruik Deel punt of Google documenten om kopieën te bewaren van dingen zoals statische IP-lijsten
  • gebruik omverwerping om wijzigingen in configuratiebestanden bij te houden

1



ik gebruik graag broncontrole op configuratiebestanden - dwingen jullie "nuttige" opmerkingen af ​​bij het inchecken of een versie uit? - warren
Nee, ik heb in feite een paar scripts geschreven (indienen en terugdraaien) om het indienen en terugzetten van wijzigingen eenvoudiger te maken. We zijn nu echter aan het experimenteren met etckeeper. - Brent


Voor Windows, bekijk Microsofts System Center-serie of een andere concurrent in configuratie- en servicebeheer voor dat platform.

De wijzigingen moeten worden doorgevoerd via een fatsoenlijke change management-routine die ze zelf goedkeurt en registreert voordat ze daadwerkelijk zijn voltooid. Dit kan 100% handboek zijn voor starters. Met een aantal van de beter geïntegreerde tools zou je de tool kunnen vragen om de feitelijke wijzigingen uit te voeren en het automatisch uit te loggen naar een centrale configuratiedatabase - in plaats van met blote handen de console van een individuele server binnen te gaan, handmatig door de instellingen graven. probeer een probleem-cowboy-stijl op te lossen.


1





U moet absoluut een proces voor wijzigingsbeheer hebben, vooral als er meerdere personen zijn die over de mogelijkheid / toegang beschikken om wijzigingen op systeemniveau in uw omgeving aan te brengen. Dit biedt ook een manier voor het management om zich af te melden voor mogelijke wijzigingen, maar het nadeel hiervan is latentie in het veranderingsproces opwekken als u niet on-the-fly wijzigingen kunt aanbrengen.

Sommige manieren om wijzigingen te volgen zijn onder meer de validatie van gebeurtenissen in uw SEM (ervan uitgaande dat u een Security Event Manager hebt) of hulpmiddelen zoals Nessus (met veel werk kan uw omgeving worden gecontroleerd om wijzigingen te vinden).


1





Dit is een meer gelokaliseerd, * nix gebaseerd antwoord. Ik heb geen goede tools gevonden om het onder Windows te emuleren.

Er zijn een paar manieren om dit te implementeren ... en te vangen als je het vergeet.

Revisiebesturingssystemen zoals subversion, git, cvs of RCS zijn een goede manier om de geschiedenis van een configuratiebestand bij te houden. Als u geen revisieregelsysteem op uw productieservers wilt installeren, kunt u configuratiebestandsmappen lokaal of op afstand opslaan met behulp van iets als rsnapshot geeft je de meeste voordelen van een RCS, maar je verliest de mogelijkheid om audits uit te voeren of commit logs te verlaten (hoewel dit kan worden opgelost met opmerkingen binnen de bestanden zelf).

Om u te helpen herinneren aan het registreren van de wijzigingen, geautomatiseerde rapportage van configuratiewijzigingen via een nachtelijke, cron'ed tripwire rennen is een goed begin. Na het bouwen van de database van tripwire van de huidige status van bestanden, zal elke wijziging hiervan resulteren in een e-mail tijdens de volgende run. U blijft deze e-mail ontvangen totdat de database is bijgewerkt, waardoor de tripwire opnieuw wordt 'gereset'.


1





Ik zou een systeem gebruiken om problemen op te lossen, zoals flyspray (wat het ook zal doen, maar ik hou van flyspray voor dingen die niet programmeren). Voordat iemand een configuratie aanraakt, moet de verbetering / het probleem worden vastgelegd. Als je het oplost / implementeert, gaan de wijzigingen in het ticket.

Een wiki kan leuk zijn om de huidige instellingen te documenteren, maar het is gemakkelijk om te verouderen - en het lijkt meer moeite te kosten om IMO bij te werken.

Je zult hier niets geautomatiseerds voor vinden - hoewel je het waarschijnlijk zou kunnen instellen, dus wijzigingen in bepaalde configuratiebestanden werden automatisch naar de issue-tracker gemaild als je dat wilde.

Ik denk dat het gewoon een kwestie is van een goed beleid, weinig barrière-instrumenten en discipline.


0





We hebben iets homegrown gemaakt om het bijhouden van veranderlogboeken in onze omgeving te doen; het is niets super gecompliceerd, en het werkt best goed.

  • Er is een zelfregulerend beleid ingesteld dat elke wijziging die naar uw schatting afwijkt van een standaardinstallatie of mogelijk problemen kan veroorzaken, moet worden gedocumenteerd in het changelog-systeem.
    • andere kant van deze 'munt' is als u een probleem probeert op te lossen, zoek dan naar recente of gerelateerde changelog-vermeldingen.
  • Meld u aan bij het systeem en kies de server, service of hardwarecomponent die u wilt wijzigen
    • de componenten zijn eerder in hetzelfde systeem ingevoerd met elementaire 'demografische' informatie (locatie, leverancier, serienummer, verantwoordelijke afdeling)
  • Kies uit een drop-down van basiscategorieën
    • Ongeplande downtime
    • patchen
    • Hardware onderhoud
    • Software installatie
  • Vermeld details over wat je deed, zag, observeerde
  • een kopie wordt verzonden naar de verantwoordelijke partij en opgeslagen als XML-bestanden die worden geïndexeerd door een zoekmachine.
  • Winst

Zoals ik al zei, niets bijzonders. Het maakt gebruik van PERL CGI (is een miljard jaar geleden geschreven) en een Google Search-apparaat voor indexering.

tekortkomingen:

  • Groepen services zijn moeilijk om mee te werken, u heeft bijvoorbeeld dezelfde patch toegevoegd aan alle 25 van uw domeincontrollers; we hebben geen "domeincontroller" -groep, dus we moeten ze allemaal handmatig selecteren
  • Kan niet worden geïntegreerd met hardware-, software- of gebeurtenislogboek foutrapportage om te helpen bij het oplossen van problemen
  • gerelateerd, handmatige gegevensinvoer voor alle 'demografische' gegevens zoals ik hierboven heb gezegd

Hoe dan ook, als u toch geïnteresseerd bent in de code, laat het me weten en ik kan het waarschijnlijk delen om te delen.


0





Zoals gezegd, het is vaak een cultureel probleem - sommige ontwikkelingswinkels doen tegenwoordig niet meer aan opmerkingen (zelfdocumentatiecode is tegenwoordig een trendy buzzword!) En sommigen gebruiken een versiecontrolesysteem als een heilige graal van historische records. Het is duidelijk dat deze niet perfect zijn.

De enige echte manier om het probleem op te lossen is dus om er een culturele oplossing van te maken. Zorg ervoor dat alle redenen voor verandering zijn vastgelegd in een bugtracker (of kennisbank of wiki) en zorg ervoor dat alle wijzigingen in een wijzigingscontrolesysteem zijn vastgelegd.

We hebben hulpdienstenklanten, elke wijziging die hun systeem overkomt, wordt vastgelegd en elke keer dat we bij hun systeem inloggen, moeten we het loggen. Voor sommigen van hen moeten we eerst om toestemming vragen (en ik denk dat ze dat ook loggen!). elk verandering wordt gelogd en het zal een disciplinaire overtreding zijn om het klantensysteem te veranderen zonder het te loggen.

Het klinkt zwaar, maar dat is het niet. U maakt snel de gewoonte om uzelf aan het toegangslogboek en het wijzigingslogboek toe te voegen - het is niet erger dan een opmerking te moeten schrijven bij het inchecken van een codewijziging.

Ik raad een bugtracker aan als het logboek van de wijzigingsreden, omdat ze meestal eenvoudig kunnen worden bijgewerkt (ik gebruik Mantis).


0





Als u op zoek bent naar de "enterprise-oplossing" (dat wil zeggen dat u meer geld hebt dan God en een echt coole tool wilt hebben), is de tool die ik ter ondersteuning en ter plaatse heb gebruikt, een van de vele functies.

Geen idee wat de basisprijzen zijn, maar voordat HP Opsware kocht, was het ~ $ 350.000 VS (zonder ondersteuning, en geloof me - je wilde ondersteuning toen ik begon met Opsware).

Verschillende van de klanten die we hadden toen ik daar werkte, gebruikten de applicatieconfiguratie en snapshot-functies in combinatie met Tripwire.

Natuurlijk, als je geen budget hebt - dit is een slechte keuze ™ :)

En, fwiw, de advertentie die bovenaan deze pagina voor mij verscheen toen ik herlaadde waar het voor was Spiceworks. Ziet er machtig lijkend op HPSA :)


0