Re: Idea about "skeleton jail"
From: Jeremie Le Hen (jeremie_at_le-hen.org)
Date: 01/31/05
- Previous message: security_at_revolutionsp.com: "Re: Simple question about CPUs and processes"
- In reply to: Xin LI: "Idea about "skeleton jail""
- Next in thread: Xin LI: "Re: Idea about "skeleton jail""
- Reply: Xin LI: "Re: Idea about "skeleton jail""
- Reply: security_at_revolutionsp.com: "Re: Idea about 'skeleton jail"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 31 Jan 2005 17:10:06 +0100 To: delphij@delphij.net
On Mon, Jan 31, 2005 at 09:39:52PM +0800, Xin LI wrote:
> Dear folks,
>
> The recent discussion about whether we should have the perl port to
> touch/install /usr/bin/perl. While I'm not interested in joining the
> discussion, it inspired me that we can make use of the fact that ports
> should not install things to "system" area and take advantage from it.
> Finally these ideas results me to hack up something that might be
> valuable to share with our users.
>
> What I am going to proposal is a concept that I call it "skeleton jail",
> or "skeljail" for short. A skel jail is something that shares most base
> system binaries/libraries with the host, through read-only mount_null's.
>
> I have already done some experiments. Basically we want the following
> directories to be mount_null'ed:
> /bin, /sbin, /lib, /libexec, /usr/bin, /usr/sbin, /usr/include,
> /usr/lib, /usr/libdata, /usr/libexec, /usr/sbin, /usr/share
>
> To get most of what we want the jail to do, to work, this includes
> ssh(1) and something else. Optionally, we may want to mount_nullfs a
> read-write /usr/ports/distfiles, a readonly /usr/ports, and something
> like /usr/game to be mounted into the skeljail.
>
> In order to avoid having to do something magic instead of "make
> installworld", I have a patchset against src/Makefile and
> src/Makefile.incl to make the work a bit easier. It adds a so-called
> "installskel" target that creates a skeljail that contains necessary
> directory hierarchy, and a set of /etc configuration files that will be
> useful to start the jail. The target must be used after a ``make
> buildworld''
>
> The two major benefits for the skeljail are:
> - Reduces the ordinary management cost because many base system files
> are shared, hence you patch only once to get all jails patched.
> - Reduces the space cost that needed for a newly created jail. It used
> to need about 110MB and with skeljail you will only need no more than
> 3MB.
>
> Apparantly skeljail is not suitable for those who want:
> - Run different FreeBSD releases on a single box.
> - Run ports that does touch system area.
>
> But having it doesn't hurt the ability for you to run a full jail.
>
> I have some handcrafted shell scripts to implement skeljail by having
> everything automatically mounted/dismounted. However, I think it might
> be better if we can have jail_<name>_skeljail="YES" switch in our jail
> rc.d(8) startup script. Please let me know if you are interested in the
> idea and I'll post a patch for review if there's enough people that
> wants this.
Sold ! I just use the same setup you described in order to reduce disk
usage and synchonize automatically jails with base system. It would be
indeed a great step forward for jail management IMHO.
Why don't you simply call the target "installjail" instead of
"installskel" ?
-- Jeremie Le Hen jeremie@le-hen.org _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: security_at_revolutionsp.com: "Re: Simple question about CPUs and processes"
- In reply to: Xin LI: "Idea about "skeleton jail""
- Next in thread: Xin LI: "Re: Idea about "skeleton jail""
- Reply: Xin LI: "Re: Idea about "skeleton jail""
- Reply: security_at_revolutionsp.com: "Re: Idea about 'skeleton jail"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
