What app is this about, and its version: Nextcloud, 32.0.5~ynh1
What YunoHost version are you running: 12.1.39
What type of hardware are you using: Old laptop or computer
The upgrade of nextcloud failed unexpectedly, apparently due to an unfulfilled dependency as the log advises ›Nextcloud or one of the apps require upgrade‹ before failing with ›An error occurred inside the app upgrade script‹. Has anyone else had problems with this update?
It seems you haven’t the valuefor ldapEmail
Normally it should be a value mail or maildrop
Can you verify if you have two ldap configurations in the admin of nextcloud =>
some time a new one which is empty is created.
what returns
yunohost app setting nextcloud enable_forward_email
Can you verify if you have two ldap configurations in the admin of nextcloud =>
some time a new one which is empty is created, you can keep just one, take care that the LDAP must have the values for communicate with LDAP Yunohost…
you can verify in a shell app
yunohost app shell nextcloud
php occ ldap:show-config s02 | grep ldapEmailAttribute
if there is a value mail or maildrop
I discovered I have also two LDAP configurations, the first one s01 is correct not the second one s02 because perhaps like you it haven’t a ldapEmailAttribute ! I have remove it the Admin nextcloud => Integration AD/LDAP
try also perhaps and see it
php occ ldap:show-config s01 | grep ldapEmailAttribute
To exit from the app shell
exit
Thank you very much, rodinux, for your help and for bringing me onto the right track! Indeed, php occ ldap:show-config only shows one configuration without prefix s01 or s02, so this is likely why the update script is unable to find the ldapEmailAttribute, although it present:
SELECT * FROM oc_appconfig WHERE appid = 'user_ldap';
+-----------+-----------------------------------+-----------------------------------------------+------+------+
| appid | configkey | configvalue | type | lazy |
+-----------+-----------------------------------+-----------------------------------------------+------+------+
...
| user_ldap | configuration_prefixes | [""] | 64 | 0 |
...
| user_ldap | ldap_configuration_active | 1 | 2 | 0 |
...
| user_ldap | ldap_email_attr | mail | 2 | 0 |
...
I remember deleting the two configurations at some point in the past, via the GUI, which then seemed like useless duplicates of the remaining config to me.
First thing that came to mind, was recreating the config prefixed with s01 or s02. Thus, on a test machine, I created an empty config with php occ ldap:create-empty-config and tried to copy the values via SQL from an existing one to the new config, then activating it. But somehow these manual changes are not persistent. And after re-connection to the DB, I only see config s01, not the modified s02. Why could this happen? Would you choose a different route?
On the other hand, I came across an issue on Github related to the config s01, apparently created during update advising to delete it. And also exchange related to testing of a pull request modifying the handling of prefixes.
Thank you for your thoughts, Daniel.
So, a closer look into the upgrade script revealed, that my situation (having ldap config without prefix used to be normal) had already been contemplated by alexAubin, thus modifying the setting ldap_config_prefix from ldap_config_prefix: s02 to ldap_config_prefix: '' was sufficient to take advantage of the upgrade logic and smoothly transition to 32.0.6!
# Before NCv32, Yunohost was not using any prefix for the LDAP config.
# This is now mandatory so we need to create a new config with a prefix.
if [ "$ldap_config_prefix" = "" ]
then
ldap_config_prefix=$(exec_occ ldap:create-empty-config --only-print-prefix)
ynh_app_setting_set --key=ldap_config_prefix --value="$ldap_config_prefix"
fi
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.