TarleyNode 0.3.7

Added

• The TarleyNode server monitors itself: it sets up its own snmpd (SNMP v3, read-only, on its own address only) and adds itself as the device TarleyNode server, so the Linux server (SNMP) template watches its CPU, memory, disks and uptime. An snmpd you configured yourself is left alone. Turn it off in Settings › Server › Monitor this server, or install with --no-self-monitor. The servers' own devices (each server's address and a cluster's shared address) and their checks no longer count towards the licence; the licence card shows how many are free. When none of your sites' ranges include the server's own address, it is added as a single address to the site the server monitors from, at once, and the audit trail says why. In a cluster every server sets up its own snmpd, and turning self-monitoring off cleans up on every server.
• An IP register, under Manage, for the address ranges your business owns, usually public ones: add IPv4 and IPv6 ranges by hand or from a CSV file (cidr, name, notes, access_group), and see how many addresses in each are used, reserved and free. A device whose monitored address is in a range shows there by itself; administrators can assign other addresses to a device, such as a firewall's public addresses, reserve them with a note or free them. A device's page lists its addresses in the register, and a range given an access group shows to that group's members.
• Servers with two network cards. Where a site's ranges or a scan's range are entered, and on a site's address list, TarleyNode shows the card, source address and gateway the server uses for each range scanned from the server, and warns when a private range would leave through a public card's default route (its scans time out). Settings › Server › Network lists the server's cards and routes; administrators add routes there, such as 10.0.10.0/23 via an internal router, which the server applies within a minute with `ip route add ... proto 191` (its own route type, so a matching route netplan or networkd adds is never removed with it) and keeps across restarts and updates. It removes only routes it added, leaves a range the server already routes alone, and refuses a route that could cut off the console (one covering the server's own addresses, its default gateway, the console's address, the browser's address or a cluster server). In a cluster the routes apply on every server. The same section chooses the address devices send syslog, traps and flows to and whether the receivers listen on all addresses or one, and points out when that address is public while an internal one exists. Viewers and operators see it read-only; changes are in the audit trail.
• The warning that a private range would leave through the public card now has an Add route button for administrators, in the site range forms, the Discovery scan form and a site's address list. It opens the Settings › Server › Network form with the range filled in, and the card when the server has only one private card; the gateway is suggested only when another route already uses a router on that card. The line shows Waiting for the server to apply it until the server reports the route, within a minute.
• New installs on a server whose default route is on a public card advertise the internal card's address to devices (asking when there are several). Upgrades keep the address they have.
• Scans use the site's SNMP login (Discovery › Logins), as PRTG does: every address is also asked for its SNMP system name and description, so a server that blocks ping and SSH and opens only 80 and 443 is found, and its type, maker and operating system (Linux, Windows, ESXi; switches, firewalls, printers, UPSs and the like) come from its answer. A found device that answered SNMP is added with the SNMP login whatever its type, servers too, beside the SSH or Windows login where it fits, so the Linux server (SNMP) template and its CPU, memory and disks follow by themselves; one added by itself after a scan gets the SNMP login only. SSH and Windows logins are still never tried before a device is added. Connected sites need this version to read SNMP during scans.
• A device already monitored whose operating system is not set takes the one its SNMP system check names the first time it answers, and its type when it was only Device, so its templates apply; the audit trail shows TarleyNode (automatic). A system someone set or cleared is left alone.

Fixed

• Automatic discovery no longer adds a Port check for every Docker interface (veth…, br-…, docker0) on a server, nor for loopback or tunnel interfaces (virbr, tun, wg, tailscale): Docker renames them on every container restart, so stale checks piled up (about 25 on one server). Those it added before are removed on upgrade; port checks someone added by hand stay.
• The TarleyNode server's own device has its certificate checked on TarleyNode's own HTTPS port (HTTPS_PORT, such as 8443) with its host name (MONITOR_HOST), instead of on 443 by address, which fails when 443 is a proxy in front of the server that needs the name. Without them it gets no certificate check.
• Scans recognise every address of the TarleyNode server itself (each of its network cards, and every server of a cluster) as This TarleyNode server, so it is no longer offered or added as a new device, such as its public card typed as a switch; the site's address list names it so. Devices already added are left as they are. A certificate check on 443 that discovery gave the server's own device before moves to the new port and name on upgrade, keeping its history.
• A device added from a scan gets Ping only when it answered ping, so a server that blocks ping is no longer always red; one that answered only a TCP port gets a check on that port. Automatic templates leave their Ping off such devices. Adding a device by hand keeps Ping unless Ping it is unticked.
• Rescan on a device page could stay on Rescanning… for good when the site never finished it (offline, or a device that answers SNMP but not its walks). It now shows as not answered after five minutes, Stop ends a running one, and Rescan starts again. People limited to some devices can rescan only the devices they see.
• A device's set-up cards follow the connection it uses, not its type: the SNMP set-up card shows on any device with SNMP checks (an SNMP login), such as a switch or an application, and no longer on a Linux server that does not use SNMP; on a device that is not Linux it gives the SNMP version, user or community, port 161 and the addresses to allow, without the snmpd commands. The flow set-up card shows on switches, routers, firewalls and wireless, and on any device that has sent flows. Both stay for administrators only.
• The server monitoring itself no longer fails with every SNMP check on a server whose firewall drops what it was not told to allow (iptables -P INPUT DROP). TarleyNode now allows UDP 161 to the server's own address from its monitoring service's network only, with one rule tagged tarleynode-self-monitor at the top of INPUT, or through firewalld or ufw when one is on, and says so under Settings › Server. It touches no other rule, puts it back every minute and after a restart, and removes it when self-monitoring is turned off, the address changes or TarleyNode is uninstalled. In a cluster each server does this for its own address, and also allows the other cluster servers, since whichever is active polls it; a server that leaves the cluster loses its rule. A firewalld or ufw rule you already had is never removed, and when the server cannot read its monitoring network for a moment, every rule is left as it is.
• On a server with two network cards, the SNMP set-up card for a device the server polls itself now allows the address of the card that reaches the device, such as 10.200.206.111, instead of the address devices send to, such as a public 203.0.113.20, so snmpd and the firewall no longer drop the polls. In a cluster it allows every TarleyNode server, since another one polls after a takeover. An IPv6 device gets IPv6 rules (rocommunity6, ip6tables), with a <tarleynode-ipv6> placeholder when no IPv6 address is known. Connected sites keep their own address.
• The SNMP set-up card on a Linux server, and docs/linux-snmp.md, write placeholders as plain values like the real thing, such as sysLocation Server room, rack 2, sysContact admin@example.com, your-community-string, your-auth-password and tarleynode-ip, with no angle brackets to remove (they were being kept, as in sysLocation <DC Local>); the old CHANGE-ME lines could be pasted as they were. Quotes appear only where the syntax needs them (the quoted 'EOF' heredoc, the createUser line, so a password may have spaces, and the firewalld rich rule), each with a comment saying why; addresses in ufw and iptables lines are plain. Step 4 now has a firewall choice: ufw (default on Debian and Ubuntu), firewalld (default on Red Hat, Rocky and Alma) or iptables, which adds the rule (ip6tables for an IPv6 address), keeps it after a reboot and says that it replaces ufw or firewalld. Install lines no longer stop to ask, so a pasted block runs through.
• Changing the server's host name and remaking its certificate no longer disconnects the server's own connected site. It used to stop with an error saying its identity belonged to another server or was invalid until its data was deleted and it was enrolled again, which left the old connected site listed; it now takes the new name by itself. Connected sites on other machines still refuse a different server.
• A scan waiting for a connected site that is offline or disconnected no longer waits there silently. Discovery shows a warning on its site, and administrators can move it to another connected site with Move to; the move is in the audit trail. Disconnecting a connected site moves its scans to where a new scan of the same site would run, or cancels them and says why on the site.
• The Top 10 CPU, memory and disk lists show each device once, under the check whose alert rule watches that list (or System resources), instead of the same value under CPU, Memory, Disk space and System resources. The list stays in order. Interfaces, response and availability lists are unchanged.
• A Linux server found by a scan no longer ends up with four checks reading the same values: the Linux server (SNMP) template takes over the System resources check the scan added, keeping its history, unless you gave that check its own alert rule.
• A device's type from its SNMP system name now wins over a guess from its open ports, and a switch or firewall that runs Linux stays a switch or firewall instead of becoming a Linux server.
• In a cluster, the active server starts TarleyNode again when its gateway or its own connected site is left stopped by a failed start, which kept the console unreachable.
• In a cluster, after a backup was restored on one server, another server taking over now enrols its own connected site again, instead of it restarting over and over and leaving every device without readings.
• Every server in a cluster now tells devices to send flows, syslog and traps to the cluster's shared address, and uses it for links, instead of the first server's own address, which stops answering after a takeover. The server's own certificate covers the shared address.
• Pressing Escape in the route dialog opened from a warning closes only that dialog, not the site, ranges or scan form behind it.
• With a sensor open, the page header no longer offers Remove device, which removed the whole device. The sensor's button reads Remove sensor, and the Remove device dialog names the device in its title.
• Fields in a form row line up again: a list without a hint, such as Make on a device page, no longer sits lower and taller than the box beside it.
• After restoring a backup, monitoring no longer stops after the first nightly backup until notifications are turned on again. Connected sites were given nothing to check and their readings were refused, with no warning. A server where this happened starts monitoring again when it is updated. Notifications still wait until you turn them on under Notifications.
• Removing a sensor that has an open alert no longer fails with Unable to remove check. The same fault kept the Docker interface Port checks above, a removed login's checks and the server's own checks in place when one of them was alerting.
• Upgrading a server in a cluster, including with apt, no longer fails now and then with a container name conflict on a standby: the installer keeps the cluster agent from starting containers while it replaces them.

All releases · Plain text