Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

Не пойму, как работает RWFS

Подготовил пакет для RWFS, в пакете следующее содержимое:

/etc/default/nvram_default - переопределяю дефолтные настройки, используемые при сбросе на заводские настройки
/etc/nginx/nvram_acl.conf - переопределяю права доступа к настройкам
/etc/web/ - заменяю некоторые страницы веб-интерфейса
/etc/web/adm/management.asp - отключаю показ предупреждений пользователю (в функции showWarning делаю выход, если AUTH_ROLE!=2)
/etc/web/wireless/main.asp - добавляю классы auth-hide-user для блоков, которые нужно скрыть от пользователя
/etc/web/treeapp.asp - скрываю меню wireless/main.asp от пользователя

Загружаю пакет в CPE — все отлично, в веб-интерфейсе все нужное скрыто от пользователя. Настройки без изменений.

Делаю сброс CPE на заводские настройки — настройки сбрасываются, CPE по дефолту настроен именно так, как мне нужно. Но веб-интерфейс вернулся к исходному виду (у пользователя доступны wireless/main).

Загружаю пакет повторно —веб-интерфейс приводится к нужному виду, но только до следующей перезагрузки или сброса настроек.

Я так понял, что /web/* перезаписывается только при загрузке RWFS, но затем эти изменения не сохраняются в NVRAM. А как в таком случае вносить постоянные изменения в веб-интерфейс? В /etc/web после перезагрузки загруженное содержимое сохраняется. При каждой перезагрузке перезаписывать его в /tmp/web?

Или я что-то не понимаю и делаю неправильно?

Впрочем разобрался. Данные из RWFS сохраняются после перезагрузки, но теряются после сброса на заводские настройки. Хотя файл /etc/default/nvram_default после сброса сохраняется. Я полагал, что RWFS не сбрасывается.

RWFS не средство для внесения постоянных изменений. Вообще изначально появилась как возможность быстро что-то поправить без пересборки по логике на стороне клиента.

Это скорее админский инструмент.

При обновлении/сбросе кнопкой RWFS будет перезаписана из архива. Сама суть кнопки сброс - возврат к заводским дефолтам. А при обновлении важно иметь непротиворечивый инит который тоже лежит на RWFS.

Отрывание сброса RWFS может аукнуться крайне неприятными последствиями при обновлении.

Более того, мы постоянно что-то правим в логике ngix ломая местами совместимость с UI (т.е. на стороне UI правки тоже вносятся) и вносить свои изменения затем обновляться == шанс получить систему в позе лотоса.

В общем я считаю любое вмешательство на уровне "кастомизации" оператором злом как оно есть, если оно не вписано в логику и не является простой крутилкой в итоге.

В HQ добавлен несколько иной инструментарий для базовой кастомизации, причём именно неизменяемой сбросом. Однако это тоже не решение.

Правильное решение == формирование внятных хотелок с пояснением на кой фиг оно нужно для планомерной интеграции в основную кодовую базу с включением по какому-то триггеру.

Ну и важно что бы оно до кучи не противоречило законодательству.

P.S. Ну либо подготовка правок и отдельная кастомизированная ветка выдающаяся нашим сервером обновления для всех клиентов оператора. Т.е. в вашей сети клиенты после первого же обновления получат и все кастомизации под вашу сеть. Это тоже уже возможно у нас вполне. Причём даже для MT уже можно делать. Ессно не бесплатно, особенно не бесплатно для чужого железа типа SNR.

 /etc/default/nvram_default после сброса сохраняется

Нет. Весь /etc восстанавливается заводской.

Собсно я о том, что в 99% случаев после кастомизации оператор напрочь забивает на клиента, а клиент в итоге не может даже самостоятельно обновиться. В итоге сотни тысяч устройств светятся дырами в мир.

Вот как у вас желание зачем-то ограничивать пользователя, так и у нас желание решить наконец проблему выше.

Эти CPE используются вовсе не для абонентов, а для собственных нужд (точки доступа для хотспота). Они все работают в режиме моста, в приватной сети, закрытой снаружи и ограниченной изнутри. Пользователь — это сотрудники ТП, у которых должны быть полномочия только на то, чтобы зайти на устройство, посмотреть уровни сигналов клиентов, кикнуть клиента и максимум — выключить/включить радио и сменить канал. Там даже обновления ПО скорее всего не будет, раз уж разработка ветки MT заморожена.

Цитата: sfstudio от 02/09/2019, 16:12

 /etc/default/nvram_default после сброса сохраняется

Нет. Весь /etc восстанавливается заводской.

Сброс кнопкой и сброс из GUI реализованы по разному? После загрузки пакета RWFS, в котором есть модифицированный /etc/default/nvram_default, заводской сброс через GUI не восстанавливает заводские значения (у точки новый IP-адрес, логин, пароль и все остальные настройки).

  1. обновление последние для MT было меньше недели назад, баги по репортам фиксятся, дыры и критичные правки из HQ время от времени переносятся
  2. можно узнать зачем вы допускаете до руления АП вообще сотрудников которым нужно что-то ограничивать? Почему опять административные вопросы нужно обязательно пытаться решать техническими средствами?

Ох уж мне эти сменщики каналов... Уже рыдаю не первый год..

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

ВООБЩЕ.

И если зачем режется домашним юзверям я с ооооооооооооооочень большими усилиями, отключениям части ЦНС и т.д. ещё понимаю. То вот этот кейз мне совсем не ясен. Если сотрудник не обезьяна то ему и словестно хватит озвучить что можно, а чего нельзя. А обезьян к железу зачем допускать вообще не пойму. С тем же успехом можно сделать кнопку кайф ему прям на рабочий стол аля сменить канал на рандомный  и по ssh + sshpass прям в скрипте это и проворачивать. Даже в UI не надо заходить и вообще ему знать что там у желеки UI есть.

Скрипт с правами только на исполнение. Или за 15 минут наклёпанная прикладуха под винды умеющая 3,5 команды по ssh для реализации собсно описанного выше. И нефиг мучать железку и её UI.

Один раз написать для себя простейшую прикладуху для автоматизации таких вещей аля wl scan/wl stalist и т.д. и всё. Никаких доступов никаких сотрудников никаких даже потенциально возможных им что-то лишнего крутануть.

Чем провинились роутеры что их колечат без остановки и создают себе же проблемы кастомизациями которые не нужны вообще.

За время пока вы с UI ковыряетесь в части выясняя как обкромсать, как rwfs заюзать и т.д. уже можно было 5ть прикладух написать делающих то что надо по ssh и выводящих красивый гуй.

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

Ну не стоит овчинка выделки с кастомизациями на стороне АП/роутера, тем более что все эти кастомизации в итоге надо за собой таскать и модифицировать если на нашей стороне что-то поменялось.

А вот cli сделан как прослойка что бы как раз изменения у нас внутри не сказывались на взаимодействии с внешними прикладухами оный юзающих.

А ssh обеспечивает должный уровень безопасности при этом не имеет проблем как UI при множественном доступе (о котором вы репортили). И потенциально гораздо безопаснее держать ssh открытый во вне с длинным паролем, чем UI. Ибо вероятность ограсти дырку в dropbear юзаемую без авторизации на фоне потенциально возможных уязвимостей в nginx составляет 0,001%.

Один раз стоит сделать для себя инструмент (не только для работы с wive годиться однако) и не придётся вечно какими-о кастомизаторствами заниматься. И от обезьян помогает. Они вообще в итоге не адресов не знают ни логина с паролем.

P.S. Наболело.

Цитата: alibek от 02/09/2019, 16:47
Цитата: sfstudio от 02/09/2019, 16:12

 /etc/default/nvram_default после сброса сохраняется

Нет. Весь /etc восстанавливается заводской.

Сброс кнопкой и сброс из GUI реализованы по разному? После загрузки пакета RWFS, в котором есть модифицированный /etc/default/nvram_default, заводской сброс через GUI не восстанавливает заводские значения (у точки новый IP-адрес, логин, пароль и все остальные настройки).

А если после этого ещё раз сбросить? =)))

При сбросе оно затянет параметры из вашего файла дефолтового, и затрёт RWFS после ребута RWFS востановится с RO раздела и от ваших дефолтов не останется ни следа.

Т.е. сработает это ровно один раз.

Вся эта эпопея называется "мы не ищем лёгких путей".

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

Не ну раз хочется заниматься удалением гланд через одно место, то хоть делать это минимально травматично. =)

Слейте ветку, поправьте что надо прямо в ней и вперёд.

Сразу грю, никакие репорты или всплывшие проблемы по самосбору не принимаем. Как и консультации на тему что и где в ветке править мы не даём. Всё на свой страх и риск.

Но я бы на вашем месте сделал бы по предложенному сценарию выше и вообще бы забыл о необходимости каких-то модификаций на стороне ПО в будущем. И для HQ бы тоже подошло бы например.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: