Replacing the battery in Balanzza Mini Rechargeable Scale

After my last trip to Mexico I had the desire to buy a rechargeable luggage scale so I didn’t have to remember to replace the batteries in it. When we travel we always have multiple USB chargers with us so a rechargeable luggage scale made a lot of sense. Based on the Wirecutters recommendation I looked to pickup a Balanzza Mini Rechargeable Scale (non-referral link).

I live in Canada and couldn’t find a local supplier and most online retailers in the US would have charged an arm and a leg on shipping or simply had no stock so I turned to eBay and found someone selling one, brand new condition, for a reasonable price.

I placed my order and waited the 2-3 weeks to arrive and when it finally got here it wouldn’t not power on. I figured the battery was dead and plugged it in to charge. After about 8 hours charging the charge light hadn’t switched from red to green. I was able to power on the scale and it worked until I disconnected it from the USB charging cable, then it died again. Seemed like either the charging component wasn’t working properly or the battery inside the scale was toast or had a bad connection.

The unit was brand new and in a sealed package so I didn’t feel like I’d been duped. I reached out to Balanzza support and heard nothing back after multiple attempts to contact them. Since I had nothing to lose at this point I decided to crack it open.

Sorry I didn’t take good photos of the inside initially, don’t know why:

Looks like the scale comes with a 100mAh LiPol battery (601522). These are easy enough to find on Amazon, eBay and Alibaba depending on how much money you want to trade off for time waiting for the battery to arrive.

I had some 240mAh LiPol’s lying around for a small quad copter drone so I figured I’d do a quick test with one of those to try and determine if the issue was the battery.

Very promising. This confirmed the included battery had no charge and was either toast OR the charging controller was faulty… or both. I cracked out the multi-meter and checked the 100mAh battery and it was toast, or at least toast looking enough I wasn’t going to bother trying to charge it. I also didn’t have a good way to charge it.

Space is tight inside the Balanzza and the original battery sat on the right side of the device in a very small space. Over on the left side of the scale there is a nice cavity that gave me a bit more wiggle room to put a bigger battery in but it was still too small to fit one of my 240mAh LiPols in so I was going to have to order something. Since I had to buy new batteries anyway I tried to find the biggest mAh LiPol that would fit inside the cavity on the left side of the Balanzza and came up with the 150mAh LiPol (402020) which measured 2.0cm*2.0cm*0.4 cm and would fit nicely. It seemed battery larger than that, mAh wise, was too physically large to fit.

Some quick soldering and shrink tube later:

and I ended up with a functioning scale. I also tested charging and after 1-2 hours the light went from red to green. Appears I fixed it and gained 50% more battery capacity!

SolarWinds Web Helpdesk 12.7.2 post-upgrade problems

Recently after upgrading our WHD from 12.7.1 to 12.7.2 we started experiencing two issues that turned out to be related.

Adding comments to tickets could generate an error stating: “Something went wrong. Please contact SolarWinds support for assitance or review the Web Hep Desk logs.”

and when trying to upload attachments to tickets: “Your upload failed: Connection reset by peer: Amount read didn’t match content-length”

After some back and forth with SolarWinds support they said the issue is related to the version of Tomcat they bundled with WHD 12.7.2. The bundled version is 9.0.31 and SolarWinds recommends manually upgrading it to 9.0.34 to fix the issue.

The procedure I followed was:

# Login to your WHD server and become root

# Make a temp directory, go into it and download Tomcat 9.0.34
mkdir temp
cd temp
wget -c https://muug.ca/mirror/apache-dist/tomcat/tomcat-9/v9.0.34/bin/apache-tomcat-9.0.34.tar.gz

# Stop WHD
service stop webhelpdesk

# Backup your existing WHD Tomcat directory just in case
cd /usr/local/webhelpdesk/bin
tar -cf tomcatBackup-20200423.tar tomcat
gzip -9 tomcatBackup-20200423.tar

# Copy Tomcat 9.0.34 overtop of Tomcat 9.0.31 while preserving WHD related content
cd ~/temp
cd apache-tomcat-9.0.34
cp -Raf bin conf lib NOTICE RELEASE-NOTES /usr/local/webhelpdesk/bin/tomcat/

# Reboot your server or manually start WHD back up
shutdown -r now
# OR
service webhelpdesk start

Once we did this the errors above went away.

Upgrading vSphere 6.7 to 7.0 using the Dell custom ISO

Took the plunge today and upgraded my homelab from vSphere 6.7 (Dell custom ISO) to vSphere 7.0 (again, Dell custom ISO).

My first attempted failed due to some dependency problems:

The main take away from this is:

QLC_bootbank_qedf_1.2.24.6-1OEM.600.0.0.2768847
QLC_bootbank_scsi-qedil_1.0.22.0-1OEM.600.0.0.2494585

I booted my node back up and enabled SSH and ran the following:

esxcli software vib list |grep qed

Which provided me a list of packages that included “qed”. I was able to quickly identify the packages with matching version numbers and then remove them:

esxcli software vib remove --vibname=qedf
esxcli software vib remove --vibname=scsi-qedil

After that I was able to reboot and perform the upgrade.

These appear to be QLogic drivers that likely came with the vSphere 6.7 Dell ISO and have since been dropped or replaced on the vSphere 7.o ISO. I don’t use any QLogic hardware in my server so removing them didn’t pose much of a risk to me.

How to use CIRA Canadian Shield with a Pi-Hole and DoH

CIRA (Canadian Internet Registration Authority) has recently launched a new DNS service called the “Canadian Shield” which is basically a DNS service similar to OpenDNS or Cloudflares 1.1.1.1 for Canadians, by Canadians.

CIRA offers three levels of protection depending on how safe you want to be:

  • Private: DNS resolution service that keeps your DNS data private from third-parties.
  • Protected: Includes Private features and adds malware and phishing blocking.
  • Family: Includes Protected and Private features and blocks pornographic content.

We use the Enterprise version of this service at my place of work and based on how we use it I’d say we’re using the equivalent of their “Protected” offering. We’ve had zero issues with the service and defiantly feels like it adds an extra layer or protection to our users.

Alright, enough free advertising (I am not receiving compensation from CIRA for this post).

When this was first announced I was eager to try it at home. CIRA’s instructions are how to either configure DNS over HTTPS (DoH) on a per-browser basis (not ideal for me since I have many devices on my network and don’t only use Firefox/Chrome) or configure your outbound DNS to use their servers over traditional, un-encrypted, DNS queries.

What I really want is to configure my Pi-hole which is my DNS endpoint for anything on my network to use the new CIRA service. This would capture ALL outbound DNS traffic and send it to CIRA making it so I only have to configure things in one place.

My current setup is: Clients -> 1 of 2 Active Directory DNS Servers -> Pi-hole -> Cloudflare via DoH (1.1.1.1 / Cloudfared)

This will easily work on a more traditional deployment of: Clients -> Pi-hole -> Cloudflare via DoH (1.1.1.1 / Cloudfared)

My Pi-hole is a basic CentOS 8 VM with the Pi-hole software installed on it with cloudflared so I can take advantage of DoH for all of my outbound DNS traffic. This is the minimum you need to get this working, a functional Pi-hole that is already sending it’s outbound DNS queries to Cloudflare (or another DoH provider) via cloudflared.

The first thing I did was re-configure my cloudflared to simply try using the CIRA DoH:

# Edit the cloudflared configuration file
vim /etc/default/cloudflared

# Commandline args for cloudflared to use 1.1.1.1
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query

# Changed the above to:
CLOUDFLARED_OPTS=--port 5053 --upstream https://private.canadianshield.cira.ca/dns-query

# Save and close the file

# Restart cloudflared
systemctl restart cloudflared

# Test DNS
nslookup google.ca

# This failed

 

This ended up not working and after I tried it I realized why. To be able to use private.canadianshield.cira.ca you have to have functioning DNS. Cloudflare has skirted this issue by using 1.1.1.1 and 1.0.0.1 for it’s service, they are IPs and do not need DNS to be working to function.

Fortunately the solution was very easy:

# I did a nslookup on the specific CIRA service I wanted to use (Private) via traditional DNS

nslookup private.canadianshield.cira.ca 1.1.1.1

Server:         192.168.0.4
Address:        192.168.0.4#53

Non-authoritative answer:
Name:   private.canadianshield.cira.ca
Address: 149.112.121.10
Name:   private.canadianshield.cira.ca
Address: 149.112.122.10
Name:   private.canadianshield.cira.ca
Address: 2620:10a:80bb::10
Name:   private.canadianshield.cira.ca
Address: 2620:10a:80bc::10

# If you want to use Protected or Family instead of private 
# do a nslookup on either protected.canadianshield.cira.ca
# or family.canadianshield.cira.ca instead and use those IPs

# I then edited my /etc/hosts file on my Pi-hole
vim /etc/hosts

# and added the following (I don't use IPv6 at this time):

# CloudA DNS
149.112.121.10 private.canadianshield.cira.ca
149.112.122.10 private.canadianshield.cira.ca

# Save and close the file

# Test DNS
nslookup cira.ca
Server:         192.168.0.4
Address:        192.168.0.4#53

Non-authoritative answer:
Name:   cira.ca
Address: 52.60.203.65

 

That’s it. I now have the CIRA Canadian Shield working on my Pi-hole using the cloudflared software.

Now for some DNS benchmarks, what’s faster? CIRA or 1.1.1.1?

I flushed the DNS cache on my Active Directory DNS servers and then restarted cloudflared on my Pi-hole before running these benchmarks:

1.1.1.1.1 / 1.0.0.1

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.009 | 0.052 | 0.196 | 0.043 | 100.0 |
  + DotCom Lookup | 0.009 | 0.013 | 0.027 | 0.004 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.009 | 0.051 | 0.195 | 0.044 | 100.0 |
  + DotCom Lookup | 0.010 | 0.014 | 0.028 | 0.003 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver

 

and here are the three CIRA services:

CIRA - Private

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.019 | 0.062 | 0.236 | 0.048 | 100.0 |
  + DotCom Lookup | 0.022 | 0.046 | 0.086 | 0.020 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.068 | 0.238 | 0.056 | 100.0 |
  + DotCom Lookup | 0.023 | 0.047 | 0.075 | 0.019 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver




CIRA - Protected

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.019 | 0.062 | 0.236 | 0.048 | 100.0 |
  + DotCom Lookup | 0.022 | 0.046 | 0.086 | 0.020 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.068 | 0.238 | 0.056 | 100.0 |
  + DotCom Lookup | 0.023 | 0.047 | 0.075 | 0.019 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver



CIRA - Family

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.064 | 0.246 | 0.053 | 100.0 |
  + DotCom Lookup | 0.022 | 0.039 | 0.080 | 0.018 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.073 | 0.248 | 0.062 | 100.0 |
  + DotCom Lookup | 0.024 | 0.049 | 0.082 | 0.020 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver

 

If I am interpreting this data correctly, CIRA is 0.010s-0.030s slower on average compared to 1.1.1.1. Hardly worth mentioning.

I’m happily switching over to a Canadian based DoH service (full disclosure, I’m Canadian). No offence Cloudflare, you still get to hold my DNS until CIRA starts offering their DNS Anycast Service for home users (hint hint).

Oh and just in case your curious, if you choose their ‘Family’ service and try and hit up Pornhub, you’re greeted with this:

Backing up a VM with a PCIe device attached to it with Veeam

In a previous post I talked about installing a Quadro P620 into my ESXi host so I could attach it to my Plex VM. This worked out great except my Veeam backups started failing.

There is a limitation in VMware vSphere where you can’t take a Snapshot of a VM with a PCIe device passed through to it.

One option is to install the Veeam Agent for the OS you’re running and use it to take guest based backups. This isn’t ideal though in my opinion. I would much rather keep my host based backups of the VM. Fortunately this is a easy solution to this problem.

Shut off the VM before taking the Veeam backup and then power it back on after the backup is complete.

To get this working you need to install the VMware PowerShell Module on your Veeam server. To do this perform the following steps:

  1. Right click on the PowerShell shortcut and choose ‘Run as Administrator’
  2. Run the following commands:
    Find-Module -Name VMware.PowerCLI
    Install-Module -Name VMware.PowerCLI -Scope AllUsers
    Get-Command -Module *VMWare*
    Set-PowerCLIConfiguration -Scope AllUsers -ParticipateInCeip $false -InvalidCertificateAction Ignore
  3. You should see a large list of VMware PowerShell commands output which means you’ve successfully installed the module

Next up you need to make sure your Veeam Services are running under a Service Account with the appropriate permissions in vCenter. I believe this is normally a best practice and chances are you’ve all already done this. In my case I’d installed Veeam as a local service. Don’t know why but to fix it I just flipped over the following Windows Services to run as my backup operator account which had Domain Admin, Backup Operator, Local Admin on the Veeam Server and Administrator on vSphere permissions already.

The services were:

  • Veeam Backup Enterprise Manager
  • Veeam Backup Service
  • Veeam Broker Service
  • Veeam Cloud Connect Service
  • Veeam Guest Catalog Service
  • Veeam RESTful API Service

I then rebooted my Veeam server.

I already have my vCenter service joined to my domain but I did run into an issue where single sign-on wasn’t working properly. If I attempted to connect to my vCenter server via PowerShell using “Connect-VIServer <VCENTER SERVER FQDN>” I would be prompted for credentials which shouldn’t be happening since the account I’m logged in as is an Administrator in vCenter.

Turned out I needed to add my AD Group that gives users Administrative access to the vCenter Global Permissions list:

  1. Login to vCenter as an administrator
  2. Click ‘Menu’ and ‘Administrator’
  3. Click ‘Global Permissions’
  4. Click ‘Add’
  5. Change the ‘User’ field to your domain, search for the user or security group (I recommend security groups) and select it, make sure the role is ‘Administrator’ and check ‘Propagate to children’ and click ‘Ok’

After doing this I could run “Connect-VIServer <VCENTER SERVER FQDN>” and not be prompted for credentials.

Now that all the prep-work is done we can re-configure our backup job in Veeam.

First we’re going to need two scripts, one to shutdown the VM and one to boot it back up. I’ve saved these scripts on my Veeam server in “C:\Scripts\<VM FQDN>\”

The shutdown script is “shutdown.bat”, be sure to search and replace “VCENTER FQDN” and “VM FQDN” with your values:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -executionpolicy bypass -Command Connect-VIServer -Server "VCENTER FQDN"; Shutdown-VMGuest -VM "VM FQDN" -Server VCENTER FQDN -Confirm:0; do{$vm=Get-VM -Name "VM FQDN"}while ($vm.PowerState -eq \"PoweredOn\")

The startup script is “startup.bat”, be sure to search and replace “VCENTER FQDN” and “VM FQDN” with your values:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -executionpolicy bypass -Command Connect-VIServer -Server "VCENTER FQDN"; Start-VM -VM "VM FQDN" -Server "VCENTER FQDN"; Start-Sleep -s 90

Once you’ve created these fire up the Veeam console and re-configure the VMs job:

  1. Launch Veeam
  2. Find the backup job for your VM, right click on it and choose ‘Edit’
  3. Go to ‘Storage’
  4. Click ‘Advanced’
  5. Go to ‘Scripts’
  6. Checkmark ‘Run the following script before the job:’ and select your “shutdown.bat” script
  7. Checkmark ‘Run the following script after the job:’ and select your “startup.bat” script
  8. Click ‘Ok’
  9. Click ‘Finish’
  10. Perform a test run of the job, you can monitor the start-up/shutdown in vCenter

That’s it. Minor inconvenience but it works. Hopefully vSphere 7 will allow for snapshots on VMs with pass-through devices configured.

References