hey all, odd question, if I wanted nfs across multiple muti-user clients, is it possible to manage access even if UIDs mismatch? Would NIS work for that? I can't find much info online

what exactly does nis/netgroups do with nfs?

spuos: NIS is really just a place to get passwd(5) and group(5) data from a central server, like LDAP or whatever

and netgroups are just a sort of basic access control list you can use for some things like deciding which hosts are allowed to mount an NFS share

You can look at the netgroup(5) manual page for more details

None of this really helps with providing NFS service to another system that has a foreign (managed by different people, names and numbers don't line up, etc) NFS client

What _might_ help, though, is the "uidmap" and "gidmap" options; see: share_nfs(8)

Though the interface is not fantastic, you can do some remapping of the numbers on a client-by-client basis

those are a bit different things there. with netgroups one can group up hosts based on their names/ip addresses, but file access in nfs protocol level needs users and groups. NFSv4 does use user and group names there (and not uid/gid as NFSv3/NFSv2 did) - so as long as names do match in your nfs domain, you are good. *EXCEPT* if you are using auth_unix (aka auth_sys) authentication, which is using uid/gid numbers. auth_krb5 (auth_gss

with kerberos 5) does work around that issue, but has stepping stone of its own.

While NIS is very simple naming service to set up, it is rather limited in most aspects and therefore should be avoided (unless you know exactly what are you doing), ldap is better option in that sense.

tsoome: care to elaborate on the nis avoidance thing? I have a vlan made of trusted peers of various unix-y oses and it seems the most compatible

jclulow: ah, that makes a lot more sense, I saw some stuff about NIS in a few man pages relating to nfssec and auth, I guess I was a little confused there

its security is rather weak by todays standards, you can google "nis versus ldap" and you get ton of information. For small home network you dont really need this all anyhow, manual/scripted sync of passwd/shadow/group is quite enough. For learning purposes either is ok, but ldap is more practical (IMO).

this was one of the best talks i have seen in a long time

i'm just confused by the rockstar intro...

LxGHTNxNG: Its pretty common on tech conferences nowadays

Úf.

Hello! I've installed another server and I'm trying NAT66 - and I'm being hit by this here, too: illumos.org/issues/17584

→ BUG 17584: Null pointer leading to a crash when using NAT66 (New)

On this server I have full control and contains no private data (there are my blogs), so I can help with any tests or information you may need

i think the most useful thing would be is if there's a crash dump (or if not, configure them and recreate the issue) if that's possible and won't be too disruptive

@stefanobsdcafe I mentioned that on the ticket too.

dumpadm(8) is your friend, and if it's a quick-to-reproduce issue you shouldn't need TOO BIG of a `dump` device/zvol.

Sure. I'll reply to the ticket, too, but the dump can be downloaded here: 45.157.176.175/vmdump.0

stefanobsdcafe: two questions: what is your opinion of singing cowboys, and secondly, where did you get a VM that cheap?

rmustacc: one thing I've noticed (while looking at hte PCI multi-segment stuff) is that the pci_{get,put}{b,w,l} functions always use IO space (all the different implementations ultimately are just doing in[bwl]()/out[bwl]()), do you know if mmio is supported on a system if there's anything PCI related that would require accessing I/O space?

singing cowboys?

spuos: sorry, I don't understand the singing cowboys part - but I understand the second part. It's a netcup piko vps - currently sold out

I'm downloading it now.

1) you'd be the second person today I've seen talking about NAT64, and 2) aww :(

(it seems like what we'd want to do is early on, if the mcfg table is there, map the cfg space(s), and set things up to use that, and if not, fall back to the other methods (with suitable escape hatches to force behavior)

but don't know if there's something we're doing which must always touch I/O space (though if so, I'm not sure how that'd work in a system w/ multiple segments)

@stefanobsdcafe please supply here two lines:

1.) output of 'ls -l vmdump0'

2.) output of "digest -a md5 vmdump.0'

Just to make sure this through-a-straw download succeeds?

-rw-r--r-- 1 root root 95551488 nov 17 19:26 vmdump.0

The digest is: 6732c6a02aa222d41cb34d8e5d517d76

Thank you. Which distro is this again?

(Not that it MATTERS a lot, but picking which machine to inspect it on will be made easier.)

this is SmartOS - joyent_20251113T010957Z

Ahh. Thanks for using the latest. I'm going to assume this is your first use of NAT64 on any illumos or else you'd have bugged a SmartOS list. You did the right thing filing a bug in illumos. Worst case for me is that it's something SmartOS-specific.

Thank you, Dan!

What's the bandwidth on your end?

Yes, it's the first time I'm using NAT64 on illumos. I'm usually routing, but netcup doesn't allow it so I need this. I can try on omnios, too - I can create another VM (or convert this) to try, tomorrow

the bandwidth should be 1GB but being an extremely cheap VPS, I think it's some sort of best effort

I mean 1 Gbit/sec

I have in theory GigE here at home, but it's more like 900Mbit, and of course the latencies, etc. etc.

Yours is a small vmdump (<100MiB), but my curl speeds are awful.

Mmm yes, I just tried to download it - it's coming down at more or less 300 Kbit/sec or even lower. I'll try a scp now

Same performance

cleartext http, I wonder if it's going through some sort of surveillance ? :D

scp has the same performance, so probably not :)

300Kbit/sec sounds high from what I"m seeing. I'll know for sure when curl gives me the finish time.

I'm flashing back to downloading Mac binaries in .hqx from sumex-aim over 56Kbit ARPANET links.

hqx? was that stuffit?

No. BinHex ==> Mac equivalent of uuencode/uudecode.

oh

If your FTP client was doing ASCII-or-other-charset things it was safer.

I just tried a speedtest from a lx zone: ✓ Download: 361.60 Mbps (Used: 511.12MB) (Latency: 6ms Jitter: 9ms Min: 0ms Max: 31ms)

✓ Upload: 95.89 Mbps (Used: 113.80MB) (Latency: 26ms Jitter: 14ms Min: 11ms Max: 57ms)

600KBit.

20mins 44sec for 95551488 bytes.

mmm

smartos-build(~/cores/nat66-stefano)[0]% echo "(95551488 * 8 ) / (20 * 60 + 44)" | bc

614479

i've been able to move it via scp (different port than 22) in a few seconds

Okay, so "flaky T1 line" instead. :)

some throttling or something like that

Yeah, that. Got it, matched md5 and size.

great

this is a deep stack of IPF mess. I'm not going to have cycles to burn but I'll say this.

- It's a DEEP stack, tickled by an interrupt too, I think.

- it *might* be a reflected packet (NAT out, turnaround-on-host, NAT in).

- It's panicking because fr_tcp_age() gets a timeout quee whose "tqe_ifq" is NULL, so the panicking fr_movequeue() function, whose second arg is that tqe_ifq, holds a mutexon a NULL pointer.

In fact, turning off the nat64 the problem disappears

- The naive assumption is that fr_movequeue may wanna check if its second arg is NULL, and if it is, Just Replace It

It's not going to be that simple. :()

I'll update the ticket a bit but then I have to leave it.

Thank you for looking into it!

jbk: In general, no there's no reason you can't use mmio the entire time. That's what we do on Oxide. The biggest challenge is just timing and mapping during boot.

That is, assuming the mmio stuff has been configured propertly for the CPU, which I would assume it is based on the acpi table.

ok..

and yeah, the sequence there is a bit involved (possibly for legacy reasons) so I've been trying to trace all that out...

there seems like there might be some stuff in there that might not longer be relevant (e.g. method 2 access from what I read suggests it was only used for 486 and pentium hardware)

though that might be better as a separate effort

arm, it's a function of the pci nexus to know how to talk to its own config space

(because unfortunately, broadcom took pci-e mandating e-cam as optional)

did the `mac_lso` test linger in `git status` for anyone else?

or have I botched a merge?

richlowe: not really sure what you mean, it's a new file, what do you see?

[illumos-gate] 17741 kmdb: potential null pointer dereference -- Toomas Soome <tsoome⊙mc>

spuos: if NFS didn't provide the required security or is too hard to setup with mis-matched uids then CIFS/SMB might be worth looking at.