Wednesday May 07, 2008 | « May 2008 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 8 | 9 | 10 | |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Today | ||||||
Links
- smf(5) blogs
- Jonathan Adams
- Liane Praza
- Stephen Hahn
- Steve Peng
- Visual Panels
- Jaime
- Steve Talley
- Tony Nguyen
Today's Page Hits: 72
Wednesday May 07, 2008 Visual Panels in OpenSolaris 2008.05
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 Jaime). I'm happy to say that — as of the May 2008 release — it is now available in the Indiana IPS repository. Installing it takes at most three steps (as root):
# pkg refresh # pkg install OSOLvpanels # svcadm restart manifest-import
The first step is unnecessary if you've refreshed since installing OpenSolaris 2008.05. The last would be if IPS supported SMF. *pokes Stephen*
If you are logged into Gnome, Visual Panels will be available as soon as you install the package and restart manifest-import. Though we started out by creating a console that contained the various sources of configuration, our usability testing showed the inconsistency with Gnome's presentation was confusing. So for the time being, we have "broken out" the panels as individual applications. Under System->Administration, you will now see:
"Apache Web Server"
"Core Files"
"Services"
"Shared Folders"
(Actually, the last two were there before and are silently hijacked when VP is installed.)
I feel like I should say more: perhaps go on a meandering,
screenshot-appointed tour of every nook and cranny, or provide a cookbook
of detailed instructions on how to do common things in VP. But after
a very enlightening usability study where we started users off at the
login screen and let them fend for themselves, I also feel like I should
shut up and see what people's raw reactions are. The former (at least
the meandering part) should be done eventually, but I will save it for
another day. To avoid a flood of similar
complaintscomments, though, I'll mention a few things
you might run into that are on my short list of things to fix:
Role support. Support for roles came in the 11th hour when we discovered that root is a role on Indiana1. So when you want to log in using the root role (or any role), you have to re-specify your username and user password, in addition to the role name and password. Yuck.
Visual footprint. When you have a console, your components not only have a similar look and feel (a good thing), but often have a similar size (not a good thing). Because of their console ancestry, the Visual Panels apps unfortunately have a large visual footprint, and need to go on a diet.
Shared Folders. We've been struggling to get the right balance between flexibility and simplicity, and still aren't there yet. And then there are the bugs.
Start up speed. Starting a Visual Panels control panel takes a few seconds. It's easy to say that this is because we're using Java, but the truth is we have a lot performance work to do. (Launching more VP-based control panels after the first window is open, on the other hand, should be pretty quick.)
Documentation. Unfortunately, Java Help isn't yet in Indiana, so the online help our doc writer worked hard to produce is unavailable. When Java Help shows up, you should be able to just install the package and VP will detect and use it automatically. We plan on putting HTML versions up on the Visual Panels page shortly as a stop-gap.
Yes, there is also a long list.
Stay tuned for more about how VP works and what we're doing with it. (I promise my next post will come before another 2 years flash by.) And please let us know what you think. None of this is set in stone, so feedback, ideas, help, etc. are all greatly appreciated.
Footnotes:
1...only if you create a non-root login during the installation process. Guess who was always installing without creating a non-root login?
(2008-05-07 01:19:31.0) Permalink Comments [12]
Trackback URL: http://blogs.sun.com/dep/entry/visual_panels_in_opensolaris_2008
Post a Comment:
You also seem to need a reboot once you've installed vpanels, as it wouldn't work until I did this on my system.
Posted by andrewk8 on May 07, 2008 at 01:36 PM PDT #
The 'svcadm restart manifest-import' should make a reboot unnecessary, though it will take a few seconds for it and its effects to complete. Can you elaborate on the symptoms you observed?
A related problem I've heard is that Gnome may not pick up the new menu entries right away; my guess is a simple relogin (or perhaps killing gnome-panel?) would solve that problem.
Posted by Dave on May 07, 2008 at 03:01 PM PDT #
The`svcadm restart manifest-import` worked just fine for me. No reboot required. Running in VirtualBox. Nice layout. I didn't notice any slow performance from java.
I think maybe some more status of what modules are loaded in apache are needed. And I'm sure there can be some more improvements on other configurable items in the http.conf file, i.e proxy redirects, scripting locations etc. But not a big deal right now.
In all nice work. I take it this is to replace smc which I like Visual Panels much more than smc.
I suspect something along the lines of disk management or zpool manaagement in the future.
That would really be nice.
Just when I thought this project was just about dead it comes back with a good show.
---Bob
Posted by Bob Palowoda on May 08, 2008 at 12:18 AM PDT #
Thanks for the kind words, Bob.
The nice thing about the Apache panel is it's fairly solid: it just
does what it claims to do. But, as you noticed, things like module
support are pretty light on functionality.
I agree ZFS configuration would be a great thing to include.
Especially in Indiana -- where the world is ZFS -- being able to
configure ZFS directly from the desktop is arguably essential.
Posted by Dave on May 08, 2008 at 05:11 PM PDT #
Random comments:
Feels odd that the "Services" panel is at the same conceptual level as all the others, given that the others all let you configure one or more of those services.
Breadcrumbs (kind of pointless in this dialog) and "Go Back" buttons are necessary evils in web apps, but shouldn't be seen in regular desktop dialogs.
They all need a lot of GNOME HIG love. (I assume they're really Java apps, but a Java app designed for the GNOME desktop ought to look and feel like a GNOME app.)
File menu looks odd on its own, and is redundant.
Apache
---
A scrolling dialog (Virtual Hosts). Yuck. This isn't a web page, dialogs should *never* need scrollbars.
Services
---
Search filter should search the service names and descriptions (as seen in the Properties dialog) as well as just the "svc:/blah/whatever" part.
What's the benefit of the icon view? Seeing a hundred identical icons with virtually-identical truncated labels is no good to anyone.
Posted by 192.18.1.36 on May 09, 2008 at 09:07 AM PDT #
Tried once. Could see the UI.
Then tried to setup a static IP on my machine...
Could not at all (diable nwan, using the network UI to change ip+machine name. reboot: no luck)
So going back to DHCP with nwam, and now I cannot login to visual panel, even if I also enter the root role and the root password and my name and my passowrd.
YEK!!!
Tried to put the new machine name just to see if someting is cached:
got infinite error dialog with
"verifing newmachinename s trusted..."
message (see the typo!!!) verifing not verifying
Clicked can
So bottom line I am stuck:
" unable to get the cert chain: connection refused"
This is hell, really...
ps: the package dep also brings 100s of other packages.. Why?
How do I recover this mess?
Posted by 192.18.43.225 on May 12, 2008 at 01:51 PM PDT #
@Anonymous 1:
To quickly propose an analogy, the relationship between the other
panels and the services panel is similar to the relationship between
your lightswitches and your fusebox. You don't get to one through
the other, and they are frequently found next to each other. Most of
the time the user should be using lightswitches, but if something
goes wrong, a trip to the fusebox might be necessary. (This analogy
obviously breaks down when you look beyond the user experience --
lightswitches don't control the state of your circuit breakers.)
The breadcrumbs do seem unnecessary for simple dialogs in the absence
of a console, but for more complex ones they are still handy. My
more general concern in this area is the total amount of real estate
used by the common header material.
The "Go back" button has felt bad ever since I put it there. I don't
consider the close-window button (read: opening a second window when
looking at an object) to be an improvement, though. One possibility
I'd like to explore is an objects/object "two shot", where we have an
abbreviated objects view on the left and an object's details on the
right.
The File menu isn't supposed to be alone; unfortunately, it has been
abandoned by the Help menu that can't be shown because Java Help
isn't yet available in OpenSolaris. Its redundancy also bothers me,
but we also need to consider the user expectation that major
functionality be accessible through menus, as well as its
accessibility benefits.
The scrollbars on dialogs are closely related to the fixed-size
footprint problem I mentioned in my original post. In general,
though, the problem is that the windows are too large; I've never
seen the Apache panel grow scrollbars unless I explicitly shrink the
window. Is your concern that the window size should be fitted to the
content, or that there is too much content to reasonably fit on your
screen at your font size?
Good suggestion on the search filter.
The icon view sucks with two straws. As you note, the labels are
useless. We'll be fixing that. The icon view is included for
consistency with other object views. i.e. its presence isn't
considered a feature so much as its absence would be considered a
bug. That said, service icons are badged when in a bad state, which
does make the icon view nice for getting a feel for system health
at-a-glance.
Thanks for the feedback. If you want to continue the discussion, I
recommend (but won't insist on) vpanels-discuss@opensolaris.org, as
email is a better medium for longer conversations.
Posted by Dave on May 12, 2008 at 03:37 PM PDT #
@Anonymous 2:
The network configuration UI is still the default one provided by
Gnome, so I'm afraid I can't help you there. I recommend raising
your concerns and questions on how to get your system working again
on desktop-discuss or nwam-discuss.
The connection error you ran into is a result of how the default
configuration -- for security reasons -- only listens to connections
over the loopback network interface. A connection to "localhost"
will succeed, but a connection to localhost's machine name will
fail. We definitely need a better error message in this case. I am
curious about the "infinite" error, though. Could you elaborate on
what you're seeing?
If you're starting with an OpenSolaris 2008.05 system, installing
OSOLvpanels should only pull in 7 packages: OSOLvpanels itself, the 2
Cacao packages, 2 packages needed by Cacao, and 2 Apache packages
(which we'd like to get rid of: see the blog post). Could your
machine be running an earlier release? If so, "pkg install" may have
upgraded the transitive closure of all dependencies of OSOLvpanels.
This could also have contributed to malfunctions you are seeing.
Posted by Dave on May 12, 2008 at 03:38 PM PDT #
@Anonymous 2:
Sounds like the server component is malfunctioning. Search for
common-agent-container-{number} in the output of 'svcs -a'; there
should be one, and it should be online.
If it's not running, that's the problem right there. If it is,
/var/cacao/instances/default/logs/cacao.0 will be helpful in
diagnosing the problem.
I don't know why it would be malfunctioning, unless you did in fact
inadvertently upgrade from a pre-2008.05 build (IPS package
dependencies are hit-and-miss at the moment).
Posted by Dave on May 13, 2008 at 01:13 PM PDT #
@Anonymous 2:
Blog comments aren't the best place for huge log files; I've removed
the ones you've posted.
Sifting through Cacao's log output, I see:
java.net.UnknownHostException: pigalle: pigalle
Which is a result of not being able to resolve your own hostname. It
sounds like your efforts to configure your networking aren't yet
complete.
This error is nonetheless irritating as I'm pretty sure it is
occurring in code that is (perhaps implicitly) referencing
localhost. I'll be filing a bug as soon as I can find out who's to
blame.
Posted by Dave on May 13, 2008 at 05:33 PM PDT #
Ok.
But
$ ping pigalle
pigalle is alive
So JMX must be looking at network setup in a different way. I guess this is the area VP needs to invest a lot: ease of use, better error handling, and ease of configuration.
Ludo
Posted by 192.18.43.225 on May 14, 2008 at 10:00 AM PDT #
More on the issue: If I enter the IP address in the "Host:" field, I have the same c'onnection refused ' error message.
(with and without the root/passwd entries
Posted by 192.18.43.225 on May 14, 2008 at 11:09 AM PDT #