Серверное администрирование *

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

Мы подготовили подборку историй о трудностях, с которыми столкнулась команда сервисных инженеров К2Тех за последние два года. Только не ждите героических сказаний — речь пойдет о тяжелой повседневной работе без прикрас и купюр. 

ChatGPT-4o написал Python-скрипт на 400 строк, который с помощью API Cloudflare переносит домены со всеми настройками между разными аккаунтами. В статье подробно рассмотрен процесс создания скрипта, включая сохранение и копирование настроек и DNS-записей. Также приводятся примеры кода и пояснения, позволяющие легко адаптировать решения под конкретные задачи.

Представьте: вы решили (или жизнь за вас так решила) перевести сотрудников с Windows на Linux. Сегодня я расскажу, как это сделать и при этом сохранить пользователям доступ к привычным приложениям. 

Проблему будем решать на примере нашего терминального сервера Termit. Под катом вы найдете пошаговую инструкцию, как с его помощью настроить терминальный доступ к Windows-приложениям. 

В SQL server есть замечательная технология - AlwaysOn. Она используется для DR (disaster recovery, асинхронная репликация данных), HA (high availability, часто с automatic failover, что возможно при синхронной репликации), и для того, что мы обсудим в статье: readonly replica для DWH/OLAP/Reporting workload.

Ничто не совершенно (хотя я восхищаюсь простотой установки некоторых решений в MS SQL по сравнению с Postgre и Oracle. Хотя бы бэкапы... А AlwaysOn для маленьких баз заводится буквально в пару кликов).

Cегодня мы рассмотрим проблемы при использовании AlwaysOn для DWH/OLAP/Reporting.

«‎Не могу поверить, что они догадались до этого первыми». Именно такая мысль пронеслась у меня в голове в середине декабря после нескольких недель работы по 12 часов в день, когда я отлаживал причины медленной работы кластера. Это был, пожалуй, самый интенсивный анализ производительности, который я проводил со времен Inktank. 

В моем сознании промелькнули полузабытые суеверия из 90-х о том, как получить благосклонность богов SCSI. 90-х? Блин, я старею. Мы прошли примерно две трети пути, который позволил бы нам начать с самого начала. Кстати говоря, я начну с самого начала.

В 2023 (я почти написал «в начале года», пока не вспомнил, что уже 2024) году в компанию Clyso обратилась довольно популярная и передовая компания, которая хотела перевести свой Ceph-кластер с HDD на NVMe-диски объемом 10 петабайт. Они сразу же заинтересовали нас. У них не было особых потребностей в RBD, RGW или CephFS. У них было свое представление, о том какое оборудование необходимо, но, к моей радости, обратились к нам, прежде чем что-то покупать. 

Open source проект – это не только код.

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

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

Данная статья написана только в образовательных целях и автор не несёт ответственности за ваши действия. Ни в коем случае не призываем читателей на совершение противозаконных действий. Материал размещен только с целью ознакомления и принятию мер по обеспечению безопасности. Использование материалов в противоправных и противозаконных запрещено законом РК. Все персоны или принадлежность к кому-либо только в голове у автора. Любые совпадения с реальностью абсолютно случайны.

Сегодня я начинаю небольшой цикл статей, посвященных операционной системе Microsoft - Azure Stack HCI. Да, именно посвященных ОС, а не решениям Azure, рассматривать я буду именно серверную ОС на базе ядра Windows Server с названием издания Azure Stack HCI, которая вот уже пять лет как ежегодно выходит по программе ежегодного (не долгосрочного) цикла выхода серверных ОС. На данный момент мой план таков:

1) В первой (этой) статье я опишу своё видение того, что такое Azure Stack HCI, чем он отличается от ОС Windows Server Datacenter Azure Edition (Core), что отличает Azure Stack HCI от сервисов Azure Stack, самое главное, для чего вам такая странная ОС в вашем датацентре;

2) Во второй статье я буду рассказывать о том, что такое Hot Patching, - процедура установки обновлений безопасности Microsoft без перезагрузки, какие требования к ОС имеются, - и самое главное, как обойти обязательность наличия подписки Azure, то есть как пользоваться Hot Patching в вашем датацентре без каких-либо Azure Benefits, как создавать виртуальные машины на базе ОС Windows Server и любых её ролей так, чтобы обновления ОС внутри ВМ не требовали их перезагрузки (как вы прекрасно понимаете, обновление хост ОС не требует перезагрузки ВМ в виду живой миграции между узлами кластера). Это весомый аргумент в пользу виртуализации Windows сервисов именно на базе Hyper-V;

3) В третьей статье я расскажу о том, как превратить ОС AzureStackHCI, которая поставляется исключительно в режиме Server Core в ОС с полным рабочим столом, чтобы у вас была возможность полноценно её администрировать. Причем сделать это таким образом, чтобы на ОС все так же продолжали приходить обновления с Windows Update.

В этом подробном гайде я расскажу о том как запустить и настроить Dash Evonode c помощью dashmate. Будут затронуты аспекты выбора и настройки VPS, установка сопутствующих зависимостей и прочее.

Создание собственного облачного хранилища с автоматическим менеджером фотографий.

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

Существует огромное количество руководств, статей, видеоуроков по bash. И это очень здорово, но есть одна проблема с ними. Процент материала "для начинающих" среди всего этого богатства стремится к 100, а вот по-настоящему интересных тонкостей касаются не только лишь все.

Я всегда любил bash-скриптинг, и сейчас пишу довольно много кода на bash. Периодически наталкиваюсь на неочевидные моменты; решил, что настала пора поделиться опытом с уважаемым хабрасообществом.

Кому интересно разобраться, что же может быть не так с bash/zsh на этот раз -- добро пожаловать под кат.

Существующие варианты реализации 2FA для OpenVPN основываются на модуле google-authenticator-libpam для OTP‑кодов и плагинов аутентификации OpenVPN libpam-radius-auth, openvpn-plugin-auth-pam, openvpn-auth-ldap и имеют ряд недостатков как для пользователя так и для администратора.

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

• использовать для аутентификации пользователей логин и пароль из LDAP‑каталога.

• удобно вводить логин, пароль, OTP в отдельные независимые поля интерфейса, а не после пароля или вместо пароля.

• реализовать различные комбинации использования логина, пароля, OTP в зависимости от задач.

• обеспечить отказоустойчивость, возможность использования нескольких серверов аутентификации.

• использовать LDAP‑каталог для централизованного управления пользователями.

• хранить seed‑значения для генератора OTP независимо от того, какой LDAP‑каталог используется (ActiveDirectory, FreeIPA, lldap или другие).

• передать функцию создания, обновления seed‑значений для генератора OTP техподдержке без необходимости подключаться к серверам OpenVPN.

• использовать на смартфонах любое приложение для генерации OTP (Яндекс.Ключ, FreeOTP Authenticator и др.).

• не зависеть от работоспособности облачных провайдеров 2FA.

Система рассчитана на следующие сценарии использования:

• доступ пользователей через OpenVPN в инфраструктуру компании.

• резервный самодостаточный безопасный удаленный доступ в инфраструктуру для администраторов на случай аварий или сбоев.

В обоих сценариях:

• не предполагается использование персональных сертификатов для каждого пользователя. Однако, это не исключает использования сертификатов в качестве дополнительной меры защиты.

• для аутентификации используется логин, пароль и OTP.