v0.70.0

Upgrading a container from 0.61 or earlier? It is NOT grandfathered

A container that answered your LAN before the upgrade stops answering it after. The dashboard goes dark from other machines until you add -e PINGULARITY_ACCESS=network (or -access network) and recreate the container.

Nothing is lost - the volume, the database and all history carry over - but you have to opt back in.

Why it fails closed rather than guessing: the daemon cannot tell a store upgraded from 0.61 or earlier from one that was born private under an earlier build and simply ran for a while. Neither recorded an access choice, and guessing "open" would put an unauthenticated dashboard on your network. So it declines, and logs one warning naming both the state and the fix.

Every install now starts private, containers included

There is no exception for fresh installs either. A published port answers 403 until you opt in with -access network / -e PINGULARITY_ACCESS=network, or turn Network access on in the Access tab from the machine itself.

An explicit -access / PINGULARITY_ACCESS overrides a disagreeing stored setting at every start, in either direction. That is the recovery for a container locked out of its own published port, and it matters because the default image has no shell to repair it from.

Other things that change on upgrade

Your DNS latency readings will move, and the old ones are not comparable. The probe now looks its name up exactly as written instead of letting your resolver try it against your search domains first. On some hosts that removes a second lookup that could only fail and the number drops; on others it removes a fast local answer for a different name and the number rises. Set any DNS alert thresholds again from what you see now rather than assuming a direction.

A second restore running at the same time as another now gets refused with HTTP 429 instead of proceeding. Two concurrent restores used to collide and leave the database partly restored. If you script restores, expect a 429 where a concurrent request previously returned success.

If you have ever been told to back up by copying the database file: stop the service first, and take pingularity.key with it. The documentation said that single file was a complete backup. It is not, and a copy taken while the service is running can be empty - recent data lives in a sidecar file until a clean stop folds it in.

What is new

• The downtime heatmap shows the whole year. Clean days used to be the same colour as the panel behind them, so a year of good days looked like blank space and only the bad days appeared. Every day is now visible, and hovering any of them tells you the date and what happened - which also means the year is finally readable with a screen reader.

• Speed tests report packet loss and jitter more honestly, and when the UDP pass cannot get through - almost always a firewall allowing the port for TCP but not UDP - the log now says so instead of failing silently.

• The dashboard does less work. Hidden panels stop fetching entirely, charts refresh at a rate that suits the window you are looking at, and a chart pinned to a wide custom range no longer re-reads your whole history every six seconds.

• Commands start about eight times faster. Every command, including version, used to spend ~43ms preparing a password hash it never used. In Docker that ran on every health check, around two minutes of CPU a day per container.

• Far fewer writes to disk. The log was being written and flushed every minute whether or not anything had been logged. On an SD card it is the number of writes that wears the card out.

Fixes worth knowing

• A chart pinned to a fixed date range could keep showing data you had deleted, permanently, until the page was reloaded.
• On Windows, the log file's permissions stopped being repaired if it was ever opened up by a restore or an admin tool.
• Restoring the connection tile could fire a full IP, ISP and route lookup that runs for up to 25 seconds, without the guard that stops two running at once.
• The first-run screen understated how much data hourly speed tests use - it now quotes a ceiling rather than a best case, and says that tests after an outage are a separate setting that is on by default.
• The logging switch labelled "Off" always kept warnings and errors, which is deliberate and useful. It said otherwise. It now says what it does.

Changelog

• Say why the exit path fell back, and widen the DNS "good" band
• Stop claiming the DNS reading only goes down after this upgrade
• Say when a blocked UDP port is why loss and jitter are missing
• Correct what the README says about traffic, alerts and speed figures
• Stop telling people a copy of the database is a complete backup
• Stop describing a release that never shipped, and tidy the repo
• Read the dashboard source the same way on every platform
• Stop charts redrawing data you deleted, and doing work while hidden
• Stop overstating what we know about quiet days and data use
• Keep the log file locked down when nothing has been logged
• Say what the logging switch actually does
• Stop timing a doomed second lookup in the DNS latency figure
• Make the daemon cheaper to run when it is idle, and correct what it tells you
• Show the whole year on the downtime heatmap, and say what each day was
• Speedtests through a proxy, containers that never open on a guess, backups that restore, and numbers that tell the truth
• Fix proxied speedtests and container lockouts, and make containers easier to run right
• Fix broken speedtest uploads (v0.61 regression), and guard the network probes