Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Apr 2013 14:53:11 +1100 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Dirk Engling <erdgeist@erdgeist.org>
Cc:        freebsd-jail@freebsd.org
Subject:   Re: rc.d/jail and jail.conf
Message-ID:  <20130401140510.Y56386@sola.nimnet.asn.au>
In-Reply-To: <5158A379.2030702@erdgeist.org>
References:  <515721F8.9090202@erdgeist.org> <51574D3F.9040300@quip.cz> <51588435.2010400@erdgeist.org> <51589607.7040401@quip.cz> <5158A379.2030702@erdgeist.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Mar 2013 22:58:33 +0200, Dirk Engling wrote:
 > On 31.03.13 22:01, Miroslav Lachman wrote:
 > 
 > >> So I guess, I am out of luck here, because users used to think of their
 > >> jails as what they saw in the hostname field on jls. If I am writing
 > >> tools that use jail_getid to map the jailname to the jid, it will never
 > >> match that hostname and I also can not copy the hostname to the jailname.
 > > 
 > > I understand what you are talking about, but jails in these days are
 > > something different from what jails were at the begining in 4.x days and
 > > users must accept that jailname is something different than hostname.
 > 
 > > In these days, you can have jails with many IP addresses or without IP
 > > address. Hostname needn't to be unique etc.
 > >
 > > Dot (.) is not allowed in jailname because of hierarchical jails,
 > > where dot is used as hierarchy separator.
 > 
 > Humm, this seems a strange thing to answer to my question. Once you see
 > jails as virtual servers (which I understand is not the only way to do,
 > but the biased way I and most jail users I talk to happen to deploy them
 > in huge quantities), the natural approach to name them is via their
 > hostname. I find it hard to grasp to tell them "don't" ;)
 > 
 > And still I find the choice of '.' as a separator unfortunate, '/'
 > springs in mind, but there might have been reasons.

'/' would be just as problematic if you wanted to use jailnames as 
directories anywhere.  ':' maybe?  but likely too late for that ..

 > I also understand that the hostname is not an unique identifier anymore,
 > still for many (if not most) setups the mapping is bijective.
 > 
 > My problem now is that referring to a jail (in a sense of virtual host)
 > becomes unintuitive. I want to do stuff with my vhost "example.com" but
 > have to call it "example" or "example_com". Even worse with
 > "www.example.com" which now needs to be an ambigous "www" or some other
 > mapping of '.' to something else.
 >
 > If I want to write tools that accept intuitive jail identifiers, I would
 > have to implement heuristics that match the hostname once the identifier
 > contains '.' and I can't find a hierarchical jail with that name.

Consistent mapping of a fqdn's '.' to '_' might be more POSLA (slightly
less astonishment :) for these users?  Of course if they do want to use 
hierarchical jails they still need to know what '.' means and does, but 
then I guess people setting up and running jails-within-jails are going 
to need to have their heads screwed on pretty tightly anyway ..

 > > Plain jls without any options should be used just for backward
 > > compatibility with old scripts, because its output is insufficient for
 > > todays jails. (only one IP is shown and no jailname)
 > > 
 > > jls -v or jls -s is better with new jails.
 > 
 > Maybe it would be easier for me to understand if I knew, how those jails
 > "in these days" are supposed to work, what the overall vision is for
 > users to integrate them in their workflow. Besides a wish list that
 > doubles as todo list in
 > 
 >   https://wiki.freebsd.org/Jails
 > 
 > and an attempted handbook section rewrite, there seems to be little in
 > that regard. Maybe I just missed out on the discussions or could not
 > find the relevant documents?
 > 
 > Maybe meeting at a BSDcon over a beer would help ;)

Unlikely to hurt, anyway :)

cheers, Ian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130401140510.Y56386>