Jamie Gritton <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #24 from Jamie Gritton <> ---
The easiest "fix" is certainly to remove the warning that the old method is
going away.  I wouldn't quite call it "mistaken", but I'll (almost) agree
there's no overriding need to take the bits out of rc.d/jail that translate the
old shell variables.

Almost, because there are some confusing multiple paths on the kernel side that
I'd would like to have deprecated, namely the security.jail.xxx_allowed and
similar sysctls that used to be the only way to (globally) affect a lot of jail
behavior, and are replaced by per-jail parameters but still live on as default
values.  But I can't get rid of those because they're part of the old
shell-based setup.

I remember some talk in the last year or two about a config file library that
would allow (among other things) those DOS-like files that shell scripts seem
to like.  What's the latest on that?  Jail.conf in particular had some sticking
points as I recall.

Something like that could be enough for ezjail, though I also wouldn't mind of
ezjail just started using the current jail.conf format.  Yes, it's harder for a
shell script to use generally, but it would be possible to keep track of a
shell-machine-readable version with a "hands off" comment at the top of it.

You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to