Time Machine server on Linux

Появилась задача: резервировать данные рабочего MacbookPro. У Mac OS существует штатный инструмент для создания резервных копий - Time Machine, который для своей работы требует или внешний диск, подключаемый непосредственно к компьютеру, или устройство от Apple - Time Capsule. Есть и третий вариант, файловый ресурс на linux-сервере, доступный по протоколу AFP.

В случае внешнего HDD его придется отдать под задачу резервного копирования полностью: он будет отформатирован в соответствующем виде. Time Capsule стоит некоторых денег. Для реализации linux-версии нужно какое-то количество времени.

Итак, для доступа к сетевым файловым ресурсам у Apple есть свой протокол - Apple Filling Protocol (AFP), свободная реализация которого называется Netatalk. В текущем стабильном (и предыдущем стабильном) релизе Debian его нет, поэтому придется взять исходники с сайта и собрать. Если предполагается частая (или многочисленная) установка, то впоследствии можно сделать deb-пакет самостоятельно, например, с помощью checkinstall.

Сам процесс установки и настройки довольно прост:

- получаем и распаковываем архив с исходниками

root@mytmserver # wget -O netatalk-3.1.10.tar.bz2 -c "http://prdownloads.sourceforge.net/netatalk/netatalk-3.1.10.tar.bz2?download"
root@mytmserver # tar -xjvf ./netatalk-3.1.10.tar.bz2
root@mytmserver # cd netatalk-3.1.10/

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

root@mytmserver # apt update && apt install build-essential libgcrypt11-dev libdb-dev libacl1-dev

- конфигурируем и собираем (список параметров сборки можно посмотреть с помощью ./configure --help)

root@mytmserver # ./configure --prefix=/usr --sysconfdir=/etc/ --with-init-style=debian-systemd --with-cnid-dbd-backend --with-acls --enable-debug
root@mytmserver # make && make install

- запускаем и ставим в автозагрузку демона

root@mytmserver # systemctl start netatalk.service
root@mytmserver # systemctl status netatalk.service
root@mytmserver # systemctl enable netatalk.service 

- перезапускаем avahi (для автообнаружения макосью)

root@mytmserver # systemctl restart avahi-daemon.service 

В логах видим примерно следующее:

root@mytmserver # journalctl -u netatalk.service
дек 22 07:56:29 mytmserver systemd[1]: Starting Netatalk AFP fileserver for Macintosh clients...
дек 22 07:56:29 mytmserver systemd[1]: Started Netatalk AFP fileserver for Macintosh clients.
дек 22 07:56:30 mytmserver netatalk[1281]: Netatalk AFP server starting
дек 22 07:56:30 mytmserver netatalk[1281]: Registered with Zeroconf
дек 22 07:56:31 mytmserver afpd[1321]: Netatalk AFP/TCP listening on 192.168.1.100:548
дек 22 07:56:31 mytmserver cnid_metad[1322]: CNID Server listening on localhost:4700

Служба работает и готова принимать соединения.

Базовая настройка для целей резервного копирования:

 - добавить общие папки внутри домашних директорий существующих в системе пользователей:

/etc/afp.conf:
 [Homes]
 basedir regex = /home

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

/etc/afp.conf:
[myTMserver Folder]
 path = /data/raid1-media/timemachine
 time machine = yes
 valid users = delayer

Далее перезапустить службу netatalk.

Со стороны Mac OS нужно включить возможность работы с "нелегальными" Time Machine серверами. Для этого в консоли (iterm2, terminal):

$ defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

В Finder проверяем доступ: 

- Command + K 

- Адрес сервера: afp://192.168.1.100

- учетные данные пользователя delayer

Если каталог по сети доступен и аутентификация пройдена, можно идти  в Системные настройки - Time Machine - Выбрать диск... В окне должен быть доступен созданный ресурс. Добавляем, при необходимости снова аутентифицируемся. Далее служба будет создавать копии автоматически.

Debian certificate add

Задача: добавить в Debian корневой и промежуточный сертификаты, выпущенные корпоративным CA. 

Сертификаты прилетели в бинарном формате DER с расширением .cer, кушать который стандартная утилита обновления списка сертификатов (update-ca-certificates) отказалась (ROOT.cer does not contain a certificate or CRL: skipping).

Решение довольно простое: конвертировать в понятный для утилиты формат PEM

$ openssl x509 -inform der -in certificate.cer -out certificate.pem

После этого копируем полученные сертификаты в /usr/local/share/ca-certificates и запускаем обновление:

~$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
2 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
Adding debian:Issuing_CA01.pem
Adding debian:ROOT_CA.pem
done.
done.

Подсмотрено тут.

haspd: aksusbd: not found

При установке x64 Haspd (от Etersoft) в x64 же Debian имеем ошибку при запуске: 

/etc/init.d/haspd: aksusbd: not found

Дело в том, что несмотря на "собранность" под 64-битную платформу, по сути своей haspd остался 32-битным, поэтому для корректной работы ему нужны некоторые i386-библиотеки. 

Для решения заданной проблемы следует установить пакет libc6-i386.

Squid + Samba4 AD Kerberos Authorization

В продолжение предыдущей заметки пара слов об авторизации доменных пользователей в Squid посредством того же Kerberos. Вообще все должно быть легко, ибо все уже украдено до нас есть готовый хелпер в комплекте /usr/lib/squid3/ext_kerberos_ldap_group_acl (по крайней мере, в Debian), который умеет ходить в AD, авторизовываться текущим keytab-ом, получать необходимые тикеты и понимать, находится ли поданная ему на вход учетная запись пользователя в заданной группе. Для тестовых целей, как и ранее, запускаем прямо из консоли:

/usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g FastInet@EXAMPLE.COM

Для дебага можно добавить опции -i или -d. Опция -h покажет встроенный хелп. 

Нормальная работа хелпера выглядит так:

root@gw0:~# /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g FastInet@EXAMPLE.COM
inettest01@example.com
OK
inettest02@example.com
ERR 

Соответственно, пользователь inettest01 является членом группы FastInet в домене EXAMPLE.COM, а пользователь inettest02 - нет.

Если ERR имеем всегда, а -d показывает ошибки вида:

kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Unknown authentication method

то, возможно, не хватает модулей gssapi к библиотеке libsasl2, через которую реализуется подключение хелпера к домену по LDAP: libsasl2-modules-gssapi-mit. После установки этого пакета у меня такая ошибка более не появлялась:

kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
kerberos_ldap_group: DEBUG: Successfully initialised connection to ldap server dc0.example.com:389

В самом Squid конструкция описывается следующим образом:

external_acl_type fastgroup_krb children=10 cache=10 grace=15 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g FastInet@EXAMPLE.COM

acl fastinet external fastgroup_krb
http_access allow fastinet

Запись external_acl_type должна быть записана в одну строку. Переменная %LOGIN передает учетную запись пользователя от negotiate хелпера (см. предыдущую заметку). Конечно, групп может быть несколько, и количество определений external_acl_type не ограничивается.
Вроде бы все просто, однако на работе хелпера я сидел не один день. Судя по дебагу вида:

support_ldap.cc(856): pid=1593 :2015/06/09 15:50:55| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
support_sasl.cc(268): pid=1593 :2015/06/09 15:50:55| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error
support_ldap.cc(860): pid=1593 :2015/06/09 15:50:55| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error

хелпер не мог соединиться с контроллером домена по ldap и запросить требуемые данные. Причем keytab-файл заведомо использовался, имена разрешались и вообще до момента означенной ошибки все логи были хорошими.
В разборках сильно помогла заметка пользователя Timp, который указал отсутствующие на PTR-записи контроллеров домена в своей очень похожей ситуации. Беда в том, что nslookup на gw0 корректно разрешался в обе стороны для dc0.
По прошествии времени я снова вернулся к этой заметке и решил последовать примеру товарища - вооружиться tcpdump-ом. И каково же было моё удивление, когда я обнаружил ответа dc0 с содержимым NXDOMAIN! И да, появлялись они в моменты работы хелпера. И дважды да, предваряли эти сообщения запросы PTR для адреса контроллера домена!!!
Точки над i расставил dig (вывод я порезал):

root@gw0:~# dig -x 192.168.0.241
;; QUESTION SECTION:
;241.0.168.192.in-addr.arpa.   IN      PTR

Секции ANSWER нет! То есть, действительно, обратной записи для контроллера домена в DNS нет. Идем в соответствующую оснастку (или samba-tool в консоли dc0, что ближе) и добавляем недостающий пойнтер. Смотрим:

root@gw0:~# dig -x 192.168.0.241
;; QUESTION SECTION:
;241.0.168.192.in-addr.arpa.   IN      PTR
;; ANSWER SECTION:
241.0.168.192.in-addr.arpa. 3600 IN    PTR     dc0.example.com.

После этих действий хелпер начал работать.

Postgresql issue during Debian Wheezy to Jessie upgrade

Проблема, собственно, в чем: при обычном dist-upgrade сабжевая СУБД нормально обновилась с 9.1 до 9.4 (минорные циферки опустим, неважно). Однако сам процесс обновления оказался забавным: инсталлятор снес 9.1 (оставив конфиги в /etc/ и базы в /var/lib), установил 9.4, создал дефолтный кластер, запустил всю эту балалайку - и доволен. 

Таким образом, в итоге имеем корректно функционирующий постгрес, но с умолчальным конфигом и без баз =).

Вообще, у postgresl имеется встроенный механизм обновления - pg_upgrade, который сам проверяет совместимость баз в старом и новом релизах и перебрасывает их из папки в папку (полагаю, что и вносит при этом необходимые изменения). Но дебиановские мейнтейнеры как-то этот момент похоже упустили. 

А делать надо следующее (актуализированные команды, чтобы не переписывать, взяты отсюда, а документация по этому вопросу - тут):

sudo -H -u postgres /usr/lib/postgresql/9.4/bin/pg_upgrade \
-b /usr/lib/postgresql/9.1/bin \
-B /usr/lib/postgresql/9.4/bin \
-d /var/lib/postgresql/9.1/main \
-D /var/lib/postgresql/9.4/main \
-o ' -c config_file=/etc/postgresql/9.1/main/postgresql.conf' \
-O ' -c config_file=/etc/postgresql/9.4/main/postgresql.conf'

Конечно, писать все можно и в одну строчку, забыв про "\". Строчные буквы относятся к файлам старой версии, прописные - к новой. 

В моем случае беда была в том, что при обновлении все бинарные файлы старого релиза оказались удалены, а в репозиториях jessie версии 9.1 уже нет. Поэтому пришлось искать старый .deb (благо кэш apt-а никто не чистил), и подсовывать файлики оттуда (установить deb-пакеты - плохая идея, ибо он начнет делать downgrade текущей инсталляции).

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

Debian Sid Fails to initramfs when root on lvm2

Сделав в очередной раз на рабочем десктопе с Debian Sid aptitude dist-upgrade, получил выпадение загрузчика в initramfs shell с ошибкой нахождения устройства, на котором находится корневой раздел. Диски на рабочей станции разбиты следующим образом: отдельный /boot раздел, все остальные разделы, включая корневой - внутри lvm-группы Debian.

Таким образом, GRUB отработал успешно, но не смог смонтировать корень и продолжить загрузку основной системы.

Далее выяснилось, что проблема заключается в том, что вышеуказанная lvm-группа не активируется при старте, поэтому ее логические тома для загрузчика и ядра не видны. Если в командной строке шелла написать lvm vgchange -ay Debian, а затем выйти из шелла через Ctrl+D, загрузка системы продолжится и пройдет успешно.

Поиски в этих ваших интернетах навели сразу на два дебиановских бага - первый, посвежее, связан с "недосовместимостью" lvm2 и systemd, второй, постарше, с некорректной работой одного из скриптов initramfs (опять же связанный с lvm2).

Так что если у вас аналогичная проблема, но вы уже используете systemd - скорее всего, поможет обновление пакета lvm2 до версии 2.02.104-1 (на момент написания доступна уже версия  2.02.104-2).

В случае использования sysvinit (или upstart, кто вас знает) обозначенная проблема затрагивает initramfs (см. второй баг) и на момент написания еще не решена. Суть бага - некорректная обработка имен lvm-разделов в случае использования UUID в grub.cfg. Таким образом, временное решение - отключение использования UUID в /etc/default/grub:

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID=true

После этого grub-mkconfig && update-grub решают проблему с загрузкой ОС.

Zabbix Template for linux disks monitoring (iostat)

Озадачили меня сбором расширенной статистики работы дисковой подсистемы сервера баз данных (Debian 7 + PosgreSQL 9.1). Начал было раздумывать над новым шаблоном в Zabbix и источниках данных для его элементов, как попался на глаза отличный и практический готовый к употреблению шаблон, скрипты сбора и парсинга данных (на базе iostat) и описание пользовательских параметров для всего этого счастья. Автор - вот, статья по сабжу - вот. Комментарии также рекомендованы к прочтению.

После минимальной адаптации к своей системе все импортировалось и заработало. Автору большое спасибо, всем остальным - рекомендую.

Kaspersky Endpoint Security for Linux

В испытательно-лабораторных целях, а также во исполнение корпоративной политики в области защиты информации взгромоздил на свою linux-машину (Debian Sid) антивайрус Kaspersky Endpoint Security For Linux Workstations. Ну и агента администрирования до кучи. 

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

С агентом все ровно - параметры центра администрирования указал, запускаться разрешил, оно работает и не шуршит; центр администрирования компьютер подцепил и видит. А вот с KES-ом возникло две непонятки. 

Во-первых, ему не понравились установленные linux-headers:

Warning: The Linux kernel source code found in
/lib/modules/3.9-1-686-pae/build is not configured correctly. You need to
configure it to build the kernel-level real-time protection module.

То есть найти нашел, но не всосал. Возможно, стоит обновиться до более свежего linux-image-3.11, для которого есть доступный пакет linux-sources, и натравить на него. Неясно.

Второй момент - в процессе интерактивной настройки нет возможности указать ни ключевой файл с лицензией, ни источник обновления. А так как выкачивать несколько сотен метров обновлений мне не улыбается, а без баз KES разумно отказывается работать, то возникают вилы.

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

EULA_AGREED=yes
SERVICE_LOCALE=ru_RU.utf8
INSTALL_KEY_FILE=/opt/kaspersky/license.key
UPDATER_SOURCE=AKServer
UPDATER_PROXY=no
UPDATER_EXECUTE=yes
UPDATER_ENABLE_AUTO=no
RTP_BUILD_KERNEL_MODULE=no
RTP_BUILD_KERNEL_SRCS=auto
RTP_SAMBA_ENABLE=yes
RTP_SAMBA_CONF=/etc/samba/smb.conf
RTP_SAMBA_VFS=/usr/lib/samba/vfs/
RTP_SAMBA_VFS_MODULE=/opt/kaspersky/kes4lwks/lib/samba/kes4lwks-smb-vfs28.so
RTP_START=yes
GUI_ENABLE=yes

 По-хорошему, собирать ядерный модуль бы надо ( RTP_BUILD_KERNEL_MODULE=no ), но пока отключил, чтобы не ругалось. Если это дело скормить скрипту настройки,

 /opt/kaspersky/kes4lwks/bin/kes4lwks-setup.pl --auto-install=./kes_file

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

И, напоследок, страшный скриншот:

 

List of Debian repositories

Довольно полный список официальных, неофициальных и вообще левых репозиториев для Debian, отформатированный для вставки в /etc/apt/sources.list .

Debian + USB ADSL modem

Совершенно внезапно словил "зов из прошлого" - потребовалось завести под Debian-ом старый-старый USB ADSL модем. Так как они все на Conexant-овском чипе, то и заводятся идентично. Вся проблема - найти фирмварь для ядерного модуля (да-да, в ядре уже давно все, как в Греции). Здесь мне помог вот этот ресурс. Более того, там описан и весь процесс установки и настройки сего девайса. В общем, читаем, смотрим, настраиваем. Единственное, что там не описано, на появившийся псевдо-интерфейс (nas0) следует навесить какой-нибудь IP-адрес, иначе pppoe-discovery не сможет корректно отработать.

Old Debian iso-releases.

Возникла необходимость в iso-образе "старого" дистрибутива Debian. Оказалось, что на всех основных зеркалах выпилено все, что ниже stable. А там, где не выпилен (хотя бы oldstable), то лежит только репозиторий. И тем не менее "в этих ваших интернетах" ничего не пропадает бесследно. Образы дисков всех релизов, начиная с 3.0_r0, лежат тут.

Установка и настройка vnstat + vnstat php frontend

Простенькая последовательность на "не забыть" по установке-настройке простенького же монитора трафика vnstat в Debian Squeeze, и не только.

apt-get install vnstat apache2 libapache2-mod-php5 php5-gd

Настройки в основном умолчальные (/etc/vnstat.conf), правим только интефейс (если хочется несколько, то через запятую):

#Interface "eth0"
Interface "ppp200"

Уводим логи в собственный файл вместо syslog:

#UseLogging 2
UseLogging 1
LogFile "/var/log/vnstatd.log"

Единоразово инициализируем базу:

root@demos:/home/interra/!# vnstat -e -i ppp200

Перезапускаем демон:

root@demos:/home/interra/!# service vnstat restart
Stopping vnStat daemon: vnstatd.
Starting vnStat daemon: vnstatd.

Убеждаемся, что все хорошо:

root@demos:/home/interra/!# cat /var/log/vnstatd.log
[2011.07.19 11:53:47] vnStat daemon 1.10 started.
[2011.07.19 11:53:47] Daemon running with pid 30757.
[2011.07.19 11:53:47] Monitoring: ppp200

Скачиваем веб-морду vnStat PHP Frontend отсюда (на момент написания версия 1.5.1), распаковываем в /var/www/vnstat.

Настройки находятся в файле  /var/www/vnstat/config.php. Для базового запуска достаточно переопределить интерфейсы:

$iface_list = array('ppp200');

$iface_title['ppp200'] = 'Internet';

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

$vnstat_bin = '/usr/bin/vnstat';

или чтением данных из текстового дампа базы, выполненного командой вида vnstat --dumpdb -i $iface > /path/to/data_dir/vnstat_dump_$iface. В этом случае переменная $vnstat_bin комментируется, и описывается переменная $data_dir:

// $vnstat_bin = '/usr/bin/vnstat';
$data_dir = './dumps';

В приведенном примере полный путь к каталогу - /var/www/vnstat/dumps. Важно, чтобы файл с дампом назывался строго vnstat_dump_$iface, где $iface - имя интерфейса, за которым ведется мониторинг. Несколько интерфейсов - несколько файлов, каждый из которых заполняется отдельной командой.

Далее внесем в cron задание на периодическое обновление дампа такого вида, создав файлик в /etc/cron.d/ или вызвав редактор - crontab -e:

*/2 * * * * /usr/bin/vnstat --dumpdb -i ppp200 > /srv/www/vnstat/dumps/vnstat_dump_ppp200

Всегда используем в кроне только абсолютные пути!

Далее остается только перезапустить apache и обратиться браузером по адресу http://адрес_сервера/vnstat

Debian Lenny + HPLJm1522MFP + xsane

Потребовалось подружить Debian Lenny и HP LaserJet m1522 MFP. Если с печатью все заработало практически из коробки и без вопросов (с умолчальным в ленни hplip_2.6.8b), то со сканированием возникли проблемы. Во-первых, поддержка сканирования для этой модели принтера реализована только в hplip_2.8.6, поэтому пришлось скачать и поставить (читай, доставить кучу dev-пакетов и скомпилить) свежий hplip. Сканер стал определяться hp-check-ом и scanimage -L, однако сканировать отказывался - hp-scan и xsane в один голос заявляли об ошибке ввода-вывода, плюс в syslog-е имелась фигня подобного рода:

zp python: io/hpmud/hpmud.c 483: invalid device_close state
zp python: hp-scan[8989]: error: Error during device I/O
zp python: io/hpmud/hpmud.c 341: device_cleanup: device uri=hp:/usb/HP_LaserJet_M1522nf_MFP?serial=00VNHTB1FH7B
zp python: io/hpmud/hpmud.c 353: device_cleanup: close device dd=1...
zp python: io/hpmud/hpmud.c 355: device_cleanup: done closing device dd=1

и прочие непотребства.

Пытался ставить разные версии hplip, включать пользователей в разные группы - безуспешно. Решение оказалось внезапным и местами волшебным, поэтому первопричины нижеследующих действий я пояснить не берусь. В одном из многих просмотренных багтрекерах  нашлось предложение подменить библиотеку libhpmud.so. В моем случае имела место такая картина:

ls -l /usr/lib/libhpmud*
-rwxr-xr-x 1 root root    867 Май  4 17:49 /usr/lib/libhpmud.la
lrwxrwxrwx 1 root root     17 Май  4 17:49 /usr/lib/libhpmud.so -> libhpmud.so.0.0.4
lrwxrwxrwx 1 root root     17 Май  4 17:49 /usr/lib/libhpmud.so.0 -> libhpmud.so.0.0.6
-rwxr-xr-x 1 root root 189818 Май  4 17:49 /usr/lib/libhpmud.so.0.0.4
-rwxr-xr-x 1 root root 201843 Май  4 17:34 /usr/lib/libhpmud.so.0.0.6

Поэтому я заменил симлинк  /usr/lib/libhpmud.so -> libhpmud.so.0.0.4 на /usr/lib/libhpmud.so -> libhpmud.so.0.0.6

 mv libhpmud.so libhpmud.so_
 ln -s libhpmud.so.0.0.6 libhpmud.so

Чудесным образом ошибка исчезла и xsane запустился =). Да, возвращаясь к вопросу о группах - следует все же добавить пользователя в lp и scanner.

Восстановление работоспособности blueman

В один из дней после обычного для Sid-а aptitude dist-upgrade поломался bluetooth-applet. Точнее, blueman-applet, заменяющий дефолтный при установке сотфины blueman - более функционального и приятного менеджера голубозубых соединений. Сегодня выдалась свободная минутка, поэтому дошли руки поглядеть внимательнее, что сломалось.

Симптоматика следующая - после запуска рабочего стола (и апплета вместе с ним) blueman не может получить доступ к BT-адаптеру, показывая пустой список подключенных устройств, хотя сам адаптер подключен и системой корректно определяется:

delayer@inspire:~$ sudo hciconfig -a
hci0:    Type: BR/EDR  Bus: USB
    BD Address: 00:15:83:35:1D:6F  ACL MTU: 510:8  SCO MTU: 48:10
    UP RUNNING PSCAN ISCAN
    RX bytes:2056 acl:0 sco:0 events:80 errors:0
    TX bytes:4694 acl:0 sco:0 commands:78 errors:0
    Features: 0xff 0xfe 0xff 0xfe 0x98 0x3f 0x79 0x83
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
    Link policy: RSWITCH HOLD SNIFF
    Link mode: SLAVE ACCEPT
    Name: 'ISSCEDRBTA'
    Class: 0x5a0104
    Service Classes: Networking, Capturing, Object Transfer, Telephony
    Device Class: Computer, Desktop workstation
    HCI Version: 2.1 (0x4)  Revision: 0x90e
    LMP Version: 2.1 (0x4)  Subversion: 0x316
    Manufacturer: Integrated System Solution Corp. (57)

Такой вот стоит дешевенький донгл без роду-племени (хотя, может и вру, на корпусе логотип Acorp-а есть). Запуск апплета (или любой другой софтинки вида blueman-*) консольно проходил успешно, но с тем же результататом - нужные пункты меню выбирались, но не нажимались, а в логах узрелось нечто вида: "except dbus.DBusServiceUnknownError:". Раскопки этих ваших интернетов привели к workaround-у: а) добавить пользователя в группы dbus и uucp б) запускать апплет через ck-launch-session (некая приблуда ConsoleKit-ная). То бишь проблема, оказывается, с правами доступа. Дальнейший гуглинг вывел на файл /etc/dbus-1/system.d/bluetooth.conf, 

 <!-- This configuration file specifies the required security policies
     for Bluetooth core daemon to work. -->

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <!-- ../system.conf have denied everything, so we just punch some holes -->

  <policy user="root">
    <allow own="org.bluez"/>
    <allow send_destination="org.bluez"/>

    <!-- allow root to send to agents -->
    <allow send_interface="org.bluez.Agent"/>
  </policy>

  <!-- allow users at the console, see consolekit or libpam-foreground -->
  <policy at_console="true">
    <allow send_destination="org.bluez"/>
  </policy>

  <!-- allow users of bluetooth group to communicate with hcid -->
  <policy group="bluetooth">
    <allow send_destination="org.bluez"/>
  </policy>

  <policy context="default">
    <deny send_destination="org.bluez"/>
  </policy>

</busconfig>

где описываются политики для демона bluetoothd. Чтение его внутренностей показало, что доступ к демону и иже с ним имеют только а) root (отсюда работоспособность через sudo и ck-launch-session) и б) группа bluetooth.

Таким образом sudo adduser delayer bluetooth с последующим релогином проблему решает.

З.Ы.: XML-файлик удалось беспроблемно вставить в текст после прогона через эту форму.

Debian Sid + udev start error

Свежее обновление Sid-а принесло сурприз, иксы начали стартовать без устройств ввода, то есть ни мышки, ни клавы. Исследования системы показали, что виноват в этом udevd, который не может стартовать при загрузке ОС. Причина такого поведения: появление в дистрибутиве каталога /run (откуда такой взялся, пишут, к примеру, тут), в который udev пытается что-то писать (в моем случае, записать файлик root-link-rule), но почему-то не может. А так как X.org сегодня не занимается устройствами ввода сам (отдав это на откуп udev + hal), то он запускается без оных. Workaround-ов два (пока не попилят udevd): или удалить каталог /run (тогда udev начнет работать по старинке и будет писать свои правила в /etc/udev/rules.d/ вместо /run/udev/rules.d/), или добавить в секцию ServerLayout файла xorg.conf директиву Option "AllowEmptyInput" "false".

Также по проблеме есть бага, так что ее пилят. Вроде как даже есть какие-то фиксы (обсуждают тут), но в официальный репозиторий они пока не утекли, ждем-с. ;) Там же предлагаются и иные способы решения проблемы.

bind9 + форвардинг отдельной зоны.

Для многих это покажется элементарщиной и вопросом, достойным гневного "RTFM!", но тем не менее, вполне может пригодиться. Задачка следующая: сказать шлюзному DNS-серверу (в роли которого выступает bind9), что заданную зону (в моем случае .vpn) спрашивать у отдельного DNS-сервера, а не ходить за ней к провайдеру, который ни сном ни духом. Делается это просто: в файл /etc/bind/named.conf.local добавляем следующие строки:

zone "vpn" {
    type forward;
    forwarders { dns-server-ip; };
    };

где  dns-server-ip, конечно, адрес сервера, знающего всю правду о зоне .vpn. После этого перезапускаем bind и проверяем работоспособность nslookup-ом.
Для реверсивного разрешения (при условии, что на удаленном сервере оно настроено) действия аналогичны:

zone "xxx.168.192.in-addr.arpa" {
    type forward;
    forwarders { dns-server-ip; };
    };

xxx.168.192 - обратная запись айпишников, в которые разрешаются dns-ки зоны vpn.

fam vs. gamin

А оказывается, вон оно как бывает... В общем, сносим fam, ставив gamin.

KDE3 + неработающий numpad

Старенькая проблемочка со старенькими KDE3.5.10 в Debian Lenny (а вот этот - вечно молодой в течение всего до'squeeze'ного периода): цифровая клавиатура (numpad) может в упор не работать, хотя лампочка соответствующая "включение-выключение" отрабатывает, в случае включенной опции управления курсором мыши с клавиатуры. Убирается по адресу: Система - Параметры - Оборудование - Клавиатура (или что-то вроде такого пути, может различаться в разных дистрибутивах).

Проблема сборки свежих ядер (2.6.33+) в Lenny - ошибка несоответствия версий.

Едрить-колотить! В кои-то веки потребовалось самому подсобрать дебиановское ядро (2.6.35 проверить на проблемной машинке) для Lenny, дак и то умудрился словить вилы. А именно - вот эти вилы, о которых все прогрессивное красноглазое человечество уже с начала года знает.

Симптоматика следующая:

This is kernel package version 11.015.
| echo "The UTS Release version in include/linux/version.h"; echo "          \"\" "; echo "does not match current version:"; echo "      \"2.6.33-rc1-amd64\" "; echo "Please correct this."; exit 2
| The UTS Release version in include/linux/version.h
|            ""
| does not match current version:
|            "2.6.35-interra"
| Please correct this.

И как не мучайся, пока не поставишь версию пакета kernel-package за номером 12.036, где бага поправлена, фиг что соберется. Хотя вру, старые ядра (до 2.6.33), говорят, собираются. Это и есть единственно верное лечилово. Да, в стабильном репозитории нужной версии пакета нет, поэтому или качать по ссылке выше, или подключить testing.

NX Client + Multimedia support

Появилась интересная задачка - получить звук с удаленного терминала на локальную рабочую станцию. И там и там linux (Debian Lenny и Ubuntu Lucid), терминал - NX (не ванильный NX-free от NoMachine), а RX@Etersoft, но в данном вопросе сие неважно). 

Немного потыкавшись по интернетам, выяснил, что сие возможно, причем без излишнего шаманства. Разработчики клиента добавили функционал "проброса" аудио-потока через nx-сессию, поэтому со стороны клиента достаточно в настройках подключения во вкладке Services выставить галку Multimedia Support. 

С серверной стороны действий несколько больше. Вскрытие показало, что для передачи аудио-потока используется eSound. В принципе, никаких допольнительных настроек оного не требуется, достаточно просто его установить:

apt-get install esound

Затем выставляем галку "Включить программное смешивание звука (ESD)" в Система - Параметры - Звук - вкладка Звук. Если установлен пакет gnome-audio, то тут же можно проверить работоспособность на звуковых файлах, нажав "Воспроизвести".

В принципе, всё. Можно слушать музыку, смотреть фильмы и так далее, нужно лишь установить какой-нибудь поддерживающий esd медиаплаер. Например, для работы с amaroK нужно в настройках движка xine (должна быть установлена библиотека libxine1) выставить модуль вывода esd. 

Непонятно, правда, как правильно задать вывод через esd для vlc, я ниасилил сделать это в интерфейсе настроек. Однако рабочим является такой вариант: vlc --aout=esd file:///home/user/Track1.mp3. Предварительно стоит установить пакет vlc-plugin-esd, который по умолчанию не всегда установлен.

Таким образом, если ширина канала позволяет, звук идет без артефактов. Теоретически, думаю, можно регулировать канал потока, но этим я не занимался пока что.