Foreman installation on Docker: "stty: standard input: Inappropriate ioctl for device"

I’m trying to install The Foreman in a Docker image after Quickstart installation guide in the Foreman documentation. My Dockerfile looks like this:

FROM centos:7

RUN yum -y install && \
    yum -y install && \
    yum -y install && \
    yum -y install foreman-installer && \

When I run “docker build .” the commands execute, but in the end the foreman-installer refuses to start the installation with the following error message:

stty: standard input: Inappropriate ioctl for device
Output of ‘facter fqdn’ is different from ‘hostname -f’

Make sure above command gives the same output. If needed, change the hostname permanently via the
’hostname’ or ‘hostnamectl set-hostname’ command
and editing the appropriate configuration file.
(e.g. on Red Hat systems /etc/sysconfig/network,
on Debian based systems /etc/hostname).

If ‘hostname -f’ still returns an unexpected result, check /etc/hosts and put
the hostname entry in the correct order, for example: full

The fully qualified hostname must be the first entry on the line
Your system does not meet configuration criteria

According to the installation docs the installation is non-interactive, so why does the installer (probably) ask for input on stdin?

Also, what is wrong with the hostname? Why should I need to set a hostname in a Docker image anyway?

Any help greatly appreciated!

Looks like with

foreman-installer -v

I can fix the “stty: standard input: ...” complaint. The rest of the error message remains unchanged, though.

I’ve also tried to wrap the Dockerfile with a docker Compose setup, using the hostname: option and by setting HOSTNAME in the environment: block, without any results.

Related discussions that give some hints:

While I personally like the foreman-installer, it’s unsuited to a proper container deployment. It’s aimed at installing a whole stack where a real container deployment ideally splits it into one process per container. Running a whole stack inside a container with a process manager is IMHO a VM so I’d recommend using a VM in that case.

As pointed out in Docker image for running The Foreman the more likely path forward with containers is deploying to openshift which we have a proof of concept for now.

tl;dr: IMHO we have no supported way of running foreman in containers, but it’s on the roadmap. If you’d like to help make it happen, we’d appreciate any help.

Thanks @ekohl, thanks for the reminder. Those are good points to keep in mind!

Pragmatically speaking, the point of running The Foreman in a container is somewhat being able to easily swap components in and out of a system setup (e.g. Puppet, the web application “The Foreman”, database, etc.) and keep the data outside in a volume. For what I understand The Foreman is not easily separable from Puppet. That makes splitting it up into its technical components, and coming up with, say, a docker Compose setup, difficult. Is that being worked on?

If I would, for now, run a Vagrant setup with The Foreman how would I cleanly separate the data from the Vagrant machine? i.e. which directory trees would I have to mount from, e.g., the host machine to allow for easy backup of configuration data and database, and what else would I have to keep in mind to make sure the setup is easily upgradable?

Side note: I need upgrading to be super-simple straight-forward (e.g. run vagrant destroy && vagrant up to upgrade the entire setup).

That’s incorrect. The only way Foreman talks to Puppet is via the Foreman Proxy. Place a proxy on another host and you can remove Puppet from the Foreman host. Do be aware that for the ENC and Reports it needs to talk to the Foreman API but that’s a matter of pointing to the correct URL and getting the certificates right.

Certificates is also hard within containers and not something I think we already have a good solution to.

This is something I’m a big proponent of. With a vanilla Foreman it’s perfectly possible to split off everything and just end up with an application server (webserver + passenger). The database can live on another server as well as the proxy and its components.

Some plugins do break that assumption. Katello is obviously the biggest beast here. There is some code that assumes a shared filesystem and certificate handling is complicated. That’s high on my wish list to fix, but finding time to do so is hard.

@ekohl I was mostly referring to the tight marriage of the Foreman installer, which then sets up Puppet as a first-class citizen. That obviously gives a wrong impression. Also, it looks like it’s possible to set up The Foreman without the installer, i.e without Puppet, so not even that assumption holds true.

There is some code that assumes a shared filesystem and certificate handling is complicated.

It should be possible to share code across containers, e.g. via volumes. At least as a first workaround, as long as a clean separation is too laborious. And what exactly are the issues with certificates?

It would be nice to have a docker Compose setup instead of what is the foreman-installer today. And then maybe have separate installers that set up the single Docker images, so that you could easily, simply run those installers just in a row if you strictly preferred a non-Docker local setup, or a Vagrant powered VM.

You’re right, there is still some assumptions left in the installer that I’d love to remove. One of the reasons I think the installer is the wrong tool for a containerized deployment.

You have to know what you’re doing. AFAIK there isn’t documentation that tells you how to generate the correct certificates if you’re going to split it up.

For this I’d look at the aforementioned containerization effort in forklift. Note that @ehelms is working on it and has some work in progress.

Back to the original issue. I’m now trying to run the installer in a CentOS 7 Vagrant box - instead of a Docker image -, but I still get the same error:

In fact, facter fqdn yields the domain name plus the domain suffix (as set in my router and visible in /etc/resolv.conf as search foobar.local) while hostname -f only yields the host name without the domain suffix. (I’m running Ubuntu 17.10)

Is this a problem with facter, or do I have my router configured in a perverted way? I’ve also checked the Vagrant machine settings and there is no way in explicitly setting the domain suffix. Why is facter doing this? How can I fix the situation (for everyone using my project)?

hostname -f is supposed to return a FQDN. It is likely that there’s a short name in /ec/hosts that’s incorrect. Because some tools use hostname -f and others facter fqdn they must match.

Just fund shlomizadok/foreman-docker-compose, which is a Docker Compose setup of The Foreman! :smiley: Yay!

There has been a proposal to move this project under the umbrella of the The Foreman GitHub organization. Who can help to complete the request today?

Shlomi is no longer actively maintaining that project, the last commit is almost two years ago. For it to migrate to the foreman org, we would need a new maintainer to step up and take responsibility for it.

I have an active interest to get the project working (and continue to work) . I can step in. I’d need a hand though from someone who knows the components. I do little Ruby, so someone knowing the The Foreman code base would be great. Currently, the Docker Compose build aborts with errors.

1 Like

I’d like to hear @ehelms’s thoughts on the overlap with Forklift. I’m all for more emphasis on Foreman in containers, but my support is limited to cheerleading and poking people, so actual code maintainers are going to be needed :slight_smile:

@bittner thanks for the offer. If we can get another person involved, then starting with a 2-person team who can review each others changes seems like an excellent start.

I think that’s a discussion about “lightweight” vs. “heavyweight”. I’ve got the impression Forklift isn’t targeted towards home automation (aka “living room servers”). I wouldn’t run an OpenShift cluster on my home NAS hardware. So, maybe these are actually different “products”.

I actually managed to get “docker-compose up” pass with adding a few packages that are now needed. The infrastructure is up, now I’m at the application-specific level of problems.

@Gwmngilfen It would help getting the project moved into the theforeman GitHub organization. Shlomi has merged my changes, but now I face an issue that is probably easy to understand and tackle for everyone in the The Foreman community with a bit of experience of the inner workings of the forman-installer.

Visibility would help. A lot. And it’s just another helpful project. In a competition of best ideas.

It’s not clear to me that simply transferring it to our org brings that visibility. There are over 100 repos under the org, and many of those have PRs that need contribution too. Issues get missed, even on core repos - our volume is huge.Transferring a repo is not a magic wand to being seen.

You need to get eyes on your issue, that’s clear - but this is a networking problem (human networking that is). Putting the repo under our org doesn’t solve that, it’s about reaching out. My personal approach would depend on whether I knew who I needed help from - if I did, then naming those people in the GitHub issue should hopefully get their attention, or perhaps I’d speak to them on IRC. If I didn’t know who, I’d make a new thread here in the #development category about the issue, or perhaps again ask more generally on IRC.

Indeed. Or it could be duplication of effort, something that happens a lot in open source. Hard to know which without discussion, and that discussion needs to happen with the people working on our Foreman-in-containers efforts. That’s why I asked for @ehelms input above.

Ultimately this isn’t my choice. Community is about consensus, so without hearing from those people I’m not going to take action. Unilateral actions make no one happy.

You’re right. I’ve created a separate thread for this. Thanks!

1 Like