В Rails, ActionMailer предлагает нам два метода для отправки электронной почты: smtp и sendmail. Настройка метода отправки производится в config.action_mailer.delivery_method. Как следует из названий методов, отправка письма в MTA идёт либо через протокол SMTP, либо через вызов команды sendmail на сервере.

Если у вас включена отправка через sendmail и вы работает с Rails 3.x, есть тонкий момент.

Я уже писал как-то, что при тестировании rails-приложений, нужно очень внимательно следить за кэшем. Опция config.perform_caching = false работает только для caches_action в контроллерах и cache в шаблонах. Любые обращения к Rails.cache продолжают работать, потому что по умолчанию там живет AS::C::MemoryStore¹.

Конечно мы можем в #setup (TestUnit) или в #before(:each) (RSpec) каждый раз вызывать Rails.cache.clear. Но согласитесь, далеко не в каждом тесте это нужно, а гадать, где используется кэш, а где нет — это неудобно.

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

Решил переехать с Wordpress на Octopress.

Причины подобного шага вполне понятны:

1. Я хочу редактировать посты в нормальном редакторе, а не в убогом web-интерфейсе.
2. Мне надоело каждый раз обновлять сам Wordpress и десяток его плагинов каждую неделю.
3. Мне очень понравилась тема оформления Octopress: она минималистична, но функциональна и легко расширяема. А ещё блог теперь можно читать на смартфонах. Попробуйте прямо сейчас сузить ваш браузер до 300-400 пикселей в ширину.
4. В Octopress есть красивая подсветка синтаксиса кода из коробки (через pygments).
5. Octopress/Jekyll написан на ruby, а значит легко и приятно хакается.
6. Мне не надо держать больше на сервере PHP/MySQL/Apache 2!!!

Минус платформы Octopress/Jekyll только один — отсутствие динамического контента. Однако, современный уровень развития javascript легко компенсирует этот недостаток. Например, комментарии у меня теперь будут реализованы с помощью Disqus.

С выходом Ubuntu 10.04 настройка бесперебойного источника питания Ippon Back Comfo Pro стала проходить почти без всяких танцев с бубнами.

Ставим пакет nut и добавляем в /lib/udev/rules.d/52-nut-usbips.rules строчки (для вашего ИБП возможно надо будет поменять значения idVendor и idProduct, посмотрите через lsusb):

# Ippon
#  Ippon Back Comfo Pro 800
ATTR{idVendor}=="06da", ATTR{idProduct}=="0003", MODE="664", GROUP="nut"

Вытыкаем-втыкаем USB-кабель, чтобы пересоздать файл устройства.

Пишем в /etc/nut/ups.conf:

[ippon]
    driver = blazer_usb
    port = auto
    desc = "Ippon Back Comfo Pro 800"

sudo invoke-rc.d nut restart и проверим что выдаст команда upsc ippon:

$ upsc ippon
battery.voltage: 13.60
battery.voltage.nominal: 12.0
beeper.status: enabled
device.type: ups
driver.name: blazer_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.4.3
driver.version.internal: 0.03
input.current.nominal: 3.0
input.frequency: 50.1
input.frequency.nominal: 50
input.voltage: 222.3
input.voltage.fault: 222.3
input.voltage.nominal: 220
output.voltage: 222.3
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 18
ups.productid: 0003
ups.status: OL
ups.temperature: 25.0
ups.type: offline / line interactive
ups.vendorid: 06da

Profit! Остальное настраиваем по собственному вкусу и желанию.

В новых версиях openssh (хотя не таких уж и новых, >= 4.9 если не ошибаюсь) есть возможность ограничить доступ пользователя в подсистеме sftp. Т.е. задать ему ChrootDirectory, как в proftpd. Например в домашнюю папку (ибо нефиг лазить за её пределами). Рассмотрим, как это можно реализовать.

Для начала, создадим группу sftpusers. Ограничения будут действовать только на пользователей из этой группы (мы ведь не хотим ограничивать пользователя root?):

addgroup --system sftpusers

Далее заменим подсистему sftp в /etc/ssh/sshd_config:

-Subsystem sftp /usr/lib/openssh/sftp-server
+Subsystem sftp internal-sftp

Ну и наконец запишем ограничения в тот же файл:

Match Group sftpusers
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Не забываем перечитать конфиг:

invoke-rc.d ssh reload

Теперь разберемся с пользователями. При создании пользователя не надо указывать ему шелл, так как он все равно не сможет им воспользоваться (см. ForceCommand internal-sftp). Поэтому указываем в качестве шелла /bin/false. Домашняя папка (точнее папка, которую мы указали в ChrootDirectory) обязательно должна иметь владельцем пользователя root. Иначе будем получать ошибку:

fatal: bad ownership or modes for chroot directory "/home/%username%"

А вот группу-владельца chroot-папки можно задать любую. Но главное условие - chroot-директория должна быть доступна на запись только для пользователя root и никого больше. В противном случае получим вышеприведенную ошибку.

Рассмотрим пример создания пользователя:

useradd -G sftpusers -s /bin/false -d /home/user1 user1
mkdir /home/user1
chown root:user1 /home/user1
chmod 750 /home/user1

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

ChrootDirectory /home

А внутри /home разруливать доступ к папкам, используя обычные права доступа.