Good afternoon all. I seem to be stumbling over something basic. I'm following the instructions to build OmniOS (bloody) for the first time and while running the omni tool. I reach a password prompt in order to install developer/illumos-tools, which failed because I hadn't setup sudo, so I created the sudo group and enabled sudo sudo rights for

that group. Now I am trying to add user to the sudo group using `usermod -G` and am getting the message `UX: usermod: marksmith is currently logged in, some changes may not take effect until next login.` Checking my `id` after logging back in (and rebooting), the sudo group is not listed.

There is no `userinfo` command that I can find, and `id` usually works fine in it's absence, so I'm sure I'm doing something silly. Could someone point me in the right direction please?

Ok, I got it! Apparently `id -a` is needed to print any additional groups.

If you're using the illumos `id` in /usr/bin then you would need either the -a flag, or the id in /usr/gnu/bin or /usr/xpg4/bin

Or I find the `groups` command a bit more readable

ptribble Thank you :-). `groups` is indeed more readable.

In general does Solaris/illumos/OmniOS include variants of tools from multiple userlands?

I'm used to it being either-or, in that on BSD I expect a BSD userland with BSD tools, and on GNU/Linux I expect a GNU userland with GNU tools. The inclusion of more than one system is very interesting.

It varies based on the distribution, but the illumos-gate includes a lot of userland, but not enough to make a distribution.

I think of it as somewhere between Linux (the kernel) and FreeBSD (the world).

Different distributions augment what's available in their own way - OmniOS adds tools from various places, including GNU.

Some distributions replace more of the illumos-gate userland with GNU

The GNU tools are also under /usr/gnu/bin, so some people like to set their path to have that directory first and have a slightly more familiar experience when coming from other systems.

OmniOS is illumos-gate + omnios-build, and there is omnios-extra for additional packages that are outside of the release cycle.

(there are small number of other pieces like pkg5, but that's most of it)

andyf That makes sense, and is kind of neat, thanks :-). I'm trying to learn illumos/OmniOS so I think I'll stick to the illumos userland as much as possible.

The more I learn about illumos the more I (think I) understand how it sits in the middle between Linux and the BSDs, even down to things like licensing.

Is it expected that you run the `omni` tool with root permissions?

Not in general, no.

`omni` has installed the required packages, prompting for permission where necessary, but now is failing with "fatal: could not create work tree dir '/build/illumos-omnios': Permission denied". That makes sense, and I can create the directory and set the correct permissions, but the instructions on the website would lead me to suspect this

shouldn't happen.

I'm following: omnios.org/dev/build_instructions

It will use pfexec or sudo (depending on configuration) to escalate when necessary, which is just when building media or using `onu` to put the built bits in a new boot environment.

It looks like there's a missing `chown` step in those instructions, yes

You just need to change the ownership on /build (the directory will be automatically created by ZFS since it's a mountpoint)

For future reference, how does one prompt `omni` to use `pfexec` instead of `sudo`? I'm quite enjoying `pfexec` and I've never been a big fan of `sudo` for complexity.

I'll `chown` the build directory to make myself the owner

You can put `PFEXEC=pfexec` in your ~/.omni configuration file

pfexec is a really nice system - it can be very granular and the binary is not even setuid.

One thing it's missing is the option to prompt for authentication for various things, but that will hopefully arrive at some point (I have a working prototype).

I'm sorry for not doing my homework and not figuring it out myself, but how does it work then if it is not setuid?

pfexec sets a process flag on itself, and then when it calls exec(), the kernel spots this and talks to the userland pfexec daemon (pfexecd) to determine what set of extra authorisations and/or privileges to apply, and whether to change the uid/gid for the new child process.

ah, cool

thank you

There is a bit more in IPD25 (fenix)

IPD 25: Authenticated pfexec (draft)

↳ github.com/illumos/ipd/tree/master/ipd/0025/README.md

That IPD is a great read.

Aha a new build with all the new bhyve tsc stuff, let me install that

Odd question, but can someone please point me to what "braich" means in the context of omni build?

It's welsh for "arm"

It's the code name for the aarch64/Arm port of illumos, and the test omnios distribution built on it

:-) Erm... excuse me?

:-) Ahhh! Thanks fellas, I would not have got that on my own

and if at any point you fancy booting that, the last asciicase on omnios.org/setup/zadm shows the quickest way to boot it under qemu on an omnios system.

*asciicast

andyf mind blown!

What's the reason that building works in a zone but the media cannot be generated in a zone?

Generating media involves creating temporary ZFS pools and loopback mount devices and mounting filesystems and so on. I don't remember offhand which specific bit was hard to get going in a zone now, but some part of that doesn't work.

andyf That's logical. Is it possible to do the build in the local zone then build the media in the global zone?