Is there such a thing as a command I can run in the global zone which will tell
me who is logged into my non-global zones?
Peter
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
hi Octave, thanks much for the comments.
However, I think there's a need to take a few steps back...
The requirements you list are things that seems to me to be: once we
have decided that we want an NFS server in a zone, these are important
things that should be true of the delivered product.
Hi,
Read below..
--- Calum Mackay [EMAIL PROTECTED] wrote:
hi Octave, thanks much for the comments.
However, I think there's a need to take a few steps back...
The requirements you list are things that seems to me to be: once we
have decided that we want an NFS server in a zone, these
Calum Mackay wrote:
hi Octave, thanks much for the comments.
scrap projects. Probably the most common idea for having a zone NFS
server is for Jumpstart or home directories. As things stand today,
it's not doable.
Right, but these things are easily done (of course) using a server in
the
So could we all agree that:
An NFS Server in a zone means that the namespace it exports is
restricted
to that zone only. By that i mean no global zone access to that
namespace,
nor would that namespace be re-exported within another NFS Server zone
instance ?
btw: Team NFS is acutely
Robert Gordon wrote:
So could we all agree that:
An NFS Server in a zone means that the namespace it exports is restricted
to that zone only. By that i mean no global zone access to that namespace,
Unless I misunderstand you, we have no choice - the global zone's namespace is
separate
It sounds like we're saying that NFS is just a basic system service that
we want to provide from our already existing - and independently-managed
- zones, rather than setting up zones specifically to provide separate
NFS services (with the various exceptions e.g. Jumpstart testing).
That
And here is a link to the bug which is tracking NFS in zones:
http://bugs.opensolaris.org/view_bug.do?bug_id=4964859
Note that the description sucks right now as far as OpenSolaris is
concerned. I'll
get the relevant comments back into the description.
BTW: I crossposted to all of the
On Feb 14, 2007, at 12:47 PM, Jeff Victor wrote:
Robert Gordon wrote:
So could we all agree that:
An NFS Server in a zone means that the namespace it exports is
restricted
to that zone only. By that i mean no global zone access to that
namespace,
Unless I misunderstand you, we have
Robert Gordon wrote:
So could we all agree that:
An NFS Server in a zone means that the namespace it exports is restricted
to that zone only. By that i mean no global zone access to that
namespace,
nor would that namespace be re-exported within another NFS Server zone
instance ?
I
Robert Gordon wrote:
...
I'd even go further and say that any user
in the global zone would not have access to /export/z1.
...
This is already the case. The mode on the final zonepath
directory must be 700. This is set when zoneadm installs
the zone and verified when you do normal zone
Menno Lageman wrote:
Robert Gordon wrote:
So could we all agree that:
An NFS Server in a zone means that the namespace it exports is
restricted
to that zone only. By that i mean no global zone access to that
namespace,
nor would that namespace be re-exported within another NFS Server
On Wed, Feb 14, 2007 at 01:11:06PM -0600, Robert Gordon wrote:
so lets say /export/z1 is the root of zone1; and it contains a directory
that is called export. Zone1 exports it's /export, which is in reality
the global zones /export/z1/export.
I'm asserting that the global zone will not be
Nicolas Williams wrote:
I'd even go further and say that any user
in the global zone would not have access to /export/z1. [...]
But if we resolve loopback NFS mount issues then any zone could access
any other zone's NFS shares provided they have logical or
Calum Mackay wrote:
It sounds like we're saying that NFS is just a basic system service that
we want to provide from our already existing - and independently-managed
- zones, rather than setting up zones specifically to provide separate
NFS services (with the various exceptions e.g. Jumpstart
Tom Haynes wrote:
What about the case where the customer wants to administer the zone they
purchased
and they do not want the global zone admins to have local access to
their data?
Well, there is a tradition in Zones of making the global zone
substantially more equal than others. Remember
[EMAIL PROTECTED] wrote:
4) A bug currently prevents a client instance and a server instance
from being safe to use on the same box (apologies, can't quote the
bugid from here). How likely, in your use case, is it that this will
be a problem, i.e. will your boxes be in the position where a
Are there any pros/cons to using a global zone to host a service/app just as
you do on the local zones (i.e. the global zone serves as just another host
with the added responsibility of managing local zones)? Are there any
pros/cons to using the global zone only as an administrative zone,
Trusted Exensions already includes this functionality, although the
implementation is not exactly what is being requested in this thread. In
the case of Trusted Extensions, the global zone administrator determines
which labeled zone directories may be exported via NFS. There is unique
dfstab
On Wed, Feb 14, 2007 at 03:27:30PM -0600, Robert Gordon wrote:
There maybe a conflicting security requirement here. Lets say
I'm SA of the zone and i have exported /export/foo with krb5i
(since my foo really needs tight security :) ) to a limited
set of clients. Then along comes Mr Global SA
In addition, if you can run that ssh service in the global zone on an interface
on an admin network. I try to give the global zone an interface on the admin
network only with public interfaces reserved for non-global zones only.
John Clingan
Sun Microsystems
Sent from mobile phone.
Tom Haynes wrote:
What about the case where the customer wants to administer the zone they
purchased
and they do not want the global zone admins to have local access to
their data?
That would violate basics of the zones model. The global zone admin has
complete access to all devices
Robert Gordon wrote:
On Feb 14, 2007, at 3:17 PM, Edward Pilatowicz wrote:
this all makes logical sense to me.
i would refine your second point though because it doesn't take into
account lofs mounts.
ex, if i have /export/foo in the global zone and then in zonecfg i
configure a
2) Lack of requirements - we don't know what people want.
In addition to the requirements already stated by others, another
crucial one is a resolution of the infamous NFS/VM deadlock. There
have been numerous bugs filed over the years concerning it but I
believe the current one is
[EMAIL PROTECTED] wrote:
Excellent results were obtained! managed to create 5 zones on on T2k and
another 4 on a 2nd T2k. Error msgs (as described) on one, no error messages
on the other. And all the zones behaved perfectly. Gratifying. Thanx to
everyone who contributed...
It seems there is a
However, there a good shot you can
run those RH 3.8 services in zones natively (depending on the service).
FWIW, I am working with customers running many more than 5 zones on a T2K.
John Clingan
Sun Microsystems
Sent from mobile phone.
-Original Message-
From: Jeff Victor [EMAIL
Hi,
--- [EMAIL PROTECTED] wrote:
1) I think there are a variety of use cases that may have disjoint
requirements from consolidation, and I want to hear about them, too.
One example we had awhile back - SAS shares some of its data via NFS,
and loses this ability in a zone. Do they need
Hi Robert,
Excellent point! I think this is a good example of why the same
physical path can't be shared from a zone and the global zone at the
same time. Perhaps excluding any zonepaths from being shared at the
global zone is desirable if the nfs switch for that zone is turned on?
Octave
---
Robert Gordon wrote:
it seems to me that both the local zone and the global zone
should be able to export it (or not export it) independantly.
ed
There maybe a conflicting security requirement here. Lets say
I'm SA of the zone and i have exported /export/foo with krb5i
(since my foo really
Octave Orgeron wrote:
Hi Robert,
Excellent point! I think this is a good example of why the same
physical path can't be shared from a zone and the global zone at the
same time. Perhaps excluding any zonepaths from being shared at the
global zone is desirable if the nfs switch for that zone is
Edward Pilatowicz wrote:
On Thu, Feb 15, 2007 at 12:28:40AM +, Darren J Moffat wrote:
Nicolas Williams wrote:
On Wed, Feb 14, 2007 at 03:27:30PM -0600, Robert Gordon wrote:
There maybe a conflicting security requirement here. Lets say
I'm SA of the zone and i have exported /export/foo
[EMAIL PROTECTED] wrote:
I tend to agree, and the basic server consolidation target just makes
sense. I want to pretend a zone is the box I used to have and not have
to bump my nose on a funny behaviour or exceptions.
However, there are some wrinkles:
2) Due to the above, it seems like the
On Feb 14, 2007, at 3:17 PM, Edward Pilatowicz wrote:
i would refine your second point though because it doesn't take into
account lofs mounts.
ex, if i have /export/foo in the global zone and then in zonecfg i
configure a filesystem resource such that this directory is also
lofs mounted in
Octave Orgeron wrote:
--- [EMAIL PROTECTED] wrote:
2) Since NFS is mostly an in-kernel service, unlike something like
Apache, if you have some kind of issue with NFS stability, you lose
the whole box, not just the zone. This lack of fault isolation isn't
always something that people are
Robert Thurlow wrote:
Glenn Faden wrote:
4) A bug currently prevents a client instance and a server instance
from being safe to use on the same box (apologies, can't quote the
bugid from here). How likely, in your use case, is it that this will
be a problem, i.e. will your boxes be in the
35 matches
Mail list logo
