Author Topic: AToF - 01 - Platform Build - making the HostOS lean and mean  (Read 4105 times)

JTA

  • Jr. Member
  • **
  • Posts: 61
  • Karma: +0/-0
    • View Profile
AToF - 01 - Platform Build - making the HostOS lean and mean
« on: December 05, 2023, 08:45:51 pm »
In the AToF platform build, the HostOS is either x64 Windows (10 or 11, pro or enterprise) or x64 Linux. It provides all the connectivity to platform resources (filesystems, networking, security, x64 apps) and the outside world (internet).

To use Windows, just grab your test platform (desktop or laptop, i7, 32gb ram, 512gb ssd, or equivalent), and put a copy of Windows 10 on it. Right out of the box, Windows 10 or 11 isn't really your OS any longer ... MS pre-loads the build with bloat, takes away your ability to manage updates and does it themselves, and otherwise makes it hard to run lean and mean (just an OS). You could've done the same thing with Linux, and many might go this route for the HostOS; shouldn't be that much different.

So, first order of business is to make the Windows OS ours again:

1. get a license, install windows 10 (no partitioning weirdness, just give all resources to win10), apply all the latest patches (using WAU Manager) activate it, and before anything else, run the AME (ameliorated) process on it. In the old days (yesterday), I used to do all kinds of things to strip out the bad stuff. AME does it in one pass. Get it from Github.

2. now, with AME having removed all the bloat, telemetry, and other garbage from win10, you've basically got Win10 running as a "service" ... it's there, and the dt/lt boots into it, but it doesn't do much. It also doesn't *pester* you with constant messaging as to what you could be doing, the MS way. Go ahead and layer on *your*:
  - security: some product for av/firewall, etc.)
  - x64 apps: you'll need Winflector, and additionally install any x64 app you want to serve up to the VM's
  - backups: macrium reflect (free) ... get images of the HostOS every so often
  - package mgr: chocolatey (the only helper apps I use are 7zip, gsudo, filezilla)

3. Install a Type-2 Hypervisor. I use both Virtualbox and VMware Workstation, for testing purposes, but VBox alone would be fine.

With this done, you are ready to move on to VM's, holding all the OS's you'll be needing. Again, the rule of thumb is 4gb ram per OS (hostos or vm), but that's just a starting point. Adjust up or down from there, depending on what you're building and what you're doing within the VM's.

Just for reference, here's my build:
  - platform: 2018 dell precision 7520 ($200 off of ebay); i7, 32gb ram, 512gb ssd
  - HostOS: Windows 10 - lean and mean
  - licensing:
     - "Action Pack" subscription, which gains access to any kind of OS license, for *all* my OS testing
     - "Vmug" subscription, which gains access to many things VMware, including my type-2 workstation license
     - ArcaOS licenses ... got two, probably going to need more, for my dev work
     - Winflector license ... two-seat version is free, I paid for a few more seats for testing purposes
     - ESET license ...
  - On the HostOS:
    - security: I use ESET (av, firewall, etc.)
    - x64 apps: I use Winflector, and additionally install any x64 app I'll serve up to the VM's
    - Type-2 Hypervisor: I use both Virtualbox and VMware Workstation, for testing

In the background, I do have a Synology NAS, as that's where everything lands long-term. I image the OS of any of my platforms, and 7zip gives me backups of entire VM's or any collections of files/dirs.

Hope this helps ...
« Last Edit: December 21, 2023, 05:01:03 pm by JTA »

JTA

  • Jr. Member
  • **
  • Posts: 61
  • Karma: +0/-0
    • View Profile
Re: AToF - Platform Build - making the HostOS lean and mean
« Reply #1 on: December 21, 2023, 04:53:29 pm »
Sidebar: AToF and the HostOS update process

If Windows is your primary OS, you are the proud *lessee* of a Microsoft (MS) OS. They own it (as the "lessor"), and do all kinds of things to it in the "update process". They still allow you to pay for the OS, for the privilege of belng the "lessee" (owner) of the OS. Sometimes you get what you think you're getting in the patch process, and the OS is patched for bugs or for security reasons. Many times, you get what you don't think your getting, and the base OS is "upgraded", not updated. New features come down, old things get taken away. If you've applied a customization, some of these "updates" may undo it for you. Nobody really ever knows what is coming down the pipe on "patch tuesday", when the OS is Windows.

The AToF HostOS mechanism is about ending this MS update process, and making the OS your own again. Not only is it "lean and mean", it no longer participates in "updates" the MS way. The HostOS is truly more of a service, and exists only to provide core services to the AToF machine and VM environment. However, now that the OS is your own, it also means you have to be responsible for patching it, with just those patches that you truly need (bug fixes only).

Why "bug fixes" only? We don't use the HostOS for anything on the internet, nor do we use it for anything on the HostOS "desktop". It is not our "daily driver" OS. Therefore, it isn't exposed to the security dangers of our daily driver desktop, where we are browsing the internet, or using applications that reach out into the world, and where all of these things could bring dangers back into our desktop, if not fully patched each month.

What *is* exposed to the dangers of the world is your "daily driver" VM, and that could be a Windows, Linux, ArcaOS, or any other VM where your "desktop" lives. It is our use of the desktop OS that makes the OS insecure and in danger.

This daily driver VM (DDvm) is the machine that you need to keep up to date on patches, security best practices, and anything else you can think of, to keep the dangers of the world at bay. So, the update process has moved down from the HostOS to the DDvm (running ArcaOS, or Windows, or Linux). Inside of a Windows DDvm, we still restrict the MS update process to a degree by using the WAU Manager binary, which at least turns off automatic MS updates, and allows you to review the available updates and have a degree of choice in applying those updates. But, the Windows DDvm is not AME'd (ameliorated), which removes the majority of MS controls over your OS.

What about the HostOS running Windows ... who is keeping that up to date? Well, you are. Believe it or not, it is still possible to update the OS by hand.

When the Windows HostOS is operating as a service (because it's been AME'd), it doesn't really change. It stays at whatever OS level you built it at. Forever (in computer terms). MS isn't upgrading the OS in the background, each and every month. If you ever choose to "update" the HostOS running Windows, you'd just go to the Microsoft Update website (aka the "Catalog"), find the latest bug fix or security updates, pull them down, apply them, and then re-AME the HostOS. You can't do these steps with the nifty WAU Manager, you'll have to do them by hand. But, it isn't really even *necessary* to do these, unless there is a critical bug fix or security update that has the world in a panic, *and*, you agree that you need to panic as well.

Inside your daily driver VM (DDvm), which could be running Windows, Linux, or ArcaOS, you *would* be patching the OS using the native update mechanisms, because it is this DDvm OS that is exposed to the dangers of the world, and needs all the update help you can give it. If ArcaOS, then ANPM. If Linux, then package manager. If Windows, then WAU Manager (if you want control over the updates).

If your AToF HostOS is Linux, then there is no AME process (it isn't needed for this OS type), and your standard Linux package managers do (or help you to do) all the update work.

What if we want to *upgrade* the HostOS running Windows? This, too, is possible, but will have to be another sidebar.