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.
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.
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.
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.
Weekly Raw Stats – Overall weight is down 6.1 lbs – My Body Fat is down 3% – My Muscle Mass is up 2.8% – Bone Mass is up 0.2% – BMI is down 0.8 – My VO2 max is up – Sleeping has never been better – Feeling less stressed
Review Getting started is definitely the toughest part. Over the last few rides I can definitely feel a change in my breathing which is reflected in my VO2 max score. Also while doing the free-rides I’ve notices a definite change in the effort needed to bike. Theres definitely some new muscle.
pi@raspberry01:~/Scripts/keepalive$ cat keepalive.sh
#bin/bash
## BAINWERX
## NVME Keepalive Read|Write Script
## version 1.2
## created Feb 2021
## Time in 12 hr format
logging_time=$(date +'%r')
## backup dir format
logging_dir=$(date +'%m_%d_%Y')
find /home/pi/Scripts/keepalive/*.log -mtime 1 -delete;
echo "NVME Keepalive Read|Write at" "${logging_time}" >> /home/pi/Scripts/keepalive/"${logging_dir}".log
Runing this script will create a .log file with a simple write to the nvme drive. Next step wil be to setup a cron task with
sudo crontab -e
add the following lines to enable the script
# nvme drive keepalive by posting to drive every minute
*/1 * * * * sudo sh /home/pi/Scripts/keepalive/keepalive.sh
Now Save and reboot the system.
NOTE
If you are adding this with pihole…you might want to add the following step which will run when the pi is rebooted. It tells the pi that when it reboots…wait 15 seconds and then restart the pihole dns resolution
# On reboot + 15 seconds restart the pihole dns resolver (loop prevention)
@reboot sleep 15 && sudo pihole restartdns
Now that I have my “base cluster” up and running with ProxMox, it’s time to turn my attention to how I’m going to manage it.
After creating a new management user I setup ssh certs to permit ssh traffic from the master to slave systems.
Instalation of Ansible was a breeze
$ sudo apt update
$ sudo apt install software-properties-common
$ sudo apt-add-repository --yes --update ppa:ansible/ansible
$ sudo apt install ansible
After creating an inventory file, and then a quick and dirty playboook...I tested it out and...
voila!
First run went smashing..although it showed that there WAS actually an update or two on 2/3 of the servers.
After running my playbook again it looks like everything was in fact in order.
Building a raspberry pi ad blocker is pretty slick, but to really take advantage of the opportunity provided I’ve also installed unbound which is a full-fledged DNS resolution tool.
A cruise line spent hundreds of millions of dollars to build a new highly efficient cruise ship. Everything tested fine and the ship was launched successfully, on budget, and on schedule.
On its maiden voyage, its engine failed. The brand new crew ran through their basic tests, searched manuals, but were unable to fix it themselves. The ship’s owners tried one ‘professional’ after another but none of them could figure out how to fix the broken engine.
They brought in a local shipwright. He was an older man, had grown up on the docks, and had been fixing ships for as long as people could remember. He carried a small bag of tools with him, and when he arrived on board he immediately went to work.
He quietly inspected the engine very carefully, top to bottom. Two of the ship’s owners quietly watched the man, hoping he would know what to do. But as time dragged on, they didn’t think it was looking good as they noticed the man quietly speaking to himself as item after item checked as “being ok”.
After looking things over, the old man reached into his bag and pulled out a small hammer. He gently tapped something on the side of the control panel, and instantly the engine lurched into life.
He carefully put his hammer away, the engine running properly.A week later, the owners received an invoice from the old man for $50,000. Stunned with the amount of money, the owners asked the shipwright to provide an itemized invoice.
The man responded with an invoice that read: Tapping with a hammer – $2.00,Knowing where to tap – $49,998.00
Experience, and knowing where to direct that effort makes all the difference in the world.
You must be logged in to post a comment.