5 votes

Utilisateur non enregistré avatar

/usr/lib, /usr/share, et /usr/bin liés par un lien symbolique à des répertoires sur une autre partition

Demandé el 7 de Mars, 2013
Quand la question a-t-elle été
2661 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Je travaille avec un serveur en cours d'exécution qui a une partition racine de 15 Go, une partition swap de 1 Go et une partition domestique de 216,9 Go. Apparemment, le serveur a manqué d'espace sur la partition racine à un moment donné et, au lieu de l'étendre, un précédent mainteneur du serveur a déplacé le disque dur de la partition racine. /usr/lib , /usr/share y /usr/bin dans les répertoires /home/usr et a créé des liens symboliques vers les nouveaux emplacements des répertoires à leurs anciens emplacements.

Le serveur fonctionne sous Arch Linux 3.6.10-1. Les partitions root et home ont chacune un système de fichiers ext4.

À l'exception de petites nuances comme le fait de devoir dire explicitement à find pour suivre les liens symétriques lors de la recherche d'un fichier dans /usr Cette configuration pourrait-elle poser problème ? Je suis particulièrement inquiet et curieux des problèmes de sécurité liés à cette configuration.

Demandé el 7 de Mars, 2013 par Utilisateur non enregistré

Réponses

Trop de publicités?

3voto

lexma avatar
lexma Points 133

Utilisez mount avec l'option bind au lieu des liens symboliques et vous n'aurez pas ce genre de problèmes.

Pour ce faire, vous pouvez ajouter quelques lignes dans votre fichier /etc/fstab ( source ; français) :

/home/usr/bin        /usr/bin     none   bind    0       0
/home/usr/share      /usr/share   none   bind    0       0
/home/usr/lib        /usr/lib     none   bind    0       0

La syntaxe générale :

/source              /destination none   [r]bind[,...] 0 0
Répondu el 8 de Mars, 2013 par lexma (133 Points )

0 votes

Avatar de voretaq7

Remplacer un mauvais hack (symlinking core directories into /home ) avec un autre... c'est une solution, mais pas une grande.

Commenté el 8 de Mars, 2013 par voretaq7

0 votes

Avatar de d34dfish

@voretaq7 Eh bien, cela aide beaucoup quand vous ne voulez pas perdre de temps à reconstruire un système entier.

Commenté el 11 de Juillet, 2013 par d34dfish

0 votes

Avatar de voretaq7

@Cerber Comme je l'ai mentionné dans ma réponse, cela peut servir de palliatif utile, mais la "négligence supervisée" comme celle-ci est une mauvaise façon de gérer les systèmes. Corriger le problème correctement maintenant (quand c'est votre choix) est mieux que de le pirater et de prétendre que c'est un problème. vraiment et de le voir exploser et devenir une urgence plus tard (avec tout le monde qui vous crie dessus parce que la production est en panne). C'est la voix de l'expérience qui parle...

Commenté el 11 de Juillet, 2013 par voretaq7
Afficher 2 autres commentaires

2voto

voretaq7 avatar
voretaq7 Points 78924

Il y a deux solutions possibles que j'envisagerais ici :

  1. Trouvez ce qui remplit votre partition racine, et réparez-le.
    C'est probablement la bonne solution - Avec une partition racine de 15 Go (et une disposition de partition saine ) vous ne devriez vraiment pas remplir la partition racine.
    Bien sûr, si les données sont légitimes et que la disposition de partitionnement n'est pas saine (par ex. /var est sur la partition racine), il n'y a probablement pas grand chose que vous puissiez faire.

  2. Reconstruire le serveur avec un schéma de partitionnement sain.
    Si vous avez légitimement rempli la partition racine, ou si votre schéma de partitionnement n'est pas sain, vous devez reconstruire le système avec une disposition de partition plus appropriée.
    Cette solution est assez pénible (vous allez devoir sauvegarder vos données, réinstaller le système et restaurer les données), mais elle vous laissera avec une machine propre qui n'a pas de liens symboliques ou de points de montage liés traînant là où ils ne devraient pas être, pour que vous ou un futur administrateur trébuche dessus plus tard.

Il existe des solutions alternatives (comme la suggestion d'aim d'utiliser des supports de fixation ), mais je considère que ce sont des mesures palliatives pour gagner du temps avec le système en fonctionnement pendant que vous planifiez une vraie solution.

Répondu el 8 de Mars, 2013 par voretaq7 (78924 Points )

0 votes

Avatar de Utilisateur non enregistré

J'ai nettoyé la partition racine autant que possible en nettoyant /var (il se trouve sur la partition racine). J'ai également supprimé les bibliothèques et les programmes inutilisés de l'arborescence de l'ordinateur. /home/usr les répertoires. Malheureusement, si je mets le /home/usr sur la partition racine, la partition n'aurait plus qu'environ 1 Go d'espace libre (l'espace libre de la partition). /home/usr les répertoires occupent environ 12,5 Go et le répertoire racine contient encore environ 1,5 Go de données). Je ne pense pas que 1 Go soit une quantité sûre d'espace libre pour la partition racine, d'autant plus qu'elle contient /var .

Commenté el 8 de Mars, 2013 par Utilisateur non enregistré

0 votes

Avatar de voretaq7

@EvanTeitelman Si /var est sur la partition racine votre schéma de partitionnement n'est définitivement pas sain - vous pouvez gagner du temps avec la solution d'aim, mais prévoyez de reconstruire cette boîte

Commenté el 8 de Mars, 2013 par voretaq7

0 votes

Avatar de Utilisateur non enregistré

Est-ce que le fait d'essayer de redimensionner les partitions existantes et leurs systèmes de fichiers en ajoutant /var y /tmp Les partitions sont-elles une mauvaise idée ? Ou devrais-je simplement reconstruire entièrement la table de partition ?

Commenté el 8 de Mars, 2013 par Utilisateur non enregistré
Afficher 2 autres commentaires

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X