Category Archives: Blog

The following command will allow host 192.168.1.10 to have write access and mount this volume remotely, all while identifying changes as ‘root’ – this is helpful for a container data store when you have docker running on a VM in proxmox but want to piggyback from the resilient ZFS storage in proxmox.

zfs set sharenfs="[email protected]" gdata/containers

I’m experimenting with TunSafe which is a fork of wireguard that includes traffic obfuscation built-in. Traffic obfuscation is useful to hide VPN traffic from ISP’s network throttling which is done when network packet inspection identifies a tunnel protocol.

You will need a privileged container in proxmox.

Add this to container configuration file

lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file


Without this setting on the configuration file of the container tunsafe will not start. Error similar to:

~# systemctl status tunsafe.service
● tunsafe.service - TunSafe service
   Loaded: loaded (/etc/systemd/system/tunsafe.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2021-01-24 19:22:59 UTC; 26s ago
  Process: 6949 ExecStart=/opt/tunsafe/tunsafe start -d /opt/tunsafe/TunSafe.conf (code=exited, status=1/FAILURE)
 Main PID: 6949 (code=exited, status=1/FAILURE)

Jan 24 19:22:59 tunsafe-gw systemd[1]: Starting TunSafe service...
Jan 24 19:22:59 tunsafe-gw tunsafe[6949]: Loading file: /opt/tunsafe/TunSafe.conf
Jan 24 19:22:59 tunsafe-gw tunsafe[6949]: Started TCP listening socket on port 443
Jan 24 19:22:59 tunsafe-gw tunsafe[6949]: Error opening tun device
Jan 24 19:22:59 tunsafe-gw systemd[1]: tunsafe.service: Main process exited, code=exited, status=1/FAILURE
Jan 24 19:22:59 tunsafe-gw systemd[1]: tunsafe.service: Failed with result 'exit-code'.
Jan 24 19:22:59 tunsafe-gw systemd[1]: Failed to start TunSafe service.

You can speed up resilvering times on ZFS (on linux) by temporarily changing the following settings:

echo 0 > /sys/module/zfs/parameters/zfs_resilver_delay
echo 512 > /sys/module/zfs/parameters/zfs_top_maxinflight
echo 5000 > /sys/module/zfs/parameters/zfs_resilver_min_time_ms

To reset back to defaults, do:

echo 2 > /sys/module/zfs/parameters/zfs_resilver_delay
echo 32 > /sys/module/zfs/parameters/zfs_top_maxinflight
echo 3000 > /sys/module/zfs/parameters/zfs_resilver_min_time_ms

A reboot of the system should also reset these defaults.

If you are like me, you wouldn’t want anyone with console access to your server to be able to have root credentials to the database engine if they own your server. The use of “mysql -u root” should not by default grant you root on the database server.

Well apparently in MariaDB 10.1.xx I found out this was the case, because of something they call “plugin” feature of “unix_socket” which is the default.

If you are seeing this on your system and want to confirm that’s why, use the following query in the mysql shell:

MariaDB [(none)]> select Host,User, Password,plugin from mysql.user;
+-----------+------+-------------------------------------------+-------------+
| Host      | User | Password                                  | plugin      |
+-----------+------+-------------------------------------------+-------------+
| localhost | root | *DEEF4D7D88CD046ECA02A80393B7780A63E7E789 | unix_socket |
+-----------+------+-------------------------------------------+-------------+

So to fix this, reset or update your root password first then execute this inside the mysql shell:

UPDATE mysql.user SET plugin = '' WHERE user = 'root' AND host = 'localhost';