logrotate służy do rotowania określonej liczby plików log.
logrotate powinien być domyślnie zainstalowany w każdym systemie Ubuntu.
Dla każdej aplikacji, której logami chcemy zarządzać, dodajemy plik konfiguracyjny:
#/etc/logrotate.d/our_app
Zawartość pliku:
/home/apps/our_app/current/log/production.log* {
daily
rotate 7
compress
missingok
}
daily - codziennie
rotate 7 - zostaw ostatnie siedem plików
compress - spakuj gzip
missingok - nie krzycz, gdy nie ma żadnych logów
logrotate wykonuje ten skrypt każdego dnia, datę ostatniego wykonania, można sprawdzić w pliku:
cat /var/lib/logrotate/status
Za pomocą następującej komendy można ręcznie uruchomić określoną konfigurację logrotate:
sudo logrotate -f /etc/logrotate.d/our_app
środa, 25 stycznia 2012
piątek, 20 stycznia 2012
Capistrano - czyszczenie katalogu releases
Po raz kolejny szukam w Google składni polecenia capistrano aby wyczyścić stare 'releases', aby więcej tego nie szukać oto składnia:
cap deploy:cleanup -s keep_releases=2
keep_releases=2 oznacza, że pozostaną nam dwa ostanie 'releases'.
wtorek, 3 stycznia 2012
ssh bez hasła
Piszę to głównie po to aby nie musieć szukać ponownie tych informacji za miesiąc lub dwa, gdy będę musiał konfigurować rsync lub coś podobnego...
Mamy dwa serwery:
A - serwer produkcyjny
B - serwer backup
Zakładam, że na serwerze B posiadamy już użytkownika (np. backup) i folder .ssh w jego katalogu domowym. Zakładam także, że posiadamy już plik .ssh/authorized_keys2
Jeśli nie, to:
cd .ssh
touch authorized_keys2
chmod 600 authorized_keys2
Na serwerze A, z którego będziemy robili upload za pomocą rsync generujemy klucz prywatny i publiczny, np:
mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa
Wchodzimy do katalogu .ssh na serwerze A:
cd .ssh/
i kopiujemy klucz publiczny na serwer B:
scp id_rsa.pub server_b_username@server_b_domain:~/id_rsa.pub
Następnie logujemy się poprzez ssh na serwer B.
cd .ssh
cat ~/id_rsa.pub >> authorized_keys2
rm ~/id_rsa.pub
Następnie wylogowujemy się z serwera B, logujemy się na serwer A i z niego powinniśmy być w stanie zalogować się na serwer B bez podawania hasła.
Mamy dwa serwery:
A - serwer produkcyjny
B - serwer backup
Zakładam, że na serwerze B posiadamy już użytkownika (np. backup) i folder .ssh w jego katalogu domowym. Zakładam także, że posiadamy już plik .ssh/authorized_keys2
Jeśli nie, to:
cd .ssh
touch authorized_keys2
chmod 600 authorized_keys2
Na serwerze A, z którego będziemy robili upload za pomocą rsync generujemy klucz prywatny i publiczny, np:
mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa
Wchodzimy do katalogu .ssh na serwerze A:
cd .ssh/
i kopiujemy klucz publiczny na serwer B:
scp id_rsa.pub server_b_username@server_b_domain:~/id_rsa.pub
Następnie logujemy się poprzez ssh na serwer B.
cd .ssh
cat ~/id_rsa.pub >> authorized_keys2
rm ~/id_rsa.pub
Następnie wylogowujemy się z serwera B, logujemy się na serwer A i z niego powinniśmy być w stanie zalogować się na serwer B bez podawania hasła.
Instalacja gem'ów bez dokumentacji na Ubuntu
Należy utworzyć plik ~/.gemrc i dodać do niego następującą linię:
gem: --no-ri --no-rdoc
Wylogować się, zalogować ponownie i gem install [gem_name] nie powinien już instalować dokumentacji dla wybranego gem'a.
gem: --no-ri --no-rdoc
Wylogować się, zalogować ponownie i gem install [gem_name] nie powinien już instalować dokumentacji dla wybranego gem'a.
sobota, 18 czerwca 2011
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:
odnaleźć fragment:
2. dodać następującą linię
przed linią
3. zrestartować serwer jetty i nasz panel solr powinien już być zabezpieczony.
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:
odnaleźć fragment:
2. dodać następującą linię
przed linią
3. zrestartować serwer jetty i nasz panel solr powinien już być zabezpieczony.
piątek, 17 czerwca 2011
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ę:
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:
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:
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ę:
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:
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:
sobota, 12 marca 2011
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:
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:
Generujemy domyślny plik konfiguracyjny:
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'
Teraz możemy wykonać backup bazy:
...i mamy zrobiony backup!
W kolejnym poście postaram się opisać automatyzację tego rozwiązania za pomocą gema whenever.
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
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:
Generujemy domyślny plik konfiguracyjny:
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'
Teraz możemy wykonać backup bazy:
...i mamy zrobiony backup!
W kolejnym poście postaram się opisać automatyzację tego rozwiązania za pomocą gema whenever.
Subskrybuj:
Posty (Atom)