В качестве торрент-качалки у меня работает transmission, установленный на прошитый DD-WRT роутер DLink DIR320. Сложности с удаленным доступом из корпоративных сетей навели меня на мысль реализовать добавление закачек через email. Поиск готовых решений выдал связку mpop/fetchmail — procmail — munpack. Пакеты были установлены, rc-файлы написаны, cron дополнен новым заданием, и роутер начал успешно скачивать почту со специально заведенного аккаунта. Однако, наладить нормальную работу всей связки мне так и не удалось. Но задача была все-таки решена при помощи простого скрипта.
Итак, задача выглядела следующим образом: получить почту и сохранить вложенные в письма torrent-файлы туда, где их увидит transmission — в моем случае в /mmc/transmission/watch.
Для скачивания почты я использовал менее требовательный к ресурсам mpop, но fetchmail будет работать ничуть не хуже. Как и любой другой pop-клиент.
mpop по умолчанию сохраняет почту в /var/spool/mail/$USER. В моей конфигурации это /opt/var/spool/mail/root. Собственно, для решения задачи достаточно было бы одной строки mpop & munpack /opt/var/spool/mail/root -C /mmc/transmission/watch, запускаемой через cron. Но, во-первых, это лишняя нагрузка на слабое железо — я же не постоянно буду слать торенты, зачемзря munpack гонять. Во-вторых, при такой реализации в папку, за которой следит transmission, будет сыпаться всякий мусор, что тоже не есть правильно. В-третьих, в этом случае входящие письма не удаляются из почтового ящика, и, соответственно, вложения будут вновь сохраняться при каждом запуске скрипта, захламляя папку слежения.
Соответственно, возникли 3 промежуточных шага:
1) по стандартному выводу mpop определить, есть ли новые письма;
2) сохранить вложения во временную папку и уже оттуда перенести только файлы *.torrent в папку назначения;
3) удалить обработанные письма и, за ненадобностью и для надежности, все невостребованные вложения.
В результате родился скрипт, фактически заменивший собой procmail:
Конечно, при использовании procmail можно было бы сразу фильровать входящие письма и сохранять только те файлы, которые пришли с определенного адреса и с определенной темой. Но я пока не вижу, чем мне может навредить присланный гипотетическим злоумышленником на незасвеченный адрес файл, ненадолго сохраненный во временной папке без прав на выполнение.
PS: На очереди — реализация добавления закачек через RSS. Очень заманчиво было бы одним щелчком добавлять страницы с раздачами в readitlater (что я и так частенько делаю), зная, что верный скрипт сам скачает torrent-файл и поставит его на закачку.
Итак, задача выглядела следующим образом: получить почту и сохранить вложенные в письма torrent-файлы туда, где их увидит transmission — в моем случае в /mmc/transmission/watch.
Для скачивания почты я использовал менее требовательный к ресурсам mpop, но fetchmail будет работать ничуть не хуже. Как и любой другой pop-клиент.
mpop по умолчанию сохраняет почту в /var/spool/mail/$USER. В моей конфигурации это /opt/var/spool/mail/root. Собственно, для решения задачи достаточно было бы одной строки mpop & munpack /opt/var/spool/mail/root -C /mmc/transmission/watch, запускаемой через cron. Но, во-первых, это лишняя нагрузка на слабое железо — я же не постоянно буду слать торенты, зачемзря munpack гонять. Во-вторых, при такой реализации в папку, за которой следит transmission, будет сыпаться всякий мусор, что тоже не есть правильно. В-третьих, в этом случае входящие письма не удаляются из почтового ящика, и, соответственно, вложения будут вновь сохраняться при каждом запуске скрипта, захламляя папку слежения.
Соответственно, возникли 3 промежуточных шага:
1) по стандартному выводу mpop определить, есть ли новые письма;
2) сохранить вложения во временную папку и уже оттуда перенести только файлы *.torrent в папку назначения;
3) удалить обработанные письма и, за ненадобностью и для надежности, все невостребованные вложения.
В результате родился скрипт, фактически заменивший собой procmail:
#!/bin/sh
if [ -z `mpop | grep 'new'` ]; then
exit
else
mkdir /tmp/attachments
munpack /opt/var/spool/mail/root -C /tmp/attachments
mv /tmp/attachments/*.torrent /mmc/transmission/watch
rm -r /tmp/attachments
rm /opt/var/spool/mail/root
fi
Конечно, при использовании procmail можно было бы сразу фильровать входящие письма и сохранять только те файлы, которые пришли с определенного адреса и с определенной темой. Но я пока не вижу, чем мне может навредить присланный гипотетическим злоумышленником на незасвеченный адрес файл, ненадолго сохраненный во временной папке без прав на выполнение.
PS: На очереди — реализация добавления закачек через RSS. Очень заманчиво было бы одним щелчком добавлять страницы с раздачами в readitlater (что я и так частенько делаю), зная, что верный скрипт сам скачает torrent-файл и поставит его на закачку.