WikiTeki /  HébergementWeb / SocleTechnique

Page dédiée aux explications techniques des hébergements web assurés par l'AUF

Infrastructure

• tout serveur web doit être dans un CT car le web est le premier vecteur d'intrusion/attaque et de ce fait ce doit être encadré au maximum

• filtrage serré dans l'hôte

• L'installation du serveur physique devrait s'inspirer de Projet/ModèleLucid/ServeurBureautique

• OpenVZ
  • un CT pour le frontal web
  • un CT pour stocker toutes les bases de données (MySQL ou PostgreSQL par exemple)
  • un CT pour centraliser les logs des conteneurs
  • plusieurs CTs pour les sites à héberger

• le dossier web par défaut devrait se situer sous /srv

Réseau

Au minimum 2 interfaces réseau.

• une disposant d'une adresse accessible de l'extérieur ¹

• une autre pouvant faire office de pont pour le réseau privé en 192.168.0.0/24 par exemple
  • tous les CTs devraient disposer d'une adresse dans ce bloc

Parefeu et Filtrage

• par défaut on bloque tout
• DNAT depuis l'hôte du port 80 vers le frontal web

• les conteneurs ne doivent avoir accès à l'extérieur (web sortant) que pour des réseaux bien déterminés

  • les mises à jour debian
  • le réseau du responsable du produit.
    • c'est parfois nécessaire pour le téléchargement de plugins et autres extensions

• Permettre l'accès par ssh aux conteneurs afin de pouvoir éventuellement répartir l'administration technique sans devoir passer par l'hôte

• amélioration possible

seconde interface IP qui ferait
pont avec les containers... Si on peut éviter, c'est mieux, non ? 

[..] on pourrait effectivement pousser un peu plus, en faisant un pont
pour un réseau portant les services publiques (via NAT quand on a un
nombre d'IP limitées) et un autre pont qui ne ferait de communication
que via le proxy frontal web

• bien contrôler le nombre d'accès simultanés et les dénis de service

NS

Serveur DNS installé sur l'hôte à usage exclusif par les différents CTs

• 1 zone privée comme : .openvz

• résolution de noms externes
• aucun autre accès autorisé à ce serveur

Messagerie et smarthost

• exim4 partout où il n'y a pas un service SMTP complet

• tous les exim4 devrait pointer sur un smarthost

  • typiquement.. tout courriel dans un CT devrait passer par le Exim4 local
• une suggestion pour les alias de réception d'infos techniques

  • technique@xx.auf.org => contact général

  • technique-logs@xx.auf.org => les logs à lire de temps en temps

  • technique-alert@xx.auf.org => les alertes à lire et traiter

Conteneur standard

Au minimum il faut disposer des conteneurs suivant

CT base de données

Plusieurs technologies au choix... MySQL , PostgreSQL ²

Ce qui compte est de centraliser l'ensemble des bases de données dans un seul conteneur

• une base de données par conteneur
• un utilisateur avec les droits les plus spécifiques sur cette base
• en fonction du moteur de bases de données prévoir ,si les contraintes sont fortes de faire de la réplication.

Planifier des sauvegardes par base qui seront stockées dans un site approprié selon le contexte

CT MySQL

CT PostgreSQL

...

Web frontal

• apache2 avec modules: proxy,proxy_http
• tous les sites seront sur ce modèle de vhost

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerAlias ct.xxxx
        ServerName xxxx
        ProxyPass / http://xxxx./
        ProxyPassReverse / http://xxxx./
        ErrorLog ${APACHE_LOG_DIR}/site-xxxx_error.log
        CustomLog ${APACHE_LOG_DIR}/site-xxxx_access.log combined

</VirtualHost>

le ServerAlias peut être utilisé avec profit pour certaines tâches comme lancer des scripts depuis le web frontal qui passeraient par l'interface web d'un conteneur..

CT supervision

Il est préférable qu'il ait un numéro d'ordre (CTID) plus élevé que tous les autres conteneurs.

Il pourrait servir pour monitorer l'ensemble des CTs si on ne souhaite pas déporter l'ensemble des informations ailleurs. Comme outils:

• munin
• rsyslog

  • dans /etc/rsyslog.conf quelques lignes importantes (à décommenter ou ajouter selon)

$ModLoad imudp
$UDPServerRun 514

# pour les templates
$template DynFile,"/var/log/host/%fromhost%/all.log"
*.*    ?DynFile

Modèles de conteneurs OpenVZ

En fonction des besoins, il faudra disposer de plusieurs templates; certains pouvant dériver d'autres.

Template de base

• locales

• vim par défaut :  update-alternatives --config editor

• Comptes des administrateurs et groupe admin

• auf-git-etc
• exim4-daemon-light

  • /etc/mailname à bien paramétrer

  • envoi par un smarthost; pas de courriel en local
• Exim4 sur les CT et redirection vers un smarthost approprié

• /etc/resolv.conf : nameserver ip.interface.privée.hôte

• configurer rsyslog en créant un fichier /etc/rsyslog.d/local.conf  dans lequel on inscrira l'adresse IP du ct-syslog

  • sur les clients un fichier /etc/rsyslog.d/local.conf  qu'on créé avec avec l'adresse IP du ct-syslog

emplacement des logs de tous les niveaux de priorité pour la facility xx
localxx.*     /var/log/localxx

#envoi des logs en UDP sur le CT de supervision
*.* @nom.DNS.du.CT.de.supervision

• redirection des erreurs d'apache dans une facility avant copie en réseau; modifier la valeur de la directive ErrorLog dans le fichier de configuration du vhost

ErrorLog syslog:localxx

Template application python

Template application django

Template application php

• De manière générale il faudra s'assurer que les variables présentes dans /etc/php5/apache2/php.ini conviennent aux besoins.

• Consulter la documentation Debian et officielle le cas échéant
• parfois ces modifications sont prises en compte dans la création des virtualHost dans apache

Template CT-moodle

Ce template repose sur l'installation du paquet moodle fournit par Debian squeeze, en l'occurence moodle-1.9.9.dfsg2-2.1+squeeze3

• vérifier adresse de l'interface dans /etc/network/interfaces

• /etc/dbconfig-common/moodle.conf 

dbc_dbtype='mysql'
dbc_dbuser='xxxx'
dbc_dbpass='xxxx'
dbc_dbserver='ct110.openvz'
dbc_dbname='moodleNOMDUSITE'
dbc_dbadmin='root'

• exécutez dpkg-reconfigure moodle

  • url du site

  • pas de configuration de la BD (elle est faite manuellement sur le CT-MySQL)

  • garder la version actuellement installée

  • pour apache.vhost.conf, accepter la version du responsable du paquet (ou modifier ultérieurement si nécessaire)

• faire un lien symbolique pour le vhost sudo ln -s /etc/moodle/apache.vhost.conf /etc/apache2/sites-enabled/moodle-medecine 

• se rassurer que tous les droits sont corrects notamment dans le moodledata qui est /var/lib/moodle

• pas besoin de cron.. le paquet debian en installe un dans /etc/cron.d/moodle

Template CT-moodle-wheezy

Il est préférable de faire un debootstrap se servant de wheezy et puis archiver le contenu et le stocker dans /var/lib/vz/template/cache avant de continuer.

De là, démarrer une instance qu'on peut configurer en se basant sur ce qui a été fait pour le ct-moodle squeeze.

Template CT-spip

Des notes:

• NdimbyAndriantsoavina/spip

• ZAO/Dakar/Configuration/Spip

Modèles avec debootstrap

Une alternative aux modèles de conteneurs c'est de se servir uniquement de debootstrap. Ce dernier se sert de template avec la liste des paquets à installer.

• intérêt immédiat: la génération d'un système par ce biais repose sur les derniers paquets disponibles dans les dépôts
• procédure indépendante d'OpenVZ

Sauvegarde

• base de données : créer une tâche automatisée qui récuperera les dumps par base et qui seront stockés dans un dossier spécifique

• autre données tout récupérer (ainsi que les dumps) grâce notamment à BackupPC.