Passzív operációs rendszer fingerprinting (ujjlenyomat) képességet építettek a PF-be (OpenBSD packet filter) amellyel lehetőség nyílik arra, hogy a forrás host operációs rendszerének verzióját egy szűrőnek átadja. Hogy mire használható ez?

Például a webszerverünket meglátogató, régi operációs rendszerrel ellátott gépeket átirányíthatjuk egy olyan weboldalra, amelyen felhívjuk a figyemüket a frissítésre. Vagy blokkolhatjuk az összes windows gépet a mail szerverünktől, hogy óvakodjunk a windowsos vírusoktól (állítólag nagyon jól működik a SoBig.F ellen).A stuffról egy leírást találsz itt. A készítők kérnek mindenkit, hogy segítsék a fejlesztést azzal, hogy segítenek feltölteni a OS fingerprint adatbázist a saját adataikkal. Ezt megteheted itt. Ha a weboldal nem ismerné fel az operációs rendszeredet és az egyéb adatokat, akkor azokat meg tudod adni az oldalon.

Bővebben itt.

A probléma:

"Az NVidia régóta készít az általa gyártott chipekhez "gyári" - ugyan zárt forrású, de - 3D gyorsítással rendelkező eszközmeghajtó programot. A driver-nek van azonban egy olyan kellemetlen tulajdonsága, hogy csak a 2.4.x szériájú stabil kernellel hajlandó működni. Addig amíg valaki meg nem dolgozza...."

Mivel a 2.6.0-test3-bk5 kerneltől (Linus fájának Bitkeeperből kinyerhető verziója) ismét változtak az adatstruktúrákkal kapcsolatos PCI nevek, ezért egy apró módosítást kellett végrehajtani a driverben. A patchelt kernel modul forrás a legközelebbi változásokig fog lefordulni a 2.6.0-test3-bk5 és újabb kerneleken.Akinek szüksége van a patchelt (kernel modul) forrásra, az letöltheti:

NVIDIA-Linux-x86-1.0-4496-pkg2-test3-mm3.tar.gz (.sign)

A telepítés menete:

1.) tedd a NVIDIA-Linux-x86-1.0-4496-pkg2-test3-mm3.tar.gz csomagot a /usr/src-be

2.) bontsd ki

3.) cd NVIDIA-Linux-x86-1.0-4496-pkg2-test3-mm3/usr/src/nv

4.) make

Tesztelve:

Uniproc kernel, SMP kernel, gcc 3.3

Tesztelve:

Unreal Tournament, Unreal Tournament 2003, RtCW: Enemy Territory

PS: ha kell szupport, írj a Fórumba itt.



Enjoy.

Véget ért a Szükség van (minden áron) a számítástechnikában a magyarításra? című szavazás, az eredméneket meg lehet tekinteni itt.

Az új szavazás témáját kedves anonymous kolléga vetette fel, amelyet mások kiegészítettek. A heti szavazás fő kérdése: "Mivel járulok hozzá a Szabad Szoftver elképzeléshez?". Szavazni lehet itt.Az előző szavazás hozzászólásaiban valaki fel vetette, hogy miért nem javasolhatnak az olvasók szavazásra témákat. Javasolhatnak, javasolhattak, de ahogy nézem nem sokan élnek a lehetőséggel. Mindenesetre akinek van valami ötlete, a javaslatát megteheti itt (a kiírt formában).

Egy téves határellenőrzési hiba van a semget(2) rendszerhívásban, amely a rosszindulatú helyi felhasználó számára lehetővé teszi azt, hogy kernel pánikot okozzon. A hiba kihasználásának során privilégium szint emelésre nincs lehetősége a támadónak.A támadás során a támadó rá tudja venni a kernelt, hogy az kifusson a rendelkezésre álló memóriából. A bug az OpenBSD 3.3-ban jelent meg, az előző verziók nem érintettek.

A hiba javítva van az OpenBSD-current-ben és a 3.3 stable ágban is. A patch elérhető az OpenBSD 3.3-hoz itt:

ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.3/common/002_semget.patch

Az Eweek egy interjút tett közzé Linus Torvaldsszal. Az interjúban a kedden kiszivárgott állítólagos "lopott" System V kódról kérdezték Linust.Linus elmondta, hogy a SCO által bemutatott kódrészlet egy memóriakezelő rutin darabja. Tulajdonképpen nem nagyon lényeges kód. A függvény szerepel az eredeti UNIX kódban, ezt eredetieg Ken Thompson írta. A kód megjelent már többször is nyilvánosan, példul a Lion könyvben, vagy például Maurice J. Bach "The Design of the Unix Operating System" című művében is.

Más szóval a kód nem csak 30 éves, hanem már számtalanszor publikálták is. A kód egyébként része a BSD Unix-nak is. A kódot már többször is kiadták (a könyveken kívül), egyrészt Dennis Ritchie, másrészt a Caldera tette elérhetővé a BSD licenc alatt.

A dolog iróniája, hogy a kód eltávolításra kerül a megjelenő 2.6-os kernelben. Ennek nem az az oka, hogy szerzői jogokba ütközne, hanem az, hogy a kernelfejlesztők meglehetősen csúnyának találták. Szóval nem elég, hogy a BSD licenc alatt elérhető a kód, még el is lesz távolítva.

Érdekes interjú, olvassátok itt.

Bruce Perens elkészítette annak a kiszivárgott SCO "bizonyítéknak" az elemzését, amelyet tegnap tett közzé a Heise német nyelvű IT oldal.

Az 1-es képen látható görög szöveg megfejtése nem volt bonyolult. Begépelve a szöveget Symbol fonttal, majd utána a fontokat Latin-ra váltva az alábbi szöveget lehet olvasni:

* As part of the kernel evolution toward modular naming, the

* functions malloc and mfree are being renamed to rmalloc and rmfree.

* Compatibility will be maintained by the following assembly code:

* (Also see mfree/rmfree below)A kettes képen látható kódsor számos szintaktikai hibát tartalmaz, így kizárt, hogy a Linux kernel része legyen, mert ebben az állapotban biztos, hogy nem fordul le. Egyébként a kód egy malloc() függvény kódja, amelynek a szerzői jogát az AT&T birtokolja és amelyet kétszer is kiadtak BSD licenc alatt. Egyszer az AT&T egyszer pedig a Caldera. Az a Caldera, akit egyébként most SCO-nak hívnak. Érdekes ;-)

Az elemzést el lehet olvasni itt.

Most, hogy a SCO elkezdi megfélemlíteni a végfelhasználókat is, elkezdtem elmélkedni azon, hogy vajon nekünk (vagy más hozzánk hasonló otthoni felhasználóknak) kell-e rettegnünk a SCO-tól?

Először is megvizsgáltam, hogy használok-e egyáltalán olyan kódot amit a SCO kifogásol.

1.) JFS - az IBM által fejlesztett naplózó filerendszer. A SCO azt állítja, hogy ez nem az IBM saját fejlesztése, bizonyos jogilag védett kódokon alapul. Nem használom.

2.) NUMA - Non-Uniform Memory Access. Kimondottan "nagygépes" környezetben használt technológia, speciális vasat igényel (pl. IBM NUMA-Q, Compaq Wildfire, SGI MIPS64, stb. Nem használom.

3.) SMP - Többprocesszoros környezet (Symmetric Multi Processing - SMP). Olyan számítógépeken használható, amelyekben egynél több processzor található (speciális eseteket kivéve). Használom.

4.) RCU - Read-Copy Update. SMP-hez kapcsolódó kód. A Linuxban az SMP kernelhez szorosan kapcsolódik, így használom.

Négy dologból kettő.Kérdések:

1.) Lehet, hogy el kellene kezdenem félni?



2.) Mi van azokkal, akik a felsorolt 4 dologból egyet sem használnak? Azoktól milyen alapon akar a SCO pénzt kérni?

Szerencsére Magyarországon más törvények vannak (egyelőre) érvényben, mint az USA-ban, de azért játszunk el a gondolattal, hogy mi lenne akkor, ha...

Valaki mondhatná: "Ugyanmár, hogyan jutnának el hozzánk a SCO emberei?" A kérdésre egyszerű a válasz.

Elegendő, ha valaki regisztrált Linux felhasználó, elegendő ha csak egyszer postázott levelet mondjuk az LKML-re, vagy bármely más levelezési listára. A nagy keresőmotorok biztos, hogy tartalmazzák a nevét, így elképzelhető, hogy elérik ha nagyon akarják. Nem kell más hozzá, mint hogy ír valaki egy scriptet, amely levlistákról kigyűjti a nevet, címet (akár országra lebontva) és egy listát készít belőle.

A következő kérdés ez lehetne:

3.) Ki érvényesítené a SCO jogait itt Magyarországon?

Nem tudom. Akár fogadhatna egy ügyvédet, vannak szerzői jogvédő hivatalok, akiknek pont az a dolgok, hogy hasonló szerzői jogi dolgokban eljárjanak.

4.) Magyarországon mi kell ahhoz, hogy valakit perbe fogjanak szerzői jogok "megsértéséért"? Elegendő lenne-e a SCO "bemondása", hogy "lopott kódot használ, fogják perbe", vagy szakértőknek meg kellene-e mutatniuk a kérdéses kódrészeket, akik azokról szakvéleményt mondanának?

5.) Ha igen, akkor kik lennének a szakértők?

6.) Mi van olyankor, ha a SCO megbízza a magyarországi szerzői jogvédő szervezeteket, hogy járjanak el helyette?

7.) Ha netán valami csoda folytán valakit beperelnének Magyarországon, az vajon mit tehetne? A magyarországi szabadszoftveres szervezetek tudnának-e valamilyen segítséget nyújtani a bajba jutott embernek?

8.) Mennyi esélye van a SCO-nak az átlag felhasználóval szemben?

Miért mennyi esélye van a Microsoftnak az átlag felhasználóval szemben?

Egyelőre ennyi kérdés merült fel bennem. Aki tudja a válaszokat, az tudassa...



Szóval kell félnünk a SCO-tól?

Az SCO azt tervezi, hogy folytatja és kiszélesíti a FUD (Fear, Uncertainty and Doubt - félelem, bizonytalanság és kétség rövidítése) kampányát a Linux felhasználók ellen. Darl McBride - a SCO elnöke és vezérigazgatója - elmondta a las vegas-i SCO Forum-on, hogy azt tervezik, hogy beperelik a végfelhasználókat isk.

McBride szerint a Linux felhasználókat felderítő munka már el is kezdődött a múlt hónapban. McBride elmondta, hogy az elmúlt hónapban sikerült azonosítaniuk az összesen eladott Linux szerverek vásárlóinak 10%-át (gondolom az Államok területén), és mint hozzátette azt várja, hogy mire a jogi akciókat elkezdik, ez a szám felmegy több, mint 40%-ra.

Három csoport dolgozik a felhasználók felderítésén. Az egyik készíti a felhasználók listáját. A második csoport feladata az, hogy elérje a felhasználókat (levélben) és felszólítsa őket a SCO UnixWare licenc megvásárlására. A harmadik csoport feladata pedig az lesz, hogy a jogi lépéseket megtegye azon felhasználók ellen, akik elutasítják a licenc megvásárlását.

Bővebben itt.

Alan Cox - talán az egyik legismertebb 'öreg motoros' a Linux kernel bizniszben - egy kisebb patchet küldött az LKML-re amely több helyen megváltoztatja a Maintainer/Credit listát a Linux kernel forrásában. Alan eltávolította magát a karbantartók közül.Ennek az oka az, hogy Alan kiveszi a tanulmányi szabadságát a Red Hat-nál, és visszatér az egyetemre, hogy tanuljon. Mivel Alan volt a 2.2-es kernel karbantartója is, most két lehetséges verzió van. Vagy végleg befejeződik a 2.2-es kernel karbantartása, vagy új karbantartó után kell nézni.

Feltették neki a kérdést, hogy miért távozik, mire Alan egy magyarázatot postázott:

From: Alan Cox [email blocked]

Subject: Next Month/Changes to where to send stuff

Date: 20 Aug 2003 13:05:10 +0100

At the end of September I'm off back to University on a years sabbatical from Red Hat to study for an MBA. I've made the decision that I'm basically going to vanish for the year so I can concentrate on the course, and on the pet side project of learning Welsh.

I've passed all my userspace projects on to other people already, and I'll be vanishing from kernel space too (except to a few priviledged processes ;)). Lots of people send me stuff as a gateway to getting it into 2.4 and 2.6. Lots of people send me security related stuff.

Can you in future please send stuff to

Security: [email blocked]

2.4: Marcelo/the list/someone he nominates to do that job

2.6: Andrew Morton or for small stuff Rusty Russell's trivial patch manager.

The 2.2 tree needs a new maintainer, someone who can spend their entire life refusing patches, being ignored by the mainstream (because 2.2 is boring) and by vendors (who don't ship 2.2 any more).

I'm not sure what to do about the -ac patch. Most of the remaining stuff is "pending Marcelo" for 2.4 mainstream, but not the O(1) scheduler and some of the odder cool stuff (like the morse bits). As 2.6 becomes relevant 2.4-ac basically becomes a fixed collection of add-ons that aren't mainstream anyway. And of course there are other people keeping patch sets in the same way nowdays.

A few years ago I'd have worried about doing this, the great thing is that with the kernel community we have today I know I'm not a critical cog in the machine. In fact I'm surrounded by people far better than I am and we even have Andrew Morton to keep Linus in check 8)

Dal ati!

Alan

Egyszer volt már ilyen pollfest, most itt az alkalom, hogy újra olyan témák legyenek megszavazva, amely az olvasókat érdekli. Ezért olyan szavazás témákra és válaszokra várok javaslatokat, amelyek az oldal profiljába vágnak és nagyobb érdeklődésre tarthatnak számot, stb. A szavazási témákra való jelölés formája:A szavazás címe: cím (egyértelmű, pontos max. 100 karakter)

válasz 1: (max. 50 karakter)

válasz 2: (max. 50 karakter)

válasz 3: (max. 50 karakter)

[..]

válasz 12: (max. 50 karakter) (ez a maximum válasz szám)

Az érdekes szavazásokat egyenként meg fogom szavaztatni, a sokásos ~1 hét / szavazás ciklusokban.

A javaslatokat a "hozzászólások"-ba várom.

Köszönöm.

A FreeBSD Release Engineering (RE) csapat bejelentette, hogy a FreeBSD 4.9 forrásfájának fagyasztása augusztus 25-én következik be. Az ok: készülődés a 2003. szeptemer 29-re ütemezett végső kiadásra. Az augusztus 25. dátum utáni, a RELENG_4 branch-be történő commiteket jóvá kell hagynia a FreeBSD release engineering csapatnak (re@FreeBSD.org). Ez alól csak egyes különösen aktív dokumentáció írók vannak felmentve.

Az első kiadásra jelölt (RC) kiadás szeptember 12-re van ütemezve az x86 és Alpha architektúrákra. Az ISO image-ek fel lesznek töltve az ftp-master.freebsd.org és a releng4.freebsd.org siteokra. A hálózati telepítési könyvtár fel lesz töltve az ftp-master.freebsd.org-ra. A packages/ könyvtár egy relatív symlink lesz, mint ahogy le van írva a releng cikkben. A ports fa 2003. szeptember 19-én lesz taggelve.

A kiadási csomagok szeptember 26-án lesznek feltöltve. A hivatalos kiadás és hivatalos kiadási bejelentés 2003. szeptember 29-én lesz. A RE csapat szintén kiadta a FreeBSD 4.9 nyílt feladatok (TODO) listáját és a Testing Guide-ot is a 4.9-RELEASE-hez.

FreeBSD 4.9 kiadási ütemterv

Sam Ravnborg egy olyan patchet készített, amelynek segítségével lehetőség nyílik arra, hogy egy kernel forrásból különböző kimeneti könyvtárba fordítsunk kernelt. Ez akkor lehet hasznos, ha több különböző konfigurációval dolgozunk, esetleg ro mediumon (pl. CD-ROM-on) tartjuk a kernel forrást. Az elgondolás szerintem nagyon hasznos. A használata egyszerű. A kernel fordítás közben a

make O=dir/to/kernel/src

parancsot kell kiadni.

A patch nény részből áll:

core patch

ieee patch

include patch

i386+always patch

A thread itt kezdődik.

Megjelent a Debian közösség szokásos heti hírlevelének, a DWN-nek az ez évi 33. száma.

A hírlevelet megtalálod itt.

A Heise német nyelvű IT oldal egyik cikkben bemutatott két olyan képet, amelyen állítólag a 'lopott' System V kódot hasonlítják össze a Linux kernel forrásában talált kóddal.A képek:

1, 2

A Slashdot szerint a kód csakugyan a Linux kernelből való. Szerintük a képeken azt lehet látni, hogy a kód a 2.4-es kernelfa /arch/ia64/sn/io/ate_utils.c filejának 88-102, és a 109-123 sorait tartalmazza.

A német nyelvű cikk itt.

Babelfish angol fordítás itt.

Ralf Spenneberg bejelentése szerint elkészült az az új IPsec HowTo, amely a megjelenés előtt álló 2.6.0-os Linux kernelben levő natív IPsec implementációt dolgozza fel.Eddig ha valaki VPN-t szeretett volna létrehozni, akkor szinte biztos, hogy a FreeS/Wan projekt "termékét" használta fel a céljai eléréséhez. A 2.6-os kernel megjelenésével nincs szükség külső program felhasználására ahhoz, hogy valaki virtuális magánhálózatot hozzon létre.

Hogy miért? Azért, mert a 2.6-os kernel egy saját IPsec stack-et tartalmaz. A ≥2.5.47 és 2.6.*-os kernelekben például a KAME-tools (BSD-sek ismerős ugye?) segítségével lehet VPN funciókat megvalósítani. Innentől kezdve a telepítés és a konfiguráció kicsit idegen lehet a FreeS/Wan-hoz szokott felhasználóknak, viszont ismerősebb lehet a *BSD-seknek.

A 2.5/2.6-os kerneltől kezdve használhatjuk az OpenBSD-s isakmpd daemont. Ezt Thomas Walpuski köszönhetjük, aki portolta az OpenBSD IKE daemonját (apt-get install isakmpd). Ehhez hasonló dolgokról olvashatunk Ralf HOWTO-jában.

A HOWTO több formátumban is elérhető:

[HTML] [PDF] [PS] [SGML]

Vajon melyik a legnépszerűbb Linux disztribúció? Nehéz kérdés. Nehezen lehet megválaszolni, hiszen itt nem lehet eladási adatokra alapozni, hiszen vannak olyan Linux terjesztések, amelyek teljesen ingyenesek, szabadon felhasználhatóak és esetleg nem is lehet őket hivatalos kereskedelmi csatornán keresztül beszerezni. Talán a legjobban úgy lehetne megbecsülni, hogy futó websiteokról statisztikát készítve kiválasztani a legtöbbet használt Linux terjesztést.

Ezt tette a NetCraft. A felmérés egyedménye az lett, hogy a legnépszerűbb Linux terjesztés a Red Hat. Második helyen a Debian végzett maga mögé utasítva a SuSE-t, és a Mandrake-et.

De vajon ha feltennénk a kérdést, hogy a Debian Linuxon futó hostok földrajzi eloszlása milyen, azt kevesebben tudnák pontosan meghatározni.

A Netcraft készített egy grafikont amelyen ezt az eloszlást ábrázolja.

A grafikont megtalálod itt.

Anthony Towns egy meglehetősen hosszú levélben ecsetelte azt, hogy mikor lesz stabil a jelenlegi testing/unstable Debian verzió.

Az SD Times egy interjút készített Linus Torvaldsszal. Az interjúban főleg a SCO vs. IBM + Linux kérdésről esett szó.

Az interjút megtalálod itt.

A neten több helyen felütötte a fejét az a hír, hogy a Microsoft Linux alapú szerverre helyezte át webszervereit. A hír azért volt furcsa, mert a Netcraft szerint a MS továbbra is Microsoft-IIS/6.0 webszerveren szolgálja ki az oldalait, de a Linuxon. Ez így meglehetősen értelmetlen. Emiatt a NetCraft számtalan levelet kapott, amelyben kérdőre vonták őket a hibáért.

A Netcraft most közzétett egy hírt, ameyben megmagyarázza a dolgot.A dolog lényege, hogy az MS pénteken megváltoztatta a DNS konfigurációit, így a www.microsoft.com-ra irányuló kérések ezentúl nem a Microsoft saját hálózatára mutatnak ezentúl, hanem az Akamai cache rendszerre (erről volt már szó szombaton is itt.)

Az Akami egy internetes web cache rendszer, amely szimmetrikus védelmet nyújt a DDoS típusú támadások ellen. Amikor a www.microsoft.com-ot kérjük a böngészőnkben, akkor a kéréseink az Akamai rendszeréhez érkeznek. Az Akamai gépe továbbküldi a kéréseket a Win2k3 szervernek, amelyen Microsoft-IIS/6.0 web szerver fut. Az Akamai gépei Linuxot futtatnak. Így állhat elő az a morbid helyzet, hogy a NetCraft azt jelenti, hogy a www.microsoft.com-ot Linux szerveren futó Microsoft-IIS/6.0 web szerver szolgálja ki.

Bővebben itt.

A linkért köszönet a szogi-nek.

A SCO vasárnap kijelentette, hogy elkészítette az a listát, amelyen azok a nagyobb cégek szerepelnek, amelyek számos Linux szervert üzelmeltetnek. Emellett kijelentette, hogy képes ezeket a cégeket akár bíróság elé is citálni abban az esetben, ha azok nem vásárolják meg az általa kiadott UnixWare licencet.

Az Eweek cikke itt.A VNUnet pedig arról cikkezik, hogy a felhasználók és a cégek könnyen újrafordíthatják a Linux kernelt, úgy, hogy kihagyják azokat a modulokat, amelyeket a SCO kifogásol. Így megvédhetik magukat a SCO licencdíj követeléseivel szemben.

A VNUnet cikke itt.

Csütörtökön a SCO azt állította, hogy a GPL licenc nem érvényes. Erre a kijelentésre válaszolt ma Eben Moglen professzor (Kolumbia Egyetem Jogi kar).

A választ elolvashatod itt.

A KGI (Kernel Graphics Interface) egy olyan keretmunka (framework) amely lehetővé teszi azt, hogy teljes 3D gyorsítással rendelkező video kártya drivereket lehessen lefordítani különböző platformokon úgy, hogy magukban a driverekben semmilyen változtatásra nincs szükség. A KGI, amelynek a fejlesztése Linuxon történt (és amely Linuxon már eléggé stabil), mostantól elérhető Free- és OpenBSD-re is.

Linkek:

http://www.kgi-project.org/

Kernel Graphics Interface for BSD

az eredmény:

...

22/tcp open ssh

...

Remote operating system guess: Linux 2.1.19 - 2.2.20

No comment

A 2.4-es kernel IDE kódja nem a legjobb. Ezen igyekszik segíteni Erik Andersen azzal, hogy a 2.6-os kernelben levő frissítéseket elkezdte visszahelyezni a 2.4.x kernelfába.A javítások 8 (pontosabban 9) patch formájában érhetők el.

[PATCH] 1/8

[PATCH] 2/8

[PATCH] 3/8

[PATCH] 4/8

[PATCH] 5/8

[PATCH] 6/8

[PATCH] 7/8

[PATCH] 8/8

[PATCH] 9/8

Erik reméli, hogy a patchek bekerülnek 2.4-es kernelbe. Mint mondja Ő használja ezeket a fixeket egy ideje, és semmilyen problémát nem tapasztalt. Alan Cox néhány kisebb dolgot eldobott a javítások közül, de nagy részének beolvasztására ígéretet tett. Aki nem akar várni az -ac patchekre, az már most letöltheti.

Blender 2.28 frissítés 2.28a-ra!A hírt itt olvashatjátok!

Megjelent a Zack Brown által karbantartott, heti rendszerességgel megjelenő, az LKML (Linux Kernel Mailing List) levelezési lista tartalmát kivonatos formában feldolgozó hírlevél, a Kernel Traffic.

A tartalomból:

• a 2.6-os kernel méretének növekedése gondot okoz a "beágyzott" eszközökre fejlesztőknek
• filerendszerhibák a 2.6.0-test2-ben
  
• per user felhasználói limitek felállítása
  
• megjelent a Linux 2.6.0-test3
  
• Hyperthreading problémák a 2.6-ban
  
• a NetConsole állása a 2.6-ban

A hírlevelet elolvashatod itt.