{{{#!wiki warning '''Attention''' Cette page est une ébauche de documentation, qui pour le moment '''N'EST PAS UN MODÈLE À SUIVRE à l'AuF''' }}} <> 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 {{{ 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 }}} {i} 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''. ----