Le petit coin de Nicolas

Contexte / Objectifs

Imaginer :

• Vous êtes dans un grosse PME multi-sites ou avec un hébergement multi-sites
• Un applicatif est soit réparti sur chaque site, soit il est porté globalement en multi-site (ex un serveur de mail, une application web, etc)
• Votre but est de minimiser la gestion de ces équipements tout en gardant une homogénéité au niveau de la conf (tout le monde utilise par ex mail.maboite.tld pour accéder au webmail mais cela pointe en fait sur chaque serveur de mail local).

Deux modes de gestion :

• Au niveau de chaque site, vous avez la solution de déployer un serveur DNS qui gère les entrées correspondantes et faire ainsi la gestion de N dns lors de la modification d'une entrée.
• Vous utilisez les vues DNS et vous déployez un serveur maitre et les vues se transmettront aux esclaves par simple transfert de zone.

Mais au fait, c'est quoi une vue DNS ???

Kezako une vue DNS ?

Pour un serveur DNS donné, celui-ci peut répondre des informations différentes suivant le client ou bien l'IP du serveur DNS utilisée pour faire sa requête.

Dans le cas de mon webmail :

• Suppsons que la répartition entre le site A et le site B se fasse par round robin
• le client arrive sur un Reverse Proxy (RP) qui le dispatche ensuite parmi plusieurs frontaux
• Quand un client arrive sur le site A, le RP doit renvoyer sur les frontaux 10.8.0.102 à 10.8.0.104
• Quand un client arrive sur le site B, le RP doit renvoyer sur les frontaux 10.9.0.102 à 10.9.0.104

Construisons une petite matrice de flux :

Equipements

Soit 5 serveurs ayant les rôles suivants :

• srv101 / 10.8.0.1 : RP + DNS Master site A
• srv102 / 10.8.0.102 : Serveur Mail Site A 1
• srv103 / 10.8.0.103 : Serveur Mail Site A 2
• srv104 / 10.8.0.104 : Serveur Mail Site A 3
• srv201 / 10.9.0.1 - 10.9.0.2 : RP + DNS Slave site B
• srv202 / 10.9.0.102 : Serveur Mail Site B 1
• srv203 / 10.9.0.103 : Serveur Mail Site B 2
• srv204 / 10.9.0.104 : Serveur Mail Site B 3

Mise en place de la configuration DNS

Note

• Le DNS ne doit plus écouter sur le port local
• Il ne doit pas y avoir de règle sur localhost
  • Si localhost autorisé, alors localhost == 127.0.0.1 == IP1.DU.SERVEUR.FQDN == IP2.DU.SERVEUR.FQDN == ... => /etc/resolv.conf à renseigner avec l'IP locale sur lequel le serveur DNS écoute.
• Pour permettre le transfert de zone, le DNS slave doit se synchroniser avec le serveur maitre en faisant des requêtes sur 2 ip distinctes pour voir les 2 vues :
  • Si le DNS slave interroge le DNS maitre avec son IP principale (10.9.0.1), alors il obtient la vue du site B
  • Si le DNS slave interroge le DNS maitre avec son IP secondaire (10.9.0.2), alors il obtient la vue du site A
• Mise en place du transfert sur le DNS slave :
  • Installer Bind
  • Mettre en place le fichier named.conf
  • Lancez bind, il récupère alors les fichiers de zone automatiquement du serveur maitre

Conf DNS Master

Contenu de /etc/named.conf

acl "trusted" {
 localhost;
 10.0.0.0/8;
};
 
options {
    directory "/var/named";
    listen-on {
        10.8.0.1;
    };
    auth-nxdomain no;
    allow-query { trusted; };
    allow-recursion { trusted; };
};
 
# Define ACL for views
acl "frontaux_siteb" {
    10.9.0.102;
    10.9.0.103;
    10.9.0.104;
};

acl "frontaux_sitea" {
    10.8.0.102;
    10.8.0.103;
    10.8.0.104;
};
 
 acl "rpdns_sitea" {
    10.8.0.1; 
};
 
acl "rpdns_siteb" {
    10.9.0.1;
};

acl "rpdns_siteb_ext" {
    10.9.0.2;
};

 # Views definitions
view "site_a" {
	match-clients { frontaux_sitea; rpdns_sitea; };

	# Vue locale
	zone "domaine.tld" IN {
		type master;
		file "sitea.domaine.tld.zone";
		allow-update { none; };
		allow-transfer { 10.9.0.2; };
		notify yes;
	}; 
};
 
view "dns_slave" {
	match-clients { rpdns_siteb_ext; };
 
	# Vue locale
 	zone "domain.tld" IN {
		type master;
 		file "siteb.domaine.tld.zone";
		allow-update { none; };
		allow-transfer { 10.9.0.2; };
		notify yes;
	}; 
};
 
view "site_b" {
	match-clients { frontaux_siteb; rpdns_siteb; };
 
	# Vue locale
	zone "cyclo.priv" IN {
		type master;
 		file "pla.cyclo.priv.zone";
		allow-update { none; };
		allow-transfer { 10.9.0.1; };
		notify yes;
	}; 
};
 

Conf DNS Slave

acl "trusted" {
 localhost;
 10.0.0.0/8;
};
 
options {
    directory "/var/named";
    listen-on {
        10.8.0.1;
    };
    auth-nxdomain no;
    allow-query { trusted; };
    allow-recursion { trusted; };
};
 
# Define ACL for views
acl "frontaux_siteb" {
    10.9.0.102;
    10.9.0.103;
    10.9.0.104;
};

acl "frontaux_sitea" {
    10.8.0.102;
    10.8.0.103;
    10.8.0.104;
};
 
 acl "rpdns_sitea" {
    10.8.0.1; 
};
 
acl "rpdns_siteb" {
    10.9.0.1;
};

acl "rpdns_siteb_ext" {
    10.9.0.2;
};

# Views definitions
view "site_a" {
	match-clients { frontaux_sitea; rpdns_sitea; };

	# Vue locale
	zone "domaine.tld" IN {
		type slave;
		file "sitea.domaine.tld.zone";
		masters { 10.8.0.1; };
		transfer-source 10.9.0.2;
	}; 
};
 
view "dns_slave" {
	match-clients { rpdns_siteb_ext; };
 
	# Vue locale
 	zone "domain.tld" IN {
		type slave;
 		file "sitea.domaine.tld.zone";
		masters { 10.8.0.1; };
		transfer-source 10.9.0.1;
	}; 
};
 
view "site_b" {
	match-clients { frontaux_siteb; rpdns_siteb; };
 
	# Vue locale
	zone "cyclo.priv" IN {
		type slave;
 		file "siteb.domaine.tld.zone";
		masters { 10.8.0.1; };
		transfer-source 10.9.0.1;
	}; 
};
 

Conf Zone sitea.domaine.tld.zone

$TTL 864000
domaine.tld. IN SOA dns.domaine.tld. root.domaine.tld. (
        2009100101
        3600
        3600
        3600
        3600 )
@           IN      NS      domaine.tld.
dns     	IN      A       10.8.0.1
www2		IN      A       10.8.0.102
www2		IN      A       10.8.0.103
www2		IN      A       10.8.0.104
webmail 	IN		CNAME	www2

Conf Zone siteb.domaine.tld.zone

$TTL 864000
domaine.tld. IN SOA dns.domaine.tld. root.domaine.tld. (
        2009100101
        3600
        3600
        3600
        3600 )
@           IN      NS      domaine.tld.
dns     	IN      A       10.8.0.1
www2		IN      A       10.9.0.102
www2		IN      A       10.9.0.103
www2		IN      A       10.9.0.104
webmail 	IN		CNAME	www2

Conf OS

/etc/resolv.conf

Serveurs du site A :

search domaine.tld
nameserver 10.8.0.1

Serveurs du site B :

search domaine.tld
nameserver 10.9.0.1

Tests

Depuis le site A

La commande dig @10.8.0.1 webmail.domain.tld depuis un serveur du site A doit vous renvoyer une réponse en 10.8.0.x

Depuis le site B

La commande dig @10.9.0.1 webmail.domain.tld depuis un serveur du site A doit vous renvoyer une réponse en 10.9.0.x

Transfer de zone

Lorsque vous démarrez le DNS esclave, il doit récupérer automatiquement les deux fichiers de zone avec un contenu identique à celui décrit plus haut.

Sources

• Views in Bind 9
• Split views with Bind 9 Howto
• Bind - Gentoo Linux Wiki

Pour conclure...

J'espère que c'est pas trop confus et que cela vous aura donner des idées.

Dans mon cas, j'utilise ça avec en plus une zone privée :

• les internautes arrivent de l'extérieur avec une url publique
• ils transitent sur le réseau interne via des urls privées

Ordre

Une des fonctionnalités intéressante d'apache d'un point de vue administration est de pouvoir déposer des fichiers de configuration complémentaires sans avoir à toucher au fichier de configuration de base, et ce dans le répertoire /etc/httpd/conf.d/ ou /etc/apache/conf.d suivant la distribution utilisée.

Il faut néanmoins faire attention à un point, les fichiers sont chargés dans l'ordre alphabétique. Par ailleurs, dans une configuration avec une IP utilisant les virtualhost (qui ose ne pas les utiliser ?) il faut que le premier virtualhost chargé contienne la directive NameVirtualHost xxx.xxx.xxx.xxx:xx

Il vous faut donc adopter l'ordre suivant :

1. Fichiers chargeant les modules apache requis pour le(s) site(s)
2. Fichier chargeant le vhost avec la directive NameVirtualHost xxx.xxx.xxx.xxx:xx
3. Reste des fichiers de configuration des virtualhosts
4. Autres fichiers

Cela vous évitera de perdre comme moi 2h la semaine dernière à tenter de comprendre pourquoi l'authentification NTLM ne fonctionnait plus sur une url mais bien sur une autre. L'ordre alphabétique des fichiers faisait que j'avais inversé le point 1 et 2. Par contre, pour l'url d'un site situé en 3, comme le module avait été chargé en phase 2, alors l'authentification était fonctionnelle pour ce site...

Inclusion

Le module "core" d'apache fournit la directive Include très utile dans la cas où il faut reproduire une configuration identique pour plusieurs virtualhosts. Prenons le cas de deux sites réalisés avec le même outil et accessibles sous deux urls différentes (monsite.fr et monsite.com par ex). Ces deux sites possèdent le même jeu de réécriture d'url (ie celles fournit par le produit).

Une première et mauvaise façon de faire serait de créer 2 fichiers de configuration contenant à chaque fois l'ensemble de la configuration. En cas de modification d'une règle, il vous faut faire la modification à deux endroits.

Cela vous donnerait un fichier du type /etc/httpd/conf.d/www.monsite.fr.conf :

<VirtualHost *>
    ServerName www.monsite.fr
    DocumentRoot /var/www/monsite

    <Directory /var/www/monsite/>
        ...
        Ensemble d'instructions
        ...
    </Directory>

    ...
    [Jeu d'instrusctions de réécriture]
    ...

    ErrorLog ...
    AccessLog ...
</VirtualHost>

Idem pour monsite.com (/etc/httpd/conf.d/www.monsite.com.conf)

La bonne façon de faire est la suivante : /etc/httpd/conf.d/www.monsite.fr.conf

<VirtualHost *>
    ServerName www.monsite.fr
    Include /etc/httpd/application/directory.txt
    Include /etc/httpd/application/rewrite_rule.txt

    ErrorLog ...
    AccessLog ...
</Virtualhost>

et /etc/httpd/conf.d/www.monsite.com.conf

<VirtualHost *>
    ServerName www.monsite.com
    Include /etc/httpd/application/directory.txt
    Include /etc/httpd/application/rewrite_rule.txt

    ErrorLog ...
    AccessLog ...
</Virtualhost>

Avec /etc/httpd/application/directory.txt :

    DocumentRoot /var/www/monsite

    <Directory /var/www/monsite/>
        ...
        Ensemble d'instructions
        ...
    </Directory>

et /etc/httpd/application/rewrite_rule.txt :

    [Jeu d'instrusctions de réécriture]

Ainsi, on peut mutualiser au maximum au niveau de la configuration d'apache, sans se priver de pouvoir rajouter des directives propres à un virtual host en incluant des fichiers supplémentaires.

Ex si on a une couche SSO pour un site et une version anonyme :

/etc/httpd/conf.d/intranet.monsite.fr.conf

<VirtualHost *>
    ServerName intranet.monsite.fr
    Include /etc/httpd/application/directory.txt
    Include /etc/httpd/application/rewrite_rule.txt
    Include /etc/httpd/application/authentification_SSO.txt

    ErrorLog ...
    AccessLog ...
</Virtualhost>

et /etc/httpd/conf.d/intranet.monsite.com.conf

<VirtualHost *>
    ServerName intranet.monsite.com
    Include /etc/httpd/application/directory.txt
    Include /etc/httpd/application/rewrite_rule.txt
    # Include /etc/httpd/application/authentification_SSO.txt

    ErrorLog ...
    AccessLog ...
</Virtualhost>

Bien sur, vous pouvez mettre vos fichiers ailleurs que dans /etc/httpd/application

Si vous êtes à la recherche (ou connaissez des gens susceptibles d'être intéressés) d'un stage ou d'un contrat d'apprentissage pour travailler sur des projets web avec les outils eZ Publish (Intranet groupe principalement, Sites web vélos éventuellement) ou Symfony (probabilité plus faible mais sait-on jamais), n'hésitez pas à me contacter à l'adresse : nsteinmetz AT gmail POINT com.

Le stage / contrat d'apprentissage se déroulerait à Plaisir (78)

Outre le fait que la version 4.0.2 vient de sortir, il y a deux choses qu'il faut bien avoir en tête pour maintenir des sites sous eZ Publish :

• Eviter tant que faire ce peut de devoir renseigner des identifiants de noeud (Node id) dans les fichiers de settings. Lors de la mise à jour d'un environnement par ex, vous êtes bon pour les mettre à jour ou lors d'un déploiement en production, vous ne pouvez pas compter sur les id disponibles sur un autre environnement - vous obligeant à prévoir leur mise à jour dans le cadre du déploiement.
• Nettoyer vos settings au fur et à mesure :
  • Si des données relatives à plusieurs siteaccess deviennent identiques, alors déplacer les une bonne fois pour toutes dans "override"
  • Si des données ne sont plus utilisées, supprimer les
  • Si vous créez un siteaccess à partir d'un autre, ne gardez que ce dont vous avez besoin. Cela vous évitera de trainer des choses sans savoir pourquoi elles y sont...

Dans le cas d'une instance eZ Publish mutualisée (ie si vous utilisez plusieurs siteaccess, que ce soit des contenus différents par siteaccess ou bien la présentation traduite d'un contenu), vous devriez être en mesure de définir des modèles recensant le minimum / maximum de ce que peut contenir un siteaccess (idéalement que le spécifique). C'est d'ailleurs ce travail de définition de modèle que je compte faire prochainement afin de nettoyer des siteaccess non maintenus depuis maintenant plus d'un an et ayant eu de fortes évolutions...

Dans le premier épisode, nous avons vu la notion de roles

Rappel :

 python
@roles('prod')
def clean_remote_all():
    """
    delete old html files on remote server
    """
    run("rm -rf $(remote_dir)/*")

Or on peut aussi la notion de rôle pour distinguer dans une architecture n tiers, un serveur web du serveur de base de données. On peut donc imaginer un rôle "httpd" et un rôle "rdbms".

L'astuce "du jour" consiste à faire en sorte que l'on puisse utiliser ces rôles httpd/rdbms quelque soit l'environnement cible (dev / preprod / prod).

Commençons par définir nos environnements :

 python
# Dev envts
config.rdbms_dev = ['wwwdev']
config.httpd_dev = ['dbdev']

# Preprod envts
config.rdbms_ppr = ['wwwppr']
config.httpd_ppr = ['dbppr']

# Prod envts
config.rdbms_prd = ['wwwprd']
config.httpd_prd = ['dbprd']

L'astuce consiste ensuite à affecter les valeurs définies ci-dessus aux variabled httpd et rdbms afin de pouvoir les utiliser.

 python
#
## Set hosts in functions to use fab <env> <action>
#

def dev():
    """
    Define developement server
    """
    config.rdbms, config.httpd = config.httpd_dev, config.rdbms_dev

def preprod():
    """
    Define pre-production server
    """
    config.rdbms, config.httpd = config.httpd_ppr, config.rdbms_ppr

def production():
    """
    Define production server
    """
    config.rdbms, config.httpd = config.httpd_prd, config.rdbms_prd

En invoquant l'environnement lors de l'utilisation de fab, du style :

 bash
fab dev

... alors httpd prendra pour valeur "wwwdev" et rdbms prendra la valeur "dbdev"

Si j'ajoute ensuite dans mon fichier fabfile.py :

 python
#
## Test Block
#

@roles('rdbms')
def prepare_db():
    run("echo Preparing database for deployment")

@roles('httpd')
def prepare_web():
    run("echo Preparing web servers for deployment")

@depends(prepare_db, prepare_web)
@roles('httpd')
def deploy():
    run("echo Doing final deployment things to $(fab_host)")

Je peux selon mes besoins et avec le même résultat final mais sur des environnements différents deployer mon application de la façon suivante :

 bash
fab dev deploy
fab preprod deploy
fab production deploy

Autre chose intéressante ajoutée à Fabric mais non encore testée par mes soins pour le moment : la capacité de pouvoir spécifier un hote sur lequel exécuter une commande spécifique avec une syntaxe du type :

 sh
fab ping_servers:hosts="a;b;c"

L'action "ping_servers" va être exécutée que pour les servuers a, b et c