Re: [zones-discuss] Script run from global zone into local zones - to shut them down
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..
for z in `zoneadmn list -p | grep running | grep -v global | awk -F: '{print
$2}'`
do
zoneadm halt $z
done
Regards,
Sean.
.
Craig Cory stated:
Anne,
Something like this should work for you:
===
#!/bin/sh
for z in `zoneadm list`
do
if [ $z = global ]; then continue
fi
zlogin $z shutdown -y -g0 -i0
done
Regards,
Craig
In response to Anne Moore, who said:
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 this command:
zlogin $zonename1 shutdown -y -g0 -i0
Does anyone know how one would do something like this?
Thank you for all of your help!
Anne
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Craig Cory
Senior Instructor :: ExitCertified
: Sun Certified System Administrator
: Sun Certified Network Administrator
: Sun Certified Security Administrator
: Veritas Certified Instructor
8950 Cal Center Drive
Bldg 1, Suite 110
Sacramento, California 95826
[e] [EMAIL PROTECTED]
[p] 916.669.3970
[f] 916.669.3977
[w] WWW.EXITCERTIFIED.COM
+-+
OTTAWA | SACRAMENTO | MONTREAL | LAS VEGAS | QUEBEC CITY | CALGARY
SAN FRANCISCO | VANCOUVER | REGINA | WINNIPEG | TORONTO
___
zones-discuss mailing list
zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Setting up SMC on a zone - possible?
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 configuration. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Setting up SMC on a zone - possible?
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 pretty sure that you could _not_ install the package. The SUNW_PKG_ALLZONES and SUNW_PKG_HOLLOW markings on it will, I believe, cause it to be rejected on local zones. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] new option - cpu-dedicated
Mike Gerdts wrote: Does updatemanager use patchadd -M under the covers? No. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Patches via Live Upgrade with 2 zones on Solaris 10 Update 4 failed
[ 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 lumount d2 ./pca -R /.alt.d2 --install luumount d2 lurename -e d2 -n sol10p-20080229 luactivate sol10p-20080229 init 6 live-upgrade patching should be done with luupgrade -p, not with pca. luupgrade -p does essentially that same set of operations. lumount+pca+luumount should be OK. (Of course, we'd really rather that you use smpatch update -b instead of pca, but that's a different question.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Patches via Live Upgrade with 2 zones on Solaris 10 Update 4 failed
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 lumount + patchadd -R + luumount *is* supported, and that's basically what the PCA sequence does. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Boot state completion?
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 up. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
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 communication here? Some kind of zone-awareness needs to be integrated into HAL and/or dbus to deliver notification events (like hot plugging) to appropriate consumers. I don't have a proposal at this point. Hmm. I didn't read enough of the D-Bus materials to see the kernel interaction; I only read the part about inter-process communications. Still, it seems like the two should be mostly separable, that the IPC aspects should be straightforward to support in local zones. Kernel communications might not be available without zone support, but presumably there is a significant class of applications that would still be interesting - notably probably including the text editor that was the start of the conversation. (Disclaimer: I'm speaking entirely from a 100K-foot view, with almost no knowledge of how D-bus is implemented or used.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
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
Re: [zones-discuss] dbus in local zones
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 because the devices that get reported to HAL by the dbus-daemon don't exist in the non-global zones. HAL isn't zone-aware. 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 communication here? ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] sharing terminal server ports to non-global zone
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 sounds like they have a bunch of serial-attach devices that they multiplex onto the network using a terminal concentrator and demultiplex in software at the computer, and they want to make some or all of those serial connections available to applications running in local zones. Christine Tran wrote: Jerry Jelinek wrote: Christine Tran wrote: A customer is unable to share something called the terminal server ports to non-global zone. I don't know what these are, but here's the description: Serial sensor interfaces are fed to a patch panel and then received by a digital terminal server. Terminal server sends output to a switch, to which the host is connected. Terminal server port driver installs in global zone, creates /dev/dty/tt1, /dev/tty/tt2 ... He tried adding the device by set match = /dev/dty/* but the device does not appear in the non-global zone. Any thoughts? Is it /dev/dty or /dev/tty? The example shows both. What version are they running? There is a known bug with wildcard matching in u4: 6632938 zonecfg fnmatch device matching interface seems to be broken Sorry, that's /dev/dty/* not /dev/tty/*, my typo. And thanks for the bug, this may be it. CT ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
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 documentation gets old... Sure seems like a bug. Did you use, in zonecfg: zonecfg:int-sagent-1-z1:net set address=172.20.46.188/24 ? No, no /24. (I see how that could affect the picture, but it seems like /etc/netmasks should work too, and the message certainly suggests it.) Actually, I just remembered that I didn't specify the address this way. I used set address=int-sagent-1-z1. (I don't like using IP addresses when I don't absolutely have to.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
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.46.188/24 ? No, no /24. (I see how that could affect the picture, but it seems like /etc/netmasks should work too, and the message certainly suggests it.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
[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 to set the netmask for the entire Class B, but no dice.) Actually, that's exactly what you should be using in your local /etc/netmasks entry. I'm not sure, but reading netmasks(4) I don't think so. Note that it has an example entry: 128.32.27.16 255.255.255.240 and says that the system uses the longest prefix found. OTOH, I don't immediately understand how the example can work. It says that 128.32.*.* (except for the exclusions) gets a 24-bit netmask, but I don't see how that can be unambiguously determined. The example *seems* to want to explicitly specify a 28-bit netmask for several ranges and a 24-bit netmask for the rest, but how can it distinguish between requesting that 128.32.*.* is all 24-bit and requesting that 128.32.0.* is all 24-bit? (For that matter, why isn't it specifying that 128.001?.*.* is 24-bit?) Although I do suggest that specifying the prefix length (such as /24) via zonecfg(1M) is the best solution. Point-specifying a global value seems like the wrong answer. Normalization says that you should specify the global value in one place, not replicated across many. (Less abstractly, that you should specify the netmask in one place, not individually for each address that uses it.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] netmask warning, misconfiguration
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 it wanted me to set the netmask for the entire Class B, but no dice.) I see many instances of this message in BugTraq and Google searches, but I don't immediately see any resolutions. ___ zones-discuss mailing list zones-discuss@opensolaris.org
