Description

The LANDesk agent for Solaris is includes only the ability to do inventory scanning and vulnerability scanning and works on Solaris 8 and 9 only.  There are no

A single package exists that is installed by decompressing the packaging with gunzip and installing the package with pkgadd.

Installing the LANDesk Agent for Solaris

To install the LANDesk Agent on Solaris 9, do the following:

1. Copy vulScan-8.6.0.1-sol9-sparc-local.gz to the Solaris server.  Place the file in /tmp or else take note of where on the Solaris server the file was copied.

2. Connect to the Solaris server using ssh.

3. Run the following commands:

cd /tmp
gunzip vulScan-8.6.0.1-sol9-sparc-local.gz
pkgadd -d ./vulScan-8.6.0.1-sol9-sparc-local

4. Edit the /etc/vulScan.conf and change the core = EXXPEEE.landesk.com value to be your Core Server.

5. Also change the platformid to be one of the following: (Paste this in and delete the comment from before the correct version.)

#platformid solaris7
#platformid solaris8
#platformid solaris9

6. Run an inventory scan.

/usr/LANDesk/ldms/ldiscnux -ntt=CoreServer.domain.tld:5007 -v

Installation is complete

File Information

The following files are contained in this archive:

Prerequisite Software

The following dependencies are required for the LANDesk agent to function.

• libstdc++.so - version 5.0.4 or later
  vulScan was compiled against libstdc+.so version 5.0.4 and has not been tested with earlier versions.
  libstdc+ is part of the gcc package and can be found at:
  ftp://sunsite.cnlab-switch.ch/mirror/solaris-freeware/sparc/8/libgcc-3.3-sol8-sparc-local.gz
   

• libexpat.so - version 0.5 or later
  libexpat is the xml parser library used in vulScan.
  libexpat.so is part of James Clark's Expat XML parser library.  Expat downloads can be found at:
  http://sourceforge.net/projects/expat/

Using the ldiscnux Inventory Scanner

ldiscnux can be automated by use of the crontab command to cause the system to be rescanned on a periodic basis.  When sending scans to a server using -ntt=. Software scans will be performed once a day (unless forced with the -f switch) as determined by the inventory server.  (See Configure | Services | Inventory in the LANDesk Console on the Core Server).  The extent of the software scan can be controlled by the ldappl.conf file (see bottom of this doc).

To debug the inventory scanner you can output a scan to a text file with the followign command:

ldiscnux -o=scn.txt

This method enables you to see if the scanner is working locally on the computer. You can then run the inventory scanner to the LANDesk Core Server via IP socket (5007 by default) using this command:

ldiscnux -ntt=192.168.121.1 -f

The syntax for ldiscnux is as follows:

xLANDesk(R) Inventory Scanner (Solaris) Version 6.6
Copyright (c) 1999-2003 LANDesk Software Inc.  All Rights Reserved.
ldiscnux [-d=] [-f]|[-f-] [-i=] [-ntt=] [-o=] [-stdout] [-v] [-x] [-h]|[-?]
 -d=Dir         Starts the software scan in the Dir directory instead                of the root directory.
 -f             Forces a software scan.
 -f-            Forces no software scan.
 -i=ConfName    Specifies the conf filename. Default is /etc/ldappl.conf.
 -ntt=addr:port Host name or IP address of inventory server. Port is optional.
 -o=File        Inventory information is written to the specified                output file.
 -stdout        Inventory information is written to standard output
 -v             Enables verbose status messages during the scan.
 -x             Enables software scanning of network file systems (i.e. smbfs or nfs).
 -? or -h       Displays this help screen.
One of -ntt, -o or -stdout is required for the scanner to function.
Ex:  ldiscnux -ntt=123.456.10.11 -o=out.txt

The Device ID is maintained in the /etc/ldiscnux.conf file.

Last Software Scan Date=1224631115
Last Hardware Scan Date=1224631114
Device ID={39373938-3632-3233-3039-373938363232}

Using the vulScan Vulnerability Scanner

vulScan: LANDesk Vulerability scanner
usage: vulScan [-f <filename>] [-vhsuv] [-o filename]        -f <cfgfile>         use <cfgfile> for configuration information        -o <outfile>         writes the results sent to the core to <outfile>.        -v                   more verbose output (one or more times)        -h                   show this and exit        -s                   scan but don't bother to update the vulnerability cache        -u                   update definitions cache only        -V                   show version and exit

The /etc/vulScan.conf file must have the correct Core Server name manually entered.

core = YourCore.Domain.tld

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

Debian / Ubuntu

(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.

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 followaing 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>

 

Note that you can EITHER use "your intended names" directly (as we do in the case of "<Registry>"-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

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.

Issue:

You configure the 'root' account as alternative credentials in the Scheduler Service configuration. You do an unmanaged device discovery and try to push the agent to the devices you configure. They fail, with a log file indicating that authorization has been refused. LANDESK uses Putty to log remotely into the Linux/Solaris device. When you enter the root account/password in Putty directly you will get diconnected immediately.

Cause:

Access through SSH can be disabled for the root account.

Resolution:

You need to login to the device directly, access the shell and edit the following file like this:

vi /etc/ssh/sshd_config

Search for PermitRootLogon using the following command:

:/PermitRoot

Change the configured value to 'yes' (using INSERT or i to be able to insert text)

exit VI

ESC+:w

ESC+:q

Now restart the SSH service:

svcadm restart svc:/network/ssh

This will now allow you to push your agent to this device using the root account

Note: if you don't login with root in the shell, it can be necessary to sudo these commands.

Verified Product Versions

LANDESK Management Suite 9.5

LANDESK Management Suite 9.6

Description

This article would help you identify if dependency as below article for UNIX agent have sucessfully installed, and check if the shared libraries are loaded at run-time on UNIX.

*nix Agent Dependencies

You can use swlist then pass this to grep, the output should look like below for each of the required packages.

[root@lab-hpux11v2-hppa] /opt/landesk/bin =)

eng.landesk.com> swlist | grep ixZlib

ixZlib A.20.00-1.2.7.001 zlib compression library

[root@lab-hpux11v2-hppa] /opt/landesk/bin =)

eng.landesk.com> swlist | grep libgcc

libgcc 4.2.3 libgcc

[root@lab-hpux11v2-hppa] /opt/landesk/bin =)

eng.landesk.com> swlist | grep openssl

openssl 1.0.1g openssl

The utility ldd that could prints the shared libraries required by each programs,you can check with this utility tool to verify which dependency file missing right now. The ldd should look like below for each of the programs.

eng.landesk.com> ldd ./ldiscan

        /usr/lib/libc.2 =>      /usr/lib/libc.2

        /usr/lib/libdld.2 =>    /usr/lib/libdld.2

        /usr/lib/libc.2 =>      /usr/lib/libc.2

        /usr/lib/libm.2 =>      /usr/lib/libm.2

        /usr/local/lib/libstdc++.sl =>  /usr/local/lib/libstdc++.sl

        /usr/lib/libc.2 =>      /usr/lib/libc.2

        /usr/lib/libm.2 =>      /usr/lib/libm.2

Hi everyone! I am almost sure this is not a supported OS but thought I would ask. I tried after setting the alternate credentials and installing ssh.. but  get this error after pushing and it failed  See log

[refusing authorization to store unknown host-key]

The server's host key is not cached in the registry. You

have no guarantee that the server is the computer you

think it is.

The server's rsa2 key fingerprint is:

ssh-rsa 2048 a2:31:f1:f0:c6:8d:a1:f8:63:aa:49:6e:3f:d2:72:67

If you trust this host, enter "y" to add the key to

PuTTY's cache and carry on connecting.

If you want to carry on connecting just once, without

adding the key to the cache, enter "n".

If you do not trust this host, press Return to abandon the

connection.

Store key in cache? (y/n)

[refusing authorization to store unknown host-key]

The server's host key is not cached in the registry. You

have no guarantee that the server is the computer you

think it is.

The server's rsa2 key fingerprint is:

ssh-rsa 2048 a2:31:f1:f0:c6:8d:a1:f8:63:aa:49:6e:3f:d2:72:67

If you trust this host, enter "y" to add the key to

PuTTY's cache and carry on connecting.

If you want to carry on connecting just once, without

adding the key to the cache, enter "n".

If you do not trust this host, press Return to abandon the

connection.

Store key in cache? (y/n) Sat Jul 25 18:06:27 EDT 2015

### LdReExEc: /tmp/.ldcfg-476-8696/.stdout.sh

don't know how to control cba8

RV from child cmd: 1

[refusing authorization to store unknown host-key]

The server's host key is not cached in the registry. You

have no guarantee that the server is the computer you

think it is.

The server's rsa2 key fingerprint is:

ssh-rsa 2048 a2:31:f1:f0:c6:8d:a1:f8:63:aa:49:6e:3f:d2:72:67

If you trust this host, enter "y" to add the key to

PuTTY's cache and carry on connecting.

If you want to carry on connecting just once, without

adding the key to the cache, enter "n".

If you do not trust this host, press Return to abandon the

connection.

Store key in cache? (y/n) /usr/bin/head: cannot open ‘/tmp/.ldcfg-476-8696/.stdout.pid’ for reading: No such file or directory

Error 1 returned while un-managing the stack; continuing.

Removing packages: ldsmmonitor lsm-server lsm-admin lsm-client lsm-common Lbridge mgmtutilsSuSE mgmtutils ldipmi megalib ldnaSuSEldna ldsmbios smbase ...

Finished removal.

/bin/chown: changing ownership of ‘/tmp/.ldcfg-476-8696/3c5033c4.0’: Operation not permitted

/bin/chown: changing ownership of ‘/tmp/.ldcfg-476-8696/bff9aa43.0’: Operation not permitted

Unable to set ownership of /tmp/.ldcfg-476-8696/3c5033c4.0 /tmp/.ldcfg-476-8696/bff9aa43.0

Exiting with return code 1

CBA 8 X509 operation : -2147481845 (8000070b8u) : Unable to contact the remote agent.

NT File Sharing : 1222 (4c68u) : The network is not present or not started.

NT File Sharing : 53 (358u) : The network path was not found.

NT File Sharing : 53 (358u) : The network path was not found.

Error: [last attempted operation] RemoteExecute, /bin/sh "/tmp/.ldcfg-476-8696/install.sh" \"NOOEM=1\"; RemoteExecute, /bin/sh /tmp/.ldcfg-476-8696/.stdout.sh

Possible last exit_code: -1917517823

Environment: Unix/Linux agent deployment

Problem:

Agent Return Code 1895, CBA 8 The connection was not authorized.

Log:

  [refusing authorization to store unknown host-key]


The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 de:57:95:eb:12:89:48:63:6c:2e:f4:4b:5d:b2:35:38
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) Access denied
FATAL ERROR: Unable to authenticate
   
CBA 8 X509 operation : -2147481845 (8000070b8u) : Unable to contact the remote agent.
NT File Sharing : 1222 (4c68u) : The network is not present or not started.
NT File Sharing : 67 (438u) : The network name cannot be found.
NT File Sharing : 67 (438u) : The network name cannot be found.
Remote execute using TCP failed, result 0x00000581 (1409)  
Error: [last attempted operation] RemoteExecute, /bin/mkdir -p /tmp/.ldcfg-40-3732 
Possible last exit_code: 1409

Cause:

Without proper credentials, RSA fingerprint cannot be saved

Solution:

The "root" user credentials on each client system will need to be added to the Global Scheduler on the core (Configure - Services - Scheduler).  See DOC-27369.

Hi All,

Is there anyway to find a particular file under /etc/sysconfig/ ? I want to do a query, whether the file exists or not.

Regards,

Sukumar. R.

Installing the 64 bit Linux or Unix agent Manually

Applies to LDMS 9.5 and LDMS 9.6

*This will apply to most 64 bit *nix Installations with a couple of modifications. I.E. for HPUX. create an HPUX agent and get files from the HPUX folder

Steps:

1. Ensure the machine has the proper dependencies installed.  *nix Agent Dependencies
   
2. Create a Linux64Install folder somewhere to gather files on the Linux machine
3. Create a 64 Bit Linux agent in the LDMS console named linux64 or whatever you need to name it (try to avoid spaces when naming Linux agents, when we get to the point where we install manually spaces can add headache)
4. Open c:\program files\landesk\management suite\ldlogon
5. Copy any .0 files associated with the core to your Linux64Install folder
6. Make a certs subfolder in your Linux64Install folder and make a copy of the .0 files into it. The agent install consumes the .0 each time, so if you need to run multiple installs you have quick access
7. Locate linux64.sh (this will be named whatever you called the agent, same as with a windows agent ini) and copy it to your Linux64Install folder
8. Browse to c:\program files\landesk\management suite\ldlogon\unix\
9. Copy rmlinuxclient64.sh to your Linux64Install folder. (best practice to remove old agent first if applicable) typically you can get the most recent removal script from the following page. It is usually shipping but may be more recent
   1. How to uninstall the Linux and Unix agents and the options available
10. Browse to c:\program files\landesk\management suite\ldlogon\unix\linux
11. Copy baseclient64.tar.gz, vulscan64.tar.gz, and softwaredist.tar.gz to the Linux64Install folder
12. Using a tool like WinSCP, copy the Linux64Install folder to /tmp on the Linux machine
13. SSH to Linux machine as root and/or elevate the session after logging in
14. Change to temp directory cd /tmp/gather
15. Allow execute on removal script and install script chmod +x *.sh
16. Remove old agent if applicable ./rmlinuxclient64.sh
17. Install Agent ./linux64.sh

Update - October 2013 - Major update on content, including coverage of 9.5 SP1 and the changes this introduced (such as native 64-bit support for SLES-10).

I - Introduction

As it is regrettably a somewhat counter-intuitive subject matter, I intend to clarify a couple of items relating to *-ix OS's and the LANDesk agentry here.

I will clarify how to install which agent (32-bit vs 64-bit).

I will clarify which agent is supported on which platform (not as simple as you'd think).

I will give a few pointers / useful command-lines for when you are playing around with your *-ix OS.

I will mostly exclude HPUX here, as that platform has its install process documented on the LANDesk community, and the OS requires dedicated hardware, as it cannot be virtualised.

I do not claim to be a *-nix pro, so the below may include a variety of hacks that'd send a *-nix guy into a coma. The below *works* - that's all that this article claims to do.

II - 32-bit LANDesk agent

The most common way of installing the 32-bit LANDesk agent in a test environment requires a mapping to the LANDesk Core Server (or at least a complete copy of LDLOGON / subdirectories), as a combination of scripts pull down the relevant files and install them right away.

The process is as follows:

II.A - Mount a drive to the LANDesk Core and its LDLOGON directory

The 32-bit agent install is essentially a shell-script that is run, with a parameter of the agent-configuration that you want to use. As a result, it is necessary to map a drive to the LANDesk Core server for a manual install.

NOTE on mounting drives:

The exact command line used here will differ from OS to OS - and often from version to version, so I recommend that you check out Section V - DIRECT LINK - further below for details on the Linux distributions I used.

 

It may save you some considerable frustration.

I will refer to this share as "/mnt/Core/" from now on. Please substitute / amend the command-lines for whatever mount-name(s) you use.

II.B - go to the mounted directory

In other words, run:

cd /mnt/Core

II.C - From the mounted LDLOGON share run the installer

As previously mentioned, the 32-bit installer is essentially a shell-script - linuxpull.sh - which needs to be fed your desired agent-configuration's INI filename as a parameter.

./linuxpull.sh (AGENTCONFIG).ini

A real example for a 32-bit Linux configuration called "32_bit_Linux" would be for instance:

./linuxpull.sh 32_bit_Linux.ini

Note that this will require ROOT-level privileges.

This will install the agent. No inventory / vulscan takes place. You're done once the script is finished.

IMPORTANT DETAIL ON WHICH FILE YOU USE

Please note that you are using the ".INI" file here, and not the ".SH" !

You may want to consider running either an inventory scan at this point, or even an inventory scan followed by a vulnerability scan right away, so you have the device register with your LANDesk Core as soon as possible.

NOTES ON 32-BIT AGENT INSTALLS:

* As a rule, the 32-bit agent install will run an inventory scan at the end of the install (you will see the output on the screen).

* VULSCAN will not be run "by default" as part of the installation - once the inventory is on the Core, you might wish to kick this off yourself.

III - 64-bit LANDesk agent

There are a few differences between the 32-bit and 64-bit agents and their installations.

One of the first is that whilst the 64-bit agent WILL run an inventory scan as part of the install (after the install script itself has finished), this isn't as visible as it is with the 32-bit agent. Rather, it isn't visible at all. Whilst the 32-bit agent is pretty vocal about what it is doing to the display, the 64-bit agent is not - scheduled jobs run silently in the background.

The purpose here is to get an inventory scan ASAP to the Core, so that we can register the existence of the new device.

An easy trap to fall into is to assume that "if the OS is 64-bit, then I should install the 64-bit client". That is not so. Please see Section VI - DIRECT LINK - below to install the correct agent on the correct OS.

III.A - Mount a drive to the LANDesk Core and its LDLOGON directory / wherever the install binaries are

Whilst not a requirement with the 64-bit agent (there are alternative ways to get to the files), I will still assume that for most situations as part of your test-bed, you will map a drive to the Core directly.

NOTE on mounted drives:

The exact command line used here will differ from OS to OS - and often from version to version, so I recommend that you check out Section V - DIRECT LINK -  further below for details on the Linux distributions I used.

 

It may save you some considerable frustration.

III.B - Copy the required files down locally

These files are the following:

- The "(HASHVALUE).0" certificate file out of the Core's LDLOGON-directory

- The "(AGENTCONFIG).sh" shell-script file out of the Core's LDLOGON-directory

- The "BASECLIENT64.TAR.GZ" tarball out of the Core's LDLOGON\UNIX\(OSPLATFORM)\ -directory

- The "VULSCAN64.TAR.GZ" tarball out of the Core's LDLOGON\UNIX\(OSPLATFORM)\ -directory

So, for example, a real list of files (for a 64-bit Linux OS) for a 64-bit Linux agent configuration called "Linux_64_bit" would be:

- The "d4edf38c.0" certificate file out of the Core's LDLOGON-directory

- The "Linux_64_bit.sh" shell-script file out of the Core's LDLOGON-directory

- The "BASECLIENT64.TAR.GZ" tarball out of the Core's LDLOGON\UNIX\LINUX\ -directory

- The "VULSCAN64.TAR.GZ" tarball out of the Core's LDLOGON\UNIX\LINUX\ -directory

For any of the supported LINUX distributions, you need to go into LDLOGON\UNIX\LINUX\ .

For SOLARIS, you need to go into LDLOGON\UNIX\SOLARIS\ .

For HP-UX, you need to check out LDLOGON\UNIX\HPUX\ .

III.C - Grant the install-script execution rights

You do this by running the following command on the installer-script:

chmod +x (AGENTCONFIG).sh

So a real example would look like so:

chmod +x Linux_64_bit.sh

IMPORTANT DETAIL ON WHICH FILE YOU USE

Please note that you are using the ".SH" file here, and not the ".INI" !

III.D - Run the installer-script

You just need to execute it by running

./(AGENTCONFIG).sh

So a real example would appear like so:

./Linux_64_bit.sh

The installer will now run, and when you see the CLI (Command Line Interface) available to you again, the installation will be finished. Note that this will require ROOT-level privileges.

NOTES ON 64-BIT AGENT INSTALLS:

* As a rule, the 64-bit agent install will start an inventory scan as part of the install. So there's no need to start another LDISCAN command - it's already scheduled as a job.

* VULSCAN will not be run "by default" as part of the installation - once the inventory is on the Core, you might wish to kick this off yourself.

IV - Key differences / crucial reminders between 32-bit vs 64-bit agent installs

A note on "requiring Core Access"

Core-server access is only really required if either the "push"-based install, or this "pull"-based approach is used.

 

One *CAN* get around "requiring" Core Access, by copying files, or even repackaging RPM's. If the relevant *-NIX-expertise i availble, then the sky is the limit.

 

This article is merely intended to "help you get started" and assumes very limited exposure to *-NIX OS's, thus we try to keep things reasonably straight forward.

V - Hints, tips, command-line help and OS-specific things

For the purpose of the below, I'm assuming that a "Core" subdirectory has been created under "/mnt" that we will be mounting to. If you use a different directory, please amend the command-lines as needed.

V.A - SOLARIS

V.A.1 - Getting the agent binaries on a Solaris box

Despite banging my head for hours against the desk, looking at a plethora of help-files and talking to Adam, I've not been able to get Solaris to play ball and successfully connect to the LDLOGON share on a Windows Core.

Two fairly simple workarounds exist however:

Solaris Install Option 1 - Use a browser

Use a browser to browse to HTTP://CORE_NAME_OR_IP/LDLOGON/ and then copy down the .0-cert / the .SH-script.

 

Then copy the BASECLIENT64.TAR.GZ and VULSCAN64.TAR.GZ binaries from HTTP://CORE_NAME_OR_IP/LDLOGON/UNIX/SOLARIS/  and finally run the install with the locally downloaded files (remember to "chmod +x" the .SH-file!).

 

SOLARIS 10 will generally still have Firefox as a browser installed, at the very least.

 

Note

Solaris does *NOT* come with WGET by default. So you do need to actually use a browser.

- or -

Solaris Install Option 2 - SCP / FTP

Copy the necessary binaries to a cooperative Linux-box, and then use SCP (Secure Copy) to grab the files from the Linux box (I usually use Red Hat 5, as that is pretty benign for the most part).

 

SCP will have a few examples in Section VIII.A (useful commands -- DIRECT LINK), further below.

 

Alternatively, if you have an FTP-server or similar, you can just store the files there and pull them down with the Solaris box that way.

Pick your personal poison based on preference.

V.A.2 - SOLARIS and hostnames

Counter to intuition (as the OS install *DOES* ask you whether you wish to specify an OS name during the install), it actually takes a few extra steps to have a SOLARIS box "properly" report a hostname (that is, something other than "localhost.localdomain").

Here's what you need to do:

1 - go to the "/etc" directory

2 - create a file called "nodename" with a line containing the name of the device. I.e. - something like "mysolaris10x64" for instance. The following command would do just this:

gedit /etc/nodename

 

IMPORTANT -- end the line with a carriage return (i.e. "enter") or this will not work properly.

 

3 - save the file.

4 - Reboot the box.

 

REMEMBER -- *-ix is case sensitive.

And now you will have a proper network name come in through inventory

Do remember though, that you still need IP-details in "/etc/hosts", so that the box can resolve its own name!

NOTE:

I was originally led to believe that one could fix this "localhost" reporting problem by hacking around in the "/etc/hosts" file alone.

 

You may indeed find various forum-threads suggesting this - it is a bald-faced lie (at least it is in Solaris 10). The "nodename"-approach above is what actually works.

 

FINAL NOTE:

The above instructions only function for a Solaris install where you are in a X-Windows environment. If you just have a CLI (command-line interface) available to you, the following command line should help you get the required file created:

echo "(YOUR_CHOSEN_HOSTNAME)" > /etc/nodenme

 

"Real" example:

echo "Solaris-10-64" > etc/nodenme

 

This will also then include the necessary "carriage return" at the end of the "nodename"-file.

V.A.3 - SOLARIS and LANDesk 9.0 library requirements

No libraries are required, since they're included for Solaris as part of the agent install. Installing the LANDesk agent will put the following libraries into "/opt/landesk/lib/":

- libcrypto.so

- libcrypto.so.0.9.8

- libgcc_s.so.1

- libssl.so

- libssl.so.0.9.8

- libstdc++.so.6

V.A.4 - SOLARIS and LANDesk 9.5 library requirements

At present, the LANDesk 9.5 (with no SP) install does NOT put down libraries, but does seem to require them.

The reason we provided the libraries in 9.0 (and earlier versions of LANDesk) was that they were usually a royal pain to locate.

UPDATE (June 2013):

This is resolved as of SP1 for 9.5 at the very least - the necessary librarires are put down again and the install proceeds as expected.

V.A.5 - Solaris 10 and supported update versions

Do make sure that you are using Solaris 10 64-bit update 8 or newer. Older version (i.e. - Update 7 for instance) will have problems and - most likely - fail to install at all.

The baseline officially set by LANDesk Management Suite 9 and 9.5 for Solaris 10 is update 8.

V.B - RedHat / CentOS

EXPECTATION FOR THIS PART:

For all the below commands, I assume that your client can resolev the network name (be it 'short' name or FQDN) of your Core. Depending on whether you have DNS set up (you may not), remember that you can add static entries to map network-name(-s) to IP(-s) in "/etc/hosts"!

V.B.1 - Mounting a drive in Red Hat 4

Mapping to a SMB-share in Red Hat 4 uses "smbmount" with the following basis:

smbmount //(CORENAME)/ldlogon /mnt/Core -o username=AUSERNAME,password=THEPASSWORD

 

"Real" example:

smbmount //my90core/ldlogon /mnt/Core -o username=administrator,password=pw

 

You can choose NOT to include the ",password=..." (note the comma) part of the command-line, it's just a matter of convenience if you don't want to type it in separately as you're prompted for it.

 

In Red Hat 4 (and mostly "only" Red Hat 4), this does work, whilst I've had to drop that parameter off for other / newer distributions.

V.B.2 - Mounting a drive in Red Hat 5 / 6

RedHat 5 and 6 no longer have "smbmount", so instead we need to make use of "mount" with the following basis for a command-line:

mount //(CORENAME)/ldlogon /mnt/Core -t cifs -o username=AUSERNAME

 

"Real" example:

mount //my90core/ldlogon /mnt/Core -t cifs -o username=administrator

 

... and then enter te password as you're prompted for it.

V.B.3 - Mounting a drive in CentOS 5 / 6

CentOS also uses "mount", but the command-line used with Red Hat never worked for me here. So we had to adapt and use the "-cifs" flag as a basis for the mounting.

mount //(CORENAME)/ldlogon /mnt/Core -t cifs -o username=AUSERNAME

 

"Real" example:

mount //my90core/ldlogon /mnt/Core -t cifs -o username=administrator

 

... and then enter the password as you're prompted for it.

 

V.B.4 - Remember your firewalls

On RedHat 6 (and I believe, CentOS 6 - by extension), the IPTABLES firewall is installed by default. Make sure to remember to either turn it off completely or add the relevant holes into the firewall so that the LANDesk ports can talk from the Core to the client.

V.C - SLES - SUSE Linux Enterprise Server

V.C.1 - Mounting a drive in SLES 9 / 10 / 11

This is pretty straight forward and consistently works across version 9, 10 and 11 of SLES. Here's the basis for your "mount" command-line:

mount //(CORENAME)/ldlogon /mnt/Core -t cifs -o username=AUSERNAME

 

"Real" example:

mount //my90core/ldlogon /mnt/Core -t cifs -o username=administrator

 

... and then enter the password as you're prompted for it.

V.C.2 - SLES 9 specific install information

There are some required libraries that the LANDesk agent requires for SLES 9, which are NOT part of the default OS install. So you must make sure that you've got access to the SLES 9 SP4 CD's relevant to your distribution (32-bit or 64-bit, respectively).

SLES 9 requires the following libraries (applicable to both 32-bit and 64-bit versions of the OS) which are included in SP4 for SLES 9):

- libstdc++.so.6

- libstdc++.so.6(CXXABI_1.3)

- libstdc++.so.6(GLIBCXX_3.4)

 

REMEMBER:

You will only be able to access service packs / updates to SLES via a support subscription. These files are not freely available on the net.

All the required files are included in a RPM-library on CD # 1 of SP4 for SLES 9 (this is true for both 32-bit and 64-bit versions of the SP 4 CD's).

Here are the instructions for what you need to do for a SLES 9 32-bit system:

SLES 9 32-bit instructions:

1 - Insert SLES 9 32-bit SP4 CD #1

 

2 - go to the directory "/suse/i586" wherever you have SP4 stored. If you have it on a physical media / ISO, this would look like this:

cd /media/dvdram/suse/i586

 

3 - then run:

rpm -i -v compat-libstdc++-lsb-4.0.2_20050901-0.4.i586.rpm

 

to install the C++ compatibility libraries. On a default install, this should go without a problem.

SLES 9 64-bit has slightly altered paths and a slightly different RPM-package name:

SLES 9 64-bit instructions:

1 - Insert SLES 9 64-bit SP4 CD #1

 

2 - go to the directory "/suse/x86_64" wherever you have SP4 for 64-bit SLES 9 stored. If you have it on a physical media / ISO, this would look like this:

cd /media/dvdram/suse/x86_64

 

3 - then run:

rpm -i -v compat-libstdc++-lsb-4.0.2_20050901-0.4.x86_64.rpm

 

to install the C++ compatibility libraries. On a default install, this should go without a problem.

Once those libraries are installed, you can install the LANDesk agent on your SLES 9 box. Again, remember that you install the 32-bit LANDesk binaries on SLES 9 - whether you have a 32-bit or a 64-bit OS.

V.C.3 - SLES 9 hostname/network name information

SLES 9 needs to have its hostname configured after the OS-install, similar to SOLARIS 10.

Otherwise it will just show up as a host called "Linux" in your LANDesk Management Suite console, which isn't overly helpful.

Here's what you need to do.

1 - Edit the "/etc/HOSTNAME" file with your edit of choice. For those not fluent in "vi", and more comfortable with a GUI, "kate" is the default text-editor installed on a "default"-SLES 9 install.

 

So run (remember - this is case sensitive!):

kate /etc/HOSTNAME

 

2 - As you edit the file, enter your desired hostname - such as "SLES-9-32BIT" for instance, save the file. By default, you should see a hostname of "linux.site" when you open the file.

 

IMPORTANT REMINDER -- the file must only have ONE line (just the host name) and a carriage return ("enter") at the end of the first line!

 

3 - Reboot the client (can be done via running "reboot" without arguments).

 

4 - You're done. The change should be applied now.

SLES 10 and 11 prompt you for a hostname during the installation of the OS and retain that one correctly, this is just something to bear in mind with SLES 9.

V.D - Alternative options to get the files you need to install the 64-bit LANDesk agent

V.D.1 - Using WGET instead of mounting a share

"WGET" is a command-line utility that most (if not all?) *-ix distros have. It's a great way to download files from HTTP/HTTPS shares. Since LDLOGON (and its sub-directories) are HTTP-shares, this can be a great life-saver (in particular when it comes to Solaris, as that REALLY makes life difficult when trying to connect it to Windows).

Pro's:

- No need to have libraries installed to make SMBFS shares.

- No authentication problems of any kind, since you're "simply" going over HTTP.

Con's:

- You CANNOT use wildcards over HTTP (so you MUST know the exact certificate filename and agentconfig ".sh" name). This makes it impossible to have a nice "generic" script using WGET if you have to operate with multiple LANDesk Cores.

WGET is easy to use. An example "process" of getting the files this way would be like this:

1 - create a temporary directory and enter it

cd /

mkdir zztemp

cd zztemp

 

2 - download the files needed (in this example, the LANDesk Core is "Solitude" and we're downloading the files for an installation on Linux). The command-line "as is" will download the files into whatever is the current directory.

wget http://solitude/ldlogon/91543e62.0

wget http://solitude/ldlogon/64_bit_Linux.sh

wget http://solitude/ldlogon/unix/linux/baseclient64.tar.gz

wget http://solitude/ldlogon/unix/linux/vulscan64.tar.gz

 

3 - give the install script execution rights

chmod +x 64_bit_Linux.sh

 

4 - Finally, start the install

./64_bit_Linux.sh

 

V.D.2 - Using a browser

You can just browse to "http://CORE_NAME_OR_IP/ldlogon/" and download the "(CERTHASH).0" cert-file from there, as well as the "(AGENTCONFIG).sh" file from there, and then the relevant "baseclient64.tar.gz" and "vulscan64.tar.gz" from the relevant subdirectory of LDLOGON (for instance -- "http://CORE_NAME_OR_IP/ldlogon/unix/linux/").

This of course assumes that you have a GUI of some sort available to you, which isn't necessarily always the case.

The last steps (running the "chmod"-command on the .SH-script file and then executing the .SH-script) are identical, by and large it's a matter of personal preference how you get the files down onto the *-ix box in the first place.

V.D.3 - Keeping the install files on a repository

Pro's:

- Easy to access (may just need a simple mount, no dependency on having SMB-libraries).

- Can be accessed by SCP, FTP or whatever you prefer, depending on how you set it up.

- Scriptable

Con's:

- Must be maintained (agent binaries can be updated on the Core / agent configs may change). Change control is important.

V.D.4 - At the end of the day ...

The only thing that really matters is "getting the files on the box" - which you could theoretically even do by thumb-drive, if you're so inclined. One the files are available locally (again - remember the "chmod +x ..." command on the .SH-script file), the installer just needs to be run with sufficient privileges, and you are good to go.

VI - Which OS platform uses which LANDesk agent exactly (32-bit or 64-bit)?

Since the 64-bit MAP agent was only coded relatively recently, it doesn't support a number of older/"legacy" OS's, as the 32-bit LANDesk agent was expanded to cover those at the time.

To help keep things clearer, the table below as to which Linux platform/distro is supported by which LANDesk agent.

LEGEND:

{SNIP'ing off a lot of older, historical information. The below posts summarise more recent developments of relevance}

UPDATE (As of March 6th 2013):

9.0 SP4 introduces a couple of changes:

- RHEL 4 (32-bit and 64-bit) are no longer supported platforms, because the OS has gone end-of-life.

- SLES 9 (32-bit and 64-bit) are no longer supported platforms, because the OS has gone end-of-life.

- SLES 10 64-bit is now natively supported with the 64-bit MAP agent, no longer needing the 32-bit agent to be installed.

- Support was added for CentOS 6 (32-bit and 64-bit).

- Support was added for RHEL 6 (32-bit).

 

UPDATE (As of March 25th 2013):

Clarified what the situation will be for SLES 10 64-bit for 9.5.

=> 9.5 release -- install 32-bit agent.

=> 9.5 SP1 -- will include a full, native 64-bit agent much like 9.0 SP4 does

VII - Quick overview of the key LANDesk commands in *-ix:

VII.A - An important point on syntax and details.

There are some small but important differences between 32-bit and 64-bit LANDesk agent command-line options. Thus - if in doubt - run the relevant command with the "-h" parameter to get the help-screen on your particular binary and find out how the command-line should be constructed, exactly. They are at this point in time not identical, an important detail to bear in mind.

VII.B - 32-bit LANDesk agent commands

VII.B.1 - Running an inventory scan with maximum verbosity

Generally one will not require to run either inventory or vulnerability scans with maximum verbosity enabled. The most common reason to do this is as part of troubleshooting some sort of problem.

Hence the focus on enabled/maximum verbosity here.

Basic command-line:

ldiscan -f -ntt=CORENAME_OR_IP:Port -V

 

The default port used for the LANDesk inventory service is 5007. This setting is based on what is configured for the Inventory Service on the LANDesk Management Suite Core (Configure Services). Generally, it's rarely deviated from.

 

"Real" command-line:

./ldiscan -f -ntt=192.168.92.150:5007 -V

 

Output to a file:

./ldiscan -f -V -o=MyOutput.txt

 

 

REMEMBER:

The 32-bit binaries are located in:

""

/usr/LANDesk/ldms/

""

VII.B.2 - What are the key parameters for the 32-bit inventory scanner?

You can get a list of all parameters by running

./ldiscan -h

 

REMEMBER:

The 32-bit binaries are located in:

/usr/LANDesk/ldms/

VII.B.3 - Running a vulnerability scan with maximum verbosity

Generally one will not require to run either inventory or vulnerability scans with maximum verbosity enabled. The most comment (effectively - only?) reason to do this is as part of troubleshooting some sort of problem.

Thus the focus on enabled/maximum verbosity here.

./vulscan -c CORENAME -V255

 

Note that "-c CORENAME" is optional and not required. By default, the LANDesk agent will send the vulnerability scan to whatever Core (DNS-name or IP) is configured in the "landesk.conf" file in "/opt/landesk/etc/". That said, it's a good habit to get into while testing in a lab environment, so that you are sure just which Core you're sending the vulnerability scan to, if you have several LANDesk Core Servers in use.

 

REMEMBER:

The 32-bit binaries are located in:

/usr/LANDesk/ldms/

VII.B.4 - What are the key parameters for the 32-bit vulnerability scanner?

You can get a list of all parameters by running

./vulscan -h

 

REMEMBER:

The 32-bit binaries are located in:

/usr/LANDesk/ldms/

VII.C - 64-bit LANDesk agent commands

VII.C.1 - Running an inventory scan with maximum verbosity

Generally one will not require to run either inventory or vulnerability scans with maximum verbosity enabled. The most comment (effectively - only?) reason to do this is as part of troubleshooting some sort of problem.

Thus the focus on enabled/maximum verbosity here.

Basic command-line:

ldiscan -f -ntt=CORENAME_OR_IP -V 255

 

Why is no port needed for the 64-bit inventory scanner?

The 64-bit MAP agent's inventory scanner doesn't talk to the Inventory Service directly, in the way that the 32-bit inventory scanner does. Instead, it's talking to a web-service, thus there's no requirement on specifying a port.

 

Watch your space(-s)

Pay attention to syntax. Note that the 64-bit version of LDISCAN requires a "-V 255" - with a space - for maximum verbosity!

 

"Real" command-line:

./ldiscan -f -ntt=192.168.92.150 -V 255

 

Output to a file:

./ldiscan -f -V 255 -o MyOutput.txt

 

Again - note that for an output in this case, you require a syntax of "-o OUTPUTFILE" (with a space) and not "-o=OUTPUTFILE" (no space, but an '=') as you do with the 32-bit scanner.

 

The 64-bit inventory scanner logs its activites into the "landesk.log" file (under "/opt/landesk/logs/").

 

Also note that the inventory scanner isn't really a single binary/process in the 64-bit MAP agent anymore. Rather it's a series of different executables that are run sequentially and whose output is then collated into an inventory scan. Separate processes exist for collecting software, collecting CPU information, scanning memory, collecting network information and so on.

 

These indivual scanners can be executed one at a time for troubleshooting purposes, if need be, to help you narrow down where a problem arises.

 

REMEMBER:

The 64-bit binaries are located in:

/opt/landesk/bin/

VII.C.2 - What are the key parameters for the 64-bit inventory scanner?

You can get a full list command-line options by running:

./ldiscan -h

 

REMEMBER:

The 64-bit binaries are located in:

/opt/landesk/bin/

VII.C.3 - Running a vulnerability scan with maximum verbosity

Generally one will not require to run either inventory or vulnerability scans with maximum verbosity enabled. The most comment (effectively - only?) reason to do this is as part of troubleshooting some sort of problem.

Thus the focus on enabled/maximum verbosity here.

./vulscan -c CORENAME -V 255

 

Note that "-c CORENAME" is optional and not required.

 

By default, the LANDesk agent will send the vulnerability scan to whatever Core (DNS-name or IP) is configured in the "landesk.conf" file in "/opt/landesk/etc/". That said, it's a good habit to get into while testing in a lab environment, so that you are sure just which Core you're sending the vulnerability scan to, if you have several LANDesk Core Servers in use.

 

REMEMBER:

The 64-bit binaries are located in:

/opt/landesk/bin/

VII.C.4 - What are the key parameters for the 64-bit vulnerability scanner?

You can get a list of all parameters by running

./vulscan -h

 

REMEMBER:

The 64-bit binaries are located in:

/opt/landesk/bin/

 

VII.D - Relevant log files/configuration files and their locations

The locations of certain key log-files vary between the 32-bit and the 64-bit agent architectures. In order to have a single place where one can reference log-file location, the following table has been created:

VIII - Useful *-ix commands and other notes

The following is an introduction into some of the more useful commands available in a variety of *-ix operating systems. To anyone spending any significant time with *-ix, this may appear like me trying to teach someone how to suck eggs - it's not targeted at folk who are comfortable/familiar with *-ix. This is primarily for folks who have little to no real experience with *-ix - and thus serves as a "leg up" to help with a potentially otherwise unfamiliar OS.

VIII.A - SCP (mainly of use for SOLARIS)

As mentioned previously, SOLARIS can be quite difficult and/or uncooperative in regards to connecting to a Windows-share. As a workaround, you can use "SCP" (Secure Copy) to copy files from/to a "more cooperative" *-ix distribution, and move the files from there to the Windows box via a proper mapping.

SCP is very easy to use (assuming you have the relevant credentials). In the examples here, I'll be using "root"-access (which is a "no-no" in the real world, but a matter of convenience in a lab environment).

So ammend your command-lines as required.

The basic syntax for SCP is as follows:

scp (PATH/FILENAME) (REMOTE_USERNAME)@(REMOTE_DEVICENAME):(OPTIONAL_PATH)

 

So, if we were to copy a file called "InvOut.scn" from our current directory to a box called "RHEL4-32" into a directory called/located at "/mytemp", the command line could look like this:

scp InvOut.scn root@RHEL4-32:/mytemp

 

If you aren't in the directory of the files you want to copy/move, you need to specify paths. So for instance:

scp /opt/landesk/OutputFiles/InvOut.scn root@RHEL6-64:/MyOutputCollection/SomeDirectory

 

SCP will prompt you to accept a security-certificate (necessary) as well as for the password of the user that you're utilising to log on to the remote box.

 

NOTE:

If you do not specify a path, i.e. - have a command-line such as:

scp InvOut.scn root@RHEL4-32:

 

then this will copy the file(-s) into the users' home/root-directory

VIII.B - Filtering output with GREP

"grep" is one of the single most useful (and ultimately - powerful) commands in *-ix. It's usually used as part of a "pipe" command-line to filter the output of something else (text-file, command-output) into more useful (and specific) parameters.

The basic use of grep is very simple.

A practical example of using grep to filter down on output can be found just below, as we reduce the output of a process-listing into something we care for.

The most common way of calling "grep" is as part of a pipe-d command-line like so:

{COMMAND / display of a text-file} | grep "STRING_I_AM_LOOKING_FOR"

 

So if we wanted to check if a String "Device Name" exists in the text-file "MyInvOutput.scn", the basic command line with grep would look like so, for example:

cat MyInvOutput.scn | grep "Device Name"

 

Like nearly every other command, GREP has a lot of additional usage options. Use the "man"-pages for more information on just what you can do with GREP.

VIII.C - Getting a list of running processes

Sometimes you need to see what processes are running on a *-ix server. To this end, "ps" will usually serve you well. It comes into its own when combined with grep - making the mass of data actually manageable.

For a "basic" list of all processes that run, just enter:

ps -ef

 

Most of the time, however, you will desire to filter this output with "grep" so as to manage the output better. This is done like so:

ps -ef | grep "(FULL_OR_PARTIAL_STRING_OF_THE_PROCESS_NAME)"

 

So a "real" example would look like this (we're searching for all processes that include "scraper", such as the "map-scraper" process):

ps -ef | grep "scraper"

 

NOTE:

Be aware that you will inevitably find a process of your own grep-search in the list (since your GREP-command line includes the string you're looking for).

 

VIII.D - TAIL / how to track log files

In order to see log-files in real-time, the use of "tail" is useful - it allows you to see in realtime what a specific LANDes-process is doing (assuming you enabled the verbosity options) as it happens.

The basic command for constantly checking a log/text-file (and displaying any updates as they are written to it) is as follows:

tail -f PATH/FILENAME

 

So, if we were to wish to track the "vulscan.log"-file on a 64-bit LANDesk agent, we could do this with the following command:

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

 

Please look at section VII.D - DIRECT LINK - for detailed information on which log-files are located where, and what purpose / information they contain.

VIII.E - Observing directories for changes with WATCH

Sometimes you want to monitor a directory (for instance) for either file deletions or creations (such as when a certain process starts writing to a nwe file). This is easily managed with this command.

By combining the command we wish to use, along with "watch", we can do a lot.

 

So - for instance - let us watch the current directory for any changes in new/deleted files:

watch -d ls-l

 

The first half of the command line is specific to the "watch"-command, whilst the "ls -l" part is what we want the process to be monitoring.

VIII.F - Shutting your OS down

VIII.F.1 - Shutting down most *-ix OS's:

Just run this command:

shutdown -h now

 

The command-line parameters break down as follows:

-h => HALT the system (as opposed to reboot).

now => Do it now, with 0 seconds delay/warning. If you want to give warning (on a live server), check "man shutdown" for what parameter(s) you should use.

 

This will work on pretty much every version of Red Hat, CentOS and SLES that LANDesk supports.

VIII.F.2 - Shutting down Solaris

Solaris requires a different command-line. Here's what you need:

shutdown -y -i 5 -g 10

 

The command-line parameters break down as follows:

-y == Confirm the prompt of the "are you sure"-type with "yes" automatically.

-i 5 => Go to Init State 5 (i.e. - power off).

-g 10 => give 10 seconds grace/warning

VIII.G - Your *-ix and DNS / the HOSTS-file

Depending on your DNS configuration, you may or may not have hostnames resolved on your *-ix OS's.

One easy way to circumvent this (again, purely for a lab-environment - this is not a solution for a live environment) is to add entries into the HOSTS-file on your *-ix OS.

This is exactly the same concept as the "HOSTS"-file that resides in Windows under "C:\Windows\System32\Drivers\Etc".

In *-ix, this file is:

/etc/hosts

This is true for all version of Linux-flavours, as well as Solaris that LANDesk supports. You just need to edit that file, and you have your DNS-entry for your Core server and/or other *-ix devices you may want to communicate with, rather than having to use IP's all over the place.

VIII.H - Editors in your *-ix OS:

Different *-ix distributions tend to have different editors available in their installs. Generally one of the following three will be available (besides "vi", which can appear a bit intimidating towards a more casual *-ix user).

- "gedit" (for RedHat and CentOS distros)

- "emacs" (for Solaris especially)

- "kate" (for SLES 9, as it doesn't have GEDIT or EMACS by default)

VIII.I - *-ix, carriage returns and potential Windows issues

This is really more a Windows problem, but for the sake of completeness I'll mention it here.

Windows OS's can have a sometimes odd effect on non-Windows created text-files. The details vary greatly from version to version (i.e. Windows 2003 versus Windows Server 2008 R2), but the key point here is that you *CAN* run into problems.

Sometimes, when a file refuses to be processed, it could be because Windows is unable to deal with its encoding - the resulting effects of which can vary from "mild" (files do processe, but just display "odd" in NOTEPAD) to annoying (files do not process and/or cause other problems).

In such cases, it might be worth giving a "unix2dos" type command a try. This command (and it's relevant OS-specific siblings) go through text-files and reformat them in a more Windows-friendly way (replacing Linux-specific carriage returns with carriage returns that Windows can interpret better) for instance. This tends to minimise any potential impact of such issues.

Here are some relatively easy-to-get-ahold-of tools for this task (included on the OS CD's usually):

- For most Linux flavours and Solaris, use "unix2dos" in general.

- For HP-UX, use "ux2dos" in general.

Depending on the exact distribution and release version used, this may or may not be installed by default.

NOTE:

Since the problem relates to "non-Windows" files, YES, this *MAY* arise as an issue for MAC-devices as well. Be aware.

VIII.J - How to find your key binaries with WHICH

WHICH goes through all configured PATH-s, and returns the first hit for the file you're looking for. Primarily this is useful for finding an executable you're trying to locate.

So, for example, running:

which unix2dos

 

will return:

/usr/bin/unix2dos

 

on Solaris 10 (as well as a default install of RHEL 5, as it happens).

 

NOTE:

Be aware that WHICH only returns the first "hit" it finds. If you have multiple binaries, it will only return the one (whichever it runs into first). Generally, WHICH searches PATH-ed directories in the order in which they're listed.

It's a very nifty (and quick) way of locating certain binaries, without having to use "find" (paired with "grep").

IX - Final notes and words of advice

IX.A - Recursive vulnerability scans

One of the most easily overlooked differences between the *-ix platforms and "Windows-world" is related to Patch Manager. Specifically, there are various vulnerabilities for a variety of *-ix platforms which REQUIRE a FULL, RECURSIVE HDD-scan.

This can not only have a massive impact, but can also cause your vulnerability scans to take a VERY long time (15+ minutes is not unusual), depending on how much file/directory-structure there is to be scanned/checked.

LANDesk makes these vulnerabilities stand out in patch content, by having the keyword "Recursive" be included in the ID of the relevant vulnerability (thus, it's very easily searched for). If you are "just playing around" or just testing this or that, feel free to single out these vulnerabilities and put them into the "DO NOT SCAN"-section.

An example of such a scan is the "Security Threat"-type vulnerability "REDHAT-Files-008_Recursive_Scan". That "_Recursive_Scan" addition to the identifier of the vulnerability is meant to help identify this vulnerability as being one of potentially VERY high impact on a client.

WARNING:

These vulnerabilities should be used/enabled only will full awareness of just what impact they can have. Their potential impact on a server is not to be taken lightly.

At the time of the writing of this article (November 2012), there are 15 such vulnerabilities that perform recursive scans - 3 for HPUX, 4 for REDHAT, 8 for SLES.

IX.B - It is what it is - just a survival guide

The install methods described above are not meant to be the primary way in which LANDesk is deployed across your estate. It's a "quick & dirty" set of instructions on how to get clients installed, so you can actually do something with them. There are documents and BKM's on HTTP://COMMUNITY.LANDESK.COM which advise on proper deployment across an estate.

At no point do I make the claim that this is the prettiest or best way to get things done - I'm more than open to suggestions and improvements. All that I claim with this article is to provide information how to get the LANDesk agentry going on the various *-ix platforms.

That's it.

Overview: This document provides a quick overview of troubleshooting vulscan on the Linux platform. The following platforms are supported for vulnerabilities and repair however only the 32-bit LANDesk agent can repair vulnerabilities at this time.

SLES 9, 10, 10SP1, and 10SP2

RHEL 3, 4, and 5

It is important to note that there are a few vulnerabilities that involve every file on the Linux system. These vulnerabilities may take a very long time to scan for on a busy production server as they need to scan every single file. In some reports the scan process can take longer than a day to complete.

Note: Please see DOC-8273 for detailed information on how to setup vulnerability scanning on the Linux platform. This document will also provide instructions on registering each machine with Red Hat or Suse in order to download the actual patches themselves and make a repair task possible.

Log Location: /var/log/vulscan.log (older 8.8 and prior agents) /opt/landesk/logs/vulscan.log (9.0 and 9.5 agents)

Vulscan Options:

./vulscan -?

Usage: vulscan [options]

               -c <core>               use <core> as the core server

               -s <share>             use <share> as the data share name on the core

               -p <platform>         use  <platform> as the platform id

               -r <repairfile>          use <repairfile> as the repair definition file. Implies repair mode and "-n".

               -i <inventoryfile>     use <inventoryfile> for guid information

               -d <inputfile>          use <inputfile> as the vulnerability definition to scan instead of talking to the core. Implies scan mode and "-n".

               -n                          do not try to talk to the core.

               -S                         do not scan after fixing. (used in conjunction with -x)

               -f <cfgfile>              use <cfgfile> for configuration information

               -o <outputfile>         write results to <outputfile> instead of sending results to core

               -l <language>          use <language> as the request language

               -V##                       verbose output <-V2 is more verbose than -V1)

               -v                            show version and exit

               -x <vulid>                patch vulnerability id specified in <vulid>. This can be set to 'all', vulscan will query the core server for all available updates.

               -h or -?                    show this message and exit

Note: the -r and -d flags are mutually exclusive. The program can only be run in scan mode, or repair mode.

Troubleshooting:

Vulscan will periodically attempt to POST the scan results to the core server when it finishes processing a section. Using the "-o" paramter may help in troubleshooting problems with vulscan appearing to exit prematurely or halt in memory. Also the "-V##" switch can go up to 255 which will result in the most verbose logging.

Dear All,

I just started working with Patch Manager on Linux. I notice that for LDPM 9.x version, it can integrate with Linux Vendor Tools to patch 32 bit linux. For LDPM 2016, patch manager no longer work with 32 bit linux. Would you please help with the questions below?

1. If I have both 32 bit and 64 bit linux and have patch manager 2016. Can I work with the 32 bit clients using the 9.x agent connecting to the patch manager 2016 server?

2. Can 2016 linux client agent (64 bit) integrate with Linux vendor tools (e.g. Redhat Satellite) to provide automatic patching and dependency checking function?

3. Is there any getting start document on working with Linux 64 bit system with LDPM 2016? Not sure if this, How to leverage Linux vendor tools to remediate vulnerabilities  still work with LDPM 2016? Looks like LDPM 2016 need manual download of Linux patch again?

Thanks!

Environment:

Applies to LDMS 2016 x64 based agents.

Gathering Linux/Unix Logs

Requires Access To:

SSH to the agent you are troubleshooting.

What are we troubleshooting?

This can be used for troubleshooting many different tasks the agent performs.

Step by Step:

First you need to SSH into the Agent.  Once in the agent you will be modifying the text file /opt/landesk/etc/landesk.conf file.  It is always recommended to take a backup of this file prior to making changes.

If you add the following line to the bottom of the landesk.conf file: verbosity=255

Then when you run any single executable it will be picked up and verbosity will be added, however if that executable spawns another executable you will want to use the below line instead.

If you add the following line to the bottom of the landesk.conf: Overrideverbosity=255

Once you add this line even if an executable runs another the verbose will follow each process. 

Example:

If you are working with map-fetchpolicy, if the line verbosity=255 is in the landesk.conf file then map-fetchpolicy will run with -V 255 added to it's parameters. 

If you have the line Override verbosity=255 line added, then when map-fetchpolicy creates a vulscan job or sdclient job verbose will also be added.

You may also add the below lines to output the verbose information to a file directly.  Please note this may not catch all sub processes.

logfile=/path/to/file

outputfile=/path/to/file

Equal to running a -l or -o to any given process

Override logfile=/path/to/file

Override config=/path/to/file

Adding these lines will add the -l and -c option to the various tasks

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

On 2016.3 we had our Linux clients showing up under "Devices with Older Agents" . After upgrading to 2016.3 SU3 we installed the new agents and the devices still show up under "Devices with Older Agents". Are Linux agents out of date compared to the Mac and Windows Agents? Once we upgraded to 2016.3 SU3 and installed the new agents on our Mac clients they moved away from  "Devices with Older Agents". Thanks for any insight you may provide.

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.

!! Note: Agentless inventory only works with the 32bit version of the linux agent. It is currently not possible to use agentless inventory with the 64bit version of the agent. !!

Issue: Due to certain circumstances it may be required to perform an agentless inventory scan of a Linux machine. This process is not supported but should be possible with the following routine.

1- Install a full LANDesk agent on a test machine.

2- Copy the /usr/LANDesk folder to a network share. (Example: //share01/test)

3- Copy the /etc/ldappl.conf file to the same network share.

4- On a separate agentless Linux machine create a directory and mount the network share.

     Example: mkdir /mnt/share01

                     mount -t cifs -o username=something,password=something //share01 /mnt/share01

5- Execute the following command substituting correct shares and values etc:

     Example: /mnt/share01/test/LANDesk/ldms/ldiscan -ntt=CoreNameOrIP -i=/test/ldappl.conf

     Note: The -ntt switch is for the core server, the -i switch is to specify the location of the ldappl.conf file

Other notes and issues:

- The inventory scanner will automatically create a /etc/ldiscnux.conf file. This file contains the unique Device ID and some basic information. It's recommended to keep this file in place as it will uniquely identify the device with the core, otherwise new scans will continually be received each time this process is run.

- On some Linux flavors the stdlibc++.so.5 may need to be installed as the inventory scanner needs this package.

- This procedure was run on a SUSE 10 machine so other flavors may produce different results.

- A LANDesk 9 linux inventory scanner will not work correctly with a LANDesk 8.8 core. The LANDesk 9 scanner will work fine with a LANDesk 9 core.

Note: For detailed Linux command instructions please see the MAN files or the open internet depending on the flavor of linux in use.

Description

During the install of an AIX or UNIX agent, several errors may occur. The most common would be a dependency to a certain library.

Troubleshooting

General Tips

1,As the error is libstdc++.a could not be loaded, we need verify if we can find the file from the machine.

2, You can also run ldd to find all the dependencies needed from a working agent.

3,If you can find the dependency, you need to add a directory that contains the missing libraries to our library path

(HPUX: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/freeware/lib64/)

4, If the file is 32-bit, you need add lib32 that contain the missing libraries.

32-bit

64-bit

Environment:

LANDesk Management Suite 9.5 9.6

Description

The Linux agent may need to be installed manually if using a platform for which Agent deployment support does not yet exist. Manual installation is also necessary if SSH is not installed on the Linux Device.

Resolution

To manually install the Linux agent, follow the steps for the specified platform below.

Manual Install on All Supported Linux Platfroms for 8.8 and Later

1. From the Linux workstation, map a drive to the Core Server's ldlogon share.
   

   mount -t cifs -o username=User1,password=P@sswd! workgroup=Domain.tld //CoreServer/ldlogon /mnt

2. Change to the mounted directory and run linuxpull.sh with the parameter of the Agent Configuration's .ini file.
   

   cd /mnt

   ./linuxpull.sh "Default Linux Server Configuration.ini"

The linux agent will now install automatically using the settings from the chosen agent configuration.

Manual Install on All Supported Linux Platfroms for 8.7 and Earlier

Red Hat Enterprise Server 3 or 4 and SUSE 9 or 10

1. Verify that the required RPMs are installed.
   
2. Create a directory in the /tmp folder:

   mkdir /tmp/landesk

3. Change to that directory.

   cd /tmp/landesk

4. Copy or download the following files to this directory:
   
     Using a mounted share:

   mkdir /mnt1
     mount -t smbfs -o username=SomeUser,password=p@sswd!,workgroup=Domain //CoreServer/ldlogon /mnt1
     cp /mnt1/ldlogon/*.0 /tmp/landesk/
     cp /mnt1/ldlogon/Default\ Linux\ Configuration.sh /tmp/landesk/
     cp /mnt1/ldlogon/Default\ Linux\ Configuration.ini /tmp/landesk/
     cp /mnt1/ldlogon/unix/linux/* /tmp/landesk/

   Using HTTP:
   

   • http://CoreServer/ldlogon/066e6c79.0 (On each Core Server this file is unique. Replace the 066e6c79 to match the .0 file in ldlogon.)
   • http://CoreServer/ldlogon/Default Linux Agent.sh (Substitute the actual configuration name here.)
   • http://CoreServer/ldlogon/Default Linux Agent.ini (Substitute the actual configuration name here.)
   • http://CoreServer/ldlogon/unix/linux/* (All the files from this directory. Usually they must be downloaded one at a time.)

5. If the machine is an IPMI/BMC machine (with Monitoring included in the installation), type the following on a command line:

   export BMCPW="(bmc password)"

6. Running as root, execute the shell script for the configuration. For example, to deploy the  Default Linux Configuration use the full path used in step 2:

   /tmp/landesk/Default\ Linux\ Configuration.sh

7. A link to /usr/LANDesk/common/ldiscan.sh is created in /etc/cron.daily, however cron tasks can be setup as desired.

Debian / Ubuntu (Tested with Kubuntu 7.0.4)

1. Install the following Debian Packages with apt-get.
   

   sudo apt-get install xinetd
     sudo apt-get smbfs
   

   Note: Not required for the LANDesk Agent but used for share access. sudo apt-get install openssh-server
   
      Note: openssh-server is required only for a push of the LANDesk agent, which isn't yet working from my testing.
   
2. Mount a drive to the Core Server's LDLOGON share.

   sudo mount -t smbfs -o username=SomeUser,password=p@sswd!,workgroup=Domain //CoreServer/ldlogon /mnt

3. Make a temporary directory.

   mkdir /tmp/ldms

4. Copy the [hash].0 file from ldlogon to the temp directory.

   cp /mnt/*.0 /tmp/ldms/

5. Copy the baseclient.tar.gz file to the temp directory.

   cp /mnt/unix/linux/baseclient.tar.gz /tmp/ldms/

6. Untar and decompress the baseclient.tar.gz file.

   cd /tmp/ldms tar -xzf baseclient.tar.gz

7. Install the LANDesk Agent Debian packages.

   sudo dpkg -i pds2*.deb cba8*.deb ldiscan*.deb

8. Copy the .0 file to the /usr/LANDesk/common/cbaroot/certs directory.

   sudo cp /tmp/ldms/*.0 /usr/LANDesk/common/cbaroot/certs/

9. The LANDesk Agent for Debian is now installed.
   
10. Run an inventory scan.

    sudo /usr/LANDesk/ldms/ldiscan -ntt=CoreServer -f

    Note: SMBIOS data is currently not gathered as the LANDesk packages required to gather this data is not yet ported to Debian.
    
11. Add a cron job to run the inventory scanner daily or as desired.

Unsupported Platforms with RPM capability

1. Verify that the platform supports RPMs and that all required RPMs are installed.
   
2. Create a directory in the /tmp folder:

   mkdir /tmp/landesk

3. Change to that directory.

   cd /tmp/landesk

4. Copy or download the following files to this directory:
   
     Using a mounted share:

   mkdir /mnt1
     mount -t smbfs -o username=SomeUser,password=p@sswd!,workgroup=Domain //CoreServer/ldlogon /mnt1
     cp /mnt1/ldlogon/*.0 /tmp/landesk/
     cp /mnt1/ldlogon/Default\ Linux\ Configuration.sh /tmp/landesk/
     cp /mnt1/ldlogon/Default\ Linux\ Configuration.ini /tmp/landesk/
     cp /mnt1/ldlogon/unix/linux/* /tmp/landesk/

   Using HTTP:
   

   • http://CoreServer/ldlogon/066e6c79.0 (On each Core Server this file is unique. Replace the 066e6c79 to match the .0 file in ldlogon.)
   • http://CoreServer/ldlogon/Default Linux Agent.sh (Substitute the actual configuration name here.)
   • http://CoreServer/ldlogon/Default Linux Agent.ini (Substitute the actual configuration name here.)
   • http://CoreServer/ldlogon/unix/linux/* (All the files from this directory. Usually they must be downloaded one at a time.)

5. If the machine is an IPMI/BMC machine (with Monitoring included in the installation), type the following on a command line:

   export BMCPW="(bmc password)"

6. Extract all the tar.gz files.

   tar -xzf [eachfile].tar.gz

7. Install the RPMs manually. Start out in this order: pds, cba, sdclient, vulscan.
   
8. Copy the .0 file to the /usr/LANDesk/common/cbaroot/certs directory.

   sudo cp /tmp/ldms/*.0 /usr/LANDesk/common/cbaroot/certs/

9. Install smbase and ldsmbios in order to be able to scan for BIOS data such as the serial number or asset tag.

Unsupported Platforms without RPM capability - Inventory Only With BIOS Data

1. Create a directory in the /tmp folder:

   mkdir /tmp/landesk

2. Change to that directory.

   cd /tmp/landesk

3. Copy or download the following files to this directory:
   
     baseclient.tar.gz
     monitoring.tar.gz
   
     Using a mounted share:

   mkdir /mnt1
     mount -t smbfs -o username=SomeUser,password=p@sswd!,workgroup=Domain //CoreServer/ldlogon /mnt1
     cp /mnt1/ldlogon/unix/linux/baseclient.tar.gz /tmp/landesk/
     cp /mnt1/ldlogon/unix/linux/monitoring.tar.gz /tmp/landesk/

   Using HTTP:

   http://CoreServer/ldlogon/unix/linux/baseclient.tar.gz  
      http://CoreServer/ldlogon/unix/linux/monitoring.tar.gz

4. Extract both the tar.gz files.

   tar -xzf *.tar.gz

5. Extract the ldiscan-8.versionid.i386.rpm and find the  ldiscan file.
   
6. Extract the smbase rpm and find the  lsmbios file.
   
7. Create the following directories:

   mkdir /usr/LANDesk/ldms mkdir /usr/LANDesk/smbase

8. Place  ldiscan in the /usr/LANDesk/ldms directory.
   
9. Place  lsmbios in the /usr/LANDesk/smbase directory.
   
10. Add a cron job to run the inventory scanner daily or as desired.

Unsupported Platforms without RPM capability - Inventory Only

1. Create the following directory: /usr/LANDesk/ldms folder:

   mkdir /usr/LANDesk/ldms

2. Change to that directory.

   cd /usr/LANDesk/ldms

3. Download the linux scanner using a command line web utility such as wget or lynx.

     http://CoreServer/ldlogon/unix/linux/ldiscnux

4. Run an inventory scan.

   sudo /usr/LANDesk/ldms/ldiscnux -ntt=CoreServer -f

   Note: SMBIOS data is currently not gathered as the LANDesk packages required to gather this data can only be installed with RPMs.
   
5. Add a cron job to run the inventory scanner daily or as desired.