Jump to content

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

Moderators
  • Posts

    1,089
  • Joined

  • Last visited

  • Days Won

    22

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    netboot.xyz.gif

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

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

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

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

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

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

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

     

  8. @Max Z, тут красивого решения нет. Изначально PID-файлы должны находиться в tmpfs и теряться при внезапной перезагрузке.

    Наличие pid-файла без процесса говорит лишь о том, что сервис не был остановлен правильно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  13. 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
  14. В 25.08.2020 в 17:26, Goblin сказал:

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

    Цитата

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

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

  15. 17 минут назад, Сергей С сказал:

    Использую debian на кинетике гига 3. Недавно подключил у провайдера высокоскоростной интернет. Проверка на сайте speedtest.net около 300 мбит. Но при проверке утилитой speedtest из debian на кинетике скорость не выше 100 мбит. Может быть какое нибудь ограничение в скорости подключения в debian или провайдер каким то образом обманывает проверку на сайте speedtest?

    Роутер предназначен для работы с транзитным трафиком. Полагаться на показания скорости, намерянные с самого роутера не надо: CPU роутера слишком слаб для этого.

×
×
  • Create New...