Error nfsend connect error no such file or directory

Модераторы: vadim64, terminus

Frontend - Backend version missmatch!
ERROR: nfsend connect() error: No such file or directory!
ERROR: nfsend - connection failed!!
ERROR: Can not initialize globals!

root@Route:/ # nfsen start
Error reading profile 'live'
Died at /usr/local/bin/nfsen line 456.
root@Route:/ #

ading hints: can't open /usr/local/var/nfsen/profiles-stat/hints: No such file or directory at /usr/local/libexec/nfsen/NfSen.pm line 798.

root@RouteAgu:/usr/local/var/nfsen/profiles-stat # nfsen --add-profile www ww
Can not connect to nfsend: No such file or directory

nfcapd[61074]: Receive socket error: could not open the requested socket
nfsen[61075]: Error writing profile 'live' in group '.'
nfsen[61075]: Error startup nfsend: Bad file descriptor
nfsen[61075]: PANIC nfsend dies: Unable to write PID file: Bad file descriptor


Dec 17 19:37:45 RouteAgu nfsen[61122]: Error startup nfsend: Bad file descriptor
Dec 17 19:37:45 RouteAgu nfsen[61122]: PANIC nfsend dies: Unable to write PID fi
 Error startup nfsend: Bad file descriptor
 PANIC nfsend dies: Unable to write PID file: Bad

Учёт, наблюдение сетевого трафика посредством NetFlow v5 протокола через web интерфейс nfsen. FreeBSD 8.2-RELEASE-p6

• Сайт https://anteh.ru

• О netgraph

• Установка настройка сенсора ng_netflow v5

• Установка настройка коллектора flow-capture

• Установка настройка nfsen apache22 php5

• Установка одновременно работающих коллекторов flow-capture и nfdump

• Конвертация, преобразование уже имеющихся данных netflow v5 к формату nfcapd для просмотра статистики через web интерфейс nfsen 1.3.5

• sfttonf конвертор netflow v5 статистики созданной flow-capture коллектором к формату nfdump и структуре папок используемых в nfsen

Если в кратце, то для учёта трафика используйте flow-tools или чего-нибудь платное.

Поскольку не знал, что лучше использовать для учёта, то настроил учёт трафика с использованием flow-tools и nfsen. Трафик с интерфейса смотрящего в сеть после IPFW посредством Netgraph расщепляется на 2 потока, один уходит к flow-tools, другой к nfsen. Отсюда и столько текста)

Будет рассмотрена установка настройка nfsen и всего, что нужно для его работы.

Подключение коллектора flow-capture из набора программ flow-tools, для использования параллельно с nfsen.

Конвертация уже имеющихся данных netflow v5 к формату nfcapd, который понимает nfdump коллектор, с последующим просмотром статистики через nfsen. Правда, при конвертации внешней статистики автоматически графики в текущей версии nfsen 1.3.5 не строятся, разбираться как там nfsen с RRDTool завязан нет ни желания ни времени, но саму статистику используя web морду nfsen можно просматривать через фильтр.

Настраиваем сервер для учёта общего трафика, и параметров сетевого обмена через один сетевой интерфейс, смотрящий к провайдеру. Данные будем просматривать через web интерфейс nfsen. СУБД не используется. По аналогии можно настроить для учёта на любом количестве сетевых интерфейсов.

Реализуем цепочку: ipfw->ng_ipfw->ng_netflow->ng_ksocket->nfdump->nfsen. И ipfw->ng_ipfw->ng_netflow->ng_ksocket->flow-capture->sfttonf->nfdump->nfsen. Предполагается, что с фаерволом ipfw пользователь знаком. ipfw как то там настроен и работает. Материал местами изложен избыточно подробно, это может помочь тем кто, как и автор столкнулся с задачей наблюдения за сетевым обменом, учётом трафика, и про netgraph, да и про многое другое, впервые. Замечания принимаются. Ну и если оно вам надо, то все описанные материалы вы будете использовать на свой страх и риск.

Лирическое отступление, о netgraph

Википедия: NetFlow — сетевой протокол, предназначенный для учёта сетевого трафика, разработанный компанией Cisco Systems. Является фактическим промышленным стандартом и поддерживается не только оборудованием Cisco, но и многими другими устройствами (в частности, Juniper и Enterasys). Также существуют свободные реализации для UNIX-подобных систем. Для ознакомления с netgraph нужно почитать: http://citrin.ru/daemonnews/netgraph.html -Всё о netgraph.

Установку компонентов производилась под FreeBSD 8.2 RELEASE p6.

Netflow имеет три основных компонента:

Сенсор. Будем использовать ng_netflow

Коллектор. Возьмем nfdump -идёт в составе nfsen

Система обработки и представления данных. Через web интерфейс nfsen

Съём статистики можно производить через хуки Ethernet интерфейса или через ng_ipfw. Первый способ самый быстрый. Второй использует ng_ipfw, что незначительно добавляет нагрузки, но получаем большую гибкость. IPFW может предварительно отфильтровать ненужный трафик перед передачей его в узел ng_ipfw. ng_netflow, ng_ipfw, ng_ksocket и прочие ng_* -это узлы. Просмотреть все имеющиеся KLD-модули узлов можно, введя команду:

# ls /boot/kernel/ng_*.ko

Узлы, как составные кирпичики, для построения нужной конфигурации обработки сетевых потоков. У каждого узла есть определённый набор крючков(hook) которыми он соединяется с соседними узлами. Узел можно/нужно конфигурировать, запрашивать его состояние, принимать ответные сообщения и т. д. Каждый крючок имеет уникальное имя, которое часто отражает его назначение.

Узел ng_ipfw — интерфейс между ipfw и системой netgraph может присутствовать только в одном экземпляре, создаёт интерфейс для доступа к подсистеме netgraph из IPFW. При загрузке в ядро, модуль автоматически создает свой узел в пространстве подсистемы netgraph с именем «ipfw:». ng_ipfw принимает подключения к произвольным номерным хукам, номера хуков указываются в правилах IPFW. Узел ng_netflow способен получать информацию о проходящем через него трафике и экспортировать ее в виде совместимым с протоколом NetFlow фирмы Cisco. Создание узла всегда происходит с подключением одного из хуков создаваемого узла.

Для взаимодействия ipfw и netgraph в ipfw существует два правила ngtee и netgraph, пример:
ipfw add netgraph 10 all from any to any — направит весь трафик попавший в правило, в хук ipfw:10 модуля ng_ipfw
ipfw add ngtee 20 ip from any to any — скопирует весь трафик попавший в правило, в хук ipfw:20 модуля ng_ipfw

ng_netflow поддерживает максимальное число крючков, равное NG_NETFLOW_MAXIFACES. Хуки Ng_netflow имеют имена iface0, iface1, iface2, ifaceN. Также соответствующие им out0, out1, out2, outN. И хук экспорта статистики export. Входящий трафик в ifaceN обрабатывается модулем учета. Если подключен соответственный хук outN, трафик без изменений уходит в него, если не подключен — никуда не уходит. Трафик вошедший в хук outN без изменений проходит к хуку ifaceN, без обработки модулем учета. Т.е. фактически на счетчики попадает только входящий трафик в ifaceN. Для управления поведением учета трафика есть настройки, о которых будет рассказано ниже. В итоге через хук export будут выходить UDP дейтаграммы netflow, этот кух обычно подключают к хуку inet/dgram/udp модуля ng_ksocket.

Экспортирует netflow версии v5. Принимаемые модулем контрольные сообщения, они же команды: info, ifinfo, setdlt, setifindex, settimeouts, setconfig, show. Setdlt устанавливает тип интерфейса, подключенного к ifaceN. Из всех возможных вариантов.

(/usr/src/sys/net/bpf.h)
#define DLT_NULL 0 /* BSD loopback encapsulation */
#define DLT_EN10MB 1 /* Ethernet (10Mb) */
#define DLT_EN3MB 2 /* Experimental Ethernet (3Mb) */
#define DLT_AX25 3 /* Amateur Radio AX.25 */
#define DLT_PRONET 4 /* Proteon ProNET Token Ring */
#define DLT_CHAOS 5 /* Chaos */
#define DLT_IEEE802 6 /* IEEE 802 Networks */
#define DLT_ARCNET 7 /* ARCNET */
#define DLT_SLIP 8 /* Serial Line IP */
#define DLT_PPP 9 /* Point-to-point Protocol */
#define DLT_FDDI 10 /* FDDI */
#define DLT_ATM_RFC1483 11 /* LLC/SNAP encapsulated atm */
#define DLT_RAW 12 /* raw IP */

Поддерживаются только Ethernet и голый IP, соответственно варианты 1 и 12. Первый вариант установлен по умолчанию. Синтаксис setdlt {iface=0 dlt=12}. Settimeouts — устанавливает таймауты активных и не активных потоков, после которых статистика будет отправлена в коллектор. Синтаксис settimeouts {inactive=15 active=1800}. Таймаут активного потока — по умолчанию 1800 секунд. И таймаут не активного потока по умолчанию 15 секунд. C помощью Info можно просмотреть информацию о настройках таймаутов и проверить работоспособность ng_netflow.

Установка/настройка сенсора ng_netflow v5

В общем можем убедиться, что /boot/kernel/ng_netflow.ko, /boot/kernel/netgraph.ko, /boot/kernel/ng_ipfw.ko и т.д. в наличии.

Добавляем в конфигурационный файл ядра параметры и пере собираем его. Кому не нравится пересборка, могут подключить соотвецтвующие модули динамически. Файл ядра лежит в паке /usr/src/sys/amd64/conf в зависимости от типа вашей системы вместо amd64 может быть другая папка. Не используем оригинальный файл конфигурации ядра GENERIC. Копируем и переименовываем GENERIC например в NNKER. Добавляем параметры в NNKER:

options NETGRAPH

options NETGRAPH_SOCKET

options NETGRAPH_IPFW

options NETGRAPH_NETFLOW

options NETGRAPH_KSOCKET

Пере собираем и устанавливаем новое ядро:

Проверяем, что есть папка /usr/src/sys/amd64/compile, если папки нет, то создаём её, иначе команда config не отработает будет ругаться No such file or directory.

NNKER в текущем случае имя конфигурационного файла ядра, если всё в в порядке то увидим что то вроде:

Если не всё в порядке, то исправляем ошибки в файле конфигурации ядра.

Далее идём в:

И выполняем команду:

Через минут 40 или несколько часов, процесс завершится и производим перезагрузку.

Предполагается, что с IPFW пользователь знаком, и сейчас IPFW настроен и работает. В текущей конфигурации используется IPFW + ядерный NAT. В общем параметры ядра для ядерного NAT:

options IPFIREWALL

options IPFIREWALL_NAT

options LIBALIAS

Нужен ли вам NAT решаем сами. Добавляем в файл конфигурации IPFW строки:

(Это только пример, чтобы через # ipfw show | more посмотреть, что правила срабатывают и трафик уходит в ng_ipfw. re1 имя сетевого интерфейса)

/sbin/ipfw -q add 00440 ngtee 10 ip from any to any out xmit re1 # Исходящий трафик

/sbin/ipfw -q add 00450 ngtee 20 ip from any to any in recv re1 # Входящий трафик

/sbin/ipfw -q add 00460 ngtee 30 ip from any to any via re1 # Исходящий + входящий

Куда их добавлять, сколько и в каком виде решаем сами, здесь приведён пример. Сам использовал только одно правило, если как в примере, то правило с номером 00460. Разница между правилами ngtee и netgraph в том, что все пакеты попавшие в правило netgraph передаются только в ng_ipfw и дальше по цепочке IPFW не передаются. Пакеты попавшие в ngtee передаются и в ng_ipfw и дальше по цепочке IPFW. Или другими словами netgraph направляет весь поток в ng_ipfw, а ngtee направляет копию потока в ng_ipfw и сам поток далее по цепочке IPFW.

Возможно удобней всего входящий и исходящий трафик учитывать отдельно, т.е. если как в примере, то использовать правила 00440 и 00450. Но для упрощения описания будет приведён пример для 00460 правила.

Перезапустить правила IPFW после изменения, в общем случае, можно командами:

# ipfw -q -f flush #Очистка правил ipfw. Разумеется работаем локально. Нужно, если в правилах ipfw не предусмотрена автоматическая очистка.

# /bin/sh /etc/fwall.conf & #Загрузка правил. fwall.conf конфигурационный файл фаервола, создаётся вручную, может иметь любое имя и располагаться где угодно.

Проверяем работоспособность модуля ng_ipfw скомпилированного с ядром, нужно убедиться, что происходит передача пакетов от ipfw к ng_ipfw:

# ngctl

+ list

Увидим примерно следующее:

Ipfw -узел ng_ipfw

Ngctl1724 -узел запущенного экземпляра ngctl

# kldstat

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

Проверяем происходит ли передача пакетов от фаервола IPFW к узлу ng_ipfw:

Произведём какие либо действия, приводящие к сетевому обмену, например обновление портов #portsnap fetch, или обновим интернет страницу на компьютере локальной сети стоящим за NAT. Далее запускаем команду просмотра правил IPFW:

# ipfw show | more

Ищем номера ipfw правил(первый столбец), указанных для ngtee и должны увидеть, что количество пакетов(второй столбец), к-во байт(третий) для каждого из правил не нулевое пример:

Правило 00440 направит/скопирует весь трафик попавший в правило в хук ipfw:10 модуля ng_ipfw. Правило 00450 направит/скопирует весь трафик попавший в правило в хук ipfw:20 модуля ng_ipfw. Правило 00460 направит/скопирует весь трафик попавший в правило в хук ipfw:30 модуля ng_ipfw.

Три правила 00440, 00450, 00460 использовались исключительно для примера, можно обойтись и одним для одного сетевого интерфейса.

В общем убедились, что из фаервола ipfw пакеты передаются в netgraph узел «ipfw:».

Чтобы не плодить конфигурационные файлы, в конфигурационный файл фаервола ipfw добавляем скрипт настройки узлов, плохо или нет туда его добавлять не знаю, всё работает. Добавляется до начала описания правил. Кусок конфигурационного файла фаервола:

#netgraph ipfw->ng_ipfw->ng_netflow->ng_ksocket->127.0.0.1:56783

/usr/sbin/ngctl -f- <<-SEQ

mkpeer ipfw: netflow 30 iface0

name ipfw:30 IPFWtoNetFlow

msg IPFWtoNetFlow: setdlt {iface=0 dlt=12} #Interfase type: possible 1 or 12

msg IPFWtoNetFlow: setifindex {iface=0 index=3} #Number equivalent re1 is 3

msg IPFWtoNetFlow: settimeouts {inactive=16 active=1801}

mkpeer IPFWtoNetFlow: ksocket export inet/dgram/udp

name IPFWtoNetFlow:export Ksock

msg Ksock: connect inet/127.0.0.1:56783 # nfcadp(nfsen)

SEQ

mkpeer ipfw: netflow 30 iface0 #производит создание безымянного узла типа netflow и устанавливает соединение между крючками ipfw:30 и <пока безымянный узел типа netflow>:iface0. Цифра 30 берётся из конфигурационного файла фаервола ipfw она идёт за именем правила ngtee. iface0 стандартное имя крючка для узла типа netflow.

name ipfw:30 IPFWtoNetFlow #назначаем имя «IPFWtoNetFlow» безымянному узлу типа netflow.

msg IPFWtoNetFlow: setdlt {iface=0 dlt=12} #устанавливаем тип интерфейса 12 для крючка iface0. Варианта два либо 1 либо 12, 1 установлен по умолчанию и здесь не подходит. 12 -принимать через iface0 чистые IP пакеты.

msg IPFWtoNetFlow: setifindex {iface=0 index=3} #Здесь устанавливаем номер интерфейса(параметр index=), в который пакет вошел. Каждому имени интерфейса re1 re2 nfe0 и т.д. сопоставляется некий номер. При некоторых вариантах реализации сетевого обмена получается так, что этот номер для узла ng_netflow неизвестен или неправильный и явное указание этого номера решает проблему. Предполагаю, что т.к. пакеты мы берём из ipfw то правильный индекс уже был проставлен и эта настройка ни на что не повлияет и нахрен не нужна. Но если уж приспичило, то для выяснения чему равен index=??? или номер сетевого интерфейса, с которого снимаем статистику, делаем следующее:

Создаём файл с расширением .c например if_nametoindex.c. В пустой if_nametoindex.c файл добавляем:

#include <sys/socket.h>

#include <net/if.h>

using namespace std;

#include <iostream>

int main(int argc, char **argv)

{ for (int i = 1; i < argc; i++)

{ cout << argv[i] << » = » << if_nametoindex(argv[i]) << «n»;

}

return 0;

}

ПЕРЕВОД СТРОКИ В КОНЦЕ ФАЙЛА ОБЯЗАТЕЛЕН

Находясь в тойже директории, что и if_nametoindex.c выполняем компиляцию:

# c++ -o if_nametoindex if_nametoindex.c

Появится исполняемый файл, который зелёный если через mc-light на него смотреть. Далее запускаем исполняемый файл:

# ./if_nametoindex «re1» «re2» «lo0»

re1 = 3

re2 = 4

lo0 = 7

Запускается одним или несколькими параметрами через пробел. В качестве параметра в main передаётся имя/имена сетевого/ых интерфейса/ов и в ответ выдаётся соответствующий номер, который и присваиваем index=3 для re1.

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

msg IPFWtoNetFlow: settimeouts {inactive=16 active=1801} #устанавливает таймауты активных и не активных потоков, после которых статистика будет отправлена в коллектор. Синтаксис «settimeouts { inactive=15 active=1800 }» По умолчанию таймаут активного потока 1800 секунд, не активного 15 секунд.

mkpeer IPFWtoNetFlow: ksocket export inet/dgram/udp #производит создание безымянного узла типа ksocket и устанавливает соединение между крючками IPFWtoNetFlow:export и <пока безымянный узел типа ksocket>: inet/dgram/udp.

name IPFWtoNetFlow:export Ksock #назначаем имя «Ksock» безымянному узлу типа ksocket.

msg Ksock: connect inet/127.0.0.1:56783 #Куда отправляем netflow данные задаём хост и порт, на который будут уходить наши пакеты. В текущем случае коллектор находится на этом же компьютере поэтому всё засылаем на loopback.

Перезапускаемся на всякий

Настройку цепочки «ipfw -> ng_ipfw -> ng_netflow -> ng_ksocket ->127.0.0.1:56783» закончили, проверим что получилось.

Проверяем собралась ли нужная нам цепь:

# ngctl

+ ls

Если вывод подобный, то всё в порядке.

Проверим принимаются ли данные в узел ng_netflow «IPFWtoNetFlow:»:

# ngctl

+ msg IPFWtoNetFlow: info

Видим, что чтото принимается.

Проверим отправляет ли узел «Ksock» что ни будь на 56783 порт. В конфигурационном файле фаервола прописываем разрешающее правило для 127.0.0.1 на 56783 порт и при наличии обмена, после команды

# ipfw show | more

можем видеть, что вторая и третья колонки соответствующего правила не нулевые, значит какие то данные узел «Ksock» передаёт, например, если вместо 127.0.0.1 был бы настроен 192.168.10.1, то увидим:

Убираем всё лишнее из конфигурационного файла ipfw.

Цепочка ipfw->ng_ipfw->ng_netflow->ng_ksocket-> inet/127.0.0.1:56783 настроена.

Теперь к 56783 порту теперь можем подключить какой либо коллектор. В текущем случае, подключаем либо nfsen(коллектор + веб морда), либо flow-capture(коллектор).

Установка/настройка коллектора flow-capture вместо nfdump(если устанавливаем nfsen, то раздел пропускаем):

Для разграничения nfsen и flow-capture коллекторов можно использовать разные номера портов. Можно настроить и одновременную работу, в этом случае нужно настроить несколько ksocket один на nfsen второй на flow-capture. Но для упрощения описания оставим настройки netgraph такими же. Т.е. если используем flow-capture то nfsen не запускаем и наоборот.

Устанавливаем из портов flow-tools:

# make install clean

Создаём каталог /usr/flows для хранения записей netflow потока. Группа flowtools и пользователь flowtools создаются автоматически при установке flow-tools.

Назначаем группу(flowtools) и владельца(flowtools) папке /usr/flows:

# chown -R flowtools:flowtools /usr/flows

В /etc/rc.conf добавляем строки:

#flow-tools

flow_capture_enable=»YES»

flow_capture_user=»flowtools»

flow_capture_group=»flowtools»

flow_capture_datadir=»/usr/flows»

flow_capture_localip=»127.0.0.1″ #ip машины, на которой запущен коллектор flow-tools

flow_capture_remoteip=»127.0.0.1″ #ip машины, с которой мы принимаем flow поток

flow_capture_port=»56783″ #порт коллектора flow-capture на котором он слушает и получает данные

flow_capture_flags=»-N 3 -n 288 -z 0 -E 100G -V 5 -S 5″

#-N3 хранение файлов данных в папках YYYY/YYYY-MM/YYYY-MM-DD/flow-file, задает глубину иерархии каталогов

#-n288 24*60/288=5min количество записей в день т.е. если =288 то файл создаётся раз в 5 минут

#-z0 уровень сжатия данных выбирается от 0 до 9. 0-без компрессии, 9-максимальная компрессия. На компрессию потребуется дополнительные ресурсы процессора.

#-E100G под данные netflow отводится 100G -100 гигабайт. По достижению предела, судя по всему данные будут циклически перезаписываться.

#Параметр -S5 указывает размер интервала в минутах, в течение которого flow-capture будет записывать информацию о счетчиках пакетов в лог-файл.

#-V5 версия netflow

#-S5 Интервал времени в минутах, по истечении которого демон будет генерировать статистику о числе полученных потоков, числе обработанных пакетов, а также число потерянных потоков. Информация заносится в системный журнал /var/log/messages. Правда не наблюдал, чтобы туда что либо записывалось.

Проверяем, чтобы в конфигурационном файле фаервола ipfw была строка

msg Ksock: connect inet/127.0.0.1:56783

Перезагружаемся и проверяем, запустился ли сервис flow-capture:

# sockstat -4 -l | grep flow

Если видим подобное, то всё в порядке. Проверяем также, что в папке /usr/flows с интервалом в 5 минут появляются файлы. Через mc-light выглядеть это будет так:

Можно по обновлять страницы в браузере, и убедиться, что размеры последующего файла будут меняться. Согласно настройкам за 24часа будет создано 288 файлов(параметр -n 288) файл раз в 5 минут. Если нужно запустить несколько копий flow-capture, необходимо задать несколько каталогов для записи данных в переменной flowcapture_dir. Прослушиваемый порт, в этом случае, будет автоматически увеличиваться на 1для каждой копии flow-capture.Например, пусть:

flowcapture_dir=»/var/netflow/in /var/netflow/out»

flowcapture_port=8818

Тогда данные, поступающие на порт 8818 буду попадать в каталог /var/netflow/in,а, поступающие на порт 8819 — в каталог /var/netflow/out.

Содранный пример настроек для нескольких коллекторов трафика, на случай если придётся(нижеприведённые строки настроек никуда не вписываем, не обращаем внимания):

# Разрешаем старт flow_capture

flow_capture_enable=»YES»

#Указываем ip адрес на котором будет слушать flow_capture

flow_capture_localip=»107.25.214.157″

#Делаем 2 разных коллектора трафика для 2 роутеров

flow_capture_profiles=»router1 router2″

#Директория где будут сохраняться принятые флоу записи для первого роутера

flow_capture_router1_datadir=»/var/db/flows/router1″

#Порт на котором слушает флоу для первый роутера

flow_capture_router1_port=»5632″

#Флаги для первого роутера

flow_capture_router1_flags=»-E20G -n287 -N-2″

#Далее аналогично, но для второго роутера

flow_capture_router2_datadir=»/var/db/flows/router2″

flow_capture_router2_port=»5633″

flow_capture_router2_flags=»-E5G -n287 -N-2″

flow-capture настроили. Теперь пользуясь различными flow-tools программами можно просматривать трафик на настроенном сетевом интерфейсе.

Установка/настройка nfsen apache22 php5

Устанавливаем в следующей последовательности:

apache22

PHP5 с поддержкой apache

nfsen

Устанавливаем web сервер apache22

# whereis apache22

apache22: /usr/ports/www/apache22

# cd /usr/ports/www/apache22

# make && make install && make clean

# rehash

в /etc/rc.conf добавляем строку

apache22_enable=»YES»

редактируем /usr/local/etc/apache22/httpd.conf

Listen 192.168.200.2:80 #-IP локальной сети, сетевой карты компьютера, на котором установлен apache. Apache будет обрабатывать запросы пришедшие только на этот сетевой интерфейс и на указанный порт.

ServerName 192.168.200.2 #Можно не указывать, но на всякий случай рекомендуют чтоб было. Поскольку DNS записи нет, то в качестве имени указываем IP

DocumentRoot «/usr/local/www/nfsen»

Или

DocumentRoot «/usr/local/www/apache22/data»

Alias /nfsen «/usr/local/www/nfsen»

После:

<Directory />

AllowOverride None

Order deny,allow

Deny from all

</Directory>

Добавляем:

<Directory «/usr/local/www/nfsen»>

Options Indexes FollowSymLinks

DirectoryIndex nfsen.php

AllowOverride None

Order allow,deny

Allow from all #1 Что в строках 1 и 2 написать решаем сами

#Allow from 192.168.ля.ля #2 в общем случае доступ разрешён отовсюду

</Directory>

Комментируем:

#<Directory «/usr/local/www/apache22/data»>

# Options Indexes FollowSymLinks

# AllowOverride None

# Order allow,deny

# Allow from all

#</Directory>

Раз комментируем

# Various default settings

Include etc/apache22/extra/httpd-default.conf

Комментируем:

#<IfModule ssl_module>

#SSLRandomSeed startup builtin

#SSLRandomSeed connect builtin

#</IfModule>

После установки php проверяем, чтобы в конце файла были строки:

Include etc/apache22/Includes/*.conf

AddType application/x-httpd-php .php

AddType application/x-httpd-php-source .phps

Редактируем /usr/local/etc/apache22/extra/httpd-default.conf

Timeout 300

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 5

UseCanonicalName Off

AccessFileName .htaccess

ServerTokens Prod

ServerSignature Off

HostnameLookups Off

файл /usr/local/etc/apache22/httpd.conf проверяем на ошибки командой
# apachectl configtest

Syntax OK

Всё хорошо.

Просто инфа: управление apache возможно следующими командами:

# apachectl start
# apachectl restart
# apachectl graceful
# apachectl stop

Устанавливаем PHP5, для apache22 и nfsen.

# whereis php5

php5: /usr/ports/lang/php5

# cd /usr/ports/lang/php5

# make && make install && make clean

Нужно, чтобы была выбрана опция Build Apache module

Если в процессе установки/переустановки окно с опциями не появилось, то:

# make deinstall удаляем то, что было установлено

# make config вызов

# make && make install && make clean снова установка

Проверяем, чтобы в /usr/local/etc/apache22/httpd.conf появились строки:

…

…

LoadModule php5_module libexec/apache22/libphp5.so

…

…

AddType application/x-httpd-php .php

AddType application/x-httpd-php-source .phps

Если последние 2 строки не появились, добавляем их вручную в конец файла.

Устанавливаем nfsen:

nfsen не работает с flow-tools данными, он использует свой коллекто nfdump, у которой свой формат хранения netflow данных, отличный от flow-tools. Но есть ft2nfdump — конвертор данных из формата flow-tools в nfdump.

Нужно проверить версию порта libtool

# pkg_info | grep libtool

Во время текущей установки, с версией libtool-2.2.10 выдаётся ошибка и требует обновления до 2.4. Обновляем через portupgrade. Если не установлен portupgrade, то ставим:

Инфа про portupgrade:

-r с рекурсивным обновлением всех зависимостей

-b создание резервной копии старых версий пакетов

-a обновление всех установленных пакетов

-f форсированное обновление пакетов — здесь следует подробно изучить UPDATING

Вместо имени обновляемого пакета могут использоваться выражения, например при обновление всех пакетов начинающихся на php5 можно использовать команду: #portupgrade ‘php5*’

Настройка поведения portupgrade производится в файле /usr/local/etc/pkgtools.conf.

# rehash

Проверяем, какие порты можно обновить:

# pkg_version -v | grep «need»

Выводится ряд строк, в том числе и:

libtool-2.2.10 < needs updating (port has 2.4_1)

Смотрим информацию о пакете:

# pkg_info | grep libtool информация о порте

# portupgrade libtool обновление порта

# pkg_info | grep libtool информация о порте

libtool-2.4_1 Generic shared library support script

libtool обновили до libtool-2.4_1

снова запускаем установку пакета nfsen, вместе с ним установятся все нужные зависимости:

# rehash

Если в процессе установки периодически наблюдаем строки

«===> WARNING: Vulnerability database out of date, checking anyway»

То ждём, когда закончится установка и делаем:

# portaudit -Fad

Если portaudit не установлен, то ставим.

Видим, что с пакетом косяк «Affected package: ruby-1.8.7.302,1»

# pkg_version -v | grep «need» выводим список портов, которые можно обновить

И в списке видим ruby-1.8.7.302,1

# portsnap fetch ;на всякий

# portupgrade ruby обновление порта

# pkg_info | grep ruby

ruby-1.8.7.352_2,1 An object-oriented interpreted scripting language

# portaudit -Fad

auditfile.tbz 100% of 72 kB 62 kBps

New database installed.

Database created: Wed Jan 18 01:45:00 GMT-4 2012

0 problem(s) in your installed packages found.

Теперь всё ок.

# find / -name ft2nfdump

/usr/local/bin/ft2nfdump

Видим, что nfdump и нужный нам ft2nfdump установлены.

Если нужно, то для проверки возможности конвертации из файлов созданных flow-capture в файлы nfdump производим такое преобразование над одним из файлов.

ns1# ft2nfdump -r /usr/flows/2012/2012-01/2012-01-17/ft-v05.2012-01-17.000459+0400 | nfdump | less

Date flow start Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows

2012-01-17 00:04:12.429 0.000 UDP 85.21.78.91:123 -> 120.18.125.114:123 1 76 1

2012-01-17 00:04:12.429 0.000 TCP 61.128.172.133:16348 -> 120.88.125.114:22 1 48 1

2012-01-17 00:04:25.429 4.000 TCP 94.245.82.12:80 -> 120.88.125.114:42055 3 308 1

…

…

…

Видим, что один из файлов netflow потока созданный flow-capture был прочитан, даже видим, что какая то зараза на 22й порт ломится во второй строке. И данные какого то сервера времени на 123й порт.

Просто инфа про управление nfsen

Файл настроек nfsen находится в /usr/local/etc/nfsen.conf

Запуск nfsen:

/usr/local/bin/nfsen start

# nfsen start

Перезапуск после внесения изменений в /usr/local/etc/nfsen.conf

/usr/local/bin/nfsen reload

# nfsen reload

# nfsen stop

Всегда проверяем на ошибки syslog файл /var/log/messages

Для автозапуска nfsen можно, например в конфигурационный файл файервола, добавить строку:

#Nfsen start:

/usr/local/bin/nfsen start

Запустим nfsen:

# nfsen start

Видим, что стартовало 3 коллектора настроенных по умолчанию, они не нужны, отключаем. Информация собираемая коллекторами находится в папке /usr/local/var/nfsen/profiles-data/live

В файле конфигурации /usr/local/etc/nfsen.conf отключаем три работающих коллектора. Точнее 2 коллектора и один(upstream1) не нашол что это такое. Сбор информации, по умолчанию, производится с источников peer1 peer2 и upstream1. Для их отключения параметру ‘port’ присваиваем значение 0:

%sources = (

‘upstream1’ => { ‘port’ => ‘0’, ‘col’ => ‘#0000ff’, ‘type’ => ‘netflow’ },

‘peer1’ => { ‘port’ => ‘0’, ‘IP’ => ‘172.16.17.18’ },

‘peer2’ => { ‘port’ => ‘0’, ‘IP’ => ‘172.16.17.19’ },

);

# nfsen stop

# nfsen start

Видим, что коллекторы отключены, отлично.

Проверяем работу nfsen, пока без файлов данных:

В браузере набираем, ну или какой адрес был выбран:

http://192.168.200.2/nfsen/nfsen.php

Если в браузере видим:

ERROR: nfsend connect() error: No such file or directory!

ERROR: nfsend — connection failed!!

ERROR: Can not initialize globals!

Значит nfsen не запущен

# nfsen start

В браузере видим что то вроде этого:

Переходим на вкладку Stats и видим:

Подобные проблемы возможно возникают, если вопрос с переходом на летнее/зимнее время, в связи с его отменой, был решён при копировании файла /usr/share/zoneinfo/Etc/GMT-4 (если для московского времени) в папку /etc и последующим его переименованием в localtime. При таких действиях на команду

# date будет следующий вывод.

В общем нужно сделать всё по честному:

# whereis zoneinfo

zoneinfo: /usr/ports/misc/zoneinfo

# cd /usr/ports/misc/zoneinfo

# make && make install && make clean

# tzsetup

Появляется первый диалог отвечаем нет, далее по ходу пьесы

Рекомендуется сделать перезагрузку, далее

# date

Thu Jan 19 17:00:15 MSK 2012

Всё отлично

Проверяем, что получилось и… ничего не получилось, ну хоть время стало временней чем было.

Тогда файл /usr/local/etc/php.ini-production копируем в эту же директорию /usr/local/etc/ с заменой имени на php.ini, далее в php.ini находим строки:

[Date]

; Defines the default timezone used by the date functions

; http://php.net/date.timezone

;date.timezone =

Раз комментируем (удаляем четвёртую строку и присвоим ей следующее значение:

date.timezone = Europe/Moscow

либо перезапускаем apache, либо компьютер, проверяем что получилось:

Предупреждений нет, пол дела сделано. Для полного фен Шуя нужно установить ntp сервер времени, как это сделать и зачем оно надо, можно посмотреть в сети.

Настраиваем коллектор nfdump на приём данных от ранее настроенного сенсора:

конфигурации nfsen /usr/local/etc/nfsen.conf

# nfsen stop

Заменяем существующие настройки для %sources = (… на строки:

%sources = (

‘allin’ => { ‘port’ => ‘56784’, ‘IP’ => ‘127.0.0.1’ },

);

allin здесь имя папки /usr/local/var/nfsen/profiles-data/live/allin в эту папку коллектор и будет складывать все данные.

ns1# nfsen start

Configured sources do not match existing sources. Run ‘nfsen reconfig’ first!

ns1# nfsen reconfig

New sources to configure : allin

Remove configured sources: peer2 upstream1 peer1

Continue? [y/n] y

Add source ‘allin’

…

…

Подождём минут 15 и посмотрим в папку /usr/local/var/nfsen/profiles-data/live/allin там должны появиться файлы коллектора.

В браузере пишем http://192.168.200.2/nfsen/nfsen.php и видим что то похожее на картинку ниже. На картинке данные накопленные за несколько дней. В общем что то видим.

На картинке не показана нижняя часть со статистикой.

Как, что, и где настраивается в nfsen смотрим в сети.

Подгрузить существующие данные, собранные не nfdump получилось, но картинок для них не строится. Т.е. графики видны только для данных собранных местным nfdump коллектором. Данные сконвертированные из flow-capture можно посмотреть через фильтр в nfsen, но графики для них не рисуются. Как произвести преобразование из flow-capture в nfdump и поместить в nfsen речь пойдёт ниже.

На всякий поставим на сбор данных ещё и flow-capture коллектор, что удобней будет потом разберёмся, благо трафик никакой и места лишнего на винчестере полно.

Установка одновременно работающих коллекторов flow-capture и nfdump

ng_hub — принимает данные на любом подключенном хуке с произвольным именем, и отправляет эти данные без изменений на все подключенные хуки. Контрольных сообщений не принимает.

В конфигурационном файле фаервола меняем скрипт настройки netgraph. Добавляем модуль ng_hub, для размножения потоков netflow v5 на 2 порта для flow-capture и nfdump, меняем скрипт настройки netgraph на следующий:

# NETGRAPH

# ipfw->ng_ipfw->ng_netflow->ng_hub|-> ng_ksocket->127.0.0.1:56783 #flow-capture

# |-> ng_ksocket->127.0.0.1:56784 #nfdump

/usr/sbin/ngctl -f- <<-SEQ

mkpeer ipfw: netflow 30 iface0

name ipfw:30 IPFWtoNetFlow

msg IPFWtoNetFlow: setdlt {iface=0 dlt=12} #Interfase type: possible 1 or 12

msg IPFWtoNetFlow: setifindex {iface=0 index=3} #Number equivalent re1 is 3

msg IPFWtoNetFlow: settimeouts {inactive=16 active=1801}

mkpeer IPFWtoNetFlow: hub export hook0

name IPFWtoNetFlow:export hubb

mkpeer hubb: ksocket hook1 inet/dgram/udp

name hubb:hook1 KsockFC

msg KsockFC: connect inet/127.0.0.1:56783 #for flow-capture collector

mkpeer hubb: ksocket hook2 inet/dgram/udp

name hubb:hook2 KsockNFCD

msg KsockNFCD: connect inet/127.0.0.1:56784 #for nfdump(nfsen) collector

SEQ

Кому хочется можно ng_hub, запускаемый модулем на данный момент, скомпилировать с ядром (options NETGRAPH_HUB).

Можем посмотреть, что подгруженно как модуль:

# kldstat

Конвертация/ преобразование уже имеющихся данных netflow v5 к формату nfcapd для просмотра статистики через web интерфейс nfsen 1.3.5. Но, графики для внешней статистики nfsen 1.3.5 не строит

Файлы netflow v5 сгенерированные flow-capture будут конвертированы и помещены в нужные папки, согласно текущим настройкам иерархии директорий nfsen. nfsen настроен и работает.

В файле /usr/local/etc/nfsen.conf добавляем запись отключённого коллектора flowcapt параметр ‘port’ => ‘0’. Работающий коллектор allin, или то что у вас настроено не трогаем.

%sources = (

‘flowcapt’ => { ‘port’ => ‘0’, ‘col’ => ‘#0000ff’, ‘type’ => ‘netflow’ },

‘allin’ => { ‘port’ => ‘56784’, ‘IP’ => ‘127.0.0.1’ },

);

Далее:

# nfsen stop

Configured sources do not match existing sources. Run ‘nfsen reconfig’ first!

# nfsen reconfig

New sources to configure : flowcapt

Continue? [y/n] y

Add source ‘flowcapt’

Start/restart collector on port ‘0’ for [no collector]

Restart nfsend:[68019]

Появилась новая директория /usr/local/var/nfsen/profiles-data/live/flowcapt

Пусть данные netflow v5 созданные flow-capture коллектором находятся в папке /usr/flows

Качаем утилиту sfttonf и конфигурационный файл к ней. Помещаем sfttonf и конфигурационный файл пускай в одну и туже папку /aa. Что за sfttonf такой описано ниже.

sfttonf использует ft2nfdump конвертор netflow v5. Не знаю, конвертирует ли ft2nfdump сжатые данные flow-capture, проверял только на не сжатых.

Убеждаемся, что в /usr/local/etc/nfsen.conf параметр:

$SUBDIRLAYOUT = 1; это # 1 %Y/%m/%d year/month/day -иерархия директорий, в которых хранятся данные, эту структуру можно менять, но потребуется перезапуск nfsen и некоторые манипуляции о которых nfsen сообщит при запуске. nfsen stop, nfsen start.

К месту, nfsen читает как сжатые, так и несжатые nfcapd. Файлы.

Редактируем конфигурационный файл sfttonf.conf, в текущем случае интересует только одна строка /usr/flows > /usr/local/var/nfsen/profiles-data/live/flowcapt %Y/%m/%d %z которая означает: брать flow-capture файлы из /usr/flows преобразовывать, сжимать(%z) и помещать в /usr/local/var/nfsen/profiles-data/live/flowcapt/YYYY/mm/dd согласно году месяцу и дате содержащимся в имени их файла. Параметр %z означает что выходные файлы nfcapd. будут сжиматься. %Y/%m/%d такая иерархия директорий соответствует параметру $SUBDIRLAYOUT = 1; в /usr/local/etc/nfsen.conf. Nfsen жестко привязан к иерархии папок, в которых хранятся netflow данные. А также к именам файлов данных, и даже к времени их создания раз в 5 минут.

НАЧАЛО конфигурационного файла для sfttonf

…

…

# For creation sub hierarchy you can use %Y %m %d %H key words and another character

# in any combination

# If key words for sub hierarche will not be used that will be used sub hierarchy the sam

#—EXAMPL————————EXAMPL——————————EXAMPL—

#</flow-capture source folder> > </nfsen destination folder>

#</flow-capture source folder> > </nfsen destination folder> %Y / %m / % d %z

#</flow-capture source folder> > </nfsen destination folder> %Ybla /%Ybla%mb

#</flow-capture source folder> > </nfsen destination folder> %Y/%Y-%m/%Y-%m-%

#—————————————————————————

/usr/flows > /usr/local/var/nfsen/profiles-data/live/flowcapt %Y/%m/%d %z

# /3 > /T5 %Y/%m/%d

#/usr/flows > /T6 %Y/%m/%d

#/usr/flows > /T3 %Ynah%de%mhr%H/lala%H%Y/%mmumu

#/usr/flows/in > /usr/local/var/nfsen/profiles-data/live/allin

#/usr/flows/out > /usr/local/var/nfsen/profiles-data/live/allout

#ServSt. Not remove last string

ОКОНЧАНИЕ

Запускаем из /aa директории sfttonf:

# ./sfttonf /etc/sfttonf/sfttonf.conf

…

…

ft2nfdump -r /usr/flows/2012/2012-02/2012-02-01/ft-v05.2012-02-01.011945+0400 | nfdump -z -w /usr/local/var/nfsen/profiles-data/live/flowcapt/2012/02/01/nfcapd.201202010119

ft2nfdump -r /usr/flows/2012/2012-02/2012-02-01/ft-v05.2012-02-01.012443+0400 | nfdump -z -w /usr/local/var/nfsen/profiles-data/live/flowcapt/2012/02/01/nfcapd.201202010124

ft2nfdump -r /usr/flows/2012/2012-02/2012-02-01/ft-v05.2012-02-01.012943+0400 | nfdump -z -w /usr/local/var/nfsen/profiles-data/live/flowcapt/2012/02/01/nfcapd.201202010129

Convertion finished

=== anteh.ru ===

Выполняем команды:

# nfsen -r live #что то вроде применения последних изменений

После выполнения должен появиться файлик .nfstat в /usr/local/var/nfsen/profiles-data/live/flowcapt.

# nfsen -l live #проверка применения последних изменений

Набираем в браузере:

http://<ip адрес на котором слушает web сервер>/nfsen/nfsen.php

приведу ещё раз картинку с настроенным nfsen, графики от встроенного nfdump коллектора, от внешне подключённой статистики графиков не будет.

Нижняя часть скриншота не влезла

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

Не удалось разобраться, почему nfsen не рисует графики для внешних netflow баз статистики. Даже если свои собственные прикреплять как внешние(копирование существующей nfcapd статистики в …/live/<папка>), то графиков всё равно не видно. Возможно нужны какие-то манипуляции с RRDTool. Но просматривать статистику для внешних баз, через фильтр по web интерфейсу, можно, но только с профиля live, собственно что ещё нужно. Ни с одного созданного профиля что-либо прочитать не удалось.

Для работы с внешней подключённой базой нужно на вкладке details в профиле live в нижней части экрана после надписи Netflow Processing выбрать Source: ранее созданный flowcapt. Чтобы просматривать статистику через фильтр на пустом графике нужно указать диапазон времени, в котором будем просматривать базу. Нужно выбрать channel: только flowcapt затем Select->Time window и растащить курсор в разные стороны, попутно выбрав в Display масштаб времени за который нужно просматривать статистику. Задать какое-нибудь значение в фильтре, например any. И ещё левой половиной курсора просмотра на графике умудриться попасть в нужный начальный интервал времени, короче должен существовать файл с именем содержащем такую же дату и время, как указано в параметре tstart 2012-02-01-02-45 иначе будет выдано предупреждение, что такого файла нет. Можно файл в ручную переименовать, или посмотреть, чтобы такой существовал и выставить на него левую границу курсора. Но если учесть что коллектор nfdump формирует файлы только каждые 5 минут, а nfsen заточен строго на эти 5 минут, а файлы flow-capture не выровнены по границе в 5 минут и при преобразовании имя файла остаётся таким же, то даже если в настройках flow-captute стоит параметр 288 файлов в день(в лучшем случае), ааа б… какого….

В общем так и живём.

Основные неприятности с временной разбивкой файлов, nfsenу нужны файлы с именами выровненными по 5 минут. Опробовалась версия nfsen 1.3.5, возможно с последующими версиями будет попроще, а то скриншоты на программу всегда аж с переливающимися всеми цветами радуги картинками, а на деле пользоваться конечно можно…. В общем со временем разберёмся.

В теории с помощью sfttonf можно nfdump коллектор заменить на flow-capture коллектор. Задумка по началу заключалась именно в этом, но из за проблем с текущей версией nfsen-1.3.5 подобное решение не реализовывалось. Зачем вообще это нужно? Ну возможно, чтобы не использовалась библиотека libcap, возможность использования flow-tools, да и мало ли для чего ещё. Правда не знаю поддерживает ли ft2nfdump что-либо кроме netflow v5 и работает ли он с сжатыми flow-capture файлами.

The nfs server is running Arch Linux. The nfs client below («pc1») is running Ubuntu 16.04. Both are using nfs4.

root@PC1:~# cat /etc/fstab (relevant line shown below):

server:/backup/system/pc1 /backup/system nfs4 auto,noatime        0 0

After the client boots, the nfs mount fails: journalctl -b -p err (output shown below):

Aug 25 17:56:43 LatishaPC1 systemd[1]: Failed to mount /backup/system.

root@PC1:~# showmount -e server (output shown below):

Export list for server:
/export                          192.168.1.0/24
/export/backup/system            192.168.1.0/24
/export/backup/system/pc1 192.168.1.8

manually trying to mount (as root) using mount /backup/system gives this output:

mount.nfs4: mounting server:/backup/system/pc1 failed, reason given by server: No such file or directory

However, we see from showmount that the server does list the directory.

Here’s the /etc/exports file on the server:

/export 192.168.1.0/24(fsid=0,rw,sync,no_subtree_check)                                                            
/export/backup/system/ 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check,nohide)
/export/backup/system/pc1 192.168.1.8(rw,sync,no_root_squash,no_subtree_check)

I tried it without and without that last line above. Same error either way.
I’ve been troubleshooting for several days and have not resolved it. (I have other nfs servers and clients that are working as expected and I have compared this config to the working systems and I don’t see a difference.) I checked many similar questions. I’m probably overlooking an obvious answer. I apologize in advance if this has already been answered somewhere on StackExchange. I didn’t find a solution yet.

UPDATE 1:

The client can mount server:/ and mounting that gives another clue. When navigating the mount to /backup/system/, the directory is empty. It should contain «pc1» as shown in the showmount command above.

Here are the file permissions as shown on the server.

[root@server export]# cd backup/
[root@server backup]# ls -la
drwxr-xr-x 1 root         root   76 Jun  3 02:31 .
drwxr-xr-x 1 root         root   12 Aug 25 02:44 ..
drwxr-xr-x 1 root         root  142 Jul  5 19:58 system
[root@server backup]# cd system/
[root@server system]# ls -la
drwxr-xr-x 1 root root 142 Jul  5 19:58 .
drwxrwx--- 1 root root   6 May 28 11:35 pc1

UPDATE 2:
output of root@PC1:~# ip a follows. It shows that the IP address listed in /etc/exports on the server is correct.

2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.1.8/24 brd 192.168.1.255 scope global dynamic enp0s31f6