On Apr 14, 2012, at 2:19 PM, Mark Felder wrote:

> On Sat, 14 Apr 2012 14:59:47 -0500, <fb...@a1poweruser.com> wrote:
>> 
>> I don't see any v2 in the jail environment. Vimage is a separate software 
>> module that is not part of the the system base release. It has to be 
>> compiled into a custom kernel to be enabled and it's labeled as 
>> experimental, "use at your own risk". Not some thing I would want in my jail 
>> environment. So the bottom line is there is no version 2 of the jail 
>> environment,(IE changes to the jail command and its associate commands).
>> 
> 
> Actual changes to the jail command can be found here:
> http://lists.freebsd.org/pipermail/freebsd-jail/2011-July/001568.html
> 
> How to use the jails v2 is covered many places. It does indeed exist, and you 
> can probably use the package here to get yourself started because the rc.d 
> script for jails is not updated to handle v2 jails.
> 
> http://druidbsd.sourceforge.net/vimage.html

The ".shtml" that I added in the website re-design looks nicer ^_^

http://druidbsd.sourceforge.net/vimage.shtml

I'm also planning on updating it with nice and pretty netgraph drawings.

When you're using my vimage package, you can use the following command to 
produce a nice diagram of your network:

sudo ngctl dot | dot -Tsvg -o $HOSTNAME-vimages.svg

Requires graphics/graphviz from ports/packages.

NOTE: I personally like SVG as it scales very nicely. Five command-line driven 
X11 applications that can display SVG are graphics/gimmage, graphics/gthumb, 
graphics/gqview, graphics/gx, and graphics/eog. Also, the latest version of 
every browser (including Firefox10/11, Chrome13, Safari5, and IE9) can display 
SVG. Latent versions of Operating Systems have built-in support as well 
(including Mac OS X Lion and Windows 7).

Alternatively, you can generate PNG or JPG using one of:

sudo ngctl dot | dot -Tpng -o $HOSTNAME-vimages.png
sudo ngctl dot | dot -Tjpg -o $HOSTNAME-vimages.jpg

I've uploaded a PNG for viewing pleasure:

http://druidbsd.sourceforge.net/download/warden0.jbsd.svg

NOTE: If you really need JPG or PNG, graphics/ImageMagick has the "convert" 
utility which is, well, almost magical in a sense (if not already hinted-at by 
the name). ^_^

How to read the diagram:

The "pink" cluster at the top-right are "unused" interfaces. Unused in the 
sense that netgraph doesn't have anything to do with them. In my graph for our 
FreeBSD-8.1 server named "warden0.jbsd.vicor.com" (it runs jails, get it? haha; 
and it's on the "jbsd" network, for jailed-bsd hosts).

In the diagram, "igb1" is shown as unused (it's displayed in the pink 
"disconnected" cluster -- which, if you're viewing in the browser, mousing over 
the cluster will display "cluster_disconnected" as a reminder of its purpose). 
This is not entirely true, it's in-use by the base-hose (warden0.jbsd). The 
other unused item is the socket we used to dump the dot(1) graph (see 
ng_socket(4) and ngctl(8)).

In the SVG diagram, there are a total of 5 vimage jails running on the host, 
sharing one physical Ethernet port and one physical wire (flowing through the 
igb0 interface). The five hosts are named (in rc.conf(5)):

        kps0a_dev
        kps64a_dev
        kws82a_dev
        kws411a_dev
        kws411b_dev

All these hosts are using the same On-board Intel Gigabit (igb(4)) network 
interface as illustrated in the above linked-to SVG image.

An ether-link is created for each vimage and "hooked into" a bridge that is 
created for the specific hardware interface. An upper-link is then created 
between the bridge and the hardware interface. Finally (for convenience) a 
lower-link is created between the bridge and the hardware interface (allowing 
the base host -- warden0.jbsd -- to interact with the vimages).

The links and their types are rendered in octagons and the netgraph objects are 
rendered as records (multi-field boxes). At the bottom-left of each record (the 
lower-left field) is the netgraph type. For example,

At the top-left of the graph you'll see a record where the top-field is 
"ng0_kps64a_dev:" (explained below), the lower-left field is "eiface", and the 
lower-right field is "[15]:", the "eiface" is the netgraph type.

For each of the netgraph types, such as "eiface", "ether", "bridge", and 
"socket", you can say "man ng_{type}" (for exampe, "man ng_bridge" or "man 
ng_ether").

The aforementioned top-field of each record is the interface name visible by 
ifconfig(8) inside the vimage. The format is "ngNN_NAME" where "NN" is the 
number starting at zero for each bridged interface (regardless of which 
underlying hardware interface is backing the netgraph(4)-created interface) and 
"NAME" is the rc.conf(5) name of the vimage.

Here's another SVG showing a machine running 7 high-security vimages:

http://druidbsd.sourceforge.net/download/bastion.svg

We see something very different from this system. In this system, we're not 
utilizing bridging versus simply shoving multiple network interfaces into 
various vimages. In this case, each vimage is given their own physical wire and 
therefore the netgraph(4) system is never invoked as no bridging is performed.

Yet another SVG, this one displaying a more exotic setup with the base host 
(named after a famous prison) housing vimages participating in multiple 
networks with various routing et cetera…

http://druidbsd.sourceforge.net/download/folsom.svg

Our "unused" cluster shows (or doesn't for that matter) that the base host is 
using one interface and another [high security] vimage is using two interfaces 
(again, high security vimages that use whole interfaces aren't shown in the 
netgraph(4) system, not by means of redaction but by means of 
no-bridging-necessary). Along side that there are another two vimages (named 
beefcake and stats) that are bridged into igb0 (Intel Gigabit), and another 8 
vimages bridged into igb1.

NOTE: Another thing that makes the high-security vimages more secure is that 
the base host (hosting the vimage) can't see the interface that is granted to 
the vimage. However, this in no way is to imply that either netgraph(4) or 
bridging is insecure in any way. On the contrary, it is the particular setup 
that is being advocated. A secure bridge can be created by removing the 
lower-link from the bridge and hardware interface. This is done with ngctl(8) 
and can be hooked into the startup of like-minded vimages using existing 
rc.conf(5) constructs provided by vimage package version 1.0 or higher -- 
current version is 1.4).
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to