Stable IT

Saturday, 6 November 2010

http://0pl.ru/ustanovka-roundcube-v-debian-lenny/

Сам не ставил, лишь бего проглядел, но способ годный :)

Friday, 5 November 2010

Установка 64 битного ядра от Fedora 14 (2.6.35) на Debian 6 Squeeze

Пожалуйста, только не спрашивайте зачем это пригодилось :) Надо и все :)

Итак, для начала нам нужно найти собранный пакет от Fedora, поиски мы начнем со страницы: https://admin.fedoraproject.org/pkgdb/acls/name/kernel, там будет ссылка "Build Status", щелкаем по ней и попадаем на страницу http://koji.fedoraproject.org/koji/packageinfo?packageID=8, там находим нужное нам ядро по суффиксу (fc14) и версии kernel-2.6.35.xxx. В моем случае, ядро оказалось версии: kernel-2.6.35.6-50.fc14. Далее после щелчка по нужной версии ядра мы оказываемся на странице http://koji.fedoraproject.org/koji/buildinfo?buildID=202926, прокручиваем ее вниз до блока RPMS и ищем там "x86_64". Рядом с нужным нам ядром kernel-2.6.35.6-50.fc14.x86_64.rpm будет ссылка download, копируем ее и возвращаемся на машину с Дебияном.

cd /usr/src
wget http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.6/50.fc14/x86_64/kernel-2.6.35.6-50.fc14.x86_64.rpm

Теперь как вариант попробуем поставить rpm и воткнуть ядро:

apt-get install -y rpm

Для тестов нам нужен rpm новее версии 4.8, старый rpm пакетов от fc14 не поймет:

rpm --version
RPM version 4.8.1

Пробуем поставить:

rpm -Uhv kernel-2.6.35.6-50.fc14.x86_64.rpm
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
error: Failed dependencies:
fileutils is needed by kernel-2.6.35.6-50.fc14.x86_64
module-init-tools is needed by kernel-2.6.35.6-50.fc14.x86_64
initscripts >= 8.11.1-1 is needed by kernel-2.6.35.6-50.fc14.x86_64
grubby >= 7.0.10-1 is needed by kernel-2.6.35.6-50.fc14.x86_64
dracut >= 001-7 is needed by kernel-2.6.35.6-50.fc14.x86_64
linux-firmware >= 20100806-2 is needed by kernel-2.6.35.6-50.fc14.x86_64
/sbin/new-kernel-pkg is needed by kernel-2.6.35.6-50.fc14.x86_64
/bin/sh is needed by kernel-2.6.35.6-50.fc14.x86_64

Ставим с отключением проверки зависимосей:

rpm -Uhv --nodeps kernel-2.6.35.6-50.fc14.x86_64.rpm
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
Preparing... ########################################### [100%]
1:kernel ########################################### [100%]
[: 5: unknown: unexpected operator

Итак, вуаля, бинарик и конфиг ядра от Fedora упали в /boot:

test:/usr/src# ls -al /boot/vmlinuz-2.6.35.6-50.fc14.x86_64
-rwxr-xr-x 1 root root 3.7M Nov 2 05:21 /boot/vmlinuz-2.6.35.6-50.fc14.x86_64
test:/usr/src# ls -al /boot/config-2.6.35.6-50.fc14.x86_64
-rw-r--r-- 1 root root 108K Nov 2 05:21 /boot/config-2.6.35.6-50.fc14.x86_64

Но initrd не был сгенерирован и ядро не было добавлено в /boot/grub/grub.cfg.

Пробуем собрать initrd для всех ядер пачкой:

depmod -a 2.6.35.6-50.fc14.x86_64 # вроде, это не требуется
update-initramfs -v -u -k 2.6.35.6-50.fc14.x86_64 -t

После этого у нас появляется увесистый initrd:

ls -la /boot/initrd.img-2.6.35.6-50.fc14.x86_64
-rw-r--r-- 1 root root 9.5M Nov 5 17:34 /boot/initrd.img-2.6.35.6-50.fc14.x86_64

Теперь обновляем конфиг grub2:

update-grub

Теперь выбираем Fedora ядро стандартным:

vi /boot/grub/grub.cfg

Это делается директивой:

set default="4"

После этого ребутаем машину в надежде, что нигде не накосячили:

shutdown -r now

Мда, у меня не поднялось, жду квм :) Кстати, чуть выше rpm нам намекал, что там ставить не нужно и чтобы мы юзали alien.

Вариант для Lenny

Ставим на Lenny RPM 4.8: так

Вариант распаковки src rpm:

cd /usr/src
mkdir fedorakernel
cd fedorakernel
wget http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.6/50.fc14/src/kernel-2.6.35.6-50.fc14.src.rpm
/opt/rpm48/bin/rpm2cpio kernel-2.6.35.6-50.fc14.src.rpm | cpio -idmuv --no-absolute-filenames

Как распаковать rpm пакет?

rpm2cpio package.rpm | cpio -idmuv --no-absolute-filenames

Источник: http://www.opennet.ru/base/sys/rpm2cpio.txt.html

RoundCube появился в репах Дебияна :)

Ура! http://packages.debian.org/squeeze/roundcube

Крайне интересным образом ISPManager выключает базы данных

select * from mysql.user where User = 'someuser';
| dsbl_localhost | someuser | *q1wqeqweqwe | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | | | | | 0 | 0 | 0 | 0 |

То есть, вместо localhost клиенту прописывается Host dsbl_localhost, чтобы он ну никак не мог получить доступ, что же, годный метод. Поиск по интернетам также результатов не дал, видимо, "красивых" решений этой проблемы не существует. Вот даже фич риквест в баг-трекере MySQL: http://bugs.mysql.com/bug.php?id=9736

Thursday, 4 November 2010

Супер быстрая разработка веб-приложений посредством ModelBaker

http://www.widgetpress.com/modelbaker

Wednesday, 3 November 2010

ssmtp - отправка почты без установленного почтовика

Есть вот такая штучка: http://linux.die.net/man/8/ssmtp

Пока не юзал, но многие использовали, нужно попробовать :)

Почему могут не совпадать показания df и du -sh / ?

Имеем вот такую картину:

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/simfs 16G 16G 115M 100% /
tmpfs 5.9G 0 5.9G 0% /lib/init/rw
tmpfs 5.9G 0 5.9G 0% /dev/shm

du -sh /
du: cannot access `/proc/23728/task/23728/fd/4': No such file or directory
du: cannot access `/proc/23728/fd/4': No such file or directory
5.2G /

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

Вкратце объясню как так получилось - на сервере были крупные файлы (логи) и они были открыты в некоторых программах (например, nginx и apache). Эти файлы были удалены из системы посредством команды rm, но так как дескрипторы были открыты, данные, разумеется не были удалены (дабы не поломать программы) и хранились до того, пока программа их не "отпустит", но самих ссылок на файлы уже не существовало и du -sh их, разумеется, не видела и не учитывала в отличие от системы квот ядра, которая отлично понимала ситуацию. После перезаупска программ (в данном случае nginx и apache) файлы были отпущены и df -h начал показывать корректные значения.

Итого, после перезпуска демонов имеем корректные показания:

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/simfs 16G 5.2G 11G 34% /
tmpfs 5.9G 0 5.9G 0% /lib/init/rw
tmpfs 5.9G 0 5.9G 0% /dev/shm

Дабы не искать, какой именно демон использует файл, можно просто перезапустить машину / VPS.

Обладает ли Python 2.6 обратной совместимостью с 2.5

Ага, обладает: http://regebro.wordpress.com/2010/02/12/yes-python-2-6-is-backwards-compatible/

Но полный список изменений я не осилил, уж очень он серьезный.

Monday, 1 November 2010

mod_fcgid +eAccelerator + SHM

Как бы это глупо ни звучало, но при использовании eAccelerator в режиме PHP FastCGI он создает блок shm памяти для КАЖДОГО рабочего процесса PHP. То есть, если Вы ставитие лимит в 64 мегабайта кэша, то будет выделено дополнительно N*64мб памяти. Жуть не правда ли? Также, очевидно, все скрипты перекомпилируются заново при запуске очередного рабочего процесса, что сводит весь профит на нет.

А вот пруфлинк в баг-трекере eAccelerator: http://eaccelerator.net/ticket/3

На практике же все именно так и есть, имеем 3 рабочих процесса пользователя v001001:

ps aux | grep v001001
v001001 20588 0.2 0.2 336936 69056 ? S 00:33 0:15 /usr/bin/php5-cgi php
root 22492 0.0 0.0 87884 800 pts/2 S+ 02:32 0:00 grep v001001
v001001 24284 0.4 0.2 335060 63152 ? S 00:49 0:30 /usr/bin/php5-cgi php
v001001 24285 0.0 0.2 336712 57952 ? S 00:49 0:05 /usr/bin/php5-cgi php

И смотрим использование SHM памяти:

ipcs -m | grep v001001
0x00000000 266010721 v001001 600 33554432 1 dest
0x00000000 259981492 v001001 600 33554432 1 dest
0x00000000 266043689 v001001 600 33554432 1 dest
0x00000000 1069875720 v001001 600 1048576 0

То есть, 3 по 32 мегабайта. Ну что же, немного... но если у Вас таких процессов сотни 3:

ps aux | grep php5-cgi | wc -l
320

А это ни много ни мало, а целых 9 гигабайт забитых мусором. Что же делать, что же делать? Хранить кэш на диске :)

Как выкинуть определенного пользователя из ssh?

Иногда нужно выбросить определенного пользователя из ssh, допустим, на время выполнения тех работ. Есть ряд нестандартных решений (ps aux + kill -9), но оказывается есть вполне стандартное решение задачи.

Итак, имеем двух пользователей root одновременно работающих на сервере (это разные люди):

w
18:08:13 up 17:03, 2 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 xx.xx.xx.xx 18:07 0.00s 0.00s 0.00s w
root pts/1 yy.yy.yy.yy 18:08 9.00s 0.00s 0.00s -bash

Нам нужно выкинуть пользователя с IP yy.yy.yy.yy, смотрим, какой tty (терминал) ему соответствует, это pts/1 и отключаем его:

skill -KILL -t pts/1

Вуаля, мы остались в гордом одиночестве:

w
18:08:36 up 17:03, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 xx.xx.xx.xx 18:07 0.00s 0.00s 0.00s w

А выброшенный пользователь увидел примерно следующее:

Connection to xx.yy.zz.kk closed.

Далее возникает вопрос - как избежать того, чтобы пользователь вошел снова. Можно сделать это вот так, просто сгенерировав новый пароль для пользователя и установив его:

apt-get install -y pwgen # ставим генератор паролей
pwgen 16 1
passwd

После смены еще раз убеждаем, не переподключился ли второй пользователь снова командой:

w

После этого можно смело продолжать работать с машиной не беспокоясь, что кто-либо помешает.

Источник: http://www.cyberciti.biz/tips/howto-linux-kill-and-logout-users.html

Subscribe to: Posts ( Atom )