J’ai commencé à développer en PHP quand j’étais encore sur les bancs universitaires. J’ai personnellement toujours détesté ce langage (originalement non typé, fonctions non cohérentes dans leur API, parfois difficile à débugger, Juste assez similaire à JS pour se tromper souvent entre les 2, etc). Mais bon, plusieurs fournisseurs de serveurs utilisent cette technologie parce qu’elle a plusieurs avantages niveau serveurs et maintenance. La preuve que WordPress ou Drupal utilise cette technologie prouve qu’elle n’est pas si mal après tout.

Outre mes préjugés et mes aversions envers ce langage, j’aime quand même travailler avec (love-hate relashionship), sauf pour ce qui a attrait au setup de la machine de développement. Combien de journée j’ai perdu à essayer de configurer Apache, PHP ou MySQL pour qu’il fonctionne bien dans Windows et ayant les bonnes versions qui “fit” avec celle de mon host.

Avec les années, des “PHP manager” tel qu’EasyPHP, XAMPP ou WAMP sont apparues pour nous “simplifier” la vie. Mais était-ce vraiment le cas? Personnellement, j’ai toujours eu pleins de problèmes lors de l’installation (gestions de ports, de DB, de version de PHP, etc.). Mais un jour j’ai découvert “Docker“. Ce concept changea ma relation avec le développement web/PHP. Il y a plusieurs façons de travailler avec et ici je vais donner une version que je trouve très pratique pour de petits projets simples.

Requis

Je prends pour acquis que vous serez sur Windows, mais ça fonctionne aussi bien sur OSX ou Linux.

Donc, vous aurez besoin de Docker. C’est tout! Ça va installer l’engine de docker, l’outil docker-compose. Je ne passerai pas trop de temps à expliquer Docker, mais si je voulais résumer ça en 1 phrase: il s’agit de “mini machine virtuelle” qui exécute un seul “process” à la fois dans un environnement fermé (docker host) qui coexiste d’autres “process“.

Ensuite, n’oubliez pas d’aller dans les settings et de partager le “drive” sur lequel vous ferez du développement. C’est pour des questions de sécurité si vous vous posez la question pourquoi ce n’est pas partagé par défaut.

Un autre outil que je trouve vraiment pratique, c’est PHPStorm de JetBrains. Mais si vous préférez VS Code ou Notepad++, faites comme vous voulez. Cependant, je vais utiliser PHPStorm comme éditeur.

Configuration

Il y a quelques années, j’ai découverts le site phpdocker.io. C’est vraiment pratique pour partir un nouveau projet PHP sans avoir trop de connaissance avec Docker. En utilisant le générateur, on peut avoir une première ébauche fonctionnelle en quelques secondes.

Pour notre exemple, sélectionnons les options suivantes:

Project Name: honosoft
Base Port: 9090
PHP Version: 7.2.X
Extensions: MySQL & XDebug Enable 
MySQL: Let's use 5.7 for this example and fill the user/pass info

Cliquez sur le bouton “Generate Project” et téléchargez l’archive. Donc, vous retrouverez cette liste de fichier que je vous conseille de mettre à la racine de votre projet.

docker-compose.yml
phpdocker\README.html
phpdocker\README.md
nginx\nginx.conf
php-fpm\Dockerfile
php-fpm\php-ini-overrides.ini

Je vais faire un tour rapide des fichiers pour vous donner quelques explications avant de se lancer dans les commandes:

docker-compose.yml

C’est l’équivalent d’un “makefile“. Ce fichier contient la configuration de chacune de vos images. En ouvrant le fichier, on voit qu’il y a 3 services de configurer: “mysql“, “webserver” et “php-fpm“. vous remarquerez qu’il y a 2 types de services: un qui vient d’une “image” et l’autre qui est de type “build”. Le service de type “build” comme son nom l’indique va construire l’image basé sur un fichier de configuration. On verra en détail dans la section du service.

Donc, les trucs importants, si vous ne voulez pas vous taper la doc:

• volume: C’est pour faire un “mount” du “working dir” sur votre machine locale. C’est pourquoi je vous ai indiqué auparavant de “share” votre drive de dev. La syntaxe est assez simple: <host path>:<docker path>.
• ports: C’est pour “mapper” votre port de machine à celui de l’image docker. Donc, si vous voulez vous connecter sur votre process, juste assigner le bon port: <host port>:<docker port>.
• environnement: Ce sont les variables d’environnement qui seront passé à votre process.

mysql

Comme c’est basé sur une image, il n’y a pas beaucoup à dire, puisque c’est déjà configuré correctement. Le seul hic est que la base de données est vide. Donc, si jamais vous voulez initialiser un schéma ou même avec des données initiales, voici le truc: Ajoutez dans les volumes la ligne suivante:

- ./config/mysql/init:/docker-entrypoint-initdb.d/:ro

Le process MySQL, quand il va partir, va aller lire en ordre alphabétique tous les scripts *.sql et les exécuter. Très pratique pour le développement comme on ne veut pas nécessairement créer à la main le data à chaque nouvelle initialisation.

webserver

Celui-là aussi est relativement simple comme c’est basé uniquement sur une image existante. Ce qu’il y a de pratique, c’est qu’il y a déjà un volume en “mount” qui pointe sur un fichier en local: “./phpdocker/nginx/nginx.conf“.

Donc, si vous ouvrez le fichier de configuration, vous verrez qu’il est déjà configuré par défaut pour faire un “rewrite” vers “index.php“. Très pratique si vous utilisez des framework tel que Slim ou des CMS.

Aussi, vous remarquerez que le “root” du projet pointe vers “/public“, ce qui veut dire que vous allez devoir vous créer un dossier “public” avec un fichier “index.php“ dedans.

Et si jamais vous voulez voir les logs facilement en local, vous avez juste à ajouter un volume qui pointe vers: “/var/log/nginx/application.access.log“. Mais personnellement, je ne trouve pas ça super utile comme les logs apparaissent déjà dans la console qui roule le “docker-compose“.

php-fpm

Pour celui-ci, c’est un peu plus complexe, puisque c’est c’est basé sur un “Dockerfile“. Vous verrez que comme dans le docker-compose, l’image est basé sur une existante. Après, on exécute des commandes Linux pour initialiser le container. Dans ce cas-ci, on voit qu’on ajoute les “packages” “php7.2-mysql php-xdebug” à l’image.

Ensuite, le “docker-compose” pointe sur le fichier de configuration “php-ini-overrides.ini“. Donc, si vous voulez modifier des variables de PHP, c’est dans ce fichier que vous pouvez le faire.

Exécution

Voici la partie intéressante. Normalement, si vous avez déjà un fichier “index.php” dans un dossier “./public/index.php“, ça devrait fonctionner. Donc, sans plus attendre, voici les commandes utiles. Si vous en voulez d’autres, google est bien sûr là pour vous aider.

Je vous conseille d’utiliser “power shell” pour faire les commandes. Aussi, dans les fichiers que vous avez téléchargés, vous pouvez vous référer au “README.md” qui contient plusieurs commandes intéressantes qui pourront vous aider.

Start

C’est la commande qui va initialiser le tout et lancer les instances:

> docker-compose up

Après cela, vous avez seulement à aller à l’adesse http://localhost:9090 sur votre “Web Browser” préféré (En ce moment, le mien est Brave).

Build

Si jamais vous faites des changements sur un fichier “Dockerfile“, utilisez cette commande pour refaire l’image:

> docker-compose build

Débugging

Maintenant que votre setup fonctionne, comme tout bon développeur, vous voudrez tester si les “breakpoints” fonctionnent. On a mis “XDEBUG” dans les flags pour l’image de PHP, mais ce ne sera malheureusement pas suffisant. Il faut ajouter quelques “configs“,

Tout d’abord, vous devrez configurer votre fichier “php-ini-overrides.ini” avec les valeurs appropriées:

; Instead of hardcoding the machine IP, we use this hostname.
xdebug.remote_host=host.docker.internal
xdebug.remote_port=9001
xdebug.remote_enable=1
xdebug.remote_autostart=0
; Very important for Docker to be set to off or else the debug won't work
xdebug.remote_connect_back=0
xdebug.remote_mode=req
xdebug.idekey=PHPSTORM
xdebug.remote_log=/tmp/xdebug.log

Ça m’a pris malheureusement plusieurs jours faire fonctionner ça comme je désirais. Tout d’abord, je ne voulais pas “hard-coded” l’IP de ma machine, parce que si d’autres personnes prenaient le projet, ils devraient toujours faire une modification. Très pratique, depuis quelques temps, docker (18.03) a ajouter la variable “host.docker.internal”.

De plus, la variable “remote_connect_back” est à “1” par défaut et à cause de l’environnement Docker, ça cause un problème de conflit de port. J’ai ajouté aussi un log file, qui peut vous aider si jamais vous éprouvez des difficultés avec le “xdebug“.

Ensuite vous devez aller devoir configurer PHPStorm pour qu’il “match” vos “settings” que vous avez mis dans le fichier “php.ini“. Normalement, tout devrait être correct:

1. Aller dans les Settings (ctrl + alt + S)
2. Allez à la page: Languages and Frameworks -> PHP -> Debug
   • Debug Port = 9000
   • Can accept Remote Connection: checked

Vous devrez ensuite créer une nouvelle configuration:

1. Cliquez “Add Configuration”
2. Des “templates“, choisissez “PHP Remote Debug“.

Vous n’avez pas besoin de faire de setup avec la “IDE key” comme c’est en local.

Ensuite, partez en “debug” dans PHPStorm et ça devrait fonctionner comme par magie.

Note:
J’ai eu des problèmes avec la configuration de PHP 7.3 à un certain moment. Pour une raison que j’ignore, le fichier de config php n’était pas lu correctement. On dirait que ce n’était pas le bon répertoire. J’avais dû ajouter un volume pour que ça pointe dans le dossier “cli”:

- ./phpdocker/php-fpm/php-ini-overrides.ini:/etc/php/7.3/cli/conf.d/99-overrides.ini

Si jamais ça peut vous aider. C’était l’une des raisons où j’avais perdu beaucoup de temps.

MySQL

Je ne m’étendrai pas sur le sujet, mais c’était seulement pour faire une remarque quand vous allez l’utiliser dans le code PHP. Si vous voulez vous connecter, vous avez juste à utiliser le nom du host “honosoft-mysql” que vous avez spécifié dans votre fichier “docker-compose.yml“.

Package Manager

Quand on fait du web aujourd’hui, on ne peut pas travailler sans utiliser de “Package Manager”. Pour PHP par exemple, on utilise Composer. Donc, quoi faire pour ne pas avoir à installer Composer sur sa machine? Très simple, il suffit d’ajouter un service qui fera le travail pour nous. Donc dans le “docker-compose.yml”, ajoutez un nouveau service:

composer:
  restart: 'no'
  image: composer/composer
  container_name: sunebook-composer
  working_dir: /composer
  command: install
  volumes:
    - .:/composer

Après le “docker-compose up“, vous n’aurez qu’à exécuter la commande suivante:

> docker-compose run composer install

ou bien par exemple

> docker-compose run composer require package/name

Si vous allez sur dockerhub, vous trouverez pleins de containers déjà existants que vous pourrez configurer de la même manière (Node, Bower, etc). Vous pouvez aussi y aller avec une image qui a tout déjà, même avec un Webpack. Mais pour ce tutoriel, je n’entrarai pas dans les détails.

Déploiement

Une fois terminé, il y a bien sûr le déploiement à prévoir. Il y a plusieurs manières de procéder. Si vous avez un host qui supporte Docker, c’est merveilleux, avez quelques modifications, vous pourrer facilement avoir un environnement “production ready“.

Si vous avez un host “static“, avoir un build script avec Gulp ou Webpack pour créer un “package” est probablement une bonne idée. Après il s’agit que d’uploader vos fichiers finaux vers votre serveur web.

WebPack

Si vous utilisez webpack servi par un docker, vous verrez qu’avec le “hot reloading” que c’est très lent. C’est dommage, parce que pour faire un environnement de dev “instantané”, c’est vraiment super. La raison est que le “file system” de Windows et celui de Linux ne sont pas compatible à 100%. Et quand on “mount” un volume sur windows, faire des “watch” sur tous les fichiers cause énormément “d’overhead“. C’est encore pire sur Mac.

Donc les solutions possibles que je connaisse sont soit d’utiliser une vraie VM de linux et travailler dans Virtual Box par exemple ou bien directement sur linux. Ici vous avez une page qui donne des pistes de solution en attendant: https://docs.docker.com/docker-for-mac/osxfs-caching/

Conclusion

Ce fut un article beaucoup plus long que je pensais, mais voici le code source de l’article:

https://bitbucket.org/honosoft/php-docker/

Pré-requis

• Docker en local
• Client heroku (CLI) installé et configuré
• Git, pour cloner un repository
• Dotnet core 2.1.x installé (ou plus récent)

Exécuter en local

Docker: Images à pré-télécharger

Le build va reposer principalement sur 2 images. Ces images peuvent aussi être téléchargée automatiquement lors du lancement de la commande docker build lors d’une étape subséquente. Si vous voulez lancer les téléchargements en avance, lancez les commandes “docker pull” suivantes:

> docker pull microsoft/dotnet:2.1.500-sdk-alpine3.7 
> docker pull microsoft/dotnet:2.1.6-aspnetcore-runtime-alpine3.7

Créer un projet, ou faire du scaffolding

Je vais opter pour du scaffolding sur un de mes templates. Pour lancer l’installation du template en local faite à partir d’un dossier vide dotnet new -i HoNoSoFt.DotNet.Web.Spa.ProjectTemplates. Ensuite, faire dotnet new vuejs-picnic afin de lancer le scaffolding.

Cette étape n’est sans doutes pas obligatoire, mais sachez qu’Heroku vous procure le HTTPS sans doute en utilisant un reverse proxy (je ne fait que supposer ici). Du coup, vous pouvez désactiver le HTTPS du le projet surtout si vous n’avez pas de certificat valide. Le fichier a modifier est le Startup.cs, mettez en commentaire les lignes app.UseHttpsRedirection(); et app.UseHsts();.

À priori, vous avez votre projet disponible. Vous pourrez donc effectuer un  dotnet build histoire de vous assurer que le build fonctionne. Et ensuite  dotnet run vous permettra de voir avec Kestrel votre site sur https://localhost:5001/.

Faire un build local de votre image Docker

Comme vous l’avez sans doute constaté, ou pas, le projet template utilisé pour le scaffolding contenait déjà un fichier Dockerfile. Ce fichier décrit comment effectuer un build et ensuite vous donne l’option d’exécuter l’image en local.

Contenu du fichier:

####################################################
# To build your own image: 
#    > docker build -t honosoft/vuejs-picnic:latest -t honosoft/vuejs-picnic:1.0 .
# To run your image once it's ready:
#    > docker run -d -p 39803:80 --name vuejs-picnic honosoft/vuejs-picnic
# To push the image into your docker repository:
#    > docker push honosoft/vuejs-picnic:latest
# If you wish to remove your dangling images, please do the following (not mandatory)
#    > docker rmi $(docker images -f “dangling=true” -q)
####################################################

# Build the container with Source code compiled
FROM microsoft/dotnet:2.1.500-sdk-alpine3.7 as buildenv
WORKDIR /source
RUN apk add --update nodejs nodejs-npm
COPY *.csproj .
RUN dotnet restore
COPY . .
# Publishing will also restore (install) the npm packages.
RUN dotnet publish -c Release -o /app/

# Stage 2 - Creating Image for compiled app
FROM microsoft/dotnet:2.1.6-aspnetcore-runtime-alpine3.7 as baseimage
RUN addgroup -S coreApp && adduser -S -G coreApp coreApp
RUN apk add --update nodejs nodejs-npm


WORKDIR /app
COPY --from=buildenv /app .
RUN chown -R coreApp:coreApp /app

# Replace the application name if required.
CMD ASPNETCORE_URLS=http://+:$PORT dotnet Sample.Heroku.dll

IMPORTANT! Si vous utilisez “ENTRYPOINT” pour lancer l’application, ça marchera en local mais pas sur Heroku. Ce qui fait en sorte que vous devrez remplacer la commande par “CMD”, pour plus de détails cliquer ici

Comme avez pu le constater, mon projet s’appelle Sample.Heroku et le point d’entrée afin de démarrer le conteneur sera le fichier Sample.Heroku.dll. Les images utilisée sont la SDK afin de faire la compilation et ensuite l’image Runtime afin d’exécuter la publication en mode Production.

Pour bâtir votre docker, exécuter la commande docker build -t honosoft/sample-heroku:latest .. L’image devrait faire dans les 200mb décompressé et environs 80mo compressée. Il y a des moyens afin de diminuer cela, mais pour le moment on se contentera des images par défaut fournie par Microsoft.

Une fois le build terminé, vous pourrez lister vos images avec la commande docker images. Si votre image s’est construite sans soucis, vous pourrez passer à l’étape suivante, sinon vous devrez faire des corrections par rapport aux erreurs.

Lancer l’image docker en local pour tester

Rien de plus simple, par défaut, docker avec dotnet core utilise le port 80 en interne. Du coup, pour lancer votre image, effectuer la commande suivante:

docker run -d -p 8080:80 --name sample-heroku honosoft/sample-heroku

Votre image devrait donc désormais être disponible en atteignant http://localhost:8080 par le proxy créé par Docker (Port 80 sur Docker et exposé sur votre machine sur 8080).

Déploiement sur Heroku

Créer une application sur Heroku

À partir du dashboard, simplement créer une nouvelle application. Dans mon cas, l’application sera “morning-oasis-26273”.

Deploiement avec le CLI

Vous connecter à votre compte Heroku avec le CLI:

heroku login
heroku container:login

Comme vous le feriez pour envoyer vers les registres de Docker privé, effectuer un tag Heroku de votre image fraîchement créée. Ensuite, vous n’aurez qu’à faire un push (à la git), de votre image vers votre site web.

docker tag honosoft/sample-heroku registry.heroku.com/morning-oasis-26273/web
docker push registry.heroku.com/morning-oasis-26273/web

Alternativement au docker tag/push vous pouvez aussi utiliser la commande Heroku qui effectuera les 2 commandes en une seule:

heroku container:push web -a morning-oasis-26273

Lors du push, ça prendra un peu de temps tout dépendant de votre connexion internet. Le push, tel que pour GIT enverra la différence vers le serveur de registre Docker. Le premier push prendra un peu plus de temps, mais les push subséquents seront rapide et avec un faible volume de données à envoyer.

Tout ce qui reste à faire maintenant, est d’activer votre image sur le site Heroku à l’aide du CLI:

heroku container:release web -a morning-oasis-26273

Avant d’atteindre votre application, vous pouvez tout démarrer les traces logs. Ce sera utile en cas de problème (conteneur qui ne démarre pas par exemple).

heroku logs --tail -a morning-oasis-26273

Conclusion

C’était peut-être un peu plus long que prévu. Mais le tout fonctionne, bonne journée!

This is a multi-part tutorial playground in order to build, for dev or for some of your needs, an integration of:

• [Part I*] OpenLdap (Or active directory) using Contoso Users
• [Part II] IdentityServer 4 with OpenLdap (Built in Dotnet Core 2.x)
  • Option of using Redis to persist user cache (tokens)
• [Part III] Docker to run the previous two options all together (If not already explained in previous 2)
• [Part IV] A small back-end with protected Api’s
  • One in Dotnet Core 2 using the WebApi format
  • One in NodeJS
• [Part V] A small front-end to call the Api’s
  • One in Dotnet Core 2 using the WebApp MVC format
  • One in NodeJS

Requirements for this part

• Docker (Windows, Linux or Mac)

Let’s begin [Part I]

In this part, if you are using Active Directory, it will be easy to already find a VM having the Contoso users already within Active Directory. However, if you are using OpenLdap, you won’t find anything. For development purpose it’s nice to have an already populated Ldap database. For some reason, I will stay with the default schema from OpenLdap. The schema differ from Active Directory.

In this part we will cover:

• How to create an empty OpenLdap Server
• How to start the Server
• How to convert a csv file to ldif format
• How to import within OpenLdap Server
• How to see the data (tool)

How to create an empty OpenLdap Server

You have the choice here of reading all the documentation to install step-by-step or speed up by using a Docker image. For a production environment I would strongly suggest to read all the documentation regarding OpenLdap. It will helps to avoid security holes and also to build properly your Ldap tree.

Let’s pull the best image I’ve found so far for OpenLdap (osixia/openldap)

$ docker pull osixia/openldap:latest

The download should be pretty quick since the image size is not so big. At the time of writing this, the image size on the disk was about `222 MB`. The Github site from that image help you to configure it and also indicate how to have persistance and so much more. Let’s do a quick `Contoso` configuration:

Create an OpenLdap environment file

This file will basically set the Base DC and Admin/Config/Read-Only & {user} + {password}.

• File: ./ldap.env

LDAP_ORGANISATION=Contoso Ltd.
LDAP_DOMAIN=contoso.com
LDAP_ADMIN_PASSWORD=P@ss1W0Rd!
LDAP_CONFIG_PASSWORD=P@ss1W0Rd!

LDAP_READONLY_USER=true
LDAP_READONLY_USER_USERNAME=ldap-ro
LDAP_READONLY_USER_PASSWORD=P@ss1W0Rd!

• Create a folder to put shared files within Docker and OpenLdap
  • ./ldap/

Create a docker compose file

The docker-compose  file will be useful to start/restart or reconfigure the image. I prefer the docker-compose version to the all-in-one command line ( docker run ... ). It is still up to you!

File ./docker-compose.yml

ldap:
   container_name: contosoOpenLdap
   image: osixia/openldap:latest
   ports: 
     - "389:389"
     - "636:636"
   env_file:
     - ./ldap.env
   volumes:
     - ./ldap:/data/ldif

How to start the Server

Within the directory where you have the docker-compose.yml file, you should be able to use docker-compose executable (if in windows) or if you are on Linux you might have to also install that package.

$ docker-compose start

• This will be starting the server. If you prefer to see all the log within the screen, you can instead use docker-compose up command.

How to convert a csv file to ldif format

First of, what is a ldif file? Easy reading on Wikipedia. Basically, it is a Ldap Data Interchange Format. It gives the possibility to add, remove, modify (by properties if we want) or even delete using a specific text format. The format in itself is not complex, the issue you will encounter is that the attributes might not be defined (OpenLdap VS Active Directory). By example the sAMAccount exists in Active Directory and in OpenLdap it might be the uid attribute, depending on your organization.

I have created a simple project named csv2ldif (far from perfect) that can quickly convert a simple CSV format into a ldif format with a default password of P@ss1W0Rd! (Yes again, let’s keep it simple). If you want to change the default password, please do, it’s not so much work. You can also contribute to the repository. It will generate basically 2 files. The first one will be about creating the user groups. The second one is about creating the user and then assigning them to the group. In that project you can also find the CSV file regarding the Contoso Users (with also the pre-generated demo in the example folder).

Regarding the LDIF generation, you can find good information on the LdapWiki.

Small peek (Raw csv)

dn,objectClass,uid,homeDirectory,group,givenName,sn,displayName,cn,mail,manager,telephoneNumber,title
cn=Dan Jump,inetOrgPerson;person;organizationalPerson;posixAccount;top,danj,/home/danj,Executive,Dan,Jump,Dan Jump,Dan Jump,danj@contoso.com,,(425) 555-0179,CEO
cn=Adam Barr,inetOrgPerson;person;organizationalPerson;posixAccount;top,adamb,/home/adamb,Operations,Adam,Barr,Adam Barr,Adam Barr,adamb@contoso.com,cn=Dan Jump,(206) 555-5472,General Manager of Professional Services

Note that the Base OU for the groups and users are not generated. Usually you already have this in your tree. In our case we have something empty.

Create the groups and users OU using a LDIF file

dn: ou=users, dc=contoso,dc=com
ou: users
description: All people in organisation
objectclass: organizationalunit

dn: ou=groups, dc=contoso,dc=com
ou: groups
description: All Groups in organisation
objectclass: organizationalunit

Small peek (Generated groups LDIF)

dn: cn=Executive,ou=groups,dc=contoso,dc=com
objectClass: groupOfUniqueNames
cn: Executive
uniqueMember: cn=Executive,ou=groups,dc=contoso,dc=com
description: Executive

dn: cn=Operations,ou=groups,dc=contoso,dc=com
objectClass: groupOfUniqueNames
cn: Operations
uniqueMember: cn=Operations,ou=groups,dc=contoso,dc=com
description: Operations

Small peek (Generated users LDIF)

dn: cn=Dan Jump,ou=users,dc=contoso,dc=com
objectClass: inetOrgPerson
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: top
uid: danj
uidNumber: 70000
gidNumber: 70001
homeDirectory: /home/danj
givenName: Dan
sn: Jump
displayName: Dan Jump
cn: Dan Jump
mail: danj@contoso.com
telephoneNumber: (425) 555-0179
title: CEO
userPassword: {SHA}RKkNn7+KoG94IN3x/B2jnm/4DS0=

dn: cn=Executive,ou=groups,dc=contoso,dc=com
changetype: modify
add: uniqueMember
uniqueMember: cn=Dan Jump,ou=users,dc=contoso,dc=com

dn: cn=Adam Barr,ou=users,dc=contoso,dc=com
objectClass: inetOrgPerson
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: top
uid: adamb
uidNumber: 70002
gidNumber: 70003
homeDirectory: /home/adamb
givenName: Adam
sn: Barr
displayName: Adam Barr
cn: Adam Barr
mail: adamb@contoso.com
manager: cn=Dan Jump,ou=users,dc=contoso,dc=com
telephoneNumber: (206) 555-5472
title: General Manager of Professional Services
userPassword: {SHA}RKkNn7+KoG94IN3x/B2jnm/4DS0=

dn: cn=Operations,ou=groups,dc=contoso,dc=com
changetype: modify
add: uniqueMember
uniqueMember: cn=Adam Barr,ou=users,dc=contoso,dc=com

If you want the entire data don’t forget to just go on https://github.com/Nordes/Csv2Ldif/tree/master/example. There’s the 00, 01, 02 sample file where it have the entire Contoso setup.

How to import within OpenLdap Server

Right now, we have an empty OpenLdap Server. What we want is a server with some users and groups in order for us to play with them within an application or during our Devs.

Download the following files (if not already) and save them within the ./ldap/ folder you’ve created earlier:

1. 00-startup.ldif
   • Create the users and groups OU (Organisation Unit) (ou=…,dc=contoso,dc=com)
2. 01-output-groups.ldif
   • Create all the  groups CN within the  groups OU (cn=…,ou=groups,dc=contoso,dc=com)
3. [02-output-users.ldif](https://github.com/Nordes/Csv2Ldif/blob/master/example/02-output-users.ldif)
   • Create all the users CN within the users OU (cn=…,ou=users,dc=contoso,dc=com)
   • Attach all the users to their pre-defined group. In our case it’s a 1-1 match.

Import

It’s now time to launch the command line tool (if possible where you have your ldif file).

Our action parameter will be using the following:

• -f: Import the file launching the ldapmodify command within the container
• -d: Use the administrator role to import
• -w: The administrator password (if not set, but with the -w option, it will request the password). In case the password is not set, it will fail.
• -c: Continue on failure (we never know, but at least it will give the logs)
• …: The other one are trivial.

The output result when launching the command are describing what’s happening. By example

...
adding new entry "cn=Josh Edwards,ou=users,dc=contoso,dc=com"
modifying entry "cn=Sales,ou=groups,dc=contoso,dc=com"
...

If you are too lazy to type the commands, you can copy the batch file located at the same emplacement as the 3 previous downloads

Organisation Units

PowerShell uses the back tick &#96; for multiline, however on linux it will be \ character.

$ docker exec contosoOpenLdap ldapmodify \
-a -x -h localhost -p 389 \
-D "cn=admin,dc=contoso,dc=com" \
-f /data/ldif/00-startup.ldif \
-w P@ss1W0Rd! \
-c

Groups

$ docker exec contosoOpenLdap ldapmodify \
-a -x -h localhost -p 389 \
-D "cn=admin,dc=contoso,dc=com" \
-f /data/ldif/01-output-groups.ldif \
-w P@ss1W0Rd! \
-c

Users and membership

$ docker exec contosoOpenLdap ldapmodify \
-a -x -h localhost -p 389 \
-D "cn=admin,dc=contoso,dc=com" \
-f /data/ldif/02-output-users.ldif \
-w P@ss1W0Rd! \
-c

How to see the data (tool)

You have some choice here, but since I am not a big fan of doing the query all by hand and do the request through the OpenLdap Docker instance, I prefer to use LdapAdmin. It gives a UI which is easy to play with.

When creating a connection you will need to set the following:

Look After Import

ldap-Imported

The end! See you soon for the next part.