Re: [zones-discuss] [caiman-discuss] Code review for zones support in SNAP
Evan Layton wrote: Hello All, We're down to the wire on the zone support changes to SNAP upgrade and are looking for code review comments. We'll be taking comments up until COB Tuesday October 7th. Your comments are as always welcome and appreciated. Defect 3686 is the blocker bug that was submitted to cover this work and the webrev is available at: http://cr.opensolaris.org/~equach/webrev.snap_zones/ Thank you in advance for your comments and help! -evan ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss Evan, I will review this today, Monday October 6. Joe ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Programming for zones
On Sat, Oct 04, 2008 at 01:14:59PM +0100, Nick Kew wrote:
Note also that (with no disrespect meant to Nick) a common newbie
behavior is to latch onto some random interface and attempt to bend it
to solve the problem at hand, whether or not it's the intended way to
solve that problem.
That may indeed be the case. Though I should add, my newbiedom
applies to Solaris kernel goodies, not to Apache or web-serving
(guess it's time to attach my apache book .sig:-) I'm exploring
(or, if you prefer, latching on to) the possibility of a strong solution
to a long-standing problem.
[Responding out of order...]
Let's start with a definition of the problem, then we can gather
requirements and design a solution.
Remember that user is a relative term. The user of a hosting
company is the hosting customer, *not* the guy behind the web browser.
Exactly. The zone_enter will happen at server startup. To have it
happen per-request in the server would imply an enormous overhead,
because it's a complete misfit to the Apache architecture. CGI could
perhaps do it in a similar manner to the existing setuid wrapper, but
that's a lesser solution to a less-interesting problem.
OK, so this is about website virtualization.
A couple things:
1) Today the only reliable way to do website virtualization is to give
each site its own IP address(es).
That's because both, TLS and HTTP originally did not have a way for
the client to tell the server what name the client used for it.
Both TLS and HTTP have that now, but you can't necessarily count on
all clients having that support, particularly for TLS.
2) Assuming that you can demand clients that speak HTTP/1.1 and TLS
1.1+, then you could avoid (1) and still use zones for isolation.
It sounds to me like that's what you're trying to do, that this is
your problem definition: Web server virtualization without requiring
per-site IP addressing.
Assuming that I guessed your problem definition more or less correctly,
and assuming you can get away with the TLS/HTTP client requirement
(particularly the TLS requirement) then this would be very, very cool.
It'd be a feature that no other {OS, web server} pair has, and it might
help us gain more traction in the web hosting business.
This feature will be somewhat tricky.
Ideally you'd not go anywhere near zone_enter().
Instead you'd have the primary web server zone use IPC to get per-site
zones to execute a request and return the response to the primary web
server zone, which would then send it back to the client.
What's tricky here is getting the web server code to support this IPC
scheme:
- The GZ needs to arrange for the IPC end-points (doors, probably) to
be available in the primary web server zone to talk to the per-site
zones;
- The web server needs to learn how to use that IPC, including passing
all relevant information to the per-site servers;
- The zoned web server code needs to know how to fake the environment
to the server application (CGI, ...);
- It's possible that some apps might need changes to run in this zoning
scheme.
Nico
--
___
zones-discuss mailing list
zones-discuss@opensolaris.org
[zones-discuss] backup/restore within a non-global zone of lofs data
Hi, http://docs.sun.com/app/docs/doc/817-1592/gbbxq?a=view has a caution regarding restoring a lofs mounted filesystem within a non-global zone. The prior paragraph makes reference to system read-only mount points. With the exception of possible access from other zones (the global, or shared access non-global zones), I don't see a reason why a non-system lofs directory could not be backed up and restored from within a non-global zone. Am I missing something? For example, if I create /myzone/private in the global zone and lofs mount it into the non-global zone as /private, I think I should be able to manage its content via things other than ufsdump and ufsrestore from within the non-global zone. Is the caution just for /usr, /lib, /sbin, or is there something else I don't know about? Thanks Steffen (reply-to set to alias) ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Shared-ip zones with defrouter
Hi, We have a need to define a separate defaultroute for some of the shared-ip zones in our environment. All of the zones are on the same subnet, but only some need to have a different default route. I was reading psarc/2008/057 but I am confused if the functionality applies to zones on same subnet? Also I saw that this functionality was backported to Solaris 10 zoneadm patch, but it mentiones TX zones. Does this only apply to TX or regular zones as well? -- Sent from my mobile device ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Shared-ip zones with defrouter
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. --Glenn Max Levine wrote: Hi, We have a need to define a separate defaultroute for some of the shared-ip zones in our environment. All of the zones are on the same subnet, but only some need to have a different default route. I was reading psarc/2008/057 but I am confused if the functionality applies to zones on same subnet? Also I saw that this functionality was backported to Solaris 10 zoneadm patch, but it mentiones TX zones. Does this only apply to TX or regular zones as well? ___ zones-discuss mailing list zones-discuss@opensolaris.org
