В стандартном репозитории Debian живёт неприметная и не особо популярная программа sosreport. Создана она была, судя по названию, для служб технической поддержки. Тем не менее, полезна может быть не только им. Она создаёт архив со слепком состояния системы. Этот архив включает в себя практически всю информацию о системе:
◽️Настройки Grub
◽️Все конфигурационные файлы из раздела
◽️Информация о ядре, модулях, настройках sysctl
◽️Объекты systemd
◽️Различная информация о системе: версия, точки монтирования, информация о железе, кроны, пользователи, настройки сети, установленные пакеты и т.д.
◽️Информация о пользователях, история логинов, параметры.
◽️Логи из
◽️И многое другое, функциональность расширяется плагинами, которые можно писать самостоятельно
По сути собрана вся доступная подробная информация о системе. Ставится так:
Использовать удобнее всего так:
Первый ключ отменяет интерактивные вопросы перед запуском, второй добавляет логи. На выходе получите архив в разделе
Архив будет иметь имя вида
Довольно удобная штука, чтобы быстро снять слепок состояния системы и потом спокойно его изучать, не боясь, что пока ты что-то ищешь или смотришь, состояние изменится. Так же предполагаю, что может быть полезно, например, раз в сутки делать такой слепок и складывать куда-то на некоторое время, просто на всякий случай. Архив получается маленький, проблем его хранить нет. Но в случае внештатной ситуации может помочь.
Ещё вариант применения - запускать по каким-то событиям мониторинга. Например, сработал триггер на загрузку процессора. Можно запустить скрипт с sosreport, который применит только плагин process и соберёт всю информацию о процессах.
Sosreport выполнит и сохранит вывод следующих команд:
Можно и самому всё это выполнить и вывести куда-то, но через sosreport удобнее. Он к тому же может сразу положить архив куда-то по ftp или sftp с помощью ключей
Я нечто подобное делала вручную и до сих пор использую. Описывал в своей статье:
⇨ Мониторинг списка запущенных процессов в Zabbix
Я там сделал более костыльно, но зато вывод сразу в history закидываю, чтобы можно было список процессов прямо в веб интерфейсе Zabbix смотреть.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #мониторинг
◽️Настройки Grub
◽️Все конфигурационные файлы из раздела
/etc◽️Информация о ядре, модулях, настройках sysctl
◽️Объекты systemd
◽️Различная информация о системе: версия, точки монтирования, информация о железе, кроны, пользователи, настройки сети, установленные пакеты и т.д.
◽️Информация о пользователях, история логинов, параметры.
◽️Логи из
/var/log и journalctl◽️И многое другое, функциональность расширяется плагинами, которые можно писать самостоятельно
По сути собрана вся доступная подробная информация о системе. Ставится так:
# apt install sosreportИспользовать удобнее всего так:
# sos report --batch --all-logsПервый ключ отменяет интерактивные вопросы перед запуском, второй добавляет логи. На выходе получите архив в разделе
/tmp. Директорию можно указать любую. Архив будет иметь имя вида
sosreport-337737-2025-04-15-acgbmpx.tar.xz. Его можно распаковать и смотреть прямо тут, либо передать куда-то в другое место, распаковать и запустить сгенерированную html страничку sos.html, которая лежит в директории sos_reports.Довольно удобная штука, чтобы быстро снять слепок состояния системы и потом спокойно его изучать, не боясь, что пока ты что-то ищешь или смотришь, состояние изменится. Так же предполагаю, что может быть полезно, например, раз в сутки делать такой слепок и складывать куда-то на некоторое время, просто на всякий случай. Архив получается маленький, проблем его хранить нет. Но в случае внештатной ситуации может помочь.
Ещё вариант применения - запускать по каким-то событиям мониторинга. Например, сработал триггер на загрузку процессора. Можно запустить скрипт с sosreport, который применит только плагин process и соберёт всю информацию о процессах.
# /usr/bin/sosreport --batch -o processSosreport выполнит и сохранит вывод следующих команд:
# ps auxwww# lsof -b +M -n -l -c ''# ps auxwwwm# ps alxwww# ps -elfL# ps axo pid,ppid,user,group,lwp,nlwp,start_time,comm,cgroup# ps axo flags,state,uid,pid,ppid,pgid,sid,cls,pri,addr,sz,wchan:20,lstart,tty,time,cmdМожно и самому всё это выполнить и вывести куда-то, но через sosreport удобнее. Он к тому же может сразу положить архив куда-то по ftp или sftp с помощью ключей
--upload, --upload-url, --upload-user, --upload-pass. Я нечто подобное делала вручную и до сих пор использую. Описывал в своей статье:
⇨ Мониторинг списка запущенных процессов в Zabbix
Я там сделал более костыльно, но зато вывод сразу в history закидываю, чтобы можно было список процессов прямо в веб интерфейсе Zabbix смотреть.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #мониторинг
Я очень много лет использовал в Linux утилиту screen для того, чтобы в случае обрыва связи при подключении по SSH не завершалось выполнение запущенных интерактивных операций. Особенно это касается обновлений системы через apt или dnf. Типичная проблема, не считая банального обрыва связи, - подключился по VPN к серверу, запустил обновление, обновился софт для VPN, тебя отключило, обновление завершилось на середине процесса. Это может привести к проблемам (система не загрузилась из-за прерванного обновления).
В screen меня всегда раздражало то, что после открытия и сворачивания Midnight Commander по комбинации клавиш CTRL + o, очищался терминал и ты не видел то, что там было до этого. Частично помогает скрол окна SSH клиента, но это неудобно и всё равно часть информации пропадает, обрезается.
В tmux такой проблемы нет. Всё работает ожидаемо, можно разворачивать, сворачивать MC, содержимое терминала не очищается. В итоге у меня на половине серверов по старинке screen стоит, на другой - tmux. Я никакими дополнительными возможностями tmux и screen не пользуюсь, мне главное при обрыве соединения вернуться в свою сессию. В screen привык к горячим клавишам и ключам и переучиваться на tmux не хотелось, так как нет большого смысла.
Оказывается, внутри screen есть свой скролер терминала. Достаточно нажать CTRL + a и потом [, откроется скролинг, где клавиашми PgUp / PgDn можно мотать вверх и вниз и читать содержимое терминала, в том числе то, что там было до запуска MC.
Возможно кому-то эта заметка поможет. Жаль, что я раньше об этом не узнал, столько лет раздражала эта фигня, примерно так же, как лесенка в MC, пока не узнал, как от неё избавиться.
Если кто только выбирает, что использовать, screen или tmux, рекомендую последний. По основным возможностям там примерно одно и то же, у tmux даже их больше, а по удобству, очевидности стандартных настроек, tmux тоже выигрывает. Я уже привык к screen, не хочется переучиваться, так как ничего принципиально нового для себя не получу. У tmux до сих пор подсматриваю горячие клавиши и ключи. Для screen это уже давно в голове отложилось и на автомате выполняется.
Когда-то давно опрос делал по поводу screen и tmux, кто чем пользуется. Результат был примерно 50 / 50. Примерно равная популярность у этих утилит. Сейчас ещё Zellij прибавилась. Но не думаю, что она сильно популярна и не станет таковой, пока не приедет в базовые репы. Вы что предпочитаете из этой троицы?
#linux #terminal
В screen меня всегда раздражало то, что после открытия и сворачивания Midnight Commander по комбинации клавиш CTRL + o, очищался терминал и ты не видел то, что там было до этого. Частично помогает скрол окна SSH клиента, но это неудобно и всё равно часть информации пропадает, обрезается.
В tmux такой проблемы нет. Всё работает ожидаемо, можно разворачивать, сворачивать MC, содержимое терминала не очищается. В итоге у меня на половине серверов по старинке screen стоит, на другой - tmux. Я никакими дополнительными возможностями tmux и screen не пользуюсь, мне главное при обрыве соединения вернуться в свою сессию. В screen привык к горячим клавишам и ключам и переучиваться на tmux не хотелось, так как нет большого смысла.
Оказывается, внутри screen есть свой скролер терминала. Достаточно нажать CTRL + a и потом [, откроется скролинг, где клавиашми PgUp / PgDn можно мотать вверх и вниз и читать содержимое терминала, в том числе то, что там было до запуска MC.
Возможно кому-то эта заметка поможет. Жаль, что я раньше об этом не узнал, столько лет раздражала эта фигня, примерно так же, как лесенка в MC, пока не узнал, как от неё избавиться.
Если кто только выбирает, что использовать, screen или tmux, рекомендую последний. По основным возможностям там примерно одно и то же, у tmux даже их больше, а по удобству, очевидности стандартных настроек, tmux тоже выигрывает. Я уже привык к screen, не хочется переучиваться, так как ничего принципиально нового для себя не получу. У tmux до сих пор подсматриваю горячие клавиши и ключи. Для screen это уже давно в голове отложилось и на автомате выполняется.
Когда-то давно опрос делал по поводу screen и tmux, кто чем пользуется. Результат был примерно 50 / 50. Примерно равная популярность у этих утилит. Сейчас ещё Zellij прибавилась. Но не думаю, что она сильно популярна и не станет таковой, пока не приедет в базовые репы. Вы что предпочитаете из этой троицы?
#linux #terminal
В Debian есть интересная библиотека libeatmydata, которая подменяет системные вызовы fsync, fdatasync, sync и некоторые другие на пустышки. Эти команды сразу выдают положительный результат, ничего не делая. То есть не работает подтверждение записи на диск.
Это существенно ускоряет все операции записи, но и, что логично, создаёт вероятность потери данных, так как реально они залетают в кэш, а не на диск. И будут записаны в зависимости от настроек и параметров системы, когда ядро посчитает нужным выполнить синхронизацию: по таймеру фоновой синхронизации или недостатка свободной оперативной памяти.
Работает это примерно так:
Реально там ещё пару проверок с if, но по сути всё так и есть для всех системных вызовов, что она она перехватывает.
Эту возможность без особых опасений можно использовать во временных или тестовых средах, где не важна сохранность данных. Причём сделать это очень просто. Ставим пакет:
Запускаем через него любую команду. Я протестировал на старой виртуалке, которую давно не обновляли. Сделал запуск обновления без eatmydata и с ней. Разница получилась заметной.
Напомню, что реальной установкой пакетов занимается утилита
Я выполнил полное обновление пакетов в два этапа, откатив первое обновление на изначальный снепшот:
Работа dpkg занимает где-то треть всего времени, ещё треть загрузка пакетов, и треть пересборка initramfs. Без eatmydata dpkg работала примерно 30 секунд, с ней – 20.
Или вот ещё более наглядный тест. Запускаем создание файла в режиме синхронизации и подтверждения записи каждого блока:
И то же самое через eatmydata:
Эта возможность может пригодиться при сборке контейнеров, образов, раскатки тестовых сред. Можно запускать тестовую СУБД через eatmydata. Да всё, что угодно на тестовом сервере.
Если у вас есть какие-то скрипты, которые не хочется переделывать, добавляя в начало каждой команды eatmydata, можете просто задать переменную окружения, в том числе глобальную в
И все процессы будут писать без подтверждения записи в кэш.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Это существенно ускоряет все операции записи, но и, что логично, создаёт вероятность потери данных, так как реально они залетают в кэш, а не на диск. И будут записаны в зависимости от настроек и параметров системы, когда ядро посчитает нужным выполнить синхронизацию: по таймеру фоновой синхронизации или недостатка свободной оперативной памяти.
Работает это примерно так:
int fsync(int fd) {
return 0;
}Реально там ещё пару проверок с if, но по сути всё так и есть для всех системных вызовов, что она она перехватывает.
Эту возможность без особых опасений можно использовать во временных или тестовых средах, где не важна сохранность данных. Причём сделать это очень просто. Ставим пакет:
# apt install eatmydataЗапускаем через него любую команду. Я протестировал на старой виртуалке, которую давно не обновляли. Сделал запуск обновления без eatmydata и с ней. Разница получилась заметной.
Напомню, что реальной установкой пакетов занимается утилита
dpkg, а не apt. Dpkg для надёжности выполняет все действия с подтверждением записи. Так что если запустить её через eatmydata, она отработает гораздо быстрее. Я выполнил полное обновление пакетов в два этапа, откатив первое обновление на изначальный снепшот:
# time apt upgrade -yFetched 249 MB in 30s (8,183 kB/s)real 1m 43.690s# time eatmydata apt upgrade -yFetched 249 MB in 33s (7,671 kB/s)real 1m 36.984sРабота dpkg занимает где-то треть всего времени, ещё треть загрузка пакетов, и треть пересборка initramfs. Без eatmydata dpkg работала примерно 30 секунд, с ней – 20.
Или вот ещё более наглядный тест. Запускаем создание файла в режиме синхронизации и подтверждения записи каждого блока:
# dd if=/dev/zero of=/mnt/tempfile bs=1M count=512 oflag=dsync536870912 bytes (537 MB, 512 MiB) copied, 1.95211 s, 275 MB/sИ то же самое через eatmydata:
# eatmydata dd if=/dev/zero of=/mnt/tempfile bs=1M count=512 oflag=dsync536870912 bytes (537 MB, 512 MiB) copied, 0.343773 s, 1.6 GB/sЭта возможность может пригодиться при сборке контейнеров, образов, раскатки тестовых сред. Можно запускать тестовую СУБД через eatmydata. Да всё, что угодно на тестовом сервере.
Если у вас есть какие-то скрипты, которые не хочется переделывать, добавляя в начало каждой команды eatmydata, можете просто задать переменную окружения, в том числе глобальную в
/etc/environment:LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.soИ все процессы будут писать без подтверждения записи в кэш.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Настраивал на днях арендованный сервер без прямого доступа к консоли. Ещё и конфигурация была нестандартная, так что техподдержка вручную установила туда ОС и отдала мне с доступом по SSH. Нужно было настроить дополнительные диски и добавить их в fstab. Несмотря на то, что в современных ОС реально монтирует диски systemd, я по старинке предпочитаю добавлять новые точки монтирования в fstab.
В этом деле самое главное – не ошибиться и сразу после изменения файла проверить, что там всё в порядке. Иначе после перезагрузки можно получить проблемы. Без прямого доступа к консоли это может быть фатально.
Я обычно добавляю новые диски в систему следующим образом. Смотрю список дисков через fstab:
Сразу видно диски без разметки. Добавлять разделы предпочитаю в cfdisk, а не напрямую в консоли через fstab. В TUI как-то нагляднее, меньше шансов ошибиться.
Создаю раздел, выбираю тип раздела, сохраняю. После этого можно создавать файловую систему.
Монтирую в систему:
Теперь нам надо добавить эту точку монтирования в fstab. По имени диска категорически нельзя добавлять. Диски могут менять свои имена. Причём это стало актуально в какой-то момент с очередным обновлением железа. Когда я только начинал изучать Linux, спокойно монтировал по именам дисков и проблем не было. В какой-то момент они начались. И сейчас я сам часто наблюдаю, что диски, как и сетевые интерфейсы, могут изменить свои имена после перезагрузки. Если используете LVM, то можно добавлять точки монтирования по имени LV.
Смотрим UUID раздела:
Добавляем его в fstab отдельной строкой:
А теперь проверяем, всё ли мы правильно добавили.
Findmnt проверил все монтирования. В моём случае я получил предупреждение на /media/cdrom0.
Судя по всему систему ставили с какого-то диска, локального или сетевого, не знаю, но он остался в fstab. Делать ему там больше нечего, можно закомментировать строку с ним.
Более кратко можно получить информацию только об ошибках:
☝️Отдельно обращаю внимание на такой момент. До перехода управления к systemd было критически важно оставлять в fstab в конце файла переход на новую строку. Сейчас даже если этого не сделать, то проблем не будет. Всё нормально загрузится. Насколько я понимаю, это тянется из далёкого прошлого и POSIX-совместимой практики, когда файлы конфигурации заканчивались переходом на новую строку. Я лично до сих пор на всякий случай везде этой практики придерживаюсь.
Ещё один способ проверить корректность записей в fstab – использовать mount. Можно не монтировать вручную новый диск, а сразу добавить его в fstab. Потом запустить:
Утилита смонтирует все записи из файла, где не указан параметр noauto. Если вы всё верно добавили, то ошибок не увидите и получите смонтированным новый диск.
Расскажу, что будет, если, к примеру, ошибётесь с диском в fstab или он просто перестанет быть видим в системе. Я лично с этим не раз сталкивался. А однажды это привело к дальней дороге. Добавили наживую новый диск в сервер, я его добавил с ошибкой в fstab и не проверил. Сервер аварийно перезагрузился через полгода из-за обесточивания серверной. Возникли какие-то проблемы с доступом туда, ещё и сервер по неизвестной на тот момент мне причине не стартанул. Приехал туда ножками и увидел примерно то же самое, что вы видите на втором скрине.
Сразу понял, в чём дело, зашёл в режим обслуживания и поправил fstab. Так что внимательно относитесь к его настройке. Этой проблемы можно избежать, если использовать nofail в параметрах монтирования. Но с ним могут быть нюансы. Иногда лучше не загрузиться, если с разделом проблемы.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
В этом деле самое главное – не ошибиться и сразу после изменения файла проверить, что там всё в порядке. Иначе после перезагрузки можно получить проблемы. Без прямого доступа к консоли это может быть фатально.
Я обычно добавляю новые диски в систему следующим образом. Смотрю список дисков через fstab:
# fdisk -l | grep /dev/Сразу видно диски без разметки. Добавлять разделы предпочитаю в cfdisk, а не напрямую в консоли через fstab. В TUI как-то нагляднее, меньше шансов ошибиться.
# cfdisk /dev/sdbСоздаю раздел, выбираю тип раздела, сохраняю. После этого можно создавать файловую систему.
# mkfs -t ext4 /dev/sdb1Монтирую в систему:
# mkdir /mnt/disk1# mount /dev/sdb1 /mnt/disk1Теперь нам надо добавить эту точку монтирования в fstab. По имени диска категорически нельзя добавлять. Диски могут менять свои имена. Причём это стало актуально в какой-то момент с очередным обновлением железа. Когда я только начинал изучать Linux, спокойно монтировал по именам дисков и проблем не было. В какой-то момент они начались. И сейчас я сам часто наблюдаю, что диски, как и сетевые интерфейсы, могут изменить свои имена после перезагрузки. Если используете LVM, то можно добавлять точки монтирования по имени LV.
Смотрим UUID раздела:
# blkid | grep /dev/sdb1Добавляем его в fstab отдельной строкой:
UUID=eaf5c153-08b7-4ea8-8037-e6baad4cac0d /mnt/disk1 ext4 errors=remount-ro 1 0А теперь проверяем, всё ли мы правильно добавили.
# findmnt --verify --verboseFindmnt проверил все монтирования. В моём случае я получил предупреждение на /media/cdrom0.
[W] unreachable source: /dev/sr0: No such file or directoryСудя по всему систему ставили с какого-то диска, локального или сетевого, не знаю, но он остался в fstab. Делать ему там больше нечего, можно закомментировать строку с ним.
Более кратко можно получить информацию только об ошибках:
# findmnt -x☝️Отдельно обращаю внимание на такой момент. До перехода управления к systemd было критически важно оставлять в fstab в конце файла переход на новую строку. Сейчас даже если этого не сделать, то проблем не будет. Всё нормально загрузится. Насколько я понимаю, это тянется из далёкого прошлого и POSIX-совместимой практики, когда файлы конфигурации заканчивались переходом на новую строку. Я лично до сих пор на всякий случай везде этой практики придерживаюсь.
Ещё один способ проверить корректность записей в fstab – использовать mount. Можно не монтировать вручную новый диск, а сразу добавить его в fstab. Потом запустить:
# mount -a -vУтилита смонтирует все записи из файла, где не указан параметр noauto. Если вы всё верно добавили, то ошибок не увидите и получите смонтированным новый диск.
Расскажу, что будет, если, к примеру, ошибётесь с диском в fstab или он просто перестанет быть видим в системе. Я лично с этим не раз сталкивался. А однажды это привело к дальней дороге. Добавили наживую новый диск в сервер, я его добавил с ошибкой в fstab и не проверил. Сервер аварийно перезагрузился через полгода из-за обесточивания серверной. Возникли какие-то проблемы с доступом туда, ещё и сервер по неизвестной на тот момент мне причине не стартанул. Приехал туда ножками и увидел примерно то же самое, что вы видите на втором скрине.
Сразу понял, в чём дело, зашёл в режим обслуживания и поправил fstab. Так что внимательно относитесь к его настройке. Этой проблемы можно избежать, если использовать nofail в параметрах монтирования. Но с ним могут быть нюансы. Иногда лучше не загрузиться, если с разделом проблемы.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
На тему LA (Load Average) написано очень много материалов. Про неё любят спрашивать на собеседованиях, писать тематические статьи и проводить уроки различные онлайн школы. Это прям горячая тема. Я когда-то давно в одной переведённой с иностранного материала статье на хабре увидел очень хорошую аналогию LA с загрузкой шоссе машинами и сразу запомнил её. Не встречал с тех пор наглядных объяснений в таком контексте. Расскажу кратко тем, кто до конца не понимает, что эта загрузка означает.
Пара примеров, почему LA неоднозначна. Можно зайти на сервер, увидеть LA под 100, но при этом процессор будет не нагружен вообще. Это тупит примонтированный сетевой диск, например, по NFS или iSCSI. Или LA в 30 может показаться запредельно большой, но если на сервере 36 ядер и нагрузка хоть и большая, но в целом сервер её вывозит.
Для однопроцессорной системы понять логику измерения Load Average можно с помощью картинки во вложении. Для простоты восприятия LA сравнивают с транспортным потоком на мосту. Значение более 1 означает наличие очереди на въезде на мост. Размер этой очереди будет равен превышению единицы. Например, значение 1,7 показывает, что в очереди стоит 70% от числа машин, находящихся на мосту.
В ядре Linux процессы, выполняющиеся в данный момент, это машины на мосту, а процессы, ожидающие очереди на исполнение, это машины в пробке на въезде на мост. Причем очередь из процессов может образовываться не только из-за загруженности процессора, но и других компонентов системы. Например, подсистемы ввода-вывода (диск, сеть).
Идеально, когда пробки нет, никто никого не ждёт, есть запас по пропускной способности моста. Многопроцессорная система - это сумма таких мостов. Каждый увеличивает пропускную способность на единицу. Загрузка 1 для двух мостов означает нагрузку на мосты в 50%, для трёх на 33%. Ну и так далее. Очень просто и наглядно.
Если кто-то знает более простые и наглядные аналогии, расскажите.
И в продолжении этой темы добавлю ссылку на мою недавнюю заметку на тему метрики IOWait. Она тоже очень неоднозначна и может своими показаниями вводить в заблуждение, если не знаешь нюансов. Там, к сожалению, нет простой аналогии, нужно вчитаться и понять без аналогий, о чём идёт речь. Но информация важная, если вам приходится разбираться с производительностью систем на базе Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
Пара примеров, почему LA неоднозначна. Можно зайти на сервер, увидеть LA под 100, но при этом процессор будет не нагружен вообще. Это тупит примонтированный сетевой диск, например, по NFS или iSCSI. Или LA в 30 может показаться запредельно большой, но если на сервере 36 ядер и нагрузка хоть и большая, но в целом сервер её вывозит.
Для однопроцессорной системы понять логику измерения Load Average можно с помощью картинки во вложении. Для простоты восприятия LA сравнивают с транспортным потоком на мосту. Значение более 1 означает наличие очереди на въезде на мост. Размер этой очереди будет равен превышению единицы. Например, значение 1,7 показывает, что в очереди стоит 70% от числа машин, находящихся на мосту.
В ядре Linux процессы, выполняющиеся в данный момент, это машины на мосту, а процессы, ожидающие очереди на исполнение, это машины в пробке на въезде на мост. Причем очередь из процессов может образовываться не только из-за загруженности процессора, но и других компонентов системы. Например, подсистемы ввода-вывода (диск, сеть).
Идеально, когда пробки нет, никто никого не ждёт, есть запас по пропускной способности моста. Многопроцессорная система - это сумма таких мостов. Каждый увеличивает пропускную способность на единицу. Загрузка 1 для двух мостов означает нагрузку на мосты в 50%, для трёх на 33%. Ну и так далее. Очень просто и наглядно.
Если кто-то знает более простые и наглядные аналогии, расскажите.
И в продолжении этой темы добавлю ссылку на мою недавнюю заметку на тему метрики IOWait. Она тоже очень неоднозначна и может своими показаниями вводить в заблуждение, если не знаешь нюансов. Там, к сожалению, нет простой аналогии, нужно вчитаться и понять без аналогий, о чём идёт речь. Но информация важная, если вам приходится разбираться с производительностью систем на базе Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
На днях столкнулся в небольшой ошибкой в скриптах для бэкапа, когда настраивал их работу через cron. Я уже не раз упоминал, что в скриптах лучше всегда писать полные пути. Я это обычно соблюдаю, особенно для исполняемых файлов. А тут ошибся немного в другом.
Делал большой скрипт, где было много разных операций, в том числе одна из них была с rsync. Строка выглядела примерно так:
Я тут раскрыл все переменные, чтобы было понятно, о чём идёт речь, кроме одной -
То есть просто указал на файл, который лежит тут же в директории. Когда отлаживаешь и запускаешь вручную - всё работает. А через cron - нет. А так как в скрипте было много различных действий, я сходу не смог понять, почему не работает конкретно эта синхронизация. Несколько раз глазами пробежал, не пойму, где ошибка и почему всё работает, а конкретно это не синхронизируется. Вывод rsync направлен в лог, обычно там его ошибки видно, но не в этот раз. Он просто не запускался.
Потом заглянул в системную почту, и там всё понятно:
Rsync просто даже не запускался из-за того, что не видел этот файл. В общем, очередное напоминание, что в скриптах лучше всегда всё писать с полными путями, чтобы потом не тратить время на отладку.
Кто-то может подсказать, как сделать так, чтобы в скрипте был относительный путь на файл, лежащий в этой же директории, и чтобы он корректно работал в cron. Я не могу сообразить, как это сделать. Всегда в списке переменных в самом начале пишу актуальные пути под конкретный сервер, чтобы потом с этим не разбираться.
#linux #cron
Делал большой скрипт, где было много разных операций, в том числе одна из них была с rsync. Строка выглядела примерно так:
/usr/bin/rsync --progress -av --delete --delete-excluded --exclude-from=$EXCLUDE_LST -e "ssh -p 31008" user@1.2.3.4:/home/bitrix/ext_www/site01 /mnt/backups/site01/www --backup --backup-dir=/mnt/backups/site01/www_increment/`date +%Y-%m-%d`/`date +%H-%M-%S` 2>&1 >> /mnt/backups/site01/log.txtЯ тут раскрыл все переменные, чтобы было понятно, о чём идёт речь, кроме одной -
$EXCLUDE_LST. Это файл со списком исключений. Задал его вот так:EXCLUDE_LST=exclude-site01.lstТо есть просто указал на файл, который лежит тут же в директории. Когда отлаживаешь и запускаешь вручную - всё работает. А через cron - нет. А так как в скрипте было много различных действий, я сходу не смог понять, почему не работает конкретно эта синхронизация. Несколько раз глазами пробежал, не пойму, где ошибка и почему всё работает, а конкретно это не синхронизируется. Вывод rsync направлен в лог, обычно там его ошибки видно, но не в этот раз. Он просто не запускался.
Потом заглянул в системную почту, и там всё понятно:
rsync: [client] failed to open exclude file exclude-site01.lst: No such file or directory (2)rsync error: error in file IO (code 11) at exclude.c(1481) [client=3.2.7]Rsync просто даже не запускался из-за того, что не видел этот файл. В общем, очередное напоминание, что в скриптах лучше всегда всё писать с полными путями, чтобы потом не тратить время на отладку.
Кто-то может подсказать, как сделать так, чтобы в скрипте был относительный путь на файл, лежащий в этой же директории, и чтобы он корректно работал в cron. Я не могу сообразить, как это сделать. Всегда в списке переменных в самом начале пишу актуальные пути под конкретный сервер, чтобы потом с этим не разбираться.
#linux #cron
Уже не первый раз сталкиваюсь с ситуацией, что получаешь арендную VPS, а там по умолчанию уже настроены сетевые интерфейсы и ipv4, и ipv6. Делаешь обновление системы через apt, он подключается по ipv6 и ничего не качает, пишет, что no longer has a Release file. Столкнулся вчера лично с репозиторием от Яндекса:
В рунете он популярен. Я и сам всегда его использую. Не знаю, кто тут виноват, сам провайдер или Яндекс (позже выяснилось, что Яндекс, подробности в конце). Не вижу смысла разбираться и тратить время. В данном случае проще отключить ipv6. Это можно сделать разными способами. Можно конкретно apt заставить работать через ipv4. У него есть параметр для этого:
Постоянно так писать не будешь, можно добавить в конфигурацию, создав файл
Я лично поступил проще. Отключил ipv6 на уровне системы. Добавил в
И применил их:
Настройки ipv6 на сетевом интерфейсе сразу пропали, apt успешно заработал по ipv4.
Более радикальный способ отключения через GRUB, но тогда придётся обновлять загрузчик, пересобирать initramfs. Плюс, понадобится перезагрузка. Для этого в его конфиг
После этого нужно обновить загрузчик. В зависимости от системы выглядеть это может по-разному. В Debian можно так:
Заметил ещё такую особенность. До того, как отключил ipv6, заметил, что apt работает то по ipv4, то по ipv6. Можно было несколько раз его запустить и получить желаемый результат. Не знаю, с чем это может быть связано. Возможно первый резолв доменного имени идёт на DNS запись AAAA, а если подключение неудачно, то потом на A. Но не уверен, что это так. Просто догадки.
Уже после написания заметки решил повнимательнее разобраться, что реально происходит в apt при обращении по ipv6 и ipv4. Для этого сделал два отдельных запроса по разным протоколам:
Первый нормально отрабатывает и загружает файл InRelease. А во втором случае репозиторий Яндекса отвечает:
То есть DNS запись для mirror.yandex.ru есть:
Но Nginx, который раздаёт контент, не настроен для работы по ipv6. Не знаю, зачем так сделали. Если не настроили Nginx, зачем настроили ipv6? 🤷♂️ Может какие-то временные проблемы.
☝️В целом, с ipv6 такое бывает, поэтому если не используете, лучше сразу отключить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network #ipv6
http://mirror.yandex.ru/debian bookworm mainВ рунете он популярен. Я и сам всегда его использую. Не знаю, кто тут виноват, сам провайдер или Яндекс (позже выяснилось, что Яндекс, подробности в конце). Не вижу смысла разбираться и тратить время. В данном случае проще отключить ipv6. Это можно сделать разными способами. Можно конкретно apt заставить работать через ipv4. У него есть параметр для этого:
# apt -o Acquire::ForceIPv4=true upgradeПостоянно так писать не будешь, можно добавить в конфигурацию, создав файл
/etc/apt/apt.conf.d/disable-ipv6 следующего содержания:Acquire::ForceIPv4 "true";Я лично поступил проще. Отключил ipv6 на уровне системы. Добавил в
/etc/sysctl.conf пару параметров:net.ipv6.conf.all.disable_ipv6 = 1net.ipv6.conf.default.disable_ipv6 = 1И применил их:
# sysctl -pНастройки ipv6 на сетевом интерфейсе сразу пропали, apt успешно заработал по ipv4.
Более радикальный способ отключения через GRUB, но тогда придётся обновлять загрузчик, пересобирать initramfs. Плюс, понадобится перезагрузка. Для этого в его конфиг
/etc/default/grub, конкретно в параметр GRUB_CMDLINE_LINUX, нужно добавить значение ipv6.disable=1. Если там уже указаны другие значения, то перечислены они должны быть через пробел. Примерно так:GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet ipv6.disable=1"После этого нужно обновить загрузчик. В зависимости от системы выглядеть это может по-разному. В Debian можно так:
# dpkg-reconfigure grub-pcЗаметил ещё такую особенность. До того, как отключил ipv6, заметил, что apt работает то по ipv4, то по ipv6. Можно было несколько раз его запустить и получить желаемый результат. Не знаю, с чем это может быть связано. Возможно первый резолв доменного имени идёт на DNS запись AAAA, а если подключение неудачно, то потом на A. Но не уверен, что это так. Просто догадки.
Уже после написания заметки решил повнимательнее разобраться, что реально происходит в apt при обращении по ipv6 и ipv4. Для этого сделал два отдельных запроса по разным протоколам:
# apt -o Debug::Acquire::http=true -o Acquire::ForceIPv4=true update# apt -o Debug::Acquire::http=true -o Acquire::ForceIPv6=true updateПервый нормально отрабатывает и загружает файл InRelease. А во втором случае репозиторий Яндекса отвечает:
Answer for: http://mirror.yandex.ru/debian/dists/bookworm/InReleaseHTTP/1.1 404 Not FoundServer: nginx/1.24.0 (Ubuntu)............................................................Err:2 http://mirror.yandex.ru/debian bookworm Release 404 Not Found [IP: 2a02:6b8::183 80]То есть DNS запись для mirror.yandex.ru есть:
# dig +short mirror.yandex.ru AAAA2a02:6b8::183Но Nginx, который раздаёт контент, не настроен для работы по ipv6. Не знаю, зачем так сделали. Если не настроили Nginx, зачем настроили ipv6? 🤷♂️ Может какие-то временные проблемы.
☝️В целом, с ipv6 такое бывает, поэтому если не используете, лучше сразу отключить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network #ipv6
В репозиториях Debian живёт полезная утилита debootstrap, с помощью которой можно собрать работающую систему в каталоге в уже запущенной ОС. Либо взять уже готовую. Применений у этой технологии может быть много.
Например, можно создать диск в оперативной памяти, установить туда систему через debootstrap, сделать туда chroot, туда же для надёжности можно установить openssh-server и подключиться напрямую. И уже из этой системы делать с работающей всё, что угодно. Можно полностью очистить жёсткий диск перед окончанием аренды виртуалки. Можно поверх работающей системы установить совершенно другую, которую не поддерживает панель управления хостера.
Покажу на практике, как это работает. Ставим debootstrap и сразу с его помощью скачиваем образ системы Debian 12 в каталог /mnt/debootstrap:
Монтируем туда из работающей системы оборудование:
И заходим туда:
Мы оказываемся в чистой минимальной системе на базе Debinan 12 Bookworm. Можем делать в ней всё, что угодно. Зададим пароль root, установим некоторый софт:
Разрешим подключаться пользователю root по ssh сразу внутрь изоляции:
Закрываем, сохраняем, перезапускаем openssh сервер:
Выходим из chroot:
Теперь туда можно подключиться напрямую по SSH, как на любой другой сервер:
Вы оказались в вашей новой системе. Можете там делать, что угодно.
Теперь представим, что вам нужно гарантированно очистить содержимое дисков работающей системы. Для этого создаём в оперативной памяти раздел на 2GB. Можно и меньше, если памяти совсем мало, так как минимальный образ для debootstrap меньше 1GB:
Копируем туда подготовленную ранее систему:
Монтируем оборудование и подключаемся:
Запускаем ssh-сервер и подключаемся напрямую:
Теперь можем делать с системой всё, что угодно. Например, полностью очистить содержимое диска, в том числе корневого раздела основной системы. Смотрим список разделов:
У меня один диск и три раздела: sda1, sda2, sda5. Полностью очищаем все из них. После этого восстановить информацию будет невозможно:
Всё, систем надёжно убита. Можно так делать после того, как отказались от аренды. Особенно если у вас там какие-то впны были настроены или использовались другие учётные данные, которые могли остаться где-то в системе.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Например, можно создать диск в оперативной памяти, установить туда систему через debootstrap, сделать туда chroot, туда же для надёжности можно установить openssh-server и подключиться напрямую. И уже из этой системы делать с работающей всё, что угодно. Можно полностью очистить жёсткий диск перед окончанием аренды виртуалки. Можно поверх работающей системы установить совершенно другую, которую не поддерживает панель управления хостера.
Покажу на практике, как это работает. Ставим debootstrap и сразу с его помощью скачиваем образ системы Debian 12 в каталог /mnt/debootstrap:
# apt install debootstrap# mkdir /mnt/debootstrap# debootstrap bookworm /mnt/debootstrap http://deb.debian.org/debianМонтируем туда из работающей системы оборудование:
# mount --bind /dev /mnt/debootstrap/dev# mount --bind /dev/pts /mnt/debootstrap/dev/pts# mount --bind /proc /mnt/debootstrap/proc# mount --bind /sys /mnt/debootstrap/sysИ заходим туда:
# chroot /mnt/debootstrapМы оказываемся в чистой минимальной системе на базе Debinan 12 Bookworm. Можем делать в ней всё, что угодно. Зададим пароль root, установим некоторый софт:
# passwd# apt install tmux openssh-serverРазрешим подключаться пользователю root по ssh сразу внутрь изоляции:
# nano /etc/ssh/sshd_configPort 222PermitRootLogin yesЗакрываем, сохраняем, перезапускаем openssh сервер:
# /etc/init.d/ssh restartВыходим из chroot:
# exitТеперь туда можно подключиться напрямую по SSH, как на любой другой сервер:
$ ssh -p 222 root@10.20.1.9Вы оказались в вашей новой системе. Можете там делать, что угодно.
Теперь представим, что вам нужно гарантированно очистить содержимое дисков работающей системы. Для этого создаём в оперативной памяти раздел на 2GB. Можно и меньше, если памяти совсем мало, так как минимальный образ для debootstrap меньше 1GB:
# mkdir /mnt/chroot# mount -t tmpfs -o size=2G tmpfs /mnt/chrootКопируем туда подготовленную ранее систему:
# cp -R /mnt/debootstrap/* /mnt/chrootМонтируем оборудование и подключаемся:
# mount --bind /dev /mnt/chroot/dev# mount --bind /dev/pts /mnt/chroot/dev/pts# mount --bind /proc /mnt/chroot/proc# mount --bind /sys /mnt/chroot/sys# chroot /mnt/chrootЗапускаем ssh-сервер и подключаемся напрямую:
# /etc/init.d/ssh start# exit$ ssh -p 222 root@10.20.1.9Теперь можем делать с системой всё, что угодно. Например, полностью очистить содержимое диска, в том числе корневого раздела основной системы. Смотрим список разделов:
# fdisk -lУ меня один диск и три раздела: sda1, sda2, sda5. Полностью очищаем все из них. После этого восстановить информацию будет невозможно:
# shred -u -z -v /dev/sda{1,2,5}Всё, систем надёжно убита. Можно так делать после того, как отказались от аренды. Особенно если у вас там какие-то впны были настроены или использовались другие учётные данные, которые могли остаться где-то в системе.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Почти всегда, когда надо скопировать файлы с сервера на сервер, использую либо scp, либо rsync. Первый для одиночных файлов, второй для директорий. На прошлой неделе нужно было с одного старого сервера перенести выборочно кучу разрозненных файлов на другой. Вспомнил про возможность Midnight Commander, где одной из панелей с обзором файлов может выступать удалённый сервер. Это очень удобно как раз для моей задачи. Я очень редко этим пользуюсь. Даже не знаю, почему. Нет такой привычки. Хотя объективно это удобнее, чем ходить по каталогам и запускать rsync, вспоминая его ключи, особенно если надо использовать нестандартный порт SSH.
MC поддерживает два разных протокола для передачи - SFTP (SSH File Transfer Protocol) или FISH (Files transferred over Shell protocol). Последний в разделе меню называется как Shell link. По названию не совсем понятно, что это такое. На первый взгляд кажется, что в контексте передачи файлов это одно и то же. Но на деле нет. И я как раз столкнулся лично с различиями.
Сервер, с которого я подключался, был старее того, куда надо было копировать. Там вроде бы Debian 11 стоял, я копировал на 12-й. К сожалению, не могу уточнить, сервер удалён уже, а сразу не было времени подробно разбираться. Сначала использовал sftp и ни в какую не мог подключиться. Постоянно в логе принимающего севера были ошибки в auth.log на тему то ли использовавшихся шифров, то ли формата сертификата. Сразу не записал, только пометил себе сделать об этом заметку.
При этом я спокойно подключался из консоли по ssh к удалённому серверу с тем же сертификатом или паролем. Попробовал в MC подключение по Shell link и сразу подключился. Перекинул файлы и разбираться уже не стал. Позже пробовал с разными серверами использовать разные протоколы - везде работали оба.
В целом, разница понятна, так как протоколы передачи совершенно разные. Лучше использовать более привычный и распространённый sftp, если он разрешён и настроен на принимающем сервере. Это не всегда бывает так. Как и обратная ситуация. Может быть разрешён sftp, но запрещён обычный shell. А подключению по fish как раз нужен хотя бы sh на принимающей стороне. Так что если не подключается один протокол, пробуйте другой.
☝️ Отдельно отмечу такую фишку MC. Вы можете в левой панели открыть один удалённый сервер, а в правой - другой. И не настраивая прямого соединения между этими серверами перекинуть файлы, выступая со своим MC как посредник.
Настраиваются такие подключения так: нажимаем F9 -> Right или Left, то есть выбираем нужную нам панель, потом раздел меню Shell link или SFTP link. Формат подключения типичный для ssh -
На подобные заметки постоянно приходят комментаторы и начинают рассказывать, что использовать панельные менеджеры - плохая практика, надо работать в консоли, это быстрее, удобнее и т.д. Давайте воздержимся от этих бессмысленных споров. Пусть каждый работает так, как ему удобно. Мне удобно работать с MC, я к нему привык. И mcedit его люблю.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #mc
MC поддерживает два разных протокола для передачи - SFTP (SSH File Transfer Protocol) или FISH (Files transferred over Shell protocol). Последний в разделе меню называется как Shell link. По названию не совсем понятно, что это такое. На первый взгляд кажется, что в контексте передачи файлов это одно и то же. Но на деле нет. И я как раз столкнулся лично с различиями.
Сервер, с которого я подключался, был старее того, куда надо было копировать. Там вроде бы Debian 11 стоял, я копировал на 12-й. К сожалению, не могу уточнить, сервер удалён уже, а сразу не было времени подробно разбираться. Сначала использовал sftp и ни в какую не мог подключиться. Постоянно в логе принимающего севера были ошибки в auth.log на тему то ли использовавшихся шифров, то ли формата сертификата. Сразу не записал, только пометил себе сделать об этом заметку.
При этом я спокойно подключался из консоли по ssh к удалённому серверу с тем же сертификатом или паролем. Попробовал в MC подключение по Shell link и сразу подключился. Перекинул файлы и разбираться уже не стал. Позже пробовал с разными серверами использовать разные протоколы - везде работали оба.
В целом, разница понятна, так как протоколы передачи совершенно разные. Лучше использовать более привычный и распространённый sftp, если он разрешён и настроен на принимающем сервере. Это не всегда бывает так. Как и обратная ситуация. Может быть разрешён sftp, но запрещён обычный shell. А подключению по fish как раз нужен хотя бы sh на принимающей стороне. Так что если не подключается один протокол, пробуйте другой.
☝️ Отдельно отмечу такую фишку MC. Вы можете в левой панели открыть один удалённый сервер, а в правой - другой. И не настраивая прямого соединения между этими серверами перекинуть файлы, выступая со своим MC как посредник.
Настраиваются такие подключения так: нажимаем F9 -> Right или Left, то есть выбираем нужную нам панель, потом раздел меню Shell link или SFTP link. Формат подключения типичный для ssh -
root@10.20.1.23/mnt/backup. Если аутентификация по ключу настроена, то сразу подключитесь. Если нет - выскочит окно для ввода пароля. Если надо задать пароль или использовать нестандартный порт, то по F1 открывается подсказка, там показаны все варианты.На подобные заметки постоянно приходят комментаторы и начинают рассказывать, что использовать панельные менеджеры - плохая практика, надо работать в консоли, это быстрее, удобнее и т.д. Давайте воздержимся от этих бессмысленных споров. Пусть каждый работает так, как ему удобно. Мне удобно работать с MC, я к нему привык. И mcedit его люблю.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #mc
Раз уж начал вчера тему про MC (Midnight Commander), разовью её и перечислю основную функциональность этого файлового менеджера, которой лично я постоянно пользуюсь. Может кто-то найдёт для себя что-то новое.
1️⃣ Закладки. Комбинация Ctrl-\. Практически всегда начинаю работу в MC с открытия закладок. У меня там стандартно есть
2️⃣ Поиск файла. Комбинация Ctrl-s. После выбора закладки и перехода в нужный каталог сразу же запускаю поиск по файлу и начинаю его набирать. Например, перехожу в
3️⃣ Подсветка синтаксиса. Комбинация в mcedit Ctrl-s. После открытия файла включаю или отключаю подсветку синтаксиса, в зависимости то того, что хочу сделать. Если это огромный лог файл, то из-за подсветки будет тормозить просмотр, лучше сразу убрать её. Для того, чтобы стандартная подсветка для sh скриптов действовала на все файлы, даже без расширения, делаю вот так:
Копирую подсветку sh на все неопознанные файлы. Обычно это различные конфиги или логи и там как раз sh подсветка будет актуальной.
4️⃣ Cвернуть окно. Комбинация Ctrl-o. Обычно всегда сворачиваю MC, а не закрываю. Так и работаю, перемещаясь то в консоль, то в MC. Использовать его консоль для выполнения команд не люблю.
5️⃣ Создание, копирование или переименование файла. Комбинации Shift-F4, Shift-F5 и Shift-F6. Можно сделать копию файла с другим именем. Удобно, если руками правишь конфиги. Тут же копируешь старый с добавлением
6️⃣ Обновить содержимое каталога. Комбинация Ctrl-r. Не так давно узнал случайно про эту комбинацию. Пользуюсь постоянно. До этого выходил и возвращался в каталог для обновления списка файлов.
7️⃣ Выбор или отмена выбора. На цифровой панели + или -. Выбрать файлы по маске или отменить выбор. Если цифровой панели нет, то Shift-+ (шифт и потом плюс). Чаще всего приходится выбирать все файлы, для этого используется маска *, либо сразу комбинация Shift-*. Она выделяет все файлы в каталоге.
8️⃣ Расширенный Chown. Комбинации клавиш для него нет. Нажимаю F9 ⇨ File ⇨ A. Открывается Advanced chown. Я работаю в нём вместо отдельных chmod и chown.
9️⃣ Поменять местами панели. Комбинация Сtrl-u.
🔟 Посмотреть размер каталога. Комбинация Ctrl-space. Если каталоги жирные, подсчёт идёт долго, то я сразу по списку каталогов иду, не отпуская Ctrl, нажимая пробел. После каждого нажатия происходит автоматический переход на новый каталог. Так всё прокликав можно быстро либо очень большой каталог найти, либо пустой. Либо можно сначала выделить все каталоги и нажать Ctrl-space.
⏸️ Подстановка имени в консоль. Комбинация Esc-enter. Переходим к файлу, подставляем его имя в консоль, сворачиваем MC и потом в консоли работаем с выбранным файлом.
Есть ещё куча всяких комбинаций клавиш, но я даже не вспомню их, так что не использую, не считая однокнопочных, типа копирования или перемещения файлов. А эти уже на автомате вылетают. Так что когда мне кто-то говорит, что в консоли удобнее и быстрее, мне этого не понять. Что-то может и удобнее, а что-то явно нет.
Ещё некоторые моменты. Чтобы быстро получить путь каталога в буфер обмена, в котором я нахожусь в MC, сворачиваю его, пишу
MC можно запустить с разными темами. Бывает актуально, если какой-то цвет совсем нечитаем в текущей гамме. Можно чёрно-белый режим открыть, или какую-то тему выбрать:
Последняя вообще прикольная тема. Я иногда её на постоянку ставлю для выделения сервера. Обычно на какие-то свои.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #termianl #mc
/etc и /var/log, а дальше уже в зависимости от назначения сервера - каталог с бэкапами, каталог веб сервера, вольюмы контейнеров и т.д./var/log, нажимаю поиск и начинаю набирать syslog. Сразу же попадаю на нужный файл, набрав только sy.# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntaxКопирую подсветку sh на все неопознанные файлы. Обычно это различные конфиги или логи и там как раз sh подсветка будет актуальной.
.old. Либо переименовываешь текущий конфиг, чтобы отключить его. Например, добавляя к site.conf расширение .disabled. Я обычно так отключаю конфиги, не удаляю.🔟 Посмотреть размер каталога. Комбинация Ctrl-space. Если каталоги жирные, подсчёт идёт долго, то я сразу по списку каталогов иду, не отпуская Ctrl, нажимая пробел. После каждого нажатия происходит автоматический переход на новый каталог. Так всё прокликав можно быстро либо очень большой каталог найти, либо пустой. Либо можно сначала выделить все каталоги и нажать Ctrl-space.
⏸️ Подстановка имени в консоль. Комбинация Esc-enter. Переходим к файлу, подставляем его имя в консоль, сворачиваем MC и потом в консоли работаем с выбранным файлом.
Есть ещё куча всяких комбинаций клавиш, но я даже не вспомню их, так что не использую, не считая однокнопочных, типа копирования или перемещения файлов. А эти уже на автомате вылетают. Так что когда мне кто-то говорит, что в консоли удобнее и быстрее, мне этого не понять. Что-то может и удобнее, а что-то явно нет.
Ещё некоторые моменты. Чтобы быстро получить путь каталога в буфер обмена, в котором я нахожусь в MC, сворачиваю его, пишу
pwd и выделяю.MC можно запустить с разными темами. Бывает актуально, если какой-то цвет совсем нечитаем в текущей гамме. Можно чёрно-белый режим открыть, или какую-то тему выбрать:
# mc -b# mc -S darkfarПоследняя вообще прикольная тема. Я иногда её на постоянку ставлю для выделения сервера. Обычно на какие-то свои.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #termianl #mc
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда гуглишь какие-то ошибки по Linux и сопутствующему ПО, очень часто попадаешь на сайт access.redhat.com, где есть решения. Но проблема в том, что без подписки ты не можешь посмотреть ответ, только текст ошибки. Это раздражает и расстраивает.
Раньше это не представляло большой проблемы, так как достаточно бесплатной подписки Red Hat Developer Subscription for Individuals. Я даже статью делал о том, как её получить. Не пользовался никакими возможностями этой подписки, кроме доступа к порталу со статьями.
Проблема в том, что подписку надо продлевать каждый год. После 2022 года из-за экспортных ограничений, которые ввело правительство США, сделать это стало невозможно. А если быть точным, то как раньше стало невозможно, но в целом возможно и я расскажу, как это сделать.
У меня уже была учётка в RedHat, поэтому расскажу, как сделать с уже существующей. Если будете делать новую, то сразу вводите те данные, что я расскажу.
Я включил VPN из США, залогинился в учётную запись и поменял адрес с телефоном. Просто открыл карту США и вбил первый попавшийся адрес с номером телефона. Мне пришло подтверждение моего почтового адреса на email. Подтвердил его. Без этого меня не пускали в новый ЛК, ссылаясь на ограничения.
После этого пошёл по адресу developers.redhat.com/register, но не стал регистрировать, а вместо этого справа вверху нажал Login и зашёл под своей учёткой. У меня открылась форма регистрации с уже заполненными из профиля полями. И в конце не был отмечен чекбокс I have read and agree to the Red Hat Developer Subscriptions for Individuals. Отметил его и завершил регистрацию.
Собственно, всё. После этого в личном кабинете у меня появилась свежая подписка Red Hat Developer Subscription for Individuals. Далее я прошёл в их новую консоль для управления всем и вся console.redhat.com. Там уже не помню, что конкретно сделал, но подписка активировалась и добавилась ещё одна - Red Hat Beta Access.
Сначала доступ к материалам не открылся. Я расстроился. Несколько раз выходил и заходил снова в учётку, чистил кэш и куки. Почему-то ничего не помогало. В итоге открыл браузер в инкогнито, ещё раз залогинился и все материалы открылись.
С этой подпиской вам дают 16 лицензий на использование ОС RHEL. Мне и даром это не нужно. Подписку сделал исключительно, чтобы в гугле в результатах поиска иметь возможность прочитать материал. Несмотря на все ИИ, материалы с access.redhat.com представляют определённую ценность. Не раз там находил решения своих проблем, поэтому всегда старался настроить подписку.
Нигде не видел информации о том, как получить сейчас эту подписку. Интуитивно сделал всё сам, пробуя разные варианты. За пару часов разобрался.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Раньше это не представляло большой проблемы, так как достаточно бесплатной подписки Red Hat Developer Subscription for Individuals. Я даже статью делал о том, как её получить. Не пользовался никакими возможностями этой подписки, кроме доступа к порталу со статьями.
Проблема в том, что подписку надо продлевать каждый год. После 2022 года из-за экспортных ограничений, которые ввело правительство США, сделать это стало невозможно. А если быть точным, то как раньше стало невозможно, но в целом возможно и я расскажу, как это сделать.
У меня уже была учётка в RedHat, поэтому расскажу, как сделать с уже существующей. Если будете делать новую, то сразу вводите те данные, что я расскажу.
Я включил VPN из США, залогинился в учётную запись и поменял адрес с телефоном. Просто открыл карту США и вбил первый попавшийся адрес с номером телефона. Мне пришло подтверждение моего почтового адреса на email. Подтвердил его. Без этого меня не пускали в новый ЛК, ссылаясь на ограничения.
После этого пошёл по адресу developers.redhat.com/register, но не стал регистрировать, а вместо этого справа вверху нажал Login и зашёл под своей учёткой. У меня открылась форма регистрации с уже заполненными из профиля полями. И в конце не был отмечен чекбокс I have read and agree to the Red Hat Developer Subscriptions for Individuals. Отметил его и завершил регистрацию.
Собственно, всё. После этого в личном кабинете у меня появилась свежая подписка Red Hat Developer Subscription for Individuals. Далее я прошёл в их новую консоль для управления всем и вся console.redhat.com. Там уже не помню, что конкретно сделал, но подписка активировалась и добавилась ещё одна - Red Hat Beta Access.
Сначала доступ к материалам не открылся. Я расстроился. Несколько раз выходил и заходил снова в учётку, чистил кэш и куки. Почему-то ничего не помогало. В итоге открыл браузер в инкогнито, ещё раз залогинился и все материалы открылись.
С этой подпиской вам дают 16 лицензий на использование ОС RHEL. Мне и даром это не нужно. Подписку сделал исключительно, чтобы в гугле в результатах поиска иметь возможность прочитать материал. Несмотря на все ИИ, материалы с access.redhat.com представляют определённую ценность. Не раз там находил решения своих проблем, поэтому всегда старался настроить подписку.
Нигде не видел информации о том, как получить сейчас эту подписку. Интуитивно сделал всё сам, пробуя разные варианты. За пару часов разобрался.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux