Migrations effectuées le 2016-01-09 par fr33tux et nicoo.
Apache -> Nginx
Base de l'installation
On installe le paquet
nginx-light
depuis les dépôts Debian :apt-get install nginx-light
On écrit la configuration globale, en particulier on crée
snippets/tls.conf
etsnippets/restrictions.conf
On commence par recréer (dans
sites-available/https
) la structure présente avec Apache:- une ribambelle de
location truc { alias /le/chemin; }
- les redirections pour les documents ayant été déplacés.
- une ribambelle de
Ikiwiki
Ikiwiki utilise un script CGI pour l'édition.
Dans un premier temps, on le rend accessible directement à Nginx
via fcgiwrapper
.
apt-get install fcgiwrap
- On créé
fcgiwrap.conf
On ajoute les entrées qu'il faut pour chaque
ikiwiki.cgi
:location = /ecrire/ikiwiki.cgi { fastcgi_param SCRIPT_FILENAME /srv/ikiwiki/website/ecrire/dest/ikiwiki.cgi; include snippets/fcgiwrap.conf; } location = /wiki-admin/ecrire/ikiwiki.cgi { fastcgi_param SCRIPT_FILENAME /srv/ikiwiki/wiki-admin/ecrire/dest/ikiwiki.cgi; include snippets/fcgiwrap.conf; } location = /wiki-ca/ikiwiki.cgi { fastcgi_param SCRIPT_FILENAME /srv/ikiwiki/wiki-ca/dest/ikiwiki.cgi; include snippets/fcgiwrap.conf; }
NOTE : fcgiwrap
lance les scripts sous www-data
, mais
les scripts Ikiwiki sont setuid pour le bon user.
Awstats
Bonne surprise, on n'a que du contenu statique. Il suffit donc de reproduire l'ancienne conf Apache, en précisant l'authentification basique de la même manière :
location /stats {
alias /srv/awstats/html;
auth_basic "Statistiques de fréquentation";
auth_basic_user_file /etc/nginx/passwd/wiki-ca;
}
location /awstats {
alias /srv/awstats/html;
auth_basic "ca stats";
auth_basic_user_file /etc/nginx/passwd/wiki-ca;
}
location /awstats-icon {
alias /usr/share/awstats/icon;
}
On adapte /etc/awstats/awstats.nos-oignons.net.conf
pour qu'il utilise les logs Nginx.
On met également le hook pre-rotate de logrotate sur les logs Nginx, au lieu d'Apache.
Request Tracker
- On s'appuie sur https://www.bestpractical.com/docs/rt/latest/web_deployment.html#nginx
- nicoo s'est fendu d'un initscript qui lance
rt-server.fcgi
avec de faire fonctionner RT via fastcgi. - La config Nginx reprend certains éléments de l'ancienne conf Apache :
- On restreint l'accès à
/rt/REST/1.0/NoAuth
à localhost - On bypasse le process FastCGI pour les images (statiques)
- On restreint l'accès à
- On met plusieurs heures à découvrir que RT se fache tout rouge si on ne lui donne pas
fastcgi_param SCRIPT_NAME "/rt"
dans/etc/nginx/sites-enabled/https
..
Mailman
On invoque les binaires de mailman à travers fcgiwrap.
Malheureusement, mailman utilise des chemins du type /mailman/commande/parametre
,
donc on joue de fastcgi_split_path_info
pour extraire les paramètres et le binaire
à invoquer.
Concaténation de la chaîne de certificats
Nginx demande à ce que l'ensemble de la chaine de certificats soit concaténée
dans un seul fichier : /etc/ssl/certs/www.nos-oignons.net-2014-chain.crt
qui contient, dans l'ordre :
* Le certificat du domaine : `/etc/ssl/www.nos-oignons.net-2014.crt`
* Les certificats de l'autorité : `/etc/ssl/PositiveSSLCA2.crt`
On ajoute ensuite le chemin vers le nouveau fichier dans la configuration
Nginx (ssl_certificate
), le chemin de la clé (ssl_certificate_key
)
n'a lui pas changé.
Gitweb
Vu que les chemins vers les dépôts sont aliasés à la racine, il n'y a pas
besoin d'adapter la configuration pour transmettre à git les requêtes
de git clone & co.
Il y a eu malgré tout besoin de séparer le contenu statique (/gitweb/static
)
du reste pour ne pas qu'il soit correctement rendu. (TOFIX)
Pour les requêtes sur gitweb, on a besoin de splitter le path_info
pour
accéder aux commandes et dépôts voulus. On précise le fichier de configuration
de gitweb et transmet la requête à /usr/share/gitweb/gitweb.cgi
.
location /gitweb {
location /gitweb/static {
alias /usr/share/gitweb/static;
}
fastcgi_split_path_info gitweb/()(.*)$;
fastcgi_param SCRIPT_FILENAME /usr/share/gitweb/gitweb.cgi;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param GITWEB_CONFIG /etc/gitweb.conf;
include snippets/fcgiwrap.conf;
}
Wheezy -> Jessie (Bulbe)
La migration elle même
- Désinstallation d'Apache2
- Édition de
/etc/apt/sources.list
:s/wheezy/jessie/g
- Remplacement de
wheezy-backports
parjessie-backports
dans/etc/apt/sources.list.d/backports.list
- Edition de
/etc/apt/apt.conf.d/50unattended-upgrades
, qu'on convertit à l'utilisation des codenames plutôt que « stable ». - On lance
apt-get update && apt-get dist-upgrade
Pendant l'upgrade, on tombe presque à court de disque (sauvés par l'espace réservé à root) Certains logs seront deplacés temporairement vers/srv/log
- Suppression des .deb obsolètes de
/var/cache/apt
(~600Mo de gagnés), reapt-get upgrade
pour finir. - L'absence de
libdatetime-event-ical-perl
fait échouer les scripts de mise-à-jour de RT. C'est reporté dans Debian : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819675 - On édite
/etc/request-tracker4/RT_SiteConfig.pm
pour utiliserAuth::Crypt
au lieu deAuth::GnuPG
(déprécié) - On relance
dist-upgrade
... - On étend le LV bulbe/root d'un Go, histoire de ne pas craindre les soucis de place
- Supression des paquets obsolètes, à quelques exceptions notables: gitolite, Postgre 9.1 et schleuder
- reboot... et rien au démarrage.
On contacte thomasvo, de Grenode, qui met à jour la config côté hyperviseur (pygrub),
mais ce n'est pas suffisant: on a une erreur en tentant de monter /boot.
On essaie plusieurs trucs, mais visiblement systemd n'a rien de prévu pour ignorer
une erreur au montage d'un système de fichiers ...
En fait, si, on peut mettre
errors=nofail
dans le fstab, alors qu'avant c'étaiterrors=continue
... >_<'
Bley
- Ajout de l'entrée
exim_workaround = 0
dans/etc/bley/bley.conf
sans quoi bley ne démarre pas.
Schleuder
- Plus de paquet dans jessie : http://schleuder2.nadir.org/news/schleuder_on_debian_jessie.html
- On remet les dépots de wheezy, pin en priorité -1
- On installe
ruby1.8-dev
- On installe les autres dépendances via
rubygem
comme décrit sur le site de schleuder Petite différence :log4r
ne semble pas disponible dans la version prescrite ; on installe ce qu'il y a.
Le 12/01 au soir, on se rend compte que Schleuder ne voit plus aucun mail.
nicoo jette un œil et il semble que la partition était de nouveau pleine, et que SpamAssassin ne se soit pas relancé suite au reboot. Résultat, les mails ont bouncé et n'ont pas été envoyés. En faisant de la place et relançant spamd, les mails sont délivrés.
RT
- On commente deux lignes de config qui ne marchaient de toutes façons pas, et ont le mauvais goût d'empêcher la nouvelle version de se lancer.