Pour comprendre la situation telle qu’elle était avant cette réinstallation il faut revenir en arrière. Je suis, avec d'autres joueurs de TF2, administrateur du serveur de jeu (et site web) de Geek Gaming, un puissant serveur dédié loué chez OVH (Un Quad Core, 8 Go de mémoire vive, bref un monstre). Malheureusement ces derniers mois de nombreux lags sont apparus sur le serveur, qui commençaient sérieusement à irriter les joueurs. Nous (les administrateurs) nous sommes donc mis d’accord pour repartir sur de bonnes bases. Il faut savoir que lors de la première installation, nous n’étions pas encore très familiers avec Linux, ce qui nous a valut pas mal de sueurs froides.

La première étape lors de la réinstallation d’un serveur dédié est bien sûr de faire des sauvegardes de ce qu’il y a dessus, notamment des designs faits avec amour (et Photoshop), les bases de données et des scripts très utiles. Jusque là tout semblait bien parti, même certains admins étaient partis. La seconde étape a été de réinstaller le serveur à partir du panel de chez OVH, et c’est la que ça commence à être marrant.

Steam et le chmod : toute une histoire

Le propriétaire de compte, Berpj pour ne pas le citer, se connecte au panel OVH et demande la réinstallation du serveur, le partitionnement et le choix de la distribution se font sans soucis. Il faut savoir que la version qui était jusqu’à présent installée sur le serveur était une Debian Lenny 64 bits, mais à l’origine c’était une Debian Etch 32 bits (tout le monde suit). Etant persuadés que ce passage ne s’était pas fait dans les règles (avec un gain mystère de 32 bits au passage), nous nous étions mis d’accord pour repartir sur une Lenny 32 bits de base.

L’installation étant un succès, je me mets alors au travail pour réinstaller les serveurs TF2, avec au passage le chat Steam des admins qui commence à délirer. Lors de la première installation (il y a environ 8 mois), tout s’était passé comme prévu. Là par contre ça commence mal j’ai le script d’installation qui veut pas s’exécuter. Après 10 minutes de pétage de plombs, je passe tout le dossier en CHMOD 777, le programme consent enfin à démarrer.

Allo Houston : Le screen ne répond plus

L’installation étant longue, faut savoir que chez Valve, si on installe un serveur dédié faut se taper le téléchargement de tout le jeu, avec 90 % de fichiers inutiles (les 2 Go de textures sont indispensables sur un dédié, étant donné que tous les joueurs les ont déjà, tout comme les commentaires de développeurs). Pour remédier à cela je lance cette installation dans un screen Linux, j’attends quelques minutes que l’avancement avance (ce n’est pas évident au début), puis je quitte le screen. Je veux y revenir un peu plus tard pour voir où ça en est mais impossible, il me dit qu’il n’y a pas de screen ouvert, la commande top me dit pourtant que l’installation est en train de tourner, bon bref de toute façon avec le problème qui va arriver j’oublie très vite le screen.

N’est pas root qui le veut

Les autres administrateurs voulant eux aussi un compte SSH, je profite de la longue installation (qui foire) pour créer des comptes. Il faut savoir que sur un serveur dédié, il y a en permanence des robots qui essayent de se logger avec le compte root. Le plus simple est de désactiver ce compte, en ayant auparavant créé des comptes ayant les mêmes droits. Il suffit alors de se logger avec un compte puis de devenir root avec la commande sudo su pour faire ce que l’on veut. Il faut alors éditer un fichier pour y ajouter la liste des comptes autorisés à devenir root. Ce fichier /etc/sudoers a été une cause de crach. il est à l’origne en CHMOD 440, on ne peut alors pas l’éditer, je modifie alors son chmod pour l’éditer, je l’édite puis je me delogge, je tente alors de me relogger avec mon compte à moi, puis devenir root grâce à la fameuse commande sudo su.

Le reboot : presque un art

Et là c’est le drame : plus rien ne répond. Je retente alors de me logguer avec le compte root mais là je ne peux même plus me connecter au serveur. Il s’avère que d’après moi, si on ne repasse pas le fichier /etc/sudoers en CHMOD 440 ça plante le serveur dès qu’on veut passer root. Je ne pense pas que ce soit ça l’explication mais ça me le fait à chaque fois, maintenant je ne prends plus aucun risque. Les autres admins étant dans le même cas que moi, une réinstallation s’avère nécessaire. On a tout de même essayé de rebooter le serveur, d’habitude ça marche.

OVH ne répond plus

Je ne sais pas si certains ont été touchés, mais l’accès au site OVH a été très dur, voire impossible à certains moments de la journée. Et comme par hasard cela tombe au moment où on en a besoin. Une fois l’accès rétabli, Berpj recommence l’installation mais se trompe (la faute au panel OVh avec des boutons trop petits) dans le choix de la distribution et on se retrouve avec une Lenny 64 bits. Et hop c’est reparti pour une nouvelle installation. Et cette fois ci tout se passe bien (sauf le site OVH qui est indisponible par moments).

Je recommence la même manipulation que précédemment (autant planter le serveur de suite), cette fois ci je n’oublie pas de remettre le bon CHMOD, le reste se passe sans anicroche, le screen répond bien, bref je pensais la fin des ennuis terminée.

Phpmyadmin : le paquet c’est le mal

Pour installer phpmyadmin il y a 2 solutions :

• Rapide : apt-get install phpmyadmin, et ensuite il suffit de se rendre à l’adresse http://ipduserveur/phpmyadmin pour y avoir accès. Hors lors de la précédente installation, il y avait eu un problème, il manquait un lien vers le répertoire de phpmyadmin (qui n’est pas installé dans le répertoire web classique, un lien symbolique faisant la liaison). De plus cette méthode ne nous permet pas d’avoir la dernière version stable, mais une version assez vieille. Pour l’occasion j’avais donc décidé d’utiliser l’autre méthode.
• Lente : en fait elle n’est pas lente mais juste moins rapide, il faut aller sur le site de phpmyadmin, récupérer la dernière version, la télécharger, la décompresser dans le répertoire que l’on veut, on règle quelques variables et le tour est joué. Je tente donc de me connecter au répertoire, et là il me demande de télécharger un fichier, au lieu de m’afficher une page. Et ce fichier à télécharger n’est autre que le index.php. Je remarque au passage que je n’ai eu ce bug qu’avec Firefox, avec d’autres navigateurs tout se passe bien, un nettoyage de Firefox résout le problème.

Au final, tout est installé correctement, on restaure les bases de données, le blog, le forum, etc. Il manque encore quelques trucs mais l’essentiel est là. La bonne nouvelle c’est que maintenant il n’y a plus de lags sur le serveur.