Menu
▾
▴
oscar-osgi-devel — Discussion of Oscar development issues
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(23) |
Nov
(5) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(28) |
Feb
(35) |
Mar
(25) |
Apr
(2) |
May
(8) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(32) |
Dec
|
| 2003 |
Jan
(4) |
Feb
|
Mar
|
Apr
(6) |
May
(5) |
Jun
(4) |
Jul
|
Aug
|
Sep
(2) |
Oct
(10) |
Nov
(4) |
Dec
(6) |
| 2004 |
Jan
(8) |
Feb
(21) |
Mar
(15) |
Apr
(17) |
May
(89) |
Jun
(5) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Richard S. H. <he...@un...> - 2002-02-11 18:41:19
|
I interpretted the spec as saying that bundles are not actually removed until a refresh occurs (or the framework is restarted), but I am open to other interpretations...I would rather do what is "correct" though... -> richard |
|
From: Richard S. H. <he...@un...> - 2002-02-11 18:39:06
|
Rob Walker wrote: >It's "non standard" - but I was considering modifying my cop[y of >OscarShell/Oscar.java to give it a COLDSTART startup option. Anyone else hit >similar issues? > I would have no problem adding something like this to Oscar, especially for debugging purposes. In the future when I get some sort of security working, we could perhaps make it a service as well, so you could interatively get it to cold start... -> richard |
|
From: Rob W. <ro...@so...> - 2002-02-11 18:34:39
|
Woops - forgot to include the exception:
Exception in thread "main" java.lang.NullPointerException
at org.ungoverned.oscar.OscarShell.exports(OscarShell.java:314)
at
org.ungoverned.oscar.OscarShell.processCommands(OscarShell.java:198)
at org.ungoverned.oscar.OscarShell.initialize(OscarShell.java:103)
at org.ungoverned.oscar.OscarShell.<init>(OscarShell.java:73)
at org.ungoverned.oscar.OscarShell.main(OscarShell.java:684)
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
ro...@so...
|
|
From: Rob W. <ro...@so...> - 2002-02-11 18:32:32
|
I was getting the following exception if a bundle with exported packages was
uninstalled and then an "exports" command was executed.
I amended the OscarShell code as follows which seems to cure this:
public void exports(StringTokenizer st)
{
...
for (int i = 0;
(exports != null) && (i < exports.length);
i++)
{
if (exports[i].getExportingBundle() != null)
{
System.out.println("[Bundle "
+
exports[i].getExportingBundle().getBundleId()
+ "] " + exports[i].toString());
}
-- Rob
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
ro...@so...
|
|
From: Rob W. <ro...@so...> - 2002-02-11 17:37:21
|
This seems to me to be a bit of a messy (or at least confusing) area in the OSGi
spec.
The JES implementation removes bundles immediately from the list of installed
bundles, and allows their reinstall immediately upon an uninstall(). This occurs even
if they have exported packages, which seems to contradict the spec. Although the
spec wording is not clear over this. The OSGi wording is "continue to make these
packages available to their importing bundles". To me, this could be several variants,
including:
(1) the bundles are uninstalled, but the classloader and JAR files left available for
importers until after a refresh.
(2) bundles with any exports at all are not removed until after a refresh
(3) only bundles with exports which are in use are not removed until after a refresh
JES seems to do (1).
As a halfway house towards a fuller understanding/implementation, I've amended
my copy of BundleImpl to work as for (2) i.e. remove a bundle if it has no exports:
public void uninstall() throws BundleException
{
...
// Reset state and send event.
setState(Bundle.UNINSTALLED);
m_oscar.fireBundleEvent(BundleEvent.UNINSTALLED,
this);
if (getExportCount() == 0)
{
try {
m_cache.removeBundle(this.getBundleId());
m_oscar.removeBundle(this);
} catch (Exception ex) {
rethrow = new BundleException(
"failed to remove bundle jar");
}
}
else
{
// Do not remove the bundle yet, just mark it
// as pending removal just in case it is
exporting
// packages; the bundle will be removed during
// framework shutdown or when packages
refreshed.
m_removalPending = true;
}
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
ro...@so...
|
|
From: Rob W. <ro...@so...> - 2002-02-07 11:12:56
|
One thing that's really getting in my way with OSGi is the lack of startup control - i.e. the standard says framework restart always comes up with the modules in same state they were in at shutdown. This is fine sometimes, but other times there's a need for a COLDSTART option where the framework comes up with no modules, and can be re-installed/reconf'd from scratch. Classic example is after a framework crash rather than a clean shutdown - ok, ok, Oscar doesn't crash I know, but other implementations might, especially when running under Windoze ;). There's lots of simple "implementation specific" ways to achieve this (e.g. with Oscar/JES, just blow away the cache before startup). Shame there's no standard means though. It's "non standard" - but I was considering modifying my cop[y of OscarShell/Oscar.java to give it a COLDSTART startup option. Anyone else hit similar issues? -- Rob SoftSell Business Systems, Ltd. ' testing solutions for a changing world ' +44 (20) 7488 3470 www.softsell.com ro...@so... |
|
From: Yann S. <Yan...@li...> - 2002-01-31 10:44:52
|
Hi everybody ! Some good news for the embedded and OSGi world : 1. Java Real Time is growing : TimeSys Corporation today announced that their completed Reference Implementation of the Real-Time Specification for Java (RTSJ) has been accepted under the Java Community Process(SM) (JCP) and is now available for free download at the TimeSys website ( http://www.timesys.com/rtj/index.html <http://servlet.java.sun.com/logRedirect/industry-news/http://www.timesys.com/rtj/index.html> ). Completion of the Reference Implementation for the RTSJ is a significant milestone in the open and inclusive JCP process that includes the final release of the specification. The Reference Implementation not only provides a proof of implementation of the RTSJ, but also provides the virtual machine required to test a Java technology-based application against the real-time specification. http://industry.java.sun.com/javanews/stories/story2/0,1072,42261,00.html What is really really nice with this news is that it is not only "free" : it is GPL ! http://www.timesys.com/rtj/index.html I will test it as soon as I'll be sure that it won't "break" my notebook : To download TimeSys Linux GPL for the Pentium, you must have a distribution of Linux, such as Red Hat Version 6.2 or 7.0 or 7.1, already installed on the target machine. TimeSys Linux is based on release 2.4.7 of the Linux kernel. Installing the TimeSys Linux kernel will replace the original kernel on the target machine. (the archive for pentium is 30Mo, if replace is not destroy, it's ok :) That was for the first good news, the second one is more related with OSGi : 2. ACUNIA, a leading provider of next-generation software and hardware for complete telematics solutions, has announced the introduction of Matilda^(TM), its telematics service platform designed to be fully compliant with OSGi Release 2.0. The Matilda platform is ACUNIA's Java^(TM)-based software implementation of the OSGi R2 specifications, allowing service providers to design and manage their services more effectively as part of the communications pipeline to the telematics (in-vehicle) device. What is the good news then ? Just that ACUNIA is the enterprise that provide the WONKA JVM (GPLed as well). Will they push the idea to opensourcing Mathilda ? :) Those informations are really good news for the Java embedded world ! Cheers, yann. |
|
From: Richard S. H. <he...@un...> - 2002-01-26 13:58:32
|
I am trying to finish up the implementation for ServiceTracker and I had a question about it and wanted some input from another mind or two. ServiceTracker is a class (not an interface) defined in the org.osgi.util.tracker package. Some of the methods on the class are specifically marked as synchronized, such as open() and close(). Since my implementation is keeping track of its service references/objects in a HashMap, I essentially need to synchronize each method that accesses the map, which would also include getService(ref), getServiceReference(), getServiceReferences(), getServices(), remove(), and size(). So, would it be in violation of the spec to make these methods synchronized? The other option is to synchronize internally using "synchronize (this)" or to synchronize on the map itself (but this latter approach would require that open() and close() also synchronize internally on the map itself, thus they would acquire two locks)... Thoughts? -> richard |
|
From: Richard S. H. <he...@un...> - 2002-01-23 17:14:15
|
Rob Walker wrote: >Got a case where I'm loading a Bundle Jar with a fair number of classes, and >imports which are resolved to several "inner jars" within another bundle (these >also have quite a number of classes). > >My bundle startup time seems pretty long (200s), and the CPU is burning fairly >hot too. Could be an internal app. problem, but think I recall someone mentioning >Jar loading/resolving speed being an issue. > I assume that this is related to the performance hit that was taken when I switched to the new storage system abstract layer. I had to switch from JarFile to JarInputStream and it resulted in slow class loading because I had to resort to sequential search. Due to this reason and a few others (I think mentioned previously on the list), I am removing the storage system abstract layer...I will try to have that done for the next release (hopefully in two weeks). -> richard |
|
From: Rob W. <ro...@so...> - 2002-01-23 17:07:56
|
Got a case where I'm loading a Bundle Jar with a fair number of classes, and imports which are resolved to several "inner jars" within another bundle (these also have quite a number of classes). My bundle startup time seems pretty long (200s), and the CPU is burning fairly hot too. Could be an internal app. problem, but think I recall someone mentioning Jar loading/resolving speed being an issue. Anyone else noticed this? -- Rob SoftSell Business Systems, Ltd. ' testing solutions for a changing world ' +44 (20) 7488 3470 www.softsell.com ro...@so... |
|
From: Richard S. H. <he...@un...> - 2002-01-21 10:31:28
|
Robert Huitema wrote: >I appreciate what you say but there are advantages to centralising >management. We are doing it quite successfully here, and it relates to the >pyramid of skill/work. > I think that perhaps we are misunderstanding each other. I never said that we shouldn't try to think of some way to do centralized management, quite the contrary. I definitely think we need some way to do it. What I was arguing against, was that I thought I understood you as saying that you wanted to install a "management" daemon on each client machine that would do a bunch of complicated stuff, including installing Oscar for the first time. If this is what you meant, then from my point of view it merely shifts the Oscar install/update problem to the daemon. >JNLP or similar to deploy OSCARMan and OSCARs only. > Okay, I understand this point now. I still don't like adding another system/delivery mechanism if not necessary...I think a simple system bundle update service for Oscar would have the same effect...but it would not be generic enough to install other applications if that is your intent... >OSCARMan for managing the OSCAR's and bundles - global info and bundle >upgrades etc, able to be used by low skill staff. Find them, report on them, >keep an eye on them, etc > So this is my question, does OSCARMan sit on the gateway with Oscar or is it at a centralized site communicating remotely with Oscar? If it is the former, then it doesn't seem like the best plan to me, but again, I haven't really spent too much time thinking about this level yet and apparently you have...so I won't claim to have a plan... Otherwise, I think we are in agreement about the needs and requirements of such an "enterprise" management level for Oscar. -> richard |
|
From: Robert H. <ro...@42...> - 2002-01-18 22:28:09
|
Richard,
I appreciate what you say but there are advantages to centralising
management. We are doing it quite successfully here, and it relates to the
pyramid of skill/work. Basically events create work to do, eg a loss of the
webserver needs attention. A lot of these things can be automated, some can
be attended to by low skill staff (deploy/replace ebox etc). If these things
dont solve the problem it propagates up to staff of greater skill.
What this does for us is it provides effective management of 75% of everyday
events by low skill staff who are low cost, easy to obtain and train. The
remaining stuff gets the skill and attention it needs, at greater cost. In
fact its more rewarding for staff too, the low skill staff dont struggle
with stuff they cant manage, and the high skill people dont get bored. The
key is to get the staff to deliberately provide a level of automation for
recurring problems that makes it possible for the problem to be attended to
next time by the low skill staff or automated systems.
It also means fully remote management is necessary, otherwise the staff have
to travel, and thats costly in time and money. (New Zealand is 2500km by
400km.) What we have achieved with this is 1 day training for local staff
(with basic PC user skills) to install, setup and deploy eboxes. The
installation and configuration is all 'wizard' based. This brings the ebox
up on the network, and gives it basic functionality. The rest of our system
then deploys the misc bits, and if needed we log in and tidy up.
In case of errors, we have misc diagnostics etc on the ebox, and immediately
upstream, plus SSH etc connection from our base. Events are sent by email.
If we cant contact it we just get it replaced, if its still broken we now
SSH into it.
When a new installation is required our system just makes a new image in the
LDAP from a template image. Then we get a 'standard' ebox, and tell it to
get the new image and we customise it as required. Then its auto applied to
the ebox making a custom ebox. We can now duplicate the ebox just by
grabbing another standard ebox and retreiving the custom LDAP config.
Where the mods below fit in:
JNLP or similar to deploy OSCARMan and OSCARs only. We use our
AppLoader (which pre-dates JNLP) for this and its great, but now we should
now go to one of the open source JNLP apps for simplicity/compatibility. We
can upgrade our distributed systems in minutes. Thats also a big bonus for
deploying small fixes, on the fly, we just update the applications web
server image. (All other apps should be deployed as bundles by OSGi)
OSCARMan for managing the OSCAR's and bundles - global info and bundle
upgrades etc, able to be used by low skill staff. Find them, report on them,
keep an eye on them, etc
LDAP and SAN - a way to store all local ebox config and backup local
bundle data on the network. Yes complex to setup, but low skill staff only
ever see a tool with "load,save, edit, etc", so they dont know its even
there. (When you have low skill staff replacing and installing eboxes, this
is the way to remove the complexity of operations like system configuration,
backup, restoring etc.)
As far as complexity goes, well yes it does have a potentially high level of
complexity. The key is vicious use of Occams razor!!. We deliberately build
only what we have a proven need for - so the OSCARMan v1 will only do a few
simple things:
1) read LDAP to find the current OSCAR servers, and list
them
2) double-click the list to connect to an OSCAR and get a
list of current bundles and status, and log
3) Install, uninstall, upgrade, start, stop a chosen bundle
4) backup/restore one or more bundles
5) manage the JNLP image on the webserver (eg copy files
in/out)
(Most of this we have already in various forms , we just need to assemble a
gui)
v2 might add some more value
1) global operations above on a group of OSCAR's
2) automated operations etc
3) PKI management
4) search LDAP on various criteria etc
I will try to think this thru this weekend to the minimum we need.
Robert
----- Original Message -----
From: "Richard S. Hall" <he...@un...>
To: "Robert Huitema" <ro...@42...>
Sent: Friday, January 18, 2002 10:55 PM
Subject: Re: [oscar-devel] OSCAR as part of a system
> Robert Huitema wrote:
>
> >At present OSCAR is a stand-alone server, that is OSCAR is installed
> >(manually) on a given PC, and run from the PC console. This works for a
> >single PC in the lab, but look at the complexities of running 1000's of
> >these. Would you ever get suitably skilled people who could do this in a
> >commercial environment at very low cost per OSCAR?
> >
>
> I agree 100%. My PhD thesis topic was in software deployment and these
> were exactly the types of issues that I had to think about as well. I
> think that this is very important and it is the most challenging and
> interesting part of the whole "vision".
>
> >Just as a discussion starting point, lets assume we build:
> >
> > An admin manager server that runs as a daemon
> > includes an http server (Jetty?):
> > Offers OSCAR JNLP installs, upgrades etc
> > offers core and sample bundles
> > can remotely connect to one or more OSCARS and
> >manage bundles
> > receives events and messages from OSCARS
> > can remotely connect to one or more OSCARS and
> >manage OSCARS
> > manages PKI
> > can handle requests for configs and backups from
> >OSCAR
> > interfaces to an LDAP store for config storage
> > interfaces to a SAN for backups of OSCARs and bundles
> >
> > A GUI client that controls the manager server
> >
>
> This sounds great, but from my point of view it does not address the
> issues at hand, it simply moves them to a different piece of software
> because what you describe sounds pretty darn sophisticated and complex.
> As a result, putting it in place on the hosts, upgrading, etc. is just
> as problematic as anything else.
>
> >OSCAR enhancements:
> > Additions to OSCAR to allow above (as bundles?)
> > JNLP integration (see OpenJNLP and bretheren) for
> >deployment
> >
>
> Using JNLP to install Oscar is one thing, but using JNLP in Oscar, I
> don't really see the point. I had originally started with JNLP before
> learning about OSGi. I don't really like JNLP, it isn't that well
> thought out and it doesn't provide anything over OSGi conceptually other
> than the fact that you can specify where to download dependencies, but
> that is something that I had planned on adding to Oscar.
>
> >This would bring OSCAR to a point where we could install the OSCARMan(!),
> >and from there install, manage and upgrade multiple OSCAR's.
> >
>
> This sentence illustrates my point, we just pushed the
> installation/management problem back one level...now we have a
> meta-installation/management problem. :^)
>
> I am sorry if my answers are not so in-depth, but unfortunately for me,
> it is getting towards the end of the school semester here in Berlin and
> I am fairly busy. I wish I had you around to talk with when I was
> working on my PhD, because these were the exact discussions I wanted to
> have, but could never really find a community for it! :^)
>
> -> richard
>
>
>
|
|
From: Richard S. H. <he...@un...> - 2002-01-18 10:02:13
|
Robert Huitema wrote: >At present OSCAR is a stand-alone server, that is OSCAR is installed >(manually) on a given PC, and run from the PC console. This works for a >single PC in the lab, but look at the complexities of running 1000's of >these. Would you ever get suitably skilled people who could do this in a >commercial environment at very low cost per OSCAR? > I agree 100%. My PhD thesis topic was in software deployment and these were exactly the types of issues that I had to think about as well. I think that this is very important and it is the most challenging and interesting part of the whole "vision". >Just as a discussion starting point, lets assume we build: > > An admin manager server that runs as a daemon > includes an http server (Jetty?): > Offers OSCAR JNLP installs, upgrades etc > offers core and sample bundles > can remotely connect to one or more OSCARS and >manage bundles > receives events and messages from OSCARS > can remotely connect to one or more OSCARS and >manage OSCARS > manages PKI > can handle requests for configs and backups from >OSCAR > interfaces to an LDAP store for config storage > interfaces to a SAN for backups of OSCARs and bundles > > A GUI client that controls the manager server > This sounds great, but from my point of view it does not address the issues at hand, it simply moves them to a different piece of software because what you describe sounds pretty darn sophisticated and complex. As a result, putting it in place on the hosts, upgrading, etc. is just as problematic as anything else. >OSCAR enhancements: > Additions to OSCAR to allow above (as bundles?) > JNLP integration (see OpenJNLP and bretheren) for >deployment > Using JNLP to install Oscar is one thing, but using JNLP in Oscar, I don't really see the point. I had originally started with JNLP before learning about OSGi. I don't really like JNLP, it isn't that well thought out and it doesn't provide anything over OSGi conceptually other than the fact that you can specify where to download dependencies, but that is something that I had planned on adding to Oscar. >This would bring OSCAR to a point where we could install the OSCARMan(!), >and from there install, manage and upgrade multiple OSCAR's. > This sentence illustrates my point, we just pushed the installation/management problem back one level...now we have a meta-installation/management problem. :^) I am sorry if my answers are not so in-depth, but unfortunately for me, it is getting towards the end of the school semester here in Berlin and I am fairly busy. I wish I had you around to talk with when I was working on my PhD, because these were the exact discussions I wanted to have, but could never really find a community for it! :^) -> richard |
|
From: Robert H. <ro...@42...> - 2002-01-17 22:41:36
|
This relates to the other discussions on security and management
recently, but I have entered it as a separate posting since I wants to
break the overall concept away from the detail.
I think we all agree that OSGI (OSCAR) is a very promising way to deploy=
and manage services across a network of hosts that are basically=20
appliances.
But basically the potential service providers and installers of OSCAR
dont have technical skills as we know them ;-) At best they are capable
of repeating something that they have been taught, provided its pretty
straight-forward. The complexities of classpaths, PKI, TCP/IP etc need t=
o
be hidden completely.
Having a good OSCAR will be great, but it will not be really useful unti=
l
a service provider can download a manager package, which installs OSCAR
on hosts, then deploys and manages bundles in a very simple way.
Basically they are not capable of working this out themselves. Even if
they have a person capable, these people are too useful, too overworked
as a result, and too rare and expensive.
We need to include tools that build a pyramid of volume<>skill, so that
low skilled, low cost people handle the large volume work, and the high
cost,high skill people only handle the very complex stuff.
At present OSCAR is a stand-alone server, that is OSCAR is installed
(manually) on a given PC, and run from the PC console. This works for a
single PC in the lab, but look at the complexities of running 1000's of
these. Would you ever get suitably skilled people who could do this in a=
commercial environment at very low cost per OSCAR?
Issues:
Remote access for management to OSCAR, and to the host?
OSCAR lifecycle: install, upgrade, uninstall. How?
Bundle management: install, upgrade, uninstall across 1000+=20
OSCAR's
Error and event reporting
Hard drive crash, how do you restore the OSCAR to its previous=20
state
??
Richard, I know you are focused on OSCAR functionality at present, and
thats as it should be. But I propose we discuss a suitable framework for=
the management of large numbers of OSCARS, and that the model be
incorporated into the design from here forward. This is because it
impacts on all the issues we discussed in the other threads, and as such=
affects the core OSCAR design and its success in the real world.
I also propose that we encourage others to contribute stuff that can be
incorporated into a management package, and start building a basic
manager. We would be happy to start this here in NZ, cos we need it for
our clients :-) . We already have a prototypes for netstorage and
ldapconfig bundles.
Just as a discussion starting point, lets assume we build:
An admin manager server that runs as a daemon
includes an http server (Jetty?):
Offers OSCAR JNLP installs, upgrades etc
offers core and sample bundles
can remotely connect to one or more OSCARS and=20
manage bundles
receives events and messages from OSCARS
can remotely connect to one or more OSCARS and=20
manage OSCARS
manages PKI
can handle requests for configs and backups from=
=20
OSCAR
interfaces to an LDAP store for config storage
interfaces to a SAN for backups of OSCARs and bundles
=20
A GUI client that controls the manager server
=20
OSCAR enhancements:
Additions to OSCAR to allow above (as bundles?)
JNLP integration (see OpenJNLP and bretheren) for=20
deployment
=20
This would bring OSCAR to a point where we could install the OSCARMan(!)=
,
and from there install, manage and upgrade multiple OSCAR's.
Comments pls
Robert
|
|
From: Richard S. H. <he...@un...> - 2002-01-17 08:32:40
|
Robert Huitema wrote: >Good idea, I had considered an embedded Oscar, but I didnt realise that I >could pass bundles to the SystemBundle this way, I will try it. > Be aware! You are not passing "bundles" to the system bundle, even though it does accept a list of BundleActivators. This is not expecting a bundle (i.e., a JAR file with the associated manifest, etc.); this is just a was to add system services to the container. Thus, the bundle activators you pass in will literally be part of the system, they will not have classes and resources loaded from a JAR file; the classes and resources must be available in the host's classpath. Generally speaking, this method is used to have an "application" add services to the container. For an example of this, see how OscarShell adds the "refresh" service. >I must admit i havent studied the OSGi2 scheme (I will now) but I did >originally go down the route of PKI and signed jars etc. The catch is >manyfold: > > a) How does OSCAR learn which sources are trusted? Basically you need to >have a secure connection to a management server which knows this. To >connect to the management server requires OSCAR to have a PKI private >key, otherwise the management server wont know to trust the client. > You can have a system bundle that allows you to add trusted keys using a trusted key, of course. :^) >b) what about the case where a jar comes from Company1, but is offered >by Org2. Who signs the jar? Does Oscar then trust all jars signed by >org2, or by Company1? If not, then how do you tell them apart? More >complex jar<>signature<>permissions relationships. It started to feel >like ActiveX security, you just trust everything signed by Microsoft!! > You base trust on who signs it, if the right person doesn't sign it then you don't use it. If you really want to use it anyway, then you must trust the person who signed it too. >b) Anyway you need to access and store and deploy PKI private keys etc >programatically, which brings in problems of keystorage and key >passwords. Basically you have to leave the key unencrypted, or store the >password somewhere where the OSCAR can read it, all potential security >problems. > I agree here. I don't know about this, as I said, I haven't looked at it in detail...nor am I any security/PKI expert... >c) Assuming you handle a) and b), and you have bundleX able to change >network interface params. BundleX gets a request from bundleY to change >IP address, how does it decide if bundleY is allowed to do this? Probably >by asking the Permission Admin Service...which I didnt have yet. > Yes, my guess is that bundleY would somehow have a permission granted to it to do such a thing... >All in all it got pretty complex, and complexity=trouble. When I loaded >the services as id<1024, it became very simple and easy. Also I dont >think it affects the eventual use of Permission Admin Service, or misc >bundles from other vendors, since all the mechanisms they expect exist >and would work anyway. > I understand your arguments and they are certainly valid, but I won't know a valid response until I investigate it further. I think security is very important, but I have been concentrating on functionality first. Perhaps after my next round of functionality is finished I will really try to delve into security... -> richard |
|
From: Rob W. <ro...@so...> - 2002-01-17 07:51:11
|
> > Why not create a bundle that provides a servlet via HTTP service? It > > doesn't need to provide a HTML GUI, although it could. This seems > > smarter since it doesn't require yet another protocol to the gateway. > > Yes we will do this too but we already have an RMI Registry listening on > the host. The actual setup is as follows, mainly for better security: > > * A daemon runs as root, starts an RMI based hostconfig proxy service. > * OSCAR starts as nobody (eventually chrooted) and makes an RMI > connection to the hostconfig proxy. > * Hostconfig allows only connections on 127.0.0.1, and only one of them. > It exchanges keys with OSCAR to further validate. Effectively OSCAR is > now the only process that can use the proxy, no arbitrary bundle will be > allowed to connect. > * OSCAR allows only privileged bundles to use the hostconfig RMI > interface appropriately. > > Hence its pretty simple for us to create an RMI interface to OSCAR, and > then expose it via a privileged servlet bundle too, but I will try to use > an embedded OSCAR, and do this outside your code. It's not directly related, but if it's of interest we'll probably be looking at creating an XML/RPC based control interface for OSGi/Oscar. Thinking is we can implement it through registered locations within the HTTP service, since XML/RPC is carryable over HTTP and hence we can get away with a single port listener. -- Rob SoftSell Business Systems, Ltd. ' testing solutions for a changing world ' +44 (20) 7488 3470 www.softsell.com ro...@so... |
|
From: Robert H. <ro...@42...> - 2002-01-16 22:40:34
|
> Robert Huitema wrote: > >Since I know the platform I have deployed on is a Linux box, I use a > >subclass of Oscar (LinuxOscar) which loads a privileged bundle I have= > >created (MyLinuxSystemBundle). MyLinuxSystembundle IS platform specif= ic, > >it allows me to manage the platform by exposing standardised OSGI > >interfaces to other normal OSGI bundles, eg get network interface sta= ts. > > > >MyLinuxSystemBundle becomes bundle 1, and is loaded explicitly by me,= so > >I control this. If I deploy on a windows platform, i use WindowsOscar= =20 and > >MyWindowsSystemBundle instead. > > > I don't think you need to do this the way you specify, simply create a= n > embedded instance of Oscar and you can pass into it various service > objects via its constructor, without having to build a bundle. These > services will then be offered by the SystemBundle. Good idea, I had considered an embedded Oscar, but I didnt realise that = I=20 could pass bundles to the SystemBundle this way, I will try it.=20 > >While making these work I had great difficulty in making a permission= > >scheme which allowed bundles to backup and recover only their own dat= a, > >and for OSCAR to be able to to the same. It sounds easy but since > >bundleids are not predictable, it becomes almost impossible to decide= on > >appropriate access. It lands you in PKI stuff, which brings the > >head-aches of key management etc. And eventually you only end up > >resolving the bundle to the bundle provider, and you still cant decid= e > >whether to trust them or not unless they go thru a process of submitt= ing > >their bundles for approval. Its all very ugly and unworkable in a wor= ld > >with a given instance of OSCAR using a random 100 of 1000 available > >bundles. > > > I understand you issues and I believe they are very valid, but I have > not looked at the security stuff enough to know for sure which directi= on > I plan to go. I must say, though, my gut reaction is that this is not > the way to go. > From my initial glance at the OSGi Permission Admin Service, it seems= > like they have defined something that eschews the standard Java > AccessController stuff, because they indicate that permissions are > dynamic and the standard AccessController stuff is not dynamic, it it > read from a policy file at start-up. When I eventually create this > Permission Admin Service, then it should be pretty easy to add dynamic= > permissions to bundles, thus (yes, using some sort of public key > signature) Oscar could grant "all permission" to any bundles that are > signed with trusted keys. > I think that this is the better approach if it turns out to be possibl= e. I must admit i havent studied the OSGi2 scheme (I will now) but I did=20 originally go down the route of PKI and signed jars etc. The catch is=20 manyfold: a) How does OSCAR learn which sources are trusted? Basically you need t= o=20 have a secure connection to a management server which knows this. To=20 connect to the management server requires OSCAR to have a PKI private=20 key, otherwise the management server wont know to trust the client. b) what about the case where a jar comes from Company1, but is offered = by Org2. Who signs the jar? Does Oscar then trust all jars signed by=20 org2, or by Company1? If not, then how do you tell them apart? More=20 complex jar<>signature<>permissions relationships. It started to feel=20 like ActiveX security, you just trust everything signed by Microsoft!! =09 b) Anyway you need to access and store and deploy PKI private keys etc = programatically, which brings in problems of keystorage and key=20 passwords. Basically you have to leave the key unencrypted, or store the= =20 password somewhere where the OSCAR can read it, all potential security=20 problems.=20 c) Assuming you handle a) and b), and you have bundleX able to change=20 network interface params. BundleX gets a request from bundleY to change = IP address, how does it decide if bundleY is allowed to do this? Probabl= y=20 by asking the Permission Admin Service...which I didnt have yet. All in all it got pretty complex, and complexity=3Dtrouble. When I loade= d=20 the services as id<1024, it became very simple and easy. Also I dont=20 think it affects the eventual use of Permission Admin Service, or misc=20 bundles from other vendors, since all the mechanisms they expect exist=20 and would work anyway. > >On a separate note we need to be able to remotely control the OSCAR > >server, so I will build an RMI interface to allow access to the comma= nds > >(install, update, remove, start stop, etc) from our management server= s. > > > Why not create a bundle that provides a servlet via HTTP service? It > doesn't need to provide a HTML GUI, although it could. This seems > smarter since it doesn't require yet another protocol to the gateway. Yes we will do this too but we already have an RMI Registry listening on= =20 the host. The actual setup is as follows, mainly for better security: * A daemon runs as root, starts an RMI based hostconfig proxy service. * OSCAR starts as nobody (eventually chrooted) and makes an RMI=20 connection to the hostconfig proxy.=20 * Hostconfig allows only connections on 127.0.0.1, and only one of them= .=20 It exchanges keys with OSCAR to further validate. Effectively OSCAR is=20 now the only process that can use the proxy, no arbitrary bundle will be= =20 allowed to connect. * OSCAR allows only privileged bundles to use the hostconfig RMI=20 interface appropriately. =09 Hence its pretty simple for us to create an RMI interface to OSCAR, and = then expose it via a privileged servlet bundle too, but I will try to us= e=20 an embedded OSCAR, and do this outside your code. > -> richard > --__--__-- > _______________________________________________ > oscar-osgi-devel mailing list > osc...@li... > https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel > End of oscar-osgi-devel Digest |
|
From: Richard S. H. <he...@un...> - 2002-01-16 10:05:49
|
Robert Huitema wrote: >Since I know the platform I have deployed on is a Linux box, I use a >subclass of Oscar (LinuxOscar) which loads a privileged bundle I have >created (MyLinuxSystemBundle). MyLinuxSystembundle IS platform specific, >it allows me to manage the platform by exposing standardised OSGI >interfaces to other normal OSGI bundles, eg get network interface stats. > >MyLinuxSystemBundle becomes bundle 1, and is loaded explicitly by me, so >I control this. If I deploy on a windows platform, i use WindowsOscar and >MyWindowsSystemBundle instead. > I don't think you need to do this the way you specify, simply create an embedded instance of Oscar and you can pass into it various service objects via its constructor, without having to build a bundle. These services will then be offered by the SystemBundle. >While making these work I had great difficulty in making a permission >scheme which allowed bundles to backup and recover only their own data, >and for OSCAR to be able to to the same. It sounds easy but since >bundleids are not predictable, it becomes almost impossible to decide on >appropriate access. It lands you in PKI stuff, which brings the >head-aches of key management etc. And eventually you only end up >resolving the bundle to the bundle provider, and you still cant decide >whether to trust them or not unless they go thru a process of submitting >their bundles for approval. Its all very ugly and unworkable in a world >with a given instance of OSCAR using a random 100 of 1000 available >bundles. > I understand you issues and I believe they are very valid, but I have not looked at the security stuff enough to know for sure which direction I plan to go. I must say, though, my gut reaction is that this is not the way to go. From my initial glance at the OSGi Permission Admin Service, it seems like they have defined something that eschews the standard Java AccessController stuff, because they indicate that permissions are dynamic and the standard AccessController stuff is not dynamic, it it read from a policy file at start-up. When I eventually create this Permission Admin Service, then it should be pretty easy to add dynamic permissions to bundles, thus (yes, using some sort of public key signature) Oscar could grant "all permission" to any bundles that are signed with trusted keys. I think that this is the better approach if it turns out to be possible. >On a separate note we need to be able to remotely control the OSCAR >server, so I will build an RMI interface to allow access to the commands >(install, update, remove, start stop, etc) from our management servers. > Why not create a bundle that provides a servlet via HTTP service? It doesn't need to provide a HTML GUI, although it could. This seems smarter since it doesn't require yet another protocol to the gateway. -> richard |
|
From: Richard S. H. <he...@un...> - 2002-01-16 08:07:27
|
Rob Walker wrote: >Richard, > >Haven't really had time to think through all your points, and I'm not a Java >security expert. > First, if it is not obvious by now, I didn't write the message to which you are responding... :^) >I would have the following comments though: > >- relying on some specific ID allocation scheme within Oscar could make your >bundles non portable to other OSGi implementations (it may even push Oscar >away from OSGi compliance itself). There's a couple of other OSGI reference >implementations that you can test against (JES and Gatespace) which are free >for internal development use, and if OSGi compliance is a goal of yours I'd advise >doing parallel tests with Oscar plus one or more of these. > I agree. >- your notes are very Linux/Unix specific (references to root accounts and /proc), >again OSGi makes no platform distinctions and Oscar itself runs on WinXX and >Linux platforms so will need to consider how these issues apply. > I agree too. >All good issues though, and when Oscar gets the full OSGi security model it'll be >good for whoever works on it to understand the wider issues - certainly got me >thinking. > Agreed. -> richard |
|
From: Robert H. <ro...@42...> - 2002-01-15 21:35:48
|
Rob/Richard, Yes this needs consideration in terms of OSGi compliance, however since = the bundleids and special security are allocated only within OSCAR, ther= e=20 should be no problem. Working this thru a bit: SystemBundle becomes Bundle 0 as it does now. Since I know the platform I have deployed on is a Linux box, I use a=20 subclass of Oscar (LinuxOscar) which loads a privileged bundle I have=20 created (MyLinuxSystemBundle). MyLinuxSystembundle IS platform specific,= =20 it allows me to manage the platform by exposing standardised OSGI=20 interfaces to other normal OSGI bundles, eg get network interface stats.= MyLinuxSystemBundle becomes bundle 1, and is loaded explicitly by me, so= =20 I control this. If I deploy on a windows platform, i use WindowsOscar an= d=20 MyWindowsSystemBundle instead. OSCAR uses a custom security manager that sees bundleid, and knows to=20 allow bundleid<1024 special privileges. Again this is within the=20 implementation and should not affect normal bundles. This makes me=20 realise we should possibly have a setSecurityManager() in OSCAR too. Normal bundles are loaded as they are now, except they start at=20 bundleid=3D1024. I'm not sure if that breaks OSGI, but since OSGI bundle= ids=20 are never re-used, the number must get up to this level sooner or later = anyway. We continue to increment the bundleids as now. I have created 2 specialised bundles here (NetStorage and ConfigStorage)= .=20 They are backup and configuration storage services for OSCAR and misc=20 bundles. The data is kept on the management server remotely. This allows= =20 the OSCAR host to be replaced and reload current configs, data, etc from= =20 the network. Hence the OSGI gateway host becomes an appliance. While making these work I had great difficulty in making a permission=20 scheme which allowed bundles to backup and recover only their own data, = and for OSCAR to be able to to the same. It sounds easy but since=20 bundleids are not predictable, it becomes almost impossible to decide on= =20 appropriate access. It lands you in PKI stuff, which brings the=20 head-aches of key management etc. And eventually you only end up=20 resolving the bundle to the bundle provider, and you still cant decide=20 whether to trust them or not unless they go thru a process of submitting= =20 their bundles for approval. Its all very ugly and unworkable in a world = with a given instance of OSCAR using a random 100 of 1000 available=20 bundles. On a separate note we need to be able to remotely control the OSCAR=20 server, so I will build an RMI interface to allow access to the commands= =20 (install, update, remove, start stop, etc) from our management servers. Ive just found your new version (Jan) so I will try to implement this=20 stuff so you can have a look. Robert=20 |
|
From: Rob W. <ro...@so...> - 2002-01-15 10:39:27
|
Richard, Haven't really had time to think through all your points, and I'm not a Java security expert. I would have the following comments though: - relying on some specific ID allocation scheme within Oscar could make your bundles non portable to other OSGi implementations (it may even push Oscar away from OSGi compliance itself). There's a couple of other OSGI reference implementations that you can test against (JES and Gatespace) which are free for internal development use, and if OSGi compliance is a goal of yours I'd advise doing parallel tests with Oscar plus one or more of these. - your notes are very Linux/Unix specific (references to root accounts and /proc), again OSGi makes no platform distinctions and Oscar itself runs on WinXX and Linux platforms so will need to consider how these issues apply. Just some thoughts, if I get a chance I'll try and think of some more constructive angles to your comments - it's a little outside my scope of expertise though, so don't hold your breath! All good issues though, and when Oscar gets the full OSGi security model it'll be good for whoever works on it to understand the wider issues - certainly got me thinking. Regards -- Rob Walker From: Robert Huitema <ro...@42...> To: osc...@li... Subject: [oscar-devel] System bundle(s) and permissions Date sent: Tue, 15 Jan 2002 02:28:30 GMT > Richard, > > Its fairly easy to manage a bundles access privileges in Java using > SecurityManager. (Simplistically) you just allow I/O only in its own > bundle installation dir, same for classloading etc. However this gets > complex when you actually want some bundles to access resources on the > host directly, eg network interface stats and config changes > > For instance a misc bundle should not be able to read/write /proc/*, but > a host management bundle may need to. These can be thought of as > additional 'system' bundles, provided by the managers of the OSCAR server > and host. Many may be customised to a particular OSGI device eg > NetStorage, LDAPConfigStore, etc. > > To securely provide this kind of information the OSCAR server needs to > access the host with root permissions (or via a proxy with root > permissions). Then OSCAR should provide the info back to the bundle. > Hence the OSCAR server needs to know which bundles to trust. The trusted > bundle then exports an OSGI interface for other bundles. > > The difficulty is that a trusted bundle does not know whether the bundle > which accesses this exported interface is allowed special permissions or > not. I can get the bundle id, and its source, name etc, but not its local > permission map. > > Your SystemBundle overcomes this by always running as bundle 0. So OSCAR > knows if bundleid=0 its the system bundle and it can be trusted. This is > great for you, but what about my 'system bundles'. They will be assigned > the next available ID, making it difficult to differentiate them. This > leads to complex PKI, Security Managers, ClassLoaders, and misc ugly stuff:-( > > I suggest using the UNIX tcp/ip scheme, all bundleids less than 1024 are > privileged system bundles. They can only be installed by special root > methods not available to normal bundle providers. Normal bundles are > treated as now, but the bundleids start at 1024. > > Then in OSCAR's startup sequence you install your SystemBundle, and call > an empty method : > > installSystemBundles(); > > then complete loading all other bundles as you do now. > > By subclassing Oscar and overiding this method I can then install any of > my system bundles with my own predictable bundle IDS, and my System > bundles dont get nailed when you modify OSCAR ;-) The SecurityManager > becomes simple, and allows full access if bundleid<1024, restricted if > not. > > I can then use the system bundles to expose host and other management > information safely via normal OSGI, since the system bundle will know not > to expose sensitive stuff to bundleids>1024 > > Robert > > > > > > _______________________________________________ > oscar-osgi-devel mailing list > osc...@li... > https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel SoftSell Business Systems, Ltd. ' testing solutions for a changing world ' +44 (20) 7488 3470 www.softsell.com ro...@so... |
|
From: Robert H. <ro...@42...> - 2002-01-15 02:28:45
|
Richard, Its fairly easy to manage a bundles access privileges in Java using=20 SecurityManager. (Simplistically) you just allow I/O only in its own=20 bundle installation dir, same for classloading etc. However this gets=20 complex when you actually want some bundles to access resources on the=20 host directly, eg network interface stats and config changes For instance a misc bundle should not be able to read/write /proc/*, but= =20 a host management bundle may need to. These can be thought of as=20 additional 'system' bundles, provided by the managers of the OSCAR serve= r=20 and host. Many may be customised to a particular OSGI device eg=20 NetStorage, LDAPConfigStore, etc. To securely provide this kind of information the OSCAR server needs to=20 access the host with root permissions (or via a proxy with root=20 permissions). Then OSCAR should provide the info back to the bundle.=20 Hence the OSCAR server needs to know which bundles to trust. The trusted= =20 bundle then exports an OSGI interface for other bundles.=20 The difficulty is that a trusted bundle does not know whether the bundle= =20 which accesses this exported interface is allowed special permissions or= =20 not. I can get the bundle id, and its source, name etc, but not its loca= l=20 permission map. Your SystemBundle overcomes this by always running as bundle 0. So OSCAR= =20 knows if bundleid=3D0 its the system bundle and it can be trusted. This = is=20 great for you, but what about my 'system bundles'. They will be assigned= =20 the next available ID, making it difficult to differentiate them. This=20 leads to complex PKI, Security Managers, ClassLoaders, and misc ugly stu= ff:-( I suggest using the UNIX tcp/ip scheme, all bundleids less than 1024 are= =20 privileged system bundles. They can only be installed by special root=20 methods not available to normal bundle providers. Normal bundles are=20 treated as now, but the bundleids start at 1024. Then in OSCAR's startup sequence you install your SystemBundle, and call= =20 an empty method : installSystemBundles(); then complete loading all other bundles as you do now. By subclassing Oscar and overiding this method I can then install any of= =20 my system bundles with my own predictable bundle IDS, and my System=20 bundles dont get nailed when you modify OSCAR ;-) The SecurityManager=20 becomes simple, and allows full access if bundleid<1024, restricted if=20 not. I can then use the system bundles to expose host and other management=20 information safely via normal OSGI, since the system bundle will know no= t=20 to expose sensitive stuff to bundleids>1024 Robert=20 |
|
From: Richard S. H. <he...@un...> - 2002-01-04 20:36:28
|
Rob Walker wrote: >- The standard Java URLClassLoader is capable of loading from a >Jar file off the bat. As long as you construct the URL correctly, it >does the rest for you. > Yes, I originally used URLClassLoader for my own modular app env before switching to OSGi. ;^) What we need for OSGi is the ability to load from JAR files embedded in JAR files and I don't think URLClassLoader does this. Also, we need to be able to load native libraries from JAR files, and lastly, we need to be able to load classes from imported bundle packages...for these reasons I implemented BundleClassLoader. >- When JVM loads Classes from jars (using the above, but also >possibly with other loaders), it also caches them itself in the "temp" >directory of whatever platform you're on. > I didn't know that, but I am not sure if it solves anything for me. Did you have an idea how this might help Oscar? -> richard |
|
From: Rob W. <ro...@so...> - 2002-01-04 19:27:25
|
No worries - thanks for the info anyhow. I've made a temporary/interim change to my version here to implement getDataFile(), via your Storage* stuff anyhow. Needed it to get my code working with the bundles I was using, and it wasn't a big change. I can send the changed files if you're interested. BTW - couple of points on JAR files (which you may already know). I found these during my coding of our own modular app. env. which we're replacing with OSGi: - The standard Java URLClassLoader is capable of loading from a Jar file off the bat. As long as you construct the URL correctly, it does the rest for you. - When JVM loads Classes from jars (using the above, but also possibly with other loaders), it also caches them itself in the "temp" directory of whatever platform you're on. Regards -- Rob Date sent: Fri, 04 Jan 2002 19:55:26 +0100 From: "Richard S. Hall" <he...@un...> To: Rob Walker <ro...@so...> Copies to: osc...@li... Subject: Re: [oscar-devel] getDataFile and StorageNode > Rob Walker wrote: > > >One more suggestion that came to me while looking at > >implementing getDataFile(). > > > >I believe I'm right in saying that File objects can represent either > >directories or files. So maybe getFile() should either be defined at > >the StorageNode level, or also included in the StorageDirectory sub- > >interface. > > > > You are correct, but I think it is a moot point now. I have essentially > decided to scrap all of the StorageSystem stuff from Oscar at some point > in the future. The original goal of the StorageSystem was to eliminate > the implicit dependency on an actual file system, but because OSGi > exposes the getDataFile() method, this is not really possible. Further, > System.loadLibrary() also uses a file (well, a path to a file) from the > ClassLoader. As a result of these types of dependencies, it is not > possible to eliminate the file system requirement. > > To add insult to injury, the performance hit for this change was > significant since JarFile requires a File, thus I had to stop using > JarFile and use JarInputStream instead...this made scanning JAR files > really slow. > > I think I will go with a two-level approach, a local cache (i.e., the > file system) and an optional remote backing store. In this approach, if > Oscar is supplied with a remote backing store, then it would be used as > the main persistent backing store and the local file system really would > be a cache. If no remote backing store is supplied, then Oscar will only > use the local cache. > > No timeframe on this, but I would hope to include it in the next major > release... > > -> richard > > ------- End of forwarded message ------- SoftSell Business Systems, Ltd. ' testing solutions for a changing world ' +44 (20) 7488 3470 www.softsell.com ro...@so... |
|
From: Rob W. <ro...@so...> - 2002-01-04 19:27:24
|
> Sounds good, I will include the fix. I didn't write the LDAP parser > stuff, so I am glad that at least one of us understands it. :^) Wouldn't say I understand - only as far as I had to go in JSwat to trap this one ;). I'm strictly in "fix what I have to" mode so I can get my code into shape. Hopefully have time for more constructive and worthwhile contributions later. One thing I am likely to need before long is a Configuration Admin Service. I'm prototyping with the Gatespace one (which is what's thrown up my changes so far), but this has license implications so i'll need to find an open source one, or else write one later on. Looking at the OSGi spec it doesn't look too bad, so I may just dive in and build one. > I didn't see your email address on the developer mailing list though... :^) Not sure why - as a matter of course I tend to set my email "invisible" from lists I join, just coz I get so much junk mail from sites that trawl subs. lists for email addresses. Probably did that with this one too. -- Rob ------- End of forwarded message ------- SoftSell Business Systems, Ltd. ' testing solutions for a changing world ' +44 (20) 7488 3470 www.softsell.com ro...@so... |
5 messages has been excluded from this view by a project administrator.