Kevés információ áll rendelkezésre jelen pillanatban, de úgy tűnik, hogy megjelent a Netscape 7.0 for Linux végleges verziója. Az final release tarball fileja fenn van a Netscape FTP szerverén.

A LinuxToday oldal egyik tagja letöltötte, telepítette az új kiadást, és megállapította, hogy ez bizony a végleges verzió: (Reported version is Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0.)

Hivatalos bejelentés még nincs a dologról, szépen csendben történt az egész.

A letöltési oldal itt.

Sziasztok...

Mivel nem szeretnék cikket lopni, így csak egy linket tennék ide, ha nem gond... azt hiszem ezt mindenkinek érdemes elolvasnia...

The NeverGone

Megjelent a Mozilla 1.1 verziója. Letölthető az ftp.mozilla.org-ról, de a magyar tükörszerverek javallottak inkább. Az ftp.c3.hu-n a mozilla mirror régóta nem frissült, ezért az egyetlen magyar elérhetőség (a cikk írásának pillanatában):



http://mozilla.szentimre.hu/mozilla1.1/Mi benne az új?

Improved application and layout performance

Improved stability

Improved Web site compatibility

Improved CSS, DOM and HTML standards support

Distinct window icons for the different Mozilla applications (artwork contributed by Grayrest).

Mozilla can now trigger MS DUN when started without a connection.

Fullscreen mode for Mozilla on Linux (press F11).

Browser tabs now close left to right (they used to close right to left).

The tab bar now has a button for creating new tabs.

All Search entry points now use your default search engine.

Download Manager has been enabled as the default download view (with many improvements)

Autocomplete in the location bar has more intelligent completion.

The Linux File Picker has improved filtering and a new directory button.

File extensions more accurately handled in downloads and we save the correct files when saving complete Web pages

Drag and drop support has been greatly improved.

View selection source: Context clicking on a selection now lets you view the HTML source for the selected area.

Page info displays more page info with improved General and Media tab content.

New button in prefs for making Mozilla the system default browser on MS

Windows

MathML is now enabled for Mozilla on Macintosh (it was already available

on

Windows and Linux).

Mozilla now takes advantage of Quartz rendering for users of Mac OS X

10.1.5

Better Bi-Di Arabic and Hebrew support including improved layout of

Arabic

pages on Linux and other platforms without their own Arabic shaping

support.

We have new layout performance enhancements targeted at DHTML.

Mozilla now has support for the display of XBM images.

Image and plug-in blocking for Mail & News

Mozilla allows you to view HTML mail messages as plain text.

You can now quote the current message in a Mail compose window with quote

Original under the options menu.

The JavaScript Debugger has gone through a major development cycle.

It now spots a palette of nine views which can be rearranged within the main

window or docked in separate floating windows. It is also possible to

create user-defined views and commands directly with JavaScript. More

details are available in the FAQ, newsgroup, or IRC channel.

Chatzilla has improved tab completion and can now join channels with

Japanese names.


(forrás: www.mozilla.org - mi más :) )

Novák Áron

Csomag: gaim

Sebezhetőség: tetszőleges program végrehajtás

Probléma típus: távoli

Debian-specifikus: nem



A Gaim, ami egy "instant üzenő kliens", ami kombinál különböző hálózatokat, fejlesztői találtak egy sebezhetőséget a hiperlink kezelő kódban. A 'Kézikönyv' böngésző parancs átad egy megbízhatatlan sztringet a shell-nek enélkül hogy rendesen levédené idézőjelekkel, ezáltal lehetővé téve egy támadó számára, hogy tetszőleges parancsot lefuttasson a felhasználó gépén. Sajnos a Gaim nem jeleníti meg a hiperlinket mielőtt a felhasználó rákattint. Azok a felhasználók, amelyek más beépített böngésző utasításokat használnak nem sebezhetők.A probléma javítva van a 0.58-2.2 verziójú csomagban a jelenlegi stabil terjesztésben (woody), és a 0.59.1-2 verziójú csomagban az unstabil terjesztéshez (sid). A régebbi stabil terjesztés, a potato nem érintett ebben a hibában. lévén az nem tartalmazza a Gaim programot.



A Gaim javított verziója nem adja át többé a felhasználói kézikönyv parancsát a shellnek. A parancsok amelyek %s-t tartalmaznak idézőjelek közt kijavítódnak, hogy ne tartalmazzanak idézőjelet. A kézikönyv olvasó parancsot meg lehet szerkeszteni a 'General'/Általános táblán a 'Preferences'/Beállítások párbeszédablakban, amit bejelentkezési ablak 'Options'/Opciók menüjéből vagy a 'haverlista' ablak 'Tools'Eszközök menün belülről a 'Preferences'/Beállítások menüből lehet elérni.



Javasoljuk, hogy frissítsd a gaim csomagod azonnal.

Martin Schultze levele a debian-security-announce listán.

A frissítésrõl szóló FAQ-nk.

Csomag: mailman

Sebezhetőség: oldalak-közti scriptelhetőség

Probléma típus: távoli

Debian-specifikus: nem

CVE Id: CAN-2002-0388

Idézve az eredeti DSA 147-1-et:


Egy oldalközi scriptelési sebezhetőséget találtak a mailmanben, ami egy levelezési listák managelését szolgáló szoftver. Amikor egy jólformált ravasz URL-t nyitunk meg az Internet Explorerrel (úgy tűnik, más brozerek nem érintettek a hibában), az ereményül kapott weboldal hasonlítani fog az igazira, de egy javascript komponenst is lefuttat, amit egy támadó felhasználhat arra, hogy érzékeny információkat szerezzen. Az új verziójú Debian 2.2 csomagok szintén tartalmazzák a biztonságilag érintett foltokat a mailman 2.0.11 verziójából.



Ezt a hibát már a DSA 147-1-ben kijavították, azonban ellenben a közhiedelemmel, kiderült, hogy amikor a potato-t woody-ra upgradelik, a python1.5 nem upgradelődik python2.1-re. Így az is kiderült, hogy a mailman biztonsági javítása nem szándékosan ugyan, de függ a 2.1-es pythontól, mind az upstream verzióban, mind a biztonsági javításban, és ez használhatatlanná teheti a mailman-t bizonyos helyeken.



A problémát javítja a 2.0.11-1woody4 verzió az aktuális stabil terjesztésben (woody). A többi terjesztés nem érintett a hibában.

Javasoljuk frissítsd a mailman csomagjaid.

Martin Schultze levele a debian-security-announce listán.

A frissítésrõl szóló FAQ-nk.

Gondoltam másoknak is van olyan problémája, hogy régi KDE 2.x-es programokat nem tud apt-get-elni mivel azok kde2.x dependelnek. Így elkészítettem, és továbbra is fogok még készíteni Debian csomagokat KDE3-hoz.


APT-LINE:

deb http://ers.linuxforum.hu/kde3deb/ ./


(Példaképp ilyen a: Krusader, KxICQ (a legjobbab :))

A Debian fejlesztők ennek a hétnek a végén tartják az első bug kereső, és írtó partit (Bug Squashing Party 2002. augusztus. 30 - szeptember 2). Meglepő, hogy ilyen ütemben halad a fejlesztés. A Debian egy nagyon rövid fejlesztési ciklust tervez a Debian Sarge-nak, ezért szükséges minél több kiadás kritikus (release critical) bugot javítani.Az erről szóló levelet Raphael Hertzog küldte a debian-devel-announce@ levlistára.

A levelet elolvashatod itt.

XFS Root Boot HOWTO

Micskó Gábor trey@debian.szintezis.hu - Hungarian Unix Portal

v.1.0, 2002. augusztus. 26 - Copyright © Hungarian Unix Portal

1. Bemutatás

2. Elõfeltételek

3. Ext2 alapú filerendszer konvertálása XFS-re

3.1 Kernel fordítása XFS támogatással

3.2 XFS filerendszer készítése

3.3 A root filerendszer másolása

3.4 Végsõ beállítások

3.5 Reboot

4. Copyright, licenc, visszajelzés és ilyesmi1. Bemutatás:

Ez a HOWTO leírja azt az eljárást amellyel át tudunk konvertálni egy Ext2 filerendszer alapú Linux rendszert úgy, hogy az egész root (/) filerendszer XFS-en fusson. Az XFS-sel kapcsolatos bõvebb információért és a legfrissebb letöltési lehetõségért látogasd meg az XFS project web oldalát a http://oss.sgi.com/projects/xfs/ URL-en.

2. Elõfeltételek:

Mielõtt nekilátnánk, két elõfeltételnek kell megfelelned:

# Rendelkezned kell egy telepített és mûködõ Linux rendszerrel

# Rendelkezned kell egy üres partícióval, a partíciónak 83-as típusúnak (Linux) kell lennie. Az nem számít, hogy a partíció formázva van-e vagy sem, mi majd megformázzuk XFS-re, és úgyis eltûnik róla minden, ami elõtte rajta volt ;-)

Ez a dokumentum feltételezi, a partícióid kiosztása a következõ: A /dev/hda1 (swap), /dev/hda2 / (ext2), és végül /dev/hda3, amely filerendszert fogjuk XFS-re alakítani. Ez rendszer-specifikus, értelemszerûen más gépeken az ottani beállításokkal kell végezni a mûveleteket.

A Linux kernel (a howto írásának pillanatában 2.4.20-pre4) nem támogatja az XFS filerendszert, tehát külsõ patchet kell beszereznünk. Amire szükségünk lesz, az egy Linux kernel XFS filerendszer támogatással, és az xfsprogs-x.x.x.src.tar.gz programokra. Az XFS programokat (xfsprogs) letölthetjük az XFS honlapjáról http://oss.sgi.com/projects/xfs/download.html) xfsprogs-x.x.x.src.tar.gz néven. Linux kernelt fordítani XFS támogatással nem nehéz dolog, de ha még soha nem fordítottál kernelt, akkor lehet hogy nem ezzel kellene kezdened ;-)

3. Egy ext2 alapú rendszer konvertálása XFS-re

Ez a dokumentum a meglevõ ext2 alapú rendszer ``áthelyezésérõl" szól.

A következõ szekció leírja a szükséges lépéseket ahhoz, hogy hogyan építsünk fel egy XFS root (/) filerendszert, és hogyan bootoljuk be azt.

3.1 Kernel fordítása XFS támogatással

Töltsd le a legutolsó 2.4.x vanilla kernelt (a cikk írásának pillanatában a 2.4.18. Töltsd le kernelhez elérhető XFS patchet. Mielőtt nekivágsz a kernel fordításhoz, látogass el az XFS honlapjára és tájékozódj, hogy melyik a jelenleg elérhető legfrissebb stabil XFS patch, és az melyik kernelhez készült. Ha megvan, akkor azt a kernelforrást töltsd le a kernel.org-ról, amelyet az XFS patch támogat) az ftp.kernel.org-ról a /tmp könyvtárba.Csomagold ki egy elkülönített könyvtárba. Másold a /usr/src/ alá. Töltsd le a legutolsó XFS patchet ehhez a kernelhez, és másold a
kernelforrás könyvtárába (/usr/src/linux). Jelen esetben a linux-2.4.18.tar.gz kernelt, és az xfs-1.1-2.4.18-all.patch.bz2 patchet használjuk:

Kernelpatchelés menete:

#cd /usr/src/linux

#bunzip -cd xfs-1.1-2.4.18-all.patch.bz2 | patch -p1

[....]

Konfiguráld a kernelt a make config (make menuconfig, make xconfig) segítségével, amelyik közelebb áll a szívedhez :-). A "File systems" címkével jelzett szekcióban kapcsold be a "SGI XFS filesystem support" stuffot (elvileg ha jól
patcheltél, akkor ez be is lesz kapcsolva, plusz még alatta a "Enable XFS Quota" is. Azért nem árt kernel fordítás előtt ezt ellenőrizni.). Legyél biztos abban, hogy az XFS támogatást a kernelbe fixen drótozva tetted, NEM MODULBA, mert akkor nem fogja boot idõben a kernel támogatni az XFS-t (csak kisebb cselek árán, de erre most nem térek ki). Konfiguráld az egész kernelt ahogy szükséged van rá, mentsd el a konfigot, majd forgasd le a kernelt. A kernel fordítását a make dep; make clean; make bzImage parancsok kiadásával végezd (vagy ahogy tetszik, ezerféleképpen lehet) ha szükséges fordítsd le a modulokat is, make modules; make modules_install. Utána másold az új kernelt a /boot könyvtárba. Másold a System.map-ot /boot-ba.



#make dep

#make clean

#make bzImage

#cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.18-xfs

#cp /usr/src/linux/System.map /boot

Most szükségünk van az XFS programok lefordítására, (én a debian sarge rendszeremen egyszerûen kiadtam az 'apt-get install xfsprogs' parancsot, de aki akarja forgassa le (a fordításhoz nézd meg a letöltött xfsprogs-x.x.x.tar.gz-ben levõ telepítési útmutatót). Ezek a programok azok, amellyel az XFS filerendszert létre lehet hozni, ellenõrizni lehet, stb.

A következõ lépés az, hogy módosítani kell a LILO bejegyzéseit úgy, hogy az új kernelünket bootolja be. Szerkesszük a /etc/lilo.conf filet és végezzük el az alábbi bejegyzéseket:

image=/boot/vmlinuz-2.4.18-xfs

label=xfsboot

read-only

root=/dev/hda2

Futtassuk az /sbin/lilo parancsot, ahhoz hogy aktiváljuk az új konfigurációt és rebootoljunk az új kernellel.

3.2 Az XFS filerendszer készítése

OK, most van egy kernelünk XFS támogatással, itt az ideje, hogy megformázzuk az üres partíciónkat XFS-re.

#mkfs.xfs /dev/hda3

meta-data=/dev/hda3 isize=256 agcount=8, agsize=64448 blks

data = bsize=4096 blocks=515584, imaxpct=25

= sunit=0 swidth=0 blks, unwritten=0

naming =version 2 bsize=4096

log =internal log bsize=4096 blocks=1200, version=1

= sunit=0 blks

realtime =none extsz=65536 blocks=0, rtextents=0

[...]

3.3 A root filerendszer másolása

Ez egy könnyû lépés, kevés munkát igényel a részedrõl, viszont ez viszi el a legtöbb idõt a munka során. Elõször is umount-old az összes NFS, SMB, és cdrom-ot, ami esetleg mountolva lenne. Készíts egy csatolási pontot (mount point) az új XFS partíció részére, és mountold azt. Néhány dolog mielõtt másolsz: ne másold a /proc könyvtárt, viszont készíts neki egy csatolási pontot. Ha nem tudod umountolni a NFS-ed vagy CD-ROM-od, emlékezz rá, hogy ezeket ne másold. Minden mást másolj át a cp -a paranccsal.

#mkdir /xfsvol

#mount -t xfs /dev/hda3 /xfsvol

#cd /

#cp -a bin etc lib boot dev home usr var [...] /xfsvol

#mkdir /xfsvol/proc

Ugyanezt a cp -ax paranccsal is el lehet végezni könnyebben, lásd a bõvebb információkért a cp man oldalát.

3.4 Végsõ beállítások

Mielõtt rebootolnánk az új XFS partíciónkra, el kell végeznünk néhány beállítást. Elõször is, meg kell változtatnunk a /etc/fstab bejegyzést a root partíciónkhoz. Emlékezz! hogy az fstab file amin dolgoznunk kell a /xfsvol/etc alatt van, hiszen az lesz az új root partíciónk. Tehát szerkeszd ezt a filet, és
írd át a root partícióhoz szóló bejegyzést. Valahogy így:

/dev/hda2 / ext2 defaults 1 1

Ezt kell megváltoztatnunk így:

/dev/hda3 / xfs defaults 1 1

Editáld a /etc/lilo.conf-ot úgy, hogy a root partíciódra mutasson. Valami ilyesmit kell csinálnod:

default=xfsboot2

...

image=/boot/vmlinuz-2.4.18-xfs

label=xfsboot2

read-only

root=/dev/hda3

Figyelj arra, hogy futtasd a'/sbin/lilo'-t újra, mielõtt rebootolnál.

3.5 Reboot

Gratulálok! Ha követted a lépéseket, akkor a rendszered tisztán XFS-en fut. Hogy ellenõrizd ezt, írd be 'mount' és nézd meg a kimenetet:

/dev/hda3 on / type xfs (rw)

none on /proc type proc (rw)

none on /dev/pts type devpts (rw,gid=5,mode=620)

Ha minden jól müködik, akkor a régi partíciódat (/dev/hda2) megformázhatod XFS-re, és visszaállíthatod a rendszered az eredeti partícióra. Vagy csinálhatsz amit kedved tart. Ha rám hallgatsz azt csinálsz amit akarsz ;-).

4. Copyright, licenc, visszajelzés és ilyesmi:

Micskó Gábor trey@debian.szintezis.hu - Hungarian Unix Portal

Ez a dokumentum szabadon másolható és terjeszthetõ, ha a copyright és az engedély szövegét minden másolaton megõrzik. E dokumentum módosított változatai a változatlan másolatokkal megegyezõ feltételek alapján másolhatók és terjeszthetõk, ha a módosított változatot is az ezzel az engedéllyel megegyezõ feltételekkel terjesztik. A fordítások is a ``módosított változat'' kategóriájába tartoznak.

Garancia: Nincs.

Ajánlások: Az üzleti célú terjesztés megengedett és támogatott, de nyomatékosan ajánlott, hogy a terjesztõ lépjen kapcsolatba a szerzõvel a terjesztés elõtt, a dolgok

naprakészségének biztosítása végett. (Küldhetsz egy példányt abból, amit csinálsz, ha már úgyis csinálod.) A fordítóknak is ajánlott kapcsolatba lépni a szerzõvel, mielõtt lefordítják. A nyomtatott változat jobban néz ki. A papírt használd fel újra!

Visszajelzéseket, építõ jellegû kritikát a trey@debian.szintezis.hu email címre várok.

A dokumentum otthona a Hungarian Unix Portal. A legfrissebb verziót a

http://www.hup.hu/old/xfs URL-en keresd.

Sok szerencsét!

ReiserFS Root Boot HOWTO

Micskó Gábor trey@debian.szintezis.hu - Hungarian Unix Portal

v.1.0, 2002. augusztus. 26 - Copyright © Hungarian Unix Portal

1. Bemutatás

2. Elõfeltételek

3. Ext2 alapú filerendszer konvertálása ReiserFS-re

3.1 Kernel fordítása ReiserFS támogatással

3.2 ReiserFS filerendszer készítése

3.3 A root filerendszer másolása

3.4 Végsõ beállítások

3.5 Reboot

4. Hibaelhárítás

5. Copyright, licenc, visszajelzés és ilyesmi1. Bemutatás:

Ez a HOWTO leírja azt az eljárást amellyel át tudunk konvertálni egy Ext2 filerendszer alapú Linux rendszert úgy, hogy az egész root (/) filerendszer ReiserFS-en fusson. A ReiserFS-sel kapcsolatos bõvebb információért és a legfrissebb letöltési lehetõségért látogasd meg a ReiserFS project web oldalát a http://www.reiserfs.org/ URL-en.

2. Elõfeltételek:

Mielõtt nekilátnánk, három elõfeltételnek kell megfelelned:

# Rendelkezned kell egy telepített és mûködõ Linux rendszerrel

# Rendelkezned kell egy üres partícióval, a partíciónak 83-as típusúnak (Linux) kell lennie. Az nem számít, hogy a partíció formázva van-e vagy sem, mi majd megformázzuk ReiserFS-re, és úgyis eltûnik róla minden, ami elõtte rajta volt ;-)

# A /boot könyvtár egy szeparált kis méretû ext2 filerendszeren legyen, mert a Lilo (LInux LOader) nem támogatja a ReiserFS filerendszerrõl való bootolást (ez nem teljesen igaz. Lehet Lilo-val ReiserFS-rõl bootolni, de! a ReiserFS filerendszert egy -notail opcióval kell felmountolni. Hogy miért? Lásd a hibaelhárítás címû részt.) A grub (GRand Unified Bootloader) az újabb információk szerint tud bootolni ReiserFS-rõl. Esetleg használj Lilo helyett grub-ot. Bõvebb információért látogasd meg a Lilo honlapját a http://brun.dyndns.org/pub/linux/lilo/, és a grub honlapját a
http://www.gnu.org/software/grub/ URL-en.

Ez a dokumentum feltételezi, a partícióid kiosztása a következõ: A /dev/hda1 (swap), /dev/hda2 /boot (ext2), /dev/hda3 root (/) filerendszer (ext2), és végül a /dev/hda4 amely filerendszert fogjuk ReiserFS-re alakítani. Ez rendszer-specifikus, értelemszerûen más gépeken az ottani beállításokkal kell végezni a mûveleteket.

A Linux kernel (2.4.x) lassan egy éve támogatja a ReiserFS filerendszert, tehát külsõ patcheket nem kell beszereznünk. Amire szükségünk lesz, az egy Linux kernel ReiserFS filerendszer támogatással, és a reiserfsprogs programok.

A ReiserFS programokat (reiserfsprogs) letölthetjük a ReiserFS honlapjáról (http://www.reiserfs.org/) reiserfsprogs-x.x.x.tar.gz néven. Linux kernelt fordítani ReiserFS támogatással nem nehéz dolog, de ha még soha nem fordítottál kernelt, akkor lehet hogy nem ezzel kellene kezdened ;-)

3. Egy ext2 alapú rendszer konvertálása ReiserFS-re

Több kereskedelmi Linux terjesztés felajánlja telepítéskor, hogy a rendszerünket ReiserFS filerendszerre telepíthetjük. Ilyenkor nem kell mást tenni, mint kiválasztani a ReiserFS-t, megadni a csatolási pontot (/) és a telepítõ elvégzi helyettünk a szükséges feladatokat. Ez a dokumentum a meglevõ ext2 alapú rendszer ``áthelyezésérõl" szól.

A következõ szekció leírja a szükséges lépéseket ahhoz, hogy hogyan építsünk fel egy Reiserfs root (/) filerendszert, és hogyan bootoljuk be azt.

3.1 Kernel fordítása ReiserFS támogatással

Töltsd le a legutolsó 2.4.x kernelt az ftp.kernel.org-ról a /tmp könyvtárba. Csomagold ki egy elkülönített könyvtárba. Másold a /usr/src/ alá.

Konfiguráld a kernelt a make config (make menuconfig, make xconfig) segítségével, amelyik közelebb áll a szívedhez :-). A "File systems" címkével jelzett szekcióban kapcsold be a "ReiserFS support" stuffot. Legyél biztos abban, hogy a ReiserFS támogatást a kernelbe fixen drótozva tetted, NEM MODULBA, mert akkor nem fogja boot idõben a kernel támogatni a ReiserFS-t (csak kisebb cselek árán, de erre most nem térek ki). Konfiguráld az egész kernelt ahogy szükséged van rá, mentsd el a konfigot, majd forgasd le a
kernelt. A kernel fordítását a make dep; make clean; make bzImage parancsok kiadásával végezd (vagy ahogy tetszik, ezerféleképpen lehet) ha szükséges fordítsd le a modulokat is, make modules; make modules_install. Utána másold az új kernelt a /boot könyvtárba. Másold a System.map-ot /boot-ba.

#make dep

#make clean

#make bzImage

#cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.0-reiserfs

#cp /usr/src/linux/System.map /boot

Most szükségünk van a ReiserFS programok lefordítására, (én a debian sarge rendszeremen egyszerûen kiadtam az 'apt-get install reiserfsprogs' parancsot, de aki akarja forgassa le (a fordításhoz nézd meg a letöltött reiserfsprogs-x.x.x.tar.gz-ben levõ telepítési útmutatót). Ezek a programok azok, amellyel a ReiserFS filerendszert létre lehet hozni, ellenõrizni lehet, ki lehet terjeszteni a méretét, stb.

A következõ lépés az, hogy módosítani kell a LILO bejegyzéseit úgy, hogy az új kernelünket bootolja be. Szerkesszük a /etc/lilo.conf filet és végezzük el az alábbi bejegyzéseket:

image=/boot/vmlinuz-2.4.0-reiserfs

label=reiserfsboot

read-only

root=/dev/hda3

Futtassuk az /sbin/lilo parancsot, ahhoz hogy aktiváljuk az új konfigurációt és rebootoljunk az új kernellel.

3.2 A ReiserFS filerendszer készítése

OK, most van egy kernelünk ReiserFS támogatással, itt az ideje, hogy megformázzuk az üres partíciónkat ReiserFS-re.

#mkreiserfs /dev/hda4

reiserfsprogs 3.6.2

mkreiserfs: Guessing about desired format..

mkreiserfs: Kernel 2.4.20-pre4 is running.

Format 3.6 with standard journal

Count of blocks on the device: 515080

Number of blocks consumed by mkreiserfs formatting process: 8227

Blocksize: 4096

Hash function used to sort names: "r5"

Journal Size 8193 blocks (first block 18)

Journal Max transaction length 1024

inode generation number: 0

UUID: 6693db94-d0e1-410c-a35e-27472e56299d

ATTENTION: YOU SHOULD REBOOT AFTER FDISK!

ALL DATA WILL BE LOST ON '/dev/hda4'!

Continue (y/n): y

[...]

3.3 A root filerendszer másolása

Ez egy könnyû lépés, kevés munkát igényel a részedrõl, viszont ez viszi el a legtöbb idõt a munka során. Elõször is umount-old az összes NFS, SMB, és cdrom-ot, ami esetleg mountolva lenne. Készíts egy csatolási pontot (mount point) az új ReiserFS partíció részére, és mountold azt. Néhány dolog mielõtt másolsz: ne másold a /proc könyvtárt, viszont készíts neki egy csatolási pontot. Ha nem tudod umountolni a NFS-ed vagy CD-ROM-od, emlékezz rá, hogy ezeket ne másold. Minden mást másolj át a cp -a paranccsal.

#mkdir /reiserfsvol

#mount -t reiserfs /dev/hda4 /reiserfsvol

#cd /

#cp -a bin etc lib boot dev home usr var [...] /reiserfsvol

#mkdir /reiserfsvol/proc

Ugyanezt a cp -ax paranccsal is el lehet végezni könnyebben, lásd a bõvebb információkért a cp man oldalát.

3.4 Végsõ beállítások

Mielõtt rebootolnánk az új ReiserFS partíciónkra, el kell végeznünk néhány beállítást. Elõször is, meg kell változtatnunk a /etc/fstab bejegyzést a root partíciónkhoz. Emlékezz! hogy az fstab file amin dolgoznunk kell a /reiserfsvol/etc alatt van, hiszen az lesz az új root partíciónk. Tehát szerkeszd ezt a filet, és írd át a root partícióhoz szóló bejegyzést. Valahogy így:

/dev/hda3 / ext2 defaults 1 1

Ezt kell megváltoztatnunk így:

/dev/hda4 / reiserfs defaults 1 1

Editáld a /etc/lilo.conf-ot úgy, hogy a root partíciódra mutasson. Valami ilyesmit kell csinálnod:

default=reiserfsboot2

...

image=/boot/vmlinuz-2.4.0-reiserfs

label=reiserfsboot2

read-only

root=/dev/hda4

Figyelj arra, hogy futtasd a'/sbin/lilo'-t újra, mielõtt rebootolnál.

3.5 Reboot

Gratulálok! Ha követted a lépéseket, akkor a rendszered tisztán ReiserFS-en fut. Hogy ellenõrizd ezt, írd be 'mount' és nézd meg a kimenetet:

/dev/hda4 on / type reiserfs (rw)

none on /proc type proc (rw)

none on /dev/pts type devpts (rw,gid=5,mode=620)

Ha minden jól müködik, akkor a régi partíciódat (/dev/hda3) megformázhatod ReiserFS-re, és visszaállíthatod a rendszered az eredeti partícióra. Vagy csinálhatsz amit kedved tart. Ha rám hallgatsz azt csinálsz amit akarsz ;-).

4. Hibaelhárítás

Probléma:

ReiserFS-t választottál a /boot partíció fájlrendszereként. Amikor egy LILO beállítást akar létrehozni, a következõ üzenetet kapod:

Hole found in map file (alloc_page)

Ezután, amikor újraindítja a rendszert. a lilo megáll, és csak a 'LI' betûk látszanak.

Ok:

A 16k-nál kisebb méretû fájlok esetében a reiserfs megpróbálja elkerülni a részblokkok elpazarlását, a fájlok végének és elejének "összecsomagolásával". Ez problémákat okoz a lilo számára, mivel a szükséges adatok a merevlemezen nem megfelelõ helyre kerülnek.

Megoldás

Kétféle megközelítés létezik: formázd újra a /boot partíciót ext2 fájlrendszer használatával, vagy csatold fel a /boot partíciót a 'notail' paraméter használatával.

Az újraformázás módja:

Root-ként másold le a /boot könyvtár tartalmát és csatold le a /boot partíciót:

cp -a /boot /boot.backup

umount /boot

Formázd újra a partíciót, ahol a /boot 'ext2'-ként lett csatolva:

mke2fs /dev/hd??

Szerkeszd meg az /etc/fstab fájlt:

változtasd meg a

/dev/hd?? /boot reiserfs defaults 0 0

sort a

/dev/hd?? /boot ext2 defaults 0 0

sorra.

Csatold fel a /boot partíciót újra, mozgasd vissza a tartalmát, majd futtasd a lilo-t:

mount /boot

mv /boot.backup /boot

lilo

A 'notail' paraméter megadása:

Rootként szerkessze az /etc/fstab fájlt:

változtasd meg a

/dev/hd?? /boot reiserfs defaults 0 0

sort a

/dev/hd?? /boot reiserfs notail 0 0

sorra.

Indítd újra rendszert. Másold és mozgasd át a /boot könyvtárat, majd futtasd le újból a lilo-t:

cp -r /boot /boot2

mv /boot2 /boot

/sbin/lilo

5. Copyright, licenc, visszajelzés és ilyesmi:

Micskó Gábor trey@debian.szintezis.hu - Hungarian Unix Portal

Ez a dokumentum szabadon másolható és terjeszthetõ, ha a copyright és az engedély szövegét minden másolaton megõrzik. E dokumentum módosított változatai a változatlan másolatokkal megegyezõ feltételek alapján másolhatók és terjeszthetõk, ha a módosított változatot is az ezzel az engedéllyel megegyezõ feltételekkel terjesztik. A fordítások is a ``módosított változat'' kategóriájába tartoznak.

Garancia: Nincs.

Ajánlások: Az üzleti célú terjesztés megengedett és támogatott, de nyomatékosan ajánlott, hogy a terjesztõ lépjen kapcsolatba a szerzõvel a terjesztés elõtt, a dolgok naprakészségének biztosítása végett. (Küldhetsz egy példányt abból, amit csinálsz, ha már úgyis csinálod.) A fordítóknak is ajánlott kapcsolatba lépni a szerzõvel,
mielõtt lefordítják. A nyomtatott változat jobban néz ki. A papírt használd fel újra!

Visszajelzéseket, építõ jellegû kritikát a trey@debian.szintezis.hu email címre várok.

Sok szerencsét!

A PostgreSQL-ben újabban felfedezett biztonsági hibákat (puffer túlcsordulás) orvosolandó megjelent a PostgreSQL 7.2.2. A megjegyzésben olvashatjuk, hogy ezek a hibák csak akkor kritikusak, ha 'open' vagy 'shared' adatbázis-szerverként használjuk a pgSQL-t. A hibák kihasználásához connectolni kell tudni az adabázis szerverhez.

Bejelentés:From: "Marc G. Fournier" [scrappy@hub.org]

To: pgsql-announce@postgresql.org

Subject: [GENERAL] PostgreSQL 7.2.2: Security Release

Date: Sat, 24 Aug 2002 00:22:17 -0300 (ADT)

Cc: freebsd-databases@freebsd.org, [pgsql-general@postgresql.org], Vince

Vielhaber [vev@michvhf.com]

Due to recent security vulnerabilities reported on BugTraq, concerning several buffer overruns found in PostgreSQL, the postgreSQL Global Development Team today released v7.2.2 of PostgreSQL that fixes these vulnerabilities.

The following buffer overruns have been identified and addressed:

... in handling long datetime input

... in repeat()

... in lpad() and rpad() with multibyte

... in SET TIME ZONE and TZ env var

Although v7.2.2 is a purely plug-n-play upgrade from v7.2.1, requiring no dump-n-reload of the database, it should be noted that these vulnerabilities are only critical on "open" or "shared" systems, as they require the ability to be able to connect to the database before they can be exploited.

The latest release is available at:

ftp://ftp.postgresql.org/pub/sources/v7.2.2

As well as at appropriate mirror sites.

Please report any bugs/problems with this release to:

pgsql-bugs@postgresql.org

Marc G. Fournier

Co-ordinator

PostgreSQL Global Development Group

Újabb -ac patch.

Letölthető patch-2.4.20-pre4-ac2.gz

Változások: [+ indicates stuff that went to Marcelo, o stuff that has not,

* indicates stuff that is merged in mainstream now, X stuff that proved bad and was dropped out, - indicates stuff not relevant to the main tree]

The HP merge is now down to 3503 lines pending

IDE status

Chasing two reports of strange ide-scsi crashes

Still some Promise glitches - need to review merge carefully

Need to double check SiS code versus older SiS code.

Sometimes we now turn DMA off excessively for simplex devices

No corruption cases except known hardware incompatibilities that broke before

The insmod of IDE drivers isnt in yet. I've been rather busy so it didn't make the time. However anyone who wants should be able to fill in the other bits of the ide pci driver registration logic to finish it off.

Once I get a bit of time I'll resync with Marcelo and push him various updates.

Linux 2.4.20-pre4-ac2

- Pull NFSD back in line with Marcelo

o Fix IDE PCMCIA build error (me)

o Fix check/request region race in IDE DMA (me)

o Fix I/O handling of dma_base2 request fail (me)

o More debugging around the simplex ide DMA (me)

o Fix kmalloc error leak in fd1772 (Silvio Cesare)

o Handle out of memory on acorn ps/2 (Silvio Cesare)

o IEEE1394 integer overflow fix (Silvio Cesare)

o Khttpd race fixes (Dan Kegel)

o Backport kaweth fixes from 2.5 (Oliver Neukum)

O Fix gcc 2.x build of brlvger (Eyal Lebedinsky)

o Error handling clean ups for USB storage (Pete Zaitcev)

o Fix loops_per_jiffy mod calculation overflow (Yoann Vandoorselaere)

o PCI hotplog oops fixes (Greg Kroah-Hartmann)

o APM do idle now doesnt keep warning on error (Ben LaHaise)

o Reinitialize AGP on i845 after a suspend (Charl Botha)

o Don't rserve port 0x45 on sbc60xxwdt (Anders Pedersen)

o Export elevator_init so modules can switch (Arnd Bergmann)

to no-op elevators

o Fix gmac link status reporting (Roberto Gordo Saez)

o Radeonfb update (Peter Horton,

Erik Andersen)

o Fix resource leak on error in sisfb (me)

o Fix sisfb to fail the load if no card is (me)

found

A Borland elérhetővé tette a már bejelentett
kylix 3 open edition-t


(Csak azt nem értem, mért háromszor akkora mint a trial enterprise változat)

Ahogy ígértem, itt vannak. Megszülettek a naplózó filerendszerek teljesítmény-tesztjeinek eredményei. A tesztekben a nagyobb naplózó FS-ek vettek részt (reiserfs, ext3, jfs) és mellé viszonyítási alapnak bekerült a jó öreg ext2 is. Azért ezek a journaling fs-ek kerültek bele a tesztbe, mert ezek szereplenek (többnyire) a mainline kernelben. Ha az XFS is belekerül, megismételjük a tesztet ;-)

A teszt eredményekből messzemenő következtetést nem lehet levonni. Nem tudni melyik készítő cég szponzorálja Dankot ;-) Mindenesetre a tesztek végén a ReiserFS került ki győztesen. Összesen 4-szer végzett az élen, őt követte a JFS és a végére maradt az Ext3, bár ez nem egyértelmű de azért az Ext3 kétszer akkora file létrehozási ideje elég durva volt. Viszont a JFS se egy kapkodó idegbeteg. Az Ext2-t nem érdemes összehasonlítani velük, mert az nem journaling fs.

A mérésekhez a http://h2np.net/tools/fs-bench.tar.gz eszközt használtuk. A mérések egy 2GB-os partíción folytak.

Lássuk, hogy mért Danko:

"A tesztgep: Asus A7V133A alaplap, 640Megabyte memoria (SD, 133MHz-n), Thunderbird 900@1000 CPU, Alaplapi ATA100 vezerlore csatlakoztatott Quantum LCT 30gigabyte-os vincseszter, billentyuzet :)

A tesztet single user modban hajtottam vegre, a teszparticio 2000megabyte-os volt.

A teszt kozbeni vincseszterhangrol "sajnos" nem tudok semmit, mert Dream Theater-t hallgattam. Persze audioCD-rol, mert az mp3 hatraltatt volna a tesztet. Meg kulonbenis, single user mode. "



Részletes eredményekért klikk a tovább gombra.Az eredményeket megnézheted HTML táblázat formájában itt, de készül a grafikonizált verziója is.

Lássuk az eredményeket:

Create files:

1. ReiserFS

2. Ext2

3. JFS

4. Ext3

Tar all, Change owner:

1. ReiserFS

2. Ext2

3. JFS

4. Ext3

Random access:

1. Ext3

2. Ext2

3. ReiserFS

4. JFS

Change mode:

1. Ext2

2. Ext3

3. JFS

4. ReiserFS

Random delete and create:

1. ReiserFS

2. Ext2

3. Ext3

4. JFS

Change mode again:

1. Ext2

2. Ext3

3. JFS

4. ReiserFS

Remove all files and directories:

1. ReiserFS

2. Ext3

3. Ext2

4. JFS

Mivel az új szerverünkön pureftpd mükődik, így gyorsabb volt hozzá megírni a jelszócserélő webes felületét mintsem megkeresni a neten. Az így elkészített munkámat most közkinccsé teszem, ha valakinek kell használja egészséggel. Az alkalmazás használatához szerver oldalon php és mySQL támogatás szűkséges.



Letöltés

Így néz ki

A hwsw.hu-n olvastam, hogy kijött új driver a KRYO kártyáihoz. Nézegetem. Hopp. Source TGZ? Nyílt forráskódú? Letöltöttem. És tényleg. (persze lehet, hogy félrenéztem :)Ez már xv és dpms támogatással is felruházott driver. Van benne AGP támogatás.

Lehet, hogy érdemes KYRO kártyákat venni?

Letöltés:
Source TGZ


Követelmények:



linux kernel 2.4.x or >= 2.5.8, source in /usr/src/linux.


tar zxvf powervr-2.00.20-369.tgz

cd powervr-2.00.20-369

make install

JFS Root Boot HOWTO

Paul Larson plars@austin.ibm.com

v1.0, May 22, 2001 - Copyright © International Business Machines Corp., 2001 1. Introduction

Micskó Gábor trey@debian.szintezis.hu - Hungarian Unix Portal

v.1.1, 2002. augusztus. 25 - Copyright © Hungarian Unix Portal

1. Bemutatás

2. Előfeltételek

3. Ext2 alapú filerendszer konvertálása JFS-re

3.1 Kernel fordítása JFS támogatással

3.2 JFS filerendszer készítése

3.3 A root filerendszer másolása

3.4 Végső beállítások

3.5 Reboot

4. Copyright, licenc, visszajelzés és ilyesmi

1. Bemutatás:

Ez a HOWTO leírja azt az eljárást amellyel át tudunk konvertálni egy ext2 filrendszer alapú Linux rendszert úgy, hogy az egész az IBM Journaled File System (JFS)-en fusson. A JFS-sel kapcsolatos bővebb információért és a legfrissebb letöltési lehetőségért látogasd meg a JFS for Linux web oldalt a http://www-124.ibm.com/developerworks/oss/jfs/ URL-en.

2. Előfeltételek:

Mielőtt nekilátnánk, két előfeltételnek kell megfelelned:

# Rendelkezned kell egy telepített és működő Linux rendszerrel

# Rendelkezned kell egy üres partícióval, a partíciónak 83-as típusúnak (Linux) kell lennie. Az nem számít, hogy a partíció formázva van-e vagy sem, mi majd megformázzuk JFS-re, és úgyis eltűnik róla minden, ami előtte rajta volt ;-)

Ez a dokumentum feltételezi, hogy egy nagy, egybefüggő Linux partíciód van, amelyen a root (/) filerendszered helyezkedik el, és nincsen külön a /home, /usr, stb. Nem baj ha esetleg külön vannak, viszont egy dologra figyelni kell, hogy az üres partíció amelyen a JFS filerendszer lesz elegendően nagy legyen ahhoz, hogy az egész / filerendszered elférjen rajta, módosítani tudd a /etc/fstab filet, törölni tudjál róla, vagy meg tudd változtani a becsatolások helyét ha az szükséges. Végül, a dokumentumban a root filerendszer (/) a /dev/hda5 eszközön van, és a új partíció, amelyet meg fogok formázni JFS-re a /dev/hda6-on lesz. Ez rendszer-specifikus, értelemszerűen más gépeken az ottani beállításokkal kell végezni a műveleteket.

Amit még figyelembe kell vennünk az az, hogy szükség lesz a megfelelő patchekre (hacsak nem kernel támogatást használunk, amely a 2.4.20-pre4-től a rendelkezésünkre áll), patchelnünk kell a kernel forrást, és egy kernelt kell fordítanunk JFS támogatással. Ez nem nehéz dolog, de ha még soha nem fordítottál kernelt, akkor lehet hogy nem ezzel kellene kezdened ;-)

3. Egy ext2 alapú rendszer konvertálása JFS-re

Több kereskedelmi Linux terjesztés felajánlja telepítéskor, hogy a rendszerünket JFS filerendszerre telepíthetjük. Ilyenkor nem kell mást tenni, mint kiválasztani a JFS-t, megadni a csatolási pontot (/) és a telepítő elvégzi helyettünk a szükséges feladatokat. Ez a dokumentum a meglevő ext2 alapú rendszer ``áthelyezéséről" szól.

A következő szekció leírja a szükséges lépéseket ahhoz, hogy hogyan építsünk fel egy JFS root (/) filerendszert, és hogyan bootoljuk be azt.

3.1 Kernel fordítása JFS támogatással

Töltsd le a legutolsó 2.4.x kernelt az ftp.kernel.org-ról, és a legutolsó jfs-x.y.z-patch.tar.gz-t a JFS for Linux web oldalról to /tmp könyvtárba. Csomagold ki őket egy elkülönített könyvtárba. Másold őket a /usr/src/ alá. Lépj be a kernel forrás alapkönyvtárába és patcheld meg a kernelforrást.

#cd /usr/src

#rm linux

#tar -xvzf /tmp/linux-2.4.3.tar.gz

#mv linux linux-2.4.3

#ln -s linux-2.4.3 linux

#mkdir jfs

#cd jfs

#tar -xvzf /tmp/jfs-0.3.1-patch.tar.gz

#cd /usr/src/linux

#patch -p1
#patch -p1

Konfiguráld a kernelt a make config (make menuconfig, make xconfig) segítségével, amelyik közelebb áll a szívedhez :-). A "Code maturity level options" címkével jelzett szekcióban, kapcsold be azt a menüpontot, hogy "Prompt for development and/or incomplete code/drivers." A "File systems" címkével jelzett szekcióban kapcsold be a "JFS filesystem support" stuffot. Legyél biztos abban, hogy a JFS támogatást a kernelbe fixen drótozva tetted, NEM MODULBA, mert akkor nem fogja boot időben a kernel támogatni a JFS-t (csak kisebb cselek árán, de erre most nem térek ki). Konfiguráld az egész kernelt ahogy szükséged van rá, mentsd el a konfigot, majd forgasd le a kernelt. A kernel fordítását a make dep; make clean; make bzImage parancsok kiadásával végezd (vagy ahogy tetszik, ezerféleképpen lehet) ha szükséges fordítsd le a modulokat is, make modules; make modules_install. Utána másold az új kernelt a /boot könyvtárba. Másold a System.map-ot /boot-ba.

#make dep

#make clean

#make bzImage

#cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.0-jfs

#cp /usr/src/linux/System.map /boot

Most szükségünk van a JFS programok lefordítására, (én a debian sarge rendszeremen egyszerűen kiadtam az 'apt-get install jfsutils' parancsot, de aki akarja forgassa le). Ezek azok a programok azok, amellyel a JFS filerendszert létre lehet hozni, ellenőrizni lehet, ki lehet terjeszteni a méretét, stb.

#cd fs/jfs/utils

#make

#make install

A következő lépés az, hogy módosítani kell a LILO bejegyzéseit úgy, hogy az új kernelünket bootolja be, és root (/) filerendszernek a JFS-t húzza fel. Szerkesszük a /etc/lilo.conf filet és végezzük el az alábbi bejegyzéseket:

image=/boot/vmlinuz-2.4.0-jfs

label=jfsboot

read-only

root=/dev/hda5

Futtassuk az /sbin/lilo parancsot, ahhoz hogy aktiváljuk a az új konfigurációt és rebootoljunk az új kernellel.

3.2 JFS filerendszer készítése

OK, most van egy kernelünk JFS támogatással, itt az ideje, hogy megformázzuk az üres partíciónkat JFS-re.

#mkfs -t jfs /dev/hda6

mkfs.jfs development version: $Name: v0_3_1 $

Warning! All data on device /dev/hda6 will be lost!

Continue? (Y/N) y

Format completed successfully.

5120608 kilobytes total disk space.

3.3 A root filerendszer másolása

Ez egy könnyű lépés, kevés munkát igényel a részedről, viszont ez viszi el a legtöbb időt a munka során. Először is umount-old az összes NFS, SMB, és cdrom-ot, ami esetleg mountolva lenne. Készíts egy csatolási pontot (mount point) az új JFS partíció részére, és mountold azt. Néhány dolog mielőtt másolsz: ne másold a /proc könyvtárt, viszont készíts neki egy csatolási pontot. Ha nem tudod umountolni a NFS-ed vagy cd-rom-od, emlékezz rá, hogy ezeket ne másold. Minden mást másolj át a cp -a paranccsal.

#mkdir /jfsvol

#mount -t jfs /dev/hda6 /jfsvol

#cd /

#cp -a bin etc lib boot dev home usr var [...] /jfsvol

#mkdir /jfsvol/proc

Ugyanezt a cp -ax paranccsal is el lehet végezni könnyebben, lásd a bővebb információkért a cp man oldalát.


3.4 Végső beállítások

Mielőtt rebootolnánk az új JFS partíciónkra, el kell végeznünk néhány beállítást. Először is, meg kell változtatnunk a /etc/fstab bejegyzést a root partíciónkhoz. Emlékezz! hogy az fstab file amin dolgoznunk kell a /jfsvol/etc alatt van, hiszen az lesz az új root partíciónk. Tehát szerkeszd ezt a filet, és írd át a root partícióhoz szóló bejegyzést. Valahogy így:

LABEL=/ / ext2 defaults 1 1

Ezt kell megváltoztatnunk így:

/dev/hda6 / jfs defaults 1 1

Editáld a /etc/lilo.conf-ot úgy, hogy a root partíciódra mutasson. Valami ilyesmit kell csinálnod:

default=jfsboot2

...

image=/boot/vmlinuz-2.4.0-jfs

label=jfsboot2

read-only

root=/dev/hda6

Figyelj arra, hogy futtasd a'/sbin/lilo'-t újra, mielőtt rebootolnál.

3.5 Reboot

Gratulálok! Ha követted a lépéseket, akkor a rendszered tisztán JFS-en fut. Hogy ellenőrizd ezt, írd be 'mount' és ellenőrizd a kimenetet:

/dev/hda6 on / type jfs (rw)

none on /proc type proc (rw)

none on /dev/pts type devpts (rw,gid=5,mode=620)

Ha minden jól müködik, akkor a régi partíciódat megformázhatod JFS-re, és visszaállíthatod a rendszered az eredeti partícióra. Vagy csinálhatsz amit kedved tart. Ha rám hallgatsz azt csinálsz amit akarsz ;-).



4. Copyright, licenc, visszajelzés és ilyesmi:



JFS Root Boot HOWTO

Paul Larson plars@austin.ibm.com

v1.0, May 22, 2001 - Copyright © International Business Machines Corp., 2001 1. Introduction

Micskó Gábor trey@debian.szintezis.hu - Hungarian Unix Portal

Több mint egy éve használok naplózó filerendszert az otthoni munkaállomásomon. Egy évvel ezelőtt amikor eldöntöttem, hogy lecserélem az ext2 filerendszeremet, és valami journaling FS után nézek, igazából nem sok választásom volt. Akkoriban az elérhető naplózó FS-ek az SGI-féle XFS, a SuSE által szponzorált ReiserFS, és a beta állapotú IBM-es JFS volt. Ezek közül egyetlen volt megtalálható az akkori kernelben, a többit bele kellett patchelni. Ez az egy a ReiserFS volt. Így nekiálltam, lementettem a filerendszerem, készítettem egy ReiserFS filerendszert, és használtam egy éven keresztül minden probléma nélkül. Bátran ajánlhatom mindenkinek, mert egy gyors, helytakarékos, korszerű journaling FS kap az, aki arra szánja el magát, hogy ReiserFS-t használ. Pár nappal ezelőtt megjelent a 2.4.20-pre4 prepatch kernel. Ez a kernel már tartalmazza az IBM JFS támogatást. Egy hirtelen ötlettől vezérelve úgy döntöttem, hogy lecserélem a jól bevált ReiserFS-t JFS-re. Hogy miért? Mert a ReiserFS túl jól működött ;-). Rendszerint a fejlesztői dolgokat használom, na nem azért mert én ``poweruser" vagyok, hanem mert szeretem kipróbálni az új dolgokat, szeretem végigszenvedni a fejlesztés lépéseit, esetenként bugreportolni, stb. Ebben az sem tántorít vissza, ha néha backupból vissza kell állítani a rendszerem. (Ilyenre az elmúlt 2-3 évben egyszer került sor, egy hibás 2.5-ös kernel IDE kód miatt.)



Szóval JFS. Miért is van szükség a JFS-re? Egyáltalán miért nem jó nekem a hagyományos ext2 filerendszer?



A legfőbb indok az, hogy a manapság kapható nagy kapacitású HDD-ket igazából nem lehet hatákonyan használni már ext2 filerendszerrel. Az ext2 filerendszer egyik szükségszerű velejárója az FSCK. Elég egy áramszünet, és a file system chechker már el is indul a gépünkön boot időben. Akinek nagy winchestere van az tudja, hogy egy 80GB-os HDD-n mennyi ideig fut az FSCK. Ez az idő a HDD-n levő adatok mennyiségétől függően több perc, egy jól megtömött filerendszer esetén akár több óra is lehet. Ezt elkerülendő, és más technikai okoból is kifejlesztettek ún. journaling, azaz naplózó filerendszereket. Ezek lényege röviden, mindenfajta technikai hókusz-pókusz nélkül az, hogy rendelkeznek egy ún. journaling-device-szal, egy naplófile-lal amelybe bejegyzésre kerülnek a filerendszeren történt változások. Ezek a bejegyzések rettentő gyorsan követik egymást. Egy esetleges rendszer osszeomlásnál a bootkor az FSCK-nak nem kell az egész filerendszert ellenőriznie, elegendő csak ellenőriznie a journal fileban levő legutolsó bejegyzések által mutatott fileokat. Így az FSCK ideje drasztikusan lecsökken. Ami azt jelenti, hogy egy 80GB-os filerendszeren egy 70%-os telítettségnél ReiserFS filerendszer RO-ra muntolva: a reiserfsck kb. 15-20 másodperc alatt végez. Gondoljuk el, hogy egy forgalmas weboldalnál mekkora kiesés lehet ext2 filerendszert alkalmazva, mondjuk egy 200-300GB-os lemezterületet ellenőrizni. Akár órákig is eltarthat. Ezt pedig az E-Business világában senki nem tudja bevállalni.



A JFS-ről csak jót lehet olvasni az IBM oldalnán (naná, ők fejlesztették ;-)). Lássuk mit tud: a JFS kimondottan nagy terhelésű fileszerverek, adatbázis szerverk filerendszerének készítették, tervezték, jelenleg az IBM enterprise kategóriájú szerverei használják. Az IBM open sourceszé tette. A JFS egy teljesen 64bites filerendszer. A minimális JFS partíció mérete 16MB. A maximális fileméretet tekintve 512 terrabyte-tól 4 petabyte-ig terjedhet. Azt hiszem a 160GB-os otthoni rendszeremnek ez bőven megfelel.



Ennyit az okoról, ha érdekel hogyan váltottam ReiserFS-ről JFS-re olvasd el JFS root boot HOWTO-t (egy cikkel feljebb). A teljesítménytesztek folynak, eredményekről később.

Köztudott dolog, hogy a Linux 2.5 kernel fejlesztése a BitKeeper nevű ``version control system"-ben folyik. Linus döntött úgy, hogy a Linux kernel fejlesztői forrását ebben tárolják, a CVS-sel szembem. Ezért többen is támadták Linust, többek között RMS. RMS kijelentette, hogy a Linux nem tekinthető 100%-ban free szoftvernek, mert a fejlesztése egy nem free rendszerben folyik.

Larry McVoy - a BitKeeper első embere - egy levelet küldött az LKML-re, melyben bejelenti, hogy megváltozott a BK liszence:

"Nem GPLizáltuk, csak néhány korrekciót hajtottunk végre a licenszen, de a változtaások fejlődések voltak, nem visszafejlődések" - írta McVoy.

A licensz-beli változásokat elolvashatod itt.

Kapcsolódó hírek:

BitKeeper, avagy Linus mégis enged?

Eric S. Raymond: A Linux kernelpatchelés krízisben van

ReiserFS patchek, a csapat a BitKeeper-t fogja használni

Richard Stallman a BitKeeperről

Interjú: Larry McVoy a BitKeeper alkotója

WTF: A Linux nem ingyenes? A Debian új kernel után nézhet?

Linux: Bitkeeper CVS gateway

McVoy levele:From: Larry McVoy

To: linux-kernel@vger.kernel.org

Cc: bitkeeper-announce@work.bitmover.com

Subject: RFC: BK license change

Date: 24 Aug 2002 02:39:35 +0200

No, we're not GPLing it but we are making a few adjustments and wanted to make sure that it was an improvement, not a regression, in the eyes of the free users. Sorry for the intrusion, I'll be as brief as possible.

You can read the new license at http://www.bitkeeper.com/bkl.txt but I'll summarize the changes here.

3(a) Propagation to openlogging.org. The old license insisted that you log your changes within 7 days; several people pointed out that they are spending their dotcom dollars sitting on an island hacking the kernel and they may not have connectivity every 7 days. Or something. We upped the limit to 21 days, that should be enough, I have to believe that you check your mail every three weeks if you are doing work.

3(c) Maintaining Open Source. Our intent was that the free use of BitKeeper was for the purpose of helping the open source community; it was not to provide commercial users a free product. We have had a number of cases where managers up to VPs have told their engineers "just don't put anything useful in the checkin comments and then we can use it for free". Not what we had in mind. So we're adding a clause which says that we reserve the right to insist that you make your repositories available on a public port within 15 days of the request.

We understand that lots of legit open source users have very good reasons for not wanting their changes made public, e.g., they are working on a security fix. We are absolutely not going to ask these sorts of repositories be forced out in the open and if you are concerned about that we can work out some sort of written agreement to that effect. We're very much committed to supporting open source development, in particular the Linux kernel and even more specifically Linus, he's a critical resource.

The only people we're going after are those people who are clearly not part of the open source community. We thought about saying we would only enforce this if they were working on source which did not have an open source license and rejected it for the following reason: there are commercial companies working on open source, using BitKeeper to do so, and not sharing their changes for as long as they can to get a competitive edge in the marketplace. There is nothing wrong with that under the terms of the GPL, but we don't have to support what we view as commercial activity for free. Open means open, it's about sharing, not money, in our opinion.

It's a hard nut to crack, you can't just say "it's free if you are doing everything out in the open" because there are legit reasons for hiding. There also commercial reasons for hiding and our view is that if that is what you are doing, you should be paying for the tools. BK is free as a way to help people help each other.

4.4. Remove the $20,000 support clause. We had a clause that said that we could shut you down if you cost us more than $20K in support. This was a widely hated clause and we're aware of that. It was there as a way to try and shut down those people who were really commercial. Since the previous change will effectively do that, we don't need this clause. That removes the fear that we'll shut down bkbits or the kernel's use of BK.

That's it on the licensing stuff. Since I'm here, here's some BK status.

We're in discussions with a very Linux friendly hosting service (4000 Linux servers hosted) to move bkbits.net and openlogging.org to their site in exchange for BK licenses. This should make the bkbits.net service have more bandwidth and the benefit of a an extremely well connected and well run hosting environment. We don't need the bandwidth, BK is

super stingy with bandwidth, but it's cool to have bkbits.net in an air conditioned, UPSed, multi peered environment instead of my office. We're psyched about this, it's a good thing.

We're working on closing the first commercial deal which we can tie to the use of BK by the kernel team. If this actually happens, I'm going to take $25K of the deal and "give" it to Linus as "BK bucks" which he can spend. What means is that he has $25K to spend on BK features that he wants. This is above and beyond stuff that we're doing already, it's a way

to give him the power to insist that we do some work that we wouldn't do otherwise. In general, we'd like to make a policy of doing this sort of thing. To date, we can't credit the open source use of BK with any commercial business. If that changes, that's good for us but it should also be good for the kernel.

--lm

Open Source programokat használva, csökkenhetnek a programozói állások a szoftver cégeknél. Ezzel egy időben viszont a szoftverekre fordított pénzek szabadulhatnak fel, amelyet az IT ipar más területein tudnak a cégek felhasználni.

Az Open Source programokat érő kritikák közül az egyik legnagyobb az, hogy a szoftverfejlesztők, és szoftver óriás cégek szerint az OS programokkal nem lehet pénzt keresni. A kritikák áltaában rámutatnak, hogy mi is történt a LinuxCare-rel, vagy a VA Software-rel és másokkal. Általában a kritikusok megjegyzik, hogy a Microsoft 2 nap alatt keres annyit, mint az összes Linux cég egyben. Általában elmondható, hogy a Linux azoknak a cégeknek hoz pénzt akik használják, és nem azoknak akik eladják. A szoftver cégek nagy árréssel dolgoznak, egyesek szerint a Microsoftnál ez eléri a 30%-ot.

Mike McCune - az osOpinion.com írója - szerint néhány ponton tévednek az Open Source programok kritikusai. Megpróbálta összeszedni, hogy szerinte hol is lehetne pénzt keresni az OS programokkal. Az eszmefuttatását elolvashatod itt.

Stephen Tweedie - a szerzője és karbantartója az ext3 journaled filerendszernek - patcheket küldött a 2.4-es kernelbe való beillesztés céljából Marcelo Tosattinak. Ahogy megjegyezte: "ezek a patchek tartalmazzák a jelenlegi legnagyobb, legfrissebb változásokat az ext3 filerendszer kódban.". Az összes patch tesztelve lett az ext3 CVS tree-ben. (Stephen Tweedie eredetileg a 2.2-es kernelekhez írta az ext3 filerendszert. Csak később került portolásra a 2.4 kernelbe. A portolást Peter Braam, Andreas Dilger és Andrew Morton végezték, Stephen segítségével. Az ext3 filerendszer a 2.4.15 kernelben lett belolvasztva a 2.4 mainline kernelbe.)

Az első patch amely az ext3 filerendszer kódhoz készült, segít "robusztusabbá tenni a dump(8) vagy a tune2fs(8) munkálatokat a block eszközökkel ``live" filerendszeren." A második patch fixálja a "a race window in buffer refiling" hibát.

Stephen Tweedie levelei:From: Stephen Tweedie

To: Marcelo Tosatti, linux-kernel-mailing-list

Subject: [Patch 0/2] 2.4.20-pre4/ext3: ext3 dirty buffer management

Date: Fri, 23 Aug 2002 00:19:34 +0100

Hi Marcelo,

This patch set contains the biggest recent change to ext3: a change to the way it deals with other dirty buffers in the system, making it robust against things like dump(8) or tune2fs(8) playing with the block device on a live filesystem. This patch has been in ext3 CVS for some time now.

I'll follow up with the other smaller fixes and tweaks in the next batch.

From: Stephen Tweedie

To: Marcelo Tosatti, linux-kernel-mailing-list

Subject: [Patch 1/2] 2.4.20-pre4/ext3: Handle dirty buffers encountered unexpectedly.

Date: Fri, 23 Aug 2002 00:19:36 +0100

Ext3's internal debugging has always assumed that it was illegal for there to be parallel IO on a buffer-head which it is trying to modify. That's reasonable --- if there is an IO collision, we end up with IOs hitting disk out-of-order wrt the journal, so we lose recovery guarantees.

However, there are two cases where the test is a little over-zealous. If user space is performing inherently non-transactional writes (eg. tune2fs adding a label to a live filesystem and writing to the buffered device superblock location) then we can hit the ext3 assertion.

More seriously, since 2.4.11 the page cache can lock a buffer_head for read even if the bh is already under journal control. The tune2fs bug is very rare: there have been no reports of it in Bugzilla or ext3-users lists, and only one on 2.5 on linux-kernel. But now, a dump(8) on a live filesystem

can also give rise to the same condition, and in testing, dump + fs activity reproduces the assertion-failure VERY rapidly.

This patch changes the jbd get-write-access code to take the buffer_head lock before testing the uptodate and dirty state of a bh, and relaxes the handling of unexpectedly-dirty buffers to be a printk warning, not a fatal error. The lock will cure the dump(8) interaction, and the warning means that we will still spot out-of-order writes, while not taking the whole kernel down if we collide with a tune2fs(8).

The patch also removes a small potential hole in the recovery guarantees. It is not safe for a transaction to steal buffers from checkpoint mode until after that transaction has committed. Otherwise, a reboot at the wrong moment might

find the old copy of the buffer in the journal had been removed from the recovery set before the new copy was written.

[patch 1]

From: Stephen Tweedie

To: Marcelo Tosatti, linux-kernel-mailing-list

Subject: [Patch 2/2] 2.4.20-pre4/ext3: Fix "buffer_jdirty" assert failure.

Date: Fri, 23 Aug 2002 00:19:36 +0100

There was a race window in buffer refiling where we could temporarily expose the journal's internal BH_JBDDirect flag as BH_Dirty, which is visible to the rest of the VFS. That doesn't affect the journaling, because we hold journal_head locks while the buffer is in this transient state, but bdflush can see the buffer and write it out unexpectedly, causing ext3 to find the buffer in an unexpected state later.

The fix simply keeps the dirty bits clear during the internal buffer processing, restoring the state to the private BH_JBDDirect once refiling is complete.

Ahogy a múlt héten írtam a 2.5-ös fejlesztői kernel a 2.4 kernelek előre portolt IDE kódját fogja használni, miután az IDE kód maintainer Martin Dalecki nem folytatja a 2.5 IDE munkát. Több levél is érkezett az LKML-re, amelyben tudakolták, hogy hogyan is tovább. Paul Bennett küldött egy levelet a fent említett levlistára, melyben a jövőről érdeklődött: "Mi a célja a 2.5-nek? Mi az implementációs terv? Mik a problémák a 2.4-ben, és hogy lesznek ezek javítva a 2.5-ben, stb?"

A Linus korábban kijelentette, hogy a lehetséges pályázók egyike Alan Cox, aki majd kibogozza az IDE kódot: "Jelenleg úgy fest a mostani állás szerint, hogy Alan lesz az aki az IDE kódon fog dolgozni, ami nyilvánvalóan nagyszerű dolog. Én csak azon csodálkozom, hogy bírja (Ő tart karban számos IDE buglistát, fixálja a bugokat évek óta, szóval reménykedhetünk)" - mondta Linus.

Cox válaszolt Bennett levelére, melyben leírta, hogy tervei szerint az IDE kód ``megszerelése" négy fázisban fog zajlani: "Ez lehetővé teszi nekünk, hogy egy szolid, stabil IDE kódot tarthassunk magunknál a fejlesztés alatt" - írta Alan Cox. Cox megjegyezte, hogy az első fázis már szinte készen van.

Akit konkrétan érdekelnek a részletek, klikk a ``tovább"-ra.From: Paul Bennett

Subject: 2.5 IDE Whitepaper?

Date: Wed, 21 Aug 2002 14:38:07 -0400

I am looking for documentation regarding the 2.5 IDE rewrite. For example: What are the goals for 2.5. What is the implementation plan? What were the problems in 2.4, and how will they be fixed in 2.5, etc?

Thanks.

-- Paul

From: Jeff Garzik

Subject: Re: 2.5 IDE Whitepaper?

Date: Wed, 21 Aug 2002 19:32:44 -0400

I wish :)

I imagine it will happen like most things happen, Linus describes his ideas and goals and wishes in a few lkml posts, and eventually something

like it happens :)

From: Alan Cox

Subject: Re: 2.5 IDE Whitepaper?

Date: 22 Aug 2002 00:51:52 +0100

I can try, my working list approximates this (ignoring the 2.5

porting/block I/O stuff which is a chapter in itself)

Phase #1 (mostly complete)

Merge Andre's current code [DONE]

Remove all the bogus code from the PCI drivers [90% DONE]

Move all the drivers seperate from the core code [DONE]

Migrate the PCI drivers to a registration API and allow insmod

Fix bugs arising from the first bits of phase 1

Phase #2

Deal with insmod of a device currently running as legacy

Fix up the locking ready to allow rmmod of a pci driver

Allow rmmod and hotplug at the controller level

Phase #3

Complete splitting setup-pci functions into smaller bits of code

and replace deep magic and callbacks with functions called from each driver. Get all the if device==foo out of the PCI code paths

Phase #4

Do something about the ide_register/unregister end of the world and legacy chipset stuff. The PPC folks may tackle this in advance

Get us to the point we can foo = ide_attach(); ide_remove(foo) for arbitary interfaces

And then (when the setup is turned the right way out and not before) begin looking at turning the actual block I/O engine the right way out. (That is driver calls helpers not midlayer and magic)

That should allow us to keep solid stable IDE along the way.

Készül a népszerű Opera böngésző legújabb egész számra végződő kiadása - olvashatjuk a The Register oldalain. Az új verzió a 7-es verziószámot viselni, és a fejlesztők elmondása alapján egy jelentős újraírás eredményeként kaphatjuk majd meg a szoftvert. Az Opera 7 heteken belül megjelenhet, természetesen a megjelenés függ a bugok számától. A böngésző 7-es verziója először window$ platformra jelenik meg (szokás szerint), és csak utána adják ki Linuxra és egyéb Unix platformra. Ezt a Linux fejlesztők túlterheltségével magyarázzák. A Linux fejlesztések lassabban haladnak most mert a beágyaztott fejlesztésekre koncentrálnak (pl. Opera for Sharp Zaurus), hiszen most ez a terület fizet a legjobban a böngésző iparban.Pål Hvistendahl, az Opera kommunikációs igazgatója szerint a fejlesztések közben a fokozottan fókuszálnak a standardok implementálására, kiváltképp a DOM (Document Object Model) megvalósítására. Ez egy nagy előny lesz a beágyazott területen dolgozó fejlesztőknek. A célok között szerepel még a sebesség növelése a felhasznált erőforrrások csökkentése mellett.

Opera 7 tartalmazni fog egy új layout motort is, és Hvistendahl ígéretet tett egy beépített e-mail kliensre is.

Csomag : irssi-text

Sebezhetőség : denial of service

Probléma-típus : távoli

Debian-specifikus: nem

BugTraq ID : 5055

Az irssi IRC kliens sebezehtő az ún. DoS, azaz a ``denial of service" típusú támadáassal. A probléma akkor jelentkezik, amikor a felhasználó belép egy olyan csatornára amelyen nagyon hosszú topic van belállítva. A topicban levő bizonyos stringek hatására az irssi lehalhat.

A probléma javítva van a 0.8.4-3.1 verziójú csomagban a jelenlegi stabil terjesztéshez (woody), és a 0.8.5-2 verziójú csomagban az unstable terjesztéshez (sid). A régebbi stabil terjesztés, a potato nem érintett ebben a hibában.Javasoljuk frissítsd az irssi csomagot és indítsd újra az IRC kliensed.

Martin Schultze levele a debian-security-announce listán.

A frissítésrõl szóló FAQ-nk.

Privát megjegyzés: Sose hagyj bent ellenőrizetlenül irc klienst, és főleg ne irc-z root-ként! :-)

A NetCraft egy online szerver uptime figyelő program, amely havi szinten statisztikát készít a világ webszervereinek összetételéről. Nem volt ez máshogy ebben a hónapban sem, lássuk az eredményeket: az augusztusi felmérés szerint 35,991,815 site volt regisztrálva a NetCraftnál, ez alacsonyabb szám mint a júliusi 37.2 millió és a júniusi 38.8 millió regisztrált site. Az webszerverek összetétele sem okozhat nagy meglepetést, hiszen a legnagyobb játékosok az Apache, Microsoft, Zeus, és iPlanet maradtak. A százalékos megoszlás pedig: 63.51%, 25.39%, 2.13%, és 1.35%. A összes gyártók adata felfelé mozdult el, kivéve a Microsoftot. Az NT alapú szerverek NT 25.64%-ot értek el, ez csökkenést mutat az előző hónap 32.11%-os részvételével szemben. Az Apache-specifikus szerverek a 65.14%-os részvételi aránnyal növekedést mutatnak, a júliusi 59.18%-kal szemben. A Macintosh-specifikus szerverek részvételi aránya minimálisan növekedett 0.32%-ról 0.33%-ra.

Részletes értékelés itt.

A Netscape folytatja a 4.x terméksorozatát a 4.8-as kiadással. Ember nem hitte volna, hogy ezt fejlesztik még. És szerintem ember nincs már aki ezt használja. De sebaj, ha valakinek kellene akkor letöltheti innen.

A változásokért olvasd el a release notes-t.