четверг, 10 сентября 2009 г.

Настройка кэширующего DNS-сервера BIND в связке с resolvconf

Опять же на работе понадобилось настроить кэширующий DNS-сервер BIND так, чтобы DNS-запросы сначала передавались провайдерским DNS-серверам (forwarders) и только в случае, если они не доступны, выполнялось самостоятельное рекурсивное решение DNS-запросов. DNS-серверы прописывать прямо в конфиг BIND не хотелось, хотелось чтобы он подхватывал их от PPPoE-подключения и Ethernet-подключения.

Вообще этот DNS-сервер не только выполняет функции кэширования, но является авторитативным для нескольких зон (master), подчинённым для других зон (slave), и выполняет передачу DNS-запросов для нескольких локальных корпоративных зон (forward) на локальные же авторитативные DNS-серверы вышестоящей корпоративной сети. Но суть заметки не в этом. Остальные аспекты настройки DNS-сервера хорошо описаны в различных источниках и не представляют каких-либо проблем.

Сначала поставим пакеты resolvconf и bind9:
# aptitude install resolvconf bind9
Пропишем в настройках Ethernet-интерфейса провайдера опцию dns-nameservers 81.30.199.5 81.30.199.94.
Соответствующий кусок файла /etc/network/interfaces будет выглядеть примерно так:
# ufanet
auto eth0
iface eth0 inet static
  address xx.xx.xx.250
  netmask 255.255.255.252
  #gateway xx.xx.xx.249
  dns-nameservers 81.30.199.5 81.30.199.94
Для получения адресов DNS-серверов от другого провайдера по протоколу PPPoE, в соответствующий этому провайдеру файл настроек /etc/ppp/peers/bis добавим опцию usepeerdns.

Теперь создадим шаблон для раздела опций BIND в файле /etc/bind/named.conf.options:
options {
  directory "/var/cache/bind/";

  forward first;

  forwarders { };

  listen-on {
    127.0.0.1;
    xx.xx.xx.250;
    10.3.0.0/18;
  };
};
Проверим, что в файле /etc/default/bind9 установлена переменная RESOLVCONF=yes. Если она принимает значение no, исправьте её на yes.

Если сейчас перезапустить BIND, то будет создан файл /var/run/bind/named.options, содержащий следующее:
// named.conf fragment automatically generated by /etc/resolvconf/update.d/bind
// DO NOT EDIT THIS FILE.  Instead edit /etc/bind/named.conf.options .
options {
  forwarders { 81.30.199.5; 81.30.199.94; 10.3.1.4; };
  directory "/var/cache/bind/";
  forward first;
  listen-on {
    127.0.0.1;
    xx.xx.xx.250;
    10.3.0.0/18;
  };
};
А в файле /etc/resolv.conf можно будет увидеть следующее:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
То есть видно, что при запуске BIND или изменении DNS-настроек отрабатывают сценарии resolvconf, которые соответствующим образом изменяют эти файлы.

Чтобы настройки BIND брались из файла /var/run/bind/named.options нужно прописать его подключение в файле /etc/bind/named.conf, заменив директиву
include "/etc/bind/named.conf.options";
на директиву
include "/var/run/bind/named.options";
Теперь можно перезапустить BIND и он будет встраиваться в систему решения DNS-запросов таким образом, как мы этого и хотели.

Настройка PPTP-сервера

На работе возникла необходимость под Linux настроить PPTP-сервер для Windows-клиентов. На всякий случай решил описать пример настройки.

Ставим ppp и pptpd:
# aptitude install ppp pptpd
Настраиваем сам сервер pptpd, прописывая в его конфигурационном файле /etc/pptpd.conf:
option /etc/ppp/pptpd-options
logwtmp
localip 10.3.17.1
remoteip 10.3.17.2-254
Опция localip задаёт IP-адрес на локальной стороне создаваемых туннелей, опция remoteip - задаёт соответственно диапазон IP-адресов, которые будут выдаваться клиентам, в качестве адресов с их стороны.

Настроим pppd для туннелей, поднимаемых сервером pptpd. Зададим настройки в файле /etc/ppp/pptpd-options:
10.3.17.1:
name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns 10.3.1.3
ms-dns 10.3.1.4
ms-wins 10.3.1.4
ms-wins 10.3.1.5
nodefaultroute
lock
nobsdcomp
idle 900
Первая опция задаёт IP-адрес локальной стороны туннеля (почему-то настройка, указанная в /etc/pptpd.conf не действует).

Опция name pptpd задаёт имя сервера. Оно будет использоваться для поиска записей в файле паролей (см. ниже).

Опции refuse-pap, refuse-chap, refuse-mschap, require-mschap-v2 отклоняют различные способы аутентификации, требуя использовать только аутентификацию по MS-CHAPv2.

Опция require-mppe-128 указывает на необходимость шифрования передаваемых по туннелю данных с помощью протокола MPPE с длиной ключа 128 бит.

Опции ms-dns 10.3.1.3 и ms-dns 10.3.1.4 задают адреса DNS-серверов, которые будут сообщены подключившемуся клиенту.

Опции ms-wins 10.3.1.4 и ms-wins 10.3.1.5 задают адреса WINS-серверов, которые будут сообщены подключившемуся клиенту.

Опция nodefaultroute заставляет pppd не устанавливать маршрут по умолчанию через подключившегося клиента.

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

Опция nobsdcomp отключает сжатие потока данных по алгоритму BSD.

Опция idle задаёт количество секунд простоя, по истечении которых простаивающее соединение будет отключено.

Теперь нужно прописать клиентов в файле паролей /etc/ppp/chap-secrets:
elvira          pptpd   "111111"                10.3.17.23
#kon_sv         pptpd   "passwd"                *
igor            pptpd   "paroli"                10.3.17.28
Символ решётки говорит о том, что данная запись отключена (закомментирована).

Символ звёздочки говорит о том, что этому клиенту будет выдан любой свободный адрес из диапазона 10.3.17.2-254, который указан в настройках pptpd.

Клиентам, для которых указан IP-адрес в последней колонке, всегда будут выдаваться этот IP-адрес.

Теперь перезапускаем PPTP-сервер, чтобы настройки вступили в силу:
# /etc/init.d/pptpd restart
Если хочется выполнять какие-то специфические для PPTP-клиента команды, то можно создать сценарии /etc/ppp/ip-up.d/pptp-clients и /etc/ppp/ip-down.d/pptp-clients, шаблон для которых представлен ниже:
#!/bin/sh

case "$PPP_IPPARAM" in
  "pptp-clients")
    # ваши команды
  ;;
  *)
    echo "No PPP_IPPARAM defined"
  ;;
esac
Теперь в файле /etc/pptpd.conf нужно прописать опцию noipparam, которая заставит pptp-сервер не передавать в качестве ipparam IP-адрес, с которого было установлено подключение.

Чтобы отличать pptp-клиентов от других PPP-подключений, добавим опцию ipparam в файл /etc/ppp/pptpd-options:
ipparam "pptp-clients"
В случае если ipparam будет равен pptp-clients, выполнятся указанные для этого случая команды. Например таким образом можно настраивать разрешающие правила в фаерволле. В том числе можно делать дополнительные проверки, идентифицируя клиента по IP-адресу внутри тоннеля или по логину, с которым клиент подключился.

Другие источники информации по этой теме:
  1. Настройка PPTP-сервера в Debian/Ubuntu
  2. Русский перевод man pppd(8) - демон протокола точка-точка (Point-to-Point Protocol Daemon)
  3. Русский перевод man pptpd(8) - PPTP VPN-демон
  4. Русский перевод man pptpd.conf(5) - конфигурация PPTP VPN демона
Последняя правка: 22-09-2009

вторник, 4 августа 2009 г.

IceWM

Поделюсь небольшим опытом по переходу с KDE на IceWM. Поскольку жизнь KDE 3.5 фактически закончится тогда, когда закончится поддержка Lenny, то KDE 3.5 скоро не станет. Пришедшая ей на смену среда KDE 4 мне не нравится, поэтому я потихоньку присматриваюсь к другим, более лёгким средам.

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

1. Автомонтирование сменных носителей информации, например дискет, компакт-дисков и USB-накопителей.

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

В KDE эта подсистема называется KIO. В Gnome ранее использовалась подсистема под названием GnomeVFS. В более современных версиях Gnome, начиная с версии 2.22, используется новая подсистема, которая называется GIO. Планировалось, что эта подсистема будет по-настоящему монтировать устройства с помощью подсистемы FUSE. Так ли обстоит дело в настоящее время, я не понял. Отслеживание зависимостей пакета gvfs говорит о том, что FUSE не используется. Однако наличие пакета gvfs-fuse говорит об обратном. Видимо доступны оба механизма или в настоящее время происходит плавный переход с использования одного механизма на использование другого. Поскольку я не пользуюсь Gnome, точнее сказать ничего не могу.

При использовании FUSE монтирование всё-же должно происходить, из чего следует одно довольно важное преимущество - смонтированными ресурсами смогут пользоваться программы, не ориентированные на Gnome.

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

Мною были опробованы демон автоматического монтирования autofs, поведение которого мне показалось довольно странным. Он требует использования отдельного каталога, в котором будут появляться все автоматически смонтированные файловые системы. В этом каталоге не должно быть посторонних каталогов, если они есть - они будут недоступны. Демон автомонтирования autofs показал себя не случшей стороны ещё по той причине, что иногда он попросту не срабатывал! Пока что я отмёл его, как "плохой, не годный" демон.

Конфигурационный файл autofs - /etc/autofs.master:
/auto /etc/auto.misc -timeout=10
Конфигурационный файл autofs - autofs.misc:
floppy -fstype=auto,user,nosuid,sync,umask=000 :/dev/fd0
cdrom -fstype=iso9660,user,nosuid,ro :/dev/hda
usb1 -fstype=auto,user,nosuid,sync,umask=000 :/dev/sdb1
usb2 -fstype=auto,user,nosuid,sync,umask=000 :/dev/sdc1
Далее, были опробованы менеджеры монтирования asmounter, wmmount, mountapp. Менеджеры просматривают список доступных точек монтирования в /etc/fstab и предоставляют удобный мышиный интерфейс для монтирования, размонтирования и извлечения сменных накопителей. Все три менеджера монтирования оказались ориентированы на совместное использование с оконными менеджерами AfterStep или WindowsMaker. С другими менеджерами они тоже работают, но в этом случае они выглядят просто как небольшое окно с пиктограммами, а хотелось бы чтобы они встраивались в трей.



Пока что я остановился на небольшом меню, позволяющем осуществлять ручное монтирование, размонтирование сменных носителей с помощью команд pmount и pumount, и извлечение сменных накопителей с помощью eject. Это меню я прописал в файл ~/.icewm/toolbar:
menu "Disks" /usr/share/icons/crystalsvg/16x16/devices/cdrom_unmount.png {
        menu "CD" /usr/share/icons/crystalsvg/16x16/devices/cdrom_unmount.png {
                prog "Mount CD" /usr/share/icons/crystalsvg/16x16/devices/cdrom_mount.png  pmount /mnt/cdrom
                prog "Unmount CD" /usr/share/icons/crystalsvg/16x16/devices/cdrom_unmount.png pumount /mnt/cdrom
                prog "Eject CD" /usr/share/icons/crystalsvg/16x16/devices/cdrom_unmount.png eject /mnt/cdrom
        }
        menu "Floppy" /usr/share/icons/crystalsvg/16x16/devices/3floppy_unmount.png {
                prog "Mount Floppy" /usr/share/icons/crystalsvg/16x16/devices/3floppy_mount.png pmount /mnt/floppy
                prog "Unmount Floppy" /usr/share/icons/crystalsvg/16x16/devices/3floppy_unmount.png pumount /mnt/floppy
        }
        menu "USB 1" /usr/share/icons/crystalsvg/16x16/devices/usbpendrive_unmount.png {
                prog "Mount USB 1" /usr/share/icons/crystalsvg/16x16/devices/usbpendrive_mount.png pmount /mnt/usb1
                prog "Unmount USB 1" /usr/share/icons/crystalsvg/16x16/devices/usbpendrive_unmount.png pumount /mnt/usb1
        }
        menu "USB 2" /usr/share/icons/crystalsvg/16x16/devices/usbpendrive_unmount.png {
                prog "Mount USB 2" /usr/share/icons/crystalsvg/16x16/devices/usbpendrive_mount.png pmount /mnt/usb2
                prog "Unmount USB 2" /usr/share/icons/crystalsvg/16x16/devices/usbpendrive_unmount.png pumount /mnt/usb2
        }
}
А выглядит оно вот так:



Перспективным направлением дальнейших поисков является возможность автомонтирования через подсистему FUSE с помощью пакета afuse. Но пока что вопрос автомонтирования, а самое главное - авторазмонтирования остаётся открытым. Именно из-за того, что авторазмонтирование нужно даже больше, чем автомонтирование, мною отметается возможность воспользоваться привязкой команд монтирования к событиям udev.

2. Микширование звуковых потоков от нескольких программ.

Если кое-как, с грехом пополам, проблема монтирования была решена, то с микшированием аудиопотоков всё не столь радужно.

В интегрированных средах Gnome и KDE микшированием звуковых потоков от разных программ занимаются специальные звуковые серверы: ESD в Gnome, aRtsd - в KDE 3.5, Phonon - в KDE 4.

Вообще, архитектура звуковой подсистемы в Linux довольно запутана. Есть звуковые подсистемы OSS и ALSA, работающие с аудиоустройствами напрямую, а есть звуковые серверы ESD, aRtsd, Phonon, Pulse Audio и JACK. Задача первых - вывести звук на аудиокарту, задача вторых - смешать звуки от нескольких программ-источников или распределить их на несколько аудиокарт. Есть ещё звуковая подсистема OpenAL, которая используется для вывода звука в играх.

Довольно неприятным оказалось то, что разные программы умеют работать с разными подсистемами и звуковыми серверами. Может оказаться так, что одна программа умеет работать только с ALSA, а другая - только с aRtsd. При этом программы, включая звуковые серверы, попросту блокируют доступ к аудиоустройству ALSA для других программ.

Я нашёл возможность смешивать аудиопотоки от разных программ прямо в подсистеме ALSA с помощью плагина программного микширования dmix. Для этого необходимо внести изменения в файл /etc/asound.conf. Некоторые источники вообще утверждают, что ALSA начиная с версии 1.0.9 стала сама подключать возможность аппаратного или программного микширования аудиопотоков, но мне добиться автоматической настройки микширования от своей ALSA 1.0.27 не удалось. После внесения необходимых настроек в файл /etc/asound.conf, некоторые программы начали одновременно выводить звук, но другие по-прежнему монопольно захватывают устройства ALSA, так что остальные программы отваливаются с ошибкой доступа.

Это всё становится особенно обидно ещё потому, что в FreeBSD, которая использует собственную реализацию подсистемы OSS, микширование включается изменением всего пары переменных ядра с помощью команды sysctl!
# sysctl hw.snd.pcm0.vchans=4
# sysctl hw.snd.maxautovchans=4
3. Завершение работы, перезагрузка, блокирование консоли, хранитель экрана, обои рабочего стола.

Все эти задачи выполняются в Gnome и KDE встроенными средствами. В IceWM пришлось немного попотеть, прежде чем достичь подобной функциональности.

3.1. Настройка меню выключения и перезагрузки

Ставим sudo:
# aptitude install sudo
В его конфиге прописываем (редактор запускается по команде visudo):
Cmnd_Alias SHUTDOWN=/sbin/shutdown, \
  /sbin/halt, \
  /sbin/poweroff, \
  /sbin/reboot

stupin ALL=NOPASSWD: SHUTDOWN
В конфиге ~/.icewm/preferences прописываем:
ShutdownCommand="sudo /sbin/shutdown -h now"
RebootCommand="sudo /sbin/shutdown -r now"
3.2. Настройка меню блокировки компьютера и хранителя экрана

В конфиг ~/.icewm/startup прописываем автозагрузку сервера хранителя экрана:
#!/bin/sh

xscreensaver -no-splash &
Не забудьте сделать файл исполняемым, например такой командой:
$ chmod +x ~/.icewm/startup
В конфиге ~/.icewm/preferences прописываем:
LockCommand="xscreensaver-command -lock"
3.3. Настройка обоев

Настройка фонового рисунка для корневого окна (экрана) производится в файле ~/.icewm/preferences, в который нужно добавить строку с указанием полного имени фоновой картинки:
DesktopBackgroundImage="/home/stupin/wallpapers/penguins_forever.bmp"
3.4. Настройка автоматически запускаемых программ

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

В конфиг ~/.icewm/startup можно прописать программы, которые будут загружаться после запуска IceWM.

Я прописал загрузку:
kdeinit - без него не работают программы из KDE,
KXNeur - индикатор и интеллектуальный переключатель раскладки
#!/bin/sh

kdeinit &
kxneur &
Не забудьте сделать файл исполняемым, например такой командой:
$ chmod +x ~/.icewm/startup
3.5. Настройка сценария выхода

Если перед выходом из IceWM необходимо выполнить какой-то сценарий, его можно прописать в ~/.icewm/preferences:
LogoutCommand="команда"
Если сценарий завершения отрабатывает долго, то можно отменить завершение работы, пока сценарий ещё не завершился. Для этого можно прописать специальный отменяющий завершение сценарий:
LogoutCancelCommand="команда"
4. Запуск нового сеанса.

Для запуска нового сеанса KDE запускает ещё один X-сервер. Я довольно долго пытался разобраться с тонкостями работы протокола XDMCP, чтобы научиться не просто запускать дополнительный X-сервер, но и добиться появления на его экране приглашения ко входу от менеджера дисплеев.

Пока я разбирался с тем, как это сделать, я перепробовал несколько разных менеджеров дисплеев: xdm, gdm, kdm, wdm, slim. Самые приятные на вид из них - это gdm, kdm и slim. Однако настройки gdm и kdm довольно сложные и запутанные, а slim наоборот - не поддерживает некоторых функций. Классической схемой настройки обладают xdm и wdm, но они очень страшно выглядят. Для меня остаётся загадкой, почему до сих пор никто не довёл xdm или wdm до приемлемого внешнего вида. Может быть потому, что всем достаточно gdm и kdm?

В xdm и wdm запуск X-серверов прописывается в файл Xservers, а в kdm и gdm своя запутанная система их запуска. В конце концов я-таки расковырял kdm и настроил автозапуск второго X-сервера. Для этого в файле /etc/kde3/kdm/kdmrc нужно привести одну строчку к следующему виду:
StaticServers=:0,:1
При этом я нашёл способ заставить kdm обслуживать динамически запускаемые X-серверы, но пока не придумал как их распределять по незанятым консолям начиная с vt8.

Вот так вот, путём потери дополнительных ресурсов на постоянный запуск дополнительного X-сервера, была достигнута возможность работать одновременно в двух сеансах графических сред.

5. Темы оформления IceWM.

Из стандартных тем оформления IceWM, находящихся в пакете icewm-themes мне больше всего приглянулась тема IceCrack2:

Затем я решил поискать дополнительные темы для IceWM в Интернете и нашёл следующую ссылку: http://box-look.org/index.php?xcontentmode=7311&PHPSESSID=0e61faca62183300205af9ced1d4ef6f
Из них мне больше всего приглянулись следующие 7 тем:

EiskristallDesert:

IceClearlooks:

IceClearlooks+:

IceClearlooks2:

LXIceHybrid:

Plastik:

Narciso-1.2:

Я собрал все эти 7 тем в виде deb-пакетов, готовых для установки в систему:
icewm-theme-clearlooks-1.0_all.deb
icewm-theme-clearlooks2-1.0_all.deb
icewm-theme-clearlooks-plus-1.0_all.deb
icewm-theme-eiskristall-desert-1.0_all.deb
icewm-theme-lx-ice-hybrid-1.0_all.deb
icewm-theme-narciso-1.2_all.deb
icewm-theme-plastik-1.0_all.deb

6. Меню IceWM.

Меню может автоматически создаваться таким же образом, каким оно создаётся в средах Gnome или KDE, из файлов .desktop. Однако я решил дополнить стандартное меню KDE собственным меню, в которое я включил самые часто используемые мной программы:
prog Konsole konsole konsole
prog Iceweasel mozilla-firefox firefox
prog Krusader krusader_user krusader
separator
menu "Графика" gwenview {
        prog Gwenview gwenview gwenview
        prog KolourPaint kolourpaint kolourpaint
        prog KSnapshot ksnapshot ksnapshot
}
menu "Интернет" firefox {
        prog Iceweasel /usr/share/pixmaps/iceweasel.png firefox
        prog Chrome /opt/google/chrome/product_logo_16.png /opt/google/chrome/chrome --enable-plugins
        prog Psi /usr/share/pixmaps/psi.xpm psi
        prog DC++ dcpp-32 linuxdcpp
        prog Kopete kopete kopete
}
menu "Мультимедиа" mplayer {
        prog "KMPlayer" mplayer kmplayer
        prog amaroK amarok amarok
        prog Kaffeine kaffeine kaffeine
        prog K3b k3b k3b
        prog KMix kmix kmix
        prog KAudioCreator kaudiocreator kaudiocreator
        prog ExFalso exfalso exfalso
        prog ncmpc amarok konsole --notabbar --nomenubar --noframe --noscrollbar -e ncmpc
}
menu "Утилиты" ark {
        prog Ark ark ark
        prog KCalc kcalc kcalc
        prog Kate kate kate
        prog KWrite kwrite kwrite
        prog KXNeur kxneur kxneur
        prog GnomeCatalog /usr/share/gnomecatalog/pixmaps/gcatalog.xpm gnomecatalog
        prog Krusader krusader_user krusader
        prog Thunar /usr/share/icons/hicolor/16x16/apps/Thunar.png thunar
        prog PCManFM pcmanfm pcmanfm
        prog "ДубльГИС" 2gis 2gis
}
menu "Игры" snake4 {
        prog "Alien Arena" alien-arena alien-arena
        prog Nexuiz nexuiz nexuiz
        prog "Open Arena" openarena32 openarena
        prog Sauerbraten sauerbraten sauerbraten
        prog SDL-Ball sdl-ball sdl-ball
        prog SuperTux /usr/share/icons/hicolor/32x32/apps/supertuxkart.xpm supertux
        prog Mahjongg gnome-mahjongg mahjongg
        prog KNetWalk knetwalk knetwalk
        prog PipeWalker PipeWalker pipewalker
        prog Snake4 snake4 snake4
        prog GnomeTris gnometris.xpm gnometris
        prog Celestia /usr/share/pixmaps/celestia.png celestia
}
menu Офис /usr/share/icons/hicolor/16x16/apps/ooo-writer.png {
        prog "OpenOffice.org Base" /usr/share/icons/hicolor/16x16/apps/ooo-base.png ooffice -base
        prog "OpenOffice.org Calc" /usr/share/icons/hicolor/16x16/apps/ooo-calc.png ooffice -calc
        prog "OpenOffice.org Draw" /usr/share/icons/hicolor/16x16/apps/ooo-draw.png ooffice -draw
        prog "OpenOffice.org Impress" /usr/share/icons/hicolor/16x16/apps/ooo-impress.png ooffice -impress
        prog "OpenOffice.org Math" /usr/share/icons/hicolor/16x16/apps/ooo-math.png ooffice -math
        prog "OpenOffice.org Writer" /usr/share/icons/hicolor/16x16/apps/ooo-writer.png ooffice -writer
        prog KCHMViewer /usr/share/icons/crystalsvg/48x48/apps/kchmviewer.png kchmviewer
        prog DjView4 /usr/share/icons/hicolor/32x32/apps/djvulibre-djview4.xpm djview
        prog KPDF /usr/share/icons/hicolor/16x16/apps/kpdf.png kpdf
        prog KGhost /usr/share/icons/hicolor/16x16/apps/kghostview.png kghost
        prog FBReader FBReader.png fbreader
        prog KSocrat /usr/share/icons/locolor/16x16/apps/ksocrat.png ksocrat
}
menu "Эмуляторы" dosbox {
        prog WINE wine wine
        prog DOSBox dosbox dosbox
        prog QEmuLator qemulator.xpm qemulator
}
В общем, можно сделать один простой, но очевидный вывод: среды KDE и Gnome не имеют отношения к Linux. Эти среды часто дублируют функционал ядра Linux таким образом, что Linux станвится просто средством их запуска. Впрочем, и KDE и Gnome пытаются стать многоплатформенными средами. И это вполне успешно им удаётся. Периодически появляются новости, что KDE и Gnome запускаются, например, поверх Windows. KDE если не работает в Mac OS X, то по крайней мере стремится работать в ней.

Пока что остаются нерешёнными два вопроса: микширование звука от нескольких программ и автомонтирование (с авторазмонтированием по таймауту) сменных носителей информации.