Posts

The V8 engine: No, not the javascript one (part two)

Image
It's been a while since I felt like writing about anything, which is a shame because I do enjoy writing when I feel in the mood. Mostly this entry is about the long and tortured road to finishing the engine in my Chrysler 300C. A proper post-mortem In the last post, I have a shot of the destroyed piston which was causing most of the problems with the big Hemi. Once the engine was out of the car and on a stand, a mate and I carefully removed the sump to reveal a pile of bits. Two of the other cylinders were also missing parts of their crown but weren't damaged like #6 was. The bits in the sump were largely expected: pieces of piston crown; oil ring pieces; compression ring pieces. Assembled on the bench they look like around enough parts that were missing from #6 piston, but not the pieces that were missing from #4 and #2. Looking carefully at the other pistons, some carried evidence of valve strike. It was also apparent that this engine does not belong with this ca

The V8 engine: No, not the javascript one (part one)

Image
We live in an age where the internal combustion engine is headed for the scrap heap. Electrification of personal transport makes a lot of sense now. Batteries have improved dramatically in the last 30 years and with them both the performance and useful range of electric cars has begun to equal petrol and diesel motors. The major US manufacturers are planning to end-of-life their iconic engines in performance vehicles with hybrid powerplants. So, at the end of a significant age of transport, I figured it was time to buy a vehicle powered by the king of the hill of automotive engines: the American, thin wall cast overhead valve V8. In my case, a mid-range 2006 Chrysler 300C with the basic 5.7 litre Hemi engine. Some personal history Back when these sort of things mattered in Australia, we were a Chrysler family. My parents had a string of Chryslers before the Australian company was purchased by Mitsubishi: An AP5 station wagon (push-button automatic, slant six engine), a Ch

Move your AWS Lambda functions inside your VPC

Image
Yeah, so I'm not great at reading documentation I don't think anybody really enjoys reading documentation, most of just want to to "git 'er dun". In that spirit, skipping over paragraphs of florid tech writing and jumping straight to the code snippets is usually enough. Not in this case though TL;DR; Lambdas moved to your VPC must be in a private subnet (i.e. no internet gateway) Lambdas must use a NAT gateway to have internet access Your NAT gateway must be attached to a public subnet i.e. one that has a an internet gateway, not your private subnet where the Lambdas will live Your private subnet must have a default route to the NAT gateway in the public subnet NAT gateways cost money, $40+ / month at the time of writing. Don't forget to fix your security groups and use endpoints if you can for AWS services The overly florid explanation I have been trying for some time to completely nail down public access to my AWS resources but on

Tailscale ate my network (and I love it)

Image
No matter where you go, there you are If you're like me, you travel occasionally. Access to your office from home, or from an airport lounge, or from a hotel room is paramount to being productive for most of us now. While I had a fairly simple Tailscale setup that got me into my test machines in the office, what I really wanted was to integrate my AWS production VPC into that system. It's surprisingly simple. Tailscale AWS instructions What do you want to do that for? In the "before tailscale" times, if I needed to test against the production AWS resources or connect dBeaver for database maintenance, I would edit the security group to add my IP address, do my testing, edit the security group to remove myself. This is as error prone as it sounds. I quite often forgot to remove my IP address from the allowed addresses, a major potential security risk when you are travelling. Tailscale has an extremely nifty way to get around it: if you run up a small ec2 ins

Pop!Os and Linux Mint Debian Edition vs Nvidia

Image
I have, on and off, tried getting an acceptable Linux distribution on this laptop (Acer Nitro 5, 8th gen i7 and an Nvidia GT1060). While Debian Buster installs and works, I have been tearing my hair out trying to get a 2nd monitor working. I figured a more "user friendly" distro was worth trying to see what would happen. I put it off until today, when Microsoft Word decided to give me some ridiculous "LinkedIn" resume helper while I was updating my resume. I don't recall asking for the LinkedIn resume assistant to be loaded (I gather it's been a thing for a few years) but it set me off. I really don't care for LinkedIn, it's a stupid fantasy world of happiness, people "living their best lives" and has lately descended into Minion memes and flat out garbage The Endless September will never go away apparently. Rant over, onto distro hopping... Laptop setup Once Windows 11 gets ahold of your machine, it gets increasingly hard to do th

We love Linux...kinda

Image
Microsoft and Nvidia, stuffing it up for everybody I was quite excited when Microsoft decided to support graphical Linux programs on Windows Subsystem for Linux 2, I figured that my laptop was about ready to either be a dual-boot Debian/Windows 10 machine or I was about to ditch Windows altogether. Windows 11 proved somewhat of a reprieve when WSLg was announced, so I duly signed up for the early access Windows program and got WSLg after a short wait. It wasn't worth it. You have been able to display X based Unix programs on Windows for a long time. An excellent product called MobaXterm was something I have been using for a few years, having a headless Linux machine laying around for most of the time. MobaXterm filled the gap in Windows, which was really missing a good SSH client and an easy to manage X server, both of which MobaXterm cover extremely well (even the free version). You might object and yell "Putty" at me, but I always found Putty to be terrible to d

Tailscale vs SSH tunnels

Image
When I first set up the shed network, I was looking forward to having a fixed IP address so that I would at least have the option of not putting everything on AWS. Being able to self-host testing environments isn't critical, but it is a lot more convenient for a small operation like SmartShepherd. I did a post on it a while back but things got wildly out of hand after that. How wildly out of hand? Look at my awesome server rack: Yeah OK, start ragging on me about my selection of patch cables. The awesome Cisco 3560X switch might only be 1Gb, but it supports switchable Power Over Ethernet and cost me a grand total of $160. Beulah, the HP Proliant server underneath is the guts of the test operation. In the background is the Ubiquiti router and a UPS. Security About 40 seconds after setting up the Ubiquiti router on the National Broadband Network (NBN) fibre connection and opening up port 22 to be forwarded to my lab server, it started getting hammered with SSH login attem