Arch Linux User Repository

If you cannot build because of a missing tar ball or a failed sha256 checksum validation, then the package is most likely outdated and they have removed the old version already. In this case, please click on “Flag package out-of-date”.

Found a fix for "authentication service could not be contacted"

Edit the config file under /home/username/.ICAClient\WFClient.ini and add a new line SSLCiphers=ALL save file and run "killall AuthManagerDaemon ServiceRecord selfservice storebrowse"

Relaunch Citrix and you should be fine

You think because you read it but I can assure you this is not a blocking issue. Try to delete the cert from /etc/ssl/certs , update the ca trust and you will see

@class101
The system has been updated.
This bug prevents remote desktop from opening so I can't ignore it.
And yet, to connect, I use a proxy via ssh on a working PC.

UPD: I fixed it.
Replace:
ProxyHost={host}
ProxyPort={port}
On: ProxyHost={host}:{port}

Magik.

@Bleser

This root cert issue is not a blocker issue, it is just spams in the log. I use to see it when analyzing another problem, you think the issue is coming from this but in reality no.

Just make sure your system is up to date and if you still see it you can just ignore it

I am getting the following error lately.

[W]==> CSDKInitialise:98> (C)2023 Citrix CryptoSDK v14.2.2.0 (OpenSSL 1.1.1t  7 Feb 2023 (Citrix FIPS-capable)) built on Mar 28 2023 16:18:58  
[W]==> initialiseSSLSDKWithParameter:167> (C)2023 Citrix CryptoKit v14.2.2.0 (OpenSSL 1.1.1t  7 Feb 2023 (Citrix FIPS-capable)) built on Mar 28 2023 16:19:01  
[W]==> initialiseSSLSDKWithParameter:198> SSLSDK initialized WITHOUT smartcard support. Compliance Mode is OPEN  
[E]==> certCheckValidityPeriod:668> Certificate (E-Tugra Certification Authority) is already expired!  
[E]==> certCheckValidityPeriod:668> Certificate (E-Tugra Certification Authority) is already expired!  
[E]==> certCheckValidityPeriod:668> Certificate (Hongkong Post Root CA 1) is already expired!  
[E]==> certCheckValidityPeriod:668> Certificate (Hongkong Post Root CA 1) is already expired!  
[E]==> certCheckValidityPeriod:668> Certificate (E-Tugra Certification Authority) is already expired!  
[E]==> certCheckValidityPeriod:668> Certificate (Hongkong Post Root CA 1) is already expired!  
[E]==> certCheckValidityPeriod:668> Certificate (Hongkong Post Root CA 1) is already expired!  
[E]==> certCheckValidityPeriod:668> Certificate (E-Tugra Certification Authority) is already expired!  

Huge step forward too !

The Workspace App infinite loading issue is fixed here. I forgot to set the DNS servers in /etc/resolv.conf of my chroot. I didn't realized probably because the hosts were resolved with the system mounts I have configured in the fstab file and the systemd-resolve service of the base system.

I'm surprised I didn't see this problem sooner because to get around the fact that SteamOS is read-only and has only a poor application directory, I install everything in the chroot which contains an official Arch Linux, and so far an empty resolv file hasn't bothered him :D

I used tools such as squid and zaproxy proxies and the https_proxy env variable to find evidences that the problem was at the HTTP transaction scope with libcurl

If by your chance Workspace never loads you will certainly find like me proofs on the HTTP layer, Citrix uses many ways to authenticate itself and in case there is something wrong, it falls back to default methods, which, when they fail often does not return the real cause of the problem and hide the root cause

Huge step forward! 23.05 is the first version in which HDX realtime audio works reliable for me.

Edit: WIll attempt to forward this as a bug report and keep you informed guys ifI make any advance thus subject, I don't think to find muich alone and it looks like a complex problem which only activates in rare circumstances because my selfservice worked very well a few days ago.

Finally, the issue I identified on my system smells like a bug, when a NetScaler internet gateway is used, circumstances as yet undetermined mean that, the authentication token may be attempted to be retrieved from the NetScaler gateway instead of the internal host...

Under these circumstances, SelfServuice will not return until exactly 30min.

If you are experiencing the same problem, to reproduce what I have found, enable Trace and Verbose in in /opt/Citrix/ICAClient/config/AuthManConfig.xml

You will see then it hangs there, because the url sent to curl returns 404, and the code is waiting 10min for a response, and is attemptingh this 3 times

CHttpTransactionBase::SendAndReceive
{
.   virtual void AM::Networking::CLinuxHttpTransaction::CheckedSendAndReceive()
.   {
.   .   m_easyResult: 52; error string from curl: 'Empty reply from server'
.   .   CheckedSendAndReceive client cert none
.   .   Throwable created: CHttpException: CheckedSendAndReceive(); server URL: 'https://NetScalerGatewayInternetHost/Citrix/Auth/auth/v1/token'
.   .   Throwable created: CLinuxHttpException: CheckedSendAndReceive(); m_Reason=1 m_Curlcode=52; url: 'https://NetScalerGatewayInternetHost/Citrix/Auth/auth/v1/token'
.   }
}

https://NetScalerGatewayInternetHost/Citrix/Auth

And I suspect it wanted to contact instead the internal host

https://InternalHost/Citrix/Auth/auth/v1/token

Because in several other places of the traces, this url works perfectly but on the internal host!

Hello buzo :)

I also think the .gitignore shouldn't cause any problems, I found it odd that it's there, because in general AUR packages are so small that ignoring files is more of an error-prone than a real benefit.

I didn't quite understand otherwise where the users' error came from when updating but it doesn't matter now that you have updated the release package, that must be ancient history.

Regarding the bug of the selfservice which fails to load the App and Desktop, I advance a little

When the bug happens here, the VERBOSE log always breaks at this step

citrix-selfservice: [selfservice]: Request to discovery URL: https://redacted/discovery 
citrix-selfservice: [selfservice]: Completed dicovery successfully 
citrix-selfservice: [selfservice]: <?xml version="1.0" encoding="utf-8"?>
citrix-selfservice: [selfservice]: Parsed dicovery document 
citrix-selfservice: [selfservice]: -Gen_DSController::ConnectToStore downloaded discovery document successfully 
citrix-selfservice: [selfservice]: Request to EndPoint URL: redacted
citrix-selfservice: [selfservice]: <?xml version="1.0" encoding="utf-8"?><endpoints xmlns="http://citrix.com/deliveryservices/1-0/endpoints">...
citrix-selfservice: [selfservice]: Request to Resource Enumeration URL: https://redacted/resources/v2 

And I think the above can be reproduced by typing

/opt/Citrix/ICAClient/util/storebrowse -E https://redacted/resources/v2

And indeed, the above command for me does never returns and hangs for ever

This is what happens when the Citrix SelfSDervice application does not return my apps.

And from this analysis there is no sign of application crash or unhandled exceptions at first glance but just a response that is never received.

The next step would be to contact the Citrix team to find out if this is a known bug, because it looks like it!

@class101: I don't see why .gitignore should be a problem. It just prevents git status from showing the tar balls (downloaded as well as results from builds). But then, I don't use makepkg directly, I always build in a clean chroot to make sure I get the dependencies right. As a side effect, this keeps the checked out dir quite clean, so I've never seen a need for git clean.

Sorry for the late update, I've been quite busy.