{"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\/it\/blog\/administrirovanie\/virtualnye-fajlovye-sistemy-v-linux-zachem-oni-nuzhny-i-kak-oni-rabotayut-chast-2","title":{"rendered":"Sistemi di file virtuali in Linux: a cosa servono e come funzionano? Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao a tutti, condividiamo con voi la seconda parte della pubblicazione \"Sistemi di file virtuali in Linux: perch\u00e9 sono necessari e come funzionano?\" \u00c8 possibile leggere la prima parte qui<\/a><\/noindex>. Ricordiamo che questa serie di pubblicazioni \u00e8 dedicata al lancio di un nuovo ciclo del corso \u00abAmministratore Linux\u00bb<\/a><\/noindex>, che inizier\u00e0 molto presto.<\/p>\n

Come osservare VFS usando strumenti eBPF e bcc<\/b><\/p>\n

Il modo pi\u00f9 semplice per capire come il kernel gestisce i file sysfs<\/code> \u00e8 osservare tutto ci\u00f2 nella pratica, e il modo pi\u00f9 semplice per osservare ARM64 \u00e8 utilizzare eBPF. eBPF (acronimo di Berkeley Packet Filter) consiste in una macchina virtuale che viene eseguita nel kernel<\/a><\/noindex>, che gli utenti privilegiati possono richiedere (query<\/code>) dalla riga di comando. Il codice sorgente del kernel informa il lettore su cosa pu\u00f2 fare il kernel; eseguire strumenti eBPF in un sistema in funzione mostra cosa fa realmente il kernel. <\/p>\n

\"Sistemi<\/a><\/noindex><\/p>\n

Fortunatamente, iniziare a usare eBPF \u00e8 piuttosto semplice grazie agli strumenti bcc<\/a><\/noindex>, che sono disponibili come pacchetti dalla distribuzione generale Linux<\/a><\/noindex> e documentati in dettaglio da Bernard Gregg<\/a><\/noindex>. Gli strumenti bcc<\/code> sono script in Python con piccoli inserti di codice in C, il che significa che chiunque conosca entrambi i linguaggi pu\u00f2 modificarli facilmente. In bcc\/tools<\/code> ci sono 80 script Python, il che significa che molto probabilmente sviluppatori o amministratori di sistema troveranno qualcosa di adatto per risolvere i loro compiti.
\nPer avere almeno un'idea superficiale di quale lavoro svolgano gli VFS in un sistema attivo, provate vfscount<\/code> o vfsstat<\/code>. Questo mostrer\u00e0, ad esempio, che decine di chiamate vfs_open()<\/code> e dei suoi \"amici\" accadono letteralmente ogni secondo.<\/p>\n

\"Sistemi
\n<\/p>\n

vfsstat.py<\/code> \u00e8 uno script in Python, con inserimenti di codice C, che conta semplicemente le chiamate alle funzioni VFS.<\/p><\/blockquote>\n

Facciamo un esempio pi\u00f9 banale e vediamo cosa succede quando inseriamo una chiavetta USB nel computer e il sistema la riconosce.<\/p>\n

\"Sistemi
\n<\/p>\n

Con eBPF possiamo osservare cosa accade in \/sys<\/code>quando viene inserita una chiavetta USB. Qui viene mostrato un esempio semplice e uno complesso.<\/p><\/blockquote>\n

Nell'esempio mostrato sopra, bcc<\/code> strumento trace.py<\/a><\/noindex> emette un messaggio quando viene eseguita la comando sysfs_create_files()<\/code>. Vediamo che sysfs_create_files()<\/code> \u00e8 stato avviato da kworker<\/code> in risposta all'inserimento della chiavetta, ma quale file \u00e8 stato creato in questo caso? trace.py<\/code> stampa il backtrace del kernel (opzione -K) e il nome del file che \u00e8 stato creato sysfs_create_files()<\/code>. L'inserimento tra virgolette singole \u00e8 codice in C, contenente una stringa di formato facilmente riconoscibile, fornita da uno script Python che esegue LLVM compilatore just-in-time<\/i>. Questa stringa viene compilata ed eseguita in una macchina virtuale all'interno del kernel. La firma completa della funzione sysfs_create_files ()<\/code> deve essere replicata nel secondo comando, affinch\u00e9 la stringa di formato possa fare riferimento a uno dei parametri. Errori in questo frammento di codice in C portano a errori riconoscibili del compilatore C. Ad esempio, se il parametro -l \u00e8 mancante, vedrai \"Failed to compile BPF text.\" Gli sviluppatori che hanno familiarit\u00e0 con C e Python troveranno gli strumenti bcc<\/code> facili da estendere e modificare.<\/p>\n

Quando la chiavetta USB \u00e8 inserita, il backtrace del kernel mostrer\u00e0 che il PID 7711 \u00e8 un thread kworker<\/code>, che ha creato il file \"events\"<\/code> in sysfs<\/code>. Di conseguenza, la chiamata a sysfs_remove_files()<\/code> mostrer\u00e0 che la rimozione della chiavetta ha portato alla cancellazione del file events<\/code>, il che corrisponde al concetto generale di conteggio dei riferimenti. Inoltre, la visualizzazione sysfs_create_link ()<\/code> con eBPF durante l'inserimento della chiavetta USB mostrer\u00e0 che sono state create almeno 48 link simbolici.<\/p>\n

Qual \u00e8 dunque il significato del file events? L'uso di cscope<\/a><\/noindex> per cercare __device_add_disk()<\/a><\/noindex>, mostra che essa chiama disk_add_events ()<\/code>, e o \"media_change\"<\/code>, oppure \"eject_request\"<\/code> possono essere scritti nel file eventi. Qui, lo strato del blocco del kernel informa il userspace dell'inserimento e dell'estrazione del \"disco\". Nota quanto sia informativo questo metodo di indagine prendendo come esempio l'inserimento della chiavetta USB rispetto ai tentativi di scoprire come funziona tutto esclusivamente dai sorgenti.<\/p>\n

I file system radice di sola lettura rendono possibili i dispositivi incorporati<\/b><\/p>\n

Certo, nessuno spegne un server o il proprio computer staccando la spina dalla presa. Ma perch\u00e9? \u00c8 tutto dovuto al fatto che i file system montati su dispositivi fisici di memorizzazione possono avere scritture in sospeso, e le strutture dati che registrano il loro stato potrebbero non essere sincronizzate con le scritture nella memorizzazione. Quando ci\u00f2 accade, ai proprietari del sistema tocca attendere il successivo avvio per eseguire l'utility fsck filesystem-recovery<\/code> e, nel peggiore dei casi, perdere dati. <\/p>\n

Tuttavia, tutti sappiamo che molti dispositivi IoT, cos\u00ec come router, termostati e automobili, ora funzionano sotto Linux. Molti di questi dispositivi hanno praticamente un'interfaccia utente inesistente e non c'\u00e8 modo di spegnerli \"pulitamente\". Immaginate di avviare un'auto con la batteria scarica, quando l'alimentazione del dispositivo di controllo \u00e8 Linux<\/a><\/noindex> costantemente altalenante. Come fa dunque il sistema a caricarsi senza un lungo fsck<\/code>, quando il motore alla fine inizia a funzionare? La risposta \u00e8 semplice. I dispositivi embedded si basano su un file system radice solo in lettura<\/a><\/noindex> (abbreviato ro-rootfs<\/code> (read-only root filesystem)). <\/p>\n

ro-rootfs<\/code> offrono numerosi vantaggi, che sono meno ovvi rispetto all'immutabilit\u00e0. Un vantaggio \u00e8 che il malware non pu\u00f2 scrivere in \/usr<\/code> o \/lib<\/code>, se nessun processo Linux pu\u00f2 scriverci. Un altro \u00e8 che un file system sostanzialmente immutabile \u00e8 cruciale per il supporto sul campo dei dispositivi remoti, poich\u00e9 il personale di supporto utilizza sistemi locali che sono nominalmente identici ai sistemi sul campo. Forse il vantaggio pi\u00f9 importante (ma anche il pi\u00f9 insidioso) \u00e8 che ro-rootfs costringe gli sviluppatori a decidere quali oggetti di sistema saranno immutabili fin dall'inizio della progettazione del sistema. Lavorare con ro-rootfs pu\u00f2 essere scomodo e doloroso, come spesso accade con le variabili const nei linguaggi di programmazione, ma i loro vantaggi compensano facilmente le spese aggiuntive.<\/p>\n

Creazione rootfs<\/code> La scrittura su un file system di sola lettura richiede alcuni sforzi aggiuntivi per gli sviluppatori di sistemi embedded, ed \u00e8 qui che entra in gioco VFS. Linux richiede che i file in \/var<\/code> siano accessibili in scrittura, e inoltre, molte applicazioni popolari che eseguono sistemi embedded cercheranno di creare file di configurazione dot-files<\/code> in $HOME<\/code>. Una delle soluzioni per i file di configurazione nella home directory \u00e8 generalmente la loro generazione predefinita e integrazione in rootfs<\/code>. Per \/var<\/code> un approccio possibile \u00e8 montarlo in una partizione separata accessibile in scrittura, mentre il \/<\/code> stesso viene montato solo in lettura. Un'altra alternativa popolare \u00e8 l'uso di montaggi bind o overlay.<\/p>\n

Mounts collegabili e sovrapposti, utilizzo come contenitori<\/b> <\/p>\n

Esecuzione del comando man mount<\/code> \u2013 il modo migliore per conoscere i mount collegabili e sovrapposti, che consentono a sviluppatori e amministratori di sistema di creare un file system in un percorso e poi fornirlo a delle applicazioni in un altro. Per i sistemi embedded, questo significa la possibilit\u00e0 di memorizzare file in \/var<\/code> su un'unit\u00e0 flash in sola lettura, ma il montaggio sovrapposto o collegato di un percorso da tmpfs<\/code> in \/var<\/code> al boot consentir\u00e0 alle applicazioni di scriverci delle annotazioni. Al successivo avvio, le modifiche a \/var<\/code> andrebbero perse. Il montaggio sovrapposto crea una fusione tra tmpfs<\/code> e il file system sottostante, permettendo di fare apparenti modifiche ai file esistenti in ro-tootf<\/code> mentre il montaggio collegato pu\u00f2 far vedere nuove cartelle vuote come accessibili per la scrittura in tmpfs<\/code> percorsi. Mentre ro-rootfs<\/code> overlayfs \u00e8 il tipo corretto (<\/code> proper) di file system, il montaggio collegato \u00e8 implementato nello<\/code>spazio dei nomi VFS Basandosi sulla descrizione dei montaggi sovrapposti e collegati, nessuno si sorprende che<\/a><\/noindex>.<\/p>\n

i container Linux li utilizzino attivamente. Osserviamo cosa succede quando utilizziamo<\/a><\/noindex> per avviare un container, usando lo strumento systemd-nspawn<\/a><\/noindex> mountsnoop system-nspawn<\/code> di bcc<\/code>.<\/p>\n

Chiamata avvia il container mentre viene eseguito<\/code> mountsnoop.py durante il \"boot\" del container mostra che l'ambiente di esecuzione del container dipende fortemente dal montaggio collegato (Viene mostrato solo l'inizio di un lungo output).<\/code>.<\/p>\n

Vediamo cosa \u00e8 stato ottenuto:<\/p>\n

Avvio system-nspawn<\/code> fornisce file selezionati in<\/p>\n

Qui systemd-nspawn<\/code> dell'host nel container come percorsi nel suo procfs<\/code> e sysfs<\/code> . Oltre al rootfs<\/code>MS_BIND flag, che stabilisce il montaggio collegato, alcuni altri flag nel sistema di montaggio definiscono la relazione tra le modifiche nel namespace dell'host e del container. Ad esempio, il montaggio collegato pu\u00f2 either saltare le modifiche in<\/code> nel container, o nasconderle a seconda della chiamata. \/proc<\/code> e \/sys<\/code> Comprendere il funzionamento interno di Linux pu\u00f2 sembrare un compito impossibile, poich\u00e9 il kernel stesso contiene una gigantesca quantit\u00e0 di codice, lasciando da parte le applicazioni dello spazio utente Linux e le interfacce delle chiamate di sistema nelle librerie in linguaggio C, come <\/p>\n

Conclusione<\/b><\/p>\n

Comprendere il funzionamento interno di Linux pu\u00f2 sembrare un compito arduo, poich\u00e9 il kernel stesso contiene una quantit\u00e0 gigantesca di codice, escludendo le applicazioni dello spazio utente di Linux e le interfacce delle chiamate di sistema nelle librerie C, come glibc<\/code>. Uno dei modi per progredire \u00e8 leggere il codice sorgente di un sotto-sistema del kernel, con particolare attenzione alla comprensione delle chiamate di sistema e degli header indirizzati allo spazio utente, cos\u00ec come delle principali interfacce interne del kernel, ad esempio, la tabella operazioni_file<\/code>. Le operazioni sui file seguono il principio \"tutto \u00e8 un file\", quindi gestirle \u00e8 particolarmente piacevole. I file sorgente del kernel in linguaggio C si trovano nella directory principale fs\/<\/code> e rappresentano l'implementazione dei sistemi di file virtuali, che sono uno strato di interfaccia che fornisce una compatibilit\u00e0 ampia e relativamente semplice con i sistemi di file e i dispositivi di archiviazione pi\u00f9 popolari. Il montaggio tramite binding e sovrapposizione attraverso i namespace di Linux \u00e8 la magia del VFS, che rende possibile la creazione di container e sistemi di file di root in sola lettura. In combinazione con lo studio del codice sorgente, lo strumento kernel eBPF e la sua interfaccia bcc<\/code>
\n rendono la ricerca nel kernel pi\u00f9 semplice che mai.<\/p>\n

Amici, fatemi sapere se questo articolo \u00e8 stato utile per voi? Forse avete qualche commento o osservazione? E per chi \u00e8 interessato al corso \"Amministratore Linux\", vi invitiamo al giornata di porte aperte<\/a><\/noindex>, che si terr\u00e0 il 18 aprile.<\/p>\n

Prima parte.<\/a><\/noindex>
\n
Fonte: 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\udd47Sistemi di file virtuali in Linux: a cosa servono e come funzionano? Parte 2 | ProHoster","description":"Ciao a tutti, condividiamo con voi la seconda parte della pubblicazione \"Sistemi di file virtuali in Linux: perch\u00e9 sono necessari e come funzionano?\" \u00c8 possibile leggere la prima parte","canonical_url":"https:\/\/prohoster.info\/it\/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":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/31333","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=31333"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31333\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/23299"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=31333"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=31333"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=31333"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}