Эволюция энергосбережения в архитектуре x86 или что такое ACPI

История развития платформы x86 непрерывно связана с борьбой за энергосбережение. Особую актуальность этот вопрос приобрел в 90-е, когда начался стремительный рост таковых частот процессоров, вылившийся в конце десятилетия в «гонку гигагерц».

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

И если Intel худо-бедно переживал такую ситуацию, то процессоры Athlon от AMD мгновенно сгорали. Это самое видео мы прикрепили к заметке. И с этим надо было что-то делать.

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

Если мы снизим на 25% частоту процессора на такое же значение снизится и потребление. А вот при снижении на 25% напряжения мы получим уже 44% экономии, а снизив одновременно и частоту, и напряжение получим целых 58% снижения потребления.

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

1️⃣ Для этого в 1996 году был принят стандарт ACPI 1.0, который вводил новые универсальные состояния системы.

🔹 Начнем с S-states (System states) – глобальные состояния всей платформы, которые подразумевали следующие варианты:

▫️ S0 — работа
▫️ S3 (Suspend to RAM) — сон с сохранением в памяти
▫️ S4 (Hibernate) — сохранение на диск
▫️ S5 — мягкое выключение (дежурный режим БП и доступен WoL)

🔹 Одновременно с ним вводились состояния простоя - C-states (CPU Idle states), которые существовали только внутри режима S0:

▫️ C0 — исполнение инструкций
▫️ C1 (Halt) — базовый простой с мгновенным пробуждением
▫️ C2/C3 — более глубокие состояния с отключением тактового генератора и кэшей

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

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

2️⃣ В ответ появились первые проприетарные технологии Intel SpeedStep (1999) и AMD PowerNow! (1999), которые умели управлять частотой и напряжением питания в зависимости от реальной нагрузки.

🔹 В результате в 2000 году появился новый стандарт ACPI 2.0, который ввел понятие P-state (CPU Performance States), которые существовали внутри уровня C0.

Первоначально предполагались:

▫️ P0 – полная производительность процессора
▫️ P1/P2 – энергосберегающие режимы со снижением частоты и напряжения процессора

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

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

3️⃣ В 2004 году увидел свет стандарт ACPI 3.0, который ввел в прошивку BIOS таблицы DSDT, в которые вендором записывались все возможные сочетания частоты и напряжения, и система в зависимости от нагрузки могла выбирать один из них.

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

Работа с картинками в веб-сервере Angie (Nginx)

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

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

В этом случае ничего не остается, как обрабатывать изображения на самом веб-сервере и тут нам поможет Angie, который является более продвинутым форком Nginx (хотя вы можете использовать и последний).

Почему именно Angie? Да потому что он имеет в репозитории уже скомпилированные модули и вам не нужно пересобирать веб-сервер вручную, а также модуль для работы с изображениями у него поддерживает форматы JPEG, GIF, PNG, WebP, HEIC и AVIF, в то время как Nginx ограничен JPEG, GIF, PNG и WebP.

Данный модуль называется http_image_filter_module и для его установки вам понадобится команда:

apt install angie-module-image-filter  libgd3

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

Пример конфигурации:

location /img/ {
    proxy_pass   http://backend;
    image_filter resize 800 600;
    image_filter rotate 90;
    error_page   415 = /empty;
}

location = /empty {
    empty_gif;
}

В нашем примере изображения из локации /img пропорционально будут уменьшены до размера 800*600 так, чтобы обе стороны не превышали указанные размеры.

После чего изображение будет повернуто против часовой стрелки на 90 градусов, поддерживаются значения 90 – 180 -270.

При совместном использовании с resize поворот происходит после изменения размера.

Вместо resize можно использовать опцию crop:

image_filter crop 800 600;

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

При использовании совместно с вращением, поворот происходит перед обрезкой.

Для конвертации формата используйте:

image_filter convert type 

Где в качестве type укажите jpeg, gif, png, webp, heic или avif, однако помните, что онлайн-конвертация, особенно современных форматов может оказывать высокую нагрузку на процессор и занимать длительное время.

Чтобы процесс случайно не съел всю оперативную память можете использовать лимит буфера загрузки изображения:

image_filter_buffer 64M;

Также можно поиграть форматами качества, изменив соответствующие опции, которые по умолчанию имеют значения:

image_filter_jpeg_quality 75;
image_filter_webp_quality 80;
image_filter_heic_quality 80;
image_filter_avif_quality 80 6;

Для AVIF второй параметр является необязательным и указывает на скорость кодирования.

При возникновении ошибок обработки: неподдерживаемый формат, неправильное расширение, превышение размера буфера и т.д. сервер выдаст ошибку 415 и отдаст картинку-заглушку empty_gif.

Сразу отметим один момент, empty_gif - это встроенная директива, которая возвращает 1×1 прозрачное GIF-изображение чтобы не ломать правильное формирование страницы на клиенте. Т.е. никаких дополнительных изображений-заглушек нигде размещать не нужно.

Тоже самое произойдет, если вы попытаетесь обработать формат не поддерживаемый http_image_filter_module или libgd.

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

Когда DNS использует UDP, а когда TCP?

Чтобы правильно ответить на этот вопрос обратимся к RFC5966, который говорит, что TCP используется для трансфера зон или ответов, размер которых превышает 512 байт.

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

А вот что такое ограничение на 512 байт и откуда оно взялось? Это связано с техническими ограничениями протокола UDP и обеспечением обратной совместимости. Проще говоря, если мы хотим быть уверенными, что любой узел сможет получить DNS-ответ по UDP, его размер не должен превышать 512 байт.

В противном случае сервер должен перейти на использование протокола TCP, либо клиент получит усеченный ответ (то, что поместится в 512 байт).

А теперь о том, какие именно записи могут превышать 512 байт:

🔸 Многочисленные записи: если запрашивается доменное имя, которое имеет много A-записей или AAAA-записей размер ответа может превышать 512 байт.

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

🔸 Записи типа CNAME: могут указывать на доменные имена, которые имеют многочисленные А-записи

🔸 DNSSEC: в этом случае дополнительные криптографические записи (RRSIG, DNSKEY) могут значительно увеличить размер ответа.

🔸 Дополнительные записи: например, NS, TXT или SRV записи, которые могут быть многочисленными и иметь достаточно большой размер.

Однако использование TCP в данном случае не является обязательным, существуют расширения протокола DNS - EDNS0, в рамках которого резолвер может в запросе указать какой размер ответа он может принять через UDP и сервер отправит ему такой ответ даже если его размер превышает 512 байт.

❓Кто должен поддерживать TCP? Согласно стандарту, все реализации должны поддерживать оба протокола, но есть и более строгие требования.

Стандарт требует обязательной поддержки от:

🔸 Авторитативного сервера, хранящего зону для ее возможной передачи тому, кто имеет право ее запросить

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

🔸 Конечных DNS-клиентов (реализаций в ОС и т.д.) – для возможности принимать не усечённые запросы.

Однако в отношении последних есть некоторые послабления, стандарт разрешает не реализовывать поддержку TCP для специализированных или маломощных устройств, если заранее известны все возможные DNS-ответы и среди них не будет превышающих 512 бит, либо получение усеченных ответов не влияет на нормальное функционирование системы.

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

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

Также стандарт устанавливает порядок использования протоколов. Резолвер прежде всего должен попытаться выполнить UDP-запрос, должен, но не обязан.

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

В случае если TCP-соединение с сервером уже установлено, то клиент может продолжать его использовать не возвращаясь на протокол UDP.

Слона надо есть по частям

Время от времени нам задают вопросы типа: «Вот настроил по вашему (или любому другому) мануалу и не работает». На уточняющий вопрос что именно не работает обычно ответа нет, не работает – и все тут.

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

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

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

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

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

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

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

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

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

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

Если вы не понимаете, что происходит и как это все работает, то начните именно с составления такой схемы.

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

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

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

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

А что тут грузят?

А грузят тут дисковый накопитель IBM 350, который хранил около 5 миллионов 6-битных символов (примерно 3,75–5 МБ), используя 50 дисков диаметром 24 дюйма (61 см), вращающихся на 1200 об/мин, с двумя независимыми манипуляторами для чтения/записи.

Весило все это добро более 1 тонны и требовало с собой особого обращения.

Цена на тот момент составляла от $9 200 или в современных ценах $106 200.

Ubuntu Cleaner – простой и удобный инструмент для очистки системы

Многие обычные пользователи Linux сетуют на отсутствие простых и привычных инструментов обслуживания системы. И эти претензии во многом обоснованы.

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

🔸 Ubuntu Cleaner – одна из таких утилит. Ее предназначение – очистка дискового пространства в системе, т.е. одна из наиболее часто востребованных функций, особенно сейчас, с ростом цен на твердотельные накопители.

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

Для установки вам потребуется подключить PPA-репозиторий или скачать DEB-пакет со страницы разработчика: https://github.com/gerardpuig/ubuntu-cleaner

Для установки через PPA выполните:

apt install software-properties-common
add-apt-repository ppa:gerardpuig/ppa
apt update
apt install ubuntu-cleaner

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

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

Из поддерживаемых систем заявлена Ubuntu, но по идее программа должна работать на любом совместимом дистрибутиве на базе Debian.

GigaCode – теперь полноценный агентский режим

Мы уже рассказывали про ИИ-помощник GigaCode (https://t.me/interface31/5274), который можно было подключить как плагин в популярную среду разработки VS Code и заставить искусственный интеллект помогать нам с написанием кода.

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

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

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

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

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

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

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

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

Для проверки мы решили создать проект с нуля, исключительно силами GigaCode, для этого создали в VS Code новое рабочее пространство и коротко, обычным языком описали агенту чего мы хотим, а захотелось нам скрипт на PowerShell.

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

Ошибки, к сожалению, он все также допускает, часть из них глупые и сам VS Code предлагает их исправить. Но мы просто скопировали текст ошибки в чат с агентом, и он сам прекрасно все сделал.

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

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

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

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

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

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

Девушки в отрасли

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

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

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

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

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

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

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

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

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

И сейчас уже далеко не редкость полностью IT-семьи, где оба супруга работают в одной отрасли и понимают друг друга, чтобы не получилось, как в том анекдоте: «я не сифилитик, а филателист».

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

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

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

Поздравляю всех наших коллег и читательниц с Женским днем! Здоровья, красоты и всего самого наилучшего!!!

ИИ как печатный станок в программировании

Интересная новость появилась еще перед мартовскими праздниками:

Дэн Бланшар (Dan Blanchard), разработчик Python-библиотеки chardet для определения кодировки символов, выпустил новую версию библиотеки под лицензией MIT вместо ранее применявшейся лицензии LGPL.

Разработчик утверждает, что AI-ассистент Anthropic Claude, который теперь числится в списке контрибьюторов, переписал библиотеку без использования оригинального кода, что позволило ему заменить копилефт лицензию на пермиссивную.

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

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

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

Брюс Перенс, один из ключевых лидеров движения Open Source и Free Software считает, что написание кода при помощи ИИ в ближайшее время кардинально изменит рынок ПО, сравнив это явление с изобретением печатного станка.

И он во многом прав. Печатный станок позволил просто и быстро тиражировать бумажные книги. Сделав печатные издание дешевле и доступнее.

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

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

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

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

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

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

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

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

Теперь нас ждет примерно тоже самое на рынке ПО: масса софта самого сомнительного качества и назначения. Теперь не нужно часами сидеть над кодом, проектировать архитектуру приложения и делать прочие сложные и скучные вещи.

Теперь берем ИИ и говорим ей: напиши мне тоже самое, только на самом супер-пупер модном и молодежном фреймворке, а вот сюда добавь перламутровые пуговицы и розового котика.

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

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

Аптайм

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

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

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

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

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

Еще одна популярная отмазка: «мол у меня там важные сервисы 24/7 и совсем-совсем никак» — это ничто иное как завуалированное признание собственной низкой квалификации. Ее следует понимать как: вот тут у меня огромная точка отказа, сюда столько всего накручено и завязано, что даже перезагружать страшно.

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

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

Равно как не стоит говорить о «важных» и «круглосуточных» сервисах. Если они построены так, что их нельзя вывести на облуживание – значит они построены плохо. И нужно не бравировать этим, а думать, как сделать хорошо. Или пригласить того, кто может это сделать.

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

Скомпрометированные пароли

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

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

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

Как это сделать? Можно использовать базу HIBP, где содержится более 306 миллионов утекших в сеть паролей.

Для этого следует использовать специальный сайт https://haveibeenpwned.com/Passwords

Можно ли ему доверять и не грозит ли это утечкой пароля?

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

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

Кроме того, если вы не доверяете свои пароли никаким онлайн-сервисам или хотите самостоятельно работать с базой утекших паролей, то вы можете скачать ее при помощи инструмента PwnedPasswordsDownloader https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader

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

На скриншоте мы проверили в сервисе один очень «популярный» пароль из десяти букв и цифр подряд на клавиатуре, набранных по очереди: 1q2w3e45t

Демилитаризованная зона (DMZ) в современных сетях

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

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

Для узлов локальной сети все узлы DMZ также рассматривались как внешние, со всеми вытекающими выводами в сфере безопасности.

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

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

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

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

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

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

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

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

Еще одна серьезная угроза – это удаленщики, явление в последние годы массовое и практически неконтролируемое. Потому как вы не можете сказать кто именно сейчас на том конце соединения: сам сотрудник или его малолетний ребенок, а может он вообще забыл ноутбук где-нибудь в кафе.

И все что защищает VPN – это только сам канал доступа, от некорректных действий со стороны пользователя это не спасет. Поэтому мы последние несколько лет практикуем дополнительные DMZ именно для VPN-пользователей.

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

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

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

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

Как правильно редактировать юниты systemd

Сегодня systemd стал безальтернативной системой управления службами в дистрибутивах первого эшелона и предоставил администраторам простые и удобные возможности для решения этой задачи.

Действительно, сравните сложность написания init-файла и юнита. 🤷🏻‍♀️

И, как всякая хорошо спроектированная и продуманная система systemd предполагает многоуровневую систему управления юнитами.

Начнем с мест их расположения, которые перечислим в порядке повышения приоритета:

▫️ /usr/lib/systemd/system – юниты установленные вместе с пакетами
▫️ /run/systemd/system – юниты, которые создаются автоматически при загрузке системы и существующие только в рамках текущего сеанса
▫️ /etc/systemd/system – юниты, созданные системным администратором

Директория /etc/systemd/system имеет наивысший приоритет и если нам нужно изменить существующий юнит службы, то мы можем скопировать его сюда из /usr/lib/systemd/system и внести свои изменения.

Вроде бы просто, да не совсем. При обновлении пакета юнит в /usr/lib/systemd/system тоже будет обновляться, при этом, в отличии от изменения конфигурационных файлов, никакого предупреждения мы не получим.

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

К чему это может привести? Да к чему угодно и отловить причину внезапно возникшего непонятного поведения службы может быть достаточно проблематично.

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

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

Скажем, нам нужно внести изменения в работу юнита myservice.service, для этого мы должны создать каталог /etc/systemd/system/ myservice.service.d и поместить в него один или несколько фалов с расширением conf.

Проще всего это сделать с помощью команды:



 systemctl edit myservice


Напоминаем, что если вы не указали тип юнита, то по умолчанию он принимается за service, а если вам нужно внести изменения в таймер, то придется указать имя юнита полностью:



 systemctl edit myservice.timer


Затем указываем только те опции, которые хотим переопределить или добавить, например:



 [Unit]
 Requires=новая зависимость
 After=новая зависимость


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

Если вы добавите:



 [Service]
 ExecStart=новая команда


То эта строка будет добавлена к существующим строкам ExecStart в юните, если вы хотите переопределить это значение, то его сначала необходимо сбросить:



 [Service]
 ExecStart=
 ExecStart=новая команда


Если у вас несколько Drop-in файлов, то изменения в них будут применяться по очереди, для расстановки приоритетов можете использовать цифровые префиксы файлов.

Еще одним достоинством команды systemctl edit является то, что по окончании редактирования конфигурация systemd будет перечитана, а служба перезапущена.

Откатить изменения можно командой



 systemctl revert myservice


Если вы редактируете drop-in файлы вручную, то после каждого изменения перечитайте конфигурацию:



 systemctl daemon-reload


И перезапустите службу



 systemctl restart myservice


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

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

Настраиваем терминальный сервер на Windows Server в рабочей группе

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

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

Но есть и определенные сложности: начиная с Windows Server 2012 компания Microsoft решила, что для развертывания терминальных служб обязательно нужен домен Active Directory.

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

✅ Читать далее