Re: vnet without epair
On 2/10/2013 1:12 AM, Teske, Devin wrote: On Sat, 9 Feb 2013, Fbsd8 wrote: What I am doing is writing documentation that describes the new 9.1 jail extensions for jail.conf and the rc.conf jail statements. I am going to submit changes to /etc/defaults/rc.conf and as long as I was on the jail subject thought I may as well include vnet because it was missing from /etc/defaults/rc.conf. Thanks for taking this on. Thank you too. The documentation needs updating. This is very welcome. I did google search and could only find 9.0 vnet jails using epair. I'm surprised you didn't find my own page on vnet jails using netgraph: http://druidbsd.sf.net/vimage.shtml I have seen this but I got the idea that it is not in ports(?) and this stopped me from trying. Thanks for your efforts, Nikos ___ 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
RE: vnet without epair
On Sun, 10 Feb 2013, Nikos Vassiliadis wrote: On 2/10/2013 1:12 AM, Teske, Devin wrote: On Sat, 9 Feb 2013, Fbsd8 wrote: I did google search and could only find 9.0 vnet jails using epair. I'm surprised you didn't find my own page on vnet jails using netgraph: http://druidbsd.sf.net/vimage.shtml I have seen this but I got the idea that it is not in ports(?) and this stopped me from trying. It's not in ports only because I first wanted to see where jail.conf would take us w/respect to vimages. However, this package not being in ports shouldn't prevented you from trying it -- it's extremely stable and as I mentioned, we've been using it heavily at $work for over 12 months now. When you download the package (*.tgz) and pkg_add it, it installs the following two files only: /etc/rc.d/vimage /etc/rc.conf.d/vimage NOTE: The rc.conf.d file is the documentation on usage If you haven't tried it, then I hope you will because I think the new jail.conf stuff falls short. Don't get me wrong, jail.conf is a great start, but simply adding the ability to manage the vnet aspect of a jail does not make a vimage (what's missing is the built-in support for generating bridges as vimages are brought up/down dynamically). I feel that before I add this to ports I need to reprogram it to use jail.conf (not directly). That will simplify its code and [should] make it smaller. I was somewhat waiting on /etc/rc.d/jail to blaze the trail for me. In short, the landscape has been changing fast enough that it's prevented me from adding this to ports, but in spite of that it's still very much real _and_ real stable. -- 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
Re: vnet without epair
On 2/10/2013 2:54 PM, Teske, Devin wrote: It's not in ports only because I first wanted to see where jail.conf would take us w/respect to vimages. I see. However, this package not being in ports shouldn't prevented you from trying it -- it's extremely stable and as I mentioned, we've been using it heavily at $work for over 12 months now. When you download the package (*.tgz) and pkg_add it, it installs the following two files only: /etc/rc.d/vimage /etc/rc.conf.d/vimage NOTE: The rc.conf.d file is the documentation on usage If you haven't tried it, then I hope you will because I think the new jail.conf stuff falls short. Don't get me wrong, jail.conf is a great start, but simply adding the ability to manage the vnet aspect of a jail does not make a vimage (what's missing is the built-in support for generating bridges as vimages are brought up/down dynamically). I feel that before I add this to ports I need to reprogram it to use jail.conf (not directly). That will simplify its code and [should] make it smaller. I was somewhat waiting on /etc/rc.d/jail to blaze the trail for me. In short, the landscape has been changing fast enough that it's prevented me from adding this to ports, but in spite of that it's still very much real _and_ real stable. Yes, of course. I will try it and report back to you my findings. What I - nikos - really need from a script like yours is the ability to generate arbitrarily complex topologies with interconnected vnet jails. Something like: abc---d | | hef---g | | i Like a cut-down version of imunes[1] without the need of a graphical user interface. I understand that is not common case and that is why I was always using ad hoc scripts. But one can always hope(or write one himself/herself of course!). 1. http://web.archive.org/web/20120418053250/http://imunes.tel.fer.hr/imunes/ Thanks, Nikos ___ 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
RE: vnet without epair
On Sun, 10 Feb 2013, Nikos Vassiliadis wrote: On 2/10/2013 2:54 PM, Teske, Devin wrote: It's not in ports only because I first wanted to see where jail.conf would take us w/respect to vimages. I see. However, this package not being in ports shouldn't prevented you from trying it -- it's extremely stable and as I mentioned, we've been using it heavily at $work for over 12 months now. When you download the package (*.tgz) and pkg_add it, it installs the following two files only: /etc/rc.d/vimage /etc/rc.conf.d/vimage NOTE: The rc.conf.d file is the documentation on usage If you haven't tried it, then I hope you will because I think the new jail.conf stuff falls short. Don't get me wrong, jail.conf is a great start, but simply adding the ability to manage the vnet aspect of a jail does not make a vimage (what's missing is the built-in support for generating bridges as vimages are brought up/down dynamically). I feel that before I add this to ports I need to reprogram it to use jail.conf (not directly). That will simplify its code and [should] make it smaller. I was somewhat waiting on /etc/rc.d/jail to blaze the trail for me. In short, the landscape has been changing fast enough that it's prevented me from adding this to ports, but in spite of that it's still very much real _and_ real stable. Yes, of course. I will try it and report back to you my findings. What I - nikos - really need from a script like yours is the ability to generate arbitrarily complex topologies with interconnected vnet jails. Something like: abc---d | | hef---g | | i Like a cut-down version of imunes[1] without the need of a graphical user interface. Excellent! This is precisely what I was after when I wrote the vimage package and its contents. I'm familiar with IMUNES and netgraph fits the bill well (especially with ngctl dot being useful in providing visual confirmation when you've achieved the desired network layout -- when ngctl dot | dot -Tsvg -o netgraph.svg starts to look like your IMUNES graph, then you know you're making progress toward having the right configuration). -- 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
Re: vnet without epair
On 2/10/2013 3:56 PM, Teske, Devin wrote: Excellent! This is precisely what I was after when I wrote the vimage package and its contents. I'm familiar with IMUNES and netgraph fits the bill well (especially with ngctl dot being useful in providing visual confirmation when you've achieved the desired network layout -- when ngctl dot | dot -Tsvg -o netgraph.svg starts to look like your IMUNES graph, then you know you're making progress toward having the right configuration). You'll be soon hearing from me then! Nikos ___ 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
RE: vnet without epair
On Sun, 10 Feb 2013, Nikos Vassiliadis wrote: On 2/10/2013 3:56 PM, Teske, Devin wrote: Excellent! This is precisely what I was after when I wrote the vimage package and its contents. I'm familiar with IMUNES and netgraph fits the bill well (especially with ngctl dot being useful in providing visual confirmation when you've achieved the desired network layout -- when ngctl dot | dot -Tsvg -o netgraph.svg starts to look like your IMUNES graph, then you know you're making progress toward having the right configuration). You'll be soon hearing from me then! Here's some examples of ngctl dot | dot -Tsvg -ofile run on various servers running my vimage package: http://druidbsd.sourceforge.net/download/warden0.jbsd.svg A server with two network interfaces (igb0 and igb1). igb0 is bridged to 5 vimages (named kps0a_dev, kps64a_dev, kws411a_dev, kws411b_dev, and kws82a_dev). Each vimage has a single bridge to the same igb0 interface and are talking on a single subnet (see next example for more complex layout). Meanwhile, igb1 is used exclusively for the host machine (netgraph displays this in a disconnected cluster because it's not in-use by the netgraph system). The ngctl99755 element off to the right is the ngctl program's connection to the netgraph system to dump the dot(1) output for the creation of the SVG image itself. http://druidbsd.sourceforge.net/download/folsom.svg A server with 5 network interfaces (em0, em1, em2, igb0, igb1). igb0 is bridged between the host machine, a vimage named stats and a vimage named beefcake. igb1 is bridged between the host machine, a vimage named bafug1, and 6 other vimages. Of the 6 other vimages, the special one is cfg0_vlbxrich which has 2 bridges to the same interface (the host machine's rc.conf has vimage_cfg0_vlbxrich_bridges=igb0 igb0) but is speaking different subnets on each of the bridged interfaces within the jail (saying ifconfig in that vimage produces two interfaces -- beside lo0 -- named ng0_cfg0_vlbxri, and ng1_cfg0_vlbxri; these are configured to 2 different subnets in the jails's /etc/rc.conf). There are more vimages that can't be seen as netgraph does not show vimages that are using whole interfaces (a single PHY on a quad-port NIC for example; or a tap/tun pair); however you can see the interfaces em0, em1, and em2. What's cute is that those vimages are often purposed as high se curity vimages and as-such we view it as a value-add that they don't appear in the netgraph layout. (but to be honest, this is an older output and I can't remember what those interfaces were used for -- our vimage servers have grown and changed since then). http://druidbsd.sourceforge.net/download/bastion.svg A high security server (that was decommissioned last Friday) where each vimage gets an entire PHY (read: netgraph is not used, whole interfaces are moved into the vimages -- see /etc/rc.conf.d/vimage specifically vimage_example_vnets). So naturally, this graph appears to be rather boring (all the interfaces are in the disconnect cluster) because netgraph isn't using the interfaces. -- 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
Re: vnet without epair
On 2/10/2013 4:02 PM, Nikos Vassiliadis wrote: On 2/10/2013 3:56 PM, Teske, Devin wrote: Excellent! This is precisely what I was after when I wrote the vimage package and its contents. I'm familiar with IMUNES and netgraph fits the bill well (especially with ngctl dot being useful in providing visual confirmation when you've achieved the desired network layout -- when ngctl dot | dot -Tsvg -o netgraph.svg starts to look like your IMUNES graph, then you know you're making progress toward having the right configuration). You'll be soon hearing from me then! Hi Devin, A request. Could you create a pkgng package as well? 10 has switched to pkgng... Thanks in advance, Nikos ___ 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
RE: vnet without epair
Have you tried using netgraph? -- Devin From: owner-freebsd-questi...@freebsd.org [owner-freebsd-questi...@freebsd.org] on behalf of Fbsd8 [fb...@a1poweruser.com] Sent: Saturday, February 09, 2013 7:57 AM To: FreeBSD questions Subject: vnet without epair Has any one been able to get RELEASE 9.1 to enable jail vnet without having to use epair? ___ 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 _ 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
Re: vnet without epair
On 2/9/2013 5:57 PM, Fbsd8 wrote: Has any one been able to get RELEASE 9.1 to enable jail vnet without having to use epair? Yes, you can use vnet-enabled jails with several types of interfaces. Physical ones like em0 etc, virtual ones like vlan0 etc, netgraph ethernet-like interfaces like ngeth etc and if_epair interfaces. What all these have in common is that they all are ethernet-like. You don't mention what kind of use and more or less most interfaces are usable in a vnet jail. Could you share more on what you are trying to achieve? Nikos ___ 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
Re: vnet without epair
Nikos Vassiliadis wrote: On 2/9/2013 5:57 PM, Fbsd8 wrote: Has any one been able to get RELEASE 9.1 to enable jail vnet without having to use epair? Yes, you can use vnet-enabled jails with several types of interfaces. Physical ones like em0 etc, virtual ones like vlan0 etc, netgraph ethernet-like interfaces like ngeth etc and if_epair interfaces. What all these have in common is that they all are ethernet-like. You don't mention what kind of use and more or less most interfaces are usable in a vnet jail. Could you share more on what you are trying to achieve? Nikos Thanks for your reply and interest. What I am doing is writing documentation that describes the new 9.1 jail extensions for jail.conf and the rc.conf jail statements. I am going to submit changes to /etc/defaults/rc.conf and as long as I was on the jail subject thought I may as well include vnet because it was missing from /etc/defaults/rc.conf. I did google search and could only find 9.0 vnet jails using epair. It was my understanding that epair was not necessary to use vnet and thanks to you, you confirmed it. As part of this self-appointed project I plan to also update man jail and the handbook jail section which is really way out of date. I plan to include vnet in all aspects of this project. I must point out this is not just a writing project. I have been using rc.conf jail statements to configure jails for some time now, and have a test bed to test things I write about so I can verify what I write is true and valid. I am working with the author of the jail environment and already have discovered bugs which are being addressed. I have never played with vimage as it's labeled as experimental because it is not scp aware. IE: can not use more than a single cpu. One of the 9.1 jail extensions deals with being able to use quotas inside of jails. I am excited to begin testing this new function. During my jail research I have come across posts where people have to use a kernel patch to get xorg desktops to work inside of a jail. I have a separate post to questions list trying to mine some info on that subject. I am always open to input. If you have the background to support my efforts in this project its welcomed. Joe ___ 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
RE: vnet without epair
On Sat, 9 Feb 2013, Fbsd8 wrote: Nikos Vassiliadis wrote: On 2/9/2013 5:57 PM, Fbsd8 wrote: Has any one been able to get RELEASE 9.1 to enable jail vnet without having to use epair? Yes, you can use vnet-enabled jails with several types of interfaces. Physical ones like em0 etc, virtual ones like vlan0 etc, netgraph ethernet-like interfaces like ngeth etc and if_epair interfaces. What all these have in common is that they all are ethernet-like. You don't mention what kind of use and more or less most interfaces are usable in a vnet jail. Could you share more on what you are trying to achieve? Nikos Thanks for your reply and interest. What I am doing is writing documentation that describes the new 9.1 jail extensions for jail.conf and the rc.conf jail statements. I am going to submit changes to /etc/defaults/rc.conf and as long as I was on the jail subject thought I may as well include vnet because it was missing from /etc/defaults/rc.conf. Thanks for taking this on. I did google search and could only find 9.0 vnet jails using epair. I'm surprised you didn't find my own page on vnet jails using netgraph: http://druidbsd.sf.net/vimage.shtml What I did was dup' the old rc.d/jail script one day and modify it to support vnet jails (read: it doesn't use jail.conf it uses the old style of rc.conf(5) parameters) with the built-in ability to do bridging with netgraph (if you enable the right kernel options and/or have the right modules loaded). It also supports shoving any whole interfaces into the vnet jails (be they real or pseudo interfaces, the only restriction is that it has to be a valid parameter in ifconfig interface vnet jail_id. ASIDE: The nice thing about using netgraph to do the bridging on the back-end is that ngctl dot | dot -Tsvg -o netgraph.svg creates nice pictures of your network layout (aside from being very versatile). It was my understanding that epair was not necessary to use vnet and thanks to you, you confirmed it. As part of this self-appointed project I plan to also update man jail and the handbook jail section which is really way out of date. I plan to include vnet in all aspects of this project. I must point out this is not just a writing project. I have been using rc.conf jail statements to configure jails for some time now, I hope you'll look at my vimage package (we've been using it for a little over 12 months now). $work has been very happy with it to say the least. and have a test bed to test things I write about so I can verify what I write is true and valid. I am working with the author of the jail environment and already have discovered bugs which are being addressed. I have never played with vimage as it's labeled as experimental because it is not scp aware. I think you mean it conflicts with SCTP (network protocol like UDP and TCP). IE: can not use more than a single cpu. I'm not so sure about that. One of the 9.1 jail extensions deals with being able to use quotas inside of jails. I am excited to begin testing this new function. Very cool -- looking forward to reading updates on that. During my jail research I have come across posts where people have to use a kernel patch to get xorg desktops to work inside of a jail. I have a separate post to questions list trying to mine some info on that subject. Excellent! I am always open to input. If you have the background to support my efforts in this project its welcomed. Yeah, we use vimages a lot at $work. For example, just yesterday, I had a need to move a machine into the server room but it wasn't in a rack-mountable case -- so I rsync'd the OS (minus /dev and /proc of course) to a directory on the vimage server, spent a minute or two copy/pasting in /etc/rc.conf, changing a couple values (like which em* interface to bridge to), and then I said service vimage start [thename] obsoleting the once-physical machine for a new vimage. In this case, the server needed to run samba on a private network. Worked great. Freed up some workstation hardware for an actual workstation and a server that should have been in the rack is now running on server equipment as it should. It was a win for everybody and it took less than an hour (including the time to rsync). Now only if I could find a graceful solution to rsync dying with out of memory errors on massive amounts of files and/or hard-links (rsync-3.0.7), I'd be all set! -- 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. ___
