Рубрика: FreeBSD Автор: Hottab :: Четверг 19 ноября 2009 в 12:14

Суть проблемы - уже на нескольких серверах загрузиться с установочного диска №1 FreeBSD 7.2 не удалось. Пробовались разные методы шаманства, переключение CD-ROM на другой порт, замена привода, отключение SATA- контроллера, подключение привода через внешний контроллер - ничего не помогло. При этом этот же CD-диск грузился на соседнем сервере без проблем.

Оказалось - проблема известна разработчикам, и на странице написано :

Note: late in the testing cycle it was discovered some machines do not recognize the i386 disc1 as bootable (they just fall through to booting off the next boot device). All affected machines did see the other discs as bootable.

Вот как то так. Интересно что мешает решить проблему с загрузчиком и выложить корректный диск..

Решение проблемы в моем случае - тоже довольно простое.
Записываем два диска, один - установочный диск FreeBSD 7.2 (disk1), второй - Live CD FreeBSD 7.2.

Грузимся с Live диска, а после загрузки меняем диск в приводе на disk1
Вот такой live hack :)


Рубрика: FreeBSD Автор: Hottab :: Понедельник 28 сентября 2009 в 20:50

Озадачился мониторингом температуры процессора на серверах.
Сам парк серверов представляет из себя сборную солянку, а ОСи - в основном FreeBSD, 6.2 и 7.2. Процессоры - Intel.

На FreeBSD 7.2 все решилось достаточно просто.
1. Собираем ядро с поддержкой coretemp

device coretemp

2. Перезагружаемся и смотрим:

# sysctl -a | grep hw.acpi.thermal.tz0.temperature
hw.acpi.thermal.tz0.temperature: 40.0C

Подробности:

# man coretemp
CORETEMP(4) FreeBSD Kernel Interfaces Manual CORETEMP(4)

NAME
coretemp -- device driver for Intel Core on-die digital thermal sensor
...
HISTORY
The coretemp driver first appeared in FreeBSD 7.0.

UPDATE: Не все так просто оказалось. Работа этого варианта зависит от реализации acpi производителя метринской платы.
Собранная статистика .

Самое интересное - это FreeBSD 6.2 , на материнских платах Intel ( SE7520JR2 ).
Сразу скажу - использование healthd, lmmon, mbmon - вменяемых значений не дало.

Найдено и опробовано следующее решение:

# uname -rpm
6.2-RELEASE-p12 i386 i386

1. Пересобираем ядро с поддержкой следующих девайсов:

device smb
device smbus # System management bus
device intpm # Intel power management
device iicbus # I2C bus system
device iicsmb # I2C to SMB bridge
device iicbb # I2C generic bit-banging driver

2. Загружаем два ipmi модуля:

# kldload ichsmb.ko
# kldload ipmi.ko
# kldstat
Id Refs Address Size Name
1 11 0xc0400000 529f78 kernel
6 1 0xca101000 4000 ichsmb.ko
7 1 0xca10d000 a000 ipmi.ko
....

После добавления этих модулей смотрим /var/log/messages:

# tail /var/log/messages
kernel: ichsmb0: port 0×540-0×55f irq 17 at device 31.3 on pci0
kernel: ichsmb0: [GIANT-LOCKED]
kernel: smbus0: on ichsmb0
kernel: smb0: on smbus0
kernel: ipmi0: on smbus0
kernel: ipmi0: SSIF mode found at address 0×42 on smbus
kernel: ipmi0: IPMI device rev. 1, firmware rev. 2.81, version 1.5
kernel: ipmi0: Number of channels 0
kernel: ipmi0: Attached watchdog

3. Если все прошло хорошо, значит осталось установить утилиты для работы с IPMI. Я использовал пакет freeipmi.

# cd /usr/ports/sysutils/freeipmi
# make install clean

4. Проверяем работает ли то что нам нужно.
Все сенсоры:

# ipmi-sensors

...
25: Sys Fan 2A (Fan): 10593.22 RPM (NA/4237.29): [OK]
26: Sys Fan 2B (Fan): 7369.20 RPM (NA/3026.63): [OK]
27: Sys Fan 3A (Fan): 10593.22 RPM (NA/4237.29): [OK]
28: Sys Fan 3B (Fan): 7369.20 RPM (NA/3026.63): [OK]
29: Sys PCI Fan (Fan): 11299.44 RPM (NA/3531.07): [OK]
30: CPU 1 Therm Ctrl (Temperature): 0.00 unspecified (NA/79.95): [OK]
31: CPU 2 Therm Ctrl (Temperature): 0.00 unspecified (NA/79.95): [OK]
32: Proc1 Core Temp (Temperature): 43.00 C (5.00/99.00): [OK]
33: Proc2 Core Temp (Temperature): 44.00 C (5.00/99.00): [OK]
34: CPU1 12V (Voltage): 12.21 V (10.91/13.14): [OK]
35: CPU2 12V (Voltage): 12.15 V (10.91/13.14): [OK]
36: FrontPanel Temp (Temperature): 25.00 C (0.00/48.00): [OK]
37: Scrty Violation (Platform Chassis Intrusion): [OK]

Или только те что интересуют:

# ipmi-sensors -s 32,33
32: Proc1 Core Temp (Temperature): 43.00 C (5.00/99.00): [OK]
33: Proc2 Core Temp (Temperature): 44.00 C (5.00/99.00): [OK]

Не забываем добавить в /boot/loader.conf загрузку модулей:

# echo 'ichsmb_load="YES"' >> /boot/loader.conf
# echo 'ipmi_load="YES"' >> /boot/loader.conf

Вот собственно и все :)


Рубрика: FreeBSD, Хостинг Автор: Hottab :: Четверг 10 сентября 2009 в 12:13

Обновил тут Nagios до 3.2 (система FreeBSD 7.2) . И обнаружил что пункт “Map” в меню не работает. При более детальном рассмотрении оказалось что не собрались некоторые cgi-скрипты.

Как оказалось, configure при обновлении не увидел библиотек gd.

Лечится просто. Во-первых, убедитесь что gd установлена.
Во-вторых выполните configure со следующими параметрами:

# ./configure --with-command-group=nagios --with-gd-lib=/usr/local/lib --with-gd-inc=/usr/local/include

и потом

# make clean && make && make install

должно работать :)


Рубрика: Linux Автор: Hottab :: Пятница 4 сентября 2009 в 12:56

Потребовалось тут установить php версии 4.3.5 на пятую Centos.
Думалось что задача тривиальная, но оказалось что не совсем.
Во первых - в репозиториях уже нет php4.3.5
Во вторых - так просто и сорсов он не компилился.

Вот об этом “во вторых” подробнее.

Сначала пришлось установить несколько devel пакетов.
В моем случае потребовались следующие:

#yum install gd-devel flex bison httpd-devel libjpeg-devel libpng-devel libxml2-devel libxslt-devel

Затем скачал с php.net нужную версию и приступил к компиляции ( компилировал модулем apache 2.2).

#./configure --with-apxs2=/usr/sbin/apxs --prefix=/usr/local/php --with-mysql --enable-mbstring --with-config-file-path=/usr/local/etc --enable-ftp --enable-libxml --with-dom-xslt --with-libxml-dir=/usr/local --enable-reflection --enable-force-cgi-redirect --enable-fastcgi --with-iconv --with-regex=php --disable-ipv6 --prefix=/usr --mandir=/usr/local/man --infodir=/usr/local/info/ --with-gd=/usr --with-dom --enable-gd-native-ttf=/usr --with-jpeg-dir=/usr --with-png-dir=/usr --with-ttf --with-zlib-dir=/usr --disable-posix --enable-inline-optimization --without-pear --disable-debug

Конфигурация прошла без ошибок а вот make не пошел.
Первая ошибка при make :

sapi_apache2.c:38:25: error: apr_strings.h: No such file or directory
In file included from /home/src/php-4.3.5/sapi/apache2handler/sapi_apache2.c:39:

Лечится это симлинками :

# ln -s /usr/bin/apu-1-config /usr/bin/apu-config
# ln -s /usr/bin/apr-1-config /usr/bin/apr-config

Делаем make clean && make и оппа - вторая ошибка:

....
sapi_apache2.c:38:
/usr/include/apr-1/apr-i386.h:270: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘apr_off_t’

Это исправляется в два действия.
1. Выполняем следующее:

# apr-config –cppflags –cflags

На экран выведется примерно такое :

-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread

2. Копируем эту строку и вставляем ее в файл Makefile.global , в строку DEFS.
Должно получится примерно так:

DEFS = -DPHP_ATOM_INC -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread -I$(top_builddir)/include -I$(top_builddir)/main -I$(top_srcdir)

Опять

# make clean && make && make install

и все. Должно работать :)


Рубрика: Хостинг Автор: Hottab :: Понедельник 10 августа 2009 в 11:52
Nagios. Все ок.

Nagios. Все ок.

Отлично когда вот так :)
Скоро статья по настройке нагиоса и плагинов :)


Рубрика: FreeBSD Автор: Hottab :: Вторник 16 июня 2009 в 18:14

Иногда жесткие диски сыпятся. И часто - совсем не в подходящее время, да и бэкап устарел… А значит приходится шевелиться :)

Вообщем следующая ситуация:

Сервер “мохнатого” года, рэйда никакого, диск SATA, старый, система FreeBSD 5.x.

После переезда сервер не поднялся, а при более пристальном разглядывании выяснилось что сильно посыпался жесткий диск. Посыпался до такой степени, что при чекании разделов уходил в kernel panic, а некоторые разделы вообще не чекал, ругался примерно так - file system is incorrect, bad superblock, run fsck manually …

Решение проблемы:
В наличии три диска
ad0 - старый диск, сыпется.
ad2 - новый диск, страховочная копия.
ad3 - новый диск, станет рабочим, вместо старого.

1. Подключаем на гарантированно работающем системнике старый диск ad0 , новый диск ad2 (лучше большего объема) и cdrom.
2. Грузимся с CD FreeBSD, переходим в режим live-cd.
3. Делаем страховочную копию (старый диск может рассыпаться в любой момент)
# dd if=/dev/ad0 of=/dev/ad2 bs=64k conv=noerror

4. Откладываем бэкап в сторону.
5. Перезагружаемся.

Поднимаем такую же систему на новом диске.

1. Подключаем диски ad0 и ad3.
1. Грузимся с CD FreeBSD, переходим в режим live-cd.
2. Разбиваем новый диск похожим образом (примерно так же, как на старом, главное чтобы разделы стали не меньше чем были). Не забываем установить загрузчик (Boot Manager) на новый диск.
3. Перезагружаемся, на всякий случай, и проверям что все изменения файловой системы точно сохранились на новом диске.
4. Самое интересное. Находимся в режиме live-cd. Теперь надо подключить разделы со старого диска. Для этого восстанавливаем superblock.
4.1. Ищем альтернативные суперблоки
# newfs -N /dev/ad0s1a
Не забываем ключ -N . Видим примерно следующее:

/dev/ad0s1a: 1024.0MB (2097152 sectors) block size 16384, fragment size 2048
using 6 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, 1129216, 1505568, 1881920

Нас интересует строка “super-block backups (for fsck -b #) at:”
и супер-блоки, которые там указаны.
4.2. Исправляем супер-блок
# fsck_ufs -b 160 /dev/ad0s1a
4.3. Монтируем исправленный раздел в принудительном режиме, так как нам надо только чтение
# mount -f /dev/ad0s1a /mnt/old

5. Теперь сам перенос. Монтируем раздел с нового диска (ad3):
# mount /dev/ad3s1a /mnt/new
Копируем tar-ом содержимое раздела
# tar -C /mnt/old -cvf - . | tar -C /mnt/new -xpf -

6. Убедились что перенос закончился, можно проверить по объему, например, командой df -h. Отмонтируем разделы /mnt/old и /mnt/new

7. Повторяем операции 4-6 (если нужно восстановление super-block) или 5-6 для всех разделов.

Вот собственно и все. Некоторые ньюансы:
Файловые системы должны быть одинаковы на старом и новом диске. То есть, если FreeBSD на старом диске была 5.х и выше - скорее всего у вас UFS2 и при создании разделов на новом диске можно использовать любой новый live-cd . Если же на старом диске 4.x - на новом тоже нужно будет создать разделы с UFS1.
В версии 4.х также не будет работать fsck_ufs -b, можно использовать dd:
# dd if=/dev/ad0s1a skip=32 of=/dev/ad0s1a seek=16 bs=512 count=16
На всякий случай, до прямого копирования , можно сохранить состояние секторов “как было”:
#dd if=/dev/ad0s1a skip=16 of=/old_16 bs=512 count=16


Рубрика: Linux, Хостинг Автор: Hottab :: Среда 27 мая 2009 в 13:25

Довольно часто на одном VE сервере должны работать несколько нод, с разным приоритетом (в зависимости от выполняемых задач, тарифных планов и т.п.).

Было опробовано два метода разделения ресурсов.

Первый - жестко задавался CPULIMIT.

Этот метод выделяет ноде как бы виртуальный процессор (в процентах CPULIMIT от реального процессора), то есть нода работает, к примеру, на процессоре 200Mzh .

Второй - CPULIMIT устанавливается в ноль, то есть не ограничевается, но для каждой ноды прописывается ее “удельный вес“, параметр CPUUNITS. Объясню данный метод на примере.

Есть две ноды, одна с критичными задачами, другая - техническая, к примеру, для бэкапов. Первой ноде присваиваем CPUUNITS=200, второй CPUUNITS=100.

В результате получаем следующую ситуацию. При загрузке обоих нод на 100 процентов, первой ноде (CPUUNITS=200) будет выделено 66% процессорных ресурсов, а второй (CPUUNITS=100) - 33% .

Резюме:
Теперь о том что получилось на практике.

При балансировке первым методом каждой ноде выделялось определенное количество процессорных ресурсов, которых с трудом хватало на выполнение задач (apache, mysql). В результате высокий LA на самой ноде, ошибки TCP на VE, и более высокий LA, как следствие, на всем VE.

При использовании второго метода ресурсы CPU для каждой ноды не имеют жестких ограничений. Это значит что каждая нода может использовать процессор на максимальную мощность, в каждый момент времени (в соотвествии с “удельным весом“). Так как в реальности idle процессора достаточно большой, то это позволяет каждой ноде использовать весь объем процессорной мощности, и ограничения вступают в силу только в момент одновременной высокой нагрузке нескольких нод.

Для разных задач можно использовать как каждый метод по отдельности, так и комплексно.


Рубрика: FreeBSD Автор: Hottab :: Воскресенье 24 мая 2009 в 1:02

Собственно сабж:
ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/


Рубрика: FreeBSD Автор: Hottab :: Воскресенье 24 мая 2009 в 0:52

Если в логах появляется такое :

kern.ipc.maxpipekva exceeded; see tuning(7)

можно потерять консоль на машину.

Моя ситуация - на клиенте был подключен NFS ресурс, один из файлов на этом ресурсе запускался через крон, достаточно часто. Затем NFS сервер был перенесен, но fstab на клиенте не был исправлен. В итоге каждый запуск скрипта по крону создавал процесс, который так и висел, не отваливаясь, а затем закончился буфер.

Резюме - внимательнее надо быть, на будущее ..
Ну и иметь ввиду что NFS коннекты так просто не умирают.


Рубрика: FreeBSD Автор: Hottab :: Пятница 22 мая 2009 в 17:54

Полезности, переодически нужно бывает

Россия:

  • cvsup.ru.FreeBSD.org
  • cvsup2.ru.FreeBSD.org
  • cvsup3.ru.FreeBSD.org
  • cvsup4.ru.FreeBSD.org
  • cvsup5.ru.FreeBSD.org
  • cvsup6.ru.FreeBSD.org
  • cvsup7.ru.FreeBSD.org

Полный список здесь


Следующая страница »

Copyright © 2009 Горячий [TAB].