[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-update-dev] Cascaded Configuration Areas
|
Well, I ran some more tests as a user
with restricted privileges and I found that a restricted user - using a
Secnario#2 - shared install, will also get the "No updates
are available" message and essentially cannot update their installation
either.
So - I am *still* torn between shipping
our product as a shared install or as a shared configuration.
It appears it is impossible in both cases to use the update mechanism
under certain conditions. In particular, in the shared install
mode, you cannot install updates to any plugins in the installation folder
unless you are an administrator. And in shared configuration
mode you cannot install any updates to any plugins in the installation
area unless you turn off cascaded mode (hence setting osgi.sharedConfiguration.area.readOnly=false).
Presumably you would also need administrator access to install updates
in this case as well.
So, currently we have issues with the
installation of new features not being picked up by users with the shared
install without doing a -clean
operation. On the other hand the shared configuration mode
should not have these issues, but comes with the alternate issue that in
order to update existing features you will have to manually specify the
shared configuration area as your target configuration when you start Eclipse.
So it appears both methods have some sort of manual step involved
- but I am leaning towards the shared configuration setup because this
manual step is:
- Less likely to occur. Administrators
will *usually* be upgrading via an installer as we have very low rates
of people actually using the update site anyway.
- The manual step (if it is required)
must be done by the person installing the updates (ideally an administrator
who is not an end user) so it is expected they know a little more about
installing the product. In the case of the shared install
you are relying on the end user to know to issue a -clean
manually.
We could potentially make this flipping
over to a non-cascaded configuration easier by having a second shortcut
in the administrator's program group to launch Eclipse in "Update
Mode" - which essentially means in non-cascaded mode - so that a user
with proper privileges could check the update sites for updates and install
them to the shared configuration area.
But it really is a wash. I'm hoping
someone will pipe up and tell me I am an idiot and I am missing some bigger
picture but I have been at this for awhile and I think I have finally unravelled
how this all works.
Mark.
----------------------------------------------------------
Mark_Melvin@xxxxxxxx
Sent by: platform-update-dev-bounces@xxxxxxxxxxx
06/08/2007 03:37 PM
Please respond to
"Eclipse Platform Update component developers list."
<platform-update-dev@xxxxxxxxxxx> |
|
To
| "Eclipse Platform Update component
developers list." <platform-update-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| Re: [platform-update-dev] Cascaded Configuration
Areas |
|
Hi Dorian,
I think the scenario you describe still works. Maybe I'll describe
my scenario then and someone can tell me the proper way to implement it...
;o)
All we want to do is have our Windows-based installer install a set of
plugins and features (along with a base Eclipse install and JRE). We
currently require administrator access and install this into C:\Program
Files\<blah blah>. Now we want this installation to be done
as an administrator and then essentially be read-only from then on. Now
other users (non-admin) can log into the machine and have all of their
user-specific settings stored in their home folders. If they want
to install new plugins they should be able to. This currently works
too, if they have appropriate access to write to the C:\Program Files area.
More on this later.
But part of the whole scenario is the ability to auto-update. When
new versions of our plugins are available (or of the Eclipse platform)
the user should be able to upgrade using the Eclipse update mechanism.
Now - I guess it is unclear whether this should be a user-specific
thing, or whether the user should be forced to log in as an administrator
to update their product.
The problem we initially had was that we were running with a normal configuration
area in the installation folder. If a user was a power user, Eclipse
would dump junk in this folder (which was undesireable). If the
user was not a power user, Eclipse would automatically dump junk into their
home folder (going into cascaded mode automatically if the user did not
have write access to the installation location). So then we decided
to switch horses and go with "Scenario #2" in the docs - the
shared install.
This appeared to work, but we recently ran into a problem. Our installer
can "update" an existing installation with new features, and
we were finding that after you updated your exisiting product installation
with new features (as an administrator), when you logged back in as a regular
user they were not being detected. You had to actually run a -clean
operation in order to find them. At this point I sort of made the
assumption that we really *should* be using was a cascaded or shared
configuration (Scenario #3 in the docs) and I have been cranking on
migrating our installer to work that way. I figured this would not
only solve the -clean issue but it would also solve the issue of users
installing their own third-party plugins. It all seemed to function
great (after bug #190533 was fixed), but I never thought about the whole
updating via an update site issue. I didn't realize the whole can
of worms I was about to open...
So, it appears that perhaps I have been running in circles the past few
days and what we *really* want is to continue using Scenario #2 - a shared
install, but figure out why users need to issue a -clean to pick them
up. But the issue I have then is - what happens when a power user
versus a regular user installs third-party plugins? It seems to me
that if you have write access to the installation folder - Eclipse dumps
them there. If not...well I have never tried this with a shared install
scenario. I assume it will go into your user configuration area?
Mark.
----------------------------------------------------------
Dorian Birsan <birsan@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx
06/08/2007 02:58 PM
Please respond to
"Eclipse Platform Update component developers list."
<platform-update-dev@xxxxxxxxxxx> |
|
To
| "Eclipse Platform Update
component developers list." <platform-update-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| Re: [platform-update-dev] Cascaded Configuration
Areas |
|
> What do other companies do in this situation? Does *anybody*
use cascaded configurations?
I'd be curious to know too. You seem to live dangerously here, expecially
given all the hacks you describe.
The main scenario that led to cascaded configs was the following: some
admin installs eclipse to a readonly location, then various users run it
in their own local space. Each user has his own configuration.Those user
configuration are cascaded to use the shared install, but each user can
add new plugins in their local space.
The main shared eclipse is managed by the admin only, users can't access
it.
I have probably missed something in your description, but is the above
scenario broken (without hacking away at config files, etc.) ?
Mark_Melvin@xxxxxxxx
Sent by: platform-update-dev-bounces@xxxxxxxxxxx
06/08/2007 02:29 PM
Please respond to
"Eclipse Platform Update component developers list."
<platform-update-dev@xxxxxxxxxxx> |
|
To
| "Eclipse Platform Update
component developers list." <platform-update-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| Re: [platform-update-dev] Cascaded Configuration
Areas |
|
OK, so I just set up a local test as it does what you describe, Dorian....but
with an unexpected twist!
- If I run using a default cascaded configuration
area (hence a read-only shared configuration area), when I search for updates
it simply tells me there are no updates available (even though there are
valid updates on the update site).
- If I override this and specify a configuration
location pointing to my shared area (cascaded then flips to off all by
itself), when I search for updates I get prompted for all of my new plugin
versions and can install updates.
- *However*, going back to case #1 - I
had faked this out with a policy file which re-directed all eclipse.org
stuff so I didn't have to wait for mirrors. Trying a cascaded configuration
again, this time allowing Eclipse updates (I am running a 3.2.2 based product),
it still does not find any "updates" for my plugins or for Eclipse,
but it now tells me there are available PATCHES for Eclipse 3.2.2 (patch
1, 2, and 3). Huh? OK, just for kicks I try to install one.
Uh-oh! It looks like it is going to go into the shared configuration
area - which should be read only right now. I click Finish anyway
and kablammo! It gives me an error telling me I cannot install the
patch because my site is not updateable.
<sigh> So am I the only one who finds this less that intuitive?
First of all - why the different behaviour for patches? And
second - if running in cascaded style (which is quite common I would think)
completely disables the update mechanism...well..to be frank - what is
the point of having an update mechanism?? If I have to specify a
different configuration on the command line, *and* log in as an administrator
to get write access to the folder anyway to install updates to my product
- well it seems to me that there is no point to having an update mechanism
because the updater will never find anything. And it makes the "Automatic
Updates" feature especially useless because it will never find *anything*
except patches - which you can't install anyway. You may as well
just have a "new feature" wizard and call it a day. Although
this seems completely broken as well because if I search for "new"
features to install - it can potentially show me features that have version
numbers *older* than the ones I already have installed (I've verified this
by pointing Eclipse to an out-of-date update site)!
What do other companies do in this situation? Does *anybody* use
cascaded configurations?
Mark.
----------------------------------------------------------
__________________
> > ............. What happens if I update a plugin using the
update
> > manager? Not install a new plugin, but actually run an
update
> > operation that installs a newer version of a plugin that currently
> > resides in my read-only configuration area (one of the base Eclipse
> > plugins for instance)? I'm assuming it will be installed
into my
> > user configuration area and not be available to other users on
the
> > machine?
>
> I don't recall the details, but I belive you can't update existing
> features/plugins because the updater will try to co-locate them with
> the old plugins. However, you should be able to install new plugins
> in a location of your choice.
Hey Dorian,
Thanks for the reply. The only concern I have is the one above. The
rest of the behaviour seems logical and desired, actually. So - if
a user is running a cascaded configuration then installing updates is completely
diasabled/broken? If this is true - what will it actually do (and
I will be testing this - I just need to set up something I can *update*
which is proving to be tricky right now)? I mean - will it *try*
to update and just fail, or will it not allow updates to the features at
all? I'm hoping the answer is c) none of the above and it will let
the user update the plugins into their user configuration area. That
seems more logical to me. Otherwise, why are we bothering to run
our own update site if the users have to become administrators and execute
a special command line (switching off cascading - which it turned on in
config.ini) in order to pick up updates to our plugins? We may as
well just give them a link to download a new installer.
M.
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE:
This electronic message contains information that may be confidential or
privileged. The information is intended for the use of the individual or
entity named above. If you are not the intended recipient, please be aware
that any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you received this electronic message in error,
please notify the sender and delete the copy you received.
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
AMI Semiconductor - "Silicon Solutions for the
Real World"
NOTICE:
This electronic message contains information that may be confidential or
privileged. The information is intended for the use of the individual or
entity named above. If you are not the intended recipient, please be aware
that any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you received this electronic message in error,
please notify the sender and delete the copy you received.
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE:
This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.