Expire-host plugin Debian build

I discovered the neat foreman expire hosts plugin that could be quite useful in my work environment. Unfortunately, there is no Debian build at the moment which is why I can’t add it to my foreman setup.

Since I’ve received so much help from the community I’d like to do my part and support development in turn. What work would building the plugin for Debian involve? I am willing to invest my personal time if someone could help me get started.

Cheers,
Nic

You’ll need to submit a PR to:

I don’t know too much about how to easily get started due to my limited Debian packaging experience.

1 Like

When I build the gemfile locally, convert to a deb file and then install on my server, I get the following error message:

support@server0142:~$ dpkg -i rubygem-foreman-expire-hosts_7.0.0_all.deb
dpkg: error: requested operation requires superuser privilege
support@server0142:~$ sudo dpkg -i rubygem-foreman-expire-hosts_7.0.0_all.deb
(Reading database ... 568861 files and directories currently installed.)
Preparing to unpack rubygem-foreman-expire-hosts_7.0.0_all.deb ...
Unpacking rubygem-foreman-expire-hosts (7.0.0) over (7.0.0) ...
dpkg: dependency problems prevent configuration of rubygem-foreman-expire-hosts:
 rubygem-foreman-expire-hosts depends on rubygem-deface (>= 0); however:
  Package rubygem-deface is not installed.

dpkg: error processing package rubygem-foreman-expire-hosts (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 rubygem-foreman-expire-hosts

However, I do have ruby 2.6.0 installed and selected as default using rvm:

support@server0142:~$ ruby -v
ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux]

So I tried to install the missing dependency manually:


ERROR:  Error installing deface:
        sprockets requires Ruby version >= 2.5.0.
support@server0142:~$ /usr/share/rvm/bin/rvm 2.6.0

No luck…

I built the gemfile like so:

\RubymineProjects\foreman_expire_hosts> gem build .\foreman_expire_hosts.gemspec
WARNING:  open-ended dependency on deface (>= 0) is not recommended
  if deface is semantically versioned, use:
    add_runtime_dependency 'deface', '~> 0'
WARNING:  open-ended dependency on rdoc (>= 0, development) is not recommended
  if rdoc is semantically versioned, use:
    add_development_dependency 'rdoc', '~> 0'
WARNING:  open-ended dependency on rubocop-performance (>= 0, development) is not recommended
  if rubocop-performance is semantically versioned, use:
    add_development_dependency 'rubocop-performance', '~> 0'
WARNING:  pessimistic dependency on rubocop-rails (~> 2.3.2, development) may be overly strict
  if rubocop-rails is semantically versioned, use:
    add_development_dependency 'rubocop-rails', '~> 2.3', '>= 2.3.2'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
  Successfully built RubyGem
  Name: foreman_expire_hosts
  Version: 7.0.0
  File: foreman_expire_hosts-7.0.0.gem

Afterwards I used fpm to create a .deb file from the gem.

fpm -s gem -t deb foreman_expire_hosts
/var/lib/gems/2.5.0/gems/fpm-1.11.0/lib/fpm/util.rb:29: warning: Insecure world writable dir /mnt/c in PATH, mode 040777
Replacing 'provides' underscores with dashes in 'rubygem-foreman_expire_hosts = 7.0.0' because debs don't like underscores {:level=>:warn}
Debian packaging tools generally labels all files in /etc as config files, as mandated by policy, so fpm defaults to this behavior for deb packages. You can disable this default behavior with --deb-no-default-config-files flag {:level=>:warn}
Created package {:path=>"rubygem-foreman-expire-hosts_7.0.0_all.deb"}

Can someaone tell me if I ran into a known problem or if I made a mistake somewhere?

Please don’t use fpm and/or gem2deb, but use an existing plugin as reference…

The Debian packaging, especially the plugins are highly special.

The plugin is now Debian packaged for 1.24 and nightly, please test and report back.

Hi mmoll

Forgive my missing reply and thanks for the initiative. I’ve just returned from a longer leave and will try the build and get back to you

1 Like

@mmoll: I had to upgrade my Foreman instance, as I was running 1.21.3.

On a side note: I actually ran into the same problem as reported here Bug #26788: Unable to upgrade from 1.21.1 to 1.22.x and to 1.23.X with foreman-remote-execution installed - Foreman (though this is not related to the foreman-expire plugin). But was able to resolve it by purging foreman-compute plugin (as well as removing the docker plugin).

Now to the actual topic: The installation went through successfully, and I can see the expire form fields on the Aditional page. (See excerpt from install log at the end)

The pretty warning dialog also shows up:
image

One thing I noticed (let me know if I should open an issue) is that the drop downs are way too narrow for the content of the Year and Month fields. It almost entirely crops the entries and makes them unreadable. Not terrible, just FYI.

Something that confused me was that there is a tool tip “Auto Expiry” that says “Automatically deletes host upon expiry, keep blank to delete hosts manually”. Is this meant to be a checkbox to enable auto expiry or does it simply inform about the consequence of entering an expiry date?

I will ping again once I was able to verify the auto delete feature.

[DEBUG 2020-01-09T10:50:20 main]  Executing: '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install ruby-foreman-expire-hosts'
[ WARN 2020-01-09T10:52:25 main]  /Stage[main]/Foreman::Plugin::Expire_hosts/Foreman::Plugin[expire_hosts]/Package[ruby-foreman-expire-hosts]/ensure: created
[ INFO 2020-01-09T10:52:25 main]  /Package[ruby-foreman-expire-hosts]: Scheduling refresh of Foreman::Rake[apipie:cache:index]
[DEBUG 2020-01-09T10:52:25 main]  /Package[ruby-foreman-expire-hosts]: The container Foreman::Plugin[expire_hosts] will propagate my refresh event
[DEBUG 2020-01-09T10:52:25 main]  Foreman::Plugin[expire_hosts]: The container Class[Foreman::Plugin::Expire_hosts] will propagate my refresh event
[ INFO 2020-01-09T10:52:25 main]  Foreman::Plugin[expire_hosts]: Scheduling refresh of Class[Foreman::Service]
[DEBUG 2020-01-09T10:52:25 main]  Class[Foreman::Plugin::Expire_hosts]: The container Stage[main] will propagate my refresh event
[ INFO 2020-01-09T10:52:25 main]  Foreman::Rake[apipie:cache:index]: Scheduling refresh of Exec[foreman-rake-apipie:cache:index]
[DEBUG 2020-01-09T10:52:25 main]  /Stage[main]/Foreman/Foreman::Rake[apipie:cache:index]/Exec[foreman-rake-apipie:cache:index]: '/usr/sbin/foreman-rake apipie:cache:index' won't
 be executed because of failed check 'refreshonly'
[DEBUG 2020-01-09T10:52:25 main]  Exec[foreman-rake-apipie:cache:index](provider=posix): Executing '/usr/sbin/foreman-rake apipie:cache:index'
[DEBUG 2020-01-09T10:52:25 main]  Executing with uid=foreman: '/usr/sbin/foreman-rake apipie:cache:index'
[ WARN 2020-01-09T10:53:51 main]  /Stage[main]/Foreman/Foreman::Rake[apipie:cache:index]/Exec[foreman-rake-apipie:cache:index]: Triggered 'refresh' from 1 event
[DEBUG 2020-01-09T10:53:51 main]  /Stage[main]/Foreman/Foreman::Rake[apipie:cache:index]/Exec[foreman-rake-apipie:cache:index]: The container Foreman::Rake[apipie:cache:index] w
ill propagate my refresh event
[DEBUG 2020-01-09T10:53:51 main]  Foreman::Rake[apipie:cache:index]: The container Class[Foreman] will propagate my refresh event
[ INFO 2020-01-09T10:53:51 main]  Class[Foreman::Service]: Scheduling refresh of Service[dynflowd]

@TimoGoebel :point_up: - Is this also a problem in the RPMs?

(Screenshot is from latest Chrome browser)

Yeah, we don’t have a proper date picker component in Foreman. That’s something we should improve.

The latter. Do you have a suggestion how we could improve the text.

Actually, we do now: https://github.com/theforeman/foreman/tree/develop/webpack/assets/javascripts/react_app/components/common/DateTimePicker
It’s already used in report template generation and maybe elsewhere

Hi @TimoGoebel ,

I have two suggestions:

  1. Add a checkbox in the plugin settings that enables/disables the deletion of hosts once they expire.
    (I know there is a grace period in the settings, however, deleting the hosts automatically is not necessarily what is desired when adding the expire information on a host)
  2. Rephrase the tooltip: “Expired hosts will be automatically deleted after the grace period (see [link]
    plugin settings) has passed. If manual deletion of hosts is preferred, do not specify an expiry date.”

To be honest with myself: The new tooltip sentence might be too long…

But still, what do you think about my ideas?

I like 'em.

I’ve opened a PR to reword the tooltip and an issue to implement the suggested setting.
Thanks for the feedback.