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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[email protected]"
