megaTherion: defrouter is only effective on shared-IP zones, and allowed-address is only effective on exclusive-IP zones. Pick one!

On an exclusive-IP zone, you set the route from inside the zone (route -p add so it persists across zone reboot)

sommerfeld: I see, thanks for the clarification

I think what I want to have is a kind of bridge-like configuration for an internal net

there are many ways to plumb something like that up - which one makes sense depends on addressing plans & how much control you have over the local network.

Simplest is probably vnics over your physical nic.

vnics over an isolated etherstub or simnet if you want it completely internal.

I see, well I've basically one internal net 192.168.171.0/24 and the omnios box would be 192.168.171.7 and I need some net block for a couple of zones which could be anything like 10.0.10.0/24

can sometimes be simpler to put the zones directly on the 192.168.171.0/24 net but that may not be what you want for other reasons.

sommerfeld: got it running, confused myself quite a bit on the way... but its basically easy

igc0:2: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 2 zone postgres inet 10.10.10.2 netmask ffffff00 broadcast 10.10.10.255

igc0:1: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 2 inet 10.10.10.1 netmask ffffff00 broadcast 10.10.10.255

and then just a NAT on 10.10.0.0/24 (but I was confused by ipf, Im a pf guy)

doubling back to eu-mirrors, primary was in swiss I think. Been a while since I checked.

Yep, AS559 is swiss

sommerfeld / megaTherion - the defrouter property alongside allowed-address should definitely work. I use it on all of my zones

andyf: I see, its getting a while to get into how things are handled - there are a couple of howtos on the net, but nothing really comprehensive.

as I know understand it ip-type exclusive gives you a seperate network stack for the zone, shared is the opposite and then you cant manipulate routes from within the zone as the routing table is the same as the host

someone knows how to correctly configure bridges?

whats also a bit strange is that if I add another lipkg branded zone, all packages are downloaded again - there is no caching?

see pkg property (flush-content-cache-on-success)

oh I see

tsoome_: it's true that if I want to keep data in lipkg branded zones seperate from BE changes that I need to manually create a 'data' dataset for each zone?

thats the separation usually means, yes:)

tsoome_: ok just wanted to clarify, is it basically the rule for all zones or are pkgsrc zones excluded from this?

its just like with physical host - you have space for your OS and you have space for your data. If you want to keep data separate from the os (in terms of storage device separation), then you need to add device for data.

in that sense, it really does not matter which type of zone or physical system it is.

well I try to understand how this works, basically BEs are snapshot for rpool/ROOT, but then why would rpool/zones/zone1/ROOT be affected?

ok for LX zones this is not the case, at least according to the documentation on omnios.org

"LX Zones, unlike ipkg or lipkg zones, do not have individual boot environments. If you update and create a new BE, any LX zones are not explicitly updated. "

seems that it's not a good idea to craete zone names with numbers in it, that breaks some things

megaTherion: what things are breached? All my production zones names end with a couple of numbers, and I noticed no drawback so far...

warden: I've tried to create an lx branded zone like in the example on omnios.org, if it contains a number like for exmaple 'influxdb2' I get an error tha the route cannot be added

I can try again and check

megaTherion: well, I'm not very experienced in OmniOS, but I'm pretty sure that zone's network stack is unrelated from its name! :)

probably, but I noticed that zadm always proposes zonename0 as physcial device ... maybe it was conflicting or so. But I'll check again if it happens

warden: you are right, it works - no clue what I did wrong

is there a reason that I cannot add a zoned dataset to an lx-branded zone?

I basically did it the same way as with another pkgsrc zone I have... but the dataset won't get mounted upon zone starting

for a "bridged" interface the easiest is probably a vnic, This is a stuff I fed to zonecfg for a test lipkg zone. gist.github.com/m1ari/da615a75ce803ab3b1e93567e35a2b8a

m1ari: ya figured that out, I couldnt get a bridge to run - Im using now vnics

rge0 is the physical interface, test00_0 is the interface inside the zone

I think part of the reason that pkg and lipkg zones have linked BEs is that part of the filesystem is shared between GZ and zone, so you need to keep packages in sync between the two. That doesn't apply in the same way for pkgsrc and lx zones.

I see, but I dont see the technical reason why a zoned dataset wouldn't apply to an lx zone too - or why it would be impossible to mount

for help the man pages are often quite good (as I think they are in freebsd) sometimes the challenge is finding the right one (especially if some of the commands are new to you)

yeah thats true, manpages are great

Im coming from freebsd actually, trying to get a similar setup done

mlari: the key thing is that Illumos doesn't have a stable system call ABI, so libc.so.1 has to match the kernel.

linked images ensure that the zones have certain core userspace packages that match the global zone and kernel.

how does the bloody release cycle works? Is it a different publisher/mirror for ips?

yes

megaTherion: see also: omnios.org/info/ipsrepos

thanks

FYI: omniosorg/omnios-build #3770 seems like a relatively critical defect in r151046 LTS?

I seem to have pkg⊙0:20241017T212621Z

megaTherion: Oh, that FYI was not aimed at you, just to the room in general, sorry

sure, I just thought I check what version I have :D

but isn't your verison older then?

Yes, r151046 is an older release but with a long term maintenance plan (LTS)

ah I see

You can see in: omnios.org/schedule

what would I have to enable SLAAC (IPv6 autoconfiguration) in OmniOS?

I believe you can just "ipadm create-addr -T addrconf igb0/v6" or whatever

I see, nice

yes, but additionianlly add -p options.

for persistance?

ah prop

neitzel: Which -p option are you thinking about?

I believe the default mode is stateless

well I get a link-local... thats it

for "policy". -p stateless=yes/no for RTADV on/off, -p statefull=yes/no for DHCPv6 on/off.

megaTherion: Are you expecting route advertisements or DHCP?

the former

Is your "ndp" service online

Im not using DHCPv6

jclulow: thanks, ndp was it

I specify "-p stateless=yes -p statefull=no" in that case, and yes: I like to forget activating ndp, too :-)

it works :)

neitzel: specifying more than one -p option to ipadm create-addr doesn't actually work (only one gets used)

(I noticed this recently, don't think I've filed the bug yet..)

in practice once you are aware of this limitation it doesn't prevent you from doing anything reasonable as there are only two options and they both default on and you never want to turn both of them off...

It might be useful to have something in the docs about IPv6, I was playing with it a couple of days ago and found it took a bit of random googling to find the answers

and it was a case of `ipadm create-addr` and starting the ndp service (seems like its disabled by default)

Ultimately I wonder if it's something that should also be in the installer (I only started looking after realising it was off by default - I'd assumed I'd have IPv6 by default as that's been the case in most other OSes for many years)

there are some missing pieces around nameserver autoconfiguration over v6.

if you put a v6 address in resolv.conf, it works but neither DHCPv6 nor SLAAC will put an address there.

sommerfeld: is it expected that resolv.conf will be automatically changed?

The DHCPv4 client will in some cases update the nameserver.

I don't really understand why the ndp service is disabled by default, FWIW

ok right, with DHCP it might make more sense

So that seems like probably an OS bug

jclulow: in FreeBSD IPv6 is still optional too.. you have to enable it with ifconfig

many people dont like IPv6

That's fine, but if you do "ipadm create-addr -T addrconf" it really feels like it should at least get turned on as part of that operation

like, if you've opted in to IPv6 it should work haha

true

one command should be enough :)