admin système

Administration de machines (systèmes d'exploitation) : sauvegarde, impression, surveillance...
Fiche logiciel validé
  • Création ou MAJ importante : 12/09/13
  • Correction mineure : 12/09/13
  • Rédacteur de la fiche : Dirk Hoffmann - Centre de Physique des Particules de Marseille (CPPM-IN2P3) (IN2P3, Université de la Méditerranée Aix-Marseille)
  • Relecteur(s) : Teresa Gomez-Diaz (LIGM)
    Cédric Hillembrand (CESR)
  • Contributions importantes : Jean-Michel Glorian (CESR) a été le contributeur initial de la fiche, suivie précédemment par Véronique Baudin (LAAS) en tant que responsable thématique.
  • Responsable thématique : David Rousse (CNRS DSI)
Mots-clés

TWiki : wiki basé sur perl et RCS

Description
Fonctionnalités générales
  • TWiki est un wiki qui permet de créer de manière collaborative un contenu accessible par un navigateur web.
  • Il fonctionne avec un serveur web comme Apache.
  • Il est écrit en perl et utilise une base de données au format RCS/CVS dans un système de fichier local ou monté, pour gérer l'historique.
Autres fonctionnalités

TWiki repose sur les concepts de web (répertoires) et de topic (fichiers ou pages) : un web est un espace de collaboration, qui peut contenir (depuis la version 5) des /web à son tour. Chaque web est contient normalement des topics qui sont les pages web du wiki.
Comme chaque topic peut avoir un topic parent, il est très facile de lister les enfants d'un topic et ainsi d'organiser son twiki en changeant le parent du topic.

  • Formulaires : il est possible de créer facilement des formulaires de saisie simplifiant l'édition et la création de pages formatées.
  • Gestion des droits d'accès :
    • niveaux d'accès : lecture / écriture (modification)
    • cibles de privilèges : personne / groupe
    • portée de privilèges : web / topic
  • Existence de plugins comme par exemple pour faire des forums.
  • Édition au choix en format "wiki dialect" (ou WikiMarkup) ou WYSIWYG.
  • Fonctions de tri/classement.
  • Notifications, abonnement.
  • La version "pro" de TWiki (depuis la version 5, voir plus loin) intègre des fonctionnalités qui renforcent sa position de plate-forme de collaboration d'entreprise.

La gestion des utilisateurs et de leurs profils se fait entièrement à travers des pages TWiki. Également la gestion de l'appartenance à un groupe se fait à travers une page spéciale TWiki. Ces pages sont normalement protégées de manière sensée contre l'abus ou l'intrusion malveillante.

Interopérabilité
  • L'accès a TWiki se faisant par le protocole HTTP, tout navigateur et tout système d'exploitation peut être utilisé pour l'accès standard utilisateur.
  • De nombreux plugins permettent d'effectuer des échanges de contenu dans différents formats (exportation au format pdf ou html).
  • Les fichiers annexes (attachments) sont stockés tels quels sur le système de fichiers.
  • Toute la base du contenu des pages peut être accédée à travers des clients RCS/CVS (ce sont des fichiers texte, voir la documentation de RCS.)
  • Accès en lecture écriture à une base de données SQL avec Databaseplugin : http://twiki.org/cgi-bin/view/Plugins/DatabasePlugin
Contexte d'utilisation dans mon laboratoire/service

Ce wiki a été utilisé dans le cadre du Cercle des métiers de l'informatique du CESR (aujourd'hui IRAP), un laboratoire du CNRS.

Il est utilisé au CPPM, laboratoire IN2P3/CNRS : http://martwiki.in2p3.fr.

Limitations, difficultés, fonctionnalités importantes non couvertes

Difficultés à mettre en place différents droits selon le type de compte.

Environnement du logiciel
Distributions dans lesquelles ce logiciel est intégré

Debian, Ubuntu, Linux CentOS

Plates-formes

Serveur web supportant ces prérequis : http://twiki.org/cgi-bin/view/TWiki05x01/TWikiSyst...

Logiciels connexes
Autres logiciels aux fonctionnalités équivalentes
Environnement de développement
Type de structure associée au développement

TWiki.org a démarré comme projet open source. Le développeur leader de TWiki a choisi d'exploiter une voie plus commerciale avec son produit (en gros une branche "gratuite" et une branche "entreprise" avec plus d'options et du support professionnel, un peu comme le couple RedHat/Fedora). Il en a résulté un "fork" du projet en 2008 en Foswiki, qui a attiré "la plus grande majorité des développeurs" (qui n'étaient pas d'accord avec ce choix donc).

En lire plus sur les forks : http://en.wikipedia.org/wiki/TWiki#Forks_of_TWiki

Et pour essayer de comprende les raisons du schisme :

Eléments de pérennité
Références d'utilisateurs institutionnels
Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur
Divers (astuces, actualités, sécurité)
  • Astuce : pour créer un topic (une page) rapidement, il suffit que le nom de votre page comporte 2 majuscules, un lien sera alors automatiquement proposé. D'autres informations pour les débutants sont accessibles ici : http://twiki.org/cgi-bin/view/TWiki/ATasteOfTWiki
  • Démo. : pour faire quelques tests sur TWiki, vous pouvez utiliser ce topic après vous être enregistré, http://twiki.org/cgi-bin/view/Sandbox/WebHome.
  • Configuration : la configuration du TWiki (définition des paths, des options régionales, activation des plugins, ...) se fait à l'aide de l'interface web, http://serveur.domaine.fr/bin/configure
    Ensuite, la définition des droits, et fonctionnalités de chaque page se fait à l'intérieur de celles-ci.
  • Sécurité : comme tout site web, l'administration d'un TWiki nécessite de prendre connaissance des avis de sécurité et des actions à mener pour limiter les risques. Toutes les informations sur les mesures à prendre, http://twiki.org/cgi-bin/view/Codev/TWikiSecurityA...
  • Gestion des permissions : l'instance TWiki du CERN (ci-dessus) intègre la gestion des groupes et utilisateurs à travers le système e-groups, qui gère de manière centrale tous les groupes de cet institut, d'environ 10000 utilisateurs.
Contributions
Fiche logiciel validé
  • Création ou MAJ importante : 20/07/10
  • Correction mineure : 23/05/13
Mots-clés

Bacula : système de sauvegarde en réseau

Description
Fonctionnalités générales

Bacula est une solution avancée de sauvegarde réseau pour des systèmes de type Unix mais qui fonctionne également sous Windows.
Il comporte un ensemble de programmes qui permet de gérer les sauvegardes, les restaurations ainsi que les vérifications de données d'un ordinateur sur un réseau hétérogène.

L'architecture est basée sur le principe client/serveur. Plusieurs serveurs avec des OS de type Unix, sont nécessaires : un directeur, une base de données de type SQL et un serveur de stockage. Windows dispose d'un client natif.

Cette architecture solide a permis au projet de progresser en nombre de fonctionnalités et apporte une grande flexibilité à l'administrateur.

L'administration peut se faire depuis une interface textuelle (bconsole) ou bien graphique (bat). Une application web est aussi disponible (bweb).

La possibilité de lancer des scripts avant et/ou après un travail de sauvegarde, ouvre de nombreuses possibilités seulement limitées par l'imagination des administrateurs : instantanés de volume logique LVM sous Linux, création d'instantanés directement au niveau d'un SAN...

Les sauvegardes sont multi-volumes, c'est-à-dire que la taille d'une sauvegarde peut dépasser la capacité d'un support stockage.
Les supports de sauvegardes sont très variés : bandes, disques et CD/DVD. Les bibliothèques de bandes comportant un ou plusieurs lecteurs sont supportées du moment qu'elles fonctionnent avec les commandes unix "mt" et "mtx"

Autres fonctionnalités
  • utilisation du Volume Shadow Copy Service de Microsoft pour de faire des sauvegardes de fichiers ouverts sous les OS de Microsoft ;
  • système de plugins ;
  • chiffrement possible des communications par TLS ;
  • sauvegarde de type vfull (virtual full), pour créer une sauvegarde complète en appliquant les précédentes sauvegardes partielles (incrémentales ou différentielles) ; la fenêtre de sauvegarde est alors réduite ;
  • migration de sauvegarde d'un support à un autre ;
  • signature et/ou chiffrement des sauvegardes avec une IGC (la clé privée n'est à fournir que sur le client et uniquement lors de la restauration ce qui assure la confidentialité des données vis à vis de ceux qui sont en charge de la sauvegarde) ;
  • création de CD permettant de réinstaller un système à partir des sauvegardes (utile en cas de remplacement du disque contenant le système).
Interopérabilité

Les données sont sauvées dans un format ouvert et stable

Limitations, difficultés, fonctionnalités importantes non couvertes
  • nombre de services à mettre en fonction ;
  • nombre d'options important ;
  • les tables contenant les fichiers sauvegardés peuvent devenir très grosses et dépasser la limite d'adressage sur 32 bits ce qui demande un paramétrage particulier du serveur SQL ;
  • certains robots de bandes peuvent exiger quelques adaptations dans les scripts ;
  • il est impératif de tester régulièrement les procédures de restauration.
Environnement du logiciel
Distributions dans lesquelles ce logiciel est intégré

Linux Debian et Fedora

Autres logiciels aux fonctionnalités équivalentes
Environnement de développement
Type de structure associée au développement

Projet avec mainteneurs.
Société pour le support depuis 2008 : Bacula System SA.

Eléments de pérennité

Le projet existe depuis 2000. Il a reçu le soutien de la FSF Europe en 2006.
La société Bacula System SA a plusieurs contrats dont un avec une banque autrichienne.

Références d'utilisateurs institutionnels

A ma connaissance beaucoup d'utilisateurs dans le milieu éducation-recherche et une banque en Autriche.

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur

Retour d'expérience d'une installation Shibboleth (Fournisseur d'identités)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 19/07/10
  • Correction mineure : 19/12/11
Mots-clés

Retour d'expérience d'une installation Shibboleth (Fournisseur d'identités)

  • Type de ressource : article, compte-rendu
  • Date de publication du document ou de l'événement : Septembre 2009
  • Auteur(s) ou responsable(s) : Samuel Godey (CNRS/UREC)
  • Contact pour plus d'informations : samuel.godey@urec.cnrs.fr

La fiche

Document de base pour la rédaction de cette fiche

Date : JUIN-DECEMBRE 2009
Auteur : Samuel Godey (CDD Ingénieur d'étude de 6 mois)
Commanditaire : Patrice Koch (Directeur du CRI Université de Franche-Comté à Besançon)

Nature de la fiche

Cette fiche expose mon expérience sur l'installation du serveur fournisseur d'identités à l'université de Franche-Comté en 2009 et explique comment réaliser la mise à jour des briques logicielles nécessaires à son fonctionnement. La partie fournisseur de services ne sera pas traitée. Certaines informations dans ce texte ont été volontairement remplacées par des termes génériques. La configuration décrite ici est dépendante de l'architecture déjà en place à l'université de Franche-Comté, cependant la majorité des grandes structures utilise des technologies similaires. Les paramètres peuvent varier et sont certainement incompatibles avec votre situation. N'attendez de ce texte qu'un point de départ ou une source d'inspiration pour votre propre fournisseur d'identités.
Attention : ce document ne garantie pas le bon fonctionnement de votre installation.

Public destinataire

Cette note est à l'attention des administrateurs d'un service "fournisseur d'identités" avec la technologie Shibboleth. Veuillez prendre en considération que des connaissances sur LDAP ainsi que sur le service SSO CAS sont nécessaires pour suivre cette fiche, bien que ces services ne soient pas obligatoires pour utiliser Shibboleth. Le serveur fournisseur d'identités a été ajusté pour la fédération éducation-recherche de Renater. Je considère que les utilitaires GNU/Debian sont maîtrisés.

Complément d'information

Les supports techniques utilisés pour réaliser l'installation initiale ainsi que d'autres documentations pour l'installation sont disponibles à l'adresse : https://federation.renater.fr
Les noms des programmes mentionnés dans ce document peuvent se trouver sous la forme "logiciel-x.x.x.foo". Veuillez prendre en considération la version des programmes stables à jour afin d'adapter ce document dans le temps. Par exemple, remplacez x.x.x par 2.3.1 si la version du logiciel "logiciel" est actuellement en version 2.3.1.

Fiches PLUME en lien avec ce retour d'expérience

Pré-requis

Serveur :

  • Lenny/Debian/GNU/Linux

Application Debian non-free/contrib :

  • sun-java-6

Applications Debian main :

  • Apache 2.2
  • mod_ssl
  • mod_proxy_ajp
  • OpenSSL
  • NTP-server
  • Maven

Applications externes :

  • Apache-tomcat6
  • Shibboleth-idp
  • CAS-client

Plan

1) Introduction

1.1) Présentation des chemins d'accès
1.2) Sources des programmes

2) Procédure de mise-à-jour de la brique Shibboleth-idp

2.1) Procédure de mise-à-jour de la brique CAS-client

3) Procédure de mise-à-jour et d'installation de Tomcat
4) Configuration de Apache2.2 (lenny/debian)
5) Configuration de Shibboleth-idp

5.1) attribute-resolver.xml
5.2) attribute-filter.xml

6) Droits et sécurité

6.1) Shibboleth-idp
6.2) Tomcat
6.3) Certificat SSL Apache
6.4) Ajout des certificats non valides

1) Introduction

Veuillez considérer ce document comme un complément d'information pour un service "fournisseur d'identités" déjà en exploitation ou en test avec les briques LDAP et CAS configurées. Il est inutile d'essayer de réaliser une nouvelle installation en s'appuyant sur ce document. Si vous souhaitez installer ce service pour la première fois, il est conseillé d'utiliser les supports techniques fournis par Renater et la documentation officielle de Shibboleth :
- Support technique Renater : https://federation.renater.fr
- Documentation officielle de Shibboleth-idp : https://spaces.internet2.edu/display/SHIB2/

Dans le cas d'une mise-à-jour à cause d'un problème de sécurité ou encore parce que de nouvelles fonctionnalités sont nécessaires, il est important de conserver une copie de la configuration en cours et de procéder à une installation standard. Dès que la mise-à-jour est terminée, il faut vérifier vos fichiers de configuration et les remplacer si nécessaire par vos sauvegardes.

Remarque très importante : si vous hésitez à réaliser une mise-à-jour et que vous préférez utiliser un SNAPSHOT (point de sauvegarde instantanée) de votre machine virtuelle, vous devrez impérativement re-synchroniser l'horloge (avec ntptime) de la machine virtuelle. En effet, une petite dérive temporelle peut supprimer les sessions actives des utilisateurs. Dans le pire de cas, un redémarrage suffit est reste une valeur sûre.

1.1) Présentation des chemins d'accès

Je vous encourage à prendre en considération les chemins ci-dessous pour la lecture de ce document car je les ai déterminés arbitrairement. Par ailleurs, ces derniers peuvent ne pas être les plus judicieux. À vous de choisir des emplacements confortables.

Shibboleth-idp : /opt/shibboleth-idp
configuration de Shibboleth : /opt/shibboleth-idp/conf
certificats de Shibboleth : /opt/shibboleth-idp/credentials
méta-données (éducation-recherche) : /opt/shibboleth-idp/metadata

Données complémentaires :

fqdn shibboleth-idp : idp.mondomaine.fr
chemin source idp : /opt/shibboleth-identityprovider-x.x.x
chemin brique logicielle : /opt/shibboleth-identityprovider-x.x.x/lib/cas-client-core-x.x.x.jar
config compil : /opt/shibboleth-identityprovider-x.x.x/src/main/webapp/WEB-INF/web.xml
configuration Renater : https://services-federation.renater.fr/exemples/co...
méta-données Renater : https://services-federation.renater.fr/metadata/re...
certificat fédération Renater : https://services-federation.renater.fr/metadata/me...

Remarques :

idp.mondomaine.fr a besoin uniquement des ports 448 et 8448. Ils doivent être accessibles et sont nécessaires au bon fonctionnement du service.
À vos pare-feu : 448 et 8448 ouverts en entrée sur idp.mondomaine.fr

1.2) Sources des programmes :

shibboleth-idp url : http://shibboleth.internet2.edu/downloads/shibbole...
shibboleth-idp nom de l'archive : shibboleth-identityprovider-x.x.x-bin.zip
cas-client url : http://www.ja-sig.org/downloads/cas-clients/
cas-client nom archive : cas-client-x.x.x-release.zip
tomcat6 url : ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x...
tomcat6 nom archive : apache-tomcat-6.x.xx.tar.gz

2) Procédure de mise-à-jour de la brique Shibboleth-idp

  • Arrêtez shibboleth-idp :

    /etc/init.d/tomcat stop
  • Faites une copie de sécurité de la configuration :

    tar zcvf ~/shib-conf.tgz /opt/shibboleth-idp/conf
  • Téléchargez la dernière version :

  • Décompressez :

    jar -xf shibboleth-identityprovider-2.1.5-bin.zip
  • Éditez le fichier de compilation :

    Par commodité, je vous conseille de faire des copies de sécurité de la configuration d'accès à votre serveur CAS. À chaque nouvelle version de Shibboleth, vous devrez adapter le fichier de compilation "web.xml" avec votre système d'authentification. Le but est d'intégrer la brique "cas-client" pré-configurée sur votre réseau en ajoutant les informations locales de votre service.

    Exemple d'un fichier /opt/shibboleth-idp/cas_web.xml à adapter suivant vos besoins :

    <!-- CAS Filter Configuration -->
    <context-param>
    <param-name<serverName</param-name>
    <param-value>https://idp.mondomaine.fr</param-value>
    </context-param>
    <!-- CAS Authentication Filter -->
    <filter>
    <filter-name>CAS Authentication Filter</filter-name>
    <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
    <init-param>
    <param-name>casServerLoginUrl</param-name>
    <!-- votre page de login -->
    <param-value>https://cas.mondomaine.fr/cas/login</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas/login</param-value> -->
    </init-param>
    </filter>
    <!-- CAS Validation Filter -->
    <filter>
    <filter-name>CAS Validation Filter</filter-name>
    <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
    <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <!-- Votre page de réception de ticket -->
    <param-value>https://cas.mondomaine.fr/cas</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas</param-value> -->
    </init-param>
    </filter>
    <!-- CAS HttpServletRequest Wrapper Filter -->
    <filter>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
    </filter>
    <!-- CAS Assertion Thread Local Filter -->
    <filter>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class>
    </filter>
    <!-- CAS Filter for Shibb RemoteUser -->
    <filter-mapping>
    <filter-name>CAS Authentication Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Validation Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>>
    <filter-mapping>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>

    C'est dans le fichier : /opt/shibboleth-identityprovider-2.x.x/src/main/webapp/WEB-INF/web.xml
    que vous devez reporter : /opt/shibboleth-idp/cas_web.xml. Pour ce faire, ajoutez le contenu du fichier "/opt/shibboleth-idp/cas_web.xml" juste en dessous de "</listener>"

  • Copiez le client CAS dans les bibliothèques des sources de Shibboleth :

    cp /opt/cas-client-3.x.x/modules/cas-client-core-3.x.x.jar /opt/shibboleth-identityprovider-2.x.x/lib/
  • Lancez la procédure d'installation :

    cd shibboleth-identitypovider-2.x.x
    chmod +x install.sh
    ./install.sh
  • Faites le choix d'installation :

    Where should the Shibboleth Identity Provider
    software be installed ? [/opt/shibboleth-idp]
    [Acceptez ce choix] the directory '/opt/shibboleth-idp' already exists.
    Would you like to overwrite this shibboleth configuration ?
    (yes, [no]) no => Naturellement c'est "no"

    C'est maintenant terminé, vous devez avoir en bas de votre terminal un message du type :

    BUILD SUCCESFUL
    Total time : 8 seconds
  • Synchronisez l'horloge :

    ntptime
  • Vérifiez la date :

    date
  • Relancez Shibboleth :

    /etc/init.d/tomcat start
  • Contrôlez le bon fonctionnement :

    tail -f /opt/shibboleth-idp/logs/idp-process.log

2.1) Procédure de mise-à-jour de la brique CAS-client

  • Téléchargez l'achive :

    wget http://www.ja-sig.org/downloads/cas-clients/cas-cl... -O /opt/cas-client-3.1.10-release.zip
  • Décompressez :

    cd /opt
    jar -xf cas-client-3.x.x-release.zip
  • Déplacez vous dans le répertoire :

    cd cas-client-3.x.x/cas-client-core
  • Compilez :
    mvn package
    /!\ Si vous avez une erreur => "Failed to resolve artifact"
    à propos du JAR org.opensaml:opensaml:jar:1.1b
    => Utilisez la version demandée ici 1.1b
  • Déplacez-vous ici :

  • Retournez dans le repertoire cas-client :

    cd cas-client-3.x.x/cas-client-core
  • Compilez avec la commande :

    mvn install :install-file -DgroupId=org.opensaml -DartifactId=opensaml -Dversion=1.1b\
    -Dpackaging=jar -Dfile=/opt/opensaml-1.1b.jar
  • Maintenant vous devez obtenir :

    "BUILD SUCCESSFUL"

    en bas de votre écran.

    Attention l'idp n'aura aucune connaissance de cette nouvelle version de CAS-client. Pour prendre en compte cette mise-à-jour vous devez faire l'upgrade de votre idp, cf. le paragraphe 2) Procédure de mise à jour de la brique Shibboleth-idp.

3) Procédure de mise-à-jour et d'installation de Tomcat

Je tiens à préciser qu'il est impératif de fonctionner avec Tomcat en version 6 au minimum. La version 5.5 rien ne marchera pas avec la plupart des navigateurs hormis mozilla-firefox, puisqu'il y a un problème de compatibilité avec les COOKIES. Dans certain cas Tomcat6 n'est pas proposé avec les distributions stables de linux, il faut donc récupérer une version binaire pré-compilée sur le site officiel de la fédération Apache.

L'installation n'a rien de compliqué mais nécessite de prendre quelques précautions pour éviter de donner un accès global au serveur. J'indique ici comment mettre Apache2.2 en frontal de Tomcat6 avec une configuration optimale, aussi bien pour Apache2.2 que pour Tomcat6.

En résumé, Apache2.2 constitue la porte d'entrée et de sortie vers l'extérieur. Apache communique directement avec Tomcat via un proxy accessible uniquement depuis la boucle locale. Tomcat s'occupe juste d'exécuter les applications web Java (webapps). Ici il est question de "idp.war".

C'est donc Tomcat6 qui doit avoir les droits nécessaires de lecture des fichiers de configuration et d'écriture des logs de Shibboleth. De façon à soulager Tomcat, la gestion de SSL/TLS est prise en charge par Apache2.2.

Voici la procédure à suivre :

  • Emplacement de réception :

    cd /opt/
  • Récupérez l'archive "

    wget ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x... -O /opt/apache-tomcat-6.x.xx.tar.gz
  • Décompressez l'archive :

    cd /opt
    tar zxvf apache-tomcat-6.x.xx.tar.gz
  • Supprimez les binaires et scripts pour windows :

    cd apache-tomcat-6.x.xx
    rm bin/*.exe bin/*.bat
  • Créez un lien symbolique par commodité :

    cd /opt
    ln -s /opt/apache-tomcat-6.x.xx tomcat
  • Activez le connecteur PROXY AJP pour Tomcat :

    Ajoutez à la section <Service name="Catalina"> du fichier /opt/tomcat/conf/server.xml le connecteur comme ci-dessous :

    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
  • Commentez le connecteur sur le port 8080 dans le fichier /opt/tomcat/conf/server.xml :

    <!--
    <Connector executor="tomcatThreadPool"
    port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />
    -->
  • Supprimez les webapps de base offerts avec Tomcat :

    rm -rf /opt/tomcat/webapps/*
  • Ajoutez la webapp Shibboleth-idp dans le fichier /opt/tomcat/conf/Catalina/localhost/idp.xml

    <Context
    docBase="/opt/shibboleth-idp/war/idp.war"
    privileged="true"
    antiRessourceLocking="false"
    antiJARLocking="false"
    unpackWAR="false" />

    Remarque : vous pouvez ajouter l'attribut autoDeploy="true". Dans ce cas l'application sera chargée au lancement de Tomcat.

  • Par mesure de sécurité, supprimez les utilisateurs qui peuvent s'authentifier sur Tomcat :

    Retirez simplement le contenu de l'instance : tomcat-users dans le fichier /opt/tomcat/conf/tomcat-users.xml comme ci-dessous :

    <?xml version="1.1" encoding='utf-8 ?>
    <tomcat-users>
    </tomcat-users>
  • Lancez Tomcat au démarrage :

    Aucun script "System V" n'est fourni avec la distribution de Tomcat. Vous allez donc devoir en créer un. Par ailleurs ce procédé permet de simplifier la maintenance, mais aussi d'assurer le lancement automatique de Tomcat au démarrage du serveur. Cela permet aussi d'en profiter pour initialiser les variables d'environnement.

    Créez le fichier /etc/init.d/tomcat comme ci-dessous :

    #!/bin/sh

    RETVAL=$?
    JAVA_HOME=/usr/lib/jvm/java-6-sun
    JAVA_OPTS="-Xmx1000m -XX:MacPermSize=512m"
    CATALINA_HOME=/opt/tomcat
    IDP_HOME=/opt/shibboleth-idp

    export JAVA_HOME
    export JAVA_OPTS
    export CATALINA_HOME
    export IDP_HOME

    case "$1" in
    start)
    if [ -f $CATALINA_HOME/bin/startup.sh ];
    then
    echo $"Starting Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/startup.sh
    fi
    ;;
    stop)
    if [ -f $CATALINA_HOME/bin/shutdown.sh ];
    then
    echo $"Stoping Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/shutdown.sh
    fi
    ;;
    *)
    echo $"Usage: $0 {start|stop}"
    exit 1
    ;;

    exit $RETVAL

    Maintenant il ne reste plus qu'à positionner le script dans les differents niveaux de démarrage comme ci-dessous :

    chmod 755 /etc/init.d/tomcat
    update-rc.d tomcat default
  • Lancez Tomcat avec un utilisateur spécifique :

    Il est préférable de lancer Tomcat avec un utilisateur spécifique avec des privilèges limités. Le script suivant vous aidera à le créer :

    #!/bin/sh

    if ! id tomcat > /dev/null 2>&1 ; then
    adduser --system --home /opt/tomcat --no-create-home \
    --ingroup nogroup --disable-password --shell /bin/false \
    tomcat
    fi

4) Configuration de Apache2.2 (Lenny/Debian)

  • Activez les ports d'écoute dans le fichier :

    /etc/apache2/ports.conf

    Vérifiez que Apache écoute bien les deux ports comme ci-dessous :

    Listen 443
    Listen 8443
  • Configurez vos deux accès :

    - Créez le fichier /etc/apache2/sites-available/idp ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:443>
    ServerName idp.mondomaine.fr:443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /etc/ssl/certs/idp.mondomaine.fr.pem
    SSLCertificateKeyFile /etc/ssl/private/idp.mondomaine.fr.key
    SSLCertificateChainFile /etc/ssl/certs/globalsign_ct_root.pem
    SSLCACertificateFile /etc/ssl/certss/sureserverEDU.pem
    SSLOptions +StdEnvVars

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all

    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

    - Créez le fichier /etc/apache2/sites-available/idp-aa ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:8443>
    ServerName idp.mondomaine.fr:8443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt
    SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key
    SSLVerifyDepth 10
    SSLOptions -StdEnvVars +ExportCertData

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all
    </proxy>
    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

  • Activez les deux accès :

    a2ensite idp idp-aa
  • Activez le module ssl :

    a2enmod ssl
  • Activez le module proxy_ajp :

    a2enmod proxy_ajp
  • Relancez le server Apache2:

    apache2ctl -t
    apache2ctl -k restart

5) Configuration de Shibboleth-idp

Il s'agit de la configuration principale et donc celle que vous devrez utiliser pour administrer Shibboleth. Elle se trouve dans deux fichiers :

- Fichier de génération d'attributs : /opt/shibboleth-idp/conf/attribute-resolver.xml

Ce fichier est nécessaire pour configurer les connecteurs, LDAP, BDD et Statique. Il sera aussi très pratique pour déterminer les attributs nécessaires aux ressources.

- Fichier de contrôle de la propagation d'attributs : /opt/shibboleth-idp/conf/attribute-filter.xml

Ce fichier détermine quels attributs seront fournis aux ressources.

Le support technique Renater offre des fichiers d'exemples qui servent de base à la fédération. Pour une utilisation classique, il faut naturellement changer la configuration des connecteurs et filtrer la propagation des attributs, le but étant d'avoir le contrôle de son fournisseur d'identités.
Fichiers de configuration d'exemples Renater : https://services-federation.renater.fr/exemples/co...

5.1) attribute-resolver.xml

Modifiez attribut-resolver.xml à partir de la section "Data connectors" comme ci-dessous :
(Ces connecteurs sont obligatoires pour mondomaine.fr)

<resolver:DataConnector id="StaticAttributes"
xsi:type="Static"
xmlns="urn:mace:shibboleth:2.0:resolver:dc">

<Attribute id="eduOrgLegalName">
<Value>
Idp MonDomaine.fr
</Value>
</Attribute>

<Attribute id="EduPersonEntitlement">
<Value>
urn:mace:dir:entitlement:common-lib-terms
</Value>
</Attribute>

</resolver:DataConnector>

<resolver:DataConnector id="votreLDAP"
xsi:type="LDAPDirectory"
xmlns:"urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://ldap.mondomaine.fr"
baseDN="ou=people,dc=mondomaine,dc=fr"
principal="cn=cri,ou=services,dc=mondomaine,dc=fr"
principalCredential="VotreMotDePasse">

<FilterTemplate>
<![CDATA[
(uid=$requestContext.princpalName)
]]>
</FilterTemplate>

</resolver:DataConnector>

<resolver:DataConnector id="computedID"
xsi:type="ComputedID"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
generatedAttributeID="computedID"
sourceAttributeID="uid"
salt="VotrePointeDeSel">

<resolver:Dependency ref="votreLDAP" />

</resolver:DataConnector>

5.2) attribute-filter.xml

Ce fichier est indispensable pour l'ajout d'un fournisseur de services. Les fournisseurs de services mentionnés dans ce fichier seront accessibles. Voici un exemple pour ajouter un fournisseur de services :

  • Déplacez vous dans la partie suivante :

    <AttributeFilterPolicy id="releaseAttributesToSelectedSP">
  • Ajoutez le fournisseur dans "PolicyRequirementRule" :

    <PolicyRequirementRule xsi:type="basic:OR">
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_a" />
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_b" />

    <!-- Mettez à la suite les fournisseurs de services -->
    <!-- Remplacez url_fournisseur_a par l'url de votre fournisseur
    exemple http://www.cairn.info
    -->
    </PolicyRequirementRule>

  • Les paramètes suivants sont les attributs propagés aux fournisseurs url_fournisseur_x :

    <!-- Ex nom complet sans accent d'une personne -->
    <AttributeRule attributeID="commonName">
    <PermitValue xsi:type="basic:ANY" />
    </AttributeRule>

    <!-- Ex nom complet avec accents -->
    <AttributeRule attributeID="DisplayName">
    <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>

  •  Attention Pour que vos modifications soient appliquées il faut impérativement relancer Tomcat.
    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

6) Droits d'accès et sécurité

Les droits d'accès peuvent être réglés avec beaucoup de souplesse. Voici un ensemble de règles pour protéger le service et les informations sensibles.

6.1) Shibboleth-idp

Shibboleth doit être accessible par Tomcat :

chown -R tomcat logs metadata credentials
chmod 755 logs metadata
chmod 750 credentials
chown tomcat conf/attribute-filter.xml
chmod 660 conf/attribute-filter.xml

chmod 444 /opt/shibboleth-idp/credentials/metadata-federation-renater.crt
chown tomcat /opt/shibboleth-idp/credentials/idp.key
chgrp root /opt/shibboleth-idp/credentials/idp.{key,crt}
chmod 440 /opt/shibboleth-idp/credentials/idp.key
chmod 644 /opt/shibboleth-idp/credentials/idp.crt

6.2) Tomcat

D'origine les droits sont bien réglés, mais assurez-vous que l'utilisateur "tomcat" est bien le propriétaire de :

/opt/tomcat

chown -R tomcat /opt/tomcat

6.3) Certificat SSL Apache

Les certificats SSL permettent d'identifier le serveur via une procédure de signature. Les échanges d'identités entre les utilisateurs et les ressources seront chiffrées. Protégez vos certificats :

chown root:root /etc/ssl/private/idp.mondomaine.fr.key
chmod 640 /etc/ssl/private/idp.mondomaine.fr.key

chown root:root /etc/ssl/certs/globalsign_ct_root.pem
chown root:root /etc/ssl/certs/idp.mondomaine.fr.pem
chown root:root /etc/ssl/certs/sureserverEDU.pem

chmod 640 /etc/ssl/certs/globalsign_ct_root.pem
chmod 640 /etc/ssl/certs/idp.mondomaine.fr.pem
chmod 640 /etc/ssl/certs/sureserverEDU.pem

 Attention Remarque : le prestataire qui assure la sécurité des certificats peut changer. Ce qui précède est donc valable jusqu'à la réception de nouveaux certificats (sauf si vous passez par GlobalSign).

Veuillez prendre note des modifications suivantes pour les nouveaux certificats.

  • Afin de simplifier la gestion des certificats, réalisez un document.cnf : /etc/ssl/idp.mondomaine.cnf. Ce document permet de conserver les paramètres utilisés lors de la création du certificat requête.

    Ci-dessous son contenu :

    [req]
    default_bits = 1024
    default_keyfile = idp.mondomaine.fr.key
    distinguished_name = req_distinguished_name
    prompt = no

    [ req_distinguished_name ]
    C = FR
    O = Mon Etablissement
    CN = idp.mondomaine.fr
    emailAddress = idpmaster [at] mondomaine [dot] fr

  • Maintenant si vous voulez générer un certificat requête avec votre clé privée correspondante, vous pouvez utiliser le script ci-dessous (fichier /root/bin/req) :

    #!/bin/sh
    # Fourni dans le répertoire courant :
    # la clé (pour Apache)
    # idp.mondomaine.fr.key
    # le certificat requête (pour votre RSSI)
    # idp.mondomaine.fr_req.pem
    openssl req -new -nodes -out idp.mondomaine.fr_req.pem\
    -config /etc/ssl/idp.mondomaine.fr.cnf

  • Vous devez remplacer la clé "RSA PRIVATE KEY" par la nouvelle clé :

    cat ./idp.mondomaine.fr.key > /etc/ssl/private/idp.mondomaine.fr.key
  • Pour terminer, il faut remplacez les chaines de certificats. Vous devez adapter les chaînes de certificats selon votre prestataire.

6.4) Ajoutez des certificats non valides

Malheureusement un bon nombre d'aministrateurs n'utilise pas SSL dans les règles de l'art. Les serveurs mal administrés ne sont pas considérés comme dignes de confiance et Java ou les navigateurs internet n'accepteront pas les connexions avec ces serveurs. Pour résoudre ce problème et forcer Java à utiliser ces serveurs, vous devez ajouter manuellement les certificats dans son KeyStore de la façon suivante :

  • Téléchargez le programme Java suivant :

  • Compilez le programme :

    javac InstallCert hostname

     Attention Pour mondomaine.fr hostname=cas.mondomaine.fr

  • On vous demande d'ajouter les certificats. Ajoutez les tous.

    Enter certificate to add to trusted keystore or 'q' to quit: [1]

     Attention 1 pour certificat numéro 1, recommancez autant de fois que vous avez des certificats, cf. le paragraphe 3).

  • Copiez le KeyStore Java "jssecacerts" crée dans le répertoire courant ici :

    cp jssecacerts $JAVA_HOME/jre/lib/security
  • Vérifiez les droits ou fixez les :

    chown root:root $JAVA_HOME/jre/lib/security/jssecacerts
    chmod 644 $JAVA_HOME/jre/lib/security/jssecacerts
  • Pour finir, relancer Tomcat :

    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

    Remarque : si vous souhaitez que ces certificats soient reconnus comme de "confiance" par toutes vos applications Java et pas seulement JSSE, écrasez "cacert" avec "jssecacerts".

Fiche logiciel validé
  • Création ou MAJ importante : 11/04/13
  • Correction mineure : 11/04/13
  • Rédacteur de la fiche : Romaric David - Direction Informatique - Pôle HPC (Université de Strabourg)
  • Relecteur(s) : Sylvain Faure (Laboratoire de Mathématiques Orsay)
  • Responsable thématique : Geneviève Romier (Institut des Grilles et du Cloud)
Mots-clés

Maui : gestionnaire de batch

  • Site web
  • Système : UNIX-like
  • Version évaluée : 3.2.6p21
  • Langue(s) de l'interface : anglais
  • Licence : Autre

    Licence dite "End User Open Source". Attention, comme indiqué par l'éditeur, la licence n'est pas open source, par exemple, usage non commercial requis !!!

    "The software license allows end-user organizations to freely use, support, modify, and distribute the code for non-commercial purposes. The license may not meet the strict definitions of open source as defined by some organizations. Read the full license for details."

Description
Fonctionnalités générales

MAUI est un ordonnanceur capable de se coupler avec différents gestionnaires de ressources, comme SGE, Torque ou Slurm.
En tant qu'ordonnanceur, le rôle de MAUI est de mettre en œuvre les politiques d'exploitation des ressources de calcul, en pilotant les gestionnaires de ressources.

De manière macroscopique, les politiques d'exploitation s'appuient sur le calcul des priorités des jobs remontés via le gestionnaire de ressources. Ainsi, à chaque étape d'ordonnancement, les ressources disponibles sont affectées selon l'ordre des priorités calculées par l'ordonnanceur.

Plus précisément, dans MAUI, le calcul des priorités prend la forme d'une somme pondérée de termes. Certains de ces termes sont fixes (comme par exemple la priorité absolue donnée à un groupe d'utilisateurs), d'autres sont variables, comme par exemple le temps passé en file d'attente.

Les politiques d'exploitation disponibles dans MAUI permettent de :

  • répartir de manière équitable la puissance de calcul entre utilisateurs ou au au contraire, favoriser certains utilisateurs, en priorité ou en historique d'utilisation ;
  • favoriser des profils d'applications (grosses applications parallèles) ;
  • prendre en compte certaines topologies de machines (sous-clusters faiblement interconnectés) ;
  • effectuer des réservations des ressources en permanence ou sur un intervalle de temps donné. Cela permet à l'ordonnanceur d'utiliser à plein ces ressources jusqu'au début de la réservation, et à partir de la fin de celle-ci, de manière totalement automatique (mode jour/nuit, semaine/week-end par exemple) ;
  • mettre en place des files préemptives sur d'autres (1 seul niveau de préemption) ;
  • affecter des priorités différentes à un job provenant d'un utilisateur donné, selon la file dans lequel il est affecté. Par exemple, certains utilisateurs peuvent n'être très prioritaires que dans certaines files, et pas dans toutes.
Autres fonctionnalités

MAUI permet également de conditionner l'attribution de ressources à un crédit suffisant. Par exemple, un groupe n'ayant acheté qu'un nombre donné d'heures de calcul ne pourra plus lancer de nouveaux travaux une fois ce nombre atteint.
Pour cela, MAUI se couple avec des gestionnaires d'allocation comme Gold ou QBank. Il reste à vérifier si ce contexte d'utilisation est très fréquent. L'auteur de la présente fiche utilise Gold uniquement pour disposer d'un accounting des jobs dans une base de données.

Interopérabilité

MAUI peut se coupler avec plusieurs gestionnaires de ressources, dont SGE, Torque et Slurm.

Contexte d'utilisation dans mon laboratoire/service

MAUI est l'ordonnanceur utilisé sur le méso-centre de l'université de Strasbourg. Nous l'utilisons pour restituer à des laboratoires de recherche ayant acheté des nœuds leur quote-part d'heures CPU. Notre configuration s'appuie sur la notion de "Qualité de service" (QoS) associée à des groupes ou listes d'utilisateurs et à des files d'attente identifiées.
MAUI nous permet d'atteindre des taux de charge instantanées de 100%.
Nous avons présenté notre utilisation de MAUI à l'occasion de l'édition 2011 des JRES : https://conf-ng.jres.org/2011/document_revision_16...

Limitations, difficultés, fonctionnalités importantes non couvertes

La documentation de MAUI est très incomplète. Une grande partie des éléments décrits dans la documentation de MAUI le sont mieux encore dans la documentation de MOAB, ordonnanceur commercial issu de MAUI. En particulier, nous avons souvent dû croiser les 2 documentations dans la mise en place de nos QoS. La documentation de MOAB détaille certains éléments non documentés du coté MAUI. La documentation comporte également des erreurs sur des mots-clés, erreurs corrigées dans la documentation de MOAB.

Toute la configuration de MAUI repose sur un fichier peu lisible. Comme certaines données (par exemple les ressources associées à des nœuds de calcul) peuvent être indiquées à la fois dans la configuration du gestionnaire de ressources et de l'ordonnanceur, il faut choisir où écrire ces éléments de configuration, ce qui n'est pas évident lorsque l'on démarre avec MAUI.
De plus, une grande partie des valeurs par défaut sont contre-intuitives.

La gestion des GPU (ou autres ressources génériques comme les licences logicielles) n'est pas fonctionnelle dans MAUI : s'il est possible au niveau du gestionnaire de ressources d'associer des GPU à un serveur de calcul, cette information n'est pas utilisée à l'ordonnancement, c'est-à-dire lors du choix des machines. Un patch posté sur la liste de diffusion permet de corriger ce défaut.

De plus, l'auteur de la fiche constate des limitations dans la "scalabilité" et la robustesse du produit au delà d'une centaine de serveurs de calcul intégrés. Pour ces raisons, une migration vers Slurm a été réalisée.

L'auteur déconseille à ce jour le choix de MAUI comme gestionnaire de batch.

Environnement du logiciel
Plates-formes

Unix, Linux

Logiciels connexes
Autres logiciels aux fonctionnalités équivalentes
  • MOAB produit commercial de la même entreprise. Voir les différences
  • PBS Pro, voir le site de PbsWorks, qui couple gestionnaire de ressources et ordonnanceur (commercial)
  • Platform HPC, sur le site de Platform (commercial)
  • LoadLeveler d'IBM, Tivoli Workload Scheduler LoadLeveler
Environnement de développement
Type de structure associée au développement

L'entreprise Cluster Resources, Inc gère le développement et propose le produit commercial MOAB

Eléments de pérennité

Attention, la licence de MAUI ne permet pas l'usage commercial. il ne s'agit donc pas d'un produit Open Source ou libre. L'éditeur vend également un produit "pro" aux fonctionnalités très proches. Il n'est donc pas impossible que l'éditeur change de politique et ferme un jour son produit MAUI dans une version ultérieure ou encore ne le fasse plus vraiment évoluer.

Références d'utilisateurs institutionnels

U.S. Department of Energy, PNNL, the Center for High Performance Computing at the University of Utah (CHPC), Ohio Supercomputing Center (OSC), University of Southern California (USC), SDSC, MHPCC, BYU, NCSA sont cités par l'éditeur

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur
Divers (astuces, actualités, sécurité)

Ne pas hésiter à consulter la documentation de Moab, qui contient un grand nombre d'informations applicables à MAUI ...

Contributions

Contacter developers [at] supercluster [dot] org

Mots-clés

CDD admin-dev WEB PLUME

PLUME (CNRS) recrute un informaticien Bac + 3 ou plus, pour de l'Administration et Développement Web sur la plate-forme PLUME (CMS Drupal). CDD de 6 mois renouvelable un an à Paris ou Lyon ou Grenoble à partir du 16 août 2010 : description du poste.

Fiche logiciel validé
  • Création ou MAJ importante : 10/07/13
  • Correction mineure : 02/06/14
Mots-clés
Pour aller plus loin
  • Fiches logiciel PLUME connexes : , ,

rsyslog : gestionnaire de journaux système (logs)

Description
Fonctionnalités générales

rsyslog est un gestionnaire de traces (logs) produites par les systèmes informatiques de type Linux, BSD et Sun Solaris.
Il permet de gérer la journalisation des événements produits par le système, ses services et les divers logiciels, de manière sécurisée. Il comprend de nombreuses fonctionnalités et sa configuration permet une organisation très fine des flux. Il est en outre compatible avec les anciennes versions de syslog et syslog-ng.

Une interface Web (phpLogCon/LogAnalyzer) peut être utilisée pour visualiser toutes les données en ligne.

Autres fonctionnalités
  • Filtrage et format de fichier entièrement configurable
  • Stockage des logs dans des bases de données SQL (de type MySQL ou PostgreSQL)
  • Envoi d'alertes par email à partir de filtres sur les logs
  • Possibilité de spool sur disque avant envoi vers un serveur centralisé
  • Transmission des logs via TCP et UDP
  • Possibilité de cryptage des flux en TLS/SSL
  • Compatible syslog, syslog-ng, il permet également de recevoir les eventlog des systèmes Windows (via un agent tiers)
Interopérabilité
  • compatible avec le format standard syslog
  • peut fonctionner avec MySQL ou PostgreSQL
  • logcheck, http://logcheck.org (utilitaire pour synthétiser et consulter les logs produits)
Contexte d'utilisation dans mon laboratoire/service

rsyslog version 4.4.2 est utilisé au laboratoire LaMCoS sur un serveur de centralisation de logs et sur tous les postes Linux.

Environnement du logiciel
Distributions dans lesquelles ce logiciel est intégré

La plupart des distributions Linux proposent rsyslog comme gestionnaire de "logs" par défaut : Fedora > 8, OpenSUSE > 11.x, RedHat Enterprise > 5.2, SUSE Enterprise > 11, Debian > 5, Mandriva > 2008, Ubuntu, BSD, Sun Solaris.

Cependant, on peut noter des différences de versions de rsyslog selon les distributions de Linux. Notamment à ce jour (juin 2013), Debian wheezy propose la version 5.8 de rsyslog.

Il faut noter aussi une nouvelle branche de développement de rsyslog, 7.4, dont la justification est expliquée ici. Celle ci est proposée dans la dernière Fedora mais la plupart des distributions de Linux embarquent encore les versions 5.

Logiciels connexes
Autres logiciels aux fonctionnalités équivalentes
Environnement de développement
Type de structure associée au développement

Le projet a été créé en 2003 par Rainer Gerhards et reste maintenu par lui (voir historique du projet).

Eléments de pérennité

rsyslog est devenu le daemon syslog par défaut sous Debian, Ubuntu, Fedora, OpenSUSE, Mandriva.
Il est soutenu par divers organismes : http://www.rsyslog.com/sponsors

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur
Divers (astuces, actualités, sécurité)

Services de transfert de fichiers volumineux

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 24/08/11
  • Correction mineure : 10/06/13
Mots-clés

Services de transfert de fichiers volumineux

  • Type de ressource : service
  • Date de publication du document ou de l'événement : Mars 2010

Cette fiche est destinée à faire connaître et répertorier les services de transferts de fichiers volumineux.

On a recours à de tels types de services lorsqu'on veut échanger des fichiers dont la taille dépasse les volumes traditionnellement pris en compte par les services de messagerie. En effet, les passerelles de messageries acceptent en général des pièces jointes dont le volume n'excède pas quelques dizaines de méga octets dans le meilleur des cas.
Or, en milieu professionnel comme privé on peut être amené à vouloir échanger des fichiers de plusieurs centaines de mega-octets (des vidéos professionnelles, des images ISO, des archives .zip ou .tar...).

Il est alors nécessaire d'avoir recours à des services de "transferts de gros fichiers". Ces services sont la plupart du temps en relation avec un serveur Web (ils fonctionnent dans un simple environnement LAMP (Linux/Apache/MySQL/Php).) et permettent à travers un formulaire de s'authentifier, puis de déposer un fichier volumineux dans un espace protégé, secret et invisible dans l'espace du serveur web

L'URL de cet espace secret qui contient le fichier à transférer, est alors communiqué par mail au demandeur qui a le choix de l'envoyer a son correspondant. Le correspondant reçoit alors par mail un message contenant l'URL pointant vers le fichier à récupérer. Il n'a plus qu'a cliquer sur le lien pour transférer et récupérer le fichier par http ou ftp.

Un certain nombre de fournisseurs d'accès Internet propose ce type de services de transfert de gros fichiers comme par exemple
- Free http://dl.free.fr/
- Wanadoo http://www.orange.fr/bin/frame.cgi?u=http%3A//mesd... (après connexion à votre compte personnel)
- OVH propose également ce type de service depuis peu: http://www.zebulon.fr/actualites/5435-ovh-transfer... - http://demo.ovh.com/

Mais on trouve également des produits libres (Open Source) d'installation assez facile et administrables, et qui prennent en charge ce type de services. Citons parmi les plus utilisés dans la communauté enseignement supérieur Recherche :
- FileX : http://www.projet-plume.org/fr/fiche/filex système de transfert de fichier par interface web
- FileZ : http://www.projet-plume.org/fr/fiche/filez dépôt et gestion de fichier partagés grâce à une URL unique
- BigFileSharing : http://www.projet-plume.org/fr/fiche/bigfilesharing transfert et partage de gros fichiers
- MySecureShell : http://www.projet-plume.org/fr/fiche/mysecureshell

Ces services ont des fonctionnalités plus ou moins semblables parmi lesquelles
* la mise en place de quotas par utilisateur.
* suivi du téléchargement sur le serveur grâce à une barre de progression.
* possibilité de détruire le fichier téléchargé ou bien destruction automatique au bout d'un certain temps
* statistiques des téléchargements
* notification de téléchargement
* quotas (taille max. d'un fichier + volume max. utilisé) par groupe/utilisateur (règles ldap ou regexp sur attributs)
* protection d'accès au document par mot de passe en option
* contrôle de la durée de disponibilité du document
* authentification via ldap ou CAS

  • pierre Fauret propose dans Plume un comparatif de ces divers outils : https://www.projet-plume.org/ressource/uploaders_c...

  • Denis Coupvent-Desgraviers signale également dans sa fiche MySecureShell que MySecureShell est un shell qui ajoute des fonctionnalités au serveur FTP sécurisé "sftp-server" du même projet (serveur FTP s’appuyant sur le protocole SSH). A partir de celui-ci, il est possible de mettre en œuvre simplement (1 seul fichier de configuration bien commenté + interface graphique) une solution de partage de fichiers volumineux en créant et en dédiant un ou des compte(s) chrooté(s) (pas de navigation possible à travers les autres comptes utilisateurs) accessible(s) par Internet. La connexion de tous les utilisateurs sur le serveur étant cryptée, le dépôt des fichiers est sécurisé et se fait via un client FTP supportant le SSH (ex : FileZilla est multiplateforme).

  • Dans le cadre de ces services de transfert de fichiers, Christian Helft note également une série de produits logiciels "commerciaux" intéressants comme dropbox plutôt orientés vers la synchronisation de dossiers en réseau à distances, et qui donc par extension peut également servir d'upload et de transfert de gros fichiers.

dropbox est extrêmement bien intégré dans les OS Windows, MacOS X et diverses distributions Linux. En plus de la fonction de synchronisation et de génération d'url privées pour les gros fichiers, il fait également de l'archivage. Cependant c'est un logiciel gratuit jusqu'à 2 Go de fichiers déposés, et payant au-delà.

si vous avez d'autres expériences sur ce type de logiciel, contactez moi...afin qu'on enrichisse la fiche descriptive

Fiche logiciel validé
  • Création ou MAJ importante : 05/03/12
  • Correction mineure : 02/01/14
  • Rédacteur de la fiche : Romaric David - Univ Strasbourg - Direction Informatique - Pôle HPC (Université de Strasbourg)
  • Relecteur(s) : Teresa Gomez-Diaz (LIGM)
  • Responsable thématique : Maurice Libes (OSU Institut Pytheas - UMS 3470 CNRS)
Mots-clés
Pour aller plus loin
  • Fiches logiciel PLUME connexes :

SystemImager : déploiement automatique et mise à jour de systèmes Linux

Description
Fonctionnalités générales

SystemImager permet d'automatiser l'installation et la mise à jour d'un parc de machines tournant sous systèmes Linux. Il s'apparente à un logiciel de clonage pour systèmes Linux. SystemImager s'appuie sur "rsync" et travaille au niveau "fichier" et non pas au niveau "bloc disque". Les installations d'images se font totalement automatiquement via le réseau avec les protocoles pxe et tftp.

SystemImager fournit un ensemble de scripts permettant de créer une image de base à partir d'un PC de référence (appelé le golden client) et de la déployer sur d'autres PC.

Une image de base est un système Linux avec toutes ses personnalisations (configuration, logiciels non packagés, ...) réalisée sur une machine de référence (le "golden client").
À l'aide des scripts fournis par SystemImager, on peut déployer cette image de manière automatique sur un ensemble d'autres PC, qui peuvent être identiques ou pas. En effet Systemimager permet d'adapter les images à des machines spécifiques, en décrivant les différences entre l'image "de base" et celle devant être installée sur une machine donnée.

Le déploiement des images peut être réalisé en mode Multicast ou avec le protocole Bittorrent ce qui permet de déployer "n" images quasiment simultanément dans un temps dépassant à peine celui de l'installation d'un seul PC.

Les commandes de base de SystemImager permettent :
- de créer l'image de base sur le PC de référence (si_prepareclient)
- d'aspirer le système de référence du "golden client" sur un serveur d'installation (si_getimage)
- de créer automatiquement le script d'installation de cette image
- d'associer un nom de machine à un script (si_addclient)
- de configurer pxe pour diriger l'action à entreprendre lors du prochain démarrage d'une machine : installation réseau ou boot local (si_mkclientnetboot)
- de mettre à jour l'image du système de référence sur le serveur d'installation (si_updateclient)
- de mettre à jour sans ré-installation, le système installé sur les machines à partir de l'image de référence disponible sur le serveur

L'accès à distance aux machines par IPMI n'est pas pris en charge par systemImager, il faut réaliser l'intégration soi-même.

Autres fonctionnalités
  • Déploiement des images avec les protocoles Multicast ou Bittorrent. Des "benchmarks" montrent qu'on peut déployer plusieurs centaines de noeuds en 15 minutes sur un réseau gigabits.

  • SystemImager propose une interface graphique pour surveiller l'installation des PC clients : http://wiki.systemimager.org/index.php/Monitoring

  • Gestion des variantes systèmes via la notion de cluster

Interopérabilité
  • SystemImager travaille avec rsync au niveau "fichier" et fonctionne avec tous les systèmes Linux sur architecture x86-64.
Contexte d'utilisation dans mon laboratoire/service
  • SystemImager est fréquemment utilisé dans le déploiement de noeuds dans les clusters de calcul : nous l'utilisons au Méso-centre de calcul de l'Université de Strasbourg (http://hpc.unistra.fr), gestion de 130 machines, 1 image de référence et 2 variantes.

Nous utilisons beaucoup la mise à jour des systèmes en ligne, sans ré-installation de ceux-ci.

Limitations, difficultés, fonctionnalités importantes non couvertes
  • SystemImager ne fonctionne qu'avec des système Linux. Il ne sert pas à déployer des systèmes Windows

  • SystemImager nécessite de configurer des serveurs complémentaires pour fonctionner correctement comme pxe, tftp, dhcp, dns. La configuration de l'ensemble du système de clonage peut demander un certain temps de mise au point avant d'obtenir un résultat satisfaisant.

  • Systemimager déploie le noyau du système de référence. Lorsque l'on ajoute des matériels récents, il faut s'assurer que l'ensemble des périphériques soient bien reconnus. En général nous rencontrons des problèmes avec les contrôleurs disques et les cartes réseau. Pour les contourner, nous attribuons le rôle de système de référence au serveur doté du matériel le plus récent.

  • Nous avons rencontré des difficultés de fonctionnement sur des distributions Ubuntu. Toutefois ces difficultés ne semblent pas partagées, cf http://www.howtoforge.com/how-to-back-up-an-ubuntu....

  • Le fonctionnement de SystemImager s'est avéré plus facile sur système CentOS.

Environnement du logiciel
Distributions dans lesquelles ce logiciel est intégré
Plates-formes
  • Fonctionne après modifications sur Ubuntu ou Debian-like, a fonctionné directement sous RedHat-Like (Centos). Non testé sous Fedora.
Autres logiciels aux fonctionnalités équivalentes
Environnement de développement
Type de structure associée au développement
Eléments de pérennité
  • SystemImager évolue régulièrement depuis presque dix ans. L'équipe de développement est très réactive via les mailing-list ou le canal IRC.
Références d'utilisateurs institutionnels
Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
  • sisuite-users [at] lists [dot] sf [dot] net - liste de support pour les utilisateurs
  • sisuite-devel [at] lists [dot] sf [dot] net - liste d'échange pour les développeurs
Documentation utilisateur
Fiche dév Ens Sup - Recherche
  • Création ou MAJ importante : 11/05/10
  • Correction mineure : 11/05/10
Mots-clés

RDVZ : mise en place de rendez-vous entre plusieurs personnes par sondage

Ce logiciel a été développé (ou est en cours de développement) dans la communauté de l'Enseignement Supérieur et de la Recherche. Son état peut être variable (cf champs ci-dessous) donc sans garantie de bon fonctionnement.
  • Site web
  • Système : UNIX-like
  • Version actuelle : 2.0.2 - 19/04/2010
  • Licence(s) : GPL, CeCILL
  • Etat : validé (au sens PLUME), diffusé, stable
  • Support : maintenu, développement en cours
  • Concepteur(s) : Centre des Ressources Informatiques - Université d'Avignon et des Pays de Vaucluse
  • Contact concepteur(s) : https://listes.univ-avignon.fr/wws/info/gpl
  • Laboratoire(s), service(s)... : Univ Avignon

 

Une fiche logiciel décrit plus en détail ce développement, consultez la pour plus d’informations : RDVZ
Fonctionnalités générales du logiciel

RDVZ permet la mise en place de rendez-vous entre plusieurs personnes par sondage en ligne.
L’organisateur crée sur un serveur avec une interface conviviale le sondage et les dates possibles puis communique l’URL du sondage aux participants. Chaque participant vote pour une date de réunion proposée par l’organisateur sur le serveur et dit si il est disponible ou non.
Cela permet de mettre en place un service de type Doodle Fiche Plume.

L’organisateur peut également exporter les résultats au format csv, et clore les votes. Il peut aussi recevoir un courrier électronique de notification à chaque vote.
La durée de vie du sondage est gérée dans le fichier de configuration.
L’application permet un accès anonyme uniquement pour le vote, et un accès authentifié (MySQL, CAS, LDAP) indispensable pour créer des rendez-vous.
Des documentations utilisateurs et développeurs sont disponibles en français et en anglais.

Contexte d’utilisation du logiciel

A l'IBGC (Bordeaux), RDVZ est utilisé depuis janvier 2009, une centaine de sondages sont créés par an. Simple d'utilisation et d'installation, il correspond à nos besoins. Nous avons choisi le mode d'authentification LDAP sans CAS. Suite aux retours des utilisateurs, quelques modifications ont été apportées.

Au sein de l'IEMN (Villeneuve d'Ascq, 59), RDVZ est utilisé depuis septembre 2008. La version en production sur la plate-forme d'hébergement est la version 1.1 (sur laquelle quelques modifs mineures ont été apportées). Plebiscité par nos utilisateurs pour sa simplicité d'utilisation, il a remplacé peu à peu Doodle dans notre unité (+ de 200 sondages crées depuis le lancement de l'outil). Point amusant, il est aussi détourné de sa fonction première (prise de rdv rapide) : utilisé parfois pour effectuer des votes électroniques sur des sujets non stratégiques.

Pour la partie authentification, nous avons fait le choix d'utiliser une base de comptes stockées dans MySQL (migration prochainement vers LDAP sans SSO-CAS). L'équipe informatique du LASIR (UMR CNRS 8516) a modifié le code source du produit pour utiliser les certificats électroniques X509 CNRS dans le processus d'authentification et l'a intégré dans sa charte graphique web.

Mis en place récemment au sein de la Maison René-Ginouvès, Archéologie et Ethnologie, la création de sondage est réservée aux membres des laboratoires de la Maison via une authentification CAS (JASIG) couplée au LDAP. Le vote, lui, est ouvert à tous les votants ayant reçu le lien adéquat et sans authentification.
Malgré cette mise en place récente, l’utilisation monte en charge rapidement. La seule modification au produit initial, mise à part la customisation graphique, est la suppression de la possibilité de laisser aux votants un commentaire global. Cette option modifiait la mise en page et générait des erreurs de manipulation de la part des votants.

RdvZ entame maintenant une seconde vie avec la version 2.0 : le développement a été entièrement refait à l'aide du framework PHP Symfony.
Nous avons notamment eu des retours de Centrale Marseille et de l'Inserm qui nous ont beaucoup aidé à corriger les différents bugs et problèmes pendant la beta.

Fiche dév Ens Sup - Recherche
  • Création ou MAJ importante : 10/05/10
  • Correction mineure : 19/05/11
  • Auteur de la fiche : Bruno Bzeznik (Projet CIMENT de l'Université Joseph Fourier)
  • Responsable thématique : Geneviève Romier (Institut des Grilles et du Cloud)
Mots-clés

CiGri : grille de calcul “légère”

Ce logiciel a été développé (ou est en cours de développement) dans la communauté de l'Enseignement Supérieur et de la Recherche. Son état peut être variable (cf champs ci-dessous) donc sans garantie de bon fonctionnement.
  • Site web
  • Système : UNIX-like
  • Version actuelle : 1.3 - Aout 2009
  • Licence(s) : GPL - v2
  • Etat : validé (au sens PLUME), diffusé, stable, en développement
  • Support : maintenu, développement en cours
  • Concepteur(s) : Bruno Bzeznik, Nicolas Capit, Olivier Richard, Elton Nicoletti Mathias, Yiannis Georgiou.
  • Contact concepteur(s) : Bruno.Bzeznik@imag.fr
  • Laboratoire(s), service(s)... : LIG, CIMENT (centre de calcul intensif des Universités Grenobloises)

 

Une fiche logiciel décrit plus en détail ce développement, consultez la pour plus d’informations : CiGri
Fonctionnalités générales du logiciel

CiGri permet de mettre en place une grille de calcul capable d'exploiter les ressources disponibles d’un ensemble de calculateurs préexistants. Il est spécialisé dans la gestion de grandes campagnes de jobs de type "bag-of-tasks" (sac de taches).

Par opposition à d'autres intergiciels de grille, comme Globus, gLite, etc., CiGri se veut un outil pour la mise en place de grilles de calcul dites "légères".

Voir plus d'informations sur la fiche logiciel Fiche Plume.

Contexte d’utilisation du logiciel

Le logiciel CiGri est utilisé sur toutes les grappes du mésocentre de calcul de l'Université Joseph Fourier (CIMENT) depuis 2002.

Publications liées au logiciel
  • Yiannis Georgiou, Olivier Richard, et Nicolas Capit.
    Evaluations of the lightweight grid cigri upon the grid5000 platform. In E-SCIENCE '07: Proceedings of the Third IEEE International Conference on e-Science and Grid Computing, pages 279-286, Washington, DC, USA, 2007. IEEE Computer Society.
  • Yiannis Georgiou, Nicolas Capit, Bruno Bzeznik, et Olivier Richard.
    Simple, fault tolerant, lightweight grid computing approach for bag-of-tasks applications. 3rd EGEE User Forum, 2008.
    Disponible à cette page : http://indico.cern.ch/contributionDisplay.py?contr....
  • Yvan Calas, Nicolas Capit, et Estelle Gabarron.
    Cigri : Expériences autour de l’exploitation d’une grille légère. JRES, 2005.
    Disponible ici : http://2005.jres.org/paper/90.pdf.
  • F. Dupros, F. Boulahya, J. Vairon, P. Lombard, N. Capit, et J-F. Méhaut.
    Iggi, a computing framework for large scale parametric simulations: Application to uncertainty analysis with toughreact. TOUGH Symposium, 2006.
    Disponible ici : http://esd.lbl.gov/TOUGHsymposium/pdf/Dupros_IGGI.pdf.
  • J. Aoun, V. Breton, L. Desbat, B. Bzeznik, M. Leabadand, et J. Dimastromatteo.
    Validation of the Small Animal Biospace Gamma Imager Model Using GATE Monte Carlo Simulations on the Grid. In J. Montagnat S. D. Olabarriaga, D. Lingrand, editor, Proceedings of MICCAI-Grid Workshop Medical imaging on grids: achievements and perspectives, MICCAI-Grid Workshop, New York États-Unis d'Amérique, 2008.
Syndiquer le contenu