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. _______________________________________________ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
