Сперва следует убедиться в том, что nginx работает:

service nginx restart
service nginx status #(проверка состояние сервиса)
nginx -t             #(проверка синтаксиса файлов, если сервис не запустился)

Пример вывода ответов на команды при правильной работе сервиса:

nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: en
Active: active (running) since Tue 2021-08-03 13:46:09 MSK; 2min 56s ago

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Если в конфигурации nginx имеются ошибки синтаксиса или nginx не работает, то следует решать проблему на уровне специалистов, обслуживающих сервер.

В такой ситуации следует:

1. Проверить, есть ли в директории /home/wialon/wlocal папка «install».
   Если такой папки нет, то вероятно, что произошел сбой при установке Wialon Local. Если папка присутствует, попробуйте перезапустить процесс Wialon Local:

   service wlocal restart

2. Попробуйте переустановить Wialon Local из официального образа, соблюдая при этом все необходимые требования:
   • Установка должна производиться в BIOS режиме, а для UEFI — в Legacy режиме;
   • При установке OS нельзя пропускать шаг с указанием настроек подключения к сети;
   • Должны отсутствовать другие сетевые ограничения к серверу, которые не позволяют загрузить соответствующие пакеты для работы сервиса.

Если после переустановки Wialon Local результат не поменялся, то обратитесь на почту support@wialon.com для ручной установки сервиса.

Проверка:

ps aux | grep -v grep | grep node
top | grep wialon

Пример ожидаемого списка активных процессов из первой команды при рабочем сервисе:

wialon 701 0.0 2.3 591208 47884 ? Ssl 12:27 0:00 /usr/bin/node /usr/lib/node_modules/forever/bin/monitor cron.js
wialon 713 1.3 36.4 1491260 745596 ? Sl 12:27 0:49 /usr/bin/node /home/wialon/wlocal/cron.js

Если для указанных команд приходит пустой ответ либо же отсутствует процесс cron.js из первой команды, то процессы Wialon Local не запущены. Попробуйте запустить сервис заново:

service wlocal restart
service wlocal status #(проверка запуска)

Если сервис не может запуститься, следует:

1. Проверить версию пакетов, необходимых для работы Wialon Local, с помощью команд:

   node -v 
   nodejs -v
   npm -v
   npm -g list | grep forever

   Ответы на первые две команды должны соответствовать требованиям к версии Wialon Local, указанным в документации:

   Версии Wialon Local	Версии Debian	Версии Node.js
   1504, 1604, 1704	8 (Jessie)	0.10.x
   1704, 1804, 1904	9 (Stretch)	6.x
   1904, 2004, 2104	10 (Buster)	10.x

   Если версия Node.js не соответствует требуемой, следует ее обновить.
   Пустой ответ на третью и/или четвертую команду говорит об отсутствии пакета npm и его модуля forever. Для их установки обратитесь к инструкции из документации.

2. Проанализировать логи сервиса Wialon Local в /home/wialon/wlocal/logs/lcm/ и, при наличии ошибок, связанных с Node.js, переустановить компоненты Wialon Local, необходимые для корректной работы, в соответствии с документацией. Пример подобных ошибок:

   Error: Most middleware (like json) is no longer bundled with Express and must be installed separately ...

   Внимательно смотрите на вывод результатов установки, чтобы не упустить ошибки, которые могут возникнуть при обновлении.

Если после выполненных действий система администрирования по-прежнему недоступна, то напишите на почту support@wialon.com.

Это может происходить при выполнении отчета, для которого используются дорожные ограничения скорости, связанные с Gurtam Maps. В таком случае следует проверить, открыты ли у вас необходимые доступы к ресурсам Gurtam Maps: lic.gurtam.com 18611-18614

Если вы пользуетесь другими картами (Yandex, Google), то следует открывать соответствующие доступы к их серверам.

Требования для работы Fleetrun и Nimbus в Wialon Local описаны в документации:

• Наличие отдельной DNS;
• Наличие flespi token в панели администратора;
• Активирована соответствующая услуга в учетной записи;
• Наличие полной цепочки SSL-сертификатов для DNS, которая используется для приложения (приложение должно работать по HTTPS);
• Для Nimbus: наличие подключенных карт Gurtam Maps;
• Наличие прямых доступов к:

  apps.wialon.com 80/443
  mqtt.flespi.io  8883 (SSL) or 1883 (non-SSL)

Если все требования соблюдены, но проблема с авторизацией в приложения все еще осталась, обратитесь на support@wialon.com. 

Прежде всего следует проверить, имеются ли какие-либо сетевые ограничения между резервным и основным серверами, и выполнить базовую проверку доступности резервного сервера по стандартному порту 32001, например, через telnet с основного сервера Wialon Local:

telnet <адрес_резервного_сервера> 32001 

В данном случае порт 32001 – стандартный порт, который указывается в системе администрирования основного сервера. C помощью этого порта осуществляется последующая синхронизация данных. Его можно сменить, поэтому внимательно проверяйте, доступны ли соответствующие порты на резервном и основном серверах, между которыми вы задали синхронизацию.

Также следует проанализировать логи модуля резервного копирования в файле /home/wl_storage_backup/logs/trace.log на предмет ошибок. В частности, в логах могут быть ошибки следующего типа:

2021/05/24 17:19:50:007: [INF:73907700] net_session::bg_task(2167042, '192.168.0.15:32001'): pipe not connected
2021/05/24 17:19:50:007: [INF:4CA1E700] messages_sync_server::sync_thread('192.168.0.15:32001:******'): invalid reply from synchronization server

Такие ошибки свидетельствуют о проблемах с доступом между серверами.

В случае длительной недоступности сервера резервного копирования, или если файлы кэша синхронизации занимают очень большой объём на диске, следует остановить модуль резервного копирования на резервном сервере с помощью команды:

Для резервного сервера старого образца:
service wlbackup stop

Для резервного сервера нового образца (начиная с версии Wialon Local 2104):
service wlocal stop

После этого необходимо решить проблемы с доступом между серверами и удалить резервную копию базы данных в директории /home/wl_storage_backup/storage

Далее в системе администрирования основного сервера следует остановить сервис Wialon, а затем выполнить команду «service wlocal stop» для остановки сайта системы администрирования, и только после этого удалить критически переполненные файлы кэша синхронизации, например, с помощью команды:

find /home/wialon/wlocal/storage -name sync.cache.* -type f -delete

При ручном удалении файлов кэша синхронизации учитывайте тот факт, что необходимые файлы лежат в разных папках директории /home/wialon/wlocal/storage и имеют названия такого формата: sync.cache.1983335884, где цифры в конце могут меняться.

Процесс синхронизации после выполнения всех процедур запускается в два этапа: сначала включается Wialon Local на основном сервере, затем на резервном. Для этого используются следующие команды:

На основном:
service wlocal start

На резервном сервере старого образца:
service wlbackup start

На резервном сервере нового образца (начиная с версии Wialon Local 2104):
service wlocal start

Об окончании процесса синхронизации на резервном сервере свидетельствует запись вида «sync finished» в файле /home/wialon/wlocal/logs/trace.log. Также для дополнительной проверки вы можете сопоставить статистику по сообщениям на основном сервере в файле /home/wialon/wlocal/storage/ms/msgs_stats.txt и на резервном в /home/wl_storage_backup/storage/ms/msgs_stats.txt — при полной синхронизации цифры должны быть сопоставимы.

Примеры логов:

2021/07/16 15:50:52:031: [INF:C2B98700] Can`t connect to SMPP server
2021/07/16 15:51:06:558: [INF:C2B98700] Can`t connect to SMPP server
2021/07/16 15:52:12:289: [INF:C2B98700] Can`t connect to SMPP server

2021/07/16 15:51:06:556: [INF:C2B98700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0
2021/07/16 15:51:06:558: [INF:C2B98700] Can`t connect to SMPP server

2021/07/16 15:55:16:332: [INF:C2B98700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0
2021/07/16 15:55:16:332: [INF:C2B98700] remote_gsm_device::start(88)

И больше никаких сообщений общения с модемом.

2021/07/16 15:56:23:400: [INF:AADC7700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0

И больше никаких сообщений общения с модемом.

Для диагностики соединения всегда проверяйте доступность удаленного хоста или шлюза, а также что модем смонтирован по указанному в панели администратора адресу и реагирует на команды (например через minicom).

Если согласно логам SMS-сообщения отправляются из сервиса Wialon, но не доходят до конечного адресата, то проблему следует решать на стороне получателя либо на стороне самого модема. Аналогичным образом следует поступать при отсутствии соединения с модемом или удаленным шлюзом: такие проблемы должны решаться на уровне собственной сети, модема или шлюза. В любых других ситуациях обращайтесь на support@wialon.com.

Процесс переноса (миграции) сервиса Wialon Local следует выполнять в описанной ниже последовательности:

1. Сообщить о дате переноса вашему персональному менеджеру.

2. Развернуть на новом сервере Wialon Local из официального образа, строго следуя официальной инструкции до шага 5 включительно (т.е. не авторизовываться в панели администратора). 
   
3. Остановить сервис Wialon в системе администрирования старого сервера, а затем выполнить команду «service wlocal stop» для остановки сайта самой системы администрирования.
4. Авторизоваться в системе администрирования нового сервера, дождаться установки основных модулей, необходимых для работы Wialon Local.
5. Включить Wialon на новом сервере и убедиться в его стабильной работе.
6. Остановить сервис Wialon в системе администрирования нового сервера, а затем выполнить команду «service wlocal stop» для остановки сайта системы администрирования.

7. Произвести копирование содержимого директории /home/wialon/wlocal/storage со старого сервера на новый в ту же директорию. Предварительно удалить содержимое директории /storage на новом сервере. После переноса выполнить команду на новом сервере:

   chown -R wialon:wialon /home/wialon/

8. Вновь запустить сервис Wialon Local (команда service wlocal start) и Wialon в системе администрирования на новом сервере для того, чтобы убедиться, что подстановка базы данных прошла успешно и сервис корректно работает.

Если на сервере, на который будет осуществляться миграция, уже был предварительно установлен модуль резервного копирования из официального образа Wialon Local, то инструкция по переносу такая же, как и в случае использования резервного сервера в качестве основного. Порядок действий описан в документации.

Прежде всего, если вы используете сервер резервного копирования, следует проверить файлы резервной копии вашей БД на резервном сервере в директориях /home/wl_storage_backup/storage/md и home/wl_storage_backup/storage/pd с помощью скрипта db_verfify , который следует создать в директории /home/wialon/wlocal . Его содержимое представлено ниже. Выполнять скрипт необходимо строго из этой же директории (home/wialon/wlocal) с помощью команды ./db_verify.sh

#! /bin/sh
export PATH="./modules/adf/bin:./modules/dep/bin:$PATH"
export LD_LIBRARY_PATH="./modules/adf/lib:./modules/dep/lib:$LD_LIBRARY_PATH"
export ADF_SCRIPT_PATH="modules/adf_scripts/scripts"
export TCL_LIBRARY="./modules/dep/lib/tcl8.4"
ulimit -c 0
db_verify /home/wialon/wlocal/storage/pd/*.db
db_verify /home/wialon/wlocal/storage/md/*.db

Если есть подозрения на повреждения каких-то конкретных db-файлов, то вместо *.db в последней строчке можно подставить название конкретно файла БД, например, m-00000001.db . Тогда строчка будет иметь вид:

db_verify /home/wialon/wlocal/storage/md/m-00000001.db

Пример результата работы скрипта:

Успешная проверка:
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000001.db succeeded.
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000002.db succeeded.
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000003.db succeeded.

Файл БД не прошел проверку:
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000003.db failed.
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000004.db failed.

В случае, если в результате проверки не обнаружится ошибок, у вас есть 2 варианта действий:

1. Прежде чем совершать какие-либо манипуляции с подстановкой базы данных, следует выключить Wialon из системы администрирования на основном сервере и сам сервис Wialon Local (service wlocal stop), а также на бэкап-сервере выключить сервис резервного копирования (service wlbackup stop). После этого заменить БД на основном сервере (директория /home/wialon/wlocal/storage) БД резервного сервера (директория /home/wl_storage_backup/storage) и запустить Wialon.
2. Воспользоваться резервным сервером в качестве основного согласно инструкции Восстановление при сбое.

Если db-файлы на сервере резервного копирования тоже оказались повреждены, попробуйте удалить резервную БД и запустить процесс синхронизации еще раз. Как только он закончится, проверьте скопированную БД с помощью скрипта db_verify и, в случае его успешного выполнения, можете подставить ее на основной сервер. Подстановку базы следует проводить из директории /home/wl_storage_backup с резервного вместо директории /home/wialon/wlocal/storage на основном. При этом битую БД основного сервера рекомендуется сохранить в отдельном месте и не удалять до тех пор, пока не получится запустить Wialon без ошибок.

Если решение с использованием сервера резервного копирования вам не помогло, то можно попробовать воспользоваться стандартными утилитами для восстановления отдельных файлов вручную. Рекомендуем также еще раз выполнить скрипт db_verify и локализовать все битые db-файлы перед дальнейшими действиями. Рассмотрим этот вариант на примере файла /home/wialon/wlocal/storage/md/m-00000007.db (если есть другие поврежденные файлы, то поступать с ними нужно аналогичным образом).

Остановите сервис Wialon в системе администрирования, а затем выполните команду «service wlocal stop» для остановки сайта системы администрирования. После этого в директории /home/wialon/wlocal выполните следующие команды:

export PATH="./modules/adf/bin:./modules/dep/bin:$PATH"
export LD_LIBRARY_PATH="./modules/adf/lib:./modules/dep/lib:$LD_LIBRARY_PATH"
export ADF_SCRIPT_PATH="modules/adf_scripts/scripts"
export TCL_LIBRARY="./modules/dep/lib/tcl8.4"
ulimit -c 0

После этого можно начать манипуляции с БД (скрипты ниже уже есть в Wialon, и их нужно просто выполнить в той же директории /home/wialon/wlocal):

db_dump -r /home/wialon/wlocal/storage/md/m-00000007.db | db_load /home/wialon/wlocal/storage/md/m-00000007.db.new

Потом в директории /home/wialon/wlocal/storage/md переименуйте новый и старый файл БД, с помощью команд:

 mv m-00000007.db m-00000007.db.old

 mv m-00000007.db.new m-00000007.db

Это стандартные утилиты для работы с БД, которые пересоздадут ваш db-файл заново.

После этого запустите Wialon и проверьте trace.log на наличие ошибок. Затем еще раз прогоните файл m-00000007.db и другие битые файлы через скрипт db_verify. при остановленном сервисе.

Если ни одна из указанных рекомендаций вам не помогла, то напишите на почту support@wialon.com и опишите все выполненные вами действия, а также проблемы, с которыми вы столкнулись при восстановлении файлов БД.

Уведомления из системы администрирования приходят на почту администратора, заданную в настройках (блок Почтовая система на вкладке Система). Они работают по следующему приоритету:

1. Отправка с помощью SMTP-сервера, заданного в системе администрирования;
2. Отправка посредством postfix, которая осуществляется, если настройки SMTP не заданы, либо если письмо не получается передать на отправку указанному почтовому шлюзу.

Логи с указанием способа и статуса отправки находятся в файле /home/wialon/wlocal/logs/lcm.log.*

При использовании собственного SMTP-сервера, логи отправки следует анализировать на стороне самого SMTP, где он развернут, а в случае с postfix логи можно посмотреть в /var/mail/ или в /var/log/mail.log.*

Также следует отметить, что Wialon Local поддерживает использование других почтовых сервисов помимо postfix, так как запрос на отправку письма передается на localhost. Таким образом, если вы решите, например, использовать exim вместо postfix, то следует убедиться, что он сможет обрабатывать все входящие почтовые запросы с localhost адреса сервера.

Начиная с Wialon Local 2104, в поле Логин для настроек SMTP-сервера в системе администрирования вы задаете не только логин для авторизации в вашем почтовом шлюзе, но еще и имя отправителя. В случае если из всех настроек SMTP-сервера у вас заполнено только поле Логин, то запрос на передачу письма уйдет к postfix под заданным логином. Если в postifix нет пользователя с таким логином, то письмо не отправится. Поэтому если вы не используете свой собственный SMTP-сервер, то все относящиеся к нему поля рекомендуем оставлять пустыми.

Письма, которые отправляются при выполнении заданий и уведомлений, работают по следующему приоритету:

1. Отправка с помощью SMTP-сервера, заданного в тарифном плане (обратите внимание, что в тарифном плане адрес SMTP-сервера следует обозначать вместе с протоколом, например «smtps://smtp.gmail.com» );
2. Если SMTP в тарифном плане не задан, то письмо будет отправлено с помощью SMTP, указанного в системе администрирования;
3. Если ни один из SMTP-адресов не указан, то письмо будет отправлено с помощью postfix.

Главное отличие от предыдущего механизма заключается в том, что если письмо не сможет отправиться с помощью одного из заданных SMTP-адресов, то оно не будет дальше передаваться на другой SMTP-адрес или на postfix — такое письмо в итоге просто не отправится. При неудачной отправке будет необходимо внести необходимые правки, чтобы в дальнейшем использовать нужный почтовый инструмент.

Логи того, какой службе было передано письмо, а также статус отправки можно найти в файле /home/wialon/wlocal/logs/trace.log по фильтру «email». Конечные логи отправки с помощью SMTP-сервера следует смотреть на стороне самого SMTP-сервера. Логи отправки через postfix все также следует смотреть в /var/mail/ или в /var/log/mail.log.*

В данном механизме тоже доступна возможность использования своего собственного почтового сервиса вместо postfix, если он аналогично привязан к localhost адресу сервера.

Wialon Local кэширует почти всю доступную для своей работы оперативную память вне зависимости от её количества на сервере. Сервис Wialon кэширует всю RAM для обработки запросов и задач, для быстрого доступа к страницам и для недопущения возможных задержек и проблем, связанных с отказов в доступе из-за использования RAM другими приложениями на сервере. Кэшированная RAM управляется балансировщиком нагрузки, который перераспределяет кэшированную RAM для WIalon или других приложений на сервере. Но по умолчанию приоритет отдается именно Wialon.

При этом вы можете проконтролировать использование оперативной памяти в системе администрирования на графике RAM. При наведении курсора на каждый участок графика вы можете увидеть запись о том, сколько памяти в данный момент активно используется, а сколько закэшировано.

При недостатке оперативной памяти для корректной работы сервиса Wialon, в логе /home/wialon/wlocal/logs/trace.log можно увидеть записи вида:

2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216
2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216
2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216
2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216

В таких случаях следует проверить, соответствует ли сервер системным требованиям для имеющегося количества объектов. Также следует проверить наличие сервисов или приложений, которые могли бы активно использовать оперативную память на сервере на момент появления такой записи, и проанализировать ситуацию.

При установке Wialon Local из официального образа на сервере автоматически создаются конфигурационные файлы для сайтов, которые иногда приходится редактировать в связи с техническими требованиями к серверу. Вся ответственность за конфигурацию и настройку nginx лежит строго на технических специалистах, которые обслуживают сервер Wialon Local.

Для последующей работы полезно понимать, какие конфигурационные файлы и настройки присутствуют на сервере сразу после установки Wialon Local. Все необходимые конфигурационные файлы будут находиться в директории /etc/nginx/conf.d/, а их стандартный вид после установки описан ниже.

1. lcm.conf — конфигурационный файл системы администрирования.

   server {
           listen          80;
           server_name     ;
           client_max_body_size 10000m;
           proxy_read_timeout 500;
           location /50x.html {
                   root /home/wialon/wlocal/nginx/www/nginx-default;
           }
           location / {
                   if ( $args ~* dns-test ) {
                           echo 1;
                   }
                   proxy_set_header Upgrade $http_upgrade;
                   proxy_set_header Connection "Upgrade";
                   proxy_pass         http://localhost:8080;
           }
   
           access_log /var/log/nginx/lcm.access.log;
   
   }

2. cms.conf — временный конфигурационный файл CMS Manager.

   server {
            listen 8024;
            server_name ;
            proxy_set_header Host your.cms_manager.DNS.0:8024;
            proxy_set_header X-Forwarded-For $remote_addr;
            client_max_body_size 64m;
            access_log /var/log/nginx/wdc.access.log;
            location /50x.html {
                    root /home/wialon/wlocal/nginx/www/nginx-default;
            }
            location / {
                    proxy_pass http://localhost:8022;
            }
   }

3. webmonitor.conf — временный конфигурационный файл Wialon Web.

   server {
            listen 8025;
            server_name ;
            proxy_set_header Host your.wialon_web.DNS.0:8025;
            proxy_set_header X-Forwarded-For $remote_addr;
            client_max_body_size 64m;
            access_log /var/log/nginx/wdc.access.log;
            location /50x.html {
                    root /home/wialon/wlocal/nginx/www/nginx-default;
            }
            location / {
                    proxy_pass http://localhost:8022;
            }
   }

4. local.conf — основной конфигурационный файл, который отражает все настройки сайтов, указанных в системе администрирования.
   Данный файл является символической ссылкой на файл, который автоматически формируется исходя из настроек сайтов в системе администрирования и находится по адресу /home/wialon/wlocal/nginx/conf/local.conf.

   Данный конфигурационный файл категорически запрещается редактировать, также не рекомендуется отвязывать символическую ссылку. Все необходимые настройки для ваших сайтов Wialon рекомендуется вносить в системе администрирования. Если вы используете собственный конфигурационный файл вместо автоматически созданного local.conf, вся ответственность за работоспособность сайтов возлагается на администратора сервера Wialon Local.

   Если по какой-либо причине символическая ссылка local.conf отвязалась, её следует вернуть с помощью команды:

   ln -s /home/wialon/wlocal/nginx/conf/local.conf /etc/nginx/conf.d/local.conf

В первых трех конфигурационных файлах параметр в пункте server_name обозначает локальный IP-адрес вашего сервера Wialon Local, к которому будут привязаны стандартные конфигурационные файлы. Этот IP-адрес потом можно изменить.

Следует понимать, что конфигурационные файлы webmonitor.conf и cms.conf являются временными исключительно потому, что используются для временного доступа к сайтам Wialon через IP-адрес и порт, а также для первичной проверки работоспособности сервиса до заведения отдельных DNS-записей для сайтов. Как только вы создадите отдельную DNS-запись для этих сайтов в системе администрирования, данные файлы уже будут неактуальны, и их рекомендуется удалить. До этого момента доступ к сайтам может осуществляться по следующим адресам: 

• Система администрирования Wialon Local: http:// или по loopback адресу самого сервера http://localhost:8080
• Сайт CMS Manager: http://:8024 или по loopback адресу самого сервера http://localhost:8024
• Cайт Wialon Web: http://:8025 или по loopback адресу самого сервера http://localhost:8025

Все необходимые логи веб-сервера и ошибки можно найти в /var/log/nginx/

1. Расширить поддержку версий протокола TLS в /etc/nginx/common/default.conf:

   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

2. Задать максимальный срок действия сертификатов SSL в /etc/nginx/common/default.conf:

   add_header Strict-Transport-Security "max-age=31536000;
   includeSubDomains" always;

3. Изменить используемый список шифрований в /etc/nginx/common/default.conf (весь перечень шифрований можно найти здесь):

   ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
   ssl_prefer_server_ciphers on;

4. Вручную добавить SSL-сертификат для сайта системы администрирования в /etc/nginx/conf.d/lcm.conf:

   server {
          listen          443;
          ssl on;
          ssl_certificate /root/ssl_certificate.crt; # абсолютный путь к сертификату
          ssl_certificate_key /root/private.key; # абсолютный путь к приватному ключу
          server_name     ;     
          ...

   В этом случае следует задать абсолютный путь к сертификату и его приватному ключу в параметрах выше.