OpenSolaris

You are not signed in. Sign in or register.

OpenSolaris Project: Visual Panels

View the leaders for this project
Project Observers

Endorsing communities

Desktop
Internationalization and Localization
Security
Service Management Facility (smf(5))
Testing

Visual Panels

Introduction

We often receive feedback that Solaris is too difficult to configure. Specifically, things which are easy to configure on other operating systems can sometime involve a complex set of error-prone steps on Solaris. There are many reasons for this:

  • We might force the user to manually express their high-level intent as a (usually large) set of low-level configuration changes.
  • If there is a tool which allows the user to easily express high-level configuration changes, it isn't always well publicized or easy to find.
  • If the tools are known, users may be forced to go to different places for different configuration tasks. The individual tools may look different or behave in different ways.

All of these are serious problems. A user trying to make a basic configuration change should be able to go to one place and find a simple, intuitive tool which behaves consistently with the tools they use for other configuration tasks (if using separate tools is, in fact, necessary).

Mere parity with other operating systems isn't the only goal, though. There are many features unique to Solaris which theoretically allow us to do a more complete job. For example, SMF gives us a much better view of how the different pieces of system software are interelated, and together with FMA it allows us to better understand and communicate software or hardware failures.

What we want Visual Panels to do

We want to provide a single, unified place for an end user to access those things he wants to configure on an OpenSolaris system. This includes desktop settings, hardware settings, system settings, etc. That said, solutions which involve enormous start-up times and put the user at serious risk of getting lost within the configuration tool itself don't count.

The user experience should be tailored to what we offer in OpenSolaris. This doesn't mean including the ability to tweak every Solaris-specific knob, but rather including those things which are uniquely useful or simply integral to the Solaris experience. The ability to provide diagnoses when requested configuration actions fail due to causes other than the administrator's immediate actions, for example, should be ubiquitously available.

The user experience when modifying a particular aspect of the system's configuration should be consistent as possible across different environments. This refers both to configuring remote machines (which, because of their similarity, we will also use to refer to Zones), as well as to configuring a Solaris machine from a non-JDS environment. "non-JDS" environments include:

  • OpenSolaris systems running an evolved future version of JDS (i.e. a natural progression from where we are)
  • OpenSolaris systems running a successor to JDS (i.e. a more radical progression)
  • OpenSolaris systems running an alternative windowing system (e.g. KDE, twm)
  • Non-OpenSolaris systems
  • Web browsers
  • TTYs

(We are not proposing providing specific solutions for all of these, but would consider producing something which would require duplicating common functionality to add support for one of these environments failure.)

We should be creating and using reusable components. If we need to create a better set of interfaces for accessing some part of the system, we should publish those so that others with the same needs can benefit.

Where we are right now

As was mentioned earlier, SMF offers us a lot. Instead of ad-hoc startup scripts, we have well-defined services with dependencies. Moreover, instead of continuing to force administrators and ISVs to create armies of simple but subtly different configuration files (or worse yet, condone the use of non-interfaces like modifying rc.d scripts), we created a convenient place to store basic typed configuration. In short, it has removed a lot of unnecessary heterogeneity.

Because of this, we decided that SMF was a good foundation to build upon. Doing so meant we could automatically handle any service currently in SMF, and without modification handle new services delivered in future releases of Solaris or by ISVs. Additionally, we could make incremental enhancements to the data stored in SMF that would allow service authors to instantly gain improved functionality for a relatively minor cost. Lastly, we could provide a means for service authors to deliver a custom interface for their service. This would be particularly useful in those cases where the underlying configuration was more complicated than a user should be forced to deal with, or when the configuration wasn't published via SMF.

We also decided that Java was a good language for implementation. Though the language itself is more complicated than something like C, the development process is far simpler. It also has a well-integrated, stable set of APIs for GUI development. The Java platform also includes mature APIs for remote management, XML parsing, data structures, and other things which would normally require us to manage a slew of other libraries (and their versions). Last but not least, it's portable, which makes it much easier to allow configuration of Solaris machines from non-Solaris platforms.

Without getting into any more narrative, we have assembled the following software components:

Java SCF interfaces

At the bottom of our software stack is a set of Java interfaces for the SCF (Service Configuration Facility – the technology just beneath SMF) and SMF. These interfaces allow both reading from and writing to the SMF repository from Java programs. We hope to publish a future version of these interfaces and integrate them with Solaris so that others can take advantage of them.

More about the Java SCF interfaces

The JMX Agent

The next piece is a Java Management Extensions (JMX) Agent which publishes MBeans for SMF services on a Solaris system. Inserting an MBean layer between our configuration tool and the system not only facilitates remote management, but should also provide interoperability with third-party management frameworks which consume MBeans.

More about the JMX Agent

The Visual Panels demo application

Lastly, we have a simple application, vp, which helps us exercise the underlying interfaces and serves as a testbed for our ideas. Many of the above principles are reflected in vp, though vp as a whole doesn't represent what we think a configuration tool should look like.

More about the Visual Panels demo

Blogs

dep - Visual Panels online help text now available

May 20, 5:48 PM

If you're using Visual Panels and are confused by a panel... it's a usability bug ( please let us know ). Normally we'd have online help to compensate for such inadequacies, but Java Help isn't ...

dep - Visual Panels in OpenSolaris 2008.05

May 7, 1:19 AM

For a while I've been working on a project to ease OpenSolaris configuration called Visual Panels (with Steve and Tony , and a great deal of patience, insight, and fastidiously gathered data from ...

Dave Powell - The last Java wrapper script

Feb 20, 2:07 PM

One of my biggest Java pet peeves is the fact that a pristene, platform-independent Java application will frequently be shipped wrapped in a diseased blanket of shell scripting. Nominally, this ...

Dave Powell - The last Java wrapper script

Feb 20, 2:07 PM

One of my biggest Java pet peeves is the fact that a pristine, platform-independent Java application will frequently be shipped wrapped in a diseased blanket of shell scripting. Nominally, this ...

Dave Powell - Visual Panels debut

Feb 6, 3:49 PM

Long ago , I mentioned I was working on creating Java APIs for SMF . Well, the blogless David Bustos and I have done just that... and a bunch more. Check out the OpenSolaris Visual Panels page to ...