| 1.1, Аноним (-), 08:01, 23/08/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>config SKIF - конфигурирование файла ядра,
эта статья о настройке ng_ipacct или о том как правильно собирать ядро?
>&& make clean && rehash
rehash тут нафик не нужен
>После всех этих манипуляций перезагрузим сервер.
ставить модулем или вкомпилить в ядро никакой разницы кроме той что в первом случае не нужно никаких ребутов, а значит первый - лучше.
>В RELENG_5 ядро многонитевое(multithreads)
и далее по тексту до
>Что ж, скачиваем и распаковываем.
это что, введение в архитектуру ядра или способ налить больше воды для придания статье объемистости? гонорар больше кстати.
>/usr/local/script . Если у вас такой нет, рекомендую
создать.
рекомендую почитать man hier и держать скрипты в ~/bin
>Объясним конструкцию if ... else : если вначале строки присутствует
эта статья о настройке ng_ipacct, о том как правильно собирать ядро или о программировании на perl?
>Загрузка необходимого модуля ng_ether
>Загрузка необходимого модуля ng_socket
>Загрузка необходимого модуля ng_tee
что-то я не понял, зачем грузить модули если они уже вкомпилированы в ядро?
>/usr/local/script/ng_stat/log/ng.log
man hier до просветления
>Пятое: Графический или web-интерфейс, для удобоваримого отображения статистики.
ну и где?
| | |
| |
| 2.2, Alexander (??), 10:48, 23/08/2005 [^] [^^] [^^^] [ответить]
| +/– | |
Да уж вата полная - но кому что...
>> ipfw отрабатывает не все пакеты, поступившие в bpf - пакетный фильтр
>> системы.
Че правда? Может ненароком net.inet.ip.fastforwarding=1.
| | |
| |
| 3.18, ganduras (?), 12:33, 24/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Да уж вата полная - но кому что...
>
>>> ipfw отрабатывает не все пакеты, поступившие в bpf - пакетный фильтр
>>> системы.
>
>Че правда? Может ненароком net.inet.ip.fastforwarding=1.
ну вообще бывает трафик на одном правиле считается два раза, вместо одного. И это происходит даже с использованием конструкции:
<rule body> in recv <interface name>
или
<rule body> out xmit <interface name>
.
На то, что трафик считается у провайдера немного не так, как у подключенного к нему абоненту, может быть несколько причин:
- провайдер может считать ВСЕ пакеты с/на данный MAC адрес или порт абонента;
- если подключение через ethernet, провайдер может считать пакеты с MAC заголовком, а не чистые IP пакеты;
- вы в курсе, что реальный размер пакета может быть больше, чем указан в заголовке IP пакета ? Разные счетчики по разному относятся к данному факту;
- несоответствие размерности килобайта/мегабайта/etc у пользователя и провайдера :) ;
- борзые терялщики трафика, в качестве счетчика;
- невероятные стечения обстоятельств и способностей отдельных личностей ;)
Автору этой статьи большой поклон. База знаний у каждого из читателей далеко не одинакова. Лучше было бы, если статья после своего выхода обзаводилась флеймом "а что это значит ?" и "как это сделать ?" ? | | |
|
| 2.3, Skif (ok), 11:48, 23/08/2005 [^] [^^] [^^^] [ответить] | +/– | Если прочитать ман - там и настравать нечего Это статья всего лиш способ показа... большой текст свёрнут, показать | | |
| |
| |
| 4.30, Merlin (??), 01:19, 28/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
>
>>А что реально надо?
>
>
>да
>;)
Да, если не трудно, можно где-то выложить эти скрипты?
| | |
|
| 3.11, AMDmi3 (?), 17:22, 23/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
>папка /usr/local/script создана для расположения ВСЕХ лично
>написанных мною скриптов и призвана не захламлять системные папки.
>Как по мне это правильный подход для любого админа. Он должен четко
>знать, где стоит чего-то самопальное. Я этому приучил уже не одного
>администратора.
~/bin именно для этого и придумали | | |
| |
| 4.13, Skif (ok), 18:29, 23/08/2005 [^] [^^] [^^^] [ответить]
| +/– | |
>~/bin именно для этого и придумали
Все же останусь при своем мнении. :)
Именно так, а не иначе. ИМХО, гораздо правильнее подход
| | |
| 4.15, Артур (??), 20:15, 23/08/2005 [^] [^^] [^^^] [ответить]
| +/– | |
>>папка /usr/local/script создана для расположения ВСЕХ лично
>~/bin именно для этого и придумали
Поддерживаю Скифа, со своим барохлом обслуживающих скриптов в /usr/local/мое гораздо удобнее поддерживать, бэкапить, работать.
Когда все в одной куче с портами в /usr/local/bin - хрен что найдешь с первого захода.
| | |
| |
| 5.16, Аноним (-), 06:44, 24/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
Уважаемые доны не знают что такое ~/ ?
Да не в /bin, не в /usr/bin и не в /usr/local/bin, разуйте глаза! В ~/, домашнем каталоге пользователя, от которого эти скрипты запускаются, создается каталог bin. Имхо, именно это unix-way, ибо не захламляются потенциально экспортируемые каталоги.
А вот держать логи в /usr/local/script/бла-бла - вообще руки оторвать надо.
>>>папка /usr/local/script создана для расположения ВСЕХ лично
>
>>~/bin именно для этого и придумали
>
>Поддерживаю Скифа, со своим барохлом обслуживающих скриптов в /usr/local/мое гораздо удобнее поддерживать,
>бэкапить, работать.
>Когда все в одной куче с портами в /usr/local/bin - хрен что
>найдешь с первого захода.
| | |
| |
| 6.20, Аноним (-), 22:24, 24/08/2005 [^] [^^] [^^^] [ответить]
| +/– | |
>Уважаемые доны не знают что такое ~/ ?
Доны посчитали сие за опечатку, ибо трудно поверить, что кто-то пихает системные скрипты в /home.
>Да не в /bin, не в /usr/bin и не в /usr/local/bin, разуйте
>глаза! В ~/, домашнем каталоге пользователя, от которого эти скрипты
>запускаются, создается каталог bin. Имхо, именно это unix-way, ибо не захламляются
>потенциально экспортируемые каталоги.
Речь про системные скрипты, которые запускаются не только одним пользователем и выполняют _системные_ функции.
>А вот держать логи в /usr/local/script/бла-бла
Вместо /usr/local/script использую /usr/local/имя_проекта (например, /usr/local/traf_acct), со своими etc, bin и share внутри.
>вообще руки оторвать надо.
За ~/bin нужно оторвать, ибо нефиг хранить системные скрипты в /home, который у многих и бэкапится иначе, и лежит на отдельном разеделее с квотами, и exec на нем запрещен, и пути править геморой при переносе и смене пользователя, и юзера убить можно вместе с домашней директорией, и вообще те скрипты из крона не под одним пользователем работают, и... | | |
| |
| 7.21, Аноним (-), 07:27, 25/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
>системные скрипты в /home.
не смешите мои тапочки, прикладные костыли это коим самое место в ~/bin
да, для непонятливых танкистов, ~/bin не обязательно /home/bin это может быть и /usr/local/имя_проекта/bin ;)
>и exec на нем запрещен,
ну вы батенька садист. или мазохист.
| | |
| |
| 8.25, Аноним (-), 22:08, 25/08/2005 [^] [^^] [^^^] [ответить] | +/– | bin какого пользователя, у нас, батенька, давно не однопольщзовательские систе... текст свёрнут, показать | | |
| |
| 9.27, Skif (ok), 14:20, 26/08/2005 [^] [^^] [^^^] [ответить] | +/– | Пальцы веером, сопли пузырями Все равно все останутся при своем ИМХО Я делаю т... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.4, gauss (?), 12:29, 23/08/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
хорошая статья. один из лучших способов биллить под фрей, не имея умного железа. критика думаю не к месту | | |
| 1.5, Аноним (5), 12:37, 23/08/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
кроме как
print "Фатальная ошибка ветвления!\n.................\n";
die "Разделение на процессы не возможно.\n Принудительный выход из дочернего процесса: $!\n";
трудно что то полезное разглядеть
| | |
| |
| 2.12, Skif (ok), 18:26, 23/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
что мешает заменить на более детальный вывод? Писал под себя посему и вывод такой, который понятен мне.
А код здесь разжеван от и до. | | |
|
| 1.6, Rastler (?), 12:50, 23/08/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Статья неплохая, воды конечно много... и самое гланое непонятно назначение всмысле что это и не матчасть, и не рукоыодство к действию, а смесь и того и другово. Если уж автору хотелось осветить теорию, то можно было бы разбить на 2 части и в первой расказать как все это работает теоретичестки. А в общем статья хорошая и слишком то уж наезжать нестоило бы. | | |
| |
| 2.9, Alexander (??), 13:30, 23/08/2005 [^] [^^] [^^^] [ответить]
| +/– | |
Забыл сказать, $good/$bad - скрипты, что в случае удачи/неудачи засыла данных на сервачок, убирают/выполняют ахтунг действия - такие как посыл письма мне, зарезание скорости абонентам, переодическое перестукивание морзянкой на спикере считалок международного морского кода об отсутствии связи с сервером и всякая всячина в подобном духе
Александр В. | | |
| |
| 3.10, Аноним (-), 15:28, 23/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
чем решение проще тем оно лучше, молодец! Кстати можно полностью обойтись ОДНИМ скриптом на sh
| | |
|
|
| 1.19, Аноним (-), 12:55, 24/08/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Господа, взгляните вы наконец на
ng_netflow из портов + http://sourceforge.net/projects/nnfc
Собирается элементарно, настраивается за пять минут, пишет в mysql, postgres, bin, txt файлы.. В отличие от предложенного в статье "агент+коллектор -> база" решение получается не зависимое от агента, писюк это или циска: "агент(ы) -> коллектор+база", масштабируемое, гетерогенное, стандартное.
А такие поделки как в статье, имхо, в сад.
| | |
| |
| 2.26, Abu (?), 03:30, 26/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
 А чтобы с двух интерфейсов собирал статистику - как быть? | | |
| |
| 3.28, Skif (ok), 14:21, 26/08/2005 [^] [^^] [^^^] [ответить]
| +/– | |
>А чтобы с двух интерфейсов собирал статистику - как быть?
перечислить через запятую. Это в статье указано. | | |
|
|
| 1.22, Аноним (-), 07:39, 25/08/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
в такой схеме соединений netgraph узлов трафик считается два раза, пакет при входе считается и когда выходит еще раз учитывается
| | |
| |
| 2.23, crypt (??), 14:12, 25/08/2005 [^] [^^] [^^^] [ответить]
| +/– | |
Тема, связанная с топиком. Как обычно организован у людей подсчет трафик для локальных пользователей? Скажем, чтобы считала входящий веб, фтп, почту для клиентов, которым предоставили хостинг? | | |
| 2.24, ganduras (?), 20:44, 25/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
>в такой схеме соединений netgraph узлов трафик считается два раза, пакет при
>входе считается и когда выходит еще раз учитывается
Это да ! Кстати беда не только Netgraph-а. Но и BPF и Firewall-а.
Но даже это можно обойти. Правда приходится патчить ядро, но BPF
начинает отделять входящие пакетики от исходящих. Единственно
где они для него всегда исходящие - это lo0 :) На основе этого
патчика в нашей конторе сделанна система обсчета, которая хранит
данные компактней, чем netflow файлы, и обсчет раз в десять быстрее
(если не в большее число раз). Вообщем пакет аналогичен trafd
(см. в портах). Но получился куда более эффективным :) И не страдает
болезнью двойного обсчета, если трафик приходит и уходит с одного и
того же интерфейса. | | |
| |
| 3.31, reaper (?), 07:49, 29/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
 >На основе этого
>патчика в нашей конторе сделанна система обсчета, которая хранит
>данные компактней, чем netflow файлы, и обсчет раз в десять быстрее
>(если не в большее число раз). Вообщем пакет аналогичен trafd
>(см. в портах). Но получился куда более эффективным :) И не страдает
>болезнью двойного обсчета, если трафик приходит и уходит с одного и
>того же интерфейса.
ну так покажи свой патчик, например статью напиши, а то достали авторизации сквида. или просто выложи, может кто другой из него статью сделает :) | | |
| |
| 4.33, ganduras (?), 12:37, 01/09/2005 [^] [^^] [^^^] [ответить]
| +/– |
>ну так покажи свой патчик, например статью напиши, а то достали авторизации
>сквида. или просто выложи, может кто другой из него статью сделает
>:)
сейчас пытаюсь найти коммитера из FreeBSD, кому эта фича была бы интересна
и кто бы его проверил.
Если ничего не получится, тогда да, придется другим путем действовать :)
| | |
| |
| 5.34, butcher (ok), 12:40, 01/09/2005 [^] [^^] [^^^] [ответить]
| +/– |
>сейчас пытаюсь найти коммитера из FreeBSD, кому эта фича была бы интересна
>и кто бы его проверил.
send-pr оформи, если кому-то будет интересно, тебе найдут.
| | |
|
|
|
| 2.29, Skif (ok), 14:24, 26/08/2005 [^] [^^] [^^^] [ответить]
| +/– |
>в такой схеме соединений netgraph узлов трафик считается два раза, пакет при
>входе считается и когда выходит еще раз учитывается
Объяснить можете? Было бы интересно, ибо такого (двойного подсчета)незамечено. | | |
| |
| 3.32, ganduras (?), 11:47, 01/09/2005 [^] [^^] [^^^] [ответить]
| +/– |
>>в такой схеме соединений netgraph узлов трафик считается два раза, пакет при
>>входе считается и когда выходит еще раз учитывается
>
>
>Объяснить можете? Было бы интересно, ибо такого (двойного подсчета)незамечено.
Это возникает не всегда, а только когда происходит прием/передача с одного
и того же интерфейса. Например на одном ethernet-е есть две сети
10.0.0.1/24 и 10.0.1.1/24. Если потребуется передать пакет с адреса,
скажем 10.0.0.50 на 10.0.1.50, тут и возникает эта ерунда. Сперва
пакет попадает на счетчик трафика как входящий, и тут же снова
обсчитывается как исходящий. При этом в большенстве случаев неизвестно,
каким является пакет, поступивший на обработку в систему учета трафика -
входящим или исходящим. Все данные, которые есть - это адрес отправителя,
и адрес получателя. Зафиксировать факт того, что пакет был дважды
посчитан, невозможно.
Единственно где это еще можно узнать - это на уровне ядра. Но даже там
нет нормального интерфейса для простого определения данного факта.
| | |
| |
| 4.35, Skif (ok), 16:24, 01/09/2005 [^] [^^] [^^^] [ответить]
| +/– |
>
>Это возникает не всегда, а только когда происходит прием/передача с одного
>и того же интерфейса. Например на одном ethernet-е есть две сети
>10.0.0.1/24 и 10.0.1.1/24. Если потребуется передать пакет с адреса,
>скажем 10.0.0.50 на 10.0.1.50, тут и возникает эта ерунда. Сперва
>пакет попадает на счетчик трафика как входящий, и тут же снова
>обсчитывается как исходящий. При этом в большенстве случаев неизвестно,
>каким является пакет, поступивший на обработку в систему учета трафика -
>входящим или исходящим. Все данные, которые есть - это адрес отправителя,
>и адрес получателя. Зафиксировать факт того, что пакет был дважды
>посчитан, невозможно.
>
>Единственно где это еще можно узнать - это на уровне ядра. Но
>даже там
>нет нормального интерфейса для простого определения данного факта.
Интренесно, а почему это называется багой? Это нормально.Теперь представьте на секунду, что у вас две сети, каждой из которых вам нужно выставить счет. Если этот трафик не будет просчитан вы потеряете деньги или просчитается только одной из них, но все-равно теряете деньги...
| | |
| |
| 5.36, ganduras (?), 17:06, 01/09/2005 [^] [^^] [^^^] [ответить]
| +/– |
>
>Интренесно, а почему это называется багой? Это нормально.Теперь представьте на секунду, что
>у вас две сети, каждой из которых вам нужно выставить счет.
>Если этот трафик не будет просчитан вы потеряете деньги или просчитается
>только одной из них, но все-равно теряете деньги...
а теперь представим реакцию абонента, когда вместо реального трафика
(причем локального) 1Gb ему выставляется счет на 2Gb. И это не только
ему, а еще тому, с кого он его скачал, но уже в качестве исходящего.
Вот это - коМММерция !
Можно конечно вычислить все роутинги, которые проходят через один
и тот же интерфейс, и делить весь трафик, который там проходит, на 2.
И надо заметить, что я не говорил, что в случае использования патча,
трафик будет потерян, а то, что будет корректно посчитан ! Причем он
все равно отправиться в фильтр два раза, но один раз с пометкой, как
входящий, а во второй, с пометкой как исходящий. По этой информации
можно разобрать пакеты для правильного обсчета всего трафика. | | |
|
|
|
|
|
