Hi,
Is there a way we can install rpm in house packages via BigFix from the same CDN red hat repositories where the patches (fixlet) is available.
I understand we can upload third-party software and those can be deployed to the endpoint.
- Samsir
Hi,Could some one please help
Im not a Linux person, but if you can script it. you can probably copy the file or call the file in a script and do it like that.
delete __createfile
delete /root/Desktop/runqna.sh
createfile until ZZZZZZ
#!/bin/sh
BESClientConfigPath=/var/opt/BESClient/besclient.config
export BESClientConfigPath
LD_LIBRARY_PATH=/opt/BESClient/binn
/opt/BESClient/bin/qna
ZZZZZZ
move __createfile /root/Desktop/runqna.sh
wait /bin/sh -c "chmod 0755 /root/Desktop/runqna.sh"
1 Like
I don’t believe that you could use the same CDN repositories as those would be managed by RedHat and I’m not aware you can upload your own content to the RedHat CDN (I’m not really a Linux person to know much about the CDN). You can create you own custom fixlets to download the RPM’s from an Intranet resource (or the main Bigfix server) and this content will then be delivered to endpoints in the same way RedHat patches would be, ie main Bigfix server downloads the rpm from the Intranet resource which is then redistributed to relevant endpoints via relays
1 Like
I wish there was a way to tell the same patch mechanism that figures out patch dependencies to also do the equivalent to “yum install {pkg name here}”, but that’s not available (although I’ve been asking for it @Aram @cmcannady ).
Depending on how long this fixlet/action will live, I don’t think pulling from the RHEL satellite server is a good idea. Those packages are updated/replaced as new versions come out (depending on how often you refresh your on-prem?). Simplest way is to have a local repo of sort (you should have one anyway) and host your package there. Then install with your own fixlet.
delete /tmp/vsftpd-2.2.2-13.el6_6.1.x86_64.rpm
prefetch vsftpd-2.2.2-13.el6_6.1.x86_64.rpm sha1:7451055057a34d81b6c3d5a857b4486e6e2ab278 size:155080 http://artifactory.domain.com/artifactory/packages/vsftpd-2.2.2-13.el6_6.1.x86_64.rpm
move __Download/vsftpd-2.2.2-13.el6_6.1.x86_64.rpm /tmp/vsftpd-2.2.2-13.el6_6.1.x86_64.rpm
wait rpm -i /tmp/vsftpd-2.2.2-13.el6_6.1.x86_64.rpm
parameter "__ExitCode" = "{if exist exit code of action then exit code of action as string else "404"}"
if {parameter "__ExitCode" != "0"}
exit {parameter "__ExitCode"}
endif
delete /tmp/vsftpd-2.2.2-13.el6_6.1.x86_64.rpm
3 Likes
Thanks folks for the update.
@masonje, have you tried the “Yum command with CentOS download plugin - CentOS 7 - x86_64” fixlet (ID#401) in the “Patches for CentOS7 Plugin R2” external site? A similar fixlet exists in the “Patches for RHEL 7” external site.
Use this Fixlet to run yum commands to install or uninstall packages using the CentOS Download Plug-in or the Custom Repository, depending on your configuration.
I don’t have CentOS 6 or RHEL 6 patch sites loaded in the Lab Services development environment, but would be happy to host a quick remote session to take a peek in your DEV and PROD environments.
Hope this helps.
@cmcannady
3 Likes
@cmcannady I could kiss you! 
How long has that been out? I have been asking for that functionality for a while now and I didn’t even think to look in the patch sites for that. I can finally deprecate at least 2 of the packages I set up years ago because of this!
1 Like
@masonje… how about a beer instead?
That feature has been available for a while and can even be used to perform OS point release upgrades using the OS specific nomenclature for YUM, etc. If you get dependency resolution issues in the EDRDeploymentData.text log file, let me know and I’ve worked up a YUM dependency resolution remediation fixlet that clears our dupes and puts YUM back in a good state… like Indiana or Ohio. 
Also, don’t forget that you’ll want to execute the import GPG key from the OS/distro respective external site against said endpoints before leveraging the “Yum command with CentOS download plugin - CentOS 7 - x86_64” or similar fixlet.
Do agree with the approach. I have been tested yum patching with a custom repo. it works. but the concern here is we need to maintain a local repository server /Sattelite or need to have a package downloaded in local pc.
@samsir, by leveraging the appropriate Download Plug-In within the root BES server, you’re effectively replacing the local Satellite and/or other repository servers/services and letting the BigFix infrastructure propagate the necessary OS distro and version specific files. This has obvious cost reduction benefits by not having to maintain additional infrastructure by allowing your existing BigFix infrastructure to be the repo proxy between your managed Linux endpoints and the manufacturer’s designated portals (i.e. RedHat Access Network). Another benefit, is BES is much better about managing bandwidth utilization across large WAN implementations through the use of bandwidth throttling, where as most repository systems (i.e. Satellite) don’t typically offer this kind critical functionality where high latency, low bandwidth remote sites exist. I hope this help answer your question.
@cmcannady , thanks for the details. do agree we can enable required plugin to patch the linux distros.
between, for the package management still we need to have a local repo to be maintained to install any new packages.
example if I would like to install sos report utility my machine either I need to download the package and upload to the system or need to connect a linux repo server to install the sos report utility . we cannot install the sosreport utility via CDN.
I hope not confusing here !!!
thanks.
@cmcannady I have doubt on the RHSM plugin for Red Hat, Is it mandatory to enable this plugin even to patch the Red Hat machine via fixlet (not via Yum).