Введение

Я делала много вещей с компьютерами, но в моих знаниях всегда был пробел: что конкретно происходит при запуске программы на компьютере? Я думала об этом пробеле — у меня было много низкоуровневых знаний, но не было цельной картины. Программы действительно выполняются прямо в центральном процессоре (central processing unit, CPU)? Я использовала системные вызовы (syscalls), но как они работают? Чем они являются на самом деле? Как несколько программ выполняются одновременно?

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

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

Более удобный формат статьи.

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

Что это, как они работают в ОС и Linux? Давайте разберемся вместе!

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

Хочу поделиться с сообществом простым и полезным шаблоном скрипта-обёртки на bash для запуска заданий по cron (а сейчас и systemd timers), который моя команда повсеместно использует много лет.

Сначала пара слов о том зачем это нужно, какие проблемы решает. С самого начала моей работы системным администратором linux, я обнаружил, что cron не очень удобный планировщик задач. При этом практически безальтернативный. Чем больше становился мой парк серверов и виртуальных машин, тем больше я получал абсолютно бесполезных почтовых сообщений "From: Cron Daemon". Задание завершилось с ошибкой - cron напишет об этом. Задание выполнено успешно, но напечатало что-нибудь в STDOUT/STDERR - cron всё равно напишет об этом. При этом даже нельзя отформатировать тему почтового сообщения для удобной автосортировки. Сначала были годы борьбы с использованием разных вариаций из > /dev/null, 2> /dev/null, > /dev/null 2>&1, | mail -E -s '<Subject>' root@.

Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.

С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).

Круто, что docker реально ускоряет разработку во множество раз. Если вести ее правильно, то даже без потери в качестве. В любом случае, docker здесь, от него не деться и приходится им пользоваться.

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

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

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

Сборная солянка из существующих best practices по работе с Grafana и немного с Prometheus, проверенных мной лично. Можно просто положить в закладки — когда-нибудь да пригодится.

Если вы столкнулись с «особой» проблемой медленного интернета и никакие танцы с бубном вам не помогают, то это статья для вас.

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

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

Привет, HABR!

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

1. Распространение файлов конфигураций UserParameter

2. Необходимость перезапуска zabbix-agent после добавления UserParameter

3. Не нулевой шанс, что zabbix-agent не запустится после добавления некорректного файла конфигурации UserParameter

Проблему под пунктом 1 затрагивать не будем и перейдем к оставшимся двум, т.к. решив проблему 2 и 3 пунктов, та что под №1 станет немного менее проблемной потому-что мы не будем бояться сломать запуск zabbix-agent при распространении файлов UserParameter. 

Мне всегда хотелось иметь возможность отлаживать bash-scripts так же, как и любой другой код, т.е. по шагам, и bash такую возможность предусмотрел, но о ней не все знают. Несмотря на довольно большой опыт использования Linux, я дошёл до неё только недавно.

Устройства компании Mikrotik стали широко распространены из-за своей цены по отношению к функционалу. Но и ошибки в программном обеспечении никто не отменял. И на этот раз вылез серьёзный баг.

25 марта один из пользователей форума Mikrotik сообщил об обнаружении подозрительной активности маршрутизаторов mikrotik с применением портов telnet (TCP port 23), TR-069 (TCP port 7547) и WINBOX (TCP 8291).

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

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