NixTux https://nixtux.ru На этом сайте делимся опытом, скриптами и советами в Linux и Свободных программах Sun, 22 Nov 2020 13:29:09 +0000 ru-RU hourly 1 https://wordpress.org/?v=5.5.3 Как работает генератор зависимостей и провайдов devel() RPM https://nixtux.ru/1077 https://nixtux.ru/1077#respond Sun, 22 Nov 2020 13:26:49 +0000 https://nixtux.ru/?p=1077 Записал видео, в котором попытался показать, как работает генератор зависимостей (Requires) и Provides для RPM, автоматизирующий их проставление в RPM-пакетах. devel() зависимости и провайды в дистрибутиве ROSA были в rpm5, для rpm4 в ходе перехода на rpm4 написал работающий по похожей логике генератор на bash. Рассматривается генератор: https://abf.io/import/devel-rpm-generators Также показано, как запускать генератор вручную для … Читать далее Как работает генератор зависимостей и провайдов devel() RPM

The post Как работает генератор зависимостей и провайдов devel() RPM first appeared on NixTux.

]]>
Записал видео, в котором попытался показать, как работает генератор зависимостей (Requires) и Provides для RPM, автоматизирующий их проставление в RPM-пакетах. devel() зависимости и провайды в дистрибутиве ROSA были в rpm5, для rpm4 в ходе перехода на rpm4 написал работающий по похожей логике генератор на bash.

Рассматривается генератор: https://abf.io/import/devel-rpm-generators
Также показано, как запускать генератор вручную для его отладки.
Документация по генераторам: https://rpm.org/user_doc/dependency_generators

The post Как работает генератор зависимостей и провайдов devel() RPM first appeared on NixTux.

]]>
https://nixtux.ru/1077/feed 0
Выступление на OSDAY-2020. Переход ROSA на RPM 4, задачи пакетной системы и ее улучшение. https://nixtux.ru/1052 https://nixtux.ru/1052#comments Fri, 06 Nov 2020 13:58:49 +0000 https://nixtux.ru/?p=1052 Более восьми лет в дистрибутивах ROSA использовался пакетный менеджер RPM5 — форк RPM4, созданный Джеффом Джонсоном, автором RPM. Долгое время RPM5 развивался гораздо активнее своего родителя, что и обусловило его выбор для ROSA. Однако, постепенно активность по разработке RPM5 угасла, а RPM4 наоборот возродился и постепенно не только вобрал большинство интересных свойств RPM5, но и … Читать далее Выступление на OSDAY-2020. Переход ROSA на RPM 4, задачи пакетной системы и ее улучшение.

The post Выступление на OSDAY-2020. Переход ROSA на RPM 4, задачи пакетной системы и ее улучшение. first appeared on NixTux.

]]>
Более восьми лет в дистрибутивах ROSA использовался пакетный менеджер RPM5 — форк RPM4, созданный Джеффом Джонсоном, автором RPM. Долгое время RPM5 развивался гораздо активнее своего родителя, что и обусловило его выбор для ROSA. Однако, постепенно активность по разработке RPM5 угасла, а RPM4 наоборот возродился и постепенно не только вобрал большинство интересных свойств RPM5, но и получил множество новых. В докладе рассмотрены задачи пакетной системы дистрибутива GNU/Linux, накопившиеся проблемы, пути их решения и новые улучшения, сделанные в ходе перехода на RPM 4.

PDF: osday-2020-mikhailnov.pdf

Ниже презентация послайдово в виде картинок и видеозапись.

















The post Выступление на OSDAY-2020. Переход ROSA на RPM 4, задачи пакетной системы и ее улучшение. first appeared on NixTux.

]]>
https://nixtux.ru/1052/feed 1
Автоматический статический анализ с помощью PVS Studio при сборке RPM-пакетов https://nixtux.ru/1041 https://nixtux.ru/1041#respond Wed, 14 Oct 2020 09:42:10 +0000 https://nixtux.ru/?p=1041 Возникла задача автоматизировать статический анализ пакетов в составе дистрибутива. Наилучший инструмент для этого — PVS Studio, потому что умеет перехватывать вызовы компилятора с помощью strace, таким образом, не требуя никаких изменений в сборочных скриптах. Сначала под наблюдением pvs-studio-analyzer запускается сборка, собирает лог, затем запускается анализатор этого лога и формируется отчет. Рассмотрим, как такое настроить, избежав … Читать далее Автоматический статический анализ с помощью PVS Studio при сборке RPM-пакетов

The post Автоматический статический анализ с помощью PVS Studio при сборке RPM-пакетов first appeared on NixTux.

]]>
Возникла задача автоматизировать статический анализ пакетов в составе дистрибутива. Наилучший инструмент для этого — PVS Studio, потому что умеет перехватывать вызовы компилятора с помощью strace, таким образом, не требуя никаких изменений в сборочных скриптах. Сначала под наблюдением pvs-studio-analyzer запускается сборка, собирает лог, затем запускается анализатор этого лога и формируется отчет. Рассмотрим, как такое настроить, избежав внесения правок в каждый пакет.

В качестве операционной системы будем рассматривать rosa2019.1 (dnf + rpm4). Я использую сборки rootfs и systemd-nspawn (snr). Сначала установим необходимые для работы пакеты:
dnf install git-core bash abf basesystem-build how-to-use-pvs-studio-free

С помощью утилиты how-to-use-pvs-studio-free нужно в исходники добавить заголовки PVS Studio. Эти исходники затем будут отстрипаны от бинарников и попадут в debugsource-подпакеты, которые публикуются в репозиторий. Установим ее из репозитория:
sudo dnf install how-to-use-pvs-studio-free

Ставим саму PVS Studio:

wget  https://files.viva64.com/pvs-studio-latest.rpm -O pvs-studio-latest.rpm
sudo dnf pvs-studio-latest.rpm

Теперь суть в следующем. Как известно, RPM превращает секцию спека %prep в shell-скрипт /var/tmp/*.sh и запускает его, аналогично делает с секциями %build и %install. Мы сделаем обертку, которая будет запускать эти скрипты вместо %_buildshell (/bin/sh).

Создаем файл /usr/bin/pvs-prep со следующим текстом:

#!/bin/sh
set -eu
sh "$2"
( cd "$1"
how-to-use-pvs-studio-free -c 2 -m .
)

Этот скрипт будет на стадии %prep добавлять шапку с рекламой PVS Studio в исходники.

Создаем файл /usr/bin/pvs-builder со следующим текстом:

#!/bin/bash
set -eu
name="$1"
script="$2"
test -f "$script"
[ -n "$2" ]
/usr/bin/pvs-studio-analyzer trace -- /bin/bash -e "$script"
mkdir -p "$HOME/pvs-logs/raw-logs"
pvs-studio-analyzer analyze -o "$HOME/pvs-logs/${name}" -j "$(nproc)" #-C /usr/bin/clang
rm -fr "$HOME/pvs-logs/html-logs/${name}"
mkdir -p "$HOME/pvs-logs/html-logs/${name}"
plog-converter -a GA:1,2 -t fullhtml "$HOME/pvs-logs/${name}" -o "$HOME/pvs-logs/html-logs/${name}"
mv -v "$HOME/pvs-logs/html-logs/${name}/fullhtml"/* "$HOME/pvs-logs/html-logs/${name}/"
rm -fr "$HOME/pvs-logs/html-logs/${name}/fullhtml"

Этот скрипт будет запускать скрипт %build под трассировщиком PVS Studio, а затем создавать отчет.

Делаем их исполняемыми:
chmod +x /usr/bin/pvs-builder /usr/bin/pvs-prep

Не используем /usr/local/bin, поскольку он не входит в $PATH в RPM.

Теперь в файл /etc/rpm/macros дописываем:

%__spec_prep_cmd /usr/bin/pvs-prep "%{_sourcedir}"
%__spec_build_cmd /usr/bin/pvs-builder %{name}

(см. https://github.com/rpm-software-management/rpm/issues/1399)

И всё. Каждая сборка проекта на C/C++ будет создавать HTML-отчет в папке $HOME/pvs-logs/html-logs/имя_пакета.

Чтобы не мучиться с mock, можно собирать список пакетов так:
cat list_sec_sorted.txt | while read -r line; do pushd $line && dnf builddep --allowerasing -y *.spec && abf rpmbuild ; popd; done
т.е. ставить сборочные зависимости в ту же систему, но разрешать удалять лишние пакеты, если устанавливаемые зависимости текущего пакета конфликтуют с зависимостями одного из предыдущих пакетов.

The post Автоматический статический анализ с помощью PVS Studio при сборке RPM-пакетов first appeared on NixTux.

]]>
https://nixtux.ru/1041/feed 0
Автоматизация GDB с помощью xdotool https://nixtux.ru/1035 https://nixtux.ru/1035#respond Sat, 10 Oct 2020 23:37:41 +0000 https://nixtux.ru/?p=1035 Понадобилось в отладчике gdb очень много раз повторить одинаковое действие, чтобы поймать значения переменных, которые были в момент сегфолта. Открыл 2 терминала, в одном запустил программу под gdb, поставил точку остановки (breakpoint), запустил (run), другой средствами оконного менеджера закрепил поверх других окон, запустив в нем: sleep 5; while true ; do xdotool type c && … Читать далее Автоматизация GDB с помощью xdotool

The post Автоматизация GDB с помощью xdotool first appeared on NixTux.

]]>
Понадобилось в отладчике gdb очень много раз повторить одинаковое действие, чтобы поймать значения переменных, которые были в момент сегфолта.

Открыл 2 терминала, в одном запустил программу под gdb, поставил точку остановки (breakpoint), запустил (run), другой средствами оконного менеджера закрепил поверх других окон, запустив в нем:
sleep 5; while true ; do xdotool type c && for type in A B ; do xdotool key KP_Enter && xdotool key p && xdotool key space && for i in $type E V R ; do xdotool type $i ; done; done && xdotool key KP_Enter ; sleep 0; if ! ps aux | grep -vE 'gdb|grep' | grep -q '/usr/bin/python3 /usr/bin/livecd-creator' ; then break ; fi; done
Этот код вводит нужные команды в gdb и проверяет, не остановился ли процесс, т.е. не произошел ли сегфолт, а если произошел, то перестает их вводить. Пошел по своим делам, оно само отработало, вернулся, передо мной был наглядный результат.

The post Автоматизация GDB с помощью xdotool first appeared on NixTux.

]]>
https://nixtux.ru/1035/feed 0
Не делать конкретные микрофон или динамики устройством по умолчанию в PulseAudio (Linux) https://nixtux.ru/1027 https://nixtux.ru/1027#respond Sat, 22 Aug 2020 15:28:18 +0000 https://nixtux.ru/?p=1027 В PulseAudio есть модуль module-switch-on-connect, который делает подключаемое устройство ввода или вывода звука устройством по умолчанию. Допустим, вы подключили USB-микрофон, а он в PulseAudio стал устройством ввода по умолчанию (см., как отмечена серая галочка справа в pavucontrol): Это обычно очень удобно. Подключили устройство и всё, ни о чем не думаете. Во многих дистрибутивах, в т.ч. … Читать далее Не делать конкретные микрофон или динамики устройством по умолчанию в PulseAudio (Linux)

The post Не делать конкретные микрофон или динамики устройством по умолчанию в PulseAudio (Linux) first appeared on NixTux.

]]>
В PulseAudio есть модуль module-switch-on-connect, который делает подключаемое устройство ввода или вывода звука устройством по умолчанию.

Допустим, вы подключили USB-микрофон, а он в PulseAudio стал устройством ввода по умолчанию (см., как отмечена серая галочка справа в pavucontrol):

Это обычно очень удобно. Подключили устройство и всё, ни о чем не думаете. Во многих дистрибутивах, в т.ч. Ubuntu и ROSA, это включено по умолчанию в файле /etc/pulse/default.pa:

### Use hot-plugged devices like Bluetooth or USB automatically (LP: #1702794)
.ifexists module-switch-on-connect.so
load-module module-switch-on-connect
.endif

Столкнулся с тем, что USB-микрофон Samson GoMic еще и звуковой картой может быть (в нем есть Jack-разъем). При его подключении к рабочей станции с Linux module-switch-on-connect делал не только его микрофон микрофоном по умолчанию, но и его устройство вывода. А мне это не нужно, нужно, чтобы звук продолжал по умолчанию выводиться на обычные динамики.

Идем в документацию по module-switch-on-connect и видим, что у него существует параметр blacklist, в котором можно регулярным выражением задать список устройств, которые исключим из автоматического переключения в статус по умолчанию. Выведем список звуковых устройств командой pactl list (не от root) и видим, что интересующее нас устройство вывода звука называется «alsa_output.usb-Samson_Technologies_Samson_GoMic-00.analog-stereo». В документации сказано, что регулярным выражением по умолчанию, если не задано иное, в т.ч. пустое выражение, является «hdmi». Это сделано, т.к. часто видеокарта умеет выводить звук по HDMI, но мало кто этим пользуется.

В файле /etc/pulse/default.pa заменяем
load-module module-switch-on-connect
на:
load-module module-switch-on-connect blacklist="(hdmi|output.*Samson.*GoMic)"
В регулярном выражении выше .* означает любые символы или их отсутствие, ( | ) — конструкция «или».

Вместо /etc/pulse/default.pa можно править ~/.config/pulse/default.pa в домашней папке, но в моем дистрибутиве в /etc/pulse/default.pa уже есть module-switch-on-connect, поэтому правил в нем.

Перезапускаем PulseAudio или весь сеанс и видим, что при подключении этого USB-микрофона Samson GoMic к Linux его микрофон становится микрофоном по умолчанию сразу и автоматически, а звук на него выводиться автоматически не начинает. То, что надо! Очень люблю PulseAudio за гибкость (и даже когда-то написал небольшую программу PulseJoin).

The post Не делать конкретные микрофон или динамики устройством по умолчанию в PulseAudio (Linux) first appeared on NixTux.

]]>
https://nixtux.ru/1027/feed 0
Алгоритм починки BTRFS https://nixtux.ru/1024 https://nixtux.ru/1024#respond Thu, 02 Jul 2020 10:36:31 +0000 https://nixtux.ru/?p=1024 Скопирую сюда хорошее описание порядка действия для починки BTRFS. На английском. The below are the steps I would recommend for ANY btrfs issue, smart people reading dmesg or syslog can probably figure out which of these steps they’d need to skip to in order to fix their particular problem. Step 1 — boot to a … Читать далее Алгоритм починки BTRFS

The post Алгоритм починки BTRFS first appeared on NixTux.

]]>
Скопирую сюда хорошее описание порядка действия для починки BTRFS. На английском.

The below are the steps I would recommend for ANY btrfs issue, smart
people reading dmesg or syslog can probably figure out which of these
steps they’d need to skip to in order to fix their particular problem.

Step 1 — boot to a suitable alternative system, such as a different
installation of openSUSE, a liveCD, or an openSUSE installation DVD.
The installation DVD for the version of openSUSE you are running is
usually the best choice as it will certainly use the same kernel/btrfs
version.
Step 2 — Go to a suitable console and make sure you do the below as root
Step 3 — Try to mount your partition to /mnt, just to confirm it’s
really broken (eg. «mount /dev/sda1 /mnt»)
Step 4 — If it mounts — are you sure it’s broken? if Yes — run «btrfs
scrub start /mnt» to scrub the system, and «btrfs scrub status /mnt»
to monitor it
Step 5 — If it doesn’t mount, try to scrub the device just in case it
works (eg. «btrfs scrub start /dev/sda1» and «btrfs scrub status
/dev/sda1» to monitor). Try mounting, if yes, you’re fixed.
Step 6 — If scrubbing is not an option or does not resolve the issue
then try «mount -o usebackuproot» instead (eg. «mount -o usebackuproot
/dev/sda1 /mnt»).

==Interlude==
All of the above steps are considered safe and should make no
destructive changes to disk, and have fixed every filesystem issue
I’ve had on btrfs in the last 5 years
Full disk issues need a different approach (basically, delete stuff
;)) documented here:
https://www.suse.com/documentation/sles-12/stor_admin/data/sect_filesystems_trouble.html

If the above doesn’t fix things for you, you can continue with the
below steps but the situation is serious enough to justify a bug
report, please!
==

Step 7 — Run «btrfs check » (eg. «btrfs check /dev/sda1»).
This isn’t going to help, but save the log somewhere, it will be
useful for the bug report.
Step 8 — Seriously consider running «btrfs restore » (eg. «btrfs restore /dev/sda1 /mnt/usbdrive»). This
won’t fix anything but it will scan the filesystem and recover
everything it can to the mounted device. This especially useful if
your btrfs issues are actually caused by failing hardware and not
btrfs fault.
Step 9 — Run «btrfs rescue super-recover » (eg. «btrfs rescue
super-recover /dev/sda1»). Then try to mount the device normally. If
it works, stop going.
Step 10 — Run «btrfs rescue zero-log » (eg. «btrfs rescue
zero-log /dev/sda1»). Then try to mount the device normally. If it
works, stop going.
Step 11 — Run «btrfs rescue chunk-recover » (eg. «btrfs rescue
chunk-recover /dev/sda1»). This will take a LONG while. Then try to
mount the device normally. If it works, stop going.
Step 12 — Don’t just consider it this time, don’t be an idiot, run
«btrfs restore » (eg. «btrfs restore
/dev/sda1 /mnt/usbdrive»).
Step 13 — Seriously, don’t be an idiot, use btrfs restore

==Danger zone=
The above tools had a small chance of making unwelcome changes, but
now you’re in the seriously suicidal territory, do not do the
following unless you’re prepared to accept the consequences of your
choice.
==

Step 14 — Now, ONLY NOW, try btrfsck aka «btrfs check —repair
» (eg. «btrfs check —repair /dev/sda1»)

There, I’m very confident the above will help you Andrei, and for
everyone else, can we please bury the nonsense that btrfs is lacking
when it comes to repair and recovery tools?

You have scrub which is safe for day to day use, the perfectly safe
usebackuproot mount option, and the various «btrfs rescue» commands
which are only moderately worrying compared to the practical Russian
roulette which is «btrfs check»

Источник

The post Алгоритм починки BTRFS first appeared on NixTux.

]]>
https://nixtux.ru/1024/feed 0
Хренак, хренак и зарелизили Федору https://nixtux.ru/1021 https://nixtux.ru/1021#respond Tue, 30 Jun 2020 22:36:19 +0000 https://nixtux.ru/?p=1021 Выкачал копии репозиториев Fedora, выкачивал так: mkdir -p fedora/linux/releases/31/Everything/x86_64/os/Packages/ rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync://mirror.yandex.ru/fedora/linux/releases/31/Everything/x86_64/os/Packages/ fedora/linux/releases/31/Everything/x86_64/os/Packages/ mkdir -p fedora/linux/releases/30/Everything/x86_64/os/Packages/ rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync://mirror.yandex.ru/fedora/linux/releases/30/Everything/x86_64/os/Packages/ fedora/linux/releases/30/Everything/x86_64/os/Packages/ mkdir -p fedora/linux/releases/32/Everything/x86_64/os/Packages/ rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync://mirror.yandex.ru/fedora/linux/releases/32/Everything/x86_64/os/Packages/ fedora/linux/releases/32/Everything/x86_64/os/Packages/ Немного проанализируем их. Посмотрим, сколько пакетов в репозитории fc32 имеют суффикс не fc32, т.е. не были пересобраны с предыдущего … Читать далее Хренак, хренак и зарелизили Федору

The post Хренак, хренак и зарелизили Федору first appeared on NixTux.

]]>
Выкачал копии репозиториев Fedora, выкачивал так:

mkdir -p fedora/linux/releases/31/Everything/x86_64/os/Packages/
rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync://mirror.yandex.ru/fedora/linux/releases/31/Everything/x86_64/os/Packages/ fedora/linux/releases/31/Everything/x86_64/os/Packages/
mkdir -p fedora/linux/releases/30/Everything/x86_64/os/Packages/
rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync://mirror.yandex.ru/fedora/linux/releases/30/Everything/x86_64/os/Packages/ fedora/linux/releases/30/Everything/x86_64/os/Packages/
mkdir -p fedora/linux/releases/32/Everything/x86_64/os/Packages/
rsync -avuH --progress --exclude=debug/ --exclude=drpms/ rsync://mirror.yandex.ru/fedora/linux/releases/32/Everything/x86_64/os/Packages/ fedora/linux/releases/32/Everything/x86_64/os/Packages/

Немного проанализируем их. Посмотрим, сколько пакетов в репозитории fc32 имеют суффикс не fc32, т.е. не были пересобраны с предыдущего релиза:

[root@nas-dfly ~]# find fedora/linux/releases/32/Everything/x86_64/os/Packages -type f -name '*.rpm' | grep -v '\.fc32\.' | wc -l
    1121
[root@nas-dfly ~]# find fedora/linux/releases/32/Everything/x86_64/os/Packages -type f -name '*.rpm' | wc -l
   55327

1121 / 55327 = 2% пакетов в момент релиза Fedora 32 не пересобирались и были просто скопированы из предыдущих релизов. Возможно, некоторые починили и положили в updates, я смотрю только release, но это не столь важно, ведь некоторые пакеты не пересобираются несколько релизов подряд:

[root@nas-dfly ~]# find fedora/linux/releases/31/Everything/x86_64/os/Packages -type f -name '*.fc2*.*' | wc -l
     110

Т.е. 110 пакетов не пересобирались более двух релизов, более года (релиз выходит раз в полгода).

Некоторые пакеты имеют сломанные зависимости, например:

Error: 
 Problem: conflicting requests
  - nothing provides mvn(org.hibernate:hibernate-validator) needed by jersey-2.28-5.fc31.noarch
  - nothing provides mvn(org.jboss.weld.se:weld-se-core) needed by jersey-2.28-5.fc31.noarch
(try to add '--skip-broken' to skip uninstallable packages)

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

The post Хренак, хренак и зарелизили Федору first appeared on NixTux.

]]>
https://nixtux.ru/1021/feed 0
Обновление переводов в исходниках drakxtools https://nixtux.ru/1016 https://nixtux.ru/1016#respond Sun, 26 Apr 2020 22:09:36 +0000 https://nixtux.ru/?p=1016 Все время забываю, как это делается, каждый раз приходится догадываться по Makefile, поэтому запишу процедуру обновления переводов после правки кода drakxtools. cd perl-install/share/po make libDrakX.pot (это добавит новую строку, в данном случае America/Nuuk, в шаблон с переводами) make merge (обновить po из шаблона pot) Дописать перевод в ru.po make merge еще раз для форматирования po

The post Обновление переводов в исходниках drakxtools first appeared on NixTux.

]]>
Все время забываю, как это делается, каждый раз приходится догадываться по Makefile, поэтому запишу процедуру обновления переводов после правки кода drakxtools.

cd perl-install/share/po
make libDrakX.pot (это добавит новую строку, в данном случае America/Nuuk, в шаблон с переводами)
make merge (обновить po из шаблона pot)
Дописать перевод в ru.po
make merge еще раз для форматирования po

The post Обновление переводов в исходниках drakxtools first appeared on NixTux.

]]>
https://nixtux.ru/1016/feed 0
Видео по работе с Git на примере пакетов в ROSA https://nixtux.ru/1009 https://nixtux.ru/1009#respond Thu, 09 Apr 2020 18:57:34 +0000 https://nixtux.ru/?p=1009 Git-ветки на примере пакета в ROSA. Часть 1. git merge веток Git. Часть 2. Откат изменений. Форс-пуш Git-ветки на примере пакета в ROSA. Часть 3. Быстрый merge из master во все остальные ветки

The post Видео по работе с Git на примере пакетов в ROSA first appeared on NixTux.

]]>

Git-ветки на примере пакета в ROSA. Часть 1. git merge веток

Git. Часть 2. Откат изменений. Форс-пуш

Git-ветки на примере пакета в ROSA. Часть 3. Быстрый merge из master во все остальные ветки

The post Видео по работе с Git на примере пакетов в ROSA first appeared on NixTux.

]]>
https://nixtux.ru/1009/feed 0
Изощренное создание %pre скриптлета RPM-пакета из шаблона https://nixtux.ru/1002 https://nixtux.ru/1002#respond Tue, 24 Mar 2020 23:25:54 +0000 https://nixtux.ru/?p=1002 Дано: файл quagga-sysusers.conf («Source3: quagga-sysusers.conf» в RPM-спеке) с таким содержимым: u @quagga_user@ - "Quagga routing suite user" /run/quagga g @quagga_user@ - m @quagga_user@ @quagga_user@ g @vty_group@ - m @quagga_user@ @vty_group@ При этом хочется использовать этот конфиг systemd-sysusers в предустановочном скриптлете RPM-пакета (%pre). Но нужно шаблоны @quagga_user@ и @vty_group@ заменить на их значения. Стандартно конфиг systemd-sysusers … Читать далее Изощренное создание %pre скриптлета RPM-пакета из шаблона

The post Изощренное создание %pre скриптлета RPM-пакета из шаблона first appeared on NixTux.

]]>
Дано:
файл quagga-sysusers.conf («Source3: quagga-sysusers.conf» в RPM-спеке) с таким содержимым:

u @quagga_user@ - "Quagga routing suite user" /run/quagga
g @quagga_user@ -
m @quagga_user@ @quagga_user@
g @vty_group@ -
m @quagga_user@ @vty_group@

При этом хочется использовать этот конфиг systemd-sysusers в предустановочном скриптлете RPM-пакета (%pre). Но нужно шаблоны @quagga_user@ и @vty_group@ заменить на их значения.

Стандартно конфиг systemd-sysusers добавляется в %pre вот так:

%pre
%sysusers_create_package %{name} %{SOURCE3}

что превращается в:

$ rpm -qp --scripts quagga-1.2.4-3-rosa2016.1.x86_64.rpm
preinstall scriptlet (using /bin/sh):

systemd-sysusers --replace=/usr/lib/sysusers.d/quagga.conf - </dev/null 2>&1 || : 
u @quagga_user@ - "Quagga routing suite user" /run/quagga
g @quagga_user@ -
g @vty_group@ -
m @quagga_user@ @vty_group@ 
SYSTEMD_INLINE_EOF

Вот как бы это прогнать через sed? Решение такое:

%pre
%{expand:
%(echo '%{sysusers_create_package %{name} %{SOURCE3}}' | \
sed -e 's,@quagga_user@,%{quagga_user},g' -e 's,@vty_group@,%{vty_group},g')
}

Убеждаемся, что это превратится в то, что нужно:

$ cp -v quagga-sysusers.conf ~/rpmbuild/SOURCES/
$ rpmspec --parse quagga.spec
<...>
%pre

systemd-sysusers --replace=/usr/lib/sysusers.d/quagga.conf - </dev/null 2>&1 || : 
u quagga - "Quagga routing suite user" /run/quagga
g quagga -
m quagga quagga
g quaggavt -
m quagga quaggavt 
SYSTEMD_INLINE_EOF 

Обратите внимание на одинарные кавычки в строке '%{sysusers_create_package %{name} %{SOURCE3}}', иначе двойные кавычки в "Quagga routing suite user" теряются.

The post Изощренное создание %pre скриптлета RPM-пакета из шаблона first appeared on NixTux.

]]>
https://nixtux.ru/1002/feed 0