multiple interfaces for jail.conf(1) and jail_set(2)

[Isaac (.ike) Levy]

>> In ezjail I can just do this:
>> 
> 
> Of course, it is great to learn that some tools can do this or that.
> However, this only is helpful to those who are just choosing what to use
> for the future. Once your choice is made, you (at least I) kind of avoid
> jumping over to doing something using different tools, especially what is
> already done some specific way on your production machine.
> 
> I guess, what I'm trying to say is: don't be surprised if OP finds your
> effort to help him ultimately useless.
> 
> Incidentally, I for one set up jails "by the book", not by using some tool
> which does it all for me behind the scenes. So, reference to any tools are
> kind of set me off (hence this my reply ;-)
> 
> Just my $0.02.
> 
> Valeri

Sorry to drag this out further, but Valeri is spot on here.

Sorry to indulge and repeat in my own words- after using jail(8) heavily since 1999, and even helping run one of the earliest jail based ISP’s, I am a bit taken back to see such a propensity toward suggesting 3rd party tooling on this list- particularly as it does not answer my original question.

Has everyone been using so many 3rd party tools for jailing for so long that we’ve forgotten how jail(8) works, to the point that my original question can’t even be recognized?  A question not worth answering, but certainly worth pondering!  I’m not arguing against the use of nice 3rd party tools, but I do want to make it very clear that they are not required for heavy or even light jailing.

The strength of jail(8) and jail(2), even before important features like multiple IP’s and per-jail securelevels etc, was always that it’s just another small piece of the the UNIX ecosystem- jail(8) was strong because the *entire* base system made it strong.
For example: before multiple jail IP’s, we’d often simply NAT addresses on the jailing host itself, a bit of scripting ifconfig(8) made it simple for our environment.  Before base provided per-jail devfs rulesets, (and even before devfs), we’d simply make and delete packs of ‘/dev’ tarballs for various jails- removing the devices which were inappropriate for our applied need.  I could go on forever, but nearly everything one could need in a jailed system can always be set up using other base tools- and the UNIX philosophy.

Even today, jail(8) is still trivially scriptable for starting/stopping and managing many jails.  For my use, just using the base system is preferable over 3rd party tooling because I know exactly what I want to do, and with common UNIX knowledge I can manage hundreds and thousands of jails across multiple hardware hosts, with nothing but the base system.  3rd party tools can be wonderful, but over the 17+ years I’ve been using FreeBSD jail(8), many 3rd party tools have come and gone, and changed a great deal- but the base UNIX system has not fundamentally changed.  I mean, even many jail related scripts I wrote in 1999 are still completely functional and relevant.

Best,
.ike