mmmmn

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://mmmmn.blogbus.com/logs/1878991.html

1、How To Display Serial Number?
> Can somebody tell me how I could remotely display the serial number of
> a Sun-Fire-280R running Solaris 5.8, from the command line?

The only way I'm aware of is to preload SUNWsneep, then run it once and
give it the serial number.

After that, you can run a command to read the serial you entered at
sneep installation time.

That requires advance planning. I do not know of any other way,
unfortunately.

That's the one thing I wish Sun did; IBM makes it very easy with their
AIX boxes by doing 'lsattr -E -l sys0 -a systemid'. Saves me if I have
inherited hardware 5000 km away and need to place a service call on it. :-)

-Dan
.
---------
 Our preferred method is to have the sysadmin who's building the box
the first time run "eeprom oem-banner=<hostid>" if it's not set
already (we use "oem-banner" to store it, since "oem-banner?" is set
to false by default).  That way, you only have to set it once, no matter
how many times you jump it, and it's always available off the command line
(you can run eeprom | grep oem-banner= even as a non-privileged user)
from there on out.
     An added benefit is that if your disk blows up and you need to call
support, and the system is say, across the pacific ocean, you'll have access
to it on console :)

-------
Not odd, because hostid does not depend on serial number at all.

The serial number is simply not recorded *anywhere*.

Hostid is randomly generated.

http://blogs.sun.com/roller/page/ambiguous/20050617#introducing_myself

....details how hostid is generated. Very interesting story, and involves
some historical attempts at obfuscation ("hiding its sources").

-Dan
.
---------
> Casper H.S. Dik <Casper.Dik@xxxxxxx> writes:
>> Dan Foster <usenet@xxxxxxxxxxx> writes:
>>
>>>Yeah, but something generates it in the first place. Is the initial
>>>generation really based on that particular hardware's serial number?
>>
>> AFAIK, they're serially generated, not related to the serial #.
>> The serial # includes a production week and year; the hostid
>> has only 24 significant bits so there's no even room for random.
>
> 24 bits?  I get what appear to be 32-bit values from the "hostid" and
> "fpversion" commands, and I see "80" and "83" in the first two hex
> digits on various Sun systems.

The first byte used to encode the architecture and model; but that changed
quite some time ago; if the high order bit is set, that no longer applies
and those characteristics are determined by other eeprom properties.  So
in principle, modern hostids could have up to 31 significant bits.  In
practice (on SPARC) the three low order bytes seem to be a copy of the
three lower-order bytes of the MAC address of the builtin network
interface, and the high order byte may be occasionally incremented or
otherwise altered as needed; the original architecture-free high order
byte was 0x80, but my Sun Blade 100 has 0x83.  I'm not sure what if any
deeper meaning there might be in different high order byte values with the
high order bit set.

# hostid;ifconfig eri0
8304ae0e
eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.1.6 netmask ffffff00 broadcast 192.168.1.255
        ether 0:3:ba:4:ae:e

So different rules for generating the hostid have applied over time on
SPARC, and on x86, it's not derived from anything in hardware/firmware
at all, but rather generated and patched in at install time.

ISTR that _some_ newer and larger SPARC systems do have the case serial
number software accessible, but I don't remember which nor how.  The
best idea I've seen is to manually store it in the eeprom oem-banner
variable at first system set-up; thereafter it would be available under
the OS with

eeprom oem-banner|sed -n -e 's/[^=]*=//p'

or at the OK prompt with printenv (if I remember correctly).  Various
people have arrived at that idea independently, so for SPARC systems,
it's probably the best generic solution.

If one has x86 systems too, one might prefer to store it in a file
instead (or as well, since that file might not be much use on a SPARC
that wasn't able to boot the OS).

-------
>> The hostid isn't tied into anything on SPARC systems.  Sun has to burn
>> the hostid into the NVRAM.
> NO, you simple write to a memory just like the clock and all other
> parameters in Openboot.
>
> Burning is the process of writing to a PROM, there are almost not PROM
> available today.

In most systems the hostid is stored in an EEPROM, which last I looked was
a type of PROM.

> I would(almost) put my life on that there is no serialnumber in the
> world of any device that you can be sure it REALLY unique due to a
> process of relabled in factory.

relabeled?  Serial numbers should _always_ be unique. If you ever find
two Sun systems with the same serial numbers I'll be very surprised.
Two systems with the same hostid's is a possibility, due to the fact
new NVRAM chips can be made with the old hostid for some (but not all)
systems.

That's not to say that any one system will always have the same serial
number - if a machine is "remanufactured" by Sun and resold then it will
get a new serial number (with the date part of the serial being the reman
date, and the rest of the serial showing that it's a Sun re-man box).

  Scott

---------
> Can somebody tell me how I could remotely display the serial number of
> a Sun-Fire-280R running Solaris 5.8, from the command line?

Sun's web site appears to be kinda broken -- I find references to
SUNWsneep but can't actually get to the pages that makes it available.

At machine install time, you can do:

# /opt/SUNWsneep/bin/sneep -s <serial number>

And then later on, you can check the chassis serial number (CSN) with:

# /opt/SUNWsneep/bin/showplatform -p csn

This data is stored in NVRAM on SPARC and in a NVRAM-like file on x86.

Of course, you still have to manually enter the serial number once, long
before you will need to know it later on.

Another way of doing it is stuffing the serial number in oem-banner as
others has pointed out. It's an equivalent method to sneep on SPARC, and
probably also works on x86 though it's likely to be stored in a file.

-Dan

2、 rice.cruft@xxxxxxxxx wrote:

> I have search the solaris newsgroups on the topic of shared library
> creation and the use of the -KPIC/-kpic flag to compile the objects
> comprising the library. I think I have a basic understanding of the
> main issues. The Sun docs state that -KPIC/pic *must* be used to when
> compiling objects for shared libraries. Yet I have noticed that shared
> libraries created without this flag load just fine at runtime.
>
> Please correct me if I am wrong...
>
> (1) shared libraries compiled without PIC objects are runtime linkable,
> but cannot be shared across processes

That's correct, although for 64 bit code you would have to compile with
-xcode=abs64 rather than the default -xcode=abs44.

> (2) point (1) is not really a problem if the shared library will not be
> used by a multitude of concurrent processes

Non-pic code may take longer to link at runtime, because it can have
more relocations.  For instance, if the code calls "write" ten times,
then the pic version will need only one relocation at runtime while the
non-pic version will need ten.

> (3) only libraries built from -KPIC objects can be really shared by
> concurrent processes

That is mostly true.  It is possible for some pages of a non-pic .so to
have no relocations in them, in which case those pages will be shared. 
I imagine that would be pretty rare, though.

> A related issue: can a shared library be composed of PIC objects and
> non-PIC objects (from static archives lib*.a) ? If so, how does this
> composition affect runtime linking?

Yes, one can mix and match.  If pic code and non-pic code wind up in the
same page, then that page will not be shared amongst processes.  Aside
from that, the only factor is that the more pic code there is the fewer
relocations will need to be done.

> Also how does a linker deal with objects from a static library that
> were built with the -KPIC flag? (Eg.  ld -o foo foo.o libwithpicobj.a )

Pic code just uses different instructions to call functions and to
access variables.  Sometimes those instructions require different
relocation entries.  The linker knows how to interpret each relocation
entry, so there is no problem mixing objects this way.

However, pic code can be slower than non-pic code.  Pic code adds an
extra jump to function calls (the call is to a table, which contains
jumps to the actual functions).  Pic code adds an extra load to access a
global variable (it loads the address from the Global Offset Table, then
loads the actual variable).  Usually this overhead is not significant
compared to everything else your program is spending time on, but of
course there are pathological cases.

Iain

-------
>I'm puzzled by this. Looking at the man page for cc it says the default
>for 64-bit compiles is abs44, But it also says (see below from the man
>page)

>"When building shared dynamic libraries, the default -xcode value of
>abs44 (not abs32) will not work with -xarch=v9, v9a, or v9b. Specify
>-xcode=pic13 or -xcode=pic32 instead."

Yep, if building a shared library, you'll need to use pic.

>So there it says use -xcode=pic13 or -xcode=pic3 for 64-bit compiles.
>I'm confused by this issue, and need to know soon, so if you can clarify
>it, I'd like to know. Although abs64 is mentioned as an argument for
>xcode, there is no information about when to use it.

-xcode=abs64 is needed when the code is too big for abs44
(code + statically allocated data > 2^44 bytes)

Casper

-------
> Casper H.S. Dik wrote:
>> Dave writes:
>>
>>
>>>So is this statement in the Sun Studio 11 man page for cc:
>>
>>
>>>"Shared objects built with -xarch=v9 -xcode=abs32 or -xarch=v9
>>>-xcode=abs44 will not work."
>>
>>
>>>wrong or am I just interpreting it incorrectly? That indicates to me
>>>that xarch=v9 -xcode=abs44 will not work under any circumstances, which
>>>seems a bit odd given it is the default on 64-bit systems.
>>
>>
>> Not, it says *shared objects*.  So programs will work fine with
>> -xcode=abs44 but shared libraries will not.
>
> Sorry, it was a shared library I wanted to create. So I assume
> -xcode=pic13 is what I need?
>
> Will -xcode=pic32 work if the GOT table is *under* 8k? If one is going
> to distribute a program for others to compile, one is unlikely to be in
> a position to know this.
>
> I've got no feeling for when -xcode=pic13 might need to be replaced by
> -xcode=pic32.

There's so much confusion here that I doubt I'll be able to address
all of them in a single post. I'll try to post a blog on this later
but let me give a quick shot at explaning what -xcode is and how it affects
your code. This is only for SPARC. Intel side has slightly different issues.

What -xcode determines is what code sequence the compiler will generate
to form the address of any symbol (a symbol could be a function or an

object).
So, for example, -xcode=abs44 tells the compiler that
only lower 44-bits of the address of any symbol the code accesses are

important
hence the compiler generates the code sequence that takes only lower 44-bit
and necessary relocations for them.
This address forming code sequence does not apply to function calls
because SPARC function calls are PC-relative AND because
calls to shared libraries go through PLT which can reach the entire 64-bit
address space. This issue only comes up when there's a global variable access
or when the pointer to a function is used.

-xcode=abs64, as its name implies, tells the compiler to assume
full 64bit is necessary to form any address.
Hence this flag is always safe.

So why does the compiler use -xcode=abs44 by default ?
It does so because it gives the better performace than -xcode=abs64
and works fine for most applications.
On the SPARC,
it takes 6 instructions to form 64-bit constant
whereas it takes 4 instructions to form 44-bit constant.
This different doesn't sound much but if your program size is large
and has many of address forming code, it could be non-trivial.

So when does -xcode=abs44 cause the runtime linker to fail ?
when the runtime linker resolves such 44-bit related relocations
and finds out that the actual address of the symbol needs more than 44-bit,
it fails to load the object and kills the program.
This can happen in following scenarios:
1. (More common than 2) All object files used in linking the executable
are compiled with at least -xcode=abs44,
and one of the shared libraries the executable links with
have been loaded into the high address range above 2^44
(regardless of how the shared library itself is built),
and the executable has an access to a global object within the shared library
or has formed a function pointer to any functions within the library.
This is the case the Studio documentation warns about.

2. (Very rare) Regardless of how the executable is compiled,
the executable loads at least two shared libraries
and one of them is compiled with -xcode=abs44
and the other is more than 2^44 away from the shared library
built with -xcode=abs44. In this case,
the runtime linker will fail to resolve relocations
used within the -xcode=abs44 built shared library.
This doesn't happen often, because most shared libraries are
built with -xcode=pic13/pic32.

In the different branch of this thread,
I've seen someone mentioning using an archive library to build
a shared library. Please remember that an archive library
is simply a collection of objects, hence, for most practical purposes,
an archive library should be treated as just bunch of objects.
>From that point of view, an archive library needs to be compiled
with whatever flag is necessary for its final use.

In another branch, there was a question about -xcode=pic13/pic32.
To determine which one (pic13 or pic32) to use,
one need to know the number of access to global symbols
in the final shared library that the object will be part of.
Since there's no easy way to know that,
usually one needs to do a trial-and-error approach:
try building a shared library with -xcode=pic13
and if the linking succeeds, then it's fine.

Now, that is a hassle (although it's usually a hassle
that has to be taken care of only once)
but the benefit of -xcode=pic13 is again the performance (what else?).
The reason is similar as abs44 vs abs64.
With -xcode=pic13, the compiler will generate
different (and shorter) code sequence to form the address
than -xcode=pic32.

Oh well, this isn't that quick nor short.
But I hope this addresses most questions.
Again, as a reminder, this is only for SPARC.
Intel has different -xcode values and different associated issues...

--------

4、i haven't run into this problem yet, but the thought
occurred to me.  maybe the question is moot:  maybe it
can only be done one way.  you tell me.

let's say i have a global and a local zone.
let's say the local zone is going to have mirrored disks.

do i mirror the disks in the global zone, and tell the local
zone about the completed mirror?

or,

do i just give the local zone the disks and let it do
the mirroring?

i'm also wondering what happens if there are differences
if, say, i want to grow the mirrored disk in the local zone.
if the global zone is calling the shots, then i'd have
to grow it in the global zone and then grow it in the local
zone again.  uh, presuming, of course, that that's how you'd
want to have the mirrors set up in the first place....
which may be wrong.

assume disksuite, or whatever it's called these days---the Sun
volume manager?

j.
I am not an expert on this - I onle have basic experience
concerning metadisks or zones. But I guess, if both is possible
both has its advantages. So I would solve this question from
the point of your requirements.

Are the admin of the local and the global zone the same person?

If so, then manage it in the global zone, because it will be more
straight forward and you don't have to include it in the setup of the
local zone.

If not, decide it using the responsibilities. Should the admin
of the local zone do his own storage management and be responsible
for this? Or should the admin of the global zone take care of
it? Has the admin of the local zone physical access to the machine?
He will need it if he should do the storage management for his zone.

Tom
-----

The hardware is owned and controlled form the Global Zone, all disk
mirroring is done there. A zone is then told what FS it can use. It does
not need to worry about mirroring (and therefore neither would an admin
who only had access to that zone).

Similary if using IPMP, it is set up in the Global Zone and any failover
would not even be noticed by a user of a zone.

HTH
--
> The hardware is owned and controlled form the Global Zone, all disk
> mirroring is done there. A zone is then told what FS it can use. It does
> not need to worry about mirroring (and therefore neither would an admin
> who only had access to that zone).

Well, to some extent.  You certainly can publish a disk device to a
non-global zone and allow it to run the filesystem.  It's not required
that the global zone manage the filesystem.

However, I don't see any way that a local zone would be able to
manipulate SVM stuff.  There's only one set of SVM configuration files,
so it'll be owned by the global zone.

Only if SVM were modified so that it could create a separate
configuration scope for a zone would that be possible.

--
>> However, I don't see any way that a local zone would be able to
>> manipulate SVM stuff.  There's only one set of SVM configuration files,
>> so it'll be owned by the global zone.

> What about ZFS then? There you have filesystem and volume manager in
> the same SW...

And immediately below my quoted line I said that it would need to be
rewritten to have a separate configuration scope to be able to do that.
So it's not impossible, just not done.  ZFS appears to have such support
for distributed management of subareas.

That said, I haven't personally brought up a ZFS filesystem in a pool to
see exactly how it works.  I'm assuming a zone owner would be able to do
filesystem things (create filesystems), but not pool things if the pool
were shared by the global zone (add/move/reconfigure storage).

-----
> That said, I haven't personally brought up a ZFS filesystem in a pool to
> see exactly how it works.  I'm assuming a zone owner would be able to do
> filesystem things (create filesystems), but not pool things if the pool
> were shared by the global zone (add/move/reconfigure storage).

I've got a box running NV27 here, so I figured I'd check this out.

If you set zonepath to something that's on a ZFS volume it isn't
available to be diddled with via zfs.

According to the docs you can export a ZFS dataset to a zone
via the 'dataset' variable in the zone config.  Doesn't seem to
work in NV27.  Again, according to the docs any dataset thus exported
can be diddled with by the zone admin -- apart from setting quotas.
However, the dataset cannot be mounted in the global zone.

That last bit is a gotcha which means we're unlikely to do this
particular trick.  We run all backups from the global zone to
avoid having to buy multiple TSM licenses per host.  But it could
be useful for hosting providers who don't do backups.

Matt

5、>> If the article I mention above is correct, then the cable is likely the
>> problem?  I got the cable from a friend, who didn't know much about the
>> cable.  Does anyone know what the pin mappings should be to go from ttya
>> (25 pin) to a pc serial console (9 pin)?
>>
>> Thanks,
>>
>> ~S
>
> use a null modem
>

Yeah, I just manually checked the pin mappings.  It appears to be a straight
through:

9 | 25
-------
1 | 8
2 | 3
3 | 2
4 | 20
5 | 7
6 | 6
7 | 4
8 | 5
9 | 22

So I either need a null modem adapter or a a null modem cable.

Thanks,

6、>
> A nice hack is to stat one's own /proc/self/lwp directory and
> subtract 2 from the link count.
>
> A more  robust technique is to read the number of directory entries...

Although explicitly documented and presumably supported would be to use
pr_nlwp (member of struct pstatus and struct psinfo) after reading struct
pstatus in from /proc/self/status, or struct psinfo from
/proc/self/psinfo.

> The information will be wrong very easily - why do you need this?

Better not be for making any decisions, if it could be obsolete by the
time you do anything with it.  OTOH, I suppose if you're printing out
some diagnostic info to stderr (where hopefully nobody would be tempted
to try to postprocess it), I don't see any particular harm in it, although
neither do I see that it would be likely to be of much use.

---------
> The source for this app is huge, and there are like 40 different places
> a thread could be created.  Not to mention whatever threads thirdparty
> libs create.

I trust then that each place a thread could be created or destroyed (not
counting library code) will have some diagnostic fprintf()'s added to it,
so you can see where it's unbalanced, if it is in fact leaking threads;
or that you can somehow verify that the number of ongoing external events
(network connections or whatever) and other legitimate reasons for threads
to have been created is reasonably close to the number of threads actually
present at any given moment.

How many threads does ps -L -p pid (whatever the pid is) typically show it
has when it hangs?  Mind you, if it hangs, IMO there's some other problem
(such as ignoring error returns from thread creation or other function
calls; or memory corruption); merely attempting to create more threads than
possible shouldn't hang anything, but rather should provide some error
indication; and from prior discussion, how many is possible tends to depend
on the stack space per thread; less per thread allows more threads before
resources run out or limits are reached.

7、>>while trying to get used to Solaris 10 i was wondering if adding
>>the '-t'-flag to the syslog call in /lib/svc/method/system-log
>>is the correct way to put syslog in nolisten mode?
>
> No. From the man page for syslogd:
>
>   The /etc/default/syslogd file contains the following default
>   parameter settings. See FILES.
>
>   LOG_FROM_REMOTE
>     Specifies   whether   remote   messages   are    logged.
>     LOG_FROM_REMOTE=NO  is equivalent to the -t command-line
>     option. The default value for LOG_FROM_REMOTE is YES.

Thanks for the pointer, should have read the manpage first!

8、rsh NETAPP df

My guess is you are pushing the total volume capacity so that the snapshots

are taking up some of your actual volume space. You will need to remove the

snapshots or wait for them to expire.

rsh NETAPP snap list
rsh NETAPP snap delete VOL_NAME weekly.0

try to delete the oldest to newest and your disk space should be recovered

somewhere along the way

On Wed, 14 Dec 2005 07:46:02 -0600, ogbk <"kenneben"@googlemail.com> wrote:

Hello,

I recently deleted a file mounted on a netapps appliance. The problem is that

since then, the system (running df -k) is still seeing the partition as if

the file was still there. du -ks * on the partition shows that the file has

been deleted. It has been over a day now, and the symptoms persist.

Does anybody know the cause/resolution of this problem, as I'm currently

missing 18GB of space?

9、> Outside of security what are YOU GUYS using Zones for?

Running multiple application environments on a single host.
You can usually get away with running a pile of stuff without
using zones, but it's simpler if you do split them up -- no
more wacky interactions to check out when things go wrong,
and so on.

We'll also start using them soon for multiple Oracle environments
on a single host, e.g., having production, test, dev, and UAT on
one box with appropriate resource limits set so that prod performance
won't be killed by the others.

> Is there some other advantages to Zones which Sun has not publized.
> I'm trying to see if I should look harder at using Zones in our Web
> Services architecture or application (NFS) servers, or in my NIS
> (Homes) server.

I'd definitely look at them for web services, means that customers
with non-standard requirements can be supported with less fuss than
otherwise.  And security is of paramount importance when dealing with
dynamic content.

Matt
--------
> I have read much of the Sun propaganda concerning Zones.  I even
> understand some of the more basic implimentations of Zones in Solaris
> 10.  Outside of security what are YOU GUYS using Zones for?
>
> Is there some other advantages to Zones which Sun has not publized.
> I'm trying to see if I should look harder at using Zones in our Web
> Services architecture or application (NFS) servers, or in my NIS
> (Homes) server.

I find they're useful for experimenting with tricky OS config changes, eg to
pam.conf. It doesn't matter then if I screw them up :-)

I use a zone to hold a "clean" development environment, so I know that when
I build our software nothing horrible leaks in. *Very* useful.

Then I use another zone to do the testing...

All obvious stuff, I'm afraid.

Cheers,

-----
Use then for dev work - can nuke the zone when it all goes horribly
wrong, so much faster than a re-install!

Use it so I can give people full access to a virtual box for there
apps, so makes my life easier.
Also by restricting the CPU and ram usages I don't really care what the
apps in the zones does, so less admin hasel for me.

General allows me to do more with less, can run serveral apps on one
box with the same ports making config and debugging easier.

---
> I have read much of the Sun propaganda concerning Zones.  I even
> understand some of the more basic implimentations of Zones in Solaris
> 10.  Outside of security what are YOU GUYS using Zones for?
>
> Is there some other advantages to Zones which Sun has not publized.
> I'm trying to see if I should look harder at using Zones in our Web
> Services architecture or application (NFS) servers, or in my NIS
> (Homes) server.

Unfortunately, you can't do serve NFS from a zone yet. Don't know when that's
coming.

I'm consolidating my various machines at home onto a single box. Mail server
is in one zone, LDAP will be in a second one (or NIS, if I feel to lazy to
set up LDAP right away, since my NIS server let out all of its magic smoke
the other day), Samba potentially in a third, and when it becomes possible,
NFS in a fourth. Access from the outside through the firewall will only be
able to see a workstation zone, not all of the other service zones. This not
only provides security, but ease of admin.

Hmm. That brings up an interesting question: Is there any 'clone zone' tool
out there?

Colin
.
----
>> I have read much of the Sun propaganda concerning Zones.  I even
>> understand some of the more basic implimentations of Zones in Solaris
>> 10.  Outside of security what are YOU GUYS using Zones for?

[snip]

sigh.  i hate to bring this up.

to get everything to work, i really need at least two machines
to run all my oracle rot.  it's not load/demand, it's that oracle
just doesn't play nice.  i said i needed at least two--but in
fact so far i've only gotten it down to three.

but i have two spare machines, and between them i can carve them
up into three-four machines.  if i could get to six....

this is all so i can do multiple test installations at once.
those of you who know oracle know what i'm talking about.
those of you who don't know, don't want to know--trust me.

j.

---
> to get everything to work, i really need at least two machines
> to run all my oracle rot.  it's not load/demand, it's that oracle
> just doesn't play nice.  i said i needed at least two--but in
> fact so far i've only gotten it down to three.

We routinely run multiple Oracle environments on a single host,
even without zones.  I'm sure there are some wrinkles to it, but
our DBAs seem to have sorted it sufficiently to be able to work.

When I get back from the Christmas break I'll be zoning up a machine
for Oracle use.  That'll have four environments and we'll be using
the resource control stuff to ensure that the production environment
isn't clobbered by test, dev, and training.

Matt

10、How many times have you seen responses like ``Don't you know that
samba is already installed in Solaris 10'', or ``You have to add
/usr/ccs/bin to your PATH to get that to work'' in this newsgroup?
Solaris 10 includes a great deal of excellent software, but it's
hidden from the users.  The result is that people assume that Solaris
is very limited and that they have to install additional software
to get things to work the way that they expect.  Or, people give
up on Solaris and move to something else.

All that's required to reveal this software is to add /usr/sfw/bin and
/usr/ccs/bin to the default PATH for command-line, CDE, and JDS3
sessions.  This can be done in /etc/profile and /etc/.login, or
perhaps in a few other places.  Can this be done?

Personally I would hate to see this done. And I'm certain it won't be,
for reasons I expect others will explain. But that's not why I'm
replying - I want to say I wish Sun (and other non-Linux vendors) would
go the other way and *stop* bundling freeware.

Tools like Perl and Samba are extremely ticklish items, for which maybe
10% of the setup cost is in building and installing and the rest in
configuring and maintaining. By throwing them in, Sun may save some
users the 10% but that gain is more than made up for by the cost of
dealing with down-rev or differently built packages. I cannot say how
much time (but it's a lot) I've lost to perl scripts that fail because
it turned out they were finding /usr/bin/perl (5.6.1) rather than the
in-house build in say /opt/perl/bin which might be 5.8.1. Or one version
has a module installed which the other doesn't. Or, worse, the one in
/usr/bin has an older version of the module which doesn't work right. Or
the HTTP proxies are configured correctly for one and not the other. And
of course there's the classic "perl was built with cc but modules are
being built with gcc" problem. And that's just Perl; more or less the
same goes for Samba or Emacs or Apache. If I want to install Apache, I
have to deal with the fact that there's already an older version of it
around and there's already an /etc/init.d/apache script which must be
either hacked (wrong) or worked around (confusing).

The bottom line is, these SW tools are moving targets. When people speak
of them as static entities ("Solaris comes with Samba") they've already
lost their way. I miss the days when if one of these packages was
present it was because you put it there. I don't mind so much the stuff
they "hide" in /opt/sfw or /usr/sfw because you can stay away from it.
The stuff they put on the default path is the big problem.

Therefore I take the opposite point of view from the OP: I wish they'd
move ALL non-traditional SW to somewhere off the beaten track.

Now, I understand there are OpenSolaris distros which are basically
Linux running on the Solaris kernel. That seems like an interesting line
of development but I see no reason for Solaris per se to go that way.

----
>Gary Mills wrote:
>> How many times have you seen responses like ``Don't you know that
>> samba is already installed in Solaris 10'', or ``You have to add
>> /usr/ccs/bin to your PATH to get that to work'' in this newsgroup?
>> Solaris 10 includes a great deal of excellent software, but it's
>> hidden from the users.  The result is that people assume that Solaris
>> is very limited and that they have to install additional software
>> to get things to work the way that they expect.  Or, people give
>> up on Solaris and move to something else.
>>
>> All that's required to reveal this software is to add /usr/sfw/bin and
>> /usr/ccs/bin to the default PATH for command-line, CDE, and JDS3
>> sessions.  This can be done in /etc/profile and /etc/.login, or
>> perhaps in a few other places.  Can this be done?

>Personally I would hate to see this done. And I'm certain it won't be,
>for reasons I expect others will explain. But that's not why I'm
>replying - I want to say I wish Sun (and other non-Linux vendors) would
>go the other way and *stop* bundling freeware.

The default web browser is in /usr/sfw/bin.  `ld' is in /usr/ccs/bin.
Certainly, those directories should be in the default path.  By and
large, the new software in /usr/sfw is one of the things that makes
Solaris 10 so superior to Solaris 9.

>Tools like Perl and Samba are extremely ticklish items, for which maybe
>10% of the setup cost is in building and installing and the rest in
>configuring and maintaining. By throwing them in, Sun may save some
>users the 10% but that gain is more than made up for by the cost of
>dealing with down-rev or differently built packages.

Perl has been integrated with Solaris for some time, although the
/usr/bin/perl symlink can be removed without affecting the internal
use of perl.  I agree, though, that multiple versions of perl are a
support nightmare in some environments.  In others, the built-in
version of perl is all that the user needs.  Still, It would be good
to have a clean way to add libraries to Sun's perl.

Samba is an example of a product that requires considerable compile-
time configuration.  The one that's supplied with an OS will likely be
suitable for most uses, but not all of them.  For example, I recently
built samba for Solaris 9 and 10 because I needed to configure it with
the Mysql libraries.  I suspect that I would have had to do the same
thing with samba on Linux.  This sort of thing is always going to happen
in a few cases.  It shouldn't be a reason to stop providing useful
software.

>The bottom line is, these SW tools are moving targets. When people speak
>of them as static entities ("Solaris comes with Samba") they've already
>lost their way. I miss the days when if one of these packages was
>present it was because you put it there. I don't mind so much the stuff
>they "hide" in /opt/sfw or /usr/sfw because you can stay away from it.
>The stuff they put on the default path is the big problem.

>Therefore I take the opposite point of view from the OP: I wish they'd
>move ALL non-traditional SW to somewhere off the beaten track.

That's essentially what they've done.  Software in /usr/sfw is
supported by Sun.  I'd like to see it made visible to the users.

----
>Samba is an example of a product that requires considerable compile-
>time configuration.  The one that's supplied with an OS will likely be
>suitable for most uses, but not all of them.  For example, I recently
>built samba for Solaris 9 and 10 because I needed to configure it with
>the Mysql libraries.  I suspect that I would have had to do the same
>thing with samba on Linux.  This sort of thing is always going to happen
>in a few cases.  It shouldn't be a reason to stop providing useful
>software.

The "source, source, source" mentality causes some evil issues; you
cannot really make a binary distribution of something which has
compile time options.  Fine for Gentoo folks, but not for binary
distributions.

>>The bottom line is, these SW tools are moving targets. When people speak
>>of them as static entities ("Solaris comes with Samba") they've already
>>lost their way. I miss the days when if one of these packages was
>>present it was because you put it there. I don't mind so much the stuff
>>they "hide" in /opt/sfw or /usr/sfw because you can stay away from it.
>>The stuff they put on the default path is the big problem.

Actually, I really like them to be there; the reason is that I have
*so* many systems and building one from scratch is painful without
all those things present.  When installing a new "environmental friendly"
firewall/webserver/fileserver for home use, I only had to install
three tools thusfar one the clean Solaris installation.  Having perl,
samba and all the rest present saves me a lot of work.

But perhaps I'm differnet; I also do not have a need for bleeding edge "X";
it would mean upgrading X on too many systems; by having them in Solaris,
I just upgrade the 10 or so Solaris systems I run every other week and the
additional packages are upgraded alongside.

>That's essentially what they've done.  Software in /usr/sfw is
>supported by Sun.  I'd like to see it made visible to the users.

Agreed.  Hiding stuff in /usr/ccs/bin and /usr/sfw/bin doesn't
serve any purpose.

Casper

-----
Actually, I really like them to be there; the reason is that I have
*so* many systems and building one from scratch is painful without
all those things present.  When installing a new "environmental friendly"
firewall/webserver/fileserver for home use, I only had to install
three tools thusfar one the clean Solaris installation.  Having perl,
samba and all the rest present saves me a lot of work.

But perhaps I'm differnet; I also do not have a need for bleeding edge "X";
it would mean upgrading X on too many systems; by having them in Solaris,
I just upgrade the 10 or so Solaris systems I run every other week and the
additional packages are upgraded alongside.

Perhaps the difference is in the environment. If you're setting up a system

for personal use, or for a short-term use, I can see where prebuilt SW can be

a considerable convenience. But when you're managing a large, heterogeneous

corporate or university network the prebuilt versions are useless to you.

There will be a corporate standard for perl and it will generally be a

different version from what happens to be on the solaris boxes (not to

mention that you may have solaris versions running from 2.5.1 to 10 with

different or missing perl versions themselves). In this environment the local

perl can only get in the way. Similarly, if you need Samba at all it will be

on a dedicated server hardened and tuned for that purpose. And the odds of

any business which uses Apache outside the firewall trusting the stock

version are low.

In all these cases the bundled tools could be useful in some corner cases

(bootstrap stuff, proof-of-concept, etc.) If I'm testing out Subversion it

might be handy to have an Apache server lying about. But for everyday use in

that kind of environment, my experience is that they do not help and can only

cause confusion.

On a more practical level - how many .profile files out there do something

like this:

 PATH=$PATH:/usr/local/bin

Now if the next upgrade of solaris appended /usr/sfw/bin et al to PATH, those

users would suddenly start finding different tools and it would break the

compatibility promise.

HT
.
----
>On a more practical level - how many .profile files out there do
>something like this:

> PATH=$PATH:/usr/local/bin

>Now if the next upgrade of solaris appended /usr/sfw/bin et al to PATH,
>those users would suddenly start finding different tools and it would
>break the compatibility promise.

That argument would also prohibit a software vendor from ever adding a
command to any of the standard directories in the standard $PATH.

I'd expect a preference for local commands to be expressed as:

 PATH=/usr/local/bin:$PATH

(Use the local perl, etc)

Commands can get added and they can be moved around; all those action
may influence what's in /usr/bin and other standard user directories.

I don't see how a OS vendor can avoid this situation; it seems that
only the customer can setup their environment such that it is future
proof; to me, that would mean that /usr/'local/bin comes in $PATH
first.

Casper

-----
I'd expect a preference for local commands to be expressed as:

 PATH=/usr/local/bin:$PATH

(Use the local perl, etc)

Commands can get added and they can be moved around; all those action
may influence what's in /usr/bin and other standard user directories.

I don't see how a OS vendor can avoid this situation; it seems that
only the customer can setup their environment such that it is future
proof; to me, that would mean that /usr/'local/bin comes in $PATH
first.

That makes sense, but there is an additional complication in certain
cases.  The preference for local vs. built-in commands may be based
on the particular sets of local and built-in commands at the time
the decision is made.  Sometimes there is no grand design behind
system directories vs. /usr/local, and the individual user is faced
with two different possible sets of commands (the set formed by
putting /usr/local/bin first, and the set formed by putting it last).
In such a case, the user basically ends up choosing which order to
put things not based on policy but based on the actual contents of
the directories at the time they make the decision.

In the ideal world, it wouldn't be like that, but in the real world,
a big /usr/local can be built up over the course of several years
and may end up being maintained by several different people.  And
even if there is a policy about whether to use executable names
that collide with ones the system uses, it may change over time.

Obviously, as you say, the OS vendor can't control this.  But where
possible, it is helpful if the OS vendor can avoid things that will
make a messy situation even messier.  :-)

Also, one other completely different reason for having /usr/local/bin
last is that sometimes /usr/local/bin is on NFS, so it's faster (and
more fault-tolerant) to have it at the end of the path.  You may not
be able to get work done if the NFS server goes down, but you might at
least be able to type "ls" and "ping" and figure out what's happening.

  - Logan

----
> Perhaps the difference is in the environment. If you're setting up a
> system for personal use, or for a short-term use, I can see where
> prebuilt SW can be a considerable convenience. But when you're managing
> a large, heterogeneous corporate or university network the prebuilt
> versions are useless to you.

If you're running a large corporate or university network, the absolute
_LAST_ thing you want is a heterogeneous environment. One, two, or maybe
three OS builds across the entire world, for a given platform should be
quite sufficient. (As an example, we have one Solaris build for workstations,
one for servers, and one for DMZ boxes.) Old cruft gets upgraded on an
irregular but comprehensive basis. There are no 2.5.1 boxes, and will be no
10 boxes outside of our test environment until we do a migration. Then we'll
migrate everything. It'll be painful for a few weeks, but admin overhead is
massively reduced afterwards.
The end result is that acceptable standard tools are based on the OS version
defaults. We wouldn't build tools with bzip2 in S8, since it wasn't part of
the S7 install but might use it in S9 and forward. (Except of course that
performance is a big issue in bzip2 vs. the small gains over gzip.)

Similarly,
the built-in perl is used for all scripts, with compatability maintained to
the version that came with the previous OS release. If this is impossible,
then it gets revisited on a case-by-case basis, but the first question to ask
is always: Is the new feature compelling enough that we have to maintain a
separate package on a single (suddenly non-standard) box? The answer is
no much more often than yes.

Curiously, this matches up fairly well with Sun's philosophy on /bin/sh.
Well, administrative conservativism makes for lower overhead.

> On a more practical level - how many .profile files out there do
> something like this:
>
>        PATH=$PATH:/usr/local/bin
>
> Now if the next upgrade of solaris appended /usr/sfw/bin et al to PATH,
> those users would suddenly start finding different tools and it would
> break the compatibility promise.

Well since /usr/local is outside of Sun's software location, it's not
breaking compatability to put tools elsewhere that supercede it. On a more
practical note, I do the above quite often but (a) expect to find my tools
only if the OS doesn't already have them bundled, and (b) haven't run into
any glaring incompatabilities between my version of 'blat' and Sun's.

It's hard to avoid this sort of problem, though. Sooner or later, admins
and users have to decide how they're going to operate, and all that vendors
can do is behave consistently.

Colin
---

11、>In article <439f457f$0$11068$e4fe514c@xxxxxxxxxxxxxx>,
>Casper H.S. Dik  <Casper.Dik@xxxxxxx> wrote:

>>>prtdiag
>>>prtdiag: failed to open SMBIOS: System does not export an SMBIOS table
>>
>>>uname -a
>>>SunOS s11 5.11 schily27 i86pc i386 i86pc
>>
>>>did this change with build 28?
>>
>>
>>No; there are quite a few BIOSes where this doesn't work and on some
>>it's our fault.
>>
>>smbios/smbios -B

>This gives nearly the same output:

>smbios -B
>smbios: failed to load SMBIOS: System does not export an SMBIOS table

Try:

 smbios -B /dev/xsvc

Casper
---------
> Casper H.S. Dik  <Casper.Dik@xxxxxxx> wrote:
>>christopher.p.brinley@xxxxxxxx writes:

>>>I know this tool is not supported on intel platform, is there anything
>>>comparable out there?

>>It is in Solaris Express.

> This is what I get:
>
> prtdiag
> prtdiag: failed to open SMBIOS: System does not export an SMBIOS table

Check /var/adm/messages.  Are there any "SMBIOS not loaded" messages logged?

Something like this:

  unix: [ID 672469 kern.info] SMBIOS not loaded (SMBIOS header checksum

mismatch)
or
  unix: [ID 672469 kern.notice] SMBIOS not loaded (SMBIOS data structure is

corrupted)
or
  unix: [ID 672469 kern.info] SMBIOS not loaded (SMBIOS format is too old for

processing)
or
  ...

Fixes for some of the smbios issues can be found on the thread:

  <URL:http://www.opensolaris.org/jive/thread.jspa?messageID=12106>

> uname -a
> SunOS s11 5.11 schily27 i86pc i386 i86pc
>
> did this change with build 28?

No, smbios support was added ~ snv_23