Многопользовательский VNC-сервер на RHEL5

Из коробки в RHEL5 (опыты проводились на Oracle Linux 5.8) для запуска Xvnc предназначена служба vncserver, предполагающая жескую привязку запущенных процессов к пользователям и портам (ея настройки находятся в /etc/sysconfig/vncservers). В данной статье описано более интересеное поведение: Xvnc принимает множественные соединения на одном порту и выводит окно авторизации gdm. При такой конфигурации служба vncserver должна быть остановлена. Далее: добавляем порт vnc в /etc/services:

vnc        5900/tcp

Создаем /etc/xinetd.d/vncserver:

service vnc
{
disable = no
protocol = tcp
socket_type = stream
server = /usr/bin/Xvnc
wait = no
user = nobody
server_args = -inetd –query localhost –once –geometry 1024x768 \
 –depth 16 -SecurityTypes=None
}
(строки, разделенные знаком \, на самом деле составляют одну строку)

И добаляем в /etc/gdm/custom.conf (если их там еще нет) следующие строки:

[security]
AllowRemoteRoot=true
DisallowTCP=false

[xdmcp]
Enable=true
MaxSessions=30

После перезапуска xinetd и gdm должна появиться возможность подсоединиться vnc-клиентом (например, remmina) на порт 5900.
В качестве неизбежных рюшечек избавимся от  гнома по умолчанию (ибо сервер у нас не совсем резиновый). В файл /etc/sysconfig/desktop пишем:

PREFERRED=/opt/bin/xsession.sh

Ну а сам /opt/bin/xsession.sh предоставляем фантазии читателя. Мой минималисткий вариант таков (mwm ставится из пакета openmotif):

#!/bin/sh
vncconfig -iconic &
xclock -bg black -fg green -digital -strftime '%H:%M:%S %d.%m.%y' \
 -geometry -0-0 -update 1 &
xterm -bg black -fg grey -geometry +0+0 &
exec mwm

В комментариях здесь нуждается только вторая строка - без нее не будет работать клипбоард.

Pacemaker за 5 минут

Так уж получилось, что и старое, и новое издание Clusters from Scratch описывают слегка не ту конфигурацию, что используется на наших серверах. Поэтому пишу сам себе HOWTO. Задача: поднять двухнодовый кластер с httpd. Платформой служит Oracle Linux 6.3 из коробки.
Предварительные необходимые шаги (без детализации):

1. отключаем selinux;
2. разрешаем весь трафик через интерфейсы, по которым узлы будут общаться друг с другом;
3. убеждаемся, что httpd не запускается при загрузке - и кластерный ip никем не используется;
4. создаем одинаковый беспарольный RSA-ключ для рута на обеих узлах и взаимно авторизуем его;
5. устанавливаем pacemaker и corosync через yum.

А теперь - за дело. /etc/corosync/corosync.conf.example содержит почти все нужное. Копируем его без суффикса example, заменяем  bindnetaddr на реальный (это адрес сети, а не хоста - он будет одинаковым на обеих узлах) и добавляем в конец секцию запуска pacemaker:
service {
        name: pacemaker
        ver: 0
}
После этого запускаем corosync:

# service corosync start

И команда

# crm status

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

# chkconfig corosync on

Все остальное, что мы собираемся запускать в кластере, будет стартовать из-под него. Если первоначальные настройки должны быть сделаны симметрично на обеих узлах, то дальнейшие crm-команды выполняются только на одном из узлов.
Наша примитивная конфигурация требует слегка поменять стандартные настройки кластера. Отключаем STONITH:

# crm configure property stonith-enabled=false

И кворум (иначе в двухнодовом кластере вместе с одним из узлов умрут все сервисы):

# crm configure property no-quorum-policy=ignore

Теперь можно добавлять ресурсы. Переходящий IP-адрес:

# crm configure primitive ip0 ocf:heartbeat:IPaddr2 \
    params ip=10.1.1.251 nic=eth1 cidr_netmask=32 \
    op monitor interval=10s

И веб-сервер:

# crm configure primitive www0 lsb:/etc/init.d/httpd \
    op monitor interval=30s

т.к. наши два ресурса логически связаны (и по смыслу должны запускаться на одном и том же узле), то сгруппируем их: 

# crm configure group g0 ip0 www0

И установим порядок запуска (веб-сервер всегда после адреса):

# crm configure order ip-www inf: ip0 www0

Далее следует сводка простейших команд администрирования кластера.

Если понадобилось вывести узел из кластера (например для апргрейда):

# crm node standby

(Эта и следующая команды выполняются на том узле, которым мы манипулируем - либо третьим аргументом должно быть имя узла). Возвращение в кластер после окончания обслуживания:

# crm node online

Перемещение группы ресурсов на другой узел кластера:

# crm resource move g0

После того, как перемещение закончится, надо выполнить:

# crm resource unmove g0

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

Посмотреть на работающий кластер в реальном времени можно командой

# crm_mon

Нуждающиеся в более серьезной документации, чем эта, найдут ее на ClusterLabs.

Заработавший rp_filter в CentOS 6.3

Продолжающиеся разборки со свежеустановленной CentOS 6.3 принесли новые неожиданные результаты. Примерная конфигурация такая:
Компьютер администратора имеет ip-адрес 10.1.1.101 в сети 10.1.1.0/24;
Сервер (как раз CentOS 6.3 x86_64) имеет интерфейс eth0 адресом 10.1.1.201 в той же сети и eth1 адресом 10.1.2.201 в сети 10.1.2.0/24.
Маршрутизация между этими сетями настроена, с роутера все три адреса успешно пингуются.
С компьютера администратора пингуется 10.1.1.201, но никак не пингуется 10.1.2.201.
В принципе такое поведение нельзя назвать неправильным - на интерфейсе eth1 оказывается пакет, который по всем правилам должен был прийти на eth0 - и ответа на него не посылается. Другое дело, что за прошлую жизнь админ так привык к неправильному поведению, что правильное ему кажется неудобным. Поиск по настройкам sysctl достаточно скоро находит виновного:
net.ipv4.conf.eth1.rp_filter = 1
Из документа http://linuxgazette.net/issue77/lechnyr.html как раз и явствует что:

The rp_filter can reject incoming packets if their source address doesn't match the network interface that they're arriving on, which helps to prevent IP spoofing.

Установка:
net.ipv4.conf.eth1.rp_filter = 0
приводит к тому, что желанный пинг появляется.
А напоследок - как всегда - самое смешное. В CentOS 5-ой ветки, на которых автор этих строк собственно и успел пристраститься к "неправильным" пингам, установки net.ipv4.conf.*.rp_filter по умолчанию - точно такие же, как и в 6.3. Только не вызывают они заявленного поведения. Одно из двух - либо давно объявленную фичу наконец-то заставили работать, либо где-то таится еще какая-то настройка, которая говорит системе, реагировать ей на rp_filter - или нет.

Неуловимый LANG в CentOS 6.3

При установке CentOS 6.3 с образа minimal меня удивили сообщения на русском языке (при установке был явно выбран английский). Переменная LANG действительно содержала ru_RU.UTF-8, но рекурсивный поиск в /etc и $HOME не давал ответа, каким образом подобное значение устанавливается - такой подстроки просто-напросто не было в файлах этих директорий. Проблема выглядела невероятной, пока не был произведен рекурсивный поиск слова LANG. Ответ нашелся в файле /etc/ssh/sshd_config:
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE \\
 LC_MONETARY LC_MESSAGES
(Это одна строка - переноса в оригинальном файле нет)
Т.е. получается, что установки языка передавались на сервер с моего компьютера по ssh. Действительно, если убрать LANG из этой строки, то при следующем входе в систему языком сообщений делается английский.
Следует добавить, что аналогичные настройки имеются и в клиентском файле /etc/ssh/ssh_config:
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE \\
LC_MONETARY LC_MESSAGES
Так что, вероятно, наиболее правильным решением проблемы является как раз изменение SendEnv на том компьютере, откуда производится вход по ssh - а то вдруг другие администраторы сервера захотят видеть русский интерфейс? Хотя - с другой стороны - а что им мешает явно установить LANG в своих профайлах?
Ну а самое смешное заключается в том, что данная строка имеется в /etc/ssh/sshd_config и в более ранних версиях CentOS (например, в 5.3) - но там она почему-то никак на язык консольных сообщений не влияет. 

Как не переходить на зимнее время на серверах

Наконец-то случилось то, на что все разумные люди уже много лет робко надеялись - клоунада с переводом стрелок отменена! Осталось понять, как мы сообщим об этом радостном событии серверам. Итак, задача: 30 октября 2011 навсегда остаться в московском летнем времени. Сервера у меня под CentOS и FreeBSD, потому все последующие упражнения проверялись именно для этих систем.
До сегодняшнего дня я считал, что летнее московское время соответствует времени GMT+4. Ничего подобного! Простые опыты показали, что все как раз наоборот - GMT-4. Убедиться в этом легко с помощью команды zdump:
$ zdump Europe/Moscow
Europe/Moscow  Wed Feb  9 09:48:59 2011 MSK
$ zdump Etc/GMT-3
Etc/GMT-3  Wed Feb  9 09:49:12 2011 GMT-3
$ zdump Etc/GMT+3
Etc/GMT+3  Wed Feb  9 03:49:15 2011 GMT+3
(проверяется -3, а не -4 потому, что у нас с вами пока зимнее время).
Дальше все достаточно просто (одинаково и для Linux и для FreeBSD):
# ln -sf /usr/share/zoneinfo/Etc/GMT-4 /etc/localtime
(если директории /usr/share/zoneinfo и /etc находятся на разных устройствах, то безопаснее будет использовать не ln, а cp).
В CentOS можно еще поправить параметр ZONE в файле /etc/sysconfig/clock, но - судя по коменту в том же файле, это значение на реальную работу системы не влияет.
Потом на каком-нибудь сервачке, который не жалко, можно заранее поставить время без пяти три 30 октября - и убедиться, что с переходом через 3 часа никакого зимнего времени не наступит.

Странное поведение mktime относительно летнего времени

На опыте столкнулся с тем, что результат, возвращаемый функцией mktime(3) не учитывает перехода на зимнее/летнее время (т.е. результаты для "лета" оказываются на час больше, чем нужно). Проверено на linux 2.6.18 и FreeBSD 8.0 с корректно установленной зоной MSK/MSD - так что, вероятно, именно такое странное поведение соответствует спецификации POSIX. Самое смешное в том, что (в полном соответствии с документацией) функция mktime не только возвращает типа значение time_t, но и "нормализует" содержимое переданной в нее по указателю struct timespec, заполняя совершенно корректными (учитывающеми перевод времени) значениями поля tm_isdst, tm_gmtoff и tm_zone. Очевидно, где-то в этом направлении и лежит путь борьбы с этой функцией. Т.е вместо очевидного:

struct timespec ts;

time_t tm = mktime(&ts);

Пишем теперь так:

struct timespec ts;

time_t tm = mktime(&ts) - ts.tm_isdst * 3600;

Эстетам же и забывчивым можно предложить определить вот такой макрос:

#define mktime(t) (mktime(t) - (t)->tm_isdst * 3600)

и использовать mktime, как обычно.

Еще идеи?

ПППингвины over Ethernet

Настраиваем PPPoE на Linux

Сервер

Для опытов использовалась OpenSUSE 11.1
Необходимо поставить следующие RPM: ppp, rp-ppoe и freeradius-client. Про то, как настраивать авторизацию на сервере RADIUS уже написано тут.
Проверить, как работает авторизация можно командой
# radexample
(да, именно с правами root - иначе она не сможет прочесть файл конфигурации, но в этом не признается - и выдаст Authentication FAILURE)
Проверив, что все работает, нужно в файле /etc/radiusclient/radiusclient.conf нужно убрать следующие строки (pppd на них сильно ругается):
radius_deadtime 0
bindaddr *
Если мы уберем эти строки заранее, ничего страшного не случится, но от radexample толку не ждите - она выпадет в кору.
Файл параметров сервера /etc/ppp/pppoe-server-options предельно прост:
+chap
-pap
auth
proxyarp
plugin radius.so
Запускается сервер командной строкой:
# pppoe-server -I eth1 -L 10.11.12.13
(стартовый скрипт для него придется сочинять самим)

1. Первый параметр - интерфейс, на котором ждем подключения клиентов. Он должен быть поднят - иначе pppoe-server не поднимется IP адрес этому интерфейсу может быть как присвоен, так и не присвоен.
2. Второй параметр - адрес, который будет отдаваться клиентам как адрес конца тоннеля (насколько мне удалось выяснить, он может быть как равен адресу нашего интерфейса - если таковой присвоен - так и не равен ему - на работу это не влияет).

Адреса клиента берем с RADUIS, потому в командной строке ничего не указываем.
Для того, чтобы сервер был реально полоезен, нужно разрешить на нем роутинг. В файле /etc/sysctl.conf пишем:
net.ipv4.ip_forward=1
Аналогичная конфигурация работоспособна на CentOS 5.3 и Ubuntu 9.04 (там пакет, содержащий pppoe-server, называется pppoe). Нужно заметить, что эти системы не нуждаются в прятание строк в файле /etc/radiusclient/radiusclient.conf (для CentOS ищется на http://rpmfind.net пакет radiusclient для fc или el, а в убунте есть аналогичный пакет radiusclient1).

Клиент

Опыты проводились на Ubuntu 9.04
Ничего доставлять не надо - все нужное в дистрибутиве уже есть.
Файл /etc/ppp/peers/pppoe:
user "myname"
defaultroute
replacedefaultroute
noauth
noipdefault
plugin rp-pppoe.so eth0
Последний параметр в последней строке - интерфейс, через который будем выходить на сервер. Он должен быть поднят, ip-адрес на нем может как быть, так и не быть.
Файл /etc/ppp/chap-secrets:
"myname" * "mysecret" *
myname и mysecret - это (как вы догадались) наши имя и пароль на RADIUS-сервере.
Соединение запускам командой:
# pppd call pppoe
Если возникли проблемы, добавляем в конфиг сервера и клиента строчку debug - и получаем довольно неплохой уровень отладочных сообщений.
Аналогичная конфигурация работает на Mandriva 2009.1

P.S. в Mandriva 2009.1 pppoe-server не вполне работоспособен - по крайней мере, мне вообще не удалось заставить его отвечать на LCP Request. Судя по всему, проблема заключается в pppd. Лечится сборкой из исходников ppp-2.4.4.XXXX.rpm для FedoraCore (pppoe плагин в него входит), а файлы в /etc/radiusclient копируются из ${RPMROOT}/BUILD/ppp-X.X.X/pppd/plugins/radius/etc (нюансы этой операции описаны в предыдущем посте).

Сервер l2tp на Linux с поддержкой RADIUS авторизации

Про настройку xl2tpd с клиентской стороны я уже писал тут, потому ограничусь только указанием принципиальных различий в конфигурации.
Опыты проводились на CentOS 5.3
Минимально необходимый /etc/xl2tpd/xl2tpd.conf в этом случае выглядит так:
[global]
access control = no
[lns default]
exclusive = no
ip range = 10.0.0.2-10.0.0.254
local ip = 10.0.0.1
require chap = yes
refuse pap = yes
require authentication = yes
pppoptfile = /etc/ppp/options.xl2tpd
Особенно надо обратить внимание на опцию require authentication = yes - без нее к RADIUS-серверу обращений не будет.
Минимально необходимое содержимое файла /etc/ppp/options.xl2tpd такое:
mtu 1410
mru 1410
nodefaultroute
lock
auth
plugin radius.so
plugin radattr.so
Чтобы номально работал radius-plugin к pppd должны сущестововать файлы в директории /etc/radiusclient. Их можно взять либо из SRPM ppp (поддиректория в каталоге BUILD: ppp-X.Y.Z/pppd/plugins/radius/etc) или установить пакет radiusclient.
В этой директории нужно подправить следующее: в файле /etc/radiusclient/servers
добавить строку, содержащую адрес RADIUS-сервера и пароль к нему:
127.0.0.1 mysecret
и тот же сервер указать в файле /etc/radiusclient/radiusclient.conf:
authserver 127.0.0.1
acctserver 127.0.0.1
Если этот файл брался из SRPM, то в нем нужно подправить еще пути к другим файлам конфигуриции клиента - все они почему-то предполагаются в /usr/local/etc/radiusclient

P.S. такой же файл options (только с прибавлением опций: +chap -pap) и те же настройки radiusclient работоспособны и при настройке демона протокола PPTP - pptpd (только он, кажется, уже немножко устарел ;)
Еще один необходимый для него файл /etc/pptpd.conf выглядит и вовсе примитивно:
option /etc/ppp/options.pptpd
localip 10.0.0.1
remoteip 10.0.0.2-254

Обзор команд работы с логическими томами в Linux

Ниже приводится краткая сводка команд по манипулированию логическими томами (Logical Volume) в Linux. Сразу неприятное предупреждение - при использовании логического тома в качестве корневого раздела, раздел /boot должен находиться на отдельном - не логическом (/dev/[hs]d?, /dev/md?) томе. Размер этого тома должен быть небольшим - даже для нескольких ядер вполне достаточно 32 Мб (инсталлятор CentOS зачем-то просит 75 Мб).
В дальнейших примерах предполагается ваяние группы логических томов - имя группы myvg - с именами root и swap. Имена используемых физических томов /dev/sda5, /dev/hdb1 и /dev/md0
Для использования в логических томах физические разделы должны быть проинициализированы:
# pvcreate /dev/sda5 /dev/hdb1 /dev/md0
посмотреть существующие физические тома можно командой:
# pvdisplay
Создадим группу (пока из двух физических томов):
# vgcreate myvg /dev/sda5 /dev/md0
Для использования группу нужно активизировать:
# vgchange -a y myvg
посмотреть существующие группы томов можно командой:
# vgdisplay
Добавить новый физический том можно командой:
# vgextend myvg /dev/hdb1
Удалить неиспользуемый том из группы можно командой:
# vgreduce myvg /dev/hdb1
Если в группе все тома используются, убрать данные с логического тома позволяет команда:
# pvmove /dev/hdb1
Предполаетася, что в группе томов достаточно свободного места для этой операции. Если места недостаточно, то команда должна иметь еще один аргумент - имя тома, куда мы переносим данные.
Если группа томов больше не должна жить, ее можно удалить:
# vgchange -a n myvg
# vgremove myvg
Теперь переходим к самому интересному - созданию разделов.
Создаем зеркалируемый том root размером 1 Gb и незеркалируемый том swap размером 512 Mb:
# lvcreate -n root -m 1 -L 1G myvg
# lvcreate -n swap -L 512M myvg
Создание файловой системы и монтирование осуществляется такими же командами, как для обычного раздела. Имена файлов логического тома: /dev/mapper/myvg-root или /dev/myvg/root
Просмотреть существующие логические тома можно командой:
# lvdisplay
Далее том можно изменять в размере. Вверх:
# lvextend -L +1G myvg/root

(аргумент -L может быть абсолютной величиной - или приращением)

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

# lvextend -l 100%VG myvg/root

И вниз:
# lvreduce -L 1.5G myvg/root
(во втором случае критичных данных на томе рекомендуется не иметь).

Чтобы получить реальную пользу от изменения размера томов нужно уметь менять размер файловых систем. Это делается командами:

Для ext3:

Вверх:
# umount /dev/myvg/root
# lvextend -L +1G myvg/root
# resize2fs /dev/myvg/root
# mount /dev/myvg/root

Вниз:
# umount /dev/myvg/root
# resize2fs /dev/myvg/root 2097152
# lvreduce -L -1G myvg/root
# mount /dev/myvg/root
последняя цифра второй команды - новый размер файловой системы в блоках

Для reiserfs:

Вверх:
# umount /dev/myvg/root
# lvextend -L +1G myvg/root
# resize_reiserfs /dev/myvg/root
# mount /dev/myvg/root

Вниз:
# umount /dev/myvg/root
# resize_reiserfs -s -1G /dev/myvg/root
# lvreduce -L -1G myvg/root
# mount /dev/myvg/root

Для xfs (только вверх):
# xfs_groufs /mnt
(да, прямо на примонтированной fs)

Для jfs:
# mount -o remount,resize /mnt
(тоже на примонтированной)

Если в группе томов есть свободное место, можно создать снимок тома:
# lvcreate -s -L 0.5G -n root_snap myvg/root
(размер может быть не равен размеру тома - очевидно, он должен быть равен объему данных на нем).
Со снимком можно делать все тоже самое, что с томом - только создавать на нем файловую систему едва ли надо...
Если хочется преобразовать обычный том в зеркалируемый, то это можно сделать, имея свободное место, равное размеру тома, на двух носителях (для размещения самого тома - и его копии). Сперва создаем физические тома, добавляем их в группу, а потом:
# lvconvert -m 1 vg1/root
В качестве дополнительных аргументов можно указать имена физических томов, на которых будет размещаться зеркало (если тут есть варианты).
Операция эта достаточно медленная. Зато потом можно высвободить исходный физический том (для тех, кто уже забыл - pvmove + vgreduce).
Ну, и совсем надоевший логический том можно и удалить:
# lvremove vg1/root_snap

Если что-то важное упустил, то можно почитать LVM HOWTO

P.S. т.к. тут упоминались устройства /dev/md?, для памяти приложу чуть-чуть о Software RAID в Linux.
Напр. создать RAID 5 уровня из 3 дисков и одного диска горячей замены:
# mdadm -C /dev/md0 -n 3 -x 1 -l 5 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
Отключить один горячий диск - и подключить новый:
# mdadm /dev/md0 -r /dev/sde1 -a /dev/sdf1
Посмотреть статус RAID:
# mdadm -Q --detail /dev/md0
Здесь нужно добавить еще одно неприятное предупреждение - загрузка с Software RAID - вещь весьма проблематичная (напр. инсталятор CentOS соглашался только на загрузку с RAID1 - что в принципе объяснимо, т.к. в этом случае диски содержат копии друг друга - т.е. можно загрузиться с любого из них). Это лишний повод для выделения /boot в отдельный (не RAID) раздел.
Для того, чтобы Software RAID нормально завелся после загрузки, нужно создать файл /etc/mdadm.conf - в нашем примере - такого вот содержания:
DEVICE /dev/sd[bcde]1
ARRAY /dev/md0 level=5 spares=1 num-devices=3 devices=/dev/sdb1,/dev/sdc1,/dev/sdd1,/dev/sde1

Ручная доработка CentOS 5.2 под дисковый контроллер Fibrochannel QLogic

Собственно проблемы большой нет - CentOS 5.2 из коробки успешно загружается на Blade-сервере IBM с контроллером QLogic QMI2472 - беда в том, что длится загрузка на этом железе примерно 13 (!) минут. Больше половины этого времени занимает device-mapper, вызываемый из /etc/rc.sysinit, - он что-то пытается сделать с дисками массива, недоступными данному хосту. Никаких правильных путей его загасить я не нашел - потому грубо правил сам файл - строку:
if [ -c /dev/mapper/control ]; then
заменил на:
if [ 0 = 1 -a -c /dev/mapper/control ]; then
(или у кого какие еще варинты заведомо невыполнимого условия?) - после этого загрузка явно пошустрела.
Еще одна не очень приятная особенность CentOS - она монтирует файловые системы не по имени устройства, а по LABEL (причем, LABEL - это просто точка монтирования - /, /var и т. д.) Если у нас на контроллере есть диски для нескольких хостов - то как быть? Быть так. Метку правим такой командой:
# tune2fs -L MY-UNIQUE-LABEL /dev/sd??
и потом исправляем метку со стандартной на нашу в файлах /etc/fstab (первый столбец) и /boot/grub/menu.lst (строка kernel аргумент root=LABEL=MY-UNIQUE-LABEL).

Создание интерфейсов VLAN во FreeBSD 7.0 и Mandriva 2008.1

Задача - нужно создать два VLAN интерфейса (для определенности - номера VLAN: 62 и 99) на одной сетевой карте (пусть в Linux она будет eth0, во freebsd - em0). Кособокость обеих способов примерно одинакова, так что дальше нет ни слова пропаганды - просто констатация.

FreeBSD
Пересобираем ядро, добавив в конфиг строку
device vlan
или пишем в /boot/loader.conf
if_vlan_load="YES"
потом пишем в /etc/rc.conf такое:
cloned_interfaces="vlan62 vlan99"
ifconfig_vlan99="inet x.x.x.x netmask y.y.y.y vlan 99 vlandev em0"
ifconfig_vlan62="inet z.z.z.z netmask w.w.w.w vlan 62 vlandev em0"
после перезагрузки должны появиться интерефейсы vlan62 и vlan99

Mandriva
(аналогично все завелось на CentOS 5.2, в инете сообщалось, что та же схема работает и в других redhat-подобных дисрибутивах)
Должен быть установлен пакет, содержащий команду vconfig. В мандриве этот пакет звался vlan-utils и по умолчанию не был установлен - в CentOS 5.2 пакет vconfig стоял по умолчанию - ну там вообще много всего лишнего ;)
Короче говоря, делаем
$ which vconfig
и при отрицательном ответе хватаемся за urpmf (для мандривы) или yum search для CentOS.
Потом создаем файл /etc/sysconfig/network-scripts/ifcfg-eth0.62
в нем пишем такое:
DEVICE=eth0.62
VLAN=yes
BOOTPROTO=static
IPADDR=x.x.x.x
NETMASK=y.y.y.y
ONBOOT=yes
аналогично создаем и файл ifcfg-eth0.99
После команды
# /etc/init.d/network restart
у нас должны появиться интерфейсы eth0.62 и eth0.99
Для других семейств Linux привожу "сырые" команды оболочки (в самом крайнем случае, их можно и вписать в /etc/rc.local). Создание VLAN интерфейса:
# vconfig add eth0 62
удаление: (мне пригодилось и в мандриве ;)
# vconfig rem eth0.62

P.S. интерфейся Linux вида eth0.62 для комады sysctl будут выглядеть как eth0/62 - лишняя точка сбила бы команду с толку.
P.P.S. ежели используется VirtualBox, то следует заметить что на драйверах Intel PRO (em(4)) vlan не заведется - это не мной первым замечено - нужно использовать PCnet (le(4)).

Явное указание архитектуры процессора при сборке RPM

Если мы компилим rpm пакеты из SRPM, то почему бы не убить двух зайцев сразу - и не оптимизировать пакеты под свой процессор (если, конечно, машина не крутится на стареньком i586). Описываемый ниже спсоб не страдает элегантностью, но он, по крайней мере, работал на Mandriva 2008.1
Наша задача разбивается на два этапа (в приведенных далее командах предполагается что пакет собирается для архитектуры pentium4 - доступные значения архитектуры можно смотреть в man gcc (1) (значения опций -march и -mtune) или в файле /usr/lib/rpm/rpmrc - там нам интересны значения arch_canon):

1. для компиляции пакета для нужной целевой платформы в строку вызова rpmbuild добавляем опцию --target=pentium4
2. пакет-то мы на прошлом шаге собрали, только rpm -i не сможет его установить. Побеждется это записью строки pentium4-intel-linux (или как там правильно для Вашей архитектуры) в файл /etc/rpm/platform
   

Заставляем работать software модем на ноутбуке с Linux

Есть ноутбук (если точнее, Fujitsu-Siemens Esprimo U9200) и Linux (если точнее, Mandriva 2009.0), у ноутбука есть встроенный модем (по сообщениям винды Motorola SM56), который автоматически при установке мандривы не обнаруживается. Прикручиваем руками.
Т.к. модем у нас софтверный, то понятно, что для его работы нужна некая софтина. Называтся эта софтина slmodemd. В случае мандривы устанавливатеся так:
# urpmi slmodem
Если в вашем дистрибутиве такого пакета нет, то можно поискать тут.
В простом случае для ее работы достаточно поправить код страны в файле /etc/sysconfig/slmodemd:
SLMODEMD_COUNTRY=RUSSIA
на случай, если вы заблудились вдали от родины, то список допустимых стран покажет команда:
$ slmodemd --countrylist
и запустить демон командой:
# /etc/init.d/slmodemd start
Критерий успеха - появление в каталоге /dev файла ttySL0 (это и будет порт модема для программы дозвона).
Но у меня так просто не заработало. У меня понадобилось включить у модема режим ALSA. Пишем в /etc/sysconfig/slmodemd:
SLMODEMD_MODULE=snd-intel8x0m
а потом (как это не удивительно) надо править скрипт /etc/init.d/slmodemd Причина в том, что в режиме ALSA устройством модема является не умолчательное /dev/slamr0, а устройство, полученное от системы asound. Там другое пространство имен. Нужное имя (из двух цифр) ищем командой:
$ cat /proc/asound/pcm | grep -i modem
Видим что-то типа:
00-06: Si3054 Modem : Si3054 Modem : capture 1
заменяем черточки в номере (первое поле) запятыми - и получаем устройство hw:0,6
Так и пишем в /etc/init.d/slmodem:
SLMODEMD_FULLDEVICE=hw:0,6
(это строчка в ветке if [ "$SLMODEMD_MODULE" = snd_intel8x0m ] - как раз наш случай).
На всякий случай, если slmodemd предполагается запускать не через скрипт /etc/init.d , а из какого-то своего скрипта, то все много короче. Строка вызова такая:
# slmodemd -c RUSSIA -a hw:0,6
(кажется, работоспособен и более простой синтаксис -a modem:0)
Модем часто теряет несущую сразу после соединения. Если для дозвона используется wvdial, то одолеть проблему можно, добавив в /etc/wvdial.conf строку:
Carrier Check = no
(при использовании гольного pppd проблема не наблюдается).
P.S. после этого модем завелся, но связаться с провайдером пока удается только на протоколах V.22bis и ниже. Если кому-то интересны такие скорости, то команда выбора протокола в этом случае такая: at+ms=122
Полный список доступных протоколов можно получить командой at+ms=? (протоколы выводятся в виде цифровых кодов, для их перевода в более принятую V.XX-нотацию, можно заглянуть в файл modem/modem_defs.h в исходниках slmodem - в нем искать описание enum DP_ID. Неплохую справку по АТ-командам, поддерживаемым slmodem, можно найти, почитав файл modem/modem_at.c - надо сказать, что перечень их довольно сильно отличается от официальной документации производителя модема - ежели вам все-таки не хватает списка от Motorola, читайте его тут).

Настройка vpn-туннеля по протоколу L2TP в Linux

Дано: Mandriva 2008.1, маршрутизатор Cisco 7200 серии, терминирующий туннели и поддерживающий протокол L2TP, нужно поднять туннель по этому протоколу без поддержки IPSec.
Пусть: адрес Cisco 172.16.0.1, мой шлюз по умолчанию (до поднятия туннеля) 10.0.0.1, имя пользователя vpn_user, пароль vpn_secret (в дальнейшем эти значения в командах и конфигах заменять на реальные).
Перед тем как начнем - два важных пункта подготовки.
Первое. Маршрут до терминатора vpn должен существовать как до, так и после поднятия туннеля (когда у нас изменится маршрут по умолчанию), потому необходимо прописать его явно:
# route add -host 172.16.0.1 gw 10.0.0.1
Так как в будущем это должно работать при загрузке, то надо либо добавить эту строку в файл /etc/rc.local (грубый вариант, который будет работать в любом Linux), либо (для Mandriva и RedHat-like) добавить строку
172.16.0.1/32 via 10.0.0.1
в файл /etc/sysconfig/network-scripts/route-eth0 (если у вас несколько сетевух, то возможно будет не eth0)
Еще один вариант (точно работает в Mandriva и рекомендуется Mandriva Wiki) - файл называется /etc/sysconfig/network-scripts/eth0.route (UPD: имя route-eth0 тоже работает) и синтакис у него такой:
ADDRESS0=172.16.0.1
NETMASK0=255.255.255.255
GATEWAY0=10.0.0.1
(если маршрут - не первый в фале, то вместо 0 будет 1, 2 и т. д.)
Для других популярных Linux действуем примерно так (прочитано в сети, не тестировалось):
В debian-like (*buntu, etc):
в файле /etc/network/interfaces
в раздел
iface eth0 inet static
добавить строку
<символ табуляции>post-up route add -host 172.16.0.1 gw 10.0.0.1

В OpenSUSE файл называется /etc/sysconfig/network/ifroute-eth0
и синтаксис строк в нем такой:
172.16.0.1 10.0.0.1 32

И второе. Для того, чтобы туннель мог быть успешно установлен, необходимо разрешить прохождение пакетов протокола UDP между портами 1701 терминатора vpn и нашего компьютера в обоих направлениях. Т.е. если конфигурацией файрвола на прохождение пакетов UDP наложены какие-то ограничения (а они у разумного администратора должны быть наложены), то должны быть добавлены примерно такие два правила:

# iptables -A INPUT -p udp -s 172.16.0.1 --sport 1701 --dport 1701 -j ACCEPT
# iptables -A OUTPUT -p udp -d 172.16.0.1 --sport 1701 --dport 1701 -j ACCEPT
Теперь начинаем собственно строить VPN. Входящий в репозиторий Mandriva пакет l2tpd у меня не завелся, потому ставил его форк xl2tpd (брать тут - есть tar.gz и srpm - кому что больше нравится). Версия у меня была 1.2.0-1. Собираем, ставим, пишем конфиг демона (файл /etc/xl2pd/xl2tpd.conf):
[lac c7200]
name = vpn_user
require chap = yes
require pap = no
lns = 172.16.0.1
redial = yes
require authentication = no
ppp debug = no
pppoptfile = /etc/ppp/options.xl2tpd
autodial = yes
hidden bit = no
flow bit = yes
length bit = yes

Опции pppd как видно из прошлого файла, пишем в /etc/ppp/options.xl2tpd:
unit 0
name vpn_user
ipparam l2tp_vpn
connect /bin/true
mru 1460
mtu 1460
noauth
persist
maxfail 0
nopcomp
noaccomp

имя и пароль добавляем в /etc/ppp/chap-secrets:
vpn_user * vpn_secret

И - для поднятия маршрутизации (т.к. pppd не умеет при запуске перзаписать существующий маршрут по умолчанию) пишем такой скрипт /etc/ppp/ip-up.local:
#!/bin/sh

# переменная $6 - это ipparam,
# заданный нами в /etc/ppp/options.xl2tpd
if [ "$6" = "l2tp_vpn" ]
then
route delete default
route add default ppp0
fi

а для обратного отката - скрипт /etc/ppp/ip-down.local:
#!/bin/sh
route delete default
route add default 10.0.0.1

(не забыть, что эти два файла должны быть исполняемыми)
Если при выключенном vpn шлюз по умолчанию Вам не нужен (все равно никуда не пущают ;), то можно вместо таких жестоких путей просто добавить строку:
defaultroute
в файл /etc/ppp/options.xl2tpd
Запускаться наш vpn будет командой:
# /etc/init.d/xl2tpd start
Осталось заметить в скобках, что в ту же мандриву входит модуль ядра pppol2tp. Так вот его в данной конфигурации загружать не надо. xl2tpd вроде должен уметь с ним работать, но у меня не заработал. Возможно, что-то не то с версиями ядра и демона.