Partitionnement du serveur Unix et disposition du système de fichiers

Il y a beaucoup d'informations contradictoires sur le partitionnement du serveur Unix sur Internet, j'ai donc besoin de quelques conseils sur la façon de procéder.

Jusqu'à présent, sur les serveurs I dans notre environnement de test, je ne me souciais pas vraiment du partitionnement et j'ai configuré un seul monolithique /plus une partition de swap. Ce schéma de partitionnement ne semble pas être une bonne idée pour nos serveurs de production. J'ai trouvé un bon point de départ ici , mais il semble très vague sur les détails.

Fondamentalement, j'ai un serveur sur lequel je vais exécuter une pile LAMP de base (Apache, PHP et MySQL). Il devra gérer les téléchargements de fichiers (jusqu'à 2 Go). Le système dispose d'une matrice RAID 1 de 2 To.

Je prévois de définir:

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

Est-ce que cela semble sain d'esprit, ou suis-je trop compliqué?

Une chose à garder à l'esprit lors de la disposition de vos partitions sont les modes de défaillance. Cette question est généralement de la forme: "Que se passe-t-il lorsque la partition x se remplit?" Dearest voretaq7 a soulevé la situation avec un plein /causant un certain nombre de problèmes difficiles à diagnostiquer. Regardons quelques situations plus spécifiques.

Que se passe-t-il si votre partition contenant des journaux est pleine? Vous perdez des données d'audit / de rapport et est parfois utilisé par des attaquants pour masquer leur activité. Dans certains cas, votre système n'authentifiera pas les nouveaux utilisateurs s'il ne peut pas enregistrer leur événement de connexion.

Que se passe-t-il sur un système basé sur RPM lorsqu'il /varest plein? Le gestionnaire de packages n'installe ni ne met à jour les packages et, selon votre configuration, peut échouer en silence.

Remplir une partition est facile, surtout lorsqu'un utilisateur est capable d'y écrire. Pour le plaisir, exécutez cette commande et voir comment vous pouvez rapidement créer un fichier assez grand: cat /dev/zero > zerofile.

Cela va au-delà du remplissage des partitions également, lorsque vous placez des emplacements sur différents points de montage, vous pouvez également personnaliser leurs options de montage.

Que se passe-t-il lorsque /dev/n'est pas monté avec noexec? Comme il /devest généralement supposé être maintenu par le système d'exploitation et ne contenir que des périphériques, il était fréquemment (et parfois encore) utilisé pour masquer les programmes malveillants. Le fait de quitter noexecpermet de lancer des fichiers binaires qui y sont stockés.

Pour toutes ces raisons, et plus encore, de nombreux guides de durcissement discuteront du partitionnement comme l'une des premières étapes à effectuer. En fait, si vous construisez un nouveau serveur, la façon de partitionner le disque est presque exactement la première chose que vous devez décider, et souvent la plus difficile à modifier ultérieurement. Il existe un groupe appelé Center for Internet Security qui produit des tas de guides de configuration faciles à lire. Vous pouvez probablement trouver un guide pour votre système d'exploitation spécifique et voir les détails qu'ils pourraient dire.

Si nous regardons RedHat Enterprise Linux 6, le schéma de partitionnement recommandé est le suivant:

# 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

Le principe derrière toutes ces modifications est de les empêcher de se toucher et / ou de limiter ce qui peut être fait sur une partition spécifique. Prenez /tmppar exemple les options . Cela signifie qu'aucun nœud de périphérique ne peut y être créé, aucun programme ne peut être exécuté à partir de là, et le bit set-uid ne peut être défini sur rien. De par sa nature même, il /tmpest presque toujours accessible en écriture dans le monde entier et est souvent un type spécial de système de fichiers qui n'existe qu'en mémoire. Cela signifie qu'un attaquant pourrait l'utiliser comme un point de transfert facile pour supprimer et exécuter du code malveillant, puis planter (ou simplement redémarrer) le système effacera toutes les preuves. Étant donné que la fonctionnalité de /tmpne nécessite aucune de ces fonctionnalités, nous pouvons facilement désactiver les fonctionnalités et éviter cette situation.

Les lieux de stockage des journaux, /var/loget /var/log/auditsont cloisonner le tampon pour les aider à l' épuisement des ressources. De plus, auditd peut effectuer certaines tâches spéciales (généralement dans des environnements à sécurité élevée) lorsque son stockage de journaux commence à se remplir. En le plaçant sur sa partition, cette détection de ressources fonctionne mieux.

Pour être plus verbeux et citer mount(8), c'est exactement ce que sont les options utilisées ci-dessus:

noexec Ne pas autoriser l'exécution directe de fichiers binaires sur le système de fichiers monté. (Jusqu'à récemment, il était de toute façon possible d'exécuter des binaires en utilisant une commande comme /lib/ld*.so / mnt / binary. Cette astuce échoue depuis Linux 2.4.25 / 2.6.0.)

nodev N'interprète pas les caractères et ne bloque pas les périphériques spéciaux du système de fichiers.

nosuid Ne permet pas aux bits set-user-identifier ou set-group-identifier de prendre effet. (Cela semble sûr, mais est en fait plutôt dangereux si suidperl (1) est installé.)

Du point de vue de la sécurité, ce sont de très bonnes options à connaître car elles vous permettront de mettre des protections sur le système de fichiers lui-même. Dans un environnement hautement sécurisé, vous pouvez même ajouter l' noexecoption à /home. Il sera plus difficile pour votre utilisateur standard d'écrire des scripts shell pour le traitement des données, par exemple l'analyse des fichiers journaux, mais cela les empêchera également d'exécuter un binaire qui élèvera les privilèges.

N'oubliez pas non plus que le répertoire de base par défaut de l'utilisateur root est /root. Cela signifie qu'il sera dans le /système de fichiers, pas dans /home.

Le montant exact que vous donnez à chaque partition peut varier considérablement en fonction de la charge de travail du système. Un serveur typique que j'ai géré nécessitera rarement une interaction avec une personne et, en tant que tel, la /homepartition n'a pas besoin d'être très grande du tout. La même chose s'applique /varcar elle a tendance à stocker des données plutôt éphémères qui sont créées et supprimées fréquemment. Cependant, un serveur Web utilise généralement /var/wwwcomme terrain de jeu, ce qui signifie que celui-ci doit également être sur une partition distincte ou /var/doit être agrandi.

Dans le passé, j'ai recommandé ce qui suit comme références.

# 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

Ceux-ci doivent être examinés et ajustés en fonction de l'objectif du système et du fonctionnement de votre environnement. Je recommanderais également d'utiliser LVM et de ne pas allouer l'intégralité du disque. Cela vous permettra d'agrandir ou d'ajouter facilement des partitions si de telles choses sont nécessaires.

En ignorant la matrice RAID sous-jacente ( voir cette question pour plus de détails sur les niveaux de matrice RAID et quand vous voulez les utiliser ), concentrons-nous sur la question centrale que vous posez:
"Comment dois-je disposer les systèmes de fichiers de mon serveur Unix?"

Quel est le problème avec une /partition géante ?

Comme vous l'avez noté dans votre question, de nombreuses distributions Linux (en particulier les distributions "Desktop" comme Ubuntu) utilisent une disposition de système de fichiers très simple: /et [swap].

Ce schéma a l'avantage de la simplicité - il est idéal pour les utilisateurs DOS / Windows qui sont habitués à leur PC personnel avec "le disque dur" comme un grand conteneur monolithique ( C:\) dans lequel vous videz des trucs, et vous n'avez pas à vous inquiéter à propos de manquer d'espace sur les systèmes de fichiers - assurez-vous simplement de rester sous la capacité du disque et tout va (au moins théoriquement) bien.

Le système à système de fichiers unique présente cependant plusieurs inconvénients - l'inconvénient le plus souvent cité est que les systèmes Unix ont tendance à très mal réagir lorsque le système de fichiers racine se remplit (au point de refuser de démarrer), et si tout est écrit sur /(la racine) un programme ou un utilisateur capricieux peut supprimer tout le système.
Un seul système de fichiers volumineux est également susceptible de représenter une perte totale en cas de panne du système et de corruption du système de fichiers.

Les problèmes ci-dessus, ainsi qu'un fort sens de l'organisation, expliquent pourquoi les serveurs Unix ont généralement plusieurs systèmes de fichiers.

Comment divisez-vous le système de fichiers Unix?

J'espère donc que vous êtes convaincu qu'il est logique d'avoir plusieurs systèmes de fichiers. La question est maintenant de savoir comment diviser le système en morceaux logiques et comment décider combien d'espace chacun obtient?
La réponse est que vous connaissez et comprenez ce que votre système d'exploitation va mettre où. Le point de départ de cette compréhension est la hierpage de manuel. La plupart des systèmes Unix sont fournis avec (à man hierpartir d'un système Linux et man hierd'un système BSD ), et cela, plus votre connaissance locale de ce que le code que vous installez va faire, vous guidera dans la création d'une disposition de partitionnement saine.

Je vais décrire ici un schéma général de partitionnement, mais ce schéma doit toujours être modifié pour répondre à vos besoins spécifiques.

Un schéma de partitionnement Unix général

/
    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.

Systèmes de fichiers spéciaux

/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.

La pratique de découper le système de fichiers comme ça remonte à l'époque où il n'y avait pas de raid logiciel, et les lecteurs de disque étaient petits, donc vous deviez en utiliser plusieurs, et donc, la seule façon de le faire était de casser le système de fichiers et mettre différents répertoires sur différents lecteurs. L'autre raison historique était que vous pouviez facilement démonter une partition et la dumpsauvegarder, ce que vous ne pouviez pas faire avec la racine. Cet outil est largement tombé en disgrâce ces jours-ci et peut à la place être utilisé sur un instantané LVM même sur la racine.

Il n'y a plus ou peu de raison de le faire. La seule raison qui reste à faire est de vouloir, par exemple, empêcher /tmpde remplir tout le disque.

Cette raison est largement hors de propos ces jours-ci, car la fourniture aux utilisateurs d'un accès shell général a disparu, et ces jours-ci, les serveurs exécutent des services dédiés, tels que des serveurs Web ou de messagerie. Étant donné que vous n'avez pas d'utilisateurs aléatoires capables d'exécuter des commandes arbitraires, vous n'avez généralement pas à vous soucier qu'ils essaient de remplir votre système de fichiers (et même lorsque vous l'avez fait, vous aviez des quotas de disque pour arrêter cela).

En ce qui concerne le niveau de raid à utiliser, vous devez vous rappeler que le but principal du raid n'est pas de protéger les données (c'est à cela que servent les sauvegardes), mais de maintenir la disponibilité. Si vous /tmplancez un raid0, votre serveur tombera quand même et vous devrez aller le réparer si l'un des disques tombe en panne. Vous pouvez également utiliser raid10 au lieu de raid1 afin d'obtenir également de meilleures performances.

Une très bonne raison de NE PAS casser le système de fichiers est que si vous vous trompez d'allocations, vous pouvez vous retrouver avec une partie du système de fichiers pleine malgré qu'il y ait beaucoup d'espace libre ailleurs. Corriger cela peut être difficile, sauf si vous utilisez LVM et que vous avez laissé un espace non attribué.

Beaucoup d'informations de partitionnement ont été générées lorsque l'espace disque était insuffisant. En conséquence, vous verrez des partitions relativement petites pour un certain nombre de cas. Les tailles de partition requises varient en fonction de l'utilisation du serveur. La plus variable ont tendance à être /tmp, /var, home, /optet /srv. /usra tendance à être d'une taille raisonnable et stable. L'espace pour /peut inclure une ou toutes les autres partitions et leurs besoins d'espace. Le dimensionnement dépend vraiment de ce que vous faites du système.

J'augmenter swapet monter /tmpsur tmpfs. Vous /tmputiliserez ensuite swap comme magasin de sauvegarde, mais utilisez la mémoire disponible. La taille de votre /tmpapparence est extrêmement élevée, mais gérera les téléchargements interrompus qui ne sont pas nettoyés.

J'envisagerais de déplacer les fichiers MySQL vers /srv. Il s'agit d'un niveau relativement nouveau dans la hiérarchie des disques.

Si vous ne connaissez pas vos besoins ultimes, envisagez d'utiliser LVM et d'étendre vos partitions en tant que remplissage.

En fonction de votre architecture - il se peut que vous ne souhaitiez pas réellement utiliser / tmp car il est effacé après chaque redémarrage. Si votre site traite d'un traitement éventuel des téléchargements, le changer en un autre emplacement (via php.ini) peut être une idée; dans lequel vous pouvez en faire n'importe quel point de montage.

Comme suggéré précédemment, il est fortement recommandé d'utiliser LVM et d'incrémenter au besoin.

Je recommanderais également fortement une partition dédiée pour les données MySQL (vous pouvez toujours la monter sous / var / lib / mysql).