SSL errors whilst upgrading to

Apologies for the grump. I really appreciate the help you’ve given.

I went through everything just one more time and was shocked to see bundle install working.
I tried bin/bundle --full-index and this finished with the same results as expected.

The next hurdle is the RAILS_ENV=production bundle exec sidekiq step:

steve@pod:~/diaspora$ RAILS_ENV=production bundle exec sidekiq
Top level ::CompositeIO is deprecated, require 'multipart/post' and use `Multipart::Post::CompositeReadIO` instead!
Top level ::Parts is deprecated, require 'multipart/post' and use `Multipart::Post::Parts` instead!
2022-08-01T22:17:10.464Z pid=4225 tid=71p WARN: `config.options[:key] = value` is deprecated, use `config[:key] = value`: ["/home/steve/diaspora/vendor/bundle/ruby/2.7.0/gems/sidekiq-cron-1.6.0/lib/sidekiq/cron/schedule_loader.rb:6:in `block in <top (required)>'", "/home/steve/diaspora/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.5.1/lib/sidekiq.rb:134:in `configure_server'"]
Rack::SSL is enabled
2022-08-01T22:17:12.750Z pid=4225 tid=71p INFO: Booting Sidekiq 6.5.1 with Sidekiq::RedisConnection::RedisAdapter options {}
2022-08-01T22:17:12.919Z pid=4225 tid=71p INFO: Cron Jobs - added job with name: check_birthday
2022-08-01T22:17:12.923Z pid=4225 tid=71p INFO: Cron Jobs - added job with name: clean_cached_files
2022-08-01T22:17:12.925Z pid=4225 tid=71p INFO: Cron Jobs - added job with name: cleanup_old_exports
2022-08-01T22:17:12.928Z pid=4225 tid=71p INFO: Cron Jobs - added job with name: cleanup_pending_photos
2022-08-01T22:17:12.930Z pid=4225 tid=71p INFO: Cron Jobs - added job with name: queue_users_for_removal
2022-08-01T22:17:12.932Z pid=4225 tid=71p INFO: Cron Jobs - added job with name: recheck_scheduled_pods
2022-08-01T22:17:12.934Z pid=4225 tid=71p INFO: Cron Jobs - added job with name: recurring_pod_check
2022-08-01T22:17:15.005Z pid=4225 tid=71p WARN: ActiveRecord::StatementInvalid: Mysql2::Error: Table 'diaspora_production.people' doesn't exist

Um, what happened to my ‘people’ table?

Are there any tables at all in that database? Is the correct MySQL version running? Are there any manual MySQL-upgrade steps to be done in the case of Ubuntu upgrades? (Sorry, it’s been a looong time since I’ve used MySQL.)

In the grand scheme of things, compared to some of the other folks posting here, there was zero grump in your messages. It can be frustrating, I know.

Well I had a working pod on the previous version this morning.

However, this doesn’t look good.

MariaDB [(none)]> show databases;
| Database            |
| diaspora_production |
| information_schema  |
| mysql               |
| performance_schema  |
| sys                 |
5 rows in set (0.002 sec)

MariaDB [(none)]> use diaspora_production;
Database changed
MariaDB [diaspora_production]> show tables;
Empty set (0.001 sec)

I have a horrible feeling I ran the rake db:create db:migrate instead of just the rake db:migrate step.

I think you can imagine the answer to the backups question… :clown_face:

Looks like I’ll have to start again. Fortunately my pod wasn’t up long, but I had followed dozens of accounts.

db:create doesn’t drop an existing database, and it also doesn’t remove tables. Only db:drop drops the database. Make sure you don’t have the old data pre-Ubuntu-upgrade somewhere in /var/lib/mysql.old or something.

If you have actually lost the database, please note that you cannot use the same diaspora* IDs again (i.e. username@pod.tld). If you re-use an old one and try to connect to a pod that knew your old setup, then it will refuse to talk to you, because… well, because you’ve lost the private keys for the old account(s). So you either have to use different usernames, or a different domain.

I have no idea what happened to the tables, then.

Still, I’m cutting my losses and moving on. I’m up to date and happy to have learned a lot today (mainly about backups).
I have lots of work adding all the people again tomorrow but that’s okay. I just followed you. :slight_smile: is alive.

Many thanks again for the support to yourself, @flaburgan and @supertux88. I’ll get out of your hair now.


I’m afraid there is no more hair left.

ehhh, I mean… Good to hear it’s working now. ;D

Don’t worry; you’re still beautiful… [off-topic alert]

…because you help people so much. [back on topic alert]

I have enough experience ripping my hair out while trying to debug weird edge-cases, it regrows fast enough. :stuck_out_tongue:

This looks really weird. As Dennis already wrote, you can’t run db:create a second time, it would complain that the DB already exists and it won’t automatically drop it. Also, if you would have ran rake db:create db:migrate then there would be tables, as the migrations would have created them (the tables themselves would be empty tough), but it looks like your database is just empty. I have no idea how this could have happened. :man_shrugging:

But if your pod was really new, it’s probably easier to just start fresh, instead of of trying to search where your tables went when you upgraded ubuntu (and as you already started a new database anyway, so merging them would even produce more chaos). So as long as you don’t re-use any usernames that existed in the old database, everything should be working fine now.

For reference: to hopefully prevent other podmins from falling into the dist-upgrade trap, I published a post from the HQ account to warn them, and I added a 22.04 honeypot to the installation guides, so that new podmins will hopefully stick with 20.04 for now.

1 Like

Hello, I just bought a new server and put 22.04 on it, getting ready for a fresh diaspora install, if we want to go step by step and see what would allow diaspora to run on it?

Or we work on diaspora* to be ready for the last Ruby, but OpenSSL 3 support comes only with Ruby 3.1, is this achievable for next major?

I don’t think that’s a good idea. While there are some hacks, none of them are supported by the Ruby team, and I don’t feel comfortable suggesting anyone to run that. I very very strongly suggest you to reinstall that server using Ubuntu 20 LTS.

@supertux88 filed an issue already, Support ruby 3 · Issue #8369 · diaspora/diaspora · GitHub. the first step is to make it work on 3.0, and then see what goes wrong on 3.1. I’m sure he’ll be happy to accept your work on that - and more people working on that will make it more likely to be ready soon. :slight_smile:

There is no rush for me to migrate diaspora-fr to that new server, I will keep it in 22.04 at the moment and wait for diaspora* to be ready.

Sure, even if I’m not sure where to start with…? I’ll see if I find something.