log69 blogja

Néha találok egészen lenyűgöző és elegáns megoldásokat Ruby-ban. Az alábbi kivétel kezelés milyen már? :)

x = 1 / 0 rescue 42

Innét.

Nemrég csorgott be Scientific Linux 6-ra Firefox 17-es (17.0.3) verziója a 10.x ESR verzió helyett. Éljen. Több feature hiányzott már a 10-esből.

Bejelentés itt.

A lényeg: nvidia-detect csomag Enterprise Linux 5 és 6-hoz (ugyanígy CentOS és Scientific Linux 5.x és 6.x-hoz), hogy a felhasználók egyszerűen meg tudják állapítani, melyik nvidia kernel modul csomagot kell telepíteniük a rendszerre a videokártyájukhoz. Így nem feltétlen futnak bele abba, hogy a fent lévő és eddig működő csomagot frissítik, és az abból már Nvidia által nem támogatott hardver tulajoknak eltörik a rendszere.

"nvidia-detect was conceived after NVIDIA recently dropped support for older 6xx and 7xxx series cards from the current driver. Some users upgraded to the latest NVIDIA driver and found their older hardware was no longer supported by the latest driver release.

Egy ilyen telón a pár napos frissítés óta állandóan megzabálta az akksit a "Media" folyamat. Reboot, process letiltása stb. sem segített.

A gond - mint kiderült végül - az volt, hogy a külső SD kártyán a fájlrendszer megsérült, és a fájl nevek helyett random karakterek jelentek meg, és ezen izzadt a media indexelő szolgáltatás. Se a fájlok tartalma nem volt olvasható, sem törölni nem lehett őket.

Lényeg hogy az SD kártya formázása után megszűnt a hiba. Google segített a hiba felderítésében az alábbi kulcsszavakkal: "android.process.media battery". Konkrétan ez a fórum.

Neten találtam Ruby nyelven faktoriális megoldást a klasszikus rekurzív helyett (a rekurzívval túlcsordul a stack, meg gondolom sokkal lassabb):

(1..n).inject(:*)

Néha felmerül téma arról, hogy régebbi gépekre milyen Linux-ot tegyünk. SL 5 jó választás lehet, és mivel nem igazán ismerem meg úgyis most jelent meg RHEL 5.9, elkezdtem játszani vele kicsit. SL-ből gondolom max 2-3 hónap múlva itt lesz az 5.9.

Gnome desktop-ot telepítettem virtuális környezetbe KVM használatával. 10 GB-os image-et adtam neki, melyen 700 MB swap-ot csináltam 1800 MB fizikai memórához.

Az első 3 CD-re van szükség (tükrök itt), és telepítés közben kell cserélni (lehetséges KVM alatt). ext3-as fájlrendszert ajánl alapból, ezt használom.

Előzmény itt. Használja: EncFS, SSH, Rsync. Script itt.

Adatok visszaállítása (ha /src-ben vannak a lementett titkosított adatok és /dst egy üres mappa, akkor az alábbi parancs után ebben lesznek láthatók a kibontott adatok):

encfs /src /dst

Számomra nagyon fontos a programozási nyelv szintaktikája. Mostanában sokat nézegettem különböző nyelveket (Lisp, Scala, Lua - csak hogy párat említsek), és eddig nem találtam egyetlen olyat sem, amely Ruby közelébe érne _számomra_.

Hogy miért Ruby-ban programozok, azt ez a leírás pontosan leírja, mellyel teljesen egyetértek. Nyilván nem mindenhol és nem mindenkor lehet megtenni, hogy eszközt választunk egy feladathoz és nem fordítva, de személy szerint arra törekszek, hogy csak olyan dolgokkal foglalkozzak, ahol a számomra tetszetős eszközöket használhatom.

Vissza álltam a desktop rendszeremen SL 6x stabil-ra. Volt egy apró bug F17 alatt, ezért megléptem.

Egy komolyabb dolgott kellett megoldanom SL alatt, mely már sok hónapja fennállt, miszerint egy kernel frissítés óta az iwl3945 modul kernel pánikot okozott az intel wifimmel. Ez egyértelműen látszott is mindig a log-okból. Szereztem teljesen ugyanolyan wifi kártyát, de azzal is ugyanez van. Persze más rendszer alatt nem volt gond ezzel, de azért le akartam tesztelni. Tehát RHEL kernel bugról van szó (SL, RHEL és CentOS alatt is találtam hiba jelentéseket). Mivel sok időt elcsesztem rá és ez sokba kerül, ezért inkább beletettem egy Atheros káryát, ezzel jónak tűnik.

Előzmény.

2 hónapig használtam a notimon Btrfs fájlrendszert munkára. Semmi komolyabb gondom nem volt vele. Viszont most visszaállok Ext4-re az alábbi okok miatt:

- megmutatkozott, hogy a fő ajánlás és vonal Fedorán (Ext4) mennyivel jobban kitesztelt, mivel ha hiba lépett fel altatásból való visszatérésnél, akkor nagyrészt a Btrfs miatt volt (a GUI-s bugreport toolból látszott)
- csináltam auto snapshot script-et, de ezzel meg az a gond, hogy a hely mindig csak fogy, mert ugye amíg egy régebbi mentés miatt még mindig tárolódnak régi fájlokhoz blokkok, akkor addig nem szabadul fel a hely - a 120-as SSD-m meg kicsi ehhez, főként a VM-ek miatt (VM-eket nem snapshot-oltam, csak eleve kevés a helyem általában)
- a legutóbbi 3.6.9-es kernel néha nem boot-ol be, majdnem biztos vagyok benne, hogy köze van ehhez is a Btrfs-nek (nem közvetve, hanem a rendszer működése közben frissítésekbe és az initramfs generálásokba valahogy beleszólt szerintem)

Ruby pár sorosokról jegyzet.

5 karakteres véletlen szám ismétlés nélküli számjegyekkel:

[*0..9].shuffle.first(5).join

..ismétléssel:

a = ""; 5.times { a += rand(10).to_s }; a

Találtam egy jó (használható) SELinux leírást.

Előzmény.

Fedora 17-en - ellentétben Scientific Linux-al - nem működött alapból a Firefox sandbox-ban. Metacity ablak kezelővel kellett indítani (itt külön ablakon belül van az app, és kényelmetlenebb meg csúnyább, kézzel kell teljesre méretezni):

sandbox -W metacity -t sandbox_web_t -X firefox

Most vettem észre, hogy egy selinux frissítés óta megy rendben így is:

sandbox -t sandbox_web_t -X firefox

Így használom:

sandbox -i ~/.mozilla/plugins -t sandbox_web_t -w 1250x730 -X -- firefox

Ugye SL-hez képest egyetlen különbség van, hogy itt nem átméretezhető a sandbox ablak, mivel az az extra egy RedHat patch RHEL rendszerhez.

Előzmény (3. bekezdés).

Ha valaki szeretne swap fájlt használni Btrfs fájlrendszerrel (F17 alatt), akkor nehézségekbe ütközik, mivel Btrfs egy "copy on write" FS, ezért lyukak lennének a swap fájlban ha engedné, és mivel a swap alrendszer blokk szinten szeretne ugyanoda írni, az korrupttá tehetné az FS-t, mert lehet hogy közben a fájlt már máshova map-pelte.

A loopback device egy lehetőség, és SSD-n szerintem kutyát nem izgatja a swap performancia. Tehát egyetlen Btrfs partícióval az alábbit lehet tenni:

Előzmény.

Kicsit fejlesztettem a Btrfs fájlrendszeren automatikus snapshot mentést menedzselő script-emen. Lefuttatva létrehoz egy napi mentést + egy havit is ha az még nincs a /snapshot könyvtárba. Illetve törli a régebbieket is (7 legfrissebb napi és 3 legfrissebb havit tart meg).

Cron.daily-be tettem be alapból, így naponta 1x lefut.

Forráskód itt.

Előzmények itt.

Röviden: egy apró Ruby script, amely megmutatja a legerőforrásigényesebb folyamatokat összesítve név szerint, vagyis a gyermekfolyamataikat és másik azonos nevű folyamatokat egybe veszi, hogy ne PID, hanem program típus alapján legyen látható, hogy milyen típusú folyamatok használják a legtöbb erőforrást - mindezt CPU, memória és diszk használat alapján.

A mostani verziót kiegészítettem a folyamat indulása óta felhasznált teljes I/O használattal (ez egyben tartalmazza a storage réteg: diszk, hálózat, tty, standard és egyéb ki- és bemenetek forgalmának mértékét), illetve a végén ezen statisztikát alapján számolok egy súlyozott értéket, és nyomtatok egy top sorrendet a folyamatok neveivel. Sajnos a kutatásom alapján nem tudok kinyerni a Linux kernel /proc kimenetéből folyamatra vetített hálózati forgalom használatot a futás kezdete óta, ezért hálózati forgalom statisztika nincs.

Egyre jobban lakom be Gnome 3-at és nagyon tetszik, mind a témája, mind az integráltsága és nagyon kényelmes. Sandbox-ban futtatott Pidgin-nel szívattam magamat, amikor is felfedeztem, hogy a táclába épülő Telepathy kliens be van védve saját SELinux szabállyal, és gyári modul van hozzá:

# semodule -l | grep -i tele
telepathy       1.0.1   

Ubuntu-n és openSUSE-n mennyire vannak AppArmor szabályok ráhúzva a futó vagy telepíthető szolgáltatásokra és programokra? Kíváncsi lennék. Érdekesség képpen a Fedora 17-en alapból betöltött SELinux modulokról itt egy lista.

su
yum install livecd-tools spin-kickstarts

livecd-creator --config=myconfig.ks --fslabel=fedora_live

...ahol myconfig.ks a saját kickstart fájl az extra csomagokkal. Ez már így friss Fedora live lesz up-to-date csomagokkal (56 perc alatt összerakta és 960 MB lett a 64 bites verzió).

Kiegészítés:
Ha valaki nem Gnome alapú spin-t akar összedobni, hanem egy minimál base-t vagy KDE vagy XFCE, akkor a /usr/share/spin-kickstarts/ mappában vannak a template kickstart fájlok.

ls /usr/share/spin-kickstarts/
fedora-aos.ks
fedora-install-fedora.ks
fedora-live-base.ks
fedora-livecd-design-suite.ks
fedora-livecd-desktop.ks
fedora-livecd-kde.ks
fedora-livecd-lxde.ks
fedora-livecd-meego.ks
fedora-livecd-security.ks
fedora-livecd-soas.ks
fedora-livecd-xfce.ks
fedora-live-desktop.ks
fedora-livedvd-electronic-lab.ks
fedora-livedvd-games.ks
fedora-livedvd-robotics.ks
fedora-livedvd-scientific-kde.ks
fedora-live-kde-base.ks
fedora-live-kde.ks
fedora-live-mini.ks
fedora-live-minimization.ks

Előzmény. Cseréltem asztali rendszerem alatt az Ext4 fájlrendszert Btrfs-re az SSD-men.

Futtattam bonnie++ tesztet. Ext4 eredmény, Btrfs eredmény. Fedora 17 x64, stock kernel 3.5.3, minden szoftver és hardver ugyanaz volt a tesztek alatt.

Megj.: Btrfs compress és ssd opciókkal van felcsatolva, tehát használok tömörítést. Illetve mindkét fájl rendszerre relatíve újonnan toltam fel az adataimat rsync-kel. Egy nem mérvadó érdekesség, hogy 8%-ot nyomott össze az összes adatomon.

Tegnapelőtt 8-án jelentette be a levlistán Connie Sieh SL 6.3 elérhetőségét.

Letöltés:
http://ftp.scientificlinux.org/linux/scientific/6.3/
http://ftp.scientificlinux.org/linux/scientific/6.3/x86_64/iso/

TUV kiadási megjegyzések itt találhatók. Innét néhány érdekesség:

"rdrand kernel support: The Intel Core i5 and i7 processors (formerly code-named Ivy Bridge) support a new rdrand instruction to quickly generate random numbers. The kernel shipped in Red Hat Enterprise Linux 6.3 utilizes this instruction to provide quick random number generation. "

Keresgettem ruby-hoz editort / IDE-t. A címben lévő progit találtam legmegfelelőbbnek számomra. Tervezem megvenni Sublime Text editort (jelenleg $59), van ezzel kapcsolatban tapasztalatotok? Érdekelne olyanok véleménye akik használják.

Első próbálgatások után (ruby kóddal teszteltem):
- jó a szintaxis kiemelés, meg hogy sok szín téma közül lehet választani (sötét vagy világos)
- nagyon gyors a felület
- a kód térkép nekem nagyon hasznos, ezzel is gyors a görgetés és segít az átláthatóságban
- nagyon jók a beállítások és jól testre szabható
- szuper a kód és szöveg kiegészítése
- szuper a keresés is, meg hogy a szövegdoboz alul van egy csíkban és így nem zavaró

Tervezem átolvasni a "distributed proxy" kulcsszavakra adott G találatokat is, de előbb levetem ide néhány gondolatom - kíváncsi lennék a véleményetekre.

Érdemes lenne-e vajon lefejleszteni egy olyan önszerveződő webproxy-t, mint a torrent továbbfejlesztése, ahol az egymáshoz közeli node-ok információt cserélnek egymással - így azt eredményezve, hogy a hasonló információ mindig megérkezhet a lehető legközelebbi kliensről? Persze teljesen automatikusan, amely nem igényelne semmilyen manuális tuningolást, hanem mondjuk magát állítgatná.

Ha lenne egy olyan daemon, amelynek kijelölhetnénk egy maximális erőforrást a kliensen (cpu / mem / disk), és azok a kliensekről infót cserélnének egymással, és ha olyan infót kér az egyik, ami a másikon már ott figyel, akkor onnét kapná meg. Ha több kliensen figyelne a keresett weboldal egy része, akkor lehetne valami okosabb megoldással szelektálni, hogy az adat mely része melyik kliensről érkezne. Illetve a https kapcsolatokból összegyűjtött cache adatok helyi megosztásán is érdemes lenne elgondolkozni, mert annál végképp nem játszhat közre ugye semmilyen köztes proxy.

Kísérletezek tovább a RedHat 6 új Sandbox feature-jével. (Előzmények 1 és 2.)

Hasznosnak tartom, ha lóg valahol egy olyan parancsikonom, amivel sandbox-ba zárt böngészőt tudok indítani. SL 6-ra 1-2 klikkel felmegy a Chrome stable. Ezt viszont nem tudom egyelőre bezárni, mert variál a PID-ekkel, és ezt nem engedi a SELinux. Majd meg akarom nézni, mennyire macerás extra saját policy típust csinálni ehhez. (Ilyenkor átirányítom a kimenetet egy fájlba és egy sleep 300-at odateszek a parancs mögé, így a /tmp/.sandbox_home* mappában meg tudom keresni a fájlt - mert a sandbox bezárásával törlődnének a temp dir-ek.)

Sokszor kell locking megoldás script-ekbe, hogy nehogy párhuzamosan elinduljon ugyanaz a script, például ha cron-ból futtatom.

Találtam egy 1 soros megoldást, tetszik. A Linux-only flock megoldást használja (util-linux-ng csomagból). Kis magyarázat: itt a trükk az, hogy a script saját magát használja lock fájlnak. Íme:

#!/bin/sh

exec 200<"$0" ; flock -n 200 || exit 1 # locking

# do some stuff here
# ...

Szerk.: illetve itt említik a mkdir-es megoldást is:

if mkdir /var/lock/mylock; then
  echo "Locking succeeded" >&2
else
  echo "Lock failed - exit" >&2
  exit 1
fi

Transmission-t úgy állítottam be, hogy a ~/Desktop mappából átveszi induláskor a *.torrent fájlokat, és a home-ba menti az eredményt. A böngészőm szinten ~/Desktop-ra menti a lementett fájlokat.

Az alábbi script-re klikkelve automatikusan elindul a Transmission egy sandbox-olt X-en belül, és csak a számára sandbox által automatikusan létrehozott mappákba lát bele (illetve más folyamatokhoz és erőforrásokhoz sem fér hozzá, amit külön nem engedünk), ezek:

/tmp/.sandbox_tmp_XXXXXX
/tmp/.sandbox_home_XXXXXX
/tmp/.sandbox-user-XXXXXX

A rendszer törli ezeket a mappákat ha bezárjuk az alkalmazást. A sandbox indítás után várok, amíg létrejön a mappája, majd kirakok az asztalomra erről egy parancsikont, mivel nem sandbox-olt alkalmazások normál módon írhatják és olvashatják a mappa tartalmát.
[code]
#!/bin/sh
sandbox -i ~/.config/transmission -i ~/Desktop/*.torrent \
-t sandbox_net_t -w 600x600 -X transmission-gtk &>/dev/null &