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:
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:
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:
- Hostname as discovered – if domain is present and domain is not in the name it is set to “name”
- Hostname Plus Domain Name and Add Host name as Alias – alias is set to “name” and the device name becomes “name.domain”
- Hostname Plus Domain Name the device name becomes “name.domain”
- 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.
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 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:
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
CPU Info: from /usr/sbin/dmidecode
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:
|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|
|zlogin||Always||Solaris (For Zones)|
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:
You could alternatively make the defaults particular to just the discovery account like so: