{"id":31333,"date":"2019-10-31T21:40:44","date_gmt":"2019-10-31T18:40:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/virtualnye-fajlovye-sistemy-v-linux-zachem-oni-nuzhny-i-kak-oni-rabotayut-chast-2\/"},"modified":"2019-10-31T21:40:44","modified_gmt":"2019-10-31T18:40:44","slug":"virtualnye-fajlovye-sistemy-v-linux-zachem-oni-nuzhny-i-kak-oni-rabotayut-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/virtualnye-fajlovye-sistemy-v-linux-zachem-oni-nuzhny-i-kak-oni-rabotayut-chast-2","title":{"rendered":"Syst\u00e8mes de fichiers virtuels sous Linux : \u00e0 quoi servent-ils et comment fonctionnent-ils ? Partie 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour \u00e0 tous, nous partageons avec vous la deuxi\u00e8me partie de la publication \u00ab Syst\u00e8mes de fichiers virtuels sous Linux : pourquoi sont-ils n\u00e9cessaires et comment fonctionnent-ils ? \u00bb Vous pouvez lire la premi\u00e8re partie ici<\/a><\/noindex>. Rappelons que cette s\u00e9rie de publications est d\u00e9di\u00e9e au lancement d'un nouveau semestre pour le cours \u00ab Administrateur Linux \u00bb<\/a><\/noindex>, qui commence tr\u00e8s bient\u00f4t.<\/p>\n

Comment surveiller le VFS avec les outils eBPF et bcc<\/b><\/p>\n

La mani\u00e8re la plus simple de comprendre comment le noyau g\u00e8re les fichiers sysfs<\/code> \u2013 c'est d'observer cela en pratique, et la fa\u00e7on la plus simple de suivre ARM64 est d'utiliser eBPF. eBPF (abr\u00e9viation de Berkeley Packet Filter) consiste en une machine virtuelle, s'ex\u00e9cutant dans le noyau<\/a><\/noindex>, que les utilisateurs privil\u00e9gi\u00e9s peuvent interroger (query<\/code>) depuis la ligne de commande. Les sources du noyau informent le lecteur de ce que le noyau peut faire ; l'ex\u00e9cution des outils eBPF dans un syst\u00e8me charg\u00e9 montre ce que le noyau fait r\u00e9ellement. <\/p>\n

\"Syst\u00e8mes<\/a><\/noindex><\/p>\n

Heureusement, commencer \u00e0 utiliser eBPF est assez facile gr\u00e2ce aux outils bcc<\/a><\/noindex>, qui sont disponibles en tant que paquets dans la distribution g\u00e9n\u00e9rale Linux<\/a><\/noindex> et largement document\u00e9s par Bernard Gregory<\/a><\/noindex>. Les outils bcc<\/code> sont des scripts en Python avec de petites insertions de code en C, ce qui signifie que quiconque conna\u00eet les deux langages peut facilement les modifier. Dans bcc\/tools<\/code> il y a 80 scripts Python, ce qui laisse entendre qu'un d\u00e9veloppeur ou un administrateur syst\u00e8me pourra probablement trouver quelque chose de adapt\u00e9 \u00e0 son probl\u00e8me.
\nPour obtenir au moins une id\u00e9e g\u00e9n\u00e9rale du travail que font les VFS dans un syst\u00e8me en fonctionnement, essayez vfscount<\/code> ou vfsstat<\/code>. Cela montrera, par exemple, que des dizaines d'appels vfs_open()<\/code> et ses \u00ab amis \u00bb se produisent litt\u00e9ralement chaque seconde.<\/p>\n

\"Syst\u00e8mes
\n<\/p>\n

vfsstat.py<\/code> \u2013 est un script en Python, avec des insertions de code en C, qui compte simplement les appels de fonctions VFS.<\/p><\/blockquote>\n

Prenons un exemple plus trivial et voyons ce qui se passe quand nous ins\u00e9rons une cl\u00e9 USB dans l'ordinateur et que le syst\u00e8me la d\u00e9tecte.<\/p>\n

\"Syst\u00e8mes
\n<\/p>\n

Avec eBPF, nous pouvons observer ce qui se passe dans \/sys<\/code>, lors de l'insertion d'une cl\u00e9 USB. Voici un exemple simple et un exemple complexe.<\/p><\/blockquote>\n

Dans l'exemple montr\u00e9 ci-dessus, bcc<\/code> l'outil trace.py<\/a><\/noindex> affiche un message lorsque la commande sysfs_create_files()<\/code>. Nous voyons qu'elle a \u00e9t\u00e9 lanc\u00e9e par sysfs_create_files()<\/code> kworker dans un flux en r\u00e9ponse \u00e0 l'insertion de la cl\u00e9, mais quel fichier a \u00e9t\u00e9 cr\u00e9\u00e9 ? Le deuxi\u00e8me exemple montre toute la puissance d'eBPF. Ici<\/code> flux en r\u00e9ponse \u00e0 l'insertion de la cl\u00e9 USB, mais quel fichier a \u00e9t\u00e9 cr\u00e9\u00e9 dans ce cas ? Le deuxi\u00e8me exemple montre toute la puissance d'eBPF. Ici trace.py<\/code> affiche la trace de retour du noyau (kernel backtrace) (option -K) et le nom du fichier qui a \u00e9t\u00e9 cr\u00e9\u00e9 sysfs_create_files()<\/code>. L'insertion dans les d\u00e9clarations uniques est un code en C, incluant une cha\u00eene de format facilement reconnaissable, fournie par un script Python qui lance LLVM compilateur just-in-time<\/i>. Cette cha\u00eene est compil\u00e9e et ex\u00e9cut\u00e9e dans une machine virtuelle \u00e0 l'int\u00e9rieur du noyau. La signature compl\u00e8te de la fonction sysfs_create_files()<\/code> doit \u00eatre reproduite dans la seconde commande pour que la cha\u00eene de format puisse faire r\u00e9f\u00e9rence \u00e0 un des param\u00e8tres. Les erreurs dans ce fragment de code C entra\u00eenent des erreurs reconnaissables du compilateur C. Par exemple, si le param\u00e8tre -l est manquant, vous verrez \u00ab Failed to compile BPF text. \u00bb Les d\u00e9veloppeurs qui sont familiers avec C et Python trouveront les outils bcc<\/code> faciles \u00e0 \u00e9tendre et \u00e0 modifier.<\/p>\n

Lorsque la cl\u00e9 USB est ins\u00e9r\u00e9e, la trace de retour du noyau montrera que le PID 7711 est le flux dans un flux en r\u00e9ponse \u00e0 l'insertion de la cl\u00e9, mais quel fichier a \u00e9t\u00e9 cr\u00e9\u00e9 ? Le deuxi\u00e8me exemple montre toute la puissance d'eBPF. Ici<\/code>, qui a cr\u00e9\u00e9 le fichier \u00ab events \u00bb<\/code> dans sysfs<\/code>. En cons\u00e9quence, l'appel avec sysfs_remove_files()<\/code> montrera que le retrait du p\u00e9riph\u00e9rique a entra\u00een\u00e9 la suppression du fichier events<\/code>, ce qui correspond au concept g\u00e9n\u00e9ral de comptage des r\u00e9f\u00e9rences. Ainsi, l'examen de sysfs_create_link()<\/code> avec eBPF lors de l'insertion de la cl\u00e9 USB montrera qu'au moins 48 liens symboliques ont \u00e9t\u00e9 cr\u00e9\u00e9s.<\/p>\n

Quelle est donc la signification du fichier events ? L'utilisation de cscope<\/a><\/noindex> pour rechercher __device_add_disk()<\/a><\/noindex>, montre qu'il appelle disk_add_events()<\/code>, et soit \"media_change\"<\/code>, ou bien \"eject_request\"<\/code> peuvent \u00eatre enregistr\u00e9s dans le fichier des \u00e9v\u00e9nements. Ici, la couche de blocs du noyau informe l'espace utilisateur de l'apparition et du retrait du \u00ab disque \u00bb. Notez \u00e0 quel point cette m\u00e9thode d'investigation est informative, par rapport aux tentatives de comprendre comment tout fonctionne uniquement \u00e0 partir des sources.<\/p>\n

Les syst\u00e8mes de fichiers racine en lecture seule rendent possibles les dispositifs int\u00e9gr\u00e9s<\/b><\/p>\n

Bien s\u00fbr, personne ne \u00e9teint le serveur ou son ordinateur en tirant la prise de la prise. Mais pourquoi ? C'est parce que les syst\u00e8mes de fichiers mont\u00e9s sur des dispositifs de stockage physiques peuvent avoir des \u00e9critures en attente, et les structures de donn\u00e9es enregistrant leur \u00e9tat peuvent ne pas se synchroniser avec les enregistrements dans le stockage. Lorsque cela se produit, les propri\u00e9taires du syst\u00e8me doivent attendre le prochain d\u00e9marrage pour ex\u00e9cuter l'outil fsck filesystem-recovery<\/code> et, dans le pire des cas, perdre des donn\u00e9es. <\/p>\n

N\u00e9anmoins, nous savons tous que de nombreux appareils IoT, ainsi que des routeurs, thermostats et automobiles, fonctionnent d\u00e9sormais sous Linux. Beaucoup de ces appareils n'ont pratiquement pas d'interface utilisateur, et il n'y a aucun moyen de les \u00e9teindre \u00ab proprement \u00bb. Imaginez d\u00e9marrer une voiture avec une batterie d\u00e9charg\u00e9e, lorsque l'alimentation de l'appareil de contr\u00f4le est en Linux<\/a><\/noindex> permanence instable. Comment se fait-il que le syst\u00e8me d\u00e9marre sans un long fsck<\/code>, lorsque le moteur commence enfin \u00e0 fonctionner ? La r\u00e9ponse est simple. Les appareils embarqu\u00e9s s'appuient sur un syst\u00e8me de fichiers racine en lecture seule<\/a><\/noindex> (abr\u00e9g\u00e9 ro-rootfs<\/code> (syst\u00e8me de fichiers racine en lecture seule)). <\/p>\n

ro-rootfs<\/code> offrent de nombreux avantages moins \u00e9vidents que ne le sont l'authenticit\u00e9. L'un des avantages est que les logiciels malveillants ne peuvent pas \u00e9crire dans \/usr<\/code> ou \/lib<\/code>, si aucun processus Linux ne peut y \u00e9crire. Un autre avantage est qu'un syst\u00e8me de fichiers largement immuable est crucial pour le support sur le terrain des appareils distants, car le personnel de support utilise des syst\u00e8mes locaux qui sont nominalement identiques aux syst\u00e8mes sur place. Peut-\u00eatre que l'avantage le plus important (mais aussi le plus sournois) est que le ro-rootfs oblige les d\u00e9veloppeurs \u00e0 d\u00e9cider quels objets syst\u00e8me seront immuables, d\u00e8s la phase de conception du syst\u00e8me. Travailler avec le ro-rootfs peut \u00eatre g\u00eanant et douloureux, comme c'est souvent le cas avec les variables const dans les langages de programmation, mais leurs avantages compensent facilement les frais suppl\u00e9mentaires.<\/p>\n

Cr\u00e9ation rootfs<\/code> en lecture seule demande quelques efforts suppl\u00e9mentaires de la part des d\u00e9veloppeurs de syst\u00e8mes embarqu\u00e9s, et c'est ici qu'intervient le VFS. Linux exige que les fichiers dans \/var<\/code> soient accessibles en \u00e9criture, et de plus, de nombreuses applications populaires qui ex\u00e9cutent des syst\u00e8mes embarqu\u00e9s tenteront de cr\u00e9er des fichiers de configuration dot-files<\/code> dans $HOME<\/code>. L'une des solutions pour les fichiers de configuration dans le r\u00e9pertoire personnel consiste g\u00e9n\u00e9ralement \u00e0 les g\u00e9n\u00e9rer \u00e0 l'avance et \u00e0 les assembler dans rootfs<\/code>. Pour \/var<\/code> une approche possible consiste \u00e0 le monter dans une partition distincte, accessible en \u00e9criture, tandis que lui-m\u00eame \/<\/code> mont\u00e9 en lecture seule. Une autre alternative populaire consiste \u00e0 utiliser des montages li\u00e9s ou superpos\u00e9s (bind or overlay mounts).<\/p>\n

Montages li\u00e9s et superpos\u00e9s, utilis\u00e9s par les conteneurs.<\/b> <\/p>\n

Ex\u00e9cution de la commande. man mount<\/code> est le meilleur moyen de conna\u00eetre les montages li\u00e9s et superpos\u00e9s, qui permettent aux d\u00e9veloppeurs et aux administrateurs syst\u00e8me de cr\u00e9er un syst\u00e8me de fichiers \u00e0 un chemin, puis de le rendre disponible aux applications \u00e0 un autre. Pour les syst\u00e8mes embarqu\u00e9s, cela signifie la possibilit\u00e9 de stocker des fichiers dans \/var<\/code> une cl\u00e9 USB accessible en lecture seule, mais le montage superpos\u00e9 ou li\u00e9 \u00e0 partir de tmpfs<\/code> dans \/var<\/code> au d\u00e9marrage permettra aux applications d'y \u00e9crire des notes (scrawl). Lors du prochain d\u00e9marrage, les modifications dans \/var<\/code> seront perdues. Le montage superpos\u00e9 cr\u00e9e une union entre tmpfs<\/code> et le syst\u00e8me de fichiers sous-jacent, permettant des modifications apparentes des fichiers existants dans ro-tootf<\/code> tandis que le montage li\u00e9 peut rendre de nouveaux dossiers vides visibles comme \u00e9tant accessibles en \u00e9criture dans tmpfs<\/code> les chemins. Alors que ro-rootfs<\/code> overlayfs est le type de syst\u00e8me de fichiers correct (<\/code> proper) le montage li\u00e9 est r\u00e9alis\u00e9 dans<\/code>l'espace de noms VFS. Sur la base de la description des montages superpos\u00e9s et li\u00e9s, personne n'est surpris que<\/a><\/noindex>.<\/p>\n

les conteneurs Linux les utilisent activement. Observons ce qui se passe lorsque nous utilisons<\/a><\/noindex> systemd-nspawn pour ex\u00e9cuter un conteneur, en utilisant l'outil<\/a><\/noindex> mountsnoop. L'appel<\/code> \u00e0 partir de bcc<\/code>.<\/p>\n

de system-nspawn lance le conteneur au moment o\u00f9<\/code> mountsnoop.py Voyons ce que cela donne :<\/code>.<\/p>\n

durant le \u00ab d\u00e9marrage \u00bb du conteneur, il montre que l'environnement d'ex\u00e9cution du conteneur d\u00e9pend fortement du montage li\u00e9 (Seule le d\u00e9but d'une longue sortie est affich\u00e9).<\/p>\n

Lancement L'appel<\/code> fournit des fichiers s\u00e9lectionn\u00e9s dans<\/p>\n

Ici pour ex\u00e9cuter un conteneur, en utilisant l'outil<\/code> procfs de l'h\u00f4te dans le conteneur sous forme de chemins dans son<\/code> et sysfs<\/code> . En plus du rootfs<\/code>drapeau MS_BIND, qui d\u00e9finit le montage li\u00e9, d'autres drapeaux dans le syst\u00e8me mont\u00e9 d\u00e9terminent la relation entre les changements dans l'espace de noms de l'h\u00f4te et du conteneur. Par exemple, le montage li\u00e9 peut soit laisser passer les changements dans dans le conteneur, soit les cacher, en fonction de l'appel.<\/code> le drapeau qui \u00e9tablit le montage li\u00e9, certains autres drapeaux dans le syst\u00e8me mont\u00e9 d\u00e9finissent la relation entre les modifications dans l'espace de noms h\u00f4te et le conteneur. Par exemple, le montage li\u00e9 peut soit ignorer les modifications dans \/proc<\/code> et \/sys<\/code> le conteneur, soit les masquer en fonction de l'appel. <\/p>\n

Conclusion<\/b><\/p>\n

Comprendre le fonctionnement interne de Linux peut sembler une t\u00e2che impossible, car le noyau lui-m\u00eame contient une quantit\u00e9 gigantesque de code, sans parler des applications de l'espace utilisateur de Linux et des interfaces d'appels syst\u00e8me dans les biblioth\u00e8ques C telles que glibc<\/code>. L'un des moyens de progresser est de lire le code source d'un sous-syst\u00e8me du noyau en se concentrant sur la compr\u00e9hension des appels syst\u00e8me et des en-t\u00eates adress\u00e9s \u00e0 l'espace utilisateur, ainsi que sur les principales interfaces internes du noyau, comme la table file_operations<\/code>. Les op\u00e9rations sur les fichiers assurent le principe selon lequel \u00ab tout est fichier \u00bb, donc leur gestion est particuli\u00e8rement agr\u00e9able. Les fichiers source du noyau en C se trouvent dans le r\u00e9pertoire sup\u00e9rieur fs\/<\/code> qui repr\u00e9sentent l'impl\u00e9mentation des syst\u00e8mes de fichiers virtuels, qui forment une couche d'abstraction permettant une large et relativement simple compatibilit\u00e9 des syst\u00e8mes de fichiers et des appareils de stockage populaires. Le montage par liaison et l'utilisation de namespaces sous Linux, c'est la magie du VFS qui rend possible la cr\u00e9ation de conteneurs et de syst\u00e8mes de fichiers racines en lecture seule. Coupl\u00e9 \u00e0 l'\u00e9tude du code source, l'outil du noyau eBPF et son interface bcc<\/code>
\n facilitent l'exploration du noyau plus que jamais.<\/p>\n

Amis, dites-nous si cet article vous a \u00e9t\u00e9 utile ? Peut-\u00eatre avez-vous des commentaires ou des remarques ? Et ceux qui sont int\u00e9ress\u00e9s par le cours \u00ab Administrateur Linux \u00bb, nous vous invitons \u00e0 notre journ\u00e9e portes ouvertes<\/a><\/noindex>, qui se d\u00e9roulera le 18 avril.<\/p>\n

Premi\u00e8re partie.<\/a><\/noindex>
\n
Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442, \u0434\u0435\u043b\u0438\u043c\u0441\u044f \u0441 \u0432\u0430\u043c\u0438 \u0432\u0442\u043e\u0440\u043e\u0439 \u0447\u0430\u0441\u0442\u044c\u044e \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u00ab\u0412\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u043e\u0432\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0432 Linux: \u0437\u0430\u0447\u0435\u043c \u043e\u043d\u0438 \u043d\u0443\u0436\u043d\u044b \u0438 \u043a\u0430\u043a \u043e\u043d\u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0442?\u00bb \u041f\u0435\u0440\u0432\u0443\u044e \u0447\u0430\u0441\u0442\u044c \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u0442\u044c \u0442\u0443\u0442. \u041d\u0430\u043f\u043e\u043c\u043d\u0438\u043c, \u0434\u0430\u043d\u043d\u0430\u044f \u0441\u0435\u0440\u0438\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0439 \u043f\u0440\u0438\u0443\u0440\u043e\u0447\u0435\u043d\u0430 \u043a \u0437\u0430\u043f\u0443\u0441\u043a\u0443 \u043d\u043e\u0432\u043e\u0433\u043e \u043f\u043e\u0442\u043e\u043a\u0430 \u043f\u043e \u043a\u0443\u0440\u0441\u0443 \u00ab\u0410\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440 Linux\u00bb, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0441\u0442\u0430\u0440\u0442\u0443\u0435\u0442 \u0443\u0436\u0435 \u0441\u043e\u0432\u0441\u0435\u043c \u0441\u043a\u043e\u0440\u043e. \u041a\u0430\u043a \u043d\u0430\u0431\u043b\u044e\u0434\u0430\u0442\u044c \u0437\u0430 VFS \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u0432 eBPF \u0438 bcc \u0421\u0430\u043c\u044b\u0439 \u043f\u0440\u043e\u0441\u0442\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23299,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31333","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Syst\u00e8mes de fichiers virtuels sous Linux : pourquoi sont-ils n\u00e9cessaires et comment fonctionnent-ils ? Partie 2 | ProHoster","description":"Bonjour \u00e0 tous, nous partageons avec vous la deuxi\u00e8me partie de la publication \u00ab Syst\u00e8mes de fichiers virtuels sous Linux : pourquoi sont-ils n\u00e9cessaires et comment fonctionnent-ils ? \u00bb Vous pouvez lire la premi\u00e8re partie","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/virtualnye-fajlovye-sistemy-v-linux-zachem-oni-nuzhny-i-kak-oni-rabotayut-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u043e\u0432\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0432 Linux: \u0437\u0430\u0447\u0435\u043c \u043e\u043d\u0438 \u043d\u0443\u0436\u043d\u044b \u0438 \u043a\u0430\u043a \u043e\u043d\u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0442? \u0427\u0430\u0441\u0442\u044c 2 | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442, \u0434\u0435\u043b\u0438\u043c\u0441\u044f \u0441 \u0432\u0430\u043c\u0438 \u0432\u0442\u043e\u0440\u043e\u0439 \u0447\u0430\u0441\u0442\u044c\u044e \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u00ab\u0412\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u043e\u0432\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0432 Linux: \u0437\u0430\u0447\u0435\u043c \u043e\u043d\u0438 \u043d\u0443\u0436\u043d\u044b \u0438 \u043a\u0430\u043a \u043e\u043d\u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0442?\u00bb \u041f\u0435\u0440\u0432\u0443\u044e \u0447\u0430\u0441\u0442\u044c \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u0442\u044c","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/virtualnye-fajlovye-sistemy-v-linux-zachem-oni-nuzhny-i-kak-oni-rabotayut-chast-2","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:40:44+00:00","article:modified_time":"2019-10-31T18:40:44+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31333","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 05:41:23","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:18:40","updated":"2026-01-21 05:41:23","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/31333","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=31333"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/31333\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/23299"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=31333"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=31333"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=31333"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}