21 апреля, 2013

ControllerMate, ремап регулировки громкости

Уже не первый год в качестве звуковой карты я использую уже не самый интересный по нынешним меркам интерфейс Audiophile USB от M-Audio. Он меня более, чем устраивает по всем статьям, поэтому при переходе на Mac я и не думал расставаться с этой железкой.

Однако, меня поджидал неприятный сюрприз: драйверы для этой карточки под OS X не используют системный микшер, следовательно громкость соответствующими клавишами на клавиатуре не регулируется, мол, в вашей карточке нечего крутить. На сайте M-Audio об этом указано, а в качестве решения предлагают крутить либо громкость в приложении, либо регулятор на передней панели аудиоинтерфейса.

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

И хотя я уже знал про существование такого чудо-приложения, как ControllerMate, провернуть описанный выше фокус удалось не сразу. Возможно, сказывается то, что с OS X я до этого толком не работал, а возможно - тот факт, что редко кто не из музыкантов и им сочувствующих пользуется внешней звуковой картой, а уж тем более с маком.

Итак, открываем ControllerMate.

Для начала я убрал действия для клавиш регулировки громкости, чтобы больше не выводилось уведомление о том, что регулировать нечего. На функционал не влияет, сделано сугубо в эстетических соображениях.

Нажимаем "Create Driver Configuration", выбираем нашу клавиатуру (в моем случае используется клавиатура от Logitech)". Хотя в моем случае почему-то выбрать надо было мышь. Это не совсем очевидно, согласен.


Находим пункты "Volume Increment" и "Volume Decrement", меняем поведение с Default на None.

После этого создаем новую группу для нашей клавиатуры (или пишем новые правила в существующую, если у вас уже есть пресеты в ControllerMate).

В качестве плеера я использую Swinsian,  и у него нет шорткатов для регулировки громкости. Конечно, их можно создать через System Preferences, но зачем плодить сущности? При нажатии на клавишу эмулировать нажатие других клавиш, чтобы отрегулировать громкость - это как-то громоздко. Правда, команд "сделать громче/тише" для AppleScript у него тоже нет, только возможность задания значений от 0 до 100. Возиться со счетчиками не хотелось, поэтому почему бы не эмулировать нажатие соответствующего пункта в меню плеера?

Создаем внутри группы пресетов для нашей клавиатуры еще одну группу, я назвал ее аналогично названию плеера,  указывем, что группа будет активна, когда запущен плеер, при этом не забываем справа от названия плеера поменять параметр на "Foreground or Background", иначе ничего не будет регулироваться, если окно плеера не является активным.


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

В окне инспектора выбираем нужную нам клавишу (точнее, достаточно один раз на нее нажать и она выберется сама). После этого добавляем новый блок, на этот раз выбираем "AppleScript - AppleScript". Чтобы не плодить файлы, выбираем, что скрипт храниться будет тут же, текст скрипта для Swinsian будет таким:

tell application "System Events" to tell process "Swinsian"
         click menu item "Increase Volume" of menu "Controls" of menu bar 1
end tell

После этого связываем созданные блоки, проделываем аналогичную процедуру для кнопки увеличения громкости, заменив Decrease на Increase соответственно.

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

Надеюсь, объяснение получилось не очень путаным.
Готовый файл конфигурации для ControllerMate можно скачать здесь.

А вообще, всем пользователям OS X, еще не знакомым с AppleScript и Automator рекомендую обратить внимание на два этих прекрасных инструмента, позволяющих автоматизировать, наверное, даже самые нетривиальные процедуры в системе.

28 марта, 2013

plesk, spamassasin и нестандартная директория для почты

Этот plesk у меня никогда не закончится.

Когда я устанавливал панель (предварительно ознакомившись с документацией), из этой самой документации я не совсем правильно понял фразу
if you want to use a separate partition for Panel, mount the partition to /opt/psa/
Понадеялся, что все, что относится к плеску, будет установлено туда. Разметку диска производил соответственно. Но оказалось, что, например, почту он все равно собирается хранить в привычной директории /var/qmail/mailnames (даже если при установке мы выбрали postfix и никакого qmail'a у нас нет). Переустанавливать и переразмечать все это хозяйство очень не хотелось, т.к. это требовало еще и поездки в дата-центр (сервер не был подключен к IP-KVM, а IMM у него был без лицензии на эту фичу). Путем недолгого гугления нашлась вот эта статья на сайте Parallels. Немного смутило то, что она для 9 и 10 версий, но про 11 ничего найти не удалось.

Выполнил все, как было написано в статье, после чего смигрировал аккаунты на этот сервер. Все хорошо, почта лежит там, где я это указал в /etc/psa/psa.conf и ничего не предвещает беды.

Но когда дело дошло до spamassasin, все пошло не так. Суть в том, что вроде он и работает, но явный спам проскакивает во входящие, так к нему еще и почему-то не добавляются заголовки от SA. При этом заголовки вполне себе присутствуют в легитимных письмах.

В логах нашлось следующее:
spam_hook[32577]: Exiting with exit code: 75
spam_hook[32577]: Unable to delivery message into Spam folder

Как это? Почему нельзя? Непонятно. Директория есть, права есть, все вроде хорошо.
На директиву save в user_prefs, кстати, spamassasin не реагировал.

Тут-то я и вспомнил о перемещении Maildir'ов, о котором писал в начале.
В результате проблему удалось решить одной короткой командой:
ranzhe@plesk:~$ sudo ln -s /opt/psa/mail/mailnames /var/qmail/mailnames

Т.е. где-то в хуке для spamassasin'a безобразно захардкодили путь, из-за чего оно и не работало.
Вот и верь после этого документации.

26 марта, 2013

И снова plesk, теперь file (fail?) sharing

В общем-то, я наверное даже готов поверить в то, что все мои проблемы с плеском - следствие миграции с 9.5.4 на 11.0.9, но на то были свои причины и выбора особо не было.

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

unable to execute file-sharing : empty error message from utility

Но вот ведь какое дело: на старом сервере не было никакого файл-шаринга, да и не нужен он и на новом, но попытки отключить его путем снятия соответствующих галок в настройках панели (Server - File Sharing - Enable Public Files) заканчивались тем, что галки эти после перезагрузки страницы опять возвращались на место.

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

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

Решилась проблема следующим образом:

ranzhe@plesk:~$ sudo /opt/psa/admin/sbin/file-sharing --sync

Точнее, не совсем. При попытке выполнить этот самый синк (а делается это php-скриптом), php отваливался из-за превышения лимита памяти, мол 128 мегабайт не хватает. Но чего не сделаешь ради хорошо дела? Вот только оказывается, что выполняется это все не просто через php-cli, конфиг которого в дебиане/убунте лежит в привычном /etc/php5/cli/php.ini, а через sw-engine-cgi, у которого свой php.ini, и путь к нему такой:

/opt/psa/admin/conf/php.ini

После увеличения лимита памяти sync отработал без ошибок, и file sharing перестал ругаться на то, что я "недостаточно прав", и вообще позволил наконец-таки отключить себя. Больше он меня не беспокоил.

17 марта, 2013

Легкий способ сделать SRS в postfix

В наше время все чаще встречаются почтовые серверы, проверяющие SPF очень строго. С учетом количества спама, гуляющего по сети, администраторов этих серверов можно понять. Но  можно столкнуться с такой ситуацией: письмо поступает с mail1@example.com на mail2@example2.com, проходит все проверки, и все хорошо. Но на сервере example2.com стоит правило "форварднуть письмо на mail3@domain3.com". Сервер example2.com начинает пересылку, но сервер domain3.com видит, что письмо от mail1@example.com пришло от сервера example2.com, который, по результатам проверки SPF, не имеет никакого права слать такую почту.

Для исправления ситуации существует SRS (Sender Rewrite Scheme). И мой любимый exim умеет это из коробки, а вот postfix - нет. Но иногда эксим прикрутить нельзя (например, у нас панель управления, которая работает только с постфиксом). Можно, конечно, написать rewrite map, и переписывать FROM на сервере example2.com, но если у нас тысяча с лишним ящиков, что делать?

Реализаций SRS для postfix существует великое множество, но многие из них требуют патча исходников либо достаточно сложны в прикручивании к уже имеющейся системе.

Но есть простое решение, появившееся не так давно. Называется postsrsd.

Тем, у кого используется ubuntu server, достаточно сделать следующее:

add-apt-repository ppa:roehling/stable
aptitude update
aptitude install postsrsd

Остальные могут сходить на github и забрать исходники для самостоятельной сборки

Дальейшая настройка предельно проста. При установке генерируется ключ, нужный для подписания писем, которые мы будем форвардить. Остальные настройки есть в /etc/default/postsrsd. Мне понадобилось сменить порты, которые слушает демон, т.к. дефолтные уже были заняты.

В конфиг постфикса пишем следующее:

sender_canonical_maps = tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes= envelope_recipient

После этого убеждаемся, что postsrsd запущен и релоадим postfix. Готово.

14 марта, 2013

Plesk и политика паролей в Horde

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

Раньше политика паролей на сервере позволяла задавать любые пароли, но после того, как некоторые неплохо так проспамились со своих адресов, было принято решение повысить требования к паролям.

Да, настройки это позволяют, хоть и не очень гибко:



И вроде все хорошо, панель больше не позволяет создать/сохранить простой пароль.

А теперь заходим в web-интерфейс почты (по умолчанию Plesk ставит Horde), выбираем в дереве слева "My Account" - "Password" иии... Да, пароль можно сменить на любой, сложность никто не проверяет. То есть пользователь, не желающий заморачиваться со сложным паролем, может просто пойти и задать себе любой. Отлично.

К счастью, в Horde предусмотрена проверка сложности для нового пароля (вот тут совсем не понятно, почему же тогда это не задействовали?). Не нашел способа получить через CLI от панели значение для действующей политики, поэтому просто забил руками параметры в файл

/usr/share/psa-horde/passwd/config/backends.php

Изначально там у единственного доступного бэкенда стоит значение
'password policy' => array(),
меняем на
'password policy' => array(
      'minLength' => 10,
      'maxSpace'  => 0,
      'minUpper'  => 1,
      'minLower'  => 1,
      'minNumeric' => 1,
      'minSymbols' => 1,
    ),

Готово.

Думаю, объяснять, какой парамтер в данном случае что означает особого смысла нет, догадаться нетрудно.

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

08 декабря, 2011

CentOS 6 и Adaptec ASR-6405E

Надо наконец с чего-то начать, поэтому напишу про трудности взаимопонимания между CentOS 6 и адаптековскми контроллерами 6405E.

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

Но у проблемы есть решение.

Нам понадобится лишь удаленный сервер, на который мы положим небольшой (1.4 мегабайта) файлик образа дискеты с драйвером. Архив с драйверами можно взять здесь, оттуда нам понадобится aac_RHEL6.img


Установку ОС я провожу по сети. В какой-то момент инсталлятор спрашивает, хочу ли я продолжать сетап в текстовом режиме или же мне больше по душе VNC. Т.к. в шестой центоси в текстовом режиме напрочь отсуствует режим ручной разметки диска, в любом случае выбираем VNC.

После этого переключаемся на второй терминал (ALT+F2) и подгружаем драйвер:

cd /tmp
mkdir aacraid 
wget http://адрес_нашего_сервера_с_образом_дискеты/aac_RHEL6.img
mount -o loop ./aac_RHEL6.img aacraid
cd aacraid
./fc-pre-install.sh
Скрипт отрапортует о том, что драйвер установлен. Переходим в VNC и видим, что всё увиделось и распозналось. Устанавливаем систему как обычно, но перед перезагрузкой останавливаемся и возвращаемся обратно во вторую консоль 

#тут я точно не помню полный путь, но начинается он с директории, именованной по версии ядра
cp -f %версия_ядра%/aacraid.ko /mnt/sysimage/lib/modules/%версия_ядра%/kernel/drivers/scsi/aacraid/
chroot /mnt/sysimage /bin/bash
source /etc/profile
gzip /boot/initramfs-%версия_ядра%.img
mkinitrd /boot/initramfs-%версия_ядра%.img `uname -r`

Готово. Возвращаемся в vnc и перезагружаемся. Стоит сказать, что перед обновлением ядра хорошо бы подключить репозиторий с сайта адаптека, чтобы не пришлось впоследствии ручками каждый раз пересобирать initramfs