Ludovic Champenois wrote:
> Christopher Kampmeier wrote:
>> Hi Ludo,
>>
>> At least on Mac OS X,
> Only Mac does this native protected install. All other installers use
> the regular user that launches the installer.
>> this bundle suffers from the same root install + pkg(5) issue as even
>> the current NetBeans + GlassFish v3 bundles. ie. out of the box, use
>> of Update Tool, the pkg(1) CLI and desktop notifier + Software Update
>> doesn't work. (If these features are not part of the test plan, they
>> need to be added).
>>
>> Assuming that the user managing the installation is usually not root,
>> the post install workaround is to:
>>
>> $ sudo chown -R <user id>:<group id>
>> /Applications/GlassFish-Tools-Bundle-For-Eclipse-1.1.7.app/Contents/MacOS/glassfishv3
>>
> Hum, for 1 single user, yes, maybe?
That's a fundamental limitation here with pkg(5): shared group with
appropriate file permissions is not sufficient. See further info below.
pkg(5) and user images don't have any problem when the owning user
performs the management tasks: be it root or a non-root. The problem is
when trying to achieve shared management across users with a common group.
>>
>> Doing this will allow the non-root user to use the Update Tool GUI and
>> pkg(1) CLI to manage the installation of v3. It will also enable the
>> desktop notifier and Software Update GUIs, which run as the non-root
>> user, to inspect and update the image.
>>
>> I am in the process of adding the gory details of why this is a
>> problem when pkg(5) is involved to an existing bug report filed under
>> Update Center.
> So this is more on the UC side?
Within pkg(5).
>> I'll also update the v3 tracking bug once those details are updated.
>>
>> We should also file a tracking bug for the Eclipse + v3 bundle. Where
>> is that issue tracker? (Same goes for NetBeans because it's not clear
>> to me that there is a tracking bug for the NetBeans installer).
>>
>> I haven't downloaded and tried the bundles on other OS platforms, but
>> a root install on those and an attempt to manage the install as a
>> non-root user will result in the same issue. (Being in the same group
>> ID doesn't help - which will be explained in the underlying UC bug
>> report).
>>
>> It's not clear to me whether you have an option to wire your installer
>> to install the content as non-root. I see about 15% of my apps under
>> /Applications installed as non-root.
>
> Let me see what I can do in the postflight script of our installer...Not
> sure if there, at that time I can get the regular user name as the
> installer has already asked for the root password to run the process. If
> I can, it is an easy change.
>
> Chmod a+w would not do the same?
No. That's insufficient.
Package maintainers specify in their package specifications the
ownership and permissions to apply to newly installed and updated files.
If a file exists and is owned by root and an updated package calls for
a change to the permissions on the file, pkg(5) will attempt to change
the permission. That's fine when the managing user is the owning user.
However, when the managing user is not the owner, but is still part of
the shared group, depending on the extent of the permissions change, the
chmod operation may fail. For example:
$ id
uid=501(ckamps) gid=100(_lpoperator) groups=80(admin),...
$ ls -al sges-v3-prelude/pkg/javadocs/resources/inherit.gif
-rw-rw-r-- 1 root admin 57 Jul 8 22:36
sges-v3-prelude/pkg/javadocs/resources/inherit.gif
$ chmod 0660 sges-v3-prelude/pkg/javadocs/resources/inherit.gif
chmod: Unable to change file mode on
sges-v3-prelude/pkg/javadocs/resources/inherit.gif: Operation not permitted
The UC team will be running the overall scenario by the pkg(5) community
to see if there's some room for more flexibility to allow for at least
shared management when a common group ID is involved. Since I don't
believe that in general other adopters of pkg(5) for layered use will
want to give up ability to specify and manage file level permissions
capability, there might not be much that can be done at the pkg(5) level.
I doubt that NetBean's use of NBMs supports use of file level
permissions by package maintainers. If it did, it would have to deal
with the same fundamental issue. Eclipse's update infrastructure may be
similar in this respect.
Chris
>
> Ludo
>>
>> Installing as non-root from the get go would certainly avoid the issue
>> pkg(5) has with the combo of root ownership + non-root management. I
>> know, NetBeans doesn't have an issue with the combo as long as a
>> common group ID is in effect and permissions are proper, but pkg(5) is
>> different in that it attempts to actively manages file permissions
>> whereas NBM does not. More will be doc'd in the UC bug report.
>>
>> Chris
>>
>> Ludovic Champenois wrote:
>>> Hi,
>>>
>>> The latest nightly build (1.1.7) for GlassFish Tools Bundle For
>>> Eclipse 1.2 is now available.
>>>
>>> It contains:
>>>
>>> * Latest Eclipse 3.5.1 IDE with WTP Java EE support
>>> * JSF Facelet plugin (from the Eclipse incubator project) to help
>>> the JSF 2.0 developer
>>> * Latest GlassFish v3 Java EE 6 Build 74 pre-registered and configured
>>> * JavaDB sample database pre-registered and configured
>>> * GlassFish Plugin (1.0.41)
>>> * Java EE 5 and updated Java EE 6 Javadoc code completion in the
>>> Java Editor
>>> * MySQL JDBC driver registered to the IDE
>>> * Maven m2 plugins
>>> * JAX-WS Metro plugin
>>> * GlassFish documentation
>>> * And optionally, a JDK 1.6. update 16
>>>
>>>
>>> Get it from http://download.java.net/glassfish/eclipse/1.1.7/ and
>>> give us feedback. The stable 1.2 version will be available soon after
>>> the release of GlassFish Java EE 6 v3 release.
>>>
>>> The stable 1.1 version is still available at
>>> http://download.java.net/glassfish/eclipse
>>>
>>> Ludo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>