Preconfiguring Containers with sysidcfg

You can preconfigure a Solaris Zone by placing a valid sysidcfg file into /etc/sysidcfg in the zone, so it finds all the information when it boots.

What's also true, at least for native zones on Solaris 10, is that you can specify a cut-down sysidcfg file. For example:

network_interface=PRIMARY {
        hostname=mars
}
system_locale=C
timezone=US/Pacific
name_service=NIS {
        domain_name=foo.com
        name_server=bar.foo.com(192.168.1.1)
}
security_policy=NONE
terminal=xterm
root_password=0123456789abcd
nfs4_domain=foo.com

If you try doing this on a Solaris 8 Container, it will go interactive. So you need to supply a bit more information. Such as:

network_interface=PRIMARY {
        hostname=mars
        netmask=255.255.255.0
        protocol_ipv6=no
}
system_locale=C
timezone=US/Pacific
name_service=NIS {
        domain_name=foo.com
        name_server=bar.foo.com(192.168.1.1)
}
timeserver=localhost
security_policy=NONE
terminal=xterm
root_password=0123456789abcd

where I've added the netmask and protocol_ipv6 settings to the network_interface section, and told it a timeserver. Clearly the Solaris 10 zone can work these out for itself, but a Solaris 8 branded zone needs to be told explicitly. (Also, it doesn't need the nfs4_domain, as that makes no sense for a Solaris 8 system.)

Compressing Backup Catalogs

Backup solutions such as NetBackup keep a catalog so that you can find a file that you need to get back. Clearly, with a fair amount of data being backed up, the catalog can become very large. I'm just sizing a replacement backup system, and catalog size (and the storage for it) is a significant part of the problem.

One way that NetBackup deals with this is to compress old catalogs. On my Solaris server it seems to use the old compress command, which gives you about 3-fold compression by the looks of it: 3.7G goes to 1.2G, for example.

However, there's a problem: in order to read an old catalog (in order to find something from an old backup) it has to be uncompressed. There's quite a delay while this happens, and even worse, you need disk space to handle the uncompressed catalog.

Playing about the other day, I wondered about using filesystem compression rather than application compression, with ZFS in mind. So, for that 3.7G sample:

Compression	Size
Application	1.2G
ZFS default	1.4G
ZFS gzip-1	920M
ZFS gzip-9	939M

Even with the ZFS default, we're doing almost as well. With gzip, we do much better. (And it's odd that gzip-9 does worse than gzip-1.)

However, even though the default level of compression doesn't compress the data quite as well as the application does, it's still much better to use ZFS to do the compression, as then you can compress all the data: if you leave it to the application then you always leave the recent data uncompressed for easy access, and only compress the old stuff. So assume a catalog twice the size above, and that we used NetBackup to compress half the catalog, then the disk used in the application case would be 3.7G uncompressed and 1.2G compressed. The total disk usage comes out as:

Compression	Size
Application	4.9G
ZFS default	2.8G
ZFS gzip-1	1.8G
ZFS gzip-9	1.8G

The conclusion is pretty clear: forget about getting NetBackup to compress its catalog, and get ZFS (or any other compressing filesystem) to do the job instead.

JKstat 0.33

There are a number of features that have been suggested for JKstat that I've been thinking of including, and I've just added one of the more interesting ones.

I think it was Phil Harman suggested this at LOSUG. Someone may have archived kstat -p output, so why not allow JKstat to read that?

So, as of version 0.33, JKstat can do exactly that. You can either save kstat -p output into files in a directory, or simply put those files into a zipfile. (The reader is pretty dumb right now - no other files or subdirectories.) It uses the timestamps on the files as the time the measurement was take,

The browser can handle the input, but needs a bit more work to be useful - it currently steps through the data in real time, which isn't ideal for what could be days of data sampled at multi-minute intervals. Ideally it would be able to step through the data, pause, and rewind. Next release, perhaps.

The chart and areachart subcommands can read in data and display a chart. For example, the cpu behaviour of my home desktop yesterday evening, from kstat -p output saved every 5 minutes, could be shown with:

./jkstat areachart -z /var/adm/ka/ka-2009-12-03.zip \
cpu_stat:: user kernel idle

which looks like:


(Yes, there's an anomaly on the first datapoint.)

This is a preliminary implementation, so there are plenty of rough edges in need of a bit of polish, but it proves that the idea of reading archival kstat data is viable.

Is package management interesting?

My desktop workstation running Solaris 10 has almost 1600 packages installed. Many of the development systems I use have something close to 1000 packages installed. My Ubuntu (8.04, to be exact) desktop install fresh off the CD has just over 1100.

Given 1600 packages, can a sysadmin manage that, or even concisely describe what is installed and what its function is? I suspect not. It's actually so bad that I suspect most of us don't even bother.

Tools don't really help here. If anything, by giving the illusion of ease of use, they encourage the growth in the number of packages, making the underlying problem worse.

Really, though, is managing packages interesting? I submit that it's not, and that looking at the problem as one of managing packages is completely the wrong question.

Instead, we should be managing applications at a higher level of abstraction. Rather than managing the 250 packages that comprise Gnome, we need to collapse that into a single item, which we can then open up into manageable chunks. A package may be the right level of granularity for a packaging system, but it's the wrong level of granularity for an administrator.

We should be thinking of applications and function, not the detail of how packages deliver that functionality. I want to be able to go to a system and ask "What do you do?" and have it come back and say "I'm a web proxy server and mail relay"; I don't want to sift through 500 packages and try to work out which of them are relevant. If I want to set up a wiki for collaborative document editing that authenticates against my Active Directory infrastructure, then I want to phrase the requirement in those terms rather than try to work out the list of components that I need for that task.

From this, the packaging details become uninteresting. What a package contains, the packaging software, package names - are less important because that's just internal implementation detail.

The old Solaris installer had some of this - it defined clusters and metaclusters. The implementation doesn't really help much - the definition of the contents of clusters and metaclusters was poor, and there was no support for the clusters once you were managing an already installed system. Also, what you really want is a system that allows for clusters to be structured hierarchically (so you could take something like Gnome, and either manage it as a single unit, or have the option of dealing with subunits like games or libraries), and to overlap (for example, you could imagine that the apache web server would be in a whole lot of clusters).

One might be tempted to construct packages that use dependency information to bring in the packages they need. This approach is flawed: it doesn't cleanly separate groups from packages; it doesn't allow you to omit subgroups; and it makes removal of a group excessively difficult. Software clusters need to be cleanly layered above packages in order to allow each layer to best meet its own requirements.

Beyond simply delivering files (via packages) a cluster could also contain the details of how to actually take the various bits and pieces and put them together into a functioning system. In fact, the whole area of application configuration is one desperately in need of more attention.

A quick summary, then: package management shouldn't be interesting, and we need to move forward to managing applications and configuration.

Not so lucky any more?

The Google home page has seen some changes of late. One of these is the removal of the "I'm feeling lucky" button.

One of the things I've noticed over the past few months is that searching online has become dramatically worse. Google is increasingly failing to find useful results, and when it does find something it will rather present you with multiple instances of the same thing (the same news article syndicated to different sources, for example) rather than the more useful list of independent answers. Commonly I end up going to subsequent search pages, and often don't get to anything useful at all.

Is Google losing its touch? Has dumb search had its day? Perhaps the "feeling lucky" option was removed because it almost never works any more.

So what is wrong with SVR4 packaging, really?

So, as might be predicted I suppose, some people wilfully disregarded the thrust of my argument, and turned it into a debate over specific packaging technologies.

OK, so that brings us to the question: what is so bad about SVR4 packaging, really?

I could go on for pages. One of the reasons I found OpenSolaris attractive was the prospect of being able to fix all the bad things with Installation and Packaging in Solaris. Let's takes some of the comments though:

old and clunky

Guilty as charged. Really, it is old. It is clunky. It's been neglected and unloved. It needs fixing. Those reasons alone aren't enough to dismiss it - the key question should be whether it can actually do the job.

missing lots of features

OK, so what features does dpkg have that SVR4 packaging doesn't? That's really the comparison - versus the dpkg or rpm commands.

enabler of dim-sum patching

Completely and utterly false. The problem with Solaris patching lies fairly and squarely in the domain of patching. This could trivially be solved without any changes to tools - either deliver whole packages, or simply institute a policy saying that you can't deliver changes to a package (or related set of packages) in independent patches. This is a process problem, not something inherent to the underlying package system.

---

Then there are more material objections:

no repository support

Actually, SVR4 packaging does have the ability to fetch and install packages from remote locations. (A crippling limitation of IPS is that it can't do anything else.) What's wrong with this picture is the lack of repositories - blastwave aside. Wouldn't it have been easier to simply make existing packages available on a web site, without having to retool everything?

lack of dependency resolution

As the success of dpkg/apt demonstrates, having your underlying packager do all the work is neither necessary nor desirable. What that does demonstrate is the requirement for more powerful tools above the base packager. Actually, separating the fancy interface from the tools doing the low-level work is probably a really good thing - it enables compatibility of the system over time even if the higher-level tools change, and it enables innovation by allowing independent components to be developed independently.

arbitrary scripting

Actually, one of the key weaknesses of SVR4 packaging is not that it supports scripting, but that the support it offers is pretty poor. there is no real support - there ought to be a strong scripting framework with a well-defined environment, and predefined functionality for common tasks. Oh, and trigger scripts would be nice. Banning scripting (yet allowing it to sneak in through the back door) fails to solve the problem, and encourages bad workarounds.

poor package names

The actual package names are pretty much immaterial. Assigning real significance to them would be false. What matters is that they're unique and follow a scheme. As a user, you might want to install "php" - all that means is that the software studies the package metadata and works out what packages to really install. Actually having a pcakge with that name isn't necessary, and probably not even desirable (it locks you into current names and prevents evolution).

---

So, beyond a recognition in the codebase that the 21st century has arrived, and the lack of an apt-get/synaptic style front-0end - all of which could fairly easily be remedied - what is really wrong with SVR4 packaging?

JKstat 0.32

Friday the 13th, and I wonder whether to hold off for a day.

But no, another JKstat release comes out.

Nothing major here, still the continuing cleanup process. The one change here is better exception handling, particularly in Client-Server mode. It's not perfect, by any means, but in the past I just dropped errors and exceptions straight in the bin.

The reason for doing so was that I wasn't keen on declaring Exceptions to be thrown - it seriously clutters up the whole API. But Fabrice Bacchella (thanks!) pointed out the obvious, that if I were to throw a RuntimeException then I wouldn't have to declare that I threw it. So the fix is to create a subclass of RuntimeException and throw that, and consumers that need to know can check for that (and can check for the specific failure - RuntimeException is far too generic).

Into the sunset?

The announcement to EOL Solaris Express Community Edition (SXCE) was telegraphed well in advance, and we're coming to the end of the road with only a handful of planned releases left to look forward to.

But, is this just the end of the road for SXCE, or is it something bigger that's at stake here?

Read the Sun marketing and you might believe this is a glorious new dawn for the Solaris/OpenSolaris world. The reality may be more like sailing off into the sunset and disappearing from view.

The fundamental difference between the old and the new is instalation and packaging, which have been ripped out wholesale and been incompatibly replaced. Even if the replacements had been perfect (and, quite frankly, they fall a huge distance short) this would have been a huge challenge. Organisations (and individuals) are under huge pressure to retrench and consolidate. Adding additional technologies that they're expected to support is an uphill battle. Adding brand new (and essentially untested) technologies that they're going to have to learn from scratch makes it doubly hard.

If the next version of Solaris had been based around SXCE, with traditional deployment technologies - traditional packaging and jumpstart - then customers would have been able to start rolling it out tomorrow. Everything a customer knew, all their existing investment in skills and tools, would be preserved. New customers would be able to leverage the skills and expertise of existing customers. All the great features and functionality present in OpenSolaris would be there to be taken advantage of.

Contrast that with the planned OpenSolaris transition. You have to retrain all your staff, replace your entire toolset, rebuild your entire systems deployment and administration infrastructure. Most environments are heterogeneous, so this means you now have an entire extra set of infrastructure to support - you aren't going to transition everything to the new scheme immediately, so you're going to have to shoulder the burden of supporting the extra scheme in parallel for years. Isn't the most likely course of action for a cash-strapped IT
department with a CIO breathing down their neck to simply reject that and migrate everything over to RHEL?

Solaris and OpenSolaris contain fantastic technologies that make them a great choice for IT departments - ZFS, Crossbow, CIFS support, zones (especially sparse root zones), Dtrace, and many more - but by making deployment such an unattractive proposition we're making it far less likely that customers will try or use these technologies, and are giving organizations and managers every excuse to ignore Solaris and OpenSolaris as an option.

The best thing Oracle could do for Solaris and OpenSolaris would be to scrap the OpenSolaris distribution (but not the rest of OpenSolaris) and redirect our energies into building a better Solaris based on SXCE. If not, then I fear that Solaris will ride off into the sunset and be consigned to the wastebasket of superior technologies that failed due to bad strategic decisions, and that's a prospect that truly saddens me.

Tinkering with the SVR4 packaging source

Take one look at the SVR4 packaging source in Solaris/OpenSolaris and it's clear that it's suffering from serious neglect. It's old. It's fragile. It's had stuff bolted onto the side over and over until it's a wonder that it works at all.

Yet, it's survived for the best part of two decades and every Solaris system uses it.

I recently had to fix up some packages on Solaris 10 that were in the deadly embrace of webstart. If you tried to remove them with prodreg, it said "oh no, you must use pkgrm", yet when you tried to use pkgrm it said "oh no, you must use prodreg".

So, we have access to the source, right? And, while I could have manually gone in and wiped out the errant packages by hand, I had a look at the SVR4 source to see if I could put together a version that actually did what it was told.

This was pretty easy. It took a little effort to get enough together that would compile cleanly on Solaris 10 again. And, having done that, and solved the initial problem, I did a bit more tinkering to remove some of the more obviously redundant code and apply some of the performance improvements that are sorely needed.

After thinking up a meaningless acronym, I've made the code I have available here: SPRATE. You're free to use it; anyone feeling masochistic enough to work on it is free to contact me.

Migrating old servers

Buried in a far recess of some organisations you'll find some really old systems. I've just acquired a new playground - not a Solaris 10 box in sight. What I do have is a lot of much older stuff, going back to:

SunOS jawdropped 5.5.1 Generic_103640-29 sun4u sparc SUNW,Ultra-1
SunOS gobsmacked 5.6 Generic_105181-39 sun4m sparc SUNW,SPARCstation-10

Ouch! I thought I had long seen the last of such hardware or Solaris versions.

Now, Solaris has excellent binary compatibility. I have some old SunOS 4 binaries from the 1980s that I use on a daily basis. So I'm expecting to be able to take a lot of what's present and simply move it onto new systems.

I'm also planning on using Solaris Containers to help make the transition easier. I would much prefer to do a proper move of the application to a newer system, but that takes time. The advantage of the Containers approach is that you can lift up a working system lock, stock, and barrel, and migrate the whole lot in one fell swoop - otherwise it can be quite a lot of effort to cleanly extract an application from an old (and usually undocumented) system.

Unfortunately there isn't a Containers implementation for Solaris 7, 2.6, or 2.5.1. So those have to be done the hard way.

java + picl = fail

Solaris has PICL - the Platform Information and Control Library - as a mechanism for storing and retrieving platform-specific information. It's structured as a tree, so a natural thought would be to load the information into java and use a swing JTree to present a graphical representation. (And would make a nice add-on to SolView.)

I wrote such a tool several years ago. It uses JNI to interface with the native libpicl, and it never worked properly. It still doesn't work properly - it crashes far more often than not. The crashes are consistent in the sense that if it crashes on a machine it will always crash in the same place (retrieving the same object from the picl tree), but are random in the sense that apparently nonsensical changes to the code will either kill or cure it.

Anyway, I'm just tossing it out there. It's called piclbrowser, and is available here. Anyone's free to take this and play with it, and is welcome to try and fix it.

Appalling Virgin "Broadband"

I've had a home broadband connection from Virgin - formerly NTL - at home for years. Until recently, the quality of the service was excellent - I could almost always get the full quoted speed, and we only had the occasional minor outage.

Recently, though, the connection has been terrible. It's been several weeks, almost a month now. I'm supposed to get 10M/s (that's 10 megabits). Trying the various speed tests that are available - including the ones recommended by Virgin themselves - and I get 5% at best, usually rather less. And I suspect that those aren't telling the full picture, as the actual rate I'm getting in practice is worse. Web pages can take minutes to load. Watching TV programmes or gaming is simply a non-starter. I tried downloading something an hour ago and it's not even managed to get a single byte yet. Packet loss is 10% and up. It's not usage or time dependent.

(Fortunately, gmail seems to remain moderately responsive, but pretty much anything else is essentially down. Attempting to actually work from home is a disaster.)

Virgin Media's online support is awful. For starters, their web form is completely incapable of working out who you are even if you're logged in - so you have to fill in all sorts of account details. The first one I sent was acknowledged and then ignored. The next one got a standardized answer. I did what was asked, got given some more things to try, and did those too. (My connection is sufficiently poor that some of the tests don't even work.) The no response in over a week. No response to my following up.

So I tried the telephone. Oh dear. After the usual rigmarole of giving them every single piece of information they already know we go through the standardized script. Have I rebooted the modem? Tried that, several times. Have I rebooted my computer? Yes. Have I checked for spyware? Yes. Am I running XP or Vista? Well, I have both, and they're slow as well, but they can't even spell Solaris. Can I run a speed test? I try that, and get almost 5% of what I'm paying for, which is actually better than most of the times I've tried.

The poor chap then has the temerity to tell me that my broadband connection is working perfectly, and that I need to call the PC helpline who'll help me fix the problem with my computer. I think I managed to stay civilized throughout the resulting exchange.

It's possible that there's a problem somewhere in the house, of course. I've tried to exclude that, and can't, because the test required to do that - direct connection of a machine into the modem - simply fails completely. I regard that as an interesting data point, but I'm only a sysadmin not a call-centre automaton reading from a script.

Faced with a combination of a terrible broadband connection, and useless customer service, I investigated alternative providers. Which leaves me stuck between a rock and a hard place, because my house must be a long way from the nearest exchange, so that using the BT line (which is the only other connectivity option) would take me down to 3M if I'm lucky. And I really do need the 10M I'm paying for.

Grrrr.

SNMP from java - updated

I've just uploaded Jangle 0.05, a minor update to my graphical java snmp client.

It's not just graphical now; I've added an snmpwalk subcommand to walk the snmp tree from the command line.

There's also the normal clutch of bug fixes and general code improvements.

One thing I've been playing with is trying to automate discovery of relationships. The snmp information is stored in a tree, but the last two nodes in the tree are inverted. Consider ifInOctets as an example: it has a child node for each interface, as does ifOutOctets. So just looking at ifInOctets gives you a list of interfaces, whereas what you really want is to generate a list of interfaces and then get all the data for that interface. You can get this by parsing MIB files, but I would like to be able to do this just by looking for patterns in the OID tree, and then look at the MIB afterwards to describe the structure. (One thing I want to avoid is having to ship all the MIBs for every possible device.)

OpenSolaris Constitution Update

The OpenSolaris Constitution is known to have a number of flaws. It's not well matched to the way the community actually works; it conflates local functional roles with global governance roles; and it's relatively long and complex.

At the last annual election, a revised constitution was proposed that aimed to eliminate those shortcomings - greatly simplified and separating governance from operations. It failed to pass. (Only narrowly, but it failed.)

The current OpenSolaris Governing Board decided early in its term of office that we would again offer a revised constitution to the OpenSolaris community, after taking an opportunity to correct any errors or issues that community members might be concerned about.

As announced, revisions to the constitution are now available for comment, and we invite all interested OpenSolaris community members to send us their comments. (Reviewing the release notes would be a sensible starting point.)

SolView 0.48

It looks like my SolView 0.47 announcement was a tad premature. Testing was somewhat incomplete.

Version 0.48 fixes the problem, and is now available.

(The technical goof I made is like this: the solview wrapper script sets things like the LD_LIBRARY_PATH and CLASSPATH. However, if you just run solview with no arguments it pulls the CLASSPATH out of the jar file manifest instead. I had updated the wrapper correctly, but forgotten the manifest. I normally run the individual views in isolation, so hadn't noticed that one of the jar files was missing, resulting in the process view generating a stack trace rather than the useful output it was supposed to.)

So, to anyone who grabbed 0.47, you'll want to get 0.48. Sorry about that.

JProc 0.2

I've been doing a little more work on JProc - a java jni interface to the Solaris procfs filesystem - to make it a little more complete and robust.

This has reached a convenient stopping point, so I've released version 0.2.

There are a couple of features that have been lifted from JKstat, namely the idea (and parts of the implementation thereof) that it's useful to manage a Set of processes as a unit, and that it's useful to be able to filter on process characteristics.

As a start, I've added filtering by user and zone. The demo application now has dropdown lists of users and zones, so you can select processes owned by a user, or running in a specific zone (or both) interactively. (They don't currently update as the list of users and zones changes - that's work left for the future.)

I've also added lookups of username, group, and zone name. This is a simple jni interface to getpwnam and friends.

One other feature I added was to convert a project id to a name. This proved rather more entertaining, as I discovered that the lookup functions are buried off in libproject rather than libc. While that of itself isn't necessarily an issue, libproject drags in quite a lot of subsidiary libraries. While in normal use they use lazy loading so that you don't drag in the extra libraries until you need them, it looks like jni drags them all in regardless. I'm not sure how useful project name/id lookups are going to be, so I may simply remove that bit of functionality.

SolView 0.47

One of the things I've been trying to do with SolView is to provide a user with multiple views of a Solaris system from all angles. I'm not going to claim I've succeeded, but I've released another SolView update with a couple of new features.

The first is to add charts from JKstat that show behaviour over time - visible in the processor and network view. I've put quite a bit into the chart support in JKstat, and was pleased that it was so easy to use it to add charts to SolView. (It's not entirely perfect - it would be nice if the colors in the cpu chart matched the cpustate widget, for example. And it's a shame that I don't collect history so that each time you look at a chart it starts from scratch.)

The second is a Process view from JProc. Which is what I wrote JProc for in the first place.

Apart from that there's the usual raft of bugfixes, and there's a little more polish. Enjoy!

JKstat - interactive chart builder

In the latest update to JKstat I've introduced a new piece of functionality I've been wanting to get done for a while.

JKstat is pretty good at producing charts, but - until now - you've either had to take what it gives you or delve into the code. No longer. As of version 0.30, if you

./jkstat chartbuilder

you'll get a window just like this:


A kstat can be selected from the tree; you can then choose the statistic or statistics of interest, and then get a chart of either the rates of change or the values of the chosen statistic(s).

You can also choose whether to produce a line chart of the various statistics, or a stacked chart, with statistics in solid color stacked atop each other.

You can then choose whether to just show this individual instance of a kstat, or to show all the available instances (so you can, for example, produce a chart showing all the disks or all the cpus, just by picking one).

And you can decide whether to show the individual kstats, or whether to show an aggregate over all the kstats.

So, the following chart is generated by selecting cpu:0:sys from the tree, checking all instances, and asking for an aggregated, stacked chart of the cpu_nsec_idle, cpu_nsec_user, and cpu_nsec_kernel statistics, showing the relative proportions of user, system, and idle time on my system.



(If you're interested, the spike of user activity at about 21:19 is a build running; the huge splodge of kernel time just after 21:27 is VirtualBox starting up a VM.)

Everything Virtual

Virtualization is one of those hot IT topics, but the reality is that - in the general sense - virtualization has been around for what seems like forever.

I define virtualization as the abstraction of logical resources away from physical resources.

For example, NFS (the Network File System) allows you to access your data from any system, not just the one that happens to be physically connected to the disks on which the data is stored.

The X Window System allows you to display applications on a different host to the one where they might be running.

VNC (Virtual Network Computing) is one of many technologies that allow you to access a complete desktop on a different system to that where it's running.

The various types of Virtual Desktops supported by X11 window managers allow you to manage and display applications independently of the physical screen that you may be sitting in front of.

Solaris Zones allow you to construct an operating system instance that, while in any particular instantiation is locked to a piece of hardware, is logically distinct. It's relatively trivial to pack up a Zone, redeploy it on new hardware, and the application layer doesn't notice. Again, a level of abstraction from the physical.

Interestingly, the current virtualization fad doesn't quite work the way you would expect based on the definition I started with. Looking at the various virtual machine technologies currently in vogue, while the virtual machines are abstract from the underlying hardware, the abstraction that's presented to the user is that of physical systems. This doesn't introduce anything new, it just gives us the same old IT infrastructure we've always had, just replicated one layer up in the stack. Useful, but not revolutionary.

And the cloud doesn't really change that, because all you're getting with a cloud is an extra layer (and a whole new charging model) underneath your virtualization layer. Everything may be virtual, but in many cases all we're doing is finding new ways to implement the physical.

xfce-taskmanager on Solaris

XFCE has a little task manager application. It's not top or prstat, but it's reasonably lightweight and integrated.

(It also allows you to click on a column heading to sort. That's one of the things that JProc does as well and that you take for granted in a graphical application.)

The original task manager was linux-specific, and the way it wandered through /proc was never going to work on Solaris. But it was easy enough to produce a Solaris version that seems to work well enough for me. Source here.