Date: Sun, 14 Apr 2013 09:24:02 -0600 From: Jamie Gritton <jamie@FreeBSD.org> To: Dirk Engling <erdgeist@erdgeist.org> Cc: freebsd-jail@FreeBSD.org Subject: Re: jail(8) vs. rc.d/jail features - fstab, zfs, vnet Message-ID: <516ACA12.708@FreeBSD.org> In-Reply-To: <516A3F57.6000001@erdgeist.org> References: <51670567.5070602@erdgeist.org> <51674E18.4070402@FreeBSD.org> <516A3F57.6000001@erdgeist.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/13/13 23:32, Dirk Engling wrote:
> On 12.04.13 01:58, Jamie Gritton wrote:
>
>> similar parameter for zfs, or we could create another set of exec.*
>> parameters, which would be more flexible in the long run. But as you
>> hinted at with "postprestart", there doesn't seem to be a good logical
>> name for it.
>
> hmm, maybe the prestart is misnamed, as it actually happens pre-create.
> Then prestart would be exactly where we would put the vnet and dataset
> magic - aftercreate but prestart.
Unfortunately it's too late to rename prestart. But we could sneak in a
postcreate. For limited use, you can work around this by not having any
exec.start, and then doing things in exec.poststart with the last
poststart script being a jexec command to run the jail's /etc/rc (or
whatever).
> I also think, it might be helpful, if the environment could be set up
> that helps the exec.* scripts finding their way back to the jail in
> question. Right now I'd have to create a script for every jail, but setting
>
> JAIL_JID=
> JAIL_NAME=
>
> before executing the scripts could make scripting nicer, especially
> finding the jid is tedious in scripts. I also thought about substitution
> of parameters, but maybe providing the jail name as parameter should be
> the job for the jail.conf's authors.
The cleanest way is with parameter substitution. I like the environment
idea, but I think that also would fit well in a command line. My command
lines run exec in a shell if they have any shell metacharacters
(!"$&'()*;<>?[\]`{|}~). If I had thought ahead, I would have added to
that an '=' at least for the first argument, and then we could send the
environment the sh way. I should make that change in case someone wants
to try that in the future, but for the present I suppose you'd have to
use the env command.
Another possibility would be adding a new exec.env parameter, where you
can set whatever you like. I'd like to avoid having any default
environment variables that aren't somehow specified in the jail.conf.
One improvement I really need to make is to make the jid accessible.
Right now, you have to do something like `jls -j $name jid` in a command
line, which is inelegant to say the least. What I need is a $jid to be
set even when it isn't specified in the config, which is a little
complicated but doable if I just get down to it.
>> Since the vnet.interface command exists, you could use that as a guide
>> for adding a "zfs" parameter. vnet.interface only does anything on jail
>> creation, as the interface automatically reverts to the parent on jail
>> removal. I don't know if the zfs stuff works the same way - if it
>> doesn't, then you'll need a similar "prepoststop" kind of operation.
>
> Looking at the zone_dataset_attach code I understand that jailed zfs
> datasets are a property of the prison struct, saved as osd and vanish
> when the jail dies. So it should not be necessary to undo the "zfs jail"
> command. However there seems not to be a nice way to find out if any
> datasets are attached to a jail, besides trying to attach them.
>
> With that knowledge I think adding a zfs_datasets option for the
> jail.conf is rather straight forward and more likely to be useful
> immediately than having the user construct wrapper scripts to find out
> about the jid of the jail that can then be passed to a number of "zfs
> jail JID DATASET" calls.
>
> Shall I proceed?
Perhaps it would be worthwhile to add a zfs.dataset parameter to go
along with the OSD data, to make that visible to the outside world. It
would be a nice use of the subsystem-dependent parameter stuff currently
used only by Linux emulation. The other option is to code it into
jail(8) itself, though I like the former better.
Proceed away :-).
- Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?516ACA12.708>