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

poniedziałek, 13 sierpnia 2012

Grupa trzymająca władze :)

Zawsze mi się ten record podobał w RIPE-ie, a teraz to mój provider :)
person:         Grupa trzymajaca wladze
address:        INEA S. A.
address:        ul. Klaudyny Potockiej 25
address:        60-211 Poznan
address:        Poland
phone:          +48 61 2222222
fax-no:         +48 61 2221241
nic-hdl:        GTW-RIPE
remarks:        *************************************************
remarks:        no remarks, sorry.
remarks:        *************************************************
mnt-by:         ICP-MNT
source:         RIPE # Filtered

środa, 1 sierpnia 2012

Fakty

Od jakiegoś czasu TVN24 ma nową stronę. Każdy materiał wideo chce Silverlighta . Problem w tym, że nie posiadam systemu operacyjnego z firmy Microsoft, a Moonlight mimo że niby dostępny dla Linuxa nie wspiera DRM. Zasadniczo nie ma problemu, jedna strona mniej którą czytam, ale do pasji mnie doprowadza nie możliwość obejrzenia sobie Faktów przez stronę. Nie mam telewizora i nie mam jak obejrzeć tego programu, a robienie szopek z DRM-em do programu, który jest dostępny na ogólnopolskim kanale, jest co najmniej nieporozumieniem. No ale Androidowa aplikacja TVN Player przecież jakoś musi działać. Silverlight-a to raczej tam nie ma, więc musi być jakieś inne rozwiązanie. Śledząc ruch z z tcpdumpem doszedłem do wniosku, że pewne fragmenty URL-a są generowane przez aplikacje. Klucz do SHA co prawda lata po internecie, ale to jednak mało elegancka metoda i wątpliwa co do legalności. Istnieją jednak inne urządzenia, które są na tyle głupie, że nie potrafią wyliczać takich kluczy i to skłoniło mnie do napisania własnego parsera :)

Kod dostępny TUTAJ

Efekt działania jest taki:
[lcf@p0x scripts]$ ./tvn_fakty.rb 
Fakty 1.08.2012
 Standard : http://tvnplayer.pl/r/vda/id/14415/i/0/platform/ConnectedTV/terminal/Samsung/ts/1343854740/t/e0e3fa075f7ff3ea081d1751f55f95df/v/1.0
 Niska : http://tvnplayer.pl/r/vda/id/14415/i/1/platform/ConnectedTV/terminal/Samsung/ts/1343854740/t/9fc83136fa239f98bb10afd70daf0a32/v/1.0
Fakty 31.07.2012
 Standard : http://tvnplayer.pl/r/vda/id/14414/i/0/platform/ConnectedTV/terminal/Samsung/ts/1343854741/t/344b62f95b4364c93ea45615cb112196/v/1.0
 Niska : http://tvnplayer.pl/r/vda/id/14414/i/1/platform/ConnectedTV/terminal/Samsung/ts/1343854741/t/da4174ff800e5101d2f16be0c8155db8/v/1.0
[...]
Następnie:
mplayer wybrany_link_ze_skryptu
i spokojnie można obejrzeć Fakty. Oczywiście skrypt może wyciągnąć link do dowolnego programu z tvnplayer, ale mi chodziło tylko i wyłącznie o możliwość obejrzenia Faktów.

czwartek, 12 lipca 2012

Backup MongoDB

Sporo czasu używałem backup.rb, który był wypadkową potrzeb z czasów jak pracowałem w G-Forces. Tyle ile było trzeba ten skrypt robił i przez sporo czasu nie potrzebowałem nic więcej. Dzisiaj trafił mi się backup MongoDB, z taką małą różnicą, że pliki mają po 50-60GB, więc grzecznie odbiłem się od ściany w postaci limitu na wielkość pliku w Amazon S3 - 5GB (bez multipart). Pisanie własnego multiparta z użyciem splita lub innego mechanizmu, może i fajne, ale trochę nie mam na to czasu. Znalazłem ot taki wynalazek backup 3 i jak na razie jest mega. Jak prosto zrobić backup MongoDB na Amazon S3:
Generujemy template:
backup generate:model --trigger mongo --databases='mongodb' --storages='s3'
I uzupełniamy stosowne dane:
  database MongoDB do |db|
    db.name               = [ "database" ]
    db.username           = "username"
    db.password           = "password"
    db.host               = "localhost"
    db.port               = 27017
    db.ipv6               = false
    db.only_collections   = ["only", "these" "collections"]
    db.additional_options = []
    db.lock               = false
    # Optional: Use to set the location of these utilities
    #   if they cannot be found by their name in your $PATH
    # db.mongodump_utility = "/opt/local/bin/mongodump"
    # db.mongo_utility     = "/opt/local/bin/mongo"
  end
  store_with S3 do |s3|
    s3.access_key_id     = "access_key"
    s3.secret_access_key = "secret_access_key"
    s3.region            = "eu-west-1"
    s3.bucket            = "bucket_name"
    s3.path              = ""
    s3.keep              = 5
  end
Uruchomienie:
backup perform --trigger mongo -r /d0/mongo-backup/
I tyle.

czwartek, 5 kwietnia 2012

Mock

Ku pamięci,
centos-build ~ # diff -burN mock.orig/ mock/
diff -burN mock.orig/py/mockbuild/backend.py mock/py/mockbuild/backend.py
--- mock.orig/py/mockbuild/backend.py 2012-04-05 17:16:56.737094931 +0200
+++ mock/py/mockbuild/backend.py 2012-04-05 17:18:40.252105177 +0200
@@ -647,7 +647,7 @@
 
             self.root_log.debug("Copying packages to result dir")
             for item in packages:
-                shutil.copy2(item, self.resultdir)
+                os.system("cp " + item + " " + self.resultdir)
 
         finally:
             self.uidManager.restorePrivs()
Jeżeli więcej niż jeden user buduje.

wtorek, 28 lutego 2012

net-snmp

Dzisiejsze odkrycie dnia - snmp pod linuxem (a przynajmniej net-snmp) ma cache. Jakoś wcześniej nie spotkałem się z tym, sprzęt sieciowy tak nie ma. Robi to niezły bałagan, jeżeli na interface-ie mamy trochę ruchu i odczytujemy dostatecznie często dane. Dostatecznie często czyli np. co minutę, bo cache jest domyślnie ustawiony na 30sec. Tak to sprawdzamy, ile jest ustawione:
host ~ # snmpwalk -v2c -c public 10.0.0.1  1.3.6.1.4.1.8072.1.5.3.1.2.1.3.6.1.2.1.2.2
NET-SNMP-AGENT-MIB::nsCacheTimeout.1.3.6.1.2.1.2.2 = INTEGER: 30
A tak, zmieniamy to na sekundowe odświeżanie.
host ~ # snmpset -c public -v2c 10.0.0.1 1.3.6.1.4.1.8072.1.5.3.1.2.1.3.6.1.2.1.2.2 i 1
NET-SNMP-AGENT-MIB::nsCacheTimeout.1.3.6.1.2.1.2.2 = INTEGER: 1
I wykresy są znowu ładne.