7022982: Security Vulnerability: “Spectre V2” vulnerability re-introduced after installing kernel modules or drivers.

This document (7022982) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 11 Service Pack 3 (SLES 11 SP3)

SUSE Linux Enterprise Server 11 Service Pack 4 (SLES 11 SP4)

SUSE Linux Enterprise Server 12 Service Pack 2 (SLES 12 SP2)

SUSE Linux Enterprise Server 12 Service Pack 3 (SLES 12 SP3)

Situation

To help mitigate thehardware implementation causing Spectre Variant 2 vulnerability,SUSE as an operating system vendor has released and is continuingto work on mitigations for these side channel attacks in the Linuxkernel and other packages.
One of the mitigationsagainst the Spectre Variant 2 vulnerability is to compile codewithout use of indirect jumps. This method is known as “Retpoline”.Many of the latest SUSE kernel updates have been built using theretpoline methods. For this mitigation to be fully effective, allrunning kernel object code, including loadable kernel modules,needs to be compiled using the retpoline methods. That requires allthird party, externally delivered kernel modules to be built in aretpoline manner.
On SLE 12 SP2 andgreater, when using the latest update kernels, a warning is shownwhen loading a module not flagged as being built with retpolinesupport:
[ 19.503350] Spectre V2 : System may be vulnerable tospectre v2
Note this issue isalso present on SLE 11 SP4 but will not show the warningmessage.
Seeing this messagemeans that your system may have been re-introduced to the SpectreVariant 2vulnerability.

Resolution

The SUSE SolidDriverteam will begin rolling out updates to the Installation Kits,Driver Kits and DUDs hosted on drivers.suse.com to provideretpoline built modules. We will focus on OS versions that arecurrently shipping and in support, specifically SLE 12 SP3, SLE 12SP2 and SLE 11 SP4. We will systematically go through andre-build/re-post these kits and let corresponding partners knowwhen they have been madeavailable.
For partners who needto re-build their own retpoline ready kernel modules and drivers,instructions can be found on our SolidDriver websitehere:

Cause

CVE-2017-5715 (Spectre – variant 2)

Additional Information

For more informationabout SUSE’s approach to the Spectre Meltdown issues see thefollowing:

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

  • No Related Posts

7018748: Command “zypper ref” returns an HTTP 400 error in SUSE Manager 3.0 or 3.1 client.

Optionally instead of the above steps the following workaround can be used, which is to set http to unsafe by running:

echo “HttpProtocolOptions Unsafe” > /etc/apache2/conf.d/zypp-fix.conf

rcapache2 restart

Further information can be found here:

https://httpd.apache.org/docs/2.4/en/mod/core.html#httpprotocoloptions

Quoting an excerpt from the above link:

> Security risks of Unsafe

>

> Users are strongly cautioned against toggling the Unsafe mode of operation,

> particularly on outward-facing, publicly accessible server deployments.

> If an interface is required for faulty monitoring or other custom service

> consumers running on an intranet, users should toggle the Unsafe option only

> on a specific virtual host configured to service their internal private

> network

NOTE: The explained procedure will not help for clients that are not registered with SUSE Manager yet. Any such clients will need an update of zypper/yum, but that will not be possible as the clients don’t have any way to get updates.

In order to bypass this problem, recreate bootstrap repository with command “mgr-create-bootstrap-repo”. The command “mgr-bootstrap” (after another maintenance update) now makes sure of that when it generates the bootstrap script. However, it means that all the bootstrap scripts will need to be regenerated to include this change (after the package spacewalk-cert-tools has been updated to version 2.5.1.9-20.1 or higher).

Related:

  • No Related Posts

VNX: Local CIFS user’s password expires even if it’s created on MMC with never expire password policy (DELL EMC Correctable)

Article Number: 498353 Article Version: 3 Article Type: Break Fix



VNX/VNXe Family,VNX1 Series,VNX2 Series,Unity Family

The customer created 2 local users on a joined domain CIFS server with never expire password policy, however the password expires every 3 months for both of them.

Event viewer doesn’t show anything wrong.

The customer was applying GPO on domain level which has another password policy causing each password within the domain to expire every 90 days.

Ask the customer to change this GPO on the domain level if the customer needs the local user’s password to never expire.

Please note that the customer has to use domain admin to change any domain group policies, also note that according to Microsoft if there is any conflict between any policy applied to each of the following it will inherit the conflicted part from the next policy type.

1. Local

2. Computer

3. Site

4. Domain

5. OU

Related:

  • No Related Posts

7022293: Error ‘CDB: Unmap/Read sub-channel TIMEOUT_ERROR’ on Nutanix Virtual Machines

This document (7022293) is provided subject to the disclaimer at the end of this document.

Environment


SUSE Linux Enterprise Server 12 Service Pack 2 (SLES 12 SP2)

SUSE Linux Enterprise Server 12 Service Pack 3 (SLES 12 SP3)

Situation

This error is observed when performing fstrim of xfs file system LUN presented by Nutanix Acropolis hypervisor (AHV):

CDB: Unmap/Read sub-channel TIMEOUT_ERROR

Resolution

Fixed in:-

SUSE Linux Enterprise Server Service Pack 2: kernel-default-4.4.103-92.53.1

SUSE Linux Enterprise Server Service Pack 3: kernel-default-4.4.92-6.18.1

Cause

Unaligned SCSI unmap requests from fstrim cause disk congestion, I/O aborts and in extreme cases virtual machine hangs.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

  • No Related Posts

“The computer restarted unexpectedly or encountered an unexpected error. Windows installation cannot proceed”

If Windows Setup fails in the middle, you may find your desktop sitting with a dialog box that says, “The computer restarted unexpectedly or encountered an unexpected error. Windows installation cannot proceed.” This means specifically that Windows rebooted during mini-setup, but it tells you nothing about why.

What this is really telling you is that the error already happened. If you hit OK, you will reboot and get to the exact same dialog forever. So there is nothing to learn here. You cannot recover this VM and cause Windows to try again, so all you can do is cancel the task, delete the desktop, and try again.

When you try again, you should watch the process more closely. Open the hypervisor console for the desktop as soon as it powers on, and watch for errors. This could be caused by a blue-screen during setup (get the STOP code), or it could be the result of another error (like the Mini-setup fails with error: Windows could not parse or process the unattend answer file for pass [specialize]), and the user clicked the OK button there. Once you click the OK button on any Windows Setup error, you will fall into an never-ending loop of this message.

Once you have determined what the actual issue was, then you can pursue fixing that. This error is just telling you that the interesting part has already happened.

Related:

  • No Related Posts

How to install Hyperledger Fabric on Ubuntu

hyperledgerhero.jpg

Hyperledger Fabric is a blockchain framework implementation that you can use as a foundation for developing applications or solutions with a modular architecture. It’s quite a challenge to install, but once you have it up and running (and have started developing applications that make use of the blockchain framework) it will be well worth your time. The good news is that it’s all open source and runs on open source platforms, so there is no software cost investment. There is of course a time investment. But this will be time worth spent.

I want to walk you through the process of installing Hyperledger Fabric v 1.0 on Ubuntu Server 16.04. This is handled completely through the command line. I will assume you already have your Ubuntu Server 16.04 up and running. You will also need an account with sudo rights.

With that said, let’s install.

Installing the Go language

Hyperledger Fabric depends upon the Go language. The minimum required version is 1.7. Although version 1.10.2 is available, it will not compile and install with this method, so we’ll be going with 1.7. Here are the necessary steps:

  1. Change into your home directory with the command cd ~/
  2. Download the tar file with the command wget https://storage.googleapis.com/golang/go1.7.1.lin…
  3. Unpack the file with the command tar xvzf go1*.tar.gz

Now we need to set GOPATH and GOROOT with the following commands:

mkdir $HOME/gopath export GOPATH=$HOME/gopath export GOROOT=$HOME/go export PATH=$PATH:$GOROOT/bin

Check to make sure golang is working by issuing the command go version. You should see the version of go you just installed (in our case, 1.10.2).

Install dependencies

Next we have a few dependencies to install. The first is libltdl-dev. This can be done with the single command:

sudo apt install libltdl-dev

Docker is our next dependencies. We’ll install Docker from a downloadable .deb file, with the commands:

wget https://download.docker.com/linux/ubuntu/dists/xenial/pool/stable/amd64/docker-ce_18.03.1~ce-0~ubuntu_amd64.deb sudo dpkg -i docker*.deb sudo apt install -f

Add our user to the docker group with the command:

sudo usermod -aG docker USERNAME

Where USERNAME is the actual name of the user.

Log out and log back in. Verify that Docker is working with the command:

docker run hello-world

If you see “Hello from Docker!” you’re good to continue on.

Next we must install Pip. Do this with the following command:

sudo apt install python-pip

Verify pip has been installed with the command pip —version.

Now we need to add Docker Compose. We will install this, by way of Pip, with the command:

sudo pip install docker-compose

Verify Docker Compose was installed with the command docker-compose —version.

Now we install git and curl with the command:

sudo apt install git curl

Installing Hyperledger Fabric

Now we install Hyperledger Fabric. Create a new directory with the command:

mkdir -p $GOPATH/src/github.com/hyperledger/

Change into that newly created directory with the command:

cd $GOPATH/src/github.com/hyperledger/

Download fabric with the command:

git clone https://github.com/hyperledger/fabric.git

Change into the fabric directory with the command cd fabric and reset the fabric commit level with the command:

git reset --hard c257bb31867b14029c3a6afe1db35b131757d2bf

Make and install fabric with the command make. This will take some time to complete. When the installation completes, issue the following commands (so our test network will succeed):

git checkout fa3d88cde177750804c7175ae000e0923199735c sh examples/e2e_cli/download-dockerimages.sh

You can now run a fabric example by changing into the examples directory with the command cd examples/e2e_cli/ and then first issuing the command to create a test channel:

./generateArtifacts.sh TESTCHANNEL

Where TESTCHANNEL is the name of a channel (such as testchannel). Next, issue the command:

./network_setup.sh up TESTCHANNEL 10000 couchdb

Where TESTCHANNEL is the name of your test channel. Near the end of the above command, you should see END-E2E drawn out in ascii (Figure A).

Figure A

Figure AFigure A

A successful run of an included example.

You might wind up with errors regarding docker images hyperledger/fabric-tools. To fix this, you must pull down the latest images from Docker Hub and then retag them. This done with the following commands:

docker pull hyperledger/fabric-tools:x86_64-1.1.0 docker tag hyperledger/fabric-tools:x86_64-1.1.0 hyperledger/fabric-tools:latest

Once you’ve issued the above commands, rerun the ./network_setup.sh up command.

Hyperledger Fabric is up and running

Congratulations! You now have Hyperledger Fabric up and running. You can now begin the process of developing for this blockchain framework.

Automatically sign up for TechRepublic’s Data Center Trends for more hot tips and tricks.

Also See

Related:

  • No Related Posts

NetWorker (NVE 9.2.1.2) AuthC “User Search Path”

root@NW-SERVER:/opt/nsr/authc-server/bin/#: authc_config -u administrator -p “Password” -e add-config

-D “config-tenant-id=1”

-D “config-name=SLU”

-D “config-server-address=ldap://DC-FQDN:389/dc=domain,dc=ch”

-D “config-domain=DomainName”

-D “config-user-dn=CN=ServiceUser,OU=Service,OU=Users,OU=Special,OU=PROD,DC=DOMAIN,DC=ch”

-D “config-user-dn-password=Password”

-D “config-user-group-attr=memberof”

-D “config-user-id-attr=sAMAccountName”

-D “config-user-object-class=person”

-D “config-user-search-filter=”

-D “config-user-search-path=ou=ADMIN”

-D “config-group-member-attr=member”

-D “config-group-name-attr=cn”

-D “config-group-object-class=group”

-D “config-group-search-filter=”

-D “config-group-search-path=”

-D “config-object-class=objectclass”

-D “config-active-directory=y”

-D “config-search-subtree=y”

Related:

  • No Related Posts

NVP-vProxy standalone ESXi Host whitout vCenter trouble

Standalone ESXi Host whitout vCenter



NetWorker (NVE) 9.2.1.2

vProxy 2.1.1-41

ESXi 6.0



I try to make a VM Image backu (NVP-vProxy). The VM has 5 virtual disks, after 1-3 disk the backup stops.



Failed to open source VMDK “[VSA_LUN01] “servername/servername_2.vmdk”: VDDK Error: 18000: Cannot connect to the host.



But I can make a backup of every separate disk, without errors

Related:

  • No Related Posts

App Layering: “Welcome to Emergency Mode” usually means the Repository logical volume is damaged

Shutdown the ELM. Make a snapshot now. Then power back on and login as root, using your normal “root” password.

This error means you have a fatal error in the Layering Service layer repository store. Beware, it may not be possible to recover this. However, your recovery efforts need to be focused on that area.

Your first instinct might be that the boot disk partitions need an fsck, like CTX221751. In reality, this is not true. App Layering uses XFS as the filesystem for both the boot partitions and the repository store, and when you attempt to fsck an XFS filesystem, fsck returns success without doing anything. XFS is a self-repairing, journaled filesystem that should never need this kind of repair.

Although there is a tool called “xfs_repair”, it cannot be run on a mounted filesystem. So if you really believe that you need to run xfs_repair on /dev/sda1 or /dev/sda2 (the boot and root partitions on the boot disk), you will need to boot up another Linux machine and attach the boot disk from your ELM manually to that machine in order to do that. That’s beyond the scope fof this article, and has never yet been necessary in App Layering, so we will not go into details here.

The Layering Service layer repository is a “logical volume” built using the Linux Logical Volume Manager (LVM) tools. This is how we allow you to expand the layer repository: we simply take any extra space or blank disks you provide, initialize them for use in the LVM, expand the volume group (VG), and expand the Logical Volume (LV) itself. Your VG could be composed of multiple Physical Volumes (PV) with your data spanned across the disks. If your VG is damaged in a way that LVM cannot recover from, you may not be able to get access to the data.

General troubleshooting guidance for the ELM’s LVM can be found in the article App Layering: How to troubleshoot the layer repository disk as well.

Having SAN-level snapshots, backups or even clones of the ELM can help guard against complete data-loss in situations like this.

Getting the complete history of storage operations is critical at this point. You need to know when the repository was expanded and how, to be able to determine what course forward you have. It’s not possible to lay out all the ways you can have LVM problems. Instead we will walk through one common scenario: a disk added to the LVM is deleted.

Imagine you start with the initial 300GB disk. You then expand it with a 3000GB disk. Then you decide you didn’t want 3000GB, so you delete the disk, and add a 300GB disk and expand into that. You think you now have a 600GB volume. The ELM thinks you have a 3600GB volume. The additional expansion could succeed as long as LVM never tried to access data in the 3000GB gap in the middle.

This can get a lot more complicated, too, because you can expand your original disk as well, at an time. So you could start with 300GB, add a 200GB disk, expand the initial disk to 400GB, add another 200GB disk, and expand the first 200GB disk to 300GB. From the user perspective, you have a single 900GB volume, but in LVM, there are 5 separate segments spread across three disks in chronological order. While we could probably recover from deleting the third disk with the 4th segment, we probably cannot recover from deleting the second disk with the second and fifth segments.

In all cases, your only hope for full recovery is if the missing disk has not had any data written to it. If you add a disk and immediately delete it, then you have some pretty good hope for recovery. If you add a disk, use it for a month, and then delete it, you are very likely to have corrupted or completely missing layer files.

In the ELM, there is only ever one VG, named unidesk_vg, into which all PVs are concatenated. That VG contains one LV, called xfs_lv, and accessible as /dev/unidesk_vg/xfs_lv. This is true no matter what platform the ELM is based on. The disk device names may change (/dev/sdb versus /dev/xvdb), but the VG and LV names are consistent.

Note, LVM stores its configuration in /etc/lvm. The current configuration can be found in /etc/lvm/backup/unidesk_vg, and previous copies of the configuration (copies are made before each LV operation – see the “description” line) are stored in /etc/lvm/archive. While reading those files is well beyond the scope of this article, it’s possible to piece together the history of LVM operations in thie ELM by reading through the archive files in chronological order.

/etc/lvm/archive:

total 16

-rw——-. 1 root root 913 Feb 6 12:46 unidesk_vg_00000-1214181995.vg

-rw——-. 1 root root 924 Feb 6 12:46 unidesk_vg_00001-58662273.vg

-rw——- 1 root root 1360 May 4 11:01 unidesk_vg_00002-1911836168.vg

-rw——- 1 root root 1612 May 4 11:01 unidesk_vg_00003-1711355933.vg

/etc/lvm/backup:

total 4

-rw——- 1 root root 1789 May 4 11:01 unidesk_vg

There are three basic tools for Linux LVM: pvdisplay (show the physical volumes in your LVM), vgdisplay (show your “volume groups” built up from your PVs), and lvdisplay (show the “logical volumes” carved out of your VGs). Use those to determine the UUID of the missing disk. In this example, we’re going to simply give LVM back the disk it’s missing, using the GUID that the old disk had. This will allow LVM to bring back up the VG, but will leave you with a hole in the middle of your VG.

First, run pvdisplay to see your present and missing PVs.

WARNING: Device for PV w3F3ad-tmK8-DfPL-eWlN-aeNg-KLbW-ZkLr05 not found or rejected by a filter.

— Physical volume —

PV Name /dev/xvdb

VG Name unidesk_vg

PV Size 300.00 GiB / not usable 4.00 MiB

Allocatable yes (but full)

PE Size 4.00 MiB

Total PE 76799

Free PE 0

Allocated PE 76799

PV UUID KzGOla-iLmf-Mog0-YYOd-9EWn-S1ug-fjW0nx

— Physical volume —

PV Name [unknown]

VG Name unidesk_vg

PV Size 100.00 GiB / not usable 4.00 MiB

Allocatable yes (but full)

PE Size 4.00 MiB

Total PE 25599

Free PE 0

Allocated PE 25599

PV UUID w3F3ad-tmK8-DfPL-eWlN-aeNg-KLbW-ZkLr05

Then run vgdisplay and lvdisplay to ensure that the LV and VG size agree and match the sum of the PVs listed. We only care about the deleted PV disk, but now is your best opportunity to see if you have more serious problems.

WARNING: Device for PV w3F3ad-tmK8-DfPL-eWlN-aeNg-KLbW-ZkLr05 not found or rejected by a filter.

— Logical volume —

LV Path /dev/unidesk_vg/xfs_lv

LV Name xfs_lv

VG Name unidesk_vg

LV UUID Iechln-zjD7-W2gf-55mH-d1Ou-aqDa-QhZWQd

LV Write Access read/write

LV Creation host, time localhost.localdomain, 2018-02-06 12:46:11 -0500

LV Status NOT available

LV Size 399.99 GiB

Current LE 102398

Segments 2

Allocation inherit

Read ahead sectors auto

WARNING: Device for PV w3F3ad-tmK8-DfPL-eWlN-aeNg-KLbW-ZkLr05 not found or rejected by a filter.

— Volume group —

VG Name unidesk_vg

System ID

Format lvm2

Metadata Areas 1

Metadata Sequence No 4

VG Access read/write

VG Status resizable

MAX LV 0

Cur LV 1

Open LV 0

Max PV 0

Cur PV 2

Act PV 1

VG Size 399.99 GiB

PE Size 4.00 MiB

Total PE 102398

Alloc PE / Size 102398 / 399.99 GiB

Free PE / Size 0 / 0

VG UUID GU8esp-euNA-qMDO-UH9Z-V0LB-Xzvs-5YsUPG

The three important pieces of information to determine are the GUID of the missing PV, its size, and that its PV Name really is “unknown”. The PV Name normally tells you the device that the PV is currently found on. The device can change; PVs are known by their GUIDs, not their physical location. But it’s important to make sure that the PV you’re about to create is listed as being attached to “unknown”.

Now attach a new, correctly-sized disk to your virtual machine. If you really can’t be sure for some reason, overestimate. Extra space at the end is unused, but coming up short is likely a disaster. Always remember that you have a snapshot.

Then get Linux to recognize the new SCSI disk you just attached by rebooting. Since there are no other processes running, a reboot is the safest way to get the new, blank disk available. Depending on your hypervisor, you may need to power-off and power back on to get the disk recognized.

Use “fdisk -l” to identify the device path for the new, empty disk. Note that every PV disk has no partition, so you need to make some intelligent guesses about which disk is being used. Run “pvdisplay” again to make sure you’re not considering any disks that are already in use. In this case, /dev/xvdc is not used in pvdisplay.

Disk /dev/xvdc: 107.4 GB, 107374182400 bytes, 209715200 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/xvda: 32.2 GB, 32214351872 bytes, 62918656 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: dos

Disk identifier: 0x000b3644

Device Boot Start End Blocks Id System

/dev/xvda1 * 2048 1026047 512000 83 Linux

/dev/xvda2 1026048 41986047 20480000 83 Linux

/dev/xvda3 41986048 58763263 8388608 82 Linux swap / Solaris

Disk /dev/xvdb: 322.1 GB, 322122547200 bytes, 629145600 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Then run this command (substituting in the correct disk instead of /dev/xvdc) to create the new PV with the old UUID.

pvcreate –uuid=w3F3ad-tmK8-DfPL-eWlN-aeNg-KLbW-ZkLr05 /dev/xvdc –restorefile /etc/lvm/backup/unidesk_vg

Success looks like this:

Couldn’t find device with uuid w3F3ad-tmK8-DfPL-eWlN-aeNg-KLbW-ZkLr05.

WARNING: Device for PV w3F3ad-tmK8-DfPL-eWlN-aeNg-KLbW-ZkLr05 not found or rejected by a filter.

Physical volume “/dev/xvdc” successfully created.

If you see a “Can’t find uuid” error like this, then you have mistyped the UUID. Double-check the ID and re-enter the command. (See if you can figure out where I substituted a capital i for a lower-case L.)

Couldn’t find device with uuid w3F3ad-tmK8-DfPL-eWlN-aeNg-KLbW-ZkLr05.

Can’t find uuid w3F3ad-tmK8-DfPL-eWIN-aeNg-KLbW-ZkLr05 in backup file /etc/lvm/backup/unidesk_vg

Run `pvcreate –help’ for more information.

Once you have confirmation that the PV is created, reboot. The LVM should start up, and the system will be functional, including the management console. However, your layer disk data may be corrupted. Make an immediate backup of the system and then test to see how bad the damage might be.

Login as root again, and perform the following to attempt to repair the XFS filesystem. This may or may not actually fix the problem with the large void in the middle of the volume, but it is important to gt this started before you start using the repository.

# umount /mnt/repository

# xfs_repair /dev/unidesk_vg/xfs_lv

xfs_repair may produce a lot of output. I have no guidance for interpreting that output. Reboot after the repair.

Related:

  • No Related Posts