Removed GUI condition check for RHEL-07-040730

[layluke]

Overall Review of Changes:
Removing GUI condition check for RHEL-07-040730

Issue Fixes:
#464

How has this been tested?:
N/A

[georgenalen]

Hey @layluke.
I'm looking at the PR and the reason for that conditional is that task will remove all GUI components. For folks that are running this role against RHEL7 with a GUI they can set rhel7stig_gui to true and it will leave the GUI. Looking at the task in its current state it should do that, is there a particular issue with it that you are seeing?

[layluke]

Hey @layluke. I'm looking at the PR and the reason for that conditional is that task will remove all GUI components. For folks that are running this role against RHEL7 with a GUI they can set rhel7stig_gui to true and it will leave the GUI. Looking at the task in its current state it should do that, is there a particular issue with it that you are seeing?

@georgenalen Yes, I think there is an issue here still. The issue is, this will remove x11 if rhel7stig_gui is set to false andrhel_07_040730 is set to false. If rhel7stig_gui is true, it just skips the removal. It will also skip the removal if rhel7stig_gui is removed and rhel_07_040730 is set to true (default)

I mentioned it in the issue #464. Currently, there is no way to get x11 to stay unless rhel7stig_gui is set to true, making it impossible to run x11 on a headless system.

Currently rhel_07_040730 has no weight in this conditional check. If there is a way for rhel_07_040730 to take precedence in the conditional that may be ideal. I think that it's implied if it's not running a GUI is not being installed, x windows is usually not there unless you want it to be.

that's why I thought the best way to handle it was to remove the conditional check for rhel7stig_gui, and handle the condition with rhel_07_040730. This will allow it's removal only if explicitly mentioned by setting rhel_07_040730 to false.

Thanks :)

[uk-bolly]

hi @layluke

Thank you for raising this PR. While not a common issue we have seen, i assume other use SSH differently to get around this. This is a great issue to solve if we can.
We have been working on alternative solutions in other repos, related X11 and gui. I have therefore created a new branch gui_fix which i hope explains this slightly better and gives a solution that works in your case and others who use X11.
It would be excellent if you are able to test and see if this fits your and STIG requirements.

Many thanks

uk-bolly

[uk-bolly]

hi @layluke

I have raised a PR to bring in v3r14 and i have incorporated the fix for the gui in to this PR to devel.
Hopefully this covers off this fix for you.

Thank you again for raising the issue and looking at a solution.

Kindest

uk-bolly

[layluke]

hi @layluke

Thank you for raising this PR. While not a common issue we have seen, i assume other use SSH differently to get around this. This is a great issue to solve if we can. We have been working on alternative solutions in other repos, related X11 and gui. I have therefore created a new branch gui_fix which i hope explains this slightly better and gives a solution that works in your case and others who use X11. It would be excellent if you are able to test and see if this fits your and STIG requirements.

Many thanks

uk-bolly

Thanks for looking at this @uk-bolly! I think the merge looks good.

It seems like maybe we're the only ones who use this functionality. Basically, we'll have someone going through a server system, and instead of using a CLI utility (or and IDE that can ssh into the system and browse files) they'll launch something like gedit on the CLI and it will pop up on their local desktop VIA xforwarding. So on servers, there are some cases where there is no gnome, yet a bare bones x11 that is there just for xforwarding, when it boots, there is no desktop, but if there is a gui program installed, it can be utilized using xforwarding.

Thanks again for taking a look!

best regards

layluke

[layluke]

Closing due to a different work around being implemented.