Заметки сисадмина

amavisd-new в Debian Etch

При обновлении в Debian'овском testing'е ( etch) пакета amavisd-new (стало ver 2.3.3) поменялось конфигурирование оного (без совместимости с предыдущим). Возникла одна проблема (остальные решились изменением новых параметров на старые значения) - перестало добавлять в хедер писем следующих полей: X-Spam-Status, X-Spam-Score и X-Spam-Level, на анализе которых procmail решал - относить письмо к спаму или нет (со складыванием в определенную папку). Решилось прописыванием в /etc/amavis/conf.d/50-user следующего:

 @local_domains_acl = ( "." );        

ЗЫ: Не забываем раскомментировать нужное в /etc/amavis/conf.d/50-user/15-content_filter_mode

Новый Archive signing key

2005 год закончился, а с ним и срок действия старого Archive signing key. Нужно обновляться. Это сделать проще так:

gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F     

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

apt-key list    

За подробностями: http://wiki.debian.org/SecureApt 

Jigdo для Centos4

В рассылке lists.centos.org/pipermail/centos рассказано об использовании jigdo для формирования образов дисков Centos'а.

Попробовал "сделать" dvd'шку, имея cd-образы. Получилось, разве что пришлось выкачать 4 файла (остальное взялось с имеющихся образов): hdstg2.img (13Mb), hdlist(8Mb), hdlist2(21Mb), boot.cat(2Kb)

Тут посмотрел, странно, что он не "зацепил" скачанное с образов. Файлы там есть и они одинаковые. Надо было не монтировать (loop'ом), наверное, а скопировать в каталог и "натравить" на этот каталог.

Почта для удаленного(-ых) офиса - postfix

У вас возникла задача - хранить пользователей в едином хранилище, но некоторые пользователи находятся в удаленных офисах. Как лучше "разрулить" почту?

Мой рецепт - воспользуйтесь transport(5). Есть такая возможность, как:

user@domain transport:nexthop
	Deliver mail for user@domain through transport to nexthop.

, т.е. почта для выбранных пользователей будет пересылаться на указанный сервер.

НО! тут есть один нюанс. В результат поиска transport_maps не должны попасть пользователи данного хоста, иначе получите "зацикливание". Как этого избежать - да очень просто - дополнительной фильтрацией по хосту (мы же знаем, кто-где находится). Раз разговор идет об едином хранилище пользователей - сразу подразумевается ldap. Приведу пример для случая использования класса inetLocalMailRecipient (схема /etc/ldap/schema/misc.schema):

main.cf:
...
transport_maps = ldap:$config_directory/ldap_transport_maps.cf
...

ldap_transport_maps.cf:
...
query_filter = (&(objectclass=inetLocalMailRecipient)(mail=%s)(!(mailHost=host1)))
result_attribute = mailHost
result_filter = smtp:[%s]
...

здесь мы используем условие "not host1", т.е. не этот хост. В конфигурациях других почтовых серверах (удаленных), соответственно будет "не_те_хосты".

sms alerts в системе мониторинга mon

Приведу alert для отправки sms'ок в системе mon. Тот, что есть в contribs мне совершенно не понравился своей неинформативностью. Сразу хочу отметить, что у нас используется gnokii и телефон Nokia3100.

Собственно сам sms.alert:

#!/usr/bin/perl
use Getopt::Std;
getopts ("s:g:h:t:l:u");
$summary=<STDIN>;
chomp $summary;
$ALERT = $ENV{"MON_ALERTTYPE"} || "UNKNOWN ALERT";
$t = localtime($opt_t);
($wday,$mon,$day,$tm) = split (/\s+/, $t);
my $alerttext = "$ALERT : $mon $day $tm $opt_g/$opt_s $summary";
foreach $number (@ARGV) {
system("echo `date` $number $alerttext >> /var/log/mon/sms.alert.log");
open (SMS, "| /usr/bin/gnokii --sendsms $number") || die "could not open pipe to sms: $!\n";
print SMS "$alerttext";
close (SMS);
sleep 2;
}

"Заморозка" пакета в Debian Sarge

Для того, чтобы при общих обновлениях (dist-upgrade) некоторые пакеты не были бы обновлены (обновление только при явном указании) их нужно "заморозить", т.е. присвоить им статус hold. Делается это так:

echo "имя_пакета hold" | dpkg --set-selections

вернуть обратно статус можно так:

echo "имя_пакета install" | dpkg --set-selections

nvidia в Debian Sarge

Вы стали счасливым обладателем дисков в Debain Sarge, но тут же замечаете, что на носителях отсутствуют Nvidia'вские дрова. Ну придется вам узнать слудеющее: Указанный софт относится к классу несвободного и "обитает" в секции non-free, которой на cd/dvd дисках нет.

Предварительная подготовка:

Как поступить? Очень просто - скопировать с официального ftp или с одного из зеркал. По следующему пути: debian/pool/non-free/n/nvidia-graphics-drivers/ находится все необходимое, в том числе и для сборки модуля ядра. Если у Вас ядро ver. 2.4.27 (Sarge'вское) - тут: debian/pool/non-free/n/nvidia-modules-i386/ уже есть собранные модули. Не забудьте также и пакет nvidia-kernel-common - обитает по следующему пути debian/pool/contrib/n/nvidia-kernel-common/. С этим пакетом, вернее со всем nvidia иногда твориться нечто странное. Он то попадает в testing (Debian Sarge), то опять возвращается в unstable. Вообщем проследите, чтоб версия nvidia-kernel-common совпадала с nvidia-graphics-drivers.

Вообщем мы скопировали себе пакеты (указанные версии были на момент написания):

• nvidia-kernel-common_1.0.7167-1_all.deb
• nvidia-glx_1.0.7167-1_i386.deb
• nvidia-kernel-source_1.0.7167-1_i386.deb

Сборка модуля ядра:

Сборка модулей ядра в Debian - процедура стандартная и отработанная, но я до сих пор не могу понять, почему в некоторых случаях пишем debian/rules binary-modules, а в некоторых debian/rules binary_modules. Например, если в случае fuse используется первый, то в случае nvidia - второй. Но все равно - опишу пошаговое действие:

# dpkg -i nvidia-kernel-common_1.0.7167-1_all.deb
# dpkg -i nvidia-kernel-source_1.0.7167-1_i386.deb
# cd /usr/src
# tar xfz nvidia-kernel-source.tar.gz
# export KVERS=`uname -r`
# export KSRC=/usr/src/kernel-headers-`uname -r`
# cd modules/nvidia-kernel
# debian/rules binary_modules        

Как обычно, не забываем предварительно проинсталировать kernel-headers для вашего ядра (посмотреть можно командой uname -r), ну и само-собой про kernel-kbuild-2.6-x (я веду разговор про сборку модуля для ядра версии 2.6).

Инсталляция:

Инсталлируем собранный модуль ядра и glx-пакет. У меня это:

# dpkg -i /usr/src/modules/nvidia-kernel-2.6.8-2-686_1.0.7167-1_i386.deb
# dpkg -i nvidia-glx_1.0.7167-1_i386.deb        

Конфигурирование:

Тут ничем не отличается от какого-либо другого дистрибутива. Читайте /usr/share/doc/nvidia-glx/README.gz и правьте настройки XFree в файле /etc/X11/XF86Config-4. Если хотите включить NVIDIA TLS, в файле /etc/default/nvidia-glx установите опцию USE_TLS=1.

PS. В связи с тем, что в Debian Etch изменено именование пакетов с kernel-* на linux-* в вышеописанном нужно это учитывать.

fuse в Debian Sarge

Странно, что в /usr/share/doc/fuse-source/README.Debian нет описания сборки модуля. Хотя это и не представляет проблем для опытного пользователя, для новичка это может быть катастрофой. Восполню указанный пробел.

Исходные данные:
$ uname -r
2.6.8-2-686
kernel-headers 2.6.8-2-686
fuse-source - 2.2.1-1
fuse-utils - 2.2.1-1
module-assistant - 0.8.2

Итак, приступим к сборке модуля:

# apt-get install fuse-source
# cd /usr/src
# tar xfj fuse.tar.bz2
# export KVERS=`uname -r`
# export KSRC=/usr/src/kernel-headers-`uname -r`
# cd modules/fuse/
# debian/rules binary-modules

А сейчас инсталлируем модуль:

# dpkg -i /usr/src/modules/fuse-module-2.6.8-2-686_2.2.1-1_i386.deb

PS. Не забудьте включить себя в группу fuse:

# adduser user fuse

KDE-меню windows-приложений

Исходные данные:
Дистрибутив - Debian Sarge
Локаль - KOI8-R
Десктор - KDE
CrossOver+Microsoft Office

Проблема:
В меню Windows Applications русские буквы отображаются квадратиками.

Решение:
Все очень просто. KDE ждет значения некоторых полей в desktop-файлах (Name, Comment) в UTF-кодировке, а у нас они в KOI8-R. Какой вывод? Правильно - перекодировать. iconv в руки и вперед. А именно, нужно перекодировать все файла (и .directory тоже) в ~/.kde/share/applnk/Windows_Applications/. Для одного файла это будет:

$ iconv --from-code=KOI8-R --to-code=UTF-8 filename.desktop --output=filename.desktop.new
$ mv -f filename.desktop.new filename.desktop

Но мы не идем по простому пути :). Нам же хочется все за раз. Ну... Вообщем скрипт для перекодирования файлов в определенном каталоге оставляю для самостоятельного написания. Подсказка - смотрите в сторону команды find.

PS. Не забудьте про каталог ~/.menu/ - там то, что в меню Debian.

xfonts-terminus в KDE (debian Sarge)

Для возможности использования в konsole шрифтов xfonts-terminus или xfonts-konsole в файл /etc/fonts/fonts.conf внесите следующую строку (понятное дело, что сами шрифты должны быть установлены):

<dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
+<dir>/usr/X11R6/lib/X11/fonts/misc</dir>
<dir>/usr/local/share/fonts</dir>

и затем выполните

# fc-cache

При последнем обновлении fontconfig необходимо еще разрешить использовать bitmaps шрифты. Это лучше сделать через

# dpkg-reconfigure fontconfig

и перезапуска X'ов.

Данный рецепт подойдет не только для KDE, ибо fontconfig используется многими приложениями

CP1251 локаль в Debian'е

Так уж получилось, что средствами dpkg-reconfigure locales cp1251-локаль создать не удасться, поэтому в файл /etc/locale.gen добавляем строку:

ru_RU.CP1251 CP1251

и затем выполняем

# locale-gen