gravy_train

Возможно, подойдет строка "components" из вывода "show version" (или тот же вывод в слитом self-test -> "<components>" ) ?

1.) Благодарю, логика стала понятнее. Пожелание к разработчикам: по возможности скорректировать описание в руководстве по CLI, заменив "установки" на "обновления" в описании команлы "components list" (сейчас так: "Переключиться на выбранную песочницу и отметить для установки все компоненты") 2.) "В выбранном" - вы имеете в виду установленный любым предыдущим вызовом "components list <sandbox>" в этой CLI-сессии? Подскажите, пожалуйста, влияют ли на этот выбор предыдущие вызовы "components auto-update channel <channel>" ? 3.) Мне не удалось найти команды, обратной commit (чего-то вроде "discard") . Из вашего опыта, опасно ли не выполнять "components commit" после "components list <sandbox>"? Стоит ли прерывать CLI-сессию, если дальнейший "commit" нежелателен? 4.) Какова логика работы "components commit в этом случае (не real case, просто для понимания логики и ограничений работы) : components list draft components commit ...Позднее, проверив нужное, пытаемся вернуться на stable: components list stable ...сессия бал прервана. Переподключаемся и вводим: components list components install exfat components commit Пожалуйста, подскажите, из какого канала будет установлен "exfat" : из draft или из stable ? 5.) <sandbox> и <channel> в документации - это названия для одного и того же (разница в терминах вызвана историческими причинами)? Или между ними есть различия? 6.) Подскажите, какой смысл имеет ключ "force" команды components check-update для случая "отдельностоящего" роутера и мудульной системы? В руководстве указано, что force = "Постоянно проверять наличие обновлений." Что может значить "постоянно" в этом конкексте (увеличение числа попыток и таймаутов, что-то другое )?

Прошивка 5.1.3 stable 1) Скрин 1 : в раскрывающемся списке портов http отсутствует поддерживаемый CrazeDNS TCP:591 (линки : первый; второй; третий; четвертый) Если раскрывающийся список портов заполнен по логике "все. что поддерживаются в режиме Через облако", то, возможно, стоит добавить порт в список (или, если это имеет какие-то негативные последствия, оговорить в доках) ? 2) Скрин 2: порты http/https не "из списка", указанные при помощи cli, вообще никак не отображаются в web. Понятно, что не все из cli стоит переносить в web. Но, возможно, порты управления, входят в число того, что стоит показывать в web в любом случае ? Как вариант: a) дать возможность вводить любой допустимый порт, показывать его в списке, но при сохранении предупреждать, что он не поддерживается CrazeDNS в режиме "Через облако"; b) если порт не совпадает с (предустановленным) списком, то оставлять список пустым, но показывать коммент под ним.

кмк, другая сторона того же вопроса. Набор действия для иллюстрации вопроса: есть единственное подключение к интернет. Создаем свою политику, в ней выбираем это единственное имеющееся подключение. Добавляем в политику клиентов. Ожидается: не встречалось каких-то упоминаний того, что "Политика по умолчанию" чем-то уникальна. Поэтому, создавая в веб-конфигураторе такой же объект, с теми же свойствами, считаем его идентичным "Политике по умолчинию". Реально: нет. Статическая запись для my.netcraze.net добавляется только в "Политику по умолчинию", но отсутствует во, вроде бы, визуально такой же (в веб-конфигураторе) созданной вручную политике. Результат: при потере роутером соединения с интернет клиенты, включенные в созданную политику, не смогут разрешить имя my.netcraze.net (ну и зайти в веб-конфиг по этому адресу) Скрины: 1) "Политика по умолчанию" 2) Созданная политика, у которой в веб-конфигураторе, вроде, нет отличий от дефолтной. 3) В чем разница (self-test или 'show dns-proxy')

Проясните, пожалуйста, вопросы по докам CLI: В мануале по CLI 1.169 (29.07.2026) описано, что - components list = "Переключиться на выбранную песочницу и ОТМЕТИТЬ для установки ВСЕ компоненты" - components install = "ОТМЕТИТЬ компонент для последующей установки" 1) Как две эти последовательные команды (components list + components install) должны работать? 2) Что должен делать install после list ? Пример Варианты: а) "install" после "list" отмечает для установки ТОЛЬКО указанный компонент, снимая отметки со ВСЕХ остальных, отмеченных при помощи list ? б) "install" после "list" обновит все компоненты, но "включенными" останутся только ранее выбранные компоненты? в) как-то иначе ? 3) ссылка "существуют команды, которые выводят список всех доступных компонентов (components list)" Так "components list" - все-таки выводит список или помечает (pending) обновление всех компонентов? 4) Как все это сочетается с источник: "Поэтому, ПЕРЕСБОРКА NDMS необходима даже при добавлении или удалении одного компонента системы." На практике. Что конкретно мне нужно сделать в CLI, чтобы добавить 2 компонента: - "Утилиты для файловой системы ext" - "Утилиты для файловой системы exFAT" ?

Спасибо, теперь понятно. Если кому еще интересно, как это реализовано в wg-easy: Feature/client firewall filtering - #2418#2418 1) А как, по вашему мнению, это должно выглядеть? Только пресеты ? Поля ввода как в wg-easy ? Пресеты + поля ? (пресеты позволяют сделать "одной кнопкой", но не позволяют указать, например, "интернет и вот этот хост из локалки" или "вот эту и эту подсеть") 2) Насколько я понимаю, при попытке в wg-easy сделать "только интернет" или "разрешить локалку и интернет" под капотом, кроме очевидного, будет создана - либо цепочка правил iptables, запрещающих доступ к приватным (по RFC) подсетям; - либо, наоборот, цепочка разрешающих правил для всех публичных подсетей + одной (указанной) "локалки" Это я к тому, что (кроме неизбежного "оверхеда" таких перечислений) могут потребоваться доп. костыли для 198.51.100.0/24

это стоковая возможность wg. По другому, без своей серьезной обертки/надстройки над wg, не получится. А каковы были ваши ожидания? Не в смысле "как реализовано", а смысле "что" ожидали/хотели увидеть? (сейчас рискуем получить ответ типа "десятки клиентов никто не обещал, а для 1-5 - пересоздай конфиг руками: удалить-создать+передать клиенту") Вот если не "сами", а "автоматом", кмк, было бы важно.

+ AllowedIPs - это вообще не про ограничения. А просто поле при создании конфига пиров. Возможно, интересно было бы вообще автоматизировать/синхронизировать добавление правил firewall при задании/изменении/удалении AllowedIPs пиров. У этого были бы шансы стать killer-фичей. Потребность реально ограничивать доступ есть при запросах хоть чуть сложнее, чем "всем можно всюду". "Топорность", кмк, здесь вызвана не реализацей в kn/nc, а просто использованием только "+-стоковых" возможностей wg. То есть, сделать то, что вы сказали ("рулить этим через firewall") - полноценная, весьма нехилая фича, никем из конкурентов, вроде, еще не реализованная. Сложности: если даже сказать "А", то придется говорить и "Б". Т.е. еще и давать либо удобный, продуманный gui для контроля/исправления таких правил frirewall для пиров (в идеале, еще и с "картой"/overview "кому куда предоствлен доступ". Эх, мечты, мечты) , либо полный CLI-доступ к тому, чем это реализовано (iptables и т.п.). Во втором случае - имхо, не выстрелит...

С учетом изменений вокруг, не стоит ли скорректировать "политику партии" в отношении доступа к веб-интерфейсу по SSL ? Сейчас применяется логика, принятая более 10 лет назад: "если SSL-сертификат от LE не получен, то лучше никакого https, чем костыли". Это приводит к тому, что, в случае проблем с сертификатом или вообще доступом в интернет (при уже полученных и действующих сертификатах на дефолтный и выбранные домены) ни удаленно, ни даже локально (прямым проводом из home-сети) в веб-интерфейс по https не попасть. У проблемы 2 стороны: 1.) Каков план на случай, если по каким угодно причинам доступ к LE затруднен для большинства владельцев роутеров ? 2.) Текущие проблемы реализации указанной логики на данный момент, стали, кмк, как минимум, сопоставимы с выигрышем от бескомпромиссного решения "лучше никакого, чем".

Пожалуйста, подскажите: 1.) Какова цель данных изменений ? 2.) Учитывают ли эти изменения ранее описанные сценарии и возникшие в них проблемы ? локальный доступ по https 5.1: отсутствие статической A-записи для CrazeDNS-домена Подключение к webUI по https Системная ошибка в браузере при обращении к 78.47.125.180

спасибо за обновление справочника по CLI. Не планируется ли добавить в доки указанное ниже ? 1.) Появившееся в стабильной 5.1.1: ipv6 access-list * media {name} partition {partition} check media {name} partition {partition} format {type} tools ping {host} dont-fragment 2.) Отсутствующее (но имеющее практический смысл) show cloud show cloud ndmp link show cloud ndmp status cloud ndmp link delete show device-list show system mode

Это на FF 149.0.2. В большинстве ситуаций все именно так, как вы сказали: "с задержкой, но всё отображает." Но иногда (примерно 1 раз из 5-10) получается описанное выше. От видимой нагрузки cpu/memory не зависит. Других закономерностей пока не уловил.

Прошивки : 5.0.12 и 5.1.1 stable Браузер : FF 149.0.2 Проблема: в webUI криво работает флаг "Обновлять в реальном времени". Периодически после очистки журнала из веб-морды он (журнал) "подтягивает" еще несколько десятков строк, которых до этого не отображал, несмотря на установленный флаг "Обновлять." При этом, того, что он подтянул, фактически в логе уже нет. Если в этот момент скачать лог, то в нем будет единственная строка : "ndm: Core::Syslog: the system log has been cleared." Хотелось бы уточнить у знающих: для чтения лога "в реальном времени" используется, грубо говоря, опрос с небольшим интервалом ? inotify ? оба метода ? Если опрос, то как проверить его интервал?

это не так: