Le Forum
Vous n'êtes pas identifié.
#1 23 Sep 2007 23:06:46
- CandyBox
- Affranchi(e)
- Date d'inscription: 23 Sep 2007
- Messages: 1
Rotation de ports
Bonjour a tous,
Je dispose d'un serveur sur lequel j'heberge entre autre un serveur de jeu (Q3a).
ce serveur distant ne m'est accessible qu'en ssh, la distrib est une Ubuntu V6.06 LTS.
Par ailleurs je suis plutot... novice en bash et autre joyeuseté.
Voila mon souci : Pour etre listé parmis les autres serveurs dans les spiders Q3, le serveur envoi un heartbeat a un/des masters serveurs, Hors ces mêmes Masters serveurs vont progressivement descendre en hierachie puis supprimer de leurs listes tous les serveurs up après une durée de 4 heures.
Les solutions adoptées (mais pas partagées 
) par nombre d'admins serveur sont les suivantes :
• Script de rotation de ports :
Consiste via cron a restarter le serveur quake toutes les 3 heures en modifiant le port UDP du jeux...
Je dispose d'un script mais manifestement l'une de fonction (net_restart) n'est pas comprise par linux/ubuntu server? (ce script fonctionne sur les serveurs windoz)
Script de la conf quake :
Code:
seta switch "vstr m1"
seta m1 "vstr info1;set net_port 27015;net_restart; heartbeat; set switch vstr m2"
seta m2 "vstr info2;set net_port 27016;net_restart; heartbeat; set switch vstr m3"
seta m3 "vstr info3;set net_port 27017;net_restart; heartbeat; set switch vstr m4"
seta m4 "vstr info4;set net_port 27018;net_restart; heartbeat; set switch vstr m1"
set info1 "The Server Must Be Restarted - please connect to IP:27015; wait 5"
set info2 "The Server Must Be Restarted - please connect to IP:27016; wait 5"
set info3 "The Server Must Be Restarted - please connect to IP:27017; wait 5"
set info4 "The Server Must Be Restarted - please connect to IP:27018; wait 5"Script de contab.txt du serveur quake
Code:
*/120 * * * * /vstr switch
• Masquage du serveur :
La solution consiste a masquer la presence du serveur pendant une durée determinée, avec si j'ai bien compris un technique de masquerading et les iptables (pas très accessible a mes pauvres compétences), que j'ai tenté malgrès tout.
Le script a rendre executable,
Code:
#!/bin/bash
# Script de blocages des heartbeats de 192.246.xx.xx
#
#
if [ "$1" = "-u" ]
then
iptables -D OUTPUT -d 192.246.xx.xx -j REJECT
else
iptables -A OUTPUT -d 192.246.xx.xx -j REJECT
file script pour cron (cron.d, cron ou ... ????)
Code:
30 0,4,8,12,16,20 * * * /usr/local/games/quake3/q3block.sh 0 0,4,8,12,16,20 * * * /usr/local/games/quake3/q3block.sh -u
Bref,
La premiere solution me semble etre la plus accessible (compte tenu de mon niveau) pour autant qu'une commande remplace avantageusement le fameux net_restart.
J'ai tenté la seconde, sans bien savoir si j'avais reussi a rendre mon script executable, (je ne suis pas même sur d'avoir effectivement convenablement "ecrit" mes cron...
Voila,... si une bonne âme se sent de filer un petit coup de main a un linux-noob, merci d'avance.
Hors ligne
#2 24 Sep 2007 12:05:57
Re: Rotation de ports
Hello,
Ta première solution est entièrement spécifique à quake, et je suis donc incapable de t'aider.
La deuxième n'a rien a voir avec le masquerading, mais en première approximation elle a l'air correcte, et va bloquer l'IP concernée pendant 30min toutes les 4h. Mais il faut que le script se trouve bien au bon endroit.
Pour vérifier s'il est exécutable, regarde ses permissions avec "ls -l /usr/local/games/quake3/q3block.sh". Comme ce script n'est pas confidentiel, tu peux donner les bits d'éxecution et lecture a tout le monde. (chmod o+rx). Pour les scripts interprétés (bash, perl, ..), il se trouve que le bit de lecture est indispensable pour permettre l'exécution.
Il y a aussi le risque que pour une raison ou pour une autre, cron ne trouve pas la commande iptables dans son path. Tu devrais donc remplacer les appels a "iptables" avec un chemin absolu "/sbin/iptables", juste pour être sûr.
Il serait peut-être mieux également de remplacer REJECT par DROP. avec REJECT, l'application recevra une erreur en essayant de répondre au heartbeat, alors qu'avec DROP le message sera silencieusement ignoré par le noyau. La meilleure solution dépend de la manière dont le serveur est programmé; pour le serveur, un DROP dans les deux directions devrait être indistinguable d'une panne du serveur master.
Il faut encore être certain que ton cron exécute bien le script. Pour vérifier, tu peux par exemple ajouter la ligne:
Code:
date >>/tmp/q3-crontick
dans le script q3block.sh. S'il est vraiment exécuté, tu verras le fichier /tmp/q3-crontick apparaitre et se remplir avec les dates d'exécution.
Si tu as simplement ajouté les lignes de configuration dans un crontab utilisateur, il faut que ce soit celui de root (un utilisateur normal n'a en principe pas le droit de changer la config iptables). Si tu as simplement créé un nouveau fichier dans le répertoire de configuration de cron (/etc/cron.d), il te faut redémarrer le daemon cron pour être certain que le changement soit pris en compte (/etc/init.d/crond restart ou qqch dans ce goût.)
Hors ligne