Oracle Java 7 pkginfo

[Timothy Sutton]

Just thought I'd share a pkginfo for Oracle's Java 7, which adds the setting to suppress update checks to a system-wide location for all users.

You may want to push this setting with a file in an extra package instead of using a postinstall_script, but it's here as an example of how to disable the Java updater, because I couldn't actually find any documentation of the /L/Application Support/Oracle/Java directory as a system-wide config location. It still seems to do an update check whenever the control panel is opened, but maybe there's another option to disable that behaviour. It at least unchecks the checkbox.

-Tim


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>autoremove</key>
<false/>
<key>catalogs</key>
<array>
<string>testing</string>
</array>
<key>description</key>
<string></string>
<key>display_name</key>
<string>Java 7 Update 09</string>
<key>installed_size</key>
<integer>145400</integer>
<key>installer_item_hash</key>
<string>39aceacaf7739ba2f34073d2e8d2884e34bbef7d9206810305ba13633a5ced82</string>
<key>installer_item_location</key>
<string>support/Java/jre-7u9-macosx-x64.dmg</string>
<key>installer_item_size</key>
<integer>51249</integer>
<key>installs</key>
<array>
<dict>
<key>CFBundleShortVersionString</key>
<string>1.7.09.05</string>
<key>path</key>
<string>/Library/Internet Plug-Ins/JavaAppletPlugin.plugin</string>
<key>type</key>
<string>bundle</string>
</dict>
</array>
<key>minimum_os_version</key>
<string>10.5.0</string>
<key>name</key>
<string>JavaOracle</string>
<key>postinstall_script</key>
<string>#!/bin/sh
JAVADIR=/Library/Application\ Support/Oracle/Java/Deployment
if [ ! -d "$JAVADIR" ]; then
/bin/mkdir -p "$JAVADIR"
fi

/bin/echo "deployment.macosx.check.update=false" > "$JAVADIR/deployment.properties"
</string>
<key>receipts</key>
<array>
<dict>
<key>installed_size</key>
<integer>145400</integer>
<key>packageid</key>
<string>com.oracle.jre</string>
<key>version</key>
<string>1.0</string>
</dict>
</array>
<key>uninstall_method</key>
<string>removepackages</string>
<key>uninstallable</key>
<true/>
<key>version</key>
<string>1.7.09.05</string>
</dict>
</plist>

[Hannes Juutilainen]

Thanks for sharing!

--
Hannes

[Timothy Sutton]

I missed the fact that Apple's JavaAppletPlugin.plugin bundle has a higher CFBundleShortVersion string than Oracle's, so Munki won't try to install this if Apple's plugin is already present.

Oracle's binary for the plugin is a symlink that points to a .dylib, so I've added this entry to my installs array:

<dict>
<key>md5checksum</key>
<string>c23e38a91738f641316835897eb4839a</string>
<key>path</key>
<string>/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/libnpjp2.dylib</string>
<key>type</key>
<string>file</string>
</dict>


-Tim

[Harry Fike]

Did you leave the entry for CFBundleShortVersionString from your original example, or did you just replace it with the md5checksum entry?

Thanks,

Harry

[Timothy Sutton]

I left it for my own reference, but this shouldn't change the behaviour. Munki will trigger an install if _any_ item from an installs array isn't satisfied.

-Tim

[Harry Fike]

Thanks for the update. I was scratching my head for a while yesterday trying to figure out why it kept telling me the update was already installed.

-- 

Harry

[Peter]

@Timothy

Thanks for sharing but i can get it to work (don't show up in Munki) (import without changes gives no problem in Munki) two questions

1) Where can i found the MD5 checksum (i think that this gives the problem not showing up)

2) can you post your Oracle Java 7 pkginfo so i can check with mine

thanks

Peter

Op vrijdag 19 oktober 2012 23:38:21 UTC+2 schreef Timothy Sutton het volgende:

[Timothy Sutton]

Hi Peter,

On 2012-10-26, at 5:49 AM, Peter <macst...@gmail.com>
wrote:

> @Timothy
>
> Thanks for sharing but i can get it to work (don't show up in Munki) (import without changes gives no problem in Munki) two questions
>
> 1) Where can i found the MD5 checksum (i think that this gives the problem not showing up)

makepkginfo -f will try to build an installs item from a file. If it's not a 'bundle' (ie. an .app, .plugin, or something containing metadata at Contents/Info.plist), it will build an MD5 of the file instead.

So:

makepkginfo -f "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/libnpjp2.dylib"

> 2) can you post your Oracle Java 7 pkginfo so i can check with mine

You can just substitute the <dict> entry in the installs array with the <dict> I posted later that uses md5checksum. Each <dict> is one "installs" item, and because the md5checksum method is the most specific ("require this file _exactly_") you only really need that to determine the Oracle plugin is installed.

I'm not yet using this in production, just FYI (need to further test internal-use web apps that require Java).


-Tim

[Peter]

Thanks for info, figure it out had an <array> between the </dict> testing it now seems to work perfect.

Op vrijdag 19 oktober 2012 23:38:21 UTC+2 schreef Timothy Sutton het volgende:

Just thought I'd share a pkginfo for Oracle's Java 7, which adds the setting to suppress update checks to a system-wide location for all users.

[Harry Fike]

Here are the steps I took to deploy it:

1. I ran munkiimport on the package downloaded from Oracle (jre-7u11-macosx-x64.dmg), up until it opens the pkginfo, before it remakes the catalogs.

2. I installed the package manually on a test machine that had previously been running version 7u9.

3. After installation I ran an md5 checksum on the file libnpip2.dylib that Tim had pointed out earlier: md5 /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/libnpjp2.dylib

3. I copied and pasted that md5 checksum into the open pkginfo.

4. I opened /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Enabled.plist and looked for the key CFBundleVersion. I copied this string to CFBundleShortVersion in the pkginfo.

5. Saved the pkginfo and remade the catalogs.

*I did edit Tim's original pkginfo to remove the receipt since it did not reflect the actual version number and it was moot as there is an installs array.

This is what my pkginfo looks like:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>autoremove</key>

<false/>

<key>catalogs</key>

<array>

<string>production</string>

</array>

<key>description</key>

<string>Installs the Java Plugin</string>

<key>display_name</key>

<string>Java 7 Update 11</string>

<key>installed_size</key>

<integer>146436</integer>

<key>installer_item_hash</key>

<string>089410645d13b2dd9e6e1551cc7ea0e74d4a26c4f5d50eb7f8a780ff25ac8b71</string>

<key>installer_item_location</key>

<string>Apps/Oracle/jre-7u11-macosx-x64.dmg</string>

<key>installer_item_size</key>

<integer>51532</integer>

<key>installs</key>

    <array>

        <dict>

        <key>CFBundleShortVersionString</key>

            <string>1.7.11.21</string>

            <key>path</key>

            <string>/Library/Internet Plug-Ins/JavaAppletPlugin.plugin</string>

            <key>type</key>

            <string>bundle</string>

        </dict>

        <dict>

        <key>md5checksum</key>

            <string>4536d18a9751c82417ce4f44cc33b568</string>

            <key>path</key>

            <string>/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/libnpjp2.dylib</string>

            <key>type</key>

            <string>file</string>

        </dict>

    </array>

<key>minimum_os_version</key>

<string>10.7.3</string>

<key>name</key>

<string>Oracle Java</string>

<key>postinstall_script</key>

    <string>#!/bin/sh

JAVADIR=/Library/Application\ Support/Oracle/Java/Deployment

if [ ! -d "$JAVADIR" ]; then

        /bin/mkdir -p "$JAVADIR"

fi

/bin/echo "deployment.macosx.check.update=false" > "$JAVADIR/deployment.properties"

</string>

<key>unattended_install</key>

<true/>

<key>uninstall_method</key>

<string>removepackages</string>

<key>uninstallable</key>

<true/>

<key>version</key>

<string>1.7.11.21</string>

</dict>

</plist>

Someone also posted a version that incorporates a different way to disable the updater: https://gist.github.com/f2c87d873cbeaa90d3cd

-- 

Harry

[Samuel Keeley]

This method of disabling the updater is really only valid for Oracle's initial release of Java 7 for Mac - version 7u9.  It now needs the LaunchAgent and LauchDaemon to be disabled and the symlinks removed.

The pkginfo you linked to, https://gist.github.com/f2c87d873cbeaa90d3cd, is the one I posted.

-sam

--
Samuel Keeley

[Harry Fike]

Thanks! I'll definitely integrate that into my pkginfo. I saw it being talked about on the irc channel, but didn't catch the whole conversation.

-- 

Harry

[Gregory Neagle]

On Jan 14, 2013, at 1:44 PM, Harry Fike <hfi...@gmail.com> wrote:

Here are the steps I took to deploy it:

1. I ran munkiimport on the package downloaded from Oracle (jre-7u11-macosx-x64.dmg), up until it opens the pkginfo, before it remakes the catalogs.

2. I installed the package manually on a test machine that had previously been running version 7u9.

3. After installation I ran an md5 checksum on the file libnpip2.dylib that Tim had pointed out earlier: md5 /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/libnpjp2.dylib

Better to do /usr/local/munki/makepkginfo -f /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/libnpjp2.dylib

3. I copied and pasted that md5 checksum into the open pkginfo.

4. I opened /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Enabled.plist and looked for the key CFBundleVersion. I copied this string to CFBundleShortVersion in the pkginfo.

Better to do /usr/local/munki/makepkginfo -f /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin

Always use makepkginfo -f to generate new/updated installs items.

[Harry Fike]

So I didn't install the 7u10 Java update, which caused the preinstall script from Sam (https://gist.github.com/f2c87d873cbeaa90d3cd) to fail. I modified the preinstall to check for the existance of the LaunchAgent and LaunchDaemon:

<key>preinstall_script</key>

<string>#!/bin/sh

 

if [ -s /Library/LaunchAgents/com.oracle.java.Java-Updater.plist ]; then

launchctl load -w /Library/LaunchAgents/com.oracle.java.Java-Updater.plist

elif [ -s /Library/LaunchDaemons/com.oracle.java.Helper-Tool.plist ]; then

launchctl load -w /Library/LaunchDaemons/com.oracle.java.Helper-Tool.plist

fi

</string>

Does that make sense or am I missing something. Munki installed it after that modification, however, I'm not sure how "if [ -s" handels symlinks.

Thanks,

Harry

[Joe Wollard]

-s just makes sure the file is not zero bytes in size. A symbolic link is generally going to be at least a few bytes in size, so it should still work. Although you might want to use -e instead, just to see if the file exists.

http://tldp.org/LDP/abs/html/fto.html 

Thanks,

Harry

[Peter]

Harry did your script adjustment work?

greetings

Peter

Op vrijdag 18 januari 2013 18:46:27 UTC+1 schreef Harry Fike het volgende:

[Harry Fike]

Peter,

So far so good. I have not seen any cases of it failing. I did change the script to check to see if the file exists (-e) instead of checking to see if it was not 0 bytes (-s), as Joe Wollard suggested.

-- 

Harry

[Joseph Rafferty]

Maybe this is just my Friday evening brain speaking, and I also am
sure there has been discussion on this (couldn't find it), but....

How are users installing over Apple's Java 1.6, which has a bundle
version of 13.8.5 (in the case of a 10.6.8 machine I'm currently
looking at)? I was considering using an installcheck_script to read
this value, and passing if it was greater than 10.0.


On Wed, Jan 30, 2013 at 8:10 AM, <si...@ifixit.no> wrote:
> Something I wrote today to fix the package instead of doing custom version
> testing:
>
> #!/bin/bash
>
> PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec/:/usr/local/bin/
> export PATH
>
> WORKDIR=/tmp/modpkg-`date +%s`
> OUTDIR=`dirname "$1"`/modpkg
> PKGNAME=`basename "$1"`
>
> pkgutil --expand "$1" "$WORKDIR"
>
> # EDIT US
> VERSION=$2
> perl -pi -e 's/(identifier=\"com\.oracle\.jre\"
> version=\")([^\"]*)(\")/${1}'$VERSION'${3}/'
> "$WORKDIR"/javaappletplugin.pkg/PackageInfo
>
> mkdir "$OUTDIR"
> pkgutil --flatten "$WORKDIR" "$OUTDIR"/"$PKGNAME"
> rm -r $WORKDIR
>
> Copy/paste to a file and call it whatever, mine is currently named
> java-applet.sh
>
> Then:
>
> chmod +x java-applet.sh
>
> Then:
>
> ./java-applet.sh /Users/simen/Downloads/Java\ 7\ Update\ 11.pkg 7.11
>
> We send the package as argument 1 and the wanted version as argument 2. The
> script will then make a modified/fixed version of the pkg to the same folder
> as the original inside a folder called modpkg.
>
> Use it if you want to :) Easy to modify new versions when they get released.
>
> Best wishes, Simen

> --
> You received this message because you are subscribed to the Google Groups
> "munki-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to munki-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Timothy Sutton]

The installs key entry for the libnpjp2.dylib file is how it's done, as shown in the pkginfo posted earlier in this thread.

By specifying that this file is installed and using md5checksum, then it requires that _exactly_ that file must be present, rather than using the "highest CFBundleShortVersionString" method used for applications, bundles, etc.

Disclaimer, I'm not yet deploying Java 7 (although given that Apple's probably not going to make an updated version of 6 for 10.7+ I probably will be very soon..). I believe others (Sam Keeley for one) have been using this pkginfo recipe successfully, however.


-Tim

[Josh Malone]

I just noticed that the 1.7.0_13 update installs a prefpane with a corresponding CFBundleShortVersion that allows munki to detect the upgrade from old Apple-installed Java -- at least, in my environment:

        <key>installs</key>
        <array>
                <dict>
                        <key>CFBundleShortVersionString</key>

                        <string>1.7.13.20</string>

                        <key>path</key>
                        <string>/Library/Internet Plug-Ins/JavaAppletPlugin.plugin</string>
                        <key>type</key>
                        <string>bundle</string>
                </dict>
                <dict>

                        <key>CFBundleShortVersionString</key>
                        <string>1.7.0_13</string>
                        <key>path</key>
                        <string>/Library/PreferencePanes/JavaControlPanel.prefPane</string>

                        <key>type</key>
                        <string>bundle</string>
                </dict>

        </array>

This seems to work on my test machines so that munki upgrades Apple-installed Java and won't attempt to downgrade users who have upgraded on their own. I'll be deploying this soon.

-Josh

[EG]

The preference pane has been there I believe since the initial version. I never paid attention to it's CFB though. I'm going to add that to my pkginfo.

[Jeremy Reichman]

For this previously posted preinstall script:

<key>preinstall_script</key>

<string>#!/bin/sh

 

if [ -s /Library/LaunchAgents/com.oracle.java.Java-Updater.plist ]; then

launchctl load -w /Library/LaunchAgents/com.oracle.java.Java-Updater.plist

elif [ -s /Library/LaunchDaemons/com.oracle.java.Helper-Tool.plist ]; then

launchctl load -w /Library/LaunchDaemons/com.oracle.java.Helper-Tool.plist

fi

</string>

I believe you'd want to make separate "if" statements so that both will be run if either just the first or just the second clause from the posted original match. You can also use -h to test for symlinks directly, which I've find handy to know.

if [ -h /Library/LaunchAgents/com.oracle.java.Java-Updater.plist ]; then

launchctl load -w /Library/LaunchAgents/com.oracle.java.Java-Updater.plist

fi

if [ -h /Library/LaunchDaemons/com.oracle.java.Helper-Tool.plist ]; then

launchctl load -w /Library/LaunchDaemons/com.oracle.java.Helper-Tool.plist

fi

--

Jeremy

On Feb 4, 2013, at 10:04 AM, EG <eriknico...@gmail.com> wrote:

The preference pane has been there I believe since the initial version. I never paid attention to it's CFB though. I'm going to add that to my pkginfo.

[Harry Fike]

Thanks for the info. For some reason I had to separate if statements in the first test I did and can't remember the logic as to why I used an elif in the final one. The original documentation I referenced didn't mention -h, but a little more digging does. Thanks for the heads up on that!

-- 

Harry

[Jeremy Reichman]

Sam's pkginfo at  https://gist.github.com/f2c87d873cbeaa90d3cd included a postinstall_script line that creates a file.

/bin/echo "deployment.macosx.check.update=false" &gt; "$JAVADIR/deployment.properties"

I'm personally not a fan of creating or manipulating files via a package or pkginfo script if I can help it. In this case, for those interested, it is possible to create your deployment.properties file separately and then package it for deployment (with a tool like Luggage). It's a small thing and it arguably creates a little more work, but we tend to hate when vendors do these kinds of things (at least in packages).

The file would need to be packaged rather than handled with copy_from_dmg because it goes into /Library/Application\ Support/Oracle/Java/Deployment, and that folder path isn't created with copy_from_dmg.

--

Jeremy

[John Lockwood]

I am now hitting this issue of Java not being updated via Munki properly. Unfortunately it seems Oracle may have changed the version strings again.

What is the current simplest working solution that will allow deploying Java 1.7 and updates to Java 1.7 via Munki. I am not concerned about disabling Java updating itself unless that is necessary to stop it breaking any further Munki derived updates.

By the way a pox on Oracle for causing this stupid problem in the first place. For goodness sake even Microsoft are better than this!

[Timothy Sutton]

Simplest working solution? Use AutoPkg, and use the OracleJava7.munki recipe:

https://github.com/autopkg/recipes/tree/master/OracleJava


Oracle hasn't changed anything in their version "methodology" on the Mac installer since they began releasing Java 7 and Java 8. It's not a very good one, but it's been consistent. Figuring out a good pkginfo for Oracle Java plugins proved problematic for people, hence the AutoPkg recipe.


Tim

> --
> You received this message because you are subscribed to the Google Groups "munki-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[John Lockwood]

It looks like with Java JRE 8 update 40, Oracle have finally started using a proper version string in it.

I just added it to my repo and it now shows a full version string, JRE 8 update 31 still had the old fubar 1.0 version string.

In case anyone has not noticed supposedly public updates for JRE 7 will cease in April this year so it is time to start moving to JRE 8 if you have not yet already done so.

[Timothy Sutton]

Mine doesn't:

<key>receipts</key>
<array>
<dict>
<key>installed_size</key>

<integer>164180</integer>

<key>packageid</key>
<string>com.oracle.jre</string>
<key>version</key>
<string>1.0</string>
</dict>
</array>

The pkginfo I have generated from AutoPkg has a proper version, but that's because the AutoPkg recipe does that part:

<key>version</key>
<string>1.8.40.25</string>



Tim

[John Lockwood]

I downloaded the update via MacUpdate in this case, and added it to my repo via MunkiAdmin using the 2.2 Munki tools.

[Timothy Sutton]

Then you might not get what you were expecting.

Oracle changed from a basic flat package to an installer wrapper application that installs said package. The _application_ has sane version info, but you almost certainly don't want to deploy that - or at least not just as a straight drag-n-drop app.


Tim

[John Lockwood]

Yep dammit, your right.

[Rick Waller]

So, it appears Java 8's latest release is also an installer wrapper application.

When I try to run OracleJava8.munki.recipe        recipes              OracleJava/OracleJava8.munki.recipe   is choking up.

Do we know who has that munki package?  Or is there a way for me to fix this by chance?  The dmg is downloading, but since it isn't a flat package, it fails to complete properly.  

Just curious...  

Thanks!!!

[Gregory Neagle]

autopkg is not Munki. Even if this was an issue, it would not be a _Munki_ issue.

FWIW: I just ran the OracleJava8.munki.recipe without issue.

-Greg

[Tim Sutton]

Also: questions about AutoPkg can go to autopkg...@googlegroups.com.

Tim