Server transfer documentation: Difference between revisions
(3 intermediate revisions by 2 users not shown) | |||
Line 315: | Line 315: | ||
<code>$ rm -r vendor/</code> | <code>$ rm -r vendor/</code> | ||
<code>$ wget https://github.com/picocms/Pico/releases/download/v3.0.0-alpha.2/pico-release-v3.0.0-alpha.2.tar.gz</code> <code>$ tar -xvzf pico-release-v3.0.0-alpha.2.tar.gz</code> | <code>$ wget https://github.com/picocms/Pico/releases/download/v3.0.0-alpha.2/pico-release-v3.0.0-alpha.2.tar.gz</code> | ||
<code>$ tar -xvzf pico-release-v3.0.0-alpha.2.tar.gz</code> | |||
<code>$ rm pico-release-v3.0.0-alpha.2.tar.gz</code> | <code>$ rm pico-release-v3.0.0-alpha.2.tar.gz</code> | ||
Line 323: | Line 325: | ||
Make ssh key in the new server for git clone the wiki-to-pdf. | Make ssh key in the new server for git clone the wiki-to-pdf. | ||
We create a user for managing access to the world such as git called ' | We create a user for managing access to the world such as git called 'USER'. | ||
=== Webhook Pico === | === Webhook Pico === | ||
Line 330: | Line 332: | ||
With a [https://docs.gitlab.com/ee/user/project/integrations/webhooks.html webhook] git pull and git push happens automatically, thus the editors don't have to access the server to edit and push back to the git. | With a [https://docs.gitlab.com/ee/user/project/integrations/webhooks.html webhook] git pull and git push happens automatically, thus the editors don't have to access the server to edit and push back to the git. | ||
Made the user | Made the user USER in gitlab and added the ssh key in it from the USER user in the new server. | ||
Create a webhook.php file in '/var/www/<code>[YOUR_DOMAIN]</code>' and insert: | Create a webhook.php file in '/var/www/<code>[YOUR_DOMAIN]</code>' and insert: | ||
Line 377: | Line 379: | ||
https://gitlab.constantvzw.org/titipi/titipi-website/-/hooks | https://gitlab.constantvzw.org/titipi/titipi-website/-/hooks | ||
With <code>nano /etc/apache2/envvars</code> change <code>export APACHE_RUN_USER=www-data</code> to <code>export APACHE_RUN_USER= | With <code>nano /etc/apache2/envvars</code> change <code>export APACHE_RUN_USER=www-data</code> to <code>export APACHE_RUN_USER=USER</code> so 'USER' is able to use the webhook. | ||
Issue: Webhook works but event not triggered. Then make sure that is under the right owner. | Issue: Webhook works but event not triggered. Then make sure that is under the right owner. | ||
<code>$ chown -R | <code>$ chown -R USER:www-data /var/www/[DOMAIN]</code> | ||
<code>$ chown www-data:www-data /var/www/[DOMAIN]/webhook.php</code> | <code>$ chown www-data:www-data /var/www/[DOMAIN]/webhook.php</code> | ||
Line 401: | Line 403: | ||
What is the prime difference between API and webhooks? It’s in how they receive data. APIs need to listen for changes continuously ('poll') to stay up to date, but with webhooks, the server can push this data over to you the instant something happens<ref>https://www.getvero.com/resources/webhooks/</ref>. | What is the prime difference between API and webhooks? It’s in how they receive data. APIs need to listen for changes continuously ('poll') to stay up to date, but with webhooks, the server can push this data over to you the instant something happens<ref>https://www.getvero.com/resources/webhooks/</ref>. | ||
Webhooks need intricate permission setups, to prevent security issues. | |||
[https://ahmetmeleq.medium.com/what-is-a-webhook-detailed-explanation-with-code-examples-ce636fba638e More detailed explanation]. | [https://ahmetmeleq.medium.com/what-is-a-webhook-detailed-explanation-with-code-examples-ce636fba638e More detailed explanation]. |
Latest revision as of 14:36, 21 May 2024
This is a rough documentation of the server transfer for TiTIPI that took place in December 2023. Please read carefully the urls with the official guides for transferring a server. Each server transfer case differs.
Create a Virtual Private Server (VPS)
Ubuntu vs Debian
We choose Debian because of these reasons (ref: https://itsfoss.com/debian-vs-ubuntu/):
Debian is older and more stable. Debian’s focus on stability means that it does not always aim for the latest versions of the software. It supports both 32-bit and 64-bit architecture and focuses primarily on FOSS (free and open source software). This means that the kernel provided by Debian does not include proprietary drivers and firmware. Debian is a true community project. The long-term support and reliability of Debian's stable release make the distro a preferred option for servers that require uninterrupted, surprise-free operation. Debian's package manager (the Advanced Package Tool, or APT for short) simplifies software installations and updates.
Ubuntu is based on Debian. It has PPA (Personal Package Archive). With PPA, installing newer software or getting the latest software version becomes a bit easier and it is a lot more forgiving when it comes to including proprietary drivers and firmware in the default ISO. Ubuntu is backed by Canonical. However, it is not entirely a corporate project. It does have a community but the final decision on any matter is in Canonical’s hands.
New VPS
With the root user create new users and add them to the sudoers file.
Add users:
$ useradd -m helen -s /bin/bash
or adduser helen
(both of these commands create a home directory and load the bash features on the user)
$ passwd helen
$ adduser helen sudo
Install and use tmux to share terminal sessions with servermates $ sudo apt install tmux
Install Apache2
How to: https://www.digitalocean.com/community/tutorials/how-to-install-the-apache-web-server-on-debian-11
$ apt update
$ apt install apache2
$ apt install ufw
$ ufw app list
$ ufw allow OpenSSH
$ ufw allow 'WWW'
$ ufw enable
$ ufw status
$ systemctl status apache2
$ hostname -I
Domain set-up
Login to the domain provider to change DNS for the domain you want.
Replace old IPv4 address with the new one provided by your VPS.
Configure apache for domain your_domain:
$ cd /var/www/
$ mkdir your_domain
$ mkdir your_domain/log
$ chmod -R 755 /var/www/your_domain/
$ nano your_domain/index.html
$ nano /etc/apache2/sites-available/your_domain.conf
Insert:
<VirtualHost *:80> ServerAdmin webmaster@localhost ServerName your_domain ServerAlias your_domain_ip DirectoryIndex index.html index.php DocumentRoot /var/www/your_domain ErrorLog /var/www/your_domain/log/error.log CustomLog /var/www/your_domain/log/access.log combined </VirtualHost>
$ a2ensite your_domain.conf
$ systemctl reload apache2
Disable default domain apache configuration
$ a2dissite 000-default.conf
$ systemctl reload apache2
$ apache2ctl configtest
$ systemctl restart apache2
Access logs
Reduce the size of the domain logs automatically:
Install logrotate: https://linux.die.net/man/8/logrotate
$ apt-get install logrotate
$ nano /etc/logrotate.d/apache2.conf
/var/log/apache2/* { weekly rotate 3 size 10M compress delaycompress } /var/www/titipi.org/log/* { daily rotate 3 size 10M compress delaycompress } /var/www/ddivision.xyz/log/* { daily rotate 3 size 10M compress delaycompress }
$ logrotate -d /etc/logrotate.d/apache2.conf
$ nano /var/log/apache2/access.log
$ systemctl reload apache2
Install and transfer MediaWiki
How to move a mediawiki: https://www.mediawiki.org/wiki/Manual:Moving_a_wiki
MediaWiki version of your old server
Version: [YOUR_WIKI_DOMAIN]/index.php/Special:Version MediaWiki 1.35.1 PHP 7.4.21 (apache2handler) MySQL 5.7.34-0ubuntu0.18.04.1
How to: https://www.mediawiki.org/wiki/Manual:Moving_a_wiki
Steps
- Install the latest mediawiki version on the new server https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki and https://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Debian_or_Ubuntu#Get_latest_MediaWiki
- Set up database for new mediawiki on the new server https://www.mediawiki.org/wiki/Manual:MariaDB/en (We choose MariaDB because MySql uses proprietary source code)
- Install wiki-to-pdf on new server (see #wiki-to-pdf)
- Make a backup of the wiki on the old server (more in detail: https://sharkysoft.com/wiki/how_to_move_a_MediaWiki_wiki_from_one_server_to_another.html)
- upgrade the MediaWiki on the old server
- mysqldump + xml dump old wiki (backup again)
- Transfer backups from the old server to the new one
- Restore the backup on the new server
Installation in the new server
Prepare the ground on the new server and download MediaWiki:
$ apt upgrade
$ apt update
$ apt-get install php php-mysql libapache2-mod-php php-xml php-mbstring
$ apt-get install mariadb-server
$ apt-get install imagemagick
$ systemctl reload apache2
$ cd /tmp/
$ wget https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.1.tar.gz
$ apt-get install wget
$ tar -xvzf mediawiki-1.40.1.tar.gz
$ mkdir /var/www/[YOUR_DOMAIN]/wiki
$ mv mediawiki-1.40.1/* /var/www/[YOUR_DOMAIN]/wiki/
Install requirements:
$ apt install php-intl
$ systemctl reload apache2
$ apt-get install php-apcu inkscape php-gd php-cli php-curl php-bcmath git
$ systemctl reload apache2
Set up database. Check here: https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki
$ mariadb -u root -p -h localhost
$ cp /home/femke/LocalSettings.php /var/www/[YOUR_DOMAIN]/wiki/
$ ls /var/www/[YOUR_DOMAIN]/wiki/
database info from old server:
$wgDBname = "name of wiki"; $wgDBuser = "user"; $wgDBpassword = "password";
Back up the wiki on the old server
How to back up a MediaWiki: https://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki
$ cd /var/www/html/[YOUR_DOMAIN]/backups/
$ mysqldump -u admin -pbugreport new_wiki -c > wikidb.sql
$ tar czvf images.tgz images/
$ mv images.tgz ../../backups/
$ cd ../../
$ cd backups/
$ mysqldump -u admin -pbugreport new_wiki --xml > wiki.xml
Upgrade mediawiki in old server
How to upgrade a MediaWiki: https://www.mediawiki.org/wiki/Manual:Upgrading
new server: MediaWiki 1.40.1 PHP 8.2.7 (apache2handler) ICU 72.1 MariaDB 10.11.4-MariaDB-1~deb12u1 Old server: MediaWiki 1.35.1 PHP 7.4.21 (apache2handler) MySQL 5.7.34-0ubuntu0.18.04.1
$ sudo tmux attach -t webserver
check storage space, which files take more space:
$ du -h -d 1 .
$ df
$ df -h
let's vacuum it!
$ journalctl --vacuum-size=100M
$ apt clean
Python wants us to have virtual environments but we go for installing through Debian packages. We tried but it was very complex. We continued with a virtual environment.
MediaWiki upgrade issues
To be able to export the database and re-import in the new server, we need to upgrade the MediaWiki version in the old server.. BUT the newer MediaWiki needs a new version of PHP (8.0+) that is not supported on the Ubuntu version (18.04). In fact it was supported but the Long Term Support has ended in June 2023 so all the packages have been removed (though paid services are provided). BUT We found some folder from a company Zend that provides "Long Term PHP support" https://repos-source.zend.com/zendphp/deb_ubuntu1804/pool/. Interesting to understand this chain of free-software dependencies becoming paid opportunities when it comes to maintenance of older systems, and that these experimentations are happening in the context of the Ubuntu enterprise/community obviously.
What was done then was to download the php8.1 packages from zend
$ wget --no-check-certicificate https://repos-source.zend.com/zendphp/deb_ubuntu1804/pool/php8.1-zend-common_8.1.27-1_amd64.deb https://repos-source.zend.com/zendphp/deb_ubuntu1804/pool/php8.1-zend-intl_8.1.27-1_amd64.deb
And then install them one by one..
$ dpkg -i php8.1-zend-common_8.1.27-1_amd64.deb php8.1-zend-intl_8.1.27-1_amd64.deb
...
Then disable the old php module in apache and enable the new one:
$ a2dismod php7.4
$ a2enmod php8.1-zend
$ service apache2 restart
Import the new database:
$ mysql -u USERNAME -p DATABASENAME < ../../linodewikidumps/wikidb-afterupdate.sql
Mediawiki quirks ContentModel reshuffle:
Common.js and Common.css swapped ContentModels O_o
To re-shuffle: 37.218.240.79/wiki/index.php?title=Special:ChangeContentModel
then change the page Mediawiki:Common.js and Mediawiki:Common.css first change to wikitext and then back to respectively javascript and css.
Install Wiki-to-pdf
Don't forget to copy the pub/ folder in the new server (it includes the publications from the old server)
How to: https://titipi.org/wiki/index.php/Wiki-to-pdf-manual and https://gitlab.constantvzw.org/titipi/wiki-to-pdf
Install Pico
Install pico and check: https://picocms.org/download/
$ tar --exclude='public_html/wiki' --exclude='public_html/wiki-to-pdf' --exclude='public_html/wiki-to-pdf-webhook.php' -zcvf backups/site.tgz public_html/
Check the php modules dom and mbstring installed for pico to run
$ php -m
From /titipi.org we update pico
$ rm -r vendor/
$ wget https://github.com/picocms/Pico/releases/download/v3.0.0-alpha.2/pico-release-v3.0.0-alpha.2.tar.gz
$ tar -xvzf pico-release-v3.0.0-alpha.2.tar.gz
$ rm pico-release-v3.0.0-alpha.2.tar.gz
With filezilla we replaced: themes/default/css/ and themes/default/index.twig
Make ssh key in the new server for git clone the wiki-to-pdf.
We create a user for managing access to the world such as git called 'USER'.
Webhook Pico
Pico's edit interface is outdated. In order to create and edit web pages we decide to put the content of the website in a git repository, in a way we create an CMS (Content management system) for ourselves. The web pages can be edited in markdown format through the git.
With a webhook git pull and git push happens automatically, thus the editors don't have to access the server to edit and push back to the git.
Made the user USER in gitlab and added the ssh key in it from the USER user in the new server.
Create a webhook.php file in '/var/www/[YOUR_DOMAIN]
' and insert:
<?php setlocale(LC_ALL,'en_US.UTF-8'); $mirrordir='/var/www/[YOUR_DOMAIN]/content'; $gitdir=$mirrordir."/.git"; $access_token = 'YOURPASS'; $headers = apache_request_headers(); $headd = array(); foreach ($headers as $header => $value) { $head["$header"] = $value; } $json= file_get_contents('php://input'); $client_token = $headers['X-Gitlab-Token']; $jsarr=json_decode($json,true); if ($client_token !== $access_token) { echo $jsarr['repository']['name']; header('HTTP/1.0 403 Forbidden'); echo "error 403"; exit(0); } $branch = $jsarr['ref']; $repo = $jsarr['repository']['name']; chdir($mirrordir); $cmd="git pull"; exec($cmd); echo 'working' ;
Check if webhook is working by testing it in gitlab (test push events):
https://gitlab.constantvzw.org/titipi/titipi-website/-/hooks
With nano /etc/apache2/envvars
change export APACHE_RUN_USER=www-data
to export APACHE_RUN_USER=USER
so 'USER' is able to use the webhook.
Issue: Webhook works but event not triggered. Then make sure that is under the right owner.
$ chown -R USER:www-data /var/www/[DOMAIN]
$ chown www-data:www-data /var/www/[DOMAIN]/webhook.php
And make sure that git instance is added in the known hosts.
Warning: Permanently added 'gitlab.constantvzw.org' (ED25519) to the list of known hosts.
What is a webhook?
Webhooks are one of a few ways web applications (a git repository with a CMS for example) can communicate with each other[1]. Webhooks allow you to send real-time data from one application to another whenever a given event occurs.
Technically, a webhook is an HTTP-based callback function triggered by an event such as pushing code to a git repository or posting a comment on an issue. Webhooks are used by a wide variety of web apps to receive small amounts of data from other apps. In this context we are using it to automate the versioning workflow around updating content of the https://titipi.org website that is hosted on gitlab. When an edit is saved (committed), this triggers a push event in the Gitlab repository (the source application) setup with a webhook. This means that gitlab sends a HTTP POST request (payload) to a predefined URL that points to a file stored on the webserver (the webserver is the target application). Notified by the webhook, the webserver performs a git pull, and the corresponding file gets updated.[2].
The exchange of data happens over the web through a “webhook URL.” A webhook URL is provided by the receiving application, and acts as a phone number that the other application can call when an event happens. Only it’s more complicated than a phone number, because data about the event is sent to the webhook URL in either JSON or XML format. This is known as the “payload.” Or they are much like SMS notifications[3]. Say your bank sends you an SMS when you make a new purchase. You already told the bank your phone number, so they knew where to send the message. (interesting wording and examples: payloads, banking ...)
What is the prime difference between API and webhooks? It’s in how they receive data. APIs need to listen for changes continuously ('poll') to stay up to date, but with webhooks, the server can push this data over to you the instant something happens[4].
Webhooks need intricate permission setups, to prevent security issues.
Install and configure Certbot
How to: https://certbot.eff.org/instructions and https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-debian-11
In Gandi create web forward for http://www.your_domain to http://your_domain
Mail transfer
- Get the DNS details from the former server where your email account is hosted (hereafter referred to as Gandi) and send them to the new server (hereafter referred to as irational) sys admin
- Backup old emails in Thunderbird: if you already use Thunderbird for the email account you transfer then you export in all 3 possible ways to be sure you can restore if something goes wrong.
- locate the folder .thunderbird in your computer, copy it somewhere else and rename it to possibly transfer.thunderbird,
- make a BACKUP with the ImportExportTools NG add-on (check in the Tools or at the top of your toolbar on the right),
- export a zip file with ImportExportTools NG. Then create temp folder in Local Folders in Thunderbird. Move temporarily the emails of the mail account you transfer to this new folder by dragging the folders there. Remove your empty account in account settings.
- Make user accounts in irational server through SSH (sys admin takes care of that). You will then have an email account in the server associated to your user account. The passwords are the same.
- SSH to irational
- Type `$ alpine` to access your email inbox. In the menu -> message index (empty)
- Test by receiving and testing emails to sys admin. At the bottom you can see commands of how to use Alpine
- Go back to menu and choose SETUP and choose C. Note: use ctrl+c to cancel what you do and E to exit
- There change your personal settings. Name: YOURNAME and domain:YOURDOMAIN, for example titipi.org, if you don't use irational domain
- Test by sending emails to a non irational account.
- Login to your old email server like Gandi
- Edit MX record, copy/save the configuration and update
- Under A/AAAA record is ip6, press edit and save copy of that record, remove 3d line, replace mail record with mail server IP address
- on TXT record: save value ("v=spf1 include:_mailcust.gandi.net ?all"). TXT is the spf. They are records that are plaintext instructions for the machinery. Replace with "v=spf1 mx ip4:193.170.194.206 a:irational.org -all"
- replace TXT hostname (mailcust.gandi.net) with nothing and save
- Sys admin restarts Postfix
- Check in mxtoolbox.com the smtp and mx if they are working
- Test gmail exchanging: send from a gmail to your email and respond back
- Use Thunderbird email client
- Enter webmail.irational.org-> go to settings->identities-> display name: add your name and email
- In thunderbird create a new account. Configure manually
- Restart Thunderbird
- Move back the emails by for example selecting all emails in the inbox in the temporary folder, right click and move them back in the new inbox, drag the subfolders.
- We get Add Security Exception message, we confirm.
- Test sending and receiving
- Changing of pwd in the server account changes also in the email (because of not virtualization). Change with `$ passwd USERNAME`