From: "James Carlson" <[EMAIL PROTECTED]>
Erik Nordmark writes:
> It depends on the administrator's mental model for the system.
Agreed. My point is that the model for an exclusive-IP zone is different
in important aspects than the shared-IP zones.
And in other important aspects it's the same
Erik Nordmark writes:
> > It depends on the administrator's mental model for the system.
>
> Agreed. My point is that the model for an exclusive-IP zone is different
> in important aspects than the shared-IP zones.
And in other important aspects it's the same: it's still a single
shared kernel a
James Carlson wrote:
In some usage models, the global zone administrator "owns"
everything. Even if he can't directly control things from the global
zone (and must log into the non-global zone to turn services on and
off), he wants to see a view of the system that includes everything.
Do you h
[EMAIL PROTECTED] writes:
> >> I tried the kill and AFAICT root in the global zone can kill a process
> >> in a non-global zone:
> >
> > OK. I must be misremembering this. I thought the restriction was
> > more complex than that.
>
> Within the global zone, the ability to kill a process in a non
I tried the kill and AFAICT root in the global zone can kill a process
in a non-global zone:
OK. I must be misremembering this. I thought the restriction was
more complex than that.
Within the global zone, the ability to kill a process in a non-global
zone is controlled by the "proc_zone" pr
As Dan pointed out, there are already other commands such as
ifconfig(1M) and mount(1M) which manipulate or observe resources
assigned to a zones so using dladm(1M) wouldn't be that inconsistent.
Yes, but those provide for manipulation (aka change) and observability in the
same place.
However
Erik Nordmark writes:
> James Carlson wrote:
> > Erik Nordmark writes:
>
> >> But the key thing to me is the consistency between where things can be
> >> observed and where they can be modified.
> >
> > We already have RFEs filed against other utilities because they don't
> > show non-global zon
James Carlson wrote:
Erik Nordmark writes:
But the key thing to me is the consistency between where things can be
observed and where they can be modified.
We already have RFEs filed against other utilities because they don't
show non-global zone activity (see, for example, CR 6369726). I th
[EMAIL PROTECTED] wrote:
If we want any form of internal consistency, wouldn't we also need to
change were we assign datalink names from zonecfg to dladm?
Thus no more 'net' resource in zonecfg for exclusive-IP zones, but
instead some
dladm set-zone zoneA bge1
Only having dladm show it,
Erik Nordmark writes:
> James Carlson wrote:
>
> > I don't think that argument works on two counts. First, exclusive-IP
> > behavior does not offer complete IP isolation, because you can't (for
> > instance) install your own copy of Firewall-1 or Cisco VPN into a
> > non-global exclusive-IP zone.
James Carlson wrote:
I don't think that argument works on two counts. First, exclusive-IP
behavior does not offer complete IP isolation, because you can't (for
instance) install your own copy of Firewall-1 or Cisco VPN into a
non-global exclusive-IP zone.
Agreed you can't do that. But how do
If we want any form of internal consistency, wouldn't we also need to change
were we assign datalink names from zonecfg to dladm?
Thus no more 'net' resource in zonecfg for exclusive-IP zones, but instead
some
dladm set-zone zoneA bge1
Only having dladm show it, and not be able to aff
Erik Nordmark writes:
> Jeff Victor wrote:
> > Here's one reason: consistency. All users in the GZ can see some
> > inforamtion about non-global zones (e.g. "ps"). Privileged GZ users can
> > see all info about non-global zones, and need to do so in order to
> > manage them.
>
> But the exclu
Eric Enright wrote:
I'd like to express interest in this as well. Just last week I came
across the need for this, and was disappointed to learn that it (or
something similar) is not there.
Would
zoneadm list -l
as specified (with example output) in
http://www.opensolaris.org/os/proje
Darren Reed wrote:
- Original Message - From: "Erik Nordmark" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
Could "ifconfig" be modified to report all network interfaces that
are assigned to a zone?
I assume you mean in the global zone; ifconfig -a inside a zone
(global or not) does
Jeff Victor wrote:
Here's one reason: consistency. All users in the GZ can see some
inforamtion about non-global zones (e.g. "ps"). Privileged GZ users can
see all info about non-global zones, and need to do so in order to
manage them.
But the exclusive-IP behavior is quite different from t
Darren Reed wrote:
- Original Message - From: "Erik Nordmark" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
Could "ifconfig" be modified to report all network interfaces that
are assigned to a zone?
I assume you mean in the global zone; ifconfig -a inside a zone
(global or not) does
- Original Message -
From: "Erik Nordmark" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
Could "ifconfig" be modified to report all network interfaces that
are assigned to a zone?
I assume you mean in the global zone; ifconfig -a inside a zone (global
or not) does report all the netwo
[EMAIL PROTECTED] wrote:
Yes, that's one of the reasons I suggested having dladm(1M) be the
place to display this information since it's where links are
administered in general, even the ones that will be handed off to
exclusive-stack zones.
David,
If we want any form of internal consistency,
The reason is that ifconfig in the global is not involved in configuring IP
for the exclusive-IP zones; that is done by ifconfig running inside the
exclusive-IP zones.
This is by design different than the IP configuration for the shared-IP
zones; those are both configurable as well as observable
[EMAIL PROTECTED] wrote:
Could "ifconfig" be modified to report all network interfaces that
are assigned to a zone?
I assume you mean in the global zone; ifconfig -a inside a zone (global
or not) does report all the network interfaces that are configured.
But that would be quite odd.
The r
Eric Enright wrote:
I just subscribed to this alias, apologies if I'm missing anything
from this thread...
Some of this was discussed a few months back.
I'd like to express interest in this as well. Just last week I came
across the need for this, and was disappointed to learn that it (or
som
On Fri 03 Nov 2006 at 04:57PM, Erik Nordmark wrote:
> Dan Price wrote:
>
> >>'list -i' religiously follows this idiosyncratic approach ;-)
> >
> >We have a plan to add 'zoneadm info' or some such to display all the
> >runtime attributes of running zones. Hopefully we'll get to that in the
> >next
Erik Nordmark wrote:
Dan Price wrote:
'list -i' religiously follows this idiosyncratic approach ;-)
We have a plan to add 'zoneadm info' or some such to display all the
runtime attributes of running zones. Hopefully we'll get to that in the
next 12 months or so. I'd request that you hold
Dan Price wrote:
'list -i' religiously follows this idiosyncratic approach ;-)
We have a plan to add 'zoneadm info' or some such to display all the
runtime attributes of running zones. Hopefully we'll get to that in the
next 12 months or so. I'd request that you hold off on adding list -l
un
On Fri 03 Nov 2006 at 09:42AM, Erik Nordmark wrote:
> Thus if instead of using zonecfg to configure the boundary of the zone,
> things were spread across different commands (use dladm to assign link
> names to zones, use some zpool command to assign pools to zones, use zfs
> commands to assign z
Peter Memishian wrote:
> > > With regard to the third bullet, please see my concerns above about the
> > > introduction of "list -l". I think this should be part of a general
> > > zone status/health facility or perhaps something that dladm(1M) can
> > > print about the link names and ho
> > > With regard to the third bullet, please see my concerns above about the
> > > introduction of "list -l". I think this should be part of a general
> > > zone status/health facility or perhaps something that dladm(1M) can
> > > print about the link names and how their assignment zone-
Peter Memishian wrote:
> With regard to the third bullet, please see my concerns above about the
> introduction of "list -l". I think this should be part of a general
> zone status/health facility or perhaps something that dladm(1M) can
> print about the link names and how their assignment z
> With regard to the third bullet, please see my concerns above about the
> introduction of "list -l". I think this should be part of a general
> zone status/health facility or perhaps something that dladm(1M) can
> print about the link names and how their assignment zone-wise.
Displaying th
30 matches
Mail list logo