Files
admin/rusonyx-vps-onboarding-quirks.md
vitya dd7c56742e docs(.wiki,.tasks): vds-kzntsv-bootstrap done — 3 phases shipped
VDS Rusonyx 160 NVMe (89.253.255.94 / vds.kzntsv.site) активирован
2026-05-20. 3 фазы за ~6 часов:

- Phase 1: harden + docker 29.5.1 + traefik v2.11 + portainer 2.21.5
- Phase 2: shared DB park (postgres 16 / mariadb 11.4 / mongo 7 /
  redis 7) via traefik raw TCP forward + self-signed TLS
- Phase 3: миграция gitea (132 repos), verdaccio (2063 pkgs), registry
  fresh install (user accepted loss old images) + Joxit GUI

Ingest 1 source + 1 entity (vds-kzntsv) + 6 concepts (traefik-tcp-
passthrough-vs-starttls / portainer-2.21-admin-password-regression /
db-tls-self-signed-via-traefik-raw-tcp / rusonyx-vps-onboarding-quirks
/ registry-gc-mount-and-modify-flag / compose-bcrypt-escape-trap).

3 follow-up  tasks: vds-gc-cron, vds-backup-rsync-kreknin, vds-ntfy-push.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-20 22:39:31 +03:00

6.4 KiB
Raw Blame History

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.

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

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

Ссылки