Category Archives: Français

Tuto Git – Commandes de base de partage des sources

Objectif: Revue complète, à l’aide un exemple concret, des commandes Git de base de de partage des sources d’un projet par deux ou plusieurs développeurs d’application. Pré-requis: Git est installé et confiiguré sur un système GNU/Linx, cf. article 1 de la serie Tuto Git.

1. Mise en place d’un environnement de simulation.

Dans cette serie de tutoriels on utilisera la simulation suivante sur une même machine: – Côté serveur: le dossier /serveurgit – Côté clients: les dossiers /pcdev1  /pcdev2 .. Pour un suivi plus simple de ce tutoriel vous pouvez ouvrir une console pour chaque PC développeur simulé. Créer les trois dossiers nécessaires: 
sudo mkdir /serveurgit
sudo chown login:login /serveurgit
 login: doit être votre login sur la machine utilisée. Faites la même chose pour les deux autres dossiers /pcdev1 et /pcdev2

2. Mise en place d’un dépôt de source sur le serveur.

Ce n’est pas dans l’objectif de ce tutoriel mais c’est une étape nécessaire pour la suite. Il s’agit d’une mise en place basique qui ne doit pas être utilisée dans la pratique. Sur le serveur (aller dans le dossier /serveurgit donc) créer un dépôt de source pour le projet “hello”. 
cd /serveurgit
git init --bare hello.git
“hello” est le nom choisi pour le projet (généralement le nom de l’application développée), l’extension “.git” n’est pas obligatoire mais c’est une bonne convention qui permet de reconnaitre le type du dépôt. Cette commande crée un dossier hello.git/. C’est la première chose à faire si on veut commencer à gérer un projet avec Git.

3. Récupération d’une copie de travail locale.

Sur le poste de travail, donc dans le dossier /pcdev1 (cd /pcdev1): 
git clone /serveurgit/hello.git
Cette commande “git clone” crée un dossier “hello/” dont le contenu est une copie locale du dépôt crée sur le serveur. Le paramètre de cette commande qui est un chemin sur le disque local, devrait être dans la réalité une URL tel que http://serveur/.. puisqu’il s’agit usuellement d’un serveur ditant.

4. Personnalisation de la configuration du projet.

A n’utiliser que si on souhaite avoir d’autres paramètres pour le projet que ceux configurés globalement dans l’article 1 de la serie. 
cd /pcdev1/hello
git config --local user.name "DEV1"
git config --local user.email "DEV1@server.com"
Ces deux commandes modifient le nom d’utilisateur et son adresse email seulement pour ce projet.

5. Ajout d’un fichier au projet

echo '#!/bin/bash' > /pcdev1/hello/hello.sh
echo 'echo "Boujour tout le monde !"' >> /pcdev1/hello/hello.sh
C’est un script shell qui affiche un message de bonjour. 
git status
On obtient un retour qui indique que le fichier nouvellement créée n’est pas suivi et nous suggère une commande qu’on va exécuter: 
git add hello.sh
Maintenant ce fichier est suivi (ou indexé) mais ce n’est pas suffisant: il faudra le valider (commit) et ensuite l’envoyer au serveur. Avant cela ajoutons un fichier de documentation du projet: 
echo 'Ce projet permet d'affichier bonjour dans plusieurs langues' > hello.doc
git add hello.doc
git status
Ce qui crée ce fichier et le rend suivi par git, la dernière commande le confirme. Maintenant on va publier ces ajouts en les envoyant au serveur: 
git commit -m "Création du projet Hello"
git push
git status
Ceci valide les deux fichiers en même temps et envoi le tout au serveur, la dernière commande le confirme.

6. Partage du projet

Le projet étant désormais dans le dépôt du serveur, le dévelopeur 2 peut y avoir accès: 
cd /pcdev2
git clone /serveurgit/hello.git
cd hello
ls -l
Ce qui permet de récupérer une copie de travail du projet sur le PC du 2eme développeur. Les deux dernières commandes permettent de s’assurer que le contenu est bien récupéré. Un peu plus d’information utile peut être obtenue par: 
git log
Et à présent on comprend mieux l’importance de la configuration effectuée et du message ajouté lors de la validation des fichiers.]]>

Outils developpement (web)

Leave a Reply

Objectif: Ce tutoriel présente les outils developpement (web) disponibles gratuitement et à utilisation totalement libre par chacun. Il s’agit d’une présentation d’un ordinateur (de bureau) type qui pourrait servir efficacement à créer des logiciels à l’aide de ces outils.

1. Le materiel.

Un PC très récent (et donc coûteux) n’est pas forcément nécessaire pour programmer et créer des logiciels. Même un PC moyen de 2012 suffirait. En cas de besoin de puissance (IDE récent gourmand en ressources, développement nécessitant de faire tourner plusieurs processus en même temps ..), priviligier un processeur récent et la quantité de mémoire RAM (8 Go suffirait à la configuration la plus exigeante). Le reste des composants n’a pas d’importance dans la majorité des cas: ecran, carte graphique, disque dur.

2. Le système d’exploitation.

GNU/Linux Ubuntu fait parfaitement l’affaire. Il est gratuit et libre. Actuellement cet OS est simple à installer (article à venir) et configure toute sorte de materiel automatiquement. En même temps sur cet OS il y a tout ce qu’il faut comme outils gratuits et libres pour développer des applications sur toute sorte de technologies (cf. les différents articles de ce blog à titre d’exemple).

outils-developpement-webDémarrage de l’IDE Eclipse «neon» sur un système KUbuntu 16.04

3. Les outils developpement (web).

 ]]>

Tuto Git – Installation et configuration de base

« Tuto git », basés sur la pratique. Vous apprendrez de manière progressive à manier les commandes essentielles vous permettant d’être rapidement opérationnels avec cet outil. Il est conseillé de suivre cette serie d’articles dans l’ordre.

  1. Cet article.
  2. Commandes de base de partage de fichiers.
  3. Modification de fichiers sans conflit.
  4. Gérer un conflit de modification simple.
  5. Gérer un conflit de modifications multiples.
  6. Gérer et suivre l’évolution des fichiers et projets.
  7. Utiliser les branches.
  8. Gestion avancée des branches.
  9. Utiliser Git avec eclipse
  10. Utiliser Git avec eclipse: publier, tagger, visualiser
Git est un outil de gestion de code source indispensable pour le développement d’applications logicielles. Ce tuto git basé sur la pratique vous permettra d’installer l’outil de gestion du code source Git et de le configurer correctement sur un système GNU/Linux Ubuntu ou compatible.

1. Rappel à propos des outils gestionnaires de code source.

Ces outils permettent principalement de:
  • Gérer l’évolution des fichiers (texte) de codes sources en gardant leur historique et permettant ainsi de revenir à une version antérieure à tout moment.
  • Gérer deux ou plusieurs branches d’évolution simultanées du projet (ensemble de codes sources) avec la possibilité de les fusionner à tout moment.
  • Partager le même projet entre plusieurs personnes (équipe de développement) sans risque de conflit de modification.
L’ensemble de ces fonctions est souvent appelé « gestion de configuration de logiciels » pour « software configuration management » (SCM). Il existe plusieurs outils libres tel que CVS (outil historique des logiciels libres), SVN, Git, Mercurial..

2. Installation de Git sur un système Ubuntu ou compatibles.

Exécuter la commande: 
sudo apt-get install git
Cette installation est valable côté client (machine du développeur), comme côté serveur (machine qui héberge le dépôt des sources). Il s’agit du même ensemble logiciel. Bien entendu la même machine peut servir de client et serveur en même temps mais ce n’est pas la configuration usuelle dans la pratique.

3. Configuration de base côté client.

Dans cette série de tutoriels Git on s’intéressera essentiellement au côté client, c’est à dire le côté du développeur. Le côté serveur est plutôt la charge d’administrateurs système. La configuration par défaut de Git permet un fonctionnement tout à fait correct. Dans la pratique une mise au point est toujours nécessaire pour l’utiliser convenablement.

a. Configuration informative.

Il s’agit de dire à Git de quel développeur il s’agit (nom et adresse email). 
git config --global user.name "Monprenom MONNOM"
git config --global user.email moi@meddeb.net
git config: est la commande de configuration de Git. –global : est le paramètre qui permet de manipuler le niveau utilisateur de la configuration.

b. Configuration des fichiers à ignorer.

Dans un projet logiciel certains fichiers ne doivent pas être conservés dans le dépôt de sources. Ces fichiers peuvent etre ceux de la configuration spécifique à un IDE tel que eclipse ou netbeans ou bien les fichiers résultats de la construction tel que les .class ou les .jar … Pour cela créer le fichier de configuration globale .gitignore_global: 
vi ~/.gitignore_global
Ce fichier contient une liste de paramètres, un paramètre par ligne. Ces paramètres peuvent être des noms de fichiers, des masques de noms ou des noms de dossiers. Par exemple: 
.project
.settings/
*.class
C’est à dire le fichier de configuration du projet eclipse .project, le dossier de configuration eclipse .settings/ et tout fichier java compilé .class. Ensuite exécuter la commande: 
git config --global core.excludesfile ~/.gitignore_global
Après cela aucun des fichiers conformes à la configuration ne sera envoyé au dépôt de source , ils seront ignorés. Cette configuration est valable pour tout les projets de l’utilisateur qui l’effectue. Elle peut toutefois être affinée par projet, cela sera traité dans la suite de cette série de tutoriels.]]>

Installer des packages personnels sur un système Ubuntu et compatibles

Objectif: installer des packages non officiels sur un système GNU/Linux Ubuntu ou compatibles, notamment Debian pour les machines serveurs. Le caractère non officiel des packages peut être la conséquence d’existence de licence particulière qui les rend non libres au sens strict. Le JRE/JDK d’Oracle se trouve dans ce cas. Avertissement: Certains packages disponibles dans des dépôts non officiels peuvent être dans un état instable ou existent pour des raisons expérimentales. Il convient de vérifier leur statut avant de les installer. 1. Installation standard L’installation de ces packages se fait de manière standard avec l’utilitaire en ligne de commande apt-get. 

sudo apt-get install oracle-java8-installer
Cette commande d’instillation du JDK Oracle version 8 ne fonctionne pas par défaut. Pour qu’elle fonctionne il faudra d’abord configurer la liste des dépôts de packages utilisables. 2. Configurer la liste des dépôts de packages Les packages du JDK d’Oracle se trouvent sur le site Launchpad: https://launchpad.net. Ils sont maintenus sur ce site par l’équipe Web Upd8: http://www.webupd8.org. Il s’agit d’un site qui héberge des PPA (Personal Packages Archives). Pour ajouter cet emplacement comme source des packages installables par apt-get, il faudra utiliser la commande: 
sudo add-apt-repository ppa:webupd8team/java
Cette commande veut dire ajouter à la liste des sources utilisables par apt-get le dépôt PPA de l’utilisateur webupd8team, catégorie java. Toutefois cette commande ne fonctionne pas par défaut (on peut avoir l’erreur « add-apt-repository: command not found »). Si c’est le cas, il faudra d’abord installer l’utilitaire add-apt-repository qui se trouve sur les dépôts officiels du Système Ubuntu ou compatibles. Cette installation se fait avec la commande: 
sudo apt-get install software-properties-common
Après l’ajout du dépôt ppa:webupd8team/java, il convient de mettre à jour le cache de l’utilitaire apt-get: 
sudo apt-get update
Après cela la commande d’installation des packages non standard invoquée en (1), fonctionnera.]]>

OpenLDAP password policy – Mieux sécuriser les comptes des utilisateurs

overlay) qui permet de mettre en place une gestion efficace des comptes d’authentification des personnes référencées dans l’annuaire OpenLDAP. Cette gestion concerne notamment les mots de passe de ces personnes. Cet article montrera la manière de configurer le serveur OpenLDAP pour activer le module « password policy » et mettre en place cette gestion. Pré-requis: L’article Ajouter des données à l’annuaire ainsi que ses pré-requis sont lus. On suppose, également, que le serveur OpenLDAP a été installé et alimenté avec les données de l’article. Pour aller plus loin à ce sujet: La démarche présentée ici constitue le volet système de bas niveau de cette fonctionnalité. L’expiration d’un compte (mot de passe), par exemple, nécessite la mise à disposition des utilisateurs finaux une interface pour modifier leurs mots de passe facilement.

1. Activer le schéma ppolicy (OpenLDAP password policy)

A l’installation du serveur OpenLDAP sur un système Debian ou compatible, le schéma ppolicy est installé: /etc/ldap/schema/ppolicy.ldif, mais il n’est pas activé. Pour l’activer: 
ldapmodify -x -a -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f /etc/ldap/schema/ppolicy.ldif
Pour vérifier le chargement effectif du schéma: 
ldapsearch -x -s one -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -b cn=schema,cn=config cn -LLL

dn: cn={0}core,cn=schema,cn=config
cn: {0}core

dn: cn={1}cosine,cn=schema,cn=config
cn: {1}cosine

dn: cn={2}nis,cn=schema,cn=config
cn: {2}nis

dn: cn={3}inetorgperson,cn=schema,cn=config
cn: {3}inetorgperson

dn: cn={4}ppolicy,cn=schema,cn=config
cn: {4}ppolicy
Remarquer la présence du schéma ppolicy en plus des quatre schémas activés par défaut.

2. Activer le module ppolicy

Créer le fichier de commande LDIF: ppolicy-module.ldif 
vi ppolicy-module.ldif
Saisir dans l’éditeur et enregistrer: 
dn: cn=module{0},cn=config
changeType: modify
add: olcModuleLoad
olcModuleLoad: ppolicy
Exécuter la commande de modification contenue dans le fichier: 
ldapmodify -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f ppolicy-module.ldif
Pour vérifier l’activation effective du module: 
ldapsearch -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -b cn=config "(objectClass=olcModuleList)" olcModuleLoad -LLL

dn: cn=module{0},cn=config
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}ppolicy
Remarquez la présence du module ppolicy dans la liste. Initialement, il n’y avait que le module de gestion de la base de données back_hdb  qui est activé.

3. Configurer le module ppolicy

Créer le fichier de commande LDIF: ppolicy-conf.ldif 
vi ppolicy-conf.ldif
Saisir dans l’éditeur et enregistrer: 
dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcPpolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=ppolicy,dc=ldaptuto,dc=net
olcPPolicyUseLockout: FALSE
olcPPolicyHashCleartext: TRUE
Ajouter l’entrée du fichier: 
ldapmodify -x -a -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f ppolicy-conf.ldif
Pour vérifier la prise en compte effective de la configuration: 
ldapsearch -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -b cn=config "(objectClass=olcPpolicyConfig)" -LLL

dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=ppolicy,dc=ldaptuto,dc=net
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: FALSE
Trois paramètres de configuration:
  1. olcPPolicyDefault: Indique un DN de configuration utilisé par défaut (cf. paragraphe suivant).
  2. olcPPolicyHashCleartext: Indique si les mots de passe doivent être cryptés systématiquement. Ce paramètre devrait être à TRUE sauf cas exceptionnel.
  3. olcPPolicyUseLockout: Indique si le message d’erreur retourné en cas de tentative de connexion à un compte verrouillé est un message spécifique à cet état de verrouillage (TRUE), ou un message général d’echec de connexion (FALSE). FALSE est plus sécurisé (pas d’indication à un éventuel pirate), TRUE est plus pratique.

4. Configurer une politique de mots de passe

Il s’agit de configurer l’entrée indiquée dans le paramètre olcPPolicyDefault de la configuration du module ppolicy, c’est à dire: cn=ppolicy,dc=ldaptuto,dc=net. Pour cela on va créer un fichier LDIF qui permettra d’ajouter cette entrée. 
vi ppolicy-defaut.ldif
Saisir dans l’éditeur et enregistrer: 
dn: cn=ppolicy,dc=ldaptuto,dc=net
objectClass: device
objectClass: pwdPolicyChecker
objectClass: pwdPolicy
cn: ppolicy
pwdAllowUserChange: TRUE
pwdAttribute: userPassword
pwdCheckQuality: 1
pwdExpireWarning: 600
pwdFailureCountInterval: 30
pwdGraceAuthNLimit: 5
pwdInHistory: 5
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdMaxAge: 0
pwdMaxFailure: 5
pwdMinAge: 0
pwdMinLength: 5
pwdMustChange: FALSE
pwdSafeModify: FALSE
Ajouter l’entrée: 
ldapmodify -x -a -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f ppolicy-defaut.ldif
Pour vérifier la prise en compte de cet ajout: 
ldapsearch -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -b dc=ldaptuto,dc=net "(objectClass=pwdPolicy)" -LLL
16 Paramètres (tous les attributs listés) permettent de configurer une politique efficace et performante de mots de passe et de gestion des comptes utilisateurs. La commande suivante permet d’avoir tous les détails à propos de ces paramètres: 
man slapo-ppolicy
A titre d’exemple, la valeur de pwdMinLength est 5, ce qui signifie qu’un mot de passe ne peut pas avoir une longueur inférieure à 5 caractères. Testons: 
ldappasswd -x -H ldap://localhost -D uid=durand,ou=people,dc=ldaptuto,dc=net -w durand -s dura

Result: Constraint violation (19)
Additional info: Password fails quality checking policy
Cette commande permet à Alain Durand de se connecter avec son identifiant et mot de passe (-D uid=durand,ou=people,dc=ldaptuto,dc=net et -w durand) et modifier ce mot de passe avec la nouvelle valeur fournie (-s dura). La commande échoue car le nouveau mot de passe comporte 4 caractères. 
ldappasswd -x -H ldap://localhost -D uid=durand,ou=people,dc=ldaptuto,dc=net -w durand -s duran
La commande réussit car le nouveau mot de passe comporte 5 caractères. Pour vérifier la prise en compte de cette modification: 
ldapsearch -x -H ldap://localhost -D uid=durand,ou=people,dc=ldaptuto,dc=net -w durand -b dc=ldaptuto,dc=net

ldap_bind: Invalid credentials (49)
Le serveur n’a pas accepté l’ancien mot de passe. Si on utilise la même commande avec le nouveau mot de passe : duran, le serveur l’acceptera. Un autre paramètre: pwdCheckModule permet de contrôler la qualité du contenu des mots de passe. Ce paramètre indique le nom du fichier d’une librairie dynamique partagée native qui se charge de cette fonction. Avant de le renseigner il faudra d’abord s’assurer que cette librairie est présente. Une telle librairie est disponible à l’installation à partir de son site Internet. Il convient de l’installer et ensuite renseigner ce paramètre en modifiant le paramétrage de la politique de mots de passe par défaut: 
vi modifpp.ldif
Saisir dans l’éditeur et enregistrer: 
dn: cn=ppolicy,dc=ldaptuto,dc=net
changeType: modify
add: pwdCheckModule
pwdCheckModule: pqchecker.so
Exécuter la modification: 
ldapmodify -x -a -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f modifpp.ldif
pqchecker.so est la librairie de contrôle de la qualité du contenu des mots de passe. Cette librairie est installée par défaut dans /usr/lib/ldap. Par défaut également elle oblige à utiliser un mot de passe avec au minimum 1 caractère majuscule, 1 minuscule, 1 chiffre et 1 caractère spécial (non alphabétique). Plus de renseignements à ce propos peuvent être trouvés sur http://www.meddeb.net/pqchecker.]]>

OpenLDAP – Utilisation pour protéger l’accès à un site web

Objectif: Utiliser le serveur d’annuaire OpenLDAP pour protéger l’accès à un site web.  Protéger l’accès revient à n’autoriser qu’un ensemble restreint de personnes à lire le contenu de ce site. Plus concrètement, à chaque demande d’accès au site web, il sera demandé la saisie d’un identifiant et un mot de passe. L’accès n’est autorisé que pour ceux qui sont référencés dans l’annuaire LDAP. Pré-requis: L’article Ajouter des données à l’annuaire ainsi que ses pré-requis sont lus. Le serveur OpenLDAP est installé et alimenté avec les données de l’article.

1. Installer le serveur web apache

Vérifier si ce serveur est installé 
sudo service apache2 status
2 Possibilités selon la réponse obtenue:
  1. « * apache2 is running » ou « * apache2 is not running » : Le serveur est installé, passer au paragraphe 2.
  2. « apache2: unrecognized service »: Le serveur n’est pas installé, il faudra le faire.
Installer le serveur: 
sudo apt-get install apache2

2. Mettre en place un site web de test

Pour rester simple, on va utiliser le site par défaut. Sauvegarder la page d’entrée de ce site: 
sudo mv /var/wwww/index.html /var/www/index.html.orig
Créer une nouvelle page: 
vi /var/wwww/index.html
Et saisir puis enregistrer: 
 <html>
  <header>
    <title>OpenLDAP tutorial</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </header>
  <body>
    <h6>Site web OpenLDAP tutorial</h6>
  </body>
</html

3. Tester le fonctionnement du site

Dans un navigateur web saisir dans la barre d’adresse: http://localhost puis entrée. Il doit s’afficher une page blanche avec le sous-titre Site web OpenLDAP en haut. Si ce n’est pas le cas, vérifier la configuration du site par défaut car l’installation a été probablement modifiée après l’installation du serveur web. 
ls -l /etc/apache2/sites-enabled/
En réponse à cette commande on devrait avoir au moins la ligne: 000-default.conf -> ../sites-available/000-default.conf Et le contenu de ce fichier doit comporter: 
<VirtualHost desktop:80>
  ServerName localhost
  DocumentRoot /var/www
  ...
</VirtualHost>
Si ce n’est pas le cas, rectifier puis redémarrer le serveur.

4. Activer et configurer le mod-ldap du serveur apache2

Le mod-ldap est un add-in du serveur web apache2, il est installé mais non activé par défaut sur les systèmes Debian et compatibles. S’il n’est pas installé, il convient de le faire avant toute autre action. 
sudo a2enmod authnz_ldap
Après l’activation, il convient de le configurer pour indiquer les paramètres de notre serveur OpenLDAP: 
sudo vi /etc/apache2/mods-enabled/ldap.conf
Modifier le contenu pour que ce fichier contienne: 
<Location />
  AuthType Basic
  AuthBasicProvider ldap
  AuthName "Saisir identifiant et mot de passe"
  AuthLDAPURL ldap://localhost/ou=People,dc=ldaptuto,dc=net?uid?sub?(objectClass=*)
  Require valid-user
</Location>
Et enfin redémarrer le serveur web pour tenir compte de cette nouvelle configuration: 
sudo service apache2 restart

5. Tester le fonctionnement de la nouvelle configuration

Dans un navigateur web saisir dans la barre d’adresse: http://localhost puis entrée. Si tout va bien, une authentification est maintenant requise pour lire la page: OpenLDAP tutorialRemarquer la phrase paramétrée qui s’affiche: Saisir identifiant et mot de passe. Saisir l’identifiant (uid) de Jean Dupond (dupond) et un faux mot de passe (différent de dupond): l’accès est refusé. Saisir le bon mot de passe (dupond), l’accès devrait être autorisé. Si vous avez activé la production des logs du serveur OpenLDAP (voir l’article Activer le Log OpenLDAP), vous pouvez également contrôler l’interaction entre les deux serveurs en examinant le fichier des logs.]]>

OpenLDAP – Ajouter des données à l'annuaire

Objectif: Dans ce 6eme article de la série « OpenLDAP Tutorial », nous allons alimenter l’annuaire avec des données utiles. Ceci permettra d’utiliser réellement le serveur OpenLDAP. Un prochain article détaillera un exemple concret d’utilisation de cet annuaire. Il sera présenté pas à pas la manière de restreindre l’accès à un site web (Internet ou Intranet) à des utilisateurs authentifiés. Pré-requis:

1. Création d’un nœud pour les personnes.

Un annuaire se doit d’être organisé. Dans un soucis d’organisation, on va d’abord créer un nœud (conteneur) qui recevra les entrées annuaire des personnes. Créer un fichier LDIF pour ce nœud: 
vi people.ldif
Saisir dans l’éditeur, puis enregistrer: 
dn: ou=People,dc=ldaptuto,dc=net
objectClass: organizationalUnit
ou: People
  • People est un nom au choix.
  • Le type de cette nouvelle entrée est organizationalUnit (OU), c’est le type usuel des nœuds conteneurs dans OpenLDAP.
  • OpenLDAP n’est pas sensible à la casse et ne fait pas de différence entre majuscules et minuscules, people ou People sont équivalents.
On ajoute cette entrée à l’annuaire: 
ldapmodify -a -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f people.ldif
-a (pour add) après ldapmodify veut dire qu’on souhaite ajouter le contenu du fichier.

2. Ajouter des personnes à l’annuaire

vi dupond.ldif
Saisir dans l’éditeur, puis enregistrer: 
dn: uid=dupond,ou=People,dc=ldaptuto,dc=net
objectClass: inetOrgPerson
givenName: Jean
sn: Dupond
cn: Jean Dupond
uid: dupond
userPassword: dupond
On ajoute cette entrée à l’annuaire: 
ldapmodify -a -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f dupond.ldif
Et on vérifie cet ajout: 
ldapsearch -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -b ou=People,dc=ldaptuto,dc=net
Remarquer que le mot de passe a été crypté et même l’administrateur ne peut plus le voir en claire.

3. Utilisation

Regardons maintenant ce qui se passe si Jean Dupond essaye de se connecter à l’annuaire et voir les personnes référencées (entre autres lui même). 
ldapsearch -x -H ldap://localhost -D uid=dupond,ou=people,dc=ldaptuto,dc=net -w dupond -b ou=people,dc=ldaptuto,dc=net -LLL
ldap_bind: Invalid credentials (49)
Rappel:
  • -D : dn de l’utilisateur qui s’authentifie, la requête utilise les droits de lecture de cet utilisateur.
  • -w : Mot de passe de cet utilisateur.
Le résultat est un message d’erreur qui veut dire que l’authentification est non valide. Pourtant les données envoyées sont correctes (dn et mot de passe). La cause est un droit d’accès insuffisant pour l’authentification. On ne va pas aborder ici ce thème sensible et complexe des droits d’accès. On va juste ajouter une configuration qui permettra aux utilisateurs de l’annuaire de s’authentifier. 
vi acces.ldif
Saisir dans l’éditeur, puis enregistrer: 
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcAccess
olcAccess: to * by users read by anonymous auth by * none
Cette commande ajoute une autorisation d’authentification (by anonymous auth) et de lecture à toutes les personnes de l’annuaire. Bien entendu il n’est pas conseillé d’utiliser une telle configuration dans la réalité. Elle n’est utilisée ici que pour des raisons de simplification de la démonstration. On lance cette commande de configuration de l’annuaire: 
ldapmodify -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f acces.ldif
Maintenant une requête de lecture des données des personnes de l’annuaire par Jean Dupond (la même que la précédente) permet de les afficher. 
ldapsearch -x -H ldap://localhost -D uid=dupond,ou=people,dc=ldaptuto,dc=net -w dupond -b ou=people,dc=ldaptuto,dc=net -LLL
dn: ou=People,dc=ldaptuto,dc=net
objectClass: organizationalUnit
ou: People

dn: uid=dupond,ou=People,dc=ldaptuto,dc=net
objectClass: inetOrgPerson
givenName: Jean
sn: Dupond
cn: Jean Dupond
uid: dupond
userPassword:: e1NTSEF9Umk1d0QrWEtmNHRrSHBOelBEMkdqU3NNSUhtRmtNU28=
Finalement l’annuaire servi par OpenLDAP permet à Jean Dupond, qui y est référencé, de s’authentifier et de lire toutes les données qu’il contient. A tire d’exercice vous pouvez ajouter une autre personne à l’annuaire: Alain Durand. Après cela le contenu de cet annuaire aura cette structure: 
dc=ldaptuto,dc=net
├── cn=admin,dc=ldaptuto,dc=net
└── ou=People,dc=ldaptuto,dc=net
    ├── uid=dupond,ou=People,dc=ldaptuto,dc=net
    └── uid=durand,ou=People,dc=ldaptuto,dc=net
 ]]>

OpenLDAP – organisation et types de données

Objectif: Dans ce 5eme article de la série OpenLDAP tutorial, nous allons voir comment ce serveur d’annuaire organise son contenu. Ceci constitue un préalable nécessaire pour pouvoir l’alimenter de données. Une fois cette alimentation faite, le serveur sera prêt pour être utilisé. Les principales utilisations sont: l’authentification d’utilisateurs auprès de systèmes informatiques et la synchronisation de données auprès de ces systèmes (serveurs de messagerie par exemple). L’intérêt de l’utilisation des serveurs LDAP pour ces fonctions est que ce protocole est devenu un standard de fait. Il est supporté par la majorité des systèmes et applications informatiques qui ont ce besoin. Un article à venir traitera l’alimentation effective en données. Pré-requis:

1. L’organisation des données dans un serveur OpenLDAP

Dans un serveur OpenLDAP, les données sont organisées en arbre . Il y a la racine de l’arbre: le DIT (Directory information tree), le tronc de celle-ci. En avançant après le tronc, on rencontre:
  • Des nœuds: données de type spécial qui ont la capacité de contenir d’autres données.
  • Des feuilles: les données proprement dites et qui peuvent être de différents types.
On peut assimiler, par analogie, cette organisation à celle d’un système de fichier sur un disque d’ordinateur. Voici la représentation qu’on obtiendrait du dossier /etc/resolvconf par la commande: 
sudo tree /etc/resolvconf
– OpenLDAP tutorialEn bleu, les noeuds ou dossiers dans un système de fichier. – En bleu claire et en vert les données proprement dites ou fichiers dans un système de fichier. Pour désigner de manière non ambiguë le fichier dnscache par exemple, on utilise le chemin complet (full qualified name – FQN): /etc/resolvconf/update.d/dnscache. Cela est nécessaire du fait qu’il peut y avoir un autre fichier, qui porte le même nom, quelque part ailleurs sur le disque.   Pour un annuaire LDAP l’équivalent du FQN est le DN (distinguished name) et il constitue le chemin complet depuis la racine (c’est à dire le DIT).

2. Les types de données dans un serveur OpenLDAP

Il existe un très grand nombre de types de données utilisables par le serveur OpenLDAP. De plus ces types de données sont extensibles et évoluent constamment. Dans la pratique il convient de choisir un ensemble restreint de ces types de données en fonction des besoins réels. Cela revient à déclarer dans la configuration du serveur les schémas à embarquer. Un schéma est une description de types de données (métadonnées). Cette commande donne la liste des schémas embarqués par le serveur: 
ldapsearch -x -H ldap://localhost -s one -D cn=admin,dc=ldaptuto,dc=net -y pwdAdmin -b cn=schema,cn=config cn -LLL
dn: cn={0}core,cn=schema,cn=config
cn: {0}core

dn: cn={1}cosine,cn=schema,cn=config
cn: {1}cosine

dn: cn={2}nis,cn=schema,cn=config
cn: {2}nis

dn: cn={3}inetorgperson,cn=schema,cn=config
cn: {3}inetorgperson
Le résultat est celui obtenu juste après l’installation d’un serveur OpenLDAP. Ce sont les quatre schémas embarqués par défaut. Ils suffisent pour la plupart des utilisations de base d’un annuaire LDAP.

3. Le contenu par défaut du serveur OpenLDAP

Pour obtenir le contenu entier et réel d’un annuaire OpenLDAP, il faut lancer une requête de recherche en mode connecté avec le compte de l’administrateur du serveur (rootdn). C’est le seul compte qui n’est jamais soumis à aucune restriction d’accès. 
ldapsearch -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -y pwdAdmin -b dc=ldaptuto,dc=net -LLL
dn: dc=ldaptuto,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: OpenLDAP tutorial
dc: ldaptuto

dn: cn=admin,dc=ldaptuto,dc=net
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9RzlwcjRUdkRJajlWOWpqYjFzMTJkczhaaDBrY2pzOXA=
Le résultat est celui obtenu juste après l’installation d’un serveur OpenLDAP. On reconnaît les valeurs saisies au cours de l’installation (ou la reconfiguration).
  • cn=admin: l’identifiant de l’administrateur du serveur.
  • o=OpenLDAP tutorial: Le nom de l’oganisation.
  • dc=ldaptuto,dc=net: le DIT (nom de domiaine).
  • userPassword: le mot de passe de l’administrateur (crypté).
En tout, il n’y a que deux entrées dans l’arbre de l’annuaire: dc=ldaptuto,dc=net └── cn=admin,dc=ldaptuto,dc=net Ce sont les valeurs de l’attribut objectClass qui déterminent la nature (ou le type) de l’entrée.
  • dc=ldaptuto,dc=net: de type dcObject, c’est le type spécial qui détermine la racine ou le DIT de l’annuaire. Cette entrée est le conteneur de toutes les données de cet annuaire.
  • cn=admin,dc=ldaptuto,dc=net: de type simpleSecurityObject, donnée finale qui représente un compte d’authentification. Contient principalement le mot de passe de ce compte.
]]>

OpenLDAP tutorial (4) – Accès à la configuration dynamique par l'administrateur

Objectif: OpenLDAP tutorial (4) a pour objectif de donner à l’administrateur du serveur OpenLDAP, créé à l’installation, les droits de gérer les données de la configuration. Ceci devrait faciliter la gestion de cette configuration, notamment en ouvrant la possibilité de la modifier à distance. Pré-requis: OpenlDAP est installé et pré-configuré sur une machine Debian, Ubuntu ou compatible. cf. les articles précédents au sujet d’OpenLDAP.

1. Eviter de saisir le mot de passe de l’administrateur à chaque commande

On stocke le mot de passe du super administrateur (ici “admin” à titre d’exemple) dans un fichier: 
echo -n "admin" > pwdAdmin
chmod 600 pwdAdmin
Ceci crée le fichier pwdAdmin qui contient le mot de passe du super administrateur. Pour tester son utilisation: 
ldapsearch -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -y pwdAdmin -b dc=ldaptuto,dc=net
L’intérêt d’utiliser le compte de l’administrateur du serveur au lieu de celui de l’administrateur système de la machine (root) est qu’on peut lancer les commandes à distance (dans ce cas remplacer localhost par le nom de la machine distante).

2. Droits d’accès du super administrateur à la configuration du serveur

La configuration du serveur OpenLDAP se trouve dans la base de données sous le DIT cn=config. Il s’agit de l’équivalent du contenu du fichier de configuration dans l’ancien mode de fonctionnement. Par défaut le super administrateur ne peut pas accéder à cette configuration: 
ldapsearch -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -y pwdAdmin -b cn=config
Le résultat est vide. On va utiliser les droits étendu de l’utilisateur système root pour donner un droit d’accès à la configuration au super administrateur du serveur OpenLDAP. Créer le fichier LDIF acces-admin.ldif, dont le contenu est : 
dn: olcDatabase={0}config,cn=config
changeType: modify
add: olcAccess
olcAccess: to * by dn.exact=cn=admin,dc=ldaptuto,dc=net manage by * break
Exécuter la commande d’ajout de ce fichier sur le serveur: 
sudo ldapmodify -Y external -H ldapi:/// -f acces-admin.ldif
Ceci donne les droits de lecture et d’écriture sur toutes les données de la configuration du serveur à l’administrateur (cn=admin,dc=ldaptuto,dc=net). On peut facilement le vérifier en lançant la requête précédente sur ces données et qui n’a retourné aucun résultat.]]>

Tutoriel Maven – Mettre en place un dépôt personnel

Objectif: Cette 4eme partie de la série “tutoriel maven” a pour objectif de montrer comment mettre en place un dépôt maven personnel public. Pour cela, nous verrons la manière avec la quelle Maven prend en compte ses dépôts lors de la construction d’un logiciel cible. Pré-requis: Maven et Java sont installés sur la machine cible munie de l’OS GNU/Linux Debian, Ubuntu ou compatibles. cf. l’article sur l’installation de Maven 3. Pour construire un logiciel cible, Maven télécharge et installe tout ce dont il a besoin pour accomplir cette tâche. Ces besoins sont principalement:

  • Les librairies dont dépend l’application: déclarées dans la section <dependencies></dependencies> du fichier pom.xml du projet.
  • Les plugin Maven qui accomplissent différentes tâches nécessaires à la construction de la cible : déclarés dans la section <plugins></plugins> du fichier pom.xml du projet.
Qui dit téléchargement, dit source et emplacement d’installation. Par défaut, si rien n’est indiqué dans la section <repositories></repositories> de pom.xml du projet, le téléchargement se fait depuis l’adresse: http://repo.maven.apache.org/maven2 Par défaut également, la cible locale de ces téléchargements se trouve dans ~/.m2/repository (sous dossier .m2/repository du dossier personnel de l’utilisateur qui lance la construction, /home/xxxxxx, xxxxxx étant l’identifiant de cette personne sur la machine d’exécution). Cette cible locale, est le dépôt Maven local. A la construction du logiciel cible, Maven cherche d’abord ses besoins dans le dépôt local, s’il ne les trouve pas il les télécharge à partir de là où il pourrait les trouver. Passons à la pratique.

1. Sauvegarder le dépôt Maven local

Si Maven est déjà installé et qu’il a été utilisé, il convient de sauvegarder le dépôt actuel. A la fin des manipulations proposées, il sera possible de le rétablir tel qu’il était à l’origine. 
mv ~/.m2/ ~/m2-save/

2. Télécharger les sources d’une librairie Java exemple et la construire

Exécuter les commandes suivantes l’une après l’autre: 
mkdir tmp && cd tmp
wget http://meddeb.net/data/bee-src.tgz
tar xzvf bee-src.tgz
cd bee/
mvn package
Ce qui revient principalement à télécharger les sources d’un exemple à construire et lancer sa construction. Remarquer que Maven télécharge beaucoup de fichiers .jar depuis le dépôt de Maven par défaut, ensuite la construction échoue. 
vi pom.xml
Remarquer qu’il n’y a aucune référence à un dépôt: la balise <repositories> n’est pas utilisée du tout. 
ls -la ~/.m2
Remarquer que cet emplacement a été recrée et même alimenté.

3. Lancer une deuxième fois la reconstruction

mvn clean package
Cette fois Maven ne télécharge plus rien, car tout ce dont il a besoin existe déjà dans le dépôt local. La construction échoue toujours car la même librairie manquante est introuvable.

4. Modifier le dépôt local par défaut

sudo vi /etc/maven/settings.xml
Repérer la balise <localRepository>, dé-commenter la et saisir une emplacement correcte, par exemple: /home/votreidentifiant/maven-repo. Remplacer “votreidentifiant” par votre identifiant sur la machine utilisée. Ceci donne: <localRepository>/home/votreidentifiant/maven-repo</localRepository> 
mvn clean package
Maven télécharge ses besoins à nouveau (car le nouveau dépôt est vide) et la construction échoue toujours à la fin. 
ls -l ~/maven-repo
Le nouveau dépôt est créée.

5. Référencer un dépôt source dans pom.xml

vi pom.xml
Ajouter à la fin du fichier, avant la balise </project> 
<repositories>
  <repository>
    <id>meddeb-net</id>
    <name>Meddeb.net Repository</name>
    <url>http://meddeb.net/maven</url>
  </repository>
</repositories>
Ensuite, construire 
mvn clean package
Maintenant la construction réussit car la librairie qui manque se trouve dans ce dépôt personnel.

6. Mettre en place un dépôt personnel

Pour cela il faut disposer d’un site web accessible sur Internet. Créer sur le serveur de ce site un dossier maven/ à la racine. Ajouter à la fin de la section de pom.xml (de la librairie bee) 
<extensions>
  <extension>
    <groupId>org.apache.maven.wagon</groupId>
    <artifactId>wagon-ftp</artifactId>
    <version>2.6</version>
  </extension>
</extensions>
Ensuite, ajouter à la fin de pom.xml (avant </project>) en remplaçant “domaine” par le nom de domaine approprié et en ajustant l’url pour l’adapter à l’url ftp d’accès au site utilisé. 
<distributionManagement>
 <repository>
   <id>domaine-net</id>
   <url>ftp://ftp.domaine.net/maven</url>
 </repository>
</distributionManagement>
Enfin, ajouter dans le fichier ~/.m2/settings.xml 
<settings>
  <servers>
    <server>
      <id>domaine-net</id>
      <username>ftp-user</username>
      <password>ftp-password</password>
    </server>
 </servers>
</settings>
id: le même utilisé dans pom.xml ftp-user: identifiant d’accès ftp au site ftp-password; mot de passe ftp d’accès au site ftp-user, ftp-password et l’url ftp du site sont fournie par votre hébergeur du site utilisé. Maintenant on peut déployer le fichier .jar résultat dans le dépôt personnel. 
mvn package deploy
Pour installer dans le dépôt local: 
mvn package install
]]>