RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1357648 - Brandbot cannot be disabled
Summary: Brandbot cannot be disabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts
Version: 7.2
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: David Kaspar // Dee'Kej
QA Contact: Daniel Rusek
URL:
Whiteboard:
Depends On: 1395391 1493545
Blocks: ovirt-node-ng-platform 1359645 1380361 ovirt-node-ng-43-el76-platform 1465901
TreeView+ depends on / blocked
 
Reported: 2016-07-18 18:38 UTC by Ryan Barry
Modified: 2018-04-10 18:26 UTC (History)
10 users (show)

Fixed In Version: initscripts-9.49.40-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1359645 (view as bug list)
Environment:
Last Closed: 2018-04-10 18:24:45 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1204194 0 unspecified CLOSED /etc/os-release on Atomic is modified by subman (disable brandbot.[path|service] ?) 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1355727 0 high CLOSED PRETTY_NAME=CloudForms show on RHVH login screen and cockpit UI after RHVH registered to RHSM 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1359645 0 urgent CLOSED Brandbot cannot be disabled 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2018:0983 0 None None None 2018-04-10 18:26:24 UTC

Internal Links: 1204194 1355727 1359645

Description Ryan Barry 2016-07-18 18:38:14 UTC 
Description of problem:
Brandbot aggressively rewrites PRETTY_NAME, and here is no way to disable brandbot's behavior other than masking systemd units.

Version-Release number of selected component (if applicable):
initscripts-9.49.30-1.el7_2.2

How reproducible:
100%

Steps to Reproduce:
1. Install any system which does not have a branded "OS", but sets PRETTY_NAME (RHV-H, for example)
2. Register to an account which has an entitlement for a branded "OS", or even "echo foobar > /var/lib/rhsm/branded_name"

Actual results:
3. PRETTY_NAME is overwritten
4. The only way to disable this is to disable/mask brandbot.[path|service]

Expected results:
There should be a way to disable brandbot. Even if this way is changing brandbot to an actual activated service, instead of one which is disabled and triggered by brandbot.path in some way.
Comment 2 Fabian Deutsch 2016-07-18 19:11:08 UTC 
Another considertaion would be to make the behavior - rewrite PRETTY_NAME - configurable.

Disabling brandbot completely might be pretty invasive (not sure what else functionality brandbot is porviding).
Comment 3 Lukáš Nykrýn 2016-07-19 07:06:48 UTC 
That is the only thing that brandbot is doing. TO be host, I have no idea if we want the possibility for user to "easily" disable brandbot. This goes beyond engineering. Let's try to ask someone who was behind this feature for rhel7. https://mojo.redhat.com/docs/DOC-186259
Comment 4 Adrian Likins 2016-07-22 17:21:29 UTC 
> (In reply to Fabian Deutsch from comment #2)

> Disabling brandbot completely might be pretty invasive (not sure what else
> functionality brandbot is porviding).

I don't work on subscription-manager/entitlements anymore, so current team would be better to ask ('chainsaw' team, aka candleping/subscription-manager dev team https://mojo.redhat.com/docs/DOC-19860).


I doubt anyone would notice if it was disabled to be honest, but that is not really my call anymore ;->

Updating PRETTY_NAME is pretty much the only functionality provided by brandbot.
The purpose of brand bot was to provide a way to change things like /etc/issue for RHEL to reflect more specific products/subscriptions/entitlements.

ie, so if I bought 'Red Hat Enterprise Linux Server (Super Turbo Bundle Edition)', the 'bits' for RHEL are the same as every other RHEL Server (69.pem) version so the default PRETTY_NAME is "Red Hat Enterprise Linux Server", but the subscription/product wants PRETTY_NAME to be 'Red Hat Enterprise Linux Server (Super Turbo Bundle Edition)'.

That info is included in the entitlement certificate and subscription-manager/rhsmcertd will update /var/lib/rhsm/branded_name causing the brandbot.path service to trigger /usr/libexec/initscripts/brandbot that changes /etc/os-release.

AFAIK, it is for purely cosmetic purposes (in the sense that nothing really depends on the value of PRETTY_NAME, at least nothing entitlement related). If there are tools that make decisions based on PRETTY_NAME brandbot will likely confuse them.
Comment 5 Lukáš Nykrýn 2016-07-25 08:16:00 UTC 
Ok, let's create a clone for redhat-release-* packages to request adding brandbot* to presets and then make it disableable.
Comment 8 David Kaspar // Dee'Kej 2017-09-20 13:31:36 UTC 
Pull-request to fix BZ #1395391 submitted for review:
https://github.com/fedora-sysv/initscripts/pull/128

This pull-request also fixes this issue.
Comment 17 errata-xmlrpc 2018-04-10 18:24:45 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0983
Note You need to log in before you can comment on or make changes to this bug.