In D28952#648255, @jamie wrote:

Might PRIV_SCHED_CPUSET be sufficient for this? If a process has the ability to explicitly expand the current cpu list, it makes sense for it to be able to implicitly do so when attaching to a jail.

first pass at a review

unfucked this differential, after accidentally updating with the wrong diff

address @kevans' feedback, by moving local_rc *.pkgsave skipping into the skipping of scratch files, since that issues a warning.

address @kevans' feedback.

suggestion to improve warning

yes, please

is there an equivalent std.debug file for stable branches?

address @0mp's comments.

addressed @swills' concerns.

aah, very good

fix @emaste's formatting remarks from IRC

i'm getting this message on boot / shutdown:

same functionality, written in C instead of python style C. thanks to RhodiumToad:

In D27959#624597, @emaste wrote:

alternatively, we could say: if it has >= 2 '.', skip it

Yes I think that's reasonable if you're up for updating this review with that change (or I'll take this one as is).

In D27959#624564, @emaste wrote:

LGTM even though we're probably close to the point where it makes sense to have a loop with a list of extensions to ignore.

this almost works 😬

this change makes my build world (in poudriere) fail

address @yuripv's comments.

In D27462#615352, @tcberner wrote:

lgtm, should I commit it?

address (most of?) @tcberner's review

address @tcberner's review

address @yuripv's review: by removing additional lints from rc.conf.5

add explanation that "-H" is needed for altlog_jaillist

So, another test round.
This works fine with syslogd_flags="-s" and syslogd_flags="-ss"; however, only when we add -H to the flags, do the syslog entries become more useful, because we get the host.hostname of the jail in our logs.
so I'll add that to that to the rc.conf man page.

result of portlint -CANv:

is there a way to make this easier searchable? should i mention "redshift"?

i've now finally gotten around to testing this change ^_^;; and i'm quite happy with the results…

address @dch and @yuripv review, moving rc.conf settings to rc.conf(5) and fixing most style issues

In D24570#554569, @freqlabs wrote:

I would love for there to be some way to include global config in jail.conf and per-jail config in jail.d/${jail}.conf. This is a good start in that direction.
Getting libucl to work properly with the current jail.conf format would be a nice way to handle that. I have opened an issue here for one of the limitations I see preventing this: https://github.com/vstakhov/libucl/issues/227

do *not* use sysexits, and document what we've done.

address @kevans's review; and document! fix almost all igor & mandoc concerns, except for this one:

Thanks @yuripv, fixed.

address @yuripv's comments

In D26973#609750, @gallatin wrote:

My issue appears to have been caused by building with WITHOUT_LOCALES=YES. Removing that makes perl happy again. Sort of odd that nothing else cared.

In D27161#609617, @jilles wrote:

My suggestion is to change all the exit statuses that were changed to sysexits codes here to 2 instead.

"requested size %s is not larger than the current filesystem size %s" remains at 1 so that it can be checked for.

This results in a pattern much like grep(1) and test(1): the exit status is 0 if the file system has been or would be (with -N) enlarged, 1 if the file system is already at its maximum size and >1 if an error occurred. In practice, the ">1" is always 2, but this allows future expansion; scripts should check for the value 1, not for the value 2.

In D27161#609095, @oshogbo wrote:

What was motivation for this? Do you have any use case for that?

In D27128#607573, @jamie wrote:

It looks to be working correctly on a quick run-through.

👍

In D27176#606806, @jilles wrote:

I think only EX_TEMPFAIL (75) has a clear and reasonably generic purpose,

add context

In D27128#606151, @jamie wrote:

I may be handy to allow jailed root to control its own security.bsd.suser_enabled.

1: It could either work one-way, with the ability to set clear one's own permission bit but not set it (except in the case of prison0).
2: More flexible but complicated, there could be separate suser_enabled and allow.suser bits, though that's only useful in the probably-rare case of wanting to regain suser ability.

I like option 2 better: easier to code, easier for admins to understand, less likely to cause a problem.