TarleyNode 0.3.1

New

• Tools on every device page: ping, traceroute, a port check, a DNS lookup and Wake-on-LAN, run from wherever the device is monitored.
• New-device alerts: a site can raise a warning when a scan finds a device never seen there before (not after its first scan, and not for a known machine that only changed address). Turn it on under the site's Logins.
• Repeating maintenance: weekly windows, such as Sundays 02:00 to 04:00, in your time zone.
• Quiet hours for each notification destination: at night or at weekends it gets critical alerts only.
• Telegram and SMS (through your Twilio account) notification destinations.
• Asset details on each device (MAC address, serial number, owner, purchase and warranty dates, notes), searchable, with a Warranties ending card on the Overview.
• Each site's address list (Discovery › Addresses) shows which addresses are monitored, seen on the network but not monitored, or free.
• Growing disks: after space is added to the TarleyNode server's disk, Settings › Server disk shows it and "Expand to use it" grows the partition, LVM volume and ext4/XFS filesystem into it without stopping (also `sudo tarleynode expand-disk`). A monitored Linux or Windows server's page has a Disks card that checks each filesystem for added space and grows one with a button, over its SSH login (root or passwordless sudo) or WinRM login (administrator).
• A sensor's page shows every value it reads at once, each with its own graph; click one to make it full width.
• Upstream devices: a device page shows what it sits behind, suggests the firewall or router at its site, and lists how many devices sit behind it. While an upstream device is down, alerts for the devices behind it are held back, so one outage sends one alert. Several devices can be put behind one from the device list.
• Top 10 lists on the Overview: least available, highest CPU and memory, fullest disks, busiest interfaces and slowest response, over the last day or week. Scheduled PDF reports include them.
• Maps can have a floor plan, rack photo or diagram behind them, with any device of the site placed on it showing its live status.
• Acknowledging an incident can carry a note, and anyone can add notes to its timeline. A device can be snoozed from the incident page for an hour, 4 hours, a day or a week.
• A changed device configuration opens a warning saying how many lines changed, with "See what changed" opening the differences. It closes once acknowledged, or a day after the last change, and can be turned off per device.
• Certificates on the Overview: every watched certificate, soonest to expire first, and one click to watch the certificate of every device scans found answering HTTPS (warning 30 days before expiry).
• Ticking devices in the device list lets you edit all their checks at once (interval, timeout, state, alerting), or put them behind an upstream device.
• Disk forecasts: the Overview lists disks that will be full within two months at the rate they grew over the last week, and a disk's own page says when it will be full.
• Rules can alert when a value goes above its normal range, learned from the last week (average plus 2, 3 or 4 standard deviations, refreshed every 15 minutes), instead of a fixed limit.
• SNMPv3 traps: this server and connected sites accept v3 traps authenticated (and decrypted) as the SNMPv3 user of the device that sent them, and v1/v2c traps with the device's own community, without setting communities by hand. New installations and connected sites set up with receivers listen on UDP 162.
• SNMPv3 logins choose their authentication (SHA-1 to SHA-512, MD5) and privacy (AES-128/192/256, DES) to match the device; before, SHA-256 and AES-128 were assumed.
• Device templates can apply themselves to every device of a type and vendor (such as firewalls from Fortinet), when devices are added and when the template is saved. Changing a template now changes the checks made from it; a check taken out keeps running on its own.
• SNMP checks show the version and port they used, and a missing value is explained as noSuchObject.
• A device page lists every sensor at once with its latest values, problems first; choosing one opens its own page with the graph, each value, and its settings.
• The Overview has a Stale checks card beside Failed checks, listing checks with no recent reading.
• History can be kept for as long as the server's disk allows, now the default for new installations: the oldest is let go only when the disk is nearly full. Settings › History chooses that or a fixed 30 days to 5 years, and shows the free disk space.
• Check history shows the last 1 hour to 30 days, or any dates you choose; longer ranges label the axis by day.
• UniFi and Zyxel Nebula checks: with an API key, TarleyNode reads what a UniFi console or server (its Integration API) or the Nebula cloud knows about every access point, switch and gateway, counts them online and offline, lists the offline ones, or watches one by name.
• The device list sorts by any column (name, status with problems first, category, site, checks, type); click a heading, click again to reverse. The choice is remembered.
• Each site has logins (SNMP, Windows, Linux). A device added from Discovery gets the one that fits it, so it starts with its ports, traffic, CPU, memory, disks and hardware sensors instead of ping alone. Logins are never tried before a device is added, and only the fitting one. A site can also add what its scans find by itself (Discovery › Logins).
• Device search also matches the device type, vendor profile, category and location, so searching "server" or "firewall" lists them.
• A device's Logins list only offers the login types that fit it: SNMP for firewalls, switches, printers and the like; WinRM for Windows servers; SSH for Linux. The rest are one click away. Fortinet devices are recognised as firewalls by their network card too.
• Locations can be dragged onto another location to go inside it, or onto All devices to go back to the top.
• Someone given a password by an administrator (a new user, or after Set password) chooses their own at first sign-in, before they can use the console.
• Backups: Settings › Backups makes one password-protected file every night (or on demand) with everything needed to put the server back, keeps the last few and offers them for download. A new installation can restore one from its setup page (or `sudo tarleynode restore FILE`), bringing back devices, history, users, alerts, settings and certificates.
• Before installing an update, Software updates shows what the new release changes, from its release notes on tarleynode.com.
• The installation guide lists every address the server needs to reach, and the installer warns if it cannot reach the licence or update server. When licence or update checks cannot get through, the console names the address to allow in the firewall and when limits would apply.

Security

• Restoring a backup takes only the settings TarleyNode itself saves, each checked, and restores the database as an ordinary database user, refusing anything TarleyNode never creates. A crafted backup could otherwise run commands on the server.
• The restore works on a copy only the server's administrator account can reach, and no longer writes through files the application could swap.
• Setting the backup password or downloading a backup asks for your own password (or a sign-in in the last 15 minutes for organisation accounts). API keys cannot reach backups, restores or phone pairing.
• Scans never send logins: custom scans no longer offer an SNMP login, and devices a scan adds by itself start with ping only until an administrator gives them a login.
• Support packs remove passwords in more forms (inside logged JSON, auth_password, priv_password, snmp_community, passphrase, SQL PASSWORD '...') and replace every internal host name.
• Paired phones keep at most the role their owner had when pairing, and stop working 90 days after their owner last signed in to the console. An administrator setting someone's password also removes their phones and revokes their API keys, and API keys pause while their owner must choose a new password.
• UniFi and Nebula checks never follow redirects, so their API key cannot be sent over plain http.
• Disk growing on Linux servers pipes its script straight into bash rather than through a temporary file.
• Monitoring on the server itself runs on a network of its own with only the gateway, away from the database, NATS and the metric store.
• Two-step sign-in setup and switch-off are rate limited, the restore status no longer names the backup to anyone not signed in, and a restore from the setup page asks you to agree to the licence terms.
• Licence keys can no longer be swapped through an environment variable outside development.

Changed

• Re-running the installer on a server that already receives syslog now also opens UDP 162 for SNMP traps.
• Captured SNMPv3 traps can be replayed by someone on the network (a limitation of the SNMP library); allow 162/udp only from your devices' subnets.
• Connected sites has its own place in the menu, with Connect a site.
• The setup page shows the licence terms and privacy notice in place (this release's copy, with a link to the latest on the website).
• No licence limits users any more: every licence, trial and TarleyNode Free has unlimited users.

Fixed

• SNMP system resources work on pfSense, TrueNAS and other systems with many volumes, which failed with "table limit".
• SNMP checks say why they fail: no answer (SNMP off, this server not allowed, or a wrong community), an unknown v3 user, a wrong v3 password or encryption setting, or a closed port, instead of "SNMP request failed". The Logins card shows the reason too.
• Support packs list the port, login type and where each failed check runs from, and no longer turn audit action names such as update.requested into placeholders.
• An update reports success only once the new release is the one running.
• An installation that stopped part way and was run again now monitors from the server itself, so its sites can be scanned. `install.sh --monitor-here` adds this to an existing installation.
• Installing on Ubuntu 26.04 no longer fails with "invalid user: '10001'"; secret files are given to the application's numeric user with chown.

All releases · Plain text