8.9. Altres configuracions: sincronització de temps, registres, accés compartit…

Els molts elements enumerats en aquesta secció són bons de saber per a qualsevol que vulgui dominar tots els aspectes de la configuració del sistema GNU/Linux. No obstant això, són tractats breument i sovint us adreçaran cap a la documentació.

8.9.1. Fus horari

TORNAR A LES BASES Enllaços simbòlics

Un enllaç simbòlic és un punter a un altre fitxer. Quan l'accediu, s'obre el fitxer al qual apunta. L'eliminació de l'enllaç no provocarà la supressió del fitxer al qual apunta. De la mateixa manera, no té el seu propi conjunt de permisos, sinó que té els permisos del fitxer apuntat. Finalment, pot apuntar a qualsevol tipus de fitxer: directoris, fitxers especials («sockets», «named pipes» o canonades amb nom , fitxers de dispositiu, etc.), fins i tot altres enllaços simbòlics.

L'ordre ln -s objectiu nom-enllaç crea un enllaç simbòlic, anomenat nom-enllaç, que apunta a l'objectiu.

Si l'objectiu no existeix, llavors l'enllaç està “trencat” i accedir-hi donarà lloc a un error indicant que el fitxer de destinació no existeix. Si l'enllaç apunta a un altre enllaç, tindreu una “cadena” d'enllaços que es converteix en un “cicle” si un dels objectius apunta a un dels seus predecessors. En aquest cas, l'accés a un dels enllaços del cicle donarà lloc a un error específic (“massa nivells d'enllaços simbòlics”); això significa que el nucli renuncia a continuar després de diverses voltes al cicle.

La zona horària, configurada durant la instal·lació inicial, és un element de configuració per al paquet tzdata. Per modificar-la, utilitzeu l'ordre dpkg-reconfigure tzdata, que permet triar de manera interactiva la zona horària que s'utilitzarà. La configuració s'emmagatzema al fitxer /etc/timezone. Addicionalment, /etc/localtime esdevé un enllaç simbòlic cap al fitxer corresponent de /usr/share/zoneinfo; el fitxer que conté les regles que regeixen les dates en què l'horari d'estiu està actiu (DST), per als països que l'utilitzen.

Quan calgui canviar temporalment la zona horària, utilitzeu la variable d'entorn TZ, que té prioritat sobre el valor predeterminat del sistema configurat:

$ date
Mon Jul 29 07:53:36 PM EDT 2024
$ TZ="Pacific/Honolulu" date
Mon Jul 29 01:54:00 PM HST 2024

NOTA Rellotge del sistema, rellotge de maquinari

Hi ha dues fonts del temps en un ordinador. La placa base d'un ordinador té un rellotge de maquinari («hardware clock»), anomenat “rellotge CMOS”. Aquest rellotge no és molt precís i té uns temps d'accés bastant lents. El nucli del sistema operatiu té el seu rellotge propi, el rellotge de programari, que manté actualitzat amb els seus propis mitjans (possiblement amb l'ajuda de servidors de temps, vegeu Secció 8.9.2, «Sincronització del temps»). Aquest rellotge de sistema és generalment més precís, especialment perquè no necessita accés a variables de maquinari. No obstant això, com que només existeix en memòria, es perd cada vegada que la màquina s'inicia, contràriament al rellotge CMOS, que té una bateria i, per tant, “sobreviu” als reinicis o aturades de la màquina. El rellotge del sistema, per tant, s'estableix a partir del rellotge CMOS durant l'arrencada, i aquest és actualizat a l'aturada (per tenir en compte possibles canvis o correccions si s'ha ajustat incorrectament).

A la pràctica hi ha un problema, ja que el rellotge CMOS no és més que un comptador i no conté informació sobre la zona horària. Hi ha una elecció a fer respecte a la seva interpretació: o bé el sistema considera que funciona en temps universal (UTC, anteriorment GMT), o en temps local. Aquesta tria podria ser un simple canvi, però les coses són realment més complicades: com a resultat de l'horari d'estiu, aquest desplaçament no és constant. El resultat és que el sistema no té manera de determinar si el desplaçament és correcte, especialment prop dels períodes de canvis d'hora. Com que sempre és possible reconstruir l'hora local a partir de l'hora universal i la informació de la zona horària, recomanem fermament tenir el rellotge CMOS en l'hora universal.

Malauradament, els sistemes Windows en la seva configuració per defecte ignoren aquesta recomanació; mantenen el rellotge CMOS en l'hora local, aplicant els canvis d'hora en arrencar l'ordinador intentant endevinar durant els canvis de temps si el canvi ja s'ha aplicat o no. Això funciona relativament bé, sempre que el sistema només tingui Windows instal·lat. Però quan un ordinador té diversos sistemes (ja sigui una configuració d'“arrencada dual” o executant altres sistemes a través de màquines virtuals) es produeix el caos, sense mitjans per determinar si el temps és correcte. Si heu de conservar absolutament Windows en un ordinador, hauríeu de configurar-lo per mantenir el rellotge CMOS com a UTC (configurant la clau de registre HKLM\ControlControl\Control\Control\Control\FinalTimeIsUniversal a “1” com a DWORD), o utilitzar hwclock --localtime --set al sistema Debian per establir el rellotge de maquinari i indicar que està configurat amb l'hora local (i assegurar-vos de comprovar manualment el temps a la primavera i la tardor).

8.9.2. Sincronització del temps

La sincronització temporal, que pot semblar supèrflua en un ordinador, és molt important en una xarxa. Atès que els usuaris no tenen permisos que els permetin modificar la data i l'hora, és important que aquesta informació sigui precisa per a evitar confusions. A més, tenir tots els ordinadors sincronitzats en una xarxa permet una millor referència creuada de la informació dels registres en diferents màquines. Per tant, en cas d'atac, és més fàcil reconstruir la seqüència cronològica d'accions en les diferents màquines implicades en el compromís. Les dades recollides en diverses màquines amb finalitats estadístiques no tindran molt sentit si no estan sincronitzades.

TORNAR A LES BASES NTP

NTP («Network Time Protocol» o Protocol del Temps en Xarxa) permet a una màquina sincronitzar-se amb d'altres amb bastanta precisió, tenint en compte els retards induïts per la transferència d'informació sobre la xarxa i altres possibles desviacions.

Encara que hi ha nombrosos servidors NTP a Internet, els més populars poden estar sobrecarregats. Per això recomanem l'ús del servidor NTP de pool.ntp.org, que és, en realitat, un grup de màquines que han acordat servir com a servidors NTP públics. Fins i tot es podria reduir l'ús a un subgrup específic d'un país, amb, per exemple, us.pool.ntp.org per als Estats Units, o ca.pool.ntp.org per al Canadà, etc.

No obstant això, si es gestiona una xarxa gran, es recomana que instal·lar un servidor NTP propi, que se sincronitzarà amb els servidors públics. En aquest cas, totes les altres màquines de la vostra xarxa poden utilitzar el vostre servidor NTP intern en lloc d'augmentar la càrrega als servidors públics. També augmentarà l'homogeneïtat dels rellotges, ja que totes les màquines es sincronitzaran en la mateixa font, i aquesta font és molt propera en termes de temps de transferència de xarxa.

8.9.2.1. Per a estacions de treball

Since work stations are regularly rebooted (even if only to save energy), synchronizing them by NTP at boot is enough. To do so, simply install either the ntpdate or the systemd-timesyncd package. You can then change the NTP server used if needed by modifying the /etc/default/ntpdate or the /etc/systemd/timesyncd.conf file.

8.9.2.2. Per a servidors

Els servidors rarament es reinicien, i és molt important que el seu temps de sistema sigui correcte. Per mantenir permanentment el temps correcte, instal·leu un servidor NTP local, un servei ofert al paquet ntp. En la seva configuració per defecte, el servidor se sincronitzarà amb pool.ntp.org i proporcionarà el temps en resposta a les peticions procedents de la xarxa local. Podeu configurar-ho editant el fitxer /etc/ntp.conf; l'alteració més important és el servidor NTP al qual es refereix. Si la xarxa té molts servidors, pot ser interessant tenir un servidor horari local que sincronitzi amb els servidors públics i que sigui utilitzat com a font d'hora pels altres servidors de la xarxa.

8.9.3. Rotació de fitxers de registre

Els fitxers de registre poden créixer, ràpidament, i és necessari arxivar-los. L'esquema més comú és un arxivat de rotació: el fitxer de registre s'arxiva regularment, i només es mantenen els últims X arxius. logrotate, el programa responsable d'aquestes rotacions, segueix les directives donades al fitxer /etc/logrotate.conf i tots els fitxers al directori /etc/logrotate.d/. L'administrador pot modificar aquests fitxers si desitja adaptar la política de rotació de registres definida per Debian. La pàgina man logrotate(1) descriu totes les opcions disponibles en aquests fitxers de configuració. És possible que vulgueu augmentar el nombre de fitxers retinguts en la rotació del registre, o moure els fitxers de registre a un directori específic dedicat a arxivar-los en lloc de suprimir-los. També els podeu enviar per correu electrònic per arxivar-los en un altre lloc.

El programa logrotate és executat diàriament pel programa de planificació cron (descrit a Secció 9.7, «Planificació de tasques amb cron i atd»).

8.9.4. Compartir els permisos d'administrador

Sovint diversos administradors treballen a la mateixa xarxa. No és molt elegant compartir les contrasenyes de l'usuari «root», obrint-se la porta de l'abús a causa de l'anonimat que crea aquesta compartició. La solució a aquest problema és el programa sudo, que permet a certs usuaris executar certes ordres amb drets especials. En el cas d'ús més comú, sudo permet a un usuari de confiança executar qualsevol ordre com a «root». Per fer-ho, l'usuari simplement executa l'ordre sudo command i s'autentica utilitzant la pròpia contrasenya personal.

When installed, the sudo package gives full root rights to members of the sudo Unix group. To delegate other rights, the administrator can use the visudo command, which allows them to modify the /etc/sudoers configuration file (here again, this will invoke the vi editor, or any other editor indicated in the EDITOR environment variable). Alternatively, they might put rules in small files in /etc/sudoers.d/ with the file permissions 0440 as long as this directory is included by /etc/sudoers via @includedir /etc/sudoers.d, which is the default for Debian. Adding a line with username ALL=(ALL) ALL allows the user in question to execute any command as root. The permissions and syntax of all files can be verified with the visudo -c command.

Configuracions més sofisticades permeten l'autorització de només ordres específiques a usuaris específics. Tots els detalls de les diferents possibilitats es donen a la pàgina del manual de sudoers(5).

8.9.5. Llista de punts de muntatge

TORNAR A LES BASES Muntar i desmuntar

In a Unix-like system such as Debian, files are organized in a single tree-like hierarchy of directories. The / directory is called the “root directory”; all additional directories are sub-directories within this root. “Mounting” is the action of including the content of a peripheral device (often a hard drive) into the system's general file tree. As a consequence, if you use a separate hard drive to store users' personal data, this disk will have to be “mounted” in the /home/ directory (during installation you already made relevant choices, see Secció 4.2.13.1, «Particionat guiat»). The root filesystem is always mounted at boot by the kernel; other devices are often mounted later during the startup sequence or manually with the mount command.

Alguns dispositius extraïbles es munten automàticament quan són connectats, especialment quan s'utilitza GNOME, Plasma o altres entorns d'escriptori gràfics. Altres han de ser muntats manualment per l'usuari. De la mateixa manera, s'han de desmuntar (eliminat de l'arbre de fitxers). Els usuaris normals no solen tenir permís per executar les ordres mount i umount. L'administrador pot, però, autoritzar aquestes operacions (independentment per a cada punt de muntatge) incloent l'opció user al fitxer /etc/fstab.

The mount command can be used without arguments to list all mounted filesystems (as found in /proc/mounts as well); you can execute findmnt --fstab to show only the filesystems from /etc/fstab. The following parameters are required to mount or unmount a device - for the complete list, please refer to the corresponding man pages, mount(8) and umount(8). For simple cases, the syntax is simple too: for example, to mount the /dev/sdc1 partition, which has an ext3 filesystem, into the /mnt/tmp/ directory, you would simply run mount -t ext3 /dev/sdc1 /mnt/tmp/. In fact, in most cases it is even not necessary to define the filesystem anymore because it is detected automatically.

El fitxer /etc/fstab proporciona una llista de tots els muntatges possibles que es produeixen automàticament a l'arrencada, o manualment per a dispositius d'emmagatzematge extraïbles. Cada punt de muntatge és descrit per una línia amb diversos camps separats per espais:

sistema de fitxers: això indica on es troba el sistema de fitxers que s'ha de muntar, pot ser un dispositiu local (partició de disc dur, CD-ROM) o un sistema de fitxers remot (com ara NFS o fins i tot SSHFS).
Aquest camp se substitueix freqüentment amb l'identificador (“ID”) únic del sistema de fitxers (que podeu determinar amb blkid dispositiu) prefixat amb UUID=. Això protegeix contra un canvi en el nom del dispositiu en cas d'afegir o treure de discos, o si els discs són detectats en un ordre diferent. Secció 8.8.1, «Identificació dels discos» cobreix aquest punt amb més detall.
punt de muntatge: aquesta és la ubicació del sistema de fitxers local on es muntarà el dispositiu, el sistema remot o la partició.
tipus: aquest camp defineix el sistema de fitxers utilitzat en el dispositiu muntat. ext4, ext3, vfat, ntfs, btrfs, xfs en són alguns exemples.
TORNAR A LES BASES NFS, un sistema de fitxers de xarxa
NFS és un sistema de fitxers de xarxa; amb Linux, permet l'accés transparent a fitxers remots incloent-los al sistema de fitxers local.
Hi ha disponible una llista completa dels sistemes de fitxers coneguts a la pàgina del manual de mount(8). El valor especial swap és per a les particions d'intercanvi; el valor especial auto li indica a mount que detecti automàticament el sistema de fitxers (fet que és especialment útil per als lectors de disc i les claus USB, ja que cadascun podria tenir un sistema de fitxers diferent);
opcions: n'hi ha moltes, depenent del sistema de fitxers, i estan documentades a la pàgina man de mount. Les més comunes són
- rw o ro que signifiquen, respectivament, que el dispositiu es muntarà amb permisos de lectura/escriptura o de només lectura.
- noauto desactiva el muntatge automàtic a l'arrencada.
- nofail permet que l'arrencada continuï fins i tot quan el dispositiu no estigui present. Assegureu-vos de posar aquesta opció per a les unitats externes que podrien estar desconnectades quan arrenqueu, perquè systemd realment garanteix que tots els punts de muntatge que s'han de muntar automàticament es muntin realment abans de permetre que el procés d'arrencada continuï fins al final. Tingueu en compte que podeu combinar això amb x-systemd.device-timeout=5s per dir-li a systemd que no esperi més de 5 segons perquè el dispositiu aparegui (vegeu systemd.mount(5)).
- user autoritza a tots els usuaris a muntar aquest sistema de fitxers (una operació que d'altra manera estaria restringida a l'usuari «root»).
- defaults significa el grup d'opcions per defecte: rw, suid, dev, exec, auto, nouser i async, cadascuna de les quals es pot desactivar individualment després de defaults afegint nosuid, nodev etc. i així blocar suid, dev, etc. Afegir l'opció user la reactiva, ja que defaults inclou nouser.
dump: aquest camp gairebé sempre està establert a 0 i és una mena de relíquia. Quan és més gran que zero, indica a l'eina dump que la partició conté dades de que s'han de fer còpies de seguretat amb freqüència. L'eina només admet sistemes de fitxers Ext2/3/4 i usarà el valor aquest valor quan s'executi mitjançant dump -W o dump -w per determinar de quines particions s'han de fer còpies de seguretat. Considereu els exemples de /usr/share/doc/dump/examples/ si voleu utilitzar aquesta característica. Però hi ha millors alternatives per fer una còpies de seguretat d'un sistema de fitxers, com fsarchiver.
pass: aquest últim camp indica si la integritat del sistema de fitxers s'ha de comprovar a l'arrencada, i en quina ordre s'ha d'executar aquesta comprovació. Si és 0, no es fa cap comprovació. El sistema de fitxers arrel ha de tenir el valor 1, mentre que altres sistemes de fitxers permanents tenen el valor 2.

Exemple 8.5. Exemple de fitxer /etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system>                           <mount point>   <type>      <options>         <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=7a250fb8-c16d-4a4e-9808-ec08ae92b6c6 /               ext4        errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=13f367ae-dbaf-40ed-85c0-4072a2ebe426 none            swap        sw                0       0
/dev/sr0                                  /media/cdrom0   udf,iso9660 user,noauto       0       0
/dev/fd0                                  /media/floppy   auto        rw,user,noauto    0       0
arrakis:/shared                           /shared         nfs         defaults          0       0

L'última entrada de l'exemple correspon a un sistema de fitxers de xarxa (NFS): el directori /shared/ del servidor arrakis està muntat a /shared/ a la màquina local.

El format del fitxer /etc/fstab està documentat a la pàgina del manual de fstab(5).

ANANT MÉS ENLLÀ Muntatge automàtic

systemd és capaç de gestionar punts de muntatge automàtic: aquests són sistemes de fitxers que es munten a la carta quan un usuari intenta accedir als seus punts de muntatge de destinació. També pot desmuntar aquests sistemes de fitxers quan ja no hi ha cap procés que hi accedeixi.

Com la majoria de conceptes de systemd, els punts de muntatge automàtic es gestionen amb unitats dedicades, utilitzant el sufixe .automount). Vegeu systemd.automount(5) per a la sintaxi precisa.

Other auto-mounting utilities exist, such as automount in the autofs package.

Tingueu en compte també que el GNOME, el Plasma i altres entorns d'escriptori gràfics funcionen conjuntament amb udisks2 i poden muntar automàticament suports extraïbles quan són connectats.

8.9.6. `locate` i `updatedb`

L'ordre locate pot trobar la ubicació d'un fitxer quan només se'n coneix una part del nom. Dóna un resultat gairebé instantàniament, ja que consulta una base de dades que emmagatzema la ubicació de tots els fitxers del sistema; aquesta base de dades s'actualitza diàriament amb l'ordre updatedb. Hi ha múltiples implementacions de l'ordre locate i mlocate és el seleccionat per Debian per al seu sistema estàndard. Si voleu considerar una alternativa, podeu provar plocate que ofereix les mateixes opcions de línia de comandes i es pot considerar com un equivalent.

locate és prou intel·ligent com per retornar només els fitxers que són accessibles a l'usuari executant l'ordre tot i que utilitza una base de dades amb informació de tots els fitxers del sistema (ja que la seva implementació d'updatedb funciona amb permisos de «root»). Per seguretat addicional, l'administrador pot utilitzar PRUNEDPATHS a /etc/updatedb.conf per evitar indexar alguns directoris.