En ce qui concerne le partitionneur auto, je ne connais certes pas tout, mais il me fait que de la m... avec le matériel dispo, et ça j'en suis sûr. ;-)
En tous cas, merci pour tes précisions sur LVM.
En fait, je ne l'ai jamais utilisé,et je ne sais pas à quel point cela complique effectivement la récupération de la partition et des données en cas de crash par exemple.
/var/log en LVM ne servirait donc pas à grand chose non plus si LVM flanchait d'une façon ou d'une autre, et pour les bases de données, je ne fais pas confiance pour les mêmes raisons.
Et qui plus est, tout comme le RAID logiciel, cela doit rajouter une couche de gestion logicielle, donc ralentir le tout, et vu que la machine n'est pas une foudre de guerre, est-ce que cela en vaut la peine...
M'enfin c'est vrai que le redimensionnement en direct est intéressant...
Ce sera probablement pour une autre fois. ;-)
En fait, en ce moment je suis surtout préoccupé par le dépannage de la machine... ;-) (crash matériel, logiciel ou les deux !?)
C'est la moindre des choses. ;-)
Tes liens m'ont pas mal servi aussi. ;-)
Ce qui est "marrant", c'est qu'au bout du compte (j'en ai eu un peu marre de tourner en rond), j'ai quasiment tout mis en Reiserfs avec données journalisées, car : je suis pas fan des mix de données entre fichiers, et l'optimization ext3, vu que je sais pas faire et que j'ai plus le temps, ça attendra encore un peu.
On verra pour les performances ce que ça donnera...
Par contre, avec le Reiserfs, je ne pourrai apparemment pas faire de grep sur les fichiers de périphériques en cas de bavure. :-D
Pour les histoires de journalisation et les options genre noatime et compagnie, soit j'ai mal/pas assez cherché, soit au niveau doc c'est très épars... Dommage, c'est plutôt important comme sujet...
Donc ça donne :
[option] = option qui sera testée après installation
IDE 1 ("20Go") /boot ; ~100 Mo (12 cyl) ; ext3 ; [noauto], noatime [?] 2 ; data=ordered
J'aurais pu utiliser ext2, mais je ne sais pas si cela nécessite un module à charger en plus, et puis bon, j'en suis pas non plus à quelques ms près.
Pour noauto, Suse me sort un message d'avertissement quand je l'active, donc je testerai ça plus tard, si ça vaut vraiment le coup.
Au niveau du dump, je sais pas encore. /home ; 5 Go ; reiser ; noatime, notail, nodev [?] 0 ; data=ordered
En général petits fichiers, données pas critiques au point d'avoir besoin d'être journalisées en mode data=journal. swap ; 1.5 Go ; swap ; priority = 1
Histoire d'avoir un swap ailleurs que sur les SCSI, vu que j'ai reçu la recommendation de ne rien y mettre d'important voire rien du tout... / ; l'espace restant (12 Go) ; reiser ; [noatime], [notail] [?] 1 ; data=journal
Les options noatime et notail devraient compenser un peu la baisse de performances du mode data=journal au lieu de ordered ?
Apparement, il vaut mieux que je ne mettre rien d'important sur les SCSI, qui sont apparemment très vieux (dommage, ça fait de la place et des gains en vitesse en moins).
Du coup, l'IDE 2 va être plus chargé (le disque le plus récent et avec la plus grande capacité)
IDE 2 ("40 Go") /tmp ; 5 Go ; reiser ; [noatime, nodev, nosuid, noexec] 0 0 ; data=ordered
Apparemment, le noexec peut être utile pour des raisons de sécurité, mais peut empêcher des scripts de fonctionner, à tester... /usr ; 5 Go ; reiser ; [notail, noatime, nodev, ro] 0 0 ; data=ordered|journal ?
Faut que je trouve plus d'infos sur les récupérations en ordered et journal. Est-ce qu'il y a un risque de corruption des données même sans accès en écriture avec reiserfs ? /srv ; 5 Go ; reiser ; [params ?] [dump?] [fsck?] ; data=journal ?
data=journal pour éviter de perdre l'intranet en cas de coupure de courant ? /var ; 25 Go ; ext3/reiserfs ? ; ? [?] [?] ; data=journal
Vu que les bases des données et les logs sont dessus, autant limiter les risques.
Pour ce qui est d'ext3 ou de reiser, je doute que les écarts de performances soient si énormes, y'a un peu de tout au niveau tailles.
Quant au temps de montage, c'est dérisoire sur de si petites capacités.
J'aurais tendance à dire quand même ext3 avec le dir_index...
J'aurais bien été tenté de mettre un /var/log distinct, mais cela nécessiterait une partition étendue.
Au pire, sur le SCSI 2... /var/log ; 5 Go ; ext3 ; [noatime, ?] [?] [?] ; data=ordered ?
J'ai pas encore grande idée sur les options, mais ça doit pouvoir attendre un peu... !?
SCSI 2 (17 Go)
On verra...
SCSI 1 (34 Go)
On verra...
Au niveau sauvegarde, je vais essayer sans le RAID logiciel pour commencer. Des sauvegardes régulières devraient suffir.
Encore merci aux personnes qui ont pris le temps de m'aider. ;-)
J'hésite encore un peu entre le reiser de Suse et l'ext3 mieux configuré.
Car j'ai déjà eu des problèmes de récupération de données avec les 2 (ext3 et Fedora 2, reiser et Suse 9.3), mais j'avais jamais touché à la journalisation par défaut. Du coup les coupures de courant et les crashs avec reboot brutal, mes distribs avaient avaient pas aimé...
Apparemment pour éviter ce genre de désagrément, il vaut mieux, avec l'ext3, activer le dir_index et le journal en data=ordered ou journal. (et data=journal avec le reiserfs)
Apparement, l'ext3 serait plus pratique à récupérer en cas de crash majeur !? (fsck vs resiserfscheck (ou un truc du genre), montage en ext2 possible si le journal déconne (est-ce que ça arrive vraiment si souvent ?), meilleure compatibilité entre distribs, ...)
Une possibilité est de mettre certaines partitions en reiser (avec beaucoup de petits fichiers), d'autres en ext3 (ceux qui contiennent les données critiques) ? Plus que 2 fs serait un gâchis de modules chargés...
Au niveau journalisation, je pense donc mettre en mode "journal" au lieu de "ordered", pour la sécurité des données en cas de crash, surtout pour les partitions sensibles : /var, /srv, / et /home ? Pour /usr, est-ce vraiment la peine ? Un logiciel, au pire ça se réinstalle... :-D
Au niveau performances, ça risque de craindre, par contre...
J'avais effectivement pensé à un RAID logiciel, un LVM pour plus de souplesse, ...
Mais mon gros problème est que pour l'instant, je fais moyennement confiance au SCSI (pas tout frais, et pas les moyens d'acheter d'autres disques SCSI, sinon j'aurais mis les db et le www sur des disques en RAID matériel)
Le SCSI 1 a des fois fait des reset ou arrêté de fonctionner, rarement, mais j'ai pas assez confiance pour y mettre des données importantes, même en RAID. ;-)
L'avantage du swap sur les SCSI, c'est que les accès disques sont bien plus rapides. Car avec 512MB de RAM, un site intranet, les db et un serveur X et KDE (oui, je sais, c'est un serveur, mais vnc et d'autres softs sont plus pratiques en graphique), ça m'étonnerait beaucoup que le serveur ne swap pas des fois. ;-)
Pour le /usr, j'ai regardé sur 2 PC, et j'ai 2,8 Go max, c'est pour ça que j'ai réduit de 10 à 5 Go.
Dans le /var, j'utilise surtout les logs et les db. Qui plus est, IDE2 est un 40 Go, donc j'utilise la place au maximum. ;-)
Pour le moment, j'ai séparé /var/log, car ça génère des accès fréquents aussi, et en production, ça peut vite prendre de la place, donc vu que j'ai du rab sur le 17Go (SCSI 2), c'est pour ça que je l'ai séparé du var, tout en gardant plein de place pour les bases de données. ;-)
Au pire, je taillerais encore dans le /var pour retirer ce qui prend beaucoup d'accès disques.
A la limite, est-ce que je peux avoir :
IDE 2
/var ; 30 Go
SCSI 2
/var/lib/mysql ; ? Go
Avec un RAID logique sur les db ? Bien que ça doit être crados au niveau perfs entre un IDE et un SCSI + RAID logiciel !?
En fait, à terme, on devrait acheter une carte contrôleur RAID S-ATA et on migrera les données dessus. Au niveau sauvegardes, je suis pas encore sûr. A priori, une copie sur le serveur de fichiers (tar, cron, cpio, images, dumps sql, ... je vais tester, je connais pas bien), pas sur un des disques du serveur, ou du moins pas uniquement.
Pour le choix du reiser, c'est ce que Yast met par défaut, je lui fait confiance pour ça. ;-)
Et de toutes façons les outils de récupération marchent pas tellement avec l'ext3 non plus, et au niveau journalisation, le reiser est sensé être plutôt optimisé d'après un des liens ci-dessus.
Au niveau compatibilité avec les livecd, ça ne semble pas poser pb (sur la 9.3).
Bon en fait j'ai vérifié sur une Suse 9.3, y'a bien /srv/www/htdocs pour le site intranet, et /var/lib/mysql pour les bases mysql.
Je pensais bien mettre /var sur une partition à part, mais la taille dépend de si je laisse les données mysql et les logs avec /var ou plus à part.
Par rapport au lien vers le guide d'install Debian, les partitions en ext2 c'est pour pouvoir utiliser des outils de récupération, pour les performances ou parce que l'ext3 existait pas encore !? :D
Pour l'histoire de logrotate, je connaissais que vaguement de nom, je vais étudier ça. :D
Donc pour l'instant, ça donne :
IDE 1
/boot ; 100Mo ; ext3
/ ; le reste ; reiser
/home ; 5 Go ; reiser
IDE 2
/var ; 30 Go ; reiser
/usr ; 5 Go ; reiser
/srv ; 5 Go ; reiser
SCSI 2
/var/log ; 10 Go ; reiser
swap ; 2 Go ; sw => swap ~ centre
/tmp ; 5 Go ; reiser
SCSI 1 (needs stability testing on a long run)
swap ; 5 Go ; sw
/something ; 30 Go ? ; somefs
Je ré-agencerais au besoin si les performances devenaient mauvaises.
Je vais maintenant m'occuper d'étudier plus en détail les options (read only, noexec, ...) et ACL pour ces partitions.
Dans un topic sur Léa Linux, je crois me rappeler qu'un gars avait conseillé de monter le /tmp avec noexec. Enfin ce genre de trucs, quoi. ;-)
Encore merci encore pour vos conseils, je vous tiens au courant. ;-)
Enfin merci pour les liens, je vais potasser ça un peu plus en détail et les mettre en bookmark, ça peut re-servir... ;-)
(j'ai mal aux yeux rien que d'y penser, toutefois) :D
Le guide Debian securing-debian-howto est pas mal (quoique des fois un peu vieux), je l'avais déjà téléchargé (pavé bien dense), mais j'y avais vraiment pas pensé sur ce coup-là. (trop axé partitions et suse-securing howto) ;-)
Un de mes problèmes, c'est que j'ai trouvé pas mal de sites qui étaient pas vraiment mis à jour, avec des données qui n'étaient en partie plus valables (genre problèmes de sécurité qui ont été corrigés depuis longtemps, tailles disques d'il y a 20 ans et avec bien moins de paquets à l'époque, ...), donc ça aide pas toujours...
Au niveau répartition sur les disques, vu que c'est un serveur, je suis aussi assez préoccupé par les performances : genre est-ce que ça ralentit le système de séparer /var et /usr de / sur une autre partition ou un autre disque, en disque maître ou esclave sur un même nappe, ce genre de choses ? Idem avec le swap ?
Vu que je dois utiliser les disques IDE plutôt que les vieux SCSI pour des raisons de fiabilité (on aura tout vu...), autant éviter les goulots d'étranglements au maximum.
Une idée à ce sujet ?
[^] # Re: les tailles des partions n'ont aucune importances !!!
Posté par Yohm . En réponse au message Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?. Évalué à 1.
La suse 10.1 est trop instable sur cette machine, je suis passé à Ubuntu server, et j'ai suivi tes conseils pour LVM.
Pour le moment, aucun problème.
Merci encore pour m'avoir aidé à franchir le pas. ;-)
[^] # Re: les tailles des partitions n'ont aucune importance !!!
Posté par Yohm . En réponse au message Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?. Évalué à 1.
En ce qui concerne le partitionneur auto, je ne connais certes pas tout, mais il me fait que de la m... avec le matériel dispo, et ça j'en suis sûr. ;-)
En tous cas, merci pour tes précisions sur LVM.
En fait, je ne l'ai jamais utilisé,et je ne sais pas à quel point cela complique effectivement la récupération de la partition et des données en cas de crash par exemple.
/var/log en LVM ne servirait donc pas à grand chose non plus si LVM flanchait d'une façon ou d'une autre, et pour les bases de données, je ne fais pas confiance pour les mêmes raisons.
Et qui plus est, tout comme le RAID logiciel, cela doit rajouter une couche de gestion logicielle, donc ralentir le tout, et vu que la machine n'est pas une foudre de guerre, est-ce que cela en vaut la peine...
M'enfin c'est vrai que le redimensionnement en direct est intéressant...
Ce sera probablement pour une autre fois. ;-)
En fait, en ce moment je suis surtout préoccupé par le dépannage de la machine... ;-) (crash matériel, logiciel ou les deux !?)
[^] # Re: liens
Posté par Yohm . En réponse au message Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?. Évalué à 1.
http://lists.debian.org/debian-user-french/2006/01/msg00241.(...)
http://zgp.org/linux-elitists/20010329123619.A12565@zgp.org.(...)
http://assistance.dedibox.fr/nntp/article.php?id=457&gro(...)
http://www.hesit.be/lamp/html/c253.html
http://www.cyberciti.biz/nixcraft/vivek/blogger/2005/10/impo(...)
[^] # Re: liens
Posté par Yohm . En réponse au message Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?. Évalué à 1.
Tes liens m'ont pas mal servi aussi. ;-)
Ce qui est "marrant", c'est qu'au bout du compte (j'en ai eu un peu marre de tourner en rond), j'ai quasiment tout mis en Reiserfs avec données journalisées, car : je suis pas fan des mix de données entre fichiers, et l'optimization ext3, vu que je sais pas faire et que j'ai plus le temps, ça attendra encore un peu.
On verra pour les performances ce que ça donnera...
Par contre, avec le Reiserfs, je ne pourrai apparemment pas faire de grep sur les fichiers de périphériques en cas de bavure. :-D
Pour les histoires de journalisation et les options genre noatime et compagnie, soit j'ai mal/pas assez cherché, soit au niveau doc c'est très épars... Dommage, c'est plutôt important comme sujet...
[^] # Re: liens
Posté par Yohm . En réponse au message Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?. Évalué à 1.
Tout d'abord, quelques liens supplémentaires :
http://www.gentoo.org/doc/fr/security/shb-mounting.xml?glang(...)
http://www.gentoo.fr/install/configuration-systeme.htm
http://www.futuremark.com/forum/showthread.php?t=6283 (about which fs for which partition)
http://clx.anet.fr/spip/article.php?id_article=32
Donc ça donne :
[option] = option qui sera testée après installation
IDE 1 ("20Go")
/boot ; ~100 Mo (12 cyl) ; ext3 ; [noauto], noatime [?] 2 ; data=ordered
J'aurais pu utiliser ext2, mais je ne sais pas si cela nécessite un module à charger en plus, et puis bon, j'en suis pas non plus à quelques ms près.
Pour noauto, Suse me sort un message d'avertissement quand je l'active, donc je testerai ça plus tard, si ça vaut vraiment le coup.
Au niveau du dump, je sais pas encore.
/home ; 5 Go ; reiser ; noatime, notail, nodev [?] 0 ; data=ordered
En général petits fichiers, données pas critiques au point d'avoir besoin d'être journalisées en mode data=journal.
swap ; 1.5 Go ; swap ; priority = 1
Histoire d'avoir un swap ailleurs que sur les SCSI, vu que j'ai reçu la recommendation de ne rien y mettre d'important voire rien du tout...
/ ; l'espace restant (12 Go) ; reiser ; [noatime], [notail] [?] 1 ; data=journal
Les options noatime et notail devraient compenser un peu la baisse de performances du mode data=journal au lieu de ordered ?
Apparement, il vaut mieux que je ne mettre rien d'important sur les SCSI, qui sont apparemment très vieux (dommage, ça fait de la place et des gains en vitesse en moins).
Du coup, l'IDE 2 va être plus chargé (le disque le plus récent et avec la plus grande capacité)
IDE 2 ("40 Go")
/tmp ; 5 Go ; reiser ; [noatime, nodev, nosuid, noexec] 0 0 ; data=ordered
Apparemment, le noexec peut être utile pour des raisons de sécurité, mais peut empêcher des scripts de fonctionner, à tester...
/usr ; 5 Go ; reiser ; [notail, noatime, nodev, ro] 0 0 ; data=ordered|journal ?
Faut que je trouve plus d'infos sur les récupérations en ordered et journal. Est-ce qu'il y a un risque de corruption des données même sans accès en écriture avec reiserfs ?
/srv ; 5 Go ; reiser ; [params ?] [dump?] [fsck?] ; data=journal ?
data=journal pour éviter de perdre l'intranet en cas de coupure de courant ?
/var ; 25 Go ; ext3/reiserfs ? ; ? [?] [?] ; data=journal
Vu que les bases des données et les logs sont dessus, autant limiter les risques.
Pour ce qui est d'ext3 ou de reiser, je doute que les écarts de performances soient si énormes, y'a un peu de tout au niveau tailles.
Quant au temps de montage, c'est dérisoire sur de si petites capacités.
J'aurais tendance à dire quand même ext3 avec le dir_index...
J'aurais bien été tenté de mettre un /var/log distinct, mais cela nécessiterait une partition étendue.
Au pire, sur le SCSI 2...
/var/log ; 5 Go ; ext3 ; [noatime, ?] [?] [?] ; data=ordered ?
J'ai pas encore grande idée sur les options, mais ça doit pouvoir attendre un peu... !?
SCSI 2 (17 Go)
On verra...
SCSI 1 (34 Go)
On verra...
Au niveau sauvegarde, je vais essayer sans le RAID logiciel pour commencer. Des sauvegardes régulières devraient suffir.
Encore merci aux personnes qui ont pris le temps de m'aider. ;-)
[^] # Re: liens
Posté par Yohm . En réponse au message Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?. Évalué à 1.
J'hésite encore un peu entre le reiser de Suse et l'ext3 mieux configuré.
Car j'ai déjà eu des problèmes de récupération de données avec les 2 (ext3 et Fedora 2, reiser et Suse 9.3), mais j'avais jamais touché à la journalisation par défaut. Du coup les coupures de courant et les crashs avec reboot brutal, mes distribs avaient avaient pas aimé...
Apparemment pour éviter ce genre de désagrément, il vaut mieux, avec l'ext3, activer le dir_index et le journal en data=ordered ou journal. (et data=journal avec le reiserfs)
Apparement, l'ext3 serait plus pratique à récupérer en cas de crash majeur !? (fsck vs resiserfscheck (ou un truc du genre), montage en ext2 possible si le journal déconne (est-ce que ça arrive vraiment si souvent ?), meilleure compatibilité entre distribs, ...)
Une possibilité est de mettre certaines partitions en reiser (avec beaucoup de petits fichiers), d'autres en ext3 (ceux qui contiennent les données critiques) ? Plus que 2 fs serait un gâchis de modules chargés...
Au niveau journalisation, je pense donc mettre en mode "journal" au lieu de "ordered", pour la sécurité des données en cas de crash, surtout pour les partitions sensibles : /var, /srv, / et /home ? Pour /usr, est-ce vraiment la peine ? Un logiciel, au pire ça se réinstalle... :-D
Au niveau performances, ça risque de craindre, par contre...
Pour l'ext3, le mode ordered suffit soit-disant (http://lwn.net/2001/0802/a/ext3-modes.php3), mais bon, en pratique ça n'a pas toujours très bien marché...
[^] # Re: liens
Posté par Yohm . En réponse au message Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?. Évalué à 1.
Mais mon gros problème est que pour l'instant, je fais moyennement confiance au SCSI (pas tout frais, et pas les moyens d'acheter d'autres disques SCSI, sinon j'aurais mis les db et le www sur des disques en RAID matériel)
Le SCSI 1 a des fois fait des reset ou arrêté de fonctionner, rarement, mais j'ai pas assez confiance pour y mettre des données importantes, même en RAID. ;-)
L'avantage du swap sur les SCSI, c'est que les accès disques sont bien plus rapides. Car avec 512MB de RAM, un site intranet, les db et un serveur X et KDE (oui, je sais, c'est un serveur, mais vnc et d'autres softs sont plus pratiques en graphique), ça m'étonnerait beaucoup que le serveur ne swap pas des fois. ;-)
Pour le /usr, j'ai regardé sur 2 PC, et j'ai 2,8 Go max, c'est pour ça que j'ai réduit de 10 à 5 Go.
Dans le /var, j'utilise surtout les logs et les db. Qui plus est, IDE2 est un 40 Go, donc j'utilise la place au maximum. ;-)
Pour le moment, j'ai séparé /var/log, car ça génère des accès fréquents aussi, et en production, ça peut vite prendre de la place, donc vu que j'ai du rab sur le 17Go (SCSI 2), c'est pour ça que je l'ai séparé du var, tout en gardant plein de place pour les bases de données. ;-)
Au pire, je taillerais encore dans le /var pour retirer ce qui prend beaucoup d'accès disques.
A la limite, est-ce que je peux avoir :
IDE 2
/var ; 30 Go
SCSI 2
/var/lib/mysql ; ? Go
Avec un RAID logique sur les db ? Bien que ça doit être crados au niveau perfs entre un IDE et un SCSI + RAID logiciel !?
En fait, à terme, on devrait acheter une carte contrôleur RAID S-ATA et on migrera les données dessus. Au niveau sauvegardes, je suis pas encore sûr. A priori, une copie sur le serveur de fichiers (tar, cron, cpio, images, dumps sql, ... je vais tester, je connais pas bien), pas sur un des disques du serveur, ou du moins pas uniquement.
Pour le choix du reiser, c'est ce que Yast met par défaut, je lui fait confiance pour ça. ;-)
Et de toutes façons les outils de récupération marchent pas tellement avec l'ext3 non plus, et au niveau journalisation, le reiser est sensé être plutôt optimisé d'après un des liens ci-dessus.
Au niveau compatibilité avec les livecd, ça ne semble pas poser pb (sur la 9.3).
[^] # Re: liens
Posté par Yohm . En réponse au message Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?. Évalué à 1.
Je pensais bien mettre /var sur une partition à part, mais la taille dépend de si je laisse les données mysql et les logs avec /var ou plus à part.
Par rapport au lien vers le guide d'install Debian, les partitions en ext2 c'est pour pouvoir utiliser des outils de récupération, pour les performances ou parce que l'ext3 existait pas encore !? :D
Pour l'histoire de logrotate, je connaissais que vaguement de nom, je vais étudier ça. :D
Donc pour l'instant, ça donne :
IDE 1
/boot ; 100Mo ; ext3
/ ; le reste ; reiser
/home ; 5 Go ; reiser
IDE 2
/var ; 30 Go ; reiser
/usr ; 5 Go ; reiser
/srv ; 5 Go ; reiser
SCSI 2
/var/log ; 10 Go ; reiser
swap ; 2 Go ; sw => swap ~ centre
/tmp ; 5 Go ; reiser
SCSI 1 (needs stability testing on a long run)
swap ; 5 Go ; sw
/something ; 30 Go ? ; somefs
Je ré-agencerais au besoin si les performances devenaient mauvaises.
Je vais maintenant m'occuper d'étudier plus en détail les options (read only, noexec, ...) et ACL pour ces partitions.
Dans un topic sur Léa Linux, je crois me rappeler qu'un gars avait conseillé de monter le /tmp avec noexec. Enfin ce genre de trucs, quoi. ;-)
Encore merci encore pour vos conseils, je vous tiens au courant. ;-)
[^] # Re: liens
Posté par Yohm . En réponse au message Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?. Évalué à 1.
Enfin merci pour les liens, je vais potasser ça un peu plus en détail et les mettre en bookmark, ça peut re-servir... ;-)
(j'ai mal aux yeux rien que d'y penser, toutefois) :D
Le guide Debian securing-debian-howto est pas mal (quoique des fois un peu vieux), je l'avais déjà téléchargé (pavé bien dense), mais j'y avais vraiment pas pensé sur ce coup-là. (trop axé partitions et suse-securing howto) ;-)
Un de mes problèmes, c'est que j'ai trouvé pas mal de sites qui étaient pas vraiment mis à jour, avec des données qui n'étaient en partie plus valables (genre problèmes de sécurité qui ont été corrigés depuis longtemps, tailles disques d'il y a 20 ans et avec bien moins de paquets à l'époque, ...), donc ça aide pas toujours...
Au niveau répartition sur les disques, vu que c'est un serveur, je suis aussi assez préoccupé par les performances : genre est-ce que ça ralentit le système de séparer /var et /usr de / sur une autre partition ou un autre disque, en disque maître ou esclave sur un même nappe, ce genre de choses ? Idem avec le swap ?
Vu que je dois utiliser les disques IDE plutôt que les vieux SCSI pour des raisons de fiabilité (on aura tout vu...), autant éviter les goulots d'étranglements au maximum.
Une idée à ce sujet ?
En tous cas, merci encore pour ton aide. ;-)