# [serveur] Discussion générale sur les serveurs

## 22decembre

Je souhaiterais ici lancer une discussion sur les serveurs et leur installation.

La documentation fournit des bases pour l'installation et dit : "adaptez à votre cas et débrouillez-vous..." Ceci n'est pas une solution !

Contrairement à un pc de bureau, par nature non-critique et que l'on reboote frequement (donc le noyau peut être mis à jour très facilement, optimisé et correctement configuré en compilation...), un serveur ne peut être facilement modifié.

Je propose donc ici de donner vos differents trucs et astuces qui concernent vos serveurs, mais aussi vos erreurs. Vous pouvez donner votre plan de partitionnement et dans ce cas "pourquoi j'ai mis une enorme partition /var... avec un fs ultra specifique", vos options noyau préferées...

Et donc le deuxième post de ce topic concernera mon cas particulier.

----------

## 22decembre

Sur mon serveur, j'ai deux disques durs :

Un gros de 500 Go (exactement 460 je crois...) sur lequel j'avais au départ installé ubuntu en trois partitions : swap (500 Mo), / (2G), /home (le reste).

Quand je suis passé à gentoo, j'ai ajouté un autre disque de 20 Go avec : swap (500 Mo), /var (6 Go), / (12 Go) et un petit /tmp de 500 Mo. Tout est en ext3, et resultat : il y a trois jours, plus d'inodes libres dans /var (aujourd'hui, je tourne à 90% d'inodes prises). Ceci explique pourquoi j'ai lancé cette discussion... En même temps, comment aurais-je pu savoir au moment du montage quelles options passer aux fs et quel fs ?

mon fstab :

```
/dev/ROOT              /               ext3            noatime         1 2

/dev/sda3               /var            ext3            defaults        0 1

/dev/sdb3               /home           ext3            defaults        0 1

/dev/sda1               none            swap            sw              0 0

/dev/sdb1               none            swap            sw              0 0

#/dev/sdb2              /mnt/ubuntu     ext3            defaults                0 0

shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0

/dev/shm                /tmp            tmpfs           defaults                0 0

/tmp                    /var/tmp        none            bind

```

J'ai dû mettre /var/tmp sur /tmp à cause des problèmes d'inodes.

Je crois qu'avoir deux swap sur deux disques améliore un peu les choses puisqu'on y acceder en même temps.

J'ai mis le dossier web dans /home, les mails des gens sont dans le dossier ~/.mail/, finalement, j'ai gardé que mysql dans /var qui est une partition technique. Peut être que je devrais le mettre dans /home aussi... Je sais pas !

----------

## mp342

Pour un serveur, il vaut mieux utiliser LVM. De cette façon, tu n'es pas obligé de tout partitionner dès l'installation, tu fait des partitions suffisamment grandes pour une utilisation classique et tu garde le reste de l'espace pour pouvoir agrandir les partitions au besoin, ça se fait a chaud sans redémarrage.

Par contre, pour les inodes, c'est assez rare qu'avec la taille par défaut tu arrive a saturation. Tu dois avoir quelque chose qui te fabrique des tonnes de petits fichiers genre ccache. Pour ce genre d'application, je préfère leur allouer une partition spécifique dans laquelle je peux définir une taille d'inode plus petite.

----------

## 22decembre

que se passe t-il en cas de crash système ?

----------

## 22decembre

bah alors...

Personne pour continuer la discussion ?

----------

## El_Goretto

Parler boulot un dimanche?  :Laughing: 

----------

## 22decembre

je vois que t'es en hardened...

Pas trop hard et complèxe ?

----------

## El_Goretto

Ben le hardening de base peut se faire sur n'importe quelle machine, profil hardened ou pas, et constitue le fondement d'une bonne install "serveur".

Être en profil gentoo hardened n'a rien de complexe. Configurer un kernel hardened c'est des options en plus gérer. La phase suivante (RBAC) est déjà un poil plus tendue (je suis en train de faire une revue des règles générées par le RBAC/grsec en mode auto apprentissage avant de les appliquer), mais ya de la bonne doc.

Mais çà c'est pour la maison, parce que je le vaux bien  :Smile: 

Disons que s'amuser à jouer avec le hardening c'est une façon d'en apprendre encore plus sur le système et linux.

----------

## 22decembre

je m'étais demandé à un moment si hardened...

J'ai lû un peu la doc, je me suis dis "c'est un truc de parano..." Genre faut régler service par service, logiciel par logiciel, les droits de fonctionnement du bazar ! Alors d'accord, question sécurité, on se pose là, mais c'est pas un peu dûr à gerer ? J'ai lû aussi qu'on pouvait même pas se connecter en root via ssh ! Délire !

Enfin bref... Moi, je reste assez dubitatif ! Mais comme d'habitude, je demande qu'a me laisser convaincre !

----------

## guilc

Hardened ce n'est pas si compliqué que ça n'en a l'air.

- Le premier (énorme) pas est utiliser un noyau patché grsec/pax. Cela apporte pas mal de limitations (zones mémoire non-exécutables, randomisation de certaines piles, interdiction d'accès à proc/kmem/chargement de modules, etc... la liste est longue). Ces limitations ne demandent "rien" à connaitre, et rendent la plupart des exploits qu'il y a eu par le passé sur le noyau linux inopérants : si tu remontes sur les exploits qu'ils y a eu, ils n'étaient pas exploitable sur un noyau grsec/pax en raison simplement des mécanismes de protection mis en place.

Et ça, c'est franchement facile à mettre en place. Il y a quelques programmes qui font des choses pas très catholiques qui en souffrent, et demandent de désactiver certaines protections (via l'utilitaire paxctl), mais rien de dramatique, et jamais sur un serveur. Les seuls programmes qui en souffrent à ma connaissance sont des programmes sous X (Xorg, mozilla, openoffice et compagnie, souvent pour des histoires de trucs codés cradement, relocation de code, mécanismes de chargement de plugin foireux)

- Le deuxième pas, les règles RBAC est beaucoup plus long, et à mon sens moins vital. Alors que les patches grsec/pax visent à "protégrer" le noyau pour rendre les failles de sécurité inexploitables, les règles RBAC visent à restreindre les ressources accessibles aux processus/utilisateurs. On peut ainsi effectivement supprimer les droits de "super-dieu" à root. Tel que je le conçoit, ces limitations visent à limiter la casse en cas d'exploit. à mon sens, si on en arrive là, c'est déjà trop tard. Je considère pour ma part que le rapport "temps passé/utilité" est défavorable, je ne me prends donc plus la tête avec ça (je l'ai fait par le passé).

De toute façon, si un exploit est passé, je formate et repart sur des bases saines. que la machine soit exploitée à fond ou pas ne change pas grand chose : je n'ai pas de données suffisamment confidentielles pour en interdire l'accès au mec qui arrive à passer root sur la machine...

Faire ces règles RBAC est assez/très fastidieux : la base de départ est de passer le système RBAC en mode "apprentissage", ou il monitore tous les accès aux ressources (fichiers/réseau/device, etc...) par les différents processus. A toi ensuite de faire le "ménage" la dedans pour voir ce qu'il y a en trop/manque par rapport à ce qui est nécessaire processus par processus.

----------

## El_Goretto

Je suis totalement d'accord avec toi sur le fait que RBAC n'est pas une protection de première ligne comme les fonctions noyaux grsec&co.

En fait, je trouve RBAC portentiellement intéressant pour étendre les possibilités des gestions de droits "standards" (en gros, reserrer un système dans son fonctionnement normal, pas quand il a été percé). Je n'ai pas encore tout lu, mais il semble y avoir des "restrictions qui sont permises" (ou vice versa plutôt) par RBAC mais pas par le système de base.

Enfin je n'en suis qu'au début du chantier  :Smile: 

----------

## guilc

 *El_Goretto wrote:*   

>  il semble y avoir des "restrictions qui sont permises" (ou vice versa plutôt) par RBAC mais pas par le système de base.

 

Effectivement, puisque RBAC ajoute la notion de... "Rôle" (le R de RBAC) qui n'existe pas sur le système POSIX classique.

Ce qui fait que tu vas définir des autorisations pour un process particulier exécuté par un utilisateur particulier pour accéder à des ressources précises, que le système POSIX ne songe même pas à rendre possible de limiter. Typiquement, autoriser seulement apache à binder le port 80 et aucun autre process. Ce n'est qu'un exemple bien sûr.

La logique POSIX, c'est plus : "qui es-tu ?" => "alors tu accéder à cet ensemble de fichiers/périphériques, le réseau c'est open-bar !"

Avec les rôles, la logique change complètement et ça devient : "qui es-tu et que dois-tu faire ?" => "alors pour faire ton boulot, tu es dans tel rôle, et je te laisse accéder à toutes ces ressources, à tel port, à telle ressource machine, et t'as pas besoin d'autre chose pour le faire". Et ça donne des trucs du genre : "Ahah, mais t'es pas apache toi ! d'où tu veux utiliser le port 80 ?!?!?! casse toi ! (pov' con)"

J'aime bien l'image du réseau, parce que c'est le cas qui montre tout de suite la grosse différence. gestion beaucoup plus fine donc.

C'est pour ça que dans le monde de RBAC root n'est plus rien et perd tous ses pouvoirs. Pour les gagner, il doit rentrer dans le rôle de l'administrateur (gradm -a admin), ce qui permet à l'utilisateur qui rootkite une machine de... ne pouvoir rien faire.

----------

## 22decembre

Ça dévie pas mal du sujet de base, mais qu'importe, c'est la vie ! Peut être, grace à cet appronfondissement de la discussion auront nous un meilleur aperçu de l'installation d'un serveur (qu'il soit hardené ou pas !)

Le hardening, ça m'a l'air bien beau, mais en dehors du noyau, ça m'a surtout l'air d'être un gros outil de sécurité en plus ! Déjà que je ne suis pas sûr d'avoir correctement réglé tout mon serveur, s'il faut rajouter ça ! Et je me dis qu'a chaque fois que tu ajoute un service (certes, c'est pas tous les quatre matins, mais quand même !), tu dois reflechir à comment mettre ça dans les règles, comment s'assurer que le service peut réellement tourner dans les limites que tu lui alloue...

----------

## guilc

C'est toi qui le premier a parlé de hardening hein  :Wink: 

Effectivement, assure toi d'abord d'avoir un serveur correctement configuré.

Il vaut mieux un serveur propre et bien configuré sans RBAC (un noyau ça fait quand même pas de mal, et c'est rien de compliqué), qu'un système mal configuré avec RBAC.

Et faire une bonne conf ça ne se fait pas non plus en 2 secondes. En général, tu as une première conf, avec des paramètres génériques/de base correspondant "au jugé" à ton besoin. Ensuite, une fois le système laché dans la vraie vie, il faut en général lui apporter du soin dans la configuration : tuning de conf de base de données en fonction du besoin, ajustement de paramètres de nombre de connexion maximum (apache, reverse-proxy, etc...), différents timeouts, etc, en fonction des logiciels utilisés. Ca, il n'y a pas de recette miracle, il faut voir en fonction de ton cas !

----------

## 22decembre

Précision : j'ai lancé le sujet sur "comment avez-vous monté votre serveur ?"

J'ai vu que El_Goretto avait un serveur en hardened, je lui ais demandé d'en parler... Je ne me défends ni ne me justifie ! Je précise !

J'aimerai que le truc aille aussi loin qu'il puisse aller, chacun donnant son avis, ses trucs et astuces ! Le hardening, une fois precisé qu'il y avait deux poids deux mesures (juste le noyau, ou le grand branle-bas de combat), me semble une option à retenir.

mp342 n'a semble t-il pas envie de continuer sur lvm, moi ça m'interesse aussi... Quels sont les inconvénients du truc ? En cas de crash system ?

----------

## guilc

 *22decembre wrote:*   

> mp342 n'a semble t-il pas envie de continuer sur lvm, moi ça m'interesse aussi... Quels sont les inconvénients du truc ? En cas de crash system ?

 

Comment ça crash système ? Si un disque meurt ?

Bah ça dépend : 

- si tes lv sont sur un seul disque, ça change rien, LVM ou pas, le disque avec ses données sont morts

- si tes lv sont à cheval sur 2 disques (2 pv sur 2 disques différents donc), tu perdras les données dans les lv qui sont à cheval, donc potentiellement plus que le disque qui crashe. Mais ça c'est pas neuf, il y a le même risque en RAID0.

Mais le LVM a des avantages non négligeables, pour peu que dessus, tu mettes des systèmes de fichier redimensionnables (ext2/3/4 ou reiserfs, je ne mets pas XFS dans le lot car il ne peut pas se réduire, juste s'agrandir).

- scénario 1 : tu gardes un coin du disque non formaté (plus exactement, dans un PV/VG mais non alloué). Un jour, ton /var vient à être trop petit => un petit coup de lvextend, et tu prend de l'espace libre du VG pour le mettre dans le LV contenant /var, et un petit coup de resize2fs plus tard, ton /var a grandi. Plutôt pratique non ?

- scénario 2 : tu t'apperçois que ton /usr est bien trop grand. hop hop, tu le réduis (resize2fs, lvreduce et re resize2fs pour ajustement), tu récupère ainsi de l'espace dans ton pv, que tu peux réalouer ailleurs, sans te soucier de l'emplacement physique sur le disque.

- scénario 3 : tu ajoutes un nouveau disque, et tu voudrais agrandir ton /home. Facile ! tu crée un nouveau PV sur le nouveau disque, et tu l'ajoutes à ton VG courant, et voila de la nouvelle place que tu peux ajouter à la partition (LV) que tu veux !

Elle est pas belle la vie avec LVM ?  :Smile: 

----------

## Oupsman

Message supprimé

----------

## 22decembre

Je vais peut être m'y essayer... mais sur un espace libre sur mon pc de bureau d'abord...

----------

## Tom_

 *guilc wrote:*   

> 
> 
> - scénario 3 : tu ajoutes un nouveau disque, et tu voudrais agrandir ton /home. Facile ! tu crée un nouveau PV sur le nouveau disque, et tu l'ajoutes à ton VG courant, et voila de la nouvelle place que tu peux ajouter à la partition (LV) que tu veux !

 

Et dans le cas où un disque meurt ? Tu perds tout ta /home ? Ca m'a fait toujours fait peur LVM pour ca ...

----------

## guilc

Bah oui, au meme titre qu'un raid 0, c'est pas spécifique à LVM. Après, faut savoir ce qu'on veut : des trucs qui ignorent la séparation physique, ou bien de la redondance.

Tu peux faire les 2, mais ça coute plus cher, vu qu'il faut ajouter les disques par paire...

----------

## Poussin

RAID(5 par exemple) + LVM c'est sympa.

Si je ne me trompe pas, avec le raid logiciel, tu peux ajouter des disques à ta grappe sans la réinitialiser (et donc tu peux augmenter ton espace disque). Couplé à LVM c'est super maniable

----------

## 22decembre

qu'en est-il ds systèmes de fichiers eux-même ?

Des suggestions de fs par point de montage ?

Les cache de ccache se mettent mieux dans quel fs par exemple ?

Reiserfs est-il toujours d'actualité (je tiens à rapeller que namesys, la boite qui le developpe, est arreté parce que son grand chef, Reiser lui-même, a tué sa femme...)

----------

## Poussin

les puristes te diront qu'on ne compile pas sur le serveur  :Wink: 

----------

## 22decembre

dans ce cas on est pas sur gentoo... (petite voix nasillarde et moqueuse...)

----------

## Poussin

Ah si si  :Smile: 

----------

## 22decembre

peut etre, mais les puristes diront aussi que gnome, kde, hal, windows (liste non-exhaustive), c'est le mal... On est dans la vie reelle et on s'efforce de se faciliter la vie...  :Laughing:   :Wink: 

----------

## Poussin

Ah ouais tu mets gnome/kde/windows sur ton serveur?  :Smile: 

Je parlais bien entendu d'un vrai serveur en production hein, pas d'un serveur domestique...

----------

## 22decembre

je n'ai pas envie de continuer dans le troll...

mais je pourrais, oui, installer kde. d'ailleurs quand j'etais admin informatique, il y avait kde sur le serveur...

pour ma part, j'ai pas X sur mon serveur, mais la n'est pas la question ! la question c'est : "quel est le fs que vous recommandez en fonction de quel point de montage ?"

----------

## 22decembre

personne a rien a dire sur la question ?

Je lis sur google et ailleurs pléthore de sujets sur les systemes de fichiers, mais aucun qui essaye de résoudre simplement cette question "quel fs pour quel point de montage ?". Ou alors juste une piste, un début d'info... Que dalle !

Apparement, reiser (du moins, la version 3) est toujours d'actualité. Mais vaut-il mieux mettre tout /usr sur un reiser ?

On m'a parlé de fs retaillable à chaud, d'inodes dynamiques, bien, ça c'est interessant ! Là, je suis disposé à me mettre à font dedans, voire à rebooter ... Mais, ils sont où ? C'est lesquels ?

----------

## Poussin

Bah des topics sur les FS, il y en a sur le forum tu sais  :Smile:  Ce n'est pas propre à un serveur

----------

## 22decembre

ZFS ?

http://fr.wikipedia.org/wiki/ZFS

http://zfsonlinux.org/

Native ZFS on Linux

----------

## 22decembre

j'ai migré sur hardened... Ça va, ça se fait...

Par contre, maintenant, j'ai des problèmes avec munin :

```
Nov  6 23:30:06 einstein kernel: grsec: Segmentation fault occurred at (null) in /usr/libexec/munin/munin-graph[munin-graph:26528] uid/euid:903/903 gid/egid:903/903, parent /usr/libexec/munin/munin-graph[munin-graph:26523] uid/euid:903/903 gid/egid:903/903

Nov  6 23:30:06 einstein kernel: munin-graph[26526] general protection ip:34ea6a09168 sp:16e4266bddf46259 error:0 in ld-2.12.1.so[34ea69f3000+20000]
```

Concretement, les graphes n'évoluent plus depuis la migration sur hardened !

j'ai essayé paxctl :

```
20:52 root@einstein ~# paxctl -pm /usr/libexec/munin/munin-graph

file /usr/libexec/munin/munin-graph is not a valid ELF executable

```

Une idée ?

----------

## gbetous

Pour la gestion des disques sur un serveur, j'ajoute ma couche sur LVM. J'ai même du mal à voir comment on peut faire sans.

Sur mon simple home-serveur, j'ai mis en place 2 "volume groups" :

- 1 premier sur un RAID 1 => il me sert principalement aux /home, mais aussi à un répertoire /backup qui est mis à disposition de la famille pour sauvegarder ce qu'on veut. Chacun est sur une partition différente (pour s'auto protéger du débordement de l'autre), et à la création je ne savais pas trop quelles dimension donner. J'ai récemment ajouté de la place à mes /home sans aucun indisponibilité, c'est la classe   :Cool: 

- 1 second sur des disques séparés, gérés à la que-leu-leu (espèce de RAID 0) pour avoir de la place pour le bordel courant (qui de nos jours se compte facilement en centaines de Go)

Je vais bientot créer un espace /photo qui sera aussi sur un RAID1, je ne sais pas encore si je tape dans le premier volume group, si j'en crée un nouveau (après l'achat de 2 disques durs dédiés)... en tous cas j'ai quasiment aucune contrainte du fait de la souplesse de LVM !

----------

## 22decembre

justement, qu'est-ce que vous recommandez de mettre sur lvm ? /usr ? /var ? /home ?

----------

## 22decembre

je relance un peu le truc...

Un problème de hardened, finalement, c'est la surveillance du serveur (le monitoring).

Plus de Munin, pas de phpsysinfo...

Quelqu'un aurait-il un bon truc bien correct et sécurisé juste pour avoir une surveillance du système ?

----------

## Poussin

euh... phpsysinfo? du monitoring?

----------

## 22decembre

bah appelle ça comme tu veux, les gars qui on codé ce truc disent que c'en est...

Toujours est-il que un bête truc qui me présente simplement la quantité d'espace disque dispo/occupé , la charge système et les processus, l'uptime, le statuts des services et ... c'est à peu près tout...

Pas grand chose quoi... bah je trouve pas ! Remarque, je cherche peut-être mal...

----------

## geekounet

Nagios pour du vrai monitoring  :Wink: 

----------

## Oupsman

Message supprimé

----------

## Poussin

vu que phpsysinfo te suffit, une page php très simple appelant un lspci, un cat /proc/cpuinfo, un cat /proc/loadavg, et un df -h devrait largement te suffir...

Mais du monitoring sans historique, ce n'est pas du monitoring........

----------

