FastNetMon

Показаны сообщения с ярлыком CentOS. Показать все сообщения
Показаны сообщения с ярлыком CentOS. Показать все сообщения

воскресенье, 8 августа 2010 г.

Установка Rsync сервера на CentOS Linux

По мотивам статьи http://phpsuxx.blogspot.com/2010/04/rsync.html решил написать мануал по установке rsync сервера и для CentOS.

Ставим xinetd (необходим для запуска rsync сервера):
yum install -y xinetd


Ставим сам rsync:
yum install -y rsync


Открываем конфиг rsync для xinetd:
vi /etc/xinetd.d/rsync


И заменяем в конфиге:
disable = yes

на
disable = no


Применяем настройки xinetd:
/etc/init.d/xinetd restart


Добавляем xinetd в автозапуск:

chkconfig xinetd on


Убеждаемся, что теперь xinetd слушает порт rsync:

netstat -lnpt | grep 873
tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 7721/xinetd


Далеее создаем конфиг /etc/rsyncd.conf по аналогии с мануалом http://phpsuxx.blogspot.com/2010/04/rsync.html, но указываем немного другие имена групп:

uid = nobody
gid = nobody


После чего применяем изменения:
/etc/init.d/xinetd restart


Все, настройка закончена :) Базовые операции с rsync можете просмотреть в статье, ссылку на которую я привел выше.

Источник: http://am3n.profusehost.net/index.php?id=70

четверг, 24 июня 2010 г.

e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang

Вот вылезла такая радость на машинке сильно нагруженной по сети:


[399393.714927] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[399393.714929] Tx Queue <0>
[399393.714930] TDH
[399393.714931] TDT <91>
[399393.714932] next_to_use <91>
[399393.714933] next_to_clean
[399393.714934] buffer_info[next_to_clean]
[399393.714935] time_stamp <105f49deb>
[399393.714936] next_to_watch
[399393.714937] jiffies <105f49f85>
[399393.714938] next_to_watch.status <0>
[399395.715956] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[399395.715957] Tx Queue <0>
[399395.715958] TDH
[399395.715958] TDT <91>
[399395.715959] next_to_use <91>
[399395.715959] next_to_clean
[399395.715960] buffer_info[next_to_clean]
[399395.715960] time_stamp <105f49deb>
[399395.715961] next_to_watch
[399395.715961] jiffies <105f4a179>
[399395.715962] next_to_watch.status <0>
[399397.709166] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[399397.709167] Tx Queue <0>
[399397.709168] TDH
[399397.709168] TDT <91>
[399397.709169] next_to_use <91>
[399397.709169] next_to_clean
[399397.709170] buffer_info[next_to_clean]
[399397.709170] time_stamp <105f49deb>
[399397.709171] next_to_watch
[399397.709171] jiffies <105f4a36d>
[399397.709172] next_to_watch.status <0>
[399399.706064] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[399399.706065] Tx Queue <0>
[399399.706066] TDH
[399399.706066] TDT <91>
[399399.706066] next_to_use <91>
[399399.706067] next_to_clean
[399399.706067] buffer_info[next_to_clean]
[399399.706068] time_stamp <105f49deb>
[399399.706068] next_to_watch
[399399.706069] jiffies <105f4a561>
[399399.706069] next_to_watch.status <0>
[399400.704517] ------------[ cut here ]------------
[399400.704547] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xd2/0x16c()
[399400.704587] Hardware name: MS-7522
[399400.704608] NETDEV WATCHDOG: eth0 (e1000): transmit queue 0 timed out
[399400.704634] Modules linked in: xt_multiport acpi_cpufreq cpufreq_stats cpufreq_powersave cpufreq_userspace cpufreq_conservative ip6table_filter ip6_tables xt_recent xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state xt_owner iptable_filter ip_tables x_tables quota_v2 quota_tree fuse nf_conntrack_ftp nf_conntrack loop snd_pcm snd_timer snd soundcore wmi i2c_i801 snd_page_alloc tpm_tis tpm tpm_bios i2c_core usbhid evdev hid pcspkr button ext3 jbd mbcache dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sd_mod crc_t10dif e1000 uhci_hcd ehci_hcd thermal fan processor thermal_sys raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 md_mod atiixp ahci sata_nv sata_sil sata_via libata via82cxxx ide_core 3w_9xxx 3w_xxxx scsi_mod [last unloaded: scsi_wait_scan]
[399400.705068] Pid: 0, comm: swapper Not tainted 2.6.33.4-fastvps-2-4 #1
[399400.705095] Call Trace:
[399400.705114] [] ? dev_watchdog+0xd2/0x16c
[399400.705146] [] ? dev_watchdog+0xd2/0x16c
[399400.705173] [] ? warn_slowpath_common+0x77/0xa3
[399400.705201] [] ? dev_watchdog+0x0/0x16c
[399400.705227] [] ? warn_slowpath_fmt+0x51/0x59
[399400.705254] [] ? try_to_wake_up+0x248/0x256
[399400.705282] [] ? autoremove_wake_function+0x9/0x2e
[399400.705310] [] ? netif_tx_lock+0x3d/0x69
[399400.705337] [] ? netdev_drivername+0x3b/0x40
[399400.705364] [] ? dev_watchdog+0xd2/0x16c
[399400.705392] [] ? blk_rq_timed_out_timer+0x2a/0x103
[399400.705421] [] ? run_timer_softirq+0x1c4/0x263
[399400.705450] [] ? __do_softirq+0xdd/0x1a2
[399400.705476] [] ? lapic_next_event+0x18/0x1d
[399400.705503] [] ? call_softirq+0x1c/0x30
[399400.705529] [] ? do_softirq+0x3f/0x79
[399400.705555] [] ? irq_exit+0x36/0x76
[399400.705580] [] ? smp_apic_timer_interrupt+0x87/0x95
[399400.705608] [] ? apic_timer_interrupt+0x13/0x20
[399400.705633] [] ? acpi_idle_enter_bm+0x273/0x2a5 [processor]
[399400.705685] [] ? acpi_idle_enter_bm+0x26c/0x2a5 [processor]
[399400.705729] [] ? cpuidle_idle_call+0x94/0xee
[399400.705757] [] ? cpu_idle+0x59/0x91
[399400.705782] ---[ end trace e53d97746b1a3cdf ]---
[399402.758125] e1000: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX



Юзаем фикс аналогичный http://phpsuxx.blogspot.com/2009/11/e1000-centos-netdev-watchdog-eth0.html

Источник: https://bugzilla.redhat.com/show_bug.cgi?id=398921

суббота, 29 мая 2010 г.

Установка Munin на Debian 6 Squeeze

Клиентская часть

Ставим датчика на Debian и набор плагинов мониторинга (они встанут в папку /usr/share/munin/plugins):
apt-get install -y munin-node munin-plugins-extra

Установка датчика на CentOS:
yum install -y munin-node

Запускаем его:
/etc/init.d/munin-node start


Убеждаемся, что процесс запустился:
ps aux | grep munin | grep -v grep
root 31205 0.0 0.0 124348 7100 ? Ss 19:47 0:00 /usr/sbin/munin-node


При этом он биндится на 4949 порт, но в конфиге блокировка на доступ к нему только с 127.0.0.1:
netstat -lnpt | grep muni
tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN 31205/munin-node
Для большей безопасности в случае только локального использования рекомендую его настроить на прослушивание только локального интерфейса:
vim /etc/munin/munin-node.conf 
Внисим там коррективу:
host 127.0.0.1
Применяем:
/etc/init.d//munin-node restart
Серверная часть

Ставим:
apt-get install -y munin


Далее я бы рекомендовал бы открыть конфиг:
vi /etc/munin/munin.conf


И сменить там стандартный путь на более удобный:
htmldir /var/www/munin


После этого оздаем папку и запускаем его вручную:
mkdir -p /var/www/munin
chown munin:munin -R /var/www/munin

su munin -s /bin/bash
/usr/bin/munin-cron
exit


При этом, никакой демон для него не требуется, опрос нод мониторинга производится по крон задачей /etc/cron.d/munin, которая также генерирует графики: /var/www/munin.

Если датчики расположены на удаленных серверах, то их нужно указывать в конфиге явно:
vi /etc/munin/munin.conf

Вот таким образом:
[srv1.domain.ru]
address 46.4.63.77
use_node_name yes

А на датчике в свою очередь нужно явно указать IP мастер сервера мониторинга:

vim /etc/munin/munin-node.conf

Он задается в строке:
allow ^127\.0\.0\.1$

После этого потребуется перезапуск: датчика
/etc/init.d/munin-node restart
Обращаю внимание, что стандартно доступ к графикам munin открыт только для 127.0.0.1 и для удаленного доступа к site.ru/munin нужно добавить свой IP:
vim /etc/apache2/conf.d/munin 

Управление плагинами

С плагинами работать крайне просто - это лишь набор слимлинков из папки /usr/share/munin/plugins в папку /etc/munin/plugins.

Например, удалить мониторинг эксима и лдап:
rm /etc/munin/plugins/exim_mailstats /etc/munin/plugins/slapd_bdb_cache_pages /etc/munin/plugins/slapd_bdb_cache_percent
А вот так можно добавить мониторинг апача (обращаю внимание, что для их работы должен быть включен ExtendedStatus у Апача, а также должен быть установлен пакет libwww-perl):
sudo ln -s /usr/share/munin/plugins/apache_accesses /etc/munin/plugins/apache_accesses
sudo ln -s /usr/share/munin/plugins/apache_volume /etc/munin/plugins/apache_volume
sudo ln -s /usr/share/munin/plugins/apache_processes /etc/munin/plugins/apache_processes

После этого для изменения набора плагинов нужно перезапустить мониторинг-ноду:

/etc/init.d/munin-node restart   


Также вот хорошая инструкция: http://debianworld.ru/articles/ustanovka-i-nastrojka-munin-v-debian-ubuntu/

четверг, 20 мая 2010 г.

CentOS - Device eth0 has different MAC address than expected

Как избавится от этой хрени? Что за сволочь это вопит? Скрипт? Бинарь?

Причем, фишка в том, что это такая сурьезная ошибка и сетка без нее подниматься не будет :)

Update: эту ошибку выдает скрипт:
vi /etc/sysconfig/network-scripts/ifup-eth


В процессе поиска обнаружил, что кроме HWADDR есть еще параметр сети MACADDR, оба они описаны в хелпе:
vi /usr/share/doc/initscripts-8.45.30/sysconfig.txt


Их отличие в том, что HWADDR - информативный параметр и лишь хранит адрес дивайса, а вот MACADDR хранит желаемый MAC адрес дивайса, который будет подсунут сетевой карте при первой возможности. Вместе же их использоваться, разумеется, нельзя.

Насколько я понял скрипт, HWADDR можно безболезненно удалить из конфига, это как раз нейтрализует отказ сети при смене сетевой карты. Но не думаю, что это очень хорошо, так как так или иначе еще ругань будет со стороны udev, который тоже любит сохранять маки и связывать их с именами устройств. Так что, пусть будет, как и было - используем HWADDR как и ранее, только не забываем про него при замене карточек.

Update: вот фикс - http://phpsuxx.blogspot.com/2010/11/kudzu-ifcfg-eth0-ifcfg-eth0bak.html

Источник: http://codeghar.wordpress.com/2008/06/09/set-mac-address/

четверг, 22 апреля 2010 г.

Использование nscd на CentOS / Debian

Имеем тормоза с DNS:

time wget -q -O/dev/null xx.com

real 0m16.113s
user 0m0.003s
sys 0m0.002s

time wget -q -O/dev/null xxx.com

real 0m16.215s
user 0m0.001s
sys 0m0.002s


Ставим nscd, который суперски умеет кэшировать запросы к DNS

CentOS way

yum install -y nscd


Активируем запуск при загрузке:
chkconfig nscd on


Запускаем:
/etc/init.d/nscd start


Debian way

apt-get install -y nscd


Статистику работы nscd можно узнать командой:
nscd -g


Через несколько суток работы nscd на одном из наших хостинг-серверов было получены следующие значения:


nscd -g
nscd configuration:

0 server debug level
4d 17h 21m 20s server runtime
8 current number of threads
32 maximum number of threads
0 number of times clients had to wait
no paranoia mode enabled
3600 restart internal

passwd cache:

yes cache is enabled
yes cache is persistent
yes cache is shared
211 suggested size
216064 total data pool size
18296 used data pool size
600 seconds time to live for positive entries
20 seconds time to live for negative entries
26303 cache hits on positive entries
0 cache hits on negative entries
18186 cache misses on positive entries
36 cache misses on negative entries
59% cache hit rate
190 current number of cached values
542 maximum number of cached values
7 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/passwd for changes

group cache:

yes cache is enabled
yes cache is persistent
yes cache is shared
211 suggested size
216064 total data pool size
17648 used data pool size
3600 seconds time to live for positive entries
60 seconds time to live for negative entries
3283 cache hits on positive entries
0 cache hits on negative entries
4439 cache misses on positive entries
67 cache misses on negative entries
42% cache hit rate
245 current number of cached values
268 maximum number of cached values
8 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/group for changes

hosts cache:

no cache is enabled
yes cache is persistent
yes cache is shared
0 suggested size
0 total data pool size
0 used data pool size
3600 seconds time to live for positive entries
20 seconds time to live for negative entries
0 cache hits on positive entries
0 cache hits on negative entries
0 cache misses on positive entries
0 cache misses on negative entries
0% cache hit rate
0 current number of cached values
0 maximum number of cached values
0 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/hosts for changes

services cache:

yes cache is enabled
yes cache is persistent
yes cache is shared
211 suggested size
216064 total data pool size
1432 used data pool size
28800 seconds time to live for positive entries
20 seconds time to live for negative entries
32 cache hits on positive entries
0 cache hits on negative entries
15 cache misses on positive entries
1876 cache misses on negative entries
1% cache hit rate
9 current number of cached values
26 maximum number of cached values
2 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/services for changes



А вот потребление памяти:
ps aux | grep nscd
root 5138 0.0 0.0 346312 1020 ? Ssl Apr24 0:38 /usr/sbin/nscd


Теперь тестируем скорость работы DNS:
time wget -q -O/dev/null xxx.com

real 0m27.112s
user 0m0.003s
sys 0m0.001s

time wget -q -O/dev/null xxx.com

real 0m0.107s
user 0m0.001s
sys 0m0.001s

time wget -q -O/dev/null xxx.com

real 0m0.106s
user 0m0.001s
sys 0m0.001s

time wget -q -O/dev/null xxx.com

real 0m0.105s
user 0m0.000s
sys 0m0.002s


Теперь если отключить nscd, проблема вернется:

time wget -q -O/dev/null xxx.com

real 0m22.109s
user 0m0.000s
sys 0m0.003s


Важное замечание

nscd умеет кэшировать не только DNS запросы, но и кучу всяких других тяжелых операций, выполняемых из libc, например: getpwnam, getpwuid, getgrnam, getgrgid, gethostbyname (как раз DNS).

Nscd provides caching for accesses of the passwd(5), group(5), and hosts(5)
databases through standard libc interfaces, such as getpwnam(3), getpwuid(3),
getgrnam(3), getgrgid(3), gethostbyname(3), and others.


Причем, не стоит бояться ошибок кэширования, так как он очень умный:
The daemon will try to watch for changes in configuration files appropriate
for each database (e.g. /etc/passwd for the passwd database or /etc/hosts and
/etc/resolv.conf for the hosts database), and flush the cache when these are
changed.


http://kernel.org/doc/man-pages/online/pages/man8/nscd.8.html

error: failed to add iptables rule to allow forwarding to 'virbr0': Invalid argument

virsh net-start default
error: Failed to start network default
error: failed to add iptables rule to allow forwarding to 'virbr0': Invalid argument


Apr 22 09:47:00 CentOS-54-64-minimal kernel: virbr0: starting userspace STP failed, starting kernel STP
Apr 22 09:47:00 CentOS-54-64-minimal avahi-daemon[3500]: Registering new address record for 192.168.122.1 on virbr0.
Apr 22 09:47:00 CentOS-54-64-minimal libvirtd: 09:47:00.348: error : internal error '/sbin/iptables --table filter --insert FORWARD --destination 192.168.122.0/255.255.255.0 --out-interface virbr0 --match state --state ESTABLISHED,RELATED --jump ACCEPT' exited with non-zero status 1 and signal 0: iptables: Unknown error 18446744073709551615
Apr 22 09:47:00 CentOS-54-64-minimal libvirtd: 09:47:00.348: error : failed to add iptables rule to allow forwarding to 'virbr0': Invalid argument
Apr 22 09:47:00 CentOS-54-64-minimal avahi-daemon[3500]: Interface virbr0.IPv4 no longer relevant for mDNS.
Apr 22 09:47:00 CentOS-54-64-minimal avahi-daemon[3500]: Leaving mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
Apr 22 09:47:00 CentOS-54-64-minimal avahi-daemon[3500]: Withdrawing address record for 192.168.122.1 on virbr0.


Ядро 2.6.33.2 и не работает :(((

virt-install ValueError: Virtual network 'default' has not been started.

Фикс:
virsh net-start default

Установка виртуализации KVM на CentOS 5.4+

Действовать мы будем по официальным мануалам от Red Hat: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Virtualization_Guide/index.html и статье "Виртуализация — это просто" LXF 12/125.

Офсайт проекта KVM: http://www.linux-kvm.org/page/Main_Page

Проверяем, можем ли мы на данный сервер поставить KVM

Во-первых, у нас должен быть CentOS / RHEL версий старше 5.4:
cat /etc/redhat-release
CentOS release 5.4 (Final)


Во-вторых, проверяем поддержку процессором аппаратной виртуализации:
egrep 'vmx|svm' --color /proc/cpuinfo


В ответ на это для каждого ядра:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm

Установка требуемого ПО

Ставим сам kvm, модуль ядра:
yum install kvm


Ставим libvirt и его обвязку для Python:

yum install -y libvirt libvirt-python


Ставим утилиту для удобной установки вирт машин:

yum install -y python-virtinst


Запускаем libvirtd:
/etc/init.d/libvirtd start


Убеждаемся, что libcirtd добавился в автозапуск:
chkconfig --list | grep virt
libvirtd 0:off 1:off 2:off 3:on 4:on 5:on 6:off


Установка VPS, создание образа

Для этого поставим CentOS 5.4 в вирт машину, для этого заюзаем утилиту virt-install (вот для того, чтобы понять, как избавиться от "Connected to domain myvps Escape character is ^]" мне пришлось изрядно прогуглить):

virt-install --connect qemu:///system --name mykvmvps --ram 1024 --file /var/lib/libvirt/images/mykvmvps.img --file-size 10 --location http://mirror.yandex.ru/centos/5.4/os/x86_64/ --network network:default --hvm --accelerate -x console=ttyS0


После этого запустится инсталлятор CentOS, где на свое усмотрение ставите машину с требуемыми настройками. В результате же установки конфиг виртуальной машины создастся в папке /etc/libvirt/qemu, а диск в папке /var/lib/libvirt/images.

Управление виртуальными машинами

Для управления VPS на базуе KVM есть две основных утилиты от RedHat: virt-manager (графическое приложение) и virsh. Обе они работают через libvirt (абстрактный относительно типа системы виртуализации API для управления). Разумеется, мой выбор — virsh.

yum group install - установка групп пакетов

У yum есть супер возможность - связки пакетов. То есть вместо установки десятка пакетов для решения задачи, можно установить группу и все требуемые пакеты будут вытянуты на автомате.

Список всех имеющихся стандартных групп можно просмотреть вот так:
yum grouplist


Довольно интересны из них, например, группы: Virtualization, KVM.

Получить информацию о группе и список ее пакетов можно так:
yum groupinfo KVM


Ну и, наконец, установка группы:
yum groupinstall KVM


Из недостатков - ставится куча совершенно ненужных пакетов :(

Сборка ядер с kernel.org в CentOS 5

Ставим зависимости:

yum install -y ncurses-devel gcc make rpm-build redhat-rpm-config


cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.2.tar.bz2
tar -xf linux-2.6.33.2.tar.bz2
cd linux-2.6.33.2


Копируем конфиг от активного ядра и если нужно вносим коррективы:

cp /boot/config-`uname -r` .config


Запускаем конфигуратор:
make menuconfig


Выбираем там следующую опцию (иначе не загрузится он на CentOS):
General setup ---> enable deprecated sysfs features which may confuse old userspace


Создаем папки для сохранения результирующего rpm файла:

mkdir -p /usr/src/redhat/SRPMS
mkdir -p /usr/src/redhat/RPMS/{i386,x86_64}


Стандартный make rpm не собирает initrd автоматически и не добавляет ядро в grub.conf, поэтому надо наложить патчик

vi scripts/package/mkspec


И в самый низ добавляем следующее:
echo "%post"
echo "/sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install "$KERNELRELEASE" || exit \$?"
echo ""

echo "%preun"
echo "/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove "$KERNELRELEASE" || exit \$?"
echo ""


Собираем ядро (заодно контролируем время сборки):
time make rpm


И ставим:

rpm -ihv /usr/src/redhat/RPMS/i386/kernel-2.6.33.2.i386.rpm



Частично основано на: http://highloaded.blogspot.com/2010/04/centos-kernel-2633-build-rpm.html

суббота, 17 апреля 2010 г.

Поддержка виртуализации kvm в RHEL/CentOS 5.4

Начиная с версии 5.4 в RHEL появилась поддержка kvm виртуализации! Причем, без каких-то левых репозиториев и сомнительных мануалов :)

Итак, встречайте, официальный мануал:
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Virtualization_Guide/index.html


Разрешаю обзывать меня ретроградом за такие новости на фоне выхода RHEL 5.5, но все же :) В ближайше время ждите мануал по поднятию виртуалки на базе KVM по CentOS 5.4 x86_64.

четверг, 15 апреля 2010 г.

Error: database disk image is malformed

yum upgrade
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons: centos.intergenia.de
* base: centos.copahost.com
* extras: centos.copahost.com
* updates: centos.copahost.com
Error: database disk image is malformed


Фикс очень прост:
yum clean all

CentOS и CRON

На одном из CentOS серверов от FastVPS заметил отсутствие CRON в принципе, что меня довольно удивило. И ведь правда - не было.

Пришлось поставить вручную:
yum install -y vixie-cron


И запустить:
/etc/init.d/crond start


В автозагрузку же он попал без моего вмешательства :)

суббота, 3 апреля 2010 г.

Как заставить httpd на CentOS принимать .htaccess в папке /var/www/html?

Открываем конфиг:
vi /etc/httpd/conf/httpd.conf


Ищем там блок Directory "/var/www/html" и внутри него заменяем:
AllowOverride None


на


AllowOverride All


Применяем изменения:
/etc/init.d/httpd restart

вторник, 30 марта 2010 г.

Установка Subversion сервера на CentOS 5

Создаем репозиторий

Ставим пакеты:
yum install -y subversion


У Subversion сервера есть два типа хранилища fsfs (рекомендуется) и bdb. Если желаете их сравнить, вот ссылочка: http://svnbook.red-bean.com/en/1.1/ch05.html#svn-ch-5-sect-1.3 (по мне - почти однозначно побеждает fsfs).

Создаем папку для репозиториев:

mkdir /var/spool/svn


Создаем репозиторий:

svnadmin create /var/spool/svn/myrepo


Переходим в папку репозитория:

cd /var/spool/svn/myrepo


Созданный репозиторий имеет вот такую структуру:
conf dav db format hooks locks README.txt


Теперь нам необходимо предоставить доступ к репозиторию по сети.

Вариантов подключения к SVN репозиторию существует великое множество (аналогичный список можете просмотреть по команде svn --version):

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme


Мне более всего нравится вариант WebDAV / https (безопасность и удобная работа с сервером), его мы и будем использовать.

Ставим Apache Dav и поддержку SSL (ога, безопасность рулит всегда):
yum install -y httpd mod_dav_svn mod_ssl


Аактивируем запуск Апача при загрузке системы и запускаем его:
chkconfig httpd on
/etc/init.d/httpd start


Убеждаемся, что все необходимые модули успешно подключились к Апачу:

apachectl -M 2>&1 | grep dav
dav_module (shared)
dav_fs_module (shared)
dav_svn_module (shared)


а также проверяем, подключился ли SSL:

apachectl -M 2>&1 | grep ssl
ssl_module (shared)


Так как все операции с репозиторием теперь будут производиться от имени Apache, то необходимо его сделать владельцем файлов нашего репозитория:
chown -R apache.apache /var/spool/svn/myrepo/


Теперь необходимо показать Апачу, где находится наш репозиторий:
vi /etc/httpd/conf.d/subversion.conf


Добавляем там внизу следующее:
<Location /myrepo>
DAV svn
SVNPath /var/spool/svn/myrepo

# Require SSL connection for password protection.
SSLRequireSSL

AuthType Basic
AuthName "Authorization Realm"
AuthUserFile /var/spool/svn/myrepo/conf/htpasswd
Require valid-user
</Location>


Создаем файл паролей с одним пользователем:

htpasswd -c /var/spool/svn/myrepo/conf/htpasswd nrg
New password:
Re-type new password:
Adding password for user nrg


Для добавления последующих пользователей используйте вот такую команду (просто ключ -c опускается):

htpasswd /var/spool/svn/myrepo/conf/htpasswd nrg2


Применяем настройки:

/etc/init.d/httpd restart


Пробуем открыть репозиторий по незащищенному соединению: http://domain.ru/myrepo и в ответ должны получить "You don't have permission to access" - это правильное поведение (в логах оно сопровождается следующими записями: "access to /var/www/html/myrepo failed, reason: SSL connection required"). После этого пробуем подключиться по httpS: https://domain.ru/myrepo и в ответ мы должны получить радостное "Revision 0: /", это повествует о том, что все рабоатет отлично и мы получили доступ к нашему репозиторию посредством WEB_DAV и SSL.

Теперь пробуем подключиться из SVN клиента:
svn co https://domain.ru/myrepo
Error validating server certificate for 'https://domain.ru:443':
....
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Authentication realm: Authorization Realm
Password for 'nrg':
Checked out revision 0.

Сразу следом стоит создать папку trunk:
svn mkdir trunk
svn ci -m 'create trunk'

Вот и все — у Вас есть собственный, супер защищенный, доступный из любой точки мира SVN репозиторий!

Основано на: http://wiki.centos.org/HowTos/Subversion

Subversion: CentOS vs Debian - где он новее?

Debian: 1.5.1dfsg1-4
CentOS: 1.4.2


Побеждает Debian :)

Хотя в свете того, что на моем Маке Subversion старее динозавров это совершенно не важно, так что сделаем репо на CentOS :)

svn --version
svn, version 1.4.4 (r25188)

Создание собственного репозитория для CentOS

Ставим служебный софт:
yum install -y createrepo


Создаем папку для хранения пакетов:

mkdir -p /var/www/html/centos_repository
cd /var/www/html/centos_repository


Теперь необходимо положить тестовый пакет в наше репозиторий:
wget http://fastvps.googlecode.com/files/mpt-status-1.2.0_RC7-3.i386.rpm


Запускаем генерацию метаданных репозитория:
createrepo .


После этого будет сгенерирована служебная папка repodata с данными о всех наших пакетах:

./mpt-status-1.2.0_RC7-3.i386.rpm
./repodata
./repodata/repomd.xml
./repodata/other.xml.gz
./repodata/filelists.xml.gz
./repodata/primary.xml.gz


Теперь нам необходимо настроить Apache, чтобы указанная папка была полностью доступна по протоколу HTTP, это осильте сами, пожалуйста.

В итоге у нас получится веб-страница http://repo.domain.ru/centos_repository с одним файлом mpt-status-1.2.0_RC7-3.i386.rpm и папкой repodata, но "правильные" репозитории выглядят немного иначе: http://mirror.yandex.ru/epel/5/

То есть внутри папки репозитория создается папка 5, соответствующая версии дистрибутива, далее создаются подпапки под требуемые архитектуры i386, x86_64 или даже SRPMS, а уже внутри них располагаются rpm пакеты и папка repodata. Если так делают сильные мира сего, то и мы поступим аналогично, чтобы не получить помойки с пакетами (например, такой как у OpenVZ репозитория - http://download.openvz.org/kernel/branches/rhel5-2.6.18/current/ и как следствие этой "помойки" при установке пакетов из их репозитория приходится явно указывать его (пакета) платформу, то есть вместо "package" приходится писать "package.x86_64", что крайне неудобно).

Переделываем на "как правильно":
rm -rf /var/www/html/centos_repository
mkdir /var/www/html/centos_repository
cd /var/www/html/centos_repository
mkdir 5
cd 5
mkdir {i386,x86_64,SRPMS}
cd x86_64
wget http://fastvps.googlecode.com/files/mpt-status-1.2.0_RC7-3.i386.rpm
cd ..


Создаем repodata:

createrepo i386

Saving Primary metadata
Saving file lists metadata
Saving other metadata

createrepo x86_64/
1/1 - mpt-status-1.2.0_RC7-3.i386.rpm
Saving Primary metadata
Saving file lists metadata
Saving other metadata

createrepo SRPMS/

Saving Primary metadata
Saving file lists metadata
Saving other metadata


Если же в процессе эксплуатации репозитория Вы планируете добавлять новые пакеты, то используйте другой синтаксис createrepo:
createrepo --update x86_64
createrepo --update i386
createrepo --update SRPMS


Теперь немного автоматизации для удобного апдейта репо:
vi /var/www/html/centos_repository/5/Makefile


Со следующим контентом:
update:
createrepo --update x86_64
createrepo --update i386
createrepo --update SRPMS


Теперь обновление репозториев при добавлении новых пакетов можно делать вот так:

make -C /var/www/html/centos_repository/5 update


Теперь наш репозиторий необходимо подключить к клиентской машинке (у меня она 64 битная, и с 32 битной мой пример работать не будет), создаем файл описание репозитория:
vi /etc/yum.repos.d/myrepo-centos.repo


Со следующим содержанием:

[myrepo-centos]
name=My Personal Yum Repo
baseurl=http://domain.ru/centos_repository/5/$basearch
enabled=1
# not secure
gpgcheck=0


Теперь запускаем yum и убеждаемся, что не выдано никаких ошибок в отношении нашего репозитория:
yum update


Получаем информацию о тестовом пакете в нашем репозитории:

yum info mpt-status
Loaded plugins: fastestmirror, versionlock
Loading mirror speeds from cached hostfile
* addons: ftp.plusline.de
* base: centos.copahost.com
* epel: mirror.andreas-mueller.com
* extras: ftp.plusline.de
* openvz-kernel-rhel5: openvz.copahost.com
* openvz-utils: openvz.copahost.com
* updates: centos.copahost.com
Reading version lock configuration
Available Packages
Name : mpt-status
Arch : i386
Version : 1.2.0_RC7
Release : 3
Size : 27 k
Repo : myrepo-centos
Summary : MPT Fusion raid inquiry tool
URL : http://www.drugphish.ch/~ratz/mpt-status/
License : GPL
Description: mpt-status give informations about raid status for LSI Fusion controllers.
: This is quite a modified version to the original mpt-status-1.0 package.


Ставим его (собственно, ради этого все и затевалось):

yum install -y mpt-status


Ну вот и все :)

Добавление новых пакетов в репозиторий

Просто кладем новые rpm в папку, соответствующую архитектуре и после этого делаем --update, как указано выше. Как результат увидим следующее:
make
createrepo --update x86_64
2/2 - vzprocps-2.0.11-6.13.swsoft.i386.rpm
Saving Primary metadata
Saving file lists metadata
Saving other metadata
createrepo --update i386
2/2 - vzprocps-2.0.11-6.13.swsoft.i386.rpm
Saving Primary metadata
Saving file lists metadata
Saving other metadata
createrepo --update SRPMS

Saving Primary metadata
Saving file lists metadata
Saving other metadata

Источник: http://blog.kagesenshi.org/2007/01/howto-creating-your-own-yum-rpm.html