Powering Sun M4000/5000 Series Servers Down And Up From The XSCF

Hey There,

Today's post is more beginner-oriented than the last few days' posts on deleted data recovery on Linux and Unix.

Below is a little walkthrough on the very basics of powering on, and powering off, M4000/5000 Series Sun Servers from the XSCF (eXtended System Controller Facility, or something roughly approximate) command line. These instructions should also apply to the M8000/9000 Series servers as well, but, since I'm getting all my output directly from an M4000, I don't want to "assume" anything incorrect about the higher end servers.

The basic steps we're going to walk through are simply logging in, powering down a domain, powering on a domain, and jumping back and forth between the XSCF command line and the M4000 console.

For the purposes of today's post, we're going to assume that the basic XSCF setup has been completed and you have an admin login account on it. You've also set up ssh (naturally) and disabled the web-based interface (because its so insecure... ;) Your admin account is "admin" - Also, in the spirit of keeping this simple, we're going to assume that you've only set up one domain on your M4000, and you've used the default first domain: domain 0.

Connecting to the XSCF is as simple as connecting to any server, assuming you have an account ;)

host # ssh admin@host-xscf
admin@host-xscf's password:
Last login: Sat Mar 28 17:55:52 2009 from fridgehost.beernutz.com

Once you're logged on, if you want to get to the console of your M4000 server, all you need to do is use the "console" command, like so (-d denotes the domain number and I use -y so I don't have to answer the "are you sure?" question every time):

XSCF> console -d 0 -y
Connect to DomainID 0?[y|n] :y

host console login: user
Password:
-bash-3.00$ exit

To get back to the XSCF prompt from the console, just type "pound dot" (literally #.) and it will kick you back to the XSCF from the console.

host console login: #.
XSCF>

Powering off the M4000 from the XSCF prompt is even more trivial ;) It should be noted that running "poweroff" at the XSCF command line is equal to running "init 5" at the command line, as root. "poweroff" will not tell you if your command was successful or not (neither will "poweron"), but you can find out the status of your request easily, by using the "showlogs" command. Also, just running "poweroff" again will let you know the status. If your previous invocation worked, you'll get an error that the machine is already powered off:

XSCF> poweroff -d 0 -y
DomainIDs to power off:00
Continue? [y|n] :y
....
XSCF> showlogs power
Example: Jan 08 16:47:45 EST 2009 Domain Power Off Operator 00 Locked
XSCF> exit

Powering on the server from the XSCF prompt is pretty much the same rigmarole :)

XSCF> poweron -d 0 -y
DomainIDs to power on:00
Continue? [y|n] :y
....
XSCF> showlogs power
Example: Jan 08 16:47:45 EST 2009 Domain Power On Operator 00 Locked
XSCF>

And that will, eventually, bring you right back to up. You can log into the console, from the XSCF prompt, before POST begins, if you want to see everything that happens on the console when you boot:

XSCF> console -d 0 -y
Connect to DomainID 0?[y|n] :y

b0939db-s console login: user
Password:
Last login: Sun Apr 5 16:57:14 from host
-bash-3.00$ exit

host console login: #.
XSCF> exit

And that's pretty much all there is to powering on and off your M4000/5000 Series server using the XSCF :)

Enjoy, but (as always) use caution if you're not sure what you're doing. As one last hint. If you get stuck at the XSCF prompt and need to know what to type next (There are no obvious hints), just type:

XSCF> man intro

or

XSCF> [tab][tab]
do you want to see all .... entries

That's literally hitting the tab key twice, above. Then it will ask you if you want to see all the available commands listed out. If you know what you want to do and you just can't remember the command name, [tab][tab] is your friend. If you think you know the name, and you also need to know a little bit about the command, then the man page for "intro" is your best bet.

Enjoy and cheers

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

M4/5000 XSCP Unintentional Denial Of Service

Hey There,

I'm not sure if this is "standard" yet, since I think I found a "bug/feature" in the Sun M4000 this weekend and had a pretty constant relationship with their support department during the investigation. Except for the fact that I had to work, it was a pretty decent experience ;)

We had a very strange situation happen that, in fact, completely crippled two of our M4000 servers. The XSCF cards on them experienced an "issue" and that meant that both servers were, for all intents and purpose, out of commission. And, I don't know if the phrase "for all intents and purposes" really does the situation justice. Those machine were actually completely inoperable. At least, in any useful sense. On the M4000 server, if the XSCF card isn't working correctly (or - while this didn't happen with us - removed) you have no way to boot the server up properly, much less get power to any of the domains the server runs. Yow! So, even though this wasn't our issue, always be extra careful not to jiggle that card loose, since it's directly accessible on the back and can be jostled around using the squeeze-grip attached to the outside.

The trouble all started when we had to Re-IP the XSCF cards on two servers. We'd never done this before and, although it's a practically painless experience, it does lead to one of the ways you can cause this denial of service (purely by accident, of course - please don't do this on purpose, even though it would very easy to. In fact - don't do it "because" it's so easy - no challenge - where's the reward? ;) Since we had been issued bad IP's in our Network build sheet, we had to Re-IP the XSCF's. Part of the process involved issuing the "rebootxscf" command which (with the configuration above) causes everything (or, at least all platadm and most basic commands) to begin failing strangely (errors on the command which show up as okay in the audit logs, inability to poweron domains, etc).

And this is where it got interesting. Through testing of various methods of power-cycling with this plugged into that and that plugged into this with the keyswitch in various positions, we could only find two ways to reproduce the error that made it seem like our M4000's were completely toast and would have to have the XSCF restored to defaults in order to access our domains that (hopefully) wouldn't get destroyed in the process (which they didn't).

Here are the two ways to accomplish the meltdown (followed by an explanation of the "why" - made, I might add, possible by the helpful folks at Sun tech support - I'm not selling anything, just thinking how a lot of times people who do the right thing don't get the recognition they deserve. Murderers, psychopaths and hate groups couldn't buy the free publicity they get in this country ;):

1. Setup either one, or both, of the Ethernet controllers that come standard on the single XSCF card. Then, after you've booted up and configured a domain (basically, made your M4000 usable and useful), remove the serial cable from the pseudo-serial port and replace it with straight Ethernet (connected to the same subnet). This will not cause you any problems. Things will continue to work as normal, except for a few seconds after you insert the Ethernet in the pseudo serial port when the XSCF readjusts to having an additional "path" to/from itself and the network. Now, ssh or telnet to the XSCF card and type:

XSCF> rebootxscf

you will be prompted that this will reset your system, which is (presumably) what you want. You'll note, within seconds, that your command prompt comes right back up and you never get disconnected. Now, even if you type something like "showdate," you'll get a "permission denied" error. Not to mention the fact that you can't run any other helpful commands like "showlog" or "rebootxscf"

2. Do the same thing you did before and power cycle your M4000. The M4000 doesn't really have an off switch, so the proper way to do this is to put the keyswitch into maintenance (or service) mode (the picture of the wrench ;) and pull the plugs to both power supplies. This will work even if you just pull the power with no regard for the state of your keyswitch. The machine will never fully come up. The amber "check" LED will go blank, but the flashing green "XSCF" LED will never stop flashing (This would usually mean that it was busy initializing). You should be able to ssh or telnet to your XSCF card, anyway, but the limitations on your usage will be as bizarre as in example 1 (As another for instance, you can create any user you want and give them all the administrative privileges you need to - assuming you have them already - but you can't do nslookup, power on/off/connect-to any domains and, as above, will not be able to run "rebootxscf.") All the restrictions, in both instances, are the same. There are so many goofy things to list, it would take a few pages.

HELPFUL HINT: If you get stuck in this situation and don't have physical access to your box, you won't be able to run "showlogs," but if you have auditadm privileges, you can run viewaudit, which can be helpful, but sometimes says that your commands are completing successfully when you get permission denied on the console and nothing happens ;)

Now, for the why as I understand it. The M8000/9000 series servers actually use the pseudo serial ports to connect primary and secondary (MASTER/SLAVE - Active/Standby) XSCF's for a redundant setup. Apparently, this functionality is going to be introduced into the M4000's. Actually, the possibility is already there (slots available, etc). So, in effect, what we did when we created this "crazy" situation was take advantage of a feature that isn't street-ready yet. Basically, once we attached the Ethernet cable to the pseudo serial port, we made the M4000 think it was the SLAVE XSCF in a redundant setup that doesn't (or maybe, at this point, CAN'T) exist. This knowledge pretty much explains all the insane error messages ;)

I hope this rundown, although drier than usual, is helpful to someone out there. Sunsolve, Sun support and Google couldn't find an answer for 3 days (Actually, I'm not sure if Sunsolve or Google have this yet - There are a few Sun FE's that know it now, though ;)

All in all, a bad experience that resulted in something good.

ONE LAST HELPFUL HINT: If you want to prevent this from ever accidentally happening (since it won't if the pseudo serial port isn't being used) one thing you can do is to plug a serial cable or dongle in the pseudo serial port. It doesn't have to be connected to anything and won't cause you any problems, but may discourage other folks from plugging anything else in there :)

Cheers,

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Sun M-Series Enterprise Unix Servers And DSCP - Why?

SPECIAL NOTE: Friday's post on the absorption of knowledge was written on Blogspot in IE7 and suffered from some horrible display problems on FireFox and other browsers. It has been completely retooled. Apologies for any inconvenience that post caused. Even though I write some goofy rants, missing text wasn't supposed to be part of that post's intentionally cryptic style. Thanks :) - Mike

Hey there,

Today, we're going to look at DSCP (The Domain to Service processor Communication Protocol) and why it was introduced with the newer M series Enterprise servers from Sun. The first time I ran into it, I thought approximately the following: All right, here's something else that can make my life more complicated ;) Now, not only do I have to hop onto a private network (added security at work) to connect to the service processor (SP), but then I have to be sure that an entirely separate network is functioning correctly in order for me to connect to a domain on my machine if I want to get there directly from the SP. I'm naturally negative, but I keep it inside until I've given myself the time to realize that things are either not as bad or better than I initially assumed, which goes a long way toward maintaining good relationships with other human beings ;)

DSCP, although it "is" another layer of complication, is actually a pretty good idea. In essence, it's an attempt at damage control and resource sharing (which almost never works entirely), on par with earlier "HUGE" Sun computers, which does a pretty decent job at a relatively low cost. And, I use the word "cost" in reference to the amount of work you have to put into getting it all set up and working correctly. It's practically free, in that respect, so kudos (The plural, pronounced kyu-doze) to Sun for adding a little extra protection and making it an additon to an existing model that doesn't encumber the admin or user to a noticeable degree. Once it's set up, it may as well be non-existent. ...unless you have problems with it, but that's a general rule when it comes to anything.

Inter-process communication on the 6800/6900, etc boxes was handled pretty decently as well, but didn't really lay ground for the possiblity of scaling easily in the future. On those boxes, shared memory (for example) was "stuck" to a single SP, so if you had multiple SP's, you essentially had multiple machines, each alienated from the other with regards to system resources. The 6800/6900's were, as one would expect, worse in this regard than the 15k-and-up models (check out the price tags. Some times it can be an indicator of quality. Is the difference in ease of sharing worth it? Depends on your situation)

The 15k-and-up servers ran physical ethernet from the service processor(s) to the domain controllers (whereas, if I forgot to mention above, the older mailbox-architecture was imbedded and much more difficult to "change"). This setup made it slightly easier to re-allocate resources since you basically had a MAN setup on your Sun system (Maintenance Area Network for those of us who still care ;). Since the MAN operated at the application layer of the stack, all you had to do to scale up when you added a new product or application was assign a new TCP port. And that was that: Sharing made much simpler. There's a lot of nitty-gritty behind it all, but who wants to read about that? If you do, check out docs.sun.com and go nuts ;)

So, now, we've made it all the way up to the almost-present (we'll just consider it the "now" for now ;) and the M-Series servers. Since the MAN configuration of the 15k-and-up servers worked out so beneficially, that concept was guaranteed to be built in to the next generation of Enterprise computers. The one big drawback, from an architectural perspective, was the fact that the 15k-and-up servers had a whole bunch of externally exposed cables patched all over the place to maintain that separate MAN network (lots of ways to goof that up). The DSCP is Sun's way of taking care of that issue while maintaining the extended reliablity (and security) introduced with the MAN concept.

DSCP reproduces the 15k-and-up MAN using shared RAM, a pseudo-serial driver and PPP. To the user, this means all the benefits of a MAN, without all of the cords ;) Actually, it's a very nice implementation of physical-to-virtual transformation. And, as we all know, in about 10 to 15 years, we'll all be virtual and the only people left alive on the planet earth will be maintenance technicians ;)

The best thing about DSCP is how incredibly complicated it is to set up. Just kidding ;) It's actually incredibly simple. So simple that, if you're like me, you're wondering when a monkey is going to be able to start doing your job ;) Assuming an unlimited amount of Domains attached to a service processor, setup of DSCP is as simple as this:

XSCF> setdscp -i 10.0.0.1 -m 255.255.255.0
Commit these changes to the database? [y|n] : y

or, even simpler:

XSCF> setdscp
DSCP network  [10.0.0.1       ] >
DSCP netmask  [255.255.255.0  ] >
XSCF address  [10.0.0.2       ] >
Domain #00 address  [10.0.0.3       ] >
Domain #01 address  [10.0.0.4       ] >

These examples are from an M4000 with only 2 domains, but the flavour stays the same on the larger boxes in the series. The only thing you really have to worry about (just like your MAN networks) is that you pick a network that doesn't get used. Generally, as shown above, using a non-routable network is best practice. Although I accidentally typed a 24-bit netmask for a class C IP (and used 1 for the network instead of 0), it doesn't really make a difference.

Of course, displaying the information is just as simple (should you forget):

XSCF> showdscp

DSCP Configuration:

Network: 10.0.0.1
Netmask: 255.255.255.0

Location     Address
----------   ---------
XSCF         10.0.0.2
Domain #00   10.0.0.3
Domain #01   10.0.0.4

The key benefit, aside from the easier resource sharing that carries over from the MAN days, is the extra protection each domain is provided. Assuming an exploit is commited against one domain, whoever's gotten onto your box and screwed up that configuration will have to work harder to get to the other connected domains, since they'll have to go through the XSCF to get there. There is no absolute direct connection between domains. Although, since I know somebody out there is thinking this, it "is" still possible to attack all the domains on an M-Series machine at once; just not in an overt fashion. For instance (and I'm not encouraging this behaviour in any way whatsover) if you can create a situation whereby the administrator needs to power-cycle his/her M-Series server to restore functionality to the exploited domain, you've just brought all of the domains down in one fell swoop.

And, in closing, if you can't get to the XSCF to check out the DSCP configuration and you have the proper privilege and access to a domain hosted on an M-Series server, you can obtain that same information using the prtdscp command. Even more convenient, you can SSH (assuming you've set it up) directly from your domain to the DSCP IP using a command similar to:

host # ssh `prtdscp -s`

If you work somewhere that can afford it, enjoy the convenience :)

Cheers,

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Taking Full Advantage Of "Who" On Solaris

Hey there,

First things first: Happy Christmas Eve :) Our apologies to our readers who celebrate different festivities this time of year. It's not that we don't want you to enjoy them (although our wishes are probably belated for some), just that we almost forgot about our own... What does that say about us? We don't know either ;) In the spirit of "it's never too late" - Happy Holidays (whatever they may be) from all of us :)

This post is more of an expansion, than a follow-up, to our May 2008 post on using who to find out what and when on Linux and Unix (picking only the options that appeared in most distro's version of "who"). It's also a bit more restrictive than our previous post, as we're restricting the discussion to newer Solaris' (8/9/10) implementation of the classic command (Okay, "according to Hoyle" (and I'm using that idiom loosely, since this post has nothing to do with the game of Whist ;), it can't be a classic for another 12 years, but if TNT can televise "new classics" that just came out last year, the meaning of the word has either been completely devalued or we're making liberal use of artistic license. We prefer the latter justification ;)

Solaris' implementation of who is a great deal better than in older versions, and turns what used to be a "mostly" informational command into a command that you can use to really get to the bottom of things. Following, a list of Solaris who's usage parameters and a brief discussion of each. One thing that should be noted is that the Solaris who command has no "help" switch (-h, --help, nothing), and it will produce output if you just run it without arguments. We usually go with "who -h" (since -h isn't an option) to get usage/help output. You'll have to subject yourself to the humiliating error message, but it's generally worth it ;)

Ladies and gentleman, The Options :)

1. Who straight-up (what better way to start a list of options than with the no-option option? This is what you get if you settle. Four columns: User ID (NAME), terminal (LINE), date (TIME) and local-screen/IP-address:

host # who
user001    console      Dec  8 09:48    (:0)
user001    pts/3        Dec  8 09:50    (:0.0)
user001    pts/5        Dec 23 08:56    (10.99.99.99)

2. -a. This option is fairly obvious. It stands for "all" and is the equivalent to using "-Abdlprtu" which, the astute among you may have noted, does not comprise the entirety of the options available ;) We'll go over all the options that are lumped together in this option shortly (If I had more time to proofread, I wouldn't have made the word option a tag for this post ;).

host # who -a
   .       system boot  Dec  8 09:46
   .       run-level 3  Dec  8 09:47     3      0  S
zsmon           .       Dec  8 09:47  old     307
LOGIN      console      Dec  8 09:47  old     331
user001  + console      Dec  8 09:48  old     663       (:0)
user001  + pts/3        Dec  8 09:50  old    1015       (:0.0)
user001    pts/4        Dec  8 10:37  old       0  id=  /4 term=0   exit=0
user001  + pts/5        Dec 23 08:56   .    17914       (10.99.99.99)
user001    pts/4        Dec 11 16:15  old   28003  id=ts/4 term=0   exit=0
user001    pts/6        Dec 19 10:39  old   11406  id=ts/6 term=0   exit=0
user001    pts/7        Dec 18 16:40  old    9997  id=ts/7 term=0   exit=0
user001    pts/8        Dec 16 14:05  old    5804  id=ts/8 term=0   exit=0

3. -b. This option will show you the last time the system booted. This can be very helpful (especially when used in combination with "last -x" to make use of last's full potential):

host # who -b
   .       system boot  Dec  8 09:46

4. -d. This option purports to list out "dead" processes. The reason we phrase it in that way is that, generally, these processes (or pseudo terminals) may have been used before, but this doesn't mean that they're hanging around like a bunch of zombie processes. For instance, the following output lists 5 "dead" pseudo terminals, although none of them can be found in the output of either "ps" or "lsof" (???) In any event, it's a cool feature :)

host # who -d
user001    pts/4        Dec  8 10:37
user001    pts/4        Dec 11 16:15
user001    pts/6        Dec 19 10:39
user001    pts/7        Dec 18 16:40
user001    pts/8        Dec 16 14:05

5. -H. This one is a fantastically fun joyride through the land of the obvious. It forces who to print out the header for each column it reports on (although it does forget about the display/IP column noted in straight-up "who" output from point 1):

host # who -H
NAME       LINE         TIME
user001    console      Dec  8 09:48    (:0)
user001    pts/3        Dec  8 09:50    (:0.0)
user001    pts/5        Dec 23 08:56    (10.99.99.99)

6. -l. Using who with the -l option lists out only "login" processes. Basically, it will only report on logins that are logged in (or appear to be logged in) to the localhost directly (no external pseudo terminals):

host # who -l
zsmon           .       Dec  8 09:47  old     307
LOGIN      console      Dec  8 09:47  old     331

7. -q. This will perform a quick who (only showing the NAME field), and is the only option that the -n option works with. If you use -n with -q, you can specify the number of returned processes you want to see per line of output, at most. By default, who -q tries to return as many results as possible on a single line:

host # who -q 
user001  user001  user001

who -q -n 2
user001  user001
user001

8. -r. This option will let you know what run level your system is currently at (again, check out our previous post on using who for more specifics on all of the output "who -r" produces:

host # who -r
   .       run-level 3  Dec  8 09:47     3      0  S

9. -s. This option is considered the "short form," since it doesn't report any "time since last login," session activity status or PID output. who, run with this option alone is actually the default output. The one time this comes in handy is when you're using it with -a (and -H for the headers, if you want), and want to trim that output a bit. Otherwise, using this option wouldn't make sense, since you'd have to specify the flags to print the two fields you want removed ;)

host # who -s
user001    console      Dec  8 09:48    (:0)
user001    pts/3        Dec  8 09:50    (:0.0)
user001    pts/5        Dec 23 08:56    (10.99.99.99)

host # who -asH

NAME       LINE         TIME
   .       system boot  Dec  8 09:46
   .       run-level 3  Dec  8 09:47     3      0  S
zsmon           .       Dec  8 09:47
LOGIN      console      Dec  8 09:47
user001  + console      Dec  8 09:48    (:0)
user001  + pts/3        Dec  8 09:50    (:0.0)
user001    pts/4        Dec  8 10:37
user001  + pts/5        Dec 23 08:56    (10.99.99.99)
user001    pts/4        Dec 11 16:15
user001    pts/6        Dec 19 10:39
user001    pts/7        Dec 18 16:40
user001    pts/8        Dec 16 14:05

10. -t: This option will show you all the times that your system clock was reset (and, yes, sometimes this output can be empty, for reasons that require no explanation ;)

host # who -t
host #

11. -T. This flag shows your tty status (referred to also, above, as session activity status). The + symbol indicates that the tty's status is "writable," the - symbol indicates that the tty's status is "not writable" and the ? symbol indicates general confusion ;) It just means that the system has no idea what the tty's status is, which generally means that it's hung:

host # who -T
user001  + console      Dec  8 09:48  old     663       (:0)
user001  + pts/3        Dec  8 09:50  old    1015       (:0.0)
user001  + pts/5        Dec 23 08:56   .    17914       (10.99.99.99)

12. -u. This flag lists out (and I'm quoting from the "usage" output) "useful information." That isn't to say that any other output you can get from who is completely useless. Although, the terminology does seem to cast a shadow... ;)

host # who -u
user001    console      Dec  8 09:48  old     663       (:0)
user001    pts/3        Dec  8 09:50  old    1015       (:0.0)
user001    pts/5        Dec 23 08:56   .    17914       (10.99.99.99)

13. -m. This flag limits the information to the current terminal session only. As you can see below, we're logged in using pseudo tty /dev/pts/5:

host # who -m
user001    pts/5        Dec 23 08:56    (10.99.99.99)

14. And, to begin the wrap-up, Solaris' who makes up for the fact that it doesn't have a built in handler to deal with being called as "whoami" by providing two different options to get that same information. In an alarming show of disregard for proper capitalization, both of these versions work ;) Note that this output is almost always exactly the same as the output from "who -m":

host # who am i
user001    pts/5        Dec 23 08:56    (10.99.99.99)
host # who am I
user001    pts/5        Dec 23 08:56    (10.99.99.99)

follow that up with the question that, statistically, follows "who am I?" most often, give it a little bit of "Talking Heads" flavour, and you've got yourself a command that's completely useless ;)

host # my God, what have I done?
-bash: my: command not found

15. Back off the Road To Nowhere (David Byrne, again. Make him stop!! ;)... Lastly (no pun intended, as you'll understand by the end of this paragraph), you can use who, using any combination of options (with the exception of -n, which only works with -q), and follow it all up with a different utmpx file (if, for instance, your old one got to big and you copied it off somewhere). Straight up who on Solaris makes use of /var/adm/utmpx, but you can tell who to use any utmpx-like file (including wtmpx, which can make the "who" command emulate the "last" command to a basic degree):

host # who /var/adm/wtmpx
root       console      Nov  6 13:39
root       console      Nov  6 13:48    (:0)
root       pts/3        Nov  6 13:51    (:0.0)
root       pts/3        Nov  6 14:38    (:0.0)
root       pts/4        Nov  6 14:39    (:0.0)
user001    sshd         Nov  7 09:48    (host.subnet.domain.com)
user001    pts/4        Nov  7 09:48    (host.subnet.domain.com)
user001    sshd         Nov  7 09:54    (host1.subnet2.domain3.com)
user001    pts/5        Nov  7 09:54    (host1.subnet2.domain3.com)
...

Here's hoping today's post help shed a bit more light on Solaris' who options than the standard usage screen does, pointed out a number of reasons it can be a great tool to have in your troubleshooting arsenal and (perhaps) taught you a trick or two :)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Quick XSCF Setup Walk-through For The Sun M4000 Server

Hey there,

You may have noticed (sometime in the last year or so ;) that I like to write about Sun computers and Solaris almost as much as I like to write about the many variants of Linux out there, without which I might not even have gotten interested in computing in the first place. Fortunately, or unfortunately, Sun still doesn't pay me residuals to write about their stuff. Admittedly I haven't, yet, screwed up the nerve to attempt brokering a pay-per-post deal with them (or anyone, for that matter). The end result would, of course, be the sound of a closing door, at best. Perhaps I underestimate the kindness of multi-million dollar corporations. One day, I'll do it, just for kicks (the worst that could possibly happen is that they'd crush me under their platinum boot-heels ;). You'll be the first to know the degree to which I'm ignored :)

In any event, since I use their products so often in my work, writing up how-to and tips-type posts regarding the use of them just makes sense. I think of myself as fairly creative (evidenced by the fact that I still exist, in spite of all the stupid, and hazardous, things I did in my youth ;), but every once in a while I have to defer some of the solid tech stuff to get it out of my system and give my noggin a break. By "solid tech stuff" I mean step-by-step walk-throughs of processes and practices, etc. Things that you can read in a manual that differ very little from what I've actually done. The facts (unlike the methods) can't be disputed. I'll admit that, for me, sometimes writing these kinds of posts is a bit mentally-boring but, if I started writing posts about all the goofy sh## I think about every day, this blog would quickly lose focus. I'd have to rename it "The Mongolian Cluster Fugg Menagerie" or something equally descriptive of what you could expect to not rely on reading every day ;) But, enough about my trivial problems. Life is generally good. My main gripe is that I have to work in order to be able to afford to feed my family. Crocodile tears ;)

This link will take you to a walk-through of the basic setup of the XSCF controller (Comparable to ALOM on some Sun systems, and the Service Controller on some others) on the new(ish) M4000 servers. Believe it or not, the hardest part was figuring out how to get started, even though I've worked on them, replacing system boards before. How embarrassing ;) These few pointers might be helpful to you (and, in the process, expose the possibly entertaining inner workings of a sleep-deprived mind ;)

1. Rather than a straight Ethernet connection, like on some of Sun's servers, the M4000 XSCF controller needs to be connected to with a serial cable (they include one with your purchase as a way of saying "Thank You" for spending 10's of thousands of dollars ;)

2. The correct port is not identified, typically, as a serial port. For ease of location, it's the second port (RJ45) in from the right, if you are looking at the server from the back.

3. Even though the XSCF has power running to it, you actually need to turn on the M4000 in order to do the initial setup through the M4000's serial connection to the XSCF (This one had me stumped for about a half an hour while I tried different cables and setups in HyperTerminal. There's just no substitute for reading the manuals that it takes forever to locate online ;) They didn't come with the physical product this time, so I just assumed a few things that ended up making my day go by much faster :)

4. For some reason, I couldn't get these basic manuals without a login to Sunsolve, although they're probably available on docs.sun.com somewhere. If you need to do any hardware work on M4000 or M5000 servers, I put up two essential guides (in PDF format) on one of my web hosting providers. These are worth their weight in paper ;)

The M4000/5000 Server Information Guide

The M4000/5000 Server Service Manual

Hope you can get some use out of those. My wife is obsessed with painting the kitchen - which is why I'm reasonably sure she won't ever read this - and I'm stuck with putting the kids to bed, which means an early night for me and more hallucinogenic dreams about Sponge Bob ;)

To leave you with another quick tip (if you need to install and get the Hell outta there ;), during our initial configuration, we intentionally opted not to set up the DSCP (Domain To Service Processor) protocol during our setup of the XSCF (Extended Control Facility). Once you have the basic networking set up, you can ssh in and set that up later. The DSCP is "important" because it's the protocol XSCF uses to communicate with your server (i.e. if it's not running, you can connect to your domain or console, but good luck getting it to manipulate your M4000 ;)

Hope you're having a peaceful evening, and that the official Sun XSCF Setup Documentation helps you some :)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Patching Your Solaris Server From A Network Mount

Hey again,

Today we're going to take a quick look at how to patch your Solaris server from the network (not version-specific, unless you're still using 2.4 in which case I don't remember how to help you, although I'm almost positive the answer is similar ;)

The first question you might be asking yourself is "Why in the world would I ever want, or even need, to do this?" Since I'm a somewhat-honest guy who writes from the hip, I'll tell you that, depending upon where you work and what kind of setup you have there, you may never ever need to do this. If (worst case) you can get a console connection to your server (which you'll need for this method, anyway) and have onsite staff that can pop a cd in a working drive, you probably wouldn't even want to do this. So, the simple answer is: Why not? If the unlikely situation arises (and, if you're reading this in the distant future, it just might have ;), you'll know how to do it. If you set yourself up correctly, it's just one more way to get around having to come into the office in the middle of the night :)

The first thing you'll want to do is to set up a boot server or a jumpstart server. Since that topic is fairly lengthy to go over, and we've already gone over it at length, please check out this old post on begin and finish script variable definitions for Solaris' jumpstart. It's actually the last part of a series of posts on Jumpstart, but, since it wasn't posted in backward chronological order, the last link (this one) connects back to all the previous posts. You can also get a feel for some of your extended options (on both the jumpstart server and the jumpstart client) in these posts on jumpstart booting.

The second thing to do would be to ensure that you have the patch bundle you need either on the local machine, on a partition that would normally get mounted in single user mode (if you can, put them in a subdirectory of / - but only if you have the space. /usr and /var "should" always be good candidates for placement, as well, but I've done this a couple times under conditions so crippling it took me months before I could walk upright again ;). Having your patches available when you get into single user mode (with no networking) is of vital importance when you want to patch your server. Did that sound redundant? Good; because it was ;)

Now, assuming you've prepped your Jumpstart server, and have it all set up to service your client (the machine we're going to patch), it's a simple matter to get things started on your end (We'll assume that you have either a console, ALOM or other such connection to your patch client server so that you won't get disconnected from it when it goes to PROM and can interact with it at any run level or phase). The following should suffice to get the whole shebang (not to be confused with shebang ;) started:

host # id
uid=0(root) gid=0(root)
host # init 0
ok> boot net -s

And we're off. Once your server has successfully booted into single user mode on your Jumpstart, or Boot, server (see above for links to more information regarding those details), you can begin going about your business and, hopefully, finishing well before the time you promised you'd be done.

First (or is it third?), after you've booted into single user mode (no networking) and verified that you can access your patches, be sure to stop any and all unnecessary services. Most of them should be gone, but a simple "ps -ef" and "df -k" to verify that no one snuck in an init script or mount at a run level you wouldn't normally suspect might save you some headache later, and it'll probably only take about 2 or 3 minutes at most, even if you have to "terminate" a process or two. Also be sure to mount any partitions that need to be mounted if, for some reason, they don't get mounted automatically. You should get errors, when you attempt to patch, that will indicate what you need to fix if something is wrong in this regard, but it's usually best just to have things ready and not take the chance that Sun forgot to put an error-check in a script somewhere!

And the rest (much like this post) is academic. The general procedure (assuming you've downloaded a recommended patch bundle from Sun and have it in the directory /patches (or something similar), would go something like this (although possibly slightly differently if you're running Solaris 10 with zones, which case you should check out that hyperlink a few words back:

host # cd /patches
host # ./install_cluster
... < wait and watch, or go away and come back - just make sure you see all the error messages. Most will probably be inconsequential if you're using a generic recommended patch cluster ("software that the patch patches isn't installed" or "greater revision of patch already installed" are technically errors, but can be safely ignored.
host # reboot -- -r

And, that should be that :) Remember, this is actually a much longer post, if you need to go back to the referenced posts and get details for all of the parts. I thought it would be nice to have everything in one place (or linked to one place) finally, with regards to this topic, so I wrote this patch-work wire-frame mockery of a sham ;)

Have fun patching and be sure to do it, at the very least, more often than the Cicadas hatch ;)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Solaris 10 - 5/08 Release: ZFS-Rooted Zones Getting Better!

Hey There,

Before anyone starts phoning in, I do realize this is not "brand new" :) It's just brand new to me and the place I work. Now that we're starting to pull in some of those Mx000 Series Boxes, we're finally up to date on Solaris 10! Plus, I'm sure it's patched to the gills ;)

Today's post is going to be almost like a press release, because the folks at Sun have released so much more information than I can process in a day that I felt it was best to let them figuratively speak for themselves ;) As you can tell by the headline today, Solaris 10 is finally starting to move in a few directions I've been hoping it would for a long long time!

Although there are a number of significant improvements in the OS, I think the home run on this release (5/08) is the ability to, at last, create zones that support zfs root filesystems without as many hassles and limitations as their previous releases! (For more whining about the headaches you may have become accustomed to already, and how to get around some of them, check out our older post on dealing with ZFS rooted zones on Solaris 10 ;) Strangely enough it's one of the things they tout the least. Another very interesting thing (for me, anyway ;) is that they've included the freeware 7-Zip utility that has long been a favorite of mine. It's, also, the last thing on the page. I'm starting to get the feeling Sun doesn't take me all that seriously...

Without further ado, check out the latest and greatest list of augmentations to Solaris 10. You can access the Official Sun 5/08 Release Notes Page if want to have easier access to past release notes and other relevant information.

Enjoy! I'm going to play around with this release a bit and see if I haven't been deluding myself ;)

Cheers,

---

Chapter 1 What's
New in the Solaris 10 5/08 Release

For a summary of features that were introduced in the Solaris 9, Solaris
8, or Solaris 7 releases, see What's New in the Solaris 9 Operating
Environment at http://docs.sun.com.

System Administration Enhancements

The following system administration features and enhancements have been
added to the Solaris 10 5/08 release.

Solaris Trusted Extensions Administrator Procedures

Starting with this release, the Solaris^TM Trusted
Extensions packages are installed when the Solaris OS is installed. The ExtraValue directory is no longer present. This directory previously
included the Solaris Trusted Extensions packages. The Solaris Trusted Extensions
functionality is managed by the service management facility (SMF) as the svc:/system/labeld:default service. This service must be enabled.
After the service is in the online state, reboot the system to activate Solaris
Trusted Extensions. Additional configuration is required after the reboot.
For more information, see Solaris
Trusted Extensions Configuration Guide.

The Solaris 10 5/08 release also includes the following features:

• 
  

  The domain of interpretation (DOI) is configurable. For more
  information, see Network Security Attributes in Trusted Extensions in Solaris Trusted Extensions Administrator’s Procedures.

  
  
  
  


• 
  

  The NFSv3 protocol supports multilevel mounts. For more information,
  see Trusted Extensions Software and NFS Protocol Versions in Solaris Trusted Extensions Administrator’s Procedures.

  
  
  
  


• 
  

  The name service cache daemon, nscd, can
  be separately configured per labeled zone. This configuration supports environments
  where each zone is connected to a subnetwork that runs at the label of the
  zone, and the subnetwork has its own name server for that label.

  
  
  
  

For more information about Solaris Trusted Extensions, see Solaris Trusted Extensions
Administrator’s Procedures.

Flash Update Tool

fwflash(1M) is a new Solaris command for the manipulation
of firmware for PCI-X, and PCI-Express HBA and HCA cards. Currently, the command
enables listing, reading, and writing the firmware for the InfiniBand HCA
cards.

For more information about this command, see the fwflash(1M) man page.

PPD File Management Utility

The PostScript^TM Printer Description (PPD) file
management utility, /usr/sbin/ppdmgr, manages PPD files
that are used with the Solaris print subsystem.

By using the ppdmgr utility, you can perform the
following tasks:

• 
  

  Add a PPD file to a PPD file repository on a system

  
  
  
  


• 
  

  Supply a label to group PPD files within a PPD file repository

  
  
  
  


• 
  

  Update the cache of the PPD file information that is used
  by the Solaris Print Manager (printmgr) GUI to display
  supported printer information

  
  
  
  

You can add a new PPD file by using the ppdmgr utility
or by using the lpadmin -n command. When
you add a new PPD file, you automatically update the cache of the PPD file
information that the printmgr GUI uses to display supported
printer information.

---

Note –

The delivery location of PPD files in the Solaris OS has changed.
During a software upgrade, any print servers with print queues that were defined
by using PPD files from the previous PPD file delivery location are automatically
updated to reflect the new PPD file delivery location.

---

In addition, a new SMF service, print/ppd-cache-update, has been introduced.
The print/ppd-cache-update service is enabled by default. This service runs
one time during system reboot to update the printer cache information with
changes from all the PPD file repositories on the system. The service might
take longer to transition to an online state during a system reboot after
a software installation or upgrade. Also, if any changes were made to the
PPD file repositories since the last PPD cache update, during system reboot,
the service might take longer to come online. Changes made to the PPD file
repositories on a system are not reflected in the PPD cache used by Solaris
Print Manager until the print/ppd-cache-update service is online.

For more information, see the following:

• 
  

  
  ppdmgr(1M) man
  page

  
  
  
  


• 
  

  
  Chapter
  9, Administering Printers by Using the PPD File
  Management Utility (Tasks), in System
  Administration Guide: Solaris Printing
  

  
  
  
  

Internet Printing Protocol Client-Side Support

Client-side support for the Internet Printing Protocol (IPP) enables
Solaris client systems to communicate with IPP-based print services, such
as those on the Linux and Mac OS X operating systems, as well as other platforms.

Small improvements are also featured in the server-side support for
the IPP listening service. These improvements promote better interoperability,
including some minor changes that result in a more standard representation
of printer and job attribute data.

The IPP server and client implementation in the Solaris OS is one of
several OpenSolaris^TM printing projects that are currently
under development. OpenSolaris printing provides a set of specifications and
implementations of software that enables you to create standardized, scalable
printing components for the Solaris and Linux software, or any operating system
that contains a set of POSIX interfaces.

For more information, see the System Administration Guide: Solaris Printing.

For more information about OpenSolaris Printing, see http://opensolaris.org/os/community/printing/.

Selectable Use of localhost for
Solaris Print Server Database Hostname

This printing feature enables the Solaris print system to recognize
and use localhost as the local host in the print system
databases. In prior releases, /bin/hostname was used
solely to generate the print hostname. The print system depended on this name
remaining constant. The ability to use localhost as the
name of the current system enables print servers to maintain the same print
hostname, independent of the system's host name.

---

Note –

The modification applies to the setup of local print queues exclusively.

---

To support this feature, the following modifications are effective for
the lpadmin command and the Solaris Print Manager graphical
user interface (GUI):

• 
  

  The lpadmin command uses the -s option
  when creating a local print queue.

  
  
  

  To use localhost as
  the host name that is specified within the print server, set the print hostname
  to localhost, as shown:

  
  
  
  
  
  
  

  # lpadmin -p <new-print-queue> -s localhost -v <device>

  
  

  For example:

  
  
  
  
  
  
  

  # lpadmin -p foo -s localhost -v /dev/term/a

  
  

  ---

  
  Note –
  

  The default behavior of the lpadmin command
  has not changed.

  
  
  

  ---

  
  
  
  


• 
  

  Solaris Print Manager now includes an added tool attribute
  check box, Use localhost for Printer Server. The localhost attribute is selected by default. To deselect the localhost attribute,
  uncheck the box. Unchecking the box selects the previously chosen behavior
  for this attribute.

  
  
  
  

For more information, see the following:

• 
  

  
  printmgr(1M) man
  page

  
  
  
  


• 
  

  
  lpadmin(1M) man
  page

  
  
  
  


• 
  

  
  System
  Administration Guide: Solaris Printing
  

  
  
  
  

Fault Management for T5140/T5240 Platforms

The Solaris predictive self-healing technology is available on Sun SPARC
Enterprise T5140 and T5240 platforms. Predictive self-healing features include
the following:

• 
  

  Automated error handling

  
  
  
  


• 
  

  Automated diagnosis

  
  
  
  


• 
  

  Automated recovery for CPU, memory and I/O subsystems

  
  
  
  


• 
  

  Clear and concise error messages

  
  
  
  

For more information, see http://www.sun.com/software/solaris/ds/self_healing.jsp and http://opensolaris.org/os/community/fm.

SunVTS 7.0

SunVTS^TM is a comprehensive system validation and
test suite designed to support Sun hardware platforms and peripherals. SunVTS
7.0 is the next generation of SunVTS 6.0 and its compatible versions.

SunVTS 7.0 includes the following features:

• 
  

  Introduction of the concept of purpose-based testing

  
  
  
  


• 
  

  Improved diagnostics effectiveness

  
  
  
  


• 
  

  Web-based user interface

  
  
  
  


• 
  

  Simplified usage

  
  
  
  


• 
  

  New architecture framework

  
  
  
  


• 
  

  Enterprise View

  
  
  
  

SunVTS 7.0 follows a conventional three-tier architecture model. This
model is composed of a browser-based user interface, a Java based middle server,
and a diagnostic agent.

System Resource Enhancements

The following system resource features and enhancements have been added
to the Solaris 10 5/08 release.

CPU Caps

CPU caps provide absolute fine-grained limits on the amount of CPU resources
that can be consumed by a project or a zone. CPU caps are provided as a zonecfg resource, and as project and zone-wide resource controls.

• 
  

  The zonecfg capped-cpu resource provides
  an absolute limit on the amount of CPU that can be consumed by a project or
  a zone.

  
  
  
  


• 
  

  The following resource controls are available:

  
  
  
  

  
  

  zone.cpu-cap

  
  

  
  

  Absolute limit on the amount of CPU resources that can be
  consumed by a non-global zone.

  
  
  

  
  

  project.cpu-cap

  
  

  
  

  Absolute limit on the amount of CPU resources that can be
  consumed by a project.

  
  
  

  
  

  
  
  
  

For more information, see the following:

• 
  

  
  zonecfg(1M) man
  page

  
  
  
  


• 
  

  
  zones(5) man
  page

  
  
  
  


• 
  

  
  System
  Administration Guide: Solaris Containers-Resource Management and Solaris Zones
  

  
  
  
  

projmod(1M) Option

Use the projmod command with the -A option
to apply the resource control values defined in the project database to the
active project. Existing values that do not match the values defined in the
project file, such as values set manually by prctl(1),
are removed.

Device Management Enhancements

The following device management features and enhancements have been
added to the Solaris 10 5/08 release.

Tape Self-Identification

The tape self-identification feature configures the tape automatically,
with the parameters provided by the tape drive. Previously, the configuration
data for a tape drive was statically supplied through user-editable configuration
files, built-in configuration tables, or default values. The tape-self identification
feature uses a few SCSI commands to directly query the required parameters
from the tape drive. When the st driver gets the parameters,
the tape drive uses them on the Solaris OS.

The advantages of tape-self identification over the traditional file-based
configuration are:

• 
  

  Simple and no user intervention is needed

  
  
  
  


• 
  

  Faster support for new tape drives

  
  
  
  


• 
  

  Easy to use, standard-based interface

  
  
  
  

x86: Enhanced Speedstep CPU Power Management

Starting with this release, Intel's Enhanced Speedstep^TM technology
is supported on the Solaris OS. Enhanced Speedstep support enables Solaris
platform users to manage the power consumption of their Intel processors by
lowering the processor frequency during idle periods.

For more information about how to enable Solaris CPU power management,
see the power.conf(4) man
page.

x86: PowerNow! CPU Performance Management

Starting with this release, AMD's PowerNow! technology is supported
on the Solaris OS. PowerNow! support enables Solaris platform users to manage
the power consumption of their Opteron 10h family of processors by adjusting
the processor operating frequency and voltage according to the task being
performed.

For more information about how to enable Solaris CPU power management,
see the power.conf(4) man
page.

iSNS Support in the Solaris iSCSI Target

This Solaris release provides support for the Internet Storage Name
Service (iSNS) protocol in the Solaris iSCSI target software.
The iSNS protocol enables automated discovery, management, and configuration
of iSCSI devices on a TCP/IP network.

The Solaris iSCSI target software does not include native iSNS server
support. However, in this Solaris 10 release, you can add access to an existing
iSNS server to automatically discover the iSCSI devices in your network.

The iscsitadm command is used to configure the Solaris
iSCSI target to discover the iSNS server and enable or disable the iSNS discovery.
Use the hostname or the IP address to specify the iSNS server.

For more information, see the iscsitadm(1M) man page and Chapter 14, Configuring
Solaris iSCSI Targets and Initiators (Tasks), in System Administration Guide: Devices and File Systems.

Security Enhancements

The following security features and enhancements have been added to
the Solaris 10 5/08 release.

Solaris Trusted Extensions Supports Mounting Labeled
File Systems With the NFSv3 Protocol

Starting with this release, the Solaris Trusted Extensions software
can mount labeled file systems by using NFS Version 3 (NFSv3) in addition
to NFS Version 4 (NFSv4). Solaris Trusted Extensions has no restrictions on
using TCP as an underlying transport protocol for NFS. However, users cannot
choose User Datagram Protocol (UDP) as the underlying protocol for read-down
NFS access for NFSv3. The use of UDP for the initial mount operation is supported,
but UDP is not supported for subsequent multilevel NFSv3 operations.

SPARC: Hardware -Accelerated Elliptical Curve
Cryptography (ECC) Support

The UltraSPARC T2 (Niagara 2) based platforms support hardware acceleration
of Elliptical Curve Cryptography (ECC) algorithms. The Solaris OS now supports
high performance ECDSA and ECDH on these platforms. These new ECC algorithms
are accessible to all users of the Solaris Cryptographic Framework including
Java technology and OpenSSL users.

Networking Enhancements

The following networking features and enhancements have been added to
the Solaris 10 5/08 release.

Sockets Direct Protocol

The Sockets Direct Protocol (SDP) is a transport protocol layered over
the Infiniband Transport Framework (IBTF). SDP is a standard implementation
based on Annex 4 of the Infiniband Architecture Specification Vol1. SDP provides
reliable byte-stream, flow controlled two-way data transmission that is very
similar to TCP.

For more information see sdp(7D) man
page.

inetd Backlog Queue Size

Starting with this release, a tunable to set the backlog queue size
of the inetd managed services is introduced. This feature
adds an SMF property to inetd called connection_backlog that enables the queue size to be modified. The default value of
the connection_backlog queue size is 10. You can modify
the connection_backlog property by using the inetadm command.
For example:

• 
  

  To list the properties, type:

  
  
  
  
  
  
  

  #inetadm -l fmri/pattern

  
  
  


• 
  

  To change the value for a specific service, type:

  
  
  
  
  
  
  

  #inetadm -m fmri/pattern conection_backlog=new value

  
  
  


• 
  

  To change the value globally, type:

  
  
  
  
  
  
  

  #inetadm -M connection_backlog=newvalue

  
  
  

For more information, see the inetadm(1M) man page.

X11 Windowing Enhancements

The following X11 windowing features and enhancements have been added
to the Solaris 10 5/08 release.

Xvnc Server and Vncviewer Client

VNC provides a remote desktop session over the Remote Frame Buffer (RFB)
protocol. RFB clients, better known as VNC viewers, are available for most
platforms, in both open-source and commercial releases.

The Solaris 10 5/08 release now includes Xvnc. Xvnc is an X server that
is based on the open-source releases from the RealVNC project and X.Org Foundation.
Xvnc is displayed to an RFB protocol client over the network without requiring
an existing X server session display on the local video hardware. This release
also includes RealVNC's vncviewer RFB client to connect to remote VNC servers,
and several associated programs for managing these servers.

For more information, see System Administration
Guide: Virtualization Using the Solaris Operating System. See
also the Xvnc(1) and vncviewer(1) man
pages.

Desktop Tools Enhancements

The following desktop tools features and enhancements have been added
to the Solaris 10 5/08 release.

StarOffice 8

Starting with this release, StarOffice has been enhanced to the latest
version, StarOffice 8.

For more information about StarOffice, see http://www.sun.com/software/star/staroffice/whats_new.jsp.

Flash Player 9

Stating with this release, the Solaris OS includes the Adobe Flash Player
9. For more information about this Flash Player, see http://www.adobe.com/products/flashplayer/productinfo/features/.

Pidgin 2.0

Pidgin is a popular open-source instant messaging client. Pidgin 2.0
includes the following features:

• 
  

  Many improvements to the UI modules including status system,
  Buddy List, Conversation, and the chat window

  
  
  
  


• 
  

  New Yahoo features including Stealth Settings, Doodle, and
  the /list command

  
  
  
  


• 
  

  Improved AIM and ICQ file transfers

  
  
  
  


• 
  

  Improved Log Viewer module

  
  
  
  


• 
  

  Support for the new version of ICQ file transfer

  
  
  
  


• 
  

  New IRC features including SSL support, and the new commands /whowas, /nickserv, /memoserv, /chanserv, and /operserv
  

  
  
  
  


• 
  

  Jabber features including support for SRV lookups, buddy icons,
  and Jabber User Directory searching

  
  
  
  

PAPI Print Commands

The Free Standards Group (FSG) Open Printing API (PAPI) commands replace
several commonly used print commands, which include the following:

• 
  

  
  cancel(1)
  

  
  
  
  


• 
  

  
  disable(1)
  

  
  
  
  


• 
  

  
  enable(1)
  

  
  
  
  


• 
  

  
  lp(1)
  

  
  
  
  


• 
  

  
  lpstat(1)
  

  
  
  
  


• 
  

  
  lpc(1B)
  

  
  
  
  


• 
  

  
  lpq(1B)
  

  
  
  
  


• 
  

  
  lpr(1B)
  

  
  
  
  


• 
  

  
  lprm(1B)
  

  
  
  
  


• 
  

  
  accept(1M)
  

  
  
  
  


• 
  

  
  lpmove(1M)
  

  
  
  
  


• 
  

  
  reject(1M)
  

  
  
  
  

The implementations of the Open Printing API commands are layered on
top of the Free Standards Group Open Printing API in the Solaris OS. This
implementation enables the commands to run on top of multiple protocols or
services.

Some advantages of the new print command implementations include the
following:

• 
  

  Improved consistency between desktop applications and command-line
  interfaces

  
  
  
  


• 
  

  Multiple print protocols and service support from the command
  line

  
  
  
  


• 
  

  Internet Print Protocol (IPP) client-side support for improved
  interoperability with Linux, Mac OS X, and other IPP-based print services

  
  
  
  


• 
  

  Enhanced remote capability and data when using IPP between
  print client and server

  
  
  
  


• 
  

  The capability to disable network services and retain access
  to local printers

  
  
  
  

For more information about the PAPI print commands, see the following:

• 
  

  
  PAPI Implementation in the Solaris OS (Reference) in System Administration Guide: Solaris Printing
  

  
  
  
  


• 
  

  OpenSolaris Printing Community web pages at http://opensolaris.org/os/community/printing/projects/papi_client_commands/
  

  
  
  
  

System Performance Enhancements

The following system performance features and enhancements have been
added to the Solaris 10 5/08 release.

64-bit SPARC: Memory Placement Optimization
Support for sun4v Platforms

Memory Placement Optimization (MPO) enables operating systems to allocate
memory local to the core where the threads or processes are being executed.
The sun4v architecture runs on virtualized hardware environment. The MPO for
sun4v platforms feature provides the required standard accessors in the sun4v
layer to provide locality information for the generic MPO framework. This
feature is effective on platforms that have multiple sockets with differences
in memory access latency. The MPO feature enhances the performance of various
applications by enabling the OS to allocate memory local to the nodes.

SPARC: Shared Contexts Support

The context mechanism, which is used by the Memory Management Unit (MMU)
hardware to distinguish between the use of the same virtual address in different
process address spaces, introduces some inefficiencies when shared memory
is used. The inefficiencies in shared memory are because the data at a particular
shared memory and the address in different processes might really be identical,
but the context number associated with each process is different. Therefore,
the MMU hardware cannot recognize a match. This inability to recognize a match
results in mappings being unnecessarily evicted from the MMU translation cache
and the Translation Lookaside Buffer (TLB), only to be replaced by identical
mappings with a different context number.

The Niagara 2 system has an additional shared context, which is a hardware
feature that can be used to prevent the inefficiency in handling shared memory.
Searching the TLB for mapping a match on either the private or the shared
context results in a TLB hit. The current software support for shared context
activates the feature for processes that use the Dynamic Intimate Shared Memory
(DISM). In this case, the process text segment and DISM segments mapped at
the same virtual address with the same permissions for each process use the
shared context.

x86: CPUID-Based Cache Hierarchy Awareness

Modern Intel processors provide an interface for discovering information
about the cache hierarchy of the processor through the CPUID instruction.

Language Support Enhancements

The following language support features and enhancements have been added
to the Solaris 10 5/08 release.

Locale Creator

Locale Creator is a command line and graphical user interface tool that
enables users to create and install Solaris locales. Using locale creator
users can create installable Solaris packages containing customized locale
data of a specific locale. After the created package has been installed, the
user has a fully working locale on the system.

For more information, see the following:

• 
  

  The command /usr/bin/localectr -h
  

  
  
  
  


• 
  

  
  localectr man page

  
  
  
  


• 
  

  
  http://developers.sun.com/global/products_platforms/solaris/reference/techart/locale-creator.html
  

  
  
  
  

libchewing 0.3.0

Chewing input method (IM) is based on libchewing, which is an open-source
library for Traditional Chinese input. libchewing has been upgraded to the
libchewing 0.3.0 version. Some of the features of the new version include
the following:

• 
  

  Incompatibility with API/ABI.

  
  
  
  


• 
  

  UTF-8 based language engine core for common Unicode environment.

  
  
  
  


• 
  

  Includes the libchewing-data subproject.

  
  
  
  


• 
  

  Zuin fixes and symbol improvements.

  
  
  
  


• 
  

  New binary form of user hash data to speed up loading and
  solving hash data corruption.

  
  
  
  


• 
  

  Improved calculation of internal tree and phone constants.

  
  
  
  


• 
  

  Revised tsi.src for richer phrases and avoiding crashes.

  
  
  
  


• 
  

  Merge phone and phrase from CNS11643.

  
  
  
  


• 
  

  Improved Han-Yu PinYin to use table-lookup implementation.

  
  
  
  


• 
  

  Experimental frequency evaluation that re-computes chewing
  lifetime.

  
  
  
  


• 
  

  Implementation of the choice mechanism for symbol pairs.

  
  
  
  


• 
  

  Experimental, memory mapping-based, binary data handling to
  speed up data loading.

  
  
  
  

For further information, see the International
Language Environments Guide.

File Encoding Examiner

The File Encoding Examiner (fsexam) enables you to convert the name
of a file, or the contents of a plain-text file, from a legacy character encoding
to UTF-8 encoding. New features in the fsexam utility include the following:

• 
  

  Encoding list customization

  
  
  
  


• 
  

  Encoding auto-detection

  
  
  
  


• 
  

  Support for dry runs, logs, batch conversion, file filtering,
  symbolic files, command line, and special file types like compress file

  
  
  
  

For more information, see the fsexam(1) and fsexam(4) man pages.

Kernel Functions Enhancements

The following kernel functions features and enhancements have been added
to theSolaris 10 5/08 release.

x86: MONITOR and MWAIT CPU Idle Loop

The Solaris OS uses the SSE3 MONITOR and MWAIT instructions in the x86
processor idle loop. Using the SSE3 instructions in the processor idle loop
eliminates the overhead of sending and receiving an interrupt to wake up a
halted processor. MONITOR is used to specify a memory range to monitor the
idle loop. MWAIT halts the processor until the address previously specified
with MONITOR is accessed. With the new idle loop, a processor has to write
to memory only to wake up a halted processor.

Driver Enhancements

The following driver features and enhancements have been added to the
Solaris 10 5/08 release.

x86: Support Sun Fire X4540 Disk Status Indicators

Starting with this release, the Sun Fire X4540 disk status indicators
are supported. The amber Fault status LED and blue Ready to Remove status
LEDs are enabled by this feature.

For more information, see the Sun Fire X4540
Server Diagnostics Guide.

MPxIO Extension for Serial Attached SCSI Devices
on mpt(7D)

The mpt driver has been enhanced to support MPxIO
with supported storage devices. When MPxIO is enabled for Serial Attached
SCSI (SAS) and SATA devices, they are enumerated under scsi_vhci(7D)
just like fibre channel devices under fp(7D).

Starting with this release, stmsboot(1M) has also
been enhanced to support multipathed SAS devices. stmsboot(1D)
operates on all attached and multipath-capable controllers by default.

If you wish to only enable multipathing on fp or mpt controllers then you can use the new flag which has been added
to restrict operations. The command, /usr/sbin/stmsboot -D mpt -e, will enable MPxIO only on attached mpt controllers.
Replacing mpt with fp in this command
will make stmsboot enable MPxIO only on attached fp controllers.

x86: SATA ATAPI Support in AHCI Driver

The AHCI driver supports SATA ATAPI CD or DVD devices. Users can use
the SATA CD or DVD in AHCI mode instead of the compatible mode. The AHCI mode
has better error handling and hot-pluggable capabilities.

For more information, see the ahci(7D) man page.

x86: AMD–8111

The AMD-8111 HyperTransport I/O hub includes a 10/100 Mbps Ethernet
LAN controller. The driver is used by the Andretti platform.

SATA NCQ Support in AHCI Driver

The AHCI driver supports the SATA NCQ feature. NCQ support improves
performance of the driver.

For more information, see the ahci(7D) man page.

x86: bnx II Ethernet Driver

Starting with this release, support is provided for the Broadcom NetXtreme
(bnx) II Ethernet chipset, which includes BRCM5706C, BRCM5706S, BRCM5708C,
and BRCM5708S.

For more information, see the bnx(7D) man page.

USB-to-Serial Driver for Keyspan Adapters

Starting with this release, a new driver is provided for Keyspan USB-to-serial
adapters. This driver supports the USA-19HS model. This feature enables you
to choose between Edgeport adapters and Keyspan adapters.

For further information, see the usbsksp(7D) man page.

Freeware Enhancements

The following freeware features and enhancements have been added to
the Solaris 10 5/08 release.

32-bit: pgAdmin III

pgAdmin III is a popular and feature-rich, open-source administration
and development platform for PostgreSQL. The graphical interface supports
all PostgreSQL features and makes administration easy. This tool enables users
to write simple SQL queries and also to develop complex databases.

For more information, see http://www.pgadmin.org/.

p7zip

Starting with this release, the Solaris OS includes p7zip port. p7zip
is similar to the Windows compression and archiving utility, 7zip.

For more information, see http://p7zip.sourceforge.net/.

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Making Solaris 10 Zones Recognize Veritas Raw Devices

Hey there,

Here's something I learned today that I never knew before! ...Actually, when you think about it, everything you ever learn is something you never knew before. Otherwise, you'd already know it, so there'd be no learning involved... Where am I? ;)

Today's short-post is a little trick concerning Solaris 10 and the Veritas File System/Volume Manager. I've been using Veritas with Solaris 10 for quite a while, so this was pretty interesting to find out. In the usual case, I could always set up Solaris zones and hand them Veritas File System partitions with no incident. Usually, something like this:

host # zonecfg -z myNewZone
... <-- Here we skip past the create and "set zonepath" type stuff.  We have more information on dealing with Solaris zones in this old post
zonecfg:myNewZone> add fs
zonecfg:myNewZone:fs> set dir=/my/directory
zonecfg:myNewZone:fs> set special=/myNewZone/my/directory
zonecfg:myNewZone:fs> set type=lofs
zonecfg:myNewZone:fs> end
zonecfg:myNewZone> commit
zonecfg:myNewZone> exit

and life was beautiful ;)

Out of sheer luck (or horrible misfortune), I've always ended up at places that (while they may make heavy use of Veritas Volume Manager, File System, Cluster Server, etc) either went with some combination of SunCluster, Sun Solaris, HP and Oracle or Informix. Now, there's nothing wrong with any of the possible combinations you could end up with here. In fact, there's - more exactly - nothing wrong, since all of them (well, not HP-UX) can work with Solaris 10 zones using raw devices.

If you're not familiar with basic disk access concepts in Unix, at a very basic level, disk in Unix is generally accessible via two standard gateways: Block devices or Raw/Character devices. Most of the time, you probably deal with the block device interface, as this allows buffered sector reads of the device (generally a hard drive/disk) and is generally faster for most operations. To demonstrate what I mean, if you wanted to read a few bytes from HardDrive1, you could read those few bytes from your block device (almost to the byte) , but you'd have to read the entire device in order to get those few bytes when accessing the information via the raw device interface.

Raw devices do have their benefits, of course, or they probably wouldn't be around any more. Like their name suggests, they allow direct (raw) access to the disk. This can make it possible for you to recover information if your disk becomes corrupted (for instance) but is mostly used by software that likes to manage disk on its own and not have to rely on the Operating System. Most database software uses disk in this manner. Oracle, for instance, creates its own "file system" and (although it will work on UFS or any other filesystem) they say it works a lot more efficiently when it can be allocated raw disk and allowed to manage it on its own. It's probably true to some degree. Does anyone really know? ;)

Anyway (back from that two-paragraph aside ;), what I learned today is that Solaris 10 Zones can't (or won't) deal with raw Veritas devices (WT_?) I also found out that there's a way to get around that issue (hence, the post - I still owe you that one that goes on and on forever and leads nowhere ;).

You can get around this deficiency by doing the following (assuming you've already taken care of the basics of setting up your Veritas Volumes and Filesystem) and have created your zone with a base filesystem, like above, and want to add a raw device.

1. Check out your raw device file in the appropriate directory:

host # ls -l /dev/vx/rdsk/myRawDisk
crw------- 1 root root 289, 45000 Aug 24 11:13 myRawDisk

and make note of the Major and Minor numbers of the device (289 and 45000 respectively, above). You'll need these to feed the mknod command you're going to hammer out next (we'll assume you set your zonepath equal to /myNewZone - oh, yeah, and it's also important that you're not in your "Zone" when you do this):

host # cd /myNewZone/dev
host # mknod myRawDisk c 289 45000

2. And (it seems too simple!!! ;) then you just need to (well... you should ;) log into your zone and check it out, with a simple "dd" test or something:

host # zlogin -l root myNewZone
...
zone # ls -l /dev/myRawDisk
crw------- 1 root root 289, 45000 Aug 24 11:13 /dev/myRawDisk
zone # dd if=/dev/myRawDisk of=/dev/null
4096+0 records in
4096+0 records out

And, there you go. That problem you never knew you had is solved! ;)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---