Script de post‑instal·lació a Linux: com automatitzar el teu sistema després de formatar

  • Un bon script de post‑instal·lació a Bash permet automatitzar actualització, instal·lació de programes i ajustaments clau després de reinstal·lar Linux.
  • Cada família de distribucions requereix ordres específiques d'actualització i instal·lació, per la qual cosa convé mantenir scripts separats per distro.
  • Per a desplegaments avançats o massius poden utilitzar eines com Kickstart, Ansible o fins i tot enfocaments tipus Linux From Scratch.
  • El nivell de complexitat pot anar des d'un install.sh simple reutilitzable fins a la construcció completa d'un sistema Linux personalitzat.

Script de post‑instal·lació a Linux

Si cada vegada que reinstal·les o formatges el teu Linux perds una tarda sencera deixant el sistema “com a tu t'agrada”, necessites automatitzar-ho ja. Un bon script de post‑instal·lació et permet, amb una sola ordre, actualitzar el sistema, instal·lar els teus programes clau, aplicar ajustaments de seguretat i fins i tot deixar afinat el teu entorn d'escriptori i els teus dotfiles sense anar ordre a ordre.

La idea és molt simple: preparar un o diversos scripts Bash reutilitzables que guardis en USB booteable multiboot, al teu repositori de configuració o en un disc extern, i que puguis llançar només acabar la instal·lació del teu distro. A partir d'aquí, el sistema es posa “en pilot automàtic” i només vigiles que no hi hagi errors grossos. Veurem com fer-ho en diferents situacions: des del típic Ubuntu recentment instal·lat fins a escenaris més avançats amb diverses distros, passant per eines d'instal·lació automatitzada.

Què és un script de post-instal·lació a Linux i per a què serveix?

Un script de post-instal·lació no és més que un fitxer de text executable amb ordres Bash que realitzen de forma seqüencial tot el que faries tu a mà just després d'instal·lar Linux. En lloc d'anar teclejant “sudo apt install això”, “sudo apt install allò altre”, toquetejar el tallafocs, instal·lar snaps, etc., el deixes escrit una vegada i el reutilitzes totes les vegades que vulguis.

Aquest tipus de script sol encarregar-se de tasques típiques de posada a punt : actualitzar la distro, instal·lar programes base (navegador, suite ofimàtica, eines de seguretat, multimèdia), activar i configurar el tallafoc, ajustar algun comportament de l'entorn gràfic (per exemple el dock del GNOME) i, si vols, executar altres scripts que portin el teu facis servir en el teu dia a dia.

Crear un script Bash bàsic de postinstal·lació

Comencem per l'enfocament més directe: un script Bash al teu home que puguis copiar enganxar a qualsevol instal·lació nova. Val per a distro-hoppers, per a qui reinstal·la molt la mateixa distro o per a tenir un guió reproduïble quan muntes equips per a uns altres.

Com utilitzar Ventoy per reparar USB
Article relacionat:
Passos per crear un USB booteable multiboot amb Ventoy

Primer, creeu el fitxer de l'script, per exemple install.sh :

touch install.sh

Després fes-ho executable, de manera que puguis llançar-ho amb ./install.sh. Aquí se sol fer servir Chmod amb permisos per a tots els usuaris, i sovint es llença de sudo si l'arxiu està en un lloc on cal elevar permisos:

sudo chmod a+x install.sh

Ara editeu el fitxer amb el vostre editor preferit. Pots fer servir Vim, Nano, Emacs, Gedit, Kate o el que tinguis més a mà. Un exemple clàssic usant Vim seria:

sudo vim install.sh

Al principi del fitxer hi ha dues línies gairebé obligatòries. La primera indica quin intèrpret ha d'executar l'script (la “shebang”):

#!/bin/bash

La segona línia sol utilitzar-se per indicar la codificació , la qual cosa és útil si utilitzaràs titlles, enyes o caràcters rars en comentaris o missatges:

# -*- ENCODING: UTF-8 -*-

Actualitzar el sistema segons la distribució

Una de les primeres coses que tothom fa després d'instal·lar Linux és actualitzar els paquets . Aquest pas també ha d'estar al teu script, però és important tenir en compte que cada distro utilitza un gestor de paquets diferent . El normal és que el teu script estigui pensat per a una família concreta (per exemple Debian/Ubuntu) i, si en toques diverses, que tinguis un script diferent per a cada cas.

Per a distribucions de l'estil Debian, Ubuntu i derivades , la seqüència típica pot ser:

sudo apt update && sudo apt -y upgrade

En altres distros la cosa canvia. Per exemple, a CentOS i Red Hat “like” s'ha utilitzat tradicionalment yum :

sudo yum update

En versions noves de Fedora va aparèixer dnf com a evolució de yum, amb una sintaxi molt semblant. Així, per a Fedora podries fer servir:

sudo dnf update

En el cas d' openSUSE , el sistema de paquets es gestiona normalment amb zypper i l'actualització general es fa amb:

sudo zypper update

Al món Arch Linux, Manjaro, Antergos, KaOS i altres basades en pacman, l'equivalent seria:

sudo pacman -Syu

Si a més uses eines externes com yaourt (avui dia substituït per yay i altres ajudants d'AUR), en alguns entorns es veia alguna cosa com:

yaourt -Syua

Altres com Gentoo o Slackware tenen els seus propis gestors i ordres dactualització. En aquest cas, el teu script anirà adaptat al que facis servir (emergeix, slapt‑get, etc.), però la idea sempre és la mateixa: deixar la base del sistema al dia tot just arrencar la post‑instal·lació.

Organitzar la instal·lació de programes per categories

Un cop el sistema està actualitzat, arriba el moment d' instal·lar tot el programari que necessites . Perquè l'script no sigui un caos, és una bona idea classificar els paquets en grups lògics i deixar els comentaris ben clars. Un esquema típic pot tenir categories com aquestes:

  • utilitats: eines de sistema, compressors, monitors, etc.
  • Internet: navegadors, clients de correu, missatgeria.
  • Jocs: Steam, Lutris, jocs nadius, etc.
  • DE / Escriptoris: entorns gràfics i complements.
  • Multimèdia: reproductors de vídeo i àudio, editors d'imatge.
  • Productivitat: suites ofimàtiques, gestors de notes, tasques.
  • Desenvolupament: compiladors, IDEs, eines de debugging.

A l'script, podeu introduir comentaris per a aquestes seccions, de manera que sigui fàcil localitzar cada bloc. Una cosa així:

# Utilidades
# Desarrollo
# Internet
# Juegos
# DE's y WM's
# Multimedia
# Productividad

A sota de cada bloc comentat, afegeixes les ordres d'instal·lació adequades per al teu distro. En un sistema basat en Arch Linux , podríeu tenir alguna cosa de l'estil:

sudo pacman -S chromium
sudo pacman -S steam
sudo pacman -S gnome-shell gnome-extra

L'objectiu és que, quan executeu l'script, s'instal·lin de cop totes les aplicacions que sols utilitzar sempre . Si en algun moment vols canviar la teva selecció (afegir o treure un programa), només modifiques la llista de paquets d'aquesta categoria i llest.

Executar l'script i les bones pràctiques

Quan ja has escrit i guardat el teu script install.sh des de la terminal només has d'anar a la carpeta on el tinguis i llançar-lo. Un patró còmode és combinar canvi de directori i execució:

cd /ruta/del/script && ./install.sh

Una altra opció molt simple per a usuaris d'Ubuntu o Debian és invocar directament bash sobre el fitxer:

bash nombre-script.sh

Perquè no hagis d'estar pendent de confirmacions, en moltes ordres d'instal·lació es fa servir el paràmetre -i (o equivalent) que accepta per defecte la pregunta de “Voleu continuar?”. D'aquesta manera l'script pot executar-se de principi a fi sense intervenció , la qual cosa és còmode quan ho llances just després d'instal·lar el sistema i el deixes llençant actualitzacions, instal·lacions i neteja mentre fas una altra cosa.

Exemple pràctic de script post‑instal·lació a Ubuntu

script post‑instal·lació a Ubuntu

En un escenari típic amb Ubuntu 22.04 LTS o posterior , té sentit muntar un script que combini APT i Snap, perquè algunes aplicacions només estan disponibles com a snaps. Un exemple de flux podria ser aquest: actualitzar, instal·lar paquets de sempre, netejar el sistema, instal·lar snaps clau, activar el tallafocs i aplicar algun retoc descriptori.

Un esquelet senzill d'aquest tipus de seqüència podria contenir blocs de l'estil:

#!/bin/bash

# Actualitzar la llista de paquets
sudo apt update

# Instal·lar actualitzacions disponibles sense preguntar
sudo apt -i upgrade

# Eliminar paquets que ja no són necessaris i netejar
sudo apt -i autoremove
sudo apt autoclean

# Instal·lar aplicacions habituals via APT
sudo apt -i install vlc gimp clamav chkrootkit lynis

# Instal·lar aplicacions habituals com Snaps
sudo snap install chromium brave

# Habilita UFW (tallafocs del nucli Linux)
sudo ufw habilitar

# Ajustar el comportament del dock del GNOME
gsettings set org.gnome.shell.extensions.dash-to-dock acció de clic 'minimitzar'

Amb una cosa tan compacte estàs cobrint actualitzacions, neteja, programari base, seguretat i un petit ajustament d'usabilitat . Per descomptat, pots ampliar aquest script al teu gust: afegir instal·lació d'eines de desenvolupament, configuració de backups, scripts que descarreguin els teus dotfiles des de Git, etc.

Usar eines avançades: Ansible, Xef i similars

Si treballes amb diverses màquines o has de replicar el teu entorn a servidors, portàtils i sobretaules, arriba un punt en què un script Bash simple es queda curt. Hi entren eines com Ansible, Xef i companyia, que permeten descriure l'estat desitjat d'un sistema (paquets instal·lats, fitxers de config, serveis actius) i aplicar-lo de manera reproduïble.

Alguns usuaris que estan farts de fer sempre la mateixa configuració post‑instal·lació a Ubuntu recorren a aquests sistemes de gestió de configuració oa projectes ja fets de post‑instal·lació específics . Un exemple real és un repositori dedicat a automatitzar la post-instal·lació a Ubuntu, on es combinen scripts Bash amb definicions de paquets, temes, tipografies i altres preferències.

Tot i així, per a molts casos d'escriptori el més pràctic segueix sent un script Bash sense dependències externes , sobretot si busques alguna cosa senzilla de transportar en un USB o que puguis copiar en una màquina recent instal·lada sense caminar muntant infraestructura addicional.

Automatització des del propi instal·lador: scripts de %post i Kickstart

Al món de les distribucions tipus Red Hat, CentOS, Rocky i derivades, és molt habitual fer servir kickstart per a instal·lacions desateses. Dins un fitxer Kickstart es pot definir una secció %post que s'executa automàticament en finalitzar la instal·lació del sistema base.

La idea és que, si has definit bé la configuració de xarxa al mateix Kickstart, en entrar a la secció de postinstal·lació la xarxa ja estarà aixecada. Aquí pots col·locar qualsevol ordre que vulguis automatitzar: instal·lació de paquets addicionals, ajustaments, descàrregues de scripts, canvis en missatges del sistema, etc.

Com a exemple senzill, es podria canviar el missatge del dia (MOTD) del sistema recent instal·lat col·locant a la secció %post una cosa equivalent a:

%post
echo "Bienvenido a tu nuevo servidor" > /etc/motd
%end

Aquest enfocament de script de post-instal·lació embegut a l'instal·lador és molt potent per a desplegaments massius , ja que tot el procés és 100% automàtic: arrenca la instal·lació, s'apliquen particions i paquets base, s'executen scripts de post-instal·lació i el sistema queda llest per utilitzar-se.

Limitacions en replicar instal·lacions entre distros heterogènies

Quan intentes utilitzar un únic mecanisme genèric de post-instal·lació per a distros molt diferents , comencen els mals de cap. No totes gestionen actualitzacions, dependències i pegats de la mateixa manera, ni ofereixen les mateixes versions de programari als seus repositoris.

Cal distingir, d'una banda, un script que només enumera paquets a instal·lar i deixa que el gestor de la distro resolgui dependències (com fa apt-get o eines estil zypper, dnf, urpmi), i de l'altra, un sistema que pretén manejar també pegats de seguretat, backports i versions noves de programes que la distribució original ni tan sols.

En una distro com Debian , amb milers de paquets i un ecosistema immens, l'instal·lador i les eines com a apt s'encarreguen de resoldre dependències del programari que la mateixa distribució manté. En altres, especialment les comercials, la filosofia és diferent: et donen el conjunt de paquets i pegats que han decidit suportar i, fora d'allà, ja entres en un terreny on la resolució de dependències i actualitzacions no està garantida.

Un exemple il·lustratiu: en una SuSE 8.2 antiga, si volies actualitzar PostgreSQL amb apt a una versió més nova que l'original de la distribució, et trobaves que apt et demanava primer la versió inclosa als CD oficials. Havies d'entrar a YaST, marcar el paquet original per a la instal·lació des del CD corresponent, i només després apt acceptava aplicar l'actualització extra des dels seus repositoris. Aquest tipus de particularitats fa que sigui difícil tenir una eina única que funcioni sense intervenció en tots els casos.

Instal·lar apps de Linux a Windows 11 amb WSL2
Article relacionat:
Com instal·lar i configurar el Subsistema de Windows per a Linux 2 (WSL2)

Els propis instal·ladors de moltes distros ja contemplen mecanismes per gravar seleccions de paquets i reutilitzar-les en altres màquines (per exemple, desar la llista de paquets en un disquet o mitjà extern i carregar-la en una instal·lació nova). En aquestes situacions, l'instal·lador torna a calcular dependències, us avisa del que falta, podeu resoldre'l automàticament o demanar-vos que accepteu paquets addicionals, o fins i tot us mostrarà l'opció arriscada de “seguir endavant encara que hi hagi possibles inconsistències”.

Quan, a més, parlem de granges de màquines heterogènies , amb maquinari i perfils de programari diferents, la complexitat es dispara. Perquè una utilitat genèrica de replicació de postinstal·lacions funcioni bé entre diferents distribucions, o bé tu mateix empaquetes i mantens tots els binaris, pegats i dependències per a cada distro , o necessites que les mateixes distribucions donin suport oficial a aquest sistema unificat, cosa poc probable en el context comercial actual.

Scripts de post‑instal·lació en entorns personalitzats i LFS

A l'extrem oposat a les distros preempaquetades hi ha els entorns en què et construeixes el teu sistema Linux des de zero , a l'estil Linux From Scratch (LFS). Aquí la post-instal·lació deixa de ser una llista de paquets i es converteix en una sèrie molt llarga de passos guiats : compilació d'eines, creació de particions, muntatge de sistemes de fitxers, ajustaments de toolchain, configuració de serveis bàsics, etc.

Seguir una guia detallada de LFS o una variant més didàctica et porta a entendre el sistema des de les capes més baixes: compiladors, enllaçadors, biblioteques C, intèrpret d'ordres, utilitats bàsiques, fins arribar al kernel ia l'arrencada amb GRUB. És un procés que es pot allargar diversos dies (entre 3 i 5, fàcilment) , requereix paciència i cert nivell d'administració Unix, però a canvi et dóna un control total sobre què s'instal·la i com es munta el sistema.

En un cas real basat en Debian com a sistema amfitrió dins d'una màquina virtual a VirtualBox, el flux comença per crear una VM amb un disc de, per exemple, 30 GB, instal·lar Debian 10 com a base, afinar els repositoris a /etc/apt/sources.list per poder accedir als paquets de compilació (build-essential, linux-headers-amd64, etc.) i després instal·lar les VBoxLinuxAdditions per tenir la integració completa amb el host.

Un cop el sistema base està còmode per treballar (pantalla completa, dependències de compilació resoltes), es crea una segona unitat de disc virtual, també de mida fixa, que serà on s'aixequi el nou sistema Linux personalitzat. Des de Debian es particiona aquest segon disc (per exemple /dev/sdb) amb eines com separat, es defineix una taula de particions de tipus msdos i es creen particions primàries i lògiques (arrel, swap, /home) seguint un esquema similar al del primer disc.

Després es formategen aquestes particions amb els sistemes de fitxers apropiats, se n'obtenen les particions UUID amb utilitats com blkid i s'afegeixen entrades a /etc/fstab del sistema amfitrió per muntar-les en punts com /mnt/lfs, /mnt/lfs/home i per habilitar el intercanviar. A partir d'aquí es munta l'estructura base, es creen directoris com $LFS/sources y $LFS/tools, es descarrega una llarga llista de paquets amb wget usant un fitxer wget-list i es crea un usuari dedicat, per exemple lfs, Amb el seu .bash_profile y .bashrc adaptats a lentorn de compilació.

El procés continua amb un inspector (un script de comprovació de versions) que verifica que hi són presents totes les eines necessàries (Bash, Binutils, GCC, etc.), instal·lant en molts casos tant el paquet principal com la seva variant de desenvolupament (-dev o -devel). També es creen enllaços simbòlics clau, com fer que /bin/sh apunti a Bash, i es van compilant un per un paquets com binutils, gcc, glibc, tcl, expect, deixagnu, m4, ncurses, bison, bzip2, coreutils, diffutils, file, findutils, gawk, gettext, grep, gzip, make, patch, perl, Python, set, tar, tex i molts altres, en dues rondes (toolchain temporal i toolchain final dins del chroot).

Al llarg del camí se sol netejar símbols de depuració innecessaris per estalviar espai, s'eliminen biblioteques estàtiques que no són imprescindibles, s'ajusta la cadena d'eines perquè totes les noves compilacions utilitzin les biblioteques acabades d'instal·lar i s'entra a l'entorn chroot preparació /dev, /proc, /sys, /run i creant nodes com /dev/console y /dev/null.

Dins del chroot es construeix l'arbre estàndard de directoris (/bin, /sbin, /usr, /var, /etc…), es generen enllaços simbòlics provisionals per a programes que encara no existeixen, s'inicialitzen / etc / passwd y / Etc / group amb un usuari root mínim, i es preparen arxius de log a /var/log amb permisos correctes. També es configuren les locals amb eines com locale-gen o equivalents, se selecciona zona horària amb tzselect i es crea un enllaç des /etc/localtime a la zona triada a /usr/share/zoneinfo.

Una altra peça crítica és la configuració de nsswitch.conf perquè la resolució de noms i altres serveis funcionin bé en xarxa, i la de ld.so.conf al costat de ldconfig per registrar les rutes de les noves biblioteques dinàmiques. Després, ja amb la glibc i els compiladors definitius, es recompilen paquets clau per assegurar-vos que tot enllaça correctament.

En paral·lel es va configurant l'accés a la xarxa al nou sistema: es creen fitxers tipus /etc/sysconfig/ifconfig.eth0 (o el nom d'interfície que correspongui), es defineix la IP, la porta d'enllaç i la màscara, es genera /etc/resolv.conf amb els servidors DNS adequats i es fixen nom d'amfitrió y / Etc / hosts amb la informació de la màquina.

També es configuren scripts i fitxers d'arrencada com /etc/inittab , /etc/sysconfig/clock , /etc/sysconfig/console i /etc/sysconfig/rc.site , on s'ajusten detalls com el nivell d'execució per defecte, el maneig de logs del sistema, l'idioma de consola, el mapa.

Per a l'experiència de shell es personalitzen /etc/profile i fitxers del tipus ~/.bash_profile i ~/.bashrc , a més de /etc/inputrc per a la biblioteca Readline (controlant dreceres de teclat, comportament de la història d'ordres, etc.). Es crea també un /etc/shells amb la llista de shells vàlides i un /etc/fstab adaptat a les noves particions (arrel, home, swap, /boot si n'hi ha).

Més endavant arriba el torn de compilar el nucli Linux: es descomprimeix la versió triada (per exemple un linux-5.x.y), es parteix d'un fitxer de configuració base, es revisen opcions clau com CONFIG_DEVTMPFS i altres relacionades amb udev i el maquinari de la VM, s'entra al menú de configuració (make menuconfig) per ajustar el nom per defecte del host i nombroses característiques, i finalment es compila (make, make modules_install) i s'instal·la el nucli i els seus components a /boot.

El pas final sol ser instal·lar i configurar GRUB com a carregador d'arrencada. S'executen ordres perquè GRUB s'escrigui al MBR del disc correcte, es genera un grub.cfg amb les entrades per al nou nucli i, si escau, per a altres sistemes presents. En aquest context concret, com que la distribució amfitriona Debian es va fer servir només com a “andami”, al final es retira el seu disc virtual de la màquina, de manera que el disc que al principi era /dev/sdb passa a ser / Dev / sda i el nou sistema Linux arrenca de forma autònoma.

Quan tot és al seu lloc, es creen arxius d'identificació com /etc/lsb-release i /etc/os-release amb el nom de la nova distro (per exemple “S4viOS”), s'ajusta un bashrc agradable per a root i futurs usuaris, i es fa un darrer desmuntatge de sistemes de fitxers abans del gran moment: reiniciar la VM , has currat des de zero arrenca per primera vegada.

Quan val la pena anar tan lluny i quan n'hi ha prou amb un simple script

Com utilitzar Ventoy per reparar USB
Article relacionat:
Passos per crear un USB booteable multiboot amb Ventoy

Tot aquest recorregut, des de l' script senzill d'APT o pacman fins al muntatge d'un sistema LFS amb kernel personalitzat i GRUB, il·lustra bé el rang de possibilitats que tens a Linux a l'hora d'automatitzar la postinstal·lació.

Per al dia a dia, el més pràctic per a gairebé qualsevol és mantenir un o diversos scripts de post-instal·lació per distribució , on actualitzis, instal·lis i afinis el que fas servir sempre; si et mous amb moltes màquines o entorns mixtos, entra en joc Ansible o Kickstart amb seccions %post; i si el que et demana el cos és entendre Linux des dels budells, el camí tipus LFS, encara que llarg, et dóna un nivell de control que cap distro comercial ofereix de sèrie. Comparteix la guia perquè més usuaris sàpiguen del tema.


Afegir com a font preferida a Google