FreeBSD peut paraître plus complexe à gérer qu'un système d'exploitation basé sur des paquetages, mais en suivant quelques règles simples, cela s'avère assez simple en réalité, et pas forcément très consommateur en temps.

Les Ports FreeBSD permettent de compiler et installer assez simplement des logiciels en tenant compte des dépendances, tout en offrant à l'administrateur la possibilité d'en personnaliser les options.

Mais une fois la machine installée et mise en production les problèmes commencent : comment s'assurer que sa machine est bien à jour pour éviter qu'elle ne soit compromise ?

Suivez le guide.


Boîte à outils de l'administrateur FreeBSD

Il manque dans l'installation par défaut plusieurs utilitaires essentiels pour tout administrateur FreeBSD.

Portaudit vérifie qu'il n'y a pas de vulnérabilité connue dans les logiciels installées via les ports ou paquetages binaires en comparant les versions par rapport à une base de données de vulnérabilités. Il ajoute également un script dans /usr/local/etc/periodic/security/410.portaudit pour générer une entrée dans le rapport security émis par email chaque jour.

En clair, vous allez pouvoir voir grâce à ce rapport en un clin d'oeil si vous avez des ports vulnérables, à mettre à jour ou désinstaller si vous n'en avez plus besoin.

En supposant que vous avez de ports à mettre à jour, vous allez avoir recours à Portupdate.

Portupgrade se compose d'un ensemble de commandes, dont la plus utile est portupgrade. Elle permet de mettre à jour simplement un ou plusieurs ports, les dépendances, ainsi de suite.

Quelques exemples d'usage :



Je vous invite à lire la manpage pour toutes les options.


Abonnez-vous aux listes de sécurité

Les Advisories FreeBSD ont comme but d'informer les utilisateurs de failles connues dans le système de base (userland + kernel). Elles indiquent la nature technique de la faille, les conséquences et la manière de résolution.

Plusieurs cas se présentent :

• La faille est dans le kernel
  Il convient alors de recompiler le kernel ou d'installer un kernel binaire patché et de redémarrer
  
• La faille est dans le userland
  Il est possible de mettre à jour la partie impactée, sans redémarrer. Des instructions détaillées sont dans l'Advisory.
  
• L'utilisateur n'est pas concerné par la faille
  Par exemple une faille dans la stack IPv6, sur un serveur sans connectivité IPv6.

Il est possible de recevoir les Advisories par email, plus d'informations sur le site de securité FreeBSD.


Utilisez freebsd-update

Si vous avez du temps et peu de machines, il est tout à faire concevable d'utiliser la méthode classique pour mettre à jour le système, en buildant à partir des sources kernel et userland. Cette méthode présente l'avantage de pouvoir personnaliser les options de compilation GCC pour gagner un peu de performances, et permet de mettre à jour alors que la version binaire n'est pas encore disponible.

Si vous disposez d'un grand nombre de machines, je conseille d'utiliser la méthode freebsd-update. Elle a l'avantage d'être simple, rapide et très prévisible. Pour la démarche précise, je vous invite à lire le handbook qui explique tout en détail.


If it ain't broken, don't fix it

L'idée ici est d'éviter de mettre à jour des ports s'il n'y a pas de raison valable pour le faire. Il existe bien sûr des motivations valables pour mettre à jour un port, dont :

• Vulnérabilité connue (et identifiée par Portaudit, par exemple)
  
• Bug de fonctionnement, réparé dans une version antérieure
  
• Version trop ancienne par rapport à un logiciel tiers donné

Cependant, mettre à jour juste par plaisir d'avoir la dernière version peut entraîner l'indisponibilité du serveur, notamment si la mise à jour est majeure. Je déconseille donc de gérer les mises à jour de cette manière.


Le cas de PHP

Sur FreeBSD je conseille de compiler PHP à la main à part pour simplifier les mises à jour. En effet, le port PHP est bien trop modulaire à mon sens (chaque option est compilée comme extension), rendant les mises à jour monstrueusement longues (décompression de l'archive de sources à chaque compilation d'extension) et hasardeuses (il lui arrive d'inverser d'ordre des extensions dans extensions.ini). De plus, PHP a déjà livré des versions défectueuses par le passé ; il est donc souhaitable de pouvoir faire machine arrière en cas de bug bloquant.

Rendez-vous dans mon dossier hébergement Web haute performance pour plus d'informations.


Et si j'ai plein de serveurs à mettre à jour ?

Si vous avez un parc important de serveurs ayant des rôles similaires, sur du hardware très similaire ou identique (notamment le processeur), et des versions de système d'exploitation identiques, il souhaitable de disposer d'un serveur de build et de test.

Voici la démarche :

• Vous installez tous les logiciels nécessaires sur le serveur de build
  
• Vous testez les différents applicatifs
  
• Vous créez un tarball de /usr/local en excluant /usr/local/etc
  
• Vous déployez ce tarball sur les différents serveurs

Vous appliquez ensuite les mises à jour sur le serveur de build, et vous recommencez le processus.

Je vous conseille de créer des scripts pour automatiser le redémarrage des différents services.


Historique

20100805 - version initiale.
20100806 - paragraphe freebsd-update.