Re: Idea about 'skeleton jail
On Sunday 13 March 2005 14:24, Anish Mistry wrote: On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. Chris, your concept looks reasonable to me. I think I would probably do something along those lines but borrow some idea's from my 'jail-build' script. It has the concept of both includes and excludes, but it also handles another directory for what I call overrides. My overrides directories are per-jail and typically include nothing more than config. files, but it works pretty handily. The overrides may best be implemented in a seperate layer... and I don't even know that I would call something like this a jailfs, more like a globfs or something... I can see potential uses beyond jails. The reasons that I never finished implementing my jailfs with quota support were primarily, that stackable filesystems seem to be somewhat of a black-art. Secondarily, I concluded that the time would be better spent implementing filesystem agnostic quota's in the vfs layer. A proper design should enable you to do a lot of fun things, I was thinking something along the lines of just a simple aggregator that a module could hand function pointers to and register interest in events, with options like.. just-notify-me and dont-continue-without-my-approval. Throw in some helpers for synchronizing module state to disk. The kernel side of this shouldn't really be very hard, but all of the userland quota utilities would need to be rewritten as they are tied to UFS at the block level. This all from about 3 years ago, and I haven't implemented any of it. I rock! Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
On Monday 14 March 2005 10:15 am, Samuel J. Greear wrote: On Sunday 13 March 2005 14:24, Anish Mistry wrote: On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. Chris, your concept looks reasonable to me. I think I would probably do something along those lines but borrow some idea's from my 'jail-build' script. It has the concept of both includes and excludes, but it also handles another directory for what I call overrides. My overrides directories are per-jail and typically include nothing more than config. files, but it works pretty handily. The overrides may best be implemented in a seperate layer... and I don't even know that I would call something like this a jailfs, more like a globfs or something... I can see potential uses beyond jails. The reasons that I never finished implementing my jailfs with quota support were primarily, that stackable filesystems seem to be somewhat of a black-art. Secondarily, I concluded that the time would be better spent implementing filesystem agnostic quota's in the vfs layer. A proper design should enable you to do a lot of fun things, I was thinking something along the lines of just a simple aggregator that a module could hand function pointers to and register interest in events, with options like.. just-notify-me and dont-continue-without-my-approval. Throw in some helpers for synchronizing module state to disk. The kernel side of this shouldn't really be very hard, but all of the userland quota utilities would need to be rewritten as they are tied to UFS at the block level. This all from about 3 years ago, and I haven't implemented any of it. I rock! Sam Would you be able to write up some design specs for getting all this done? This might be a prime example of something to try to get funding for development. -- Anish Mistry pgpyd3VJETqb2.pgp Description: PGP signature
Re: Idea about 'skeleton jail
Anish Mistry wrote: On Monday 14 March 2005 10:15 am, Samuel J. Greear wrote: On Sunday 13 March 2005 14:24, Anish Mistry wrote: On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. Chris, your concept looks reasonable to me. I think I would probably do something along those lines but borrow some idea's from my 'jail-build' script. It has the concept of both includes and excludes, but it also handles another directory for what I call overrides. My overrides directories are per-jail and typically include nothing more than config. files, but it works pretty handily. The overrides may best be implemented in a seperate layer... and I don't even know that I would call something like this a jailfs, more like a globfs or something... I can see potential uses beyond jails. I like the idea of the overrides directory. That would work nicely. If you made the overrides directory the actual jail root that might make sense. Then when the [jail|glob]fs is mounted it will simply choose the file in the jail root directory instead of the one on the normal file system. If we implemented a sort of copy of write architecture we could add to the exceptions list on the fly. That is everything from the host (everything allowed by the config file that is) is available as a copy of the host system. When you edit a file, the filesystem simply creates its own copy for the overrides directory and we edit that. That would be very neat. Imagine that working on the ports system!! :) What do you think? The reasons that I never finished implementing my jailfs with quota support were primarily, that stackable filesystems seem to be somewhat of a black-art. Secondarily, I concluded that the time would be better spent implementing filesystem agnostic quota's in the vfs layer. A proper design should enable you to do a lot of fun things, I was thinking something along the lines of just a simple aggregator that a module could hand function pointers to and register interest in events, with options like.. just-notify-me and dont-continue-without-my-approval. Throw in some helpers for synchronizing module state to disk. The kernel side of this shouldn't really be very hard, but all of the userland quota utilities would need to be rewritten as they are tied to UFS at the block level. This all from about 3 years ago, and I haven't implemented any of it. I rock! Sounds, very interesting. Sam Would you be able to write up some design specs for getting all this done? This might be a prime example of something to try to get funding for development. I would be willing to donate some time to work on designing and building this. Especially if working with someone who knows a lot more about filesystems than me. :) Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
Anish Mistry wrote: On Monday 14 March 2005 10:15 am, Samuel J. Greear wrote: On Sunday 13 March 2005 14:24, Anish Mistry wrote: On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. Chris, your concept looks reasonable to me. I think I would probably do something along those lines but borrow some idea's from my 'jail-build' script. It has the concept of both includes and excludes, but it also handles another directory for what I call overrides. My overrides directories are per-jail and typically include nothing more than config. files, but it works pretty handily. The overrides may best be implemented in a seperate layer... and I don't even know that I would call something like this a jailfs, more like a globfs or something... I can see potential uses beyond jails. The reasons that I never finished implementing my jailfs with quota support were primarily, that stackable filesystems seem to be somewhat of a black-art. Secondarily, I concluded that the time would be better spent implementing filesystem agnostic quota's in the vfs layer. A proper design should enable you to do a lot of fun things, I was thinking something along the lines of just a simple aggregator that a module could hand function pointers to and register interest in events, with options like.. just-notify-me and dont-continue-without-my-approval. Throw in some helpers for synchronizing module state to disk. The kernel side of this shouldn't really be very hard, but all of the userland quota utilities would need to be rewritten as they are tied to UFS at the block level. This all from about 3 years ago, and I haven't implemented any of it. I rock! Sam Would you be able to write up some design specs for getting all this done? This might be a prime example of something to try to get funding for development. I seem to have stopped receiving mail from the mailing lists. Would it be possible for someone to forward any replies on this thread for the last few hours to [EMAIL PROTECTED] If it would be possible for any further emails to be cc'd there as well that would be brilliant. :) Thanks Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
Not sure if this has already made it to the mailing list or not. My uni email account has started blocking email inbound and outbound to the freebsd servers. If I have missed anything since the post I am replying to I would appreciate if it could be forwarded on to me at this address...thanks :) A few more comments below. :) Anish Mistry wrote: On Monday 14 March 2005 10:15 am, Samuel J. Greear wrote: On Sunday 13 March 2005 14:24, Anish Mistry wrote: On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. Chris, your concept looks reasonable to me. I think I would probably do something along those lines but borrow some idea's from my 'jail-build' script. It has the concept of both includes and excludes, but it also handles another directory for what I call overrides. My overrides directories are per-jail and typically include nothing more than config. files, but it works pretty handily. The overrides may best be implemented in a seperate layer... and I don't even know that I would call something like this a jailfs, more like a globfs or something... I can see potential uses beyond jails. I like the idea of the overrides directory. That would work nicely. If you made the overrides directory the actual jail root that might make sense. Then when the [jail|glob]fs is mounted it will simply choose the file in the jail root directory instead of the one on the normal file system. If we implemented a sort of copy of write architecture we could add to the exceptions list on the fly. That is everything from the host (everything allowed by the config file that is) is available as a copy of the host system. When you edit a file, the filesystem simply creates its own copy for the overrides directory and we edit that. That would be very neat. Imagine that working on the ports system!! :) What do you think? The reasons that I never finished implementing my jailfs with quota support were primarily, that stackable filesystems seem to be somewhat of a black-art. Secondarily, I concluded that the time would be better spent implementing filesystem agnostic quota's in the vfs layer. A proper design should enable you to do a lot of fun things, I was thinking something along the lines of just a simple aggregator that a module could hand function pointers to and register interest in events, with options like.. just-notify-me and dont-continue-without-my-approval. Throw in some helpers for synchronizing module state to disk. The kernel side of this shouldn't really be very hard, but all of the userland quota utilities would need to be rewritten as they are tied to UFS at the block level. This all from about 3 years ago, and I haven't implemented any of it. I rock! Sounds, very interesting. Sam Would you be able to write up some design specs for getting all this done? This might be a prime example of something to try to get funding for development. I would be willing to donate some time to work on designing and building this. Especially if working with someone who knows a lot more about filesystems than me. :) Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
Frank == Frank Knobbe [EMAIL PROTECTED] writes: Frank If you nullfs these directories, you loose the ability to Frank prune the jail. Pruning is part of system hardening. I'd May be it's better to use unionfs, so anybody can replace binaries with their stub version pre jail. -- DSS5-RIPE DSS-RIPN 2:550/[EMAIL PROTECTED] 2:550/[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://neva.vlink.ru/~dsh/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
Denis Shaposhnikov wrote: Frank == Frank Knobbe [EMAIL PROTECTED] writes: Frank If you nullfs these directories, you loose the ability to Frank prune the jail. Pruning is part of system hardening. I'd May be it's better to use unionfs, so anybody can replace binaries with their stub version pre jail. This might be a very stupid idea but how about a jailfs. Now I don't know all that much about filesystem design so bear with me. How about something like this: # ls /usr/jail fulljail smalljail fulljail.conf smalljail.conf # cd /usr/jail/fulljail # ls dev etc home # cat ../fulljail.conf allow-all read-only ignore /dev /etc /usr/home allow read-write /usr/ports/distfiles # cd ../smalljail # ls # cat ../smalljail.conf ignore-all allow read-only /bin /usr/bin allow read-write /usr/home # cd /usr/jail # jail /usr/jail/fulljail fulljail 127.0.0.1 /bin/sh /etc/rc # jexec 1 ls COPYRIGHT boot compat dist etc lib mnt rescue sbin sys usr bin cdrom dev entropy home libexec proc root stand tmp var # jail /usr/jail/smalljail smalljail 127.0.0.1 /bin/sh /home/myhome/specialtask.sh # jexec 2 ls bin usr home # SO the jail filesystem is configured at jail-creation time and uses the hosts files or jail files depending on the configuration. Might have to pass the config file into the jail command. As I said I am not an expert. Mabye one of the experts could let me know what they think? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam This might be a very stupid idea but how about a jailfs. Now I don't know all that much about filesystem design so bear with me. How about something like this: snippay SO the jail filesystem is configured at jail-creation time and uses the hosts files or jail files depending on the configuration. Might have to pass the config file into the jail command. As I said I am not an expert. Mabye one of the experts could let me know what they think? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Chris This might be a very stupid idea but how about a jailfs. Now I don't know all that much about filesystem design so bear with me. How about something like this: snippay SO the jail filesystem is configured at jail-creation time and uses the hosts files or jail files depending on the configuration. Might have to pass the config file into the jail command. As I said I am not an expert. Mabye one of the experts could let me know what they think? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. -- Anish Mistry pgp4WCWHjxMeP.pgp Description: PGP signature
Re: Idea about 'skeleton jail
Anish Mistry wrote: On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. Any ideas the sort of work involved in something like this? I am graduating soon and about to have about a month of free time to spend on a project. From the very little I know about file systems on Unix they just stack together right? So there would have to be something to process the configuration file and then is it just a matter of overriding each vnode operation or is there more to it than that? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
On Mon, 2005-01-31 at 13:29 -0600, [EMAIL PROTECTED] wrote: Very nice idea!! This greatly improves jail management on FreeBSD. There is a possibility for a minor drawback -- if one can change a system binary in the host system, them all jails are compromised -- but assuming one would need root access on the host to change the binary, he would have power to change any jail anyway, so this is rather redundant. Another important drawback is that you can not prune the jail. For example, I prefer to remove sharp objects from certain jails for security reasons. There is no need for gcc, ftp and other binaries to reside in a jail when these are not used. These only give an intruder into the jail the tools he needs to bring his scripts in to further hack on the system. If you nullfs these directories, you loose the ability to prune the jail. Pruning is part of system hardening. I'd rather improve the security of a jail than to sacrifice it. Your objectives may differ of course. Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: Idea about skeleton jail
I missed the beginning of the thread, but I thought I would point out the rough script (mknulljail.sh) I wrote awhile back that uses nullfs. I also have a update script (fbinst.sh) for FreeBSD that handles jails. http://www.farley.org/?page=software mknulljail.sh is getting old and can be used for information, but I will put out a new fbinst.sh soon. Seán -- [EMAIL PROTECTED]___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about skeleton jail
I'm curious if your idea for jails extends to running 50+ jails on a box or not? I'd definitely be interested in any feedback you have on what problems may or may not be encountered with so many mounts and also the stability of nullfs nowadays. PHK has just made a call for unionfs and nullfs tests on -CURRENT and he promised to fix every known problems about these filesystems as far as they are not unsolvable architectural problems. Unfortunately these fix won't likely be backported to RELENG_5 since they are tightly bound to his bufwork on -CURRENT. For our 5.x hosting platform, we used a single shared filesystem that was mounted in each client jail, that contained the basic FreeBSD distribution. Ports are handled in a similar manner, having all the basic and commonly used ports already installed in the shared filesystem, and if the user wants to install their own ports, they go into the user's filesystem. We are considering open sourcing all of our stuff, to contribute back what we can to the OS that allowed us to build our entire company. I'd really like to see what others have done to make jails more manageable, as it seems like there is so much that can be done but not many people are working on it. It seems jails have the potential to become an incredible way to virtually partition servers, and it would not be that hard to implement solid tools for managing them. We have things like JID-aware top and tools for automated jail builds, but it would be great to work with some FreeBSD heavies to finish up clean development of things like jail resource restrictions (CPU,MEM,#PROCS,etc) and perhaps a clean and universally useful way to easily configure and launch full jail environments. Are you thinking of Solaris zones [1] ? :-) Best regards, [1] http://www.sun.com/bigadmin/content/zones/zones_lisa.pdf -- Jeremie Le Hen [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about skeleton jail
Dear Xin, On Mon, 31 Jan 2005, Xin LI wrote: XL What I am going to proposal is a concept that I call it skeleton jail, XL or skeljail for short. A skel jail is something that shares most base XL system binaries/libraries with the host, through read-only mount_null's. [snip] XL I have some handcrafted shell scripts to implement skeljail by having XL everything automatically mounted/dismounted. However, I think it might XL be better if we can have jail_name_skeljail=YES switch in our jail XL rc.d(8) startup script. Please let me know if you are interested in the XL idea and I'll post a patch for review if there's enough people that XL wants this. I wrote some scripts for very similar process (however, I used one mount to null mount jail's /usr, and move/symlinked /bin and /sbin to /usr/Rbin and /usr/Rsbin, with /usr/local, /usr/home and /usrX11R6 linked out to jail root) I'm very interested in your patchset, at least for comparing with our (and for learning, or course! ;-) Thanks! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about skeleton jail
On Mon, Jan 31, 2005 at 11:13:04PM -0800, Justin Hopper wrote: + We are considering open sourcing all of our stuff, to contribute back + what we can to the OS that allowed us to build our entire company. I'd + really like to see what others have done to make jails more manageable, + as it seems like there is so much that can be done but not many people + are working on it. It seems jails have the potential to become an + incredible way to virtually partition servers, and it would not be that + hard to implement solid tools for managing them. We have things like + JID-aware top and tools for automated jail builds, but it would be great + to work with some FreeBSD heavies to finish up clean development of + things like jail resource restrictions (CPU,MEM,#PROCS,etc) and perhaps + a clean and universally useful way to easily configure and launch full + jail environments. Yes, it would be useful (I mean CPU/MEM/#PROCS limits), but as I understand there are two kinds of opinions about jails. First is that it should be extended and allow to create a real virtual server and second is that it should be light-weight. + Pawel had some really interesting ideas for jails, but it seems that + he's too busy to work on them at the moment. Speaking of which, his + multiple IPs patch for 5.3 is still broken, and I haven't been able to + find what the problem is =( Could you describe the brokeness? I've made some fixes a week or something ago, I just created a patch against HEAD if you want to try it: http://people.freebsd.org/~pjd/patches/jail_2005020101.patch There can still be some remaining issues, but I don't have time for more detailed tests. The thing that can be useful IMHO is possibility to use reboot(8)/shutdown(8), etc. inside a jail, but... I'm unfortunately too busy with other (probably less interesting, but profitable) projects. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpiLz0M1Jpi6.pgp Description: PGP signature
Re: Idea about skeleton jail
On Mon, 31 Jan 2005, Xin LI wrote: 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. Please post your scripts :-) We recently did the same: http://wleiden.webweaving.org:8080/svn/node-config/other/misc/jails/ And found it to be useful. Dw. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about skeleton jail
2005-02-01 11:40 +0100Pawel Jakub Dawidek The thing that can be useful IMHO is possibility to use reboot(8)/shutdown(8), etc. inside a jail, but... I'm unfortunately too busy with other (probably less interesting, but profitable) projects. Quick question: Is this mean we can have init(8) running in jail? Cheers, -- Xin LI delphij delphij net http://www.delphij.net/ signature.asc Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?=
Re: Idea about skeleton jail
On Wed, Feb 02, 2005 at 12:52:17AM +0800, Xin LI wrote: + ??? 2005-02-01?? 11:40 +0100???Pawel Jakub Dawidek? + The thing that can be useful IMHO is possibility to use + reboot(8)/shutdown(8), etc. inside a jail, but... + I'm unfortunately too busy with other (probably less interesting, but + profitable) projects. + + Quick question: Is this mean we can have init(8) running in jail? Yes, I started a branch for this work (pjd_jailinit), but... -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp2fMX5uvVRx.pgp Description: PGP signature
Re: Idea about skeleton jail
On Wed, 2 Feb 2005, Xin LI wrote: 在 2005-02-01二的 11:40 +0100，Pawel Jakub Dawidek写道： The thing that can be useful IMHO is possibility to use reboot(8)/shutdown(8), etc. inside a jail, but... I'm unfortunately too busy with other (probably less interesting, but profitable) projects. Quick question: Is this mean we can have init(8) running in jail? alias reboot 'kill -TERM -1' alias shutdown 'kill -TERM -1' ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about skeleton jail
I have attached an alpha patch in attachment that implements skeljail,
which includes an installskel target to install a (hmm... as many as
you wish and your hard disk allows) skeleton after buildworld.
In order to make use it, follow the following procedure:
0. make buildworld is a prerequisite to run make installskel so do it
1. make a directory. i.e. mkdir /vhosts/1
2. cd /usr/src make installskel DESTDIR=/vhosts/1
3. (You may want to copy something like password database/first ssh keys
into the jail. I have a core.tbz to do this)
4. Add configuration to /etc/rc.conf
5. Start the jail script as usual. This includes rebooting the host, or
/etc/rc.d/jail restart.
To patch your existing system to get a test run of the patch, the
following procedure is recommended (other ways may work, too):
0. cvsup to latest -CURRENT
1. on top level src tree (/usr/src), do patch (the patch file)
2. make buildworld installworld (make sure you have latest kernel
installed, of course)
3. cd /usr/src/etc/rc.d make install (this can be accomplished in a
different way by running mergemaster)
Added rc.conf knobs:
- jail_X_skel_enable=(YES|NO)
Whether to enable skeleton jail. The default is NO.
- jail_X_skel_root
Where the skeleton should mount everything from. This can be / (the
default), and you can specify something like /vhosts/templateRELENG_4 if
you want a different release.
- jail_X_skel_romounts
Which directories we should mount from the jail_X_skel_root. The
default value is bin sbin lib libexec usr/bin usr/sbin usr/include
usr/lib usr/libdata usr/libexec usr/sbin usr/share.
I've received some of quite impressive scripts from our user community
and I will consult these scripts to find out if I have missed something
important, and do further improvements over this version. Please let me
know if there are any suggestions, flaws with this patch.
Thanks in advance!
Cheers,
--
Xin LI delphij delphij net http://www.delphij.net/
Index: Makefile
===
RCS file: /home/ncvs/src/Makefile,v
retrieving revision 1.315
diff -u -r1.315 Makefile
--- Makefile 21 Dec 2004 09:59:39 - 1.315
+++ Makefile 1 Feb 2005 06:51:43 -
@@ -65,7 +65,7 @@
TGTS= all all-man buildkernel buildworld checkdpadd clean \
cleandepend cleandir depend distribute distributeworld everything \
hierarchy install installcheck installkernel installkernel.debug\
- reinstallkernel reinstallkernel.debug installworld \
+ reinstallkernel reinstallkernel.debug installskel installworld \
kernel-toolchain libraries lint maninstall \
obj objlink regress rerelease tags toolchain update \
_worldtmp _legacy _bootstrap-tools _cleanobj _obj \
@@ -79,6 +79,7 @@
.ORDER: buildworld installworld
.ORDER: buildworld distributeworld
.ORDER: buildworld buildkernel
+.ORDER: buildworld installskel
.ORDER: buildkernel installkernel
.ORDER: buildkernel installkernel.debug
.ORDER: buildkernel reinstallkernel
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.473
diff -u -r1.473 Makefile.inc1
--- Makefile.inc1 20 Jan 2005 10:49:02 - 1.473
+++ Makefile.inc1 1 Feb 2005 16:49:29 -
@@ -516,6 +516,18 @@
rm -rf ${INSTALLTMP}
#
+# installskel
+#
+# Installs a minimum set of files that can support a mini-jail
+#
+installskel:
+ @echo --
+ @echo Making installskel
+ @echo --
+ ${_+_}cd ${.CURDIR}; ${MAKE} hierarchy
+ ${_+_}cd ${.CURDIR}/etc; ${MAKE} distribution
+
+#
# reinstall
#
# If you have a build server, you can NFS mount the source and obj directories
Index: etc/rc.d/jail
===
RCS file: /home/ncvs/src/etc/rc.d/jail,v
retrieving revision 1.21
diff -u -r1.21 jail
--- etc/rc.d/jail 16 Jan 2005 03:12:03 - 1.21
+++ etc/rc.d/jail 1 Feb 2005 07:21:57 -
@@ -59,6 +59,14 @@
eval jail_procfs=\\$jail_${_j}_procfs_enable\
[ -z ${jail_procfs} ] jail_procfs=NO
+ # Default settings for skel jail
+ eval jail_skel_enable=\\$jail_${_j}_skel_enable\
+ [ -z ${jail_skel_enable} ] jail_skel_enable=NO
+ eval jail_skel_root=\\$jail_${_j}_skel_root\
+ [ -z ${jail_skel_root} ] jail_skel_root=/
+ eval jail_skel_romounts=\\$jail_${_j}_skel_romounts\
+ [ -z ${jail_skel_romounts} ] jail_skel_romounts=bin sbin lib libexec usr/bin usr/sbin usr/include usr/lib usr/libdata usr/libexec usr/sbin usr/share
+
eval jail_mount=\\$jail_${_j}_mount_enable\
[ -z ${jail_mount} ] jail_mount=NO
# /etc/fstab.${_j} will be used for {,u}mount(8) if none is specified.
@@ -81,6 +89,9 @@
debug $_j fstab: $jail_fstab
debug $_j exec start: $jail_exec_start
debug $_j exec stop: $jail_exec_stop
+ debug $_j skel enable: $jail_skel_enable
+ debug $_j skel mount-readonly: $jail_skel_romounts
+ debug $_j skel mount-readonly
Re: Idea about 'skeleton jail' -- desirable jail features
In my opinion, FreeBSD is currently behind in virtual server implementations for a few reasons; It does not support multiple IPs in jails. Sure, there are patches, but the one here doesn't compile on 5.3-STABLE, for example. Support integrated into the base system would be neat. It would also be nice a jipconfig which lets the host system root user add IPs to the jails (perhaps a sysctl to control this behaviour? Sometimes it's not desirable to let jail root add IPs at will, while in other situations the jails root user is trustable and would be allowed to add IPs at will.) Also, there was a project for 4.10 if I remember correctly about interface virtualization, it allowed jails to have their own firewall, among other things. I don't know if this would induce a far greater load on the system (it would have to pass the jail firewall and then the host system), but, it's a really nice feature. On a totally off-topic subject, can we, faithful FreeBSD users, expect systrace support in the future ? On Mon, Jan 31, 2005 at 11:13:04PM -0800, Justin Hopper wrote: + We are considering open sourcing all of our stuff, to contribute back + what we can to the OS that allowed us to build our entire company. I'd + really like to see what others have done to make jails more manageable, + as it seems like there is so much that can be done but not many people + are working on it. It seems jails have the potential to become an + incredible way to virtually partition servers, and it would not be that + hard to implement solid tools for managing them. We have things like + JID-aware top and tools for automated jail builds, but it would be great + to work with some FreeBSD heavies to finish up clean development of + things like jail resource restrictions (CPU,MEM,#PROCS,etc) and perhaps + a clean and universally useful way to easily configure and launch full + jail environments. Yes, it would be useful (I mean CPU/MEM/#PROCS limits), but as I understand there are two kinds of opinions about jails. First is that it should be extended and allow to create a real virtual server and second is that it should be light-weight. + Pawel had some really interesting ideas for jails, but it seems that + he's too busy to work on them at the moment. Speaking of which, his + multiple IPs patch for 5.3 is still broken, and I haven't been able to + find what the problem is =( Could you describe the brokeness? I've made some fixes a week or something ago, I just created a patch against HEAD if you want to try it: http://people.freebsd.org/~pjd/patches/jail_2005020101.patch There can still be some remaining issues, but I don't have time for more detailed tests. The thing that can be useful IMHO is possibility to use reboot(8)/shutdown(8), etc. inside a jail, but... I'm unfortunately too busy with other (probably less interesting, but profitable) projects. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about skeleton jail
On Tue, 2005-02-01 at 11:40 +0100, Pawel Jakub Dawidek wrote: On Mon, Jan 31, 2005 at 11:13:04PM -0800, Justin Hopper wrote: + We are considering open sourcing all of our stuff, to contribute back + what we can to the OS that allowed us to build our entire company. I'd + really like to see what others have done to make jails more manageable, + as it seems like there is so much that can be done but not many people + are working on it. It seems jails have the potential to become an + incredible way to virtually partition servers, and it would not be that + hard to implement solid tools for managing them. We have things like + JID-aware top and tools for automated jail builds, but it would be great + to work with some FreeBSD heavies to finish up clean development of + things like jail resource restrictions (CPU,MEM,#PROCS,etc) and perhaps + a clean and universally useful way to easily configure and launch full + jail environments. Yes, it would be useful (I mean CPU/MEM/#PROCS limits), but as I understand there are two kinds of opinions about jails. First is that it should be extended and allow to create a real virtual server and second is that it should be light-weight. I would definitely like to see the jails extended in a way that would still leave them uncomplicated for people that just want to jail a single process or create a very simple jailed environment. I'm hoping that all the extensions can be created in a way that will not interfere with this. For example, each prison can have CPU/MEM/#PROCS limits in them, but by default they would be ignored. We have implemented MEM and #PROCS limits in our prison structures, but we have not settled on a method to control them. Currently we are using a kernel module approach that allows the alteration of prison values, but there is no proper locking, so it's of course not safe. + Pawel had some really interesting ideas for jails, but it seems that + he's too busy to work on them at the moment. Speaking of which, his + multiple IPs patch for 5.3 is still broken, and I haven't been able to + find what the problem is =( Could you describe the brokeness? I had sent you an email about 4 weeks ago about it, but didn't hear a response. I also emailed the hackers list about it, but no one responded. There was also a Devon H. O'Dell who said that he might be able to assist with any problems with the patch, but emails to him were not answered either. The problem is simply that jails cannot use sockets. I can forward my email with kernel trace if you do not have a copy. I've made some fixes a week or something ago, I just created a patch against HEAD if you want to try it: http://people.freebsd.org/~pjd/patches/jail_2005020101.patch There can still be some remaining issues, but I don't have time for more detailed tests. Excellent, I'll try the patch here in a couple of minutes. Can you tell me what the known issues are with the patch? Perhaps I can lend a hand on helping to resolve them. The thing that can be useful IMHO is possibility to use reboot(8)/shutdown(8), etc. inside a jail, but... I'm unfortunately too busy with other (probably less interesting, but profitable) projects. -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer BSDHosting.net Hosting Division of Digital Oasys Inc. http://www.bsdhosting.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about skeleton jail
On Tue, Feb 01, 2005 at 01:31:11PM -0800, Justin Hopper wrote: + I've made some fixes a week or something + ago, I just created a patch against HEAD if you want to try it: + + http://people.freebsd.org/~pjd/patches/jail_2005020101.patch + + There can still be some remaining issues, but I don't have time for more + detailed tests. + + Excellent, I'll try the patch here in a couple of minutes. Can you tell + me what the known issues are with the patch? Perhaps I can lend a hand + on helping to resolve them. Frankly, I don't know. It just needs detailed testing. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp1aIJTzcoLj.pgp Description: PGP signature
Idea about skeleton jail
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.
Thanks in advance!
Cheers,
--
Xin LI delphij delphij net http://www.delphij.net/
Index: Makefile
===
RCS file: /home/ncvs/src/Makefile,v
retrieving revision 1.315
diff -u -r1.315 Makefile
--- Makefile 21 Dec 2004 09:59:39 - 1.315
+++ Makefile 31 Jan 2005 13:02:34 -
@@ -65,7 +65,7 @@
TGTS= all all-man buildkernel buildworld checkdpadd clean \
cleandepend cleandir depend distribute distributeworld everything \
hierarchy install installcheck installkernel installkernel.debug\
- reinstallkernel reinstallkernel.debug installworld \
+ reinstallkernel reinstallkernel.debug installskel installworld \
kernel-toolchain libraries lint maninstall \
obj objlink regress rerelease tags toolchain update \
_worldtmp _legacy _bootstrap-tools _cleanobj _obj \
Index: Makefile.inc1
(Items indicated with * means non-essential items)===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.473
diff -u -r1.473 Makefile.inc1
--- Makefile.inc1 20 Jan 2005 10:49:02 - 1.473
+++ Makefile.inc1 31 Jan 2005 13:02:34 -
@@ -516,6 +516,18 @@
rm -rf ${INSTALLTMP}
#
+# installskel
+#
+# Installs a minimum set of files that can support a mini-jail
+#
+installskel:
+ @echo --
+ @echo Making installskel
+ @echo --
+ ${_+_}cd ${.CURDIR}; ${MAKE} hierarchy DESTDIR=${DESTDIR}
+ ${_+_}cd ${.CURDIR}/etc; ${MAKE} distribution DESTDIR=${DESTDIR}
Re: Idea about skeleton jail
2005-01-31 17:10 +0100Jeremie Le Hen On Mon, Jan 31, 2005 at 09:39:52PM +0800, Xin LI wrote [snip] Why don't you simply call the target installjail instead of installskel ? I'd admit that I have chosen the name just by chance. I prefer installskel over installjail since I think the latter refers to a concept that we actually install a full system for jailing, which is IMO installworld+etc/distribute :-) Just my $0.02 Cheers, -- Xin LI delphij delphij net http://www.delphij.net/ signature.asc Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?=
Re: Idea about 'skeleton jail
Very nice idea!! This greatly improves jail management on FreeBSD. There is a possibility for a minor drawback -- if one can change a system binary in the host system, them all jails are compromised -- but assuming one would need root access on the host to change the binary, he would have power to change any jail anyway, so this is rather redundant. Great feature here, when can we see this added to the system? 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 [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about 'skeleton jail
On Mon, Jan 31, 2005 at 01:29:24PM -0600, [EMAIL PROTECTED] wrote: Very nice idea!! This greatly improves jail management on FreeBSD. There is a possibility for a minor drawback -- if one can change a system binary in the host system, them all jails are compromised -- but assuming one would need root access on the host to change the binary, he would have power to change any jail anyway, so this is rather redundant. Great feature here, when can we see this added to the system? BTW, people are using setups like this for years. 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 -- Pawe Maachowski ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea about skeleton jail
On Mon, 2005-01-31 at 21:39 +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 We had looked into this idea at one point for our hosting systems, but what deterred us was the fact that on our systems we run several jails per box, around 50, and to have a mount for each system directory (12 or so) inside each jail would lead to a box loaded with mount points (600 +). I never looked into it fully, but I assumed this would be a resource problem, having so many mounts. Also, at that time we were using FreeBSD 4.4, and nullfs would sometimes cause kernel panics when trying to umount the jails. I'm curious if your idea for jails extends to running 50+ jails on a box or not? I'd definitely be interested in any feedback you have on what problems may or may not be encountered with so many mounts and also the stability of nullfs nowadays. For our 5.x hosting platform, we used a single shared filesystem that was mounted in each client jail, that contained the basic FreeBSD distribution. Ports are handled in a similar manner, having all the basic and commonly used ports already installed in the shared filesystem, and if the user wants to install their own ports, they go into the user's filesystem. We are considering open sourcing all of our stuff, to contribute back what we can to the OS that allowed us to build our entire company. I'd really like to see what others have done to make jails more manageable, as it seems like there is so much that can be done but not many people are working on it. It seems jails have the potential to become an incredible way to virtually partition servers, and it would not be that hard to implement solid tools for managing them. We have things like JID-aware top and tools for automated jail builds, but it would be great to work with some FreeBSD heavies to finish up clean development of things like jail resource restrictions (CPU,MEM,#PROCS,etc) and perhaps a clean and universally useful way to easily configure and launch full jail environments. Pawel had some really interesting ideas for jails, but it seems that he's too busy to work on them at the moment. Speaking of which, his multiple IPs patch for 5.3 is still broken, and I haven't been able to find what the problem is =( 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. Thanks in advance! Cheers, -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer BSDHosting.net Hosting Division of Digital Oasys Inc. http://www.bsdhosting.net ___ freebsd-hackers@freebsd.org mailing list
