Архивы рубрики ‘Статьи’

Задача: Нужен доступ к диску гостевой ОС, без захода в саму ОС. Есть образ диска в виде файла.

Итак, пробуем, как говорит man, делаем loopback устройство и монтируем в нужную папку.
Смотрим какие loopback устройства у нас и какое свободное мы можем использовать для своих целей. Следующая команда даст вам на это ответ:
# losetup –a
/dev/loop0: [0903]:98317 (/vm/vps1.img)
/dev/loop1: [0903]:98314 (/vm/vps2.img)
/dev/loop10: [0903]:98316 (/vm/vps3.img)
/dev/loop11: [0903]:98312 (/vm/vps4.img)
/dev/loop12: [0903]:98318 (/vm/vps5.img)
/dev/loop13: [0903]:98315 (/vm/vps6.img)
/dev/loop14: [0903]:98313 (/vm/vps7.img)
/dev/loop15: [0903]:98311 (/vm/vps8.vm)

Итак, мы можем использовать 16 устройство или выше, они свободны.
Создаем устройство:
# losetup /dev/loop16 /vm/vps5_1.img

Пробуем подмонтировать устройство:
# mount /dev/loop16 /mnt/vps5/
mount: you must specify the filesystem type

Система выдает ошибку, пробуем указать тип файловой системы:
#mount -t ext2 /dev/loop16 /mnt/vps5/
mount: wrong fs type, bad option, bad superblock on /dev/loop16,
       missing codepage or other error
       In some cases useful info is found in syslog — try
       dmesg | tail  or so

Все равно ошибка, в чем же дело? Все просто, ваш файл явно разбит на несколько устройств, поэтому система не понимает, что вы от нее хотите. Проверяем это утверждение следующей командой:
#fdisk -l /dev/loop16
Disk /dev/loop16: 20.9 GB, 20971520000 bytes
255 heads, 63 sectors/track, 2549 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
        Device Boot      Start         End      Blocks   Id  System
/dev/loop16p1   *           1          65      522081   83  Linux
/dev/loop16p2              66         130      522112+  82  Linux swap / Solaris
/dev/loop16p3             131        2549    19430617+  83  Linux

Так и есть, как же нам добраться к 3-му разделу? Поглядим документацию к losetup и найдем в ней опцию «-o offset», тоесть смещение. Второй вопрос, как нам высчитать это смещение? Тоже просто, используем команду fdisk для этого.
Итак:
# fdisk -ul /dev/loop16
Disk /dev/loop16: 20.9 GB, 20971520000 bytes
255 heads, 63 sectors/track, 2549 cylinders, total 40960000 sectors
Units = sectors of 1 * 512 = 512 bytes
 
       Device Boot      Start         End      Blocks   Id  System
/dev/loop16p1   *          63     1044224      522081   83  Linux
/dev/loop16p2         1044225     2088449      522112+  82  Linux swap / Solaris
/dev/loop16p3         2088450    40949684    19430617+  83  Linux

Из данных видим, что один сектор занимает 512 байт, а сместится нам нужно на 2088450 (поле Start у третьей партиции).
Итого получаем: 512 x 2088450 = 1069286400
Эту цифру мы будем использовать при создании блочного устройства. Итак:
#losetup –d /dev/loop16
#losetup –o 1069286400 /dev/loop16 /vm/vps5_1.img
#mount –t ext3 /dev/loop16 /mnt/vps5/

Дело сделано!

Все казалось бы просто, вытаскиваем ядро с kernel.org, распаковываем в /usr/src/kernel:

#tar -xjf linux-2.6.32.32.tar.bz2

#cd linux-2.6.32.32

ставим gcc и ncurses-dev, так как без них не обойтись:

yum -y install gcc

yum -y install ncurses-dev

Ставим свежий binutils, на тот момент binutils-2.20.1.

Возвращаемся к сборке ядра.

#cd /usr/src/kernel/linux-2.6.32.32

#make menuconfig

Переходим в General setup и включаем enable deprecated sysfs features which may confuse old userspace.

Ибо без этой опции, новое ядро выдаст вам при загрузке что-то наподобие:

mount: could not find filesystem ‘/dev/root’

Kernel panic …

Далее по шаблону:

#make all

#make modules_install

#make install

#reboot

Видим рабочее новое ядро и бежим пить пиво :)

В FreeBSD есть своя собственная утилита для теста производительности жестких дисков, имеет она название diskinfo. Утилита имеет несколько ключей, можно получить сведения о следующих характеристиках диска: скорость передачи данных, время позиционирования головок.

Пример использования:

diskinfo -c /dev/ad14
/dev/ad14        

512             # sectorsize       
750156374016    # mediasize in bytes (699G)
1465149168      # mediasize in sectors
1453521         # Cylinders according to firmware.
16              # Heads according to firmware.
63              # Sectors according to firmware.
ad:S13UJ1BQ908897       # Disk ident.

I/O command overhead:
time to read 10MB block      0.111087 sec       =    0.005 msec/sector
time to read 20480 sectors   2.361939 sec       =    0.115 msec/sector
calculated command overhead                     =    0.110 msec/sector

Если вы читаете эту статью, то уже наверное столкнулись с проблемой, что после перекомпиляции php с работающим mpm-itk получаем невеселую картину: ioncube и zend optimizer не хотят подгружаться и соответственно не работают. Я долго искал решение данной проблемы, задавал вопрос на форуме Searchengines и других специализированных форумах, но местные гуру порекомендовали исправить руки. И найдя в чем загвоздка, я сомневаюсь в их компетенции. Итак, что же происходит, почему ioncube и zend не работают? Причина в том, что при компиляции php, конфигуратор решает, что apr и apache работает в режиме “thread safety”, ну и соответственно добавляет везде где можно ключи чтобы и php был собран в этом режиме. Итак, чтобы отучить конфигуратор от этих темных мыслей применяем перед конфигурацией следующий patch:

— php-5.2.17/configure.orig   2011-01-09 11:32:18.000000000 +0200
+++ php-5.2.17/configure        2011-01-09 11:35:06.000000000 +0200
@@ -6380,7 +6380,7 @@
;;
esac

-  if test «$APXS_MPM» != «prefork»; then
+  if test «$APXS_MPM» != «itk» -a «$APXS_MPM» != «prefork»; then

enable_maintainer_zts=yes
if test «$pthreads_working» != «yes»; then
@@ -7228,7 +7228,7 @@
;;
esac

-  if test «$APXS_MPM» != «prefork»; then
+  if test «$APXS_MPM» != «itk» -a «$APXS_MPM» != «prefork»; then

enable_maintainer_zts=yes
if test «$pthreads_working» != «yes»; then

— php-5.2.17/sapi/apache2handler/config.m4.orig       2007-07-12 02:20:37.000000000 +0300
+++ php-5.2.17/sapi/apache2handler/config.m4    2011-01-09 11:45:40.000000000 +0200
@@ -117,7 +117,7 @@
;;
esac

-  if test «$APXS_MPM» != «prefork»; then
+  if test «$APXS_MPM» != «itk» -a «$APXS_MPM» != «prefork»; then
PHP_BUILD_THREAD_SAFE
fi
AC_MSG_RESULT(yes)

Версию patch-а текстовым файлом можно скачать тут:  php-mpm-itk.patch

Итак, возникла потребность перевести SATA контролер с режима IDE в AHCI. Сменил режим в BIOS, перезагрузил сервер и получил kernel panic. Оказалось что не все так просто.

Итак, что нужно сделать чтобы система загрузилась:

1) возвращаем режим IDE в BIOS, загружаем систему.

2) Открываем на редактирование /etc/modprobe.conf и ищем строчку:

alias scsi_hostadapter ata_piix

Заменяем ее строчкой:

alias scsi_hostadapter ahci

3) пересобираем образ initrd с поддержкой AHCI:

mkinitrd —preload=ahci /boot/initrd-`uname -r`-ahci.img `uname -r`

4) правим grub.conf , добавляем новый пункт меню с новым initrd

5) перезагружаем сервер, входим в BIOS и выставляем режим AHCI, сохраняем настройки и загружаем систему. После загрузки системы просматриваем вывод dmesg и видим что AHCI включился.

Не будем вдаваться в подробности, что такое MPM и с чем его едят, кому интересно –это сокращение от Multi-Processing Module. mpm-itk базируется на традиционном prefork MPM + добавлены некоторые функции, например возможность ограничения количества соединений на виртуальный хост, задание имени пользователя и группы от которой будет работать Apache на определенном виртуальном хосте и последнее свойство – задание приоритета работы в системе для виртуального хоста.

Итак, зачем нам нужно устанавливать этот MPM? Например:

1) для того чтобы пользователи постоянно не жаловались, что они не могут удалить те или иные файлы созданные через веб интерфейс, так как виртуальный хост будет теперь работать от имени пользователя в системе

2) исчезает головная боль у системного администратора с квотированием места для веб сайтов. Теперь файлы закачанные на сервер через веб интерфейс имеют владельца и группу пользователя, соответственно попадают в подсчет квоты.

3) приоритет процессов в системе. Очень удобно “душить” очень сильно грузящие сервер сайты

4) задание количества соединений на виртуальный хост – уходит сюрприз когда один сайт съедает максимальное количество соединений выставленных для всего сервера.

5) так как виртуальный сервер (домен пользователя) работает с правами пользователя, то возможно установить ограничение на процессорное время в системе.

Спросите почему не использовать тот же suphp? Причины: 1) у suphp есть куча ситуаций когда php код написанный под mod_php не работает. 2) suphp не работает с php кэшерами (eaccelerator, xcache и т.д.) 3) большая нагрузка на сервер

Итак, с плюсами разобрались, начнем установку. Первое это обновляем  apache и php в DirectAdmin до последней стабильной версии. Далее копируем архив apache с /usr/local/directadmin/custombuild , например в /usr/local/src, разархивируем его. Заходим на сайт разработчика mpm-itk: http://mpm-itk.sesse.net/ находим там diff файл и закачиваем его в директорию распакованного архива apache.

Запускаем patch, который внесет изменения в код:

#patch –p1 <apache2.2-mpm-itk-20090414-00.patch

Смотрим вывод и если ошибок нету то запускаем buildconf, он должен пройти без ошибок, если ошибки есть то смотрим что не хватает, например expat или autoconf, их нужно будет установить и повторить запуск buildconf. После этого архивируем директорию пропатченного apache:

#tar czf httpd-2.2.16.tar.gz httpd-2.2.16/

И копируем архив в директорию custombuild

#cp –f httpd-2.2.16.tar.gz /usr/local/directadmin/custombuild/

Переходим в директорию custombuild, снимаем md5 сумму с архива httpd-2.2.16.tar.gz и заменяем ею текущую md5 сумму в versions.txt

Приступаем к редактированию новых темплейтов для виртуальных хостов:

1) в директории /usr/local/directadmin/data/templates создаем поддиректорию custom и копируем в нее все virtual_host* конфигурационные файлы.

2) редактируем эти конфигурационные файлы, находи в них строку SuexecUserGroup и заменяем ее на AssignUserID.  Если планируете использовать директивы MaxClientsVHost и NiceValue, то добавляете их.

Теперь переходим к процессу установки нового Apache. Создаем в директории /usr/local/directadmin/custombuild директорию custom. Копируем в нее с директории configure директорию ap2. Редактируем скопированный configure.apache и добавляем в конец ключ «—with-mpm=itk», приступаем к сборке:

#/usr/local/directadmin/custombuild> ./build apache

Все, Apache пересобран, конфигурационные файлы изменены. Если у вас до этого были уже созданы пользователи и домены, то не забываем сбросить владельцев на файлах и директориях, и добавить секюрности:

# chown -R user1:group1 public_html
# cd public_html
# find . -type d -exec chmod 750 {} \;
# find . -type f -exec chmod 640 {} \;

Далее проверяем свою работу, создаем в директории любого домена php скрипт следующего содержания:

<?php system("id"); ?>

Смотрим результат через веб, при работе обычного Apache будет такой результат:

uid=1004(apache) gid=1004(apache) groups=1004(apache)

При правильной работе Apache с mpm-itk результат будет такой:

uid=1500(user1) gid=1500(group1) groups=1500(group1)

Удачи

Попросили знакомые недавно посмотреть проблему связанную с BGP. История такая: есть у них клиент, который анонсит через них свою AS + сеть. У клиента на этой сети несколько серверов. И вот в одно прекрасное «прохладное» августовское утро он им звонит и говорит, что все его сервера не работают, и просит их перегрузить.

Народ проверил доступность серверов, на всяк пожарный перегрузили, с внутренней сети сервера клиента доступны, а с мира нет. Долго бегали с бубном они, звонили аплинкам – не нашли причину. И вот эту проблему дали мне, пообещав щедро утолить мою летнюю жажду.

Я проверил настройки BGP, анонсы сети есть и уходят на аплинков. С аплинков сеть доступна, а дальше нет, уже на UA-IX сети не видно. Почесав репу решил проверить что же там в RIPE и о чудо нету объекта ROUTE. Итак, напомню, что объект ROUTE отвечает за то какой автономной системе принадлежит сеть. На основании этой информации строятся фильтры. Собственно удалив объект ROUTE из базы RIPE вы указываете, что данная сеть и AS не роутится, т.е. фильтруются. Перестройка фильтров происходит раз в сутки.

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

Итак, вы наверное уже не раз сталкивались с вопросом когда нужно быстро переместить домен с аккаунта одного пользователя на другой аккаунт. Вы делали резервную копию аккаунта, удаляли домен, потом добавляли домен на другом аккаунте и восстанавливали данные с резервной копии. Оказывается все можно сделать намного проще, итак:

cd /usr/local/directadmin/scripts
./move_domain.sh domain.com olduser newuser

вместо domain.com olduser newuser ставим свои значения, а то есть домен, старый владелец, новый владелец.

После переноса не забываем сменить владельца на файлы и директории перенесенного домена.

Сегодня мы поговорим о утилите find и что можно с помощью нее сделать.

1) с помощью утилиты find можно найти нужные нам файлы и директории, например:

найдем все файлы в текущей папке с вложениями, которые имеют расширения .html:

find . -type f -name ‘*.html’ –print

найдем все директории в текущей папке с вложения, которые имеют в названии слово “admin”:

find . -type d -name ‘*admin*’ –print

2) с помощью утилиты find можно не только найти файлы и директории по маске, но и произвести с ними действия, для этого служит ключ –exec

Примеры:

Нужно сменить права на 644 на все файлы в текущей директории рекурсивно:

find . -type f -exec chmod 644 {} \;

Нужно сменить права на 755 на все директории в текущей директории рекурсивно:

find . -type d -exec chmod 755 {} \;

Итак, мы видим что с утилитой find работать очень просто и с помощью нее можно легко все найти и проделать любые действия с файлами и директориями. Успехов вам в работе.

Если вы настроили обработку php файлов на вашем сервере через suphp, то вы больше не сможете изменять переменные php через переменные php_value и php_flag в вашем htaccess файле. Для этого вам теперь нужно использовать свой php.ini файл или общий php.ini файл сервера. Так как общий php.ini файл изменять не рекомендуется, так как все внесенные вами изменения в этот файл коснутся ВСЕХ сайтов на вашем сервере, то у вас остается только один вариант – собственный php.ini файл. Итак, вы создали php.ini файл в каталоге вашего сайта, добавили в него свои собственные переменные, но phpinfo показывает что ваши изменения не вступили в силу. В чем же проблема? Если вы внимательно посмотрите phpinfo, то увидите что ваш php.ini файл не обрабатывается.

Итак, чтобы php увидел ваш php.ini файл, вам нужно добавить в htaccess одну строку:

SetEnv PHPRC /home/user

где /home/user – полный путь к каталогу, где находится ваш php.ini файл.

Еще раз проверяем информацию в phpinfo, видим что все подхватилось, радуемся и бежим пить пиво :)