Re: starting jails in the background & dependencies
B0;251;0cOn 2010.01.14 13:35:16 +0100, Alexander Leidinger wrote:
> Quoting Remko Lodder (from Tue, 5 Jan 2010
> 11:35:48 +0100):
>
> > On Tue, January 5, 2010 11:24 am, Alexander Leidinger wrote:
> >> On Mon, 07 Dec 2009 08:03:53 +0100 Alexander Leidinger
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> now that jails are started in the background (which is good, to
> >>
> >> I just realized yesterday that it also stops in parallel (in the
> >> background). This is bad. It may be the case that a jail is not fully
> >> stopped via the rc scripts when the OS decides to kill the remaining
> >> processes during a shutdown.
> >>
> >> My first reaction is to only allow to start in the background, but
> >> everything else needs to be serialized.
> >>
> >> Any objections or better ideas out there?
>
> > I think the best way at this moment is to revert the change ( I can do
> > that , or someone else, I dont mind ) and think of a better concept. Simon
> > also mentioned that he didn't like the current way of doing things, so I
> > kept it in, for possible suggestions. Reverting the change would mean that
> > the old behaviour at least works and is with what people are used to. We
> > can then further improve it where needed.
>
> What about the following? Just have a look at the principle, I haven't
> tested it yet. What it does is:
> - revert back to serial startup by default
> - allow to only start in the background (jail_parallel_start=YES)
In some thread there was talk about parallel stop as well, but I must
admit I never looked at it.
> - take input from /dev/null: in case a start script inside the
> jail wants to read from stdin (it shouldn't), it will not
> switch the process into STOP state (but should generate some
> message in the application log)
This seems like a fine change - especially since the output from the
actual jail is hidden.
> Copy&paste, so maybe messed up tabs:
The bottom part of rc.d/jail after the patch seems well, "messy"
in lack of a better word, but since I can't come up with a better
solution right now I think this patch should be committed, and then we
can always improve the implementation later.
Note that I haven't tsted it, but I don't see any errors in the patch.
> ---snip---
> Index: share/man/man5/rc.conf.5
> ===
> --- share/man/man5/rc.conf.5(Revision 202277)
> +++ share/man/man5/rc.conf.5(Arbeitskopie)
> @@ -24,7 +24,7 @@
> .\"
> .\" $FreeBSD$
> .\"
> -.Dd November 11, 2009
> +.Dd January 14, 2010
> .Dt RC.CONF 5
> .Os
> .Sh NAME
> @@ -3472,6 +3472,11 @@
> If set to
> .Dq Li NO ,
> any configured jails will not be started.
> +.It jail_parallel_start
> +.Pq Vt bool
> +If set to
> +.Dq Li YES
> +all configured jails will be started in the background (= in parallel).
> .It Va jail_list
> .Pq Vt str
> A space separated list of names for jails.
> Index: etc/rc.d/jail
> ===
> --- etc/rc.d/jail (Revision 202277)
> +++ etc/rc.d/jail (Arbeitskopie)
> @@ -636,7 +636,8 @@
> done
>
> eval ${_setfib} jail ${_flags} -i ${_rootdir} ${_hostname} \
> - \"${_addrl}\" ${_exec_start} > ${_tmp_jail} 2>&1
> + \"${_addrl}\" ${_exec_start} > ${_tmp_jail} 2>&1 \
> +
> if [ "$?" -eq 0 ] ; then
> _jail_id=$(head -1 ${_tmp_jail})
> @@ -728,4 +729,19 @@
> if [ -n "$*" ]; then
> jail_list="$*"
> fi
> -run_rc_command "${cmd}" &
> +
> +# Only allow the parallel start of jails, other commands are not
> +# safe to execute in parallel.
> +case "${cmd}" in
> +*start)
> + ;;
> +*)
> + jail_parallel_start=NO
> +esac
> +
> +if checkyesno jail_parallel_start; then
> + run_rc_command "${cmd}" &
> +else
> + run_rc_command "${cmd}"
> +fi
> +
> Index: etc/defaults/rc.conf
> ===
> --- etc/defaults/rc.conf(Revision 202277)
> +++ etc/defaults/rc.conf(Arbeitskopie)
> @@ -630,6 +630,7 @@
> ### Jail Configuration ###
> ##
> jail_enable="NO" # Set to NO to disable starting of any jails
> +jail_parallel_start="NO" # Start jails in the background
> jail_list="" # Space separated list of names of jails
> jail_set_hostname_allow="YES" # Allow root user in a jail to change
> its hostname
> jail_socket_unixiproute_only="YES" # Route only TCP/IP within a jail
> ---snip---
--
Simon L. Nielsen
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Best practice to update jails
[Don't cc virtualization - no reason for cross post] On 2009.08.20 22:10:36 +0200, Redd Vinylene wrote: > On Thu, Aug 20, 2009 at 8:50 PM, Jose Amengual wrote: > > > I have a dev server for our developers that holds around 40 jails, each > > jail has php, mysql, python etc. > > > > The server is now 7.0 and was wondering what is the best practice to > > maintain security patches and kernel updates and I came out with the > > following idea : > > > > 1.- freebsd-update fetch install ( host system) > > 2.- rebuild kernel ( I have a custom kernel ) > > 3.- ezjail-update -b ( update basejail for all jails ) > > 4.- run in cron portaudit on the jails for thirty party security updates > > 5.- run portupgrade in case of a security update or for apps upgrade on the > > jails. > > > > I red in some forums that if you run freebsd-update you will need to do a > > portuprade -fa to reinstall all the thirty party apps because freebsd-update > > could upgrade or remove some libraries linked to that programs, is this > > true ?, will be better to run a cvsup and instead ? There is no difference wrt. ports on freebsd-update and make world. For major versions you need to recompile all ports, for minor versions you don't. Personally I use ezjail to manage a similar development setup, and I recently upgraded 7.1 -> 7.2 using 'ezjail-admin install' (or something like that). I quite often upgrade the host system and wait with the jails so you don't have to do it all in one go (though it might be simpler in). Other people mention that "most people" use use based solutions - I'm far from sure about that, at least unless you are running a modified FreeBSD or not -RELEASE, there is generally not any reason to compile it all yourself. > here's how I do it, hope it helps: http://pastie.org/590295 This does make installworld into the jail from the host - it should be mentioned that you should never do this if you use the jails for security isolation as the jail root would likely be able to perform a symlink attack. I haven't every actually looked at how it could be done, but installworld isn't make to be "secure" against such things. -- Simon L. Nielsen ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: [RFC] Skeleton jail (rc.d feature proposal)
On 2009.02.10 19:24:22 -0800, Xin LI wrote: > Ok, some local users has prodded me in committing the "skeleton jail" > feature, I find it useful myself but not sure if it's appropriate to > commit it against -HEAD, so I'd like to explain it, try to present it in This complicates an already complicated etc/rc.d/jail script so I think this is a very bad idea. rc.d/jail is already interesting enough security wise as it is IMO. If anyone wants this very much think it should be done in an "external" (to etc/rc.d/jail) jail management system/script. Personally I have been very happy with ezjail, and I think having a script like that "externally" is a much better way to go. If that means importing ezjail or making something like it I don't know. -- Simon L. Nielsen ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: cvs commit: src/etc/rc.d jail src/share/man/man5 rc.conf.5
[Trying to moving off commit lists] On 2008.09.25 09:20:04 +0400, Ruslan Ermilov wrote: > Hi Bjoern, > > On Wed, Sep 24, 2008 at 06:34:53PM +, Bjoern A. Zeeb wrote: > > On Wed, 24 Sep 2008, Ruslan Ermilov wrote: > > > > > ru 2008-09-24 15:18:27 UTC > > > > > > FreeBSD src repository > > > > > > Modified files: > > >etc/rc.d jail > > >share/man/man5 rc.conf.5 > > > Log: > > > SVN rev 183325 on 2008-09-24 15:18:27Z by ru > > > > > > Allow a jail's IP alias to be created with an arbitrary netmask. > > > > So I had been talking with various people during the last weeks/months > > about this feature of configuring an interface from rc.d/jail and I > > had been >< close to remove it a lot of times but it seems people > > prefer to actually mix network configuration, management and jail > > startup/teardown in a single script, which I think is a very > > questionable thing especially considering that we already had an > > SA for[1] that script for other means. > > > At work, we use ezjail as a management tool for jails. We want our [...] I think the main problem is that the configuration required for jails "today" is simply too much for what should be done in an rc.d script configured by rc.conf. At the Cambridge Devsummit we talked about creating some kind of more advanced jail management system and I think that is the way to go in the long run and kill off rc.d/jail. Of course doing this is no small task, but I think adding kludges to rc.conf is going to be increasingly painful. I'm not sure what form a management system should take, but having ezjail like functionality in base would be a good thing IMO. Personally I also have a rather strong dislike for the jail auto ip setting feature, but as people are using it removing the functionality will cause pain. -- Simon L. Nielsen ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: conf/124248: [patch] add support for nice value for rc.d/jail + rc.conf
On 2008.09.01 23:30:33 +0200, Miroslav Lachman wrote: > [EMAIL PROTECTED] wrote: > > Old Synopsis: adds support for nice value for rc.d/jail + rc.conf > > New Synopsis: [patch] add support for nice value for rc.d/jail + rc.conf > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-rc > > Responsible-Changed-By: linimon > > Responsible-Changed-When: Tue Jun 3 21:38:18 UTC 2008 > > Responsible-Changed-Why: > > Over to maintainer(s). > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=124248 > > Is there any chance to have it in FreeBSD 7.1 RELEASE? As the patch hasn't been commited yet to -CURRENT, having it in 7.1 is somewhat unlikely. Somebody need to take an interest first... -- Simon L. Nielsen ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new multi-/no-ip4/v6 jail patches
On 2008.07.27 17:48:26 +, Bjoern A. Zeeb wrote: > On Sun, 27 Jul 2008, Bjoern A. Zeeb wrote: > >> On Sun, 27 Jul 2008, Bjoern A. Zeeb wrote: >> >> Hi, >> >> there is a regression in there with unbound udp connects. I am >> investigating and the patches are gone for the moment. I'll let you >> know once I updated them. > > the new patches are here: > > HEAD: http://people.freebsd.org/~bz/bz_jail-20080727-10-at146056.diff > 7-STABLE: http://people.freebsd.org/~bz/bz_jail7-20080727-10-at146056.diff This patch has been running since without problems on sky.FreeBSD.org (which hosts the FreeBSD wiki and more): 6:07PM up 5 days, 49 mins, 1 user, load averages: 0.00, 0.05, 0.07 -- Simon L. Nielsen ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
