\documentclass[french,a4paper]{article}
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{babel}
\usepackage{graphicx}
\usepackage{url}
\usepackage{alltt}
\usepackage{varioref}
\usepackage{hyperref}

\title{Kollectiv' admin}
\author{intrigeri [intrigeri@squat.net]}

\begin{document}

\maketitle

\begin {abstract}
  Ce document vise à proposer un schéma d'administration
  \emph{collective} et \emph{formalisée} d'un parc d'ordinateurs, dans
  un contexte nécessitant de prêter une attention particulière aux
  questions de sécurité informatique.
\end{abstract}

\newpage
\tableofcontents

\newpage

\subsection{Changelog}
\label{sec:changelog}
\begin{itemize}
\item 2003 02 17: version initiale
\item 2003 04 04:
  \begin{itemize}
  \item quelques clarifications langagières
  \item précision plus grande au niveau des relations entre
    \textit{blocs} d'admin
  \end{itemize}
\item 2003 04 05: annexes
\item 2003 04 14: début de conversion en \TeX
\item 2003 04 19: fin de la conversion
\item 2003 04 20: écriture du Makefile
\item 2003 05 10: plein de clarifications/ajouts
\item 2003 05 29: réorganisation complète de ce document, recentrage
  sur les objectifs initiaux, peaufinages divers
\item 2003 06 07: version RFC
\end{itemize}

\subsection{TODO}
\begin{itemize}
\item préciser que les rôles des adminEs peuvent évoluer dans le temps
\item comment gérer les dépendances entre blocs d'admin ?
\item scripts permettant la gestion des admins ?
\item paquet Debian \og ala AlternC\fg{} ?
\end{itemize}


\newpage
\section{Analyse du problème}

\subsection{Politique}

Le fait d'administrer des ordinateurs collectifs ou un serveur n'est
pas anodin ; cela implique :
\begin{itemize}
\item un \og contrat de confiance\fg{} avec les utilisateurices ;
\item une grande disponibilité pour être réactif/ve en cas de
  problème;
\item du temps et de la régularité pour la maintenance;
\end{itemize}

De plus, il est souhaitable, dans le cadre de l'administration
collective d'un parc informatique, de mettre en place des solutions
respectant les contraintes suivantes :
\begin{itemize}
\item non-concentration du pouvoir ;
\item répartition du travail sur quelques cerveaux coopérants;
\item gestion et suivi aisés de la partie commune de l'administration;
\item simplicité de la transmission de tâches/responsabilités.
\end{itemize}

Quelques précisions avant de mettre les mains dans le cambouis...
\begin{itemize}
\item la confrontation de ce modèle théorique avec l'expérience vécue
  ne manquera pas, soyons-en sûrEs, de remettre en cause certains des
  choix de ce document... et tant mieux !
\item l'auteur principal étant quelque peu novice en la matière, il
  est fort probable que des absurdités se soient glissées dans ce
  document... merci de les lui signaler.
\end{itemize}




\subsection{Technique}

\subsubsection{Permissions des adminEs}

Le choix qui a été fait est de ne pas divulguer les mots de passe root
des machines, mais plutôt de donner aux adminEs les permissions
nécessaires par l'intermédiaire de sudo.

D'autre part, on ne peut évidemment pas administrer un serveur
indépendamment des machines clientes (exemple: cas d'un serveur
d'authentification) ; il est donc logique de confier aux adminEs d'un
service la gestion des logiciels correspondants sur les machines
clientes.

Afin de simplifier notre modélisation, on supposera que, pour
administrer un service donné, unE adminE a besoin des mêmes
permissions sur le serveur que sur les machines clientes.

Une solution satisfaisant à ces contraintes est proposée dans l'annexe
\ref{sec:dist-sudo}.

\subsubsection{Outils de partage d'information}

Les réplications d'informations nécessaires entre les machines sont
notamment sources :
\begin{itemize}
\item de complexification,
\item de vulnérabilités,
\item d'incohérences des données entre les machines.
\end{itemize}      
  
Pour ces raisons, on veillera à éviter ces duplications au maximum, en
choisissant autant que possible des solutions capables d'utiliser les
informations centralisées sur un serveur; cette direction donnée à
notre réflexion vaut en particulier pour :
\begin{itemize}
\item la gestion et l'authentification des comptes utilisateurices;
\item le suivi des modifications de la configuration des machines;
\item le suivi des problèmes.
\end{itemize}
  
Pour une réflexion sur les outils qui seront utilisés pour partager
ces informations, on se référera aux annexes \ref{sec:changelogs} et
\ref{sec:bug-tracking}. 



\newpage
\section{Et concrètement... comment procéder ?}
Dans cette partie, nous décrirons un mode opératoire permettant de
modéliser et de mettre en place le système d'administration collective
proposé dans ce document.

\subsection{Audit des besoins et moyens}
\label{sec:besoins-et-moyens}
La validité de la modélisation dépend, en bonne partie, de la rigueur
avec laquelle on effectuera les audits suivants :
    \begin{itemize}
    \item lister les services à mettre en place sur la machine ;
    \item établir les relations de dépendance entre ces services;
    \item en déduire l'étendue de la partie commune à touTEs les admin-e-s;
    \item lister les moyens humains disponibles : affinités,
      disponibilités coïncidentes, temps disponible, compétences, etc.
    \end{itemize}

\subsection{Répartition des tâches}
\label{sec:repartition-des-taches}
À partir des données rassemblées à l'étape \ref{sec:besoins-et-moyens} :
    \begin{itemize}
    \item définir des sous-ensembles de tâches à effectuer, qu'on
      nommera dorénavant des \textit{blocs} d'admin, qui ne se
      recoupent pas entre eux ; pour les matheuxEs, il s'agit de
      réaliser une \textit{partition} de l'ensemble des tâches à
      effectuer ;
    \item définir des sous-ensembles de personnes, qu'on nommera
      dorénavant des \textit{équipes} d'admin ; le nombre de ces équipes
      doit évidemment être au maximum égal au nombre de blocs... ;
    \item assigner une équipe à chaque bloc;
    \item déduire de l'étape \ref{sec:besoins-et-moyens} les relations de dépendance entre les
      blocs d'admin, selon la règle suivante :\\
      \\
      \begin{math}
      \textrm{le bloc } A \textrm{ dépend du bloc } B\\
      \leftrightarrow\\
      %\equiv
      \exists (\textrm{un élément } a \in A \textrm{ et un élément } b \in B)
      \textrm{ tels que } a \textrm{ dépend de } b
      \end{math}
    \end{itemize}

\subsection{Conception de la communisation des informations}
\label{sec:conception-communisation}
    \begin{itemize}
      
    \item choix des différents groupes/users/privilèges sudo, en
      fonction de la répartition des tâches effectuée à l'étape
      \ref{sec:repartition-des-taches}.
      
    \item en fonction de l'échelle du parc informatique (quantité de
      machines et de services à administrer) choix des procédures et
      outils de partage des informations; cf. annexes
      \ref{sec:changelogs} et \ref{sec:bug-tracking}.

    \end{itemize}

\subsection{Implémentation du modèle}
Il s'agit de :
\begin{itemize}
\item installation et paramétrage du système d'exploitation et de la
  partie commune
\item installation, par les adminEs concernéEs, des services
  nécessaires pour la suite
\item mise en place des outils de partage d'information prévus à
  l'étape \ref{sec:conception-communisation}
\end{itemize}

  
\newpage
\appendix{}

\section{Distribution des droits des adminEs}
\label{sec:dist-sudo}
On l'a vu, les adminEs doivent avoir accès aux machines clientes, avec
les mêmes permissions que sur le serveur, pour pouvoir les
administrer.

Comme toutE autre utilisateurice, unE adminE se connectant sur une
machine cliente se verra authentifiéE sur le serveur. Puis vient le
moment où ille utilise sudo; sudo, tout d'abord, authentifie l'adminE
sur le serveur central, via l'utilisation de PAM (Pluggable
Authentication Modules) sur la machine cliente.  Mais la difficulté
est ailleurs: sudo ne sait stocker \emph{que} dans le fichier
\texttt{/etc/sudoers} les permissions détaillées attribuées aux
adminEs ; afin de gérer tout ceci de façon centralisée, il nous faut
utiliser un système sécurisé de partage ou réplication de fichiers
pour \texttt{/etc/sudoers}. Le logiciel cfengine
(http://www.cfengine.org/) semble remplir cette tâche à merveille.



\section{Suivi et diffusion des changements}
\label{sec:changelogs}
Dans notre cadre de travail collaboratif, les membres d'une équipe
d'adminEs doivent être informéEs des modifications de configuration
effectuées par l'unE d'entre elleux. Il faut donc mettre en place un
système permettant non seulement d'enregistrer ces modifications, mais
aussi de les faire parvenir à qui de droit.

\subsection{Suivi des changements}
Pour enregistrer les modifications de configuration effectuées,
différentes méthodes s'offrent à nous :
\begin{itemize}
\item fichiers Changelog édités à la main par les adminEs ; cette
  solution a l'indéniable avantage de la simplicité, mais elle part du
  principe que les adminEs seront rigoureuxes et renseigneront
  systématiquement et correctement le Changelog approprié... cette
  supposition est peut-être un tantinet optimiste ;)
\item GNU RCS (Revision Control System) sauvegarde les modifications
  effectuées sur les fichiers qu'on lui confie ; c'est sur ce logiciel
  que se base CVS, qui lui est plutôt conçu pour gérer, à travers le
  réseau, des arborescences complètes, alors que RCS en reste à
  l'échelle du fichier et d'une machine.
\end{itemize}

\subsection{Diffusion des Changelogs}
Afin de diffuser les modifications des Changelogs, une solution
commode consiste en la création d'une liste de discussion par équipe
d'admin, plus une ML commune à tou-te-s les adminEs; ainsi, il suffira
de mettre en place un système qui envoie des mails aux listes
concernées en cas de modification des Changelogs ; si RCS est choisi,
rcs-report fait exactement ce travail ; sinon, diffmon est une
solution à étudier.

Pour éviter que ces emails ne passent en clair sur le réseau,
plusieurs solutions existent, selon le cas on choisira la plus
adaptée:
\begin{itemize}
\item inscrire aux ML l'utilisateurice de chaque adminE sur le serveur
  d'administration... c'est le plus simple, on n'a pas besoin de
  cryptage dans ce cas là car les mails ne sortent pas du serveur;
\item utiliser une clé gpg par équipe d'admin et crypter les mails
  avant qu'ils ne soient envoyés sur la liste;
\item utiliser la version patchée de Mailman: \newline cf.
  http://www.nah6.com/products/secure-list/.
\end{itemize}


\section{Suivi des problèmes}
\label{sec:bug-tracking}
Tout d'abord, pourquoi suivre les problèmes avec un logiciel
spécialisé ? On pourrait en effet considérer cette méthode comme trop
lourde, trop compliquée, cependant... un tel logiciel sert :
\begin{itemize}
\item pour ne pas oublier dans un coin certains problèmes, en se
  promettant d'y revenir plus tard;
\item pour que toutE unE chacunE puisse signaler des problèmes.
\end{itemize}

Pour ce faire, d'excellents outils libres existent ; par exemple :
\begin{itemize}
\item RT (perl/mysql), utilisé sur stallman.indymedia.org ; il n'est
  hélas pas packagé en Debian, mais sait s'authentifier sur le serveur
  web :\newline http://www.bestpractical.com/rt/
\item Bugzilla (perl/mysql), très complet en version 2.14.2 sur Woody
  ; cette version n'est plus supportée par l'équipe de
  développement... et a des trous de sécurité ; la dernière version
  stable (2.16.3) est dans Sarge :\newline
  http://www.mozilla.org/projects/bugzilla/
\item Debian bug tracking software (perl/?) ; un peu roots :\newline
  http://www.chiark.greenend.org.uk/~ian/debbugs/
\item Mantis (php/mysql) :\newline http://mantisbt.sourceforge.net/
\item GNU GNATS (?/txt) :\newline
  http://www.gnu.org/software/gnats/
\end{itemize}

Idéalement, le logiciel choisi doit être capable de s'authentifier sur
l'annuaire centralisé d'utilisateurices qui aura été choisi. Seul RT
remplit cette condition, car il sait s'authentifier sur Apache, donc,
par transitivité, sur PAM et/ou LDAP.


\end{document}

\bye

