[devel] /usr/bin/bash

[devel] /usr/bin/bash

[Vitaly Lipatov]

Некоторые скрипты из апстримов используют /usr/bin/bash.
Может быть, мы можем сделать (под)пакет, предоставляющий симлинк 
/usr/bin/bash?
Есть ли какие-то возражения?

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] /usr/bin/bash

[Vladimir D. Seleznev]

On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
> Некоторые скрипты из апстримов используют /usr/bin/bash.

А мы не можем исправлять скрипты?

> Может быть, мы можем сделать (под)пакет, предоставляющий симлинк 
> /usr/bin/bash?
> Есть ли какие-то возражения?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] /usr/bin/bash

[Ivan A. Melnikov]

On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
> Некоторые скрипты из апстримов используют /usr/bin/bash.
> Может быть, мы можем сделать (под)пакет, предоставляющий симлинк
> /usr/bin/bash?
> Есть ли какие-то возражения?

Если начать такое делать, будет сложно остановиться.

-- 
  wbr,
    iv m.

Re: [devel] /usr/bin/bash и объединение /usr/bin и /bin

[Vitaly Lipatov]

Ivan A. Melnikov писал 20.8.21 16:24:
> On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
>> Некоторые скрипты из апстримов используют /usr/bin/bash.
>> Может быть, мы можем сделать (под)пакет, предоставляющий симлинк
>> /usr/bin/bash?
>> Есть ли какие-то возражения?
> 
> Если начать такое делать, будет сложно остановиться.
Всё время на пустом месте хвастаться несовместимостью с остальным миром 
тоже довольно бессмысленный путь.

lav@ubuntu64:~$ which bash
/usr/bin/bash

lav@ubuntu64:~$ ls -ld /bin
lrwxrwxrwx 1 root root 7 Jul 31  2020 /bin -> usr/bin


[lav@fedora64 ~]$ which bash
/usr/bin/bash
[lav@fedora64 ~]$ ls /bin -ld
lrwxrwxrwx. 1 root root 7 янв 26  2021 /bin -> usr/bin

Я не против, если все за то, чтобы объединить /bin и /usr/bin, это решит 
проблему.

Но более простым мне представляется вопрос, чем bash хуже, чем
/bin/zsh <- /usr/bin/zsh
или даже
/bin/cat <- /usr/bin/cat

(см. списки в конце письма)

За что боремся?


Vladimir D. Seleznev писал 20.8.21 16:21:
> On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
>> Некоторые скрипты из апстримов используют /usr/bin/bash.
> 
> А мы не можем исправлять скрипты?
Можем. Но если это делают вендоры, то они начинают громоздить лапшу с 
проверкой версии дистрибутива, разными вариантами скриптов и пр.

Что говорить, СБИС поставляет свой glibc, чтобы на ALT работала их 
программа :)

А если это делаем мы, то это непростой труд, и хотелось бы понимать, 
ради чего он.


У нас обнаруживается как минимум три ссылки в /bin на бинарники в 
/usr/bin
$ for i in $(find /bin -type l) ; do echo "$(readlink -f $i) <- $i" ; 
done | grep ^/usr/bin
/usr/bin/tracepath <- /bin/tracepath
/usr/bin/tracepath <- /bin/tracepath6
/usr/bin/rpm <- /bin/rpm

И гораздо больше в обратную сторону:
$ for i in $(find /usr/bin -type l) ; do echo "$(readlink -f $i) <- $i" 
; done | grep ^/bin
/bin/tput <- /usr/bin/tput
/bin/unicode_start <- /usr/bin/unicode_start
/bin/sort <- /usr/bin/sort
/bin/setfont <- /usr/bin/setfont
/bin/bzip2recover <- /usr/bin/bzip2recover
/bin/mail <- /usr/bin/mailx
/bin/monit <- /usr/bin/monit
/bin/getopt <- /usr/bin/getopt
/bin/head <- /usr/bin/head
/bin/tail <- /usr/bin/tail
/bin/install <- /usr/bin/install
/bin/unicode_stop <- /usr/bin/unicode_stop
/bin/gawk <- /usr/bin/pgawk
/bin/install <- /usr/bin/ginstall
/bin/dbus-send <- /usr/bin/dbus-send
/bin/systemctl <- /usr/bin/systemctl
/bin/fgconsole <- /usr/bin/fgconsole
/bin/wc <- /usr/bin/wc
/bin/deallocvt <- /usr/bin/deallocvt
/bin/taskset <- /usr/bin/taskset
/bin/gawk <- /usr/bin/awk
/bin/zsh <- /usr/bin/zsh
/bin/du <- /usr/bin/du
/bin/cat <- /usr/bin/cat
/bin/dbus-launch <- /usr/bin/dbus-launch
/bin/kill <- /usr/bin/kill
/bin/find <- /usr/bin/find
/bin/mail <- /usr/bin/Mail
/bin/kbd_mode <- /usr/bin/kbd_mode
/bin/dumpkeys <- /usr/bin/dumpkeys
/bin/mkfifo <- /usr/bin/mkfifo
/bin/cut <- /usr/bin/cut
/bin/gawk <- /usr/bin/gawk
/bin/chvt <- /usr/bin/chvt
/bin/raw <- /usr/bin/raw
/bin/xargs <- /usr/bin/xargs
/bin/gawk <- /usr/bin/dgawk
/bin/openvt <- /usr/bin/openvt


-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] /usr/bin/bash

[Dmitry V. Levin]

On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
> Некоторые скрипты из апстримов используют /usr/bin/bash.
> Может быть, мы можем сделать (под)пакет, предоставляющий симлинк 
> /usr/bin/bash?
> Есть ли какие-то возражения?

Я против.  Пусть кривые апстримы выпрямляются.


-- 
ldv

Re: [devel] /usr/bin/bash и объединение /usr/bin и /bin

[Andrey Savchenko]

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

On Fri, 20 Aug 2021 23:29:35 +0300 Vitaly Lipatov wrote:
> Ivan A. Melnikov писал 20.8.21 16:24:
> > On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
> >> Некоторые скрипты из апстримов используют /usr/bin/bash.
> >> Может быть, мы можем сделать (под)пакет, предоставляющий симлинк
> >> /usr/bin/bash?
> >> Есть ли какие-то возражения?
> > 
> > Если начать такое делать, будет сложно остановиться.
> Всё время на пустом месте хвастаться несовместимостью с остальным миром 
> тоже довольно бессмысленный путь.
> 
> lav@ubuntu64:~$ which bash
> /usr/bin/bash
> 
> lav@ubuntu64:~$ ls -ld /bin
> lrwxrwxrwx 1 root root 7 Jul 31  2020 /bin -> usr/bin
> 
> 
> [lav@fedora64 ~]$ which bash
> /usr/bin/bash
> [lav@fedora64 ~]$ ls /bin -ld
> lrwxrwxrwx. 1 root root 7 янв 26  2021 /bin -> usr/bin

С каких это пор Ubuntu и Fedora стали всем остальным миром?

Вот пара примеров, что под рукой:

Gentoo:
$ which bash
/bin/bash

Debian:
$ which bash
/bin/bash

Best regards,
Andrew Savchenko

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

Re: [devel] /usr/bin/bash и объединение /usr/bin и /bin

[Dmitry V. Levin]

On Fri, Aug 20, 2021 at 11:29:35PM +0300, Vitaly Lipatov wrote:
> Ivan A. Melnikov писал 20.8.21 16:24:
> > On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
> >> Некоторые скрипты из апстримов используют /usr/bin/bash.
> >> Может быть, мы можем сделать (под)пакет, предоставляющий симлинк
> >> /usr/bin/bash?
> >> Есть ли какие-то возражения?
> > 
> > Если начать такое делать, будет сложно остановиться.
> Всё время на пустом месте хвастаться несовместимостью с остальным миром 
> тоже довольно бессмысленный путь.
> 
> lav@ubuntu64:~$ which bash
> /usr/bin/bash

Вывод which говорит о том, какой каталог первый в $PATH.
При этом в любом дистрибутиве верно следующее:
$ PATH=/bin:/usr/bin which bash
/bin/bash


-- 
ldv

Re: [devel] /usr/bin/bash

[Alexey V. Vissarionov]

On 2021-08-21 00:11:27 +0300, Dmitry V. Levin wrote:

 >> Некоторые скрипты из апстримов используют /usr/bin/bash.
 >> Может быть, мы можем сделать (под)пакет, предоставляющий
 >> симлинк /usr/bin/bash?
 >> Есть ли какие-то возражения?
 > Я против. Пусть кривые апстримы выпрямляются.

Это, конечно, было бы хорошо... но пока вполне можно обойтись
банальным sed -i -re '1,1{s,/usr/bin/bash,/bin/bash,g}' $file


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

Re: [devel] /usr/bin/bash

[Vitaly Lipatov]

Dmitry V. Levin писал 21.8.21 0:11:
> On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
>> Некоторые скрипты из апстримов используют /usr/bin/bash.
>> Может быть, мы можем сделать (под)пакет, предоставляющий симлинк
>> /usr/bin/bash?
>> Есть ли какие-то возражения?
> 
> Я против.  Пусть кривые апстримы выпрямляются.
А есть какие-то аргументы?
Или просто /bin/bash так же как /bin/sh?

Почему у нас есть симлинки
/usr/bin/cat
/usr/bin/zsh
и т.д.,
а /usr/bin/bash это внезапно плохо.

В целях выпрямления апстримов я бы и /usr/bin/cat убрал.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] /usr/bin/bash

[Dmitry V. Levin]

On Sat, Aug 21, 2021 at 02:37:10AM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 21.8.21 0:11:
> > On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
> >> Некоторые скрипты из апстримов используют /usr/bin/bash.
> >> Может быть, мы можем сделать (под)пакет, предоставляющий симлинк
> >> /usr/bin/bash?
> >> Есть ли какие-то возражения?
> > 
> > Я против.  Пусть кривые апстримы выпрямляются.
> А есть какие-то аргументы?
> Или просто /bin/bash так же как /bin/sh?

Непонятно, зачем люди ломают обратную совместимость на ровном месте.
/bin/bash - это практически стандарт.

> Почему у нас есть симлинки
> /usr/bin/cat

В coreutils.spec написано, что для обратной совместимости, оно там
с момента появления coreutils в 2002 году, видимо, приехало туда в
результате объединения пакетов fileutils, sh-utils, и textutils.

> В целях выпрямления апстримов я бы и /usr/bin/cat убрал.

Я не хочу тратить время на исследование того, нужен ли ещё /usr/bin/cat
где-нибудь, а вы хотите?


-- 
ldv

Re: [devel] /usr/bin/bash

[Vitaly Lipatov]

Dmitry V. Levin писал 21.8.21 11:18:
> On Sat, Aug 21, 2021 at 02:37:10AM +0300, Vitaly Lipatov wrote:
>> Dmitry V. Levin писал 21.8.21 0:11:
>> > On Fri, Aug 20, 2021 at 01:28:33PM +0300, Vitaly Lipatov wrote:
>> >> Некоторые скрипты из апстримов используют /usr/bin/bash.
>> >> Может быть, мы можем сделать (под)пакет, предоставляющий симлинк
>> >> /usr/bin/bash?
>> >> Есть ли какие-то возражения?
>> >
>> > Я против.  Пусть кривые апстримы выпрямляются.
>> А есть какие-то аргументы?
>> Или просто /bin/bash так же как /bin/sh?
> 
> Непонятно, зачем люди ломают обратную совместимость на ровном месте.
> /bin/bash - это практически стандарт.
Смущает при этом запись в спеке:
b/bash4/bвash.spec:mv %buildroot%_bindir/bash %buildroot/bin/%name

...
> Я не хочу тратить время на исследование того, нужен ли ещё /usr/bin/cat
> где-нибудь, а вы хотите?

:)

Спасибо за ответы, будем править апстримы.

P.S.
В спеках удаётся найти не так много замен:
c/cri-o/cri-o.spec:sed -i -e 's|/usr/bin/mkdir|/bin/mkdir|; 
s|/usr/bin/touch|/bin/touch|; s|/usr/bin/rm|/bin/rm|; 
s|/usr/bin/bash|/bin/bash|' \
d/deepin-session-shell/deepin-session-shell.spec:sed -i 
's|/usr/bin/bash|/bin/bash|' src/dde-shutdown/view/contentwidget.cpp
g/gradle/gradle.spec:sed -i -e s,/usr/bin/bash,/bin/sh, 
%buildroot%_bindir/*
j/java-runtime-decompiler/java-runtime-decompiler.spec:sed -i 
s,/usr/bin/bash,/bin/bash, %SOURCE1
p/perl-Test-YAML/perl-Test-YAML.spec:sed -i -e s,/usr/bin/bash,/bin/sh, 
bin/test-yaml
r/rr/rr-project.spec:subst '1s:/usr/bin/bash:/bin/bash:' 
%buildroot%_bindir/signal-rr-recording.sh


-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] /usr/bin/bash

[Dmitry V. Levin]

On Sat, Aug 21, 2021 at 01:33:16PM +0300, Vitaly Lipatov wrote:
[...]
> Спасибо за ответы, будем править апстримы.

Непонятно, откуда вообще берётся желание указывать абсолютные пути к тому,
что находится в $PATH.  Интерпретаторы из-за shebang, а остальные зачем?


-- 
ldv

Re: [devel] /usr/bin/bash

[Vitaly Lipatov]

Dmitry V. Levin писал 21.8.21 13:38:
> On Sat, Aug 21, 2021 at 01:33:16PM +0300, Vitaly Lipatov wrote:
> [...]
>> Спасибо за ответы, будем править апстримы.
> 
> Непонятно, откуда вообще берётся желание указывать абсолютные пути к 
> тому,
> что находится в $PATH.  Интерпретаторы из-за shebang, а остальные 
> зачем?

Возможно, что где-то не знают про execlp/execvp и запускают с помощью 
exec по прямому пути?

А вот некоторые пишут
#!/usr/bin/env bash

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


-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] /usr/bin/bash

[Leonid Krivoshein]

21.08.2021 13:38, Dmitry V. Levin пишет:
> On Sat, Aug 21, 2021 at 01:33:16PM +0300, Vitaly Lipatov wrote:
> [...]
>> Спасибо за ответы, будем править апстримы.
> Непонятно, откуда вообще берётся желание указывать абсолютные пути к тому,
> что находится в $PATH.  Интерпретаторы из-за shebang, а остальные зачем?

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


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] /usr/bin/bash

[Vitaly Lipatov]

Dmitry V. Levin писал 21.8.21 13:38:
> On Sat, Aug 21, 2021 at 01:33:16PM +0300, Vitaly Lipatov wrote:
> [...]
>> Спасибо за ответы, будем править апстримы.
> 
> Непонятно, откуда вообще берётся желание указывать абсолютные пути к 
> тому,
> что находится в $PATH.  Интерпретаторы из-за shebang, а остальные 
> зачем?

Возможно, не владеют необходимым средством в языке:
		if (file_exists('/usr/sbin/btrfs')) {
			$this->binary = '/usr/sbin/btrfs';
		} elseif (file_exists('/sbin/btrfs')) {
			$this->binary = '/sbin/btrfs';
		} elseif (file_exists('/bin/btrfs')) {
			$this->binary = '/bin/btrfs';
		} else {
			throw new RuntimeException("Can't find btrfs binary");
		}
-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] /usr/bin/bash

[Alexey V. Vissarionov]

On 2021-08-21 13:38:07 +0300, Dmitry V. Levin wrote:

 >> Спасибо за ответы, будем править апстримы.
 > Непонятно, откуда вообще берётся желание указывать абсолютные
 > пути к тому, что находится в $PATH. Интерпретаторы из-за shebang,
 > а остальные зачем?

Например, из-за того, что до сих пор существуют не очень мудрые
люди, которые считают, что простому пользователю не нужны каталоги
/sbin, /usr/sbin, /opt/sbin и /usr/local/sbin в ${PATH}.

Например, многострадальный /sbin/ip я в скриптах вижу регулярно.


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

Re: [devel] /usr/bin/bash

[Alexey V. Vissarionov]

On 2021-08-21 15:02:28 +0300, Leonid Krivoshein wrote:

 >>> Спасибо за ответы, будем править апстримы.
 >> Непонятно, откуда вообще берётся желание указывать абсолютные
 >> пути к тому, что находится в $PATH. Интерпретаторы из-за
 >> shebang, а остальные зачем?
 > Типичный администраторский подход.

Как раз у хорошего админа в $PATH есть все необходимое.

 > Не все в курсе интерактивного режима.

Это как - "не в курсе"?

 > Где-то боятся нарваться на алиасы,

Вот это, кстати, в полный рост... И за пакет rootfiles нас ругают
вполне заслуженно.

 > хотя не должны при выполнении скрипта,

Скрипты бывают и однострочными, запускаемыми прямо из командной
строки.

 > где-то для воспроизводимости или безопасности, если что-то
 > изменится во внешней среде.

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


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

Re: [devel] /usr/bin/bash

[Vladimir D. Seleznev]

On Sat, Aug 21, 2021 at 10:12:18PM +0300, Alexey V. Vissarionov wrote:
> On 2021-08-21 15:02:28 +0300, Leonid Krivoshein wrote:
> 
>  >>> Спасибо за ответы, будем править апстримы.
>  >> Непонятно, откуда вообще берётся желание указывать абсолютные
>  >> пути к тому, что находится в $PATH. Интерпретаторы из-за
>  >> shebang, а остальные зачем?
>  > Типичный администраторский подход.
> 
> Как раз у хорошего админа в $PATH есть все необходимое.
> 
>  > Не все в курсе интерактивного режима.
> 
> Это как - "не в курсе"?
> 
>  > Где-то боятся нарваться на алиасы,
> 
> Вот это, кстати, в полный рост... И за пакет rootfiles нас ругают
> вполне заслуженно.

Впервые слышу, что кто-то ругает за него. И в чём вред этого пакета?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] /usr/bin/bash

[Alexey V. Vissarionov]

On 2021-08-22 04:08:07 +0000, Vladimir D. Seleznev wrote:

 >>> Где-то боятся нарваться на алиасы,
 >> Вот это, кстати, в полный рост... И за пакет rootfiles нас
 >> ругают вполне заслуженно.
 > Впервые слышу, что кто-то ругает за него. И в чём вред этого
 > пакета?

Вредов там как минимум два:

1. Алиасы с параметром -i для cp, rm итд вызывают интересные
спецэффекты в однострочниках. Например, когда речь идет о
перезапуске демонов - особенно таких критичных, как SSH:
service sshd stop && cp /etc/ssh/sshd_config{.backup,} &&
service sshd start

2. После того, как пользователь нарывается на вышеописанный
спецэффект, у него возникает вполне разумное желание вынести
этот пакет. И тут его ждет следующая подстава, еще интереснее:
файл ~root/.ssh/authorized_keys переименовывается в *.rpmsave
и пользователь теряет административный доступ к компутеру
(если, конечно, заранее не проковырял какую-нибудь дырку через
тот же sudo).

Зачем вообще что-то делать с чужими конфигами - мне неочевидно.
Да и вообще у нас таких корявостей много...


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

Re: [devel] /usr/bin/bash

[Vladimir D. Seleznev]

On Sun, Aug 22, 2021 at 06:32:59PM +0300, Alexey V. Vissarionov wrote:
> On 2021-08-22 04:08:07 +0000, Vladimir D. Seleznev wrote:
> 
>  >>> Где-то боятся нарваться на алиасы,
>  >> Вот это, кстати, в полный рост... И за пакет rootfiles нас
>  >> ругают вполне заслуженно.
>  > Впервые слышу, что кто-то ругает за него. И в чём вред этого
>  > пакета?
> 
> Вредов там как минимум два:
> 
> 1. Алиасы с параметром -i для cp, rm итд вызывают интересные
> спецэффекты в однострочниках. Например, когда речь идет о
> перезапуске демонов - особенно таких критичных, как SSH:
> service sshd stop && cp /etc/ssh/sshd_config{.backup,} &&
> service sshd start

Что мешает отредактировать имеющийся /root/.bashrc?

> 2. После того, как пользователь нарывается на вышеописанный
> спецэффект, у него возникает вполне разумное желание вынести
> этот пакет. И тут его ждет следующая подстава, еще интереснее:
> файл ~root/.ssh/authorized_keys переименовывается в *.rpmsave
> и пользователь теряет административный доступ к компутеру
> (если, конечно, заранее не проковырял какую-нибудь дырку через
> тот же sudo).

И почему может возникнуть желание удалить пакет вместо того, чтобы
отредактировать конфиги?

$ rpm -qc rootfiles 
/root/.bash_logout
/root/.bash_profile
/root/.bashrc
/root/.i18n
/root/.rpmmacros
/root/.ssh/authorized_keys
/root/.ssh/config
/root/.tcshrc
/root/.zlogout
/root/.zprofile
/root/.zshenv
/root/.zshrc

Обрати внимание на аргументы командной строки команды rpm.

> Зачем вообще что-то делать с чужими конфигами - мне неочевидно.
> Да и вообще у нас таких корявостей много...

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] /usr/bin/bash и объединение /usr/bin и /bin

[Oleg Solovyov]

В письме от пятница, 20 августа 2021 г. 23:29:35 MSK пользователь Vitaly 
Lipatov написал:
> lav@ubuntu64:~$ ls -ld /bin
> lrwxrwxrwx 1 root root 7 Jul 31  2020 /bin -> usr/bin
> 
> [lav@fedora64 ~]$ ls /bin -ld
> lrwxrwxrwx. 1 root root 7 янв 26  2021 /bin -> usr/bin

Выстрел себе в обе ноги из картечницы.
Если /usr не примонтируется по какой-то причине, восстановить систему будет 
невозможно без использования сторонних загрузочных носителей, т.к. все 
аварийные программы для починки лежат в /bin, который в упомянутых 
дистрибутивах почему-то симлинк на /usr/bin.

Re: [devel] /usr/bin/bash

[Alexey V. Vissarionov]

On 2021-08-22 17:21:31 +0000, Vladimir D. Seleznev wrote:

 >>>>> Где-то боятся нарваться на алиасы,
 >>>> Вот это, кстати, в полный рост... И за пакет rootfiles нас
 >>>> ругают вполне заслуженно.
 >>> Впервые слышу, что кто-то ругает за него. И в чём вред этого
 >>> пакета?
 >> Вредов там как минимум два:
 >> 1. Алиасы с параметром -i для cp, rm итд вызывают интересные
 >> спецэффекты в однострочниках.
 > Что мешает отредактировать имеющийся /root/.bashrc?

А что мешает сделать систему рабочей из коробки? Или хотя бы не
ломать ее?

Если бы параметр "-i" был настолько нужен, разработчики coreutils
обязательно сделали бы это поведением по умолчанию.

 >> 2. После того, как пользователь нарывается на вышеописанный
 >> спецэффект, у него возникает вполне разумное желание вынести
 >> этот пакет. И тут его ждет следующая подстава, еще интереснее:
 >> файл ~root/.ssh/authorized_keys переименовывается в *.rpmsave
 > И почему может возникнуть желание удалить пакет вместо того,
 > чтобы отредактировать конфиги?

Я же написал:

 >> Зачем вообще что-то делать с чужими конфигами - мне неочевидно.

И на зачем этот пакет вообще нужен, если конфиги все равно придется
редактировать?

 > $ rpm -qc rootfiles
 > /root/.bash_logout
 > /root/.bash_profile
 > /root/.bashrc
 > /root/.i18n
 > /root/.rpmmacros
 > /root/.ssh/authorized_keys
 > /root/.ssh/config
 > /root/.tcshrc
 > /root/.zlogout
 > /root/.zprofile
 > /root/.zshenv
 > /root/.zshrc

0. Какой смысл охватывать пакетной системой файлы в $HOME,
даже если это ~root ?

1. Зачем пихать в ~root конфиги для шеллов? Если пользователь
работает с каким-то шеллом, конфиги у него свои, а если не
пользуется вообще, то они ему просто не нужны.
Но даже если на этот вопрос вдруг есть разумный ответ, то:

2. Зачем задавать для root алиасы с "-i"? Чтобы выработать
у пользователей привычку использовать параметр "-f"? Здесь,
правда, могу поздравить авторов этой офигенной идеи: у них
это прекрасно получается.

3. Если очень уж хочется облагодетельствовать пользователей,
пакет rootfiles лучше сделать пустым, а в его %post настроить
копирование отсутствующих в ~root файлов из /etc/skel - это
же позволит передать управление их содержимым мейнтейнерам
соответствующих пакетов (bash, tcsh, zsh).

4. Пользовательские конфиги SSH трогать не надо. Вообще никак.
Максимум - mkdir -pm700 ~/.ssh && touch ~/.ssh/authorized_keys
(и то некоторые пользователи будут недовольны получать после
каждого обновления письма от систем контроля целостности).

 > Обрати внимание на аргументы командной строки команды rpm.

Да я-то видел, что они %config - только пользователям от этого
ни разу не легче.

 >> Да и вообще у нас таких корявостей много...

Здесь, насколько я понимаю, возражений нет?


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

Re: [devel] /usr/bin/bash и объединение /usr/bin и /bin

[Alexey V. Vissarionov]

On 2021-08-23 09:35:33 +0300, Oleg Solovyov wrote:

 >> lav@ubuntu64:~$ ls -ld /bin
 >> lrwxrwxrwx 1 root root 7 Jul 31 2020 /bin -> usr/bin
 >> [lav@fedora64 ~]$ ls /bin -ld
 >> lrwxrwxrwx. 1 root root 7 янв 26 2021 /bin -> usr/bin
 > Выстрел себе в обе ноги из картечницы.
 > Если /usr не примонтируется по какой-то причине,

/usr в виде отдельной файловой системы - такой же архаизм,
как, например, отдельная ФС для /boot или как использование
initrd при загрузке с локального накопителя.

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

Сейчас отдельными файловыми системами есть смысл делать /home
и (на серверах) /var - да и то не из-за объема, а из-за разных
параметров монтирования (например, nosuid,nodev для /home и
noexec,nodev для /var).

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

Если и то, и другое находится на корневой ФС - никакой разницы.

 > который в упомянутых дистрибутивах почему-то симлинк на
 > /usr/bin.

Хм... А не наоборот?


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

Re: [devel] /usr/bin/bash

[Sergey V Turchin]

On Sunday, 22 August 2021 18:32:59 MSK Alexey V wrote:

[...]
> файл ~root/.ssh/authorized_keys переименовывается в *.rpmsave
> и пользователь теряет административный доступ к компутеру
У пользователя такого не бывает, а root ССЗБ.

[...]

-- 
Regards, Sergey.

Re: [devel] /usr/bin/bash

[Alexey V. Vissarionov]

On 2021-08-23 12:09:33 +0300, Sergey V Turchin wrote:

 >> файл ~root/.ssh/authorized_keys переименовывается в
 >> *.rpmsave и пользователь теряет административный доступ
 >> к компутеру
 > У пользователя такого не бывает, а root ССЗБ.

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


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

Re: [devel] /usr/bin/bash

[Sergey V Turchin]

On Monday, 23 August 2021 13:42:05 MSK Alexey V wrote:
> On 2021-08-23 12:09:33 +0300, Sergey V Turchin wrote:
>  >> файл ~root/.ssh/authorized_keys переименовывается в
>  >> *.rpmsave и пользователь теряет административный доступ
>  >> к компутеру
>  > 
>  > У пользователя такого не бывает, а root ССЗБ.
> 
> Ага... Только именно такие Б и визжат в сетевых конференциях,
> формируя у полупочтенной публики устойчивый образ "альтговно".
Им не поможет.

-- 
Regards, Sergey.

Re: [devel] /usr/bin/bash

[Vladimir D. Seleznev]

On Mon, Aug 23, 2021 at 11:17:21AM +0300, Alexey V. Vissarionov wrote:
> On 2021-08-22 17:21:31 +0000, Vladimir D. Seleznev wrote:
> 
>  >>>>> Где-то боятся нарваться на алиасы,
>  >>>> Вот это, кстати, в полный рост... И за пакет rootfiles нас
>  >>>> ругают вполне заслуженно.
>  >>> Впервые слышу, что кто-то ругает за него. И в чём вред этого
>  >>> пакета?
>  >> Вредов там как минимум два:
>  >> 1. Алиасы с параметром -i для cp, rm итд вызывают интересные
>  >> спецэффекты в однострочниках.
>  > Что мешает отредактировать имеющийся /root/.bashrc?
> 
> А что мешает сделать систему рабочей из коробки? Или хотя бы не
> ломать ее?

Она рабочая и не поломанная из коробки.

> Если бы параметр "-i" был настолько нужен, разработчики coreutils
> обязательно сделали бы это поведением по умолчанию.

Он работает в интерактивном шелле. Можно поспорить, нужны ли таки алиасы
по-умолчанию, но факт в том, что сейчас они есть. А для однострочников
на шелле лучше начинать команды с символа бэкслеша "\": мало ли какие
ещё алиасы выстрелят:

while read -r f n; do \mv "$f" "$n"; done <flist

>  >> 2. После того, как пользователь нарывается на вышеописанный
>  >> спецэффект, у него возникает вполне разумное желание вынести
>  >> этот пакет. И тут его ждет следующая подстава, еще интереснее:
>  >> файл ~root/.ssh/authorized_keys переименовывается в *.rpmsave
>  > И почему может возникнуть желание удалить пакет вместо того,
>  > чтобы отредактировать конфиги?
> 
> Я же написал:
> 
>  >> Зачем вообще что-то делать с чужими конфигами - мне неочевидно.

Ничего с ними не сделано: это конфиги по-умолчанию.

> И на зачем этот пакет вообще нужен, если конфиги все равно придется
> редактировать?

Или не придётся.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] /usr/bin/bash

[Alexey V. Vissarionov]

On 2021-08-23 13:54:40 +0300, Sergey V Turchin wrote:

 >>>> файл ~root/.ssh/authorized_keys переименовывается в
 >>>> *.rpmsave и пользователь теряет административный доступ
 >>>> к компутеру
 >>> У пользователя такого не бывает, а root ССЗБ.
 >> Ага... Только именно такие Б и визжат в сетевых конференциях,
 >> формируя у полупочтенной публики устойчивый образ "альтговно".
 > Им не поможет.

А нам вредит.


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

Re: [devel] /usr/bin/bash

[Aleksey Novodvorsky]

пн, 23 авг. 2021 г. в 18:07, Alexey V. Vissarionov <gremlin@altlinux.org>:
>
> On 2021-08-23 13:54:40 +0300, Sergey V Turchin wrote:
>
>  >>>> файл ~root/.ssh/authorized_keys переименовывается в
>  >>>> *.rpmsave и пользователь теряет административный доступ
>  >>>> к компутеру
>  >>> У пользователя такого не бывает, а root ССЗБ.
>  >> Ага... Только именно такие Б и визжат в сетевых конференциях,
>  >> формируя у полупочтенной публики устойчивый образ "альтговно".
>  > Им не поможет.
>
> А нам вредит.
Алексей, прошу не говорить за всех. Давайте вернемся к техническим
конкретным вопросам.

Rgrds, Алексей,

Re: [devel] /usr/bin/bash

[Dmitry V. Levin]

On Mon, Aug 23, 2021 at 11:17:21AM +0300, Alexey V. Vissarionov wrote:
[...]
>  >> Да и вообще у нас таких корявостей много...
> 
> Здесь, насколько я понимаю, возражений нет?

Насколько я вижу, здесь никто эту точку зрения не разделяет.


-- 
ldv

Re: [devel] /usr/bin/bash

[Andrey Savchenko]

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

On Mon, 23 Aug 2021 21:03:46 +0300 Dmitry V. Levin wrote:
> On Mon, Aug 23, 2021 at 11:17:21AM +0300, Alexey V. Vissarionov wrote:
> [...]
> >  >> Да и вообще у нас таких корявостей много...
> > 
> > Здесь, насколько я понимаю, возражений нет?
> 
> Насколько я вижу, здесь никто эту точку зрения не разделяет.

Не нужно за всех говорить, пожалуйста. Пакетирование файлов из $HOME
для меня выглядит дикостью и, наиболее вероятно, это нарушает LFS
или что-нибудь в этом духе.

С другой стороны, с проблемами на этой почве я не сталкивался
и вообще не знал, что эти файлы пакетируются до чтения данной ветки.
Чудачество какое-то, вот честно; давайте ещё содержимое /etc/tcb/
пакетировать.

Best regards,
Andrew Savchenko

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

Re: [devel] /usr/bin/bash

[Dmitry V. Levin]

On Mon, Aug 23, 2021 at 09:17:08PM +0300, Andrey Savchenko wrote:
> On Mon, 23 Aug 2021 21:03:46 +0300 Dmitry V. Levin wrote:
> > On Mon, Aug 23, 2021 at 11:17:21AM +0300, Alexey V. Vissarionov wrote:
> > [...]
> > >  >> Да и вообще у нас таких корявостей много...
> > > 
> > > Здесь, насколько я понимаю, возражений нет?
> > 
> > Насколько я вижу, здесь никто эту точку зрения не разделяет.
> 
> Не нужно за всех говорить, пожалуйста. Пакетирование файлов из $HOME
> для меня выглядит дикостью и, наиболее вероятно, это нарушает LFS
> или что-нибудь в этом духе.

root - не пользователь, /root - гораздо больше, чем просто домашний
каталог, и нет, это не нарушает LFS или что-нибудь в этом духе.

> С другой стороны, с проблемами на этой почве я не сталкивался
> и вообще не знал, что эти файлы пакетируются до чтения данной ветки.

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


-- 
ldv

Re: [devel] /usr/bin/bash

[Leonid Krivoshein]

23.08.2021 21:17, Andrey Savchenko пишет:
> On Mon, 23 Aug 2021 21:03:46 +0300 Dmitry V. Levin wrote:
>> On Mon, Aug 23, 2021 at 11:17:21AM +0300, Alexey V. Vissarionov wrote:
>> [...]
>>>   >> Да и вообще у нас таких корявостей много...
>>>
>>> Здесь, насколько я понимаю, возражений нет?
>> Насколько я вижу, здесь никто эту точку зрения не разделяет.
> Не нужно за всех говорить, пожалуйста. Пакетирование файлов из $HOME
> для меня выглядит дикостью и, наиболее вероятно, это нарушает LFS
> или что-нибудь в этом духе.
>
> С другой стороны, с проблемами на этой почве я не сталкивался
> и вообще не знал, что эти файлы пакетируются до чтения данной ветки.
> Чудачество какое-то, вот честно; давайте ещё содержимое /etc/tcb/
> пакетировать.

Пакетируется /etc/skel и конфиги в /root. Там есть вопросы и атавизмы 
типа /etc/skel.ru_RU.*, причём файлы упакованные по-разному, что-то как 
обычные файлы, что-то как файлы конфигурации. Наверное, правильный 
подход держать рекомендуемые настройки в области системы, а не данных 
пользователей. Опытные пользователи таскают всё своё с собой с машины на 
машину. Не очень хорошо, если root'у что-то внезапно приедет и перезапишет.

Если они конфиги, а не обычные файлы, получается не сильно лучше. Взять 
ту же настройку поддержки ECDSA в SSH. Если вы устанавливали систему на 
основе стабильного бранча p8, инсталляционный диск которой был выпущен в 
конце 2017, значит, в домашний каталог первого непривилегированного 
пользователя с UID 500 у вас попал .xprofile, в котором ещё не было 
поддержки SSH-ключей ECDSA и ED25519 -- она появился лишь в 2018 году в 
Сизифе: 
http://git.altlinux.org/gears/e/etcskel.git?p=etcskel.git;a=commitdiff;h=e50d1a39bc4c619bb6930662f5a2c41ad4d2b886 
. Будь она глобальной, она приехала бы всем пользователям с новой 
пакетной базой.

Насчёт алиасов, в Альте они разумные. Но их нужно прописывать в /etc 
глобально.

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


-- 
Best regards,
Leonid Krivoshein.