Installer un serveur TosDJ pas à pas

TosDJ est le serveur d’annuaire (fork d’OpenDJ) qui porte les trois bases décrites dans Composants et couches : Config Store, Core Token Store (CTS) et User Store interne. Une même distribution TosDJ sert à préparer n’importe laquelle de ces trois bases — c’est le profil choisi au moment du setup qui détermine le schéma LDAP et les données initiales chargées.

Cet article installe un serveur TosDJ directement sur un hôte Linux, sans conteneur, en mode silencieux (non interactif), pour pouvoir scripter le déploiement. Il s’appuie sur la même mécanique que celle utilisée pour construire l’image Docker officielle (tosiam-container/images/tosdj), mais rejouée à la main.

Le concept de profil

Le setup de TosDJ accepte un paramètre profile dont les trois seules valeurs valides sont config, cts et user. Chaque profil charge un jeu de fichiers LDIF de schéma (chargés dans config/schema/) et un jeu de données initiales (chargées dans le backend userRoot) :

En résumé : config est un profil “tout-en-un” (il inclut aussi le schéma CTS et utilisateur), tandis que cts et user sont des profils volontairement minimaux, pensés pour des instances TosDJ dédiées à une seule base dans une architecture distribuée.

1. Prérequis

• Un hôte Linux (physique ou VM), un utilisateur système dédié (tosdj dans les exemples ci-dessous) et un répertoire de travail lui appartenant.
• Un JDK compatible (Amazon Corretto 25 dans les images officielles) :

sudo useradd -m -s /bin/bash tosdj
sudo -iu tosdj

JDK_VERSION=25
wget "https://corretto.aws/downloads/latest/amazon-corretto-${JDK_VERSION}-x64-linux-jdk.tar.gz"
mkdir -p ~/opt && tar xf amazon-corretto-*.tar.gz -C ~/opt
ln -s ~/opt/amazon-corretto-* ~/opt/jdk
export JAVA_HOME=~/opt/jdk
export PATH="$JAVA_HOME/bin:$PATH"

• L’archive de la distribution TosDJ (tosdj-<version>.zip), obtenue depuis les releases GitHub du projet.

2. Déployer l’archive

TosDJ sépare le répertoire d’installation (binaires, immuable) du répertoire d’instance (données, config, logs) via un fichier instance.loc — cela permet par exemple de partager un même binaire entre plusieurs instances, ou de le mettre à jour indépendamment des données.

INSTALL_DIR=~/tosdj/install
INSTANCE_DIR=~/tosdj/instance

mkdir -p "$INSTALL_DIR" "$INSTANCE_DIR"/{data,backup}
unzip -q tosdj-3.35.0.zip -d "$INSTALL_DIR"
mv "$INSTALL_DIR"/opendj/* "$INSTALL_DIR" && rmdir "$INSTALL_DIR"/opendj

echo "$INSTANCE_DIR/data" > "$INSTALL_DIR"/instance.loc

export PATH="$INSTALL_DIR/bin:$PATH"

3. Matériel TLS : autorité interne et certificat serveur

Le fichier silencieux utilisé plus bas (generateSelfSignedCertificate=false) suppose qu’un keystore PKCS12 contenant déjà un certificat serveur existe. Sans conteneur, il faut le préparer soi-même : une autorité de certification interne (à créer une seule fois, puis réutiliser pour tous les nœuds), et un certificat serveur signé par cette autorité, exporté en PKCS12.

mkdir -p ~/tosdj/pki && cd ~/tosdj/pki

# 1. Autorité de certification interne (une seule fois pour tout le parc)
openssl genrsa -out tosiamCA.key 2048
openssl req -new -x509 -days 1825 -key tosiamCA.key -out tosiamCA.crt \
  -subj "/C=FR/ST=./L=PARIS/O=TOSIT/OU=TOSIAM/CN=tosiam-ca"

# 2. Clé et CSR du serveur (à refaire pour chaque nœud)
SERVER_HOST=$(hostname -f)
openssl ecparam -name prime256v1 -genkey -noout -out server.key

cat > san.cnf <<EOF
[ req ]
distinguished_name = dn
req_extensions     = req_ext
prompt             = no
[ dn ]
CN = ${SERVER_HOST}
[ req_ext ]
subjectAltName = @alt_names
keyUsage = digitalSignature
extendedKeyUsage = serverAuth
[ alt_names ]
DNS.1 = ${SERVER_HOST}
DNS.2 = localhost
IP.1  = 127.0.0.1
EOF

openssl req -new -key server.key -out server.csr -config san.cnf
openssl x509 -req -in server.csr -CA tosiamCA.crt -CAkey tosiamCA.key -CAcreateserial \
  -out server.crt -days 365 -sha256 -extfile san.cnf -extensions req_ext

# 3. Export au format PKCS12 attendu par le silentfile
openssl pkcs12 -export -in server.crt -inkey server.key -chain -CAfile tosiamCA.crt \
  -name server-cert -out ~/tosdj/server.p12
# (mot de passe du PKCS12 demandé ici -> même valeur que KEYSTORE_PASSWORD plus bas)

rm server.csr san.cnf

Si des outils clients (scripts d’exploitation, dsreplication, ldapsearch) doivent faire confiance à ce certificat sans --trustAll, importer la CA dans le magasin de confiance de la JVM :

keytool -import -alias tosiam-ca-cert -file ~/tosdj/pki/tosiamCA.crt \
  -storepass changeit -cacerts -noprompt

4. Le fichier d’installation silencieux

Le setup de TosDJ accepte un fichier de propriétés (--propertiesFilePath) qui remplace toute interaction : c’est l’équivalent du “silent install” d’autres installeurs. Voici le fichier utilisé, avec le rôle de chaque paramètre :

cat > ~/tosdj/silentfile.txt <<'EOF'
hostname                        =@SERVER_HOST@
ldapPort                        =@LDAP_PORT@
generateSelfSignedCertificate   =false
usePkcs12keyStore               =@KEYSTORE_PATH@
keyStorePassword                =@KEYSTORE_PASSWORD@
certNickname                    =server-cert
ldapsPort                       =@LDAPS_PORT@
jmxPort                         =@JMX_PORT@
adminConnectorPort              =@ADMIN_PORT@
rootUserPassword                =@TOSDJ_ADMIN_PASSWORD@
baseDN                          =@ROOT_SUFFIX@
doNotStart                      =true
profile                         =@PROFILE@
tosiamPassword                  =@TOSIAM_DB_PASSWORD@
httpPort                        =@HTTP_PORT@
EOF

# Valeurs (reprises des valeurs par défaut de l'image Docker officielle)
sed -i \
  -e "s/@SERVER_HOST@/$(hostname -f)/g" \
  -e "s/@LDAP_PORT@/1389/g" \
  -e "s#@KEYSTORE_PATH@#$HOME/tosdj/server.p12#g" \
  -e "s/@KEYSTORE_PASSWORD@/password/g" \
  -e "s/@LDAPS_PORT@/1636/g" \
  -e "s/@JMX_PORT@/1689/g" \
  -e "s/@ADMIN_PORT@/4444/g" \
  -e "s/@TOSDJ_ADMIN_PASSWORD@/password/g" \
  -e "s#@ROOT_SUFFIX@#dc=tosit,dc=org#g" \
  -e "s/@PROFILE@/config/g" \
  -e "s/@TOSIAM_DB_PASSWORD@/password/g" \
  -e "s/@HTTP_PORT@/8080/g" \
  ~/tosdj/silentfile.txt

Remplacer les mots de passe d’exemple par de vraies valeurs avant tout usage réel — et ne jamais laisser ce fichier lisible par d’autres utilisateurs du système (chmod 600).

5. Lancer l’installation

chmod 600 ~/tosdj/silentfile.txt
"$INSTALL_DIR"/setup --cli --propertiesFilePath ~/tosdj/silentfile.txt --acceptLicense --no-prompt

• --cli : force le mode ligne de commande (pas d’interface graphique).
• --propertiesFilePath : le fichier silencieux préparé ci-dessus.
• --acceptLicense : accepte la licence sans invite.
• --no-prompt : n’invite jamais l’utilisateur, échoue plutôt que de demander une valeur manquante — le comportement recherché pour un script.

6. Reconstruction des index et démarrage

doNotStart=true a volontairement laissé le serveur arrêté après le setup, pour reconstruire tous les index avant le premier démarrage :

"$INSTALL_DIR"/bin/rebuild-index --baseDN dc=tosit,dc=org --rebuildAll
"$INSTALL_DIR"/bin/start-ds

7. Vérifier l’installation

"$INSTALL_DIR"/bin/status --bindDN "cn=Directory Manager" --bindPasswordFile <(echo password)

ldapsearch -h "$(hostname -f)" -p 1389 -D "cn=Directory Manager" -w password \
  -b "dc=tosit,dc=org" -s base "(objectclass=*)"

Pour aller plus loin

Cette procédure prépare une seule instance avec un seul profil. Pour un déploiement de production :

• Répéter l’installation avec profile=cts et profile=user sur des instances séparées si l’architecture distingue Config Store, CTS et User Store (voir Composants et couches).
• Mettre en réplication les instances d’un même profil avec dsreplication enable/initialize, et partitionner le CTS si le volume le justifie : voir Scalabilité & haute disponibilité pour le détail des commandes et des mécanismes réellement disponibles.