Výsledek? Jedna odpověď z třiceti odeslaných emailů… Uvědomuji si, že moje nabídka (peníze za nic) není příliš atraktivní, nicméně neslušnost toho, že ani neodpovím se mi poměrně nelíbí. Raději zkousnu email typu:

Nezájem.
========
Toto je automaticky generovaný email

než ignoraci. Ignorace mi přijde neslušná až opovrhující a firma tím u mě ztrácí svůj kredit…

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ů

 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.

• 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…

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

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

• možnost klasicky blogískovat (třeba pod /blog)
• články
• sekce článků
• syntax highlighting
• propojení s Bazaar (decentralizovaný VCS)
• možnost používat vlastní PHP skripty jednoduše integrovatelné
• galerie
• RSS/Atom
• pěkné URL
• možnost více jazyků (stačí čj/aj)

Ne všechno je povinné, nicméně maximalní naplnění požadavků by se mi líbilo…

Za vaše doporučení budu rád, celkem mě láká Drupal, jen prosím zbytečně nedoporučujte Joomlu, s Joomlou nejsem duševně kompatibilní…

• heslo hashovat pořádnou hashovací funkcí, md5/sha1 jsou prolomené
• Použití soli při hashování, vyhnutí se rainbow tabulkám
• ochrana před SQL injection
• ochrana přes XSS
• nepoužívání register_globals coby bezpečnostní hrozby
• nevyžadovat zbytečné údaje
• Sledovat chyby a aktualizovat/opravovat, pokud jde o úpravu/užití připraveného systému (Joomla, Wordpress)

Co vy na to? Myslíte si, že něco chybí? Napište v komentářích, za každou připomínku děkuji…

UPDATE

• pokud je to možné, používat SSL alespoň pro login
• do cookies neukládat žádné osobní údaje