LinuxCamp | DevOps

Полезные опции для поиска файлов через grep

Иногда нужно найти один/несколько файлов, содержащих определённую строку в: логах, конфигах или исходном коде. Для этого очень часто под рукой оказывается утилита grep. Для сводки, интересные флаги и регулярные выражения для grep мы рассматривали тута.

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

$ grep -r "root" /etc/
/etc/mdadm/mdadm.conf:MAILADDR root
...

Если хотим подсветить вхождения цветом, используем опцию "--color=always":

$ grep --color=always -r "root" /etc/

Опции "-C, -B, -A" вообще имбовые, использую их целую неделю) Вы можете включить отображение не только текущей строки, в которой было найдено вхождение, но и n строк до/после:

1) -C: выводит n строк до и после вхождения;

$ grep -C2 -r --color=always "Hello3" ./
./hello-Hello1
./hello-Hello2
./hello:Hello3
./hello-Hello4
./hello-Hello5

2) -B: выводит n строк перед вхождением;

$ grep -B2 -r --color=always "Hello3" ./
./hello-Hello1
./hello-Hello2
./hello:Hello3

3) -A: выводит n строк после вхождения;

$ grep -A2 -r --color=always "Hello3" ./
./hello:Hello3
./hello-Hello4
./hello-Hello5

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

Без флага мы получим строки, в которых присутствует хотя бы 1 символ из набора (H, e, l, o). С флагом получим строки с буквальным совпадением:

$ grep "[Hello]" hello
Help me please
Helloup
[Hello]

$ grep -F "[Hello]" hello
[Hello]

LinuxCamp | #utils

⚡️ Дождались! Ребята сделали крутейший канал про Linux

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

Подписывайтесь: @linuxos_tg

В смысле DevOps?

Друзья, вижу ваше негодование по поводу добавления DevOps к каналу) И прям читаю мысли: "Где тут вообще DevOps?!" Так вот, правки внесены не просто так.

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

Посты от редакторов будем маркировать тегом: by + имя (#bymaga).

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

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

LinuxCamp | #info

Залутал гуся на cpp конфе 🐥

Утилиты для работы с DBus сервисами

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

1) qdbusviewer: графическая Qt утилита, которая позволяет просматривать активные сервисы в которые можно постучаться по системной (system bus) или пользовательской (session bus) шине. Она предоставляет удобный интерфейс для работы с объектами, методами и сигналами.

$ sudo apt install qttools5-dev-tools
$ qdbusviewer

2) dbus-send: низкоуровневый cmd инструмент, который позволяет вручную отправлять запросы к сервисам:

$ sudo apt install dbus
$ dbus-send --system --dest=com.redhat.tuned --type=method_call --print-reply /Tuned com.redhat.tuned.control.active_profile

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

3) dbus-monitor: выводит на консоль информацию о сигналах в момент их получения либо о методах в момент вызова:

$ dbus-monitor "type='method_call',interface='org.kde.Solid.PowerManagement'"

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

4) busctl: современный аналог dbus-send, включен в systemd. С помощью утилиты можно вызывать (busctl call) методы и прослушивать (busctl monitor) события. Также можно выводить список узлов на пользовательской и системной шинах:

$ sudo apt install systemd

$ busctl call com.redhat.tuned /Tuned com.redhat.tuned.control active_profile

$ busctl --system monitor "com.redhat.tuned.control" "profile_changed"

$ busctl --user list
$ busctl --system list

LinuxCamp | #utils

Возможности для молодых людей в «Алабуге», Республике Татарстан

В особой экономической зоне «Алабуга» активно развивается лидерская программа «100 Лидеров». В ней могут поучаствовать молодые специалисты от 19 до 26 лет.

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

Питание и проживание за счет компании.

Работа в «Алабуге» - это зарплата от 110 до 240 тысяч рублей и участие в реализации проектов мирового уровня.

Следующий поток - с 5 по 9 апреля!
Заявку можно подать на сайте

Как я познакомился с Димасом Dbus-ом

В общем-то, с dbus я уже был ранее знаком, но последние рабочие такски заставили меня прибегнуть к практике. Если кто не в танке, dbus (Desktop Bus) - это система межпроцессного взаимодействия в Linux. Позволяет она удобно из одного приложения дергать код другого, подписываться на сигналы и передавать информацию.

Задача была следующая - на стороне приложения отслеживать профили энергопотребления системы (balanced, powersave, performance) и корректировать поведение для экономии заряда либо выдавать сверх производительность.

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

1) tuned (com.redhat.tuned) - приложение, которым можно переключать и отслеживать профили. Можно использовать независимо от окружения;

2) PowerManagement (org.kde.Solid.PowerManagement) - kde модуль, который позволяет отслеживать состояние батареи: идет ли питание от провода, низкий ли заряд и т.д.;

По итогу, через PowerManagement получилось отследить 3 состояния: AC (питание по проводу), Battery и LowBattery. Если хотите проверить у себя:

$ qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement org.kde.Solid.PowerManagement.currentProfile

Полный интерфейс вывести можно вот так:

$ busctl --user introspect org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement

Приложение tuned позволило более гибко настроить приложуху и отследить профили (balanced, powersave, performance), которые могут выставляться независимо от заряда батареи. Узнать профиль:

dbus-send --system --dest=com.redhat.tuned --type=method_call --print-reply /Tuned com.redhat.tuned.control.active_profile

Вывести полный интерфейс:

$ busctl --system introspect com.redhat.tuned /Tuned

Конечно же для языка C у нас есть либа (libdbus), через которую аналогичную процедуру можно реализовать кодом. Задача еще в работе, поэтому по мере своего продвижения в dbus буду постить полезности.

LinuxCamp | #story

Как я познакомился с Димасом Dbus-ом

В общем-то, с dbus я уже был ранее знаком, но последние рабочие такски заставили меня прибегнуть к практике. Если кто не в танке, dbus (Desktop Bus) - это система межпроцессного взаимодействия в Linux. Позволяет она удобно из одного приложения дергать код другого, подписываться на сигналы и передавать информацию.

Задача была следующая - на стороне приложения отслеживать профили энергопотребления системы (balanced, powersave, performance) и корректировать поведение для экономии заряда либо выдавать сверх производительность.

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

1) tuned (com.redhat.tuned) - приложение, которым можно переключать и отслеживать профили. Можно использовать независимо от окружения;

2) PowerManagement (org.kde.Solid.PowerManagement) - kde модуль, который позволяет отслеживать состояние батареи: идет ли питание от провода, низкий ли заряд и т.д.;

По итогу, через PowerManagement получилось отследить 3 состояния: AC (питание по проводу), Battery и LowBattery. Если хотите проверить у себя:

$ qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement org.kde.Solid.PowerManagement.currentProfile

Полный интерфейс вывести можно вот так:

$ busctl --user introspect org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement

Приложение tuned позволило более гибко настроить приложуху и отследить профили (balanced, powersave, performance), которые могут выставляться независимо от заряда батареи. Узнать профиль:

dbus-send --system --dest=com.redhat.tuned --type=method_call --print-reply /Tuned com.redhat.tuned.control.active_profile

Вывести полный интерфейс:

$ busctl --system introspect com.redhat.tuned /Tuned

Конечно же для языка C у нас есть либа (libdbus), через которую аналогичную процедуру можно реализовать кодом. Задача еще в работе, поэтому по мере своего продвижения в dbus буду постить полезности.

LinuxCamp | #story

Почему BIOS нужно называть UEFI и как его разрабатывают

BIOS — это системное программное обеспечение, которое встроено прямо в материнскую плату и хранится в энергонезависимой памяти: как правило, это SPI Flash. Даже если на материнской плате нет жесткого диска или другого накопителя данных, BIOS уже присутствует. Сейчас BIOS правильнее называть UEFI, но по инерции многие продолжают называть эту систему BIOS.

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

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

Первые PC были системами с 16-битной адресацией и реальным режимом работы, они поддерживали максимум один мегабайт памяти, адресуемой посегментно. Использовать язык высокого уровня для написания ПО первичной инициализации таких систем было неэффективно, а порой и невозможно, поэтому для разработки BIOS использовали максимально низкоуровневый язык программирования — ассемблер.

В середине 90-х годов компания Intel начала разрабатывать процессоры с архитектурой Itanium. Анализируя BIOS, инженеры поняли, что его возможностей недостаточно для инициализации сложных систем с большим объемом памяти и 64-битными процессорами. В результате была разработана новая спецификация программной инициализации под названием EFI.

Что было дальше и как сейчас разрабатывают прошивки для ноутбуков и серверов, читайте в статье руководителя отдела разработки BIOS/UEFI российской компании YADRO.

Channel name was changed to «LinuxCamp | DevOps»