New System, Credentials, Contabo, Windows, Shell Hash Cache
A new system build, security is paramount on every level. Applications are in containers or isolated with limited file system access. All storage media is encrypted. Btrfs file system is used everywhere. Backups are off-site and off-line and encrypted. And so on, quite an operation. But when my old system did die. I took the change to build a new high performance secure work station.
Tickets, credentials, handing and security - I find it horrible, that some organizations seem to use their ticketing / email systems for all credential management. Ticketing systems often aren't really secure and as we know. Needless to say, the email is total security nightmare. When we combine these with all administrative credentials, we probably have some kind of security issue on our hands. Of course it might not realize, but if someone fully utilizes all the credentials then the situation is quite bad.
Contabo experience is resumed - Still way more than one week spent, trying to get Windows 2025 server deployed, it boots to QEMU boot selection, currently it seems that there's no media attached nor any boot source (PXE) for the Proxmox QEMU virtual environment. And as usual, their helpdesk pretty much useless. They seem to prefer canned and unintelligent responses (what a surprise). Maybe even bot, with fake name(s).
Windows Server 2025 (@ Contabo) - I also deployed another Windows Server 2025 and it doesn't have working IPv6. Yet I don't know why. I tried everything I could figure out based on my experience and also several different AIs. It's good that it's test setup and environment, so I can basically share all configuration data with AI without worries of leaking anything that matters. Let's see if they're able to help with that. And obvious things first, yes, IP is correct, yes gateway is configured as instructed. No it's not about DNS. I've tried automatic RouterDiscovery / Accept RA and disabling it, as well as manually configuring default gateway. But nope, it just doesn't work. Interestingly I've go in the same data center Windows 2022 servers which do work ok. So either Windows 2025 is broken or there's something strange and wonky with their image or I've seriously misconfigured something? Really hard to tell what it actually is. And for sure, it's NOT about the IPv6 being disabled. I can ping the default gateway, routing just doesn't work from that point on. I've also tried /112 and /64 networks. - UX for this whole process is absolute and total disaster. - Now I received message that there's some issue with the boot, and they'll recommend complete system re-installation. - Sure, why not. But how about figuring out the root cause, instead of taking series of random actions which haven't provided any value in past? - Unfortunately that's quite common with so called "helldesks". It's case where bunch of clueless people are doing some random actions, without knowing what the others are doing and not understanding anything about the overall complete situation unfolding. - Yeah, some use more fancy terms to describe the same show - kw: Organizational Misalignment - When different parts of an organization act without coordination, Operational Fragmentation - Disconnected or uncoordinated actions across teams, Siloed Decision Making - Decisions made in isolation without considering other departments, Organizational Incoherence - Lack of unified direction or strategy. - Yup, nothing personal. It's just how their corporate operations seem to work. Unfortunately that's not even rare.
Bash hash cache fail - Want to laugh? Learning by failing. Now this feels really silly. I updated 7-zip to a secure version on one server and wanted to check that it was fixed, so... Old version was 16.02, I installed new version 24.09. But when I run it, I'll still get the 16.02. To troubleshoot that, I run which command.. And it of course shows correct path for the newer version. I dug around and found that there's an old version in the /usr/bin directory. But why is the which command lying? It was showing me path /usr/local/bin. Maybe I'll log in and out once, must be some mystery cache somewhere.... Yeah, that seems to have fixed the issue... So my guess was probably correct. Well, at least this came up as an entertaining thing, and in some situations this could surprise you much worse. After some time I decided to dig deeper. The root reason is optimization aka shell command hashing path cache. Which (the cache!) still contained the old mapping. Which (the command) didn't use it, but the shell executing the program did. You can see the cache contents by running command hash as well as delete entries from it, if necessary. Another great example why you should know the systems you're using very well.
2025-07-06