Заметка дня #2

Нередко возникает желание выполнить команду наподобие следующей:

$ sed 's/from/to/g' large\_file.txt > large\_file.txt

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

$ cat large\_file.txt $ du \-h large\_file.txt 0 large\_file.txt

Файл становится пустым ещё до начала выполнения sed. Командая оболочка, занимающаяся перенаправлением вывода, открывает файл при помощи системного вызова open(O_WRONLY|O_TRUNK), очищающего файл. Убедиться в этом можно, оттрассировав оболочку:

$ strace \-f \-e openat \-o trace.txt bash \-c '>asdf' $ cat trace.txt ... 283602 openat(AT\_FDCWD, "asdf", O\_WRONLY|O\_CREAT|O\_TRUNC, 0666) = 3 ...

Чтобы обойти эту особенность, проще всего создать временный файл, куда перенаправить вывод команды, и затем заменить им старый файл. Этот подход кому-то может показаться не эстетичным, и в такой ситуации пригодится команда sponge из пакета moreutils:

$ sed 's/from/to/g' large\_file.txt | sponge large\_file.txt

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

К счастью, многие команды сразу имеют ключ, позволяющий выполнять операции над оригинальным файлом: так, например, вывод команды GNU sed, запущенной с ключом \-i/\-\-in\-place, будет автоматически оказываться в оригинальном файле. Под капотом опция всё равно создаёт временный файл - просто его переимнованием утилита занимается сама.

К слову, перенаправлением вывода можно пользоваться для создания файла: привычный всем touch file.txt можно сократить до >file.txt. Мелочь, а приятно :)

#tip

Заметка дня #1

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

Оказывается, контейнер PEM может содержать комментарии до и после сертификата, поэтому вывод команды

$ openssl s\_client \-connect google.com:443 \-showcerts

можно направить прямиком в openssl x509:

$ echo | \ openssl s\_client \-connect google.com:443 \-showcerts 2>/dev/null | \ openssl x509 \-noout \-text Certificate: Data: Version: 3 (0x2) Serial Number: 71:8d:f8:a4:d1:48:8a:78:09:cc:ed:27:10:7d:81:84 ...

Вторая часть команды пропустит весь текст, окружающий пару \-\-\-\-\-BEGIN CERTIFICATE\-\-\-\-\- / \-\-\-\-\-END CERTIFICATE\-\-\-\-\-, и покажет содержимое первого сертификата.

Метод не подойдёт для вывода на экран информации о каждом из сертификатов в цепочке, однако имеющийся опыт показывает, что чаще всего как раз интересен именно первый из них.

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

#tip

Telegram

Остальные 90%

Пару недель назад встретил короткую статью о вопросах, задаваемых при приёме в Google на позицию SRE, и был удручён, когда не смог найти ответ на одну из задач. В задании предлагалось обработать файл при помощи утилиты awk, а я всегда её пропускал мимо и…

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

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

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

Итак, открываем рубрику первой Заметкой дня!

Неожиданно эта неделя обрадовала выходом моей публикации в журнале "IEEE Open Journal of the Communications Society" из первого квартиля:
https://ieeexplore.ieee.org/document/10547545.
Оформление и защита результатов длились весь прошедший год.

Исследование посвящено моделированию трафика приложений VR и было начато во время моей работы в Лаборатории беспроводных сетей ИППИ РАН. Безмерную благодарность выражаю коллегам, без помощи которых эта работа едва ли могла увидеть свет!

Статья находится в открытом доступе, поэтому с результатами исследования могут ознакомиться все желающие :)

Недавний выход стабильной версии Ubuntu 24.04 LTS заставляет задуматься о неминуемом окончании поддержки полюбившейся версии 22.04. Релизный цикл Ubuntu длится 5 лет, торопиться с обновлением пока нет необходимости, однако на новые сервера уже стоит устанавливать последнюю LTS-версию.

Взятый Canonical курс на использование пакетного менеджера snap одобряют не все пользователи Ubuntu. Несмотря на обещанные преимущества snap, deb-пакеты остаются привычным решением, которое хочется вернуть. Это и сделаем.

Сам snap установлен как deb-пакет, от которого можно избавиться, предварительно удалив все имеющиеся snap-ы:

```
# Remove dependent snaps first
while snap list 2>&1 | grep -v 'No snaps'; do
for pkg in $(snap list | cud -d' ' -f1 | tail -n +2); do
sudo snap remove "$pkg"
done
done

# Remove snap
sudo apt -y purge snapd
sudo apt -y autoremove
```

На этом упражнение не заканчивается. Многие deb-пакеты ссылаются на snap-пакеты, и в зависимостях содержат только что удалённый snapd, который вернётся при установке. Застрахуемся от этого, создав файл /etc/apt/preferences.d/snap\-disable со следующим содержимым:

Package: snapd Pin: release a=* Pin\-Priority: \-10

Теперь установка пакетов, зависимых от snapd, будет завершаться ошибкой:

$ sudo apt install firefox ... The following packages have unmet dependencies: firefox : PreDepends: snapd (>= 2.54) but it is not installable ...

Мы успешно удалили пакетный менеджер, однако также мы потеряли Firefox и утилиты, завязанные на snap. К счастью, многие из них можно найти в обычных PPA-репозиториях и поправить приоритеты установки тем же способом, которым мы запретили установку snapd. На примере Firefox это будет выглядеть так:

```
$ cat /etc/apt/preferences.d/firefox-nosnap
# Always use ppa repo
Package: firefox*
Pin: release o=LP-PPA-mozillateam
Pin-Priority: 1001

# Ignore snap version
Package: firefox*
Pin: release o=Ubuntu
Pin-Priority: -1

$ sudo add-apt-repository -y ppa:mozillateam/ppa
$ sudo apt install firefox
```

Теперь всё готово, мы окончательно избавились от snap и можем установить Firefox привычной командой.

В качестве заключения отмечу, что самый весомый аргумент против snap в Ubuntu 24.04 перестал быть актуальным: snap по-прежнему монтирует пакеты, однако вывод df теперь чист: все точки монтирования попадают в отдельное пространство имён, и найти их можно, например, командой nsenter \-a \-t $(pgrep firefox) df. А значит, можно дать этому пакетному менеджеру ещё один шанс :)

Друзья, недавно нас стало немного больше, чем помещается в 8-битный регистр :)

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

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

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

Искать подходящий docker-образ в отсутствие браузера может быть затруднительно. Ситуацию спасает команда docker search, при помощи которой можно получить список наиболее популярных docker-образов приложений, их описание и даже количество звёздочек на Docker Hub. В документации также явно указано, что поиск осуществляется только по Docker Hub. Команда, однако, умеет искать и по другим репозиториям, хотя документация об этом умалчивает: для поиска достаточно указать путь до нужного нам репозитория перед именем образа:

```
$ docker search bitnami/nginx
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
bitnami/nginx Bitnami container image for NGINX 187 [OK]
...

$ docker search quay.io/nginx
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
openshift-scale/nginx 0
...
```

В полном выводе команд можно заметить, что поля STARS, OFFICIAL и AUTOMATED не заполнены при обращении к quay.io, а поле DESCRIPTION содержит сырое markdown-описание с главной страницы образа: грешить на подобные артефакты не стоит, поскольку никаких гарантий на совместимость с другими репозиториями Docker не даёт.

Иногда хочется аналогичным образом поискать в локальном репозитории, однако вероятность успеха не велика: команда docker search использует первую версию REST API, поддерживаемую не везде. Это легко видеть по ошибке при выполнении команды:

$ docker search localhost/nginx Error response from daemon: invalid registry endpoint "http://localhost/v1/". HTTPS attempt: Get "https://localhost/v1/\_ping": dial tcp 127.0.0.1:443: connect: connection refused. HTTP attempt: Get "http://localhost/v1/\_ping": dial tcp 127.0.0.1:80: connect: connection refused

Стандартный образ registry оказывается тоже подвержен этой проблеме:

$ docker run \-\-rm \-p 5000:5000 \-d registry 323e0cc06269846ee8f54d183f6b540ccc8cb119a5d85662625bdc5b889e78a6 $ docker search localhost:5000/nginx Error response from daemon: Unexpected status code 404

Несмотря на описанные сложности, осуществить поиск по локальному репозиторию всё-таки возможно: обратившись по пути /v2/_catalog, мы получим список загруженных в него образов. Для примера добавим образ в репозиторий и поищем его:

```
# Get a some image from Docker Hub
$ docker pull nginx:latest

# Retag it
$ docker tag nginx:latest localhost:5000/a/b/c/nginx:our

# Push to local registry
$ docker push localhost:5000/a/b/c/nginx:our

# Finally, search
$ curl localhost:5000/v2/_catalog
{"repositories":["a/b/c/nginx"]}
```

Список тегов для образа находится по пути /v2/<repo>/tags/list:

$ curl localhost:5000/v2/a/b/c/nginx/tags/list {"name":"a/b/c/nginx","tags":["our"]}

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