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

И еще немного разудалого секаса...

... с расширением дисков на файловом сервере FreeBSD 9.0. Т.е. на первый взгляд никакого секаса не планировалось:
gpart resize -i номер раздела имя провайдера
growfs имя устройства
все. На второй все оказалось несколько занятней. Фрюха старая как не скажу что и обновлялась с FBSD 7.0, т.е. схема разбиения дисков - ну нифига не GPT, а BSD Slice\Partition, файловая система ессно, UFS с наворотами в виде SU+Journal. Размер 1,5 Тб и с бэкапом все не так, чтобы очень - ну, понятно чем пахнет, да?
gpart resize - ошибка. Ага. Ожидалось. Надо заресайзить слайс fdisk'ом. Уйблин... какой же он родом из 90х, а? Не, в начале 200х мы конечно всей этой арифметикой с вычислением количества секторов занимались - но блин же блин! Винты в то время были хорошо если на гиг, секторов этих - МАЛО, а сейчас 2Тб в сумме и сектора как бы не по 2К... ачешуеть. Посчитал, перепроверил, посчитал еще раз, забил - стрррашно! Отменил, повторил, проверил, забыл одну лишнюю цифру отменил еще раз, write! А вот фиг. Ну да, ну да - слайс используется.
sysctl kern.geom.debugflags=16 - дети-не-делайте-так-fdisk-write!
ОК. Reboot.
Три минуты ужаса - работает. gpart show - ага, slice расширен, unpartitioned отсутствует, зато есть свободное место внутри slice'а. Отмонтируем будущий расширяемый раздел - тот который g и /home
Запускаем bsdlabel - здравствуй, vi! Видим партицию c - whole drive DO NOT EDIT - это они зря, место явно нихрена не все, надо править. Страшна... правим.
Следом смотрим размер последнего раздела - будем увеличивать его, считаем, еще раз считаем, перепроверяем, write? Авотфиг! Нет прав доступа к разделу.
Гм. А! sysctl kern.geom.debugflags=16
Повторяем. write? Опять фиг.
Гм. Ну, reboot что ли. Single-user-mode-service-sshd-start цепляемся, bsdlabel-повторить - хрен. Нучоооазаааанааафик...
Гуглим. Думаем. Гуглим. От нефиг делать gpart resize -i 7 хренак! работает.
reboot. Три минуты ужаса, gpart show - ага. Раздел расширился.
Ну, дальше просто! growfs - авотхрен! В разделе есть живые снапшоты. snapshot list - ну, да. Есть 100 Гб в сумме почти. Ок. mount - rm -f /home/.snap/* - пять минут полет нормальный, десять минут - полет нормальный полчаса... нифига не нормальный! Смотрим - оп-па! Консолька по сети отпала. Ок, то же самое из-под screen'a - пять минут, десять минут... двад... ок! Готово!
umount - growfs - вот тебе адреса новых секторов с супеблоком, пять минут... оп-па. Ошибка. rdfs: failed negative block number. Гм. Что-то пошло не так. Выйдем и зайдем по новой - growfs... Хрен! Само по себе не пропало, чапай думу думать будем, а пока - reboot и еще раз! Не-а. Гм. Гугль не гуглится толком, проблемы с расширением аж 16Тб, какой-то патч... ладно, смотрим в исходники - ага. Ну, понятно. Под число секторов отдано длинное целое и на 2Тб переполнение, с появлением знака. Патч... не-а. Не подходит. Тут понимать что написЯно нужно, да править ручками.
Нуууу... лаааааадно. Попробуем уменьшить размер, что ли? Если ему два Тб не нравятся? А, стоп! А сколько ему понравится? 2кб блок, длинное целое... это что же - меньше 1,5 Тб? Данунах!
Э... Ну, вроде позднее про ошибки не пишут - давайте так, FreeBSD 11 Memstick на флешку, грузимся с неё и алга! Сказано - сделано, пишем, грузим, алга? growfs - success а не секас! Работает, в смысле.
fsck - Use Journal - версия журнала не соответствует, запускаем полную... стоп-стопэ!
reboot - fsck - use... Хвала Аллаху, милостивому и милосердному, хвала хвала и трижды хвала, аминь!
Да шоб я! Да еще раз!

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

23:10 

Интересный эффект при попытке...

... создать файловую систему ufs на geli-устройстве со включенной аутентификацией:
Создаем sparse-file (Вообще - пофиг, но мне нужен именно он, так что...):
dd if=/dev/zero of=~/enc.img bs=1M count=1 seek 1023 conv=sparse
Смонтируем его в систему:
mdconfig -a -t vnode -f ~/enc.img
Создадим на его основе шифрованный криптопровайдер со включенной (Это важно!) data integrity.
geli init -a HMAC/SHA256 -s 4096 /dev/md0
Подключим его к системе:
geli attach /dev/md0.eli
Разметим для дальнейшего использования (В данном случае можно и обойтись, но с физическим устройством - понадобится. Да и просто - культурней):
gpart add -s GPT /dev/md0.eli
gpart create -t freebsd-ufs /dev/md0.eli
Создадим файловую систему на размеченном носителе:
newfs /dev/md0.elip1
И обломаемся об ошибку:
newfs: can't read old UFS1 superblock: read error from block device: Invalid argument
Упс. Беглый google'инг говорит, что бИда происходит из-за того, что блоки, к которым обращается система еще не подписаны geli и надо бы перед форматированием того-этого инициализировать систему с помощью, например
dd if=/dev/random of=/dev/md0.elip1
но делать это в случае sparse-файла как-то не хочется ибо при этом будут потеряны все его преимущества. Ой?
Не-а. Достаточно инициализировать тот сектор, в который будет записан суперблок (Копии пишутся с рандомным смещением в каждую группу цилиндров) с помощью того же dd указав его размер (Не забыть указать тот же самый в newfs - и да, размер блока не должен быть меньше размера сектора, выбранного для geli-провайдера).
dd if=/dev/random of=/dev/md0.elip1 bs=8192 count=1
И вуаля! Работает, причем именно так, как нужно )

@темы: FreeBSD

22:15 

Состоял я в интимной связи...

... с этой самой вашей FreeBDSM'ой и её шлангом!
Не собирается tripwire, в пакетах нет, в интернетиках стоны на шланг.
Ок, в системе стоит gcc46 - собираю. Ага. Щаз. Разбежался. Нет, оно собирается. Но при запуске крашится.
Начинаю разбираться со шлангом. Ага, ага - таких страдальцев полна макось. Тырю три патча оттуда, натягиваются с трудом, но разобраться можно. Вылезает четвертый глюк, про который в тырнетиках и стонов нет.
Пытаюсь разобраться шо цэ такэ. Ага. Походу разница между gcc'шной libstdc++ и clang'овой libc++, в последней один из методов std::iterator !внезапно стал private. Зачем? Почему? Моя не понимать.
Попытался обкостылить с трех сторон, задолбался по самое нимагу и в конце концов тупо перекинул его обратно в public.
Собролось. Поставилось. Работает.
Напоминаю себе абизяну с очками - а вот если очки в тисках закрепить и на табуретку встать под углом 71 к горизонту - то левый глаз что-то видит! Что? На нос одевать? Не, не пробовал!
Патч с этой порнографией сабмитить откровенно стыдно.

@темы: FreeBSD

23:19 

Есть ощущение...

... что в процессе "втягивания" fuse в базовую систему BSD'шники серьёзно чего-то там отломали.
С fusefs-kmod fusefs-wdfs работала нормально, а с реализацией модуля из базовой системы... ну, гм. Оно в общем-то читается. И даже пишется. Каталоги, по крайней мере создаются. А вот попытка создать (Любым способом, по копирование включительно) любой файл вызывае таки ой. Отладка говорит, что CREATE Function is not implemented.
При том другие файловые системы в юзерспейсе работает совершенно нормально (Проверил на ntfs-3g). По логам коммитов wdfs серьёзно не пилился больше года - т.е. в нем ничего отломать не должны вроде как.
Надо попробовать таки поставить заигноренный fusefs-kmod и покрутить туды-сюды, но леееень же! И - ну как еще чего отвалится?

Ох, чудны дела твои оспыдя. Что-нибудь да отломают.

@темы: FreeBSD

20:15 

Былинно отказал на работе.

Для разнообразия - совершенно самостоятельно.
Пять одинаковых шлюзов сбора данных задеплоил из предварительно настроенного образа, а шестой, который должен подключаться через gprs решил настроить ручками - не развернуть образ и допилить нужное, а - повторение же мать его и перемать учения - поднять с нуля.
Ну и поднял, чО. Первый прикол произошел, когда инит сказал rc.conf 0:not found. Полчаса с ним возился, уже до rc-скриптов дошел - мол, что за фигня-то? Отродясь такого не было, и 0 в rc.conf'е нет никакого, и поиск vim'овский его не видит... только сам vim как-то подтупливает непонятно, курсор не рисует с первого раза, но мало ли - мож клава глючит, или еще чего. А потом я почти случайно нажал на мониторе "автонастройку" и... монитор сместился вниз на одну строчку!!! :0 само собой - попытка перейти на первую строку файла в "подтупливающем" vim'е в режиме редактирования )))
Потом слегонца повозюкался с ppp - ставить mpd счел нецелесообразным (Кто его окромя меня поддерживать-то будет?), решил обойтись userland'ным из базовой системы. В процессе решил, что ipfw kernel nat тут тоже будет overkill'ом и настроил ppp'шную реализацию (Один черт, на том же libalias'e собрана), что сильно упростило набор правил firewall'а (Написать, что ли отдельно... хм..)
Настроил. Проверил. Работает. Но... после установки в Чайковском выяснился "нюанс" - пользователя auser забыл добавить в группу wheel!!! А sshd во фре по умолчанию с permitrootlogin=no сконфигурен! Зайти под юзером можно, но su сделать нельзя, под root'ом залогиниться не получается... обидка-досадка-гневик!
Сервачок-то работает, но если !внезапно понадобиться добавить еще пару параметров в мониторинг или там индекс в db то упс!!!
Вот и думай теперь голова, шапку куплю...

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

19:45 

Кто бы мог подумать...

... что openjdk6/7 не собирается (Вернее, не bootstrap'ится, а еще точнее - просто segfault'ится) в собранном clang'ом окружении? Какая-то фигня с libc'шным vsnprintf'ом имеет место быть. Фрюшники не чешутся, а у маководов со времен snow_кого-то-там "все работает"(С). Абыдна, вай!

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

13:20 

Забавный фокус

Дано. Поднятый непойми кем и непойми когда сервер freenas на 7.4-p7.
Через iscsi раздается 600+ гигов для бэкапа. Физически раздается не блочное устройство, а файл.
Раздается, работает - но есть нюанс! Из 600+ раздающихся гигов реально используется несколько меньше, а место таки трэба. Т.е. надо бы экспортировать через iscsi мнэээ... "динамически увеличивающийся" носитель.
Вопрос? Нивапрос, гуглим в сторону sparse files, которые таки поддерживаются в UFS2.
dd if=/dev/zero of=/mnt/sparse.img bs=1G count=1 seek=619 conv=sparse
"Проматываем" 619 гиговых блоков от начала файла, дальше пишем гиг нулей (Реально можно было и точнее подогнать, но считать лениво), указываем, что создаем "разряженный" файл, при этом реально запись "нулей" не производится.
Делам ls -lah - уупс! Видим размер 620G. Гм. Делаем на всякий случай du -hd 1 /mnt - ууупс-2, занято полтора гига. Т.е. ls со sparse-файлами просто работать не умеет (Ну или там ключик какой специяльный нужОн, не разбирался). Дальше экспортим через iscsi, форматируем, пишем, проверяем. Работает.
Если вдруг нужно на standalone-машине повошкаться (Ну-там jail'ы покрутить или еще чего) можно воспользоваться loop-устройствами, о чем я вроде даже и писал:
mdconfig -a -t vnode -f /путь -u номер
gpart create -s mbr /dev/mdномер
gpart add -t freebsd /dev/mdномер
newfs //dev/mdномерs1
mount /dev/mdномерs1 /путь
Работаем!

P.S. Из замеченных косяков - зверская фрагментация при работе "на запись" с большим количеством sparse-файлов, возможность отстрелить себе ногу с помощью overcommit'a так же ничем не ограничена. А вообще - работает и работает хорошо.

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

21:39 

Прошло полтора года...

... и мудрый вождь Быстрые Грабли понял, что проблемы со скоростью вайфуя в квартире вызваны не hostapd, не if_run/runfw драйвером, не Dlink'овской железкой, не Ralink'овским чипестом и не настройкой клиентских адаптеров даже, нет - виновата похоже подсистема USB во FreeBSD, ибо замеренная с помощью dd скорость записи на USB Mass-storage подозрительно похожа на скорость вайфуя в квартире. Казалось бы, чего стоило методом исключения допетрить, что если с вайфуем per se проблем нет, то искать их надо в другом месте - но нет! Мы лучше 8-stable поставим, или там 9-current, hostapd из сырцов соберем, дрова с SVN-разрабочтика стянем, ага, ага. Тьфуй, в общем.

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

17:26 

В очередной раз почувствовал себя...

... провайдерским саппортом из анекдота - "От нас все патроны ушли, проблемы на вашей стороне!"(С)

Сначала пионЭр на том конце провода зарезал icmp за вычетом 0,8,11 - request/reply, dest. host unreachable, а об остальных сообщениях мы не знаем и знать не хотим, ага. Потом товарищ забыл воткнуть tcpmssfix в mpd.conf, а дальше начался цирк-с-конями ).
Приходит пакет, видит do not fragment, дропается, а ответный icmp message to big режется ipfw. В security log при этом должна валиться запись - но у нас же, блин, все секууурно! Мы заранее ограничили число однотипных сообщений 10, а сделать ipfw zero нам, пардон, членомерка не велит, мы на счетчики медитируем! Пару правил, которые вроде как за прохождение трафика отвечают - пжалста, а все счетчики целиком - никак-никак.
А виноват во всем этом, разумеется, я - так как "просто интернет" у мужика есть, а https до меня "не работает". https "вообще"? Работает, конечно! telnet на 443 порт идет нормально, так что решайте ВАШУ проблему!
Хвала Аллаху, милостивому и милосердному, что главбух с той стороны объяснила одмину, что "интернет вообще" и "telnet на 443" != "работающий банк-клиент" и товарищ осознал, что "https вообще" у НЕГО не работает и я тут не при чем. Впрочем, мне это не помогло - "Ну надо же решить проблему! Да, она не у вас, но мы вам деньги платим, а оно не работает, так что давайте как-нибудь вы там подумаете, что мне сделать, чтобы... Нет ssh-доступ я вам дать не могу, секуууурность не позволяет, так что вы уж там как-нибудь телепатически..."
Пришлось решать, ага. По tcpdump'у увидел, что на той стороне дропается от четверти до трети пакетов, предположил, что проблема в NAT'е (Т.к. на прозрачно проксируемый http товарищ не жаловася, а ходящий через nat https чудесатил во всю). Замена kernel nat на NATD вполне логично не спасла (Хотя потерь, почему-то, стало меньше), подумал, что mpd с ipfw порядок прохождения пакетов поделить не могут (Дурак, ага), предожил вынести функционал nat'а в mpd через ng_nat. Опять же не помогло. В процессе совместного ковыряния mpd.conf'а (C ng_nat'ом я, в общем-то, до этого "никак") добавил tcpmssfix из своей конфиги и вуаля! Еще полчаса копошений и проблему раскопали полностью, но день того-этого... кончился :).
Такое вот вождение-луноходов-по-граблям получилось.

Какая у этой басни мораль? А морали здесь нет никакой - по крайней мере у меня её вывести не получается, так что - "запомните дети, патамучта понять это нэвозможна! и не делайте так!"

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

10:10 

Запомните это дети...

Типовая установка - апдейт с 8.2. до 9.0, один винт, ATA_CAM, GPT + ZFS root. На выходе - геморрой с лоадером.
Ок. Задач по сложнее - апдейт с 8.2 до 9.0, шесть винтов в raidz, ATA_CAM, GPT + ZFS root. Выдыхаем, напрягаемся, крестимся, все-все-бэкапим, апгрейдим, апдейтим, ребутим... и все в общем-то работает, без сучка без задоринки.
Хм. Еще-более-типовая задача: апдейт с 7.2 до 9.0, gmirror. На радостЯх апдейтися, ставим ядро, ребутимся в сингл-юзер... а вотхрен! root-mount error. gm0 видится, а gm0s1a и та дэ - фиг.
Приходится разваливать рейд, грузиться с member-диска, создавать другой инстанс gmirror'а, dump-restore'ить инфу и пересобирать рейд. Половина действий из-под того же singl'а
Иде логика, иде разум?!

@темы: FreeBSD

14:45 

Типовая задача

зарезать до и больше всякого разного (Музыки, видео, бэкапов, дистрибутивов etc) используя минимальное количество болванок. Засада кроется в том, что файлы имеют разный размер, на одну болванку не лезут и вообще никак не отсортированы. Знакомо? Мне - да.

Первое НЕПРАВИЛЬНОЕ решение - берем "двухпанельный файловый менеджер"(ТМ) и начинаем... ну вы поняли, да? Почему неправильное? Муууууторно же! Да и результат на больших объемах (Болванок 15-20) прямо скажем, не блещет.
Второе НЕПРАВИЛЬНОЕ решение - tar -c(j) |split -b 4.2G archive.tar - на выходе n файлов одинакового размера. Быстро, чисто, просто. Что не так? А что будет с этим tar'ом делать какой-нибудь mp3-player? Вот-вот. Да и просто windows-пользователь не вдруг join сделает :).
Третье НЕПРАВИЛЬНОЕ решение - ну, например for i in os.walk() с поправкой на язык программирования ;). Думаю, очевидно, что нефиг велосипеды изобретать.
Так что делать-то? Ха! В комплекте cdrkit есть замечательная 3rd-party утилита dirsplit, которая делает именно то, что нам нужно - разбивает папку с изобилием файлов на каталоги требуемого нам размера. Синтаксис тоже очевиден:
dirsplit (опции) цель префикс_результата
-v verbose
-s размер
-m двигать или копировать
-L/l создавать вместо перемещения или копирования сим-хард линки
-f фильтр

Что, все так уж хорошо? Не-а!!! Может в этих ваших линуксах и да, но в Суровой Фре...
1) cdrkit сам по себе конфликтует с cdrtools прописанным в качестве зависимостей у туевой хучи пакетов. Сюрприииз! Не смертельный - можно собрать игнорируя конфликты, а установку не проводить, используя получившийся бинарник на свое усмотрение
2) Можно было БЫ - если бы не "Сюрприииииз!-2" в 9-ке cdrkit не собирается. Совсем. Broken, говорят, причем даже и не врут. Можно конечно попытаться собрать из исходников только dirsplit, но к стыду моему cmake я не знаю от слова "совсем" и разбираться с этой дьяволовой махинией не намерен. Тупик? А вот и нет!
Все, в общем-то, не так плохо. Берем с офсайта собранный package cdrkit'а для 8-ки, растариваем копируем bin/cdrkit куданадо и идем насвистывая. Вуаля!

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

10:38 

Старые песни...

... о главном. О граблях, то есть. Кто-то каждый новый год ходит в баню, а вот я столь же регулярно обновляю сервера на FreeBSD. Процесс, ей-ктулху, в своем роде не менее увлекательный, но как бы это сказать... несколько спесфисский.
Начнем с того, что 9.0 должна была выйти ДО нового года - но release announcement 'a не было. В то же время, CVS-тэг вполне себе наличествовал, а третьего января на оф. сайтах выложили дистрибутивы 9-ки. Странно, но ладно. Будем обновляться с 8.2 amd64.

Обновляем дерево исходных кодов системы, запускаем сборку мира. Упс. Custom make.conf ему не нравится - дескать, cputype должен быть дефолтовым =?. Ладно. Мне не жалко. Делаем. Собираем. Собирается. Собираем ядро по готовой конфиге. Без приключений. Ставим ядро. Ребутимся в single user, ставим мир. Нормально.
Перезагружаемся. Нормально. Делаем zpool upgrade -a. Нормально v28 в наличии. Делаем zfs upgrade. Поднимаем до 5ой версии. Норм. Не забываем (Вааааау! Нам даже напоминают!) обновить gptzfsboot. Перезагружаемся.
pmbr отрабатывает. gptzfboot отрабатывает... вроде. Только не правильно. Can't work out which disk we are booting from. Упс. Жужль говорит, что такая фиганда была с 9.0 RC2 amd64. Не решено. Впрочем... говорят, что gptzfsboot с i386 работает нормально. Проверяем - врут! При сравнении самосборки с релизом i386 diff говорит, что 'files differ', но установка не помогает. Пичаль...
Ладно, по проторенной дорожке идем в сорцы и ищем где же находится это сообщение об ошибке. Сюрприииз! Относится оно не к gptzfsboot'у а к zfsloader'у - его и меняем "с эталонного носителя" - алиллуйя! Пошла загрузка. Тыр-пыр-пыр... не могу примонтировать root. WTF?! А! МогЁт быть, в кастомном kernel'е выпилено все, кроме ATA_CAM и винт не определяется? Ладно, грузанемся с generic'ом, ну или подгрузим недостающее модулями ядра из loader prompt'а. Ребут... авотфиг.
Грузимся с эталонного носителя, импортируем zfs pool. С -f нормально. Хм. Может, zpool.cache не проапдейтился? Маунтим livecd в rw, экспортируем пул, импортируем еще раз, копируем zpool.cache куданадо. Ребут. Та же фигня. Хм. bootfs выставлен правильно? С одной стороны, в wiki сказано, что и фиг на него (В 8-ке, кстати, и впрямь фиг) - а с другой, кто их знает, что там в девятке произошло? Грузимся, импортируем, смотрим. Нет, bootfs стоит и стоит правильно. Грузимся таки с syspool'а. Чтож за фигня-то, а?
Лезем в гугль. И еще раз. И еще. Наконец видим в списках рассылки по freebsd 9-current от ажно 10-го года описание "неведомых грабель" - мол, legacy-mountpoint+vfs.root.mountfrom нонеча не true, и / надо задавать явным образом. Хм. Грузимся с livecd, импортируем пул с -o altroot=/mnt, меняем mountpoint с legacy на /, перезагружаемся и а-лилуйя! алилуйя! алиллуйя!!! Оно стартует. Уффф
Правда при загрузке оно ругается на unrecognized command 'volinit' - но это, в общем-то фигня - где-то в rc,d/zfs что-то накосячено, но жить (Тьфу-тьфу-тьфу!) оно вроде не мешает.
В общем, opensource такой опенсорц, что просто "ой!" :)

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

08:55 

FreeBSD 7.4

UFS+Gjournal+async. 1,3 ТБ раздел. Два гига на журнал. При попытке снять snapshot периодически (Раз дней эдакк в пять) падает в корку по переполнению журнала. Соответствующая PR'ка имеется, но open-статус оптимизма не внушает. Более того, недолгие рысканья по сети принесли информацию о том, что обновление до 8(.2) щастьЯ тоже не принесет. Есть мнение, что проблема связана с пользовательской активностью во время снятия снапшота - порядка 15 минут для 700Gb данных, в течении которых fs фактически находится в ro, а юзвери джамшутят, джамшутят, джамшутят и джамшутят. Gjournal у нас работает на block-level'е и журналирует как метаданные fs, так и сами данные - 2Gb того... может и не хватить. Вот только проверять это на "боевом" сервере под конец рабочего года желания нет, а имитировать такую нагрузку "в песочнице" - ну не bonnie же мне запускать, а?!
Абидна, вай... Ладно, один черт, в НГ+ буду 9.0 тестить.

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

10:13 

Что бы вы подумали, получив...

... permisson denied (public key) при попытке подключиться к серверу через SSH после недельного отсутствия на рабочем месте? Вот-вот, это самое и :).

Отключаем сеть, грузимся с физ. консоли меняем пароли, отключаем SSH на внешнем интерфейсе, начинаем копаться. В логах них...фига, даже попытки коннекта не пишутся. authorized_keys на месте, права на нем родные (400, ага), mtime - показывает, что последнее изменение было год назад, содержимое в порядке. sshd_config - на месте, последнее изменение тогда же, содержимое сравниваем с rcs-копией с backup'а - все ok. ps -ax -показывает, что sshd запускается именно что с моим конфигом. Хм. Странно. Может, sshd не тот? Запускаем ручками sshd -f /etc/ssh/sshd_config - та же фигня. Мндя. Сталбыть, sshd подменили. Гм. diff говорит, что sshd из хост-системы совпадает с sshd из jail'а, в который я через ssh захожу (Кстати, уж если что и могли сломать, так этот самый jail, в котором apache+mysql вертится), пусть и с другим ключом. Странно, но возможно, в принципе. Собираю sshd на отдельной машине, приношу, ставлю (Не, я знаю, что по уму надо бы makeworld/kernel сделать, /usr/obj притащить и поставить грузанувшись с болванки - но не в рабочее же время на "боевом" сервере!) - та же фигня. Гм. Ну так же не бывает!!!
Л-ладно. sshd -df /etc/ssh/sshd_config, цепляемся... и нифига интересного в логах. Логинимся локально... упс! ipython, установленный в качестве шелла для учетки, говорит, что у него беда с конфигом, генерит дефолтовый и дохнет! Неужели?!? Меняю шелл на tcsh, логинюсь - нормально. Цепляюсь удаленно - отлуп. Что еще изобрести? А! Отключаю аутентификацию по ключу, вробаю challenge-response + PAM, логинюсь! вау! Работает, но ssh -v, в самом конце пишет, что, мол, cannot chroot to a directory <...>. Ы?! Логинюсь, делаю chroot <...> - и впрямь, cannot. WTF?! Смотрю внимательней - блиииин! Permissions на homedir вместо 755 - 650! Я ж не так давно с ftp игрался, соответственно права на каталоги правил, а ssh-соединение с рабочей машинки до сервака висело... ну, месяца два висело без перезапуска, вот и. Не совсем правда понятно, нахрена sshd читать содержимое каталога, если путь до ~/.ssh/authorized_keys прописан в sshd_config'е и darkroom вполне читается - однако-ж вот.
Мнда. Осталось придумать, что сделать с м-мммм.... произведенными в процессе всех этих плясок-с-бубном кирпичами, и вот оно, Щастьё!

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

18:30 

На уровне идеи...

... взять (cw)Rsync, закинуть его в планировщик задачcron с частотой раз в пять минут, натравить на папку с рабочей информацией и залить результат во write-only реплику на сервер с ФС, поддерживающей copy-on-write, транзакционную семантику и live-access to snapshot (ZFS, hammer, btfs), снимки делать с той же частотой и экспортировать их через samba'у в read-only - чем не user-frendly continious-backup made in "на коленке"?
Надо потестить нагрузку на проц-сетку. плюс прикинуть объем на каждого пользователя - copy-on-write + deduplication (hammer точно могЁт) эт конечно хорошо, но все же есть у меня соменения...
В перспективе - приделать к этому web-based аггрегатор ресурсов (Собираем по папОчкам на сервере актуальный список файлов и раздаем его по http в виде smb:// ссылок всем желающим).
В качестве collaboration-software наверное, не подойдет, но live-backup вполне-вполне...

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

14:32 

Мы делили апельсин...

... много наших полегло! Или - кто бы мог подумать, что "отдать пару файлов по FTP" может оказаться ТАКОЙ проблемой!
Дано - серверЪ с FreeBSD 8.1. Самба, отдает cp866/1251, на самой, ессно, koi8-r. Нужно предоставить доступ для внешних клиентов. Ответ? Правильно, FTP. Поднимаем FTPD (Ага, две строчки в rc.conf - ftpd_enable="YES" и ftpd_flags="-4 -r -D"), рисуем ftpchroot - в путь!
Стоп машина! Народ интересуется - "А как этим пользоваться?!" Гхм. Консольный ftp не канает ;) filezilla'ы, FAR'ы и TotalCmd тоже. "Канает" только и исключительно бра-аавзеры разных типов плюс, та-дам!!! "Проводник виндовс". Врот-тя-ноги.
Нет, бравзеры "в количестве" ftp вполне даже знают ;) и русские имена после смены кодировки ;) вполне даже читают, НО! Иё-моё все свои служебные сообщения кодирует в cp1251 и при наличии на странице одновременно koi8-r файлов и cp1251 ссылок типа "папка уровнем выше" - что-нибудь обязательно окажется в виде всем знакомых "кракозябров"(ТМ), плюс - всем известная :) проблема с буквой "я" в koi8-r... Непорядок, в общем.
Что делает админ, наткнувшись на проблему с кодировкой файлов? Праааильно - вспоминает про "богодушу-мать!данный" unicode. Создаем тестового пользователя, пишем ему в .login_class ru_RU.UTF8, с помощью convmv (Ааатличнейшая штука, если кто не знал) -f koi8-r -t utf-8 -r --notest /путь преобразуем подопытного в нужный вид, добавляем к ftpd_flags="-8", пробуем... Ну, у меня опять все работает, а вот гейтцем обиженные windows'ятники неожиданно оказываются в пролете - их ё-моё с windows ехплохером внезапно! не умеют работать с unicode'ом. От слова "совсем" - в глухую виснут при попытке что-нибудь сделать. Fail.
Преобразовывать имена файлов в cp1251 - sensored. Надо конвертить "на лету". Google говорит, что такая возможность есть у ... и у ... и ... тоже умеет... Из всего разнообразия выбираем vsftpd-ext по причине простоты настроек, небольшого размера, невдолбенной секурности - ну и некоторого знакомства с сабжем ). В портах выбираем "с RC-скриптами", компилим, ставим, правим конфиг до плюс-минус следующего вида:
anonymous_enable=NO
#Нафиг анонимусов
local_enable=YES
write_enable=NO
#Read-only
dirmessage_enable=YES
xferlog_enable=YES
xferlog_file=/var/log/xferlog
xferlog_std_format=YES
idle_session_timeout=600
data_connection_timeout=120
nopriv_user=ftpuser
chroot_local_user=YES
Всех chroot'им
userlist_enable=YES
userlist_file=/etc/ftpusers
#Явно указанных пускаем
userlist_deny=NO
#Остальных нафиг
ls_recurse_enable=YES
listen=YES
listen_ipv6=NOp
background=YES
convert_charset_enable=YES
#Осторожно, ГРАБЛИ! Кодировки субпродукт желает увидеть ИМЕННО В ТАКОМ написании
#иначе - fail "без указания причин" - работать будет в стиле "что вижу, то пою" - конвертации.

local_charset=KOI8R
remote_charset=CP1251
#Преобразуем имена файлов из koi8-r в cp1251
pasv_min_port=49152
pasv_max_port=65535
Запускаем vsftpd... и наступаем на грабли. "Этот сервер поддерживает только анонимные соединения", иди нафиг. Гхм! Вот же! Вот! anonymous_enable=NO - чего тут не понятного? Фигу, "Этот сервер...". так, его этак, переставил, воткнул, поднял, нашел чужой конфиг, воткнул, посмотрел... "не выходит каменный цветок у Данилы-мастера" и все тут. Без конфига не стартует, но на его содержимое пилюёть. Где ошибка? Праааильна, в rc-скрипте. Написать соответствующий check для скрипта мантейнер порта додумался, а вот подсунуть его в run_rc_cmd "ниасилил", мало того, видимо, чтобы "злобный враг не догадался" засунуть путь к конфигу в vsftpd_flags="" этот .... секретчик воткнул в свой супер-скрипт следующую строчку:
# vsftpd_flags="/some/path/conf.file" # Not required
Мнда. Убил бы, натурально. Минут 40 на поиск насекомого убил, но - оно таки заработало. Радует. Виндузятников.

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

11:32 

Дело было вечером, делать было нечего...

... решил Шаман поднят себя imap-сервер. Полгода через SSH логиниться на сервак и читать почту с консоли... мндээээ... стыдно, в общем зато работает!!!. При всем богатстве вариантов альтернативы dovecot'у, в общем-то, нет (Ну, в самом деле! Не громоздить же на "домашний" atom'ный сервер, у которого "в прыжке" меньше 10-ти пользователей DBMail или там Courier мать-его-и-перемать!).
Вечер убил - но сервер поднял ). Особых хитростей там нет (Конфиги ОЧЕНЬ хорошо комментированы, плюс - "в комплекте" идет весь набор документации в wiki-формате), но, как водится, "есть нюансы", читай ГРАБЛИ :) - впрочем, по порядку:
ставим из портов, копируем /usr/share/doc/dovecot/example-config куда надо, начинаем править. Конфиги модульные (По сию пору не могу понять, нравится мне эта "тенденция" или нет - с одной стороны, нарушается "целостность восприятия", с другой - "уместить" в голове содержание пары-тройки "мааа-ааленьких файликов" проще, чем монструозную простыню на пять-шесть экранов) - dovecot.conf + содержимое conf.d, комментариев в них, пожалуй, даже слишком много (По ходу работы - выпилил нафиг, понадобятся - в wiki возьму).
При включении imap автоматически начинает слушаться и imaps на 993 порту, для отключения пришлось предпринять не вполне тривиальное действие - прописать куда надо что-то вроде:
service imap-login{
inet_listner imaps {
port = 0
}
}
Аутентификацию я рожал на сертификатах, так что:
ssl = required (Не 'yes'!)
disable_plaintext_auth
auth_ssl_require_client_cert=yes
auth_ssl_username_from_cert=yes
ssl_verify_client_cert=yes
ssl_cert_username_field=commonName
В качестве БД паролей используем static, запрос пароля отключаем:
passdb {
driver = static
args = nopasword=yes #Уродство, правда?(Ибо нефиг - )
}
userdb - системная /etc/passwd.
В процессе настройки наступил на грабли с:
auth_username_format= - решил lowercase'нуть полученное из сертификата имя и "срезать" доменную часть (Удруг-да появится? ))) для чего воткнул %Lu%n и получил на выходе в debug.log'е shamanshaman в качестве имени пользователя и ошибку поиска в результате. На поиск убил уйму времени и сил, но разобрался.
Еще один гнусный прикол обнаружился при попытке настроить тестовую аутентификацию через PAM - при запуске auth-worker'а от имени обычного пользователя pam_unix выдает UNIX autentication refused и "пишите письма", от root'а же все работает нормально.
В общем, долго ли, коротко - оно работает. Не понятно, правда, как убедить почтовый клиент, что сертификата, в общем-то, достаточно и пересылать имя+пароль не надо от слова "совсем"... впрочем, серверу и так хорошо, а клиент шлет себе '1' и радуется, ага.

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

14:49 

Упал-отжался!

Хожу я, понимаешь, от серверной стойки до рабочего места - как тот ученый кот - два шага в ту сторону, касание стойки - щелчок статики, два шага в другую, касание ноутбука - он же. Раз на пятый индеец быстрый глаз догадывается, что "это жжжж не спроста" и "как бы чего не вышло", но занятия, разумеется, не прекращает ;), на шестой касание пальцем "в куда-то в районе карт-ридера" вызывает видимую невооруженным взглядом искру и особый букет ощущений.
А в карт-ридере у нас SD-карточка на один гиг с системным /boot'ом... ls /boot - висяк. При-плы-ли.
Вынимаем карточку, ставим в стационарный ридер. Нуль эффекта. Угу. Приплыли. Без особой надежды переворачиваю карточку... о! Определяется. Правда UFS2 windows закономерно не узнает. ОК, цепляем обратно на ноут, грузимся с DVD'шки - da0 есть, s1a на ней нету. Делаем. Копируем /mnt2/boot, пишем по новой loader.conf, перезагружаемся. Ага. Ядро видится, система начинает грузиться... и не находит root. Гхм. Странно. Нет, ясно, что в custom'ном kernel'е были вкомпилены device ahci и options ATA_CAM, а device ata напротив, выпилены к чертям собачачьим, в то время как на дисковом GENERIC'е все строго наоборот - но zfs pool-то собран из geom-провайдеров заданных по gpt-меткам! Ллладно. Пытаюсь загрузить geom_gpt_load - система говорит, что в GENERIC оно уже вкомпилено.
Перезагружаюсь, импортирую пул - статус ONLINE, но scrub requested. Гхым. "Все хорошо, но ничего не работает". Опять же, без особой надежды (Ясен пень, надо ядро собирать по готовой спеке!) делаю этот самый scrub, перезагружаю... вааау! Вот моя система, вот мой стол родной! Уффф... на всякий случай проверяю последний бэкап на домашнем сервере - закономерное 25.12.2010, однако. Кап-пи-таль-но свезло, да...

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

20:59 

Возвращаясь к...

... напечатанному - нарисовал таки я могутный скрЫпт на puthon'е, реализующий вышеуказанную функциональность, затестил, воткнул в cron - а потом чуть не родил, пытаясь понять, почему же он, сАбака, от user'а работает как положено (Приводит resolv.conf к виду
search (список доменов)
nameserver 127.0.0.1
И auto_forward.conf к состоянию
forwarders {
список адресов из resolv.conf'а;
};
forward first;
), а от root'а полностью убивает все линки в auto_forward.conf'е и выпиливает инструкцию nameserver из resolv.conf'а.
Ларчик, как водится, открылся просто:
целей отладки для я воткнул в свой скрипт не subprocess.Popen(['/usr/sbin/rndc', 'reload']), а subprocess.Popen(['/etc/rc.d/named', 'restart']) оставив named_auto_forward="YES" из rc.conf'а в неприкосновенности. В результате, вместо "мягкой" перезагрузки BIND'а происходил его рестарт родным скриптом, ожидающим, хе-хе! соответствующего содержимого resolv.conf'a и правящим auto_forward.conf под себя...
Мораль сей басни выводите сами )

@темы: FreeBSD, Python

09:05 

Не жизнь, а анекдот!

Решил я таки вкорячить себе midori - ну-там "на попробовать", заместо firefox'а. В процессе понадобилось обновить ICU ажно до 4.6 (А /usr/ports/UPDATING по таким "малозначительным" поводам мы не читаем, ага :)))) - ну почти в точности по Каганову вышло:
"Мне на хрен не уперлось читать тонны документаций и медитировать, что означает и как поступить если «ОШИБКА КОМПИЛЯЦИИ: установите библиотеку не ниже huiTamLib-2.4.0«. При том, что в системе, разумеется, давно присутствует какая-нибудь «huiTamLib2-5.1"? Ее предлагается снести, чтобы отвалилось полсистемы или обновить до старой, чтоб полсистемы отвалилось? Вам же знаком этот повседневный линуксовый дзен, не правда ли? "(С)
Оно, собственно, собралось и даже поставилось - но после включения дома "отвалилось полсистемы" и вместо xfce пришлось пускать openbox ). За ночь portupgrade таки перелабал полсистемы (Теперь, за вычетом некоторых "нечуйствительных" мелочей софт у меня "в актуальном состоянии") - в процессе выяснилось, что BSD'шники умудрились поломать ATK, с которым собирается туева хуча гномосятины, но -fk к portupgrade'у выручил. В общем, не пересобрались у меня только claws-mail (Ставить ради _документации_ к почтовику весь tetex мне как-то... оне бы еще OpenOffice предложили, шлимазлы!) и... gtk, внаглую наплевавший на шаманство с atk.
Попытка установить "ручками" к успеху так же не привела - huiTamLib2-5.1 в очередной раз оказалась не той версии, впрочем, UPDATING в очередной раз дал ответ - "Мужик! А ты снеси старую версию полностью и поставь новую!", так и сделали. Старую - снесли, а новая, ессно, не поставилась ))). Версия в Atk-1.0.gir не та, мол. Впрочем, на эти грабли я уже вставал, и что надо (1.0 на 1.2 в repository version) сменил, но к успеху и это не привело - на сий раз со страшным грохотом (Assertion error! и та дэ) навернулся питоний g-ir-scanner. Пришлось лезть ему унутрь и смотреть, что там не так. Посмотрел, подумал... и выпилил соответсвтующий assert нафиг. И что вы думаете? Сработало! В точности по анекдоту:
" - Этого, этого и этого - расстрелять!
- Не надо!
- Этого - не надо, он не хочет."
ага. *nix'овый дзен во всем его многообразии, даа.... :)

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

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

главная