Более идиотского решения я еще не видел. Объема кассет для бекапов критически не хватало и он, как мудак бегал 2 раза в день переставлять кассеты. Они, к слову, должны хранится отдельно от серверов, на случай пожара или грабежа,  но по факту лежали в соседней к серверной комнате. В итоге толку ноль, пафоса море, можно сидеть пилить дальше.

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

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

И вот недавно звонит мне вождь этого офиса (сидящий, кстати, на верху) и сообщает что нижнюю часть надо срочно закрывать, да и верхняя тоже скоро съедет. Я поднял панику и пытался или оттянуть переезд до полного съезда или хотя бы перевести 15й на 8й, а не наоборот. Но ничего не вышло, более того, направив вождя выяснять реально ли перенести подключение телефонии и инета на верх, узнал, что стоить это будет много.

Решение было принято простое и очень колхозное: на 8м скручиваю инетный кабель и телефонные с кабелями идущими на верх, прячу скрутки в вентиляционный канал (откуда они и приходят) и оставляю под крышкой вентиляции бумажку с матерными угрозами не рвать скрутки и своим мобильным на всякий случай. Это было легко. А на верхнем этаже оказалось очень тесно, почти все нужно было уместить под фальш-потолком (такое гавно квадратиками) с осветителями, при этом часть ламп держалась не на анкерах к нормальному потолку, а просто лежало на алюминиевых уголках, туда же положил атску и пытался забить кучу проводов со свичем. Естественно это не могло закончится хорошо :) В один момент я задел жопой кабель идущий к атс и она утянула за собой 4 потолочные панели и светильник. Все это говно эпично повисло на проводах. Ремонтировать я ничего не стал, закинул атс подальше, кое как скрутил провода и разобрав висящий в воздухе светильник закинул его на тот же фальшпотолок. Все работает, все довольны, хорошо не пытался сервер забить туда же :)

P.S. Надпись над столом (там сидит дама-манагер) сделал я, она хотела ее замазать, а вождь сказал -»не надо, она меня мотивирует!».

Склад: Игорь,это Наташа с фурнитуры……а у тя есть краска для СКАНЕРА?
ivg: o.O
Склад: что?
ivg: Что и для чего тебе нужно?
Склад: у меня стоит сканер,а краска закончилась

WTF?

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

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

Причина в большой фрагментации файлов скачиваемых через 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 :)

И немного лирики, зачем все это нужно. Я давно храню и скачиваю варез, фильмы и музыку исключительно на шифрованные носители, в России мы живем с безумной правоохранительной системой с которой вы, скачавший и поставивший куда либо Photoshop или записавший на диск свеже скачанный фильм — являетесь уголовным преступником, совершившим тяжкое преступление, до 6 лет лишения свободы однако. Если убить кого нибудь в состоянии аффекта — и то меньше.

Собственно начнем, попутно расписав нюансы. Суть — 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 есть, но динамический. Для простоты пускай там тоже будет виндовс.

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