IDEA OPENED - Provide the ability to create custom download plugins - for use to GIT/Nexus repos

I opened an idea today - https://bigfix-ideas.hcltechsw.com/ideas/BFPTCH-I-142
To provide the ability to create custom download plugins, where we could provide the user id and password to use to pull files from GIT/Nexus repos for example. Currently when the BigFix master tries to pull files down it doesn’t have rights/permissions to access the files, but my user id does. I would like the ability to create a service account that could pull files directly from a GIT/Nexus repo, to maintain version. I am not sure BigFix might add the ability for version control of its baselines and fixlets.

Thanks,
Bryan Lenherr

1 Like

Are you interested in having the client download directly from the repo, or do you want the download requests passed up the relay chain and the downloads executed by the root server?

Trying to understand the use-case. Would you be supplying the binary or script that authenticates and performs the downloads, and just need documentation on how to call it through the BigFix architecture? Or are you asking for BigFix to provide a GIT client and associated logic for it through the relay chain?

Having the client execute your scripts as a download plugin (where the client would connect directly to GIT) is actually an option already. I don’t think we have a step-by-step instruction yet, but you could build something custom based on https://developer.bigfix.com/action-script/reference/download/execute-prefetch-plug-in.html

“Or are you asking for BigFix to provide a GIT client and associated logic for it through the relay chain?”

Yes I believe we would want it to be processed through the relay chain, with the bigfix master pulling from GIT to relay to client.

I believe it could be something as simple as adding the options of user id and password for the master to use to pull from the GIT/NEXUS repo. This could be setup similar to have other download plugins are configured with an ini file with the user and encrypted password to use. like AIXProtocolR2

Then the prefetch would just be like url=AIXProtocolR2:/website/filename.txt
And it would use the user and encrypted password associate with that plugin.
I believe we use something like this to pull openssl down from IBM through the bigfix master to relay to client…

prefetch openssl-1.0.2.2100.tar.Z sha1:a4433f26a06e4e272248170b6a61ba23d312ffe6 size:34883100 AIXProtocolR2://get.file/openssl/openssl-1.0.2.2100 sha256:05061bbe92afc0833b91986280f6c389a04f626db8a61d4497528833df79b511

Unless there is a way to do the prefetch and pass it a ini file that has that user and password in it?

Bryan

Using the client-side method, you would need to get the credentials down to the client or have them present somewhere already, that a running script on the client could read.

I was trying to clarify what you were asking -

Sounded like you were asking for a generalized way of building your own download Plug-Ins, or maybe just documentation on how to do it. But I think now you mean we should provide specifically a GIT download plugin where we would manage credentials and have the root server execute git client commands to a repo you specify from the client?

Would you want the client to be able to request from any git repo, or just a specific list that you allow in the plug-in config on the server?

Probably from a specific list of git repos only, but I could see the requirement for others to download from any git repos…maybe have a whitelist and if nothing is whitelisted then allow it to download from any?

I wouldn’t want to limit it to just our specific use case, but cover many uses.

Bryan

1 Like

I really like this idea. Most AIX and Linux admins have many scripts that they use to do their daily work. I have been asked many times if BigFix contains function to support version control for custom content. Having a download plugin for GIT would give users exactly that capability to provide version control for custom content, without the BigFix product being in the business of re-inventing GIT.

I agree it would make sense to whitelist the repositories to use.

Jason,
Any further thoughts on this one?

Thanks,
Bryan

Other than “looks like a good idea” ? To be clear I’m not part of the development team and wouldn’t be building this kind of functionality. I voted for it though.