[Solved]Ldap error: could not create permission for app

Alaska · January 9, 2021, 12:59pm

My YunoHost server

Hardware: VPS bought online
YunoHost version: 4.1.4.1 (stable).
I have access to my server : Through SSH and through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes
If yes, please explain: I restored the full backup from the version 3.x on 4.x as i had just installed the newest version

Description of my issue

I have updated my server from debian9 to debian10 and installed the latest YUNOHOST version. After that i restored all backups. The backup told me that it couldn’t install the getgrav app as it doesn’t exist. I went for the application site in the webadmin and tried to install the app. It had an ldap error with the permission. The diagnose tool told me that some of the conf files had to be overwriten by the ‘recreate’ command. I did as told but now i get the error: “Failed to get label for app grav?” and it runs forever.

I know now after checking the shell that a grav app was installed. I removed the app and tried to reinstall it again via the webadmin. This failed with this log message:

args:
  app: grav
  args: domain=blog.maindomain.tld&path=%2Fgrav&admin=8nvx3j8rcg7acg9z7dq62t&is_public=1&language=en_EN
  force: false
  label: Grav
  no_remove_on_failure: false
ended_at: 2021-01-09 13:05:52.986002
error: 'Could not create permission ''grav.main'': error during LDAP add operation
  with: rdn=''cn=grav.main,ou=permission'', attr_dict={''cn'': ''grav.main'', ''objectClass'':
  [''top'', ''permissionYnh'', ''posixGroup''], ''isProtected'': [''FALSE''], ''showTile'':
  [''FALSE''], ''gidNumber'': ''79520'', ''label'': [''Grav''], ''authHeader'': [''TRUE'']}
  and exception {''info'': u''isProtected: attribute type undefined'', ''desc'': u''Undefined
  attribute type''}'
interface: api
operation: app_install
parent: null
related_to:
- - app
  - grav
started_at: 2021-01-09 13:05:52.875603
success: false
yunohost_version: 4.1.4.1

============

2021-01-09 14:05:52,890: INFO - grav wird installiert...
2021-01-09 14:05:52,969: INFO - <strong>Der Vorgang konnte nicht abgeschlossen werden 'Create permission 'grav''. Bitte gib das vollständige Protokoll dieser Operation mit <a href="#/tools/logs/20210109-130552-permission_create-grav">Klicken Sie hier</a> an, um Hilfe zu erhalten</strong>

when i try different apps i get the same error.

It seems i have a problem with ldap. I will look in the forum and search for a solution or does someone know how to fix this problem with ldap?

Edit: I edited this post after my discoveries.

Mon serveur YunoHost

Matériel: VPS acheté en ligne
YunoHost version: 4.1.4.1 (stable).
J’ai accès à mon serveur : Par SSH et par le webadmin
**Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance YunoHost ?
Si oui, veuillez expliquer: J’ai restauré la sauvegarde complète de la version 3.x sur 4.x car je venais d’installer la dernière version

Description de mon problème

J’ai mis à jour mon serveur de debian9 à debian10 et j’ai installé la dernière version de YUNOHOST. Après cela, j’ai restauré toutes les sauvegardes. La sauvegarde m’a dit qu’elle ne pouvait pas installer l’application getgrav car elle n’existe pas. Je suis allé sur le site de l’application dans le webadmin et j’ai essayé d’installer l’application. Il y avait une erreur ldap avec la permission. L’outil de diagnostic m’a dit que certains des fichiers de configuration devaient être écrasés par la commande “recreate”. J’ai fait ce qui m’a été dit, mais maintenant je reçois l’erreur : “Impossible d’obtenir l’étiquette pour l’application” et ça marche pour toujours.

Je sais maintenant, après avoir vérifié le shell, qu’une application grav a été installée. J’ai supprimé l’application et j’ai essayé de la réinstaller via le webadmin. Cela a échoué avec ce message de journal :

args:
  app: grav
  args: domain=blog.maindomain.tld&path=%2Fgrav&admin=8nvx3j8rcg7acg9z7dq62t&is_public=1&language=en_EN
  force: false
  label: Grav
  no_remove_on_failure: false
ended_at: 2021-01-09 13:05:52.986002
error: 'Could not create permission ''grav.main'': error during LDAP add operation
  with: rdn=''cn=grav.main,ou=permission'', attr_dict={''cn'': ''grav.main'', ''objectClass'':
  [''top'', ''permissionYnh'', ''posixGroup''], ''isProtected'': [''FALSE''], ''showTile'':
  [''FALSE''], ''gidNumber'': ''79520'', ''label'': [''Grav''], ''authHeader'': [''TRUE'']}
  and exception {''info'': u''isProtected: attribute type undefined'', ''desc'': u''Undefined
  attribute type''}'
interface: api
operation: app_install
parent: null
related_to:
- - app
  - grav
started_at: 2021-01-09 13:05:52.875603
success: false
yunohost_version: 4.1.4.1

============

2021-01-09 14:05:52,890: INFO - grav wird installiert...
2021-01-09 14:05:52,969: INFO - <strong>Der Vorgang konnte nicht abgeschlossen werden 'Create permission 'grav''. Bitte gib das vollständige Protokoll dieser Operation mit <a href="#/tools/logs/20210109-130552-permission_create-grav">Klicken Sie hier</a> an, um Hilfe zu erhalten</strong>

Il semble que j’aie un problème avec la ldap. Je vais regarder dans le forum et chercher une solution ou quelqu’un sait-il comment régler ce problème avec ldap ?

Edit : J’ai édité ce post après mes découvertes.

Aleks · January 9, 2021, 3:38pm

Can you go in Tools > Migrations in the webadmin and see if there’s still a pending migration (number 19 supposedly)

Alaska · January 9, 2021, 4:34pm

Aloha,
thanks for the question. There is no pending migration because i haven’t used this way of migration.
My steps were:

Install latest distro of debian. The drive got cleaned for a fresh start so the old version of the yunohost instance was deleted
Install latest version of yunohost and do postinstall settings
Use scp to put each backup package (mail, settings, user-data, getgrav) on the server
Restore settings first then mail and so on.
fix problems with conf files and other dns stuff i had trouble with as i had tried to use a pw with a length of 128

I asked myself if it is a good idea to restore LDAP backup on a fresh installed system. I suspect a mismatch of credentials but i have no idea.

Aleks · January 9, 2021, 5:25pm

Eeeerh yeah so it looks like there’s some database format inconsistency. It expects to be able to set an “isProtected” attribute but somehow doesn’t know this kind of isProtected parameter exists … so I’m suspecting the LDAP format is not the right one … The backup/restore system is supposed to upgrade the database format if it finds that it needs it, but somehow apparently did not …

Maybe we could try to force re-run migration 19 (even if it did not run on your system because it’s a fresh one) with

yunohost tools migrations run 0019_extend_permissions_features --force-rerun

but that’s really a wild guess / attempt

Alaska · January 10, 2021, 6:54pm

Aloha,
thanks for your help. I ran the following command and it solved my problem with LDAP:
yunohost tools migrations migrate 0019_extend_permissions_features --force-rerun

Steps i done:

Log in with admin at my server via ssh
sudo -s
then the migration command

Thanks again for the help.

GeekyOne · January 11, 2021, 6:37pm

Hello everyone, thanks for the post !
First I’ve the same symptoms as Alaska (failed to get label message after a failed upgrade and no pending migrations), so I’ve re-run the migrations 19 and still have the issue : https://paste.yunohost.org/raw/salonarona

Is something wrong with my conf.json.persistent file ?
"
{
“redirected_urls”: {}
}
{
“theme” : “mytheme”,
}
"

Thank you for the enlightening.

EDIT : huh found the issue … My persistent file was effectively not working correctly bc the theme name doesn’t match with the working one. Rename persistent as bak and regenerate ssowatconf with “yunohost app ssowatconf --debug”, then apply the Aleks command for the migration. Solved my problem ! I’ll recreate the personnalized theme later

Aleks · January 11, 2021, 9:03pm

Yes, this is not a valid JSON …

It should look like this (only one “main” block, and also pay attention to commas) … unfortunately json is really not an easy format to tell non-tech people to manually edit … :

{
“redirected_urls”: {}, 
“theme” : “mytheme”
}

Aleks · January 11, 2021, 9:04pm

I doubt this has anything to do with the actual theme name existing or not … this is purely a syntax issue.

GeekyOne · January 11, 2021, 9:32pm

I’ve corrected the persistent file, just remove the “redirected_urls” mentions and let the theme, and it works back

system · January 26, 2021, 9:32pm

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.