OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
☷

Linux Node Preflight

Generate a read-only diagnostic script
Input

Sensitive values (IP, hostname, user, paths) are masked in the output.

Introduction

The Linux Node Preflight generates a bash script that inventories a Linux server before you run a blockchain node on it: distribution, architecture, CPU and flags, memory, swap, disk and filesystem type, NTP and timezone, ulimits, occupied ports, firewall, Docker, Compose, systemd, kernel, sysctl parameters and outbound connectivity.

The script is strictly diagnostic. It installs nothing, changes no configuration, opens no ports, restarts nothing and sends nothing to the network except a TCP reachability probe. You run it on the node, then paste the report back here for analysis.

Objective

  • Generate a read-only bash script tailored to the chosen chain and node type.
  • Surface the items that most often break a node rollout: insufficient RAM or disk, missing swap, unsynchronised clock, occupied ports, missing Docker/Compose and unsupported architecture.
  • Optionally mask public IP, hostname, username, personal paths and token-looking values in the output.
  • Analyse the pasted report locally and classify the result as approved, attention, critical or unverified.

Inputs

  • Blockchain and node type (validator, RPC, full, archive or pruned).
  • Masking preference for sensitive values.
  • The report text produced by the generated script (paste it back for analysis).

How it works

The script is assembled from read-only commands (uname, lscpu, /proc/meminfo, df, lsblk, findmnt, timedatectl, ulimit, ss, ufw/firewall-cmd, docker, systemctl, sysctl, a TCP reachability probe) and prints a PF_KEY=value report.

When masking is enabled, the script pipes its output through a sed filter that redacts IP addresses, hostnames, the current user, personal paths and token-looking values before display.

The pasted report is parsed back into keys and compared against per-chain thresholds: RAM and free disk against the recommended minimum, swap presence, NTP synchronisation, required ports in use, Docker/Compose presence, architecture support and the open-file ulimit.

The result is classified: approved when nothing failed, attention when warnings exist, critical when a blocking item failed, unverified when required keys are missing from the report.

Testable example

Try it — the analysis runs locally in your browser.

Example

Blockchain: Cosmos · Node type: validator · Mask: on

Expected output

PF_OS=Ubuntu 24.04.4 LTS
PF_ARCH=aarch64
PF_MEM_TOTAL_GB=5
PF_DISK_FREE_GB=67
PF_NTP=yes
PF_PORTS=22 80 443 3100
→ Critical: RAM below the recommended minimum for this profile.

Reading the output

  • Approved means the checked items meet the profile thresholds — it does not guarantee the node will run; it is a readiness signal, not a certification.
  • A critical finding (RAM, disk, occupied required port) should be resolved before deploying the node.
  • Warnings such as missing swap or unverified items are context-dependent; review them for your workload.
  • Masked output keeps the report safe to paste into a browser, but treat the report as sensitive anyway.

Risks

  • A node started on an under-sized server can corrupt its database during sync and force a full re-sync.
  • An unsynchronised clock breaks validator voting and can trigger penalties.
  • Pasting a report that contains real secrets — the mask option reduces, but does not eliminate, this risk.

Limitations

  • The tool reads what the script printed; it cannot verify anything the script could not measure.
  • Docker and Compose are reported, not required — some node deployments run without them.
  • The connectivity probe only checks reachability; it sends no data.

Official references

FAQ

Does the script change anything on my server?

No. It only reads system information and prints a report. It installs no packages, changes no configuration, opens no ports and restarts nothing. Review the generated script before running it if you prefer.

What does the connectivity probe do?

It opens a TCP connection to 1.1.1.1:53 and reports ok or unreachable. It sends no application data — it only tests whether outbound connections work, which most node stacks need for peer discovery.

Should I paste the report with masking off?

No. Keep masking on: the report contains your public IP, hostname and username. The analysis works identically either way because it reads the PF_ keys, not the masked values.