[illumos-gate] 15878 Do not attempt to update CPU microcode on virtual hardware -- Andy Fiddaman <illumos⊙fn>

As far as ilb is concerned, I see it as included rather than integrated

In 2023, it's not even much of a load balancer, compared to the richness in haproxy or nginx

Which is a shame, because I see a space for something that is fully integrated with zones (as targets), SMF, and the firewall

no maintenance means outdated software, as simple as that.

so, it is one line of patch (code.illumos.org/c/illumos-gate/+/2934). I have spent few hours reading up about ilb (fortunately there is docs.oracle.com, because we have no documentation about it), then setting up test instance, then configuring auditing (because patch code path is about creating audit event), I still cant get the related audit record out of it, meaning I have missed something.

→ CODE REVIEW 2934: 15755 ilbd: the comparison will always evaluate as 'false' (NEW) | illumos.org/issues/15755

It's not merely unmaintained, it was never really finished

so it should be removed, not fixed.

I would agree with taht, yes

Also, please note if you're feeling the testing burden is too high, please reach out to talk to us and we can try to figure out things that help make it easier or related based on the specifics of the case.

But writing up an ipd to remove ilb, understanding its usage beyond just folks in this channel, and we probably can. There are probably interesting ideas in there, but as it was unfinished, it may not be worth it in its current form.

last meaningful change for ilbd was 808b84d02d9e58543ac8cde2701dec91a8c237f0 - rest are like fixing NULL pointer related bits and makefile and gender language. But it means there may still be some users:D

It's important to remember there are things we use without significant changes that folks are actually using regularly.

Not saying ilb will be one of them, but just helpful to remember that.

I guess there are different levels for being unfinished - missing documentation is one of such levels.

hm, audit session id = 0 probably explains why I can not get audit records from it.

It is, especially because of how the manual page gap happened.

I would not bet on a lot of usage of ilb though.

I suppose I should write some manual pages for NWAM seeing as how I have mostly figured out how to use it lol

I'd love to see the physical:default and physical:nwam mess gone;)

jclulow: is this an endorsement of NWAM or merely a "my hand was forced and now I must know these tings"

rzezeski: It is actually pretty good at certain things.

cool, good to know

In particular, at Oxide we have a lot of illumos desktop systems that we place near equipment to manage it (via USB, serial, ethernet) and some of those desktops get sent out onto foreign networks

And in cases where I cannot predict what the network is, and where it might change over time or people might unplug and replug things, NWAM does a pretty good job at responding to the changes

yea that sounds like the use-case it was intended for

physical:default is simple and robust for static configurations, but it's not great for dynamic ones. It supports DHCP for example but it doesn't really deal with shit changing, and sometimes it can get stuck if things didn't happen at the right point in boot

e.g., I don't expect it to update resolv.conf correctly later

But NWAM will, because it's heavier handed in its approach haha

well, ipadm create-addr could be smart enough to live with nwam for example.

It's possible. It would make it more complicated though, so I'm not sure we'd ever require NWAM on all systems

I think it'd be good to have a somewhat more ergonomic mechanism to switch between them and see which kind is active

Coming from the perspective of SmartOS, I'd prefer not to require NWAM on all systems.

NWAM is the network profile thing right?

sjorge: Yes.

trolled by MAXNAMLEN vs MAXNAMELEN today

alanc: what does Solaris have for MAXNAMLEN?