środa, 19 grudnia 2012

Fakty v2.0

Ludzie od tvnplayera postanowili zrobić update API do wersji jak przypuszczam 2.0.
-base_url = "http://tvnplayer.pl/api/?platform=ConnectedTV&terminal=Samsung&format=json"
+base_url = "http://tvnplayer.pl/api/?platform=ConnectedTV&terminal=Samsung&format=json&authKey=ba786b315508f0920eca1c34d65534cd"
-fakty_id_url = "#{base_url}&type=episodes&id=#{odc['id']}&sort=newest&m=getItem&deviceScreenHeight=1080&deviceScreenWidth=1920"
+fakty_id_url = "#{base_url}&type=episodes&id=#{odc['id']}&v=2.0&sort=newest&m=getItem&deviceScreenHeight=1080&deviceScreenWidth=1920"
W efekcie doszedł parametr "authKey" oraz "v=2.0".
"v=2.0" pewnie ma jakieś głębsze znaczenia, projektując API nikt nie pomyślał, że będzie potrzebna kolejna wersja, przecież to takie mało oczywiste, ale można uznać, że jest ok. Natomiast po co dodawać parametr "authKey", który jest statyczny (tak, nie jest liczony z niczego, ot po prostu jest dopisany na sztywno do url-a) i lata sobie w sieci bez żadnego zabezpieczenia. Pragnę poznać rozwinięcie tej, jakże głębokiej, myśli autora tego wynalazku.

Działający skrypt do oglądania faktów: https://github.com/ljagiello/scripts/blob/master/tvn_fakty.rb

wtorek, 18 grudnia 2012

RAID6 safe ?

Po co raid ? A podobno, żeby było bezpiecznie. Raid6 z założenia 2 dyski nadmiarowe, o ile nie mamy wyjątkowego pecha powinno być dobrze. Tak mi się wydawało do niedawna... Był sobie raid6 z 9 dysków, w którym nagle jeden z nich (Seagate) postanowił, że się spali. Doprowadzając do unieruchomienia każdego procesu, który chciał cokolwiek od tego zasobu. Heh, nie został oznaczony jako fail, ot postanowił, że dalej działać nie będzie. Koniec końców reboot.

Po powrocie systemu, dysk nie odpowiada, zgłasza błędy.
ata24.00: status: { DRDY ERR }
ata24.00: error: { ABRT }
ata24: hard resetting link
ata24: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata24.00: configured for UDMA/133 (device error ignored)
sd 23:0:0:0: [sds] Result: hostbyte=0x00 driverbyte=0x08
sd 23:0:0:0: [sds] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex): 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00  00 00 00 08
sd 23:0:0:0: [sds] ASC=0x0 ASCQ=0x0
sd 23:0:0:0: [sds] CDB: cdb[0]=0x28: 28 00 00 00 00 08 00 00 02 00
end_request: I/O error, dev sds, sector 8
ata24: EH complete
Smartctl mówi o dysku 4GB, którego serial nie wygląda na serial
Device Model:     ST_M13FQBL
Serial Number:    QNR_BFW
Firmware Version: 05201250
User Capacity:    4,142,054,400 bytes
Z ciekawości sprawdzam w google co to za śmieszny serial i dostaje taki link:
http://forums.seagate.com/t5/Barracuda-XT-Barracuda-Barracuda/Drive-showing-as-ST-M13FQBL-after-replacing-logic-board/td-p/131842
Faktycznie dokładnie to się stało, potwierdzone przez remote-hands.

Trudno dysk padł, maszyna powinna działać - no nie wyszło, ale przynajmniej dane są:
root@XXXXXX:~# mdadm -A /dev/md1
mdadm: /dev/md1 assembled from 8 drives - not enough to start the array while not clean - consider --force.
Ok, po dobroci nie chce, pozostaje --force:
root@XXXXXX:~# mdadm -A --force /dev/md1
mdadm: failed to RUN_ARRAY /dev/md1: Input/output error
No nie dobrze, 10TB danych nie do końca chce ponownie wrócić do życia. Okazuje się, że trzeba wyczyścić superblock i zbudować raid-a ponownie (ważne: w tej samej kolejności dysków i z tym samym chunk sizem :)
mdadm --zero-superblock /dev/sd[fhijkprb]1
mdadm --create -c 1024 -v /dev/md1 -l 6 --raid-devices=9 /dev/sd[fhijkprb]1 missing
Efekt:
/dev/mapper/md1       9.5T  4.2T  5.4T  44% /nfs/md1
Reasumując, softraid jest spoko do czasu jak działa, jak przestaje działać to jest duża szansa na to, że będą problemy, a przynajmniej, że nie skończy się na informacji o potrzebie wymiany dysku, gdzieś w systemie monitorowania.