How to Recover XenServer Physical Volume Structure after Accidental Deletion

This article describes how to recreate a Physical Volume (PV) and restore Logical Volume Manager (LVM) structure in a situation where Shared or Local storage metadata has been damaged or overwritten.

Warning! Perform the instructions at your own risk. It is recommended to raise a case with Citrix Technical Support to confirm the cause of the issue and then perform necessary steps. Do not attempt commands in this article unless you are confident in understanding of the issue and suggested steps.

If a PV information has been accidentally deleted or tempered with, LVM commands such as “lvscan”, “vgscan”, and “pvscan” return incorrect or empty output.

Note: The commands lvscan, vgscan, and pvscan also return empty output if storage is disconnected or XenServer has problems with communicating to the storage device. Ensure that storage is attached and can be accessed from XenServer, by testing reading with hdparm –t /dev/sd<x> or hdparm –t /dev/mapper/<scsi id> for multipathed SRs, before proceeding with the following instructions. Correct output returns the PV associated with block device and corresponding Volume Groups.

For instance, correct output of pvscan command for shared SR (iSCSI or HBA) with multipath enabled would be in the following format.

PV /dev/mapper/<scsi id> VG VG_XenStorage-<SR uuid> lvm2 [<size total/size free>]

Note how the block device appears under /dev/mapper. If multipath is not enabled, PV value would point to a single block device /dev/sd<x>, like in case of the local storage. For example:

PV /dev/sda3 VG XSLocalEXT-fdf91589-39f4-4104-9856-3cb6c606255 lvm2 [457.75 GB / 0 free]

If only /dev/sd<x> device is displayed, you can confirm scsi id of that device by inspecting output of command.

ls –alh /dev/disk/by-id/


For example, if there is an iSCSI device with scsi id of “23237636464633731” and uuid “e79f14b6-055e-a166-42ce-bf535db5f285”, as seen in general tab of the SR in XenCenter, then the pvscan output for this SR is as follows.

PV /dev/mapper/23237636464633731 VG VG_XenStorage-e79f14b6-055e-a166-42ce-bf535db5f285 lvm2 [1.22 TB / 116.00 GB free]

However, when LVM has been tempered with, pvscan command may provide no output for that SR, or another Volume Group (VG_XenStorage-<different uuid>) name will be assigned to the PV on the expected scsi device.

Background

This problem can occur in following or similar cases:
  1. Storage has been accidentally mapped to another XenServer pool and/or PV and VG metadata has been removed or overwritten with new PV and VG information.
  2. LVM metadata has been removed with incorrect pv/vg commands executed on the host.

  3. Storage failure that caused corruption on the LUN affecting LVM metadata.

Related:

Citrix Workspace App for Linux – Session failed to launch on CentOS8.x and Fedora 29-31

The steps below outline a way to work around the problem and get a compatible version of the library (shared object) onto the endpoint.

The objective here is to take the version of libcrypto from a prior release of the OS, and for purposes of the CWA Linux(CWAL), use it in place of the default library provided. This can be accomplished either directly on the endpoint or from some other machine and then transferred over to the endpoint.

Optionally, to have a completely installable package, the CWAL’s tarball package can be customized. How to accomplish this is included within the CWAL’s online documentation. It can found under the section “Customize installation”.

1. Before following any of these steps you may want to make backup copies of some or all of the CWAL installation.

2. From a browser, navigate to the following URL:

3. The rpm package should begin to download.

4. Once the file has downloaded you can extract the libcrypto so from the package

5. Make sure the RPM package file is in a separate folder to prevent any mistaken overwriting of system files

6. From a terminal window navigate to the folder containing the RPM file.

7. Now execute the following command to extract only the necessary file:

  • For CentOS: rpm2cpio openssl-libs-1.0.2k-19.el7.x86_64.rpm | cpio -icvdum ./usr/lib64/libcrypto.so.1.0.2k
  • For Fedora: rpm2cpio openssl-libs-1.1.0h-3.fc28.x86_64.rpm | cpio -icvdum ./usr/lib64/libcrypto.so.1.1.0h

8. This should extract the libcrypto file into the cwd under usr/lib64/ folder in the current directory

9. With the extraction complete, copy the extracted file into the root folder of the CWAL, typically this will be /opt/Citrix/ICAClient. This will be the target libcrypto version for the following steps.

  • Option: Alternately, the file can be copied it into the OS’s default library folder /usr/lib64.
  • Note: This will change some of the following information as the path to the library will be different.

10. At this point there are a couple of options to preload the library, but ultimately “export LD_PRELOAD=/opt/Citrix/<name of target libcrypto library>” must be executed prior to the engine ( wfica ).

11. The file wfica.sh, which should be in the CWAL root folder, can be used as a script wrapper to preload the library before wfica is executed. The file will need to be modified to export the LD_PRELOAD statement and properly pass arguments to whatever the wfica binary is renamed to in the following step.

12. The current wfica binary will need to be renamed to something else, for example “wfica.exe”, which will be used for the purpose of this document.

cd to the /opt/Citrix/ICAClient foldercp wfica wfica.exe

13. An example of a modified script wrapper, wfica.sh, could look as follows:

#!/bin/shICAROOT=/opt/Citrix/ICAClientexport ICAROOTLD_LIBRARY_PATH=/opt/Citrix/ICAClient/libexport LD_LIBRARY_PATHLD_PRELOAD=/opt/Citrix/ICAClient/<name of target libcrypto library>export LD_PRELOAD$ICAROOT/wfica.exe $@

14. The modified wfica.sh will need to be copied over the original wfica binary.

cd to the /opt/Citrix/ICAClient foldercp wfica.sh wfica

15. Another option is to place the “export LD_PRELOAD=/opt/Citrix/ICAClient/<name of target libcrypto library>” statement into the user’s .bashrc file.

  • The .bashrc file is located in each user’s home folder.
  • This will however mean that each user, who will need to use the CWAL, must have their .bashrc file modified
  • Optionally, this can be made global by various methods. As there are a few ways to accomplish this it will not be covered here.

Whichever way is chosen, the method must export the LD_PRELOAD statement prior to the execution of wfica to ensure that it is using the compatible shared object.

Related:

Data Protection Evolution in the Coming Decade – Part 4

In part 3 of this blog series we discussed our vision for future data protection. It will be a multi-year effort to fully realize, but our early efforts in this journey are already starting to bear fruit. Recently we released support for the protection of Kubernetes containers on VMware – a first-to-market data protection solution that will enable our customers to accelerate innovation and increase their agility across multi-cloud environments by leveraging containers for application deployments while ensuring the protection of critical data wherever containers are deployed. Going forward, our customers can expect to see a … READ MORE

Related:

Oracle Database 18c XE now under the Oracle Free Use Terms and Conditions license

Today we announce the availability of Oracle Database 18c XE for Linux under the Oracle Free Use Terms and Conditions license. This new license is part of the XE RPM installer file and will be installed alongside Oracle Database 18c XE. The download of the RPM file requires no more click-through on the website! Users can now install Oracle Database 18c XE for Linux directly from the web via:

yum -y localinstall https://download.oracle.com/otn-pub/otn_software/db-express/oracle-database-xe-18c-1.0-1.x86_64.rpm

The Docker build files and Vagrant boxes files for 18c XE have also been updated to take advantage of this change and no longer require the user to download the software first either!

This change has been requested by the community. Oracle continues its commitment to the community and will base future releases of XE, Windows and Linux alike, under the Free Use Terms and Conditions license as well.

Related:

Cisco Data Center Network Manager JBoss EAP Unauthorized Access Vulnerability

A vulnerability in the application environment of Cisco Data Center Network Manager (DCNM) could allow an authenticated, remote attacker to gain unauthorized access to the JBoss Enterprise Application Platform (JBoss EAP) on an affected device.

The vulnerability is due to an incorrect configuration of the authentication settings on the JBoss EAP. An attacker could exploit this vulnerability by authenticating with a specific low-privilege account. A successful exploit could allow the attacker to gain unauthorized access to the JBoss EAP, which should be limited to internal system accounts.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200102-dcnm-unauth-access

Security Impact Rating: Medium

CVE: CVE-2019-15999

Related:

Sophos Anti-Virus for Linux: System requirements

This knowledge base article lists the system requirements of the Sophos Anti-Virus for Linux for Sophos Central, Sophos Enterprise Console and the standalone versions.

The following sections are covered:

Applies to the following Sophos products and versions

Sophos Anti-Virus for Linux

Sophos Anti-Virus for Linux 10

Sophos Anti-Virus for Linux 10 offers additional capabilities which include Malicious Traffic Detection and Sophos Security Heartbeat™ (applies to Central Server Protection license).

Here is the list of its minimum system requirements:

Sophos Anti-Virus for Linux 9

Sophos Anti-Virus for Linux 9 is the only version available for the standalone and Enterprise Console-managed versions.

Here is the list of its minimum system requirements:

  • Supported Distributions (latest minor point or LTS version):
    • Amazon Linux, Amazon Linux 2
    • CentOS 6/7
    • Debian 9, 10
    • Oracle Linux 6/7
    • Red Hat Enterprise 6/7/8
      • Red Hat Enterprise Linux 6 32-bit version supported until Nov 30th 2020
    • SUSE 12/15
    • Ubuntu 16/18 LTS
  • System type:x86_64
  • Free disk space: 1 GB
  • Free Memory: 1 GB
  • Stack sizes: Non-default stack sizes are not supported.
  • Language version: English and Japanese (EUC and UTF-8). Shift JIS and JIS are not supported.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable for us to ensure that we continually strive to give our customers the best information possible.

Related:

Sophos Antivirus for Linux: Limited Support for RHEL 6 during Extended Life Phase (Japan only)

Sophos plans to provide Limited Support for Sophos Antivirus for RHEL 6 during Red Hat’s Extended Life Phase (ELP), until June 30, 2024, on the following basis:

  • Limited Support for Sophos Antivirus for RHEL 6 is provided on the assumption that the customer subscribes to Red Hat’s Extended Life-cycle Support (ELS) Add-On to receive critical security fixes for the operating system through the Extended Life Phase (ELP)
  • Limited Support is subject to a valid subscription to a current Sophos Server Protection license and receipt by Sophos of a support extension fee.
  • Limited Support means that Sophos will continue to test and release new versions of the Virus Engine or Virus Data Library as part of the release calendar. Only critical product issues will be addressed, which may include hot fixes, vulnerabilities or improvements to protection, at Sophos’ discretion.
  • Limited Support will be provided for 64-bit platforms and the last minor point release of RHEL 6. Sophos will endeavor to provide support for other minor releases on a ‘commercially reasonable efforts’ basis, as follows:
    • Support for product configuration and usage questions will be provided by Sophos Technical Support.
    • Technical product issues will be investigated using Sophos’ existing maintenance process, on the basis that the issue can be replicated on the last minor release
    • If a reported product issue cannot be replicated on the last minor release, Sophos advises that such issues would fall outside the scope of support.
  • Limited Support for Sophos Antivirus on RHEL 6 does not include CentOS and Oracle Linux derivatives. See Retirement calendar for supported platforms and operating systems.
  • Sophos currently plans to provide Limited Support for Sophos Antivirus on RHEL 6 through Red Hat’s published Extended Life Phase (June 30, 2024). Sophos reserves the right to suspend, reduce or terminate Limited Support before this date for reasons including but not limited to changes in demand, security, and technology. For example, if Sophos discovers an issue that requires the third-party operating system provider to provide a fix and the third party does not provide such fix, or if Sophos determines that a product code change would be required to address an issue for the RHEL 6 operating system.

Limited Support Terms

RHEL 6 Limited Support. AVAILABLE IN JAPAN ONLY. Subject to receipt by Sophos of a support extension Fee (either directly or via an authorized reseller as applicable), Sophos agrees that it will continue to provide Limited Support on a technically and commercially reasonable endeavours basis for a version of Sophos Anti-Virus for Red Hat Enterprise Linux (RHEL) version 6 on 64 bit platforms, beyond the published end of support date until the earlier of (i) the expiry of the support extension period stated in the relevant Schedule, or (ii) 30 June 2024. RHEL 6 Limited Support comprises regular updates to security data and periodic updates to the product engine only. Sophos reserves the right to suspend, reduce or terminate RHEL 6 Limited Support prior to such date for reasons including but not limited to changes in demand, security and technology, and if and to the extent that Sophos determines that a code change would be required to the Sophos Anti-Virus Product to address an issue for the RHEL 6 operating system.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

Related:

Sophos Anti-Virus for Linux: Additional steps required for SAV on Red Hat Enterprise Linux 8

This article provides the additional steps required to install and run Sophos Anti-Virus for Linux on Red Hat Enterprise Linux 8. For both Central and SEC managed environments

Applies to the following Sophos products and versions

Sophos Anti-Virus for Linux

Operating systems

Red Hat Enterprise Linux 8

With the release of Red Hat Enterprise Linux 8, a number of new and tighter security features have been introduced and these have meant some additional steps are required to install and run SAV for Linux.

  1. Set a variable to refer to the SAV install point.

    # INST=/opt/sophos-av

  2. Create a context to label all files in $INST/talpa with the ‘is-kernel-module’ label.



    # semanage fcontext -a -t modules_object_t "$INST/talpa(/.*)?

  3. Set the SELinux Boolean to allow all root processes to load kernel modules. [see note 1]

    # semanage boolean --modify --on domain_kernel_load_modules

  4. Install libnsl for UNC updating to work on SEC managed environments. [see note 2]

    # yum install -y libnsl

  5. Install SAV without starting savd.

    # ./install.sh $INST --autostart=False

  6. Apply the correct labels to $INST/talpa. [see note 3]

    # restorecon -R -v $INST/talpa

  7. Start savd.

# systemctl restart sav-protect

Additional Notes:

  • SAV for Linux requires the ability to load modules to kernel. This is disabled by default in SELinux. The SELinux Boolean option will allow all root processes to load kernel modules. By default SELinux on Red Hat Enterprise Linux 8 prevents daemons from loading kernel modules.

  • The libnsl step is only needed where SAV version 9 is updating via UNC cifs/windows share location.

  • The restorecon command is for restoring SELinux Context of the directory and will need to be done every time SAV is re-installed.
  • If on-access is required with Talpa the for on-access scanning, the following packagers are required

# yum install kernel-devel

# yum group install “development Tools”

# yum install elfutils-libelf-deveplease

Please see compiling Talpa for further details

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable for us to ensure that we continually strive to give our customers the best information possible.

Related: