| [Dev OpenGP] [103] Report... |
[ Thread Index |
Date Index
| More opengp.tuxfamily.org/development Archives
]
Revision: 103
Author: alband85
Date: 2009-03-26 15:50:37 +0100 (Thu, 26 Mar 2009)
Log Message:
-----------
Report... let's go on!
Modified Paths:
--------------
externals/Com/Rapport/tex/rapport.tex
Modified: externals/Com/Rapport/tex/rapport.tex
===================================================================
--- externals/Com/Rapport/tex/rapport.tex 2009-03-26 13:31:19 UTC (rev 102)
+++ externals/Com/Rapport/tex/rapport.tex 2009-03-26 14:50:37 UTC (rev 103)
@@ -263,32 +263,42 @@
\begin{figure}
\centering
+ %TODO:SUPPRIMER ?
\includegraphics[width=.7\textwidth]{../figures/arch/globalFunc}
\caption{Fonctionnement global}
\end{figure}
\section{Authentification}
-%TODO: authentification
-\section{Annuaire}
-%TODO: annuaire
+Plusieurs méthodes d'authentification sont envisageables avec un niveau de sécurité plus ou moins élevé.
+\begin{itemize}
+ \item Une authentification de type \og{}login / mot de passe\fg{} (en associant un mot de passe à un nom distingué) présente l'avantage d'être le plus simple à mettre en place (presque aucune configuration nécessaire) mais propose un niveau de sécurité très faible.
+ \item Une authentification de type TLS assure une meilleure sécurité mais sa mise en \oe uvre est plus délicate. En effet la mise en place d'une autorité de certification associée à LDAP n'est pas triviale. Cette technique impose en outre de déployer des certificats sur toutes les machines.
+ %TODO: autre ?
+\end{itemize}
+
\section{Client}
-%TODO: client / démon
+%TODO: [MICHEL]-client / démon : pourquoi il est là, comment on le conçoit (PAS comment il est implémenté)
\chapter{Annuaire}
\section{Existant}
On souhaite autant que possible conserver la compatibilité avec le monde Windows. Pour celà, on base le schéma d'annuaire sur le schéma \emph{Active Directory}. On retiendra notamment les classes d'objets \texttt{OrganizationalUnit} et \texttt{Computer}.
-%TODO: à finir
+
\section{Ajouts}
-%TODO: annuaire -> ajouts
+Dans une optique de compatibilité, la modification des classes d'objets déjà existantes n'est pas envisageable. Deux classes d'objets ont donc été définies et héritent des classes définies dans \emph{Active Directory}.
\chapter{Gestion de la configuration}
L'objectif est de représenter la configuration de manière homogène au niveau de l'annuaire et de la conserver sous cette forme \og{}le plus longtemps possible\fg{}. On se propose donc de gérer celle-ci au format XML et de ne la convertir au format natif que lorsque cela est nécessaire (au moment de l'écriture du fichier de configuration sur machine).
\section{Structuration de la configuration : schéma XML}
-%TODO: schéma XML -> Michel
+%TODO: [MICHEL]-schéma XML
\section{Manipulation de la configuration}
-%TODO: introduction de la section
+Deux cas sont à distinguer dans le cadre de la manipulation de la configuration :
+\begin{itemize}
+ \item la conversion d'un fichier (ou d'un fragment de fichier) d'une machine vers le format \og{}OGP\fg{} (XML) dans l'annuaire ;
+ \item la conversion de la configuration stockée dans l'annuaire en fichier de configuration natif.
+\end{itemize}
+Si ces deux mécanismes manipulent les mêmes objets, il sont néanmoins indépendants l'un de l'autre et peuvent (doivent ?) être conçus avec des approches différentes.
\subsection{Fusion d'arbres XML}
@@ -341,13 +351,18 @@
Calcul de $\xmlunion{B_1}{B_2}$ :\\
On note :
\begin{itemize}
- \item $B_1^*$ l'ensemble des balises de $B_1$ qui n'ont pas d'équivalent dans $B_2$. \\
- $B_1^*=\left\lbrace\left( n_1,A_1,B,t\right)\in B_1\left|\not\exists\left( n_2,A_2,B',t'\right)\in B_2\left|n_2=n\wedge A_2=A\right.\right.\right\rbrace$
- \item $b_1^*\left(n,A\right)$ l'ensemble des balises de $B_1$ de nom $n$ et d'attributs $A$ ayant un équivalent dans $B_2$.
+ \item $B_1^*$ l'ensemble des balises de $B_1$ qui n'ont pas d'équivalent dans $B_2$ ;
\[
- b_1^*\left( n,A\right)=\left\lbrace\left( n_1,A_1,B,t\right)\in B_1\left|n_1=n \wedge A_1=A \wedge \exists\left( n_2,A_2,B',t'\right)\in B_2\left|n_2=n\wedge A_2=A\right.\right.\right\rbrace
+ B_1^*=\left\lbrace\left( n_1,A_1,B,t\right)\in B_1\left|\not\exists\left( n_2,A_2,B',t'\right)\in B_2\left|n_2=n\wedge A_2=A\right.\right.\right\rbrace
\]
- \item $B_2^*$ l'ensemble des balises de $B_2$ qui n'ont pas d'équivalent dans $B_1$.
+ \item $b_1^*\left(n,A\right)$ l'ensemble des balises de $B_1$ de nom $n$ et d'attributs $A$ ayant un équivalent dans $B_2$ ;
+ \begin{multline*}
+ b_1^*\left( n,A\right)= \bigg\lbrace\left( n_1,A_1,B,t\right)\in B_1\big|
+ n_1=n \wedge
+ A_1=A \wedge \\
+ \exists\left( n_2,A_2,B',t'\right)\in B_2\big|n_2=n\wedge A_2=A\bigg\rbrace
+ \end{multline*}
+ \item $B_2^*$ l'ensemble des balises de $B_2$ qui n'ont pas d'équivalent dans $B_1$ ;
\item $b_2^*\left(n,A\right)$ l'ensemble des balises de $B_2$ de nom $n$ et d'attributs $A$ ayant un équivalent dans $B_1$.
\end{itemize}
@@ -357,7 +372,11 @@
\]
\end{theorem}
\begin{proof}
- D'après l'hypothèse \ref{hyp:notwins}, $\forall \left(n,A,i\right), \mathrm{card}\left\lbrace\left( n',A',B,t\right)\in B_i\left|n'=n\wedge A'=A\right.\right\rbrace\in\left\lbrace 0, 1\right\rbrace$, or $b_i^*\left(n,A\right)$ est inclus dans cet ensemble.
+ D'après l'hypothèse \ref{hyp:notwins} :
+ \[
+ \forall \left(n,A,i\right), \mathrm{card}\left\lbrace\left( n',A',B,t\right)\in B_i\left|n'=n\wedge A'=A\right.\right\rbrace\in\left\lbrace 0, 1\right\rbrace,
+ \]
+ or $b_i^*\left(n,A\right)$ est inclus dans cet ensemble.
\end{proof}
Ainsi :
\begin{definition}
@@ -368,7 +387,7 @@
\end{definition}
\subsubsection{Algorithme}
-L'algorithme \ref{algorithm:XMLMerge} (page \pageref{algorithm:XMLMerge}) présente la mise en \oe uvre de cette méthode. La réorganisation des \texttt{id} est décrite par l'algorithme \ref{algorithm:reorgid} (page \pageref{algorithm:reorgid}).
+L'algorithme \ref{algorithm:XMLMerge} (page \pageref{algorithm:XMLMerge}) présente la mise en \oe uvre de cette méthode. La réorg\-anisation des \texttt{id} est décrite par l'algorithme \ref{algorithm:reorgid} (page \pageref{algorithm:reorgid}).
\begin{algorithm}[hb!]
\caption{Fusion de deux arbres XML}
@@ -444,11 +463,10 @@
\subsection{Génération de fragments XML}
-On s'intéresse ici à la conversion d'un fichier de configuration ou d'un fragment de fichier de configuration vers un format XML.
-%TODO: génération de fragments XML
+On s'intéresse ici à la conversion d'un fichier de configuration ou d'un fragment de fichier de configuration vers un format XML. Les formats de fichiers de configuration étant relativement hétérogènes, OGP ne propose pas d'outil par défaut dans ce sens : la liberté est laissée au développeur du plugin de faire suivant ses préférences.
+À titre indicatif, le projet \href{http://simpleparse.sourceforge.net}{\emph{SimpleParse}}\footnote{Voir \url{http://simpleparse.sourceforge.net}} semble souple et adapté à la plupart des besoins. Il est néanmoins possible d'utiliser d'autres API de \emph{parsing} ou d'en développer une nouvelle.
-
\part{Réalisation}
%TODO: réalisation (part)
@@ -529,10 +547,38 @@
\chapter{Déploiement}
-%TODO: Bibliothèques
+\section{Installation des dépendances}
+OGP se base sur des modules Python qui sont nécessaires à son exécution :
+\begin{itemize}
+ \item \texttt{lxml.etree} (bibliothèque de manipulation de XML) ;
+ \item \texttt{ldap} (bibliothèque d'accès à LDAP) ;
+ \item \texttt{pkg\_resources} (chargement dynamique de \emph{packages}).
+\end{itemize}
+Ces modules font partie des bibliothèques standards mais ne sont pas fournis avec une installation de base.
+
+Sous \emph{Debian}, l'installation des paquets suivants permet de disposer de toutes les ressources nécessaires :
+\begin{itemize}
+ \item \texttt{python-lxml} ;
+ \item \texttt{python-ldap} ;
+ \item \texttt{python-pkg-resources}.
+\end{itemize}
+Le paquet \texttt{python-minimal} suffit à fournir les autres modules nécessaires.
+
+À titre indicatif, l'intégralité des modules utilisés est listée en annexe \ref{section:APIModulesNecessaires} (page \pageref{section:APIModulesNecessaires}).
+
+\section{Installation des bibliothèques OGP}
+Les bibliothèques sont stockée dans le dépôt telles qu'elles sont à utiliser dans leur environnement de production. Il \og{}suffit\fg{} donc de les copier en excluant les répertoires \url{.svn} s'ils existent.
+
+Par défaut, lors de l'exécution, l'interpréteur Python génère à la volée le \emph{byte-code} dans les fichiers \og{}pyc\fg{}. Néanmoins, si le répertoire n'est pas accesible en écriture, il lui sera impossible de les créer et l'exécution ne pourra pas se poursuivre. On stockera donc les fichiers \og{}py\fg{} (fichiers sources) et les fichiers \og{}pyc\fg{} (\emph{byte-code}).
+
+Cette procédure est automatisée par le fichier \emph{Makefile} :
+\begin{itemize}
+ \item \verb+make binaries+ génère le \emph{byte-code} ;
+ \item \verb+make install-libs+ copie les bibliothèques dans le \emph{path} Python (par défaut \url{/usr/lib/python2.5}).
+\end{itemize}
+
+\section{Installation du démon}
%TODO: Installation du démon
-%TODO: Droits ?
-% ...
\addcontentsline{toc}{chapter}{Table des figures}
\listoffigures
@@ -873,7 +919,7 @@
\paragraph{Paramètres}
\begin{itemize}
\item \texttt{dn} (str), nom distingué (\emph{distinguished name}) de l'entrée ;
- \item \texttt{attrs} %TODO ???
+ \item \texttt{attrs} %TODO [MICHEL]-???
\end{itemize}
\subsubsection{\_\_modify()}
@@ -882,7 +928,7 @@
\paragraph{Paramètres}
\begin{itemize}
\item \texttt{dn} (str), nom distingué (\emph{distinguished name}) de l'entrée ;
- \item \texttt{mods} %TODO ???
+ \item \texttt{mods} %TODO [MICHEL]-???
\end{itemize}
\subsubsection{\_\_delete()}
@@ -1255,9 +1301,25 @@
\item \texttt{s} (str ou int), chaîne à convertir en booléen.
\end{itemize}
-\chapter{Schéma d'annuaire}
+\section{Modules Python nécessaires à l'API}\label{section:APIModulesNecessaires}
+\begin{itemize}
+ \item base64
+ \item copy
+ \item hashlib
+ \item imp
+ \item ldap
+ \item logging
+ \item lxml.etree
+ \item os
+ \item pkg\_resources
+ \item stat
+ \item sys
+\end{itemize}
+\chapter{Schéma d'annuaire}\label{chapter:ANXschemaLDAP}
+
+
\section{Attributs}
\subsection{Syntaxe}
Pour mémoire, les syntaxes et leur OID sont détaillées dans le tableau ci-dessous.
@@ -1271,7 +1333,7 @@
Entier & Integer & 1.3.6.1.4.1.1466.115.121.1.27 \\\hline
\end{tabular}
\end{center}
-\subsection{Attributs propres à OGP}
+\subsection{Attributs propres à OGP}\label{subsection:ANXattributsLDAPOGP}
Les attributs suivants, spécifiques à OGP, ont été ajoutés au schéma \emph{Active Directory}.
\begin{center}
\begin{minipage}{.95\textwidth}
@@ -1289,7 +1351,7 @@
\end{minipage}
\end{center}
-\section{Classes d'objets}
+\section{Classes d'objets}\label{section:ANXobjectClassOGP}
Les classes d'objets suivants, spécifiques à OGP, ont été ajoutées au schéma \emph{Active Directory}.
\begin{center}
\begin{minipage}{.95\textwidth}
@@ -1297,9 +1359,9 @@
\captionof{table}{\caption{Classes d'objets LDAP spécifiques OGP}\label{tab:classLDAPOGP}}
\begin{tabular}{|l|p{15mm}|c|p{30mm}|}
\hline
- \textsc{Classe d'objet} & \textsc{Suffixe OID}\footnotemark & \textsc{Hérite de} & \textsc{Attributs propres} \\\hline\hline
- oGPOrganizationalUnit & .2.2 & organizationalUnit & description, oGPXMLConfig, oGPSOA \\\hline
- oGPComputer & .2.1 & computer & oGPXMLConfig, oGPMachineCertificate, description, oGPSOA \\\hline
+ \textsc{Classe d'objet} & \textsc{Suffixe OID}\footnotemark & \textsc{Hérite de} & \textsc{Attributs propres} \\ \hline\hline
+ oGPOrganizationalUnit & .2.2 & organizationalUnit & description, oGPXMLConfig, oGPSOA \\ \hline
+ oGPComputer & .2.1 & computer & oGPXMLConfig, oGPMachineCertificate, description, oGPSOA \\ \hline
\end{tabular}
\footnotetext{Préfixe de tous les OID : 1.3.6.1.4.1.7135.1.3.136}
\end{center}