Category: Linux

SSHFS, zdalne partycje oraz automontowanie

May 15, 2011 /

Każdy z was pewnie nie raz chciał mieć dostęp do swoich danych zgromadzonych w innym miejscu świata.

Ja postanowiłem dorwać się do mojej małej macierzy która (niestety) komunikuje się ze światem poprzez USB. Na szczęście nieopodal niej stoi całkiem poczciwy serwer deweloperski. Kilka linijek do /etc/fstab i już można cieszyć się dostępem do danych za pośrednictwem SSH.

Jak zwykle jest to jednak za mało. Czy nie byłoby fajniej mieć zamapowany z automatu każdy z dysków na np. laptopie? Pewnie że by było :) i tym się dzisiaj zajmiemy. Aby montować nasze zdalne partycje wykorzystamy sshfs oraz autofs.

Zainstalujmy najpierw to czego potrzebujemy:

sudo aptitude install sshfs autofs

Następnie dodajmy się do grupy fuse:

sudo gpasswd -a $USER fuse

Zamknijmy okno basha i otwórzmy nowe. W nim utworzymy parę kluczy publiczny-prywatny. Będą one potrzebne nam do uwierzytelniania się na serwerze bez potrzeby podawania hasła:

ssh-keygen -t dsa -f ~/.ssh/id_dsa_open

Passphrase musi pozostać puste, tak więc wciskamy 2 razy enter.

Dodajmy nasz klucz:

ssh-add ~/.ssh/id_dsa_open

Kopiujemy nasz klucz publiczny na serwer:

ssh-copy-id -i ~/.ssh/id_dsa_open.pub user@adres.naszego.serwera

Próbujemy się zalogować na serwerze wykorzystując klucz (bez potrzeby podawania hasła):

sudo ssh -i ~/.ssh/id_dsa_open user@adres.naszego.serwera

Edytujemy /etc/auto.master dopisując następującą linijkę:

/media/sshfs	/etc/auto.sshfs	--timeout=3600 --ghost --verbose

Powyższy wpis sprawi, że nasze zdalne katalogi montowane będą w katalogu /media/sshfs.

Dodajemy wpis w /etc/auto.sshfs:

nazwa_zasobu -fstype=fuse,rw,allow_other,noatime,IdentityFile=/home/user/.ssh/id_dsa_open :sshfs\#user@adres.naszego.serwera\:/sciezka/do/katalogu/zdalnego

Pamiętajcie żeby zamienić "user" na login ze zdalnego konta oraz podać prawidłowy adres serwera oraz ścieżkę do katalogu który chcemy sobie udostępnić.

Restartujemy autofs:

sudo restart autofs

Wchodzimy w /media/sshfs i korzystamy z naszych danych kiedykolwiek potrzebujemy.

Warto oczywiście pamiętać, że prędkość dostępu do danych zgromadzonych na zasobie zdalnym będzie zależna od łącza jakie posiadamy (my oraz druga strona), tak więc jeśli potrzebujemy przetransferować jakiś duży plik, może to chwilę potrwać.

Odpalanie wielu serwerów z pomocą jednego polecenia

March 23, 2011 /

Trafiają się nam projekty, w których wymagane jest uruchamianie kilku (kilkunastu) usług zanim będziemy mogli pracować. Odpalanie tego (i zarządzanie) w kilku oknach jest delikatnie mówiąc niewygodne.

Aby sobie to ułatwić, wystarczy napisać prosty skrypt w Bashu, który dane serwery będzie odpalał bezpośrednio w screenie. Ostatni z odpalanych serwerów pozostawimy "na wierzchu", dopisując kod który w momencie naciśnięcia na nim Ctrl+C (zamknij), wyłączy wszystkie pozostałe serwery. W ten sposób będziemy mogli łatwo i wygodnie zarządzać uruchamianiem i zamykaniem całego projektu. Dodamy sobie także alias tak, aby móc wygodnie wywoływać nasz skrypt.

Załóżmy, że nasz projekt nazywa się Kotowari. Wszystkie tworzone (później) screeny będą zawierać w sobie tę nazwę. Dzięki temu, będziemy mogli je zabić pozostawiając inne pracujące screeny (nie związane z projektem). Zdefiniujemy sobie także pułapkę na Ctrl+C:

trap close_screens INT

function close_screens() {
	kill -9 `ps aux  | awk '/Kotowari/{print $2}'`
	screen -wipe
}

Teraz pora na odpalanie kolejnych serwerów. Serwery które odpalamy przez init.d lub takie które nie potrzebują do pracy konsoli (nie "zostają" w niej), możemy odpalać bezpośrednio czyli:

sudo /etc/init.d/apache2 start;
sudo /etc/init.d/mysql start;

Warto zwrócic uwagę, że nie zostaną one zabite podczas zamykania projektu. Dlaczego to tak zostawiam? Tego typu procesy i tak zazwyczaj chodzą niezależnie od danego projektu i są współdzielone (zazwyczaj są też włączane przy boocie systemu - próbujemy je włączyć tak dla pewności). Oczywiście nic nie stoi na przeszkodzie aby je zamykać w napisanej powyżej funkcji close_screens().

Teraz pora na procesy dedykowane naszej aplikacji i zamknięcie całości:

screen -d -S "Kotowari Proc 1" -m "/sciezka/do/naszego/procesu1"
screen -d -S "Kotowari Proc 2" -m "/sciezka/do/naszego/procesu2"

"/sciezka/do/naszego/procesu3"

close_screens

Ostatni proces nie jest uruchamiany w screenie, ponieważ on ma nam zostać "na" konsoli. Jego zamknięcie zainicjuje funkcję close_screens która zamknie resztę z procesów ukrytych w screenach.

Jeszcze tylko alias:

alias nasz_projekt="/sciezka/do/naszego/skryptu.sh"

Całość:

trap close_screens INT

function close_screens() {
	kill -9 `ps aux  | awk '/Kotowari/{print $2}'`
	screen -wipe
}

sudo /etc/init.d/apache2 start;
sudo /etc/init.d/mysql start;

screen -d -S "Kotowari Proc 1" -m "/sciezka/do/naszego/procesu1"
screen -d -S "Kotowari Proc 2" -m "/sciezka/do/naszego/procesu2"

"/sciezka/do/naszego/procesu3"

close_screens

Copyright © 2026 Closer to Code

Theme by Anders Noren — Up ↑