symlinks avant / arrière: pratique administrative?

Je me request comment les autres personnes se sentent à propos des liens symésortingques: sont-ils sécuritaires? Bonnes pratiques? Dépend?

La raison pour laquelle je request est qu'apparemment dans le monde de bureau Linux, il semble y avoir une poussée par divers distros pour combiner / usr / bin avec / bin.

J'ai demandé pourquoi, mais je n'ai pas eu de bonnes réponses à part faire un appel "exec" pour charger des programmes et ne pas avoir à chercher PATH (ce qui, pour moi, semble une chose plutôt négligeable à faire).

Donc, ils ne veulent pas chercher path et toujours utiliser / usr / bin / – ok, pourquoi ne pas simplement mettre les liens symboliques dans / usr / bin pointant vers / bin? (FWIW, ce n'est pas seulement "bin", mais aussi sbin, lib et lib64).

Au lieu d'utiliser des backlinks, ma distro courante actuelle a choisi de déplacer les binarys de la partition racine vers / dedans / usr et, lorsqu'ils déplacent des files depuis / [s] bin et les libs vers / usr / [s] mettre en avant des liens depuis les directorys basés sur la racine vers les files dans / usr.

Je n'ai aucune raison, pourquoi ils ont décidé de déplacer des choses de la partition racine vers / usr, mais je pensais que c'était le bon sens, dans le cas de files critiques (comme ceux nécessaires pour le démarrage), de ne jamais utiliser de liens à un système de files qui pourrait ne pas être monté au moment où vous pouvez referencer les liens symboliques.

C'est-à-dire que les liens dans / usr à root sont sécurisés car vous ne pouvez pas monter / usr si vous n'avez pas de racine! Mais dans l'autre sens … plus d'une fois, j'ai restauré / usr à partir d'une sauvegarde ou résolu à la main un problème uniquement à partir des rootfs.

Suis-je excessivement conservateur ou est-ce que le lien vers l'avant est considéré comme étant dans le domaine des «bonnes pratiques» pour les files critiques?

L'argument est que le fait de savoir où un binary donné devrait être (/ ou / usr) est une complication inutile qui ne sert à rien. Les systèmes n'ont pas encore pu démarrer sans / usr depuis un certain time maintenant, il n'y a donc plus de raison de conserver deux directorys.

Voir http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge pour plus de détails.

Une meilleure raison pour une utilisation extensive (prudente) des liens symboliques …

Les liens symboliques font pour les filesystems (une sorte de database hiérarchique) ce que font les foreign keys pour les bases de données relationnelles.

Avec une utilisation judicieuse des liens symboliques «avant» et «arrière» (bien que je ne les aie pas entendue de cette façon), une dissortingbution peut être conçue où la plupart des choses dans / etc, / bin, / lib et sbin sont liens symboliques vers / usr / etc, / usr / bin, / usr / lib et / usr / sbin. Il pourrait alors y avoir plusieurs versions du directory / usr montées quelque part comme sous / initrd (initialize ramdisk). Le système de files pourrait alors gérer, grâce à la création et à la suppression soigneuse des liens symboliques, quelle version était utilisée pour chaque file à un moment donné.

Puppy Linux et d'autres dissortingbutions utilisent les filesystems unionfs et aufs pour implémenter une variante de ce concept.

L'original O / S, tel qu'il est dissortingbué, est maintenu statique (inaltéré) en stockage permanent en tant que «couche inférieure». Lorsque l'un des files, comme / etc / hosts par exemple, est édité et sauvegardé, au lieu de changer l'original, le système de files crée une nouvelle copy dans la "couche de travail" la plus haute sur le disque virtuel. Le système de files présente alors cette copy, à la place de l'original, à l'user.

Les copys du disque virtuel sont périodiquement (configurables par l'user root), balayées en arrière-plan par une troisième couche qui est également stockée en permanence. Altered, les copys de disque virtuel superposent effectivement leurs versions sauvées qui à leur tour recouvrent les originaux statiques. Seule la copy la plus haute est visible (pour un file non modifié, ce serait l'original), de sorte que le système de files semble complètement typique de l'user et des autres logiciels.

Cette technique améliore la vitesse et la fiabilité du système …

Le file initié par l'user lit et écrit très rapidement car il utilise toujours le disque virtuel.
Comme la couche ramdisk ne contient que des files récemment modifiés, il rest petit et fonctionne comme un autre cache .
Rinçage à un stockage permanent plus lent est reporté au traitement de fond.
Des copys peuvent être faites périodiquement de la troisième couche «savefile», fournissant ainsi une capacité «d'annulation» lorsque les configurations ou les installations se déroulent mal ou que des programmes malveillants sont détectés.

Les liens symboliques sont ce qui rend tout cela possible.

Réponses aux questions …

Comment "haute vitesse" est votre configuration?

Le plus de memory que vous pouvez lui donner, plus le programme peut être conservé dans le disque virtuel et donc plus il sera réactif. Le démarrage d'un programme à partir de ramdisk est un peu plus rapide que le démarrage à partir de la memory flash (flash, SD, etc.) et ne prend qu'une infime fraction du time nécessaire pour démarrer le même programme à partir d'un disque dur.

Sur mon ordinateur portable Toshiba 4030CDT 1999 de 300 MHz avec 64 Mo de RAM, Puppy Linux 5.2.2 Wary, principalement basé sur Slackware, il n'y a pas de place pour beaucoup de disque virtuel, donc les programmes se chargent à partir du disque dur. Pourtant, l'interface graphique 2D est assez réactive. Je l'utilise comme la "console" connectée via Synergy à tous les autres hôtes.

A l'autre bout de l'échelle ce que j'utilise maintenant (via l'ordinateur portable) … un Compaq S6010V fonctionnant avec un processeur Celeron 2,6GHz et 1,3Go de RAM. Le disque virtuel "PuppySpace" a reçu 512 Mo dont less de 200 Mo sont actuellement utilisés. Loaded sont Zim (une application de prise de notes Python), Geany éditeur / IDE, un client terminal avec 5 sessions ouvertes et 2 copys de Chrome avec un total de 12 tabs de pages Web actifs, y compris Gmail.

Combien de time rest-t-il normalement?

Parce que je développe et change constamment des configs, les redémarrages planifiés sont courants. La sortie de disponibilité pour le Compaq est actuellement …

 16:21:10 up 4 days, 7:28, load average: 0.06, 0.24, 0.30

Est-il facile pour l'user de comstackr son propre kernel à partir de kernel.org et de démarrer avec lui?

Je ne peux pas aborder cela comme je ne l'ai jamais fait. Bien que la communauté Puppy Linux soit pleine de personnes qui comstacknt leurs propres kernelx pour le petit-déjeuner.

Est-ce quelque chose que vous exécutez des servers?

Tous mes systèmes exécutent des gestionnaires de windows JWM ou Openbox (basés sur GTK +), mais un certain travail a été fait pour configurer Puppy en tant que server comme avec LEMP et le jukebox de server de musique simplifié (mpdPup) .

aufs? … à quoi ça sert? (sur xfs / ext.

Aufs est une réécriture complète de unionfs. Ils implémentent tous deux un assembly d'union dans lequel plusieurs filesystems tels que xfs, ext3 / 4, etc. sont montés sur le même sharepoint assembly afin qu'ils se superposent.

Pour l'instant, il est préférable de ne pas créer /usr une partition séparée. De cette façon, il n'y a pas besoin de liens symboliques.

Du less, c'est ce que j'ai décidé après que les problèmes de binarys se soient déclenchés dans ma dissortingbution. En fait, cela me semble très logique d'avoir tous les files binarys et les bibliothèques sur la même partition. Peu importe alors qui sont dans /bin et qui sont dans /usr/bin , et ils peuvent être déplacés comme bon vous semble.

La seule raison pour laquelle j'ai eu un /usr séparé en premier lieu était que j'ai simplement fait une partition pour tout; avec LVM, c'est facile à faire. Cependant en dehors de cela, il n'y avait aucune raison pratique pour cela. Il a été séparé pour le plaisir de se séparer.

Si vous avez une partition pour tout, votre racine / partition sera quasiment vide. Dans mon cas, c'était less de 200 Mo. J'ai donc fusionné avec la partition /usr et libéré l'espace précédemment inutilement gaspillé par la partition racine. Jusqu'à présent, je n'ai pas découvert d'inconvénients.

Le process de fusion à partir d'un système de secours: (utilisez à vos risques et périls risque de briser votre système)

 mkdir /mnt/root /mnt/usr mount /dev/lvm/root /mnt/root mount /dev/lvm/usr /mnt/usr # /usr will be mounted as /, so move everything into a new usr/ subdirectory mkdir /mnt/usr/usr mv /mnt/usr/* /mnt/usr/usr/ # copy the root files, preserving hard links just in case rsync -aH /mnt/root/. /mnt/usr/. # update fstab: comment /usr, change UUID of / to the one of /usr nano /mnt/usr/etc/fstab umount /mnt/root umount /mnt/usr lvrename lvm/root lvm/oldroot lvrename lvm/usr lvm/root # chroot to see if it works and update grub UUID mount /dev/lvm/root /mnt/root mount -o bind /dev /mnt/root/dev mount -o bind /proc /mnt/root/proc mount -o bind /sys /mnt/root/sys chroot /mnt/root /bin/bash update-grub # may depend on distro/bootloader