Столкнулся на днях с ошибкой, которую уже давно не видел. Минут 10 потратил, пока не понял, в чём проблема. Давно работает один LXC контейнер с Debian внутри. У меня давняя привычка везде и всюду использовать названия только на английском языке и никогда не ставить пробелы, заменяя их тире или подчёркиванием. И вам того же советую во избежание траты времени на поиск внезапных ошибок или проблем с отладкой.

Закинул туда скрипт с комментариями на русском языке, которые иногда оставляю в начале. Вместо русских букв местами получил крякозябры. Первое, на что посмотрел - кодировка исходного текста. На всякий случай сохранил его в VSCode, убедился, что там UTF-8 и скопировал ещё раз. Не помогло.

Подумал, может это в mcedit проблема. Открыл скрипт в nano - там то же самое. На всякий случай скопировал по scp этот же скрипт, чтобы исключить проблемы, связанные с буфером обмена. То же самое. Копирую на другой сервер, там всё нормально.

Дальше понял, что надо локали в терминале смотреть:

# locale
LANG=C
........

Если честно, даже не знаю, что это за локаль C. Пока нигде не было русского языка, проблем не замечал. Обычно тут по умолчанию стоит en_US.UTF-8. Если и надо поменять локаль, то на ru_RU.UTF-8, чтобы нормально 1С сервер работал. Больше не знаю ситуаций, где бы стоило менять её с английской.

Меняю локаль на английскую:

# locale-gen en_US.UTF-8
# update-locale en_US.UTF-8

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

# dpkg-reconfigure locales

Чтобы новая локально заработала, нужно перезайти пользователем в терминал. Перезагружаться не обязательно.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#linux #terminal

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

Приведу примеры централизованной записи команд, о которых я рассказывал ранее:

◽️sshlog - запись вводимых команд и вывода, централизованный сбор логов с записями сессий, уведомления о каких-то событиях в консоли и многое другое.
◽️tlog - централизованная система сбора пользовательской активности в консоли от RedHat.
◽️snoopy - небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов. 
◽️log-user-session - программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл. 
◽️PROMPT_COMMAND - логирование в текстовый файл с помощью встроенной возможности оболочки bash.

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

После подключения к серверу запустите её и направьте вывод в лог-файл:

# script -q -f ~/terminal_$(date +%F_%T).log

Теперь всё, что вы введёте в консоль, будет записано в файл. Для удобства сразу дату туда добавил. Для того, чтобы прекратить запись, достаточно ввести команду exit в терминале, и script завершит свою работу.

В лог попадёт некоторый "мусор", который затрудняет восприятие вывода. Это связано с тем, что script записывает сырой поток команд, который включает в себя некоторые закодированные ASCII последовательности, например, описывающие цветной вывод или команды терминала, типа возврата каретки и т.д.

Это всё можно разом очистить. Например, так:

# sed -i 's/\x1B\[[0-9;?]*[A-Za-z]//g; s/\x1B\][0-9;]*.*(\x07|\x1B\\)//g;' terminal_2025-10-12_22:42:54.log

\x1B\[[0-9;?]*[A-Za-z] - убрали управляющие последовательности (цвета, курсор и bracketed paste);

\x1B\][0-9;]*.*(\x07|\x1B\\) - убрали OSC-последовательности ESC ] 0; title ESC \ и некоторые другие;

\r - убрали возврат каретки (^M);

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

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

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#linux #terminal #ssh

Я всегда без исключения в Linux использую swap в виде отдельного файла, а не раздела. Причина очень простая - это намного удобнее. Из глубины веков тянется шлейф убеждений, что отдельный раздел работает быстрее, чем файл. Теоретически - да, практически не понятно.

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

Swap в 1 ГБ добавляю так:

# dd if=/dev/zero of=/swap bs=1024 count=1000000
# mkswap /swap
# chmod 0600 /swap
# swapon /swap

Если всё ок, то добавляю в /etc/fstab:

/swap swap swap defaults 0 0

Отдельно отмечу, что не рекомендуется создавать пустой файл с помощью truncate или fallocate:

# truncate -s 1G /swap
# fallocate -l 1G /swap

Он создастся мгновенно, в отличие от dd, которая явно пишет туда нули. Не помню, в какой документации читал, но запомнил, что swap лучше нулями сразу записать, а не создавать пустым.

Если swap уже настроен в виде раздела, то трогать уже не буду, если только это не пустая виртуалка. Иногда попадаются виртуалки с lvm, где swap в виде отдельного lv раздела. Это стандартная схема установки в Debian. В этом случае его можно удалить, объединить с основным, а swap сделать в виде файла.

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

Последовательность действий тут такая. Смотрим список разделов:

# lvs
root   web-01-vg -wi-ao---- <27.51g
swap_1 web-01-vg -wi-ao---- <1.54g

Небольшая виртуалка с диском на 30 ГБ, где 1,5 отдано под swap. Уберём этот раздел и объединим с основным. Отключаем этот swap:

# swapoff -a

И сразу же проверьте файл /etc/fstab. Там нужно удалить строку с подключением этого раздела. Выглядит примерно так:

/dev/mapper/web--01--vg-swap_1 none      swap  sw       0    0

Закомментируйте её. Удаляем раздел со свапом:

# lvremove /dev/web-01-vg/swap_1
Do you really want to remove active logical volume web-01-vg/swap_1? [y/n]: y
 Logical volume "swap_1" successfully removed.

Расширяем корневой раздел:

# lvextend -l +100%FREE /dev/web-01-vg/root
 Size of logical volume web-01-vg/root changed from <27.51 GiB (7042 extents) to 29.04 GiB (7435 extents).
 Logical volume web-01-vg/root successfully resized.

И растягиваем файловую систему на весь раздел, так как увеличение раздела не подразумевает её автоматическое увеличение. Она ничего не знает об увеличенном разделе, если ей об этом не сказать.

# resize2fs /dev/web-01-vg/root
resize2fs 1.47.2 (1-Jan-2025)
Filesystem at /dev/web-01-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 4
The filesystem on /dev/web-01-vg/root is now 7613440 (4k) blocks long.

Проверяем, что получилось:

# df -h | grep root
/dev/mapper/web--01--vg-root  29G 4.7G  23G 18% /

Раздел стал 29G против предыдущих 27.5G. Дальше можно добавлять swap в виде файла, как я показал в начале. И обязательно, когда всё закончите, перезагрузите виртуалку и убедитесь, что всё в порядке. Все эти операции не требуют перезагрузки, но если где-то ошиблись, особенно в fstab, можете получить проблемы во время загрузки. По горячим следам это легко исправить, а если reboot случится через полгода и система не загрузится, можно сразу не сообразить, из-за чего это.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#linux #terminal #совет