Настраиваем цвета строки приглашения Bash

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

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

За формат строки приглашения отвечает переменная окружения PS1 и по умолчанию она имеет значение:

PS1='\u@\h:\w\$ '

Где u – имя пользователя, h – имя хоста, w – текущий путь, а $ - символ приглашения.

В результате строка будет выглядеть так:

user@host:/home/user$

Для изменения внешнего вида нам доступны три параметра: формат символов, цвет текста и цвет фона.

Формат может принимать три значения:

▫️Нормальный текст – 0
▫️Жирный текст – 1
▫️Подчеркнутый текст – 4

Цвета текста / фона:

▫️Черный 30/40
▫️Красный 31/41
▫️Зеленый 32/42
▫️Желтый 33/43
▫️Голубой 34/44
▫️Фиолетовый 35/45
▫️Бирюзовый 36/46
▫️Белый 37/47

Для того чтобы задать цвет отдельных элементов применяется специальное форматирование, использующее символы \e в начале и m в конце.

Например, выделим имя пользователя и хост зеленым цветом, а путь сделаем синим, при этом двоеточие и символ приглашение раскрашивать не будем:

PS1='\[\e[01;32m\]\u@\h\[\e[m\]:\[\e[01;34m\]\w\[\e[m\]\$ '

Сам цвет задает конструкция:

\[\e[01;32m\] 

Формат текста задает 01, а его цвет – 32, т.е. жирный зеленый. Если мы хотим еще изменить фон, то добавляем туда еще одно значение:

\[\e[01;32;43m\] 

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

Конструкция

\[\e[m\]

Сбрасывает цвет и формат элементов на дефолтные.

Так, например, если мы уберем такую конструкцию перед двоеточием, то оно тоже окрасится в заданный перед этим цвет:

PS1='\[\e[01;32m\]\u@\h:\[\e[01;34m\]\w\[\e[m\]\$ '

Проверить что получилось можно сразу, введя указанную строку в консоль и нажав Enter. Таким образом можно тонко настроить цвета в соответствии со своими потребностями.

Если же вы люто накосячили, то не отчаивайтесь, введите

PS1='\u@\h:\w\$ '

И все снова станет как было. Либо просто выйдите из консоли.

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

Настраиваем DNS-резольвер Unbound для работы с DNS over TLS

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

Поэтому современный DNS также требует TLS-защиты, наиболее просто и прозрачно для администратора использовать DNS over TLS (DoT). Да, эта технология не маскирует себя под HTTPS-трафик, но в большинстве случаев это и не нужно.

Для реализации нашей задумки мы будем использовать популярный DNS-резольвер Unbound, который присутствует в репозиториях всех основных дистрибутивов Linux.

Установить его можно командой:

apt install unbound

Затем откроем основной конфигурационный файл /etc/unbound/unbound.conf и приведем его к следующему виду:

include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

server:
    use-syslog: yes
    username: "unbound"
    directory: "/etc/unbound"
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
    verbosity: 2

    do-ip6: no
    interface: 192.168.100.53
    port: 53
    prefetch: yes

    root-hints: /usr/share/dns/root.hints
    harden-dnssec-stripped: yes

    cache-max-ttl: 86400
    cache-min-ttl: 900

    aggressive-nsec: yes
    hide-identity: yes
    hide-version: yes
    use-caps-for-id: yes

    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8

    #control which clients are allowed to make (recursive) queries
    access-control: 127.0.0.1/32 allow_snoop
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.100.0/24 allow  

    num-threads: 4
    msg-cache-slabs: 8
    rrset-cache-slabs: 8
    infra-cache-slabs: 8
    key-cache-slabs: 8
    rrset-cache-size: 256m
    msg-cache-size: 128m
    so-rcvbuf: 8m

forward-zone:
    name: "."
    forward-ssl-upstream: yes
    forward-addr: 1.1.1.1@853#one.one.one.one
    forward-addr: 1.0.0.1@853#one.one.one.one

forward-zone:
    name: "nalog.ru."
    forward-ssl-upstream: yes
    forward-addr: 77.88.8.8@853#common.dot.dns.yandex.net

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

Мы же разберем настройки непосредственно DoT. Так как Unbound не DNS-сервер, а именно резольвер, то он на все запросы либо отдает данные из кеша, либо запрашивает их у вышестоящих серверов.

Где именно это делать мы указываем в секциях forward-zone, таких секций может быть несколько и тогда Unbound ищет среди низ наиболее точное совпадение.

В нашем примере таких секций две: "." и "nalog.ru." – обратите внимание, что имена зон всегда должны заканчиваться на точку, точка обозначает корень системы DNS.

И именно поэтому в одном из имен зон пересылки у нас стоит точка, это обозначает, что сюда следует посылать все DNS-запросы, которым не нашлось иного совпадения. Вторая зона у на нас отвечает за домен nalog.ru.

В нашем примере для nalog.ru мы используем сервера Яндекс.DNS, для всех остальных запросов будут использоваться Cloudflare DNS.

Опция forward-ssl-upstream: yes включает DoT для указанных зон, ниже перечисляются сервера, к которым следует делать запросы. В записи мы указываем адрес и порт, по умолчанию это 853.

А вот запись после # - это не комментарий, это доменное имя, на которое выписан сертификат сервера. Что позволяет выполнить проверку сертификата на стороне клиента. Даже если кто-то перехватит наш трафик и направит на поддельный DoT-сервер, он не сможет предъявить клиенту валидный сертификат.

Данная часть записи не является обязательной, но крайне желательна, так как защищает от подмены сервера и атак класса MitM. Нужные имена доменов вы можете узнать в документации вашего DNS-провайдера.

Некоторые мысли по поводу организации DNS-трафика в сетях с Mikrotik

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

Сегодня мы рассмотрим один из возможных вариантов в сетях с использованием в качестве шлюза роутеров Mikrotik.

Ой, да что там думать, скажет иной читатель, включаем DoH и понеслась! Но не все так просто. При включении DoH перестают работать записи типа FWD, что во многих случаях неприемлемо, поэтому нужно искать другое решение.

Завернуть DNS-запросы в трубу… Ну такое себе решение, скажем честно. Труба в наше время может отвалиться в любой момент, и тогда вся ваша сеть вообще окажется без DNS.

Поэтому работать надо через основное подключение, но исключительно по защищенным протоколам.

Сегодня в домашней сети был опробован данный вариант и результат его можно считать отличным.

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

Для разрешения запросов мы подняли дополнительный кеширующий DNS-сервер Unbound, но вы можете использовать любое иное решение, главное, чтобы оно умело использовать в качестве апстрима сервера DoT/DoH.

Как вы уже должны были понять, в качестве вышестоящего сервера для Unbound мы использовали один из публичных серверов по протоколу DoT.

Почему DoT, а не DoH? DoT проще в настройке и позволяет четко определять такой трафик, что полезно если вы используете сложные правила фильтрации. С другой стороны, это делает видимым такой трафик для провайдера, но доступа к нему он все равно не имеет.

Смысла прятать факт наличия DNS-трафика в зашифрованном виде особо нет, но если вы хотите скрыть такую активность, то лучше использовать DoH. В общем – на ваш выбор.

После чего в качестве используемого DNS-сервера для Mikrotik указываем адрес нашего Unbound. Для клиентов сети основным DNS как был Mikrotik, так и остался, это нужно для того, чтобы работали FWD записи и разные другие правила.

Этот режим показан на диаграмме зелеными стрелочками. DNS-запрос приходит на Mikrotik и если его не нужно перенаправлять на какой-либо специфический сервер, то он уходит на Unbound, а с него по DoT/DoH на выбранный вышестоящий DNS-сервер.

А что будет, если клиент явно укажет на своем устройстве другие DNS-сервера? Все просто, решаем при помощи правила на Mikrotik:

/ip firewall nat
add action=dst-nat chain=dstnat comment="SAFE DNS" dst-address=!192.168.1.0/24 dst-port=53 protocol=udp to-addresses=192.168.1.53

Где 192.168.1.0/24 – адрес вашей внутренней сети, а 192.168.1.53 – адрес сервера Unbound.

После чего ваш роутер будет перехватывать все транзитные DNS-запросы и отправлять их на ваш Unbound-сервер. Этот режим показан на схеме голубыми стрелочками.

Также для контроля возможной утечки DNS советуем вам на первых порах добавить в брандмауэр, на самый верх, еще два правила:

/ip firewall filter
add action=passthrough chain=output dst-address=!192.168.1.0/24 dst-port=53 log=yes log-prefix=LEAK_DNS protocol=udp
add action=passthrough chain=forward dst-address=!192.168.1.0/24 dst-port=53 log=yes log-prefix=LEAK_DNS protocol=udp

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

Сразу дадим одну наколку, если у вас используются коммутируемые подключения или вы получаете настройки по DHCP – обязательно снимите галочку Use Peer DNS.

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

А можно мы сами?

- А у нас тут 1С не запускается, пишет недостаточно места…

- Значит недостаточно места, надо почистить.

- А если вы подключитесь, то возьмете как за час работы?

- Да, это минимальная такса.

- Но там же просто место почистить.

- Да какая разница, мы тратим свое время. Время – деньги.

- А можно мы сами почистим?

- Можно.

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

Наверное, вы уже догадались, они удалили самую большую папку в корне диска, с простым и понятным названием «СТ», в которой была база 1С. 🤦‍♀️

Сэкономили денег, однако.

Последний бекап от марта месяца. Но документов немного, дня за два-три в пару рук внесут все обратно.

Морали не будет. Каждый сам определяет, что дорого, а что нет. И несет последствия своего выбора.

Не спеши, а то успеешь

В начале нашей заметки я расскажу одну поучительную историю. В студенческие годы физрук подрядил нас почистить от снега спортплощадку. Срок – пара. Ну мы минут за 30 справились, пришли к нему гордые и довольные.

А он отправил нас… обратно снег по спортплощадке разбрасывать. Ну бывший военный, что с него взять. Но, оказалось, в этом действе был заложен глубокий смысл. Который он нам наглядно продемонстрировал.

Любые нормы на чем-то да основаны, проверены временем и т.д. и т.п. Сказали чистить снег пару – значит пару. Это сегодня снега пару сантиметров выпало, и вы за полчаса справились, а завтра его по колено наметет? А норма – штука такая, если ее регулярно перевыполнять, то ее обязательно поднимут (или сократят) и легче никому от этого не станет.

Это правило я тогда запомнил, и оно сильно помогает по жизни. Вот есть работа, которая по нормам занимает два часа, а вы набили руку и делаете ее за час. Не спешите никого радовать. Два часа и точка!

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

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

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

Еще хуже, если это проект с большим количеством этапов. На проекте самой большой ценностью является время. И если у вас указано, что данный этап занимает неделю – занимайтесь неделю, даже если справились за три дня.

Не спешите сдавать этот этап, оставьте эти два дня себе, есть возможность – начните работу над следующим этапом или просто подготовьтесь к нему, что делать – всегда найдется. Но у вас будет запас времени.

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

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

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

А это значит, что можно на эту тему вас прогнуть и на следующий проект установить сроки самостоятельно. Итог – вы в цейтноте и бегаете в мыле по потолку, чтобы успеть выполнить все работы. Оно вам надо?

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

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

Для себя я давно вывел некоторые эмпирические коэффициенты, любые материалы на проекте умножаем на 1,25, а время просто увеличиваем в полтора, а то и два раза. Запас карман не тянет, особенно если это такой ресурс, как время.

Новый формат DEB822 для источников APT

Так уж пошло, что многие привычные вещи воспринимаются нами чем-то незыблемым, а попытка нарушить текущий ход вещей часто воспринимается в штыки. Новый формат источников APT - DEB822 не исключение, он появился начиная с выпуска Debian 13, а пользователи Ubuntu познакомились с ним немного раньше, начиная с Ubuntu 24.04. В данной статье мы подробно разберем новый формат, его основные отличия и преимущества перед привычным старым.

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

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

✅ Читать: https://interface31.ru/post/novyj-format-deb822-dlya-istochnikov-apt/

Их нравы
 
На конференции Linux App Summit Себастьян Вик (Sebastian Wick), мэйнтейнер инструментария Flatpak, и Адриан Вовк (Adrian Vovk), создатель инсталлятора для GNOME OS и один из разработчиков systemd-homed и systemd-sysupdate, выступили с докладом о будущем системы самодостаточных пакетов Flatpak.
 
В докладе упоминалось намерение создать для нужд Flatpak новый процесс systemd-appd для управления правами приложений и вложенной изоляции. Важный нюанс: код ещё не написан, а поддержка пока только задумывалась.
 
Но тут «разверзлись хляби небесные» в социальной сети Fediverse началась волна агрессии. Разработчиков обвинили в «насаждении диктатуры», «предательстве портативности» и «союзничестве с Ландьюком». Критика сыпалась на этапе концепции, без анализа доклада. Аргументы «мы ещё даже код не написали» игнорировались.
 

Брайан Ландьюк (Bryan Lunduke) — известный технический блогер, яростный критик systemd и корпоративного влияния в Linux . В данном контексте обвинение в «союзничестве» с ним используется как токсичный ярлык и обвинение в намеренном вреде проекту ради идеологии.  

 
В результате Адриан Вовк заявил, что до начала этой токсичной кампании он искренне хотел найти элегантное решение для пользователей альтернативных init-систем (например, выделить appd в отдельный демон, как это сделали с elogind). Но после потока неконструктивной агрессии и обвинений у него пропала мотивация тратить личное время и силы на это:
 

Но, честно говоря, всё это обсуждение сейчас совершенно бессмысленно, пока мы не написали ни единой строчки кода. Если быть откровенным, до этой травли в Феди я планировал максимально тактично отнестись к сценарию использования без systemd. Но тут я увидел, как кто-то в открытую обвиняет нас в том, что мы «союзники Ландьюка».

Так что, извините, но у меня больше нет ни малейшего желания тратить своё время на это дерьмо. Оно того не стоит.

 
К чему это привело? Да к тому, что systemd теперь станет обязательной зависимостью Flatpak, альтернативные решения разработчики больше рассматривать не желают.
 
И это не первый случай токсичного поведения меньшинств, которые потом искренне удивляются почему никто не хочет поддерживать их решения и вообще тратить на них время. Многие начинают склоняться к теориям заговора и козням корпораций.
 
На самом деле проблема не в systemd vs openrc (или подставьте сюда все что хотите). Проблема в культуре дискуссии. Токсичное меньшинство, кричащее громче всех, создаёт иллюзию «общественного мнения». Но реальные мейнтейнеры видят: за громкими лозунгами стоит оголтелый фанатизм и догматическое отторжение инакомыслия.

Настраиваем Visual Studio Code для удаленной работы через SSH

Сегодня все чаще и чаще для конфигурационных файлов используются продвинутые текстовые форматы, такие как JSON или XML, имеющие строгий синтаксис и структуру.

Их применение облегчает программную обработку данных, но при этом они все еще остаются легко читаемыми человеком.

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

Поэтому гораздо удобнее использовать для этого специальные среды разработки, например, VS Code, тем более что он прекрасно умеет работать через SSH.

✅ Читать далее: https://interface31.ru/post/nastraivaem-visual-studio-code-dlya-udalennoy-raboty-cherez-ssh/