[devel] RFC: wayland session wrapper script

[devel] RFC: wayland session wrapper script

[Igor Vlasenko]

Уважаемые коллеги!

Как показал #40910
https://bugzilla.altlinux.org/40910
нам срочно нужен wayland session wrapper script.

Выношу на обсуждение, что туда хотелось бы запихнуть.

I/Часть один. Что хотелось бы иметь в таком скрипте.

1) Самый минимум такого скрипта - это

№!/bin/bash -login
# wayland session wrapper script.
exec "$@"

Этого минимума хватит, чтобы втянуть /etc/profile and /etc/profile.d
и закрыть #40910.
Но этого недостаточно по сравнению с нашей инфраструктурой над /etc/X11/Xsession.

Поэтому вот что еще хочу туда добавить:

2) обертки
SELINUX_WRAPPER=...
DBUS_WRAPPER=
# we already have user's dbus session or we are about to run it
[ -n "$DBUS_SESSION_BUS_ADDRESS" -o "$1" = "dbus-run-session" ] || DBUS_WRAPPER=dbus-run-session

exec $SELINUX_WRAPPER $DBUS_WRAPPER "$@"

DBUS_WRAPPER - для запуска на системах без systemd.

3) XDG_SESSION_TYPE.

принудительно устанавливать, если вдруг не установлен:
XDG_SESSION_TYPE=${XDG_SESSION_TYPE:-wayland}

То же самое, кстати, надо будет сделать и в /etc/X11/Xsession:
XDG_SESSION_TYPE=${XDG_SESSION_TYPE:-x11}

Это нужно для поддержки старых и кривых DM.

4) redirect stderr to a file

   Наверное, тоже надо.
   Куда-то, к примеру, в "$HOME/.local/share/wayland-session.log",
   имена предлагайте.

   Возможно, проверить сначала, что мы не запущены под GDM, sddm, ...
   которые сами делают stderr redirect
   и посмотреть в /proc/self/fd/2, это -f или -с

# redirect stderr to a file, if it is not yet redirected by DM
if [ ! -e /proc/self -o -c /proc/self/fd/2 ]; then
for errfile in "$HOME/.local/share/wayland-session.log"; do
	if install -m600 /dev/null "$errfile" 2>/dev/null; then
		exec &>"$errfile"
		break
	fi
done

4) <wayland>/profile.d.

Хоть мы уже втянули /etc/profile.d, но для
wayland session wrapper script нужен и свой отдельный

   <wayland>/profile.d

Смысл его существования в том, что ряд тулкитов и приложений
поддерживают wayland, но без волшебного понуждения в виде
магических переменных вида THIS_APP_PLEASE_DO_USE_WAYLAND=1
все равно по умолчанию запускаются под XWayland.
Такие костыли можно как раз в <wayland>/profile.d/ и сложить.

Кстати, проявилась тенденция переходить на использование
в качестве такого костыля
XDG_SESSION_TYPE=wayland
почему я и хочу форсить значение этой переменной в п.3.


5) <sessions>/profile.d.

Исторически сложилось, что у нас есть /etc/X11/profile.d
и в нем есть ряд скриптов.

Сейчас там 5 скриптов.

Из них только 1 X11 specific:
/etc/X11/profile.d/xapp-gtk3-module.sh

Остальные не совсем понятна логика, почему они в
/etc/X11/profile.d, а не просто в /etc/profile.d.

В случае
/etc/X11/profile.d/ssh-agent.sh
логика понятна, не хочется вызывать этот скрипт в
случае удаленного логина по ssh.
Но там вроде бы достаточно дополнительно проверить,
есть ли $SSH_CONNECTION, и с такой проверкой
можно смело переносить в /etc/profile.d
(поправьте, если не так, знающие люди!)

Что касается оставшихся скриптов
/etc/X11/profile.d/xdg-user-dirs.sh
/etc/X11/profile.d/zdg-user-dirs-install.sh
/etc/X11/profile.d/zdg-move-templates.sh
то мне не очень понятно, почему они не в /etc/profile.d.
(расскажите, знающие люди!)

Если их все же нельзя перенести в /etc/profile.d,
то придется дополнительно вводить каталог
<sessions>/profile.d,
Откуда будут читать и wayland-session,
и патченый /etc/X11/Xsession.

Если их можно перенести в /etc/profile.d, то перенести нужно,
и тогда они будут доступны и в wayland-session,
и в Xsession.

Также в /etc/X11/Xsession есть
TryXBrowser() and TryTextBrowser() stuff and
export BROWSER HELP_BROWSER

Этот кусок тоже логично выпилить и перенести в /etc/profile.d.

6. init.d
Для X есть /etc/X11/xinit.d.
Мне сначала показалось, что в 'wayland session wrapper script'
init.d не нужен. Напомню, что для xsession
DM __СНАЧАЛА__ запускает X, потом в запущенном X исполняется Xsession
и скрипты из xinit.d.

Для обертки wayland-session это не так. Во время его работы
wayland сервера еще нет и, возможно, никогда и не будет
(если, к примеру, запускается fbterm).
Поэтому иметь <wayland>/init.d бессмысленно.

Однако, анализ скриптов /etc/X11/xinit.d/ показал, что есть тема,
общая между Xsession, wayland compositor и fbterm, но не для
удаленного логина по ssh.

Это внесение пользовательских настроек в железо локальной машины,
на которой открывается сессия. Это может быть
* загрузка параметров alsa для не-pulse юзера,
* пользовательские настройки видеокарты
  #/etc/X11/xinit.d/nvidia-settings.sh     nvidia-settings
* пользовательские настройки для multiseat
  #/etc/X11/xinit.d/90-multiseat-*  setup-multiseat-*
и т. д.

Поэтому имеет смысл иметь <user-hardware>/init.d,
который запускать и из wayland-session, и из
/etc/X11/Xsession.

Прошу обсуждать, дополнять, критиковать.

P.S.

Про "II/Часть два. Что где в каком каталоге расположить и как назвать".

Специально не стал писать, так как сначала нужно определиться,
что нам нужно, а что, вроде <wayland>/init.d - нет.

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

-- 

I V

Re: [devel] RFC: wayland session wrapper script

[Alexey V. Vissarionov]

On 2021-12-02 20:35:23 +0200, Igor Vlasenko wrote:

 > Как показал #40910 https://bugzilla.altlinux.org/40910
 > нам срочно нужен wayland session wrapper script.
 > Выношу на обсуждение, что туда хотелось бы запихнуть.
 > I/Часть один. Что хотелось бы иметь в таком скрипте.
 > 1) Самый минимум такого скрипта - это
 > №!/bin/bash -login
 > # wayland session wrapper script.
 > exec "$@"
 > Этого минимума хватит, чтобы втянуть /etc/profile and
 > /etc/profile.d и закрыть #40910.

Очень прошу прямо в первой же строчке этого скрипта написать
что-то наподобие

test -x ~/.wayland-session && exec ~/.wayland-session $*

То есть, если у пользователя по данному вопросу есть свое
мнение - пусть делает так, как считает нужным.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] RFC: wayland session wrapper script

[Sergey V Turchin]

On Thursday, 2 December 2021 22:09:12 MSK Alexey V wrote:

[...]
> Очень прошу прямо в первой же строчке этого скрипта написать
> что-то наподобие
> 
> test -x ~/.wayland-session && exec ~/.wayland-session $*
> 
> То есть, если у пользователя по данному вопросу есть свое
> мнение - пусть делает так, как считает нужным.
По аналогии с ~/.xsession.d/ и .xinitrc надо что-то, получается.

-- 
Regards, Sergey.

Re: [devel] RFC: wayland session wrapper script

[Igor Vlasenko]

On Fri, Dec 03, 2021 at 10:30:29AM +0300, Sergey V Turchin wrote:

> По аналогии с ~/.xsession.d/ и .xinitrc надо что-то, получается.

Это некорректная аналогия.

Напомню, что это 'wayland session wrapper script', т.е.
скрипт-обертка, который запускается DM-ом (lightdm, sddm) для запуска
программы из /usr/share/wayland-sessions/some.desktop.

Этот скрипт-обертка выполняется _до_ возможного запуска wayland
композитора, и вполне возможно, запускает нечто с wayland совсем
не связанное, как fbterm.

Слово wayland там из wayland-sessions из /usr/share/wayland-sessions/,
не из сеанса Wayland!

Не надо путать его с гипотетическими скриптами
.wayland-session ~/.wayland-session.d/ и .wayland-initrc,
полученными по аналогии s/x/wayland-/ из
.xsession ~/.xsession.d/ и .xinitrc

В Wayland нет разделения на сервер, WM и композитор.
.xsession и .xinitrc были нужны для X, поскольку для X такое
разделение есть, и скрипты xsession появились и были нужны,
чтобы дособрать к X серверу рабочий сеанс X из кусочков.

Логика .wayland-session и .wayland-initrc аналогична, дособрать
рабочий сеанс Wayland из кусочков. По этой логике такие скрипты
должны запускаться после старта Wayland.
Но опять повторю, в Wayland нет разделения на сервер, WM и композитор.
Поэтому такие скрипты должен был бы запускать сервер-композитор
Wayland __ПОСЛЕ__ своего старта.

Но существующие композиторы Wayland так не делают.
Вместо стандартной единой для всех у каждого из них есть своя система
и конфигурации, и постнастройки.

Если есть желание иметь .wayland-session и .wayland-initrc
как стандартный способ что-то сделать пользователем, надо сначала
такой стандарт создать.

Надо писать RFC предлагаемого стандарта, продвигать его в wayland.freedesktop.org
и патчить имеющиеся композиторы Wayland, начиная с plasma,
чтобы .wayland-session и .wayland-initrc заработал.

И эти имена ~/.wayland-session и ~/.wayland-initrc лучше не трогать и
не использовать, вдруг такой стандарт действительно появится.


-- 

I V

Re: [devel] RFC: wayland session wrapper script

[Igor Vlasenko]

On Thu, Dec 02, 2021 at 10:09:12PM +0300, Alexey V. Vissarionov wrote:
> test -x ~/.wayland-session && exec ~/.wayland-session $*
добавил
# let user deifine his own wrapper
test -x ~/.wayland-sessions-wrapper && exec ~/.wayland-sessions-wrapper "$@"

-- 

I V

Re: [devel] RFC: wayland session wrapper script

[Alexey V. Vissarionov]

On 2021-12-03 12:59:01 +0200, Igor Vlasenko wrote:

 >> test -x ~/.wayland-session && exec ~/.wayland-session $*
 > добавил
 > # let user deifine his own wrapper

# allow users to create their own session wrappers

 > test -x ~/.wayland-sessions-wrapper && exec
 > ~/.wayland-sessions-wrapper "$@"

Отлично!


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] RFC: wayland session wrapper script

[Dmitry V. Levin]

On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
[...]
> Остальные не совсем понятна логика, почему они в
> /etc/X11/profile.d, а не просто в /etc/profile.d.
> 
> В случае
> /etc/X11/profile.d/ssh-agent.sh
> логика понятна, не хочется вызывать этот скрипт в
> случае удаленного логина по ssh.

Не только в этом случае, но в случае любого другого логина, кроме такого,
когда ssh-agent сможет асинхронно запрашивать подтверждения у пользователя.
Например, логин на tty1 тоже не подходит.
Проверка на $DISPLAY в самом начале /etc/X11/Xsession не просто так.

Можно попробовать такой вариант:

[ -n "${SSH_AUTH_SOCK-}" ] ||
[ -z "${DISPLAY-}" ] ||
tty -s || {
	...
}


-- 
ldv

Re: [devel] RFC: wayland session wrapper script

[Igor Vlasenko]

On Fri, Dec 03, 2021 at 03:12:46PM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
> [...]
> > Остальные не совсем понятна логика, почему они в
> > /etc/X11/profile.d, а не просто в /etc/profile.d.
> > 
> > В случае
> > /etc/X11/profile.d/ssh-agent.sh
> > логика понятна, не хочется вызывать этот скрипт в
> > случае удаленного логина по ssh.
> 
> Не только в этом случае, но в случае любого другого логина, кроме такого,
> когда ssh-agent сможет асинхронно запрашивать подтверждения у пользователя.
> Например, логин на tty1 тоже не подходит.
> Проверка на $DISPLAY в самом начале /etc/X11/Xsession не просто так.

Спасибо за разъяснение. Тогда получается следующее:

1) /etc/X11/profile.d/ssh-agent.sh нельзя перемещать в /etc/profile.d/
пусть будет там, где былю

2) нельзя просто добавить симлинк в 
<wayland session wrapper script>/profile.d
так как из /usr/share/wayland-sessions может быть запушен
тот же fbterm.

Можно добавить эвристику, которая будет смотреть,
что запускается, и для известных композиторов
явно вызывать
/etc/X11/profile.d/ssh-agent.sh


> Можно попробовать такой вариант:
> [ -n "${SSH_AUTH_SOCK-}" ] ||
> [ -z "${DISPLAY-}" ] ||
> tty -s || {
> 	...

Для обсуждаемого скрипта не cгодится, так как Wayland еще
не запущен, следовательно, WAYLAND_DISPLAY, XWayland и DISPLAY тоже нет

Пусть для /etc/X11/profile.d/ssh-agent.sh будет все как есть


-- 

I V

Re: [devel] почему ssh-agent не имеет смысла на tty1

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

On Fri, Dec 03, 2021 at 03:12:46PM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
> [...]
> > Остальные не совсем понятна логика, почему они в
> > /etc/X11/profile.d, а не просто в /etc/profile.d.
> > 
> > В случае
> > /etc/X11/profile.d/ssh-agent.sh
> > логика понятна, не хочется вызывать этот скрипт в
> > случае удаленного логина по ssh.
> 
> Не только в этом случае, но в случае любого другого логина, кроме такого,
> когда ssh-agent сможет асинхронно запрашивать подтверждения у пользователя.
> Например, логин на tty1 тоже не подходит.

...Как и на любом VT? Почему же?
Чем плохо прямо на том же терминале спрашивать? Или есть TUI-приложения,
вызывающие ssh, при работе с которыми такая наглость от ssh-agent
сломает интерфейс?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] почему ssh-agent не имеет смысла на tty1

[Dmitry V. Levin]

On Fri, Dec 03, 2021 at 07:07:57PM +0300, Arseny Maslennikov wrote:
> On Fri, Dec 03, 2021 at 03:12:46PM +0300, Dmitry V. Levin wrote:
> > On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
> > [...]
> > > Остальные не совсем понятна логика, почему они в
> > > /etc/X11/profile.d, а не просто в /etc/profile.d.
> > > 
> > > В случае
> > > /etc/X11/profile.d/ssh-agent.sh
> > > логика понятна, не хочется вызывать этот скрипт в
> > > случае удаленного логина по ssh.
> > 
> > Не только в этом случае, но в случае любого другого логина, кроме такого,
> > когда ssh-agent сможет асинхронно запрашивать подтверждения у пользователя.
> > Например, логин на tty1 тоже не подходит.
> 
> ...Как и на любом VT? Почему же?
> Чем плохо прямо на том же терминале спрашивать? Или есть TUI-приложения,
> вызывающие ssh, при работе с которыми такая наглость от ssh-agent
> сломает интерфейс?

Поскольку ssh-agent и всё, что он запустит, будет в фоне, a при попытке
спросить с терминала этому фоновому процессу просто пришлют сигнал.


-- 
ldv

Re: [devel] RFC: wayland session wrapper script

[Alexey Gladkov]

On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
> Уважаемые коллеги!
> 
> Как показал #40910
> https://bugzilla.altlinux.org/40910
> нам срочно нужен wayland session wrapper script.

Спасибо, что начал двигать эту тему. Это я как человек сидящий на
wayland-only окружении говорю.

> В случае
> /etc/X11/profile.d/ssh-agent.sh
> логика понятна, не хочется вызывать этот скрипт в
> случае удаленного логина по ssh.
> Но там вроде бы достаточно дополнительно проверить,
> есть ли $SSH_CONNECTION, и с такой проверкой
> можно смело переносить в /etc/profile.d
> (поправьте, если не так, знающие люди!)

Если кому-нибудь нужно у меня есть pinentry для gpg-agent под x11/wayland.
НО без привязки к gnome.


-- 
Rgrds, legion

Re: [devel] RFC: wayland session wrapper script

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Gladkov <legion-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
 >> Уважаемые коллеги!
 >> 
 >> Как показал #40910
 >> https://bugzilla.altlinux.org/40910
 >> нам срочно нужен wayland session wrapper script.

 > Спасибо, что начал двигать эту тему. Это я как человек сидящий на
 > wayland-only окружении говорю.

+1 к спасибо, назрело и перезрело.
legion: кстати, как ты этот свой sway запускаешь wayland-only,
неужто c exec sway c tty ? asking for a friend

 >> В случае
 >> /etc/X11/profile.d/ssh-agent.sh
 >> логика понятна, не хочется вызывать этот скрипт в
 >> случае удаленного логина по ssh.
 >> Но там вроде бы достаточно дополнительно проверить,
 >> есть ли $SSH_CONNECTION, и с такой проверкой
 >> можно смело переносить в /etc/profile.d
 >> (поправьте, если не так, знающие люди!)

 > Если кому-нибудь нужно у меня есть pinentry для gpg-agent под x11/wayland.
 > НО без привязки к gnome.


 > -- 
 > Rgrds, legion

 > _______________________________________________
 > Devel mailing list
 > Devel@lists.altlinux.org
 > https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] RFC: wayland session wrapper script

[Alexey Gladkov]

On Fri, Dec 03, 2021 at 05:49:31PM +0300, Sergey Bolshakov wrote:
> >>>>> "Alexey" == Alexey Gladkov <legion-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
> 
>  > On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
>  >> Уважаемые коллеги!
>  >> 
>  >> Как показал #40910
>  >> https://bugzilla.altlinux.org/40910
>  >> нам срочно нужен wayland session wrapper script.
> 
>  > Спасибо, что начал двигать эту тему. Это я как человек сидящий на
>  > wayland-only окружении говорю.
> 
> +1 к спасибо, назрело и перезрело.
> legion: кстати, как ты этот свой sway запускаешь wayland-only,
> неужто c exec sway c tty ? asking for a friend

Именно так и запускаю. Я пробовал разные DM, но не срослось. Собирать
что-то от фанатов [1] тоже не стал так как это +1 DM (из и так развелось)
и плюс его вычитывать же нужно. Я так и не собрался.

В остальном системный конфиг sway почти такой же как мой. В моём из
важного разве что используется waybar, запускается mako и swaykbdd.

[1] https://git.sr.ht/~kennylevinsen/greetd

-- 
Rgrds, legion

Re: [devel] DM (RFC: wayland session wrapper script)

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 3333 bytes --]

On Fri, Dec 03, 2021 at 04:10:04PM +0100, Alexey Gladkov wrote:
> On Fri, Dec 03, 2021 at 05:49:31PM +0300, Sergey Bolshakov wrote:
> > >>>>> "Alexey" == Alexey Gladkov <legion-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
> > 
> >  > On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
> >  >> Уважаемые коллеги!
> >  >> 
> >  >> Как показал #40910
> >  >> https://bugzilla.altlinux.org/40910
> >  >> нам срочно нужен wayland session wrapper script.
> > 
> >  > Спасибо, что начал двигать эту тему. Это я как человек сидящий на
> >  > wayland-only окружении говорю.
> > 
> > +1 к спасибо, назрело и перезрело.
> > legion: кстати, как ты этот свой sway запускаешь wayland-only,
> > неужто c exec sway c tty ? asking for a friend
> 
> Именно так и запускаю. Я пробовал разные DM, но не срослось. Собирать
> что-то от фанатов [1] тоже не стал так как это +1 DM (из и так развелось)

Вот потому и развелось, что никто не пытался общую привилегированную
часть написать один раз, секурно и хорошо, а вендорам DE и администраторам
оставить писать greeters — и убедить их всех, включая гномеров, так
делать.

> и плюс его вычитывать же нужно. Я так и не собрался.
> 
> В остальном системный конфиг sway почти такой же как мой. В моём из
> важного разве что используется waybar, запускается mako и swaykbdd.
> 
> [1] https://git.sr.ht/~kennylevinsen/greetd

Он собран в сизиф.

Я его читал средне-вдумчиво, там немного кода, он выглядит почти
хорошим, в т. ч. архитектурно. Разве только:
(1) написан на Rust с std и обильным cargo, список модулей на пару экранов не влезает :(
(2) автору совсем не пришло в голову, что запускать гритеры лучше из
    инит-скриптов / строчек в inittab / autovt@.service (зачем заново
    писать startup manager?);
(3) он, запускаясь на VT X, _сначала_ вызывает ioctl(*, KDSETMODE, KD_TEXT),
    а _потом_ спрашивает у гритера, какой режим VT ему нужен;
(4) он, кажется, не решает проблему "если DM крашнулся, сеансы убиваются
    вслед"; (один из путей решения — пункт 2)
(5) ну и XDG compliance у него не реализован, кажется, ничем: нет в
    комплекте лончера, который бы все эти переменные ставил (т. е.
    потребуются костыли, о которых пишет Игорь viy@).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] DM (RFC: wayland session wrapper script)

[Alexey Gladkov]

On Fri, Dec 03, 2021 at 07:05:12PM +0300, Arseny Maslennikov wrote:
> On Fri, Dec 03, 2021 at 04:10:04PM +0100, Alexey Gladkov wrote:
> > On Fri, Dec 03, 2021 at 05:49:31PM +0300, Sergey Bolshakov wrote:
> > > >>>>> "Alexey" == Alexey Gladkov <legion-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
> > > 
> > >  > On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
> > >  >> Уважаемые коллеги!
> > >  >> 
> > >  >> Как показал #40910
> > >  >> https://bugzilla.altlinux.org/40910
> > >  >> нам срочно нужен wayland session wrapper script.
> > > 
> > >  > Спасибо, что начал двигать эту тему. Это я как человек сидящий на
> > >  > wayland-only окружении говорю.
> > > 
> > > +1 к спасибо, назрело и перезрело.
> > > legion: кстати, как ты этот свой sway запускаешь wayland-only,
> > > неужто c exec sway c tty ? asking for a friend
> > 
> > Именно так и запускаю. Я пробовал разные DM, но не срослось. Собирать
> > что-то от фанатов [1] тоже не стал так как это +1 DM (из и так развелось)
> 
> Вот потому и развелось, что никто не пытался общую привилегированную
> часть написать один раз, секурно и хорошо, а вендорам DE и администраторам
> оставить писать greeters — и убедить их всех, включая гномеров, так
> делать.
> 
> > и плюс его вычитывать же нужно. Я так и не собрался.
> > 
> > В остальном системный конфиг sway почти такой же как мой. В моём из
> > важного разве что используется waybar, запускается mako и swaykbdd.
> > 
> > [1] https://git.sr.ht/~kennylevinsen/greetd
> 
> Он собран в сизиф.

О. Уже. Я не заметил :)

> 
> Я его читал средне-вдумчиво, там немного кода, он выглядит почти
> хорошим, в т. ч. архитектурно. Разве только:
> (1) написан на Rust с std и обильным cargo, список модулей на пару экранов не влезает :(

Да. Где-то автор писал, что он заинтересовался rust :)

> (2) автору совсем не пришло в голову, что запускать гритеры лучше из
>     инит-скриптов / строчек в inittab / autovt@.service (зачем заново
>     писать startup manager?);

Потому что он как и я не использует systemd ? На это намекает то, что он
же является автором seatd :)

> (3) он, запускаясь на VT X, _сначала_ вызывает ioctl(*, KDSETMODE, KD_TEXT),
>     а _потом_ спрашивает у гритера, какой режим VT ему нужен;

Послали ему исправление ?

> (4) он, кажется, не решает проблему "если DM крашнулся, сеансы убиваются
>     вслед"; (один из путей решения — пункт 2)

Для меня это не вариант решения. Для автора, кажется, тоже.

> (5) ну и XDG compliance у него не реализован, кажется, ничем: нет в
>     комплекте лончера, который бы все эти переменные ставил (т. е.
>     потребуются костыли, о которых пишет Игорь viy@).

Я их себе сам выставляю их. Не вижу в этом проблемы. Мне кажется это не
дело DM.

-- 
Rgrds, legion

Re: [devel] DM (was: RFC: wayland session wrapper script)

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 4386 bytes --]

On Fri, Dec 03, 2021 at 07:05:01PM +0100, Alexey Gladkov wrote:
> On Fri, Dec 03, 2021 at 07:05:12PM +0300, Arseny Maslennikov wrote:
> > (2) автору совсем не пришло в голову, что запускать гритеры лучше из
> >     инит-скриптов / строчек в inittab / autovt@.service (зачем заново
> >     писать startup manager?);
> 
> Потому что он как и я не использует systemd ? На это намекает то, что он
> же является автором seatd :)

Я же не зря _сначала_ написал "инит-скриптов / строчек в inittab". Для
этого же совсем не обязателен systemd и его logind.

В сизифе есть пакет kmscon, который можно запустить так:
  /usr/bin/kmscon --vt=tty5 --seats=seat0 --no-switchvt --login -- /sbin/agetty -o '-p -- \\u' --noclear -- -

Судя по https://tldp.org/LDP/sag/html/config-init.html, команду выше или
скрипт с ней можно положить в четвёртое поле записи inittab, разве нет?

> > (3) он, запускаясь на VT X, _сначала_ вызывает ioctl(*, KDSETMODE, KD_TEXT),
> >     а _потом_ спрашивает у гритера, какой режим VT ему нужен;
> 
> Послали ему исправление ?

Надо ещё разбираться подробнее, но не до того пока.

% grep -nC5 compatibility greetd/src/session/worker.rs
140-            pam.putenv(&format!("XDG_VTNR={}", vt))?;
141-
142-            // Opening our target terminal.
143-            let target_term = terminal::Terminal::open(&path)?;
144-
145:            // Set the target VT mode to text for compatibility. Other login managers
146-            // set this to graphics, but that disallows start of textual applications,
147-            // which greetd aims to support.
148-            target_term.kd_setmode(terminal::KdMode::Text)?;
149-
150-            // Clear TTY so that it will be empty when we switch to it.

Как я понимаю, это не столько исправление, сколько улучшение — оно
потребует изменения протокола greetd-ipc: сначала стартует гритер,
декларирует требования (например, что он текстовый и хочет пользоваться
VT в текстовом режиме), потом происходит уже настройка и выдача VT и
ответ гритеру, что получилось, потом последний открывает VT и начинает работу.

> > (4) он, кажется, не решает проблему "если DM крашнулся, сеансы убиваются
> >     вслед"; (один из путей решения — пункт 2)
> 
> Для меня это не вариант решения. Для автора, кажется, тоже.

Ну почему же: greeter или пользовательский сеанс на VT X порождается условным
/usr/sbin/dm --vt=ttyX в процессе-потомке со сброшенными привилегиями,
он же задействует PAM-стек. Если общий деймон необходим для выполнения
каких-то ещё привилегированных операций, с ним можно по сокету общаться.

Наверное, здесь сказано много слов и мало кода...

> 
> > (5) ну и XDG compliance у него не реализован, кажется, ничем: нет в
> >     комплекте лончера, который бы все эти переменные ставил (т. е.
> >     потребуются костыли, о которых пишет Игорь viy@).
> 
> Я их себе сам выставляю их. Не вижу в этом проблемы. Мне кажется это не
> дело DM.

Да, это дело соотв. прослойки, которую можно и не использовать.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] DM (was: RFC: wayland session wrapper script)

[Alexey Gladkov]

On Fri, Dec 03, 2021 at 10:59:43PM +0300, Arseny Maslennikov wrote:
> On Fri, Dec 03, 2021 at 07:05:01PM +0100, Alexey Gladkov wrote:
> > On Fri, Dec 03, 2021 at 07:05:12PM +0300, Arseny Maslennikov wrote:
> > > (2) автору совсем не пришло в голову, что запускать гритеры лучше из
> > >     инит-скриптов / строчек в inittab / autovt@.service (зачем заново
> > >     писать startup manager?);
> > 
> > Потому что он как и я не использует systemd ? На это намекает то, что он
> > же является автором seatd :)
> 
> Я же не зря _сначала_ написал "инит-скриптов / строчек в inittab". Для
> этого же совсем не обязателен systemd и его logind.
> 
> В сизифе есть пакет kmscon, который можно запустить так:
>   /usr/bin/kmscon --vt=tty5 --seats=seat0 --no-switchvt --login -- /sbin/agetty -o '-p -- \\u' --noclear -- -

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

> > > (4) он, кажется, не решает проблему "если DM крашнулся, сеансы убиваются
> > >     вслед"; (один из путей решения — пункт 2)
> > 
> > Для меня это не вариант решения. Для автора, кажется, тоже.
> 
> Ну почему же: greeter или пользовательский сеанс на VT X порождается условным
> /usr/sbin/dm --vt=ttyX в процессе-потомке со сброшенными привилегиями,
> он же задействует PAM-стек. Если общий деймон необходим для выполнения
> каких-то ещё привилегированных операций, с ним можно по сокету общаться.
> 
> Наверное, здесь сказано много слов и мало кода...

Скорее всего да )))

Кстати, такая же проблема со всеми остальными dm. Там же тоже стартует
процесс от которого зависит сеанс. Разве нет ?

-- 
Rgrds, legion

Re: [devel] RFC: wayland session wrapper script

[Alexey Gladkov]

On Fri, Dec 03, 2021 at 04:10:04PM +0100, Alexey Gladkov wrote:
> >  > Спасибо, что начал двигать эту тему. Это я как человек сидящий на
> >  > wayland-only окружении говорю.
> > 
> > +1 к спасибо, назрело и перезрело.
> > legion: кстати, как ты этот свой sway запускаешь wayland-only,
> > неужто c exec sway c tty ? asking for a friend
> 
> Именно так и запускаю. Я пробовал разные DM, но не срослось. Собирать
> что-то от фанатов [1] тоже не стал так как это +1 DM (из и так развелось)
> и плюс его вычитывать же нужно. Я так и не собрался.
> 
> В остальном системный конфиг sway почти такой же как мой. В моём из
> важного разве что используется waybar, запускается mako и swaykbdd.
> 
> [1] https://git.sr.ht/~kennylevinsen/greetd

Для истории хочу приложить несколько ссылок:

https://github.com/solarkraft/awesome-wlroots
https://github.com/natpen/awesome-wayland

Думаю стоит ли собрать wofi:

https://hg.sr.ht/~scoopta/wofi

-- 
Rgrds, legion

Re: [devel] RFC: wayland session wrapper script

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

On Fri, Dec 03, 2021 at 02:50:57PM +0100, Alexey Gladkov wrote:
> On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
> > Уважаемые коллеги!
> > 
> > Как показал #40910
> > https://bugzilla.altlinux.org/40910
> > нам срочно нужен wayland session wrapper script.
> 
> Спасибо, что начал двигать эту тему. Это я как человек сидящий на
> wayland-only окружении говорю.

Вообще без xwayland?

> 
> > В случае
> > /etc/X11/profile.d/ssh-agent.sh
> > логика понятна, не хочется вызывать этот скрипт в
> > случае удаленного логина по ssh.
> > Но там вроде бы достаточно дополнительно проверить,
> > есть ли $SSH_CONNECTION, и с такой проверкой
> > можно смело переносить в /etc/profile.d
> > (поправьте, если не так, знающие люди!)
> 
> Если кому-нибудь нужно у меня есть pinentry для gpg-agent под x11/wayland.
> НО без привязки к gnome.

Нужно, конечно!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] RFC: wayland session wrapper script

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 10290 bytes --]

On Thu, Dec 02, 2021 at 08:35:23PM +0200, Igor Vlasenko wrote:
> Уважаемые коллеги!
> 
> Как показал #40910
> https://bugzilla.altlinux.org/40910
> нам срочно нужен wayland session wrapper script.
> 
> Выношу на обсуждение, что туда хотелось бы запихнуть.
> 
> I/Часть один. Что хотелось бы иметь в таком скрипте.
> 
> 1) Самый минимум такого скрипта - это
> 
> №!/bin/bash -login
Nitpick: наверное, `--login'?
> # wayland session wrapper script.
> exec "$@"
> 
> Этого минимума хватит, чтобы втянуть /etc/profile and /etc/profile.d
> и закрыть #40910.

Не знаю, оффтоп или нет, но сейчас нет чёткого понимания, какова задача,
стоящая перед /etc/profile{,.d}.
Предназначены ли эти файлы только для установки переменных окружения или
ещё и для произвольного кода?
Если второе, то: каким интерпретатором они исполняются? Если
логин-шеллом пользователя, т. е. "от балды", то это вряд ли хорошо.

Obligatory picture:
https://t.me/PAAMAYIM_NEKUDOTAYIM/30

> Но этого недостаточно по сравнению с нашей инфраструктурой над /etc/X11/Xsession.
> 
> Поэтому вот что еще хочу туда добавить:
> 
> 2) обёртки

> 3) XDG_SESSION_TYPE.

> 4) redirect stderr to a file

На systemd нужна возможность направить это в журнал, а не в файл.
Она особенно полезна в случае, когда хомяк в системе медленный и
маленький, а /var быстрее и больше, да и проворачивается (logrotate) он
самостоятельно.

> 
>    Наверное, тоже надо.
>    Куда-то, к примеру, в "$HOME/.local/share/wayland-session.log",
>    имена предлагайте.
> 
>    Возможно, проверить сначала, что мы не запущены под GDM, sddm, ...
Не возможно, а точно. :)
>    которые сами делают stderr redirect
>    и посмотреть в /proc/self/fd/2, это -f или -с
> 
> # redirect stderr to a file, if it is not yet redirected by DM
> if [ ! -e /proc/self -o -c /proc/self/fd/2 ]; then
> for errfile in "$HOME/.local/share/wayland-session.log"; do
> 	if install -m600 /dev/null "$errfile" 2>/dev/null; then
> 		exec &>"$errfile"
> 		break
> 	fi
> done
> 
> 4) <wayland>/profile.d.
> 
> Хоть мы уже втянули /etc/profile.d, но для
> wayland session wrapper script нужен и свой отдельный
> 
>    <wayland>/profile.d
> 
> Смысл его существования в том, что ряд тулкитов и приложений
> поддерживают wayland, но без волшебного понуждения в виде
> магических переменных вида THIS_APP_PLEASE_DO_USE_WAYLAND=1
> все равно по умолчанию запускаются под XWayland.

Кроме известных и популярных исключений, лучше не надо такое выставлять,
особенно в стабильных конфигурациях и дистрибутивах. Когда разработчики
приложений начинают полагать, что под wayland их продукт работает хорошо
(лучше, чем с Xorg/Xwayland), они убирают необходимость прописывать
такие переменные. Если такая переменная нужна — значит, апстрим не
уверен в себе, а мы и подавно — но усер может захотеть сам такую
переменную выставить.

> Такие костыли можно как раз в <wayland>/profile.d/ и сложить.
> 
> Кстати, проявилась тенденция переходить на использование
> в качестве такого костыля
> XDG_SESSION_TYPE=wayland
> почему я и хочу форсить значение этой переменной в п.3.
> 
> 
> 5) <sessions>/profile.d.
> 
> Исторически сложилось, что у нас есть /etc/X11/profile.d
> и в нем есть ряд скриптов.
> 
> Сейчас там 5 скриптов.
> 
> Из них только 1 X11 specific:
> /etc/X11/profile.d/xapp-gtk3-module.sh
> 
> Остальные не совсем понятна логика, почему они в
> /etc/X11/profile.d, а не просто в /etc/profile.d.

Потому что просто profile.d рассчитан на срабатывание ещё и в текстовых
сеансах, в т. ч. удалённых?

> 
> В случае
> /etc/X11/profile.d/ssh-agent.sh

С одной стороны, его запускать на systemd не надо, потому что есть user
unit (иными словами, предусмотреть там проверку, как вы предложили
выше). С другой, как заставить этот user unit работать только при
наличии локальных сеансов, не патча systemd --user?

> логика понятна, не хочется вызывать этот скрипт в
> случае удаленного логина по ssh.
> Но там вроде бы достаточно дополнительно проверить,
> есть ли $SSH_CONNECTION, и с такой проверкой
> можно смело переносить в /etc/profile.d
> (поправьте, если не так, знающие люди!)
> 
> Что касается оставшихся скриптов
> /etc/X11/profile.d/xdg-user-dirs.sh
> /etc/X11/profile.d/zdg-user-dirs-install.sh
> /etc/X11/profile.d/zdg-move-templates.sh
> то мне не очень понятно, почему они не в /etc/profile.d.
> (расскажите, знающие люди!)
> 
> Если их все же нельзя перенести в /etc/profile.d,
> то придется дополнительно вводить каталог
> <sessions>/profile.d,
> Откуда будут читать и wayland-session,
> и патченый /etc/X11/Xsession.

Здесь и в иных местах: не лучше ли <sessions>/profile.d и иные
нововводимые каталоги, в которые пакеты будут класть файлы, помещать
вне /etc, например, в /usr/share (и соотв. за-.-ить их)? /etc же для
администратора.

> Если их можно перенести в /etc/profile.d, то перенести нужно,
> и тогда они будут доступны и в wayland-session,
> и в Xsession.
> 
> Также в /etc/X11/Xsession есть
> TryXBrowser() and TryTextBrowser() stuff and
> export BROWSER HELP_BROWSER
> 
> Этот кусок тоже логично выпилить и перенести в /etc/profile.d.
> 
> 6. init.d
> Для X есть /etc/X11/xinit.d.
> Мне сначала показалось, что в 'wayland session wrapper script'
> init.d не нужен. Напомню, что для xsession
> DM __СНАЧАЛА__ запускает X, потом в запущенном X исполняется Xsession
> и скрипты из xinit.d.
> 
> Для обертки wayland-session это не так. Во время его работы
> wayland сервера еще нет и, возможно, никогда и не будет
> (если, к примеру, запускается fbterm).

Если wayland-сервера никогда не будет, то тогда это не wayland-session,
а нечто другое... И обёртка там нужна своя, аналогичная, но без
X11-specific и wayland-specific действий.

> Поэтому иметь <wayland>/init.d бессмысленно.
> 
> Однако, анализ скриптов /etc/X11/xinit.d/ показал, что есть тема,
> общая между Xsession, wayland compositor и fbterm, но не для
> удаленного логина по ssh.
> 
> Это внесение пользовательских настроек в железо локальной машины,
> на которой открывается сессия. Это может быть
> * загрузка параметров alsa для не-pulse юзера,
> * пользовательские настройки видеокарты
>   #/etc/X11/xinit.d/nvidia-settings.sh     nvidia-settings
> * пользовательские настройки для multiseat
>   #/etc/X11/xinit.d/90-multiseat-*  setup-multiseat-*
> и т. д.
> 
> Поэтому имеет смысл иметь <user-hardware>/init.d,
> который запускать и из wayland-session, и из
> /etc/X11/Xsession.
> 
> Прошу обсуждать, дополнять, критиковать.
> 
> P.S.
> 
> Про "II/Часть два. Что где в каком каталоге расположить и как назвать".
> 
> Специально не стал писать, так как сначала нужно определиться,
> что нам нужно, а что, вроде <wayland>/init.d - нет.
> 
> В зависимости от итога, можно будет сделать структуру каталогов проще
> или потребуется усложнять.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] RFC: wayland session wrapper script

[Igor Vlasenko]

On Fri, Dec 03, 2021 at 06:14:41PM +0300, Arseny Maslennikov wrote:
> > №!/bin/bash -login
> Nitpick: наверное, `--login'?

Да, спасибо. Пришло по наследству от /etc/X11/Xsession.
там тоже надо поправить.

> Не знаю, оффтоп или нет, но сейчас нет чёткого понимания, какова задача,
> стоящая перед /etc/profile{,.d}.
> Предназначены ли эти файлы только для установки переменных окружения или
> ещё и для произвольного кода?
> Если второе, то: каким интерпретатором они исполняются? Если
> логин-шеллом пользователя, т. е. "от балды", то это вряд ли хорошо.

Сейчас 'только для установки переменных окружения' предлагается
   pam_env /etc/environment
 и systemd /etc/environment.d
 pam_env(8) environment(5) environment.d(5)
/etc/environment неудобный, /etc/environment.d
удобный, но только под systemd.

Эх. если бы допилить pam_env, чтобы читал и /etc/environment.d,
можно бы было переезжать основной частью /etc/profile{,.d} ...

 
> > Поэтому вот что еще хочу туда добавить:
> > 
> > 2) обёртки
> 
> > 3) XDG_SESSION_TYPE.
> 
> > 4) redirect stderr to a file
> 
> На systemd нужна возможность направить это в журнал, а не в файл.
> Она особенно полезна в случае, когда хомяк в системе медленный и
> маленький, а /var быстрее и больше, да и проворачивается (logrotate) он
> самостоятельно.

Перенаправлением stderr сейчас занимается DM. Это к его конфигам.
а я сделал подстраховку, если -c /proc/self/fd/2
то скрипт шевелится перенаправлять.
 
> >    Возможно, проверить сначала, что мы не запущены под GDM, sddm, ...
> Не возможно, а точно. :)

Видел где-то какие-то волшебные переменные, которые говорят,
что мы из-под GDM.
Нигде не найду, как понадобились :(

> > Смысл его существования в том, что ряд тулкитов и приложений
> > поддерживают wayland, но без волшебного понуждения в виде
> > магических переменных вида THIS_APP_PLEASE_DO_USE_WAYLAND=1
> > все равно по умолчанию запускаются под XWayland.
> 
> Кроме известных и популярных исключений, лучше не надо такое выставлять,
> особенно в стабильных конфигурациях и дистрибутивах. Когда разработчики
> приложений начинают полагать, что под wayland их продукт работает хорошо
> (лучше, чем с Xorg/Xwayland), они убирают необходимость прописывать
> такие переменные. Если такая переменная нужна — значит, апстрим не
> уверен в себе, а мы и подавно — но усер может захотеть сам такую
> переменную выставить.

Да.
 
> Потому что просто profile.d рассчитан на срабатывание ещё и в текстовых
> сеансах, в т. ч. удалённых?

Гм. к примеру xdg-user-dirs.sh. Если пользователь
залогинился с консоли, почему бы не выполнить xdg-user-dirs.sh?

Если бережемся удалённые грузить (что правильно),
надо просто добавить проверку на $SSH_CONNECTION.
 
> > /etc/X11/profile.d/ssh-agent.sh
> 
> С одной стороны, его запускать на systemd не надо, потому что есть user
> unit (иными словами, предусмотреть там проверку, как вы предложили
> выше). С другой, как заставить этот user unit работать только при
> наличии локальных сеансов, не патча systemd --user?

Я пока вручную перебираю сессии, и отсеиваю framebuffer'ные.
а для остальных запускаю /etc/X11/profile.d/ssh-agent.sh
 
> > логика понятна, не хочется вызывать этот скрипт в
> > случае удаленного логина по ssh.
> > Но там вроде бы достаточно дополнительно проверить,
> > есть ли $SSH_CONNECTION, и с такой проверкой
> > можно смело переносить в /etc/profile.d
> > (поправьте, если не так, знающие люди!)
> > 
> > Что касается оставшихся скриптов
> > /etc/X11/profile.d/xdg-user-dirs.sh
> > /etc/X11/profile.d/zdg-user-dirs-install.sh
> > /etc/X11/profile.d/zdg-move-templates.sh
> > то мне не очень понятно, почему они не в /etc/profile.d.
> > (расскажите, знающие люди!)
> > 
> > Если их все же нельзя перенести в /etc/profile.d,
> > то придется дополнительно вводить каталог
> > <sessions>/profile.d,
> > Откуда будут читать и wayland-session,
> > и патченый /etc/X11/Xsession.
> 
> Здесь и в иных местах: не лучше ли <sessions>/profile.d и иные
> нововводимые каталоги, в которые пакеты будут класть файлы, помещать
> вне /etc, например, в /usr/share (и соотв. за-.-ить их)? /etc же для
> администратора.

Да, было бы хорошо. Но куда?
В SuSE видел, к примеру, usr/etc. Насколько это FHS?

> Если wayland-сервера никогда не будет, то тогда это не wayland-session,
> а нечто другое... И обёртка там нужна своя, аналогичная, но без
> X11-specific и wayland-specific действий.

я добавил это списком исключений (fbcon/fbterm)
и установкой для них XDG_SESSION_TYPE=tty

А для запуска чего-то уже когда сервер есть,
нужно пользоваться xdg autostart.

-- 

I V

Re: [devel] RFC: wayland session wrapper script

[Yuri Sedunov]

В Пт, 03/12/2021 в 20:01 +0200, Igor Vlasenko пишет:
> On Fri, Dec 03, 2021 at 06:14:41PM +0300, Arseny Maslennikov wrote:
...
> > 
> > >    Возможно, проверить сначала, что мы не запущены под GDM, sddm,
> > > ...
> > Не возможно, а точно. :)
> 
> Видел где-то какие-то волшебные переменные, которые говорят,
> что мы из-под GDM.
> Нигде не найду, как понадобились :(

$ env|grep GDM
GDM_LANG=ru_RU.UTF-8
GDMSESSION=gnome


-- 
Yuri N. Sedunov