Jun 162017
 

Been searching for a tool to streamline ZFS replication between my storage arrays and I think I found it – it’s called syncoid.

Installation

# ubuntu
apt install pv lzop mbuffer libconfig-inifiles-perl git -y
# centos
yum install pv lzop mbuffer perl-Config-IniFiles.noarch git -y


cd /usr/src/
git clone https://github.com/jimsalterjrs/sanoid.git
cp sanoid/syncoid /usr/local/sbin/

Now setup SSH keys for passwordless root login and create cronjob to fire up /usr/local/sbin/replication-syncoid.sh once a day/week/whenever suits you.

0 0 * * 1   /usr/local/sbin/replication-syncoid.sh|logger

Where /usr/local/sbin/replication-syncoid.sh is

#!/bin/bash
FILESYSTEMS="apps home service vmfs"
LOG=/var/log/syncoid.log
for i in $FILESYSTEMS; do 
echo "---------------  `date` - syncing $i -------------" >> $LOG 2>&1 
/usr/local/sbin/syncoid -r root@mielnet-second-tier0022:tank/$i cistern/$i >> $LOG 2>&1
echo "---------------  `date` - done $i -------------" >> $LOG 2>&1
done

 

No matching ciphers

You may get a message:

"no matching cipher found: client [email protected],arcfour server aes256-ctr,aes192-ctr,aes128-ctr,arcfour256,arcfour128" 

most likely when you run Centos 6 on target host. You need to check for available ciphers on target host and modify syncoid script accordingly.

# ssh -Q cipher root@mielnet-second-tier0022| paste -d , -s
3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected]

and paste output from above on line 39 of /usr/local/sbin/replication-syncoid.sh

$sshcipher = '-c 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected] ';

 

Now your sync will run OK.

 

Summary

It gets the job done nicely and saves me from writing my own bash-perl-voodoo-black-magic-fuckery.

Thanks Jim.

Sep 082016
 

malamute

Got hit by this problem after upgrading Thinlinc 4.4 to 4.6 on one of my Debian Jessie boxes.

After upgrade process and setup completed I ran commands to get around Debian issues as documented here:

sudo update-rc.d vsmagent defaults
sudo update-rc.d vsmserver defaults
sudo update-rc.d tlwebaccess defaults
sudo update-rc.d tlwebadm defaults
read thinlinc version < /opt/thinlinc/etc/thinlinc-release
/opt/thinlinc/bin/tl-config /vsm/setup_completed=${version}
sudo service vsmagent start
sudo service vsmserver start
sudo service tlwebaccess start
sudo service tlwebadm start

Then  I tried reconnecting to the session and Thinlinc client generated dreaded “No password configured for vnc auth”. Error is not particularly clear  and the only clue from Thinlinc mailing list was

 

Typically, this error message indicates "disk full" on the server and 
similar problems. The user could also be out of quota. It could also be an 
issue with SELinux. Basically, if Xvnc cannot access 
/var/opt/thinlinc/sessions/${USER}/X/sessionkey, you will get this 
error.

which wasn’t the case here.

What helped, I murdered all “tl-session” processes and restarted vsm*

pkill tl-session
systemctl restart vsmagent vsmserver

and after that Thinlinc was more keen to start a session for me. Jolly good.