[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-developers] RE: Web Interface
- Subject: Re: [cobalt-developers] RE: Web Interface
- From: Michael Stauber <devel@xxxxxxxxxxxxxx>
- Date: Thu Aug 7 08:47:01 2003
- Organization: SOLARSPEED.NET
- List-id: Discussion Forum for developers on Sun Cobalt Networks products <cobalt-developers.list.cobalt.com>
Hi Daniel,
> I've already read the help doc compiled for older Raqs, but I'm curious how
> to do the following on the 550:
>
> How does one add a service control page on the web gui? Is there a
> standard way to do this, or must one simply patch the scripts that run the
> Admin server? Where are these scripts?
You might want to check the developers guide for the Qube3. The RaQ550 uses a
similar architecture and similar procedures for the admin interface:
ftp://ftp.cobalt.sun.com/pub/developer/TechNotes/DevGuide.pdf
Basically the RaQ550 gui is installed in /usr/sausalito and uses mostly PHP
and some PERL scripts, CCE and so called handlers which tie into the backend.
Explaining how that all works together is pretty much beyond the scope of an
email.
However, paces to check are the following directories:
/usr/sausalito/ui/web
/usr/sausalito/ui/menu
/usr/sausalito/handlers
/usr/sausalito/schemas
/usr/sausalito/ui/menu: Contains the XML files which generate menu entries in
the GUI.
/usr/sausalito/ui/web: Contains the PHP pages which are linked to in such a
menu entry. It also contains the PHP scripts which parse user input and then
trigger system changes through the handlers.
/usr/sausalito/handlers: As the RaQ550 GUI runs as unprivileged user for
security reason it cannot read or write to many system files directly, or
restart daemons which require root permissions. Therfore handlers are used as
"agents" and they interface between the unprivileged web interface and the
underlying system.
The RaQ550 also no longer uses Postgres to store information about sites,
users and settings for the GUI. Instead that stuff is stored in an object
database in XML format. To tie into that with custom GUI pages is possible,
but the average developer might rather not do that for the added layer of
complexity and the inside knowledge which is required for that purpose.
The steepest learning curve is obviously ahead if someone wants to add a new
menu entry to the GUI, wants to connect it a separate page to do "stuff" from
there which interacts with processes on the server. Best way to do that is to
look at existing pages of the GUI and to learn from them.
The easier approach sure is to modify existing GUI pages (and their handlers)
to your needs. Adding custom text or a custom checkbox here and there isn't
that difficult. However, these modifications might be lost during
installation of official patches which mess with the GUI.
Hope this helps and gives some insights.
--
With best regards,
Michael Stauber