jail(8) vs. rc.d/jail features - fstab, zfs, vnet

[Dirk Engling]

On 12.04.13 01:58, Jamie Gritton wrote:

Jamie,

> 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.

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.

> 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?

  erdgeist