Учимся мониторить kernel
На днях, по рабочим задачам, мне нужно было выявить, какая версия ядра фиксит проблему. Тут, конечно же, пришлось вспомнить, как можно установить ядро, посмотреть его версию, запустить систему с целевым образом.
Ядро Linux - это один из самых важных компонентов операционной системы - буквально ее база и основа всех основ.
Самый распространенный способ посмотреть версию ядра - это команда uname. Она выводит некоторую системную информацию, в том числе, о ядре.
Чтобы исключить всю информацию, кроме нас интересующей, можно использовать флаг '-r':
Но это далеко не единственный способ справиться с задачей. Мы можем посмотреть строку запуска Grub с помощью команды:
Тут в параметре BOOT_IMAGE мы можем видеть полный путь к образу, который был загружен.
В той же файловой системе proc есть файл version, где хранится версия ядра:
Дальше, чтобы получить ту же информацию мы можем посмотреть лог dmesg, в самом начале которого отображается версия ядра:
Ага, а как можно посмотреть общий список образов, которые установлены в системе?
Тут тоже есть несколько способов. Во-первых, можно использовать пакетный менеджер:
Во-вторых, можно посмотреть содержимое папки boot и выловить от туда все образы ядра с именем vmlinuz:
В-третьих, используя тот же boot, а именно файл "/boot/grub/grub.cfg", можно посмотреть на все доступные версии:
Эта команда ищет строки, которые содержат слова menuentry либо submenu и передает их команде cat на вывод, которая, в свою очередь, предварительно прогоняет их через фильтр по разделителю (-f2 -d "'").
Linux++ | IT-Образование
На днях, по рабочим задачам, мне нужно было выявить, какая версия ядра фиксит проблему. Тут, конечно же, пришлось вспомнить, как можно установить ядро, посмотреть его версию, запустить систему с целевым образом.
Ядро Linux - это один из самых важных компонентов операционной системы - буквально ее база и основа всех основ.
Самый распространенный способ посмотреть версию ядра - это команда uname. Она выводит некоторую системную информацию, в том числе, о ядре.
Чтобы исключить всю информацию, кроме нас интересующей, можно использовать флаг '-r':
$ uname -r
6.8.0-41-generic
Но это далеко не единственный способ справиться с задачей. Мы можем посмотреть строку запуска Grub с помощью команды:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.8.0-41-generic
Тут в параметре BOOT_IMAGE мы можем видеть полный путь к образу, который был загружен.
В той же файловой системе proc есть файл version, где хранится версия ядра:
$ cat /proc/version
Linux version 6.8.0-41-generic
Дальше, чтобы получить ту же информацию мы можем посмотреть лог dmesg, в самом начале которого отображается версия ядра:
$ sudo dmesg | grep Linux
Linux version 6.8.0-41-generic
Ага, а как можно посмотреть общий список образов, которые установлены в системе?
Тут тоже есть несколько способов. Во-первых, можно использовать пакетный менеджер:
$ sudo dpkg -l | grep linux-headers | grep ii | awk '{print $3}'
$ sudo rpm -q kernel
Во-вторых, можно посмотреть содержимое папки boot и выловить от туда все образы ядра с именем vmlinuz:
$ ls /boot | grep vmlinuz
vmlinuz
vmlinuz-6.8.0-36-generic
vmlinuz-6.8.0-41-generic
В-третьих, используя тот же boot, а именно файл "/boot/grub/grub.cfg", можно посмотреть на все доступные версии:
$ grep 'menuentry \|submenu ' /boot/grub/grub.cfg | cut -f2 -d "'"
Ubuntu, with Linux 6.8.0-41-generic
Ubuntu, with Linux 6.8.0-41-generic (recovery mode)
Эта команда ищет строки, которые содержат слова menuentry либо submenu и передает их команде cat на вывод, которая, в свою очередь, предварительно прогоняет их через фильтр по разделителю (-f2 -d "'").
Linux++ | IT-Образование
👍40🔥8❤2
Как не поломать sudo?
Настройки sudo по большей части находятся в файле /etc/sudoers. Для внесения изменений в этот файл крайне нежелательно использовать обычный редактор текста.
Дело в том, что некорректный синтаксис файла sudoers запросто может навредить операционной системе и поломать sudo.
И вот проблема, вы поломали sudo, что будем делать дальше, ведь файл /etc/sudoers может редактировать только превелигированный пользователь?)
У меня уже был однажды такой казус, правда, не из-за файла sudoers, но в результате, sudo отвалился. Пришлось чиниться через live образ, вам оно надо?)
Для редактирования файла существует специальная команда – visudo, которая обычно использует текстовый редактор vi и при сохранении изменений всегда проверяет синтаксис на корректность:
Если кто-то уже редактирует файл, вы получите предупреждение с просьбой попробовать позже и, если вы допустили ошибки, файл просто не будет сохранен.
Также, утилита блокирует sudoers для того, чтобы никто не мог одновременно с вами его изменять.
Если вам не нравится дефолтный текстовый редактор, visudo позволяет его изменить. Команда распологает встроенным списком поддерживаемых редакторов.
Для того, чтобы переопределить редактор, достаточно объявить переменную окружения EDITOR:
Для того, чтобы изменения применялись постоянно, вам требуется прописать команду выше в файл .bashrc для пользователя.
Linux++ | IT-Образование
Настройки sudo по большей части находятся в файле /etc/sudoers. Для внесения изменений в этот файл крайне нежелательно использовать обычный редактор текста.
Дело в том, что некорректный синтаксис файла sudoers запросто может навредить операционной системе и поломать sudo.
И вот проблема, вы поломали sudo, что будем делать дальше, ведь файл /etc/sudoers может редактировать только превелигированный пользователь?)
У меня уже был однажды такой казус, правда, не из-за файла sudoers, но в результате, sudo отвалился. Пришлось чиниться через live образ, вам оно надо?)
Для редактирования файла существует специальная команда – visudo, которая обычно использует текстовый редактор vi и при сохранении изменений всегда проверяет синтаксис на корректность:
$ sudo visudo
Если кто-то уже редактирует файл, вы получите предупреждение с просьбой попробовать позже и, если вы допустили ошибки, файл просто не будет сохранен.
Также, утилита блокирует sudoers для того, чтобы никто не мог одновременно с вами его изменять.
Если вам не нравится дефолтный текстовый редактор, visudo позволяет его изменить. Команда распологает встроенным списком поддерживаемых редакторов.
Для того, чтобы переопределить редактор, достаточно объявить переменную окружения EDITOR:
$ export EDITOR=nano
Для того, чтобы изменения применялись постоянно, вам требуется прописать команду выше в файл .bashrc для пользователя.
Linux++ | IT-Образование
👍39🔥9❤2
Пора обновляться на Kernel 6.11?
Серия ядер Linux 6.10 достигла конца срока поддержки, и вам следует рассмотреть возможность обновления до ядра Linux 6.11.
Ядро Linux 6.10 было выпущено 14 июля 2024 года и представило новые функции, среди которых:
1) системный вызов mseal() для защиты памяти;
2) поддержку языка Rust для архитектуры RISC-V;
3) поддержку сжатия Zstandard для файловой системы EROFS;
Ядро Linux 6.10 не является веткой с долгосрочной поддержкой (LTS), поэтому поддерживалось только несколько месяцев и получило четырнадцать обновлений.
Ядро Linux 6.11 было выпущено 15 сентября 2024 года и уже было принято различными популярными дистрибутивами: Ubuntu 24.10, Arch Linux, Fedora Linux и openSUSE Tumbleweed.
Данный релиз также является краткосрочным - будет поддерживаться несколько месяцев.
Если вам нужна долгосрочная поддержка, следует использовать либо Linux 6.6, либо Linux 6.1, обе версии будут поддерживаться до декабря 2026 года и являются LTS.
Вообще, честно говоря, новость новостью, но загоняться на счет версии ядра особо не стоит, если вам не требуются самые передовые фичи либо баг фиксы. Обновление ядра может привести к ряду проблем, если какие-то утилиты несовместимы с нововведениями.
Некоторые дистры на ядро накладывают ряд патчей, чтобы все работало и не ломалось. Лучше всего - дождаться стабильной версии дистрибутива и обновить все его компоненты, включая ядро.
Linux++ | IT-Образование
Серия ядер Linux 6.10 достигла конца срока поддержки, и вам следует рассмотреть возможность обновления до ядра Linux 6.11.
Ядро Linux 6.10 было выпущено 14 июля 2024 года и представило новые функции, среди которых:
1) системный вызов mseal() для защиты памяти;
2) поддержку языка Rust для архитектуры RISC-V;
3) поддержку сжатия Zstandard для файловой системы EROFS;
Ядро Linux 6.10 не является веткой с долгосрочной поддержкой (LTS), поэтому поддерживалось только несколько месяцев и получило четырнадцать обновлений.
Ядро Linux 6.11 было выпущено 15 сентября 2024 года и уже было принято различными популярными дистрибутивами: Ubuntu 24.10, Arch Linux, Fedora Linux и openSUSE Tumbleweed.
Данный релиз также является краткосрочным - будет поддерживаться несколько месяцев.
Если вам нужна долгосрочная поддержка, следует использовать либо Linux 6.6, либо Linux 6.1, обе версии будут поддерживаться до декабря 2026 года и являются LTS.
Вообще, честно говоря, новость новостью, но загоняться на счет версии ядра особо не стоит, если вам не требуются самые передовые фичи либо баг фиксы. Обновление ядра может привести к ряду проблем, если какие-то утилиты несовместимы с нововведениями.
Некоторые дистры на ядро накладывают ряд патчей, чтобы все работало и не ломалось. Лучше всего - дождаться стабильной версии дистрибутива и обновить все его компоненты, включая ядро.
Linux++ | IT-Образование
👍26❤🔥4🔥2
Слышали про chroot?
Chroot (change root) - это утилита, которая используется для того, чтобы создать закрытое окружение "тюрьму", в которой программа будет видеть определенную часть файловой системы, как корневую '/'.
Это похоже на создание миниатюрного "сейфа" или "контейнера" для запуска приложений. В качестве примера можете вспомнить тот же Docker.
Под капотом chroot использует одноименный системный вызов и в некоторых ситуациях может пригодиться, как дополнительный элемент безопасности, который позволит ограничить набор каталогов и файлов, доступных программе.
Системный вызов chroot()
Каждый процесс обладает корневым каталогом — он представляет собой стартовую точку, от которой интерпретируются абсолютные имена путей, начинающиеся с символа '/'. По умолчанию данным каталогом является реальный корневой каталог файловой системы.
Иногда бывает удобно, чтобы процесс изменил свой корневой каталог. Это может реализовать с помощью системного вызова chroot(). Системный вызов chroot() изменяет корневой каталог процесса на каталог, указанный в аргументе pathname:
Затем все абсолютные имена путей интерпретируются, как начинающиеся с указанного местоположения в файловой системе. Иногда это называют заключением в клетку chroot, поскольку программа оказывается замкнутой внутри некоторой части файловой системы.
Моменты, которые стоит учитывать при работе с chroot
Следует 100% помнить, что вызов chroot() не меняет текущий рабочий каталог процесса. Для обеспечения полной безопасности, либо перед, либо после chroot() необходимо выполнить вызов chdir(), иначе процесс сможет использовать относительные пути для доступа к ресурсам вне клетки.
Также, при переходе в пространство chroot, вы можете столкнуться с тем, что ничего не работает) Это и не удивительно, как оболочка будет выполнять команды, которых для нее просто не существует...
Для решения проблемы вам может понадобиться перенести ряд библиотек и программ из "реальной" корневой системы в имитированную либо использовать команду debootstrap, но это уже отдельная история)
Linux++ | IT-Образование
Chroot (change root) - это утилита, которая используется для того, чтобы создать закрытое окружение "тюрьму", в которой программа будет видеть определенную часть файловой системы, как корневую '/'.
Это похоже на создание миниатюрного "сейфа" или "контейнера" для запуска приложений. В качестве примера можете вспомнить тот же Docker.
Под капотом chroot использует одноименный системный вызов и в некоторых ситуациях может пригодиться, как дополнительный элемент безопасности, который позволит ограничить набор каталогов и файлов, доступных программе.
Системный вызов chroot()
Каждый процесс обладает корневым каталогом — он представляет собой стартовую точку, от которой интерпретируются абсолютные имена путей, начинающиеся с символа '/'. По умолчанию данным каталогом является реальный корневой каталог файловой системы.
Иногда бывает удобно, чтобы процесс изменил свой корневой каталог. Это может реализовать с помощью системного вызова chroot(). Системный вызов chroot() изменяет корневой каталог процесса на каталог, указанный в аргументе pathname:
#include <unistd.h>
int chroot(const char *pathname);
Затем все абсолютные имена путей интерпретируются, как начинающиеся с указанного местоположения в файловой системе. Иногда это называют заключением в клетку chroot, поскольку программа оказывается замкнутой внутри некоторой части файловой системы.
Моменты, которые стоит учитывать при работе с chroot
Следует 100% помнить, что вызов chroot() не меняет текущий рабочий каталог процесса. Для обеспечения полной безопасности, либо перед, либо после chroot() необходимо выполнить вызов chdir(), иначе процесс сможет использовать относительные пути для доступа к ресурсам вне клетки.
Также, при переходе в пространство chroot, вы можете столкнуться с тем, что ничего не работает) Это и не удивительно, как оболочка будет выполнять команды, которых для нее просто не существует...
Для решения проблемы вам может понадобиться перенести ряд библиотек и программ из "реальной" корневой системы в имитированную либо использовать команду debootstrap, но это уже отдельная история)
Linux++ | IT-Образование
👍32🔥7❤3⚡1🤯1
Микротуториал по управлению пакетами (Debian-based)
В Linux и разработчики и обычные пользователи довольно часто работают с бинарными пакетами: обновляют их, удаляют, переустанавливают, смотрят описание, мониторят содержимое.
Сегодня мы рассмотрим пулл команд по работе с пакетами, которые, на практике, чаще всего используются в "Debian-based" системах.
Если интересно подробнее изучить, что такое бинарный пакет, пакетный менеджер и для чего все это нужно, отсылаю вас на мой ранний пост.
Основные команды apt
1. Обновляет локальный кэш с информацией о доступных пакетах и их версиях из репозиториев, прописанных в "/etc/apt/sources.list":
2. Обновляет все установленные пакеты до актуальных версий, НО существующие пакеты не удаляет.
Если для обновления требуется удаление/установка зависимостей, оно пропускается, и пакет остается нетронутым в текущей версии:
3. Обновляет все установленные пакеты до актуальных версий, устанавливает или удаляет пакеты для разрешения зависимостей:
4. Устанавливает пакет вместе со всеми его зависимостями:
5. Переустанавливает пакет и обновляет все его содержимое. Бывает полезно, если какие-то файлы пакета были удалены или повреждены:
6. Удаляет указанный пакет, но оставляет файлы конфигурации:
7. Полностью удаляет пакет и его конфигурационные файлы:
8. Показывает информацию о пакете: версия, зависимости, описание, размер и т.д.:
9. Ищет пакеты в репозиториях по имени или описанию:
10. Удаляет пакеты, которые были установлены как зависимости, но больше не требуются:
11. Удаляет все загруженные архивы пакетов из кэша "/var/cache/apt/archives/":
Основные команды dpkg
1. Устанавливает пакет из локального файла .deb и не подтягивает зависимости:
2. Удаляет пакет, но сохраняет конфигурационные файлы:
3. Полностью удаляет пакет и его конфигурационные файлы:
4. Показывает список всех установленных пакетов либо информацию о конкретном пакете:
5. Выводит подробную информацию о пакете/пакетах:
6. Показывает список файлов, установленных данным пакетом:
7. Показывает содержимое архива .deb (файлы, которые будут установлены):
8. Доводит конфигурацию пакета/пакетов до конца при аварийном завершении:
9. Показывает имя пакета, который устанавливает указанный файл:
Linux++ | IT-Образование
В Linux и разработчики и обычные пользователи довольно часто работают с бинарными пакетами: обновляют их, удаляют, переустанавливают, смотрят описание, мониторят содержимое.
Сегодня мы рассмотрим пулл команд по работе с пакетами, которые, на практике, чаще всего используются в "Debian-based" системах.
Если интересно подробнее изучить, что такое бинарный пакет, пакетный менеджер и для чего все это нужно, отсылаю вас на мой ранний пост.
Основные команды apt
1. Обновляет локальный кэш с информацией о доступных пакетах и их версиях из репозиториев, прописанных в "/etc/apt/sources.list":
$ sudo apt update
2. Обновляет все установленные пакеты до актуальных версий, НО существующие пакеты не удаляет.
Если для обновления требуется удаление/установка зависимостей, оно пропускается, и пакет остается нетронутым в текущей версии:
$ sudo apt upgrade
3. Обновляет все установленные пакеты до актуальных версий, устанавливает или удаляет пакеты для разрешения зависимостей:
$ sudo apt dist-upgrade
4. Устанавливает пакет вместе со всеми его зависимостями:
$ sudo apt install <имя_пакета>
5. Переустанавливает пакет и обновляет все его содержимое. Бывает полезно, если какие-то файлы пакета были удалены или повреждены:
$ sudo apt install --reinstall <имя_пакета>
6. Удаляет указанный пакет, но оставляет файлы конфигурации:
$ sudo apt remove <имя_пакета>
7. Полностью удаляет пакет и его конфигурационные файлы:
$ sudo apt purge <имя_пакета>
8. Показывает информацию о пакете: версия, зависимости, описание, размер и т.д.:
$ sudo apt show <имя_пакета>
9. Ищет пакеты в репозиториях по имени или описанию:
$ sudo apt search <имя_пакета>
10. Удаляет пакеты, которые были установлены как зависимости, но больше не требуются:
$ sudo apt autoremove
11. Удаляет все загруженные архивы пакетов из кэша "/var/cache/apt/archives/":
$ sudo apt clean
Основные команды dpkg
1. Устанавливает пакет из локального файла .deb и не подтягивает зависимости:
$ sudo dpkg -i <имя_пакета.deb>
2. Удаляет пакет, но сохраняет конфигурационные файлы:
$ sudo dpkg -r <имя_пакета>
3. Полностью удаляет пакет и его конфигурационные файлы:
$ sudo dpkg -P <имя_пакета>
4. Показывает список всех установленных пакетов либо информацию о конкретном пакете:
$ dpkg -l
$ dpkg -l <имя_пакета>
5. Выводит подробную информацию о пакете/пакетах:
$ dpkg -s
$ dpkg -s <имя_пакета>
6. Показывает список файлов, установленных данным пакетом:
$ dpkg -L <имя_пакета>
7. Показывает содержимое архива .deb (файлы, которые будут установлены):
$ dpkg -c <имя_пакета.deb>
8. Доводит конфигурацию пакета/пакетов до конца при аварийном завершении:
$ sudo dpkg --configure -a
$ sudo dpkg --configure <имя_пакета>
9. Показывает имя пакета, который устанавливает указанный файл:
$ dpkg -S picom.desktop
picom: /etc/xdg/autostart/picom.desktop
Linux++ | IT-Образование
6👍59🔥12❤3🤯2🤬1
Переводим .rpm пакет в .deb (alien)
Представим такую ситуацию - ваш друг очень хочет дать вам потестить свое революционное приложение...
Да, все круто, вы только за то, чтобы дать конструктивный фитбек и потыкаться в утилите, но есть проблема - приятель сидит на какой-нибудь федоре и понятия не имеет, как дебианизировать пакет.
Без паники, есть решение - утилита alien, которая способна перегнать "инородную" для вашего пакетного менеджера бинарную сборку из одного формата в другой.
Поддерживается преобразование между пакетами: Linux Standard Base (.lsb), Redhat (.rpm), Debian (.deb), Stampede (.slp), Solaris (.pkg) и Slackware (.tgz).
Для преобразования .deb файла в .rpm с изменением стандартных для Debian инсталляционных скриптов используется опция -r. На выходе получится RPM-пакет:
Для преобразования .rpm файла в .deb используется опция -d. На выходе получится DEB-пакет:
За дополнительной информацией об утилите направляю вас прямо в мануал.
Linux++ | IT-Образование
Представим такую ситуацию - ваш друг очень хочет дать вам потестить свое революционное приложение...
Да, все круто, вы только за то, чтобы дать конструктивный фитбек и потыкаться в утилите, но есть проблема - приятель сидит на какой-нибудь федоре и понятия не имеет, как дебианизировать пакет.
Без паники, есть решение - утилита alien, которая способна перегнать "инородную" для вашего пакетного менеджера бинарную сборку из одного формата в другой.
Поддерживается преобразование между пакетами: Linux Standard Base (.lsb), Redhat (.rpm), Debian (.deb), Stampede (.slp), Solaris (.pkg) и Slackware (.tgz).
$ sudo apt install alien
Для преобразования .deb файла в .rpm с изменением стандартных для Debian инсталляционных скриптов используется опция -r. На выходе получится RPM-пакет:
$ sudo alien -r --noscripts <some_pkg>.deb
<some_pkg>.rpm generated
Для преобразования .rpm файла в .deb используется опция -d. На выходе получится DEB-пакет:
$ sudo alien -d --noscripts <some_pkg>.rpm
<some_pkg>.deb generated
За дополнительной информацией об утилите направляю вас прямо в мануал.
Linux++ | IT-Образование
🔥43👍16🐳3❤2👏2🤷♂1
Как демоны выполняют логгирование?
При написании демона одной из проблем является вывод сообщений об ошибках. Поскольку его выполнение происходит в фоновом режиме, он не может просто выводить информацию в терминал, как это делают другие программы (для того, чтобы освежить в памяти понимание демонов, отсылаю вас на ранний пост).
Так вот, в качестве альтернативы сообщения можно записывать в отдельный журнальный файл программы. Основной недостаток такого подхода заключается в сложности менеджмента этих файлов. Для решения проблемы была разработана система syslog.
Что такое syslog?
Система syslog предоставляет единый централизованный механизм, который позволяет любому приложению записывать свои сообщения в единый журнал. Система syslog состоит из двух основных компонентов: демона syslogd и библиотечной функции syslog().
Демон syslogd, принимает сообщения из двух разных источников: сокета UNIX-домена (/dev/log), который хранит сообщения, сгенерированные локально, и сокета интернет-домена, который хранит сообщения, отправленные по TCP/IP.
Для записи сообщений в журнал любой процесс может воспользоваться библиотечной функцией syslog(). На основе переданных ей аргументов она создает сообщение и помещает его в сокет "/dev/log", где оно будет доступно для syslogd.
Файл /etc/syslog.conf
Конфигурационный файл "/etc/syslog.conf" определяет поведение демона syslogd и то, как и куда должны записываться системные сообщения. Он состоит из набора правил, которые имеют следующий вид:
Программный интерфейс syslog
Программный интерфейс syslog состоит из трех основных функций, которые входят в пространство "syslog.h":
1. Функция openlog() устанавливает настройки, которые по умолчанию применяются ко всем последующим вызовам syslog():
2. Функция syslog() записывает сообщения в журнал:
3. Функция closelog() вызывается после окончания записи сообщений, чтобы разорвать соединение с журналом:
Если не прорабатывать конфиги и не указывать альтернативные пути вывода сообщений для различных источников, то последовательное выполнение функций выше приведет к появлению лога в файле "/var/log/syslog":
Linux++ | IT-Образование
При написании демона одной из проблем является вывод сообщений об ошибках. Поскольку его выполнение происходит в фоновом режиме, он не может просто выводить информацию в терминал, как это делают другие программы (для того, чтобы освежить в памяти понимание демонов, отсылаю вас на ранний пост).
Так вот, в качестве альтернативы сообщения можно записывать в отдельный журнальный файл программы. Основной недостаток такого подхода заключается в сложности менеджмента этих файлов. Для решения проблемы была разработана система syslog.
Что такое syslog?
Система syslog предоставляет единый централизованный механизм, который позволяет любому приложению записывать свои сообщения в единый журнал. Система syslog состоит из двух основных компонентов: демона syslogd и библиотечной функции syslog().
Демон syslogd, принимает сообщения из двух разных источников: сокета UNIX-домена (/dev/log), который хранит сообщения, сгенерированные локально, и сокета интернет-домена, который хранит сообщения, отправленные по TCP/IP.
Для записи сообщений в журнал любой процесс может воспользоваться библиотечной функцией syslog(). На основе переданных ей аргументов она создает сообщение и помещает его в сокет "/dev/log", где оно будет доступно для syslogd.
Файл /etc/syslog.conf
Конфигурационный файл "/etc/syslog.conf" определяет поведение демона syslogd и то, как и куда должны записываться системные сообщения. Он состоит из набора правил, которые имеют следующий вид:
источник.приоритет действие
# Записывать все сообщения от ядра в файл kern.log
kern.* /var/log/kern.log
Программный интерфейс syslog
Программный интерфейс syslog состоит из трех основных функций, которые входят в пространство "syslog.h":
1. Функция openlog() устанавливает настройки, которые по умолчанию применяются ко всем последующим вызовам syslog():
void openlog(const char *ident, int log_options, int facility);
openlog("slog", LOG_PID|LOG_CONS, LOG_DAEMON);
2. Функция syslog() записывает сообщения в журнал:
void syslog(int priority, const char *format, ...);
syslog(LOG_INFO, "Hello world ... ");
3. Функция closelog() вызывается после окончания записи сообщений, чтобы разорвать соединение с журналом:
void closelog(void);
Если не прорабатывать конфиги и не указывать альтернативные пути вывода сообщений для различных источников, то последовательное выполнение функций выше приведет к появлению лога в файле "/var/log/syslog":
xodefenderpc slog[754521]: Hello world ...
Linux++ | IT-Образование
👍26🔥8❤5🤔3👎1😈1
Базовые принципы коммуникации "пользователь -> приложение"
Всех приветствую на том конце провода. Сегодня коротенько рассмотрим базовые способы того, как пользователю можно повлиять на поведение программы, если она это допускает и предусматривает.
Обозреваемые концепты относятся к исполняемым файлам в целом, поэтому затрагивают и динамические библиотеки.
Некоторые из нас в курсе про какие-нибудь механизмы IPC (Inter Process Communications), как например: DBUS. IPC подразумевает коммуникацию между приложениями. Выглядеть она может следующим образом "пользователь -> приложение_1 -> приложение_2".
Причем пользователь в этой схеме не является ключевой сущностью - он может как-то повлиять на "приложение_1" и затригерить его обратиться к "приложение_2".
Коммуникация "пользователь -> приложение" обычно реализована 3 способами: конфиги, переменные окружения, аргументы командной строки:
Общение через файлы конфигурации
Приложение может давать пользователю влиять на внутреннюю кухню через конфиги. Тут, чтобы понять, есть ли такая возможность, можно либо почитать описание утилиты, которое она обычно предоставляет, либо посмотреть на список установленных файлов:
Для удобства, в последнем случае можно "грепнуть" вывод, т.к. обычно конфиги заканчиваются ".cnf" и ".conf":
Также стоит упомянуть тот факт, что конфиги бывают пользовательскими и системными. Пользовательские, как правило, имеют больший приоритет и расположены в скрытой директории внутри хомяка "~/.config". Системные, в свою очередь, где-то внутри "/etc/":
Общение через переменные окружения
Приложение может поддерживать коннект с пользователем и обрабатывать запросы в том числе и через переменные. Если мы посмотрим на мануал к проекту mesa, сколько же там всего можно проконтролировать, оставляю ссылочку. Аналогичная история и с такими проектами, как gtk, kwin и т.д.
Если приложение допускает кастомизацию одних и тех же параметров и через файлы и через проставление переменных окружения, то переменные, как правило, имеют больший приоритет.
Общение через переменные происходит обычно по 3 сценариям:
1) мы определяем переменную для конкретного пользователя, например через файл "~/.bashrc". В таком случае, каждый раз, как пользователь открывает сессию, переменная становится видимой для приложений внутри:
2) мы определяем общесистемную переменную "/etc/environment", которая доступна приложениям любой сессии и всем пользователям:
3) мы передаем переменную программе на старте. В результате, только целевая программа и ее потомки будут видеть переменную и смогут с ней работать:
Общение через аргументы командной строки
Еще одна полезная опция - передавать программе определенный пулл параметром через CLI (Command line interface) в момент запуска. Такой формат очень распространен в "no-GUI" утилитах, работа с которыми происходит исключительно в командной строке: nmcli, pkcs11-tool, ssh и т.д.:
Список параметров программа, как правило, выдает через флаг "--help":
Linux++ | IT-Образование
Всех приветствую на том конце провода. Сегодня коротенько рассмотрим базовые способы того, как пользователю можно повлиять на поведение программы, если она это допускает и предусматривает.
Обозреваемые концепты относятся к исполняемым файлам в целом, поэтому затрагивают и динамические библиотеки.
Некоторые из нас в курсе про какие-нибудь механизмы IPC (Inter Process Communications), как например: DBUS. IPC подразумевает коммуникацию между приложениями. Выглядеть она может следующим образом "пользователь -> приложение_1 -> приложение_2".
Причем пользователь в этой схеме не является ключевой сущностью - он может как-то повлиять на "приложение_1" и затригерить его обратиться к "приложение_2".
Коммуникация "пользователь -> приложение" обычно реализована 3 способами: конфиги, переменные окружения, аргументы командной строки:
Общение через файлы конфигурации
Приложение может давать пользователю влиять на внутреннюю кухню через конфиги. Тут, чтобы понять, есть ли такая возможность, можно либо почитать описание утилиты, которое она обычно предоставляет, либо посмотреть на список установленных файлов:
# читаем мануал к программе
$ man picom
# смотрим на список установленных файлов
$ dpkg -L picom
Для удобства, в последнем случае можно "грепнуть" вывод, т.к. обычно конфиги заканчиваются ".cnf" и ".conf":
$ dpkg -L picom | grep -e .conf -e .cnf
/usr/share/doc/picom/examples/picom.sample.conf
Также стоит упомянуть тот факт, что конфиги бывают пользовательскими и системными. Пользовательские, как правило, имеют больший приоритет и расположены в скрытой директории внутри хомяка "~/.config". Системные, в свою очередь, где-то внутри "/etc/":
$ dpkg -L openssl | grep -e .conf -e .cnf
/etc/ssl/openssl.cnf
Общение через переменные окружения
Приложение может поддерживать коннект с пользователем и обрабатывать запросы в том числе и через переменные. Если мы посмотрим на мануал к проекту mesa, сколько же там всего можно проконтролировать, оставляю ссылочку. Аналогичная история и с такими проектами, как gtk, kwin и т.д.
Если приложение допускает кастомизацию одних и тех же параметров и через файлы и через проставление переменных окружения, то переменные, как правило, имеют больший приоритет.
Общение через переменные происходит обычно по 3 сценариям:
1) мы определяем переменную для конкретного пользователя, например через файл "~/.bashrc". В таком случае, каждый раз, как пользователь открывает сессию, переменная становится видимой для приложений внутри:
$ cat ~/.bashrc
export SOME_VARIABLE="some value"
2) мы определяем общесистемную переменную "/etc/environment", которая доступна приложениям любой сессии и всем пользователям:
$ cat /etc/environment
SOME_VARIABLE="some value"
3) мы передаем переменную программе на старте. В результате, только целевая программа и ее потомки будут видеть переменную и смогут с ней работать:
$ SOME_VARIABLE="some value" picom
Общение через аргументы командной строки
Еще одна полезная опция - передавать программе определенный пулл параметром через CLI (Command line interface) в момент запуска. Такой формат очень распространен в "no-GUI" утилитах, работа с которыми происходит исключительно в командной строке: nmcli, pkcs11-tool, ssh и т.д.:
$ pkcs11-tool --module /usr/lib/librtpkcs11ecp.so -T
Список параметров программа, как правило, выдает через флаг "--help":
$ nmcli --help
nmcli [ПАРАМЕТРЫ] ОБЪЕКТ { КОМАНДА | help }
ПАРАМЕТРЫ
-a, --ask запрос отсутствующих параметров
Linux++ | IT-Образование
👍31🔥10❤🔥3
Топ команд по управлению процессами
Как-то раньше мы с вами говорили про процессы и разбирали их различия с программами. Сегодня посмотрим на основные команды, которые КАЖДЫЙ линуксоид должен знать и уметь применять в работе.
Команда для просмотра процессов "ps":
Команда ps используется для отображения информации о запущенных процессах. Она выводит большинство необходимых данных, которые требуются для администрирования.
Если выполнить ps без каких-либо флагов, то получится просмотреть только процессы, запущенные текущим терминалом:
C этой командой вам нужно быть довольно точным в требованиях. Если вы хотите посмотреть на полный список процессов, запущенных целевым пользователем, вам нужно попросить именно об этом:
Если мы посмотрим на вывод с флагом "--help", то поймем, что команда на столько обширная, что и для "--help" есть ряд параметров:
Возможных флагов и комбинаций, на самом деле, уйма. На практике, чаще всего, используется именно следующая запись "ps -aux", где:
'a' говорит о выводе процессов всех пользователей;
'u' требует отобразить пользователя, которому принадлежит процесс;
'x' просит вывести процессы, которые не привязаны к управляющему терминалу (TTY) - демоны и другие фоновые процессы.
Команды для убийства процессов "kill/pkill":
Бывает же такое, программа просто перестает отвечать на запросы. Да, знаю, частенько бывает. В таком случае может быть полезно, во что бы то ни стало, уничтожить подвисший процесс. Сделать это можно с помощью команд "kill" и "pkill".
Команда "kill" требует указать id процесса, который необходимо терминировать:
Работает это через отправку сигнала целевому процессу. Без явного указания, команда пытается "убить" процесс с помощью сигнала "SIGTERM", которые не гарантирует полное и сиюсекундное терминирование.
Для того, чтобы по-настоящему "убить" процесс, требуется отправить сигнал "SIGKILL", который находится под 9 номером:
Список всех сигналов можно получить через флаг '-l':
Утилита "pkill" позволяет оперировать именами, а не идентификаторами и отправляет сигнал она всем процессам с указанным именем:
Команда для получения id процесса "pgrep":
pgrep позволяет находить идентификаторы (PID) запущенных процессов на основе заданных критериев: имя процесса, его владелец и т.д. Для того, чтобы получить (PID) процесса по его имени, следует выполнить:
Команды для оценки потребления ресурсов системы "top/htop":
Их использование полезно для анализа процессов и определения того, сколько CPU тратится на их выполнение, какое потребление оперативной памяти и т.д. htop является более продвинутой версией, но, в своей основе, они используются для идентичных целей:
Linux++ | IT-Образование
Как-то раньше мы с вами говорили про процессы и разбирали их различия с программами. Сегодня посмотрим на основные команды, которые КАЖДЫЙ линуксоид должен знать и уметь применять в работе.
Команда для просмотра процессов "ps":
Команда ps используется для отображения информации о запущенных процессах. Она выводит большинство необходимых данных, которые требуются для администрирования.
Если выполнить ps без каких-либо флагов, то получится просмотреть только процессы, запущенные текущим терминалом:
$ ps
PID TTY TIME CMD
107468 pts/1 00:00:00 bash
107747 pts/1 00:00:00 ps
C этой командой вам нужно быть довольно точным в требованиях. Если вы хотите посмотреть на полный список процессов, запущенных целевым пользователем, вам нужно попросить именно об этом:
$ ps -u xodefender | grep picom
109331 ? 00:00:00 picom
Если мы посмотрим на вывод с флагом "--help", то поймем, что команда на столько обширная, что и для "--help" есть ряд параметров:
$ ps --help
Usage:
ps [options]
Try 'ps --help <simple|list|output|threads|misc|all>'
Возможных флагов и комбинаций, на самом деле, уйма. На практике, чаще всего, используется именно следующая запись "ps -aux", где:
'a' говорит о выводе процессов всех пользователей;
'u' требует отобразить пользователя, которому принадлежит процесс;
'x' просит вывести процессы, которые не привязаны к управляющему терминалу (TTY) - демоны и другие фоновые процессы.
$ ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.3 23128 13352 ? Ss 08:57 0:07 /sbin/init
Команды для убийства процессов "kill/pkill":
Бывает же такое, программа просто перестает отвечать на запросы. Да, знаю, частенько бывает. В таком случае может быть полезно, во что бы то ни стало, уничтожить подвисший процесс. Сделать это можно с помощью команд "kill" и "pkill".
Команда "kill" требует указать id процесса, который необходимо терминировать:
$ kill 109331
Работает это через отправку сигнала целевому процессу. Без явного указания, команда пытается "убить" процесс с помощью сигнала "SIGTERM", которые не гарантирует полное и сиюсекундное терминирование.
Для того, чтобы по-настоящему "убить" процесс, требуется отправить сигнал "SIGKILL", который находится под 9 номером:
$ kill -9 109331
Список всех сигналов можно получить через флаг '-l':
$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP ...
Утилита "pkill" позволяет оперировать именами, а не идентификаторами и отправляет сигнал она всем процессам с указанным именем:
$ pkill -9 picom
Команда для получения id процесса "pgrep":
pgrep позволяет находить идентификаторы (PID) запущенных процессов на основе заданных критериев: имя процесса, его владелец и т.д. Для того, чтобы получить (PID) процесса по его имени, следует выполнить:
$ pgrep picom
109331
Команды для оценки потребления ресурсов системы "top/htop":
Их использование полезно для анализа процессов и определения того, сколько CPU тратится на их выполнение, какое потребление оперативной памяти и т.д. htop является более продвинутой версией, но, в своей основе, они используются для идентичных целей:
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 106676 xodefen+ 20 0 495180 92356 63828 S 1.0 2.3 0:34.08 Xorg
Linux++ | IT-Образование
👍42🔥11❤3👌2
Мониторинг ресурсов системы: Mission Center
Mission Center — полезная GUI программа для мониторинга использования CPU, RAM, GPU, дисков, сети, процессов.
Является более стильным аналогом приложения «Системный монитор» в GNOME. Интерфейс программы - диспетчер задач Windows, реализованный на GTK4.
Mission Center может быть отличным выбором для новичков, которым первое время может быть трудно ориентироваться в терминале и использовать утилиты top и htop.
Я как-то сам искал что-то графическое для вывода базовой информации. Из всех найденных вариантов, этот показался наиболее удобным и исчерпывающим.
Возможности:
1. Мониторинг использования CPU: общая статистика, статистика по каждому ядру и процессу.
2. Просмотр процессов и потоков.
3. Мониторинг использования RAM и Swap.
4. Мониторинг использования дисков, расчет скорости записи и чтения.
5. Оценка использования сети.
6. Мониторинг использования GPU: потребление памяти, питания и т.д.
7. Просмотр информации о сетевых интерфейсах: имя сетевой карты, тип соединения, ip адрес и т.д.
Установка:
1. Если дистрибутив поддерживает Flatpak, то ставится и запускается все максимально просто:
Установка Flatpak
Установка Mission Center
2. Во втором случае путь один - ручная сборка через исходники. Подробная инструкция по установке содержится в GitLab репозитории проекта: ИСХОДНИКИ.
Сайт проекта: Mission Center.
Linux++ | IT-Образование
Mission Center — полезная GUI программа для мониторинга использования CPU, RAM, GPU, дисков, сети, процессов.
Является более стильным аналогом приложения «Системный монитор» в GNOME. Интерфейс программы - диспетчер задач Windows, реализованный на GTK4.
Mission Center может быть отличным выбором для новичков, которым первое время может быть трудно ориентироваться в терминале и использовать утилиты top и htop.
Я как-то сам искал что-то графическое для вывода базовой информации. Из всех найденных вариантов, этот показался наиболее удобным и исчерпывающим.
Возможности:
1. Мониторинг использования CPU: общая статистика, статистика по каждому ядру и процессу.
2. Просмотр процессов и потоков.
3. Мониторинг использования RAM и Swap.
4. Мониторинг использования дисков, расчет скорости записи и чтения.
5. Оценка использования сети.
6. Мониторинг использования GPU: потребление памяти, питания и т.д.
7. Просмотр информации о сетевых интерфейсах: имя сетевой карты, тип соединения, ip адрес и т.д.
Установка:
1. Если дистрибутив поддерживает Flatpak, то ставится и запускается все максимально просто:
Установка Flatpak
$ sudo apt install flatpak
$ flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
Установка Mission Center
$ flatpak install flathub io.missioncenter.MissionCenter
$ flatpak run io.missioncenter.MissionCenter
2. Во втором случае путь один - ручная сборка через исходники. Подробная инструкция по установке содержится в GitLab репозитории проекта: ИСХОДНИКИ.
Сайт проекта: Mission Center.
Linux++ | IT-Образование
🔥25👍12❤3👎2
Учимся работать с историей bash
Чем больше работаешь в командной строке, тем чаще возникает необходимость повторять введенные ранее команды.
Самый простой, но иногда неоптимальный способ — нажимать клавиши «вверх» и «вниз». При каждом нажатии стрелки «вверх» в поле ввода начнет появляться предыдущая выполненная команда, если нажать «вниз» — следующая.
История команд bash хранится в специальном файле .bash_history, который лежит в домашней директории пользователя. Каждый раз, когда пользователь вводит команду, она попадает именно в этот файл. Запись происходит при завершении сеанса.
За то, какое количество команд хранится в истории, отвечает переменная окружения HISTFILESIZE. Если она выставлена, то берется указанное в ней число, иначе история не обрезается и файл .bash_history растет бесконечно:
Посмотреть историю можно и более простым способом - выполнить команду history. Эта команда выведет содержимое .bash_history, добавив слева номер:
Если набрать "history 5", то отобразятся только пять последних введенных команд:
При необходимости историю всегда можно погрепать:
Еще один способ - использовать комбинацию Ctrl+R прямо в оболочке. После нажатия клавиш начинается поиск:
Настройка истории Linux
По умолчанию, команда history дополняет .bash_history только порядковым номером, но вы можете выводить еще и дату выполнения команды. Для этого нужно экспортировать переменную HISTORYFORMAT вместе нужным форматом:
Также можно отключить вывод одинаковых команд:
Вы можете указать какие команды не стоит отображать, например, не будем выводить ls -l, pwd и date:
Linux++ | IT-Образование
Чем больше работаешь в командной строке, тем чаще возникает необходимость повторять введенные ранее команды.
Самый простой, но иногда неоптимальный способ — нажимать клавиши «вверх» и «вниз». При каждом нажатии стрелки «вверх» в поле ввода начнет появляться предыдущая выполненная команда, если нажать «вниз» — следующая.
История команд bash хранится в специальном файле .bash_history, который лежит в домашней директории пользователя. Каждый раз, когда пользователь вводит команду, она попадает именно в этот файл. Запись происходит при завершении сеанса.
За то, какое количество команд хранится в истории, отвечает переменная окружения HISTFILESIZE. Если она выставлена, то берется указанное в ней число, иначе история не обрезается и файл .bash_history растет бесконечно:
$ cat ~/.bash_history
history | grep qdbu
qdbus org.kde.KWin /Compositor suspend
Посмотреть историю можно и более простым способом - выполнить команду history. Эта команда выведет содержимое .bash_history, добавив слева номер:
$ history
6 exit
7 docker ps
Если набрать "history 5", то отобразятся только пять последних введенных команд:
$ history 5
1498 sudo reboot
1499 cat ~/.bash_history
...
При необходимости историю всегда можно погрепать:
$ history | grep export
174 export HOME=/tmp
183 history | grep export
Еще один способ - использовать комбинацию Ctrl+R прямо в оболочке. После нажатия клавиш начинается поиск:
$ (reverse-i-search)`qdb': qdbus org.kde.KWin /Compositor suspend
Настройка истории Linux
По умолчанию, команда history дополняет .bash_history только порядковым номером, но вы можете выводить еще и дату выполнения команды. Для этого нужно экспортировать переменную HISTORYFORMAT вместе нужным форматом:
$ export HISTTIMEFORMAT='%F %T '
$ history
1503 2024-10-28 11:17:56 cat ~/.history
Также можно отключить вывод одинаковых команд:
$ export HISTCONTROL=ignoredups
Вы можете указать какие команды не стоит отображать, например, не будем выводить ls -l, pwd и date:
$ export HISTIGNORE='ls -l:pwd:date:'
Linux++ | IT-Образование
👍49🔥24❤3👎1
Во, отличная шпаргалка, которая будет полезным дополнением к 2 предыдущим постам:
1) разница между chmod и chown;
2) файл групп /etc/group;
Много раз слышал от знакомых "Ой, вот помню, что 777 дает всем права на все, дальше хз...".
Та я и сам, когда лень вспоминать степени 2 и что-то там считать, обычно проставляю права через "буковки". Теперь, может, и другие комбинации в голове отложатся)
LinuxCamp
1) разница между chmod и chown;
2) файл групп /etc/group;
Много раз слышал от знакомых "Ой, вот помню, что 777 дает всем права на все, дальше хз...".
Та я и сам, когда лень вспоминать степени 2 и что-то там считать, обычно проставляю права через "буковки". Теперь, может, и другие комбинации в голове отложатся)
LinuxCamp
👍43🔥17🤯2
Старость - не радость!
Сейчас с дистрибутивами такая история, что несколько версий ядра может быть доступно пользователю на этапе установки системы.
Причем, рекомендованым к установке - тем, что средней опытности юзер, вероятнее всего, поставит, необязательно будет самое передовое.
Тут, конечно, на помощь приходят ядерщики, которые патчат ядра и активно следят за тем, чтобы все они работали корректно на разных системах в разных условиях.
Но за всем не уследишь. На днях, что вы думаете, нашел очередную проблему в модуле ядра - драйвере i915... По итогу, уже 2 очень неприятных графических бага решаются просто поднятием версии до плюс-минус актуальной.
Больше шансов столкнуться с проблемами у тех пользователей, которые сидят на старых ядрах и новом железе. Какие-то шестеренки linux kernel могут очень тяжело прокручиваться на вашем 144Гц мониторе или, к примеру, intel I9 последнего поколения.
В результате хочется отметить, что иногда простое обновление ядра до актуальной версии может быть быстрым и эффективным решением многих багов.
Linux++ | IT-Образование
Сейчас с дистрибутивами такая история, что несколько версий ядра может быть доступно пользователю на этапе установки системы.
Причем, рекомендованым к установке - тем, что средней опытности юзер, вероятнее всего, поставит, необязательно будет самое передовое.
Тут, конечно, на помощь приходят ядерщики, которые патчат ядра и активно следят за тем, чтобы все они работали корректно на разных системах в разных условиях.
Но за всем не уследишь. На днях, что вы думаете, нашел очередную проблему в модуле ядра - драйвере i915... По итогу, уже 2 очень неприятных графических бага решаются просто поднятием версии до плюс-минус актуальной.
Больше шансов столкнуться с проблемами у тех пользователей, которые сидят на старых ядрах и новом железе. Какие-то шестеренки linux kernel могут очень тяжело прокручиваться на вашем 144Гц мониторе или, к примеру, intel I9 последнего поколения.
В результате хочется отметить, что иногда простое обновление ядра до актуальной версии может быть быстрым и эффективным решением многих багов.
Linux++ | IT-Образование
🔥27👍9❤🔥5👎1
Модуль ядра — ключ к расширению возможностей Linux
Как вы знаете, или, может быть, слышали, ядро Linux изначально задумывалось монолитным - весь функционал отрабатывает в рамках одной программы:
Такая архитектура имеет ряд недостатков, например, невозможность установки новых драйверов без полной пересборки. Разработчики думали, думали и нашли решение этой проблеме, проработав систему модулей.
Сегодня ядро позволяет драйверам оборудования, файловых систем, и некоторым другим компонентам быть скомпилированными отдельно - в качестве модулей.
Модуль ядра - это программа, которая может отсоединяться от ядра и присоединяться к нему по необходимости, без повторной его компиляции и перезагрузки системы.
В общих терминах, модуль можно описать, как плагин, который расширяет функциональность ядра.
Такой подход не свел монолитность на нет - ядро таковым и осталось, за счет того, что работает вместе с модулями в одном адресном пространстве.
Находятся все модули в директории "/lib/modules/". Учитывая то, что они собираются под каждую отдельную версию ядра, в этом каталоге выстраивается структура папок - по штуке на установленную версию:
В директории целевого ядра находятся, как сами модули, так и дополнительные конфиги:
В ОС Linux все модули имеют расширение .ko (kernel object) или .ko.zst (модуль, сжатый с помощью алгоритма Zstandard). Подгружаются они, как правило, на этапе бута системы.
Помните, я тут недавно жаловался на драйвер i915, который в старых ядрах очень несовместим с некоторыми intel процессорами. Давайте посмотрим, где он засел:
Сегодня мы узнали, что такое модуль ядра. В следующей публикации дополнительно расширим спектр скиллов и рассмотрим основные команды администрирования модулей.
Linux++ | IT-Образование
Как вы знаете, или, может быть, слышали, ядро Linux изначально задумывалось монолитным - весь функционал отрабатывает в рамках одной программы:
/boot/vmlinuz-6.8.0-47-generic
Такая архитектура имеет ряд недостатков, например, невозможность установки новых драйверов без полной пересборки. Разработчики думали, думали и нашли решение этой проблеме, проработав систему модулей.
Сегодня ядро позволяет драйверам оборудования, файловых систем, и некоторым другим компонентам быть скомпилированными отдельно - в качестве модулей.
Модуль ядра - это программа, которая может отсоединяться от ядра и присоединяться к нему по необходимости, без повторной его компиляции и перезагрузки системы.
В общих терминах, модуль можно описать, как плагин, который расширяет функциональность ядра.
Такой подход не свел монолитность на нет - ядро таковым и осталось, за счет того, что работает вместе с модулями в одном адресном пространстве.
Находятся все модули в директории "/lib/modules/". Учитывая то, что они собираются под каждую отдельную версию ядра, в этом каталоге выстраивается структура папок - по штуке на установленную версию:
$ cd /lib/modules
$ ls
6.10.1-061001-generic 6.11.0-9-generic 6.8.0-060800-generic 6.9.0-060900-generic
В директории целевого ядра находятся, как сами модули, так и дополнительные конфиги:
$ cd 6.8.12-060812-generic
$ ls
build
modules.builtin
modules.dep.bin
kernel
...
В ОС Linux все модули имеют расширение .ko (kernel object) или .ko.zst (модуль, сжатый с помощью алгоритма Zstandard). Подгружаются они, как правило, на этапе бута системы.
Помните, я тут недавно жаловался на драйвер i915, который в старых ядрах очень несовместим с некоторыми intel процессорами. Давайте посмотрим, где он засел:
$ find /lib/modules/$(uname -r) -name *.ko* | grep i915
/lib/modules/6.8.12-060812-generic/kernel/drivers/gpu/drm/i915/i915.ko.zst
Сегодня мы узнали, что такое модуль ядра. В следующей публикации дополнительно расширим спектр скиллов и рассмотрим основные команды администрирования модулей.
Linux++ | IT-Образование
👍60🔥21❤🔥4
Подгружаем, отгружаем, управляем – просто и эффективно
Прошлый пост нам рассказал о том, что из себя представляет модуль ядра. Понимание этого - уже супер, но хочется больше!
Сегодня посмотрим на парочку команд и приемов по администрированию модулей.
Перечисление загруженных модулей
У вас есть возможность вывести список, подгруженных на данный момент, модулей. Выполнить это нам поможет lsmod - простая утилита, которая не принимает никаких опций или аргументов.
Все, что делает команда - читает файл "/proc/modules" и отображает его содержимое в хорошо отформатированном списке:
Результат дает нам следующую информацию:
1) Module - название модуля, выгруженного в память;
2) Size - количество памяти (в килобайтах), которое занимает модуль;
3) Used by - количество экземпляров модуля, используемое в настоящее время. Нулевое значение означает, что модуль не используется и его можно безопасно выгрузить.
Разделенный запятыми список после числа показывает, какие модули использует экземпляр;
Вывод информации о модуле
Команда modinfo отображает дополнительную информацию о модуле:
Загрузка модулей в рантайме
Как уже говорилось, подгрузка модулей - эффективный способ расширить функционал ядра. Как загрузить модуль? Использовать команды modprobe и insmod:
1) modprobe - умная команда, которая анализирует файл modules.dep, чтобы сначала загрузить зависимости, потом уже сам модуль:
2) insmod - более простая и менее гибкая команда, которая загружает модуль без проверки зависимостей:
Выгрузка модулей в рантайме
При необходимости можно удалить модули из работающей системы. Это также можно выполнить 2 способами: использовать rmmod или modprobe -r.
Последняя используется для более безопасного удаления, учитывая зависимости.
При выгрузке модуля через rmmod, остальные, которые от него зависят, будут пытаться функционировать.
Также команда поддерживает опцию "--force", которая ингода может быть полезна для агрессивной выгрузки:
Исключение модуля из автоматической загрузки
Для того, чтобы не загружать модуль на этапе бута системы, его требуется добавить в ЧС - файл blacklist.conf:
Такой прием бывает полезен, если требуется отключить проблемное оборудование или драйверы.
Автозагрузка модулей
Для того, чтобы каждый раз не производить ручную загрузку модулей, работать с которыми требуется регулярно, существует отдельный каталог, в котором можно настроить автоматическую загрузку модулей на старте системы "/etc/modules-load.d/".
В каталоге хранятся конфиги, содержащие наименования необходимых модулей:
При следующем запуске системы, указанные в файле модули, будут автоматически загружены.
Linux++ | IT-Образование
Прошлый пост нам рассказал о том, что из себя представляет модуль ядра. Понимание этого - уже супер, но хочется больше!
Сегодня посмотрим на парочку команд и приемов по администрированию модулей.
Перечисление загруженных модулей
У вас есть возможность вывести список, подгруженных на данный момент, модулей. Выполнить это нам поможет lsmod - простая утилита, которая не принимает никаких опций или аргументов.
Все, что делает команда - читает файл "/proc/modules" и отображает его содержимое в хорошо отформатированном списке:
$ lsmod
Module Size Used by
tcp_lp 12663 0
bluetooth 372662 7 bnep
rfkill 26536 3 bluetooth
Результат дает нам следующую информацию:
1) Module - название модуля, выгруженного в память;
2) Size - количество памяти (в килобайтах), которое занимает модуль;
3) Used by - количество экземпляров модуля, используемое в настоящее время. Нулевое значение означает, что модуль не используется и его можно безопасно выгрузить.
Разделенный запятыми список после числа показывает, какие модули использует экземпляр;
Вывод информации о модуле
Команда modinfo отображает дополнительную информацию о модуле:
$ modinfo i915
filename: /lib/modules/6.8.12-060812-generic/kernel/drivers/gpu/drm/i915/i915.ko.zst
license: GPL and additional rights
denoscription: Intel Graphics
author: Intel Corporation
...
Загрузка модулей в рантайме
Как уже говорилось, подгрузка модулей - эффективный способ расширить функционал ядра. Как загрузить модуль? Использовать команды modprobe и insmod:
1) modprobe - умная команда, которая анализирует файл modules.dep, чтобы сначала загрузить зависимости, потом уже сам модуль:
$ modprobe i915
$ lsmod | grep i915
i915 4268032 53
2) insmod - более простая и менее гибкая команда, которая загружает модуль без проверки зависимостей:
$ insmod helloWorld.ko
Welcome to Hello world Module.
Выгрузка модулей в рантайме
При необходимости можно удалить модули из работающей системы. Это также можно выполнить 2 способами: использовать rmmod или modprobe -r.
Последняя используется для более безопасного удаления, учитывая зависимости.
При выгрузке модуля через rmmod, остальные, которые от него зависят, будут пытаться функционировать.
Также команда поддерживает опцию "--force", которая ингода может быть полезна для агрессивной выгрузки:
$ rmmod module.ko
Goodbye, from module
$ modprobe -r module.ko
Goodbye, from module
Исключение модуля из автоматической загрузки
Для того, чтобы не загружать модуль на этапе бута системы, его требуется добавить в ЧС - файл blacklist.conf:
$ cat /etc/modprobe.d/blacklist.conf
blacklist eepro100
blacklist evbug
Такой прием бывает полезен, если требуется отключить проблемное оборудование или драйверы.
Автозагрузка модулей
Для того, чтобы каждый раз не производить ручную загрузку модулей, работать с которыми требуется регулярно, существует отдельный каталог, в котором можно настроить автоматическую загрузку модулей на старте системы "/etc/modules-load.d/".
В каталоге хранятся конфиги, содержащие наименования необходимых модулей:
$ cat modules.conf
video
e1000
serio_raw
При следующем запуске системы, указанные в файле модули, будут автоматически загружены.
Linux++ | IT-Образование
👍37🔥10❤🔥4❤1
Сокращаем команды: Мощь псевдонимов в Linux
Команда alias — это удобный инструмент для тех, кто постоянно работает в командной строке.
Пользователям часто приходится использовать одну и ту же команду. Нередко — с большим количеством опций или с одними и теми же аргументами.
Alias является, встроенной в оболочку командой, которая позволяет оптимизировать рутину и скрывать длинные вызовы под лаконичными псевдонимами.
К примеру, нам нужно понять, какие файлы занимают в целевом каталоге слишком много места и не надо ли их удалить...
Для реализации этой задачи нам потребуется команда ls и много-много аргументов:
Каждый раз набирать команду с таким количеством параметров не слишком удобно и хорошо бы это дело как-то сократить. Можно воспользоваться alias и определить ярлык для данного вызова:
Теперь запуск lsrt приведет к тому же результату, что и использование ls с параметрами.
Если нам больше не нужен ярлык, мы можем воспользоваться командой "unalias" и удалить его:
Если требуется вывести значение конкретного псевдонима, запустите alias и передайте его имя в качестве аргумента:
Важно: после начала нового сеанса оболочки псевдоним пропадет, а при попытке его использовать мы получим ошибку следующего вида:
Создание постоянных псевдонимов
Давайте, для начала, посмотрим, какие псевдонимы уже заданы в системе и доступны для текущей сессии:
Хммм, интересно, почему я ничего еще не делал, а уже что-то определено...
Да, в зависимости от дистрибутива, определенный набор псевдонимов уже будет заранее задан.
Как правило, найти и определить глобальные псевдонимы можно в скрипте "~/.bashrc", который выполняется каждый раз при инициализации оболочки:
Вот и они - те самые псевдонимы. Таким образом, для того, чтобы наш ярлык был доступен в разных терминалах целевого пользователя, нам требуется прописать его в локальном файле "~/.bashrc".
Если вы хотите, чтобы ваши алиасы были доступны для всех юзеров системы, необходимо использовать файл "/etc/bash.bashrc".
Linux++ | IT-Образование
Команда alias — это удобный инструмент для тех, кто постоянно работает в командной строке.
Пользователям часто приходится использовать одну и ту же команду. Нередко — с большим количеством опций или с одними и теми же аргументами.
Alias является, встроенной в оболочку командой, которая позволяет оптимизировать рутину и скрывать длинные вызовы под лаконичными псевдонимами.
К примеру, нам нужно понять, какие файлы занимают в целевом каталоге слишком много места и не надо ли их удалить...
Для реализации этой задачи нам потребуется команда ls и много-много аргументов:
$ ls --human-readable --size -1 -S --classify
Каждый раз набирать команду с таким количеством параметров не слишком удобно и хорошо бы это дело как-то сократить. Можно воспользоваться alias и определить ярлык для данного вызова:
$ alias lsrt='ls --human-readable --size -1 -S --classify'
Теперь запуск lsrt приведет к тому же результату, что и использование ls с параметрами.
Если нам больше не нужен ярлык, мы можем воспользоваться командой "unalias" и удалить его:
$ unalias lsrt
$ lsrt
Command 'lsrt' not found
Если требуется вывести значение конкретного псевдонима, запустите alias и передайте его имя в качестве аргумента:
$ alias g
alias g='grep'
Важно: после начала нового сеанса оболочки псевдоним пропадет, а при попытке его использовать мы получим ошибку следующего вида:
<your-alias-name> : command not found.
Создание постоянных псевдонимов
Давайте, для начала, посмотрим, какие псевдонимы уже заданы в системе и доступны для текущей сессии:
$ alias
alias l='ls -CF'
alias la='ls -A'
...
Хммм, интересно, почему я ничего еще не делал, а уже что-то определено...
Да, в зависимости от дистрибутива, определенный набор псевдонимов уже будет заранее задан.
Как правило, найти и определить глобальные псевдонимы можно в скрипте "~/.bashrc", который выполняется каждый раз при инициализации оболочки:
$ cat ~/.bashrc | grep alias
alias la='ls -A'
alias l='ls -CF'
Вот и они - те самые псевдонимы. Таким образом, для того, чтобы наш ярлык был доступен в разных терминалах целевого пользователя, нам требуется прописать его в локальном файле "~/.bashrc".
Если вы хотите, чтобы ваши алиасы были доступны для всех юзеров системы, необходимо использовать файл "/etc/bash.bashrc".
Linux++ | IT-Образование
👍43🔥17✍4❤3
Valve ускорила драйверы для AMD на 228%
Перед началом чуть-чуть разъясню: в Linux существует 3 драйвера для видеокарт AMD и Vulkan API:
1) AMDVLK (открытый и официальный);
2) RADV (открытый и неофициальный, из Mesa);
3) AMDGPU-PRO (закрытый и официальный);
В Mesa 24.3 наконец-то устранена основная проблема с драйвером RADV (Radeon Vulkan), которая приводила к снижению производительности по сравнению с проприетарными драйверами AMD: AMDVLK и AMDGPU-PRO.
Этот разрыв в производительности существовал почти 2 года в рамках "AMD FSR2 sample app".
Он был успешно устранён командой разработчиков Linux драйверов от Valve путём изменения нескольких строк кода.
Спасибо инженеру Сэмюэлю Питойсету, который, как сообщает Phoronix, выявил проблему и устранил её, изменив менее десятка строк кода.
Есть нюанс: эти самые 228% прироста производительности относятся только к демо-приложению для FSR2, а не к самому алгоритму, поэтому ликовать и думать, что сейчас на SteamDeck последние тайтлы будут идти на Ultra в 8K Super Resolution, не стоит...
С другой стороны, так как изменения вносились в сам драйвер, а не в "sample app", вероятно, определенный прирост производительности в каких-то кейсах мы все-таки получим.
Linux++ | IT-Образование
Перед началом чуть-чуть разъясню: в Linux существует 3 драйвера для видеокарт AMD и Vulkan API:
1) AMDVLK (открытый и официальный);
2) RADV (открытый и неофициальный, из Mesa);
3) AMDGPU-PRO (закрытый и официальный);
В Mesa 24.3 наконец-то устранена основная проблема с драйвером RADV (Radeon Vulkan), которая приводила к снижению производительности по сравнению с проприетарными драйверами AMD: AMDVLK и AMDGPU-PRO.
Этот разрыв в производительности существовал почти 2 года в рамках "AMD FSR2 sample app".
Он был успешно устранён командой разработчиков Linux драйверов от Valve путём изменения нескольких строк кода.
Спасибо инженеру Сэмюэлю Питойсету, который, как сообщает Phoronix, выявил проблему и устранил её, изменив менее десятка строк кода.
It looks like the fixed-func hardware is very slow to cull primitives with zero pos.w but shader based culling helps a lot.
This fixes a massive performance gap with the FSR2 demo compared to AMDGPU-PRO, +228% on RDNA2.
-Samuel Pitoiset (Credit: Phoronix)
Есть нюанс: эти самые 228% прироста производительности относятся только к демо-приложению для FSR2, а не к самому алгоритму, поэтому ликовать и думать, что сейчас на SteamDeck последние тайтлы будут идти на Ultra в 8K Super Resolution, не стоит...
It's since been clarified that this performance improvement is around the FSR2 sample application and not the FSR2 algorithm/implementation itself.
С другой стороны, так как изменения вносились в сам драйвер, а не в "sample app", вероятно, определенный прирост производительности в каких-то кейсах мы все-таки получим.
Linux++ | IT-Образование
🔥25👍13❤🔥4
Ускорь свою работу в командной строке - используй alias!
Приветствую! В прошлой публикации о псевдонимах мы познакомились с потрясающей командой оболочки alias и научились сокращать вызовы команд с длинным перечнем аргументов до пары символов.
Сегодня мы обратимся к моему опыту и рассмотрим ТОП команд, которые удобно использовать под псевдонимами.
Быстрый поиск команды по истории
Создание родительских директорий
Удаление директории
Перезагрузка и отключение системы
Переход назад по каталогам
Установка пакетов
Обновление пакетов
Топ 5 потребление памяти
Топ 5 потребление CPU
Сравнение файлов и директорий
Упаковка и распаковка .tar архива
Отображение скрытых файлов и каталогов
Linux++ | IT-Образование
Приветствую! В прошлой публикации о псевдонимах мы познакомились с потрясающей командой оболочки alias и научились сокращать вызовы команд с длинным перечнем аргументов до пары символов.
Сегодня мы обратимся к моему опыту и рассмотрим ТОП команд, которые удобно использовать под псевдонимами.
Быстрый поиск команды по истории
$ alias hgrep='history | grep'
$ hgrep cat
712 cat gtk-dark.css
Создание родительских директорий
$ alias mkdirs='mkdir -pv'
$ mkdirs ./dir1/dir2/dir3
Удаление директории
$ alias rmd='rm -rf'
$ rmd ./dir1
Перезагрузка и отключение системы
$ alias reboot='sudo /sbin/reboot'
$ alias poweroff='sudo /sbin/poweroff'
Переход назад по каталогам
$ alias ..="cd .."
$ alias ..2="cd ../.."
$ alias ..3="cd ../../.."
Установка пакетов
$ alias install='sudo apt install'
Обновление пакетов
$ alias upgrade='sudo apt update && sudo apt dist-upgrade'
Топ 5 потребление памяти
$ alias mem5='ps auxf | sort -nr -k 4 | head -5'
Топ 5 потребление CPU
$ alias cpu5='ps auxf | sort -nr -k 3 | head -5'
Сравнение файлов и директорий
$ alias diff='diff -Naur'
Упаковка и распаковка .tar архива
$ alias tar='tar -cvf'
$ alias untar='tar -xvf'
Отображение скрытых файлов и каталогов
$ alias ls.='ls -d .* --color=auto'
Linux++ | IT-Образование
1👍79❤🔥14👌7❤1
Оболочка - не терминал: что это и зачем нужно?
До того как значки и окна заполонили экраны наших мониторов, для взаимодействия с системой использовался командный интерпретатор (оболочка).
Оболочка — это специальная программа, которая предоставляет пользователю интерфейс для взаимодействия с ядром ОС.
Она принимает понятные человеку команды и выполняет их через обращения к ядру - на его языке - через набор системных вызовов: fork(), execve() и т.д.
Вот мы вводим команду "ls -l". Грубо говоря, как оболочка ее выполняет: создает дочерний процесс через вызов fork(), выполняет программу с заданными аргументами через execve() и дожидается ее завершения через wait().
Терминалом (эмулятором терминала) можно назвать более высокоуровневую программу, которая запускает оболочку и позволяет нам видеть ввод и вывод информации. Он, по сути, является оберткой для оболочки.
Никто же нам не мешает просто удалить исполняемые файлы оболочек (bash, sh, zsh) и запустить терминал... Так, конечно же, делать НЕ СТОИТ, но приложение, вероятно, запустится и выведет следующее сообщение:
При этом мы все еще сможем вводить текст и видеть его в окошке. Без оболочки терминал уже не так полезен - он понятия не имеет, как выполнить ту же команду "ls -l".
Также у оболочек может быть набор встроенных команд, которые могут отличаться от типа к типу. Помните, мы тут alias рассматривали? Так вот, это и есть та самая, встроенная в оболочку команда:
Команды оболочки - не отдельные программы. За их выполнением оболочка не пойдет по каталогам, прописанным в переменной $PATH: /usr/bin, /usr/sbin... К встроенным командам еще можно отнести: cd, case, export, pwd и т.д.
Linux++ | IT-Образование
До того как значки и окна заполонили экраны наших мониторов, для взаимодействия с системой использовался командный интерпретатор (оболочка).
Оболочка — это специальная программа, которая предоставляет пользователю интерфейс для взаимодействия с ядром ОС.
$ whereis bash
bash: /usr/bin/bash
Она принимает понятные человеку команды и выполняет их через обращения к ядру - на его языке - через набор системных вызовов: fork(), execve() и т.д.
Вот мы вводим команду "ls -l". Грубо говоря, как оболочка ее выполняет: создает дочерний процесс через вызов fork(), выполняет программу с заданными аргументами через execve() и дожидается ее завершения через wait().
Терминалом (эмулятором терминала) можно назвать более высокоуровневую программу, которая запускает оболочку и позволяет нам видеть ввод и вывод информации. Он, по сути, является оберткой для оболочки.
Никто же нам не мешает просто удалить исполняемые файлы оболочек (bash, sh, zsh) и запустить терминал... Так, конечно же, делать НЕ СТОИТ, но приложение, вероятно, запустится и выведет следующее сообщение:
Warning: Could not find an interactive shell to start
При этом мы все еще сможем вводить текст и видеть его в окошке. Без оболочки терминал уже не так полезен - он понятия не имеет, как выполнить ту же команду "ls -l".
Также у оболочек может быть набор встроенных команд, которые могут отличаться от типа к типу. Помните, мы тут alias рассматривали? Так вот, это и есть та самая, встроенная в оболочку команда:
$ type alias
alias is a shell builtin
Команды оболочки - не отдельные программы. За их выполнением оболочка не пойдет по каталогам, прописанным в переменной $PATH: /usr/bin, /usr/sbin... К встроенным командам еще можно отнести: cd, case, export, pwd и т.д.
Linux++ | IT-Образование
👍53🔥11❤6❤🔥2
Командные оболочки: от классики до инноваций
Наверняка многие знают оболочки sh и bash. Так же большинство из нас что-то слышали про zsh и fish. Однако на этом список не заканчивается.
В наши дни оболочек развелось немало, но далеко не все они используются. Сегодня мы рассмотрим самые основные экземпляры и посмотрим на их ключевые особенности.
Оболочка sh (Bourne shell)
Эта оболочка была написана Стивом Борном в 1977 году и является старейшей из известных публике.
Bourne shell была первой полноценной оболочкой и содержала функционал, который сейчас реализован всеми актуальными последователями: использование переменных, выполнение команд и функций, перенаправление ввода-вывода.
Сейчас sh по ряду причин является ссылкой на sh-совместимую оболочку:
В современных системах Bourne shell уже не используется в качестве пользовательской оболочки, однако полезен в роли командного интерпретатора.
Именно поэтому он и существует в качестве ссылки, чтобы не ломать совместимость для выполнения скриптов. Все же помнят про shebang?)
Оболочка bash (Bourne again shell)
Была разработана в рамках проекта GNU в качестве улучшенной реализации Bourne shell в 1989 году.
Основными создателями bash являются Брайан Фокс и Чет Рэми. Название можно перевести, как «Возрождённый шелл Борна». Скорее всего, самая популярная оболочка на сегодняшний день.
Данная оболочка является наследником sh и значительно расширяет его функционал. Однако все еще является древней и не такой красивой и конфигурируемой, как более новые zsh и fish.
Оболочка zsh (Z shell)
Свободная современная sh-совместимая оболочка, созданная в 1990 году. Имеет ряд преимуществ перед bash, касающихся в основном работы в интерактивном режиме.
Zsh поддерживает автодополнение, коррекцию опечаток, подсветку синтаксиса и довольно мощную конфигурацию внешнего вида и функционала через темы и плагины.
Однако zsh в полной мере раскрывается только через настройку конфигов. При первом запуске вы, вероятно, зададитесь вопросом: Зачем оно вообще надо - тот же самый bash... Да, его нужно вручную настраивать.
Очень рекомендованным дополнением к оболочке zsh является фреймворк "OH MY ZSH", который предназначен для управления настройками zsh и расширения его функционала за счет плагинов и тем.
Оболочка fish (friendly interactive shell)
Fish уже не такая "бородатая" оболочка. Первая версия датируется 2005 годом. На фоне основных коллег по цеху, которые были выпущены еще в прошлом веке fish — свежий огурчик.
Если вам нужен функционал больше, чем у bash, но вам не хочется зарываться в конфиги, как с zsh, можно рассмотреть данную оболочку.
Все бы хорошо, но есть нюанс: fish - POSIX-несовместимая оболочка. Это значит, что правила, продиктованные стандартом POSIX для ряда оболочек (bash, zsh и т.д.), не имеют никакого влияния на fish.
Пример. Вот так мы определяем локальные переменные в bash и zsh:
Давайте попробуем повторить то же самое в fish:
Тут так не получится. В fish переменные определяются следующим образом:
Уже поняли в чем суть? Если вы напишите скрипт на специфичном для fish синтаксисе и попытаетесь запустить его через интерпретатор bash, sh или zsh, вероятно, он упадет с ошибкой.
Linux++ | IT-Образование
Наверняка многие знают оболочки sh и bash. Так же большинство из нас что-то слышали про zsh и fish. Однако на этом список не заканчивается.
В наши дни оболочек развелось немало, но далеко не все они используются. Сегодня мы рассмотрим самые основные экземпляры и посмотрим на их ключевые особенности.
Оболочка sh (Bourne shell)
Эта оболочка была написана Стивом Борном в 1977 году и является старейшей из известных публике.
Bourne shell была первой полноценной оболочкой и содержала функционал, который сейчас реализован всеми актуальными последователями: использование переменных, выполнение команд и функций, перенаправление ввода-вывода.
Сейчас sh по ряду причин является ссылкой на sh-совместимую оболочку:
$ ls -l | grep sh
sh -> dash
В современных системах Bourne shell уже не используется в качестве пользовательской оболочки, однако полезен в роли командного интерпретатора.
Именно поэтому он и существует в качестве ссылки, чтобы не ломать совместимость для выполнения скриптов. Все же помнят про shebang?)
#!/bin/sh
Оболочка bash (Bourne again shell)
Была разработана в рамках проекта GNU в качестве улучшенной реализации Bourne shell в 1989 году.
Основными создателями bash являются Брайан Фокс и Чет Рэми. Название можно перевести, как «Возрождённый шелл Борна». Скорее всего, самая популярная оболочка на сегодняшний день.
Данная оболочка является наследником sh и значительно расширяет его функционал. Однако все еще является древней и не такой красивой и конфигурируемой, как более новые zsh и fish.
Оболочка zsh (Z shell)
Свободная современная sh-совместимая оболочка, созданная в 1990 году. Имеет ряд преимуществ перед bash, касающихся в основном работы в интерактивном режиме.
$ sudo apt install zsh
Zsh поддерживает автодополнение, коррекцию опечаток, подсветку синтаксиса и довольно мощную конфигурацию внешнего вида и функционала через темы и плагины.
Однако zsh в полной мере раскрывается только через настройку конфигов. При первом запуске вы, вероятно, зададитесь вопросом: Зачем оно вообще надо - тот же самый bash... Да, его нужно вручную настраивать.
Очень рекомендованным дополнением к оболочке zsh является фреймворк "OH MY ZSH", который предназначен для управления настройками zsh и расширения его функционала за счет плагинов и тем.
Оболочка fish (friendly interactive shell)
Fish уже не такая "бородатая" оболочка. Первая версия датируется 2005 годом. На фоне основных коллег по цеху, которые были выпущены еще в прошлом веке fish — свежий огурчик.
$ sudo apt-add-repository ppa:fish-shell/release-3
$ sudo apt update
$ sudo apt install fish
Если вам нужен функционал больше, чем у bash, но вам не хочется зарываться в конфиги, как с zsh, можно рассмотреть данную оболочку.
Все бы хорошо, но есть нюанс: fish - POSIX-несовместимая оболочка. Это значит, что правила, продиктованные стандартом POSIX для ряда оболочек (bash, zsh и т.д.), не имеют никакого влияния на fish.
Пример. Вот так мы определяем локальные переменные в bash и zsh:
$ MY_VAR="Hello"
Давайте попробуем повторить то же самое в fish:
$ MY_VAR="Hello"
fish: Unsupported use of '='. In fish, please use 'set MY_VAR "Hello"'
Тут так не получится. В fish переменные определяются следующим образом:
$ set MY_VAR "Hello"
Уже поняли в чем суть? Если вы напишите скрипт на специфичном для fish синтаксисе и попытаетесь запустить его через интерпретатор bash, sh или zsh, вероятно, он упадет с ошибкой.
Linux++ | IT-Образование
👍48❤9❤🔥7🔥2
Понимание типов оболочек: interactive, non-interactive, login, non-login
Да-да, с оболочками есть еще и такой прикол. Многих людей сбивает с толку процесс настройки оболочек именно по тому, что они не в курсе о типовых различиях. Сегодня я постараюсь дать вам базовое понимание каждого из типов, чтобы потом легче было разобраться с конфигами.
Оболочки "interactive"
Максимально упрощая, интерактивная оболочка - та, с которой мы работаем через ручной ввод - мы печатаем команду, передаем ее оболочке на вход и видим результат по завершению. Когда вы запускаете терминал, оболочка стартует в интерактивном режиме.
Оболочки "non-interactive"
Это тот режим запуска оболочки, когда она не взаимодействуют напрямую с пользователем. Обычно они запускаются для выполнения команд или скриптов и завершаются по мере окончания задачи. Все же помнят про тот самый shebang:
Так вот, для запуска скрипта мы изначально открываем bash (интерактивная оболочка) и указываем путь:
Далее bash запустит интерпретатор sh (неинтерактивная оболочка), после чего тот "втихую" выполнит скрипт.
Это ВАЖНО помнить! Скрипты отрабатывают в неинтерактивных оболочках и ваши настройки в файле "~/.bashrc" окажутся бесполезными. Почему такие оболочки не подгружают конфиги? Хороший вопрос. Есть несколько причин:
1) скрипту не следует полагаться на пользовательские настройки - быть "пользователезависимым". Если юзер "настругал" скрипт, опираясь, допустим, на свои алиасы, будет нарушена портируемость и у другого человека он, вероятно, не стартанет.
2) чтение и отработка конфигов может занимать время. Без дополнительных подготовок скрипт банально быстрее отработает.
Оболочки "login"
Такая оболочка создается первым пользовательским процессом, когда тот успешно логинится в системе и открывает сессию через tty или ssh. Если вы авторизовались через GUI - дисплей менеджер, "login shell" обычно заменяется оконным менеджером либо менеджером сессии.
Данный тип оболочки не создается все время, как мы открываем терминал и отличается тем, что читает дополнительные конфиги. Явно его можно идентифицировать по префиксу '-' для исполняемого файла. Давайте зайдем пользователем через tty и проверим:
А теперь сами запустим еще одну оболочку внутри родительской и убедимся, что статус "login shell" выдается невсегда:
Также узнать тип оболочки можно через переменную '0':
Оболочки "non-login"
Создаются при обычном старте - без авторизации пользователя. Все, что нужно для инициализации такой оболочки - просто открыть терминал либо самому запустить исполняемый файл без дополнительных флагов, которые переводят оболочку в режим "login": "-l" и "--login".
Linux++ | IT-Образование
Да-да, с оболочками есть еще и такой прикол. Многих людей сбивает с толку процесс настройки оболочек именно по тому, что они не в курсе о типовых различиях. Сегодня я постараюсь дать вам базовое понимание каждого из типов, чтобы потом легче было разобраться с конфигами.
Оболочки "interactive"
Максимально упрощая, интерактивная оболочка - та, с которой мы работаем через ручной ввод - мы печатаем команду, передаем ее оболочке на вход и видим результат по завершению. Когда вы запускаете терминал, оболочка стартует в интерактивном режиме.
Оболочки "non-interactive"
Это тот режим запуска оболочки, когда она не взаимодействуют напрямую с пользователем. Обычно они запускаются для выполнения команд или скриптов и завершаются по мере окончания задачи. Все же помнят про тот самый shebang:
#!/bin/sh
Так вот, для запуска скрипта мы изначально открываем bash (интерактивная оболочка) и указываем путь:
$ ./noscript.sh
Далее bash запустит интерпретатор sh (неинтерактивная оболочка), после чего тот "втихую" выполнит скрипт.
Это ВАЖНО помнить! Скрипты отрабатывают в неинтерактивных оболочках и ваши настройки в файле "~/.bashrc" окажутся бесполезными. Почему такие оболочки не подгружают конфиги? Хороший вопрос. Есть несколько причин:
1) скрипту не следует полагаться на пользовательские настройки - быть "пользователезависимым". Если юзер "настругал" скрипт, опираясь, допустим, на свои алиасы, будет нарушена портируемость и у другого человека он, вероятно, не стартанет.
2) чтение и отработка конфигов может занимать время. Без дополнительных подготовок скрипт банально быстрее отработает.
Оболочки "login"
Такая оболочка создается первым пользовательским процессом, когда тот успешно логинится в системе и открывает сессию через tty или ssh. Если вы авторизовались через GUI - дисплей менеджер, "login shell" обычно заменяется оконным менеджером либо менеджером сессии.
Данный тип оболочки не создается все время, как мы открываем терминал и отличается тем, что читает дополнительные конфиги. Явно его можно идентифицировать по префиксу '-' для исполняемого файла. Давайте зайдем пользователем через tty и проверим:
$ ps -auxf
(root) /bin/login -p --
(user) \_ -bash
\_ ps -auxf
А теперь сами запустим еще одну оболочку внутри родительской и убедимся, что статус "login shell" выдается невсегда:
$ bash
$ ps -auxf
/bin/login -p --
\_ -bash
\_ bash
\_ ps -auxf
Также узнать тип оболочки можно через переменную '0':
$ echo $0
-bash
Оболочки "non-login"
Создаются при обычном старте - без авторизации пользователя. Все, что нужно для инициализации такой оболочки - просто открыть терминал либо самому запустить исполняемый файл без дополнительных флагов, которые переводят оболочку в режим "login": "-l" и "--login".
Linux++ | IT-Образование
👍19❤🔥16🔥10