Bug 1570172 - insights-client is not registered when installed by the ansible role redhat-access-insights-client
Summary: insights-client is not registered when installed by the ansible role redhat-a...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Hybrid Cloud Console (console.redhat.com)
Classification: Red Hat
Component: Client
Version: unspecified
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
: ---
Assignee: jcrafts
QA Contact: Jeff Needle
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-20 19:55 UTC by Gavin Romig-Koch
Modified: 2018-09-24 16:24 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-24 16:24:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Gavin Romig-Koch 2018-04-20 19:55:40 UTC
One of the requirements on the new client (insights-client) and it's installation was that it continue to support existing scripts, playbooks, etc. that use or depend on the old client (redhat-access-insights).

The redhat-access-insights-client does not work with the new client.  The script does indeed install the new client, but does not ever register the host with the server. 

The ansible role must test for the existence of /etc/redhat-access-insights/.registered to avoid rerunning "redhat-access-insights --register" when it isn't necessary.  Any script (ansible, puppet, chef, bash, ...) that runs on a regular bases to ensure that a server's configuration is correct would need to do the same thing.

The RPM installation of the new client makes that file a soft link to the location of the new clients version of that file.  A soft link always exists, even if the file it points to does not.  So scripts that test for the existance of this file, find it always exists, and so will never run 'register'.

Comment 2 jcrafts 2018-07-02 19:29:32 UTC
Fixed via https://github.com/RedHatInsights/insights-core/commit/6a76245a87611074917e70a4b22efbff8b824dd1

Delete existing symlinks on run, and recreate dotfile as a real file, maintain both locations.

Comment 3 jcrafts 2018-07-02 19:43:39 UTC
Symlinks for these files should also be explicitly deleted by the RPM spec, will be included next RPM release.


Note You need to log in before you can comment on or make changes to this bug.