On 10/18/2013 2:42 PM, Dirk Engling wrote:
Dear jail enthusiasts,in order to move forward with my jail management project ezjail, and make it support the new jail.conf way of managing jail configs, I need a way to add properties to jails that are currently not in the list of allowed parameters. I was thinking of something like web-jail { name = 'www.test.com'; meta.ezjail.imagetype = 'zfs'; meta.ezjail.zfsdataset = 'tank/ezjail/www.test.com-data'; } Alternatively, I could keep a shadow tree of config options and generate jail configs on the fly, but that would mean not using the power of the new jail config format. This can also lead to conflicting settings (e.g. from wildcard jails or global options) and unexpected parts of the system to look for configs. Another issue is the complexity of the jail.conf format which makes it hard to automatically manipulate entries. I've started working on a parser/generator in shell, but wondered if there are any plans to add a way to remove jail blocks (adding is easier) and add/modify/delete parameters in jail blocks. Some standardized way to get the result from jail(8)'s parser would of course be a nice start. Any thoughts on that?
I'd been thinking of a similar thing, but at a different level. A "jail environment" where these arbitrary parameters are visible inside the kernel (and thus also via jls(8)). I was considering a single "env" parameter formatted like an environ(7) string, but I like your presentation as separate parameters (though I would probably call them "env.*" instead of "meta.*"). Regarding the jail.conf format, it would make sense to move its parsing into libjail. Then if we want we could add features like the extra manipulation you mention. - Jamie _______________________________________________ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
