Files
knowledge-base/projects/buzharovo/server1c.md
dttb bf565f1392 mmfb/lionart-1c: SSH + фикс efsaveragent + накопленный backlog vault-а
Сегодня (mmfb / LionART 1C):
- projects/mmfb/lionart-1c.md — новый файл: VM 100 на pve LionART
  (WIN-70M2VEJIKEF, 10.253.1.240, Win Server 2022, 1С+SQL+Effector Saver),
  SSH-доступ claude/Kl@udeD1ag!2026 заведён, RDP под Администратор + 2FA.
- projects/mmfb/proxmox-inventory.md — hostname WIN-70M2VEJIKEF в VM 100.
- decisions/2026-05-28-mmfb-effector-saver-locked-admin.md — диагноз
  цикла 7038 (SCM-пароль разъехался с .\Администратор) + lockout учётки,
  и пошаговое решение (disable службы → ADSI unlock → LogonUser-проверка
  → sc.exe config password= → start auto).

Накопившийся backlog (без отдельной правки в эту сессию):
- decisions/: buzharovo (recon, migration-plan, 1c-licensing), sergey
  (instagram iPhone fakeip), amneziavpn macOS v1/v2 incompat, benelux
  compromise 2026-05-20, glavtorg autologon off, omni domain+update.
- projects/: benilux README, buzharovo README+server1c, dttb
  (nextcloud-talk-bot, npm-proxy-hosts, proxmox-inventory, vpn-clients),
  glavtorg, sergey README, projects/_index.
- claude-memory/: benelux, omniroute.
- snippets/mac-dictation/groq-dictate.sh.
- notes/claude/: ~80 авто-сохранённых транскриптов сессий за май.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-29 12:33:03 +03:00

144 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
date: 2026-04-17
updated: 2026-05-07
type: project
tags: [dttb]
---
# Server1C — Сервер 1С в Бужарово
> **2026-05-07:** проведена разведка перед миграцией на HomeLab. См. [[decisions/2026-05-07-buzharovo-recon]] и [[decisions/2026-05-07-buzharovo-migration-plan]].
## Подключение
- **Публичный IP:** 185.13.47.2 (RDP:3389) — ⚠ открыт в Интернет
- **Netbird IP:** 100.70.75.103 (server1c.netbird.cloud)
- **WinRM:** порт 5985, basic auth
- **Учётка:** dttb / 1qaz!QAZ
- **OS:** Windows Server 2012 R2 (build 9600) — EOL 2023-10-10
- **Hostname:** Server1C
- **Локация:** Бужарово
- **LAN:** 192.168.1.249/24, gw 192.168.1.1, MAC 00:E0:4C:68:9E:34
## Hardware (бытовая сборка, без ИБП)
- **Мать:** ASUS PRIME Z690M-PLUS D4 (BIOS AMI v1620 от 2022-08-12)
- **CPU:** Intel i5-12400 (6c/12t @ 2.5 GHz)
- **RAM:** 64 GB DDR4 (2 модуля по 32GB), без ECC
- **Disks:** 3× Samsung SSD 980 PRO 500GB NVMe
- C: 465GB (~375 свободно)
- D: 195GB (~92 свободно)
- E: 270GB (~215 свободно)
- **ИБП:** ❌ нет (`Win32_Battery` пуст) — основная причина крашей
## MSSQL
- **Версия:** SQL Server 2012 SP2 (build 11.2.5058) — ⚠ Extended Support EOL 2022-07-12
- **Instance:** `MSSQL11.MSSQLSERVER` (default)
- **Listening:** 0.0.0.0:1433 (доступен из NetBird, не только localhost)
- **Auth:** `dttb` НЕ имеет SQL-логина; `sa`-пароль не подобран
## Касса (НЕ на сервере)
- **KASSA3** — 192.168.1.18, активно подключается к 1С на порт 1560
- **KASSIRULICA2** — 192.168.1.99, вторая касса
- USB-фискальников и драйверов ККТ на сервере НЕТ → миграция не требует USB-redirect
## Локальные пользователи (RDP-юзеры 1С)
АртемК, ГорячевАЕ, Павел, ПальмованаН, ФирсовС + dttb (admin). БольшаковаЕН отключён.
## Известные проблемы
- **24+ грязных ребута 04.05.2026** (`Kernel-Power 41` все Bug=0, EventID 6008) → отключение питания
- **rmngr-loop после crash** — рецепт ниже
- ⚠ RDP 3389 открыт в Интернет
- ⚠ Антивируса нет
- AnyDesk запущен (parallel remote channel)
## 1С:Предприятие
Версия: **8.3.27.1606** x64. Текущее состояние служб (2026-05-07):
1. `1C:Enterprise 8.3 Server Agent` — Stopped, **Disabled** (бинарник 8.3.18 удалён)
2. `1C:Enterprise 8.3 Server Agent (x86-64)` — Running, Auto ★ рабочая
3. `RagentServer_8327` — Stopped, **Disabled**
**Запуск рабочей службы:**
```
"C:\Program Files\1cv8\8.3.27.1606\bin\ragent.exe" -srvc -agent
-regport 1541 -port 1540 -range 1560:1591
-d "C:\Program Files\1cv8\srvinfo"
```
**Кластер:** `473f3f9e-4aea-43bc-ac45-ec98da8700c7` "Локальный кластер" (Server1C:1541), **4 инфобазы** (имена → GUID нужно сверить):
- 00d417ca-... (служебные данные 7.3 GB)
- 426d93c8-... (4.8 GB)
- 688e50c3-... (15.2 GB) — самая большая
- 9e258b8f-... (12 GB)
⚠ Размеры выше — это `srvinfo/reg_1541` (полнотекстовые индексы + журналы), **не** размер SQL БД (тот неизвестен из-за SQL auth).
**Лицензии 1С:** HASP-ключа нет, `.lic` файлы не найдены → программная онлайн-лицензия с привязкой к HWID. ⚠ Перед миграцией — найти PIN-коды.
### Решено: конфликт служб при загрузке (2026-04-16)
**Проблема:** 3 службы с Automatic стартовали одновременно, боролись за порты 1540/1541.
- Служба 8.3.18 (x86) — бинарник удалён, падала с ошибкой "файл не найден"
- RagentServer_8327 — дубликат без параметров, таймаут на портах
- Рабочая: `1C:Enterprise 8.3 Server Agent (x86-64)` (8.3.27.1606)
**Решение:** отключены лишние службы (Disabled), оставлена только x86-64.
### Решено: rmngr-loop после грязного ребута (2026-05-07)
**Симптомы:** утром локальные пользователи в Бужарово жалуются на резко тормозящую 1С. Удалённое подключение к 1С через NetBird ни при чём — проблема видна и в локальной сети.
**Диагноз:**
- Сервер ушёл в crash в 09:05 (Event 41 Kernel-Power: rebooted without cleanly shutting down + EventLog 6008: previous shutdown was unexpected).
- После загрузки `rmngr.exe` (менеджер кластера 1С) держит ~1.7 ядра постоянно вместо штатных <2% в idle. `rphost`, `sqlservr`, диски, сеть — в норме.
- `rac.exe localhost:1540 cluster list` отваливается с "ошибка соединения с сервером" — admin-канал rmngr повис, кластер не отвечает на управление.
- `netbird.exe` параллельно крутит 1.4 ядра — это reconnect-loop как побочка crash, после ребута сам приходит в норму.
**Рецепт:**
1. Замерить дельту CPU через `Get-Process | %{$_.CPU}` за 5 секунд — если у `rmngr` >50% одного ядра в idle, диагноз подтверждён.
2. **Полный ребут сервера НЕ помогает** — после загрузки rmngr опять начинает жрать CPU. На свежезагруженном сервере uptime=0.6 min: rmngr уже на 178% ядра.
3. **Помогает рестарт службы:** `Restart-Service -Name '1C:Enterprise 8.3 Server Agent (x86-64)' -Force`. После рестарта rmngr возвращается к 3% ядра. Все активные сеансы пользователей вылетят — нужно их предупредить.
4. После рестарта может остаться орфан-процесс `ragent` от прошлого старта (не слушает 1540, висит). Прибить вручную: `Stop-Process -Id <pid> -Force`.
**Why:** причина рута rmngr-loop неясна — возможно повреждение кэша `srvinfo`, регресс 8.3.27.1606, или Disabled-служба `RagentServer_8327` мешает первому запуску ragent. Если повторится — смотреть `C:\Program Files\1cv8\srvinfo\reg_*\1Cv8FTLog\` на ошибки.
**Долгосрочно:** настроить несколько `rphost` в кластере (по одному на 8-12 сеансов) — сейчас один rphost на всех локальных юзеров = бутылочное горлышко.
## MS SQL Server (для server1c\RitmUl)
- **Instance:** `localhost` (default, MSSQL11 = SQL Server 2012 SP4)
- **SA / Qwer1122334400** (полные права на все БД)
- **БД:** `RitmUl` (~3.8 GB), также есть `Accounting`, `Retail_2021`, `Retail_2021demo`
- **Connection string:** `Server=localhost;Database=master;User Id=sa;Password=Qwer1122334400;`
## Бэкапы — native SQL, не Effector Saver
**Канон от 2026-05-08:** `BACKUP DATABASE` через SQL Server, не DT-выгрузка через Effector Saver. Подробности и причины — в [[decisions/2026-05-08-buzharovo-sql-native-backup]].
Команда:
```sql
BACKUP DATABASE [RitmUl]
TO DISK = N'C:\backup\RitmUl_<timestamp>.bak'
WITH FORMAT, INIT, COMPRESSION, COPY_ONLY, STATS = 5
```
- **Папка:** `C:\backup\` (на C: было 374 GB свободно на 2026-05-08)
- **Время:** ~2 сек на 3.8 GB БД
- **Размер:** ~30% от оригинала (3.8 GB → 1.1 GB сжатый)
- **Online:** не требует отключения пользователей, не требует cluster admin'а 1С
- **Скрипт:** `/root/clawd/scripts/sql_native_backup.py` на LXC 139 (severny-les bot)
## Кластер 1С — известные проблемы
### Cluster admin отсутствует, и его нельзя добавить
Серверная консоль 1С`Локальный кластер → Администраторы` показывает 0, но при попытке создать через GUI требует логин cluster admin'а (которого нет) — chicken-and-egg. Через `rac` и `V83.COMConnector` — то же самое. Agent admin (создан 2026-05-08, `admin/1qaz!QAZ` на уровне `(*)Server1C → Администраторы`) **не поднимает права на cluster operations**.
**Последствия:**
- Effector Saver задача `Бэкап 1Cv8` падает с `Администратор кластера не аутентифицирован (HRESULT=80004005)` → не может вызвать `TerminateSession` → не может получить эксклюзив на ИБ.
- Все cluster operations (просмотр сессий, kill сессий, блокировка соединений) недоступны через API.
**Что НЕ помогло:** SQL `KILL` сессий через sa — 1С rphost восстанавливает соединения за 1-2 мин, и persistent session_id (например `КулябинПИ 4514` от 12:55:42 в день 2026-05-08) reanimate.
**Workaround:** SQL native backup (см. выше) — обходит всю эту историю с эксклюзивом.
**Как лечить (не сделано, рискованно):** обнулить `C:\Program Files\1cv8\srvinfo\reg_1541\1CV8Clst.lst` → потеряются и админы и регистрация ИБ → перерегистрировать ИБ через SQL params (`SA/Qwer1122334400`, host `localhost`, db `RitmUl`).
### V83.COMConnector x64 зарегистрирован
2026-05-08 я через `regsvr32` зарегистрировал `C:\Program Files\1cv8\8.3.27.1606\bin\comcntr.dll` в `HKLM\SOFTWARE\Classes\V83.COMConnector` (только x64; x86 платформа на сервере не установлена). В Effector Saver вручную переключено на "64-разрядный V83.ComConnector" → `HRESULT=800401F3` ушёл.