|
|
OpenSolaris Project: Visual PanelsView the leaders for this projectProject Observers Endorsing communitiesDesktopInternationalization and Localization Security Service Management Facility (smf(5)) Testing Visual PanelsIntroductionWe 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:
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 doWe 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:
(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 nowAs 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 interfacesAt 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 AgentThe 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 applicationLastly, we have a simple application, More about the Visual Panels demo Blogsdep - Visual Panels in OpenSolaris 2008.05May 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 scriptFeb 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 scriptFeb 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 debutFeb 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 ... Dave Powell - Visual Panels debutFeb 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 ... |