admin/.wiki/concepts/rusonyx-vps-onboarding-quirks.md

title, type, tags, sources, updated

title	type	tags	sources	updated
Rusonyx VPS onboarding quirks (Astra Облако / myvm.rusonyx.ru)	concept	rusonyx vds bootstrap onboarding gotchas vendor	../sources/vds-kzntsv-bootstrap-2026-05-20.md	2026-05-20

Rusonyx VPS onboarding quirks

Quirks first-boot опыта на Rusonyx VDS (Astra Облако, https://myvm.rusonyx.ru) — для memory будущих сессий. Зафиксировано при активации vds-kzntsv 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. Письмо при активации прямо рекомендует последовательность:

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 с конкретными 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 (если конфиг утерян):

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:

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.

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:

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.

Когда применять

• Любой новый Rusonyx VDS (Astra Облако).
• Возможно частично применимо к другим Russian VDS-providers с custom OS templates (REG.RU, FirstByte, RuVDS), но конкретные dpkg prompt'ы вендор-specific.

Ссылки

• vds-kzntsv-bootstrap-2026-05-20 — где впервые столкнулись.
• vds-kzntsv — текущий live host.