Problem:

Need to gather log files for Support to troubleshoot Linux/Unix

How to Get Verbose Logs for All Processes of a Client with LDMS 2016

Solution:

Attached is a perl script that will gather and tar files that support will request. It will create a file called gather.tar.gz in the /tmp folder.

1. Download file

2. Copy to machine displaying issue

3. chmod +x gatherlogs.pl

4. Run ./gatherlogs.pl

5. Attach the /tmp/gather.tar.gz to case

Description

Basic inventory is supported on all Linux platforms as long as certain dependencies are met, such as compat-libstdc++. LANDesk has, however, created supports to deploy the Linux Agent to certain Linux Platforms using a Scheduled Agent Configuration.  SSH is used by the task.

In the LANDesk Help file, refer to the section titled

.

NOTE: Make sure name resolution back to the core works from the client. If it doesn't then the /etc/hosts file on the client can be edited with the correct resolution.

For information on troubleshooting the Linux Agent deployment, see the following document:

How to troubleshoot the Linux agent deployment?

Deploying the Linux Agent

To deploy the Linux agent to an unmanaged device, follow the steps below:

Red Hat Enterprise 3

(Requirements tested with RH3U7 and a minimal installation.)

Required Configuration

Required Software

sysstat - (Server Manager agent only.) This is found on Disk 3 of the Red Hat Enterprise 3 CDs.

Red Hat 3 version prior to update 7 may or may not need additional RPMs installed.  I did not test them.</ol>

Red Hat Enterprise 4

(Requirements tested with update 4 and a minimal installation.)

Required Configuration

Required Software:

SUSE 10 and SUSE 11

Tested with SUSE 10 SP1

Tested with SUSE 10 SP3 x64

Tested with SUSE 11 SP2 x64

Required Configuration

Required Software

Kubuntu

(Tested with Kubuntu 7.0.4 and the push wasn't working, will have to test again later)

Required Configuration:

Required Software

These two applications, xinetd and openssh-server, are not installed by the default Kubuntu 7.0.4 installation CD.  There may be other software that is required, but these are the only two items required after a default installation.

Description: This document is intended to help with troubleshooting Linux and Unix LANDesk agents. The document will contain several tips and tricks to discover problems on various features of the agent. The document is written around Linux so if Unix is the client then changes to the listed options will probably be needed but most of the executables are the same.

Analyzing logs dynamically while they are being updated

Linux and Unix includes a tool called "tail". Tail has the ability to constantly display a file and list the changes that are added to it AS they are being added. This is helpful in many circumstances. You can monitor several log files at once and easily see the order they are updated. You can watch a particular log to see if anything changes while running an application. Etc. Here is an example command that should work on many Linux distributions. (Note: The syntax may be slightly different on Unix platforms etc. Search the internet for proper syntax). This command is especially helpful to watch /var/log/messages. For those that are familiar with Windows this file is as close to the Event logs as you can get.

tail -f -n 100 /opt/landesk/logs/landesk.log

-f = A continous monitor of the file instead of just listing the last few lines of the file.

-n = The number of lines at the end of the file to list or watch

See the screen shot below...tail is watching landesk.log, scheduler.log, and vulscan.log at the same time in separate windows while an inventory or vulscan can be run in the top terminal window

Searching for files on the entire system

Command: find / -name filename

Description: The find command will start searching in the / (root directory) and search for the name of a file. Other parameters may include size or other file options.

Listing ports that are open

Command: netstat -auntp

Description: General command for Windows and Linux that shows open ports. (command options differ from Windows) This is good to see if cba is listening on the right ports. Ensuring the ports are open on the firewall is good as well.

Quick Information on using VI to edit a file

Description: Simple instructions for opening a file, editing it, then saving it again. VI is a simple editor that has two modes. One edits like a normal text editor while the other performs operations/commands. Toggling back and forth is key to using VI.

Example: Editing a hosts file to add a static name resolution

1- vi /etc/hosts

2- Press the letter "i" to enter "Insert" mode.

3- Edit the file and perform what operations you like.

4- Hit the ESC button to return to "Command" mode when you're done.

5- Press ":" to get a command prompt within the editor. Or type a ":" to apply one of the following commands.

6- Exit the editor with what action you want:

     q! = Quit, discard changes, and I mean it

     wq! = Write changes, quit, and I mean it.

While navigating in command mode, it doesn't use arrow keys, but letters:

H(Left) J(Down) K(Up) L(Right)

Searching a file for specific words and content

Description: cat filename | grep searchword

Explanation: "cat" will display the contents of a file. "grep" will search a file for a specific word. The "|" or pipe symbol chains the commands together to produce a more powerful command that searches a file

Example: See below...cat and grep are used twice...once to search for the word "sender" and the other to search for the word "PipeToProxyHost"

Checking applications that are running in memory

Description: "top" is the command to display all applications running on a Linux system. No command line options are needed. It will also display free space, memory, and other information.

h = The help menu

SHIFT + < = Toggles left on the list

SHIFT + > = Toggles right on the list

q = Quit

Example: The screen shot below shows map-scheduler listed which is part of the 64-bit LANDesk agent

Checking disk space

Command: df

Output: See below

File Permissions and Other Properties

Description: See below...the following diagram will show the file rights that are located on just about everything in Linux. If you use "ls -l" in a particular directory it will list all the files and display the information below. Example: In order for a file to be executable by everyone it will have an "x" in all three columns.

Command to change permissions: chmod +x filename

Description: This command will add execute permission to everyone on the file. The "+x" can be a "-" as well as "r" or "w" to add or subtract permissions across Owner, Group, and Others.

It looks like the daily inventory scan is running everyday around the time that the package was originally installed.  I definitely don't want it running during the day and I definitely don't want it running at the same time on all of my machines.  I'm guessing that I'll need to modify ldclient.db - and that there are 2 options:

1) modify the resource_values table entry where feature_id = crontime to be some random time during the night.

2) modify the resource_values table entry where feature_id = cronperiod to be something like 'never' and rely on a cron.daily script to run it at a random time overnight.

Thoughts, suggestions, criticisms?

0 - Version Disclaimer / Clarification

This article covers the creation / use of custom data files with the LANDesk MAP-agent for Linux, used predominantly between versions of LANDesk Management Suite 9.5 and up to (and including) Ivanti Enterprise Manager 2017.1 !

Please be aware that as of Ivanti Enterprise Manager 2017.3, a freshly architected Linux agent (the "component architecture" agent) exists, which operates quite differently.

A separate article will be created for the new component agent architecture and its use of custom data overe here -- How to scan custom data on Linux Platforms in detail (EPM 2017.3 onwards)  !

I - Introduction

The purpose of this article is to familiarise the user with the ways in which the LANDesk *-IX inventory scanner picks up / process custom-data - and to do so in a manner to help people who may not necessarily have had a lot of experience with *-IX OS'es.

So whilst this has effectively very similar content to the Article here this one goes through the process without assuming any significant experience with either XML files and/or *-IX OS'es

This is a new feature that is currently only available with the 64-bit agent, the 32-bit agent is not able to pick up Custom Data by means of reading files. A "workdaround" for 32-bit agents up to LANDesk Management Suite 9.5 is provided towards the end of this document for anyone interested.

II - Getting Started

Before we begin - a few things to be aware of:

• Case sensitivity (depends on your DBMS / its settings)

• PLAN FIRST ... changing this stuff on the fly tends to lead to a huge mess. Knowing *WHAT* you want to collect and *WHERE* you want it to show up (ideally you're aiming for consistency with any Custom Data with your Windows-devices, if that is applicable) up-front reduces the considerable headaches involved in cleaning up overly enthusiastic but unplanned approaches.

• Test and test thoroughly. Once you've set this "live", any changes other than "new additions" can be quite painful.

• The file(-s) must be located in "/opt/landesk/var/customdata/". The "customdata" directory does *NOT* exist by default under "/opt/landesk/var/" - so you need to create it.

• REMEMBER - you must change the ownership ownership of the following to landesk of:
  • The directory containing the custom data XML's (i.e. -"customdata")
  • any XML's themselves that you create.

You do this via running:

chown landesk:landesk <DIRECTORY_OR_FILE>

so for instance, if we want to change the ownership of the "customdata" directory, we can do so via:

chown landesk:landesk customdata

 

- or, if you want to use the full path, you can do so as well:

chown landesk:landesk /opt/landesk/var/customdata

• REMEMBER - CUSTOM DATA GETS BLOCKED BY DEFAULT!

Whilst the data may be sent to your Core Server, remember that you need to "un-block" it as per this document HERE.

• To test / debug your XML's, run

./opt/landesk/bin/map-reporter -V 255

This will launch the part of the inventory scanner that (among other things) processes the custom data. The "-V 255" flag enabled maximum verbosity. This way, you can easily check whether there are any problems with the files themselves (usually the act of forgetting to change ownership of the files), or with their data structure (and there's a few potential gotchas here to stumble into).

III - The Custom Data XML-file structure

Here's a generic template for the format you need to follow (in essence - you're looking at a pretty standard XML file)::

<?xml version="1.0"?>

<!-- OPTIONAL COMMENT #1 -->

<!-- OPTIONALCOMMENT #2 -->

<!-- OPTIONALCOMMENT #3 -->

<NAME_OF_CONTAINER_UNDER_CUSTOM_DATA>

        <OPTIONAL_CONTAINER_SHORTNAME name="Some Optional Container Name">

                  <MyData1>VALUE</MyData1>

                  <MyData2>VALUE</MyData2>

                  (...)

                  <MyLastData>VALUE</MyLastData>

        </OPTIONAL_CONTAINER_SHORTNAME>

</NAME_OF_CONTAINER_UNDER_CUSTOM_DATA>

 

... and we would aim to achieve something like the following for our custom data:

Note that you can EITHER use "your intended names" directly (as we do in the case of "<LongWindedWay>"-line below), or you can use a shorthand variable inside the XML whose 'full display name' you define (such as in the line "<LDCF name="LANDesk Custom Fields">"-line below)

A filled out Custom Data XML-file can then look like so:

* Note - for ease of readbility, I'm marking XML comments in THIS COLOUR.

<?xml version="1.0"?>

<!-- LANDesk Unix/Linux Agent - Custom Data XML Example File -->

<!-- Version 1.2.3.4 -->

<!-- My Team / My Date -->

 

<!-- You can use long-names in the XML for your categories / attributes, such as for "Asset Information"-->

<!-- Note that you MUST NOT have spaces in your object-names/tags! -->

 

<!-- Addition of White Space for added readability is fine -->

 

<Asset_Information2>

    <LDCF name="LANDesk Custom Fields_2">

<!-- Note that I use "REL-L-NUM" here! -->

        <RELLNUM name="Location RELEASE NUMBER">9.5.0.1</RELLNUM>

        <LOC name="Location In The World">London</LOC>

        <LongWindedWay name="Comment">

            This is me. Aren't I pretty?

        </LongWindedWay>

    </LDCF>

 

<!-- Note that you *CANNOT* use multiple "root" categories in a single XML. -->

<!-- So you cannot have both the "ASSET_INFORMATION" and the "USERINFO" groups in a single XML. -->

<!-- Just use multiple XML's in this case - the inventory scan will pick them all up.-->

 

    <SC name="Some Other Category_2">

<!-- Note that I use "REL-U-NUM" here! Beware of similar attributes (such as REL-L-NUM above), it can make mistakes more likely -->

        <RELUNUM name="User RELEASE NUMBER">9.5.0.1</RELUNUM>

        <ORGUNIT name="Organisational Unit">MyUnit</ORGUNIT>

    </SC>

</Asset_Information2>  

This would then present itself in inventory as per the following two screenshots:

PLEASE NOTE:

It does *NOT* matter in what order you add the custom inventory data. By default, LANDesk will sort things alphabetically for you in the console anyway (as you can see in the screenshot used above). The below version of the very same XML-data has been reformatted to closer represent the inventory scan showing on the screenshot.

Keeping to such an alphabetic theme might make things easier for you to work with whilst your designing your custom data / if you have to edit it, but is not a requirement in the slightest.

IV - How to get multiple bits of Custom Data in

IV.1 - Option 1 - Multiple files (recommended)

This is a favourable option because it's easier to control & modify and you can have segragated data (i,e, a "Asset Information" and a "User Information" category for instance).

Also this makes it a lot more manageable if you need to update anything - if you have different scripts collecting different bits of custom data, it's much easier to just have "one function/script change one small file" rather than having a singular, massive XML.

This is by far the more manageable an friendly option.

IV.2 - Option 2 - A really long file

This is less recommended for two reasons:

* You're more likely to make mistakes (more lines == more likelihood, after all), and ...

* A single error would effectively prevent ALL of your custom data from being processed, rather than "just the particular part file".

* More complex to update and manage via scripts.

I'm not saying "it can't be done" (as I'm certain some people might take it as a challenge) - I'm merely highlighting the fact that you're inviting a lot of considerable problems with really no benefit in return.

V - Don't-s and Do-s

Just a recap and listing of experiences made.

V.1 - Don't-s...

* Don't forget to run "chown" and change ownership over to "landesk:landesk" on the directory as well as the XML file(-s), else we may not be able to read the contents of the file(-s).

* Don't assume that you get everything right the first time round. Test & re-test as it's it's simple to do. Remember - all it takes is "map-reporter -V 255". The verbose option will generally be your best friend to highlight problems with your XML's.

* Don't be adventurous with naming your XML-tags or object names. Generally, sticking to the following list is "safe":

- Characters from "a-z"

- Characters from "A-Z"

- Numbers (so 0-9)

- Using a dash ( - ) and an underscore ( _ )

XML doesn't necessarily deal very well with certain characters outside of those listed above - so try and avoid that risk.

Just to clarify, I'm talking about the XML-tags and object-names only here. So in the example given above in Section III, XML-tags would be things such as:

• The "LDCF" and the 'LANDesk Custom Fields_2" in ... <LDCF name="LANDesk Custom Fields_2">
• The "RELLNUM" as well as the LOCATION in ... <RELLNUM name="Location RELEASE NUMBER">9.5.0.1</RELLNUM>

Whilst certain characters such as ( & ) or ( * ) are relatively commonly avoided, some unexpected stumbling blocks do occur. For instance, I was reading out a certain piece of hardware information and the data that was given to me was a single string with a few ( : ) colons in it ... due to uniqueness concerns, we ended up trying auto-naming the attribute with such a ( : ) in it ... such as "Disk:0" for instance ... and this can get you into trouble.

Using such characters in the DATA VALUE tends to be fine (so that'd be for instance the "9.5.0.1" string in the above example of RELLNUM) but outside of that, be mindful that XML can scupper your well-laid plans. Test and re-test.

V.2 - Do...

* ... think carefully about what custom data you WANT to collect and what you may want to collect in the future / further down the line.

* ... design your XML's sensibly with this in mind will save you headaches further down the line (moving data from "place A" to "place B" is a pain - not only would it need to be done in the database, but in the XML's as well, and you'd be potentially facing some clients that don't update properly, etc. - so all sorts of fun to go wrong with data in (potentially) multiple places for different devices. Data consistency is your friend!

VI - What about 32-bit agents?

Due to current differences in architectural differences between the 64-bit MAP agent and the 32-bit agent the above process is not applicable to 32-bit agents.

If you end up being in a situation where you do need to add custom data to a current (up to LANDesk Management Suite version 9.5 at the time of writing) is essentially the following:

1 - Run inventory with the option to create an output file.

2 - Append your desired data in regulard inventory scanner format to the output file.

For the example used here, the correspondonding format data would look like so:

Custom Data - Asset_Information2 - LANDesk Custom Fields_2 - Location RELEASE NUMBER = 9.5.0.1

Custom Data - Asset_Information2 - LANDesk Custom Fields_2 - Location In The World = London

Custom Data - Asset_Information2 - LANDesk Custom Fields_2 - Comment =             This is me. Aren't I pretty?

Custom Data - Asset_Information2 - Some Other Category_2 - User RELEASE NUMBER = 9.5.0.1

Custom Data - Asset_Information2 - Some Other Category_2 - Organisational Unit = MyUnit

VI.A - 32-bit MAP agent with IEM 2016 onwards

Please note that as of IEM 2016, the MAP-agent does come in 32-bit format, so the use of the XML's described here is fine with that.

VII - In Conclusion

This article should provide all of the information that you might require to work with custom data on *-IX operating systems, even if you have very little experience with it.

Description:

The Installation of the new linux agent might not have changed on the front-end but we have made some major changes on how the agent works on the back-end.  The below doc describes the  nixconfig.sh which is now used for installation of the agent with some new features.  The change occurred to make the agent less bulky and consistency with other agents like Windows and Mac. These include agent settings, conf files and new switches for our components. We will be covering the installation, prerequisites and new OS support.

Verify your platform:

1. Find out what release you are using, usually with uname -a or lsb_release -a from your linux console.
2. Find your platform on our Supported Platforms and Compatibility Matrix for LANDESK Management Suite/Ivanti Endpoint Manager.
3. If supported, please continue.

New Items:

• Raspbian version 7 is supported with 2017.3 release with version 8 and 9 coming with SU1.
• Changed agent to use conf files and No longer using .db files for inventory and switched to json.
• Solaris HPux and AIX are still under legacy agent- the nixconfig.sh will install the agent as before but the changes have not been. Theses are on the roadmap to be updated.

Installation Guide

Nixconfig.sh is updated to remove legacy packages, install new component architecture packages on Linux hosts and support legacy agent on Unix (AIX, HP-UX and Solaris) hosts.

Notes:

• The inventory package is installed with privilege escalation disabled so the inventory scan will not have system cache, memory bank information, etc.
• Software distribution and Vulnerability remediation require privilege escalation which is turned on by default.
• To allow privilege escalation, ensure sudo is setup with password-less access for the landesk user and set privilegeEscalationAllowed flag to true in all application specific configuration files (hardware.conf, inventory.conf, software_distribution.conf and vulnerability.conf) located in

/opt/landesk/etc.

• The Core “push” installation will drop the Configuration shell script, Configuration INI file, Agent archives and nixconfig.sh scripts on the Linux hosts (Unix hosts will also get wget executables). The INI file will drive the installation so package selection, Core address, certificates, etc. will be based on the INI file contents. For “pull” installations, the administrator only needs nixconfig.sh, access to either cURL or wget, and the relavent command line options to perform the request action (install, upgrade or removal).

Push Install:

1. Create a new agent
   asd
2. Name and check the boxes needed ( UBuntu and Raspbian will not run vulscan but will download the files for when it's available- future release)
   
3. schedule the agent and add the machines from a UDD scan. All the files needed are moved to the client for install. Prerequisites are not on the core and the client requests them from their respective version repo- redhat goes out to redhat servers.

Manual Install

Script Features:

• Run in minimum shell – Bourne shell
• Supports for running from no-exec mounted partitions
• Support for non-root installations (sudo or RBAC)
• Previous installation detection and upgrade support
• Prerequisite reporting and installation
• User defined repositories (yum and zypper only)
• Handle agent install, removal and upgrade (remove/install combined)
• Support same guid across upgrades (breadcrumb remains in /opt/landesk/etc/guid file)
• Pull files from Core by cURL or wget (wget provided for AIX, HP-UX and Solaris)
  • 1^st attempt is for individual RPM packages (future)
  • 2^nd attempt is archive package (existing tarballs)

Script Usage:

Usage: ./nixconfig.sh [OPTION]...

LDMS Agent installation, upgrade and removal processing.

-a core        FQDN of LDMS core.

-c INI_file    Uses INI configuration file for installation preferences.

-d             Add debug lines to output.

-h             Prints help message.

-i pkg         Installs specified agent packages [all, cba8, ldiscan, sdclient or vulscan].

-l log_file    Log file for logging output [default: stdout].

-k cert_file   Certificate file.

-p             Install prerequisites - pulled from distribution repositories or Core.

-r pkg         Remove specified agent packages [all, cba8, ldiscan, sdclient or vulscan].

-R             With option -r, ensures the /opt/landesk directory is gone including the GUID file.

-u repo_url    Custom repository definition (Linux Only).

-D             Install assuming no network connection except to core. (Overrides -p and -u options).

Script Examples:

• Installation from no-exec /tmp partition (very important to include the path to script):

./bin/sh /tmp/nixconfig.sh -a win-pt2tta27i1n.ivanti.com -i all -p

• Installation from standard /tmp partition:

./nixconfig.sh -a win-pt2tta27i1n.ivanti.com -i all -p

• Remove installation leaving breadcrumb (add -R to remove breadcrumb):

./nixconfig.sh -r allNotes:

• -D allows the customer to install the Agent packages without access to a known repository but does require access to the Core.
• - The “-u” (custom repo) option - you need to specify the URL to a proper repository definition file hosted on the RPM repository (http://www.example.com/example.repo).
• - Custom repositories and prerequisite installations can be defined in the INI file but the Core UI does not support them at this point.
  • PRQ=YES under Products in the INI file will install Prerequisites.
  • A section with the following format adds a custom repository (secondary repos can be added by separating the strings with a space):

[Custom Repository]Repository=”http://www.example1.com/example1.repo”

• - To remove an agent from the Core via push the user can modify the INI file and set all of the products to NO (same as “-r all” on the CLI).
• - Upgrades are handled by removing individual existing components and then reinstalling them.
• - Prerequisites for Linux distributions will be pulled from the distribution repository.
• - Prerequisites for Unix systems are pulled from the Core so the LDMS user would just need to put the proper packages under the proper OS directory on the Core.

Prerequisites

• CentOS/Red Hat Enterprise Linux 6 Packages:

  • glibc, pam, xinetd, libgcc, libxml2, zlib, openssl, libtool-ltdl

• CentOS/Red Hat Enterprise Linux 7 Packages:

  • glibc, pam, xinetd, libgcc, libxml2, zlib, openssl, libtool-ltdl

• SuSE Linux Enterprise Server 11 Packages:

  • glibc, pam, xinetd, libgcc46, libxml2, zlib, util-linux, libtool

• SuSE Linux Enterprise Server 12 Packages:

  • glibc, pam, xinetd, libgcc_s1, libxml2-2, libz1, openssl, util-linux, libtool

• Ubuntu 14.04 and 16.04 Packages:

  • libpam-runtime, xinetd, libxml2, zlib1g, openssl, libltdl7

• Raspbian version 8 (Jessie)
  • uuid-runtime, libpam-runtime, xinetd, libxml2, zlib1g, openssl, libltdl7

Configuration Files:

This info is fairly extensive and have created a separate doc to over the full details. Please see doc: 2017.3+ Linux Agent Conf Files

Script Tools:

Questions:

• Regarding pre-req packages does the core now ship with these files?
  • For AIX, HP-UX and Solaris, if the customer puts the prerequisite packages on their core in ldlogon/unix/(aix|hpux|solaris)/ directory, they can use the -p option and the script will pull the prerequisites from the Core (if wget or curl is available).  Linux customers need to have an accessible RPM repository.  The prerequisites are not shipped with the Core at this point because we have some legal work to go through to ensure we can redistribute the packages without issue.
• Does the installer look automatically for a .0 (public key) cert file in its “run” directory?
  • Yes – they can be specified on the command line, INI file or just placed in the run directory – all should work
• Is there currently failover logic around the pre-req repositories?
  • We assume Linux distros will have access to a repository and yum/zypper setup properly to work (no “failover”).  Unix variants will only contact the Core for prerequisites.  If the Linux package manager doesn’t work, the prerequisite install will fail at this point.
• Does the installer support offline installation?
  • Yes, if needed you can copy the nixconfig script, the INI, the .0, as well as the tar.gz files to the machine.  Then once you have set execution rights run these as root.

Hello,

I would like to install the linux agent on a Debian server. I have the Endpoint Security 8.5 U1 installed and tried with some of the agents provided in the "Tools / Download agent installer" menu.

Each time I have the following on the Linux Debian server :

root@GCRM01:~/UnixPatchAgent# ./install

 

Installing HEAT PatchLink Agent 8.3051

Copyright (c) 2015 HEAT Software USA Inc.

 

 

Performing tests for Manual install...

Manual installation tests successfully completed.

 

 

Enter the directory where HEAT PatchLink Agent should be installed [/usr/local]:

Expanding archive...

ERROR: A proper release file was not found in /etc/

Please install the correct redhat-relese or suse-release package and retry the installation

Is there any way to install the agent on a Debian server ?

Thanks

Best regards

Gabriel Maret

• • Issue:
  • Troubleshoot:
  • Cause:
  • Resolution:

Issue:

The task is in pending status and does not change when deploying software to Linux platform agent with Policy method. It happens to when you try to apply a Linux patch with Policy too.

Troubleshoot:

Get the policy.log, scheduler.log, vulnerability.log from the Linux platform agent.

You may find below in the log:

Force Redeployment: false, Is Multi-Task Protected: true, Policy Deployable: false, Policy Type (roll-up): true, Push Policy (roll-up): false]

Cause:

This is a configuration issue. If Force Redeployment has NOT been checked on the core and multitask-protection is true on the core then this policy task should NOT be rescheduled to run on the client.

Resolution:

Either force redeployment needs to be true which translates to the Task setting “Ignore subsequent requests on successfully targeted clients” being checked:

Or multi-task protection needs to be false which translates to the Distribution and Patch agent setting under Install/remove options “If a multiple-patch task is running, then…” be checked. This is under Software Distribution agent setting:

Description: This is a quick reference list of some agent errors or problems that have been noticed and the fixes that are needed to remedy them. These issues (if not already addressed) should be fixed in future service updates.

Issue 1: "cannot use operator[] with boolean" message when running vulscan. Message should appear in the /opt/landesk/log/vulnerability.log

Resolution:This was a bug in the vulnerability scanner that was fixed in 2017.3 SU3. A work around would be to remove any patches from the unassigned group for Linux.

Issue 2: "terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::substr" when running a vulnerability scan. This message should also appear in the /opt/landesk/log/vulnerability.log

Resolution:This is a bug that should be addressed in a future service update. A complete removal and reinstall with specifying the core certificate should resolve the problem.

1. Remove the database record for the client.
2. Remove the agent on the client. Command: nixconfig.sh -r all -R
3. Reinstall the agent but be sure to include the most current certificate on the core as a parameter. Example: ./nixconfig.sh -p -a mycore.ivanti.com -i all -k e19d0bd5.0 (substitute the corename and the .0 file on the core server)

Issue 3: "Failed to uncompress stream" when running a vulnerability scan

Resolution:The cause/resolution is still being researched however the vulnerabilitydata on the core may be at fault.

1. Rename (or delete) the vulnerabilitydata files (2 of them) on the core for the specific OS.
   1. Directory: C:\Program Files\LANDesk\ManagementSuite\ldlogon\VulnerabilityData
   2. There will be two files. XML and XMLZ for each OS. Example Red Hat 7: 100_rhel7_x86_64_intl.1521136382.xml and 100_rhel7_x86_64_intl.1521136382.xmlz
   3. Rename both files.
   4. Run a vulnerability scan on the client. The scan should make a request to the core. Vulcore should then rebuild the vulnerabilitydata for that OS.
      1. Note: If the rebuild of the file doesn't happen then the .NET cache for it will need to be removed. Follow these steps:
         1. At a command prompt run: IISRESET /STOP
         2. Delete the folder: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\wsvulnerabilitycore
         3. At a command prompt run: IISRESET /START

Issue 4: Agent Status Icons are not working or the right-click request a scan is grayed out.

Resolution: This issue can be caused by a few sources. The core is attempting to reach the client so DNS, network issues, etc can all cause the problem. If the core does reach the client it will then compare the DeviceID. Make sure the ID matches what is shown in inventory. If the client doesn't match then remove the database record for the client and perform a full inventory scan.

The client DeviceID is located in the file: /opt/landesk/etc/landesk.conf

The core DeviceID is located in the inventory record:

Hello everybody,

Has someone experience with agent installation on Ubuntu?

I have tried this instructions : Manual Install of 64 Bit Linux/Unix Agent

After all I successfully installed the client and the process is running.

But now the problem: I get no information about this device in our Management Suite.

I'm not sure if the scan fails or if it has problems to send data to our server. This is how the scan file looks like.

Can somebody help?

Thank you

Introduction

This document is designed to give a new IVANTI Administrator a quick way to patch linux agent via patch manager component.  It will get you started so you have a solid starting place to build upon.

Assumptions

A license for Linux OS is required for patch installation, you need active your Linux subscription by registering with Linux Vendor.

As we call on YUM to download and install linux patch, you can check the YUM configure file once you complete the registration

Detailed step

1, Download Linux patch definition

2, Run vulscan on Linux client

[root@localhost Desktop]# cd /opt/landesk/bin/

[root@localhost bin]# ./vulscan -V255

3, Go to Ivanti core server and right-click that device. Then select "Security and Patch Information"

4,Right click the the detected vulnerability, and select "Repair" to create a repair task.

Once you run the task, the client will call on YUM to download the patches you have specified, then run YUM install to install the package.

Note: If you want to learn more about YUM, please see article as below

How to use YUM to fix linux agent dependency package issue

Suggestions for Troubleshooting

When experiencing problems with the security scan (vulscan stays in memory or fails to report a vulnerability, etc) a helpful step for troubleshooting is to use the Linux "tail" command in one terminal window while executing the security scan in another. See the screen shot below. The tail command will constantly monitor the vulscan log after it's executed and report updates to the log in real time. If the scan gets stuck or hung on a specific vulnerability it will be identified in the log. 

Command to execute the tail: (note: the 500 in the command below just dictates how many lines to watch at the end of the log file)

tail -f -n 500 /opt/landesk/logs/vulscan.log

Command to execute the security scan:

/opt/landesk/bin/vulscan -V255

After executing the command it may be a minute before the scan starts. You can see two copies of the putty.exe application is running with the same user logged into both. The scan gets sent as a job and waits for the job to be executed. The scan is currently running and parsing through each vulnerability.

This article details the troubleshooting steps and other related information for Linux and Unix agents. This information will help configure and resolve issues with the Linux and Unix agents.

General Information

Linux and Unix agents in Ivanti have changed their structure 2 times over several versions. Below is a timeline of sorts that explains each version

Supported Flavors and Versions of Linux can be found in the following article: Supported Platforms and Compatibility Matrix

How to tell the difference between the 64-bit and 32-bit Linux agents

General Information on the 2017.3 Linux Agent

Agent Installation

• 32-bit and MAP Agent
  • Push and Manual Install
    • For these versions of the agent it's required to copy over several files before running the agent. Details on this process can be found in this article: Manual Install of the 64-bit Linux/Unix Agent.
    • For both push and manual installs please reference this article: How to install the 32-bit and 64-bit Linux and Unix agents in 9.x (this will cover 2016.x as well)
• 2017.3 Agent
  • General Information, Push, and Manual Install. Also, prerequisite information can also be found here: 2017.3 Linux Agent
  • Push Install
    • This version of the agent can install with the same requirements for pushing agents as the 32-bit and MAP agent but it also has the ability to push with a non-root user. This type of push does require some pre-configuration of the machine in order to make it work. Details can be found in this article: How to: Push a Linux agent using a non-root user with some agent install troubleshooting notes
  • Manual Install
    • Nixconfig.sh - If you are familiar with the windows manual installation tool (wscfg32.exe) then this is the Linux equivalent. However, in addition to installing the agent it can also automatically install needed dependencies and is even used for removal of the agent among other options. Details and options on using this tool can be found in the following article: LDMS 2016 SU4 Agent Install Changes.

Installation log files

Possible Installation issues

Dependency and permission problems are the most common issues when installing the Linux and Unix agents. Be sure to analyze firewall traffic (or disable as a test), look at various logs, and test with different users. DNS problems going to the device and back to the core can also be an issue. Please test with both hostname and Fully Qualified Domain Name (FQDN) in both directions.Also see the General Errors and Fixes section below. Prerequisite applications needed by the agent can also be an installation problem. Please reference the update log for the particular Linux OS that you're working with.

General Errors and Fixes

2017.3 Agent Errors and Fixes

Uninstalling the Linux and Unix Agents

• 32-bit and MAP Agent
  • Rmlinux64client.sh. For details, options, and to download this tool see the following article: How to uninstall the Linux and Unix agents and the options available

• 2017.3 Agent
  • Use nixconfig.sh as noted in the installation section above. This tool both installs and removes the agent. As noted in the referenced article there are additional options to remove the agent more thoroughly as well.

Settings and Custom Information

• MAP Agents
  • How to scan custom data on Linux/Unix Platforms in detail (MAP Agent)
• 2017.3 Agent
  • How to scan custom data on Linux/Unix Platforms in detail (2017.3 onwards)

Vulnerabilities and Patching

• Ivanti is able to detect vulnerabilities on many platforms but we cannot store Linux patches. For remediation a patching server needs to be configured in the client OS which may require a support agreement with the corresponding vendor. The patching server can be either a public server or a type of satellite server that is local to the network. A satellite server is helpful so that each client doesn't download the same patch over and over.
• The utility on the client OS that's used to install the patch will depend on the particular Linux OS. When remediating patches Ivanti will call the client tool to download and install the patch. Please research the correct tool for the OS that you're working with and it's corresponding logs for troubleshooting. Some troubleshooting can also be found in the system logs on the client (/var/log/messages, etc) and the Client Side Logs listed below.
• Additional Articles for configuration and troubleshooting security scans on Linux:
  • General Troubleshooting Information
    • How to detect and remediate vulnerabilities
  • Map Agent
    • How to leverage Linux vendor tools to remediate vulnerabilities
    • How to gather debug output from a patch repair job for a 64-bit Linux agent

Client Side Logs:

2017.3 and MAP Agent

Agent Install Directories

Gathering logging information for Ivanti support

Standard Log Files

Description: On 9.0 and above LANDesk core servers there is an option in the Agent Configuration to specify if that agent is 32-bit or 64-bit. Each agent configuration will employ a different set of files and those files operate completely different from one another. Also, with the release of 2017.3 a new agent structure is now in place. Telling the difference between these agents can be difficult. The 32-bit agent technically can be installed on both a 32-bit and 64-bit OS's for example.

NOTE: Only 1 agent (either 32-bit or 64-bit) can be used at a time. Both agents on 1 device will cause problems.

[2017.3 Agent]

This is the newest Linux agent. The agent is in use on all supported Linux distributions in 2017.3 and onwards. Unix clients still use the MAP Agent below. This is a directory listing of /opt/landesk/bin.

[64-bit MAP Agent]

The 64-bit agent is newer than the 32-bit agent but it's also more self-sufficient. This agent will include it's own scheduler that runs in memory and will execute tasks according to configuration. The primary installation directory is /opt while it will configure links in the /usr/LANDesk directory.

[32-bit Agent]

The 32-bit agent is older and operates much differently. Inventory and Security scans are scheduled manually through cron. The inventory scanner is found in /usr/LANDesk/ldms.

It's recommended to use a naming convention with the agent which will make it easier to tell through the inventory scan. See below..the Agent Configuration Name is shown:

Description: When repairing kernel related patches these patches may remain in the "All Detected" section of Security and Patch Information while some may move to "All Installed". The reason for this is the old kernels still remain on the machine. If the machine is booted with the old kernels then the machine will be vulnerable.

Solution: A code change is planned to address the design in a different way and detect the current running kernel. To make reports and the GUI show as "fixed" remove the old kernel files from the machine and they should no longer show vulnerable.

Example: CESA-2017-3200 below. Depending on the particular vulnerability some may move correctly while others do not.

Description: This document is intended to help with troubleshooting Linux and Unix LANDesk agents. The document will contain several tips and tricks to discover problems on various features of the agent. The document is written around Linux so if Unix is the client then changes to the listed options will probably be needed but most of the executables are the same.

Analyzing logs dynamically while they are being updated

Linux and Unix includes a tool called "tail". Tail has the ability to constantly display a file and list the changes that are added to it AS they are being added. This is helpful in many circumstances. You can monitor several log files at once and easily see the order they are updated. You can watch a particular log to see if anything changes while running an application. Etc. Here is an example command that should work on many Linux distributions. (Note: The syntax may be slightly different on Unix platforms etc. Search the internet for proper syntax). This command is especially helpful to watch /var/log/messages. For those that are familiar with Windows this file is as close to the Event logs as you can get.

tail -f -n 100 /opt/landesk/logs/landesk.log

-f = A continous monitor of the file instead of just listing the last few lines of the file.

-n = The number of lines at the end of the file to list or watch

See the screen shot below...tail is watching landesk.log, scheduler.log, and vulscan.log at the same time in separate windows while an inventory or vulscan can be run in the top terminal window

Searching for files on the entire system

Command: find / -name filename

Description: The find command will start searching in the / (root directory) and search for the name of a file. Other parameters may include size or other file options.

Listing ports that are open

Command: netstat -auntp

Description: General command for Windows and Linux that shows open ports. (command options differ from Windows) This is good to see if cba is listening on the right ports. Ensuring the ports are open on the firewall is good as well.

Quick Information on using VI to edit a file

Description: Simple instructions for opening a file, editing it, then saving it again. VI is a simple editor that has two modes. One edits like a normal text editor while the other performs operations/commands. Toggling back and forth is key to using VI.

Example: Editing a hosts file to add a static name resolution

1- vi /etc/hosts

2- Press the letter "i" to enter "Insert" mode.

3- Edit the file and perform what operations you like.

4- Hit the ESC button to return to "Command" mode when you're done.

5- Press ":" to get a command prompt within the editor. Or type a ":" to apply one of the following commands.

6- Exit the editor with what action you want:

     q! = Quit, discard changes, and I mean it

     wq! = Write changes, quit, and I mean it.

While navigating in command mode, it doesn't use arrow keys, but letters:

H(Left) J(Down) K(Up) L(Right)

Searching a file for specific words and content

Description: cat filename | grep searchword

Explanation: "cat" will display the contents of a file. "grep" will search a file for a specific word. The "|" or pipe symbol chains the commands together to produce a more powerful command that searches a file

Example: See below...cat and grep are used twice...once to search for the word "sender" and the other to search for the word "PipeToProxyHost"

Checking applications that are running in memory

Description: "top" is the command to display all applications running on a Linux system. No command line options are needed. It will also display free space, memory, and other information.

h = The help menu

SHIFT + < = Toggles left on the list

SHIFT + > = Toggles right on the list

q = Quit

Example: The screen shot below shows map-scheduler listed which is part of the 64-bit LANDesk agent

Checking disk space

Command: df

Output: See below

File Permissions and Other Properties

Description: See below...the following diagram will show the file rights that are located on just about everything in Linux. If you use "ls -l" in a particular directory it will list all the files and display the information below. Example: In order for a file to be executable by everyone it will have an "x" in all three columns.

Command to change permissions: chmod +x filename

Description: This command will add execute permission to everyone on the file. The "+x" can be a "-" as well as "r" or "w" to add or subtract permissions across Owner, Group, and Others.

Overview:

The goal of this document is to act as a guide on not only how to perform a vulnerability scan but also what to do when a scan doesn't work correctly.

Scope:

• 2017.3 agent and MAP Agent (2016.x and 2017.1)

Client Requirements:

• Clients will need access to their own patch repository. This requirement can vary according to the OS flavor. Some examples and notes and below:
  • Red Hat versions will require a support agreement
  • CentOS is free but access (ports, resolution, firewall, etc) will need to be allowed.
  • Some versions of Linux can make use of a "satellite server" which is a local repository of patches so each client can get the needed patches locally instead of going to the internet.
• Clients will need an Ivanti EPM agent installed

Process Outline:

1. Vulnerabilities need to be downloaded to the core server before a client machine will show vulnerable. For a detailed walk-through see: How to detect and remediate Linux vulnerabilities
2. An agent needs to be installed on the client
3. A vulnerability scan needs to be performed.
   1. Example command: /opt/landesk/bin/vulscan -V255
   2. This command increases the verbosity of the logging on the scan
   3. This command can be executed from the console by right-clicking on a machine, however, Agent Status (Discovery) needs to be functional. See the communication information in the troubleshooting section below
4. A repair task for a specific vulnerability needs to be configured and executed
   1. A policy supported push is the most common type to use
   2. If the push doesn't succeed (for whatever reason) then a policy scan will need to be invoked on the client: /opt/landesk/bin/policy
   3. You can right-click on a specific machine, select Security and Patch, then select Security and Patch Information. This will display all of the detected and installed information.

1. A second vulnerability scan may need to be performed. This is to report the vulnerability is no longer present
   1. Note: Kernel patches may still show vulnerable if the affected older kernel files are not removed from the machine

Additional Note: You can see what a machine is vulnerable for by right-clicking and selecting "Security and Patch Information".

Troubleshooting, Help, and Logs:

• How to troubleshoot Linux and Unix
• Command to tell what ivanti or landesk processes are running on a Linux machine: "ps -ef | grep landesk"
  • See the screen shot below. In this case only CBA and the grep command (when running the command above) are currently in memory

• How to search for a vulnerability using "vi" (Linux editor)

1. Edit the vulnerability.log: vi /opt/landesk/log/vulnerability.log
2. Enter command mode by holding down the shift and colon keys. You should see a colon at the bottom of the screen: SHIFT and :

           3. Search for the vulnerability by package name. You can find the name in the properties of the vulnerability. You can search by prefacing the name with a "/"

                       Example: NetworkManager-wwan-1.0.6-29.e17_2.x86_64.rpm

                       Note: In this case I searched using the first part of the full name but the full name can be used

                       Note: The cursor moves to the targeted line in the file. Repeat the steps to find the next line.

                       In most cases the requested package and installed package are compared and the results are displayed.

• Linux clients (just like windows) are affected by common communication problems between the core and client.
  • DNS resolution forward and reverse between the core and client
  • Firewalls and ports. The Linux agent doesn't add exceptions to the firewall. This needs to be done manually according to what firewall is in use.
    • Firewalls cause a large majority of Agent Status and Discovery issues (icons in the console)
  • The "cba" client as shown above in this section, needs to be running to receive instructions from the core server

• Analyze the vulnerability definition on the core server.
  • Find a vulnerability in the console.
  • Right-click and select properties.
  • Click on a specific vulnerability name and select properties again. Analyze all of the information.

                    Example: This screen shot shows what platforms the vulnerability affects. This information is usually correct but if it's not, log a case with support to get the content corrected. Other settings should be verified too when troubleshooting.

• Analyze the update log for the particular version of Linux that you are working with.
  • Log location for most logs: /var/log
  • Update and utility will vary by Linux flavor. Some examples are below but these examples may vary by version as well. Search the internet for patch logs related to a specific build
    • Red Hat = Yum (var/log/yum.log). Up2date was used in older versions.
    • Ubuntu = Read the history.log located in /var/log/apt
    • SUSE = /var/log/zypp/history

Known Issues:

• 2017.3 Agent Errors and Fixes

• At the time of this writing Linux clients cannot communicate through a Cloud Services Appliance (CSA). This feature is on the road map to be added in a future release. No date is currently available.

• Linux Kernel Vulnerabilities
  • Issue: Some Linux kernel vulnerabilities may continue to show in the All Detected section of the Security and Patch Information window. The reason for this is that older kernel files still reside on the client. If these files are used then the client will be vulnerable again. An enhancement is planned to add detection for the currently running kernel. This enhancement will be in the future and no date is currently available.
  • Fix: Remove the older vulnerable kernel files

• The "History" portion of the Security and Patch Information window does not work at this time and will display an error (see screen shot below).
  • The error is "Certificate based authentication failed" and "Client did not submit a certificate"
  • This error is due to the client-certificate based security feature. Linux clients don't currently use this feature but plan to in the future.

Hi team,

We have Ivanti Endpoint Security 8.5.0.20 (8.5 Update 1) installed and I would like to install the agent on our Red Hat 7.4 servers, but face several issues:

1. The Agent 8.3057 installation worked fine
2. I see the DAU scan status is "Failed FFFFFFFF"
3. When clicking on the status, I see
   Last Run Result: STDERR:[/bin/sh: /tmp/update.4595596053691871914.bat: Permission denied]. 
4. On the client the file exists and has rwx permissions for root only:
   -rwx------. 1 root root 281 May  4 10:27 /tmp/update.4595596053691871914.bat
5. Actually there is no permission issue, just a script that should either
   1. contain "#!/bin/sh" as a 1st line or
   2. be run with the command "/bin/sh /tmp/update.4595596053691871914.bat", not simply "/tmp/update.4595596053691871914.bat"
6. Anyway, if I go a little bit further and use one or the other method mentioned above, I can run the update script and get the following failure:
   Unsupported OS 'Red Hat Enterprise Linux Server 7 on x86_64
   This is not exactly what I understand from
   https://help.ivanti.com/ht/help/en_US/IES/85U1/Ivanti_ES_8.5U1_Agent_InstallGuide.pdf
7. Actually /tmp/update.4595596053691871914.bat calls /usr/local/patchagent/update/bin/detect, which in turn call /usr/local/patchagent/update/bin/Updatemcescan_Linux
   and in Updatemcescan_Linux, there is a list of supported operating systems:
   OSNAME=$(./getOSLongName_Linux)
   
   case "$OSNAME" in
       ...
       "Red Hat Enterprise Linux Client 5 on x86") ;;
       "Red Hat Enterprise Linux Server 5 on x86") ;;
       "Red Hat Enterprise Linux Client 5 on x86_64") ;;
       "Red Hat Enterprise Linux Server 5 on x86_64") ;;
       "Red Hat Enterprise Linux Client 6 on x86") ;;
       "Red Hat Enterprise Linux Client 6 on x86_64") ;;
       "Red Hat Enterprise Linux Server 6 on x86") ;;
       "Red Hat Enterprise Linux Server 6 on x86_64") ;;
       *) echo "Unsupported OS '$OSNAME'"; exit ;;
   esac
8. If I push a little bit further, I see that Updatemcescan_Linux get a file mcescan-1.953-x64.tar.gz from the server, which should contain a file mcescan-x64/mcescan-base-rh7-x64.tar.bz2, but only contains mcescan-x64/mcescan-base-rh6-x64.tar.bz2.

So my question is the following: did I miss something or does the Agent 8.3057 really not support RHEL 7 ?

Thanks in advance for your feedback,

Stefane

Hi folks,

In this topic "Supported Platforms and Compatibility Matrix for LANDESK Management Suite/Ivanti Endpoint Manager" https://community.ivanti.com/docs/DOC-23848I can see AIX,Ubuntu are supported for Ivanti Agent.

But in Patch & Compliance --> Download --> Updates I can not see AIX, Ubuntu.

Could it be possible if anyone can confirm the Patch and Compliance is supported or not for download patches for following operating system:

- AIX
- Red Hat Enterprise Linux
- Oracle Linux
- Oracle Solaris, Sun Solaris
- CentOS
- SUSE Linux Enterprise
- Ubuntu Linux

Thanks a lot!

Hi, Can you help to answer the following?

• How does Ivanti patch Linux Redhat? How does it commuicate to RHEL? Any requirement from client on the patching and what are the mechanisms?
• What are Ivanti procedures to prevent infinite loop (after patching)?
• Does customer still need to purchase subscription from vendor?
• Does Ivanti anti-virus cover platform for Linux?
• Does Ivanti support Sophos and Oracle?

Thank you.