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:
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.
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.
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.
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.
Hi,
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.
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
@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.
Yay!