← Back to context

Comment by 9x39

5 days ago

Given it's only 20 pcs, I might have just opted for fully local machines with a basic disk overlay software with exceptions for where Steam and Epic live. Course, engineering a centralized solution can be fun, but locked-down PCs are just simple. Having built corporate RDP and VDI solutions I'm just biased towards keeping things simple these days and pushing admin work off myself.

Going off the local PC only idea, you could script just your rebuilds of them in the off chance something goes south, along with maybe a disk image with the majority of common games loaded. This is just thinking along the lines it's friends and family, not the general public. I'd probably use gigabit Internet (or more) which makes updates you're missing fast, while Steam lets PCs on a LAN share updated files and save bandwidth.

Did you consider patch panels or things like PatchBox to organize those UTP cables or allow for changes in your switching later?

Hmm, that sounds like a lot more maintenance work to me.

The way I have it set up, I am essentially maintaining only one PC, in a totally normal way. I update Windows by pulling up Windows Update in the control panel, etc. Since I only have to do it for one machine this is fine -- orchestrating updating 20 machines sounds like a pain. Yeah I know there are enterprise tools for this but why bother?

Once I've updated that one machine I just run one command on the server and now all the machines have cloned it. At the end of the party I run one command and all the machines are reverted.

Also I can give everyone full admin access to their machine (which you sometimes need for games) and not have to worry about it, because I know it'll all be completely reverted later.

  • Ah, I think I see where I failed to explain what I meant.

    You could skip the orchestration and remote storage layers altogether and cut your commands you run down to ~0 with local nvme SSDs. What orchestration do PCs running Steam and Epic need? Machines can just auto-update, unless you really like reinventing that or only have a few megabits of bandwidth.

    Again, it's not that the netboot setup isn't cool to see built, I was just thinking out loud how to simplify it even further.

    • I guess you're suggesting I leave the machines on and hope they all update themselves in the background.

      I don't think that would really work. Not all the changes I make to machines before a party are things that they'd do automatically if just left to sit. E.g. I usually install some new games some people suggested, or download the latest nvidia driver directly from the web site (where they are available before Windows Update gets them), or remove games we aren't playing anymore to free up space (or because they are constantly downloading enormous updates wasting banwidth), etc.

      Also, I don't actually leave the machines running outside of parties, and updates don't just all happen immediately when you turn the machine on... I'd have to start them up a few days in advance.

  • I meant your thing works great so good for you !

    But to me it sounds harder to maintain than just wake on lan + pxe to reimage the machines before every lan party.

    I think it's specifically the fact that they access their disk remotely live that's bothering me.

    Why not just image it to the ssd and call it a day ?

    • Why not do it live? It works!

      Well, OK, admittedly in the latest build, I have some stability issues right after boot. But in the worst case the machine reboots once or twice, and then it works. If it doesn't BSOD in the first five minutes then it's good, and everything works every bit as well as if the storage were local.

      Whereas reimaging all the machines would actually take more time than waiting for this stability issue to work itself out. And would also require that I install storage in all the machines big enough to hold the main image (currently, they don't have this).

      Overall I find it more convenient this way.

      Note that the stability issue is specific to my hardware/drivers -- I didn't have any such problem in the Palo Alto house.