Comment 1 Emelie 2024-11-26 16:17:53 CET

An idea is to use a Python subprocess, running as the user, not root. It seems we can get the underlying username from the environment variable SUDO_USER.

Comment 4 Samuel Mannehed 2024-11-27 15:05:47 CET

> MUST:
> - When clicking links in tl-setup and installer, the page must open in a browser.
Yes! A browser is attempted to be opened through 'xdg-open'. If that doesn't work, the default Gtk behavior is used as a fallback.
> SHOULD:
> - Links should show link-texts instead of urls when suitable.
Yes. This was enabled in commit r41356 and r41356 on bug 6144.
> - Future developers should not have to actively make links clickable.
By using a tlgtk.Label class, we get this handler for all labels.
> COULD:
> - Additional links could be added to other pages in tl-setup.
More work could be done here, but we added a link to the sudo-page in tl-setup.

Comment 6 Samuel Mannehed 2024-11-27 16:26:40 CET

Created attachment 1247 [details]
screenshot of error on rhel 9

Tested on Fedora 41, it works well. But on RHEL 9, it seems some environment variable is missing. If no browser is running, one opens properly. But if there is an existing Firefox window, we get an error when clicking a link in tl-setup, as seen in the attached screenshot.

Comment 7 Samuel Mannehed 2024-11-27 20:32:48 CET

(In reply to Samuel Mannehed from comment #6)
> Created attachment 1247 [details]
> screenshot of error on rhel 9
> 
> Tested on Fedora 41, it works well. But on RHEL 9, it seems some environment
> variable is missing. If no browser is running, one opens properly. But if
> there is an existing Firefox window, we get an error when clicking a link in
> tl-setup, as seen in the attached screenshot.
The following is printed to stderr:
> which: no firefox in ((null))
> /bin/xdg-open: line 811: : command not found
> /bin/xdg-open: line 881: x-www-browser: command not found

Comment 8 Samuel Mannehed 2024-11-27 21:06:48 CET

It seems XDG_RUNTIME_DIR is the environment variable that we need, at least for Firefox on RHEL 9.

Comment 9 Samuel Mannehed 2024-11-28 08:56:43 CET

(In reply to Samuel Mannehed from comment #8)
> It seems XDG_RUNTIME_DIR is the environment variable that we need, at least
> for Firefox on RHEL 9.

The environment differs when starting `tl-setup` using our sudo-relaunch (without specifying sudo), and when explicitly writing `sudo tl-setup`. XDG_RUNTIME_DIR isn't available in sudo's env in the latter case.

Comment 12 Samuel Mannehed 2024-11-28 13:42:46 CET

On Ubuntu 24.10, we found two other issues in different scenarios:

 * If running a Wayland session, the WAYLAND_DISPLAY environment variable is needed for xdg-open to be able to start a graphical application.
 * If Firefox (or probably any browser) is installed as a snap, the XDG_DATA_DIRS environment variable is required for xdg-open to find the binary.

Comment 13 Samuel Mannehed 2024-11-29 10:12:54 CET

Sadly, testing shows that we can't make it work easily in all cases.

The XDG_RUNTIME_DIR variable breaks things on RHEL 9 when running Wayland and tl-setup is started with `sudo tl-setup`, it fails to open links using xdg-open. If XDG_RUNTIME_DIR is not set, an X11 fallback is used instead - which works for opening links in all cases.

However, for Ubuntu, we always need XDG_RUNTIME_DIR.

This means we need a good fallback method for the cases where opening the link fails.

Comment 20 Samuel Mannehed 2024-11-29 10:59:32 CET

The issues in comment 6, comment 8 and comment 12 are now fixed. A fallback as was mentioned in comment 13 was also implemented; when opening the link in a browser fails, we will put the URL in the clipboard instead. In this case, a toast-style notification is shown to the admin.

Tested on RHEL 9 and Ubuntu 24.10.

Comment 23 Samuel Mannehed 2024-11-29 11:27:08 CET

To follow up on the acceptance criteria notes in comment 4:

> MUST:
> - When clicking links in tl-setup and installer, the page must attempt to open in a browser.
Yes, it works in most cases. The only known scenario where opening a link doesn't work is on RHEL 9 when all three bullet-points below are true:
 * you are running Wayland
 * there is no web browser window open
 * tl-setup was started with `sudo /opt/thinlinc/sbin/tl-setup`

> SHOULD:
> - If opening a link fails, a good fallback should be in place.
If opening a link fails, the link URL is copied to the clipboard.

If tl-setup isn't running as sudo (if you're running as root graphically), the default Gtk behavior is used.

Comment 24 Samuel Mannehed 2024-11-29 16:19:02 CET

More detailed testing revealed that things weren't working as well as we thought. For example:

* Debian 12:
  - tl-setup started without sudo
  - both when using Firefox and Chrome as default browser
> X (Authorization required, but no authorization protocol specified. Error: cannot open display:0)
* PopOS:
  - tl-setup started with sudo
  - using Chrome as default browser (probably because root's default browser was still Firefox)
> Firefox is already running but not responding
* Fedora 41:
  - tl-setup started without sudo
  - no browser window was previously open
  - using Chrome as default browser
>X (Missing X server or $DISPLAY. The platform failed to initialize. Exiting)
* Ubuntu 24.10:
  - tl-setup started with sudo
  - a browser window was already open
  - using Firefox as default browser
> Firefox is already running but not responding
  - no browser window was previously open
  - using Firefox as default browser
>X (Missing X server or $DISPLAY. The platform failed to initialize. Exiting)

---

Due to the many issues, we have decided to revert the changes that attempt to open a link. The part about copying the URL to the clipboard will be kept, and handled under bug 8468.

For the future, a better idea is to try to separate the UI from the parts of tl-setup that needs escalated privileges. This would allow us to run the Gtk UI as the user. Note bug 7358 on the subject.

Moving this bug back to "LowPrio".