Fleetrun
Hecterra
NimBus
Другие приложения
Wialon для Android/iOS
Logistics
Wialon Local
Wialon Hosting
Distance Tag
WiaTag
Configurator
2104
Содержание
Памятка администратора Wialon Local
  • technical_consulting
  • administration_system
  • installation
  • upgrading_wialon_local
  • backup
  • logs
  • license

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

Доступы

Обязательные

  • lic.gurtam.com 31176 — проверка компонентов лицензии.

  • local-api.wialon.com 443 — скачивание обновлений скриптов и модулей.

Опциональные

  • lic.gurtam.com 18711 — сервис определения положения по LBS.

  • lic.gurtam.com 18712 — сервис push-уведомлений в мобильные клиенты.

  • lic.gurtam.com 18611-18614 — сервис для работы карт Gurtam Maps.

  • https://distro.gurtam.com/maps/ — хранилише старых AVD-карт, доступные AVD-карты.

  • https://api.telegram.org — сервер для уведомлений в Telegram.

  • https://acme-v02.api.letsencrypt.org/ — генерация Let's Encrypt сертификатов (порт 80 должен быть обязательно открыт).

Приложения

  • mqtt.flespi.io 8883 (SSL) или 1883 (не SSL) — MQTT-брокер.

  • app-local.wialon.com порт 443 — для доступа к NimBus, Fleetrun, Hecterra и другим веб-приложениям.

  • 193.193.165.135 порты 80 и 443 — для доступа к NimBus, Fleetrun, Hecterra.
  • apps-svcs.wialon.com  порт 443 — для доступа к app Dashboard
  • 193.193.165.135.0/24 порты 80 и 443 — доступ ко всей подсети с Wialon apps.

Оборудование

Стандратный диапазон портов в iptables для оборудования Wialon:

  • -A INPUT -p udp -m state --state NEW -m udp --dport 20100:30000 -j ACCEPT

  • -A INPUT -p tcp -m state --state NEW -m tcp --dport 20100:30000 -j ACCEPT

Видеосервер

  • Порт 1935 или 19350 в зависимости от типа устройства.

  • Порт 8083 — получение файлов от видеосервера.

Прочее

  • BASE URL для приложений Logistics, Nimbus, Fleetrun, Hecterra должны быть внешними.

  • URL подключения для мобильного клиента Wialon Local должен быть внешним без порта (доступ через IP:port не предусматривался).

  • Генерация и обновление Let's Encrypt сертификатов производится через http-запрос, порт 80. За месяц до истечения сертификата производится попытка автообновления. При неудаче попытка повторяется через неделю.

Контроль дискового пространства

  • Установка Wialon Local по умолчанию осуществляется в /home/wialon/wlocal.

  • Wialon контролирует только свободное место в /home. Если в нем менее 5 Гб, то Wialon автоматически останавливается, чтобы не повредить БД.

  • Дефрагментация файлов БД запускается автоматически при степени фрагментации больше 20%. Для успешной дефрагментации требуется в 2,5 раза больше свободного места, чем размер файла БД. Текущий уровень (или процент) фрагментации файлов базы данных можно посмотреть в storage/ms/msgs_stats.

  • По умолчанию logrotate ротирует и хранит логи за 10 дней. Периодически проверяйте отсутствие сбоев в ротировании логов.

  • В wlocal/storage, wlocal/storage/md и wlocal/storage/pd могут образоваться файлы кэшей на отправку данных на резервнй сервер — sync.cache.. Размер кэш более 1 Гб влечет за собой медленную скорость сети, недоступность резервного сервера в сети или прекращение его работы.

  • В /home/wialon/wlocal/ может образоваться файл с расширением *.msgs. Это кэш поступивших сообщений для записи в БД. Размер кэша более 1 Гб влечет за собой медленную скорость записи/дисков и может указывать на повреждение БД/диска.

  • В разделах /root/ и /var/ всегда должно быть свободное место для нормальной работы системы и авторизации в системе администратора.

Папки и логи

  • Все логи работы Wialon Local расположены по умолчанию в папке /home/wialon/wlocal/logs/. По умолчанию логи хранятся и ротируются за 10 дней (logrotate).

  • Передача SMS на отправку SMPP шлюзу или GSM модему логируется в trace.log сервиса wialon. Коммуникация с шлюзом или GSM устройством, отправка SMS логируется в логах smpp_device_* / gsm_device_*.

  • Передача email на отправку MAIL серверу логируется в логе trace.log. Непосредственно обработку и отправку самого письма MAIL сервером следует анализировать по логам MAIL сервера (postfix/mailx по умолчанию, либо логи непосредственно SMTP). Таймаут для отправки команды на SMTP-сервер в Wialon — 10 секунд. Таймаут для получения ответа (код 250) от SMTP-сервера в Wialon — 5 секунд. Производится 5 попыток передачи email на отправку Wialon -> SMTP. После 5-й не успешной попытки задача на отправку email удаляется из очереди, в логе trace.log фиксируется ошибка выполнения задачи на отправку email.

  • Проблемы с генерацией или обовлением Lets Encrypt сертификатов логируются в lcm/lcm.log. Иногда вместо продления/обновления сертификата более корректно будет удалить старых SSL сертификатов (сбросить кнопкой Default) и сгенерировать новые.

  • В error.log попадают записи из всех логов сервиса со словом "error". Т.е. иногда это может быть не ошибка, а просто слово "error" в ответе трекера на выполнение команды, либо слово "error" в имени или тексте выполняемого отчета/уведомления и т.п.

  • В папке /home/wialon/wlocal/tmp/charts/ хранятся текстовые файлы со статистикой для графиков ресурсов панели администратора. Файлы не ротируются и не удаляются, при необходимости старые файлы можно удалить вручную при остановленном WL.

  • При сбое сервиса WL по возможности предусмотрен автоматический дамп процесса wialon, файлы в папке debug/.

  • Полученные от трекеров видеофайлы хранятся в формате MP4 отдельно от БД Wialon в директории /mnt/storage/video. Эта папка создается при установке видеосервиса на WL.

  • Журнал error.log и уведомление администратора по электронной почте запускаются для любой записи активности в trace.log с ключевыми словами 'error' и 'PANIC'. Рекомендуется избегать совпадения этих слов и совпадения корня ключей в составе других слов в названиях системных элементов (объектов, отчетов, уведомлений) для предотвращения ложных предупреждений об ошибках работы сервиса на электронную почту администратора.

Сервис горячего резервного копирования

  • Автоматический контроль свободного места на диске не предусмотрен — следить за переполнением необходимо штатными средствами.

  • Первичная синхронизация/копирование БД заканчивается появлением в trace.log записи "Sync finished". 

  • Если происходит обрыв подключения/потери связи с сервером/межсетевые проблемы, то в trace.log появляется запись "pipe_not_connected".

  • Рост кэша синхронизации на основном сервере при настроенном и работающем модуле резервного копирования для этой синхронизации в основном указывает на недостаточную скорость передачи данных по сети, недостаточную скорости чтения-записи дисков, на проблемы синхронизации из-за поврежденного файла БД или поврежденных секторов диска.

Условия принудительной синхронизации БД заново:

  • Некорректная остановка бэкапа. Тогда на бэкапе не создаются файлы serial.dat и props.dat, которые отвечают за продолжение синхронизации БД.
  • Если модуль резервного копирования или основной сервис перезапустили до полной синхронизации.
  • Ошибка при синхронизации какого-либо файла (обычно из-за его повреждения).

Запрещенные действия при работе и обслуживании Wialon Local

  • В соответствии с лицензионным соглашением, вмешательство в дистрибутив WL (изменение любых файлов внутри любых директорий) со стороны клиента не допускается. Изменения конфигураций сервиса Wialon — изменения дизайна, SSL, ограничения и т.д. — производится через систему администрирования.

  • Запрещено запускать два и более сервиса Wialon по одной лицензии.

  • Нельзя выключать сервер или перезагружать ОС при работающем сервисе Wialon.

  • Нельзя перемещать или удалять файлы или папки в рабочей директории wlocal/ (в особенности папку storage/).

Сергей Новиков,Инженер отдела технического консалтинга

Архитектура Wialon Local
  • technical_consulting
  • administration_system

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

Сергей Новиков,Инженер отдела технического консалтинга

Возможные проблемы в работе Wialon Local
  • technical_consulting
  • administration_system
  • sms
  • backup

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

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

Ошибки системы администрирования

При входе в систему администрирования вы можете столкнуться с разными ошибками. Исходя из кода и имени ошибки, выберите один из следующих вариантов решения.

The site can't be reached / Unable to connect / Page not found

Недоступность сайта и вывод ошибок с таким текстом может быть связана с состоянием nginx.

 Решение

Сперва следует убедиться в том, что 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 не работает, то следует решать проблему на уровне специалистов, обслуживающих сервер.

404 Not Found

Если система администрирования недоступна и возвращает ошибку «404 Not Found», то, скорее всего, установка сервиса Wialon Local была произведена некорректно и файлы, необходимые для работы сервиса, просто отсутствуют.

 Решение

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

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

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

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

502 Bad Gateway

Ошибка «502 Bad Gateway» при обращении к системе администрирования может быть связана со статусом процессов, связанных с работой Wialon Local.

 Решение

Проверка:

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, 17048 (Jessie)0.10.x
    1704, 1804, 19049 (Stretch)6.x
    1904, 2004, 210410 (Buster)10.x

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

  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@gurtam.com.

Ошибка «502 Bad Gateway» при выполнении отчета

Если при выполнении отчета в Wialon вы были перенаправлены на страницу с ошибкой «502 Bad Gateway» или она наблюдается в консоли браузера при выполнении отчета, то, скорее всего, запрашиваемый отчет пытается загрузить ресурсы, доступ к которому у вас ограничен.

 Решение

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

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

Проблемы с авторизацией в Fleetrun/Nimbus

Если с имеющимся у вас паролем для пользователя wialon вам не удается авторизоваться в приложениях Fleetrun или Nimbus, но при этом вы можете авторизоваться на сайте мониторинга, то следует проверить, выполнены ли требования к работе приложений.

 Решение

Требования для работы 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@gurtam.com. 

Увеличение размера кэша синхронизации

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

 Решение

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

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

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

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

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

После этого необходимо решить проблемы с доступом между серверами и удалить резервную копию базы данных в директории /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

Об окончании процесса синхронизации на резервном сервере свидетельствует запись вида «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 — при полной синхронизации цифры должны быть сопоставимы.

Проверка подключения модема к Wialon Local

При любых затруднениях с подключением модема к Wialon Local следует анализировать логи в /home/wialon/wlocal/logs

Передача SMS на отправку SMPP-шлюзом или GSM-модемом логируется в trace.log сервиса Wialon. Коммуникация со шлюзом или GSM устройством, а также отправка SMS, логируется в логах /home/wialon/wlocal/logs/ с названиями smpp_device_* / gsm_device_*.

 Решение

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

 SMPP-шлюз

После создания и включения SMPP-шлюза, создается отдельный лог-файл smpp_device_*.log , в который записываются все ошибки соединения и логируется факт соединения.
Также все взаимодействия со шлюзом будут отображены в trace.log.

Например при отсутствии соединения с SMPP-шлюзом в указанных логах будут фигурировать сообщения формата:

smpp_device_*.log
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
trace.log
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
 GSM/Network модемы

Взаимодействие с GSM- и сетевыми модемами до момента установления первого соединения будет фиксироваться только в trace.log.
Пример записей в логе при отсутствии соединения с модемом:

GSM trace.log
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)

И больше никаких сообщений общения с модемом.
Network trace.log
2021/07/16 15:56:23:400: [INF:AADC7700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0

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

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

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

Перенос Wialon Local на новый сервер

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

 Решение

Процесс переноса (миграции) сервиса 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 на новом сервере.
  8. Вновь запустить сервис Wialon Local (команда service wlocal start) и Wialon в системе администрирования на новом сервере для того, чтобы убедиться, что подстановка базы данных прошла успешно и сервис корректно работает.

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

Поврежденные файлы базы данных

Если после аварийной остановки или сбоя сервера Wialon не может запуститься и ссылается на поврежденные файлы базы данных, то в файле trace.log можно увидеть следующую запись:

trace.log
2021/08/17 12:50:26:649: [INF:FAB26740] storage_service_db::open_databases: opening database environment...
2021/08/17 12:50:26:713: [INF:FAB26740] storage_service_db::open_databases: opening databases...
2021/08/17 12:50:26:714: [INF:FAB26740] storage_messages_env::open_environment: opening database environment (cache: size: 12104 MB, chunks: 1)...
2021/08/17 12:50:28:049: [INF:FAB26740] storage_messages_env::open_environment: recovering environment: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
2021/08/17 12:50:28:841: [INF:FAB26740] adf_load_plugin('storage_server'). Error loading plugin. Error initializing storage subsystem as server.
2021/08/17 12:50:28:841: [INF:FAB26740] Error: couldn`t load ADF plugin: 'storage_server'.

В случае, когда сервис Wialon продолжает работать, и при этом в логе содержатся записи «Fatal error, run database recovery», следует немедленно остановить Wialon (сервис и сайт системы администрирования) и приступить к восстановительным процедурам.

 Решение 1

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

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 без ошибок.

 Решение 2

Если решение с использованием сервера резервного копирования вам не помогло, то можно попробовать воспользоваться стандартными утилитами для восстановления отдельных файлов вручную. Рекомендуем также еще раз выполнить скрипт 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@gurtam.com и опишите все выполненные вами действия, а также проблемы, с которыми вы столкнулись при восстановлении файлов БД.

Проблемы с доставкой почты

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

В Wialon Local существует два механизма отправки почтовых уведомлений. Знание их особенностей может быть полезно при диагостике потенциальных проблем.

 Отправка писем из системы администрирования

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

  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-сервер, то все относящиеся к нему поля рекомендуем оставлять пустыми.

 Отправка писем из Wialon

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

  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 адресу сервера.

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

Большое использование RAM

При работе с Wialon Local можно заметить, что сервис постоянно потребляет почти все доступное количество оперативной памяти сервера. Это вполне ожидаемое поведение, так как сервис Wialon кэширует почти всю доступную оперативную память, но активно использует лишь некоторую ее часть.

 Решение

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

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

Проблемы с конфигурацией nginx

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

 Решение

При установке 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/

Улучшение безопасности nginx

В зависимости от требований к безопасности и к сети сервера может потребоваться дополнительная настройка конфигурации 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     ;     
           ...

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


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

Владимир Мелекесцев,Инженер отдела технического консалтинга

10
  • 10
  • 25
  • 30
Спасибо за ваш отзыв!
Сообщить об ошибке
Текст с ошибкой Комментарий
Максимум 500 символов