Say I want to write a script that will show me what agent versions are available for RHEL x86_64, and their URLs, without having to scrape an HTML web page. Is there a catalog or API somewhere for programmatic listing of downloadable RPMs?
There are Fixlets for the current supported versions…I’d consider that to be our catalog.
Doesn’t that depend on having bigfix already installed? That seems like a chicken-and-egg problem. A script should be able to find available versions and their characteristics, without having to have the software installed. How could I do that?
We would usually just use a static download to deploy (any recent) version of the client to get it attached to the deployment, and then use a policy action on the Upgrade fixlet to get it to the new latest version…I’m not sure I see the need to scrape the HTML from the download center?
What is that static download?
On [I wanted to link, but this forum won’t allow me to because I’m a new user] you have a list of releases and the patches available for each one. On each patch link, you have server, relay, and agent, with each one giving a list of architectures and OSes, and each one of those gives a downloadable RPM.
If a script wanted to find, say, the RPM URL for the latest patch of each major release, for x86_64, and what OSes it’s available for, how would it do that?
If a script wanted to download the latest 9.5 agent for CentOS 7, how would it find that?
You keep going back to ‘How would a script do it’, and that’s fine I guess, that’s just not something I’ll be able to help with. There’s obviously some way to do it, as the Client Deploy Tool that we publish does it too, but I don’t know whether they are doing anything more than keeping a list of download links in a config file or not.
Well yes, that’s my question 
There is a tool called AutoPkg that kind of automates things like HTML scraping and packaging.
You can also install an older version of the agent, but then auto upgrade once installed.
I use this script to fully automate BigFix install for Linux/Unix/Mac, but with a version number hard coded that I update periodically: https://github.com/jgstew/tools/blob/master/bash/install_bigfix.sh
If I was smart, I would use AutoPkg to automatically update my script.
And that’s the problem 
In my case, I have a small collection of RPMs that we include in a build that gets distributed. Periodically, someone needs to see if there are new versions of any of those packages, and if so, replace the RPM we have stored with a newer RPM. I want to automate this so someone can just run one command that will check for updates of all of the RPMs we maintain here (not very many), and automatically download any that have new patch releases. For new major versions, it would alert the human and let them decide whether to bump up to that.
For some packages, this is pretty easy. But for BigFix, it seems impossible without a) scraping web pages and parsing them, and b) depending on the web pages’ format to remain consistent, which seems like not a fair bet.
It would make sense for there to be some machine readable catalog of available RPMs, but I guess what I’m getting from this thread is that there really isn’t? Anyone know why?
This gives you the answer you are looking for, but by scraping the HTML: (I haven’t tested this in a while)
You could take the output of this, compare it against the last time this has been done, and if newer, then trigger … whatever.
The new version number gets plugged into the (RPM) download URLs in a predictable way.
Basically, if we were going to go through the effort of building RPM repos for our releases, we’d ended up with about fifty repos (one for each OS), with a single package in each (current client version). It wouldn’t be very useful to our customers, I think, because most wouldn’t want to update their yum repo configs to go search our repo to find one package.
In my experience, most customers like to test our clients in their environment before doing a mass upgrade, and they might not appreciate having to keep up with our repo and trying to version-lock to a version they are managing. We don’t have many machines reading our repo to begin with.
Additionally, the install package itself is not beneficial without also having a masthead file, so there is some configuration required at the customer side anyway.
We only release a new version every two to three months; perhaps have someone subscribe to the release-announcements category so they’ll get an email notification, and then update your repos from our packages only when they are updated?
But what about something very lightweight, like a directory that just has all the RPMs as files, if their names encode information in a consistent way? Or, a text file one can grab that has a CSV listing version, type, architecture, OS, and URL to download?
That’s not automatable, and not sustainable - when five or six different software providers all ask you to do something like this, it ends up being a lot of tedious manual interrupts, error prone, easy to miss, and not well tracked.
1 Like
I do agree with this, could be better.
not a bad idea.