Jump to content

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

Moderators
  • Content Count

    1,066
  • Joined

  • Last visited

  • Days Won

    22

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

  1. Прошивать только через Recovery, т.к. цифровой подписи не будет, ну и обновляться дальше исключительно самостоятельно. Это для тех, кто очень хорошо представляет зачем.

    Хороший пример: вшивание в образ прошивки своего прикладного софта или сборка ядерных модулей, не вошедших в официальный комплект.

    • Thanks 2
  2. 11 час назад, mmc сказал:

    Без понятия, это разработчикам ПО keenetic решать, я лишь озвучил факты:

    Открою секрет: никто не заинтересован в решении вашей задачи больше вас самих. Если нет желания вникать в собственный вопрос, то никто за вас это делать не станет.

     

  3. 29 минут назад, mmc сказал:

    Да и просто здравый рассудок подсказывает, что это не той сложности надстройка, чтобы 80+ мб весить при нормальной реализации.

    Какую реализацию предлагаете?

  4. 54 минуты назад, mmc сказал:

    Может быть, потому что он, как и остальные имеющиеся на рынке хабы, поддерживает только собственные zigbee-устройства Билайн, которых ещё нет в природе?=)

    Нет, не поэтому. Для него и свободные прошивки есть.

  5. 1 час назад, mmc сказал:

    Соответственно, логично как можно скорее выпустить либо необходимое ПО, либо, если изменения в железе всё же потребуются, линейку новых роутеров с поддержкой zigbee и, вуаля, Keenetic может стать законодателем моды в системах умного дома,

    SmartBOX Turbo+ у Билайна выпускается с ZegBee-чипом. IMHO, присутствие этого чипа почти никто не заметил.

  6. 2 минуты назад, Станислав Поветьев сказал:

    То есть это работает только при использование KeenDNS? Если проксирую свой домен то нет?

    Если варианты или планы реализации этого функционала для собственных доменов?

    С собственным доменом логично использовать собственный nginx.

  7. В 09.05.2020 в 15:19, Florun сказал:

    цель - загружаться по лан с возможностью выбора - 

     -облегченная винда - с набором типа лайф сд

    -установка виндов на выбор 

    -установка линуксов на выбор

    Гляньте потом на https://netboot.xyz/ Вероятно, там уже есть всё, что вам надо.  

    netboot.xyz.gif

  8. @dsolo, теоретически может. Точечные запреты включают ~173000 отдельных IP-адресов и если использовать их непосредственно, то кинетик стихами заговорит.

    Поэтому авторы сервисов antifilter.network/antifilter.download выполняют суммаризацию исходных адресов в диапазоны, которых получается уже ~17000, что вполне приемлемо. В процессе суммаризации в диапазоны могут попадать адреса, ранее в список блокировки не попадавшие. Получается, что в некоторых относительно редких случаях через VPN пойдёт «невинный» трафик.

    Кроме этого, часть блокировок ведётся по доменному имени, поэтому авторы названных сервисов сначала разрешают DNS-имена в IP-адреса перед добавлением в общий список. При этом администратор заблокированного домена волен изменять DNS-запись как угодно, например, указать в качестве разрешаемого IP-адреса 8.8.8.8 или вовсе CDN-сеть. В итоге обращения к этим ресурсам пойдут через VPN.

  9. В 21.10.2019 в 18:39, Le ecureuil сказал:

    Пожалуйста, голосуйте, но еще и опишите хотя бы область, где tinc выделялся своими фичами над другими.

    • В отличие от остальных это mesh. Т.е. выход на нужную ноду будет найден через посредников, если напрямую она не доступна. 
    • Нагрузка каналов между двух нод при прямом подключении никак не сказывается на остальных.
    • Присоединять новую ноду можно по коду-инвайту.

    Что не исключает перечисленных минусов, включая тормознутость, невозможность аппаратного ускорения шифров и пр.

     

  10. 5 часов назад, Hotery сказал:

    ну... это не совсем уж так... зависит от сервера (это вот домен на cloudflare).

    Некоторые серверы вольны не следовать стандарту и это очень спорный выбор их авторов. Попробуйте ради интереса зарегистрировать домен с подчёркиванием, у вас ничего не выйдет.

    • Upvote 1
  11. По сути, это Debian'овский пакет без каких-либо правок. Вероятно, подразумевалось, что RTC на больших компьютерах «тикают» всегда в UTC.

    Пока грациозного решения я не вижу, да и для кинетиков оно не сильно актуально.

  12. 33 минуты назад, MDP сказал:

    А вот с этим как-то надо разобраться...каша образуется в syslog -сервере.

    Почему? В syslog-сервер события ложатся последовательно по мере прибывания, просто с разными time stamp'ами. 

    36 минут назад, MDP сказал:

    Зря сделали отсчет от последнего сохранения конфига

    Отнюдь. Это в т.ч. бережёт от следующей циклической ситуации:

    • Имя NTP-сервера не может быть разрешено, т.к. пока не работает DNS,
    • DoH/DoT DNS не может подняться, т.к. сертификаты пока не валидны по времени.
  13. 29 минут назад, Goblin сказал:

    а логи править некрасиво.

    Зря цепляетесь, там затёрт IP-адрес. 

    37 минут назад, yuoras сказал:

    Пусть там будет хоть 1900 год)

    SSL-сертификаты будут невалидны, а так-то да. От железячечки без RTC чего-то серьёзного в плане точности времени  можно не требовать. Если обратили внимание, после ребута роутер достаёт "текущее" время из последнего сохранённого конфига.

  14. 16 минут назад, Goblin сказал:

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

    Сколько раз висеть?:) 

    ~$ sudo grep -i synchronized  /var/log/x.x.x.x-syslog
    …
    Jun  8 04:13:01 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org".
    Jun  9 19:25:41 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org".
    Jun 16 19:25:53 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org".
    Jun 23 19:26:44 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org".
    Jun 30 19:27:16 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org".
    Jul  7 19:27:47 x.x.x.x ndm: Ntp::Client: time synchronized with "1.pool.ntp.org".
    Jul  9 21:47:39 x.x.x.x ndm: Ntp::Client: time synchronized with "1.pool.ntp.org".
    Jul 14 19:41:03 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org".
    Jul 16 16:16:04 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org".
    Jul 23 16:16:15 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org".
    Jul 30 16:16:36 x.x.x.x ndm: Ntp::Client: time synchronized with "1.pool.ntp.org".
    Aug  6 16:16:47 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org".
    Aug 13 16:16:59 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org".
    Aug 20 16:17:10 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org".
    Aug 26 18:58:38 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org".

    Т.е. раз в несколько дней потенциально тратить на ожидание завершения синхронизации времени несколько дополнительных миллисекунд.

     

    Я бы не доверил роутеру автоматический выбор какого-либо внешнего сервиса, будь-то NTP или DNS или ещё что-то, если это потенциально может привнести доселе отсутствующие проблемы.

    • Upvote 1
    • Y'r wrong 1
  15. В 25.08.2020 в 17:26, Goblin сказал:

    В конце статьи:

    Цитата

    Если точность +-0.05 секунды вас устраивает, можно не заморачиваться с выбором серверов, и синхронизироваться с сервером по умолчанию

    Что-то я не уверен, что внутренний MIPS clocksource способен обеспечить такую точность. А при использовании CONFIG_RALINK_CPUSLEEP вообще суточный дрейф до нескольких секунд.

×
×
  • Create New...