7022849: Reflection ???Error initializing VBA components??? when loading the Reflection Workspace.

The Microsoft Visual Basic for Applications (VBA) package installed by Reflection Desktop 16 is an integral part of the product that typically gets installed as a pre-requisite, but can also be an optional component. If Reflection Desktop is installed via the SETUP.EXE program, the Visual Basic for Applications is listed in the Feature Tree of options and is installed by default and the error listed in the article will not appear.

If Reflection Desktop is deployed directly via the installer package (*.msi) file (using a msiexec command or third-party tool) problems like the error message described in this article can occur.

1. If no VBA is desired, make sure to install Reflection via a msiexec command line with a TRANFORM file set to remove the Visual Basic for Applications feature.

Example: msiexec /I ReflectionV16.1.msi TRANSFORMS=custom.mst /qb

2. If the VBA feature is desired, deploy the additional Microsoft VBA 7.1 core and language-specific *.msi packages from the ..PrerequisitesVB71 folder via a msiexec command line.

Example: msiexec /I vba71.msi /qb for the VBA Core

msiexec /I vba71_1033.msi /qb for the English language

Related:

  • No Related Posts

7023219: End of Support for iSeries Agents and Endpoints

This release does not include support for iSeries agents or endpoints. To monitor your iSeries assets using the latest release of Secure Configuration Manager, NetIQ recommends that you use TGAudit, which provides enhanced capabilities and reporting. If you are entitled to NetIQ Security Solutions for iSeries, you can use TGAudit at no extra cost. You can download TGAudit from the download page https://download.microfocus.com/Download?buildid=ZoH3ukkXcTc~. For more information about TGAudit or migrating your data, contact your Sales Representative or Technical Support.

If you want to continue monitoring your iSeries assets using your existing agents and endpoints, you will need to use a prior version of Secure Configuration Manager installed on a separate server. You must also maintain separate databases for each version.

Related:

  • No Related Posts

7001133: Recommendations for the usage of user_friendly_names in multipath configurations

Concerning issue 1. it is not recommended to use user_friendly_names if the system root is on multipath.

It is advices to use the alias configuration option in the multipath.conf file instead, e.g.:

multipaths {

multipath {

wwid 36006048000028350131253594d303030

alias mpatha

}

multipath {

wwid 36006048000028350131253594d303041

alias mpathb

}

multipath {

wwid 36006048000028350131253594d303145

alias mpathc

}

multipath {

wwid 36006048000028350131253594d303334

alias mpathd

}

}


If root is not on multipath, but multipath is included in the initrd anyway (this can happen if root is on LVM), and user_friendly_names is used, then one should boot with the parameter “multipath=off”, to avoid problems.

This will disable multipath in the initrd only. Once the system boots, the boot.multipath and multipathd boot scripts will still be able to activate multipathing.


Concerning issue 2. it needs to be assured that the bindings file is available on the system root and multipath can find it.

This be done for example by moving the bindings file to: /etc/multipath/bindings,

and setting the option “bindings_file” in the defaults section of /etc/multipath.conf, e.g:

defaults {

user_friendly_names yes

bindings_file “/etc/multipath/bindings”

}

Note: Since SUSE Linux Enterprise Server 11 Service Pack 3 the bindings are on default already stored in /etc/multipath/bindings.

An extra entry in multipath.conf is not longer needed. (this can be checked with command: # multipath -t | grep bindings)

Related:

  • No Related Posts

7023272: IDM 4.7.0 Data Collection Service (DCS) Driver 4.2.0 won’t start: NoClassDefFoundError: com/microfocus/database/builder/DatabaseBuilder

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

Environment

Identity Manager 4.7.0

Identity Manager Driver – Data Collection Service

Situation

After applying the Data Collection Service Driver 2.0 update on a IDM 4.7 server, the following error is received when attempting to start the driver.

08/15/18 09:05:27.732]:Data Collection Service Driver ST:DCSShim: BatchFileManager – Initializing state file…

[08/15/18 09:05:27.732]:Data Collection Service Driver ST:

DirXML Log Event ——————-

Driver: DENCHRIS18_TREEsystemdriverset1Data Collection Service Driver

Status: Error

Message: Code(-9010) An exception occurred: java.lang.NoClassDefFoundError: com/microfocus/database/builder/DatabaseBuilder

at com.novell.nds.dirxml.driver.dcsshim.persist.BatchFile.open(Unknown Source)

at com.novell.nds.dirxml.driver.dcsshim.persist.BatchFileManager.<init>(Unknown Source)

at com.novell.nds.dirxml.driver.dcsshim.DCSShim.init(Unknown Source)

at com.novell.nds.dirxml.engine.Driver.startShim(Driver.java:1676)

at com.novell.nds.dirxml.engine.Driver.initialize(Driver.java:329)

at com.novell.nds.dirxml.engine.Driver.<init>(Driver.java:295)

at com.novell.nds.dirxml.engine.DriverEntry.run(DriverEntry.java:626)

at java.lang.Thread.run(Thread.java:748)

[08/15/18 09:05:27.733]:Data Collection Service Driver ST:Driver terminated.

[08/15/18 09:05:27.735]:Data Collection Service Driver ST:Writing XML attribute vnd.nds.stream://DENCHRIS18_TREE/system/driverset1/Data+Collection+Service+Driver#DirXML-PersistentData.

Resolution

Per the readme, the DCS 4.2.0 update requires the 4.7.1 update be installed on the server.

System Requirements:

•Identity Manager 4.7.1 or higher.

•IDM Reporting Module.

Install the 4.7.1 and the driver should start.

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

7022979: How to restore Crowbar backup on the admin node

Following steps will clean and restore backup without need to reinstall the admin node
0. Create a snapshot prior cleaning up (optional for btrfs)
snapper create -d "cleaned admin node"

1. Check admin node uses localhost and ip of admin server as dns servers.
Can be restored from cache if needed:

cp -a /var/lib/crowbar/cache/etc/resolv.conf /etc/resolv.conf

DNS forwarders can be added to
/etc/bind/named.conf

Example resolv.conf:

cat >/etc/resolv.conf <<EOF

search examplecloud.suse.com

nameserver 127.0.0.1

nameserver 192.168.124.10

EOF

2. Stop all cloud services
for service in crowbar crowbar-jobs crowbar-init
tftp chef-{server,solr,expander,client} couchdb
apache2 named dhcpd xinetd rabbitmq-server postgresql dnsmasq;
do
systemctl stop $service;
done
2.1 Stop unstopped processes (if they exists)

killall epmd # part of rabbitmq

killall looper_chef_client.sh

3. Deinstall cloud packages

zypper rm

`rpm -qa|grep -e crowbar -e chef -e cloud -e apache2`

couchdb createrepo erlang rabbitmq-server sleshammer yum-common

bind bind-chrootenv dhcp-server tftp

4. Delete content in cloud directrories

rm -rf /opt/dell/*

/etc/{bind,chef,crowbar,crowbar.install.key,dhcp3,xinetd.d/tftp}

/etc/sysconfig/{dhcpd,named/*,rabbitmq-server}

/var/lib/{chef,couchdb,crowbar,dhcp,rabbitmq}

/var/run/{chef,crowbar,named/*,rabbitmq}

/var/log/{apache2,chef,couchdb,crowbar,nodes,rabbitmq}

/var/cache/chef

/var/chef

/var/lib/pgsql/*

/srv/tftpboot/{discovery/pxelinux.cfg/*,nodes,validation.pem}

(Note: In case of non btrfs root partition some directrories needs to be recreated)
5. Verify subprocesses are also down after deinstallation (usually not needed anymore)

killall epmd

############ #clean state #############
6. Create snapshot of cleaned admin node (optional for btrfs)

snapper create -d "cleaned admin node"

7. Ensure admin node is resolvable, nslookup and ping works

#e.g. start dnsmasq and add ip/name to /etc/hosts as needed

systemctl start dnsmasq.service
8. Install required patterns
zypper in -t pattern base cloud_admin


9. apply PTF fix for hostname check against /etc/hostname instead "hostname -f" if still needed

rpm -Fhv /ptf/*.rpm

10. Prepare backup in place

mkdir restore

cd restore

tar -xvf ../backup-restore.tar.gz

10.1 Make sure admin node is network.json compliant - the admin ip matches
first ip of an interface ( usually eth0 )
cp crowbar/configs/crowbar/network.json /etc/crowbar/network.json


10.2 Copy/Add hostnames to "/etc/hosts" from backup if not sufficient

cp crowbar/configs/hostname /etc/hostname

10.3 If using remote SMT add ip/name to the backup tar (not needed if reachable

via separate bastion network)

echo "10.10.10.10 smt-server.suseexample.com smt-server">> crowbar/configs/hosts

echo "10.10.10.0 192.170.124.1" >> /etc/sysconfig/network/routes



10.4 Create new tar-archive with changes

tar -czvf restore.tar.gz crowbar/ knife/ meta.yml

11 Start crowbar-init

systemctl start crowbar-init

12 Create empty crowbar database

crowbarctl database create

(To check sanity checks what causes issues access via browser:

http://localhost:3000/sanity)

######## #restore ########
13 Create snapshot prior restore (optional for btrfs)

snapper create -d "clean admin node prior uploading/restore backup"



14 Upload restore tarball
crowbarctl backup upload restore.tar.gz --debug --anonymous

(Note:if it still does not work check to use fqdn in /etc/hostnames or get PTF installed
15 Restore backup

crowbarctl backup list

crowbarctl backup restore <name-from-list>

16 monitor progress

tail -f /var/log/apache2/*log /var/log/crowbar/*

(or access installer within browser

17 finally check services are up, if not start them:

for service in crowbar crowbar-jobs

tftp chef-{server,solr,expander,client} couchdb
apache2 named dhcpd xinetd rabbitmq-server postgresql dnsmasq;
do
systemctl status $service;
done

Related:

  • No Related Posts

7023269: Context list is empty when browsing for eDirectory context in NURM

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

Environment

Open Enterprise Server 2018 (OES 2018) Linux
Open Enterprise Server 2015 (OES 2015) Linux Support Pack 1
Open Enterprise Server 2015 (OES 2015) Linux

Situation

Context list is empty when browsing for eDirectory context in NURM

Resolution

In order to browse for the eDirectory context in NURM, the edir_root_ca cert must exist in the /etc/alternatives/jre/lib/security/cacerts certificate store and contain a valid eDir CA cert. Follow this process to create the needed CA cert:
Verify CA Certificate
  1. Run this command to make sure the CA has not expired:
    • openssl x509 -in /etc/opt/novell/certs/SSCert.der -inform der -noout -text |grep “Not After”
  2. If the CA has expired, you will need to recreate the CA in iManager and export it to the server using this document: https://www.novell.com/communities/coolsolutions/cool_tools/certificate-recreation-script-oes1-and-oes2/

Remove any existing edir_root_ca

Run these commands to remove any existing edir_root_ca certs from the stores:
  • ST=”-keystore /etc/alternatives/jre/lib/security/cacerts -storepass changeit”; keytool $ST -list |grep edir |cut -d, -f1 |while read EC; do echo $EC; keytool $ST -delete -alias $EC; done
  • ST=”-keystore /var/opt/novell/tomcat/conf/cacerts -storepass changeit”; keytool $ST -list |grep edir |cut -d, -f1 |while read EC; do echo $EC; keytool $ST -delete -alias $EC; done

7016201: How to enable Workflow operations within DRA

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

Environment

NetIQ Directory and Resource Administrator 8.7.x

NetIQ Directory and Resource Administrator 9.0.x

NetIQ Directory and Resource Administrator 9.1.x

NetIQ Aegis 3.2

NetIQ Directory and Resource Administrator 9.1.x Workflow Automation 3.3

Situation

How to configure DRA to generate workflow events for use by Aegis.

How to register DRA and Aegis interoperability DLLs.

How to configure the Aegis Business service connection for DRA.

Resolution

Configure the DRA to Aegis connection details

  1. Launch a 32 bit CMD Prompt (Located in C:Windowssyswow64cmd.exe)
  • Note: To prevent access restrictions by Windows User Access Control, use the Right Click menu to run as administrator
  • Using 32bit version of cscript.exe (Located in C:Windowssyswow64) run the following CMD
  • cscript.exe <Path to the DRA Program Files location (Default: C:Program Files (X86)NetiqDRA)> ConfigureAegisSettings.vbs
    1. Fill in the required information via the prompts
    1. Hitting enter at a prompt will leave the previous values in place
    2. The values configured by the script are stored under HKLMSoftwareWow6432Mission Critical SoftwareOnePointAdministrationDataModulesAegisIntegration ; and are encrypted.

    Register the DRA Application DLLS

    1. Launch a 32bit CMD Prompt (Located in c:Windowssyswow64cmd.exe)
    • Note: To prevent access restrictions by Windows User Access Control, use the Right Click menu to run as administrator
  • Register the Aegis Operations Library and Web Console Library Files
    • From the DRA Application Path (Default C:Program Files (X86)NetiqDRA) run regsvr32 NqAegisOperations.dll
    • From the DRA Application Path (Default C:Program Files (X86)NetiqDRA) run regsvr32 DraWcAegisUtility.dll
        • This DLL is specific to the IIS Server hosting the Legacy ASP DRA Website (Default URL for web site: http(s)://<IISServer>/DRA) . If the DRA Web Console is hosted on an IIS server not running the DRA Services, this step must be run on the Windows OS hosting IIS.
    • Register the Aegis operations library with the Windows DOT Net Subsystem
        • From the Microsoft DOT Net path (Default c:WindowsMicrosoft.NETFrameworkv4.0.30319) run RegAsm.exe NetIQ.DRA.Interop.Aegis.dll

    Import the Aegis Workflow Registry settings into the Windows Registry

    1. From the Windows Run window run use the 32bit version of Regedit to register the Aegis Operations Registry Settings
    • c:WindowsSysWOW64Regedit.exe <Path to DRA Program Files (Default C:Program Files (X86)NetiqDRA)>NqAegisOperations.reg
  • From the Windows Run window run use the 32bit version of Regedit to register the DRA powers required for Aegis
    • c:WindowsSysWOW64Regedit.exe <Path to DRA Program Files (Default C:Program Files (X86)NetiqDRA)>NqAegisOperationsPowerTemplate.reg

    After all of the above steps are completed, restart the NetIQ Administration Service

    Additional Information

    Before editing the Windows Registry, it is recommended to have a valid backup in place.

    These steps must be performed on EVERY DRA Server. The values entered using the ConfigureAegisSettings.VBS script should be the exact same for every DRA Server as well. The data stored by the script does NOT replicate to all DRA Servers. This script must be run on each DRA Server one by one.

    DraWcAegisUtility.dll only applies to customers using the legacy ASP Web Console.

    This KB does NOT apply to versions of DRA from version 9.2 , and newer. For details on the DRA 9.2 DRA Server to Workflow Server configuration, including post upgrade steps; please see: www.netiq.com/documentation

    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

    7023078: Security Vulnerability: “L1 Terminal Fault” (L1TF) ??? Hypervisor Information (CVE-2018-3620, CVE-2018-3646, XSA-273).

    Full mitigation for this issue requires a combination of hardware and software changes. Depending on the guest type, software changes may be required at both the Hypervisor and guest level.

    Updated Intel microcode (provided through your hardware / BIOS vendor or by SUSE) introduces a new feature called “flush_l1d”. Hypervisors and bare-metal kernels use this feature to flush the L1 data cache during operations which may be susceptible to data leakage (e.g. when switching between VMs in Hypervisor environments).

    Software mitigations exist for the Linux Kernel and for Hypervisors. These mitigations include support for new CPU features, passing these features to guests, and support for enabling/disabling/tuning the mitigations. Recommended mitigations vary depending on the environment.

    For the Linux kernel (on both bare metal and virtual machines) L1TF mitigation is controlled through the “l1tf” kernel boot parameter. For complete information on this parameter, see TID 7023077.

    KVM

    For KVM host environments, mitigation can be achieved through L1D cache flushes, and/or disabling Extended Page Tables (EPT) and Simultaneous MultiThreading (SMT).

    The L1D cache flush behavior is controlled through the “kvm-intel.vmentry_l1d_flush” kernel command line option:

    kvm-intel.vmentry_l1d_flush=always

    The L1D cache is flushed on every VMENTER.

    kvm-intel.vmentry_l1d_flush=cond

    The L1D cache is flushed on VMENTER only when there can be leak of host memory between VMEXIT and VMENTER. This could still leak some host data, like address space layout.

    kvm-intel.vmentry_l1d_flush=never

    Disables the L1D cache flush mitigation.

    The default setting here is “cond”.

    The l1tf “full” setting overrides the settings of this configuration variable.


    L1TF can be used to bypass Extended Page Tables (EPT). To mitigate this risk, it is possible to disable EPT and use shadow pages instead. This mitigation is available through the “kvm-intel.enable_ept” option:
    kvm-intel.enable_ept=0

    The Extended Page tables support is switched off.
    As shadow pages are much less performant than EPT, SUSE recommends leaving EPT enabled, and use L1D cache flush and SMT tuning for full mitigation.


    To eliminate the risk of untrusted processes or guests exploiting this vulnerability on a sibling hyper-thread, Simultaneous MultiThreading (SMT) can be disabled completely.

    SMT can be controlled through kernel boot command line parameters, or on-the-fly through sysfs:

    On the kernel boot command line:

    nosmt

    SMT is disabled, but can be later reenabled in the system.

    nosmt=force

    SMT is disabled, and can not be reenabled in the system.

    If this option is not passed, SMT is enabled. Any SMT options used with the “l1tf” kernel parameter option overrides this “nosmt” option.


    SMT can also be controlled through sysfs:

    /sys/devices/system/cpu/smt/control

    This file allows to read the current control state and allows to disable or (re)enable SMT.

    Possible states are:

    on

    SMT is supported and enabled.

    off

    SMT is supported, but disabled. Only primary SMT threads can be onlined.

    forceoff

    SMT is supported, but disabled. Further control is not possible.

    notsupported

    SMT is not supported.

    Potential values that can be written into this file:

    on

    off

    forceoff

    /sys/devices/system/cpu/smt/active

    This file contains the state of SMT, if it is enabled and active, where active means that multiple threads run on 1 core.

    Xen

    For Xen hypervisor environments, mitigation is enabled by default and varies based on guest type. Manual adjustment of the “smt=” parameter is recommended, but the remaining parameters are best left at default values.A description of all relevant parameters are provided in the event any changes are necessary.

    PV guests achieve mitigation at the Xen Hypervisor level. If a PV guest attempts to write an L1TF-vulnerable PTE, the hypervisor will force shadow mode and prevent the vulnerability. PV guests which fail to switch to shadow mode (e.g. due to a memory shortage at the hypervisor level) are intentionally crashed.

    pv-l1tf=[ <bool>, dom0=<bool>, domu=<bool> ]

    By default, pv-l1tf is enabled for DomU environments and, for stability and performance reasons, disabled for Dom0.

    HVM guests achieve mitigation through a combination of L1D flushes, and disabling SMT.

    spec-ctrl=l1d-flush=<bool>

    This parameter determines whether or not the Xen hypervisor performs L1D flushes on VMEntry. Regardless of this setting, this feature is virtualized and passed to HVM guests for in-guest mitigation.

    smt=<bool>
    This parameter can be used to enable/disable SMT from the hypervisor. Xen environments hosting any untrusted HVM guests, or guests not under the full control of the host admin, should either disable SMT (through BIOS or smt=<bool> means), or ensure HVM guests use shadow mode (hap=0) in order to fully mitigate L1TF. It is also possible to reduce the risk of L1TF through the use of CPU pinning, custom CPU pools and/or soft-offlining of some hyper-threads.
    These approaches are beyond the scope of this TID, but are documented in the standard Xen documentation.

    WARNING – The combination of Meltdown mitigation (KPTI) and shadow mode on hardware which supports PCID can result in a severe performance degradation.

    NOTE – Efforts are ongoing to implement scheduling improvements that allow hyper-thread siblings to be restricted to threads from a single guest. This will reduce the exposure of L1TF, and the requirement to disable SMT in many environments.

    Related:

    • No Related Posts