Clarification on kernel modules for ENSL

[Jmac24]

New to managing ENS on Linux systems and wanted some clarification on what the ENS Kernel Modules for Linux are needed for. I've read through the product and installation guides and searched the KB and community for info and there isn't anything that I found that gives a full explanation on them. If someone can post a resource that would be awesome/

I am updating some systems that are on ENSL 10.5.1 to 10.6.5, and some that are missing ENSL. I see that there are Kernel Modules that can be checked in as well. Do these need to be checked in first? Is there a specific order that I need to do this? If I go and check the latest kernel modules in, are there any potential issues I need to be aware of for existing systems checking in?

Any info that can give some insight into what is needed and proper update steps would be a great help.

[Former Member]

The Kernel Modules package for ENSL installs prior to the Threat Prevention package and contains the kernel modules needed for Threat Prevention to function, similar to how the ENS Platform installer on windows installs the SysCore suite of drivers used by the other modules. It contains the file access kernel module used for On-Access scanning (on supported kernels, otherwise FANotify is used for scanning) and the AAC kernel module used for Access Protection.

For those systems that you are upgrading from 10.5.1 to 10.6.5, you do need to first check in the Kernel Modules package and then check in the Threat Prevention package. You don't need to worry about your 10.5.X systems once the packages are checked in, they will not update or pull this down on their own.

As for the deployment task to upgrade your endpoints - Your safest bet is going to be a product deployment task that installs the Kernel Modules package first, followed by the Threat Prevention package. This is not necessarily required though, and if you prefer you can simply deploy the Threat Prevention package and the McAfee Agent should pull down the kernel modules package on its own.

FYI - This is the Windows focused Endpoint Security forum. For Linux/Mac questions, you may find better support here: https://community.mcafee.com/t5/Mac-and-Linux-Products/bd-p/mac-and-linux

[patrakshar]

@Jmac24 

So if I understand  correctly your question is  what to do with "McAfeeESP-KernelModule---Release-ePO.zip"

These are the exact steps you will need to follow:

Check in 10.6.5 extension.

In master repository check in "McAfee Endpoint Security Kernel Modules for Linux 10.6.5 Build 107 - ePO Package Version 10.6.0.107"

In master repository check in "McAfee Endpoint Security for Linux Threat Prevention 10.6.5 Build 107 - ePO Package Version 10.6.5.1...

Create a deployment task to deploy 'McAfee Endpoint Security for Linux Threat Prevention 10.6.5 Build 107 - ePO Package Version 10.6.5.1...

Previously we had the Kernel module information merged into the regular Installation package. However in 10.6.0 version onward we have made the Kernel module as separate package. It just gets check in first in EPO Master repository and then only you can check in the TP module. There is no deployment task needed for the Kernel module as it will be validated as per the TP deployment task.

[Jmac24]

@patrakshar 

Thanks,

That helps. One question, it shows in the master repo as "content". Right now I have 10.6.5 Kernel Modules and Threat Prevention checked into our Evaluation branch and a client task for 10.6.5. If I push that install to some systems, and their agent policy is pointing to current for kernel modules (we have 10.6.2 in current) will that be a problem or will the installer know that the 10.6.5 modules are in Evaluation because of the client task?

In this case, do I need to copy them into current? If I do that, what is the impact on systems running a previous version of ENS that check in for updates to that branch?

Thanks

[patrakshar]

@Jmac24  You can either copy them into Current or change the Agent policy to take ENSLTP update from Evaluation which also should do the same.

[Jmac24]

Thanks, what is the impact to systems running a previous version that point to Current if I copy that to Current? My existing 10.5.3 and 10.6.2 clients? Will they automatically update on their daily update check? I don't want production systems getting the 10.6.5 version yet.

[Former Member]

If you don't want production systems to get the update yet, then I would suggest creating a McAfee Agent policy which is set to update from the previous or test branch (wherever you have placed the latest version) then assign this policy to your test machines that you want to update.

You will then also need to include (tick) the updates for ENS in the Product Update Client Task. When this task is then run on the clients, it will check the agent policy to know which branch it should query against and then if there are later versions in that branch than applied, it will attempt the update.

[Jmac24]

Makes enough sense. We have a situation where we have 4 different groups of servers running different versions right now. It's a mix between 10.5.1, 10.5.5, 10.6.4 and 10.6.5. Working on getting them all on 10.6.5 which I'm pushing in phases.

We have 10.5.1 in current and all of the agent policies point to current. 10.5.5 AND 10.6.5 are in Evaluation along with the Kernel Modules v 10.6.5. They are not checked in to current.

If I check the 10.6.5 Kernel Modules into current, my understanding is that the only systems that would update during a scheduled update with that box checked would be systems running a previous version of 10.6. The 10.5.5 and 10.5.1 systems would not, correct?