244 lines
13 KiB
Text
244 lines
13 KiB
Text
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY enbase "../&base;">
|
|
<!ENTITY date "$FreeBSD: www/fr/projects/updater.sgml,v 1.3 2004/01/08 00:26:46 stephane Exp $">
|
|
<!ENTITY title "Projet de Mise à jour Binaire pour FreeBSD (binup)">
|
|
<!ENTITY email 'freebsd-binup'>
|
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
|
|
|
<!ENTITY done "<font color='green'>Fait</font>">
|
|
<!ENTITY inprogress "<font color='blue'>En progrès</font>">
|
|
<!ENTITY notstarted "<font color='red'>Pas encore commencé</font>">
|
|
]>
|
|
|
|
<!--
|
|
The FreeBSD French Documentation Project
|
|
Original revision: 1.8
|
|
|
|
Version francaise : Stephane Legrand <stephane@freebsd-fr.org>
|
|
-->
|
|
|
|
<html>
|
|
&header;
|
|
|
|
<h2>Contenu</h2>
|
|
<ul>
|
|
<li><a href="#goals">Objectifs</a></li>
|
|
<li><a href="#design">Conception</a></li>
|
|
<li><a href="#implementation">Implémentation</a></li>
|
|
<li><a href="#code">Code</a></li>
|
|
</ul>
|
|
|
|
<a name="goals"></a>
|
|
<h2>Objectifs</h2>
|
|
|
|
<p>Le projet de mise à jour binaire pour FreeBSD a pour objectif de fournir un mécanisme
|
|
sécurisé pour la distribution des mises à jour binaires sous FreeBSD.
|
|
Ce projet est complémentaire aux projets <a
|
|
href="http://www.openpackages.org">Open Packages</a> et
|
|
<a href="libh.html">libh</a> et n'empiète pas sur ceux-ci.</p>
|
|
|
|
<p>Ce système est un mécanisme client/serveur qui permet aux clients
|
|
d'installer n'importe quel "profil" ou version de FreeBSD via le
|
|
réseau. Un profil peut contenir un ensemble spécifique de
|
|
logiciels FreeBSD à installer, des paquetages additionnels et
|
|
des actions de configuration de manière à l'adapter au mieux
|
|
à un environnement donné (ie un profil de serveur web sécurisé sous FreeBSD 4.3)</p>
|
|
|
|
<p>Notre implémentation a pour but de faire abstraction de l'ontologie actuelle
|
|
des collections de logiciels FreeBSD de manière à pouvoir intégrer au mieux
|
|
les futurs développements visant à une plus grande modularité du système
|
|
de base.</p>
|
|
|
|
<a name="design"></a>
|
|
<h2>Conception</h2>
|
|
|
|
<h3>Les "profils"</h3>
|
|
|
|
<p>Ce que l'utilisateur voit en tant "qu'objets de plus haut niveau" dans le système de mise à jour
|
|
sont des profils. Un profil peut représenter un système de configuration
|
|
utilisateur donné ou un modèle générique (serveur web,
|
|
serveur de mail, etc) fourni par nous.</p>
|
|
|
|
<p>Chaque profil consiste en des fichiers et/ou des collections.
|
|
Une collection représente un ensemble de fichiers tel qu'un
|
|
paquetage ou comme ce que le programme sysinstall appelle une "distribution".
|
|
Les profils existent sur le serveur mais le client peut aussi
|
|
choisir de mettre des copies en cache de manière à utiliser des services à la "tripwire".
|
|
Des profils typiques pourraient ressembler à cela :</p>
|
|
|
|
<pre>
|
|
[mysystem] [web-server]
|
|
bin 4.2 bin 4.2
|
|
bash 2.02 manpages 4.2
|
|
src 4.2 apache 2.1
|
|
xblaster 1.0
|
|
</pre>
|
|
|
|
<p>Une collection peut également avoir un numéro de version spécifique associé
|
|
ou bien un numéro de version "flottant" ce qui signifie que la collection
|
|
utiliserait la plus récente version supérieure au numéro indiqué.</p>
|
|
|
|
<p>Identification</p>
|
|
|
|
<p>Les utilisateurs s'identifieront sur le serveur via un nom d'utilisateur
|
|
et un mot de passe ce qui leur permettra d'accéder à leurs profils
|
|
personnalisés ainsi qu'aux profils systèmes.</p>
|
|
|
|
<p>Les paquetages binaires du serveur sont signés avec une clef
|
|
publique.</p>
|
|
|
|
<h3>Logiciel client de mise à jour</h3>
|
|
|
|
<p>Le client supporte la connexion à un serveur de mise à jour,
|
|
l'identification d'un utilisateur, la consultation des profils existants ou la création
|
|
des nouveaux profils ainsi que le téléchargement des fichiers de données et "d'actions"
|
|
à partir du serveur. Les nouveaux fichiers de données seront créés de telle façon
|
|
que les mises à jour partielles ne provoqueront pas de corruption de données et les transactions
|
|
sont délivrées avec une atomicité raisonnable.</p>
|
|
|
|
<p>Le client sera implémenté en 3 étapes :</p>
|
|
|
|
<ul>
|
|
<li>Un ensemble de librairies qui implémentent le plus gros des
|
|
fonctions client <-> serveur.</li>
|
|
|
|
<li>Une version en ligne de commande du client qui supporte toutes
|
|
les fonctions disponibles dans la librairie.</li>
|
|
|
|
<li>Une version avec interface graphique du client qui utilise soit le
|
|
client version ligne de commande soit directement les routines de la librairie
|
|
selon ce qui est le plus adapté.</li>
|
|
</ul>
|
|
|
|
<p>Etant donné qu'un système peut aussi être "mis à jour" à partir d'une première installation, la
|
|
prochaine génération de logiciel d'installation pourrait prendre en charge
|
|
le formatage du système de fichier ainsi que la configuration réseau puis utiliser
|
|
la librairie cliente pour proposer un menu permettant de faire une sélection parmi les
|
|
logiciels disponibles et réaliser l'installation.</p>
|
|
|
|
<h3>Logiciel serveur de mise à jour</h3>
|
|
|
|
<p>Le serveur supporte les connexions par un nombre arbitraire de clients
|
|
et l'authentification des utilisateurs (ou d'un utilisateur "anonyme" si le serveur est
|
|
configuré pour supporter les connexions anonymes) afin de déterminer les
|
|
profils disponibles.</p>
|
|
|
|
<p>Une fois que le serveur reçoit une demande (e.g. un jeu de collections)
|
|
de la part d'un client et un nom de profil côté serveur pour faire la
|
|
correspondance, il fait une recherche sur chaque collection pour voir si une version
|
|
plus récente de cette collection existe sur le serveur ou s'il existe une
|
|
modification en attente concernant la collection qui serait
|
|
supérieure à la version de patch de la collection présente dans
|
|
la demande du client.</p>
|
|
|
|
<p>Les différences et/ou les collections entières sont envoyées au client pour
|
|
être décompactées en même temps que toutes les pré/post-actions pour chaque différence ou
|
|
collection qui doivent être exécutées sur le client. Une fois que le
|
|
client a confirmé que toutes les pré/post-actions et le
|
|
décompactage de la collection concernée ont été exécutés avec succès, il
|
|
met à jour le profil stocké et passe à la suivante. Si le
|
|
transfert est interrompu en cours de route, le processus peut donc
|
|
reprendre d'où il s'est arrêté.</p>
|
|
|
|
<p>Le serveur de mise à jour fournit un espace de stockage local pour un certain nombre
|
|
de données sur les profils suivant des contraintes d'espace disque et peut également
|
|
être utilisé comme moyen de cloner des machines. L'utilisateur installe une seule
|
|
machine entièrement adaptée à ses besoins puis télécharge son profil sur le
|
|
serveur. Chaque machine suivante est installée à partir de ce profil
|
|
et voilà, une armée de clones.</p>
|
|
|
|
<p>Le serveur ne conservera probablement pas les données concernant uniquement le côté client
|
|
tel que <tt>/etc/master.passwd</tt> ou plus largement tout ce qui est
|
|
en dehors de ces propres collections. Mais nous pouvons laisser cette décision
|
|
ouverte pour plus tard ou le proposer en tant qu'option de configuration.</p>
|
|
|
|
<a name="implementation"></a>
|
|
<h2>Détails sur l'implémentation</h2>
|
|
|
|
<a name="update-server"></a>
|
|
<h3>Serveur de mise à jour</h3>
|
|
|
|
<p>Le serveur de mise à jour est en grande partie fonctionnel.
|
|
Les informations à propos des profils, des collections et des actions sont stockées
|
|
dans une base de données SQL. Une couche d'abstraction se charge d'appeler
|
|
les fonctions correspondantes (MySQL et PostgreSQL sont supportés pour le moment) afin de
|
|
répondre aux requêtes des clients. L'utilisation d'une base de données relationnelles nous
|
|
a permis de modifier très facilement l'organisation des données
|
|
sans perdre du temps à réécrire du code. Comme nos structures de données
|
|
sont quasiment finalisées, il pourrait être plus efficace d'utiliser BerkeleyDB ou
|
|
une autre solution mais, pour l'instant, l'utilisation du SQL nous a permis de gagner
|
|
beaucoup de temps de développement.</p>
|
|
|
|
<p>Le serveur peut être utilisé pour installer ou mettre à jour un
|
|
système FreeBSD 4.X mais il reste beaucoup de finitions à faire
|
|
et de nombreuses fonctionnalités manquantes sont encore nécessaires.</p>
|
|
|
|
<a name="update-server-todo"></a>
|
|
<p>Liste des choses à faire pour le serveur :</p>
|
|
|
|
<ul>
|
|
<li>Ajouter la possibilité de gérer les paquetages tel qu'ils sont actuellement définis
|
|
et utilisés dans FreeBSD</li>
|
|
|
|
<li>Ajouter un mécanisme pour lire l'ontologie (N.d.T. : sic !) de l'arbre des sources FreeBSD
|
|
à partir d'un fichier XML au lieu de le coder en dur dans un script
|
|
Perl qui se charge de générer les tables SQL nécessaires. Cela
|
|
permettra beaucoup plus de flexibilité dans la création des
|
|
profils et des composants logiciels. Il devrait aussi fournir une
|
|
description pour des paquetages qui pourraient prendre le pas sur des sous-ensembles de ce que
|
|
sysinstall appelle actuellement le "système de base" (par exemple, un profil
|
|
avec Postfix au lieu de Sendmail et toutes les dépendances de configuration
|
|
qui vont avec).</li>
|
|
|
|
<li>Ajouter une information "somme de contrôle" ("checksum") et offrir un service à la
|
|
"tripwire" aux clients.</li>
|
|
</ul>
|
|
|
|
<a name="update-client"></a>
|
|
<h3>Client de mise à jour</h3>
|
|
|
|
<p>Le client de mise à jour n'est pour le moment pas utilisable. Actuellement, il
|
|
existe du code pour réaliser concrètement les mises à jour ainsi que pour
|
|
tester les diverses fonctions de mise à jour. Par ailleurs,
|
|
le client ne gère pas encore les paquetages. Une fois que
|
|
cette fonction aura été ajoutée, et que les bugs auront été
|
|
corrigés, le code existant devra être converti en
|
|
librairie.</p>
|
|
|
|
<p>A partir de là, il sera aisément possible de créer un installeur ainsi
|
|
qu'un programme utilisateur de mise à jour en version texte,
|
|
X11 et peut-être même en version GNOME et KDE.</p>
|
|
|
|
<a name="update-client-todo"></a>
|
|
<p>Liste des choses à faire pour le client :</p>
|
|
|
|
<ul>
|
|
<li>ajouter les informations concernant le copyright/la licence pour tous
|
|
les fichiers sources</li>
|
|
<li>se mettre en conformité avec style(9)</li>
|
|
<li>corriger les bugs les plus critiques</li>
|
|
<li>ajouter la fonction de gestion des paquetages</li>
|
|
<li>faire la conversion en librairie</li>
|
|
</ul>
|
|
|
|
<a name="code"></a>
|
|
<h2>Où est le code ?</h2>
|
|
|
|
<p>Ce projet est actuellement développé au sein du dépôt CVS principal
|
|
de FreeBSD. Les sources sont disponibles dans <tt>projects/binup</tt>.
|
|
Vous pouvez utiliser les méthodes habituelles pour récupérer les sources FreeBSD
|
|
afin d'y accéder. <b>NOTE :</b> les utilisateurs de cvsup doivent utiliser la
|
|
collection <tt>projects-all</tt> pour accéder à la hiérarchie <tt>projects/</tt></p>
|
|
|
|
<p>Une liste de diffusion a été mise en place pour ce projet. Vous pouvez poster
|
|
vos questions, patches, etc sur la liste de diffusion <a
|
|
href="mailto:freebsd-binup@FreeBSD.org">freebsd-binup@FreeBSD.org</a>
|
|
Pour savoir comment s'abonner à cette liste, veuillez consulter le <a
|
|
href="&enbase;/doc/&url.doc.langcode;/books/handbook/eresources.html#ERESOURCES-MAIL">Manuel de
|
|
Référence FreeBSD</a></p>
|
|
|
|
&footer;
|
|
</body>
|
|
</html>
|
|
|