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

Как связать пару тысяч ИП и маркет?

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

Рассказываем на примере кейса XWAY. Переходите в Академию Selectel чтобы узнать, как компания:

• Построила гибридную и отказоустойчивую инфраструктуру с обработкой 1 000 запросов в секунду.

• Использует облачные серверы, Managed Kubernetes и выделенные серверы от Selectel для обеспечения высокой производительности.

• Обеспечивает быструю и надежную сетевую связность при уровне SLA 99,98%

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

Лондон-Париж. Дедики там, блики крыш

Невозможно не вспомнить когда-то популярную песню. И невозможно не рассказать, что мы открыли целых 2 новых локации для выделенных серверов — Лондон и Париж.

Итак, в наличии по 5 сборок (но скоро могут разобрать, успевайте):

💂В Великобритании:

Минимальная: AMD EPYC 3151, 4 ядра, 2.7 ГГц, 8 потоков, 32 ГБ RAM, 1 ТБ NVMe — за 7 800 ₽/мес

Максимальная: AMD EPYC 7702, 64 ядра, 2.0 ГГц, 128 потоков, 512 ГБ RAM, 2 × 2 ТБ NVMe — за 27 300 ₽/мес

🥐 Во Франции:

Минимальная, как и у британских соседей.

Максимальная: 2 × AMD EPYC 7742, 64 ядра, 2.25 ГГц, 128 потоков, 512 ГБ RAM, 2 × 2 ТБ NVMe — за 48 100 ₽/мес

Пополнить коллекцию дедиков →

Доброго дня. В этом посте хочу описать способ развертывания приложений в Docker на Linux сервере без использования реестра. Для этого нужно:

1. Сохранение образа docker save -o myimage.tar myimagename

2. Передача файл myimage.tar на сервер по FTP или любым другим способом

3. Загрузка образа docker load -i myimage.tar или podman load -i myimage.tar

Такой способ позволяет разворачивать Docker‑образы без использования реестра — просто, удобно и быстро. Если у вас по любой причине нет реестра, но хочется использовать Docker, вы можете найти это полезным. Надеюсь, кому‑то пригодится в реальной практике. Если вы используете другие подходы или автоматизируете процесс — поделитесь в комментариях. Спасибо за внимание!

Мы используем коммутаторы Arista с rear-to-front обдувом, что очень удобно для кабель-менеджмента, поскольку вся укладка кабелей как правило происходит с тыльной стороны стойки, при этом спереди всё выглядит минималистично и без проводов. Но вот что бывает когда стойка узкая, в нашем случае всего 600мм. Стойка, кстати, российского бренда NTSS. По бокам есть Zero-U лотки для крепления PDU, но они недостаточно утоплены вглубь. Да и PDU достаточно жирные — APC 8886. Мы также попробовали установить родные PDU от NTSS, но проблему это не решило.

Уши на этих рельсах сделаны как единое целое и снять их невозможно. Чтобы вытащить свитч, необходимо сначала вытащить оба PDU. подобные свитчи достаточно тяжелые, поэтому для крепления в стойке рекомендуется использовать рельсы вместо ушей. Да и предполагалось что рельсы упростят работу с оборудованием, а не усложнят её :(

Что делать — непонятно. На ум приходит только спилить эти уши, но в таком случае свитчи уже будет невозможно прикрутить к стойке. Ставить свитчи вперёд тоже плохое решение, особенно с точки зрения кабель-менеджмента, да и потребуется заменить 18 блоков питания и 36 вентиляторов чтобы развернуть направление обдува :(

Также есть вариант с универсальными рельсами и полками, но это тоже так себе решение, которое потребует доработок.

Ставить горизонтальные PDU вместо вертикальных тоже не хотим, это усложнит кабель-менеджмент.

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

Самое печальное, по моему личному опыту, что в 99% случаев в аренду предлагают стойки шириной 600мм, не больше. А если хочешь шире — то разница в цене будет огромная, так как такая стойка занимает уже больше одной плитки. Да и в текущих реалиях ЦОДы забиты, мест для таких стоек крайне мало.

Что интересно, даже новые ЦОДы везде повально экономят на ширине стоек и ставят эти несчастные 600мм узкие стойки.

Как известно, основной глобальный инструмент для просмотра логов Certificate Transparency (CT-логов) через веб-интерфейс - это crt.sh. Однако сертификаты российских УЦ в глобальные логи пока не попадают (перечень принимаемых сертификатов и пресертификатов в CT-логе всегда ограничен некоторым набором корневых ключей). Для российских УЦ запущены российские CT-логи. Для просмотра российских CT-логов тоже есть сервисы с веб-интерфейсом:

• ct.tlscc.ru - это выделенный экземпляр crt.sh, поддерживаемый ТЦИ и настроенный на российские логи; веб-сайт использует TLS-сертификат, выпущенный от корня ТЦИ, так что если корня в браузере нет, то будет выдаваться предупреждение; (пример запроса);

• precert.ru - отдельный и весьма удобный сервис, имеющий целый ряд преимуществ: например, здесь другой интерфейс для поиска записей, подробная статистика по логам и УЦ; (пример запроса).

Сейчас в российские CT-логи добавляются сведения о сертификатах, выпускаемых НУЦ (все логи) и ТЦИ (логи "Яндекса" и VK). Основной объём логов составляют пресертификаты, которые добавляют сами УЦ, в процессе выпуска сертификата. Пресертификат отличается от сертификата наличием специального расширения (CT Poison), отсутствием SCT-меток и значением подписи. Обратите внимание, что сертификаты добавить в CT-лог может каждый. Например, можно добавить сертификат, найденный на каком-то веб-узле в Сети (если, конечно, сертификат выпущен подходящим УЦ). Но для добавления придётся уже воспользоваться HTTP-интерфейсом соответствующего лога напрямую, подготовив и отправив POST-запрос.

Зачем просматривать CT-логи? Во-первых, наличие сторон, изучающих записи в CT-логах, это основной декларируемый смысл Certificate Transparency. Во-вторых, просмотр логов позволяет пронаблюдать, что и для чего выпускается, и даже минимально контролировать выпуск сертификатов для тех доменов, которые вы администрируете; Certificate Transparency не гарантирует, что сведения о выпущенном сертификате будут в CT-логе, но такие сведения могут там быть, а сам по себе сертификат, благодаря наличию цифровой подписи, это какой-никакой, но документ, подтверждающий хотя бы свой собственный выпуск. В-третьих, в логах можно найти что-то неожиданное - для этого внимание нужно обращать на таймстемпы, на формат (пре)сертификатов, на состояние конкретных лог-сервисов.

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки - шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS - есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз - для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

Так что, вместо возни с автоматическим перевыпуском суперкоротких сертификатов, центральный сервис может выдавать квитанции доступа на каждую TLS-сессию. Естественно, TLS-сертифкат сервера должен быть предъявлен раньше, чем отправлено сообщение с подписью CertificateVerify. Однако эти сообщения в TLS передаются сервером одной серией, поэтому, в процессе создания TLS-сессии, сервер сможет сразу же получить от центрального узла и сгенерированный только что сертификат, и соответствующую подпись, собрать это всё вместе и отправить клиенту.

Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify - TLS-сессия браузером установлена не будет.

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

Пишут, что CA/B-форум согласовал дальнейшее сокращение интервала валидности TLS-сертификатов: теперь планируют к 2029 году уменьшить этот интервал до 47 дней. Ожидаемо. Я бы предположил, что ещё короче сделают (да и, фактически, раньше; например, Let's Encrypt уже готовит шестидневные сертификаты).

Тенденция коснётся и сертификатов, выпускаемых "собственными УЦ": если браузер принципиально не верит сертификатам только на основании длительности их интервала валидности, то не играет роли, был ли добавлен корневой ключ УЦ вручную или приехал в составе дистрибутива. (Технически, да, урезать действие ограничения для "домашних" сертификатов можно, но вряд ли имеет смысл на это рассчитывать.) Кроме того, строго автоматический выпуск сертификатов - требует наличия подходящего API на стороне УЦ, тоже немаловажный технологический фактор.

Интересно, что TLS-сертификаты становятся больше похожи на квитанции доступа. Что-то вроде тикетов в каком-нибудь глобальном Kerberos, только повёрнуто в сторону к клиенту, который с браузером. При этом всякий веб-узел должен постоянно и автоматически отмечаться на центральном сервисе, получая новую квитанцию, которая разрешает браузерам доступ. Ну или квитанцию сервис не выдаёт, тогда доступ к веб-узлу для браузеров отключается автоматом. Да, нужно будет ещё в браузерах отключить возможность "отменить предупреждения безопасности" простым способом, но это уже детали.

Чемпионат мира по метанию серверов на фестивале CloudFest-2025

CloudFest – ежегодный фестиваль интернет-индустрии и облачных вычислений, прошедший в Германии с 17 по 20 марта 2025 года и привлекший почти 9 тысяч посетителей. Мероприятие традиционно проводится в Европе-Парке в Шварцвальде и имеет достаточно насыщенную программу: 250 выступающих от 150 компаний-участников из 80 стран. Доклады, мастер-классы, новинки от гигантов индустрии, стартапы и проч. … но, по понятным причинам шоу-стоппером и гвоздем фестиваля стал чемпионат по метанию серверов – World Server Throwing Championship (WSTC). 

Метались серверы высотой 1U весом примерно 10 кг. (Говорят, можно даже было приносить свои серверы, но это не точно). Здесь всё как в большом спорте – громкие прозвища, например, Бартош-Зверь, Дирк-Машина, чемпионские пояса, анонсеры, чирлидерши и проч. 

В конкурсе принимали участие как мужчины, так и женщины – единственное требование к участникам – надеть перчатки дабы не поранить руки о края девайса и желание метать сервер %&#* далеко (орфография сохранена). 

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

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

Официальный ролик дополняет любительское видео.

Устроители шутят (или нет?) и поговаривают, что в будущем следует ожидать включение этого вида спорта в олимпийскую программу.

Комменты под видео в сети:

 - Надо биатлон устроить: Сначала пишут код, который выполняет какую-то полезную работу на сервере, подключенном только к ИБП. Потом метают ИБП и сервер. Результаты суммируют.

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

- Там от сервера - одно название. Ни тебе процессора с кулером, ни Хардов, ни РАМы, ни рек-Маунт-китов.

- Честно говоря, это самое приятное мероприятие, которое я когда-либо видел. 

- Линукс знает, как падать. 

- Обычный день сисадмина.

Внимание, админы! Broadcom опять закручивает гайки и вводит штрафы задним числом для подписчиков VMware.

Как заговорить с сетевиками на одном языке? 😎

В Академии Selectel появился бесплатный курс «Погружение в компьютерные сети». Он поможет разобраться в принципах работы, понять ключевые термины и уверенно ориентироваться в основах. Всего час — и сложные вещи станут простыми.

Курс подходит новичкам, которые хотят разобрать тему по полочкам. Но и опытным специалистам будет полезно: с этими материалами вы восполните пробелы в знаниях и вспомните все, что забылось со временем.

Начните обучение в Академии Selectel прямо сейчас ➡️

Как сделать сервис быстрым и безопасным?

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

Ваша задача — сделать так, чтобы поддержка стабильно работала даже под высокой нагрузкой, персональные данные были в безопасности, а важная информация случайно не пропала. Справитесь? Вот платформа Юздеск справляется на инфраструктуре Selectel.

В Академии Selectel рассказываем, как компания:

• добилась 100% соответствия инфраструктуры 152-ФЗ и готовности к аттестации по требованиям ФСТЭК,

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

• стабильно работает при средней нагрузке 1 500 RPS.

Представим, что у нас некоторая система, состоящая из микросервисов, которые работают на разных машинах, но внутри общей IP-сети на немаршрутизируемых IP-адресах (10.0.0.0/8, 192.168.0.0/16 и т.д.). Микросервисы разговаривают друг с другом по TCP, подключаясь по IP-адресам, указанным в соответствующих конфигурационных файлах каждого. Но можно указать и не IP-адрес, а некий хостнейм, прописав его же в /etc/hosts. Почему-то часто считают, что "хостнейм эквивалентен IP-адресу". Оно, конечно, удобно так считать, с точки зрения "человекопонятности", но не всегда хорошо с точки зрения безопасной настройки.

Дело в том, что опечатка (или намеренная замена символа) в имени хоста может привести к тому, что адрес окажется в чужой DNS-зоне. Простейший случай: users-db.example.com -> users-db.example.co. Да, должно быть закрыто, да, есть .local, а хостнеймы можно записывать одним "лейблом", но это не решает проблему: использование символьного хостнейма гарантирует дополнительные запросы для разрешения имён, будь то локальные запросы на той же машине или запросы внешние, возникшие из-за опечатки. А всякий, даже локальный, библиотечный/системный вызов, выполняющий трансляцию имён и адресов, готов принести с собой неожиданные эффекты (см. ниже пример уже про IP-адреса). Не обязательно это эффекты от подмены библиотеки или подмены конкретного вызова. А если кто-то умеет записывать в /etc/hosts, то он и конфиг любой поправит. Что, впрочем, не всегда так, поскольку раскладывание hosts по машинам могут автоматизировать - тогда перехватить нужно только точку управления скриптом, формирующим файл. А ведь ещё обычно используется два протокола: v6 и v4, адреса и "резолвинг" там разные.

Если в конфигах микросервисов прописывать непосредственно IP-адреса (пусть и автоматом), то ситуация несколько лучше. Есть неплохие шансы, что трансляция имён/адресов не будет использована. Минимальная опечатка в записи немаршрутизируемого адреса реже приводит к тому, что трафик убегает наружу. Это так потому, что, во-первых, на то они и немаршрутизируемые; во-вторых, в таких системах обычно настраивают различные ACL, а они настраиваются для IP, в других местах, не на конкретной машине с микросервисом, да и пальцы у настраивающих ACL дрожат по-иному.

Тут, впрочем, необходимо отметить некоторые тонкости: ping 010.010.010.010 -- на многих и многих системах отправит пакеты в сторону серверов Google (проверьте). Я раньше рекомендовал использовать этот довольно хитрый "оборот" в рамках собеседований на должность сетевого инженера/разработчика (теперь уже смысла, понятно, нет), поскольку понимание того, почему здесь пакеты уходят в сторону сети Google, раскрывает основную часть опасений, связанных с использованием имён хостов в конфигах. Но всё же, в 010.010.010.010 - более одной "опечатки".

Гигабит в Нидерландах

• Расширили линк до дата-центра до 400 Гбит/с

• Поставили новые 100G свитчи

• И, наконец, завезли мощный маршрутизатор MX304

И как вишенка на торте. Все это великолепие дало нам возможность открыть новую линейку тарифов со скоростным интернетом до 1 Гбит/с.

1 CPU, 1 ГБ RAM, 15 ГБ NVMe + IP за 950 руб/мес, и далее по возрастанию конфигов. Все гигабитные тарифы уже доступны и в панели, и на сайте.

Сервер с 1 Гбит/с — сюда →

Let's Encrypt больше не будет отправлять уведомления по электронной почте об истечении срока действия сертификатов

Ну что ж, вот и кончилась эпоха... С момента своего создания Let’s Encrypt отправлял уведомления об истечении срока действия сертификатов по электронной почте подписчикам, которые предоставили им свой адрес. Однако, начиная с 4 июня 2025 года, данная рассылка будет прекращена.

Let’s Encrypt приводит следующие аргументы в поддержку этого решения:

1. За последние 10 лет подавляющее большинство подписчиков внедрили автоматизированные системы обновления сертификатов, которые являются более надёжными, чем получение уведомлений по электронной почте.

2. Для рассылки уведомлений Let’s Encrypt вынужден хранить миллионы адресов электронной почты, что негативно сказывается на конфиденциальности. Сокращение объёма хранимых данных рассматривается как приоритетная задача.

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

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

Для тех, кто хочет продолжать получать уведомления об истечении срока действия сертификатов есть возможность воспользоваться сторонним сервисом Red Sift Certificates Lite (https://redsift.com/pulse-platform/certificates-lite). Мониторинговый сервис Red Sift предоставляет уведомления бесплатно для 250 сертификатов.

Несмотря на заявленное стремление сокращать количество хранимых адресов для рассылки уведомлений об истечении срока действия сертификатов, рассылки о новостях Let’s Encrypt и ее материнской компании ISRG (https://www.abetterinternet.org/) не прекратятся... А те кто не успел на них подписаться даже могут это сделать. Правда, как это сочетается с желанием сократить общую сложность инфраструктуры, я уже не могу и предположить.

Для тех, кто еще не добавил автоматическое обновление сертификатов на свой сервер – вот подходящая команда для cron (пытается обновить сертификаты через каждые трое суток):

0 2 */3 * * /usr/bin/certbot renew --quiet >/dev/null 2>&1

Добавить ее можно путем вызова команды crontab -e

Обратите внимание что после ввода строки надо обязательно нажать Enter!

Создать Telegram-бота и получить за это подарок от Selectel?

Да, это возможно, если вписаться в наш интерактив. Вот что нужно сделать:

1. Создайте бота и опубликуйте репозиторий на GitHub.

2. Пришлите ссылку на репозиторий в Telegram-канал SelectelFeedbackBot, чтобы получить бонусные рубли для панели управления.

3. Задеплойте бота в облаке Selectel, оплатив услуги полученными баллами.

4. Отправьте ссылку на бота в Telegram-канал SelectelFeedbackBot.

Мы будем ждать ваших сообщений до 2 марта 2025 года, после чего подведем итоги. 10 счастливчиков получат комплект мерча Selectel: картхолдер, кружку и плюшевого Тирекса 🦖

Если готового бота у вас еще нет и вы вообще таким не занимались, то у нас в Академии Selectel есть пример для вдохновения — пошаговый гайд по созданию бота для прогноза погоды. На всякий случай есть еще инструкция, как задеплоить бота на сервер (мало ли).

Полные правила конкурса доступны по ссылке. Узнать обо всем чуть подробнее можно в нашем Telegram-канале.

Из Let's Encrypt сообщают, что выпустили первый TLS-сертификат сроком действия шесть дней. Сделать такие TLS-сертификаты доступными для всех планируют к концу 2025 года. Короткоживущие сертификаты не будут содержать ни ссылки на OCSP-респондер, ни ссылки на точку раздачи CRL. То есть, никаких механизмов проверки статуса (отзыва) в сертификате не предусмотрено. Такой вариант допускается для короткоживущих сертификатов требованиям CA/B-форума (организация, через которую определяются требования к УЦ, корневые ключи которых включаются в дистрибутивы браузеров).

Для подключения шестидневных сертификатов нужна поддержка соответствующих профилей в ACME-клиенте. Очевидно, заказ короткоживущих сертификатов для легитимных, - долгоживущих, - сайтов имеет смысл выполнять только полностью автоматически. Зато такие сертификаты обещают и для IP-адресов, что удобно в ряде сценариев использования. DNS для подтверждения управления IP-адресами не подходит. Поэтому проверяется только факт управления узлом под заданным IP-адресом, а не доменной зоной. И такая проверка будет происходить не только по HTTP, но и довольно экзотическим методом TLS-ALPN, который целиком работает на уровне TLS и вообще не виден для веб-сервера, работающего выше TLS.

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

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

Эта строгая тенденция к снижению срока действия сертификатов, которым браузеры соглашаются верить, достаточно давняя - ей около десяти лет. А хорошим подтверждением курса на "сверхкороткие" сертификаты является то, что в рекомендациях CA/B-форума для таких сертификатов уже закреплено отсутствие требования ссылки на CRL (OCSP сейчас не является обязательным для любых оконечных сертификатов).

Часто в разных скриптах, обрабатывающих серверные TLS-сертификаты, - скажем, для мониторинга, - в качестве источника "целевого" имени при выборе сертификата используется содержание Subject/CN (commonName). Предполагается, что в Subject/CN должно быть доменное имя. Вот типичный пример:

$ openssl x509 -in disruptive.pem -subject -noout -nameopt multiline | awk -F' = ' '/commonName/ {print $2}'
disrupted.zone

Однако, если речь про сертификаты для TLS в современном вебе и про имена, то полагаться тут на Subject нельзя. Нужно использовать другой фрагмент сертификата, а именно - расширение SAN (Subject Alternative Name).

Для извлечения расширения SAN при помощи OpenSSL x509 нужно использовать опцию -ext subjectAltName. Выдача состоит из списка, где каждому значимому элементу соотвествует префикс, обозначающий тип. DNS-имена OpenSSL выводит с префиксом "DNS" (кто бы мог подумать!). Пример:

$ openssl x509 -in google-com.cert.pem -noout -ext subjectAltName
X509v3 Subject Alternative Name: 
    DNS:*.google.com, DNS:*.appengine.google.com
[...]

Кроме "DNS" могут встретиться другие префиксы, обозначающие IP-адреса и т.д. Однако для обработки имён - нужны имена, то есть "DNS". Скрипт, конечно, несколько усложнится. Пример:

$ openssl x509 -in google-com.cert.pem -noout -ext subjectAltName \
> | awk 'NR>1{split($0,A,",");for(k in A){split(A[k],B,":"); if(B[1]~/DNS/){print B[2]}}}' \
> | wc -l
135

Причина использования SAN в том, что имя из поля Subject/CN оконечного (серверного) сертификата браузеры давно не используют в качестве идентификатора при валидации. А чтобы валидация сертификата для веб-узла прошла успешно (в браузере), необходимо наличие подходящего имени в SAN. Более того, современные требования для УЦ по выпуску TLS-сертификатов ("документы CA/B-форума") прямо не рекомендуют использование поля commonName в Subject оконечных сертификатов для веб-узлов. Это значит, что доменного имени в Subject может просто не оказаться, но сертификат (при прочих равных) будет валидным для браузера.

Чего ждет бизнес от облачной IT-инфраструктуры? ☁️

Гибкости в управлении, легкой масштабируемости, оперативного решения вопросов через техподдержку, защищенности от внешних воздействий. А еще того, что обслуживание этой инфраструктуры ляжет на плечи провайдера. С такими ожиданиями московский девелопер Level Group мигрировал в Selectel.

В кейсе рассказываем, как компания:

• бесплатно мигрировала в частное облако и повысила доступность корпоративных сервисов,

• организовала сетевую связность, объединив все узлы инфраструктуры в единую сеть без доступа в интернет, 

• отказалась от капитальных затрат в пользу операционных и сократила расходы на инфраструктуру на 30%.

Подробности кейса — в Академии Selectel.

Запустили выделенные серверы с мгновенной установкой

Надеемся, что вы хорошо отдохнули за долгие выходные и готовы к новым релизам. И вот первый из них — в панели появились конфиги выделенных серверов, которые готовы к запуску сразу после заказа. Без участия менеджера и дополнительного времени на обработку.

Доступно для конфигураций в Санкт-Петербурге с каналом 1 Гбит/с и ОС Ubuntu 22.04. Найти их можно на отдельном табе «Мгновенная установка» с иконкой⚡️

Остается только убедиться, что на балансе есть нужная сумма, нажать «Заказать», и сервер сразу же будет готов к работе.

Получить конфиг в один клик →

Новогодняя задача: помогите Тирексу поставить и нарядить елочку

Условие

Сисадмин Тирекс засиделся допоздна и не успел не то что нарядить елку, но даже купить ее! У него нет главного символа праздника, но есть лапки, компьютер, IDE, технический склад ума и знание Python.

Задача

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

• на вход программа получает два числа: rows отвечает за высоту елки в строчках (не менее трех), freq — за частоту появления украшений.

• ветки елки — символ *.

• игрушки — символы о, О, @ и 0.

• елка имеет ствол из трех символов | и стоит на полу из символов _.

• ветви елки расположены «ступенями»: первая состоит из трех строк, каждая следующая ниже — на одну больше.

• первая строка следующей ниже «ступени» должна иметь на два символа меньше, чем последняя строка предыдущей.

• елка должна иметь границы в виде символов /  и  \.

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

• украшения не должны висеть на границе елки (они же упадут!).

Бонусная задача

• вывести снег символом . (точка).

• раскрасить елку зеленым, фон — синим, игрушки — разными цветами (кроме зеленого и синего), снег — белым.

Попробуйте решить задачу самостоятельно и делитесь своими идеями в комментариях. А вариант ответа Тирекса ищите в Академии Selectel.