1

Тема: Изменения в Entware (идея) - обсуждаем.

Предисловие
При создании Qnapware и Entware-arm была пропатчена системная библиотека для совместимости с рядом устройств. В результате этих патчей бинарники Entware (Qnapware) имеют свой набор локалей и свой файл nsswitch.conf, расположенный в папке /opt/etc.
Пока никто не жаловался на это. Более того в некоторых случаях это удобно.

Преамбула
Пакеты entware используются на совершенно разных устройствах. На маршрутизаторах, НАСах, андроид железках, на экзотических Popoplug V2. На некоторых устройствах нет ssh сервера, на других самбы, на третьих нормальной linux авторизации.

Предлагаю Пропачить системную библиотеку так, чтобы функции авторизации использовали файлы /opt/etc/passwd, /opt/etc/group (и /opt/etc/shadow, /opt/etc/gshadow, /opt/etc/shells) вместо этих же файлов, но в папке /etc

Что это даст
Возможность запускать dropbear, samba на тех системах, где это было невозможно или сложно. Создавать дополнительных пользователей для сервисов, когда это нужно.

Недостатки
Если использовать службы и сервисы Entware, которым нужна авторизация, то пароль суперпользователя будет тот, который задан в Entware, а не в основной системе. Имя суперпользователя всегда будет root (а не admin, как могло быть раньше).

Большинство не использует такие службы из Entware, их такие изменения (почти) не затронут. Если не устанавливать busybox, dropbear, samba из entware, то все останется как и раньше (но никто не мешает их установить и использовать). А вот на "хитрых системах" это поможет. Хитрые системы - те же ZyXEL Keenetic с прошивкой NDMS V1 (нет ssh, файлы в /etc не используются и имеют ошибки, сильно урезан busybox), андроиды (тут полный разброд и шатание: на одних железках нет одного, на других другого). Popoplug - нет самбы.

Ваше мнение?
Отписываемся. Если используются сильно нестандартные железки - какие?

2

Re: Изменения в Entware (идея) - обсуждаем.

Имхо, есть резон попробовать создать отдельный пакет с патченым uclibc (или-что-там-ещё-используется-в-форках) с предлагаемым поведением. Если получится такой пакет штатно разворачивать через opkg (и обратно) - будет здорово и некоторым поможет. Не у всех "хитрые системы". К примеру, на прошивке Padavan и так всё отлично, зачем принуждать пользователей писать новые конфиги?

3

Re: Изменения в Entware (идея) - обсуждаем.

Голос незарегистрированного пользователя, внезапно:

theMIROn :

не думаю, что такой дефолт - полезен. лучше - сделать патченую либу отдельным пакетом с кучей варнингов, в пост-инсталл пакета - копирование добра из /etc/ в /opt/etc

и, кстати, /etc/passwd юзается не только в libc емнип, поэтому одной либой дело может и не обойтись

Отредактировано ryzhov_al (2015-05-06 12:13:48)

Со всеми вытекающими...

4

Re: Изменения в Entware (идея) - обсуждаем.

MercuryV :

попробовать создать отдельный пакет с патченым uclibc

Это пока и планируется. Но кроме пакета libc_xxx.ipk потребуется установить busybox (в нем апплет adduser и т.п. напрямую работают с файлами passwd, group). Пакет samba36 потребуется с дополнительными патчами. пакеты shadow* нужно изменить утилиты типа useradd опять напрямую работают с файлами авторизации.

MercuryV :

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

Для каких пакетов потребуются новые конфиги? Можно пример. Если и потребуются то таких единицы.

А вот если все оставить как и было, то возникает вопрос - что будет если пользователь установит и запустит shadow-useradd. Проработает ли он, а если проработает, то проработает ли корректно? А если проработает корректно, то останутся ли изменения после перезагрузки?

5

Re: Изменения в Entware (идея) - обсуждаем.

ryzhov_al :

кстати, /etc/passwd юзается не только в libc емнип, поэтому одной либой дело может и не обойтись

Да, выше привел пакеты, в которых он используется. В текущей сборке entware число файлов, где используется /etc/passwd менее 40. Половину из них я выше указал. Еще используется в proftpd (используется ли реально???) в zabbix и нескольких пиновских скриптах.

6

Re: Изменения в Entware (идея) - обсуждаем.

в пост-инсталл пакета - копирование добра из /etc/ в /opt/etc

Влад дело предлагает.
Кстати, а вариант пропатчить так, чтобы сначала конфиги искались в /opt/etc, а при отстутствии там - в /etc не рассматривается?

7

Re: Изменения в Entware (идея) - обсуждаем.

Повторюсь здесь.

На мой взгляд, надо определиться с каким-либо одним решением:

  • оставить всё как есть,

  • читать всё из /opt

  • читать из /opt только passwd и groups, а services/hosts и другое оставить в /etc.

Третий вариант не однозначен: стоит ли переносить в /opt shells?

Поддерживать сразу несколько решений, например пакеты с патченой и непатченой *libc — легче сразу застрелиться.

Красивых вариантов я не вижу, а раз так, то стоит ли малой части девайсов городить огород?

Со всеми вытекающими...

8

Re: Изменения в Entware (идея) - обсуждаем.

Я понимаю, что красивых вариантов нет. Можно вернутся к решению, которое используется в entware+keenetic. Вот кусочек скрипта запуска Entware на кинетике:

find /etc -mindepth 1 -maxdepth 1 ! -name passwd ! -name shells ! -name group -exec cp {} -RPf <папка, в которую  почти все копируем>
/bin/mount -o bind "<папка, в которую  почти все копируем>" /etc

Я считаю, services/hosts/protocols и т.п. нужно оставить как есть.

ryzhov_al :

стоит ли переносить в /opt shells?

Да. Это нужно для dropbear. Можно вернуть postinst в пакетах с новыми шеллами - https://github.com/Entware/entware/blob … path.patch

ryzhov_al :

пакеты с патченой и непатченой *libc — легче сразу застрелиться.

+100

MercuryV :

в пост-инсталл пакета - копирование добра из /etc/ в /opt/etc

??? Зачем. Ничего этого не нужно. Пакеты продолжают работать со своими файлами, как раньше. Если же используются функции (авторизации) getpwxxxx, то обращение идет к /opt/etc/passwd (через системную либу).

9

Re: Изменения в Entware (идея) - обсуждаем.

Список файлов (из /staging_dir/....root-<платформа>), в которых есть /etc/passwd. Включены все, в том числе и текстовые файлы

$ find . -type f -exec grep -n -l /etc/passwd {} \;
./etc/nginx/naxsi_core.rules
./etc/postfix/main.cf.proto
./etc/postfix/main.cf
./etc/rsnapshot.conf
./etc/zabbix_agentd.conf
./etc/zabbix_agent.conf
./etc/lighttpd/conf.d/30-userdir.conf
./etc/freeradius2/sites/default
./etc/freeradius2/modules/passwd
./etc/mc/mcedit.menu
./sbin/unix_chkpwd
./sbin/userdel
./sbin/samba_multicall
./sbin/usermod
./sbin/mount.davfs
./sbin/zabbix_agent
./sbin/proftpd
./sbin/zabbix_server
./sbin/useradd
./sbin/unix_update
./sbin/zabbix_proxy
./sbin/groupmod
./sbin/zabbix_agentd
./share/zsh/5.0.6/functions/Completion/Unix/_su
./share/zsh/5.0.6/functions/Completion/compaudit
./share/vim/vim74/filetype.vim
./share/vim/vim74/ftplugin/changelog.vim
./share/vim/vim74/doc/eval.txt
./share/vim/vim74/doc/map.txt
./share/vim/vim74/doc/todo.txt
./share/vim/vim74/doc/filetype.txt
./share/doc/dovecot/example-config/example-config/conf.d/10-auth.conf
./share/doc/dovecot/example-config/example-config/conf.d/auth-system.conf.ext
./share/mc/help/mc.hlp
./bin/gawk
./bin/rsnapshot
./bin/chage
./bin/sendsms
./bin/psktool
./bin/busybox
./bin/pgawk
./bin/passwd
./bin/lsof
./lib/security/pam_unix.so
./lib/security/pam_localuser.so
./lib/ruby/2.2/open-uri.rb
./lib/ruby/2.2/pathname.rb
./lib/ruby/2.2/arm-linux-gnueabi/etc.so
./lib/perl5/5.20/Config_heavy.pl
./lib/libnss_files-2.20.so
./lib/libnss_compat-2.20.so
./lib/python2.7/StringIO.py
./lib/python2.7/bsddb/dbrecio.py
./lib/python2.7/site-packages/twisted/conch/manhole_tap.py
./lib/python2.7/site-packages/mercurial/byterange.py
./lib/python2.7/site-packages/werkzeug/utils.py
./lib/python2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py

10

Re: Изменения в Entware (идея) - обсуждаем.

Немного истории.
1. Сначала жила-была zyxware. Чтобы запустить dropbear и другие бинарники, использующие функции getpwxxx делались патчи, подменяющие функции авторизации на свои, использующие файлы passwd и подобные в других папках.
2. Потом для Entware на кинетиках делался специальный скрипт запуска (фрагмент выше), использующий mount -bind /etc.
3. Предлагается третье решение, на мой взгляд самое универсально и не меняющее ничего (ну почти) для "стандартных" железок. Но и на этих железках может пригодится (для запуска сервисов, которым нужен определенный юзер, которого стандартными средствами не создать).

11

Re: Изменения в Entware (идея) - обсуждаем.

Резюмируя дискуссию в скайпе. В связи с тем, что я упёрся рогом и не увидел у предлагаемой идеи весомых преимуществ, Zyxmon'ом предложен следующий вариант: собрать busybox и samba в двух вариантах, отличающихся местом заимствования системных файлов.

Коллеги?

Со всеми вытекающими...

12

Re: Изменения в Entware (идея) - обсуждаем.

Возможно вариант с кастомными busybox и samba достаточен.
Можно ещё dropbear, чтоб два раза не вставать.

13

Re: Изменения в Entware (идея) - обсуждаем.

MercuryV :

Можно ещё dropbear

"Неможно". dropbear всю информацию получает через системные вызовы *libc. Его негде патчить.

ryzhov_al :

что я упёрся рогом

Никакого упирания рогом я не увидел.  Вопрос дискуссионный, неоднозначный. Поэтому тему и создал. Отношение к Entware у нас немного разное. Я считаю Entware универсальной системой на все случаи жизни, а Александр - системой, прежде всего, для азусовских роутеров.

Не вижу проблем один раз создать несколько пакетов (*.ipk), которые модифицируют поведение entware. Вопрос в другом. Если предложение не принимается, то варианты такие
(1) Его использую в entware-arm и qnapware
или
(2) параллельно собирается два варианта пакетов (их немного libc, busybox, samba, shadow*, proftpd ...).

В случае (2) возникает вопрос автоматизации сборки с минимальными накладными расходами.

Бинарники entware имеют свой environment, свои локаль, dynamic_loader. Почему бы им (опционально) не иметь и свою систему авторизации, не зависимую от основной системы?

14

Re: Изменения в Entware (идея) - обсуждаем.

Zyxmon :

Отношение к Entware у нас немного разное. Я считаю Entware универсальной системой на все случаи жизни, а Александр - системой, прежде всего, для азусовских роутеров.

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

Zyxmon :

Вопрос в другом. Если предложение не принимается, то варианты такие
(1) Его использую в entware-arm и qnapware
или
(2) параллельно собирается два варианта пакетов (их немного libc, busybox, samba, shadow*, proftpd ...).

В случае (2) возникает вопрос автоматизации сборки с минимальными накладными расходами.

Бинарники entware имеют свой environment, свои локаль, dynamic_loader. Почему бы им (опционально) не иметь и свою систему авторизации, не зависимую от основной системы?

Наверное так будет лучше всего. Потому, что это больше актуально для фидов ARM/X86, не входящих в «исторический» Entware для MIPSEL-устройств.

Со всеми вытекающими...

15

Re: Изменения в Entware (идея) - обсуждаем.

Проверил идею - все работает.
Пока склоняюсь к такому решению -
выложить в отдельной папке несколько ipk файлов (libc, busybox, samba,..) и рядом дополнительные патчи для сборки.

16

Re: Изменения в Entware (идея) - обсуждаем.

По итогам этого обсуждения набросал заметку
http://www.zyxmon.org/2015/05/10/ustana … -zhelezki/