Quoting Jamie Gritton <[email protected]> (from Thu, 24 Jun 2010
10:30:42 -0600):
On 06/24/10 06:43, Alexander Leidinger wrote:
On Wed, 23 Jun 2010 13:48:28 -0600 Jamie Gritton<[email protected]>
wrote:
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 not sure from your explanation if your new setup allows ezjail to
mangage jails as easy as it is now. If the new jail command will have
an option to specify a config file, and the jail command only operates
on the jails of this config file and ignores other jails which are
already running (e.g. on a shutdown request), your new system looks
like it is easy to use with ezjail.
Yes, you'll be able to specify a config file via the command line, with
a default of /etc/jail.conf.
Great.
Jails that exist outside of the config file's knowledge are a tricky
point, and the problems are really only on a shutdown request. While I
haven't coded this part of things yet, I've considered that I'll need
two different kinds of blanket shutdowns: one for all the jails in the
config file, and another for all jails in the system. The latter would
be the most sensible to use during system shutdown, when it doesn't make
sense to leave any jails running. But orderly shutdown is part of the
config spec (e.g. running "/bin/sh /etc/rc.shutdown"), and it may be
best to assume that if the jails were created outside of the rc system,
they'll be removed in the same way.
There are two additional sides:
1) For jails which are created by example via ezjail I agree that it
is within the responsability of the ezjail to shut them down.
2) For jails which are created/started by hand from a custom config
file for testing purposes, I think a "shutdown all remeaining jails
even if there is not entry in the config file" would be good. The
problem with this is, that you need to make assumptions how to do a
shutdown, or record this info in the kernel on creation time (and use
this only if no config with appropriate info is available).
So in short, I think it will be compatible with ezjail.
Another point which interests me is how your new way of doing things
will handle things like allow.raw_sockets. Assume I have some kernel
modification which adds allow.XXX, do I need to modify the parsing of
the jail command to handle this, or will this work transparently
without userland modifications?
That will work transparently, as does the current jail(8) command line.
The only time you'd need to modify userland tools for a new jail
parameter is if that parameter has a data type the tools don't
understand. Most parameters operate on numbers or strings, but for
example IP addresses are passed in binary and userland needs to know how
to convert them to/from strings.
That's easy enough for my purposes. :)
Bye,
Alexander.
--
Hitchcock's Staple Principle:
The stapler runs out of staples
only while you are trying to staple something.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[email protected]"
