Roman_Petrov

По просьбам трудящихся изучил проблему с обновлением на 3.9 с 2.хх. Необходимо проделать следующее: 1. Обновить opkg opkg update opkg upgrade Скорее всего в конце будет ошибка о невозможности обновления syslog-ng из за несовпадение конфигов, библиотек и т.д. 2. Сохраните пути и данные из своего старого конфига по пути nano /opt/etc/syslog-ng.conf (я считаю, что у вас установлен nano - opkg install nano) 3. Пути по opkg install --force-reinstall syslog-ng скорее всего не будет, не даст, поэтому только останется одно-насильно переставить с полной перезаписью: opkg install --force_overwrite syslog-ng 4. Придётся по новой прописывать конфигурацию по пути (я считаю, что у вас установлен nano - opkg install nano) nano /opt/etc/syslog-ng.conf Оригинальный файл: Я изменил на свои настройки: #здесь изменил на журналирование UNIX-stream (удалил unix-dgram("/dev/log"); ) source src { internal(); #здесь поправил на IP адрес моего роутера с 0.0.0.0 source net { udp(ip(192.168.1.1) port(514)); #здесь изменил путь к записи файла журналов на мой диск по моему предпочтению. Вы можете оставить, как есть или свой путь прописать: destination messages { file("/opt/var/log/messages"); #здесь закоментил путь к includes: # put any customization files in this directory # @include "/opt/etc/syslog-ng.d/" 5. Потом проверяем на синтаксис на пожарный случай: syslog-ng -s и если не появилось никаких сообщений (в противном случае смотрим, что выскочило и проверяем где накосячили) запускаем сервис: /opt/etc/init.d/S01syslog-ng start 6. Через некоторое время проверяем, что все пишется с помощью nano: nano /opt/var/log/messages Проверяйте как работает и пишите.

Один в один никак нельзя было, там путь к диску на который пишет у @felcons совершенно другой прописан. И адрес самого себя, роутера не 192.168.1.1 а другой. По хорошему вам надо как то так: @version:3.9 options { chain_hostnames(no); create_dirs(yes); flush_lines(0); keep_hostname(yes); log_fifo_size(256); log_msg_size(1024); stats_freq(0); flush_lines(0); use_fqdn(no); }; .source src { internal(); unix-stream("/dev/log"); }; source net { udp(ip(192.168.1.1) port(514)); }; source kernel { file("/proc/kmsg" program_override("kernel")); }; destination messages { file("/opt/var/log/messages"); }; log { source(src); source(net); source(kernel); destination(messages); }; #@include "/opt/etc/custom-logs.conf" Прописывать надо все вдумчиво, своими ручками, с пониманием что и как делаем, указвывая то что нужно именно нам, а не copy-paste. В веб роутера задать отправку журнала на ремонтный адрес самого себя, т.е 192.168.1.1 Потом только стартовать уже syslog-ng /opt/etc/init.d/S01syslog-ng start

Проблема зарыта здесь скорее всего }; source src { udp(ip(192.168.1.1) port(514)); internal(); unix-stream("/dev/log"); }; source net { udp(ip(192.168.1.1) port(514)); }; И возможно вы не зделали что я писал выше. Сейчас катастрофически не хватает времени, буду благодарен @Lordmaster если пока выложит содержимое своего конфиг файла, чтобы помочь человеку... Хотя в принципе я думаю, что поправить все просто и реально. В ближайшее время описание поправлю в шапке.

Должно быть как то так, у вас также?

Есть одно сомнение. В веб интерфейсе на вкладке журнала вы поставили галку на "отправлять лог на" и выставили адрес самого роутера?

А что у вас раньше стояло здесь: }; source src { udp(ip(192.168.1.1) port(514)); internal(); unix-stream("/dev/log"); }; ? Судя по файлу конфигурации, который вы привели, изменилась его структура. Я уже давненько за отсутствием времени не обновлял пакеты и видимо упустил. P.S. по виду создается впечетление, что теперь нужно, как явно подсказывает сам изначальный текст настроек, работать с: }; source net { udp(ip(0.0.0.0) port(514)); }; Т.е. в него подставлять настройку приема лога с отправляемого виртуально в сеть по настройке журнала роутера...

Ну что ж, будем надеятся, была бы хорошая фича в 2.10....

Ну да, да, эт понятно. Могли бы явно сказать "не мечтайте, ну все , все, забудьте, маркетинг запретил". А так молчат все и думай себе

Не кхотят наверное однако, не очень понятно. Или тихонько ковыряют или заброшено и правда.

Ну что ребят, в теме как то глухо стало ? Монтируем на OPKG пакетах ?

Если вы имеете в виду встроенное расписание, CLI, то: 1) show schedule или конкретного вашего расписания show schedule название_вашего_расписания 2) удалить no schedule название_вашего_расписания Если внешнего, по крону, то смотрите в шапке, там все расписано подробно.

Нет, это не так, приоритет одинаковый. Результатом работы расписания через него тоже будет отданная команда в CLI через ndmq, например, при наступлении времени отключения подается команда "system no led shutdown" и светодиоды в любом случае загорятся. Другое дело, что использование внешнего расписания становиться бессмысленным, когда можно все сделать проще встроенным.

U Zyxel есть одно неоспоримое преимущество перед другими роутерами, он не режет скорость. Всякие другие многие, даже вроде очень приличных даже фирм, грешат этим.

Просто резервация не проблема, это возможно и в текущей реализации- проблема в беспребойном или практически беспребойном доступе к интернету и вообще во функции мультиван как таковой- быть или не быть, вот в чем вопрос

Конюгтивный диссонанс ?

Ну да, так они дорогие, дома такой не захочешь ставить даже при наличии денег, хоть и там много вкусностей, вроде мне оч. актуального бесшовного роуминга wifi на 2 дополнительных точки и т.д. А балансировка и мультиван, это для них как бы практически норма ... Пока так, издалека присматриваюсь

А так разве бывает ?

Да, я думаю вряд ли будут делать данный функционал в домашних девайсах, потому что в таком случае более дорогие профессиональные девайсы становаятся относительно неинтересными. На это косвенно не раз уже намекали.

Голосов вроде потихоньку набирается, посмотрим, как пойдет. Конечно хотелось бы.

Да, выглядит интэресно!

Вот и я об этом, а как же ? Еще ток встроенный коммутатор управления wifi точками доступа и вообще полный фарш. P.D. может вы и правы, пора USG 60W покупать, раз такие "плюшки" хошшца, не всеж в домашний роутер пихать так сказать. Но было б интересно однако.

Сложно вам возразить Ни у кого нет а у нас есть, ну как то так

Что здесь такого необычного? Мне кажется по совремерным меркам это вполне нормальная уже вещь практически. Тем более в роутерах уже реализован частично данный функционал связкой резервирование-ping check. Почему нельзя развивать как то? Ведь до 2.0 прошивок не было и даже резервирования и даже возможности назначить несколько Wan?

Да, конечно, в таком случае понятно, что вы имели в виду.

@vasek00 и @r13 просил же, не клюйте сильно Давайте проголосуем, вдруг все получиться и разработчики сделают. Нет смысла спорить.