> Why can’t I set up Windows or MacOS like that? I know the answer I just find the answer annoying.
I wish I still cared about this. I had intended to build an iPXE boot menu via a small web service that would act as a windows install XML template editor/selector, but I never got around to doing it after learning enough web dev to pull it off.
I built a few similar things that worked inside of WinPE, but the slowness of waiting for it to boot was always what drove me to do as much config as possible in the PXE boot menu—you can get into that in seconds versus minutes for the PE.
I used to install Windows a lot, and found a lot of tech around it to be a little too opinionated. SMS/WDS were just too legacy-leaning and Microsoft Enterprise-flavored. FOG was a little too heavy-handed (though very good). Glazier excited me but I never actually used it to determine if it has the flexibility I wanted...
But I digress. OS installs should be a lot easier and faster to accept your configuration preferences and get to work when the goal is "erase this machine and reinstall" than they are even today.
Built out a (i)PXE build system for Windows at an /old job/
It would chain load the iPXE binary from the network, then call out to a HTTP end-point with "?mac={macaddress}" so we could identify it. Then it would auto-pull from git, or generate (and push into git) a config, which would load the WinPE image over the network, and launch a powershell script. All of which would talk back to the HTTP endpoint throughout.
Because we tracked it all with a Slackbot on every execution.
Fun hack, certutil.exe has the ability to do HTTP/S requests, so we would leverage that to "live off the land", even though we could integrate any binary into the image outselves.
That was the point as I read it. Payload signature verification is a good and sometimes desirable alternative to transport encryption when the payload itself isn't secret.
Highly-cacheable resources like game and OS updates are often intentionally delivered over http as signed payloads to facilitate middlebox caching.
The organic search results didn't offer what I needed at all, but the ad took me straight to an e-commerce site that sold what I wanted. I had it in my hands at a reasonable price about 5 days.
It was for a Nintendo Wii component video cable, back in 2007.
> Finally, AWS isn't a silver bullet. For anyone in us-east-1, you know [0].
I probably should have commented on the original article here, but I pulled all of my company's production infra out of that AZ back in 2019 because AWS dragged its feet for too long deploying 5th gen hardware there.
I assumed the racks were full or something. I still don't know if they ever did get newer hardware in that AZ—I just avoid it like the plague.
I had a light chuckle this week when I discovered the work I did out of sheer frustration saved us from a partial outage seven years later.
> Another alternative is Mellanox with RDMA. You need CX4+ for optimal performance over TCP/IP, while the cheap CX3 is excellent with IPoIB.
Do these benefit the iSCSI target end of the equation too, or just the initiator? And do they work like an HBA, where you configure the card in a firmware setup menu, or does it just transparently accelerate the software initiator on Windows/Linux?
It is a bit different, Mellanox with iSCSI/iSER over IB/RoCE is much less complex than iSCSI over TCP. RoCE runs over UDP, but requires switches with PFC, and ECN. Chelsio plays nice with any switch. Mellanox has much better offloading of NVMe-oF, where the network card can directly communicate with the NVMe device over pci-express so it can completely bypass system ram and host cpu. In fact, Linux will know nothing about the transfers to and from the NVMe device.
To get accelerated iSCSI, you need to install Chelsio or Mellanox drivers. While both work out of the box with the inbox drivers, they have special drivers that you have to download and install to unlock the extra performance. I think Chelsio has everything included in FreeBSD, so there the inbox drivers already come with top performance unlocked.
I thought it really excelled at displaying the timeline—it was quite novel to see a timeline for a video I was watching that didn't occlude any part of the screen—but quite annoyingly it would go black due to inactivity.
And of course the virtual function keys were awful.
I've wondered for a while if it would be possible to do that with a USB FXS adapter[1], and something like a Pi, but you'd basically need a soft modem of some kind to make it work and the only module for Asterisk isn't up to the challenge (last I checked five years ago).
However, to be frank, it'd make more sense to do PPP over null modem with a straight serial connection.
You can set your ULA to something like "fddd:192:168::/48" and then on your vlan you prefix hint, say, "66". Now, any device on that vlan will be addressable by "fddd:192:168:66::$host". For example, your gateway ('router') for that vlan would be "fddd:192:168:66::1".
If you want to be really wonky you can script DHCPv6 to statically assign ULA IPv6 leases that match the IPv4, and expire them when the IPv4 lease expires, but like said upthread, addressing hosts via IPv6 is the wrong way to go about it. On your lan, you really want to be doing ".local" / ".lan" / ".home".
> addressing hosts via IPv6 is the wrong way to go about it. On your lan, you really want to be doing ".local" / ".lan" / ".home".
.local is fine as long as all the daemons work correctly, but AFAIK there's no way to have SLAAC and put hosts in "normal" internal DNS, so .lan/.home/.internal are probably out.
> On your lan, you really want to be doing ".local" / ".lan" / ".home".
The "official" is home.arpa according to RFC 8375 [1]:
Users and devices within a home network (hereafter referred to as
"homenet") require devices and services to be identified by names
that are unique within the boundaries of the homenet [RFC7368]. The
naming mechanism needs to function without configuration from the
user. While it may be possible for a name to be delegated by an ISP,
homenets must also function in the absence of such a delegation.
This document reserves the name 'home.arpa.' to serve as the default
name for this purpose, with a scope limited to each individual
homenet.
It may be the most officially-recommended for home use, but .internal is also officially endorsed for "private-use applications" (deciding the semantics of these is left as an exercise to the reader): https://en.wikipedia.org/wiki/.internal
".home" and ".lan" along with a bunch of other historic tlds are on the reserved list and cannot be registered.
Call techy people pathologically lazy but no one is going to switch to typing ".home.arpa" or ".internal". They should have stuck with the original proposal of making ".home" official, instead of sticking ".arpa" behind it. That immediately doomed the RFC.
I do it by abusing the static slaac address. I have a set of wierd vms where they are cloned from a reference image, so no fixed config allowed. I should have probably just have used dhcp6 but I started by trying slaac and the static address were stable enough for my purposes so it stuck.
How does that work? I initially assumed you meant you just statically assigned machines to addresses, which I think would work courtesy of collision avoidance (and the massive address space), but I can't see how that would work for VMs. Are you just letting VMs pick an IP at random and then having them never change it, at which point you manually add them to DNS?
Pretty much. A given mac address assigned in the vm config maps directly to a static slaac address(the ones they recommend you not use) and those preknown slaac address are in dns, Like I said, I should probably use dhcp6 but it was a personal experiment in cloning a vm for a sandbox execution environment. and those slacc address were stable enough for that. every time it gets cloned to the same mac address it ended up with the same ip6 address. works for me, don't have to faf around with dhcp6, put it in dns. time for a drink.
But the point is that is the address you would put in dns if you also wanted to use slaac. Most of the time however you will just set a manual address. And this was with obsd, where when slaac is setup you get the slaac address and a temporary address. I don't really know what linux does. Might have to try now.
Clarification for others: with privacy extensions disabled, SLAAC'd IPv6 addresses are deterministically generated based on MAC addresses. There's also an inbetween (IPv6 are stable per network by hashing).
I wish I still cared about this. I had intended to build an iPXE boot menu via a small web service that would act as a windows install XML template editor/selector, but I never got around to doing it after learning enough web dev to pull it off.
I built a few similar things that worked inside of WinPE, but the slowness of waiting for it to boot was always what drove me to do as much config as possible in the PXE boot menu—you can get into that in seconds versus minutes for the PE.
I used to install Windows a lot, and found a lot of tech around it to be a little too opinionated. SMS/WDS were just too legacy-leaning and Microsoft Enterprise-flavored. FOG was a little too heavy-handed (though very good). Glazier excited me but I never actually used it to determine if it has the flexibility I wanted...
But I digress. OS installs should be a lot easier and faster to accept your configuration preferences and get to work when the goal is "erase this machine and reinstall" than they are even today.
reply