km.azerttyu.net

[2024] Redmine et plugins à surveiller

km — 2024-10-24T08:55:46Z

En complément des plugins utilisé en production, voici une liste de plugin identifié cette année.
Certains sont vieux d'autres récents, maintenus ou pas. C'est la foire aux plugins, on a du intéressant, du moins intéressant.
Un travail de fond doit être fait pour voir leur pertinence

Les plugins à surveiller

https://github.com/batizhevsky/redmine_pretend
- Permettant d'usurper temporairement le profil d'une autre personne
https://github.com/nounder/redmine_impersonate
- Alternative à pretend, à comparer
https://github.com/planio-gmbh/redmine_issue_field_visibility
- Pour cacher certaines informations (temps passé, ...) pour certains profils
https://github.com/rozpuszczalny/vscode-redmine
- Voir redmine dans son vscode
https://github.com/frywer/custom_tables
- Faire des listes personnalisé à attribuer à des tickets (une sorte de categorie avancée)
- ne semble plus maintenu
https://github.com/clear-code/redmine_full_text_search
- de la recherche sous stéroïde , projet actif
https://www.r-labs.org/projects/r-labs/wiki/Wiki_Extensions_en
- Étendre le wiki avec des macro , ne semble plus maintenu et doublon de additionals
https://github.com/cryptogopher/issue_recurring
- Des tickets récurrents, intéressant quand on a besoin d'avoir des rappels sur certaines taches projet, maintenu
https://github.com/nanego/redmine_multiprojects_issue
- affecter un ticket à plusieurs projets, maintenu
https://github.com/hicknhack-software/redmine_hourglass
- Suivi de temps, intéressant si on est collé à son redmine en permanence, maintenu
https://github.com/Restream/redmine_issue_checklist
- Proposer une liste de point à valider sur un ticket, ne semble plus maintenu
https://github.com/abahgat/redmine_didyoumean
- Est ce qu'un ticket correspond à un autre existant ? non maintenu
https://github.com/OCA/connector-redmine
- Connecter odoo à redmine, idée intéressant à voir avec dolibarr ?
https://github.com/mikitex70/redmine_drawio
- Des graphiques tout beau
https://github.com/danmunn/redmine_dmsf
- un mode avancé pour gérer sa base documentaire de fichier (doublon avec redmine_full_text_search ?, preview_online ?), maintenu
https://github.com/anteo/redmine_custom_workflows
- workflow on stéroïde, nécessite de savoir écrire en ruby
https://github.com/phlegx/redmine_gitlab_hook
- Brancher les dépots gitlab
https://github.com/dhanasingh/redmine_wktime
- Mettre un ERP dans redmine, maintenu
https://github.com/suer/redmine_webhook
- Notifier sur les créations de tickets par API
https://github.com/jfqd/redmine_helpdesk
- Étendre le mode support et les échanges par courriel
https://github.com/AlphaNodes/additional_tags
- Un plugin d'alphanode pour attribuer des tags aux tickets, logique qu'on retrouve sur différentes forge
https://github.com/jgraichen/redmine_dashboard#readme
- Une alternative au plugin kanban, maintenu à comparer
https://github.com/cat-in-136/redmine_hearts
- Donner des cœurs et +1 aux commentaires et tickets
https://github.com/kbsali/php-redmine-api
- Communiquer via PHP sur l'API redmine, maintenu
https://github.com/onozaty/redmine-view-customize
- Personnaliser les interfaces en injectant js/css à la demande

Des thèmes

https://github.com/farend/redmine_theme_farend_bleuclair
- maintenu, adaptation du thème par défaut
https://github.com/makotokw/redmine-theme-gitmike
- un à la github, non maintenu

[2024] Redmine et ses plugins

km — 2024-10-23T16:55:21Z

Dans le cadre des outils collboratifs j'utilse régulèrement redmine
Pour ce faire j'utilise certains plugins et j'essaye de faire une veille annuelle de ce qui me semble intéressant.

Les plugins que j'utilise :

Additionals

Le plugin Additionnals permet de personnaliser en profondeur les différentes pages et fonctionnalités pour chaque projet (général, sommaire, wiki). Par exemple

je rajoute un menu dynamique listant toutes les pages dans la partie latérale de wiki.
je liste les sous projets de chaque projet
des macro comme child_pages sont utilisés abusivement sur les différentes partie des pages wiki
je personnalise le menu pour ajouter des renvois vers d'autres services, une sorte de boussole

Le projet est toujours actifs et maintenu.

Kanban

Le plugin Kanban permet d'afficher les tickets en mode kanban. Bien pratique pour avoir une vue globale des états d'avancée dans ses dossiers.

Pour activer la fonctionnalité ne pas oublier d'activer les permissions et de passer projet par projet.

Activité du projet réduite mais comme il fonctionne sans heurt, ce n'est pas un problème.

Default custom query

Le plugin personnalisation des filtre de tickets permet de personnaliser des règles de filtrage pour les tickets pour chaque utilisateur.
Il est possible d'activer un filtrage par défaut si celui de redmine ne convient.

Pour ma part, j'ai une règle me permettant de voir en une fois tous les tickets en cours de traitement.

Édition dynamique des tickets

Le plugin d'édition dynamique des ticket est probablement mon plugin préféré.
En gros il permet de gérer ses tickets à la JIRA, on peut mettre à jour un champ d'un ticket sans éditer l'intégralité de celui ci. Si vous connaissez SPIP cela ressemble également à la fonctionnalité #EDIT

Ce plugin est activement maintenu.

Aperçu des pièces jointes

Les plugins d'aperçus principal et complémentaire sont pratiques pour voir rapidement les pièces jointes du wiki ou des tickets.

Il est nécessaire d'ajouter les bibliothèques serveurs utiles pour lire les pièces jointes comme les tableurs ou les archives.

Le projet est maintenu tranquillement, le suivi est assuré.

Éditeur wysiwyg

Le plugin d'édition visuelle est un petit plaisir à avoir sous le coude.
Il est pratique dans la plupart des cas surtout quand les personnes accédant à l'interface du wiki ou des tickets ne sont pas ni à l'aise avec la syntaxe textile (par défaut) ou markdown.

Le plugin fonctionne bien, attention une fois activé, il est compliqué de revenir en arrière car la syntaxe peut devenir un mélange entre markdown et textile.
Il est conseillé de passer la configuration par défaut en syntaxe markdown (format utilisé en interne pour faire le pivot entre les affichages)

Open Redmine

Le plugin openRedmine est un client android libre pour accèder à un ou plusieurs redmine à distance. Bien pratique même si le projet ne semble plus actif.

PurpleMine2

Un thème plutôt agréable , dans la ligné du thème par défaut mais à mon sens mieux structuré.

Avoir plusieurs comptes Skype

km — 2011-12-10T12:19:23Z

Lorsqu'on travaille à son compte ou bien dans une petite structure, il arrive souvent que son poste informatique personnel soit aussi son poste professionnel.
Un des outils régulièrement plébiscité par les 2 populations, professionnelle et grand public, se trouve être Skype.
Cet article est un petit aide mémoire pour pouvoir l'utiliser dans ces 2 contextes sans avoir à tout mélanger et en même temps.

Pré requis

Pour commencer il faut avoir :

une version skype au moins égale à 2.2
2 comptes inscrits distincts

Et avec Windows ?

Si on possède un poste Windows, il est simple d'utiliser la dernière version officielle et de lire la documentation associée : Comment avoir 2 comptes Skype sur le même ordinateur

Je ne m'étendrais pas plus car la documentation est claire et qu'il n'est pas necessaire d'en dire plus.

Et avec Linux ?

Si on possède un poste Linux (par exemple une distribution de la lignée Debian ), il est possible de faire la même chose. Sur une même session utilisateur, on peut exécuter 2 instances Skype avec leurs propres paramètres.

mon@orid:~$ skype -h
Skype 2.2.0.35 Usage: skype [options]
Options: --dbpath= Specify an alternative path to store Skype data files. Default: ~/.Skype --resources= Specify a path where Skype can find its resource files. Default: /usr/share/skype --disable-api Disable Skype Public API. --pipelogin Command line login. "echo username password | skype --pipelogin" --version Display version information and exit.

Comme la documentation en ligne le dit explicitement, on peut spécifier un répertoire de stockage spécifique par instance Skype. Il est donc aisé de faire :

mon@rdi:~$ skype --dbpath=~/.Skype/maison
mon@rdi:~$ skype --dbpath=~/.Skype/masociete

Et alors ?

On peut bien entendu imaginer de lancer des instances supplémentaires pour transformer son espace de travail en guirlande de Nôël, ou plus simplement pour utiliser un compte temporaire lors de l'organisation d'un événement.

Subgit ou la cohabitation heureuse de SVN et Git

km — 2011-09-07T15:32:50Z

Subgit est un projet tout jeune, initié par l'équipe de TMate. Subgit a pour vocation de synchroniser un dépôt SVN en temps réel avec un dépôt Git.

Présentation

Subgit est un ensemble de scripts java qui assure la synchronisation entre un dépôt SVN et son homologue Git. C'est à dire que tout commit poussé sur l'un ou l'autre des dépôts sera automatiquement présent sur les 2. Un jeu de hooks assure la cohérence et la synchronisation des dépôts.

Principe de fonctionnement de subgit

subgit.com

Organiser son dépôt SVN

La plupart des outils de versionning propose une logique d'historisation basée sur un trunk, des branches et des tags.
SVN en pratique propose une logique de répertoires dont le nommage est non figé. Par conséquent les 3 concepts précédemment indiqués peuvent être nommés comme on l'entend.

Toutefois dans cette première version, Subgit considère seulement la correspondance suivante :

SVN	Git
trunk/	master
branches/	branches
tags/	tags

Le dépôt SVN ne peut aussi contenir qu'un projet à la racine. C'est le cas générique que l'on devrait trouver dans la plupart des dépôts SVN.

Dans les évolutions futures, il est prévu :

de personnaliser la correspondance SVN/Git
de gérer une hiérarchie de sous projets
dé déclarer sa propre structure de correspondance pour les cas plus complexes (famille de projets, nommage différent, ...)

Dans le cas présent, le minimum requis est la présence de trunk/ les 2 autres répertoires pourront être créés manuellement aussi bien du coté Git que SVN. Les hooks feront le necessaire pour maintenir la cohésion.

Pré requis

Dans la suite de l'article nous supposons l'existence d'un dépôt SVN et le souhait de mettre en place un dépôt Git synchrone.
Il est à noter que le projet permet aussi de passer d'un dépôt Git vers SVN, nous n'aborderons pas ce cas de figure pour la suite de cet article.

Pour utiliser subgit, nous aurons au préalable :

un serveur debian dont on aura la maitrise complète,
un dépôt SVN actif dont le répertoire de référence sera /var/subversion/monprojet/

Installation

Comme il a été indiqué précédemment Subgit utilise java pour assurer la cohérence des commits. Nous installons donc le necessaire :

apt-get install git-core sun-java6-bin

Pour continuer nous téléchargeons et installons les scripts depuis la page officielle EAP

weisse:~#mkdir -p /var/subgit weisse:~#wget http://subgit.com/download/subgit-1.0.0-EAP_391.zip -O /var/subgit/subgit.zip weisse:~#unzip /var/subgit/subgit.zip -d /var/subgit

Traduire de SVN vers Git

En toute logique avant de synchroniser les commits à venir, il est utile de convertir l'existant. Subgit fournit un script dédié.

weisse:/var/subgit# subgit-1.0.0-EAP_391/bin/subgit init /var/subversion/monprojet/ SubGit version 1.0.0-EAP ('Miai') build #391 This is an EAP build, which you may not like to use in production environment. Translating: '/var/subversion/monprojet' Subversion revisions: 367 SubGit hooks installed. TRANSLATION SUCCESSFUL Total time: 26 seconds Run 'git clone /var/subversion/monprojet monprojet-git' to obtain Git clone of Subversion repository; or 'svn co file:///var/subversion/monprojet monprojet-wc' to obtain Subversion working copy.

Comme on peut le voir dans cet exemple les 367 commits existants coté SVN ont été convertis.
Par défaut le dépôt créé est stocké au même endroit que le dépôt SVN, on peut le constater en remarquant la présence des répertoires .git et .subgit

Utiliser ses dépôts

Du fait que les 2 dépôts sont contenus dans le même répertoire, le chemin d'accès est donc le même aussi bien pour Git que pour SVN.
Pour des raisons pratiques il est possible de déclarer un autre répertoire cible pour Git (par exemple si on souhaite coupler gitosis/gitolite ou fournir un accès http)

Maintenant nous sommes libres de commiter aussi bien à l'aide d'un client Git ou de continuer à utiliser son client SVN.

Tout commit, branche, tag sera reporté automatiquement d'une dépôt à l'autre.

N'est elle pas belle la vie ?

Optimiser Trac

km — 2010-03-13T10:37:52Z

Dans le cadre du projet SPIP, nous utilisons un serveur dédié pour notre dépôt subversion. Ces dernières soirées nous avons pris les meilleurs conseils sur le net pour optimiser notre serveur.

L'organisation du serveur

Pour la suite de l'article, nous vous situons l'organisation de notre serveur.

Nos dépôts SVN : /var/svn-repos/
Nos répertoires web : /var/www/
Nos dépôts Trac : /var/trac/
Les éléments statiques : /var/trac/deploy (géré par trac-admin)
Nos binaires spécifiques /var/trac/bin/

La timeline

Situation

La timeline est sûrement la page qui consomme le plus de ressources. Sur cette page se trouve l'ensemble de l'activité du trac, commits svn compris.

Par défaut elle est sur 30 jours ce qui est un peu trop sur un projet comme la zone qui génère plusieurs dizaines de commits par jours. De plus il est possible d'effectuer une recherche sur une période de 90 jours d'activité.

Résultat, nous avions 1 fois sur 2 la page qui bloquait lors des accès à la base de données.

Solution

Pour limiter les incidents sur cette page, comme le préconise la page performance de Trac, nous avons limité l'affichage par défaut au 5 derniers jours et autorisé une recherche maximale sur un mois.

sudoer~: nano /var/trac/spip-zone/conf/trac.ini

[timeline] changeset_show_files = 0 default_daysback = 5 max_daysback = 30

Mapper les ressources statiques

Situation

Par défaut l'ensemble des données est géré par Trac. Les éléments statiques tels que les images, javascript, feuilles de style, ... passent par python.
On configure apache pour que celui-ci se charge directement de ces données comme l'explique la documentation Trac

Solution

Pour obtenir les fichiers statiques nous utilisons la commande trac-admin deploy.
sudoer~: trac-admin /var/trac/spip-zone/ deploy /var/trac/deploy

Nous mettons à jour notre Virtualhost en mappant les éléments statiques.

sudoer~: nano /etc/apache2/sites-enabled/zone.spip.org

 #Gerer les fichiers statiques en direct Alias /trac/spip-zone/chrome/ /var/trac/deploy/htdocs/  Order allow,deny Allow from all

Optimiser Apache

Les points qui vont suivre concernent principalement l'optimisation côté serveur.

Dans notre cas nous suivons les conseils Yslow. On peut trouver des informations complémentaires sur différents sites tel que le blog Frédéric de Villamil ou bien du côté de devside.

Optimiser la bande passante

Situation

On constate que l'ensemble de nos données n'est pas optimisé pour la transmission sur le réseau. Les éléments sont envoyés tels quels, ils ne sont pas compressés lors de leur passage sur le réseau.

On peut trouver plus d'information sur cette page dédiée

Solution

On configure le mode de compression selon la nature des fichiers transmis. On exclut de la compression les éléments normalement compressés comme les archives et les images.

sudoer~: nano /etc/apache2/mods-enabled/deflate.conf

# Compresser tout le contenu, sauf certains types spécifiques  # Placer le filtre 'DEFLATE' sur tout le contenu sortant SetOutputFilter DEFLATE # Exclure les élément non compressibles en fonction de leur type SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|rar|zip)$ no-gzip  # Gérer proprement les requettes qui transitent pas des proxies Header append Vary User-Agent   # Gérer proprement les anciens navigateurs qui ne supportent pas la compression  BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Optimiser la durée de vie des fichiers

Situation

Une certaine partie des éléments d'une page sont statiques. C'est à dire qu'ils vont très peu évoluer dans un temps relativement long. Ainsi les navigateurs mettent à jour un certain nombre de fichiers alors que cela est inutile.

Solution

Pour peaufiner les informations de durée de vie nous employons le mode expires tel que peut nous l'expliquer encore Yslow

On installe ainsi les modules Apache requis.

sudoer~: a2enmod expires

sudoer~: nano /etc/apache2/mods-enabled/expires.conf

 ExpiresActive On ExpiresByType text/css "access plus 30 days" ExpiresByType text/javascript "access plus 7 days" ExpiresByType application/x-javascript "access plus 7 days" ExpiresByType application/javascript "access plus 7 days" ExpiresByType image/x-icon "access plus 7 days" ExpiresByType image/png "access plus 30 days" ExpiresByType image/gif "access plus 30 days" ExpiresByType image/jpeg "access plus 30 days" ExpiresByType image/jpg "access plus 30 days" ExpiresByType application/x-shockwave-flash "access plus 60 days"

Les Etag

Situation

Les Etag sont des identifiants uniques pour associer une ressource (fichier, ...) à une version donnée.
Si on se réfère aux tests Yslow, on constate que notre serveur serait mal configuré.
Pour autant avant de courir et de mettre un gros FileETag none dans votre configuration. Il est utile de se référer à certains articles de référence tel que celui d'Eric dapset.

Solution

Dans notre cas, nous avons un seul serveur, des ressources principalement gérées dynamiquement et un mappage des ressources statiques.
La solution est alors simple : « Ne rien faire ».

Fournir Trac, mod_wsgi

Trac utilise python, on ne répètera jamais assez ce détail.
Du coup nous avons plusieurs solutions pour le faire fonctionner avec Apache.

On trouve d'un côté les solutions CGI et de l'autre les modules. le site de codepoint fournit un certain nombre d'explications sur ces différentes approches.
Les solution CGI sont normalement faciles à mettre en place mais leurs performances sont inférieures aux modules apache.

Parmi les solutions modules nous avons mod_python et mod_wsgi. Le mod_wsgi est le module recommandé à l'heure actuelle. Mod_python n'est plus maintenu et fournit comparativement des performances moindres.

Préalablement nous avons deployé les fichiers statiques (pour rappel sudoer~: trac-admin /var/trac/spip-zone/ deploy /var/trac/deploy).

Un fichier de configuration spécifique pour wsgi est alors fourni, nous le retrouvons dans /var/trac/deploy/cgi-bin/trac.wsgi

Nous configurons alors notre serveur en conséquence. Nous gardons /var/trac/deploy hors du DocumentRoot ce qui devrait limiter les incidents de sûreté.

 DocumentRoot /var/www/zone.spip.org/ #Fournir Trac WSGIScriptAlias /trac/spip-zone /var/trac/deploy/cgi-bin/trac.wsgi  PythonOption TracLocale "fr_FR.utf-8" WSGIApplicationGroup %{GLOBAL} Order deny,allow Allow from all

To be continued

Pour aller plus loin dans la configuration du mod_wsgi nous pouvons consulter le site officiel de Trac et celui du projet wsgi.

Créer un démon Subversion

km — 2010-02-25T15:09:43Z

Par défaut le paquet subversion ne fournit pas de script init.d.
Nous devons donc le coder nous même. Cet article s'appuie énormément sur la documentation d'ubuntu.

De petites adaptations sont présentes pour être conforme à la logique Debian.

Créer un dépot SVN

sudoer~: addgroup svn --system sudoer~: adduser svn --system --home /var/svn-repos/ --no-create-home --ingroup svn sudoer~: chown -R svn: /var/svn-repos/

Configurer les fichiers

On prépare un fichier dans /etc/default/subversion. Ce fichier indique les paramètres requis à l'exécution du démon subversion.

sudoer~: nano /etc/default/subversion

#Virtual root for repositories served REPO=/var/svn-repos/

Ensuite nous préparons le script init.d pour gérer les tâches d'exécution. Le script est complétement inspiré de la documentation ubuntu

sudoer~: nano /etc/init.d/subversion

#!/bin/sh -e ### BEGIN INIT INFO # Provides: subversion # Required-Start: $local_fs $remote_fs $network $syslog # Required-Stop: $local_fs $remote_fs $network $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start/stop subversion daemon ### END INIT INFO if [ -x /usr/bin/svnserve ] ; then HAVE_SVNSERVE=1 else echo "Svnserve not installed." exit 0 fi . /lib/lsb/init-functions . /etc/default/subversion case "$1" in start) log_action_begin_msg "Starting SVN server" start-stop-daemon --start --chuid svn:svn --exec /usr/bin/svnserve -- -d -r $REPO log_action_end_msg $? ;; stop) log_action_begin_msg "Stoping SVN server" start-stop-daemon --stop --exec /usr/bin/svnserve log_action_end_msg $? ;; force-reload|restart) $0 stop $0 start ;; *) echo "Usage: /etc/init.d/svnserve {start|stop|restart|force-reload}" exit 1 ;; esac exit 0

Activer le démon

Il ne faut pas oublier de rendre le script exécutable. l'utilisation de chmod suffit.

sudoer~: chmod 755 /etc/init.d/subversion

Debian fournit update-rc.d un script qui permet d'appliquer au bons endroits les appels au script lors du démmarage pour cela il s'appuis sur les informations LSB. Dans notre nous nous sommes inspiré ce celles utilisées par le script apache2.

sudoer~: update-rc.d subversion defaults

 Adding system startup for /etc/init.d/subversion ... /etc/rc0.d/K20subversion -> ../init.d/subversion /etc/rc1.d/K20subversion -> ../init.d/subversion /etc/rc6.d/K20subversion -> ../init.d/subversion /etc/rc2.d/S20subversion -> ../init.d/subversion /etc/rc3.d/S20subversion -> ../init.d/subversion /etc/rc4.d/S20subversion -> ../init.d/subversion /etc/rc5.d/S20subversion -> ../init.d/subversion

Gosa : Utilisation de Samba

km — 2009-08-31T14:19:47Z

Configuration de l'annuaire LDAP

Lors de la configuration de notre annuaire LDAP, nous avons déjà activé les schémas requis pour Samba (voir Installer Gosa (partie 2 : Gosa). Nous n'avons rien à configurer de ce coté.

Installer le plugin pour GOsa

Avec la version 2.6.5 de GOsa, l'interface d'admistration de Samba est affectée à un plugin. Nous devons installer le plugin gosa-plugin-samba.

gosa:# apt-get install gosa-plugin-samba

En nous connectant à l'interface d'administration, une icône dédiée à Samba nous indique que le plugin est correctement installé.

Créer un compte Samba

Pour créer un compte Samba, il faut ajouter un utilisateur dans notre annuaire et lui affecter les droits Unix, puis les droits Samba.

A ce stade, notre utilisateur gosa est prêt à se connecter à notre serveur Samba.
L'étape suivant consiste en la configuration de notre serveur Samba.

Configurer le serveur Samba : Authentification LDAP

Pour commencer nous devons installer le serveur samba (il est recommandé d'utiliser un serveur dédié pour ce service)

samba:# apt-get install samba

Nous éditons ensuite le fichier smb.conf pour paramétrer les connexions à notre annuaire LDAP.

samba:# nano /etc/samba/smb.conf

 passdb backend = ldapsam:ldap://ip_gosa ldap admin dn = "cn=admin,dc=mydc,dc=mycountry" ldap ssl = off ldap delete dn = no ldap user suffix = ou=users ldap machine suffix = ou=machines ldap group suffix = ou=groups ldap suffix = dc=mydc,dc=mycountry

A noter :

On n'aborde pas la sécurisation via ssl, d'où l'option à off
Au lieu de l'ip_gosa, on peut indiquer le nom du serveur.

Configurer le serveur Samba : Partage de répertoire

Voici un exemple de partage possible.
La première section correspond à un répertoire accessible pour l'ensemble du groupe gosa_groupe. Ce groupe est défini via l'administration de GOsa.
La seconde section est un partage générique pour que chaque compte accède à son répertoire personnel (exemple : /home/gosa)

Notre utilisateur gosa doit appartenir au groupe gosa_groupe pour accéder aux 2 partages.

#Partage accessible uniquement aux comptes appartenant au groupe gosa_groupe [Commun] comment = Partage Commun path = /var/samba/Commun valid users = @gosa_groupe browseable = yes writable = yes #Interdire les non authentifiés guest ok = No #Accéder au répertoire de l'utilisateur authentifié. #Dans l'explorateur le répertoire sera nommé selon le compte utilisateur. [homes] comment = Répertoire Personnel browseable = No writeable = Yes

Vérification de la configuration

Samba fournit la commande testparm qui analyse le fichier smb.conf et retourne les erreurs éventuelles.

samba:# testparm

Load smb config files from /etc/samba/smb.conf Processing section "[section1]" ... Processing section "[SectionN]" Loaded services file OK.

On relance le démon afin de prendre en compte nos modifications.

samba:# /etc/init.d/samba restart

Configurer le compte d'administration Samba

Pour finaliser la configuration, nous devons sauvegarder le mot de passe du compte administrateur déclaré dans smb.conf

samba:# smbpasswd -w MonMotDePasse

Setting stored password for "cn=admin,dc=mydc,dc=mycountry" in secrets.tdb

Vérifier la connexion LDAP

Pour vérifier que notre serveur de fichier voit bien notre compte créé avec GOsa, nous utiliserons pdbedit

samba:# pdbedit -L

gosa:1001:gosa gosa

Nous pouvons vérifier l'ensemble des paramètres de notre compte via samba:# pdbedit -L -v -u gosa

Ainsi se conclut cet article, notre utilisateur gosa doit pouvoir s'authentifier sans problème au serveur Samba et consulter ses documents.

Ressources

Gosa : Authentification Unix (compte posix)

km — 2009-08-28T09:31:32Z

Nous allons autoriser un poste client à considerer nos comptes GOsa comme des comptes Unix standard

Pré requis

Avant de continuer la lecture de cet article, je vous invite à les 2 articles suivants :

Ces articles proposent une configuration de base concernant GOsa et son annuaire LDAP.

Création d'un compte GOsa

Pour authentifier un compte GOsa, il faut d'abord le créer. En 2 captures, c'est fait.

creation compte 01 creer

creation compte 02 information

Pour l'utilisateur créé, nous le configurons pour qu'il soit considéré comme un compte unix. Lors de l'installation de notre annuaire LDAP, les objets et attributs requis pour gérer les comptes posix sont déja actifs.

creation compte 03 activer unix

creation compte 03 compte unix

Notre utilisateur est prêt à se connecter sur notre poste client. Nous continuons par la configuration du dit poste.

Installation des paquets NSS et PAM

Sur le poste qui acceptera des comptes gérés par LDAP, nous installons en premier les outils utiles à leurs communications.
apt-get install libnss-ldap, nous amènera à configurer 2 paquets libnss-ldap et libpam-ldap.

Les questions sont relativement claires, donc pas d'explications, juste une installation en image.

Le paquet libnss

libnss ldap 01 uri

libnss ldap 02 DN

libnss ldap 03 version

libnss ldap 04 anonyme

libnss ldap 05 root

libnss ldap 06 chmod

libnss ldap 07 admin ldap

libnss ldap 08 passwd

libnss ldap 09 nsswitch

libpam ldap 01 uri

Le paquet libpam

libpam ldap 02 DN

libpam ldap 03 version

libpam ldap 04 root

libpam ldap 05 anonyme

libpam ldap 06 admin ldap

libpam ldap 07 passwd

libpam ldap 08 chiffrage

Configuration des paquets

Avec la configuration réalisée à l'aide de debconf, il se trouve que la communication avec le serveur LDAP ne fonctionne pas à tous les coups.
La configuration générée utilise une URI ldap ://, hors il est préférable de faire appel à l'attribut host

Dans les 2 fichiers suivants :

on commente la ligne commençant par ldap://
on ajoute la ligne host ldap.mydc.mycountry

client:# nano /etc/libnss-ldap.conf
client:# nano /etc/pam_ldap.conf

Configuration de NSS

Pour rappel, lors de l'installation du paquet libnss-ldap, la dernière étape nous invitait à éditer le fichier nsswitch.conf

client:# nano /etc/nsswitch.conf

Nous ajoutons la référence à ldap.

passwd: compat ldap group: compat ldap shadow: compat ldap

Configuration de PAM

PAM est un module qui gére les différents sources d'authentification et fait le pont avec les applications nécessitant une authentification.

Nous avons 3 fichiers à mettre à jour.

client:# nano /etc/pam.d/common-account

account	sufficient	pam_ldap.so account	required	pam_unix.so try_first_pass

client:# nano /etc/pam.d/common-auth

auth	sufficient	pam_ldap.so auth	required	pam_unix.so nullok_secure try_first_pass

client:# nano /etc/pam.d/common-password

password	sufficient	pam_ldap.so password	required	pam_unix.so nullok obscure min=4 md5

Automatiser la création des répertoires utilisateurs

En l'état si vous tentez de vous connecter (# ssh gosa@ip_client) avec le compte créé au tout début de l'article vous obtenez ce genre de message :

Could not chdir to home directory /home/gosa: No such file or directory gosa@client:/#

A ce stade de notre configuration, seule l'authentification par ldap a été activée. Ainsi nous pouvons bien nous connecter avec notre compte mais si le répertoire utilisateur n'existe pas celui n'est pas créé automatiquement.

Pour remédier à ce problème, nous éditons le fichier client:# nano /etc/pam.d/common-session

session required pam_unix.so session required pam_mkhomedir.so skel=/etc/skel/ session optional pam_ldap.so

Connexion

Et ainsi se conclue cet article :

# ssh gosa@ip_client gosa@client:~# gosa@client:~#pwd gosa@client:~#/home/gosa

Ressources

Installer Gosa (partie 2 : Gosa)

km — 2009-08-26T15:10:51Z

Gosa est une interface web évoluée destinée à piloter un annuaire ldap
Cet outil propose une interface simple et unifiée pour gérer ses collaborateur en entreprise [1], de la gestion de compte unix en passant par le déploiement de systeme bureautique complet.

Pré requis

Nous avons a disposition un serveur Debian Lenny avec une installation standard et le paquet ssh et un annuaire LDAP actif. Ce serveur gérera uniquement GOsa et l'annuaire ldap.
Pour la partie LDAP, nous pouvons nous reporter à l'article Installer Gosa (partie 1 : Ldap).

Ce serveur est connecté à un réseau (au moins local) et sera nommé gosa tout le long de cet article.

Obtenir et Installer le dernier paquet gosa

Les dépôts officiels de Debian hébergent déjà des paquets pour GOsa. Mais le projet GOsa évolue plus vite que l'actualisation de ces dépots, nous utiliserons donc leur dépôt public.

Nous éditons notre fichier sources.list :
gosa:# nano /etc/apt/sources.list, nous ajoutons la ligne suivante :
deb http://oss.gonicus.de/pub/gosa/debian-etch/ ./

Enfin on installe avec les commandes classiques :

gosa:# apt-get update gosa:# apt-get install gosa

Vérifier et préparer Gosa

A ce point de l'article nous avons accès à l'interface de configuration. Nous pouvons y accéder depuis notre navigateur favori (non ce n'est pas un panda chez moi).
http://ip_gosa/gosa/

Pour valider son installation, gosa demande l'écriture d'un fichier spécifique :
gosa:# echo -n a077780babfcf255bbb5ee809c22d75e > /tmp/gosa.auth

Une fois fait nous continuons en choisissant notre langue de prédilection.

Ensuite GOsa fait un état des lieux et vérifie que les extensions PHP requises sont bien installées sur le serveur.

Nous continuons en validant la licence d'utilisation.

Accéder à un annuaire LDAP

La prochaine étape consiste à se connecter à un annuaire ldap.
Comme nous n'avons pas encore fournit nos paramètres de connexion, nous observons :

 La connexion anonyme sur le serveur 'ldap://localhost:389' à échoué !

comme le montre la capture suivante.

En mettant à jour nos informations, nous obtenons un message de succès en rappelant le compte et le serveur ldap utilisé.
Pour l'URI de connexion, je suggère de donner un nom de domaine plutôt qu'une IP. Cette solution permettra de faire évoluer notre infrastructure réseau simplement via le fichier hosts de gosa ou un serveur DNS interne.

Validation des schémas

L'étape suivant consiste par la vérification des schémas activé dans l'annuaire. Si certains objets ou attributs sont manquant, une liste récapitule ceux à activer.

Dans ce cas je vous invite à relire Installer Gosa (partie 1 : Ldap) pour corriger les objets manquants signalés en rouge.

Les objets facultatifs manquant sont signalés en bleu, pour le moment on ne s'en préoccupe pas, on abordera les modules de GOsa dans d'autres articles.

Paramétrage de GOsa

A l'aide de 3 étapes on peut personnaliser sa configuration de GOsa. Du fait d'une installation minimaliste, seules les configurations par défaut sont conservées.

Vérification de l'annuaire LDAP

Une fois connecté à l'annuaire LDAP et les schémas validés GOsa vérifie certains problèmes de configuration classique. Pour chaque problème rencontré une solution est proposée.

Lorsque les problèmes sont résolus, tous les messages d'erreurs sont supprimés.

Participer à GOsa

Pour améliorer la qualité du projet, l'équipe de developpement vous propose de vous abonner à la liste de diffusion. Vous pouvez aussi remonter librement diverses informations concernant votre installation.

Finaliser la configuration

Une fois la configuration validée et finie, vous êtes invité à protéger votre fichier de configuration. Vous devez d'abord telecharger le fichier de configuration et le sauver dans /etc/gosa/gosa.conf puis :

chown root:www-data /etc/gosa/gosa.conf chmod 640 /etc/gosa/gosa.conf

Se connecter

Vous venez d'arriver à la conclusion de cet article. La configuration des modules sera abordée lors de prochaines publications.

[1] association, groupe, ...

Installer Gosa (partie 1 : Ldap)

km — 2009-08-07T14:59:11Z

Gosa est une interface web évoluée pour piloter des comptes et systèmes géré dans des annuaires LDAP.
Cet article ne parlera que de la configuration minimale requise pour rendre Gosa fonctionnel.

Introduction

Pour la suite de l'article, nous nommerons le serveur LDAP gosa. Dans notre cas, nous utiliserons le même serveur pour gérer notre annuaire LDAP et gosa.

Le serveur (sous Debian) a été installé avec le strict minimum, juste l'installation standard et le paquet ssh.

Installer LDAP

Nous utiliserons l'annuaire ldap fournit par slapd. Il s'agit de la version 2.4.11-1.

L'installation se fait simplement : gosa :# apt-get install slapd .

L'ensemble des éléments de configuration se feront tous dans le fichier /etc/ldap/slapd.conf. Si ce n'est pas le cas, je le préciserai.

Sauf indication contraire, nous utiliserons la configuration par défaut du fichier.

L'annuaire utilisé a pour suffixe dc=mydc,dc=mycountry, il faudra penser à changer ses informations à son cas particulier. Par exemple j'utilise mon nom de domaine et son TLD.

Les schémas

Pour utiliser un annuaire LDAP, il faut lui fournir des schémas. Ce sont, en version courte, de simples descriptifs précisant comment l'annuaire doit stocker et gérer ses données.

Les schémas nécessaire au fonctionnement de LDAP sont déjà activés :

# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema

Le schéma inetorgperson par exemple est normalisé.

Il est possible par la suite de faire évoluer au fur et à mesures des besoins, en ajoutant de nouveaux schémas à notre annuaire.

Les schémas Gosa

Gosa propose fournit ses propres schémas pour mieux gérer les données contenues dans l'annuaire.

Au préalable nous penserons à ajouter le dépot de gosa (cf partie2). L'installation est classique avec gosa :# apt-get install gosa-schema. Dans notre cas il s'agit de la version 2.6.5-1etch1.

Les schémas minimums à ajouter sont (pour les étourdis nano /etc/ldap/slapd.conf) :

#for gosa
include /etc/ldap/schema/gosa/gosystem.schema
include /etc/ldap/schema/gosa/gofon.schema
include /etc/ldap/schema/gosa/goto.schema
include /etc/ldap/schema/gosa/samba3.schema
include /etc/ldap/schema/gosa/gosa-samba3.schema #Options mais obligatoire
include /etc/ldap/schema/gosa/gofax.schema
include /etc/ldap/schema/gosa/goserver.schema

Configurer les droits d'accès

Comme Gosa apporte de nouveaux attributs et objets à l'annuaire, nous déclarons des droits supplémentaires pour mieux les protéger.

## Configuration Gosa
#Partie Samba
access to attrs=userPassword,sambaPwdLastSet,sambaPwdMustChange,sambaPwdCanChange,shadowMax,shadowExpire by dn="cn=admin,dc=mydc,dc=mycountry" write by dn="uid=samba,ou=DSA,dc=mydc,dc=mycountry" write by anonymous auth by self write by * none
access to attrs=sambaLmPassword,sambaNtPassword by dn="cn=admin,dc=mydc,dc=mycountry" write by dn="uid=samba,ou=DSA,dc=mydc,dc=mycountry" write by anonymous auth by self write by * none ##Partie Autre
access to attrs=goImapPassword by dn="cn=admin,dc=mydc,dc=mycountry" write by * none
access to attrs=goKrbPassword by dn="cn=admin,dc=mydc,dc=mycountry" write by * none
access to attrs=goFaxPassword by dn="cn=admin,dc=mydc,dc=mycountry" write by * none
access to attrs=gotoLastUser by * write #Autorisation générique
access to dn.regex="ou=incoming,dc=mydc,dc=mycountry" by dn="cn=terminal-admin,dc=mydc,dc=mycountry" write by dn="cn=admin,dc=mydc,dc=mycountry" write
access to dn.sub="ou=incoming,dc=mydc,dc=mycountry" by dn.regex="cn=terminal-admin,dc=mydc,dc=mycountry" write by dn="cn=admin,dc=mydc,dc=mycountry" write
access to dn="ou=(people|groups|computers),dc=mydc,dc=mycountry" by dn="cn=admin,dc=mydc,dc=mycountry" write by dn="uid=samba,ou=DSA,dc=mydc,dc=mycountry" write by * read
access to * by dn="cn=admin,dc=mydc,dc=mycountry" =wrscx by * read by anonymous auth

Lancer Ldap

Nous avons maintenant un annuaire minimaliste compatible avec Gosa. Pour l'activer :

gosa:# /etc/init.d/slapd start Starting OpenLDAP: slapd.

Si ldap se lance correctement alors nous pouvons passer à l'étape suivante.

Utiliser Gosa

A partir de cet instant, nous pouvons configurer Gosa pour piloter notre annuaire.
N'oublions pas que cet annuaire est configuré au minimum nous devrons donc par la suite revenir sur la configuration de LDAP pour ajouter le support de Samba et autres services.