Измеряйте качество интернет-соединения с помощью сервиса Selectel Speedtest ⚡
Selectel уже более семи лет поддерживает собственный инструмент для измерения качества интернет-соединения — Selectel Speedtest.
С помощью сервиса вы можете отслеживать скорость скачивания и загрузки, а также пинг и задержки при передаче данных (джиттер). Ежемесячно Selectel Speedtest помогает более 20 000 пользователей.
На странице Selectel Speedtest представлены тестовые файлы разного объема, с помощью которых можно легко проверить качество интернет-соединения. При этом сервис не сохраняет данные о результатах.
В последнюю пятницу июля в России, как и во всём мире, отмечается День системного администратора. Несколько лет назад на эту тему сложились стихи, которые до сих пор в открытых источниках не публиковались.
В эту пятницу привычно
Стул придвинет он к компу
Пусть всё кажется обычным,
Присмотритесь же к нему:
В джинсах, свитере неброском,
(Невзирая на июль)
Стильный, без излишков лоска,
Твёрдо держится за руль.
Он почти всегда в ударе,
В поле - воин, хоть один,
Он простой советский* парень**,
По профессии - админ
Ночь не спит в дежурной смене,
Утром чинит 1С,
Днём сетей рисует схемы,
Вечер - время сервис деск
"Файрвол", "маршрутизатор" -
Знает много умных слов,
Он прогрессор и новатор,
Накатить всегда готов
"Накатить" - релиз, конечно,
Здесь ci/cd, DevOps,
Пинги, tracert бесконечный,
Стойка в сотню терафлопс
Кубер, докер, AstraLinux
Windows, база SQL -
Все сомнения отринув,
В бубен бьёт, и точно в цель.
Вот бигдаты полный кластер,
Шарды, топики, бэкап -
Он над всем - незримый мастер,
Всё ИТ - в его руках.
Вам настроит сервер ловко,
И в hardware тоже крут:
Фен, утюг, микроволновку
Все чинить ему несут.
Антивирус, драйвер, почта,
Принтер, сканер, монитор,
"Очень важно", "суперсрочно"
"Почему пропал курсор?"
С датацентром связь наладит,
На заявки даст ответ,
И готов клиентов ради
Пропустить опять обед...
Всё как в высшем пилотаже.
Завтра - снова день такой.
Сисадмин стоит на страже.
Наш коллега. Наш герой. ❤️
* или российский, кому как по душе
** да, есть сисадмины девушки, но тут нужно было в рифму )
Еще больше мощности: в Облаке Рег.ру запускаем высокочастотные серверы в Москве
В Облаке Рег.ру возобновилась возможность аренды высокочастотных серверов в Московском регионе. Ранее услуга была доступна только в локации Санкт-Петербурга. Тарифная линейка будет особенно полезна для работы с масштабируемыми проектами и высоконагруженными приложениями: базы данных, аналитика, 1С-Битрикс, транзакционные системы, а также для задач с низкими задержками: игровые серверы, финансовые транзакции, потоковое видео.
Под капотом решения:
процессоры с тактовой частотой 3,2/3,7 ГГц и NVMe диски;
технология Turbo Boost, которая дает ускорение до 5,1 ГГц.
Ключевые особенности услуги:
производительность, которая часто требуется для задач с критичной высокой тактовой частотой CPU;
доступность: чем ближе к московским пользователям, тем ниже пинг.
Подключить обновленную линейку уже можнов личном кабинете облачной платформы Рег.ру.
Мечты сбываются — открыт предзаказ на серверы с GPU NVIDIA 🥳
Хорошие новости для тех, кто давно искал тот самый сервер с мощной видеокартой под игры, AI-задачи или работу с графикой.
Какие видеокарты доступны:
Tesla H200 141GB (PCIe)
Tesla H100 80GB HBM2
Tesla A100 80GB HBM2
Tesla A30 24GB GDDR6
RTX A6000 48GB GDDR6
RTX A5000 24GB GDDR6
RTX 4090 24GB GDDR6X
RTX 5070 Ti 16Gb GDDR7
Как получить сервер:
1️⃣ Оставляете заявку на сайте или в панели управления; 2️⃣ Менеджер связывается с вами и уточняет детали; 3️⃣ Для предзаказа нужно внести минимальный платеж 5 000 ₽; 4️⃣ После получения сервера остается только доплатить оставшуюся сумму по выбранному тарифу.
Важно: если нужной видеокарты нет в списке, то напишите об этом менеджеру, уточним наличие.
Какую информацию содержит FRU EEPROM и как с ней работать
Съемная микросхема FRU Key, которая устанавливается в один из серверов YADRO
Набор возможных данных, хранимых во FRU EEPROM, определяется спецификацией Intel IPMI FRU Information Storage. Вся информация разделена на пять областей, присутствие каждой из которых не обязательно и определяется информацией в общем заголовке FRU EEPROM, где размещены указатели на данные каждой из них в следующем порядке:
1. Область для внутреннего использования (Internal Use Area) — ее содержимое не описано спецификацией. Предполагается, что эта часть EEPROM может использоваться программным обеспечением BMC или другого контроллера на плате для хранения какой-то служебной информации (например, внутренних состояний).
2. Область информации о шасси (Chassis Information Area) — здесь содержится базовая информация о «корпусе» или «шасси» устройства, описываемого этим FRU EEPROM. Основным параметром тут является «тип шасси», который представляет собой целое число, выбираемое согласно спецификации SMBIOS (см. DMTF DSP0134, Table 17). Например, значение 0x17 соответствует типу «Rack Mount Chassis». Также в этой области может содержаться информация о серийном номере шасси и его артикуле (part number).
Создатели спецификации предполагали, что эта область присутствует на главной плате всего изделия и на любых корпусированных компонентах, таких как блоки питания или дисковые накопители, но не все производители и не всегда придерживаются этого правила.
Какие еще есть области во FRU EEPROM, и как утилита frugen и библиотека libfru помогают с ними работать — читайте в статье Александра Амелькина, технического эксперта департамента разработки BIOS и BMC в компании YADRO, а также автора и мейнтейнера проекта frugen / libfru.
Подарить свое сердце? А может, лучше подарить свой сервер? 💙
Очень приятная фича, которая даст возможность перенести сервер вместе с бэкапами, IP и сетевыми дисками с одного аккаунта на другой без лишних заморочек.
Как перенести сервер:
1️⃣Заходим в Панель управления, выбираем конкретный сервер и нажимаем «Доступ»
2️⃣Кликаем кнопку «Передать»
3️⃣Указываем логин аккаунта, на который переносится сервер, и вводим код подтверждения (он придет на почту)
4️⃣У получателя сервер появится в списке. Его можно принять или вообще отказаться от переноса
Важно: во время передачи облачный сервер будет заблокирован и помечен в панели как ожидающий переноса (но на его работе это не отразится).
Начинаю собирать домашнюю "лабу". И моя небольшая история
Я расту, и с ростом меня растут мои аппетиты. Занимаюсь программированием я класса с.. 8? Где-то так, но у меня не было возможности устроить себе рабочее место. Моим рабочим местом долгое время был небольшой ноутбук на селероне с 4 гб оперативной памяти. На нём я и простенькие сайты умудрялся делать, и в SA:MP играл (кто-то помнит?), и делал даже сервер для CR:MP.
Появился в сознательном возрасте компьютер у меня позже, но он тоже был не мощный. Не очень новый процессор, видеокарта только встроенная в процессор, один монитор. Но я пытался выжимать максимум, на нём я начал изучать Питон, тыкал Шарпы. Сейчас я окончательно закрепил себя у себя в сознании как Python Backend Web-developer.
Дальше, уже в другой квартире даже, появилась возможность собрать компьютер получше. Ryzen 7 3700X, 32 Гб ОЗУ (которые появились даже позже, изначально сидел на 12), RTX 3060.
Когда я уже начал получать свои первые деньги, я купил себе второй монитор, потому что понял, с одним мне работать тяжело. И правда: бывает нужен и браузер, и IDE, а я скакал то одно открывал, сворачивал, другое открывал, иногда делил свой 24-дюймовый экран пополам, и это было жутко некомфортно.
Примерно в то же время, даже немного раньше, чем второй монитор, я взял себе у знакомого старый Synology NAS, за недорого относительно цен на них на новые.
Моя гордость, первый в жизни NAS - Synology DS212j
Купил в него диск на 4 Тб, так чтоб надолго. Пользуюсь =)
Это только начало ведь. Я расту, аппетиты растут.
По работе набирался опыта работы с железками. Видел коммутаторы, впервые смотрел как вживую настраивается Микротик (одно дело в PNET тыкнуть на роутер и вот тебе консоль, другое - настраивать реальное устройство). Что самое интересное - я узнал про Proxmox.
Не то что бы я раньше не знал про виртуализацию. Виртуалки конечно запускал, и линукс на них, но только изнутри Винды в VirtualBox или VMWare. А тут - проксмокс!
Буквально на днях решил протестировать, что же это такое. Помните ноутбук на селероне с 4 Гб оперативки, про который шла речь выше? Так вот, я взял его, старичка, накатил проксмокс по гайду с Хабра, даже виртуалочку одну на убунту всё таки создал. Более того, даже приложение по работе, которое я разрабатываю, развернул. Правда, больше ничего я не разверну - оно уже всё вместе кушает 3.28Гб ОЗУ из 4х. Но я хочу больше...
То, что будет скоро, буквально до 30 июня максимум: мой первый МиниПК. Характеристики такие: N100, 16 Gb RAM, 1Tb SSD. Беру его как раз для виртуалок. Тестовое окружение для того, чтобы деплоить и тестировать свои приложения а-ля как будто на реальном сервере, плюс отдельные виртуалки под разные сервисы, какие - посмотрим. Возможно, первым сервисом, который я поставлю, будет Plex (или его аналог). И сразу же поставлю Gitea, которая сейчас работает с моего компьютера.
И то, что будет раньше 30 июня, совсем скоро - локальная сеть быстрее 100 мбит. Я пока что взял один коммутатор с 5 портами по 2.5 гбит, надо будет подумать, между кем делить трафик на коммутаторе. Может, буду с МиниПК как раз раздавать фильмы/сериалы, и поведу быструю локалку на телевизоры - к одному на кухне, к другому в зале. Тут есть проблема - я не знаю как это сделать красиво. Сейчас телики работают по вайфаю. Как вести провод - придумаем.
P.S. Если бы тут можно было вставить больше одной фотографии - я бы вставил, но увы.
Задача будет полезна разработчикам веб-приложений и сервисов.
Текст подготовил Артём Шумейко — внештатный райтер, амбассадор Selectel и автор YouTube-канала о разработке.
Условие
В компании «ГигаПост» выпустили долгожданное обновление: на сайте появилась новая кнопка «Подписаться на тему». Интерфейс готов, API поддерживает, проверено на стенде — все работает как часы.
Но после релиза начались странности. Некоторые пользователи видят кнопку, а некоторые — нет. Кто-то говорит, что она появилась через сутки. Кто-то — что только после нажатия Ctrl+F5.
Команда фронтенда уверена — код задеплоен. Бэкенд-эндпоинт отвечает корректно. На тестовом стенде все видно. Даже сам разработчик открывает сайт на своем ноутбуке — кнопка есть.
Начали подозревать баг в логике отображения, потом — переключение языка, затем подумали про авторизацию. Но фича пропадает у пользователей даже с одинаковыми условиями.
И вот тогда кто-то предложил простую мысль: а пользователи вообще видят свежую версию сайта?
Задача
Почему часть пользователей не видит новую кнопку, хотя код задеплоили? В чем может быть причина? Где в цепочке доставки может остаться старая версия?
Предлагайте свое решение в комментариях. А правильный ответ можно подсмотреть в Академии Selectel.
Как обнаружить anycast-адреса сервисов при помощи неравенства треугольника
Технически, по одному и тому же IP-адресу может отвечать всякий интернет-узел, который находится на (двунаправленном) техническом пути следования пакетов. Чтобы такое работало без запинки для многих IP-источников - требуется согласовать пути следования пакетов на уровне IP-сети, то есть, средствами BGP. Штатный способ использования этой особенности называется Anycast. Настроить и поддерживать сложно, но, при грамотном подходе, метод отлично работает и достаточно широко используется в глобальной Сети. При Anycast один и тот же IP-адрес, наблюдаемый из разных точек Интернета, адресует разные физические узлы. Эти физические узлы могут быть географически распределены - ближе к пользователям. Обычно, так и делается, потому что это одно из основных практических преимуществ Anycast, но далеко не единственное преимущество - anycast-адреса могут быть разведены средствами BGP и коммутации сетевых сегментов из соображений устойчивости к DDoS-атакам, распределения прочей нагрузки, повышения надёжности и т.д. Примеры: 1.1.1.1, 8.8.8.8, многие корневые DNS-серверы.
Как подручными средствами проверить, что какой-то интернет-сервис стоит за anycast-адресами? Для этого нужно использовать неравенство треугольника. Тестируемый узел должен отвечать в рамках того или иного протокола, который позволяет измерить сетевое время доставки пакетов.
Методика. Пусть мы обнаружили IP-адрес сервиса (обычно, из DNS) и хотим его проверить. Пусть узел под этим адресом отвечает по ICMP - ping. Возьмём два опорных узла-источника, расположенных в совсем разных местах Интернета: например, узел в Амстердаме (обозначим его А) и узел во Владивостоке (соответственно - В). Тестируемый узел назовём Т. Принцип: если среднее время доставки ping между А, В (А <--> В) существенно превышает сумму ping для А --> Т и В --> Т, то сервис, работающий на узле T, скорее всего, использует Anycast. Поэтому измеряем время силами ping. Это и есть нарушение неравенства треугольника: если сумма расстояний (в смысле ICMP) от каждой из точек тестирования к тестируемому узлу меньше, чем расстояние между этими точками, то тестируемый узел - это, скорее всего, как минимум два узла, использующих один и тот же IP-адрес, то есть, это anycast-адрес.
Конечно, тут всегда есть место для погрешности, однако в подавляющем большинстве случаев Anycast так виден - иначе в нём не было бы смысла. Можно взять несколько опорных точек, а не две, тогда точность возрастёт.
Вебинар «Почему HCI не только про “проще”, но и про “надёжнее”»
Любой сбой инфраструктуры = простои, потери и размытая репутация.
Но классические платформы виртуализации либо сложные, либо дорогие, либо не отвечают новым требованиям к отказоустойчивости и управляемости.
Есть ли альтернатива? Расскажем на вебинаре «Точка устойчивости ИТ».
Когда: 10 июня в 11.00 (МСК)
➖Почему гиперконвергентная инфраструктура действительно может выигрывать у классических решений ➖Как снизить затраты времени, ресурсов и усилий на поддержку ➖Как управлять инфраструктурой без лишней сложности (живое демо!)
Встречайте в панели серийную консоль — быструю и с удобным копипастом.
Работает «из коробки» на серверах, установленных после 4 апреля 2024. Для остальных — одна команда в панели управления, и готово.
Из удобных фич:
➖ Поддержка Ctrl+C/Ctrl+V, скролла и мыши в терминале. ➖ Подсветка синтаксиса в один клик. ➖ Независимость от публичной сети и SSH. ➖ Мгновенный запуск и оптимизация потребления ресурсов.
✏️ VNC-консоль также остается доступной. На всех серверах, кроме тех, что с Виндой, можно легко переключаться между консолями.
Представьте, что ваш бизнес обслуживает более 2 000 продавцов, интегрированных с крупнейшими маркетплейсами. Каждый день поступает множество запросов, и важно обеспечить стабильную работу платформы при высокой нагрузке. Как сделать так, чтобы система оставалась надежной и безопасной, а данные не терялись?
Рассказываем на примере кейса XWAY. Переходите в Академию Selectel чтобы узнать, как компания:
Построила гибридную и отказоустойчивую инфраструктуру с обработкой 1 000 запросов в секунду.
Использует облачные серверы, Managed Kubernetes и выделенные серверы от Selectel для обеспечения высокой производительности.
Обеспечивает быструю и надежную сетевую связность при уровне SLA 99,98%
Автоматизировала управление инфраструктурой, снизив зависимость от сторонних специалистов.
Невозможно не вспомнить когда-то популярную песню. И невозможно не рассказать, что мы открыли целых 2 новых локации для выделенных серверов — Лондон и Париж.
Итак, в наличии по 5 сборок (но скоро могут разобрать, успевайте):
Такой способ позволяет разворачивать 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.
Никогда такого не было, и вот опять. В сети появилась новость, что Broadcom в очередной раз закручивает гайки для мелких подписчиков VMware.
Из ключевых изменений: 1. Повышен порог минимального числа ядер в лицензии с 16 до 72 штук на командную строку. Соответственно, более мелкие тарифы устранены. 2. Штрафы в 20% от стоимости первого года подписки, если вы не продлили свою лицензию до истечения срока действия текущей.
Самое неприятное, что пункт №2 будет применяться задним числом, об этом прямо сообщает Broadcom в своем меморандуме (скрин от The Register тык).
На вопрос "зачем?" ответ простой: избавиться от vSphere Foundation и vSphere Enterprise Plus, которыми пользуются мелкие компании, и продвинуть свой пакет Cloud Foundation (VCF), который и дороже, и серверов для своего управления требует больше.
Ситуация вокруг VMware, в целом, развивается ровно по тому сценарию, о котором говорил любой участник рынка с двухзначным IQ: Broadcom контора-соковыжималка, и если регулятор разрешит им купить VMware, они тут же станут крутить гайки. Если эта история прошла мимо вас, то напомню: менеджмент Broadcom мамой клялся обещал не усложнять жизнь малым и средним предприятиям и оставить продукты VMware такими же доступными для всех участников рынка, как и прежде. Под эти разговоры они и смогли протащить сделку по покупке VMware.
Хватило этого обещания примерно на полгода, а с тех пор мы только и видим, как новые владельцы занимаются планомерным отстрелом "неэффективных направлений".
Короче говоря, если вы еще пользуетесь продуктами VMware, но при этом не способны внезапно повысить расходы на лицензию в 2-3 раза в течение ближайших пары лет, то стоит всерьез присмотреться к другим решениям. Потому что останавливаться новые хозяева не собираются.
В Академии Selectel появился бесплатный курс «Погружение в компьютерные сети». Он поможет разобраться в принципах работы, понять ключевые термины и уверенно ориентироваться в основах. Всего час — и сложные вещи станут простыми.
Курс подходит новичкам, которые хотят разобрать тему по полочкам. Но и опытным специалистам будет полезно: с этими материалами вы восполните пробелы в знаниях и вспомните все, что забылось со временем.
Начните обучение в Академии Selectel прямо сейчас ➡️
Представьте, что ваш бизнес обслуживает более 500 компаний, у каждой из которых есть тысячи или даже десятки тысяч клиентов. И все они ежедневно обращаются в клиентскую поддержку через телефон, почту, соцсети, мессенджеры и т. д.
Ваша задача — сделать так, чтобы поддержка стабильно работала даже под высокой нагрузкой, персональные данные были в безопасности, а важная информация случайно не пропала. Справитесь? Вот платформа Юздеск справляется на инфраструктуре Selectel.
Представим, что у нас некоторая система, состоящая из микросервисов, которые работают на разных машинах, но внутри общей 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 - более одной "опечатки".
Let's Encrypt больше не будет отправлять уведомления по электронной почте об истечении срока действия сертификатов
письма счастья от Let’s Encrypt
Ну что ж, вот и кончилась эпоха... С момента своего создания Let’s Encrypt отправлял уведомления об истечении срока действия сертификатов по электронной почте подписчикам, которые предоставили им свой адрес. Однако, начиная с 4 июня 2025 года, данная рассылка будет прекращена.
Let’s Encrypt приводит следующие аргументы в поддержку этого решения:
За последние 10 лет подавляющее большинство подписчиков внедрили автоматизированные системы обновления сертификатов, которые являются более надёжными, чем получение уведомлений по электронной почте.
Для рассылки уведомлений Let’s Encrypt вынужден хранить миллионы адресов электронной почты, что негативно сказывается на конфиденциальности. Сокращение объёма хранимых данных рассматривается как приоритетная задача.
Отправка уведомлений обходится в десятки тысяч долларов в год — средства, которые можно использовать гораздо эффективнее для улучшения других компонентов инфраструктуры.
Поддержка системы рассылки увеличивает общую сложность инфраструктуры, требуя дополнительных ресурсов и повышая вероятность ошибок. С учётом планов по внедрению новых функций становится необходимым сокращение избыточной сложности инфраструктуры.
Для тех, кто хочет продолжать получать уведомления об истечении срока действия сертификатов есть возможность воспользоваться сторонним сервисом Red Sift Certificates Lite (https://redsift.com/pulse-platform/certificates-lite). Мониторинговый сервис Red Sift предоставляет уведомления бесплатно для 250 сертификатов.
Несмотря на заявленное стремление сокращать количество хранимых адресов для рассылки уведомлений об истечении срока действия сертификатов, рассылки о новостях Let’s Encrypt и ее материнской компании ISRG (https://www.abetterinternet.org/) не прекратятся... А те кто не успел на них подписаться даже могут это сделать. Правда, как это сочетается с желанием сократить общую сложность инфраструктуры, я уже не могу и предположить.
Для тех, кто еще не добавил автоматическое обновление сертификатов на свой сервер – вот подходящая команда для cron (пытается обновить сертификаты через каждые трое суток):
Мы будем ждать ваших сообщений до 2 марта 2025 года, после чего подведем итоги. 10 счастливчиков получат комплект мерча Selectel: картхолдер, кружку и плюшевого Тирекса 🦖
Если готового бота у вас еще нет и вы вообще таким не занимались, то у нас в Академии Selectel есть пример для вдохновения — пошаговый гайд по созданию бота для прогноза погоды. На всякий случай есть еще инструкция, как задеплоить бота на сервер (мало ли).
Из 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 должно быть доменное имя. Вот типичный пример:
Однако, если речь про сертификаты для TLS в современном вебе и про имена, то полагаться тут на Subject нельзя. Нужно использовать другой фрагмент сертификата, а именно - расширение SAN (Subject Alternative Name).
Для извлечения расширения SAN при помощи OpenSSL x509 нужно использовать опцию -ext subjectAltName. Выдача состоит из списка, где каждому значимому элементу соотвествует префикс, обозначающий тип. DNS-имена OpenSSL выводит с префиксом "DNS" (кто бы мог подумать!). Пример:
Кроме "DNS" могут встретиться другие префиксы, обозначающие IP-адреса и т.д. Однако для обработки имён - нужны имена, то есть "DNS". Скрипт, конечно, несколько усложнится. Пример:
Причина использования SAN в том, что имя из поля Subject/CN оконечного (серверного) сертификата браузеры давно не используют в качестве идентификатора при валидации. А чтобы валидация сертификата для веб-узла прошла успешно (в браузере), необходимо наличие подходящего имени в SAN. Более того, современные требования для УЦ по выпуску TLS-сертификатов ("документы CA/B-форума") прямо не рекомендуют использование поля commonName в Subject оконечных сертификатов для веб-узлов. Это значит, что доменного имени в Subject может просто не оказаться, но сертификат (при прочих равных) будет валидным для браузера.
Чего ждет бизнес от облачной IT-инфраструктуры? ☁️
Гибкости в управлении, легкой масштабируемости, оперативного решения вопросов через техподдержку, защищенности от внешних воздействий. А еще того, что обслуживание этой инфраструктуры ляжет на плечи провайдера. С такими ожиданиями московский девелопер Level Group мигрировал в Selectel.
В кейсе рассказываем, как компания:
бесплатно мигрировала в частное облако и повысила доступность корпоративных сервисов,
организовала сетевую связность, объединив все узлы инфраструктуры в единую сеть без доступа в интернет,
отказалась от капитальных затрат в пользу операционных и сократила расходы на инфраструктуру на 30%.
Запустили выделенные серверы с мгновенной установкой
Надеемся, что вы хорошо отдохнули за долгие выходные и готовы к новым релизам. И вот первый из них — в панели появились конфиги выделенных серверов, которые готовы к запуску сразу после заказа. Без участия менеджера и дополнительного времени на обработку.
Доступно для конфигураций в Санкт-Петербурге с каналом 1 Гбит/с и ОС Ubuntu 22.04. Найти их можно на отдельном табе «Мгновенная установка» с иконкой⚡️
Остается только убедиться, что на балансе есть нужная сумма, нажать «Заказать», и сервер сразу же будет готов к работе.
Новогодняя задача: помогите Тирексу поставить и нарядить елочку
Условие
Сисадмин Тирекс засиделся допоздна и не успел не то что нарядить елку, но даже купить ее! У него нет главного символа праздника, но есть лапки, компьютер, IDE, технический склад ума и знание Python.
Задача
Помоги Тирексу вывести в консоли наряженную елку на любимом языке программирования. Педантичный Тирекс предъявляет следующие требования:
на вход программа получает два числа: rows отвечает за высоту елки в строчках (не менее трех), freq — за частоту появления украшений.
ветки елки — символ *.
игрушки — символы о, О, @ и 0.
елка имеет ствол из трех символов | и стоит на полу из символов _.
ветви елки расположены «ступенями»: первая состоит из трех строк, каждая следующая ниже — на одну больше.
первая строка следующей ниже «ступени» должна иметь на два символа меньше, чем последняя строка предыдущей.
елка должна иметь границы в виде символов / и \.
между двумя украшениями по горизонтали должна быть минимум одна ветка.
украшения не должны висеть на границе елки (они же упадут!).
Бонусная задача
вывести снег символом . (точка).
раскрасить елку зеленым, фон — синим, игрушки — разными цветами (кроме зеленого и синего), снег — белым.
Попробуйте решить задачу самостоятельно и делитесь своими идеями в комментариях. А вариант ответа Тирекса ищите в Академии Selectel.
Теперь созданные образы сервера можно переносить между локациями — Москвой, Санкт-Петербургом, Польшей, Нидерландами и Казахстаном.
Буквально в пару кликов: тап на три точки рядом с нужным образом → пункт «изменить регион» → выбор локации → сохранить. Подробнее об образах и их переносе читайте в документации.
Между Москвой и Питером перенос проходит практически моментально, между другими регионами со скоростью от 1 до 10 гигабит в секунду.
Добавили возможность управлять облачными серверами через бота в Телеграме: проверять статусы, следить за нагрузкой, включать, выключать, перезагружать и подключаться к ним по SSH. Все это по вашим идеям: раз, два и три. К боту можно привязывать личные и групповые чаты. Например, можно подключить бота к чату с командой инженеров, чтобы все участники были в курсе событий.
И для тех и для других можно задать индивидуальные настройки на получение уведомлений, кодов 2FA, управление ресурсами, тикетами и балансом.
Для этого в разделе «Настройки аккаунта → Уведомления» привяжите телеграм-аккаунт и нажмите кнопку «Настроить». Затем выберите тип чата, отсканируйте QR или сразу перейдите в бота по ссылке.
Практический курс по работе с объектным хранилищем
В новом бесплатном курсе рассказываем, что такое S3 и как применить его в своих проектах. Вас ждет 10 материалов, изучение которых займет чуть менее трех часов.
В рамках курса вы научитесь:
использовать хранилище в Kubernetes,
подключаться к нему из платформы для дата-аналитики,
Записали видеоэкскурсию по DCImanager — платформе для управления физической ИТ-инфраструктурой!
С помощью DCImanager можно:
● управлять мультивендорным серверным и околосерверным оборудованием дата- центра из одного окна; ● вести учет оборудования, комплектующих и лицензий в инфраструктуре и на складе; ● автоматизировать выдачу физических активов подразделениям компании; ● замещать решения для управления оборудованием от зарубежных вендоров; ● обновлять прошивки BMC и BIOS/UEFI серверов, в том числе с внутреннего репозитория; ● контролировать идентичность настроек оборудования; ● вести учет IP-адресов, настройка сетевого оборудования и виртуальных сетей.
В видео показываем, что представляет собой DCImanager, и рассказываем об основных возможностях платформы.
Скачать бесплатный триал DCImanager, получить доступ к демостенду или заказать демонстрацию можно на нашем сайте.
