Linux & Unix Server Auto-Discovery

Device42 supports SSH-based linux and unix discovery from within the main appliance (v13.2+). For a full list of supported *nix operating systems please visit Device42 Supported Operating Systems

Setting up Linux/Unix auto-discovery

Prior to configuring an ssh-based discovery job please be sure you have your SSH port (standard TCP port 22, or custom port) open between your Device42 Main Appliance or Remote Collector and the targetted unix/linux servers.

From “Discovery → Hypervisors/nix/win”*, you can add a *nix discovery job to connect and gather host and VM details:

Setting up *nix based auto-discovery

On the “Add Hypervisors/*nix/win for Autodiscovery” page, choose *nix as the platform. Other options are as follows:

URL Prefix: This will be https in most cases. But, if you have changed it, you have the option to switch it to http.
Server : This is the FQDN or IP of the vCenter server or the ESX server. If using FQDN, device42 should be setup for DNS resolution(vm console, option 1)
End IP Address : Optional, if doing discovery on a range of servers rather than a single server.
Port : This will be 22 by default. Only change if you have a different ssh port configured.

Username & password: self explanatory. Use username with permission to connect to the linux/unix targets with SSH.

WARNING: Please do not set up an auto-discovery / scan using critical production account credentials!

Depending on permissions granted & your configured password policies, account lock-out could result in an otherwise completely avoidable outage. You, the customer, are responsible for any such behavior that might result if you choose to ignore this requirement.

Strip domain suffix : Checking this will strip domain suffix from discovered servers [see the next section for hostname config details].
Give Precedence to Hostname : Check this option to give precedence to the discovered hostname.
Debug Level : Debug On for extra debug info, useful for a support ticket.

There are a few other options that are geared toward hypervisor discovery and can be ignored for WinRM discovery.
Last status : Last run task status.
Run report: This will record what has changed in the last task.

Schedule for auto-discovery: You can schedule the discovery to run at certain times.

Configuring Linux Hostname Discovery Details

When discovering a device name, the first command we check is “hostname”. This is used to derive the shortname of the host.

After running hostname, we’ll run the following commands to obtain the domain name. They’re ordered by which command’s results we give the most weight to:

  • domainname
  • dnsdomainname
  • ypdomainname
  • nisdomainname

If we don’t get a domain name with any of those commands we’ll try “cat /etc/resolv.conf” last. In this case we’ll split on the white space in the file and look for a “domain” token. When we see one, we’ll assign domain as the 2nd token after “domain”.

Strip Domain Suffix Option:

When selected, Device42 will drop everything after the first “.” in the device name.

For naming options, the above mentioned Strip Domain Suffix option occurs prior to assigning the device name according to the naming option you choose. The naming options are as follows:

  1. Hostname as discovered – if domain is present and domain is not in the name it is set to “name”
  2. Hostname Plus Domain Name and Add Host name as Alias – alias is set to “name” and the device name becomes “name.domain”
  3. Hostname Plus Domain Name the device name becomes “name.domain”
  4. HostnameAddHostnamePlusDomainNameAlias names stays the same and a alias is set as “name.domain”

Run *Nix SSH discovery

Upon save(if you haven’t scheduled the discovery), you can run it from list, view or edit page using “Run now” button or link.

Scheduling

Scheduling

You can schedule the auto-discovery to run on a recurring basis. Specifically, you can choose to have it run on certain days of the week and at a specific time each day.

Linux Considerations

Linux Auto-discovery has been tested against Redhat, Debian, CentOS, Ubuntu, and Oracle distributions and should work fine against just about all similar linux distributions that have python installed.

Confirm this by checking to see if your platform supports the following commands:

Hostname: /bin/hostname
OS: /usr/bin/python -m platform
Manufacturer, Hardware and Serial # : sudo /usr/sbin/dmidecode -s system-manufacturer (and system-product-name, system-serial-number)
IP Info: /sbin/ifconfig -a
Memory: /proc/meminfo
CPU Info: from /usr/sbin/dmidecode

Linux Permissions

There are several commands that are run as part of the Linux autodiscovery process that, by default, typically require root privileges. We do extensive testing to see which commands we can run without sudo while still obtaining all available information. The following is a table of commands we sometimes or always run as sudo. For the “Sometimes” commands, we’ll try to run the command first without, and if we receive a permission denied command rather than an “invalid command”, “command not found” or similar we’ll attempt to run as sudo. This list will also say if it’s ran on every linux/unix flavor or only certain platforms:

Command Sudo OS Flavor
cat Sometimes All
fdisk Always All
grep Sometimes All
ls Sometimes All
cd Sometimes All
netstat Sometimes All
ss Sometimes All
crontab Always All
exportfs Sometimes All
hdparm Sometimes All
pwdx Sometimes All
hadoop Sometimes All
hdfs Sometimes All
SYBASE__DOT__sh Sometimes All
dataserver Sometimes All
su $oracle_user Sometimes Discovers Oracle application information by running necessary commands as the Oracle user
su $sap_hana_user Sometimes Discovers SAP HANA application information by running necessary commands as the SAP user
dmidecode Sometimes Linux:Freebsd:OpenBSD:Mac
dmesg Sometimes Linux:Debian:OracleLinux:HPUX
format Always Solaris
pfiles Always Solaris
zlogin Always Solaris (For Zones)
system_profiler Sometimes Mac
ioscan Sometimes HPUX
print_manifest Sometimes HPUX
swlist Sometimes HPUX
lslpp Sometimes Aix

Below you can see an example of how to allow a particular user or group to run a specific sudo command without being prompted for password:

**%your-group-here ALL = (ALL) NOPASSWD:/usr/sbin/dmidecode, /sbin/hdparm, /sbin/fdisk**

Adjust the above paths as needed to match the location of each program. If these permissions are missing, the auto-discovery client will not be able to discover hardware, manufacturer, serial #, and so on, as well as service dependencies and valuable application configuration information.

You might also have to comment out Default Requiretty in /etc/sudoers file.

SUDO PATH in non-interactive shells

If users are experiencing linux discoveries where Device42 is using a non-interactive shell rather than interactive, we may be trying the commands multiple times because PATH is not set in non-interactive shells. The users can set that information in their sudoers file for the service account to prevent these commands from being executed multiple times. It should be there by default, but sometimes it’s commented out or removed for security hardening.

It’s not a bug, but some deployments may see security alerts for invalid commands being executed because of this.

In sudoers, there should be a line as follows:

Defaults secure_path=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin”

You could alternatively make the defaults particular to just the discovery account like so:

Defaults:DISCOVERY_ACCOUNT
secure_path=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin”