Partitionnement par défaut

Le serveur arrive avec en gros un swap et une partition « / » de quasimment 1 To (la capacité de mon disque) et un /var (dans mes souvenirs) de quelques dizaines de Mo. C’est assez cool pour héberger une base de données, genre des gros fichiers dans /var/lib/mysql…
Aucune restriction type nosuid, noexec, nodev.
Donc je suggère d’abord une réinstallation en mode « je personnalise mes partitions ». L’interface web est curieuse, il faut d’abord affecter un peu de place à /boot, puis de la place (mais pas tout) à /. (pas slashdot, c’est un point pour finir ma phrase )
A ce moment là, l’interface vous permet de nommer et modifier n’importe que point de montage: /home, /var, /tmp, le swap. A votre convenance.
Pour ce qui est des options noexec, nodev, nosuid, que vous voulez peut-être positionner, il faudra modifier /etc/fstab à la main et rebooter ou faire des mount -o remount qui vont bien.

A la fin j’ai ça, dans le cas d’un serveur en RAID 1 logiciel (celui à 69 €, l’autre est en RAID 1 hard, je préfère). Remplacez mentalement /dev/md par /dev/sda si ça vous pose un problème existentiel.

/dev/md2        /       ext3    errors=remount-ro       0       1
/dev/md1        /boot   ext3    errors=remount-ro,nodev,nosuid,noexec   0       1
/dev/md3        /home   ext3    nodev,nosuid    1       2
/dev/md6        /tmp    ext3    nodev,nosuid    1       2
/dev/md7        /var    ext3    nodev   1       2
/dev/sda5       swap    swap    defaults        0       0
/dev/sdb5       swap    swap    defaults        0       0
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

Sources logicielles (apt)

Il y a un miroir OVH. Je n’aime jamais trop ce concept, ne sachant pas si c’est à jour ou pas.
De toute manière, il manque le repository « volatile ». Quitte à l’ajouter, je suis revenu aux standards Debian, voici mon /etc/apt/sources.list :

deb ftp://ftp2.fr.debian.org/debian/ lenny main contrib non-free
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free

Un petit aptitude update et aptitude safe-upgrade plus tard, vous voilà à jour.

Kernel

Le kernel par défaut est le 2.6.27.10-grsec-xxxx-grs-ipv4-32 pour un serveur 32 bits. Le patch grsec apporte des modifications de sécurité (mouais) au kernel standard.
Le truc louche est que je ne vois aucun linux-image installé via dpkg -l. J’ai tenté l’installation du dernier 2.6 packagé par Debian (le 2.6.26, via le paquet linux-image-2.6-686), ça a un peu foiré, j’ai lâché l’affaire.
J’ai un peu peur de l’upgrade de sécurité du kernel, qui viendra bien un jour ou l’autre. Pas de paquet qui a amené le noyau (!) et je suis sur les repos autres que les miroirs OVH. Bref à mon avis, le kernel est figé pour longtemps. EDIT: A priori, vu des commentaires, c’est comme chez dedibox : un serveur FTP mettant à jour les noyaux. Supeeeer. Il doit y avoir une mailing-list ou un newsgroup pour suivre les upgrades recommandés, j’espère. C’est le cas chez dedibox.

LILO vs. GRUB

Ils ont choisi LILO. Soit. Je n’ai pas osé mettre GRUB, de peur de foutre la zone avec le reboot en mode rescue. ou de faire sauter (peut-être) le KVM sur IP (ça m’étonnerait quand même). ‘Pas eu envie de tester.
Inconvénient de LILO : penser à taper lilo après un upgrade de noyau. Mais bon, vu la situation décrite ci-dessus…

Accès SSH

Evidemment, accès root autorisé, de toutes les IP.
J’ai changé tout ça : PermitRootLogin no et AllowUsers après avoir créé des utilisateurs locaux. Pour ce qui du classique changement de port, j’ai plutôt opté pour du bridage par IP source sur ce port. Faites comme vous voulez.
OVH peut se connecter en root via clef publique autorisée (installée avec la machine). Si le concept vous plait (et que vous ne virez pas la clef de authorized_keys), il serait judicieux de laisser passer le SSH pour l’IP source qu’ils utilisent (décrite dans le chapitre du firewall ci-après).
Le PermitRootLogin doit être largement incompatible avec ce principe, au passage. Mais bon, on le sait, le RootLogin, c’est mal.

Shorewall (ou iptables)

Là, c’est l’épisode « La mise en place du firewall ou si tu bloques le ping, j’te reboote ». Arg. La cocasse anecdote. Je vous raconte ça comme je l’ai vécu. Les conclusions pour éviter une galère potentielle seront donc à la fin. C’est plus marrant comme ça.
Donc, voici le truc.

(vous pouvez lire mon guide complet sur debian, notamment shorewall, à cette adresse : http://michauko.org/docs/debian_testing/

Après un aptitude install shorewall, il faut configurer Shorewall, avec le postulat de base « je bloque tout sauf ce qui m’intéresse ». Normal. J’ouvrirai le reste à mesure que j’installerai les services (MySQL, apache, mail…)

Les « templates » shorewall pour un serveur à une interface (c’est notre cas) sont amenés par le paquet shorewall-common, dans /usr/share/doc/shorewall-common/examples/one-interface/
Copiez donc tout le contenu dans /etc/shorewall/ et passez en revue tous les fichiers pour que ça corresponde à vos besoins : bridage du SSH sur quelques IP par exemple.
Attention à cette règle (policy) :

$FW             net             ACCEPT

Elle rend possible l’attaque réseau depuis votre machine si elle est compromise. Détailler chaque flux sortant peut permettre d’éviter ça, si votre machine a été compromise juste assez pour faire chier, mais pas assez pour être root, auquel cas l’intervenant fera mumuse avec votre shorewall de toute manière.
Si vous avez besoin d’un fichier « params » vide, il est donné là : /usr/share/doc/shorewall-common/default-config/params.
Une fois votre conf adaptée, modifiez /etc/default/shorewall => startup=1 et relancez shorewall. Testez votre connexion SSH sans perdre l’ancienne session, au cas où la conf n’accepte plus rien, suite à fausse manip…

Cocasse anecdote : une sonde de leur côté (OVH) a immédiatement détecté que mon serveur ne répondait plus au ping=> REBOOT quasi-instantané pour cause de défaillance. O_o woooow. Que ça détecte une « panne », admettons, que ça force un reboot, PUTAIN NON !!!!!
J’ai eu un ticket quelques instants après m’indiquant qu’il y avait un kernel panic et qu’ils l’avaient donc passé en mode rescue. Moi je veux bien, mais sur la console, y’avait bien écrit « reboot », et pas le bon gros figeage d’un « kernel panic ». Le type au téléphone m’avait confirmé quelques minutes avant qu’ils avaient forcé le reboot. Bref passons. Ca commence bien la relation client…
Je pense surtout que quelqu’un a eu un excès de zèle et sous couvert d’un ping qui ne répondait pas, m’a rebooté comme un porc la machine, « pour m’aider », en me la mettant en mode rescue. Ah ouais, super, ça m’aide à mort…
Quelques cris plus tard, un type du service des serveurs dédiés m’indique le « Guide OVH pour le firewall » (http://guides.ovh.net/fireWall). A priori, il me confirme que les machines de monitoring évoquées dans ce guide ne changent pas et qu’il n’y en a pas d’autres en terme de monitoring qui feraient que ma machine serait vu comme défaillante et qui ferait que le mec qui s’emmerde au mois de juillet dans la salle serveur prendrait un coup de chaud et me rebooterait le serveur. Pour m’aider.

Bref, il faut laisser passer le ping pour les machines suivantes : proxy.ovh.net, proxy.p19.ovh.net, proxy.rbx.ovh.net, ping.ovh.net et les 3 premiers octets de votre IP+250/251/249 (3 machines en plus donc).
Plus une machine pour le SSH si vous pouvez avoir besoin d’eux un jour.

Changez enfin les permissions 755 à 750 sur /etc/shorewall

Question : le « PermitRootLogin no » => peut-on quand même passer en mode rescue ? Je le pense, mais bon… car le pass du root est différent. C’est un autre OS qui boote, véritablement, avec uniquement un compte root. Si quelqu’un peut me confirmer ça en commentaire, merci.

Le guide OVH donne la syntaxe iptables pour tolérer le ping de tout ça. Si vous adorez ces longues lignes iptables inbuvables, c’est pour vous. Pour le reste, il y a mast shorewall.
Côté shorewall, avec les fichiers par défaut, il faut comprendre que tout traffic net -> $FW est bloqué par défaut, en « DROP info », sauf une règle spéciale pour le ping en « DROP simple » – pour éviter de pourrir les logs. J’ai donc ajouté avant cette règle l’autorisation pour les machines de supervision OVH. Ca donne donc :

/etc/shorewall/policy

Inchangé dans cet exemple :

#SOURCE         DEST            POLICY          LOG LEVEL       LIMIT:BURST
$FW             net             ACCEPT
net             $FW             DROP            info
net             all             DROP            info
# The FOLLOWING POLICY MUST BE LAST
all             all             REJECT          info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

/etc/shorewall/rules

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE         ORIGINAL RATE            USER/   MARK
#                                                       PORT    PORT(S)        DEST             LIMIT           GROUP

### PING
# ouverture pour monitoring OVH
ACCEPT          net:213.186.50.98       $FW     icmp    # proxy.ovh.net
ACCEPT          net:213.186.45.4        $FW     icmp    # proxy.p19.ovh.net
ACCEPT          net:213.251.184.9       $FW     icmp    # proxy.rbx.ovh.net
ACCEPT          net:213.186.33.13       $FW     icmp    # ping.ovh.net
ACCEPT          net:x.y.z.250       $FW     icmp    # specifique à mon IP : x.y.z.53
ACCEPT          net:x.y.z.249       $FW     icmp    # specifique à mon IP : x.y.z.53
ACCEPT          net:x.y.z.251       $FW     icmp    # specifique à mon IP : x.y.z.53
# des machines à moi :
ACCEPT          net:$une_machine     $FW     icmp
ACCEPT          net:$une_autre            $FW     icmp
#défaut :
Ping/DROP       net             $FW # le reste est en "DROP info". Là on va éviter des logs inutiles

### SSH
# moi, moi et moi :
ACCEPT          net:$une_machine     $FW     tcp     22
ACCEPT          net:$une_autre            $FW     tcp     22
# à la limite, eux :
ACCEPT          net:213.186.50.100      $FW     tcp 22  # cache.ovh.net, probablement inutile, pas de compte dans mon cas

### WEB, utiliser AllowWeb serait plus dans le coup non ?
ACCEPT          net                     $FW     tcp     80,443

### MAIL si besoin
ACCEPT          net                     $FW     tcp     25

#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

/etc/shorewall/params : exemple

# blabla...
#               net     eth0            130.252.100.255 routefilter,norfc1918
#
###############################################################################
une_machine=a.b.c.d
une_autre=e.f.g.h
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

autres

Dans cet exemple, les fichiers « interfaces », « zones » etc sont bien tels quels.
Pensez au restart de shorewall et au test afin d’être sûr de toujours pouvoir venir en SSH sur votre serveur.

Autres trucs à faire avant d’aller plus loin

Je passe sur les softs que vous utiliserez ou non : postfix ou exim, snort, rkhunter…
Pensez à cron-apt, apt-listbugs, ntp…

Autre spécificité OVH

Le script /usr/local/rtm/bin/rtm qu’on trouve dans /etc/crontab. Un outil maison de monitoring. Admettons. C’est expliqué là : http://guides.ovh.net/RealTimeMonitoring

A plus tard pour compléter ce retour d’expérience. En bien je l’espère

Je considère dans l’exemple ci-dessous que vous avez un compte utilisateur Linux dédié (pas root !!!).

Utilisez le package prêt à l’emploi pour un serveur dédié UT2004. Disponible par exemple chez Clubic. Prenez le dernier serveur dédié, à cet instant V3339. C’est simplement un fichier ZIP à décompresser quelque part (exemple /home/ut2004/serveur).

Obtenez une clef de licence pour serveur (gratuite) sur le site officiel de l’éditeur. Ne surtout pas utiliser votre clef perso !!!
Vous la recopierez ensuite dans le fichier (à créer) : « System/cdkey ».

Ensuite, libre à vous d’ajouter des pack de maps en tout genre, disponible là aussi chez Clubic, par exemple.
L’installation de toutes ces choses est uniquement basée sur du « dézippage » de fichier (zip ou tar.gz). Pas trop dur, le tout est de respecter les arborescences.

Ensuite, le plus important, il faut configurer un minimum votre serveur. Copiez le fichier « System/Default.ini » afin de conserver celui d’origine. Je l’appelle ici « System/ma_conf.ini ». Les parties importantes de ce fichier sont les suivantes :

[URL]
Port=votre port d'écoute du serveur, 7777 par défaut

[Uweb.WebServer]
bEnabled=True pour activer le serveur web intégré pour l'administration
ListenPort= le port d'écoute du serveur d'admin (80 est une mauvaise idée si vous avez déjà Apache sur votre serveur)

[Engine.AccessControl]
AdminPassword=pour accéder à l'interface web d'administration
GamePassword=Si vous forcez un mot de passe pour se connecter à votre serveur, en tant que joueur

[IpDrv.MasterServerUplink]
DoUplink=True/False pour remonter ou non l'existence de ce serveur aux serveurs « masters ». Vous avez un paramètre similaire pour Gamespy qui demandera d'ouvrir certains ports en plus sur votre firewall.

[Engine.GameInfo] 
MaxPlayers=à vous de voir le nombre de joueurs max
MaxSpectators=et de spectateurs

Vers la fin de fichier, vous trouverez les « maps » par défaut que vous voulez voir dans votre « map cycle » suivant les modes de jeux. A modifier à cet endroit ou via l’interface WebAdmin (c’est beaucoup plus simple la première fois).
Pour accéder au WebAdmin, allez sur « http://votre_serveur:leListenPortQueVousAvezChoisi/ ».

N’oubliez pas de gérer vos règles de firewall pour qu’on puisse se connecter à votre serveur depuis l’extérieur, mais pas forcément au serveur web d’administration.

Enfin, pour lancer le serveur (dans une session « screen » de préférence), utilisez un script dans ce genre :

ut2k4@mabobox:~$ cat start-ut.sh
#!/bin/sh

cd ut2004/System/
./ucc-bin server CTF-Citadel?game=XGame.xCTFGame?mutator=?AdminName=toto?AdminPassword=tata ini=ma_conf.ini -nohomedir

Notez le ma_conf.ini

Hop, à vos Flak, prêts ? feu, fraggez !!!

D’abord, utilisez un compte utilisateur Linux dédié, c’est plus sûr. Disons qu’il s’appelle « steam », pour l’exemple ci-dessous.
Pas besoin d’avoir acheté le jeu, d’avoir une license, un compte Steam etc, car la création de serveur dédié est gratuite (comme pour tous les jeux en général).

La mise en place d’un serveur steam se passe en quelques étapes :

Installation de l’outil de serveur dédié
Téléchargez-le et lancez-le comme suit :

steam@monnusk:~$ wget http://www.steampowered.com/download/hldsupdatetool.bin
steam@monnusk:~$ chmod +x hldsupdatetool.bin
steam@monnusk:~$ ./hldsupdatetool.bin
blablabalba
...
Enter 'yes' to accept this agreement, 'no' to decline: yes
extracting steam.tar.Z...done

Mise à jour du coeur de Steam
La commande est :

steam@monnusk:~$ ./steam -command update -game valve -dir .
Checking bootstrapper version ...
Getting version 18 of Steam HLDS Update Tool
Downloading. . . . . . . . . . . .
Steam Linux Client updated, please retry the command

Dans l’exemple ci-dessus en gras, le client s’est d’abord mit lui-même à jour. On relance la même commande, et cette fois c’est bien le noyau Steam qui se met à jour :

steam@monnusk:~/steam$ ./steam -command update -game valve -dir .
Checking bootstrapper version ...
Updating Installation
No installation record found at .
Checking/Installing 'Linux Server Engine' version 35
Downloading: .\core_i386.so
Downloading: .\engine_amd.so
Downloading: .\engine_amd64.so
Downloading: .\engine_i486.so
Downloading: .\engine_i686.so
Downloading: .\filesystem_stdio_amd64.so
Downloading: .\filesystem_stdio_i386.so
Downloading: .\hlds_amd
Downloading: .\hlds_amd64
Downloading: .\hlds_i486
Downloading: .\hlds_i686
Downloading: .\hlds_run
Downloading: .\hltv
Downloading: .\libSteamValidateUserIDTickets_amd64.so
Downloading: .\libSteamValidateUserIDTickets_i386.so
Downloading: .\linuxreadme.txt
Downloading: .\proxy_i386.so
Downloading: .\steam_api_i486.so
Downloading: .\steamclient_i486.so
Downloading: .\tier0_s_i486.so
Downloading: .\vstdlib_s_i486.so

No installation record found at .
Checking/Installing 'Half-Life Base Content' version 8
Downloading: .\valve\cl_dlls\client.dll
Downloading: .\valve\dlls\hl.dll
et ça continue...
Downloading: .\valve\violence.cfg
Downloading: .\valve\xeno.wad

HLDS installation up to date

Installation des jeux souhaités
Pour installer Day Of Defeat :

steam@monnusk:~/steam$ ./steam -command update -game dod -dir .

Pour installer Counter-Strike Source :

steam@monnusk:~/steam$ ./steam -command update -game "counter-strike source" -dir css

Attention à la partie en gras. CSS doit être dans un répertoire à part. Ne me demandez pas pourquoi ?

Lancement d’un jeu
Je vous recommande de vous créer des scripts pour le lancement de chacun de vos jeux ; et de lancer tout ça dans des « screen » afin de pouvoir reprendre les sessions plus tard.
Pour DoD, le script ressemblera à ça :

#!/bin/sh

cd steam/
./hlds_run -console -game dod +ip vo.t.re.ip -port 27015 +map dod_anzio +maxplayers 21 -autoupdate -tickrate 100

Pour CSS, plutôt à ça, il y a une vague nuance :

#!/bin/sh

cd steam/css/
./srcds_run -console -game cstrike +ip vo.t.re.ip -port 27015 +map de_dust +maxplayers 21 -autoupdate -tickrate 100

Il faut évidemment ouvrir les ports réseaux TCP et UDP que vous spécifiez. Et si vous voulez faire tourner plusieurs jeux en même temps, il faudra utiliser des ports différents.

Voilou, bon frags.