However there is programs that look for /usr/bin/python and this is not a binary found on the server.

So how do you solve this little problem? The idea behind that is that you might need either python 2 or python 3 for your programs so you can install either of them to be the default one, with two respective packages called:

python-is-python3 and python-is-python2

If you try to just install python, what will install python2 and python-is-python2, so your default python interpreter will use python 2.

Another not so elegant solution is to just link python to python3 like this:

ln -fs /usr/bin/python3 /usr/bin/python

The problem is that this newer machine was not detecting these keys with xev and when I was using the function keys for the screen brightness acpi events were triggered, so I needed to find how to catch the key presses.

So bellow is what I used in order to control my brightness.
First of all you need to find out what keys acpi detects, you can do that with acpi_list.
In my case the output of it was the keys video/brightnessup BRTUP 00000086 00000000
and video/brightnessdown BRTDN 00000087 00000000

So the next step is to add new acpi event. This is very straightforward, for ubuntu you just go to the /etc/acpi/events/ folder and create two files there – one for increasing the brightness and one for decreasing it. What you put in these files is simply what command or script to be executed when that key is pressed. I will give example with just the brightness increase scripts, as the brightness decrease are basically the same, just the key and script is different, so you should not have any problems adding the others.

So my /etc/acpi/events/brightness_up looks like this

# /etc/acpi/events/brightness_up
# This is called when the user presses the brightness up button and calls
# /home/ivan/.config/i3/brightness_up.sh which will increase the screen brightness.
# Author: Ivan Denkov

event=video/brightnessup BRTUP 00000086 00000000
action=/etc/acpi/brightness_up.sh

This trigger the script located in /etc/acpi/brightness_up.sh you need to make that script executable, and this are the contents to go there. Here is the script:

#!/bin/bash
CAT="$(which cat)"
current_brightness=`$CAT /sys/class/backlight/intel_backlight/brightness`
new_brightness=$(($current_brightness+20))
echo $new_brightness > /sys/class/backlight/intel_backlight/brightness

You just need to replicate the event and the script for lowering the brightness and you should be good to go.
If for some reason the above does not work, make sure that:
– You have made the bash scripts executable.
– Make sure the bash scripts by itself can change the brightness(It is actually working)
– Double check acpi_listen to make sure you have put the correct keys in the events.

I assume it will be practically the same procedure on the Thinkpad T480.

mysqldump -u MYSQL_USERNAME -p DATABASE | gzip -c | ssh USER@HOST 'cat > ~/dump.sql.gz'

ssh USER@HOST "cat /path/to/db.sql" | mysql -uUSER  -pPASSWORD DATABASE

show variables like 'have_query_cache';

That should return:

+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+

Then you need to check some variables related to query caching. I will explain each of them:

mysql> show variables like 'query_cache_%' ;
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 262144   |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 10485760 |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

query_cache_limit – the total size each individual query can be. In my case that is 262144
query_cache_min_res_unit – how large is each chunk/block of cached data
query_cache_size – the total amount of cached queries, 0 disables it, and it needs to be at least 40kb at the lowest to work. Usually the default is 16,777,216
query_cache_type – if the value is ON it means cache query is enabled. If it is OFF it means it is disabled.

Add the following to your sql config file, probably in /etc/mysql/my.cnf and edit the values to fit your needs and/or your servers specs –

[mysqld]
query_cache_type=1
query_cache_size = 32M
query_cache_limit=512K

Then restart mysql/maridb and you should be good to go. You can verify the changes in the config file by running again:

show variables like 'query_cache_%';

You can check some query cache stats by running this:

mysql> SHOW STATUS LIKE 'Qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 2        |
| Qcache_free_memory      | 14713664 |
| Qcache_hits             | 1750     |
| Qcache_inserts          | 1643     |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 247      |
| Qcache_queries_in_cache | 423      |
| Qcache_total_blocks     | 887      |
+-------------------------+----------+

For further and more detailed information, MariaDB knowledge base about Query Cache is far better place.

You can fix it with one of these, I prefer removing the expiration with chage:

chage -M -1 root

or

passwd -x -1 root

You can confirm with:

chage -l root

master: 192.168.122.25
slave: 192.168.122.26

1. Before anything else you need to update all packages on the two machines:

sudo apt update
sudo apt upgrade

2. First thing is to add the official MariaDB repo for the stable release from here – https://downloads.mariadb.org/mariadb/repositories/
In my case, for Ubuntu 18.04 I had to use this:

sudo apt-get install software-properties-common
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el] http://ams2.mirrors.digitalocean.com/mariadb/repo/10.3/ubuntu bionic main'

3. Install it on both servers:

sudo apt install mariadb-server

You will have to provide password for the root user during install. Please note this is not the exisitng Ubuntu root user, but is new password the root user for mysql.

4. On both servers: sudo mysql_secure_installation
This will ask you for the root password you have set up in the previous step. You should remove anonymous users, disable remote root loginand remove test database. Basically answer yes[Y] to all if you are installing this on a machine available from the internet.

5. On both servers:

sudo systemctl enable mariadb.service
sudo systemctl start mariadb

The first command will make the mariadb server start every time the machine is re/started and the second will just the start service right now as it still not running.

6. On the master server create empty database

MariaDB [(none)]> mysql -uroot -p
MariaDB [(none)]> create database database_name;

7. On the master server we need to enable binary logging.
– Backup the original file in /etc/mysql/

cp my.cnf my.cnf.bkp

Add this new lines under the [mysqld] section, and replace the IP address with the one your master machine have.

#Replication settings
log-bin
server_id=1
bind-address=192.168.122.25
binlog-ignore-db = information_schema
binlog-ignore-db = mysql
binlog-ignore-db = performance_schema
binlog-ignore-db = test

This will replicate all new databases to the slave server, if you like to replicate just one specific database you should use

replicate-do-db = 

8. Now we need to login to the master sql server and create replication user and give the necessary grants.

MariaDB [(none)]> CREATE USER 'slave'@'localhost' IDENTIFIED BY 'SomePassword';
MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO slave IDENTIFIED BY 'SomePassword' WITH GRANT OPTION;
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> FLUSH TABLES WITH READ LOCK;
MariaDB [(none)]> SHOW MASTER STATUS;

The last command output is important in order the slave to know from which point it should start replicating from.

Unlock the databases and exit:

MariaDB [(none)]> UNLOCK TABLES;
MariaDB [(none)]> exit;

9. Login to the slave and create another empty database with the same name and the slave user.

CREATE DATABASE DATABASE_NAME;
CREATE USER 'slave'@'localhost' IDENTIFIED BY 'SomePassword';
FLUSH PRIVILEGES;

10. Add this the to the [mysqld] section in /etc/mysql/my.cnf in the slave:

server_id=2

Note that the master have server_id=1 so you should have different IDs on the different servers.

11. Log in to the slave database and run the following commands in the MariaDB prompt. Double check the MASTER_LOG_FILE and MASTER_LOG_POS variables, which should be the same as the values returned by SHOW MASTER STATUS above.

MariaDB [(none)]> CHANGE MASTER TO
MASTER_HOST='192.168.122.25',
MASTER_USER='slave',
MASTER_PASSWORD='SomePassword',
MASTER_PORT=3306,
MASTER_LOG_FILE='mariadb-bin.000001',
MASTER_LOG_POS=314,
MASTER_CONNECT_RETRY=10,
MASTER_USE_GTID=current_pos;

Now start the slave and check the status without exiting the MariaDB prompt:

MariaDB [(none)]> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G;

12. Test the replication:
login in the master server and create table in our empty database:

CREATE TABLE IF NOT EXISTS names (
task_id INT AUTO_INCREMENT,
title VARCHAR(255) NOT NULL,
start_date DATE,
due_date DATE,
status TINYINT NOT NULL,
priority TINYINT NOT NULL,
description TEXT,
PRIMARY KEY (task_id)
) ENGINE=INNODB;

You should see the new table created on the slave server too.

13. Debug: If there is something wrong with the slave replication it should show with when you run

SHOW SLAVE STATUS\G;

Most of the time problems are easily resolved with updating the slave configuration with the

CHANGE MASTER

query, stopping and then starting the slave. Watch for log position and the log file name.

So first of all you need to make sure what is your key “called”, you can to that with the xev program.

Then you need to get your modifier map with: xmodmap -pm
In my case my output was this:

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

I use mod4 for my i3 config, so I needed to add the Print key to the mod4 modifier with this command:

xmodmap -e "add mod4 = Print"

After that we see that Print is added to the mod4:

mod4        Print (0x6b),  Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf),  Print (0xda)

And you will probably want to add this command to your i3 config so it get excuted on each boot:

exec --no-startup-id /usr/bin/xmodmap -e "add mod4 = Print"

mount -t tmpfs -o size=64M tmpfs /absolute/path/to/your/folder/

To make it permanent you need to add this in the /etc/fstab file:

tmpfs /absolute/path/to/your/folder tmpfs defaults,size=64M 0 0

The file is /etc/systemd/system/brightness.service
but there is symlink from the /etc/systemd/system/multi-user.target.wants directory.

This are the contents of the service file:

[Unit]
Description=Alter permissionsfor brightness

[Service]
ExecStart=/bin/chmod go+rw /sys/class/backlight/intel_backlight/brightness
ExecStop=/bin/chmod go+rw /sys/class/backlight/intel_backlight/brightness

[Install]
WantedBy=multi-user.target

You will also want to enable and start the service with:

systemctl enable brightness.service
systemctl start brightness.service

All of this action is happening on Ubuntu 18.04