Tag: howto

Opublikowane w

Sprawdzanie dysku USB w Debianie.

O tym, że warto monitorować stan dysku, nie trzeba – mam nadzieję – nikogo przekonywać. Wystarczy tylko dodać, że wczesne wykrycie anomalii może pozwolić na proste i bezpiecznie skopiowanie wszystkich danych. Jeśli ktoś nie chce lub nie czuje się na siłach we wnikanie w dobrze opisane na wiki parametry S.M.A.R.T, to jako wariant minimum proponuję przyjąć, że jakakolwiek różna od zera wartość dla Reallocated Sectors Count jest sygnałem, że warto szybko zrobić backup danych. A już na pewno warto spisać dysk na straty, jeśli ta wartość rośnie.

Jeśli chodzi o desktopy, to – jak podpowiada ike w komentarzu – dysk można sprawdzić korzystając z gsmartcontrol (zapewne dostępne w repozytorium pakietów dla Twojej dystrybucji). Na pewno wygodniejsze i łatwiejsze rozwiązanie.

Pisałem już o odczycie S.M.A.R.T w Debianie dla dysków w kieszeniach USB. W zasadzie temat wyglądał na wyczerpany, bo nowe smartmontools obsługują dyski w kieszeniach USB, ale… nie do końca. Niedawno miałem do czynienia z dwiema kieszeniami USB dla dysków 2,5″ – na jednej smartmontools nie umiało sprawdzić stanu dysku, na drugiej działało bez problemu.

Przeszedł bym nad tym do porządku dziennego, szczególnie, że żadna z kieszeni nie była moja, ale okazało się, że moja kieszeń 3,5″ też nie pozwala na sprawdzenie stanu dysku tak po prostu:

smartctl -a /dev/sdb
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

/dev/sdb: Unsupported USB bridge [0x04b4:0x6830 (0x001)]
Smartctl: please specify device type with the -d option.

Zatem jak sprawdzić dysk w kieszeni USB? Okazało się, że opcji do -d w smartmontools jest nieco więcej. Ten wpis podsunął rozwiązanie problemu, jest nim dodanie parametru -d usbcypress. Czyli ostatecznie komenda to:

smartctl -a -d usbcypress /dev/sdb

Wynik lsusb dla mojej kieszeni USB:

Bus 001 Device 002: ID 04b4:6830 Cypress Semiconductor Corp. CY7C68300A EZ-USB AT2 USB 2.0 to ATA/ATAPI

Podobno dość popularny producent chipsetów. Dla wyczerpania tematu – chyba wszystkie sprzętowe kontrolery RAID (przynajmniej znane mi) również pozwalają na sprawdzanie S.M.A.R.T dla dysków SATA. Też warto sprawdzać, bo można dostrzec nadchodzący błąd wcześniej, niż zgłosi go kontroler…

Opublikowane w

Grub2, memmap i problemy z upgrade do Squeeze.

Ostatni upgrade systemu (z prywatnych, głównie desktopy) do Squeeze’ego zakończony. Zasadniczo bez zgrzytów, poza tym, że wyglądał trochę inaczej niż inne, a pakietów było mnóstwo. Naprawdę mnóstwo, apt-cacher wiele nie pomógł, choć inny desktop też z niego korzysta. KDE4 robi swoje, niestety. Łącze 1Mbps to przeżytek. No i jeszcze szopka z upgrade do grub2 była.

Desktop ma uszkodzony RAM, więc korzystam ze sposobu na uszkodzoną pamięć RAM, który opisywałem wcześniej. W grub miałem wpis:

/boot/vmlinuz-2.6.32.11 root=/dev/hda2 ro memmap=2M$311M

Przy dist-upgrade wszytko wykrył poprawnie, łącznie z dodatkowymi opcjami. Oczywiście skorzystałem z proponowanej opcji chainload (i całe szczęście…). Po reboocie wchodzę do grub2, tam wybieram nowy kernel (dystrybucyjny) i… reboot. Bez żadnego komunikatu. Niefajnie. Niestety to samo powtórzyło się przy wybraniu z grub2 kernela własnej roboty, którego używałem na Lenny.

Za to – ku mojemu zdziwieniu – ze starego gruba nowy kernel zadziałał. Co ciekawe, w przeciwieństwie do wersji z Lenny’ego, obsługiwał poprawnie wpis dla memmap – przy szybkim teście podlinkowanym wyżej nie było błędów.

Chwila zabawy i jasne było, że coś się skopało. Zamiast memmap=2M$311M było widoczne… memmap=2M11M. WTF? A po usunięciu opcji memmap wszystko ładowało się poprawnie (tyle, że korzystając ze skopanego obszaru RAM). Chwila googlania i wydało się, że do /etc/default/grub trafiła linia

GRUB_CMDLINE_LINUX="memmap=2M$311M"

która po przetworzeniu przez *sh będzie faktycznie wyglądała tak, jak wyglądała, bo $3 zostanie uznane za zmienną… Grub2 dodatkowo wymaga w swoim menu postaci memmap=2M\$311M czyli ostatecznie poprawna wersja w pliku /etc/default/grub to:

GRUB_CMDLINE_LINUX="memmap=2M\\\$311M"

Jutro zgłaszam buga.

Opublikowane w

BitlBee czyli ostateczny klient CLI do… wszytkiego.

BitlBee to multikomunikator czyli klient… wszystkiego (o czym dalej), działający jak stary, dobry IRC. Filozofia jest specyficzna, bo multikomunikatorem jest demon, z którym komunikujemy się jak z serwerem IRC. Czyli bierzemy dowolnego klienta IRC (np. konsolowe irssi), którym podłączamy się do serwera BitlBee. Potem już w zasadzie analogicznie – mamy kanał (z użytkownikiem @root, który z systemowym root nie ma nic wspólnego), a kontakty dodane przez serwisy są nickami na tymże kanale. Rozmowa jak z każdym innym użytkownikiem IRC – można w osobnym oknie (domyślne i IMO najwygodniejsze), można w oknie wspólnym…

Rozstrzał wersji jest ogromny – w nowowydanym Squeeze jest bitlbee jest w wersji 1.2.8-1, w unstable – 3.0.1-1. Szybka lektura changeloga na stronie projektu i okazuje się, że zaliczyli przeskok numeracji z 1.3 na 3.0, przy czym wersja 1.3 zaliczyła całkowite przepisanie kodu IRC i tyle zmian, że w changelogu nie wymieniają. Dodatkowo, zarówno bitlbee-libpurple, czyli transport do innych sieci, jak i bitlbee-plugin-otr, czyli implementacja OTR, nie występują w wersji dla Squeeze, więc wybór był prosty – 3.0.1.

Oczywiście nie jest idealnie – już na starcie zgłosiłem buga z nieustawianiem haseł domyślnie, ale to łatwo poprawić samodzielnie. Poza tym, ma to średni wpływ, bo domyślnie demon dostępny jest tylko lokalnie, a do dostępu do samych serwisów i tak wymagane jest kolejne uwierzytelnianie.

Kolejny bug, również zgłoszony (w sumie do upstreamu), to korzystanie jedynie z niesolonych MD5 (i jedynie z nich) do przechowywania skrótów haseł. Okazało się, że błędnie, bo MD5 są solone (ale nadal tylko z MD5 można korzystać, co zbyt fajne nie jest, ale wystarczy mocne hasło do głównego konta).

W czasie testu opierałem się na tych dwóch opisach BitlBee. Nie twierdzę, że są najlepsze, ale mi wystarczyły w zupełności. Do wyboru jest sporo innych w sekcji External docs na stronie projektu. Tak naprawdę sam program posiada bardzo dobry, dostępny w każdej chwili tutorial i pomoc.

I to w zasadzie tyle. Korzystanie jest równie dobre i wygodne, na jakie wygląda z opisu. Oczywiście, jeśli komuś pasuje ircowy sposób rozmowy i obsługi. Obsługiwany jest nie tylko Jabber, ale także Twitter (czyli też identi.ca), MSN, OSCAR (AIM/ICQ). Wygląda, że BitlBee potrafi korzystać z libpurple, więc liczba protokołów raczej będzie szybko rosnąć. Teoretycznie obsługiwane są także GG, IRC (trochę nie widzę sensu, ale jest…), bonjur i wiele innych protokołów.

Na deser smaczek: BitlBee jest leciutkie. Lżejsze od centerim (dawniej centericq), z którego korzystałem do tej pory. Testy na laptopie zdane na piątkę (tylko jabber), jak tylko zrobię upgrade routera do Squeeze, to na pewno zmieniam centerim na BiltBee + irssi.

PS. Dla nieangielojęzycznych: mój krótki tutorial konfiguracji BitlBee po polsku.