does illumos have ability for mandatory file locking

and is it less broken than linux's (currently depreciated)

illumos.org/man/2/fcntl suggests there is but that it needs to be enabled for the file first, which sounds good, but what command would be used to enable mandatory locking on a file?

chmod(2) - it's overloaded on the sgid bits of the file mode

`chmod 02644` for example.

chmod(1) for the command, obviously, but it's documented quite well in illumos.org/man/2/chmod

thanks

I'm interested in illumos now, which distro is least dead

Apart from those which are used internally by various companies, SmartOS, OpenIndiana, Tribblix and OmniOS are all options in my opinion. There are others such as DilOS that I don't know much about, but it's also active from what I've seen.

It depends what you prefer - for example SmartOS is targetted at being a hypervisor (originally booted from USB or PXE but can now boot from internal disk), OmniOS and OI are for more traditional disk installation - OI follows illumos-gate directly, OmniOS has stable and LTS releases, and a 'bloody' release that is updated much more often (usually weekly). Tribblix is a "retro" distribution that I have not used much, but it has a really nice package system

that is very fast (and still has SPARC support!)

so I need 32 bit, it seems none of these and including ones listed on website don't support 32 bit yet 32 bit is still in the illumos tree right

32bit kernel?

They all still support 32-bit userland, just not a 32-bit kernel

everything now runs 64bit kernel with mixed 32/64 userland

I need 32 bit kernel, but I could very well upgrade hardware depending on which ones have mandatory access control options and non shitty package manager.

because lack of mandatory access control is pita for my application

*lack of mandatory file lock

Tribblix is possibly the only one that still has a version with a 32-bit kernel, but I doubt that is still supported.

andyf: it's not listed as a download on the website

The distinction here is that our 64-bit kernel still supports 32-bit applications. However, illumos as a whole does not suppot it for a kernel.

so that explains it

does illumos rbac implementation have issues

That's a vague question. AFAICT we don't as long as it's configured properly.

Are you concerned about something or have you found something wrong?

kebe: I'm just probing for caution responses.

caution responses/best practices

...guides

Gotcha.

[illumos-gate] 15566 Update AMD microcode to 20230414 -- Andy Fiddaman <illumos⊙fn>

@richlowe fenix illumos 3627

BUG 3627: ipnet taskq can outlive ipnet_stack_t (or netstack in general) and panic (New)

↳ illumos.org/issues/3627

I tripped on it today while rebooting the Kebecloud HN as part of ordinary update testing.

I have a core!

tl;dr --> ipnet needs to teardown its taskq(s) earlier in its existence, not in _fini().

hurray!

I'm not fixing it right now. I'm remote, making sure 20230420 gets out, and then bracing for impact with much (but well-timed) upstream -gate churn for tomorrow or Monday when I return to MA.

it looks like ipnet doesn't register a shutdown routine.. IIRC how netstacks are torn down.. that's probably the place to tear down the taskq

at least my recollection is that's where you want to more or less 'quiesce' stuff, then the destroy is where you can free up any resources

(at least that seemed to be the common pattern)

though i'm not sure any of that is really captured anywhere that's easily discoverable

I still pretty firmly believe ipnet doesn't _need_ that taskq

jesus the peanut gallery got way too excited over this one: openzfs/zfs #12225

[illumos-gate] 15463 ndi_devi_enter et al can be safer and clearer -- Dan Cross <cross⊙oc>

andyf OpenIndiana also still has SPARC support: dlc.openindiana.aurora-opencloud.org/SPARC

We certainly could use a few more testers...