Tag: hp
Sophos Anti-Virus for Linux and UNIX: Changes to supported platforms
Announced 30 June 2017 – As part of Sophos’ ongoing product lifecycle review process, we plan to update the platforms that are supported by the Sophos Anti-Virus for Linux and UNIX offerings. The changes are designed to enable Sophos to provide the strongest protection for the most popular platforms, and will affect the following:
The following sections are covered:
- Support for legacy UNIX platforms (HP-UX)
- Support for 32-bit Linux platforms
- Provision of Talpa Binary Packs for on-access scanning
- Sophos Enterprise Console for UNIX
- Related information
- Feedback and contact
Applies to the following Sophos products and versions
Central Managed Threat Response [MTR] for Linux
The number of customers requiring Anti-Virus capabilities for legacy UNIX platforms continues to decline. Sophos plans to support the most popular platforms going forward, and plans to retire support for HP-UX.
- Support for HP-UX will end on 30 June 2020.
- Supported AIX and Solaris platforms will continue to be supported as standalone (unmanaged) SAV for UNIX deployments, in line with the retirement dates published on the Endpoint Security and Control: Retirement calendar for supported platforms and operating systems.
The latest versions of many popular Linux distributions are now only available for 64-bit platforms. After June 30, 2018, with the exception of Red Hat Enterprise Linux 6, Sophos Anti-Virus for Linux will support 64-bit versions of Linux distributions only.
- Please refer to Endpoint Security and Control: Retirement calendar for supported platforms and operating systems for a full list of supported platforms and retirement dates.
Update July 1, 2018: In line with previous communications, Sophos Anti-Virus for Linux now supports 64-bit platforms only, with the exception of Red Hat Enterprise 6.
The Sophos Anti-Virus for Linux agent currently includes a large number of pre-compiled Talpa Binary Packs for on-access scanning, many of which are for very old and deprecated kernel versions. Most customers use newer kernels in order to benefit from kernel enhancements and improved security, therefore Sophos plans to reduce the number of pre-compiled Talpa Binary Packs that are provided with the product.
- When a new kernel version is introduced for a specific Linux distribution, Sophos typically aims to provide a Talpa Binary Pack for the new kernel version within approximately two to four weeks.
- After June 2018, Talpa Binary Packs for kernel versions that are older than 18 months for that Linux distribution will be removed from the agent download. Update: This change is now scheduled for release October 22, 2018.
- Talpa Binary Packs for kernel versions that are older than 18 months for that Linux distribution will be removed from the agent download.
- Sophos will continue to provide Talpa Binary Packs for all kernel versions for supported Red Hat Enterprise Linux 6/7 distributions.
- A definitive list of kernel versions for which Talpa Binary Packs are provided will continue to be published and updated on a regular basis. See TalpaBinaryPacks.txt for the current list. Note: this list is updated automatically when Talpa Binary Packs are added and removed.
- Existing Sophos Anti-Virus for Linux installations will not be affected by this change. Talpa on-access scanning will continue to function without interruption and Sophos will continue to support customers using the product.
- If on-access scanning is required and Sophos does not provide a pre-compiled Talpa Binary Pack for your kernel, the following options are available:
- Use the alternative fanotify kernel interface (see Sophos Anti-Virus for Linux: Fanotify Overview).
- Upgrade to a later kernel version for which a Talpa Binary Pack is provided.
- Compile a binary pack locally (see Sophos Anti-Virus for Linux: Locally compiling Talpa Binary Packs for On-Access scanning and Rolling out a custom TBP to multiple computers with Sophos Anti-Virus for Linux v 9)
Talpa on-access scanning continues to be fully supported on Linux distributions and kernels for which Sophos provides a pre-compiled Talpa Binary Pack, and platforms on which local compilation of Talpa is possible. Customers using kernels for which Sophos does not provide a pre-compiled Talpa Binary Pack, and who cannot compile Talpa locally, can contact Sophos Support to discuss possible alternative approaches to enable on-access scanning.
Sophos will continue to offer and support the standalone version of Sophos Anti-Virus for UNIX, however the ability to manage SAV for UNIX using the Sophos Enterprise Console will be discontinued.
- After December 2019, management of Sophos Anti-Virus for UNIX via the Sophos Enterprise Console will not be supported
- The standalone version of Sophos Anti-Virus for UNIX will continue to be available and supported (see Installing the standalone version of SAV for Linux/UNIX)
- To migrate from a Sophos Enterprise Console managed UNIX server to a standalone implementation see Sophos Anti-virus for UNIX: Migrating a protected UNIX server managed by Sophos Enterprise Console to a Standalone (unmanaged) implementation
If you have questions about these changes, please use the Sophos Server Protection Community Forum. If you have suggestions on how Sophos could improve its offerings for Linux servers, please Suggest an Idea on the Sophos Ideas website.
- Endpoint and Server Protection: Retirement calendar for supported platforms and operating systems
- Sophos Antivirus for Linux: Limited Support for RHEL 6 during Extended Life Phase (Japan only)
- Installing the standalone version of SAV for Linux/UNIX
- Sophos Anti-Virus for Linux: Locally compiling Talpa Binary Packs for On-Access scanning
- Rolling out a custom TBP to multiple computers with Sophos Anti-Virus for Linux
- Fanotify alternative on-access scanning method
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:
Keyboard Problems with SEE 11.2.1 and HP Elitebook G6
Hi,
I have a problem with new HP Elitebook G6 (but also with some HP Zbook G5 models) and the internal keyboards in SEE UEFI preboot screen.
Problem is that not every keystroke is recognized. I have to press sometime up to 4-5 times until it is recognized. Its not usable for users espacialy in the password field.
USB Keyboard works fine.
Legacy Bios Mode works fine, too. OS is Windows 10 1809
I tried a lot with several Bios settings, but could not get it work.
Any suggestions?
BR
Andreas
Related:
Unable to Image HP Stream
Hi Everyone,
I have several HP Stream 11 Pro G2s that I am attempting to image. These laptops have no networking ports so the only way I can do this is by using a Ghost Boot Disk created with Standard Tools and send the image to a local USB drive. The laptops are Windows 10 with GPT partitioning for UEFI booting. Currently the boot disk is booting with MBR (I’m unable to make the boot disk boot via UEFI).
The problem is occuring when I go to create the image. The Ghost Boot Disk boots perfectly, and starts Ghost (I’m using the x64 version). I can select the onboard eMMC drive and I can select the USB drive I want to send the image too; however, as soon as I start I’m immediately presented with a Usage Error 662. I’ve googled the error and tried different drives, I’ve tried swapping which ports the boot drive and the data drive are in. I even attempted to send to send the image to the Ghost Boot Disk drive, no effect. Same message. Everytime.
The only time I can get the message to change is if I attempt to send the image to a folder within the data drive. Then Ghost generates an Internal Error 8027 message.
I’m at a complete loss here. I know that I’ve successfully imaged these computers before (past me, unfortunately, did not write down the instructions), but now they refuse to work no matter what.
Any help would be supremely appreciated.
Thank you!!
Related:
Post Distribution Services Are Disabled
Very similar to an issue discussed here but I didn’t want to ressurect a dead thread.
After distributing an image to a HP Z6 G4 workstation the machine will not complete its configuration. When I visit the machine and login using a local administrator account I find that the “DHCP Client (dhcp)” and “TCP/IP NetBIOS Helper (lmhosts)” services are set to disabled. If I configure both services to “Automatic”, restart, and then have Ghost perform a domain join everything appears normal.
The first time this happened I thought it was a misconfiguration issue from trying to capture and distribute an already established/dirty image. The second, and most recent, time I created an entirely new build from scratch but experienced the same results.
Similar to the linked thread the machine in question has two NICs. The first is listed as a Intel(R) Ethernet Connection (3) I219-LM and is disconnected and not in use. The second is a Intel(R) Ethernet Connection X722 for 1GbE.
Also similarly the image was created without using Sysprep against a Windows 10 Build 1903 system.
Related:
Cannot create redistributable Windows installation package
Our desktop guy was setting up a new laptop for a user and received the following error with the latest package release. The laptop is a new HP running Windows 10 with Windows updates applied and on the clients domain. Logging in as either the user with admin rights or the domain admin produced the same error. We have 15 licenses available so it was not a license issue. We ended up using a package that was a month old and were able to install Symantec Cloud. We then ran live update to update the agent. Any ideas as to what may have caused this and possibly a fix moving forward would be appreciated. We get these setups on a regular basis and this is the first one we had this particular issue with.
“You cannot create redistributable Windows installation package because your subscription does not entitle you for the same”
Related:
SEE Client Administrator/Management Agent shows no internal drives when Disk 0 is unallocated
The SEE Client Administrator and SEE Management Agent will both show no internal drives if Disk 0 is unallocated (unformated) in a system with two or more drives. I have an HP ZBook 15 that came with an internal 256 GB M.2 PCI-E SSD. That drive proved to be too small for my needs so I installed an additional 1 TB SATA SSD. I left the M.2 drive in the laptop when I added the new SSD. Disk Management shows the 256 GB SSD as Disk 0 (Unallocated) and the 1 TB SSD as Disk 1. Windows 10 1809 is installed on Disk 1. If I create a new simple volume on Disk 0 and then launch either the SEE Client Administrator or SEE Management Agent I will see both Disk 0 and DIsk 1 displayed. If I delete the volume on Disk 0, the SEE Client Administrator and SEE Management Agent will both fail to show any internal drives. This was tested with both Symantec Endpoint Encryption 11.2.1 and 11.2.1 MP1. I was able to verify that Disk 1 is in fact encrypted with the following command.
C:Program FilesSymantecEndpoint Encryption ClientsDrive Encryption>eedadmincli.exe –status
Related:
Unable to load nic driver intel i219-lm
using Hp 800 g4 dm 35 taa devices and all of the drivers will load using dpinst but not the network driver, I run dpinst direct on the machine and it acts like the this model network card is not even installed. But in device manager if I click update driver and point it at the folder it installs without issue. I also have network connection in the bios and PXE booting works fine attached is the dpinst log. I have download every driver I can find from HP, DELL and direct from intel with nothing working
Related:
Unable to load x64 driver preboot
Switching to HP 800 G4 devices using the intel i219l network driver and when when I select win 10 pe x64, just keep getting the message “restarting dhcp client” confirmed pxe is running on the site server and listening on the correct port
I went to upload the network drivers to preboot but when I try to select x64 it will let me click on add but then just gives me a message “drivers cannot be added” when I try to add them under x86 it works without issue and the new driver folder can be found under the CUSTOM on the nbs
We don’t use x86 PE so need these drivers to be in the x64 folder correct? I copied the folder from the x86 over to the x64 and rebuilding the PXE preboots now but anyone point out what I’m doing wrong here?
Related:
ViPR Controller: Unable to discover HP-UX Host
Article Number: 525202 | Article Version: 2 | Article Type: Break Fix |
ViPR Controller,ViPR Controller Controller 3.6
When a HP-UX host is being added/discovered the following error is observed is the ViPR Controller logs
vipr3 vipr3 controllersvc 2018-08-07 07:38:50,135 [1967|host|CS_Discovery|null|3799fd86-0cb4-4b8c-af8e-7b9975acb853] DEBUG Command.java (line 405) Executing: lanscan | grep lan0 | awk ‘{print $2}’
vipr3 vipr3 controllersvc 2018-08-07 07:38:50,387 [1967|host|CS_Discovery|null|3799fd86-0cb4-4b8c-af8e-7b9975acb853] ERROR ComputeSystemDiscoveryEngine.java (line 132) Discovery failed for <Host-Name> [<Host-URN>]: String index out of range: 17
java.lang.StringIndexOutOfBoundsException: String index out of range: 17
at java.lang.String.substring(String.java:1963)
at com.emc.hpux.command.GetNetworkAdapterMacAddressCommand.normalizeMacAddress(GetNetworkAdapterMacAddressCommand.java:23)
HPUX Discovery is failing as result of LAN0 being hard coded in VIPR while on the host LAN0 does not exist.
ViPR runs the following command “lanscan | grep lan0 | awk ‘{print $2}’” and if LAN0 doesnot exist on the Host the discovery fails with the mentioned error.
Dell-EMC is evaluating the requirements to address this issue in an upcoming ViPR Controller product release. As a workaround, there are two options below: Workaround #1: Workaround #2: |
When Workaround #2 is used, the Catalog services for HP-UX will not work but it will still be possible to create a volume and export it to the host.
ViPR Controller logs
vipr3 vipr3 controllersvc 2018-08-07 07:38:50,135 [1967|host|CS_Discovery|null|3799fd86-0cb4-4b8c-af8e-7b9975acb853] DEBUG Command.java (line 405) Executing: lanscan | grep lan0 | awk ‘{print $2}’
vipr3 vipr3 controllersvc 2018-08-07 07:38:50,387 [1967|host|CS_Discovery|null|3799fd86-0cb4-4b8c-af8e-7b9975acb853] ERROR ComputeSystemDiscoveryEngine.java (line 132) Discovery failed for <Host-Name> [<Host-URN>]: String index out of range: 17
java.lang.StringIndexOutOfBoundsException: String index out of range: 17
at java.lang.String.substring(String.java:1963)
at com.emc.hpux.command.GetNetworkAdapterMacAddressCommand.normalizeMacAddress(GetNetworkAdapterMacAddressCommand.java:23)
at com.emc.hpux.command.GetNetworkAdapterMacAddressCommand.parseOutput(GetNetworkAdapterMacAddressCommand.java:18)
at com.emc.hpux.command.HpuxResultsCommand.processOutput(HpuxResultsCommand.java:14)
at com.iwave.ext.command.Command.execute(Command.java:462)
at com.emc.hpux.HpuxSystem.executeCommand(HpuxSystem.java:83)
at com.emc.hpux.HpuxSystem.executeCommand(HpuxSystem.java:74)
at com.emc.hpux.HpuxSystem.getNetworkAdapterMacAddress(HpuxSystem.java:62)
at com.emc.storageos.computesystemcontroller.impl.adapter.HpuxHostDiscoveryAdapter.setNativeGuid(HpuxHostDiscoveryAdapter.java:193)
at com.emc.storageos.computesystemcontroller.impl.adapter.AbstractHostDiscoveryAdapter.discoverHost(AbstractHostDiscoveryAdapter.java:72)
at com.emc.storageos.computesystemcontroller.impl.adapter.HpuxHostDiscoveryAdapter.discoverHost(HpuxHostDiscoveryAdapter.java:56)
at com.emc.storageos.computesystemcontroller.impl.adapter.AbstractHostDiscoveryAdapter.discoverTarget(AbstractHostDiscoveryAdapter.java:59)
at com.emc.storageos.computesystemcontroller.impl.ComputeSystemDiscoveryEngine.discoverInLock(ComputeSystemDiscoveryEngine.java:121)
at com.emc.storageos.computesystemcontroller.impl.ComputeSystemDiscoveryEngine.discover(ComputeSystemDiscoveryEngine.java:93)
at com.emc.storageos.volumecontroller.impl.plugins.ComputeSystemCommunicationInterface.discover(ComputeSystemCommunicationInterface.java:49)
at com.emc.storageos.volumecontroller.impl.plugins.discovery.smis.DataCollectionJobInvoker.invoke(DataCollectionJobInvoker.java:185)
at com.emc.storageos.volumecontroller.impl.plugins.discovery.smis.DataCollectionJobInvoker.process(DataCollectionJobInvoker.java:135)
at com.emc.storageos.volumecontroller.impl.plugins.discovery.smis.DataCollectionJobConsumer.invokeJob(DataCollectionJobConsumer.java:173)
at com.emc.storageos.volumecontroller.impl.plugins.discovery.smis.DataCollectionJobConsumer.consumeItem(DataCollectionJobConsumer.java:93)
at com.emc.storageos.volumecontroller.impl.plugins.discovery.smis.DataCollectionJobConsumer.consumeItem(DataCollectionJobConsumer.java:61)
at com.emc.storageos.coordinator.client.service.impl.DistributedQueueConsumer$1.run(DistributedQueueConsumer.java:80)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)