[uzavřeno] jakublucky.cz

Je to pár dnů, co se mi do ruky dostala nová tiskárna, HP OfficeJet J6410. Je to moc pěkný multifunkční kousek, vedle oboustranného i barevného tisku (inkoust, kazety 350 a 351) zvládá také skenování (i z podavače, takže více stran najednou) až do 4800 DPI, barevné kopírování (bez nutnosti počítače) a fax. To vše přes USB, Ethernet i Wifi (až do WPA)

Jak na ní přes ethernet nebo USB v Debianu?

1. (Jen pro ethernet) někde v síti rozběhat DHCP, nebo přes ovládací panel na tiskárně nastavit IP adresu
2. doinstalovat balíčky hplip hplip-ppds cups libsane
3. spustit příkaz hp-setup

Tiskárna je okamžitě připravena k použití, skenování přes xsane funguje bez problémů

V poslední době jsem na webech *.debian-linux.cz a abclinuxu.cz několikrát narazil na zmínku o tom, že se v Debianu používá jako defaultní hash hesel md5, což osobně nepovažuji za dobrý nápad, vzhledem k tomu, že md5 je zdiskreditována (např zde) (jedním z diskreditujících byl dokonce Čech Vlastimil Klíma)

 Co to pro nás znamená? V první řadě fakt, že pokud se někdo dostane k našemu /etc/shadow, má teoretickou (ale reálnou) možnost rekonstruovat původní heslo, nebo alespoň sekvenci znaků, která generuje shodnou hash, tedy se teoreticky dá použít k autentizaci…

Je to kritické? Proč se nic neděje? Kritické to není, Debian používá ještě takzvanou “sůl”, která hashovací funkci modifikuje, takže je zneužití dosti ztíženo, nikoliv však znemožněno.

Jak to tedy spravit? Nejlépe je upravit konfigurační soubor autentifikačního systému PAM tak, aby používal jinou hash než md5. Při prohledání manuálové stránky jsem si vybral sha512, která se zdá být dostatečně bezpečná

Otevřete si pod rootem soubor /etc/pam.d/common-password

Řádek:

password [success=1 default=ignore] pam_unix.so obscure md5

změňte takto

password [success=1 default=ignore] pam_unix.so obscure sha512


a pomocí passwd změňte heslo (stejně to potřebujete, protože to staré už máte dlouho ;-) )

Varování! S PAMem si příliš nehrajte, chybné nastavení PAMu může vést k dost nepříjemným následkům, například k otevření bezpečnostní díry nebo naopak k nemožnosti přihlásit se.

Hledám nějaký šikovný wiki systém, na který bych mohl dávat své Howto. Nejsem ohledně tohoto příliš náročný, ale mám jednu podmínku, kterou například Mediawiki (ta, co je na wikipedia.org) nesplňuje. Touto podmínku je jednoduše říditelný systém práv, který by umožnil:

• Mít neveřejné články (ke čtení jen pro některé skupiny)
• Mít pro některé skupiny možnost mít články read-only
• Systém schvalování nových uživatelů/ jednoduché přidělování práv

Pro MediaWiki sice existuje plužina accesscontrol, kterou v praxi znám z Gewiki, nicméně ten není vyhovující, spíše z něj mám pocit, že nefunguje než funguje…

Nedávno jsem už nevydržel rachocení svého Thinkpadu, respektive jeho větráku, a rozhodl jsem se ho dát do servisu. Zapátral jsem na internetu po autorizovaných Lenovo/IBM servisech, protože notebook je ještě v záruce.

To bylo první příjemné překvapení, na rozdíl od Asusu, který má jeden jediný centrální servis a to ještě v Ostravě, Lenovo jich má po Praze desítky a několik z nich dokonce nedaleko mého bydliště. Zasondoval jsem ještě na Jabberu a DragonJake mi doporučil Bit Servis, který dokonce není příliš daleko ode mě.

Do servisu jsem se vydal v pátek dopoledne, protože jsem odpoledne odjížděl na delší dobu pryč do míst, kde bych notebooku stejně moc neužil. Z Kačerova jsem byl za chvilku na místě (autobus jede cca 10 minut) a nastal asi jediný problém celé akce. Zjistit kudy dovnitř. Nejistě jsem zazvonil na dveřích, dlouho se nikdo neozýval a už jsem skoro začínal mít vztek, že jsem jel zbytečně, ale nakonec se dveře otevřeli a já vstoupil dovnitř. Pak už to šlo ráz na ráz. Slečna, která reklamaci vyřizovala jen zadala sériové číslo do systému, řekla mi, že mám ještě rok a půl záruku, zapsala do protokolu o předání i UltraBay zařízení, které bylo zasunuto v notebooku a varovala mne, že jeden z techniků má dovolenou a že to bude trvat trochu dýl. To mě zamrzelo, ale co se dá dělat.

Za 10 minut už jsem čekal na autobus zpátky na Kačerov a se svým odjezdem  jsem na celou věc defakto zapomněl. Hned v pondělí se mi ozvalo neznámé číslo, z něj se ozvala slečna, která se mnou v pátek vyřizovala reklamaci, aby mi řekla, že oprava notebooku je hotova…

Shrnuto: Rychlý a zcela bezproblémový servis

Když jsem zjistil, jak někteří nešťastníci tápají, kterak se reportují bugy v Debianu, rozhodl jsem se celé společnosti výrazně ulevit od tohoto nešvaru a napsat stručný návod, který snad pomůže každému náhodně zacestovalému hledači…

Krok #1, instalace potřebného

V první řadě je potřeba nainstalovat balíček (velikost 815k), která nám umožní používat skvělé konzolové rozhraní.

apt-get install python-urwid

Krok #2, spuštění reportbugu

V oblíbeném terminálovém emulátoru (Terminál, Konsole, Xter ) si pusťte (pod běžným uživatelem, root se nedoporučuje) reportbug příkazem

reportbug

V terminálu se vám objeví velké šedé okno na modrém pozadí. Uprostřed okna je vstupní formulář. Do tohoto vyplňte jméno balíku, jehož chybu reportujete.

Krok #3 Není už takový bug?

Po chvilce stahování dat z webu se vám zobrazí seznam všech aktivních bugů pro vámi zadaný balík. Pečlivě je projděte, zda tam již není něco podobného. Není větší hanba než reportovat duplicitní bug, ale stává se.

Krok #4, už konečně reportujeme

Už jsme pokročili dále. Nyní je potřeba vyplnit nadpis vašeho bugu. Věnujte chvilku tomu promyslet si, co tam patří a co ne. Určitě žádná slova jako: Help, Fuck, OMG a podobně. Věcně, stručně. Dobrý příklad může být například: Crash when ends playlist. I méně vycvičený orangutan z toho pozná, že program padá když mu skončí playlist.

Krok #5, další adresáti

Zde můžete přidat adresáty k vašemu bugu. Vesměs to není nutné, snad jedině v případě, že chcete aby vám to přišlo i na jiný mail nebo třeba kamarádovi se stejným problémem.

krok #6, důležitost chyby

V dalším kroku je důležitý bod, volba “nebezpečnosti” chyby. Obecně bych zde doporučoval volit spíše nižší než vyšší, neboť úrovněmi Critical, Grave a Serious se sice vývojáři zabývají co nejdříve, nicméně kdejaká zbytečnost označená jako Critical nebývá příliš vítána.

krok #7, patch a překlady

Pokud zasíláte patch, nebo jde o problém v překladu (překlepy v jazykových variantách jsou problémy překladu), je v tomto kroku to správné místo k označení.

krok #8, vlastní popis chyby

Nakonec se vyplňuje slovní popis chyby. Zde je vhodné uvést co nejširší množství informací:

• Způsob, jakým se dá chyba “zopakovat”, který má správce balíku provést, aby se mu projevila stejná chyba
• Zda se tato chyba projevuje od nějakého upgrade
• Svůj hardware, pokud to může mít vliv
• různé terminálové výpisy
• V případě, že program padá, výpis strace, gdb výstup apod. (o strace a gdb více v dalším díle)
• konfigurační soubory (zkontrolujte, zda neobsahují nějaké citlivé údaje)

Naopak neuvádějte aktuální verze balíčků, to zvládá reportbug vyplnit za vás.

Případné delší výpisy je vhodné přiložit spíše jako soubor a přiložit v kroku #9

krok #9, přiložení souborů a odeslání

Pokud máte některé soubory k přiložení, přiložte je nyní pomocí volby “Attach a file”,volba “Include a text file” způsobí, že se soubor vloží přímo do textu zprávy, což je obvykle nežádoucí. Nakonec bugreport odešlete.

Krok #10, komunikace s vývojářem

Odesláním bugreportu ještě celá věc neskončí, během nějaké doby se vám pravděpodobně ozve správce daného balíku a pravděpodobně po vás bude něco chtít. Je žádoucí na tyto emaily reagovat, neboť další informace mohou vést k opravení vašeho bugu nebo alespoň ke kontrole, že k této chybě už v nové verzi nedochází.