From edwin.shao at gmail.com Thu Oct 1 18:42:42 2009 From: edwin.shao at gmail.com (Edwin Shao) Date: Thu Oct 1 18:42:48 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: <4AC18822.7020705@FreeBSD.org> References: <4AC0E5E6.1010700@FreeBSD.org> <20090928180731.M68375@maildrop.int.zabbadoz.net> <4AC12798.8070308@FreeBSD.org> <4AC18822.7020705@FreeBSD.org> Message-ID: The base system has allow_raw_sockets, the first level jail also has allow_raw_sockets and has the exact same configuration as the base system (I use puppet to manage config files.) I can't set allow_raw_sockets anyway for the second-level jail without manually invoking the jail command. On Tue, Sep 29, 2009 at 7:08 AM, Jamie Gritton wrote: > Does the base system have security.jail.allow_raw_sockets=1? You need to > have that, or set the jail's allow.raw_sockets. You can't set the jail's > permissions from within the jail itself. If you have multiple jail > levels, then both jails need to allow raw sockets - a jail can't allow a > child jail to do what it can't do itself. > > - Jamie > > > Edwin Shao wrote: > >> One other thing that is odd: hierarchical jails don't seem to inherit some >> sysctls such as allow_raw_socket. >> >> In the host (jail), rc.conf has jail_set_allow_raw_sockets="YES" and >> sysctl.conf has "security.jail.allow_raw_sockets=1", but no child jail can >> ping out: >> neko# ping google.com >> ping: socket: Operation not permitted >> >> What is happening in this case? >> Thank you for your time again. >> >> >> On Tue, Sep 29, 2009 at 12:16 AM, Jamie Gritton > jamie@freebsd.org>> wrote: >> >> The sysctls not only don't get written to, they don't have any useful >> information to read either. They only describe the existence and format >> of the various jail parameters. Sorry, but there;s no way to set a >> default children.max parameter or inherit it from the parent. We've >> decided to set the default to the most secure/restrictive in many >> cases. >> Once we've come up with a new jail configuration interface, this won't >> be such a hassle. >> >> The devfs errors are probably something that will have to be addressed >> in a later revision - I haven't looked in the devfs direction so I'm >> not >> sure about that. The mount error may be related to the first jail's >> allow.mount parameter (whose default comes from >> security.jail.mount_allowed). >> >> - Jamie >> >> Edwin Shao wrote: >> >> Thanks, that worked for me. >> >> * Using jail to change children.max on the parent does not >> affect `sysctl security.jail.param.children.max` in the child. >> Also security.jail.param.children.cur never changes either. Not >> sure if that's intended behavior. >> * Is there any way to persist the >> security.jail.param.children.max parameter without entering the >> jail command every time? * I get the following output when I >> create a jail inside a jail: >> >> hyper ~> ezjail-admin start neko >> Configuring jails:. >> Starting jails:devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not >> permitted >> devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted >> /etc/rc.d/jail: WARNING: devfs_set_ruleset: you must specify a >> ruleset number >> devfs rule: ioctl DEVFSIO_SAPPLY: Operation not permitted >> ln: log: Operation not permitted >> mount: proc : Operation not permitted >> neko. >> >> I'm using the same configuration values as in the parent's jail, >> which work. Everything seems to work alright inside the jail, so >> I assume the errors are safe to ignore? >> >> Thanks again! >> - Edwin >> >> On Mon, Sep 28, 2009 at 9:11 PM, Bjoern A. Zeeb >> > >> > >> wrote: >> >> On Mon, 28 Sep 2009, Edwin Shao wrote: >> >> Hi Jamie, >> When I try to change the parameter, nothing happens: >> rescue /etc> sudo sysctl security.jail.param.children.max=1 >> security.jail.param.children.max: 0 -> 0 >> >> rescue /etc> sudo sysctl security.jail.param.children.max >> security.jail.param.children.max: 0 >> >> Am I doing this incorrectly? >> >> >> Yes. It's a parameter to jail(8). The security.jail.param >> sysctls can >> be seen as a list of possible options valid to jail(8). See >> man 8 jail >> for the exact details. >> >> /bz >> >> -- Bjoern A. Zeeb What was I talking about and >> who are you again? >> >> >> >> From jamie at FreeBSD.org Fri Oct 2 18:46:22 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Fri Oct 2 18:46:27 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: References: <4AC0E5E6.1010700@FreeBSD.org> <20090928180731.M68375@maildrop.int.zabbadoz.net> <4AC12798.8070308@FreeBSD.org> <4AC18822.7020705@FreeBSD.org> Message-ID: <4AC64A73.7010305@FreeBSD.org> Without going into the current rc system, which isn't up to the task of hierarchical jails, here's a minimal set of parameters/commands to create hierarchical jails that can still ping: # jail -c name=foo host.hostname=foo allow.raw_sockets children.max=99 ip4.addr=10.20.12.68 persist # jexec foo /bin/csh foo# jail -c name=bar host.hostname=bar allow.raw_sockets ip4.addr=10.20.12.68 persist foo# jexec bar /bin/csh bar# ping gritton.org PING gritton.org (161.58.222.4): 56 data bytes 64 bytes from 161.58.222.4: icmp_seq=0 ttl=54 time=78.344 ms - Jamie Edwin Shao wrote: > The base system has allow_raw_sockets, the first level jail also has > allow_raw_sockets and has the exact same configuration as the base > system (I use puppet to manage config files.) I can't set > allow_raw_sockets anyway for the second-level jail without manually > invoking the jail command. > > On Tue, Sep 29, 2009 at 7:08 AM, Jamie Gritton > wrote: > > Does the base system have security.jail.allow_raw_sockets=1? You need to > have that, or set the jail's allow.raw_sockets. You can't set the jail's > permissions from within the jail itself. If you have multiple jail > levels, then both jails need to allow raw sockets - a jail can't allow a > child jail to do what it can't do itself. > > - Jamie > > > Edwin Shao wrote: > > One other thing that is odd: hierarchical jails don't seem to > inherit some sysctls such as allow_raw_socket. > > In the host (jail), rc.conf has jail_set_allow_raw_sockets="YES" > and sysctl.conf has "security.jail.allow_raw_sockets=1", but no > child jail can ping out: > neko# ping google.com > > ping: socket: Operation not permitted > > What is happening in this case? > Thank you for your time again. > > > On Tue, Sep 29, 2009 at 12:16 AM, Jamie Gritton > > >> wrote: > > The sysctls not only don't get written to, they don't have > any useful > information to read either. They only describe the existence > and format > of the various jail parameters. Sorry, but there;s no way to > set a > default children.max parameter or inherit it from the parent. > We've > decided to set the default to the most secure/restrictive in > many cases. > Once we've come up with a new jail configuration interface, > this won't > be such a hassle. > > The devfs errors are probably something that will have to be > addressed > in a later revision - I haven't looked in the devfs direction > so I'm not > sure about that. The mount error may be related to the first > jail's > allow.mount parameter (whose default comes from > security.jail.mount_allowed). > > - Jamie > > Edwin Shao wrote: > > Thanks, that worked for me. > > * Using jail to change children.max on the parent does not > affect `sysctl security.jail.param.children.max` in the > child. > Also security.jail.param.children.cur never changes > either. Not > sure if that's intended behavior. > * Is there any way to persist the > security.jail.param.children.max parameter without > entering the > jail command every time? * I get the following output when I > create a jail inside a jail: > > hyper ~> ezjail-admin start neko > Configuring jails:. > Starting jails:devfs rule: ioctl DEVFSIO_RGETNEXT: > Operation not > permitted > devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted > /etc/rc.d/jail: WARNING: devfs_set_ruleset: you must > specify a > ruleset number > devfs rule: ioctl DEVFSIO_SAPPLY: Operation not permitted > ln: log: Operation not permitted > mount: proc : Operation not permitted > neko. > > I'm using the same configuration values as in the > parent's jail, > which work. Everything seems to work alright inside the > jail, so > I assume the errors are safe to ignore? > > Thanks again! > - Edwin > > On Mon, Sep 28, 2009 at 9:11 PM, Bjoern A. Zeeb > > > > > >>> wrote: > > On Mon, 28 Sep 2009, Edwin Shao wrote: > > Hi Jamie, > When I try to change the parameter, nothing happens: > rescue /etc> sudo sysctl > security.jail.param.children.max=1 > security.jail.param.children.max: 0 -> 0 > > rescue /etc> sudo sysctl > security.jail.param.children.max > security.jail.param.children.max: 0 > > Am I doing this incorrectly? > > > Yes. It's a parameter to jail(8). The security.jail.param > sysctls can > be seen as a list of possible options valid to > jail(8). See > man 8 jail > for the exact details. > > /bz > > -- Bjoern A. Zeeb What was I talking > about and > who are you again? > > > > From bugmaster at FreeBSD.org Mon Oct 5 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:08:45 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200910051106.n95B6t2J088719@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 4 problems total. From bzeeb-lists at lists.zabbadoz.net Tue Oct 6 10:50:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Oct 6 10:50:26 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA5704.2070404@elischer.org> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> <4ACA4216.9060008@tomjudge.com> <4ACA5704.2070404@elischer.org> Message-ID: <20091006104529.B5956@maildrop.int.zabbadoz.net> On Mon, 5 Oct 2009, Julian Elischer wrote: > Tom Judge wrote: >> Adam Vande More wrote: >>> On Mon, Oct 5, 2009 at 12:47 PM, Tom Judge >> > wrote: >>> >>> Julian Elischer wrote: >>> >>> Tom Judge wrote: >>> >>> Hi, >>> >>> Does anyone know of a patch that will add per jail memory >>> limits so that a jail can't swallow the resources of the >>> entire box? >>> >>> >>> Thanks >>> >>> Tom >>> >>> not yet.. >>> >>> >>> I started to port this to 7.1 today: >>> >>> http://wiki.freebsd.org/JailResourceLimits >>> >>> >>> What are the peoples opinions on this patch? >>> >>> >>> Tom >>> >>> >>> If you're soliciting opinions if this will be used and is needed, I would >>> love to see this functionality. This is the main reason I've had to chose >>> XEN over jails. If you need some help testing, let me know. >>> >>> -- >>> Adam Vande More >> Hi Adam, >> >> I have a patch against 7.1 here: >> http://svn.tomjudge.com/freebsd/patches/jail-resource-limits/jail-limits.patch > > > > probably the person who should work with this in -current is james (CC'd) Probably the person who should be contacted is trasz who worked on hierachical resource limit per .., jail in p4. Though this is slightly different. I think it's ok if people need those things to update the pathes but I doubt any will probably ever make it into FreeBSD as those things are kind of contrary to the V_ plans. BTW, I think the patch referenced is not the latest I had seen and I thought that we also had one for 7.x or even for 8 already floating around. Maybe some investigation on list archives etc. might be helpful before starting to hack things. Maybe also check the links on http://wiki.freebsd.org/Jails >> >> >> I will try to bring the patch up to current when I get a chance but I have >> no real need to do this as we use 7.1 in production. >> >> Notes: >> >> * CPU limiting is not support is not supported unless you use >> shecd_4bsd. >> * I have not tested this on any system yet, just compile tested, I am >> putting it though its paces right now. >> >> Tom -- Bjoern A. Zeeb It will not break if you know what you are doing. From 000.fbsd at quip.cz Wed Oct 7 09:35:48 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Oct 7 09:35:55 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACBF147.1030002@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACBF147.1030002@tomjudge.com> Message-ID: <4ACC60EF.50104@quip.cz> Tom Judge wrote: > So I have worked up some thing usable fore us based on the 7.0 code from > the wiki. > > This patch is for 7.1 in implements both soft and hard memory limits. > > Details are here: > http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits > > Changes that add supporting infrastructure for cpu limiting are in the > patch but changes to the schedulers have not been included. If you need > the scheduling support you will need to patch sched_4bsd with the code > from the original patch set here: > > http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html > > Hope this is useful for some people. I added links to this thread and to your patch into wiki page http://wiki.freebsd.org/Jails. I hope it will help people to find your work. Do you plan to make it for 7.2 and other future releases? Miroslav Lachman From greenx at yartv.ru Wed Oct 7 10:17:48 2009 From: greenx at yartv.ru (Andrey Groshev) Date: Wed Oct 7 10:17:55 2009 Subject: how to make the jail safe for the parent system? Message-ID: <4ACC6ABE.9050107@yartv.ru> Hi, All! I understand, what not absolutely normal question, but... There is I and my server. Also there is other person a server responsible for a web. Periodically he wants that I would instal some software, but in my representation, this software bad or unnecessary. I wish to make jail for its and its software. To give to this person complete access to it, let does all that wants. But, if in the jail create wrong start scripts, then the parent system too cannot be started up to the end. For example: in jail in /etc/rc.local write /bin/sh And that starts all after this prison will not receive handle. Question: how it to avoid? From kostjn at peterhost.ru Wed Oct 7 10:30:58 2009 From: kostjn at peterhost.ru (Menshikov Konstantin) Date: Wed Oct 7 10:31:06 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACC60EF.50104@quip.cz> References: <4ACA0549.7030404@tomjudge.com> <4ACBF147.1030002@tomjudge.com> <4ACC60EF.50104@quip.cz> Message-ID: <4ACC6C01.80106@peterhost.ru> Miroslav Lachman wrote: > Tom Judge wrote: > >> So I have worked up some thing usable fore us based on the 7.0 code >> from the wiki. >> >> This patch is for 7.1 in implements both soft and hard memory limits. >> >> Details are here: >> http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits >> >> Changes that add supporting infrastructure for cpu limiting are in >> the patch but changes to the schedulers have not been included. If >> you need the scheduling support you will need to patch sched_4bsd >> with the code from the original patch set here: >> >> http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html >> >> Hope this is useful for some people. > > I added links to this thread and to your patch into wiki page > http://wiki.freebsd.org/Jails. I hope it will help people to find your > work. > Do you plan to make it for 7.2 and other future releases? > > Miroslav Lachman > _______________________________________________ > 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" > It is good that people work in this direction! At present there are some patches, however any of them is not finished. I suggest to discuss in details a problem. The most important questions. 1. It is necessary to limit what resources? 2. How resources should be limited? Soft and hard limits. 3. How to count memory occupied with group of processes? 4. How to limit memory use? Whether correctly to kill processes? 5. How to limit use of processor time at absence in ULE separate turns of performance for jails? 6. Whether limits should be inherited at creation jails? etc. -- Menshikov Konstantin From kostjn at peterhost.ru Wed Oct 7 14:47:32 2009 From: kostjn at peterhost.ru (Menshikov Konstantin) Date: Wed Oct 7 14:47:39 2009 Subject: how to make the jail safe for the parent system? In-Reply-To: <4ACC6ABE.9050107@yartv.ru> References: <4ACC6ABE.9050107@yartv.ru> Message-ID: <4ACCAAB7.8010507@peterhost.ru> Andrey Groshev wrote: > Hi, All! > > I understand, what not absolutely normal question, but... > > There is I and my server. > Also there is other person a server responsible for a web. > Periodically he wants that I would instal some software, but in my > representation, this software bad or unnecessary. > I wish to make jail for its and its software. > To give to this person complete access to it, let does all that wants. > But, if in the jail create wrong start scripts, then the parent system > too cannot be started up to the end. > For example: in jail in /etc/rc.local write /bin/sh > And that starts all after this prison will not receive handle. > > Question: how it to avoid? > > Hi. I`m think, that this is bug in /etc/rc.d/jail script. You can fix /etc/rc.d/jail 626 run_rc_command "${cmd}" & 627 sleep 5 instead 626 run_rc_command "${cmd}" This work. From tom at tomjudge.com Wed Oct 7 21:07:45 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Oct 7 21:07:52 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACC60EF.50104@quip.cz> References: <4ACA0549.7030404@tomjudge.com> <4ACBF147.1030002@tomjudge.com> <4ACC60EF.50104@quip.cz> Message-ID: <4ACCFEB1.1010306@tomjudge.com> Miroslav Lachman wrote: > Tom Judge wrote: > >> So I have worked up some thing usable fore us based on the 7.0 code >> from the wiki. >> >> This patch is for 7.1 in implements both soft and hard memory limits. >> >> Details are here: >> http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits >> >> Changes that add supporting infrastructure for cpu limiting are in >> the patch but changes to the schedulers have not been included. If >> you need the scheduling support you will need to patch sched_4bsd >> with the code from the original patch set here: >> >> http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html >> >> Hope this is useful for some people. > > I added links to this thread and to your patch into wiki page > http://wiki.freebsd.org/Jails. I hope it will help people to find your > work. > Do you plan to make it for 7.2 and other future releases? Thanks for adding it to the wiki. It should be simple to apply to 7.2, I can try to knock out a patch in my spare time for this. However at this time I have no plans to take this any further, it seems plenty of people are working on this problem. Maybe one day there will be an in tree solution. Tom From greenx at yartv.ru Thu Oct 8 06:49:24 2009 From: greenx at yartv.ru (Andrey Groshev) Date: Thu Oct 8 06:49:31 2009 Subject: how to make the jail safe for the parent system? In-Reply-To: <4ACCAAB7.8010507@peterhost.ru> References: <4ACC6ABE.9050107@yartv.ru> <4ACCAAB7.8010507@peterhost.ru> Message-ID: <4ACD8B66.5080508@yartv.ru> Hi, About "&" I thought, where it to attach.:) Yes - so works correctly. This bug lies on a surface, PR too I can not find. How you think, can be to write it? Menshikov Konstantin ?????: > Andrey Groshev wrote: >> Hi, All! >> >> I understand, what not absolutely normal question, but... >> >> There is I and my server. >> Also there is other person a server responsible for a web. >> Periodically he wants that I would instal some software, but in my >> representation, this software bad or unnecessary. >> I wish to make jail for its and its software. >> To give to this person complete access to it, let does all that wants. >> But, if in the jail create wrong start scripts, then the parent >> system too cannot be started up to the end. >> For example: in jail in /etc/rc.local write /bin/sh >> And that starts all after this prison will not receive handle. >> >> Question: how it to avoid? >> >> > Hi. > I`m think, that this is bug in /etc/rc.d/jail script. > You can fix /etc/rc.d/jail > 626 run_rc_command "${cmd}" & > 627 sleep 5 > instead > 626 run_rc_command "${cmd}" > This work. > > From freebsd at optiksecurite.com Thu Oct 8 17:58:03 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Thu Oct 8 17:58:09 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update Message-ID: <4ACE2829.6030804@optiksecurite.com> Hi everyone! I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The upgrade went fine on the base system following the procedure written in the announcement email by Ken Smith. My problem is when I try to upgrade my jails, I get this message: # freebsd-update -b /usr/jail/mysql/ fetch install Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 8.0-RC1 from update5.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 8.0-RC1-p0. No updates are available to install. Run '/usr/sbin/freebsd-update fetch' first. But, if I compare the dates of the files in the base system to the files in the jails, it's obvious that the jails are not up to date. It seems like freebsd-update doesn't care about the basedir I specified. Thanks a lot for your help, Martin From hulibyaka at gmail.com Thu Oct 8 18:24:03 2009 From: hulibyaka at gmail.com (hulibyaka hulibyaka) Date: Thu Oct 8 18:24:09 2009 Subject: xorg in jail Message-ID: Hello maillist I've try to setup and run X environment in the jail (FreeBSD-9 Current). xinit with correct xorg.conf for my video card (radeon) get this message: --- (WW) xf86EnableIO: Failed to open /dev/io for extended I/O(EE) No devices detected. Fatal server error: no screens found --- But /dev/io and /dev/mem is exist in my dev for jail (i use this rules in /etc/devfs.rules, thanks to Alexander Leidinger ): --- [devfsrules_unhide_audio=5] add path 'audio*' unhide add path 'dsp*' unhide add path midistat unhide add path 'mixer*' unhide add path 'music*' unhide add path 'sequencer*' unhide add path sndstat unhide add path speaker unhide [devfsrules_unhide_printers=6] add path 'lpt*' unhide add path 'ulpt*' unhide add path 'unlpt*' unhide [devfsrules_unhide_input=7] add path 'atkbd*' unhide add path 'kbd*' unhide add path 'joy*' unhide add path 'psm*' unhide add path sysmouse unhide add path 'ukbd*' unhide add path 'ums*' unhide [devfsrules_unhide_xorg=8] add path agpgart unhide #add path console unhide add path dri unhide add path 'dri*' unhide add path io unhide add path mem unhide #add path pci unhide add path tty unhide add path ttyv0 unhide add path ttyv1 unhide add path ttyv8 unhide [devfsrules_unhide_cam=9] add path 'da*' unhide add path 'cd*' unhide [devfsrules_unhide_kmem=10] add path kmem unhide [devfsrules_jail_desktop=11] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login add include $devfsrules_unhide_audio add include $devfsrules_unhide_input add include $devfsrules_unhide_xorg add include $devfsrules_unhide_cam add include $devfsrules_unhide_kmem --- But X starting successfull when i make: chroot /jail/root_of_jail xinit from outside jail. What the difference for restriction on /dev/io between chroot and jail? How can i get all needed by xinit privileges on /dev/io within jail ? From ltning at anduin.net Thu Oct 8 18:37:42 2009 From: ltning at anduin.net (=?iso-8859-1?Q?Eirik_=D8verby?=) Date: Thu Oct 8 18:37:49 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update In-Reply-To: <4ACE2829.6030804@optiksecurite.com> References: <4ACE2829.6030804@optiksecurite.com> Message-ID: <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> On 8. okt. 2009, at 19.58, Martin Turgeon wrote: > Hi everyone! > > I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The upgrade > went fine on the base system following the procedure written in the > announcement email by Ken Smith. My problem is when I try to upgrade > my > jails, I get this message: > > # freebsd-update -b /usr/jail/mysql/ fetch install > Looking up update.FreeBSD.org mirrors... 3 mirrors found. > Fetching metadata signature for 8.0-RC1 from update5.FreeBSD.org... > done. > Fetching metadata index... done. > Inspecting system... done. > Preparing to download files... done. > > No updates needed to update system to 8.0-RC1-p0. > No updates are available to install. > Run '/usr/sbin/freebsd-update fetch' first. > > But, if I compare the dates of the files in the base system to the > files > in the jails, it's obvious that the jails are not up to date. > > It seems like freebsd-update doesn't care about the basedir I > specified. It does, but if you do a 'uname -a' - inside or outside the jail - you'll see that it reports the OS revision of the host. So you should have updated your jails first, then the host ... One way to get around it is to replace /usr/bin/uname with a shell script, which calls the original uname (which you have renamed) and pipes through something like sed to replace the revision with what you used to have: #!/bin/sh /usr/bin/uname.org $* | sed s/"8.0-RC1-p0"/"7.2-RELEASE_p3"/g And this is a seriously butt ugly hack. /Eirik > Thanks a lot for your help, > > Martin > > _______________________________________________ > 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" > From remodeler at alentogroup.org Thu Oct 8 18:54:49 2009 From: remodeler at alentogroup.org (remodeler) Date: Thu Oct 8 18:54:55 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update Message-ID: <20091008184515.M60887@alentogroup.org> I don't think your /usr/jail/mysql/ root is really a basedir, the way freebsd-update thinks of it. The jail only has world files, not the kernel. There are a number of specialized jail admin tools in ports. Also, the handbook has good information on a manual method to maintain jails, using symlinks and nullfs mounts for security. It uses make installworld with a target to the jail directory. From freebsd at optiksecurite.com Thu Oct 8 19:04:56 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Thu Oct 8 19:05:02 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update In-Reply-To: <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> References: <4ACE2829.6030804@optiksecurite.com> <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> Message-ID: <4ACE37D6.9040908@optiksecurite.com> Eirik ?verby a ?crit : > On 8. okt. 2009, at 19.58, Martin Turgeon wrote: > >> Hi everyone! >> >> I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The upgrade >> went fine on the base system following the procedure written in the >> announcement email by Ken Smith. My problem is when I try to upgrade my >> jails, I get this message: >> >> # freebsd-update -b /usr/jail/mysql/ fetch install >> Looking up update.FreeBSD.org mirrors... 3 mirrors found. >> Fetching metadata signature for 8.0-RC1 from update5.FreeBSD.org... >> done. >> Fetching metadata index... done. >> Inspecting system... done. >> Preparing to download files... done. >> >> No updates needed to update system to 8.0-RC1-p0. >> No updates are available to install. >> Run '/usr/sbin/freebsd-update fetch' first. >> >> But, if I compare the dates of the files in the base system to the files >> in the jails, it's obvious that the jails are not up to date. >> >> It seems like freebsd-update doesn't care about the basedir I specified. > > It does, but if you do a 'uname -a' - inside or outside the jail - > you'll see that it reports the OS revision of the host. So you should > have updated your jails first, then the host ... > Ok but if I update in the process of upgrading the first jail, the new kernel will be installed and asked to reboot. After that, I will have the same problem when upgrading the other jails and the base system, right? There must be something I don't understand well. Thanks a lot for your answer. Martin > One way to get around it is to replace /usr/bin/uname with a shell > script, which calls the original uname (which you have renamed) and > pipes through something like sed to replace the revision with what you > used to have: > > #!/bin/sh > /usr/bin/uname.org $* | sed s/"8.0-RC1-p0"/"7.2-RELEASE_p3"/g > > And this is a seriously butt ugly hack. > > /Eirik > >> Thanks a lot for your help, >> >> Martin >> >> _______________________________________________ >> 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" >> > From ltning at anduin.net Thu Oct 8 19:06:22 2009 From: ltning at anduin.net (=?iso-8859-1?Q?Eirik_=D8verby?=) Date: Thu Oct 8 19:06:29 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update In-Reply-To: <4ACE37D6.9040908@optiksecurite.com> References: <4ACE2829.6030804@optiksecurite.com> <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> <4ACE37D6.9040908@optiksecurite.com> Message-ID: On 8. okt. 2009, at 21.04, Martin Turgeon wrote: > Eirik ?verby a ?crit : >> On 8. okt. 2009, at 19.58, Martin Turgeon wrote: >> >>> Hi everyone! >>> >>> I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The >>> upgrade >>> went fine on the base system following the procedure written in the >>> announcement email by Ken Smith. My problem is when I try to >>> upgrade my >>> jails, I get this message: >>> >>> # freebsd-update -b /usr/jail/mysql/ fetch install >>> Looking up update.FreeBSD.org mirrors... 3 mirrors found. >>> Fetching metadata signature for 8.0-RC1 from >>> update5.FreeBSD.org... done. >>> Fetching metadata index... done. >>> Inspecting system... done. >>> Preparing to download files... done. >>> >>> No updates needed to update system to 8.0-RC1-p0. >>> No updates are available to install. >>> Run '/usr/sbin/freebsd-update fetch' first. >>> >>> But, if I compare the dates of the files in the base system to the >>> files >>> in the jails, it's obvious that the jails are not up to date. >>> >>> It seems like freebsd-update doesn't care about the basedir I >>> specified. >> >> It does, but if you do a 'uname -a' - inside or outside the jail - >> you'll see that it reports the OS revision of the host. So you >> should have updated your jails first, then the host ... >> > Ok but if I update in the process of upgrading the first jail, the > new kernel will be installed and asked to reboot. After that, I will > have the same problem when upgrading the other jails and the base > system, right? There must be something I don't understand well. > Thanks a lot for your answer. The kernel will be installed inside the jail, and the message about rebooting can be safely ignored. Just run the install command once more, and you're done and can move on to the next jail. :) /Eirik > Martin >> One way to get around it is to replace /usr/bin/uname with a shell >> script, which calls the original uname (which you have renamed) and >> pipes through something like sed to replace the revision with what >> you used to have: >> >> #!/bin/sh >> /usr/bin/uname.org $* | sed s/"8.0-RC1-p0"/"7.2-RELEASE_p3"/g >> >> And this is a seriously butt ugly hack. >> >> /Eirik >> >>> Thanks a lot for your help, >>> >>> Martin >>> >>> _______________________________________________ >>> 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 >>> " >>> >> > > > From Alexander at Leidinger.net Fri Oct 9 08:45:37 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Oct 9 08:45:43 2009 Subject: xorg in jail In-Reply-To: References: Message-ID: <20091009104526.12875uad5sybsao0@webmail.leidinger.net> Quoting hulibyaka hulibyaka (from Thu, 8 Oct 2009 22:01:23 +0400): > What the difference for restriction on /dev/io between chroot and > jail? How can i get all needed by xinit privileges on /dev/io within > jail ? There are additional access restrictions in the kernel when run in a jail. You need http://www.leidinger.net/FreeBSD/current-patches/jail.diff and you need to rebuild the kernel and the world. After that you need to add jail_JAILID_startparams="allow.dev_io_access" for your jail startup. Bye, Alexander. -- Pie are not square. Pie are round. Cornbread are square. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From linimon at FreeBSD.org Fri Oct 9 19:44:35 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Oct 9 19:44:41 2009 Subject: kern/139454: [jail] traceroute does not work inside jail Message-ID: <200910091944.n99JiYSC032482@freefall.freebsd.org> Old Synopsis: traceroute does not work inside jail New Synopsis: [jail] traceroute does not work inside jail Responsible-Changed-From-To: freebsd-bugs->freebsd-jail Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 9 19:44:09 UTC 2009 Responsible-Changed-Why: reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=139454 From steinex at nognu.de Fri Oct 9 21:00:14 2009 From: steinex at nognu.de (Frank Steinborn) Date: Fri Oct 9 21:00:21 2009 Subject: misc/139454: traceroute does not work inside jail Message-ID: <200910092100.n99L0EIf092474@freefall.freebsd.org> The following reply was made to PR kern/139454; it has been noted by GNATS. From: Frank Steinborn To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: misc/139454: traceroute does not work inside jail Date: Fri, 9 Oct 2009 22:28:09 +0200 BTW, it works when enumerating the source address with -s. A friend told me that he's seeing the same issue on 7.1 - 6.4 will be tested later tonight and i will follow up with the results (I'm pretty sure it worked there, though). From steinex at nognu.de Fri Oct 9 21:10:15 2009 From: steinex at nognu.de (Frank Steinborn) Date: Fri Oct 9 21:10:21 2009 Subject: misc/139454: traceroute does not work inside jail Message-ID: <200910092110.n99LA5G6000630@freefall.freebsd.org> The following reply was made to PR kern/139454; it has been noted by GNATS. From: Frank Steinborn To: bug-followup@FreeBSD.org Cc: Subject: Re: misc/139454: traceroute does not work inside jail Date: Fri, 9 Oct 2009 22:34:53 +0200 BTW, it works when enumerating the source address with -s. A friend told me that he's seeing the same issue on 7.1 - 6.4 will be tested later tonight and i will follow up with the results (I'm pretty sure it worked there, though). From 000.fbsd at quip.cz Fri Oct 9 22:30:08 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Oct 9 22:30:15 2009 Subject: kern/139454: [jail] traceroute does not work inside jail Message-ID: <200910092230.n99MU7X7069243@freefall.freebsd.org> The following reply was made to PR kern/139454; it has been noted by GNATS. From: Miroslav Lachman <000.fbsd@quip.cz> To: bug-followup@FreeBSD.org, steinex@nognu.de Cc: Subject: Re: kern/139454: [jail] traceroute does not work inside jail Date: Sat, 10 Oct 2009 00:20:36 +0200 I can confirm that traceroute inside jail on 6.3 works, on 7.2 works only with traceroute -s Both machines have security.jail.allow_raw_sockets: 1 From kerbzo at gmail.com Sat Oct 10 08:44:29 2009 From: kerbzo at gmail.com (Kevin Smith) Date: Sat Oct 10 08:45:02 2009 Subject: xorg in jail In-Reply-To: <20091009104526.12875uad5sybsao0@webmail.leidinger.net> References: <20091009104526.12875uad5sybsao0@webmail.leidinger.net> Message-ID: <40670A70-FF15-4B7C-A7CB-5DE04E8EB358@gmail.com> Does this patch fix vnc server start error also ? When I try to run tightvncserver in a jail it says: A VNC server is already running as :0 even if there is no vnc server running. Thank you, regards On Oct 9, 2009, at 10:45 AM, Alexander Leidinger wrote: > Quoting hulibyaka hulibyaka (from Thu, 8 Oct > 2009 22:01:23 +0400): > >> What the difference for restriction on /dev/io between chroot and >> jail? How can i get all needed by xinit privileges on /dev/io within >> jail ? > > There are additional access restrictions in the kernel when run in a > jail. You need > http://www.leidinger.net/FreeBSD/current-patches/jail.diff > and you need to rebuild the kernel and the world. > > After that you need to add > jail_JAILID_startparams="allow.dev_io_access" for your jail startup. > > Bye, > Alexander. > > -- > Pie are not square. Pie are round. Cornbread are square. > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = > B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = > 72077137 > _______________________________________________ > 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" -- Kevin From Alexander at Leidinger.net Sun Oct 11 15:35:43 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Oct 11 15:35:50 2009 Subject: xorg in jail In-Reply-To: <40670A70-FF15-4B7C-A7CB-5DE04E8EB358@gmail.com> References: <20091009104526.12875uad5sybsao0@webmail.leidinger.net> <40670A70-FF15-4B7C-A7CB-5DE04E8EB358@gmail.com> Message-ID: <20091011173533.000018be@unknown> On Sat, 10 Oct 2009 10:14:26 +0200 Kevin Smith wrote: > Does this patch fix vnc server start error also ? I don't know. The patch allows access to /dev/io. Normally this is not possible, even if /dev/io is visible in the jail, as the kernel disallows all access to it from a jail. > When I try to run tightvncserver in a jail it says: > > A VNC server is already running as :0 I wouldn't expect that a VNC server needs access to /dev/io, so I would be surprised if this would help. > even if there is no vnc server running. You could start it via "ktrace -i tightvncserver" and when it abortet you can have a look with kdump|less what it tries to do. Bye, Alexander. > Thank you, > regards > > On Oct 9, 2009, at 10:45 AM, Alexander Leidinger wrote: > > > Quoting hulibyaka hulibyaka (from Thu, 8 Oct > > 2009 22:01:23 +0400): > > > >> What the difference for restriction on /dev/io between chroot and > >> jail? How can i get all needed by xinit privileges on /dev/io > >> within jail ? > > > > There are additional access restrictions in the kernel when run in > > a jail. You need > > http://www.leidinger.net/FreeBSD/current-patches/jail.diff > > and you need to rebuild the kernel and the world. > > > > After that you need to add > > jail_JAILID_startparams="allow.dev_io_access" for your jail startup. > > > > Bye, > > Alexander. > > > > -- > > Pie are not square. Pie are round. Cornbread are square. > > > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = > > B0063FE7 > > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = > > 72077137 > > _______________________________________________ > > 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" > > -- > Kevin > From bz at FreeBSD.org Mon Oct 12 07:09:09 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Mon Oct 12 07:09:14 2009 Subject: kern/139454: [jail] traceroute does not work inside jail Message-ID: <200910120709.n9C798tW099803@freefall.freebsd.org> Synopsis: [jail] traceroute does not work inside jail Responsible-Changed-From-To: freebsd-jail->bz Responsible-Changed-By: bz Responsible-Changed-When: Mon Oct 12 07:08:21 UTC 2009 Responsible-Changed-Why: This could be multi-IP jails fallout though it's more likely that traceroute is doing something silly. http://www.freebsd.org/cgi/query-pr.cgi?pr=139454 From bugmaster at FreeBSD.org Mon Oct 12 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:08:34 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200910121106.n9CB6tbO036451@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 4 problems total. From freebsd at optiksecurite.com Thu Oct 15 17:44:45 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Thu Oct 15 17:44:52 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update In-Reply-To: References: <4ACE2829.6030804@optiksecurite.com> <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> <4ACE37D6.9040908@optiksecurite.com> Message-ID: <4AD75F8B.10906@optiksecurite.com> Eirik ?verby a ?crit : > > On 8. okt. 2009, at 21.04, Martin Turgeon wrote: > >> Eirik ?verby a ?crit : >>> On 8. okt. 2009, at 19.58, Martin Turgeon wrote: >>> >>>> Hi everyone! >>>> >>>> I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The upgrade >>>> went fine on the base system following the procedure written in the >>>> announcement email by Ken Smith. My problem is when I try to >>>> upgrade my >>>> jails, I get this message: >>>> >>>> # freebsd-update -b /usr/jail/mysql/ fetch install >>>> Looking up update.FreeBSD.org mirrors... 3 mirrors found. >>>> Fetching metadata signature for 8.0-RC1 from update5.FreeBSD.org... >>>> done. >>>> Fetching metadata index... done. >>>> Inspecting system... done. >>>> Preparing to download files... done. >>>> >>>> No updates needed to update system to 8.0-RC1-p0. >>>> No updates are available to install. >>>> Run '/usr/sbin/freebsd-update fetch' first. >>>> >>>> But, if I compare the dates of the files in the base system to the >>>> files >>>> in the jails, it's obvious that the jails are not up to date. >>>> >>>> It seems like freebsd-update doesn't care about the basedir I >>>> specified. >>> >>> It does, but if you do a 'uname -a' - inside or outside the jail - >>> you'll see that it reports the OS revision of the host. So you >>> should have updated your jails first, then the host ... >>> >> Ok but if I update in the process of upgrading the first jail, the >> new kernel will be installed and asked to reboot. After that, I will >> have the same problem when upgrading the other jails and the base >> system, right? There must be something I don't understand well. >> Thanks a lot for your answer. > > The kernel will be installed inside the jail, and the message about > rebooting can be safely ignored. Just run the install command once > more, and you're done and can move on to the next jail. :) > > /Eirik > > >> Martin >>> One way to get around it is to replace /usr/bin/uname with a shell >>> script, which calls the original uname (which you have renamed) and >>> pipes through something like sed to replace the revision with what >>> you used to have: >>> >>> #!/bin/sh >>> /usr/bin/uname.org $* | sed s/"8.0-RC1-p0"/"7.2-RELEASE_p3"/g >>> >>> And this is a seriously butt ugly hack. >>> >>> /Eirik >>> >>>> Thanks a lot for your help, >>>> >>>> Martin >>>> >>>> Thanks a lot! It worked great, but I'm still concerned by the fact that the world in the jails are from 8.0 while the kernel is still at 7.2 during the updates of the jails. In the normal update procedure, the kernel is upgraded first, rebooted and then the world is updated. It must have a good reason for this. Why can I jail be an exception to this rule? Martin From ltning at anduin.net Thu Oct 15 18:20:06 2009 From: ltning at anduin.net (=?iso-8859-1?Q?Eirik_=D8verby?=) Date: Thu Oct 15 18:20:13 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update In-Reply-To: <4AD75F8B.10906@optiksecurite.com> References: <4ACE2829.6030804@optiksecurite.com> <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> <4ACE37D6.9040908@optiksecurite.com> <4AD75F8B.10906@optiksecurite.com> Message-ID: On 15. okt. 2009, at 19.44, Martin Turgeon wrote: > Eirik ?verby a ?crit : >> >> On 8. okt. 2009, at 21.04, Martin Turgeon wrote: >> >>> Eirik ?verby a ?crit : >>>> On 8. okt. 2009, at 19.58, Martin Turgeon wrote: >>>> >>>>> Hi everyone! >>>>> >>>>> I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The >>>>> upgrade >>>>> went fine on the base system following the procedure written in >>>>> the >>>>> announcement email by Ken Smith. My problem is when I try to >>>>> upgrade my >>>>> jails, I get this message: >>>>> >>>>> # freebsd-update -b /usr/jail/mysql/ fetch install >>>>> Looking up update.FreeBSD.org mirrors... 3 mirrors found. >>>>> Fetching metadata signature for 8.0-RC1 from >>>>> update5.FreeBSD.org... done. >>>>> Fetching metadata index... done. >>>>> Inspecting system... done. >>>>> Preparing to download files... done. >>>>> >>>>> No updates needed to update system to 8.0-RC1-p0. >>>>> No updates are available to install. >>>>> Run '/usr/sbin/freebsd-update fetch' first. >>>>> >>>>> But, if I compare the dates of the files in the base system to >>>>> the files >>>>> in the jails, it's obvious that the jails are not up to date. >>>>> >>>>> It seems like freebsd-update doesn't care about the basedir I >>>>> specified. >>>> >>>> It does, but if you do a 'uname -a' - inside or outside the jail >>>> - you'll see that it reports the OS revision of the host. So you >>>> should have updated your jails first, then the host ... >>>> >>> Ok but if I update in the process of upgrading the first jail, the >>> new kernel will be installed and asked to reboot. After that, I >>> will have the same problem when upgrading the other jails and the >>> base system, right? There must be something I don't understand >>> well. Thanks a lot for your answer. >> >> The kernel will be installed inside the jail, and the message about >> rebooting can be safely ignored. Just run the install command once >> more, and you're done and can move on to the next jail. :) >> >> /Eirik >> >> >>> Martin >>>> One way to get around it is to replace /usr/bin/uname with a >>>> shell script, which calls the original uname (which you have >>>> renamed) and pipes through something like sed to replace the >>>> revision with what you used to have: >>>> >>>> #!/bin/sh >>>> /usr/bin/uname.org $* | sed s/"8.0-RC1-p0"/"7.2-RELEASE_p3"/g >>>> >>>> And this is a seriously butt ugly hack. >>>> >>>> /Eirik >>>> >>>>> Thanks a lot for your help, >>>>> >>>>> Martin >>>>> >>>>> > Thanks a lot! It worked great, but I'm still concerned by the fact > that the world in the jails are from 8.0 while the kernel is still > at 7.2 during the updates of the jails. In the normal update > procedure, the kernel is upgraded first, rebooted and then the world > is updated. It must have a good reason for this. Why can I jail be > an exception to this rule? Because when you upgrade the host, the very binaries you are installing are being installed by ... the binaries you are installing. Which is why you'll want them to be reasonably in-sync with the kernel. When upgrading jails using freebsd-update, my understanding is that it uses the host binaries to push files to the target directory (basedir). The risk of trouble is therefore very low (I've upgraded dozens of jails from 7.x to 8.0-RC1 without any issues), though I can probably imagine situations where this is not the case - i.e. if the upgrade depends on functionality in an upgraded binary in order to be able to complete the upgrade, however that sounds like a very unlikely scenario to me. And *any* use of the basedir option to freebsd-update would break in such a case. /Eirik From freebsd at optiksecurite.com Thu Oct 15 18:56:55 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Thu Oct 15 18:57:01 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update In-Reply-To: References: <4ACE2829.6030804@optiksecurite.com> <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> <4ACE37D6.9040908@optiksecurite.com> <4AD75F8B.10906@optiksecurite.com> Message-ID: <4AD77075.3010907@optiksecurite.com> Eirik ?verby a ?crit : > > On 15. okt. 2009, at 19.44, Martin Turgeon wrote: > >> Eirik ?verby a ?crit : >>> >>> On 8. okt. 2009, at 21.04, Martin Turgeon wrote: >>> >>>> Eirik ?verby a ?crit : >>>>> On 8. okt. 2009, at 19.58, Martin Turgeon wrote: >>>>> >>>>>> Hi everyone! >>>>>> >>>>>> I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The >>>>>> upgrade >>>>>> went fine on the base system following the procedure written in the >>>>>> announcement email by Ken Smith. My problem is when I try to >>>>>> upgrade my >>>>>> jails, I get this message: >>>>>> >>>>>> # freebsd-update -b /usr/jail/mysql/ fetch install >>>>>> Looking up update.FreeBSD.org mirrors... 3 mirrors found. >>>>>> Fetching metadata signature for 8.0-RC1 from >>>>>> update5.FreeBSD.org... done. >>>>>> Fetching metadata index... done. >>>>>> Inspecting system... done. >>>>>> Preparing to download files... done. >>>>>> >>>>>> No updates needed to update system to 8.0-RC1-p0. >>>>>> No updates are available to install. >>>>>> Run '/usr/sbin/freebsd-update fetch' first. >>>>>> >>>>>> But, if I compare the dates of the files in the base system to >>>>>> the files >>>>>> in the jails, it's obvious that the jails are not up to date. >>>>>> >>>>>> It seems like freebsd-update doesn't care about the basedir I >>>>>> specified. >>>>> >>>>> It does, but if you do a 'uname -a' - inside or outside the jail - >>>>> you'll see that it reports the OS revision of the host. So you >>>>> should have updated your jails first, then the host ... >>>>> >>>> Ok but if I update in the process of upgrading the first jail, the >>>> new kernel will be installed and asked to reboot. After that, I >>>> will have the same problem when upgrading the other jails and the >>>> base system, right? There must be something I don't understand >>>> well. Thanks a lot for your answer. >>> >>> The kernel will be installed inside the jail, and the message about >>> rebooting can be safely ignored. Just run the install command once >>> more, and you're done and can move on to the next jail. :) >>> >>> /Eirik >>> >>> >>>> Martin >>>>> One way to get around it is to replace /usr/bin/uname with a shell >>>>> script, which calls the original uname (which you have renamed) >>>>> and pipes through something like sed to replace the revision with >>>>> what you used to have: >>>>> >>>>> #!/bin/sh >>>>> /usr/bin/uname.org $* | sed s/"8.0-RC1-p0"/"7.2-RELEASE_p3"/g >>>>> >>>>> And this is a seriously butt ugly hack. >>>>> >>>>> /Eirik >>>>> >>>>>> Thanks a lot for your help, >>>>>> >>>>>> Martin >>>>>> >>>>>> >> Thanks a lot! It worked great, but I'm still concerned by the fact >> that the world in the jails are from 8.0 while the kernel is still at >> 7.2 during the updates of the jails. In the normal update procedure, >> the kernel is upgraded first, rebooted and then the world is updated. >> It must have a good reason for this. Why can I jail be an exception >> to this rule? > > Because when you upgrade the host, the very binaries you are > installing are being installed by ... the binaries you are installing. > Which is why you'll want them to be reasonably in-sync with the kernel. > > When upgrading jails using freebsd-update, my understanding is that it > uses the host binaries to push files to the target directory > (basedir). The risk of trouble is therefore very low (I've upgraded > dozens of jails from 7.x to 8.0-RC1 without any issues), though I can > probably imagine situations where this is not the case - i.e. if the > upgrade depends on functionality in an upgraded binary in order to be > able to complete the upgrade, however that sounds like a very unlikely > scenario to me. And *any* use of the basedir option to freebsd-update > would break in such a case. > > /Eirik > Sounds reasonable to me. Thanks for your quick reply. Martin From ltning at anduin.net Thu Oct 15 18:58:40 2009 From: ltning at anduin.net (=?iso-8859-1?Q?Eirik_=D8verby?=) Date: Thu Oct 15 18:58:46 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update In-Reply-To: <4AD77075.3010907@optiksecurite.com> References: <4ACE2829.6030804@optiksecurite.com> <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> <4ACE37D6.9040908@optiksecurite.com> <4AD75F8B.10906@optiksecurite.com> <4AD77075.3010907@optiksecurite.com> Message-ID: On 15. okt. 2009, at 20.56, Martin Turgeon wrote: > Eirik ?verby a ?crit : >> >> On 15. okt. 2009, at 19.44, Martin Turgeon wrote: >> >>> Eirik ?verby a ?crit : >>>> >>>> On 8. okt. 2009, at 21.04, Martin Turgeon wrote: >>>> >>>>> Eirik ?verby a ?crit : >>>>>> On 8. okt. 2009, at 19.58, Martin Turgeon wrote: >>>>>> >>>>>>> Hi everyone! >>>>>>> >>>>>>> I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The >>>>>>> upgrade >>>>>>> went fine on the base system following the procedure written >>>>>>> in the >>>>>>> announcement email by Ken Smith. My problem is when I try to >>>>>>> upgrade my >>>>>>> jails, I get this message: >>>>>>> >>>>>>> # freebsd-update -b /usr/jail/mysql/ fetch install >>>>>>> Looking up update.FreeBSD.org mirrors... 3 mirrors found. >>>>>>> Fetching metadata signature for 8.0-RC1 from >>>>>>> update5.FreeBSD.org... done. >>>>>>> Fetching metadata index... done. >>>>>>> Inspecting system... done. >>>>>>> Preparing to download files... done. >>>>>>> >>>>>>> No updates needed to update system to 8.0-RC1-p0. >>>>>>> No updates are available to install. >>>>>>> Run '/usr/sbin/freebsd-update fetch' first. >>>>>>> >>>>>>> But, if I compare the dates of the files in the base system to >>>>>>> the files >>>>>>> in the jails, it's obvious that the jails are not up to date. >>>>>>> >>>>>>> It seems like freebsd-update doesn't care about the basedir I >>>>>>> specified. >>>>>> >>>>>> It does, but if you do a 'uname -a' - inside or outside the >>>>>> jail - you'll see that it reports the OS revision of the host. >>>>>> So you should have updated your jails first, then the host ... >>>>>> >>>>> Ok but if I update in the process of upgrading the first jail, >>>>> the new kernel will be installed and asked to reboot. After >>>>> that, I will have the same problem when upgrading the other >>>>> jails and the base system, right? There must be something I >>>>> don't understand well. Thanks a lot for your answer. >>>> >>>> The kernel will be installed inside the jail, and the message >>>> about rebooting can be safely ignored. Just run the install >>>> command once more, and you're done and can move on to the next >>>> jail. :) >>>> >>>> /Eirik >>>> >>>> >>>>> Martin >>>>>> One way to get around it is to replace /usr/bin/uname with a >>>>>> shell script, which calls the original uname (which you have >>>>>> renamed) and pipes through something like sed to replace the >>>>>> revision with what you used to have: >>>>>> >>>>>> #!/bin/sh >>>>>> /usr/bin/uname.org $* | sed s/"8.0-RC1-p0"/"7.2-RELEASE_p3"/g >>>>>> >>>>>> And this is a seriously butt ugly hack. >>>>>> >>>>>> /Eirik >>>>>> >>>>>>> Thanks a lot for your help, >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> >>> Thanks a lot! It worked great, but I'm still concerned by the fact >>> that the world in the jails are from 8.0 while the kernel is still >>> at 7.2 during the updates of the jails. In the normal update >>> procedure, the kernel is upgraded first, rebooted and then the >>> world is updated. It must have a good reason for this. Why can I >>> jail be an exception to this rule? >> >> Because when you upgrade the host, the very binaries you are >> installing are being installed by ... the binaries you are >> installing. Which is why you'll want them to be reasonably in-sync >> with the kernel. >> >> When upgrading jails using freebsd-update, my understanding is that >> it uses the host binaries to push files to the target directory >> (basedir). The risk of trouble is therefore very low (I've upgraded >> dozens of jails from 7.x to 8.0-RC1 without any issues), though I >> can probably imagine situations where this is not the case - i.e. >> if the upgrade depends on functionality in an upgraded binary in >> order to be able to complete the upgrade, however that sounds like >> a very unlikely scenario to me. And *any* use of the basedir option >> to freebsd-update would break in such a case. >> >> /Eirik >> > Sounds reasonable to me. Thanks for your quick reply. Reasonable != true. And for that matter, reasonable != reasonable. YMMV etc. etc. I haven't peeked (much) into the code, so I'm just guessing from my experiences. ;) People in the know should correct me if I'm wrong.. /Eirik From freebsd at optiksecurite.com Thu Oct 15 19:17:20 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Thu Oct 15 19:17:26 2009 Subject: Can't upgrade jails to 8.0 using freebsd-update In-Reply-To: References: <4ACE2829.6030804@optiksecurite.com> <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> <4ACE37D6.9040908@optiksecurite.com> <4AD75F8B.10906@optiksecurite.com> <4AD77075.3010907@optiksecurite.com> Message-ID: <4AD77352.5080908@optiksecurite.com> Eirik ?verby a ?crit : > > On 15. okt. 2009, at 20.56, Martin Turgeon wrote: > >> Eirik ?verby a ?crit : >>> >>> On 15. okt. 2009, at 19.44, Martin Turgeon wrote: >>> >>>> Eirik ?verby a ?crit : >>>>> >>>>> On 8. okt. 2009, at 21.04, Martin Turgeon wrote: >>>>> >>>>>> Eirik ?verby a ?crit : >>>>>>> On 8. okt. 2009, at 19.58, Martin Turgeon wrote: >>>>>>> >>>>>>>> Hi everyone! >>>>>>>> >>>>>>>> I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The >>>>>>>> upgrade >>>>>>>> went fine on the base system following the procedure written in >>>>>>>> the >>>>>>>> announcement email by Ken Smith. My problem is when I try to >>>>>>>> upgrade my >>>>>>>> jails, I get this message: >>>>>>>> >>>>>>>> # freebsd-update -b /usr/jail/mysql/ fetch install >>>>>>>> Looking up update.FreeBSD.org mirrors... 3 mirrors found. >>>>>>>> Fetching metadata signature for 8.0-RC1 from >>>>>>>> update5.FreeBSD.org... done. >>>>>>>> Fetching metadata index... done. >>>>>>>> Inspecting system... done. >>>>>>>> Preparing to download files... done. >>>>>>>> >>>>>>>> No updates needed to update system to 8.0-RC1-p0. >>>>>>>> No updates are available to install. >>>>>>>> Run '/usr/sbin/freebsd-update fetch' first. >>>>>>>> >>>>>>>> But, if I compare the dates of the files in the base system to >>>>>>>> the files >>>>>>>> in the jails, it's obvious that the jails are not up to date. >>>>>>>> >>>>>>>> It seems like freebsd-update doesn't care about the basedir I >>>>>>>> specified. >>>>>>> >>>>>>> It does, but if you do a 'uname -a' - inside or outside the jail >>>>>>> - you'll see that it reports the OS revision of the host. So you >>>>>>> should have updated your jails first, then the host ... >>>>>>> >>>>>> Ok but if I update in the process of upgrading the first jail, >>>>>> the new kernel will be installed and asked to reboot. After that, >>>>>> I will have the same problem when upgrading the other jails and >>>>>> the base system, right? There must be something I don't >>>>>> understand well. Thanks a lot for your answer. >>>>> >>>>> The kernel will be installed inside the jail, and the message >>>>> about rebooting can be safely ignored. Just run the install >>>>> command once more, and you're done and can move on to the next >>>>> jail. :) >>>>> >>>>> /Eirik >>>>> >>>>> >>>>>> Martin >>>>>>> One way to get around it is to replace /usr/bin/uname with a >>>>>>> shell script, which calls the original uname (which you have >>>>>>> renamed) and pipes through something like sed to replace the >>>>>>> revision with what you used to have: >>>>>>> >>>>>>> #!/bin/sh >>>>>>> /usr/bin/uname.org $* | sed s/"8.0-RC1-p0"/"7.2-RELEASE_p3"/g >>>>>>> >>>>>>> And this is a seriously butt ugly hack. >>>>>>> >>>>>>> /Eirik >>>>>>> >>>>>>>> Thanks a lot for your help, >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> >>>> Thanks a lot! It worked great, but I'm still concerned by the fact >>>> that the world in the jails are from 8.0 while the kernel is still >>>> at 7.2 during the updates of the jails. In the normal update >>>> procedure, the kernel is upgraded first, rebooted and then the >>>> world is updated. It must have a good reason for this. Why can I >>>> jail be an exception to this rule? >>> >>> Because when you upgrade the host, the very binaries you are >>> installing are being installed by ... the binaries you are >>> installing. Which is why you'll want them to be reasonably in-sync >>> with the kernel. >>> >>> When upgrading jails using freebsd-update, my understanding is that >>> it uses the host binaries to push files to the target directory >>> (basedir). The risk of trouble is therefore very low (I've upgraded >>> dozens of jails from 7.x to 8.0-RC1 without any issues), though I >>> can probably imagine situations where this is not the case - i.e. if >>> the upgrade depends on functionality in an upgraded binary in order >>> to be able to complete the upgrade, however that sounds like a very >>> unlikely scenario to me. And *any* use of the basedir option to >>> freebsd-update would break in such a case. >>> >>> /Eirik >>> >> Sounds reasonable to me. Thanks for your quick reply. > > Reasonable != true. And for that matter, reasonable != reasonable. > YMMV etc. etc. I haven't peeked (much) into the code, so I'm just > guessing from my experiences. ;) > > People in the know should correct me if I'm wrong.. > > /Eirik I must admit that I was looking for a confirmation... ;) I thought it was a problem a lot of people would have faced... Martin From tommyhp2 at yahoo.com Sat Oct 17 11:09:38 2009 From: tommyhp2 at yahoo.com (Tommy Pham) Date: Sat Oct 17 11:09:44 2009 Subject: Understand the internals of FreeBSD Message-ID: <510798.22136.qm@web38206.mail.mud.yahoo.com> Hi everyone, What do you all recommend for a better understanding of the FreeBSD's internals & jail system? Should I review C, C++ or both before reading the source code? It's been over a decade since I code in C/C++ and that was in college doing old school structured programming languages. :D Thanks, Tommy From bugmaster at FreeBSD.org Mon Oct 19 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:08:41 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200910191106.n9JB6uhM063489@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 4 problems total. From bzeeb-lists at lists.zabbadoz.net Wed Oct 21 22:35:09 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Oct 21 22:35:16 2009 Subject: Setting the jail identifier from /etc/rc.conf In-Reply-To: <20091021222054.GJ1293@hoeg.nl> References: <20091021222054.GJ1293@hoeg.nl> Message-ID: <20091021222851.O91695@maildrop.int.zabbadoz.net> On Thu, 22 Oct 2009, Ed Schouten wrote: > Hi, > > I haven't played with Jails for a long time, but I wanted to figure out > how hard it is to make init spawn getties for certain jails. It > shouldn't be too hard (jexec foo /usr/libexec/getty), but I can't seem > to find a way to set the jid to a certain value from within rc.conf. > > It also seems jids cannot contain dots, which means I cannot set the jid > equal to the hostname of the jail. > > Maybe a Jail hacker can give me some advice here? Wouldn't it be more > sane if the kernel just used the hostname as an identifier if there is > no jail with the same hostname yet? Or maybe we should at least provide > a config tunable for this? Redirect to freebsd-jail@ ; you may even find the answers to those int he mail archive (unless those had been private threads I was on Cc: on;-) -- Bjoern A. Zeeb It will not break if you know what you are doing. From ed at 80386.nl Thu Oct 22 12:08:18 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Oct 22 12:08:24 2009 Subject: Setting the jail identifier from /etc/rc.conf In-Reply-To: <86ljj4s6hj.fsf@ds4.des.no> References: <20091021222054.GJ1293@hoeg.nl> <86ljj4s6hj.fsf@ds4.des.no> Message-ID: <20091022120816.GK1293@hoeg.nl> Hi Dag-Erling, * Dag-Erling Sm?rgrav wrote: > on the command line). There is no rc.conf variable for it, but you can > add "-n foo" to jail_foo_flags. Well, good enough I guess. I solved the entire getty thing by doing the following. I'm running a jail called small.80386.nl, which is a temporary install I had, to see what happens if you enable a lot of WITHOUT_* flags. /etc/devfs.rules: | [small_80386_nl=5] | add include $devfsrules_hide_all | add include $devfsrules_unhide_basic | add include $devfsrules_unhide_login | add path ttyv8 unhide /etc/rc.conf: | jail_small_flags="-l -U root -n small_80386_nl" | jail_small_devfs_ruleset="small_80386_nl" /etc/ttys: | ttyv8 "/usr/sbin/jexec small_80386_nl /usr/libexec/getty Pc" cons25 on secure -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-jail/attachments/20091022/5921abf3/attachment.pgp From coco at executive-computing.de Sun Oct 25 04:11:15 2009 From: coco at executive-computing.de (Marco Steinbach) Date: Sun Oct 25 04:11:23 2009 Subject: Understand the internals of FreeBSD In-Reply-To: <510798.22136.qm@web38206.mail.mud.yahoo.com> References: <510798.22136.qm@web38206.mail.mud.yahoo.com> Message-ID: <4AE3CFDD.1080302@executive-computing.de> Tommy Pham schrieb: > Hi everyone, > > What do you all recommend for a better understanding of the FreeBSD's internals & jail system? Should I review C, C++ or both before reading the source code? It's been over a decade since I code in C/C++ and that was in college doing old school structured programming languages. :D "The Design and Implementation of the FreeBSD Operating System" (ISBN 978-0201702453) was a good starting point for me. As for understanding the internals of the jail mechanism in detail, you will need to familiarize yourself with at least parts of the source of the system. The man pages (apropos jail) will provide some entry points. There is an introductory paper written by Poul-Henning Kamp and Robert N.M. Watson available at http://phk.freebsd.dk/pubs/sane2000-jail.pdf, which might help you getting started. Other documents at http://phk.freebsd.dk/pubs/ might be of interest, also. MfG CoCo From bugmaster at FreeBSD.org Mon Oct 26 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:08:38 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200910261107.n9QB71Nt043806@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 4 problems total. From notification at bankofamerica.com Tue Oct 27 07:34:37 2009 From: notification at bankofamerica.com (Bank of America) Date: Tue Oct 27 07:34:43 2009 Subject: Security Notification Message-ID: <20091026235131.3E50DE753B98A8E4@bankofamerica.com> Dear Bank of America Customer, freebsd-jail@freebsd.org As part of our security measures, we regularly screen activity in the Bank of America system. We recently contacted you after noticing an issue on your account. We requested information from you for the following reason: We recently received a report of unauthorized credit card use associated with this account. As a precaution, we have limited access to your Bank of America account in order to protect against future unauthorized transactions. Case ID Number: BOA-531-472-560 This is a reminder to restore your account as soon as possible. Please download the form attached to this email and open it in a web browser. Once opened, you will be provided with steps to restore your account access. We appreciate your understanding as we work to ensure account safety. In accordance with Bank of America's Customer Agreement, your account access will remain limited until the issue has been resolved. Unfortunately, if access to your account remains limited for an extended period of time, it may result in further limitations or eventual account closure. We encourage you to restore your Bank of America account as soon as possible to help avoid this. We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account. We apologize for any inconvenience. Sincerely, Bank of America Security Center -------------- next part -------------- A non-text attachment was scrubbed... Name: Restore_your_Online_Banking_account.html Type: application/octet-stream Size: 3786 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-jail/attachments/20091027/06fd04ab/Restore_your_Online_Banking_account.obj From 000.fbsd at quip.cz Tue Oct 27 18:41:34 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue Oct 27 18:41:41 2009 Subject: Jails creation In-Reply-To: <4AE728F8.7020809@interazioni.it> References: <4AE6C7BD.907@interazioni.it> <4AE7232E.2070208@quip.cz> <4AE728F8.7020809@interazioni.it> Message-ID: <4AE73ED9.5000505@quip.cz> Tonix (Antonio Nati) wrote: > Miroslav Lachman ha scritto: [...] >> You are not the first one with this idea. You can easily use nullfs >> mount of directories from base system, but people mostly prefer >> independent directory with jail install shared by many jails. >> >> And sometimes somebody needs jails with modified binaries, so it is >> not possible to share theme with base system in all cases. >> >> There are many ways to get jails running without sources, it is up to >> you to choose one. [...] > I have nothing against shared dirs, but my question is this: why the > basic jail creation command requires compilation? Given the fact jail > must have exactly the same version of base system, why the base create > command dos not simply copy the existing binaries? It would avoid local > source, remote packages, etc... It is not true. Jail command does not requires compilation, nor exactly same version. I am running 6.x version jail on system with 7.2 and you can run 32bit (i386) jail on 64bit (amd64) system. The `jail` command is there just for starting the jail, not for building it. The jail even does not need to be a full installed system! There are too many different scenarios with jails, that there can not be "one command to satisfy them all". It is up to administrator to prepare the best environment for his/her needs. If you need the full copy of the base system, you can do it really easily (by tar as was suggested by Vincet Hoffman or dump & restore), and if you do it for each jail, you loose the benefits of shared read-only base directory (you will need more disk space and more memory). If you do not want to spend some time by compilation, you can install the jail from installation media you already have from system install. cd /some/media/7.2-RELEASE/base mkdir /path/to/myjail setenv DESTDIR /path/to/myjail sh install.sh That's all! It is too simple in contrast to source build or manually copy something from base. If you are using ZFS, you can use snapshots and clones... And many more scenarios exist. I am CCing freebsd-jail@, it is more appropriate list to contionue. Miroslav Lachman From remodeler at alentogroup.org Fri Oct 30 04:13:11 2009 From: remodeler at alentogroup.org (remodeler) Date: Fri Oct 30 04:13:18 2009 Subject: Security of syslog socket in vnet jail? Message-ID: <20091030041848.M5504@alentogroup.org> I wonder if anyone has an opinion on the security implications of opening syslog sockets in a vnet jail, vs. using a remote logging host. The jail does not otherwise allow unix sockets. The /var/run/log and /var/run/logpriv sockets would be provided by the host syslogd, using -l option. The alternative would have syslogd running in its own vnet jail as a logging host. Thank you.