Sergey Zozulya

Не совсем понял. Т. е. доступ будет только из локальной сети? Мне это не подходит, частенько нужно снаружи посмотреть. Но лучше уж так, чем никак.

@zyxmon все, что там нашел во всех тикетах, прочитал, поэтому тут и задаю вопрос. У меня IP всегда разные, поэтому такая защита не подходит. Там везде рекомендуют настраивать защиту через HTTP сервер, но нам это тоже не подходит.

Можно ли как-то защитить доступ к netdata снаружи? Сейчас достаточно знать имя и порт - калитка открыта, что довольно неприятно.

Атака на системы с rTorrent для скрытого майнинга криптовалюты http://opennet.ru/48177/

Может есть возможность v1.9.0 собрать?

Назрел вопрос, когда мы уже сможем вовсю влиться в бета-тест нового приложения? В обозримом хоть будущем?

@a5325a нынче пароль, вроде как, keenetic

rtorrent тоже не без недостатков. Например, он не поддерживает UPnP/NAT-PMP/NAT traversal (придется открывать порты вручную, что для домашнего роутера может вызвать много вопросов у пользователей) и IPv6 (в свете оживления этой темы у разработчиков может быть важным).

Да, конечно, я ошибся. Смотреть надо колонку "Загружать".

@KyzjaTV и когда кнопку нажмете, смотрите колонку Приоритет, там будет понятно.

Так заработало, спасибо!

В NetworkManager лишь плагин, из CLI та же самая ошибка: sstpc --password=password --user=user sstp_server_hostname **Error: HTTP handshake with server failed, (-1) С какими параметрами он у вас вызывается?

SSTP-сервер на Keenetic'е, пробую подключиться с помощью клиента SSTP-Client для Linux - http://sstp-client.sourceforge.net/ Какие бы настройки не пробовал, в логах те же ошибки. На роутере всегда это: В syslog такое (главную проблему выделил): Настройки SSTP-Client (это по умолчанию, кроме Ignore certificate warnings. Другие разные комбинации галок тоже пробовал): В то же время с помощью клиента VPN Client Pro для Android подключается с настройками по умолчанию и прекрасно работает, только имя и пароль ввести: @Le ecureuil в чем может быть проблема у SSTP-Client?

Кстати, вам спасибо! Эта отладка выявила очень неочевидную проблему.

Тоже к этому склоняюсь. Но проверить бы еще у кого-нибудь. Если повторится, то либо исправлять как-то (к кому вообще с этим?), либо забить (в моем случае больше не буду использовать кириллицу в конце путей).

Предложенная @sergeyk отладка вот что прояснила: [2018/02/06 19:50:31] minidlna.c:1232: warn: Starting MiniDLNA version 1.2.1. [2018/02/06 19:50:31] minidlna.c:437: warn: ret (0) != media_path->types (2), path = "/tmp/mnt/My Passport/Videos/TV Shows/Блудливая Калифорния" [2018/02/06 19:50:31] minidlna.c:472: warn: New media_dir detected; rebuilding... [2018/02/06 19:50:31] minidlna.c:1273: warn: HTTP listening on port 8200 Парсер посчитал, что это новый параметр media_dir в конфиге, хотя это не так. В базе до старта minidlna хорошо видно, что эта папка уже просканирована и имеет корректный TIMESTAMP = 2: Убрал этот media_dir из конфига, история повторилась теперь уже с Теория большого взрыва. Убрал и ее, только тогда ресканы базы сразу после старта minidlna прекратились. Напрашивается только один вывод - minidlna по каким-то причинам не дружит с кириллическими символами в путях media_dir. @TheBB @zyxmon @кто-нибудь-еще не могли бы подтвердить (или нет), когда время будет?

@TheBB вот спасибо, как доберусь, проверю и отпишу.

@TheBB @zyxmon может вы что толковое подскажете по этой проблеме?

Идею понял, но это только если попросить мэйнтейнеров Entware собрать тестовый пакет с такой отладкой. Самому мне до этого не дотянуться.

Начал разбираться с тем, что рескан всей базы стартует при любом запуске minidlna, достаточно даже просто сделать: /opt/etc/init.d/S90minidlna stop /opt/etc/init.d/S90minidlna start Включил debug-логи, но это ничего не прояснило, рескан стартует буквально сразу же после старта: [2018/02/02 20:11:13] minidlna.c:1231: warn: Starting MiniDLNA version 1.2.1. [2018/02/02 20:11:13] minidlna.c:471: warn: New media_dir detected; rebuilding... Полез смотреть minidlna.c, но квалификации разобраться не хватило. Судя по выводу New media_dir detected; rebuilding... в лог и этому куску кода из minidlna.c: переменной ret присваивается 1, а это значит, что minidlna при старте обнаруживает новую директорию (параметр media_dir в конфиге) и инициирует рескан. Проблема в том, что никаких новых директорий в конфиге на самом деле нет. У меня в конфиге 5 параметров media_dir, вот в таком виде (где три точки уже идет реальный путь до каталога): media_dir=V,/tmp/mnt/... media_dir=V,/tmp/mnt/... media_dir=/tmp/mnt/... media_dir=V,/tmp/mnt/... media_dir=V,/tmp/mnt/... Почему в итоге ret = 1, не докопался. Если кто может подсказать, в чем проблема (ждать довольно долго при каждой перезагрузке роутера напрягает), дайте знать. Могу предоставить базу или другую необходимую информацию. Хочется это победить. UPD. Проверил созданную базу после остановки minidlna. Все пять каталогов есть в таблице DETAILS, при этом TIMESTAMP у них корректный.

Уже такое писали и не раз. Ответ разработчиков - так и задумано.

С этими модемами часто такое.

Что-то поменялось?

Тогда вопрос с миниатюрами закрыт. Спасибо.

Вот оно что, теперь ясно, действительно не понял этот параметр. Правильно тогда понимаю, что отключить показ миниатюр у тех файлов, в которых она встроена в контейнер, нельзя никакими настройками?