new jail framework with vnet, zfs and jail.conf support

[Andreas Nilsson]

On Tue, May 13, 2014 at 2:40 PM, Fbsd8 <fbsd8 at a1poweruser.com> wrote:

> Andreas Nilsson wrote:
>
>>
>>
>>
>> On Tue, May 13, 2014 at 2:11 PM, Fbsd8 <fbsd8 at a1poweruser.com <mailto:
>> fbsd8 at a1poweruser.com>> wrote:
>>
>>
>>     freebsd_jail at dachev.info <mailto:freebsd_jail at dachev.info> wrote:
>>
>>         Hi,
>>
>>         I'm currently in process of development of new tool for easy
>>         jail administration with zfs and vimage/vnet(bridge epair
>>         interface) support
>>         The idea is to have a single application (python script) without
>>         any other confg files and customization
>>         This tool is written on Python, also work only with vnet, zfs
>>         and FreeBSD 10 (probably will work on FreeBSD 9.1 but i never
>>         test it)
>>         JADM work only with native /etc/jail.conf
>>         When is started for first time jadm generate new /etc/jail.conf
>>         in special format developed by me.
>>         jail.conf file can be used and without JADM.
>>
>>         for more information please contact me or visit:
>>         https://github.com/__NikolayDachev/jadm
>>
>>         <https://github.com/NikolayDachev/jadm>
>>
>>         JADM is in development status more of functions work normal
>>         (with bugs but work :)).
>>
>>         Unfortunately i don't have a lot of time for it so i need test
>>         users.
>>         At the moment last function for JADM is to support skeleton jail
>>         model (similar to ezjail with base jail and etc.)
>>         This function is still in progress meanwhile, if someone have a
>>         time to test all other functions and to report any issue, bug or
>>         ideas
>>
>>
>>
>>
>>     I think you have made some poor basic design choices.
>>
>>     1. Requiring python as a dependent. Thats a lot of overhead just for
>>     a script. Not a show stopper, but a csh script would have been better.
>>
>> Why is csh better than sh?
>>
>>     2. Using the highly experimental "vimage" as the cornerstone of the
>>     over all design. Vimage has many long standing PRs, does not work
>>     with any of the firewalls, has NO maintainer, requires a custom
>>     kernel to enable.
>>     This is a major show stopper. Can not risk a production jail
>>     environment on highly experimental software. Even if vimage gets a
>>     maintainer, all the firewalls need to be updated to play nice in an
>>     vimage environment, and there are existing PRs to that effect which
>>     the firewall maintainers are reluctant to address because of
>>     vimage's status as highly experimental. What your trying to do may
>>     never bare fruit due to things totally out of your control.
>>
>> What do you mean by "not work with any of the firewalls"?
>>
>
> When enabled with a kernel that has vimage they hang the system on boot,
> page fault, or in the case of ipfw, Nat page faults. Just check the
> outstanding pr list for the gory details.


And that is a gross overstatement. I run vimage-kernel and ipfw on a number
of machines. Not one kernel panic.

>
>
>> And for people who require separate networking, vimage is the answer. I
>> say it is a shame vimage is not in generic yet.
>>
>>
> I agree with you. But its out of our control. If I remember correctly, the
> vimage author completed his dissertation which was based on his writing
> vimage, graduated college and moved on with his life.
>
> That would be very sad. Maybe the foundation could sponsor him and/or
someone else to have another go at it. It's not like pf and ipfilter are
the most well-maintained things either.

I however long for the day when FreeBSD catches up with illumos in terms of
light-weight virtualization with separate networking (seeing as jails were
the model for zones). But maybe netmap+vale-switches with vimage could be
made to play better together. But I guess we each want different things.

Best regards
Andreas