oleg/knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
437ba231ad399a7c77e7d02799ec82cefcbfb1ce
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

11 KiB
Raw Blame History

date, updated, type, tags
date updated type tags
2026-04-17 2026-05-07 project
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.

Команда:

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 ушёл.

Reference in New Issue View Git Blame Copy Permalink