Je tente depuis plusieurs jours de mettre en place Wallabag latest (2.3.6) couplé au travail d’Immae réalisé pour pouvoir authentifier les utilisateurs Wallabag sur mon OpenLDAP et ainsi mieux intégrer l’appli au sein de mon infra.
Le problème c’est que je ne m’en sors pas entre les git rebase, les composer update / composer require fr3d/ldap-bundle et les make install LDAP_ENABLED=true
Le make a tendance à relancer un git pull et écraser toute la partie LDAP.
J’ai fini par testé depuis le fork maintenu sur https://github.com/wallabag/wallabag/pull/3263 mais je n’arrive toujours pas à m’idientifier (les logs montrent un filtre ldap différent de ce que j’ai dans app/config/parameters.yml).
Bref, j’ai beau tester à droite à gauche, pour l’instant j’ai pas grand chose à me mettre sous la dent… Du coup si quelqu’un a réussi, ca m’intéresse beaucoup (et pourrait faire l’objet d’un article pour la litière
Bonjour @popi
Je viens de mettre à jour mon fork de wallabag qui implémente l’authentification par LDAP. Tu peux le trouver ici : https://git.immae.eu/cgit/github/wallabag/wallabag.git/log/?h=gitolite_local/ldap
Note qu’il y a une grosse différence entre le dépôt git et la « release » telle que tu peux la télécharger sur le site de wallabag . Pour éviter de builder le paquet toi-même, je t’invite à faire ainsi :
Télécharger la release 2.3.6 et la décompresser là où tu veux (tu peux utiliser une installation déjà existante)
Installer composer
Les différentes actions dans la suite sont à lancer en tant que l’utilisateur du serveur web (wwwdata, wwwrun, httpd, autre). Il faut les droits d’écriture dans le dossier de wallabag
php -d memory_limit=-1 /path/to/composer.phar require --update-no-dev -o --prefer-dist fr3d/ldap-bundle
malheureusement, la mémoire de composer n’est pas très bien gérée, il va prendre presque 2Go de RAM juste pour ajouter une malheureuse dépendance, d’où le memory_limit=-1. Je ne voulais pas packager le composer.lock avec ldap directement parce que je voulais que ça reste « optionnel », et je n’ai toujours pas fait le changement, my bad
Il va probablement te poser des questions sur la configuration ldap (sinon lance composer install pour que ça se fasse), réponds-y. A priori la seule configuration qui peut être déroutante est le ldap_filter: il te permet de filtrer les utilisateurs ayant accès à wallabag (chez moi, c’est un subset des utilisateurs ldap). Si tu n’es pas à l’aise avec ce genre de choses, mets (objectClass=*) ça autorisera tous les utilisateurs. ldap_admin_filter c’est pour désigner les utilisateurs qui en plus sont admin de wallabag. Si tu mets null, personne n’est admin
./bin/console --env=prod doctrine:migrations:migrate et confirmer (il y a une modification de la bdd pour implémenter ldap)
Ensuite, tu fais comme d’habitude pour migrer les fichiers téléchargés (si pertinent)
Ensuite pour migrer les utilisateurs déjà existant, il te suffit d’aller dans la base de donnée, aller dans la table user et ajouter dans la colonne dn le dn ldap de l’utilisateur correspondant. Il n’y a pas de méthode automatisée pour cela.
J’ai suivi rigoureusement tes instructions et n’ai eu qu’une erreur lors du composer require qui ne s’est pas reproduite en faisant un composer install (cf ci-dessous).
Je remet l’ensemble des commandes et résultats ici en référence (exécuté sur un conteneur LXC sous Debian Stretch).
cd ~/release_2.3.6/
wget https://github.com/wallabag/wallabag/archive/2.3.6.zip
unzip 2.3.6.zip
cd wallabag-2.3.6
curl -o wallabag-ldap.patch "https://git.immae.eu/?p=github/wallabag/wallabag.git;a=patch;h=1f1a8e18ef0a171d83c0b86ea0c81dfb05fe87b0"
patch -p1 -i wallabag-ldap.patch
composer require --update-no-dev -o --prefer-dist fr3d/ldap-bundle
[..]
[error output]
Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache handling the post-cmd event terminated with an exception
Je relance un composer install, et ça passe cette fois:
composer install
[output]
[OK] Cache for the "dev" environment (debug=true) was successfully cleared.
> Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installAssets
Trying to install assets as relative symbolic links.
--- ------------------------------ ------------------
Bundle Method / Error
--- ------------------------------ ------------------
✔ NelmioApiDocBundle relative symlink
✔ CraueConfigBundle relative symlink
✔ WhiteOctoberPagerfantaBundle relative symlink
✔ FOSJsRoutingBundle relative symlink
--- ------------------------------ ------------------
[OK] All assets were successfully installed.
Pour finir, la migratino DB pour gérer les entrée LDAP:
./bin/console --env=prod doctrine:migrations:migrate
Application Migrations
WARNING! You are about to execute a database migration that could result in schema changes and data lost. Are you sure you wish tocontinue? (y/n)y
Migrating up to 20171125164500 from 20171125164500
++ migrating 20170710113900
-> ALTER TABLE wallabag_user ADD dn LONGTEXT DEFAULT NULL
++ migrated (14.29s)
Pour bien repartir sur des bases fraîches, je redémarre apache et php-fpm, et c’est tout bon
Note que wallabag écrit des fichiers dans ./var (cache, logs), ./data (probablement une base sqlite quand pertinent, jamais rien vu d’autre encore) et ./web/assets (des images-icones téléchargées comme aperçu).
Ce dernier est probablement à conserver lors des upgrades si tu ne veux pas te retrouver avec des images manquantes
