Sign inRegisterCheck connection

PHP Runtime Metadata for a Weather Site, Kept Private

Treat PHP version, GD, and XML as private station-site metadata. Do not publish phpinfo-style pages; record the runtime in a private operator log.

Back to Cumulus weather software guides

A Cumulus or Weather Display website was not only HTML. It was a runtime: a PHP version, loaded extensions, and the libraries that turned logger files into charts, XML, and gauges. That runtime is metadata about how observations were published. It belongs in an operator log. It does not belong on a public page that reprints phpinfo().

The historical URL /phpversion named that runtime. A sibling, /phpversion/gauges.php, used the same directory for analog dashboard gauges—mapped instruments, not a version string. This article is only about the environment record. It is not a live probe of the modern TNET stack, not a gauge dashboard, and not an invitation to expose server internals.

Historical context

Hobby weather sites in the 2000s often ran shared hosting with whatever PHP the provider shipped. Templates needed GD or another image library to draw graphs and banners. XML parsers ingested Cumulus or Weather Display exports. When a chart broke, the first diagnostic question was “which PHP, which GD, which XML extension?” Some operators answered it by hanging a phpinfo-style script on a guessable URL. Search engines and incoming links then treated that URL as content.

The original weather-station site is not rehosted as a diagnostic console. Publishing a full runtime dump was a convenience that doubled as an information leak. The useful residue is the idea of recording the publishing environment next to the data, the same way you record the logger model next to the temperature series.

What is worth recording

For a personal weather website, the environment is part of provenance. If two archives of the same station disagree, you want to know whether the template, the parser, or the language version changed.

Record, privately:

  • PHP version and whether it was CLI or the web SAPI.
  • Operating system and web server at a coarse level (for example, Apache on a named distro), not a full module list.
  • Image library — historically GD for PNG/JPEG graphs and banners; note the GD version if you have it.
  • XML stack — SimpleXML, DOM, or another extension used to read station XML.
  • Timezone setting of the PHP runtime versus the station clock. A mismatch here forges observation times.
  • Character encoding defaults, because mojibake in tags is a data bug, not a weather event.
  • Template or Cumulus/WD version that emitted the files PHP consumed.
  • Date of the record — metadata needs its own timestamp.

That list is an operator diary. It lets you explain why a graph script failed after a host “upgrade,” or why XML that parsed in 2012 throws in a later language. It is the software analog of noting that the temperature sensor moved from a roof to a screen.

Do not record passwords, API keys, database connection strings, cookie secrets, full php.ini dumps, or absolute paths that map the hosting account. Those are credentials and topology, not weather-site metadata.

Why a public phpinfo page is a security smell

PHP’s own documentation describes phpinfo() as a dump of compilation options, extensions, server and environment details, paths, and configuration values. That is exactly the inventory an attacker uses to pick exploits: outdated versions, dangerous functions left enabled, include paths, and sometimes environment variables that were never meant to be HTML.

A weather site does not need to advertise that inventory. Visitors need current conditions, units, and timestamps. They do not need to know the exact patch level of the image library. Searchable /phpversion URLs, /info.php droppings, and leftover install scripts are a known class of information disclosure. Removing them is not secrecy about meteorology. It is ordinary web hygiene.

If you still need a remote diagnostic during a migration, use an authenticated, temporary endpoint, then delete it. Do not leave it in the public tree because “the graph page might break again.” The graph page should fail closed with a generic error, not with a stack trace and a version banner.

This article does not provide a phpinfo replica, a fingerprinting script, or a copy of historical configuration. The historical URL remains an article so old links land on guidance instead of on a dump.

Runtime as evidence, not as a product feature

TNET’s public methodology talks about evidence families and about keeping observed, modelled, and derived information labeled. A station website has a smaller version of the same problem: the observation is the logger value; the derived display is the PNG or gauge; the publishing runtime is how the display was made. Confusing those three produces fake precision (a gauge drawn to 0.01 °C on an old PHP GD build) and fake continuity (a reconstructed page that no longer matches the PHP that wrote the archive).

When you migrate a Cumulus site:

  1. Snapshot the private runtime record before the host upgrades PHP.
  2. Snapshot logger files and templates in the same bundle.
  3. Note which scripts required GD versus which only parsed XML.
  4. Retire public diagnostic URLs.
  5. Verify that timezone and unit conversions still match the logger after the new runtime.

The XML parse page on this host is the sibling problem on the data side. The projects index collected the PHP utilities that depended on this environment. Neither needs a public phpinfo.

What an operator log entry can look like

Keep it boring and dated:

2011-06-12: PHP 5.x (web), GD enabled, SimpleXML enabled, date.timezone = America/Phoenix, Cumulus build {name}, charts written as PNG. No public phpinfo. This note is not a live scan.

Replace the version tokens with whatever you actually ran. Do not invent a version for this restoration. If you do not remember, write “unknown” rather than a plausible number. Unknown is honest metadata. A guessed PHP version is a fabricated instrument history.

Store the log off the web root. Include it when you hand the station to a successor. That is how a backyard archive stays interpretable after the original host is gone.

Practical checklist

  • No phpinfo(), full ini_get tables, or extension dumps on public URLs.
  • Private dated record of PHP, GD, XML, timezone, and template versions.
  • Secrets and paths excluded from that record.
  • Gauges, graphs, and XML tools documented as dependents of the runtime, not as the runtime itself.
  • After any host change, re-validate units and timestamps on one known-good dayfile.
  • This URL is documentation, not a scanner.

Modern relevance

Personal weather sites still break when a host jumps language versions. The lesson from /phpversion is to treat the runtime as part of the station’s metadata, then keep that metadata out of public HTML. For how TNET separates kinds of information on a modern product page—without publishing internal assembly details—see how the service works. Cumulus-era publishing notes remain on the Cumulus legacy hub.

Sources