Lorsqu’on est connecté en ssh à un ordinateur distant et qu’on laisse la connexion inactive pendant un certain temps, il arrive que l’on soit déconnecté. On se retrouve alors avec un message du style :

Read from remote host buzut.fr: Connection reset by peer Connection to buzut.fr closed.

Voyons comment résoudre ce problème.

Par méconnaissance, par habitude ou par confort, on utilise toujours apt-get pour gérer nos distributions. Et ce blog ne fait pas exception à la règle. Pourtant Aptitude est bien mieux à de nombreux égards.

Vous n’êtes pas sans savoir que des serveurs, au même titre que tout équipement informatique, doivent être mis à jour. Cela pour des raisons de performances, mais aussi et surtout pour la sécurité de ces derniers ! Néanmoins, lorsqu’on gère plusieurs serveurs, cela peut vite devenir fastidieux de se connecter à chacun et de les mettre à jour manuellement. Voyons comment faire pour que ces petites mises à jour se fassent automatiquement !

Pour ceux qui l’ignorent, le RAID consiste à rassembler plusieurs disques et de les utiliser de manière concurrente pour améliorer les performances ou la résilience des données. Quelque soit le nombre de disques réel, à l’usage ce sera comme si vous n’en aviez qu’un.

On peut utiliser RAID à partir de deux disques et jusqu’à plusieurs centaines. Par ailleurs, il existe beaucoup de configuration RAID différentes, que vous vouliez assurer la redondance de vos données, améliorer les performances ou les deux à la fois, pour un serveur ou un ordinateur personnel, il y a forcement un niveau de RAID qui vous convient.

On a vu dans un précédent article comment garder un œil sur ses serveurs avec des rapports journaliers, mais ici, c’est d’une manière graphique que nous voulons voir nos serveurs, et surtout, voir l’évolution dans le temps. Quelle quantité de RAM est utilisée, quel espace disque reste-t-il, quelles sont les ressources CPU monopolisées par les services en fonctionnement…

Nous avons vu dans un précédent article comment faire un monitoring ON SITE d’un serveur. Cependant, lorsqu’on en possède plusieurs, ce n’est pas ce qu’il y a de plus pratique que de devoir se connecter manuellement en SSH sur le serveur et d’aller explorer un par un les fichiers de logs. Logwatch va justement nous permettre d’automatiser tout cela et de recevoir des rapports directement par mail !

Je me suis dis que ce serait une bonne idée de compiler dans un article quelques trucs et astuces, relatifs notamment à la surveillance de votre serveur.

C’est l’occasion d’apprendre ou réapprendre à se servir des outils inclus dans toute bonne distribution qui se respecte, mais aussi comment compléter ces outils.

Il peut y avoir plusieurs raisons pour lesquelles ssh est confronté à un problème de vérification de l’hôte, la plupart du temps, le serveur distant a subit une modification et sa clef ne correspond plus à celle qui a été enregistrée sur votre poste. Mais le problème peut aussi venir d’un mauvais paramétrage des droits de /dev/tty.

Partager pour mieux régner ! Le partitionnement est tout simplement LA première étape dans l’installation d’un serveur puisqu’elle doit s’effectuer avant même l’installation du système à proprement parler. Je ne vais pas aborder ici le gestionnaire de partitionnement de Ubuntu ou de Debian – ils sonts assez intuitifs, et c’est encore différent si vous passez par OVH par ex (n’ayant pas d’accès direct au serveur) – mais plutôt de l’architecture logique des partitions.

On le sait tous, le DDoS c’est une plaie ! Il y a en même temps mille et aucune manière de s’en prémunir réellement, sauf à ne pas être connecté à internet… facile à dire.

On a déjà vu que Fail2Ban apporte quelques solutions contre ce type d’attaque, mais ce n’est pas forcément suffisant. Je vous propose donc ici une configuration de iptables qui tachera de filtrer et de bloquer les DDoS.