По мотивам реальных событий

▫️ Вася решил мониторить температуру произвольных устройств.

▫️ Вася решил использовать для этого sensors

▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:

UserParameter=lm.nvme0Temperature,sensors | tail -n 3 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

UserParameter=lm.nvme1Temperature,sensors | tail -n 8 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

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

❓Что не так сделал Вася?

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

▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.

▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.

▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.

▫️ Затем это все передается команде awk, где и происходит основная магия.

🔹 -F'[:+°]' – делим строку по указанным разделителям, искомое нами значение является третьим полем, так как располагается между плюсом и градусом.

🔹 {avg+=$3} – суммируем третье поле от всех строк в файле, эта конструкция перекочевала сюда из вышестоящей директивы для процессора, где в выводе не было общей температуры, но была температура по ядрам. В итоге мы отбирали количество строк по числу ядер и выводили среднюю.

🔹 END{print avg/NR} – выводит среднее значение разделенное на количество строк в стандартны поток ввода-вывода.

👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.

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

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

Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:

nvme-pci-0100
Adapter: PCI adapter
Composite:    +37.9°C  (low  =  -0.1°C, high = +114.8°C)
                       (crit = +119.8°C)

Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:

sensors | grep nvme-pci-0100 -A 2

Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:

sensors | grep nvme-pci-0100 -A 2 | tail -n 1

И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:

sensors | grep nvme-pci-0100 -A 2 | tail -n1 | awk -F'[:+°]' '{print $3}'

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

Раскрашиваем логи при помощи ccze

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

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

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

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

✅ Читать далее: https://interface31.ru/post/adminu-na-zametku-31-rasskrashivaem-logi-pri-pomoshhi-ccze/

Zabbix - основы и базовые понятия

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

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

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

✅ Читать далее: https://interface31.ru/post/zabbix-osnovy-i-bazovye-ponyatiya/

Садись кибитка – тюрьма поехали

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

Что произошло? Ровно то, о чем мы писали в апреле этого года: https://t.me/interface31/5975

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему у жесткого диска указан TRIM и что это обозначает?

Итак, откуда у жесткого диска команда TRIM

К сожалению, правильный ответ на вопрос дали немногие читатели. И это действительно диск с SMR, а наличие поддержки TRIM у жесткого диска – 100% признак черепицы.

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

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

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

Более подробно об этом в нашей статье: Что такое черепичная магнитная запись SMR и стоит ли ее избегать?

Настраиваем сетевую файловую систему NFS в Debian и Ubuntu

NFS (Network File System) - сетевая файловая система в Linux и UNIX-like системах позволяющая монтировать сетевые ресурсы удаленного компьютера и работать с ними как с локальными.

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

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

✅ Читать далее: https://interface31.ru/post/nastraivaem-setevuyu-faylovuyu-sistemu-nfs-v-debian-i-ubuntu/

Подальше положишь – поближе возьмешь?

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

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

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

А папочка была закреплена как рабочая область в VS Code и ее физическое расположение благополучно забылось.

Ну и дальше все по классике, что-то пошло не так и после очередного обновления VS Code запускаться перестал. Пришлось переустановить.

А где теперь мой пет-проект? А нету его. И найти его в файловой системе он не смог. Поиск тоже ничего внятного не дал, ибо было не очень понятно, что именно искать. Возникла паника и теории заговора, мол VS Code, при удалении папку проекта снес и так далее и все такое прочее.

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

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

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

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

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

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

В оригинале можно ознакомиться здесь: https://learn.microsoft.com/ru-ru/troubleshoot/sql/database-engine/database-file-operations/considerations-autogrow-autoshrink

Мертвые форматы
 
Встретился случайно с одним своим знакомым, который работает в бюджетной организации, и сразу вспомнил эту историю. Дело было где-то в середине десятых, из организации списали последние компьютеры на Windows 9x и выяснилась одна крайне неприятная вещь.
 
Практически весь электронный архив документов оказался в формате AWD, который на современных системах прочитать нельзя никак. Вообще никак, без шансов. И весь огромный архив сканов одним моментом превратился в тыкву.
 
Решение тогда нашли в виртуалке с Windows 98 на борту, через которую все это методично перегонялось в современный PDF. Но, как выяснилось, отдельные документы в AWD находят до сих пор, и эта схема по сей день востребована.
 
А вообще история показательна. В свое время Microsoft не стала заморачиваться и для своей подсистемы At Work Fax (AWD) приобрела компонент Imaging for Windows у сторонней компании, которая позже была куплена компанией Kodak. Доступа к исходным кодам у нее не было и компонент поставлялся по ограниченному лицензионному соглашению.
 
Причем существовал он только для линейки 9x, в NT поддержки AWD изначально не было. А с выходом Windows XP и вовсе решили от него отказаться, нежели платить Kodak за новую версию (если она вообще существовала в природе). После чего формат AWD резко осиротел.
 
Масштаб бедствия можно оценить по тому, что этот формат предлагался при сканировании штатными средствами по умолчанию и пользователи не видели особого смысла выбирать что-то иное.
 
Но в Microsoft решили, что одного раза недостаточно, и чтобы не платить за лицензию теперь уже Adobe, они, начиная с Windows Vista, ввели и начали агрессивно продвигать собственный формат – XPS (XML Paper Specification), который позже был стандартизирован как OpenXPS.
 
А в системе устанавливался по умолчанию виртуальный принтер Microsoft XPS Document Writer, который, казалось бы, закрывал главную проблему тех лет – конвертацию документа в универсальный формат, который везде будет открываться одинаково.
 
Напомним, что Adobe сделала PDF открытым только в 2008 году, а до этого массовых бесплатных решений для конвертации в этот формат не существовало. Поэтому формат достаточно активно использовался, но повальной популярности, как в свое время AWD, не достиг.

Сам по себе формат XPS был технически неплох: по сути, ZIP-архив с разметкой XAML, векторной графикой и шрифтами. Но он оказался за пределами мира Windows никому не нужен.
 
В macOS его просто проигнорировали, а в Linux определенные попытки были, но разработка велась по остаточному принципу и существующие библиотеки обеспечивают только базовую поддержку формата.
 
К выходу Windows 10 Microsoft признала провал и внедрила в систему нативный Microsoft Print to PDF, что сразу лишило формат XPS смысла существования. А дальше все пошло по классике: начиная с выпуска 1803, утилиту XPS Viewer перестали устанавливать по умолчанию и перенесли в раздел опциональных компонентов, откуда его нужно устанавливать вручную.
 
А начиная с Windows 11 24H2 формат признан устаревшим, и его поддержка полностью удалена из дистрибутива.
 
В результате через какое-то время пользователи снова могут оказаться в ситуации, когда документы есть, а открыть их нечем. Даже если формат открытый, какой смысл в открытости, если он никому не нужен и никем не поддерживается.
 
И чтобы прочитать и конвертировать такие документы, снова придется идти проторенным путем – поднимать виртуалку с устаревшей системой.
 
А какие мертвые форматы документов встречались вам?

Прекращена поддержка Debian 11

31 августа 2026 года поддержка дистрибутива Debian 11 прекращена. Репозитории официально переведены в архив, обновлений безопасности больше не будет. Одновременно с ним во вторую стадию поддержки перешел Debian 12.

Что это значит? Схема поддержки Debian построена следующим образом: три года обычной поддержки и два года LTS. Но последний термин не должен сбивать вас c толку, LTS поддержка обеспечивается отдельной командой и распространяется не на весь дистрибутив.

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

Справедливости ради следует сказать, что существует еще Extended LTS, которая осуществляется энтузиастами и силами компании Freexian и будет поддерживать Debian 11 до 30 июня 2031 года.

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

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

Debian или Ubuntu

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

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

1️⃣ Debian. Официально Debian не имеет строгого релизного цикла, так как основной упор команда разработчиков делает на качестве, и выпуск новой версии дистрибутива производится тогда, когда он будет соответствовать внутренним стандартам качества, а не к определенной дате.

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

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

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

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

За пределами пятилетнего цикла доступны дополнительные пять лет коммерческой ELTS поддержки от компании Freexian, при этом уровень этой поддержки и состав поддерживаемых пакетов определяется самой компанией, а точнее ее спонсорами.

2️⃣ Ubuntu. Выпуски дистрибутива с долгосрочной поддержкой (LTS) происходят по строго определенному двухгодовому графику. Таким образом каждый апрель каждого четного года мы получаем новый выпуск системы.

Ubuntu LTS получает пятилетнюю поддержку от компании-разработчика, которая распространяется на весь дистрибутив в части разделов main и restricted,  и в течении этих пяти лет он будет получать обновления и улучшения пакетов, исправления ошибок и обновления безопасности.

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

За пределами стандартной пятилетней поддержки доступна коммерческая поддержка ESM еще на пять лет, которая предоставляется также компанией-разработчиком и распространяется на весь дистрибутив. В течении этого времени он будет получать обновления безопасности и исправления критических багов, причем не только для main, но и для universe.

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

👉 Таким образом, как мы видим, есть довольно существенная разница в релизном цикле и способах поддержки Debian и Ubuntu.

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

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

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

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

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

Протоколы быстрого роуминга Wi-Fi 802.11k/v/r

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

В самом простейшем случае роуминг представляет собой обычное переподключение, когда клиент обнаружив слабый сигнал от точки доступа (обычно -75 дБи и ниже) начинает поиск альтернативных точек и подключается к той, которая предоставляет наиболее сильный сигнал.

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

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

🔹 802.11k: Radio Resource Measurement - позволяет точкам и клиентам динамически обмениваться информации о состоянии среды передачи, что позволяет клиенту быстрое и проще понять куда можно переподключиться.

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

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

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

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

🔹 802.11v: Wireless Network Management – протокол, используемый в связке с 802.11k и позволяющий проактивно управлять беспроводной сетью.

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

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

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

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

🔹 802.11r: Fast BSS Transition – протокол быстрого переключения, который позволяет ускорить этот процесс за счет предварительной аутентификации и генерации сессионных ключей.

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

Это может занимать до 0,7 – 1 с, что приводит к разрывам VoIP соединений, зависанию видеоконференций, лагам в онлайн-играх и т.д.

802.11r предлагает выполнять предварительную аутентификацию и генерацию ключей для подключения к другой точке еще до разрыва старого подключения, что позволяет радикально сократить время переключения до 15-50 мс.

Однако для ее поддержки требуется WPA2-Enterprise или WPA3, что делает технологию пока недоступной большинству домашних и SOHO пользователей.

Когда vSphere уже «трофейная», а продлевать нечего 🙃

24 сентября в 11:00 (МСК) CNS и Orion Soft проводят вебинар про
zVirt, российскую платформу виртуализации на замену VMware
vSphere и Hyper-V.

Покажем на живом демо-стенде, в реальном интерфейсе:
▫️ живую миграцию ВМ
▫️ гиперконвергенцию
▫️ SDN
▫️ DR и катастрофоустойчивость
▫️ управление всем этим из одной консоли, без «зоопарка»

Отдельно для тех, у кого КИИ: сертифицированная ФСТЭК редакция и реестр отечественного ПО, то есть что показать безопасникам и регулятору.

👉 Регистрация: Здесь
#реклама
О рекламодателе

​​Спрашивают – отвечаем. Какой утилитой можно посмотреть какой процесс сколько занимает памяти.

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

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

Утилита достаточно проста, прежде всего запустим ее с ключом -h, чтобы посмотреть доступные ключи. Их немного.

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

Всего колонок четыре, коротко разберем что они обозначают:

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

🔸 PSS – пропорциональный объем памяти, наиболее интересное с практической точки зрения число, так как объем памяти разделяемых библиотек делится пропорционально между процессами, например, если у нас три процесса используют одну и ту же библиотеку, то занимаемый ею объем памяти поделится на троих.

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

🔸 Swap – объем сброшенных в подкачку страниц памяти процесса.

Сразу запоминаем полезные ключи программы:

▫️ -t - выводит снизу результирующую строку по всем колонкам
▫️ -p – представляет значение в процентах от общего объема памяти, а не в килобайтах
▫️ -а – подстраивает ширину колонок под текущий размер окна терминала

Как мы уже говорили, сортировка ведется по возрастанию колонки PSS, т.е. самые «жирные» процессы будут внизу.

Это поведение можно изменить ключами -s и -r, после которых следует указать имя колонки для сортировки. Ключ -r сортирует значения в обратном порядке – по убыванию значений.

Например, чтобы посмотреть кто использует Swap в процентах по убыванию значений, используйте:

smem -tap -r swap

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

Также мы можем делать отборы по имени процесса или его владельцу, например, посмотрим все процессы Postgres по убыванию в процентах:

smem -tpa -P postgres -r pss

Или все процессы пользователя 1С:Предприятия:

smem -tpa -U usr1cv8  -r pss

Что еще можно посмотреть с ее помощью? Использование памяти в разрезе пользователей с ключом -u или по всей системе с ключом -w.

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

Сеанс двоичной магии с разоблачением

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

Начнем с просто примера: 192.168.1.100 с маской 255.255.255.0 или /24

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

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

128 | 64 | 32 | 16 | 8 | 4 | 2 | 1

Теперь берем первый октет, проверяем, помещается ли первое число 128 в 192? Помещается, ставим 1. Затем вычитаем из 192 число 128, получаем 64. Проверяем со вторым числом, помещается, снова ставим 1 и вычитаем из остатка 64.

У нас остался ноль, в который не помещаются остальные числа, там проставляем ноли.

В итоге адрес 192.168.1.100 мы запишем как

11000000 10101000 00000001 01100100

Теперь маска, также переводим ее в двоичный вид. Но если с 255.255.255.0 все понятно, то как понимать /24? А просто, 24 обозначает что маска содержит 24 единицы, т.е. вам даже не нужно ничего переводить:

/24  = 255.255.255.0 = 11111111 11111111 11111111 00000000

А теперь начинается настоящая двоичная магия, записываем адрес и маску друг под другом:

11000000 10101000 00000001 01100100
11111111 11111111 11111111 00000000

Те части адреса, которые покрываются маской являются номером (префиксом) сети, а те, которые не попадают в маску – номером узла.

Таким образом у нас адрес сети (все что не попадает под маску меняем нолями):

11000000 10101000 00000001 00000000

Что соответствует 192.168.1.0

Минимальным адресом сети будет:

11000000 10101000 00000001 00000001 = 192.168.1.1

Максимальным:

11000000 10101000 00000001 11111110 = 192.168.1.254

А последний доступный адрес в сети является широковещательным:

11000000 10101000 00000001 11111111 = 192.168.1.255

Теперь поменяем маску на /23 или 255.255.254.0 и посмотрим, что изменится:

11000000 10101000 00000001 01100100
11111111 11111111 11111110 00000000

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

11000000 10101000 00000000 00000000 = 192.168.0.0

Минимальный адрес:

11000000 10101000 00000000 00000001 = 192.168.0.1

Максимальный адрес:

11000000 10101000 00000001 11111110 = 192.168.1.254

Широковещательный адрес:

11000000 10101000 00000001 11111111 = 192.168.1.255

А теперь вернемся к примеру из пятничного вопроса:

5.6.7.0/23

00000101 00000110 00000111 00000000
11111111 11111111 11111110 00000000

Адрес сети:

00000101 00000110 00000110 00000000 = 5.6.6.0

Минимальный адрес:

00000101 00000110 00000110 00000001 = 5.6.6.1

Максимальный адрес:

00000101 00000110 00000111 11111110  = 5.6.7.254

Широковещательный адрес:

00000101 00000110 00000111 11111111  = 5.6.7.255

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

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

Почему? Расписываем в двоичном виде адрес и маску и понимаем, что сети с адресами 5.6.6.0/23 и 5.6.8.0/23 существовать могут, а вот сеть с адресом 5.6.7.0/23 – нет.

Что такое SRV-записи DNS и для чего они нужны

В комментариях к нашим заметкам по DNS уже не раз спрашивали: что такое SRV-записи и для чего они нужны.

Начнем немного издалека. Все знают, что основная задача DNS сервера – это разрешение имен, т.е. преобразование понятных человеку доменных имен в IP-адреса. Для этого используется запись типа А, которая прямо сопоставляет имя и IP-адрес. Например:

pc-petya   IN A 192.168.121.156

Она говорит, что узел сети с именем pc-petya имеет адрес 192.168.121.156.

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

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

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

Что мы будем делать в реальном мире? Правильно, спросим: а где тут почта?

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

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

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

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

Но благодаря этому одним типом записи мы можем закрыть все текущие службы и новые, которые могут появиться в будущем. Достаточно лишь знать название службы, а остальное нам сообщит наша универсальная справочная (DNS-сервер).

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

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

_xmpp-server._tcp 21600 IN SRV 20 0 5269 domain-xmpp.yandex.net.

Имя записи: _xmpp-server._tcp – т.е. межсерверное общение XMPP-серверов по протоколу TCP.

Далее идет TTL – 21 600 сек (6 часов) и тип записи IN SRV, после чего указан ее приоритет – 20 (здесь как в MX – чем ниже, тем предпочтительнее) и вес 0 (используется для выбора нескольких записей с одинаковым приоритетом), затем порт – 5269 и узел, на котором располагается данная служба - domain-xmpp.yandex.net.

Обратите внимание на точку на конце – она обозначает абсолютный путь, в противном случае такой адрес служба DNS дополнит текущим доменом.

А вот еще запись:

_xmpp-client._tcp 21600 IN SRV 20 0 5222 domain-xmpp.yandex.net.

Она отличается только именем _xmpp-client._tcp и сообщает куда должны подключаться XMPP-клиенты через TCP. Также можем увидеть здесь другой порт.

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

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

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

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