rootname@VPShosting:/var/www# mv html html_01.bak
rootname@VPShosting:/var/www# git clone https://github.com/friendica/friendica.git -b stable html

…ᘛ⁐̤ᕐᐷ jesuisatire bitPickup

2023-11-08 17:16:40

Partical re-installation/redo of the following steps

It looks like somehow because of this unfinished step the installation went wrong and when browsing to the friendica installation a blank page was displayed.
After redoing the steps of installation from the github pull of friendica the web page displayed Service unavailable.
Their for I'm going to redo the steps from the certbot installation to the gitpull

¡Update - solved!

The tutorial by @Hank G ☑️ states that:

Tutorial wrote:

With the default Apache installation the /var/www/ directory is owned by root. We will want to instead make this whole directory and sub-directory to be owned by the Apache process’s user www-data.

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

We will now want to execute the rest of the commands as that user so we execute the sudo command on the bash shell to make all subsequent command execute as the www-data user in the root of the /var/www directory.
Next we are going to use the fact that the default Apache site that is already configured is looking for the /var/www/html directory. We will move the original default site to a backup location.

I missed that important detail and didn't changed to the user www-data so the new git pulls didn't work as expected.

Switching to user www-data and than performing the steps of git pull and adjustments to the friendica installation apparently everything worked out:

rootname@VPShosting:/var/www# cd /var/www
rootname@VPShosting:/var/www# -u www-data bash

www-data@VPShosting:~$ ls -l

git clone https://github.com/friendica/friendica.git -b stable html/code]
www-data@VPShosting:~$ [code]cd html

rootname@VPShosting:/var/www#

Browsing now to the web page the friendica installation verification screen is visible.
😀

Last step:
Updating the local.config.php file and uploading it to the new server.
This will activate the new VPS server of your friendica node!

Allocate local.config.php in the PuTTy privkey.pem folder: /home/user/.VPShosting

user@localPC:~/.VPShosting$ nano local.config.php

Adapt local.config.php for the new VPS server setting:

<?php
// Local configuration
// If you're unsure about what any of the config keys below do, please check the static/defaults.config.php for detailed
// documentation of their data type and behavior.
return [
	'database' => [
		[s]'hostname' => 'subdomain.oldhosting.com:3306',[/s]
		'hostname' => 'yourfriendicadomain.com', <-- THIS WAS WRONG!!
		'hostname' => 'localhost',
		'username' => 'friendicadb',
		'password' => '[b]changedPassword[/b]',
		'database' => 'friendicadb',
		'charset' => 'utf8mb4',
	],
	// ****************************************************************
	// The configuration below will be overruled by the admin panel.
	// Changes made below will only have an effect if the database does
	// not contain any configuration for the friendica system.
	// ****************************************************************
	'config' => [
		'php_path' => '/usr/bin/php',
		'admin_email' => 'youradmin@email.com',
		'sitename' => 'Friendica Social Network',
		'register_policy' => \Friendica\Module\Register::CLOSED,(or OPEN)
		'max_import_size' => 200000,
	],
	'system' => [
		'url' => 'https://yourfriendicadomain.com',
		[s]'basepath' => '/apps/friendica',[/s]
		'basepath' => '/var/www/html',
		'default_timezone' => 'AnyTime/AnyWhere',
		'language' => 'en',
	],
];

Uploading with PuTTy private .pem key:
user@localPC:~/.VPShosting$ scp -i privkey.pem local.config.php USER@SERVER:/var/www/html/config/local.config.php

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.
😮

Access over sFTP:

me in a previous post wrote:

https://squeet.me/display/962c3e10-2165-2dbe-eb37-5f6322325636
"My access is over SSH with puTTy[/url] created public/private keys, no password.
Can I create sFTP access with for example filezilla and if so how?"

Raroun wrote:

sFTP should work out of the box with any Application that supports private key authorization - like scp or FileZilla.

I never managed to make fileZilla work with the puTTy keys.
🙁

first move the phpmailer.config.php file to the friendica config folder:
rootname@VPShosting:~# mv /var/www/html/addon/phpmailer/config/phpmailer.config.php /var/www/html/config/phpmailer.config.php

edit the phpmailer configuration file already located in the friendica config folder:
rootname@VPShosting:~# nano /var/www/html/config/phpmailer/config/phpmailer.config.php

<?php
// Warning: Don't change this file! It only holds the default config values for this addon.
// Instead overwrite these config values in config/addon.config.php in your Friendica directory
return [
	'phpmailer' => [
		// smtp (Boolean)
		// Enables SMTP relaying for outbound emails
		'smtp' => false,
		// smtp_server (String)
		// SMTP server host name
		'smtp_server' => 'smtp.example.com',
		// smtp_port (Integer)
		// SMTP server port number
		'smtp_port' => 25,
		// smtp_secure (String)
		// What kind of encryption to use on the SMTP connection.
		// Options: '', 'ssl' or 'tls'.
		'smtp_secure' => '',
		// smtp_port_s (Integer)
		// Secure SMTP server port number
		'smtp_port_s' => 465,
		// smtp_username (String)
		// SMTP server authentication user name
		// Empty string disables authentication
		'smtp_username' => '',
		// smtp_password (String)
		// SMTP server authentication password
		// Empty string disables authentication
		'smtp_password' => '',
		// smtp_from (String)
		// From address used when using the SMTP server
		// Example: no-reply@example.com
		'smtp_from' => '',
	],
];

<?php
// Warning: Don't change this file! It only holds the default config values for this addon.
// Instead, copy this file to config/phpmailer.config.php in your Friendica directory and set the correct values there
return [
	'phpmailer' => [
		// smtp (Boolean)
		// Enables SMTP relaying for outbound emails
		'smtp' => true,
		// smtp_server (String)
		// SMTP server host name
		'smtp_server' => 'mail.ProviderDomain.com',
		// smtp_port (Integer)
		// SMTP server port number
		'smtp_port' => 587,
		// smtp_secure (String)
		// What kind of encryption to use on the SMTP connection.
		// Options: '', 'ssl' or 'tls'.
		'smtp_secure' => 'tls',
		// smtp_port_s (Integer)
		// Secure SMTP server port number
		'smtp_port_s' => 465,
		// smtp_username (String)
		// SMTP server authentication user name
		// Empty string disables authentication
		'smtp_username' => 'admin@yourFriendicaDomain.com',
		// smtp_password (String)
		// SMTP server authentication password
		// Empty string disables authentication
		'smtp_password' => 'CHANGED-EmailPassword',
		// smtp_from (String)
		// From address used when using the SMTP server
		// Example: no-reply@example.com
		'smtp_from' => 'admin@yourFriendicaDomain.com',
	],
];

creat a copy of the MySQL DB
rootname@VPShosting:~# mysqldump -u username -p database_to_backup > backup_name.sql

install automysqlbackup
rootname@VPShosting:~# sudo apt-get install automysqlbackup
rootname@VPShosting:~# sudo automysqlbackup

listing automysqlbackup folders
rootname@VPShosting:~# cd /var/lib/automysqlbackup
rootname@VPShosting:~# /var/lib/automysqlbackup# ls
daily monthly weekly

listing daily backed up files:
rootname@VPShosting:~# ls -R /var/lib/automysqlbackup/daily

to have a look at automysqlbackup, as is there is no tweaking neccesary:
rootname@VPShosting:~# nano /etc/default/automysqlbackup