[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Apply devfs rulesets to devfs mountpoints for chroot'd environment?



Hi all, 

I'm trying to install bind9 in a chroot on Debian GNU/kFreeBSD Wheezy.

I mostly followed this: http://wiki.debian.org/Bind9#Bind_Chroot

but bind wasn't too happy with my /dev/random in the chroot; it seems like with kFreeBSD, we can't use mknod for that, and we need to use devfs with a special devfs ruleset. Cf. http://fanf.livejournal.com/123376.html


So I got this working in my shell, and now I'm looking into automating this at boot time. I can put a new line in /etc/fstab that will mount devfs on /path/to/chroot/dev, but AFAICT, I can't specify in /etc/fstab which rules to apply to the devfs mounted there.

The answer for pure FreeBSD systems seems to be adding a devfs ruleset in /etc/devfs.rules, and then to add a line like:

devfs_set_rulesets="/chroot/dev=devfsrules_jail"

in /etc/rc.conf.


I found a relevant email in the archives about some work to provide persistent devfs rules on Debian GNU/kFreeBSD: http://lists.debian.org/debian-bsd/2006/05/msg00005.html

So I tried adding a /etc/devfs.rules file on my Debian GNU/kFreeBSD system; but this seems to have 0 effect: after a reboot, `devfs rule showsets` still shows only one ruleset, the one set up by /etc/init.d/freebsd-utils.
But even if this worked, there doesn't seem to be anything like /etc/rc.conf on Debian GNU/kFreeBSD.


So my question is: what is the right way to apply custom devfs rulesets to devfs mountpoints for something like a chroot'd installation of a service like bind?


Here are the options that I can think about:

  1. Incorporate in individual init scripts like the bind9 one all the necessary commands to read some file that describes a devfs ruleset and applies it to the devfs mountpoint for that chroot.

  2. Enhance /etc/init.d/freebsd-utils to read /etc/devfs.rules, thus creating all the devfs rulesets, and add something else that will allow us to assign a given ruleset to a devfs mountpoint.

  3. Do the same thing as option #2 in a separate init script.


Option #1 doesn't sound like a very good option to me because if it gets wider adoption, a lot of init scripts will have to change to incorporate similar devfs calls for kFreeBSD; furthermore, we tell Linux folks to manually manage their /path/to/chroot/dev by creating the right nodes with mknod, so there's probably no reason to do something different for kFreeBSD by handling all of that automatically only for that kernel.


Option #2 sounds good to me in theory, but there's one catch: freebsd-utils does its job way before local file systems are mounted. So if /path/to/chroot/dev happens to be in a file system that is not the root file system, it won't even be visible by the time freebsd-utils runs (unless we move mountall up in the boot sequence).


That's why I think the most viable option is #3: this new script could depend on mountall, and still be processed in runlevel S to it gets done soon enough for most daemons that might care about this.

What do you guys think about that?


Thanks, 

-- 
Joel Lopes Da Silva


Reply to: