Александр Рыжов

Если не обременит, то наверное стоит, хотя бы для того, что бы посмотреть список пакетов для установки или скачать индивидуально интересующий пакет.Готово.https://www.ryzhov-al.ru/keenopt_index/ Обновляется раз в сутки.

На Entware при развёртывании Windows использовал dnsmasq + tftpd-hpa, т.к. не знаю другого TFTP-сервера, умеющего выполнять подстановку символов.ЗЫ Добавлю ради кинетиков в репозиторий dnsmasq.

К DNS-серверу, в свою очередь, со временем понадобятся ### Tunlr support server=/pandora.com/199.x.x.x server=/spotify.com/199.x.x.x или ### Using dnscrypt-proxy no-resolv server=127.0.0.1#65053 server=127.0.0.1#65054 Не верю, что всё это станут реализовывать. Лучше уж поднимать свой сервер.

Можно перекидывать DHCP-запросы серверу в LAN-сети и затем отдавать им нужные опции? ip dhcp relay server ‹address› Разумеется, в этом случае свой DHCP-сервер в LAN-сети должен брать на себя весь функционал заводского?

Так или иначе, нет возможности передать встроенному DHCP-серверу нужные опции. Всё, на что мы можем повлиять, это… (config)> ip dhcp class - DHCP class configuration pool - DHCP pool configuration host - set static lease host match - configure DHCP service relay - configure DHCP relay service

2. Экспорт LD_LIBRARY_PATH наверняка сделано потому, что в тулчейн для сбора пакетов не заложен rpath=/opt/lib. Хочу напомнить, что пути из LD_LIBRARY_PATH не заменяют rpath, а дополняют его подстановкой перед путями из rpath, что для без указания правильного префикса /opt не имеет смысла для ряда пакетов, использующих свои плагины (poptop, znc, perl и другие). Устанавливай LD_LIBRARY_PATH или нет, такие пакеты без правки префикса не взлетят: admin@RT-N66U:/tmp/home/root# ldd /opt/bin/perl libperl.so => /opt/lib/perl5/5.22/CORE/libperl.so (0x2aac0000) libpthread.so.0 => /opt/lib/libpthread.so.0 (0x2ac85000) libdl.so.0 => /opt/lib/libdl.so.0 (0x2acaa000) libm.so.0 => /opt/lib/libm.so.0 (0x2acbd000) ... Кроме того, для бинарников с установленными битами setuid или setgid содержимое LD_LIBRARY_PATH игнорируется по соображением безопасности. Это можно проверить, скажем, на пакете sudo. Если для сборки пакетов будет использовать билдут с этой правкой, то костыль с установкой LD_LIBRARY_PATH не понадобится.

1) Кажется, есть противоречение между wiki и прошивкой. Согласно этой статьи в среду должны передаётся: LD_LIBRARY_PATH=/opt/lib:/opt/usr/lib:/lib:/usr/lib Однако /lib/libndmOpkg.so при запуске initrc экспортирует в среду: LD_LIBRARY_PATH=/lib:/usr/lib:/opt/lib:/opt/usr/lib Это можно воспроизвести, написав «фальшивый» скрипт /opt/etc/init.d/S99fake со следующим содержимым: #!/bin/sh export > /opt/tmp/env.tst В итоге при запуске внешних сервисов возможны жалобы can't resolve symbol с аварийным завершением работы.

Как я пока что понимаю, несмотря на присутствие в base-files скриптов /lib/functions, OpenWrt'шный механизм не будет использоваться ни для конфигурирования пакетов, ни для запуска сервисов, т.к. для запуска выбрана NSLU-like схема /opt/etc/init.d/Sxx. Соответсвенно, Makefile'ы для половины пакетов всё равно придётся править, хотя бы ради добаваления скриптов запуска.

Насколько понимаю, сейчас среда NDM Systems Buildroot сделана так, чтобы как можно меньше отличаться от OpenWrt Buildroot. Пакеты конфигурируются, компилируются и пакуются без упоминания префикса /opt, что позволяет использовать Makefile'ы OpenWrt'шных пакетов без какой-либо модификации, а для распаковки на роутере в конфиге opkg.conf указывается опция dest root /opt. В частности, вижу в билдруте NDM: $ cat include/package-defaults.mk ... CONFIGURE_PREFIX:=/usr CONFIGURE_ARGS = \ --target=$(GNU_TARGET_NAME) \ --host=$(GNU_TARGET_NAME) \ --build=$(GNU_HOST_NAME) \ --program-prefix="" \ --program-suffix="" \ --prefix=$(CONFIGURE_PREFIX) \ --exec-prefix=$(CONFIGURE_PREFIX) \ --bindir=$(CONFIGURE_PREFIX)/bin \ --sbindir=$(CONFIGURE_PREFIX)/sbin \ --libexecdir=$(CONFIGURE_PREFIX)/lib \ --sysconfdir=/etc \ --datadir=$(CONFIGURE_PREFIX)/share \ --localstatedir=/var \ --mandir=$(CONFIGURE_PREFIX)/man \ --infodir=$(CONFIGURE_PREFIX)/info \ $(DISABLE_NLS) \ $(DISABLE_LARGEFILE) \ $(DISABLE_IPV6) Получается, что пакеты, которые конфигурируются с помощью GNU Build System (половина, а то и большинство) получат в своих бинарниках hardcoded-пути: /etc для поиска своих конфигов, /var — для сохранения временных данных, /usr/share для поиска данных и т.п., что неправильно. Правильный вариант кроме указания корректных опций конфигурирования потребует соответсвующего изменения Makefile'ов пакетов, что значительно более трудоёмкая задача. Первый путь был выбран исходя из перечисленных доводов? Не будет ли это нарушение FHS выглядеть коряво? Здесь лежат все необходимые правки билдрута, если будет выбран «правильный» путь. С пакетами, повторюсь, придётся повозиться отдельно.

Совершенно верно, те же uclibc обновить или base-files к примеру...Тогда наиболее логичный путь — это установка первым делом полноценного opkg. И не надо будет обременять "эмулятор" opkg всеми функциями настоящего (в части, записью статусов распакованных пакетов в /opt/lib/opkg/status), и будет возможность обновлять в т.ч. базовые файлы и uclibc-библиотеки.

В смысле? Т.е. при выполнении opkg upgrade должны обновляться в т.ч. те пакеты, которые были распакованы из /opt/install?Про Entware пока речь не заходила, но там не в пакетах только сам статический бинарник opkg. Это сделано умышлено, для того, чтобы он остался работоспособен даже в том случае, если остальная система в руинах. Кстати, сто́ит ли мне сделать такой html-индекс для keenopt для облегчения навигации по пакетам? Чуть позже сделаю на своих мощностях, посмотрим насколько будет полезен.

Примеры из моих пакетов: раз, два, три. Раз у /opt/install цель — установить окружение для работы, то теоретически может понадобиться и /opt/bin/sh. Это можно учесть в зависимостях пакета, если, конечно, при установке из /opt/install эти зависимости будут учитываться. Если зависимости не будут учитываться, что хорошо бы распаковывать пакеты из /opt/install в алфавитном порядке, тогда зависимости можно будет соблюсти, назвав пакеты 00utility1.ipk, 02utility1.ipk и т.д.

Пока просто вожу руками в воздухе. Если удастся получить девайс на тест, то внесу посильный вклад. Первая засада с выполнением post/pre-inst скриптов видится в том, что они представляют собой shell-скрипты, начинающиеся shebang'ом #!/bin/sh и к моменту их выполнения /opt/bin/sh ещё может не существовать.

Правильно ли я понимаю то, что пакеты, положенные в папку /opt/install будут распаковываться при каждой загрузке роутера, причём post/pre-inst скрипты в пакетах выполняться не будут?

Скорее всего, в .config билдрута указана CONFIG_SOFT_FLOAT, а тулчейн собран с hardfloat.