Суть проблемы - Centos 5.6 не видит сетевой чип Atheros Communications AR8121 .
Решение подключаем репозиторий elrepo.org (спасибо, что уже собрали) и ставим модуль ядра kmod-atl1 (kmod-atl1e, kmod-atl2)

Все просто (спасибо, что уже собрали)

Обнаружилась проблема.

На чистой установке ISPManager (Centos 5.7, php-5.1.6) не подключается php.ini пользователя (если php для домена переключен в режим php-cgi).

Решение - костыль, но работает.
Перезаписываем файл php-bin/php (в директории пользователя) на сам бинарный php-cgi.
Т.е.
mv /usr/bin/php-cgi ./php

и не забываем сделать chown.
В таком варианте - конфиг подхватывается

Про багу отписал на форуме ISP - http://forum.ispsystem.com/ru/showthread.php?t=17160 , они ее даже приняли

Но судя по changelog`у ждать придется не меньше месяца , а это напрягает.. бага весьма критичная.

Сервер: Centos 5.7
2 HDD .
На сервере разделы собраны в md (raid-1), один диск вылетел.
Задача: добавить новый диск .
Состояние до добавления такое :

[root@serv]# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 hdc1[0]
521984 blocks [2/1] [U_]

md3 : active raid1 hdc5[0]
20482752 blocks [2/1] [U_]

Делается просто.
1. Ставится новый диск.
2. Копируем таблицу разделов
[root@serv]# sfdisk -d /dev/hdc | sfdisk /dev/hda

3. Проверяем таблицы разделов
[root@serv]# fdisk -l /dev/hdc
Disk /dev/hdc: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 65 522081 fd Linux raid autodetect
/dev/hda2 66 12813 102398310 fd Linux raid autodetect
/dev/hda3 12814 23012 81923467+ fd Linux raid autodetect
/dev/hda4 23013 38913 127724782+ 5 Extended
/dev/hda5 23013 25562 20482843+ fd Linux raid autodetect
/dev/hda6 25563 26084 4192933+ 82 Linux swap / Solaris
/dev/hda7 26085 26594 4096543+ fd Linux raid autodetect
/dev/hda8 26595 38913 98952336 fd Linux raid autodetect

4. Добавляем в md разделы нового диска
[root@serv]# mdadm /dev/md0 - -add /dev/hda8
[root@serv]# mdadm /dev/md1 - -add /dev/hda7
[root@serv]# mdadm /dev/md2 - -add /dev/hda1
[root@serv]# mdadm /dev/md3 - -add /dev/hda5
[root@serv]# mdadm /dev/md4 - -add /dev/hda2
[root@serv]# mdadm /dev/md5 - -add /dev/hda3

5. Смотрим как собирается
[root@serv]# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 hda1[2] hdc1[0]
521984 blocks [2/1] [U_]
resync=DELAYED

md3 : active raid1 hda5[2] hdc5[0]
20482752 blocks [2/1] [U_]
resync=DELAYED

Понадобилось писать в базу все то, что чекает нагиос.
Взял для этого NDO2Utils .

Система где установлен nagios : Centos 5.7 2.6.18-274.3.1.el5
Nagios : 3.3.1

Все встает по инструкции, без проблем.
Но при рестарте сервиса nagios в логе /usr/local/nagios/var/nagios.log вылезает ошибка:

[1283518804] LOG VERSION: 2.0
[1283518804] ndomod: NDOMOD 1.4b9 (10-27-2009) Copyright (c) 2009 Nagios Core Development Team and Community Contributors
[1283518804] ndomod: Could not open data sink! I’ll keep trying, but some output may get lost…

Проверка и перепроверка конфига ndo2db.cfg и ndomod.cfg ничего не дала.

Решение данного бага простое - ndomod хочет видеть свой конфиг ndomod.cfg только в директории /etc/nagios3.

Т.е. создаем директорию , копируем туда конфиг и правим конфиг nagios-а ( nagios.cfg )

broker_module=/usr/local/nagios/bin/ndomod.o config_file=/etc/nagios3/ndomod.cfg

После этого ошибка пропала, в базу полились данные.

Задача - добавить функционал к уже установленному на сервере php5.
Установка из репозитория или из портов - невозможна, так как не совпадают версии.

Решается просто.
В моем случае это Centos 5.4, php5.2.16 (но схема должна работать почти везде).
Нужно добавить поддержку imap (подключить imap.so)

Решение.
Скачиваем исходники php нужной версии и распаковываем их в /root/php-5.2.16
Делаем phpize (тем, что уже уставнолен на сервере - whereis phpize )

serv# cd /root/php-5.2.16/ext/imap
serv# /usr/bin/phpize

Запускаем configure:

serv# ./configure --with-kerberos --with-imap --with-imap-ssl

У меня конфигурация сразу не прошла, доставил нужные зависимости (openssl-devel и т.д.)
В итоге все сконфигурировалось.

serv# make install

И не забываем подключить собранный imap.so:

serv# echo "extension=imap.so" > /etc/php.d/imap.ini

Рестартуем апач и радуемся.

Система FreeBSD 6.2, обновлены порты до последних.
Не ставится libxml2.

Вылетает с ошибкой:

./configure.lineno: 14571: Syntax error: Bad substitution

Решение:

в файле /usr/ports/textproc/libxml2/work/libxml2-2.7.8/configure
закомментировать следующую строку :

WIN32_EXTRA_PYTHON_LIBADD="-L${pythondir}/../../libs -lpython${PYTHON_VERSION//./}"

Найдено здесь

Обновлял мир и ядро на FreeBSD 6.2.
После обновления решил обновить и пакеты.

Не собрался mc, как выяснилось из-за glib
glib вылетал с такой ошибкой:

./de.po:15: keyword “msgctxt” unknown
./de.po:15: parse error
…

Проблема была с gettext, т.е. сначала надо было обновить его.
Потом все взлетело

В рамках некрофилии и прочих извращений
Добавляем поддержку frontpage на web-сервер под управлением hsphere

Все делается на самом сервере:

www# cd /hsphere/pkg
www# fetch http://www.psoft.net/shiv/HS/FBSD6/hsphere-frontpage-5.0_11.tgz
www# pkg_add -f hsphere-frontpage-5.0_11.tgz
www# /usr/local/etc/rc.d/apache.sh restart


Hsphere - 2.6
web-сервер - FreeBSD 6.2

Обнаружил интересный баг.
Есть два сервера PSBM, на каждом крутится по 5-6 VM (виртуальных машин). VM подключены к сети в режиме bridge.
Выяснилось что скорость передачи по tcp между VM-ами на разных серверах не превышает 40-60 кб/c. При этом скорость с внешними ресурсами и на самих серверах была вполне нормальной.

Оказалось, проблема с generic-receive-offload на адаптере, на котором висят бриджи.

Решение достаточно простое.
Во первых, обновляем ethtool, нужна версия больше 6.3

vm# yum info ethtool
...
Installed Packages
Name : ethtool
Arch : x86_64
Version : 6
Release : 4.el5
Size : 149 k
Repo : installed
Summary : Ethernet settings tool for PCI ethernet cards
URL : http://sourceforge.net/projects/gkernel/
License : GPL
Description: This utility allows querying and changing of ethernet card settings, such as speed, port, autonegotiation, and PCI locations.

vm# yum update ethtool

Во вторых, отключаем собственно gro

vm# ethtool -K eth0 gro off

Проверяем

vm# ethtool -k eth0

Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off

И добавляем строку в /etc/rc.local, чтобы при перезагрузке отключалось

vm# echo -e "ethtool -K eth0 gro off" >> /etc/rc.local

Должно помочь

З.ы.
Если при выполнении команды

vm# ethtool -K eth0 gro off

Появится такое - “no offload settings changed” , значит ethtool старой версии.

Надеюсь что Parallels эту багу пофиксят.

Довольно часто , при переносе сайтов с виртуального хостинга на VPS , нужно менять DOC_ROOT в suexec.
Небольшая инструкция для Centos ( но в принципе, на других дистрибутивах все аналогично).

Устанавливаем gcc (если не установлен):

serv# yum install gcc

Сначала узнаем какой версии установленный у нас Apache:

serv# httpd -v
Server version: Apache/2.2.3
Server built: Aug 30 2010 12:32:08

Потом скачиваем исходники нужного apache, например отсюда :
http://archive.apache.org/dist/httpd/

serv# wget http://archive.apache.org/dist/httpd/httpd-2.2.3.tar.gz

Распаковываем и конфигурируем с нужными параметрами (так как нам нужен только suexec - указываем параметры только для suexec):

serv# tar -xzf ./httpd-2.2.3.tar.gz
serv# cd httpd-2.2.3
serv# ./configure --enable-suexec --with-suexec-caller=apache --with-suexec-userdir=cgi-bin --with-suexec-docroot=/home --with-suexec-uidmin=500 --with-suexec-gidmin=500 --with-suexec-logfile=/var/log/httpd/suexec.log

И собираем, !но не устанавливаем! :

serv# make

Дальше смотрим права и владельца на установленный в системе suexec

serv# ls -lah /usr/sbin/suexec
-r-s--x--- 1 root apache 12K Aug 30 2010 /usr/sbin/suexec

Копируем на место старого новый suexec, ставим нужные права и владельца, и проверяем:

serv# cp ./support/suexec /usr/sbin/suexec
serv# chown root:apache /usr/sbin/suexec
serv# chmod 4510 /usr/sbin/suexec

serv# ls -lah /usr/sbin/suexec
-r-s--x--- 1 root apache 23K Mar 9 12:45 /usr/sbin/suexec

Рестартуем apache и все

До модификации:

serv# suexec -V
-D AP_DOC_ROOT="/var/www"
-D AP_GID_MIN=500
-D AP_HTTPD_USER="apache"
-D AP_LOG_EXEC="/var/log/httpd/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=500
-D AP_USERDIR_SUFFIX="cgi-bin"

После:

serv# suexec -V
-D AP_DOC_ROOT="/home"
-D AP_GID_MIN=500
-D AP_HTTPD_USER="apache"
-D AP_LOG_EXEC="/var/log/httpd/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=500
-D AP_USERDIR_SUFFIX="cgi-bin"


Собрал домашний сервер, на Centos.
Все задачи, маршрутизацию на 2 локальные сетки, на пиринговые ресурсы внешние сделал.
IPTV через igmpproxy прикрутил. Интернет раздается провайдером по VPN (l2tp), использовал xl2tpd.

Но вот потребовалось подключаться к VPN-серверу на площадке (mpd5). Как не бился с форвардингом - не работало.

Картина такая - на интерфейсе домашнего сервера , который смотрит во внутреннюю локалку - пакеты GRE уходят, но ответов не приходит.

На интерфейсе сервера на площадке - обратная картина - GRE посылается на домашний сервер, но нет ответа.

На ppp0 - тоже видно что пакеты приходят с площадки, но из локалки ничего нет.

Решение задачи простое - загрузить модуль ядра :

serv# modprobe ip_nat_pptp

и все взлетело

Ну и чтобы загружалось всегда - прописываем модуль здесь - /etc/sysconfig/iptables-config, строка - IPTABLES_MODULES=”ip_conntrack_netbios_ns ip_nat_pptp”

З.ы. VPN соединение создавалось не на домашнем сервере, а на компьютере в домашней локальной сети.

Если вдруг сломалась очередь qmail-a, есть полезная утилита для ее восстановления.
Называется queue-fix, ставится из портов:

serv# cd /usr/ports/mail/queue-fix
serv# make config
serv# make install

После установки переименовываем старую очередь (расположение по дефолту):

serv# mv /var/qmail/queue /var/qmail/queue.old

Останавливаем qmail полностью, чтобы никаких его процессов не висело в памяти

например так:

serv# /usr/local/etc/rc.d/qmail.sh stop

и фиксим очередь :

serv# /var/qmail/bin/queue-fix -i /var/qmail/queue

Запускаем qmail

serv# /usr/local/etc/rc.d/qmail.sh start

должно заработать.

Если не заработало - надо проверять.

У меня например, на qmail был наложен патч BIG TODO.
Поэтому при установке queue-fix этот патч также надо использовать (make config).

Посмотреть с какими патчами был собран qmail (если он собирался из портов конечно) можно, например, так:

serv# cat /var/db/ports/qmail/options

Как-то так..

Собственно все просто.
Для поддержки режима bridge пересобираем ядро с поддержкой девайса:

device if_bridge

и опциями для фильтрации трафика (на базе ipfw):

options IPFIREWALL
options IPFIREWALL_DEFAULT_TO_ACCEPT

В файл /etc/sysctl.conf добавляем строки

net.link.bridge.ipfw=1
net.link.bridge.pfil_member=1
net.link.bridge.pfil_bridge=1
net.link.ether.ipfw=1
net.inet.ip.fw.enable=1


В файле /etc/rc.conf поднимаем сам мост (на двух физических интерфейсах fxp0 и em0):

cloned_interfaces="bridge0"
ifconfig_bridge0="addm fxp0 addm em0 up"
ifconfig_fxp0="inet 192.168.1.2 netmask 255.255.255.0 up"
ifconfig_em0="up"


Для доступа по сети на интерфейс fxp0 назначен IP.
В принципе, для этого хорошо было бы использовать отдельный интерфейс, но его нет, так что используем один из имеющихся.

reboot

Здесь можно взять rpm htop для Centos
http://packages.sw.be/htop/

Возникла проблема при запуске сервера виртуализации от Parallels.
Использовал сервер Parallels Server 4 Bare Metal.
Версия установочного диска взята с сайта, 697-5612 (17 декабря 2009).

Сервер просетапился корректно, проблем при установке не возникло.
Но, при первом запуске, сервер не загрузился, повис на моменте запуска сервиса Parallels services. Причем повис так, что не реагировал на Ctrl-Alt-Del, выключился только по кнопке питания.

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

Решение проблемы было найдено опытным путем
Загружаемся в интерактивном режиме (используя кнопку “I”) и отказываемся от запуска “Parallels services“.

Проверям что на сервере доступен интернет.
Обновляем ядро и систему утилитой vzup2date:
# vzup2date

Но это еще не все

Обновление будет проходить в несколько этапов.

При обновлении на сервер будет корректно установлено новое ядро , но в процессе установки обновлений для утилит Parallels сервер опять зависнет (видимо попробует запустить сервис “Parallels services”).

Опять ребутим сервер и в при загрузке не забываем выбрать новое ядро (в grub`e по умолчанию будет стартовать старое).

Снова входим в режим интерактивной загрузки, отказываемся от запуска сервиса ps.

Опять запускаем vzup2date.
И вот теперь обновление завершится корректно.

Правим /boot/grub/grub.conf для загрузки нового ядра и ребутим сервер.

Вообщем то ничего особо страшного, оибки бывают у всех.

Но почему на сайте Parallels выложен кривой дистрибутив, и нигде нет ни слова о подобной проблеме, ни на форуме, ни в разделе помощи - мне непонятно.