Environnement de travail Distribution: Ubuntu 11.10
Packages Code: sudo apt-get install lamp-server^ L installation d Apache2 est détaillée là: http://www.linux-france.org/prj/edu/archinet/systeme/ ch16s02.html
Configuration de Apache httpd.conf et a2(en,dis)site Initialisation Tous les fichiers sont à partir de /etc/apache2/ Apache2 gère un ensemble d URL, avec pour chaque domaine URL un hôte virtuel Apache2 est configuré par défaut avec un hôte virtual dans le fichier httpd.conf On configure des hôtes dans le répertoire sites-available On rend un hôte actif avec a2ensite hôte On rend un hôte inactif avec a2dissite hôte À chaque changement de configuration il faut relancer apache avec sudo service apache2 reload ou sudo apachectl graceful
Configuration d un hôte de base Un hôte est défini par: l adresse IP sur laquelle il écoute, en générale *:80 Le domaine URL qu il sert, par exemple example.org ou localhost Le répertoire du système de fichiers correspondant à l URL de base, par défaut /var/www Fichier sites-available/localhost: <VirtualHost *:80> ServerAdmin me@gmail.com ServerName localhost DocumentRoot /var/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> Alias /doc "/usr/share/doc" <Directory "/usr/share/doc"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from 127.0.0.0/255.0.0.0 ::1/128 Allow from 141.115.74.22/255.255.0.0 </Directory> </VirtualHost>
Configuration d un hôte, explications Alias: La ligne d alias signifie que le répertoire servi par localhost/doc/ ne sera pas /var/www/doc, mais /usr/share/doc Directory: cet élément sert à spécifier le traitement du répertoire: Options: Indexes affiche la liste des fichiers par défaut, Multiviews signifie qu Apache sert le document à servir en fonction de la requête (index.en.html pour index.html si le client a pour locale en) AllowOverride: spécifie si Apache doit regarder les fichiers.htaccess Order: deny,allow signifie que Apache va d abord évaluer les règles Deny, puis les règles Allow pour décider si une requête est permise. La précédence va à la dernière évaluation (ici, Allow)
Architecture Rack But Une interface commune pour les applications basées sur Ruby Sous-répertoires de l application: public: contient les données qui seront servies tmp: utilisé en particulier pour le fichier restart.txt (l application est redémarrée à chaque touch sur ce fichier) un fichier config.ru pour le lancement de l application le module libapache2-mod-passenger fait le lien entre l architecture Rack et Apache2 Bien sûr, Rails suit cette architecture...
Installation du module Passenger On passe par apt-get pour l installation: Code: $ sudo apt-get install libapache2-mod-passenger $ a2enmod passenger La seconde ligne intègre le module à Apache. Comme d habitude, il faut ensuite relancer Apache... Les instructions de configurations sont disponibles à l adresse: http://www.modrails.com/documentation/users%20guide%20apache.html
Mise en ligne d une application sur un hôte On écrit un hôte dédié qui sert des applications rails il sert les documents sous /webapps On veut déployer l application exemple Avec le fichier ci-contre elle devient disponible à l URL ex.example.org Il faut encore que le DNS (ou /etc/hosts si l accès local suffit) puisse associer ce nom à la machine locale Fichier site-availables/rails: <VirtualHost *:80> ServerName ex.example.org ServerAdmin me@gmail.com DocumentRoot "/webapps/exemple/public" <Directory "/webapps/exemple/public"> Allow from all Options -MultiViews </Directory> </VirtualHost>
Mise en ligne de plusieurs applications sur un hôte En local, on aimerait avoir un seul hôte rails qui sert toutes les applications rails On veut déployer les applications exemple1 et example2 dans /webapps On fait deux liens symboliques de exemple1/public et exemple2/public vers /webapps/exemple1 et /webapps/exemple2 Fichier site-availables/rails: <VirtualHost *:80> ServerName rails ServerAdmin me@gmail.com DocumentRoot "/webapps" <Directory "/webapps"> Allow from all </Directory> <DirectoryMatch "^/webapps/> Options -MultiViews </Directory> </VirtualHost> et mettre rails sur la même ligne que localhost dans /etc/hosts
Passage en mode production La manipulation précédente a pour but de pouvoir tester une Rails application en mode production sans avoir à passer par heroku Elle est aussi une base pour le déploiement professionnel dans un Cloud non-dédié à Rails (comme slicehost.com ou Amazon EC2) On va passer du répertoire de développement au répertoire qui sera servi (via le lien symbolique) par Apache/Passenger en: Copiant le répertoire dans un répertoire contenant les versions «production» des applications En mettant les bases de données à jour pour l environnement de production
Suite de la présentation 1. On installe hg (mercurial) pour déplacer correctement et rapidement les applications entre différents répertoires 2. On décide d une architecture pour le placement des applications 3. On automatise les manipulations avec des scripts
Motivation Synchronisation de répertoires: On veut pouvoir transporter les sources vers le répertoire de tests ou de production Ces répertoires seront gérés par une installation locale d Apache Code: sudo apt-get install hg
Principales commandes hg init: prépare le répertoire courant pour mercurial hg add.: initie la gestion de tous les fichiers et sous-répertoires du répertoire courant hg commit: crée une version pour mercurial hg clone rep : copie le répertoire rep dans le répertoire courant (après la première fois) hg pull: copie le répertoire rep dans le répertoire courant (après la première fois) hg pull: copie le répertoire vers le répertoire dont il est le clone
Déploiement en mode production (local) Emplacement des répertoires: ${HOME}/src/Rails/: répertoire contenant toutes les applications rails en cours de développement ${LOCAL}/www-src/: répertoire contenant toutes les applications rails déployées localement ${LOCAL}/webapps/: répertoire contenant les applications rails déployées Script ${HOME}/bin/wwwproduction: #! /bin/bash umask 0770 SRC_DIR=${HOME}/src/Rails OUT_DIR=${LOCAL}/www-src/ WWW_DIR=${LOCAL}/webapps/ CURRENT_DIR=${PWD} cd ${OUT_DIR} if [ -d "${SRC_DIR}/$1" ] ; then if [ -d "$1" ] ; then cd $1 ; hg pull rake db:migrate RAILS_ENV="production" touch tmp/restart.txt else hg clone ${SRC_DIR}/$1 if [! -d $1/tmp ] ; then mkdir $1/tmp ; touch tmp/restart.txt fi rake db:migrate RAILS_ENV="production" chgrp -R www-data. ; cd ${WWW_DIR} ln -sf ${OUT_DIR}/$1/public $1 fi else echo "Usage: $0 <nom de l app Rails>" fi cd ${CURRENT_DIR}
Contrôle d accès Cadre Apache2 est exécuté par l utilisateur www-data du groupe www-data On utilise le groupe www-data pour désigner tous les utilisateurs pouvant mettre en ligne des applications rails On veut les droits suivants: Pour ${LOCAL}/www-src et ${LOCAL}/webapps: www-data (user,apache)-> read, write,execute www-data (group) -> création d un nouveau répertoire ou d un lien Sur les applications: www-data (user,apache)-> read, write,execute owner (user) -> read,write,execute www-data (group) -> read,execute Problème: www-data et propriétaires avec les mêmes droits
Access Control List Motivations: Permettre à l utilisateur www-data et au créateur d une application d agir avec les droits utilisateurs sur les fichiers d une application Droits Unix habituels: un seul utilisateur, il faudrait donner les droits d écriture au groupe www-data Mais alors n importe quel membre du groupe www-data pourrait modifier les applications des autres membres Intérêt des Access Control Lists Plusieurs utilisateurs peuvent mettre en ligne des applications Permet la ségrégation en créant un compte utilisateur par application
Contrôle d accès Droits pour le répertoire ${LOCAL}/www-src Principe: On utilise le sticky bit et un droit en écriture pour www-data sur le répertoire ${LOCAL}/www-src pour que les membres du groupe www-data puissent créer des applications Code: sudo chown root:www-data ${LOCAL}/www-src sudo chmod g+t ${LOCAL}/www-src
Contrôle d accès Droits pour le répertoire ${LOCAL}/webapps Principe: On utilise le sticky bit et un droit en écriture pour www-data sur le répertoire ${LOCAL}/www-src pour que les membres du groupe www-data puissent créer des liens vers leurs applications Code: sudo chown root:www-data ${LOCAL}/webapps sudo chmod g+t ${LOCAL}/webaaps
Contrôle d accès Configuration de l utilisateur Principe: Lorsqu un membre du groupe www-data veut créer ou modifier une application, il doit être explicitement dans ce groupe, et tout interdire pour les membres de ce groupe Démarrage de l édition newgrp www-data umask 077 Fin de l édition exit
Accès donné à l utilisateur www-data (Apache) Mettre en place les ACLs sur une partition Les ACLs ne sont pas supportées par défaut Pour qu elles soient supportées dans une partition, il faut monter cette partition avec l option acl (éditer /etc/fstab si nécessaire, démonter la partition, et la remonter) Une fois que c est fait: Code: sudo setfacl -R -m u:www-data:rwx,m:rwx ${LOCAL}/www-src Exemple de fichier /etc/fstab: /dev/sda6 /export/longview ext3 acl,errors=remount-ro 0 1