Au revoir OVH :( Bonjour Online !!

Bonjour,

Bon petit bilan de mon passage chez Online avant que ma Kimsufi ne prenne un coup de format.

Premier point, l’installation du serveur. Comme vous l’avez peut être lu précédemment nous avons installé un VMware vSphere sur le serveur. Cependant, avec les affres de l’ADSL j’avais des petits soucis de corruptions de données. Heureusement une âme bienveillante ma prêté ça de bande passante NC (merci Jérem).

Une fois le serveur installé, des petits soucis de macs virtuels avec le routeur pfsense (2h passé sur les forums et une autre heure à trifouiller pfsense). Au final ça fonctionne et 3 VM son hébergé derrière ce pare feu.

Enfin la partie marrante : la migration de nh-ks01, le serveur Web, Mail, DNS et MySQL :). Et bien au final tout c’est super bien passé, juste un petit souci de compatibilité de mon roundcube sur Debian 5 avec le package de sécurité PHP (suhosin) présent pas défaut sur Debian 6. Pour le moment je l’ai désactivé en attendant la prochaine version de roundcube ou je referais la configuration. En effet avec un serveur à rendre pour le 1 mars, plus vite ça fonctionnait mieux c’était.

Donc voilà ! Sinon pour la partie Online, Malheureusement, en même pas un mois chez eux j’ai déjà subit un incident réseau. Coup de pas de bol ! On verra par la suite. @+

Serveurs Online : Les nouvelles Dedibox v3

Yop,

En attendant de finaliser la rédaction de mon article sur l’utilisation de LVM2, voici une petite news concernant l’hébergeur Online (anciennement Dedibox filial d’Iliad) qui a sortie depuis peu ses nouvelles offres de serveurs dédiés.

Pour ma part j’ai commencé ma migration de ma Kimsufi 250G à un serveur Dedibox DC. Je vous ferez un petit retour d’expérience dès que j’ai au moins migré MySQL et apache.

Pour en revenir à Online voici les réels plus que je leurs trouve à OVH :

  • Pas de frais d’installation contre 57€ chez OVH
  • KVM IP fournis. Enfin une carte DRAC (Comme ILO chez HP ou RSC chez SUN), qui vous permet de gérer l’alimentation de votre serveur, de monter des média (CD-Rom, ISO…)
  • Une gamme de prix plus large…

Maintenant il ne reste plus qu’à attendre la réponse de kimsufi.

Synology lance son DSM 3.1 en phase Beta

Etant possesseur d’un NAS synology, je ne puis être qu’enthousiaste à l’annonce de l’évolution du firmware de ce dernier.

Parmis les évolutions,

  • Tolérance de défaillance du Synology Hybrid RAID étendu à deux disques
  • Support du iSNS pour les cibles iSCSI
  • Introduction de la synchronisation de dossiers entre NAS
  • La fonction de recherche de fichiers a été ajouté
  • Le gestionnaire de fichiers supporte maintenant l’affichage des photos et vidéos
  • Support du partage des imprimantes multifonctions (imprimante et scanner) pour Windows
  • Impression depuis iPhone et iPad grace à AirPrint
  • Ajout du MailServer au sein du DSM
  • Refonte du Download Station et de l’Audio Station
  • Surveillance Station supporte désormais jusqu’à 42 Caméras
  • L’application mobile DS Files bientôt disponible

Pour plus d’information consulter le site de Synology.

Pour le téléchargement ça se passe par ici : http://ukdl.synology.com/download/beta/001_Operating%20System/

Source : synology.com

Gérez vous même votre nom de domaine.

Bonjour,

Pour commencer ma série de billets tuto, je vais parler de ce qui facilite tout d’abord la gestion d’un réseau : le DNS. Est-il nécessaire de rappeler le fonctionnement de ce protocole, qui permet de résoudre une IP à partir d’un nom (largement plus facile à retenir) ? Non je ne pense pas. Au pire en voici le lien Wikipédia.

Afin de mettre en œuvre ce tuto, il vous faut un nom de domaine, et un registrar qui vous autorise à le gérer vous même (par exemple OVH, ou Gandi). Pour illustrer mes propos, je prendrai en exemple le nom de domaine nexxx.us que je loue chez OVH.

L’avantage de bind9 (ou named) c’est que le logiciel est administrable de la même manière sur presque toutes les distributions Linux (pas sur Ubuntu par exemple). Pour ma part j’utilise un Debian 5.0 accueillir mon serveur de nom.

Bon maintenant commençons. Loguez vous sur votre machine puis installons bind9 et vérifions le contenu du répertoire.

# aptitude install bind9 bind9utils
# ls -alh /etc/bind/
drwxr-sr-x 3 root bind 4.0K 2011-01-14 00:46 .
drwxr-xr-x 96 root root 4.0K 2011-01-13 10:40 ..
-rw-r--r-- 1 root root 237 2010-08-04 22:50 db.0
-rw-r--r-- 1 root root 271 2010-08-04 22:50 db.127
-rw-r--r-- 1 root root 237 2010-08-04 22:50 db.255
-rw-r--r-- 1 root root 353 2010-08-04 22:50 db.empty
-rw-r--r-- 1 root root 270 2010-08-04 22:50 db.local
-rw-r--r-- 1 root root 3.0K 2010-08-04 22:50 db.root
-rw-r--r-- 1 root bind 617 2011-01-11 22:16 named.conf
-rw-r--r-- 1 root bind 165 2010-08-04 22:50 named.conf.local
-rw-r--r-- 1 root bind 633 2010-12-20 13:18 named.conf.options
-rw-r----- 1 bind bind 77 2010-12-15 17:30 rndc.key
-rw-r--r-- 1 root root 1.3K 2010-08-04 22:50 zones.rfc1918

Tout d’abord quelques explications sur les différents fichiers. Les fichiers commençant par « db » sont des fichiers de bases de données pour les noms domaines gérés par bind. Les fichiers « db » avec des chiffres derrière sont les fichiers bases de données pour le reverse DNS avec les pointeurs inclus dedans. Nous ne nous occuperons pas du reverse DNS, car à moins que vous ne possédiez votre propre bloc d’adresses publiques vous ne pourrez pas gérer les pointeurs depuis votre serveur DNS. Nous allons donc maintenant créer notre propre fichier de zone :

# touch /etc/bind/db.nexxx.us
# vi /etc/bind/db.nexxx.us

$TTL    86400
@       IN      SOA ns0.nexxx.us. admin.nexxx.us(
2011011512      ; serial
28800           ; refresh, seconds
7200            ; retry, seconds
604800          ; expire, seconds
28800 )         ; minimum, seconds
 
; Bloc pour Name serveur
@       IN      NS      ns0.nexxx.us.
@       IN      NS      ns.kimsufi.com.
 
; bloc pour serveur MX
@       IN      MX      5       nh-ks01.nexxx.us.
 
; bloc generique
localhost       IN      A       127.0.0.1
localhost6      IN      AAAA    ::1
 
; Bloc pour machines
nexxx.us.       IN      A       94.23.28.6
ns0             IN      A       94.23.28.6
nh-ks01         IN      A       94.23.28.6
nh-ks02         IN      A       88.177.45.114
 
; Bloc Machine ipv6
ipv6.nexxx.usIN      AAAA    2001:41d0:2:1d06::1
 
; Bloc pour Alias environnement de production
mail            IN      CNAME   nh-ks01.nexxx.us.
www             IN      CNAME   nh-ks01.nexxx.us.

Passons à l’explication de ce fichier :

  • Le TTL (Time To Live) permet de définir le temps maximum de mise en cache de la résolution par les clients DNS. Typiquement ce paramètre est à 24H (86 400 secondes). Si ce paramètre est trop long cela diminue la vitesse de propagation, de vos modifications. en revanche s’il est trop court vous risquez de surcharger votre serveur de clients qui viennent vous réinterroger inutilement.
  • Le SOA (Start Of Authority) est en fait l’entête qui contient les informations générales sur le domaine. On y trouve :
    • le nom du  serveur primaire : ns0.nexxx.us.
    • l’adresse Email du gestionnaire avec un « . » au lieu de l’ « @ » : admin.nexxx.us.
    • le « serial »  qui identifie la version de votre fichier : 2011011512. Il ne faut pas oublier d’incrémenter ce paramètre lors de la mise à jour de vos entrées dns.
    • le « refresh » qui correspond au délai de mise à jour de vos slaves : 28800
    • le « retry »  qui correspond au délai à attendre pour un slave avant de relancer une mise à jour en échec : 7200
    • le « expire » qui définie le temps de validité d’une zone sur un slave s’il est dans l’incapacité de joindre le master : 604800
    • et enfin le « minimum » qui correspond au temps de mise en cache d’une réponse à un enregistrement non existant : 28800
  • Les enregistrements IN :
    • Les NS sont les serveurs DNS qui gèrent la zone. On déclare ici le master et les slaves
    • Les MX sont les serveurs de messageries. Ce champ est utilisé par les serveurs SMTP pour savoir où router les Email. Le MX a la particularité de posséder un champ « poids » qui défini la priorité entre les MX. Plus le chiffre est faible plus le serveur est prioritaire.
    • les A sont les champs d’hôte qui font la correspondance entre un nom et une IPv4.
    • les AAAA ont le même rôle que les A mais pour IPv6
    • les CMANE sont des alias de nom

Maintenant concentrons nous sur le fichier named.conf. Ce fichier contient le détail des zones administrées, avec les fichiers de bases de données associés. Les zones déclarées dans ce fichier ne concernent que la partie localhost pour le moment. Nous allons y ajouter la zone que nous venons de créer à la suite du fichier :

zone "nexxx.us" {
	type master; // Définie notre serveur en maitre sur la zone
	notify yes; // Active la notification de changement aux esclaves
	allow-transfer { 88.100.45.150; 213.186.33.199; }; // Liste des esclaves
	file "/etc/bind/db.nexxx.us"; // Emplacement du fichier de base de données
};

J’ai mis en commentaire dans le fichier ci dessus l’explication de chaque paramètre. J’y ai déclaré deux serveur slave (Le premier étant un autre de mes serveurs, le second étant un serveur mis à disposition par OVH pour cet usage).

Bon maintenant passons à la configuration général de bind. Ceci correspond au fichier named.conf.options.

# vi /etc/bind/named.conf.options

options {
        directory "/var/cache/bind";
 
        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113
 
        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.
 
        // forwarders {
        //      0.0.0.0;
        // };
 
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { 2001:41d0:2:1d06::1; }; //adresse IPv6 d'écoute
        listen-on { 94.23.28.6; }; // adresse IPv4 d'écoute
        allow-recursion { 127.0.0.1; }; // Adresses des clients autorisés à résoudre autre chose que les zones gérés
};

Nous avons maintenant terminé la configuration de notre serveur, il nous faut relancer le service :
# /etc/init.d/bind9 restart
Stopping domain name service...: bind9 waiting for pid 2347 to die.
Starting domain name service...: bind9.

Vous pouvez voir dans le fichier de log la procédure de lancement du service, et vérifier le bon chargement de votre zone :
# cat /var/log/syslog|grep named
Jan 17 11:37:00 ks367743 named[13341]: zone 0.in-addr.arpa/IN: loaded serial 1
Jan 17 11:37:00 ks367743 named[13341]: zone 127.in-addr.arpa/IN: loaded serial 1
Jan 17 11:37:00 ks367743 named[13341]: zone 255.in-addr.arpa/IN: loaded serial 1
Jan 17 11:37:00 ks367743 named[13341]: zone localhost/IN: loaded serial 2
Jan 17 11:37:00 ks367743 named[13341]: zone nexxx.us/IN: loaded serial 2011011706
Jan 17 11:37:00 ks367743 named[13341]: running

Occupons-nous à présent de notre slave. ce dernier doit récupérer la zone de notre master de manière autonome et transparente. Pour cela on va éditer le fichier named.conf sur le slave pour lui rajouter notre zone.

zone "nexxx.us" {
        type slave;
        file "/etc/bind/db.nexxx.us";
        masters { 94.23.28.6; };
};

Une fois le fichier validé, relançons le service bind et vérifions que la zone ait bien été récupérée
# cat /var/log/syslog|grep named
Jan 17 11:48:27 nh-ks02 named[29378]: zone nexxx.us/IN: loaded serial 2011011706
Jan 17 11:48:27 nh-ks02 named[29378]: running
Jan 17 11:48:27 nh-ks02 named[29378]: zone nexxx.us/IN: sending notifies (serial 2011011706)

On peut constater que notre zone s’est correctement chargée au redémarrage.

Voilà notre domaine est créé.  Il faut dorénavant indiquer à notre registrar que nous prenons la responsabilité de la gestion du domaine. Dans notre exemple notre fournisseur est OVH.  Je vais donc vous fournir des captures d’écran qui vous indiqueront comment compléter au mieux les information fournies à notre prestataire.

Tout d’abord connectons-nous sur le manager et allons dans nos options de domaine :

Gestion des DNS OVH

Gestion des DNS OVH

Enfin modifions les propriétés pour que cela soit cohérent avec nos serveurs :

Nous y ajoutons nos serveurs DNS (le master en premier, les slaves ensuite), puis on valide les changements. Il faudra attendre au maximum 24 heures pour que cela se répercute sur les serveurs DNS du registrar (en général au bout d’une heure c’est bon).

Bon nous en avons presque terminé, maintenant il ne nous reste plus qu’a tester la bonne configuration du domaine. Et là, il existe un super outils founir par l’AFNIC : http://www.afnic.fr/outils/zonecheck . Il vous suffit d’entrer votre nom de domaine. Voici le résultat pour nexxx.us :

Afnic ZoneCheck

Un constate une erreur mineur, qui est lié au fait que le serveurOVH ne répond pas au ping (c’est pas notre problème :p)

Bon voilà nous avons maintenant l’entière responsabilité de notre domaine. A vous de jouer maintenant !

PS : En bonus, mon petit script qui permet de versioner et d’actualiser tout les N heures votre base DNS.

#!/bin/bash
#
# Script de mise a jour des DNS
#
#
SERIAL=`date +'%Y%m%d%H'`
BINDDIR=/etc/bind
DBN="db.nexxx.us"
DBF=$BINDDIR/$DBN
OLDF=$BINDDIR/old_$DBN
DOLD=15
LOGF=/tmp/dns_maint.log
TMPF=/tmp/$DBN.tmp
 
if [ -d "$OLDF" ];then
cp $DBF $OLDF/$DBN.$SERIAL
else
mkdir $OLDF
cp $DBF $OLDF/$DBN.$SERIAL
fi
 
# Purge des anciens fichier db
echo "Les fichier suivant vont être purgé :" > $LOG
find $OLDF/ -mtime +$DOLD -print >> $LOGF
find $OLDF/ -mtime +$DOLD -exec rm -f {} \;
echo "Fichier purgés !!!" >> $LOGF
echo "Mise à jour du serial DNS : " >> $LOG
OSERIAL=`cat $DBF|awk '/serial/ {print $1}'`
cat $DBF|sed 's/'$OSERIAL'/'$SERIAL'/g' > $TMPF
cp $TMPF $DBF
echo "Fichier DNS mis à jour, nouveau Serial : "$SERIAL >> $LOG
echo "Rechargement du cache BIND">> $LOGF
/etc/init.d/bind9 reload >> $LOGF
rm $TMPF
echo "Fin du programme !">> $LOGF

Beta Private Cloud OVH : Présentation

Logi OVHBonjour,

Comme beaucoup je trouve que depuis quelques mois le mot « Cloud » est utilisé à tort et à travers trop souvent. Les services marketing ont trouvés en ce mot issu du jargon des ingénieurs un concept clinquant, qui « tâche grave » !

En revanche OVH une société que j’affectionne particulièrement de part ses idées novatrices et ses prix abordables (Non promis plus de pub après ça), proposera d’ici peu un service de Private Cloud.

Le concept est suffisamment simple pour séduire. En souscrivant à ce service vous devenez locataire d’un cluster VMware vSphere. J’entends les septiques d’ici ! Quand je dis cluster voilà grosso modo ce que cela comprend (dans la Beta en tout cas) :

– Un bloc RIPE d’adresse /28 (-1 pour la gateway)

– vos hyperviseurs (ESX) que vous pouvez louer à l’heure en fonction des performances proposées

– votre SAN loué en fonction du volume souhaité et également de l’heure.

Bon étant un grand utilisateur de VMware, je vous dirais qu’il manque encore quelques petites choses (Gestion des pools, des vSwitch…) mais l’essentiel est là. Vous pouvez lancer votre ferme de serveurs à moindre coût avec toute les sécurités qui vont bien (vMotion pour déplacer vos machines entre ESX, VMware HA, pour relancer votre VM sur un autre ESX en cas de crache d’un d’entre eux…). Enfin bref ça s’annonce bien quoi.

Et maitenant le prix… la somme pour laquelle j’en aurais eu en étant client du service est impressionnante (pas loin de 600€ pour 2 ESX et un SAN de 300Go).  Et oui, au cas où vous en doutiez encore ce service est bel et bien destiné aux entreprises de type PME qui souhaitent consolider leurs serveurs visibles de l’extérieur, ou tout simplement réaliser un PRA pour une Web Application par exemple.

Mais l’idée est louable.

Bon maintenant je passe à la rédaction du test avec des jolies photos.