Hello,
I would like to know if there is a command someone can run in a non
global zone to determine the globale zone and the name of the command of
course?

        Thomas

Hi,

Thomas Glanzmann wrote:
> Hello,
> I would like to know if there is a command someone can run in a non
> global zone to determine the globale zone and the name of the command of
> course?
What do you want to do?
The global zone has always the name "global".
The command zonename(1) tells you the name of the zone you are on.

HTH
Ewald

Hello Ewald,
I have 6 v490 running the veritas cluster suite and veritas filesystems.
We have a lot of zones on this machines running. But one zone is only
running on one machine at a time. What I want is to tell as user of one
_non global_ zone on which of our 6 v490 the zone is running.

        Thomas

Thomas Glanzmann <sithglan@stud.uni-erlangen.de> wrote:

> What I want is to tell as user of one
> _non global_ zone on which of our 6 v490 the zone is running.

How about creating a file which contains the output of "hostname" run
on the global zone and then make that file available to every non-global
zone? Like /master, and then the user could simply do a cat /master?

Alexander Skwar

Hello,

> How about creating a file which contains the output of "hostname" run
> on the global zone and then make that file available to every
> non-global zone? Like /master, and then the user could simply do a cat
> /master?

I know how to work around it. What I want is a way to tell from the non
global zone to tell on what host I am running on.

        Thomas

Hello,
but the idea isn't that stupid but there must be a better documented
way. Hopefully.

        Thomas

Thomas Glanzmann <sithglan@stud.uni-erlangen.de> wrote:

> Hello,
> 
>> How about creating a file which contains the output of "hostname" run
>> on the global zone and then make that file available to every
>> non-global zone? Like /master, and then the user could simply do a cat
>> /master?
> 
> I know how to work around it. What I want is a way to tell from the non
> global zone to tell on what host I am running on.

Yes. That file "/master" should be accessible by the non-global
zones, of course.

Alexander Skwar

Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
>
>but the idea isn't that stupid but there must be a better documented
>way. Hopefully.
>

It appears that Sun has not provided a way for processes in a
non-global zone to learn the hostname of the global zone.  Not
even a command that the root user would invoke from a shell
command line.

There was a previous discussion of this in this newsgroup,
and one Sun person responded "We never thought it would be
necessary for a non-global zone to know the global zone's
hostname."  This is true, in theory.

However, in practice it's a very important piece of information
that should be available to the non-global zone.  How does a
sysadmin find out which global zone (i.e. physical server)
controls the cpu and memory resources for a particular zone,
in a network with a dozen servers and a hundred zones?  Or more?

Or how does a new sysadmin pick up the pieces at a site whose
old sysadmin unexpectedly quit without documenting the server
configurations?  Everyone else at the site can tell the sysadmin
the hostname/ip of the mail server, the file server, and the DNS
server(s), but when those are non-global zones, how can the
sysadmin find out the hostname/ip of the global zones that
control them?

Sun apparently thinks the sysadmin should keep good records
of global zones on paper or a database external to the servers.
This is not a bad idea, but there needs to be a way to learn
this information from the non-global zones themselves.

Now that zones can be easily migrated from one server to another,
we have the new possibility that the sysadmin's external records
are incorrect.  Zone migration from one server to another can be
automated as part of a home-built high availability scheme, and
the zone is no longer on the original server.  Or even that zones
were migrated from a failed server to a working server late at
night to fix an outage, and the external records weren't updated.

Until Sun sees these things and provides a way for a non-global
zone to learn the hostname of its controlling global zone, we
sysadmins will have to create workarounds.

The most often suggested workaround is to create a file in a
filesystem that the global zone shares with all non-global
zones, and put the global zone's hostname or IP address in
that file.

Of course, this won't work for non-global zones that don't
share any filesystems with the global zone.  That's why the
zone itself should be able to tell us, Sun.

  -Greg
-- 
Do NOT reply via e-mail.
Reply in the newsgroup.

quoting Thomas Glanzmann (18 Sep 2007 14:10:32 GMT):
> but the idea isn't that stupid but there must be a better documented
> way. Hopefully.

Alexander's idea provides the information you want. So, why should there
be a 'better' way? The info won't change ;-)
A.f.a.i.k. you can't run a command from within a non-global zone that
provides data from the global zone. That would be a security risk.

-- 
Dick Hoogendijk -- PGP/GnuPG key: 01D2433D
++ http://nagual.nl/ | Solaris 10 / XDE ++

· Greg Andrews <gerg@panix.com>:

> However, in practice it's a very important piece of information
> that should be available to the non-global zone.  How does a
> sysadmin find out which global zone (i.e. physical server)
> controls the cpu and memory resources for a particular zone,
> in a network with a dozen servers and a hundred zones?  Or more?

Why should he? In theory, that piece of information is of
no matter at all to the sysadmin of a non-global zone. It's
just none of his business. He's there to admin the non-global
zone. Name of the global zone is nothing he should worry
about.

Now, how does a sysadmin of a global zone find out? "Simple":
He's having a look in the documentation. That's where the
relationship "non-global zone" -> "global zone" is to be 
found, IMO.

> This is not a bad idea, but there needs to be a way to learn
> this information from the non-global zones themselves.

Why? What for?

> Of course, this won't work for non-global zones that don't
> share any filesystems with the global zone.  That's why the
> zone itself should be able to tell us, Sun.

I disagree.

Anyway - wouldn't it work to figure out the MAC adress of the
NIC and then do a ARP lookup to get the IP and then do a nslookup
to get the name for the IP? Or do "virtual" interfaces have
distinct MAC adresses?

Alexander Skwar
-- 
QOTD:
        How can I miss you if you won't go away?

Besides all the other valid points raised on this, what do you
mean by the hostname of a system? This really isn't well defined
in the first place.

Also, there's no reason for a local and global zone to be using
the same naming schemes, so the name by which each knows itself
(however you defined hostname above) does not necessarily have
the same (or any) meaning to the other one, and might actually
be completely misleading.

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

Greg Andrews wrote:
> Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
> 
>>but the idea isn't that stupid but there must be a better documented
>>way. Hopefully.
>>
> 
> 
> It appears that Sun has not provided a way for processes in a
> non-global zone to learn the hostname of the global zone.  Not
> even a command that the root user would invoke from a shell
> command line.
> 
> There was a previous discussion of this in this newsgroup,
> and one Sun person responded "We never thought it would be
> necessary for a non-global zone to know the global zone's
> hostname."  This is true, in theory.
> 
> However, in practice it's a very important piece of information
> that should be available to the non-global zone.  How does a
> sysadmin find out which global zone (i.e. physical server)
> controls the cpu and memory resources for a particular zone,
> in a network with a dozen servers and a hundred zones?  Or more?
> 
> Or how does a new sysadmin pick up the pieces at a site whose
> old sysadmin unexpectedly quit without documenting the server
> configurations?  Everyone else at the site can tell the sysadmin
> the hostname/ip of the mail server, the file server, and the DNS
> server(s), but when those are non-global zones, how can the
> sysadmin find out the hostname/ip of the global zones that
> control them?
> 
> Sun apparently thinks the sysadmin should keep good records
> of global zones on paper or a database external to the servers.
> This is not a bad idea, but there needs to be a way to learn
> this information from the non-global zones themselves.
> 

It's not just Sun that thinks so.  A good Sysadmin documents his 
systems!  A Sysadmin who does not document is not good!  It's that 
simple.  Shit happens!  Someone else, who is far less knowledgeable, may 
have to take over for as much as a couple of months while the Sysadmin 
recovers from a heart attack.  Or maybe her husband found her in bed 
with someone else and shot them both!  Shit happens!

System documentation should include:
a. The hardware configuration including model and serial numbers.
b. The software configuration; listing the name and version of each 
product installed on that system.
c. The network configuration.
d. The storage configuration.
e. Shutdown and startup procedures.  In some shops the order in which 
systems are powered up and booted may be significant.  Likewise the 
order in which things are shut down may be significant.  Document it!
f. The contact information for hardware and software support.
g. The names and contact information for the stakeholders; e.g. the 
managers who depend on that system for some essential service.  This 
should indicate which managers rely on which applications.
h. The backup strategy; e.g. when and how do you back up, how do you 
restore those backups if necessary, etc.  It's not a bad idea to include 
a detailed description of how backups and restores are done, including 
the exact text of the commands to do a backup or a restore.  Man pages 
may not be available if the system is down!
i. A record of the software licenses including license keys if any.

There may well be other things that should be included but I think that 
the above is the minimum.  A good manager will insist that his Sysadmin 
write and maintain such documentation.  Unfortunately, GOOD managers are 
usually in very short supply so just do it anyway.  Once it's done, it 
must be maintained.  Review it from time to time and make the necessary 
changes.

[Andrew Gabriel]:
>
>   Besides all the other valid points raised on this, what do you
>   mean by the hostname of a system? This really isn't well defined
>   in the first place.

s/hostname/nodename/, then

>   Also, there's no reason for a local and global zone to be using
>   the same naming schemes, so the name by which each knows itself
>   (however you defined hostname above) does not necessarily have the
>   same (or any) meaning to the other one, and might actually be
>   completely misleading.

sure, but that's your problem to sort out if you don't use FQDN.
-- 
Kjetil T.

[Alexander Skwar]:
>
>   � Greg Andrews <gerg@panix.com>:
>   > This is not a bad idea, but there needs to be a way to learn
>   > this information from the non-global zones themselves.
>   
>   Why? What for?

I set up ident in a non-global zone.  the problem is that the zone has
no access to the TCP state tables needed to look up the user owning
the connection, so instead my patched identd contacts the global zone
and asks for the information.  this is hard to do without knowing at
least one the global zone's IPs.

>   > Of course, this won't work for non-global zones that don't
>   > share any filesystems with the global zone.  That's why the
>   > zone itself should be able to tell us, Sun.
>   
>   I disagree.

I however agree 100% with Greg Andrews.

>   Anyway - wouldn't it work to figure out the MAC adress of the NIC
>   and then do a ARP lookup to get the IP and then do a nslookup to
>   get the name for the IP? Or do "virtual" interfaces have distinct
>   MAC adresses?

that's certainly not going to work for my ident daemon, but in any
case it's very error prone.  for once -- the global zone might use
bge0 while the zone uses bge1 (in such a setup the admin will almost
certainly have to turn on unique MAC addresses per interface).
furthermore, you will only find a match if both the zone and the
global zone are in the ARP cache.  in other words, you will have to
ping all potential candidates before checking the ARP cache, and hope
the entry hasn't expired in the interim.

(I "solved" it by storing an extra CNAME for each zone, pointing at
its master.  others probably object to publishing this information to
the world :-)
-- 
Kjetil T.

On 18 Sep., 11:28, Thomas Glanzmann <sithg...@stud.uni-erlangen.de>
wrote:
> Hello,
> I would like to know if there is a command someone can run in a non
> global zone to determine the globale zone and the name of the command of
> course?
>
>         Thomas

Hi

No command, but look at /etc/net/tic*/hosts files
We found there the global Zone Host

cu