Как я познакомился с Димасом 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 сервисами. Коротко пробежимся по самым основным:

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

В смысле DevOps?

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

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

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

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

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

LinuxCamp | #info

Полезные опции для поиска файлов через 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

Как сделать службу недоступной?

Иногда возникает необходимость удалить службу Systemd или хотя бы сделать её недоступной для использования.

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

Самый простой способ избавиться от службы - это удалить пакет, вместе с котором она поставляется. Сначала нужно найти путь к файлу юнита. Это можно сделать с помощью команды "status":

$ systemctl status docker

docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)

Теперь узнаем имя пакета, с которым служба поставляется. Если мы работаем с deb сборками, используем флаг "-S":

$ dpkg -S /lib/systemd/system/docker.service
docker.io: /lib/systemd/system/docker.service

После того, как имя пакета известно, удаляем его:

$ sudo apt remove docker.io 

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

Замаскированные службы нельзя запустить вручную и они не активируются на старте системы (даже если добавлены в автозагрузку). Для маскировки используется команда mask:

$ sudo systemctl mask docker
Created symlink /etc/systemd/system/docker.service → /dev/null

Прикольно, конечно, реализована маскировка - в системном каталоге для сервисов создается симлинка на устройство "/dev/null" (говорили о нем тут).

Если посмотрим на состояние службы, увидим, что она замаскирована:

$ sudo systemctl status docker
docker.service
Loaded: masked (Reason: Unit docker.service is masked.)

Для того, чтобы убрать маскировку используем команду unmask. Ссылка удалится и не будет мешать старту сервиса:

$ sudo systemctl unmask docker
Removed /etc/systemd/system/docker.service.

LinuxCamp | #systemd

Собираем минимальный Docker образ

Docker — это инструмент для запуска приложений в изолированных контейнерах. Он делает разработку и развертывание проще, быстрее и безопаснее.

Нужен он для: изоляции приложений и зависимостей, переносимости (софтина работает одинаково на любой системе) и DevOps-процессов.

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

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

Минимальный пример запуска первого Docker-контейнера с Python (FastAPI):

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

$ sudo apt install python3 python3-pip -y
$ sudo apt install docker.io -y

После установки создаем рабочую папку:

$ mkdir fastapi_backend && cd fastapi_backend

Активируем виртуальное окружение, чтобы изолировать зависимости проекта и с помощью команды pip freeze автоматически сформировать requirements.txt, не заполняя его вручную:

$ python3 -m venv venv
$ source venv/bin/activate

Cкачиваем необходимые для создания API зависимости с помощью пакетного менеджера pip и сохраняем их в requirements.txt:

$ pip install fastapi uvicorn
$ pip freeze > requirements.txt

2. Создадим в каталоге проекта файл "main.py" с простым API:

$ touch main.py

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"Hello": "LinuxCamp"}

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

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["uvicorn", "main:app", "--host", "127.0.0.1", "--port", "8000"]

4. На этом все! Мы уже можем собрать свой Docker-образ и запустить его, после чего приложение будет доступно по адресу ниже:

$ sudo docker build -t myapp .
$ sudo docker run -d -p 8000:8000 myapp

$ curl -L http://127.0.0.1:8000 
$ {"Hello":"LinuxCamp"}

http://127.0.0.1:8000

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

$ docker ps

CONTAINER ID   IMAGE                     COMMAND             
640d6f4d1acb   fastapi_backend   "uvicorn main:app --…" 

LinuxCamp | #devops #docker #bymaga

systemd: проверка статуса службы

Система инициализации Systemd позволяет не только запускать и останавливать службы, но и проверять их состояние.

Для просмотра информации о сервисе используется команда status утилиты systemctl. Например, чтобы посмотреть состояние docker нужно выполнить:

$ systemctl status docker
 
docker.service - Docker Application Container Engine 
Loaded: loaded (/lib/systemd/system/docker.service; enabled;> 
Active: active (running) since ...

Давайте рассмотрим полный вывод:

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

Тут возможны и другие значения, например, masked если юнит скрыт или not-found если он не найден. Также здесь находится информация добавлен ли юнит в автозагрузку (enabled/disabled);

Active - текущее состояние и подсостояние юнита, если он запущен, выводится active(running), если он не был запущен, то inactive(dead) если что-то пошло не так, failed и т.д.

Docs - название man страницы с документацией для службы.

Process - запускаемые процессы, их состояние и код выхода.

Main PID - идентификатор основного процесса службы.

Tasks - количество процессов, запущенных в рамках этой службы.

Memory - потребление памяти службой.

CPU - использование процессора службой.

Для того чтобы посмотреть все доступные значения состояний для полей Loaded и Active выполните:

$ systemctl --state help

Списочек получите некороткий) За доп. инфой направлю вас в man.

После всех полей статуса выводится журнал службы - последние 10 строк вывода основного процесса.

Если хотите получить больше строк, используйте опцию "--lines" с нужным количеством:

$ systemctl status --lines=50 avahi-daemon

LinuxCamp | #systemd

Где же сидят эти службы?

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

1) системные службы, которые запускаются от суперпользователя. Для управления такими службами нужно использовать sudo.

2) пользовательские службы, которые запускаются от определённого юзера, который имеет над ними полный контроль без необходимости в sudo.

Системные службы лежат в:

1) /usr/lib/systemd/system;
2) /lib/systemd/system;
3) /etc/systemd/system;

Пользовательские служы лежат в:

1) /usr/lib/systemd/user;
2) /lib/systemd/user;
3) /etc/systemd/user;
4) /home/user/.config/systemd/user;

Файлы сервисов, поставляемые с пакетами, как правило, располагаются в каталогах lib и /usr/lib, а в /etc/ расположены модифицированные юниты, переопределяющие стандартные настройки.

LinuxCamp | #systemd

Как узнать тип сессии: Wayland или Xorg?

Многие популярные дистрибутивы уже используют Wayland по умолчанию. Однако у Wayland всё ещё есть проблемы. Многие старые программы не поддерживаются или работают плохо.

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

Самый простой способ посмотреть какой дисплейный сервер используется в данный момент, это вывести содержимое переменной окружения XDG_SESSION_TYPE:

$ echo $XDG_SESSION_TYPE
wayland

Кроме того, можно узнать тип текущей сессии с помощью loginctl. Для этого нужно сначала вывести список активных сессий через list-sessions:

$ loginctl list-sessions

SESSION  UID    USER      SEAT  TTY  
3      1000    parallels   seat0 tty2 
c1     127       gdm      seat0 tty1 
 
2 sessions listed.

Потом выводим тип конкретной сессии через опцию show-session:

$ loginctl show-session 3 -p Type
Type=wayland

Или можно сделать всё одной командой, получив идентификатор сессии из переменной окружения XDG_SESSION_ID (если определена):

$ loginctl show-session "$XDG_SESSION_ID" -p Type

LinuxCamp | #microhelp #sessions

Если часто просматриваешь логи, помни про "tail -f"

Команда "tail -f" отображает последние строки файла и продолжает обновлять вывод в реальном времени. Это особенно полезно, когда работаешь с журналами, типа syslog. Утилиты head и tail рассматривали тут.

Много раз слышал от людей, что они для дебага какого-то функционала сначала инициировали вывод в syslog, после чего либо через GUI редактор, либо через постоянный вызов tail просматривали логи. Как-то неэффективно...

Для решения задач такого типа предлагаю использовать:

$ tail -f /var/log/syslog

Если нужно отображать больше последних строк, чем по дефолту, дописывайте флаг "-n". Когда дополнительно нужно прогнать вывод через фильтр, grep в помощь:

$ tail -n 100 -f /var/log/nginx/access.log

$ tail -f /var/log/nginx/error.log | grep "timeout"

Я помню, как сам мучился с дебагом, когда не был в курсе про этот чудо-флаг) Дело в том, что не все приложения выдают лог в консоль. Если вы работаете с демоном, то у него нет управляющего терминала и все идет в журналы. Как раз тут и было бы весьма удобно использовать "tail -f".

LinuxCamp | #microhelp #utils

Удаление файлов старше n дней

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

Для CLI существует специальная команда find, которая отвечает за поиск файлов. Подробно говорили о ней тут.

С помощью опции "-mtime" получится найти только те файлы, дата изменения которых старше заданного временного промежутка. В качестве примера возьмем каталог Downloads и срок в 35 дней:

$ find ~/Downloads -type f -mtime +35

Следующий шаг – непосредственно чистка:

$ find ~/Downloads -type f -mtime +35 -delete

Вам необязательно действовать напрямую и стирать сразу же все файлы. Их можно отсортировать дополнительно по еще одному признаку, например, по названию или расширению. Для этого есть опция "-name":

$ find ~/Downloads -name "*.zip" -type f -mtime +35 -delete

Также, чтобы сгоряча не удалить нужный и недавно используемый файл, можно для каждого элемента вывода выполнить "ls -l" и посмотреть дату последнего изменения ресурса:

$ find ~/Downloads -type f -mtime +5 -exec ls -l {} \;
... Feb 17 17:30 ./file

LinuxCamp | #microhelp #utils

Из чего состоит Dockerfile

Dockerfile - это набор команд, по которым docker собирает образ контейнера. Для начала нужно немного разъяснить, как это работает под капотом.

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

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

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["uvicorn", "main:app", "--host", "127.0.0.1", "--port", "8000"]

Его и разберем построчно:

1) FROM - команда, которая создает базовый образ. В нашем случае это python:3.11-slim. Но что это и откуда берется? - из Docker Hub!

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

python:3.11-slim — это официальный образ Python версии 3.11 в минималистичной вариации "slim";

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

3) COPY - копирует файлы с хоста в контейнер. Можно заметить, что данная команда выполняется дважды в файле.

Сначала копируется только файл requirements.txt для того, чтобы разделить установку зависимостей и основной код. Это делается ради кэширования слоёв: файл зависимостей меняется редко, и при пересборке будет использоваться уже готовый слой;

4) RUN - выполняет команду внутри контейнера на этапе сборки и создаёт новый слой. В данном случае ставит зависимости из requirements.txt;

5) Ещё один "COPY . ." — теперь закидываем остальной код проекта в контейнер.

6) Последняя инструкция CMD - не создает новый слой, там указаны команды которые выполняются при запуске контейнера. В нашем Dockerfile выполняются команды запуска fastapi-приложения:

— "uvicorn" - сервер, который запускает fastapi-приложение
— "main:app" - main — это имя файла python, а app — это объект fastapi внутри этого файла.
— "--host", "127.0.0.1" - указывает, что сервер будет слушать на локальном интерфейсе.
— "--port", "8000" - указывает порт, на котором работает приложение.

LinuxCamp | #devops #docker #bymaga

Реально же, SIGKILL не контрится)

LinuxCamp | #memes

docker init: как использовать на Windows

Команда "docker init" создает стартовые файлы, связанные с Docker, для вашего проекта == автоматически генерирует их для запуска приложения под ваш стек. Docker init сейчас доступен только на Docker Desktop на Windows и MacOS, в большинстве ОС на linux данной команды нет:

- .dockerignore
- Dockerfile
- compose.yaml
- README.Docker.md

Устанавливаем Docker Desktop на устройство если не установлен. Если не имели раньше дела с питухоном питоном, также скачиваем его. Как все готово, создаем рабочий каталог:

mkdir my-fastapi-project
cd my-fastapi-project

Создаем и активируем виртуальное окружение чтобы изолировать зависимости проекта и с помощью команды pip freeze автоматически сформировать requirements.txt, не заполняя его вручную:

python3 -m venv venv
source venv/bin/activate

Cкачиваем необходимые для создания API зависимости с помощью пакетного менеджера pip и сохраняем их в requirements.txt:

pip install fastapi uvicorn
pip freeze > requirements.txt

Создадим в каталоге проекта файл "main.py" с простым API:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def root():
    return {"Hello": "Docker Init"}

Теперь наконец можем запустить магию:

docker init

Нас встречает приветственное сообщение, которое просит нас выбрать язык проекта (python), его версию (3.12.7), порт на котором будет слушать приложение (8000). Далее нужно вписать команду для запуска. Он увидел что я работаю с fastapi и предлагает:

uvicorn 'main:app' --host=0.0.0.0 --port=8000

И тут видим, что автоматически были созданы перечисленные в начале файлы! Далее можем абсолютно спокойно поднять контейнер командой:

docker compose up --build

Дожидаемся пока сбилдится наше приложение и проверяем все ли ок. Переходим в браузер и видим заветное:

http://127.0.0.1:8000
{"Hello":"Docker Init"}

LinuxCamp | #devops #docker #bymaga #win

Размонтирование файловой системы: unmount

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

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

Сначала посмотрим полный список доступных дисков:

$ sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL

loop0  4K /snap/bare/5
sda 104G                              
├─sda1  vfat 1G /boot/efi                    
├─sda2  ext4 2G /boot                        
...
sdb          500G                              
├─sdb1 ntfs  500G /media/root-user/C2D8...

USB-диск объемом 500 ГБ маркирован как sdb1. Для его размонтирования следует выполнить команду:

$ sudo umount /dev/sdb1

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

Если диск в настоящий момент занят, то возникнет ошибка. С помощью опции "-l" его получится размонтировать, когда он освободится:

$ sudo umount -l /dev/sdb1

Для принудительного отключения можно использовать флаг "-f". Все выполняемые операции незамедлительно прервутся, и ждать ничего не придется:

$ sudo umount -f /dev/sdb1

Размонтировать все устройства

Опция "-a" отвечает за размонтирование всех файловых систем. Eсть несколько разделов с исключениями: roc, devfs, devpts, sysfs, rpc_pipefs и nfsd. Запускать ее нужно с осторожностью:

$ sudo umount -a

Перед выполнением команды вы можете посмотреть то, какие устройства будут затронуты. Тут пригодятся опции "--fake" и "-v" для вывода подробной информации:

$ sudo umount --fake -v -a

/run/user/1000/doc: successfully unmounted
/snap/firefox/6015: successfully unmounted
...

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

Размонтировать путь

Если вы хотите отключить конкретный путь от корневой FS, то подход будет иной.

В качестве примера возьмем каталог "/run/lock/tmpfs". Команда для размонтирования будет выглядеть следующим образом:

$ sudo umount /run/lock/tmpfs

Рекурсивное размонтирование

Для рекурсивного размонтирования определенной директории, к описанной выше команде следует добавить опцию "-R":

$ sudo umount -R /run/lock/tmpfs

Если же вы хотите получить дополнительную информацию при рекурсивном размонтировании, то воспользуйтесь опцией "-v":

$ sudo umount -R -v /run/lock/tmpfs

LinuxCamp | #utils

Релиз Ubuntu 25.04 Plucky Puffin

По информации OpenNET, основные изменения и доработки включают:

— Рабочий стол обновлён до GNOME 48, в котором реализована поддержка HDR, тройной буферизации, стековой компоновки. Добавлены оптимизации потребления памяти и производительности;

— Вместо Evince для просмотра PDF задействована программа Papers;

— Задействован пакетный менеджер APT 3.0, в котором предложен новый движок разрешения зависимостей Solver3;

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

— Ядро Linux обновлено до 6.14;

— На ноутбуках с GPU NVIDIA по умолчанию включён сервис nvidia‑powerd, обеспечивающий поддержку Dynamic Boost;

— Обеспечена полная поддержка GPU Intel на базе архитектуры Xe2;

LinuxCamp | #news

ArcoLinux прекращает деятельность

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

Завершает работу после 8 лет существования. Эрик Дюбуа (создатель) сообщил, что проект прекратит выпуск ISO, приложений и скриптов с 1 июля 2025 года. Уже скоро социальные сети проекта также будут деактивированы.

Причины:

— Личные причины Эрика Дюбуа: автор не стремится к новым амбициозным планам и хочет замедлить темп жизни.

Он планирует заниматься Linux исключительно для удовольствия, без давления, связанного с управлением крупной инициативой

— Появление мелких ошибок, влияющих на качество работы, из-за потери концентрации и внимания создателя проекта

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

LinuxCamp | #news

Как разбить файл на части?

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

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

Разбить по размеру

Для этого используем опцию "-b", определяющую максимальный размер элемента. За основу возьмем файлик в 721 байт. Его нужно разбить на части по 100 байт. Для удобства зададим префикс имени "file-part_":

$ ls -l
721 Apr 20 13:11 file_orig

$ split -b 100 ./file_orig ./file-part_

Помимо оригинала появятся еще 8 файлов:

$ ls -l
721 Apr 20 13:11 file_orig
100 Apr 20 13:12 file-part_aa
...
21 Apr 20 13:12 file-part_ah

Разбить по количеству строк

Может быть нужно разбить один текстовый документ на несколько, с количеством строк "<= n". В этом вопросе полезной окажется опция "-l". Команда поделит большой log-файл на части по 10 тысяч строк в каждом:

$ split -l 1000 ~/Logs/log ~/Logs/log-part_

Разбить на определённое количество файлов

Еще одна интересная задача, в решении которой поможет опция "-n". Размер будет, по возможности, поделен поровну. Достаточно прописать итоговое количество файлов и запустить команду:

$ split -n 3 ./file_orig ./file-part_

$ ls -l
240 Apr 20 13:31 file-part_aa
240 Apr 20 13:31 file-part_ab
241 Apr 20 13:31 file-part_ac
721 Apr 20 13:11 file_orig

Настройка имени частей файла

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

С помощью опций можно изменить его длину "-a", переключиться на числа "-d" или hex-символы "-x". В последних двух сценариях получится выбрать начальную точку отчета "--numeric-suffixes" для чисел и "--hex-suffixes" для hex-символов.

Возьмем задачу – разделить текстовый файл на 3 части равного размера, чтобы каждый из них имел префикс "file-part_" и числовой суффикс из одного символа, начиная с 1:

$ split -a 1 --numeric-suffixes=1 -n 3 ./file_orig ./file-part_

$ ls -l
240 Apr 20 13:36 file-part_1
240 Apr 20 13:36 file-part_2
241 Apr 20 13:36 file-part_3

Объединение частей файла

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

$ cat ~/Archive/split-archive.part_* > ~/Archives/cat-archive.tar.gz

LinuxCamp | #utils

Как удалять ссылки?

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

Обычно мы как проверяем ссылку - выполняем "ls -l" и смотрим на тип:

$ ls -l
lrwxrwxrwx ... sftp-server -> openssh/sftp-server

Если будем работать через find, руками тип смотреть не придется. Для фильтрации по символьным ссылкам у нас есть опция "-type l":

$ find /usr/lib -type l
/usr/lib/gvfs/gvfsd-afp
/usr/lib/libmultipath.so

Если мы переживаем, что удалим что-то лишнее, можем проверить путь к файлу, на который указывает ссылка. Для этого нужно для вывода команды выполнить "-exec ls -l {} \":

$ find /usr/lib -type l -exec ls -l {} \;
/usr/lib/gvfs/gvfsd-afp -> ../../libexec/gvfsd-afp
/usr/lib/libmultipath.so -> libmultipath.so.0

Напоследок разберемся с поиском и удалением битых ссылок, которые никуда не ведут. Для такой цели подойдет параметр "-xtype l":

$ find ~/broken_links/ -xtype l

LinuxCamp | #microhelp

Как узнать разрядность операционки?

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

Существует две самые популярные: i386 (32 битная) и x86_64 (64 битная). Первая уже устаревшая и поддерживает работу с не больше чем 4ГБ оперативки.

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

Самый простой способ узнать разрядность - воспользоваться утилитой arch:

$ arch
aarch64

Да, это "маковская" история. Aarch64 — это 64-битная архитектура от ARM (иногда её называют arm64).

Есть еще команда uname, которая выводит архитектуру ядра через опцию "-m". Архитектура ядра соответствует системной, поэтому этот метод можно использовать:

$ uname -m
aarch64

Команда file позволяет просматривать информацию о файлах. Для исполняемых отображается их архитектура. Если вы посмотрите архитектуру какого-либо важного системного файла, то узнаете и разрядность системы:

$ file /lib/systemd/systemd
/lib/systemd/systemd: ELF 64-bit LSB pie executable, ARM aarch64, ...

LinuxCamp | #utils