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.
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.