Не пойму, как работает RWFS
Цитата: alibek от 02/09/2019, 13:03Подготовил пакет для 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 - переопределяю дефолтные настройки, используемые при сбросе на заводские настройки /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?
Или я что-то не понимаю и делаю неправильно?
Цитата: alibek от 02/09/2019, 14:06Впрочем разобрался. Данные из RWFS сохраняются после перезагрузки, но теряются после сброса на заводские настройки. Хотя файл /etc/default/nvram_default после сброса сохраняется. Я полагал, что RWFS не сбрасывается.
Впрочем разобрался. Данные из RWFS сохраняются после перезагрузки, но теряются после сброса на заводские настройки. Хотя файл /etc/default/nvram_default после сброса сохраняется. Я полагал, что RWFS не сбрасывается.
Цитата: sfstudio от 02/09/2019, 16:11RWFS не средство для внесения постоянных изменений. Вообще изначально появилась как возможность быстро что-то поправить без пересборки по логике на стороне клиента.
Это скорее админский инструмент.
При обновлении/сбросе кнопкой RWFS будет перезаписана из архива. Сама суть кнопки сброс - возврат к заводским дефолтам. А при обновлении важно иметь непротиворечивый инит который тоже лежит на RWFS.
Отрывание сброса RWFS может аукнуться крайне неприятными последствиями при обновлении.
Более того, мы постоянно что-то правим в логике ngix ломая местами совместимость с UI (т.е. на стороне UI правки тоже вносятся) и вносить свои изменения затем обновляться == шанс получить систему в позе лотоса.
В общем я считаю любое вмешательство на уровне "кастомизации" оператором злом как оно есть, если оно не вписано в логику и не является простой крутилкой в итоге.
В HQ добавлен несколько иной инструментарий для базовой кастомизации, причём именно неизменяемой сбросом. Однако это тоже не решение.
Правильное решение == формирование внятных хотелок с пояснением на кой фиг оно нужно для планомерной интеграции в основную кодовую базу с включением по какому-то триггеру.
Ну и важно что бы оно до кучи не противоречило законодательству.
P.S. Ну либо подготовка правок и отдельная кастомизированная ветка выдающаяся нашим сервером обновления для всех клиентов оператора. Т.е. в вашей сети клиенты после первого же обновления получат и все кастомизации под вашу сеть. Это тоже уже возможно у нас вполне. Причём даже для MT уже можно делать. Ессно не бесплатно, особенно не бесплатно для чужого железа типа SNR.
RWFS не средство для внесения постоянных изменений. Вообще изначально появилась как возможность быстро что-то поправить без пересборки по логике на стороне клиента.
Это скорее админский инструмент.
При обновлении/сбросе кнопкой RWFS будет перезаписана из архива. Сама суть кнопки сброс - возврат к заводским дефолтам. А при обновлении важно иметь непротиворечивый инит который тоже лежит на RWFS.
Отрывание сброса RWFS может аукнуться крайне неприятными последствиями при обновлении.
Более того, мы постоянно что-то правим в логике ngix ломая местами совместимость с UI (т.е. на стороне UI правки тоже вносятся) и вносить свои изменения затем обновляться == шанс получить систему в позе лотоса.
В общем я считаю любое вмешательство на уровне "кастомизации" оператором злом как оно есть, если оно не вписано в логику и не является простой крутилкой в итоге.
В HQ добавлен несколько иной инструментарий для базовой кастомизации, причём именно неизменяемой сбросом. Однако это тоже не решение.
Правильное решение == формирование внятных хотелок с пояснением на кой фиг оно нужно для планомерной интеграции в основную кодовую базу с включением по какому-то триггеру.
Ну и важно что бы оно до кучи не противоречило законодательству.
P.S. Ну либо подготовка правок и отдельная кастомизированная ветка выдающаяся нашим сервером обновления для всех клиентов оператора. Т.е. в вашей сети клиенты после первого же обновления получат и все кастомизации под вашу сеть. Это тоже уже возможно у нас вполне. Причём даже для MT уже можно делать. Ессно не бесплатно, особенно не бесплатно для чужого железа типа SNR.
Цитата: sfstudio от 02/09/2019, 16:12/etc/default/nvram_default после сброса сохраняется
Нет. Весь /etc восстанавливается заводской.
/etc/default/nvram_default после сброса сохраняется
Нет. Весь /etc восстанавливается заводской.
Цитата: sfstudio от 02/09/2019, 16:15Собсно я о том, что в 99% случаев после кастомизации оператор напрочь забивает на клиента, а клиент в итоге не может даже самостоятельно обновиться. В итоге сотни тысяч устройств светятся дырами в мир.
Вот как у вас желание зачем-то ограничивать пользователя, так и у нас желание решить наконец проблему выше.
Собсно я о том, что в 99% случаев после кастомизации оператор напрочь забивает на клиента, а клиент в итоге не может даже самостоятельно обновиться. В итоге сотни тысяч устройств светятся дырами в мир.
Вот как у вас желание зачем-то ограничивать пользователя, так и у нас желание решить наконец проблему выше.
Цитата: alibek от 02/09/2019, 16:42Эти CPE используются вовсе не для абонентов, а для собственных нужд (точки доступа для хотспота). Они все работают в режиме моста, в приватной сети, закрытой снаружи и ограниченной изнутри. Пользователь — это сотрудники ТП, у которых должны быть полномочия только на то, чтобы зайти на устройство, посмотреть уровни сигналов клиентов, кикнуть клиента и максимум — выключить/включить радио и сменить канал. Там даже обновления ПО скорее всего не будет, раз уж разработка ветки MT заморожена.
Эти CPE используются вовсе не для абонентов, а для собственных нужд (точки доступа для хотспота). Они все работают в режиме моста, в приватной сети, закрытой снаружи и ограниченной изнутри. Пользователь — это сотрудники ТП, у которых должны быть полномочия только на то, чтобы зайти на устройство, посмотреть уровни сигналов клиентов, кикнуть клиента и максимум — выключить/включить радио и сменить канал. Там даже обновления ПО скорее всего не будет, раз уж разработка ветки MT заморожена.
Цитата: 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-адрес, логин, пароль и все остальные настройки).
Цитата: sfstudio от 02/09/2019, 16:12/etc/default/nvram_default после сброса сохраняется
Нет. Весь /etc восстанавливается заводской.
Сброс кнопкой и сброс из GUI реализованы по разному? После загрузки пакета RWFS, в котором есть модифицированный /etc/default/nvram_default, заводской сброс через GUI не восстанавливает заводские значения (у точки новый IP-адрес, логин, пароль и все остальные настройки).
Цитата: sfstudio от 02/09/2019, 16:58
- обновление последние для MT было меньше недели назад, баги по репортам фиксятся, дыры и критичные правки из HQ время от времени переносятся
- можно узнать зачем вы допускаете до руления АП вообще сотрудников которым нужно что-то ограничивать? Почему опять административные вопросы нужно обязательно пытаться решать техническими средствами?
Ох уж мне эти сменщики каналов... Уже рыдаю не первый год..
В общем на мой взгляд занимаетесь ерундой. Не должны нерадивые сотрудники вообще куда-то доступ иметь. Ни под какими ограничениями и реквизитами.
ВООБЩЕ.
И если зачем режется домашним юзверям я с ооооооооооооооочень большими усилиями, отключениям части ЦНС и т.д. ещё понимаю. То вот этот кейз мне совсем не ясен. Если сотрудник не обезьяна то ему и словестно хватит озвучить что можно, а чего нельзя. А обезьян к железу зачем допускать вообще не пойму. С тем же успехом можно сделать кнопку кайф ему прям на рабочий стол аля сменить канал на рандомный и по 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. Наболело.
- обновление последние для MT было меньше недели назад, баги по репортам фиксятся, дыры и критичные правки из HQ время от времени переносятся
- можно узнать зачем вы допускаете до руления АП вообще сотрудников которым нужно что-то ограничивать? Почему опять административные вопросы нужно обязательно пытаться решать техническими средствами?
Ох уж мне эти сменщики каналов... Уже рыдаю не первый год..
В общем на мой взгляд занимаетесь ерундой. Не должны нерадивые сотрудники вообще куда-то доступ иметь. Ни под какими ограничениями и реквизитами.
ВООБЩЕ.
И если зачем режется домашним юзверям я с ооооооооооооооочень большими усилиями, отключениям части ЦНС и т.д. ещё понимаю. То вот этот кейз мне совсем не ясен. Если сотрудник не обезьяна то ему и словестно хватит озвучить что можно, а чего нельзя. А обезьян к железу зачем допускать вообще не пойму. С тем же успехом можно сделать кнопку кайф ему прям на рабочий стол аля сменить канал на рандомный и по 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. Наболело.
Цитата: sfstudio от 02/09/2019, 17:01Цитата: 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 бы тоже подошло бы например.
Цитата: 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 бы тоже подошло бы например.
