Re: Clients identiek houden
Op 12-03-15 om 09:23 schreef Jan-Rens Reitsma: > On 01/09/2015 12:25 PM, Paul van der Vlis wrote: >> Hoi allen, >> >> Ik beheer een aantal clients die eigenlijk identiek zijn, op een paar >> uitzonderingen na zoals de hostname. Ik heb een backup van zo'n client >> op de server. > > Dat doet me denken aan computerzalen op scholen en in bibliotheken. Het gaat hier om een bedrijf. > > >> Ook iets als Puppet is een optie, maar dat lijkt me veel werk om goed >> aan de praat te krijgen. Ik gebruik nu een eigen script, wat een ander >> script download en uitvoert. > > Bieden www.thinstation.org of Debian Edu / Skolelinux Wheezy (met > netinstall en rsync) geen betere oplossingen dan Puppet? Het zijn drie heel verschillende oplossingen. Met ThinStation heb ik jarenlange ervaring in combinatie met FreeNX. Later ben ik X2go gaan gebruiken. Thin clients zijn mooi, maar tegenwoordig wil men ook graag YouTube en andere bewegende beelden kunnen weergeven. Dat ging niet zo goed, in elk geval niet full-screen. Het beeld stottert en de serverbelasting is hoog. Ook lokale devices zijn vaak wat lastig bij thin-clients. SkoleLinux is ook een thin-client oplossing, maar ik geloof dat er tegenwoordig ook een fat-clients zijn. Dat vind ik een goed idee en zou ik weleens willen zien. Ik denk dat applicaties wel wat traag starten, vooral als een hele klas dat doet. Alles moet over het netwerk. Puppet is een veelgebruikt beheertool om van alles te doen op vele clients. Ik heb er geen ervaring mee. Mijn rync oplossing is weer anders, en werkt goed. Maar er zitten nog wel wat ruwe randjes aan, zo wordt bijvoorbeeld de default printer overschreven en moet de resolutie van de monitor na een sync worden aangepast. Groet, Paul. -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55015792.8010...@vandervlis.nl
Re: Clients identiek houden
On 01/09/2015 12:25 PM, Paul van der Vlis wrote: Hoi allen, Ik beheer een aantal clients die eigenlijk identiek zijn, op een paar uitzonderingen na zoals de hostname. Ik heb een backup van zo'n client op de server. Dat doet me denken aan computerzalen op scholen en in bibliotheken. Ook iets als Puppet is een optie, maar dat lijkt me veel werk om goed aan de praat te krijgen. Ik gebruik nu een eigen script, wat een ander script download en uitvoert. Bieden www.thinstation.org of Debian Edu / Skolelinux Wheezy (met netinstall en rsync) geen betere oplossingen dan Puppet? Zie: https://www.debian.org/News/2013/20130928 Mvg, Jan-Rens. -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55014cf6.6090...@gmail.com
Re: Clients identiek houden
On 03/08/2015 10:08 AM, Paul van der Vlis wrote: Op 07-03-15 om 10:17 schreef Jan-Rens Reitsma: On 03/03/2015 02:25 PM, Paul van der Vlis wrote: Een punt is wel dat het UUID van het filesysteem en de swap correct moeten zijn, want dat wordt via rsync niet meegekopieerd. Een alternatief is eventueel in /etc/fstab en /boot/grub/grub.conf een devicenaam te gebruiken in plaats van het UUID. Het lastige van een filesysteem UUID is dat je het alleen kunt aanpassen als dat filessysteem niet gemount is, Misschien kun je dit soort problemen met UUID's oplossen door HDD's te verwijderen en door USB-sticks te vervangen. Onlangs heb ik (bij wijze van experiment) Debian mbv netinstall geinstalleerd op een USB-stick in een oude laptop waar ik de wifi-kaart en de HDD uitgesloopt had. Debian startte van USB-stick verbluffend snel op en werkte zo te zien prima. Als ik me niet vergis krijgt een filesysteem op een USB-stick geen UUID omdat een USB-stick een removable medium is. Volgens mij vergis je je. En als er geen UUID's zouden zijn, dan moet je toch iets ervoor in de plaats gebruiken, dus weer device-namen (of labels). Je hebt gelijk, ik had de USB-stick nog liggen en ik zag in de fstab de UUID's voor twee partities staan. De partities op de USB-stick worden bij een standaard installatie aan /dev/sda device files gelinkt. De installer heeft ook een swap-partitie op de USB-stick aangemaakt. Daar had ik niet aan gedacht. :-( Verder zijn de meeste USB sticks een stuk trager dan de SSD's die nu gebruikt worden. Daar twijfel ik niet aan maar USB-sticks lijken tijdens het opstarten veel sneller te zijn dan oude HDD's. Je zou de USB-sticks read only kunnen maken en na inloggen zou je een NFS kunnen mounten. Ze zijn voor de gebruiker zowiezo read-only (behalve de tmp-dirs), en verder read-only maken maakt het doen van security updates onmogelijk. Ik bedoelde ro voor users, niet voor het updaten door root. Ik las overigens dat Google ook rsync gebruikt voor het updaten. Ze hebben het zelfs gebruikt om hun productieservers te upgraden van Redhat naar Debian-based. Dat wist ik nog niet, dat Google Debian gebruikt op hun servers. Zie: https://www.usenix.org/conference/lisa13/technical-sessions/presentation/merlin Interessant! Zou Red Hat het omgekeerde proces ook kunnen laten zien? Ik zie rsync ondertussen niet alleen als alternatief voor Puppet (wat ik overigens niet goed ken), maar ook als alternatief voor security updates via apt. Zelf had ik het (nutteloze?) idee voor een speciale configuratie voor de Debian installer waarmee Debian op een laptop (of PC) met een (micro-)USB-stick en een grote HDD (2 of 3 TB) geïnstalleerd kan worden. Daarmee zouden de statische / /boot /bin /sbin /lib ... etc op de USB-stick geplaatst kunnen worden en de dynamische /var /home /tmp ... etc op de HDD, zonder dat een gebruiker met de hand de parameters voor een optimale configuratie hoeft in te stellen. Groet, Paul. Mvg, Jan-Rens. -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54fdba01.6050...@gmail.com
Re: Clients identiek houden
Op 07-03-15 om 10:17 schreef Jan-Rens Reitsma: > On 03/03/2015 02:25 PM, Paul van der Vlis wrote: >> Een punt is wel dat het UUID van het filesysteem en de swap correct >> moeten zijn, want dat wordt via rsync niet meegekopieerd. Een >> alternatief is eventueel in /etc/fstab en /boot/grub/grub.conf een >> devicenaam te gebruiken in plaats van het UUID. >> Het lastige van een filesysteem UUID is dat je het alleen kunt aanpassen >> als dat filessysteem niet gemount is, > > Misschien kun je dit soort problemen met UUID's oplossen door HDD's te > verwijderen en door USB-sticks te vervangen. Onlangs heb ik (bij wijze > van experiment) Debian mbv netinstall geinstalleerd op een USB-stick in > een oude laptop waar ik de wifi-kaart en de HDD uitgesloopt had. Debian > startte van USB-stick verbluffend snel op en werkte zo te zien prima. > > Als ik me niet vergis krijgt een filesysteem op een USB-stick geen UUID > omdat een USB-stick een removable medium is. Volgens mij vergis je je. En als er geen UUID's zouden zijn, dan moet je toch iets ervoor in de plaats gebruiken, dus weer device-namen (of labels). Verder zijn de meeste USB sticks een stuk trager dan de SSD's die nu gebruikt worden. > Je zou de USB-sticks read > only kunnen maken en na inloggen zou je een NFS kunnen mounten. Ze zijn voor de gebruiker zowiezo read-only (behalve de tmp-dirs), en verder read-only maken maakt het doen van security updates onmogelijk. Ik las overigens dat Google ook rsync gebruikt voor het updaten. Ze hebben het zelfs gebruikt om hun productieservers te upgraden van Redhat naar Debian-based. Dat wist ik nog niet, dat Google Debian gebruikt op hun servers. Zie: https://www.usenix.org/conference/lisa13/technical-sessions/presentation/merlin Ik zie rsync ondertussen niet alleen als alternatief voor Puppet (wat ik overigens niet goed ken), maar ook als alternatief voor security updates via apt. Groet, Paul. -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54fc1177.8050...@vandervlis.nl
Re: Clients identiek houden
On 03/03/2015 02:25 PM, Paul van der Vlis wrote: Hoi, Hallo Paul, Een punt is wel dat het UUID van het filesysteem en de swap correct moeten zijn, want dat wordt via rsync niet meegekopieerd. Een alternatief is eventueel in /etc/fstab en /boot/grub/grub.conf een devicenaam te gebruiken in plaats van het UUID. Het lastige van een filesysteem UUID is dat je het alleen kunt aanpassen als dat filessysteem niet gemount is, Misschien kun je dit soort problemen met UUID's oplossen door HDD's te verwijderen en door USB-sticks te vervangen. Onlangs heb ik (bij wijze van experiment) Debian mbv netinstall geinstalleerd op een USB-stick in een oude laptop waar ik de wifi-kaart en de HDD uitgesloopt had. Debian startte van USB-stick verbluffend snel op en werkte zo te zien prima. Als ik me niet vergis krijgt een filesysteem op een USB-stick geen UUID omdat een USB-stick een removable medium is. Je zou de USB-sticks read only kunnen maken en na inloggen zou je een NFS kunnen mounten. Met vriendelijke groet, Jan-Rens. -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54fac226.8020...@gmail.com
Re: Clients identiek houden
Op 03-03-15 om 19:47 schreef Paul van der Vlis: > Op 03-03-15 om 14:25 schreef Paul van der Vlis: > >> Een punt is wel dat het UUID van het filesysteem en de swap correct >> moeten zijn, want dat wordt via rsync niet meegekopieerd. Een >> alternatief is eventueel in /etc/fstab en /boot/grub/grub.conf een >> devicenaam te gebruiken in plaats van het UUID. >> Het lastige van een filesysteem UUID is dat je het alleen kunt aanpassen >> als dat filessysteem niet gemount is, > > Ik ben erachter gekomen dat "update-grub" het UUID uit de partitie haalt > en aanpast in /boot/grub/grub.cfg. Dat wist ik nog niet. > > Uiteraard wijzigt dit niet het UUID in /etc/fstab, daar moet het ook nog > gewijzigd. Ik denk dat ik daar een device naam ga gebruiken. Het werkt nu helemaal goed volgens mij. In fstab gebruik ik nu een device naam in plaats van een UUID. Het UUID in grub wordt automatisch aangepast aan het UUID van de partitie in de machine, dat hoeft nu niet meer hetzelfde te zijn dus. Nieuwe scripts staan hier: https://vandervlis.nl/files/backup-client8 https://vandervlis.nl/files/sync-client8 Groet, Paul. -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f6d903.1040...@vandervlis.nl
Re: Clients identiek houden
Op 03-03-15 om 14:25 schreef Paul van der Vlis: > Een punt is wel dat het UUID van het filesysteem en de swap correct > moeten zijn, want dat wordt via rsync niet meegekopieerd. Een > alternatief is eventueel in /etc/fstab en /boot/grub/grub.conf een > devicenaam te gebruiken in plaats van het UUID. > Het lastige van een filesysteem UUID is dat je het alleen kunt aanpassen > als dat filessysteem niet gemount is, Ik ben erachter gekomen dat "update-grub" het UUID uit de partitie haalt en aanpast in /boot/grub/grub.cfg. Dat wist ik nog niet. Uiteraard wijzigt dit niet het UUID in /etc/fstab, daar moet het ook nog gewijzigd. Ik denk dat ik daar een device naam ga gebruiken. ( Uiteraard kan ik op die naam ook zoek en vervang doen met een UUID, waarschijnlijk is er ook ergens al een scriptje wat zoiets kan. ) Overigens weet ik niet of het mogelijk is om update-grub te draaien na het rsyncen. Groet, Paul. -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f601b8.4020...@vandervlis.nl
Re: Clients identiek houden
Hoi, Op 09-01-15 om 12:25 schreef Paul van der Vlis: > Hoi allen, > > Ik beheer een aantal clients die eigenlijk identiek zijn, op een paar > uitzonderingen na zoals de hostname. Ik heb een backup van zo'n client > op de server. > > Om een client te installeren boot ik met een live-cd, partitioneer, > formatteer, download de data uit de backup, en installeer grub. Wellicht > kan dit handiger, maar dit werkt. > > Nu zit ik me af te vragen of zoiets ook later zou kunnen, dus om de > machines identiek te houden. Bijvoorbeeld vanaf de server iets van: > rsync -a --exclude=... --del /client pc01:/ > > Het lijkt me eigenlijk moeten kunnen, alleen komt die --exclude > natuurlijk wel vrij precies. en zijn er wellicht nog meer punten (zoals > de netwerk interfaces in udev, en het UUID van het filesystem moet > identiek zijn). Ik heb dit nu getest voor een upgrade van Debian7 naar Debian8 en het lukt redelijk. Het syncen zelf geeft geen problemen. Een punt is wel dat het UUID van het filesysteem en de swap correct moeten zijn, want dat wordt via rsync niet meegekopieerd. Een alternatief is eventueel in /etc/fstab en /boot/grub/grub.conf een devicenaam te gebruiken in plaats van het UUID. Het lastige van een filesysteem UUID is dat je het alleen kunt aanpassen als dat filessysteem niet gemount is, Verder is het me nog niet gelukt om na het sysncen het systeem netjes uit te zetten met "poweroff" of iets dergelijks, wellicht komt dat omdat init.d veranderd is in systemd. Op het moment wordt het systeem hard uitgezet, niet helemaal netjes. Wat als laatste nog een probleem is, is dat grub welliswaar vervangen is op het filesysteem, maar niet in het MBR, daarom krijg je een Grub rescue prompt. Als ik echter boot met een livecd dan is dit eenvoudig te herstellen door te chrooten en een "grub-install --recheck /dev/sda1" uit te voeren. Wellicht kan dit nog in het sync-script worden opgenomen. Dit lijkt me ook heel geschikt om een client later te updaten, zodat de systemen weer echt gelijk zijn. Hieronder heb ik de scripts neergezet, er is vast het een en ander wat nog beter kan. Kritiek en aanvullingen zijn welkom. Groet, Paul. - #!/bin/bash # p...@vandervlis.nl # script om client naar de server te kopieren # start echo -e "\n`date +%T` Start backup" # ask machine when not on commandline: if test "$1" = ""; then read -p "Machine naam (voorbeeld: mm-n001): " machine else machine=$1 fi if test "$machine" = ""; then echo no machine. exit fi # Local DIR voor backup LDIR="/backup/client8" # Wat niet gebackupped hoeft te worden EXCLUDE="\ --exclude=/mnt/** \ --exclude=/backup/** \ --exclude=/proc/** \ --exclude=/tmp/** \ --exclude=/lost+found \ --exclude=/sys/** \ --exclude=/var/cache/apt/archives/** \ --exclude=/home/** \ --exclude=/data/** \ " #syncen naar remote echo -e "\n`date +%T` Syncen naar backup-server:" if ! test -e $LDIR; then mkdir -p $LDIR; chmod 700 $LDIR; fi cd $LDIR nice rsync -axzve ssh --numeric-ids --del --delete-excluded $EXCLUDE \ $machine:/ ./ # verwijderen udev bestanden: rm $LDIR/etc/udev/rules.d/70-persistent-net.rules rm $LDIR/etc/krb5.keytab # klaar echo -e "\n`date +%T` Backup klaar." -- - #!/bin/bash # p...@vandervlis.nl # script om client vanaf de server te updaten # start echo -e "\n`date +%T` Start sync" # ask machine when not on commandline: if test "$1" = ""; then read -p "Machine naam (voorbeeld: mm-n001): " machine else machine=$1 fi if test "$machine" = ""; then echo no machine. exit fi # Local DIR LDIR="/backup/client8" # Wat niet gebackupped hoeft te worden EXCLUDE="\ --exclude=/mnt/** \ --exclude=/proc/** \ --exclude=/tmp/** \ --exclude=/lost+found \ --exclude=/sys/** \ --exclude=/var/cache/apt/archives/** \ --exclude=/var/log/** \ --exclude=/home/** \ --exclude=/data/** \ --exclude=/etc/hostname \ --exclude=/etc/krb5.keytab \ --exclude=/etc/udev/rules.d/** \ --exclude=/etc/ssh/ssh_host_* \ " #syncen naar remote echo -e "\n`date +%T` Syncen naar client:" cd $LDIR nice rsync -axzve ssh --numeric-ids --del $EXCLUDE \ ./ $machine:/ # klaar echo -e "\n`date +%T` Backup klaar." --- # wijzigen UUID, zoiets: tune2fs -U ad118d5d-456b-4fbe-b902-f8c9bd87afeb /dev/sda1 swapoff /dev/sda5 mkswap -U dfae00aa-23d7-4d56-8226-e7ebc5cf8f4a /dev/sda5 -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f5b663.8040...@vandervlis.nl
Re: Clients identiek houden
On Mon, Jan 12, 2015 at 02:45:50AM +0100, Steven Post wrote: > > > > http://en.wikipedia.org/wiki/Ansible_%28software%29 > > > > > [...] > > Mijn persoonlijke voorkeur blijft toch Puppet, daar heb ik meer ervaring > mee dan met Ansible, dat gebruik ik sinds kort voor een ander project > (niet mijn keuze). Dat het zonder agent werkt kan inderdaad een > voordeel zijn, maar bij de verschillende Puppet modules versus alles > in de Ansible core is het toch omgekeerd lijkt me. > > Dat gezegd zijnde wil ik nog even meegeven dat als je grote directory > trees gaat syncen met Ansible je best kijk naar de 'synchronize' > module, niet de 'copy' module (zeg ik dat goed? modules?). Ja, dat is juist, het zijn modules ( http://docs.ansible.com/modules_by_category.html ) En er wordt meteen gezeg dat 'alles in de core' niet waar is. 8^) [...] > Als je net met configuration management begint kan ik nog wel de 101 > aanraden, deze is op [1] te vinden. Dat was een sessie op FOSDEM 2014. > > Mvg, Steven > > [1] http://video.fosdem.org/2014/H1309_Van_Rijn/Saturday/ Hey, daar staan nog andere lezing in webm formaat. Dank! Groeten Geert Stappers -- Leven en laten leven -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150122113708.ge23...@gpm.stappers.nl
Re: Clients identiek houden
Op 13-01-15 om 11:06 schreef Germ van Ek | Esyst: > Ik heb de historie van deze thread niet meer, gisteren al wel gelezen, > maar je originele vraag is mij dus niet helemaal helder. > > Als je losse clients (terminals) hebt die identiek moeten blijven op > wellicht een hostname oid na, dan is een image of rsync prima, met --delete. Voor een image moet de machine uit, lijkt me. Ik wou dat rsyncen in lopende bedrijf doen, eventueel tijdens het aan- of uitzetten van de machine. Dat het geschikt is voor nieuwe installaties weet ik wel, maar wat ik niet zo goed weet is of het geschikt is om machines identiek te houden. Uiteraard snap ik dat lopende programma's problemen kunnen geven als ze worden geupdated, en dat daarom soms een herstart van het programma nodig is. Ik zie dat onder Debian vaak bij een upgrade van de browser of de e-mail client. Wat ik mis zijn meldingen aan de user dat een programma moet worden herstart. Ik heb daar ook bugs voor ingediend bij een aantal programma's, maar in feite is het iets wat voor elk lopend programma van toepassing is. En voor libraries is dat vast ook het geval. > Bij ons is het aantal servers sterk aan het groeien, en ben ik er met > configuratie management naartoe aan het werken dat ik via PXE + Puppet > snel een server kan vervangen of toevoegen, maar dat is een iets ander > gebruik. Uiteraard snap ik dat er met iets als Puppet andere dingen mogelijk zijn, omdat machines daar kunnen verschillen. Maar zie je ook voordelen voor Puppet als de machines identiek zijn? > Ik zou je bijna wel aanraden om in ieder geval versiebeheer, GIT of iets > dergelijks, te gaan gebruiken. Vroeg of laat gaat je dat helpen om > historie terug te kunnen zien of een foute aanpassing terug te draaien. Daar heb je helemaal gelijk aan. Zelf gebruik ik al erg lang backups met hardlinks, waarmee ik een oude versie snel kan terugbrengen. Zo exact als GIT is het echter niet, het is meer een snapshot, terwijl GIT meer patchbeheer is. Vooral bij veel wijzigingen is GIT daarom beter. Ik zit er wel eens aan te denken, maar je moet het ook in en uit GIT krijgen. Groet, Paul. > Met vriendelijke groeten, > > Germ van Ek > Esyst BV > > > > *Van: *"Paul van der Vlis" > *Aan: *debian-user-dutch@lists.debian.org > *Verzonden: *Maandag 12 januari 2015 19:54:17 > *Onderwerp: *Re: Clients identiek houden > > Hallo, > > Bedankt voor de antwoorden. Ik zie het, jullie raden me een config > management systeem aan. > > Maar waar ik eigenlijk vooral nieuwsgierig naar ben is waarom rsyncen > van zo'n client geen goed idee is. Het lijkt me zo'n simpele en voor de > hand liggende oplossing dat ik vast niet de eerste ben die er op is > gekomen. > > Het nadeel van een config management systeem lijkt me dat je alleen > dingen wijzigt en de rest laat staan. Het lijkt me dat er in de loop der > tijd toch wat verschillen ontstaan tussen de systemen, omdat er iemand > vergeet iets op te ruimen e.d. > > Bij rsync doe je het omgekeerde, je maakt alles helemaal gelijk, met een > paar uitzonderingen. Dat lijkt me in principe beter (maar niet overal > bruikbaar). > > Dus nog een keer de vraag: waarom is het geen goed idee om een client te > beheren door middel van een rsync? > > Met vriendelijke groet, > Paul van der Vlis. > > > -- > Paul van der Vlis Linux systeembeheer, Groningen > http://www.vandervlis.nl > > > -- > To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/54b41859.8010...@vandervlis.nl > > -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b5025b.4080...@vandervlis.nl
Re: Clients identiek houden
Ik heb de historie van deze thread niet meer, gisteren al wel gelezen, maar je originele vraag is mij dus niet helemaal helder. Als je losse clients (terminals) hebt die identiek moeten blijven op wellicht een hostname oid na, dan is een image of rsync prima, met --delete. Bij ons is het aantal servers sterk aan het groeien, en ben ik er met configuratie management naartoe aan het werken dat ik via PXE + Puppet snel een server kan vervangen of toevoegen, maar dat is een iets ander gebruik. Ik zou je bijna wel aanraden om in ieder geval versiebeheer, GIT of iets dergelijks, te gaan gebruiken. Vroeg of laat gaat je dat helpen om historie terug te kunnen zien of een foute aanpassing terug te draaien. Met vriendelijke groeten, Germ van Ek Esyst BV - Oorspronkelijk bericht - > Van: "Paul van der Vlis" > Aan: debian-user-dutch@lists.debian.org > Verzonden: Maandag 12 januari 2015 19:54:17 > Onderwerp: Re: Clients identiek houden > Hallo, > Bedankt voor de antwoorden. Ik zie het, jullie raden me een config > management systeem aan. > Maar waar ik eigenlijk vooral nieuwsgierig naar ben is waarom rsyncen > van zo'n client geen goed idee is. Het lijkt me zo'n simpele en voor de > hand liggende oplossing dat ik vast niet de eerste ben die er op is gekomen. > Het nadeel van een config management systeem lijkt me dat je alleen > dingen wijzigt en de rest laat staan. Het lijkt me dat er in de loop der > tijd toch wat verschillen ontstaan tussen de systemen, omdat er iemand > vergeet iets op te ruimen e.d. > Bij rsync doe je het omgekeerde, je maakt alles helemaal gelijk, met een > paar uitzonderingen. Dat lijkt me in principe beter (maar niet overal > bruikbaar). > Dus nog een keer de vraag: waarom is het geen goed idee om een client te > beheren door middel van een rsync? > Met vriendelijke groet, > Paul van der Vlis. > -- > Paul van der Vlis Linux systeembeheer, Groningen > http://www.vandervlis.nl > -- > To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/54b41859.8010...@vandervlis.nl
Re: Clients identiek houden
Hallo, Bedankt voor de antwoorden. Ik zie het, jullie raden me een config management systeem aan. Maar waar ik eigenlijk vooral nieuwsgierig naar ben is waarom rsyncen van zo'n client geen goed idee is. Het lijkt me zo'n simpele en voor de hand liggende oplossing dat ik vast niet de eerste ben die er op is gekomen. Het nadeel van een config management systeem lijkt me dat je alleen dingen wijzigt en de rest laat staan. Het lijkt me dat er in de loop der tijd toch wat verschillen ontstaan tussen de systemen, omdat er iemand vergeet iets op te ruimen e.d. Bij rsync doe je het omgekeerde, je maakt alles helemaal gelijk, met een paar uitzonderingen. Dat lijkt me in principe beter (maar niet overal bruikbaar). Dus nog een keer de vraag: waarom is het geen goed idee om een client te beheren door middel van een rsync? Met vriendelijke groet, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b41859.8010...@vandervlis.nl
Re: Clients identiek houden
On Sun, 2015-01-11 at 19:58 +0100, Geert Stappers wrote: [...] > > Nog een tip: Ansible > > Ansible is ook orchestration zo als Puppet en Chef. > > Grootste pluspunt van Ansible is dat het "agentless" is. > Ansible maakt gebruikt van SSH en Python. > Dus geen gekloot met eerst agent software op de clients te leggen. > Ook geen gedoe met "certificates". > > Andere goede ontwerpkeuze van Ansible is dat volgorde in de "playbooks" > aangehouden wordt. Bij Puppet wordt de volgorde van "afspelen" door > de Puppetagent naar eigen goed dunken bepaalt ... > > > En mocht je nog nooit eerder van Ansible gehoord / gelezen hebben, > dat kan kloppen, het bestaat nog net geen drie jaar. > > http://en.wikipedia.org/wiki/Ansible_%28software%29 > > [...] Mijn persoonlijke voorkeur blijft toch Puppet, daar heb ik meer ervaring mee dan met Ansible, dat gebruik ik sinds kort voor een ander project (niet mijn keuze). Dat het zonder agent werkt kan inderdaad een voordeel zijn, maar bij de verschillende Puppet modules versus alles in de Ansible core is het toch omgekeerd lijkt me. Dat gezegd zijnde wil ik nog even meegeven dat als je grote directory trees gaat syncen met Ansible je best kijk naar de 'synchronize' module, niet de 'copy' module (zeg ik dat goed? modules?). Ik heb die fout ook even gemaakt, maar dan merk je meteen dat copy enorm traag is voor dat soort dingen. Synchronize is een wrapper rond rsync. Wat me wel enigzis stoorde bij Ansible (grotendeels user error) is dat er bij elke catalog run een 'change' stond genoteerd, doordat enkele resources 2 conflicteren waarden kregen, in dit geval file permissions. Dat is iets wat ik in Puppet nooit voorheb (tenzij je met 'exec' begint te spelen), met uitzondering van het managen van files/directories op een NAS volume (altijd bij opletten). Het belangrijkste is echter niet welke tool je kiest voor configuration management, wel dat je er een kiest. Als je net met configuration management begint kan ik nog wel de 101 aanraden, deze is op [1] te vinden. Dat was een sessie op FOSDEM 2014. Mvg, Steven [1] http://video.fosdem.org/2014/H1309_Van_Rijn/Saturday/ signature.asc Description: This is a digitally signed message part
Re: Clients identiek houden
On Sat, Jan 10, 2015 at 12:33:18PM +0100, Steven Post wrote: > Dag Paul, > > Disclaimer: ik werk als ICT system engineer en sta mee in voor het > beheer van een aantal Linux systemen. Een aantal dat steeds blijft > groeien. Momenteel zo'n 250. > > On Fri, 2015-01-09 at 12:25 +0100, Paul van der Vlis wrote: > > Hoi allen, > > > > Ik beheer een aantal clients die eigenlijk identiek zijn, op een paar > > uitzonderingen na zoals de hostname. Ik heb een backup van zo'n client > > op de server. > > > > Om een client te installeren boot ik met een live-cd, partitioneer, > > formatteer, download de data uit de backup, en installeer grub. Wellicht > > kan dit handiger, maar dit werkt. > > > > Nu zit ik me af te vragen of zoiets ook later zou kunnen, dus om de > > machines identiek te houden. Bijvoorbeeld vanaf de server iets van: > > rsync -a --exclude=... --del /client pc01:/ > > > > Het lijkt me eigenlijk moeten kunnen, alleen komt die --exclude > > natuurlijk wel vrij precies. en zijn er wellicht nog meer punten (zoals > > de netwerk interfaces in udev, en het UUID van het filesystem moet > > identiek zijn). > > > > Hebben jullie al eens met zo'n gedachte gespeeld of er zelfs ervaring mee? > > > > Uiteraard is het hele filesysteem via NFS ook een optie, maar dat maakt > > b.v. het opstarten van een applicatie weer traag lijkt me. > > Verder wordt het niet zo heel veel gebruikt en is het niet altijd > > bruikbaar (bijvoorbeeld niet bij laptops). > > > > Ook iets als Puppet is een optie, maar dat lijkt me veel werk om goed > > aan de praat te krijgen. Ik gebruik nu een eigen script, wat een ander > > script download en uitvoert. > > > > Zelf gebruik ik Puppet om systemen identiek te houden, of althans de > delen van de systemen die me interesseren. > > Onze systemen zijn Red Hat, maar dat is perfect te vertalen naar > Debian-based systemen. Wij gebruiken kickstart om een machine te > installeren (virtueel of fysiek), in Debian zou dat 'preseeding' zijn. > Een van de items in onze 'post-install' scripts (uitgevoerd via de > automatische kickstart/preseed) gaat een puppet agent installeren en > verbinden met de puppet master (2 dedicated machines achter een hardware > load balancer). Als het moeilijk is om een aparte server te gebruiken > voor de Puppet master (geen hardware ter beschikking, of geografisch te > verspreid) kan je ook 'puppet apply' uitvoeren op de verschillende > machines (via crontab bijvoorbeeld). > > Puppet (en enkele andere tools zoals chef, maar daar heb ik geen > ervaring mee)zijn uitstekend geschikt voor configuration management > zoals het beheren van users, packages, services, etc... > Het identiek houden van files kan ook op een simpele manier (inclusief > de attributen zoals permissions, owner, etc.), maar als dit er echt veel > worden (hele directory trees) zal het Puppet erg vertragen tijdens een > run. Hiervoor is iets als rsync beter voor geschikt. Het rsync-commando > in een cronjob kan op zich dan weer perfect via puppet verspreid worden > naar de systemen. > > Mijn raad voor Puppet is vooral: begin klein. > Je moet niet meteen proberen om alles in Puppet te zetten, dat is meer > iets voor de langere termijn als je bestaande systemen hebt. > De eerste dingen die je doet zijn 'low hanging fruit', de makkelijke > dingen waar je normaal zelf het meeste tijd insteekt. > Ook nieuwe dingen zet je in Puppet, bestaande items kan je langzaam > toevoegen. Puppet beheert de zaken die je wil, al de andere dingen > worden niet aangeraakt. > > Een 2de tip voor Puppet is: denk in het begin niet aan hoe je iets in > Puppet zal zetten, maar hoe het er op de machine moet uitzien, dan pas > zet je dat in Puppet, niet omgekeerd. > > Succes! > > Regards, > Steven Nog een tip: Ansible Ansible is ook orchestration zo als Puppet en Chef. Grootste pluspunt van Ansible is dat het "agentless" is. Ansible maakt gebruikt van SSH en Python. Dus geen gekloot met eerst agent software op de clients te leggen. Ook geen gedoe met "certificates". Andere goede ontwerpkeuze van Ansible is dat volgorde in de "playbooks" aangehouden wordt. Bij Puppet wordt de volgorde van "afspelen" door de Puppetagent naar eigen goed dunken bepaalt ... En mocht je nog nooit eerder van Ansible gehoord / gelezen hebben, dat kan kloppen, het bestaat nog net geen drie jaar. http://en.wikipedia.org/wiki/Ansible_%28software%29 Groeten Geert Stappers -- Leven en laten leven -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015085829.gp23...@gpm.stappers.nl
Re: Clients identiek houden
On Fri, Jan 09, 2015 at 12:25:31PM +0100, Paul van der Vlis wrote:
> Hoi allen,
>
> Ik beheer een aantal clients die eigenlijk identiek zijn, op een paar
> uitzonderingen na zoals de hostname. Ik heb een backup van zo'n client
> op de server.
>
> Om een client te installeren boot ik met een live-cd, partitioneer,
> formatteer, download de data uit de backup, en installeer grub. Wellicht
> kan dit handiger, maar dit werkt.
>
> Nu zit ik me af te vragen of zoiets ook later zou kunnen, dus om de
> machines identiek te houden. Bijvoorbeeld vanaf de server iets van:
> rsync -a --exclude=... --del /client pc01:/
Dat lijkt me niet zo'n geweldig idee. Je wilt een config management
systeem gebruiken.
[...]
> Ook iets als Puppet is een optie, maar dat lijkt me veel werk om goed
> aan de praat te krijgen. Ik gebruik nu een eigen script, wat een ander
> script download en uitvoert.
Puppet is helemaal niet "veel werk om goed aan de praat te krijgen". Je
*kan* een puppet master opzetten, maar dat is niet absoluut nodig.
Gewoon een "git pull origin; puppet apply foo.pp" werkt ook. En dat kan
heel simpel; een foo.pp zoals dit:
---
$packages_goed = ['awesome', 'nbd-server', 'ltsp']
$packages_slecht = ['gnome', 'kde', 'xfce']
package {$packages_goed:
ensure => present,
}
package {$packages_slecht:
ensure => absent,
}
file {"/etc/nsswitch.conf":
ensure => present,
source => "http://foo.local/nsswitch.conf";,
}
---
... zorgt er voor dat "awesome", "nbd-server", en "ltsp" geïnstalleerd
worden, terwijl "gnome", "kde", en "xfce" weggehaald worden. Daarbovenop
zal /etc/nsswitch.conf vergeleken worden met de nsswitch.conf op de
opgegeven URL, en desnoods vervangen. Je kan die ook mee in de
repository steken, als je de juiste directories behoudt.
Het wordt natuurlijk wat complexer als je meer configuratie nodig hebt,
maar het voordeel van dat te doen (en in een versiecontrole-systeem te
steken) is dat je heel eenvoudig een rollback kunt doen in geval een
bepaalde update een foutje veroorzaakt...
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
--
To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2015082529.ga4...@grep.be
Re: Clients identiek houden
Dag Paul, Disclaimer: ik werk als ICT system engineer en sta mee in voor het beheer van een aantal Linux systemen. Een aantal dat steeds blijft groeien. Momenteel zo'n 250. On Fri, 2015-01-09 at 12:25 +0100, Paul van der Vlis wrote: > Hoi allen, > > Ik beheer een aantal clients die eigenlijk identiek zijn, op een paar > uitzonderingen na zoals de hostname. Ik heb een backup van zo'n client > op de server. > > Om een client te installeren boot ik met een live-cd, partitioneer, > formatteer, download de data uit de backup, en installeer grub. Wellicht > kan dit handiger, maar dit werkt. > > Nu zit ik me af te vragen of zoiets ook later zou kunnen, dus om de > machines identiek te houden. Bijvoorbeeld vanaf de server iets van: > rsync -a --exclude=... --del /client pc01:/ > > Het lijkt me eigenlijk moeten kunnen, alleen komt die --exclude > natuurlijk wel vrij precies. en zijn er wellicht nog meer punten (zoals > de netwerk interfaces in udev, en het UUID van het filesystem moet > identiek zijn). > > Hebben jullie al eens met zo'n gedachte gespeeld of er zelfs ervaring mee? > > Uiteraard is het hele filesysteem via NFS ook een optie, maar dat maakt > b.v. het opstarten van een applicatie weer traag lijkt me. > Verder wordt het niet zo heel veel gebruikt en is het niet altijd > bruikbaar (bijvoorbeeld niet bij laptops). > > Ook iets als Puppet is een optie, maar dat lijkt me veel werk om goed > aan de praat te krijgen. Ik gebruik nu een eigen script, wat een ander > script download en uitvoert. > Zelf gebruik ik Puppet om systemen identiek te houden, of althans de delen van de systemen die me interesseren. Onze systemen zijn Red Hat, maar dat is perfect te vertalen naar Debian-based systemen. Wij gebruiken kickstart om een machine te installeren (virtueel of fysiek), in Debian zou dat 'preseeding' zijn. Een van de items in onze 'post-install' scripts (uitgevoerd via de automatische kickstart/preseed) gaat een puppet agent installeren en verbinden met de puppet master (2 dedicated machines achter een hardware load balancer). Als het moeilijk is om een aparte server te gebruiken voor de Puppet master (geen hardware ter beschikking, of geografisch te verspreid) kan je ook 'puppet apply' uitvoeren op de verschillende machines (via crontab bijvoorbeeld). Puppet (en enkele andere tools zoals chef, maar daar heb ik geen ervaring mee)zijn uitstekend geschikt voor configuration management zoals het beheren van users, packages, services, etc... Het identiek houden van files kan ook op een simpele manier (inclusief de attributen zoals permissions, owner, etc.), maar als dit er echt veel worden (hele directory trees) zal het Puppet erg vertragen tijdens een run. Hiervoor is iets als rsync beter voor geschikt. Het rsync-commando in een cronjob kan op zich dan weer perfect via puppet verspreid worden naar de systemen. Mijn raad voor Puppet is vooral: begin klein. Je moet niet meteen proberen om alles in Puppet te zetten, dat is meer iets voor de langere termijn als je bestaande systemen hebt. De eerste dingen die je doet zijn 'low hanging fruit', de makkelijke dingen waar je normaal zelf het meeste tijd insteekt. Ook nieuwe dingen zet je in Puppet, bestaande items kan je langzaam toevoegen. Puppet beheert de zaken die je wil, al de andere dingen worden niet aangeraakt. Een 2de tip voor Puppet is: denk in het begin niet aan hoe je iets in Puppet zal zetten, maar hoe het er op de machine moet uitzien, dan pas zet je dat in Puppet, niet omgekeerd. Succes! Regards, Steven signature.asc Description: This is a digitally signed message part
Clients identiek houden
Hoi allen, Ik beheer een aantal clients die eigenlijk identiek zijn, op een paar uitzonderingen na zoals de hostname. Ik heb een backup van zo'n client op de server. Om een client te installeren boot ik met een live-cd, partitioneer, formatteer, download de data uit de backup, en installeer grub. Wellicht kan dit handiger, maar dit werkt. Nu zit ik me af te vragen of zoiets ook later zou kunnen, dus om de machines identiek te houden. Bijvoorbeeld vanaf de server iets van: rsync -a --exclude=... --del /client pc01:/ Het lijkt me eigenlijk moeten kunnen, alleen komt die --exclude natuurlijk wel vrij precies. en zijn er wellicht nog meer punten (zoals de netwerk interfaces in udev, en het UUID van het filesystem moet identiek zijn). Hebben jullie al eens met zo'n gedachte gespeeld of er zelfs ervaring mee? Uiteraard is het hele filesysteem via NFS ook een optie, maar dat maakt b.v. het opstarten van een applicatie weer traag lijkt me. Verder wordt het niet zo heel veel gebruikt en is het niet altijd bruikbaar (bijvoorbeeld niet bij laptops). Ook iets als Puppet is een optie, maar dat lijkt me veel werk om goed aan de praat te krijgen. Ik gebruik nu een eigen script, wat een ander script download en uitvoert. Groet, Paul. -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54afbaab.2090...@vandervlis.nl
