Due to the improved RCS performance (reduced load) of the “Patch Metadata Download” option on Patch Manager we implemented that model when we upgraded to Core-Sat (I think 5 years ago now). That option requires you to run the “Download Manager” which uses Apache resources instead of the CSDB resources. I must admit. I am not a big fan of this solution. I just wanted to share my experience, maybe I am overlooking something obvious. However, I had many support cases open for this in this past and I was only able to determine why we had such bad performance “out of the box” after learning a lot of Apache and the different options.

The “Download Manager” option requires a Patch Gateway, that will go out to the vendor and get the binaries. You need to pay special attention to these settings.

We have ~700 Streamline Sats that preload from our Full Service Satelitte servers. (typical). We preload the Apache patches just like we used to do when the binaries where in the CSDB.

First, the setting for “Time for which the binary is valid” in the Configuration, Distribution Settings. It by default is set to 7 days. My assumption was that after 7 days it would go upstream do a quick check and realized it already had the same file and re-stamp the date time. I was wrong, it actually downloads a fresh copy regardless if it already has a perfectly good file! This is how Apache works. That makes perfect sense of web servers with thousand of tiny files that can be easily refreshed. It does not make sense for 100 MB or greater patch binaries.

So imagine what happens when you are preloading 700 devices with say 10 GB of patches. Then every week it deletes the files and does it again!! Over and over. Complete breakdown of the process.

OK, I am not proud of this but to get around this we up the “Time for which the binary is valid” to 20 years (not a typo) on the patch gateway. We simply can’t have the file expire on all these remote locations.

Second, when you preload patches, you go against the upstream host only. There is no option to use COP. That make the flexibility of the product at a lot less and can’t use COP based bandwidth trotting.

There is no appevent reporting of patch preloads. There is not even a local “radstate” type file, you have to look in the log to if you had failures.

On the preload process there is a one hour download timeout per file!! So, if you were on a slow link with a big file, even if it was working just fine, the preload process will actually just give up and move on. It is not documented but you can configure that.

in patchgw.cfg add an “http_timeout” element with the timeout in seconds.

For now, I am sticking with this option as I believe it is the only option to reduce a big (in my opinion un-needed) load on the RCS for patch management. It has been working OK

However, I hope that in the future we can have a lightweight model that does not require the download manager / Apache.