Rsync config with MailinaBox gives: invalid literal for int() with base 10: ” message

Mail in  a Box (mailinabox) can backup its mail with rsync to a destination of your choice. When it was working but your target backup machine has been changed suddenly mail in a box comes with the message: invalid literal for int() with base 10: ”

You checked, double checked your settings and they are all ok .. but still the above message. The reason is that Mail in a Box keeps a record of your SSH keys to protect itself:

messages like:  WARNING: POSSIBLE DNS SPOOFING DETECTED!  and

The ECDSA host key for [my.box.org]:22 has changed,
and the key for the corresponding IP address [target.ip]:22 has a different value. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. Offending key for IP in /root/.ssh/known_hosts:7

Normally this is good behaviour but now you need to have fixed this: its easy with this command
ssh-keygen -f “/root/.ssh/known_hosts” -R [my.domain.name]:port

 

Multiple SSH instances on OpenMediavault

I have a port 22 open towards a device allowing me to logon. I have mutiple other devices also with SSH but I do not want them available over the internet. This is fine as long as you do nothing in your portforwarding.

But as I wrote earlier in a previous post: I need SSH for my RSYNC backup. This cannot run on port 22 as the device where port 22 is open is not the device running what is the target for the RSYNC job.

So we do configure openmediavault (4.x) to have 2x a SSH instanc running on a different port with a different configuration

The 2nd instance allows only a login with public key. All other logins are disabled.

Simple steps:

cp /lib/systemd/system/ssh.service /etc/systemd/system/sshdrsync.service
modified 1 certain part in the target file:
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd_rsync_config $SSHD_OPTS

than copied the standard ssh config from OMV to the sshd_rsync where I modified the port to the port it needs to run on.

this you can find in /etc/ssh

Please note that in the ssh file I already had the include part about the public key (where to find it).

than: 2 commands:

systemctl enable sshdrsynd.service

systemctl start sshdrsync.service

ready set and go .. 10 min work. (testing is simple ssh to the new port, your login will tell you that it is only allowing with public key.

Backup MIAB (Mail in a Box) through Rsync towards Openmediavault Server

Mail in a box (MIAB) has a backup feature available. It stores full and incremential backups on the mailserver and it is possible to store the backup also on another device through RSYNC. In my situation I am saving the data to an OpenMediaVault NAS

Here I write my own: How I did it (quick and dirty cause I expect you to know things).

In short:
rsync over port 5678 to backup your data to the OpenMediaVault NAS

  1. Make sure you have a hostname available where rsync can be connected to, the hostname must point to the IP where the OMV (OpenMediaVault) is connected
  2. Rsync over SSH is being used.
  3. if you do not want to use port 22 with Rsync, you need to modify /root/mailinabox/management/backup.py line 19: change -p 22 to -p 5678
  4. Enable Rsync Server in the GUI (Grapical User Interface) of openmediavault.

Please note that it is not possible to use the ~/.ssh/config file where you can add the port as well. The reason is that the verification process needs in the backup.py a -p setting which is not overridden bij de config file.

  • SSH standard port 22, this we will change. (ie. port 22 is already in use towards another server)
  • In the router go to your portforwarding section and open port 5678 towards port 22 to your device (with OpenMediaVault).
  • MIAB and RSYNC needs to have the full path where to store the backup. In my situation: /media/a925efd7-ada5-48b5-80e6-383cc6274bcd/Backup (the folder must available and writable
  • Make sure that a user can login with SSH and can access OpenMediaVault
  • MIAB is providing a public key for auto-login needed for rsync. this key must be available in OpenMediavault. You can put the public key in: ~/.ssh/authorized_keys or in a folder in /var/lib/openmediavault/ssh/authorized_keys where you create a file with the name of the user
  • within MIAB you can use from /root/mailinabox/ the following: sudo management/backup.py –verif

to test if your public key is accepted: from MAIB ssh with the following command:  ssh -p 5678 -i /root/.ssh/id_rsa_miab user@domain.name

If this is giving you a direct login to your OpenMediaVault NAS you can use Rsync ;)

Missing something? Reply and ask

 

VLAN for Guests with Ubiquity: Unifi USG, USW8-150, AC-Pro, AC-LR and other stuff

This posts is merely an overview of what I did to get my WLAN guests, who access the Internet through the hotspot feature of the USG and the Unifi controller,through a VLAN so that they are not part of my own private network. (security)

This handout only applies when you own some gear of Ubiquity. (I have also other hardware, here you might have to make some configuration as well, my situation is explained.

What hardware is in the network
USG Router – US 8-150W switch – AC-Pro, 2 x AC-Lite AccessPoint (Unifi stuff)
1x TP-Link TLSG108E (Smart Switch)
2x Dump switch 5 port Netgear (not important in this story)
1x TP-Link TLSG2216 (Smart Switch)

1st Create a guest network with VLAN100. Do this only if you have the USG. If you do not have an USG this does not apply cause the network part in the controller is for use with the Unifi USG router.

If you use “Guest” it is already isolated from your corporate LAN.
Modify other settings like DHCP in this menu. This I do not explain.

Now make sure your SSID for your guests can be on a VLAN

This is the most important part.

Notice: I have an US-8-150W. When creating a VLAN Guest network in the profiles part of the controller the ports will be configured automatically. As long as you have all profiles accepted on the ports, the VLAN will directly work if your AccessPoint is directly connected to the Unifi Switch.

In my situation I have 2 AccessPoints behind a smart switch and 1 AccessPoint connected to a dumb switch what is connected to the US-8-150W (all devices eventually come to the US-8-150W as the uplink is the USG Router).

A simple test towards the AP connected to the dumpswitch is showing that the VLAN is working

To have the VLAN100 working towards the other APs you need to tag the ports in other smart swiches. In my situation 2 different TP-Link devices

Tips for the TP-Link: TLSG108E: enable 802.1Q (no need to set the 802.1Q PVID setting)

In my example you see that port 1 and port 6 are tagged with VLAN 100. Port 1 is the uplink port towards the other switch (the unifi switch) and port 6 is the port towards the AccessPoint

Apply and save the configuration and your guests can access the guest portal over VLAN

the TP-Link SG2216 is a business smart switch so the screens are a little different

Here you see the VLAN section of the SG2216 where I tagged port 16 (uplink port towards the Unifi Switch) and port 10 connected to the AccessPoint. Now this AccessPoint is also serving VLAN towards my Guests.

Maybe you wonder what will happen to your normal LAN clients when you enable or tag ports on VLAN100: your normal LAN is not tagged and the switches will forward your data normally.

Add route to Linux system to allow a VPN connection access the System which is behind a VPN ;)

Okay machine ‘I am behind a VPN’ can be accessed locally: 10.1.1.20, with OpenVPN it is behind an external IP address, not mine
I set up a VPN to my local network: 10.10.10.50 is my IP when I am behind a VPN, when I try to access 10.1.1.20 it is not allowed, where other machines in the same network are ok.
This is due to the OpenVPN connection being active (when disabling OpenVPN, than all is ok), so trying to be able to allow the remote VPN access the machine.

Now I did 2 things and I believe the first command did it.

1. used a new route:
ip route add 10.10.10.0/24 (VPN) via 10.1.1.100 (router) dev eth0

and I used
2. iptables -A INPUT -s 10.10.10.50 -j ACCEPT (but this one did not work, but I will mention it .. you never know)

Kodi and texturecache

There is a nice tool for updating your db (mine is MySQL) with a tool called texturecache

this info is for my own purpose if useful use it

Crontab in place

0 */2 * * * sh /home/kodi/kodiupdate.sh > /dev/null 2>&1

#!/bin/bashNAME=texturecache
INIT_DIR=/etc/init.d
echo “Start Scanning Video Library vscan”
/home/kodi/texturecache.py vscan
sleep 5
echo “Start Cleaning Video Library vclean”
/home/kodi/texturecache.py vclean
sleep 5
echo “Start update with qax”
/home/kodi/texturecache.py qax
echo “Start scanning texturecache with function C”
/home/kodi/texturecache.py c
sleep 5
echo “Prune data missing on disk P”
/home/kodi/texturecache.py P
sleep 5
echo “Start update with Xd”
/home/kodi/texturecache.py Xd
sleep 3
echo “Start update with ./texturecache.py R”
/home/dennis/kodi/texturecache.py R
sleep 3
echo “end”

Make sure that there is a connection with your “Master Kodi”
create a samba link in /etc/fstab ie. example
//192.168.1.115/Userdata/ /media/kodi cifs guest,uid=1000,iocharset=utf8 0 0
now the thumbnails can be saved correctly

Fixing BSOD within Windows 2008 R2 after installing wrong VIOSTOR driver under Cloudstack

I needed to expand my Windows 2008 R2 server with extra HDD data. I had an ISO available with VIOSTOR drivers (Virtio Storage) and autodetected the drivers. How could I be so stupid.

after reboot: BSOD and BSOD and stupid as I was I was unable to go back to ‘last good known configuration’.

first of all I had to pick the drivers for Windows 2008 from this location: ISO/viostor/2k8/(R2 if you have it)/amd64/viostor.*

To stop the BSOD from happening:

Find the viostor drivers (probably):

Windows/System32/drivers/viostor.sys
Windows/DriverStore/FileRepository/viostor.inf_amd64_neutral_b5a4b523b42ac3b3/viostor.sys
Windows/DriverStore/FileRepository/viostor.inf_amd64_neutral_e322cb56cfbcc209/viostor.sys
Windows/LastGood/system32/DRIVERS/viostor.sys

Rename Windows/System32/drivers/viostor.sys to System32/drivers/disabled.viostor.sys.disabled;

Similarly renamed both Windows/DriverStore/FileRepository/viostor.inf_amd64_neutral_b5a4b523b42ac3b3/viostor.sysand Windows/DriverStore/FileRepository/viostor.inf_amd64_neutral_e322cb56cfbcc209/viostor.systo disabled.viostor.sys.disabled

Then reboot.

Please be noticed that it can cost you a NEW license if you add this driver. Your hardware can be changed and it could be that Microsoft does not allow your key anymore.

Fixing design issue – Expand Windows 2008 r2 – Drive C: partition size where Drive D has enough size available under Cloudstack

Situation:

A number of Windows 2008 server installations where designed to have 1 DISK with 100GB deviced in 50GB C and 50GB D. Unfortunately 50GB is too less if you run a server and want to apply all patches. (Previous downloaded patches are kept in a ‘storage’ and cannot be deleted, finally consuming a lot of HDD space.

To solve this: add a DATA DISK to the instance in Cloudstack. Please note: the DATA DISK will not be found / seen or identified automatically by the Windows Server

Through the managment panel within Cloudstack you need to attach an ISO: VIRTIO (Leaseweb does provide this)

Within the Device Manager an SCSI device has been found, but no drivers can be applied, therefore the ISO you need to attach so that the VIRTIO drivers can be applied to your machine.

Now the drive will become available and you can format etc..

To expand the C drive: remove all data from the partitions/drives not needed (D, E etc.) You can also copy the content to the new DATADISK you now have.

By default through the DISK MANAGER (under Server Manager) you  CANNOT expand the root / boot disk. You can try all kinds of freeware stuff: no go, it will all point you to version you have to pay $$ for.

The solution is to use DISKPART. As Administrator open a CMD window and enter:

DISKPART <Enter>
List Disk <Enter>
Select Disk 0 <Enter> (Assuming that Disk 0 is your boot/root disk)
Detail Disk <Enter>
Information about your disk is given, you see the volumes
Select Volume 1 <Enter> (or 2 depends what is your Volume with C)
Extend Size = 20000 (20000 gives you an expand of 20GB for your C drive).

Repeat some commands if not all storage is given to C ..

Exit <Enter>

Performance issues HP Microserver gen8 and VMWARE EXSI 6.5

upgraded ESXI to 6.5 U1 which is version 6.5.0 build 5969303

You are running HPE Customized Image ESXi 6.5.0 version 650.10.1.0.47 released on July 2017 and based on ESXi 6.5.0 Vmkernel Release Build 5310538

unfortunately the HP Microserserver Gen8 is than running with: HPE_bootbank_scsi-hpvsa_5.5.0.102-1OEM.550.0.0.1331820

As I was (and still am but as of writing I am in maintenance mode) seeing spikes in my CPU usages. It might be caused by the bad performance

checking with:
cd /vmfs/volumes/datastore1
time dd if=/dev/zero of=tempfile bs=8k count=1000000

It took a very long time to see some output. (Very long time!)

than I tried to downgrade to the hpvsa-5.5.0-88.zip driver

guidelines:

  1. enter maintenance mode
  2. I do a reboot, but you can do it probably without
  3. copy the downloaded driver to /tmp/ and run the following command
  4. esxcli software vib install -d /tmp/hpvsa-5.5.0-88.zip
  5. the old driver will be removed and the 5.5.0-88 driver installed
  6. Now important: if you do reboot this way: you will not see your DataStores anymore, only your NFS datastores (in my situation) this is caused by VMWARE ESXI as it will be using vmw_ahci driver for the datastore.
  7. so disable the usage of this ‘default’ driver: esxcli system module set –enabled=false –module=vmw_ahci
  8. now you can reboot and your device will be using the 5.5.0-88 driver
  9. you can see this by using; cat /proc/driver/hpvsa/hpvsa0

the speed should have been returned.

 

The hassle of upgrading ESXI 6.0 to ESXI 6.5 on a HP Microserver gen8

Wauw ..

yesterday and today I tried to upgrade my HP Microserver Gen8 from VMWARE ESXI 6.0.0 to 6.5
what a trouble ..

Steps:
shut down all vms (hosts) and enter maintenance mode. If you do this there are a number of online blogs with help to install from online depots but in all my tests it was too slow or I was to impatient to wait to end. But in the end I always ended up with an system with errors:

the transaction is not supported: VIB Hewlett-Packard_bootbank_scsi-hpvsa_5.5.0-88OEM.550.0.0.1331820

Do not try to force the installation. You will end up with an system where it seems that your EXSI is updated to 6.5 but actually is is running in a ramdisk environment. Easy to see cause you have lost your datastores (NFS datastores are still mounted).

If you than reboot: you are back to 6.0.0 .. so how to solve this:

easy: when entering maintenance mode: reboot your machine. In many guidelines this part is not mentioned.

After I rebooted I first tried the online depot installation documentation but ended up waiting and waiting. I got a VMWARE image for update from VMWARE but I got all kinds of different issues again:

“The upgrade contains the following set of conflicting VIB” When using the standard image of VMWARE: many conflicting vibs a no go for me. So I read some blogs and I found out that it is best to keep using your HPE image vmware files. (So in short: if you used the HPE VMWARE ESXI ISO installing Esxi onto your HP Microserver Gen8 keep using the update files with HPE in it and not the plain VMWARE onces. It can give issues !

After I used the HPE image I only got 1 issue: one vib was still complaining. On this blog I read what I needed to do: remove this vib (partner supported, so not native).

After removing this VIB I could upload the various ZIP bundle files like

VMware-ESXi-6.5.0-5310538-HPE-650.10.1.0.47-Jul2017-depot.zip
VMware-ESXi-6.5.0-Update1-5969303-HPE-650.U1.10.1.0.14-Jul2017-depot.zip

with the command:
esxcli software vib install -d “/vmfs/volumes/datastore1/patch-directory/VMware-ESXi-6.5.0-5310538-HPE-650.10.1.0.47-Jul2017-depot.zip”

I was able to install finally the 6.5 version. Due to issues of Storage driver I immediately updated to the U1 update
with the command:

esxcli software vib update -d “/vmfs/volumes/datastore1/patch-directory/VMware-ESXi-6.5.0-Update1-5969303-HPE-650.U1.10.1.0.14-Jul2017-depot.zip”

the blog nxhut showed me some info that with the U1 version the storage speed performance issues should be over.

A simple test downloading a file towards a VM showed me a 18MB/s so the 10MB/s barrier was not seen.

A last reboot and get the machine out of maintenance mode. Finally I have a running 6.5U1.