{"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: perch\u00e9 sono utili 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 utili 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 monitorare le VFS utilizzando strumenti eBPF e bcc<\/b><\/p>\n

Il modo pi\u00f9 semplice per capire come il kernel gestisce i file sysfs<\/code> \u00e8 osservarlo in pratica, e il modo pi\u00f9 semplice per osservare ARM64 \u00e8 utilizzare eBPF. eBPF (abbreviazione di Berkeley Packet Filter) consiste in una macchina virtuale eseguita nel kernel<\/a><\/noindex>, che gli utenti privilegiati possono interrogare (query<\/code>) dalla riga di comando. I sorgenti del kernel informano il lettore su ci\u00f2 che pu\u00f2 fare il kernel; l'esecuzione degli strumenti eBPF in un sistema carico mostra cosa fa realmente il kernel. <\/p>\n

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

Fortunatamente, iniziare a utilizzare eBPF \u00e8 abbastanza semplice con gli strumenti bcc<\/a><\/noindex>, disponibili come pacchetti dalla distribuzione generale Linux<\/a><\/noindex> e documentati in dettaglio da Bernard Gregg<\/a><\/noindex>. Strumenti bcc<\/code> \u2013 sono script in Python con piccole sezioni di codice in C, il che significa che chiunque abbia familiarit\u00e0 con entrambe le lingue pu\u00f2 modificarli facilmente. In bcc\/tools<\/code> ci sono 80 script Python, il che implica che probabilmente uno sviluppatore o un amministratore di sistema riuscir\u00e0 a trovare qualcosa di adatto per risolvere il problema.
\nPer avere almeno una visione superficiale del lavoro che svolgono i VFS in un sistema attivo, prova a vfscount<\/code> o vfsstat<\/code>. Questo mostrer\u00e0, ad esempio, che decine di chiamate vfs_open()<\/code> e dei suoi \u00abamici\u00bb si verificano letteralmente ogni secondo.<\/p>\n

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

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

Facciamo un esempio pi\u00f9 triviale 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 vedere cosa accade in \/sys<\/code>, quando una chiavetta USB \u00e8 inserita. Qui viene mostrato un esempio semplice e complesso.<\/p><\/blockquote>\n

Nell'esempio mostrato sopra, bcc<\/code> strumento trace.py<\/a><\/noindex> emette un messaggio quando viene eseguita la funzione sysfs_create_files()<\/code>. Vediamo che sysfs_create_files()<\/code> \u00e8 stato avviato con kworker<\/code> flusso in risposta al fatto che la chiavetta USB \u00e8 stata inserita, ma quale file \u00e8 stato creato? Il secondo esempio mostra tutta la potenza di eBPF. Qui trace.py<\/code> viene visualizzato il backtrace del kernel (opzione -K) e il nome del file che \u00e8 stato creato. sysfs_create_files()<\/code>L'inserimento in frasi singole \u00e8 un codice in C che include 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 riprodotta nel secondo comando, affinch\u00e9 la stringa di formato possa fare riferimento a uno dei parametri. Gli errori in questo frammento di codice C portano a errori riconoscibili del compilatore C. Ad esempio, se si omette il parametro -l, vedrete \u00abFailed to compile BPF text\u00bb. Gli sviluppatori che conoscono bene 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 il flusso kworker<\/code>, che ha creato il file \u00abevents\u00bb<\/code> in sysfs<\/code>. Di conseguenza, la chiamata a sysfs_remove_files()<\/code> mostrer\u00e0 che la rimozione del dispositivo ha portato alla cancellazione del file events<\/code>, che corrisponde al concetto generale del conteggio dei collegamenti. In questo caso, la visualizzazione sysfs_create_link ()<\/code> con eBPF durante l'inserimento di una chiavetta USB mostrer\u00e0 che sono state create almeno 48 symlink.<\/p>\n

Qual \u00e8 quindi il significato del file events? L'uso di cscope<\/a><\/noindex> per trovare __device_add_disk()<\/a><\/noindex>, dimostra che chiama disk_add_events ()<\/code>, e o \"media_change\"<\/code>, oppure \"eject_request\"<\/code> possono essere registrati nel file eventi. Qui, il livello di blocco del kernel informa l'userspace dell'inserimento e dell'estrazione di un 'disco'. Nota quanto sia informativo questo metodo di indagine tramite l'inserimento di una chiavetta USB rispetto ai tentativi di capire come funziona tutto esclusivamente dai sorgenti.<\/p>\n

I filesystem 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 perch\u00e9 i file system montati sui dispositivi di memorizzazione fisica possono avere registrazioni in sospeso e le strutture dati che registrano il loro stato potrebbero non sincronizzarsi con le registrazioni nell'archiviazione. Quando accade, ai proprietari del sistema tocca aspettare il prossimo avvio per eseguire l'utilit\u00e0. fsck recupero filesystem<\/code> e, nel peggiore dei casi, perdere dati. <\/p>\n

Tuttavia, sappiamo tutti che molti dispositivi IoT, cos\u00ec come router, termostati e automobili, ora funzionano con Linux. Molti di questi dispositivi non hanno praticamente interfaccia utente e non c'\u00e8 modo di spegnerli \u00abpulitamente\u00bb. Immagina di avviare un'auto con la batteria scarica, mentre l'alimentazione dell'unit\u00e0 di controllo Linux<\/a><\/noindex> oscilla continuamente. Com'\u00e8 possibile che il sistema si avvii senza un lungo fsck<\/code>, quando finalmente il motore inizia a funzionare? La risposta \u00e8 semplice. I dispositivi embedded si affidano al file system radice soltanto in lettura<\/a><\/noindex> (abbreviato ro-rootfs<\/code> (filesystem di root in sola lettura)). <\/p>\n

ro-rootfs<\/code> offrono numerosi vantaggi, che sono meno ovvi rispetto all'autenticit\u00e0. Uno dei vantaggi \u00e8 che il malware non pu\u00f2 scrivere in \/usr<\/code> o \/lib<\/code>, se nessun processo Linux pu\u00f2 scrivere l\u00ec. Un altro \u00e8 che un filesystem sostanzialmente immutabile \u00e8 fondamentale per il supporto sul campo dei dispositivi remoti, poich\u00e9 il personale di supporto utilizza sistemi locali che sono nominalmente identici ai sistemi sul posto. Probabilmente, 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 gi\u00e0 nella fase di 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 i costi aggiuntivi.<\/p>\n

Creazione rootfs<\/code> la modalit\u00e0 sola lettura richiede alcuni sforzi aggiuntivi per gli sviluppatori di sistemi embedded, ed \u00e8 qui che entra in gioco il VFS. Linux richiede che i file in \/var<\/code> erano disponibili per la registrazione e, inoltre, molti applicativi 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 solitamente la loro generazione anticipata e assemblaggio in rootfs<\/code>. Per \/var<\/code> uno dei possibili approcci \u00e8 montarlo in una partizione separata, accessibile in scrittura, mentre il filesystem stesso \/<\/code> \u00e8 montato solo in lettura. Un'altra alternativa popolare \u00e8 l'uso di mount bind o overlay.<\/p>\n

I mount bind e overlay, utilizzati dai contenitori<\/b> <\/p>\n

Esecuzione del comando man mount<\/code> \u00e8 il modo migliore per conoscere i mount bind e overlay, che consentono a sviluppatori e amministratori di sistema di creare un filesystem in un percorso e poi fornirlo alle applicazioni in un altro. Per i sistemi embedded, questo significa la possibilit\u00e0 di conservare file in \/var<\/code> su una flash drive accessibile solo in lettura, ma il montaggio overlay o bind di un percorso da tmpfs<\/code> in \/var<\/code> il caricamento permetter\u00e0 alle applicazioni di registrare note l\u00ec (scrawl). Al successivo avvio, le modifiche a \/var<\/code> saranno perse. Il montaggio sovrapposto crea un'unione tra tmpfs<\/code> e il filesystem sottostante e consente di apportare modifiche apparenti ai file esistenti in ro-tootf<\/code> mentre il montaggio collegato pu\u00f2 rendere nuove cartelle vuote tmpfs<\/code> visibili come accessibili per la scrittura in ro-rootfs<\/code> percorsi. Mentre overlayfs<\/code> \u00e8 il tipo corretto (proper<\/code>) di filesystem, il montaggio collegato \u00e8 implementato nello spazio dei nomi VFS<\/a><\/noindex>.<\/p>\n

Basandosi sulla descrizione del montaggio sovrapposto e collegato, nessuno si sorprende che i container Linux<\/a><\/noindex> li utilizzano attivamente. Osserviamo cosa succede quando usiamo systemd-nspawn<\/a><\/noindex> per avviare un container, utilizzando lo strumento mountsnoop<\/code> da bcc<\/code>.<\/p>\n

La chiamata system-nspawn<\/code> avvia un container durante il funzionamento mountsnoop.py<\/code>.<\/p>\n

Vediamo cosa \u00e8 uscito:<\/p>\n

Avvio mountsnoop<\/code> durante il 'caricamento' del container dimostra che l'ambiente di esecuzione del container dipende fortemente dal montaggio collegato (viene mostrato solo l'inizio di un lungo output).<\/p>\n

Qui systemd-nspawn<\/code> fornisce i file selezionati nel procfs<\/code> e sysfs<\/code> host nel container come percorsi nel suo rootfs<\/code>. Oltre a MS_BIND<\/code> Il flag che stabilisce il montaggio bind, cos\u00ec come altri flag nel sistema di montaggio, definiscono la relazione tra le modifiche nello spazio dei nomi dell'host e del container. Ad esempio, il montaggio bind pu\u00f2 sia ignorare le modifiche nel \/proc<\/code> e \/sys<\/code> container, sia nasconderle a seconda della chiamata. <\/p>\n

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

Capire il funzionamento interno di Linux pu\u00f2 sembrare un compito impossibile, dato che il kernel stesso contiene una quantit\u00e0 enorme di codice, trascurando le applicazioni dello spazio utente di Linux e le interfacce delle syscall nelle librerie in C, come glibc<\/code>. Un modo per progredire \u00e8 leggere il codice sorgente di un sottosistema del kernel con l'accento sulla comprensione delle syscall e delle intestazioni rivolte allo spazio utente, cos\u00ec come delle principali interfacce interne del kernel, per esempio, la tabella file_operations<\/code>. Le operazioni sui file seguono il principio \"tutto \u00e8 un file\", quindi gestirle \u00e8 particolarmente gratificante. I file sorgenti del kernel in C si trovano nella directory di alto livello. fs\/<\/code> rappresentano l'implementazione dei file system virtuali, che costituiscono uno strato di interfaccia garantendo una compatibilit\u00e0 ampia e relativamente semplice tra i file system e i dispositivi di archiviazione pi\u00f9 diffusi. Il montaggio con binding e overlay attraverso i namespace Linux \u00e8 la magia del VFS, che rende possibile la creazione di contenitori e file system root soltanto in lettura. Combinato con lo studio del codice sorgente, lo strumento kernel eBPF e la sua interfaccia. bcc<\/code>
\n rendono l'esplorazione del kernel pi\u00f9 semplice che mai.<\/p>\n

Amici, fateci sapere se questo articolo \u00e8 stato utile per voi! Potreste avere commenti o osservazioni? E a coloro a cui interessa il corso \"Amministratore Linux\", invitiamo a giorno delle 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\udd47 Sistemi 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: a cosa servono e come funzionano?\" La prima parte pu\u00f2 essere letta qui. Ricordiamo che questa serie di pubblicazioni \u00e8 dedicata al lancio di un nuovo flusso del corso \"Amministratore Linux\", che inizier\u00e0 molto presto. Come monitorare il VFS utilizzando strumenti eBPF e bcc Il pi\u00f9 semplice","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 \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","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}]}}