Piwigo users management / Gestion utilsateurs Piwigo

YunoHost configuration

Hardware: x64 vps
Internet access: in a datacenter
YunoHost version: 3.0.0.1
yunohost: 3.0.0.1
yunohost-admin: 3.0.0
moulinette: 3.0.0
ssowat: 3.0.0
Have you personalized your yunohost with some specifics configurations or do you use only the yunohost cli/webadmin tool ? basic

Version française plus bas.

Description of my problem

Hi

I would like to manage ldap and not-ldap users as I read there it was possible :
=> Multi-users support / public mode / SSO for YunoHost users / allow other users management, and guest mode

I checked /etc/yunohost/apps/piwigo/settings.yml => is_public: ‘1’

In Piwigo users management menu, my only choice is to type an ldpa name… I didn’t try, I don’t want to fuck it up.

During my investigation, I noticed strange things :

  • Yunohost admin interface says everything is up-to-date but internal Piwigo update interface says “Update to 2.9.3” !!??
  • I read in Piwigo’s settings.yml fpm_service: php5-fpm but is not installed, replaced by php7.0-fpm !!??

Context

Migration from Yunohost 2.7 to 3 was laborious : disk was full, I resized and finished migration but it seemed to be ok.

So, 2 questions :

  • how to add “Piwigo only” users ?
  • are strange things about configuration linked with laborious migration ?

Thanks


Description de mon problème

Bonjour

J’aurais voulu être un artiste gérer des utilisateurs ldap et non ldap. C’est à dire ajouté un utilisateur uniquement dans Piwigo, non géré par le SSO de Yunohost. Il me semblait que c’était possible d’après ce que j’ai lu ici :
=> Support multi-utilisateurs / mode public SSO pour les utilisateurs YunoHost / autorise la gestion d’autres utilisateurs, et le mode invité

J’ai vérifié la configuration dans /etc/yunohost/apps/piwigo/settings.yml => is_public: ‘1’

Dans la page de gestion des utilisateurs de Piwigo mon seul choix est de renseigner un nom ldap. Je n’ai pas essayer, pas envie de tout foutre en l’air.

J’ai remarqué quelques bizarreries :

  • l’interface de mise à jour de Yunohost indique que tout est à jour alors que l’interface de mise à jour de Piwigo me propose de mettre à jour vers la version 2.9.3
  • Je lis dans le fichier de settings de Piwigo fpm_service: php5-fpm mais celui-ci n’est plus installé, remplacé par php7.0-fpm

Contexte

La migration de Yunohost 2.7 vers 3 a été laborieuse : plus de place sur le disque, redimensionnement, relance de la migration, tout semblait d’aplomb.

Finalement 2 questions :

  • comment fait-on pour ajouter des utilisateurs propres à Piwigo ?
  • est-ce que mes bizarreries de configurations sont liées à la migration toute moisie ?

Merci

This is a bit weird… What is the version stated in /etc/yunohost/apps/piwigo/manifest.json?

I think this is due to our migration strategy that changed over time (keep existing PHP5 versus completely removing it now). You can safely ignore that.

I’ve just tested a user creation and it works as expected. Just consider that the Piwigo LDAP plugin shouldn’t replace every “User” occurrence by “LDAP user” in the forms, as we can also create users in Piwigo only :wink:

I don’t think so at the moment.

What is the version stated in /etc/yunohost/apps/piwigo/manifest.json?

“version”: “2.9.2-2”

as we can also create users in Piwigo only

so I will try…

Thank you for your time

The latest YunoHost version is 2.9.3~ynh1, so the update should have been proposed to you…
Could you try upgrading with yunohost app upgrade piwigo --debug?

Of course…

339  DEBUG loading actions map namespace 'yunohost'
354  DEBUG extra parameter classes loaded: ['ask', 'password', 'required', 'pattern']
354  DEBUG initializing base actions map parser for cli
355  DEBUG registering new callback action 'yunohost.utils.packages.ynh_packages_version' to ['-v', '--version']
1217 DEBUG initialize authenticator 'ldap-anonymous' with: uri='ldap://localhost:389', base_dn='dc=yunohost,dc=org', user_rdn='None'
1224 DEBUG lock has been acquired
1347 DEBUG loading python module yunohost.app took 0.123s
1347 INFO processing action [22504.1]: yunohost.app.upgrade with args={'url': None, 'app': ['piwigo'], 'auth': <moulinette.authenticators.ldap.Authenticator object at 0x7ff68e3b7210>, 'file': None}
1463 INFO Upgrading apps piwigo
1463 INFO Mise à jour de l'application piwigo...
1470 SUCCESS piwigo est déjà à jour
1470 DEBUG action [22504.1] executed in 0.123s
1470 DEBUG lock has been released
1470 ERROR Aucune application à mettre à jour

Then I think you could force the upgrade with:

yunohost app upgrade -u https://github.com/YunoHost-Apps/piwigo_ynh piwigo --debug

Here it is !

17783 WARNING Data dir won't be saved, because backup_core_only is set.
18181 WARNING Source path '/etc/fail2ban/jail.d/piwigo.conf' does not exist
18181 WARNING !!
18182 WARNING   piwigo's script has encountered an error. Its execution was cancelled.
18182 WARNING !!
18182 WARNING 
18281 WARNING Impossible de sauvegarder l'application « piwigo »
18397 WARNING Il n'y a rien à sauvegarder
18503 ERROR Impossible de mettre à jour piwigo
18504 DEBUG action [3965.1] executed in 17.576s
18504 DEBUG lock has been released
18505 ERROR Aucune application à mettre à jour

Only yunohost-jails.conf and defaults-debian.conf in /etc/fail2ban/jail.d/

Hello,

Dirty solution without risk:

touch /etc/fail2ban/jail.d/piwigo.conf
touch /etc/fail2ban/filter.d/piwigo.conf
yunohost app upgrade -u https://github.com/YunoHost-Apps/piwigo_ynh piwigo --debug

Proper solution but riskier (you need to already have a backup of piwigo in case of problem!):

NO_BACKUP_UPGRADE=1 yunohost app upgrade -u https://github.com/YunoHost-Apps/piwigo_ynh piwigo --debug

Well well

Could you give me more information please ?
Why second choice is proper than first ? Why 2 files missing ?

Thanks

If you want to dig into the details: the YunoHost migration to Debian Stretch implied to simply delete existing fail2ban configurations for apps installed before the migration. You had Piwigo installed prior to Stretch migration, hence the fail2ban configuration files got deleted.
Your problem is that the upgrade script first executes the backup script (in case of any problem), and this backup script wants to backup… the fail2ban configuration files :wink:

The second solution is a “declared” possibility to avoid executing the backup script during the upgrade… but you’re technically no more protected by the backup in case of upgrade failure.
This first solution consists in creating empty fail2ban configuration files so that the backup script gets executed successfully.

hello

I chose “Dirty solution without risk” and result is : Piwigo upgraded to 2.9.3~ynh1 but all pictures are lost !

My configuration :
I have 3 disks : one for /, one for /var and a big one for /home
I sym linked /var/www/piwigo/galleries to /home/yunohost.app/piwigo/galleries in order to deport pictures on my big disk.
I set only_core_backup to 1 because I don’t have enough space to backup data.

Result : after piwigo upgrade, /home/yunohost.app/piwigo/galleries has been deleted !
Fortunately I made a snapshot before…

Do you think this is linked with yunohost backup procedure or only linked with internal piwigo upgrade procedure ? (in order to create an issue somewhere)

Thx

In my experience, the galleries directory didn’t store anything important; all photos are stored in the upload and _data directory which are symlinked to /home/yunohost.app by the package. And that’s why the galleries directory is overwritten during upgrade…
What files did you have in that galleries directory? Are you sure photos didn’t eventually show up again?

If you set only_core_backup to 1, then obviously you hadn’t much more security with the YunoHost backup… and you need to take care of your backups by yourself.

Yes it is ! This is the default directory for “synchro method”. They call it FTP method… See there. My method is to rsync my local big family album into this distant directory and synchronize with piwigo tools to update pictures. Using this way, I can manage tags later for example and update them when I want.
I think it could be cool to manage this directory like upload and _data, no ?

Well, you’re damn right!
I didn’t suspect Piwigo could store its photos in two different directories… :thinking:

So yes, you can create an issue in Piwigo repository so that we can handle the galleries directory the same way we handle _data and upload directories :+1:

Done ! Thank you for your help.