Problem installing BESClient on CentOS7 docker image: initscripts

Usage and Config Platform
1

When attempting to install the BESClient in a CentOS 7 docker image, I get the following error:

/etc/init.d/besclient: line 12: /etc/init.d/functions: No such file or directory

This is because the docker image is barebones, and the dependency initscripts is not present.

I’m using the following to kickstart the CentOS docker image to get this error:

sudo docker run -it centos bash -c "cd /tmp;curl -O https://raw.githubusercontent.com/jgstew/tools/master/bash/install_bigfix.sh;chmod u+x install_bigfix.sh;./install_bigfix.sh alpha.bigfix.com;tail -f /dev/null"

I’m not exactly sure if it is possible, but ideally, initscripts would be a dependency of the BESClient declared within the RPM package so it could be handled better.

Reference:

Related:

2

Note: the following command addresses this issue:

sudo docker run -d centos bash -c "yum install initscripts -y;cd /tmp;curl -O https://raw.githubusercontent.com/jgstew/tools/master/bash/install_bigfix.sh;chmod u+x install_bigfix.sh;./install_bigfix.sh alpha.bigfix.com;tail -f /dev/null"

This was a successful install using this command: https://alpha.bigfix.com/common/ui/devices/5216863

3

Interesting error, yeah it does just source it even if its not present. How “basic” a CentOS install did you do? I haven’t heard of anyone having this issue. Wondering if its reproducible and if so if removing the line allows for it to continue. If so I can change the init scripts going forward to check for the existence.

1 Like
4

It is technically the CentOS from here: https://hub.docker.com/_/centos/

You just install docker, then run the command I provided.

The docker version doesn’t contain init and bigfix won’t work without it, and I don’t think it is just that line, I think that is just the first line that fails.

The solution is to just install initscripts first before installing BigFix.

I’m not sure that this is a case that really needs to be handled by BigFix itself unless you really want to support BigFix running within docker, but it is also something that could potentially be handled by the install process.

I don’t know much about RPMs but it might help if initscripts was listed as a dependency of BigFix.

5

I’ll try and use that image. It would be nice if we could do what is simple without initscripts being present as we try to work with “nothing” around

1 Like
6

I agree that if there was something you could do, that would be useful.

With docker it might not matter as much since there really isn’t a concept of “rebooting” a docker container, but if there isn’t initscripts or something to replace it, then there isn’t something to start BigFix running except for when you install it for it to just get itself running that first time.

7

Also, if you have docker on a system, and run this, then it will give you 1 of each of 5 different linux oses with the BigFix client installed and running:

I can’t get OpenSUSE to work at all due to missing dependencies and I’m not sure how to fix it with zypper or otherwise. This is actually a bigger problem than what I originally am posting about here since I was able to work around the problem for CentOS.

8

What is the exact scenario you are trying, to put a BESClient inside the Docker container image? Do you foresee use any patching or security compliance content there?

9

Knowing @jgstew its most likely because he can :slight_smile:
My other guess would be to have agents running on a single piece of hardware that he can use with Query to get answers from.

1 Like
10

That is very close. It is a very lightweight way to run all of the various linux flavors in a single VM for relevance and/or action testing. I can also host them all for cheap on Microsoft Azure and then make them available on alpha.bigfix.com 's webUI so that they can be tested there as well, but without giving everyone access to my network. (I’m using free azure credits through an MSDN subscription)

It isn’t really possible to get Query to work well due to UDP/NAT issue unless I run a relay as well inside of docker, which actually would be another good thing to test, if nothing else to get Query working properly.

There is actually more complicated scripts for getting bigfix running in docker for testing provided by IBM here: GitHub - bigfix/bfdocker: Build docker images of the BigFix Server and Agent

I didn’t make my semi-universal install_bigfix script for use with docker, but it just so happens it works fairly well to do that. I never actually used docker before except for right before I made this post, and I have to say it works very well.

1 Like
11

Right - because with docker containers you start them with a single process. There is no concept of init or systemd or so on. Theres a number of different ways people mange the starting of a number of processes in containers.

I’ve never had any significant problems installing or running the bigfix agent in docker containers.

1 Like
12

Another use case for running BigFix Clients within Docker is that I have some REST API automation that runs through a BigFix task on a repeating schedule. When the task is running, no other actions can be run on that particular client, which is not great if the REST API automation takes a long time and the system should be doing other things. Doing the automation within a Docker Container is a great way to handle these tasks in an isolated way where the BigFix client doesn’t need to do anything else.

For example, I have a script that exports all of the custom BigFix content and commits it to a GIT repo for backup and version control. For some reason the REST API requires that the export of the content be done one at a time, so it can take 6 hours in some cases to do the full export.