UMGUM.COM (лучше) 

Стартовая  →   ( Развёртывание и поддержание сетевой инфраструктуры, конфигурирование коммуникационного оборудования и приложений, инсталляция и сервисное сопровождение серверов, а также консультирование по существу в области сетевого и серверного администрирования. )


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

Предлагаю услуги удалённого администрирования сетей передачи данных и серверов.

Я разрабатываю планы, внедряю и поддерживаю востребованное в области телекоммуникаций (каналы передачи данных, доступ в интернет, структурированные локальные сети), компьютеризации (оборудование офисов, центров хранения и обработки данных), а также информационных технологий вообще (операционные системы и приложения, программно-аппаратные комплексы), предпочитая решения на базе Cisco и Linux. Документирую процессы и оставляю внятные руководства к действиям. Пишите о своих желаниях.

Чиню то, с чем уже смирились и сочли особенностью реализации.

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

Делаю так, чтобы всё работало по возможности хорошо и незаметно.

Основным приобретённым профессиональным опытом я считаю навык системного подхода к решению производственных задач, что позволяет обеспечивать поддержание работоспособности вверенного сегмента ответственности на должном уровне с минимальными издержками, как временными, так и финансовыми.

Примеры успешно реализованных проектов.

Оформить заявку на проведение работ!

   [ просмотреть в полном объеме ]




Перевод 389-AS/DS на SSL  →   ( Решение проблем с проверкой валидности предлагаемого LDAP-сервером x509-сертификата, если таковой "самоподписанный (self-signed)". )

18 декабря 2019

OS: "Linux Debian/Ubuntu/RHEL/CentOS/", "MS Windows 7/10".
Application: LDAPS-клиенты.

После перевода на приём клиент-серверных подключений к LDAP-сервису "389-DS" только в зашифрованных SSL/TLS-соединениях может возникнуть проблема с проверкой валидности предлагаемого сервером x509-сертификата, если таковой "самоподписанный (self-signed)".

Прежде всего стоит проверить возможность подключения к LDAP-серверу посредством SSL/TLS-соединения, запросить сертификата и ознакомится с его параметрами:

$ echo QUIT | openssl s_client -connect ldap0.example.net:636 | openssl x509 -noout -text | less

Если SSL-сертификат "валидный" и вся цепь его электронных подписей проверяется вплоть до доверенных корневых удостоверяющих центров, то проблем с подключением у подавляющего большинства клиентов не предвидится.

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

   [ уже посетило: 114 ]   [ просмотреть в полном объеме ]


LDAP  →   ( Пишем простой сервис анализа журналов событий LDAP "389-DS" и представления свода количества подключений пользователей, без выдачи сведений о персоналиях. )

17 декабря 2019

OS: "Linux Ubuntu 16/18 (Xenial/Bionic) LTS".
Application: "LDAP 389-AS/DS v1.3", "Apache2", "Bash".

Задача: визуализировать статистику о количестве подключений пользователей к LDAP-сервису, без выдачи сведений о персоналиях.

Статистика нам потребовалась для отслеживания процесса миграции со старого LDAP-сервера на новые инстансы, с попутной нормализацией политики использования учётных записей. От описываемого здесь сервиса требовалось лишь показать таблицы с перечнями комбинаций "источник подключения - пользователь" для каждого инстанса. Этого легко добиться регулярным сканированием журналов событий "389-DS" и генерированием простейшей HTML-страницы с таблицей.

Картинок с примерами здесь не будет - слишком служебная информация на них - но выглядит это примерно как в аналогичном web-сервисе для "Eduroam".

   [ уже посетило: 116 ]   [ просмотреть в полном объеме ]


Zabbix  →   ( Мониторинг состояния компонентов LDAP-сервиса "389 Directory Server". )

16 декабря 2019

OS: "Linux Debian 8/9 (Jessie/Stretch)", "Linux Ubuntu 16/18 (Xenial/Bionic) LTS".
Application: "LDAP 389-AS/DS v1.3", "Zabbix v3/4".

Задача: наладить посредством системы мониторинга "Zabbix" отслеживание текущего состояния LDAP-сервиса "389 Directory Server", хранения статистики и уведомления о недоступности критически важных компонентов.

Общий принцип действия выработанного решения таков:

1. Раз в час "Zabbix" обращается за списком актуальных объектов мониторинга (в данном случае репликационных связей) к "Zabbix Agent"-у на стороне сервера "389-AS/DS", ожидая его в JSON-массиве.
2. Для полученного перечня объектов мониторинга сервером "Zabbix", в соответствии с заготовками в специализированном шаблоне, по спецификации "Low-Level Discovery (LLD)" создаются необходимые элементы.
3. Практически все запросы обрабатываются запускаемыми "Zabbix Agent"-ом самодельными скриптами, извлекающими данные через CLI-утилиту "ldapsearch".

Получившееся полностью автоматизированное решение отслеживает состояние локального LDAP-сервера и репликационных связей с другими LDAP-серверами по следующим позициям:

Наличие процесса сервиса "389-DS" (item/trigger, every 30sec);
Наличие открытого порта TCP:636 (item/trigger, every 30sec);
Доступность LDAP-сервиса для клиентских подключений (trigger, every 120sec);
Статистика количества текущих клиентских соединений (item/graph, every 60sec);
Статистика запрошенных клиентом и выполненных сервером операций (item/graph, every 60sec);
Статус каждого соединения репликации по отдельности (item/trigger, every 5min);
Задержки между репликациями для каждого соединения (item/graph, every 5min);
Информирование о длительном периоде без репликации (trigger, every 5hour).

   [ уже посетило: 125 ]   [ просмотреть в полном объеме ]


Перевод 389-AS/DS на SSL  →   ( Исправляем ошибки несовместимости "389 Console" с SSL/TLS-шифрованием в "Linux Ubuntu 18.04 LTS". )

13 декабря 2019

OS: "Linux Ubuntu 18.04 (Bionic) LTS".
Application: "389 Administration Server v.1.3.7", "Java v8/11", "389 Console".

В процессе перевода панелей управления LDAP-серверов "389-AS/DS" столкнулся с невнятной проблемой - GUI-утилита "389-console" не могла подключится к доступному только через SSL серверу администрирования.

   [ уже посетило: 101 ]   [ просмотреть в полном объеме ]


LDAP  →   ( Наладка равноправной взаимной "multi-master" репликации между LDAP-серверами "389-DS". )

12 декабря 2019

OS: "Linux Ubuntu 18 (Bionic) LTS".
Application: "389 Administration & Directory Server v.1.3.7", "Stunnel".

Задача: наладить равноправную взаимную "multi-master" репликацию пользовательской области данных между LDAP-серверами "389-DS", предварительно настроенными в соответствии с отдельной инструкцией на этом сайте.

В документации заявлено, что "RHDS v10" поддерживает до 20 (двадцати) одновременно работающих связей репликации "multi-master". Не уверен, но возможно у его бесплатного аналога "FDS v1.3" есть ограничение до 4 (четырёх) связей репликации "multi-master" - но нам этого вполне хватит, так как планируется одновременная работа трёх LDAP-серверов.

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

1. Настраиваем "потребителей (consumers)" данных.
2. Настраиваем "поставщиков (suppliers)" данных.
3. Инициируем связи, поочерёдно для всех поставщиков.
4. Проверяем успешность и полноту синхронизации данных.
5. Опционально настраиваем связку с сервером, не поддерживающим SSL.
6. Обнаруженные проблемы.

   [ уже посетило: 101 ]   [ просмотреть в полном объеме ]


LDAP  →   ( Защищаем сетевые соединения LDAP-инстанса "389-DS" и сервера администрирования "389-AS" SSL/TLS-шифрованием с последующим отключением небезопасного протокола доступа. )

11 декабря 2019

OS: "Linux Ubuntu 18 (Bionic) LTS".
Application: "389 Administration & Directory Server v.1.3.7", "OpenSSL".

Задача: защитить клиент-серверные соединения LDAP-инстанса "389-DS" и сервера администрирования "389-AS" SSL/TLS-шифрованием с последующим отключением небезопасного протокола доступа.

Сервисы "389-DS" могут обслуживать клиентов как в открытом виде, так и в защищённом SSL/TLS-шифрованием соединении, при этом поддерживается три режима работы:

1. Open LDAP, TCP:389 - передача данных в открытом виде.
2. LDAP with StartTLS, TCP:389 - включение шифрования данных по требованию клиента.
3. LDAPS with SSL/TLS, TCP:636 - обязательное шифрование передаваемых данных.

Таким образом, при подключении к LDAP-сервису клиент может выбрать, насколько защищённое соединение ему устанавливать, в зависимости от секретности задачи.

Зачем применять шифрование клиентских соединения при работе с LDAP, внутри которого пользовательские пароли хранятся в виде "хешей"? На удивление многие считают, что если пароль на стороне сервера "хеширован", то и на этапе аутентификации при подключении он не будет раскрыт. Налицо отсутствие причинно-следственной связи, но не всем это понятно без демонстрации доказательств.

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

   [ уже посетило: 168 ]   [ просмотреть в полном объеме ]


LDAP  →   ( Развёртывание и настройка LDAP-сервера "389-AS/DS", с последующим созданием заготовки структуры записей и учётных записей для управления таковыми, а также активацией необходимых плагинов и схем данных. )

10 декабря 2019

OS: "Linux Ubuntu 18 (Bionic) LTS".
Application: "389 Administration & Directory Server v.1.3.7".

Задача: развернуть и настроить LDAP-сервер "389-AS/DS", с последующим созданием заготовки структуры записей и учётных записей для управления таковыми, а также активацией необходимых плагинов и схем данных.

Последовательность дальнейших действий такова:

1. Подготовка системного окружения (отдельная инструкция).
2. Установка и первичная настройка.
3. Создание простой структуры записей данных.
4. Запрещение анонимного доступа к данным LDAP.
5. Разрешение пользователям корректировать свои профили.
6. Создание учётных записей администраторов DIT.
7. Создание учётных записей операторов DIT.
8. Создание сервисных учётных записей.
9. Оптимизация процедур выявления групповой принадлежности.
10. Оптимизация процедуры выделения "Posix UID & GID".
11. Добавление атрибутов и классов в схему данных.
12. Экспорт и импорт данных.

   [ уже посетило: 101 ]   [ просмотреть в полном объеме ]


LXC/LXD  →   ( Запуск приложения в LXD-контейнере, на примере установки, простейшей настройки и проверки функциональности "389 Directory Server". )

4 декабря 2019

OS: "Linux Ubuntu 16/18 (Xenial/Bionic) LTS".
Apps: "LXD v.3.0.3", "389 Directory Server v.1.3.7".

Задача: запустить приложение в изолированной среде LXC-контейнера, с управляющей обёрткой LXD, на примере установки, минимальной предварительной настройки и проверки функционирования LDAP-сервиса в реализации "389 Directory Server".

Последовательность дальнейших действий такова:

1. Подготовка системного окружения и установка сопутствующего ПО;
2. Преднастройка компонентов LXD;
3. Создание LXD-контейнера желаемого типа;
4. Установка и запуск LDAP-сервиса внутри LXD-контейнера;
5. Проверка функциональности LDAP-сервиса и создание своего DIT;
6. Клонирование LXD-контейнера.

   [ уже посетило: 482 ]   [ просмотреть в полном объеме ]


LXC/LXD  →   ( Запуск приложения в LXC-контейнере, на примере установки, простейшей настройки и проверки функциональности "OpenLDAP Server". )

23 ноября 2019

OS: "Linux Ubuntu 16/18 (Xenial/Bionic) LTS".
Apps: "LXC v.3.0.3", "OpenLDAP v.2.4.45".

Задача: запустить приложение в изолированной среде LXC-контейнера, на примере установки, минимальной предварительной настройки и проверки функционирования LDAP-сервиса в реализации "OpenLDAP standalone server".

Последовательность дальнейших действий такова:

1. Подготовка системного окружения и установка сопутствующего ПО;
2. Преднастройка компонентов LXC;
3. Создание LXC-контейнера желаемого типа;
4. Установка и запуск LDAP-сервиса внутри LXC-контейнера;
5. Проверка функциональности LDAP-сервиса и создание своего DIT;
6. Клонирование LXC-контейнера.

   [ уже посетило: 1372 ]   [ просмотреть в полном объеме ]


← Ctrl → Старее →
66  65  64  63  62  61  60  59  58  57  ...  Первая →