Cooper's blog

Видеодрайвер перестал отвечать и был восстановлен. Проблема на ASUS M50VN после установки VISTA SP2.

Cooper — Sat, 23 Jan 2010 11:42:00 +0300

На днях, после установки SP2 VISTA на домашнем ноутбуке ASUS M50N начались проблемы с видеокартой. Периодически экран гас, через некоторое время изображение восстанавливалось и в трее появлялась загадочная надпись - “Видеодрайвер перестал отвечать и был восстановлен”. Установка новейшего драйвера с сайта NVIDIA, а также применения патчей от Майкрософт, как рекомендуется на ряде форумов (например: http://forum.himki.net/index.php?showtopic=74296), ни к чему не привели. Решение было найдено на сайте поддержки ASUS - http://support.asus.com. В разделе BIOS необходимо скачать последнее обновление - BIOS 212: Update VBIOS to fix VGA flicker and freeze problem. И, затем применить его с помощью прогораммы WinFlash, входящую в стандартный набор утилит ASUS. Если вдруг её не оказалось на компьютере, то скачать WInFlash можно с того же сайта поддержки из раздела BIOS-Utilities

ЗОМБИ ПРОЦЕССЫ В ЛИНУКС. Что это значит, как с этим бороться и стоит ли.

Cooper — Tue, 24 Feb 2009 23:09:00 +0300

Наверняка хоть раз многие задавали себе вопрос, глядя на выдачу команды ps ax, что это загадочные zombie процессы. Их пытаешься удалить (буквально убить) командой kill, но они остаются целыми и невредимыми.

10310 ?        Z      0:00 [php <defunct>]
10316 ?        Z      0:00 [php <defunct>]
10352 ?        Z      0:00 [php <defunct>]

На самом деле зомби уже уничтоженные процессы. А, как известно, нельзя убить дважды :). Ранее для них уже была выполнена команда kill, но, по разным причинам, она не смогла завершиться завершением процесса. Он остается формально существующим, но ресурсы, отведенные для него, на самом деле, освобождаются. Причина существования zombie процессов заключается в том, что родительский процесс может запросить статус завершения или затребовать статистику использования ресурсов порожденного зомби. В случае, если процесс-родитель не нуждается больше в зомби, он сигнализирует об этом операционной системе с помощью вызова системной функции wait(). В нормальной ситуации, когда процесс завершается, все его child processes становятся наследниками init, PID которого равен 1. Init всегда ждёт завершения child processes, для того, чтобы избежать порождения зомби. Если всё же в вашей системе завелись зомби, это означает, что они не обслуживают более свои родительские процессы (определить, кстати, которые можно командой ps -lax, колонка PPID):

[user1@www user1]$ ps -lax
F   UID   PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
0     0 10302     1  15   0 29420 8132 -      S    ?          0:06 /usr/local/bin/ruby /var/www/site/public/dispatch.fcgi
0     0 10310 10302  15   0     0    0 -      Z    ?          0:00 [php <defunct>]
0     0 10316 10301  15   0     0    0 -      Z    ?          0:00 [php <defunct>]

В этом случае у вас есть три варианта: (1) исправить процесс родитель; (2) убить его; (3) или продолжать жить с этим. Надо заметить, что жить с этим не так уж и сложно, поскольку зомби - это всего лишь дополнительная строчка в выдаче команды ps .

Изменение часового пояса (timezone) в ОС Linux через терминальный режим.

Cooper — Tue, 17 Feb 2009 15:32:00 +0300

Многие современные Linux дистрибутивы имеют в своем составе программы с довольно дружественным интерфейсом для установки часового пояса. Часто эта функция доступна через программное меню или простым нажатием правой кнопки мыши на иконке с изображением часов в известных графических средах, таких как KDE или GNOME. Но зачастую, приходится работать в режиме терминала, где нет доступа к удобной функциональности графического интерфейса. В этом случае часовой пояс устанавливается с помощью команд Linux и весь процесс состоит из нескольких простых шагов:

1. Заходим в систему как root, проверяем текущий часовой пояс, установленный на машине. Для этого выполняем команду date. На экране появится что-то типа:

Tue Feb 17 23:31:00 CST 2009

В данном случае CST и есть наш текущий часовой пояс.

2. Зайдя в директорию /usr/share/zoneinfo мы увидим список регионов, из которых можно выбрать наиболее подходящий для нас. Допустим, мы хотим переключиться на часовой пояс Москвы. Для этого нам нужно использовать файл Moscow, находящийся в поддиректории Europe.

3. На всякий случай делаем резервную копию файла с текущими настройками:

mv /etc/localtime  /etc/localtime-old

4. Создаем символическую ссылку на нужный нам timezone:

ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime

5. Прописываем значение параметра ZONE в файле /etc/sysconfig/clock В нашем случае оно должно быть “Europe/Moscow”.

6. Устанавливаем аппаратные часы, выполнив команду:

/sbin/hwclock --systohc

7. В принципе, на этом все необходимые изменения можно считать законченными. Правда вместе с изменением часового пояса у нас «съехало» и текущее время:

Wed Feb 18 08:32:05 MSK 2009

Установим правильные значения для даты и времени, используя команду date:

date -s "02/17/2009 23:32:00"

Слухи о Google. PageRank будет обнулён.

Cooper — Fri, 09 Nov 2007 02:19:00 +0300

По сообщениям нескольких англоязычных ресурсов один из инженеров Google раскрыл планы компании о том, что в течение ноября этого года будут внесены изменения в четыре элемента их поисковой машины, а также в систему AdSense. Это связано с намерениями помешать дальнейшему расширению масштабов чёрной оптимизации, жульничеству с использованием PR и AdSense скликиванию.

PageRank должен быть обнулен и заменён.

PageRank (PR), получивший за время своего существования достаточно много нелестных отзывов, должен быть упразднён. Все значения PR, отображаемые на панелях браузеров будут сброшены и больше не будут восстановлены ( вот почему последнее обновление PageRank так затянулось). Это очень печальная новость для людей, зарабатывающих с помощью платного размещения ссылок на своих сайтах. На собственном примере могу сказать, что буквально сегодня была продана ссылка за 3.99 $/месяц на этом блоге через систему Sape. Упразднение PR по планам должно быть завершено к середине ноября, одновременно с выходом новой панели инструментов Google версии 4.2. В ней уже появится VR (visitor rating). Google VR™ будет использовать систему, похожую на известный социальный сервис digg. Для этого на панели Google появится кнопка для голосования, фиксирующая рейтинги страниц, выставляемые посетителями сайта. Отображение VR будет таким же, как и PR – в виде синей полоски на tool bar.

При расчете VR будет приниматься во внимание несколько факторов, такие, как соотношение между количеством посетителей и голосований и откуда посетитель пришел на сайт (например, с другого сервера или с поисковой машины). Также будет учтено как часто посетитель возвращается на ваш сайт в течение длительного промежутка времени.

AdSense скликивание

С целью уменьшения мошенничества с системой AdSense и непреднамеренного скликивания, Google разработал систему предотвращения случайных кликов. Разработанный механизм, в случае нажатия кем-либо на рекламное объявление, предусматривает показ предупреждения. В нем сообщается, что ссылка является PPC рекламой и будет произведен переход на спонсорский сайт. В случае положительного ответа Вы получаете оплату за клик, если ответ отрицательный – нет. Есть предположение, что это уменьшит AdSense заработки и увеличит CPC (cost per click).

Данные об обратных ссылках не будут доступны

Оператор link: в поиске Google был долгое время способом, с помощью которого можно определить как много существует обратных ссылок на ваш сайт (достаточно важный фактор при размещении платных ссылок на сайте). Но теперь можно об этом не беспокоится, потому что Google убирает все данные об обратных ссылках из поисковой машины, а также из инструментов вэб-мастера и службы аналитики.

Замена rel=”nofollow” на rel=”dofollow”

Не так давно Google предложил великолепную идею использовать атрибут rel=”nofollow” для ссылок. Это сообщало Google-роботу о том, что не надо переходить по ссылкам для индексирования ресурсов, на которые они указывают. Это хорошо помогало бороться со спам-комментариями в блогах. Но, к сожалению, не так много людей использовало этот атрибут, и он постепенно вымер. По этой причине в ноябре Google заменяет его значение на rel=”dofollow”, что должно служить командой роботу перейти по ссылке и проиндексировать ресурс. Все теги ссылок без указания атрибута или с атрибутом rel=”nofollow” будут проигнорированы Google роботом. Таким образом, все линки, приносившие вам прибыль, станут бесполезными.

Использованные ресурсы: The Google Rumor Mill

SAPE. Итоги первого месяца работы с системой

Cooper — Fri, 08 Jun 2007 14:41:00 +0400

Вот и закончился первый месяц использования системы купли-продажи ссылок SAPE и хочется подвести некоторые итоги, поделиться опытом.

За это время я постарался попробовать все основные режимы со стороны вэб-мастера (ВМ), а также попытался вывести деньги. Надо сказать, что система выглядит ещё достаточно сырой, но, с другой стороны обладает достаточным потенциалом и множеством полезных функций.

Работа в SAPE для ВМ начинается с заведения площадки и выставления цен на страницы. При этом рекомендуется придерживаться средних значений цены, что я и сделал. Ссылки начали продаваться, практически сразу же, но поначалу мне была непонятна избирательность Оптимизаторов. То есть на некоторых страницах все линки уходили на ура за два-три дня, а на других не продавались совсем.

Всё стало понятно, когда в списке страниц, на которых могут быть помещены ссылки, появилась новая колонка ВС, то есть «внешние ссылки».

Оптимизаторы то видели ВС всегда и делали выводы – с большим количеством внешних ссылок страница представляет меньшую ценность для них.

Пришлось срочно заняться оптимизацией контента и других частей страниц, генерируемых блог-движком. С точки зрения SEO считается, что самым подходящим способом скрыть внешние ссылки для поисковиков (и как я надеялся для SAPE) это обрамить их тегом n o i n d e x. Это действует на Яндекс, для Google рекомендуется использовать атрибут rel=”nofollow”.

Частично это помогло, но для некоторых страниц до сих пор отображаются сильно завышенные результаты. Даже элементарный ручной подсчет показывает, что не может быть на странице столько ссылок. Эта тема до сих пор активно обсуждается на форуме, но однозначного ответа всё равно нет. По заявлениям самих SAPE-разработчиков параметр ВС пересчитывается где-то раз в сутки только для тех страниц, где уже размещены sape-links. Для остальных, только во время индексации.

Я пока решил ничего не трогать и посмотреть, что будет после очередном SAPE-индексировании, возможно, оно поможет актуализировать значения для ВС.

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

Теперь о приятном, то есть о выводе денег. На момент регистрации в системе поддерживались Яндекс.Деньги и WebMoney. Затем из-за каких-то проблем, остались только WM. Сам процесс перевода заключается в выставлении заявки, где указывается сумма (не более 10 WMZ), затем заявка ставится в очередь. Весь процесс занимает около суток. Процесс перевода при первой выплате в целях безопасности длится гораздо дольше, примерно неделю.

Использованная литература: И. Ашманов, А. Иванов “Оптимизация и продвижение сайтов в поисковых системах”

SAPE ON RAILS. Интеграция PHP-кода SAPE.RU в Ruby on Rails приложение.

Cooper — Mon, 23 Apr 2007 16:52:00 +0400

Наверняка уже многие счастливые обладатели сайтов, разработанных на php или html, установили и с удовольствием пользуются системой купли-продажи ссылок sape.ru. Поскольку мой блог использует Typo движок, написанный на Ruby on Rails, то конкретных инструкций по размещению sape-кода мне найти не удалось ни на форуме sape.ru, ни в Интернет. Поэтому пришлось провести небольшое исследование по способам интеграции Rails и PHP и затем реализовать на основе собранного материала Typo sidebar plug-in.

Первое, что я сделал, это вынес php-код для отображения ссылок, в отдельный файл с именем sape1.php. Этот файл был сохранен в директории /var/www/websites/mysite/public

Как показали первые эксперименты с sape, большая часть проблем с отображением ссылок продавцов была связана с тем, что невозможно определить внутри php-скрипта текущую страницу сайта или доменное имя. Поэтому далее в этом скрипте явно были прописаны параметры, в обычных условиях получаемые из контекста web-сервера: ‘request_uri’, ’host’. А также изменён параметр ’charset’ на UTF-8 в соответствии с используемой кодировкой страниц моего сайта. Значение ‘request_uri’ дополнительно преобразовывалось функцией urlencode() для корректной интерпретации символов кириллицы в URL.


<?php
    define('_SAPE_USER', '999999999999999999999999999999999');
    require_once('/var/www/websites/mysite/'._SAPE_USER.'/sape.php');
    $o['request_uri'] = $_GET['uri'];
    $o['request_uri'] = str_replace('%2F', '/', urlencode($o['request_uri']) );
    $o['host']    = 'cooper.ezlibrary.com';
    $o['charset'] = 'UTF-8';
    $sape = new SAPE_client($o);
    unset($o);
    echo $sape->return_links();
?>

После изменений в php-коде остается создать Sape sidebar plugin , где основная концепция реализована в файле content.rhtml:

<% command = '/usr/local/bin/php -q /var/www/websites/mysite/public/sape1.php uri=' + request.env["REQUEST_URI"].to_s %>
<%= `#{command}` %>

Через административный интерфейс добавляем новый plug-in на sidebar. С появлением новых запросов на размещение в sape.ru:

… они появляются в sidebar области Typo блога:

Так что те, кто ещё не присоединился, могут попробовать в действии систему купли-продажи ссылок Sape.ru теперь и на Ruby On Rails сайтах.

* * UPDATE * *

описанная выше методика была протестирована на системе RedHat EL3 c PHP 4.3.2 Позже возникла необходимость перейти на PHP 5.1 и оказалось, что подход к интеграции php-sape клиента в этом случае немного отличается.

При запуске php-скрипта public/sape1.php из typo-окружения элемент массива $_GET[‘uri’] не инициализируется значением, в результате ссылки на странице не видны. Для исправления ситуации вместо $_GET[‘uri’] нужно использовать $argv[1], также uri имеет уже закодированный вид, так что убираем строку с функцией urlencode():


<?php
    define('_SAPE_USER', '999999999999999999999999999999999');
    require_once('/var/www/websites/mysite/'._SAPE_USER.'/sape.php');
    // replace $_GET[‘uri’] with $argv[1]
    $o['request_uri'] = $argv[1];
    // remove uri encoding
    $o['host']    = 'cooper.ezlibrary.com';
    $o['charset'] = 'UTF-8';
    $sape = new SAPE_client($o);
    unset($o);
    echo $sape->return_links();
?>

А в typo-плагине откорректировать файл views/content.rhtml опустив название параметра uri и убрав ключ -q:


<% command = '/usr/local/bin/php /var/www/websites/mysite/public/sape1.php ' + request.env["REQUEST_URI"].to_s %>
<%= `#{command}` %>

TYPO 4.1. Миграция блога на новый релиз

Cooper — Wed, 21 Mar 2007 01:27:00 +0300

После выхода версии typo 4.1 тут же захотелось опробовать её в деле. В принципе, сам процесс обновления практически не отличался от предыдущего, добавился только 4-й пункт, из-за того что изменился адрес и способ доступа к svn-репозитарию проекта. Ещё одна вещь, которая бросилась в глаза после завершения обновления, это проблема с обработкой тэгов typo:code, typo:lightbox. Это только те теги, которые я заметил. Судя по откликам , существуют и другие похожие проблемы. Frederic обещает разобраться с этим в релизе 4.1.1. Пока что пришлось для топовых постов поменять <typo:code> на <pre> а <typo:lightbox /> на <img />

Итак, сам процесс обновления описан ниже:

1) Останавливаем lighttpd:

/etc/init.d/lighttpd stop

2) Делаем backup сайта:


tar cfv cooper.ezlibrary.com_r1193.tar www.ezlibrary.com/*
gzip cooper.ezlibrary.com_r1193.tar

3) Бэкапируем базу MySQL:


 mysqldump typo_user_typo > /home/backups/mysql/cooper.ezlibrary.com-mysql-db-backup.sql

4) Переключаемся на новый typo svn-репозиторий (если ещё не переключились):


svn switch --relocate svn://typosphere.org/typo/trunk  http://svn.typosphere.org/typo/trunk

5) Обновляем текущую версию последним стабильным релизом 4.1 (revision 1389):

svn update -r 1389

6) Мигрируем на новую версию схемы базы данных:

rake migrate

7) Стартуем lighttpd:

/etc/init.d/lighttpd start

TYPO 4.1. Что нового?

Cooper — Tue, 20 Mar 2007 12:13:00 +0300

Где-то с конца прошлого года казалось, что проект вот-вот закончит свое существование. Об этом можно было судить потому, что разработка не велась несколько месяцев, официальный сайт проекта был недоступен в течение трёх месяцев без каких-либо официальных объяснений. Не была известна дата следующего официального релиза и, если говорить, в общем и целом - будущее проекта. На этом фоне многие приверженцы Typo начали переходить на Mephisto или другие blog-engines.

И вот, наконец, вышел очередной релиз Typo 4.1 , в котором реализовано несколько интересных вещей:

Поддержка Ruby on Rails 1.2.
Внесены функциональные и эргономические изменения в раздел администрирования блога (back office).
Добавлена поддержка интернационализации и локализации, используя localization плагин. Из поддерживаемых языков в данном релизе кроме английского языка доступен ещё французский.
Комментарии и trackbacks по умолчанию модерируемы.
Исправлено множество ошибок и проведено улучшение кода.
Поддержка RSS для тэгов и категорий.
Плагины используют механизм Rails plugin.

Typo 4.2 по прогнозам должно быть выпущено через два месяца, и судя по планам этот релиз будет выглядеть также впечатляюще:

Поддержка пользовательских ролей и процесса публикации статьи.
Возможность реализации на одной копии Typo множества блогов.
Переход с модуля Localization на Globalization для поддержки i18n и l10n.
Интеграция предложенных разработчиками патчей как плагинов.
Завершение улучшения административного раздела блога.
Перевод интерфейса на новые языки.

МОДЕМ ZYXEL P-660HW EE. Обновление микропрограммы

Cooper — Sun, 18 Mar 2007 06:28:00 +0300

Модем приобрел в мае 2005 года, при настройке подключения к Интернет провайдер предоставил инструкцию для настройки модема исключительно в режиме Bridge. Для меня это было не очень удобным, так как кроме ноутбука через Wi-Fi планировал использовать также КПК. Решил на первое время оставить пока так, а потом перейти на Routingmode плюс DHCP с Private-адресацией.

И вот, спустя почти два года, настало время осуществить задуманное. Кроме того, под это дело захотелось обновить прошивку микропрограммы. На сайте Zyxel в разделе Download была скачана последняя версия 3.40(PE.11)C0_20061218 и через web-интерфейс (Maintenance->Firmware) успешно загружена в модем.

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

Ничего не другого не придумал, как сделать downgrade до предпоследней версии 340PE9C0_20050907. Прошивка длилась 15-20 минут, светодиод PWR/SYS мигал зелёным цветом. Предыдущая прошивка по времени занимала около 10 минут, и я подумал, что модем завис и решил перезапустить его. Хотя, конечно, выключать устройство в процессе прошивки категорически запрещено. После этого, при включении замигал PWR/SYS, затем, через некоторое, время буквально на полсекунды загорались янтарным цветом и гаснули все лампочки LAN. Затем, секунд через пять, зелёным загорался индикатор WLAN, через три-четыре секунды гас и всё повторялось снова в цикле. Это могло означать всё что угодно, в том числе, что процесс прошивки завершился некорректно и микропрограмма безнадёжно испорчена.

За советом решил обратиться в службу поддержки Zyxel. Ответ получил достаточно оперативно, но ничего хорошего он не предвещал. Технический специалист посоветовал сделать аппаратный сброс. В случае, если это не поможет, он рекомендовал привезти устройство в сервисный центр. Надо сказать, что HARD RESET я пытался сделать сразу же после неудачной попытки поменять прошивку и, это не имело никакого эффекта. Но для очистки совести решил сделать его ещё раз, предварительно изучив раздел User Guide, посвященный аппаратному сбросу. Прочитав первое предложение, я понял, что надежда есть:

“Удерживайте кнопку RESET (ПЕРЕЗАПУСК) в течение десяти секунд до тех пор, пока светодиод SYS или светодиод PWR/SYS не начнет мигать, а затем отпустите её.”

Я, конечно же, не удерживал RESET десять секунд, а просто нажимал и отпускал. В результате модем нормально инициализировался, я смог подключиться к нему, используя стандартные настройки (пароль и IP адрес). Устройство, на первый взгляд, работало стабильно и перепрошивать микропрограмму я не стал. Сделав необходимые настройки для подключения к провайдеру и работы через Wi-Fi, я забекапировал конфигурацию:

C:\>ftp 192.168.1.1
Связь с 192.168.1.1.
220  FTP version 1.0 ready at Sat Jan 01 03:05:18 2000
Пользователь (192.168.1.1:(none)): root
331 Enter PASS command
Пароль: ******
230 Logged in
ftp> get rom-0 my_zyxel_config.rom
200 Port command okay
150 Opening data connection for RETR rom-0
226 File sent OK
ftp: 49152 байт получено за 0,30 (сек) со скоростью 163,30 (КБ/сек).
ftp> quit
221 Goodbye!

В результате в файле my_zyxel_config.rom мы получили текущую работающую конфигурацию, которую в случае неудачного изменения настроек можно будет восстановить.

НАСТРОЙКА IPTABLES. Защита от паразитного трафика

Cooper — Tue, 28 Nov 2006 19:14:00 +0300

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

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

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

Блокировать “плохие” хосты на уровне приложения;
Использовать стандартные средства вэб-сервера Apache или lighttpd;
Настроить правила утилиты iptables, которая присутствует во всех LINUX дистрибутивах, базирующихся на ядрах 2.4.x или 2.6.x

Первые два способа были исключены из рассмотрения, поскольку здесь существует определённая привязка к приложению или к конкретному web-серверу. И если, например, Apache будет заменён на ngnix, придется заново прописывать блокирующие правила. К тому же, паразитные пакеты будут доходить до вэб сервера и приложения, дополнительно загружая их.

Используя утилиту iptables достаточно просто можно настроить набор правил для блокирования, а также получить средство для накопления и просмотра статистики по созданным правилам.

Настройка правил iptables

Процесс настройки достаточно простой и занимает несколько минут. Надо заметить, что Вы должны зайти на сервер как root пользователь или использовать команду sudo для добавления правил.

Итак, у нас есть конкретный хост (crawler.bloglines.com, IP=65.214.44.29) и целая подсеть (84.110.0.0), которые надо забанить. Правила выглядят так:

#Crawler bloglines 
/sbin/iptables -A INPUT -s 65.214.44.29 -p tcp -m multiport --dports 80 -j DROP

#bzq-*.red.bezeqint.net
/sbin/iptables -A INPUT -s 84.110.0.0/255.255.0.0 -p tcp -m multiport --dports 80 -j DROP

Для других хостов или подсетей в правилах iptables, меняется только IP источника (параметр -s).

Просмотр статистики iptables

Запускаем iptables с параметрами -L и -v для просмотра статистики. Опция -L определяет вывод статистики для цепочки (chain). Если конкретная цепочка не задана, то для всех.

Опция -v задает расширенный вывод, включающий в себя счетчики пакетов и байт.

Очень часто добавляется параметр -n, который говорит команде iptables о том, что не надо обращаться к DNS для разрешения IP адресов и вывода их в виде доменных имен. Это значительно уменьшает время на выдачу результатов и позволяет уменьшить нагрузку на сервер.

Для дополнительного удобства список правил может быть пронумерован. Для этого используется опция –line-numbers.

/sbin/iptables -L -v --line-numbers

Сохранение правил и статистики

Если перезагрузить компьютер или удалить iptables kernel modules вся информация о собранной статистике и добавленных правилах будет утеряна. Чтобы предотвратить потерю данных необходимо делать бэкап после каждого изменения в списке правил. Для этого служить утилита iptables-save. Например:

iptables-save -c > /root/iptables-backup.txt

Восстановить данные из бэкапа можно используя команду iptables-restore. Обычно это делается после перезагрузки в одном из скриптов инициализации, например в /etc/rc.d/rc.local для Red Hat Linux.

iptables-restore -c < /root/iptables-backup.txt

Библиография: