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:
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.
Strip domain suffix : Checking this will strip domain suffix from discovered servers.
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.
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:
|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: