Darren Reed wrote:
> Hmmm, I think I prefer the bottom one, but I can't see why
> either precludes the other as I'm pretty confident no sane
> person will ever want a zone name that matches a uuid and
> code could easily be written to cover this.
Are zones required to have names?
If so, one case
Before diving too far down this rathole... aren't the package scripts
run in the context of the zone?
James Carlson wrote:
> Ralf Weber writes:
>> or your zone path when the package gets created inside a zone. So I
>> would rewrite your scripts as:
> [...]
>> ${BASEDIR}/usr/sbin/chroot ${BAS
James Carlson wrote:
> Jordan Brown writes:
>> Before diving too far down this rathole... aren't the package scripts
>> run in the context of the zone?
>
> Yes, for the specific issue of running a script in a zone, but in
> general, you can't chroot to $BASE
Liane Praza wrote:
> It leaves a bad taste
> in my mouth, but then again so does the fact that we've got two
> different patching systems which require the system to be in different
> states when they run.
Three :-)
Well, sort of.
All of them agree that the system should be "in single user mo
Bob Netherton wrote:
> And further
> refinement would only impact patching rather than the booting process
> as a whole.
Hmm. I don't know how to have a service that runs when a particular
milestone is selected, that *doesn't* run when "all" is selected.
(Other than by dynamically enabling and
Steve Lawrence wrote:
> So you want to be able to interrupt any boot to any milestone, and instead do
> the patch processing if a patch is pending. You basically want to interrupt
> the current milestone, and instead just boot to filesystem-local and do the
> patching.
That would be my initial pl
Steve Lawrence wrote:
> I can't see any straightforward way to interrupt boot without changing the
> milestone. You could make lots of services dependent on a patching
> service, but that will have a maintenance burden. It also may not play well
> with 3rd party services.
Yep.
Hmm. I just real
Nils Goroll wrote:
> I suggest to introduce an additional milestone (e.g. milestone/ready)
> with optional dependencies on all "system" services, roughly matching
> the time when rc3 is run.
That's much later than is desirable for these patches. The goal is to
have the system as quiet as possi
[ Which brain-dead mail client turns all of the spaces in the Subject
into tabs? ]
Zones folks: the current proposed answers to this problem involve
moving system/filesystem/local into milestone/single-user. That was
apparently considered and rejected as the answer for the patchadd
problem t
Steve Lawrence wrote:
> I assume you are targeting this change for s10.
Yes.
> The single-user milestone is intended to mimic the traditional unix
> run-level 1 (S?)
Nit: Run level 1 is slightly different from S.
> This is typically where an admin would run stuff like
> fsck (on filesystems th
Steve Lawrence wrote:
> A. Make patchadd verify that the system is in single user milestone when
> installing a single-user patch.
That's a non-starter. *Many* of our customers ignore our recommendation
to install patches in single-user mode, and will revolt if we attempt to
enforce it.
I
Steve Lawrence wrote:
> Call this requirement (no login prompt) out in your use case. I assume
> the patch service will patch, set the boot milestone, and reboot before
> the patch milestone is actually met, avoiding the maint prompt.
Yes.
> Definately get some console messages out of the patch-
bart(1M) says about its -R option:
Note - The root file system of any non-global zones
must not be referenced with the -R option. Doing
so might damage the global zone's file system,
might compromise the security of the gl
Jerry Jelinek wrote:
> Jordan Brown wrote:
>> bart(1M) says about its -R option:
>>
>> Note - The root file system of any non-global zones
>> must not be referenced with the -R option. Doing
>> so might damag
We had a meeting this morning to further discuss this issue, but
unfortunately a number of key people were not able to make it. SMF and
Zones people: Please take a look at the following and see if you can
shoot any holes in it.
---
There is an important assumption that today's automated patc
Jordan Brown wrote:
> Proposal 2:
> - Make the new patching service depend on system/filesystem/local.
> - Modify patchadd to temporarily enable system/filesystem/local before
> patching, and disable it afterward, *if* it is offline. Note that when
> the patching service runs, sy
Narendra Kumar S.S wrote:
> Is there any particular reason, why you are not proposing to move
> filesystem/local to single-user milestone.
That was option #1 in my list. However, there were those who objected
to changing the definition of single-user mode in this way. In
addition, there
You and Dan both talked about user authentication and therefore the need
for the zone_enter to happen "late", but I don't think that's part of
the picture here at all.
Nick is trying to isolate virtual systems, not users. I've seen this
problem on my personal hosting providers - my CGI scripts
Nicolas Williams wrote:
> On Fri, Oct 03, 2008 at 02:37:28PM -0700, Jordan Brown wrote:
>> Nick is trying to isolate virtual systems, not users. I've seen this
>
> That was, obviously, not the impression tat I got. It's trivial to
> separate virtual systems by just
Nick Kew wrote:
>> (Note, incidentally, that the picture might be different for a Java
>> server, where the Java byte code for the application and a bunch of
>> overhead objects might well fall into that sharable bucket.)
>
> Would that apply to similar bytecode like Python, which is commonly
>
Mike Gerdts wrote:
> When really important features are released as new
> packages "genesis patches" are delivered to deliver the feature.
Sometimes, but not always. In fact, I'd have to say "usually not". The
Genesis technique is not without its problems, and is considered
controversial.
I get:
zoneadm: zone 'int-sagent-1-z1': WARNING: bge0:1: no matching subnet
found in netmasks(4) for 172.20.46.188; using default of 255.255.0.0.
but my /etc/netmasks (on both the global and local zone) looks good:
172.20.46.0255.255.255.0
(I also tried 172.20.0.0 on the theory that maybe
Antonello Cruz wrote:
> I would definitely run
>
> zonecfg -z int-sagent-1-z1 info
>
> to check what the zone thinks is the netmask.
Doesn't display a netmask.
> I suspect if you haven't defined the '/24' it will pick the default for
> the address class. In this case, '/16' IIRC.
> Sometimes d
Antonello Cruz wrote:
>> zoneadm: zone 'int-sagent-1-z1': WARNING: bge0:1: no matching subnet
>> found in netmasks(4) for 172.20.46.188; using default of 255.255.0.0.
> How did you setup the IP address for that zone?
>
> Did you use, in zonecfg:
> zonecfg:int-sagent-1-z1:net> set address=172.20.4
[EMAIL PROTECTED] wrote:
> What does the "netmasks" entry in /etc/nsswitch.conf say? A common
> issue is that a user changes their local /etc/netmasks file but their
> the switch says to use something like "nis".
Bingo! Thanks!
>> (I also tried 172.20.0.0 on the theory that maybe it wanted me t
Paul Davis wrote:
>
> Sounds like they want to access the local zone's console directly from a
> terminal server? I don't believe there is a concept of that in the zones
> model (of course, the local zone's console is normally started with
> "zlogin -C zonename" from the global zone).
Sure sou
>> dbus-daemon cannot be run in non-global zones
Sure sounds like the question is "why not?".
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Glenn Faden wrote:
> 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
Glenn Faden wrote:
>> I understood that. What I didn't understand was why there wasn't a
>> completely separate instance of the dbus-daemon running in each zone,
>> with its own rendezvous file for communicating with clients in that
>> zone. Why would you expect there to be cross-zone communic
Christine Tran wrote:
> who -r still works in a zone.
>
> [EMAIL PROTECTED]> zonename
> zone1
> [EMAIL PROTECTED]> who -r
> . run-level 3 Jan 24 14:53 3 0 S
Yes, but apropos of our earlier discussion around
milestone/multi-user-server, run level 3 doesn't mean "all services
[ Sorry if this is a repeat. I tried to abort it during the original
send and haven't gotten my own copy, so I think something went a bit
weird. ]
Renaud Manus wrote:
> Eric Ham wrote:
>> I then ran the following Live Upgrade and PCA commands with no errors.
>>
>> lumake -s sol10-2007-08 -n d2
Renaud Manus wrote:
> Jordan Brown wrote:
>> luupgrade -p does essentially that same set of operations.
>> lumount+pca+luumount should be OK.
>
> But we (Sun) don't support it.
True (which is why I said we'd prefer you used smpatch), but I believe
that lumou
Mike Gerdts wrote:
> Does updatemanager use patchadd -M under the covers?
No.
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Anne Moore wrote:
> Thanks for the reply. I am talking about the Solaris Management Console. I
> have a whole-root zone and those two services are running. However, there is
> no /usr/sbin/smc in my whole-root zone. It's like the whole-root
> installation didn't even install it. Very odd.
SUNWmcc
Jordan Brown (Sun) wrote:
> You could perhaps install all of the contents of that package (plus any
> other packages that are required and similarly situated), and that might
> well work.
... but it would of course not be a supported conf
Anne Moore wrote:
> Okay, that's good information. I can then install it manually and things
> should work. I'll try in the morning.
You could perhaps install all of the contents of that package (plus any
other packages that are required and similarly situated), and that might
well work.
I'm pr
Anne Moore wrote:
> All
>
> I'm trying to write a script that will shutdown all zones from the local
> zone. I'm not terribly good with scripting (yet), but thought many of
> you would be.
>
> I need to run the command "zoneadm list" and then output each line to a
> different variable to run
Depends on whether you want to take the zone down *now* or want the
gradual shutdown behavior of shutdown. Granted, -g0 is pretty abrupt.
Sean McGrath - Sun Microsystems Ireland wrote:
>
> surely use zoneadm halt instead of zlogin ?
>along with zoneadm list -p and grep for running zones..
38 matches
Mail list logo