updating ezjails with freebs d-update
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
>>> 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
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
> 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.
>>> 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