Install Tips - netdisco/netdisco GitHub Wiki

As of version 2.077011, Python is required and will be installed if missing.

If you access the internet through an enterprise proxy, the download of uv may fail due to a mismatch in TLS Certificate Authority. This can be rectified by passing SSL_CERT_FILE and REQUESTS_CA_BUNDLE, for example (with SLES):

If all else fails, you can downgrade to a version without Python:

The Netdisco applications will generate RC scripts suitable for Linux systems:

On systemd-based systems please see the systemd guide.

On BSD systems please see our FreeBSD tips, as well as our OpenBSD tips, and submit patches against the Daemon::Control distribution.

See the ticket https://github.com/netdisco/netdisco/issues/692

See this page: https://github.com/StewAlexanderACC/NetDisco-Ubuntu-Install

Some installations of PostgreSQL don’t have MD5 authentication enabled by default, which blocks database connections with the default Netdisco configuration.

If your database and Netdisco are on the same system, then the easiest solution is to comment out the “host:” line in your deployment.yml file.

Alternatively, reconfigure PostgreSQL to permit MD5 auth for TCP connections by adding the following to your system’s “pg_hba.conf” file (and restarting the database service):

A common scenario is that the network is split into security domains (or zones) and one Netdisco poller daemon cannot see all devices.

You can run multiple pollers, as long as they all connect back to the same PostgreSQL database. Use the devices_only or devices_no configuration settings to control which devices are "seen" by each poller. You can also include only the necessary minimum SNMP community/authentication settings in each poller’s configuration.

Of course you will also need to start the web server somewhere, as well.

The Netdisco in the zone must be able to talk to the main database. This might involve configuring your firewall to allow Postgres traffic on TCP 5432, as well as modifying postgresql.conf and pg_hba.conf to allow remote connections.

The standard port for PostgreSQL is 5432. To connect on a different port you need to use the host option under database: config in your ~/environments/deployment.yml file. For example if connecting to a database on the local server:

Obviously, substitute the user, pass, and actual port number for your local values. Note the separator character is a semicolon.

The netdisco-deploy script asks for Internet access but it is possible to install off-line. You should download the following two files:

• https://raw.githubusercontent.com/netdisco/upstream-sources/master/ieee/oui.txt

• https://github.com/netdisco/netdisco-mibs/releases/latest (download link is on the page)

Run the netdisco-deploy script but pass the OUI file name as a parameter on the command line, for example:

Then answer yes to questions, even though you’re not connected to the Internet.

For the MIBs you can simply extract the downloaded archive to the home directory of Netdisco, and change the name of the directory to netdisco-mibs.

The installation process installs Netdisco self-contained to your home directory. The target directory can easily be changed by setting the NETDISCO_HOME environment variable, for example:

Obviously, you’ll need to substitute this wherever you see “~” in the installation instructions. The Netdisco application will use this setting itself to locate files and configuration.

Simply add any options after the “start” command. See other sections of this document for some examples.

Netdisco will assume its web site is hosted at the apex of your server - that is, the document root. To relocate the web application, pass the --path parameter to the web startup script:

Alternatively, can set the path configuration option in your deployment.yml file:

Pass the --port parameter to any of the web scripts. For example:

Alternatively, the PORT environment variable can be used (only with netdisco-web).

Pass the --host parameter to any of the web scripts. For example:

Set the IPV environment variable, can be 4, 6 or *. For example:

By default the web application daemon starts listening on port 5000 and goes into the background. This is ideal for hosting behind a web proxy (e.g. Apache with mod_proxy).

After enabling the headers, proxy and proxy_http modules in Apache, a suitable configuration would be:

To combine this with Non-root Hosting as above, simply change the paths referenced in the configuration, and set path in your deployment.yml as discussed above. Note there is no trailing slash in the Apache config:

To delegate user authentication to Apache, use the trust_remote_user or trust_x_remote_user settings. See the configuration documentation for more details.

The web front-end can also run as a PSGI application. In this example, we’ll run it inside Apache with mod_perl. This is useful if you need to maintain a legacy 1.x front-end as the two can co-exist in the same Apache server.

To deploy, add Apache’s user to the netdisco group so it can read netdisco’s files then adapt this example into your Apache configuration:

There is no SSL support in the built-in web server. This is because it’s not straightforward to support all the SSL options, and using port 443 requires root privilege, which the Netdisco application should not have.

You are instead recommended to run netdisco-web behind a reverse proxy as described elsewhere in this document. Apache can easily act as an SSL reverse proxy.

Add the following to your configuration:

Other ways to run and host the web application can be found in the Dancer::Deployment page. See also the plackup and starman documentation.