Adobe Remote Update Manager

[Christopher Grande]

New tool from Adobe - http://labs.adobe.com/downloads/aameetools.html

A tool that provides command line access to install Adobe updates either by contacting Adobe directly or your own Adobe Update Server.

Maybe something munki can connect into?

[Greg Neagle]

As the tool currently stands, I don't see a clean way to integrate it with Munki.

Its current functionality is the rough equivalent of `softwareupdate -ia`.

There's no way to get a list of available updates.
There's therefore no way to tell the user what is about to happen.
There's therefore no way to get the user to quit applications that will be updated.

For machines that spend a significant time at the loginwindow, I suppose Munki could run the RemoteUpdateManager and tail/parse its log for progress info. But that's not real integration.

-Greg

[Timothy Sutton]

RUM needs to be copied to the machine and run manually in order for it to query the server (Adobe's or yours) and download/install the relevant updates.

Invoking it via Munki isn't something Munki is really suited to. It might be possible to write a LaunchDaemon to run only the context of the loginwindow and on a schedule where you know a machine will be unoccupied during some window in time.

Most of the CS apps have been ok with updates recently, but there was at least one case with CS5 where following an update, an app would go into an update loop requiring admin rights until an obscure file within its installation was created to suppress the behaviour. I wouldn't want this situation happening without being able to first test the updates myself in the same configuration.


I suppose you could also roll your own automatic-update-downloader-and-munkiimport'er tool with RUM, however it's only going to check for updates that can apply against CS apps that on the machine, and the form those updates come in might not be exactly the same as those you download (similar to how Apple's updates work with SUS)

RUM also currently writes its logs to the Library/Logs folder of the user running it, which isn't very useful in an administrative context.


-Tim

[Greg Neagle]

I think it would be very useful if Munki could run this and update Adobe CS5-CS6 applications; it would serve a similar need as having Munki run Apple's softwareupdate on each machine.

But as I said in an earlier post, I think as the tool currently works it would not cleanly integrate with Munki.

-Greg

[Bernstein, Gary]

I haven't looked very closely at it, but could it be run as part of a postinstall?
-Gary

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- "The reward for work well done is the opportunity to do more."

-- "I tried, but it didn't work" is a lot better than "I wish I'd tried."

Gary R. Bernstein
Interim Assistant Director of FAA IT Services
College of Fine and Applied Arts
University of Illinois - Urbana-Champaign
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

[immoral]

Hi All

Anyone have an idea which SUS catalog to use in OS X Server 10.7.4 to facilitate Munki running OS updates for Lion and SnowLeopard? Since the update the catalogs have changed as has the location/s.

I've had a crack a a few but to no avail. The logs suggest using symbolic links is an issue but a bunch of catalogs are now nested another level or two deeper and the Lion catalogs seem to be aliased back to the html root folder. I'm guessing that's the symbolic links it's moaning about.

In essence the Apple SUS structure seems to have changed and i'm not sure how to respond. All worked before then I guess I broke it with an update.

I know it's not strictly a Munki question but i'm struggling to find answers elsewhere.

Regards

Tristan

[Greg Neagle]

The layout of Apple software update catalogs have not changed since Leopard; Apple just adds a new one for each major OS release.

The only configuration that always works, no matter the configuration or version of the software update server, is to point each client to the specific software update catalog for its OS version.

Tiger: http://swscan.apple.com/content/catalogs/index-1.sucatalog
Leopard: http://swscan.apple.com/content/catalogs/others/index-leopard.merged-1.sucatalog
Snow Leopard: http://swscan.apple.com/content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog
Lion: http://swscan.apple.com/content/catalogs/others/index-lion-snowleopard-leopard.merged-1.sucatalog
Mountain Lion: http://swscan.apple.com/content/catalogs/others/index-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog

Substitute the base URL for your internal SUS as needed:

http://myinternalsus.example.org:8088/content/catalogs/others/index-lion-snowleopard-leopard.merged-1.sucatalog

If you are running Apple's software update service on OS X Server 10.6.6 or later, you can get away with a "unified" catalog URL, but I won't go into that here.

-Greg

[immoral]

Thanks for the clarification Greg. I'll point my machines to the Lion flavor then. They were pointing to Snow and still working but that stopped working when I updated to 10.7.4.

Regards

Tristan

[Greg Neagle]

You should point your _Lion_ machines to the Lion sucatalog, and your Snow Leopard machines to the Snow Leopard sucatalog.

Sent from my iPhone

[immoral]

maybe I should clarify with a brief history which may point to the current situation (experienced Munki/SUS users may find a flaw or two, please feel free to point them out...)

I had a Snow Leopard X Serve running Apple SUS and Munki (0.8.1.1). All my clients were/are running Lion. I had Managed Installs pointing to index-snowleopard-leopard.merged-1.sucatalog and this worked fine (well it appeared to as it was handing out Apple updates). I used this catalog as it was in the setup documents in the forum and was in the repo on snow leopard server. and yes, i don't have a sound knowledge of Apple SUS so winging it but it worked. we live and learn...

I updated the Xserve to Lion (looking to bring it in line with the clients). This too worked (ok appeared to work fine) too with no change to the catalog.

I update the Xserve to 10.7.4 and it all stops working. I see I should have used the Lion catalog but didn't look for a change in catalogs to reflect Lion. My bad.

My clients are still running 0.8.1.1 Munki.

My repo is on another drive on the Xserve storing updates in /Volume/DriveName/SUS Repo/ correct? no deeper to the html directory/other directory?

Looking at the swupd structure in /var/db/ i see that it is different to the structure in my repo which may be an issue. i have rebuilt my repo but it still differs.

it's sunny outside with a moderate but stable wind. perfect for kite flying but i digress...

regards

tristan

[immoral]

pointed it to the internal repo. stopped throwing an error. started working. no other change. oddness. more testing.

[immoral]

last post... changed to lion catalog and using internal repo. works as expected for some of the updates. close.

[Ted August]

Apologies on re-opening a two month old thread, but I have also been thinking about how to integrate AUS, RUM, and Munki. My first "quick & dirty" idea is to deploy a payload free package using Munki that runs a postflght script that starts the RUM utility. I would imagine that the script wouldn't exit until the RUM is done downloading and installing updates. I envision sending out a different version of the package whenever I want to force clients to run updates from the server, and it still takes advantage of the Munki backend for execution.

Thoughts? I'm guessing there are probably better ways to do this...

-Ted

[Hugh Burt]

I have found this useful for our lab machines and this is what I have cobbled together. I made a package with Iceberg which Munki installs on the clients.  The package is simply the Remote Update manager folder and its associated files which goes into the Utilities folder. The pkginfo file has a post install script which runs the shell script. <key>postinstall_script</key>          <string>#!/bin/sh  /Applications/Utilities/Remote\ Update\ Manager/InstallRUMManPage.sh        </string>  Then, with ARD, I put a launchdaemon file into /Library/Launchdaemons which calls the utility at 08:00 hrs. <dict> <key>Label</key> <string>com.adoberemoteupdater</string> <key>ProgramArguments</key> <array> <string>/Applications/Utilities/Remote Update Manager/RemoteUpdateManager</string> </array> <key>StartCalendarInterval</key> <dict> <key>Hour</key> <integer>8</integer> </dict> </dict> I suppose I could have added the launchdaemon to the package so Munki adds it as well. ----------------------------------------------------------------------- “Weaseling out of things is important to learn. It’s what separates us from the animals.....except the weasel” ~ Homer Simpson --- On Fri, 27/7/12, Ted August <taugust...@gmail.com> wrote: