Сборка UIRD в магее

#21

Проблема есть
При загрузке с UIRD в AUFS Магеи 7.1 пакет shadow-utils-4.6-1.mga7.x86_64.rpm не устанавливается
Но если загрузить в LiveDVD от Магеи то устанавливается
Т е к Магее не обратиться
Причем если загрузить от UIRD LiveDVD от Магеи пакет shadow-utils-4.6-1.mga7.x86_64.rpm не устанавливается
С пакетом прежней версии shadow-utils-4.4-1.2.mga6.x86_64.rpm все ок

Проверка :
Удаляю пакет shadow-utils

/ # rpm --nodeps -e shadow-utils

Пробую установить его

/ # rpm -ivh shadow-utils-4.6-1.mga7.x86_64.rpm
Verifying… ################################# [100%]
Подготовка… ################################# [100%]
Обновление / установка…
1:shadow-utils-2:4.6-1.mga7 ################################# [100%]
ошибка: распаковка архива не удалась на файле /usr/bin/newgidmap;5d4946f0: cpio: cap_set_file не удалось - Нет такого файла или каталога
ошибка: shadow-utils-2:4.6-1.mga7.x86_64: установить не удалось

Отличия пакетов (из shadow-utils.spec)
shadow-utils-4.4-1.2.mga6.x86_64.rpm

%files -f shadow.lang
%doc doc/HOWTO NEWS
%doc doc/WISHLIST doc/README.platforms
%attr(0640,root,shadow) %config(noreplace) %{_sysconfdir}/login.defs
%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/default/useradd
%{_bindir}/sg
%attr(2711,root,shadow) %{_bindir}/chage
%attr(4711,root,root) %{_bindir}/gpasswd
%attr(4711,root,root) %{_bindir}/newgidmap
%attr(4711,root,root) %{_bindir}/newgrp
%attr(4711,root,root) %{_bindir}/newuidmap

shadow-utils-4.6-1.mga7.x86_64.rpm

%files -f shadow.lang
%doc doc/HOWTO NEWS
%doc doc/WISHLIST doc/README.platforms
%attr(0640,root,shadow) %config(noreplace) %{_sysconfdir}/login.defs
%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/default/useradd
%{_bindir}/sg
%attr(2711,root,shadow) %{_bindir}/chage
%attr(4711,root,root) %{_bindir}/gpasswd
%attr(0711,root,root) %caps(cap_setgid=ep) %{_bindir}/newgidmap
%attr(4711,root,root) %{_bindir}/newgrp
%attr(0711,root,root) %caps(cap_setuid=ep) %{_bindir}/newuidmap

Или отличия для newgidmap
%attr(4711,root,root) %{_bindir}/newgidmap
%attr(0711,root,root) %caps(cap_setgid=ep) %{_bindir}/newgidmap

Т е отличаются %caps(cap_setgid=ep) это :

use caps instead of setuid on newuidmap/newgidmap

Что бы это значило ?

#22

Не знаю даже. Там, кстати, еще права разные в %attr

#23

Это в переводе

используйте заглавные буквы вместо setuid на newuidmap / newgidmap

И вроде ошибка никак не связана с заглавными буквами

Если бы права доступа были виновны, то и сообщение было бы другое
Сам newgidmap то же что на старой версии
Пока делаю системный модуль на Магее а все остальное дособирываю.
Чистая пакетная сборка не собирается
Конечно можно либо использовать старый shadow-utils или его перекомпилировать

#24

Наверное. Цифра 4 впереди это SUID, выполнять с правами владельца.

#25

Таблица разделов на флэшке у меня уже давно gpt и сегодня сделал флэшку в msdos(bios) разметке.
Но ничего не изменилось и баг остался.
Пробовал для верности на LiveDVD от Магеи запустить сборку дистра но не получилось.
Видимо пакетов не хватает
Кроме того еще не устанавливается пакеты perl, gnome-keyring а может и еще найдется.
Повторюсь, что данную проблему я обхожу. Использую сис-модуль на базе штатной установки Магеи в минимальной конфигурации где данные пакеты уже установлены.
Вроде как aufs виновата
В федоре смотрел shadow-utils и он аналогичный с Магеей
В Росе обновят shadow-utils и в МагОС эта же проблема будет.

#26

Пересобрал я shadow-utils-4.6-1.mga7.x86_64.rpm
Командой :slight_smile:

rpmrebuild -e shadow-utils

При этом удалив из спека %caps(cap_setgid=ep)

%attr(0711,root,root) %{_bindir}/newgidmap
%attr(4711,root,root) %{_bindir}/newgrp
%attr(0711,root,root) %{_bindir}/newuidmap

Все !
Пакетная сборка пошла !!!
Но все равно остался вопрос. Что такое %caps(cap_setgid=ep)
И почему shadow-utils устанавливается в LiveDVD от Магеи
И почему пакет не устанавливается в aufs, на которой собирается MagOS

#27

rpmdrake2xzm - https://cloud.mail.ru/public/3kv7/2UkX7bbra

Запустил на Магее
Изменения :slight_smile:

  1. Стр 67

for a in ls -dr $mod_path/??-*; do

Это берется rpm-база с последнего модуля
Иначе с первого

  1. Теперь /var/lib/rpm/Packages будут запоминаться в модуле записи
    Для этого перенес со своего chrootdisk clear_rpm - стр 39

  2. Прежний вариант rpmdrake2xzm не записывал модуль на LXQt
    Глючит mdialog
    В магее отсутствует xuserrun
    Закоментировал со стр 38 в mdialog

start mdialog with xuserrun
if [ “$(id -un)” = “root” ] ;then
xuserrun $0 “$@” ; exit
fi

В итоге kdialog на плазме работает а zenity на LXQt нет
Заменил mdialog на cXdialog в стр 107
Теперь везде все работает

  1. Ввел переменную
    Это куда будет писаться модуль

SELECT=/memory/layer-base/0

Меня этот адрес устраивает. В моей сборке есть возможность без особых усилий запускать 4 различные сборки и как раз при различных запусках модуль будет писаться куда надо
А имена папок MagOS и MagOS-Data в корне флэшки в моей сборке пришлось изменить
на Linux и LX-Data
Т к нельзя было запустить вашу сборку из MagOS/MagOS
Уже протестировал. Обновил Магею и МагОС из rpmdrake2xzm

  1. Заменил gactivate на activate

[ $? = 0 ] && activate “$mod_name”

gactivate на plasma работает на LXQt нет (нет сообщения о выполнении операции)
Вроде все. Возможно что по мелочи
А так rpmdrake2xzm понравилась тем что если не установить пакета то модуля и не создается
И запускается от обычного пользователя. Мой chrootdisk только от root
Теперь это надеюсь просто аналог штатного rpmdrake2xzm, но только с возможностью создания модуля

PS
Не понял зачем создается

mod_file="$URPMITMP/rpmdrake2xzm.img"

В своем chrootdisk я обхожусь без pmdrake2xzm.img
Но вроде не мешает

#28

Это скрипт найденный на гитхабе и слегка модифицированный. Должен быть в 88-magos.xzm

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

#29

Наверное Вам лучше разобраться с mdialog и xuserrun. В наших скриптах много где используется. Помимо запуска zenity или kdialog зависимо от среды mdialog решает и еще одну проблему. Сообщения от рута в kdialog отправленные udev или например cron не будут работать, а с mdilaog - работают.

#30

xuserrun заработал но модуль в LXQt в zenity не создается
пишет

chmod: невозможно получить доступ к ‘PREFIX=NONKDE PREFIX=NONKDE 1 /memory/data/mounts/0/Linux/Mageia/optional/555.xzm’: Нет такого файла

Т е лишняя инфа в zenity при установке имени файла
Вроде то же самое и в Росе при запуске вашей сборки
И kdialog нормально работает на LXQt есть сообщение о выполнении операции gactivate
Задал строчкой

mod_name=$(kdialog --getsavefilename $file_save/$xzm_name.$MODULEFORMAT)

zenity похоже в Магее или старый (вроде мало опций) или наоборот самый новый
Осталось mdialog заставить в LXQt запускать kdialog
Здесь с путем все ок. Допустим

mod_name=/memory/layer-base/0/optional/66-XX.xzm

У zenity

mod_name=PREFIX=NONKDE PREFIX=NONKDE 1 /memory/data/mounts/0/Linux/Mageia/optional/555.xzm

#31

Да, можно так починить.

#32

rpmdrake2xzm
Обновленный вариант - https://cloud.mail.ru/public/2kvi/5zsmpQWHh

  1. Починил zenity на LXQt стр 109 - Это оказалось проще

mod_name=$(echo $mod_name | sed s/[.]$MODULEFORMAT$// | awk ‘{ print $2 }’)

Запуск rpmdrake2xzm только от user. Запуск от root оказалось запрещен в mdialog
В Магее работает. Даже как то скучно.
В МагОС обновился и после перезагрузки не смог открыть rpm-базу в rpmdrake
Но в своем chrootdisk (запуск от root) я МагОС обновил и открыл в rpmdrake rpm-базу
Вероятно запуск rpmdrake2xzm в Росе надо делать от root
Но учитывая что в Магее rpmdrake2xzm от user работает то больше уж ничего делать не буду
Непонятно что делать

  1. Запуск в chrootdisk rpmdrake в МагОС получился - /usr/bin/rpmdrake
    Но в rpmdrake2xzm есть другой запуск - rpmdrake - /usr/sbin/rpmdrake
    В rpmdrake2xzm и тот и другой работают
    В chrootdisk запустилдся только - /usr/bin/rpmdrake
    То же непонятки. Как в системе может быть два варианта запуска приложения ?
#33

Да запросто. Например из sbin запускается сразу, а из usr/bin перезапускает тот что в sbin только с kdesu/beesu. Просто предположение :slight_smile:

#34

Если закоментировать xuserrun то mdialog будет запускать kdialog и zenity при входе в систему как root
Похоже что xuserrun как раз и запрещает работу при входе в систему как root
Учитывая что сборку дистра и все настройки системы я делаю при входе в систему как root
То для меня это ограничение. Долгое время использовал только вход от root.
Если я закоментирую то будут ли какие нибудь неприятности ?
Если это лучше не делать то тогда просто перейду на kdialog

#35

Может просто xuserrun не работает. Попробуйте под рутом xuserrun whoami

#36

Работает

mageia ~ # xuserrun whoami
root
mageia ~ #

Видимо виноват mdialog

f [ “$(id -un)” = “root” ] ;then
xuserrun $0 “$@” ; exit
fi

Закоментировать эту блокировку и все работает под root

#37

не работает, xuserrun whoami должно вернуть имя текущего юзера пользователя иксов. Вы ж не под рутом иксы запускаете.

#38

Именно под root
Но под юзер вроде то же самое

live@mageia ~ $ xuserrun whoami
live
live@mageia ~ $

Вот в root-терминале от юзера

mageia ~ # xuserrun whoami
live
mageia ~ #

#39

xuserrun whoami запущенное под root, должно у вас вернуть live. Если возвращает root значит не работает.

#40
  1. Вход в систему от пользователя live
  1. Вход в систему от пользователя root