[Bug]: LDAP migration failing NC27->NC28 involving ldap_group_members table
#43584
Comments
elr3m
added
0. Needs triage
|
Are background jobs disabled somehow in your staging environment by chance? Or maybe staging was off and just recently turned on so it hasn't had a chance to run before trying to update to v28? There's an hourly I'm assuming staging has it's own functioning ldap setup otherwise. :-) |
joshtrichards
changed the title
|
Thank you for your answer, I would like to do the 28 upgrade on Production and that issue worries me quite a bit :) .
Background jobs were not disabled.
Is there a way to "fill the table" manually? FYI, I am not able to use |
|
Looks like some sort of interaction with the recent migration changes to the the group membership data from #39446 & #42576. I'm not particularly familiar with what's going on here. Hey @come-nc: I'm kind of stabbing in the dark, but given the broad server/apps/user_ldap/lib/Migration/Version1190Date20230706134108.php Lines 111 to 116 in 9c00d12 server/apps/user_ldap/lib/Migration/Version1190Date20230706134108.php Lines 100 to 104 in 9c00d12 Or is this a situation where this should never happen and you think something else is probably going on here? |
joshtrichards
changed the title
ldap_group_members table
joshtrichards
changed the title
ldap_group_members tableldap_group_members table
|
It’s quite unexpected for this unserialize call to return false. @joshtrichards I did not think it was possible for this column to not contain a serialized array, but yes I think we can ignore it and count on the background job to fill the new table later instead. |
|
@come-nc Thank you for your answer, here are a screenshot of the query: Let me know if you need more information! |
|
There is only one line? I do not understand how it could get false when unserializing in this case, unless the data is corrupted. |
|
Yes indeed, one line only, is there a way to re-generate the line? Or maybe there is a character in one of the username that breaks the serialization? |
|
Can you double-check the encoding on your database, @elr3m? I can't |
|
I’d be surprised if PHP produced a serialization it’s not able to unserialize. Maybe an encoding thing indeed. You can simply delete the line, the background job should recreate the info in the new table. I guess I’ll edit the migration to ignore unserialization failures. |
@joshtrichards It is currently utf8mb4_general_ci
@come-nc , I will do that today (PT) and report back here. Thank you both. |
|
FYI: we're regularly seeing errors originating from failed de-serialization, like the following, since at least NC 25:
Our updates failed with the same errors. Emptying the oc_ldap_group_members table made the update work. |
|
Indeed, deleting the line seems to resolve the issue, as I was able to enable the I went and checked on the The solution being found, I am not sure what to do with this GitHub issue (change status, close...). Let me know what should I do with it, if anything. |
Leave this issue open, I will close after merging a PR for ignoring unserialize failure. |
Bug description
During the 27.1.6 to 28.0.2 upgrade, the process failed because of the user_ldap app.
I disabled user_ldap app with occ and was able to proceed with the rest of the upgrade.
After that I get the below error message when trying to re-enable user_ldap .
Not sure what a boolean is returned there, my php knowledge is very limited so I am not sure what the query actually is (LDAP or MySQL?).
Any ideas?
Please do let me know if I am missing something or if more specific logs needs to be uploaded to help.
This is a staging instance of Nextcloud, production is untouched and working fine on 27.1.6.
Steps to reproduce
Error:
Expected behavior
Ability to enable user_ldap
Installation method
Community Manual installation with Archive
Nextcloud Server version
28
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "cloud-stg.kqed.org" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "version": "28.0.2.5", "overwrite.cli.url": "https:\/\/cloud-stg.kqed.org", "htaccess.RewriteBase": "\/", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "auth.webauthn.enabled": false, "ldapIgnoreNamingRules": false, "maintenance": false, "memcache.local": "\\OC\\Memcache\\APCu", "memcache.locking": "\\OC\\Memcache\\Redis", "filelocking.enabled": "true", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 0, "timeout": 0 }, "lost_password_link": "disabled", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_smtpmode": "smtp", "mail_sendmailmode": "smtp", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "587", "twofactor_enforced": "true", "twofactor_enforced_groups": [ "admin" ], "twofactor_enforced_excluded_groups": [], "theme": "", "loglevel": 0, "enabledPreviewProviders": [ "OC\\Preview\\Image", "OC\\Preview\\Movie", "OC\\Preview\\TXT" ], "default_phone_region": "US", "updater.release.channel": "stable", "app_install_overwrite": [ "twofactor_admin", "workflow_pdf_converter", "files_trackdownloads", "extract", "impersonate", "user_ldap" ], "mysql.utf8mb4": true, "mail_smtpauthtype": "LOGIN", "mail_smtpauth": 1, "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "updater.secret": "***REMOVED SENSITIVE VALUE***" } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
I have tried taking a Database from the production environment and it fails all the same.
SSO is used to authenticate and LDAP is used to permit create the NC account.
Those 2 have been working along side for 2 or 3 major versions.
The text was updated successfully, but these errors were encountered: