еще про Transmission и eCryptfs

В settings.json есть еще один полезный параметр способный защитить комп от самопожирания дисковыми запросами — peer-limit-global или в десктопной версии в настройках (GUI) Maximum peers overall.

Этот параметр ограничивает количество соединений с другими торрент клиентами и как следствие снижает фрагментацию записи или чтение файлов. На сервере ограничил тем же числом что и количество соединений на каждый торрент (peer-limit-per-torrent) т.е. 60. Методом тыка выяснено что это спасает однодисковый комп от зомбирования торрент клиента.

Тем у кого стоит мега RAID из 15 SAS дисков с пропускной в 200 мб/с думаю вообще ничего ограничивать не придется :)

Transmission & eCryptfs

Пользователи торрент клиента Transmission (да и многих других клиентов p2p) при попытке скачать файл большого размера в каталог зашифрованный eCryptfs получали чудовищную нагрузку диска, а затем сожравший 100% CPU процесс клиента, который, при попытке его прибить превращался в зомби.

Причина в большой фрагментации файлов скачиваемых через bittorrent, шифрованная файловая система не успевает за запросами на чтение и запись в разные части файла, получаются очереди которые в конечном итоге забивают весь обмен с диском и загружают CPU. Спасение из данной ситуации — кеш.

Начиная с версии 2.10 в Transmission появился параметр cache-size-mb с переменной по умолчанию — 2. Т.е. кеш равен 2 мб, что по нынешним меркам просто смешно, его и надо увеличить для стабильной и быстрой работы.

Итак, что делаем (на примере Ubuntu 10.10):

1. обновляем Transmission, добавив репозиторий со свежими версиями:

sudo add-apt-repository ppa:transmissionbt/ppa

sudo apt-get update

sudo apt-get upgrade

(если у вас сервер и нет add-apt-repository - поставьте его: sudo apt-get install python-software-properties)

2. Если Transmission обычны, десктопный - просто закрываем его. Если используется серверный transmission-daemon — останавливаем его:

service transmission-daemon stop

3. Открываем файл конфигурации, если серверный transmission-daemon:

sudo nano /etc/transmission-daemon/settings.json

Если обычный (внимание — тут sudo не нужно!):

nano .config/transmission/settings.json

4. Находим там строку «cache-size-mb»: 2, и меняем 2 на сколько не жалко памяти :) Лично я на сервере выделил половину ОЗУ — 512, на ноутбуке же всего 64 и похоже хватает. Напоминаю что выход из nano — Ctrl+x :)

и немного лирики, зачем все это нужно

Решение задачи об обратном подключении

Итак, как я уже писал, есть сервер к которому невозможно подключится извне, а очень хочется :)

Собственно начнем, попутно расписав нюансы. Суть — VNC reverse connection, т.е. сервер будет сам искать нас и подключаться что бы мы им поуправляли.

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

Теперь немного теории, если на управляющей машине запустить vnc viewer, указав какой нить порт и запустив Listening mode,

то клиент становится как бы сервером и слушает этот порт, а на сервере (после запуска клиента!) сообщаем vnc службе к какому ip и порту лезть

Вуаля! На клиенте внезапно открывается десктоп сервера. Кажется все просто — суем команду на запуск подключения службы сервера в шедулер и пускай ломится к нам хоть каждую минуту. Но, не тут то было, vnc viewer даже после подключения сидит и слушает порт, а значит запустив его один раз что бы поработать мы будем получать каждую минуту еще одно окно с нашего сервера, достанет быстро. Что делать? Это и есть первый нюанс.

Вывод — нужно что бы сервер отслеживал наличие связи с нами, и только если ее нет — пытался подключится, а значит в шедулер мы суем уже не команду для vnc службы, а некий скрипт, который будет смотреть в netstat и думать :)

Нелегко даются cmd скрипты линуксоеду, но все же вот такое родилось:
del vncstat
netstat -a -n | findstr "10000" | more > vncstat
for /F "tokens=4" %%i IN (vncstat) DO (if %%i==ESTABLISHED (exit /B))
"C:\Program Files (x86)\TightVNC\tvnserver.exe" -controlservice -connect 192.168.1.14:10000

192.168.1.14 — заменяем на ip или домен того места где у вас vnc viewer
10000 — заменяем на порт в vnc viewer

Обзываем это в духе vnc.cmd и в шедулер его.

Теперь второй нюанс — мы не всегда сидим за одним и тем же ip, а необходимость ковырять сервер может возникнуть в дороге когда у вас в руках ноут и gprs. Решается просто, главное что бы у вас был внешний ip — динамический днс.

Я выбрал freedns.afraid.org, удобно, зарегистрировал себе какой нить megaadmin.mooo.com, зашел в интерфейс когда надо подключится, ткнул линк и этот домен прицелен на тебя, осталось запустить вьювер и подождать.

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

Все, по всем вопросам в комменты, и лучше в stand-alone блог а не в ЖЖ, у меня там есть OpenID и Gravatar и прочая цивилизация :)

Интересная задачка

Условия:

Компьютер подключен к интернету через NAT и не имеет внешнего IP адреса, за компьютером никто не сидит — это сервер. Windows Server 2008 R2.

Необходимо:

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

У задачки есть простое решение, но с двумя нюансами. Следующим постом решение в картинках :)

переезд

Достало ухаживать за красной шапочкой в ВПСке, да и 14 баксов в месяц для меня сейчас много. Перенес все на Host Gator, 10баксов, места анлим, канал тоже, админить ничего не надо, красота :)