HashiCorp Vault имеет в своём арсенале SSH secrets engine, который позволяет организовать защищённый доступ к вашим машинам по ssh, через создание клиентских сертификатов и одноразовых паролей. Про последнее – создание одноразовых паролей (OTP) – мы и поговорим в этой статье.

Всем привет. Меня зовут Ярослав. Вместе с моим коллегой Володей, мы представляем команду Sunshard. Нашей небольшой командой Hashicorp-энтузиастов мы решаем различные бизнес-задачи для команд разработки.

SSH/HTTPS/OpenVPN/Telegram и всё на одном порту?! Что?!
— Да!

Ключевые проекты

• Debian 8, ядро 4.19
• FRRouting (в версии 1.1 и более древних использовался Quagga)
• ISC-DHCP
• Keepalived
• StrongSwan
• OpenVPN
• PowerDNS
• Wireguard
• OpenNHRP
• Accel-ppp
• xL2tpd
• Squid
• mDNS-repeater
• IGMP-Proxy
• iPerf
• более детальный список в Release notes

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

Для диагностики модулей есть хорошая программа memtest86+, но если памяти у нас 1ТБ, то полное тестирование растягивается на несколько дней, а бизнес не может так долго ждать.

Как же быть? В этой публикации я поделюсь опытом тестирования памяти сервера Gigabyte R292-4S0 с СУБД на Enteprice Linux 8 (EL8) и 1 ТБ памяти двумя методами:

С EFI загрузкой memtest86+ v7;

С автоматизированным созданием сотни libvirt-KVM виртуальных машин с memtest86+ внутри.

Запуск memtest внутри виртуальной машины... "Фу...", - скажут некоторые. И будут неправы. Почему?

Не буду томить вас долгим вступлением. Ниже подробное описание этой реализации.

Введение

Угадай данную статью написал ChatGPT или нет?

Хотите потестировать приложение, или опробовать в работе инструмент? В этой статье опишу то, как организовал тестовый стенд на Linux. Стенд поддерживает работу с доменами, умеет генерировать TLS сертификаты, легко масштабируется, окружение строится по принципе IaaC, не требует много ресурсов, легко разворачивается скриптами или SCM, есть UI, не зависит от внешних сервисов.

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

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

В рабочих процессах клонирование Linux-хостов для меня стало обычным делом. Но однажды пришлось клонировать сервер с LVM и шифрованием LUKS на меньший по объему диск. И оказалось не все так просто.

Как урезать LVM и LUKS? Как правильно склонировать диск и расширить его обратно?
Рассказал все под катом.

В своем порыве использовать только технологии компании Red Hat, я решила освоить их first-party контейнерный стек. В основе стека лежит podman- движок для контейнеров, работающий без демон-процесса и без root привилегий по умолчанию. podmanинтегрируется в экосистему Red Hat - запуск контейнеров производится посредством systemd ; контейнеры интегрируются с SELinux. Конечно, самая главная причина использовать podmanвместо Docker - его включение по умолчанию в дистрибутив Red Hat Enterprise Linux и подобные.

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

Привет! Меня зовут Игорь, я управляющий партнёр и системный архитектор в KTS.

В этой статье, подготовленной по мотивам моего доклада в «Школе мониторинга» Slurm, хочу поделиться своим набором best practice «Как лучше всего настроить Grafana Loki для сбора логов в инфраструктуре». 

На мой взгляд, порог входа в систему достаточно низкий, и в Интернете много туториалов. Поэтому я расскажу о более сложных и не совсем очевидных вещах, с которыми не раз сталкивался при работе с Grafana Loki. 

Команда Kubernetes Platform в Quadcode внедряет, поддерживает и сопровождает Kubernetes и все процессы вокруг него. Пять с половиной лет наши кластеры и подходы менялись и эволюционировали. В статье расскажем, с чего мы начинали, к чему пришли, и как получилось сделать сопровождение bare metal кластеров комфортным.

Черновик статьи был написан еще год назад, когда я работал на крупном международном проекте, но из-за разных событий прошлого года он остался неопубликованным.

На проекте в моем ведении находилось несколько on-premise кластеров в нескольких европейских датацентрах. «Мы» в этой статье — небольшая команда DataOps из 5 человек.

Было дело я читал на Хабре статью про «Кластер Elasticsearch на 200 ТБ+» и примерял написанное к нам, у нас такой кластер считался средним, самый маленький кластер под 0,1Ptb, а большой тогда был под 0,5Ptb. Потом была поставлена задача подготовить кластер к увеличению объемов входящих данных в 2-3 раза, а срок хранения в 2 раза, т. е. объем хранимых данных, если грубо экстраполировать, должен был стать в районе 2-3Ptb.

Хочу поделиться нашим опытом, может кому пригодиться.

Сетевой стек — одна из самых запутанных вещей в Linux. И не только из-за сложности некоторых концепций и терминов, но и из-за изменения смысла некоторых параметров в разных версиях ядра. В этой статье приведена информация для ядра 2.2 и выше, а также, там где это возможно, указано различие между версиями вплоть до 5.5.

О том как изменять параметры ядра, описываемые здесь, можно прочитать в статье Linux Kernel Tuning for High Performance Networking: Configuring Kernel Settings.

Данная статья расскажет о том, как установить Ceph на несколько нод и установить Opennebula, а так же произвести интеграцию Opennebula с Ceph.

• Установка Ceph, распределенного хранилища. (Я буду описывать установку двухуровневого хранилища с кэширующим пулом из SSD-дисков)
• Установка MySQL, Galera кластера с мастер-мастер репликацией
• Установка софт-свича OpenvSwitch
• Установка непосредственно самой OpenNebula
• Настройка отказоустойчивого кластера
• Первоначальная конфигурация