oxidecomputer / oxidecomputer/omicron

[rss] could check more for obviously-incoherent configuration

Open
#6,714 0 comments 0 reactions 1 assignee View on GitHub

@iximeow is already working on this.

Since Sep 27, 2024.

development Sled Agent
Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Description

i was modifying smf/sled-agent/non-gimlet/config-rss.toml to run Omicron on a local workstation, and did a fairly unwise thing:

# The IP ranges configured as part of the "internal services" IP Pool
#
# This is a range of *external* IP addresses that will be assigned to the
# External DNS server(s) and Nexus instances.  These are the IPs that users
# *outside* the rack will use to reach these services.  These will also be used
# by services like NTP as their externally-facing address for NAT.
#
# For more on this and what to put here, see docs/how-to-run.adoc.
[[internal_services_ip_pool_ranges]]
first = "192.168.0.128"
last = "192.168.0.140"

...
[rack_network_config]
...
# You can configure multiple uplinks by repeating the following stanza
[[rack_network_config.ports]]
# Routes associated with this port.
routes = [{nexthop = "192.168.0.1", destination = "0.0.0.0/0"}]
# Addresses associated with this port.
addresses = [{address = "192.168.0.130/24"}]

note that internal_services_ip_pool_ranges contains rack_network_config.addresses[0]. so, RSS gets on its merry way of setting up NTP, DNS, etc but then partway through it sets stuck (not exactly sure what it was stuck on, which is its own problem)

trying to debug this, dig oxide.computer in the NTP zone would hang, as would dig 0.pool.ntp.org (the default and configured ntp_servers name). however, chronyc -n sources listed four IPs, so 0.pool.ntp.org resolved at some point earlier. 1.1.1.1 and 9.9.9.9 were reachable from the global zone of the host, and those hostnames resolved the entire time without issue.

what appears to have happened is that one of the services that was started was done so on 192.168.0.130, which conflicts with the router's 192.168.0.130, and so networking to the outside world was fully wedged.

i think we'd be able to check this kind of thing here, though i see some similar validation in wicket here? the former seems like what i'd run into locally, but i'm not sure which workflows involve reconfiguration through wicket.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.