Ineu

perl -e 'print "$_\n" for (@INC)' - выведет список каталогов, в которых перл ищет включаемые файлы. Добавить каталог - push @INC, '/путь/к/каталогу'

Michail писал(а) Tue, 11 July 2006 14:20 Тоесть? Какие пути? perl виден, пути к нему прописаны. Должно все работать! Пути К МОДУЛЮ. Причем тут пути к интерпретатору перла????

То есть ipacc считает то, что посчиталось бы по ULOG, будь он последним правилом в цепочке?

Итак, наблюдения на данный момент: Несколько устройств, управляемые одним драйвером, определяются в порядке нумерации на шине PCI, то есть в порядке установки в в слоты (если, конечно, материнка спроектирована нормально ). Тенденции в порядке определения устройств с разными драйверами не заметил никакой, поэтому единственный выход - собирать дрова модулями и подгружать их в нужном порядке. ЗЫ. Встроенная сетевуха у меня - последнее устройство на шине, так ли на других матерях?

Spank писал(а) Tue, 11 July 2006 09:00 Фильтрация пакетов IP идет на сетевом уровне, а как известно например tcpdump работает на канальном уровне. Тоесть если я пишу: iptables -A FORWARD -d 1.1.1.1 -j ACCEPT то билланг основанный на libpcap это пощитает, а я не хочу. Ну и в таком же духе. хм... tcpdump -i any dst not 1.1.1.1?

Не дошло... и вряд ли дойдет, потому как от домашней машины я особо много не требую, а на серваке такое делать что-то не очень хочется Хотя мб на днях на домашней переберу таким образом ядро, поглядим, что получится... О результатах сообщу ЗЫ. Кстати, ядро - 2.6.16-gentoo-r9

Byte писал(а) Mon, 10 July 2006 22:48 ну, знаете-ли... это смотря какими способами... я вот насчитал парочку мне известных: 1. галочками в свойствах мультимедия 2. программно 3. удалить/установить драйвер 4. отключить устройство в свойствах 5. удалить фалы дров 6. выдернуть плату из материнки 7. выключить питание.... .... может еще есть... уверен.... вот только еще остальные способы не выучил... ведь виндовс она как - многозадачная система, понимаете-ли... Выдернуть плату из материнки - это настолько радикальное отключение Виндовс Аудио, что может сказаться даже на других ОСях Я, собсно, подразумевал службу Виндозную, которая живет в services.msc

Собрал с make allmodconfig. На проце 2.8 ГГц собиралось 1 час (!) Размер файла bzImage - 1360k Размер /lib/modules/... - 395м (триста девяносто пять метров - прописью, если кто не верит ) Практически четыреста метров бинарников... Мне ночью буду кошмары сниться

2Byte ЗЫ. А как по-Вашему, много людей знают о возможности включения/выключения Windows Audio?

Ну да... а как эта хрень будет грузиться...

Сабж дает ядро с размером файлы bzImage - 12867k, размер /lib/modules... - 3 с лишним метра. После этого делать make allmodconfig боюсь

Byte писал(а) Mon, 10 July 2006 19:45 ухты!!!! до чего техника дошла: права на использование аудио устройств!!!! прям виндовс!.. )) Докатились... Скоро Фришный стек TCP/IP будет "прям Виндовс"

lelik9 писал(а) Mon, 10 July 2006 18:06 И еще, нормально ли то что у меня дисккэш отжирает от оперативы 5оо мегов??? всего памяти у меня гиг. Нормально

Можно и в скрипт, но не нужно, поскольку для настройки ядра есть специальный механизм. Вам надо будет внести подправить /etc/sysctl.conf. Как это сделать - man sysctl

iptables - это хорошо, но зачем привлекать тяжелую артиллерию, если все можно сделать намного проще? echo 0 > /proc/sys/net/ipv4/ip_forward - это запрет форвардинга, то есть пересылки пакетов между интерфейсами.

Spank писал(а) Mon, 10 July 2006 13:31 2. Библиотеки снифера не рулят, так как будут щитать трафик задропаный в iptables. Это с чего они себя будут так вести? Цитата: 4. Все они повторно разбирают пакет уже разобранный системой. Зачем делать 2 раза одно и тоже, к тому же это может быть критично на слабых роутерах. На слабых роутерах критична в первую очередь обработка прерываний для сетевых карт, поэтому при достаточно большом потоке трафика о слабых машинах можно забыть. К тому же в случае логирования сведений о пакете согласно заголовка, сколько же должно быть пакетов, чтоб была видна разница в скорости между решениями ядерным и пользовательского уровня?

А чем ipcad/netflow не устраивает?

Пока нашел одно решение - собирать все дрова модулями, а потом подгружать в нужной очередности. Правда, работает это только для разных карточек/чипов, если, например, 2 одинаковых - проблема остается ЗЫ. Кста, довольно интересно получается, когда потом rmmod'ом какой-нибудь модуль удаляешь, пропадает устройство соответствующее, то есть в системе, например, есть eth1, а вот eth0 нету

Приветствую! Проблема: ядро определяет сетевые карты в весьма произвольном порядке. Стояло у меня на мосту 6 сетевух - одна интегрированная, три 100мб и две 1гб. Гигабитные стояли в нижних PCI и определялись как eth{4,5}. Поменял местами. Порядок установки карточек в PCI сверху вниз - 1гб, 1гб, 100мб, 100мб, 100мб. При это гигабитные все равно определяются как eth{4,5}. Хочется, чтобы они определялись согласно их расположению в слотах. Как очевидное решение - жестко скармливать ядру при загрузке параметры сетевух, но при смене карточки придется много менять

2.4 - man devfsd 2.6 - man udev

ZeUsM писал(а) Fri, 07 July 2006 10:54 Мож фаер какой стоит по умолчанию в Мастере, ставил по дефолту убирал установку серверных частей (DNS, MAIL и т.д.) Все может быть. /etc/init.d/iptables stop

Доброго времени суток! Думаю, не только у меня при усложнении дерева классов в tc возникает сабжевый вопрос. Если кто-нибудь его красиво и эффективно решил, просьба поделиться опытом. Имхо, все, кто может ответить на этот вопрос, не нуждаются в рассказах, что это и как работает, но тем не менее приведу несколько замечаний, которые могут помочь в размышлениях. Заодно прошу меня поправить, если что-то пропущу или скажу неточно. Итак 1. Набор правил управления трафиком строится в виде дерева. Узлами его являются пары класс/присоединенная к нему дисциплина. Каждая дисциплина (речь не идет о простейших бесклассовых дисциплинах) может иметь в принципе неограниченное кол-во подклассов, каждый из которых - свою дисциплину и т.д. 2. Каждый элемент узла (дисциплина/класс) имеет уникальный дескриптор, использующийся для дальнейшего построения дерева и в фильтрах. Дескриптор состоит из двух двухбайтных величин - старшего и младшего номеров. 3. Старший номер класса повторяет старший номер родительской дисциплины. Младший номер любой дисциплины равен 0. 4. Корневой дисциплине назначается дескриптор 1:0 (не отступая от канонов ) Интересует система назначения дескрипторов. Вытекающие из вышесказанного ограничения: 1. Дескриптор корневой дисциплины - 1:0 2. Количество классов на каждом уровне неограничено. 3. Количество уровней дерева неограничено 4. Максимальное значение старшего/младшего номера - 2**16 5. Необходима возможность добавления ветки на любой из уровней дерева без необходимости изменения системы именования 5. Необходима возможность определения ветки/родителя по дескриптору Стандартная система, приводимая во многих статья по tc, состоит в том, что при переходе на каждый новый уровень старший номер дескриптора увеличивается на один ноль. Например, для дерева * / \ * * / \ \ * * * .............. получаем следущую систему нумерации (для ветки 2): 0 root qdisc 1:0 1 1.1 class 1:2 1.2 qdisc 20:0 2 2.1 class 20:1 2.2 qdisc 200:0 3 3.1 class 200:1 3.2 qdisc 2000:0 4 4.1 class 2000:1 4.2 qdisc 20000:0 5 5.1 class 20000:1 5.2 qdisc 200000:0 # 200 000 > 65536 Такая схема не устраивает, поскольку уже на пятом уровне происходит превышение старшего номера над максимально возможным. Теоретически количество подклассов для каждого уровня может достигать 2**16, а практически это нарушает ограничение 5, т.к. в такой схеме старшие номера дескрипторов следующего уровня определяются как номер ветки * (10 ** уровень), что уже для 200 класса на первом уровне (и, соотв, для 200 ветки) потребует дескриптора потомка 200 * (10 ** 1) = 2000, а для следующего уровня - 200 * (10 ** 2) = 20000, т.е. кол-во уровней сокращается до двух Если есть мысли насчет другой системы именования - прошу высказываться

Живем!!! Блин, я уж боялся, что конец форуму пришел... но линухру живее всех живых. Ура!

С4в­"$ФнЩS„ж‡кK¤Y[Ґ¤Ёn"іt