Ja saps qui ets i en quina màquina ets. Queda la pregunta que tanca l'orientació: on ets i què tens al voltant.

Quan obres l'explorador de fitxers a Windows veus C:, potser D:, i una carpeta Program Files on s'instal·la el programari. A Linux no existeix res d'això. Hi ha un únic arbre que neix a / i del qual penja absolutament tot: els programes, la configuració, els teus documents, els discos, i fins i tot informació que no és en cap disc, com la temperatura del processador.

Aquesta lliçó et dona el mapa. En acabar-la, quan vegis una ruta com /var/log/tramontana/acces.log la sabràs llegir com una frase amb significat, i quan hagis de decidir on col·locar una peça de programari nova no ho faràs per intuïció sinó amb l'estàndard a la mà. És la diferència entre un servidor que qualsevol pot administrar i un servidor on les coses són «on les va posar en Tal».

1. Un arbre únic enfront de les unitats de Windows
2. Què significa muntar
3. L'estàndard FHS: recorregut pels directoris
4. Dades estàtiques i variables, compartibles i no compartibles
5. Tot és un fitxer: els set tipus
6. Els pseudo-sistemes /proc i /sys
7. Fitxers ocults i la convenció del punt
8. Rutes absolutes i relatives
9. On va cada peça de Tramontana i per què

La diferència estructural amb Windows és de fons, no de nomenclatura.

A Windows, l'estructura de l'emmagatzematge es reflecteix a les rutes: si un fitxer és al segon disc, la seva ruta comença per D:. Si demà aquell disc canvia de lletra, totes les rutes canvien.

A Linux, la ruta descriu què és el fitxer, no on és físicament. /var/log/tramontana/acces.log significa «un fitxer de registre de l'aplicació Tramontana». Que sigui al primer disc, al segon, en un volum LVM o en un recurs de xarxa compartit és irrellevant per a qui el fa servir i pot canviar sense que cap programa se n'assabenti.

Aquesta independència entre estructura lògica i disposició física és una de les millors idees del disseny Unix, i el mecanisme que la fa possible s'anomena muntatge.

Muntar és connectar el contingut d'un dispositiu d'emmagatzematge a un directori de l'arbre. Aquell directori s'anomena punt de muntatge, i a partir del muntatge, entrar-hi significa entrar al dispositiu.

Mira-t'ho al teu servidor:

Interpretació: la partició /dev/sda2 està muntada a /, i la /dev/sda1 a /boot/efi. Quan accedeixes a un fitxer dins de /boot/efi, estàs llegint del segon dispositiu, encara que des del teu punt de vista només hagis entrat en un subdirectori.

Les conseqüències pràctiques d'aquest model són enormes:

• Pots afegir un disc nou de 2 TB i muntar-lo a /srv/tramontana/backups. Els scripts de còpia de seguretat continuen escrivint a la mateixa ruta de sempre i no se n'assabenten de res.
• Pots muntar un recurs de xarxa a /mnt/nas i treballar-hi com si fos local.
• Pots aïllar riscos: si /var és a la seva pròpia partició, un registre desbocat no omple el sistema arrel, com vam veure a la lliçó 01-04.

El muntatge en profunditat, el fitxer /etc/fstab i el muntatge automàtic són la lliçó 05-04.

L'FHS (Filesystem Hierarchy Standard) és el document que defineix què va a cada directori. El manté la Linux Foundation i el segueixen totes les distribucions importants.

El seu valor és enorme i molt concret: gràcies a ell, un administrador que arriba a un servidor Rocky Linux sap que la configuració és a /etc sense necessitat de buscar-la. L'FHS és el que fa que Linux sigui predictible.

Mira l'arrel del teu servidor:

Cinc directoris concentren el 90 % de la teva feina. Val la pena detallar-los.

/etc — la configuració. Tot allò que configura el sistema i els seus serveis és aquí, i gairebé sempre en text pla. És el directori més valuós d'un servidor: si fas còpia d'/etc, pots reconstruir la configuració de la màquina.

Cada nom és una peça que estudiaràs: passwd i group (usuaris, lliçó 05-01), fstab (muntatges, 05-04), crontab (tasques programades, 03-07), ssh (accés remot, 06-02), netplan (xarxa, 06-01).

I una implicació del fet que sigui text pla que convé apreciar ara: /etc es pot versionar amb Git. Molts administradors ho fan, i així tenen l'historial complet de canvis de configuració dels seus servidors, amb qui va canviar què i quan.

/var — el que creix. Variable: dades que canvien durant l'operació normal.

És el directori que més vigila un administrador, perquè és el que s'omple.

/home — els usuaris. Cada usuari té el seu: /home/operador, /home/alumne. És l'únic lloc on un usuari normal pot escriure lliurement, i on viurà /home/operador/scripts.

/opt i /usr/local — programari que no ve del gestor de paquets. Aquí hi ha una distinció fina que confon molta gent:

/srv — dades servides. És el menys utilitzat i el pitjor entès. L'FHS el defineix com les dades que aquest servidor serveix a tercers: llocs web, FTP, recursos compartits, còpies de seguretat. La diferència amb /var/www és que /srv està pensat per organitzar-se per servei o per client, i moltes distribucions el deixen buit perquè l'administrador l'estructuri.

Si llistes l'arrel amb detall veuràs una cosa curiosa:

Aquella l inicial i la fletxa indiquen que no són directoris reals, sinó enllaços simbòlics als seus equivalents dins d'/usr. És l'anomenada usr merge, completada a Ubuntu i a la majoria de distribucions modernes.

Històricament, /bin contenia allò imprescindible per arrencar i reparar el sistema (perquè /usr podia ser en una altra partició o fins i tot en xarxa i no estar disponible al començament de l'arrencada), i /usr/bin la resta. Avui initramfs resol l'arrencada primerenca i aquella separació ja no aporta res, així que es va unificar. Els enllaços es mantenen perquè les rutes antigues de milers de scripts continuïn funcionant.

És un bon exemple de com l'FHS evoluciona conservant la compatibilitat.

L'FHS no és una llista arbitrària de noms. Al darrere hi ha dos eixos de classificació, i entendre'ls et permet deduir on va cada cosa en lloc de memoritzar-ho.

Els dos eixos:

• Estàtic enfront de variable. Estàtic és el que només canvia quan un administrador instal·la o modifica alguna cosa: els programes d'/usr, la configuració d'/etc. Variable és el que canvia sol durant el funcionament: els registres de /var/log, les cues, les memòries cau.
• Compartible enfront de no compartible. Compartible és allò que tindria sentit servir per xarxa a diverses màquines: els binaris d'/usr són idèntics a tots els servidors de la mateixa distribució. No compartible és allò específic d'una màquina: la seva configuració de xarxa, el seu hostname, els seus registres.

Quatre conseqüències pràctiques que apareixen constantment en administració:

1. Determina què es copia i amb quina freqüència. /etc (estàtic, no compartible) és petit i valuosíssim: copia'l cada dia. /usr (estàtic, compartible) no cal copiar-lo, es reinstal·la amb el gestor de paquets. /var/log (variable) es copia o es rota segons la política de retenció.

2. Determina què es pot muntar com a només lectura. En servidors enfortits, /usr es munta en mode només lectura perquè no ha de canviar durant el funcionament. Qualsevol intent d'escriptura allà és senyal de compromís. /var i /etc, en canvi, han de poder escriure's.

3. Determina què necessita partició pròpia. El que és variable creix de manera impredictible: per això /var mereix la seva pròpia partició, com vam veure a la lliçó 01-04. El que és estàtic té mida acotada.

4. Determina on posar allò teu. I aquí hi ha l'aplicació directa: l'aplicació de Tramontana és estàtica (només canvia quan en Luis desplega una versió nova), la seva configuració és estàtica i no compartible, i els seus registres són variables i no compartibles. Tres naturaleses diferents que exigeixen tres ubicacions diferents. Ho tanquem a la secció 9.

Ja vas veure el principi a la lliçó 01-02. Ara toca veure'l funcionant.

A Linux, gairebé tot es presenta amb la mateixa interfície de fitxer, de manera que les mateixes syscalls (open, read, write, close) i les mateixes eines serveixen per a coses radicalment diferents.

Hi ha set tipus, i ls -l els identifica amb la primera lletra de cada línia:

Comprova-ho:

Fixa't en dos detalls reveladors:

• La primera lletra de cada línia és el tipus: l, -, d, c, b.
• A les línies de dispositiu, on els fitxers normals mostren la mida, hi apareixen dos números (1, 3 i 8, 0). Són els números major i menor: el major identifica quin controlador del nucli gestiona el dispositiu, i el menor quin d'ells és. Un dispositiu no té mida perquè no conté dades: és una porta a un controlador.

Tres fitxers de /dev que faràs servir constantment.

/dev/null — el forat negre. Tot el que hi escriguis desapareix; llegir-lo retorna el fi de fitxer immediatament.

No hi ha sortida. Cap de les dues operacions no produeix res.

La seva utilitat és diària: descartar la sortida que no interessa. Ja el vas fer servir sense saber-ho a la lliçó 01-04, quan vas verificar la ISO amb sha256sum -c SHA256SUMS 2>/dev/null per descartar els missatges d'error de les imatges no descarregades. La redirecció és la lliçó 03-04.

/dev/zero — la font infinita de zeros. Llegir-lo retorna bytes zero sense límit. Serveix per crear fitxers de mida fixa o per esborrar dades.

head -c 20 pren 20 bytes i od -c els mostra de manera llegible: vint zeros.

/dev/sda — el disc sencer. No és una metàfora: és el disc. El pots llegir byte a byte i, si ets root, escriure'l. És el que permetia a dd gravar una ISO en un USB a la lliçó 01-04, i també el que fa que aquella ordre sigui tan perillosa.

/dev/random i /dev/urandom generen dades aleatòries criptogràficament segures, i són la base de la generació de claus que veuràs al Mòdul 6.

Aquest llistat pot semblar una curiositat, però té una conseqüència que travessa tot el curs: les mateixes eines serveixen per a tot.

cat pot mostrar un fitxer de text, la informació del processador (/proc/cpuinfo) o els bytes d'un disc. grep pot buscar en un registre, en la sortida d'un altre programa o en un pseudo-fitxer del nucli. Redirigir la sortida d'un programa a un fitxer, a un dispositiu o a un altre programa és exactament la mateixa operació.

Quan al Mòdul 3 encadenis eines amb canonades, aquella uniformitat és el que ho fa possible. En un sistema on els discos, els processos i la xarxa tinguessin cadascun la seva API pròpia, caldrien programes diferents per a cada cosa.

/proc i /sys són l'aplicació més espectacular del principi anterior. No ocupen ni un sol byte al disc: són sistemes de fitxers virtuals que el nucli genera en memòria en el moment en què els llegeixes.

Cada vegada que obres /proc/meminfo, el nucli construeix aquell "fitxer" al vol amb l'estat actual de la memòria. És una interfície de consulta disfressada de sistema de fitxers.

Informació del processador:

grep -m1 mostra només la primera coincidència, perquè el fitxer repeteix la informació per a cada nucli.

Informació de memòria:

Aquí hi ha la dada interessant: d'aquí és exactament d'on free -h treu els seus números. free no és més que un programa que llegeix /proc/meminfo i el presenta de manera llegible. El mateix passa amb uptime i /proc/uptime, o amb ps i els directoris /proc/<pid>/.

Comprovar-ho canvia la manera de veure el sistema: les eines de diagnòstic no tenen poders especials, simplement llegeixen fitxers que tu també pots llegir.

Un procés concret. Cada procés en execució té un directori a /proc amb el seu número de PID:

/proc/1/ és el procés 1, és a dir, systemd. Què hi ha a dins:

(El tr '\0' ' ' substitueix els caràcters nuls que separen els arguments per espais, perquè sigui llegible.)

Altres fitxers útils de /proc:

/sys exposa dispositius i paràmetres del nucli, i molts dels seus fitxers són escrivibles. Canviar-ne un modifica el comportament del nucli a l'instant, sense reiniciar.

Aquell 0 significa que el reenviament de paquets IP està desactivat: el servidor no actua com a router. Activar-lo seria tan simple com escriure un 1 en aquell fitxer.

Aquest mecanisme és el que fa possible l'ajust fi del nucli, i és el tema de la lliçó 07-03. Es menciona aquí només perquè entenguis la naturalesa d'allò que estàs veient.

Advertiment clar: /proc i /sys són segurs per llegir — fes-ho sense por, és la millor manera d'entendre què fa el teu sistema. Escriure-hi sense saber què fas pot degradar el rendiment o desestabilitzar la màquina. Durant aquest mòdul, limita't a mirar.

A Linux, un fitxer el nom del qual comença per punt està ocult. No hi ha un atribut especial com a Windows: és només una convenció de nom que les eines respecten.

-a significa all. Hi apareixen molts més elements.

Els dos primers són especials i hi seran sempre, a qualsevol directori:

• . és el directori actual.
• .. és el directori pare.

No són un adorn: són entrades reals del directori, i són la base de les rutes relatives de la secció següent.

Els fitxers ocults habituals al teu directori personal:

El propòsit de la convenció és purament pràctic: la configuració personal es guarda al directori de l'usuari, però no ha de destorbar quan aquest llista els seus documents. Els programes posen la seva configuració amb punt al davant i desapareixen de la vista.

Un detall important que ja es dedueix de la taula: un directori ocult pot contenir fitxers perfectament visibles. .ssh està ocult, però ls -a ~/.ssh en mostra el contingut amb normalitat. Ocultar afecta l'element, no allò que hi ha a dins.

I un avís operatiu: en fer còpies de seguretat d'un directori personal, cal assegurar-se d'incloure els fitxers ocults. És una font clàssica de còpies incompletes en què es perd tota la configuració i les claus SSH.

Hi ha dues maneres d'anomenar un fitxer, i la distinció és tan simple com fonamental.

Ruta absoluta: parteix de l'arrel / i descriu el camí complet. És la mateixa sigui on sigui qui l'escrigui.

Ruta relativa: parteix del directori actual. El seu significat depèn d'on siguis.

Els símbols que es fan servir a les rutes:

Quan fer servir cadascuna:

La primera fila és la que més disgustos evita. Un script que fa servir la ruta relativa logs/acces.log funciona quan el proves des del teu directori, i falla misteriosament quan cron l'executa des d'un altre lloc. És un dels errors més freqüents en començar amb automatització, i hi tornarem a les lliçons 03-07 i 04-07.

L'ús pràctic de les rutes —moure's amb cd, saber on ets amb pwd, llistar amb ls— és la lliçó 02-03. Aquí només et calia la definició.

Arriba el moment d'aplicar tot el mapa. En Luis Ferrer està llest per desplegar Tramontana Reserves a srv-tramontana i et pregunta on posar cada cosa. La resposta no és una opinió: es dedueix de l'FHS i de la classificació estàtic/variable.

Anem una per una, perquè el raonament importa més que la conclusió.

Tramontana Reserves no ve dels repositoris d'Ubuntu: és programari propi que en Luis desplega manualment. L'FHS reserva /opt exactament per a això, amb la convenció /opt/<proveïdor>/<producte>.

És estàtica perquè només canvia quan es desplega una versió nova, no durant el funcionament. I és compartible: si demà hi hagués un segon servidor d'aplicació, tindria exactament el mateix contingut en aquella ruta.

Avantatge addicional de la naturalesa autocontinguda d'/opt: desinstal·lar és esborrar un directori, i fer còpia de l'aplicació és copiar un directori.

Alternativa descartada: /usr/local. És correcta per a programari compilat que s'integra al sistema, repartint binaris a /usr/local/bin i biblioteques a /usr/local/lib. Per a una aplicació web autocontinguda, /opt és més net.

Aquí hi van la cadena de connexió a la base de dades, els paràmetres de l'aplicació i les seves credencials. /etc és, per definició de l'FHS, la configuració estàtica específica d'aquesta màquina.

Aquesta última part és la clau, i és el que justifica separar la configuració de l'aplicació en lloc de deixar-la dins de /opt/tramontana/app/config:

• El servidor de proves i el de producció executen el mateix codi amb configuració diferent. Separar-los permet desplegar el mateix artefacte a tots dos.
• La còpia de seguretat d'/etc recull automàticament la configuració de tots els serveis, inclosa la nostra.
• En actualitzar l'aplicació (esborrant i recreant /opt/tramontana/app), la configuració no corre cap risc.
• La configuració conté secrets i necessita permisos restrictius, diferents dels del codi. Els permisos són la lliçó 02-07 i els secrets la 06-05.

acces.log i errors.log són l'exemple perfecte de dades variables: creixen contínuament sense intervenció de ningú.

Posar-los a /var/log no és una formalitat. Té conseqüències molt concretes:

• És on les eines de rotació de registres (logrotate) esperen trobar-los, per comprimir i eliminar els antics automàticament. Sense això, un registre creix fins a omplir el disc.
• És on qualsevol administrador mirarà primer en investigar un problema.
• Com vam veure a la lliçó 01-04, /var pot ser a la seva pròpia partició: si els registres es desboquen, el sistema arrel no se'n veu afectat.

Alternativa descartada: deixar-los dins de /opt/tramontana/app/logs, que és el que moltes aplicacions fan per defecte. És un error clàssic: barreja dades estàtiques amb variables, trenca la rotació automàtica, complica les còpies de seguretat i fa que un desbordament afecti la partició equivocada.

/srv és el directori per a dades que aquest servidor serveix o custodia, organitzades per servei.

I hi ha una raó operativa de pes per separar-les: en ser al seu propi directori de primer nivell, /srv/tramontana/backups es pot muntar en un disc físic diferent amb una sola línia a /etc/fstab, sense tocar ni una ruta dels scripts. És exactament l'escenari de la secció 2 sobre muntatge.

I això importa molt, perquè una còpia de seguretat al mateix disc que les dades originals protegeix contra l'esborrat accidental, però no contra la fallada del disc. L'estratègia completa de còpia és la lliçó 05-08.

Els scripts d'automatització que escriuràs al Mòdul 4 són teus: el teu directori personal és el seu lloc natural mentre els estàs desenvolupant.

Un matís professional que convé anticipar: quan un script deixa de ser un experiment i passa a ser part de l'operació —l'executa cron, en depèn una còpia de seguretat—, ja no hauria de viure en un directori personal. El seu lloc passa a ser /usr/local/bin o /opt/tramontana/bin, perquè si demà operador deixa d'existir o se li neteja el directori, l'operació no pot dependre d'això. Ho veurem a la lliçó 04-07.

Així queda srv-tramontana quan el desplegament estigui complet:

Cinc directoris, cinc naturaleses diferents, cinc justificacions. Qualsevol administrador de Linux del món entendria aquesta estructura sense que ningú l'hi expliqui. Això és el que aporta seguir un estàndard.

• Confondre /root amb /. / és l'arrel de l'arbre; /root és el directori personal de l'usuari root. Es pronuncien igual i són coses diferents.
• Buscar un «Program Files» de Linux. No existeix un únic lloc: el programari es reparteix segons la seva naturalesa (/usr/bin per a binaris de paquets, /opt per a aplicacions de tercers, /usr/local per al que es compila a mà, /etc per a la seva configuració).
• Instal·lar programari propi a /usr/bin. Aquell directori pertany al gestor de paquets. El que hi posis a mà pot ser sobreescrit o eliminat en una actualització. Fes servir /usr/local/bin o /opt.
• Deixar els registres dins del directori de l'aplicació. Trenca la rotació automàtica, barreja dades estàtiques amb variables i arrisca la partició equivocada.
• Guardar dades importants a /tmp. Es neteja en reiniciar i, en molts sistemes, també periòdicament. Si necessites temporals que sobrevisquin, fes servir /var/tmp.
• Escriure a /proc o /sys sense entendre què fa. Llegir-los és segur i educatiu; escriure'ls pot desestabilitzar el sistema a l'instant.
• Oblidar els fitxers ocults en copiar un directori personal. T'endús els documents i deixes enrere la configuració i les claus SSH. ls -a abans de copiar.
• Fer servir rutes relatives en scripts. Funcionen quan els proves i fallen quan els executa cron des d'un altre directori. En scripts, rutes absolutes.
• Consell. Quan dubtis on posar alguna cosa, fes-te dues preguntes: això canvia sol durant el funcionament? (si sí, va sota /var) i és específic d'aquesta màquina? (si sí, /etc per a configuració). Amb aquestes dues preguntes resols la majoria dels casos.
• Consell. Dedica una estona a explorar /etc, /var/log i /proc amb ls i cat. No hi ha risc a llegir, i la familiaritat amb el terreny s'adquireix recorrent-lo. És la millor inversió de temps abans de començar el Mòdul 2.
• Consell. L'FHS complet està publicat i és sorprenentment llegible. Quan tinguis un dubte real sobre on va alguna cosa, consultar-lo et dona una resposta amb autoritat, no una opinió.

Per a cada element, indica en quin directori s'hauria d'ubicar segons l'FHS, i justifica la resposta fent servir la classificació estàtic/variable i compartible/no compartible:

1. El certificat TLS del domini de Tramontana Reserves.
2. Una base de dades PostgreSQL amb les reserves.
3. Un script que la Marta executa cada matí per generar un informe.
4. El fitxer cases.txt amb el catàleg de cases rurals que l'aplicació serveix a les agències.
5. Un fitxer temporal de 3 GB generat durant una migració, que ha de sobreviure a un reinici.
6. Una versió d'nginx compilada a mà amb mòduls especials.

Executes ls -l en un directori i obtens aquesta sortida:

1. Identifica el tipus de cada element i explica com ho has determinat.
2. Per què dos d'ells mostren dos números on els altres mostren una mida? Què signifiquen aquests números?
3. Què passaria si esborressis l'element actual? I si esborressis /var/log/tramontana?

En Luis Ferrer et proposa aquesta estructura per desplegar Tramontana Reserves:

Argumenta, punt per punt, quatre problemes concrets d'aquesta proposta, i presenta l'estructura alternativa amb la seva justificació FHS. Per a cada problema, descriu un escenari real en què causaria un incident.

Solució a l'Exercici 1

1. Certificat TLS → /etc/ssl/certs/ (o /etc/tramontana/ssl/). Estàtic i no compartible. És configuració: només canvia quan es renova, i és específic d'aquesta màquina i del seu domini. Va a /etc per definició. La clau privada associada ha d'anar a /etc/ssl/private/ amb permisos molt restrictius, perquè qui l'obtingui pot suplantar el servidor. Es tracta a la lliçó 06-05.

2. Base de dades PostgreSQL → /var/lib/postgresql/. Variable i no compartible. Canvia contínuament amb cada reserva; és estat persistent d'un servei, que és exactament la definició de /var/lib. És la ubicació que PostgreSQL fa servir per defecte a Ubuntu, i respectar-la assegura que les eines de còpia i les polítiques de SELinux o AppArmor esperin trobar-la allà.

3. Script d'informe diari → /usr/local/bin/ (o /opt/tramontana/bin/). Aquest té matís. Mentre s'està desenvolupant, /home/operador/scripts està bé. Però l'enunciat diu que la Marta l'executa cada matí: és una eina operativa de la qual depèn algú més. Ha de passar a /usr/local/bin, que és el lloc de l'FHS per a executables locals afegits per l'administrador, amb dos avantatges: és al PATH de tots els usuaris (la Marta l'invoca pel seu nom, sense ruta) i no depèn que el compte operador continuï existint.

4. cases.txt servit a les agències → /srv/tramontana/. Variable i compartible. La paraula clau de l'enunciat és serveix: són dades que aquest servidor lliura a tercers, que és la definició literal de /srv a l'FHS. Si es servís exclusivament per web mitjançant nginx, /var/www/ també seria defensable; /srv és preferible quan les dades es serveixen per diversos canals o pertanyen conceptualment al servei.

5. Temporal de 3 GB que sobreviu al reinici → /var/tmp/. Els dos requisits apunten al mateix lloc. /tmp queda descartat perquè es buida en reiniciar (i en molts sistemes és un tmpfs a la RAM, on 3 GB serien un problema seriós de memòria). /var/tmp està pensat precisament per a temporals persistents entre reinicis, i és al disc.

6. nginx compilat a mà → /usr/local/. Estàtic i compartible. /usr/local és l'arbre paral·lel reservat al programari que l'administrador compila i instal·la manualment: el binari a /usr/local/sbin/nginx, la configuració a /usr/local/etc/nginx/. La seva raó de ser és no col·lidir amb /usr, que pertany al gestor de paquets: així una actualització d'Ubuntu no sobreescriurà mai la teva compilació, i la teva compilació no trencarà mai el paquet oficial.

Solució a l'Exercici 2

1. Tipus, determinats per la primera lletra de cada línia:

Detalls que confirmen cada lectura: l'enllaç mostra -> /var/log/tramontana i té permisos rwxrwxrwx (els enllaços simbòlics sempre els tenen; els que compten són els del destí). El dispositiu de bloc pertany al grup disk, l'habitual als discos. I buit amb números 1, 3 és en realitat /dev/null: aquests són els seus números major i menor característics.

2. Els dos números.

Els mostren disc-dades (8, 16) i buit (1, 3), els dos dispositius. En un fitxer normal, aquella columna indica la mida en bytes; un dispositiu no té mida perquè no conté dades: és una porta d'accés a un controlador del nucli.

En lloc seu hi apareixen:

• El número major identifica el controlador del nucli que gestiona el dispositiu. El 8 correspon als discos SCSI/SATA; l'1 als dispositius de memòria, entre els quals hi ha /dev/null.
• El número menor identifica quin dels dispositius que gestiona aquell controlador és. El 16 correspon a /dev/sdb (el 0 seria /dev/sda); el 3 a /dev/null concretament.

És a dir, disc-dades és el segon disc del sistema i buit és el forat negre.

3. Conseqüències d'esborrar.

Si esborres actual: no passa res rellevant. Un enllaç simbòlic és només un punter, un fitxer diminut que conté una ruta com a text. Esborrar-lo elimina la drecera; el directori /var/log/tramontana i tot el seu contingut continuen intactes. Pots recrear l'enllaç en un segon.

Si esborres /var/log/tramontana: perds els registres de debò. I a més l'enllaç actual queda trencat (dangling): continua existint i apuntant a una ruta que ja no existeix. Qualsevol programa que intenti seguir-lo rebrà un error del tipus «No such file or directory», cosa que resulta confusa perquè l'enllaç sí que apareix en llistar el directori.

Els enllaços trencats es detecten fàcilment perquè ls els mostra en vermell parpellejant a la majoria de terminals amb color.

Aquesta asimetria —l'enllaç depèn del destí, el destí no depèn de l'enllaç— és la característica essencial dels enllaços simbòlics, i explica en què es diferencien dels enllaços durs. És el tema de la lliçó 02-06.

Solució a l'Exercici 3

Problema 1: tot penja d'un directori personal.

Tota la infraestructura de producció depèn de l'existència del compte luis. /home està reservat a dades personals d'usuaris, no a serveis.

Escenari d'incident: en Luis deixa l'empresa. Se segueix el procediment normal de baixa: eliminar el compte amb userdel -r, que esborra el directori personal. S'esborra l'aplicació en producció, la seva configuració, els seus registres i les seves còpies de seguretat, tot alhora. Ningú no va relacionar donar de baixa un empleat amb destruir el servei, perquè en un sistema ben organitzat no hi ha per què haver-hi relació.

Un incident equivalent i més silenciós: els permisos de /home/luis restringeixen l'accés, i l'usuari del servei web (www-data) no pot llegir l'aplicació. S'acaba resolent amb permisos massa oberts sobre un directori personal, cosa que obre un forat de seguretat.

Problema 2: els registres conviuen amb l'aplicació.

logs/ és dins del mateix arbre que app/, barrejant dades variables amb dades estàtiques.

Escenari d'incident: una fallada al codi provoca un bucle que escriu a errors.log sense parar. El registre creix fins a omplir la partició que conté /home, que en moltes instal·lacions és la mateixa que /. Amb el disc arrel ple, el sistema no pot escriure fitxers temporals: els serveis comencen a fallar en cascada, journald no pot registrar res i pot ser que ni tan sols es pugui iniciar sessió per diagnosticar-ho. Amb els registres a /var/log i /var a la seva pròpia partició, el dany hauria quedat contingut.

Segon efecte: logrotate no gestiona aquells registres, perquè no són on espera. Ningú no els comprimeix ni els elimina, així que creixen indefinidament.

Problema 3: la configuració és dins de l'aplicació.

config/app.conf penja del mateix arbre que el codi.

Escenari d'incident: en Luis desplega la versió 2.0 esborrant i recreant el directori tramontana/. Es perd app.conf amb la cadena de connexió a la base de dades i les credencials. El servei no arrenca i cal reconstruir la configuració de memòria, en plena caiguda, amb la pressió de tenir el servei aturat.

Problema estructural associat: en no estar separada, no es pot desplegar el mateix artefacte a proves i a producció amb configuracions diferents. S'acaben mantenint dues còpies divergents del codi, que és com apareixen les fallades que «només passen en producció».

Problema 4: les còpies són al mateix arbre que les dades.

backups/ és dins de /home/luis/tramontana/, és a dir, al mateix disc i sota el mateix directori que protegeix.

Escenari d'incident: falla el disc. Es perden alhora les dades originals i totes les còpies de seguretat. També n'hi ha prou amb un rm -rf mal dirigit sobre /home/luis/tramontana/: s'emporta per davant l'objecte de la còpia i la còpia mateixa.

Una còpia de seguretat que comparteix destí amb l'original protegeix únicament contra l'esborrat selectiu d'un fitxer. No protegeix contra la fallada de maquinari, ni contra un esborrat ampli, ni contra un xifratge per ransomware, que són precisament els escenaris que justifiquen tenir còpies.

Estructura alternativa:

Com presentar-l'hi a en Luis (perquè tenir raó no n'hi ha prou): l'argument que convenç no és «l'FHS ho diu», sinó els quatre escenaris d'incident. L'estructura correcta no és més burocràtica: és la que fa que donar de baixa un empleat no tombi el servei, que un registre desbocat no ompli el disc arrel, que un desplegament no esborri les credencials i que les còpies serveixin d'alguna cosa quan falli el disc. A més, costa el mateix muntar-la bé des del principi que muntar-la malament.

Amb aquesta lliçó tanques el Mòdul 1 i tens el mapa complet del territori:

• Linux organitza l'emmagatzematge en un únic arbre des de /, no en unitats separades, i el muntatge és el que connecta dispositius a punts d'aquell arbre, separant l'estructura lògica de la disposició física.
• L'FHS defineix què va a cada directori i és el que fa predictible qualsevol sistema Linux: /etc per a la configuració, /var per al que creix, /usr per al programari del sistema, /opt per a aplicacions de tercers, /srv per al que se serveix, /home per als usuaris.
• La classificació estàtic/variable i compartible/no compartible no és teoria: determina què copies, què muntes en només lectura, què necessita partició pròpia i on col·loques allò teu.
• Tot és un fitxer, i ls -l et diu de quin tipus per la seva primera lletra: -, d, l, c, b, s, p. Els dispositius com /dev/null, /dev/zero i /dev/sda són portes a controladors del nucli.
• /proc i /sys no ocupen disc: són finestres al nucli generades al vol, i són la font de la qual beuen eines com free, uptime i ps.
• Els fitxers ocults són només una convenció de nom, i . i .. són entrades reals de cada directori.
• Les rutes absolutes parteixen de / i són les que has de fer servir en scripts; les relatives parteixen d'on siguis i són còmodes quan treballes a mà.
• I saps justificar, amb l'estàndard a la mà, per què Tramontana Reserves va a /opt/tramontana/app, la seva configuració a /etc/tramontana/, els seus registres a /var/log/tramontana/, les seves còpies a /srv/tramontana/backups i els teus scripts a /home/operador/scripts.

Fes balanç d'on eres en començar el mòdul i on ets ara. Saps què és Linux i què és exactament el nucli; coneixes la filosofia Unix que explica el disseny de tot el que veuràs; entens el panorama de distribucions i per què Ubuntu Server 24.04 LTS és l'elecció correcta per a srv-tramontana; tens el servidor instal·lat, verificat, actualitzat i amb instantànies; saps llegir el prompt, executar ordres bàsiques i fer el reconeixement d'una màquina; i tens el mapa complet del seu sistema de fitxers. Això és un laboratori funcionant i un vocabulari comú amb qualsevol administrador de sistemes.

Fins ara has mirat. Al Mòdul 2: Ordres Bàsiques començaràs a treballar de debò: aprendràs a manejar la línia d'ordres amb soltesa, a consultar la documentació del sistema per no dependre de cercadors, a navegar per l'arbre de directoris que acabes de conèixer, a crear, copiar, moure i esborrar fitxers, a veure i editar-ne el contingut, a manejar enllaços durs i simbòlics, i a dominar els permisos i la propietat, que és la peça que separa un servidor que funciona d'un servidor que a més és segur. Prepara la teva instantània, obre una sessió a srv-tramontana i ens veiem a la primera lliçó.