From owner-freebsd-jail@FreeBSD.ORG Tue Jun 21 18:51:29 2011 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C2DD1065690 for ; Tue, 21 Jun 2011 18:51:29 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 2E06F8FC1D for ; Tue, 21 Jun 2011 18:51:28 +0000 (UTC) Received: from mx1.psconsult.nl ([80.89.238.138]) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id p5LIpMVv014074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Jun 2011 20:51:27 +0200 (CEST) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id p5LIpMCh014073 for freebsd-jail@freebsd.org; Tue, 21 Jun 2011 20:51:22 +0200 (CEST) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Tue, 21 Jun 2011 20:51:22 +0200 From: Paul Schenkeveld To: freebsd-jail@freebsd.org Message-ID: <20110621185122.GA13459@psconsult.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Exposing a hierarchy of ZFS datasets inside multiple jails X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 18:51:29 -0000 Hi, On Fri, Jun 17, 2011 at 02:46:59PM -0400, Lars Kellogg-Stedman wrote: > Hello all, > > Hi there, > > I am trying to expose a hierarchy of home directories to a number of > FreeBSD jails. The home directories are configured such that each is a > unique ZFS dataset. The jails are used for development work and hence > are created and destroyed on a regular basis. > > My first thought was simply to use nullfs to mount /home inside the > jail, but nullfs doesn't provide any way to access subordinate > filesystems. > > My second thought was to export the directories via NFS and then run > the automounter daemon (amd) inside each jail. This would have Just > Worked...if it were possible to perform NFS mounts inside a jail. But > it's not. > > My third thought was to run amd on the host and provision nullfs > mounts into the jails...but amd support for nullfs doesn't exist. > > My fourth thought was to go back to exporting the directories using > NFS, because of course amd works with NFS, right? Unfortunately, > rather than mounting a directory on the target mountpoint, amd likes > to mount things in a temporary location (/.amd_mnt/...) and then > create a symlink...which, of course, is useless inside the jail > environment.t > > So maybe you could use nullfs to expose a subdirectory of /.amd_mnt to > the jail? No! This brings us back to my first attempt, in which we > find that there is no way to access subordinate filesystems using > nullfs. > > And then my head exploded. > > Is there a good solution for what I'm trying to do? A bad solution > would be to run a script after booting the jail that would create > multiple nullfs mountpoints for all the home directories, but this is > pretty clunky -- it would need to be run periodically to take into > account new directories or removed directories. So basically I would > have to write a poorly designed automounter. > > There must be a better way. How are other folks solving this? > > It looks like there are discussions going back several years about > setting the VFCF_JAIL on NFS filesystems, but it these haven't > resulted in any changes to the released code. Is this the best way to > go? In theory, if I build a kernel under which NFS is jail friendly I > can go ahead and run amd inside the jail Probably not a good solution but to stir the pool of thoughts a bit... Nullfs mounts and NFS mounts operate on filesystems (or datasets) and do not include subordinates. Smbfs operates on directory (sub)trees so have /home and /home/user[123...] datasets outside the jails, run samba there with a share called [home] (not to be confused with the [homes] share that comes with smb.conf.sample) and mount this share using mount_smbfs inside every jail (from fstab.). Just my $.02 Regards, Paul Schenkeveld