Script om nieuwe Ubuntu installatie te customizen

[aawe mwan]

Ik zit al jaren aan te hikken tegen het opnieuw installeren van Ubuntu op mijn werkstation. De reden is dat ik alle tweaks die ik in de loop van de jaren (sinds 2014) gedaan heb dan opnieuw zal moeten doen, maar ik heb er nooit een lijstje van gemaakt dus ik zal alles weer opnieuw bij elkaar moeten Googelen.

Ik heb me nu voorgenomen om een shellscript te gaan bouwen, dat ik straks eenmalig kan draaien over een verse Ubuntu installatie, zodat al mijn persoonlijke tweaks er in komen. Heet zoiets een configuratiescript?

Wat ik een paar jaar geleden ingesteld heb, is dat alle bestanden die door root ge-edit worden, een backup krijgen in de directory /root/config-backup . Dat op zich is dus al een tweak die het script op een nieuwe installatie moet uitvoeren. En ik weet nu welke tekstfiles mijn script zal moeten aanpassen.

Ik kan me zo voorstellen dat er een tool in de repository zit voor het updaten van een setting in een configfile. Maar ik heb die niet kunnen vinden. ik heb alleen crudini gevonden voor het updaten van INI files, dus meestal heb je daar niks aan. Daarom heb ik naar sed gekeken en je kunt gewoon een sed script schrijven zodat hij configregels kan updaten en toevoegen, met behoud van commentaar. Met sed werkt het en het was leerzaam en leuk om uit te zoeken hoe dit werkt, maar het is wel omslachtig.

Bestaan hier tegenwoordig niet handige standaardtools voor?

Op detailniveau: tools voor het aanpassen van een setting (in een tekstfile).
Op overkoepelend niveau: is een gewoon .sh bestand handig genoeg, of is het handiger om hiervoor een makefile te maken (ik weet nog niet hoe make werkt), of bestaat hier tegenwoordig een nieuwe tool voor die iedereen gebruikt?

Voor de volledigheid: het is dus niet zo dat ik elke maand 1000 nieuwe containers ga uitrollen, maar ik wil gewoon gemakkelijk minder dan 1 keer per jaar een verse installatie kunnen doen van mijn eigen werkstation.

[Raven]

"Ik kan me zo voorstellen dat er een tool in de repository zit voor het updaten van een setting in een configfile. "

Sed? Die gebruik ik op dit moment in een bash script dat van Debian een router maakt, om voorbeelden te geven: Het uncommenten van 2 regels in /etc/sysctl.conf

Bash:

sed -i "/^#net.ipv4.ip_forward=1/ cnet.ipv4.ip_forward=1" /etc/sysctl.conf
sed -i "/^#net.ipv6.conf.all.forwarding=1/ cnet.ipv6.conf.all.forwarding=1" /etc/sysctl.conf

De Network Manager instellen om alle interfaces te beheren, ook die wat in /etc/network/interfaces staan:

Bash:

sed -i "/^managed=false/ cmanaged=true" /etc/NetworkManager/NetworkManager.conf

(Vervang managed=false door managed=true.)

Zo heb ik nog meer regels, waaronder niet aangepaste maar toegevoegde regels aan config bestanden, dat is zo simpel als

Bash:

echo 'regel 1
regel2' >> /pad/configbestand.conf

Als je Googled op sed examples kun je zien wat dat tooltje allemaal kan

[ Voor 6% gewijzigd door Raven op 05-05-2020 11:46 ]

[LEDfan]

Augeas is IMO de meest bekende tool om eender welk config file aan te passen.
Opzich werkt die tool goed, maar het heeft wel een hoge leercurve en als iets niet werkt is het heeel lastig om te achterhalen waarom. Voordeel is dat augeas de structuur van de config file begrijpt en je dus meer kans hebt dat iets nog werkt als een stuk van de config file veranderd is. Daarnaast zal je met sed denk ik sneller resultaten behalen.

Configuration as code is het beheren van (server) configuratie m.b.v. van code. In je huidige opzet is dat een shell script, maar voor grotere setups wordt er dikwijls Puppet, Ansible of Chef gebruikt.
Chef ben ik zelf niet zo'n fan van, Puppet werkt heel goed maar is ook weer wat moeilijker om te leren en daarnaast ook wat moeilijker om te beheren. Ansible kan je gebruiken vanaf het moment dat je Python op je workstation hebt en daarvoor moet je ook geen specifieke taal leren (wel YAML).

Mijn conclusie: als je je goed voelt bij een shell script en het werkt naar behoren zou ik voorlopig niet naar andere tools kijken. Er bestaan betere manieren om dit te doen, maar om deze te gaan leren voor een simpele workstation lijkt me zwaar overkill.
Als je toch eens een dergelijke tool wilt gebruiken zou ik je aanraden om naar Ansible te kijken.
P.s. welke manier je ook kiest (shell script, ansible etc), als je de tool maar om het jaar gebruikt zal je waarschijnlijk wel wat aanpassingen moeten doen om het terug 100% te laten werken op een nieuwe versie van Ubuntu.
Maar je hebt dan wel het voordeel dat alles is gedocumenteerd hoe het hoort te werken (een van de belangrijke reden waarom dit voor servers vaak gebruikt wordt).

[aawe mwan]

@LEDfan Augeas klinkt eigenlijk wel als de tool die je wilt hebben om alle configs te editen. Je hebt al ontzettend veel mogelijkheden, daarom is het grappig dat het bestand /etc/hdparm.conf, een van de bestanden die ik zou willen aanpassen, nog niet bij de stock lenses zit.

Bij een nieuwe installatie heb je gelukkig nog niet te maken met de ingewikkelde configuraties die Augeas goed moet kunnen bewerken. Dan is het vaak zelfs zo simpel als "onderaan het bestand toevoegen".

@Raven Het klopt zeker dat het zal kunnen met sed, dat schreef ik eigenlijk ook al een beetje. Je kunt het sed script zelfs heel erg fancy maken, met bijvoorbeeld het uitcommentariëren van de vorige versie van de configregel als die al bestond. En voor dit alles kan je gewoon een functie definiëren in je bash script.

Maar het zou toch gemakkelijk zijn als je iets zou kunnen gebruiken dat vergelijkbaar is met bijvoorbeeld:
crudini --set /etc/sysctl.conf - vm.swappiness 1

[EnnaN]

aawe mwan schreef op dinsdag 5 mei 2020 @ 11:27:
Bestaan hier tegenwoordig niet handige standaardtools voor?

Voor de volledigheid: het is dus niet zo dat ik elke maand 1000 nieuwe containers ga uitrollen, maar ik wil gewoon gemakkelijk minder dan 1 keer per jaar een verse installatie kunnen doen van mijn eigen werkstation.

Je kan eens naar ansible kijken. Default install maken, en dan je ansible playbook eroverheen gooien. Elke change die je wil doen kan je dan ook via ansible doen, en weer uitrollen: zo hou je een up-to-date en geteste ansible situatie, en kan je altijd een nieuwe uitrol doen?

[Raven]

aawe mwan schreef op dinsdag 5 mei 2020 @ 12:32:
@Raven Het klopt zeker dat het zal kunnen met sed, dat schreef ik eigenlijk ook al een beetje. Je kunt het sed script zelfs heel erg fancy maken, met bijvoorbeeld het uitcommentariëren van de vorige versie van de configregel als die al bestond. En voor dit alles kan je gewoon een functie definiëren in je bash script.

Maar het zou toch gemakkelijk zijn als je iets zou kunnen gebruiken dat vergelijkbaar is met bijvoorbeeld:
crudini --set /etc/sysctl.conf - vm.swappiness 1

Woops, ik had niet zó ver gelezen Het is misschien wel wat omslachtig, maar het werkt prima Er zijn volgens mij wel commando's om te doen wat ik wil, maar zoals die voor het enablen van forwarding, die moet dan na elke start opnieuw uitgevoerd worden, het sed commando is 1 maal uitvoeren.

[thunder7]

Ik snap de zin niet goed - ubuntu is perfect in het upgraden tot de huidige release, zonder je settings te verliezen. En je kunt perfect opnieuw installeren, waarbij je je settings verliest.

Wat is exact het voordeel dat je verwacht van opnieuw installeren met een zelfgebouwd script om je settings en tweaks te bewaren t.o.v. een update die ubuntu al aanbiedt?

[aawe mwan]

thunder7 schreef op dinsdag 5 mei 2020 @ 13:25:
ubuntu is perfect in het upgraden tot de huidige release, zonder je settings te verliezen.

Het upgraden van 12.04 naar 14.04 en naar 16.04 ging goed, tot zo ver ben ik het met je eens.

Maar het upgraden van 16.04 naar 18.04 werkte niet goed: ik heb dit op diverse computers gedaan, het ging wel met elke puntrelease iets beter, maar het was steeds noodzakelijk om een verse installatie te doen om weer een bruikbare computer te krijgen: een van de vervelende problemen bij deze upgrade was een geheugenlek in de GUI, dat er niet was bij een verse installatie maar wel bij upgrade vanaf 16.04.

Vorige week heb ik een upgrade van 18.04 naar 20.04 gedaan en ik was er deze keer natuurlijk wel wat vroeg bij, maar deze keer is bijvoorbeeld door het upgradeproces de instelling verwijderd, die zorgde dat de machine niet in stand-by gaat als je via SSH bent ingelogd.

Ik vind het eigenlijk ook helemaal niet handig dat het upgradeproces regelmatig onderbreekt met de vraag of je een door jezelf aangepast configbestand wilt vervangen door het configbestand van de package maintainer. Natuurlijk wil je dat eigenlijk nooit, je wilt normaal de configuraties uit het verleden bewaren en je wilt ook de nieuw beschikbare opties aan het configbestand toevoegen. Maar dat is geen optie; als je dat wilt dan moet je het met de hand doen.

Dus daarom vind ik het handiger dat ik een script heb voor de configuratie. En dat script kan je natuurlijk gewoon zo opzetten dat je het zowel over een geupgrade als over een verse installatie kunt draaien.

[Hero of Time]

aawe mwan schreef op dinsdag 5 mei 2020 @ 15:31:
[...]


Het upgraden van 12.04 naar 14.04 en naar 16.04 ging goed, tot zo ver ben ik het met je eens.

Maar het upgraden van 16.04 naar 18.04 werkte niet goed: ik heb dit op diverse computers gedaan, het ging wel met elke puntrelease iets beter, maar het was steeds noodzakelijk om een verse installatie te doen om weer een bruikbare computer te krijgen: een van de vervelende problemen bij deze upgrade was een geheugenlek in de GUI, dat er niet was bij een verse installatie maar wel bij upgrade vanaf 16.04.

Vorige week heb ik een upgrade van 18.04 naar 20.04 gedaan en ik was er deze keer natuurlijk wel wat vroeg bij, maar deze keer is bijvoorbeeld door het upgradeproces de instelling verwijderd, die zorgde dat de machine niet in stand-by gaat als je via SSH bent ingelogd.

Dit zijn voor mij o.a. de redenen geweest om van het 'brakke' Ubuntu af te stappen en een rolling release distro te pakken. Dan heb je telkens kleine updates ipv elk half jaar of nog erger, elke 2 jaar, een grote waar zoveel is verandert dat je vorige config mogelijk meer problemen oplevert dan dat je wilt.

Ik vind het eigenlijk ook helemaal niet handig dat het upgradeproces regelmatig onderbreekt met de vraag of je een door jezelf aangepast configbestand wilt vervangen door het configbestand van de package maintainer. Natuurlijk wil je dat eigenlijk nooit, je wilt normaal de configuraties uit het verleden bewaren en je wilt ook de nieuw beschikbare opties aan het configbestand toevoegen. Maar dat is geen optie; als je dat wilt dan moet je het met de hand doen.

Er zijn genoeg situaties waarbij je de config van de maintener wel wilt hebben. Simpelweg omdat de service waar het voor is anders niet meer start omdat er allemaal deprecated meuk in staat en nu weigert te starten. Iets wat je niet merkt bij zo'n enorme verandering van versie, maar wel als je geleidelijk met de versies mee gaat.

Denk bijvoorbeeld aan Samba. Je zou iets er in kunnen hebben staat dat 6 jaar geleden met versie 3 prima werkte. Toen het 4 jaar geleden naar versie 4.0 ging werkte 't nog, maar had je al deprecated zaken erin. En dan upgrade je nog een keer, want alles werkte nog. Oeps, opeens niet meer, want de nieuwe versie heeft geen deprecation warnings meer en faalt gewoon. Zonder dat je weet waarom.

Bovenstaand scenario is dan ook waarom het handig is om met enige regelmaat een schone Ubuntu installatie te doen. En waarom je nu naar een oplossing zoekt voor je config.

Wat ik zelf doe? Tja, sinds de installatie van m'n twee computers (de eerste is van 2012) heb ik geen herinstallatie gedaan. Dus ik weet ook niet precies wat ik opnieuw zou moeten instellen. Dat zie ik tegen de tijd wel als ik er tegenaan loop. Ik herinner wel een paar, zoals m'n sources.list aanpassen om naar Unstable te gaan en Experimental toevoegen, bij inputrc een regel toevoegen om tab-completion niet hoofdlettergevoelig te maken en wat thema's in /usr/share/themes en /usr/share/icons plaatsen.

Als ik het wel allemaal zou bijhouden, dan zou ik dat in een documentje plaatsen en bijhouden omdat je nooit met zekerheid kan zeggen dat de optie die je nu zet, de volgende keer nog mogelijk is. In andere gevallen zo veel mogelijk kijken of er iets als .d mappen of config bestanden mogelijk zijn die je kan gebruiken voor je eigen wijzigingen bovenop de default (denk aan vimrc.local in /etc of lightdm.conf.d) en dan die bijhouden wat je nu al doet.

[MainframeX]

EnnaN schreef op dinsdag 5 mei 2020 @ 12:35:
[...]


Je kan eens naar ansible kijken. Default install maken, en dan je ansible playbook eroverheen gooien. Elke change die je wil doen kan je dan ook via ansible doen, en weer uitrollen: zo hou je een up-to-date en geteste ansible situatie, en kan je altijd een nieuwe uitrol doen?

Dit is wat ik zelf al jaren doe met Ansible. Ik heb gewoon alle aanpassingen bijgehouden in een playbook die ik op git bewaar. Bij installatie van een nieuwe laptop is het een kwestie van 5 á 10 minuutjes uit laten rammelen en dan nog 2-3% met de hand configureren en klaar. Wellicht dat je hier en daar nog een kleine aanpassing moet doen i.v.m. nieuwe release maar dat is echt minimaal.

Ik vind het echt een uitkomst zo. Je computers worden op deze manier een stuk vervangbaarder. Als je dan ook nog je data buiten je laptop/pc bewaard kan je hem letterlijk tegen de stenen gooien en met een nieuwe uit de doos na een half uurtje weer aan het werk. Het kost even een beetje tijd maar ik kan het iedereen aanbevelen!

[aawe mwan]

Intussen heb ik naar Ansible gekeken. Dat was een goede tip. Mijn indruk is dat met zo'n configscript (met sed) ik eigenlijk gewoon Ansible aan het nabouwen ben.

Het starten met Ansible is erg gemakkelijk. Voor mijn toepassing is de basis het playbook bestand. Boven een playbook hangt een structuur van de computers die je wilt managen, maar het enige dat je hoeft te weten is dat deze "inventory" in het bestand /etc/ansible/hosts staat en als je daar gewoon de naam en/of het IP-adres van je beheerde computer toevoegt, dan kan je meteen van start.

Het principe is dat je in het playbook bestand zet welke configuratie je wilt hebben en dat Ansible dan zelf uitzoekt of dat momenteel al op de beheerde computer staat en zo niet de commando's daarheen stuurt om de gewenste situatie te bereiken (als het al goed staat, dan verandert hij niks). Naar beneden toe vertaalt Ansible al je instellingen in SSH commando's en Python scripts, dus je hebt geen speciale software op de beheerde computer nodig.

Ansible weet zelf al wel welke slimme dingen hij met je packet tool kan doen (controleren of een package al geïnstalleerd is of niet, controleren hoe oud je repository cache is, dat soort dingen). Voor de meeste tekstfiles is de insteek van het playbook nog wel technisch: je geeft aan welke regels in welk tekstbestand moeten staan, zonder dat Ansible hoeft te weten waar die regels voor dienen.

Eigenlijk verbaast het me waarom ik niet veel eerder naar Ansible gekeken heb. Er zijn 2 redenen. Ik had nooit het vermoeden dat je met een tool als deze zo gemakkelijk kunt beginnen met het beheren van 1 computer. Maar belangrijker nog: alle tutorials die ik over Ansible gezien heb, hebben me niet een goede indruk gegeven van wat Ansible is. Met de kennis van nu heb ik nog een paar tutorials bekeken van mensen die ik in het algemeen goede tutorials vind maken, maar hun Ansible tutorials zijn dat niet echt.

Aan de video van Quentin Stafford-Fraser heb ik wel wat gehad:

--update--
Post geupdate omdat Ansible weldegelijk zelf de juiste packet management tool kan kiezen en toepassen.

[ Voor 13% gewijzigd door aawe mwan op 18-05-2020 19:28 ]

[aawe mwan]

Hero of Time schreef op dinsdag 5 mei 2020 @ 16:13:
[...]
Dit zijn voor mij o.a. de redenen geweest om van het 'brakke' Ubuntu af te stappen en een rolling release distro te pakken. Dan heb je telkens kleine updates ipv elk half jaar of nog erger, elke 2 jaar, een grote waar zoveel is verandert dat je vorige config mogelijk meer problemen oplevert dan dat je wilt.

Hmm ja, ik denk dat je hiermee het punt wel raakt.

Het idee van een LTS sprak me destijds ontzettend aan, toen ik begon met Ubuntu. Rond 2012 was dat. En zolang je binnen een release blijft, werkt heeft dat al die jaren prima gewerkt: geen verrassingen bij een normale update/upgrade, die is er gewoon binnen een tiental seconden doorheen en het systeem werkt daarna nog gewoon. Destijds was dit nog niet de normale gang van zaken bij PC's. Sterker: ik nam eigenlijk aan dat ik na ongeveer een jaar het OS gewoon opnieuw zou moeten installeren, wat dat was destijds wel normaal bij PC's.

Maar goed, als je grote veranderingen uitstelt tot ze allemaal bij elkaar komen, dan krijg je dus wat ik nu heb. Maar als ik moet kiezen: ik wil niet voor verrassingen wil komen te staan bij een gewone dagelijkse update, dus daarom kies ik (op de belangrijkste computer) niet rolling updates, maar voorlopig toch de oplossing met Ansible. (En het maakt ook overstappen gemakkelijk.)

[Berlinetta]

Ik heb zelf een Bash script gemaakt om mijn systemen te installeren.
Heb trouwens ook Ansible gebruikt, maar ik blijf bij Bash script(s).

[Douweegbertje]

aawe mwan schreef op vrijdag 15 mei 2020 @ 20:30:
[...]


Hmm ja, ik denk dat je hiermee het punt wel raakt.

Het idee van een LTS sprak me destijds ontzettend aan, toen ik begon met Ubuntu. Rond 2012 was dat. En zolang je binnen een release blijft, werkt heeft dat al die jaren prima gewerkt: geen verrassingen bij een normale update/upgrade, die is er gewoon binnen een tiental seconden doorheen en het systeem werkt daarna nog gewoon. Destijds was dit nog niet de normale gang van zaken bij PC's. Sterker: ik nam eigenlijk aan dat ik na ongeveer een jaar het OS gewoon opnieuw zou moeten installeren, wat dat was destijds wel normaal bij PC's.

Maar goed, als je grote veranderingen uitstelt tot ze allemaal bij elkaar komen, dan krijg je dus wat ik nu heb. Maar als ik moet kiezen: ik wil niet voor verrassingen wil komen te staan bij een gewone dagelijkse update, dus daarom kies ik (op de belangrijkste computer) niet rolling updates, maar voorlopig toch de oplossing met Ansible. (En het maakt ook overstappen gemakkelijk.)

Als Ansible gebruiker, maar dan voor servers, kan ik je in elk geval aanraden om vooral ook veel af te kijken en vervolgens daar je eigen draai aan te geven.
Persoonlijk kijk ik minder/niet in de "ansible galaxy" store - maar puur op github m.b.t. wat andere hebben gemaakt.

Er zijn namelijk best wel wat trucjes en tricks binnen Ansible, wat je leven oftewel makkelijker of lastiger kan maken Grote kans dat je ook iets tegenkomt wat voor 70% goed is voor jouw persoonlijke aanpak, en dan zou je de rest zelf kunnen bouwen.

Een belangrijk stukje is om je meuk wel zodoende te maken dat het idempotent is. Als je dat niet doet, kan je in vervelende situaties terecht komen.

[_eXistenZ_]

Saltstack, Ansible, Puppet, Chef, of een eigen bash script

[jurroen]

Ik zou persoonlijk met shellscripting - zoals bash - beginnen. Dat is een laagdrempelige en leuke manier om het te leren. Je kunt simpel beginnen die wat simpele taken doen, zoals een configuratiebestandje aanmaken of een bestaande bewerken - of je kunt het gelijk heel fancy doen en iets bouwen wat op meerdere dstro's werkt

Ik gebruik zelf geruime tijd Ansible, maar dat is ook omdat ik een behoorlijke fleet van servers moet bijhouden en het net even wat efficienter werkt; het pielen met shellscripting heeft mij wel enorm veel geleerd over de architectuur en hoe je bepaalde zaken het beste kunt aanpakken. Want dat leer je ook - het is niet alleen maar code met een juiste syntax

[Verwijderd]

Ik geloof dat jij Kickstart zoekt

Je kan daarmee een volledige installatie grotendeels, zo niet alles, aanpassen voor, tijden en na een installatie van Ubuntu. En dat volledig unattended.

https://help.ubuntu.com/l...n-guide/i386/ch04s06.html

[powerboat]

Ik maak gebruik van Ansible (lokaal) + Git door de wijzigingen in git aan te passen. Kun je makkelijk een stapje terug doen en testen in een vm voordat je upgrade.

En voor elke nieuwe os release een aparte branch maken.

Ansible is door yml goed te lezen en heb je niet het gevoel van hoe zat het ook alweer

[aawe mwan]

Intussen heb ik mijn eerste dagelijks gebruikte computer overgeformatteerd en daarna volledig automatisch in de oude staat hersteld met Ansible.

Basis van mijn strategie was het maken van de volgende scheiding:

• Alle settings die in /home staan, gaan mee door /home 1:1 te kopieren op bestandsniveau;
• Al het andere wordt door Ansible opnieuw gemaakt in de schoon geïnstalleerde versie;

„Al het andere” zijn bijvoorbeeld settings die buiten /home staan zoals een ramdisk in /etc/fstab, het installeren van softwarepackages of het aanmaken van de bijbehorende startscriptjes in /etc/local/bin.

Na het terugzetten miste ik wat instellingen in eerste instantie, maar dat bleek te komen door dconf: de dconf instellingen staan weliswaar in een bestand in /home, maar voor de ingelogde user overschrijft het systeem dat bestand met wat er in het geheugen staat; op die manier kan je dit bestand dus niet zelf terugzetten.

Zie ik het verkeerd, of heb ik nu ook een perfecte disaster-recovery als ik het systeem verdeel over 2 drives:

• De drive met mountpoint /home kan ik t.z.t. terughalen van de backup;
• De drive met mountpoint / kan ik nu al inrichten en veilig in de kast bewaren.

[ Voor 3% gewijzigd door aawe mwan op 17-04-2021 15:23 ]