Asset management reports?

Hey there, we have a foreman install that is installed on all machines we manage and is working great.

I can go into facts and pull out a username or a serial number or device type. But i havent found any area where i could gather this information in a report that i could share with management.

Is there a ready built report or plugin that can be configured to generate a report that lists

  • hostname
  • serial number
  • model number
  • last user

Maybe a plugin of some sort?
let me know.

This should be doable out of the box. In Monitor > Report templates, you should be able to put together a report template, which could be used to generate an asset report. You can access all the facts in the template so as long as the information you want to have in the report is available as facts, you should be good to go.

The following should work, just add the facts you need to it

name: Host - Asset
snippet: false
- name: hosts
  required: false
  input_type: user
  description: Limit the report only on hosts found by this search query. Keep empty
    for report on all available hosts.
  advanced: false
  value_type: search
  resource_type: Host
  hidden_value: false
model: ReportTemplate
<%- report_headers 'Name', 'Manufacturer', 'Product name' -%>
<%- load_hosts(search: input('hosts')).each_record do |host| -%>
<%-   facts = host.facts_hash -%>
<%-   report_row({
        'Manufacturer': facts['dmi::manufacturer'],
        'Product name': facts['dmi::product::name']
      }) -%>
<%- end -%>
<%= report_render -%>

I appear not to have Monitor → report templates. Is it possible that this is a module i would have to turn on?


foreman version is 1.19.0 , which might be a bit behind as everyone is too scared to update it. Could that be why?

Most likely, yes. 1.19 is ancient. With 1.19 I don’t think there’s a way how to do what you want. There might be a plugin for it, but I don’t know about it and with you being so behind the latest you would be on your own.

From where I stand I’d say you have two real options, either upgrade to a newer version or roll your own solution.

Ok! so we upgraded now. Sitting at version 3.1.2

I copy and pased the text above into a new report template, however i get the following error:

ERF01-2862 [Foreman::Renderer::Errors::UndefinedInput]: Rendering failed, no input with name "hosts" for input macro found

Do you have more of a step by step guide?

EDIT: i can make an input called ‘hosts’, and then preview returns about 6 lines of hosts and model numbers. great! however when i save and click generate on the next page, i get:

Oops, we're sorry but something went wrong The Dynflow world was not initialized yet. If your plugin uses it, make sure to call Rails.application.dynflow.require! in some initializer

any idea?

Good, good. How did you perform the upgrade? Just to get an idea if we’re looking at a somewhat standard setup or something custom

We’ve seen this a couple of times in upgraded setups. Could you check that your deployment is not using passenger anymore?

My colleague did it. He said that he did a stepped upgrade, one version at a time till we got to the latest release. He’s the foreman expert

Could you check that your deployment is not using passenger anymore?

How do i do that? Neither of us know what passenger is.

A little bit of background about the passenger to puma can be found here 2.1 Headline features . As for how to check it, I’m not really sure to be honest. I don’t have any 2.0 or older instance around where I could check, the most reliable way would probably be inspecting apache’s configuration to see if it is running passenger or just proxying incoming requests to puma. But again, I can’t really give you the exact stanzas to look for

So i do have a passenger.conf file in /etc/apache2/mods-enabled

it has the following text:

# The Passenger Apache module configuration file is being
# managed by Puppet and changes will be overwritten.
<IfModule mod_passenger.c>
  PassengerRoot "/usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini"
  PassengerDefaultRuby "/usr/bin/ruby"
  PassengerMaxPoolSize 12
  PassengerMaxInstancesPerApp 6
  PassengerMaxRequestQueueSize 250
  PassengerMaxRequests 10000
  PassengerStatThrottleRate 120

Obviously i am not going to like for instance delete this file, without more clear instructions on exactly how to resolve this.

Say i removed this component, would it not break the webserver if its using it?

I also have another paseenger file in that directory, which was recently modified (due to upgrade maybe on apr 7). Its called passenger.load and has the following inside it:

LoadModule passenger_module /usr/lib/apache2/modules/

Actually looking again i have a third file, called zpassenger.load and the text of that file is the same as above.
Not really sure how i would proceed.

To be honest, me neither. I never was really familiar with this area and 2.0/1 was a long time ago. Also I was under the impression that this situation )passenger on newer releases) should be almost impossible if the installer was used to perform the upgrade. You already mentioned your colleague did the upgrade as a stepped upgrade, which is good. But did he use the installer to do each of those upgrades or was it done by hand?

He said he didnt use the installer, but used instructions on a foreman website. He only used the installer on the first install. Luckily, he documented the whole process! so maybe something stands out. Sorry its so verbose and messy.

Forman upgrade procedure (THIS DOCUMENT IS A WORK IN PROGRESS):

1.19-1.20, 1.20-1.21, 1.21-1.22, 1.22-1.23, 1.23-1.24, (upgrade to debian buster change the sources.list to buster), 1.24-2.0, 2.0-2.1, 2.1-2.2, 2.2-2.3, 2.3-2.4,2.4-2.5,

2.5-3.0 (Puppet-plugin needs to be added to Foreman 3.0)(puppetserver and puppet-agent need to be v6.15 or higher)

update the repository keys for puppet if an ‘apt-get update’ has errors on puppet:

sudo dpkg -i puppet-release-xenial.deb
sudo apt-get update
If dpkg gives errors due to previously installed keys then remove them with
apt-get remove . I had to remove ‘puppet5-release’ then run the ‘dpkg -i puppet-release-xenial.deb’ again
get the repository key for

wget -q -O- | apt-key add -

gpg --import /root/foreman.asc

gpg --export $KEY_FINGERPRINT > /etc/apt/trusted_gpg.d/foreman.gpg

First edit /etc/apt/sources.list.d/foreman.list and change the release number from the previous release or “stable” to 1.20:

deb stretch 1.20
deb plugins 1.20

Next upgrade all Foreman packages:

systemctl stop apache foreman.service foreman.socket dynflow*

apt-get update
apt-get --only-upgrade install ruby* foreman*

The database should be migrated already, but you can make sure by executing the migration script again, it should produce no errors or output:

foreman-rake db:migrate
foreman-rake db:seed

You should clear the cache and the existing sessions:

foreman-rake tmp:cache:clear
foreman-rake db:sessions:clear

restart services or restart your foreman server

systemctl start apache foreman.service foreman.socket (Not needed if you restart your server)

Foreman 2.5 > 3.0 procedure:

upgrade your puppetserver and puppet-agent to version 6 as per procedure below

after the standard upgrade procedure as above you will need to add the foreman puppet plugin.

apt-get install ruby-foreman-puppet

Upgrade Debin from ‘Stretch’ to ‘Buster’

disable the gui start as the gui may fail during the update

systemctl set-default

change the /etc/apt/sources.list

modify the word ‘stretch’ to ‘buster’

apt update

apt full-upgrade

enable the gui when you are ready with:

systemctl set-default

Upgrade puppetsever and puppet-agent to version 6 (needed by Foreman 3.0)

vi /etc/apt/sources.list.d/puppet.list

modify the repo line to 'deb stretch puppet6

apt-get update

apt-get install --only-upgrade puppetserver

apt-get install --only-upgrade puppet-agent

Check the puppet CA is setup properly and that it can be seen by Foreman:

Do the following on the puppet master (probably on foreman server), also do it on one of the nodes (PC laptops or Workstations)

puppet agent --test --server --ca_server

vi /etc/foreman-proxy/setting.d/puppetca.yml and add the :puppet_version as follows.

:enabled: https

:ssldir: “/etc/puppetlabs/puppet/ssl”

:use_provider: puppetca_hostname_whitelisting

:puppet_version: ‘6.26.0’

vi /etc/foreman-proxy/settings.d/puppetca_http_api.yml make sure the following lines exist and point to the correct directories

URL of the puppet master itself for API requests.

:puppet_url: https://HOSTNAME REMOVED:8140

SSL certificates used to access the CA API.

:puppet_ssl_ca: /etc/puppetlabs/puppet/ssl/certs/ca.pem

:puppet_ssl_cert: /etc/puppetlabs/puppet/ssl/certs/HOSTNAME REMOVED.pem

:puppet_ssl_key: /etc/puppetlabs/puppet/ssl/private_keys/HOSTNAME REMOVED.pem

Oof, that is a handful. Well documented, but completely out of my league :confused:

If you have backups, maybe the easiest way would be just running the installer over it and seeing what happens?

ok! So he was able to fix it. yay!

He ran the installer in test mode, it complained about puppet being out of date and gave a command to fix that, which was run. However this reset some of the defaults for java JVM heap. This led to some instability before we compared configs and found the problem.

Here is his comment:

On the server you should check the puppet server configs and adjust the instances as necessary. Use the tuning guilde from

On our Foreman the puppet server instances are set in /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf. In the puppetserver.conf file look for max-active-instances (default is 4).

The each instance will use 512mb of Java Heap so you will need to modify the puppet startup for java by modifying /etc/default/puppetserver as follows:

If you had 8 instances change the Xms and Xmx to 4G

JAVA_ARGS="-Xms4G -Xmx4G -Djruby.logger.class=com.puppetlabs.jruby_utils.jruby.Slf4jLogger -XX:ReservedCodeCacheSize=512m"

1 Like