> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/ustanovka-i-obnovlenie/ustanovka-produkta.md). # Установка продукта Эта инструкция описывает первичную установку iEXExchanger на новый Linux-сервер без панели управления. Выполнить её может владелец обменного пункта, системный администратор или технический специалист с доступом к серверу. **Installer** — программа установки iEXExchanger. Она подготавливает сервер, устанавливает необходимое окружение, создаёт базы данных, загружает начальные данные и настраивает сайт, HTTPS, фоновые службы и резервное копирование. Совместимые версии компонентов определяются поставкой. Устанавливать или подбирать их вручную не требуется. После установки доступны три инструмента: * **`iexctl`** — команда для проверки и обслуживания установленной системы. * **Updater** — инструмент применения последующих обновлений iEXExchanger. * **Update Agent** — фоновая служба, через которую административная панель взаимодействует с системой обновлений на сервере. Все серверные команды в этой инструкции выполняются от `root` — администратора сервера. Команды для вашего компьютера отмечены отдельно. {% hint style="danger" %} Первичная установка предназначена только для чистого сервера. Не запускайте её поверх действующего iEXExchanger, FASTPANEL, другого сайта, существующих баз данных или настроенного серверного окружения. Обновление и перенос работающего проекта выполняются по отдельным инструкциям. {% endhint %} ## Перед началом установки {% stepper %} {% step %} ### Обозначения доменов В инструкции используются два адреса: ``` https://ваш_домен https://app.ваш_домен ``` `https://ваш_домен` — основной домен **Frontend**, на котором открывается клиентский сайт обменного пункта. `https://app.ваш_домен` — технический поддомен **Backend**. На нём находятся административная панель, API и другие серверные функции iEXExchanger. **API** — интерфейс, через который клиентский сайт и другие разрешённые приложения обращаются к серверным функциям. В командах и `install.yaml` заменяйте эти обозначения фактическими доменами проекта. Домены в `install.yaml` указываются без `https://`, портов и путей: ``` ваш_домен app.ваш_домен ``` Адрес административной панели содержит дополнительный путь после домена Backend. Точный адрес для входа Installer сохранит после установки — придумывать или подбирать его самостоятельно не нужно. {% endstep %} {% step %} ### Требования к серверу {% content-ref url="/pages/RjtzBZHtqwFTm8nJo8p8" %} [Системные требования](/ustanovka-i-obnovlenie/sistemnye-trebovaniya.md) {% endcontent-ref %} Для установки необходимы: * поддерживаемая операционная система и архитектура процессора; * достаточные ресурсы процессора, оперативной памяти и свободного места на диске; * полноценный доступ `root`; * публичный IPv4-адрес; * возможность управлять DNS-записями домена; * доступные порты SSH, HTTP и HTTPS; * доступ сервера к интернету для загрузки необходимых компонентов. IPv6 используйте только при его полноценной настройке и доступности на сервере. **SSH** — защищённое подключение к командной строке сервера. HTTP и HTTPS используются для открытия сайта и работы сертификата. Разрешите входящие подключения к фактическому SSH-порту и портам `80` и `443` в сетевом экране хостинга. Локальный сетевой экран Installer настроит во время установки. Installer дополнительно проверит платформу и ресурсы командами `checklist` и `plan`. Не продолжайте установку, если платформа отмечена как неподдерживаемая или обязательных ресурсов недостаточно. Не устанавливайте вручную Nginx, PHP, PostgreSQL, Redis, Node.js, PM2, Supervisor или FASTPANEL. Требуемое серверное окружение создаёт Installer. {% endstep %} {% endstepper %} ### Подготовьте данные До начала установки подготовьте: * IP-адрес сервера; * пользователя `root`; * порт SSH; * способ авторизации по SSH — пароль или ключ; * основной домен Frontend; * технический поддомен Backend; * архив лицензии; * код лицензии, если он предоставлен отдельно; * контрольные суммы скачанных файлов; * свой email для сертификата Let's Encrypt, если хотите указать его при выпуске. Email не является обязательным условием выпуска сертификата. Порядок заполнения этого поля описан в разделе «Настройте HTTPS». {% hint style="warning" %} Проверьте домены до активации лицензии и установки. Опечатка может привести к ошибке проверки лицензии, DNS или HTTPS. {% endhint %} ### Подготовьте DNS DNS-записи связывают доменные имена с сервером. Создайте их в сервисе, который управляет DNS вашего домена, до проверки плана установки. {% content-ref url="/spaces/uyjsNtEAtO6Sby8CHWyD/pages/YcOQhy8Pn5VQ52X582gd" %} [Настройка DNS домена](/help-center/upravlenie-serverom/nastroika-dns-domena.md) {% endcontent-ref %} {% content-ref url="/spaces/uyjsNtEAtO6Sby8CHWyD/pages/43DGhWN1Ki1aj8RrllVR" %} [Настройка DNS](/help-center/administrirovanie/seti-i-bezopasnost/cloudflare/nastroika-dns.md) {% endcontent-ref %} Для основного домена и поддомена `app` создайте записи типа **A** с IPv4-адресом нового сервера. Запись типа **AAAA** нужна только при использовании IPv6. Добавляйте её, если этот адрес настроен на сервере и доступен извне. Устаревшие A- или AAAA-записи могут направлять часть посетителей на другой сервер и мешать проверке HTTPS. Если нужен дополнительный адрес с `www`, создайте для него DNS-запись и добавьте имя в `spec.domains.frontendAliases`. Installer не создаёт DNS-записи и не добавляет `www` автоматически. После изменения записей дождитесь, пока новые адреса станут доступны через публичный DNS. #### Прямое подключение При прямом подключении посетители обращаются непосредственно к вашему серверу. В `install.yaml` для параметра `spec.preflight.dnsMode` используется значение: ```yaml dnsMode: direct ``` Installer проверяет, что публичные адреса доменов совпадают с адресами сервера. Параметр `spec.nginx.trustedProxyCidrs` в этом случае остаётся пустым: ```yaml trustedProxyCidrs: [] ``` #### Cloudflare или другой прокси-сервис При включённом проксировании посетители сначала обращаются к Cloudflare или другому промежуточному сервису, который передаёт запросы вашему серверу. Поэтому публичный DNS может показывать адрес сервиса, а не IP вашего сервера. Для такой схемы используется: ```yaml dnsMode: proxy ``` Публичные DNS-записи всё равно обязательны. Этот режим разрешает адреса прокси-сервиса при проверке DNS, но не подтверждает правильность всех его настроек. В `spec.nginx.trustedProxyCidrs` укажите актуальные диапазоны IP-адресов используемого сервиса. **CIDR** — формат записи диапазона адресов: адрес сети и число после `/`. Эти диапазоны позволяют Nginx доверять сведениям о посетителе, полученным от вашего прокси-сервиса. Используйте только официальный список провайдера. IP самого сервера сюда добавлять не нужно. Для Cloudflare актуальные диапазоны опубликованы на странице [IP Ranges](https://www.cloudflare.com/ips/). Порядок первоначальной настройки HTTPS при использовании Cloudflare приведён в разделе «Настройте HTTPS». ### Поддержка и услуга установки В документации приведён порядок самостоятельной первичной установки. Если вам требуется установка специалистами, повторная установка, перенос системы или подготовка дополнительного сервера, уточните действующие условия перед заказом. Подробнее: [Услуги iEXExchanger](https://iexexchanger.com/services). *** ## Установка с помощью ИИ-агента Этот вариант предназначен для технического ИИ-агента, которому разрешено подключаться к новому серверу, выполнять команды от `root`, работать с файлами и проверять сайт через браузер. До запуска подготовьте установочные файлы и данные из раздела «Перед началом установки». {% content-ref url="/pages/U0YPvPyzY7nFVhyGTJFI" %} [Работа с AI](/nachalo-raboty/rabota-s-ai.md) {% endcontent-ref %} {% prompt description="Установить iEXExchanger на чистый сервер" icon="rectangle-terminal" openInAIProviders="true" defaultExpanded="partial" %} ```markdown # Задача Установи iEXExchanger на чистый сервер штатным Installer и выполни проверки после установки. Используй актуальную инструкцию: https://docs.iexexchanger.com/ustanovka-i-obnovlenie/ustanovka-produkta Все установочные файлы загружены в `/home`. Найди Installer, полные архивы Backend и Frontend, архив лицензии и официальные контрольные суммы. Не запрашивай имена файлов, версии и значения, которые можно достоверно определить по серверу и содержимому поставки. # Данные Доступ к серверу: УКАЖИТЕ IP, SSH-ПОРТ, ПОЛЬЗОВАТЕЛЯ И СПОСОБ АВТОРИЗАЦИИ. Frontend: https://ваш_домен Backend: https://app.ваш_домен Код лицензии: ПЕРЕДАЙТЕ ЗАЩИЩЁННЫМ СПОСОБОМ ИЛИ УКАЖИТЕ ПУТЬ К ЗАЩИЩЁННОМУ ФАЙЛУ. Email для сертификата: ИСПОЛЬЗУЙТЕ ПЕРЕДАННЫЙ ВЛАДЕЛЬЦЕМ АДРЕС ИЛИ ПУСТОЕ ЗНАЧЕНИЕ. # Правила Работай только на указанном сервере и в рамках первичной установки. Используй обычную установку Installer на сервер. Не устанавливай Docker или FASTPANEL для выполнения этой задачи. Не подбирай и не закрепляй собственные версии PHP, Node.js, PostgreSQL и других компонентов. Сохраняй совместимые настройки из полного install.example.yaml поставки. Не настраивай вручную Nginx, базы данных, Redis, службы приложения или Scheduler: это выполняет Installer. Не импортируй SQL, не запускай php artisan migrate, Product Updates, Composer, npm или сборку приложения отдельно от штатной установки. Не удаляй существующие данные и службы ради прохождения проверок. Если сервер не является чистым, остановись и сообщи о найденных конфликтах. Не выводи в ответы и журналы пароль SSH, код лицензии, содержимое .env, реквизиты администратора, cookie и приватные ключи. Не объявляй проверку выполненной, если она была недоступна или не запускалась. # Выполнение 1. Подключись по SSH. Подтверди адрес сервера, доступ root, поддерживаемые ОС и архитектуру. Проверь отсутствие действующего приложения и конфликтующего окружения. 2. Изучи `/home`. Найди `iex-installer-linux.zip`, обязательный `iex-installer-linux.zip.sha256`, один Backend full, один Frontend full и один архив лицензии. Допустимы стандартные имена архивов и варианты `install_backend_<суффикс>.zip`, `install_frontend_<суффикс>.zip`. Не принимай архив обновления за полный установочный архив. Если файл отсутствует или найдено несколько кандидатов одного назначения, сообщи, что нужно исправить. 3. Подготовь `unzip`, `ca-certificates` и редактор, если они отсутствуют. Проверь внешнюю контрольную сумму Installer и официальные SHA-256 остальных архивов. Не создавай собственные суммы вместо официальных. 4. Проверь, не существует ли прежняя распаковка или начатая установка. Не перезаписывай её. Для новой подготовки распакуй Installer в `/home/installer`, проверь внутренний `SHA256SUMS` и выполни `iex-installer version`. 5. Если отдельный код лицензии предоставлен, сохрани его в `/root/iex-license/license-key`. Используй каталог root:root с правами 0700 и umask 077 до создания файла. Файл должен принадлежать root:root и иметь права 0600. Не помещай код в командную строку, YAML или отчёт. Если отдельного кода нет и он включён в Backend, сохрани штатное значение. 6. Создай `/home/installer/install.yaml` из полного `install.example.yaml`. Укажи фактические домены без схемы и путей, название проекта, текущий SSH-порт и ссылку на файл кода лицензии, если он создан. Не заменяй конфигурацию сокращённым документом и не создавай второй spec. 7. Проверь публичные DNS-записи. Используй dnsMode: direct для прямого подключения или proxy для подтверждённой схемы с прокси-сервисом. Проверяй также дополнительные доменные имена и IPv6. Не продолжай, если запросы направляются на неизвестный или прежний сервер. 8. Для Cloudflare можно первоначально выпустить сертификат в DNS only, заранее задав proxy в YAML, если затем планируется включить проксирование. После выпуска сертификата проверь Full (strict), включение прокси и публичную доступность. Для trustedProxyCidrs используй только официальные диапазоны фактически используемого сервиса. 9. Настрой штатный HTTPS через Let's Encrypt. Для tls.email используй переданный владельцем реальный email или пустую строку "". Не оставляй адрес-заглушку и не запрашивай email как обязательное условие. При явно выбранном готовом сертификате используй provider: files, проверь сертификат и ключ и отдельно укажи порядок продления. 10. Сохрани resourceMode: enforce, автоматический подбор ресурсов, включённые HTTPS, сетевой экран и резервное копирование. Не изменяй generated://. Не обходи недостаток ресурсов переводом ошибок в предупреждения. 11. Выполни config show, config validate, checklist и plan. Изучи ошибки и предупреждения. Если сервер чистый и Installer разрешает install, запусти одну штатную установку с подготовленным конфигурационным файлом. 12. При сбое сначала выполни status, reports show install и checklist. Следуй строке «Следующее действие». Используй resume только для совместимого незавершённого запуска с тем же Installer, YAML и архивами. При retry after от Let's Encrypt дождись указанного времени UTC с запасом. Не удаляй состояние операции, базы или журналы. 13. После успешной установки выполни status, обычный verify и verify --public-endpoints. По отчёту подтверди host.postgresql.import.main, host.postgresql.import.pulse, backup.initial-verified, artisan.product-updates.apply и controltools.install. 14. Проверь iexctl, iexctl doctor, iexctl services status, iexctl services verify и iex-updater status. Убедись, что Update Agent включён и активен, а systemd не содержит служб с ошибкой. Не заменяй управляющие инструменты вручную. 15. Проверь CRON, файл Scheduler, результат установочного запуска Scheduler и отсутствие дублирующего таймера. Для Let's Encrypt проверь certbot.timer. Проверь клиентский сайт по HTTPS. 16. Получи точный URL административной панели из защищённого файла Installer. Выполни реальный вход, обнови страницу и открой другой раздел. Не раскрывай реквизиты в отчёте. Если проверка через браузер недоступна, явно укажи, что она не выполнена. 17. После завершения установки создай новую копию командой `iexctl backup run`. Выполни `iexctl backup status`, `iexctl --timeout 12h backup verify --full` и `iexctl --timeout 12h backup restore-test`. Проверь расписание резервного копирования. Укажи предел проверки: restore-test извлекает файлы и проверяет структуру дампов, но не импортирует базы в отдельный PostgreSQL. 18. Проверь, настроено ли хранение копий вне сервера и сохранён ли ключ восстановления отдельно. Если внешнее хранение не настроено, укажи это как незавершённую подготовку к работе с реальными данными. Не публикуй ключ или резервные данные. 19. Выполни `iexctl registration sync` и `iexctl registration status`. Различай временную недоступность внешнего сервиса и отказ из-за лицензии или домена. Не скрывай ошибки. 20. До перезагрузки проверь второе SSH-подключение с тем же портом. Перезагрузи сервер до ввода проекта в работу. После восстановления SSH повтори проверки Installer, системных служб, публичных адресов, iexctl, Updater, резервного копирования, клиентского сайта и входа администратора. 21. Подготовь диагностический комплект командой `iexctl --format json support bundle`. Проверь его контрольную сумму и права 0600. Перед передачей убедись, что он не содержит секретов, дампов, необработанных полных журналов или реквизитов администратора. # Результат Верни отчёт без секретных данных: - итог установки: PASS, WARN или FAIL; - Run ID; - фактически установленная версия продукта и Installer; - результаты импорта основной базы и базы Pulse; - результат Product Updates; - результаты внутреннего и публичного verify; - состояние служб, Scheduler, Updater и Update Agent; - результат проверки HTTPS и продления сертификата; - результат создания копии завершённой установки; - результаты проверки целостности и извлечения копии с указанием границ restore-test; - состояние внешнего хранения резервных копий; - результат регистрации сервера; - результат реального входа администратора; - результаты проверок после перезагрузки; - путь и SHA-256 диагностического комплекта; - оставшиеся проблемы и невыполненные проверки. Используй PASS только после успешного выполнения обязательных проверок. Если остались ошибки, недоступные проверки или незавершённые действия, прямо укажи их и не объявляй систему полностью готовой. ``` {% endprompt %} *** ## Подготовка установочных файлов {% stepper %} {% step %} ### Скачайте файлы В личном кабинете откройте нужную лицензию и найдите блок **«Релизы и файлы лицензии»**. {% content-ref url="/pages/hSsHgydQTzax5c06kVsd" %} [Файлы лицензии и релизы](/nachalo-raboty/faily-licenzii-i-relizy.md) {% endcontent-ref %} Для первичной установки подготовьте: ``` iex-installer-linux.zip iex-installer-linux.zip.sha256 iexexchanger_backend_full.zip iexexchanger_frontend_full.zip АРХИВ_ЛИЦЕНЗИИ.zip ``` Backend и Frontend также могут иметь имена: ``` install_backend_<суффикс>.zip install_frontend_<суффикс>.zip ``` Переименовывать такие архивы не требуется. Имя архива лицензии может отличаться. Используйте ZIP, предоставленный для вашей лицензии. **`full`** означает полный комплект для первичной установки. Архив обновления предназначен для уже установленной системы и для этой инструкции не подходит. Backend и Frontend должны относиться к одному выпуску. Лицензионный архив должен соответствовать вашему домену и быть совместим с выбранным выпуском. Совместимость лицензии нельзя определять только по имени ZIP-файла. Не распаковывайте Backend, Frontend и архив лицензии самостоятельно. Отдельно скачивать `iexctl`, Updater или Update Agent не нужно. Installer проверяет управляющие инструменты, включённые в поставку, и устанавливает совместимый комплект. Если комплект неполный или несовместимый, установка остановится с пояснением. Не обходите такую проверку ручной заменой файлов. **SHA-256** — контрольная сумма, рассчитанная по содержимому файла. Сравнение с официальным значением позволяет обнаружить повреждение или подмену файла. Сохраните контрольные суммы, показанные в личном кабинете. {% hint style="warning" %} Файл `iex-installer-linux.zip.sha256` нужен для внешней проверки архива Installer. Если его нет в загрузках, получите полный официальный комплект. Не создавайте собственную контрольную сумму вместо отсутствующей официальной: такая проверка не подтвердит происхождение скачанного архива. {% endhint %} {% endstep %} {% step %} ### Загрузите файлы на сервер Загрузите все подготовленные файлы в каталог: ``` /home ``` Для передачи можно использовать **SFTP** — защищённую передачу файлов через SSH. Подключитесь к серверу с его IP-адресом, пользователем `root` и фактическим SSH-портом. Если используете команду `scp`, откройте терминал **на своём компьютере** и перейдите в каталог со скачанными файлами. {% content-ref url="/spaces/uyjsNtEAtO6Sby8CHWyD/pages/cCEoFDjTDIufy3NUEakd" %} [Подключение к серверу по SSH](/help-center/upravlenie-serverom/podklyuchenie-k-serveru-po-ssh.md) {% endcontent-ref %} Выполните: ```bash scp -P ПОРТ_SSH \ iex-installer-linux.zip \ iex-installer-linux.zip.sha256 \ "BACKEND_FULL.zip" \ "FRONTEND_FULL.zip" \ "АРХИВ_ЛИЦЕНЗИИ.zip" \ root@IP_СЕРВЕРА:/home/ ``` Замените: * `ПОРТ_SSH` — фактическим портом SSH; * `IP_СЕРВЕРА` — IP-адресом сервера; * `BACKEND_FULL.zip` — именем скачанного Backend-архива; * `FRONTEND_FULL.zip` — именем скачанного Frontend-архива; * `АРХИВ_ЛИЦЕНЗИИ.zip` — именем лицензионного архива. Для стандартного SSH-порта `22` параметр `-P ПОРТ_SSH` можно убрать. В команде `scp` параметр порта `-P` пишется с заглавной буквы. {% endstep %} {% step %} ### Подключитесь к серверу Откройте терминал **на своём компьютере**. {% content-ref url="/spaces/uyjsNtEAtO6Sby8CHWyD/pages/cCEoFDjTDIufy3NUEakd" %} [Подключение к серверу по SSH](/help-center/upravlenie-serverom/podklyuchenie-k-serveru-po-ssh.md) {% endcontent-ref %} Для нестандартного SSH-порта выполните: ```bash ssh -p ПОРТ_SSH root@IP_СЕРВЕРА ``` Для стандартного порта: ```bash ssh root@IP_СЕРВЕРА ``` В команде `ssh` порт задаётся строчной буквой `-p`. После подключения проверьте, что вошли на нужный сервер: ```bash hostname whoami ``` `hostname` покажет имя сервера, а `whoami` должен вывести: ``` root ``` Все последующие серверные команды выполняются в этой SSH-сессии. Для команд с `read` в этой инструкции используется оболочка Bash, стандартная для `root` на поддерживаемых системах. {% endstep %} {% step %} ### Проверьте загруженные файлы Выведите список ZIP-файлов и файла контрольной суммы Installer: ```bash find /home -maxdepth 1 -type f \ \( -name '*.zip' -o -name 'iex-installer-linux.zip.sha256' \) \ -printf '%f\n' | sort ``` В `/home` должны находиться: * архив Installer; * файл `iex-installer-linux.zip.sha256`; * один полный Backend-архив; * один полный Frontend-архив; * один архив лицензии. Автоматический поиск не должен выбирать между несколькими архивами одного назначения. Если в `/home` находятся старые версии, другой архив лицензии или посторонние ZIP-файлы, переместите их в отдельный каталог. Не удаляйте неизвестные файлы автоматически. {% endstep %} {% step %} ### Установите начальные утилиты На чистом сервере могут отсутствовать необходимые утилиты: * `unzip` распаковывает Installer; * `ca-certificates` позволяет проверять защищённые HTTPS-соединения; * `nano` используется для редактирования конфигурации. Установите их: ```bash apt-get update DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \ unzip \ ca-certificates \ nano ``` Обновите системное хранилище сертификатов: ```bash update-ca-certificates ``` Проверьте доступность команд: ```bash command -v unzip command -v nano command -v sha256sum test -f /etc/ssl/certs/ca-certificates.crt ``` Команды `command -v` должны вывести пути к программам. Последняя команда должна завершиться без ошибки; отдельного сообщения об успехе она не выводит. {% endstep %} {% step %} ### Проверьте контрольные суммы Перейдите в каталог загруженных файлов и проверьте архив Installer: ```bash cd /home sha256sum --check iex-installer-linux.zip.sha256 ``` Ожидаемый результат: ``` iex-installer-linux.zip: OK ``` Рассчитайте SHA-256 остальных архивов: ```bash sha256sum /home/*.zip ``` Сравните значения с контрольными суммами из личного кабинета. {% hint style="danger" %} Не продолжайте установку, если хотя бы одна контрольная сумма отличается. Повторно скачайте и загрузите соответствующий файл. Не изменяйте файл контрольных сумм ради получения результата `OK`. {% endhint %} После проверки установите владельца и ограничьте доступ к архивам: ```bash chown root:root /home/*.zip chmod 0600 /home/*.zip chown root:root /home/iex-installer-linux.zip.sha256 chmod 0600 /home/iex-installer-linux.zip.sha256 ``` Права `0600` разрешают читать и изменять файлы только владельцу — `root`. {% endstep %} {% step %} ### Проверьте предыдущую распаковку До распаковки выполните: ```bash ls -ld \ /home/installer \ /home/iex-installer-linux \ 2>/dev/null ``` При первой подготовке оба каталога должны отсутствовать. В этом случае команда не выведет их список. Если `/home/installer` уже существует, не распаковывайте новый Installer поверх него. Сначала проверьте состояние: ```bash /home/installer/iex-installer status ``` Посмотрите отчёты: ```bash /home/installer/iex-installer reports list --kind install /home/installer/iex-installer reports show install ``` Если ранее запускалась установка, используйте раздел «Продолжение прерванной установки». Если существует только `/home/iex-installer-linux`, проверьте его содержимое и выясните, была ли прервана подготовка. Не удаляйте каталог автоматически. {% endstep %} {% step %} ### Распакуйте Installer Если `/home/installer` и `/home/iex-installer-linux` отсутствуют, выполните: ```bash cd /home unzip -q iex-installer-linux.zip mv /home/iex-installer-linux /home/installer cd /home/installer ``` Проверьте файлы внутри распакованного комплекта: ```bash sha256sum --check SHA256SUMS ``` Все проверяемые файлы должны получить результат `OK`. Разрешите запуск Installer и исполняемых файлов для поддерживаемых архитектур: ```bash chmod 0755 \ /home/installer/iex-installer \ /home/installer/iex-installer-linux-amd64 \ /home/installer/iex-installer-linux-arm64 ``` Проверьте запуск: ```bash /home/installer/iex-installer version ``` Команда выведет версию Installer. Запускной файл `iex-installer` автоматически выбирает исполняемый файл для архитектуры сервера. Выбирать его вручную не нужно. {% endstep %} {% endstepper %} ## Настройка Installer ### Сохраните код лицензии Проверьте, предоставлен ли в личном кабинете отдельный код лицензии.
Если код предоставлен отдельно, сохраните его в защищённом файле: ``` /root/iex-license/license-key ``` Если этот файл уже существует после предыдущей попытки установки, сначала проверьте состояние операции. Не перезаписывайте его без необходимости. Выполните команды ниже. После приглашения `Введите код лицензии:` вставьте код и нажмите `Enter`. Вводимые символы не отображаются — это нормально. ```bash install -d -o root -g root -m 0700 /root/iex-license umask 077 read -r -s -p 'Введите код лицензии: ' IEX_LICENSE_KEY_INPUT printf '\n' printf '%s\n' "$IEX_LICENSE_KEY_INPUT" > /root/iex-license/license-key unset IEX_LICENSE_KEY_INPUT chown root:root /root/iex-license/license-key chmod 0600 /root/iex-license/license-key ``` `umask 077` ограничивает доступ уже в момент создания файла. Проверьте владельца и права без вывода содержимого: ```bash stat -c '%U:%G %a %n' /root/iex-license/license-key ``` Ожидаемый результат: ``` root:root 600 /root/iex-license/license-key ``` Не записывайте код лицензии непосредственно в `install.yaml`, историю команд или отчёт. Если отдельный код не предоставлен и он уже включён в Backend, оставьте `spec.license.keyRef` закомментированным. ### Создайте install.yaml `install.yaml` — файл настроек, по которому Installer выполняет установку. Перейдите в каталог Installer: ```bash cd /home/installer ``` Создайте рабочую конфигурацию из полного примера, включённого в поставку: ```bash test -f install.yaml || cp install.example.yaml install.yaml chmod 0600 install.yaml nano install.yaml ``` Если `install.yaml` уже существует, команда не заменит его новым примером. Редактируйте полный документ. В YAML вложенность определяется отступами: сохраняйте их и используйте пробелы, а не табуляцию. {% hint style="warning" %} Не создавайте второй раздел `spec` и не заменяйте весь `install.yaml` сокращённым примером из документации. Примеры ниже показывают отдельные части файла. Изменяйте соответствующие существующие поля, сохраняя остальные настройки. {% endhint %} Для сохранения файла в `nano` нажмите `Ctrl + O`, подтвердите имя клавишей `Enter`, затем нажмите `Ctrl + X`. ### Укажите параметры установки Все параметры ниже находятся внутри существующего раздела `spec`. Обозначение `spec.domains.frontend` означает: найти `spec`, внутри него `domains`, затем изменить поле `frontend`. #### Домены и название проекта В разделе `spec.domains` укажите свои домены: ```yaml domains: frontend: ваш_домен backend: app.ваш_домен ``` Не добавляйте `https://`, порт или путь административной панели. Остальные поля раздела `domains` сохраните. В `spec.application.name` укажите название проекта. Обычно здесь используется основной домен: ```yaml application: name: ваш_домен ``` В этом же разделе находится `adminPath` — часть адреса административной панели после домена Backend. Если менять её не требуется, оставьте значение из поставки. Готовый адрес для входа Installer сохранит после установки. #### Режим проверки DNS При прямом подключении в существующем разделе `spec.preflight` должны быть значения: ```yaml preflight: dnsMode: direct resourceMode: enforce ``` Если используется Cloudflare или другой прокси-сервис, замените `dnsMode` на `proxy`. `resourceMode: enforce` означает, что Installer остановит установку при нехватке обязательных ресурсов. Оставьте это значение. Перевод ошибки в предупреждение не устраняет нехватку памяти или места на диске. Для прямого подключения поле в существующем разделе `spec.nginx` должно оставаться пустым: ```yaml trustedProxyCidrs: [] ``` При использовании прокси-сервиса заполните этот список его официальными диапазонами адресов, как описано в разделе подготовки DNS. #### SSH и сетевой экран В `spec.firewall.sshPort` укажите порт, через который вы подключились к серверу. Для стандартного порта: ```yaml firewall: enabled: true sshPort: 22 ``` **Firewall** — сетевой экран, ограничивающий входящие подключения. Installer настроит его с учётом указанного SSH-порта. {% hint style="danger" %} `spec.firewall.sshPort` должен совпадать с фактическим портом SSH. Неверное значение может заблокировать последующее подключение. Этот параметр разрешает порт в сетевом экране, но не меняет настройки самой службы SSH. {% endhint %} #### Код лицензии Если вы создали `/root/iex-license/license-key`, найдите в разделе `spec.license` закомментированное поле `keyRef` и раскомментируйте его: ```yaml keyRef: file:/root/iex-license/license-key ``` Префикс `file:` означает, что Installer должен прочитать код из указанного файла. Сам код в YAML не вставляется. Если отдельный код не предоставлен и он уже включён в Backend, оставьте поле закомментированным. #### Файлы поставки Оставьте каталог входных файлов в разделе `spec.artifacts`: ```yaml artifacts: directory: /home ``` У источников Backend, Frontend и архива лицензии сохраните значение: ```yaml type: auto ``` `auto` означает автоматический поиск подходящих архивов в `/home`. Прописывать версии и имена архивов вручную не требуется. #### Данные для входа администратора Параметр `spec.admin.credentialsExportPath` задаёт файл, в который Installer запишет адрес панели, email и новый пароль администратора: ```yaml credentialsExportPath: /home/iexexchanger-admin-access.txt ``` Можно оставить стандартный путь. Если путь изменяется, файл должен находиться непосредственно внутри `/home`, без вложенного каталога. Символические ссылки вместо файла не допускаются. Сохраните: ```yaml resetPassword: true ``` Это позволяет Installer сформировать новый пароль администратора. Поле `spec.admin.expectedEmail` при заполнении проверяет ожидаемый email существующего администратора. Оно не создаёт новый аккаунт и не изменяет его адрес. Если такая проверка не нужна, оставьте значение из примера. #### Остальные настройки Оставьте без изменений штатные версии окружения и значения автоматического подбора ресурсов. Installer использует совместимые настройки из поставки. Сохраните включёнными: * HTTPS; * сетевой экран; * резервное копирование; * создание нового пароля администратора. Не меняйте значения вида: ``` generated://... ``` Это ссылки на секреты, которые Installer создаст для вашей установки, например пароли баз данных и ключи приложения. Они не являются адресами сайтов и не требуют ручного заполнения. `spec.host.applicationUser` задаёт отдельного пользователя Linux, от имени которого работает приложение. Он отличается от `root`. Оставьте штатное значение, если нет технической необходимости выбрать другое до первой установки. После установки эта учётная запись закрепляется за системой. ### Настройте HTTPS HTTPS обеспечивает защищённое соединение браузера с сайтом. Для него нужен сертификат, соответствующий доменам проекта. #### Автоматический сертификат Let's Encrypt Для стандартной установки используйте Let's Encrypt. Installer получит сертификат и настроит его автоматическое продление. В существующем разделе `spec.tls` должны быть следующие параметры: ```yaml tls: enabled: true provider: letsencrypt email: "" redirectHttp: true ``` В `email` можно указать свой действующий адрес или оставить пустую строку `""`. Email не является обязательным условием выпуска сертификата. Адрес-заглушку из `install.example.yaml` необходимо заменить своим адресом или пустой строкой. `redirectHttp: true` включает перенаправление посетителей с HTTP на HTTPS. До установки оба домена и все добавленные дополнительные имена должны иметь правильные DNS-записи. Порт `80` должен быть доступен извне для проверки владения доменом, а порт `443` — для HTTPS. Проверке по пути: ``` /.well-known/acme-challenge/ ``` не должны мешать парольная защита, CAPTCHA или правила прокси-сервиса. #### Первоначальный выпуск сертификата с Cloudflare {% content-ref url="/spaces/uyjsNtEAtO6Sby8CHWyD/pages/Sx75QVfqZsJgR5Iiq2xh" %} [Настройка SSL/TLS](/help-center/administrirovanie/seti-i-bezopasnost/cloudflare/nastroika-ssl-tls.md) {% endcontent-ref %} Если сертификата на новом сервере ещё нет, первоначальный выпуск можно выполнить с записями Cloudflare в режиме [**DNS only**](https://developers.cloudflare.com/dns/proxy-status/). В этом режиме запросы идут напрямую на сервер. Дождитесь обновления DNS перед запуском Installer. Если после установки планируется включить проксирование, задайте: ```yaml dnsMode: proxy ``` до первого запуска установки. Временно включённый DNS only этому не мешает. После успешного выпуска сертификата выберите в Cloudflare режим [**Full (strict)**](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/) и включите проксирование нужных записей. Затем обязательно выполните `verify --public-endpoints`, описанную ниже. Она проверяет итоговую доступность проекта через публичные адреса. #### Если используется готовый сертификат Этот вариант нужен при наличии собственного действующего сертификата и соответствующего приватного ключа. Для обычной установки оставьте Let's Encrypt. Подготовьте сертификат с полной цепочкой в формате PEM и приватный ключ. Сертификат должен: * покрывать оба домена и дополнительные имена из конфигурации; * соответствовать приватному ключу; * быть доверенным системой; * иметь запас срока действия более 30 дней. Создайте защищённый каталог: ```bash install -d -o root -g root -m 0700 /root/iex-tls ``` Загрузите в него файлы: ``` /root/iex-tls/fullchain.pem /root/iex-tls/privkey.pem ``` Ограничьте доступ: ```bash chown root:root /root/iex-tls/fullchain.pem /root/iex-tls/privkey.pem chmod 0600 /root/iex-tls/fullchain.pem /root/iex-tls/privkey.pem ``` В существующем разделе `spec.tls` используйте: ```yaml tls: enabled: true provider: files certificateRef: file:/root/iex-tls/fullchain.pem privateKeyRef: file:/root/iex-tls/privkey.pem redirectHttp: true ``` Поле `email` для этого варианта удалите. Installer проверит сертификат и ключ перед использованием. Продление собственного сертификата организуется отдельно. Автоматическое продление Let's Encrypt к этому варианту не относится. ### Проверьте итоговую конфигурацию Покажите настройки в безопасном виде: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ config show ``` Проверьте структуру файла: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ config validate ``` Проверьте готовность сервера, DNS и входных файлов: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ checklist ``` Сформируйте план установки: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ plan ``` Назначение команд:
КомандаЧто проверяет
config showПоказывает итоговые настройки в безопасном виде
config validateПроверяет структуру и допустимость конфигурации
checklistПоказывает готовность сервера и разрешённое следующее действие
planФормирует последовательность установки и проверяет её условия
Эти команды не устанавливают серверное окружение. Устраните ошибки `ERROR`. Каждое предупреждение `WARN` изучите до запуска установки. На чистом сервере часть пунктов может иметь статус: ``` НЕТ → ВЫПОЛНИТЬ ``` Это означает, что компонент ещё не установлен и будет подготовлен Installer. Такой статус не равен ошибке. Статус: ``` ПОКА НЕ ПРОВЕРЕНО ``` означает, что проверка станет доступна позже. Для первой установки строка `Следующее действие` должна разрешать команду `install`. Если указан другой вариант, используйте раздел «Продолжение прерванной установки». Количество и порядок этапов определяются полученной поставкой. Ориентируйтесь на названия и результаты этапов, а не на их номера. ## Установка системы ### Запустите Installer После успешного выполнения `config validate`, `checklist` и `plan` запустите: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ --non-interactive \ --yes \ install ``` Параметры команды: * `--config` указывает файл настроек; * `--non-interactive` отключает интерактивные вопросы; * `--yes` подтверждает выполнение установки. Эти параметры не отключают обязательные проверки. Не закрывайте SSH-сессию до завершения команды. Не запускайте одновременно вторую установку, `resume`, обновление или ручные операции с базами данных. ### Что выполняет Installer Во время первичной установки Installer: * проверяет платформу, ресурсы, DNS, системное время и занятые порты; * проверяет отсутствие конфликтующего окружения; * устанавливает необходимые системные компоненты и ionCube Loader; * настраивает swap — резервную область на диске на случай нехватки оперативной памяти; * создаёт отдельного пользователя приложения; * создаёт каталоги приложения и сохраняемых данных; * создаёт уникальные секреты установки; * распаковывает Backend, Frontend и архив лицензии; * настраивает базы данных, Nginx, Redis, сетевой экран и HTTPS; * импортирует начальные данные; * создаёт и проверяет начальную резервную копию; * выполняет Product Updates; * создаёт новый пароль администратора; * делает подготовленный выпуск приложения текущим; * запускает службы приложения и задачи по расписанию; * включает регулярное резервное копирование; * устанавливает `iexctl`, Updater и Update Agent; * выполняет итоговые проверки; * сохраняет состояние и отчёт установки. **Product Updates** — предусмотренная выпуском последовательность изменений базы данных и настроек приложения. Во время установки её выполняет Installer. Приложение работает от отдельного пользователя Linux. Фоновые службы выполняют свои задачи: * **Horizon** обрабатывает очередь заданий. * **Reverb** передаёт события в реальном времени. * **Pulse** собирает диагностические данные. * **Scheduler** запускает действия по расписанию. Открывать внутренние порты баз данных и фоновых служб в интернет для установки не требуется. ### Импорт баз данных Основная база заполняется из файла Backend: ``` database/iex_data.sql ``` Вторая база используется Pulse для диагностических данных. Она заполняется из: ``` database/pulse_db.sql ``` Не импортируйте эти файлы вручную. Не запускайте отдельно `php artisan migrate`, Product Updates, установку зависимостей через Composer или npm и сборку приложения. Штатную последовательность импорта и подготовки приложения выполняет Installer. ### Статусы в терминале Во время установки могут отображаться следующие статусы:
СтатусЗначение
ПРОВЕРКАПроверяется текущее состояние
ВЫПОЛНЯЕТСЯВыполняется изменение сервера
КОНТРОЛЬПроверяется результат изменения
ПОДТВЕРЖДЁНРезультат этапа подтверждён
ПОВТОРЭтап ожидает повторного выполнения
ГОТОВОЭтап успешно завершён
ПРОПУЩЕНИзменение не требуется или этап не применяется к этой конфигурации
ОШИБКАУстановка остановлена из-за ошибки
`ПРОПУЩЕН` сам по себе не означает ошибку. Читайте пояснение этапа и проверяйте итоговый отчёт. Успех всей установки определяется итоговым статусом и последующими проверками. ### Статусы в отчёте Команда `reports show install` использует отдельные названия:
СтатусЗначение
ОЖИДАЕТЭтап ещё не выполнен
ВЫПОЛНЯЕТСЯЭтап выполняется
УСПЕШНОЭтап выполнен
УЖЕ ГОТОВОТребуемое состояние существовало ранее
ОШИБКАЭтап завершился ошибкой
Для обязательного завершённого этапа допустимы: ``` [УСПЕШНО] [УЖЕ ГОТОВО] ``` ## Продолжение прерванной установки ### Проверьте состояние Если команда завершилась ошибкой или SSH-соединение было потеряно, не запускайте новую установку сразу. Проверьте состояние: ```bash /home/installer/iex-installer status ``` Посмотрите список отчётов: ```bash /home/installer/iex-installer reports list --kind install ``` Откройте последний отчёт: ```bash /home/installer/iex-installer reports show install ``` Отчёт содержит: * **Run ID** — идентификатор запуска; * итоговый статус; * идентификатор этапа с ошибкой; * путь к журналу; * пути установки; * результаты выполненных этапов. Если процесс установки ещё работает, дождитесь его завершения. Потеря SSH-соединения сама по себе не подтверждает остановку процесса. После просмотра состояния и отчёта выполните: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ checklist ``` Найдите строку `Следующее действие`.
Предложенное действиеКак продолжить
installПроверить актуальный план и выполнить разрешённую установку
resumeУстранить причину ошибки и продолжить совместимый незавершённый запуск
verifyУстановка уже завершена; проверить её результат
ручная диагностикаАвтоматическое продолжение заблокировано; изучить указанную причину
### Продолжите тот же запуск Используйте `resume`, только если в строке `Следующее действие` команда `checklist` предлагает `resume` и не изменялись: * Installer; * `/home/installer/install.yaml`; * Backend-архив; * Frontend-архив; * архив лицензии. После устранения причины ошибки выполните: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ --non-interactive \ --yes \ resume ``` Installer сверит файлы и настройки с сохранённым планом, затем продолжит незавершённые этапы того же запуска. {% hint style="danger" %} Не удаляйте каталоги установки, базы данных, состояние установки или журналы ради повторного запуска. Не импортируйте SQL повторно и не запускайте Product Updates вручную. {% endhint %} ### Если изменились конфигурация или архивы Если изменились `install.yaml`, Installer или хотя бы один ZIP-файл, не используйте `resume` старого запуска. Повторите проверки: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ config validate /home/installer/iex-installer \ --config /home/installer/install.yaml \ checklist /home/installer/iex-installer \ --config /home/installer/install.yaml \ plan ``` Продолжайте только способом, разрешённым Installer после проверки нового плана. Если ошибка относится к Product Updates, SQL или содержимому поставки, не исправляйте установленную базу вручную. Сохраните Run ID и отчёт. Дальнейшие действия выполняйте с исправленной официальной поставкой или по инструкции технической поддержки. ### Если Let's Encrypt сообщил о лимите Если в ошибке указано `retry after`, сохраните тот же Installer, `install.yaml` и архивы. Дождитесь указанного времени UTC с небольшим запасом, затем повторите `checklist`. Если следующим действием предложен `resume`, продолжите тот же запуск. Не запускайте новые установки подряд ради повторного запроса сертификата и не заменяйте рабочий HTTPS самоподписанным сертификатом. ## Проверка установленной системы ### Проверьте итоговый статус Выполните: ```bash /home/installer/iex-installer status ``` Откройте отчёт: ```bash /home/installer/iex-installer reports show install ``` Итоговый статус установки должен быть: ``` Статус: УСПЕШНО ``` Если итоговый статус отличается, сначала устраните причину по отчёту и рекомендациям Installer. ### Выполните внутреннюю проверку Проверьте установленную систему: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ verify ``` Команда должна завершиться без ошибки. Эта проверка оценивает установленное окружение и работу компонентов системы. ### Выполните публичную проверку После направления доменов на установленный сервер и завершения настройки прокси, если он используется, выполните: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ verify --public-endpoints ``` Команда проверяет доступность Frontend и Backend через публичные домены. Успешная внутренняя проверка не заменяет публичную: ошибочная настройка DNS или Cloudflare может мешать посетителям, даже если службы на самом сервере работают. ### Проверьте управляющие инструменты Проверьте постоянную команду управления: ```bash command -v iexctl iexctl version ``` Первая команда должна показать путь к `iexctl`, вторая — установленную версию. Проверьте общее состояние системы и служб: ```bash iexctl doctor iexctl services status iexctl services verify ``` Назначение команд: | Команда | Назначение | | ------------------------ | --------------------------------------------- | | `iexctl doctor` | Общая диагностика установленной системы | | `iexctl services status` | Просмотр состояния управляемых служб | | `iexctl services verify` | Проверка работоспособности обязательных служб | Проверьте Updater: ```bash /usr/local/sbin/iex-updater status ``` Проверьте версии Updater и Update Agent: ```bash /usr/local/sbin/iex-updater version /usr/local/sbin/iex-update-agent -version ``` Эти команды проверяют доступность инструментов и показывают их версии. Обновление приложения они не запускают. {% hint style="warning" %} `iexctl doctor` может показать предупреждение, например о хранении резервных копий на том же диске или временной недоступности внешнего сервиса. Предупреждение нужно изучить, но оно не равно ошибке основной службы. Ошибку `iexctl services verify` необходимо устранить до ввода системы в работу. {% endhint %} ### Проверьте Update Agent и системные службы Проверьте автоматический запуск и текущее состояние агента: ```bash systemctl is-enabled iex-update-agent.service systemctl is-active iex-update-agent.service ``` Ожидаемые значения: ``` enabled active ``` `enabled` означает, что служба включена в автоматический запуск. `active` означает, что она работает сейчас. Дополнительно проверьте механизм контроля зависания агента — watchdog: ```bash systemctl show iex-update-agent.service \ --property=Type \ --property=NotifyAccess \ --property=WatchdogUSec ``` Ожидается: * `Type=notify`; * `NotifyAccess=main`; * ненулевое значение `WatchdogUSec`. Это означает, что служба сообщает системе о своей готовности и поддерживает контроль зависания. Эти параметры настраивает Installer; редактировать их вручную не нужно. **systemd** управляет запуском системных служб. Проверьте, есть ли службы с ошибкой: ```bash systemctl --failed --no-pager ``` В списке не должно быть служб в состоянии `failed` — завершившихся с ошибкой. ### Подтвердите базы, Product Updates и начальную копию Следующая команда отбирает нужные строки из отчёта. Она не запускает импорт или изменения повторно: ```bash /home/installer/iex-installer reports show install | \ grep -E 'Статус:|host\.postgresql\.import\.(main|pulse)|backup\.initial-verified|artisan\.product-updates\.apply|controltools\.install' ``` Проверьте наличие этапов: ``` host.postgresql.import.main host.postgresql.import.pulse backup.initial-verified artisan.product-updates.apply controltools.install ``` Их значения:
ЭтапЧто подтверждает
host.postgresql.import.mainИмпорт начальных данных основной базы
host.postgresql.import.pulseИмпорт начальных данных базы Pulse
backup.initial-verifiedСоздание и проверку начальной резервной копии
artisan.product-updates.applyВыполнение штатной последовательности Product Updates
controltools.installУстановку проверенного комплекта управляющих инструментов
Каждый обязательный этап должен иметь статус: ``` [УСПЕШНО] ``` Если необходимое состояние было подтверждено при продолжении установки, также допустим: ``` [УЖЕ ГОТОВО] ``` ### Проверьте Scheduler **Scheduler** запускает задачи приложения по расписанию. При стандартной установке служба **CRON** каждую минуту вызывает `schedule:run`, а приложение определяет, какие задачи пора выполнить. Проверьте CRON: ```bash systemctl is-enabled cron.service systemctl is-active cron.service ``` Ожидаемые значения: ``` enabled active ``` Проверьте файл расписания, созданный Installer: ```bash test -f /etc/cron.d/iexexchanger-scheduler && \ echo 'Scheduler CRON: OK' cat /etc/cron.d/iexexchanger-scheduler ``` В файле должна быть одна созданная Installer ежеминутная команда `schedule:run`, выполняемая от пользователя приложения, а не от `root`. Проверьте результат установочного запуска Scheduler: ```bash systemctl show iex-scheduler.service \ --property=Result \ --value ``` Ожидаемый результат: ``` success ``` `iex-scheduler.service` выполняет одно задание и завершается. Поэтому `inactive` при результате `success` является нормальным состоянием. Отдельный `iex-scheduler.timer` при такой схеме не нужен: расписанием уже управляет CRON. Проверьте отсутствие старого таймера, чтобы задачи не запускались дважды: ```bash if systemctl list-unit-files --no-legend iex-scheduler.timer | \ grep -q '^iex-scheduler.timer'; then echo 'ОШИБКА: найден устаревший iex-scheduler.timer' else echo 'Устаревший таймер Scheduler: отсутствует' fi ``` Если найден старый таймер, сохраните результат диагностики и выясните причину. Не создавайте параллельное расписание вручную. ### Проверьте продление сертификата При использовании Let's Encrypt проверьте автоматический запуск продления: ```bash systemctl is-enabled certbot.timer systemctl is-active certbot.timer ``` Ожидаемые значения: ``` enabled active ``` Посмотрите ближайший запуск: ```bash systemctl list-timers --all --no-pager 'certbot*' ``` **Таймер** — расписание, по которому systemd запускает задачу. Для сертификата, переданного через `provider: files`, наличие `certbot.timer` не требуется. Продление такого сертификата организуется отдельно. ### Проверьте регистрацию сервера Выполните синхронизацию с официальным сервисом: ```bash iexctl registration sync iexctl registration status ``` Первая команда синхронизирует сведения об установке, вторая показывает результат. При ошибке изучите её причину. Временная недоступность внешнего сервиса отличается от отказа из-за лицензии или домена. Отказ регистрации, связанный с данными проекта, нельзя оставлять без исправления. ### Проверьте клиентский сайт Откройте в браузере: ``` https://ваш_домен ``` Проверьте: * сайт открывается; * используется HTTPS; * браузер не предупреждает об ошибке сертификата; * страница повторно открывается после обновления; * не отображается ошибка связи с Backend; * сайт не остаётся в режиме обслуживания. Проверку административной панели выполните по следующему разделу. ## Доступ к административной панели {% stepper %} {% step %} ### Когда создаётся файл После успешного завершения установки Installer создаёт отдельный файл с данными для входа. Доступ к нему имеет только `root`. Стандартный путь: ``` /home/iexexchanger-admin-access.txt ``` Во время незавершённой или неуспешной установки этот файл может ещё отсутствовать. {% endstep %} {% step %} ### Где хранятся реквизиты Пользовательская копия находится по пути из параметра: ``` spec.admin.credentialsExportPath ``` Стандартное значение: ``` /home/iexexchanger-admin-access.txt ``` Installer также сохраняет внутренний защищённый файл: ``` /var/lib/iexexchanger/installer/admin-credentials-<идентификатор-релиза>.txt ``` Команда: ```bash /home/installer/iex-installer reports show install ``` показывает путь к внутреннему файлу в строке: ``` Файл реквизитов администратора ``` Эта строка не показывает изменённый пользовательский `credentialsExportPath`. Если вы меняли путь пользовательской копии, найдите его через: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ config show ``` Внутренний файл управляется Installer и используется для безопасного продолжения операции. Не изменяйте и не удаляйте его. {% endstep %} {% step %} ### Как посмотреть реквизиты Проверьте владельца и права пользовательского файла: ```bash stat -c '%U:%G %a %n' /home/iexexchanger-admin-access.txt ``` Ожидаемый результат: ``` root:root 600 /home/iexexchanger-admin-access.txt ``` Если вы изменили `credentialsExportPath`, используйте свой путь. Откройте файл только в своей закрытой SSH-сессии от `root`: ```bash sed -n '1,20p' /home/iexexchanger-admin-access.txt ``` Файл содержит: * точный адрес административной панели; * email администратора; * автоматически созданный пароль; * путь к внутренней защищённой копии. {% hint style="danger" %} Команда просмотра выводит пароль в терминал. Не отправляйте содержимое файла в чат, обращение поддержки или общедоступное хранилище. {% endhint %} {% endstep %} {% step %} ### Проверьте вход 1. Скопируйте точный адрес из строки `Адрес`. 2. Откройте его в браузере. 3. Введите email и пароль из файла. 4. Убедитесь, что открылась административная панель. 5. Обновите страницу. 6. Откройте другой раздел административной панели. Проверка считается успешной, если после обновления страницы авторизация сохраняется и разделы открываются без ошибок. {% endstep %} {% step %} ### Если пользовательский файл не создан Проверьте состояние и отчёт: ```bash /home/installer/iex-installer status /home/installer/iex-installer reports show install ``` Если установка не имеет итогового статуса `УСПЕШНО`, сначала определите разрешённое следующее действие: ```bash /home/installer/iex-installer \ --config /home/installer/install.yaml \ checklist ``` Продолжайте установку через `resume` только тогда, когда это предлагает Installer. Порядок приведён в разделе «Продолжение прерванной установки». Если установка имеет статус `УСПЕШНО`, но пользовательский файл отсутствует: 1. Найдите путь в строке `Файл реквизитов администратора` отчёта. 2. Проверьте владельца и права внутреннего файла. 3. Получите Backend-домен и `adminPath` через `config show`. 4. Просмотрите внутренний файл только в своей закрытой SSH-сессии от `root`. 5. Сохраните реквизиты в менеджере паролей. 6. Сохраните Run ID и сообщение об ошибке создания пользовательской копии для диагностики. Не запускайте ручной сброс пароля во время незавершённой установки. При `resume` Installer использует уже сформированные реквизиты и не создаёт новый пароль без необходимости. {% endstep %} {% endstepper %} ### Сохраните реквизиты После успешной проверки входа: 1. Сохраните адрес, email и пароль в защищённом менеджере паролей. 2. Ограничьте доступ к записи ответственными сотрудниками. 3. Проверьте вход с сохранёнными данными. 4. После подтверждённого входа удалите пользовательскую копию `/home/iexexchanger-admin-access.txt`, если она больше не нужна на сервере. Не удаляйте внутренний файл из `/var/lib/iexexchanger/installer`. *** ## Резервная копия после установки Installer создаёт начальную резервную копию до выполнения Product Updates. После завершения установки создайте ещё одну копию. Она сохранит состояние уже подготовленного приложения, включая изменения базы и новый пароль администратора. ### Создайте копию установленной системы Выполните: ```bash iexctl backup run ``` Дождитесь завершения без ошибки. Проверьте состояние и время последней копии: ```bash iexctl backup status ``` По умолчанию зашифрованные копии сохраняются локально: ``` /var/backups/iexexchanger/restic-repository ``` Для хранения и проверки копий система использует **Restic** — программу резервного копирования. ### Проверьте целостность и извлечение файлов Проверьте все сохранённые данные хранилища: ```bash iexctl --timeout 12h backup verify --full ``` Затем проверьте извлечение последней копии: ```bash iexctl --timeout 12h backup restore-test ``` `--timeout 12h` задаёт максимально допустимое время команды. Это не длительность проверки и не расписание её запуска. `restore-test` выполняет следующие действия: * извлекает последнюю копию в отдельный временный каталог; * проверяет наличие сохранённых файлов и конфигурации; * проверяет читаемость структуры дампов обеих баз; * удаляет временные данные после проверки. **Дамп** — файл с сохранённым содержимым базы данных. Рабочие базы при этой проверке не изменяются. {% hint style="info" %} `restore-test` проверяет извлечение файлов и структуру дампов. Он не импортирует дампы в отдельный PostgreSQL и не заменяет полное испытание восстановления всего сервера. {% endhint %} Обе команды должны завершиться без ошибки. Наличие копии или активного расписания само по себе не подтверждает, что сохранённые данные можно прочитать. ### Проверьте регулярное копирование В стандартной конфигурации резервное копирование выполняется ежедневно. Проверьте таймер: ```bash systemctl is-enabled iex-backup.timer systemctl is-active iex-backup.timer ``` Ожидаемые значения: ``` enabled active ``` Посмотрите следующий запуск: ```bash systemctl list-timers --all --no-pager iex-backup.timer ``` Служба, создающая копию, может быть `inactive` между запусками. Постоянно активным должно быть её расписание — `iex-backup.timer`. ### Настройте хранение вне сервера Локальная копия помогает при ошибках приложения, но теряется вместе с сервером или его диском. До начала работы с реальными данными настройте хранение резервных копий вне этого сервера и сохраните ключ восстановления отдельно. {% content-ref url="/pages/LBKgvBucM15o8QrI5D99" %} [Создание резервной копии](/server-i-dannye/sozdanie-rezervnoi-kopii.md) {% endcontent-ref %} ## Проверка после перезагрузки Проверьте автоматический запуск служб до начала работы с клиентами. Сначала откройте второе SSH-подключение с теми же данными. Убедитесь, что после настройки сетевого экрана сервер по-прежнему разрешает вход. Затем перезагрузите сервер: ```bash systemctl reboot ``` SSH-соединение будет разорвано, а сайт временно станет недоступен. Дождитесь загрузки сервера и подключитесь снова. После подключения выполните: ```bash systemctl is-system-running systemctl --failed --no-pager ``` Ожидается состояние системы: ``` running ``` В списке служб с ошибкой не должно быть записей. Если система ещё загружается, дождитесь завершения запуска служб. Повторите проверки: ```bash /home/installer/iex-installer status /home/installer/iex-installer \ --config /home/installer/install.yaml \ verify /home/installer/iex-installer \ --config /home/installer/install.yaml \ verify --public-endpoints /usr/local/sbin/iexctl services verify /usr/local/sbin/iexctl backup status /usr/local/sbin/iex-updater status /usr/local/sbin/iexctl registration status ``` Повторно откройте клиентский сайт и административную панель. Войдите в административную панель, обновите страницу и откройте другой раздел. Убедитесь, что система работает после перезагрузки без ручного запуска служб. ## После установки ### Сохраните установочные материалы Сохраните: * `/home/installer`; * `/home/installer/install.yaml`; * `/root/iex-license/license-key`, если он создавался; * Run ID успешной установки; * отчёт установки; * контрольные суммы архивов; * реквизиты администратора в менеджере паролей. Installer остаётся в `/home/installer` для проверки состояния, просмотра отчётов и обслуживания установочной операции. Не копируйте Installer в `/usr/local/sbin`. После установки постоянная команда `iexctl` доступна из любого каталога: ```bash iexctl version ``` Постоянные `iexctl`, `iex-updater` и `iex-update-agent` устанавливаются из проверенной поставки. Не заменяйте их вручную. Не удаляйте настройки, сведения о выполненных операциях и журналы. Они нужны для диагностики и последующего обслуживания. Служебные данные находятся в каталогах: ``` /etc/iexexchanger /var/lib/iexexchanger ``` Не удаляйте входные архивы до завершения всех проверок, включая проверку после перезагрузки. ### Подготовьте данные для диагностики Если возникла проблема, сначала сохраните Run ID и отчёт: ```bash /home/installer/iex-installer reports show install ``` Если отчёта недостаточно, создайте диагностический комплект: ```bash iexctl --format json support bundle ``` Команда выводит пути к диагностическому архиву и его контрольной сумме. Передавайте архив вместе с созданной для него контрольной суммой. Файл должен иметь права `0600`. Перед передачей проверьте содержимое. В диагностические материалы не должны попадать: * пароль `root`; * приватный SSH-ключ; * код лицензии; * пароль администратора; * содержимое `.env`; * приватные ключи и токены; * cookie; * дампы баз данных. Полный журнал передавайте только после проверки содержимого и по защищённому каналу. ### Когда установка завершена Перед переходом к настройке обменного пункта подтвердите: * итоговый статус Installer — `УСПЕШНО`; * внутренняя и публичная проверки завершились без ошибки; * базы данных импортированы, Product Updates выполнен; * обязательные службы и Scheduler работают; * Updater доступен, Update Agent включён и активен; * проверены HTTPS и автоматическое продление сертификата, если используется Let's Encrypt; * создана копия завершённой установки; * проверены целостность резервных данных и извлечение последней копии; * включено регулярное резервное копирование; * проверен результат регистрации сервера; * клиентский сайт открывается; * вход в административную панель сохраняется после обновления страницы; * необходимые проверки повторно пройдены после перезагрузки. Не оставляйте необъяснённые ошибки перед вводом системы в работу. Успешная установка подтверждает готовность серверного окружения. Настройка направлений обмена, платёжных модулей и остальных функций проекта выполняется отдельно. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.iexexchanger.com/ustanovka-i-obnovlenie/ustanovka-produkta.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.