Czasami przydatną rzeczą okazuje się archiwizacja uprawnień do plików i katalogów. Możemy to zrobić komendą:
# getfacl nazwa_pliku
Możemy spróbować zdobyc uprawnienia rekurecyjnie w całym podkatalogu, a wynik zapisać w pliku:
# getfacl katalog > /tmp/files.acl
Jeżeli z jakiegoś powodu potrzebujemy przywrócić uprawnienia do poprzednich - robimy to komendą:
# setfacl --restore=/tmp/files.acl
Zadanie domowe:
- przeglądnąć man setfacl i getfacl
- potestować we własnym zakresie różne opcje(jak zawsze)
Pokazywanie postów oznaczonych etykietą linux. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą linux. Pokaż wszystkie posty
środa, 18 listopada 2009
piątek, 6 listopada 2009
Secure FTP - bezpieczne FTP w praktyce
Nie mam zamiaru opowiadać tu o słabościach protokołu FTP i problemach związanych z konfiguracją takowego serwera. Lepiej pójść na skróty i skorzystać z gotowego, lepszego i prostszego rozwiązania (KISS) jakim jest SFTP. Mając zainstalowany serwer SSH (prawie na pewno będzie to openSSH) dostajemy taką możliwość gratis.
Najprostszym a zarazem najszybszym sposobem jest stworzenie konta i ustawienie domyślnego shella na binarkę serwera sftp - najczęściej jest to sftp-server (w debianie - /usr/lib/sftp-server, w Gentoo - /usr/lib/misc/sftp-server, w innych - poszukajcie sobie sami). Zakładamy konto:
Pozostaje jeszcze dodać sftp-server do listy dozwolonych powłok (shell) zgłoszeniowych (debilne tłumaczenie - login shells), np. tak:
Szybko i prosto zdefiniowaliśmy serwer SFTP. Jedyne co można zarzucić temu rozwiązaniu to możliwość poruszania się użytkownika po całym filesystemie - w miarę oczywiście posiadanych uprawnień - a tego nie zawsze chcemy.
Drugim sposobem, który jest może trudniejszy w konfguracji jest udostępnienie jedynie dostępu do serwera sftp z możliwością chrootowania katalogu użytkownika (chroot).
Zmieniamy w /etc/ssh/sshd_config
Subsystem sftp internal-sftp
Restartujemy sshd (/etc/init.d/sshd restart) i już.
Waryo pamiętać o ustawieniu shella użytkownika na /sbin/nologin
Bardzo ważne jest ustawienie właściciela i grupy na katalogu do którego będzie ograniczone środowisko robocze użytkownika na root oraz ustawienie odpowiednich uprawnień aby umożliwić użytkownikowi zapis w tym katalogu.
ps. Zamiast Match User można użyć np. Match Group - polecam poczytanie manuala sshd.
Najprostszym a zarazem najszybszym sposobem jest stworzenie konta i ustawienie domyślnego shella na binarkę serwera sftp - najczęściej jest to sftp-server (w debianie - /usr/lib/sftp-server, w Gentoo - /usr/lib/misc/sftp-server, w innych - poszukajcie sobie sami). Zakładamy konto:
useradd -m -s /usr/lib/misc/sftp-server username
Pozostaje jeszcze dodać sftp-server do listy dozwolonych powłok (shell) zgłoszeniowych (debilne tłumaczenie - login shells), np. tak:
echo "/usr/lib/misc/sftp-server" >> /etc/shells
Szybko i prosto zdefiniowaliśmy serwer SFTP. Jedyne co można zarzucić temu rozwiązaniu to możliwość poruszania się użytkownika po całym filesystemie - w miarę oczywiście posiadanych uprawnień - a tego nie zawsze chcemy.
Drugim sposobem, który jest może trudniejszy w konfguracji jest udostępnienie jedynie dostępu do serwera sftp z możliwością chrootowania katalogu użytkownika (chroot).
Zmieniamy w /etc/ssh/sshd_config
Subsystem sftp internal-sftp
# These lines must appear at the *end* of sshd_config
Match User username
ChrootDirectory /home/userhome
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
Restartujemy sshd (/etc/init.d/sshd restart) i już.
Waryo pamiętać o ustawieniu shella użytkownika na /sbin/nologin
Bardzo ważne jest ustawienie właściciela i grupy na katalogu do którego będzie ograniczone środowisko robocze użytkownika na root oraz ustawienie odpowiednich uprawnień aby umożliwić użytkownikowi zapis w tym katalogu.
ps. Zamiast Match User można użyć np. Match Group - polecam poczytanie manuala sshd.
czwartek, 20 sierpnia 2009
svn: Can't convert string from 'UTF-8' to native encoding:
Ostatnio mi się przydarzył taki błąd. Występuje on gdy klient dostanie z repozytorium plik z nazwą zawierający znak w UTF-8, którego nie jest w stanie zaprezentować używając lokalnego kodowania znaków. W takim wypadku należy odpowiednio zmienić używane kodowanie znaków:
W moim przypadku zadziałało. Warto to ustawić na stałe. W Gentoo mamy do tego katalog /etc/env.d.
Jako lekturę polecam przewodnik lokalizacji Gentoo
$ export LC_CTYPE=pl_PL.UTF-8
$ locale
LANG=
LC_CTYPE=pl_PL.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
W moim przypadku zadziałało. Warto to ustawić na stałe. W Gentoo mamy do tego katalog /etc/env.d.
Jako lekturę polecam przewodnik lokalizacji Gentoo
środa, 12 sierpnia 2009
Sudo - jak umożliwić użytkownikowi przełączenie na konto root?
Na początku pozwolę sobie stwierdzić, że można to zrobić pewnie na milion sposobów - no może trochę przesadziłem - ale na pewno jest ich trochę - i w tym tkwi piękno linuxa.
Najpierw zastanówmy się o co chodzi w tym zadaniu tak naprawdę? Upraszczając - jeśli użytkownik może się przełączyć na konto roota to de facto nadajemy mu uprawnienia administracyjne. Jak to zrobić? Można np. stworzyć grupę i nadać członkom tej grupy uprawnienia do uruchamiania wszystkich poleceń systemowych. Często korzystam z gotowej "receptury" w /etc/sudoers:
i już. Członkowie grupy wheel mają teraz uprawnienia administracyjne. Wystarczy dodać odpowiednie osoby do grupy wheel poprzez edycję /etc/groups lub wywołanie groupmod lub gpasswd lub ...
Teraz już z konta fares możemy przejśc na root:
I to tyle. Czekam na wasze rozwiązania w komentarzach.
Najpierw zastanówmy się o co chodzi w tym zadaniu tak naprawdę? Upraszczając - jeśli użytkownik może się przełączyć na konto roota to de facto nadajemy mu uprawnienia administracyjne. Jak to zrobić? Można np. stworzyć grupę i nadać członkom tej grupy uprawnienia do uruchamiania wszystkich poleceń systemowych. Często korzystam z gotowej "receptury" w /etc/sudoers:
#visudo
# Uncomment to allow people in group wheel to run all commands
%wheel ALL=(ALL) ALL
i już. Członkowie grupy wheel mają teraz uprawnienia administracyjne. Wystarczy dodać odpowiednie osoby do grupy wheel poprzez edycję /etc/groups lub wywołanie groupmod lub gpasswd lub ...
# gpasswd -a fares wheel
Adding user fares to group wheel
Teraz już z konta fares możemy przejśc na root:
fares@ny $ sudo su -
I to tyle. Czekam na wasze rozwiązania w komentarzach.
sobota, 11 lipca 2009
Konfiguracja powiadomień przy wykonaniu komendy sudo
Sudo jak już zapewne wiemy umożliwia nam rozszerzenie uprawnień użytkownika w systemie bez konieczności udostępniania hasła konta root.
Warto wiedzieć, że sudo ma możliwość informowania o aktywności użytkowników w systemie - wykonywanych poleceniach, próbach naruszania uprawnień, etc.
Domyślnie komenda sudo zapisuje informacje w logu systemowym - w zależności od dystrybucji i konfiguracji loggera systemowego, moe to być /var/log/auth.log (Debian i s-ka), /var/log/secure (Redhat & co). Można też skonfigurować polecenie sudo, tak żeby w momencie użycia tej komendy wysyłane było powiadomienie na wybraną skrzynkę pocztową.
Jak to zrobić?
Wyedytujmy /etc/sudoers:
Teraz musimy ustawić konto, na które będą trafiały powiadomienia - dodajemy:
Opcje są dość opisowe:
- mailto "admin@staff.example.com" - do kogo wysłać mail
- mail_always - wysyłaj zawsze gdy wykonywane jest sudo (domyślnie jest wyłączone)
Dodatkowo możemy ustawić na on/off:
- mail_badpass - wysyłaj powiadomienia gdy użytkownik poda niewłaściwe hasło (domyślnie wyłączone)
- mail_no_host - wysyłaj maila gdy użytkownik nie ma uprawnień do wykonania danej komendy na określonym hoście (domyślnie wyłączone)
mail_no_perms - wysyłaj maila gdy użytkownik nie ma uprawnień do wykonania danej komendy (domyślnie wyłączone)
- mail_no_user - wysyłaj maila gdy użytkownik nie jest zdefiniowany w pliku sudoers (domyślnie włączone)
Sudo Logfile
UWAGA! Należy pamiętać o odpowiednim skonfigurowaniu systemu pocztowego na hoście z którego zamierzamy wysyłać powiadomienia.
PS. Można wyłączyc logowanie z użyciem systemu logującego - musimy wtedy ustawić ścieżkę do logów. Robimy to tak:
Warto wiedzieć, że sudo ma możliwość informowania o aktywności użytkowników w systemie - wykonywanych poleceniach, próbach naruszania uprawnień, etc.
Domyślnie komenda sudo zapisuje informacje w logu systemowym - w zależności od dystrybucji i konfiguracji loggera systemowego, moe to być /var/log/auth.log (Debian i s-ka), /var/log/secure (Redhat & co). Można też skonfigurować polecenie sudo, tak żeby w momencie użycia tej komendy wysyłane było powiadomienie na wybraną skrzynkę pocztową.
Jak to zrobić?
Wyedytujmy /etc/sudoers:
vim /etc/sudoers
Teraz musimy ustawić konto, na które będą trafiały powiadomienia - dodajemy:
mailto "admin@mojafirma.pl"
mail_always on
Opcje są dość opisowe:
- mailto "admin@staff.example.com" - do kogo wysłać mail
- mail_always - wysyłaj zawsze gdy wykonywane jest sudo (domyślnie jest wyłączone)
Dodatkowo możemy ustawić na on/off:
- mail_badpass - wysyłaj powiadomienia gdy użytkownik poda niewłaściwe hasło (domyślnie wyłączone)
- mail_no_host - wysyłaj maila gdy użytkownik nie ma uprawnień do wykonania danej komendy na określonym hoście (domyślnie wyłączone)
mail_no_perms - wysyłaj maila gdy użytkownik nie ma uprawnień do wykonania danej komendy (domyślnie wyłączone)
- mail_no_user - wysyłaj maila gdy użytkownik nie jest zdefiniowany w pliku sudoers (domyślnie włączone)
Sudo Logfile
UWAGA! Należy pamiętać o odpowiednim skonfigurowaniu systemu pocztowego na hoście z którego zamierzamy wysyłać powiadomienia.
PS. Można wyłączyc logowanie z użyciem systemu logującego - musimy wtedy ustawić ścieżkę do logów. Robimy to tak:
Defaults !lecture,tty_tickets,!fqdn,!syslog
Defaults logfile=/var/log/sudo.log
czwartek, 9 lipca 2009
ORA-12162 TNS:net service name is incorrectly specified
Ostatnio doświadczyłem tego na Debianie po zainstalowaniu Oracle XE zgodnie z zaleceniami okazało się, że próby połączenia z Oraclem przez sqlplus kończą się powyższym błedem 'ORA-12162 TNS:net service name is incorrectly specified'. Jak się okazuje rozwiązanie jest banalne - wystarczy ustawić zmienne środowiskowe (hmm... dziwne, że w paczce to nie jest robione - no cóż - debian):
i już. Później najlepiej te zmienne ustawić w domyślnym środowisku - o ile się nie mylę w Debianie można to zrobić w /etc/profile lub /etc/bash.bashrc (strasznie brakuje mi tu katalogu /etc/env.d z Gentoo).
export ORACLE_SID=XE
export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
i już. Później najlepiej te zmienne ustawić w domyślnym środowisku - o ile się nie mylę w Debianie można to zrobić w /etc/profile lub /etc/bash.bashrc (strasznie brakuje mi tu katalogu /etc/env.d z Gentoo).
środa, 8 lipca 2009
Bash - PIPESTATUS
W jednym z pierwszych blogów zadałem pytanie dotyczące wykrywania błędu przy wykonaniu poleceń w potoku (pipe).
W wypadku jakichkolwiek skryptów ważne jest pilnowanie poprawności wykonania komend. Każda wykonana komenda zwraca status zakończenia, który jeśli wszystko przebiegło poprawnie powinien być równy zero.
Sprawdźmy to:
Co jednak w wypadku gdy korzystamy z potoku?
Weźmy przykład:
Co sie stanie jeśli plik nie istnieje? Wykonajmy to polecenie:
Status wykonania polecenia poprawny (zero). Dlaczego? Ponieważ zmienna $? przechowuje stan wykonania ostatniego polecenia. W naszym przykładzie błąd wystąpił przy pierwszym poleceniu - wyświetleniu zawartości pliku. Ponieważ plik nie istniał został wyświetlony błąd - jednak operacja była kontynuowana w potoku. Polecenie gzip wykonało się poprawnie - skompresowało zerowej wielkości strumień wejściowy. Zwrócony status jest więc jak najbardziej w tym wypadku właściwy - mimo, że cała operacja w potoku nie wykonała się po naszej myśli.
W takim wypadku z pomocą przychodzi zmienna $PIPESTATUS - tabela statusów zakończenia poleceń w potoku. Każda kolejna komórka tabeli zawiera status wykonania poszczególnych poleceń. Zobaczmy jak to działa:
Mamy niepoprawny status wykonania cat - jest więc możliwość stwierdzenia błędu wykonania któregoś z poleceń w potoku.
Możemy odwoływać się do poszczególnych komórek tabeli za pomocą indeksu, np. dla pierwszego polecenia będzie to ${PIPESTATUS[0]}. Należy jednak pamiętać o tym, że zawartość zmiennej PIPESTATUS jest 'ulotna', tzn. dostępna jest tylko bezpośrednio po wykonaniu polecenia. Dla zrozumienia pokażę to na poniższym przykładzie:
cat plik |gzip > plik2.gz
cat: plik: No such file or directory
# echo ${PIPESTATUS[*]}
1 0
# echo ${PIPESTATUS[*]}
0
Drugie wykonanie zwraca status wykonania polecenia echo.
W wypadku dłuższych skryptów istnieje możliwość przerwania przetwarzania skryptu w wypadku wystąpienia błędu za pomocą komendy set -e. Myślę, że jest to wygodniejsze niż śledzenie statusów po każdym wywołaniu (chociaż jak zawsze to zależy od tego co robimy).
PS. Możemy wykluczyć poszczególne polecenia w skrypcie z "ostrej" obsługi błędów przy włączonym set -e. Robimy to poprzedzając dane polecenie znakiem wykrzyknika '!'. Polecam manual set
Przydatne odnośniki:
http://tldp.org/LDP/abs/html/internalvariables.html
W wypadku jakichkolwiek skryptów ważne jest pilnowanie poprawności wykonania komend. Każda wykonana komenda zwraca status zakończenia, który jeśli wszystko przebiegło poprawnie powinien być równy zero.
Sprawdźmy to:
# ls
# echo $?
0
Co jednak w wypadku gdy korzystamy z potoku?
Weźmy przykład:
cat plik | gzip > plik2.gz
Co sie stanie jeśli plik nie istnieje? Wykonajmy to polecenie:
cat: plik: No such file or directory
# echo $?
0
Status wykonania polecenia poprawny (zero). Dlaczego? Ponieważ zmienna $? przechowuje stan wykonania ostatniego polecenia. W naszym przykładzie błąd wystąpił przy pierwszym poleceniu - wyświetleniu zawartości pliku. Ponieważ plik nie istniał został wyświetlony błąd - jednak operacja była kontynuowana w potoku. Polecenie gzip wykonało się poprawnie - skompresowało zerowej wielkości strumień wejściowy. Zwrócony status jest więc jak najbardziej w tym wypadku właściwy - mimo, że cała operacja w potoku nie wykonała się po naszej myśli.
W takim wypadku z pomocą przychodzi zmienna $PIPESTATUS - tabela statusów zakończenia poleceń w potoku. Każda kolejna komórka tabeli zawiera status wykonania poszczególnych poleceń. Zobaczmy jak to działa:
cat plik |gzip > plik2.gz
cat: plik: No such file or directory
# echo ${PIPESTATUS[*]}
1 0
Mamy niepoprawny status wykonania cat - jest więc możliwość stwierdzenia błędu wykonania któregoś z poleceń w potoku.
Możemy odwoływać się do poszczególnych komórek tabeli za pomocą indeksu, np. dla pierwszego polecenia będzie to ${PIPESTATUS[0]}. Należy jednak pamiętać o tym, że zawartość zmiennej PIPESTATUS jest 'ulotna', tzn. dostępna jest tylko bezpośrednio po wykonaniu polecenia. Dla zrozumienia pokażę to na poniższym przykładzie:
cat plik |gzip > plik2.gz
cat: plik: No such file or directory
# echo ${PIPESTATUS[*]}
1 0
# echo ${PIPESTATUS[*]}
0
Drugie wykonanie zwraca status wykonania polecenia echo.
W wypadku dłuższych skryptów istnieje możliwość przerwania przetwarzania skryptu w wypadku wystąpienia błędu za pomocą komendy set -e. Myślę, że jest to wygodniejsze niż śledzenie statusów po każdym wywołaniu (chociaż jak zawsze to zależy od tego co robimy).
PS. Możemy wykluczyć poszczególne polecenia w skrypcie z "ostrej" obsługi błędów przy włączonym set -e. Robimy to poprzedzając dane polecenie znakiem wykrzyknika '!'. Polecam manual set
Przydatne odnośniki:
http://tldp.org/LDP/abs/html/internalvariables.html
piątek, 3 lipca 2009
Instalacja pakietów w dystrybucji gentoo na przykładzie serwera subversion. Część II
Ostatnio zakończyłem na sprawdzeniu znaczenia USE-flag za pomocą komendy euse. Pora powiedzieć trochę więcej o tych flagach.
Większość pakietów (programów) dostępnych w dystrybucjach Linuksa rozprowadzanych jest na licencji GPL lub BSD (są też rzadziej używane LGPL, MIT, etc.), co oznacza, że źródła tych programów dostępne są w sieci bezpłatnie. Autor udostępnia swoją pracę - umożliwiając nam jednocześnie wprowadzanie w niej zmian na określonych licencją warunkach. Co to oznacza w praktyce?
Na przykład to, że możemy taki pakiet ściągnąć i zainstalować na swoim komputerze za darmo. Ponieważ są to jednak wyłącznie źródła, a nie gotowy do uruchomienia program, konieczna jest ich kompilacja do wersji binarnej. Każdy dobrze przygotowany pakiet źródłowy zawiera pliki INSTALL i README, w których autor opisuje sposób instalacji. Najczęściej są to trzy kroki:
- konfiguracja pakietu (./configure) z odpowiednimi opcjami
- kompilacja - make
- instalacja - make install
W wypadku wielu pakietów oprogramowania - szczególnie tych bardziej zaawansowanych - np. subversion'a pierwszy krok (konfiguracja) może przysporzyć sporego bólu głowy. Musimy określić wiele ustawień dotyczących instalowanego pakietu, m.in.:
- gdzie ma być zainstalowany (domyślnie jest to zazwyczaj /usr/local)
- czy stworzyć biblioteki umożliwiające obsługę subversion z poziomu języka ruby, python, perl, java?
- czy skompilować z dodatkowymi modułami?
- czy skompilować moduły umożliwiające współpracę z repozytorium za pośrednictwem apache'a?
- czy dodać bibliotekę odpowiedzialną za obsługę repozytoriów za pomocą protokołu http?
Szczegółowe możliwości konfiguracji pojedynczego pakietu można sprawdzić po rozpakowaniu paczki źródłowej i uruchomieniu programu ./configure --help
Można oczywiście skorzystać z gotowych pakietów dostarczanych przez główne dystrybucje Linuksa. Co jednak zrobić gdy chcemy mieć dodatkową funkcjonalność, która przez dystrybucję nie została dodana do standardowego modułu, hmmm... Weźmy przykład przeglądarki tekstowej links. Standardowo dostarczana jest ona bez obsługi protokołu ssl (dziwne, nieprawdaż?). Co sie wtedy robi, ano przecież jest to oczywiste - odinstalowuje pakiet links i instaluje pakiet links-ssl. Ciemność widzę... No tak i tu zaczyna się opisywane już wcześniej pojęcie 'packaging hell'. Tysiące zależności, miliony pakietów, które tak naprawdę są tym samym pakietem, tylko z inną funkcjonalnością.
I tu z pomocą przychodzi nam rozwiązanie oferowane przez portage. Jeden pakiet, w którym to my definujemy jaką ma on mieć funkcjonalność. Robimy to właśnie za pomocą USE-flag. Weźmy nieszczęsny pakiet links - wiemy już jak dodać funkcjonalność ssl do pakietu w dystrybucji pakietowej dajmy na to Ubuntu - zainstalować links-ssl, odinstalować links, tyle że w odwrotnej kolejności. Nie zapomnij za żadne skarby o tym mój drogi czytelniku.
Co należy zrobić w Gentoo - ustawić dla pakietu flagę USE ssl i już. O resztę zadba za Ciebie portage.
Jak ustawić flagę?
- można ustawić ją globalnie - np. w pliku /etc/make.conf poprzez dodanie jej do parametrów zmiennej USE=""
- lokalnie - per pakiet - robimy to w pliku /etc/portage/package.use, wpis wyglada np. tak:
www-clients/links ssl
- w trakcie instalacji pakietu (niezalecane) - ustawiając zmienną USE przy wywołaniu emerge: USE=ssl emerge -av links (Ze względu na to, że flaga ta jest ustawiana przy pojedynczym wywołaniu emerge, jeśli nie dopiszemy ją na stałe pakiet przy następnej aktualizacji zostanie przekompilowany bez ssl)
Kiedy już nauczymy się ręcznie dodawać flagi możemy zacząć używać narzędzia do automatycznego ustawiania flag. Z tego co mi wiadomo działa ono tylko globalnie, tzn. dodaje wpisy w /etc/make.conf, które to tyczą się wszystkich pakietów. Wtedy flagę ssl możemy dodać tak:
Proponuję przeczytać ze zrozumieniem man euse i wszystko powinno się wyjaśnić. W razie problemów można praktycznie przećwiczyć wszyskie przypadki.
Należy jednak pamiętać o tym, że zmieniamy globalne ustawienia, które są nadpisywane przez ustawienia per pakiet (/etc/portage/portage.use).
Możemy też wyłączać wybrane funkcjonalności - robimy to poprzedzając wybraną flagę znakiem '-' (minus). Działanie jest analogiczne jak w przypadku dodawania flag opisanego powyżej.
Proponuję potestować to u siebie, np. z użyciem opcji 'pretend' (nie instaluj tylko sprawdź) emerge'a:
Dobrze, USE flagi już mamy z grubsza omówione. Wracajmy po tej krótkiej dygresji ;) do głównego wątku - czyli subversion. Skończyliśmy na:
Flagi, które nam się wyświetliły wynikają z ogólnych ustawień systemu, a w szczególności profilu tego systemu (ale o tym następnym razem). Jak widać w wypadku subversion aktywne flagi to:
Pozostałe flagi są nieaktywne (znak minus) - co oznacza, że dana funkcjonalność, za którą odpowiada flaga będzie niedostępna.
Zestaw flag mniej więcej nam odpowiada - chcemy mieć możliwość udostępniania repozytorium przez apache'a (flaga apache2), flaga webdav umożliwi klientowi svn (subversion) dostęp do repozytoriów poprzez http. Nie chcemy mieć natomiast flagi berkdb, która to określa sposób przechowywania danych w repozytorium. Nie będziemy korzystać z domyślnej bazy Berkley - zamiast niej skorzystamy z nowego systemu przechowywania danych w subversion - a mianowicie z subversion FSFS. O zaletach i wadach konkretnych sposobów przechowywania danych w repozytorium dużo inforamcji znajduje się w svn book, a konkretnie tu.
Skoro wiemy co i jak ma być ustawione - zmieniamy flagi dla pakietu. Ponieważ nie chcę zmieniać ich globalnie - wyłącze je na poziomie pojedynczego pakietu, tzn. w /etc/portage/package.use. Wpis wygląda następująco:
Teraz przystąpmy do instalacji
Jak widać flaga berkdb jest nieaktywna - czyli tak jak chcieliśmy. Zatem rozpocznijmy instalację - enter. Następuje konfiguracja i instalacja kolejnych pakietów z powyższej listy, zgodnie z kolejnością ich wyświetlania. Kolejne kroki instalacji odpowiadają krokom, które należy przejść przy ręcznej instalacji pakietu (configure, make, make install). Tyle tylko, że są one zautomatyzowane, ustystematyzowane i zgodne z konwencją (tak bardzo ważne słowo, które znacznie ułatwia życie jeśli się żyje w zgodzie z nim), powtórzmy KONWENCJĄ przyjętą w Gentoo. Zdejmuje to z nas ciężar pamiętania o tym co, gdzie z jakimi flagami i jak zostało zainstalowane. Od tej pory odpowiedzialność za pakiet, a w szczególności jego aktualizacje zrzucamy na barki Gentoo.
i to by było na tyle na dziś...
Przydatne linki:
Gentoo Portage part 1
Gentoo Portage part 2
Subversion Book
Większość pakietów (programów) dostępnych w dystrybucjach Linuksa rozprowadzanych jest na licencji GPL lub BSD (są też rzadziej używane LGPL, MIT, etc.), co oznacza, że źródła tych programów dostępne są w sieci bezpłatnie. Autor udostępnia swoją pracę - umożliwiając nam jednocześnie wprowadzanie w niej zmian na określonych licencją warunkach. Co to oznacza w praktyce?
Na przykład to, że możemy taki pakiet ściągnąć i zainstalować na swoim komputerze za darmo. Ponieważ są to jednak wyłącznie źródła, a nie gotowy do uruchomienia program, konieczna jest ich kompilacja do wersji binarnej. Każdy dobrze przygotowany pakiet źródłowy zawiera pliki INSTALL i README, w których autor opisuje sposób instalacji. Najczęściej są to trzy kroki:
- konfiguracja pakietu (./configure) z odpowiednimi opcjami
- kompilacja - make
- instalacja - make install
W wypadku wielu pakietów oprogramowania - szczególnie tych bardziej zaawansowanych - np. subversion'a pierwszy krok (konfiguracja) może przysporzyć sporego bólu głowy. Musimy określić wiele ustawień dotyczących instalowanego pakietu, m.in.:
- gdzie ma być zainstalowany (domyślnie jest to zazwyczaj /usr/local)
- czy stworzyć biblioteki umożliwiające obsługę subversion z poziomu języka ruby, python, perl, java?
- czy skompilować z dodatkowymi modułami?
- czy skompilować moduły umożliwiające współpracę z repozytorium za pośrednictwem apache'a?
- czy dodać bibliotekę odpowiedzialną za obsługę repozytoriów za pomocą protokołu http?
Szczegółowe możliwości konfiguracji pojedynczego pakietu można sprawdzić po rozpakowaniu paczki źródłowej i uruchomieniu programu ./configure --help
Można oczywiście skorzystać z gotowych pakietów dostarczanych przez główne dystrybucje Linuksa. Co jednak zrobić gdy chcemy mieć dodatkową funkcjonalność, która przez dystrybucję nie została dodana do standardowego modułu, hmmm... Weźmy przykład przeglądarki tekstowej links. Standardowo dostarczana jest ona bez obsługi protokołu ssl (dziwne, nieprawdaż?). Co sie wtedy robi, ano przecież jest to oczywiste - odinstalowuje pakiet links i instaluje pakiet links-ssl. Ciemność widzę... No tak i tu zaczyna się opisywane już wcześniej pojęcie 'packaging hell'. Tysiące zależności, miliony pakietów, które tak naprawdę są tym samym pakietem, tylko z inną funkcjonalnością.
I tu z pomocą przychodzi nam rozwiązanie oferowane przez portage. Jeden pakiet, w którym to my definujemy jaką ma on mieć funkcjonalność. Robimy to właśnie za pomocą USE-flag. Weźmy nieszczęsny pakiet links - wiemy już jak dodać funkcjonalność ssl do pakietu w dystrybucji pakietowej dajmy na to Ubuntu - zainstalować links-ssl, odinstalować links, tyle że w odwrotnej kolejności. Nie zapomnij za żadne skarby o tym mój drogi czytelniku.
Co należy zrobić w Gentoo - ustawić dla pakietu flagę USE ssl i już. O resztę zadba za Ciebie portage.
Jak ustawić flagę?
- można ustawić ją globalnie - np. w pliku /etc/make.conf poprzez dodanie jej do parametrów zmiennej USE=""
- lokalnie - per pakiet - robimy to w pliku /etc/portage/package.use, wpis wyglada np. tak:
www-clients/links ssl
- w trakcie instalacji pakietu (niezalecane) - ustawiając zmienną USE przy wywołaniu emerge: USE=ssl emerge -av links (Ze względu na to, że flaga ta jest ustawiana przy pojedynczym wywołaniu emerge, jeśli nie dopiszemy ją na stałe pakiet przy następnej aktualizacji zostanie przekompilowany bez ssl)
Kiedy już nauczymy się ręcznie dodawać flagi możemy zacząć używać narzędzia do automatycznego ustawiania flag. Z tego co mi wiadomo działa ono tylko globalnie, tzn. dodaje wpisy w /etc/make.conf, które to tyczą się wszystkich pakietów. Wtedy flagę ssl możemy dodać tak:
# euse -E ssl
Zablokować globalnie kompilację z flagą:
# euse -D ssl
a usunąć wszelkie wpisy z daną flagą z /etc/make.conf tak:
# euse -P ssl
Proponuję przeczytać ze zrozumieniem man euse i wszystko powinno się wyjaśnić. W razie problemów można praktycznie przećwiczyć wszyskie przypadki.
Należy jednak pamiętać o tym, że zmieniamy globalne ustawienia, które są nadpisywane przez ustawienia per pakiet (/etc/portage/portage.use).
Możemy też wyłączać wybrane funkcjonalności - robimy to poprzedzając wybraną flagę znakiem '-' (minus). Działanie jest analogiczne jak w przypadku dodawania flag opisanego powyżej.
Proponuję potestować to u siebie, np. z użyciem opcji 'pretend' (nie instaluj tylko sprawdź) emerge'a:
# emerge -pv links
Dobrze, USE flagi już mamy z grubsza omówione. Wracajmy po tej krótkiej dygresji ;) do głównego wątku - czyli subversion. Skończyliśmy na:
# emerge -av subversion
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-db/sqlite-3.6.13 USE="threadsafe -debug -doc -soundex -tcl" 2,716 kB
[ebuild N ] net-misc/neon-0.28.4 USE="nls ssl zlib -doc -expat -gnutls -kerberos -pkcs11 -socks5" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 758 kB
[ebuild N ] virtual/perl-MIME-Base64-3.07 0 kB
[ebuild N ] dev-perl/URI-1.35 94 kB
[ebuild N ] dev-util/subversion-1.6.2 USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -ctypes-python -debug -doc -emacs -extras -gnome-keyring -java -ruby -sasl -test -vim-syntax -webdav-serf" 5,343 kB
Flagi, które nam się wyświetliły wynikają z ogólnych ustawień systemu, a w szczególności profilu tego systemu (ale o tym następnym razem). Jak widać w wypadku subversion aktywne flagi to:
apache2 berkdb dso nls perl python webdav-neon
Pozostałe flagi są nieaktywne (znak minus) - co oznacza, że dana funkcjonalność, za którą odpowiada flaga będzie niedostępna.
Zestaw flag mniej więcej nam odpowiada - chcemy mieć możliwość udostępniania repozytorium przez apache'a (flaga apache2), flaga webdav umożliwi klientowi svn (subversion) dostęp do repozytoriów poprzez http. Nie chcemy mieć natomiast flagi berkdb, która to określa sposób przechowywania danych w repozytorium. Nie będziemy korzystać z domyślnej bazy Berkley - zamiast niej skorzystamy z nowego systemu przechowywania danych w subversion - a mianowicie z subversion FSFS. O zaletach i wadach konkretnych sposobów przechowywania danych w repozytorium dużo inforamcji znajduje się w svn book, a konkretnie tu.
Skoro wiemy co i jak ma być ustawione - zmieniamy flagi dla pakietu. Ponieważ nie chcę zmieniać ich globalnie - wyłącze je na poziomie pojedynczego pakietu, tzn. w /etc/portage/package.use. Wpis wygląda następująco:
dev-util/subversion -berkdb
Teraz przystąpmy do instalacji
emerge -av subversion
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-db/sqlite-3.6.13 USE="threadsafe -debug -doc -soundex -tcl" 2,716 kB
[ebuild N ] net-misc/neon-0.28.4 USE="nls ssl zlib -doc -expat -gnutls -kerberos -pkcs11 -socks5" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 758 kB
[ebuild N ] virtual/perl-MIME-Base64-3.07 0 kB
[ebuild N ] dev-perl/URI-1.35 94 kB
[ebuild N ] dev-util/subversion-1.6.2 USE="apache2 dso nls perl python webdav-neon -bash-completion -berkdb -ctypes-python -debug -doc -emacs -extras -gnome-keyring -java -ruby -sasl -test -vim-syntax -webdav-serf" 5,343 kB
Total: 5 packages (5 new), Size of downloads: 8,910 kB
Would you like to merge these packages? [Yes/No]
Jak widać flaga berkdb jest nieaktywna - czyli tak jak chcieliśmy. Zatem rozpocznijmy instalację - enter. Następuje konfiguracja i instalacja kolejnych pakietów z powyższej listy, zgodnie z kolejnością ich wyświetlania. Kolejne kroki instalacji odpowiadają krokom, które należy przejść przy ręcznej instalacji pakietu (configure, make, make install). Tyle tylko, że są one zautomatyzowane, ustystematyzowane i zgodne z konwencją (tak bardzo ważne słowo, które znacznie ułatwia życie jeśli się żyje w zgodzie z nim), powtórzmy KONWENCJĄ przyjętą w Gentoo. Zdejmuje to z nas ciężar pamiętania o tym co, gdzie z jakimi flagami i jak zostało zainstalowane. Od tej pory odpowiedzialność za pakiet, a w szczególności jego aktualizacje zrzucamy na barki Gentoo.
i to by było na tyle na dziś...
Przydatne linki:
Gentoo Portage part 1
Gentoo Portage part 2
Subversion Book
czwartek, 2 lipca 2009
PortageXS - narzędzia przydatne w zarządzaniu pakietami
Znalazłem ostatnio w portage'u ciekawy projekt - PortageXS. Jest to napisana w Perl'u (no niestety - nie Ruby - coż) warstwa abstrakcji służąca do zarządzania systemem portage z poziomu skryptu Perl.
Warto zainstalować to narządko w swoim systemie. Można to zrobić tak:
Po zainstalowaniu warto sprawdzić jakie pliki zostały zainstalowane. To można zrobić za pomocą narzędzia equery, które znajduje się w pakiecie gentoolkit. Jeśli nie macie tego w swoim systemie - pora zainstalować to za pomocą komendy emerge:
Teraz możemy już wyświetlić listę zainstalowanych przez pakiet PortageXS plików:
Są przykładowe skrypty, spróbojmy uruchomić:
i wiele innych, które prezentują możliwości tej biblioteki.
Polecam do lektury:
* man equery
* man emerge
Warto zainstalować to narządko w swoim systemie. Można to zrobić tak:
# emerge -av PortageXS
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] dev-perl/PortageXS-0.02.09 USE="-minimal" 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB
Would you like to merge these packages? [Yes/No]
Po zainstalowaniu warto sprawdzić jakie pliki zostały zainstalowane. To można zrobić za pomocą narzędzia equery, które znajduje się w pakiecie gentoolkit. Jeśli nie macie tego w swoim systemie - pora zainstalować to za pomocą komendy emerge:
# emerge -av gentoolkit
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] app-portage/gentoolkit-0.2.4.5 [0.2.4.2-r1] 87 kB
Total: 1 package (1 new), Size of downloads: 87 kB
Would you like to merge these packages? [Yes/No]
Teraz możemy już wyświetlić listę zainstalowanych przez pakiet PortageXS plików:
equery files PortageXS
[ Searching for packages matching PortageXS... ]
* Contents of dev-perl/PortageXS-0.02.09:
/etc
/etc/init.d
/etc/init.d/portagexsd
/etc/portagexs
/etc/portagexs/categories
/etc/portagexs/certs
/etc/portagexs/init.d
.....
/usr/lib/perl5/vendor_perl/5.8.8/PortageXS/examples/searchPackageByMaintainer.pl
/usr/lib/perl5/vendor_perl/5.8.8/PortageXS/examples/spinner.pl
/usr/sbin
/usr/sbin/portagexsd
/usr/share
/usr/share/doc
/usr/share/doc/PortageXS-0.02.09
/usr/share/doc/PortageXS-0.02.09/Changes.bz2
/usr/share/doc/PortageXS-0.02.09/README.bz2
Są przykładowe skrypty, spróbojmy uruchomić:
# /usr/lib/perl5/vendor_perl/5.8.8/PortageXS/examples/getArch.pl
Arch: x86
i wiele innych, które prezentują możliwości tej biblioteki.
Polecam do lektury:
* man equery
* man emerge
środa, 1 lipca 2009
Darmowy system - darmowa nauka
Właśnie pojawiła się w sieci darmowa książka o Linuksie. Niestety (jak dla mnie) wygląda na to, że opiera się ona na dystrybucji SuSE.
hmmm... w sumie nie ma się co dziwić skoro została opracowana przez Novella. Mimo wszystko myślę, że warto się bliżej temu przyjrzeć. Jeżeli korzystamy z Linuksa jako desktopa to jak najbardziej polecam SuSE :).
hmmm... w sumie nie ma się co dziwić skoro została opracowana przez Novella. Mimo wszystko myślę, że warto się bliżej temu przyjrzeć. Jeżeli korzystamy z Linuksa jako desktopa to jak najbardziej polecam SuSE :).
wtorek, 30 czerwca 2009
Pisanie skryptów administracyjnych z wykorzystaniem języka Ruby.
Krótka poranna wstawka. Naukę można zacząć od interaktywnej konsoli Ruby. Zwie się to irb. Jeśli ktoś nie ma zainstalowanego Ruby na swojej stacji - nic straconego - wystarczy przeglądarka. Pod adresem Try Ruby zaznajomić z językiem. Miłej zabawy.
niedziela, 28 czerwca 2009
Oracle Text nie działa (Error DRG-10700: preference does not exist: CTXSYS.DEFAULT_LEXER)
Podczas próby utworzenia pełnotekstowego indeksu dostaję taki błąd:
czyli jakby był (poprawnie) zainstalowany, a jednak czegoś mu brakuje.
Warto zwrócić uwagę na linię preference does not exist: CTXSYS.DEFAULT_LEXER. Nie zainstalowano wymaganych domyślnych ustawień językowych (warto zajrzeć tu). W celu instalacji należy uruchomić plik drdefXX.sql, gdzie XX to wersja językowa z której chcemy skorzystać. W moim wypadku będzie to us. Szukam pliku:
Użytkownik CTXSYS istnieje, Oracle Text się identyfikuje jako:
SQL> CREATE INDEX ap_values_idx ON asset_property(value) INDEXTYPE IS CTXSYS.CONTEXT
2 ;
CREATE INDEX ap_values_idx ON asset_property(value) INDEXTYPE IS CTXSYS.CONTEXT
*
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: Oracle Text error:
DRG-10700: preference does not exist: CTXSYS.DEFAULT_LEXER
ORA-06512: at "CTXSYS.DRUE", line 160
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 364
SQL> select * from ctx_version;
VER_DICT VER_CODE
---------- ----------
10.2.0.1.0 10.2.0.1.0
czyli jakby był (poprawnie) zainstalowany, a jednak czegoś mu brakuje.
Warto zwrócić uwagę na linię preference does not exist: CTXSYS.DEFAULT_LEXER. Nie zainstalowano wymaganych domyślnych ustawień językowych (warto zajrzeć tu). W celu instalacji należy uruchomić plik drdefXX.sql, gdzie XX to wersja językowa z której chcemy skorzystać. W moim wypadku będzie to us. Szukam pliku:
# cd /usr/lib/oracleJest. Spróbujmy wykonać skrypt:
# find -name drdef*
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefe.sql
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefptb.sql
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefzhs.sql
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefja.sql
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefko.sql
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefzht.sql
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdeff.sql
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefd.sql
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefi.sql
./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefus.sql
# su - oraclexeI mamy działający Oracle Text.
$
sqlplus ctxsys/<password> @./app/oracle/product/10.2.0/server/ctx/admin/defaults/drdefus.sql
SQL*Plus: Release 10.2.0.1.0 - Production on Sun Jun 28 10:13:46 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Creating lexer preference...
PL/SQL procedure successfully completed.
Creating wordlist preference...
PL/SQL procedure successfully completed.
Creating stoplist...
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
Creating default policy...
PL/SQL procedure successfully completed.
sobota, 27 czerwca 2009
Instalacja pakietów w dystrybucji gentoo na przykładzie serwera subversion. Część I
Dystrybucja Gentoo zaadaptowała jedną z lepszych rzeczy jakie udało się wymyślić projektom z rodziny BSD, coś co nazywamy portami (ports). Oczywiście porty w wykonaniu BSD to wykorzystanie w bardzo ubogi sposób plików Makefile do kompilacji i instalacji pakietów ze źródeł. Co to tak dokładnie oznacza?
Proponuję zajrzeć tu ponieważ nie zamierzam wiernie przeklajać treści, które bardzo dobrze opisują system portage:
- portage - wikipedia
- oficjalna dokumentacja Gentoo
Ponieważ przy pisaniu bloga mam zamiar prowadzić swoją listę zalet i wad Gentoo - dopisuję pierwszą zaletę:
- Rewelacyjny system zarządzania instalacją oprogramowania - Portage.
Co tak naprawdę przemawia do mnie w portage?
- na pewno to, że za jego pomocą (korzystając z repoozytorium systemowego - głównego) zainstaluję pakiety typu mplayer, skype, kadu, adobe acrobat, itd. A moje działanie ograniczy się w najprostszym wypadku do wydania polecenia (przy instalacji skype):
- dodatkowo przy aktualizacji danego pakietu USE-flagi dają mi szybko wgląd w to jak w pakiecie zmieniła się funkcjonalność. Zapewnione to jest przez kolorowanie obsługiwanych przez pakiet flag i odpowiednie oznaczenie nowych flag w danej wersji softu.
- pakiety podzielone na kategorie
- możesz skonfigurować system dokładnie pod swoją architekturę sprzętową. Większość dystrybucji dostarcza pakiety skompilowanie pod i386, co poniektóre dodają i686. Tu możemy skorzystać z pełnych możliwości jakich nam dostarcza nasz hardware (choć musimy oczywiście wiedzieć co robimy)
Wadą Gentoo, która niejednej osobie dała się we znaki jest:
- konieczność kompilacji wszystkiego - spowalnia to zdecydowanie czas instalacji (choć widziałem pakety binarne, które wykonywały czynności okołoinstalacyjne nieraz dłużej niż zajmowała kompletna instalacja pod Gentoo). Na kompilację są sposoby (ccache, distcc) lub tworzenie pakietów (pkg, rpm) - kompilacja na jednej maszynie i rozprowadzenie skompilowanego pakietu na pozostałe maszyny. Gentoo posiada do tego ciekawy mechanizm, z którego muszę się przyznać nie korzystałem - catalyst
Z pozostałych warto powiedzieć o:
- rozmiarze, który drzewo portage zajmuje na dysku.
... dobra wracam do głównego nurtu
Część praktyczna
Zacznijmy więc instalację subversion.
Zakładam, że mamy skonfigurowany system portage (o tym opowiem następnym razem dość szczegółowo). Główny plik konfiguracyjny instalatora Gentoo - polecenia emerge - to plik /etc/make.conf.
A więc do dzieła:
U - update (zostanie zainstalowany pakiet w nowszej wersji)
F - fetch (pakiet źródłowy musi być ściągniety przez użytkownika, np. w wypadku sun-java-1.4, ponieważ musimy zaakceptować licencję na stronie SUNa. Podobnie jest z wieloma innymi pakietami np. Oracle'a. Jednak lepsze to niż nie mieć pakietu w repozytorium i samemu się borykać z jego ręczną instalacją)
f - fetch (jak poprzednio z tą różnicą, że pakiet jest już ściągnięty)
D - downgrade (zostanie zainstalowana starsza wersja pakietu - dzieje się to najczęściej gdy zainstalowany był pakiet zamaskowany)
S - pakiet slotowany (instalujemy inną wersję danego pakietu bez odinstalowywania istniejących w systemie- np. sun-jre-1.4, sun-jre-1.5 mogą być zainstalowane obok siebie w systemie i zamiennie używane w zależności od potrzeb)
R - reinstalacja (pakiet będzie przeinstalowany - numer wersji pozostaje ten sam)
I - interactive (wymagana interakcja z użytkownikiem - hmm chyba się z takim nie spotkałem - domyślam się, że może chodzić o akceptację umowy licencyjnej, etc.)
B - blocked (instalacja pakietu blokowana przez inny zainstalowany pakiet)
b - blocked (instalacja blokowana przez inny pakiet, jednak system portage rozwiąże automatycznie ten problem)
W nawiasie pojawia się też tajemniczy wyraz ebuild - jest to program, bezpośredni interfejs do systemu portage. Emerge instalując pakiety tak naprawdę wywołuje w odpowiedniej sekwencji program ebuild z właściwym parametrem (man ebuild).
W dalszej części linijki mamy nazwę pakietu wraz z wersją (subversion-1.6.2) poprzedzoną nazwą kategorii do której został on zaliczony (dev-util - narzędzia developerskie). Informacje te odzwierciedlają strukturę, która znajduje się w katalogu /usr/portage, gdzie znajduje się całe drzewo portage (ciekawskich zachęcam do sprawdzenia).
Kolejna część to:
USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -ctypes-python -debug -doc -emacs -extras"
Jest to informacja na temat flag USE (funkcjonalności), które pakiet obsługuje. Znak '-' minus mówi nam, że dana funkcjonalność nie zostanie włączona w bieżącej instalacji. Flagi w większości wypadków są opisowe. Jednak jeżeli dana flaga nic nam nie mówi możemy użyć polecenia euse:
Proponuję zajrzeć tu ponieważ nie zamierzam wiernie przeklajać treści, które bardzo dobrze opisują system portage:
- portage - wikipedia
- oficjalna dokumentacja Gentoo
Ponieważ przy pisaniu bloga mam zamiar prowadzić swoją listę zalet i wad Gentoo - dopisuję pierwszą zaletę:
- Rewelacyjny system zarządzania instalacją oprogramowania - Portage.
Co tak naprawdę przemawia do mnie w portage?
- na pewno to, że za jego pomocą (korzystając z repoozytorium systemowego - głównego) zainstaluję pakiety typu mplayer, skype, kadu, adobe acrobat, itd. A moje działanie ograniczy się w najprostszym wypadku do wydania polecenia (przy instalacji skype):
emerge skype- to, że gdy instaluję nowy pakiet widzę na podstawie USE-flag jakie możliwości mi daje lub jaką ma mniej więcej funkcjonalność (ale o tym za chwilę - omówię to na przykładzie).
System sam za mnie ściągnie pakiet z sieci i go zainstaluje. Spróbujcie zrobić to samo w innej dystrybucji. Nie znam takiej. W każdej z przez mnie testowanych (a było ich wiele) wymagane jest dodanie nowych repozytoriów, które nie zawsze dają powody żeby im kompletnie ufać (są to często repozytoria prowadzone przez osoby prywatne lub organizacje nieściśle związane z fundacją/firmą/etc. prowadzącą daną dystrybucję) - a to przecież musimy zrobić żeby zainstalować pakiet, którego nie ma w repozytorium dystrybucji.
- dodatkowo przy aktualizacji danego pakietu USE-flagi dają mi szybko wgląd w to jak w pakiecie zmieniła się funkcjonalność. Zapewnione to jest przez kolorowanie obsługiwanych przez pakiet flag i odpowiednie oznaczenie nowych flag w danej wersji softu.
- pakiety podzielone na kategorie
- możesz skonfigurować system dokładnie pod swoją architekturę sprzętową. Większość dystrybucji dostarcza pakiety skompilowanie pod i386, co poniektóre dodają i686. Tu możemy skorzystać z pełnych możliwości jakich nam dostarcza nasz hardware (choć musimy oczywiście wiedzieć co robimy)
Wadą Gentoo, która niejednej osobie dała się we znaki jest:
- konieczność kompilacji wszystkiego - spowalnia to zdecydowanie czas instalacji (choć widziałem pakety binarne, które wykonywały czynności okołoinstalacyjne nieraz dłużej niż zajmowała kompletna instalacja pod Gentoo). Na kompilację są sposoby (ccache, distcc) lub tworzenie pakietów (pkg, rpm) - kompilacja na jednej maszynie i rozprowadzenie skompilowanego pakietu na pozostałe maszyny. Gentoo posiada do tego ciekawy mechanizm, z którego muszę się przyznać nie korzystałem - catalyst
Z pozostałych warto powiedzieć o:
- rozmiarze, który drzewo portage zajmuje na dysku.
... dobra wracam do głównego nurtu
Część praktyczna
Zacznijmy więc instalację subversion.
Zakładam, że mamy skonfigurowany system portage (o tym opowiem następnym razem dość szczegółowo). Główny plik konfiguracyjny instalatora Gentoo - polecenia emerge - to plik /etc/make.conf.
A więc do dzieła:
# emerge --ask --verbose subversionOjoj, troszkę tego jest. Pięć pakietów do instalacji. Dlaczego? Ponieważ instalacja subversion wymusza na portage'u konieczność instalacji dodatkowych pakietów, od których zależy poprawne funkcjonowanie subversion. Skupmy się wyłącznie na linijce z interesującym nas programem:
lub zamienie z krótkimi opcjami (gdy już nabierzemy wprawy):
# emerge --av subversion
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-db/sqlite-3.6.13 USE="threadsafe -debug -doc -soundex -tcl" 2,716 kB
[ebuild N ] net-misc/neon-0.28.4 USE="nls ssl zlib -doc -expat -gnutls -kerberos -pkcs11 -socks5" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 758 kB
[ebuild N ] virtual/perl-MIME-Base64-3.07 0 kB
[ebuild N ] dev-perl/URI-1.35 94 kB
[ebuild N ] dev-util/subversion-1.6.2 USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -ctypes-python -debug -doc -emacs -extras -gnome-keyring -java -ruby -sasl -test -vim-syntax -webdav-serf" 5,343 kB
Total: 5 packages (5 new), Size of downloads: 8,910 kB
Would you like to merge these packages? [Yes/No]
[ebuild N ] dev-util/subversion-1.6.2 USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -ctypes-python -debug -doc -emacs -extras"Pierwsza część - w nawiasach kwadratowych mowi nam o statusie pakietu. W naszym wypadku jest to nowy pakiet (literka N). Pozostałe możliwe oznaczenia to:
U - update (zostanie zainstalowany pakiet w nowszej wersji)
F - fetch (pakiet źródłowy musi być ściągniety przez użytkownika, np. w wypadku sun-java-1.4, ponieważ musimy zaakceptować licencję na stronie SUNa. Podobnie jest z wieloma innymi pakietami np. Oracle'a. Jednak lepsze to niż nie mieć pakietu w repozytorium i samemu się borykać z jego ręczną instalacją)
f - fetch (jak poprzednio z tą różnicą, że pakiet jest już ściągnięty)
D - downgrade (zostanie zainstalowana starsza wersja pakietu - dzieje się to najczęściej gdy zainstalowany był pakiet zamaskowany)
S - pakiet slotowany (instalujemy inną wersję danego pakietu bez odinstalowywania istniejących w systemie- np. sun-jre-1.4, sun-jre-1.5 mogą być zainstalowane obok siebie w systemie i zamiennie używane w zależności od potrzeb)
R - reinstalacja (pakiet będzie przeinstalowany - numer wersji pozostaje ten sam)
I - interactive (wymagana interakcja z użytkownikiem - hmm chyba się z takim nie spotkałem - domyślam się, że może chodzić o akceptację umowy licencyjnej, etc.)
B - blocked (instalacja pakietu blokowana przez inny zainstalowany pakiet)
b - blocked (instalacja blokowana przez inny pakiet, jednak system portage rozwiąże automatycznie ten problem)
W nawiasie pojawia się też tajemniczy wyraz ebuild - jest to program, bezpośredni interfejs do systemu portage. Emerge instalując pakiety tak naprawdę wywołuje w odpowiedniej sekwencji program ebuild z właściwym parametrem (man ebuild).
W dalszej części linijki mamy nazwę pakietu wraz z wersją (subversion-1.6.2) poprzedzoną nazwą kategorii do której został on zaliczony (dev-util - narzędzia developerskie). Informacje te odzwierciedlają strukturę, która znajduje się w katalogu /usr/portage, gdzie znajduje się całe drzewo portage (ciekawskich zachęcam do sprawdzenia).
Kolejna część to:
USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -ctypes-python -debug -doc -emacs -extras"
Jest to informacja na temat flag USE (funkcjonalności), które pakiet obsługuje. Znak '-' minus mówi nam, że dana funkcjonalność nie zostanie włączona w bieżącej instalacji. Flagi w większości wypadków są opisowe. Jednak jeżeli dana flaga nic nam nie mówi możemy użyć polecenia euse:
# euse -i nlsOpis euse - zostawiam do następnego razu. Jest już późno.
global use flags (searching: nls)
************************************************************
[+ D ] nls - Adds Native Language Support (using gettext - GNU locale utilities)
local use flags (searching: nls)
************************************************************
[+ D ] nls (app-portage/eix):
Support foreign language messages (experimental; currently only de)
[+ D ] nls (net-analyzer/rrdtool):
Enable native language support (using intltool)
[+ D ] nls (net-irc/rbot):
Build and install translation for the messages coming from the bot and its plugins (through dev-ruby/ruby-gettext).
piątek, 26 czerwca 2009
Zdalny pipe
Dziś kolega 'junior admin' podniecił się strasznie możliwością przekierowywania standardowego wyjścia programu na standardowe wejście kolejnego między lokalnym i zdalnym systemem, czyli tzw. pipem. Zacznijmy od dwóch przykładów, które mi podesłał:
Następnie mamy | czyli przekierowanie/przekazanie standardowego wyjścia poprzednio wykonywanej komendy (opisanej już jedyneczki) na standardowe wejście kolejnej komendy (STDIN - czyli deskryptor pliku o identyfikatorze 0 [zero])
Kolejnym poleceniem jest wywołanie ssh - nawiąż połączenie z hostem remotehost i wykonaj polecenia podane jako kolejny parametr. Podajemy je w cudzysłowiu, żeby bash w trakcie przetwarzania nie potraktował spacji jako separatora kolejnych argumentów (pewnie poleciałyby błedy - można spróbować - na pewno coś 'chorego' się stanie. O interpretacji linii poleceń przez shell to może innym razem - jak ktoś z czytelników będzie bardzo tego chciał).
Pozostaje więc ostatnia część:
Drugi przypadek pozostawiam do samodzielnej analizy. W razie problemów i pytań służę pomocą
Do samodzielnej lektury polecam wikipedię
A co w wypadku gdy łączymy kilka poleceń w pipe? Jak wykryć, że któreś (nieostatnie) polecenie wykonało się niepoprawnie?
Odpowiedź w przyszłym blogu...
Może warto poszukać samemu?
Czekam na komentarze...
W pierwszej linijce pakujemy (bez kompresji) zadaną jako drugi parametr listę plików, pierwszym parametrem jest w tym wypadku znak '-' często używany jeśli chcemy uzyskać coś na STDOUT zamiast zapisać gdzieś w pliku, gdy program to umożliwia. Tak więc znak '-' informuje polecenie tar, że zamiast zapisywać tworzone archiwum do pliku ma wyrzucić wynik na standardowe wyjście (czyli w linuksie plik o deskryptorze 1).tar cf - whatever | ssh remotehost " ( cd /some/path ; tar xf - ) "
ssh remotehost "( cd /somewhere ; tar cf - something ) " | tar xf -
Następnie mamy | czyli przekierowanie/przekazanie standardowego wyjścia poprzednio wykonywanej komendy (opisanej już jedyneczki) na standardowe wejście kolejnej komendy (STDIN - czyli deskryptor pliku o identyfikatorze 0 [zero])
Kolejnym poleceniem jest wywołanie ssh - nawiąż połączenie z hostem remotehost i wykonaj polecenia podane jako kolejny parametr. Podajemy je w cudzysłowiu, żeby bash w trakcie przetwarzania nie potraktował spacji jako separatora kolejnych argumentów (pewnie poleciałyby błedy - można spróbować - na pewno coś 'chorego' się stanie. O interpretacji linii poleceń przez shell to może innym razem - jak ktoś z czytelników będzie bardzo tego chciał).
Pozostaje więc ostatnia część:
cd /some/path ; tar xf -To już dosyć proste - zmieniamy ścieżkę i rozpakowujemy archiwum poleceniem tar (x - extract). Pojawia się znowu magiczny minus. W wypadku rozpakowywania (jak co poniektórzy pewnie się domyślają) minus mówi o tym, że źródłem z którego należy czytać nie jest plik a standardowe wejście (przytaczane wcześniej zero).
Drugi przypadek pozostawiam do samodzielnej analizy. W razie problemów i pytań służę pomocą
Do samodzielnej lektury polecam wikipedię
- wersja angielska
- polska - też jest ale jest dużo mniej informacji
echo $?Jeżeli program wykonał się poprawnie - nie pojawiły się błędy - to status powinien być równy 0 [zero]. W przypadku problemów będzie to cyfra różna od zero - to co będzie oznaczać zależy już od programu. Warto sprawdzać tą zmienną pisząc skrypty - przez co możemy przerwać je w odpowiednim momencie, gdy coś pójdzie nie tak a nie zostawić wszystko dalszemu biegowi wypadków.
A co w wypadku gdy łączymy kilka poleceń w pipe? Jak wykryć, że któreś (nieostatnie) polecenie wykonało się niepoprawnie?
Odpowiedź w przyszłym blogu...
Może warto poszukać samemu?
Czekam na komentarze...
czwartek, 25 czerwca 2009
kopiowanie plików na zdalne serwery
Możliwości jest wiele. Od prostego scp, przez rsync'a wywoływanego na wiele sposobów, poprzez netcat'a, montowanie zdalnego zasobu przez sshfs lub temu podobne drivery do sftp, żeby nie wspomnieć tu o standardowym ftp lub uniksowych nfs-ach. Znalazło by się jeszcze wiele innych, o których albo nie pamiętam albo w momencie pisania nie przyszły mi do głowy. Open source - open mind.
Najprościej można tak:
scp plik_lokalny [user@]host_zdalny:/sciezka/w/filesystemie [-p 22]
-p 22 to port na który łączymy się ze zdalnym hostem.
Popatrz tez w man. Warto z tego polecenia często korzystać - szczególnie na początku, gdy system kryje w sobie mnóstwo tajemnic.
i pojedynczy plik jest skopiowany o ile użytkownik może pisać w określonej zdalnej lokalizacji.
Skopiowaliśmy pojedynczy plik. A co jeśli chcemy skopiować część struktury katalogów. Powiedzmy podkatalog '/home/foo'. Użyjmy przełącznika -r (recursive). Musimy uważać jedynie na symlinki (o tym innym razem) ponieważ scp podąży za tymi linkami i zamiast skopiować informację o linku - przeniesie nam całą zawartość, na którą wskazuje symlink - a to może kosztować sporo miejsca i powielić nam struktury w filesystemie. Zamiast -r często warto najpierw skompresować zawartość, którą zamierzamy przenieść i nie przejmować się problemami związanymi z użyciem przełącznika -r.
Przypomniało mi się jeszcze o dd. Można też w pipe puścić wejście dd i z drugie strony tunelu ssh zapisać do pliku wynikowego. Ale o tym może innym razem.
Jest jeszcze conajmnie jeden problem, który jest związany z użyciem scp. Mianowicie gdy coś nam przerwie transmisję, to możemy śmiało zaczynać kopiowanie od zera - nic się nie da zrobić (przynajmniej tak mi się wydaje).
Warto wtedy pomyśleć o użyciu
Jako przykład, z którego korzystałem przed chwilką podam:
rsync galeria.tar.bz2 -ave ssh ssh.linuxway.eu:/home/galeria.tar.bz2
Zgłębienie składni pozostawiam czytelnikowi.
- SCP
Najprościej można tak:
scp plik_lokalny [user@]host_zdalny:/sciezka/w/filesystemie [-p 22]
-p 22 to port na który łączymy się ze zdalnym hostem.
Popatrz tez w man. Warto z tego polecenia często korzystać - szczególnie na początku, gdy system kryje w sobie mnóstwo tajemnic.
i pojedynczy plik jest skopiowany o ile użytkownik może pisać w określonej zdalnej lokalizacji.
Skopiowaliśmy pojedynczy plik. A co jeśli chcemy skopiować część struktury katalogów. Powiedzmy podkatalog '/home/foo'. Użyjmy przełącznika -r (recursive). Musimy uważać jedynie na symlinki (o tym innym razem) ponieważ scp podąży za tymi linkami i zamiast skopiować informację o linku - przeniesie nam całą zawartość, na którą wskazuje symlink - a to może kosztować sporo miejsca i powielić nam struktury w filesystemie. Zamiast -r często warto najpierw skompresować zawartość, którą zamierzamy przenieść i nie przejmować się problemami związanymi z użyciem przełącznika -r.
Przypomniało mi się jeszcze o dd. Można też w pipe puścić wejście dd i z drugie strony tunelu ssh zapisać do pliku wynikowego. Ale o tym może innym razem.
Jest jeszcze conajmnie jeden problem, który jest związany z użyciem scp. Mianowicie gdy coś nam przerwie transmisję, to możemy śmiało zaczynać kopiowanie od zera - nic się nie da zrobić (przynajmniej tak mi się wydaje).
Warto wtedy pomyśleć o użyciu
- rsync
Jako przykład, z którego korzystałem przed chwilką podam:
rsync galeria.tar.bz2 -ave ssh ssh.linuxway.eu:/home/galeria.tar.bz2
Zgłębienie składni pozostawiam czytelnikowi.
Subskrybuj:
Posty (Atom)
