I have no words…

At some point since 2019 our 2014 Honda Odyssey EX-L backup sensors just mysteriously stopped working for no apparent reason.

As a result of this, the van has had 3 rear end incidents as the result of backing the vehicle up (as the sensors no longer worked).

As I am prepping the van for a road trip this year, I thought just for the heck of it I would buy a new backup sensor switch…just in case that was the culprit.

10 second job to replace…and…nope!

I searched the internet for “honda odyssey 2014 parking sensor blinks” and this little gem popped up.

WHO KNEW YOU COULD TURN ONLY THE REAR SENSORS OFF.

NOT DISABLE TEMPORARILY…BUT TURN OFF INDEFINITELY.

Don’t worry provincial government, it’s not your fault.

The province recorded the lowest voter turnout in history during this 2022 provincial election, with roughly 44% of eligible voters casting a ballot.

Less than 50% bothered to get out and vote. What really bothers me though are the ridiculous comments about how one Provincial leader or another is going to cut healthcare and education, and it’s apparent that not everyone understands how it all works together.

Ontario healthcare and education is publicly funded by the Ontario taxpayer to the Province of Ontario.

What we generally fail to take into consideration is the impact of the other tier of government.

When the FEDERAL government financially drains the middle-class, the lower-class grows. This tranlates into two major compounding problems.

Problem #1, with less taxes being collected from the middle-class due to there being fewer of them, there are now less tax dollars to go into existing services like healthcare and education.

Problem #2, is that because the lower class has expanded, there is an increased demand for additional support services. These are generally non-profit serfvices, and as a result require tax funding….meaning less money for education and healthcare.

The future cuts to education and healthcare will be because of the federal government, not the provincial one.

We as a province need to be moving people into the middle class. This increases incoming tax dollars, and reduces stress on critical support services.

As long as the middle-class is targeted by the federal government it’s just a matter of time before the system fails. You don’t have critical support services if you don’t have a group of people footing the bill. Consider this the next time you vote.

Portainer Update (updated 08/28/2022)

After the last portainer update to 2.9.3, I noted that the documentation was manually pulling an older version of the software. It’s key to make sure that you are always downloading the LATEST version of portainer.

Step 1 update the linux distro

sudo apt-get update && sudo apt-get upgrade

Step 2 – Stop Portainer container

sudo docker stop portainer

Step 3 – Remove the container

sudo docker rm portainer

Step 4 – pull the latest image

sudo docker pull portainer/portainer-ce:latest

Step 5 – Deploy the updated version of Portainer

sudo docker run -d -p 8000:8000 -p 9000:9000 -p 9443:9443 -–name=portainer —restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

PHPBB 3.3.5 Upgrade

I was up for a good chunk of the night last night updating a phpbb3 forum. I’ve done this same upgrade LITERALLY 100’s of times. The corollacustomz group used to run this same forums set and it was never an issue. This upgrade shouldn’t be rocket science…but clearly there’s something broken with the 3.3.5 file set. No matter what I attempted to perform, I would get errors and it seemed like I was trying to convert rather than upgrade.

I ended up doing everything that I was asked to do….and then manually running the upgrade service via command-line on the site itself. In the future, I think I’m just gonna do it this way because it’s truly a heck of alot easier to perform this task uploading the needed files, running the script, and then deleting the install directory.

php ./bin/phpbbcli.php db:migrate –safe-mode

Cogeco & Hitron CODA-4589

I received a call for help earlier this week from a family member. Their internet service was recently upgraded, and worked fine for a little bit, and then suddenly it was unstable. Oddly enough, while speaking to the user they were able to connect to a vpn and browse the internet just fine.

First thoughts went to DNS resolution, and I arranged to head out there and take a look. What I discovered was a double-nat issue as well as a minor configuration on the users home router (not their fault at all).

While a substantial and quality router, the way that Cogeco implemented their firmware onto this device is frustrating to say the least. Fortunately for most users….while NOT being able to actually bridge this router (despite fully disabling the wireless & disabilinn gateway mode), there is a workaround that works equally as well.

Connect your home wireless router to port 1 on the Hitron, and then enable internet pass-through on port 1. This works only because the Cogeco service provides 2-3 external ip addresses to each router.

The frustration here is that is SHOULD be as easy and just putting the Hitron into a pass-through configuration, but when this is done, the Cogeco firmware rears its head and double-reboots the Hitron…forcing the router to restore to it’s original configuration. Despite pulling out all the trick I know with these routers, the Cogeco firmware is a real “treat” (note the sarcasm) to work with. To be fair, it likely has more to do with a features that isn’t obvious to any of us…but having a router that can actually be put into a bridged mode would be an asset.

But passthrough works, and the user seems happy now that their home internet is back up and running.

Resizing an Ubuntu LVM Host!

I spent hours trying to find instructions on how to resize my Ubuntu virtual hosts after one of my cluster workers seemingly ran out of space (randomly). After working out the basics, I was able to resize my drives correctly after assigning them the correct disk size in ProxMox.

root@server:~# fdisk -l

GPT PMBR size mismatch (104857599 != 209715199) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
Disk /dev/sda: 100 GiB, 107374182400 bytes, 209715200 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 396A0315-7944-49AC-BBFF-7AD2F7747AC9

Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 2101247 2097152 1G Linux filesystem
/dev/sda3 2101248 104857566 102756319 49G Linux filesystem

Disk /dev/mapper/ubuntu–vg-ubuntu–lv: 48.102 GiB, 52609155072 bytes, 102752256 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
root@server:~# parted
GNU Parted 3.3
Using /dev/sda
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) resizepart
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an
extra 104857600 blocks) or continue with the current setting?
Fix/Ignore? Fix
Partition number? 3
End? [53.7GB]? 100%
(parted) quit
Information: You may need to update /etc/fstab.

root@server:~# pvresize /dev/sda3
Physical volume “/dev/sda3” changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

root@server:~# lvextend -l +100%FREE /dev/mapper/ubuntu–vg-ubuntu–lv
Size of logical volume ubuntu-vg/ubuntu-lv changed from <49.00 GiB (12543 extents) to <99.00 GiB (25343 extents).
Logical volume ubuntu-vg/ubuntu-lv successfully resized.

root@server:~# resize2fs /dev/mapper/ubuntu–vg-ubuntu–lv
resize2fs 1.45.5 (07-Jan-2020)
Filesystem at /dev/mapper/ubuntu–vg-ubuntu–lv is mounted on /; on-line resizing required
old_desc_blocks = 7, new_desc_blocks = 13
The filesystem on /dev/mapper/ubuntu–vg-ubuntu–lv is now 25951232 (4k) blocks long.

root@server:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 2.9G 0 2.9G 0% /dev
tmpfs 595M 1.2M 594M 1% /run
/dev/mapper/ubuntu–vg-ubuntu–lv 98G 32G 62G 34% /
tmpfs 3.0G 0 3.0G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.0G 0 3.0G 0% /sys/fs/cgroup
/dev/sda2 976M 198M 712M 22% /boot
/dev/loop1 56M 56M 0 100% /snap/core18/1932
/dev/loop2 72M 72M 0 100% /snap/lxd/16099
/dev/loop0 56M 56M 0 100% /snap/core18/1944
/dev/loop3 68M 68M 0 100% /snap/lxd/18150
/dev/loop4 32M 32M 0 100% /snap/snapd/10492
/dev/loop5 32M 32M 0 100% /snap/snapd/10707
tmpfs 595M 0 595M 0% /run/user/1000

PiHole System v2.0

So I’ve noticed the PiHole being a little bogged down as of late. I’m only running it on a Raspberry Pi 3b+ at the moment so I know I am a little limited as to the performance…but as I have a couple of background projects I want to tackle this year, I thought I would take the oppotunity to replace the SD card with an NVME SSD drive (only about 5000 times faster).

Overall it was a pretty painless process…the big part was realizing that it takes 5-10 seconds for the USB to recognize the booth drive…but then it’s *BOOM* and we are back up and running almost instantly (pretty impressive actually).

The drive went together without a hitch, and was recognized and everything…but then…ROADBLOCK.

I boot off of an SD card…how do I image that to the NVME drive?

Thankfully someone else ran into this same issue and wrote a script/small app to resolve this very issue…and DAMN is it easy and impressive. With a small installation and a simple command of…

$ rpi-clone sda

I was up and running with no issues!

================================================================

Mad props to https://github.com/billw2/rpi-clone

On a Raspberry Pi:

	$ git clone https://github.com/billw2/rpi-clone.git 
	$ cd rpi-clone
	$ sudo cp rpi-clone rpi-clone-setup /usr/local/sbin

Make sure /usr/local/sbin is in your $PATH and then run rpi-clone or rpi-clone-setup with no args to print usage.

rpi-clone-setup is for setting the hostname in /etc/hostname and /etc/hosts files. It is run automatically by rpi-clone if -s args are given, but before your first clone using a -s option, test run rpi-clone-setup with:

      $ sudo rpi-clone-setup -t testhostname

And check the files under /tmp/clone-test to be sure the files have been edited correctly. If you need additional customizations to a clone, add them to the rpi-clone-setup script.