poniedziałek, 13 lipca 2009

Co nieco o euse i innych

Ponieważ pewnie wiele osób zauważyło, że euse nie jest demonem szybkości, warto zastanowić się nad alternatywami. Wcześniej jednak spróbujmy znaleźć powód wolnego działania euse.
Zaczynamy!
Gdzie znajduje się program euse:

# which euse

/usr/bin/euse

OK, mamy. Teraz nauczmy się wykorzystywać przydatne skróty shella. Strzałki w górę i dół na klawiaturze umożliwiają nam nawigację w historii wykonanych poleceń. Więc strzałka w górę i mamy poprzednio wykonane polecenie. Teraz naciśnijmy HOME i jesteśmy na początku linii, END - na jej końcu. O tym jak konfigurować własne skróty opowiem innym razem.
Wykorzystując tą wiedzę co by się za dużo nie napisać zmodyfikujmy tę linię, tak żeby zobaczyć czym jaki jest typ pliku euse:

# file `which euse`
/usr/bin/euse: Bourne-Again shell script text executable


aha - czyli skrypt Bash. Polecenie file wyświetla nam na podstawie swojej bazy informacje na temat typu pliku (polecam do szczegółowej lektury man).
Czym jest zaś tajemniczy ` - backquote (backtick)?
W tym miejscu następuje podmiana wywołania polecenia na wartość zwróconą po jego wykonaniu (command substitution lub bardziej po polsku - cytowanie polecenia). Czyli wszystko co znajdzie się pomiędzy znakami ` jest wykonywane a następnie wynik zwrócony jest podstawiany w to miejsce. Wywołania z użyciem backtick'ów (odwrotny apostrof) można zagnieżdżać, należy jednak pamiętać wtedy o użyciu znaku maskującego \ (tzw. backslasha). Backtick jest szczególnie użyteczny w skryptach, gdy chcemy podstawić gdzie możemy wykorzystać go do podstawienia wyniku wykonania polecenia pod zmienną (np.: ZMIENNA=`ls -l`). Zamiennie z backtickiem można stosować konstrukcję $(polecenie).

Skoro zaczynamy powoli wchodzić w shella nasuwają mi się dwa pytanka, a mianowicie:
- po czym poznać czy dana komenda to polecenie zewnętrzne, czy wbudowana komenda basha?
- dlaczego cd jest wbudowany w bash?

Zostawiam je na razie jako zadanie domowe - spróbujcie pogłówkować.

Teraz gdy dowiedzieliśmy się paru nowych rzeczy warto popatrzyc w źródła euse (nie zapomnijcie o wykorzystywaniu opisanych skrótów):

vim `which euse`

Ponieważ - jak stwierdziliśmy wcześniej - wyświetlanie informacji o flagach jest wolne skupmy się na tej operacji i trochę pogmerajmy w kodzie. Informacje wyświetlamy za pomocą opcji -i - poszukajmy:

while [ -n "${1}" ]; do
case "${1}" in
-h | --help) MODE="showhelp";;
-v | --version) MODE="showversion";;
-i | --info) MODE="showdesc";;
-I | --info-installed) MODE="showinstdesc";;
-l | --local) SCOPE="local";;
-g | --global) SCOPE="global";;
-a | --active) MODE="showflags";;
-E | --enable) MODE="modify"; ACTION="add";;
-D | --disable) MODE="modify"; ACTION="remove";;
-P | --prune) MODE="modify"; ACTION="prune";;
-*)


Jest w pętli odpowiedzialnej za odczyt argumentów wywołania (opcji) programu/skryptu (o tym innym razem). Jak widać (mniej lub bardziej) użycie tej opcji powoduje ustawienie w skrypcie zmiennej MODE na wartość showdesc.
Co się dzieje dalej?
Na samym końcu skryptu znajdziemy:

##### main program comes now #####

# disable globbing as it fucks up with args=*
set -f
parse_arguments "$@"
check_sanity

eval ${MODE} ${ARGUMENTS}
set +f


Jak widać mamy tu cały przepływ programu - kolejno wywołanie funkcji (zdefiniowanych powyżej) parse_arguments (parsowanie opcji), check_sanity (pomijam - pewnie sprawdzanie poprawności wywołania, opcji, etc.) i wykonanie funkcji o nazwie zdefiniowanej w zmiennej MODE (i wszystko się wyjaśniło - o eval powiem innym razem). Zaglądnijmy do tej funkcji (showdesc):

# This function takes a list of use flags and shows the status and
# the description for each one, honoring $SCOPE
showdesc() {
local descdir
local current_desc
local found_one
local args

args="${*:-*}"

if [ -z "${SCOPE}" ]; then
SCOPE="global" showdesc ${args}
echo
SCOPE="local" showdesc ${args}
return
fi

descdir="$(get_portdir)/profiles"

[...]

while [ -n "${1}" ]; do
if [ "${SCOPE}" == "global" ]; then
if grep "^${1} *-" "${descdir}/use.desc" > /dev/null; then
get_flagstatus "${1}"
foundone=1
fi
grep "^${1} *-" "${descdir}/use.desc"
fi
# local flags are a bit more complicated as there can be multiple
# entries per flag and we can't pipe into printf
if [ "${SCOPE}" == "local" ]; then
if grep ":${1} *-" "${descdir}/use.local.desc" > /dev/null; then
foundone=1
fi
grep ":${1} *-" "${descdir}/use.local.desc" \
| sed -e "s/^\([^:]\+\):\(${1}\) *- *\(.\+\)/\1|\2|\3/g" \
| while read line; do
pkg="$(echo $line | cut -d\| -f 1)"
flag="$(echo $line | cut -d\| -f 2)"
desc="$(echo $line | cut -d\| -f 3)"
get_flagstatus "${flag}"
printf "%s (%s):\n%s\n\n" "${flag}" "${pkg}" "${desc}"
done
fi
shift
done


Przy okazji takiego grzebania można sie trochę nauczyć i dowiedzieć o Gentoo i portage'u. Jak widać opisy flag globalnych - znajdują się w pliku profiles/use.desc w katalogu głównym systemu portage, natomiast flagi zdefiniowane w poszczególnych paczkach (lokalne) - w profiles/use.local.desc.
Patrząc na pętle łatwo zauważyć, że wyszukiwanie odbywa się za pomocą polecenia grep (o tym innym razem). W wypadku flag globalnych operacja jest dość szybka, jednak komplikuje się i wydłuża przy flagach lokalnych ze względu na ich format (warto zaglądnąć do tych plików). No i już wiemy dlaczego to tyle trwa.

Przeglądając źródła warto zwrócić jeszcze uwagę na komendę set +f/set -f, która odpowiada za obsługę globbingu w shellu - w skrócie ubogiego krewnego wyrażeń regularnych (o tym innym razem). Tu została zastosowana, żeby ominąć jej rozwinięcie/ewaluację w shellu - widać chłopaki mieli pewien problem z tym przy wywołaniu.

PS. Następnym razem opowiem o innych narzędziach do zarządzania flagami.
Zmieniam też nieco tryb pisania z pn-sobota na pn/sr/pt

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:

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

piątek, 10 lipca 2009

visudo - cóż to jest?

Ponieważ ktoś mnie ostatnio zagadnął apropos informacji znalezionych na blogu - odpowiem szybko jak mi się wydaje - cóż to jest.

Visudo to nic innego jak narzędzie przygotowane specjalnie na potrzeby edycji pliku /etc/sudoers, w którym przechowywana jest konfiguracja polecenia sudo - zdefiniowane są uprawnienia - kto co i jak może uruchomić w systemie.
Visudo korzysta domyślnie z aktualnie zdefiniowanego edytora tekstowego.
Krótka dygresja na temat edytora tekstowego
W systemie można zdefiniować edytor systemowy za pomocą zmiennej środowiskowej EDITOR. Warto sprawdzić co jest ustawione u nas:

# env|grep EDITOR
EDITOR=/usr/bin/vim


W każdej chwili możemy zmienić aktualnie używany edytor na dowolny - zmieniając ścieżkę edytora w zmiennej EDITOR.
W Gentoo ustawienia domyślnej wartości zmiennej EDITOR dokonujemy w pliku /etc/rc.conf (o tym innym razem).
Koniec krótkiej dygresji

Oczywiście plik /etc/sudoers możemy edytować za pomocą dowolnego edytora tekstu ale tylko visudo zapewni nam dwie rzeczy:
1. kontrolę poprawności konfiguracji (kontrolę składni)
2. blokadę przed równoczesnymi zmianami pliku /etc/sudoers

Jak zawsze polecam czytanie manuala (man visudo) - RTFM!

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):

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:

# 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

wtorek, 7 lipca 2009

Instalacja pakietów w dystrybucji gentoo na przykładzie serwera subversion. Część III

Zakładam, że kompilacja przebiegła bezproblemowo. Jednymi z ostatnich komunikatów po instalacji w dystrybucji Gentoo są często informacje o tym co trzeba zrobić, żeby uzyskać w pełni funkcjonalny, działający produkt. To według mnie kolejna zaleta, która jest przydatna szczególnie wtedy gdy poruszamy się po nowym gruncie, tj. testujemy jakis nieznany nam w szczegółach pakiet a chcemy go szybko uruchomić. Instrukcja jest dobrze sformatowana, a ze względu na to, że korzystamy z kolorowej konsoli - trudno ją przeoczyć. Dodatkowo w przypadku instalacji kilku pakietów emerge na zakończenie instlacji wyświetli w podsumowaniu informacje z każdego z nich. Są jeszcze inne sposoby na to, żeby nie przeoczyć komunikatów (o tym innym razem).
W wypadku subversion wygląda to tak:

* Subversion Server Notes
* -----------------------
*
* If you intend to run a server, a repository needs to be created using
* svnadmin (see man svnadmin) or the following command to create it in
* /var/svn:
*
* emerge --config =dev-util/subversion-1.6.2
*
* Subversion has multiple server types, take your pick:
*
* - svnserve daemon:
* 1. Edit /etc/conf.d/svnserve
* 2. Fix the repository permissions (see "Fixing the repository permissions"
)
* 3. Start daemon: /etc/init.d/svnserve start
* 4. Make persistent: rc-update add svnserve default
*
* - svnserve via xinetd:
* 1. Edit /etc/xinetd.d/svnserve (remove disable line)
* 2. Fix the repository permissions (see "Fixing the repository permissions"
)
* 3. Restart xinetd.d: /etc/init.d/xinetd restart
*
* - svn over ssh:
* 1. Fix the repository permissions (see "Fixing the repository permissions"
)
* Additionally run:
* groupadd svnusers
* chown -R root:svnusers /var/svn/repos
* 2. Create an svnserve wrapper in /usr/local/bin to set the umask you
* want, for example:
* #!/bin/bash
* . /etc/conf.d/svnserve
* umask 007
* exec /usr/bin/svnserve ${SVNSERVE_OPTS} "$@"
*
* - http-based server:
* 1. Edit /etc/conf.d/apache2 to include both "-D DAV" and "-D SVN"
* 2. Create an htpasswd file:
* htpasswd2 -m -c /var/svn/conf/svnusers USERNAME
* 3. Fix the repository permissions (see "Fixing the repository permissions"
)
* 4. Restart Apache: /etc/init.d/apache2 restart
*
* Fixing the repository permissions:
* chmod -Rf go-rwx /var/svn/conf
* chmod -Rf g-w,o-rwx /var/svn/repos
* chmod -Rf g+rw /var/svn/repos/db
* chmod -Rf g+rw /var/svn/repos/locks
*
* If you intend to use svn-hot-backup, you can specify the number of
* backups to keep per repository by specifying an environment variable.
* If you want to keep e.g. 2 backups, do the following:
* echo '# hot-backup: Keep that many repository backups around' > /etc/env.d/80
subversion
* echo 'SVN_HOTBACKUP_BACKUPS_NUMBER=2' >> /etc/env.d/80subversion
*
* Subversion contains support for the use of Memcached
* to cache data of FSFS repositories.
* You should install "net-misc/memcached", start memcached
* and configure your FSFS repositories, if you want to use this feature.
* See the documentation for details.
*
>>> Regenerating /etc/ld.so.cache...

>>> Recording dev-util/subversion in "world" favorites file...


Emerge oprócz wymienionych już cech (instalacja, dobór flag, changelog, itd.) jest w stanie skonfigurować zainstalowany pakiet - oczywiście o ile ten pakiet posiada taką funkcjonalność (o tym innym razem). Jak widać, po instalacji menadżer pakietów zaleca mi skonfigurowanie pakietu. Mam to zrobić za pomocą komendy:


# emerge --config =dev-util/subversion-1.6.2


Configuring pkg...

* >>> Initializing the database in //var/svn ...
* >>> Populating repository directory ...
* >>> Setting repository permissions ...


Ponieważ w wypadku subversion istnieje kilka trybów uruchomienia serwera repozytorium, które podaje nam instrukcja - konieczne jest wykonanie instrukcji odpowiednich dla wybranego rodzaju pracy serwera. Dla mnie to dodatkowy plus jeśli chodzi o Gentoo - instalowane pakiety dostarczane są z dokładną instrukcją. Dzięki temu mam wgląd w podstawowe możliwości - co dodatkowo ułatwia zaznajomienie się z funkcjonalnością instalowanego pakietu.
Jak widać subversion może działać jako:
- osobny daemon (o tym innym razem)
- daemon uruchamiany w miarę potrzeby poprzez daemon'a xinetd (o tym innym razem).
- svn po ssh - czyli tunelowanie połączenia z repozytorium za pomocą ssh (o tym innym razem)
- usługa na protokole HTTP - poprzez serwer apache

Ja wybiorę repozytorium działające po protokole http.
Muszę więc wykonać czynności konfiguracyjne specyficzne dla serwera apache.
1. edycja pliku /etc/conf.d/apache2 i dodanie do zmiennej APACHE2_OPTS dwóch makr "-D DAV" i "-D SVN"
Zatrzymajmy się tu na chwilę - pojawiło się trochę nowości - wyjaśnię po kolei większość z nich.
Po pierwsze katalog /etc/conf.d - to specjalny katalog, w którym znajdują się ustawienia startowe poszczególnych usług uruchamianych w systemie. W innych dystrybucjach analogiczne informacje są często przechowywane w katalogu /etc/defaults. Tak więc plik /etc/conf.d/apache2 jest plikiem konfiguracyjnym skryptu startowego serwera apache. Skrypty startowe znajdują się w katalogu /etc/init.d i mają taką samą nazwę jak pliki konfiguracyjne z /etc/conf.d. Makro definiowane przez nas służy najczęściej (w wielkim skrócie) do tworzenia warunków w konfiguracji serwera przy których dany moduł lub dana konfiguracja ma być wczytana, np. możemy za pomocą niego definiować w konfiguracji kiedy moduł ma być wczytany. Pozwolę sobie wsadzić tu ni z gruszki ni z pietruszki fragment konfiguracji jaka mogła by być użyta w przypadku makra DAV:


< IfDefine DAV>
LoadModule mod_dav.so
</IfDefine>


2. Stworzenie pliku htpasswd:
# htpasswd2 -m -c /var/svn/conf/svnusers krzysiek

Plik ten wykorzystamy do przechowywania bazy użytkowników, którzy później bedą mieli dostęp do repozytorium, po wcześniejszym uwierzytelnieniu. Istnieje wiele mechanizmów uwierzytelniania użytkowników poprzez serwer apache (m.in. dlatego korzystamy z apache'a) - my w tej chwili skorzystamy z domyślnego jaki proponuje nam subversion.
3. Poprawki w ustawieniu uprawnień do plików:
# chmod -Rf go-rwx /var/svn/conf
# chmod -Rf g-w,o-rwx /var/svn/repos
# chmod -Rf g+rw /var/svn/repos/db
# chmod -Rf g+rw /var/svn/repos/locks


Muszę jeszcze skonfigurować serwer apache. Ponieważ na razie chcę uruchomić repozytorium skorzystam z gotowca. Ponieważ ustawiłem przy instalacji subversion USE flagę apache2 - zostały zainstalowane dodatkowe moduły do apache'a. Ich konfiguracja znajduje się w pliku /etc/apache2/modules.d/47_mod_dav_svn.conf. Wyedytuję ten plik i odkomentuje wszystkie linie z przykładową konfiguracją, które się tam znajdują.

4. Uruchom/zrestartuj serwer apache

# /etc/init.d/apache2 restart


Sprawdźmy czy działa?
# svn info http://localhost/svn/repos/
Authentication realm: Subversion repository
Password for 'root':
svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for 'http://localhost/svn/repos'


Nie działa - ale rozczarowanie. Pomyślmy - co może być nie tak?
Komunikat wskazuje na błąd po stronie serwera www. Zajrzę w logi błędów apache'a (error logs).

# tail /var/log/apache2/error_log
[Thu Jul 09 09:25:28 2009] [notice] caught SIGTERM, shutting down
[Thu Jul 09 09:25:57 2009] [notice] Apache/2.2.11 (Unix) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8k SVN/1.6.2 PHP/5.2.9-pl2-gentoo configured -- resuming normal operations
[Thu Jul 09 09:29:54 2009] [error] [client 127.0.0.1] (13)Permission denied: Could not open password file: /var/svn/conf/svnusers


aha - uprawnienia do pliku - chłopaki w Gentoo coś przegapili w instrukcji - zgłoszę na bugs.gentoo.org
Ustawię poprawnie uprawnienia dla całego repozytorium

# chown -R apache:apache /var/svn

Sprawdzę teraz:

# svn co http://localhost/svn/repos/
Authentication realm: Subversion repository
Password for 'root':
Authentication realm: Subversion repository
Username: krzysiek
Password for 'krzysiek':
-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:

Subversion repository

can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/root/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? n
Please type 'yes' or 'no': no
Checked out revision 0.


Jest OK.
UWAGA! Zwróćcie uwagę na komunikat (zawsze zwracajcie uwagę na komunikaty) - warto wyłączyć przechowywanie haseł w pliku na dysku.
Robimy to ustawiając opcję store-plaintext-passwords na no w pliku /root/.subversion/config

I to na tyle na dziś. Następnym razem zajmę się omówieniem podstaw obsługi repozytorium subversion.

W najbliższym czasie wspomnę też o skryptach startowych Gentoo i omówię pominięte dziś punkty z instrukcji tj. snv_hot_backup i pakiet memcached.

poniedziałek, 6 lipca 2009

Portage - wyświetlanie informacji o zmianach

Dzisiaj krótko. Portage wśród swoich możliwości ma śledzenie zmian wprowadzanych między kolejnymi wydaniami dowolnego pakietu - tzw. changelogi. Jeśli chcemy być na bieżąco - to oprócz widocznych zmian we flagach (opcja --verbose) - możemy wyświetlić informacje o zmianach w funkcjonalności pakietu. Wśród licznych opcji narzędzia emerge mamy przełącznik --changelog (-l). Zaprezentuję to na przykładzie pakietu apache:

emerge -p --changelog apache

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] www-servers/apache-2.2.11-r2 [2.2.11]

*apache-2.2.11-r2

07 Jul 2009; Benedikt Böhm +apache-2.2.11-r2.ebuild:
fix #276707, #276792

07 Jul 2009; Richard Freeman apache-2.2.11-r1.ebuild:
amd64 stable - 276589

06 Jul 2009; Brent Baude apache-2.2.11-r1.ebuild:
Marking apache-2.2.11-r1 ppc64 and ppc for bug 276589

06 Jul 2009; Jeroen Roovers apache-2.2.11-r1.ebuild:
Stable for HPPA (bug #276589).

*apache-2.2.11-r1

05 Jul 2009; Benedikt Böhm -apache-2.2.9-r1.ebuild,
+apache-2.2.11-r1.ebuild:
fix #263588, #265547, #231913, #268154, #271470, #272951, #276426

02 May 2009; Jeroen Roovers apache-2.2.11.ebuild:
Stable for HPPA (bug #265705).

26 Apr 2009; Raúl Porcel apache-2.2.11.ebuild:
arm/ia64/s390/sh/sparc stable wrt #265705

26 Apr 2009; Brent Baude apache-2.2.11.ebuild:
Marking apache-2.2.11 ppc for bug 265705

23 Apr 2009; Markus Meier apache-2.2.11:
amd64/x86 stable, bug #265705

23 Apr 2009; Tobias Klausmann apache-2.2.11:
Stable on alpha, bug #265705

21 Apr 2009; Brent Baude apache-2.2.11.ebuild:
Marking apache-2.2.11 ppc64 for bug 265705

23 Jan 2009; Raúl Porcel apache-2.2.10.ebuild:
alpha/arm/ia64/s390/sh stable wrt #252432

09 Jan 2009; Brent Baude apache-2.2.10.ebuild:
Marking apache-2.2.10 ppc for bug 252432

07 Jan 2009; Brent Baude apache-2.2.10.ebuild:
Marking apache-2.2.10 ppc64 for bug 253432

04 Jan 2009; Markus Meier apache-2.2.10.ebuild:
amd64/x86 stable, bug #252432

04 Jan 2009; Friedrich Oslage apache-2.2.10.ebuild:
Stable on sparc, bug #252432

01 Jan 2009; Guy Martin apache-2.2.10.ebuild:
hppa stable, #252432


Jak widać emerge wyświeli nam wszystkie zmiany jakie zaszły pomiędzy aktualnie zainstalowaną wersją pakietu (2.2.11) a najnowszą, zalecaną do instalacji.

To tyle. Polecam w wolnym czasie samodzielne poszukiwania w man emerge.