RE: [cobalt-developers] Package Un-installation issues on Qube 3

["Robert Walter" <rwalter@xxxxxxxxx>]

Michael,

I am with you on the makefile stuff. And I am also working the config
files through PHP. That is fine as long as you don’t need root level
access to things. Only handlers get root access to the system. So don't
even bother trying with PHP. You can do it with PHP, but it makes for
one hell of a security hole. Doing anything in terms of interacting with
the system from PHP is fine, as long as it seems logical. Why go around
a bush when you can see through it? Anyhow, Just use common sense in
your code, and no-one will ever complain.

In terms of makefiles, I don’t bother. The cobalt ones are buggy from
what I have heard, and it is quite simple to build a package manually.
Just build your RPMS as normal, and then slide them into a package file
template.

You can find a readme. File on the cobalt website at...

ftp://ftp.cobaltnet.com/pub/developer/TechNotes/sampleQube3.readme

This refers to a sample package file (sample.qube3.pkg) in the sample
directory. So find the file and go from there. It gives step by step
instructions how to make a package by hand. (Way easy)

PS. If you are interested, I have a few packages for the Qube3. You can
find them on my site. Please let me know if you are interested in them,
or have any feedback about them in general.

Regards,

Robert Walter
www.cyrius.ca
rwalter@xxxxxxxxx
Cyrius Automation Inc.
78 - 678 Citadel Drive
Port Coquitlam, BC
V3C6M7  CANADA



-----Original Message-----
From: cobalt-developers-admin@xxxxxxxxxxxxxxx
[mailto:cobalt-developers-admin@xxxxxxxxxxxxxxx] On Behalf Of Michael
Stauber
Sent: Saturday, July 06, 2002 9:18 PM
To: cobalt-developers@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-developers] Package Un-installation issues on Qube
3


Hi Robert,

> Cobalt has a bug in their uninstall script which
> messes up when your package name contains spaces in it. If you notice,

> all of Cobalts packages are named like 
> "Qube3-All-Security-4.0.1-13323" with no spaces. This is contradicted 
> in the sausalito manual on page 6-13 where the NameTag: variable 
> clearly states that it can be an Internationalizable package name 
> string.

Hmm ... very interesting. I'll try to remember that info when it comes
to naming my packages. Yeah, the manuals are contradicting, in parts
obviously wrong or omiting a few important details. :o/

"msgunfmt" anyone? <grrr>

> In terms of writing your own stuff, keep at it. It will take reading 
> the Sausalito manual about 10 times before it all makes sense.

I finally got my custom pages inserted into the Qube3 interface and
learned a little more about Sausalito. Mostly by reverse-engineering
existing pages or trial and error as you suggested.

In some parts I'm simply cheating on Sausalito as I use one of my PHP
scripts to read from and to write to a config file directly, fully
bypassing the handlers. I looked at the handlers and OID stuff, but that
seemed more hassle than it was worth for simply fetching a few values
from a config file and rewriting the file from scratch if the admin
changes some values through the GUI.

So now I've got the XML file with the navigational nodes, have my PHP
pages, the *.po file, *.schema, *.conf and the handler *.pl - all in the
proper places where the GUI expects 'em.

Where I'm currently stuck at is building the RPMs. I know how to build
RPMs in general and based on /usr/sausalito/devel/templates/spec.tmpl I
made a specfile for my purposes. However, there is no sample
packing_list.tmpl anywhere on the Qube (opposed to what the manual
says), but ok, I got one from an older version of that PKG (same
software without GUI) that I can modify.

But what's the matter with the makefile in first place and the commands
"make all, make clean, make install and make rpm"? Somehow they don't
seem to fit into the scheme and the manuals are kinda elusive on that
issue.

>From my understanding I could as well create a single RPM with my
gui-extensions the "normal" way. Upon installation that RPM then
distributes the correct files to the proper places in /usr/sausalito to
be done with it.

Then I simply build an PKG which contains my manually created packing
list, a custom services.po, the RPMs (of course) and all the proper
install and uninstall scripts. To me that looks like the easiest
alternative at the point where I'm at, but somehow I think that's not
the way it's supposed to be done.

Any pointers? Many thanks in advance!

--

Mit freundlichen Grüßen / With best regards

Michael Stauber
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer

_______________________________________________
cobalt-developers mailing list cobalt-developers@xxxxxxxxxxxxxxx
http://list.cobalt.com/mailman/listinfo/cobalt-developers