Re: [reposado] Reposado behind a firewall

[Jon Rhoades]

Hi Joe,

You just need to set the clients to use the internal Reposado server - see http://support.apple.com/kb/HT4069 for the various ways you can set this, in addition if you are using Munki, you can set it there.

Cheers Jon 

--
Jon Rhoades
Research Information Systems
Eastern Hill Academic Centre
(Incorporating The University of Melbourne Departments of Medicine, Surgery and Clinical School (St.Vincent's), St Vincent's Institute and O'Brien Institute)

---

From: "Joseph Chilcote" <chil...@gmail.com>
To: repo...@googlegroups.com
Sent: Tuesday, 26 March, 2013 9:07:41 AM
Subject: [reposado] Reposado behind a firewall

Is anyone running reposado to serve updates to machines that are firewalled off the internet? I've got all the pieces in place, except the clients still query http://swpost.apple.com/stats on port 443. Is there a way to deliver the functionality of that call within reposado?

--joe

--
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/groups/opt_out.
 
 

[Joseph Chilcote]

Hi Jon.

Thank you for the response.  I have reposado configured and providing updates.  That's not the issue. The issue is I have segments of my user population who operate labs which are segregated behind a firewall and not given access to the wild wild west internet.  When they run software update, the process stalls while attempting to connect with swpost.apple.com over port 443.  That's the piece I'm trying to fix. I'd like to avoid using Apple's SUS for the simple reason that I wish to not use Apple hardware to provide services.  However, I'm testing that as an alternative and differentiator at the moment.

Here are the connections being made when I run software update against my reposado server. Note the connection to Apple in red. This is the point of failure.

2371   softwareupdate   2   <my_reposado_ip>   80          69 In progress

2371   softwareupdate   2   <my_reposado_ip>   80          61 In progress

2371   softwareupdate   2   <my_reposado_ip>  80          62 In progress

2371   softwareupdate   2   17.146.232.25    443         56 In progress

Cheers,

--joe

[Greg Neagle]

On Mar 26, 2013, at 9:38 AM, Joseph Chilcote <chil...@gmail.com> wrote:

Hi Jon.

Thank you for the response.  I have reposado configured and providing updates.  That's not the issue. The issue is I have segments of my user population who operate labs which are segregated behind a firewall and not given access to the wild wild west internet.  When they run software update, the process stalls while attempting to connect with swpost.apple.com over port 443.  That's the piece I'm trying to fix. I'd like to avoid using Apple's SUS for the simple reason that I wish to not use Apple hardware to provide services.  However, I'm testing that as an alternative and differentiator at the moment.

Is behavior different with Apple's SUS? If so, what do they connect to? What is the response? If clients are truly attempting to connect to http://swpost.apple.com/stats:443, I don't see how Apple's SUS would provide different behavior.

-Greg

[Stephan Peterson]

I wonder if the connection to http://swpost.apple.com/stats:443 is truly necessary. I'm curious what would happen if you modified /etc/hosts to just send that to localhost.

Stephan

[Greg Neagle]

I'm guessing the solution might be to rewrite the ApplePostURl in each catalog:

<?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>ApplePostURL</key>

<string>http://swpost.apple.com/stats</string>

But to _what_, and what sort of service might be needed at that URL?

Anyone care to tackle this?  Joe?

-Greg

[Joseph Chilcote]

Turns out it was a problem with documentation.  The lab manager was testing with `softwareupdate -l CatalogURL <link>`, without, you'll note, the correct ("--") flag before CatalogURL. Updated the document, and software update is happily ignoring this firewalled outbound call to apple. 

The offending documenter has been publicly humiliated and relieved of duty. 

--joe