"Couldn't communicate with helper application"??

856 views
Skip to first unread message

david koff

unread,
Aug 5, 2014, 7:58:44 PM8/5/14
to repo...@googlegroups.com
hey gang: i've set up a proof of concept instance of reposado and margarita. both are running nicely in OSX 10.9.4 Server. i'm able to create branches, add and delete items and manage via the GUI and command line. the catalogs created and stored in the /html/content/catalogs folder are available and readable in browsers from other machines on the network, showing the plists as expected. we don't have a FQDN yet (it's a proof of concept), so i'm using the IP of the server in the CatalogURL name. For eaxmple: 111.222.333.444:8088/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog. 

after modifying the CatalogURL via the defaults command and verifying we've got the correct URL, i run software update from both the GUI and command line. the test computers all connect and then.... error out with: "Service connection interrupted! Couldn’t communicate with a helper application."

as i haven't seen that error much and don't see it mentioned much online, i thought i'd ask the greg & the group for any clarification. mostly, i want to confirm the error has nothing to do with my set up. 


our pref file is as follows:
<?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>LocalCatalogURLBase</key>
<string>111.222.333.444</string>
<key>UpdatesMetadataDir</key>
<string>/SuS/meta</string>
<key>UpdatesRootDir</key>
<string>/SuS/html</string>
<key>RepoSyncLogFile</key>
<string>/var/log/ReposadoSync.log</string>
</dict>
</plist>

Gregory Neagle

unread,
Aug 5, 2014, 8:01:20 PM8/5/14
to repo...@googlegroups.com
On Aug 5, 2014, at 4:58 PM, david koff <davi...@gmail.com> wrote:

hey gang: i've set up a proof of concept instance of reposado and margarita. both are running nicely in OSX 10.9.4 Server. i'm able to create branches, add and delete items and manage via the GUI and command line. the catalogs created and stored in the /html/content/catalogs folder are available and readable in browsers from other machines on the network, showing the plists as expected. we don't have a FQDN yet (it's a proof of concept), so i'm using the IP of the server in the CatalogURL name. For eaxmple: 111.222.333.444:8088/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog. 

after modifying the CatalogURL via the defaults command and verifying we've got the correct URL, i run software update from both the GUI and command line. the test computers all connect and then.... error out with: "Service connection interrupted! Couldn’t communicate with a helper application."

as i haven't seen that error much and don't see it mentioned much online, i thought i'd ask the greg & the group for any clarification. mostly, i want to confirm the error has nothing to do with my set up. 


our pref file is as follows:
<?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>LocalCatalogURLBase</key>
<string>111.222.333.444</string>

That's not a URL, that's an IP address. You want something like


david koff

unread,
Aug 6, 2014, 12:37:08 PM8/6/14
to repo...@googlegroups.com

My apologies, Greg:

I omitted the full story: I'd included the http prefix initially and gotten a different error message which returns when I put it back:

dkoff$ softwareupdate -l
Software Update Tool
Copyright 2002-2012 Apple Inc.
Finding available software
unsupported URL

Currentlly the plist is set to:

dkoff$ defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist

{
AutomaticCheckEnabled = 1;
CatalogURL = "http://10.216.220.203:8088/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog";
LastAttemptSystemVersion = "10.9.4 (13E28)";
LastRecommendedUpdatesAvailable = 0;
LastResultCode = 100;
LastSessionSuccessful = 1;
LastUpdatesAvailable = 0;
PrimaryLanguages = (
en
);
RecommendedUpdates = (
);
SkipLocalCDN = 0;
}

As before, if I drop that same URL into any browser, it pulls up the catalog.

Gregory Neagle

unread,
Aug 6, 2014, 12:40:06 PM8/6/14
to repo...@googlegroups.com
On Aug 6, 2014, at 9:37 AM, david koff <davi...@gmail.com> wrote:


My apologies, Greg:

I omitted the full story: I'd included the http prefix initially and gotten a different error message which returns when I put it back:

dkoff$ softwareupdate -l
Software Update Tool
Copyright 2002-2012 Apple Inc.
Finding available software
unsupported URL

Currentlly the plist is set to:

dkoff$ defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist

{
AutomaticCheckEnabled = 1;
CatalogURL = "http://10.216.220.203:8088/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog";
LastAttemptSystemVersion = "10.9.4 (13E28)";
LastRecommendedUpdatesAvailable = 0;
LastResultCode = 100;
LastSessionSuccessful = 1;
LastUpdatesAvailable = 0;
PrimaryLanguages = (
en
);
RecommendedUpdates = (
);
SkipLocalCDN = 0;
}

As before, if I drop that same URL into any browser, it pulls up the catalog.


It pulls up a _file_, which may or may not be a valid software update catalog.

At this point I don't trust your configuration. Please post reposado's preferences without editing them. If you don't want them on a public list, mail them to me privately.

-Greg



 
That's not a URL, that's an IP address. You want something like



<key>UpdatesMetadataDir</key>
<string>/SuS/meta</string>
<key>UpdatesRootDir</key>
<string>/SuS/html</string>
<key>RepoSyncLogFile</key>
<string>/var/log/ReposadoSync.log</string>
</dict>
</plist>


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

david koff

unread,
Aug 6, 2014, 12:42:01 PM8/6/14
to repo...@googlegroups.com
Will also append the http prefix to the LocalCatalogURLBase entry in the reposado pref file and report back. 

david koff

unread,
Aug 6, 2014, 1:05:25 PM8/6/14
to repo...@googlegroups.com


<?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>LocalCatalogURLBase</key>
<string>xx.216.220.203</string>
<key>RepoSyncLogFile</key>
<string>/var/log/ReposadoSync.log</string>
<key>UpdatesMetadataDir</key>
<string>/SuS/meta</string>
<key>UpdatesRootDir</key>
<string>/SuS/html</string>
</dict>
</plist>

Gregory Neagle

unread,
Aug 6, 2014, 1:08:05 PM8/6/14
to repo...@googlegroups.com
On Aug 6, 2014, at 10:05 AM, david koff <davi...@gmail.com> wrote:

<?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>LocalCatalogURLBase</key>
<string>xx.216.220.203</string>

Again, as I pointed out before, this is NOT a url and will result in invalid catalog files.


Specify a valid URL fragment, usually of the format "http://xx.216.220.203"

Gregory Neagle

unread,
Aug 6, 2014, 1:15:58 PM8/6/14
to repo...@googlegroups.com
One more thing; after fixing reposado's preferences, you'll need to have reposado rebuild all the .sucatalog files: a repo_sync run should do it.

-Greg

david koff

unread,
Aug 6, 2014, 2:44:47 PM8/6/14
to repo...@googlegroups.com
ah!

i'd fixed the pref file by appending the http prefix and running softwareupdate -l on my client machines with the same results. but... i didn't re-do a repo-sync after changing that pref file. that's important. perhaps something to add to the documentation?

i will re run a reposync and report back. 

thanks, greg.

Gregory Neagle

unread,
Aug 6, 2014, 2:46:07 PM8/6/14
to repo...@googlegroups.com
On Aug 6, 2014, at 11:44 AM, david koff <davi...@gmail.com> wrote:

ah!

i'd fixed the pref file by appending the http prefix and running softwareupdate -l on my client machines with the same results. but... i didn't re-do a repo-sync after changing that pref file. that's important. perhaps something to add to the documentation?

The documentation does say that value should be a URL.

It's hard to predict every possible mistake someone might make and then the recovery for each possible mistake.

david koff

unread,
Aug 6, 2014, 2:50:10 PM8/6/14
to repo...@googlegroups.com
yes, you can't predict every mistake others will make.
no, i wasn't suggesting you alter the documentation about a valid URL as it is clear.
yes, i *was* suggesting that you alter the doc to include the part about a repo_sync being required if you change the LocalCatalogURLBase.

Gregory Neagle

unread,
Aug 6, 2014, 2:51:21 PM8/6/14
to repo...@googlegroups.com
On Aug 6, 2014, at 11:50 AM, david koff <davi...@gmail.com> wrote:

yes, you can't predict every mistake others will make.
no, i wasn't suggesting you alter the documentation about a valid URL as it is clear.
yes, i *was* suggesting that you alter the doc to include the part about a repo_sync being required if you change the LocalCatalogURLBase.

There might be other changes that require a repo_sync. Anything that would change what is synced and the created catalogs might require a new repo_sync.

david koff

unread,
Aug 6, 2014, 6:20:35 PM8/6/14
to repo...@googlegroups.com
There might be other changes that require a repo_sync. Anything that would change what is synced and the created catalogs might require a new repo_sync.
Copy that. I'll update my own docs to better remember this in the future. 

 
Based on your suggestion, I've edited the server prefs and re-run repo_sync and it fixed the URL issue, thank you. However, now when I call softwareupdate from CLI or GUI, I'm getting a different error: "The operation couldn’t be completed. (NSURLErrorDomain error -1100.)". 

Catalogs for each of three branches are live and can be viewed in a client browser. If the catalog is EMPTY (and one of them is currently) the softwareupdate request works and returns: "No new software available." So I'm guessing that the software is working. But if I then add even just one patch into the empty branch, it goes back to showing the NSURLErrorDomain error. 

Out of curiosity, running softwareupdate -i from CLI runs and returns no errors. 










Greg Neagle

unread,
Aug 6, 2014, 6:26:12 PM8/6/14
to repo...@googlegroups.com
On Aug 6, 2014, at 3:20 PM, david koff <davi...@gmail.com> wrote:

There might be other changes that require a repo_sync. Anything that would change what is synced and the created catalogs might require a new repo_sync.
Copy that. I'll update my own docs to better remember this in the future. 

 
Based on your suggestion, I've edited the server prefs

I can't see them from here, so I cannot be sure you made appropriate changes.

and re-run repo_sync and it fixed the URL issue, thank you. However, now when I call softwareupdate from CLI or GUI, I'm getting a different error: "The operation couldn’t be completed. (NSURLErrorDomain error -1100.)". 

Catalogs for each of three branches are live and can be viewed in a client browser. If the catalog is EMPTY (and one of them is currently) the softwareupdate request works and returns: "No new software available." So I'm guessing that the software is working. But if I then add even just one patch into the empty branch, it goes back to showing the NSURLErrorDomain error. 

This implies to me you still have a configuration problem.

http://gist.github.com would be a good place to share your configuration and sucatalogs. An sucatalog containing a single product that demonstrates the issue should be sufficient.


Out of curiosity, running softwareupdate -i from CLI runs and returns no errors. 


Sure. It has nothing to do.

Correct syntax is:

softwareupdate -ia

or

softwareupdate -ir

or

softwareupdate -i item1 [item2 ...]

-Greg

david koff

unread,
Aug 6, 2014, 6:53:48 PM8/6/14
to repo...@googlegroups.com

I can't see them from here, so I cannot be sure you made appropriate changes.

repo prefs: 

<?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>LocalCatalogURLBase</key>
        <string>http://XXX.216.220.203</string>
        <key>RepoSyncLogFile</key>
        <string>/var/log/ReposadoSync.log</string>
        <key>UpdatesMetadataDir</key>
        <string>/SuS/meta</string>
        <key>UpdatesRootDir</key>
        <string>/SuS/html</string>
</dict>
</plist>

repo catalog for the pilot branch currently on server:

Gregory Neagle

unread,
Aug 6, 2014, 6:57:50 PM8/6/14
to repo...@googlegroups.com

david koff

unread,
Aug 6, 2014, 8:18:45 PM8/6/14
to repo...@googlegroups.com
they do not. to drill down a bit: permissions on the repo folder on the server (/SuS/html) are set to 755 down the folder tree, so all should be able to read/execute. 

Greg Neagle

unread,
Aug 6, 2014, 9:52:57 PM8/6/14
to repo...@googlegroups.com
That's your problem.

I don't know your web server configuration; it's not clear to me that apache/nginx/whatever is configured so that your document root is in /SuS/html. Put an index file in there are try to visit http://XXX.216.220.203/index.html

I think you've bit off too much at once...

Greg Neagle

unread,
Aug 6, 2014, 9:57:14 PM8/6/14
to repo...@googlegroups.com
Actually this also occurs to me:

You've said you are pointing your clients at


Yet your LocalCatalogURLBase is set to "http://XXX.216.220.203:

If your server is truly serving content at http://10.216.220.203:8088/...etc, your LocalCatalogURLBase should be "http://10.216.220.203:8088"

It must be the actual base URL, not something sorta kinda close.

-Greg

Ken Elliott

unread,
Aug 7, 2014, 1:23:28 AM8/7/14
to repo...@googlegroups.com
Do they exist on your server?
Is your repository up-to-date with Apple. (These updates were released a week ago)
run repo_sync

I’m thinking these paths are incorrect.
<key>UpdatesMetadataDir</key> 
<string>/SuS/meta</string> 
<key>UpdatesRootDir</key> 
<string>/SuS/html</string> 

I have reposado in a sub directory “reposado” on the web server. (i.e. not at the root)
I also have a test repository on an external disk which I connect to via Mac’s built in web server.
The working paths on the test repository are as follows.

<key>LocalCatalogURLBase</key>
<key>UpdatesMetadataDir</key>
<string>/Volumes/500GB/Web/Documents/reposado/metadata</string>
<key>UpdatesRootDir</key>
<string>/Volumes/500GB/Web/Documents/reposado/html</string>

In the above “Do these URLs work?" My paths end up being

As already mentioned if you change these paths you need to run repo_sync to update the repositories paths.

I think you've bit off too much at once...
Agreed.
Get reposado working as an update server,
before thinking about branches and margarita.

Regards Ken

david koff

unread,
Aug 8, 2014, 3:44:46 PM8/8/14
to repo...@googlegroups.com
i've gone back to retrace my steps based on your suggestions, thank you both greg and ken. i've removed all branches from the set up and removed margarita. i'm thinking the issue might lay with the differences between how i've set up the websites service on the server and the repo server settings. but i'm not sure. 

1) i set the websites service on mavericks server to serve 10.216.220.203/SuS/html as the root folder via port 8088
2) i set our repo server prefs to:

<?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>LocalCatalogURLBase</key>
        <string>10.216.220.203:8088/SuS/html</string>
        <key>RepoSyncLogFile</key>
        <string>/var/log/ReposadoSync.log</string>
        <key>UpdatesMetadataDir</key>
        <string>/SuS/meta</string>
        <key>UpdatesRootDir</key>
        <string>/SuS/html</string>
</dict>
</plist>

a sample index.html file placed in that UpdatesRootDir gets served up just fine when pointing a browser to: http://10.216.220.203:8088

entering the following catalogURL into a browser lists the full updates:

if i copy the full path listed for a sample pkg in that same catalog file, i get a "URL not found" error for: 10.216.220.203/SuS/html/content/downloads/42/47/031-00536/0e3xru4xatuj4v9wb0y113nirfvnz34v8d/CLTools_Executables.pkg

but if i remove the "/SuS/html" from the URL and enter the following, the same download works fine: 10.216.220.203:8088/content/downloads/42/47/031-00536/0e3xru4xatuj4v9wb0y113nirfvnz34v8d/CLTools_Executables.pkg

obviously, there's something going on there.

regarding the com.apple.Software.plist on my clients:

I get a "unsupported URL" error when i set the CatalogURL to:

and i get a "Can't load data from the Software Update server (10.216.220.203)." error when i set the CatalogURL to:

to be honest, my eyes are screwed up from trying to pinpoint what's going on at this point. 

they do not.Do they exist on your server?

Kris Lou

unread,
Aug 8, 2014, 5:27:31 PM8/8/14
to repo...@googlegroups.com
I think that your LocalCatalogURLBase is incorrect.




Gregory Neagle

unread,
Aug 8, 2014, 5:30:13 PM8/8/14
to repo...@googlegroups.com
On Aug 8, 2014, at 12:44 PM, david koff <davi...@gmail.com> wrote:

i've gone back to retrace my steps based on your suggestions, thank you both greg and ken. i've removed all branches from the set up and removed margarita. i'm thinking the issue might lay with the differences between how i've set up the websites service on the server and the repo server settings. but i'm not sure. 

1) i set the websites service on mavericks server to serve 10.216.220.203/SuS/html as the root folder via port 8088

If /SuS/html is the webserver's root folder, then the LocalCatalogURLBase is http://10.216.220.203:8088

2) i set our repo server prefs to:

<?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>LocalCatalogURLBase</key>
        <string>10.216.220.203:8088/SuS/html</string>

No possible way that is right.
There is no URL scheme there.

URLs always start with a URL scheme. Common URL schemes are http:, https:, file:, and so on.

Based on other things you've said here, I _think_ your LocalCatalogURLBase is http://10.216.220.203:8088

        <key>RepoSyncLogFile</key>
        <string>/var/log/ReposadoSync.log</string>
        <key>UpdatesMetadataDir</key>
        <string>/SuS/meta</string>
        <key>UpdatesRootDir</key>
        <string>/SuS/html</string>
</dict>
</plist>

a sample index.html file placed in that UpdatesRootDir gets served up just fine when pointing a browser to: http://10.216.220.203:8088

Which then confirms that your LocalCatalogURLBase is http://10.216.220.203:8088.


entering the following catalogURL into a browser lists the full updates:

if i copy the full path listed for a sample pkg in that same catalog file, i get a "URL not found" error for: 10.216.220.203/SuS/html/content/downloads/42/47/031-00536/0e3xru4xatuj4v9wb0y113nirfvnz34v8d/CLTools_Executables.pkg

but if i remove the "/SuS/html" from the URL and enter the following, the same download works fine: 10.216.220.203:8088/content/downloads/42/47/031-00536/0e3xru4xatuj4v9wb0y113nirfvnz34v8d/CLTools_Executables.pkg

obviously, there's something going on there.

Yes. You've entered the wrong thing for LocalCatalogURLBase. This should be the beginning part of the URLs for all the stuff that will be served by your web server. All URLs in the catalog will be constructed using this value as a base.


If you do not understand it, please ask for clarification.

david koff

unread,
Aug 25, 2014, 7:37:11 PM8/25/14
to repo...@googlegroups.com
yes, that did the trick, thank you. the missing URL prefix was the issue. not sure why i couldn't remember the prefix but thank you for setting me straight both greg and kris. 
Reply all
Reply to author
Forward
0 new messages