Date: Mon, 25 Aug 2014 11:04:34 -0400 From: Fbsd8 <fbsd8@a1poweruser.com> To: Warren Block <wblock@wonkity.com> Cc: doug@safeport.com, freebsd-questions@FreeBSD.ORG Subject: Re: updating ezjails with freebs d-update Message-ID: <53FB5082.40905@a1poweruser.com> In-Reply-To: <alpine.BSF.2.11.1408241947250.2348@wonkity.com> References: <alpine.BSF.2.00.1408240008220.65526@bucksport.safeport.com> <53FA18FD.1060309@a1poweruser.com> <alpine.BSF.2.00.1408241740340.73111@bucksport.safeport.com> <alpine.BSF.2.11.1408241947250.2348@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warren Block wrote: > On Sun, 24 Aug 2014, doug@safeport.com wrote: > >> On Sun, 24 Aug 2014, Fbsd8 wrote: >> >>> You can disregard most of that new handbook jail ezjail section. > > Thanks for your input. I can assure you that the document was reviewed > by members of the freebsd-doc mailing list, on IRC, and in private > email. Mistakes and omissions were found and corrected. It's not > perfect, but serves the purpose of an overview of using ezjail. It also > serves a second purpose, showing how to set up bind99 in a jail. This > quick overview of a jailed BIND is useful for those wishing to improve > BIND security now that the old chroot option is not available in the port. > I emailed you off list about the items voiced here and as the resulting handbook shows you still went ahead and published it anyway with all the mis-leading information included. By the way, there is a chroot port, it named qchroot and is very user friendly. >>> First of all the current version of ezjail uses the /etc/rc.d/jail >>> script method. This method is depreciated in FreeBSD version 10.0 and >>> scheduled to be removed in FreeBSD version 10.1 or 11.0. The section >>> should have contained a red warning box informing the reader that >>> this documentation only applies to Freebsd 10 and older releases. > > When that actually happens, a warning can be added. Or ezjail may be > updated by then. For now, it is not needed. > There are red box warning in the handbook already where the reader is informed that documentation only applies to older versions of Freebsd. Following those examples sure would not hurt at this time for your ezjail section. You could always remove the red box later, if and when ezjail gets updated to use jail(8). FreeBSD 10.0 automatically converts /etc/rc.d/jail script method defined jails to jail(8) definitions on the fly at jail start up along with a warning message that what their doing is depreciated and to change to jail(8) method. If I was a newbe to jails and I got that message I sure would not go to bed with software that is depreciated right out of the box. A warning in the handbook would have given me the background info necessary to make an informed decision. >>> On the subject of a jails loopback interface. Jails don't have >>> loopback interfaces or use them. Sure you can assign one but it's >>> really a definition error which the jail(8) program does not issue a >>> error message for. All reference to the loopback interface should be >>> removed from this section as its very mis-leading to the reader and >>> unnecessary. >>> >>> I installed bind99 in a jail(8) jail with out any lo1 or 127.0.0.1 ip >>> address and it worked just fine. > > The loopback clone information was added on the advice of the FreeBSD > cluster administrators. It keeps jail loopback traffic off the host > interface, and I understand it was an approach they took due to actual > problems. Then your source must not understand their problem correctly. Just think what you are saying, that jails have access to the hosts loopback facility. This violates the whole jail concept. The whole jail concept is based on jails not having any access to host services. Sure you can code a faulty IPv4 parameter that includes the new interface name option of lo0 or lo1, but that is a codding error which jail(8) does not issue a error message on. Just because no negative effects occur when doing so is no reason to assume jails use the hosts lo0 interface or need there own lo1 to function. Some real live jail testing would have proven this out. >>> Adding a password to jails "root" user is a waste of time and effort. >>> ezjail already requires the user to have "root" access on the host >>> before the "ezjail-admin install" command will function. > > ezjail-admin is not the only way to access a jail. Many run sshd, for > example. It is bad practice to have a root account with no password, > and I always try to show best practices. > Yes if the host jail administrator wants to grant some jail user ssh root access, then a root password would be required. But just because some jail has a user login account to the jail for user ssh access, the root user account is still denied access just like on the host. Adding a jail root password as standard procedure is not required like the handbook new jail section makes the reader think. It should be removed from the handbook. >>> Editing the jail's /etc/hosts file and changing the ip address to the >>> jails ip address and adding the jailname to the localhost entries is >>> totally unnecessary. Jails work fine using the default hosts file. > > Again, thanks for your input. > If your saying you agree with this, then how about removing it from your new jail section so as not to mis-lead the reader that it's required? >>> How can the handbook recommend using a utility tool that has a >>> incomplete manual which is missing details about the utilities >>> sub-commands. > > If an incomplete manual was grounds for exclusion, the Handbook would be > a much shorter document. ezjail is extremely popular, and not including > it in the Handbook was an oversight that needed to be fixed. Qjail is also extremely popular and you should have included a qjail section. Are you saying that since you have commit authority for the handbook that you would commit a section about qjail? I already wrote a new jail section for the handbook and made it into a port called jail-primer. https://www.freebsd.org/cgi/ports.cgi?query=jail-primer&stype=all The long description says this A simplified prospective on jail configuration and usage. Complete easy to understand detailed documentation on creating a Third Generation Jail System Solution which is based on a single filesystem that contains all of the required operating system executable libraries which is shared with each of the individual jails. The legacy rc.conf method, Modern rc.conf method, and the jail(8) jail.conf methods are documented. Scripts are included that perform the tasks explained in the documentation. WWW: http://jail-primer.sourceforge.net/ > >>> In my opinion this new section should have never been added to the >>> handbook until after ezjail gets updated to use jail(8) and it's >>> manual is updated to contain details about all it's sub-commands. > > Given that ezjail works on all supported releases of FreeBSD, this seems > a bit extreme. If and when that situation changes, the section can be > easily updated. > The handbook is very static and never kept up to date. It's not right to place things in the handbook that are depreciated even before being published in the handbook without some kind of warning. >> Thank you, most helpful > I think ezjail is a good utility and recommend it to any host administrators who wants a tool to simplify jail admin of a couple of jails and or uses zfs for jail filesystems. On the other hand, I recommend qjail for simplified admin of jail environments larger that 3 jails. qjail also has vnet/vimage function which ezjail does not have. qjail's manual is complete and contains detailed information on usage. qjail uses the jail(8) method which allows the usage of pre-defined zfs data areas. The reader should test both ezjail and qjail and decide for them selfs which one best serves their needs. > Fbsd8 neglects to mention the history between ezjail and the qjail fork > of it. A search on "ezjail and qjail" will help fill out the picture. > Shame on you Warren. For someone who has worked so hard to earn the respect of his peers and here you try to use slander in a effort to discredit what I have posted in this thread. I know that you know that is unacceptable behavior. Let me set the record straight once again. While working for one of the largest ISP's in the Philippines, to save money I converted them from Microsoft servers to FreeBSD. Using jails we saved a lot of money on no-longer needed computer equipment. But native jails are so hard to maintain and administrate after a few jails. We started to use ezjail and soon came to realize it's many short comings. We decided to develop our own fork of ezjail. ezjail copyright says to "buy me (the author) a beer if we ever meet". The ISP's attorney read that and told us that was some kind of British humor, and it was ok to fork it. We rewrote a large chunk of the code to make it simple to be maintained by the junior script programmers we have on staff, added many functions to make it user-friendly. After using it in-house for a while we got permission from the ISP management to make a FreeBSD port of it as we wanted to give back to the FreeBSD community. To our great surprise a big stink was made of the standard FreeBSD copyright we put on it. As a 3rd world country and people who never did a port of a forked utility before we were totally unaware of the un-documented custom to give credit to the original work we had forked from. People jumped to the conclusion that this was done on purpose which was totally incorrect. A updated version was immediately published to correct this copyright mis-understanding. So Warren show some professionalism and apologize for your mistake in judgment bring up this dead copyright mis-understanding which has absolutely no bearing on the facts, opinions and comments contained in the content of this questions list thread.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53FB5082.40905>