bahamat: Sense error: I mean *not* using them.

Reinhilde: You can set the vlan id to 0 for all vlans. Not recommended, but it does work.

yup. Again: there's my homelab weekend project

That's in the context of a support contract.

We're not going to support Triton running in production with a support contract without VLANs. There are too many peripheral issues with it. But it's fine for a home lab, and it doesn't even require any extra effort. You just specify the vlan_id to be 0.

Not using VLANs prevents proper tenant isolation, and doesn't properly protect the admin network from tenant networks, which is why it is not and will not ever be supported. Does it work? Sure. Does it violate specific safety tenets of Triton? Absolutely.

got it, merci bahamat

Anybody using TritonDataCenter and interested in trying out the nix package manager: I've built something that might interest you git.greenbaum.cloud/dev/tritonshell

danmcd (LIBERA-IRC): Do you have some free cycles this week to further look into the recent issue in lx brand?

lx_setsockopt_ip call returns 0x16 == 22 == EINVAL

this one

teutat3s : oh - I nix was already on my list to try out...

teutat3s : which image/distro do you use nix?

neuroserve (LIBERA-IRC): you could just install the package manager nix on your favorite Linux distro or on macOS and use it as an alternative to brew

I use NixOS currently

neuroserve (LIBERA-IRC): nixos.org/download.html

teutat3s: what's up with the "(LIBERA-IRC)" suffix in your nick mentions?

a bridge of some kind?

Yeah, I’m writing to libera IRC bridged from a Matrix Homeserver zizzy (LIBERA-IRC)

fyi, upgrading from 20220310T212952Z to 20221020T001410Z causes all of the bhyve VMs interfaces to re-enumerate

thetooth: what do you mean by re-enumerate?

MAC address changes? something else?

(I am running joyent_20221020T001410Z on one of my machines and didn't notice anything...)

we run a virtual router appliance, the router is configured eth0,eth1 and so on, basically eth1 is listed as net1 in the zone config, it's mac has not changed but it's now in position 6, which makes the rest offset by 1

i don't know what that tag in particular changed but it's moved around in every single VM that's part of that L2 network

did you try rolling back to see if it puts things back the way they were?

i did but the change was one way

as in booting into the old image and the offset is now permanent

oh

dladm shows that the affected tag is now assigned to an unplumbed interface

it's not under /usbkey/config, it's just a spare port

wait it IS up, but the tag in question should belong to an etherstub, not a physical link

hmm.

Someone decided to turn an etherstub into a phy, at some point between march and now, the port isn't even connected properly, it's plugged into VoIP ¯\_(ツ)_/¯

would that count as datacentre gore?

so the issue is unlikely to be the upgrade, right?

i think the usbkey config was changed inbetween so no not directly

strange that the order no longer matches the order it's defined though

thetooth: Triton itself doesn't use etherstubs in any capacity, so it's not something we test in SmartOS, but it makes me wonder if something similar happened on OmniOS during that period. We try to track illumos-gate pretty closely.

at a guess it seems like a concurrency thing, before we had just two interfaces admin (not connected to any of the VMs) and ixgbe0 which is connected to the router and then to everything else via etherstubs, all of these are up in a matter of microseconds, where as our DMZ with a telephone extension isn't going to be up for a while since the switch

with shit can the port as soon as it doesn't come back with a cisco mac, so it's throwing that tagged network in slightly later and putting it at the end of the list

i fixed it by using fixed hardware id's for the interface config inside the router appliance, idk what's worse, expecting the interfaces to always enum in order or expecting the macs to never change

Well the mac is not going to change because that's specified in the vm config. But I think on modern systems, you can't count on enumeration order in any case.

I'm curious to see if you boot into the older PI, create a new vm, then boot into the newer PI if it would then renumber it.

I can try that tomorrow perhaps

Right now everything is still on fire