://opensolaris.org/os/project/kerberos/
Sent using mutt, a sweet, text based e-mail app http://www.mutt.org/
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Glenn Faden | Senior Principal Software Engineer
Phone: +1 408 276-6884 | Mobile: +1 415 637
Glenn
Faden |
Senior Principal Software Engineer
Phone:
+1 650 786 4003 | Mobile: +1 415 637 8181
Oracle
Solaris Security, Solaris Core OS Technology Engineering
. Is it possible to shut down internet connection
to the global zone, or not? And if it is possible, how do I do it? Just by ifconfig
e1000g0 down or something similar?
Yes. That is sufficient.
--Glenn
ORACLE ®
Glenn Faden | Senior Principal Software Engineer
Phone: +1 650 786 4003 | Mobile: +1
in a zone. If you are using
VirtualBox, you can use the same networking tricks to get isolation as
you would use for a zone.
___
zones-discuss mailing list
zones-discuss@opensolaris.org
--
ORACLE ®
Glenn Faden | Senior Principal Software Engineer
the global zone will be attacked...
___
zones-discuss mailing list
zones-discuss@opensolaris.org
--
ORACLE ®
Glenn Faden | Senior Principal Software Engineer
Phone: +1 650 786 4003 | Mobile: +1 415 637 8181
Oracle Solaris Security, Solaris Core OS
list
zones-discuss@opensolaris.org
--
Glenn Faden | Senior Principal Software Engineer
Phone: +1 650 786 4003 | Mobile: +1 415 637 8181
Oracle Solaris Security, Solaris Core OS Technology Engineering
___
zones-discuss mailing list
zones-discuss
Mike Gerdts wrote:
On Tue, Feb 16, 2010 at 9:08 AM, Christine Tran
christine.t...@gmail.com wrote:
Does the data really need to be under the zonepath? If you were to do
something like:
zfs create -o mountpoint=/stuff rpool/stuff
mkdir /stuff/z1 /stuff/z2
zonecfg -z z1
add fs
set
Mike Gerdts wrote:
A non-global zone cannot be an NFS server (without a third-party
userland NFS server implementation). Also, NFS mounting a file system
in a non-global zone that is exported from that zone's global zone is
not supported. It may seem to work, but there is a known deadlock
maco wrote:
Glenn,
Thanks for the quick reply. I installed OpenSolaris 2008.11, but have kept it
up to date with the package manager.
The only mounted ROOT filsystem is the main one mounted on /.
I've since tried to make the zone ready with:
r...@gaia:/zones# zoneadm -z poseidon ready
Moore, Joe wrote:
William Roche wrote:
Now about the automounter, I share Nico's point of view, but as far as
I
know nothing like that already exist, and No, the automounter or a
mount
request isn't 'clever' enough (or customized enough) yet to handle NFS
data shared by the global zone and
Nicolas Dorfsman wrote:
Le 30 juin 09 à 16:13, Moore, Joe a écrit :
William Roche wrote:
Now about the automounter, I share Nico's point of view, but as far as
I
know nothing like that already exist, and No, the automounter or a
mount
request isn't 'clever' enough (or customized enough) yet
Roman V Shaposhnik wrote:
On Tue, 2009-06-30 at 17:00 -0500, Nicolas Williams wrote:
The problem at hand is a reentrance issue in the VM.
Could you, please, point me to the most authoritative CR that captures
this issue?
Hasn't it been mentioned in this thread already? I
Steve Lawrence wrote:
I think each zone's automounter is smart enough to use lofs instead of nfs for
mounts from a non-global to a global zone.
Please explain how this is possible. How can the automounter convert an
nfs specification of a global zone pathname into a pathname which can be
Nicolas Williams wrote:
On Mon, Jun 29, 2009 at 11:31:20AM -0700, Glenn Faden wrote:
Steve Lawrence wrote:
I think each zone's automounter is smart enough to use lofs instead of nfs
for
mounts from a non-global to a global zone.
Please explain how this is possible. How can
James Carlson wrote:
On Jun 29, 2009, at 2:31 PM, Glenn Faden glenn.fa...@sun.com wrote:
Steve Lawrence wrote:
I think each zone's automounter is smart enough to use lofs instead
of nfs for
mounts from a non-global to a global zone.
Please explain how this is possible. How can
Edward Pilatowicz wrote:
the inherit-pkg-dir property is only applicable to solaris distros
which use SVR4 packaging. (this means solaris 10 and SXCE). it is not
applicable to opensolaris system. using it on opensolaris based systems
will result in undefined behaviors and unsupporable
I would like to nominate myself as a Core Contributor, having
implemented several zones features (labeled zones, defrouter, cross-zone
FIFOs, etc.). FYI, Trusted Extensions is also using branded zones at
this time and has an active case to for a new brand called labeled. I
am currently a Core
In S10u6 labeled zones must use TCP sockets to connect to the global
zone Xserver. The DISPLAY variable must be set to either
global-zone-hostname:0 or localhost:0. Some code in X11 will fallback to
using localhost:0 when :0 (specifying local transport, eg. UNIX domain
sockets) fails. S10u5
Christine,
From the package list I assume you are running Solaris 10, not OpenSolaris.
I suppose you can leave out the X11-related packages, but it isn't a
valid assumption that a headless system doesn't need these packages. X11
applications can be remotely displayed using X protocol, or via
fu qilai wrote:
Hi,Can I defrouter my non-global zone to match exclusive IP model for Solaris
10 10/08?
[Feature:The ability to set the default router through an optional defrouter
property in a shared-IP zone added. ]
(1)A machine connects to LAN1 via NIC1 and LAN2 via NIC2 . (VLAN)
Weiberle wrote:
On 10/06/08 21:38, Glenn Faden wrote:
Max,
The default route option is not specific to TX zones. However, it is
intended for environments where your zones aren't sharing the same
physical interfaces. This feature sets the default route for an
interface so I don't think
Max,
The default route option is not specific to TX zones. However, it is
intended for environments where your zones aren't sharing the same
physical interfaces. This feature sets the default route for an
interface so I don't think it will provide the functionality you are
looking for.
Jerry,
For Trusted Extensions in OpenSolaris, we plan to use a new labeled
brand for zones which will be derived from the new ipkg brand. So your
proposal also affects labeled branded zones. I would like to explore
the plan to delegate these datasets to the zone. Since the zone's root
dataset
Your proposed suggestion made sense to me, but it was deferred while we worked
on exclusive IP stacks for zones, and other enhancements. However, it seems
that this problem still requires a solution, so I've submitted the following
project proposal to PSARC:
2008/057 Default Route For Zones
When deploying zones in Trusted Extensions some customers want to boot many
zones (hundreds) into the ready state. Since each zone has a unique label and
zfs dataset their filesystems be used by label-aware services in the global
zone such as NFS and sendmail, even when no processes (except
I thought I answered that. The dbus-daemon is using a UNIX domain
rendezvous file in /tmp in the global zone. The non-global zones have
their own instances of /tmp, so the rendezvous file does not exist in
their namespace. Even if it did, there would be other problems because
the devices that
Can you clarify whether you are seeing this problem with TJDS and/or
TCDE? Also, please move this discussion to security-discuss. That is
where Trusted Extensions discussions should take place.
--Glenn
Danny Hayes wrote:
We are running Solaris 10 U4 w/ Trusted Extensions on x86. When we open
I took another look at this configuration, and have yet another suggestion.
Instead of specifying the zfs dataset using zonecfg's datatset keyword, where
it is mounted by the zone, you can just specify that it should be mounted by
zoneadm, instead.
I previously suggested doing this:
There are some interesting ordering issues with respect to the steps
required for this configuration:
1. The dataset's mount point must be within the zone's root path for it
to be mounted read-write within that zone (you can't use lofs).
2. The dataset should not be mounted (by the global
I posted an earlier reply to zones-discuss, but I didn't copy all of the forums
in the original posting. I'm doing so now. I am also correcting some errors in
my earlier reply:
Yes, it is possible to share a zfs dataset that has been added to a labeled
zone.
Set the mountpoint property of
Please try the following:
Set the mountpoint property of your dataset zone/data to be within the
restricted zone's root. For example:
# zfs set mountpoint=/zone/needtoknow/root/zone/data zone/data
That will cause the dataset to appear automatically as a read-write
mount point in the
It is not practical for each zone to have its own X server. The X server
runs in the global zone, and can be accessed from non-global zones. You
can also run Xnest in a non-global zone, but the actual
keyboard/mouse/display are still under the control of the global zone.
When Trusted
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
[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
Names pipes may be used between zones when Trusted Extensions is enabled. The
policy for data flow between zones is generally more restrictive when TX is
enabled, but in this case it is slightly more open. The specific policy
difference is implemented in the function tsol_fifo_access().
Dan Price wrote:
On Tue 12 Dec 2006 at 10:47AM, Glenn Faden wrote:
Names pipes may be used between zones when Trusted Extensions is
enabled. The policy for data flow between zones is generally more
restrictive when TX is enabled, but in this case it is slightly more
open. The specific policy
Steffen Weiberle wrote:
Is it safe to generalize that non-LOFS file systems in Solaris 10 do
not allow cross-zone interaction? procfs does not. namefs does not.
tmpfs does not. sockfs does not. doors does not. What about all the
others (I can't even name them all)?
Doors can be used in
Paul Kraus wrote:
On 7/31/06, Steffen Weiberle [EMAIL PROTECTED] wrote:
Home directories are more problematic; you will need to loopback mount
them into the local zones.
Is the underlying problem being worked on, or is it worth an RFE to
make this transparent (automount
if remote,
[EMAIL PROTECTED] wrote:
There is no way for the non-global zone automounter to convert these
automounts from NFS to LOFS. Firstly, there is no API for the non-global
zone to determine that the NFS server is, in fact, the global zone
sharing the same kernel.
It can easily tell this
39 matches
Mail list logo
