Re: Cant reach Jailed services from internet.
Mogamat Abrahams wrote: Joe writes: Your 67.205.xx.xx ip address looks like a dynamic ip address that you use dhcp to automatically obtain all the network configuration information needed by your host. Static ip addresses don't work that way. You have to manually configure the static network. If I remember correctly, for a block of 3 assignable ip addresses you need a block of 5 from your provider. The first and last ip address are used to config the network. This address was provided and I manually configured the nic. You never said if you have a firewall on your host. The firewall rules maybe dropping unsolicited inbound traffic for those 174 prefixed ip addresses. Try putting a pass all log from that NIC rule or just a log all rule or turn off the firewall all together and see what happens. Verify your NAT is not trying to NAT unsolicited inbound traffic for those 174 prefixed ip addresses. I had no firewall installed on the machine as we were still setting up and usually only add firewalling last. Here is something interesting though, since compiling a custom kernel and including: device<><-->pf device<><-->pflog nooptions<->sctp options><-->VIMAGE device ><-->epair device ><-->if_bridge options><-->NULLFS #firewall options MROUTING# Multicast routing options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default options IPFIREWALL_FORWARD #packet destination changes options ACCEPT_FILTER_DATA options ACCEPT_FILTER_DNS options ACCEPT_FILTER_HTTP options ZERO_COPY_SOCKETS My JAILS now both receive and respond to traffic! This was the only change i remember making. Just running on firewall_type="OPEN" and have not even defined any other rules. So the problem seems solved, however still not sure what fixed it!! Is NAT a requirement for Jail networking where the default gateway is not on the same subnet as the Jail? Mogamat Abrahams It's customary to post your solution as the last post in this thread. Since you have so many kernel options included it would be nice to know which one really made the difference. BY process of limitation nooptions sctp problem was fixed in 8.1-release device pfyour not using this firewall device pflog optionsACCEPT_FILTER_DATA These 4 have never been talked about optionsACCEPT_FILTER_DNSbefore in vnet context. Not likely optionsACCEPT_FILTER_HTTP to have any bearing on your problem. optionsZERO_COPY_SOCKETS Since your problem was happening with both if_bridge/epair and netgraph vnet networks seems unlikely that device epair device if_bridge compiled into the kernel has any bearing on your problem. My money is on options MROUTING # Multicast routing May I suggest you remove the above kernel options and recompile with modules. If it works then you know what kernel option is the solution to a vnet jail receiving inbound traffic. Then post the if_bridge/epair commands you used to create your vnet/vimage inbound and outbound network. Your solution post provides an answer (solution) for people who search the list email archives who have the same problem. Doing this is how you repay the people who help you on this list. ___ 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: Starting jail breaks routing / multi-network jail
Josh Beard wrote: Hello, I posted this on forums.freebsd.org ( http://forums.freebsd.org/showthread.php?t=41135), but figured I may have better luck here. I'm trying to setup a host that will accommodate two networks for its jails - with two NICs. One of this NICs (igb0) is connected to our LAN and the other (igb1) is connected to a public WAN switch. For the WAN side, I'll actually have two different gateways with two completely different set of addresses due to IP exhaustion - same network, however. I'm not sure if the problem I'm having is a bug, a misconfiguration, or a limitation. Whenever starting a a test jail that has an address on the LAN and one on the WAN, my hosts's routing gets changed and I'm unable to reach the public address I have for the jail. Here's a snip of what the host /etc/rc.conf looks like (addresses obfuscated for privacy): ifconfig_igb0="inet 172.30.112.196 netmask 255.255.240.0" ifconfig_igb0_alias0="inet 172.30.112.192 netmask 255.255.240.0" # (I tried a recommended 255.255.255.255, too) ifconfig_igb1="inet 96.2.192.A netmask 255.255.255.240 broadcast 96.2.192.BA " ifconfig_igb1_alias0="inet 24.111.1.B netmask 255.255.255.240 broadcast 24.111.1.BB" defaultrouter="24.111.1.BR" I'm using ezjail and in the jail's config, I have: export jail_jailedhost_ip="igb0|172.30.112.192,igb1|24.111.1.a" export jail_jailedhost_fib="1" Before starting the jail, I can ping any of the addresses in question. After starting, the public addresses stop responding. - default24.111.1.b UGS 04 igb1 24.111.1.x/28link#3 U 0 43 igb1 24.111.1.a link#3 UHS 00lo0 (and the routes for the LAN) - When I start the jail, my hosts's routes change: - default24.111.1.b UGS 0 236 igb1 24.111.1.a link#3 UHS 00lo0 => 24.111.1.a/32link#3 U 00 igb1 (routes for the LAN - routes for each address /32) - The broadcast for each interface also changes to its own address (/32). I can "fix" this by doing this on the host system, but this isn't desirable. If I have to, I guess I could have this executed on startup (but cycling a jail will break the routing table again): service netif restart service routing restart set fib 1 route add -host 24.111.1.BR -iface igb1 set fib 1 route add default 24.111.1.BR I'm not sure where to go from here. I've tried using setfib to take care of this (as you see there), but the results are the same. TL;DR: Starting a jail with a LAN and public address changes the host's routing table and will not talk over the public network. Cycling the netif and routing services resolves it. Any insight? Anything is much appreciated. Josh Let me start of by saying I an no network expert. This is my understanding of how jail works. 1. There are 2 ways to define jails, the legacy rc.d-script method where the jail description parameters are in /etc/rc.conf and the jail(8) method that finally has all the bugs fixed in 9.2 where the jail description parameters are in /etc/jail.conf. These 2 methods can not be mixed together. 2. By design normal jails defined using either method ONLY access an single NIC having a single or multiple IPv4/IPv6 ip address/addresses. 3. The only way to assign multiple NICs to a jail is by using the highly experimental vimage software that has to be compiled into the hosts kernel which limits the host to only using IPFW firewall. PF and IPF filewalls on the host with vimage will case a hang. 4. fib's are only configured on the host, it takes an boot option or the kernel has to be recompiled to increase the number of system fibs available to the host before you can assign a second one to a jail. 5. This is incorrect syntax ip="igb0|172.30.112.192,igb1|24.111.1.a" should be ip="172.30.112.192,24.111.1.a" No nic device name. Not issuing a error does not mean its correct. My jail system has 4 LAN only jails that have outbound access to the public internet and 2 public accessible jails for my web and email servers using the same public routable dynamic IPv4 IP address assigned by my ISP without the need for special host firewall port redirection. I use the qjail version 3.1 utility to admin my jail system. Due to the 9.2-BETA port freeze qjail-3.2 which adds IPv6 support has not been committed to the port system yet. The port-make-files can be downloaded from here http://sourceforge.net/projects/qjail/files/Port%20make%20files/ Good luck. ___ 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: ezjail and UPDATING20131010
Kenta Suzumoto wrote: Hi there. I updated to 10-STABLE after it was branched and suddenly none of my [ez]jails will start. Does it have anything to do with the entry in UPDATING? What's the best way to solve it? The jail rc.script environment in 10.0 has been patched to convert all the jail rc.conf parameters to the new jail(8) format and then exec jail(8). This is in preparation for depreciating the jail.conf jail parameters. ezjail uses the rc.conf jail parameters and needs to be updated to use the native jail(8) parameters. Until that gets done ezjail only works with 9.2 and older versions of FreeBSD. The qjail utility uses the native jail(8) parameters right now. Give it a try. ___ 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: Can Firefox break out of a jail
Erich Dollansky wrote: Hi, I do some experimenting with jails at the moment on a FreeBSD 10.0 machine. The jails are all setup manually according to the handbook and man jail. Each jail gets a name and an IP address. Individual ports are then installed via the ports tree. X is running on the host system. Telnet is used to connect to the jails. When I install now firefox in a jail and also in the host system, I get the following behaviour. Scene A Firefox runs already on the host system. I start then firefox inside the jail firefox. It all seems fine as long as I do not use the history or want to save the visited page. The jailed firefox sees then the history of the firefox running on the host. Scene B Firefox is first started inside the jail firefox. When then the host system also starts a firefox, this firefox sees now the history and the filesystem of the jailed firefox. Is it X that allows the jailed firefox to communicate directly with firefox running directly on the host? Is there then a way to secure the system? I have tried then programs like gedit or kate and saw only the behaviour I expected. Both programs either saw only resources from inside the jail or from outside but never resources from the other side of the fence. firefox has to be installed where you have xorg and your desktop installed. Installing firefox in a jail be it self does nothing. What you think you are seeing is wrong. ssh into jail having firefox is not running firefox. ssh into the host where xorg and desktop and firefox is the only to have firefox work to the best of my knowledge. ___ 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: new jail framework with vnet, zfs and jail.conf support
freebsd_j...@dachev.info wrote: Hi, I'm currently in process of development of new tool for easy jail administration with zfs and vimage/vnet(bridge epair interface) support The idea is to have a single application (python script) without any other confg files and customization This tool is written on Python, also work only with vnet, zfs and FreeBSD 10 (probably will work on FreeBSD 9.1 but i never test it) JADM work only with native /etc/jail.conf When is started for first time jadm generate new /etc/jail.conf in special format developed by me. jail.conf file can be used and without JADM. for more information please contact me or visit: https://github.com/NikolayDachev/jadm JADM is in development status more of functions work normal (with bugs but work :)). Unfortunately i don't have a lot of time for it so i need test users. At the moment last function for JADM is to support skeleton jail model (similar to ezjail with base jail and etc.) This function is still in progress meanwhile, if someone have a time to test all other functions and to report any issue, bug or ideas I think you have made some poor basic design choices. 1. Requiring python as a dependent. Thats a lot of overhead just for a script. Not a show stopper, but a csh script would have been better. 2. Using the highly experimental "vimage" as the cornerstone of the over all design. Vimage has many long standing PRs, does not work with any of the firewalls, has NO maintainer, requires a custom kernel to enable. This is a major show stopper. Can not risk a production jail environment on highly experimental software. Even if vimage gets a maintainer, all the firewalls need to be updated to play nice in an vimage environment, and there are existing PRs to that effect which the firewall maintainers are reluctant to address because of vimage's status as highly experimental. What your trying to do may never bare fruit due to things totally out of your control. 3. Should use the allow_zfs option of jail(8) instead of embedded native zfs commands. With surgery JADM could become a ZFS admin script, there is a need for that and one does not exist that I know of. ___ 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: iocage - drop in jail manager
Peter Toth wrote: For anyone interested in managing jails with VNET, ZFS and resource limits I have created a jail manager script https://github.com/pannon/iocage . Basically rewritten most of "zjails" in pure sh with simplicity in mind. 90% is done final commits will be happening in the next 2 weeks. Feel free to give it a test drive. Will this script work on i386 systems? Will this script work on a generic system with no zfs disk area enabled? Does vnet jail still have "lost memory bug" when stopping vnet jail? Do any of the host firewalls (ie; ipfw, ipf, pf) work on host and in multiple vnet jail at same time? Does NAT function work in vnet jail? Can non-vnet jails be created? ___ 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: vnet jail and ipfw/nat on host - keep-state problem?
Peter Toth wrote: Have not used natd with IPFW much as always preferred PF to do everything on the host. I have only a wild guess - the "me" keyword in IPFW is substituted only to the host's IPs known to itself. The host's IPFW firewall most likely doesn't know anything about IPs assigned to vnet interfaces inside the jail. Vnet jails behave more like separate physical hosts. Internet ---> [host] --- (10.0.10.0 LAN) --> [vnet jail] The PF issue inside a jail is a separate problem, PF is not fully VIMAGE/VNET aware as far as I know. Can someone comment on these or correct me? P On Fri, Jul 11, 2014 at 7:11 PM, Peter Ross wrote: On Thu, 10 Jul 2014, Peter Toth wrote: Hi Peter, Try to make these changes: net.inet.ip.forwarding=1 # Enable IP forwarding between interfaces net.link.bridge.pfil_onlyip=0 # Only pass IP packets when pfil is enabled net.link.bridge.pfil_bridge=0 # Packet filter on the bridge interface net.link.bridge.pfil_member=0 # Packet filter on the member interface You can find some info here http://iocage.readthedocs.org/en/latest/help-no-internet.html I've had these issues before with PF and IPFW, by default these will be filtering on your bridge and member interfaces. Thanks. It did not change anything. Now, inside_ the jail I run "ipfw allow ip from any to any". This on the host system: 01000 check-state 01100 allow tcp from any to any established 01200 allow ip from any to any frag 00100 divert 8668 ip4 from any to any via age0 03100 allow udp from any to 10.0.10.1 dst-port 53 keep-state 03200 allow udp from any to me dst-port 53 keep-state (with natd redirecting "redirect_port udp 10.0.10.1:53 external.ip:53") If I add 03300 allow udp from me 53 to any it works.. So it makes me think check-state isn't usable - because 03200 allow udp from any to me dst-port 53 keep-state should cover the returning packets. I played with your parameters but it did not help. But thanks for the idea. Here again the setup: Internet->age0(host interface with natd and external IP) ->bridge10(10.0.10.254)->epair1a ->epair1b(10.0.10.1 in bind vnet jail) I wonder what kind of restrictions exist with vnet.. it does not seem to work _exactly_ as a "real" network stack (the issues with pf inside the jail let me think of it too) Did I find a restriction, a bug - or just that I've got it wrong? Regards Peter Any firewall function that runs in the kernel will not function inside of a vnet/vimage jail. ___ 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: Jail vnet features
Marcin Michta wrote: Hello, I want to ask what are advantages and disadvantages using VNET? I know that it allows each jail to have a private networking stack, but what else? Regards Marthin Its experimental, it has many bugs posted in PR system, loses memory every time a vnet jail is stopped, firewalls in vnet jail don't work, other that these show stoppers, use at your own risk. ___ 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: Jail vnet features
wishmaster wrote: --- Original message --- From: "Fbsd8" Date: 11 July 2014, 16:49:08 Marcin Michta wrote: Hello, I want to ask what are advantages and disadvantages using VNET? I know that it allows each jail to have a private networking stack, but what else? Regards Marthin Its experimental, it has many bugs posted in PR system, loses memory every time a vnet jail is stopped, firewalls in vnet jail don't work, other that these show stoppers, use at your own risk. Hey, man. Stop panic! Firewall works very well. Memory leak on shutdown it is not very big problem. Main advantage for me is: I am able to filtering and prioritization traffic coming thought base system. My vnete'ed jails is like a regular LAN clients and they share INET pipe with appropriate weight. I use ipfw. Oh ya, host panic on boot is another common happing with vimage and firewall ipf and pf trying to run inside of a vnet jail and on the host at the same time. Many people DO consider any kind of memory leak in kernel software such as vimage is a really big show stopper for not using it in a production system. If you read a little bit closer the previous post you will see it's talking about firewall running inside of a vnet/vimage jail. It doesn't say anything about running a host firewall directing traffic to a ip number assigned to a vnet jail. Here is a list of some of the vnet outstanding PR's 143808, 147950, 148155, 152148, 160496, 160541, 161094, 164763, 165252, 176112, 176929, 178480, 178482, 179264, 182350, 185092, 188010, 191468 vnet/vimage is experimental and should never be used in a production system and be exposed to the public network. It is not a secure software configuration. Sure you can disregard all warnings and common sense and risk your host system, thats your choice. ___ 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: vnet jail and ipfw/nat on host - keep-state problem?
Peter Toth wrote: On Sat, Jul 12, 2014 at 1:33 AM, Fbsd8 <mailto:fb...@a1poweruser.com>> wrote: Peter Toth wrote: Have not used natd with IPFW much as always preferred PF to do everything on the host. I have only a wild guess - the "me" keyword in IPFW is substituted only to the host's IPs known to itself. The host's IPFW firewall most likely doesn't know anything about IPs assigned to vnet interfaces inside the jail. Vnet jails behave more like separate physical hosts. Internet ---> [host] --- (10.0.10.0 LAN) --> [vnet jail] The PF issue inside a jail is a separate problem, PF is not fully VIMAGE/VNET aware as far as I know. Can someone comment on these or correct me? P On Fri, Jul 11, 2014 at 7:11 PM, Peter Ross mailto:peter.r...@alumni.tu-berlin.de>> wrote: On Thu, 10 Jul 2014, Peter Toth wrote: Hi Peter, Try to make these changes: net.inet.ip.forwarding=1 # Enable IP forwarding between interfaces net.link.bridge.pfil_onlyip=0 # Only pass IP packets when pfil is enabled net.link.bridge.pfil_bridge=0 # Packet filter on the bridge interface net.link.bridge.pfil_member=0 # Packet filter on the member interface You can find some info here http://iocage.readthedocs.org/__en/latest/help-no-internet.__html <http://iocage.readthedocs.org/en/latest/help-no-internet.html> I've had these issues before with PF and IPFW, by default these will be filtering on your bridge and member interfaces. Thanks. It did not change anything. Now, inside_ the jail I run "ipfw allow ip from any to any". This on the host system: 01000 check-state 01100 allow tcp from any to any established 01200 allow ip from any to any frag 00100 divert 8668 ip4 from any to any via age0 03100 allow udp from any to 10.0.10.1 dst-port 53 keep-state 03200 allow udp from any to me dst-port 53 keep-state (with natd redirecting "redirect_port udp 10.0.10.1:53 <http://10.0.10.1:53> external.ip:53") If I add 03300 allow udp from me 53 to any it works.. So it makes me think check-state isn't usable - because 03200 allow udp from any to me dst-port 53 keep-state should cover the returning packets. I played with your parameters but it did not help. But thanks for the idea. Here again the setup: Internet->age0(host interface with natd and external IP) ->bridge10(10.0.10.254)->__epair1a ->epair1b(10.0.10.1 in bind vnet jail) I wonder what kind of restrictions exist with vnet.. it does not seem to work _exactly_ as a "real" network stack (the issues with pf inside the jail let me think of it too) Did I find a restriction, a bug - or just that I've got it wrong? Regards Peter Any firewall function that runs in the kernel will not function inside of a vnet/vimage jail. This sounds a bit vague, can you please explain in more detail what you meant by this? IPFW works inside a vnet jail - You can manage per jail firewall instances without any issues. The only firewall which cannot function inside a jail (yet) is PF. P You are incorrect. Here is a list of some of the vnet/vimage outstanding PR's 143808, 147950, 148155, 152148, 160496, 160541, 161094, 164763, 165252, 176112, 176929, 178480, 178482, 179264, 182350, 185092, 188010, 191468 ___ 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: vnet jail and ipfw/nat on host - keep-state problem?
Sham on you Peter Toth.
Slander and calling names about someone who does not agree with you is
childish and something I would expect from a 10 year old.
This foolish post only shows how unprofessional your behavior is.
Sham on you.
Every thing stated by me is the truth and verified by the outstanding
pr's. If you can't trust the PR system as credible, then what can you trust.
I don't disagree that you may have a working vnet/vimage configuration
running on your hobby host system or that your foolishly exposing your
hobby host system to public network attack and host system takeover.
There is a very big difference between software that does not crash when
started and software that performs within its design parameters. I think
just because your configuration does not crash means to you its working
as expected. This is foolish in light of all the negative warnings about
vimage.
vimage is experimental and nothing you say can change that fact. Readers
don't believe me or Peter Toth and review the listed pr numbers and do
your own search of bugzilla on keyword vnet or vimage and make up your
own mind.
Peter Toth wrote:
Dear Joe Barbish (alias fb...@a1poweruser.com
<mailto:fb...@a1poweruser.com>),
When you going to stop trolling the FreeBSD mailing list and spread
disinformation?
People come to this place to learn, share information, help out other
folks and most importantly to have a constructive debate! (obviously
some would rather divert this effort)
The PR number's mentioned are mostly outdated from the 8.x and 9.x
series - some of them are completely irrelevant (like ACPI) or for a
i386 system.
Beyond this I am categorically refusing to waste any energy and time on
answering any trolling/diversion attempts by Joe Barbish.
I am not going to burn time on dissecting each PR one-by-one but rather
share my experience with VNET.
Over the last year and a half have deployed numerous production systems
based on amd64 10-RELEASE with VNET enabled and PF running on the host.
Encountered 0 instability issues! Details on how to do this are
here: http://iocage.readthedocs.org/en/latest/real-world.html
As I mentioned before IPFW works in a jail and PF only works on the host.
Back to the original issue though, Peter could you please share your
IPFW config with me (maybe just send it directly to me), would be very
interested to get it going in my lab setup and add a howto page to share
this with others.
Cheers,
Peter
On Sat, Jul 12, 2014 at 1:16 PM, Fbsd8 <mailto:fb...@a1poweruser.com>> wrote:
Peter Toth wrote:
On Sat, Jul 12, 2014 at 1:33 AM, Fbsd8 mailto:fb...@a1poweruser.com> <mailto:fb...@a1poweruser.com
<mailto:fb...@a1poweruser.com>>__> wrote:
Peter Toth wrote:
Have not used natd with IPFW much as always preferred PF
to do
everything
on the host.
I have only a wild guess - the "me" keyword in IPFW is
substituted only to
the host's IPs known to itself.
The host's IPFW firewall most likely doesn't know
anything about IPs
assigned to vnet interfaces inside the jail.
Vnet jails behave more like separate physical hosts.
Internet ---> [host] --- (10.0.10.0 LAN) -->
[vnet jail]
The PF issue inside a jail is a separate problem, PF is
not fully
VIMAGE/VNET aware as far as I know.
Can someone comment on these or correct me?
P
On Fri, Jul 11, 2014 at 7:11 PM, Peter Ross
mailto:peter.r...@alumni.tu-__berlin.de
<mailto:peter.r...@alumni.tu-berlin.de>>>
wrote:
On Thu, 10 Jul 2014, Peter Toth wrote:
Hi Peter,
Try to make these changes:
net.inet.ip.forwarding=1 # Enable IP
forwarding
between interfaces
net.link.bridge.pfil_onlyip=0 # Only pass IP
packets
when pfil is enabled
net.link.bridge.pfil_bridge=0 # Packet filter
on the
bridge interface
net.link.bridge.pfil_member=0 # Packet filter
on the
member interface
You can find some info
here
http://iocage.readthedocs.org/en/latest/help-no-internet.html
<http://iocage.readthedocs.org/__en/latest/help-no-internet.__html>
<http://iocage.readthedocs.__org/en/latest/help-no-__internet.html
<http://iocage.readthedocs
Re: no network connection from inside a jail
Erich Dollansky wrote: Hi, I recently upgraded to 10.1 BETA3 via sources. All seemed to be fine until I started jails which connect to the Internet. It simply does not work anymore. When the browser from the jail connects to another jail on the same machine via HTTP, it all works. Accesses to the ouside of the machine fails. Even a ping to a local device does not work. ping 192.168.yyy.xxx ping: socket: Operation not permitted despite having security.jail.allow_raw_sockets: 1 Just to make sure, I upgraded also the world in all jails without any difference. UPDATING did not mention any changes since BETA1. I feel a bit lost now. What could have caused the problems? Erich What version of the base system are your jails at? IE: are they at 10.0 or 10.1 xxx or some older version? What method did you use to define your jails [rc.conf or jail.conf]? ___ 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"
Handbook Jail Chapter rewrite available for critique
To all interested parties; I have completed the final draft of the total rewrite of FreeBSD's handbook Chapter 16 on Jails. Before submitting my work for submission to the documentation group for insertion in the handbook I am looking for critique of the work to find errors in concept, wrong use of words, or anything to make it better. All feedback welcomed. Please email me directly so we keep the noise down on the mailing list. Use this URL to access it http://www.jails.a1poweruser.com/ Thank You. ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ 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: Handbook Jail Chapter rewrite available for critique
Nicolas de Bari Embriz Garcia Rojas wrote: Hi, nice document, related to the use of jail.con maybe the use of sysutils/jail2 could be mention since I think makes things a little more easy. I don't know what you mean by "jail.con", But I have reviewed sysutils/jail2 which tries to work with the new /ect/jail.conf file and the jail(8) program. Whats provided with the new handbook jail chapter surpasses what it does in my opinion. related to this: During the development of the jail.conf file method documented here, a few bugs came to light with the jail(8) program which the author has fixed, but which are not included in the 9.1-RELEASE. You can wait for the publishing of 9.2-RELEASE which will contain the updated version of jail(8) or you can download just the source for jail(8) and compile it to use on 9.1-RELEASE. Can you please explain what are the bugs are or any reference with more info? There are no pr's on the bugs I have been working with Jamia Gritton on. He's the author of the jail(8) program. I don't see the need to list them here. But I can say downloading the jail(8) source and doing a make on it this morning has resolved many problems I was experiencing. One of the problems was fixed in the kernel source so downloading a fresh copy and recompiling your kernel will put you ahead of my testing bed. hahaha also any idea/example of how to use the cpuset.id would be appreciated. As I read it, processes running on the host pretty much share all the cpu's across all tasks as they call for service. cupset is all ready available at the host level if I remember correctly. cpuset.id provides a way to give a jail a larger slice of the time slice resources at a cpu level. In simple terms make that jail run faster. On the other side of that same coin it could be used to limit what the jail would normally be getting. All depends how you code the parameter and how many jail definitions it's used in. You may want to give this a try, it's already in 9.1 http://forums.freebsd.org/showthread.php?t=28871 Let me know if you have any success using it on jails. Also if you have time, download those handbook scripts and play around and see it you like what they build for you. regards ___ 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: Handbook Jail Chapter rewrite available for critique
s...@tormail.org wrote: "Fbsd8" wrote: This is my first public exposure. The Doc gang is seeing it for the first time just like you. Gotcha. I also see you're pushing the sysutils/qjail port for users who don't want to configure things themselves. In my experience, ezjail is a much better solution. I also see that you are the maintainer/author of qjail and like to shovel your opinion as the only solution, both in this "rewrite" and all over the FreeBSD forums. Maybe if you gave qjail a try you would have a different opinion of it. Every ezjail user who tries qjail stays with qjail. Maybe if you have read the online version of the handbook jail chapter you would see the doc team has no problem with recommending qjail. The Ports section of the handbook mentions portmaster, portupgrade and maybe even some others. If you include more options than only the one you care about, maybe it could work. I have tried qjail, as have others I know. I'm just saying ezjail has been a lot better for my use case at a webhosting company, where we run many jails per server. You can say "everyone who tries it stays with it" but there's nothing backing that up... at all. I think the userbase is about as inflated as your ego as the author. I don't recommend things based on their author's views (else I wouldn't run OpenBSD firewalls :)) but the constant pushing of qjail as the way and the true light you do really turns me off from it. Do we even need an updated version? I trust the documentation team to write one much more than a biased port maintainer with a poor grasp of English. You must be making a joke to think what is in the handbook jail chapter don't need to be redone. It may need some additions with the recent improvements, but I doubt it needs a complete rewrite. It's not my native language either, but this needs some serious work. Hay dud you going into the un-professional area with comments like that. The FreeBSD team has very high standards for the handbook and documentation in general. You're going into "the unprofessional area" by submitting poorly-written documentation to the project and sending your replies off-list. At no time have I said I have submitted this to the doc guys, I fact the opposite is turn. You even asked me to email you off list. Are you having old age short time memory lost? Don't you read what you write before you re-post My sending you a reply off list was just trying to be considerate of your obvious bad manners. Maybe other readers of this list accept your bad manners but I don't. You are not going to start a flame war with me. As far as I am concerned you are a flamer and have nothing of value to add. I am not going to feed you. You are here by terminated from this thread and as such will be here with ignored by me. Your the one why posted this to the list, now the whole list will be exposed to you failed attempt at a flame war. Please email me directly so we keep the noise down on the mailing list. This is funny. The only thing funny is your post. Be constructive or I will ignore you. It's only constructive if people agree with you, right? ___ 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: Handbook Jail Chapter rewrite available for critique
Andreas Nilsson wrote: Great! There really was a need to modernize the handbook with regards to jails. Since I'm not a native English speaker I'll leave grammar and spelling for those who are ;) My first impressions are along the lines: To much scripts, to few examples/scenarios. Our users are smart, show them what can be accomplished with "high-level" config, leave minutiae to some part of the appendix. The complexities of a a third generation jail system is imposable to explain from the command line. This is already stated in the document. Scripts are a more modern way to cover the over all subject without getting bogged down entering command line commands that the operater can make mistakes and typos and have to start from the begining just to continue. Also the exclusion of zfs and vnet is surprising, as those really make jails shine, imo ( although jails really need to be thought about the "gray" area visa-vi networking in rc-scripts that vnet provides ). How about the resource control, which further makes jails really spiffy. Well lets start with what the documents says about vnet. Its "experimental". I tried to compile it into my test bed 9.1 kernel and the system panicked on first boot. Now really, lets get serious here. Why would I include something that is so obvious not ready for prime time?. There is no way it should be used in a production jail system securing processes exposed to the public internet. It's a use at your own risk application. Maybe down the road when it grows up I will consider adding a sub-chapter about it. But for now its a dead subject. ZFS, Here is another software application just newly introduced as experimental a few years ago. I admit it has come a long way in a short time and is now included in the base system. But its a very big animal and the handbook zfs chapter needs a lot more usage information first. The jail chapter is not the place to be documenting how to utilize zfs. Lets clear up some mis-conceptions. Jails can run on any host that has part or all of it's hard drive space under zfs control. It has no effect on the jail filesystems, matter of fact the jail system is totally un-aware it's on a zfs system. Mounting zfs spaces to the jail filesystem can be done from the host right now. The new jail.conf definition statements has the allow.mount.zfs parameter which allows the running jail to mount zfs space already defined within the running filesystem. It's my understanding it does not allow mounting zfs space from outside of the jailed filesystem. jail.conf does have some exec.* parameters for issuing commands to the host during the jail start process. zfs users have used these to automate mounting zfs data space to a jail's filesystem before the jail really comes to life. It's all in the jail(8) man page. I leave it up to the jail administrator to manage zfs for jail systems. Again it's not the jails job to manage zfs. I would have preferred top-level separation of the different methods, ie after the introduction there was one "track" manual, one for old-school rc-, one for new-school rc- and one for jail.conf-style jails. More specifically I agree with Isaac Levy's, especially in regards to the "jail cell" terminology: "16.1 Synopsis": the term jail cell is used, long before being defined. "16.2 Introduction": Mentioning jail cells in a historic contest is imho a "blatant" lie ( they were never known as such ). As far as I know, no official documentation has called them cells, either. That does not mean that it's not an appropriate term, though. As a contrast there is Solaris vocabulary of zones ( "cells" ) and global zone ( "jail system" ). In this regard I prefer the solaris one. Most importantly, a large chunk of 16.2 would imo fit much better as a "history"-appendix. Current and new users don't need to know and consider the limitations of earlier implementations. The "generations" talked about could perhaps be quantified with a release version :) Read this section again. it's not meant to be a history lesson. it's meant to expose the reader to the progress of the chroot and how the jail filesystem of that time affected performance and ease of use, leading up to the third generation jail filesystem documented in the new jail chapter. There are, as stated by Isaac Levy, many (good) utils for managing jails. Why the focus on qjail? I also think that most of the strong points of jails are rendered moot without, in order, zfs and vimage. Linux jails might also interest quite a few people. For real, Linux jails documented in the FreeBSD handbook? You have to be joking. Give qjail a ride and you will see that it's light years ahead of any of those ports you speak of. You really have to take time and digest what you read. It has to be read as a whole not as some limited selection of parts. It will all make sense after a few reads. Thanks for the feedback. Joe
Re: Handbook Jail Chapter rewrite available for critique
Ian Smith wrote: On Tue, 19 Mar 2013 17:53:30 +0100, Dirk Engling wrote: > On 18.03.13 20:16, s...@tormail.org wrote: > > > to configure things themselves. In my experience, ezjail is a much better > > solution. I also see that you are the maintainer/author of qjail and like > > to shovel your opinion as the only solution, both in this "rewrite" and > > all over the FreeBSD forums. > > Taking a look at the qjail code I can not help to notice several odd > similarities with the ezjail-admin script, down to the very basic bail > out routines. I would not go so far to claim it was just a global > search/replace job but to me the code looks familiar enough to find the > > # Copyright 2010, Qjail project. All rights reserved. > > offensive. I am usually quite open with the license of my software, > beerware is as permissive as it gets. I just can not take some script > kiddie right out copying my code verbatim and selling it as his, not > even acknowledging me as the original author. > > Anyone here with suggestions how to properly react to this kind of "fork"? Yes. Publicity. Making sure the FreeBSD community gets to finds out. You may be polite and un-selfserving enough to not go so far Dirk, but I will. Huge swathes of qjail are direct copies of your code, in most cases only with the names of the variables changed from ezjail_* to qjail_*. I found it cute renaming 'flavour' to the American spelling. Anyone looking at bin/qjail from qjail-2.1.tbz alongside the latest ezjail-admin (mine downloaded from your cvsweb) cannot fail to notice within the first couple of screens. Sure there are changes, additions and deletions, but to fail to acknowledge the original authorship of this code, and the implication that Joe Barbish (aka 'Qjail project') is its original author is entirely outrageous; not ethical, even if legal. To that end I'm cross-posting this to -questions, where Mr Barbish has also posted about his proposed "rewrite" of Chapter 16 of the Handbook, which is nothing but a huge and poorly written manual for 'the qjail way', with its peculiar assumptions and unique "jailcell" terminology. "Fourth Generation", no less! The idea that the "doc gang" would entertain the idea of removing all of the worthy content of the present Chapter 16 - even if it does need some updating - and replace it with this effort is laughable, yet stranger things have happened if there's any disconnect between developers and documenters .. witness the Handbook firewalls section, by Joe Barbish. cheers, Ian Boy this simple critique request sure has gotten out of hand. So lets set the record straight. On the subject ezjail not being referenced in the document like it is in the current version of the online handbook is just a writing content error. The document being critiqued is the first public draft. Pointing out over sights like not included ezjail in that section is the type of constructive feedback that is desired. Any inference it was done on purpose is just crazy. When it comes to the question of the handbook jail chapter needing updating, A member of the document team has already offered to partner up with me to get it added to the handbook as fast as possible. To me that means the document team is already aware the current handbook jail chapter is outdated and has just been waiting for someone to write a update which is just what I did. If you people have a beef with that, take it up with the document team not me. If any of you think you can do a better job then NOW is the time to step up or shut up. On the subject of qjail being a fork of ezjail, of course it is. Qjail was developed by the qjail project team who are a group of FreeBSD users who live around Angeles City, Philippines. Of the seven members 2 are foreigners living in the area, one American and one British. Our British member concluded that the author of ezjail must be British based solely on the spelling of the flavour directory. He also convinced us that his Beerware license was British humor, a joke, and should not be taken serous. In our review of other jail ports we did not see this Beerware license again or for that matter, see it in any of the 5000+ ports we looked at or use. So the group coincided to the British members view point as sound advice. If you inspect the qjail source, you should recognize the comments at the beginning as a copy of what is included in every FreeBSD config file. It was inserted in the front like they have. We though that was how you make software opensource which was the intention. There are no formal copyright documents; it's just a extrapolation from the FreeBSD comments. Maybe our local view of worldly subjects like this is not correct, so please forgive us and help use learn what the accepted viewpoint should be. I was chosen the project leader and public voice only because my English was the best among us. If the Freebsd c
Re: Handbook Jail Chapter rewrite available for critique
s...@tormail.org wrote: On Fri, Mar 22, 2013 at 6:12 PM, Fbsd8 wrote: Boy this simple critique request sure has gotten out of hand. So lets set the record straight. You got exactly what you asked for. On the subject ezjail not being referenced in the document like it is in the current version of the online handbook is just a writing content error. With all the spam you've put on the forums and mailing list(s) about qjail, I wonder how true it is that you just "whoops, forgot to mention ezjail" in your propaganda rewrite. When it comes to the question of the handbook jail chapter needing updating, A member of the document team has already offered to partner up with me to get it added to the handbook as fast as possible. The documentation team will never accept such poorly-written stuff that's laced with "use qjail use qjail use qjail - it's the only way!" I'll believe it when I see it. On the subject of qjail being a fork of ezjail, of course it is. Forks don't completely overwrite the copyright of a project and claim it as their own, while just changing variable names and renaming the tool something else. This is not a fork, it's a complete rip-off that gives no credit to the original author (who did MUCH more of the work). Qjail was developed by the qjail project team No it wasn't. It was developed by the ezjail author, and you just made small changes and called it your own. Our British member concluded that the author of ezjail must be British based solely on the spelling of the flavour directory. He also convinced us that his Beerware license was British humor, a joke, and should not be taken serous. I think the GPL is a joke, but people still take it seriously. You can't just decide a license should be completely ignored. I was chosen the project leader and public voice only because my English was the best among us. It gives me a headache trying to read some of the stuff you write. You've got an American guy and a British guy and neither of their native English is better than yours? Sib your unfounded ranting and raving only demonstrates you are off your medication for your anti social behavior mental condition. Sending the above post to the list after removing the subject line to hide from your fellow list subscribers only confirms your mental condition. I have re-applied the correct subject line so the list readers can see how sick you really are. Your post is un-professional and borders on slander. In some circles it would label you as a flame war inciter and get you banned from the list. Best you read what you write before posting it so you can reconsider the tone of what you have written. Please present a more professional manner in your list post content. Thank you in advance for your attention to this matter in future posts to this list and any other Freebsd lists you may belong to. If you are unable to control your anti social impulses I suggest you seek medical treatment immediately before you do bodily harm to your self or to someone who loves you. I am only expressing my concern for you physical and mental health well being. If you contuine to pursue this nonsense your actions will force me to contact the list administrator to have you banned. This is your only warning. ___ 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:qjail fork attribution was Handbook Jail Chapter rewrite available for critique
Dirk Engling wrote: Dear JoeB, since you just threatened me via private email to expose my evil plans of preventing your ubercool project from taking FreeBSD by storm, I would like to comment on your views and your project publicly On 22.03.13 23:12, Fbsd8 wrote: On the subject of qjail being a fork of ezjail, of course it is. So, you've decided to run along with an existing code base to fork a project. Congratulations. You surely must have had reasons, like including features that the original author told you never to implement. Like you found the project abandoned and no one replied to your requests. Well, except you did not. I found out about your fork by chance, after someone directed my attention to your constant bragging and nagging. Why, after all, would you ever feel the need to talk to me directly about the fork? After all, what common interests might we possibly share? So I think the only reason to rip off ezjails code was to boost your ego with some impressive looking column of shell script you obviously had trouble understanding, which comes as no surprise as you _still_ seem to have trouble grasping even the basic concepts of shell scripting: http://lists.freebsd.org/pipermail/freebsd-questions/2013-January/248558.html http://lists.freebsd.org/pipermail/freebsd-questions/2013-January/247723.html Reading this I find it very disturbing that you try to lure users into using your bumbling hack that pokes in one of the core security features of FreeBSD. To put it more plainly: What you do is dangerous. Stop doing it. You're putting your users at risk. British member concluded that the author of ezjail must be British based solely on the spelling of the flavour directory. He also convinced us that his Beerware license was British humor, a joke, and should not be taken serous. In our review of other jail ports we did not see this Then tell your "British member" to read up on some contemporary literature, maybe Wikipedia http://en.wikipedia.org/wiki/Beerware so he has a chance to understand what connects Beerware and FreeBSD. Do not use your confused team member as pretext to violate the terms of license you obviously found by yourself and chose to ignore. file. It was inserted in the front like they have. We though that was how you make software opensource which was the intention. There are no formal copyright documents; it's just a extrapolation from the FreeBSD comments. Besides completely failing to see the point what the difference between open source and public domain is, you do not have the slightest idea, what a community of people sharing their code as open source is about. The simple fact that you resort to Windows and IIS to serve your web site should have warned me, that you do not actually have any connection to the scene besides your gimme-gimme-gimme attitude. To make my point clear: Open source software is about attribution. For multiple reasons, most important to me: getting to socialize. Beerware is not so much about getting the actual beer, but to have a chance to sit together and talk with people sharing common interests. Now you rob me of the chance to ever hear from people using my code disguised as yours. Another reason, of course, is the pride we take in spending nearly ten years on ezjail and we definitely do not like some script kiddie running around adorn himself with plumes plucked from our asses. section is not appropriate to include qjail under Freebsd opensource type of license, then we can change the comments to say "totally free to do as you wish as opensource" and leave it at that. If something else is needed, please inform what that is by private email. To continue this this subject in public is not appropriate. Please respect our wish in this matter. No, I will not respect your wishes, as you chose to ignore mine. You are not totally free to do as you wish with the ezjail authors' code and you can not grant that rights to someone else. Regarding your fork: I can not and I will not prevent forks from happening. So I wish you good luck with it. Maybe you learn some shell on the way. The qjail port has been marked RESTRICTED by the ports managers and I will withdraw my concerns once you find a proper way to indicate original authorship in a humble way. Regards, erdgeist Dear Dirk Engling I feel sorry for you. I man with such talent and respect has fallen to such a level of self induced public humiliation. This outburst only confirms my suspicion that your suffering from dementia caused by advancing age. I tried to give you a way to save face as I purposed in my private email to you. But now that you have moved things into the public light you force me to publicly point out just how confused your thinking is. The FACT is the ezjail-3.2.3 port currently in the port system contains NO verbiage concerning any type of license. Even the ezjail Makefile doesn't invoke the BSD
