Błąd przy instalacji Traca: No such file or directory: '/var/lib/trac/.egg-cache/VERSION

Co robimy:
Dodajemy do konfiguracji vhosta w apache'u:

PythonOption PYTHON_EGG_CACHE /tmp

Jeżeli w katalogu z projektami istnieje katalog .egg-cache - usuwamy go. Później wystarczy restart apache'a.

Zapisywanie uprawnień do plików i katalogów

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)

ORA-01658: unable to create INITIAL extent for segment in tablespace string

Brakło miejsca przy rozszerzaniu pliku należącego do przestrzeni tabel (TABLE SPACE). Jeżeli została użyta opcja opcja AUTOEXTEND (przy tworzeniu takiego plikunp. ALTER DATABASE DATAFILE 'pelna_sciezka_do_pliku' AUTOEXTEND ON NEXT 10M;) - to prawdopodobnie zabrakło miejsca na partycji, w której znajduje się powyższy plik. W przeciwnym razie powodem jest przekroczenie rozmiaru pliku (gdy nie używamy opcji AUTOEXTEND) - wtedy musimy ręcznie zwiększyć jego rozmiar, np. tak:

ALTER DATABASE DATAFILE 'pelna_sciezka_do_pliku' RESIZE 500M;

Gentoo - problemy przy kompilacji KDE4 - błąd libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive

Ponieważ pakiety KDE4 w Gentoo w końcu zostały zakwalifikowane jak pakiety stabilne - postanowiłem sobie zaktualizować system instalując przy okazji środowisko grficzne KDE4. Niestety przy kompilacji pakietu pojawia się powyższy błąd:

/bin/grep: /usr/lib/libogg.la: No such file or directory
/bin/sed: can't read /usr/lib/libogg.la: No such file or directory
libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive
make: *** [libgstvorbis.la] Error 1
*
* ERROR: media-plugins/gst-plugins-vorbis-0.10.23 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 2289: Called gst-plugins-base_src_compile
* environment, line 1665: Called die
* The specific snippet of code:
* emake || die "compile failure"
* The die message:
* compile failure
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/log/portage/media-plugins:gst-plugins-vorbis-0.10.23:20091113-071732.log'.
* The ebuild environment file is located at '/var/tmp/portage/media-plugins/gst-plugins-vorbis-0.10.23/temp/environment'.
*

Żeby pozbyć się problemów instalujemy pakiet dev-util/lafilefixer, a następnie go uruchamiamy:

# lafilefixer --justfixit

Następnie można kontynuować aktualizację.

Zadanie domowe:
- poszukać informacji o plikach .la
- przeglądnąć dowolny plik libtool .la

Jak sprawdzić z skąd instancja Oracle'a wzięła parametry startowe?

Z którego typu parametrów uruchomieniowych korzysta twoja instancja? Zmieniłeś je w PFILE'u a instancja dalej się uruchamia ze starymi ustawieniami - więc zapewne jest to SPFILE? Nie chcesz zgadywać?

Uruchamiamy konsolę:

sqlplus / as sysdba
SELECT DECODE (value, NULL,'PFILE', 'SPFILE') "Init File Type" FROM v$parameter WHERE name = 'spfile';

I już wiemy.
Ogólnie zasada jest taka - wartość value = NULL oznacza, że baza nie korzysta z określonego typu pliku inicjalizacyjnego. Jeżeli w obydwu przypadkach wartość kolumny VALUE jest NULLem - to baza danych używa PFILE.

Możemy też łatwo znaleźć lokalizację pliku za pomocą:

select value from v$parameter where name like 'spfile';

lub

SHOW PARAMETER SPFILE;

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:

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.

Oracle na Centosie

Zainstalowałem sobie testowego Oracle'a na wirtualnej maszynie. Przy instalacji patch'a wywalił mi komunikat:

[root@centosik Disk1]# ./runInstaller -silent -responseFile response/patchset.rsp
Starting Oracle Universal Installer...

Checking installer requirements...

Checking operating system version: must be redhat-3, SuSE-9, SuSE-10, redhat-4, redhat-5, UnitedLinux-1.0, asianux-1, asianux-2 or asianux-3
Failed <<<<

Exiting Oracle Universal Installer, log for this session can be found at /home/oracle/oraInventory/logs/installActions2009-11-01_12-56-26PM.log

Jak się można domyślić "enterprajsowe" sprawdzenie dystrybucji to naprawdę skomplikowane zadanie.
Jak uruchomić patcha mimo wszystko? A na przykład tak:

echo "Red Hat Linux release 5" > /etc/redhat-release

i już działa - dystrybucja jest w porządku - "enterprajs" rządzi

ps. wszystko jak się wydaje zależy od wersji oracle. Swego czasu musiałem mieć w pliku redhat-release wpis np. redhat-4

Ruby - zabawy z gem chronic

Ostatnio popełniłem skrypt do generowania statystyk z backupów wykonanych w określonych przedziałach czasowych. Uznałem, że bardzo wygodnie było by udostępnić elastyczny mechanizm umożliwiający podanie okresu na podstawie którego ma byc wygenerowana statystyka.

Tu z pomocą przychodzi gem w Ruby co się zowie 'chronic'. Najpierw zainstalujmy gema (niestety nie ma go w portage'u - przynajmniej głownym repo):

gem install chronic

I już mamy gema.
Pobawmy się tym trochę w irb (interaktywny interpreter Ruby - czy jakkolwiek to nazwać)

ja@komp ~ $ irb
irb(main):001:0> require 'chronic'
=> true
irb(main):002:0> Chronic.parse("yesterday")
=> Wed Nov 04 12:00:00 +0100 2009
irb(main):003:0> Chronic.parse("yesterday").class
=> Time
irb(main):004:0>

Jak widać chronic zwraca obiekt klasy Time - klasa wbudowana w Ruby (standard library). Umożliwia nam to proste operowanie w kodzie np. do generowania zapytań SQL (klauzula where time ...)

Oczywiście to dopiero początek:

irb(main):005:0> Chronic.parse("last friday")
=> Fri Oct 30 12:00:00 +0100 2009
irb(main):006:0> Chronic.parse("last friday at 5pm")
=> Fri Oct 30 17:00:00 +0100 2009
irb(main):007:0> Chronic.parse("last month")
=> Fri Oct 16 12:30:00 +0200 2009
irb(main):008:0> Chronic.parse("last wednesday")
=> Wed Nov 04 12:00:00 +0100 2009

To zaledwie parę przykładów - tak żeby pokazać co potrafi sparsować chronic.
Ważnym parametrem przy parsowaniu jest kontekst czasu - w skrócie czy chronic ma szukać w pasującej do opisu daty przeszłości czy w przyszłości:

irb(main):010:0> Chronic.parse("wednesday", :context => :past)
=> Wed Nov 04 12:00:00 +0100 2009
irb(main):011:0> Chronic.parse("wednesday", :context => :future)
=> Wed Nov 11 12:00:00 +0100 2009
irb(main):012:0> Chronic.parse("wednesday")
=> Wed Nov 11 12:00:00 +0100 2009

Jak widać domyślnym kontekstem jest :future.

Opcja :now umożliwia zdefiniowanie daty, która ma być przez parser traktowana jako data aktualna (odnośnik czasowy w stosunku do którego ma być wykonane obliczenie). Domyślnie jest to czas bieżący:

irb(main):024:0> Chronic.parse("wednesday 4:00", :now => Time.local(2005, 1, 1))
=> Wed Jan 05 16:00:00 +0100 2005

Opcja :ambiguous_time_range umożliwia określenie przedziału czasowego, w którym będzie poszukiwana punkt w czasie - zobaczmy to na przykładzie:

irb(main):024:0> Chronic.parse("wednesday 4:00", :now => Time.local(2005, 1, 1))
=> Wed Jan 05 16:00:00 +0100 2005
irb(main):020:0> Chronic.parse("wednesday 6:00", :ambiguous_time_range => 5)
=> Wed Nov 11 06:00:00 +0100 2009
irb(main):021:0> Chronic.parse("wednesday 4:00", :ambiguous_time_range => 5)
=> Wed Nov 11 16:00:00 +0100 2009

Określiłem przeszukiwany przedział czasowy na 5am-5pm - jak widać zwrócone czasy zawierają się w zdefiniowanym przeze mnie przedziale.

Pozostaje jeszcze opcja :guess - to już pozostawiam czytelnikowi

Przydatne linki:
Chronic gem

Na nowym portalu:
Gemcutter gems - chronic

Jak utworzyć nowy dysk dla vmware

Zabrakło mi miejsca na dysku wirtualnej maszyny wmware.
Ponieważ nie mam na stacji pełnej wersji VmWare a jedynie vmplayera - nie mogłem skorzystać z interfejsu graficznego do prostej operacji jaką jest dodanie nowego dysku.
Trochę googlowania i jest rozwiązanie (dla tych co mają zainstalowane qemu).

Nowy, czysty dysk można utworzyć poleceniem:

qemu-img create -f vmdk disk2.vmdk 15G Formating 'disk2.vmdk', fmt=vmdk, size=15728640 kB

Później wystarczy jedynie dodanie tego dysku do konfiguracji maszyny wirtualnej. W tym celu musimy wyedytować plik o rozszerzeniu .vmx. Jest to plik tekstowy. W zależności od typu wygenerowanego dysku tworzymy odpowiedni wpis. W moim przypadku był to dysk IDE więc dodałem dwie linijki:

ide1:0.present = "TRUE"
ide1:0.fileName = "disk2.vmdk"

Polecenie watch - jak go używać?

Polecenie watch okazuje się często bardzo przydatnym narzędziem w codziennej praktyce administratorskiej. Pozwala nam ono wykonywać cyklicznie komendę podaną jako parametr w wywołaniu watch wyświetlając jej wynik za każdym razem na nowym ekranie:

watch [opcje] polecenie

Pozwala to w dość skuteczny sposób śledzić zmiany zachodzące pomiędzy kolejnymi wykonaniami polecenia.

Przejdźmy do praktyki. Prześledźmy zmiany pamięci dostępnej w systemie:

# watch -n 1 free

Co 1 sekundę wykonujemy polecenie free (wyświetla statystyki pamięci dostępnej w systemie - o tym innym razem).
Polecenie watch pozwala nam na więcej - możemy śledzić zmiany zachodzące w wyniku wykonania między dwoma kolejnymi wywołaniami (opcja -d):

# watch -n 1 -d free

Możemy też użyć wartości =cumulative przy opcji -d - zaznaczone będą wszystkie zmiany jakie zachodzą między wywołaniami polecenia - zmiany te będą kumulowane - nie zostaną skasowane jak w wypadku użycia samej opcji -d

# watch -n 2 free -d=cumulative free

Inne przykłady zastosowania komendy watch:

- śledzenie liczby przerwań (o przerwaniach innym razem)

# watch -n1 -d 'cat /proc/interrupts'

- śledzenie procesów ZOMBIE w systemie - no tak nie całkiem do końca ale powinno zadziałać (o procesach innym razem)

# watch -n2 "ps auxw | grep 'defunct' | grep -v 'grep' | grep -v 'watch'"

grep -v odfiltrowuje linie zawierające tekst pasujący do wzorca - stosuje się to często przy wyszukiwaniu konkretnego procesu w systemie gdy chcemy odfiltrować proces grep w zwróconym wyniku:

# ps ax|grep cron|grep -v grep

Zadanie - Jak inaczej można odfiltrować grep z listy procesów?

- śledzenie nawiązanych połączeń:

# watch -n 1 -d "netstat -tpanl | grep ESTABLISHED"

Zastosowań znajdzie się pewnie mnóstwo - ja często używam watch przy poleceniu dd w celu sprawdzenia ile danych zostało skopiowanych za jego pomocą. Polecenie dd wyświetla aktualny stan kopiowania tylko w momencie gdy proces dd otrzyma sygnał SIGUSR1 (polecam man dd):

# watch -n 2 'kill -SIGUSR1 $pid

$pid określa numer procesu dd w systemie (trzeba go wcześniej zidentyfikować).

Debian - Bash auto uzupełnianie - problemy

Jeżeli jako zwykły użytkownik przy używaniu tabulatora w celu autouzupełnienia tekstu (np. nazwy katalogu) pojawia się nam taka lub podobna linijka:

cd /ho-sh: <( compgen -d -- '/ho' ): No such file or directory

(w tym wypadku chciałem przejść do katalogu /home bez wpisywania całej nazwy a jedynie poprzez wpisanie pierwszej litery 'h' a później naciśnięcie klawisza TAB)

to problemem jest używany przez nasz shell - używamy shella innego niż Bash. Najprostszym rozwiązaniem jest zmiana w pliku /etc/passwd shella na bash (ambitnym pozostawiam analizę narzędzia compgen).

Zobaczmy to a przykładzie. Wyszukam informacje o użytkowniku w pliku passwd:

# grep user1 /etc/passwd
user1:x:1001:1001:Ordinary user:/home/user1:/bin/sh

Każda linijka w tym pliku definuje jednego użytkownika systemowego. Konkretne informacje o użytkowniku oddzielone są dwukropkiem - i oznaczają kolejno:
- nazwę użytkownika
- skrót hasła lub x jeśli skrót jest przechowywany w bezpiecznym pliku - /etc/shadow
- numeryczny identyfikator użytkownika (bodajże typu int) - uid
- numeryczny identyfikator grupy głównej (domyślnej - też typu int) użytkownika - gid
- katalog domowy użytkownika
- opis użytkownika - pełna nazwa - ciąg pozwalający odszyfrować po co i przez kogo jest używany dany login
- domyślny shell użytkownika

Jak widać user1 używa shella sh - żeby wyeliminować opisany błąd należy edytorem tekstowym z poziomu administratora zmienić wpis dotyczący shella z /bin/sh na /bin/bash i już.

A co jeśli nie mamy uprawnień roota?
Można użyć polecenia chsh będąc zalogowanym na swoim koncie:

#chsh -s /bin/bash

Możemy używać tego polecenia również z poziomu administratora jeśli nie chcemy edytować pliku ręcznie - polecenie jako argument może przyjąc login użytkownika, na którym chcemy dokonać zmiany (polecam man chsh).

Jak sprawdzić aktywny shell?
Za pomocą zmiennej shella $0

# echo $0
-bash

Pliki konfiguracyjne, którym warto się przyjrzeć:
/etc/shadow
/etc/login.defs
/etc/shells

Jako zadanie domowe pozostawiam pytania:
Jak działa chsh?
Dlaczego skróty haseł zaleca się trzymać w osobnym pliku /etc/shadow?
Do czego służy polecenie getent?

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:

$ 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

Oracle - jak włączyć tryb ARCHIVELOG?

Domyślnie po instalacji tryb archiwizowania redo logów jest wyłączony co oznacza, że w momencie zapełnienia wszystkich wolumenów redo logów następuje ich rotacja - najstarszy redo log jest czyszczony a następnie zrzucane do niego wykonane transakcje.
Żeby nie stracić tych informacji warto włączyć tryb archivelog (to nie jedyny powód dla którego warto to zrobić - o tym następnym razem).
Włączę konsolę oracle'a:

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Aug 19 07:33:05 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.


Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL>

Teraz w konsoli sprawdźmy w jakim trybie są archiwizacja redo logów:

SQL> select log_mode from v$database;

LOG_MODE
------------
NOARCHIVELOG

Teraz włączę archivelogi. W tym celu należy na początek wyłączyć bazę danych:

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

Teraz zamontujemy bazę - nie będzie ona jeszcze dostępna z zewnątrz.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 268435456 bytes
Fixed Size 1258364 bytes
Variable Size 243272836 bytes
Database Buffers 20971520 bytes
Redo Buffers 2932736 bytes
Database mounted.

Możemy ustawić tryb pracy z archiwizowaniem redo logów:

SQL> alter database archivelog;

Database altered.

Następnie otwieramy bazę danych:

SQL> alter database open;

Database altered.

Sprawdźmy czy się udało:

SQL> select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG

Jak najbardziej.

Zobaczmy czy działa proces archiwizacji redo logów (arch):

SQL> show parameter log_archive_start

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_start boolean FALSE

Jak widać nie działa. W celu uruchomienia go ręcznie można użyć komendy:

SQL> alter system archive log start;

System altered.

Zobaczmy w widoku procesów oracle czy działa jakiś archiwizator:

SQL> select * from v$archive_processes;

PROCESS STATUS LOG_SEQUENCE STAT
---------- ---------- ------------ ----
0 ACTIVE 0 IDLE
1 ACTIVE 0 IDLE
2 STOPPED 0 IDLE
3 STOPPED 0 IDLE

Działają dwa. Czyli ok.
Teraz należałoby ustawić automatyczny start procesów archiwizacji. Musimy to zrobić w pliku init.ora. Należy dodać poniższe linijki:

log_archive_dest = /var/lib/oracle/archivelog/
log_archive_format = %S.arc
log_archive_start = true

Ważne! Żeby wykonywać te polecenia muszę być zalogowany z uprawnieniami SYSDBA lub SYSOPER.

Narzędzia pomocnicze do zarządzania pakietami w Gentoo

Dziś wspomnę o dwóch pakietach znajdujących się w portage'u a stworzonych w celu ułatwienia zarządzania pakietami - są to app-portage/gentoolkit oraz app-portage/portage-utils.
Obydwa pakiety posiadają dobrą dokumentację, której nie zamierzam tutaj przekopiowywać - pozwolę sobie jedynie skomentować ewentualnie rozszerzyć fragmenty, które moim zdaniem mogą być dla początkującego użytkownika Gentoo nieczytelne.
Obydwa pakiety dostarczają zbliżoną funkcjonalność jeśli chodzi o zarządzanie pakietami, jednak pod względem szybkości bezwzględnie lepszy jest portage-utils w całości napisany w C.
W przypadku pakietu portage-utils po zainstalowaniu warto pamiętać o dodaniu synchronizacji bazy ebuildów za pomocą narządka q-reinitialize (/etc/portage/postsync.d). W tym celu należy uczynić ten plik wykonywalnym;

# chmod u+x /etc/portage/postsync.d/q-reinitialize

Informację tą powinniście zobaczyć po zainstalowaniu pakietu, więc raczej ciężko ją przegapić. Od tej pory po każdej synchronizacji portage'a nastąpi przebudowanie cache'u narządka portage-utils.
Zaglądnijmy na chwilę do pliku q-reinitialize:

# cat /etc/portage/postsync.d/q-reinitialize
[ -x /usr/bin/q ] && /usr/bin/q -qr

Wiele to tu się nie dzieje no bo i po co (KISS!). Nawias kwadratowy to polecenie służące do sprawdzenia typów plików i porównywania wartości zmiennych. W tym wypadku sprawdzamy czy plik q jest wykonywalny (-x). W kolejnym kroku ale tylko i wyłącznie wtedy gdy można uruchomić plik q wykonujemy reinicjalizację cache'u. Operator && to nic innego jak operatror logiczny AND - służy nam w tym wypadku do czegoś co lubię nazywać leniwym uruchamianiem - tzn. uruchomienia drugiego polecenia tylkw w wypadku gdy pierwszy człon (przed operatorem) wykona się prawidłowo tj. zwróci wartość 0.
Przyjrzyjmy się teraz wykorzystaniu narzędzi, o których nie wspomina dokumentacja Gentoo (jak wspomniałem nie zamierzam powielać treści):
- qlop - analizator logów emerge (/var/log/emerge.log)
Pozwala na wyciąganie wielu przydatnych informacji z logów emerge.
Historia synchronizacji portage:

# qlop -s

Historia instalacji:

# qlop -l

- qpkg - zarządzanie skompilowanymi pakietami

# qpkg --clean

czyści nieużywane paczki binarne

# qpkg --eclean

czyści paczki, których nie ma już w drzewie portage

Na dziś to tyle. Następnym razem muszę wspomnieć o narzędziach: glsa-check, revdep-rebuild, genlop oraz o sposobach odczytu informacji poinstalacyjnych.

Ograniczenie czasowe w skryptach shellowych - komenda timeout

Ostatnio potrzebowałem użyć jakiegoś sposobu do wymuszenia ograniczenia czasowego na wykonanie komendy w skrypcie. Wynikiem moich poszukiwań było zastosowanie komendy timeout. W Gentoo jest ona dostarczana wraz z pakietem 'sys-apps/coreutils'. Jak jej używać?

# timeout 3s find /home -name *pdf

Jeżeli polecenie podane jako argument komendy timeout nie wykona się w ciągu 3 sekund zostanie ono zakończone.
Domyślnie do uruchomionego procesu wysyłany jest sygnał TERM (o sygnałach już wkrótce) - co wymusza na procesie zakończenie działania. Jeśli potrzebujemy możemy wybrać dowolny z dostępnych sygnałów - trzeba jednak mieć na uwadze, że jedynie sygnał nr 9 (SIGKILL) wymusza na procesie zamknięcie. Syganły definujemy poprzez parametr -s po którym podajemy nr sygnału lub jego nazwę:

# time timeout -s9 3s find / -name *pdf

Czas po jakim nastąpi wysłanie sygnału do procesu (bo to chyba słuszniejsza definicja tego co się dzieje) możemy określić w sekundach (s), godzinach (h) lub dniach (d).

Nasuwa się pytanie w jaki sposób sprawdzać czy komenda się zakończyła czy została przerwana?
Można to zweryfikować za pomocą statusu wyjścia $?. Jeśli nastąpił timeout wartość zmiennej wynosi 124 - w pozostałych wypadkach będzie to status zakończenia zwrócony przez wykonane polecenie.

Jak można inaczej zaimplementować timeout w skrypcie? Mi przychodzi do głowy takie rozwiązanie:

# polecenie & sleep 10 && kill %1 && fg

Jak to działa? Pozostawiam to póki co czytelnikowi jako zadanie domowe.

Vista - udziały administracyjne - jak włączyć?

Musimy wyedytować rejestr a dokładniej dodać do gałęzi HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System klucz "LocalAccountTokenFilterPolicy" typu DWORD i ustawić jego wartość 1.

Vista - konto administrator

Ostatnio potrzebowałem odblokować domyślnie zablokowane konto administratora w viście.

1. Uruchom cmd jako administrator
2. Wykonaj net user administrator /active:yes

i już

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:

#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.

eselect - narzędzie do konfiguracji i administracji środowiska Gentoo

Spośród wielu przydatnych narzędzi znacznie automatyzujących administrację w systemie Gentoo nie można zapomnieć o eselect. Jest to modularne narzędzie pozwalające na konfigurację wielu aspektów środowiska napisane w całości w bashu.
Jak to zainstalować?

Poszukajmy w portage'u znaną już z wcześniejszych postów komendą eix:

# eix ^eselect
[I] app-admin/eselect
Available versions: 1.0.10 1.0.11-r1 1.0.12 1.1.1 ~1.1.2 {bash-completion doc vim-syntax}
Installed versions: 1.1.1(14:09:03 08/02/09)(bash-completion -doc)
Homepage: http://www.gentoo.org/proj/en/eselect/
Description: Gentoo's multi-purpose configuration and management tool

[I] app-admin/eselect-fontconfig
Available versions: 1.0
Installed versions: 1.0(15:55:30 01/20/08)
Homepage: http://www.gentoo.org
Description: An eselect module to manage /etc/fonts/conf.d symlinks.

[I] app-admin/eselect-news
Available versions: ~20070709 ~20071025 ~20071201 20080320
Installed versions: 20080320(11:29:19 02/15/09)
Homepage: http://paludis.pioto.org/
Description: GLEP 42 news reader

[I] app-admin/eselect-oodict
Available versions: 20060621 20060706 ~20060806 20061117
Installed versions: 20061117(16:53:52 09/21/07)
Homepage: http://www.gentoo.org/
Description: Manages configuration of dictionaries for OpenOffice.Org.

[I] app-admin/eselect-opengl
Available versions: 1.0.5 ~1.0.6 1.0.6-r1 ~1.0.7
Installed versions: 1.0.6-r1(20:49:53 05/11/08)
Homepage: http://www.gentoo.org/
Description: Utility to change the OpenGL interface being used

* app-admin/eselect-oracle
Available versions: ~1.0-r260
Homepage: http://www.gentoo.org/
Description: Utility to change the Oracle SQL*Plus Instantclient being used

* app-admin/eselect-postgresql
Available versions: 0.3
Homepage: http://www.gentoo.org/
Description: Utility to change the default postgresql installation

[I] app-admin/eselect-python
Available versions: 20080521 20080925 20090606 ~20090801 ~20090804
Installed versions: 20090606(14:20:10 08/02/09)
Homepage: http://www.gentoo.org
Description: Manages multiple Python versions

[I] app-admin/eselect-rails
Available versions: 0.14 0.15
Installed versions: 0.15(14:21:36 08/02/09)
Homepage: http://www.gentoo.org/
Description: Manages Ruby on Rails symlinks

[I] app-admin/eselect-ruby
Available versions: ~20081211 20081227
Installed versions: 20081227(14:20:21 08/02/09)
Homepage: http://www.gentoo.org
Description: Manages multiple Ruby versions

[I] app-admin/eselect-vi
Available versions: 1.1.4 1.1.5 ~1.1.6
Installed versions: 1.1.5(10:33:02 12/22/07)
Homepage: http://www.gentoo.org/
Description: Manages the /usr/bin/vi symlink

* app-vim/eselect-syntax
Available versions: 20070506
Homepage: http://www.gentoo.org/
Description: vim plugin: Eselect syntax highlighting, filetype and indent settings

Found 32 matches.

Ze względu na liczbę dostępnych modułów wynik został troszeczkę skrócony - wyciąłem mniej ważne z mojego punktu widzenia moduły. Jak widać jest tego trochę. Zainstalujmy teraz eselect:

# emerge -av eselect

Udało się. Zobaczmy w praktyce jak to działa, uruchomię:

# eselect
Usage: eselect

Global options:
--no-color,--no-colour Disable coloured output

Built-in modules:
help Display a help message
usage Display a usage message
version Display version information

Extra modules:
bashcomp Manage contributed bash-completion scripts
binutils Manage installed versions of sys-devel/binutils
ctags Manage /usr/bin/ctags implementations
editor Manage the EDITOR environment variable
env Manage environment variables set in /etc/env.d/
esd Select esound daemon or wrapper
fontconfig Manage fontconfig /etc/fonts/conf.d/ symlinks
java-nsplugin Manage the Java plugin for Netscape-like Browsers
java-vm Manage the Java system and user VM
kernel Manage the /usr/src/linux symlink
modules A module for querying modules. By default, it lists all available modules
news-tng Read Gentoo ("GLEP 42") news items
news Read GLEP 42 news items
oodict Manage the configuration of dictionaries for OpenOffice.Org.
opengl Manage the OpenGL implementation used by your system
pager Manage the PAGER environment variable
profile Manage the /etc/make.profile symlink
python Manage the /usr/bin/python and python.1 man symlinks.
rails Manage Ruby on Rails versions
rc Manage /etc/init.d scripts in runlevels
ruby Manage ruby symlinks
vi Manage /usr/bin/vi implementations
visual Manage the VISUAL environment variable
wxwidgets Manage the system default wxWidgets profile.
xvmc Manage the XvMC implementation used by your system

Liczba modułów jest znaczna - czego można się już było spodziewać po wynikach wyszukiwania. Z tego względu omówię jedynie najważniejsze moduły - pozostałe pozostawiam do testowania we własnym zakresie - zasada działania i wywoływania jest podobna o ile nie identyczna.

Co się przydaje:

- moduł editor -ustawienie domyślnego edytora - spróbujmy:

# eselect editor
Usage: eselect editor

Standard actions:
help Display help text
usage Display usage information
version Display version information

Extra actions:
list List available targets for the EDITOR variable
set Set the EDITOR variable in profile
target Target name or number (from 'list' action)
show Show value of the EDITOR variable in profile
update Update the EDITOR variable if it is unset or invalid

Wyświetli nam działania jakie możemy w ramach modułu wykonać (są one na ogół identyczne w każdym z modułów - dzięki czemu obsługa eselect jest prosta - wszystko to kwestia przyjęcia właściwej konwencji)
Wylistuję dostępne edytory:

# eselect editor list
Available targets for the EDITOR variable:
[1] /bin/nano
[2] /bin/ed
[3] /usr/bin/ex
[4] /usr/bin/vi

Ustawię edytor na vi (tak naprawdę to będzie vim). Przy ustawianiu za pomocą eselecta możemy używać numer wpisu lub jego nazwę- ja skorzystam z numeru:

# eselect editor set 4
Setting EDITOR to /usr/bin/vi ...

Co się stało? Powinno się zmienić ustawienie zmiennej środowiskowej EDITOR.

# env|grep EDITOR
EDITOR=/bin/nano

hmm... nie jest tak jakbym chciał. Co się stało? Proawdopodobnie niezostała zaktualizowana wartość zmiennej w środowisku. Sprawdzę czy zmienna została ustawiona (katalog /etc/env.d - o tym opowiem innym razem szczegółowo)

# grep -r EDITOR /etc/env.d/
/etc/env.d/99editor:EDITOR="/usr/bin/ex"

Jest. A więc narzędzie zmienia ustawienia zmiennej EDITOR w konfiguracji systemu. W celu wymuszenia zmian w środowisku roboczym należy wykonać aktualizację:

# env-update
>>> Regenerating /etc/ld.so.cache...

I już powinno być ok. Sprawdzę:

edward ~ # env|grep EDITO
EDITOR=/usr/bin/vim

No i jest. Zmienną EDITOR można było do niedawna ustawić również w pliku /etc/rc.conf jednak zalecane jest definiowanie jej w pliku ~/.bashrc (lub odpowiedniku) bądź utworzenia pliku /etc/env.d/99editor i ustawienie tam zmiennych (jak w powyższym przykładzie).

- ustawienie aktywnej jvm
W tym wypadku mamy możliwość ustawienia wersji wirtualnej maszyny java, którą będziemy używać. Możemy dokonać wyboru na poziomie systemu lub użytkownika. Zdefinujmy aktywny jvm na poziomie systemu:

# eselect java-vm list
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
Available Java Virtual Machines:
[1] sun-jdk-1.4
[2] sun-jdk-1.5 system-vm
[3] sun-jdk-1.6

a co to - 'shell-init: error retrieving current directory: getcwd'? Może się zdarzyć jeśli uruchamiamy polecenie będąc w katalogu, który został wcześniej usunięty (weszliśmy do katalogu - ktoś w innej sesji go usunął)
Dobra lećmy dalej:

ny ~ # java -version
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode)
ny ~ # eselect java-vm set system 3
ny ~ # java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)

Jak widać zmieniłem ustawienia jvm na poziomie systemu. Po ustawieniu w ten sposób jvm następuje automatyczne przełączenie aktualnie aktywnego jvm - wersja się zmieniła bez żadnych dodatkowych zabiegów.
Każdy użytkownik może zmienić używanego jvm - można to zrobić tak:

k@ny ~ $ java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)
k@ny ~ $ eselect java-vm set user 2
k@ny ~ $ java -version
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode)
k@ny ~ $ eselect java-vm list
Available Java Virtual Machines:
[1] sun-jdk-1.4
[2] sun-jdk-1.5 user-vm
[3] sun-jdk-1.6 system-vm

Użytkownik po zmianie używa java'y Suna w wersji 1.5 natomiast systemowy jvm jest ustawiony na wersję Sun JDK 1.6.
Dla ciekawskich pozostawiam temat w jaki sposób te zmiany są realizowane w systemie - jak to się automagicznie dzieje (być może sam też to kiedyś opiszę). Trochę ciekawych informacji na temat java w Gentoo można znaleźć tu.

- zmiany w portage - moduł news/news-tng. Niedawno dodano do portage tzw. newsy - wiadomości mające informować nas o ważnych zmianach w funkcjonowaniu pakietów w portage i samego portage'a.
Sprawdźmy jak to działa:

ny ~ # eselect news-tng
Usage: eselect news-tng

Standard actions:
help Display help text
usage Display usage information
version Display version information

Extra actions:
count Display number of news items
new Count unread news items (default)
all Count all news items
list List news items
purge Purge read news
read ... Read news items
new Read unread news items (default)
all Read all news items
item Number of item (from 'list' action)
--raw Output in raw format
unread ... Mark read news items as unread again
all Mark all news items as unread
item Number of item (from 'list' action)
ny ~ # eselect news-tng list
News items:
[1] 2009-04-06 (unread) Migration from teTeX to TeXLive
[2] 2009-04-18 (read) Generation 1 Java Setup Deprecated

Mam 2 wiadomości - 1 przeczytaną i 1 nieprzeczytaną. Przeczytajmy zatem wiadomość 2:

# eselect news-tng read 1
2009-04-06-tetex
Title Migration from teTeX to TeXLive
Author Christian Faulhammer
Author Ulrich Müller
Author Alexis Ballier
Posted 2009-04-06
Revision 1

teTeX is obsolete and has been unsupported upstream since May of 2006.
All users who still have teTeX installed should uninstall it and install
TeXLive using the upgrade guide accessible at the following URL:
http://www.gentoo.org/proj/en/tex/texlive-migration-guide.xml

tandetny ~ # eselect news-tng list
News items:
[1] 2009-04-18 (read) Generation 1 Java Setup Deprecated
[2] 2009-04-06 (read) Migration from teTeX to TeXLive

Jak widać informacje pozyskiwane tym źródłem mogą być po pierwsze użyteczne, po drugie pozwolą nam oszczędzić wiele bólów związanych z tym, że przeoczyliśmy jakąś ważną informację bo pakiet podczas instalacji nie poinformował nas o jakiejś ważnej zmianie (nie musimy śledzić, poszukiwać informacji po forach) ponieważ portage po każdej aktualizacji poinformuje nas w podsumowaniu ile mamy nowych newsów.
To jak dla mnie kolejna zaleta Gentoo - zintegrowane z systemem zarządzania pakietami ważne informacje o zmianach/nowinkach/sposobie konfiguracji oraz doskonała dokumentacja - jak widać na przykładzie dostajemy link do dokumentu opisującego zasady migracji z teTeX do TeXLive.


- zmiany profilu systemu Gentoo - moduł profile. Zasada użycia jest podobna, o tym czym są profile w Gentoo opowiem wkrótce.

- zmiany ustawień skryptów startowych - moduł rc - co startować w danym runlevelu o co nie. O runlevelach i ich specyficznej implementacji w Gentoo - wkrótce.

- zmiana aktywnego interpretera Ruby, Python - odpowiednio moduły ruby, python - podobnie jak w wypadku jvm.

Pozostałe pozostawiam do testowania we własnym zakresie. Z wartych zainteresowania wymieniłbym postgresql, kernel, rails, bash-completion, opengl.

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

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

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!

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

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

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.

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.

Daniel Robbins o Gentoo, zarządzaniu pakietami

W wolnym czasie polecam wywiad z Danielem Robbinsem - twórcą dystrybucji Gentoo. Ciekawie o Portage'u jak o przepisie na instalację - bardzo trafne spostrzeżenie.

Zarządzanie stacjami Windows za pomocą Cygwina, cz. I - Instalacja Cygwina i przygotowanie paczki do cichej instalacji

Cytat dnia:
The two basic principles of Windows system administration:

* For minor problems, reboot
* For major problems, reinstall

Ta idea przyświeca zapewne większości administratorów Windows (są oczywiście nieliczne wyjątki ale ja w swojej karierze takich nie spotkałem).
To będzie prawdopodobnie pierwszy z cyklu artykułów na temat zdalnego zarządzania stacjami Windows.
Od dłuższego czasu próbuję znaleźć rozsądny sposób na zarządzanie stacjami będącymi w domenie ale zarządzanymi przez serwer Linuksowy z działającą Sambą. Co to jest Samba? O tym opowiem z pewnością w przyszłości...
A teraz zajmijmy się zarządzaniem stacjami Windows.
Po dłuższym rozeznaniu tematu znalazłem pewien zestaw aplikacji open source wspomagających zarządzanie stacjami roboczymi. Pozwolę sobie je tu wymienić:
- projekt unattended-gui - umożliwia zarządzanie infrastrukturą, na pierwszy rzut oka niby wiele można (zarządzanie oprogramowaniem na stacjach windows, linux, konfiguracją sieci, switch'y, etc.) jednak nie znalazłem zbyt wielu informacji jak to się dokładnie robi. Możliwe jednak, że się mylę - na swoje usprawiedliwienie dodam, że przeglądałem to jedynie przez parę minut - projekt mnie nie przekonał, na tyle, żeby z niego skorzystać. Jednak na pewno będę miał go na oku.

- projekt kontrolpack - dostęp do zdalnej konsoli systemów Windows, Linux, Mac OS X. Działa w architekturze klient-serwer. Dosyć ciekawe rozwiązanie, jednak chyba jeszcze nie w pełni dopracowane. W trakcie testów doświadczyłem pewnych problemów ze zwieszaniem się klienta windowsowego przy odpalaniu skryptów Ruby. Wydaje się, że przy dużej liczbie stacji udostępnienie konsoli może być niewystarczającym rozwiązaniem. Nie znalazłem żadnych informacji na temat tworzenia grup hostów. Klient łączy się z serwerem na dziwnym porcie - wygląda na to, że korzysta z własnego protokołu transmisji - co mnie nie przekonuje - tym bardziej, że nigdzie w dokumentacji nie znalazłem informacji na temat sposobu wymianych danych między klientem a serwerem, a cóż tu dopiero mówić o jej bezpieczeństwie. Projekt rozwija się dynamicznie i miejmy nadzieję, że w krótkim czasie funkcjonalność i dokumentacja znacznie się poprawią.

- winexe - znalazłem gdzieś na forum, program umożliwiający zdalne podłączenie do stacji i uruchomienie dowolnego procesu. Pozwolę sobie w dalszym cyklu artykułów napisać o nim więcej.

- cygwin - nazwijmy go emulatorem środowiska Linux na windowsie. Dokładny opis można znaleźć w wikipedii

Poza programi open source warto wspomnieć o dwóch opcjach komercyjnych:
- program psexec - zdalne wykonywanie poleceń - podobnie jak winexe
- windows services for unix - odpowiednik cygwina stworzony przez Microsoft - ciężka kobyła (300MB) a nie ma nawet w pakiecie usługi ssh. Według Microsoftu ma przekonać administratorów *nix do środowiska windows i ułatwić ich migrację na nową platformę. Jednak w środowisku administratorów *nix program nazywany jest przewrotnie unix services for windows - krótko mówiąc brakująca proteza umożliwiająca w miarę rozsądną pracę w środowisku windows.
SFU po zainstalowaniu umożliwia połączenie ze stacją za pomocą protokołu telnet (przypominają się dawne czasy). Co prawda chłopaki coś wspominają o tym, że jest problem z przesyłaniem haseł plain tekstem przez sieć, ale przecież instalujemy to w zaufanej infrastrukturze - więc w czym rzecz? No jeśli już potrzebujecie to instalujcie openSSH - ale jak? To poszukajcie w sieci - mi się odechciało.

Po dłuższej analizie i licznych próbach (współ)pracy z powyższymi narzędziami dokonałem wyboru - tandem:
Cygwin, winexe i Ruby (jako język skryptowy) powinien zaspokoić moje potrzeby/wydumane wymagania.

Teraz po krótce pozwolę sobie opisać na początek kolejne kroki instalacji i przygotowywania pakietu Cygwin do używania w zarządzaniu stacjami Windows.

Pojawia się tu kilka niuansów nad którymi spędziłem trochę czasu, szczególnie wredny jest etap przygotowywania cichej instalacji i sama cicha instalacja.

Ze strony głównej projektu Cygwin ściągamy instalkę setup.exe.

Lista dostępnych opcji instalatora:
-D --download Download from internet
-L --local-install Install from local directory
-s --site Download site
-R --root Root installation directory
-q --quiet-mode Unattended setup mode
-h --help print help
-l --local-package-dir Local package directory
-r --no-replaceonreboot Disable replacing in-use files on next
reboot.
-n --no-shortcuts Disable creation of desktop and start
menu shortcuts
-N --no-startmenu Disable creation of start menu shortcut
-d --no-desktop Disable creation of desktop shortcut
-A --disable-buggy-antivirus Disable known or suspected buggy anti
virus software packages during
execution.

*Przygotowanie paczki cygwin do cichej instalacji na wielu stacjach roboczych
- Uruchamiamy setup.exe
- wybieramy katalog docelowy (c:\cygwin)
- wybieramy lokalny katalog repozytorium pakietów (c:\cygwin-root\root-dir) - należy go stworzyć przed instalacją
- wybieramy instalację z sieci
- wybieramy mirror (w sumie dowolny)
- wybieramy dodatkowe paczki do zainstalowania (z bardziej przydatnych: openssh, wget, procps, linux-utils, netcat)
- przechodzimy przez kolejne kroki instalatora

Po zainstalowaniu cygwina w katalogu z repozytoriami (c:\cygwin-root\root-dir) pojawi się folder, którego nazwa będzie adresem serwera źródeł instalacji (mirror) wybranego w trakcie uruchomienia instalatora cygwin.
Sam cygwin zainstaluje się w c:\cygwin.
Musimy teraz odtworzyć strukturę z konfiguracją zainstalowanego cygwina w katalogu c:\cygwin-root:
- tworzymy katalog c:\cygwin-root\cygwin\etc\setup
- przegrywamy z c:\cygwin\etc\setup do katalogu c:\cygwin-root\cygwin\etc\setup wszystkie pliki, których nazwa zaczyna się od last- (last-*)
- kopiujemy z c:\cygwin\etc\setup do c:\cygwin-root\cygwin\etc\setup plik setup.ini

Mamy już gotową konfigurację, którą możemy posłużyć się przy kolejnych instalacjach cygwina na stacjach roboczych.

*Cicha instalacja paczki cygwin na stacji roboczej
- tworzymy katalog c:\cygwin
- kopiujemy katalog c:\cygwin-root\cygwin\etc do c:\cygwin
- uruchamiamy instalator w trybie cichej instalacji:

setup.exe -q -R c:\cygwin -L -l c:\cygwin-root\root-dir

Jeżeli chcemy mieć Cygwin'a zainstalowanego na dysky systemowym zamiast identyfikatora napędu (c:) warto użyć zmiennej systemowej %systemdrive%

*Uruchomienie usługi SSH na stacji
Rejestracja SVC
- uruchamiamy konsolę cygwina
- uruchamiamy polecenie ssh-host-config
- odpowiadamy na zadawane pytania:
"privilege separation" => yes
"create local user sshd" => yes
"install sshd as a service" => yes
"CYGWIN=" => ntsec tty
- jeżeli pojawią się błędy - należy poprawić ustawienia systemu zgodnie z zaleceniami, które wyświetli ssh-host-config
- uruchamiamy utworzony serwis sshd za pomocą jednej z dwóch komend

net start sshd
cygrunsrv --start sshd

Teraz trzeba jeszcze odblokować usługę na firewall'u:

cmd /c if exist c:\windows\system32\netsh.exe netsh firewall set allowedprogram c:\cygwin\usr\sbin\sshd.exe SSHD enable

Muszę przyznać, że zarządzanie firewallem Windowsowym jest bardzo podobne do tworzenia reguł za pomocą iptables (o ile nie robimy tego w GUI ;)), a więc bardzo wygodne - ale o tym to już innym razem.

WAŻNE!
*Żeby użytkownicy Windows mogli się logować należy synchronizować bazy danych użytkowników w Windowsie ze środowiskiem Cygwin. Robimy to za pomocą:

mkpasswd -cl > /etc/passwd
mkgroup --local > /etc/group

*Zawsze upewnij się, że każdy użytkownik w systemie ma ustawione hasło do logowania.

Przydatne linki:
Projekt Cygwin
Cygwin FAQ
Z jakiegoś forum na temat instalacji Cygwina

Sudo - nadawanie specjalnych uprawnień

Ponieważ nie zamierzam przepisywać, podam link do dobrego przewodnika po komendzie sudo. O dziwo jest taki przewodnik zrobiony przez Gentoo. To kolejna zaleta tego projektu - świetna, dogłębna i spójna dokumentacja.

Po zaznajomieniu się z komendą czas na praktykę.
Ja w swoim zastosowaniu, w stawianym systemie chcę nadać możliwość instalowania pakietów za pomocą polecenia emerge jednemu użytkownikowi. Jak to zrobić?
Proponuję tak:

# visudo
-bash: visudo: command not found

O cholewcia - nie jest zainstalowane. Więc poszukajmy w portage'u:

emerge --search sudo

W czasie kiedy to polecenie się wykonuje dopiszę kolejną według mnie (niewielką) zaletę Gentoo -w porównianiu do dystrybucji debianowych jedną komendą zainstalujemy, wyszukamy pakiet - w Debianie są osobne i nieintuicyjne apt-get (instalacja) apt-cache search(bodajże - wyszukiwanie).
Dobra - mam już wyniki - a wśród nich:

Searching...
[ Results for search key : sudo ]
[ Applications found : 6 ]

* app-admin/sudo
Latest version available: 1.7.1-r1
Latest version installed: [ Not Installed ]
Size of files: 738 kB
Homepage: http://www.sudo.ws/
Description: Allows users or groups to run commands as other users
License: as-is BSD

Ponieważ emerge --search wyszukuje pakiet przeglądając na bieżąco wszystkie ebuildy w portage'u (/usr/portage - chyba wszystkie - tak mi się wydaje - a jeśli nie to metadata) nieraz możemy się poirytować czasem trwania wyszukiwania - jak to miało miejsce w moim wypadku. Proponuję używać komendy eix. hmm.. pryska zaleta jednej komendy do wyszukiwania i instalacji - no cóż - ale za to mamy szybko działającego eix'a - apt-chache strasznie muli mimo, że podobnie jak eix wyszukuje dane we własnej, zindeksowanej wcześniej bazie pakietów.
eix instaluję tak (warto zainstalować z bazą sqlite - odpowiednia flaga jest przy pakiecie):

# emerge -av eix

Zalecam używanie opcji --verbose --ask przy każdej instalacji - zawsze warto mieć wgląd w to co się będzie działo niż na ślepo instalować.

Zainstaluję w końcu sudo:

# emerge -av sudo
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] app-admin/sudo-1.7.1-r1 USE="pam -ldap -offensive (-selinux) -skey" 739 kB

Total: 1 package (1 new), Size of downloads: 739 kB

Would you like to merge these packages? [Yes/No]

I już. Teraz nadaję uprawnienia użytkownikowi:

# visudo

Dodaję linię:
user localhost = /usr/bin/emerge

i już - użytkownik user może używać komendy emerge.

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:

# 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

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:

# 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

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

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.

Tworzenie spersonalizowanej paczki instalacyjnej przeglądarki Mozilla Firefox dla systemu windows. Część I.

Do utworzenia paczki instalacyjnej będzie nam potrzebne narządko 7-zip oraz najnowsza wersja instalatora Firefox.
Po ściągnięciu i zainstalowaniu 7-zip, rozpakowujemy za jego pomocą instalkę Firefox. Jest to samorozpakowujące się archiwum 7z.

Teraz możemy przyjrzeć się zawartości archiwum. Znajduje się tu:

• katalog localized

-plik browserconfig.properties
Ustawiamy odpowiedniu stronę startową zmieniając wpis

browser.startup.homepage/moja.strona.startowa
Opis parametrów znajduje się w bazie wiedzy fundacji Mozilla:
browser.startup.homepage

browser.startup.page=3
browser.startup.page

Browser.sessionstore.resume=true
browser.sessionstore.resume_session

Browser.sessionstore.enabled=true
Browser.sessionstore.enabled

Browser.sessionstore.resume_from_crash=true
Browser.sessionstore.resume_from_crash

Wybrałem tylko nieliczne z dostępnych właściwości - te które zamierzam ustawić globalnie dla wszystkich instalacji Firefoxa.
-plik localized\defaults\profileprefs.js
Tutaj możemy ustawić pozostałe właściwości. I znów kłania się nam strona mozilla fundation
-plik localized/crashreporter.ini - komunikat po awaryjnym wyłączeniu (w UTF8)
-katalog localized/searchplugins - pliki xml ze zdefiniowanymi usługami wyszukiwania (prawdopodobnie pole szukaj w przeglądarce). Można tu poeksperymentować jeśli ma się swoje wiki.

Ustawień jest całe mnóstwo ich rozpoznanie pozostawiam na później, gdy będzie to potrzebne.

• katalog nonlocalized

- plik nonlocalized\defaults\pref\firefox.js
Jeśli użytkownik nie ma prawa aktualizacji aplikacji - a tak często się zdarza -warto wyłączyć automatyczne aktualizacje (przecież pilnujemy ich w firmie centralnie)
pref("app.update.enabled", false);

Możemy również wyłączyć podpowiadanie frazy wyszukiwania, za pomocą:
pref("browser.search.suggest.enabled",false);

• katalog optional

Można wyłączyć wysyłanie raportów po nieprawidłowym zamknięciu firefoxa. W tym celu należy usunąć katalog optional\extensions\talkback@mozilla.org

Mając przygotowaną paczkę, możemy przystąpić do jej cichej instalacji na stacjach roboczych. Po skopiowaniu na stację roboczą wystarczy wydać polecenie:

setup.exe /S

Można opcjonalnie podać ścieżkę do pliku .ini, w którym możemy ustawić parametry instalatora - po informacje odsyłam do Mozilla wiki

Linki:
Silent Firefox installation
Command line arguments