Partizionamento server Unix e layout del filesystem


29

Ci sono molte informazioni contraddittorie sul partizionamento del server Unix su Internet, quindi ho bisogno di qualche consiglio su come procedere.

Finora, sui server nel mio ambiente di test non mi importava molto del partizionamento e ho configurato un singolo monolitico /più una partizione di swap. Questo schema di partizionamento non sembra una buona idea per i nostri server di produzione. Ho trovato un buon punto di partenza qui , ma sembra molto vago nei dettagli.


Fondamentalmente ho un server su cui eseguirò uno stack LAMP di base (Apache, PHP e MySQL). Dovrà gestire i caricamenti di file (fino a 2 GB). Il sistema ha un array RAID 1 da 2 TB.

Ho intenzione di impostare:

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

Sembra sano o sto complicando troppo le cose?


1
Qual è il tuo obiettivo finale? Cosa stai cercando di realizzare esattamente?
Scott Pack,

9
Comunque tu decida di ritagliarlo, suggerirei di usare LVM per definire le tue partizioni e quindi allocare lo spazio in modo conservativo, lasciando un po 'di spazio su disco non allocato. Quindi, quando decidi che hai bisogno di più spazio da qualche parte, puoi semplicemente estendere LV e il filesystem.
ktower,

Risposte:


33

Una cosa da tenere a mente quando si delineano le partizioni sono le modalità di fallimento. In genere quella domanda ha il seguente formato: "Cosa succede quando la partizione x si riempie?" Caro voretaq7 ha sollevato la situazione con un pieno /causa di un numero qualsiasi di problemi difficili da diagnosticare. Diamo un'occhiata ad alcune situazioni più specifiche.

Cosa succede se la partizione in cui sono archiviati i registri è piena? Si perdono dati di auditing / reporting e talvolta vengono utilizzati dagli aggressori per nascondere la propria attività. In alcuni casi, il sistema non autentica i nuovi utenti se non è in grado di registrare il loro evento di accesso.

Cosa succede su un sistema basato su RPM quando /varè pieno? Il gestore pacchetti non installa o aggiorna i pacchetti e, a seconda della configurazione, potrebbe non riuscire in modo invisibile all'utente.

Riempire una partizione è facile, specialmente quando un utente è in grado di scriverla. Per divertimento, eseguire questo comando e vedere quanto velocemente si può fare una grande lima abbastanza: cat /dev/zero > zerofile.

Oltre a riempire anche le partizioni, quando posizioni posizioni su punti di montaggio diversi puoi anche personalizzare le loro opzioni di montaggio.

Cosa succede quando /dev/non viene montato noexec? Poiché in /devgenere si presume che sia gestito dal sistema operativo e contenga solo dispositivi, è stato spesso (e talvolta è ancora) utilizzato per nascondere programmi dannosi. Uscire noexecconsente di avviare i binari memorizzati lì.

Per tutti questi motivi e molti altri, molte guide di indurimento discuteranno del partizionamento come uno dei primi passi da eseguire. In realtà, se si sta costruendo un nuovo server come partizionare il disco è quasi esattamente la prima cosa che si deve decidere su, e spesso il più difficile da cambiare in seguito. Esiste un gruppo chiamato Center for Internet Security che produce guide di configurazione facili da leggere. Probabilmente puoi trovare una guida per il tuo sistema operativo specifico e vedere eventuali dettagli che potrebbero dire.

Se osserviamo RedHat Enterprise Linux 6, lo schema di partizionamento consigliato è questo:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

Il principio alla base di tutti questi cambiamenti è quello di impedire che si influenzino a vicenda e / o limitare ciò che può essere fatto su una partizione specifica. Prendi le opzioni /tmpper esempio. Ciò che dice è che nessun nodo di dispositivo può essere creato lì, nessun programma può essere eseguito da lì e il bit set-uid non può essere impostato su nulla. Per sua stessa natura, /tmpè quasi sempre scrivibile dal mondo ed è spesso un tipo speciale di filesystem che esiste solo in memoria. Ciò significa che un utente malintenzionato potrebbe utilizzarlo come un semplice punto di staging per eliminare ed eseguire codice dannoso, quindi il crash (o semplicemente il riavvio) del sistema eliminerà tutte le prove. Poiché la funzionalità di /tmpnon richiede nessuna di quelle funzionalità, possiamo facilmente disabilitare le funzionalità e prevenire quella situazione.

Le posizioni di archiviazione dei registri vengono /var/loge /var/log/auditvengono eliminate per contribuire a respingerle dall'esaurimento delle risorse. Inoltre, auditd è in grado di eseguire alcune operazioni speciali (in genere in ambienti con sicurezza più elevata) quando l'archiviazione del registro inizia a riempirsi. Posizionandolo sulla sua partizione questo rilevamento delle risorse funziona meglio.

Per essere più prolisso e per citare mount(8), questo è esattamente ciò che sono le opzioni usate sopra:

noexec Non consentire l'esecuzione diretta di alcun file binario sul file system montato. (Fino a poco tempo fa era possibile eseguire comunque i binari usando un comando come /lib/ld*.so / mnt / binary. Questo trucco fallisce da Linux 2.4.25 / 2.6.0.)

nodev Non interpretare i caratteri o bloccare dispositivi speciali sul file system.

nosuid Non consentire che i bit set-user-identifier o set-group-identifier abbiano effetto. (Questo sembra sicuro, ma in realtà è piuttosto pericoloso se hai installato suidperl (1).)

Dal punto di vista della sicurezza, queste sono ottime opzioni da sapere poiché ti permetteranno di mettere protezioni sul filesystem stesso. In un ambiente altamente sicuro è anche possibile aggiungere l' noexecopzione a /home. Renderà più difficile per l'utente standard la scrittura di script di shell per l'elaborazione dei dati, ad esempio l'analisi dei file di registro, ma impedirà loro di eseguire un file binario che aumenterà i privilegi.

Inoltre, tieni presente che la home directory predefinita dell'utente root è /root. Questo significa che sarà nel /filesystem, non in /home.

La quantità esatta assegnata a ciascuna partizione può variare notevolmente a seconda del carico di lavoro del sistema. Un server tipico che ho gestito richiede raramente l'interazione personale e come tale la /homepartizione non deve essere molto grande. Lo stesso vale per il /varfatto che tende a memorizzare dati piuttosto effimeri che vengono creati ed eliminati frequentemente. Tuttavia, un server Web utilizza in genere /var/wwwcome campo giochi, il che significa che deve essere anche su una partizione separata o /var/deve essere ingrandito.

In passato ho raccomandato quanto segue come baseline.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

Questi devono essere rivisti e adattati in base allo scopo del sistema e al modo in cui opera l'ambiente. Consiglierei anche di usare LVM e di non allocare l'intero disco. Ciò ti consentirà di ampliare o aggiungere facilmente partizioni se tali cose sono necessarie.


1
L' noexecosservazione è importante in generale: è consigliabile montare /tmpcon il noexecflag per evitare che utenti malintenzionati caricino i rootkit attraverso exploit di sicurezza del browser. Allo stesso modo /homeviene spesso montato nosuidpoiché non esiste alcun motivo per cui i binari setuid siano presenti. Ri: /deve noexec, su molti (anche se non tutti) i sistemi moderni /devè spesso un devfsfilesystem e non consente agli utenti di creare / archiviare file regolari (Su FreeBSD restituisce " Operation not supported", su Ubuntu il udevfilesystem montato /devconsente di creare file regolari. ).
voretaq7,

2
@ voretaq7: Sì, l'utilizzo /tmpcome trampolino di lancio è molto divertente poiché è sempre presente e quasi mai bloccato.
Scott Pack,

Grazie per questi consigli. Controllerò noexec in quanto migliora la sicurezza!
Buzut,

12

Ignorando l'array RAID sottostante ( vedi questa domanda per maggiori dettagli sui livelli dell'array RAID e quando vuoi usarli ), concentriamoci sulla domanda principale che mi stai ponendo:
"Come devo disporre i file system del mio server Unix?"


Cosa c'è che non va in una /partizione gigante ?

Come hai notato nella tua domanda, molte distribuzioni Linux (specialmente le distribuzioni "Desktop" come Ubuntu) usano un layout di filesystem molto semplice: /e [swap].

Questo schema ha il vantaggio della semplicità : è ottimo per gli utenti DOS / Windows che sono abituati al loro PC di casa con "il disco rigido" come un grande contenitore monolitico ( C:\) in cui si scarica materiale e non bisogna preoccuparsi sull'esaurimento dello spazio sui filesystem - assicurati di rimanere sotto la capacità del disco e che tutto (almeno teoricamente) vada bene.

Lo schema a file singolo presenta diversi svantaggi: lo svantaggio più spesso citato è che i sistemi Unix tendono a reagire molto male quando il filesystem di root si riempie (al punto di rifiutarsi di avviarsi) e se tutto sta scrivendo /(root) un programma ribelle o un utente possono eliminare l'intero sistema.
Un singolo filesystem di grandi dimensioni è anche soggetto a una perdita totale in caso di crash del sistema e conseguente danneggiamento del filesystem.

I problemi di cui sopra, oltre a un forte senso dell'organizzazione, è il motivo per cui i server Unix hanno in genere più file system.


Come si scompone il filesystem Unix?

Quindi spero che tu sia convinto che avere più filesystem abbia senso. La domanda ora è come suddividere il sistema in blocchi logici e come si decide quanto spazio occupa ciascuno?
La risposta è sapere e capire quale sistema operativo metterà dove. Il punto di partenza per questa comprensione è la hierpagina man. La maggior parte dei sistemi Unix viene fornita ( man hierda un sistema Linux e man hierda un sistema BSD ) e questo, oltre alla tua conoscenza locale di ciò che il codice che stai per fare, ti guiderà nella creazione di un layout di partizionamento sano.

Descriverò qui uno schema generale di partizionamento, ma questo schema dovrebbe sempre essere modificato per soddisfare le vostre esigenze specifiche.

Uno schema generale di partizionamento Unix

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

Filesystem speciali

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

2
I due motivi che hai elencato oggi sono in gran parte obsoleti. ext [234] riserva un po 'di spazio per root e non consentirà ai programmi utente di utilizzarlo tutto in modo che il sistema non abbia problemi con lo spazio esaurito e tutti i moderni filesystem utilizzano il journaling in modo che non vengano danneggiati dopo un incidente.
psusi,

2
@psusi Lo spazio riservato all'utente root (di solito il 5-10% della dimensione del filesystem) non aiuta se l'utente root è quello che scrive i file che riempiono il disco (come spesso accade con i file di registro). È anche errato supporre che solo perché un filesystem è registrato su giornale sarà sempre al sicuro dalla corruzione - il journaling aumenta la robustezza, ma non garantisce la sicurezza (in particolare se ci si imbatte in un bug non scoperto nel file system / codice journaling e si accartoccia il journal - Le persone di ReiserFS possono raccontare grandi storie a riguardo fin dai primi giorni di quel filesystem).
voretaq7,

2
Avere un intatto /usro /varnon aiuta se /è danneggiato. Allo stesso modo avere un intatto /non aiuta (molto) se /homeè corrotto. Alla fine devi ripristinare dal backup in entrambi i modi. Per non parlare di tali guasti sono uno su un milione a meno che non si stia eseguendo un fs nuovo / instabile.
psusi,

4

La pratica di intagliare il filesystem in quel modo è dai tempi in cui non vi era alcun raid di software e le unità disco erano piccole, quindi è stato necessario utilizzarne diversi, e quindi l'unico modo per farlo era quello di rompere il filesystem e mettere directory diverse su unità diverse. L'altro motivo storico è stato quello di poter facilmente smontare una partizione e dumpper il backup, cosa che non si poteva fare con il root. Al giorno d'oggi questo strumento è in gran parte sfavorito e può invece essere utilizzato su un'istantanea LVM anche sul root.

Non c'è più alcun motivo per farlo. L'unico motivo che rimane per farlo è se, ad esempio, si desidera impedire il /tmpriempimento dell'intero disco.

Questo motivo è in gran parte irrilevante in questi giorni perché gli utenti di prova con accesso generale alla shell sono passati di lato e in questi giorni i server eseguono servizi dedicati, come i server Web o di posta. Dato che non hai utenti casuali in grado di eseguire comandi arbitrari, in genere non devi preoccuparti che provino a riempire il tuo filesystem (e anche quando lo hai fatto, hai avuto quote di disco per fermarlo).

Per quanto riguarda il livello di raid da utilizzare, è necessario ricordare che lo scopo principale del raid non è proteggere i dati (ecco a cosa servono i backup), ma mantenere i tempi di attività. Se fai /tmpun raid0, il tuo server continuerà a non funzionare e dovresti andare a ripararlo se uno dei dischi fallisce. Potresti anche voler usare raid10 invece di raid1 in modo da ottenere prestazioni migliori.

Un ottimo motivo per NON rompere il filesystem è che se sbagli le allocazioni, puoi finire con una parte del filesystem piena nonostante ci sia molto spazio libero altrove. Correggerlo può essere difficile, a meno che non si usi LVM e si lasci spazio non assegnato.


4
Ci sono molte ragioni per continuare a scolpire un filesystem Unix in modo tradizionale. Se non ci fosse motivo per fare questo ci saremmo fermati da ora - amministratori di sistema non sono CHE attaccati alle tradizioni arcane :)
voretaq7

1
@ voretaq7, quindi nominane alcuni. Se non ci riesci, supporre ciecamente che ci debba essere è sciocco.
psusi,

1
Sarebbe opportuno che quei voti negativi fornissero effettivamente una controproposta piuttosto che una saggezza convenzionale del pappagallo cieco.
psusi,

2
Mantiene / var / log dal prendere tutto compilando. Limita la corruzione a un filesystem. Semplifica i backup, sia che si tratti di snapshot o di montare regole di attraversamento, spesso si desidera eseguire il backup delle cose su pianificazioni diverse. Semplifica l'imaging / gli aggiornamenti. Consente la selezione di prestazioni basate su filesystem relative all'attività.
Jeff Ferland,

1
@JeffFerland, nella migliore delle ipotesi questo è un motivo debole per mettere / var / log sulla propria partizione, ma non per le altre altre partizioni. A meno che non si stia ancora utilizzando dump, il backup di diverse parti di fs non richiede che tali parti si trovino su partizioni diverse. Agli aggiornamenti non importa in un modo o nell'altro. Anche l'imaging non è un ottimo modo per fare le cose.
psusi,

3

Molte informazioni sul partizionamento sono state generate quando lo spazio su disco era insufficiente. Di conseguenza vedrai partizioni relativamente piccole per un numero di casi. Le dimensioni delle partizioni richieste variano in base all'utilizzo del server. Il più variabili tendono ad essere /tmp, /var, home, /opt, e /srv. /usrtende ad avere dimensioni ragionevoli e stabili. Lo spazio per /può includere una o tutte le altre partizioni e i loro requisiti di spazio. Il dimensionamento dipende davvero da cosa stai facendo il sistema.

Vorrei aumentare swape montare /tmpsu tmpfs. Si /tmpdovrà quindi utilizzare di swap come archiviazione secondaria, ma la memoria utilizzo come disponibili. La dimensione del tuo /tmpaspetto è estremamente elevata, ma gestirà il caricamento interrotto che non viene ripulito.

Vorrei prendere in considerazione lo spostamento dei file MySQL in /srv. Questo è un livello relativamente nuovo nella gerarchia del disco.

Se non conosci i tuoi requisiti finali, considera l'utilizzo di LVM e l'espansione delle partizioni come riempimento.


Fai attenzione ad aumentare lo swap - È bene avere uno scambio "sufficiente", ma se ne hai troppo non lo userai mai (perché quando stai cambiando pesantemente le prestazioni del sistema sono troppo dolorose). Direi che il 4G proposto nella domanda è probabilmente "sufficiente" per uno stack LAMP - se stai usando 4G di scambio (e in realtà stai pagando dentro e fuori quei dati) probabilmente stai anche urlando al telefono perché il sito web è lento :)
voretaq7,

1
@ voretaq7 Non importa quale sia lo scambio di dimensioni se si utilizza per programmi attivi. Usarlo per tmpfs in cui i file di grandi dimensioni vengono scritti su disco ma i file più piccoli rimangono residenti in memoria è un uso ragionevole dello scambio. Si risparmia sulla scrittura di ogni file su disco quando si intende metterlo altrove. Ho suggerito di aumentare lo spazio di swap perché sembrava che fosse necessario un grande /tmpspazio.
BillThor,

Perché non utilizzare un file normale per lo scambio? Non sono stati veloci come una partizione di swap dedicata per molto tempo?
Chris Smith,

@ChrisSmith Un file normale dovrebbe essere veloce quasi quanto una partizione dedicata, ma potrebbe non essere contiguo sul disco portando a dividere le richieste I / O. Questo può essere compensato da strisce. Inoltre, è relativamente facile eliminare accidentalmente un file di scambio. Il file eliminato non sarà evidente fino al riavvio del sistema, quando non avrà più spazio di scambio.
BillThor,

@BillThor Questo è vero - se stai usando tmpfse ti aspetti di raggiungere lo swap come backing store dovresti avere uno swap "sufficiente" per soddisfare le tue richieste di tmpfs, oltre a una riserva appropriata anche per il sistema. (Questo non è qualcosa a cui penso normalmente dal momento che l'unico sistema in cui utilizzo tmpfsè configurato per non colpire lo scambio, poiché ha un surplus di RAM e sto usando lo spazio temporaneo per piccoli file che vengono creati / eliminati rapidamente :)
voretaq7,

2

A seconda della tua architettura, potresti non voler usare / tmp poiché viene cancellato dopo ogni riavvio. Se il tuo sito si occupa dell'eventuale elaborazione dei caricamenti, può essere un'idea cambiarlo in un'altra posizione (tramite php.ini); in cui è possibile effettuare qualsiasi punto di montaggio.

Come suggerito in precedenza, si consiglia vivamente di utilizzare LVM e incrementare secondo necessità.

Consiglio vivamente anche una partizione dedicata per i dati MySQL (è ancora possibile montarlo in / var / lib / mysql).


In genere è una buona idea presumere che i file /tmppotrebbero non essere presenti in un secondo momento - ti salva da spiacevoli sorprese in seguito :-)
voretaq7
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.