Topic: Мануал по установке bitcoind на бесплатный Amazon EC2 (Read 13896 times)

http://eu1.bitcoincharts.com/blockchain/

Lexiko, все правильно по бэкапам написал. В гугле можно еще over 9000 вариантов найти, тот же rsync, например, + самому придумать столько же. Можно хоть вручную все качать раз в неделю.

В смысле? На Амазон? Качал на другом сервере через bitcoind , а потом просто перенес базу в архиве. Можно было и полностью качать, но это лишние i/o операции.

Где-то видел ссылку на ежедневный слепок базы, если кто вспомнит, поделитесь плз.

База блоков закачивалась вручную или клиентом?

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

Мой вариант бакапа. Делаем задание для крона, которое :
а). будет заставлять демона сделать копию кошелька
б). Будет паковать этот кошелек с ядреным паролем и для особых параноиков, шифровать поверху ключом
в). Ложить запакованный файл в определенную папку, единственнодоступную специально для этого созданному юзеру, например bit_baker

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

С удаленного компьютера делаем также кроном:
scp -i приватный.ключ  wallet.bak [email protected]:/backups

Все! на сервере крон будет по интервалу создавать копию , шифровать, а со второго сервера этот файлик будет стандартно забираться по тому же интервалу.
Для этого не нужно каких-то сторонних сервисов по типу фтп + ssh безопасный протокол.

Минимизация рисков, в том числе рисков человеческих ошибок, это важная часть работы настоящего инженера.
Я предлагал рассмотреть вариант установки на двух виртуалках - сайт на EC2, данные на S3.
Считаю, что за это предложение меня надо похвалить, а не поругать.

Уважаемые, ну хватит уже перецитировать этот бред. Из-за того, что какой-то криворукий админ накосячил и грохнул виртуалку с кошельком обвинять весь облачный хостинг это мягко говоря неправильно.
О криворукости говорит уже тот факт , что он не сделал резервной копии кошелька перед началом каких-либо операций. Удаленный бакап кошелька делается ОДНОЙ шелловской коммандой, настроить ее в крон дело 5 минут. Умереть может любой сервер в любом ДЦ, чтобы избежать вышеописанных проблем и придумали бакапы, если вы их не делаете, то сами себе ЗБ.

Хотел добавить памяти, случайно грохнул виртуалку. Амазон ни чем не смог помочь. Интересно, а чем они могут помочь, если при удалении виртуалка полностью уничтожается? Понятно что его деликатно кебенизировали.  Ни кто не будет хранить удаленные виртуалки вечно, даже из соображений безопасности.
Точно также как это делают обычные vps/vds провайдеры. По крайней мере нормальные ДЦ после того как снимают ваш сервер с обслуживания жестко форматируют хард.
Многие (большинство) ДЦ также могут отформатировать хард , после 5-7 дневной неоплаты. на амазоне же у меня простроченная виртуалка болталась несколько месяцев, а амазон терпеливо просил ее оплатить.

Какая-то биржа у нас уже навернулась из-за того, чтоб хостилась на облаке и не реплицировала записи кошелька

UPD: bitomat.pl (Over 17,000 Bitcoins Missing)

Bitomat, Poland-based third largest Bitcoin exchange,
announced that as of July 26 they lost access to their wallet.dat file
and thus the exchange’s entire fund base has become inaccessible.

they were using Amazon Web Service’s Elastic Cloud Computing (Amazon EC2) network
and held all of their information, including the wallet file
for the exchanges bitcoins in a virtual machine.


UPD2:
я не читал статью внимательно и не проникся, как именно используется Amazon S3 (он вроде бы данные терять не должен). Если в статье используется только он, то еще надо описать связь между сайтом на EC2 и базой на S3 (как эта связь шифруется и всё такое)

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

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

Для тех, кто только что переключился , демон необходим для автономного осуществления организации приема BTC на своем ресурсе (серверная часть).
Тут можно посмотреть живой пример https://bitcointalksearch.org/topic/btc-60144 и скачать исходники клиентской части, непосредственно встраиваемой на ваш сайт. Если у вас уже есть свой сервер, можете перейти сразу к шагу 8, иначе читаем ниже.

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

• Виртуальный сервер в формате micro на основе Linux/Windows с доступом по SSH/RDP.
• 30Гб места в Elastic Block Storage 2 млн обращений к диску, плюс 1Гб под бэкапы.
• 5 Гб of Amazon S3 , 20,000 Get запросов, and 2,000 Put запросов
• 15 Гб трафика в месяц.
• Выделенный внешний IP адрес.

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

Шаг 1: Регистрируемся на Amazon.

Процедура регистрации обычно не вызывает вопросов. Единственный совет — вводить реальные или близкие к реальным данные. Семенов Горбунковых с улицы Горького давно не регистрируют, а если неправильно указать индекс города, то система даст скрытый отлуп на этапе проверки кода по телефону.
Перед тем как вбивать данные кредитной карты, нужно убедиться что по ней доступно для снятия минимум 85р для Mastercard и 75р для Visa. В зависимости от региона и типа кредитной карты в конце процесса регистрации нас могут попросить подтвердить свой сотовый телефон. Тут правил 3 — вписывать номер нужно без восьмерки и кода страны (10 цифр), не забывать правильно выбирать страну и начинать вводить код с клавиатуры только после того как синтезированная телефонная барышня перестанет говорить и затаится в ожидании. Если подтвердить не попросят, значит Амазону очень понравилась ваша кредитка и у них еще еще не было проблем с пользователями из вашего диапазона адресов. Но поскольку нас больше всего интересует сервис EC2 (для которого верификация обязательна), то подтверждать 4 цифры по телефону придется в любом случае. После регистрации с карты снимут 1 доллар (и потом его не вернут) и сразу предоставят доступ к сервису хранения файлов S3 и к шикарной консоли управления



Шаг 2: Подготовка к созданию EC2 сервера.

Прямо со страницы управления S3 можно щелкнуть по верхней закладке EC2 и согласиться на добавление этого сервиса к вашему аккаунту. Если на этапе проверки кредитки не перекинуло в процедуру проверки телефонного номера, то перекинет отсюда и нужно будет подтвердить. После подтверждения откроется примерно такая картина


а с карты спишется еще один доллар.

Шаг 3: Добавление пользовательской группы.

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



и назовем ее, например, basic.

После создания добавим несколько правил в закладке Inbound
Разрешим доступ по ssh для ip из подсети 1.1.0.0/16 (с этого адреса будет досутпен 22 порт)



По аналогии добавим порт , на котором наш RPC демон будет общатся с интерфейсом магазина 8332 (или другой). Ип 2.2.2.2 - адрес сервера , на котором находится магазин, подставите свой.
После каждого правила жмем Add Rule , а после того как добавлены все порты "Apply Rule Change". Если у нас будет работать только демон, остальные порты лучше не открывать из соображений безопасности.


Теперь наш сервер защищен от вторжений извне.

Шаг 4: Создание SSH ключей.

Ключи нужны для доступа на сервер по SSH и они могут быть созданы и в процессе развертывания образа выбранной ОС, но в IE и Chrome наблюдаются периодические глюки с отдачей файла ключей на скачивание. Поэтому лучше сделать это заранее и если заглючит, то повторить.
Для генерации ключей выбираем Key Pairs в меню и давим пару кнопок.

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

Шаг 5: Развертывание образа Операционной Системы.

Итак, у нас есть ключ и дополнительная пользовательская группа. Теперь можно смело нажимать Launch Instance из меню EC2 Dashboard.



Согласимся на Classic Wizard.

Далее выбираем себе подходящую ось. Для bitcoind сервера это не принципиально , дело вкуса.
Если вы приверженец Centos, Redhat, Suse, тогда выбирайте эти дистрибутивы из вкладки QuickStart ,
Мне больше нравится дистрибутив Debian 6 x64, под него я писал и все скрипты, если вам он тоже по душе, переходим во вкладку Comunity AIMs и вводим в поле поиска ami-e00df089  , после чего выбираем этот дистрибутив кнопкой Select.

Оставляем все установки по умолчанию.    


Включаем защиту от удаления.    


Теги вбивать не обязательно.


Будем использовать уже сгенерированные ключи.


В конфигурации фаервола оставляем только Security Group индекс-basic.


Проверяем установки и запускаем.


После запуска в списке Instances появится наш микро-сервер.

Шаг 6: Регистрируем IP адрес для сервера.

В меню Elastic IPs сначала резервируем себе IP адрес.


И тут же присваиваем его нашему запущенному серверу.


Обратите внимание что резервирование незакрепленного за работающим сервером IP адреса не входит в бесплатный пакет. За это придется платить по центу в час. Как только IP присваивается запущенному северу, он тут же становится бесплатным.
В нашем примере Амазон выдал серверу адрес 107.21.246.159 и в дальнейшем мы его будем часто использовать, но в вашем случае во всех действиях и командах его нужно будет заменять на адрес, который выдали лично вам.

Шаг 7: Подключаемся к серверу по SSH.

Для этой цели можно использовать массу разнообразных программ, но вся дальнейшая инструкция написана для виндового и бесплатного PuTTY(прямая ссылка на загрузку).
Из архива нам в первую очередь понадобится puttygen.exe. Запускаем, выбираем Conversions/Import key.


и пересохраняем приватный кей как SSH2 RSA .ppk файл. На этом этапе не помешает как следует запаролить ключ.


После этого запускаем putty.exe, вбиваем наш IP в поле Host Name.


в разделе SSH-Auth указываем путь к .ppk ключу.


и нажимаем кнопку Open. В окошке терминала не должно быть никаких сообщений об ошибках, а в предложение:
login as: ,нужно ввести ec2-user.



Шаг 8: Устанавливаем bitcoind демона.

Далее уже обычный процесс установки демона, если вы устанавливали bitcoind на другие системы, можете с этим справится и тут. Я предложу свой скрипт для разворачивания демона.

• 1). Закачиваем к себе скрипт установки
  wget http://dl.dropbox.com/u/60284981/Bitcoin/install.zip (в архиве бинарник от linux x64 , если у вас другая операционка, соберите под нее свой или скопируйте готовый с оффсайта)
  и базу , состоянием на 01.02.2012 (около 1 гб)
  wget http://dl.dropbox.com/u/60284981/Bitcoin/bitcoin_base.zip
  * Примечание. Особенность облачных хостингов в том, что вы платите не фиксированную плату, а за фактически потребляемые ресурсы. В случае bitcoind таким ресурсом будут дисковые операции , которые ограничены 2 млн I/O в мес. Сервер тратит около 0,3 млн в сутки, каждый млн I/O операций сверх лимита стоит недорого 0,1$, всего в месяц за i/o заплатить около 0,50$-0,80$. Однако если сервер заставить качать все блоки с ноля, количество затраченных i/o на пуск сильно возрастет, поэтому я рекомендую сначала скачать базу целиком, а потом уже докачать оставшиеся блоки. Можете воспользоваться своим архивом , сделанным на локальном компьютере или взять мой.
• 2). Распаковываем и запускаем setup.sh (дав предварительно ему права на запуск chmod +x setup.sh)
  Действия , которые произведет скрипт:
  
  • а). Создаст пользователя bitcoin и группу bitcoin от которых будет запускаться демон
  • б). Скопирует файл конфигурации /etc/bitcoin/bitcoin.conf
  • в). Скопирует демона в папку /usr/local/bin/
  • г). Развернет базу в папку /var/lib/bitcoin/
  • д). Скопирует скипт автозапуска в  /etc/init.d/
  • е). Установит все необходимые права

• 3). Последний штрих, подредактируем /etc/bitcoin/bitcoin.conf
  вместо rpcallowip=107.21.246.159 пропишите ваш ип адрес, выданный Amazon
  также обязательно добавить строку с ип адресом вашего сервера , который будет обращатсья к демону  rpcallowip=2.2.2.2 ну и опционально ип вашего рабочего компьютера.
  rpcuser=xxx
  rpcpassword=xxx
  таже замените на свои , при желании можете сменить порт
  4). Запускаем демона /etc/init.d/bitcoin start
  посмотреть лог в реальном времени можно коммандой tail -f /var/lib/bitcoin/.bitcoin/debug.log
  

P.S. Отдельного пользователя под демона можно не создавать, но все же лучше перестраховаться. Папки также можете разместить где вам удобно, не забыв  подредактировать скрипт автозапуска /etc/init.d/bitcoin

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

P.P.S. Пользование демоном практически полностью вкладывается в бесплатные лимиты http://aws.amazon.com/free/ . Перерасход , как было сказано выше, идет лишь по дисковым операциям, за которые прийдется заплатить сущие копейки (около 50-80 центов в мес).
Пользоваться таким хосингом можно целый год, после чего перерегистрировать на другую карту или оплачивать платные услуги . По моим подсчетам месячная плата, по окончанию бесплатного года, не превысит 4-5$ , что вполне приемлимо, ибо это цена обычного шаред хостинга, за полноценный сервер.
Нагрузка на процессор у меня не превышала несколько %, так что вы можете использовать данный сервер и под другие нужды, хотя с точки зрения безопасности этого делать не желатыльно.
Перерасходов по трафику также небыло, демон расходует около 10-20% от бесплатных лимитов.

В статье были использованы материалы взятые из статьи http://habrahabr.ru/blogs/hosting/135713/ с согласия автора.

(c) Вы можете свободно использовать и перепечатывать данный материал в своих целях с указанием ссылки или без.
Удачной работы!