Generowanie losowych haseł w Ubuntu
Hasła, każdy ma ich przynajmniej kilka w pamięci, ale życie uczy, że nie warto stosować takich samych do autoryzacji bankowych, kont na naszej-klasie, gadu czy na roota
Chciałbym Wam przedstawić bardzo proste narzędzie z którego korzystam z powodzeniem od kilku lat – nazywa się apg (Automated Password Generator) i służy do wygodnego generowania haseł.
Narzędzie oferuje dwa rodzaje haseł – mniej zaawansowane, ale znacznie łatwiejsze do zapamiętania dla osób znających język angielski oraz bardziej zaawansowane (zawierające poza literami dodatkowe krzaczki). Za pomocą dodatkowych parametrów możemy wpłynąć na zawartość dużych, małych liter lub liczb.
Instalacja jest standardowa:
aptitude install apg
Help
Wygląda tak:
apg -h apg Automated Password Generator Copyright (c) Adel I. Mirzazhanov apg [-a algorithm] [-r file] [-M mode] [-E char_string] [-n num_of_pass] [-m min_pass_len] [-x max_pass_len] [-c cl_seed] [-d] [-s] [-h] [-y] [-q] -M mode new style password modes -E char_string exclude characters from password generation process -r file apply dictionary check against file -b filter_file apply bloom filter check against filter_file (filter_file should be created with apgbfm(1) utility) -p substr_len paranoid modifier for bloom filter check -a algorithm choose algorithm 1 - random password generation according to password modes 0 - pronounceable password generation -n num_of_pass generate num_of_pass passwords -m min_pass_len minimum password length -x max_pass_len maximum password length -s ask user for a random seed for password generation -c cl_seed use cl_seed as a random seed for password -d do NOT use any delimiters between generated passwords -l spell generated password -t print pronunciation for generated pronounceable password -y print crypted passwords -q quiet mode (do not print warnings) -h print this help screen -v print version information
A teraz praktyka
Wystarczy znajomość kilku parametrów:
Generowanie 5-ciu haseł: -n
apg -n 5 ookyopIack berpAxEr DusEphac yomlipvog~ weehacir
Generowanie haseł o minimalnej długości: -m
apg -n 5 -m 10 BlysBicWeo fefimvesBa CuAtecHeoc crejvibred CynfiShnoi
Generowanie haseł z wymową (aby łatwiej było je zapamiętać): -t
apg -n 5 -m 10 -t WaigJocWig (Waig-Joc-Wig) Geagsyinau (Geags-yin-au) Cunefkalt9 (Cun-ef-kalt-NINE) Pemyidyish (Pem-yid-yish) agsirasuk7 (ags-ir-as-uk-SEVEN)
Generowanie bardziej zaawansowanych haseł: -a 1
apg -a 1 -n 5 -m 10
N;%5RWNM|B
$48+HGvlac
{@M!yPMa-y
jyI<{\3;{i
t)nThAUw?~
Skrypt ten jest bardzo przydatny, kiedy musimy wygenerować komuś hasło ponieważ nie jest w stanie sobie czegoś wymyślić (i pewnie wymyślił by ostatecznie nazwę swojego psa lub imię małżonki) lub stawiamy następny z kolei serwer mysql, a nie chcemy zostawiać takiej dziury jak nie tak dawno ktoś z ekipy Wykopu, kiedy to wykradziono im hasła użytkowników.
Wirtualni userzy ftp w Ubuntu
Poniżej znajduje się instrukcja opisująca jak skonfigurować krok po kroku bardzo prosty i bezpieczny serwer ftp obsługujący wirtualne konta – użytkowników, których fizycznie nie ma zdefinowanych w systemie. Jako serwer ftp wykorzystany zostanie vsftpd (very secure ftp daemon).
Założenia: potrzebujemy prostego serwera ftp do którego możemy zdefiniować kilku użytkowników, gdzie każdy ma dostęp do tego samego katalogu (opis jak należy to skonfigurować, aby każdy użytkownik miał swój własny katalog znajduje się we wpisie źródłowym, którego adres zamieściłem na końcu wpisu).
Najpierw instalujemy serwer ftp oraz narzędzie do obsługi bazy użytkowników:
aptitude install vsftpd db4.2-util
Tworzymy katalog ftp:
mkdir /home/ftp chown ftp:ftp /home/ftp
(aplikacja domyślnie podczas instalacji zakłada katalog /srv/ftp)
Podmieniamy plik /etc/vsftpd.conf na następujący:
# /etc/vsftpd.conf listen=YES listen_ipv6=NO #listen_port=2121 anonymous_enable=NO local_enable=YES guest_enable=YES virtual_use_local_privs=YES pam_service_name=vsftpd-virtual guest_username=ftp local_root=/home/ftp local_umask=022 write_enable=YES hide_ids=YES dirmessage_enable=YES use_localtime=YES xferlog_enable=YES log_ftp_protocol=YES setproctitle_enable=YES connect_from_port_20=YES chroot_local_user=YES chroot_list_enable=NO secure_chroot_dir=/var/run/vsftpd/empty
W razie potrzeb – zmieniamy ustawienia – np. jeśli chcemy zmienić port na którym aplikacja ma nasłuchiwać – usuwamy znak komentarza z linii listen_port i zmieniamy numer portu.
Przygotowujemy plik /etc/pam.d/vsftpd-virtual:
auth required pam_userdb.so db=/etc/vsftpd-virtual account required pam_userdb.so db=/etc/vsftpd-virtual
Przygotowujemy plik z użytkownikami i hasłami /etc/vsftpd-konta:
uzytkownik1 haslo1 uzytkownik2 haslo2
umieszczamy hasła w bazie:
db4.2_load -T -t hash -f /etc/vsftpd-konta /etc/vsftpd-virtual.db
a następnie restartujemy usługę:
service vsftpd restart
Możemy już zalogować się do serwera, przykładowo:
lftp -p 2121 -u uzytkownik1,haslo1 localhost lftp test1@localhost:~> ls lftp test1@localhost:/>
Źródło: http://linuxforfun.net/2008/04/05/vsftpd-virtual-users/
ACL dla plików i katalogów w Ubuntu
Unixowy system uprawnień dla plików i katalogów został naprawdę dobrze przemyślany i świetnie się sprawdza. Każdy jednak prędzej czy później może trafić na sytuację, w której możliwość stosowania rozszerzonych uprawnień dałaby znacznie większą swobodę i wygodę.
Kogo temat może zainteresować?
Wydaje mi się, że użytkownicy zwykłych desktopów nie będą ACL’i potrzebować. Jeśli jednak jakiś developer umieszcza przykładowo serwer z repozytorium u siebie albo jest administratorem jakiegoś serwera – myślę, że warto się zapoznać z poniższą tematyką.
Krok po kroku
Access Control Lists (ang. ACL), czyli listy kontroli dostępu są w jądrze Ubuntu wkompilowana domyślnie już od jakiegoś czasu. Niewiele stoi zatem nam na przeszkodzie, aby aktywnie zacząć z nich korzystać. ACL należy traktować jako rozszerzenie Unixowego systemu uprawnień plików i katalogów, dlatego zestaw komend takich jak chown czy chmod nadal obowiązuje.
Czego zatem potrzebujemy? Musimy uświadomić nasz system, że będziemy wykorzystywać ACL’e dla konkretnych systemów plików. No i przede wszystkim – musimy mieć narzędzia do zarządzania ACL’ami oraz wiedzieć, jak się ich używa
Zatem po kolei.
Sprawdźmy, czy mamy narzędzia do obsługi ACL’i. Narzędzia nazywają się setfacl, getfacl oraz chacl.
desktop repos # getfacl Program getfacl nie jest obecnie zainstalowany. Można go zainstalować wpisując: apt-get install acl getfacl: command not found desktop repos #
Więc go sobie instalujemy:
sudo aptitude install acl
Spróbujmy ustawić jakąś rozszerzoną listę dostępu. Przejdźmy do katalogu domowego, załóżmy katalog test oraz nadajmy uprawnienia rwx użytkownikowi nobody.
cd mkdir test setfacl -R -m u:nobody:rwX test setfacl: test: Operation not supported
Komunikat Operation not supported oznacza nic innego jak brak obsługi ACL w systemie plików. Jeśli nasz katalog domowy znajduje się na odrębnym systemie plików home, możemy aktywować obsługę ACL komendą:
sudo mount -o remount,acl /home
Teraz ustawianie rozszerzonych uprawnień powinno już działać. Ponowne wydanie komendy setfacl nie powinno już zwrócić błędu.
Przy okazji, możemy zobaczyć jak wyglądają uprawnienia naszego katalogu:
nme@desktop ~ $ setfacl -R -m u:nobody:rwX test nme@desktop ~ $ ls -lad test/ drwxrwxr-x+ 2 nme nme 4096 2009-12-30 14:29 test/ nme@desktop ~ $ getfacl test # file: test # owner: nme # group: nme user::rwx user:nobody:rwx group::r-x mask::rwx other::r-x
Warto zwrócić uwagę na uprawnienia zwracane komendą ls -l: drwxrwxr-x+ – na końcu listy uprawnień znajduje się znak + oznaczający rozszerzone informacje. Takie uprawnienia możliwe są do odczytu za pośrednictwem getfacl co też uczyniłem powyżej. Wynik komendy jest dość czytelny.
Wracając do wydanej komendy:
setfacl -R -m u:nobody:rwX test
Co po naszemu brzmi – rekursywnie zmodyfikuj uprawnienia dla użytkownika nobody dla katalogu test ustawiając uprawnienia rwx dla katalogów i rw dla plików.
Dziecinne proste. Rozbudujmy komendę:
setfacl -Rm u:nobody:rwX,d:u:nobody:rwX test
(pierwsza część jest tak naprawde zbędna, ponieważ uprawnienia dla użytkownika już ustawiliśmy, ale chciałem przedstawić sposób w jaki możemy łączyć uprawnienia w obrębie jednej komendy)
d:u:... można zapisać również jako default:u:... co oznacza, że dla nowo zakładanych plików/katalogów, takie atrybuty mają być domyślnie dodawane.
Ważna sprawa, na koniec
Aby używać list dostępu, aktywowaliśmy opcję acl poprzez przemontowanie systemu pliku. Niestety, po restarcie, system plików nie będzie już obsługiwał list dostępu.
Co zatem zrobić?
Jeśli chcemy, aby nasz system plików pamiętał o tym, że ma obsługiwać rozszerzone listy dostępu, w pliku /etc/fstab należy to zaznaczyć, acl jako opcję dla naszego systemu plików:
/dev/mapper/desktop-home /home ext3 defaults,acl 0 2
Więcej informacji, wraz z przykładami znaleźć możecie na stronach manuala komend do obsługi acl które przedstawiłem w tym tekscie.
Ailurus: wygodny tuning Ubuntu
Niestrudzony Adrian Nowak, na blogu Ubucentrum zamieścił wpis Ailurus – ułatwi początki z Linuksem.
Czym jest Ailurus? To wygodny interfejs produkcji “Thrusted Digital Technology Lab.” z siedzibą w Chinach, do tuningu systemu i obsługi systemu
Faktycznie, narzędzie jest faktycznie bardzo ciekawe. Nie znajduje się jednak w standardowym repozytorium. Dlatego myślę, że warto wspomnieć, w jaki sposób najwygodniej je zainstalować.
Nie zalecałbym metody którą proponuje Adrian – czyli instalacji pojedynczej paczki z serwisu GetDeb.net.
Instalowanie pojedynczych paczek jest zaśmiecaniem systemu.
Instalacja
W Ubuntu 9.10 możemy w wygodny sposób dodawać repozytoria, które sprawią, że jeśli pojawi się nowa wersja pakietu, przy aktualizacji systemu, pakiet zostanie również uaktualniony.
# przechodzimy na roota sudo -i # dodajemy nowe repozytorium add-apt-repository ppa:ailurus # aktualizujemy wykaz aktualnych pakietów aptitude update # instalujemy pakiet aptitude install ailurus
Aplikacja, po instalacji jest dostępna poprzez Programy / Narzędzia systemowe / Ailurus.
Co oferuje nam pakiet?
- Tips and tricks – warto przeglądnąć – informacje jak za pomocą gconf-editora wykonać tuning naszego Gnome’a
- Wygodny frontend do konfiguracji i sprawdzenia parametrów systemu (typ procesora, ilość pamięci, czy procesor jest 64-bitowy, rodzaj karty graficznej i sieciowej)
- Skróty do instalacji różnych przydatnych aplikacji, których nazwy należałoby w innym wypadku pamiętać albo trzeba byłoby się bardziej narobić, żeby je zainstalować
- Ustawienia systemowe – innymi słowy – edycja plików konfguracyjnych, modifykacja menu kontekstowego Nautilusa itp
- i wiele innych…
Kiedy można sobie ułatwić życie, warto to robić
Infrastruktura PKI na podstawie SSH
Infrastruktura kluczy publicznych (ang. Public Key Infrastructure, w skrócie PKI) jest podstawą współczesnej kryptografii. Miałem już styczność z wieloma osobami z branży IT, które kompletnie nie czuły o co właściwie w tym chodzi.Myślę, że poniższy tekst napewno się komuś przyda oraz, że warto mu poświęcić 5 minut. Spróbuję się maksymalnie streścić
Klucze symetryczne i niesymetryczne
Większość szyfrowanych kanałów transmisji wykorzystuje jednocześnie klucze niesymetryczne jak i symetryczne.
Zaletą kluczy symetrycznych (takich jak AES, Blowfish czy DES) jest szybkość szyfrowania/deszyfrowania przy stosunkowo niskim obciążeniu procesora.
Wadą kluczy symetrycznych jest etap nawiązania transmisji. Jeśli oba komputery nie posiadają tego samego klucza do szyfrowania/deszyfrowania wiadomości – klucz taki musiałby być wysłany z jednego z nich do drugiego drogą nieszyfrowaną. Taką wymianę klucza można byłoby łatwo podsłuchać. Następnie, korzystając z tak zdobytego klucza – można podsłuchać resztę transmisji (taki atak nosi nazwę Man In The Middle).
Dlatego właśnie pojawiły się klucze niesymetryczne (np. stosowany standardowo w protokole ssh – algorytm RSA). Klucz niesymetryczny składa się z dwóch części – publicznej i prywatnej. Posiadacz części publicznej klucza jest w stanie zaszyfrować wiadomość. Posiadacz klucza prywatnego – może taką wiadomość odszyfrować. Proste. Dodatkowo – na podstawie klucza publicznego jesteśmy w stanie zweryfikować odcisk klucza (fingerprint) – jeśli się zgadza, wiemy, że rozmawiamy z właściwym serwerem.
Klucze w praktyce
Serwery Linuxowe na których pracuje usługa ssh mają również wygenerowane swoje klucze. Autentykacja może być różnoraka, jednak do najpopularniejszych należą – para użytkownik-hasło oraz łączenie się z wykorzystaniem kluczy.
Wykorzystanie haseł jest proszeniem się o kłopoty. Warto przesiąść się na klucze. Jak to zrobić?
Wygenerujmy sobie klucz. W obecnych czasach warto zaznaczyć, że chcemy mieć klucz 4096-bitowy, będzie się generował dłużej, ale będzie bezpieczniejszy. Warto też ustawić hasło dla klucza.
nme@notebook ~ $ ssh-keygen -b 4096 Generating public/private rsa key pair. Enter file in which to save the key (/home/nme/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/nme/.ssh/id_rsa. Your public key has been saved in /home/nme/.ssh/id_rsa.pub. The key fingerprint is: 12:30:87:ca:06:81:d8:5a:32:41:81:4c:3a:74:33:a9 nme@notebook The key's randomart image is: +--[ RSA 4096]----+ |XO.++.. | |X.+.++ | |oB.. . | |.E+ . | | . . S | | . | | | | | | | +-----------------+ nme@notebook ~ $
W katalogu .ssh pojawiły się dwa pliki id_rsa – będący naszym kluczem prywatnym oraz id_rsa.pub – czyli klucz publiczny.
Klucza publicznego nie trzeba specjalnie strzec. Ważne, aby nasz klucz prywatny nie dostał się w cudze ręce.
Po co ten obrazek w ASCII? Abyśmy nie musieli weryfikować znak po znaku naszych kluczy. Jeśli chcemy odczytać fingerprint klucza, wydajemy komendę:
ssh-keygen -l
Jeśli chcemy zobaczyć odcisk wraz z obrazkiem ASCII – wydajemy:
ssh-keygen -lv
Okej. Powiedzmy, że mamy klucze i serwer na który chcielibyśmy się łączyć za ich pomocą. Musimy umieścić zawartość naszego klucza publicznego w pliku .ssh/authorized_keys na serwerze docelowym. Możemy to zrobić komendą:
nme@notebook ~ $ ssh-copy-id serwer: The authenticity of host 'serwer (x.x.x.x)' can't be established. RSA key fingerprint is fe:2b:6b:71:6f:81:ef:07:74:89:72:e7:ef:ab:f8:62. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'serwer,x.x.x.x' (RSA) to the list of known hosts. Password: nme@notebook ~ $
teraz możemy już normalnie się zalogować:
nme@notebook ~ $ ssh serwer nme@serwer ~ $
W pliku .ssh/authorized_keys możemy trzymać dowolną ilość kluczy.
Dobrą praktyką jest generowanie kluczy prywatnych na każdej stacji roboczej z której łączymy się na inne maszyny. W wypadku gdy np. ktoś ukradnie nam jedną z tych maszyn – wystarczy usunąć dane klucze z plików authorized_keys serwerów, do których mamy dostęp.
Skoro już opanowaliśmy klucze – warto wyłączyć autoryzację do naszych serwerów za pośrednictwem par użytkownik-hasło. Robimy to edytując plik /etc/ssh/sshd_config – weryfikujemy ustawienia:
# Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords PasswordAuthentication no
Restart sshd we współczesnych Ubuntu czy RedHatach wykonujemy komendą:
sudo service ssh restart
Kiedy wyłączymy już logowanie na pary użytkownik-hasło i pozostawimy jedynie logowanie na klucze:
nme@notebook ~ $ ssh serwer Permission denied (publickey). nme@notebook ~ $
Gdzie poza SSH stosowane są jeszcze klucze?
Infrastruktura kluczy publicznych (PKI) stosowana jest również przykładowo w HTTPS czy w sieciach bezprzewodowych – WPA2 (AES). Klucze niesymetryczne stosowane są do nawiązania transmisji między klientem i serwerem – celem wymiany klucza symetrycznego, a następnie transmisja jest już oparta o klucz symetryczny.
Znajomość ogólnych zasad działania PKI jest bardzo praktyczna również w przypadku, jeśli przymierzamy się do wykorzystania OpenPGP czy certyfikatów SSL, które możemy traktować jak wyższe stopnie zaawansowania
Wyłączenie użytkownikowi MOTD na Ubuntu
Tematyka niniejszego wpisu jest, można powiedzieć wręcz banalna, ale myślę, że to trick warty poznania lub przypomnienia. Nie dotyczy tylko i wyłącznie dystrybucji Ubuntu, ale w zasadzie wszystkich Linuxów.
Jeśli logujesz się po ssh na inny komputer, wyświetlana jest zawartość Message Of The Day (/etc/motd). Jeśli nie chcesz tego widzieć, w swoim katalogu domowym wystarczy utworzyć plik o nazwie .hushlogin, wersja copy & paste:
cd touch .hushlogin
(polecenie cd bez parametrów to kolejny trick – sprawia, że zostajemy przeniesieni do naszego katalogu domowego)
Efekt
Zilustrowałem poniżej:
nme@desktop ~ $ ssh laptop Linux laptop 2.6.31-14-generic-pae #48-Ubuntu SMP Fri Oct 16 15:22:42 UTC 2009 i686 To access official Ubuntu documentation, please visit: http://help.ubuntu.com/ System information as of Fri Nov 6 20:56:41 CET 2009 System load: 0.16 Memory usage: 18% Processes: 155 Usage of /: 7.1% of 35.51GB Swap usage: 0% Users logged in: 1 Graph this data and manage this system at https://landscape.canonical.com/ Last login: Fri Nov 6 20:55:19 2009 from desktop.local nme@laptop ~ $ touch .hushlogin nme@laptop ~ $ logout Connection to laptop closed. nme@desktop ~ $ ssh laptop nme@laptop ~ $
Proste, aczkolwiek przydatne
Wprowadzenie do systemu kontroli wersji Mercurial
Poniższy tekst jest jedynie wprowadzeniem do pracy z Mercurialem. Osoby które chcą pogłębić swoją wiedzę w zakresie tego tematu – zachęcam do przeczytania darmowej książki dostępnej w Internecie – Mercurial: The Definitive Guide.
Aby pracować na Mercurialu musimy go najpierw zainstalować. Dla systemu Windows Mercurial jest jedną wygodną do zainstalowania paczką. Informację jak zalecam to zrobić pod Ubuntu, zamieściłem tu: Instalacja Mercurial z GUI TortoiseHG pod Ubuntu 9.04.
Konfiguracja wstępna
Zanim rozpoczniemy pracę z Mercurialem, należy w swoim katalogu domowym utworzyć plik .hgrc w którym konfigurujemy swojego użytkownika. Plik ten powinien zawierać następującą treść:
[ui] username = Imie Nazwisko < konto@domena.pl >
Pod Linuxem lub Unixem warto również ustawić zmienną środowiskową EDITOR wskazującą na nasz
ulubiony edytor. W moim wypadku, w pliku .bashrc w katalogu domowym
musiałem dodać na końcu linijkę:
export EDITOR="vim"
W tym momencie możemy już przystąpić do pracy.
Tworzenie repozytorium
Załóżmy, że jesteśmy w katalogu testy.
Utwórzmy w nim plik notatki.txt zawierający jedną linijkę tekstu:
To są moje notatki
Utwórzmy też katalog dokumenty, a w nim umieśćmy plik do-zrobienia.txt zawierający następującą treść:
[ ] Zrobić przelewy za październik [ ] Podać do Energetyki stan licznika
Struktura plików i katalogów wygląda zatem następująco:
user@host testy $ ls dokumenty notatki.txt user@host testy $ ls dokumenty/ do-zrobienia.txt
Możemy w tym momencie utworzyć sobie repozytorium Mercuriala. Przechodzimy zatem do katalogu testy i wydajemy komendę:
user@host testy $ hg init
W katalogu powinien pojawić się podkatalog .hg
Co teraz możemy zrobić? Dostępne komendy pojawią się po wydaniu komendy hg bez parametrów:
user@host testy $ hg Mercurial Distributed SCM basic commands: add add the specified files on the next commit annotate show changeset information by line for each file clone make a copy of an existing repository commit commit the specified files or all outstanding changes diff diff repository (or selected files) export dump the header and diffs for one or more changesets forget forget the specified files on the next commit init create a new repository in the given directory log show revision history of entire repository or files merge merge working directory with another revision parents show the parents of the working directory or revision pull pull changes from the specified source push push changes to the specified destination remove remove the specified files on the next commit serve export the repository via HTTP status show changed files in the working directory update update working directory view start interactive history viewer use "hg help" for the full list of commands or "hg -v" for details
Jeśli chcemy uzyskać większą ilość komend, należy uruchomić polecenie
hg help.
Zobaczmy status naszego katalogu. Możemy napisać hg status, jednak można też zastosować skróconą wersję komendy:
user@host testy $ hg st ? dokumenty/do-zrobienia.txt ? notatki.txt
Widzimy, że system Mercurial widzi dwa pliki. Przed ich nazwami figuruje znak pytajnika, co oznacza, że Mercurial nie do końca wie, co to za pliki.
Dodawanie plików do repozytorium
Do dodawania plików do repozytorium służy komenda hg add [nazwa pliku], przy czym nazwa pliku jest parametrem opcjonalnym. Jeśli jej nie podamy – Mercurial doda wszystkie nieznane pliki w naszym katalogu i podkatalogach do repozytorium.
Dodajmy nasze pliki do repozytorium.
user@host testy $ hg add adding dokumenty/do-zrobienia.txt adding notatki.txt
podglądając status widzimy:
user@host testy $ hg st A dokumenty/do-zrobienia.txt A notatki.txt
Zatwierdzanie i weryfikowanie zmian
możemy w tym momencie zatwierdzić zmiany:
user@host testy $ hg commit
W tym momencie uruchomi się nam edytor w którym uzupełniamy pierwszą linię. Pozostałe zostały zasugerowane przez Mercuriala:
utworzone repozytorium
HG: Enter commit message. Lines beginning with 'HG:' are removed. HG: Leave message empty to abort commit. HG: -- HG: user: Imie NazwiskoHG: branch 'default' HG: added dokumenty/do-zrobienia.txt HG: added notatki.txt
Jeśli chcemy którąś z tych linii pozostawić, powinniśmy usunąć HG: sprzed wpisu.
Po zapisaniu pliku, jeśli Mercurial znajdzie choć jedną linię opisu (czyli w naszym wypadku tekst “utworzone repozytorium”), zapisze to jako nową wersję (revision).
Możemy podejżeć zmiany:
user@host testy $ hg st user@host testy $
Jak widać, nie ma żadnych. Zobaczmy zatem historię:
user@host testy $ hg log changeset: 0:996ae301b615 tag: tip user: Imie Nazwiskodate: Tue Oct 13 08:40:12 2009 +0200 summary: utworzone repozytorium user@host testy $
Dokonajmy jakiejś zmiany w pliku dokumenty/do-zrobienia.txt, powiedzmy, że teraz wygląda tak:
[x] Zrobić przelewy za październik [ ] Podać do Energetyki stan licznika
Sprawdzając status widzimy:
user@host testy $ hg st M dokumenty/do-zrobienia.txt user@host testy $
Możemy też podejżeć co zostało zmienione:
user@host testy $ hg diff diff -r 996ae301b615 dokumenty/do-zrobienia.txt --- a/dokumenty/do-zrobienia.txt Tue Oct 13 08:40:12 2009 +0200 +++ b/dokumenty/do-zrobienia.txt Tue Oct 13 08:46:21 2009 +0200 @@ -1,2 +1,2 @@ -[ ] Zrobić przelewy za październik +[x] Zrobić przelewy za październik [ ] Podać do Energetyki stan licznika user@host testy $
Zatwierdzę teraz zmiany, sprawdzę status i historię:
user@host testy $ hg commit user@host testy $ user@host testy $ hg st user@host testy $ user@host testy $ hg log changeset: 1:155c93da6b65 tag: tip user: Imie Nazwiskodate: Tue Oct 13 08:48:01 2009 +0200 summary: aktualizacja changeset: 0:996ae301b615 user: Imie Nazwisko date: Tue Oct 13 08:40:12 2009 +0200 summary: utworzone repozytorium user@host testy $
Usuwanie plików z repozytorium
Teraz usunę plik notatki.txt:
user@host testy $ hg remove notatki.txt user@host testy $ ls dokumenty user@host testy $
Zatwierdzę zmiany i zobaczę historię. Ograniczę sobie przy okazji historię do dwóch najaktualniejszych zmian:
user@host testy $ hg commit user@host testy $ hg log -l 2 changeset: 2:ec95d15664fb tag: tip user: Imie Nazwiskodate: Tue Oct 13 08:51:36 2009 +0200 summary: usunięte notatki changeset: 1:155c93da6b65 user: Imie Nazwisko date: Tue Oct 13 08:48:01 2009 +0200 summary: aktualizacja user@host testy $
Zdecydowałem jednak, że przywrócę plik notatki. Cofnę zatem ostatniego commita komendą rollback, zobaczę jaki
jest status i przywrócę plik notatki.txt:
user@host testy $ hg rollback rolling back last transaction user@host testy $ hg log changeset: 1:155c93da6b65 tag: tip user: Imie Nazwiskodate: Tue Oct 13 08:48:01 2009 +0200 summary: aktualizacja changeset: 0:996ae301b615 user: Imie Nazwisko date: Tue Oct 13 08:40:12 2009 +0200 summary: utworzone repozytorium user@host testy $ hg st R notatki.txt user@host testy $ ls dokumenty user@host testy $ hg revert notatki.txt user@host testy $ ls dokumenty notatki.txt user@host testy $
Myślę, że jako wprowadzenie, taki opis wystarczy
Drażniący dzwięk podczas pracy na baterii w Ubuntu
Linux Ubuntu jest na tą chwilę chyba najlepszą Linuxową dystrybucją na desktopa. Jest ona jednak nadal świeża i zdarza się, że czasami ma pewne problemy z nowszym sprzętem.
Jednym z takich problemów z którym się zetknąłem jest drażniący pisk czyli dźwięk o wysokiej częstotliwości (ang. high-pitch noise) podczas pracy notebooka na zasilaniu bateryjnym. Przyczyną tego dzwięku jest wyższy tryb ACPI odpowiedzialny z zarządzaniem zasilaniem i temperaturą. Więcej szczegółów technicznych można znaleźć na stronach Intela opisujących C-State Architecture.
Mój notebook ma procesor Intel Centrino (Core2) Duo T5600 i niestety ten problem go dotyczy.
Stare rozwiązanie stosowane w Ubuntu 8.04
W jądrze systemu ustawiona jest możliwość zmiany tego parametru podczas pracy systemu (parametr CONFIG_ACPI_PROCESSOR=y).
Aby dźwięk ustał należy uruchomić komendę:
echo 2 >/sys/module/processor/parameters/max_cstate
Można pokusić się o dodanie takiego skryptu do /etc/acpi.d który ten problem rozwiąże, ale lepiej zastosować następne rozwiązanie.
Szczegółowe informacje można znaleźć tutaj.
Nowe rozwiązanie dla Ubuntu 8.04, 8.10 i 9.04 oraz prawdopodobnie pozostałych
W konfiguracji grub’a, do parametrów kernela należy dodać processor.max_cstate=2, przykładowy wpis:
title Ubuntu 9.04, kernel 2.6.28-15-generic root (hd0,1) kernel /vmlinuz-2.6.28-15-generic root=/dev/mapper/sys-root ro quiet splash processor.max_cstate=2 initrd /initrd.img-2.6.28-15-generic quiet
Rozwiązanie to ma tą wadę – trzeba o nim pamiętać i uzupełniać w konfiguracji gruba nowe kernele o ten parametr. Jeśli to rozwiązanie jest dla Ciebie przydatne to zachęcam do oznaczenia go sobie w Google Readerze jako ulubione, bo kto wie, być może będzie potrzeba aby do niego wrócić
Mercurial w Eclipse IDE
Środowisko programistyczne Eclipse jest jednym z najlepszych spośród tych dostępnych za darmo. Osobiście preferuję vim’a, ale większość programistów przywykło do większych luksusów
Eclipse jest dostępny zarówno pod Windows jak i pod Linuxem. Jego instalacja w systemie Microsoftu jest dość prostą czynnością.
W Linux Ubuntu, Eclipse jest niby też dostępny w standardowej dystrybucji, ale mnie osobiście nigdy nie udało się go z sukcesem uruchomić ze standardowej paczki. Tym z Was, którzy chcą z niego skorzystać pod Ubuntu zachęcam do pobrania Eclipse z ich strony, następnie rozpakowanie go do docelowego katalogu, a na koniec ręczne stworzenie skrótu.
Eclipse zostało stworzone w Javie i w zamyśle jest IDE służącym do tworzenia aplikacji właśnie w tym języku. Dzięki zaawansowanemu systemowi rozszerzeń możliwe jest jednak jego wykorzystanie do tworzenia aplikacji w innych językach. Właśnie ten mechanizm umożliwi nam również uzupełnienie Eclipse’a o system kontroli wersji.
Aby mieć możliwość z korzystania z Mercuriala, konieczna będzie jego instalacja w systemie. Dla systemu Microsoft Windows można go pobrać z tej strony. Dodatkowo warto zainstalować TortoiseHG. Kroki opisujące instalację pod Linux Ubuntu wraz z TortoiseHG opisałem tutaj.
Wtyczka Mercurial-Eclipse
Aby za pomocą środowiska Eclipse posługiwać się systemem kontroli wersji Mercurial, konieczne będzie dodanie jego repozytorium do dostępnych źródeł w Eclipse. W tym celu wybieramy Help / Install new software… / Add… i podajemy:
name: Mercurial Eclipse
location: http://www.vectrace.com/eclipse-update/
Osobiście testowałem plugina w wersji 1.4.1286 – zainstalował się i działał prawidłowo.
Po zainstalowaniu, plugin poprosi o restart środowiska Eclipse. Kiedy już Eclipse zacznie ponownie działać, powinniśmy mieć dostęp do nowej funkcjonalności.
Dość ważną kwestią jest na początku zaglądnięcie do ustawień Mercuriala – Window / Preferences, wybieramy Team / Mercurial. Należy tutaj podać Mercurial Username w postaci Imię nazwisko <adres@email>. Zaleciłbym również zaznaczenie opcji Automatically associate Mercurial with new projects containing hg repository.
Jeśli chodzi o zakładanie repozytorium dla istniejącego już projektu – w Eksploratorze workspace wybieramy projekt, naciskamy prawy klawisz myszy, następnie Team / Share project – tam wybieramy Mercurial i na następnej stronie wizarda Use project root.
Jeśli repozytorium już było założone – trzeba zaglądnąć do projektu podobnie jak przy tworzeniu nowego repozytorium, wybrać Share project, a na końcu Use existing .hg repository.
W tym momencie możemy już korzystać z bardziej urozmaiconej zawartości popup menu Team

Instalacja Mercurial z GUI TortoiseHG pod Ubuntu 9.04
Mercurial jest jednym z najpopularniejszych ostatnio systemów kontroli wersji. Został on napisany w języku Python i coraz więcej projektów jest do niego migrowanych. Google Code umożliwia wybór jednego z dwóch systemów kontroli wersji – jednym z nich jest SVN, drugim właśnie Mercurial.
Różnice między scentralizowanym a rozproszonym systemem kontroli wersji
Zasada działania Mercuriala jest zbliżona do Git‘a – oba są tzw. rozproszonymi systemami kontroli wersji. SVN z drugiej strony jest systemem zcentralizowanym. Praca na systemie rozproszonym jest o tyle wygodna, że każda lokalna kopia repozytorium może być traktowana jako pełnoprawna i całkowicie niezależna. Rozwijając kod który jest obsługiwany w takim systemie kontroli wersji, commitowanie, czyli zatwierdzanie mniejszych porcji zmian jest znacznie wygodniejsze i nie wymaga zaprzątania głowy głównego repozytorium… którego tak naprawdę wcale nie musi być.
Jak to robi Linus Torvalds?
Większe projekty, takie jak jądro Linuxa coraz częściej przechodzą na rozproszone systemy kontroli wersji. Linus Torvalds bardzo zachęca wszystkich do migrowania do Gita z SVN’a. Git został napisany właśnie z myślą o developerach jądra systemu Linux. Głównymi zaletami według niego są dwie kwestie – pierwsza: znacznie wygodniejsze merge’owanie (łączenie zmian wprowadzonych przez różnych developerów) oraz druga – rozproszone repozytoria pozwalają na hierarchiczne scalanie kodu (z punktu widzenia pracy grupowej). Dzięki tej drugiej, Linus może powierzyć np. opiekę nad modułami jądra dotyczącymi sieci komuś, kto zna się na tym konkretnym temacie lepiej, potrafi weryfikować zmiany i poprawki. Zebrane do repozytorium przez opiekuna drzewa sieci poprawki, Linus może włączyć do jego repozytorium, które traktowane jest jako główne mając pewność, że wszystkie zmiany zostały odpowiednio zweryfikowane.
Kontrola wersji z linii komend
Mercuriala można zainstalować ze standardowego pakietu w Ubuntu. Na pakiet składa się jedna aplikacja – hg. Za jej pomocą można wykonać wszystkie operacje na repozytorium z poziomu linii komend.
$ hg Mercurial Distributed SCM basic commands: add add the specified files on the next commit annotate show changeset information by line for each file clone make a copy of an existing repository commit commit the specified files or all outstanding changes diff diff repository (or selected files) export dump the header and diffs for one or more changesets forget forget the specified files on the next commit init create a new repository in the given directory log show revision history of entire repository or files merge merge working directory with another revision parents show the parents of the working directory or revision pull pull changes from the specified source push push changes to the specified destination remove remove the specified files on the next commit serve export the repository via HTTP status show changed files in the working directory update update working directory view start interactive history viewer use "hg help" for the full list of commands or "hg -v" for details
Kontrola wersji z poziomu interfejsu graficznego
Istnieje jednak możliwość pracy graficznej. Windowsowi użytkownicy jako graficzny interfejs zwykle wykorzystują TortoiseHG, który wywodzi się z TortoiseSVN. Pod Linuxem możemy również wykorzystać TortoiseHG.
Instalacja Mercuriala i TortoiseHG pod Ubuntu 9.04
Uruchomienie komend zamieszczonych poniżej sprawi, że nasz Mercurial zostanie “podniesiony” do najnowszej stabilnej wersji, pojawi się nam TortoiseHG również w wersji stabilnej, a następnie TortoiseHG zostanie włączone do domyślnego menadżera plików w Gnome – Nautilusa. Zainstalowana zostanie również aplikacja Meld, która czyni merge’owanie całkiem przyjemną czynnością w interfejsie graficznym
# Najpierw przechodzimy na roota, tego którego w Ubuntu nie masudo -i # Dodajemy drzewo stable repozytorium Mercuriala z Ubuntu Launchpad PPA cat >/etc/apt/sources.list.d/mercurial.list << EOF deb http://ppa.launchpad.net/mercurial-ppa/stable-snapshots/ubuntu jaunty main deb-src http://ppa.launchpad.net/mercurial-ppa/stable-snapshots/ubuntu jaunty main EOF sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key 323293EE # Dodajemy drzewo stable repozytorium TortoiseHG z Ubuntu Launchpad PPA cat >/etc/apt/sources.list.d/tortoisehg.list << EOF deb http://ppa.launchpad.net/tortoisehg-ppa/stable-snapshots/ubuntu jaunty main deb-src http://ppa.launchpad.net/tortoisehg-ppa/stable-snapshots/ubuntu jaunty main EOF sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key D5056DDE # odświeżamy listę repozytoriów i pobieramy pakiety oraz dodajemy obsługę bindingsów Pythona w Nautilusie aptitude update aptitude install -y python-nautilus mercurial tortoisehg tortoisehg-nautilus meld # doinstalowujemy pakiet iniparse wget http://iniparse.googlecode.com/files/python-iniparse_0.3.1-1_all.deb dpkg -i python-iniparse_0.3.1-1_all.deb rm python-iniparse_0.3.1-1_all.deb
Po wykonaniu tych komend najlepiej się przelogować ponownie, aby Nautilus zdał sobię sprawę z wprowadzonych zmian. Można też (już na swoim użytkowniku) uruchomić komendę:
nautilus -q
Która spowoduje przeładowanie Nautilusa (może nam zniknąć do następnego zalogowania zawartość pulpitu). Jeśli wszystko pójdzie pomyślnie, w efekcie możemy zarządzać repozytorium w następujący sposób:


