palacsint weblapja

Céges gépen:

• Thunderbird Portable feltelepítve titkosított lemezre (TrueCrypt)

Thunderbird-ben, céges gépen:

• Szerkesztés / Postafiók beállításai / Kiszolgáló beállításai /
  • Üzenetek megtartása a kiszolgálón: bepipálva
  • Legfeljebb X napig: nincs bepipálva
  • Letörlésükig: nincs bepipálva
• Szerkesztés / Postafiók beállításai / Kiszolgáló beállításai / Másolatok és mappák /
  • Rejtett másolatot kap (Bcc): Saját cím beírva

Otthoni gépen, szintén Thunderbird-ben:

• Szerkesztés / Postafiók beállításai / Kiszolgáló beállításai
  • Üzenetek megtartása a kiszolgálón: bepipálva
  • Legfeljebb 5 napig: bepipálva
  • Letörlésükig: nincs bepipálva

Így a leveleket csak az otthoni Thunderbird törli a szerverről, valamint az öt nap miatt a hosszú hétvégéken érkező levelek is meglesznek a céges gépen arra az esetre, ha esetleg kellene valami régebbi dolog munkaidőben.

A céges gépről küldött levelek pedig az otthoni postafiókba is megérkeznek, csak át kell őket pakolni az Elküldött elemek mappába. Túl sokat nem írok, úgyhogy ezt általában kézzel csinálom, bár biztos lehet rá automatikus szabályt is létrehozni.

Az, hogy túl zöld. Mondhatni sötétzöld. De ne legyünk ilyen durvák, nézzük a tényeket, spekulációkat.

Az SPCR fórumára bevágott WD Support által írt levelek és SMART adatok szerint a WD GP winyók 8 másodperc inaktivitás után parkolják a fejet. A másfél éve létező SCPR fórum után az elmúlt egy évben valamikor felkerült a hivatalos Western Digital tudástárba is egy bejegyzés a problémáról (The S.M.A.R.T Attribute 193 Load/Unload counter keeps increasing on a SATA 2 hard drive).

A funkció előnye, hogy kevesebb áramot fogyaszt a merevlemez, ellenben növekszik a SMART Load_Cycle_Count (LCC) számláló értéke. A winyó adatlapja szerint ezekből a parkolásokból legalább 300 ezret ki kellene bírnia. Ha azonban pechesek vagyunk, és mondjuk pont 10 másodpercenként nyúlunk a lemezhez (vagy megteszi egy programunk 10 másodpercenként), akkor ezt a 300 ezres számot viszonylag hamar elérhetjük (kb. 35 nap folyamatos üzem esetén).

Persze ez nem jelenti azt, hogy a 300 001-edik parkolás már biztosan nem fog sikerülni, és utána a winyón tárolt adatok sosem lesznek elérhetőek, de akkor is idegesítő. Főleg, ha a parkolás hangját is halljuk. A fentebb említett fórumon egyébként van néhány felhasználó, akiknek több milliónál jár ez a számláló és a winyó hibátlanul működik.

De nézzük, hogy miért nem túl fair a helyzet:

• A winyó adatlapján, weblapján, és általában úgy sehol sincs feltüntetve, hogy rendelkezik ezzel a funkcióval. A felhasználók egy része nem azért vett WD GP winyót, mert annyira zöld, hanem mert csak 5400-at fordul percenként, ami jóval csendesebb működést és kevesebb hőt eredményez, mint a szokásos 7200-as változatok. Tényleg érdekel valakit az a pár Watt? Tegyük hozzá, hogy a parkolás sem teljesen zajtalan művelet.
• A Raid Edition 2-es Green Power winyókhoz a gyártó kiadott egy firmware frissítést és egy programot, amivel ezt a funkciót testre lehet szabni (beállítható a timeout értéke), illetve teljesen ki is kapcsolható a parkolás. Ez a nem RE2-es változathoz nem készült el. Miért?
• Egyeseknek egy nem támogatott wdidle3.exe nevű program segítéségével sikerült kikapcsolni a funkciót. Másoknál ugyanez nem működik. Viszont valószínűleg ugrik a garancia, ha ezt használjuk.
• A fentebb linkelt tudástári bejegyzés szerint Linux alatt kikapcsolható a hdparm -B 255 paranccsal a funkció. Nálam HDIO_DRIVE_CMD failed: Input/output error hibával leáll a hdparm, és tovább nő az LCC értéke. Támogatás nincs, mert a WD nem támogatja a merevlemezeit Linux/Unix alatt.

Saját tapasztalat: Egy éves WD10EADS, 70 ezer körüli Load_Cycle_Count érték, tökéletes működés.

---

Frissítés, 2011. augusztus 12.:

A témáról a Prohardver is cikkezett nemrég. Ők is a WD egyik support oldalára hivatkoznak (Answer ID 5357), ami szerint lehet használni a wdidle3.exe-t Caviar Green lemezekkel. Pontosan idézve a support oldalt: „Set Idle3 to max time (effectively turns off load/unload power saving feature thus will use more power) per below link.”

A „below link”-et követve eljutunk az RE2GP Idle Mode Update Utility oldalára, ahonnan letölthető a wdidle3.exe egy figyelmeztetés mellett, mely szerint csak a WD1000FYPS-01ZKB0, WD7500AYPS-01ZKB0, WD7501AYPS-01ZKB0 modellekkel használható. Nem Raid Edition Green Power merevlemez nincs a listában. Az első lapon (Answer ID 5357) viszont Raid Edition merevlemez egyáltalán nincs említve.

Az anomáliáról kérdeztem a hivatalos supportot is, szerintük nem támogatott a WD10EADS, és a többi nem Raid Edition lemezek használata wdidle3.exe-vel: „Unfortunately this software was made for a specific model of internal drives and the Caviar Green GP drive is not one of them. It was made for RE3 drives.” (Igen, RE3-at írtak a levélben.) A support oldalt persze azóta sem tették egyértelművé, hiába kértem.

További adalék, hogy az eredeti, NGOHQ-n megjelent cikket a Western Digital PR is kommentálta, de a kommentben nyoma sincs tiltakozásnak, hogy a wdidle3.exe használata Caviar Green lemezekkel nem támogatott.

Ezek után nem könnyű eldönteni, hogy merjük-e a használni a wdidle3.exe-t, esetlegesen kockáztatva a garanciát, vagy inkább hagyjuk szépen növekedni az LCC-t.

Lentebb egy biztonsági mentést készítő szkript Sony PRS-650-hez. Amit tud: automatikus mount/umount, könyvtárlétrehozás dátum alapján, md5sum az elkészült mentésről, a database/media/audio/ alatti tartalmak kihagyása.

#!/bin/bash

### Sony PRS-650 backup script by palacsint, 2011. 07. 14.
### http://palacsint.hu/

INPUT_DIR=/mnt/prs650_internal
BACKUP_BASE_DIR=/backup/sony-prs-650


mkdir --parents $BACKUP_BASE_DIR || exit -1

BACKUP_DIR=$BACKUP_BASE_DIR/sony-prs-650-$(date +%Y-%m-%d)
echo "Backup directory: $BACKUP_DIR"
if [ -d $BACKUP_DIR ]; then
    echo "Backup directory already exists, skip backup"
    exit -1
fi

echo "Free space on backup drive: $(df -h $BACKUP_BASE_DIR | tail -1 | awk '{print $4}')"

MOUNTED=false
if mountpoint -q $INPUT_DIR; then
    echo "Input directory $INPUT_DIR already mounted"
    MOUNTED=true
else
    mount $INPUT_DIR || exit -1
fi


mkdir --parents $BACKUP_DIR || exit -1

rsync --whole-file --recursive --filter='exclude, database/media/audio/**' $INPUT_DIR/ $BACKUP_DIR

find $INPUT_DIR | sed "s:$INPUT_DIR::" | sed 's:/::' > $BACKUP_DIR/file-list

cfv -q -C -t md5 -rr -p $BACKUP_DIR || exit -1

echo "Backup size: $(du -sh $BACKUP_DIR | awk '{print $1}')"

if [ "x$MOUNTED" = "xfalse" ]; then
    umount $INPUT_DIR
    sync
fi
echo "Backup OK"

Adott a következő könyvtár, amely napi mentéseket tartalmaz negyedévenként külön szülőkönyvtárban:

...
backup-2011q1/backup-2011-03-31
backup-2011q1/backup-2011-04-01
backup-2011q2/backup-2011-04-02
...

Az egyes napi mentések nem túl nagyok, de azért jó lenne egy idő után hatékonyan tömöríteni őket. Tart és gzipet vagy bzip2-t használva nem nyerünk sokat, a jelen esetben néhány száz megás, minimálisan eltérő napi mentések tömörített mérete csak 10-20 százalékkal kisebb, mint a könyvtárak tömörítetlen mérete.

A tar fájl a benne lévő fájlokat elérési útjuk szerinti ábécé sorrendben tárolja. Így a mindegyik napi mentésben előforduló azonos fájlok egymástól távol kerülnek a tar fájlban. A távolság miatt a gzip/bzip2 nem ismeri fel az ismétlődő mintákat, ezért nem tömörít hatékonyan. (Aki otthon van a témában, nyugodtan javítson ki, pontosítson kommentben.)

Gyors megoldás, ha gzip/bzip2 helyett 7-Zip-et használunk. Sajnos a gzip/bzip2 párost semmilyen paraméterrel nem sikerült rávennem, hogy maguktól felismerjék ezeket az ismétlődéseket, de a tar tartalmának megfelelő sorrendezésével segíthetünk a dolgon.

Erre két javasolt megoldás a credentiality blogon található. Az MD5 hash alapján történő sorrendezés megtalálható az előbbi linken, a fájlnév alapú sorrendezésre pedig egy példamegoldás a következő:

$ cat ~/bin/tar2 
#!/bin/bash
export GZIP=-9
find "$1" -type f | awk '{split($0, pathElements, "/"); print pathElements[length(pathElements)] "\t" $0 }' | sort | cut -f 2- | tar czvf "$1.tar.gz" -T -

Sajnos a tar tartalmának megfelelő sorrendezése nem segít az ismétlődő, de túl nagy fájlok tömörítésén, ezen ismétlődéseket a gzip/bzip2 továbbra sem fogja felismerni. A 7-Zip használata erre is megoldást jelent.

A PDF toolkittel – vagy röviden csak pdftk-val – egyszerűen módosíthatóak a pdf fájlok metaadatai. A telepítés Debian alatt csak egy apt-get install pdftk, de van Windowsos bináris is, bár azt nem próbáltam.

A metaadatok közül a Sony PRS-650 esetében a szerző és a cím a legérdekesebb. A dátum szerinti sorrendezésnél a felmásolás dátuma számít, nem a pdf fájlban lévő időpont.

Metaadatok lekérdezése:

$ pdftk original.pdf dump_data > pdf.data

Az így létrejött pdf.data fájl tartalma valami ilyesmi:

InfoKey: Creator
InfoValue: Writer
InfoKey: Title
InfoValue: árvíztűrő tükörfúrógép - ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP
InfoKey: Producer
InfoValue: OpenOffice.org 3.2
InfoKey: Author
InfoValue: palacsint
InfoKey: CreationDate
InfoValue: D:20110727211139+02'00'
PdfID0: d52f66ef5c592704640f4c44af42383
PdfID1: d52f66ef5c592704640f4c44af42383
NumberOfPages: 1

A címet az „InfoKey: Title” utáni sorban lévő InfoValue után kell megadni, a szerzőt pedig az „InfoKey: Author” utáni sorban. A cím jelen esetben az „árvíztűrő tükörfúrógép - ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP” szöveg. Értelemszerűen az ékezetes karaktereket a fenti formában kell megadni.

Végül a pdf.data módosítása után a metaadatok visszatöltése egy új fájlba:

$ pdftk original.pdf update_info pdf.data output metafix.pdf

Frissítés (2013. április 12.): Valamivel újabb Debianban már az escape-elés sem szükséges, UTF-8 karaktereket minden gond nélkül lehet használni a pdf.data fájlban.

# cat /etc/udev/rules.d/92-sony-prs-650.rules 
# Sony PRS-650 internal memory
SUBSYSTEMS=="scsi", ATTRS{model}=="PRS-650         ", SYMLINK="prs650_internal", GROUP="prs650"

# Sony PRS-650 Launcher
ATTRS{model}=="PRS-650 Launcher*", SYMLINK="prs650_launcher", GROUP="prs650"

# Sony PRS-650 SD
ATTRS{model}=="PRS-650 SD      ", SYMLINK+="prs650_sd", GROUP="prs650"

# tail -3 /etc/fstab 
/dev/prs650_internal 	/mnt/prs650_internal		vfat	user,noexec,gid=1000,uid=1000,fmask=0117,dmask=0007,iocharset=utf8
/dev/prs650_launcher 	/mnt/prs650_launcher		vfat	ro,user,noexec,gid=1000,uid=1000,fmask=0117,dmask=0007,iocharset=utf8
/dev/prs650_sd 		/mnt/prs650_sd			vfat	user,noexec,gid=1000,uid=1000,fmask=0117,dmask=0007,iocharset=utf8

A gyors lecsatoláshoz pedig:

$ cat ~/.bash_profile |grep sony
alias sonyu='if [ $(pwd | grep "^/mnt/prs650_" | wc -l) -gt 0 ]; then cd /mnt; fi; umount /mnt/prs650_sd /mnt/prs650_internal /mnt/prs650_launcher'

Úgy kb. ezek a csomagok kellenek hozzá:

sudo apt-get install python2.6 python-dbus python-imaging python-lxml \
python-mechanize python-beautifulsoup python-pkg-resources python-pypdf \
python-cssutils python-encutils python-cherrypy3 python-dateutil \
python-django-tagging python-qt4 xdg-utils imagemagick ttf-liberation \
python-routes libpoppler-qt4-dev libmagickwand3 libmagickwand-dev \
python2.6-dev libchm-dev libpodofo-dev libpodofo-utils python-sip-dev \
python-qt4-dev libpoppler-qt4-dev python-pythonmagick

(Calibre 0.7.32)

A múltkori hacktivitys bejegyzésben előkerült a National Software Reference Library (NSRL) Project. Most megnéztem kicsit közelebbről a letölthető hashadatbázist.

Az összesen négy, egyenként 360 megabájtos CD képfájl egy-két txt mellett tartalmaz egy-egy, majdnem ugyanekkora zipet. A zipekben vannak az ellenőrzőösszegek, amelyek egyenként 1,7 gigabájtos fájlmérettel büszkélkedhetnek. Így összesen 7 gigabájtnyi hasht kapunk.

Pontos adatmennyiség (idézet a read_me.txt-ből):

CD "A"    14,526,967 files,  4,373,310  unique SHA-1 values
CD "B"    14,577,858 files,  4,371,962  unique SHA-1 values
CD "C"    14,511,572 files,  4,375,127  unique SHA-1 values
CD "D"    14,656,439 files,  4,369,231  unique SHA-1 values
          -------------------------------------------------
  TOTAL   58,272,836 files, 17,489,630  unique SHA-1 values

A hashfájlok tartalma valami ilyesmi:

"SHA-1","MD5","CRC32","FileName","FileSize","ProductCode","OpSystemCode","SpecialCode"
"000000206738748EDD92C4E3D2E823896700F849","392126E756571EBF112CB1C1CDEDF926","EBD105A0","I05002T2.PFB",98865,3095,"WIN",""
"0000004DA6391F7F5D2F7FCCF36CEBDA60C6EA02","0E53C14A3E48D94FF596A2824307B492","AA6A7B16","00br2026.gif",2226,228,"WIN",""
"000000A9E47BD385A0A3685AA12C2DB6FD727A20","176308F27DD52890F013A3FD80F92E51","D749B562","femvo523.wav",42748,4887,"MacOSX",""
"00000142988AFA836117B1B572FAE4713F200567","9B3702B0E788C6D62996392FE3C9786A","05E566DF","J0180794.JPG",32768,16848,"358",""
"00000142988AFA836117B1B572FAE4713F200567","9B3702B0E788C6D62996392FE3C9786A","05E566DF","J0180794.JPG",32768,18266,"358",""
"00000142988AFA836117B1B572FAE4713F200567","9B3702B0E788C6D62996392FE3C9786A","05E566DF","J0180794.JPG",32768,2322,"WIN",""
"00000142988AFA836117B1B572FAE4713F200567","9B3702B0E788C6D62996392FE3C9786A","05E566DF","J0180794.JPG",32768,2575,"WIN",""

A fenti mintánál is látszik, hogy egy hash többször is szerepel különböző OpSystemCode, ProductCode vagy SpecialCode mezővel. Ezek feloldását a cédén mellékelt NSLROS.txt és NSLRProd.txt fájlok tartalmazzák. A 358-as azonosítójú operációs rendszer például a rejtélyes TBD névre hallgat.

Az utolsó négy sor ProductCode értékei (16848, 18266, 2322, 2575) a következőket fedik:

"ProductCode","ProductName","ProductVersion","OpSystemCode","MfgCode","Language","ApplicationType"
...
16848,"Microsoft Office XP Small Business","Version 2002","189","609","English","Operating System"
18266,"Microsoft Office XP","2002","190","609","Dutch","Office Suite"
18266,"Microsoft Office XP","2002","204","609","Dutch","Office Suite"
18266,"Microsoft Office XP","2002","224","609","Dutch","Office Suite"
18266,"Microsoft Office XP","2002","264","609","Dutch","Office Suite"
2322,"Office XP","Standard2002 NL","WIN","Microsoft","Dutch","Suite"
2575,"Publisher Deluxe with Photo Editing","2002","WIN","Microsoft","English","Publishing"
2575,"Publisher Deluxe with Photo Editing","2002","WIN2000","Microsoft","English","Publishing"
2575,"Publisher Deluxe with Photo Editing","2002","WIN98","Microsoft","English","Publishing"
2575,"Publisher Deluxe with Photo Editing","2002","WINME","Microsoft","English","Publishing"
2575,"Publisher Deluxe with Photo Editing","2002","WINNT","Microsoft","English","Publishing"
2575,"Publisher Deluxe with Photo Editing","2002","WINXP","Microsoft","English","Publishing"

A teljes hashadatbázis 58 millió sorából 1,4 millióban szerepel a Linux szó, szóval nem csak windowsos fájlokról van szó. Ezen kívül van még itt Solaris, MacOS, mindenféle DOS-ok, OpenVMS, Palm OS stb. Az NSRLProd.txt majdnem 26 ezer sora 8500 különböző nevű terméket tartalmaz.

A teszteléshez első körben egy pár hónapos (XpHun#1) és egy valamivel régebben frissített magyar Windows XP mentést használtam (XpHun#2). Aztán szereztem egy md5 fájlt egy magyar Vista, valamint egy SP3-as angol XP (XpEng) C:\Windows könyvtárának tartalmáról is. Végül egy Debian Lenny-t is megnéztem (/bin, /sbin, /usr, /var).

Eredmények a következő táblázatban:

Az ugyanolyan hash értékkel rendelkező fájlok csak egyszer szerepelnek az összegekben.

A legjobb eredmények is éppen csak 50 százalék felettiek. Az angol XP magas találati arányának oka lehet, hogy régen volt frissítve (csak a két és fél éve kiadott SP3-at tartalmazta), másrészt talán az angol Windows fájljai nagyobb eséllyel kerülhetnek be a NSRL adatbázisába, mint a magyarok.

Látszik az eredményekből, hogy nem mindenható eszközről van szó (legalábbis jelenlegi állapotában semmiképp sem), a felismert fájlok eltávolítása után még bőven marad átnéznivaló, ha alaposak akarunk lenni. Ettől függetlenül mindenképp segítséget jelent, az a néhány ezer-tízezer megtalált fájl sem elhanyagolható könnyebbség egy ilyen feladatnál.

(Technikai részletek: 2010/06/01 - RDS Version 2.29)

Érdemes a wipe kézikönyvét átfutni. Pár érdekesebb gondolat az elejéről:

Ha a wipe futtatásakor nem a gyors módot választjuk, akkor 35-ször írja felül a fájlok tartalmát. Az első és utolsó négy kör véletlen adatokkal történik, a közbenső 27 pedig fix értékekkel. A módszer pontos leírását Peter Gutmann Secure Deletion of Data from Magnetic and Solid-State Memory című cikke tartalmazza.

Ez a 35 felülírás általában eltart egy ideig. Mondjuk 100 megabájt / szekundumos írási sebességgel és 100 gigabájtos lemezzel számolva egy kör 1000 másodperc. 35 kör 35 ezer másodperc. Ami úgy tíz óra. Ha egy terabájtos lemezről van szó, akkor már 100 óra. Egyszerűbb titkosítani az egészet, úgy csak a kulcsot kell biztonságosan törölni.

Ha megelégszünk kevesebb körrel is, akkor a -Q paraméter mellé ne felejtsük el megadni a -q kapcsolót, mert nélküle a -Q semmit sem ér.

Alább egy rövid leírás a Midnight Commanderben az Eszközök menüpont Menüfájl szerkesztése menüpontjával elérhető menüfájl szintaxisáról, amely menüt az F2 gombbal lehet előcsalogatni.

A leírás az mc kézikönyvére épül, amiből érdemes átfutni a Menu File Edit, illetve Menü szerkesztés című fejezetet.

A menüfájlban a sor első betűje lesz a gyorsbillentyű az adott menüponthoz. Utána az mc-vel szállított alapértelmezett fájlban egy tabulátor karakter következik, majd a menü neve. Nem feltétlenül muszáj ezt a szokást követni, a tabulátor karakter kimaradhat, de így valamivel kulturáltabban néz ki.

Az ezután következő, kötelezően szóközzel vagy tabulátorral kezdődő sorok lesznek a menü kiválasztásakor végrehajtandó parancsok. Ezeket az mc futtatás előtt kimásolja egy ideiglenes fájlba, amit a/tmp mappában helyez el és ott shell szkriptként futtat. Így használhatóak a szokásos shell szkript funkciók.

Ezeken kívül további lehetőség a szkriptekben a %f, %F, %d, %D, %t, %T helyettesítő karakterek használata. A %f az aktuálisan kiválasztott fájl nevét, a %d az aktuális könyvtár nevét, a %t az összes kijelölt (tagged) fájl nevét fogja tartalmazni. A nagybetűs változatuk a másik panelre vonatkozik. Még ezen kívül van néhány, érdemes megnézni az mc dokumentációját (Macro Substitution, illetve Makro helyettesítő).

A menüpontok nevei előtt meg lehet adni további feltételeket, amelyek eldöntik, hogy a menüpont megjelenhet-e a menüben, illetve alapértelmezett legyen-e. Ha nincsenek ilyen feltételek, akkor a menüpont mindig megjelenik.

A megjelenési feltételeket plusz jellel (+), az alapértelmezetté tételhez szükséges feltételeket pedig egyenlőségjellel (=) kell kezdeni.

Ezekben a feltételekben az f, d és t karaktereket használhatjuk. Az f-fel a fájl nevére vonatkozó kényszereket lehet megadni, például:

= f *.tar.gz | f *.tgz

Itt a *.tar.gz és a *.tgz shell minta, a helyes működéshez a menüfájl első sorában a

shell_patterns=1

beállításnak kell szerepelnie. Ha ez az érték nulla, akkor reguláris kifejezéseket kell megadnunk, ami így néz ki:

= f \.tar\.gz$ | f \.tgz$

A d karakter ugyanez, csak könyvtárnevekre, a t pedig a fájl tulajdonságaira vonatozik (fájl-e, könyvtár-e, olvasható-e stb.).

Ha az aktuális elem könyvtár:

= t d

Ha vannak kijelölt fájlok a panelen:

= t t

A kétfajta feltételt össze is lehet vonni (+= vagy =+), ilyenkor egy sorban megadható a megjelenítéshez szükséges feltétel, ami egyben alapértelmezetté is teszi a menüpontot.

Hibakeresésre alkalmazható a +? és az =?, ilyenkor minden feltétel kiértékelése után az mc megjeleníti az eredményt egy ablakban.

Ha kiértékelt feltételek alapján több menüpont is aktuális lehetne, akkor (nálam) az elsőt választja az mc.

Mellékletek:

• Mignight Commander 4.7.4 magyar nyelvű kézikönyv
• Midnight Commander 4.7.4 angol nyelvű kézikönyv