Just a comment: IF a jail is a VNET jail, that jail doesnt need the ip4/ip6 addresses
2010/6/23 Jamie Gritton <[email protected]>: > The rc system is becoming increasingly unable to handle the newer jail > features. We've held off patching /etc/rc.d/jail for new parameters, > with the promise of something better. Here's my outline of what I hope > will be in fact better than what we have now. > > I'm working on extending jail(8) to use a configuration file that would > have everything currently in a $jail_XXX variable in rc.conf. > /etc/rc.d/jail would ideally be reduced to a single "jail -c" call for > startup and "jail -r" for shutdown, though I'm not sure if thing will go > quite that far. > > I'm using the state of the art in config files, the C-style already used > by apmd and devd in /etc, as well as many non-core programs. Each section > would be a jail name, and within the sections would be the jail parameters, > or pseudo-parameters known by the program. > > foo { > host.hostname = "foo.bar"; > path = "/usr/jail/foo"; > ip4.addr = "11.22.33.44"; > } > > The "name" parameter is implicit. Adding an actual name explicitly in > the definition may work if you want it different for some reason, though > I haven't yet worked out how well that would work. > > You can also have default parameters, defined at the top level or in a > pseudo-jail called "*". The reason for that is you can also have > defaults that apply only to some jails, as a hierarchical feature. So > you could have a section "foo.*" that would have parameters for any jail > under "foo". > > Parameters can include other parameters as shell-style variables. This > use useful for defining defaults based on the jail name. A common use I > expect is: > > path = "/usr/jail/$name"; > > This would allow you to set up default parameters as templates. This > variable substitution also works the other way. Consider the global > variable: > > $prefix = "10.1.1"; > > foo { > ip4.addr = "$prefix.3" > } > > Note difference to the previous example. The variable is defined as > "$prefix = ...", not as "prefix = ...". That means it won't be included > as a jail parameter (since there is no parameter called "prefix"). > > When this setup, you should be able to fully specify a jail with most of > the work done on the global end, and the per-jail parameters needing > only the parts that actually vary between jails. > > In addition to the known jail parameters, there are pseudo-parameters > that don't get passed to jail_set(2), but have some use in setting up > the jail on the userland side. The current jail(8) already has the > "command" pseudo-parameter, that specifies something to run (typically > "sh /etc/rc") after the jail is created. > > I have done very little work with these pseudo-parameters so far, and > they're still mostly up in the air. From recent conversation on the > jail list, I've added "depend", which can specify that a jail is not to > start until another jail has been set up. > > The other pseudo-parameters come from what /etc/rc.d/jail currently > does. Many of these have to do with commands run at different stages in > the setup. Here's the current shell settings I have able to pull from > that file: > > Commands: > > exec_prestart: run outside jail before create > exec_start: single command run inside jail upon creation > same as "command" parameter > exec_afterstart: run inside jail after create, each in its own "jexec" > exec_poststart: run outside jail after create (after exec_afterstart) > exec_prestop: run outside jail before destroy > exec_stop: run inside jail before destroy > exec_poststop: run outside jail after destroy > > Other: > > interface: interface to create/destroy all jail's IPs on > fib: setfib ID > devfs_enable: mount a /dev > devfs_ruleset: /dev ruleset > fdescfs_enable: mount a /dev/fs > procfs_enable: mount a /proc > mount_enable: mount arbitrary filesystems > fstab: filesystems to mount > consolelog: where to redirect start/stop command output > > Some of these parameters could use some cleaning up, and are only the > way they are because of the constraints of the sh-based rc system. > Notably "fib" may be better worked into the kernel as a true jail > parameter. I wouldn't expect a one-for-one transfer of all these > parameters from /etc/rc.d/jail into jail(8), but I'd want to provide > their functionality in whatever way works best. > > This is where I start to need input. What works best? I was rather > surprised at the proliferation of exec_* specifiers in the rc system > (including the recent request for yet another), and I'm not sure what > the real needs are for such things. The various filesystem parameters > could probably be (mostly) merged into a single per-jail fstab, or > perhaps a "mount" pseudo-parameter. Doubtless this config file format > will grow with time, but I'd like it to get as clean a start as > possible. > > Right now I don't have code I can share. I've made the code to read the > config files, but not to do anything with them yet. But as I firm up > just what configuration options will exist, something runnable should > soon follow. > > I'm interested in hearing the needs of jail users, to make sure I do the > right thing. > > - Jamie > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "[email protected]" > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[email protected]"
