L'utilisation d'un système de fichiers racine en lecture seule est-elle une bonne idée pour la configuration intégrée?

J'ai été chargé d'exécuter Linux en tant que système d'exploitation sur un périphérique intégré.

La cible dispose d'un processeur x86 et d'un périphérique CompactFlash de 8 Go pour le stockage.

J'ai réussi à utiliser buildroot pour créer l'image du noyau et les outils de compilation croisée. J'ai partitionné le périphérique CF en une petite partition FAT où réside l'image du noyau ainsi que la syslinuxconfiguration de démarrage et un ext3système de fichiers où j'ai décompressé le système de fichiers racine généré par buildroot.

Le système démarre avec succès syslinuxen définissant le répertoire racine sur la partition CF ext3 où se trouve mon système de fichiers racine.

Ma question est centrée sur le besoin de robustesse face à une perte de puissance immédiate (et fréquente) car il est crucial que l'appareil démarre correctement après une panne de courant. J'ai lu que le montage du système de fichiers racine en lecture seule est un moyen d'assurer l'intégrité des données. Est-ce une façon raisonnable pour moi de procéder?

J'ai également lu la possibilité de charger le système de fichiers racine dans la RAM pour obtenir la même chose, mais je ne sais pas encore comment le faire.

Existe-t-il une manière préférée d'atteindre cet objectif et si oui, quelle est la meilleure façon pour moi de procéder?

Nouvelle réponse (2015-03-22)

( Remarque: cette réponse est plus simple que la précédente, mais pas plus sécurisée. Ma première réponse est plus forte car vous pouvez conserver les fichiers en lecture seule par les options de montage fs avant les drapeaux d'autorisation. Ainsi, forcer l' écriture d'un fichier sans autorisation d'écriture ne fonctionnera pas du tout.)

Oui, sous Debian , il y a un paquet: fsprotect ( page d'accueil ).

Il utilise aufs(par défaut, mais pourrait utiliser un autre unionfsoutil) pour permettre les changements de session en direct mais en RAM par défaut, donc tout est oublié au redémarrage.

Vous pouvez les installer en exécutant simplement:

apt-get install fsprotect

Une fois terminé, à partir du document en ligne:

Après ça:

• Modifier /boot/grub/menu.lstou /etc/default/grub2ou /etc/lilo.confet ajouter "fsprotect=1G " aux paramètres du noyau.
• Modifiez 1G selon vos besoins.
• Appliquer les modifications (c'est-à-dire exécuter update-grub )
• Modifier /etc/default/fsprotectsi vous souhaitez protéger des systèmes de fichiers autres que/ .
• redémarrer

Vous pouvez également vouloir protéger par mot de passe le chargeur de démarrage grub ou interdire toute modification de celui-ci.

De là, si un fichier est protégé contre les modifications, par exemple par

chmod ugo-w myfile

si vous utilisez pour exemple vi myfileet essayez d'écrire dessus avec la commande :w!, cela fonctionnera et votre myfilesera changé. Vous pouvez redémarrer afin de récupérer non modifiémyfile .

Ce n'est même pas possible avec ma première solution suivante:

Ancienne (première) réponse:

Oui, c'est une solution solide, mais puissante!

Rendre o / utilisable

Vous devez monter certains répertoires dans rw , comme /var, /etcet peut-être /home. Cela pourrait être fait en utilisant aufs ou unionfs . J'aime ça autrement , en utilisant /dev/shmet mount --bind:

cp -a /var /dev/shm/
mount --bind /dev/shm/var /var

Vous pourriez auparavant, déplacer tous les répertoires qui ne doivent pas changer en fonctionnement normal dans a static-var, que créer des liens symboliques dans / var:

mkdir /static-var
mkdir /static-var/cache
mkdir /static-var/lib
mv /var/lib/dpkg /static-var/lib/dpkg
ln -s /static-var/lib/dpkg /var/lib/dpkg
mv /var/cache/apt /static-var/cache/apt
ln -s /static-var/cache/apt /var/cache/apt
... # an so on

Alors , quand à remontage ro, la copie /varen /dev/shmne prendra pas trop de place que la plupart des fichiers sont déplacés vers/static-var et que les liens symboliques doivent être copiés dans la RAM.

La meilleure façon de le faire finement est de faire un cycle d'alimentation complet, une journée de travail complet et d'exécuter finement une commande comme:

find / -type f -o -type f -mtime -1

Vous verrez donc quels fichiers doivent être situés sur une partition en lecture-écriture.

Enregistrement

Comme il n'y a pas de mémoire statique inscriptible sur cet hôte, pour stocker l'historique et les autres journaux, vous devez configurer un syslogserveur distant .

echo >/etc/syslog.conf '*.* @mySyslogServer.localdomain'

De cette façon, si votre système tombe en panne pour une raison quelconque, tout ce qui précède est enregistré.

Mise à niveau

Lors de l'exécution avec certains mount --bindutilisateurs, pour effectuer une telle mise à niveau pendant que le système est en cours d'utilisation (sans avoir besoin de s'exécuter init 1, pour réduire les temps d'arrêt), le moyen le plus simple consiste à reconstruire une racine propre , capable de faire la mise à niveau:

Après avoir remonté '/' en mode lecture-écriture :

mount -o remount,rw /

for mpnt in /{,proc,sys,dev{,/pts}};do
    mount --bind $mnpt /$mnt$mpnt;
    done

chroot /mnt

apt-get update && apt-get dist-upgrade

exit

umount /mnt/{dev{/pts,},proc,sys,}

sync
mount -o remount,ro /

Et maintenant:

shutdown -r now

Je n'ai d'expérience qu'avec une buildroot plus récente (2014-02). Dans cette version, vous pouvez désactiver «remonter le démarrage en lecture-écriture du système de fichiers racine» dans le fichier de configuration avec:

BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW n'est pas défini

J'ai réussi à créer une image qui utilise simplement sa partition ext4 / en lecture seule, donc débrancher la puissance du système ne nuit pas du tout. Cela fonctionne très bien, donc si vous n'avez pas besoin d'écrire sur votre système de fichiers, c'est peut-être une solution beaucoup plus simple que celle mentionnée ci-dessus (qui semble plus ou moins applicable à un système Debian car elle se réfère à apt-get).