Re: Re[2]: Loopback and jail.conf
On Wed, Jun 26, 2013 at 07:47:25AM +, Ivailo Tanusheff wrote: > Mate, I do not need pf or ipfw :) > Maybe I did not describe it well, what I simply need is: > > Jail 1: > Interface em0: 192.168.0.1 > Interface lo0: 127.0.0.1 > > Jail 2: > Interface em0: 192.168.0.2 > Interface lo0: 127.0.0.1 > > Jail 3: > Interface em0: 192.168.0.3 > Interface lo0: 127.0.0.1 > > As you can see, there the same address for the loopback, which gives me an > error when I start the jail: > Jail 1 starts ok. > Then when I start Jail 2: > jail: jail2: IPv4 addresses clash > > What I use in jail.conf: > > Jail1: ip4.addr = 192.168.0.1 , 127.0.0.1; > Jail2: ip4.addr = 192.168.0.2 , 127.0.0.1; You can add aliases to lo0: 127.0.0.2, .3, .4, ... pgpnWVX_WnJdo.pgp Description: PGP signature
Re: fast way to update jails (FreeBSD 10.0 host)
Am 2014-01-29 13:46, schrieb Nicolas de Bari Embriz Garcia Rojas: Hi, I avoid mergemaster since ask for to many changes, it is faster for me some times just copy /etc.old —> /etc important files, but this maybe because I am using the bad flags. Can you please give me a tip or some good flags that I should use when using mergemaster. thanks in advance. mergemaster -FUi automatically merges a lot of stuff leaving only the relevant changes for manual merge. ___ 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: deploy multiple vnets with VIMAGE/VNET + Production Ready?
On Mon, May 30, 2016 at 09:40:42AM -0400, Ernie Luzar wrote: > Here are the bare truths without any sugar coating. > Vimage is officially described as experimental. You have to recompile > the kernel to included vimage. Enabling pf or ipf firewalls cause the > host to crash. ipfw firewall does not cause a crash but has next to no > real life usage on vimage. When stopping vimage jails there is a problem > with memory loss. You need a high proficiency in coding netgraph which > is used to tie the hosts network to each vimage jail. Needs a public > network with multiple static ip address & registered domain names even > to test it. > > A few brave soles have accepted these short comings and have deployed > vimage in a production environment with good results so they say, or at > best they have not reported any problems. I guess it all depends of what > your shop defines "production ready" as. At my shop vimage is NOT > considered something management is willing to base the business on. > Maybe your shop is different. > > There are a few write ups about how to configure vet/vimage jails, but > their out of date. IE: 8.x & 9.x releases which are at EOL [end of life, > unsupported]. The current production version of Freebsd is at 10.3 with > 11.0 due out in August. Only know of one utility jail tool that has > vnet/vimage function. Try the qjail port, it will shorten your learning > curve. sysutils/iocage also supports VIMAGE > > Now there is a guy who is patching vimage trying to get it so it can be > incorporated into the base kernel. His goal was to get it into release > 11.0, but updates to 11.0 source are now suspended until 11.0 is > published so thats not going to happen. They sure would not incorporate > viamge without a general announcement calling for users to test drive it > first. This has not happened yet that I know of. You seem to forget that there have been fixes already in HEAD: http://freshbsd.org/search?branch=HEAD&project=freebsd&q=vimage+OR+vnet pgp3ePKmkZuyH.pgp Description: PGP signature
Re: testing 11.0-RC1 vnet jails with ipfilter
On Tue, Aug 16, 2016 at 09:05:28PM -0400, Ernie Luzar wrote: > Bjoern A. Zeeb wrote: > > On 16 Aug 2016, at 21:08, CyberLeo Kitsana wrote: > > > >> On 08/16/2016 03:21 PM, Ernie Luzar wrote: > >> > >>> Issuing "ipf -FS -Fa" command from within the vnet jail gives this > >>> message, "open device:no such file or directory. User kernel version > >>> check failed. > >> > >> According to ipf(8), the ipfilter utilities touch /dev/ipauth , /dev/ipl > >> , and /dev/ipstate . Have you checked that the devfs ruleset applied to > >> your jail has those unhidden? > >> > >>> Issuing "ipfstat -hnio command from within the vnet jail gives this > >>> message, open(IPSTATE_NAME):no such file or directory. > >> > >> ipfstat(8) also lists /dev/kmem ; I suspect that including this may be a > >> bad idea. > > > > /dev/kmem is a bad idea; I should go and check what it is using it for > > and if needed we should fix that. > > > > > > I guess the general thing is that we might want to create another > > default set of devfs rules which include additional nodes we now > > consider safe inside VNET jails; the jail.conf still needs to know the > > right ruleset to apply, so the jail.conf would need to specify the other > > devfs_ruleset=“..” for vnet jails. Maybe Jamie could then come up with > > an intelligent solution that would automatically flip things if option > > vnet is set? I guess jail.conf(5) will need more examples for these > > things as well. > > > > > > /bz > > > > If thats the road you are thinking of going down, then we have to look > at the big picture. Is another rule set say number 5 that includes rule > set number 4 plus the nodes for ipfilter, pf, and ipfw. Or maybe a > separate rule set for each firewall which is more secure. > > There is no way jail(8) could know which firewall if any was going to be > run in the vnet jail to select the correct rule if there were separate > rules for each firewall. A combined rule set containing everything > needed for all 3 firewalls would be something jail(8) could auto default > to if vnet option was coded. > > In light of 11.0 release being published soon there should be something > posted to the release notes talking about this with sample code for a > combined rule #5. This would give vnet users a copy & paste solution to > use until jail(8) gets updated in 11.1. > > I tried this rule set in /etc/devfs.rules > > [devfsrules_jail=5] > add include $devfsrules_jail > add path /dev/ipl unhide > add path /dev/ipauth unhide > add path /dev/ipstate unhide I think you have to remove '/dev/' > > Boot time get error message that this was invalid. > > If I could get a correct syntax combined rule #5 file, I could continue > testing all 3 firewalls using 11.0-RC1. > > Your help would be greatly appreciated. > > > > > > > > > > ___ > 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" pgpzXbXsjAoMZ.pgp Description: PGP signature
Re: [call for testing] kmod-devctl-jail
On Fri, Jun 07, 2019 at 02:46:42AM +0200, Fabian Freyer wrote: > Hi all, > > I'd like to call for testing of the kernel module kmod-devctl-jail [1], > which adds devctl(4) support for jail state changes. The aim is to > provide some logging and/or auditing support as well as providing jail > managers with a way to get notified of jail state changes. > > I'm not yet clear as to whether this is something that could/should get > upstreamed into base, or should better live in ports. > > Please CC me when replying to this, as I am not subscribed to freebsd-jail@. > > Thanks, > Fabian > > [1] https://github.com/fubarnetes/kmod_devctl_jail.git I just gave it a shot and it can be a very useful tool IMHO. Please create a review on Phabricator and maybe it can get added to base. Here's the log output produced from starting and stopping a jail: var/log tail -f jail Jun 7 23:01:01 nelson jail[314]: Jail JID=2 created Jun 7 23:01:02 nelson jail[1720]: Process PID=1644 attached to Jail JID=2 Jun 7 23:01:12 nelson jail[46712]: Process PID=46535 attached to Jail JID=2 Jun 7 23:01:12 nelson jail[68454]: Jail JID=2 removed ___ 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"
Re: Upgrading multiple Jails via freebsd-update
Am 2020-12-13 13:04, schrieb antranigv: Greetings! freebsd-update is an amazing tool to upgrade the system without compiling from sources and upgrading jails can be as easy as freebsd- update -b /path/to/jail upgrade -r 12.2-RELEASE, however I have noticed that when using the utility multiple times, it still fetches the files multiple times. My question is: Is there a way to use FreeBSD-update in a way, that allows the user to download once and upgrade multiple Jails. I run dozens of jails on multiple hosts and it's very frustrating to download the same content. I think it's okay for the patch files to be downloaded every time (freebsd-update fetch install), since they are small and don't require a lot of time, but the upgrade process is somehow a pain. Some things I know I don't want: 1) Thin Jails (I like using zfs clone on ZFS systems and tar xf base.txz -C jail0/ on UFS) as a solution, since I change the base a lot. 2) Using network caching (say, via Varnish), it seems like more overhead, although any new suggestions would be nice 3) compiling the sources at all (but I'm rethinking this lately, however my CPU is not that fast). Any tips and suggestions would be nice! P.S. In an ideal solution, it would be nice to just download the ISO or tarballs from the mirrors and pass that to freebsd-update, but looks like that required a lot of work. You can nullfs-mount /var/db/freebsd-update from the host into the jails you want to update. ___ 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"
Re: jail.conf and rc.conf
On Mon, Feb 25, 2013 at 02:50:55PM +0100, Andreas Nilsson wrote: > Hello, > > I needed to set up some jails, and since it has been a while since I did I > decided to read a bit about it. I stumbled upon the file /etc/jail.conf, > which I found very nice. Now my question: > > How do I specify that jails in listed in jail_list in rc.conf should use > jail.conf for their parameters/settings? > > Best regards > Andreas Take a look at sysutils/jail2, it's probably what you need. pgplg4PHfYIIr.pgp Description: PGP signature
