Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Feb 2017 18:01:24 -0500
From:      Ernie Luzar <luzar722@gmail.com>
To:        Jeff Kletsky <freebsd@wagsky.com>
Cc:        freebsd-jail@freebsd.org
Subject:   Re: Using jail.conf array parameters in exec.* commands
Message-ID:  <58A780C4.6030503@gmail.com>
In-Reply-To: <5c11e326-cd4b-73e1-a681-9d116a0c1cd3@wagsky.com>
References:  <b54f6576-7627-f3c3-70b0-b2c9c54a4fd6@wagsky.com> <58A42DC7.5040702@gmail.com> <5c11e326-cd4b-73e1-a681-9d116a0c1cd3@wagsky.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Jeff Kletsky wrote:
> Thanks for the suggestion of trying to use 'ifconfig interface vnet jail'
> in the scripts themselves.
> 
> I'll get my scripts up once I've got them running again confidently
> and can get proper licensing on them.
> 
> TL;DR
> 
> * Is there a clean way to "catch" failures in jail(8) creation after
>   exec.prestart completes, such as vnet.interface failing?
> 
> * Is there a good way to execute commands in the host environment once
>   jail(8) brings up the jail, but before exec.start runs?
> 
> 
> 
> The rest:
> 
> I've been thinking about that for a while, especially as there isn't a
> way to "catch" an execution error in jail(8) itself, such as the vnet
> transition failing. (Yes, I'll open an issue on that once I'm convinced
> I can't do it with the current jail functionality.)
> 
> To be able to call 'ifconfig interface vnet jail' the jail needs to
> exist already:
> 
>     # ifconfig ngeth3 vnet t2
>     ifconfig: jail "t2" not found
> 
> Further, the network needs to be up and running when services are
> started. ntpd, anything that binds to a specific interface (rather
> than *), anything that needs DNS (such as nginx providing proxy
> services), ...
> 
> 
> jail(8) tells me I have the following hooks available
> 
>     exec.prestart  -- jail isn't created yet
>     exec.start     -- runs *in* the jail; typically starts execution
>     exec.poststart -- runs in the host, after exec.start completes
> 
> There isn't a "jail up, but not executing yet" hook in the host
> environment that I am aware of.
> 
> There is a somewhat ugly approach along the lines of:
> 
>     exec.prestart  -- do the setup on the host side
>     exec.start     -- '/bin/true' or 'return 0'-- don't do anything
>     exec.poststart -- 'ifconfig interface vnet jail'-like things
>                       'jexec jail sh /etc/rc > ${exec.consolelog}'
> 
> 
> Is there a better approach that someone out there knows of?
> 
> 
> Thanks!
> 
> Jeff
> 

Lets make this simple. Do not use the "service jail jailname start" 
command to start / stop your jails. Your mixing legacy rc.conf jail 
method with jail.conf method. All ways use the jail(8) command itself to 
start/stop your jails.

If you do this in a script then you can check the jail resulting return 
code to determine if the jail start/stop failed. But there is no 
information to tell you why it failed. In all most all cases it's caused 
by jail.conf parameters syntax coding error or invalid value content. 
Really pretty simple to determine cause by looking at the jail.conf 
content for the offending vnet jail.

Change your mind set from thinking you have to use the exec.* hooks to 
configure the vnet jails netgraph network setup.

Just have individual jail.conf files for each vnet jail with no vnet 
interface defined.

Now you can start the jail with just the standard exec.start line and 
standard exec.stop line. Once your script has issued the jail(8) command 
to start the jail then follow it with all the netgraph commands to 
enable its network. The vnet jail it self has no knowledge of any 
network connectivity at start up, you can wrap either bridge/epair or 
netgraph around it and it don't care.

This was learned the hard way.










Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58A780C4.6030503>