Montée en version OpenBSD : 5.6 vers 5.7
Voici un exemple de montée en version OpenBSD, un cas concret de manipulation autour d’Openbsd que nous avons l’habitude de réaliser. Il s’agit de migrer deux Firewall en Production.
Montée en version OpenBSD : Migration de deux firewall en production
- Nous avons l’habitude d’utiliser des commandes simples pour mettre à jour nos distributions Linux, mais qu’en est-il d’OpenBSD?
La sécurité prime pour cette distribution orientée pare-feu haute
disponibilité mais au détriment de la facilité d’upgrade. - Nous allons voir les différentes étapes afin de parvenir à une montée en version OpenBSD sans risque à travers l’exemple de deux firewalls filtrant mis à jour sans interruption de service. Nous effectuons les mises à jour via le disque dur. Il est bon de savoir que le cycle de sortied’une nouvelle mouture stable est de 6 mois.
- Avant de se lancer il est important de lire les patch notes :
http://www.openbsd.org/faq/upgrade57.html pour la version qui nous
intéresse.Nos deux pare-feu disposent de OpenBGP / pf / pfsync ainsi que des cartes carp0 afin d’assurer la redondance via une Virtual IP. - Nous commencerons par le slave puis, effectuerons la bascule pour mettre l’autre firewall à jour.
1. Vérification et précautions d’usage
- Bien que ces précautions ne soient pas une obligation, il sera plus
rapide en cas de problème, de revenir en arrière. - Création des répertoires et sauvegarde de /etc/*
mkdir -p /upgrade57/backup && cd /upgrade57/backup tar czvf etc_svg_before_update.tar.gz /etc/
- Sauvegarde de la liste des paquets installés manuellement
pkg_info -m > packages.txt
2. Téléchargement des composants de la mise à jour OpenBSD
cd /upgrade57 ftp http://ftp.openbsd.org/pub/OpenBSD/5.7/ports.tar.gz ftp -ia http://ftp.fr.openbsd.org/pub/OpenBSD/5.7/amd64/{index.txt,man57.tgz,comp57.tgz,base57.tgz,bsd,bsd.mp,bsd.rd,INSTALL.amd64,SHA256,SHA256.sig}
- On note que l’ancien set etc.tgz , n’existe plus à partir de la 5.7 .
- En effet , il a été mergé avec base57.tgz.
Préparation pour le reboot, installation du noyau
mv /bsd /bsd.5.6 mv /bsd.rd /bsd.rd.5.6 mv /bsd.sp /bsd.sp.5.6 cp /upgrade57/bsd* /
- Application des nouveaux portages :
cd /usr tar xzf /upgrade57/ports.tar.gz
- Note: Lors du passage de la 5.6 à la 5.7 pour les carp, une attention
particulière doit être portée à la présence de la directive carpdev dans
leur fichiers de configuration respectifs /etc/hostname.carpX. Cette
directive avait un caractère optionnel jusqu’à la version 5.6. - Nous pouvons rebooter et utiliser notre nouveau noyau afin de procéder à
l’upgrade - à l’invite de command de boot, taper bsd.rd, le processus qui suit est
similaire à une installation.
[U] pour Upgrade [fr] choix du clavier [sd0] disque [sd0a] partition [disk] mode d'installation [yes] le disque est-il déjà monter [/upgrade57] chemin des sets [done] autre set disponible => non
- Ensuite nous pouvons relancer le serveur :
reboot
- Application de la configuration du set base57.tgz.
sysmerge
- pour une version inférieure à la 5.7,exemple avec la 5.6 nous utilisons
sysmerge -s /upgrade56/etc56.tgz
- le sysmerge montre les différences entre les fichiers de configuration
de la distribution avec ceux
actuellement utilisés. Dans notre cas, nous voulons garder
impérativement la configuraiton du pare-feu et
du démon ssh. - Répondre par [i] install le nouveau fichier issu du base57.tgz alors que
répondre [d], laisse le fichier actuel. - exemple :
/etc/newsyslog.conf [i] /etc/pf.conf [d] /etc/ssh/sshd_config [d]
- Mise à jour OpenBSD des paquets
PKG_PATH=http://ftp.spline.de/pub/OpenBSD/5.7/packages/amd64/ export PKG_PATH pkg_add -vui
- Les paquets se mettent à jour, il peut être nécessaire de relancer les
daemons après leur mise à jour. - Application des suppresions issues du patchnote
rm -f /etc/rc.d/named rm -f /usr/sbin/dnssec-keygen rm -f /usr/sbin/dnssec-signzone rm -f /usr/sbin/named rm -f /usr/sbin/named-checkconf rm -f /usr/sbin/named-checkzone rm -f /usr/sbin/nsupdate rm -f /usr/sbin/rndc rm -f /usr/sbin/rndc-confgen rm -f /usr/share/man/man5/named.conf.5 rm -f /usr/share/man/man5/rndc.conf.5 rm -f /usr/share/man/man8/dnssec-keygen.8 rm -f /usr/share/man/man8/dnssec-signzone.8 rm -f /usr/share/man/man8/named.8 rm -f /usr/share/man/man8/named-checkconf.8 rm -f /usr/share/man/man8/named-checkzone.8 rm -f /usr/share/man/man8/nsupdate.8 rm -f /usr/share/man/man8/rndc-confgen.8 rm -f /usr/share/man/man8/rndc.8
rm -f /usr/sbin/openssl rm -f /etc/rc.d/nginx rm -f /usr/sbin/nginx rm -f /usr/share/man/man8/nginx.8 rm -f /usr/share/man/man5/nginx.conf.5 rm -f /sbin/mount_procfs rm -f /usr/share/man/man8/mount_procfs.8 rm -rf /usr/include/libmilter rm -rf /usr/libdata/perl5/site_perl/`uname -p`-openbsd/libmilter rm -rf /usr/libexec/sendmail rm -rf /usr/share/sendmail
rm -f /etc/rc.d/sendmail rm -f /usr/lib/{libmilter.a,libmilter.so.3.0,libmilter_p.a} rm -f /usr/libexec/smrsh rm -f /usr/sbin/{editmap,mailstats,praliases} rm -f /usr/share/man/man1/{hoststat.1,praliases.1,purgestat.1} rm -f /usr/share/man/man8/{editmap.8,mailq.8,mailstats.8,smrsh.8} rm -f /var/log/sendmail.st rmdir /usr/libexec/sm.bin rm -rf /usr/lkm /usr/share/lkm /dev/lkm rm -f /usr/bin/modstat rm -f /sbin/mod{,un}load rm -f /usr/share/man/man8/mod{stat,load,unload}.8 rm -f /usr/share/man/man4/lkm.4 rm -f /usr/share/mk/bsd.lkm.mk /usr/include/sys/lkm.h
rm -f /usr/include/ressl.h rm -f /usr/lib/libressl.* /usr/lib/libressl_* rm -f /usr/share/man/man3/ressl_* rm /usr/mdec/installboot /usr/share/man/man8/sparc64/installboot.8 rm /etc/rc.d/rtsold /sbin/rtsol /usr/sbin/rtsold rm /usr/share/man/man8/rtsol.8 /usr/share/man/man8/rtsold.8 rm -f /usr/X11R6/include/GL/glcorearb.h rm -f /usr/X11R6/include/EGL/eglextchromium.h
rm -r /var/tmp ln -s /tmp /var/tmp
groupdel _lkm userdel smmsp groupdel smmsp
- Bascule des cartes CARP
- Afin de promouvoir l’actuel slave en master afin de le mettre à jour, il
faut utiliser la commande suivante sur le master afin de le dépromote.
En effet plus le nombre est grand moins la tendance sera à l’élection en maître du serveur visé.
ifconfig -g carp -carpdemote 120
- En supposant que les cartes carp soit toutes dans le groupe carp, un
ifconfig vous donnera les informations nécessaires, ainsi que les états
backup ou master des carp.
Ainsi, nous voyons bien que le processus de montée en version OpenBSD n’est pas similaire à ce que l’on connaît sous Linux. C’est une autre façon de faire. Vu l’aspect critique du service, nous vous conseillons fortement d’avoir une plateforme de pré-production similaire à la production pour tester le processus d’upgrade et voir les impacts sur les services fonctionnant sur les systèmes.
Syloé peut vous apporter son expertise dans ce domaine, dans le cadre d’intervention en assistance ou en installation et infogérance de vos Firewall sous OpenBSD.