• ↓
  • ↑
  • ⇑
 
Записи с темой: freebsd (список заголовков)
16:39 

Глас вопиющего в пустыне:

Кто-нибудь знает, поддерживает ли ufs'ный dump ufs'ные же ACL? Помнится мне, поддержка ACL dump'ом в ext3 появилась ну сиииильно не сразу...
Ладно. Пошел проверять.

@темы: FreeBSD

15:32 

Еще один элегантный способ...

... отстрелить себе ногу.

Сижу, дописываю очередной скрипт на питоне, для разнообразия - версии 2.5 (Об этом как-нибудь еще будет - много и матерно). В зависимости от опций командной строки вывод должен идти либо на экран, либо в файл. По причине редкостной ублюдочности старого python'овского (До версии 2.6, ага) print'а, а так же нежелания плодить дублирующиеся фрагменты кода решаю сделать "финт ушами":
f = sys.stdout
if opt.verbose > 1:
f = open('бла-бла-бла','w')
ну и в коде, соответственно:
f.write('бла-бла-бла')
уже не заботясь о том, куда именно пишу. Для того, чтобы обеспечить гарантированное (Ибо нефиг!) закрытие файла в случае падения скрипта (Ну ма-ааало ли...) заворачиваю всю конструкцию (А вот нету в 2.5 менеджера контекста!) в
try:
...
finally:
f.close()
и запускаю. Оно, собственно, работает. Оно даже очень хорошо работает - вот только результат у sys.stdout.close() оказывается м-мммм... вполне предсказуемым, но в данном контексте весьма неожиданным ))))). Если бы работал не в screen'е - было бы совсем забавно, но и так - доставило ).

@темы: FreeBSD, Python

18:57 

В первый раз в жизни...

... поиграл в боулинг. Скорее понравилось, чем нет при там, что скорее НЕ получалось, чем наоборот. Поел мяса, попил пива - хороший вид спорта!
По работе загнал bind c isc-dhcp 3.1 (Древний, как дерьмо мамонта - но работает) в jail. Воспользоваться специфическими freebsd'шными наворотами (компиляция с jails + sockets) не вышло - после включения sysctl security.jail.allow_raw_sockets оно даже запустилось, но адреса выдавать отказалось наотрез; так что пришлось так же разрешать сокеты и экспортировать bpf через devfs.rules после чего адреса стали выдаваться а вот динамической обновление зоны в DNS так и не завелось. Буду курить дальше, причем именно в направлении "нормального" запуска из клетки.

@темы: FreeBSD

16:56 

И еще одни грабли...

... на которые многие наступают, но мало кто описывает ).
Синопсис - openvpn в "клиент-серверной" конфигурации, сервер freebsd (В общем-то, однофигственно) клиент - windows. Работаем через tun-устройства (Нафиг нам ethernet через VPN гонять?). Задачка - прописать клиенту маршрут до сети за сервером.
В случае *nix клиента и *nix сервера проблемы, в общем-то, нет у них с PtP все, нормально, а вот у виндей, как обычно, "все не слава Б-гу". Прежде всего - в них _нет_ tun-устройств. Совсем. Tun-режим _эмулируется_ tap-драйвером (Стороннего, впрочем, производителя) следующим образом:
На каждого клиента выдается подсеть /30, первый-последний адреса, как обычно, сеть+broadcast, предпоследний адрес назначается клиенту, а второй - виртуальный IP-адрес сервера, причем, "виртуальный" настолько, что на ping'и, хе-хе! не отзывается.
Соответственно, человек, по какой-то причине решивший прописать маршруты самостоятельно видит дивную картину - на стороне *nix'ей обычный PtP туннель ("inet 192.168.100.1 192.168.100.2 netmask 0xffffffff" - как-то так )), а на стороне windows - непойми откуда взявшийся адрес с /30-й маской (IPv4-адрес. . . . . . . . . . . . : 192.168.100.6, Маска подсети . . . . . . . . . . : 255.255.255.252 - что-то в этом роде) плюс маршрут с непингующимся шлюзом - сюрпри-ииииз! Причем в man'е все это описывается буквально парой строчек ("For tun-style tunnels, each client will be given a /30 subnet (for interoperabil ity with Windows clients)." - вот, собственно, и все )), как хочешь, так и понимай ). Конечно, не man'ами едиными - в частности, я, помнится, все это нашел в официальном FAQ'е на официальном же сайте, но все же...
В общем, к чему я это: в случае *nix-*nix используйте директиву --ifconfig-pool-linear и не трахайте себе моск, в случае windows-клиентов старайтесь использовать родной push, в случае windows+*nix клиентов пользуйтесь client-config-dir'ом + тем же push'ем (И надейтесь, что route с той стороны все поймет правильно - что, в общем-то, далеко не факт, учитывая число реализаций этой функции ;)), ну а если уж вам по какой-то причине захотелось прописать маршрут руками - используйте "виртуальный адрес сервера" не беспокоясь о его "непингуемости" и все будет ОК.

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

16:43 

О том, как полезно...

... внимательно читать man'ы:

Настраиваю я, значицца ddns в jail'е - традиционное allow-ipdate { 127.0.0.1; }; не прокатывает, ибо loopback'а в jail'е нет - сталбыть, будем использовать TSIG. Ну, коли уж юзать, то на всю катушку, и вместо allow-update я пишу update-policy { grant ddns_key subdomain example.local. A; }; что-то в этом духе делаю для зоны обратного просмотра (Сама зона другая и разрешенный тип записей - PTR), разрешаю обновление соответствующих зон в DHCP, цепляю виртуальную ХРюшу - ipconfig /renew... Нет, адрес с DHCP я получаю, но новой записи в DNS нёма, а в логах только "updating zone 'example.local/IN': update failed: rejected by secure update (REFUSED)" - понимай, как знаешь.
Нет, я конечно знаю - nsupdate -k и далее по тексту, однако - сюрпри-ииииз! ручное обновление зоны проходит без ошибок, сталбыть, проблема на стороне DHCP. Ключ? Кавычки? Точки? Опции запуска? Компиляции? А вот хз. "Все хорошо, но ничего не работает"(Ц). Наконец, испробовав методом научного тыка все возможные и часть невозможных сочетания параметров делаю то, с чего собственно стоило все это начинать ) - _внимательно_ читаю man. Полностью, а не те куски, "которые нужны". И что бы вы думали? Нахожу искомое в описании директивы update-style interim (Казалось бы, что про него читать? update-syle'ов у нас всего два и один из них ad-hoc "is deprecated" ;)). Оказывается, эта зар-раза для того, чтобы отличать обновления, вносимые в DNS разными DHCP-серверами кроме A-записи вносит еще и TXT-запись, содержащую md5-hash запроса на получения адреса, а моя секьюрная-пресекьюрная update-policy разрешает для зоны прямого просмотра изменения только и исключительно A-записей. Точка.
Остается вопрос: а) какого рожна в логах не было ничего вразумительного по этому поводу, б) почему не была внесена PTR-запись в зону обратного просмотра в) что, низ-зя было внести одну A а TXT тупо заигнорить?

@темы: FreeBSD

13:34 

О "поломатой судьбе":

Воткнул я тут на новый сервер фрюху. Восьмую, ага. Воткнул, честно скажу, криво - не то, чтобы совсем, но м-ммм... кривовато :). Все, в общем-то как обычно - /root в readonly, /var, /usr - с softupdates, /tmp, swap - а вот отдельный /home решил сделать через gjournal опосля. А, да - ну как обычно все это на двух дисках в gmirror'e.
Так вот, зеркало с его участием я таки сделал %) осталось всего ничего - создать на нем новую partition, ага. Вот только сюрпри-иииз! Sysinstall о всяких mirror'ах знать не знает, ведать не ведает и думать не стремиться. Ну-да мы люди храбрые, нам и bsdlabel за gparted сойдет ). Делов-то! Последний раздел делать - эт вам не весь диск разбивать, с арифметикой можно не заморачиваться - поставил пару '*' и в путь: bsdlabel -e /dev/mirror/gm0, копируем последнюю строчку, меняем букву, ставим '*'ки, :x!... а вот хрен! "disklabel: Class not found" А! Ну, вроде ясно система же рабочая! sysctl kern.geom.debugflags=16... Не-а. Не едем. И так не едем, и эдак. Внимание, вопрос - это 8_0-p2 такой поломатый, или с gmirror'ом оно завсегда так?
Не, на кривой козе оно, кнечно, объезжается:
gmirror remove gm0 /dev/... - выкидываем второй диск из зеркала
disklabel -e /dev/... - допиливаем до нужного состояния
gmirror label -v gm1 /dev/... - создаем второе зеркало
vi /etc/fstab - прописываем загрузку со второго зеркала
shutdown -r now
gmirror stop gm0 - уничтожаем первое зеркало
gmirror clear /dev/... - на всякий случай уничтожаем метаданные с первого диска
gmirror insert -v gm1 /dev/... - включаем первый диск во второе зеркало
Наслаждаемся!
Но все же... интересно. Буду тестить на виртуальной машине в 7 фре.

@темы: FreeBSD

16:42 

Продолжение банкета:

сохранять журнал на отдельном разделе 8-ка отказалась. Категорически.
Попытка сделать gjournal label -f /dev/mirror/gm0s1g /dev/mirror/gm0s1h (В single-user'e + kern.geom.debugflags=16, ага) приводит к невнятному "No such file or directory" (Какие нафиг файлы, вы о чем?) на gm0s1h.
Еще веселей получилось с "загонянием" готового журнала в зеркало. Нет, оно даже сработало - номинально, но при перезагрузке - упс! gjournal provider вылетел куда-то "в далека" по таймауту.
Вариант с журналом на том же устройстве, что характерно, прокатил.
Думаю.

@темы: FreeBSD

16:37 

Закрытия вопроса для:

fdisk + bsdlabel в 8-ке похоже и впрямь, поломанные. В семерке эти же операции с GEOM'овскими провайдерами проходят "на ура" (Местами даже слишком - bsdlabel умудряется работать с конкретными физ. устройствами при включенном, подмонтированном etc. gmirror'е - эта информация стоила мне порушенной таблицы разделов на одном из винтов виртуальной машины )))). Гугление mail-list'ов указывает на "слишком хорошо" доделанную GPT-partitioning, но окончательной ясности с этим вопросом у меня все еще нет.
Журнал на отдельном разделе отказывается создаваться только в том случае, если раздел а) последний на слайсе б) свободного места на слайсе нет. Фиксится через bsdlabel -e /dev/... путем уменьшения значения в поле size на единицу ;) для 8ки с-но, не слишком актуально по причине см. выше

Собссно, это была присказка, сказка, т.е. настоящая причина ;) ниже:
читать дальше

@темы: FreeBSD

15:20 

О "черной магии"...

... мать её за ногу ). Есть в разновсяческих *nix'ах туева хуча энное количество параметров, которые никто толком не знает, как настраивать ("Зависит от нагрузки"(Ц) - читай "развитым классовым чутьем") - все бы хорошо, не оказывай они порой такое влияние на жизнедеятельность системы. Не будем поминать недоброй памяти maxusers (которая не "max" и к "users" никакого отношения не имеет) - она давно (Вроде как еще с 4-сколько-то) ставится автоматически, отложим в сторону nmbclusters (На не ОЧЕНЬ сильно нагруженных серваках оно почитай что и не роляет, ибо хе-хе! меняется в зависимости от maxusers), забудем на время про туеву хучу недокументированных sysctl'ей - эт все мелочи, но! Вот скажите мне, как я должен выбирать размер файла/устройства для хранения GJOURNAL'ьного журнала, а?
По формуле 3,3*(объем памяти) взятой из статьи про настройку _десктопа_? А если её у меня хренадцать гигов? М? По суперформуле ram+swap? Взять, как предлагают, ((скорость записи на диск)*20 + хрен-его-знает)? А теперь добавим к "процессу выбора" тот факт, что в случае нехватки места под журнал мы ловим глухой висяк + возможную потерю данных... весело, да?
Или вот глянем в сторону "супер-альтернативы" - zfs (Отдельные "лучи поноса": системные требования в виде 2+ гигов памяти _на файловую систему_-то!, отсутствие поддержки ACL, которые еще-только-обещают приделать, причем не posix, а вполне себе NFSv4, траблы с загрузкой...). В варианте i386: Typically you need to increase vm.kmem_size_max and vm.kmem_size (with vm.kmem_size_max >= vm.kmem_size) to not get kernel panics (kmem too small). The value depends upon the workload. - "классовым чутьем", ога. Еще и ядро пересобрать с KVA_PAGES, число которых тоже не понятно, откуда брать. А-ааатлична, я считаю.

Не, я отлично понимаю, что при помощи этой и тому подобной "черной магии" _иногда_ можно очень даже значительно повысить общую производительность системы, что в принципе невозможно в "не столь открытых" ;) системах, но, но, но... Иногда все это ОЧЕНЬ раздражает )

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

16:08 

Редкое для меня ощущение...

... сижу, "как умный" читаю как бы так PDC из Samba изладить, избежав (Ну вот хочется!) дублирования информации в системной /etc/(master.)passwd - и так читаю, и эдак читаю, и офсайт облазил, и на ангельском загуглил, и slackware'ную хаутую нарыл - "нету газу теплороду"(С) и все тут. Все прям как сговорились - пишут 'add user sсript = /usr/sbin/pw "%u"' или другую какую "вариацию на тему". К полудню плюнул на это дело и решил "ручками попробовать". Что характерно - с первой попытки (!) понял, что ему трэба.
Странные какие-то ощущения. Обычно "как дурак" пробуешь, пробуешь, пробуешь - потом резко умнеешь, и начинаешь думать читать, после чего достаточно быстро "все-все" (Ну, эт я загнул, кнечно) понимаешь, а тут... Не-по-ря-док!

@темы: FreeBSD, Жизнь

16:26 

Восстание машин

Все началось с того, что вполне знакомый, еще поза-позавчера абсолютно рабочий ключ отказался открывать дверь. Напрочь.
Параллельно выяснилось, что "интернет-не-интернетит". Весело день начинается, ага.
После Героической (При помощи плоскогубцев и какой-то матери) Победы над Дверью выяснилось, что интернет не просто "не интернетит", но и на пинги на внутреннем интерфейсе не отзывается, что уже совсем ай-яй-яй. Подключенный монитор с клавой показали, что система свалилась в single user mode по причине повреждения ufs. Ручная проверка привела к удалению... проще сказать, что не побилось, чем перечислять потери ).
Make installworld вернул системе относительную работоспособность, но вопроса (разумеется) не решил. Изучение логов показало, что 7го числа по причине глюков с первым винтом рассыпался рейд, "на честном слове и на одном винте крыле" система продержалась часов 8 и по причине глюков уже со вторым винтом свалилась в ребут. Поднялась она, разумеется, уже без всякого рейда, проработала до 5 утра 8го марта и сдохла уже куда более основательно (Побилось почитай все, смонтированное в rw - логи, кэш проксюка, обновлявшееся по расписанию дерево портов и пр).
Попытка разрулить ситуацию штатными средствами (gmirror forget - замена винта - gmirror insert) к успеху не привела - оба винта отчаянно матерились на IDMA CRC error'ы, вызывали "interrupt storm'ы" и падали на первых 10 процентах ребилда. Было принято решение "по быренькому" переставить фрюху и накатить на нее часть старых конфигов с бэкапа.
"Быренько", ага. Сначала отказался писать уже не встроенный (ВСЕ ЕЩЕ не починенный!) резак, но подключаемый через USB-контроллер IDE'шный ветеран, после успешного прожига (Гы-гы! Осуществленного с помощью линуксовой машинки, с mount -t ntf, mkisofs и прочих прелессстей) "внезапно" выяснилось что в серваке стоит только и исключительно CDROM, и ни о каких DVD речи не идет, пришлось опять подключать внешний DVD через USB-интерфейс.
После третьего ребута он даже нормально опознался, но делу это помогло не сильно - попытка записи на уже новые винты успехом не увенчалась - установка систематично падала на разных стадиях процесса с теми же ошибками винтов. Речь зашла уже не о винтах а о контроллере и на "быренько поставим" никто особо не надеялся.
Было решено поставить какой-нибудь роутер со склада и не мучится. Щаз! Найденный "wireless" зухель долго отказывался выдавать дефолтовый пароль (На коробке его не нашлось, в бумажной мануале была только рекомендация воспользоваться диском с netfriend'ом - Мать-мать-мать! Про это я как-нибудь отдельно выскажусь), в процессе первоначальной настройки выяснилось, что во время передергивания оборудования в стойке я как-то сумел вырубить розеточную панель, на которую был запитан в том числе провайдерский свитч, ну и в довершение - провайдер использовал привязку по MAC-адресу, а записать MAC старой сетевухи я того... не догадался.
В общем, весь комплект приятных ощущений поимел.
Завтра буду потрошить "умираю-но-не-сдаюсь" сервер )))

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

13:29 

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

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

@темы: 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

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, Работа

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, Жизнь, Работа

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, Работа

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

09:19 

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

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

@темы: 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, Работа

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, Работа

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

главная