[Citrix Products affected from log4j zero-day vulnerability (CVE-2021-44248)?]

On 12/11/2021 at 6:56 AM, Scott Bowling said:

The Linux VDA appears to be impacted. But won't really know till Citrix support provides updates.

 

I do see that log4j is available and used for debugging for Linux VDA...but commented out...not sure if that is enough though..

 

[Any way to remove a XEN patch easily?]

I'm running XEN 8.2 and have a pool (20 host) patched to XS82E024 patch level and see that there is a new 026 patch. I have about a dozen new hosts i need to add to that pool, but i don't want to upgrade the entire pool because just  yet.

 

I just want to run the automated updates and get all of the updates then remove the 026 patch if possible before adding to pool.  Otherwise I think the only other way is to do them individually to 024 for all new new hosts.

 

Saw this old thread from 2012 but not sure if it still applies.

https://discussions.citrix.com/topic/303768-remove-a-patch-installed/

 

[Citrix 1912 site and minimum vda version]

We recently migrated some test VDA's to the Citrix Cloud. Not exactly sure what version they are on but i believe they are always greenfield. so the latest. We immediately saw issues with registration on Linux VDA's with 18.08 and lower while any LVDA with 19.09 or newer worked fine. This happens with any policy change, studio pushes down the policy and the older LVDA's can't read it, thus sending the LVDA in a registration loop, registering OK, then fails on policy check, then tries to re-register, repeating this every min or so.

 

The fix was to update the Xorg on the older VDA's to work with the newer 19.12LTSR e.g. installing Xorg 1.20.4 on our Cent7.4 which originally was running 1.19.5 + 19.12LTSRcu2 is working in Citrix cloud with the latest. This is also supposedly officially supported by Citrix. (Supported meaning they will support the required components like Xorg + VDA regardless of OS version) 

 

RH6.8 (lVDA 7.15LTSR) , Cent.74 (18.08) no longer registers with Cloud connector. 

 

2020-12-07 16:29:45.741 [INFO ] [11535] - The Citrix Desktop Service successfully obtained the following list of 2 delivery controller(s) with which to register: 'xsj-***.com (), xsj-com ()'.

2020-12-07 16:29:47.262 [ERROR] [21] - VdaState.AssignVdaStateInfo: Failure. Error: Could not find [PolicySetting] on: VdaParametersAccessors.DefinedFeatures

2020-12-07 16:29:47.269 [ERROR] [21] - MxPolicyManager.WriteSinglePolicy: Failed to uncompress policy information. Error: 'Expected this cabinet CFFOLDER to have a compression type of 1, but found it to be 4611.'

2020-12-07 16:29:47.270 [ERROR] [21] - ConfigurationManagerService.Set: Exception: MxPolicyManager.ProcessMultipleMxPolicies: Error while saving policy settings - Location=/var/xdl/vda Exception=Expected this cabinet CFFOLDER to have a compression type of 1, but found it to be 4611.

2020-12-07 16:29:47.433 [INFO ] [11535] - The Citrix Desktop Service successfully registered with delivery controller xsj.com (IP Address 1).

The endpoint address of the controller is http://xsjcom:80/Citrix/CdsController/IRegistrar.

2020-12-07 16:29:52.507 [ERROR] [11537] - AgentHeartBeatCBPv1_5.SendHeartbeatCbpV15Thread: Heartbeat to http://xsj-.com:80/Citrix/CdsController/IRegistrar rejected

2020-12-07 16:29:52.507 [WARN ] [11537] - The Citrix Desktop Service's connection to the Citrix Desktop Delivery Controller Service was terminated. The Citrix Desktop Delivery Controller Service is running on server 'xsj.com'.

Check that there is no active firewall blocking the controller communicating with this machine.

Please refer to Citrix Knowledge Base article CTX117248 for further information.

[XEN 8.2 /var/log/secure filling up with to 3GB every few weeks crashing hosts]

We did open a case with Citrix, they had me try option "B"  that did work on some hosts. But not all hosts. We ended up doing opiton "A" and just limiting the logging.

 

A)

1) Edited file /etc/rsyslog.d/xenserver.conf and comment below line

authpriv.warning                                             -/var/log/secure

 

B)

1) Put the host into maintenance mode if HA is enabled.
2) Run command "> secure"
3) Run command "xe-toolstack-restart"
4) Run command "logrotate -f -v /etc/logrotate.conf"
5) Run command "logrotate -f -v /etc/logrotate-xenserver.conf"
6) Run command "systemctl restart rsyslog.service"
7) Repeat step 3

 

Now, i'm seeing my xensource.log getting filled up. 

[XEN 8.2 /var/log/secure filling up with to 3GB every few weeks crashing hosts]

Hi, this was a fresh build from ISO.  We did not muck with any partition layout. Thanks

[XEN 8.2 /var/log/secure filling up with to 3GB every few weeks crashing hosts]

We recently moved from VMWare to XEN and its been working ok so far, but I have been getting alerts regarding the Control domain getting full. I do see that the /var/log/secure file is growing a very fast pace with all stunnel traffic logs. 

 

At first i just ignored it, but then my host crashed due to it. I currently  have a script that purges the secure file every time i get the alerts which has been monthly for some XEN hosts. Although this seems likes it logging too much? has anyone every seen this grow to such a large size? This does not happen on all m y hosts at all sites which is strange. We are 8.2 and updated to E017.  Thanks

 

https://support.citrix.com/article/CTX202821

 

 

[Non supported Linux VDA's not supported in Citrix Cloud?]

Wondering if anyone has migrated LInux VDA to the cloud? We have some legacy OS's e.g.RHEL 6.8 running 7.15 LTSR CU6 and Cent74 running 18.08 all of which go into a registration loop in Citrix cloud when ever there is a Citrix Cloud studio policy change or new policy is created. I believe our Citrix Cloud is on the latest version of Citrix for it's Studio and DDC's and not backwards compatible to older VDA's.

 

Our other Linux VDA's running Cent77/Rhel77/Ubuntu18.04 running 19.12LTSR does not have such issues. The fix is the update the policy again which somehow gets the LVDA's to register correctly.

 

Basically it looks like Linux VDA tries to download any new policies and errors out on the unzipping of the policy. Then the VDA restarts the registration service again, registers correctly, downloads the policy again, then fail. then repeat over and over. Reboots don't help it either. The only fix it seems is to toggle  on/off any policy or update any policy in studio to get it working again.

 

Citrix support says they will only give us support on new OS's running supported VDA's. That is unfortunate since we were looking to migrate to cloud. Now we may stay on prem  running 7.15LTSR and look for another display remoting technology in the long term.

 

Log error:

 

2020-12-07 16:29:45.741 [INFO ] [11535] - The Citrix Desktop Service successfully obtained the following list of 2 delivery controller(s) with which to register: 'xsj-dvapvdiclc2.***.com (172.*.*.*), xsj-dvapvdiclc1.*com (172.*.*.*I)'.

2020-12-07 16:29:47.262 [ERROR] [21] - VdaState.AssignVdaStateInfo: Failure. Error: Could not find [PolicySetting] on: VdaParametersAccessors.DefinedFeatures

2020-12-07 16:29:47.269 [ERROR] [21] - MxPolicyManager.WriteSinglePolicy: Failed to uncompress policy information. Error: 'Expected this cabinet CFFOLDER to have a compression type of 1, but found it to be 4611.'

2020-12-07 16:29:47.270 [ERROR] [21] - ConfigurationManagerService.Set: Exception: MxPolicyManager.ProcessMultipleMxPolicies: Error while saving policy settings - Location=/var/xdl/vda Exception=Expected this cabinet CFFOLDER to have a compression type of 1, but found it to be 4611.

2020-12-07 16:29:47.433 [INFO ] [11535] - The Citrix Desktop Service successfully registered with delivery controller xsj-dvapvdiclc2.*com (IP Address 172.*.*.*).

[Non supported Linux VDA's not supported in Citrix Cloud?]

Wondering if anyone has migrated LInux VDA to the cloud? We have some legacy OS's e.g.RHEL 6.8 running 7.15 LTSR CU6 and Cent74 running 18.08 all of which go into a registration loop in Citrix cloud when ever there is a studio policy change or new policy is created. Our other Linux VDA's running Cent77/Rhel77/Ubuntu18.04 running 19.12LTSR does not have such issues. The fix is the update the policy again which somehow gets the LVDA's to register correctly.

 

Basically it looks like Linux VDA tries to download any new policies and errors out on the unzipping of the policy. Then the VDA restarts the registration service again, registers correctly, downloads the policy again, then fail. then repeat over and over. Reboots don't help it either. The only fix it seems is to toggle  on/off any policy or update any policy in studio to get it working again.

 

Citrix support says they will only give us support on new OS's running supported VDA's. That is unfortunate since we were looking to migrate to cloud. Now we may stay on prem  running 7.15LTSR and look for another display remoting technology in the long term.

 

Log error:

 

2020-12-07 16:29:45.741 [INFO ] [11535] - The Citrix Desktop Service successfully obtained the following list of 2 delivery controller(s) with which to register: 'xsj-dvapvdiclc2.***.com (172.*.*.*), xsj-dvapvdiclc1.*com (172.*.*.*I)'.

2020-12-07 16:29:47.262 [ERROR] [21] - VdaState.AssignVdaStateInfo: Failure. Error: Could not find [PolicySetting] on: VdaParametersAccessors.DefinedFeatures

2020-12-07 16:29:47.269 [ERROR] [21] - MxPolicyManager.WriteSinglePolicy: Failed to uncompress policy information. Error: 'Expected this cabinet CFFOLDER to have a compression type of 1, but found it to be 4611.'

2020-12-07 16:29:47.270 [ERROR] [21] - ConfigurationManagerService.Set: Exception: MxPolicyManager.ProcessMultipleMxPolicies: Error while saving policy settings - Location=/var/xdl/vda Exception=Expected this cabinet CFFOLDER to have a compression type of 1, but found it to be 4611.

2020-12-07 16:29:47.433 [INFO ] [11535] - The Citrix Desktop Service successfully registered with delivery controller xsj-dvapvdiclc2.*com (IP Address 172.*.*.*).

[Latest Citrix Workspace 21.02.0.25 receiver not working on Windows / Linux VDA that are not the latest CU2. (Unknown Client error 0)]

Hello

I updated my Windows workspace receiver yesterday released 2/1/2021  version and not I'm not able to connect to any VDA that is not 19.12 LTSR CU2. Meaning I'm only able to connect to my  desktop VDA's running 19.12.LTSR Cu2

 

 

Example:

[root@xsjrhel77vda]# rpm -qa XenDesktopVDA
XenDesktopVDA-19.12.0.50-1.el7_x.x86_64 

FAILING with new receiver.

 

[root@xsjcent77-01]# rpm -qa XenDesktopVDA
XenDesktopVDA-19.12.2000.3-1.el7_x.x86_64

WORKING  with new receiver.

 

I also have the latest Mac Workspace receiver 21.01.0.21 and it seems to be backwards compatible for all VDA's so it's only Windows that has issues.

 

Funny enough XA apps do work published by the same servers that are not working for full desktops. . Downgraded back to previous version of workspace and all is good. Not sure if anyone else is seeing this?

 

It is failing on prem, and also in Citrix cloud where we are running a POC.

 

 

 

 

 

 

 

https://www.citrix.com/downloads/workspace-app/windows/workspace-app-for-windows-latest.html

[RHEL 7x, Cent7x, much slower on LVDA 19.12 compared to RHEL6x on LVDA7.18]

You are correct in that GNOME 3 is a CPU hog. We have done some comparisons and saw GNOME3 had the highest CPU load followed by gnome classic, then KDE seemed to be the best however KDE is no longer supported by RHEL as they are moving towards GNOME. 

[RHEL 7x, Cent7x, much slower on LVDA 19.12 compared to RHEL6x on LVDA7.18]

We are migrating from RHEL6.8 on LVDA 7.16 to RHEL77 LVDA 19.12 and notice that performance is much slower on the RHEL77. Also bandwidth consumption is much higher than before.

 

With most of our company working from due to COVID, the number 1 issue is "My VDI is slow" primarily from the users that have been migrated to the newer RHEL7x with Cirix workspace 18.12 and 20.6 .  Typically this is due to the users home environment, but we need to be able to make it as efficient as possible.  How can I get the best performance for my remote users now and why is the new LVDA consuming so much more bandwidth over the previous version. 

 

Thanks

 

 

[grey screen appears and disappears..tried all workarounds]

My my experience, most of these types of desktop disappearing issues can be contributed to the users .cshrc or .bashrc other .dot files having something incorrectly set. Moving them temporarily to a backup folder to try to get a successfully VDI desktop, then copy them back one by one is a good way to debug.

Typical culprits of VDI not being able to get a session that i have seen are:

 

.cshrc

.bashrc

.bash_profile

.bash_login

.profile

.login
 

I've seen this in some users home directory in the .bashrc or .cshrc . Commenting out these two lines seemed to work for them.

 

.bashrc

# No autologout

#set autologout=0

 

# Autocomplete

#set autolist