Ознакомьтесь с нашей политикой обработки персональных данных
  • ↓
  • ↑
  • ⇑
 
Записи с темой: Работа (список заголовков)
16:16 

Матерное, рабочее.

19:33 

Одной строкой:

Политика использования MS IE в установке-по-умолчанию MS Server 2008 R2 полностью совпадает с моим видением этого продукта: Он есть. Он кое-как работает. Пускать его в интернет НЕЛЬЗЯ.
HP-шники со своим ML100 G6 совсем с дубу рухнули - ни на офсайте, ни уж тем более на диске с дровами НЕТ драйвера видеоадаптера для 2008 R2 x64, при том, что этот самый R2 - официально рекомендованная для этого сервера ОС. Впрочем, для 2008 x86 их тоже нет. Зато они есть для ML110 G5. Даже работают. Мораль by HP - "гую фтопку, ставьте CORE-ку", видимо.
Переход от FreeBSD (IPFW+DeleGate) к Windows XP + Traffic Inspector - полный отвал башки и вынос мозга. Хрен знает, на что и для кого эта прога рассчитана - для SOHO - слишком замудоглючна, для ENT-сегмента прокси-сервер-шлюз на вынь ХрюХрю как-то даже... не смешно. Впрочем, в качестве биллинг-системы для домашней сети или там какой-нибудь семейной гостиницы, наверное, сгодится...

@темы: Работа

16:38 

Продолжим, помолясь

После обнаружения в анализируемой сети активных хостов атакующий переходит к следующему этапу - попытке определить список доступных сетевых служб на целевой машине. Для этого используется т.н. технология "сканирования портов".
Наиболее распространены следующие типы сканирования:
- сканирование "полусоединением", оно же stealth, tcp syn и пр.
- сканирование с нестандартной установкой tcp-флагов
- UDP-сканирование
Для решения специфических задач (Определение правил брандмауэра, обход брандмауэра, сканирование нестандартных систем и пр) могут так же использоваться TCP ACK сканирование, сканирование Мэймона и TCP-window сканирование.
Проще всего справиться со сканированием с нестандартной установкой флагов:
ipfw add deny all from any to any tcpflags syn,fin,ack,psh,urg,rst - NULL-scan
ipfw add deny all from any to any tcpflags !syn,!fin,!ack,!psh,!urg,!rst XMAS-scan
ipfw add deny all from any to any not established tcpflags fin FIN-сканирование.
UDP-сканирование само по себе штука не простая - открытые порты почти всегда (Зависит от службы) не отвечают на запрос, фильтруемые порты не отвечают тем более, а закрытых портов при правильно настроенном файрволле у нас просто нет ).
Увы, самый простой, самый быстрый и самый надежный способ (Используемый nmap'ом по умолчанию) заблокировать практически невозможно: syn-пакет является частью легитимного процесса установления соединения. В процессе подобного сканирования _можно_ обнаружить две аномалии - резкое увеличение пакетов с rst-флагом приходящих с одного адреса и большое количество попыток установления соединения. Теоретически, это можно использовать для попытки обнаружения сканирования, но на практике все не так просто. Используя ipfw можно попытаться ограничить число одновременных попыток соединения, но поможет это мало - даже последовательный перебор всех 65535 портов занимает порядка 20 секунд, пытаться "ускорить" этот процесс - нет особого смысла. Попытка обнаружить аномальное увеличение RST-пакетов с помощью IDS так же не приведет к успеху, т.к. установление соединений с закрытыми портами будет заблокировано межсетевым экраном и собственно увеличения - не произойдет.
Таким образом, можно с уверенностью сказать, что атакующий _получит_ список запущенных на целевой машине сетевых служб, и с этим мало что можно сделать.

@темы: FreeBSD, Работа

16:36 

Ну и еще немного о...

... firewall'ах (На примере IPFW) - вдруг кому интересно? ))

Основные требования к правилам межсетевого экрана - читаемость и производительность. Если первое более-менее понятно (Кому не понятно - откройте дефолтовый rc.firewall FreeBSD и никогда, никогда, НИКОГДА не повторяйте то, что там увидите!), то со вторым надо разобраться чуть по-подробней.
От чего зависит производительность firewall'а? От количества операций сравнения, которые производит межсетевой экран над полученными в результате анализа пакета данными. Оно, в свою очередь, определяется количеством правил, которое проходит пакет и числом критериев, по которым производится сравнение.
Для примера возьмем несколько достаточно стандартных правил из Handbook'а:
Что мы видим? Любой пакет, направленный "к нам" будет последовательно сравниваться с правилами, предназначенными для "исходящих" пакетов (0-299) и только потом дойдет до правил, предназначенных собственно для обработки пакетов "входящих", кроме того, в каждом правиле предусмотрена проверка "направления движения" пакета и интерфейса, через который он "движется". Не-по-ря-док.
Что тут можно сделать? Например, разделить поток трафика...
... примерно таким образом:
При этом а) входящим пакетам не придется проходить сравнения с правилами предназначенными для пакетов исходящих и б) собственно операции сравнения можно значительно упростить т.к. "направление движения" и "интерфейс" мы проверяем при этом самом "делении". Как только в дело вмешается nat + расположенные на самом сервере службы таким простым делением обойтись уже не удастся - я лично делю трафик на (входящий-исходящий), (внутренний интерфейс-наружный интерфейс), (адресованный серверу - транзитный), в ряде случаев к последней "дележке" добавляются еще broadcast и multicast трафик, но это требуется не слишком часто. Единственное требование, нужное для выполнения этого "фокуса" - _явная_ нумерация всех правил в списке, что определенным образом затрудняет сопровождение скрипта.
Можно еще скомпоновать несколько правил "в одно":
$cmd 00200 allow tcp from any to any 80,443,25,110 setup keep-state
Не следует забывать, что подобная организация правил упрощает сопровождение-управление скрипта и затрудняет тонкую "донастройку" правил, но "группировать" подобным образом "однотипные" протоколы можно и нужно.

Для того, чтобы все это не превратилось в нечитаемую мешанину из goskipto рекомендуется:
- Нумеровать правила с шагом хотя бы в 10 (Но в 100, как собственно и установлено по дефолту - лучше. Мало ли...).
- Отделять логические блоки правил друг от друга при помощи комментариев, в которых _обязательно_ указывать что это за блок, и в каком числовом диапазоне он расположен ("#######Обрабатываем входящий трафик 0-32500#####:" - примерно так).
- Не экономить на "внутритекстовых" комментариях.

@темы: FreeBSD, Работа

14:58 

Полежал. Прошло.

Поставил вместо isc-dhcpd 3.1.3 (С обновлением от 27 марта, ага) его же версии 3.0.7_5. Запустил с теми же конфигами. Возрадовался, ибо работает. Решил разобраться чуть-глубже, стартанул tcpdump -i lo0 -w ./3.0.7_5, записал дамп происходящего. Снес 3.0.7_5, воткнул обратно 3.1.3, злорадно запустил tcpdump... и обломался! ЭТА СВОЛОЧЬ НАЧАЛА НОРМАЛЬНО ОБНОВЛЯТЬ ОБРАТНУЮ ЗОНУ!!!
Снес-почистил-ребутнул-поставил-запустил... обновляет. Скопировал конфиги на другую виртуальную машину, запустил... работает! Без всякого копирования нарисовал всю схему по новой на свободной ВМке - тоже работает.
Сижу в раздумьях и сомненьях - "то ли лыжи не едут, то ли я ..."(Ц).

Буду утешаться тем, что скилл установки-настройки BIND'а поднялся на пару пунктов. На будущее - копирнул себе стартовые скрипты от 3.1.3 и сорцы от 4.1.1, буду пользоваться ими... :shuffle:

@темы: FreeBSD, Работа

16:44 

Ну и опять о вечном...

... т.е. о граблях(ТМ).
FreeBSD 7_3.
DNS. Зона прямого просмотра. Зона обратного просмотра. Файл с ключом. named-checkconf. named-checkzone. OK
DHCP. update-style interim. Зоны, primary 127.0.0.1; ключ. isc-dhcpd start. ОК.
Проверяем клиента - ipconfig /release - ipconfig /renew. Получаем адрес. nslookup <имя> - получаем IP. nslookup ip - получаем... ничего не получаем.
Лезем в логи - offer/ack, forward проапдейтили, TXT + A создали, TXT удалили, а с revers'ом - таки ой: "dhcpd: unable to add reverse map from <> to <> timed out".
В логах BIND'а чуть интересней:
client 127.0.0.1 updating zone бла-бла-бла ОК
client внешний адрес update 'x.x.x.in-addr.arpa/IN' denied.
Шо за нафиг? Прямую зону обновляем через 127.0.0.1, а обратную - через собственно интерфейс? Резво лезу в dhcpd.conf - нет, и там, и там стоит обращаться к 127.0.0.1. Странно. Запускаю tcpdump -i lo0, делаю release-renew на клиенте - думаю, может, это он, зар-раза за обновлением пополз, на DHCPD наплевав? Не-а!!! Запрос на обновление прямой зоны идет через 127.0.0.1 от, собственно, 127.0.0.1, а запрос на обновление зоны обратного преобразования идет через 127.0.0.1 же, но src-addr там именно что адрес реального интерфейса!
Для проверки меняю у зоны обратного преобразования update-policy на allow-update { адрес интрефейса }, проверяю - пашет. Меняю на 127.0.0.1 - нихтЪ. Ставлю вместо адреса ключ - опять нихтЪ. Запускаю nsupdate -k <ключ>, server = 127.0.0.1, делаю обновление - проходит.
"От такая вот загогулина"(С). Оно, конечно, и без зоны обратного просмотра прожить можно, да и на всю бОшку инсекьюрные апдейты по IP-адресу нормально пашут, но, блин, интересно же! Полдня вокруг железки с бубном плясал, так ничего и не добился. Думаю завтра качнуть с isc.org сорцы 4_1_1 вместо 3х из портов и попробовать скрестить ежа с ужом...
Вся жизнь - борьба!

@темы: Работа, FreeBSD

16:19 

Поймал себя на желании...

... в третий раз переписать основной firewall'ьный скрипт - ибо "читаемость" входит в противоречие с "простотой парсинга".
Медитирую на фразу "совершенство недостижимо", думаю странное ).

@темы: FreeBSD, Жизнь, Работа

12:51 

Мучительно размышляю...

... написать ли мне еще немного о классических (По сеансовый уровень включительно) firewall'ах "вообще", сказать пару-тройку слов конкретно про ipfw, перейти к application level proxy, или написать чуть-чуть об организации DNS в доменах MS AD и не только? ;)

Ладно, пока суть-да-дело, напишу-ка я о... ноутбуках ;). В общем-то, о том, что свой букварь я купил уже м-ммм... два года назад, и с тех пор "софтострой" так и не сподвиг меня на апгрейд ;) я уже писал. Похоже, фирма Интел победила Майкрософт "за явным преимуществом" - не самое мощное железо двухлетней давности вполне прилично тянет ОС последнего поколения с "довеском" в виде пары виртуальных машин. Конечная станция "Золотой век"? Не-а.
Итак, что способно сподвигнуть меня на замену железа:
- Мобильный интернет уровня той же Йоты (Ну или хотя бы Sky-Link'а :shuffle:), ОПСОСную USB-пипирку не предлагать ;). Конечно, дело это не (с)только "железячное" (Intel собственно, уже )) - н-но...
- Увеличенный хотя бы до 8-ми (Но десять - лучше!) часов срок автономной _работы_ (Не "включил и ждешь", а именно _работаешь_).
- Доступные SSD с прогнозируемой (Или просто увеличенной ДО) надежностью работы. Гигов 160 со скоростью записи под 200 за нормальные деньги и я ваш ;).
- Качественные изменения интерфейса Честно говоря, предполагаемые multitouch-планшетки не кажутся мне особенно удобными именно для _работы_, но в сочетании с первыми пунктами - чем черт не шутит?

@темы: Работа

15:58 

Две распространенные...

... ошибки (?) при написании firewall'ов:
Первая - исключение из рассмотрения одного из проходов. "Слева у меня диск С и справа у меня диск С, ну я один и удалил"(С), ага. Зачем описывать в правилах два прохода - "замышим" все на выходе в интернет и будем жить, да. В лучшем случае трафик делится на "входящий" и "исходящий" без указания интерфейсов - т.е. дважды проходит _один и тот же_ набор правил, а в худшем - просто ставится что-то вроде ipfw add allow all from any to any via <внутренний интерфейс>.
Пошло все это, как мне кажется с весьма умных людей, которые решали достаточно специфические задачи (Интернет-провайдинг) в достаточно специфических условиях (ОЧЕНЬ большой объем трафика, отсутствие каких-либо "дополнительных" служб на сервере, практически одинаковый уровень безопасности "внутренней" и "наружной" сетей и пр), охотно приводимые ими примеры отлично работали, хорошо читались, охотно комментировались и, как следствие, получили широкое распространение.
"Куда крестьяне, туда и обезьяне", ага. Увы, в "корпоративных" (Малый-средний бизнес, где все еще "в ходу" подобные "самоделки") решениях условия-требования несколько другие: "наружная" и "внутренняя" сеть обладают разными уровнями безопасности, "внутренняя" сеть, кто бы там что не думал, _НЕ_ является "абсолютно безопасной" (Т.е. решение с разрешением _всего_ трафика на внутреннем интерфейсе является категорически неприемлемым), сам брандмауэр может предоставлять внутренним пользователям дополнительные услуги (DNS-сервер, различные proxy и пр) - так что экономить на "головоемкости" не следует, и "мой тоби совет" - контролировать надо _оба_ прохода трафика, причем правила контроля "в общем случае" должны быть _разные_.
Вторая распространенная ошибка - использование nat'а в качестве stateful фильтра. Казалось бы, и там и там мы контролируем src port/addr - dst port/addr, создаем динамические правила с ограниченным сроком жизни - "... What's the difference?"(C). Увы, в большинстве современных реализаций nat'а она все-таки есть. Более-менее контроль состояния обеспечивает т.н. symmetric nat (Навскидку - pf), остальные реализации (Port restricted, addr restricted, full clone nat) допускают те или иные вольности с прохождением трафика (Из любви к истине скажем, что делается это не просто так - наиболее "безопасная" реализация nat'а, равно как и statefull filtering сам по себе, создают значительные проблемы ряду протоколов (Пиринговые сети, STUN и пр)).
Если посмотреть еще чуть-чуть глубже, например, набрав во FreeBSD'шной консоли sysctl net.inet.ip.fw мы увидим:
net.inet.ip.fw.dyn_keepalive: 1
net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_ack_lifetime: 300
что stateful фильтрация контролирует _все_ стадии "жизни" tcp-соединения, создавая целый _ряд_ динамических правил с разным временем жизни, чем известные мне реализации nat'а (Совершенно справедливо, ибо не барское это дело ;)) не озадачиваются. Ergo - на nat надейся, а "контролем состояния" не пренебрегай, как бы геморройно это ни было в том же ipfw ;). Впрочем, чрезмерно увлекаться подобным контролем тоже не стоит - записи в таблице состояний, записи в таблице nat'а, энное количество правил + два прохода трафика = потенциальная уязвимость к (D)DOS атакам. На мой взгляд, имеет смысл использовать контроль состояния на выходе из firewall'а, а на внутреннем интерфейсе можно применять классическую пакетную фильтрацию образца 80х годов... впрочем, по этому поводу я все еще думаю, ибо "совершенство приходит с опытом" :shuffle:

@темы: FreeBSD, Работа

16:07 

Загадка...

... ну или очередные грабли - это уж кому как ;). Как запрячь в одну упряжку осла и трепетную лань совместить в одном ipfw'шном ruleset'е stateful filtering и kernel nat написано в handbook'e. Чего там _не_ написано (Не удивлюсь, если оный sysctl появился уже _после_ выхода статьи, а "поправить" ни у кого руки не дошли) - sysctl net.inet.ip.fw.one_pass надо ставить в нуль, иначе работать пример не будет. Внимание, вопрос! Можно ли нафантазировать stateful ruleset с one_pass=1 и nat?
Ответ

@темы: FreeBSD, Работа

16:25 

В отличие от большинства...

... хороших программистов, искренне недоумевающих, зачем всякие "быдлокодеры"(ТМ) пытаются натянуть контрацептив на глобус используют реляционные СУБД там, где надо и где не надо (Вот ей-ктулху, каждый раз вижу попытку запихнуть OpenLDAP в какой-нибудь MySQL -и не знаю, плакать, или смеяться), я плохой программист системный администратор подобными вопросами не задаюсь, ибо знаю ответ(ы) ;). Если кому интересно - SQL чуть ли не единственный распространенный декларативный язык программирования, более того, из всего "подмножества" известных мне языков, он является едва ли не самым "человеческим" (Знающий английский язык человек вполне способен _правильно_ понять конструкцию вида select <> from table <> where <>, даже не будучи знакомым с SQL)
Чего я НЕ знаю - так это нафига, ну нафига использовать в качестве рСУБД MySQL, а? Я бы понял, продолжай народ пихать embedded 4-ку, так ведь нет! База на две таблицы, apache с СУБД на одном компе через 127.0.0.1 общаются, а туда же - подавай им 5.1...
Вот чем им всем sqlite не нравится, а? Отличная производительность, достаточный для 995% проектов набор возможностей, практически полное отсутствие потребности в администрировании, встроенная поддержка во всех распространенных языках программирования и прочие "радости бытия", так ведь нет... Не-по-ни-ма-ю.

@темы: Работа

09:19 

"Многа думать"...

... над "шайтанамой" в очередной раз не пришлось. Отдохнул, подумал, открыл исходники, подумал, закрыл исходники, подумал еще чуть-чуть, подвесил на модуль аутентификации SUID, проверил - работает! Этой зар-разе и впрямь не хватало прав на чтение /etc/master.passwd - аутентификация на удаленных серверах проходила "на ура" а локальная - таки ой ).
С одной стороны - "самдурак", мог бы и пораньше допереть, с другой - в рассчете на таких вот дураков можно было и какую-нибудь отладку прикрутить... :shuffle:
UPD А pam_group таки не заработал. От слова "совсем". Выкрутился при помощи родного winbind'ового require_membership_of='SID' и доменных групп. Вот правда лочить пользователя при помощи net rap groupmember delete <группа> <пользователь> -U <администратор> как-то очень уж... /не может подобрать слово/, а если учесть, что пароль этим net'ям мне удалось передать только с помощью expect...
Думаю нехорошее.

@темы: FreeBSD, Работа

11:36 

Шайтанама, аднако!

При помощи кувалды напильника и божьей какой-то матери прикручиваю к проксюку аутентификацию. Номинально - все великолепно, проксюк поддерживает pam, но делает он это м-ммм... в общем, круче "английских ученых"(ТМ) "голландских программистов"(ТМ) могут быть только программисты японские. Из четырех функциональных классов (auth, account, passwd, session) поддерживается только auth да и с тем происходит нечто странное:
Требуется осуществить аутентификацию доменных пользователей, и предоставить части из них доступ в сеть интернет. Ок. Ставим samba'у с поддержкой AD, конфигуряем (Workgroup, REALM, password server, idmap'ы), джойним (net ads join -U <> -S <>), проверяем - wbinfo -u. Работает. Правим nsswitch.conf, проверяем через id <имя> - тоже работает.
Пишем pam'овский файл в одну строчку - auth required pam_winbind.so. Настраиваем проксюк. Проверяем через браузер. Работает.
Добавляем проверку принадлежности к группе - auth required pam_group.so group=internet. Создаем группу, добавляем в нее доменного пользователя, проверяем через браузер - не работает. Хм. Странно. На всякий случай явно ставим winbind enum users/groups в smb.conf - проверяем через getent group. Работает. Браузер - нихтЪ.
"Для упрощения ситуации" - плюем на доменных пользователей. Закидываем локального user'а в группу internet, меняем pam_winbind.so на pam_unix.so, проверяем - упс!
Гхм. Копируем pam'овский файл, например, в su. Проверяем. Как ни странно, su с этими настройками пашет. Копируем обратно, докидываем к unix.so опцию debug. Запускаем, смотрим в debug.log - видим даже не фигу, а вообще черте-что и с боку бантик: pam_winbind.so у которого опции 'debug' нет и не было исправно в логах гадил (Скомпилен так, похоже) а pam_unix.so молчит как кошка об забор, что уж совсем ни в какие ворота.
Многа гуглю думаю.

@темы: Работа, FreeBSD

11:55 

Проникся чувством глубокого уважения...

... к предкам. Всего-то две шестидневных недели (Вторая с двенадцатичасовым рабочим днем) и меня почитай, хоронить можно - а они так (Оу, нет! Не "так", далеко не "так"!) всю жизнь работали! Спасибо соввласти за 5*8, в общем ).

Оффтоп: кто-нибудь знает рецепты салатов с морской капустой? Самой "душманской", консервированной? "Что-нибудь" я, конечно, и сам "насооружаю", не впервой, но...

@темы: Жизнь, Работа

10:23 

А в это время...

... без особого шума и пыли вышла FreeBSD 7_3. Читаю расширенные release notes и просто-таки душа радуется:
- Ну, изменения в ядре меня особо не колышат, хотя сетвой стек JAIL'ов... впрочем, за этим в 8-ку ). Пофисенный баг планировщика радует, но оно и так патчилось
- boot loader с поддержкой zfs - м-ммм... для меня не шибко актуально, но все равно - "спасибо" )
- из hw support'а заинтересовал только пофикшенный баг ipmi и то "теоретически"
- в network'е интересного чуть побольше - починили TCP segmentation offloading в fxp-драйвере, и! (Не успел пожаловаться, ага!) пофиксили багу с whatchdog timeout'ом для xl
- запузырили поддержку vlan в GENERIC-ядро, нарисовали rc-скрипты - давно пора, ага
- пофиксили охапку багов ata-драйвера
- изменили механизм балансировки gmirror'а (Будем почитать, да-ссс)
- всякая мелочь - utf-8 в man'ах, квалификаторы размера в fdisk'е (Алилуйя! Аллилуйя! Аллиллуйя!), прикрутили аутентификацию к fetch'у и прочее разное.
Ня! Буду обновляться )

@темы: FreeBSD, Работа

16:35 

"Одной строкой":

еще пара граблей в логах:
Mar 16 05:08:29 kernel: xl1: link state changed to DOWN
Mar 16 05:08:32 kernel: xl1: link state changed to UP
Mar 16 05:26:47 kernel: xl1: watchdog timeout
или сетевуха глючная (Были на ее счет подозрения, да) - или одно из двух ) Попробовал sysctl hw.pci.enable_msi(x)=0, будем посмотреть.

Плюс недавноустановленный ntpd истошно верещит:
Mar 18 09:55:30 ntpd[4547]: kernel time sync status change 6001
Mar 18 10:46:44 ntpd[4547]: kernel time sync status change 2001
в списках рассылки сообщается, что бага (Не сами по себе микроизменения - это норма, а именно засирание логов), в dev-ветке вроде как даже пофиксенная. Думаю, выкинуть логи из syslog'а в какой-нибудь совсем отдельный файл и тупо рЭзать его newsyslog'ом - ну или просто забить, растет он _сильно_ не быстро ))).

То, что sudo нифига не экспортит переменные окружения я знаю. То, что без экспортированного TERMCAP'а TERM=SCREEN и bell этим самым SCREEN'ом не поддерживается -- тоже логично. Но почему при 'vbell off' вместо этого чертового несуществующего "bell'a" все еще выходит идиотское 'Wuff, wuff!!" мне хоть убей, не понятно.
И то и другое и третье по сути мелочь - но неприятная.

"А в это время" "с мест" сообщают, что у одного из моего серваков - год uptime'a. Однако, ДАТА!

А еще на неделе был День св. Патрика.
И пятница наступила по расписанию (Больно!).
В общем, опять нет повода не выпить! Но! Я всех обманул - и не стал ))).

@темы: FreeBSD, Жизнь, Работа

16:21 

О раздвоении личности

С одной стороны все Мы Николай Второй понимаем, что "лучший метод творчества - это воровство"(С), и удачно примененный "костыль"(ТМ) (Ну, там вместо парсинга с помощью pcre заюзать какой-нибудь, прости осподи, sed/awk, а то и просто grep'ом обойтись) вызывает у меня чувство м-ммм... пожалуй, гордости (Она, какой я умный!) с другой - проекты-франкенштейны, состоящие из костылей чуть более, чем полностью вызывают уже не "раздражение", а натуральную ненависть.
Несоответствие масштабов применяемых средств и достигаемых целей просто убивает: "А давайте мы поставим веб-сервер, базу данных, два языка программирования, поставим "по зависимостям" туеву хучу модулей" - и все это для того, чтобы (Например!) посчитать трафик в конторе на пять машин. И это НЕ единичный случай "тысячи их" в разновсяческих OpenSource проектов.
С одной стороны - изобретать велосипед как-то не хочется, а с другой - разбираться со всем этим... "... и мудрость отличать первое от второго"(С).

@темы: Работа

16:16 

Если вдруг кому интересно...

... над понедельничными граблями "долго думать" не пришлось ;).
Vmware'ная VM'ка + wireshark со всей определенностью показали, что при каждом изменении IP-адреса система разражается т.н. gratuitous ARP-пакетом (Что, в общем-то, фича - а если кто rfc с draft'ами не читает, то он сам себе злобный баклажан), но делает она это sic! даже с отключенным/static ARP (Что, похоже, все-таки бага).
К счастью, внимательное (Ключевое слово!) изучение network.subr показало, что непрерывность последовательности alias'ов, о которой говорилось в man'ах, имеет значение только для парсинга аргументов в rc.conf, но никак не для самого ifconfig'а, которому эти номера псевдонимов вообще не передаются, более того, ifconfig без проблем допускает добавление первого и единственного ip-адреса с использованием синтаксиса псевдонимов. Сталбыть, окончательный вариант решения проблемы имеет вид:
ifconfig_<интерфейс>="ether <мак-адрес> "
ifconfig_<интерфейс>_alias0="inet <адрес> netmask <маска>"
Вуаля. Можно начинать бороться с вторничными граблями ))).

@темы: FreeBSD, Работа

17:42 

Порция понедельничных...

... граблей ).

Сервак, через пень-колоду собрали. Сервак через пень-колоду об-раз-цо-во настроили, увы, "в процессе" выяснилось одно "но" - враг трудового народа провайдер производит привязку по mac-адресу, с-но, при вылете сервера записью старого mac-адреса я никто не озаботился. При подключении "временного" варианта (Зухельного роутера) пришлось через суппорт провайдера произвести привязку к другому mac'у.
Ок. При настройке сервера я это учел и mac зухеля аккуратно записал. Осталось понять, как его ак-ку-рат-нень-ко так подменить при загрузке FreeBSD. Само по себе - не бином Ньютона - ifconfig <интерфейс> ether <адрес>, но при загрузке, через rc.conf?
"Очевидный" вариант - ifconfig_<интерфейс>="inet netmask <маска> ether " по понятным причинам (Все это передается в качестве аргументов родному ifconfig'у, а он "одной строкой" устанавливать адреса разных классов не умеет) не прокатил.
Чуть менее "очевидный" вариант - дважды задать адреса для одного интерфейса в стиле:
ifconfig_<интерфейс>="inet netmask <маска>"
ifconfig_<интерфейс>="ether "
не прокатил тоже (Опять таки, не удивительно, учитывая механизм обработки rc.conf'а).
Затык-с. Просто выполнить юзерский скрипт с этим самым ifconfig'ом - "низкий класс, нечистая работа"(С) - пришлось засучить рукава и полезть изучать /etc/rc.d/netif - далее по тексту ). В процессе родилась "Оригинальная Идея"(ТМ) и файл rc.conf (В "интерфейсной части", ессно!) принял следующий вид:
ifconfig_<интерфейс>="inet netmask <маска>"
ifconfig_<интерфейс>_alias0="ether "
т.е. мы "создаем псевдоним", передаем ему в качестве адреса - mac. Ясен пень, псевдоним (Второй IP на интерфейсе) не созается, но! аргументы старательно передаются ifconfig'у.
И вот он, торжественный момент - сервак втыкается в стойку, нажимается кнопка "пуск"... пять минут - полет нормальный, но тырнетов нет. Быстрая проверка показала, что mac-адрес уже новывый, но толку от этого нет - стандартный шлюз не пингуется, а tcpdump показывает, что все, что он может "отдать" - arp'шный ответ на who has... Полчаса танцев-с-бубном, обратное подключение зухеля - нет эффекта. Пришлось звонить провайдеру. Эти... параноики на первый же ethernet frame с mac'ом отличным от ожидаемого насмерть лочат порт, а rc.conf обрабатывается последовательно...
Буду ДОЛГО думать.

@темы: Работа, FreeBSD

13:29 

Хотел быстренько задать...

... ну ОЧЕНЬ животрепещущий (Для меня) вопрос - но не успел. Абидна, да ).
Откладываем до понедельника.

@темы: FreeBSD, Жизнь, Работа

Танец-с-саблями на граблях

главная