Всем хороша среда выполнения Javascript NodeJS, но у неё есть три недостатка.

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

Что с этим делать? Можно потратить много времени, разобраться, где утекает память, написать исправление к модулю и послать Pull-Request разработчикам модуля, который они скорее всего проигнорируют, так как у них проблема не воспроизводится, или же они, как обычно, не видят в этом проблему. А можно просто перезапустить программу через несколько часов работы, когда начинают появляться утечки памяти.

Для примера, рассмотрим почтовый сервер на основе https://haraka.github.io/, который, после запуска потребляет 56.8 мегабайт памяти, а через несколько суток - уже 180 мегабайт.

Данный сервер запускается с помощью systemd, используя этот unit файл:

[Unit]
Description=Haraka inbound STMP server
After=network.target

[Service]
Type=simple

User=haraka
Group=haraka

WorkingDirectory=/opt/haraka/haraka-inbound
ExecStart=/usr/bin/npm start
Restart=always
RestartSec=1s
Environment=NODE_ENV=production

# Hardening
ProtectHome=yes
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Как его можно перезапустить, допустим, раз в час, используя systemd?

Для этого достаточно почитать документацию к systemd, и найти этот параметр конфигурации:

https://www.freedesktop.org/software/systemd/man/systemd.service.html#RuntimeMaxSec

RuntimeMaxSec=

Configures a maximum time for the service to run. If this is used 
and the service has been active for longer than the specified time it is terminated 
and put into a failure state. Note that this setting does not have any effect 
on Type=oneshot services, as they terminate immediately after activation 
completed. Pass "infinity" (the default) to configure no runtime limit.

То есть, задав этот параметр равным 3600, мы добьёмся того, что systemd будет автоматически останавливать, и снова запускать почтовый сервер каждый час. Так как Haraka написан неожиданно хорошо для nodejs приложений, он не только быстро перезагружается, он ещё знает, как закончить все транзакции перед перезапуском, и поэтому ни одно письмо не пропадёт.

Такой unit файл был в итоге создан для почтового сервера:

[Unit]
Description=Haraka inbound STMP server
After=network.target

[Service]
Type=simple

User=haraka
Group=haraka

WorkingDirectory=/opt/haraka/haraka-inbound
ExecStart=/usr/bin/npm start
Restart=always
RestartSec=1s
Environment=NODE_ENV=production

# Gracefully restart service every hour to prevent memleaks
RuntimeMaxSec=3600

# Hardening
ProtectHome=yes
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Теперь почтовый сервер перезапускается раз в час, и в среднем потребляет около 60 мегабайт памяти.

Недавно на работе у меня было такое задание - соединить NodeJS приложение с OpenLDAP сервером, обладающем следующей структурой данных: в корне - структура Organization Unit с профилями пользователями, доступная, для примера, по DN ou=people,dc=vodolaz095,dc=ru и имеющая следующую структуру:

dn: ou=people,dc=vodolaz095,dc=ru
objectclass: organizationalUnit
ou: people

В этой структуре - уже были профили пользователей - например, uid=user1,ou=people,dc=vodolaz095,dc=ru, uid=user2,ou=people,dc=vodolaz095,dc=ru и т.д.

Аккаунты пользователей принадлежали к типам posixAccount, inetOrgPerson, organizationalPerson, person.

Аккаунты пользователей выглядели примерно вот так:

dn: uid=user1,ou=people,dc=vodolaz095,dc=ru
cn: Jane Doe
gidnumber: 1000
givenname:  Jane
homedirectory: /home/janedoe
initials: JS
loginshell: /bin/bash
objectclass: posixAccount
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
mail: user1@vodolaz095.ru
sn: Doe
uid: user1
uidnumber: 1002
userpassword: {SSHA}HF3O9bpD+/a5iswMxRCwBgboZgV2Mkpp

При этом для каждого пользователя был задан пароль.

Задача состояла в том, что пользователь вводит логин (в виде user1) и пароль в NodeJS приложении. И программа должна проверить, угадал ли пользователь пароль, а потом программа должна загрузить все данные о пользователе из базы данных OpenLDAP.

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

Для работы по протоколу openLDAP я использовал следующую NodeJS библиотеку - https://www.npmjs.com/package/ldapjs. Минимальный работающий образец исходного кода представлен тут:

'use strict';

const ldap = require('ldapjs');

const ldapClient = ldap.createClient({
  url: 'ldap://127.0.0.1:389'
});

const username = 'cn=readonly,dc=vodolaz095,dc=ru';
const password = 'readonly';

ldapClient.bind(
  username,
  password,
  function (error) {
    if (error) {
      throw error;
    }
    console.log('bind performed');

    ldapClient.search('ou=people,dc=vodolaz095,dc=ru', {
      filter: `(uid=vodolaz095)`,
      scope: 'one',
      attributes: ['uid', 'dn', 'cn', 'mail']
    }, function (error, res) {
      if (error) {
        throw error;
      }
      res.on('searchEntry', function (data) {
        // console.log('Data found', data);
        console.log('Data object', JSON.stringify(data.object, null, 2));
      });
      res.once('error', function(error){
        throw error;
      });
      res.once('end', function () {
        console.log('Completed');
        process.exit(0)
      });
    });
  }
);

Как видно из кода, мы сначала “биндимся” к базе данных как пользователь readonly с DN cn=readonly,dc=vodolaz095,dc=ru, потом ищем пользователя в коллекции ou=people,dc=vodolaz095,dc=ru по фильтру (uid=vodolaz095), и если мы его нашли, то можно попробовать “забиндиться” как этот пользователь к базе данных, тем самым проверив пароль, подходит ли он.

'use strict';

const ldap = require('ldapjs');

const ldapClient = ldap.createClient({
  url: 'ldap://127.0.0.1:389'
});

const username = 'uid=vodolaz095,ou=people,dc=vodolaz095,dc=ru';
const password = 'superSecretPasswordOfVodolaz095!';

ldapClient.bind(username, password, function (error) {
  if (error) {
    throw error;
  }
  console.log('пароль подошёл, пользователь vodolaz095 авторизирован!');
});

Можно ли как то упростить данную процедуру?

Возможно ли не использовать пользователя readonly?

Можно ли минимизировать число запросов данных к базе данных ldap?

Ответ:

Да, можно

И сейчас я расскажу, как. Оказывается, большинство openLDAP серверов позволяют авторизоваться (“забиндиться”) как искомый пользователь, и даже получить его профиль.

Рассмотрим данный код:

'use strict';

const ldap = require('ldapjs');

const ldapClient = ldap.createClient({
  url: 'ldap://127.0.0.1:389'
});


const username = 'uid=vodolaz095,ou=people,dc=vodolaz095,dc=ru'
const password = 'thisIsVerySecureSecretPassword';


ldapClient.bind(
  username,
  password,
  function (error) {
    if (error) {
      throw error;
    }
    console.log('bind performed');

    ldapClient.search('uid=vodolaz095,ou=people,dc=vodolaz095,dc=ru', { 
      scope: 'base', // important
      attributes: ['uid', 'dn', 'cn', 'mail']
    }, function (error, res) {
      if (error) {
        throw error;
      }
      res.on('searchEntry', function (data) {
        // console.log('Data found', data);
        console.log('Data object', JSON.stringify(data.object, null, 2));
      });
      res.once('error', function (error){
        throw error;
      });
      res.once('end', function () {
        console.log('All passed');
        process.exit(0);
      });
    });
  }
);

С помощью этого кода мы напрямую пытаемся “забиндиться” к базе данных ldap как ограниченный пользователь, используя функцию ldapClient.bind(username, password, function(error){....}).

Если “забиндиться” получилось, то это означает, что пароль подошёл. Теперь надо получить профиль пользователя, и по умолчанию, все пользователи ldap имеют права на чтение своего собственного профиля. По крайней мере, так работает в контейнеризированной сборке openLDAP из https://github.com/osixia/docker-openldap.

После того, как мы забиндились, мы можем попробовать найти свой собственный профиль. Это можно сделать с помощью данной функции:

    ldapClient.search('uid=vodolaz095,ou=people,dc=vodolaz095,dc=ru', { 
      scope: 'base', 
      attributes: ['uid', 'dn', 'cn', 'mail']
    }, function (error, res) {....})

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

Код ошибки мог меняться в замисимости от страницы, но почти всегда это был SQL запрос вроде такого

select count(distinct posts.id) as aggregate 
from posts 
where (posts.status = 'published' and posts.page = false)

Главное, что в нём всегда встречалось read ECONNRESET.

Причина неполадок состояла в том, что сервер базы данных закрывал соединение с блог платформой, так как оно, по мнению сервера, не использовалось. Данная неполадка чинится отправкой этих запросов на MariaDB сервер через консоль сервера MySQL/MariaDB:

SET GLOBAL connect_timeout=28800;
SET GLOBAL wait_timeout=28800;
SET GLOBAL interactive_timeout=28800;

Эти переменные задают критерии, используемые сервером для того, чтобы определить, какие соединения считаются неиспользуемыми, и их можно разорвать. Я поставил значение в 8 часов (28800 секунд), и разрывы соединения пропали. Подробнее о всех системных переменных базы данных MariaDB.

Обновление 1.

При перезагрузке сервера с базой данных, глобальные переменные к сожалению сбрасываются. Одно из возможных решений проблемы ошибки с разрывом соединения было описано в этом комментарии https://github.com/TryGhost/Ghost/issues/9739#issuecomment-406240883 Пользователь с ником Toub посоветовал периодически загружать главную страницу блога, чтобы платформа посылала запросы к базе данных, и соединение восстанавливалось.

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

'use strict';

const async = require('async'); // tested with  version >=2.6.2
const request = require('request'); //  tested with version >=2.88.0

let i = 0;
async.doWhilst(
  function (callback) {
    request('https://blog.vodolaz095.life', function (error, response) {
      if (error) {
        return callback(error);
      }
      i += 1;
      console.log('Test %s. Status code - %s', i, response.statusCode); // eslint-disable-line
      callback(null, response.statusCode);
    });
  },
  function (statusCode) {
    return statusCode !== 200;
  },
  function (error) {
    if (error) {
      throw error;
    }
    console.log('Blog awaken!');  // eslint-disable-line
    process.exit(0);
  }
);

И поставил его в крон на запуск каждую минуту.

* * * * * cd /home/vodolaz095/ && node /home/vodolaz095/wakeBlog.js

Посмотрим, что из этого получится…

Обновление 2

Скрипт для побудки блога проработал несколько лет. Но в 2026 году я решил делать личный сайт на Hugo. Поэтому, можно считать, что проблему я решил.

Полезные ссылки на документацию по языку программирования Javascript:

1. https://developer.mozilla.org/ru/
2. https://javascript.ru
3. https://nodejs.org/api/