Contributing a node

Contributing hardware — For institutions and campus IT staff adding servers to the NRP pool.

This is the procedure for adding a server to Nautilus, the Kubernetes cluster the NRP runs. Deciding whether your institution should contribute at all? Contribute hardware covers the arrangement.

How we reach the node

Your site gives the NRP one of two kinds of access, and that choice sets the one boundary between us that moves: who installs the operating system and keeps the firmware current. IPMI is less work for your site. Without it the NRP cannot power-cycle a hung node, reach its console, or reinstall it remotely, so recovery goes through someone at your site.

Pick one, and the rest of this page shows what it means for you.

Your site gives the NRP

IPMI accessRoot SSH with sudo

Researchers build on

Workloads notebooks · training · inference

NRP operates remotely, from IPMI up remotely, from the OS up

Kubernetes one national cluster

OS , Security , Monitoring

IPMI , Firmware , BIOS — run by the NRP — run by your site

Your site hosts plus firmware, BIOS, and the OS install

Servers , Rack , Power , Network path

What each side runs

Your site provides

Space and power Rack units, power drops, and cabling, with conditioned power and cooling the node can stay up on.
Network path Usually a Science DMZ path outside the campus firewall, at 10–100G, with jumbo frames to every other node, and local iptables or firewalld off.
With IPMI Management access IPMI, reachable from the NRP management address.
With root SSH Management access Root SSH with sudo, reachable from the NRP management address.
With root SSH OS install and firmware Install Ubuntu Server 24.04, and keep the BIOS and firmware current.
An on-site contact A named person we can reach for physical access, reboots, and hardware swaps.
With root SSH Recovery Without IPMI, a hung node needs hands: we tell your on-site contact what it needs, and they do it.

Helps if you can

Warranty coordination Forward vendor hardware tickets to the NRP for triage.
Maintenance notice Tell us before planned power or network downtime so we can drain the node.

The NRP runs

With IPMI OS and firmware The Ubuntu Server 24.04 install, BIOS and firmware updates, and the OS lifecycle from then on.
With root SSH OS lifecycle Everything from the OS up, once your site has installed it.
Cluster join Joining the node to Nautilus, storage provisioning, and GPU drivers.
Security from the OS up Patching, package updates, and host hardening. Nobody at your site tracks CVEs for the node.
Cluster network policy Central Calico policy firewalls the node, so you maintain no per-node rules.
Monitoring and response 24/7 alerting, health checks, and incident handling.

Also included

Procurement guidance Hardware recommendations and fulfillment support.
Capacity reporting Grafana dashboards and accounting for your own utilization.
Docs and training Reference material and sessions for your local administrators.

The network path is the requirement that rules nodes out. Check yours against Networking before you send anything.

What to send us

Node IP configuration — public IP, subnet mask, and gateway.
DNS servers for the host network
If you have no preference we default to public resolvers: 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google).
Management access
With IPMI
The IPMI address, and its credentials if any are set. Credentials are a secret: they travel by email only, never in the chat.
With root SSH
The name of an account with sudo on the node. We send you our operators’ public keys to add to it, so no secret changes hands.
Include jump-host details if the node is not directly reachable.
Firewall allowance — if your ACL needs an entry for IPMI or SSH, allow the NRP management address:
```
67.58.53.149
```
Contacts — the on-site contact from the table above, and a security contact for incident notices, if that is a different person.

That is enough for us to build the host. The template below has a line for each; copy it into your email.

Subject: Contributing a node: <institution>

Node IP / subnet / gateway:
DNS servers:                  (or "defaults")
Management access:            IPMI at <address>, or SSH account <name>
Jump host:                    (if any)
On-site contact:              <name, email, phone>
Security contact:             <name, email>

Send it

Email the details to support@nationalresearchplatform.org, with your institution in the subject line. We take it from there: configuring the node, joining it to Nautilus, and bringing it into the scheduling pool.

Never post addresses or credentials in the support chat. Its rooms are public, and private messages to admins there are rejected. The chat and the bi-weekly office hours are the place for questions.

Security incidents

Incident notice runs both ways:

You tell us about incidents at your site that could affect the node — a compromised management network, exposed credentials, anything that puts the host at risk.
We tell you about incidents on the cluster that could affect your site.

Either way, by email to support@nationalresearchplatform.org, not in the support chat.

Once the node is online

Your researchers need accounts, and that path is separate from the hardware: CILogon federated identity, promotion from guest to user by an existing admin, a namespace, and the Acceptable Use Policy. Get Access is the walkthrough to point them at.

From then on the node is yours first. When your researchers want it, they get it; when it would sit idle, the rest of the pool runs on it, and your researchers can schedule across everyone else’s. Its utilization shows in the cluster’s Grafana dashboards alongside every other contributed node.

This work was supported in part by National Science Foundation (NSF) awards CNS-1730158, ACI-1540112, ACI-1541349, OAC-1826967, OAC-2112167, CNS-2100237, CNS-2120019.