Jump to content

gvan

Forum Members
  • Posts

    210
  • Joined

  • Days Won

    2

Everything posted by gvan

  1. Да, если софта пару-тройку пакетов. Но у меня побольше. Да и вспоминать, что нужно поставить, а что нет, куда положить нужные данные и т.п., не хочется. А по поводу изменений релизов, вообще не вижу проблем. Ведь указанный скрипт запускается каждую ночь и мы всегда получаем полный свежий слепок системы, причем в новом архиве. У меня он на данный момент занимает менее 20Мб. А обновление того же самого софта opkg update/upgrade также можно добавить в cron. Но каждый волен выбирать сам
  2. У меня это какой-то полубинарный файл. Если сделать: cp /flash/startup-config /opt/tmp/test.txt То вначале файла test.txt какая-то каша. Да и вариант с ndmq -p более универсальный (вдруг захочется сохранить в третьем файле результат вывода каких-либо других CLI команд). Да, ничто не мешает изменить переменную BACDIR на BACDIR=/opt/etc/ Но у меня, например, кроме конфигов есть еще БД, которые лежат вне /opt/etc. Также мой вариант, если вдруг умрет флэшка, позволяет за 15 минут развернуть новую entware, без танцев с бубном и без каких-либо установок дополнительных программ. Рассказываю как. Есть переносимая флэшка, на которой развернут пустой entware. Ну, не совсем пустая. На ней есть fdisk, e2mkfs (и прочие дисковые утилиты). Запускаю entware с нее. Создаю раздел на новом диске, форматирую его, запускаю распаковку созданного в первом сообщении .tgz на новую флэшку (еще надо будет создать var/log и tmp, т.к. в архиве их нет). Все. Можно монтировать entware на новой флэшке. Уже несколько раз подобным образом переезжал. Если нужна более подробная информация по шагам, то могу расписать и дополнить первое сообщение.
  3. Ясно А "каждая нужда" какими примерно событиями определяется (чтобы для себя понимать насколько часто это может происходить и от чего это зависит)?
  4. Т.е. при возникновении таких сетевых событий делается flush всех правил и цепочек без исключений? Или же какие-то служебные все-таки остаются? Если есть возможность хака в виде создания некой своей кастомной цепочки (например, с именем, начинающимся с определенных символов), то можно в ней уже учитывать трафик. Ну естественно при этом эта цепочка не должна чиститься.
  5. А чем определяется частое передергивание правил? Использую collectd c плагином iptbales, который напрямую общается c netfilter для получения значений счетчиков. Для отрисовки трафика определенных клиентов через iptables создаю и маркирую правила. Соответственно, в свой скрипт /opt/etc/ndm/netfilter.d/filter.sh добавил код (правила). Например: [ "$table" != "filter" ] && exit 0 # check the table name /opt/sbin/iptables -I OUTPUT -p ICMP -s 192.168.1.0/24 -m comment --comment "ICMP" -j ACCEPT /opt/bin/logger -t "iptables" "Rule for collectd added" Но по syslog вижу, что этот код часто выполняется. Скорее всего, это происходит, когда подключаются/отключаются клиенты wi-fi, порты роутера. При этом и обнуляются счетчики на данном правиле. Это не очень положительно сказывается на точности учета трафика (если, особенно период опроса счетчиков большой). Можно ли этого как-то избежать?
  6. На форуме уже пару раз возникал вопрос о периодическом бэкапе конфига. Но не менее обидно потерять свои наработки в entware. В данной статье выложен простой скрипт, который запускается по cron и сохраняет содержимое /opt, конфига и прошивки. Есть возможность отказаться от бэкапа любого из указанных компонентов. Резервная копия прошивки не сжимается архиватором, т.к. файл прошивки и так уже максимально упакован. Старые архивы в соответствии с установленным интервалом времени удаляются. Предварительно необходимо изменить настройки скрипта в разделе конфигурационных параметров. Данная резервная копию может использоваться как для полного, так и частичного восстановления entware. Информация об этом дана в конце статьи. Для нормальной работы cron entware д.б. установлена на раздел с файловой системой ext2/ext3/ext4. Устанавливаем и запускаем cron opkg install cron /opt/etc/init.d/S10cron start В каталоге /opt/etc/cron.daily создаем файл backup и размещаем в нем следующий код: Делаем файл backup исполняемым: chmod +x backup В данном скрипте предусмотрено исключение определенных каталогов (например, tmp, var/log). Бэкап производится на другой диск (флэшку). Если будете бэкапить содержимое на этот же диск, не забудьте добавить каталог с архивами в исключение. Иначе скрипт будет выполняться, пока не закончится место на диске. Архивы хранятся 8 дней (переменная DAYSTOR). Новый архив конфига создается только в том случае, если произошло его изменение. При этом не учитывается MD5 и строка "clock date". Информация о ходе бэкапа передается в syslog. Если эта информация нужна, и syslog у вас еще не настроен, то рекомендую его включить, как указано в соответствующей статье. Если не нужна, то ничего делать не нужно. Как минимум в данном коде вам необходимо изменить переменные BACSTORDIR и BACNAME. Всё. Каждую ночь будет сохраняться свежая копия entware и конфига роутера. Использование сохраненной резервной копии. По восстановлению конфига роутера вопросов возникнуть не должно. Распаковываем файл командой gzip, копируем его себе на устройство и далее его можно загрузить в роутер через соответствующий пункт в веб-интерфейсе ("Система-Файлы"). Пример команды для распаковки конфига: gzip -d config-2016-11-29.gz Таким же образом можно воспользоваться сохраненным файлом прошивки. Теперь о том, для чего делается резервная копия entware и как можно использовать полученный архив. Возможны случаи, когда мы наставили большое количество пакетов (какие не помним, они начали работать некорректно и т.п.), но точно знаем что хотелось бы вернуться на состояние "как было пару дней назад". Или еще хуже в результате экспериментов удалили системные файлы entware, полностью нарушив ее работу. Или вышел из строя диск (флэшка). 0. Подготовительная стадия. Предполагается, что у нас есть чистая entware, используемая для функции восстановления. Например, отдельная флэшка или раздел на диске/флэшке (далее диск восстановления - ДВ). На нем предварительно установлены утилиты для работы с диском (создания разделов, форматирования файловой системы): opkg install fdisk tune2fs e2fsprogs Через веб-интерфейс в разделе "Приложения-OPKG" подключаем entware с ДВ. 1. Создание раздела на диске. В моем примере восстановление entware будет выполняться на второй раздел флэшки (диск /dev/sda). ДВ находится на первом разделе флэшки. Используемая файловая система для entware - ext2 Создаем раздел диска через fdisk. Если на новом диске есть какие-то не нужные разделы, то их также можно удалить (см. help по команде "m"). 2. Форматирование раздела. Создаем ФС ext2 с меткой KINGSTON2 и UID (для удобства работы c OPKG) 00000000-0000-0000-1111-000000000002: Создаем каталог /tmp/mnt/KINGSTON2 и монтируем вновь созданную ФС: mount /dev/sda2 /tmp/mnt/KINGSTON2 Предполагаем, что архив entware уже находится на ДВ в /opt/tmp/king3-2016-12-06.tgz 3. Восстановление и запуск entware. Запускаем восстановление entware и создаем каталоги, которые мы не включили в резервную копию: Запускаем восстановленную entware в веб-интерфейсе. Примечание: Пункты 0-2 можно пропустить, если раздел для entware создается на каком-то другом устройстве (например, ПК). Также для простоты, используя midnight commander (opkg install mc), можно в архиве entware просмотреть интересующие нас файлы или скопировать их в какой-то другой каталог. Возможно извлечение и просмотр отдельных файлов и через команду tar.
  7. Collectd - это простой и легкий сервис, который собирает данные о производительности системы и приложений и предоставляет механизмы для хранения полученных значений в различных форматах, например в RRD файлах. Сбор статистики производится с помощью подключаемых плагинов. В данном примере будет рассмотрена возможность использования плагина для работы с SNMP (получения данных со встроенного в роутер SNMP-сервера), плагина для работы с дисковой подсистемой и плагина для записи полученных данных в RRD БД. Задача collectd только собирать данные. Отрисовка графиков производится с помощью rrdcgi, который позволяет использовать некое подобие шаблонов, упрощающих формирование html-файлов и облегчающих процесс их настройки. Создание графиков выполняется только по запросу пользователя (при обращении к веб-скриптам), соответственно, нагрузка на систему незначительная. До графических возможностей netdata, недавно включенного в состав готовых пакетов, конечно, далеко, но здесь в первую очередь обеспечивается задача долговременного хранения данных статистики. Примеры отображения полученной информации: Этим возможности программы не ограничиваются. Существует дополнительные плагины, открывающие другие варианты сбора статистики (в том числе с определенных сервисов). Например, плагин iptables, позволяющий собирать данные по помеченным цепочкам правил (в планах отрисовывать графики по определенным клиентам wi-fi), плагин ping, формирующий данные по задержкам до определенного хоста и т.п.. Также есть возможность формирования нотификаций при достижении определенных значений полученной информации с помощью плагина threshold. Этап 1. Формирование данных статистики. Включаем через CLI поддержку snmp на роутере: service snmp system configuration save Ставим в entware SNMP-утилиты и проверяем работу протокола SNMP на роутере: opkg install snmp-utils snmp-mibs snmpwalk -c public 127.0.0.1 . >/opt/tmp/snmp.txt Если все прошло успешно, то должен создаться файл, содержащий все возможные OID роутера. Распаковываем содержимое приложенного архива files.zip во временную папку и устанавливаем collectd c необходимыми для нашего примера плагинами: opkg install collectd collectd-mod-logfile collectd-mod-disk collectd-mod-snmp collectd-mod-rrdtool Создаем каталог для rrd файлов: mkdir -p /opt/var/lib/collectd/rrd Копируем файл кастомных типов из архива share/custom-types.db в /opt/share/collectd Заменяем конфигурационный /opt/etc/collectd.conf на файл conf/collectd.conf Некоторые пояснения по конфигурационному файлу. Вначале указываются рабочие каталоги, а также подключается файл с кастомными типами (в нем описывается хранение характерных для keenetic данных: оперативной памяти и CPU). Далее указывается интервал (в примере 180 сек.) сбора статистики для плагинов (в настройках плагина snmp д.б. такой же интервал). Изменение интервала в дальнейшем допускается только при удалении всех rrd файлов (обнуление статистики). Но также можно выполнить их тюнинг вручную. В противном случае получим некорректную статистику. Плагин logfile нужен для записи журналов самого сервиса collectd. В нем и будем смотреть возникающие при настройке и работе сервиса ошибки. Плагин disk пишет информацию о работе выбранных дисков (разделов). В примере указаны только хардварные диски (производительность отдельных разделов не учитываю, т.к. у меня в этом необходимости нет). Информация начинает записываться в БД через 3*интервал_опроса после запуска collectd. Плагин rrdtool собственно и обеспечивает сохранение данных в БД RRD. Размер каждого созданного файла БД фиксированный, информация записывается по кругу, переписывая устаревшие данные. Наибольшая точность данных получается для статистики за последние сутки (в примере точность до 3 минут). Данные за неделю, месяц и год усредняются и хранятся с большими интервалами времени. Но при этом существует возможность считывания максимальных значений статистики, которые были в указанные периоды (эти данные не усредняются, и в отрисовке графиков мы их также будем отображать). Значение “RRARows 480” определяет количество записей для каждого раздела данных (сутки, неделя, месяц, год). 480 соответствует точности для записи данных за сутки с интервалом три минуты (24*60/3). Плагин snmp выполняет сбор статистики по протоколу SNMP. В разделе Host указывается узел, с которого собираются данные, а также имена разделов с данными для опроса определенных OID (информацию по нужным мне OID брал из временного файла /opt/tmp/snmp.txt). Запускаем collectd /opt/etc/init.d$ /opt/etc/init.d/S??collectd start Проверяем лог /opt/var/log/collectd.log на наличие ошибок. Если все прошло успешно, то через несколько минут в БД RRD можно посмотреть вносимые сервисом данные, например по uptime системы. Для этого установим rrdtool: opkg install rrdtool rrdtool dump /opt/var/lib/collectd/rrd/localhost/snmp/uptime.rrd | less На этом данный этап закончен. Можно спокойно передохнуть, а настройку отрисовки графиков продолжить в следующий раз. Этап 2. Формирование графиков статистики. Приступим к настройке визуальной части системы. Для этого установим http-сервер. В примере будет использоваться lighttpd с модулем lighttpd-mod-cgi. Можете использовать другой http-сервер, но необходимо будет в соответствии с документацией на сервер настроить поддержку выполнения CGI-скриптов. Также необходимо установить rrdcgi для формирования динамических HTML-файлов. Устанавливаем сервер и необходимое ПО: opkg install lighttpd lighttpd-mod-cgi rrdcgi Настраиваем сервер. В /opt/etc/lighttpd/lighttpd.conf меняем порт на 8000 и убираем комментарий: server.port = 8000 И добавляем в index-file.names запуск индексной страницы с именем index.rcgi: index-file.names = ( "index.php", "index.html", "index.htm", "default.htm", "index.lighttpd.html", "index.rcgi" ) В /opt/etc/lighttpd/conf.d/30-cgi.conf корректируем cgi.assign для выполнения скриптов с расширением .rcgi: cgi.assign = ( ".pl" => "/opt/bin/perl", ".cgi" => "/opt/bin/perl", ".rb" => "/opt/bin/ruby", ".erb" => "/opt/bin/eruby", ".py" => "/opt/bin/python", ".rcgi" => "/opt/bin/rrdcgi" ) Запускаем сервер: /opt/etc/init.d/S80lighttpd start Копируем содержимое архива www/* в каталог /opt/share/www. В переменной RRDPATH файлов 3*.rcgi нужно указать правильный путь к каталогу статистики, т.к. он зависит от названия вашего роутера. Также у меня для доступа в Интернет используется PPPoE, физическое подключение имеется только к WAN и к трем интерфейсам роутера. Поэтому набор файлов редактируйте под свои нужды. Но скрипты для общей статистики системы должны работать без каких-либо изменений. Подключаемые шаблоны находятся в /opt/share/www/include. Их тоже можно корректировать, если возникнет необходимость (например, изменить дизайн страницы, поменять цвет и форму графиков и т.п.). Документацию смотрите на официальной странице RRDTOOL. Если требуется выполнить какие-то дополнительные вычисления над данными в RRD (а в некоторых шаблонах это используется), то они производятся в обратной польской записи (RPN), в конце статьи есть ссылка на он-лайн конвертер. В общем шаблоне /opt/share/www/include/0-page.tmpl используется параметр <RRD::SETVAR ADDOPT5 --lazy>, необходимый для того, чтобы каждый раз не пересоздавать изображения с графиками, если информация в RRD файле не менялась. При отладке (например, подборе цвета линий на графике или изменении шрифтов) можно данный параметр изменить на заглушку <RRD::SETVAR ADDOPT5 --title=''>. В этом случае картинка будет перерисовываться каждый раз при открытии страницы со статистикой. Делаем исполняемым скрипт формирования индексной страницы и запускаем его для создания файла index.cgi: chmod +x /opt/share/www/scripts/index.sh /opt/share/www/scripts/index.sh Если потребуется изменить дизайн индексной страницы, то его придется изменять непосредственно в скрипте. Выносить HTML-код в отдельный файл пока не планировал. Открываем сайт со статистикой в браузере по адресу http://адрес_роутера:8000/ Архив (конфигурация, шаблоны, скрипт для создания индексной страницы): files.zip Список используемой литературы: Официальная страница collectd Collectd Wiki Официальная страница rrdtool Он-лайн конвертер для обратной польской записи Названия и коды цветов в HTML, CSS и JavaScript
  8. Для сохранения конфига во временную папку можно воспользоваться командой: ndmq -p "show running-config" -P message > /opt/tmp/config.txt Данную задачу можно добавить в /opt/etc/crontab. Например, сохранение конфига в 4 часа утра: 0 4 * * * root ndmq -p "show running-config" -P message > /opt/tmp/config.txt Если требуется каждый раз создавать новый файл конфига (например, для истории), то можно усложнить команду сохранения конфига: ndmq -p "show running-config" -P message > /opt/tmp/config-`date +%Y-%m-%d`
  9. Еще бы добавить информацию по первичной настройке, показать на примерах, что в итоге мы можем получить и после этого вынести статью в каталог готовых решений. Графики, насколько я понимаю, также можно строить на самом entware?
  10. Наверно стоит поменять '==', на '=' . Такое ощущение, что не находит программу microdc2, т.к. задан неправильный путь поиска бинарников.
  11. Не могу подсказать. Нужно знать правильную команду на включение/отключение pppoe. Я взял команду из сообщения Le ecureuil. Возможно, в мануале на CLI найдете. Но ребут в крон, как я написал выше, должен работать.
  12. Это я неправильно написал. Нужно так 0 * * * * root /opt/sbin/reboot Команду подсказали выше. Пример выполнения нескольких команд в одной строке в cron каждый час (выполняется команда date ожидается 1 секунда и date выполняется повторно, результат выполнения записывается в файл): 0 * * * * root (/opt/bin/date && sleep 1 && /opt/bin/date) >> /opt/tmp/date.txt Попробуйте. Если результат для этого примера будет также отрицательный, то лучше настроить логирование entware и смотреть /opt/var/log/message на наличие ошибок. Предполагаю, что переподключение pppoe каждый час будет выглядеть так: 0 * * * * root /opt/bin/ndmq -p 'interface PPPoE0 no connect' -P message && sleep 5 && /opt/bin/ndmq -p 'interface PPPoE0 connect' -P message Проверить не могу, т.к. обрублю себе сук, на котором сижу (если что-то пойдет не так), т.к. сижу удаленно. Но предварительно можно проверить результат в командной строке, выполнив команду: /opt/bin/ndmq -p 'interface PPPoE0 no connect' -P message && sleep 5 && /opt/bin/ndmq -p 'interface PPPoE0 connect' -P message А далее уже добавить в cron.
  13. Ну, неправильно введено, пропущено имя пользователя, от которого нужно запускать команду. Нужно так (в принципе path задан правильный, но лучше указать полный путь к команде перезагрузки) 50 22 * * * root /opt/sbin/reboot Также не забудьте сделать в файле /opt/etc/crontab последнюю строку пустой. Чтобы сделать перезагрузку роутера раз в час (например, в 00:00, 01:00 и так далее) команда будет выглядеть так: 0 */1 * * * root /opt/sbin/reboot Также файловая система на entware должна быть ext*. Чтобы отлавливать ошибки cron. можно включить логирование с помощью syslog-ng (см. соответствующую тему на форуме в разделе готовых решений).
  14. Хотелось уточнить по поводу счетчиков: UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 58739 UCD-SNMP-MIB::ssCpuRawNice.0 = Counter32: 0 UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 22109 UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 517951 UCD-SNMP-MIB::ssRawInterrupts.0 = Counter32: 0 UCD-SNMP-MIB::ssRawContexts.0 = Counter32: 0 Такое ощущение, что они у меня в версии v2.08(AAFS.2)A9 показывают погоду в Австралии. Ими как-то можно пользоваться для расчета нагрузки CPU или же они для этого не предусмотрены? Сам веб-интерфейс как получает загрузку процессора? По данному вопросу написал в ветке тестирования 2.08. Сегодня перегрузил роутер, но лучше не стало. Причем в 2.06 (правда я тестировал SNMP всего один день) у меня сложилось впечатление, что работало нормально. Или же остается получать загрузку CPU только через внешние скрипты? Дополнение: Вопрос, скорее всего, снят. Формула для расчета cpu_user=ssCpuRawUser*100/(ssCpuRawUser+ssCpuRawSystem+ssCpuRawIdle) неверна. В качестве переменных в правой части равенства надо брать не полученные по SNMP значения, а разность текущего и предыдущего показания счетчика. Т.е. cpu_user=(ssCpuRawUser2-ssCpuRawUser1)*100/((ssCpuRawUser2-ssCpuRawUser1)+(ssCpuRawSystem2-ssCpuRawSystem1)+(ssCpuRawIdle2-ssCpuRawIdle1))
  15. Если его запустить вручную так, то все нормально отрабатывает?: /etc/init.d/S37xmail start Если да, то, возможно, запуск xmail при загрузке роутера не укладывается в какие-то таймауты. Соответственно, и возникает ошибка... И я бы подкорректировал строчку PATH, добавив в конце ":/opt/bin": PATH=$XMAIL_ROOT/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/bin
  16. Что у вас в самом скрипте автозапуска xmail вы не показали (по-умолчанию его в самом пакете нет). Протестировать вручную автоматический запуск программы можно с параметром start или stop (остановка). Например: # S37xmail start Если скрипт не отрабатывает нормально, то и роутер при перезапуске не сможет его запустить. Простой пример скрипта автозапуска выглядит так: Но это не совсем правильный вариант написания подобных скриптов для entware, но в простейших случаях сгодится.
  17. Обновился с тестовой версии 2.06 с поддержкой SNMP на версию v2.08(AAFS.2)A9. Снимал показания загрузки CPU со следующих счетчиков: UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 189927 UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 144865 UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 11349065 Далее по формуле, найденной в Сети, вычисляю загрузку процессора в процентах: cpu_user=ssCpuRawUser*100/(ssCpuRawUser+ssCpuRawSystem+ssCpuRawIdle) Таким же образом считаю для cpu_system и cpu_idle: cpu_system=ssCpuRawSystem*100/(ssCpuRawUser+ssCpuRawSystem+ssCpuRawIdle) cpu_idle=ssCpuRawIdle*100/(ssCpuRawUser+ssCpuRawSystem+ssCpuRawIdle) Общую загрузку cpu получал суммой вычисленных выше cpu_user и cpu_system. Сравнивал результат с показанием в веб-интерфейсе кинетика. Примерно совпадало, динамика изменений - тоже. Но сегодня обратил внимание, что нагрузка, полученная по SNMP перестала, соответствовать действительности. Для теста нагрузил процессор командой "cat /dev/zero | bzip2 -c > /dev/null", запустил snmpwalk и увидел, что значения в CpuRawUser и ssCpuRawSystem не растут, а в ssCpuRawIdle, соответственно, не уменьшаются (как было ранее). Думаю, что если перегружу железку, то опять станет нормально. Но пока этого делать не хочу, т.к. баг/фича сейчас воспроизводится. Также увидел, что по отношению к версии 2.06, в 2.08 команда htop стала показывать 2 процессора (ядра): 1 [||||||||||||||||||||||||||||||||||||||||||||||||||| 77.3%] Tasks: 34, 29 thr; 2 running 2 [||||||||||||||||||||| 29.9%] Load average: 0.35 0.10 0.29 Mem[||||||||||||||||||||||||||||||||| 59.0M/250M] Uptime: 18:38:07 Swp[ 0K/0K] Это так и должно быть? Не может быть тогда проблема связана с тем, что загрузка CPU по SNMP для второго "ядра" должна показываться в других счетчиках, например, ssCpuRawIdle.1, но при этом их в поддержки нет? Также отмечаю, что значения Load Average, получаемые по SNMP, при этом соответствуют действительности (в данном примере не обращать внимания на несоответствие значений в выводе команды htop): UCD-SNMP-MIB::laLoad.1 = STRING: 0.26 UCD-SNMP-MIB::laLoad.2 = STRING: 0.62 UCD-SNMP-MIB::laLoad.3 = STRING: 0.52 Дополнение Вопрос снят. Моя ошибка. Для расчета нужно брать не прямые значения ssCpuRawUser, ssCpuRawSystem, ssCpuRawIdle, а их разницу от предыдущих показаний.
  18. 1. Проводить ротацию логов можно в разных каталогах. Делайте, например, отдельный конф-файл для этого. 2. В соответствии с документацией, существует опция olddir Это требуется? Документацию можно посмотреть в интернете. Например, есть перевод мануала на сайте OpenNET.
  19. Вот нашел. Но здесь речь идет о 2.07. Но, возможно, что так теперь везде. Но у меня винт спит (нет никаких звуков и вибрация двигателя не чувствует). Остается, для того чтобы убедиться, что не в окружении самого entware дело, временно отключить поддержку opkg, на всякий случай перегрузиться с выключением питания роутера и посмотреть будет ли винт спать.
  20. Нет. Все будет нормально. Можно сколько угодно раз подключать/отключать. Ничего не пропадет. К сожалению так и не смог научиться на entware, как посмотреть, что за процесс пишет на диск. Копал пакеты dstat, vmstat. Похоже этой поддержки нет в ядре. Вспомнил. Если не ошибаюсь, то недавно в ветке про тестирование прошивок проскакивала информация, что разработчики по дефолту отключили засыпание диска. Но сейчас не могу что-то найти эту тему... Но повторюсь, Если entware развернут не на диске, который хочется чтобы спал, то он отключается со временем (если конечно к нему нет обращений). У меня по крайней мере так.
  21. Не замечал такого - диск прекрасно спит. Также giga II. Прошивка сейчас правда сейчас стоит экспериментальная v2.06(AAFS.5)C1 и поддержка opkg перенесена с диска на флэшку (но диск присутствует). Swap отключен? Будет ли активность.диска, если отключить модуль opkg, оставив при этом сам диск. В момент, когда моргает лампочка, что показывает iostat (пример, если диск в системе называется sda): # iostat -k -z -t -d sda 1 iostat, если по-умолчанию отсутствует, то есть в пакете sysstat. Данный пример показывает статистику sda в килобайтах с интервалом каждую секунду, если обращения были (опция -z). Также есть пакет iotop. Он бы показал активность процессов, обращающих к диску. Но к сожалению, на entware он у меня не запускается: Could not run iotop as some of the requirements are not met: - Linux >= 2.6.20 with - I/O accounting support (CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING) Еще увидел внимание, что установлен smartmontools. Тоже ранее использовал данный пакет в совокупности с smartd. Обратил внимание, что если "почитать" параметры smart с диска, то у него тоже со сном после этого возникали проблемы. После перезагрузки, если не обращаться для чтения smart проблема сохраняется? Можно даже временно удалить smartmontools (хотя в этом необходимости нет, т.к. он себя по-умолчанию в cron и в автозагрузку не прописывает).
  22. Ну вообще-то называть logrotate костылем, я бы не стал. Как правило, в linux он является штатным средством для ротации, архивирования, удаления логов. Его преимущество заключается в гибкости настроек и универсальности. Возможно, ng-syslog и может самостоятельно сохранять логи в требуемом формате, но удалять-то их все-равно придется через cron. А если требуется старые логи сжимать, то тут вообще, скорее всего, без вариантов. Но выбор средства борьбы с логами, конечно, остается за пользователем. Но я не зря в начале темы указал, что таким образом можно управлять логами не только от syslog. Есть и другие сервисы и службы (например, почтовые-сервера, прокси, tor и т.д.- благо entware нам позволяет это делать!), которые могут сохранять свои логи, причем в разных каталогах и с различным наименованием. В этом случае logrotate сможет легко с ними управляться. В моем примере это учтено. logrotate переименовывает текущий файл, но ng-syslog продолжает писать в старый файл. По завершению ротации ng-syslog перезапускается для того, чтобы начать писать лог в файл по-умолчанию. Но если захотеть, то можно в конфе logrotate сначала останавливать ng-syslog, а потом после ротации запускать. Возможность для этого имеется, но я не вижу в этом необходимости, т.к. данного механизма достаточно. Да, тут могут быть, наверное, проблемы. Но это не вина ng-syslog или logrotate. Поэтому для себя и не вижу смысла писать логи ng-syslog в формате ${YEAR}_${MONTH}_${DAY}.log, а ротацию логов по нужному мне формату раз в сутки доверить logrotate.
  23. Не совсем понял о чем вопрос. logrotate как раз и предназначен для того, чтобы не изобретать велосипед и иметь возможность достаточно гибко настроить ротацию логов (особенно если их несколько). Он сам и удаляет старые файлы. Архивные файлы в зависимости от настроек могут как раз и содержать в имени файла дату ротации (по-умолчанию как раз так и есть). Для указанного примера, это будет выглядеть так: n Name │ Size │Modify time .. │UP--DIR│июл 16 23:38 messages │ 5075│окт 10 12:21 messages-20160926 │ 247934│сен 26 04:02 messages-20161002 │ 187521│окт 2 04:02 messages-20161010 │ 451485│окт 10 04:02
  24. Перенес. Исходное сообщение отредактировал с указанием ссылки на тему.
  25. Если вы задались задачей собирать логи (журналы работы) системы в отдельный файл, который не стирается после перезагрузки роутера, то, скорее всего, через некоторое время столкнетесь с проблемой, когда размер лога станет занимать значительный объем диска. Задача по включении системного логирования во внешний лог описывается в соответствующей теме "Запись syslog на внешний USB-диск с помощю Syslog-ng", (автор Roman_Petrov). Здесь рассмотрим непосредственно механизм ротации логов. 1. Необходимо установить через opkg пакеты logrotate и cron. Cron нужен для периодического запуска logrotate. А logrotate в свою очередь требуется для проверки необходимости ротации логов и непосредственно их ротации в соответствии с заданными условиями (например, интервал времени и объем). С cron могут возникнуть проблемы, если файловая система диска fat или ntfs, т.к. на конфигурационных файлах будут неправильные (с точки зрения linux/cron) атрибуты файлов. И задачи просто не будут запускаться. Решение имеется, но нужно ставить crontab из busybox (п.2). Второй и третий вариант решения проблемы с cron и ntfs/fat - это изменить файловую систему подключенного диска на ext2 или ext3, либо поставить поддержку opkg на отдельную флэшку (раздел) с ext2/ext3 (если, не хочется возиться с преобразованием основного диска). Для себя я выбрал третий вариант (хотя и на диске с файлами у меня ext3). Но т.к. основной диск у меня используется редко, и я хочу, чтобы он "засыпал" и отключал питание, то все логи пишу на отдельную флэшку (достаточно будет размером 1 Гб). 2. Настраиваем ротацию логов. Основной конф /opt/etc/logrotate.conf не трогаем и делаем отдельную конфигурацию для ротации файла /opt/var/log/messages (таким же образом можно будет настроить ротирование и других логов, если они у вас имеются - например, от прокси). Для этого в подключаемом по-умолчанию каталоге /opt/etc/logrotate.d (указано в основной конфигурации /opt/etc/logrotate.conf) создаем конф-файл messages и добавляем в него следующие строки: Здесь ротация производится по достижению размера лога 1Мб, хранится всего три последних файла. После ротации лога перезапускается сервис syslog-ng (нужно для правильного продолжения записи в новый лог). С учетом основной конфигурации (см. файл /opt/etc/logrotate.conf, опция weekly) ротация лога будет производиться каждую неделю или же при достижении объема 1Мб. Можно почитать в инете мануал для более тщательной настройки logrotate. Например, чтобы делать ротацию не только по размеру, но и по времени. Можно также сжимать архивные файлы логов. Перевод документации по logrotate можно посмотреть на сайте OpenNET. 3. Далее настраиваем cron в основном файле /opt/etc/crontab. Т.к. по-умолчанию задач, выполняемых ежедневно, еженедельно и т.п., у меня нет, то он выглядит так: Раскоментарена только строка для выполнения ежедневных задач. По-умолчанию после установки cron запускаются все задачи (все строки раскоментарены). Т.е. можно данный файл и не изменять, но при этом в /opt/var/log/messages при выполнении этих задач-заглушек (с частотой, как минимум 1 минута) будет появляться соответствующая запись о выполнении данной задачи. Поэтому решать вам. Нужно также перезапустить службу cron. Для этого необходимо выполнить команду с консоли: /opt/etc/init.d/S10cron restart 4. Добавляем в cron задачу, которая будет выполняться один раз в сутки. Для этого в каталоге /opt/etc/cron.daily размещаем исполняемый файл. Я его назвал /opt/etc/cron.daily/logrotate . В нем размещены следующие команды: Исполняемым файл можно сделать через пакет mc (файловый менджер - must have) или с командной строки: chmod 755 /opt/etc/cron.daily/logrotate Можно проверять необходимость ротации логов чаще, а не только раз в сутки. Для этого нужно раскоментировать соответствующие записи /opt/etc/crontab и поместить задачу logrotate в соответствующий каталог. Но, как правило, в нашем случае логи быстро не увеличивают размер и в этом необходимости нет. Обращаю внимание, что linux очень часто плохо относится к тому, если в текстовых конф-файлах и т.п. последняя строка не заканчивается символом возврата каретки. Поэтому необходимо после последней строки в файле нажимать Enter для перевода курсора на новую пустую строку. В приведенных мной примерах эта пустая строка имеется. Всё. Если хочется сразу проверить ротацию лога вручную (и его размер в соответствии с конфом уже больше 1Мб), то команду ротации можно принудительно выполнить с консоли (или просто запустить исполняемый файл-задачу): /opt/sbin/logrotate /opt/etc/logrotate.conf или (т.к. файл у нас уже исполняемый) запустить задачу /opt/etc/cron.daily/logrotate
×
×
  • Create New...