http://wiki.rosalab.ru/ru/api.php?action=feedcontributions&user=Betcher&feedformat=atomRosalab Wiki - Вклад участника [ru]2024-03-29T06:04:13ZВклад участникаMediaWiki 1.26.4http://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21053Qemoo2024-03-04T06:48:26Z<p>Betcher: /* Установка с исо на реальный диск */</p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой набор параметров.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
===== Установка с исо на реальный диск =====<br />
<br />
Ключ -a позволяет подключать к виртуальной машине дополнительные устройства или образы<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если исо по-байтово копировать на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
==== Проброс каталога между хостом и гостем ==== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
=== Сеть ===<br />
<br />
Для удобства взаимодействия по сети с виртуальными машинами Virt-Manager'а, виртуальные машины, запущенные с помщью qemoo, получают сетевой адрес из той же подсети, если она существует. Обычно это подсеть 192.168.122.0/24 на интерфейсе virbr0. Если этого интерфейса нет, вероятно не установлена и/или не запущена служба libvirtd. В этом случае для каждой виртуальной машины будет подниматься своя виртуальная подсеть, в которой она будет находиться за NAT, что не всегда подходит.<br />
Также сетевой мост можно создать и настроить самостоятельно, назвав его qemoobr0. При его наличии virbr0 игнорируется.<br />
<br />
=== Демон ===<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к ее экрану вам понадобится сторонее приложение (virt-viewer, remmina). <br />
<br />
Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
=== systemd ===<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
<u>systemd-escape здесь нужен для экранирования слэшей в путях</u><br />
<br />
=== Конфигурационные файлы ===<br />
<br />
В порядке увеличения приоритета:<br />
<br />
1. /etc/qemoo.cfg<br />
или вместо него указанный в переменной окружения $QEMOOCFG<br />
2. ./qemoo.cfg<br />
3. имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг<br />
4. указанный с параметром --config<br />
<br />
<br />
<br />
[https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695 Тема по qemoo на https://forum.rosalinux.ru/]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21052Qemoo2024-03-04T06:47:59Z<p>Betcher: /* Конфигурационные файлы */</p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой набор параметров.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
===== Установка с исо на реальный диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства или образы<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если исо по-байтово копировать на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
==== Проброс каталога между хостом и гостем ==== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
=== Сеть ===<br />
<br />
Для удобства взаимодействия по сети с виртуальными машинами Virt-Manager'а, виртуальные машины, запущенные с помщью qemoo, получают сетевой адрес из той же подсети, если она существует. Обычно это подсеть 192.168.122.0/24 на интерфейсе virbr0. Если этого интерфейса нет, вероятно не установлена и/или не запущена служба libvirtd. В этом случае для каждой виртуальной машины будет подниматься своя виртуальная подсеть, в которой она будет находиться за NAT, что не всегда подходит.<br />
Также сетевой мост можно создать и настроить самостоятельно, назвав его qemoobr0. При его наличии virbr0 игнорируется.<br />
<br />
=== Демон ===<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к ее экрану вам понадобится сторонее приложение (virt-viewer, remmina). <br />
<br />
Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
=== systemd ===<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
<u>systemd-escape здесь нужен для экранирования слэшей в путях</u><br />
<br />
=== Конфигурационные файлы ===<br />
<br />
В порядке увеличения приоритета:<br />
<br />
1. /etc/qemoo.cfg<br />
или вместо него указанный в переменной окружения $QEMOOCFG<br />
2. ./qemoo.cfg<br />
3. имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг<br />
4. указанный с параметром --config<br />
<br />
<br />
<br />
[https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695 Тема по qemoo на https://forum.rosalinux.ru/]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21047Qemoo2024-03-01T13:08:34Z<p>Betcher: /* Демон */</p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой набор параметров.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
===== Установка с исо на реальный диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства или образы<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если исо по-байтово копировать на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
==== Проброс каталога между хостом и гостем ==== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
=== Сеть ===<br />
<br />
<br />
<br />
=== Демон ===<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к ее экрану вам понадобится сторонее приложение (virt-viewer, remmina). <br />
<br />
Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
=== systemd ===<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
<u>systemd-escape здесь нужен для экранирования слэшей в путях</u><br />
<br />
=== Конфигурационные файлы ===<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
1. /etc/qemoo.cfg<br />
или вместо него указанный в переменной окружения $QEMOOCFG<br />
2. ./qemoo.cfg<br />
3. имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг<br />
4. указанный с параметром --config<br />
<br />
<br />
<br />
[https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695 Тема по qemoo на https://forum.rosalinux.ru/]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21046Qemoo2024-03-01T13:07:25Z<p>Betcher: /* Хитромудрая загрузка */</p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой набор параметров.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
===== Установка с исо на реальный диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства или образы<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если исо по-байтово копировать на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
==== Проброс каталога между хостом и гостем ==== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
=== Сеть ===<br />
<br />
<br />
<br />
=== Демон ===<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к его экрану вам понадобится<br />
сторонее приложение (virt-viewer, remmina). <br />
<br />
Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
=== systemd ===<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
<u>systemd-escape здесь нужен для экранирования слэшей в путях</u><br />
<br />
=== Конфигурационные файлы ===<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
1. /etc/qemoo.cfg<br />
или вместо него указанный в переменной окружения $QEMOOCFG<br />
2. ./qemoo.cfg<br />
3. имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг<br />
4. указанный с параметром --config<br />
<br />
<br />
<br />
[https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695 Тема по qemoo на https://forum.rosalinux.ru/]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21045Qemoo2024-03-01T13:06:27Z<p>Betcher: /* Установка с исо на диск */</p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой набор параметров.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
===== Установка с исо на реальный диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства или образы<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если раскатать исо на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
==== Проброс каталога между хостом и гостем ==== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
=== Сеть ===<br />
<br />
<br />
<br />
=== Демон ===<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к его экрану вам понадобится<br />
сторонее приложение (virt-viewer, remmina). <br />
<br />
Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
=== systemd ===<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
<u>systemd-escape здесь нужен для экранирования слэшей в путях</u><br />
<br />
=== Конфигурационные файлы ===<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
1. /etc/qemoo.cfg<br />
или вместо него указанный в переменной окружения $QEMOOCFG<br />
2. ./qemoo.cfg<br />
3. имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг<br />
4. указанный с параметром --config<br />
<br />
<br />
<br />
[https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695 Тема по qemoo на https://forum.rosalinux.ru/]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21044Qemoo2024-03-01T13:04:39Z<p>Betcher: /* Конфигурационные файлы */</p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой набор параметров.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
===== Установка с исо на диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если раскатать исо на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
==== Проброс каталога между хостом и гостем ==== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
=== Сеть ===<br />
<br />
<br />
<br />
=== Демон ===<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к его экрану вам понадобится<br />
сторонее приложение (virt-viewer, remmina). <br />
<br />
Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
=== systemd ===<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
<u>systemd-escape здесь нужен для экранирования слэшей в путях</u><br />
<br />
=== Конфигурационные файлы ===<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
1. /etc/qemoo.cfg<br />
или вместо него указанный в переменной окружения $QEMOOCFG<br />
2. ./qemoo.cfg<br />
3. имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг<br />
4. указанный с параметром --config<br />
<br />
<br />
<br />
[https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695 Тема по qemoo на https://forum.rosalinux.ru/]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21043Qemoo2024-03-01T11:09:51Z<p>Betcher: </p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой набор параметров.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
===== Установка с исо на диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если раскатать исо на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
==== Проброс каталога между хостом и гостем ==== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
=== Сеть ===<br />
<br />
<br />
<br />
=== Демон ===<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к его экрану вам понадобится<br />
сторонее приложение (virt-viewer, remmina). <br />
<br />
Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
=== systemd ===<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
<u>systemd-escape здесь нужен для экранирования слэшей в путях</u><br />
<br />
=== Конфигурационные файлы ===<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
/etc/qemoo.cfg<br />
./qemoo.cfg<br />
имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг)<br />
<br />
<br />
<br />
<br />
[https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695 Тема по qemoo на https://forum.rosalinux.ru/]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21042Qemoo2024-03-01T11:05:17Z<p>Betcher: </p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой набор параметров.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
===== Установка с исо на диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если раскатать исо на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
==== Проброс каталога между хостом и гостем ==== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
=== Демон ===<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к его экрану вам понадобится<br />
сторонее приложение (virt-viewer, remmina). Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
=== systemd ===<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
<u>systemd-escape здесь нужен для экранирования слэшей в путях</u><br />
<br />
=== Конфигурационные файлы ===<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
/etc/qemoo.cfg<br />
./qemoo.cfg<br />
имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг)<br />
<br />
<br />
<br />
<br />
[https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695 Тема по qemoo на https://forum.rosalinux.ru/]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21041Qemoo2024-03-01T11:00:31Z<p>Betcher: </p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
<br />
===== Установка с исо на диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если раскатать исо на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
==== Проброс каталога между хостом и гостем ==== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
=== Демон ===<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к его экрану вам понадобится<br />
сторонее приложение (virt-viewer, remmina). Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
=== systemd ===<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
<u>systemd-escape здесь нужен для экранирования слэшей в путях</u><br />
<br />
=== Конфигурационные файлы ===<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
/etc/qemoo.cfg<br />
./qemoo.cfg<br />
имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг)<br />
<br />
<br />
<br />
<br />
[https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695 Тема по qemoo на https://forum.rosalinux.ru/]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21040Qemoo2024-03-01T10:57:34Z<p>Betcher: </p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой.<br />
<br />
==== Просто передайте то, что нужно запустить ====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
<br />
===== Установка с исо на диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если раскатать исо на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
===== Проброс каталога между хостом и гостем ===== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
==== Демон ====<br />
<br />
Можно запустить виртуальную машину с выводом видео по протоколу SPICE, то есть машина будет запущена демоном, а для подключения к его экрану вам понадобится<br />
сторонее приложение (virt-viewer, remmina). Запустите с ключом -d. Qemoo вернет номер порта для подключения.<br />
<br />
qemoo -d Rosa.iso<br />
<br />
==== systemd ====<br />
<br />
Пакет qemoo содержит юниты для создания виртуальных машин управляемых systemd.<br />
Можно использовать для запуска виртуальных машин при старте ОС хоста.<br />
<br />
При запуске qemoo в режиме установки (ключ -i) рядом с новым qcow2<br />
образом создается одноименный файл - образ.qcow2.conf он содержит<br />
настройки которые нужно применять при старте qemoo c этим образом <br />
<br />
Выглядит так: <br />
<br />
ACTION=run<br />
RAM="auto"<br />
ADD=""<br />
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"<br />
PORT=""<br />
REDIRUSB=""<br />
LOSETUP=""<br />
SPICE=""<br />
SHARE="/home/betcher/Programming/ISO"<br />
QEMOOADD="" <br />
<br />
Для запуска с systemd нужно изменить:<br />
<br />
SPICE=yes (чтобы виртуальная машина запускалась демоном)<br />
PORT=6001 (порт для подключения иначе будет назначен автоматически)<br />
<br />
Запуск такого образа от root с systemd:<br />
<br />
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Проверка состояния:<br />
<br />
systemctl status qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Включить авто запуск гостя при старте ОС хоста:<br />
<br />
systemctl enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Отключить запуск гостя при старте хоста:<br />
<br />
systemctl disable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
Те же команды можно использовать для запуска виртуальной машины с правами пользователя, для этого после systemctl добавляем --user <br />
<br />
Например: <br />
<br />
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img.qcow2)<br />
<br />
_systemd-escape здесь нужен для экранирования слэшей в путях_ <br />
<br />
==== Конфигурационные файлы ====<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
/etc/qemoo.cfg<br />
./qemoo.cfg<br />
имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг)<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21039Qemoo2024-03-01T10:38:03Z<p>Betcher: </p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой.<br />
<br />
===== Просто передайте то, что нужно запустить =====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
<br />
===== Установка с исо на диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
===== Хитромудрая загрузка =====<br />
<br />
Можно грузить с iso так, как загрузка шла бы если раскатать исо на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
===== Конфигурационные файлы =====<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
/etc/qemoo.cfg<br />
./qemoo.cfg<br />
имя_загружаемого_образа.conf<br />
то есть:<br />
_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг)<br />
<br />
===== Проброс каталога между хостом и гостем ===== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
<br />
<br />
<br />
<br />
https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21038Qemoo2024-03-01T10:33:28Z<p>Betcher: </p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
* Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
* Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
* Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
* Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой.<br />
<br />
===== Просто передайте то, что нужно запустить =====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
<br />
Если EFI, то добавляем ключ -e<br />
<br />
qemoo -e my.img <br />
и т.д<br />
<br />
===== Установка ОС на виртуальный диск ===== <br />
<br />
Добавляем ключ -i<br />
<br />
qemoo -i Rosa.iso<br />
qemoo -i -е /dev/sdb<br />
<br />
утилита создаст в текущем каталоге образ qcow2 и подключит его при старте, после инсталляции можно грузиться с образа этим же qemoo<br />
<br />
qemoo _qemoo1_ROS.qcow2 (имена образов генерируются, но можно и задать)<br />
<br />
<br />
===== Установка с исо на диск =====<br />
<br />
Ключ -a позволяет подключать виртуальной машине дополнительные устройства<br />
<br />
qemoo Rosa.iso -a /dev/sdb<br />
<br />
<br />
===== Параметры для qemu =====<br />
<br />
Можно добавлять свои параметры для qemu в конце строки после --<br />
<br />
qemoo -e -S Rosa.iso -- -smp 4<br />
<br />
<br />
Можно грузить с iso так, как загрузка шла бы если раскатать исо на флешку.<br />
<br />
qemoo -l Rosa.iso<br />
qemoo -l -e Rosa.iso<br />
<br />
Можно пробросить при загрузке usb устройство целиком, например для 4G модемов с sd картой куда установлена ОС или барий на токене<br />
<br />
qemoo -L /dev/sdb<br />
<br />
===== Конфигурационные файлы =====<br />
<br />
В порядке уменьшения приоритета:<br />
<br />
/etc/qemoo.cfg<br />
./qemoo.cfg<br />
имя_загружаемого_образа.conf<br />
(_qemoo1_MOS.qcow2 - образ<br />
_qemoo1_MOS.qcow2.conf - его личный конфиг)<br />
<br />
===== Проброс каталога между хостом и гостем ===== <br />
<br />
При каждой загрузке в гостевую ОС пробрасывается папка ( по умолчанию ./ ), как подключить ее в гостевой ОС линукс будет написано в консоль при старте <br />
<br />
<br />
<br />
<br />
<br />
https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Qemoo&diff=21037Qemoo2024-03-01T10:15:24Z<p>Betcher: Новая страница: «=== Qemoo - скрипт-обертка для эмулятора qemu. === Qemoo не заменит virt-manager или virtualbox, а также поддер…»</p>
<hr />
<div>=== Qemoo - скрипт-обертка для эмулятора qemu. ===<br />
<br />
Qemoo не заменит virt-manager или virtualbox, а также поддерживает только малую часть возможностей qemu, но совершенно незаменим когда нужно быстро запустить виртуальную машину.<br />
Qemoo избавит вас от необходимости заучивать километровые команды для запуска элементарной виртуалки с iso.<br />
Qemoo имеет всего несколько параметров и конфигурационный файл позволяющий добавить или изменить любые параметры эмулятора qemu.<br />
Qemoo может помочь вам, даже когда его возможностей по конфигурации qemu недостаточно, добавив ключ -S вы можете сгенерировать cmdline для qemu и уже на основе этой заготовки делать свой.<br />
<br />
===== Просто передайте то, что нужно запустить =====<br />
<br />
qemoo Rosa.iso<br />
qemoo /dev/sda<br />
qemoo ./Rosa.qcow2<br />
и т.д.<br />
<br />
<br />
https://forum.rosalinux.ru/viewtopic.php?f=58&t=10695</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F&diff=21020Barium:Системы сохранения2024-02-19T09:48:04Z<p>Betcher: /* uird.mounts и uird.home */</p>
<hr />
<div>Большая часть особых свойств, что отличают ОС Барий от других дистрибутивов росы, собранных на той же пакетной базе, заложены в [[Barium:UIRD]].<br />
<br />
'''UIRD это init ram disk (initrd)''' собираемый с использованием dracut, но кардинально отличающийся сценарием загрузки ОС. Предназначен<br />
для загрузки модульных дистрибутивов. В настоящее время используется в MagOS, Барии, ublinux, MOS-flash доступен как дополнительный initrd в дистрибутивах puppyrus.<br />
А значит описанное далее в целом справедливо и для них.<br />
<br />
<u>Именно UIRD отвечает за то как будут сохраняться ваши данные.</u><br />
<br />
==== Немного теории ====<br />
<br />
Модульными дистрибутивами называются сборки где корневая ФС линукс собирается на этапе initrd из слоев. Каждый из слоев содержит свою часть файлов. <br />
В качестве слоя может быть все что возможно смонтировать в линукс: раздел, папка, iso, img. Но чаще всего это squashfs архивы это и есть модули. <br />
Все эти слои объединяются с пощью aufs/overlayfs в один каталог, который и будет корнем "/" для дальнейшей загрузки дистрибутива. <br />
Все эти слои монтируются read only, кроме последнего, верхнего слоя. Еще немного и будет понятного к чему вся эта предыстория.<br />
Итак. Система загружена, модули RO. А что будет если добавить в систему файл или изменить существующий? Все эти изменения фиксируются в последнем слое,<br />
который мы называем changes. При удалении существующего файла, в changes будет оставлена метка (тень или whiteout), и объединяющая модули ФС будет считать<br />
что этого файла нет. А что может быть смонтировано в верхний слой? Опять же все что можно смонтировать в Линукс с возможностью записи. <br />
<br />
<br />
В UIRD способ работы с верхним слоем, то есть иначе говоря способ сохранения данных между перезагрузками, управляется параметром '''uird.mode'''. Доступно 4 варианта:<br />
<br />
==== uird.mode=clean ====<br />
<br />
Если смонтировать в верхний слой aufs каталог в tmpfs, то все изменения будут храниться в ОЗУ и после выключения исчезнут. Это называем - "чистый режим", в большинстве конфигураций это состояние по умолчанию.<br />
<br />
==== uird.mode=changes ====<br />
<br />
Если смонтировать туда папку на диске или по сети (не принципиально), или файл-образ , то данные будут сохраняться после перезагрузки. Таких папок или файлов может<br />
быть несколько, с разным набором установленного софта и настройками. Эти папки или файлы-образы мы называем - профилями. Такой режим используется <br />
по умолчанию в MagOS. Кроме '''uird.mode=changes''' вам нужно указать где находится файл или папка для сохранений '''uird.chages=/куда/писать''' <br />
(способы указания путей смотрите в [[Barium:UIRD]]) <br />
<br />
==== uird.mode=clear ==== <br />
<br />
Гибридный режиме между clean и changes, слой подключается как для changes, но перед подключением зачищается. То есть для пользователя выглядит как clean, <br />
но не задействует ОЗУ для хранения изменений во время работы системы.<br />
<br />
==== uird.mode=toxzm ====<br />
<br />
Режим добавляющий к режиму clean возможность сохранения. Во время работы изменения пишутся в папку в ОЗУ, (для Бария это блочное устройство zram со сжатием).<br />
При выключении машины эти изменения пакуются в модули. Для включения режима кроме '''uird.mode=toxzm''' нужно передать путь к файлу с настройками режима <br />
'''uird.changes=/где/конфиг.cfg''' и '''uird.shutdown'''.<br />
<br />
Режим имеет возможность очень тонкой настройки сохранений, можно указать для любого файла или папки нужно ли сохранять и в какой модуль.<br />
Для каждого модуля в конфигурационном файле который указываете в uird.changes для этого режима есть отдельная секция состоящая из нескольких параметров.<br />
Название параметра завершается индексом, именно по индексу определяется принадлежность параметра секции. Цифровые индексы должны идти по порядку, <br />
в этом порядке модули подключаются при старте.<br />
<br />
'''XZM''' - имя модуля, если оставить пустым то будет сгенерировано по характеристикам железа, то есть модуль будет иметь свое имя на каждой машине<br />
'''MODE''' - режим подключения модуля при загрузке, варианты: copy, mount, mount+wh.<br />
'''REBULID''' - нужно ли пересобрать модуль при выключении машины, варианты: yes, no, once<br />
'''ADDFILTER''' - фильтры (grep) для получения списка файлов и каталогов, которые нужно сохранить в модуль<br />
'''DROPFILTER''' - фильтры для исключения файлов и каталогов из списка полученного после ADDFILTER<br />
'''SQFSOPT''' - опции для mksquashfs, обычно это алгоритм сжатия и размер блока<br />
'''MAXCOPYSIZE''' - Максимальный размер разрешенный для модуля, после чего параметр MODE модуля будет переведен в 'mount', REBUILD в 'no' и создана новая секция с MODE=copy и REBUILD=yes<br />
<br />
<br />
'''Далее на примере конфигурационного файла из бария:'''<br />
<br />
''Для удобства списки можно заносить в переменные''<br />
<br />
GARBAGE="/var/log /var/spool /var/tmp /var/cache"<br />
PAM="/etc/pam.d /etc/pam_pkcs11 /etc/pki /xdg/autostart/"<br />
<br />
''Сохраняем домашние каталоги пользователей в модуль homes.xzm''<br />
<br />
XZM0="homes.xzm"<br />
MODE0="copy"<br />
REBUILD0="no"<br />
ADDFILTER0="/home"<br />
DROPFILTER0=""<br />
SQFSOPT0='-comp lz4 -b 512k'<br />
MAXCOPYSIZE0=300<br />
<br />
''Системные изменения сохраняем в свой модуль для каждой машины.''<br />
''(если имя для модуля не указано, оно генерируется на основе железа)''<br />
<br />
XZM1=""<br />
MODE1="mount"<br />
REBUILD1="no"<br />
ADDFILTER1=""<br />
DROPFILTER1="$GARBAGE /home " <br />
SQFSOPT1="-comp lz4 -b 512k"<br />
MAXCOPYSIZE1=""<br />
<br />
''Примеры с отключенной пересборкой''<br />
<br />
XZMpam='pam.xzm'<br />
MODEpam='copy'<br />
REBUILDpam='no'<br />
ADDFILTERpam="$PAM"<br />
DROPFILTERpam=""<br />
SQFSOPTpam='-comp xz -b 512k'<br />
MAXCOPYSIZEpam=""<br />
<br />
''Контрольные суммы cts''<br />
<br />
XZMcts='cts.xzm'<br />
MODEcts='copy'<br />
REBUILDcts='no'<br />
ADDFILTERcts="/etc/cts /etc/prelink.conf.d/cts.conf"<br />
DROPFILTERcts=""<br />
SQFSOPTcts='-comp xz -b 512k'<br />
MAXCOPYSIZEcts=""<br />
<br />
<br />
== uird.mounts и uird.home ==<br />
<br />
От части к способам сохранений имеют отношения еще и эти два параметра, позволяющие объединить, например, сохранение части изменений в каталог, а другой части в модуль.<br />
<br />
=== uird.mounts === <br />
<br />
Параметр используется в трех случаях. <br />
* для того, чтобы разгрузить запись в uird.from при сложном вложенном монтировании. Например iso в сети по http, внутри которого файл со squashfs, внутри которого файл с ext3 (стандартная конфигурация для современных исо)<br />
* чтобы организовать автомонтирование раздела для пользователя<br />
* чтобы сделать бинд (mount -o bind) каталога на носителе внутрь системы, а это как раз интересующий нас в контексте темы случай.<br />
Например запись:<br />
<br />
uird.mounts=/my_WWW::MNT=/var/www::MNTOPTS=noexec+rw::FORCE=yes::INIT=yes<br />
<br />
Означает найти в корне доступных на момент загрузки разделов каталог /my_WWW. Найденный каталог будет смонтирован в /.memory/mounts/0 с параметрами noexec,rw, а /var/WWW будет биндом на эту папку.<br />
FORCE=yes означает не прерывать загрузку если каталог /my_WWW не будет найден, а INIT=yes означает в случае если каталог пуст скопировать туда все что есть в модулях в /var/www, то есть как бы инициализировать.<br />
<br />
=== uird.home === <br />
<br />
По сути подмножество uird-mounts для конкретного каталога /home<br />
<br />
uird.home=/dev/sda1/homes<br />
<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F&diff=21019Barium:Системы сохранения2024-02-19T09:37:44Z<p>Betcher: </p>
<hr />
<div>Большая часть особых свойств, что отличают ОС Барий от других дистрибутивов росы, собранных на той же пакетной базе, заложены в [[Barium:UIRD]].<br />
<br />
'''UIRD это init ram disk (initrd)''' собираемый с использованием dracut, но кардинально отличающийся сценарием загрузки ОС. Предназначен<br />
для загрузки модульных дистрибутивов. В настоящее время используется в MagOS, Барии, ublinux, MOS-flash доступен как дополнительный initrd в дистрибутивах puppyrus.<br />
А значит описанное далее в целом справедливо и для них.<br />
<br />
<u>Именно UIRD отвечает за то как будут сохраняться ваши данные.</u><br />
<br />
==== Немного теории ====<br />
<br />
Модульными дистрибутивами называются сборки где корневая ФС линукс собирается на этапе initrd из слоев. Каждый из слоев содержит свою часть файлов. <br />
В качестве слоя может быть все что возможно смонтировать в линукс: раздел, папка, iso, img. Но чаще всего это squashfs архивы это и есть модули. <br />
Все эти слои объединяются с пощью aufs/overlayfs в один каталог, который и будет корнем "/" для дальнейшей загрузки дистрибутива. <br />
Все эти слои монтируются read only, кроме последнего, верхнего слоя. Еще немного и будет понятного к чему вся эта предыстория.<br />
Итак. Система загружена, модули RO. А что будет если добавить в систему файл или изменить существующий? Все эти изменения фиксируются в последнем слое,<br />
который мы называем changes. При удалении существующего файла, в changes будет оставлена метка (тень или whiteout), и объединяющая модули ФС будет считать<br />
что этого файла нет. А что может быть смонтировано в верхний слой? Опять же все что можно смонтировать в Линукс с возможностью записи. <br />
<br />
<br />
В UIRD способ работы с верхним слоем, то есть иначе говоря способ сохранения данных между перезагрузками, управляется параметром '''uird.mode'''. Доступно 4 варианта:<br />
<br />
==== uird.mode=clean ====<br />
<br />
Если смонтировать в верхний слой aufs каталог в tmpfs, то все изменения будут храниться в ОЗУ и после выключения исчезнут. Это называем - "чистый режим", в большинстве конфигураций это состояние по умолчанию.<br />
<br />
==== uird.mode=changes ====<br />
<br />
Если смонтировать туда папку на диске или по сети (не принципиально), или файл-образ , то данные будут сохраняться после перезагрузки. Таких папок или файлов может<br />
быть несколько, с разным набором установленного софта и настройками. Эти папки или файлы-образы мы называем - профилями. Такой режим используется <br />
по умолчанию в MagOS. Кроме '''uird.mode=changes''' вам нужно указать где находится файл или папка для сохранений '''uird.chages=/куда/писать''' <br />
(способы указания путей смотрите в [[Barium:UIRD]]) <br />
<br />
==== uird.mode=clear ==== <br />
<br />
Гибридный режиме между clean и changes, слой подключается как для changes, но перед подключением зачищается. То есть для пользователя выглядит как clean, <br />
но не задействует ОЗУ для хранения изменений во время работы системы.<br />
<br />
==== uird.mode=toxzm ====<br />
<br />
Режим добавляющий к режиму clean возможность сохранения. Во время работы изменения пишутся в папку в ОЗУ, (для Бария это блочное устройство zram со сжатием).<br />
При выключении машины эти изменения пакуются в модули. Для включения режима кроме '''uird.mode=toxzm''' нужно передать путь к файлу с настройками режима <br />
'''uird.changes=/где/конфиг.cfg''' и '''uird.shutdown'''.<br />
<br />
Режим имеет возможность очень тонкой настройки сохранений, можно указать для любого файла или папки нужно ли сохранять и в какой модуль.<br />
Для каждого модуля в конфигурационном файле который указываете в uird.changes для этого режима есть отдельная секция состоящая из нескольких параметров.<br />
Название параметра завершается индексом, именно по индексу определяется принадлежность параметра секции. Цифровые индексы должны идти по порядку, <br />
в этом порядке модули подключаются при старте.<br />
<br />
'''XZM''' - имя модуля, если оставить пустым то будет сгенерировано по характеристикам железа, то есть модуль будет иметь свое имя на каждой машине<br />
'''MODE''' - режим подключения модуля при загрузке, варианты: copy, mount, mount+wh.<br />
'''REBULID''' - нужно ли пересобрать модуль при выключении машины, варианты: yes, no, once<br />
'''ADDFILTER''' - фильтры (grep) для получения списка файлов и каталогов, которые нужно сохранить в модуль<br />
'''DROPFILTER''' - фильтры для исключения файлов и каталогов из списка полученного после ADDFILTER<br />
'''SQFSOPT''' - опции для mksquashfs, обычно это алгоритм сжатия и размер блока<br />
'''MAXCOPYSIZE''' - Максимальный размер разрешенный для модуля, после чего параметр MODE модуля будет переведен в 'mount', REBUILD в 'no' и создана новая секция с MODE=copy и REBUILD=yes<br />
<br />
<br />
'''Далее на примере конфигурационного файла из бария:'''<br />
<br />
''Для удобства списки можно заносить в переменные''<br />
<br />
GARBAGE="/var/log /var/spool /var/tmp /var/cache"<br />
PAM="/etc/pam.d /etc/pam_pkcs11 /etc/pki /xdg/autostart/"<br />
<br />
''Сохраняем домашние каталоги пользователей в модуль homes.xzm''<br />
<br />
XZM0="homes.xzm"<br />
MODE0="copy"<br />
REBUILD0="no"<br />
ADDFILTER0="/home"<br />
DROPFILTER0=""<br />
SQFSOPT0='-comp lz4 -b 512k'<br />
MAXCOPYSIZE0=300<br />
<br />
''Системные изменения сохраняем в свой модуль для каждой машины.''<br />
''(если имя для модуля не указано, оно генерируется на основе железа)''<br />
<br />
XZM1=""<br />
MODE1="mount"<br />
REBUILD1="no"<br />
ADDFILTER1=""<br />
DROPFILTER1="$GARBAGE /home " <br />
SQFSOPT1="-comp lz4 -b 512k"<br />
MAXCOPYSIZE1=""<br />
<br />
''Примеры с отключенной пересборкой''<br />
<br />
XZMpam='pam.xzm'<br />
MODEpam='copy'<br />
REBUILDpam='no'<br />
ADDFILTERpam="$PAM"<br />
DROPFILTERpam=""<br />
SQFSOPTpam='-comp xz -b 512k'<br />
MAXCOPYSIZEpam=""<br />
<br />
''Контрольные суммы cts''<br />
<br />
XZMcts='cts.xzm'<br />
MODEcts='copy'<br />
REBUILDcts='no'<br />
ADDFILTERcts="/etc/cts /etc/prelink.conf.d/cts.conf"<br />
DROPFILTERcts=""<br />
SQFSOPTcts='-comp xz -b 512k'<br />
MAXCOPYSIZEcts=""<br />
<br />
<br />
== uird.mounts и uird.home ==<br />
<br />
От части к способам сохранений имеют отношения еще и эти два параметра, позволяющие объединить например сохранение части изменений в каталог, а другой части в модуль.<br />
<br />
=== uird.mounts === <br />
<br />
Параметр используется в трех случаях. <br />
* для того, чтобы разгрузить запись в uird.from при сложном вложенном монтировании. Например iso в сети по http, внутри которого файл со squashfs, внутри которого файл с ext3 (стандартная конфигурация для современных исо)<br />
* чтобы организовать автомонтирование раздела для пользователя<br />
* чтобы сделать бинд (mount -o bind) каталога на носителе внутрь системы, а это как раз интересующий нас в контексте темы случай.<br />
Например запись:<br />
<br />
uird.mounts=/my_WWW::MNT=/var/www::MNTOPTS=noexec+rw::FORCE=yes::INIT=yes<br />
<br />
Означает найти в корне доступных на момент загрузки разделов каталог /my_WWW. Найденный каталог будет смонтирован в /.memory/mounts/0 с параметрами noexec,rw, а /var/WWW будет биндом на эту папку.<br />
FORCE=yes означает не прерывать загрузку если каталог /my_WWW не будет найден, а INIT=yes означает в случае если каталог пуст скопировать туда все что есть в модулях в /var/www, то есть как бы инициализировать.<br />
<br />
=== uird.home === <br />
<br />
По сути подмножество uird-mounts для конкретного каталога /home<br />
<br />
uird.home=/dev/sda1/homes<br />
<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F&diff=21018Barium:Системы сохранения2024-02-19T09:22:42Z<p>Betcher: </p>
<hr />
<div>Большая часть особых свойств, что отличают ОС Барий от других дистрибутивов росы, собранных на той же пакетной базе, заложены в UIRD.<br />
UIRD это init ram disk (initrd) собираемый с использованием dracut, но кардинально отличающийся сценарием загрузки ОС. Предназначен<br />
для загрузки модульных дистрибутивов. В настоящее время используется в MagOS, Барии, ublinux, MOS-flash доступен как дополнительный initrd в дистрибутивах puppyrus.<br />
А значит описанное далее в целом справедливо и для них.<br />
<br />
<u>Именно UIRD отвечает за то как будут сохраняться ваши данные.</u><br />
<br />
=== Немного теории ===<br />
<br />
Модульными дистрибутивами называются сборки где корневая ФС линукс собирается на этапе initrd из слоев. Каждый из слоев содержит свою часть файлов. <br />
В качестве слоя может быть все что возможно смонтировать в линукс: раздел, папка, iso, img. Но чаще всего это squashfs архивы это и есть модули. <br />
Все эти слои объединяются с пощью aufs/overlayfs в один каталог, который и будет корнем "/" для дальнейшей загрузки дистрибутива. <br />
Все эти слои монтируются read only, кроме последнего, верхнего слоя. Еще немного и будет понятного к чему вся эта предыстория.<br />
Итак. Система загружена, модули RO. А что будет если добавить в систему файл или изменить существующий? Все эти изменения фиксируются в последнем слое,<br />
который мы называем changes. При удалении существующего файла, в changes будет оставлена метка (тень или whiteout), и объединяющая модули ФС будет считать<br />
что этого файла нет. А что может быть смонтировано в верхний слой? Опять же все что можно смонтировать в Линукс с возможностью записи. <br />
<br />
<br />
В UIRD способ работы с верхним слоем, то есть иначе говоря способ сохранения данных между перезагрузками, управляется параметром '''uird.mode'''. Доступно 4 варианта:<br />
<br />
==== uird.mode=clean ====<br />
<br />
Если смонтировать в верхний слой aufs каталог в tmpfs, то все изменения будут храниться в ОЗУ и после выключения исчезнут. Это называем - "чистый режим", в большинстве конфигураций это состояние по умолчанию.<br />
<br />
==== uird.mode=changes ====<br />
<br />
Если смонтировать туда папку на диске или по сети (не принципиально), или файл-образ , то данные будут сохраняться после перезагрузки. Таких папок или файлов может<br />
быть несколько, с разным набором установленного софта и настройками. Эти папки или файлы-образы мы называем - профилями. Такой режим используется <br />
по умолчанию в MagOS. Кроме '''uird.mode=changes''' вам нужно указать где находится файл или папка для сохранений '''uird.chages=/куда/писать''' <br />
(способы указания путей смотрите в [[Barium:UIRD]]) <br />
<br />
=== uird.mode=clear === <br />
<br />
Гибридный режиме между clean и changes, слой подключается как для changes, но перед подключением зачищается. То есть для пользователя выглядит как clean, <br />
но не задействует ОЗУ для хранения изменений во время работы системы.<br />
<br />
=== uird.mode=toxzm ===<br />
<br />
Режим добавляющий к режиму clean возможность сохранения. Во время работы изменения пишутся в папку в ОЗУ, (для Бария это блочное устройство zram со сжатием).<br />
При выключении машины эти изменения пакуются в модули. Для включения режима кроме '''uird.mode=toxzm''' нужно передать путь к файлу с настройками режима <br />
'''uird.changes=/где/конфиг.cfg''' и '''uird.shutdown'''.<br />
<br />
Режим имеет возможность очень тонкой настройки сохранений, можно указать для любого файла или папки нужно ли сохранять и в какой модуль.<br />
Для каждого модуля в конфигурационном файле который указываете в uird.changes для этого режима есть отдельная секция состоящая из нескольких параметров.<br />
Название параметра завершается индексом, именно по индексу определяется принадлежность параметра секции. Цифровые индексы должны идти попорядку, <br />
в этом порядке модули подключаются при старте.<br />
<br />
'''XZM''' - имя модуля, если оставить пустым то будет сгенерировано по характеристикам железа, то есть модуль будет иметь свое имя на каждой машине<br />
'''MODE''' - режим подключения модуля при загрузке, варианты: copy, mount, mount+wh.<br />
'''REBULID''' - нужно ли пересобрать модуль при выключении машины, варианты: yes, no, once<br />
'''ADDFILTER''' - фильтры (grep) для получения списка файлов и каталогов, которые нужно сохранить в модуль<br />
'''DROPFILTER''' - фильтры для исключения файлов и каталогов из списка полученного после ADDFILTER<br />
'''SQFSOPT''' - опции для mksquashfs, обычно это алгоритм сжатия и размер блока<br />
'''MAXCOPYSIZE''' - Максимальный размер разрешенный для модуля, после чего параметр MODE модуля будет переведен в 'mount', REBUILD в 'no' и создана новая секция с MODE=copy и REBUILD=yes<br />
<br />
<br />
'''Далее на примере конфигурационного файла из бария:'''<br />
<br />
''Для удобства списки можно заносить в переменные''<br />
<br />
GARBAGE="/var/log /var/spool /var/tmp /var/cache"<br />
PAM="/etc/pam.d /etc/pam_pkcs11 /etc/pki /xdg/autostart/"<br />
<br />
''Сохраняем домашние каталоги пользователей в модуль homes.xzm''<br />
<br />
XZM0="homes.xzm"<br />
MODE0="copy"<br />
REBUILD0="no"<br />
ADDFILTER0="/home"<br />
DROPFILTER0=""<br />
SQFSOPT0='-comp lz4 -b 512k'<br />
MAXCOPYSIZE0=300<br />
<br />
''Системные изменения сохраняем в свой модуль для каждой машины.''<br />
''(если имя для модуля не указано, оно генерируется на основе железа)''<br />
<br />
XZM1=""<br />
MODE1="mount"<br />
REBUILD1="no"<br />
ADDFILTER1=""<br />
DROPFILTER1="$GARBAGE /home " <br />
SQFSOPT1="-comp lz4 -b 512k"<br />
MAXCOPYSIZE1=""<br />
<br />
''Примеры с отключенной пересборкой''<br />
<br />
XZMpam='pam.xzm'<br />
MODEpam='copy'<br />
REBUILDpam='no'<br />
ADDFILTERpam="$PAM"<br />
DROPFILTERpam=""<br />
SQFSOPTpam='-comp xz -b 512k'<br />
MAXCOPYSIZEpam=""<br />
<br />
''Контрольные суммы cts''<br />
<br />
XZMcts='cts.xzm'<br />
MODEcts='copy'<br />
REBUILDcts='no'<br />
ADDFILTERcts="/etc/cts /etc/prelink.conf.d/cts.conf"<br />
DROPFILTERcts=""<br />
SQFSOPTcts='-comp xz -b 512k'<br />
MAXCOPYSIZEcts=""<br />
<br />
<br />
== uird.mounts и uird.home ==<br />
<br />
От части к способам сохранений имеют отношения еще и эти два параметра, позволяющие объединить например сохранение части изменений в каталог, а другой части в модуль.<br />
<br />
=== uird.mounts === <br />
<br />
Параметр используется в трех случаях. <br />
* для того, чтобы разгрузить запись в uird.from при сложном вложенном монтировании. Например iso в сети по http, внутри которого файл со squashfs, внутри которого файл с ext3 (стандартная конфигурация для современных исо)<br />
* чтобы организовать автомонтирование раздела для пользователя<br />
* чтобы сделать бинд (mount -o bind) каталога на носителе внутрь системы, а это как раз интересующий нас в контексте темы случай.<br />
Например запись:<br />
<br />
uird.mounts=/my_WWW::MNT=/var/www::MNTOPTS=noexec+rw::FORCE=yes::INIT=yes<br />
<br />
Означает найти в корне доступных на момент загрузки разделов каталог /my_WWW. Найденный каталог будет смонтирован в /.memory/mounts/0 с параметрами noexec,rw, а /var/WWW будет биндом на эту папку.<br />
FORCE=yes означает не прерывать загрузку если каталог /my_WWW не будет найден, а INIT=yes означает в случае если каталог пуст скопировать туда все что есть в модулях в /var/www, то есть как бы инициализировать.<br />
<br />
=== uird.home === <br />
<br />
По сути подмножество uird-mounts для конкретного каталога /home<br />
<br />
uird.home=/dev/sda1/homes<br />
<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F&diff=21017Barium:Системы сохранения2024-02-19T09:18:24Z<p>Betcher: </p>
<hr />
<div>Большая часть особых свойств, что отличает ОС Барий от других дистрибутивов росы, собранных на той же пакетной базе, заложены в UIRD.<br />
UIRD это init ram disk (initrd) собираемый с использованием dracut, но кардинально отличающийся сценарием загрузки ОС. Предназначен<br />
для загрузки модульных дистрибутивов. В настоящее время используется в MagOS, Барии, ublinux, доступен как дополнительный initrd в дистрибутивах puppyrus.<br />
<br />
<u>Именно UIRD отвечает за то как будут сохраняться ваши данные.</u><br />
<br />
'''Немного теории чтобы дальше было проще.'''<br />
<br />
Модульными дистрибутивами называются сборки где корневая ФС линукс собирается на этапе initrd из слоев. Каждый из слоев содержит свою часть файлов. <br />
В качестве слоя может быть все что возможно смонтировать в линукс: раздел, папка, iso, img. Но чаще всего это squashfs архивы это и есть модули. <br />
Все эти слои объединяются с пощью aufs/overlayfs в один каталог, который и будет корнем "/" для дальнейшей загрузки дистрибутива. <br />
Все эти слои монтируются read only, кроме последнего, верхнего слоя. Еще немного и будет понятного к чему вся эта предыстория.<br />
Итак. Система загружена, модули RO. А что будет если добавить в систему файл или изменить существующий? Все эти изменения фиксируются в последнем слое,<br />
который мы называем changes. При удалении существующего файла, в changes будет оставлена метка (тень или whiteout), и объединяющая модули ФС будет считать<br />
что этого файла нет. А что может быть смонтировано в верхний слой? Опять же все что можно смонтировать в Линукс с возможностью записи. <br />
<br />
<br />
В UIRD способ работы с верхним слоем, то есть иначе говоря способ сохранения данных между перезагрузками, управляется параметром '''uird.mode'''. Доступно 4 варианта:<br />
<br />
==== uird.mode=clean ====<br />
<br />
Если смонтировать в верхний слой aufs каталог в tmpfs, то все изменения будут храниться в ОЗУ и после выключения исчезнут. Это называем - "чистый режим", в большинстве конфигураций это состояние по умолчанию.<br />
<br />
==== uird.mode=changes ====<br />
<br />
Если смонтировать туда папку на диске или по сети (не принципиально), или файл-образ , то данные будут сохраняться после перезагрузки. Таких папок или файлов может<br />
быть несколько, с разным набором установленного софта и настройками. Эти папки или файлы-образы мы называем - профилями. Такой режим используется <br />
по умолчанию в MagOS. Кроме '''uird.mode=changes''' вам нужно указать где находится файл или папка для сохранений '''uird.chages=/куда/писать''' <br />
(способы указания путей смотрите в [[Barium:UIRD]]) <br />
<br />
=== uird.mode=clear === <br />
<br />
Гибридный режиме между clean и changes, слой подключается как для changes, но перед подключением зачищается. То есть для пользователя выглядит как clean, <br />
но не задействует ОЗУ для хранения изменений во время работы системы.<br />
<br />
=== uird.mode=toxzm ===<br />
<br />
Режим добавляющий к режиму clean возможность сохранения. Во время работы изменения пишутся в папку в ОЗУ, (для Бария это блочное устройство zram со сжатием).<br />
При выключении машины эти изменения пакуются в модули. Для включения режима кроме '''uird.mode=toxzm''' нужно передать путь к файлу с настройками режима <br />
'''uird.changes=/где/конфиг.cfg''' и '''uird.shutdown'''.<br />
<br />
Режим имеет возможность очень тонкой настройки сохранений, можно указать для любого файла или папки нужно ли сохранять и в какой модуль.<br />
Для каждого модуля в конфигурационном файле который указываете в uird.changes для этого режима есть отдельная секция состоящая из нескольких параметров.<br />
Название параметра завершается индексом, именно по индексу определяется принадлежность параметра секции. Цифровые индексы должны идти попорядку, <br />
в этом порядке модули подключаются при старте.<br />
<br />
'''XZM''' - имя модуля, если оставить пустым то будет сгенерировано по характеристикам железа, то есть модуль будет иметь свое имя на каждой машине<br />
'''MODE''' - режим подключения модуля при загрузке, варианты: copy, mount, mount+wh.<br />
'''REBULID''' - нужно ли пересобрать модуль при выключении машины, варианты: yes, no, once<br />
'''ADDFILTER''' - фильтры (grep) для получения списка файлов и каталогов, которые нужно сохранить в модуль<br />
'''DROPFILTER''' - фильтры для исключения файлов и каталогов из списка полученного после ADDFILTER<br />
'''SQFSOPT''' - опции для mksquashfs, обычно это алгоритм сжатия и размер блока<br />
'''MAXCOPYSIZE''' - Максимальный размер разрешенный для модуля, после чего параметр MODE модуля будет переведен в 'mount', REBUILD в 'no' и создана новая секция с MODE=copy и REBUILD=yes<br />
<br />
<br />
'''Далее на примере конфигурационного файла из бария:'''<br />
<br />
''Для удобства списки можно заносить в переменные''<br />
<br />
GARBAGE="/var/log /var/spool /var/tmp /var/cache"<br />
PAM="/etc/pam.d /etc/pam_pkcs11 /etc/pki /xdg/autostart/"<br />
<br />
''Сохраняем домашние каталоги пользователей в модуль homes.xzm''<br />
<br />
XZM0="homes.xzm"<br />
MODE0="copy"<br />
REBUILD0="no"<br />
ADDFILTER0="/home"<br />
DROPFILTER0=""<br />
SQFSOPT0='-comp lz4 -b 512k'<br />
MAXCOPYSIZE0=300<br />
<br />
''Системные изменения сохраняем в свой модуль для каждой машины.''<br />
''(если имя для модуля не указано, оно генерируется на основе железа)''<br />
<br />
XZM1=""<br />
MODE1="mount"<br />
REBUILD1="no"<br />
ADDFILTER1=""<br />
DROPFILTER1="$GARBAGE /home " <br />
SQFSOPT1="-comp lz4 -b 512k"<br />
MAXCOPYSIZE1=""<br />
<br />
''Примеры с отключенной пересборкой''<br />
<br />
XZMpam='pam.xzm'<br />
MODEpam='copy'<br />
REBUILDpam='no'<br />
ADDFILTERpam="$PAM"<br />
DROPFILTERpam=""<br />
SQFSOPTpam='-comp xz -b 512k'<br />
MAXCOPYSIZEpam=""<br />
<br />
''Контрольные суммы cts''<br />
<br />
XZMcts='cts.xzm'<br />
MODEcts='copy'<br />
REBUILDcts='no'<br />
ADDFILTERcts="/etc/cts /etc/prelink.conf.d/cts.conf"<br />
DROPFILTERcts=""<br />
SQFSOPTcts='-comp xz -b 512k'<br />
MAXCOPYSIZEcts=""<br />
<br />
<br />
== uird.mounts и uird.home ==<br />
<br />
От части к способам сохранений имеют отношения еще и эти два параметра, позволяющие объединить например сохранение части изменений в каталог, а другой части в модуль.<br />
<br />
=== uird.mounts === <br />
<br />
Параметр используется в трех случаях. <br />
* для того, чтобы разгрузить запись в uird.from при сложном вложенном монтировании. Например iso в сети по http, внутри которого файл со squashfs, внутри которого файл с ext3 (стандартная конфигурация для современных исо)<br />
* чтобы организовать автомонтирование раздела для пользователя<br />
* чтобы сделать бинд (mount -o bind) каталога на носителе внутрь системы, а это как раз интересующий нас в контексте темы случай.<br />
Например запись:<br />
<br />
uird.mounts=/my_WWW::MNT=/var/www::MNTOPTS=noexec+rw::FORCE=yes::INIT=yes<br />
<br />
Означает найти в корне доступных на момент загрузки разделов каталог /my_WWW. Найденный каталог будет смонтирован в /.memory/mounts/0 с параметрами noexec,rw, а /var/WWW будет биндом на эту папку.<br />
FORCE=yes означает не прерывать загрузку если каталог /my_WWW не будет найден, а INIT=yes означает в случае если каталог пуст скопировать туда все что есть в модулях в /var/www, то есть как бы инициализировать.<br />
<br />
=== uird.home === <br />
<br />
По сути подмножество uird-mounts для конкретного каталога /home<br />
<br />
uird.home=/dev/sda1/homes<br />
<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F&diff=21016Barium:Системы сохранения2024-02-19T08:49:33Z<p>Betcher: й</p>
<hr />
<div>Большая часть особых свойств, что отличает ОС Барий от других дистрибутивов росы, собранных на той же пакетной базе, заложены в UIRD.<br />
UIRD это init ram disk (initrd) собираемый с использованием dracut, но кардинально отличающийся сценарием загрузки ОС. Предназначен<br />
для загрузки модульных дистрибутивов. В настоящее время используется в MagOS, Барии, ublinux, доступен как дополнительный initrd в дистрибутивах puppyrus.<br />
<br />
<u>Именно UIRD отвечает за то как будут сохраняться ваши данные.</u><br />
<br />
'''Немного теории чтобы дальше было проще.'''<br />
<br />
Модульными дистрибутивами называются сборки где корневая ФС линукс собирается на этапе initrd из слоев. Каждый из слоев содержит свою часть файлов. <br />
В качестве слоя может быть все что возможно смонтировать в линукс: раздел, папка, iso, img. Но чаще всего это squashfs архивы это и есть модули. <br />
Все эти слои объединяются с пощью aufs/overlayfs в один каталог, который и будет корнем "/" для дальнейшей загрузки дистрибутива. <br />
Все эти слои монтируются read only, кроме последнего, верхнего слоя. Еще немного и будет понятного к чему вся эта предыстория.<br />
Итак. Система загружена, модули RO. А что будет если добавить в систему файл или изменить существующий? Все эти изменения фиксируются в последнем слое,<br />
который мы называем changes. При удалении существующего файла, в changes будет оставлена метка (тень или whiteout), и объединяющая модули ФС будет считать<br />
что этого файла нет. А что может быть смонтировано в верхний слой? Опять же все что можно смонтировать в Линукс с возможностью записи. <br />
<br />
<br />
В UIRD способ работы с верхним слоем, то есть иначе говоря способ сохранения данных между перезагрузками, управляется параметром '''uird.mode'''. Вариантов несколько:<br />
<br />
* uird.mode=clean<br />
* uird.mode=clear<br />
* uird.mode=changes<br />
* uird.mode=toxzm<br />
<br />
==== uird.mode=clean ====<br />
<br />
Если смонтировать в верхний слой aufs каталог в tmpfs, то все изменения будут храниться в ОЗУ и после выключения исчезнут. Это называем - "чистый режим", в большинстве конфигураций это состояние по умолчанию.<br />
<br />
==== uird.mode=changes ====<br />
<br />
Если смонтировать туда папку на диске или по сети (не принципиально), или файл-образ , то данные будут сохраняться после перезагрузки. Таких папок или файлов может<br />
быть несколько, с разным набором установленного софта и настройками. Эти папки или файлы-образы мы называем - профилями. Такой режим используется <br />
по умолчанию в MagOS. Кроме '''uird.mode=changes''' вам нужно указать где находится файл или папка для сохранений '''uird.chages=/куда/писать''' <br />
(способы указания путей смотрите в [[Barium:UIRD]]) <br />
<br />
<br />
=== uird.mode=clear === <br />
<br />
Гибридный режиме между clean и changes, слой подключается как для changes, но перед подключением зачищается. То есть для пользователя выглядит как clean, <br />
но не задействует ОЗУ для хранения изменений во время работы системы.<br />
<br />
=== uird.mode=toxzm ===<br />
<br />
Режим добавляющий к режиму clean возможность сохранения. Во время работы изменения пишутся в папку в ОЗУ, (для Бария это блочное устройство zram со сжатием).<br />
При выключении машины эти изменения пакуются в модули. Для включения режима кроме '''uird.mode=toxzm''' нужно передать путь к файлу с настройками режима <br />
'''uird.changes=/где/конфиг.cfg''' и '''uird.shutdown'''.<br />
<br />
Режим имеет возможность очень тонкой настройки сохранений, можно указать для любого файла или папки нужно ли сохранять и в какой модуль.<br />
Для каждого модуля в конфигурационном файле который указываете в uird.changes для этого режима есть отдельная секция состоящая из нескольких параметров.<br />
Название параметра завершается индексом, именно по индексу определяется принадлежность параметра секции. Цифровые индексы должны идти попорядку, <br />
в этом порядке модули подключаются при старте.<br />
<br />
'''XZM''' - имя модуля, если оставить пустым то будет сгенерировано по характеристикам железа, то есть модуль будет иметь свое имя на каждой машине<br />
'''MODE''' - режим подключения модуля при загрузке, варианты: copy, mount, mount+wh.<br />
'''REBULID''' - нужно ли пересобрать модуль при выключении машины, варианты: yes, no, once<br />
'''ADDFILTER''' - фильтры (grep) для получения списка файлов и каталогов, которые нужно сохранить в модуль<br />
'''DROPFILTER''' - фильтры для исключения файлов и каталогов из списка полученного после ADDFILTER<br />
'''SQFSOPT''' - опции для mksquashfs, обычно это алгоритм сжатия и размер блока<br />
'''MAXCOPYSIZE''' - Максимальный размер разрешенный для модуля, после чего параметр MODE модуля будет переведен в 'mount', REBUILD в 'no' и создана новая секция с MODE=copy и REBUILD=yes<br />
<br />
<br />
'''Далее на примере конфигурационного файла из бария:'''<br />
<br />
''Для удобства списки можно заносить в переменные''<br />
<br />
GARBAGE="/var/log /var/spool /var/tmp /var/cache"<br />
PAM="/etc/pam.d /etc/pam_pkcs11 /etc/pki /xdg/autostart/"<br />
<br />
''Сохраняем пользовательские данные в модуль homes.xzm''<br />
<br />
XZM0="homes.xzm"<br />
MODE0="copy"<br />
REBUILD0="no"<br />
ADDFILTER0="/home"<br />
DROPFILTER0=""<br />
SQFSOPT0='-comp lz4 -b 512k'<br />
MAXCOPYSIZE0=300<br />
<br />
''Системные изменения сохраняем в свой модуль для каждой машины.''<br />
''(если имя для модуля не указано, оно генерируется на основе железа)''<br />
<br />
XZM1=""<br />
MODE1="mount"<br />
REBUILD1="no"<br />
ADDFILTER1=""<br />
DROPFILTER1="$GARBAGE /home " <br />
SQFSOPT1="-comp lz4 -b 512k"<br />
MAXCOPYSIZE1=""<br />
<br />
''Примеры с отключенной пересборкой''<br />
<br />
XZMpam='pam.xzm'<br />
MODEpam='copy'<br />
REBUILDpam='no'<br />
ADDFILTERpam="$PAM"<br />
DROPFILTERpam=""<br />
SQFSOPTpam='-comp xz -b 512k'<br />
MAXCOPYSIZEpam=""<br />
<br />
''Контрольные суммы cts''<br />
<br />
XZMcts='cts.xzm'<br />
MODEcts='copy'<br />
REBUILDcts='no'<br />
ADDFILTERcts="/etc/cts /etc/prelink.conf.d/cts.conf"<br />
DROPFILTERcts=""<br />
SQFSOPTcts='-comp xz -b 512k'<br />
MAXCOPYSIZEcts=""<br />
<br />
<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=21003Notamock2024-01-16T12:46:26Z<p>Betcher: /* notamock */</p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ d - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
==== Общее ====<br />
* все утилиты требуют прав root, связано c использованием монтирований. Далее по тексту su, sudo опускаются.<br />
* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg (можно использовать собственные с ключом --config /путь/файл.cfg)<br />
* все утилиты имеют встроенный --help<br />
* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров. <br />
* для пересоздания базовой rootfs нужно запустить любую из утилит с ключом -u в момент, когда rootfs не используется другими утилитами notamock. Для обновления rootfs ничего дополнительно делать не нужно.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
* TMPD=/путь/папка - использовать указанный каталог вместо /tmp/notamock, полезно для гигантских проектов для сборки которых не достаточно размера /tmp хоста.<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.<br />
<br />
==== Основной режим ====<br />
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.<br />
<br />
notamockd -t <TOKEN><br />
<br />
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.<br />
<br />
Полезные опции:<br />
<br />
* -p - количество билдеров<br />
* -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.<br />
* -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.<br />
* --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10<br />
* --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.<br />
<br />
Если не указать внешний каталог для сборки (ключ -B), сборки будут идти в /tmp контейнера размер которого установит systemd-nspawn, а это, если не ошибаюсь, 20% от ОЗУ. Альтернативный способ увеличить пространство для сборок - переключить с systemd-nspawn на встроенный в notamock способ использующий chroot - CHROOT=INTERNAL, в таком случае для сборок будет доступно все пространство /tmp хоста. Дополнительно можно указать TMPD=/папка/на/диске если нужно чтобы контейнеры вообще не использовали /tmp системы.<br />
<br />
==== Образ для докера ====<br />
<br />
dnf install docker<br />
systemctl start docker<br />
notamockd --docker -b имя_для_билдера<br />
docker image ls # находим свой образ<br />
docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID><br />
<br />
Внимание: без '''-v /хост/папка/:/tmp''' работать не будет из-за необходимости монтирования overlayfs внутри контейнера.<br />
<br />
=== notamockc === <br />
<br />
Если вам понадобилась rootfs не нужно качать с абф и или собирать просто запустите.<br />
<br />
notamockc<br />
<br />
или<br />
<br />
notamockc -r 2023.1<br />
<br />
Можно передать команду:<br />
<br />
notamockc -r 2023.1 -- dnf provides thunderbird<br />
<br />
Команда будет выполнена в chroot с rosa2023.1</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=21002Notamock2024-01-16T12:42:28Z<p>Betcher: /* Основной режим */</p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ d - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
==== Общее ====<br />
* все утилиты требуют прав root, связано c использованием монтирований. Далее по тексту su, sudo опускаются.<br />
* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg (можно использовать собственные с ключом --config /путь/файл.cfg)<br />
* все утилиты имеют встроенный --help<br />
* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров. <br />
* для пересоздания базовой rootfs нужно запустить любую из утилит с ключом -u в момент, когда rootfs не используется другими утилитами notamock. Для обновления rootfs ничего дополнительно делать не нужно.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.<br />
<br />
==== Основной режим ====<br />
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.<br />
<br />
notamockd -t <TOKEN><br />
<br />
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.<br />
<br />
Полезные опции:<br />
<br />
* -p - количество билдеров<br />
* -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.<br />
* -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.<br />
* --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10<br />
* --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.<br />
<br />
Если не указать внешний каталог для сборки (ключ -B), сборки будут идти в /tmp контейнера размер которого установит systemd-nspawn, а это, если не ошибаюсь, 20% от ОЗУ. Альтернативный способ увеличить пространство для сборок - переключить с systemd-nspawn на встроенный в notamock способ использующий chroot - CHROOT=INTERNAL, в таком случае для сборок будет доступно все пространство /tmp хоста. Дополнительно можно указать TMPD=/папка/на/диске если нужно чтобы контейнеры вообще не использовали /tmp системы.<br />
<br />
==== Образ для докера ====<br />
<br />
dnf install docker<br />
systemctl start docker<br />
notamockd --docker -b имя_для_билдера<br />
docker image ls # находим свой образ<br />
docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID><br />
<br />
Внимание: без '''-v /хост/папка/:/tmp''' работать не будет из-за необходимости монтирования overlayfs внутри контейнера.<br />
<br />
=== notamockc === <br />
<br />
Если вам понадобилась rootfs не нужно качать с абф и или собирать просто запустите.<br />
<br />
notamockc<br />
<br />
или<br />
<br />
notamockc -r 2023.1<br />
<br />
Можно передать команду:<br />
<br />
notamockc -r 2023.1 -- dnf provides thunderbird<br />
<br />
Команда будет выполнена в chroot с rosa2023.1</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=21001Notamock2024-01-14T12:19:11Z<p>Betcher: /* Общее */</p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ d - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
==== Общее ====<br />
* все утилиты требуют прав root, связано c использованием монтирований. Далее по тексту su, sudo опускаются.<br />
* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg (можно использовать собственные с ключом --config /путь/файл.cfg)<br />
* все утилиты имеют встроенный --help<br />
* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров. <br />
* для пересоздания базовой rootfs нужно запустить любую из утилит с ключом -u в момент, когда rootfs не используется другими утилитами notamock. Для обновления rootfs ничего дополнительно делать не нужно.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.<br />
<br />
==== Основной режим ====<br />
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.<br />
<br />
notamockd -t <TOKEN><br />
<br />
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.<br />
<br />
Полезные опции:<br />
<br />
* -p - количество билдеров<br />
* -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.<br />
* -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.<br />
* --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10<br />
* --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.<br />
<br />
==== Образ для докера ====<br />
<br />
dnf install docker<br />
systemctl start docker<br />
notamockd --docker -b имя_для_билдера<br />
docker image ls # находим свой образ<br />
docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID><br />
<br />
Внимание: без '''-v /хост/папка/:/tmp''' работать не будет из-за необходимости монтирования overlayfs внутри контейнера.<br />
<br />
=== notamockc === <br />
<br />
Если вам понадобилась rootfs не нужно качать с абф и или собирать просто запустите.<br />
<br />
notamockc<br />
<br />
или<br />
<br />
notamockc -r 2023.1<br />
<br />
Можно передать команду:<br />
<br />
notamockc -r 2023.1 -- dnf provides thunderbird<br />
<br />
Команда будет выполнена в chroot с rosa2023.1</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=21000Notamock2024-01-14T12:13:39Z<p>Betcher: /* Notamock - набор утилит создающих окружения для сборки rpm пакетов. */</p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ d - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
==== Общее ====<br />
* все утилиты требуют прав root, связано c использованием монтирований. Далее по тексту su, sudo опускаются.<br />
* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg<br />
* все утилиты имеют встроенный --help<br />
* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров. <br />
* для пересоздания базовой rootfs нужно запустить любую из утилит с ключом -u в момент, когда rootfs не используется другими утилитами notamock. Для обновления rootfs ничего дополнительно делать не нужно.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.<br />
<br />
==== Основной режим ====<br />
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.<br />
<br />
notamockd -t <TOKEN><br />
<br />
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.<br />
<br />
Полезные опции:<br />
<br />
* -p - количество билдеров<br />
* -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.<br />
* -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.<br />
* --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10<br />
* --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.<br />
<br />
==== Образ для докера ====<br />
<br />
dnf install docker<br />
systemctl start docker<br />
notamockd --docker -b имя_для_билдера<br />
docker image ls # находим свой образ<br />
docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID><br />
<br />
Внимание: без '''-v /хост/папка/:/tmp''' работать не будет из-за необходимости монтирования overlayfs внутри контейнера.<br />
<br />
=== notamockc === <br />
<br />
Если вам понадобилась rootfs не нужно качать с абф и или собирать просто запустите.<br />
<br />
notamockc<br />
<br />
или<br />
<br />
notamockc -r 2023.1<br />
<br />
Можно передать команду:<br />
<br />
notamockc -r 2023.1 -- dnf provides thunderbird<br />
<br />
Команда будет выполнена в chroot с rosa2023.1</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20999Notamock2024-01-14T12:12:22Z<p>Betcher: /* notamockc */</p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
==== Общее ====<br />
* все утилиты требуют прав root, связано c использованием монтирований. Далее по тексту su, sudo опускаются.<br />
* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg<br />
* все утилиты имеют встроенный --help<br />
* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров. <br />
* для пересоздания базовой rootfs нужно запустить любую из утилит с ключом -u в момент, когда rootfs не используется другими утилитами notamock. Для обновления rootfs ничего дополнительно делать не нужно.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.<br />
<br />
==== Основной режим ====<br />
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.<br />
<br />
notamockd -t <TOKEN><br />
<br />
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.<br />
<br />
Полезные опции:<br />
<br />
* -p - количество билдеров<br />
* -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.<br />
* -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.<br />
* --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10<br />
* --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.<br />
<br />
==== Образ для докера ====<br />
<br />
dnf install docker<br />
systemctl start docker<br />
notamockd --docker -b имя_для_билдера<br />
docker image ls # находим свой образ<br />
docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID><br />
<br />
Внимание: без '''-v /хост/папка/:/tmp''' работать не будет из-за необходимости монтирования overlayfs внутри контейнера.<br />
<br />
=== notamockc === <br />
<br />
Если вам понадобилась rootfs не нужно качать с абф и или собирать просто запустите.<br />
<br />
notamockc<br />
<br />
или<br />
<br />
notamockc -r 2023.1<br />
<br />
Можно передать команду:<br />
<br />
notamockc -r 2023.1 -- dnf provides thunderbird<br />
<br />
Команда будет выполнена в chroot с rosa2023.1</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20998Notamock2024-01-14T11:56:29Z<p>Betcher: /* Общее */</p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
==== Общее ====<br />
* все утилиты требуют прав root, связано c использованием монтирований. Далее по тексту su, sudo опускаются.<br />
* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg<br />
* все утилиты имеют встроенный --help<br />
* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров. <br />
* для пересоздания базовой rootfs нужно запустить любую из утилит с ключом -u в момент, когда rootfs не используется другими утилитами notamock. Для обновления rootfs ничего дополнительно делать не нужно.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.<br />
<br />
==== Основной режим ====<br />
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.<br />
<br />
notamockd -t <TOKEN><br />
<br />
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.<br />
<br />
Полезные опции:<br />
<br />
* -p - количество билдеров<br />
* -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.<br />
* -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.<br />
* --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10<br />
* --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.<br />
<br />
==== Образ для докера ====<br />
<br />
dnf install docker<br />
systemctl start docker<br />
notamockd --docker -b имя_для_билдера<br />
docker image ls # находим свой образ<br />
docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID><br />
<br />
Внимание: без '''-v /хост/папка/:/tmp''' работать не будет из-за необходимости монтирования overlayfs внутри контейнера.<br />
<br />
=== notamockc === <br />
<br />
Если вам понадобилась rootfs не нужно качать с абф и или собирать просто запустите.<br />
<br />
notamockc<br />
<br />
или<br />
<br />
notamockc -r 2023.1<br />
<br />
Можно передать команду:<br />
<br />
notamockc -r 2023.1 -- dnf provides thunderbird</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20997Notamock2024-01-14T11:53:01Z<p>Betcher: /* Общее */</p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
==== Общее ====<br />
<br />
* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg<br />
* все утилиты имеют встроенный --help<br />
* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров. <br />
* для пересоздания базовой rootfs нужно запустить любую из утилит с ключом -u в момент, когда rootfs не используется другими утилитами notamock. Для обновления rootfs ничего дополнительно делать не нужно.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.<br />
<br />
==== Основной режим ====<br />
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.<br />
<br />
notamockd -t <TOKEN><br />
<br />
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.<br />
<br />
Полезные опции:<br />
<br />
* -p - количество билдеров<br />
* -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.<br />
* -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.<br />
* --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10<br />
* --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.<br />
<br />
==== Образ для докера ====<br />
<br />
dnf install docker<br />
systemctl start docker<br />
notamockd --docker -b имя_для_билдера<br />
docker image ls # находим свой образ<br />
docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID><br />
<br />
Внимание: без '''-v /хост/папка/:/tmp''' работать не будет из-за необходимости монтирования overlayfs внутри контейнера.<br />
<br />
=== notamockc === <br />
<br />
Если вам понадобилась rootfs не нужно качать с абф и или собирать просто запустите.<br />
<br />
notamockc<br />
<br />
или<br />
<br />
notamockc -r 2023.1<br />
<br />
Можно передать команду:<br />
<br />
notamockc -r 2023.1 -- dnf provides thunderbird</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20996Notamock2024-01-14T11:50:53Z<p>Betcher: </p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
==== Общее ====<br />
<br />
* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg<br />
* все утилиты имеют встроенный --help<br />
* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере будут используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров. <br />
* для пересоздания базовой rootfs нужно запустить любую из утилит с ключом -u в момент, когда rootfs не используется другими утилитами notamock. Для обновления rootfs ничего дополнительно делать не нужно.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.<br />
<br />
==== Основной режим ====<br />
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.<br />
<br />
notamockd -t <TOKEN><br />
<br />
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.<br />
<br />
Полезные опции:<br />
<br />
* -p - количество билдеров<br />
* -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.<br />
* -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.<br />
* --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10<br />
* --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.<br />
<br />
==== Образ для докера ====<br />
<br />
dnf install docker<br />
systemctl start docker<br />
notamockd --docker -b имя_для_билдера<br />
docker image ls # находим свой образ<br />
docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID><br />
<br />
Внимание: без '''-v /хост/папка/:/tmp''' работать не будет из-за необходимости монтирования overlayfs внутри контейнера.<br />
<br />
=== notamockc === <br />
<br />
Если вам понадобилась rootfs не нужно качать с абф и или собирать просто запустите.<br />
<br />
notamockc<br />
<br />
или<br />
<br />
notamockc -r 2023.1<br />
<br />
Можно передать команду:<br />
<br />
notamockc -r 2023.1 -- dnf provides thunderbird</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20995Notamock2024-01-14T11:26:51Z<p>Betcher: /* notamockd */</p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.<br />
<br />
==== Основной режим ====<br />
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.<br />
<br />
notamockd -t <TOKEN><br />
<br />
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.<br />
<br />
Полезные опции:<br />
<br />
* -p - количество билдеров<br />
* -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.<br />
* -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.<br />
* --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10<br />
* --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.<br />
<br />
==== Образ для докера ====<br />
<br />
dnf install docker<br />
systemctl start docker<br />
notamockd --docker -b имя_для_билдера<br />
docker image ls # находим свой образ<br />
docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID><br />
<br />
Внимание: без '''-v /хост/папка/:/tmp''' работать не будет из-за необходимости монтирования overlayfs внутри контейнера.</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20994Notamock2024-01-14T10:36:28Z<p>Betcher: </p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей, например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера<br />
<br />
Более подробно в notamock --help и cat /etc/notamock.cfg.<br />
В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.<br />
<br />
=== notamocks ===<br />
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:<br />
<br />
notamocks<br />
<br />
Полезные опции:<br />
<br />
* -p - количество параллельно запускаемых сборок<br />
* -s - не собирать проекты, который уже собраны<br />
* -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.<br />
* -l -каталог для логов<br />
<br />
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock. <br />
<br />
=== notamockd ===<br />
<br />
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты.<br />
<br />
Notamockd имеет два режима работы.<br />
# Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.<br />
# notamockd создает образ для docker, а контейнер запускает докер.</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20993Notamock2024-01-14T10:11:00Z<p>Betcher: </p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -r - сборка для платформы отличной от текущей например: -r 2023.1<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, достаточно сделать копию спека с другим именем.<br />
* RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.<br />
* REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:<br />
# контейнер будет сброшен если запустить сборку без REUSABLE=yes<br />
# контейнер будет сброшен если запустить сборку другого проекта<br />
* PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20992Notamock2024-01-14T09:57:02Z<p>Betcher: </p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.<br />
<br />
=== notamock ===<br />
<br />
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. <br />
Например для локальной пересборки текущей версии lsof можно использовать такие команды:<br />
<br />
dnf install abb notamock<br />
abb clone lsof<br />
cd lsof<br />
notamock<br />
<br />
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее.<br />
notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:<br />
<br />
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes<br />
<br />
Наиболее полезные, на мой взгляд, опции:<br />
<br />
* -v - более подробный выхлоп<br />
* -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента: <br />
# не работает совместно с ключом -v<br />
# измененный вами спек при выходе из этого режима (exit) не сохранится, достаточно сделать копию спека с другим именем.</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20991Notamock2024-01-14T09:38:18Z<p>Betcher: </p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки rpm пакетов. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf<br />
<br />
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. <br />
Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Notamock&diff=20990Notamock2024-01-14T09:33:37Z<p>Betcher: Новая страница: «== Notamock - набор утилит создающих окружения для сборки пакетов с rpmbuild. == Частично пересека…»</p>
<hr />
<div>== Notamock - набор утилит создающих окружения для сборки пакетов с rpmbuild. ==<br />
<br />
Частично пересекается по задачам с mock, отсюда и название.<br />
<br />
* notamock - утилита для запуска одиночного процесса локальной сборки проекта<br />
* notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock<br />
* notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash<br />
* notamockd - (+ в - от daemon) утилита для создания контейнеров для сборки с abf<br />
* notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:utils&diff=20649Barium:utils2023-09-20T08:35:41Z<p>Betcher: </p>
<hr />
<div>=== Barium-utils === <br />
набор скриптов для управления модулями и другими компонентами дистрибутивов Роса "Барий". <br />
<br />
<br />
'''Базовый набор включает:''' <br />
<br />
* barium - "точка входа". Единый скрипт запуска для остальных утилит. Только для него есть ссылка в $PATH, все остальные запускаются с его помощью. Например:<br />
<br />
barium ls <br />
<br />
* b-lib - библиотека, которую используют скрипты barium-utils, без параметров выведет список доступных функций. Некоторые из них можно использовать отдельно. Например:<br />
<br />
barium b-lib getHash ваш_пароль<br />
<br />
создаст хэш пароля в таком виде как он записывается в /etc/shadow, можно использовать для генерации хэша пароля пользователя и root для Rosa.ini<br />
<br />
* ls - список подключенных модулей<br />
<br />
* add - утилита для подключения модуля "на горячую", работает только при загрузке с aufs. Аналог pfsload (pfs-utils), activate (MagOS)<br />
<br />
* rm - утилита для отключения модуля "на горячую", работает только при загрузке с aufs. Аналог pfsunload (pfs-utils), deactivate (MagOS)<br />
<br />
* modinfo - получение информации о модуле. Аналог pfsinfo (pfs-utils)<br />
<br />
* find - поиск файла по подключенным модулям<br />
<br />
* mkmod - создание модуля из папки. Сборка составных модулей. Аналог mkpfs (pfs-utils) <br />
<br />
* splitmod - разборка составных модулей. Аналог pfsextract (pfs-utils)<br />
<br />
* dnf2mod - сборка модулей из пакетов находящихся в репозиториях с использованием dnf. Аналог dnf2xzm (MagOS)<br />
<br />
* chroot2mod - сборка модулей по сценарию выполняемому в chroot'e, аналогичном базовой системе. Аналог chroot2pfs (pfs-utils)<br />
<br />
* diff-changes - утилита позволяет вычислять изменения в changes за определенный период и создавать из изменений модуль Аналог syschanges (MagOS)<br />
<br />
* getmod - поиск и скачивание модулей из репозитория модулей<br />
<br />
* instmod - установка модуля в систему (локальные файлы, а также rsync и протоколы которые понимает wget) <br />
<br />
* comparator - утилита для объединения одинаковых текстовых файлов находящихся в разных модулях. В первую очередь это касается /etc/shadow, /etc/group, /etc/passwd.<br />
При создании модуля может создаваться пользователь. Если таких модулей несколько, то <br />
<br />
barium comparator -i /etc/shadow /etc/group /etc/passwd<br />
<br />
поможет собрать пользователей по модулям<br />
<br />
* marriage - утилита для управления привязкой Бария к машинам.<br />
<br />
* update - утилита для обновления системы<br />
<br />
* applet - апплет в трей, показывает состояние системы управляет основными функциями ОС Барий<br />
<br />
<br />
'''В версии для установки на токен дополнительно доступны:'''<br />
<br />
* install - консольный инсталлятор бария на токен с привязкой логина к пинкоду<br />
<br />
* install-gui - GUI для barium install<br />
* login - консольная утилита для привязки логина в систему к пинкоду токена<br />
* setup - утилита используемая из install-gui для настройки при первом старте предустановленной на токен ОС Барий<br />
* token - вспомогательная для barium login утилита для определения типа токена<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%B2%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F&diff=20647Barium:виртуализация2023-09-18T06:50:06Z<p>Betcher: /* Запуск ОС из распакованного архива */</p>
<hr />
<div>=== Запуск Бария в виртуальных машинах ===<br />
Сборки Бария распространяются архивами tar.gz и в формате iso. Второй вполне подходит для запуска в виртуальных машинах, но речь здесь пойдет о другом.<br />
simple-install, это скрипт, который используется для установки Бария, не такой уж и simple, как оказалось :), и может быть использован для генерации готового образа для виртуальной машины. <br />
С разделом для хранения данных, с шифрованием, свопом, блэкджеком и проч. На момент написания статьи поддерживается создание образов в формате qcow2 и "сырых" образов img.<br />
simple-install содержит готовый конфиг для образов виртуальных машин, но можно задать все необходимые параметры вручную. Рассмотрим оба варианта. Для такой сборки дополнительно к <br />
обычному списку пакетов для simple-install в системе понадобится пакет qemu-img (точнее исполняемые qemu-img, qemu-nbd в системах отличных от Росы имена пакетов могут отличаться).<br />
<br />
=== Сборка по готовому шаблону. ===<br />
<br />
'''simple-install --qimage 10000 -t virt -p 123qwe'''<br />
<br />
здесь: <br />
<br />
'''--qimage 10000''' - установка в образ qcow2 размером 10000M (образ динамический,реально займет пару гигабайт)<br />
'''-t virt''' - использовать встроенный шаблон virt <br />
'''-p 123qwe''' - пароль для раздела luks<br />
<br />
=== Сборка по шаблону с изменениями. ===<br />
<br />
'''simple-install --qimage 10000 -t virt ROSA-DATA=3:x:ext4 --flags overlay'''<br />
<br />
здесь: <br />
<br />
'''ROSA-DATA=3:x:ext4''' - задает параметры для третьего раздела с ROSA-DATA, а именно ext4 вместо luks по этому пароль задавать не нужно.<br />
'''--flags overlay''' - заменить список флагов (файлы маркеры для конфига grub2) на свой, по дефолту для -t virt там есть флаг luks<br />
<br />
=== Сборка со своими значениями ===<br />
<br />
simple-install --qimage 10000 -t none boot=1:100:vfat ROSA-SYSTEM=2:8000:ext3 ROSA-DATA=2 SWAP=3:x:swap --flags aufs<br />
<br />
здесь:<br />
<br />
'''-t none''' - не использовать шаблон<br />
<br />
=== Для запуска такого образа с qemu нужны приблизительно такие параметры: ===<br />
<br />
qemu-system-x86_64 \<br />
-boot c \<br />
-enable-kvm \<br />
-name "BARIUM" \<br />
-smp 2 \<br />
-m 3G \<br />
-vga std \<br />
-rtc base=localtime \<br />
-hda ./OS.img<br />
<br />
=== При установке в virt-manager: === <br />
<br />
- выбираем "Импорт образа диска", <br />
- добавляем папку с образом как хранилище, выбираем наш образ, <br />
- тип "generic linux 2020", <br />
- Память, процессоры и прочие настройки - по желанию<br />
<br />
'''Установка завершена'''<br />
'''записываем в Rosa.ini явки, пароли и можно пользоваться'''<br />
<br />
=== PXE загрузка ===<br />
<br />
Можно пойти дальше и сделать так чтобы с Бария, установленного выше описанным способом, загружалось по PXE нужное количество виртуальных машин, которые могут даже не иметь своего виртуального диска.<br />
Для такой загрузки подготовлен специальный модуль, в котором есть необходимый софт и минимальные настройки. Далее описывается последовательность действий на примере virt-manager.<br />
<br />
* Создаем образ для загрузки Бария, который будет нашим PXE, NFS, DHCP сервером в локальной, для виртуальных машин, сети. Далее Сервер. <br />
Чтобы не иметь проблем с указанием источника содержащего ROSA-DATA, устанавливаем барий на три раздела.<br />
<br />
* Загружаем образ. Переходим в консоли в папку /.memory/layer-base/1/modules и<br />
<br />
'''barium getmod pxeboot.xzm''' <br />
<br />
* В файле /.memory/layer-base/1/Rosa.ini раскомментируем:<br />
<br />
'''ROUTER=yes'''<br />
<br />
Выключаем виртуальную машину. Модуль у нас есть, переходим к настройкам virt-manager:<br />
<br />
* Главное окно Virt-manager. Переходим к вкладке: Правка - Свойства подключения - Виртуальные сети<br />
<br />
* Жмем плюс. Название: любое например pxe, Режим: Изолированный, Все остальные галки нужно убрать<br />
<br />
* В главном окне virt-manager жмем по иконке нашего Сервера, откроется окно, не запуская переходим к настройкам (голубой флажок в панели)<br />
<br />
* Удаляем все сетевые устройства. Скорее всего там одно дефолтное с NAТ.<br />
<br />
* Жмем плюс, выбираем новое сетевое устройство. В пункте "Создать на базе" выбираем ранее созданную сеть "pxe"<br />
<br />
* Аналогично добавляем еще одно сетевое устройство, только на этот раз с NAT.<br />
<br />
Сервер готов, можно загрузить.<br />
<br />
Переходим к клиентам.<br />
<br />
* Главное окно virt-manager. Создать новую виртуальную машину. Установка вручную. Тип машины Generic Linux 2020. Память и процессоры по желанию.<br />
<br />
* В настройках хранилища убираем галку с создания и не выбираем готовых образов (потом добавим если нужно)<br />
<br />
* В последнем меню нужно поставить галку в графе "проверить конфигурацию перед установкой"<br />
<br />
* В меню настроек нужно также удалить сетевое устройство по умолчанию и добавить наше "pxe". Второе сетевое устройство здесь не понадобится.<br />
<br />
* Там же в меню настроек выбрать "Загрузка" и поставить галочку напротив нашей сети<br />
<br />
Готово. Можно грузить.<br />
<br />
Таких виртуальных машин можно запустить столько сколько позволит ваше ОЗУ.<br />
<br />
Чтобы такие машины могли сохранять данные при работе можно подключать к ним образы qcow2. Готовый образ для данных можно генерировать также как и основной с simple-install<br />
<br />
'''simple-install --qimage 4000 -t none ROSA-DATA=1:3000:ext4 SWAP=2:x:swap'''<br />
<br />
Такой образ подключается к каждой машине отдельно и хранит только изменения сделанные во время работы системы.<br />
<br />
Либо данные могут писаться по nfs на Сервер, в пунктах загрузки есть пример где так подключается /home. <br />
<br />
=== Запуск ОС из распакованного архива ===<br />
<br />
''доступен только в коммерческой версии''<br />
<br />
* Распаковываем tar.gz архив со сборкой в папку под ОС linux<br />
* Проверяем наличие в системе qemu-system-x86_64, при отсутствии останавливаем qemu<br />
* Переходим в папку куда распакован Барий<br />
* Запускаем<br />
<br />
'''./qemurun'''<br />
* Способ позволяет установить ОС на токен без создания установочной флешки, для этого передаем скрипту файл устройства носителя (токена)<br />
<br />
'''./qemurun /dev/sda'''<br />
<br />
* Далее аналогично установке с флешки, то есть запускаем графический инсталлятор, заполняем поля с явками и паролями и жмем "Выполнить"<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%B2%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F&diff=20646Barium:виртуализация2023-09-18T06:46:12Z<p>Betcher: </p>
<hr />
<div>=== Запуск Бария в виртуальных машинах ===<br />
Сборки Бария распространяются архивами tar.gz и в формате iso. Второй вполне подходит для запуска в виртуальных машинах, но речь здесь пойдет о другом.<br />
simple-install, это скрипт, который используется для установки Бария, не такой уж и simple, как оказалось :), и может быть использован для генерации готового образа для виртуальной машины. <br />
С разделом для хранения данных, с шифрованием, свопом, блэкджеком и проч. На момент написания статьи поддерживается создание образов в формате qcow2 и "сырых" образов img.<br />
simple-install содержит готовый конфиг для образов виртуальных машин, но можно задать все необходимые параметры вручную. Рассмотрим оба варианта. Для такой сборки дополнительно к <br />
обычному списку пакетов для simple-install в системе понадобится пакет qemu-img (точнее исполняемые qemu-img, qemu-nbd в системах отличных от Росы имена пакетов могут отличаться).<br />
<br />
=== Сборка по готовому шаблону. ===<br />
<br />
'''simple-install --qimage 10000 -t virt -p 123qwe'''<br />
<br />
здесь: <br />
<br />
'''--qimage 10000''' - установка в образ qcow2 размером 10000M (образ динамический,реально займет пару гигабайт)<br />
'''-t virt''' - использовать встроенный шаблон virt <br />
'''-p 123qwe''' - пароль для раздела luks<br />
<br />
=== Сборка по шаблону с изменениями. ===<br />
<br />
'''simple-install --qimage 10000 -t virt ROSA-DATA=3:x:ext4 --flags overlay'''<br />
<br />
здесь: <br />
<br />
'''ROSA-DATA=3:x:ext4''' - задает параметры для третьего раздела с ROSA-DATA, а именно ext4 вместо luks по этому пароль задавать не нужно.<br />
'''--flags overlay''' - заменить список флагов (файлы маркеры для конфига grub2) на свой, по дефолту для -t virt там есть флаг luks<br />
<br />
=== Сборка со своими значениями ===<br />
<br />
simple-install --qimage 10000 -t none boot=1:100:vfat ROSA-SYSTEM=2:8000:ext3 ROSA-DATA=2 SWAP=3:x:swap --flags aufs<br />
<br />
здесь:<br />
<br />
'''-t none''' - не использовать шаблон<br />
<br />
=== Для запуска такого образа с qemu нужны приблизительно такие параметры: ===<br />
<br />
qemu-system-x86_64 \<br />
-boot c \<br />
-enable-kvm \<br />
-name "BARIUM" \<br />
-smp 2 \<br />
-m 3G \<br />
-vga std \<br />
-rtc base=localtime \<br />
-hda ./OS.img<br />
<br />
=== При установке в virt-manager: === <br />
<br />
- выбираем "Импорт образа диска", <br />
- добавляем папку с образом как хранилище, выбираем наш образ, <br />
- тип "generic linux 2020", <br />
- Память, процессоры и прочие настройки - по желанию<br />
<br />
'''Установка завершена'''<br />
'''записываем в Rosa.ini явки, пароли и можно пользоваться'''<br />
<br />
=== PXE загрузка ===<br />
<br />
Можно пойти дальше и сделать так чтобы с Бария, установленного выше описанным способом, загружалось по PXE нужное количество виртуальных машин, которые могут даже не иметь своего виртуального диска.<br />
Для такой загрузки подготовлен специальный модуль, в котором есть необходимый софт и минимальные настройки. Далее описывается последовательность действий на примере virt-manager.<br />
<br />
* Создаем образ для загрузки Бария, который будет нашим PXE, NFS, DHCP сервером в локальной, для виртуальных машин, сети. Далее Сервер. <br />
Чтобы не иметь проблем с указанием источника содержащего ROSA-DATA, устанавливаем барий на три раздела.<br />
<br />
* Загружаем образ. Переходим в консоли в папку /.memory/layer-base/1/modules и<br />
<br />
'''barium getmod pxeboot.xzm''' <br />
<br />
* В файле /.memory/layer-base/1/Rosa.ini раскомментируем:<br />
<br />
'''ROUTER=yes'''<br />
<br />
Выключаем виртуальную машину. Модуль у нас есть, переходим к настройкам virt-manager:<br />
<br />
* Главное окно Virt-manager. Переходим к вкладке: Правка - Свойства подключения - Виртуальные сети<br />
<br />
* Жмем плюс. Название: любое например pxe, Режим: Изолированный, Все остальные галки нужно убрать<br />
<br />
* В главном окне virt-manager жмем по иконке нашего Сервера, откроется окно, не запуская переходим к настройкам (голубой флажок в панели)<br />
<br />
* Удаляем все сетевые устройства. Скорее всего там одно дефолтное с NAТ.<br />
<br />
* Жмем плюс, выбираем новое сетевое устройство. В пункте "Создать на базе" выбираем ранее созданную сеть "pxe"<br />
<br />
* Аналогично добавляем еще одно сетевое устройство, только на этот раз с NAT.<br />
<br />
Сервер готов, можно загрузить.<br />
<br />
Переходим к клиентам.<br />
<br />
* Главное окно virt-manager. Создать новую виртуальную машину. Установка вручную. Тип машины Generic Linux 2020. Память и процессоры по желанию.<br />
<br />
* В настройках хранилища убираем галку с создания и не выбираем готовых образов (потом добавим если нужно)<br />
<br />
* В последнем меню нужно поставить галку в графе "проверить конфигурацию перед установкой"<br />
<br />
* В меню настроек нужно также удалить сетевое устройство по умолчанию и добавить наше "pxe". Второе сетевое устройство здесь не понадобится.<br />
<br />
* Там же в меню настроек выбрать "Загрузка" и поставить галочку напротив нашей сети<br />
<br />
Готово. Можно грузить.<br />
<br />
Таких виртуальных машин можно запустить столько сколько позволит ваше ОЗУ.<br />
<br />
Чтобы такие машины могли сохранять данные при работе можно подключать к ним образы qcow2. Готовый образ для данных можно генерировать также как и основной с simple-install<br />
<br />
'''simple-install --qimage 4000 -t none ROSA-DATA=1:3000:ext4 SWAP=2:x:swap'''<br />
<br />
Такой образ подключается к каждой машине отдельно и хранит только изменения сделанные во время работы системы.<br />
<br />
Либо данные могут писаться по nfs на Сервер, в пунктах загрузки есть пример где так подключается /home. <br />
<br />
=== Запуск ОС из распакованного архива ===<br />
<br />
''доступен только в коммерческой версии''<br />
<br />
* Распаковываем tar.gz архив со сборкой в папку под ОС linux<br />
* Проверяем наличие в системе qemu-system-x86_64, при отсутствии останавливаем qemu<br />
* Переходим в папку куда распакован Барий<br />
* Запускаем<br />
<br />
'''./qemurun'''<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Server_12.4&diff=20519Server 12.42023-03-30T10:18:23Z<p>Betcher: </p>
<hr />
<div>= ROSA Server 12.4 =<br />
<br />
== Описание дистрибутива ==<br />
<br />
Образ '''ROSA server''' 12.4 — это минималистичная операционная система для использования и на железе, и в виртуальных средах.<br />
<br />
Ее концепция такова: в состав дистрибутива включен лишь минимально необходимый для удобной работы администратора набор компонентов, а из репозитория можно установить необходимые пакеты.<br />
<br />
== Состав дистрибутива ==<br />
<br />
В состав образа входят следующие компоненты:<br />
<br />
* графический, консольный и автоматизированный установщики (подробнее см. в статье [[Anaconda]])<br />
* ядро Linux 6.1<br />
* системный менеджер systemd<br />
* сервер SSH openssh-server<br />
* служба синхронизация времени chrony<br />
* служба автоматической или ручной настройки сети NetworkManager<br />
* различные небольшие утилиты<br />
<br />
== Доступные в репозитории компоненты ==<br />
<br />
Другие компоненты можно установить из обширного [http://mirror.rosalinux.ru/rosa/rosa2021.1/repository/x86_64/ репозитория], например:<br />
<br />
* служба каталогов FreeIPA (пакет <code>ipa-server</code>)<br />
* служба каталогов [[Samba|Samba AD]]<br />
* DNS-сервер bind<br />
* база данных MariaDB (MySQL) (пакет <code>mariadb</code>)<br />
* база данных PostgreSQL 12 (пакет <code>postgresql</code>)<br />
* веб и прокси сервер apache (с [https://abf.io/import/apache/blob/rosa2021.1/README.GOST поддержкой] запутывающего кодирования по ГОСТ)<br />
* Система мониторинга [[Zabbix]]<br />
* виртуализация (qemu+libvirt)<br />
* веб и прокси сервер nginx и различные модули для него (пакеты <code>nginx-module-*</code>)<br />
* российский форк nginx '''[https://www.opennet.ru/opennews/art.shtml?num=58036 angie]''' и те же самые модули, что и для nginx:<br />
angie-module-perl<br><br />
angie-module-rtmp<br><br />
angie-module-upload<br><br />
angie-module-http_auth_pam<br><br />
angie-module-ndk<br><br />
angie-module-array-var<br><br />
angie-module-aws-auth<br><br />
angie-module-brotli<br><br />
angie-module-spnego-auth<br><br />
* и многие другие<br />
<br />
Репозиторий общий с десктопными дистрибутивами.<br />
<br />
Также можно установить графические оболочки (однако лучше использовать сразу образ с нужной оболочкой, иначе корректность работы не гарантируется и не проверяется службой контроля качества):<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Графическая оболочка !! Пакет для установки<br />
|-<br />
| XFCE || task-xfce для XFCE с настройками Росы или task-xfce-minimal для XFCE без доп. настроек<br />
|-<br />
| KDE Plasma5 || task-plasma5 или task-iso-plasma5<br />
|-<br />
| GNOME || task-iso-gnome для установки GNOME с настройками, дополнениями и другим ПО, как в образе с GNOME;<br><br />
для установки «ванильного» GNOME: gdm gnome-session-x11-session gnome-session-wayland-session gnome-classic-session<br />
|-<br />
| LXQt || task-iso-lxqt<br />
|-<br />
| MATE || task-mate<br />
|-<br />
| Lumina || task-lumina<br />
|-<br />
| icewm || icewm или task-iso-icewm<br />
|-<br />
| i3 || i3 или task-i3<br />
|-<br />
|}<br />
<br />
Дополнительно необходимо установить пакет task-x11.<br />
<br />
== Скриншот ==<br />
<br />
[[Файл:ROSA-12.4-server-tty.png|ROSA-12.4-server-tty.png]]<br />
<br />
== Скачать ==<br />
<br />
* [http://mirror.rosalinux.ru/rosa/rosa2021.1/iso/ROSA.FRESH.12/server/ROSA.FRESH.SERVER.12.4.x86_64.iso x86_64 ISO] <br />
* [http://mirror.rosalinux.ru/rosa/rosa2021.1/iso/ROSA.FRESH.12/server/ROSA.FRESH.SERVER.12.4.x86_64.uefi.iso x86_64 ISO UEFI]<br />
<br />
или с [https://mirror.yandex.ru/rosa/rosa2021.1/iso/ROSA.FRESH.12/server/ Yandex-CDNа].<br />
<br />
{{Примечание|Проверить целостность образов можно командой '''checkisomd5 ИмяОбраза''' или выбрав режим самопроверки при запуске.}}<br />
<br />
[[Категория:ROSA Server]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%BD%D0%B0_%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB&diff=20518Установка на шифрованный раздел2023-03-30T07:51:32Z<p>Betcher: </p>
<hr />
<div><br />
== Установка ==<br />
Инсталлятор anaconda. используемый в Роса начиная с платформы rosa2021.1, позволяет создавать шифрованные разделы в том числе можно шифровать и всю корневую ФС, при условии что загрузчики будут вынесены на отдельные разделы.<br />
<br />
Для установки с шифрованным корнем делаем следующую разбивку:<br />
<br />
====Раздел 1==== <br />
<br />
* Размер - 100-200 Мb<br />
* FS - vfat, флаг esp (если разбивка в анаконде достаточно указать тип) <br />
* Точка монтирования - /boot/efi<br />
<br />
====Раздел 2====<br />
* Размер - 500-1000 Mb (для установки хватит и 300, но для обновления initrd уже недостаточно)<br />
* FS: ext4<br />
* Точка монтирования - /boot<br />
<br />
====Раздел 3====<br />
* Размер - от 10 Gb<br />
* FS - любая с поддержкой юникс прав, например ext4<br />
* Точка монтирования - /<br />
* Вот для этого раздела включаем шифрование LUKS2<br />
<br />
Дальнейшая установка не отличается ничем. Во время загрузки ОС после выбора пункта загрузки в меню граба на этапе initrd у вас будет запрашиваться пароль. Прямо поверх заставки plymouth. <br />
Описания там нет нужно вводить пароль от корневого LUKS2 раздела.<br />
<br />
== Загрузка без ввода пароля ==<br />
Как вы уже заметили загрузчики остаются на открытых разделах, чтобы защитить машину от взлома путем внесения изменений на этих разделах необходимо устанавливать пароль для UEFI.<br />
Но это приведет к тому, что для загрузки вам нужно будет вводить уже два пароля, а если еще отключен автологин то уже три. Однако есть способ загружать машину без ввода пароля LUKS <br />
не теряя при этом в безопасности.<br />
<br />
Все современные x86_64 машины, примерно с 16го года оснащаются модулем [https://ru.wikipedia.org/wiki/TPM_(%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F) tpm2], который можно использовать для разблокировки раздела LUKS. Упрощенно можно объяснить идею так - ключ от LUKS вместо вас вводит машина. Таким образом изъятый носитель расшифровать не получится потому что ключ в машине, а машину загрузить не получится потому-что пароль на загрузку UEFI.<br />
<br />
'''Есть два способа использования tpm2 для авторазблокировки корневого раздела LUKS для Linux.''' <br />
<br />
* c использованием фреймворка clevis<br />
* c systemd-cryptenroll. <br />
<br />
Оба доступны для ОС Роса платформы rosa2021.1 и новее. Для их использования подготовлены специальные пакеты с упрощающие настройку:<br />
<br />
luksunlock-systemd<br />
luksunlock-clevis<br />
<br />
''Можно выбрать любой либо устанавливать luksunlock и система выберет лучший вариант.''<br />
<br />
'''В консоли с правами root в системе установленной в LUKS раздел выполните:'''<br />
<br />
dnf install luksunlock -y <br />
luksunlock<br />
<br />
Далее следуйте указаниям утилиты, в простейшем случае понадобится только ввести пароль для LUKS раздела. После завершения работы утилиты пароль LUKS при загрузке более запрашиваться не будет.<br />
<br />
''Важно!!! В случае использования luksunlock-clevis окошко для ввода пароля все равно будет появляться.''<br />
<br />
''Паниковать и пытаться вводить пароль не нужно, просто дождитесь окончания загрузки.'' <br />
<br />
'''Для того чтобы отключить авторазблокировку корневого раздела LUKS:'''<br />
<br />
lukslock</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B8&diff=20455Barium:модули2023-03-24T09:04:19Z<p>Betcher: </p>
<hr />
<div>=== Что за модули такие ===<br />
UIRD создает корневую файловую систему для дальнейшей загрузки ОС из слоев собранных объединяющей файловой системой aufs/overlayfs. В качестве слоев может использоваться все что возможно смонтировать в Линукс в режиме read only. Чаще всего это squashfs архивы, это и есть модули Бария. Squashfs архив отличает то, что данные из него можно читать блочно, то есть для того чтобы извлечь файл нет необходимости распаковывать весь архив, распаковываются только блоки, в которых лежат части этого файла. Помимо уменьшения размера ОС это часто дает прирост в скорости чтения, особенно с медленных носителей, относительно чтения не сжатых данных с того же носителя. Это происходит потому, что прочитать 1 мегабайт и распаковать его в 3 мегабайта с "быстрым" процессором и "медленным" носителем, будет быстрее чем читать не сжатые 3 мегабайта. Каждый такой модуль содержит свою часть файловой системы. Модуль не равен rpm пакету по содержимому, он может содержать как один файл, так и всю ОС, как это бывает в livecd.<br />
<br />
===Подключение и отключение модулей=== <br />
Корневая rootfs собирается на этапе UIRD (initrd Бария) из модулей. Модули при этом подключаются из нескольких каталогов по определенным правилам. Системные модули лежат в /.memory/layer-base/0/base. При обновлении ОС эти модули заменяются новыми. Если положить модуль сюда он будет подключен при старте системы. Но для собственных модулей предназначены другие каталоги:<br />
<br />
/.memory/layer-base/0/modules<br />
/.memory/layer-base/1/modules<br />
<br />
Основное отличие в том, что второй каталог находится на шифрованном разделе предназначенном для пользовательских данных, а первый на системном разделе. (При стандартной установке)<br />
Если использовать aufs вместо overlayfs у вас появится возможность подключать и отключать модули "на горячую" используя утилиты:<br />
<br />
'''barium add module.xzm'''<br />
'''barium rm module.xzm'''<br />
<br />
С overlayfs такая возможность не доступна. <br />
<br />
=== Как сделать модуль ===<br />
Squashfs архивы создаются утилитой mksquashfs из пакета squahfs-tools, и модули вполне можно сделать имея только mksquashfs, но для большего удобства подготовлено несколько утилит в составе barium-utils.<br />
<br />
=== barium mkmod ===<br />
Основная задача утилиты сделать модуль из папки с файлами, дополнительно можно склеивать папки и модули в один модуль в любых сочетаниях.<br />
Например:<br />
У вас есть два файла - программа и ее конфиг. В системе они должны быть размещены по путям:<br />
<br />
/usr/bin/superproga<br />
/etc/superproga.d/superproga.conf<br />
<br />
* Создаем папку с именем будущего модуля:<br />
<br />
mkdir ./superproga<br />
<br />
* Внутри папки создаем нужные каталоги. Обратите внимание на права и пользователя каталогов. Для системных папок обычно достаточно создавать их под рутом.<br />
<br />
<br />
mkdir -p ./superproga/usr/bin<br />
mkdir -p ./superproga/etc/superproga.d<br />
<br />
* копируем файлы в папки, допустим они у нас тоже были в текущем каталоге<br />
<br />
cp ./superproga ./superproga/usr/bin/<br />
cp ./superproga.conf ./superproga/etc/superproga.d/<br />
<br />
* Пакуем<br />
<br />
'''barium mkmod ./superproga'''<br />
<br />
Итогом будет модуль superproga.xzm, при подключении которого файлы окажутся в системе в нужных подкаталогах.<br />
Модули невозможно редактировать, они монтируются только RO, поэтому, если вам нужно будет что-то изменить, придется собирать модуль заново.<br />
Если же нужно добавить файл в модуль, можно воспользоваться режимом "склейки" утилиты barium mkmod<br />
<br />
mkdir -p ./superproga2/etc/skel/.config/<br />
cp superproga.conf ./superproga2/etc/skel/.config/<br />
'''barium mkmod ./superproga2 ./superproga.xzm -o superproga2.xzm'''<br />
<br />
=== Распаковка модулей ===<br />
<br />
Для распаковки модуля проще всего смонтировать модуль и забрать содержимое из точки монтирования.<br />
Также можно использовать утилиту unsquashfs.<br />
Для разборки составного ("склеенного") модуля есть утилита barium split<br />
<br />
=== barium dnf2mod === <br />
<br />
Пожалуй наиболее востребованная утилита для сборки модулей. Она использует dnf. То есть устанавливает в модуль запрошенные пакеты из репозитория, вместе с зависимостями и результатом выполнения скриптов из rpm. После установки из модуля удаляются базы rpm, dnf и кэши. Таким образом, при подключении модуля, база rpm не изменится и пакеты не будут зарегистрированы как установленные в системе. Это сделано для того, чтобы модули не были инкрементно зависимы. Любой модуль собранный dnf2mod зависит только от базовых модулей системы и может быть удален в любой момент не нарушая работу других модулей.<br />
<br />
Например: <br />
<br />
'''barium dnf2mod nano'''<br />
<br />
Соберет пакет с редактором nano. Пакет будет собран даже в том случае, если nano уже есть в базовой системе. Это позволяет, например, выборочно обновить пакет не дожидаясь обновления всей системы.<br />
<br />
Можно передать список модулей:<br />
<br />
'''barium dnf2mod nano mc busybox''' <br />
<br />
С ключoм "-с" утилита будет использовать системные настройки и кэши dnf.<br />
В конце строки с параметрами после ключа --dnf можно дописать параметры, которые будут передаваться dnf при установке, например --repofrompath.<br />
Нет необходимости запоминать параметры сборки модуля, они хранятся внутри и запустив <br />
<br />
'''barium dnf2mod nano.xzm''' <br />
<br />
вы пересоберете модуль с теми же параметрами как он был собран, но с обновленными пакетами из репозитория.<br />
<br />
=== barium chroot2mod === <br />
<br />
Утилита пакует в модуль изменения файлов произошедшие в chroot, которые являются результатом выполнения команды или скрипта. Rootfs для chroot при этом собрана из базовых модулей системы.<br />
Звучит малопонятно, далее на примерах.<br />
<br />
'''barium chroo2mod -o nano.xzm --command dnf install nano'''<br />
<br />
<br />
Утилита создаст rootfs из базовых модулей так, как это делает uird, выполнит в chroot указанную команду, и запакует только новые и измененные в результате выполнения команды файлы.<br />
Результат будет близок к barium dnf2mod nano, за исключением того, что кэши и базы rpm и dnf автоматически не удаляются.<br />
В данном примере используется dnf, но утилита с ним никак не связана, можно запустить какой-то консольный конфигуратор или wget или просто /bin/bash и сделать все руками, после выхода из оболочки все будет запаковано.<br />
<br />
Для более сложных случаев вместо параметра --command используется --script, которому передается сценарий сборки, обычно это bash, но не принципиально. <br />
<br />
Пример: <br />
<br />
Создаем скрипт getproga.sh для гипотетического проекта proga, для простоты допустим, что компилировать не нужно, только забрать скрипты c гит репозитория <br />
<br />
#!/bin/bash<br />
# устанавливаем необходимые для сборки пакеты<br />
dnf install git-core<br />
cd /tmp<br />
# клонируем проект с гит репозитория<br />
git clone https://server/user/proga.git<br />
# устанавливаем<br />
chmod +x ./proga/bin/* <br />
cp ./proga/bin/* /usr/bin/<br />
# зачищаем<br />
dnf remove git-core<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
Делаем исполняемым:<br />
chmod +x getproga.sh<br />
<br />
Запускаем сборку:<br />
<br />
'''barium chroo2mod -o proga.xzm --script ./getproga.sh'''<br />
<br />
<br />
Для того, чтобы использовать внутри сборочной рутфс файлы, находящиеся снаружи (то есть в основной системе), используем параметр --bind. Ему передается два пути к папкам разделенные двоеточием. Первый путь снаружи rootfs, второй внутри. В таком случае --script уже не нужен, указываем --command /путь/в/rootfs/скрипт.sh <br />
<br />
Пример:<br />
<br />
Создаем папку, в которой будут файлы для сборки модуля.<br />
Переносим в нее yandex-browser.rpm<br />
Рядом создаем скрипт yb.sh:<br />
<br />
#!/bin/bash<br />
# переходим в каталог с файлами для сборки<br />
cd $(basedir $0)<br />
# устанавливаем rpm<br />
dnf install -y ./yandex-browser.rpm<br />
# зачищаем (если нужно)<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
# и т.д.<br />
<br />
Делаем исполняемым:<br />
chmod +x yb.sh<br />
<br />
Находясь в каталоге со скриптом и rpm пакетом запускаем сборку.<br />
<br />
'''barium chroot2mod -o yandex-browser.xzm --bind ./::/var/lib/YB --command /var/lib/YB/yb.sh'''<br />
<br />
<br />
Еще более сложный реальный пример скрипта, для сборки аналогичным способом. С подключением локального каталога с rpm пакетами как репозитория:<br />
<br />
#!/bin/bash<br />
BASE=$(dirname $0)<br />
dnf install -y lsb || echo lsb > /tmp/problem.packages<br />
echo "[localrepo]<br />
name=tmprepo<br />
baseurl=file://${BASE}/REPO<br />
enabled=1<br />
gpgcheck=0" > /etc/yum.repos.d/tmp.repo<br />
# включаем i686 репозитории<br />
for a in $(ls -1 /etc/yum.repos.d |grep i686) ; do<br />
sed -i 's/enabled.*/enabled=1/' /etc/yum.repos.d/$a<br />
done<br />
dnf refresh<br />
pushd $BASE<br />
cp -fax ./CERT/* / || echo "error ${LINENO}"<br />
#Установка корневых сертификатов<br />
update-ca-trust enable<br />
tar -xf /tmp/stunnel/dis/root_crt.tar.gz -C /etc/pki/ca-trust/source/anchors/<br />
cat x86_64.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y || echo $a >> /tmp/problem.packages<br />
done<br />
echo 'i686 ===============' >> /tmp/problem.packages<br />
echo "Install i686 packages"<br />
cat i686.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y --forcearch i686 || echo $a >> /tmp/problem.packages <br />
done<br />
echo 'Problem rpms ===========' >> /tmp/problem.packages<br />
echo "Install problem packages"<br />
cat problem_rpm.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo ========= $a ===============<br />
dnf download $a<br />
name=$(ls -1 |grep -i $a)<br />
rpm -Uhv --nodeps ./$name || echo $a >> /tmp/problem.packages<br />
rm - $name<br />
done<br />
# подключение библиотек смарткарт к цитриксу<br />
ln -sf /usr/lib64/libeToken.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
ln -sf /usr/lib64/libjcPKCS11-2.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
# сертификат для цитрикс-клиента<br />
cp /etc/pki/127.0.0.1.crt /opt/Citrix/ICAClient/keystore/cacerts/127.0.0.1.pem<br />
/opt/Citrix/ICAClient/util/ctx_rehash<br />
# русская клавиатура для цитрикса<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/All_Regions.ini<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/usertemplate/All_Regions.ini<br />
# systemctl daemon-reload<br />
# обновляем системное хранилище сертификатов для браузера <br />
update-ca-trust<br />
# подключаем в загрузку туннели<br />
systemctl enable iuspt-in.service<br />
systemctl enable iuspt-out.service<br />
mkdir -p /opt/cprocsp/var/run/stunnel<br />
# подключаем сертификаты к КриптоПро<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mCA -file /etc/pki/gazprom_inform_ca_gost_2012.cer<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mROOT -file /etc/pki/root_gazprom_ca_gost_2012.cer<br />
# устанавливаем скрипт для файрфокса в автостарт<br />
chmod +x setup_user.sh<br />
cp setup_user.sh /usr/lib/rosa-rw/rc.desktop/all/<br />
popd<br />
rm -f /etc/yum.repos.d/tmp.repo<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
<br />
Модули собранные утилитой barium chroot2mod, также как и с dnf2mod, хранят cmdline сборки, но пересобраться смогут только те, что собраны независимо, то есть без локальных файлов.<br />
<br />
====Проекты для chroot2mod==== <br />
<br />
Если модуль предполагается периодически пересобирать для обновления, а сборка требует сценарий и дополнительные файлы, вместо --script удобнее использовать новый параметр --project, которому передается имя папки с проектом. Здесь проект это каталог, который содержит один обязательный файл - build.c2m, а также другие файлы и папки нужные вам для сборки. Файл build.c2m это скрипт, обычно bash, но не обязательно. Он должен иметь права на выполнение. Логика написания скрипта такая же ка для --script. Плюсы --project в том что такие проекты удобнее хранить и собирать.<br />
<br />
'''barium chroot2mod --project ./project_dir '''<br />
<br />
Пример build.c2m для сборки модуля КонтинетАп:<br />
<br />
#!/bin/bash<br />
cd $(dirname $0) # делаем текущей папку с build.c2m и cts.rpm <br />
dnf install ./cts* # устанавливаем локальный rpm файл cts, а также необходимые зависимости. Можно rpm -Uhv если зависимостей нет.<br />
systemctl enable cts # включаем сервис cts по умолчанию<br />
<br />
=== barium diff-changes === <br />
Утилита помогает вычислять изменения произошедшие в системе и делать модули содержащие эти изменения. Этот способ хуже подходит для сборки модулей чем chroot2mod так как фоновые процессы тоже могут вносить изменения и мы это не контролируем. Но иногда может быть полезной например если нужная вам утилита имеет только графический установщик. В простейшем случае процесс создания модуля с diff-changes выглядит так:<br />
<br />
'''barium diff-changes''' # создается контрольная точка<br />
<br />
Далее выполняете в системе действия по установке и настройке, так как вы бы это делали например в ROSA CHROME. После завершения:<br />
<br />
'''barium diff-changes -d -m''' <br />
<br />
* -d рассчитать разницу<br />
* -m собрать модуль содержащий новые и измененные файлы<br />
Если создано несколько контрольных точек нужно будет дополнительно указать нужную ключом -i. Контрольные точки можно именовать при создании, тогда итоговый модуль будет иметь имя как у контрольной точки.<br />
<br />
barium diff-changes -p -i yandex-browser<br />
dnf install -y ./yandex-browser.rpm<br />
dnf clean all<br />
barium diff-changes -i yandex-browser -d -m new<br />
<br />
Параметр "new" ключа -m указывает собирать модуль только из новых файлов и игнорировать измененные.<br />
<br />
''Это только пример, конкретно в этой ситуации правильнее использовать chroot2mod.'' <br />
<br />
Зачем же нужна утилита если не гарантирует корректность созданных модулей. Основная задача diff-changes помочь вам определить какие файлы были изменены или добавлены, с тем, чтобы использовать эту информацию для сборки модуля другим способом или настройки сохранения в модули для этих файлов.<br />
<br />
=== Решение проблем ===<br />
<br />
Случается,что при некорректном завершении сборочных утилит остаются артефакты монтирований. Это может привести к невозможности сборки. В большинстве случаев поможет:<br />
<br />
'''barium b-lib destroy_union 5'''<br />
'''barium b-lib destroy_layers 5''' <br />
<br />
"5" здесь предположительное количество некорректно завершенных заданий. Пишите больше не ошибетесь :)<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B8&diff=20454Barium:модули2023-03-21T09:16:48Z<p>Betcher: </p>
<hr />
<div>=== Что за модули такие ===<br />
UIRD создает корневую файловую систему для дальнейшей загрузки ОС из слоев собранных объединяющей файловой системой aufs/overlayfs. В качестве слоев может использоваться все что возможно смонтировать в Линукс в режиме read only. Чаще всего это squashfs архивы, это и есть модули Бария. Squashfs архив отличает то, что данные из него можно читать блочно, то есть для того чтобы извлечь файл нет необходимости распаковывать весь архив, распаковываются только блоки, в которых лежат части этого файла. Помимо уменьшения размера ОС это часто дает прирост в скорости чтения, особенно с медленных носителей, относительно чтения не сжатых данных с того же носителя. Это происходит потому, что прочитать 1 мегабайт и распаковать его в 3 мегабайта с "быстрым" процессором и "медленным" носителем, будет быстрее чем читать не сжатые 3 мегабайта. Каждый такой модуль содержит свою часть файловой системы. Модуль не равен rpm пакету по содержимому, он может содержать как один файл, так и всю ОС, как это бывает в livecd.<br />
<br />
===Подключение и отключение модулей=== <br />
Корневая rootfs собирается на этапе UIRD (initrd Бария) из модулей. Модули при этом подключаются из нескольких каталогов по определенным правилам. Системные модули лежат в /.memory/layer-base/0/base. При обновлении ОС эти модули заменяются новыми. Если положить модуль сюда он будет подключен при старте системы. Но для собственных модулей предназначены другие каталоги:<br />
<br />
/.memory/layer-base/0/modules<br />
/.memory/layer-base/1/modules<br />
<br />
Основное отличие в том, что второй каталог находится на шифрованном разделе предназначенном для пользовательских данных, а первый на системном разделе. (При стандартной установке)<br />
Если использовать aufs вместо overlayfs у вас появится возможность подключать и отключать модули "на горячую" используя утилиты:<br />
<br />
'''barium add module.xzm'''<br />
'''barium rm module.xzm'''<br />
<br />
С overlayfs такая возможность не доступна. <br />
<br />
=== Как сделать модуль ===<br />
Squashfs архивы создаются утилитой mksquashfs из пакета squahfs-tools, и модули вполне можно сделать имея только mksquashfs, но для большего удобства подготовлено несколько утилит в составе barium-utils.<br />
<br />
=== barium mkmod ===<br />
Основная задача утилиты сделать модуль из папки с файлами, дополнительно можно склеивать папки и модули в один модуль в любых сочетаниях.<br />
Например:<br />
У вас есть два файла - программа и ее конфиг. В системе они должны быть размещены по путям:<br />
<br />
/usr/bin/superproga<br />
/etc/superproga.d/superproga.conf<br />
<br />
* Создаем папку с именем будущего модуля:<br />
<br />
mkdir ./superproga<br />
<br />
* Внутри папки создаем нужные каталоги. Обратите внимание на права и пользователя каталогов. Для системных папок обычно достаточно создавать их под рутом.<br />
<br />
<br />
mkdir -p ./superproga/usr/bin<br />
mkdir -p ./superproga/etc/superproga.d<br />
<br />
* копируем файлы в папки, допустим они у нас тоже были в текущем каталоге<br />
<br />
cp ./superproga ./superproga/usr/bin/<br />
cp ./superproga.conf ./superproga/etc/superproga.d/<br />
<br />
* Пакуем<br />
<br />
'''barium mkmod ./superproga'''<br />
<br />
Итогом будет модуль superproga.xzm, при подключении которого файлы окажутся в системе в нужных подкаталогах.<br />
Модули невозможно редактировать, они монтируются только RO, поэтому, если вам нужно будет что-то изменить, придется собирать модуль заново.<br />
Если же нужно добавить файл в модуль, можно воспользоваться режимом "склейки" утилиты barium mkmod<br />
<br />
mkdir -p ./superproga2/etc/skel/.config/<br />
cp superproga.conf ./superproga2/etc/skel/.config/<br />
'''barium mkmod ./superproga2 ./superproga.xzm -o superproga2.xzm'''<br />
<br />
=== Распаковка модулей ===<br />
<br />
Для распаковки модуля проще всего смонтировать модуль и забрать содержимое из точки монтирования.<br />
Также можно использовать утилиту unsquashfs.<br />
Для разборки составного ("склеенного") модуля есть утилита barium split<br />
<br />
=== barium dnf2mod === <br />
<br />
Пожалуй наиболее востребованная утилита для сборки модулей. Она использует dnf. То есть устанавливает в модуль запрошенные пакеты из репозитория, вместе с зависимостями и результатом выполнения скриптов из rpm. После установки из модуля удаляются базы rpm, dnf и кэши. Таким образом, при подключении модуля, база rpm не изменится и пакеты не будут зарегистрированы как установленные в системе. Это сделано для того, чтобы модули не были инкрементно зависимы. Любой модуль собранный dnf2mod зависит только от базовых модулей системы и может быть удален в любой момент не нарушая работу других модулей.<br />
<br />
Например: <br />
<br />
'''barium dnf2mod nano'''<br />
<br />
Соберет пакет с редактором nano. Пакет будет собран даже в том случае, если nano уже есть в базовой системе. Это позволяет, например, выборочно обновить пакет не дожидаясь обновления всей системы.<br />
<br />
Можно передать список модулей:<br />
<br />
'''barium dnf2mod nano mc busybox''' <br />
<br />
С ключoм "-с" утилита будет использовать системные настройки и кэши dnf.<br />
В конце строки с параметрами после ключа --dnf можно дописать параметры, которые будут передаваться dnf при установке, например --repofrompath.<br />
Нет необходимости запоминать параметры сборки модуля, они хранятся внутри и запустив <br />
<br />
'''barium dnf2mod nano.xzm''' <br />
<br />
вы пересоберете модуль с теми же параметрами как он был собран, но с обновленными пакетами из репозитория.<br />
<br />
=== barium chroot2mod === <br />
<br />
Утилита пакует в модуль изменения файлов произошедшие в chroot, которые являются результатом выполнения команды или скрипта. Rootfs для chroot при этом собрана из базовых модулей системы.<br />
Звучит малопонятно, далее на примерах.<br />
<br />
'''barium chroo2mod -o nano.xzm --command dnf install nano'''<br />
<br />
<br />
Утилита создаст rootfs из базовых модулей так, как это делает uird, выполнит в chroot указанную команду, и запакует только новые и измененные в результате выполнения команды файлы.<br />
Результат будет близок к barium dnf2mod nano, за исключением того, что кэши и базы rpm и dnf автоматически не удаляются.<br />
В данном примере используется dnf, но утилита с ним никак не связана, можно запустить какой-то консольный конфигуратор или wget или просто /bin/bash и сделать все руками, после выхода из оболочки все будет запаковано.<br />
<br />
Для более сложных случаев вместо параметра --command используется --script, которому передается сценарий сборки, обычно это bash, но не принципиально. <br />
<br />
Пример: <br />
<br />
Создаем скрипт getproga.sh для гипотетического проекта proga, для простоты допустим, что компилировать не нужно, только забрать скрипты c гит репозитория <br />
<br />
#!/bin/bash<br />
# устанавливаем необходимые для сборки пакеты<br />
dnf install git-core<br />
cd /tmp<br />
# клонируем проект с гит репозитория<br />
git clone https://server/user/proga.git<br />
# устанавливаем<br />
chmod +x ./proga/bin/* <br />
cp ./proga/bin/* /usr/bin/<br />
# зачищаем<br />
dnf remove git-core<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
Делаем исполняемым:<br />
chmod +x getproga.sh<br />
<br />
Запускаем сборку:<br />
<br />
'''barium chroo2mod -o proga.xzm --script ./getproga.sh'''<br />
<br />
<br />
Для того, чтобы использовать внутри сборочной рутфс файлы, находящиеся снаружи (то есть в основной системе), используем параметр --bind. Ему передается два пути к папкам разделенные двоеточием. Первый путь снаружи rootfs, второй внутри. В таком случае --script уже не нужен, указываем --command /путь/в/rootfs/скрипт.sh <br />
<br />
Пример:<br />
<br />
Создаем папку, в которой будут файлы для сборки модуля.<br />
Переносим в нее yandex-browser.rpm<br />
Рядом создаем скрипт yb.sh:<br />
<br />
#!/bin/bash<br />
# переходим в каталог с файлами для сборки<br />
cd $(basedir $0)<br />
# устанавливаем rpm<br />
dnf install -y ./yandex-browser.rpm<br />
# зачищаем (если нужно)<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
# и т.д.<br />
<br />
Делаем исполняемым:<br />
chmod +x yb.sh<br />
<br />
Находясь в каталоге со скриптом и rpm пакетом запускаем сборку.<br />
<br />
'''barium chroot2mod -o yandex-browser.xzm --bind ./::/var/lib/YB --command /var/lib/YB/yb.sh'''<br />
<br />
<br />
Еще более сложный реальный пример скрипта, для сборки аналогичным способом. С подключением локального каталога с rpm пакетами как репозитория:<br />
<br />
#!/bin/bash<br />
BASE=$(dirname $0)<br />
dnf install -y lsb || echo lsb > /tmp/problem.packages<br />
echo "[localrepo]<br />
name=tmprepo<br />
baseurl=file://${BASE}/REPO<br />
enabled=1<br />
gpgcheck=0" > /etc/yum.repos.d/tmp.repo<br />
# включаем i686 репозитории<br />
for a in $(ls -1 /etc/yum.repos.d |grep i686) ; do<br />
sed -i 's/enabled.*/enabled=1/' /etc/yum.repos.d/$a<br />
done<br />
dnf refresh<br />
pushd $BASE<br />
cp -fax ./CERT/* / || echo "error ${LINENO}"<br />
#Установка корневых сертификатов<br />
update-ca-trust enable<br />
tar -xf /tmp/stunnel/dis/root_crt.tar.gz -C /etc/pki/ca-trust/source/anchors/<br />
cat x86_64.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y || echo $a >> /tmp/problem.packages<br />
done<br />
echo 'i686 ===============' >> /tmp/problem.packages<br />
echo "Install i686 packages"<br />
cat i686.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y --forcearch i686 || echo $a >> /tmp/problem.packages <br />
done<br />
echo 'Problem rpms ===========' >> /tmp/problem.packages<br />
echo "Install problem packages"<br />
cat problem_rpm.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo ========= $a ===============<br />
dnf download $a<br />
name=$(ls -1 |grep -i $a)<br />
rpm -Uhv --nodeps ./$name || echo $a >> /tmp/problem.packages<br />
rm - $name<br />
done<br />
# подключение библиотек смарткарт к цитриксу<br />
ln -sf /usr/lib64/libeToken.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
ln -sf /usr/lib64/libjcPKCS11-2.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
# сертификат для цитрикс-клиента<br />
cp /etc/pki/127.0.0.1.crt /opt/Citrix/ICAClient/keystore/cacerts/127.0.0.1.pem<br />
/opt/Citrix/ICAClient/util/ctx_rehash<br />
# русская клавиатура для цитрикса<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/All_Regions.ini<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/usertemplate/All_Regions.ini<br />
# systemctl daemon-reload<br />
# обновляем системное хранилище сертификатов для браузера <br />
update-ca-trust<br />
# подключаем в загрузку туннели<br />
systemctl enable iuspt-in.service<br />
systemctl enable iuspt-out.service<br />
mkdir -p /opt/cprocsp/var/run/stunnel<br />
# подключаем сертификаты к КриптоПро<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mCA -file /etc/pki/gazprom_inform_ca_gost_2012.cer<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mROOT -file /etc/pki/root_gazprom_ca_gost_2012.cer<br />
# устанавливаем скрипт для файрфокса в автостарт<br />
chmod +x setup_user.sh<br />
cp setup_user.sh /usr/lib/rosa-rw/rc.desktop/all/<br />
popd<br />
rm -f /etc/yum.repos.d/tmp.repo<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
<br />
Модули собранные утилитой barium chroot2mod, также как и с dnf2mod, хранят cmdline сборки, но пересобраться смогут только те, что собраны независимо, то есть без локальных файлов.<br />
<br />
====Проекты для chroot2mod==== <br />
<br />
Если модуль предполагается периодически пересобирать для обновления, а сборка требует сценарий и дополнительные файлы, вместо --script удобнее использовать новый параметр --project, которому передается имя папки с проектом. Здесь проект это каталог, который содержит один обязательный файл - build.c2m, а также другие файлы и папки нужные вам для сборки. Файл build.c2m это скрипт, обычно bash, но не обязательно. Он должен иметь права на выполнение. Логика написания скрипта такая же ка для --script. Плюсы --project в том что такие проекты удобнее хранить и собирать.<br />
<br />
'''barium chroot2mod --project ./project_dir '''<br />
<br />
Пример build.c2m для сборки модуля КонтинетАп:<br />
<br />
#!/bin/bash<br />
cd $(dirname $0) # делаем текущей папку с build.c2m и cts.rpm <br />
dnf install ./cts* # устанавливаем локальный rpm файл cts, а также необходимые зависимости. Можно rpm -Uhv если зависимостей нет.<br />
systemctl enable cts # включаем сервис cts по умолчанию<br />
<br />
=== barium diff-changes === <br />
Утилита помогает вычислять изменения произошедшие в системе и делать модули содержащие эти изменения. Этот способ хуже подходит для сборки модулей чем chroot2mod так как фоновые процессы тоже могут вносить изменения и мы это не контролируем. Но иногда может быть полезной например если нужная вам утилита имеет только графический установщик. В простейшем случае процесс создания модуля с diff-changes выглядит так:<br />
<br />
'''barium diff-changes''' # создается контрольная точка<br />
<br />
Далее выполняете в системе действия по установке и настройке, так как вы бы это делали например в ROSA CHROME. После завершения:<br />
<br />
'''barium diff-changes -d -m''' <br />
<br />
* -d рассчитать разницу<br />
* -m собрать модуль содержащий новые и измененные файлы<br />
Если создано несколько контрольных точек нужно будет дополнительно указать нужную ключом -i. Контрольные точки можно именовать при создании, тогда итоговый модуль будет иметь имя как у контрольной точки.<br />
<br />
barium diff-changes -p -i yandex-browser<br />
dnf install -y ./yandex-browser.rpm<br />
dnf clean all<br />
barium diff-changes -i yandex-browser -d -m new<br />
<br />
Параметр "new" ключа -m указывает собирать модуль только из новых файлов и игнорировать измененные.<br />
<br />
''Это только пример, конкретно в этой ситуации правильнее использовать chroot2mod.'' <br />
<br />
=== Решение проблем ===<br />
<br />
Случается,что при некорректном завершении сборочных утилит остаются артефакты монтирований. Это может привести к невозможности сборки. В большинстве случаев поможет:<br />
<br />
'''barium b-lib destroy_union 5'''<br />
'''barium b-lib destroy_layers 5''' <br />
<br />
Пять здесь предположительное количество некорректно завершенных заданий. Пишите больше не ошибетесь :)<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B8&diff=20453Barium:модули2023-03-20T10:07:47Z<p>Betcher: </p>
<hr />
<div>=== Что за модули такие ===<br />
UIRD создает корневую файловую систему для дальнейшей загрузки ОС из слоев собранных объединяющей файловой системой aufs/overlayfs. В качестве слоев может использоваться все что возможно смонтировать в Линукс в режиме read only. Чаще всего это squashfs архивы, это и есть модули Бария. Squashfs архив отличает то, что данные из него можно читать блочно, то есть для того чтобы извлечь файл нет необходимости распаковывать весь архив, распаковываются только блоки, в которых лежат части этого файла. Помимо уменьшения размера ОС это часто дает прирост в скорости чтения, особенно с медленных носителей, относительно чтения не сжатых данных с того же носителя. Это происходит потому, что прочитать 1 мегабайт и распаковать его в 3 мегабайта с "быстрым" процессором и "медленным" носителем, будет быстрее чем читать не сжатые 3 мегабайта. Каждый такой модуль содержит свою часть файловой системы. Модуль не равен rpm пакету по содержимому, он может содержать как один файл, так и всю ОС, как это бывает в livecd.<br />
<br />
===Подключение и отключение модулей=== <br />
Корневая rootfs собирается на этапе UIRD (initrd Бария) из модулей. Модули при этом подключаются из нескольких каталогов по определенным правилам. Системные модули лежат в /.memory/layer-base/0/base. При обновлении ОС эти модули заменяются новыми. Если положить модуль сюда он будет подключен при старте системы. Но для собственных модулей предназначены другие каталоги:<br />
<br />
/.memory/layer-base/0/modules<br />
/.memory/layer-base/1/modules<br />
<br />
Основное отличие в том, что второй каталог находится на шифрованном разделе предназначенном для пользовательских данных, а первый на системном разделе. (При стандартной установке)<br />
Если использовать aufs вместо overlayfs у вас появится возможность подключать и отключать модули "на горячую" используя утилиты:<br />
<br />
'''barium add module.xzm'''<br />
'''barium rm module.xzm'''<br />
<br />
С overlayfs такая возможность не доступна. <br />
<br />
=== Как сделать модуль ===<br />
Squashfs архивы создаются утилитой mksquashfs из пакета squahfs-tools, и модули вполне можно сделать имея только mksquashfs, но для большего удобства подготовлено несколько утилит в составе barium-utils.<br />
<br />
=== barium mkmod ===<br />
Основная задача утилиты сделать модуль из папки с файлами, дополнительно можно склеивать папки и модули в один модуль в любых сочетаниях.<br />
Например:<br />
У вас есть два файла - программа и ее конфиг. В системе они должны быть размещены по путям:<br />
<br />
/usr/bin/superproga<br />
/etc/superproga.d/superproga.conf<br />
<br />
* Создаем папку с именем будущего модуля:<br />
<br />
mkdir ./superproga<br />
<br />
* Внутри папки создаем нужные каталоги. Обратите внимание на права и пользователя каталогов. Для системных папок обычно достаточно создавать их под рутом.<br />
<br />
<br />
mkdir -p ./superproga/usr/bin<br />
mkdir -p ./superproga/etc/superproga.d<br />
<br />
* копируем файлы в папки, допустим они у нас тоже были в текущем каталоге<br />
<br />
cp ./superproga ./superproga/usr/bin/<br />
cp ./superproga.conf ./superproga/etc/superproga.d/<br />
<br />
* Пакуем<br />
<br />
'''barium mkmod ./superproga'''<br />
<br />
Итогом будет модуль superproga.xzm, при подключении которого файлы окажутся в системе в нужных подкаталогах.<br />
Модули невозможно редактировать, они монтируются только RO, поэтому, если вам нужно будет что-то изменить, придется собирать модуль заново.<br />
Если же нужно добавить файл в модуль, можно воспользоваться режимом "склейки" утилиты barium mkmod<br />
<br />
mkdir -p ./superproga2/etc/skel/.config/<br />
cp superproga.conf ./superproga2/etc/skel/.config/<br />
'''barium mkmod ./superproga2 ./superproga.xzm -o superproga2.xzm'''<br />
<br />
=== Распаковка модулей ===<br />
<br />
Для распаковки модуля проще всего смонтировать модуль и забрать содержимое из точки монтирования.<br />
Также можно использовать утилиту unsquashfs.<br />
Для разборки составного ("склеенного") модуля есть утилита barium split<br />
<br />
=== barium dnf2mod === <br />
<br />
Пожалуй наиболее востребованная утилита для сборки модулей. Она использует dnf. То есть устанавливает в модуль запрошенные пакеты из репозитория, вместе с зависимостями и результатом выполнения скриптов из rpm. После установки из модуля удаляются базы rpm, dnf и кэши. Таким образом, при подключении модуля, база rpm не изменится и пакеты не будут зарегистрированы как установленные в системе. Это сделано для того, чтобы модули не были инкрементно зависимы. Любой модуль собранный dnf2mod зависит только от базовых модулей системы и может быть удален в любой момент не нарушая работу других модулей.<br />
<br />
Например: <br />
<br />
'''barium dnf2mod nano'''<br />
<br />
Соберет пакет с редактором nano. Пакет будет собран даже в том случае, если nano уже есть в базовой системе. Это позволяет, например, выборочно обновить пакет не дожидаясь обновления всей системы.<br />
<br />
Можно передать список модулей:<br />
<br />
'''barium dnf2mod nano mc busybox''' <br />
<br />
С ключoм "-с" утилита будет использовать системные настройки и кэши dnf.<br />
В конце строки с параметрами после ключа --dnf можно дописать параметры, которые будут передаваться dnf при установке, например --repofrompath.<br />
Нет необходимости запоминать параметры сборки модуля, они хранятся внутри и запустив <br />
<br />
'''barium dnf2mod nano.xzm''' <br />
<br />
вы пересоберете модуль с теми же параметрами как он был собран, но с обновленными пакетами из репозитория.<br />
<br />
=== barium chroot2mod === <br />
<br />
Утилита пакует в модуль изменения файлов произошедшие в chroot, которые являются результатом выполнения команды или скрипта. Rootfs для chroot при этом собрана из базовых модулей системы.<br />
Звучит малопонятно, далее на примерах.<br />
<br />
'''barium chroo2mod -o nano.xzm --command dnf install nano'''<br />
<br />
<br />
Утилита создаст rootfs из базовых модулей так, как это делает uird, выполнит в chroot указанную команду, и запакует только новые и измененные в результате выполнения команды файлы.<br />
Результат будет близок к barium dnf2mod nano, за исключением того, что кэши и базы rpm и dnf автоматически не удаляются.<br />
В данном примере используется dnf, но утилита с ним никак не связана, можно запустить какой-то консольный конфигуратор или wget или просто /bin/bash и сделать все руками, после выхода из оболочки все будет запаковано.<br />
<br />
Для более сложных случаев вместо параметра --command используется --script, которому передается сценарий сборки, обычно это bash, но не принципиально. <br />
<br />
Пример: <br />
<br />
Создаем скрипт getproga.sh для гипотетического проекта proga, для простоты допустим, что компилировать не нужно, только забрать скрипты c гит репозитория <br />
<br />
#!/bin/bash<br />
# устанавливаем необходимые для сборки пакеты<br />
dnf install git-core<br />
cd /tmp<br />
# клонируем проект с гит репозитория<br />
git clone https://server/user/proga.git<br />
# устанавливаем<br />
chmod +x ./proga/bin/* <br />
cp ./proga/bin/* /usr/bin/<br />
# зачищаем<br />
dnf remove git-core<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
Делаем исполняемым:<br />
chmod +x getproga.sh<br />
<br />
Запускаем сборку:<br />
<br />
'''barium chroo2mod -o proga.xzm --script ./getproga.sh'''<br />
<br />
<br />
Для того, чтобы использовать внутри сборочной рутфс файлы, находящиеся снаружи (то есть в основной системе), используем параметр --bind. Ему передается два пути к папкам разделенные двоеточием. Первый путь снаружи rootfs, второй внутри. В таком случае --script уже не нужен, указываем --command /путь/в/rootfs/скрипт.sh <br />
<br />
Пример:<br />
<br />
Создаем папку, в которой будут файлы для сборки модуля.<br />
Переносим в нее yandex-browser.rpm<br />
Рядом создаем скрипт yb.sh:<br />
<br />
#!/bin/bash<br />
# переходим в каталог с файлами для сборки<br />
cd $(basedir $0)<br />
# устанавливаем rpm<br />
dnf install -y ./yandex-browser.rpm<br />
# зачищаем (если нужно)<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
# и т.д.<br />
<br />
Делаем исполняемым:<br />
chmod +x yb.sh<br />
<br />
Находясь в каталоге со скриптом и rpm пакетом запускаем сборку.<br />
<br />
'''barium chroot2mod -o yandex-browser.xzm --bind ./::/var/lib/YB --command /var/lib/YB/yb.sh'''<br />
<br />
<br />
Еще более сложный реальный пример скрипта, для сборки аналогичным способом. С подключением локального каталога с rpm пакетами как репозитория:<br />
<br />
#!/bin/bash<br />
BASE=$(dirname $0)<br />
dnf install -y lsb || echo lsb > /tmp/problem.packages<br />
echo "[localrepo]<br />
name=tmprepo<br />
baseurl=file://${BASE}/REPO<br />
enabled=1<br />
gpgcheck=0" > /etc/yum.repos.d/tmp.repo<br />
# включаем i686 репозитории<br />
for a in $(ls -1 /etc/yum.repos.d |grep i686) ; do<br />
sed -i 's/enabled.*/enabled=1/' /etc/yum.repos.d/$a<br />
done<br />
dnf refresh<br />
pushd $BASE<br />
cp -fax ./CERT/* / || echo "error ${LINENO}"<br />
#Установка корневых сертификатов<br />
update-ca-trust enable<br />
tar -xf /tmp/stunnel/dis/root_crt.tar.gz -C /etc/pki/ca-trust/source/anchors/<br />
cat x86_64.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y || echo $a >> /tmp/problem.packages<br />
done<br />
echo 'i686 ===============' >> /tmp/problem.packages<br />
echo "Install i686 packages"<br />
cat i686.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y --forcearch i686 || echo $a >> /tmp/problem.packages <br />
done<br />
echo 'Problem rpms ===========' >> /tmp/problem.packages<br />
echo "Install problem packages"<br />
cat problem_rpm.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo ========= $a ===============<br />
dnf download $a<br />
name=$(ls -1 |grep -i $a)<br />
rpm -Uhv --nodeps ./$name || echo $a >> /tmp/problem.packages<br />
rm - $name<br />
done<br />
# подключение библиотек смарткарт к цитриксу<br />
ln -sf /usr/lib64/libeToken.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
ln -sf /usr/lib64/libjcPKCS11-2.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
# сертификат для цитрикс-клиента<br />
cp /etc/pki/127.0.0.1.crt /opt/Citrix/ICAClient/keystore/cacerts/127.0.0.1.pem<br />
/opt/Citrix/ICAClient/util/ctx_rehash<br />
# русская клавиатура для цитрикса<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/All_Regions.ini<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/usertemplate/All_Regions.ini<br />
# systemctl daemon-reload<br />
# обновляем системное хранилище сертификатов для браузера <br />
update-ca-trust<br />
# подключаем в загрузку туннели<br />
systemctl enable iuspt-in.service<br />
systemctl enable iuspt-out.service<br />
mkdir -p /opt/cprocsp/var/run/stunnel<br />
# подключаем сертификаты к КриптоПро<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mCA -file /etc/pki/gazprom_inform_ca_gost_2012.cer<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mROOT -file /etc/pki/root_gazprom_ca_gost_2012.cer<br />
# устанавливаем скрипт для файрфокса в автостарт<br />
chmod +x setup_user.sh<br />
cp setup_user.sh /usr/lib/rosa-rw/rc.desktop/all/<br />
popd<br />
rm -f /etc/yum.repos.d/tmp.repo<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
<br />
Модули собранные утилитой barium chroot2mod, также как и с dnf2mod, хранят cmdline сборки, но пересобраться смогут только те, что собраны независимо, то есть без локальных файлов.<br />
<br />
====Проекты для chroot2mod==== <br />
<br />
Если модуль предполагается периодически пересобирать для обновления, а сборка требует сценарий и дополнительные файлы, вместо --script удобнее использовать новый параметр --project, которому передается имя папки с проектом. Здесь проект это каталог, который содержит один обязательный файл - build.c2m, а также другие файлы и папки нужные вам для сборки. Файл build.c2m это скрипт, обычно bash, но не обязательно. Он должен иметь права на выполнение. Логика написания скрипта такая же ка для --script. Плюсы --project в том что такие проекты удобнее хранить и собирать.<br />
<br />
'''barium chroot2mod --project ./project_dir '''<br />
<br />
Пример build.c2m для сборки модуля КонтинетАп:<br />
<br />
#!/bin/bash<br />
cd $(dirname $0) # делаем текущей папку с build.c2m и cts.rpm <br />
dnf install ./cts* # устанавливаем локальный rpm файл cts, а также необходимые зависимости. Можно rpm -Uhv если зависимостей нет.<br />
systemctl enable cts # включаем сервис cts по умолчанию<br />
<br />
=== barium diff-changes === <br />
Утилита помогает вычислять изменения произошедшие в системе и делать модули содержащие эти изменения. Этот способ хуже подходит для сборки модулей чем chroot2mod так как фоновые процессы тоже могут вносить изменения и мы это не контролируем. Но иногда может быть полезной например если нужная вам утилита имеет только графический установщик. В простейшем случае процесс создания модуля с diff-changes выглядит так:<br />
<br />
'''barium diff-changes''' # создается контрольная точка<br />
<br />
Далее выполняете в системе действия по установке и настройке, так как вы бы это делали например в ROSA CHROME. После завершения:<br />
<br />
'''barium diff-changes -d -m''' <br />
<br />
* -d рассчитать разницу<br />
* -m собрать модуль содержащий новые и измененные файлы<br />
Если создано несколько контрольных точек нужно будет дополнительно указать нужную ключом -i. Контрольные точки можно именовать при создании, тогда итоговый модуль иметь имя как у контрольной точки.<br />
<br />
barium diff-changes -p -i yandex-browser<br />
dnf install -y ./yandex-browser.rpm<br />
dnf clean all<br />
barium diff-changes -i yandex-browser -d -m new<br />
<br />
Параметр "new" ключа -m указывает собирать модуль только из новых файлов и игнорировать измененные.<br />
<br />
''Это только пример, конкретно в этой ситуации правильнее использовать chroot2mod.'' <br />
<br />
=== Решение проблем ===<br />
<br />
Случается,что при некорректном завершении сборочных утилит остаются артефакты монтирований. Это может привести к невозможности сборки. В большинстве случаев поможет:<br />
<br />
'''barium b-lib destroy_union 5'''<br />
'''barium b-lib destroy_layers 5''' <br />
<br />
Пять здесь предположительное количество некорректно завершенных заданий. Пишите больше не ошибетесь :)<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B8&diff=20452Barium:модули2023-03-20T08:39:45Z<p>Betcher: </p>
<hr />
<div>=== Что за модули такие ===<br />
UIRD создает корневую файловую систему для дальнейшей загрузки ОС из слоев собранных объединяющей файловой системой aufs/overlayfs. В качестве слоев может использоваться все что возможно смонтировать в Линукс в режиме read only. Чаще всего это squashfs архивы, это и есть модули Бария. Squashfs архив отличает то, что данные из него можно читать блочно, то есть для того чтобы извлечь файл нет необходимости распаковывать весь архив, распаковываются только блоки, в которых лежат части этого файла. Помимо уменьшения размера ОС это часто дает прирост в скорости чтения, особенно с медленных носителей, относительно чтения не сжатых данных с того же носителя. Это происходит потому, что прочитать 1 мегабайт и распаковать его в 3 мегабайта с "быстрым" процессором и "медленным" носителем, будет быстрее чем читать не сжатые 3 мегабайта. Каждый такой модуль содержит свою часть файловой системы. Модуль не равен rpm пакету по содержимому, он может содержать как один файл, так и всю ОС, как это бывает в livecd.<br />
<br />
=== Как сделать модуль ===<br />
Squashfs архивы создаются утилитой mksquashfs из пакета squahfs-tools, и модули вполне можно сделать имея только mksquashfs, но для большего удобства подготовлено несколько утилит в составе barium-utils.<br />
<br />
=== barium mkmod ===<br />
Основная задача утилиты сделать модуль из папки с файлами, дополнительно можно склеивать папки и модули в один модуль в любых сочетаниях.<br />
Например:<br />
У вас есть два файла - программа и ее конфиг. В системе они должны быть размещены по путям:<br />
<br />
/usr/bin/superproga<br />
/etc/superproga.d/superproga.conf<br />
<br />
* Создаем папку с именем будущего модуля:<br />
<br />
mkdir ./superproga<br />
<br />
* Внутри папки создаем нужные каталоги. Обратите внимание на права и пользователя каталогов. Для системных папок обычно достаточно создавать их под рутом.<br />
<br />
<br />
mkdir -p ./superproga/usr/bin<br />
mkdir -p ./superproga/etc/superproga.d<br />
<br />
* копируем файлы в папки, допустим они у нас тоже были в текущем каталоге<br />
<br />
cp ./superproga ./superproga/usr/bin/<br />
cp ./superproga.conf ./superproga/etc/superproga.d/<br />
<br />
* Пакуем<br />
<br />
'''barium mkmod ./superproga'''<br />
<br />
Итогом будет модуль superproga.xzm, при подключении которого файлы окажутся в системе в нужных подкаталогах.<br />
Модули невозможно редактировать, они монтируются только RO, поэтому, если вам нужно будет что-то изменить, придется собирать модуль заново.<br />
Если же нужно добавить файл в модуль, можно воспользоваться режимом "склейки" утилиты barium mkmod<br />
<br />
mkdir -p ./superproga2/etc/skel/.config/<br />
cp superproga.conf ./superproga2/etc/skel/.config/<br />
'''barium mkmod ./superproga2 ./superproga.xzm -o superproga2.xzm'''<br />
<br />
=== Распаковка модулей ===<br />
<br />
Для распаковки модуля проще всего смонтировать модуль и забрать содержимое из точки монтирования.<br />
Также можно использовать утилиту unsquashfs.<br />
Для разборки составного ("склеенного") модуля есть утилита barium split<br />
<br />
=== barium dnf2mod === <br />
<br />
Пожалуй наиболее востребованная утилита для сборки модулей. Она использует dnf. То есть устанавливает в модуль запрошенные пакеты из репозитория, вместе с зависимостями и результатом выполнения скриптов из rpm. После установки из модуля удаляются базы rpm, dnf и кэши. Таким образом, при подключении модуля, база rpm не изменится и пакеты не будут зарегистрированы как установленные в системе. Это сделано для того, чтобы модули не были инкрементно зависимы. Любой модуль собранный dnf2mod зависит только от базовых модулей системы и может быть удален в любой момент не нарушая работу других модулей.<br />
<br />
Например: <br />
<br />
'''barium dnf2mod nano'''<br />
<br />
Соберет пакет с редактором nano. Пакет будет собран даже в том случае, если nano уже есть в базовой системе. Это позволяет, например, выборочно обновить пакет не дожидаясь обновления всей системы.<br />
<br />
Можно передать список модулей:<br />
<br />
'''barium dnf2mod nano mc busybox''' <br />
<br />
С ключoм "-с" утилита будет использовать системные настройки и кэши dnf.<br />
В конце строки с параметрами после ключа --dnf можно дописать параметры, которые будут передаваться dnf при установке, например --repofrompath.<br />
Нет необходимости запоминать параметры сборки модуля, они хранятся внутри и запустив <br />
<br />
'''barium dnf2mod nano.xzm''' <br />
<br />
вы пересоберете модуль с теми же параметрами как он был собран, но с обновленными пакетами из репозитория.<br />
<br />
=== barium chroot2mod === <br />
<br />
Утилита пакует в модуль изменения файлов произошедшие в chroot, которые являются результатом выполнения команды или скрипта. Rootfs для chroot при этом собрана из базовых модулей системы.<br />
Звучит малопонятно, далее на примерах.<br />
<br />
'''barium chroo2mod -o nano.xzm --command dnf install nano'''<br />
<br />
<br />
Утилита создаст rootfs из базовых модулей так, как это делает uird, выполнит в chroot указанную команду, и запакует только новые и измененные в результате выполнения команды файлы.<br />
Результат будет близок к barium dnf2mod nano, за исключением того, что кэши и базы rpm и dnf автоматически не удаляются.<br />
В данном примере используется dnf, но утилита с ним никак не связана, можно запустить какой-то консольный конфигуратор или wget или просто /bin/bash и сделать все руками, после выхода из оболочки все будет запаковано.<br />
<br />
Для более сложных случаев вместо параметра --command используется --script, которому передается сценарий сборки, обычно это bash, но не принципиально. <br />
<br />
Пример: <br />
<br />
Создаем скрипт getproga.sh для гипотетического проекта proga, для простоты допустим, что компилировать не нужно, только забрать скрипты c гит репозитория <br />
<br />
#!/bin/bash<br />
# устанавливаем необходимые для сборки пакеты<br />
dnf install git-core<br />
cd /tmp<br />
# клонируем проект с гит репозитория<br />
git clone https://server/user/proga.git<br />
# устанавливаем<br />
chmod +x ./proga/bin/* <br />
cp ./proga/bin/* /usr/bin/<br />
# зачищаем<br />
dnf remove git-core<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
Делаем исполняемым:<br />
chmod +x getproga.sh<br />
<br />
Запускаем сборку:<br />
<br />
'''barium chroo2mod -o proga.xzm --script ./getproga.sh'''<br />
<br />
<br />
Для того, чтобы использовать внутри сборочной рутфс файлы, находящиеся снаружи (то есть в основной системе), используем параметр --bind. Ему передается два пути к папкам разделенные двоеточием. Первый путь снаружи rootfs, второй внутри. В таком случае --script уже не нужен, указываем --command /путь/в/rootfs/скрипт.sh <br />
<br />
Пример:<br />
<br />
Создаем папку, в которой будут файлы для сборки модуля.<br />
Переносим в нее yandex-browser.rpm<br />
Рядом создаем скрипт yb.sh:<br />
<br />
#!/bin/bash<br />
# переходим в каталог с файлами для сборки<br />
cd $(basedir $0)<br />
# устанавливаем rpm<br />
dnf install -y ./yandex-browser.rpm<br />
# зачищаем (если нужно)<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
# и т.д.<br />
<br />
Делаем исполняемым:<br />
chmod +x yb.sh<br />
<br />
Находясь в каталоге со скриптом и rpm пакетом запускаем сборку.<br />
<br />
'''barium chroot2mod -o yandex-browser.xzm --bind ./::/var/lib/YB --command /var/lib/YB/yb.sh'''<br />
<br />
<br />
Еще более сложный реальный пример скрипта, для сборки аналогичным способом. С подключением локального каталога с rpm пакетами как репозитория:<br />
<br />
#!/bin/bash<br />
BASE=$(dirname $0)<br />
dnf install -y lsb || echo lsb > /tmp/problem.packages<br />
echo "[localrepo]<br />
name=tmprepo<br />
baseurl=file://${BASE}/REPO<br />
enabled=1<br />
gpgcheck=0" > /etc/yum.repos.d/tmp.repo<br />
# включаем i686 репозитории<br />
for a in $(ls -1 /etc/yum.repos.d |grep i686) ; do<br />
sed -i 's/enabled.*/enabled=1/' /etc/yum.repos.d/$a<br />
done<br />
dnf refresh<br />
pushd $BASE<br />
cp -fax ./CERT/* / || echo "error ${LINENO}"<br />
#Установка корневых сертификатов<br />
update-ca-trust enable<br />
tar -xf /tmp/stunnel/dis/root_crt.tar.gz -C /etc/pki/ca-trust/source/anchors/<br />
cat x86_64.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y || echo $a >> /tmp/problem.packages<br />
done<br />
echo 'i686 ===============' >> /tmp/problem.packages<br />
echo "Install i686 packages"<br />
cat i686.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y --forcearch i686 || echo $a >> /tmp/problem.packages <br />
done<br />
echo 'Problem rpms ===========' >> /tmp/problem.packages<br />
echo "Install problem packages"<br />
cat problem_rpm.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo ========= $a ===============<br />
dnf download $a<br />
name=$(ls -1 |grep -i $a)<br />
rpm -Uhv --nodeps ./$name || echo $a >> /tmp/problem.packages<br />
rm - $name<br />
done<br />
# подключение библиотек смарткарт к цитриксу<br />
ln -sf /usr/lib64/libeToken.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
ln -sf /usr/lib64/libjcPKCS11-2.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
# сертификат для цитрикс-клиента<br />
cp /etc/pki/127.0.0.1.crt /opt/Citrix/ICAClient/keystore/cacerts/127.0.0.1.pem<br />
/opt/Citrix/ICAClient/util/ctx_rehash<br />
# русская клавиатура для цитрикса<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/All_Regions.ini<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/usertemplate/All_Regions.ini<br />
# systemctl daemon-reload<br />
# обновляем системное хранилище сертификатов для браузера <br />
update-ca-trust<br />
# подключаем в загрузку туннели<br />
systemctl enable iuspt-in.service<br />
systemctl enable iuspt-out.service<br />
mkdir -p /opt/cprocsp/var/run/stunnel<br />
# подключаем сертификаты к КриптоПро<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mCA -file /etc/pki/gazprom_inform_ca_gost_2012.cer<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mROOT -file /etc/pki/root_gazprom_ca_gost_2012.cer<br />
# устанавливаем скрипт для файрфокса в автостарт<br />
chmod +x setup_user.sh<br />
cp setup_user.sh /usr/lib/rosa-rw/rc.desktop/all/<br />
popd<br />
rm -f /etc/yum.repos.d/tmp.repo<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
<br />
Модули собранные утилитой barium chroot2mod, также как и с dnf2mod, хранят cmdline сборки, но пересобраться смогут только те, что собраны независимо, то есть без локальных файлов.<br />
<br />
====Проекты для chroot2mod==== <br />
<br />
Если модуль предполагается периодически пересобирать для обновления, а сборка требует сценарий и дополнительные файлы, вместо --script удобнее использовать новый параметр --project, которому передается имя папки с проектом. Здесь проект это каталог, который содержит один обязательный файл - build.c2m, а также другие файлы и папки нужные вам для сборки. Файл build.c2m это скрипт, обычно bash, но не обязательно. Он должен иметь права на выполнение. Логика написания скрипта такая же ка для --script. Плюсы --project в том что такие проекты удобнее хранить и собирать.<br />
<br />
'''barium chroot2mod --project ./project_dir '''<br />
<br />
Пример build.c2m для сборки модуля КонтинетАп:<br />
<br />
#!/bin/bash<br />
cd $(dirname $0) # делаем текущей папку с build.c2m и cts.rpm <br />
dnf install ./cts* # устанавливаем локальный rpm файл cts, а также необходимые зависимости. Можно rpm -Uhv если зависимостей нет.<br />
systemctl enable cts # включаем сервис cts по умолчанию<br />
<br />
=== barium diff-changes === <br />
Утилита помогает вычислять изменения произошедшие в системе и делать модули содержащие эти изменения. Этот способ хуже подходит для сборки модулей чем chroot2mod так как фоновые процессы тоже могут вносить изменения и мы это не контролируем. Но иногда может быть полезной например если нужная вам утилита имеет только графический установщик. В простейшем случае процесс создания модуля с diff-changes выглядит так:<br />
<br />
'''barium diff-changes''' # создается контрольная точка<br />
<br />
Далее выполняете в системе действия по установке и настройке, так как вы бы это делали например в ROSA CHROME. После завершения:<br />
<br />
'''barium diff-changes -d -m''' <br />
<br />
* -d рассчитать разницу<br />
* -m собрать модуль содержащий новые и измененные файлы<br />
Если создано несколько контрольных точек нужно будет дополнительно указать нужную ключом -i. Контрольные точки можно именовать при создании, тогда итоговый модуль иметь имя как у контрольной точки.<br />
<br />
barium diff-chages -p -i yandex-browser<br />
dnf install -y ./yandex-browser.rpm<br />
dnf clean all<br />
barium diff-changes -i yandex-browser -d -m new<br />
<br />
Параметр "new" ключа -m указывает собирать модуль только из новых файлов и игнорировать измененные.<br />
<br />
''Это только пример, конкретно в этой ситуации правильнее использовать chroot2mod.'' <br />
<br />
=== Решение проблем ===<br />
<br />
Случается,что при некорректном завершении сборочных утилит остаются артефакты монтирований. Это может привести к невозможности сборки. В большинстве случаев поможет:<br />
<br />
'''barium b-lib destroy_union 5'''<br />
'''barium b-lib destroy_layers 5''' <br />
<br />
Пять здесь предположительное количество некорректно завершенных заданий. Пишите больше не ошибетесь :)<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:Rosa_ini&diff=20451Barium:Rosa ini2023-03-20T08:04:30Z<p>Betcher: </p>
<hr />
<div>==ROSA.ini==<br />
<br />
Конфигурационный файл для загружаемой системы задается параметром UIRD - uird.config=Имя.ini, для Бария это Rosa.ini. Поиск файла осуществляется в источниках от последнего к первому до совпадения. Это позволяет иметь разные конфигурационные файлы для отличающихся режимов загрузки. В Барии файлов Rosa.ini - два. ROSA-SYSTEM/Rosa.ini и ROSA-DATA/Rosa.ini. Второй используется для стандартных режимов загрузки, первый только для безопасного режима, когда ROSA-DATA не подключается совсем.<br />
<br />
Обработку ini UIRD осуществляет в момент когда rootfs уже собран. Текущим каталогом в момент запуска обработки является корень собранной sysroot, это важно для установки путей в скриптах, обычно просто убираем начальный слэш. <br />
<br />
Файл поделен на секции, каждая секция описывает действия над одним файлом. Имя файла задается в квадратных скобках. Если файл отсутствовал он будет создан.<br />
<br />
[/etc/ROSA-RW/config]<br />
<br />
После скобки можно задать права в формате chmod<br />
<br />
[/path/filename]a+x<br />
<br />
Если это скрипт и вы хотите здесь же его выполнить, то дальше, также в квадратных скобках нужно задать способ которым вы хотите это сделать. Варианта три:<br />
<br />
[/path/filename]a+x [/bin/bash/] запустит с bash<br />
[/path/filename]a+x [.] выполнить как часть uird-init<br />
[/path/filename]a+x [chroot . ] сделать chroot в sysroot и выполнить там<br />
<br />
Дальше идут строки, которые добавляются в файл. Если это скрипт и он находится во временном каталоге, например:<br />
<br />
[ /tmp/myscript ]a+x [.]<br />
<br />
Можно просто писать строки как бы вы писали их в этот скрипт, если файл существующий и вы вносите в него изменения, то есть несколько ключевых моментов.<br />
* Изменения значения переменной:<br />
<br />
'''Параметр=значение''' <br />
<br />
Меняет параметр в файле на нужное значение. Если параметра нет, строка будет добавлена в конец файла.<br />
<u>Это, пожалуй, основной кейс использования ini.</u><br />
<br />
* Добавить строку в файл, если такой строки в нем еще нет, это важно чтобы избежать накопления одинаковых строк в режимах с сохранением.<br />
<br />
'''+строка'''<br />
<br />
* Добавить строку без проверки<br />
<br />
'''|строка'''<br />
<br />
* Удалить строку<br />
<br />
'''-строка'''<br />
'''-.*''' - очистит весь файл<br />
<br />
<br />
'''Примеры:''' <br />
<br />
<br />
Секция, которая запускает преинит скрипты Бария. Если убрать эту секцию преинит скрипты не будут запущены<br />
<br />
[/usr/lib/rosa-rw/rc.d/rc.preinit]a+x [/bin/bash] <br />
+true<br />
<br />
Части секций с основными параметрами настройки Бария, остальное смотрите в сборке<br />
<br />
[/etc/ROSA-RW/config]<br />
# Хэш пароля для пользователя<br />
# Получить хэш можно: barium b-lib getHash пароль<br />
DEFAULTPASSWD='$6$gOeGyqCj$mqD04gwHbD1dICacthmQmxN1/02qxwFVILvm/uyHLxkXnTEEqMOqzYr/ehIuZ1JFA7KyPhggBjs5y4wv5M3Tt/'<br />
# Хеш пароля для пользователя root<br />
DEFAULTROOTPASSWD='$6$gOeGyqCj$mqD04gwHbD1dICacthmQmxN1/02qxwFVILvm/uyHLxkXnTEEqMOqzYr/ehIuZ1JFA7KyPhggBjs5y4wv5M3Tt/'<br />
# Имя пользователя по умолчанию (стандартно rosa)<br />
DEFAULTUSER=betcher<br />
# Дополнительные данные пользователя<br />
DEFAULTGECOS='Александр Михайлович,+79039501172'<br />
# User for X autostarting<br />
# Пользователь для автовхода (none отключает автовход)<br />
AUTOLOGINUSER=betcher<br />
# Groups for users<br />
# Группы, в которых будут состоять пользователи<br />
USERGROUPS=audio,video,usb,wheel<br />
<br />
#Автообновление системы <br />
AUTOUPDATE=auto<br />
<br />
#Алгоритм сжатия модулей по умолчанию<br />
#MKSQFS_OPTS="-b 512K -comp xz"<br />
#Алгоритм сжатия, используемый для сохранения изменений в модуль<br />
MKSQFS_FASTALG="-b 512K -comp lz4"<br />
<br />
# [/etc/sysconfig/clock]<br />
# UTC=true<br />
# ZONE=Asia/Krasnoyarsk<br />
# ARC=false<br />
<br />
# Настройки сервера ssh<br />
# Дополнительно нужно открыть порт или подсеть в настройках iptables<br />
# А также добавить sshd в SERVICESSTART=sshd<br />
# [/etc/ssh/sshd_config]<br />
#Port 22<br />
#ListenAddress 0.0.0.0<br />
#PermitRootLogin no<br />
#MaxAuthTries 6<br />
#AllowUsers user<br />
<br />
# Таблетка от жадности для сотовых операторов<br />
[/etc/sysctl.d/rosa.conf]<br />
net.ipv4.ip_default_ttl=65<br />
<br />
===Редактор ROSA.ini===<br />
Начиная с мартовских версий 2023 года в сборках доступна графическая утилита для редактирования ROSA.ini. Можно запустить из меню или в консоли:<br />
<br />
'''barium iniedit'''<br />
<br />
Все введенные значения проходят простейшую валидацию (лишние пробелы, не ascii символы и т.д.), пароль автоматически заменяется хэшем.<br />
Позволяет использовать в качестве основы для редактирования как текущий ROSA.ini так и файл в его дефолтном виде.<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:utils&diff=20450Barium:utils2023-03-20T07:31:10Z<p>Betcher: </p>
<hr />
<div>=== Barium-utils === <br />
набор скриптов для управления модулями и другими компонентами дистрибутивов Роса "Барий". <br />
<br />
<br />
'''Базовый набор включает:''' <br />
<br />
* barium - "точка входа". Единый скрипт запуска для остальных утилит. Только для него есть ссылка в $PATH, все остальные запускаются с его помощью. Например:<br />
<br />
barium ls <br />
<br />
* b-lib - библиотека, которую используют скрипты barium-utils, без параметров выведет список доступных функций. Некоторые из них можно использовать отдельно. Например:<br />
<br />
barium b-lib getHash ваш_пароль<br />
<br />
создаст хэш пароля в таком виде как он записывается в /etc/shadow, можно использовать для генерации хэша пароля пользователя и root для Rosa.ini<br />
<br />
* ls - список подключенных модулей<br />
<br />
* add - утилита для подключения модуля "на горячую", работает только при загрузке с aufs. Аналог pfsload (pfs-utils), activate (MagOS)<br />
<br />
* rm - утилита для отключения модуля "на горячую", работает только при загрузке с aufs. Аналог pfsunload (pfs-utils), deactivate (MagOS)<br />
<br />
* modinfo - получение информации о модуле. Аналог pfsinfo (pfs-utils)<br />
<br />
* mkmod - создание модуля из папки. Сборка составных модулей. Аналог mkpfs (pfs-utils) <br />
<br />
* splitmod - разборка составных модулей. Аналог pfsextract (pfs-utils)<br />
<br />
* dnf2mod - сборка модулей из пакетов находящихся в репозиториях с использованием dnf. Аналог dnf2xzm (MagOS)<br />
<br />
* chroot2mod - сборка модулей по сценарию выполняемому в chroot'e, аналогичном базовой системе. Аналог chroot2pfs (pfs-utils)<br />
<br />
* diff-changes - утилита позволяет вычислять изменения в changes за определенный период и создавать из изменений модуль Аналог syschanges (MagOS)<br />
<br />
* getmod - поиск и скачивание модулей из репозитория модулей<br />
<br />
* instmod - установка модуля в систему (локальные файлы, а также rsync и протоколы которые понимает wget) <br />
<br />
* comparator - утилита для объединения одинаковых текстовых файлов находящихся в разных модулях. В первую очередь это касается /etc/shadow, /etc/group, /etc/passwd.<br />
При создании модуля может создаваться пользователь. Если таких модулей несколько, то <br />
<br />
barium comparator -i /etc/shadow /etc/group /etc/passwd<br />
<br />
поможет собрать пользователей по модулям<br />
<br />
* marriage - утилита для управления привязкой Бария к машинам.<br />
<br />
* update - утилита для обновления системы<br />
<br />
* applet - апплет в трей, показывает состояние системы управляет основными функциями ОС Барий<br />
<br />
<br />
'''В версии для установки на токен дополнительно доступны:'''<br />
<br />
* install - консольный инсталлятор бария на токен с привязкой логина к пинкоду<br />
<br />
* install-gui - GUI для barium install<br />
* login - консольная утилита для привязки логина в систему к пинкоду токена<br />
* setup - утилита используемая из install-gui для настройки при первом старте предустановленной на токен ОС Барий<br />
* token - вспомогательная для barium login утилита для определения типа токена<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=Barium:%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B8&diff=20449Barium:модули2023-03-20T07:25:31Z<p>Betcher: </p>
<hr />
<div>=== Что за модули такие ===<br />
UIRD создает корневую файловую систему для дальнейшей загрузки ОС из слоев собранных объединяющей файловой системой aufs/overlayfs. В качестве слоев может использоваться все что возможно смонтировать в Линукс в режиме read only. Чаще всего это squashfs архивы, это и есть модули Бария. Squashfs архив отличает то, что данные из него можно читать блочно, то есть для того чтобы извлечь файл нет необходимости распаковывать весь архив, распаковываются только блоки, в которых лежат части этого файла. Помимо уменьшения размера ОС это часто дает прирост в скорости чтения, особенно с медленных носителей, относительно чтения не сжатых данных с того же носителя. Это происходит потому, что прочитать 1 мегабайт и распаковать его в 3 мегабайта с "быстрым" процессором и "медленным" носителем, будет быстрее чем читать не сжатые 3 мегабайта. Каждый такой модуль содержит свою часть файловой системы. Модуль не равен rpm пакету по содержимому, он может содержать как один файл, так и всю ОС, как это бывает в livecd.<br />
<br />
=== Как сделать модуль ===<br />
Squashfs архивы создаются утилитой mksquashfs из пакета squahfs-tools, и модули вполне можно сделать имея только mksquashfs, но для большего удобства подготовлено несколько утилит в составе barium-utils.<br />
<br />
=== barium mkmod ===<br />
Основная задача утилиты сделать модуль из папки с файлами, дополнительно можно склеивать папки и модули в один модуль в любых сочетаниях.<br />
Например:<br />
У вас есть два файла - программа и ее конфиг. В системе они должны быть размещены по путям:<br />
<br />
/usr/bin/superproga<br />
/etc/superproga.d/superproga.conf<br />
<br />
* Создаем папку с именем будущего модуля:<br />
<br />
mkdir ./superproga<br />
<br />
* Внутри папки создаем нужные каталоги. Обратите внимание на права и пользователя каталогов. Для системных папок обычно достаточно создавать их под рутом.<br />
<br />
<br />
mkdir -p ./superproga/usr/bin<br />
mkdir -p ./superproga/etc/superproga.d<br />
<br />
* копируем файлы в папки, допустим они у нас тоже были в текущем каталоге<br />
<br />
cp ./superproga ./superproga/usr/bin/<br />
cp ./superproga.conf ./superproga/etc/superproga.d/<br />
<br />
* Пакуем<br />
<br />
'''barium mkmod ./superproga'''<br />
<br />
Итогом будет модуль superproga.xzm, при подключении которого файлы окажутся в системе в нужных подкаталогах.<br />
Модули невозможно редактировать, они монтируются только RO, поэтому, если вам нужно будет что-то изменить, придется собирать модуль заново.<br />
Если же нужно добавить файл в модуль, можно воспользоваться режимом "склейки" утилиты barium mkmod<br />
<br />
mkdir -p ./superproga2/etc/skel/.config/<br />
cp superproga.conf ./superproga2/etc/skel/.config/<br />
'''barium mkmod ./superproga2 ./superproga.xzm -o superproga2.xzm'''<br />
<br />
=== Распаковка модулей ===<br />
<br />
Для распаковки модуля проще всего смонтировать модуль и забрать содержимое из точки монтирования.<br />
Также можно использовать утилиту unsquashfs.<br />
Для разборки составного ("склеенного") модуля есть утилита barium split<br />
<br />
=== barium dnf2mod === <br />
<br />
Пожалуй наиболее востребованная утилита для сборки модулей. Она использует dnf. То есть устанавливает в модуль запрошенные пакеты из репозитория, вместе с зависимостями и результатом выполнения скриптов из rpm. После установки из модуля удаляются базы rpm, dnf и кэши. Таким образом, при подключении модуля, база rpm не изменится и пакеты не будут зарегистрированы как установленные в системе. Это сделано для того, чтобы модули не были инкрементно зависимы. Любой модуль собранный dnf2mod зависит только от базовых модулей системы и может быть удален в любой момент не нарушая работу других модулей.<br />
<br />
Например: <br />
<br />
'''barium dnf2mod nano'''<br />
<br />
Соберет пакет с редактором nano. Пакет будет собран даже в том случае, если nano уже есть в базовой системе. Это позволяет, например, выборочно обновить пакет не дожидаясь обновления всей системы.<br />
<br />
Можно передать список модулей:<br />
<br />
'''barium dnf2mod nano mc busybox''' <br />
<br />
С ключoм "-с" утилита будет использовать системные настройки и кэши dnf.<br />
В конце строки с параметрами после ключа --dnf можно дописать параметры, которые будут передаваться dnf при установке, например --repofrompath.<br />
Нет необходимости запоминать параметры сборки модуля, они хранятся внутри и запустив <br />
<br />
'''barium dnf2mod nano.xzm''' <br />
<br />
вы пересоберете модуль с теми же параметрами как он был собран, но с обновленными пакетами из репозитория.<br />
<br />
=== barium chroot2mod === <br />
<br />
Утилита пакует в модуль изменения файлов произошедшие в chroot, которые являются результатом выполнения команды или скрипта. Rootfs для chroot при этом собрана из базовых модулей системы.<br />
Звучит малопонятно, далее на примерах.<br />
<br />
'''barium chroo2mod -o nano.xzm --command dnf install nano'''<br />
<br />
<br />
Утилита создаст rootfs из базовых модулей так, как это делает uird, выполнит в chroot указанную команду, и запакует только новые и измененные в результате выполнения команды файлы.<br />
Результат будет близок к barium dnf2mod nano, за исключением того, что кэши и базы rpm и dnf автоматически не удаляются.<br />
В данном примере используется dnf, но утилита с ним никак не связана, можно запустить какой-то консольный конфигуратор или wget или просто /bin/bash и сделать все руками, после выхода из оболочки все будет запаковано.<br />
<br />
Для более сложных случаев вместо параметра --command используется --script, которому передается сценарий сборки, обычно это bash, но не принципиально. <br />
<br />
Пример: <br />
<br />
Создаем скрипт getproga.sh для гипотетического проекта proga, для простоты допустим, что компилировать не нужно, только забрать скрипты c гит репозитория <br />
<br />
#!/bin/bash<br />
# устанавливаем необходимые для сборки пакеты<br />
dnf install git-core<br />
cd /tmp<br />
# клонируем проект с гит репозитория<br />
git clone https://server/user/proga.git<br />
# устанавливаем<br />
chmod +x ./proga/bin/* <br />
cp ./proga/bin/* /usr/bin/<br />
# зачищаем<br />
dnf remove git-core<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
Делаем исполняемым:<br />
chmod +x getproga.sh<br />
<br />
Запускаем сборку:<br />
<br />
'''barium chroo2mod -o proga.xzm --script ./getproga.sh'''<br />
<br />
<br />
Для того, чтобы использовать внутри сборочной рутфс файлы, находящиеся снаружи (то есть в основной системе), используем параметр --bind. Ему передается два пути к папкам разделенные двоеточием. Первый путь снаружи rootfs, второй внутри. В таком случае --script уже не нужен, указываем --command /путь/в/rootfs/скрипт.sh <br />
<br />
Пример:<br />
<br />
Создаем папку, в которой будут файлы для сборки модуля.<br />
Переносим в нее yandex-browser.rpm<br />
Рядом создаем скрипт yb.sh:<br />
<br />
#!/bin/bash<br />
# переходим в каталог с файлами для сборки<br />
cd $(basedir $0)<br />
# устанавливаем rpm<br />
dnf install -y ./yandex-browser.rpm<br />
# зачищаем (если нужно)<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
# и т.д.<br />
<br />
Делаем исполняемым:<br />
chmod +x yb.sh<br />
<br />
Находясь в каталоге со скриптом и rpm пакетом запускаем сборку.<br />
<br />
'''barium chroot2mod -o yandex-browser.xzm --bind ./::/var/lib/YB --command /var/lib/YB/yb.sh'''<br />
<br />
<br />
Еще более сложный реальный пример скрипта, для сборки аналогичным способом. С подключением локального каталога с rpm пакетами как репозитория:<br />
<br />
#!/bin/bash<br />
BASE=$(dirname $0)<br />
dnf install -y lsb || echo lsb > /tmp/problem.packages<br />
echo "[localrepo]<br />
name=tmprepo<br />
baseurl=file://${BASE}/REPO<br />
enabled=1<br />
gpgcheck=0" > /etc/yum.repos.d/tmp.repo<br />
# включаем i686 репозитории<br />
for a in $(ls -1 /etc/yum.repos.d |grep i686) ; do<br />
sed -i 's/enabled.*/enabled=1/' /etc/yum.repos.d/$a<br />
done<br />
dnf refresh<br />
pushd $BASE<br />
cp -fax ./CERT/* / || echo "error ${LINENO}"<br />
#Установка корневых сертификатов<br />
update-ca-trust enable<br />
tar -xf /tmp/stunnel/dis/root_crt.tar.gz -C /etc/pki/ca-trust/source/anchors/<br />
cat x86_64.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y || echo $a >> /tmp/problem.packages<br />
done<br />
echo 'i686 ===============' >> /tmp/problem.packages<br />
echo "Install i686 packages"<br />
cat i686.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo $a |xargs dnf install -y --forcearch i686 || echo $a >> /tmp/problem.packages <br />
done<br />
echo 'Problem rpms ===========' >> /tmp/problem.packages<br />
echo "Install problem packages"<br />
cat problem_rpm.need |grep -v '^#'| grep -v '^[[:space:]]*$' | while read a ; do <br />
echo ========= $a ===============<br />
dnf download $a<br />
name=$(ls -1 |grep -i $a)<br />
rpm -Uhv --nodeps ./$name || echo $a >> /tmp/problem.packages<br />
rm - $name<br />
done<br />
# подключение библиотек смарткарт к цитриксу<br />
ln -sf /usr/lib64/libeToken.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
ln -sf /usr/lib64/libjcPKCS11-2.so '/opt/Citrix/ICAClient/PKCS#11/'<br />
# сертификат для цитрикс-клиента<br />
cp /etc/pki/127.0.0.1.crt /opt/Citrix/ICAClient/keystore/cacerts/127.0.0.1.pem<br />
/opt/Citrix/ICAClient/util/ctx_rehash<br />
# русская клавиатура для цитрикса<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/All_Regions.ini<br />
sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/usertemplate/All_Regions.ini<br />
# systemctl daemon-reload<br />
# обновляем системное хранилище сертификатов для браузера <br />
update-ca-trust<br />
# подключаем в загрузку туннели<br />
systemctl enable iuspt-in.service<br />
systemctl enable iuspt-out.service<br />
mkdir -p /opt/cprocsp/var/run/stunnel<br />
# подключаем сертификаты к КриптоПро<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mCA -file /etc/pki/gazprom_inform_ca_gost_2012.cer<br />
/opt/cprocsp/bin/amd64/certmgr -install -store mROOT -file /etc/pki/root_gazprom_ca_gost_2012.cer<br />
# устанавливаем скрипт для файрфокса в автостарт<br />
chmod +x setup_user.sh<br />
cp setup_user.sh /usr/lib/rosa-rw/rc.desktop/all/<br />
popd<br />
rm -f /etc/yum.repos.d/tmp.repo<br />
dnf clean all<br />
rm -rf /var/cache/dnf<br />
<br />
<br />
Модули собранные утилитой barium chroot2mod, также как и с dnf2mod, хранят cmdline сборки, но пересобраться смогут только те, что собраны независимо, то есть без локальных файлов.<br />
<br />
====Проекты для chroot2mod==== <br />
<br />
Если модуль предполагается периодически пересобирать для обновления, а сборка требует сценарий и дополнительные файлы, вместо --script удобнее использовать новый параметр --project, которому передается имя папки с проектом. Здесь проект это каталог, который содержит один обязательный файл - build.c2m, а также другие файлы и папки нужные вам для сборки. Файл build.c2m это скрипт, обычно bash, но не обязательно. Он должен иметь права на выполнение. Логика написания скрипта такая же ка для --script. Плюсы --project в том что такие проекты удобнее хранить и собирать.<br />
<br />
'''barium chroot2mod --project ./project_dir '''<br />
<br />
Пример build.c2m для сборки модуля КонтинетАп:<br />
<br />
#!/bin/bash<br />
cd $(dirname $0) # делаем текущей папку с build.c2m и cts.rpm <br />
dnf install ./cts* # устанавливаем локальный rpm файл cts, а также необходимые зависимости. Можно rpm -Uhv если зависимостей нет.<br />
systemctl enable cts # включаем сервис cts по умолчанию<br />
<br />
=== Решение проблем ===<br />
<br />
Случается,что при некорректном завершении сборочных утилит остаются артефакты монтирований. Это может привести к невозможности сборки. В большинстве случаев поможет:<br />
<br />
'''barium b-lib destroy_union 5'''<br />
'''barium b-lib destroy_layers 5''' <br />
<br />
Пять здесь предположительное количество некорректно завершенных заданий. Пишите больше не ошибетесь :)<br />
<br />
[[Категория:Barium]]</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%BD%D0%B0_%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB&diff=19858Установка на шифрованный раздел2023-02-06T06:36:23Z<p>Betcher: </p>
<hr />
<div>== ЗАГОТОВКА СТАТЬИ ==<br />
<br />
<br />
== Установка ==<br />
Инсталлятор anaconda. используемый в Роса начиная с платформы rosa2021.1, позволяет создавать шифрованные разделы в том числе можно шифровать и всю корневую ФС, при условии что загрузчики будут вынесены на отдельные разделы.<br />
<br />
Для установки с шифрованным корнем делаем следующую разбивку:<br />
<br />
====Раздел 1==== <br />
<br />
* Размер - 100-200 Мb<br />
* FS - vfat, флаг esp (если разбивка в анаконде достаточно указать тип) <br />
* Точка монтирования - /boot/efi<br />
<br />
====Раздел 2====<br />
* Размер - 500-1000 Mb (для установки хватит и 300, но для обновления initrd уже недостаточно)<br />
* FS: ext4<br />
* Точка монтирования - /boot<br />
<br />
====Раздел 3====<br />
* Размер - от 10 Gb<br />
* FS - любая с поддержкой юникс прав, например ext4<br />
* Точка монтирования - /<br />
* Вот для этого раздела включаем шифрование LUKS2<br />
<br />
Дальнейшая установка не отличается ничем. Во время загрузки ОС после выбора пункта загрузки в меню граба на этапе initrd у вас будет запрашиваться пароль. Прямо поверх заставки plymouth. <br />
Описания там нет нужно вводить пароль от корневого LUKS2 раздела.<br />
<br />
== Загрузка без ввода пароля ==<br />
Как вы уже заметили загрузчики остаются на открытых разделах, чтобы защитить машину от взлома путем внесения изменений на этих разделах необходимо устанавливать пароль для UEFI.<br />
Но это приведет к тому, что для загрузки вам нужно будет вводить уже два пароля, а если еще отключен автологин то уже три. Однако есть способ загружать машину без ввода пароля LUKS <br />
не теряя при этом в безопасности.<br />
<br />
Все современные x86_64 машины, примерно с 16го года оснащаются модулем [https://ru.wikipedia.org/wiki/TPM_(%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F) tpm2], который можно использовать для разблокировки раздела LUKS. Упрощенно можно объяснить идею так - ключ от LUKS вместо вас вводит машина. Таким образом изъятый носитель расшифровать не получится потому что ключ в машине, а машину загрузить не получится потому-что пароль на загрузку UEFI.<br />
<br />
'''Есть два способа использования tpm2 для авторазблокировки корневого раздела LUKS для Linux.''' <br />
<br />
* c использованием фреймворка clevis<br />
* c systemd-cryptenroll. <br />
<br />
Оба доступны для ОС Роса платформы rosa2021.1 и новее. Для их использования подготовлены специальные пакеты с упрощающие настройку:<br />
<br />
luksunlock-systemd<br />
luksunlock-clevis<br />
<br />
''Можно выбрать любой либо устанавливать luksunlock и система выберет лучший вариант.''<br />
<br />
'''В консоли с правами root в системе установленной в LUKS раздел выполните:'''<br />
<br />
dnf install luksunlock -y <br />
luksunlock<br />
<br />
Далее следуйте указаниям утилиты, в простейшем случае понадобится только ввести пароль для LUKS раздела. После завершения работы утилиты пароль LUKS при загрузке более запрашиваться не будет.<br />
<br />
''Важно!!! В случае использования luksunlock-clevis окошко для ввода пароля все равно будет появляться.''<br />
<br />
''Паниковать и пытаться вводить пароль не нужно, просто дождитесь окончания загрузки.'' <br />
<br />
'''Для того чтобы отключить авторазблокировку корневого раздела LUKS:'''<br />
<br />
lukslock</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%BD%D0%B0_%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB&diff=19857Установка на шифрованный раздел2023-02-06T06:33:52Z<p>Betcher: </p>
<hr />
<div>== ЗАГОТОВКА СТАТЬИ ==<br />
<br />
<br />
== Установка ==<br />
'''Инсталлятор anaconda. используемый в Роса начиная с платформы rosa2021.1, позволяет создавать шифрованные разделы в том числе можно шифровать и всю корневую ФС, при условии что загрузчики будут вынесены на отдельные разделы.'''<br />
<br />
Для установки с шифрованным корнем делаем следующую разбивку:<br />
<br />
====Раздел 1==== <br />
<br />
* Размер - 100-200 Мb<br />
* FS - vfat, флаг esp (если разбивка в анаконде достаточно указать тип) <br />
* Точка монтирования - /boot/efi<br />
<br />
====Раздел 2====<br />
* Размер - 500-1000 Mb (для установки хватит и 300, но для обновления initrd уже недостаточно)<br />
* FS: ext4<br />
* Точка монтирования - /boot<br />
<br />
====Раздел 3====<br />
* Размер - от 10 Gb<br />
* FS - любая с поддержкой юникс прав, например ext4<br />
* Точка монтирования - /<br />
* Вот для этого раздела включаем шифрование LUKS2<br />
<br />
Дальнейшая установка не отличается ничем. Во время загрузки ОС после выбора пункта загрузки в меню граба на этапе initrd у вас будет запрашиваться пароль. Прямо поверх заставки plymouth. <br />
Описания там нет нужно вводить пароль от корневого LUKS2 раздела.<br />
<br />
== Загрузка без ввода пароля ==<br />
Как вы уже заметили загрузчики остаются на открытых разделах, чтобы защитить машину от взлома путем внесения изменений на этих разделах необходимо устанавливать пароль для UEFI.<br />
Но это приведет к тому, что для загрузки вам нужно будет вводить уже два пароля, а если еще отключен автологин то уже три. Однако есть способ загружать машину без ввода пароля LUKS <br />
не теряя при этом в безопасности.<br />
<br />
Все современные x86_64 машины, примерно с 16го года оснащаются модулем [https://ru.wikipedia.org/wiki/TPM_(%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F) tpm2], который можно использовать для разблокировки раздела LUKS. Упрощенно можно объяснить идею так - ключ от LUKS вместо вас вводит машина. Таким образом изъятый носитель расшифровать не получится потому что ключ в машине, а машину загрузить не получится потому-что пароль на загрузку UEFI.<br />
<br />
'''Есть два способа использования tpm2 для авторазблокировки корневого раздела LUKS для Linux.''' <br />
<br />
* c использованием фреймворка clevis<br />
* c systemd-cryptenroll. <br />
<br />
Оба доступны для ОС Роса платформы rosa2021.1 и новее. Для их использования подготовлены специальные пакеты с упрощающие настройку:<br />
<br />
luksunlock-systemd<br />
luksunlock-clevis<br />
<br />
''Можно выбрать любой либо устанавливать luksunlock и система выберет лучший вариант.''<br />
<br />
'''В консоли с правами root в системе установленной в LUKS раздел выполните:'''<br />
<br />
dnf install luksunlock -y <br />
luksunlock<br />
<br />
Далее следуйте указаниям утилиты, в простейшем случае понадобится только ввести пароль для LUKS раздела. После завершения работы утилиты пароль LUKS при загрузке более запрашиваться не будет.<br />
<br />
''Важно!!! В случае использования luksunlock-clevis окошко для ввода пароля все равно будет появляться. Паниковать и пытаться вводить пароль не нужно, просто дождитесь окончания загрузки.'' <br />
<br />
Для того чтобы отключить авторазблокировку корневого раздела LUKS:<br />
<br />
lukslock</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%BD%D0%B0_%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB&diff=19856Установка на шифрованный раздел2023-02-06T06:28:56Z<p>Betcher: </p>
<hr />
<div>== ЗАГОТОВКА СТАТЬИ ==<br />
<br />
<br />
== Установка ==<br />
Инсталлятор anaconda. используемый в Роса начиная с платформы rosa2021.1, позволяет создавать шифрованные разделы в том числе можно шифровать и всю корневую ФС, при условии что загрузчики будут вынесены на отдельные разделы.<br />
<br />
Для установки с шифрованным корнем делаем следующую разбивку:<br />
<br />
====Раздел 1==== <br />
<br />
* Размер - 100-200 Мb<br />
* FS - vfat, флаг esp (если разбивка в анаконде достаточно указать тип) <br />
* Точка монтирования - /boot/efi<br />
<br />
====Раздел 2====<br />
* Размер - 500-1000 Mb (для установки хватит и 300, но для обновления initrd уже недостаточно)<br />
* FS: ext4<br />
* Точка монтирования - /boot<br />
<br />
====Раздел 3====<br />
* Размер - от 10 Gb<br />
* FS - любая с поддержкой юникс прав, например ext4<br />
* Точка монтирования - /<br />
* Вот для этого раздела включаем шифрование LUKS2<br />
<br />
Дальнейшая установка не отличается ничем. Во время загрузки ОС после выбора пункта загрузки в меню граба на этапе initrd у вас будет запрашиваться пароль. Прямо поверх заставки plymouth. <br />
Описания там нет нужно вводить пароль от корневого LUKS2 раздела.<br />
<br />
== Загрузка без ввода пароля ==<br />
Как вы уже заметили загрузчики остаются на открытых разделах, чтобы защитить машину от взлома путем внесения изменений на этих разделах необходимо устанавливать пароль для UEFI.<br />
Но это приведет к тому, что для загрузки вам нужно будет вводить уже два пароля, а если еще отключен автологин то уже три. Однако есть способ загружать машину без ввода пароля LUKS <br />
не теряя при этом в безопасности.<br />
<br />
Все современные x86_64 машины, примерно с 16го года оснащаются модулем [https://ru.wikipedia.org/wiki/TPM_(%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F) tpm2], который можно использовать для разблокировки раздела LUKS. Упрощенно можно объяснить идею так - ключ от LUKS вместо вас вводит машина. Таким образом изъятый носитель расшифровать не получится потому что ключ в машине, а машину загрузить не получится потому-что пароль на загрузку UEFI.<br />
<br />
Есть два способа использования tpm2 для авторазблокировки корневого раздела LUKS для Linux. <br />
<br />
* c использованием фреймворка clevis<br />
* c systemd-cryptenroll. <br />
<br />
Оба доступны для ОС Роса платформы rosa2021.1 и новее. Для их использования подготовлены специальные пакеты с упрощающие настройку:<br />
<br />
luksunlock-systemd<br />
luksunlock-clevis<br />
<br />
''Можно выбрать любой либо устанавливать luksunlock и система выберет лучший вариант.''<br />
<br />
'''В консоли с правами root в системе установленной в LUKS раздел выполните:'''<br />
<br />
dnf install luksunlock -y <br />
luksunlock<br />
<br />
Далее следуйте указаниям утилиты, в простейшем случае понадобится только ввести пароль для LUKS раздела. После завершения работы утилиты пароль LUKS при загрузке более запрашиваться не будет.<br />
Важно!!! В случае использования luksunlock-clevis окошко для ввода пароля все равно будет появляться. Паниковать и пытаться вводить пароль не нужно, просто дождитесь окончания загрузки. <br />
<br />
Для того чтобы отключить авторазблокировку корневого раздела LUKS:<br />
<br />
lukslock</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%BD%D0%B0_%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB&diff=19836Установка на шифрованный раздел2023-01-17T16:32:22Z<p>Betcher: /* Загрузка без ввода пароля */</p>
<hr />
<div>== ЗАГОТОВКА СТАТЬИ ==<br />
<br />
<br />
== Установка ==<br />
Инсталлятор anaconda. используемый в Роса начиная с платформы rosa2021.1, позволяет создавать шифрованные разделы в том числе можно шифровать и всю корневую ФС, при условии что загрузчики будут вынесены на отдельные разделы.<br />
<br />
Для установки с шифрованным корнем делаем следующую разбивку:<br />
<br />
====Раздел 1==== <br />
<br />
* Размер - 100-200 Мb<br />
* FS - vfat, флаг esp (если разбивка в анаконде достаточно указать тип) <br />
* Точка монтирования - /boot/efi<br />
<br />
====Раздел 2====<br />
* Размер - 500-1000 Mb (для установки хватит и 300, но для обновления initrd уже недостаточно)<br />
* FS: ext4<br />
* Точка монтирования - /boot<br />
<br />
====Раздел 3====<br />
* Размер - от 10 Gb<br />
* FS - любая с поддержкой юникс прав, например ext4<br />
* Точка монтирования - /<br />
* Вот для этого раздела включаем шифрование LUKS2<br />
<br />
Дальнейшая установка не отличается ничем. Во время загрузки ОС после выбора пункта загрузки в меню граба на этапе initrd у вас будет запрашиваться пароль. Прямо поверх заставки plymouth. <br />
Описания там нет нужно вводить пароль от корневого LUKS2 раздела.<br />
<br />
== Загрузка без ввода пароля ==<br />
Как вы уже заметили загрузчики остаются на открытых разделах, чтобы защитить машину от взлома путем внесения изменений на этих разделах необходимо устанавливать пароль для UEFI.<br />
Но это приведет к тому, что для загрузки вам нужно будет вводить уже два пароля, а если еще отключен автологин то уже три. Однако есть способ загружать машину без ввода пароля LUKS <br />
не теряя при этом в безопасности.<br />
<br />
Все современные x86_64 машины, примерно с 16го года оснащаются модулем [https://ru.wikipedia.org/wiki/TPM_(%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F) tpm2], который можно использовать для разблокировки раздела LUKS. Упрощенно можно объяснить идею так - ключ от LUKS вместо вас вводит машина. Таким образом изъятый носитель расшифровать не получится потому что ключ в машине, а машину загрузить не получится потому-что пароль на загрузку UEFI.<br />
<br />
Есть два способа использования tpm2 для авторазблокировки корневого раздела LUKS для Linux. <br />
<br />
# c использованием фреймворка clevis <br />
# c systemd-cryptenroll. <br />
<br />
Оба доступны для ОС Роса платформы rosa2021.1 и новее. Для их использования подготовлены специальные пакеты с упрощающие настройку:<br />
<br />
luksunlock-systemd<br />
luksunlock-clevis<br />
<br />
Можно выбрать любой либо устанавливать luksunlock и система выберет лучший вариант.<br />
<br />
В консоли с правами root в системе установленной в LUKS раздел выполните:<br />
<br />
dnf install luksunlock -y <br />
luksunlock<br />
<br />
Далее следуйте указаниям утилиты, в простейшем случае понадобится только ввести пароль для LUKS раздела. После завершения работы утилиты пароль LUKS при загрузке более запрашиваться не будет.<br />
<br />
Для того чтобы отключить авторазблокировку корневого раздела LUKS:<br />
<br />
lukslock</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%BD%D0%B0_%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB&diff=19835Установка на шифрованный раздел2023-01-17T16:31:18Z<p>Betcher: /* Раздел 3 */</p>
<hr />
<div>== ЗАГОТОВКА СТАТЬИ ==<br />
<br />
<br />
== Установка ==<br />
Инсталлятор anaconda. используемый в Роса начиная с платформы rosa2021.1, позволяет создавать шифрованные разделы в том числе можно шифровать и всю корневую ФС, при условии что загрузчики будут вынесены на отдельные разделы.<br />
<br />
Для установки с шифрованным корнем делаем следующую разбивку:<br />
<br />
====Раздел 1==== <br />
<br />
* Размер - 100-200 Мb<br />
* FS - vfat, флаг esp (если разбивка в анаконде достаточно указать тип) <br />
* Точка монтирования - /boot/efi<br />
<br />
====Раздел 2====<br />
* Размер - 500-1000 Mb (для установки хватит и 300, но для обновления initrd уже недостаточно)<br />
* FS: ext4<br />
* Точка монтирования - /boot<br />
<br />
====Раздел 3====<br />
* Размер - от 10 Gb<br />
* FS - любая с поддержкой юникс прав, например ext4<br />
* Точка монтирования - /<br />
* Вот для этого раздела включаем шифрование LUKS2<br />
<br />
Дальнейшая установка не отличается ничем. Во время загрузки ОС после выбора пункта загрузки в меню граба на этапе initrd у вас будет запрашиваться пароль. Прямо поверх заставки plymouth. <br />
Описания там нет нужно вводить пароль от корневого LUKS2 раздела.<br />
<br />
== Загрузка без ввода пароля ==<br />
Как вы уже заметили загрузчики остаются на открытых разделах, чтобы защитить машину от взлома путем внесения изменений на этих разделах необходимо устанавливать пароль для UEFI.<br />
Но это приведет к тому, что для загрузки вам нужно будет вводить уже два пароля, а если еще отключен автологин то уже три. Однако есть способ загружать машину без ввода пароля LUKS <br />
не теряя при этом в безопасности.<br />
<br />
Все современные x86_64 машины, примерно с 16го года оснащаются модулем [https://ru.wikipedia.org/wiki/TPM_(%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F) tpm2], который можно использовать для разблокировки раздела LUKS. Утрируя можно объяснить идею так: ключ от LUKS вместо вас вводит машина. Таким образом изъятый носитель расшифровать не получится потому что ключ в машине, а машину загрузить не получится потому-что пароль на загрузку UEFI.<br />
<br />
Есть два способа использования tpm2 для авторазблокировки корневого раздела LUKS для Linux. <br />
<br />
# c использованием фреймворка clevis <br />
# c systemd-cryptenroll. <br />
<br />
Оба доступны для ОС Роса платформы rosa2021.1 и новее. Для их использования подготовлены специальные пакеты с упрощающие настройку:<br />
<br />
luksunlock-systemd<br />
luksunlock-clevis<br />
<br />
Можно выбрать любой либо устанавливать luksunlock и система выберет лучший вариант.<br />
<br />
В консоли с правами root в системе установленной в LUKS раздел выполните:<br />
<br />
dnf install luksunlock -y <br />
luksunlock<br />
<br />
Далее следуйте указаниям утилиты, в простейшем случае понадобится только ввести пароль для LUKS раздела. После завершения работы утилиты пароль LUKS при загрузке более запрашиваться не будет.<br />
<br />
Для того чтобы отключить авторазблокировку корневого раздела LUKS:<br />
<br />
lukslock</div>Betcherhttp://wiki.rosalab.ru/ru/index.php?title=%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%BD%D0%B0_%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB&diff=19834Установка на шифрованный раздел2023-01-17T09:05:46Z<p>Betcher: /* Загрузка без ввода пароля */</p>
<hr />
<div>== ЗАГОТОВКА СТАТЬИ ==<br />
<br />
<br />
== Установка ==<br />
Инсталлятор anaconda. используемый в Роса начиная с платформы rosa2021.1, позволяет создавать шифрованные разделы в том числе можно шифровать и всю корневую ФС, при условии что загрузчики будут вынесены на отдельные разделы.<br />
<br />
Для установки с шифрованным корнем делаем следующую разбивку:<br />
<br />
====Раздел 1==== <br />
<br />
* Размер - 100-200 Мb<br />
* FS - vfat, флаг esp (если разбивка в анаконде достаточно указать тип) <br />
* Точка монтирования - /boot/efi<br />
<br />
====Раздел 2====<br />
* Размер - 500-1000 Mb (для установки хватит и 300, но для обновления initrd уже недостаточно)<br />
* FS: ext4<br />
* Точка монтирования - /boot<br />
<br />
====Раздел 3====<br />
* Размер - от 10 Gb<br />
* FS - любая с поддержкой юникс прав, например ext4<br />
* Точка монтирования - /<br />
* Вот для этого раздела включаем шифрование LUKS2<br />
<br />
Дальнейшая установка не отличается ничем. Во время загрузки ОС после выбора пункта загрузки в меню граба на этапе initrd у вас будет запрошен пароль. Прямо поверх заставки plymouth. <br />
Описания там нет нужно вводить пароль от корневого LUKS2 раздела.<br />
<br />
== Загрузка без ввода пароля ==<br />
Как вы уже заметили загрузчики остаются на открытых разделах, чтобы защитить машину от взлома путем внесения изменений на этих разделах необходимо устанавливать пароль для UEFI.<br />
Но это приведет к тому, что для загрузки вам нужно будет вводить уже два пароля, а если еще отключен автологин то уже три. Однако есть способ загружать машину без ввода пароля LUKS <br />
не теряя при этом в безопасности.<br />
<br />
Все современные x86_64 машины, примерно с 16го года оснащаются модулем [https://ru.wikipedia.org/wiki/TPM_(%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F) tpm2], который можно использовать для разблокировки раздела LUKS. Утрируя можно объяснить идею так: ключ от LUKS вместо вас вводит машина. Таким образом изъятый носитель расшифровать не получится потому что ключ в машине, а машину загрузить не получится потому-что пароль на загрузку UEFI.<br />
<br />
Есть два способа использования tpm2 для авторазблокировки корневого раздела LUKS для Linux. <br />
<br />
# c использованием фреймворка clevis <br />
# c systemd-cryptenroll. <br />
<br />
Оба доступны для ОС Роса платформы rosa2021.1 и новее. Для их использования подготовлены специальные пакеты с упрощающие настройку:<br />
<br />
luksunlock-systemd<br />
luksunlock-clevis<br />
<br />
Можно выбрать любой либо устанавливать luksunlock и система выберет лучший вариант.<br />
<br />
В консоли с правами root в системе установленной в LUKS раздел выполните:<br />
<br />
dnf install luksunlock -y <br />
luksunlock<br />
<br />
Далее следуйте указаниям утилиты, в простейшем случае понадобится только ввести пароль для LUKS раздела. После завершения работы утилиты пароль LUKS при загрузке более запрашиваться не будет.<br />
<br />
Для того чтобы отключить авторазблокировку корневого раздела LUKS:<br />
<br />
lukslock</div>Betcher