Configuration On Premises : Prérequis et installation

Cette documentation présente les étapes pour installer la solution LockSelf On-Premises.

____________________________________________________________________________________

Pour installer votre instance On Premises, deux options s'offrent à vous :

  • Installer l'application manuellement, en suivant les étapes présentées ci-après
  • Utiliser notre script d'installation, qui vous permet d'installer l'application en quelques minutes (et qui suit les mêmes étapes de cette documentation)
    • N'hésitez pas à demander le script à votre Responsable de Comptes

Dans le cas où vous optez pour le script, il vous faudra décider si vous souhaitez mettre en place votre propre instance MariaDB et créer votre base de donnée (voir point 5 de la documentation). Vous pouvez donc : 

  • Soit laisser le script d'installation générer la base de donnée sur la machine.
  • Soit mettre en place votre instance MariaDB et créer votre base de données, pour ensuite, dans le script d'installation, définir les informations de votre base de donnée manuellement.

Dans tous les cas (installation manuelle ou script), il sera important de :

  1. Connaître l'environnement Linux.
  2. Savoir manipuler un environnement Docker et être à l'aise avec docker-compose.
  3. Maitriser les commandes "docker ps", "docker exec", "docker logs", "docker images", "docker load" et toutes les commandes basiques de docker.
  4. Avoir déjà déployé et maintenu des environnements MySQL/MariaDB.
  5. Disposer d'un flux HTTPS entre un poste utilisateur et le serveur LockSelf de vérification de licence (nécessaire pour activer la clé de licence, voir étape 7)

 

1. Préambule

L’application LockSelf utilise deux composants :

  • Une API REST PHP 
  • Une base de données MariaDB

La base de données et l’API LockSelf sont déployées via Docker en utilisant respectivement les images officielles MariaDB (https://hub.docker.com/_/mariadb) et php:fpm-alpine (https://hub.docker.com/_/php).

L’image MariaDB est utilisée sans modification particulière.

L’image PHP (base Alpine) est quant à elle optimisée :

  • Compilation et configuration de Nginx
  • Configuration de PHP-FPM
  • Installation et configuration de Supervisord

Tous les processus à l’intérieur du conteneur applicatif s’exécutent avec l’utilisateur ‘nobody’. En ce qui concerne le conteneur MariaDB, l’utilisateur utilisé est ‘mysql’.

Nous conseillons de ne pas mettre les deux parties (base de données et applicatif) sur le même serveur et nous préconisons l’utilisation l’un des OS suivants :

  • Ubuntu (LTS)
  • Debian (LTS)
  • CentOS (LTS)
  • RockyLinux (LTS)

Nous recommandons les configurations suivantes : 

  • si vous utilisez 1 même serveur pour les deux parties (base de données et applicatif) = 2 CPU et 4 Go de RAM
  • si vous utilisez 2 serveurs distinct : chacun à 2 CPU et 2 Go RAM (nous recommandons néanmoins 4 Go de RAM pour le serveur de la base de données)

Les deux serveurs (base de données et applicatif) doivent avoir le package docker d’installé. Nous n’expliquerons pas comment fonctionne docker dans cette procédure, vous devez être initié à cet outil afin de correctement faire l’installation.

💡Nous préconisons un passage via Ansible du playbook hardening, qui permet de mettre en place une sécurité supplémentaire au sein du host (https://github.com/openstack/ansible-hardening).

 

2. Pré-requis

Avant de commencer l’installation du service, assurez-vous d’avoir les éléments suivants :

  • Le nom de domaine que vous souhaitez utiliser. (ex : lockself.company.com)
  • Le certificat SSL, les certificats intermédiaires et la clé privée associés à ce nom de domaine. Ces certificats seront utilisés par le serveur web de l'application pour sécuriser les échanges entres l'utilisateur et ce dernier. Dans le cadre d'une interconnexion SSO entre un AD et LockSelf, ces certificats seront exploités pour générer les metadata de l'application qui seront par la suite fournis à l'AD. Dans le cas où vos certificats contiennent des Bag Attributes et Key Attributes, merci de les supprimer.
  • Les informations d’authentification et de connexion à votre SMTP (qui servira à envoyer les emails systèmes relatif à l’utilisation de l’application)

Si vous souhaitez mettre en place une interconnexion sur un annuaire d’entreprise, nous utilisons le protocole SAMLv2. Il faut donc vous assurez d’avoir à disposition un module de type ADFS pour Active Directory, OpenID pour OpenLDAP ou les modules SAMLv2 inclus dans Azure ou Office 365.

 

3. Description de l’infrastructure simplifiée

mceclip0.png

💡L’installation de LockSelf peut également se faire en mode cluster, pour la partie applicative et pour la partie base de données.

 

4. Matrice de flux de réseaux

Les flux à mettre en place pour les différents serveurs sont :

Serveur Entrant Sortant
Applicatif 443 depuis l'extérieur 25, 465 ou 587 vers votre serveur SMTP
Base de données 3306 depuis le subnet des serveurs applicatifs  

 

5. Installation du premier composant : La base de données MariaDB

5.1. Action à réaliser sur le serveur de base de données – Étape 1

Pour le déploiement du conteneur de base de données, trois possibilités. À vous de choisir laquelle vous souhaitez utiliser suivant les préconisations de l’entreprise.

5.1.1. Lancement manuel

docker run \
--name mariadb \
-v /var/lib/mysql:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=my-secret-pwd \
-e MYSQL_DATABASE=lockself \
-p 3306:3306 \
-d mariadb:10.6.X
  • --name : correspond au nom du conteneur une fois créé
  • -v : correspond au volume monté permettant la persistance des données
  • -e : MYSQL_ROOT_PASSWORD – remplacer « my-secret-pwd » par le mot de passe qui sera associé à l’utilisateur root au premier lancement du conteneur
  • -e : MYSQL_DATABASE – « lockself » correspond au nom de la base de données créée au premier lancement du conteneur
  • -p : permet au serveur host de forward les requêtes sur le port 3306 au conteneur
  • -d : permet au conteneur de se lancer en background
  • mariadb:10.6.X : correspond à la version de l’image MariaDB utilisée

Les variables d’environnements option -e sont prises en compte uniquement lors du premier démarrage du conteneur. Si des datas sont présentes dans /var/lib/mysql, ces valeurs ne seront pas prises en compte et n’auront aucun effet.

⚠️ Attention, la version de l’image est à adapter suivant la version 10.6 en cours de MariaDB.

5.1.2. Lancement via docker-composer

Si vous souhaitez utiliser docker-compose pour démarrer le conteneur de base de données, vous pouvez utiliser le fichier de configuration docker-compose.yml ci-dessous :

version : '3.8'
services:
mariadb:
image: mariadb:10.6.X
restart: always
volumes:
- "/var/lib/mysql:/var/lib/mysql"
ports :
- "3306:3306"
environment:
MYSQL_ROOT_PASSWORD: my-secret-pwd
MYSQL_DATABASE: lockself

Une fois le fichier de configuration récupéré sur le serveur host, vous pourrez démarrer le conteneur via la commande suivante :

docker-compose up -d --build
⚠️ Attention, la version de l’image est à adapter suivant la version 10.6 en cours de MariaDB.

 5.1.3. Lancement via docker-swarm

Si vous souhaitez utiliser docker-swarm pour démarrer le conteneur de base de données, vous pouvez utiliser le fichier de configuration yaml ci-dessous :

version: '3.7'

services:
mariadb:
image: mariadb:10.6.X
ports:
- target: 3306
published: 3306
protocol: tcp
mode: host
environment:
MYSQL_ROOT_PASSWORD: my-secret-pwd
MYSQL_DATABASE: lockself
volumes:
- "/var/lib/mysql:/var/lib/mysql"

Swarm peut s’utiliser de plusieurs façons que nous ne détaillerons pas dans cette procédure. Vous pourrez retrouver tous les détails concernant son fonctionnement sur son site officiel : https://docs.docker.com/engine/swarm/

⚠️ Attention, la version de l’image est à adapter suivant la version 10.6 en cours de MariaDB. Afin de pouvoir déployer via ce mécanisme, vous pouvez être amené à rajouter des options, tels que le network, le deploy etc.

5.2. Explications relatives à l'étape 5.1

5.2.1. Point obligatoire pour le bon fonctionnement de l'application

Afin d’obtenir une persistance des données, le montage d’un volume est nécessaire afin de partager le dossier /var/lib/mysql du conteneur (qui contient les datas de la db) avec le host.

Ce point de montage se fait via l’option -v ou volumes suivant le mode de lancement choisi.

A l’étape 5.1, nous utilisons le point de montage suivant : /var/lib/mysql:/var/lib/mysql

Optionnel : Dans le cas où le SELinux est activé sur les serveurs host, une modification des droits doit être effectuée sur les différents fichiers :

chcon -Rt svirt_sandbox_file_t /var/lib/mysql

Dans cet exemple, les données MariaDB qui sont stockées dans le conteneur dans le dossier /var/lib/mysql seront également stockées sur le host dans le dossier /var/lib/mysql.

5.2.2. Pour en savoir plus sur les volumes

https://docs.docker.com/storage/volumes/

5.3. Action à réaliser sur le serveur de base de données – Étape 2

Cette étape est à réaliser sur le serveur de base de données une fois le conteneur MariaDB démarré, fin de préparer le script d’ajout d’utilisateur.

Pour cela, récupérez le script ci-dessous et modifier les valeurs suivantes :

  • PASSWORD – A remplacer par les mots de passe que vous souhaitez associer aux users.
  • IP – A remplacer par l’IP/Range des serveurs applicatifs. Attention à être sûr de l’IP de sortie qui sera utilisée. Suivant les architectures, les serveurs applicatifs peuvent sortir depuis l’IP du conteneur (généralement en 172.X) ou depuis l’IP du serveur host.
-- Create user www. It used by the application to read the db.
-- IP has to be modified with the IP/Range of the application servers.
-- PASSWORD has to be modified with the password you want to give to this user.
CREATE USER 'www'@'IP' IDENTIFIED BY 'PASSWORD';

-- Grant rights to the www user.
-- Replace IP with the IP/Range of the application servers.
GRANT SELECT,INSERT,UPDATE,DELETE ON lockself.* TO 'www'@'IP';

-- Create user lockself_migration. It used by the application to migrate the db.
-- IP has to be modified with the IP/Range of the application servers.
-- PASSWORD has to be modified with the password you want to give to this user.
CREATE USER 'lockself_migration'@'IP' IDENTIFIED BY 'PASSWORD';

-- Grant rights to the lockself_migration user.
-- Replace IP with the IP/Range of the application servers.
GRANT SELECT,INSERT,UPDATE,DELETE,ALTER,CREATE,DROP,INDEX ON lockself.* TO 'lockself_migration'@'IP';

Pour rappel, l’utilisateur root et la création de la base de données sont réalisés par les variables d’environnements lors du premier lancement du conteneur.

💡 Vous pouvez si vous le souhaitez créer d’autres utilisateurs pour vos besoins de backup, monitoring etc.

5.4. Action à réaliser sur le serveur de base de données – Étape 3

Une fois le script ci-dessus modifié et adapté à vos besoins, exécutez la commande ci-dessous afin de créer les utilisateurs dans la base de données :

docker exec -i mariadb sh -c 'exec mysql -uroot -pmy-secret-pwd' < create_user.sql

  • mariadb est à modifier avec le nom du conteneur choisi (nom choisi à l’étape 5.1)
  • my-secret-pwd est à modifier avec le mot de passe root
  • create_user.sql est à modifier par rapport au nom du fichier contenant le script SQL ci-dessus

 

6. Installation du second composant : L’application LockSelf

6.1. Préambule

Tout d’abord, il faut récupérer le package fourni par les équipes LockSelf et vérifier son intégrité. Ce package comprend :

  • L’image du conteneur : lockself-api-X.X.X.tar.gz
  • La signature de l’image du conteneur : lockself-api-X.X.X.tar.gz.sig
⚠️ Avant toutes opérations, vous devez vérifier la signature apposée sur l’image du conteneur.

6.2. Action à réaliser sur le serveur applicatif – Étape 1

La première étape consiste à créer une paire de clé RSA. Celle-ci sera utilisée par l’application LockSelf. Ces clés sont à stocker sur le serveur, nous nous en servirons en étape 6.5.

openssl genpkey -out private.pem -aes256 -algorithm rsa -pkeyopt rsa_keygen_bits:4096

Pour la passphrase demandée pendant l'execution de cette commande, nous préconisons une passphrase aléatoire de 32 caractères alphanumériques avec caractères spéciaux. Cette passphrase vous sera demandée en étape 6.3.

openssl pkey -in private.pem -out public.pem -pubout

La première commande permet la création de la clé privée RSA (4096 bits) et la chiffre en AES256 avec la passphrase spécifiée.

La seconde permet d’extraire la clé public associée.

6.3. Action à réaliser sur le serveur applicatif – Étape 2

Récupérez le script install_lockself.sh en annexe de document (13.1) sur le serveur et exécutez-le. Plusieurs informations vous seront demandées. A la fin d’exécution du script, vous récupérerez un fichier nommé env qui nous servira à l’étape 6.5.

Le fichier d’environnement généré env contient notamment les salts de chiffrement et les variables relatives à votre infrastructure on-premises.

6.4. Avant le déploiement du conteneur

Avant le déploiement du conteneur, vérifiez que vous avez les informations suivantes disponibles sur le serveur web :

  • Le fichier env (par exemple dans : /home/user/lockself/env) généré par le script install_lockself.sh (Étape 6.3)

  • Dans un dossier (par exemple : /home/user/lockself/ssl/), les certificats SSL (pour rappel: Dans le cas où vos certificats contiennent des Bag Attributes et Key Attributes, merci de les supprimer):

    • Le certificat suivi de la chaine de certification sous le nom : ssl-certificate.crt
    • La clé privée non chiffrée sous le nom : ssl-certificate.key
    • Seulement dans le cadre d'une connexion SSO :
      • Le certificat SANS la chaine de certification sous le nom : sp.crt
  • Dans un dossier (par exemple : /home/user/lockself/jwt/) la paire de clé RSA générée à l’étape 6.2 :

    • La clé privée sous le nom : private.pem
    • La clé publique sous le nom : public.pem
  • Un dossier qui servira à stocker les fichiers et qui les rendra permanent en cas de redémarrage du conteneur (par exemple : /home/user/lockself/files).

  • Optionnel : Dans le cas où le SELinux est activé sur les serveurs host, une modification des droits doit être effectuée sur les différents fichiers :
    • chcon -Rt svirt_sandbox_file_t /home/user/lockself/jwt
    • chcon -Rt svirt_sandbox_file_t /home/user/lockself/ssl
    • chcon -Rt svirt_sandbox_file_t /home/user/lockself/env
    • chcon -Rt svirt_sandbox_file_t /home/user/lockself/files

6.5. Action à réaliser sur le serveur applicatif – Étape 3

Charger l’image LockSelf sur le serveur web :

docker load --input lockself-api-X.X.X.tar.gz

Pour le déploiement du conteneur applicatif, trois possibilités. À vous de choisir laquelle vous souhaitez utiliser suivant les préconisations de l’entreprise.

6.5.1. Lancement manuel

docker run \
--name lockself-api-3 \
-v /home/user/lockself/jwt:/usr/local/var/www/html/config/jwt \
-v /home/user/lockself/ssl:/usr/local/etc/nginx/ssl \
-v /home/user/lockself/env:/usr/local/var/www/html/.env \
-v /home/user/lockself/files:/usr/local/var/www/html/var/glutton \
-v /home/user/lockself/ssl/sp.crt:/usr/local/var/www/html/vendor/onelogin/php-saml/certs/sp.crt \
-v /home/user/lockself/ssl/ssl-certificate.key:/usr/local/var/www/html/vendor/onelogin/php-saml/certs/sp.key \
-p 80:8080 \
-p 443:4443 \
-d lockself-api-v3:X.X.X
  • --name : correspond au nom du conteneur une fois créé
  • -v : correspond aux volumes montés
  • -p : permet à l’host de forward les requêtes sur le port 80 et 443 au conteneur
  • -d : permet au conteneur de se lancer en background
  • lockself-api-v3:X.X.X : correspond à la version de l'image LockSelf utilisée
⚠️ Attention à correctement adapter le tag de l’image, ainsi que les paths relatifs aux volumes. Les deux derniers points de montage sont à effectuer uniquement pour faire fonctionner une connexion SSO.

6.5.2. Lancement via docker-compose

Si vous souhaitez utiliser docker-compose pour démarrer le conteneur applicatif, vous pouvez utiliser le fichier de configuration docker-compose.yml ci-dessous :

version: '3.8'

services:
lockself-api-3:
image: lockself-api-v3:X.X.X
restart: always
volumes:
- "/home/user/lockself/jwt:/usr/local/var/www/html/config/jwt"
- "/home/user/lockself/ssl:/usr/local/etc/nginx/ssl"
- "/home/user/lockself/env:/usr/local/var/www/html/.env"
- "/home/user/lockself/files:/usr/local/var/www/html/var/glutton"
- "/home/user/lockself/ssl/sp.crt:/usr/local/var/www/html/vendor/onelogin/php-saml/certs/sp.crt"
- "/home/user/lockself/ssl/ssl-certificate.key:/usr/local/var/www/html/vendor/onelogin/php-saml/certs/sp.key"
ports :
- "80:8080"
- "443:4443"

Une fois le fichier de configuration récupéré sur le serveur host, vous pourrez démarrer le conteneur via la commande suivante :

docker-compose up -d --build
⚠️ Attention à correctement adapter le tag de l’image, ainsi que les paths relatifs aux volumes. Les deux derniers points de montage sont à effectuer uniquement pour faire fonctionner une connexion SSO.

6.5.3. Lancement via docker-swarm

Si vous souhaitez utiliser docker-swarm pour démarrer le conteneur de base de données, vous pouvez utiliser le fichier de configuration yaml ci-dessous :

version: '3.7'

services:
lockself-api-3:
image: lockself-api-v3:X.X.X
ports:
- target: 8080
published: 80
protocol: tcp
mode: host
- target: 4443
published: 443
protocol: tcp
mode: host
volumes:
- "/home/user/lockself/jwt:/usr/local/var/www/html/config/jwt"
- "/home/user/lockself/ssl:/usr/local/etc/nginx/ssl"
- "/home/user/lockself/env:/usr/local/var/www/html/.env"
- "/home/user/lockself/files:/usr/local/var/www/html/var/glutton"
- "/home/user/lockself/ssl/sp.crt:/usr/local/var/www/html/vendor/onelogin/php-saml/certs/sp.crt"
- "/home/user/lockself/ssl/ssl-certificate.key:/usr/local/var/www/html/vendor/onelogin/php-saml/certs/sp.key"

Swarm peut s’utiliser de plusieurs façons que nous ne détaillerons pas dans cette procédure. Vous pourrez retrouver tous les détails concernant son fonctionnement sur son site officiel : https://docs.docker.com/engine/swarm/

⚠️ Attention à correctement adapter le tag de l’image, ainsi que les paths relatifs aux volumes. Les deux derniers points de montage sont à effectuer uniquement pour faire fonctionner une connexion SSO. Vous pouvez également être amené à rajouter des options, tels que le network, le deploy etc.

Les migrations de base de données (incluant la création de la structure) seront faites automatiquement au lancement du conteneur. Vérifiez que ce dernier soit bien démarré en exécutant la commande : 

  • docker logs -f CONTAINER_ID

 

7. Créer le compte administrateur

Une fois l'infrastructure en place, vous aurez la possibilité de créer votre compte administrateur. Pour ce faire, rendez-vous sur l'URL ci-dessous et remplissez les informations demandées :

https://FQDN/external/users/validate-account/index.html?firstCo

Où FQDN est le nom de domaine que vous exploitez

Demandez la clé de licence à votre Responsable de Comptes.

Afin d'activer la clé de licence, vous devrez posséder un ordinateur qui aura une connexion internet vers notre système de licence. Le nom de domaine et l'IP de ce serveur pourra vous être fourni par votre Responsable de Comptes.

 

8. Backup

Deux éléments sont importants à sauvegarder en lieu sûr une fois l’installation terminée :

  • Le fichier env généré à l'étape 6.3.
    • Ce fichier comporte les fichiers de configuration indispensable au bon fonctionnement de votre installation. Ces fichiers une fois générés ne pourront pas être régénérés à l’identique. Si vous veniez à perdre ceux-ci, les informations contenues dans la base de données deviendraient indéchiffrables.
  • La base de données

Nous recommandons d’appliquer un chiffrement (symétrique ou asymétrique) pour le backup de ces deux composants.

 

9. Interconnecter l'application en SSO

Afin de connecter l'application en SSO, vous pouvez suivre la documentation suivante : Configuration de l'interconnexion SSO

9.1. Synchronisation des groupes

Si vous envoyez via la Fédération les groupes des utilisateurs et que vous voulez que ceux-ci soient synchronisés dans LockSelf, il vous faudra changer dans le fichier env le paramètre suivant : (attention à ce que la claim groups soit bien envoyée par la Fédération) :

intercoAd=0 par intercoAd=1

Si vous souhaitez ne pas récupérer l'entièreté des groupes de votre annuaire, vous pouvez choisir un prefix où seul les groupes ayant ce prefix seront récupérés par LockSelf. La variable suivante sera à remplacer dans le fichier env :

intercoAdPrefix='' par intercoAdPrefix='MY_PREFIX'

Redémarrez ensuite le conteneur.

9.2 Vérifier la connexion

Si toutes les étapes ont été correctement effectuées, vous aurez la possibilité de faire une connexion depuis l'onglet SSO de l'application.

 

10. Annexes

Annexe 1 - install_lockself.sh

#!/bin/bash
# This script will configure your LockSelf installation
# It will create a env file. This file will be mount in your container.
# Maintener: LockSelf SAS <contact@lockself.com>

if [ -f $PWD/env ]
then
printf "You already have a LockSelf installation. Be careful to dont lose the '~/env' file. Without it, it will be impossible to access your datas. If you're sure to would reinstall LockSelf, delete the ~/env file and relaunch this script."
exit 1
fi

printf " _ _ _____ _ __ \n"
printf "| | | | / ____| | |/ _|\n"
printf "| | ___ ___| | _| (___ ___| | |_ \n"
printf "| | / _ \ / __| |/ /\___ \ / _ \ | _|\n"
printf "| |___| (_) | (__| < ____) | __/ | | \n"
printf "|______\___/ \___|_|\_\_____/ \___|_|_| \n\n"

printf "Welcome to the LockSelf's on-premises installation program\n"
printf "First, we will configure the database informations (applicative account - step 5.3):\n\n"

while [[ $dbHost == "" ]]
do
printf "DB Host: > " && read dbHost
done
while [[ $dbName == "" ]]
do
printf "DB Name: > " && read dbName
done
while [[ $dbUser == "" ]]
do
printf "DB User (applicative account): > " && read dbUser
done
while [[ $dbPassword == "" ]]
do
printf "DB Password (applicative account): > " && read -s dbPassword
done
while [[ $dbPassword2 == "" ]]
do
printf "\nVerify your DB Password (applicative account): > " && read -s dbPassword2
done
if [[ $dbPassword != $dbPassword2 ]]
then
printf "\nThe two passwords are not corresponding. Please relaunch the installation."
exit 1
fi
printf "\n\nNow, lets configure the database informations for the user lockself_migration: (step 5.3)\n"
while [[ $dbPasswordPhinx == "" ]]
do
printf "DB Password lockself_migration: > " && read -s dbPasswordPhinx
done
while [[ $dbPassword2Phinx == "" ]]
do
printf "\nVerify your DB Password lockself_migration: > " && read -s dbPassword2Phinx
done
if [[ $dbPasswordPhinx != $dbPassword2Phinx ]]
then
printf "\nThe two passwords are not corresponding. Please relaunch the installation."
exit 1
fi
printf "\n\nPlease now enter the passphrase choosen for the JWT: (step 6.2)\n"
while [[ $jwtPassphrase == "" ]]
do
printf "Write your JWT Passphrase: > " && read -s jwtPassphrase
done
while [[ $jwtPassphrase2 == "" ]]
do
printf "\nVerify your JWT Passphrase: > " && read -s jwtPassphrase2
done
if [[ $jwtPassphrase != $jwtPassphrase2 ]]
then
printf "The two passwords are not corresponding. Please relaunch the installation."
exit 1
fi
printf "\n\nLet's configure the SMTP connexion (it will be used to send the system email):\n"
while [[ $smtpHost == "" ]]
do
printf "SMTP Host: > " && read smtpHost
done
while [[ $smtpPort == "" ]]
do
printf "SMTP Port: > " && read smtpPort
done
while [[ $smtpAuth == "" ]]
do
printf "SMTP Auth: (true or false) > " && read smtpAuth
done
if [ $smtpAuth == "true" ]
then
while [[ $smtpUsername == "" ]]
do
printf "SMTP Username: > " && read smtpUsername
done
while [[ $smtpPassword == "" ]]
do
printf "SMTP Password: > " && read smtpPassword
done
else
smtpUsername=""
smtpPassword=""
fi
while [[ $smtpSsl == "" ]]
do
printf "SMTP SSL: (ssl or tls or null) > " && read smtpSsl
done
if [ $smtpSsl == "null" ]
then
smtpSsl=""
fi
while [[ $smtpNoReply == "" ]]
do
printf "No-reply address: (ex: no-reply@company.com) > " && read smtpNoReply
done
printf `date`
printf "\nSMTP configuration terminated\n"
printf "\n\nLast thing, specify the domain you want to use:"
while [[ $domain == "" ]]
do
printf "\nDomain: (ex: lockself.company.com) > " && read domain
done

/bin/cat <<EOF > $PWD/env
###> symfony/framework-bundle ###
APP_ENV=prod
APP_DEBUG=0
APP_SECRET=62ab7ba420f13ef7f912d270c2a40ee0
###< symfony/framework-bundle ###

###> lexik/jwt-authentication-bundle ###
JWT_SECRET_KEY=%kernel.project_dir%/config/jwt/private.pem
JWT_PUBLIC_KEY=%kernel.project_dir%/config/jwt/public.pem
JWT_PASSPHRASE="$jwtPassphrase"
JWT_TTL=604800
###< lexik/jwt-authentication-bundle ###

###> doctrine/doctrine-bundle ###
DATABASE_URL='mysql://$dbUser:$dbPassword@$dbHost:3306/$dbName'
###< doctrine/doctrine-bundle ###

###> robmorgan/phinx ###
PHINX_USER='lockself_migration'
PHINX_PASSWORD='$dbPasswordPhinx'
PHINX_HOST='$dbHost'
PHINX_PORT='3306'
PHINX_DB_NAME='$dbName'
###< robmorgan/phinx ###

###> LockSelf ###
debug=0
domain=$domain
saltPassword1="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltPassword2="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltPin1="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltPin2="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
keyPin="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 32 ; echo)"
ivPin="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltApiHash1="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltApiHash2="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
sampleHash="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
blockConnexionInSecond=900
pinLength=6
saltTransfer1="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltTransfer2="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltTransferProtectedEmail1="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltTransferProtectedEmail2="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltDeposit1="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltDeposit2="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltMail1="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
saltMail2="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%&()+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 16 ; echo)"
bucket=
providerAccessKey=
providerSecretKey=
providerRegion=
providerEndpoint=
provider=LOCAL
depositTokenTime=15
noReplyEmail='$smtpNoReply'
colorBtn='#39499b'
companyName="LockSelf"
nameDepositBox="Access to a deposit box"
newFileDeposit="New file uploaded"
newTransfer="New protected file received"
apiVersion=3
intercoAd=0
intercoAdPrefix=''
importOrganization=0
importOrganizationSendEmail=0
intercoAdOrganizations=0
###< LockSelf ###

###> symfony/swiftmailer-bundle ###
MAILER_URL=smtp://$smtpHost:$smtpPort?encryption=$smtpSsl&username=$smtpUsername&password=$smtpPassword
###< symfony/swiftmailer-bundle ###

###> ovh/ovh ###
smsApplicationKey=
smsApplicationSecret=
smsConsumerKey=
smsEndpoint=
###< ovh/ovh ###

###> knplabs/knp-snappy-bundle ###
WKHTMLTOPDF_PATH=/usr/local/bin/wkhtmltopdf
WKHTMLTOIMAGE_PATH=/usr/local/bin/wkhtmltoimage
###< knplabs/knp-snappy-bundle ###

EOF

printf "\n\nStep 6.3 terminated. If you want to review your config file, like your smtp or database configuration, you can check the 'env' file which is created by this script or you can continue the deployment guide."

Mise à jour