yeah.. with enough options, i finally got it to work -- was trying to skip a directory but add another filter

iximeow: there are several github repos that have parts of the website, including github.com/illumos/docs.git and github.com/illumos/dev-guide.git

sommerfeld: right, i mean specifically the source for the page at `illumos.org` - i couldn't find one that had the words on the homepage

the "What is illumos?" paragraph also shows up in docs.git/docs/index.md but it looks to me more like it has heritage in the illumos.org page, rather than a hint as to how illumos.org/index.html gets assembled

I believe there is a separate repo that may be private.

I think that's accurate

well, in lieu of being able to post a change somewhere, i'll idly say, it would be nice if illumos.org linked to gerrit primarily and github as a mirror :P

iximeow: ask and ye shall receive

richlowe - the unreferenced files in bhyve are at least intentional, but we should probably just go through and remove them now.

Once illumos 16890 (fenix) is integrated, I am going to look at changing bhyve so we build it with XPG6 which will change the balance of diffs from freebsd - at least we can stop with all of the uint8_t/caddr_t confusion in places. I can take that opportunity to remove the unused files too.

FEATURE 16890: bhyve upstream sync 2024 November (In Progress)

↳ illumos.org/issues/16890 | code.illumos.org/c/illumos-gate/+/3809

there are still few with loader too.

So I have an OmniOS NAS (10.0.0.10), which runs Tailscale in a sparse zone with exclusive IP (10.0.0.20 ) plus TUN enabled ( Tailscale IP: 100.103.207.28 ). I have set up this Taislcale node as a subnet router, which advertises 10.0.0.0/24 and also set up exit node with the necessary settings according to the guide lightsandshapes.com/posts/tailscale-on-omnios

It was working fine, I was able to ping/ssh the NAS using its LAN address (10.0.0.10) from aboard. However since last week I am unable toping the NAS remotely using its LAN IP, but I can still ssh into it using the same IP. There is no active firewall rule as far as I know, which could block ICMP echo.

[illumos-gate] 15854 Typos in section 9f of the manual -- Peter Tribble <peter.tribble⊙gc>

szilard: in that blog post, Mike configures ipnat and turns on ipfilter. Please enable ipfilter and confirm your ipnat configuration.

if you don't NAT the packets, then you have to set up routing on the relevant subnet and add ACLs to allow the return traffic back onto the tailnet. It is very unlikely that is how you had it set up. Make sure that NAT is properly configured and try again.

So I have an OmniOS NAS (LAN IP: 10.0.0.10) running Tailscale in a sparse zone (LAN IP: 10.0.0.20, Tailscale IP using tun: 100.103.207.28). I have set it up as a subnet router, and it advertises 10.0.0.0/24 on the Tailscale network. I have also set up it as an exit-node with the necessary config according to the guide here: lightsandshapes.com/posts/tailscale-on-omnios

I frequently connect to the NAS from remotely using its LAN IP, which worked fine so far, however sicne last week it doesn't answer to pinging its LAN IP over Tailscale.

But I am still able to ssh into it using its LAN IP over Tailscale

See the output here: pastebin.com/raw/Z2W7WYkE

As you can see on this client can communicate with 10.0.0/24 through tun0 trough the gateway 100.81.49.59.

There is no ACL configured in Tailscale. Also there is no active firewall rule on the NAS.

But for some reason all packets gets lost. I have no idea whats wrong.

szilard: what did you change since last week? I have tried to state repeatedly that what is wrong ios that you have NAT turned off in the sparse zone.

s/ios/is/

if you reread the blog post you have now linked twice, you will see that for the exit node, NAT is turned on. That is similarly needed for a subnet router.

lets consider the tailscale zone. It's LAN IP is 10.0.0.20, while it's Tailscale IP is 100.103.207.28 : I can't ping the LAN IP, but I can ping its Tailscale IP: pastebin.com/raw/SDnMbujh

szilard: I will not consider anything until you first try my well documented suggestion.

If I would have NAT disabled in the sparse zone, I wouldn't be able to ssh into the NAS, as far as I know, but correct me if i am wrong.

TRY IT. See if it works. I don't mind us discovering that I am wrong. You can always turn it back off again.

Wait.

OK, lemme try.

I may have gotten impatient too quickly.

What else has changed?

But every use of subnet router and exit node I have done has used NAT.

I have enabled both services, ping still not working: pastebin.com/raw/Cg8pSJJr

I have disabled IPV6 on the router to which the NAS is attached.

Among other things. I am unsure.

I mean, I did many changes last week, no idea what broke it.

I don1t use IPv6 on my LAN, and it was not working previously, so I simply disabled it, I think this should not be the reason.

szilard: what does `ipnat -l` report?

wait, I see "z_tailscale0" in ipadm but I see "tailnode0" in ipnat.conf that seems wrong.

I think you accidentally broke your nat.

what'

do you see in `dladm show-link` ?

also, shouldn't the NAT be inside the zone, not outside?

nahamu: wohooo!

what was the solution?

nahamu: you have right, I have mistakenly copy-pasted and not adjusted the vnic-name. It should be z_tailscale0 (my naming scheme is z_(service)(number) )

LEt me correct it.

I have corrected it, and disabled/enabled the referred services, but ping still not working.

the NAT configuration is for inside the zone, not in the GZ.

nahamu: You have right. I have just checked, I have the NAT configuration file in the zone aswell, with the correct content.

But where am I supposed to enable the services? In the zone or in the GZ?

enable the service inside the zone

you can and should remove that NAT rule from the GZ.

Oh, let me try that aswell

(and you can disable ipfilter in the GZ.)

I have disabled ipfilter and ipv44-forward in the GZ, enabled them in the zone.

removed also the NAT config from the GZ.

should I try to reboot the NAS?

let me try to reboot it. please do not answer till i return as my bnc runs on the machine I am rebooting right now :)

I'm back.

ping still not working.

FYI: Ping works ok on the LAN between the machines and the zones, but not over Tailscale.

[illumos-gate] 17234 clean up I32LPx silliness -- Patrick Mooney <pmooney⊙pc>

So there are 3 "machines" we care about. the GZ which is not on the tailnet at all, the tailscale zone which is a subnet router, and the client machine. what OS is the client machine?

Because for a subnet router to work, you have to allow the route in the Tailscale admin console and you have to accept the route on the client.

And of course if the client is on the same LAN as the GZ, I think the client will prefer to route over the LAN than the tailnet.

None of my clients can ping the NAS and the IP's on the LAN over Tailscale. I have tested using the following clients: Android 15, OpenBSD and Windows

nahmu: the route is created and accepted in the admin console. Without that I wouldn't be able to ssh into the GZ over Taislcale.

[illumos-gate] 17242 Manual formatting present literally -- Peter Tribble <peter.tribble⊙gc>

how do you know you are SSHing into the GZ over tailscale?

nahmu: sure, the clients on the lan probably using the direct connection.

nahmu: I am sitting at my GF using her wifi, supplied by a different ISP, while my NAS is at my flat using my own network. around 10 kms away.

and you use the GZ LAN IP to ssh to it?

I use the GZ lan ip (10.0.0.10) to dial in, yes. Tailscale is not installed in the GZ.

hmm

I am using my company provided laptop, where I don1t have admin rights, but I canrun Qemu, so I have installed openbsd in qemu, and in qemu I have Tailscale running connected to my mesh. So I can use the OpenBSD virtual machine as an SSH jump-host to dial into any machine in my LAN over the tailscale running in a zone on my NAS. I know, it is a bit convoluted.

but even this IRC client is runing on my NAS, so I am almost sure I am conneted over Tailscale :)

It just somehow disturbs me to not being able to ping, while it was working previously.

As I can ping just fine on the LAN (like router -> NAS and its zones), I think it is not an issue with my LAN.

I tought maybe I have some strange firewall rule on the router, but AFAIK the communication between the zones and the GZ doesn1t goes over my router running openwrt, but uses crossbow instead (correct me if I am wrong).

considering this, then the issue must be either with the Tailscale mesh, or with the setup of the NAS.

As there is no firewall / ACL active, it can1t be the culprit.

I can ping the hosts just fine using their TS ip. So the issue could be somewhere the tailscale zone.

have you looked with "snoop" on all the interfaces to see where the icmp packet is still visible and where it stops?

wiedi: no, I never heard about this tool, thanks for the hint.

Just for info, here is my zadm config for the taislcale zone: pastebin.com/raw/3JD3xyEc

[illumos-gate] 17235 memchr(3C) and memrchr(3C) accept const void pointer -- rilysh <nightquick⊙pm>

wiedi: I have started snoop in the zone like: "snoop icmp"

While it was running I have logged into my router and pinged the IP of the zone, it showed up just fine, so the snoop is working correctly.

However pinging the zone over tailscale generates no output at all in snoop. I have pinged it with both the LAN IP and with its Tailscale IP. No output.

I might need to recreate a similar setup to figure this out...

jclulow: hurrah! seems good :)

Look, what have I found: pastebin.com/raw/eisrDhyZ

is that not just some DNS noise?

Hmmm

Why would it ask for the dns info of that specific ip in the same moment i ping it?

From that exact ip.

I think snoop is trying to resolve hostnames for IPs.

use snoop -r

snoop on illumos accepts `-r` to suppress resolving the IP.

[illumos-gate] 17227 want dcmd to extract/replace bits -- Andy Fiddaman <illumos⊙fn>

what tsoome said.

let me see if I can reproduce this on my end...

okay, I lose pings when I use my illumos subnet router, but they work when I use my raspberry pi.

So I don't know that I ever had that working on illumos...

I'll file a bug to track this, szilard.

szilard: so this used to work for you?

nshalman/tailscale #88 to track...

nahamu : yes

It used to work before for me, i am sure.

Are you using the binaries I publish on github, or the OmniOS package?

(if you have time to figure out what version last worked that might help me narrow in on a fix)

Does anybody know what rights I need to give a zone to mount lofi devices? I am trying to ban image-builder into a zone

usual way to find that sort of thing out is by enabling privilege debugging with the ppriv command ..

how do I do that?

ppriv -D -e mount -F lofi ....

ah nice

hmm that reports nothing

I have the UFS mount though

hmm. it could be that it would be "unsafe" to grant to a zone

ppriv -D -e /usr/sbin/mount -F ufs -o nologging,noatime /dev/lofi/1 /images/work/installer/generic-ttya-ufs/a

sommerfeld: It's definitely unsafe to give file system mount rights to zones. I believe there is a per-zone list of allowed file systems

The "fs-allowed" property

as per zonecfg(8)

it depends on the filesystem, but if it touches disk don't trust it

or rather, if it touches user-provided data

jclulow: that worked thanks

would be nice if zone config would allow to use like fs-allow=ufs:onerror=umount

You would have to radically harden ufs anyway

so it'd be nice, but it's the same problem

which is "all our filesystems which touch arbitrary data do it too trustingly by far"

the fact it panics is not the problem, the fact something causes it to want to is

that too, yep.

I think at some point joyent seriously considered a hardened fat32 :)

or maybe it was only "not slow as hell"

just rewrite ufs in rust to make it safe 8-)

richlowe: I think the goal with any imagined future pcfs work was exclusively performance driven

Mind you the performance bottleneck was usually the USB stick

alanc: I had the thought yesterday "ufs has never been portable, thus ufs on aarch64 could have 64bit times and that'd be ok"

luckily I calmed down

shouldn't that be, "thus there is no reason for ufs on aarch64 to exist, since it doesn't need to be able to import old data"?

Indeed haha

I would certainly ditch it

I expect we'll ditch it on x86 as well, rather than put a bunch of effort into 64bit time stuff there

actual decisions like that have not been made

availability is on an it-was-easy-or-necessary basis

Yeah

in this case "easy"

I vote for deprecating UFS by 2035.

danmcd: or 2030 even

I haven't tested it, to my knowledge. I probably made and mounted something

Yeah, to be clear, you should do whatever you need to do in ARM town to get the next piece of the cathedral stood up

But at integration time I suspect "we will just never ship UFS here" is extremely reasonable

right, I expect numerous debates about what is shipped

as I've mentioned, anything I haven't thought worth my time isn't, for instance

mmm

Wearing my SA hat, I would like to add to the "do not ship it" vote. There are times where it is best to just move on and this is one of those opportunities we so rarely get.

jclulow: right, people coming at this from a "do less" perspective is certainly heartening right now, if surprising :)

The only way I got rid of some really, really old hardware was the transition to 64bit when they dropped backwards compat. Even then I had PIs complaining they were 'throwing away perfectly usable computers."

(They might have sung a different tune if their grants were billed for the electricity. <shrug>)

[illumos-gate] 17177 want libktest -- Patrick Mooney <pmooney⊙pc>

omitting UFS sounds great

a related debate we've been having is "if we get rid of ufs, shouldn't we keep ufsrestore, so people can restore old backups to new ZFS filesystems?"

we didn't go as far as "if we get rid of ufs in the kernel, should we keep ufsdump to let people read their old disks and migrate data to ZFS?", instead preferring to suggest they ufsdump *before* upgrading, or reboot to an old BE that still had UFS to do so

well, also ufsdump is not the only tool to read data from ufs;)

it's the one we support

ah, you mean, while the kernel driver is no more?, then sure.

alanc: Yeah, I mean, it seems reasonable to keep those programs around for longer (again, only on systems that ever had UFS to begin with)

those systems I have seen around had nothing to pick from ufs, they were running some ancient oracle on top of s10 and were waiting for some data to get either expired or migrated off before powering of....

off*