Bug 2017903
| Summary: | [RFE] gnome-shell-extension-heads-up-display body from file | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Pat Riehecky <riehecky> |
| Component: | gnome-shell-extensions | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED MIGRATED | QA Contact: | Michael Boisvert <mboisver> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | CentOS Stream | CC: | bstinson, jadahl, jkoten, jwboyer, misterbonnie, rstrode, tpelka, tpopela |
| Target Milestone: | rc | Keywords: | FutureFeature, MigratedToJIRA, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-09-15 16:55:00 UTC | Type: | Story |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Pat Riehecky
2021-10-27 16:44:38 UTC
Are you enabling the feature using the gnome-extensions settings ui? (the gnome-extensions-app command) ? Assuming yes, you can actually configure this in a config file using dconf. For instance, by creating a file called /etc/dconf/db/local.d/99-banner.conf To know what to put in it, create a fresh user, go into the settings UI and enable the extension and set the message, then run, $ dconf dump / It will show all the settings the user has set that differ from defaults. In particular it could show, for example: [org/gnome/shell/extensions] enabled-extensions=['heads-up-display.github.com'] [org/gnome/shell/extensions/heads-up-display] message-body='This machine is the property of the US Government.\n\nUnauthorized access is strictly prohibited.\n\nAbusers will be prosecuted to the fullest extent of the law.\n' message-heading='CLASSIFIED SYSTEM' show-when-locked=false show-when-unlocked=true show-when-unlocking=true By putting that in /etc/dconf/db/local.d/99-banner.conf and running "dconf update" after making changes, the setting can be controlled from the file. You could imagine taking this a step further, by computing the setting from /etc/motd... Say with a script, update-message-banner.sh, like so: #!/bin/bash cat << EOF > "/etc/dconf/db/local.d/99-banner.conf" [org/gnome/shell/extensions] enabled-extensions=['heads-up-display.github.com'] [org/gnome/shell/extensions/heads-up-display] message-heading="$(head -n1 /etc/motd)" message-body="$(tail -n+2 /etc/motd | sed -z 's/\n/\\n/g')" show-when-locked=true show-when-unlocked=true show-when-unlocking=true EOF dconf update That script would take the first line of /etc/motd and put it in the heading and all other lines in the body of the banner. Then you would just need to run "update-message-banner.sh" any time /etc/motd changes by running the script from systemd with a path monitoring unit. e.g., /etc/systemd/system/motd.path [Unit] Wants=update-message-banner.service [Path] PathChanged=/etc/motd and /etc/systemd/system/update-message-banner.servce [Service] Type=simple ExecStart=/usr/local/bin/update-message-banner.sh Does that meet your needs? If so great, let's close this out. If not, I guess we could add some new setting "message-file" or "message-command" that makes it read from a file or run a command directly from within gnome-shell, but that setting would then conflict with message-header/message-body. We would have to establish a precedence or something like that to know which settings to honor and which to ignore if both the old ones and the new one are set. The downside of reading it at runtime is it may require changes to SELinux policy to e.g. allow the login screen to read the file depending on which file is getting read. Hello, That comes close to what I'm looking for. I might be able to tweak this into shape.... Ideally, a "message-file" with an inotify on the file would be much less setup. I guess we could make the precedence explicit by adding two new keys: 1. message-file 2. message-source where the latter could be a string to say whether to honor message-file or message-header/message-body. Would you want the file format to be --- Heading The message body goes here. --- or --- Heading The message body goes here. --- or something different? One concern I have is the nature of the banner (it's size, placement on screen, etc) means that not all messages are a good fit for it. By adding a file browser to the preferences dialog, the extension potentially makes it easy for the user to put a wall of text on their screen. Nothing catastrophic, but it's a bit of a UI niggle. A format something like: --- Heading The message body goes here. --- Would be great! I don't think this is going to make 9.0 at this point, proposing for a future update. Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |