Accueil Compétences Expériences Parcours Annexes
Des compétences, des expériences, un portfolio
AFS est un système de fichiers distribué, conçu pour faciliter la gestion d'un grand parc de machines hétérogènes. Un tel système de fichiers fournit, sur un site donné, un "espace de nommage" unique à tous ses clients; ceci signifie que tous les utilisateurs du site voient la même hiérarchie, ce qui implique: - Un même chemin d'accès (pathname) à tous les fichiers AFS -- en particulier les fichiers communs (binaires, etc.), mais aussi une grande facilité pour donner un accès (contrôlé) aux fichiers personnels - Une simplicité raisonnable pour fournir à un utilisateur un même environnement sur toutes les machines AFS. - A l'échelle d'un site, les machines partageant un tel système de fichiers constituent une "cellule AFS". Ces cellules peuvent être inter connectées entre elles, à l'échelle Internet, conduisant à un seul grand système de fichiers AFS mondial. - La cellule de l'INRIA s'appelle "inria.fr". A ce jour, elle contient l'INRIA Rocquencourt et l'INRIA Grenoble qui est en phase d'expérimentation. Dans une cellule, les machines sont de deux types : Serveurs AFS : Les machines serveurs sont celles qui contiennent l'ensemble des fichiers de la hiérarchie locale AFS. Dans la pratique, les machines serveurs ne concernent que les administrateurs AFS et sont peu visibles des utilisateurs, sauf en cas de panne du serveur où se trouvent les répertoires personnels des utilisateurs (quoique dans cette situation le comportement d'AFS est plus efficace qu'avec NFS). Clients AFS : Les machines clientes ont sur leur disque une mini racine (permettant de passer en single mode), un cache contenant les fichiers de la hiérarchie AFS récemment utilisés. Les quelques règles de bases à connaître lors de l'utilisation d'AFS sont les suivantes : - Jeton ou Token : lorsqu'une personne se connecte avec son nom de login et son mot de passe associés au compte informatique crée dans la base "hand" (base des comptes informatiques de l'UR Rocquencourt), il obtient un jeton, d'une durée de validité de 25 heures. Il peut alors pendant ce temps faire tout ce que ses droits lui permettent. - Une fois ces 25 heures révolues, son jeton est invalidé, et les tâches qu'il exécute (shell, script, navigateur, éditeur ...) sont désormais exécutées en tant que "anyuser", l'équivalent d'un compte invité aux droits très restreints. - Les solutions qui s'offrent alors à lui sont les suivantes : soit dans le shell qui a perdu le jeton exécuter "klog username" et taper son mot de passe AFS (couche d'authentification en plus du mot de passe machine), soit se déconnecter et se reconnecter sur l'environnement graphique, ce qui fera une nouvelle demande de jeton, et revalidera sa session. - AFS permet de disposer d'ACL beaucoup plus pointues que celles du système Linux classique, d'une centralisation des outils et logiciels installés. Sur toutes les machines, le répertoire "/usr/local/ "est le même montage AFS, qui se comporte alors comme NFS. Cette architecture de clients / serveurs AFS permet un grand nombre d'actions sur l'administration des systèmes. Elle permet entre autre de s'assurer de la sécurité et de l'intégrité sur les fichiers systèmes et les données. Les serveurs AFS disposent de multiples disques sur lesquels sont crées des volumes. Ces volumes sont organisés pour créer l'arborescence du système de fichier. Cette arborescence existe en double sur les serveurs. Une partie visible de tous en lecture et écriture (RW, Read-Write) sur laquelle les droits utilisateurs sont appliqués, et une deuxième partie, qui n'est pas directement visible par les utilisateurs (les dossiers sont précédés d'un "."), qui elle est uniquement en lecture seule (RO, Read-Only) et utilisée comme sauvegarde. Toutes les nuits à 3h du matin, des scripts vérifient les données modifiées des volumes en RW et les copient sur les volumes en RO. Ce "clone" de sauvegarde a plusieurs buts, le premier est de fournir aux utilisateurs un service de sauvegarde fiable et performant (grâce à un outil appelé NetWorker qui permet une restauration rapide), mais aussi une sécurité système très efficace car ces mêmes scripts vérifient l'intégrité des fichiers système des machines Linux (si un fichier protégé à été modifié d'une quelconque manière -erreur de manipulation ou piratage-, il est alors immédiatement écrasé par le fichier d'origine). Du côté administrateur système ce procédé est sécuritaire car les scripts remontent les erreurs quotidiennement par email mais aussi car il prévient les erreurs des utilisateurs et préserve le système. Il permet aussi d'installer ou de déployer de nouvelles versons d'outils facilement et rapidement pour l'intégralité du parc informatique sous Linux (fonctionnement comparable à Active Directory sous Windows). Le lien entre les volumes en lecture seule et ceux en lecture-écriture est fait par un outil appelé "repack". Lors de modifications prévues sur un système (test, vérification, ou validation de modification), un administrateur système peut provoquer à l'aide de cet outil, le passage des données des volumes en lecture-écriture sur les volumes en lecture seule. Cela signifie que le processus peut aussi est très réactif en cas de problèmes. C'est à ce jour le réseau sous Linux (300 machines environ gérées par cette cellule AFS), le plus abouti et fiable que j'ai pu rencontrer.
1 - Apache ant Récupérer l'archive tar.gz a cette adresse: http://ant.apache.org/ (A l'époque la dernière version était la 1.6.5) Décompresser cette archive dans /usr/java/ # unzip apache-ant-1.6.5.zip # mv apache-ant-1.6.5 /usr/java/ Pour gérer les variables a exporter, il y a deux méthodes, on peut utiliser indifféremment l'une ou l'autre. - Soit créer un script shell (env.sh par exemple) qui permettra de faire tous les exports facilement et que l'on pourra appeler à partir d'un script sur une machine de service. - Soit placer les exports dans le fichier .bashrc (par exemple), et qui donc sera lu dès que l'utilisateur se connecte. Voici le fichier: #!/bin/sh export ANT_HOME=/usr/java/apache-ant-1.6.5 PATH=${ANT_HOME}/bin:$PATH export PATH export JAVA_HOME=/usr/java/jdk1.5.0_07 PATH=${JAVA_HOME}/bin:$PATH Pour tester que les export ont bien ete pris en compte: # ant Qui doit retourner une erreur du type: Buildfile: build.xml does not exist! Build failed 2 - Java JDK Pour l'installation des outils (uPortal, CAS, Helpdesk), il est nécessaire d'avoir un JavaDevelopperKit (1.5 par exemple), mais le JavaRuntimeEdition est suffisant pour l'exécution seule de Tomcat et du helpdesk. Un RPM ou un BIN auto-extractible peut être téléchargé a cette adresse: http://java.sun.com/j2se/1.5.0/download.jsp # chmod +x jdk-1_5_0_06-linux-i586-rpm.bin # ./jdk-1_5_0_06-linux-i586-rpm.bin Pour tester, même méthode que pour apache, # java qui renvoi le résultat de java -help 3 - Jetty Utilisé pour la conversion des certificats en keystore java, la dernière version stable peut être trouvée a cette adresse: http://sourceforge.net/project/showfiles.php?group_id=7322&package_id=132252 La décompresser dans /usr/java # unzip jetty-5.1.10.zip # mv jetty-5.1.10 /usr/java/ 4 - Certificats Comme dit précédemment, avant la mise en place de l'IGC, la création et la gestion des AC et des certificats se faisait manuellement. Voici les commandes à effectuer pour chacune des machines après avoir récupéré les certificats par l'IGC. 4.1 - waco (waco.inria.fr, la machine qui héberge le serveur CAS) # /usr/local/openssl-0.9.7d/bin/openssl pkcs12 -export -inkey waco.inria.fr.key \ -in waco.inria.fr.crt \ -out waco.inria.fr.pkcs12 # /usr/java/jdk1.5.0_07/bin/java -classpath \ /usr/java/jetty-5.1.10/lib/org.mortbay.jetty.jar org.mortbay.util.PKCS12Import \ waco.inria.fr.pkcs12 waco.inria.fr.keystore # /usr/java/jdk1.5.0_07/bin/keytool -keyclone \ -keystore waco.inria.fr.keystore \ -alias 1 -dest waco.inria.fr # /usr/java/jdk1.5.0_07/bin/keytool -delete \ -alias 1 -keystore waco.inria.fr.keystore # /usr/java/jdk1.5.0_07/bin/keytool -import \ -alias waco.inria.fr -trustcacerts \ -file waco.inria.fr-chain.pem \ -keystore waco.inria.fr.keystore # /usr/java/jdk1.5.0_07/bin/keytool \ -list -v -keystore waco.inria.fr.keystore 4.2 - comox (comox.inria.fr, la machine qui héberge le esup-helpdesk) # /usr/local/openssl-0.9.7d/bin/openssl pkcs12 \ -export -inkey comox.inria.fr.key \ -in comox.inria.fr.crt -out comox.inria.fr.pkcs12 # /usr/java/jdk1.5.0_07/bin/java -classpath /usr/java/jetty-5.1.10/lib/org.mortbay.jetty.jar org.mortbay.util.PKCS12Import \ comox.inria.fr.pkcs12 comox.inria.fr.keystore # /usr/java/jdk1.5.0_07/bin/keytool -keyclone \ -keystore comox.inria.fr.keystore \ -alias 1 -dest comox.inria.fr # /usr/java/jdk1.5.0_07/bin/keytool -delete \ -alias 1 -keystore comox.inria.fr.keystore # /usr/java/jdk1.5.0_07/bin/keytool -import \ -alias comox.inria.fr -trustcacerts \ -file comox.inria.fr-chain.pem -keystore comox.inria.fr.keystore # /usr/java/jdk1.5.0_07/bin/keytool -list -v \ -keystore comox.inria.fr.keystore 5 - Ldap L'authentification du serveur CAS est réalisée en parallèle avec le serveur LDAP de l'INRIA. Un serveur LDAP comporte différents attributs, celui que nous voulons utiliser est le champ 'inriaLogin' correspondant en général au login utilisateur (la plupart du temps les 8 premières lettres du nom de famille à l'INRIA), et non pas l'attribut 'cn' ou 'uid' qui est moins parlant et que les utilisateurs ne connaissent pas forcement. 6 - Cas Generic Quickstart Le fichier de configuration du serveur CAS est situé dans './esup-cas-quick-start-2.0.6-1/properties/build.properties' voici ce fichier de configuration épuré des commentaires et des options de configuration qui ne nous concernent pas. #================================================= # CAS Generic Handler version # esup-casgeneric.version=2.0.6 esup-casgeneric.release=1 #================================================= # CAS Generic Handler authentication mode # # ${esup-casgeneric.auth} should correspond to a folder in custom/esup-casgeneric-auth # # Possible values are empty-password (by default, for debugging purposes # only) and ldap (authentication with an LDAP directory). # # To add a new authentication mode, simply add a directory to custom/esup-casgeneric-auth # esup-casgeneric.auth=ldap #================================================= # Complex (search, then bind) LDAP authentication esup-casgeneric.auth=ldap-search #esup-casgeneric.auth.ldap-search.filter=uid=%u esup-casgeneric.auth.ldap-search.filter=inriaLogin=%u esup-casgeneric.auth.ldap-search.search-base=ou=people,dc=inria,dc=fr esup-casgeneric.auth.ldap-search.scope=sub esup-casgeneric.auth.ldap-search.bind-dn= esup-casgeneric.auth.ldap-search.bind-password= esup-casgeneric.auth.ldap-search.url=ldap://ildap1-roc.inria.fr #================================================= # Complex (search, then bind) LDAP authentication with a replica #esup-casgeneric.auth=ldap-search-rep #esup-casgeneric.auth.ldap-search-rep.filter=uid=%u #esup-casgeneric.auth.ldap-search-rep.search-base=ou=people,dc=esup-portail,dc=org #esup-casgeneric.auth.ldap-search-rep.scope=sub #esup-casgeneric.auth.ldap-search-rep.bind-dn=admin #esup-casgeneric.auth.ldap-search-rep.bind-password=secret #esup-casgeneric.auth.ldap-search-rep.url1=ldap://ldap.esup-portail.org #esup-casgeneric.auth.ldap-search-rep.url2=ldap://ldap2.esup-portail.org #================================================= # CAS Generic Handler log file # # if you use a relative path, it will be relative to your servet container's root directory. esup-casgeneric.log.path=/var/log/esup-casgeneric.log #================================================= # CAS Generic Handler log (log4j) level # #esup-casgeneric.log.level=INFO #================================================= # CAS Server version # cas-server.version=2.0.12 #================================================= # CAS Server HTML rendering # # the cas-server.render variable should correspond to folder and a properties # file in custom/cas-server-render # # Possible value are esup-portail.org (by default) and its.yale.edu (the # original look). # # To add a new xxx rendering, simply add a new xxx folder and a xxx.properties # file to custom/cas-server-render # #cas-server.render=esup-portail.org #================================================= # Jakarta Tomcat location # cas-server.deploy.home= ${basedir}/jakarta-tomcat-${jakarta-tomcat.version}/webapps/cas #================================================= # Apache Jakarta Tomcat version # jakarta-tomcat.version=5.0.28 #================================================= # port CAS will be listenig to # jakarta-tomcat.port.shutdown=8005 jakarta-tomcat.port.https=8443 #================================================= # properties for the server certificate # # if ${jakarta-tomcat.genkey} is true, the certificate is generated by ant # as server.ks and the public certificate is exported as cacerts.ks (both # files are located in the jakarta-tomcat-x.y.z/conf folder, using # ${jakarta-tomcat.keystore.*} properties). # # Otherwise, the server certificate is intended to be found in # ${jakarta-tomcat.keystore.path}. In this case, ${jakarta-tomcat.keystore.alias} # and ${jakarta-tomcat.keystore.password} are used by Jakarta Tomcat to # read the server certificate. # # To use an existant keystore, set the following properties: jakarta-tomcat.keystore.genkey=false jakarta-tomcat.keystore.path=/var/tomcat/certificats/server.keystore jakarta-tomcat.keystore.alias=waco.inria.fr jakarta-tomcat.keystore.storepass=export jakarta-tomcat.keystore.keypass=${jakarta-tomcat.keystore.storepass}