Octave,
Again, if a SA is using /etc/nodename to determine the hostname via a script
then they are using an inherently broken method to determine it. The reason
being is that /etc/nodename only covers a standalone system or an IP address
that is configured locally. /etc/nodename does not cover network booted
(DHCP
or RARP/bootparams) systems.
Thanks,
John
On 06/24/10 09:33 AM, Octave Orgeron wrote:
Hi,
What would probably make sense is to maintain the config file method and have
SMF load it. However, I'd also propose the to SMF the ability to dump such
variables back to the standard configuration files. This could be a good
compromise and also give SA's the ability to backup and restore the
configuration of a server through SMF.
Octave
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Octave J. Orgeron
Solaris Virtualization Architect and Consultant
Web: http://unixconsole.blogspot.com
E-Mail: unixcons...@yahoo.com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
----- Original Message ----
From: John Fischer<john.fisc...@oracle.com>
To: psarc-...@sun.com
Cc: Dave Miner<dave.mi...@oracle.com>
Sent: Thu, June 24, 2010 10:18:07 AM
Subject: Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223
FastTrack timeout 06/25/2010]
Still looking for a +1 on the new proposal.
Thanks,
John
On 06/23/10 11:24 AM, John Fischer wrote:
Darren,
Right. This case could have the data in /etc files and migrate the information
into SMF.
There are several ways to deal with System Configuration:
1. simply use files
2. use files and migrate configuration into SMF from file
3. use SMF for configuration and have files as compatibility
4. use SMF only
5. other (there are always other ways of doing things)
During the design phase discussion we did not see that large of a hit by using
the
SMF only method especially since nodename is only used for standalone or the IP
address is configured locally. Thus in certain cases /etc/nodename is not a
guarantee
that the hostname is the same as what is in the file. Since this is the case
scripts
should really be using 'uname -n' to determine the hostname. When we couple the
hit that the customer is taking in the upgrade migration from Solaris 10 it was
decided
that now was the time to make this sort of change.
Thanks,
John
On 06/23/10 10:54 AM, Darren J Moffat wrote:
On 23/06/2010 17:25, John Fischer wrote:
I understand that this change will break some scripts that admins
or developers have. However, as someone has already pointed out
the decision to move this direction was made in the original greenline
case. We are simply executing on one aspect of that strategy.
You are but there are is also precedence in other cases where data has been
moved from a file in /etc to SMF. In some of those other cases the approach
was taken to load the data in the /etc file(s) into SMF.
Could this case possibly do that type of thing ?
On 06/22/10 02:29 PM, Peter Tribble wrote:
On Sat, Jun 19, 2010 at 9:25 PM, James
Carlson<carls...@workingcode.com> wrote:
On 6/19/10 6:52 AM, Volker A. Brandt wrote:
3. Obsolete file /etc/nodename. This file will no longer exist in
the system
This will break 1000s of LOC of scripts. I am sure you have
considered the consequences your customers will be facing, and
have decided that your gain outweighs their loss...
Really? I can't say I've ever seen a script that reads /etc/nodename in
preference to using "uname -n" output, nor can I find any. Providing a
pointer to one would probably help focus the discussion.
I had several admin scripts that I wrote, nothing major. I would prefer
to use `uname -n`, but after about the third time that I found a system
thinking it was called --fqdn I started to mistrust uname -n, as it
can be
accidentally set to something other than the real name of the system
by incautious admins or applications, and looked at /etc/nodename as
a more reliable source of what the hostname was *supposed* to be.
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
