updating ezjails with freebs d-update

Fbsd8 fbsd8 at a1poweruser.com
Mon Aug 25 15:10:11 UTC 2014

Warren Block wrote:
> On Sun, 24 Aug 2014, doug at 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 

>>> 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 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. 

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.

More information about the freebsd-questions mailing list