Date: Tue, 19 Jul 2011 11:14:36 -0600 From: Jamie Gritton <jamie@FreeBSD.org> To: Paul Schenkeveld <freebsd@psconsult.nl> Cc: freebsd-jail@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: New jail(8) with configuration files, not yet in head Message-ID: <4E25BB7C.4090106@FreeBSD.org> In-Reply-To: <20110718190839.GA81421@psconsult.nl> References: <4E114EA9.4000605@FreeBSD.org> <20110718190839.GA81421@psconsult.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
This project came from a desire to improve the jail startup procedure in rc.d/jail, which remains stuck handling the old fixed-parameter jails. Rather that continue to extend an already unwieldy number of rc.conf shell variables, I opted to add a configuration file like other subsystems use (e.g. apmd, devd). The new jail pseudo-parameters added to the config file exist mostly to match the existing rc.d/jail functionality - the mount.* and exec.* parameters are direct analogs to rc.conf shell variables. Some other parameters match the command-line options of the existing jail(8). I have tried to avoid bloating the command with new features that don't have a reasonably broad base; the only really new things I can think of are the "depend" parameter (dependency graph of jails, as you mentioned in your footnote [2]) and the "vnet.interface" parameter. I wouldn't want to do away with a config file, as that's a much cleaner way to define multiple jails than depending on the rc system or requiring a "roll your own" approach that is currently the only way to use the newer features. Since jail creation is so tied to processes running under them, the exec.* parameters as originally defined by the rc system are best kept; while a single "command" parameter would suffice for many (perhaps most) jails, the flexibility to run commands as either system or jail users, either before or after jail creation, seems an advantage worth keeping. The other big rc bits - mounting filesystems and preparing network interfaces, seem sufficiently broad-based to include for the general populace. There are still featured I'd like to add, mostly in flexibility of the config file - including files, better handling of auto-generated JIDs, stuff like that. I don't really see adding anything else that isn't tied to the basic definition of jails, and of starting them, stopping them, or changing their parameters - all of which the current command-lines usage already does, though not as well. It's clear now that this won't be happening in 9.0. So none of this is in danger of getting pushed through in a hurry. - Jamie On 07/18/11 13:08, Paul Schenkeveld wrote: > Hi, > > On Sun, Jul 03, 2011 at 11:24:57PM -0600, Jamie Gritton wrote: >> I'm hoping to get the latest version of jail(8) in before the door slams >> shut on 9.0. If anyone wants to take a look at the new code and give it >> a spin, it may help to ease RE's mind about my tardiness. The included >> diff applies to the current usr.sbin/jail directory. In addition to the >> new program, it adds a jail.conf(5) man page that explains the config >> file format (hint: it's a typical C-style block config). > > Although I really like this new functionality, there is one issue that > I am concerned about. Should all this functionality be integrated into > the jail(8) command? > > In UNIX tradition we have simple interfaces[1] in the base system and > jail(8) used to fit in quite well. Your new jail(8) tries to be an all > singing and dancing subsystem for managing jails but there will always > be users that need one more feature[2]. That's why we have ezjail, > jailer, jailadmin and others in ports and over time there will be new > ones with new features. > > Jail(8) is the one FreeBSD command to create, modify and destroy jails > and is used by many of these wrappers. Your new jail(8) covers part > of the functionality of these wrapper but not all. It may grow new > features as people submit ideas and you or someone else is willing to > code the feature but there will always be wrappers to suit needs not > covered by this jail command. > > I don't want to start a bikeshed discussion and will shut up immediately > if I appear to be the only one concerned but if others care like I do, > I'd suggest to put this functionality into a separate program and leave > jail(8) to be the minimalistic interface to just control the jail(2) > system call from a command interpreter. > > Again, I'm not against your enhancements, I'm just worried about > pollution of OS primitives. > > With kind regards, > > Paul Schenkeveld > > [1] Chown/chgrp/chmod are nice examples, I could easily think of at > least a dozen enhancements like only operating on files matching a > specific user/group or mapping a list of old uids/gids to a list of > new ones or looking up user info in LDAP. Sometimes throwing in > find(1) will help you solve the problem at hand, sometimes you need > to write a script or program. > > [2] My favorites: starting jails in parallel, dependency graph of jails, > monitoring jails and restarting them when they die, migration of > jails to other hosts and populating new jails from a release DVD, > /usr/src or the source repository and provisioning jails from a > database. > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E25BB7C.4090106>