log69 blogja

SL (RedHat / CentOS) 6.x Sandbox

Végre volt időm átnézni RedHat 6-os Sandbox feature-jét, amely a release notes-ukban is olvasható (8.2.2. bekezdés):
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.0_R…

Magyarázat a Sandbox-hoz:
http://www.misdivision.com/blog/rhel-6-sandbox

Ez egy olyan SELinux policy, amellyel könnyedén bezárhatunk alkalmazásokat egy csökkentett jogosultsággal rendelkező környezetbe, ahol alapesetben nincs joguk más folyamatokhoz és fájlokhoz hozzáférni. Ez a -X kapcsolóval grafikus alkalmazásokhoz is egyszerű lehetőség. A -t kapcsolóval megadható más policy, pl. hogy hozzáférhessen net-hez is.

SL 6.2

Nézegetem Scientific Linux-ot. Ahogy látom, tegnapi a 6.2-es ISO-k dátuma. Még nem találok release notes-ot hozzá.
http://ftp.scientificlinux.org/linux/scientific/6.2/x86_64/iso/

Lennétek olyan kedvesek írni véleményt SL-ről CentOS-hez, ill. más disztrókhoz képest? Mi a tapasztalatotok ezzel a rendszerrel?

Pl. zárt wifi és egyéb firmware-ekkel hogy áll? Meg úgy általában? RedHat-hez képest a biztonsági javításokat milyen gyorsan veszik át? Vagy ezt automatizálják, és program mindig legyártja a RH forrásból a cuccokat?

Ill. készítenek híbrid ISO image-eket SL-hez? Vagy csak azt? Meg ha saját Live CD-s összeállítást akarok csinálni, ahhoz van támogatás? Illetve külső repokkal is lehet saját Live rendszert összerakni?

Ruby + sysstat #2

Előzmények itt.

Most eltávolítottam az uptime és pidstat parancs (sysstat csomag) függőséget is a kódból, így ha nincs acpi és pydf sem, a fontosabb infót akkor is meg tudja jeleníteni. E két utóbbi csak opcionális függőség. Kb. 20 %-al gyorsabb is lett így a kód (0.1 sec alatt fut).

Tesztelve Ruby 1.8.5 - 1.9.3 verziók között. Forráskód itt, letöltés itt.

Ha lenne valakinek kedve, le tudnátok tesztelni friss (>3.0.x) kernel alatt? Illetve régi 2.6.18-as (pl. Debian Etch vagy CentOS 5 talán?) kernellel? Ugye a /proc-ban turkálok, és ezért érdekes a kernel verzió.

Ruby + pwgen

Sok fajta véletlen jelszó generátor progi létezhet, én általában pwgen parancsot használom Linux alatt. Ugye ez ún. kiejthető jelszavakat is létre tud hozni. Valóban könnyebben megjegyezhető. Mindenhová véletlen jelszót generálok, nem csak magamnak hanem másoknak is, ezért sűrűn használom.

Mindössze annyi volt a gondom vele, hogy bizonyos karaktereket nem akarok hogy megjelenjenek a jelszóban. Olyanokra gondolok, amelyek leírva vagy nyomtatva, betűtípustól függően összekeverhetők. Ilyen a kicsi "i" betű, kicsi "L" betű és nagy "L" betű, "O" betű és nulla stb. Illetve a különböző (pl. qwertz és qwerty) billentyűzet kiosztás miatt olyan jelszavakat akartam, amelyek mindenfajta bemeneten működnek.

Ruby + SDL

Nézegettem Ruby SDL lib-jét. Találtam egy egyszerű init példát itt. SDL doksi pedig itt.

Biztos ismeritek, mikor véletlen módon elhelyezett pontok kergetik egymást. :)

Ruby script itt. Hozzávalók:

sudo apt-get install ruby libsdl-ruby

Ruby + sysstat

Előző blogomban valamelyest fejtegettem mi nem tetszik a Python 3-ban, és a Ruby felé kacsingatok, meg valszeg ezt fogom saját cuccokhoz használni.

Összekapartam ma egy olyan rendszer stat script-et, amelyre igényem volt már régóta, és így legalább kicsit át is tudtam nézni a nyelvet. Főként az kellett, hogy az azonos nevű folyamatokat egyben összesítve lássam. Tehát pl. a tíz db bash process memória fogyasztását és gép bekapcsolás óta eltelt összes CPU idejét egyben lássam szummázva.

Nem nagy cucc, de ha már megírtam, felteszem ide is, hátha valaki örül neki (vagy nem) :)

Python 3 >> Ruby

Sajnos azt kell mondjam, hogy nagyon nem tetszik a Python 3. Amennyire levette a terhet az ember válláról a 2-es és nem kellett "gondolkodni" a kódoláshoz, hanem produktív tudtam lenni, annyira nem a 3-as.

Eleve a print parancs. Nagyon kényelmes volt, majdnem ez miatt szerettem Python-t a leginkább. Mindegy mit printeltünk, kinyomta a tartalmát.

Ezen kívül bevezettek egy rakás olyan kulcsszót, amelyek kellenek a függvény hívásokhoz, ráadásul olyan alapértelmezésekkel, ami nem tetszik. Pl.:


out = subprocess.check_output(["acpi", "-V"], universal_newlines=True)
print (out)

df use értéke

$ df -k /
Filesystem            1K-blocks      Used Available Use% Mounted on
/dev/mapper/main-raid 961428808 855008128  96653116  90% /

$ pydf -k
Filesystem                 Size      Used    Avail Use%                                 Mounted on
/dev/mapper/main-raid 961428808 855008128 96653116 88.9 [##########################...] /

$ wcalc "855008128 / 961428808 * 100"
 = 88.931

Nem stimmel a df által mutatott "Use%" értéke. Vajon miért?

pydf

Weboldal | Szerző oldala | Most ezt és ezt az oldalát böngészgetem, az ilyennek tudok örülni..

Szerző oldaláról: "If you multiply the number of letters of my first name with that of my surname and substract the date when I was born (either day or month), you'll get : !!! 4 2 !!!" / "Esoteric stuff" - "Installing Debian on Sony Vaio P..." :)

tomld vs Tomoyo 2.4

Elkezdtem írni a fejlesztőnek egy I'd like to express my frustration about.. kezdetű levelet, aztán úgy döntöttem hogy inkább leblogolom ide azt annyi.

Olyan szintű strukturális változásokat eszközöltek Tomoyo 2.4-ben 2.3 és előttiekhez képest, hogy valószínűleg dobom a projektet.

A profile.conf fájlt major verziónként változtatták, immáron harmadszor. Minek? Semmi új paramétert nem hozott be az mellett, hogy nagyon szar a felépítése. Így néz ki most (comment sorokat kihagyva):


0-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 }
0-CONFIG={ mode=disabled grant_log=no reject_log=yes }
1-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 }
1-CONFIG={ mode=learning grant_log=no reject_log=yes }
2-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 }
2-CONFIG={ mode=permissive grant_log=no reject_log=yes }
3-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 }
3-CONFIG={ mode=enforcing grant_log=no reject_log=yes }

Debian + Tomoyo verzió gond

Debian-nál is az történik mint Ubuntu-nál, a kernel oldali Tomoyo verzió frissülésével nem frissítették a user space részt.

Bug report itt.

Remélem mielőbb javítják, pont tesztelni akartam a 2.4-es Tomoyo-t. Valószínűleg azt mutatja, hogy kicsi az érdeklődés az irányában - mondjuk a maintainer figyelhetné a gyári kernel verzió változásokat.

Get Flash video

Cél: weboldalról lementeni a beágyazott Flash videót (mivel bizonyos flash plugin verzió óta már nem érhető el az aktuálisan játszott flash tartalom a /tmp mappán belül).

Meg kell várni míg teljesen előtölti a videót a böngészőben a lejtászó, majd a script futtatása. Home-ba dobja véletlen névvel az .flv fájlokat vagy fájlt - ha van.

[code]
#!/bin/bash

ps aux | grep -v grep | grep -i "libflashplayer.so" \
| tr -s " " "\t" | cut -f2 | grep -oE "[0-9]+" | while read PID; do

ls /proc/"$PID"/fd | while read FILE; do

F1=/proc/"$PID"/fd/"$FILE"
F2=$(readlink -f "$F1")

tomld - csomagolás

Legutóbbi blog bejegyzésemben azzal kapcsolatban panaszkodtam, hogy nem értem miért nem találtam több hónap alatt egy mentort a csomag feltöltésemhez. lacos-nak hála, találtam egy fejlesztőt, aki fel fogja tölteni a csomagomat (ajánlotta daniel@-t hogy kérdezzem meg hátha alapon, és bejött).

Sőt, össze is írta Daniel a listát, hogy az elkészített csomagomban mit kell kijavítanom. Elég hosszú lett :)

Annyi mindössze a problémám, hogy azt sem tudom hogy álljak neki. A mostani csomagomat is úgy kísérleteztem ki a nem megfelelően dokumentált DH script-ek miatt. aaphoto csomagomnál speciel kereken 20 levelet váltottunk a mentorommal, mire elfogadta az első feltöltéshez.

tomld - mentors

Szerintetek miért nem tudom bejuttatni Debian-ba tomld csomagom (ugye kell egy hivatalos Debian fejlesztő, aki mentor-ként feltölti)? Most már több hónapja is van, hogy spammeltem az IRC csatornákat, levlistát, de semmi mozgás. Szeretnék több user-t teszteléshez.

Mi lehet a gond? Nagyon szar a cucc? Vagy érdektelen a téma? Vagy nincs annyi kapacitása a fejlesztőknek, hogy átnézzék és feltolják experimentalba? Nem lenne sok dolguk. Másik progimat pl. gyorsan betolták szó nélkül (sajnos az a mentor-om nem vállalta ezt, de nem írta hogy miért, bár pozitív dolgot írt vissza).

tomld - domain deny lekelezése

Tomoyo-nak két fajta megtagadás bejegyzése van.

1) Access deny: Ez egy létező, már kikényszerítő módban lévő domain hiányzó szabályának jelzéséhez van. Ha pl. a chromium létre akar hozni egy mappát egy olyan helyen, ahová nincs jogosultsága, akkor az alábbi bejegyzés jön létre a syslog-ban:

TOMOYO-ERROR: Access 'mkdir /home/user/anything/' denied for /usr/lib/chromium-browser/chromium-browser

1) Domain deny: Ez egy létező, már kikényszerítő módban lévő domain hiányzó aldomainjének jelzéséhez van. Ha pl. a chromium futtatni akarja egy allow_execute szabályában lévő binárisát, de nincs hozzá aldomain, akkor hasonló üzenetet kapunk syslog-ban:

Android - clear frequently called list

Sajna Android-on nincs rá opció, hülyeség, de ez van. (Ez a Favorites lista a leggyakrabban hívott kapcsolatokkal, ezt nem lehet törölni vagy reset-elni). Itt a megoldás, kipróbáltam és remekül megy:

http://www.droidforums.net/forum/droid-general-discussions/15839-clear-…

Szerk.: még egy hasznos app: E-book olvasáshoz PDF-ben olvastam Adobe reader-rel, de az katasztrófa volt. Most találtam egy minden igényt kielégítő cuccost: Aldiko book reader:

Tud epub-ot és pdf-et is olvasni, az SD kártyáról is, megjegyzi könyvenként, hol tartottál, lehet kijelző fényességet állítani a normálhoz képest, lehet inverzben olvasni, a betű nagyság nagyítés és kicsinyítés nagyon fokozatos, lehet tördelést állítani, margót, nagyon jó és jól kezelhető a menüje szerintem stb stb. Ja és Free.

Address book .wab to vCard .vcf

Az van, hogy migrálok Office Outlook, Outlook Express és Thunderbird klienseket intranetes Roundcube webmailbe. A migrálás egyszerű: a meglévő offline levelező programban létrehozom az új IMAP-os fiókot, és áthúzom a mappákat. Pár klikk az egész. Viszont a címjegyzéket is migrálnom kell.

A Roundcube címjegyzéke vCard-ot tud megenni, erre akartam egy szabad szoftveres megoldást találni. Találtam is, de csak fél megoldást, ezért hozzáírtam a másik felét.

Kellékek:
- Thunderbird
- 2vcard (benne van Debian és Ubuntu repoban)
- vcard_reformat.py (az én progim)

tomld - optimalizációk

Elkezdtem tomld optimalizációján dolgozni, érdekes lesz.

Kaptam visszajelzést desktop-ról kb. 500 domain-el és 37 ezer szabállyal, itt már dögledezik és 2.5 percig tart egy futási ciklus az általam megálmodott 1 sec helyett :) Viszont itt sok folyamat van és a szabályok számával a futás idő jócskán exponenciálisan nő, egy sima szerveren nagyon kicsi a futási idő - átlagos szervereimen 0.2 sec. Úgy látom, hogy processzor típus is nagyon számít, órajeltől inkább függetlenül (illetve valszeg cache méret).

Ma az strcat2() funkcióban a malloc + régi adat átmásolását lecseréltem realloc-ra, így már eleve 3 %-al gyorsabb lett a kód. Persze tudom, eleve is csinálhattam volna így, de gyorsan össze akartam lapátolni egy működő verziót, mivel eleve alapjaiban eszközöltem változtatásokat sokszor, ezért még semmi nem volt biztos - még az sem, hogy sebességre elfogadható lesz.

iPhone4 felcsatolása Debian Squeeze alatt

Egy ismerősömnek össze kellett hozni. Lejegyeztem nagyjából:

# MOUNT IPHONE4 ON DEBIAN SQUEEZE WITH IFUSE
# work also with 4.3.3.

# with squeeze repos
sudo apt-get clean
sudo apt-get update
sudo apt-get build-dep libimobiledevice1

# with sid repos
sudo apt-get clean
sudo apt-get update
sudo apt-get -b source libimobiledevice1

sudo dpkg -i libimobiledevice_*.deb

# with squeeze repos
sudo apt-get clean
sudo apt-get update
sudo apt-get install ifuse

# plug iphone in usb and mount it
ifuse /media/iphone

# unmount it
fusermount -u /media/iphone

tomld - chroot

Végre sikerült megoldanom a chroot kérdését is. Tartottam tőle, hogy alapjaiban újra kell írnom nagy részét, de hála sikerült nagyon egyszerű módon megoldanom.

Ha tomld olyan rendszeren volt indítva, amely tartalmazott chroot-ból indított folyamatokat, akkor a létrehozott szabályaikban az elérési utak a valós, vagyis a chroot-tal prefix-elt könyvtár neveket tartalmazták. Ez azért volt probléma, mert a szabályaimat a "/" gyökérhez igazítottam. Tehát pl. a "/" gyökeret kivételként kezelem, és nem wildcard-ozok ki mindent ebben a könyvtárban, ha írás történik ide, stb.

Horizontal colored diff?

Létezik olyan colordiff parancs alternatíva, amely nem csak soronként színez, hanem vízszintesen is elkülöníti láthatóan a vízszintes különbséget?

Olyanra gondolok mint a github-on. Jó lenne már régóta egy ilyen. Akár le is lehetne programozni, mert neten nem igazán találtam releváns infót, igaz kicsit régebben néztem.

Valakinek ötlet?
Köszi.

tomld - DoS

A stabil kiadáshoz úgy éreztem, még egy dolog nagyon hiányzik. Ez annak lekezelése, ha túl sok szabály gyűlik be, amely során a tomld folyamat túl sokáig maximumon pörgetheti a CPU-t. Ez előfordulhat pl. nagy mennyiségű fájl hozzáférésnél pl. fájl szerver esetében.

Úgy oldottam meg, hogy figyelem minden ciklus teljes futási idejét, és ha túl lép egy előre megadott értéket (jelenleg 30 sec, normál esetben 1 sec alatt kell futnia egy mai gépen), akkor végignézem az összes szabályban található összes elérési utat, és ezek közül kikeresem azt, amely a legtöbb fájlt tartalmazza. (Ehhez minden azonos elérési út szülő könyvtárát számolom meg.)

pidstat

Megnézni, hogy a boot óta melyik folyamat ette a legtöbb CPU-t:


sudo apt-get install sysstat

pidstat -h | sort -n -k6

Melyik folyamat használt legtöbb I/O-t (read / write):


pidstat -hd | sort -n -k3
pidstat -hd | sort -n -k4

Adott folyamat CPU vagy I/O fogyasztása boot óta:


pidstat -C firefox
pidstat -d -C firef

tomld - titkosított FS

Egyetlen nyitott kérdés maradt jelenleg tomld-vel kapcsolatban. Ez a titkosított (ecryptfs) fájlrendszeren való használata. (Köszönet szimszon-nak a sok tesztelésért).

Az történik, hogy Tomoyo nem csak a feloldott fájlok hozzáférését jegyzi ecryptfs esetében, hanem mindeközben a titkosított mappán belüli titkosított nevű fájlt is beteszi a szabályok közé. A véletlen szerű nevek miatt pedig a szabályok csak gyűlni fognak megállás nélkül. Ez automatikusan nem oldódik meg.

Mostantól tomld alapbeállításokkal végignézi a /proc/mounts tartalmát, és ha talál ecryptfs típusú csatolást, akkor a titkosított részt hozzáadja automatikusan a rekurzív mappákhoz, és ezzel már kézi hack-elés nélkül is jól működik titkosított $HOME-on is.