An old Minecraft Overviewer (RIP) installation of mine had an issue trying to render a non overworld (nether/end) as of late, all of the tiles would be made and the process would complete without error. Yet, when you go to view the world in the browser you are met with an uninitialized screen (grey not black) and none of the javascript (leaflet) starting...

You would get this in the browser console (for the leaflet.js script),
Uncaught Error: Invalid LatLng object: (NaN, NaN)

So, knowing zilch about leaflet, apart that it was a replacement for google maps API when it became closed, I starting taking stabs.
Perhaps the initializing coordinate that the overviewer rendering process feeds leaflet was missing or incorrect (NaN)!
This felt like a time sink, nevertheless I pushed forward and eventually located a file, "overviewerConfig.js" which held a bunch of map-like structures which I surmised loaded the initial state of the map(s) into the leaflet engine.

What caught my eye under the "tilesets" section was an entity labelled "spawn", wich was set to "spawn":"false".
Upon comparing it to a "working" output of overviewer I realized that it should be set to the spawn coordinates, and roughly corresponds to where the overviewer starts out when you first open the map. So it was totally reasonable that mine was now failing for the nether/end maps, as theres no 'spawn' for either of them.

Simply Setting it to : "spawn" : [0,0,0] solved it.

Was looking for the most basic way to change a file's hardlink (ie swap an inode) and found this. Spruced it up a little. Still looking for a simpler solution.

After connecting a VPN client, if you need to add routes for various reasons (ie. to route all upstream traffic), there are a couple of minimal routes which must be added to get it working. This can be useful if you're setting up your own tunnel to a VPN server you manage, which of course must have IP forwarding enabled, or are subscribed to one of the many ubiquitous services around and the routes are not getting automatically pushed for whatever reasons.

These have been tested to work on windows. The unix version of 'route' most likely will be identical.

Whats useful about these three rules is that they get all upstream traffic flowing to the tunnel address (on the vpn server), ignoring "METRIC". This is important as it can be and usually is configured arbitrarily for each system. Therefore a more, 'guaranteed' approach is necessary. Since route matching always sticks to the most specific rule, ie. a catchall rule for 0.0.0.0 is lower bound than one to an arbitrarily-specific address (1.2.3.4), the easiest way to override the 'usual' default catchall rule is to break the ip space in half and push both halves to the new VPN default gateway. Each half (with MASK 128.0.0.0) is more specific than the catchall (with MASK 0.0.0.0).

Adjusting routes manually this way is also ideal in that if a VPN 'disconnects', the routes to the original gateway aren't automatically reinstated, and as such traffic should halt until manual intervention...

For a while now I've really loved my Dell XPS 9305. It was the first machine that really worked with Linux out of the box, for me. Nothing was disfunctional. Not a single device. It ushered in my "Year Of The Linux Desktop" (2021), and I found it so nice to work with I bought it from my former employer when they went under. Everthing was great, well except for theese pesky forced reboots (crashes), which happened to occur always when I was away from the machine so as to limit my ability to gain any hands-on insight into the true cause. At least they were infrequent, every few months. Still it was very unsettling, as without any warning whatsoever the machine would die. The system log (journalctl) was completely blank as well, as if the machine's power vanished, though it was on battery.

I ignored it, however I was lucky it would only rear up once or twice a year, and having come from a long history of trying to use Desktop Linux I was more than willing to take an occasional hiccup, even one of this severity, if it meant computing freedom finally.

I notice something odd during boot though, a slurry of ACPI errors which upon surface investigation sounded (from prominent discussions) as if it was due to lacking ACPI support of some kind in Ubuntu itself. Due to this assumption and having zero time to push further I lived with it.
But again it would result in stuff like this:

One day, and on a whim, I decided to follow this up. Instead of searching for ACPI+Ubuntu errors, I went with the most obvious route, rather, "forced reboots on Dell XPS". The page exploded. Everyone and thier mother was suffering, Windows included, from the most trivial reboot/crashes which haven't been a problem since the earth was cooling 25+ years ago. After sifting through pages, over years and years of discussion, the result was that, for the most part, Dell couldn't write firmware any more. What was once a common and accepted academic assumption, that your system won't crash due to anything hardware/firmware related, suddenly didn't hold. Secondly, the expectation that the vendor (DELL) actually cared to address the issue which was affecting ALL downstream OSes was also not the case. Many had tried BIOS updates which, allegedly, were claimed to address the issue, one wich from what I learned was related to the board's ACPI and Wireless card's integration, or rather lack thereof. The Wifi chip would occasionally request to going into powersave mode, and the ACPI would say in layman's, "I have no idea what you're talking about, lets force-reboot!" after which the charger (if present) is no longer able to be detected until a cold boot! None of the updates, from DELL had any affect, from what others were saying, and I even tried to disable powersave on my wifi, which unfortunatley has not stopped it.

I'm sure it somehow could be worse, but the fact that it is 2025+ and the laptop has, for all intents and purposes, the functinal reliability of a system with Win98, is flabbergasting. Whats old is now new again. Ultimately Dell does not care and refuses to asses such a critical usability flaw in an otherwise very usable, non-obsolete, system.

https://www.dell.com/community/en/conversations/xps/xps-15-9500-plugged-in-but-will-not-recognize-it-is-charging/647f9496f4ccf8a8de6e4213

https://www.dell.com/community/en/conversations/xps/xps-15-9500-random-restart-no-charge/664396cf3a00f45897890270?page=5

Farewell soon my friend.

In case you encounter the strange need to access a current system's opessh from a very old client.

sshd_config

So, I just discovered that my 5400 rpm harddrive, a WD80EFAX is really a 7200 rmp drive, and more than that, all 3.5" drives above 6TB are, in fact 7200, all an entire 3 mfgs withstanding! Due to changing market factors, the only large drives manufactures can afford to create are the faster, hotter and louder, 7200 variants. It seems as though the only reason we were in fact able to purchase the quieter, cooler, and longer lasting ones in the past were due to economies of scale, that and the fact that everyone and their mother were purchasing them. Now that margins have collapsed with ssds around, they can only afford to make one type.

I wouldn't have been so dissapointed if it were only this, oh no rather, the blatant lying about this change in SMART (diagnostics deliberately shows incorrect rpm data), and the complete ommission and obfuscation in advertisments borders on racketeering. WD, of course has led the way, most prominently by its use of labelling "5400 rpm class" drives, while still packing a 7200 in the box. It took some intrepid and commendable researchers (arstechnica) acoustically microphoning said drives to prove they, indeed, spun at the un-advertised speed of 7200 rpm.

I myself, actually did realize something was amiss four years ago after I noticed a newly purchased drive was hot to the touch, when compared to others plugged in right next to it. In the same aparatus. After reviewing its SMART recently I discoverd it was a whole 12 degress celsius hotter than a comparable, true 5400 drive. Lovely. 49 vs 37C

More evidence of the downward spiral tech is plowing through. Be wary going forward, theres much margin for future prevarications and ommissions about anything and everything you intend to lay down money for.

regreSSHion

CVE-2024-6387

Heres the skinny on this summer-dog-days fun RCE.

OpenSSH Version History

• [START - 4.4p1)     VULNERABLE
• [4.4p1 - 8.5p1)     FIXED   patched in CVE-2006-5051 and CVE-2008-4109
• [8.5p1 - 9.8p1)     VULNERABLE  (again)

However,
This is basically a nothingburger.
The bug was re-introduced in ~2022-ish in Openssh version 8.5p1. It has a POC against 32bit systems, running this daemon.
Meanwhile 64 bit systems are unaffected due to layout space randomization, yadda....

--> In the year of our lord 2024 very few systems, if any, are on 32 bit x86 with Openssh. <--

I just checked my fleet as well. The only likely 32-bit candidates are ARM/MIPS for routers, and guess what they run, dropbear.

I mean, check yours, but mine were OpenWRT and DietPI, both using dropbear.

Armbian does use OpenSSH though the variants i have are all 64, not saying its pure, but rather anecdotal.

Realistically,
Raspbian is the only common SOC distro which, if it was deployed with 32 bit could be problematic.
Again, you'd have to have deployed it in the last year or two AND not have the 64 bit version.
Its thankfully not a situation I found myself in but from what I read, the 32 is still a widely used variant, if not THE variant.
The above is the most common candidate for a vulnerable device.

In x64 land, typical systems just dont fall into the 32bit category at this stage in the game, those systems are outliers.
However, definitely update your herd, even if you are completely 64bit, but there is a case to not kneejerk since there is a huge, non-vulnerable version gap (4.4-8.5) which is quite fine to leave in service(Terrapin Attack CVE-2023-48795 not withstanding), and while the last few years have been vulnerable, if you haven't deployed many Raspberry-PI like systems in that window you're also not most likely at risk.

# query your daemon
$ nc -v -v <host> <sshport>

# what system your're running
$ uname -m

Alas, for some time now I was looking for a sign. A harbringer of things to come. Something, at least tangentially related to the sad phenomenon I am witness to recently of the growing indignation surrounding C-suite management and engineering. I totally understand it. There are things that get under people's skin. The first being that we all want returns on our investments, or rather talents. It is this last bit which is causing inter-class grief in the twenty-first century. For years, tech has led, engineering and developers no less. With management a short armslength behind, dare I say even in the most conservative of companies. Things were new, and management was obviously in the dark, admitting it nontheless. Ossification has had its course though, especially as of late, and the overconfidence of a new generation has, I think, led them into a new era of blind hubris. Although they are aiming for survival, the reality is that unnecessary complexity and homogenization has surged in the latest years, by leaps and bounds as a result. Now more than ever, wisdom is necessary, and the necessity of cooperation between technical experts and big-picture thinkers is needed. Without it more events like yesterday will occur.

The main issues with yesterday's occurrence are two fold. The first being that Microsoft, and CrowdStrike, are both technically held to blame. Microsoft is, for having a facility in its OS, be it kernel-mode drivers inserts or whatever the case which allowed a terminal condition during os bootstrapping. This is a tough call though, since if you let 'helpers' swing the hammer during the construction of your house, you can't, rightly be surprised if SOMETHING comes out crooked, or worst still, if it collapses. This is the unwritten agreement problem between MS and its kernel developers. Its been this way since forever, and I understand it affects any 2-party situation when tech+policy come together. What I'm very dissapointed with is how a company who can find the time to endlessly refresh the Windows desktop and peer into our telemetry like never before with AI and other time consuming projects, can NOT at the very least have some sort of auto driver rollback feature if it detects a new driver has crashed the system repeatedly on boot up. Again, there just must've not been enough time in the day for that project. I would've gladly taken it up.

Crowdstrike, on the other side is, without a doubt the main shoulderer of any blame here. They. Obviously. Didn't. Test. It. Theres not much more to say. On the ethicality of thier systems, which are arguably spyware, one can't really hold them to task as they are simply filling a market 'need'. Whether the need be ethical, which it is not, is irrelevant. There is, in fact, an entire ecosystem surrounding systems such as theese which I've had to personally 'deal' with while working for several companies in the past. They are, without a doubt, almost always a scourge and don't serve the empolyee in any way or form. However they are a 'requirement' by our last group, management, who through thier ignorance and hubris have ever-growingly allowed the scope of theese systems to creep into every facet of modern machinery.

Most strikingly this last part, which stands out from the technical failings of the first two culprits, is actually a failure of those in power to see the shortcommings of that which they dictate, most specifically because they inherently lack the ability to understand the failure modes. Windows, should not be running on forklifts, fullstop. I don't care what your ideas are. The opening-up of huge classes of unrelated medical machinery, heavy equipment, airport kiosks, and the like to the desktop operating systems of today, especially be it WINDOWS is unnaceptable, even if it be Windows Embedded. They should not be on such a system requiring irrecoverable update cycles of this frequency. Bewilderment was the takeaway from alot of engineering-minded people as well when they learned of this crucial facet. I can recall in the Deepwater Horizon film, seeing WinXP on the drilling machines. Reality is very much this, sadly, and more. It seems without competent engineers who have the authority to object, familiar systems are seen as 'acceptable' when used to control things many orders of magnatude simpler. The negatives, like an expanded attack surface, and tie-ins to corporate spyware agent platforms aren't even considered. There needs to be a third option. An extensible, purpose built, reskinnable, and dare I say minimalist OS for machine control, which ISN'T directly internet connected and beholden to constant keystone updates which could and do bring down the entire fleet. Remember, diversity is our strength right? But this of course requires more muscle and authority from engineering, and certainly more competent boots on the ground. The last of which is not going to happen in our current ecosystem and corporate mindset where one-size-fits-all-control-and-monitor-everything is the mantra. Theese software platforms are choosen by people who have little-to-zero actual understanding of what hazards they impart on systems and are only fed what compliance checkboxes they can now tick once they sign up thier organization. Yet another security theatre of a different kind.

For my future predictions, expect more of the same, in addition to the slow circling of the drain that technology has become even when it IS working. Where nuance would flourish, expect commoditization, homogenization, and aggregation to dominate like the gorilla they are. Responsibility, oh thats in there too, or at least to remind us of what we don't get, any responsibility to strive for more appropriate solutions. None at all.

Keywords: Apache2, Upload Limit, Request Limit, 1 GB, Lua, idealism.

I have been using apache since forever. So I tend to take things the wrong way when it gets mucked-with.

So, on a recent ugrade bender while changing some decade-old systems from the 3. kernel to something recent, and leaving ubunster to come back to debian all over again, I realized something odd.
There was definatley something blocking me from POSTing more than 1024MB files or even multiple smaller ones adding up to over that limit! This was to controlled code, code which I had worked out all kinks time and time again, and I knew exactly what needed to be adjusted in php.ini. No this was elsewhere, it wasn't even getting to php, and was in some browsers manifesting as a "413 request entity too large".

The usual gamut of sites and know-it-alls proved pretty much useless. Stuck in the past they were, perpetually hashing out the memory_limit and post_max_size existentialisms. Quickly I started the process of elimination, taking into account working systems with almost-as-new setups. It must, I deduced, be something 'Changed' in the last year or two and definately apache based. A flashback quickly befel me. Ahh right! Just like when PHP 8 decided (itself) to implicitly set the default timezone to UTC (and not use the system time)! It was a subtle but not TOO difficult change to notice. This one must be similarly situated. A long-standing apache2.conf setting that's never needed to be used has now had its default setting altered to 1 GiB, implicitly. But why?

🎡🌴🗿 CVE-2022-29404 🗿🌴🎡

So IF you're using LUA on the backend via Apache mod_lua and a malicious script...I'll let the official explanation stand:
In Apache HTTP Server 2.4.53 and earlier, a malicious request to a lua script that calls r:parsebody(0) may cause a denial of service due to no default limit on possible input size.

So to recap, to fix the issue, which can of course be mitigated by not using mod_lua as stated elsewhere or possibly implementing a script check manually which would parse potential user-generated scripts to look for the rparsebody(0) or perhaps rewriting the implemntation of rparsebody() to not accept unbounded inputs, instead ALL installations of the webserver WHETHER OR NOT THEY ARE USING LUA, must now have a decades-old convention changed (WITH NARY A NOTICE IN SUPPLIED apache2.conf FILES!) to a value which induces behavior which is VERY timeconsuming to track down given the multitude of competing settings in php or other backend solutions which mimmic the same situation, while at the same time affording the admin ZERO error log notices in a vanilla log installation that the situation is occurring. Oh, the fix could also have just been an alternative "LimitRequestBody" directive in mod_lua's conf which it could have been required to use. The possibilities are endless. What shouldn't have happened though is what did happen.

The REAL issue is how this fix is somehow considered an ideal resolution to the initial CVE at hand. Fixes should always address the problem as close to the original cause as possible. Something in a mod_lua config would have been much more appropriate to those of us luddites who don't use the module.

The industry is changing. Right now, before our very eyes, interesting things are taking hold. No one can truly say where things may end up, and not eveything will be for the better. At least for the moment though, before the storm, it gives us pause to look around and remember the amazing things which have come to pass and have died, are dying, and have helped us get to where we are now.

In loving memory of the free ESXi vSphere Hypervisor

...and for that matter VMWare...

https://news.ycombinator.com/item?id=39359534