vitya
11554d45ac
Incident 2026-05-28 ~05:45–13:52 MSK на vds-kzntsv. ~2.5ч активного outage + ~5.5ч на эфемерной статике до окончательного fix хостером. Revised RCA: наш netplan+systemd-networkd конфликтовал с provider's expected ifupdown stack. Их start/ipadd procedure ожидает чистый ifupdown и не может auto-recover когда networkd «держит» eth0. 8 дней работало потому что networkd сам тянул DHCP. Когда что-то на стороне Rusonyx разорвало DHCP-binding — auto-recovery не сработала. Fix: systemctl mask netplan + systemd-networkd* (на running system без stop — IP и SSH сохранились), Rusonyx ребутнул VM и положил чистый /etc/network/interfaces.d/ifcfg-eth0 через свой start/ipadd. Netmask /18, gw 89.253.192.1, чистый ifupdown. Wiki: - NEW concepts/vds-kzntsv-dhcp-outage-2026-05-28 — full RCA + recovery runbook (эфемерная статика + permanent-fix via ifupdown) + diagnostic dot-graph + revised lessons-learned + anti-pattern - NEW sources/vds-kzntsv-incident-2026-05-28 — timeline 05:25 backup OK → 08:43 statics → 13:52 final reset; provider's ifcfg-eth0 content; ticket text reference - UPDATE entities/vds-kzntsv — mask /18, ifupdown stack, kernel cmdline net.ifnames=0 объясняет eth0 naming, hypervisor hw80, pass-store путь, Known issues § - UPDATE concepts/rusonyx-vps-onboarding-quirks — quirk #9 переписан про /18 layout + canonical ifcfg, quirk #10 NEW про ifupdown vs netplan stack choice + bootstrap mask commands - UPDATE index.md + log.md Tasks: - STATUS header: incident RESOLVED summary - NEXT_SESSION: следующая сессия — cleanup netplan-artifacts (optional), registry GC (~20G pending), board-viewer-build unhealthy разбор Memory (out-of-repo): vds-kzntsv-rusonyx-network-recovery переписан с revised RCA — canonical bootstrap step «mask netplan/networkd» для всех Rusonyx Ubuntu VDS. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
171 lines
11 KiB
Markdown
171 lines
11 KiB
Markdown
---
|
||
title: Rusonyx VPS onboarding quirks (Astra Облако / myvm.rusonyx.ru)
|
||
type: concept
|
||
tags: [rusonyx, vds, bootstrap, onboarding, gotchas, vendor]
|
||
sources: [../sources/vds-kzntsv-bootstrap-2026-05-20.md]
|
||
updated: 2026-05-20
|
||
---
|
||
|
||
# Rusonyx VPS onboarding quirks
|
||
|
||
Quirks first-boot опыта на Rusonyx VDS (Astra Облако, https://myvm.rusonyx.ru) — для memory будущих сессий. Зафиксировано при активации [`vds-kzntsv`](../entities/vds-kzntsv.md) 2026-05-20.
|
||
|
||
## 1. VNC console не открывается с первого раза
|
||
|
||
В Управление сервером → Консоль HTML5 noVNC может не загружаться (зависание на индикаторе соединения). Помогает кнопка **«Остановить VNC»** в той же панели — force-disconnect stale attachment'а на hypervisor side. После клика подождать ~5 сек, открыть консоль заново.
|
||
|
||
Если не помогает — ticket в support, без VNC реальной возможности зайти в box нет (см. quirk 2).
|
||
|
||
## 2. Stale системный образ Ubuntu — обязательный upgrade через VNC
|
||
|
||
Поставка содержит сотни pending updates, включая `openssh-server` и kernel. Письмо при активации **прямо рекомендует** последовательность:
|
||
|
||
```bash
|
||
apt update
|
||
apt upgrade
|
||
apt --fix-broken install
|
||
apt upgrade
|
||
```
|
||
|
||
И ключевая часть: **«строго через VNC-консоль»**, потому что `openssh-server` upgrade'у переключают сервис, что разрывает SSH session и бьёт upgrade на половине.
|
||
|
||
По дороге будет **5+ dpkg interactive prompts** (conffile conflicts). Ответы:
|
||
|
||
| Prompt | Правильный ответ | Reasoning |
|
||
|---|---|---|
|
||
| `/etc/ssh/sshd_config` | **2** (keep local) | Rusonyx-modified sshd_config форсит `PermitRootLogin yes` + `PasswordAuthentication yes` для первого захода. Maintainer-версия дефолтит `prohibit-password` — потеряешь SSH-доступ если ключ ещё не залит. |
|
||
| `/etc/cloud/cloud.cfg` | **N** (keep current) | Rusonyx модифицировал под свой provisioning (network, ssh-key inject). Maintainer-версия может сломать их хуки. |
|
||
| `grub-pc /dev/vdaX target` | **1** (`/dev/vda` whole-disk MBR) | Опция 2 (на partition) — blocklist mechanism, less reliable. Опция 3 (skip) = box не загрузится. |
|
||
| `cloud-init local config` (если появится) | keep | По той же логике. |
|
||
|
||
После завершения — `reboot` (или ждать пока apt сам запустит).
|
||
|
||
## 3. SSH initial password — одноразовый
|
||
|
||
Активационное письмо даёт `root` + одноразовый пароль. Первый шаг bootstrap'а (после VNC-upgrade) — push своего SSH key и harden sshd:
|
||
|
||
```
|
||
PermitRootLogin no
|
||
PasswordAuthentication no
|
||
PubkeyAuthentication yes
|
||
```
|
||
|
||
Через **drop-in file `/etc/ssh/sshd_config.d/00-hardening.conf`** (префикс `00-` чтобы выиграть first-match precedence над `50-cloud-init.conf` который форсит `PasswordAuthentication yes`).
|
||
|
||
## 4. Подключение через SSH с password на Windows
|
||
|
||
OpenSSH for Windows **не имеет** `-pw` flag (как `plink`/PuTTY) или `sshpass`. Для одноразового password-bootstrap:
|
||
|
||
- **plink.exe** (`C:\Program Files\PuTTY\plink.exe`) — supports `-pw`, доступен если PuTTY установлен.
|
||
- Pipe `echo y | plink ...` для auto-accept first-time host key (plink кэширует в registry).
|
||
- После push pubkey → переключаемся на native OpenSSH `ssh -i` (plink больше не нужен).
|
||
|
||
## 5. Hypervisor-side VNC ≠ guest-side VNC service
|
||
|
||
В гостевой системе **нет** VNC service'а — VNC console работает на qemu/KVM hypervisor side. Поэтому request «зайди и передёрни vnc service из гостя» невозможен. Управляется только через Rusonyx web panel.
|
||
|
||
## 6. Default firewall — open?
|
||
|
||
Из наблюдений 2026-05-20: после reboot SSH:22 поднимался автоматом, не было видно guest-side ufw default-deny. Но **ICMP ping проходил до VNC-fix**, при том что **все TCP-порты были filtered**. Похоже, Rusonyx имеет perimeter firewall, который автоматически allow'ит TCP только когда VPS становится «active» в их учёте — корреляция с моментом первой VNC-сессии. Не воспроизводимо post-factum; для будущих VDS — стоит сначала открыть VNC, потом ждать что SSH станет доступен.
|
||
|
||
## 7. Tariff именования
|
||
|
||
«160 SSD» переименован в «160 NVMe» (та же цена, апгрейд по IOPS). Если в старой переписке/доках видите «160 SSD» — это actually 160 NVMe. Аналогично могут быть переименования для 80/220+ тарифов.
|
||
|
||
## 8. Welcome-email рекомендации
|
||
|
||
Содержит только команды apt upgrade, **не упоминает**:
|
||
- Что VNC может быть stale.
|
||
- Какие dpkg prompts и правильные ответы.
|
||
- Initial password — одноразовый, нужно сменить на ключ.
|
||
|
||
См. также: support-ticket draft в [`vds-kzntsv-bootstrap-2026-05-20`](../sources/vds-kzntsv-bootstrap-2026-05-20.md) с конкретными suggestions для Rusonyx.
|
||
|
||
## 9. Сеть = /18, не /24. Gw в той же subnet
|
||
|
||
Rusonyx прописывает VM в **/18** (`netmask 255.255.192.0`), не в /24. Адреса `89.253.192.0 – 89.253.255.255` — это один большой L2 broadcast domain, gateway `89.253.192.1` сидит **внутри** него.
|
||
|
||
Каноническая ifupdown-конфигурация (то что прописывает их `start/ipadd` procedure):
|
||
|
||
```
|
||
auto eth0
|
||
allow-hotplug eth0
|
||
iface eth0 inet static
|
||
address 89.253.255.94
|
||
netmask 255.255.192.0
|
||
post-up ip ro add 169.254.0.0/16 dev eth0 metric 400
|
||
post-up ip ro add 89.253.192.1 dev eth0 metric 400
|
||
post-up ip ro add default via 89.253.192.1 dev eth0 metric 400
|
||
post-up ip ro add 89.253.192.0/18 via 89.253.192.1 dev eth0 src 89.253.255.94 metric 400
|
||
post-up ip ro del 89.253.192.0/18 dev eth0 proto kernel scope link src 89.253.255.94
|
||
```
|
||
|
||
Тонкость: их post-up сначала добавляет 89.253.192.0/18 **через gw** (routed), потом удаляет автоматически добавленный kernel-route (directly attached). То есть весь трафик внутри /18 идёт **через gw**, не L2-broadcast — типичный hosting-pattern для изоляции клиентов друг от друга (`proxy-ARP` / routed-on-host).
|
||
|
||
Эфемерная статика для recovery (если конфиг утерян):
|
||
|
||
```bash
|
||
sudo ip addr add 89.253.255.94/18 dev eth0 # /18 — gw сам в подсети, link-route не нужен
|
||
sudo ip route add default via 89.253.192.1 dev eth0
|
||
```
|
||
|
||
Если по какой-то причине /18 не приемлем — fallback с /24 и link-route к gw:
|
||
|
||
```bash
|
||
sudo ip addr add 89.253.255.94/24 dev eth0
|
||
sudo ip route add 89.253.192.1 dev eth0 # link-scope route к gw
|
||
sudo ip route add default via 89.253.192.1
|
||
```
|
||
|
||
DNS resolvers: `89.253.252.30`, `89.253.252.31`.
|
||
|
||
Как обнаружить gw/netmask для конкретной VM:
|
||
|
||
1. **Соседний VPS у того же хостера** — `ip route` + `ip addr` покажут.
|
||
2. **`/etc/network/interfaces.d/ifcfg-<iface>`** на самой VM (если конфиг present) — provider's canonical setup.
|
||
3. Cached DHCP lease (если уцелел): `cat /run/systemd/netif/leases/*` → поле `ROUTER=`.
|
||
4. Активационное письмо при выдаче VPS.
|
||
5. Support ticket — последний resort.
|
||
|
||
Подробный кейс где это пригодилось — [`vds-kzntsv-dhcp-outage-2026-05-28`](vds-kzntsv-dhcp-outage-2026-05-28.md).
|
||
|
||
## 10. Network stack: ifupdown (NOT netplan)
|
||
|
||
Rusonyx provisioning ожидает **`ifupdown` + `networking` service**, не netplan/systemd-networkd. Их `start/ipadd/ipdel` procedure (вызывается при start VM / IP add-remove / network reset) кладёт `/etc/network/interfaces.d/ifcfg-<iface>` и ребутает networking.
|
||
|
||
Header в их `/etc/network/interfaces`:
|
||
|
||
```
|
||
# Autoconfigured by Provider's start/ipadd/ipdel procedure.
|
||
# !!! DO NOT MANUALLY EDIT OR DELETE THIS FILE !!!
|
||
```
|
||
|
||
**Проблема**: Ubuntu 24.04 base ships netplan + systemd-networkd. cloud-init часто оставляет `/etc/netplan/50-cloud-init.yaml` с `dhcp4: true`. После первого boot оба стека активны параллельно.
|
||
|
||
Скорее всего **8 дней работает потому что DHCP сам всё резолвит**. Но если что-то на стороне хостера разорвёт DHCP-binding (rare, но случается — см. инцидент 2026-05-28), **их auto-recovery `start/ipadd` не сможет применить static config**, потому что networkd «держит» eth0. → VM лежит до тикета.
|
||
|
||
**Канон setup после bootstrap для Rusonyx Ubuntu VDS:**
|
||
|
||
```bash
|
||
sudo systemctl disable systemd-networkd.service systemd-networkd.socket systemd-networkd-wait-online.service
|
||
sudo systemctl mask systemd-networkd.service systemd-networkd.socket systemd-networkd-wait-online.service
|
||
sudo systemctl mask netplan # preventive
|
||
# leave networking enabled (default)
|
||
```
|
||
|
||
**Безопасно на running system** — `disable`/`mask` без `stop` не убивают текущий процесс. Изменение вступает только при следующем boot.
|
||
|
||
**Anti-pattern:** прописывать persistent статику через `/etc/netplan/*.yaml`. Использовать ifupdown (`/etc/network/interfaces.d/*`), а лучше — попросить хостера через тикет «настройте дефолтную конфигурацию» — они через `start/ipadd` пропишут это сами.
|
||
|
||
Подробный кейс — [`vds-kzntsv-dhcp-outage-2026-05-28`](vds-kzntsv-dhcp-outage-2026-05-28.md).
|
||
|
||
## Когда применять
|
||
|
||
- Любой новый Rusonyx VDS (Astra Облако).
|
||
- Возможно частично применимо к другим Russian VDS-providers с custom OS templates (REG.RU, FirstByte, RuVDS), но конкретные dpkg prompt'ы вендор-specific.
|
||
|
||
## Ссылки
|
||
|
||
- [`vds-kzntsv-bootstrap-2026-05-20`](../sources/vds-kzntsv-bootstrap-2026-05-20.md) — где впервые столкнулись.
|
||
- [`vds-kzntsv`](../entities/vds-kzntsv.md) — текущий live host.
|