Début
La popularité des solutions UTM modernes est principalement associée à leur multifonctionnalité. La capacité de résoudre rapidement toutes les tâches informatiques d'une entreprise, et même à partir d'une seule interface Web, attire de nombreux administrateurs système.
Notre solution, Internet Control Server , appartient également à la classe des produits UTM, combinant les fonctions de protection réseau, de gestion de connexion Internet, de filtrage de contenu et bien d'autres.
Malgré les avantages évidents, l'utilisation de telles solutions présente un inconvénient: elles sont souvent monolithiques, ce qui ne permet pas de répondre aux évolutions du marché de manière plus flexible.
De ce point de vue, un produit plus intéressant est la passerelle UTM, qui peut être construite par l'utilisateur lui-même, en fonction des tâches réelles de l'entreprise.
Dans ce cas, l'administrateur système construit sa passerelle à partir des «blocs de construction» des composants, en installant uniquement les modules dont il a besoin. Tous les outils se trouvent dans le cloud du développeur et l'utilisateur télécharge et installe les packages requis. Ce principe est devenu fondamental pour nos développements futurs.
L'écosystème historique de FreeBSD était bien et bien compris. Nous avons choisi le programme d'installation de paquets FreeBSD traditionnel, pkg, comme la méthode la plus appropriée pour distribuer des paquets. Un référentiel est collecté dans notre cloud et l'accès à celui-ci est prescrit sur le client dans la configuration traditionnelle de pkg.
Qu'avons-nous prévu de faire
Le système doit être un constructeur sous la forme d'un noyau sur lequel les composants sont enfilés. L'utilisateur reçoit un kit de distribution qui ne comprend que les plugins minimum requis (routeur, fierwall, etc.). Le reste est installé selon les besoins.
Pour que le système fonctionne, nous devions implémenter les composants suivants:
- système - noyau FreeBSD modifié
- core - un package spécial avec les paramètres du produit, qui est la dépendance parente pour tous les plugins
- plugins - chacun d'eux est un package compilé qui est installé de manière régulière à l'aide de l'utilitaire pkg
Structure du plugin
Comme indiqué, un plugin est un package régulier. Il peut être installé avec l'utilitaire pkg.
Afin de maintenir la compatibilité descendante, il a été décidé que la nouvelle version majeure du plugin serait un package séparé, non lié à la version majeure précédente. Par exemple plugin-v1 et plugin-v2 . La raison en est qu'ils peuvent avoir des dépendances complètement différentes, voire se contredire.
La version mineure change simplement le numéro de version du package, tout est comme d'habitude ici.
Travailler avec des plugins
Pour que le système fonctionne comme nous en avons besoin, un utilitaire complémentaire a été créé au-dessus de pkg.
Les principaux outils de travail seront les commandes pkg query et pkg rquery .
Le premier recueille des informations sur les plugins installés dans le système, le second accède au référentiel.
Afin que l'utilitaire contrôle l'exécution correcte des commandes dans le système, l'exécution de chaque commande est vérifiée pour un code de retour. Si un code retour de 0 est reçu, la commande a été exécutée, si autre chose, une erreur s'est produite. Ainsi, vous pouvez suivre, par exemple, les problèmes de connexion réseau.
Une nuance intéressante est apparue ici. Par exemple
, si vous recherchez tous les packages par modèle: si aucun package installé ne correspond à la condition de modèle, l'erreur 69 est renvoyée sans message d'erreur. Les développeurs de l'utilitaire ont considéré que si la recherche ne retournait rien, il s'agissait d'un comportement anormal. Bon, d'accord. J'ai dû gérer un tel cas d'une manière spéciale.
Problèmes de mise à jour
Ensuite, les problèmes de versioning commencent lors de la mise à jour des plugins.
Premièrement, l'utilitaire pkg, lors de l'exécution de la commande pkg upgrade <pkg_name>, met également à jour TOUTES les dépendances directes du package, ce comportement est conçu par les développeurs. Mais dans notre cas, cela inclut la mise à jour et le noyau, si une version mineure a été publiée pour cela, ce qui n'est pas souhaitable, car le noyau modifie les paramètres système et nécessite également un redémarrage du système après la mise à jour.
Autrement dit, si nous avons déjà installé SP2 - pkg-1 et pkg-2 , et en fonction de pkg-1 Set pkg-2 , si nous exécutons la commande pkg upgrade pkg-1 , puis pkg-2 est également mis à jour .
Allons dans l'autre sens.
Construisons l'arborescence des dépendances des packages de haut en bas.
Trouvez les noms de tous les packages dont dépend notre package:
pkg rquery% rn <pkg_name>
Maintenant, tous les packages qui dépendent de notre package:
pkg rquery% dn <pkg_name> Supprimons
toutes les entités qui dépendent du package. Ensuite, nous commencerons à supprimer les entités dont dépend notre package jusqu'à ce que nous nous retrouvions dans le noyau (nous ne le supprimerons pas bien sûr). Vous pouvez maintenant restaurer l'arborescence en installant les dernières versions mineures de tous les packages qu'elle contient.
Par exemple, dans l'image ci-dessus, nous pouvons voir que le paquet ics-plugin-a-v1 dépend du plugin ics-plugin-b-v1 . Si nous devons mettre à jour le paquet vers la version ics-plugin-v2 , cela impliquera également la mise à jour du paquet ics-plugin-b-v1 , pour lequel il existe 2 versions majeures - ics-plugin-b-v2 et ics-plugin -b-v3 . Cependant, aucun d'entre eux ne prend en charge le plugin ics-plugin-c-v1 . Autrement dit, la mise à jour installera d'abord le package ics-plugin-b-v2 ou -v3 , puis ics-plugin-a-v1et ics-plugin-c sera désinstallé et non installé.
De plus, le noyau peut avoir une version majeure, auquel cas l'ensemble des plugins doit être mis à jour pour correspondre.
Pour installer le package ics-plugin-a , qui dépend de ics-core-v2, vous devez mettre à jour ics-core, après quoi seuls les principaux packages qui dépendent de ics-core-v2 seront installés .
Sauvegarde de la base de données
Lorsque vous travaillez avec le référentiel, une situation est possible lorsque, pendant la mise à jour, la connexion sera perdue (le code d'erreur système 70 ou 3 se produit). De plus, pour désinstaller correctement le plugin, le système a besoin d'une base pkg valide sur le système. Lors de l'exécution de la commande pkg update , s'il n'y a pas de connexion, la base signale une erreur et même localement n'effectue pas ses fonctions tant que la mise à jour n'est pas terminée correctement.
Pour éviter de telles situations, nous utiliserons l'utilitaire de sauvegarde pkg . Avant toute opération, pendant laquelle il est possible de ne pas obtenir le résultat souhaité, enregistrez la base de données:
pkg backup -d <backup_dir>
Si l'opération ne s'est pas terminée correctement, remettez la base de données à sa place:
pkg backup -r <backup_dir>
Coeur
Jusqu'à présent, tout est assez simple. S'il y a une mise à jour pour le noyau, alors:
- télécharger la nouvelle image du noyau dans l'archive
- créer un nouvel ensemble de données dans zfs
- monter l'ensemble de données dans le système
- décompresser l'image
- installer un package spécial avec les options de noyau nécessaires pour un fonctionnement normal
- enregistrer la nouvelle image comme amorçable
- ???
Profit?
Pas encore.
Nous devons restaurer les plugins système installés précédemment par l'utilisateur (s'ils sont pris en charge par le nouveau noyau, bien sûr). En conséquence, vous devez créer un référentiel de plugins distinct pour chaque version du noyau.
Mais (comme toujours) il y a une nuance.
Nous n'avons pas encore installé le noyau de la future version, et nous ne pouvons pas installer le plugin pour une autre version. Si nous démarrons le système à partir d'une nouvelle image, nous ne pourrons pas accéder au référentiel (pour des raisons historiques et techniques, le routage est également un plugin).
Que faire?
Nous élevons le serveur avec api, qui servira l'archive avec le référentiel de plugins pour la version de noyau spécifiée.
Ensuite, notre utilitaire générera un fichier de configuration du référentiel avec le chemin vers le dossier avec l'archive décompressée.
Pour FreeBSD, ce sera le fichier <repo_name> .conf dans / usr / local / etc / repos ou / etc / repos . Il est à noter ici que le chemin est écrit comme suit: url: “file: /// path_to_repo” ( 3 barres obliques! )
Sauvegardez les données sur les plugins installés et vérifiez leur compatibilité avec la future version du noyau (s'il y en a des incompatibles , nous en informerons l'utilisateur).
Vous pouvez maintenant redémarrer.
Dernière chose
Pkg nécessite une initialisation (bootstrap) après la mise à niveau du système. Par conséquent, si vous exécutez une commande, vous serez invité à la saisir. Dans notre cas, l'utilitaire de liaison ne comprendra pas qu'il le souhaite et considérera que l'opération n'a pas été effectuée correctement.
Pour ce faire, nous avons créé un gestionnaire d'erreurs d'initialisation, heureusement, il a un code d'opération système séparé 1. Par conséquent, si l'utilitaire rencontre un tel code, il exécute simplement
pkg -y
Pkg fait un bootstrap, et vous pouvez alors travailler normalement.
Total
C'est ainsi que nous avons construit notre référentiel. Bien qu'il s'agisse d'un prototype, et à l'avenir, il changera probablement et deviendra plus complexe, mais la base de conception a été posée et restera inchangée.
La technologie décrite sera appliquée dans les nouveaux développements d'Internet Control Server, ce qui le rendra encore plus pratique pour une utilisation dans les réseaux d'entreprise des entreprises. Vous pouvez télécharger et tester la version la plus récente de l'ICS sur le lien .
Période d'essai, version gratuite pour 9 utilisateurs, démo en ligne et support technique réactif.
Suivez l'actualité et restez avec nous!