Zabezpieczenie jetty

W mojej aplikacji Ruby on Rails używam gema Sunspot, który to używa RSolr do komunikacji z serwerem Solr. Solr to serwer bazujący na indeksie Lucene, który świetnie nadaje się do wyszukiwania pełnotekstowego.
Domyślna instalacja Sunspot posiada kopię Solr'a, którą można uruchomić na jetty. Jetty domyślnie uruchamia się na porcie 8983 i można podglądnąć sobie panel administracyjny Solr'a wchodząc na adres: http://localhost:8983/solr/admin/

Wszystko fajnie gdy pracuje się na localhost, jednak na serwerze produkcyjnym nie jest mile widziane aby każdy miał dostęp do wspomnianego panelu.

Najpierw próbowałem zabezpieczyć port 8983 dla ruchu z poza mojego serwera, chciałem użyć do tego ufw niestety moje zdolności administratorskie nie są na tyle dobre aby to poprawnie skonfigurować.

Następnie zastanawiałem się czy jest możliwość konfiguracji jetty, aby odpowiadała tylko dla zapytań z konkretnego hosta. Okazało się, że można to skonfigurować, oto instrukcja:

1. w pliku konfiguracyjnym jetty jetty.xml - w moim przypadku ścieżka to:

/usr/local/ruby/lib/ruby/gems/1.9.1/gems/sunspot-1.2.1/solr/etc/jetty.xml

view raw jetty_path.txt hosted with ❤ by GitHub

odnaleźć fragment:

<Call name="addConnector">

view raw jetty_addConnector.xml hosted with ❤ by GitHub

2. dodać następującą linię

<Set name="Host"><SystemProperty name="jetty.host" default="127.0.0.1"/></Set>

view raw jetty_host.xml hosted with ❤ by GitHub

przed linią

<Set name="port"><SystemProperty name="jetty.port"/></Set>

view raw jetty_port.xml hosted with ❤ by GitHub

3. zrestartować serwer jetty i nasz panel solr powinien już być zabezpieczony.

whenever - zarządzaj crontab za pomocą Ruby

Zgodnie z obietnicą opiszę jak skonfigurować crontab za pomocą gem'a whenever.

W poprzednim poście mowa była jak utworzyć backup bazy MySql za pomocą gem'a backup i wysłać go do Amazon S3.

Przydałoby się zautomatyzować ten proces aby wykonywał się przynajmniej raz dziennie.

Oto jak można to zrobić za pomocą gem'a whenever.

Pominę proces instalacji, gdyż jest to bardzo dobrze opisane na stronie projektu.

Po komendzie wheneverize . został utworzony plik config/schedule.rb, w tym pliku należy wpisać własne zadania, które chcemy wykonać na naszym serwerze.

Moim celem było utworzenie taska, który będzie wykonywał się codziennie i który będzie wywoływał komendę:

backup perform -t test_backup

view raw perform hosted with ❤ by GitHub

Zgodnie z dokumentacją napisałem coś takiego:

	every 1.day, :at => '01:15 am' do
	command "backup perform -t test_backup -c /path/to/backup/config.rb"
	end

view raw schedule_v1.rb hosted with ❤ by GitHub

Jeśli używamy domyślnego pliku konfiguracyjnego dla gem backup, to możemy w komendzie pominąć paramter -c oraz ścieżkę do pliku, można jednak wskazać konkretny plik, gdzie mamy zdefiniowany nasz Backup::Model test_backup.

Po wrzuceniu tego na serwer okazało się, że cron nie rozumie polecenia backup. Trzeba było odpowiednio ustawić zmienną PATH, poniżej jeszcze raz plik schedule.rb wraz z dodatkowymi ustawieniami:

	env :PATH, '/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/ruby/lib/ruby/gems/1.9.1:/usr/local/ruby/bin'
	env :SHELL, '/bin/bash'
	env :MAILTO, 'your@email.com'
	every 1.day, :at => '01:15 am' do
	command "backup perform -t test_backup -c /path/to/backup/config.rb"
	end

view raw schedule_v2.rb hosted with ❤ by GitHub

Cron po każdym uruchomieniu taska wyśle podsumowanie na adres email, który został ustawiony w zmiennej :MAILTO.

To wszystko. Cron działa, backup się wykonuje. Bardzo podoba mi się, to, że taski cron są zdefiniowane wraz z projektem Rails. Jeśli używa się capistrano do deployment'u to warto dodać do pliku deploy.rb task, który będzie aktualizował crontab po każdym wypuszczeniu nowej wersji aplikacji:

	namespace :deploy do
	desc "Update the crontab file"
	task :update_crontab, :roles => :db do
	run "cd #{release_path} && whenever --update-crontab #{application}"
	end
	end

view raw deploy.rb hosted with ❤ by GitHub

Amazon S3 i backup

Dzięki Ruby5 ponownie znalazłem fajne narzędzie, tym razem do robienia backup'ów.

Gem backup ma za zadanie robić backup'y (bazy danych, plików) i wysyłać je tam gdzie sobie tego zażyczymy (ftp, Amazon S3, itd).

Spodobała mi się opcja wysyłania backup'u bazy MySql na Amazon S3.
Nigdy wcześniej nie korzystałem z Amazon S3, można tam założyć konto, które będzie darmowe do momentu gdy miesięcznie nie przekroczy się następujących parametrów:

• 5 GB of Amazon S3 storage
• 20 000 Get Requests
• 2 000 Put Requests

Sądzę, że na początek to w zupełności wystarczy.
Więcej info odnośnie darmowego serwisu Amazon: AWS free

OK, mamy konto S3, należałoby utworzyć jakiś bucket na S3 - należy zalogować się do
https://console.aws.amazon.com - nazwę naszego bucket'a ustawiamy na 'test'.

Potrzebujemy jeszcze access_key_id oraz secret_access_key, są do pobrania z:
https://aws-portal.amazon.com

Teraz czas na gema backup, instalacja:

gem install backup

view raw install hosted with ❤ by GitHub

Generujemy domyślny plik konfiguracyjny:

backup generate --databases='mysql' --storages='s3' --compressors='gzip'

view raw generate hosted with ❤ by GitHub

Należy dostosować plik konfiguracyjny (domyślnie w ~/Backup/config.rb) do naszych potrzeb: nazwa bazy, użytkownika i hasło oraz nazwa regionu Amazon, ja wybrałem Europę - stąd wartość dla s3.region = 'eu-west-1'

	Backup::Model.new(:test_backup, 'test backup') do
	database MySQL do |db|
	db.name = "my_database"
	db.username = "db_user"
	db.password = "db_password"
	db.host = "localhost"
	db.port = 3306
	db.additional_options = ['--quick', '--single-transaction']
	end
	store_with S3 do |s3|
	s3.access_key_id = 'AMAZON_ACCESS_KEY'
	s3.secret_access_key = 'AMAZON_SECRET_ACCESS_KEY'
	s3.region = 'eu-west-1'
	s3.bucket = 'test'
	s3.keep = 7
	end
	compress_with Gzip do |compression|
	compression.best = true
	compression.fast = false
	end
	end

view raw config.rb hosted with ❤ by GitHub

Teraz możemy wykonać backup bazy:

backup perform -t test_backup

view raw perform hosted with ❤ by GitHub

...i mamy zrobiony backup!

W kolejnym poście postaram się opisać automatyzację tego rozwiązania za pomocą gema whenever.

Upgrade do Rails 3.0.5 paperclip i ... gdzie są moje zdjęcia?!?!

Tak jak zalecano zrobiłem upgrade na produkcji do Rails 3.0.5. Po wgraniu nowej wersji oraz po komendzie:
bundle update
gem'y rails zostały zaktualizowane.
Aplikacja (holidio) śmiga, jednak zauważyłem, że niestety nie wyświetlają się zdjęcia, które zostały wgrane za pomocą paperclip...
Hmm, nie zastanawiając się zbyt długo zrobiłem szybki rollback (dobrze, że korzystam z capistrano):
cap deploy:rollback
To przywróciło aplikację do poprzedniej wersji a mi dało trochę czasu na zastanowienie się co poszło nie tak...

Przypomniało mi się, że słuchając jednego z ostatnich podcastów Ruby5 chłopaki wspominali, że w Rails 3.0.5 poprawiono "pluralizację" oraz, że m.in. od teraz np. "media" w liczbie mnogiej dalej pozostaną "media", a nie jak to było wcześniej "medias"...
Ale co to ma wspólnego z moją aplikacją?
Ano ma, paperclip domyślnie używa katalogu "data" dla załączników. Ja potrzebowałem wielu załączników (zdjęć) do mojego modelu, więc załączniki te zostały zapisane w folderze "datas" (zła odmiana w liczbie mnogiej).
Po upgrade do Rails 3.0.5 aplikacja szukała zdjęć w katalogu "data"... a takiego folderu niestety nie miałem na serwerze... Aby to naprawić wystarczyło zmienić nazwę folderu z "datas" na "data" i sprawa załatwiona.
Gdybym potrzebował jednak utrzymać starą nazwę folderu, można przekazać paperclip parametr :path i dowolnie ustawić jego wartość.

Couldn't parse YAML at line - po update RubyGems do wersji 1.6.1

Wygląda na to, że połączenie Ruby 1.9.2 oraz najnowszej wersji RubyGems 1.6.1 domyślnie używa 'psych' jako parsera plików YAML...

Mi nie udało się zainstalować gem'a 'psych', więc trzeba było ustawić inny domyślny parser dla aplikacji.

W pliku boot.rb dodałem następujące linie:

require 'yaml'
YAML::ENGINE.yamler = 'syck'

Can't find gem rake ([">= 0"])

Dotyczy prawdopodobnie tylko Ruby 1.9.2 na Windows. U mnie problem zaczął się po próbie instalacji gem'a radiant (cms), który, wygląda na to, że niestety jeszcze nie działa pod Ruby 1.9.2.

Wystarczyło usunąć plik "rake.gemspec" z folderu:
C:\Ruby192\lib\ruby\gems\1.9.1\specifications
To załatwiło sprawę.