Creating SSH log in keys:

debian linux
puttygen -t rsa -b 4096 -C "username@hostname" -o keyfile.ppk

Apparently the "" signs in the user name part have to be used.

You should use/create a password in the procedur of creating the keyfile.ppk, you'll be asked if you want to in the creation process.

It is unclear to me to what extent username and hostname have to be specific somehow. Like to say, you normally would log in as the user root and hostname would normally most likely be yourDomainName or yourServerIP but I don't know if there for you should most likely need to use root@00.000.00.000/root@yourdomain or could even use wtfWhyNot@anyNameOrNumber

Get the public key:
puttygen -L keyfile.ppk

The result will be something like:
ssh-rsa AAA..->..ztc username@hostname

Copy/paste the public key into some .txt file to have this at hand. Your hosting povider will have to locate this in your VPS setup or tell you how to upload it yourself.

Extract and separate the private key you'll need to log onto your server:
puttygen keyfile.ppk -O private-openssh -o privkey.pem

puTTy will create all those keys in the directory the console is in while executing the commands.

Log into your server:
ssh -i privkey.pem username@hostname

When ever you want to log into your server from console, you'll have to be in the folder where the privkey.pem is located.

For example, you might create a folder /hostingVPS in your /home folder and locate the privkey.pem there.

In that case to log onto your server the procedure would be:

open your console:

cd hostingVPS
ssh -i privkey.pem username@hostname

keyfile.ppk, privkey.pem and your public key are quite important so you should back them up savely.

Edit unattended upgrade configuration:
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

modify:
//Unattended-Upgrade::Automatic-Reboot "false";

You want to uncomment the line and set the value to true so it reads:
Unattended-Upgrade::Automatic-Reboot "true";

restart unattended upgrade service:
sudo systemctl restart unattended-upgrades

This step derailed completely my intent to migrate the server.

It took me a lot of work and effort too find the problems I created by not following the instructions by the tutorial. The reason I couldn't follow the tutorial "as is" was because the old server was still up and running and I wanted to first make a "test install", check than if everything worked out as expected to finally migrate the node onto the new VPS hosting.
In the end I managed to do the migration and am working right now on re-editing this "tutorial / experience report" so it can serve as tutorial without losing the "live report" in the process of summing up this report.
At the same time I'm working on a final tutorial for server migration that will be published accordingly.

As it looks right now there are two options:

A)
You simply follow hankG's tutorial and set the old server into maintenance mode once you reach the certbot step as you will need a working "redirect" for the new IP of your domain to be able to register the SSL certificate. You will have to leave your domain meanwhile off line, using the hints in this report on downloading, uploading and so. If something goes wrong you will have the option to change the IP redirect of your domain to the old hosting and reactivate that server while you check out what went wrong on the new server.

B)
You find some work around by registering some subdomain or another domain with the certbot routine and certify that domain for your new server. Once everything else is working fine and you feel secure with what you are doing you redirect the IP of the domain you want to migrate, run the certbot routine for your new certificate for the new server and work on from there.

Link to the completion of this step:
squeet.me/display/962c3e10-136…

…ᘛ⁐̤ᕐᐷ jesuisatire bitPickup

2023-11-07 04:03:45

At this point all changes to be able to switch from the old to the new server should be done.

• DB merged
• file storage merged
• local.config.php merged

To set old server into maintenance mode enter via SSH and browse to your friendica installation:
rootname@oldserver:/friendicarootdir/~# bin/console maintenance 1

Check that the server is set to maintenance by browsing to your domain on the web:

Go to your name server provider and change the IP to the new server.

Complete certbot HTTPS instalation

Now it's time to go back to the certbot installation and complete those steps. Be aware that you have to wait for the IP setting change for your domain to come into effect. This might take some time, depending on your service provider and the settings you might be able to influence, apparently eventually up to a day. In my case it was about half an hour.
In this case, as the certbot installation was completed but abandoned as the old server was still running, the only thing I had to do was the following:

Run the following command over SSH:
root@ubuntu:~# sudo certbot --apache

certbot wrote:

Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel):

yourdomainname.com

certbot output

Requesting a certificate for yourdomainname.com
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/yourdomainname.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/yourdomainname.com/privkey.pem
This certificate expires on XXXX-XX-XX.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for yourdomainname.com to /etc/apache2/sites-available/000-default-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on yourdomainname.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: letsencrypt.org/donate
* Donating to EFF: eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
rootname@ubuntu:~

If you want to check the installed certs on your server you can do this by typing:
rootname@ubuntu:~#certbot

certbot output

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: yourdomainname.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): C!!!
Please specify --domains, or --installer that will help in domain names autodiscovery, or --cert-name for an existing certificate name.
Ask for help or search for solutions at community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
rootname@ubuntu:~#

If everything went well now your new server should be up and running.

spoilerAlert: I get a blank page.

Somehow I managed to mistype something here and got stuck.
The console gave me the following message:

Disallow root login remotely? [Y/n] ^C <- (some bad keystroke)
Aborting!

Cleaning up...
root@ubuntu:~#

So I just started again:

sudo mysql_secure_installation

The following lines came up and after just redoing the same steps apparently everything went fine.

sudo chown -R www-data:www-data /var/www

cd /var/www

sudo -u www-data bash

mv html html.bak

tweaking basic apache settings:

sudo nano /etc/php/8.1/apache2/php.ini

search for the following lines [ctrl+w] and modify the values:

[ctrl] W -> find line

set to:
memory_limit = 256M

upload_max_filesize = 100M

max_execution_time = 300

max_input_vars = 1500

Checking 000-default-le-ssl.conf after successful completion of the certbot HTTPS routine:

Certbot entered more lines in the already existing file that was created by scratch when executing
sudo nano /etc/apache2/sites-available/000-default-le-ssl.conf
creating a complete mess.

It created kinda a double entry and also added <VirtualHost *:80>
I started testing and comparing and ended up with the following file:

With <VirtualHost *:80> firefox gives a:
SSL_ERROR_RX_RECORD_TOO_LONG error,
so I used port 443 as in the example and apparently that works.