Hi all.

To access Citrix, I've been using on Slackware the Chrome plugin for years:
https://chrome.google.com/webstore/detail/citrix-workspace/haiffjcadagjlijoggckpgfnoeiflnem
Following the latest version of Alien's Chromium on Sat May 27 17:55:32
UTC 2023 (see
http://www.slackware.com/~alien/slackbuilds/ChangeLog.txt), the plugin
has finally stopped working.

These are the steps I took to regain access to my workplace's Citrix
environment. Hope it helps.

-----------------------------------------------------------------
# Login as root
sudo su -l

# Download, compile and install, in this order:

# http://slackbuilds.org/repository/15.0/development/unifdef/
# https://slackbuilds.org/repository/15.0/libraries/libsoup3/
# https://slackbuilds.org/repository/15.0/libraries/libwpe/
# https://slackbuilds.org/repository/15.0/libraries/wpebackend-fdo/
# https://www.slackbuilds.org/repository/15.0/libraries/webkit2gtk4.1/
(this one took hours to compile)

# Go to the page
#
https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html

# Navigate to Tarball Packages
# --> Citrix Workspace app for Linux (x86_64)
# --> Download file
# At this time the file is
https://downloads.citrix.com/21784/linuxx64-23.3.0.32.tar.gz

# Unzip the file
tar -xzvf [your-download-directory]/linuxx64-23.3.0.32.tar.gz

# Execute the setup script, accepting the default settings:
[your-download-directory]/linuxx64-23.3.0.32/setupwfc

# Back from root to your user
exit

# Open a web browser and navigate to your organization Citrix gateway
(ask your admins, ex.: https://citrix.yourorg.com).
# You might get an error message saying that "... you have not chosen to
trust the certificate... SSL eror 61...".
# See
https://support.citrix.com/article/CTX203362/error-ssl-error-61-you-have-not-chosen-to-trust-certificate-authority-on-receiver-for-linux
# You better ask to your administrator for this one. Basically, you need
to copy into /opt/Citrix/ICAClient/keystore/cacerts/
# the root certificate used by https://citrix.yourorg.com. You may
download it with your browser (see relevant docs) and simply copy it in
the Citrix cacerts directory:
sudo cp -v ~/[your-download-directory]/your-root-certificate.pem
/opt/Citrix/ICAClient/keystore/cacerts/
# If necessary adjust ownership and permissions:
sudo chown -v root:sys
/opt/Citrix/ICAClient/keystore/cacerts/your-root-certificate.pem
sudo chmod -v a-wx
/opt/Citrix/ICAClient/keystore/cacerts/your-root-certificate.pem

--
/

Hi, Slash

Thanks for the interesting article.

I'd like to add a single tip, if I may...

On Tue, 30 May 2023 16:58:06 +0200, slash wrote:

[snip]
> -----------------------------------------------------------------
> # Login as root
> sudo su -l

Here, you use sudo(8) to execute the su(1) command, such that you get a
root "login" shell. I imagine that you do it this way as the su(1)
command gives you the root shell, and your username is in the
/etc/sudoers file, with permission to run su(1), alleviating the need
to know or use the root password.

Did you know that you could
sudo -i
and get the same results as your
sudo su -l
?

[snip]

HTH
--
Lew Pitcher
"In Skills We Trust"

On 5/30/23 18:20, Lew Pitcher wrote:
> Hi, Slash
>
> Thanks for the interesting article.
>
> I'd like to add a single tip, if I may...
>
> On Tue, 30 May 2023 16:58:06 +0200, slash wrote:
>
> [snip]
>> -----------------------------------------------------------------
>> # Login as root
>> sudo su -l
>
> Here, you use sudo(8) to execute the su(1) command, such that you get a
> root "login" shell.

Hi Lew, yes, that's the purpose.

> I imagine that you do it this way as the su(1)
> command gives you the root shell, and your username is in the
> /etc/sudoers file, with permission to run su(1), alleviating the need
> to know or use the root password.

Yes, I'm in the sudoers file:
slash ALL=(ALL:ALL) NOPASSWD: ALL

> Did you know that you could
> sudo -i
> and get the same results as your
> sudo su -l
> ?

No, I didn't know that, thanks for the tip. I've quickly browsed the man
pages of su and sudo. Is there any practical difference between
"sudo su -l" and "sudo -i"?
For example, with "sudo -i" do you still need to be in /etc/sudoers or
not? Any other advantage of "sudo -i" over "sudo su -l"?

Thanks, bye,

--
/

On Wed, 31 May 2023 06:23:55 +0200, slash wrote:

> On 5/30/23 18:20, Lew Pitcher wrote:
>> Hi, Slash
>>
>> Thanks for the interesting article.
>>
>> I'd like to add a single tip, if I may...
>>
>> On Tue, 30 May 2023 16:58:06 +0200, slash wrote:
>>
>> [snip]
>>> -----------------------------------------------------------------
>>> # Login as root
>>> sudo su -l
>>
>> Here, you use sudo(8) to execute the su(1) command, such that you get a
>> root "login" shell.
>
> Hi Lew, yes, that's the purpose.
>
>> I imagine that you do it this way as the su(1)
>> command gives you the root shell, and your username is in the
>> /etc/sudoers file, with permission to run su(1), alleviating the need
>> to know or use the root password.
>
> Yes, I'm in the sudoers file:
> slash ALL=(ALL:ALL) NOPASSWD: ALL
>
>> Did you know that you could
>> sudo -i
>> and get the same results as your
>> sudo su -l
>> ?
>
> No, I didn't know that, thanks for the tip. I've quickly browsed the man
> pages of su and sudo. Is there any practical difference between
> "sudo su -l" and "sudo -i"?

No practical difference, but perhaps a minor performance difference.
With
sudo su -l
you run two processes: sudo and su
while, with
sudo -i
you only run one process.

> For example, with "sudo -i" do you still need to be in /etc/sudoers or
> not?

Yes, you will still need an entry in /etc/sudoers to run sudo -i, just
as you did for sudo su -l

With
sudo -i
we just eliminate the (unnecessary) su command.

> Any other advantage of "sudo -i" over "sudo su -l"?

It's easier to remember? That's all I got :-)

--
Lew Pitcher
"In Skills We Trust"

On 5/31/23 21:10, Lew Pitcher wrote:
> On Wed, 31 May 2023 06:23:55 +0200, slash wrote:
<cut>
>> No, I didn't know that, thanks for the tip. I've quickly browsed the man
>> pages of su and sudo. Is there any practical difference between
>> "sudo su -l" and "sudo -i"?
>
> No practical difference, but perhaps a minor performance difference.
> With
> sudo su -l
> you run two processes: sudo and su
> while, with
> sudo -i
> you only run one process.
>
>> For example, with "sudo -i" do you still need to be in /etc/sudoers or
>> not?
>
> Yes, you will still need an entry in /etc/sudoers to run sudo -i, just
> as you did for sudo su -l
>
> With
> sudo -i
> we just eliminate the (unnecessary) su command.
>
>> Any other advantage of "sudo -i" over "sudo su -l"?
>
> It's easier to remember? That's all I got :-)

Fair enough, thanks for your hints, it's always good to learn something new.

--
/

On 5/30/23 16:58, slash wrote:

> These are the steps I took to regain access to my workplace's Citrix
> environment. Hope it helps.

I forgot a step. The Citrix tarball might expect a webkit2gtk version
different from the one you just got from slackbuilds.org, so you might
need to create a link to the Slackbuilds library with the filename
expected by Citrix. Here is the adjusted procedure:

------------------------------------------------------------------
# Login as root
sudo su -l # (...or sudo -i, as per Lew's suggestion)

# Download, compile and install, in this order:

# http://slackbuilds.org/repository/15.0/development/unifdef/
# https://slackbuilds.org/repository/15.0/libraries/libsoup3/
# https://slackbuilds.org/repository/15.0/libraries/libwpe/
# https://slackbuilds.org/repository/15.0/libraries/wpebackend-fdo/
# https://www.slackbuilds.org/repository/15.0/libraries/webkit2gtk4.1/

# Go to the page
#
https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html

# Navigate to Tarball Packages
# --> Citrix Workspace app for Linux (x86_64)
# --> Download file
# At this time the file is
https://downloads.citrix.com/21784/linuxx64-23.3.0.32.tar.gz

# Unzip the file
tar -xzvf [your-download-directory]/linuxx64-23.3.0.32.tar.gz

# On the following step you might get an error saying
# "One of the prerequisites required for installation is not
present-"libwebkit2gtk-X.X.so.X" not found..."
# If this happens, you need to create a link to he libwebkit2gtk... file
using
# the filename expected by the Citrix installer.
# With the versions listed above, this is what you need:
ln -s -v /usr/lib64/libwebkit2gtk-4.1.so.0.8.2
/usr/lib64/libwebkit2gtk-4.0.so.37
# Adjust the filenames accordingly with the versions of
slackbuilds.org's webkit2gtk and the Citrix's tarball
# you are working with. You might not need to create any link if the two
parties happen to be in sync.

# Execute the setup script, accepting the default settings:
[your-download-directory]/linuxx64-23.3.0.32/setupwfc

# Back from root to your user
exit

# Open a web browser and navigate to your organization Citrix gateway
(ask your admins, ex.: https://citrix.yourorg.com).
# You might get an error message saying that "... you have not chosen to
trust the certificate... SSL eror 61...".
# See
https://support.citrix.com/article/CTX203362/error-ssl-error-61-you-have-not-chosen-to-trust-certificate-authority-on-receiver-for-linux
# You better ask to your administrator for this one. Basically, you need
to copy into /opt/Citrix/ICAClient/keystore/cacerts/
# the root certificate used by https://citrix.yourorg.com. You may
download it with your browser (see relevant docs) and simply copy it in
the Citrix cacerts directory:
sudo cp -v ~/[your-download-directory]/your-root-certificate.pem
/opt/Citrix/ICAClient/keystore/cacerts/
# If necessary adjust ownership and permissions:
sudo chown -v root:sys
/opt/Citrix/ICAClient/keystore/cacerts/your-root-certificate.pem
sudo chmod -v a-wx
/opt/Citrix/ICAClient/keystore/cacerts/your-root-certificate.pem

On Tue, 30 May 2023 16:58:06 +0200, slash wrote:

> # Login as root
> sudo su -l

On Slackware sudo, useful in some cases, is redundant to run su for root
login shell.

beowulf@gandalf: ~ $ su -
Password:

....

root@gandalf:~# exit
logout
beowulf@gandalf: ~ $

see "man su"

-KB

On 6/6/23 22:43, King Beowulf wrote:

> On Slackware sudo, useful in some cases, is redundant to run su for root
> login shell.
>
> beowulf@gandalf: ~ $ su -
> Password:

Of course, but this requires you to know the root's password.

--
/

On Wed, 07 Jun 2023 13:21:57 +0200, slash wrote:

> On 6/6/23 22:43, King Beowulf wrote:
>> On Slackware sudo, useful in some cases, is redundant to run su for
>> root login shell.
>>
>> beowulf@gandalf: ~ $ su -
>> Password:
>
> Of course, but this requires you to know the root's password.

That is true, but any user trusted to do "sudo -i" has the power to more
or less temporary change the root password and should then also be
considered trusted to know the root password.

regards Henrik

On 6/8/23 07:33, Henrik Carlqvist wrote:
> On Wed, 07 Jun 2023 13:21:57 +0200, slash wrote:
>
>> On 6/6/23 22:43, King Beowulf wrote:
>>> On Slackware sudo, useful in some cases, is redundant to run su for
>>> root login shell.
>>>
>>> beowulf@gandalf: ~ $ su -
>>> Password:
>>
>> Of course, but this requires you to know the root's password.
>
> That is true, but any user trusted to do "sudo -i" has the power to more
> or less temporary change the root password and should then also be
> considered trusted to know the root password.

All true, but why insert the root password if you can spare keyboard
consumption by using sudo -i? And why waste the time to put you in
sudoers if you have the root password?
We might as well conclude that sudo is useless. :-)

--
/

On 2023-06-08, slash wrote:

> ... why insert the root password if you can spare keyboard consumption
> by using sudo -i? And why waste the time to put you in sudoers if you
> have the root password?
> We might as well conclude that sudo is useless. :-)

Depending on the environment, it largely is. As an example, on my home
systems, with only two trusted users, both of whom have the root
password, no sudo. At work, where we need to provide selective
privilege elevation to certain subsets of users, sudo.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca
----------------------------------------------------------------------