Documentatie infrastructuur van klanten

[battler]

Hoe houden jullie de infrastructuurgegevens van jullie klanten bij? Er zijn meer dan genoeg tools voor het beheren van klantgegevens, offertes, projecten, planning etc.. Maar echt infrastructuurgegevens als IP-adressen, Gebruikersnamen en wachtwoorden, Topologytekeningen e.d Hoe doen jullie dat?

Ik zie vaak voorbij komen dat bedrijven dit in excel doen. En ik moet toegeven het is vrij gemakkelijk om alles daar in bij te houden maar op een gegeven moment loop je toch tegen limities aan. Wachtwoorden wil je er bijvoorbeeld niet in opslaan en topologytekeningen kan je er niet mee maken. Daarnaast vind ik het ook niet meest overzichtelijke manier om grotere netwerken in te documenteren maar dit laatste kan misschien met de templates te maken hebben.

Hoe doen jullie dit? Excel, zelf geschreven applicatie of is er een netwerkdocumentatieplatform dat iedereen stiekem gebruikt maar waar ik nog nooit van heb gehoord?

[Stoelpoot]

Het is mijn vakgebied niet helemaal, maar kan je niet een 'archief' van gegevens bijhouden per klant. Waarbij je dan bvb een mapje hebt met je tekeningen, een excelsheet met je IP-adres gegevens, en een Keepass-DB met je gebruikersnamen / wachtwoorden. Dan heb je ook geen last van 'dit programma is hier heel goed voor maar daar belabberd in' maar kan je het programma kiezen wat voor die taak het beste werkt.

[NiGeLaToR]

Zodra je een infra-inventarisatie maakt is deze al weer verouderd, dus een tool die dit permanent monitort is op zich het mooiste. Vaak heb je dan meteen monitoring erbij, maar dat hoeft niet. En wachtwoorden bewaar je in een password manager, zoals LastPass, onepass of keepass.

[RedShift]

Word documenten met gestandardiseerde key-value pairs zoals bv.

Server abc
FQDN-Hostname: server.foo.local
OS: VMware ESXi
OS-Version: 5.5.0
Management-IP: 1.2.3.4
...

Ook Excel sheets voor grotere netwerken, meestal dan enkel maar netwerkadressen.

Voor serverracks, RackTables.

[knutsel smurf]

Excel voor de meeste zaken maar dan voeg ik ze toe aan SFDC zodat het makkelijk terug te vinden is.

Voordeel is dat je met SFDC de juiste rechten aan iedereen kan toekennen en het is altijd beschikbaar.

[ddkiller0900]

Netwerk / infrastructuur tekeningen zou je in Visio kunnen maken of als het opensource moet zijn bv. Dia. Andere gegevens kan je opslaan in een configuratie database management systeem (cmdb). Zelf ga ik binnenkort aan de slag met Otrs.

[ Voor 21% gewijzigd door ddkiller0900 op 21-01-2017 18:59 ]

[The Eagle]

Ontwerpen in word, lijstjes in Excel. Overal templates voor, van een installatiedocument tot een low level planning, runbooks en alles wat er tussen zit. En verder laten we meestal overal Splunk los, daar kunnen we vrijwel alles up to date mee vangen. Kost wat maar dan heb je ook wat

[ Voor 26% gewijzigd door The Eagle op 21-01-2017 19:08 ]

[unezra]

IP adressen en wachtwoorden hebben we nog in Excell sheets staan, maar van beiden willen we af.

Waar we heen gaan / heen willen is een combinatie van:
- een CMDB (iTop CMDB is *erg* goed, CMDB met IP administratie, helpdesk software, etc)
- wiki (voor de systeemdocumentatie, wij gebruiken DokuWiki)
- infra plaatjes maken we in Visio (plaatjes kun je dan weer uploaden naar je wiki)

Wachtwoorden hebben we nog niet echt een oplossing voor.

Overigens hebben wij geen klantdocumenatie, we beheren immers geen klanten, alleen onze eigen infra. De tools zijn wel universeel inzetbaar. iTop kun je prima zo configureren dat klanten eigen CI's hebben en daarmee vormt het dus een onderdeel van je systeemdocumentatie.

Op een wiki is dat ook prima te separeren, aparte realm per klant. Wachtwoorden kunnen daar eventueel ook in, mits je je wiki goed af schermt.

Qua password management vind ik zelf vim met gnupg plugin fijn, maar dat moet je ding zijn. Voordeel is dat je heel makkelijk iemans rechten kunt intrekken door diens GPG key te verwijderen uit de file. Voordeel en tegelijkertijd nadeel is dat het free format is, het is gewoon een textfile die prima doorzoekbaar is, maar die misschien wat minder mooi is dan keepass.

URL's:
- iTop CMDB - http://www.combodo.com/?lang=en
- iTop *is* 100% Open Source Software en volledig vrij te gebruiken, check wel de extentions page voor extra
functionaliteit. Alleen de ITSM designer kost geld. Waarschijnlijk heb je die niet nodig.
- iTop Extentions - https://wiki.openitop.org/doku.php?id=extensions:start
- DokuWiki - https://www.dokuwiki.org/dokuwiki#
- GnuPG Vim - http://www.vim.org/scripts/script.php?script_id=3645

[Will_M]

Heeft er hier iemand al wel eens ooit van IPAM gehoord?

[The Eagle]

Nope. En dit is zo te zien ook alleen handig in een MS oriented omgeving.
Having said that, als iemand me nog kant pointen naar een tool waarin ik IP reserveringen goed bij kan houden, houd ik me aanbevolen

[unezra]

The Eagle schreef op zaterdag 21 januari 2017 @ 19:51:
Nope. En dit is zo te zien ook alleen handig in een MS oriented omgeving.
Having said that, als iemand me nog kant pointen naar een tool waarin ik IP reserveringen goed bij kan houden, houd ik me aanbevolen

TeemIP
Zowel los te gebruiken als als onderdeel van iTop CMDB.
(Je kunt het niet *eerst* los gebruiken en later integreren met iTop.)

http://www.combodo.com/teemip-194

[Will_M]

De meeste tools zoals bijv. HP SIM kunnen dit soort dingen overigens wel regelen voor je én zijn te integreren in je huidige CMDB tooling.

Tooling kan inmiddels overweg met SMNB V3 en dus ook met apparaten welke alléén maar op die manier willen babbelen (NUTANIX devices, bijv.).

[ Voor 52% gewijzigd door Will_M op 21-01-2017 20:06 ]

[ik222]

The Eagle schreef op zaterdag 21 januari 2017 @ 19:51:
Nope. En dit is zo te zien ook alleen handig in een MS oriented omgeving.
Having said that, als iemand me nog kant pointen naar een tool waarin ik IP reserveringen goed bij kan houden, houd ik me aanbevolen

https://phpipam.net. Vooral handig dat je vrij makkelijk zelf een plugin kan maken zoals bijvoorbeeld ARP / ND based discovery. Als je dan je DNS goed op orde hebt dan heb je aan IP management al bijna geen omkijken meer. Bij ons komen Windows hosts er vanzelf in via AD, voor ons linux serverpark heb ik een simpele puppet module geschreven die zorgt dat automatisch de DNS records in de AD aangemaakt worden.

Sowieso is echte documentatie die je handmatig moet bijwerken kansloos en daardoor zinloos in mijn ervaring. Automatiseren (bijvoorbeeld met iets als puppet) en daarin geïntegreerde monitoring is het enige wat op de lange termijn werkt.

[Will_M]

ik222 schreef op zaterdag 21 januari 2017 @ 20:15:
[...]

https://phpipam.net. Vooral handig dat je vrij makkelijk zelf een plugin kan maken zoals bijvoorbeeld ARP / ND based discovery. Als je dan je DNS goed op orde hebt dan heb je aan IP management al bijna geen omkijken meer. Bij ons komen Windows hosts er vanzelf in via AD, voor ons linux serverpark heb ik een simpele puppet module geschreven die zorgt dat automatisch de DNS records in de AD aangemaakt worden.

Sowieso is echte documentatie die je handmatig moet bijwerken kansloos en daardoor zinloos in mijn ervaring. Automatiseren (bijvoorbeeld met iets als puppet) en daarin geïntegreerde monitoring is het enige wat op de lange termijn werkt.

Grrr.... Puppet is leuk, maar niet als je "@Random" een server moet kunnen uitrollen (en al helemaal niet als 't een MS Window Server moet zijn). Puppet is, IMHO, meer bedoeld om een server farm compliant te kunnen houden (óf krijgen) én om snel een uitbreiding te kunnen uitvoeren op zo'n farm.

[unezra]

ik222 schreef op zaterdag 21 januari 2017 @ 20:15:
[...]
Sowieso is echte documentatie die je handmatig moet bijwerken kansloos en daardoor zinloos in mijn ervaring. Automatiseren (bijvoorbeeld met iets als puppet) en daarin geïntegreerde monitoring is het enige wat op de lange termijn werkt.

Lijkt me wat kort door de bocht.

Hoe ga je bijvoorbeeld procedurebeschrijvingen automatisch documenteren, of wat de diepere gedachte is achter de opbouw van een systeem?

Ik snap dat een deel van je "documentatie" zit in geautomatiseerde processen, maar ik denk ook dat je niet zonder een goed documenatie systeem (bijjvoorbeeld een wiki) die je consequent bij houd kunt.

Plus een CMDB. Waarin ieder item zit.
(Dat kun je dan weer automatiseren, zowel CMDB -> Deployment systeem als andersom.)

[ik222]

wimmel_1 schreef op zaterdag 21 januari 2017 @ 20:24:
[...]


Grrr.... Puppet is leuk, maar niet als je "@Random" een server moet kunnen uitrollen (en al helemaal niet als 't een MS Window Server moet zijn). Puppet is, IMHO, meer bedoeld om een server farm compliant te kunnen houden (óf krijgen) én om snel een uitbreiding te kunnen uitvoeren op zo'n farm.

Ik ben zelf niet van de Windows systemen, werk enkel met unix en heb wat noodzakelijke intergratie voor die unix systemen met de AD gemaakt.

Maar in ons geval kun je met puppet bijvoorbeeld prima snel een basis uitrol doen, dan krijg je een basis linux server waarmee je verder nog steeds handmatig kan doen wat je wilt maar die wel automatisch de basis monitoring krijgt, die wel aan het standaard patch schedule hangt, waarvoor wel de IP adressen gereserveerd zijn, waarvoor wel DNS records zijn aangemaakt en die wel de basis hardened config voor zijn environment heeft. Dat bespaart een hoop ellende.

En voordat een server dan echt productie gaat draaien is het de bedoeling dat deze wel volledig in puppet staat op zo'n manier dat we hem in principe op elk moment kunnen weggooien en direct opnieuw kunnen uitrollen. Is dat in de praktijk al overal perfect gelukt? Nee, uiteraard zijn er losse servers waar handmatige stappen in een txt file in de SVN staan en waarbij het soms zelfs de vraag is of die txt file compleet is. Maar de belangrijke platformen zijn wel volledig puppetized volgens deze filosofie en daar kijken we ook of het werkt als we een server opnieuw moeten uitrollen.

unezra schreef op zaterdag 21 januari 2017 @ 20:34:
[...]


Lijkt me wat kort door de bocht.

Hoe ga je bijvoorbeeld procedurebeschrijvingen automatisch documenteren, of wat de diepere gedachte is achter de opbouw van een systeem?

Ik snap dat een deel van je "documentatie" zit in geautomatiseerde processen, maar ik denk ook dat je niet zonder een goed documenatie systeem (bijjvoorbeeld een wiki) die je consequent bij houd kunt.

Plus een CMDB. Waarin ieder item zit.
(Dat kun je dan weer automatiseren, zowel CMDB -> Deployment systeem als andersom.)

Natuurlijk heb ik het iets gechargeerd neergezet hierboven, ja wij hebben ook een wiki voor bepaalde procedures en knowledge base achtige zaken. Maar wat ik dus duidelijk wil maken is dat een heel groot deel te automatiseren is waardoor je nog erg weinig handmatige documentatie nodig hebt. En in een wat grotere omgeving gaat het ook echt alleen op die manier werken, daar ben ik van overtuigd.

[Will_M]

ik222 schreef op zaterdag 21 januari 2017 @ 21:07:
[...]

Ik ben zelf niet van de Windows systemen, werk enkel met unix en heb wat noodzakelijke intergratie voor die unix systemen met de AD gemaakt.

Maar in ons geval kun je met puppet bijvoorbeeld prima snel een basis uitrol doen, dan krijg je een basis linux server waarmee je verder nog steeds handmatig kan doen wat je wilt maar die wel automatisch de basis monitoring krijgt, die wel aan het standaard patch schedule hangt, waarvoor wel de IP adressen gereserveerd zijn, waarvoor wel DNS records zijn aangemaakt en die wel de basis hardened config voor zijn environment heeft. Dat bespaart een hoop ellende.

En voordat een server dan echt productie gaat draaien is het de bedoeling dat deze wel volledig in puppet staat op zo'n manier dat we hem in principe op elk moment kunnen weggooien en direct opnieuw kunnen uitrollen. Is dat in de praktijk al overal perfect gelukt? Nee, uiteraard zijn er losse servers waar handmatige stappen in een txt file in de SVN staan en waarbij het soms zelfs de vraag is of die txt file compleet is. Maar de belangrijke platformen zijn wel volledig puppetized volgens deze filosofie en daar kijken we ook of het werkt als we een server opnieuw moeten uitrollen.


[...]

Natuurlijk heb ik het iets gechargeerd neergezet hierboven, ja wij hebben ook een wiki voor bepaalde procedures en knowledge base achtige zaken. Maar wat ik dus duidelijk wil maken is dat een heel groot deel te automatiseren is waardoor je nog erg weinig handmatige documentatie nodig hebt. En in een wat grotere omgeving gaat het ook echt alleen op die manier werken, daar ben ik van overtuigd.

En met bovenstaande gaat 't vaak al meteen fout. Een server uitrollen met met een "basis" qua IP configuratie welke gecontroleerd wordt door bijv. .Puppet wil, voor mij, vaak al zeggen dat ik met route-tabellen moet gaan werken op zo'n server (doordat er meerdere NIC's in zitten en niet alles over ALLE nic's mag lopen qua verkeer).

Routes bepaal ik liever op een ROUTER.... Zo'n apparaat is daar per slot van rekening voor gemaakt

[ Voor 3% gewijzigd door Will_M op 21-01-2017 22:48 ]

[ik222]

wimmel_1 schreef op zaterdag 21 januari 2017 @ 22:39:
[...]


En met bovenstaande gaat 't vaak al meteen fout. Een server uitrollen met met een "basis" qua IP configuratie welke gecontroleerd wordt door bijv. .Puppet wil, voor mij, vaak al zeggen dat ik met route-tabellen moet gaan werken op zo'n server (doordat er meerdere NIC's in zitten en niet alles over ALLE nic's mag lopen qua verkeer).

Routes bepaal ik liever op een ROUTER.... Zo'n apparaat is daar per slot van rekening voor gemaakt

Ik begrijp echt totaal niet welke afslag je nu genomen hebt en welke link met routing je nu legt.

Puppet is een systeem waarmee je een server configuratie als code schrijft. Deze configureert dus enkel het IP adres (kan er 1 zijn, kunnen er meerdere zijn) voor de server wat je zelf in het manifest hebt opgenomen, voor een server hebben we dus een standaard template waarin je dat soort basis dingen (hostname, minimaal 1 IP interface en nog wat dingen) zelf moet invullen, anders rolt simpelweg je server niet uit.

Het stuk van de documentatie wat je met puppet zo makkelijk kan automatiseren is dat puppet dan zorgt dat dat IP adres ook in de IP adminstratie tool wordt opgenomen en dat er een DNS naam voor geregistreerd wordt bij de DNS servers. Ook meldt puppet het systeem aan bij de monitoring en ons systeem voor patch management. Op die manier kun je eigenlijk nooit "vergeten" servers krijgen waar niemand meer van weet.

En daarnaast is voor de volledig puppetized productie platforms de puppet code inclusief comments dus gelijk ook voor een heel groot deel de documentatie . Daarin zie ik namelijk de volledige server van voor naar achter omschreven.

[ Voor 7% gewijzigd door ik222 op 22-01-2017 08:25 ]

[CAPSLOCK2000]

Ik werk vooral veel met platte tekstfiles met een snufje markup, meestal markdown, pod of dokuwiki.
Wachtwoorden en andere gevoelige informatie wordt met PGP beschermd.
Voor IPAM hebben we een intern geschreven tool, thuis heb ik gewoon een tekstfile.

Een groot probleem is de documentatie vindbaar maken. Het gebeurt veel te vaak dat er prachtige documentatie wordt geschreven die niemand ooit leest. Vindbaar is misschien niet het juiste woord, je wil dat de juiste informatie gevonden wordt, of de lezer daar nu naar op zoek was of niet. IMHO werkt het het beste om de documentatie zo dicht bij mogelijk te houden. Als het even kan in de configuratiefile. Dat maakt ook de kans groter dat die documentatie ooit nog gemoderniseerd wordt.

Documentatie heb je het hardste nodig als er iets mis gaat. Daarom begin ik documentatie bij voorkeur met een paniek-sectie. Wat moet je weten als alles stuk is? Wie moet je bellen? Hoe doe je een harde reset? Waar hangt de sleutel? Dat soort info. Soms is het alleen een verwijzing: In geval van paniek zie document X.

Hoe meer je automatiseert hoe minder je hoeft te weten hoe minder documentatie er nodig is.
Ten tweede zorgt automatisering voor standaardisering. Hoe minder uitzonderingen hoe minder documentatie je nodig hebt. Daarmee heb ik mooi bruggetje naar Puppet waar ik ook nog een ei over kwijt wil.

Puppet is geen vervanging voor al je documentatie maar het helpt wel, onder andere om voornoemde redenen.

Ik zie Puppet juist wel als de manier om snel een "@random" server uit te rollen (al zou ik niet weten hoe het onder Windows zit). Puppet doet al het saaie standaardwerk terwijl ik kan nadenken over het echte werk. Een applicatie Puppetizen kost op korte termijn wel een beetje meer werk dan direct op de server werken maar op het totaal is dat eigenlijk verwaarloosbaar, als het goed is ben je veel meer tijd kwijt met nadenken over de werking van de applicatie. De volgende keer dat je zo'n applicatie nodig hebt heb je die investering al weer terugverdient.
Zelfs bij one-off applicaties vind ik het al snel de moeite waard omdat Puppet impliciet voor documentatie zorgt (yes, ik ben weer terug on topic!). Ik kan alle veranderingen aan een systeem bij elkaar zien door nara de Puppet-configuratie te kijken. Omdat die configuratie in versiebeheer zit weet ik ook wanneer en door wie een verandering is gedaan en met een beetje geluk waarom.

[Verwijderd]

Wij gebruiken IT Glue. Eerder vooral veel tekstdocumenten, configs etc. op een bepaalde plaats. Dit maakte het doorzoeken enorm onhandig.

IT Glue kun je enorm goed customizen, vindbaar maken van documentatie is daarmee echt heel makkelijk geworden.

Belangrijke functies zoals auditing, rechten zijn allemaal mogelijk.

We documenten vrij veel, eigenlijk vrijwel alles wat past onder deze kopjes:

[battler]

Verwijderd schreef op donderdag 2 februari 2017 @ 11:42:
Wij gebruiken IT Glue. Eerder vooral veel tekstdocumenten, configs etc. op een bepaalde plaats. Dit maakte het doorzoeken enorm onhandig.

IT Glue kun je enorm goed customizen, vindbaar maken van documentatie is daarmee echt heel makkelijk geworden.

Belangrijke functies zoals auditing, rechten zijn allemaal mogelijk.

We documenten vrij veel, eigenlijk vrijwel alles wat past onder deze kopjes:

[afbeelding]

Ziet er interessant uit, is er ook een export functie?

[Verwijderd]

battler schreef op donderdag 2 februari 2017 @ 12:08:
[...]


Ziet er interessant uit, is er ook een export functie?

Jup, kun je per klant regelen. Of alles in één keer. Je kunt ook je eigen klanten een aparte login geven voor hun eigen organisatie. En dan ook weer bijvoorbeeld bepaalde rechten regelen, zodat ze onder andere wachtwoorden niet kunnen uitlezen.

[Kavaa]

Verwijderd schreef op donderdag 2 februari 2017 @ 11:42:
Wij gebruiken IT Glue. Eerder vooral veel tekstdocumenten, configs etc. op een bepaalde plaats. Dit maakte het doorzoeken enorm onhandig.

IT Glue kun je enorm goed customizen, vindbaar maken van documentatie is daarmee echt heel makkelijk geworden.

Belangrijke functies zoals auditing, rechten zijn allemaal mogelijk.

We documenten vrij veel, eigenlijk vrijwel alles wat past onder deze kopjes:

[afbeelding]

Mooie tool, maar aardig aan de prijs. Zeker die instap prijs..

Wat is jullie ervaring daarmee?

[xmenno]

Eigenlijk is de manier om een low level design te maken waar alle tekeningen in staan maar ook waarom iets zo is. Met een goed LLD zou je de infra opnieuw moeten kunnen bouwen.
Als je een goed onderliggend design hebt dan verandert daar niet zo veel aan, behalve dat er misschien hosts bij komen maar daar pas je het design niet voor aan. Als de topologie verandert dan pas je het design aan.

Verder iets als phpipam voor (automatische) adres registratie/uitgifte.
Misschien een LibreNMS voor graphing, die ook kaartjes maakt op basis van CDP.
Config backup schedule met Rancid.
ELK stack voor logging.

[unezra]

xmenno schreef op maandag 6 februari 2017 @ 14:53:
Verder iets als phpipam voor (automatische) adres registratie/uitgifte.

Ik vind TeemIP fijner / beter dan phpipam, zowel los als geïntegreerd met iTop CMDB.

Misschien een LibreNMS voor graphing, die ook kaartjes maakt op basis van CDP.

Zabbix vind ik hier prettiger, maar ik ken LibreNMS niet goed genoeg dus wellicht dat het een prima tool is.

Config backup schedule met Rancid.

Rancid is *raar* maar leuk. Niet echt een "mooie" tool, wel verdomd functioneel en handig. Gebruiken we ook sinds kort.

ELK stack voor logging.

ELK las ik toevallig deze howto over:
http://www.tecmint.com/in...k-stack-on-centos-rhel-7/

Maar het feit dat Kibana een java applicatie gebruikt staat me tegen. Zijn daar alternatieven voor en zijn er alternatieven die niet alleen met een Linux agent (Filebeat) werken, maar wat universeler zijn? (Zodat je ook Windows machines, firewalls, netwerk componenten, etc, etc, etc, centraal kunt loggen en analyseren.)

Zoiets staat al lang op mijn verlanglijstje maar het is er tot dusver niet van gekomen. Idealiter heb ik dus wel 1 centraal log systeem voor alles dat we hier hebben draaien en niet een systeem per type device of per OS.

[xelnaha]

Voor mijn vakgebied: netwerken & datacentra gebruik ik veel verschillende zaken. Voor DCIM voornamelijk itracs, aangezien excel niet heel handig is voor paar duizend verbindingen + rack allocatie etc

http://www.commscope.com/...RACS-DCIM-Software-Suite/

Voor IPAM, of infoblox, maar wat ik heel veel heb gebruikt is:

ipplan

Iplan is al lange tijd niet meer onderhouden helaas, en tegenwoordig zijn er aardig wat alternatieven zoals bv solarwinds etc.

voor config management: rancid

en zo zijn er nog wel wat zaken

[The Eagle]

unezra schreef op maandag 6 februari 2017 @ 15:14:
[...]


Ik vind TeemIP fijner / beter dan phpipam, zowel los als geïntegreerd met iTop CMDB.


[...]


Zabbix vind ik hier prettiger, maar ik ken LibreNMS niet goed genoeg dus wellicht dat het een prima tool is.


[...]


Rancid is *raar* maar leuk. Niet echt een "mooie" tool, wel verdomd functioneel en handig. Gebruiken we ook sinds kort.

Zegt me niks maar klinkt handig. Ga ik in duiken

[...]


ELK las ik toevallig deze howto over:
http://www.tecmint.com/in...k-stack-on-centos-rhel-7/

Maar het feit dat Kibana een java applicatie gebruikt staat me tegen. Zijn daar alternatieven voor en zijn er alternatieven die niet alleen met een Linux agent (Filebeat) werken, maar wat universeler zijn? (Zodat je ook Windows machines, firewalls, netwerk componenten, etc, etc, etc, centraal kunt loggen en analyseren.)

Zoiets staat al lang op mijn verlanglijstje maar het is er tot dusver niet van gekomen. Idealiter heb ik dus wel 1 centraal log systeem voor alles dat we hier hebben draaien en niet een systeem per type device of per OS.

Zoals al eerder aangegeven, Splunk. Voor en nadeel tegelijk is dat je per volume betaalt. Dus kleine omgevingen relatief goedkoop. Maar gebouwd voor grote. Zitten bij ons een 6 a 7k VM's plus storage, network etc in
Tevens ideaal om firewall blocks te detecteren

[Verwijderd]

djkavaa schreef op donderdag 2 februari 2017 @ 19:20:
[...]


Mooie tool, maar aardig aan de prijs. Zeker die instap prijs..

Wat is jullie ervaring daarmee?

Mijn werkgever betaalt het gewoon. Ook voor stagiaires etc. Dat geld haal je er wel uit door niet oneindig info hoeven te zoeken in een gedeelde map bijvoorbeeld.

[unezra]

The Eagle schreef op maandag 6 februari 2017 @ 20:47:
[...]

Zegt me niks maar klinkt handig. Ga ik in duiken

:-)

[...]
Zoals al eerder aangegeven, Splunk. Voor en nadeel tegelijk is dat je per volume betaalt. Dus kleine omgevingen relatief goedkoop. Maar gebouwd voor grote. Zitten bij ons een 6 a 7k VM's plus storage, network etc in
Tevens ideaal om firewall blocks te detecteren

Iets dat niet 100% OSS is, is geen optie helaas.
Op dit moment is dat deels vanwege de kosten (iets met budgettaire beperkingen), maar ook omdat we dat hebben aangewend om te zeggen "OSS tenzij" en ik betwijfel of ik een goede case heb voor een betaalde logfile analyzer. Mijn uren zijn "gratis", licenties zijn dat niet.

[JackBol]

unezra schreef op dinsdag 7 februari 2017 @ 09:08:
[...]


:-)


[...]


Iets dat niet 100% OSS is, is geen optie helaas.
Op dit moment is dat deels vanwege de kosten (iets met budgettaire beperkingen), maar ook omdat we dat hebben aangewend om te zeggen "OSS tenzij" en

Zoals eerder aangegeven, kan je naar ELK kijken. Evt. Met Grafana ipv Kibana.

ik betwijfel of ik een goede case heb voor een betaalde logfile analyzer. Mijn uren zijn "gratis", licenties zijn dat niet.

Tenzij je enkel leeft van zuurstof kost jij gewoon geld. Maar zolang je dat mantra blijft herhalen krijg je nooit een case bij de budget houder. Ik ben zelf ook een OSS proponent, maar je moet bij ieder project een build-vs-buy decision maken. En als je jouw uren daarbij op 0 zet, fop je alleen jezelf.

[Zenix]

Graylog is ook goed alternatief voor ELK. Makkelijker om op te zetten.

[Firefly III]

-

[ Voor 99% gewijzigd door Firefly III op 21-10-2019 10:02 . Reden: Leeg ivm privacy ]

[Verwijderd]

JCE schreef op woensdag 8 februari 2017 @ 12:25:
Wat ik mis in heel veel genoemde oplossingen is het feit dat het zo makkelijk een rommeltje kan worden.

Natuurlijk kan je de meest uitgebreide tooling in de soep laten lopen, maar ik denk dat de volgende oplossingen nooit en te nimmer consistent en foutloos te krijgen zijn:

• Excel sheets
• Word docs (met of zonder "key-value pairs")
• Text documenten, password managers
• Wiki, confluence, jira, enz.

Deze tooling kan wel helpen, maar nooit het probleem oplossen. Tenzij je tevens de tool-politie in het leven roept (waarbij "tool" natuurlijk vervangbaar is voor jouw oplossing) die consequent en consistent al die documenten gaat zitten rechtbreien.

Voor de mensen die denken dat dedicated tooling te duur is, die moeten voor de gein eens met een stopwatch bij houden hoeveel tijd hun Excelsheetjes kosten. Zeker in grote teams, met veel mensen, beloof ik je alvast dat je binnen no-time met je hele afdeling kan gaan skiën van de tijd (DUS het geld) die dat kost

Daarom moet je Excel sheets, Word docs etc ook niet in je infrastructuur zetten. Gebruik de aangegeven tooling en stap af van je Office documenten.

Wij gebruiken om deze eigenlijk amper nog Word documenten. Deze zijn allemaal omgezet naar doorzoekbare tekst in ons systeem.

Veel genoemde oplossingen hebben ook import mogelijkheden om dit voor je te doen.

[unezra]

JackBol schreef op woensdag 8 februari 2017 @ 12:18:
[...]
Zoals eerder aangegeven, kan je naar ELK kijken. Evt. Met Grafana ipv Kibana.

ELK zit ik juist idd naar te kijken. Als Grafana geen Java is, klinkt dat zeker interessant.
Iets om verder te onderzoeken dus.

[...]
Tenzij je enkel leeft van zuurstof kost jij gewoon geld. Maar zolang je dat mantra blijft herhalen krijg je nooit een case bij de budget houder. Ik ben zelf ook een OSS proponent, maar je moet bij ieder project een build-vs-buy decision maken. En als je jouw uren daarbij op 0 zet, fop je alleen jezelf.

Ik zet mijn uren niet op 0, ik zeg alleen dat consensus is dat personele uren van eigen personeel "gratis" zijn.
Tuurlijk snap ik dat het zo niet werkt, maar zo rekent het management / de directie. Kortom, zij foppen zichzelf, ik maak me daar verder niet al te druk over.

Ach, zo ongunstig is het voor mij niet. Omdat mijn uren gratis zijn, krijg ik makkelijker iets voor elkaar als ik het zelf doe dan als ik het uitbesteed en laat ik nu net de afgelopen jaren naar mijn gevoel veel te veel hebben moeten uitbesteden. Daar krijg je geen gelukkiger techneut van, maar ook geen beter bedrijf.

Kortom, het is prima zo.

[Gravit0n]

battler schreef op donderdag 19 januari 2017 @ 14:20:
Hoe houden jullie de infrastructuurgegevens van jullie klanten bij? Er zijn meer dan genoeg tools voor het beheren van klantgegevens, offertes, projecten, planning etc.. Maar echt infrastructuurgegevens als IP-adressen, Gebruikersnamen en wachtwoorden, Topologytekeningen e.d Hoe doen jullie dat?

Ik zie vaak voorbij komen dat bedrijven dit in excel doen. En ik moet toegeven het is vrij gemakkelijk om alles daar in bij te houden maar op een gegeven moment loop je toch tegen limities aan. Wachtwoorden wil je er bijvoorbeeld niet in opslaan en topologytekeningen kan je er niet mee maken. Daarnaast vind ik het ook niet meest overzichtelijke manier om grotere netwerken in te documenteren maar dit laatste kan misschien met de templates te maken hebben.

Hoe doen jullie dit? Excel, zelf geschreven applicatie of is er een netwerkdocumentatieplatform dat iedereen stiekem gebruikt maar waar ik nog nooit van heb gehoord?

Een Wiki page per klant, veel moeilijker hoeft het niet te zijn.

[CAPSLOCK2000]

unezra schreef op maandag 6 februari 2017 @ 15:14:
ELK las ik toevallig deze howto over:
http://www.tecmint.com/in...k-stack-on-centos-rhel-7/

Maar het feit dat Kibana een java applicatie gebruikt staat me tegen. Zijn daar alternatieven voor en zijn er alternatieven die niet alleen met een Linux agent (Filebeat) werken, maar wat universeler zijn? (Zodat je ook Windows machines, firewalls, netwerk componenten, etc, etc, etc, centraal kunt loggen en analyseren.)

Zoiets staat al lang op mijn verlanglijstje maar het is er tot dusver niet van gekomen. Idealiter heb ik dus wel 1 centraal log systeem voor alles dat we hier hebben draaien en niet een systeem per type device of per OS.

ELK is erg gaaf.
Mag ik vragen wat het probleem met java is? (Ik wil geen java-flamewar maar wil concreet weten wat jouw bezwaar is, in deze hoek ontkom je haast niet aan java. Laat ik maar alvast bij zeggen dat het geheugen gebruik nogal fors is, maar ik vind de voordelen groot genoeg om dat te accepteren).

Verkijk je niet op die filebeat-plugin, dat is maar één manier om data naar ELK te sturen en zeker niet de beste, meer de laatste optie als je een andere mogelijkheden hebt. Als je applicatie bv json uitspuugt dan kun je dat direct insturen, zonder filebeat er tussen te zetten.

Zie hier de lijst met input-plugins (filebeat gebruikt het lumberjack protocol):
https://www.elastic.co/gu...urrent/input-plugins.html


Voor ik met ELK begon hadden we al een centrale syslog-server. De quick & dirty oplossing was filebeat installeren op de centrale logserver en het vanaf daar naar ELK doorsturen. Aan de bestaande apps hoeft niks verandert te worden.
De volgende stap (nog niet uitgevoerd) is dat we filebeat er uit halen en de logs direct van syslog naar ELK sturen, zonder ze eerst naar een file te sturen want daarbij verlies je toch weer wat informatie. Modernere versies van syslog kunnen dat maar die heb nog niet op die ene server.
Daarnaast probeer ik applicaties waar mogelijk direct hun data naar ELK te laten sturen zonder langs de centrale syslogserver te gaan, zodat er nog minder informatie verloren gaat.

[ Voor 3% gewijzigd door CAPSLOCK2000 op 08-02-2017 14:15 ]

[Acmosa]

Om data van Windows machines in ELK te krijgen gebruik ik nxlog.
Mocht je nog vragen hebben over ELK dan kan ik je daar misschien ook nog wel mee helpen.
Wij gebruiken nu een ELK stack, ossec, zabbix en grafana voor het dashboard van alles.
Documenteren gebeurt vooral in Visio, excel, KeePass en een wiki.
Maar ik ga zeker kijken naar iTop.

[Yalopa]

Sharepoint site per klant, daar word, excel en visio bestanden op. Wachtwoorden worden daar natuurlijk niet bewaard.

Documenteren voordat je iets doet zorgt er voor dat je nadenkt over wat je gaat doen. Automatische documentatie generatoren zijn leuk, maar dan hoop ik maar dat alle changes via templates en approval workflows doorgevoerd worden, anders heb je direct een rommeltje....

[Kavaa]

Zijn er hier nog users die Self Hosted tools gebruiken die in de buurt komen van IT Glue.
We hebben niet per definitie iets tegen Hosted... Maar het is altijd weer de vraag wie er bij de data van je klanten kan enz. Zeker als je er wachtwoorden etc. in gaat zetten met remote adressen.

Loop al een hele tijd te zoeken en dingen te proberen maar het is het allemaal net niet.

Ook zoeken we naar iets met een goede export functie naar meerdere styles zodat we in een keer een document hebben met evt. alle gegevens van de klant of juist een deel hiervan.

Confluence "Self Hosted" komt aardig in de buurt. Nadeel daarmee is weer, je klant kan er zelf niet op inloggen. Ofja het kan wel... Maar dan betaal je er ook voor. En de pricing is nogal hoog.

Dan kun je wel zeggen ja een klant logt niet zo vaak in true, maar om de optie te hebben is wel nice.

Wellicht dat iemand nog een lijstje heeft van wat hij/zij kent of gebruikt of wel eens gezien heeft?

[init6]

Kavaa schreef op zondag 18 maart 2018 @ 19:18:
Zijn er hier nog users die Self Hosted tools gebruiken die in de buurt komen van IT Glue.
We hebben niet per definitie iets tegen Hosted... Maar het is altijd weer de vraag wie er bij de data van je klanten kan enz. Zeker als je er wachtwoorden etc. in gaat zetten met remote adressen.

Loop al een hele tijd te zoeken en dingen te proberen maar het is het allemaal net niet.

Ook zoeken we naar iets met een goede export functie naar meerdere styles zodat we in een keer een document hebben met evt. alle gegevens van de klant of juist een deel hiervan.

Confluence "Self Hosted" komt aardig in de buurt. Nadeel daarmee is weer, je klant kan er zelf niet op inloggen. Ofja het kan wel... Maar dan betaal je er ook voor. En de pricing is nogal hoog.

Dan kun je wel zeggen ja een klant logt niet zo vaak in true, maar om de optie te hebben is wel nice.

Wellicht dat iemand nog een lijstje heeft van wat hij/zij kent of gebruikt of wel eens gezien heeft?

Documenteren:
Confluence
Gitlab
Subtrac
Github
Readthedocs

Single point of truth:
Collins
Cobbler
Foreman
Ipplan
Patchmanager

Secret management:
Hashicorp Vault
Ansible Vault
Keepass
Lastpass

Log tools:
ELK stack (ipv logstash filebeat)
Splunk

Monitoring:
Smokeping
Prometheus
Icinga
Ganglia
Zabbix

Automatisering tools/ infrastructure as code:
Terraform
Ansible
Chef
Cfengine3
Puppet
Salt
(R)ex
Synctool

Om maar wat tooltjes te noemen

[Kavaa]

init6 schreef op zondag 25 maart 2018 @ 21:39:
[...]


Documenteren:
Confluence
Gitlab
Subtrac
Github
Readthedocs

Single point of truth:
Collins
Cobbler
Foreman
Ipplan
Patchmanager

Secret management:
Hashicorp Vault
Ansible Vault
Keepass
Lastpass

Log tools:
ELK stack (ipv logstash filebeat)
Splunk

Monitoring:
Smokeping
Prometheus
Icinga
Ganglia
Zabbix

Automatisering tools/ infrastructure as code:
Terraform
Ansible
Chef
Cfengine3
Puppet
Salt
(R)ex
Synctool

Om maar wat tooltjes te noemen

Mooi lijstje om weer eens wat dingen te testen