What is Reddit's opinion of Foreman?

From 3.5 billion Reddit comments

So Foreman is basically an automated provisioning system. You hook it up to DNS servers, DHCP servers, and another configuration management tool called Puppet.

Once a server is connected to Foreman, it manages the state of that server using Puppet (which normally has its own dashboard and own configuration files, except now it's all going through Foreman's web UI).

If you have a system managed by Foreman it comes up on the hosts dashboard. Exactly like the Puppet dashboard.

The difference being, deleting a system from the Puppet dashboard just removes it from Puppet - the next time that system calls in for configuration information, it gets nothing.

Deleting a system from foreman actually deletes the VM. Me, being new to Foreman, didn't realize this. Bricks were shat.

If you're interested in bare metal provisioning (and life cycle management in general) you might want to check these two other projects out, if you haven't already.

The first is foreman which tries to do a bit more than just bare metal provisioning, but looks pretty cool.

The second is Razor from puppet which has some cool ideas (tagging nodes and creating policies that match those tags), but i'm not quite sure how much development is going on right now.

have you looked at Foreman?

Generally speaking, the first term that you're looking for is 'provisioning'. Once you have that covered your next goal is config management. That's where Puppet/Chef/Ansible/etc come into play.

As a side note, how tied are you to KVM? Do you need to virtualize non-Linux OSes, or could you use containers such as the LXC-based Docker or OpenVZ-based Proxmox? In either case provisioning becomes easier because you can control the guest's network configuration from the host, which means you're cutting out a large chunk of what's probably your biggest annoyance with VMs.

Puppet doesn't really do provisioning, just configuration/state management. For provisioning, look into kickstart/PXE or Redhat Satellite if you'd like to stick with redhat products.

Also, I relied heavily on Foreman to manage provisioning. It is an excellent tool that integrates well with Puppet.

Came here to say this. This will almost certainly be faster than cloning.

I'd recommend using Cobbler or Foreman. I generally only deploy one or two hosts at a time and use Cobbler every time, I wouldn't really want to do 100 systems any other way.

I was using The Foreman until recently, and I kind of like it. Was never 100% on it though, even though I cannot really explain why.

I have had a lot of success with Cobbler.

Currently I use Razor in my lab and really like it.

We use the combo of Foreman and Puppet (open source, not Enterprise). Integrated with VMware, that means I can build any of our server types and have them actively taking jobs in a few mouse clicks and <15min.

[edit] Foreman also works with KVM and libvrt if you want to go completely OSS.

What are your specific requirements? What OS, fleet size, applications etc? What do you mean "getting servers up"? Physical or virtual? If virtual, then self hosted on VMware/Openstack or AWS/GCE etc?

In any case, you owe it to yourself to look at Foreman. Foreman will handle DNS/DHCP/PXE kickstart/preseed/jumpstart for you, and has deep integration with puppet (chef to follow this year hopefully). It can also help with virtual provisioning, but capabilities vary with providers.

I've used foreman at scale, and so have others. http://theforeman.org/learn_more.html

Foreman is a provisioning tool for servers. It can stand up machines in all types of environments, and use all sorts of provisioning tools. It has a REST api so we script around it.

It's slowly becoming the source of truth for our infrastructure because it knows about all our Amazon, VMWare, and Xen hosts.

My oss solution for this is to use Foreman to provision nodes, hooked into isc-dhcpd and freeipa

automated provisioning and node lifecycle management, integrated with dhcp/dns/krb.

I have also used phpipam and gestioip, and both are ok, I prefer phpipam, because it has an api so you can programmatically add/remove hosts/nets/ips (which I can call during provisioning from foreman)

Take a look at Foreman

You can add VMware as a compute node, and then deploy templates/VMs from Foreman.

( I can't remember if it only supports Vsphere, og if you can use it against an ESXI node directly )

Honest answer: Yes, it works great.

We manage a 800+ Server environment in which ~400 of those boxes are windows. We chose puppet over Salt/Ansible/Powershell DSC because we run a mix of different operating systems that have their own quirks (SVR 2003, SVR 2008, SVR 2012 etc). Puppet gives us one unified configuration enforcement platform for servers that are not all on the same domain.

You can manage most resources with puppet on windows, this includes:

• Services
• Files/Folder trees
• Scheduled Tasks
• Local users and groups
• Packages

If you choose puppet, I would recommend using Foreman as your ENC.

Saltstack was our next choice, however the management side of the platform is not very mature as of yet (for newbies) so we went with Foreman/Puppet. I suspect that once Saltstack gets a mature web based management system we may switch to Salt for the remote execution part of it.

Powershell DSC was not a choice as it has very poor linux support. We need unified systems management and Puppet fits the bill for now.

Good luck!

Cobbler is great, but theforeman is better. It supports rhel, debian, solaris, ubuntu, suse. unattended installs, and fantastic puppet integration.

good luck.

Foreman currently requires 3.x, you need to use the regular non-PC1 repository and should have the "puppet" package installed. The quickstart shows which Puppet Labs repository to configure. You can either reinstall or downgrade the package back to puppet-3.8.6.

> I know that what you're saying is a commonly held belief, but I'm challenging it.

Fair enough. It will be a learning experience regardless of the outcome. Good for you for seeing if using Vagrant will make your current setup a bit better.

If I were personally in your situation, I would look into using Vagrant + Packer as /u/deadbunny mentioned, and then I would consider using Open vSwitch, libvirt, and Foreman in production.

Our dev/ops team uses foreman. I had to install a system via foreman for the first time this week and it was painless, though admittedly I did not set up the foreman server.

http://theforeman.org/

Supported platforms:

• CentOS, Scientific Linux or Oracle Linux 6 or 7
• Debian 8 (Jessie) or 7 (Wheezy)
• Fedora 19
• Red Hat Enterprise Linux 6 or 7
• Ubuntu 12.04 (Precise) or 14.04 (Trusty)

I've never used Foreman. I just build my own PXE based provisioner with kickstart. As long as the machine can do PXE, it'll register itself drop the OS on the machine get its hostname and the post configure itself...

But, if you want to use Foreman this isn't a hard thing to do... Foreman has the ability to build bare metal machines. A quick google led me here: http://theforeman.org/plugins/foreman_discovery/2.0/ The way I interpret that is that the bare metal boots into PXE and then loads the discovery plugin. it registers itself into Foreman for you to find later. You then click the host, give it an identity, and the installation and post configuration happens for you. Is this a fair compromise?

Take a look at Packer.

If that's not what you meant by "image", and you were instead looking for a way to quickly configure physical servers from some kind of template, then a tool like Puppet would suit your needs, used with something like The Foreman.

> So my idea was to configure seperate config groups for chrony servers and clients which I attach to the hosts (or host groups). > > At this point I can not find where to specify seperate parameters for the two config groups.

Use config groups as a way to attach multiple classes to a host or host group in one click. So a LAMP config group may add a class to configure Apache, plus some monitoring, plus a MySQL database class etc.

Use host groups as a way to specialise and classify your hosts as a hierarchy. You can override class parameters on a host group or at a host level, for example.

Note that you can also change class parameters based on facts and any attribute apart from config groups via Configure > Puppet classes. See the smart matchers docs for some info: http://theforeman.org/manuals/1.9/index.html#4.2.6SmartMatchers

Current place is a smaller startup, but the last place we had several thousand physical machines and a few hundred VMs.

Since we were heavy into Puppet, we used The Foreman. Just give it a MAC and tell it what environment and type of machine you want, and it will add it to DHCP/DNS, PXEboot the OS of your choice, install Puppet, and attach it to the Puppet Master to finish building out the machine. It also supports VMware, EC2, etc.

We hooked into Nagios using some scripting and the API for Foreman - query for environment and type/application, and apply monitoring as applicable.

You need to add the VMware host as a compute resource. This is how Foreman is intended to manage the complete life cycle. I haven't done it for VMware, but have for KVM.

The foreman v2 API is fairly mature, although a bit inconsistent in places. Assigning a host to a hostgroup should be fairly straightforward, the docs are useful...

http://theforeman.org/api_v2.html

We replaced our SCCM environment (two actually) with puppet and I gotta say we are happy about the choice. Puppet at the end of the day is lightyears more powerful than SCCM in our particular use case. Stack Foreman ontop of puppet and you have easy to use web based management and auditing.

SCCM was a pain due to us having multiple domains and it being more user level focused. Our use case is more host focused and puppet's resource types fit the bill. Also SCCM does not manage linux machines which we are a mixed linux/windows environment.

If you want to magically go further in a Sysadmin role, you need to research a wide range of technologies and find what fits for the business case. Puppet fits our business case while SCCM did not.

TheForeman is an open source server lifecycle management application written on rails. There is a a Dev and User google group, IRC channel, Redmine bug list, and of course Git repo.

http://theforeman.org/manuals/1.4/index.html#3.InstallingForeman

I used the official instructions. Have my own dhcp and DNS so didn't have it set those up.

You then set up a compute resource for your hypervisor. I used KVM, remember there are specific packages for the different compute resources.

The documentation for this project is pretty good IMHO.

I wish you all the luck in the world, it really makes deployment a lot easier and quicker.

I am using cobbler right now to do what you are doing, but am going to be moving to theforeman in the very near future.

Either of the above with puppet (or chef or cfengine whatever configuration management makes you happy) is pretty awesome.

good luck.

There is a nice ecosystem of tools and recipes around both Puppet and Chef.

Both are quite easy to use, and require basic knowledge of ruby. You can probably get by with 0 ruby knowledge, because so many recipes can be found online.

Puppet has a dry run mode while Chef does not. (Puppets dry run is not that great, but it can be a factor for decision makers)

There is a project called Foreman, which lets you manage different aspects of puppet like cert signing, fact collection, fact search, class and parameter allocation, reports monitoring etc. The reports emailing and monitoring features itself make puppet management easy.

http://theforeman.org/projects/foreman/wiki/ScreenShots

The official puppet dashboard is also pretty good.

I'm not sure if the equivalent tools for Chef do the same, or scale for 100s or 1000s of servers. There is a paid product for Chef, not sure how good it is: http://www.cyclecomputing.com/grill/tour

There's The Foreman, but good luck getting it to work. I've been tearing my hair out for weeks trying to get this to deploy and VMs. Also, don't even try using 1.17, there are deployment bugs in it that make it unusable.

I used to run FreeBSD in a lab. The OS would be installed locally and all the rest (that lives in /usr/local in FreeBSD) would be automounted from a central server.

Homedirectories were on a central server provided by the computing department, as was the YP/NIS-server (yeah, back then NIS was all the rage).

That was before FreeBSD 4.0 came out. I think this could still work.

It looks like PCBSD still supports something like this: http://web.pcbsd.org/doc/10/html/using.html#thin-client

I've never tried that again in the last 15-ish years, I must admit.

As others have said, it's run out of fashion.

A full-blown solution these days would probably be built on something like http://theforeman.org or RedHat's Satellite Server 6.

Perfectly doable with 2 people - provided your time is worth nothing and you have lots of it...

I have not used Foreman in a while, but this page has some information on Puppet environments: http://theforeman.org/manuals/1.11/index.html#4.2ManagingPuppet . I would either attempt to rename your environment to remove the dash or replace it with underscore. Also puppet-ca I believe is a Class that Puppet uses internally in a Puppet Master environment to define the node used to sign certificates. If possible, it would be better to use a different name for your environment so that it does not conflict.

If 'puppet-ca' is not the name of the environment assigned to your nodes, then this could indicate a totally different issue.

Was this working and then just stopped, or is this a new environment/setup that you are working through? Do you have non-OS X nodes working with the same setup (assigned environment, classes, etc)?

Two person team, around 500'ish bare-metal servers (+20-30 VMs) across two datacenters, 35 x 10/40 GbE switches, a Netapp, Compellent and some Brocade FC. Everything is 100% Linux (RHEL) provisioned with Foreman when we're not doing OpenStack deployments, managed via a mix of puppet and ansible.

These power large internal/external R&D and OpenStack environments and some public facing CI, cloud and build services. We use nagios for monitoring and graphite/grafana (collectd) for graphing. We use ELK for log aggregation.

Dealing with so many iDRAC is by far the largest pain but we automate a lot of it with XML templates

The foreman ==> http://theforeman.org/ especially if you use puppet.

Also there is the foreman based katello which adds software management: http://www.katello.org/

Both are the basis for Redhat Sattelite and under active development

Basically, to answer your example, you would need 2 classes:

ntp::server, to configure your servers ntp::client, to configure your clients.

IIRC in foreman you can configure classes to set them to given hosts: http://theforeman.org/manuals/1.9/index.html#4.2.2Classes

For the Katello.org web page you are correct, but I have found that the Red Hat Satellite Server 6 documentation is 1 for 1 the same product, and excellent documentation in general.

If you pm me your email I will forward the PDFs to you.

-edit

Here is a dump of the docs: https://www.dropbox.com/sh/27g7e2b2porw9up/AABSecr8OC_J7_aPPUT9pz_Xa?dl=0

-edit2

Since Katello's core is Foreman, foreman plugins and documentation work extremely well also. Anything not covered in the Red Hat docs will be covered in the Foreman docs here: http://theforeman.org/manuals/1.8/index.html

the .env file is for maintaining env variables for an application. The idea is pretty simple really, should be self explanatory.

~~The Procfile however comes from http://theforeman.org/, it's a lifecycle management tool that helps automating basic application tasks~~.

Edit: My bad, it actually comes from https://github.com/ddollar/foreman most notably used by Heroku

Analyzing tapo

• comments per month: 9.8
• posts per month: 0.1 ^lurker
• favorite sub PS4
• favorite words: games, really, you're
• age 8 years 6 months ^old ^man
• profanity score 0.6% ^Gosh ^darnet ^gee ^wiz

• trust score 81.5%

• Fun facts about tapo

  • "I've been playing on Fedora 21 the whole time, so it runs just fine on the Linux."
  • "I'm a diehard Debian fan but when it comes to shit like this I don't blame you for going back to Windows."
  • "I've read its a modified version of Hyper-V, they even got Dave Cutler to work on it."
  • "I've had this issue since launch and I've heard its buggy WiFi firmware on some machines."
  • "I am not taking about OpenGL."
  • "I am not saying it's not an improvement, I'm not saying it's not good for Xbox or Windows, but it's not as fast as bare metal."
  • "I'm a huge Bungie fan (Marathon was the first shooter I played) and I fully intended on buying MCC and a One, no interest in Halo 4 or 5."
  • "I am a huge fan of BioShock and BioShock Infinite, but I enjoyed The Last of Us more."
  • "I've been throwing everything I can into InfluxDB (carbon input) and visualizing it with Grafana and it is fucking awesome You're right."
  • "I've done this internally with a few hundred sites."
  • "I'm a massive fan of Foreman."

You might classify your nodes as development, qa, staging, release-candidate, or production with an external node classifier (ENC) instead of complicating your puppet conf or using Heira. An example of an open source tool to use as an ENC would be The Foreman. Of course, if you've got Puppet Enterprise you can use the web app that comes with it as an ENC.

I've only ever installed using the packages, which won't bulldoze anything:

http://theforeman.org/manuals/1.6/index.html#3.3InstallFromPackages

It means you have to set up a lot of stuff manually, but by the sounds of it that's probably what you want.

Thanks! OpenStack is probably the most interesting out of the three, but i think combining Puppet and Openstack you could get a really powerful way to manage and destroy VMs quickly. I have also heard that puppet is very good with http://theforeman.org/

I would second racktables. It might include the backup requirements out the box, but the program is a PHP / MySQL web page, so you could always add them if necessary.

The foreman (http://theforeman.org/) does provide some inventory management (Not as good as racktables) as it is a life cycle management program (which does use puppet).

You can use Chef and Puppet in client/server mode, or in 'solo" mode. In my opinion, if you want the client/server model, puppet is easier to setup and maintain. With this model, you get benefits like centralized reports, monitoring, auditing, fact/ohai database etc.

Knife ssh on chef is great, and does not have a full equivalent in puppet. To use knife-like capabilities on the puppet side, you need mcollective, which needs a client on all hosts, in addition to the puppet client. The other options is to create your own knife like tools, using dashboard or foreman.

The chef server is a little harder to setup and maintain, but its not a huge deal for a experienced sysadmin. It does depend on extra things like Couchdb. The puppet dashbord, or other Foss software like Foreman are imo, easier to setup and maintain.

If you prefer the 'solo' model, then it comes down to weather you prefer the Chef language, or the Puppet Dsl.

Do you prefer chef 'data-bags', to store variables or external data, or you prefer puppets hiera/ENC.

To gather custom data about nodes, some prefer puppet Facter while some like chefs Ohai. Both are easy in my opinion, but some like the fact that ohai can return structured Json output, which is as yet missing in Facter.

Ubuntu support is great for both tools, not sure about Freebsd.

If you self-host, you can look at Foremans baremetal provisioning features, and tight puppet integration.

Chef/puppet dont care if you use them deploy PHP or haskell, or what-have-you.

Choice of git is perfect for either tools to maintain the code. If you want Rbac for the server tools, you need the paid Chef server, or the paid puppet Enterprise server, or Foreman.

You won't know what works best for your infrastructure, until you try these options. Take a week or two to do just that.

The Foreman takes a little time to setup. Once you have it setup, you can manage DNS(add remove records), DHCP (add lease), PXE, (create PXE config files), Kickstart (create dynamic kickstarts from templates), assign Puppet classes, view puppet reports. All features are optional, choose what you want. This works for bare-metal and virtual hosts. It can even create virtual machines for you(KVM and ovirt so far).

You should look into this if you anticipate re-installing these servers, or plan to manage more and more servers in the future.

What do you need that Foreman cannot do?

It may be easier to shim those pieces into Foreman than to pursue other options.

Foreman has a well documented API... if you'll take a look at the API you see that you can put KVPs in the lookup_key APIs http://theforeman.org/projects/foreman/wiki/API

We use Forman! at work although we only do RHEL and CentOS. It does however support Debian. It also integrates with puppet for full configuration management. The only thing it doesn't do on your list is SUSE.

3) No and yes. Use The Foreman (http://theforeman.org/), which is written by the excellent Ohad Levy.

It's a bit tricky to set up, but once it's running you get a single portal that tells you at a glance what machines are failing puppet runs and why. There's a very simple RESTful API you can use to query it from Nagios (that's what we do).