Дмитрий
c370ff8248
Проверено на боевом 25.06: config.php = ubuntu:www-data mode 775, www-data ЧИТАЕТ его через группу, портал HTTP 200 — реального дефекта НЕТ. Квирк «лечили» несколько раз, гонясь за строгой проверкой «владелец == www-data», тогда как важна читаемость. Две первопричины повтора закрыты: 1. deploy/redeploy.sh: optimize перенесён в КОНЕЦ (после chown -R ubuntu:www-data bootstrap/cache). Раньше optimize шёл ДО chown'а → chown переписывал владельца свежего config.php обратно на ubuntu. Теперь кэши пишутся после chown и остаются www-data:www-data. 2. .claude/agents/prod-deploy-validator.md П1: критерий сменён на ЧИТАЕМОСТЬ www-data (sudo -u www-data test -r config.php) вместо строгого владельца. Владелец ubuntu при группе www-data+775 больше НЕ даёт ложный NO-GO. Свежесть (mtime ≥ .env, квирк 104) сохранена. Описание квирка 107 и формат рапорта обновлены. Прод не трогали — он здоров. После следующего redeploy config.php станет www-data-owned. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
deploy/
Скрипты применения обновлений на боевом сервере liderra.ru.
redeploy.sh
Server-side половина деплоя. На боевом лежит в /var/www/liderra/redeploy.sh
(вне репозитория Laravel). Здесь — каноническая копия для версионирования
и аудита.
Workflow деплоя:
-
Локально — собрать архив кода + Vite-сборку:
git archive HEAD app/ db/ | gzip > /tmp/deploy-code.tgz tar czf /tmp/deploy-build.tgz -C app/public build/ -
scp обоих архивов на сервер.
-
На сервере — распаковать в
/var/www/liderra/app/, выставить владельцаwww-data:www-data, запуститьbash /var/www/liderra/redeploy.sh.
NB: redeploy.sh НЕ делает git pull — он рассчитан на то, что код
уже залит scp. Если запустить без предварительного scp — будет no-op
(composer install / migrate / optimize / restart на той же кодовой базе).
Квирк 107 (фикс встроен): строка sudo -u www-data php artisan optimize
обязательна. Без неё optimize запускался от ubuntu → bootstrap/cache/config.php
с владельцем ubuntu → php-fpm (под www-data) не мог прочитать → 503 на всём
портале. Инцидент 24.05.2026 03:46 UTC, портал лежал 18 минут.
Грабли composer-прав (фикс встроен, инцидент 23.06.2026): vendor/ принадлежит
www-data, а redeploy.sh бежит от ubuntu. Голый composer install падал
autoload_classmap.php: Permission denied, и из-за set -e скрипт рвался ДО optimize
и рестарта → новый код на диске, classmap новых классов НЕ пересобран → прод 500.
Фикс: sudo env COMPOSER_ALLOW_SUPERUSER=1 composer install … + sudo chown -R www-data:www-data vendor.
Также: при ручном восстановлении кэши надо пересобирать ДО рестарта php-fpm —
opcache держит старые до перезапуска (затяжной 500, пока fpm не рестартнут ПОСЛЕ кэшей).
Грабли миграций crm_migrator (инцидент 19.06 + 23.06): таблицы, принадлежащие
crm_migrator (напр. saas_transactions), штатной .env-ролью НЕ альтерятся
(must be owner). Применять миграцию ВРУЧНУЮ под sudo -u postgres psql ДО запуска
redeploy.sh + INSERT INTO migrations (migration, batch) VALUES ('<имя_без_php>', <batch>).
Тогда php artisan migrate --force в скрипте = no-op. Иначе set -e порвёт деплой.
Расхождение с боевым: если правится этот файл — синкать на боевой (scp + проверка хеша). Боевой = source of truth для исполнения, репо = source of truth для рецепта.