Cloudron Forum

@nebulon I definitely did not set it manually.

@nebulon Thanks, all done!
Your solution with MIGRATION_IGNORE_INVALID_OTP_SECRET=true /app/pkg/start.sh works perfectly.

Steps:

• Update to 4.3.0 (don’t forget to enable back up!)
• Enable Recovery Mode in Cauldron's app admin panel
• Run the command above (as suggested by @nebulon)
• Disable Recovery Mode.

2FA also works after migration; I tested it on several older accounts.
Thanks a lot!

I checked the OTP_SECRET value - it is the same before and after the update. Still the same error:

Oct 22 00:56:25 ==> Configuring mastodon
Oct 22 00:56:25 ==> Migrating database
Oct 22 00:56:25 ACTIVE_RECORD_ENCRYPTION_DETERMINISTIC_KEY=*************
Oct 22 00:56:25 ACTIVE_RECORD_ENCRYPTION_KEY_DERIVATION_SALT=************
Oct 22 00:56:25 ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY=**************
Oct 22 00:56:28 I, [2024-10-21T22:56:28.524715 #15] INFO -- : [dotenv] Loaded .env.production
Oct 22 00:56:29 2024-10-21T22:56:29.000Z
Oct 22 00:56:29 2024-10-21T22:56:29.000Z
Oct 22 00:56:29 2024-10-21T22:56:29.000Z
Oct 22 00:56:29 2024-10-21T22:56:29.000Z
Oct 22 00:56:29 2024-10-21T22:56:29.000Z
Oct 22 00:56:29 == 20240307180905 MigrateDeviseTwoFactorSecrets: migrating ====================
Oct 22 00:56:29 ERROR: Unable to decrypt OTP secret for user 1.
Oct 22 00:56:29 I, [2024-10-21T22:56:29.274159 #15] INFO -- : Migrating to MigrateDeviseTwoFactorSecrets (20240307180905)
Oct 22 00:56:29 In this case, their OTP secret had already been lost with the change to `OTP_SECRET`, and
Oct 22 00:56:29 Migration aborted.
Oct 22 00:56:29 Please double-check that you have not accidentally changed `OTP_SECRET` just for this
Oct 22 00:56:29 This is most likely because you have changed the value of `OTP_SECRET` at some point in
Oct 22 00:56:29 migration, and re-run the migration with `MIGRATION_IGNORE_INVALID_OTP_SECRET=true`.
Oct 22 00:56:29 proceeding with this migration will not make the situation worse.
Oct 22 00:56:29 time after the user configured 2FA.

@nebulon Hello,
OTP_SECRET was set two years ago and has not changed since then. Some users successfully use 2FA (including me)

Hey folks,
After updating I was permanently getting errors of migration like on the screenshot below:

In the end, I just restored the backup.
Any ideas on how to fix it?

@johannesjom me too

@redegelde I did it on the instance with 500+ users and all was fine. Just keep backup near)

@girish hello! What does it mean for administrators? Is it nessesary Package Update for stable servers?

@shanelord01 to be honest we did not thing about LOS. Thanks for proposal, looks like this is also good option

@redegelde looks the same. You need to transfer only files, Mastodon config, and Postgre DB (Reddis DB also can be transferred but is not necessary). But be sure that your version of Mastodon exactly the same as on Cloudron (4.0.2 for now). There can be an incompatibility between DB schemes of two different versions of Mastodon.

@shanelord01
I'm also using Linode 8gb /4 CPUs (but dedicated) - for 50 members it is more than enough (you can use 4Gb / 2 CPU cores). Now we have almost 400 users and 8/4 works well.

For files we use Amazon S3 (pretty cheep)

@nebulon IMPORTANT!
After migration to Mastadon user management, we found the small (or not) issue: 2FA authentication keys based on one-time-password were broken for users who used them. Looks like those keys were related to the environment, but the environment was changed (because we create new Mastodon App while migrating the process).

As a result we decided to disable 2FA for all our users who used it before migration.

How it can be fixed:

1. Find all users in DB who use 2FA (look into table public.users, column otp_required_for_login with value 't')
2. Reset for those users next columns values to default: otp_required_for_login, otp_backup_codes, encrypted_otp_secret, encrypted_otp_secret_iv, encrypted_otp_secret_salt
3. Send an email to those users asking them to re-setting-up 2FA.

What the interesting - disable 2FA through admin panel does not works for users from old app, so we did it right through DB

@redegelde https://forum.cloudron.io/topic/8071/change-cloudron-user-management-to-mastodon-app-user-management-on-existed-app/9?_=1669227101540 it can be useful for you

@jdaviescoates https://forum.cloudron.io/topic/8071/change-cloudron-user-management-to-mastodon-app-user-management-on-existed-app/9?_=1669227101540 it can be useful for you

So, how switch your currently existing Mastodon app from Cloudron user management to Mastodon user management?

Short answer - it is impossible, but... You can save settings and create DB dump, then delete the old app, create a new one and apply old settings and dump of DB!
This approach works only if your Mastodone app use external file storage for files (like S3 or else). If you store user files inside Cloudron - you need to download them to your computer before switching!

Prerequisite:

1. You need dump of app postgress DB. It can be done through app console and command
   PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} pg_dump --no-owner --no-privileges --username=${CLOUDRON_POSTGRESQL_USERNAME} --host=${CLOUDRON_POSTGRESQL_HOST} ${CLOUDRON_POSTGRESQL_DATABASE} > /tmp/pgdump.sql
   Your dump will be waiting for you at tmp/pgdump.sql. Just upload it to your local machine by pressing "Upload" button in app terminal (PC, laptop, whatever)
2. You need to save your custom settings from .env.production file. File placed in app/code folder - just type ls -a to see it and then use vim to copy file content.
3. In app settings save to notes your notification email-address (if you change it after installation).

Steps to switching:
0. Turn on RecoveryMode of your old instance

1. Save all settings and DB dump (see info above)
2. Delete old app
3. Install new Mastodon app from Cloudrone AppStore
   • !IMPORTANT: during the installation process choice "Leave user management to the app" option!
4. After app installation you need just update .env.production, re-set email address for notification, and import DB (more info about importing process here https://docs.cloudron.io/guides/import-postgresql/)
   • IMPORTANT: Do all of the updates in RecoveryMode of app
5. Upload old files (if you do not use an external file store like Amazon S3 etc.)

That is it! After these short manipulations (it takes 20-30mins) Mastadon user management will be turned on and your users will be able to reset their passwords without any troubles.

@nebulon I already migrated In half an hour can describe manual of how I did it (if needed)

@nebulon thx for you suggestion!
After small research of my two instances (with Cloudron user management and with Mastodon user management) I notice that in bose instances inside postgres DB existed "public.users" table that contains "encrypted_password" values. So I assume that if I'll be able manually disable SSO through .env.production, then users will be able to log in and recover passwords. Am I right?

@nebulon bug with password reset described here: https://forum.cloudron.io/topic/7978/when-using-cloudron-user-management-non-cloudron-users-cannot-reset-password

For now, we have a huge issue with user password reset in the case when using Cloudron user management, and as far as I understood there is no anyway for solving this issue now.

My question: is it possible move non-Cloudrone users to Mastodon user management system in existed app?

@girish hello!
Any updates regarding this issue? I setted up an instance and now we have more than 300 users, but without having the possibility to reset the password looks like we need close our server and re-setup it. It is a bad way for us...

Do you have like an instruction on how to move users from the old instance (with Cloudrone user management) to the new one (with inapp Mastodon user management)?