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
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.
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.
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.
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.
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.
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.
So, good news on the “Run diaspora* on Ubuntu 22.04”, as Dennis noticed, Ruby 2.7.7 has been fixed to use the good openSSL version so it is now possible to install diaspora* on Ubuntu 22.04, forcing OpenSSL downgrade to 1.0 with
rvm pkg install openssl
rvm remove 2.7 # If you tried to install it before
rvm install 2.7 --with-openssl-dir=$HOME/.rvm/usr
gem install bundler
I didn’t test that on a production server, but locally I was then able to run bin/bundle install without any trouble. I have a server without Ubuntu 22.04, I will try to do a production installation at some point.