Cet article est le premier d’une série consacrée à la mise en place d’un serveur dédié. Le but est double : garder une trace de ce que je fais pour administrer mon serveur et donner des astuces à celles et ceux qui voudraient se lancer dans l’administration d’un serveur.
J’ai reçu mon serveur OVH à peu près 30 minutes après avoir passé commande : on reçoit un email avec le nom de la machine, son adresse IP et les identifiants root pour se connecter dessus via SSH.
Système d’exploitation
Au moment de la commande, on peut indiquer quel système d’exploitation on veut installer sur le serveur. La plupart des hébergeurs que j’ai contacté proposent CentOS (qui est basé sur Red Hat).
J’ai donc installé CentOS dans une machine virtuelle sur mon PC pour voir ce que ça donne. J’ai assez vite abandonné l’idée, principalement parce que les noms des commandes changent : ce n’est plus apt-get mais yum etc. Réapprendre toutes les commandes d’une autre distribution n’ayant aucun attrait pour moi, j’ai éliminé CentOS de la liste des candidats.
Voici les distributions et systèmes d’exploitations proposés chez OVH à la date de cet article :
Debian 5.0 Stable, Ubuntu Server 8.04, Ubuntu Server 8.10, Ubuntu Server 9.04, Ubuntu Server 9.10, Open Suse 11, Red Hat Ent. Linux 5, Fedora 11, CentOS, Gentoo 2007, Gentoo 2008, Gentoo 10.1, Slackware 12.1, Slackware 13, Mandriva, ArchLinux, FreeBSD 7.1, FreeBSD 8.0, OpenSolaris (BETA), Openfiler NSA 2.3, Windows Server 2008 R2 Datacenter Edition, Windows Server 2008 R2 Entreprise Edition, Windows Server 2008 R2 Standard Edition, Windows Server 2008 R2 Web Edition, Windows Server 2008 R2 Core Datacenter Edition, Windows Server 2008 R2 Core Entreprise Edition, Windows Server 2008 R2 Core Standard Edition, Windows Server 2008 R2 Core Web Edition, Windows Server 2008 Datacenter Edition SP2, Windows Server 2008 Web Edition SP2, Windows 2003 Enterprise Edition, Windows 2003 Standard Edition, Windows Server 2003 Web Edition.
J’ai opté pour la simplicité et la robustesse, j’ai installé une Debian 64-bits.
SSH
Je dois vous dire que SSH m’était totalement inconnu à ce jour et pour cause : on n’y a jamais droit lorsque l’on est hébergé sur un serveur mutualisé. D’ailleurs, cela se comprend aisément puisqu’en root, on a accès à toute la machine, sans limitations.
Pour se connecter sous l’utilisateur root au serveur myserver.host.com en SSH, il suffit d’ouvrir une fenêtre de terminal et de taper la commande suivante :
ssh -l root myserver.host.comCode language: CSS (css)Voici la réponse du serveur :
root@myserver.host.com's password: _Code language: CSS (css)Vous n’avez plus qu’à entrer votre mot de passe root pour entrer sur le serveur.
Mise à jour du serveur
Il est important d’effectuer les mises à jour d’usage après l’installation du système d’exploitation. A cet effet, nous allons rapatrier la liste des mises à jour et correctif :
apt-get updateCode language: JavaScript (javascript)et on les applique :
apt-get upgradeCode language: JavaScript (javascript)Votre serveur est maintenant à jour.
Commandes bash utiles
Une fois sur le serveur, c’est de la ligne de commande : c’est un serveur donc il n’y a aucune application graphique pour limiter la consommation CPU et RAM. Voici donc quelques petites commandes bash utiles :
top permet de voir les processus en cours. Si vous cliquez sur Shift + m, ils seront classés par taux d’utilisation de la mémoire. Vous aurez également la charge du serveur sur 3 nombres : le premier donne la charge dans la dernière minute, le deuxième dans les 5 dernières minutes et le troisième dans le dernier quart d’heure.
Exemple :
top - 19:25:29 up 2 days, 20:39, 1 user, load average: 0.39, 0.22, 0.20 Tasks: 112 total, 1 running, 110 sleeping, 0 stopped, 1 zombie Cpu(s): 13.5%us, 2.0%sy, 0.0%ni, 83.5%id, 0.3%wa, 0.0%hi, 0.7%si, 0.0%st Mem: 2015040k total, 1515012k used, 500028k free, 249868k buffers Swap: 523800k total, 38724k used, 485076k free, 800688k cachedfree -m donne l’utilisation de la RAM et du SWAP en Mo. Exemple :
total used free shared buffers cached Mem: 1967 627 1340 0 33 137 -/+ buffers/cache: 456 1511 Swap: 511 32 478 netstat -tanpu permet de savoir quels services sont lancés et sur quels ports ils écoutent.
tail -f /var/log/messages permet de lire les derniers enregistrements en temps réel d’un fichier log. Le fichier /var/log/messages contient les messages du système. tail -f est très utile pour débugger ou voir l’activité d’un de vos services (comme le fichier /var/log/apache2/access.log d’Apache ou celui du serveur de mail dans /var/log/mail.log).
w montre les charges CPU ainsi que les utilisateurs connectés au serveur.
df -hT donne l’espace disque de chacune des partitions.
du -sh * | sort -n permet de lister les plus gros répertoires du disque dur.
Voilà pour les bases. Prochain article : installation d’Apache, PHP et MySQL.
Vous avez un projet WordPress ou WooCommerce en tête? Transformez votre vision en réalité avec mon expertise reconnue.
Et la sécurisation ? :D
Si tu comptes installer un serveur de jeu (ce dont je doute mais bon) il pourrait être judicieux d’installer un nouveau noyau recompilé en 1000hz.
Ah oui, y’a de la sécurisation aussi ! J’y reviendrai dans un article “dédié”, histoire d’expliquer tout ça en détail :)
Pas de jeu sur le serveur de prévu… je trouve que le Core2 est déjà pas mal utilisé avec le site, un peu trop à mon goût d’ailleurs ! Quel est l’avantage du noyau 1000Hz ? Des performances accrues ?
Oui, de meilleures performances. Je vais citer quelqu’un du Site du Zéro qui l’explique (clairement) mieux que moi :
Donc oui, c’est plus avantageux pour les serveurs de jeu puisque plus d’infos sont envoyées plus souvent, ce qui fait qu’on a une meilleure latence quand on tire sur un ennemi, par exemple. J’imagine que ça a ses avantages pour d’autres utilisations.
Je vais rajouter ça à ma liste de choses à tester pendant les vacances ! Cela a l’air simple à mettre en place.
Oui c’est vraiment pas compliqué ;)
J’utilise toujours “aptitude” au lieu de “apt-get” … Il parait que ça résout mieux certains conflits, etc …
;-)
Pour SSH, pense à Fail2ban : simple et efficace :-)
J’utilise l’un et l’autre : quand j’ai commencé sous Linux, j’utilisais beaucoup apt-get, maintenant je suis plutôt aptitude. Mais je change de temps en temps : un aptitude purge m’a sauvé l’autre jour d’une image de noyau défaillante (alors que l’équivalent apt-get ne résolvait pas le problème).
Oui, fail2ban est excellent ! Je le couple avec quelques règles iptables.