​​Hyper-V Server больше не будет бесплатным

Данная новость не нова, но как показала практика об этом знают далеко не все пользователи. Поэтому напомним.

Hyper-V Server — это, по сути, Windows Server Core, на котором Microsoft предварительно установила роль Hyper-V. Поскольку он предоставляется бесплатно, вам потребуется оплатить только стоимость гостевых лицензий.

Hyper-V Server пользуется заслуженной популярностью, так как предоставляет мощное средство виртуализации на привычной платформе Windows, да еще и совершенно бесплатно. При этом были доступны все «взрослые» возможности, включая кластеризацию.

Первый звоночек прозвучал с выходом Windows Server 2022, тогда пользователи ждали выпуска Hyper-V Server 2022, но этого не произошло.

Позже Microsoft заявила, что отказывается от выпуска бесплатного Hyper-V Server в пользу платного Azure Stack HCI. Но сам Hyper-V все еще остается доступным как роль в Windows Server 2022.

При этом окончание поддержки последнего бесплатного выпуска Hyper-V Server 2019 продлено с 2024 на 2029 год.

Означает ли это отказ Microsoft от Hyper-V вообще? Скорее всего да, как минимум в бесплатном варианте. А точно мы узнаем с выходом новой серверной системы, которой обещает стать Windows Server 2025.

Но даже если роль Hyper-V сохранится в серверном выпуске это поставит владельцев бесплатного Hyper-V Server перед необходимостью покупать серверные лицензии Windows Server и CAL к ним.

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

​​Некоторые вопросы производительности виртуальных машин и все такое прочее

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

Но не все так просто, особенно когда начинают тестировать разные гипервизоры в «одинаковых» условиях.

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

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

Чтобы не замусоривать свой домашний компьютер он нашел в закромах свободный диск на 2 ТБ и поставил на него виртуалку на Windows 10 при помощи бесплатной ныне VMware Workstation.

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

Т.е. если сильно не грузить диск, то он подтормаживал, но в целом работал. Но если задач ему накинуть – то уходил в 100% загрузку, при этом скорости обмена с диском были в это время очень скромные – несколько МБ/с.

Диск он поставил не самый плохой, но и не самый производительный - ST2000DM008 – черепица. Скажем сразу, диск очень даже неплохой и работает отлично, если не перегружать мелкоблочкой.

Но черепица – это для многих жупел, поэтому диск он поменял на WD20EARZ с классической технологией записи. Помогло? Нет.

Оба диска были проверены на бед-блоки, прогнаны через все возможные тесты, как синтетические, так и ручные – но никаких проблем выявлено не было.

В общем, коллега выбрал «помощь друга». А мы на эти грабли тоже наступали и тоже не могли сначала понять в чем дело.

Оказалось, что при создании виртуальной машины он выставил тип виртуального жесткого диска – NVMe.

Ну так он же виртуальный, мало ли чего он там выставил… А вот и нет. Вспомним про такую штуку как очереди. У классических ATA-дисков очередь одна, без всяких оптимизаций. Как команды послали – так диск их и выполнял, даже если это было не оптимально.

У SCSI и SATA появилась «умная очередь» с глубиной в 256 и 32 команды, это значило, что диск анализировал команды на указанную глубину и оптимизировал их выполнение, объединяя те, которые обращались с соседним областям диска.

Это позволяло оптимизировать запросы случайного доступа, которые являются узким местом любого механического диска.

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

NVMе вообще принесло революционные изменения - 65536 очередей с глубиной 65536 команд каждая.

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

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

Но даже поменяв черепицу на классику легче не станет. Это все равно, что попытаться без задержек трафик МКАД направить на проселочную грунтовую дорогу.

А помогло пересоздание виртуальной машины с указанием типа виртуального диска адекватно используемому железу, после чего даже черепичный Seagate стал работать полностью адекватно и без тормозов.

А всего-то какая-то одна настройка, а сколько таких настроек еще может быть?

​​10 лет Windows 10!

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

Тогда предполагалось, что «десятка» станет последним выпуском Windows и далее система будет развиваться в концепции «ОС как услуга». Но время внесло свои коррективы… Тем не менее Windows 10 готовится поспорить за лавры самой долгоживущей ОС со своей не менее удачной предшественницей – Windows XP.

А сегодня хотелось бы оглянуться назад и посмотреть на историю семейства ос NT 6 со всеми их взлетами и провалами.

Первой ОС для широкого круга пользователей на основе семейства NT стала Windows XP (семейство NT 5), которая предложила неведомую ранее стабильность и возможности корпоративных ОС NT/2000 простому пользователю.

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

Ответом на все эти вызовы стал «долгострой» Longhorn, который вначале 2007 года увидел свет под именем Windows Vista, она же первая пользовательская система на платформе NT 6.

Нет, Vista не была плохой системой, наоборот, она предлагала рекордное число новшеств: контроль пользовательских записей (UAC), новую модель видеоподсистемы, новую модель драйверов, новое ядро и много-много других различных новшеств.

Но все пошло как всегда: UAC оказался чрезмерно назойлив, новая модель драйверов требовала обязательной цифровой подписи (весьма недешевой), но, самое главное, Microsoft (по слухам, на поводу Intel) серьезно занизила системные требования к новой системе.

На топовых ПК Vista чувствовала себя отлично, но на бюджетных (но полностью с ней «совместимых») вела себя как улитка, попавшая в студень. Добавим к этому проблемы совместимости со старым ПО, драйверами.

В общем Vista была повсеместно признана дребеденью и решительно провалилась. Ситуацию не исправили даже два сервис-пака, которые серьезно подтянули качество системы, а железо уже позволяло ее без проблем запускать. Но увы, имя Vista стало черной меткой.

Поэтому Microsoft пошел на ребрендинг и следующая NT 6 система получила простое и незамысловатое имя Windows 7, также впервые было опробовано широкое бета-тестирование в виде выпуска бесплатных предварительных версий.

И Windows 7 выстрелила, хотя, по сути, это была Vista SP2 с рядом доработок, которые скорее тянули на SP3, а не на полноценную систему.

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

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

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

Но в целом, на пользовательском рынке Windows 8 провалилась, не так громко, как Vista, но тем не менее. И полумеры, вроде возврата кнопки Пуск в Windows 8.1 ситуацию не спасли.

Поэтому Microsoft пошла по уже проверенному пути и подала развитие Windows 8 в другой обертке, под видом совершенно новой операционной системы Windows 10.

И снова не прогадала. Если под капотом особо существенных изменений не произошло, то в пользовательской части они объединили лучшее из классической к этому времени «семерки» и «модерновой» Windows 8.

Получилось… А это все вы знаете сами. Получилось, да так хорошо, что именно Windows 10 претендует на лавры самой долгоживущей системы у признанного лидера – Windows XP.

Deckhouse User Community meetup #2
21 августа | Москва

«Флант» приглашает на второй Deckhouse User Community meetup. Три доклада от практиков:

→ управление узлами кластера на всём их жизненном цикле с командой Deckhouse Core;
→ построение платформы обучения K8s на DKP CE с коллегами из КРОКа;
→ автоматизация архитектурного контроля и подход Architecture as Code с экспертами «ДОМ.РФ Технологии».

Регистрируйтесь, если интересны реальные кейсы работы с Kubernetes-платформами.

Онлайн миграция виртуальных машин и контейнеров Proxmox VE между узлами при помощи remote-migrate

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

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

Начиная с Proxmox VE 7.3 мы можем использовать штатную утилиту remote-migrate, которая позволяет выполнить это задачу в кратчайшие сроки и даже поддерживает онлайн-миграцию. Подробнее в нашей статье.

https://interface31.ru/tech_it/2024/09/onlayn-migraciya-virtual-nyh-mashin-i-konteynerov-proxmox-ve-mezhdu-uzlami-pri-pomoshhi-remote-migra.html

Настраиваем Fail2Ban для совместной работы с брандмауэром Mikrotik

Fail2Ban - давно зарекомендовавшее себя решение для Linux систем, позволяющее эффективно выявлять и блокировать вредоносную активность, такую как подбор паролей или поиск уязвимостей.

Но как быть, если защищаемые узлы находятся внутри сетевого периметра, а на внешнем контуре находится роутер Mikrotik?

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

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

https://interface31.ru/tech_it/2024/09/nastraivaem-fail2ban-dlya-sovmestnoy-raboty-s-brandmauerom-mikrotik.html

Настраиваем мониторинг Proxmox Virtual Environment при помощи Zabbix

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

Поэтому очень важно держать руку на пульсе и своевременно получать данные о состоянии гипервизора и виртуальных машин. В этом нам поможет система мониторинга Zabbix.

В данной статье мы рассмотрим, как настроить интеграцию Proxmox и Zabbix чтобы начать получать все необходимые данные о состоянии гипервизора и виртуальных машин.

https://interface31.ru/tech_it/2024/08/nastraivaem-monitoring-proxmox-virtual-environment-pri-pomoshhi-zabbix.html

Debian 13 еще не вышел и только-только вошел в стадию полной заморозки пакетов (27 июля), релиз назначен на 9 августа. Но Proxmox уже сегодня представил Proxmox VE 9.0.

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

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

Но в любом случае бросать все и переходить на новую версию гипервизора мы не советуем. А вот в лабораторных условиях развернуть и протестировать можно, но не более, примерно до выхода Proxmox VE 9.1.

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

Поэтому, прежде чем браться за ее освоение, нужно изучить базовые понятия и основы построения системы, чтобы понимать из каких элементов, как из кирпичиков, строится мониторинг.

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

https://interface31.ru/tech_it/2024/09/zabbix-osnovy-i-bazovye-ponyatiya.html

Их нравы

Читаю тут новости и не перестаю удивляться. Есть одна широко известная компания, которую принято всячески ругать за телеметрию. Но заметка не об этом.

В предлагаемом в репозитории Debian Testing (будущий релиз Debian 13) пакете StarDict, реализующем интерфейс для поиска в словарях, выявлена проблема с конфиденциальностью - в конфигурации по умолчанию приложение отправляет автоматически помещаемый в буфер обмена выделенный текст (x11 PRIMARY selection) на внешние серверы. Достаточно в любом приложении выделить отрывок текста, и он сразу отправляется без шифрования по протоколу HTTP на китайские серверы online-словарей dict.youdao.com и dict.cn.

Ну это же просто праздник какой-то! Выделил текст в любом приложении, и он уже по незащищенному HTTP-протоколу потопал на сайт китайских товарищей. А если вы еще используете публичные КВН и тому подобное баловство – то еще и успел осесть по дороге.

Пароли? Банковские данные? Конфиденциальная информация? Ну да, достаточно просто выделить.

Сопровождающий пакет StarDict в Debian ответил, что подобное поведение является штатным. По умолчанию в StarDict включён режим автоматического поиска в словарях выделенного текста и активированы как локальные, так и внешние словари. Серверы dict.youdao.com и dict.cn предоставляют англо-китайские словари, включаемые по умолчанию.

Зачем большинству пользователей англо-китайские словари – загадка, но так как сопровождающий – китаец, то он так решил. И вообще, он художник, он так видит.

Кстати, подобное поведение в 2009 году было признано уязвимостью (CVE-2009-2260), но сейчас, видимо, настали совсем другие времена и это стало новой нормальностью.

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

Теперь, похоже, надо снова что-то аналогичное, но только совсем по другой причине.

✅ Источник новости: https://www.opennet.ru/opennews/art.shtml?num=63677

​​Linux, пакеты, доверие

Каждый раз, говоря об открытом ПО в пример ставится его большая безопасность, проистекающая из открытости. Мол, тысячи глаз следят, тысячи рук исправят…

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

Поэтому поиском уязвимостей занимаются в основном энтузиасты, злоумышленники и специалисты по безопасности.

Мы же в свою очередь рассмотрим спектр угроз для простого пользователя Linux, а также возможные варианты противодействия им.

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

Автор также волен вносить в свой код любые изменения, которые сочтет нужным.

Большинство авторов редко занимаются сборкой ПО под конкретные дистрибутивы, либо собирают под ряд наиболее популярных. В этом случае мы можем подключить репозиторий от разработчика и получать бинарные пакеты прямо из первых рук.

Но это не всегда хорошо. Почему? Потому что автор может не знать тонкостей конкретного дистрибутива и просто собрать пакет без оптимизаций и интеграций. Чтобы был.

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

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

Сегодня есть еще и третий путь – пакеты Snap, Flatpak и AppImage. Их сборкой могут заниматься как авторы ПО, так и третьи лица. Поэтому всегда нужно понимать кто собирает и поддерживает версию, которую вы хотите установить.

А теперь об угрозах. Основная – это компрометация исходного кода разработчика. Это могут сделать как злоумышленники, так и сам автор, примеров тому в последние годы было достаточно. Также возможна игра вдолгую – с постепенным перехватом управления проектом злоумышленниками.

В этом случае, если вы используете репозиторий или иные пакеты непосредственно от разработчика, то вы сразу получаете скомпрометированный пакет себе в систему после ближайшего обновления, а в случае Snap/Flatpak этого даже не потребуется, они обновятся сами. Но их, как раз, наиболее легко и просто откатить.

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

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

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

Также он может собрать пакет немного не так, с отличиями от исходного кода в репозиториях дистрибутива. Это достаточно несложно обнаружить, достаточно просто пересобрать дистрибутив (или пакет) из исходных кодов, но в случае целенаправленной атаки время может быть упущено и скомпрометированный пакет разойдется пользователям.

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

В целом, несмотря на все потенциальные угрозы, пакеты из репозитория дистрибутива наиболее безопасны. Так как имеют временной зазор между появлением версии разработчика и ее попадания в дистрибутив, а также промежуточное звено дополнительного контроля – мейнтейнера.