-**Runtime-deps собраны (girar 426095 TESTED, 2026-07-19):** perl-CSS-Inliner + perl-GraphViz2 (+ perl-Badger/Test-Snapshot/HTML-Query) — отсутствовали в Сизифе,
подключаются **runtime-условно** (`require` в RT/Util.pm:326, RT/Graph/Tickets.pm), поэтому `make testdeps` их не видел.
Поставлены на rt-test (`epm install 426095`), верифицированы: тикет #69737 (HTML+CSS, падал на `Can't locate CSS/Inliner.pm`) теперь рендерится. Kanban git-alt #297. Ждёт публикации `gita commit 426095`.
-**Secure-cookie фикс применён (2026-07-19):** RT 6.0 дефолтит `WebSecureCookies=1` → на голом HTTP (rt-test) логин не прилипал. `Set($WebSecureCookies,0)` в local.pm. См. [[lesson_rt6_secure_cookies_http]]. Прод за HTTPS — дефолт ок.
-**БД:**`eter_rt` на **mysql.auth.dmz.etersoft.ru** (CT 219, **MySQL 5.5.43**, x86_64). Юзер `eter_rt`.
- ⚠️ **RT принципиально не работает с MySQL 8** (RT не использует quoted identifiers → SQL syntax error на `Groups`/`Principals` — см. баг 7693#c51-53). База сидит на древнем MySQL 5.5 именно поэтому.
-**RT 4.4.x — EOL** (последний 4.4 был 4.4.7). Наш 4.4.4 — 2019 год.
-**Непатченые CVE** на 4.4.4+: ALT bug 49420 (CVE-2022-25802, CVE-2023-41259, CVE-2023-41260) — статус **NEW**, не чинят.
- Мейнтейнер ALT-пакета (`hiddenman@`) давно не трогал.
-**Вывод:**`epm`-обновление даёт лишь косметику 4.4.4→4.4.5, CVE остаются. Актуальный RT (5.x/6.x) в ALT **отсутствует** — нужна собственная упаковка из апстрима или tarball-инсталляция.
## Ключевые риски и ограничения
1.**i686 → x86_64 нельзя через `epm release-upgrade`** (ALT release-upgrade не меняет архитектуру). Уход с 32-bit = **пересоздание контейнера**. Подтверждает гипотезу: recreate, а не релиз-апгрейд.
2.**БД.** На mysql.auth живёт **MySQL 5.5.43** (сама по себе EOL), RT держится на ней именно из-за несовместимости с MySQL 8. Решено: остаться на MySQL. Для тест-контура поднять отдельную инстансу (MariaDB 10.x из p11 — RT 4.4.5 с ней работает) и залить туда дамп боевой `eter_rt`. На проде БД-хост не меняется (CT 219 не трогаем).
3.**RT 4.4.4→4.4.5 — минорный бамп**, миграция схемы тривиальна/отсутствует (в отличие от мажорного 4→5). Но сохраняются исторические грабли окружения: исчезающие perl-модули (Data::GUID, Plack::FCGI, Locale::Maketext), пакет `rt` тянет apache, кастомные scrip/condition (`AnyTransactionSource`).
4.**Фронтенд TLS на azbykar (CT 102)** — отдельный хост, при переносе домена rt.pr надо отдельный server-блок (или wildcard). Корневой диск azbykar 16 ГБ — следить за логами.
## ✅ РЕШЕНО (2026-07-13)
-**Версия RT: остаёмся на 4.4.5** (4.4.4 → 4.4.5 через `epm` из p11/Sisyphus). Мажорного апгрейда на 5.x/6.x **нет** — их нет в репозитории ALT, а собственная упаковка признана нерациональной.
- ✏️ **Уточнение 2026-07-15:** целевая версия поднята до **4.4.7** (girar task [425459](#-проверка-girar-task-425459-rt-447--2026-07-15) проверен на rt-test). 4.4.7 лучше 4.4.5 тем, что чинит блокер `RT/Condition.pm:201` (см. ниже) — пересборка ALT-пакета / локальный патч больше не нужны. Цель — 4.4.7, как только попадёт в p11/Sisyphus.
-**БД: остаёмся на MySQL.** Миграции на PostgreSQL **нет**. RT 4.4.x работает с MySQL 5.5/5.7 и MariaDB 10.x.
-**Главный выигрыш обновления — не фичи RT** (бамп 4.4.4→4.4.5 косметический), а **уход с EOL-системы p9 + 32-bit i686** на актуальный p11/x86_64.
- Развилки «версия RT» и «MySQL vs PostgreSQL» (этап 2) — **закрыты**.
## 🚀 Боевой переезд (2026-07-16, в процессе)
План заказа: «доготовить всё кроме БД+аттачей, потом перенести, мигрировать схему, переключить nginx». Girar-таск с rt 4.4.7 — **425459** (НЕ 425450, исправлено заказчиком). Ставить избирательно: `epm install 425459/rt 425459/rt-mailgate` (не тянуть test-ветку).
**Новые объекты:**
-**CT 412** (`rt`, нода **border**, **10.20.30.196**) — новый app-контейнер. p11/x86_64, **systemd-networkd** (etcnet замаскирован). DNS `rt.dmz.etersoft.ru`. RT **4.4.7-alt1** + rt-mailgate (из task 425459), perl-Plack-FCGI/perl-FCGI. nginx 1.30 + postfix 3.8 + fetchmail 6.4 + mutt. U root — login-shell **fish** (ходить через `ssh root@... 'bash -c ...'` или `bash -s` heredoc).
-**CT 369** (`mariadb.dmz.etersoft.ru`, border, **10.20.30.195**) — новый выделенный БД-хост, **MariaDB 11.8.8**. Юзеры = как на mysql.auth: `root` (`6f1XQPLsfd`), `eter_rt`@% (`Veegi9sh`), `phpmyadmin` controluser. В phpMyAdmin (CT 240). Подробности: [reference_mysql_servers.md](../reference_mysql_servers.md).
**Prep CT 412 (завершено, сервисы disabled):** RT_SiteConfig (DatabaseHost→mariadb.dmz.etersoft.ru), AnyTransactionSource.pm, rt-fcgi@.{service,socket}+logging.conf, nginx rt server-block + `/etc/nginx/RT-fcgi` + `include/stat.conf`, postfix×5 (postmap canonical/transport + newaliases), fetchmailrc (600), check_oversize_mails(.list), logrotate.d/rt. `/var/www/webapps/rt` → symlink на `/usr/share/rt/html` (images alias). **cron×3 придержан** в `/root/rt-cron-hold.tar` (деплой в момент старта). Principal.pm — stock 4.4.7 (патч уже в upstream). В `/etc/nginx/sites-enabled.d/` есть чужой `remnawire.conf` (seti.eterfund.ru на :8443/unix-сокете) — с RT :80 не конфликтует, не трогать.
**FREEZE старого RT (CT 233, 18:33 MSK):** веб стоп + disabled (nginx, rt-fcgi@1-5.socket), cron убран в `/root/rt-migration-freeze/` (rt, rt-fetchmail, rtresolve + найденный **live**`rt.bak-20260603` — cronie НЕ пропускает `.bak-*` по расширению!). fetchmail нет, rt-бэкенд остановлен. Контейнер жив. **БД статична.**
**Cutover-шаги:** dump eter_rt с mysql.auth (4.4 ГБ, ✅ 1.6 ГБ gz, 35 таблиц) → import в mariadb.dmz → `rt-setup-database --action upgrade` на CT 412 → rsync attachments (✅ 4728 файлов/7574 каталогов) → старт rt-fcgi+nginx+postfix на CT 412 + деплой cron → repoint `proxy_pass` на **azbykar (CT 102, 10.20.30.23)** 10.20.30.53→10.20.30.196 → verify rt.etersoft.ru. Откат — вернуть proxy_pass; CT 233 держать.
## ✅ ПРОВЕРКА girar task 425459 (rt 4.4.7) — 2026-07-15
Проверено на rt-test (CT 183, gefest, 192.168.0.191, p11/x86_64). Полный отчёт + инвентарь для переноса — в комменте к [баге 12480](https://bugs.etersoft.ru/show_bug.cgi?id=12480)(2026-07-15).
-`epm install 425459`: rt-4.4.5-alt1_4 → **rt-4.4.7-alt1** (+rt-mailgate), встало чисто, sources.list не засорён (task-репо во временном apt-config, убирается сам).
- 🎯 **`RT/Condition.pm:201` — ИСПРАВЛЕНО в пакете 4.4.7** (`= undef;` с `;`). Блокер p11/Perl 5.38 снимается сам собой. Локальный патч/пересборка больше не нужны.
- rt-fcgi@1..4 стартуют без ошибок; логин, тикет #70317 (UTF-8), поиск — работают. Schema upgrade 4.4.5→4.4.6 прошёл (rc=0; один индекс `ObjectCustomFields(ObjectId)` не создался — апстрим-баг RT в именовании индексов на MySQL, некритично).
## 📋 Инвентарь для переноса (audit прода CT 233, 2026-07-15)
Что есть на проде, но **НЕ перенесено** в тест-контур (потеряется при recreate):
- ✅ **Патч ядра Principal.pm — РАЗОБРАН (2026-07-16):** etersoft-патч = **ровно 1 строка** — backtick вокруг `Groups`: `FROM \`Groups\`, Principals...`. Сравнение с upstream (git `bestpractical/rt` tag `rt-4.4.4`, raw `lib/RT/Principal.pm`) дало один-строчный diff. В upstream **4.4.7** тот же фикс сделан лучше через `QuotedTableName('Groups')` (→ backtick на MariaDB). **Портить не надо** — CT 412 оставлен на stock 4.4.7 `Principal.pm`. (`rpm -V` показывал `S.5....T.`, не conffile.)
-**Переключение прода = repoint `proxy_pass`** на новый контейнер (одна строка + reload), мгновенный откат. **Сертификаты мигрировать не надо.**
## Стратегия
Многоэтапно, через **тестовый контур `rt.pr.etersoft.ru`** (подход, предложенный заказчиком):
- клонируем данные, обновляем на копии, проверяем, и только потом трогаем боевой CT 233.
-**Recreate** (новый CT x86_64 p11), а не релиз-апгрейд i686.
-**Изолированная копия БД** — НИКОГДА не подключать тестовый RT к боевой `eter_rt` на mysql.auth (rt-setup-database мигрирует схему → убьёт прод).
- БД-хост (mysql.auth, CT 219) **не трогаем** — recreate касается только app-контейнера CT 233.
## Этапы
### Этап 1 — Тестовый контур rt.pr ✅ ВЫПОЛНЕНО (2026-07-13)
**Контур:** CT `rt-test` на ноде **gefest** (НЕ enceladus — там нет места/шаблона), IP **192.168.0.191** (vmbr0 office LAN — ⚠️ ошибка, тест-серверы должны быть на 10.20.30.x, см. [feedback_test_servers_on_dmz.md](../feedback_test_servers_on_dmz.md); оставлено как есть по указанию). ОС ALT **p11 x86_64**, RT **4.4.5-alt1_4**, MariaDB **11.8.8** (локально в CT, дамп боевой `eter_rt`). Доступ: http://rt.pr.etersoft.ru/ (внутр. зона; root, temp-pass `Rt-test-2026` — тестовая копия БД).
**Верификация — всё работает после фикса ниже:** логин (302, сессия), просмотр тикета #70317 (UTF-8 ок), поиск по статусу + FTS-поиск по контенту (<1с), Create+Correspond (write path), scrips (4/5/6/7/24 грузятся и выполняются), ExternalStorage (чтение вложений ок). Данные мигрированы без потерь.
### 🔴 БЛОКЕР: RT/Condition.pm:201 — fatal на Perl 5.38 (p11)
`/usr/share/perl5/RT/Condition.pm` строка **201** — **пропущена точка с запятой**:
```perl
$self->{'TemplateObj'}=undef# ← НЕТ ';'
$self->{'TicketObj'}=undef;
```
На **Perl 5.28** (p9/прод) это парсится (warn), на **Perl 5.38** (p11) — **fatal compile error**`Can't modify undef operator in scalar assignment` → не грузится базовый `RT::Condition` → **падают ВСЕ scrip-условия** (AnyTransaction, OwnerChange, SLA_*, ...). На тесте фикшено одной точкой (`sed -i "201s/=undef$/=undef;/"`), после этого scrips работают. **Тот же баг в боевой RT 4.4.4** — просто скрыт старым Perl.
→ Для прода фикс должен идти через **пересборку ALT-пакета** (апстрим-баг RT + упаковка на p11). См. «Решения». На тесте применён локальный патч (`*.orig-20260713` бэкап).
> ✅ **РЕШЕНО 2026-07-15:** в rt **4.4.7** (girar task 425459) баг исправлен в самом пакете — нормальный `= undef;` с `;`. Переход на 4.4.7 снимает блокер полностью; пересборка ALT-пакета и локальный патч больше **не нужны**. См. [проверку 4.4.7](#-проверка-girar-task-425459-rt-447--2026-07-15).
### ⚙️ Настройки после миграции (обязательно для прода)
-**MariaDB:** после загрузки дампа статистика инода пустая (`data_length=0` для таблиц с сотнями тыс. строк) → full scans, поиск/просмотр висят 30+с. Лечится: `mariadb-check --analyze eter_rt` + `innodb_buffer_pool_size=2G` (`/etc/my.cnf.d/zz-rt-tuning.cnf`). После этого — sub-second.
-**perl-Plack-FCGI + perl-FCGI** — пакет `rt` их НЕ тянет, без них rt-fcgi падает (`Can't locate Plack/Handler/FCGI.pm`).
-**MTA** — на тесте нет sendmail (`Could not send mail`), scrips почту композят, но не отправляют. На проде MTA есть.
### Этап 1 — исходный план (минимум: воспроизвести боевой функционал на новой ОС)
1.**DNS:** завести `rt.pr.etersoft.ru` (внутренняя зона → IP нового тест-CT; позже публичный TLS через azbykar или отдельный server-блок). См. skill `/dns`.
2.**Создать CT** x86_64 **p11** на enceladus (клон template-CT или новый из ostemplate). Имя напр. `rt-test` / `rt.pr`. СНАЧАЛА IP, ПОТОМ старт ([reference_create_lxc_container_pve.md](../reference_create_lxc_container_pve.md)). 2 vCPU / 3–4 ГБ RAM.
3.**Поднять изолированную копию БД:** MariaDB 10.x (из p11) в тест-CT (или отдельный CT), залить туда свежий дамп `eter_rt` с mysql.auth (`mysqldump --single-transaction`, `--routines`). **Не боевой mysql.auth.** RT 4.4.5 с MariaDB 10.x работает.
4.`epm install rt rt-mailgate` (даст 4.4.5) + perl-зависимости по мере вылета (Data::GUID, Plack-FCGI, Locale-Maketext*…).
7.`rt-setup-database --action upgrade` на копии БД (4.4.4→4.4.5 — мелко, но прогнать).
8. fetchmail — НЕ подключать к боевой поддержке (тестовая очередь/ящик).
9.**Проверить:** логин, список тикетов, ответ с вложением, поиск, права, кастомные scrips. Смотреть `journalctl -u 'rt-fcgi@*'`, `/var/log/rt/rt.log`.
### Этап 2 — ~~Решение по версии RT~~ ЗАКРЫТ (2026-07-13)
Решено: **остаёмся на RT 4.4.5 + MySQL** (5.x/6.x нет в репозитории ALT, собственная упаковка нерациональна; PostgreSQL-миграция не нужна). Этап 2 как точка выбора — отпал.
### Этап 2b — (опционально) работа с CVE
На 4.4.5 остаются CVE (ALT bug 49420: CVE-2022-25802, CVE-2023-41259, CVE-2023-41260). Если критично — оценить бэкпорты патчей апстрима (4.4.5→4.4.7) вручную поверх пакета. По умолчанию **не делаем** (RT за корпоративным периметром, риск низкий).
### Этап 3 — Боевое обновление CT 233
**Предварительное условие:** ~~зафиксировать блокер Condition.pm:201~~ — ✅ **снято** переходом на rt 4.4.7 (girar task 425459, см. [проверку](#-проверка-girar-task-425459-rt-447--2026-07-15)). Остаётся: дождаться попадания 4.4.7 в p11/Sisyphus (или ставить из task-репо).
**Перед recreate — вытащить из прода весь [инвентарь для переноса](#-инвентарь-для-переноса-audit-прода-ct-233-2026-07-15)** (Principal.pm diff, postfix×5, fetchmailrc, cron×3, check_oversize_mails, logrotate, ExternalStorage path) и сложить в репозиторий для воспроизводимости. На тест-контуре этого нет — потеряется.
По итогам этапов 1–2:
-**Recreate** (i686→x86_64 нельзя release-upgrade): новый CT x86_64 p11 (как rt-test, но боевой конфиг: домен rt.etersoft.ru, postfix, fetchmail, cron, ExternalStorage) → миграция БД+attachments → **переключить `proxy_pass` на azbykar (CT 102)** на новый IP → декомисс CT 233.
- 🔄 **БД — отдельный MySQL, НЕ в контейнере** (решение заказчика 2026-07-15; тест-контур держит MariaDB локально — это только для изоляции теста). **Открытый вопрос:** переиспользовать `mysql.auth` (CT 219, MySQL 5.5.43 — сам EOL, shared с другими сервисами) или поднимать новый выделенный хост. RT 4.4.x работает с MySQL 5.5/5.7 и MariaDB 10/11, но **НЕ с MySQL 8** (баг 7693#c51 — unquoted identifiers).
-**Cutover** = repoint `proxy_pass http://<new-CT>:80` на azbykar + reload; откат — вернуть строку. Сертификаты не трогать.
- Окно работ, согласование с support/ТП (RT — рабочий инструмент, простой критичен).
- ⚠️ **Перед любыми изменениями — PVE snapshot** (на rt-test перед апгрейдом 4.4.7 снимок не делался — упущение).
## Связанные задачи
-**Бага 12480** (REOPENED, «Обновить RT на рабочем сайте», lav@) — исторический контекст апгрейда 3.8→4.4 (2019). Решить: вести работу в ней или завести **новую багу** под текущий масштаб (p9→p11, recreate, RT-версия).
-**Бага 7693** (ASSIGNED, поддержка rt.etersoft.ru) — ongoing.
-**ALT bug 49420** — CVE на RT 4.4.4 (внешний трекер, статус NEW).
-**Kaiten #66499560** — интеграция виджета `/api/support/widget` в карточку тикета (Scrip + iframe + HMAC, Perl/Mason override). Просит dev-RT контур → **этап 1 его даёт**. Но: мажорный апгрейд RT (B) перепишет Mason-шаблоны → override виджета делать на финальной версии RT. Координировать: виджет — после фиксации версии RT.
description:PVE на gefest — добавить настоящий Kerberos SSO (SPNEGO) для веб-логина; пользователь настраивает сам, потом проверить
metadata:
type:project
---
**Задача:** включить настоящий Kerberos SSO (SPNEGO/GSSAPI) автовход в веб-морду PVE на **gefest** (192.168.0.13, кластер MIAC). Пользователь (Vitaly) настраивает сам; моя роль — **проверить после**.
**Контекст (состояние на 2026-07-24):**
- AD = **ETERSOFT.RU**, DC = dc.etersoft.ru (10.20.30.20), Kerberos :88, LDAP :389 (SRV-записи есть).
- gefest **уже в AD через winbind** (`realm list`: `client-software: winbind`, `login-formats: ETERSOFT\%U`), есть `/etc/krb5.keytab`. sssd тоже active/enabled (гибрид/legacy).
- В PVE сейчас realm только `pam` + `pve`. Доменные юзеры сидят как `user@pam` (aalyaev@pam, lav@pam …) — `pam` уже проверяет пароли по AD (PAM→winbind→Kerberos). Т.е. AD-аутентификация УЖЕ работает, просто не как SSO.
-**Важно:** PVE из коробки НЕ поддерживает SPNEGO в web UI → настоящий SSO требует reverse-proxy (nginx/apache + GSSAPI) спереди PVE, либо иной обвязки. Уточнить у пользователя архитектуру когда скажет «готово».
**Как проверять (когда пользователь попросит):**
1. У клиента валидный TGT: `klist` (на lav/builder64 — `kinit lav@ETERSOFT.RU`).
2.`curl --negotiate -u : http(s)://<pve-proxy-url>/` — должен вернуть ответ без падения в 401/логин-форму.
3. Браузер: `network.negotiate-auth.trusted-uris` (Firefox) / group policy (Chromium) на хост PVE-прокси.
4. Падение в форму ввода пароля = SSO НЕ работает (откат на обычную аутентификацию).
5. Уточнить у пользователя: какой URL/порт прокси, на каком хосте он крутится (gefest? отдельный контейнер?), доступ снаружи или только office-LAN.
