Śledzenie w Git zmian modułu jakby był zwykłym kodem

Może się okazać, że chcemy aby w naszym projekcie, w którym używamy Composera, zmiany w paczce były śledzone w głównym drzewie aplikacji. Inaczej mówiąc chcemy zrezygnować z traktowanie paczki jako submodułu, tak aby była traktowana jak normalny kod aplikacji.
Jeśli spróbujemy dodać paczkę, skończy się to tylko dodaniem pustego folderu.
Próba dodanie podfolderu z paczki zakończyć się może czymś podobnym:
# git add public_html/protected/vendors/crisu83/yiistrap/assets/
fatal: Path 'public_html/protected/vendors/crisu83/yiistrap/assets/' is in submodule 'public_html/protected/vendors/crisu83/yiistrap'

Wg mnie najlepszym wyjściem jest użycie czwartej metody opisanej tutaj: http://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md.
W skrócie, chodzi o wpisanie do .gitignore naszej aplikacji ścieżki do ignorowania folderów .git w naszych modułach. Dzięki temu możemy dodać zawartość modułów do naszej aplikacji i Composer bez problemu będzie aktualizował nasze moduły.

Jeśli z jakiegoś powodu nie działałoby dodanie modułu do gita można spróbować najpierw usunąć moduł z opcją --cached:

# git rm --cached public_html/protected/vendors/crisu83/yiistrap
rm 'public_html/protected/vendors/crisu83/yiistrap'

Po tej operacji możemy bez problemu dodać moduł.

RabbitMQ – action „start” failed

Problem

Podczas instalacji rabbitmq-server napotykam na problem, pakiet nie chce się do końca zainstalować:
Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_log, _err rabbitmq-server. invoke-rc.d: initscript rabbitmq-server, action "start" failed. dpkg: error processing rabbitmq-server (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: rabbitmq-server

Ponadto:
# invoke-rc.d rabbitmq-server start
Starting message broker: rabbitmq-serverFAILED - check /var/log/rabbitmq/startup_\{log, _err\} ... (warning).
failed!
invoke-rc.d: initscript rabbitmq-server, action "start" failed.

dmesg pokazuje:
[11300042.270119] erlexec[3446]: segfault at 4 ip 000076b83c0fcc96 sp 00007a1d47eae7d0 error 6 in libc-2.11.3.so[76b83c060000+159000]

strace:
[pid 5782] lstat("/sys", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 5782] lstat("/sys/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 5782] lstat("/sys/devices/system", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 5782] lstat("/sys/devices/system/node", {st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid 5782] open("/sys/devices/system/node", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
[pid 5782] --- SIGSEGV (Segmentation fault) @ 0 (0) ---

# ls -al /sys/devices/system/node
pokazuje uprawnienia 700

Naprawa

Daje:
# chmod a+xw /sys/devices/system/node
# rm -rf /var/lib/rabbitmq/mnesia/

odpalam z roota
# /usr/lib/rabbitmq/bin/rabbitmq-server
# invoke-rc.d rabbitmq-server start
Starting message broker: rabbitmq-serverFAILED - check /var/log/rabbitmq/startup_\{log, _err\} ... (warning).
failed!
invoke-rc.d: initscript rabbitmq-server, action "start" failed.

# ls /var/log/rabbitmq/startup_*
startup_err startup_log
# cat /var/log/rabbitmq/startup_*

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
BOOT FAILED
===========

Error description:
{error,{could_not_write_file,"/var/lib/rabbitmq/mnesia/rabbit@mephisto/cluster_nodes.config",
eacces}}

Log files (may contain more information):
/var/log/rabbitmq/rabbit@mephisto.log
/var/log/rabbitmq/rabbit@mephisto-sasl.log

Stack trace:
[{rabbit_node_monitor,write_cluster_status,1},
{rabbit_node_monitor,prepare_cluster_status_files,0},
{rabbit,'-boot/0-fun-1-',0},
{rabbit,start_it,1},
{init,start_it,1},
{init,start_em,1}]

{"init terminating in do_boot",{rabbit,failure_during_boot,{error,{could_not_write_file,"/var/lib/rabbitmq/mnesia/rabbit@mephisto/cluster_nodes.config",eacces}}}}

Zmieniam uprawnienia:
# chown rabbitmq:rabbitmq /var/lib/rabbitmq/ -R

Uruchamiam:
# invoke-rc.d rabbitmq-server start
Starting message broker: rabbitmq-server.

Test

# ps aux | grep rabbit
rabbitmq 14638 0.0 0.0 11748 1384 ? S 20:08 0:00 /bin/sh /usr/sbin/rabbitmq-server
rabbitmq 14648 5.7 0.2 142460 34276 ? Sl 20:08 0:00 /usr/lib/erlang/erts-5.8/bin/beam.smp -W w -K true -A30 -P 1048576 -- -root /usr/lib/erlang -progname erl -- -home /var/lib/rabbitmq -- -pa /usr/lib/rabbitmq/lib/rabbitmq_server-3.1.5/sbin/../ebin -noshell -noinput -s rabbit boot -sname rabbit@mephisto -boot start_sasl -kernel inet_default_connect_options [{nodelay,true}] -sasl errlog_type error -sasl sasl_error_logger false -rabbit error_logger {file,"/var/log/rabbitmq/rabbit@mephisto.log"} -rabbit sasl_error_logger {file,"/var/log/rabbitmq/rabbit@mephisto-sasl.log"} -rabbit enabled_plugins_file "/etc/rabbitmq/enabled_plugins" -rabbit plugins_dir "/usr/lib/rabbitmq/lib/rabbitmq_server-3.1.5/sbin/../plugins" -rabbit plugins_expand_dir "/var/lib/rabbitmq/mnesia/rabbit@mephisto-plugins-expand" -os_mon start_cpu_sup false -os_mon start_disksup false -os_mon start_memsup false -mnesia dir "/var/lib/rabbitmq/mnesia/rabbit@mephisto"

# invoke-rc.d rabbitmq-server status
Status of node rabbit@mephisto ...
[{pid,14648},
{running_applications,[{rabbit,"RabbitMQ","3.1.5"},
{os_mon,"CPO CXC 138 46","2.2.5"},
{xmerl,"XML parser","1.2.5"},
{mnesia,"MNESIA CXC 138 12","4.4.14"},
{sasl,"SASL CXC 138 11","2.1.9.2"},
{stdlib,"ERTS CXC 138 10","1.17"},
{kernel,"ERTS CXC 138 10","2.14"}]},
{os,{unix,linux}},
{erlang_version,"Erlang R14A (erts-5.8) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:30] [kernel-poll:true]\n"},
{memory,[{total,28874312},
{connection_procs,2712},
{queue_procs,5424},
{plugins,0},
{other_proc,9018160},
{mnesia,59648},
{mgmt_db,0},
{msg_index,34208},
{other_ets,792096},
{binary,1848},
{code,15563458},
{atom,1351233},
{other_system,2045525}]},
{vm_memory_high_watermark,0.4},
{vm_memory_limit,6707676774},
{disk_free_limit,1000000000},
{disk_free,6399975424},
{file_descriptors,[{total_limit,924},
{total_used,3},
{sockets_limit,829},
{sockets_used,1}]},
{processes,[{limit,1048576},{used,129}]},
{run_queue,0},
{uptime,435}]
...done.

 

Podpowiadanie w bashu

Aby uruchomić podpowiadanie w bashu należy na początek zainstalować pakiet bash-completion:
# apt-get install bash-completion

Następnie należy edytować plik .bashrc
# vim ~/.bashrc

i dodać w nim:
if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi

Certyfikat SSL w DirectAdmin z użyciem SNI

Jeśli chcesz zainstalować więcej niż jeden certyfikat ssl używając jednego adresu ip do rozważenia zostaje użycie SNI czyli Server Name Indication. Aby zainstalować certyfikat SSL w DirectAdmin należy:

  1. Włączyć w konfiguracji DirectAdmina opcję sni:
     # vim /usr/local/directadmin/conf/directadmin.conf

    i dodajemy:

     enable_ssl_sni=1
  2. Generujemy klucz prywatny dla naszej domeny:
    # openssl genrsa -des3 -out naszadomena.pl.key 2048
  3. Generujemy żądanie certyfikatu:
    # openssl req -new -key naszadomena.pl.key -out naszadomena.pl.csr
  4. W naszym centrum certyfikacji (CA) uzyskujemy certyfikat na podstawie „naszadomena.pl.csr”. Polecam StartSSL, w którym możemy uzyskać certyfikat bezpłatnie. Otrzymany plik zapisujemy jako „naszadomena.pl.crt”.
  5. W DirectAdmin wchodzimy do „SSL Certificates”. Zaznaczamy opcję „Paste a pre-generated certificate and key” i wklejamy w polu poniżej zawartość klucza prywatnego „naszadomena.pl.key” i pod nim certyfikat „naszadomena.pl.crt”.
  6. Musimy dodać Root Certificate naszego CA, w tym celu, pod polem opisanym powyżej jest link „Click Here to paste a CA Root Certificate” do formularza, do którego wklejamy zawartość certyfikatu od CA (w StartSSl: ToolBox -> StartCom CA Certificates ->StartCom Root CA (PEM encoded),  zaznaczamy „Use a CA Cert.” i zapisujemy zmiany.
  7. Może się zdarzyć, że nie możemy ponownie uruchomić Apache, który zaakceptowałby poprawnie nasz certyfikat – wejście na stronę „naszadomena.pl” powoduje ostrzeżenie o błędnym certyfikacie. Upewnij się, że pliku konfiguracyjnym dla domeny „/usr/local/directadmin/data/users/naszadomena/httpd.conf”, masz prawidłowe ścieżki do prywatnego klucza oraz samego certyfikatu.
  8. Podczas ponownego uruchamiania (jeśli certyfikat jest poprawnie obsługiwany przez Apache) pojawi się informacja o podanie hasło do klucza prywatnego. Podajesz hasło, które ustawiłeś dla wygenerowania „naszadomena.key”. Aby usunąć hasło z klucza zrób jego kopię:
    # cp naszadomena.key naszadomena.key.crypted

    utwórz plik z kluczem bez hasła:

    # openssl rsa -in naszadomena.key.crypted -out naszadomena.key
  9. Uruchom ponownie Apache, w przeglądarce powinieneś móc połączyć się z domeną po ssl.

Monitoring hostów Apacha przy użyciu Munina

apache_vhosts

Jednym z ciekawych pluginów do Munina jest apache_vhosts. Pokazuje on na wykresie per vhost: średnią wielkość odpowiedzi, średni czas odpowiedzi oraz ilość zapytań na minutę.

Wybór metody pozyskiwania danych

Czytając README możemy się dowiedzieć, że do prawidłowego funkcjonowania pluginu potrzebujemy analizować logi Apache i tu mamy do wyboru trzy metody:

  1. Możemy użyć apache_pipelogger, do którego Apache będzie zapisywał logi
  2. Możemy użyć apache_logparser jako daemona, który parsuje logi Apache
  3. Możemy użyć dwie metody jednocześnie – dane będę połączone.

Ja wybrałem metodę nr 2.

Instalacja dodatkowych modułów

Aby zapewnić prawidłowe funkcjonowanie pluginu musimy zainstalować następujące moduły perla:  File::Tail::Multi Storable IPC::ShareLite Munin::Plugin (opcjonalnie Data::Dumper). Możemy to zrobić otwierając perlowy shell:
perl -MCPAN -e shell
a następnie zainstalować moduł, np.:
install File::Tail::Multi

Kopiowanie plików

W kolejnym kroku musimy przekopiować: apache_logparserapache_vhosts do katalogu z naszymi pluginami. W moim przypadku jest to /usr/share/munin/plugins. Następnie powinniśmy utworzyć symlink w /etc/munin/plugins do apache_vhosts.

Konfiguracja parsera

W pliku apache_logparser musimy skonfigurować ścieżkę do plików z logami, określić jak wyglądają nazwy vhostów, aby parser mógł określić nazwę vhosta. Edytujemy:

my $dir = "/logs/apache_logs";
my $files = "*access_log";
my $site = "(.*)-access_log";

Próba parsera

Na tym etapie możemy zobaczyć czy parser działa prawidłowo. Wystarczy, że zmienimy w nim

local $debug=1;

Teraz odpalając parsera będziemy widzieć wynik analizy poszczególnych logów. Na czas konfiguracji możemy zostawić uruchomionego daemona.

Konfiguracja noda

Kolejną czynnością jest konfiguracja noda Munina. Musimy w pliku /etc/munin/plugin-conf.d/munin-node umieścić:

[apache_vhosts]
user root
env.subgraphs requests bytes time
env.checks requests bytes time

Test pluginu

Możemy tera sprawdzić czy plugin działa prawidłowo, wystarczy uruchomić:

munin-run apache_vhosts

Finalne uruchomienie

Na koniec zatrzymujemy daemona parsera logów i wyłączamy w nim tryb debug. Uruchamiamy go w tle. Restartujemy noda Munia. Po kilku minutach powinniśmy zobaczyć nowe wykresy 🙂

Sekunda przestępna

Na serwerze zauważyłem, że dwa procesy mysql pracują zużywając stanowczo więcej zasobów procesora niż zwykle. Z wykresów wynika, że problem rozpoczął się 1 lipca o godzinie 2:00. W logach zero błędów. Po podłączeniu się stracem dostałem:

# strace -p 6868 -tttt

1341226359.261640 futex(0x123c1d0, FUTEX_WAKE_PRIVATE, 1) = 0
1341226359.261703 futex(0x123c214, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 701273, {1341226360, 261694000}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
1341226359.261791 futex(0x123c1d0, FUTEX_WAKE_PRIVATE, 1) = 0
1341226359.261841 futex(0x123c214, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 701275, {1341226360, 261831000}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
(…)

Okazało się, że winna jest sekunda przestępna. Rozwiązaniem problemu jest zatrzymanie serwera czasu, ustawienie czasu i włączenie serwera czasu. U mnie wyglądało to tak:

# invoke-rc.d ntp stop
# date -s "`date`"
# invoke-rc.d ntp start

Procesy mysql automatycznie wróciły do normy.

Problem z ponownym zamontowanie partycji Truecrypt

Po odmontowaniu patrycji używając umount (powinno się robić przez truecrypt -d) chciałem jeszcze raz zamontować ją. Niestety nie udało się, otrzymałem komunikat:

device-mapper: create ioctl failed: Urządzenie lub zasoby zajęte
Command failed

Rozwiązaniem okazuje się usunięcie urządzenia poprzez dmsetup. Patrzymy jakie mamy urządzenie:

# dmsetup ls
truecrypt1 (253, 0)

I usuwamy je:

# dmsetup remove truecrypt1

Teraz możemy ponownie zamontować urządzenie:

truecrypt obraz /montuj/do

Ubuntu 10.10 – nie działa przycisk myszy

Ostatnio po upgrade Ubuntu 10.04 do wersji 10.10 natrafiłem na problem z lewym przyciskiem myszy. Dokładniej mówiąc w bliżej nieokreślonych sytuacjach, powiedzmy w losowej długości działania systemu, nagle przestaje działać lewy przycisk myszy, dodatkowo za chwilę alt+tab również nie działa. Posiadam mysz na ps, wyciągnięcie wtyczki z komputera jak również ponowne załadowania modułu ‚psmouse’ nie przyniosło zamierzonych rezultatów. Rozwiązaniem okazało się ponowne załadowanie modułów ‚usbhid’ oraz ‚hid’. Magiczna linijka:

 rmmod usbhid && rmmod hid && modprobe hid && modprobe usbhid 

Oczywiście najlepiej zapisać to sobie do katalogu bin, żeby było pod ręką w razie potrzeby.