FreeBSD

Számos operációs rendszer/disztribúció értékelést olvashattunk már az elmúlt években. Sajnos ezek többnyire valamelyik felkapott rendszert elemezték ki, pl. a Red Hat-et, SuSE-t, Mandrake-t, stb. Aztán mostanában megjelentek a "kevésbé felhasználóbarát" OS leírások is, mint a Slackware vagy a Debian, de mint a fehér holló olyan ritka volt eddig a BSD rendszereket elemző leírás. Most megjelent egy norvég Linux felhasználó és fejlesztő tollából származó írás, amely a FreeBSD 5.0-át veszi közelebbről szemügyre.

Az írást elolvashatod itt.

Peter Wemm levele szerint hozzájutott egy x86-64-es géphez. Az első eredményekről rögtön be is számolt.A gépen képes volt elindítani mind a 32, mind a 64 bites kernelt. A támogatás Peter elmondása szerint egyelőre meglehetősen döcögős, de semmiképpen sem reménytelen :)

Aki figyelmesen megnézi a dmesg kimenetet, láthatja, hogy a gép 3,14 MHz-es. Peter elmondta, hogy ennek az oka az, hogy nem beszélhet a sebességről, így átírta a valódi értéket a Pi-re. A gép egyébként 32 bites módban (FreeBSD/i386) gyönyörűen és meglehetősen jó sebességgel működik.

Kapcsolódó oldalak:

dmesg kimenet

Perforce Hammer repo

Mike Barcroft néhány rég várt módosítást eszközölt a FreeBSD -CURRENT ágában a jail megvalósításban.A módosítások:

• új sysctl (security.jail.list), amely az éppen aktív jaileket tartalmazza
• jls(8) parancs, amely a fentit felhasználva az aktív jaileket listázza ki
• jexec(8) parancs, amely egy már futó jailben indít új processzt
• -j opció a killall(1) parancshoz, amelynek segítségével egy adott jailben futó összes program leállítható
• -i opció a jail(8) parancshoz, amely egy új jail indításakor kiírja annak azonosítóját (ID)

Mike írt pár sort arról is, hogy miként működik ez a valóságban:

sol# jail /tmp/jail localhost 127.0.0.1 /bin/sh &

[1] 19114

sol# jail /tmp/jail localhost 127.0.0.1 /bin/csh &

[2] 19139

[1] + Suspended (tty input) jail /tmp/jail localhost 127.0.0.1 /bin/sh

sol# jls

JID IP Address Hostname Path

2 127.0.0.1 localhost /tmp/jail

1 127.0.0.1 localhost /tmp/jail

[2] + Suspended (tty input) jail /tmp/jail localhost 127.0.0.1 /bin/csh

sol# jexec 2 /bin/ps -auxww

USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND

0 19139 0.0 0.1 1268 708 p4 TJ 3:09AM 0:00.03 /bin/csh

0 19217 0.8 0.1 640 312 p4 R+J 3:09AM 0:00.01 /bin/ps -auxww

sol# jexec 1 /bin/csh

%ps -auxww

USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND

0 19114 0.0 0.1 872 444 p4 TJ 3:08AM 0:00.02 /bin/sh

0 19318 0.8 0.2 1504 1200 p4 SJ 3:09AM 0:00.04 /bin/csh

0 19331 0.0 0.1 640 440 p4 R+J 3:09AM 0:00.01 ps -auxww

%exit

sol# killall -KILL -j 2

[2] - Killed jail /tmp/jail localhost 127.0.0.1 /bin/csh

sol# killall -KILL -j 1

[1] + Killed jail /tmp/jail localhost 127.0.0.1 /bin/sh

sol# jls

sol#

Néhány nappal ezelőtt az OpenBSD pf-jét (packet filter) sikeresen portolták FreeBSD 5.0-ra. Most megjelent egy portolási, telepítési és tesztelési útmutató ehhez a mókához. Az útmutatót megtalálod itt.

Dru Lavigne előző cikkében a tripwire-t ismertette, amely egy hatékony program arra, hogy megvizsgáljuk rendszerünket, hogy nem került-e bele "oda nem illő" program. Például rootkit (korábbi cikk: 1, 2, 3) vagy esetleg nem cserélték-e ki valamelyik gyakran használt programunkat (top, ls, ps, stb.) valamilyen backdoor-ral ellátott programra (gyakori, és kedvelt eljárása az a crackereknek, hogy a sűrűn használt programokat "megpatkolják" egy hátsó bejárattal, és azt lecsererélik a megtámadott rendszeren. Ebből a gyanútlan adminisztrátor semmit nem vesz észre, mert a program funkcióját továbbra is ellátja, maximum a mérete, és a file ellenőrőösszege (checksum) az, ami árulkodó lehet. az ilyen programok felderítésére hatékony eszköz a tripwire). Dru ezen a héten további integritás-ellenőrző programokat ismertet. Ezek a programok a aide és a yafic. Ezen kívül szó esik még a rendszerben megbúvó DDoS programok felfedezéséről is (trinoo, tfn, stacheldraht).Dru Lavigne egy hálózati ismeretek oktató tanárnő, instruktor egy magániskolában Kingstonban (ON). Az a hír járja róla, hogy a célja az, hogy minél több operációs rendszer tudjon bootolni egyszerre a tesztgépén. 1997-ben egy bug után nyomoztott az Interneten, a Yahoo keresője a FreeBSD oldalára vetette, azóta megszállott FreeBSD felhasználó. Szabadidejében TCP/IP adminisztációs könyveket és RFC-ket olvas.

A cikket megtalálod itt.

A FreeBSD-s Murray Stokely bejelentette a FreeBSD 4.8 publikus megjelenését, azaz a FreeBSD-release jelző már igaz rá. A kiadás olyan új dolgokat tartalmaz, mint a kezdeti Firewire támogatás, szupport az Intel egyes processzoraiban nemrég felbukkanó HyperThreading-hez, stb.

Email bejelentés:From: Murray Stokely murray@freebsdmall.com

To: announce@FreeBSD.org

Date: Thu, April 3, 2003 10:43 pm

Subject: [FreeBSD-Announce] FreeBSD 4.8 Now Available

--------------------------------------------------------------------------------

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

I am happy to announce the availability of FreeBSD 4.8-RELEASE, the latest release of the FreeBSD -STABLE development branch. Since FreeBSD 4.7-RELEASE in October 2002, we have made conservative updates to a number of software programs in the base system, dealt with known
security issues, and added initial support for Firewire,
HyperThreading, and other new hardware technologies.

For a complete list of new features and known problems, please see the release notes and errata list, available here:

http://www.FreeBSD.org/releases/4.8R/relnotes.html

http://www.FreeBSD.org/releases/4.8R/errata.html

This release does not include all of the new technologies that were introduced with FreeBSD 5.0 in January. FreeBSD 4.X releases offer a more conservative platform than FreeBSD 5.0 at this time. For more information about the distinctions between FreeBSD 4.X and 5.0, or for general information about the FreeBSD release engineering activities, please see:

http://www.FreeBSD.org/releng/

Availability

- ------------

FreeBSD 4.8-RELEASE supports the i386 and alpha architectures and can be installed directly over the net using the boot floppies or copied to a local NFS/FTP server. Distributions for the i386 are available now. As of this writing, the final builds for the alpha architecture are in progress and will be made available shortly.

Please continue to support the FreeBSD Project by purchasing media from one of our supporting vendors. The following companies have contributed substantially to the development of FreeBSD:

FreeBSD Mall, Inc. http://www.freebsdmall.com/

Daemonnews, Inc. http://www.bsdmall.com/freebsd1.html

Each CD or DVD set contains the FreeBSD installation and application package bits for the i386 ("PC") architecture. For a set of distfiles used to build ports in the ports collection, please see the FreeBSD Toolkit, a 6 CD set containing extra bits which no longer fit on the 4 CD set, or the DVD distribution.

If you can't afford FreeBSD on media, or just want to use it for

evangelism purposes, then by all means download the ISO images. We can't promise that all the mirror sites will carry the larger ISO images, but they will at least be available from:

ftp.FreeBSD.org

ftp12.FreeBSD.org

ftp14.FreeBSD.org

ftp.au.FreeBSD.org

ftp.es.FreeBSD.org

ftp2.de.FreeBSD.org

ftp4.de.FreeBSD.org

ftp7.de.FreeBSD.org

ftp.tw.FreeBSD.org

ftp6.tw.FreeBSD.org

FreeBSD is also available via anonymous FTP from mirror sites in the following countries: Argentina, Australia, Brazil, Bulgaria, Canada, China, Czech Republic, Denmark, Estonia, Finland, France, Germany, Hong Kong, Hungary, Iceland, Ireland, Japan, Korea, Lithuania, the Netherlands, New Zealand, Poland, Portugal, Romania, Russia, Saudi

Arabia, South Africa, Slovak Republic, Slovenia, Spain, Sweden, Taiwan, Thailand, Ukraine, and the United Kingdom.

Before trying the central FTP site, please check your regional

mirror(s) first by going to:

ftp://ftp..FreeBSD.org/pub/FreeBSD

Any additional mirror sites will be labeled ftp2, ftp3 and so on.

More information about FreeBSD mirror sites can be found at:

http://www.FreeBSD.org/doc/en_US.IS...irrors-ftp.html

For instructions on installing FreeBSD, please see Chapter 2 of The FreeBSD Handbook. It provides a complete installation walk-through for users new to FreeBSD, and can be found online at:

http://www.FreeBSD.org/doc/en_US.IS...ok/install.html

Acknowledgments

- ---------------

Many companies donated equipment, network access, or man-hours to finance the release engineering activities for FreeBSD 4.8 including The FreeBSD Mall, Compaq, Yahoo!, Sentex Communications, and NTT/Verio.

In addition to myself, the release engineering team for 4.8-RELEASE includes:

Scott Long scottl@FreeBSD.org Release Engineering

Bruce A. Mah bmah@FreeBSD.org Release Engineering, Documentation

Robert Watson rwatson@FreeBSD.org Release Engineering, Security

Wilko Bulte Release Engineering, Alpha arch

David O'Brien Release Engineering, Alpha arch

John Baldwin Release Engineering

Ruslan Ermilov Release Engineering

Kris Kennaway Package Building

Will Andrews Package Building, KDE

Jacques A. Vidrine Security Officer

Joe Marcus Clarke GNOME Integration

Julian Elischer Release Testing

Please join me in thanking them for all the hard work which went into making this release. Many thanks are also due to the FreeBSD committers (committers@FreeBSD.org), without whom there would be nothing to release, and thousands of FreeBSD users world-wide who have contributed bug fixes, features, and suggestions.

Enjoy!

Murray Stokely

(For the FreeBSD Release Engineering Team)

-----BEGIN PGP SIGNATURE-----

iD8DBQE+jRqatNcQog5FH30RAuLUAKCxKfoRyBbqwm4QYIkLq+

xZkCupqQCgvjFp

aLZzPDweEFXkcoVMgviWcU8=

=Jw+z

-----END PGP SIGNATURE-----

A FreeBSD 4.8-nak március 24-én kellett volna megjelennie, de - a FreeBSD csapattól nem szokatlanul - sajnos csúszik a kiadás. A csúszás okairól Bruce A. Mah ír legújabb levelében. Az egyik fő ok, hogy az MFSROOT kernel nem fér rá egy 1440-es floppyra, és ez további bonyodalomhoz vezet. Bruce szerint ez az ok - amit a RE team megjelölt a csúszás indokaként - csak egy április 1-i fréfa lehet. Csípős hangvételű leveléből azt jöhet le az olvasónak, hogy megint flame-ek lassítják a fejlesztést. Főleg a PS-t érdemes elolvasni a levél alján. Bár ahhoz, hogy tisztán lássunk meg kellene hallgatni a másik oldalt is (RE team). Ők egyelőre nem nyilatkoztak a csúszásról publikusan.Date: Wed, 2 Apr 2003 16:23:25 -0800

From: "Bruce A. Mah" bmah@freebsd.org

To: freebsd-stable@freebsd.org

Subject: 4.8-RELEASE status

--jI8keyz6grp/JLjh

Content-Type: text/plain; charset=us-ascii

Content-Disposition: inline

Hi--

A number of you have been (rightfully) wondering what's up with the i386 4.8-RELEASE. Here's the current state:

The files that are as of this moment tagged as RELENG_4_8_0_RELEASE can't be used to build a release because the MFSROOT kernel (that goes on the kern.flp) overflows a the size of a 1440K floppy disk.

This bug was masked by another problem that happened to be present on the machines used by the RE team to build releases...namely, that they didn't have the cvsroot-all collection in their local repositories. To make a long story short, the $FreeBSD$ tags didn't get expanded in the source files, thus (I am not making this up) causing the MFSROOT
kernel to be just a *little* bit smaller so that it could fit on a

floppy. I think this was the world's April Fool's joke to the RE

team.

We're currently trying to fix this by finding some other driver we can move to a module on the mfsroot.flp image (or maybe just eliminate). After we finish some tests, we'll need to commit whatever change is required, re-tag the affected files, and then rebuild the base system.

I'm not in a position to comment on a timeline for these happenings.

Thanks for your continued patience!

Bruce.

PS. This may sound rude, for which I apologize in advance: The less time that the RE team has to spend replying to various emails (particularly those that are not relevant to the immediate goal of shipping 4.8-RELEASE), the faster the release is probably going to be finished.

--jI8keyz6grp/JLjh

Content-Type: application/pgp-signature

Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+i3792MoxcVugUsMRAsWKAKD7ZZ2byt7SRC5yCD10AX

f0OyBXsQCdHWe4

vJqPvL44qDJQOhKU82Wu5sg=

=xgSt

-----END PGP SIGNATURE-----

--jI8keyz6grp/JLjh--

Úgy tűnik, beadták a derekukat a FreeBSD core team tagjai, mivel a -CURRENT ágba bekerült az x86-os rendszereken, lapozással működő PAE támogatás (Physical Address Extension), amely a 32 bites címzést bővíti ki, így 4 GB helyett 64 GB memóriát képes kezelni XT-ből származtatható szuperszerverünk.A megvalósítást Jake Burkholder adta hozzá a forráskódhoz.

Jake hozzátette, hogy egyelőre csak az ahc, ata és em meghajtókkal próbálta ki a PAE opciót, illetve ezeket leszámítva azokkal fog működni, amelyek nem használnak dma-t, vagy a FreeBSD busdma mechanizmussal működnek, illetve képesek 64 bites címzésre.

Azok a meghajtók, amelyek nem képesek a fentiek szerint működni, adatkorrupciót okozhatnak azokban a gépekben, amelyekben több, mint 4 GB memória van.

A PAE használata mellett a kernel modulokat is el kell felejteni egyelőre, mivel minden modulnak, amely a pmap_mapdev, pmap_kextract, vagy a vtophys hívást használja, statikusan kell a kernelben lennie. Ebbe beleértendő az ACPI is (amit modulként szokás leginkább használni. Vagy sehogy :).

Jake a visszajelzésekre vár, lehet tehát tesztelni, de csak óvatosan.

A PAE 36 bites címzése az Intel Pentium Pro processzoroktól kezdve használható, de jobb helyeken inkább 64 bites processzorokat vesznek :)

Az első MPSAFE meghajtó (busdma)

Jeff Roberson és csapata kifejlesztett egy 1:1 szálkezelési (threading) implmentációt a FreeBSD-hez. Ennek a csomagnak a segítségével sikeresen futtattak mozilla 1.2.1-et. Az 1:1 szálkezelési modell (eredetileg a RedHat Linux fejlesztői által adoptált modell) a Native Posix Thread Library-n (NPTL) alapul. A project tiszteletben tartja az M:N mintájú Kernel Schedulable Entity (KSE) implementációt, és nem gátolja annak működését.

Email bejelentés:Date: Tue, 25 Mar 2003 21:59:40 -0500 (EST)

From: Jeff Roberson

To: arch@freebsd.org

Subject: 1:1 Threading implementation.

I realize that many people have strong feelings on this topic. I'm asking everyone up front to try not to devolve this thread into a bikeshed.

Thanks to the foundation provided by Julian, David Xu, Mini, Dan Eischen, and everyone else who has participated with KSE and libpthread development Mini and I have developed a 1:1 threading implementation. This code works in parallel with KSE and does not break it in any way. It actually helps bring M:N threading closer by testing out shared bits.

I have successfully run mozilla 1.2.1 using this threading package. It still has some bugs and some incomplete corners but we're very close to being able to commit this. I'm going to post a link to the kernel portion of this code at the end of this mail. The library will come later.

What this means is that for every pthread in an application there is one KSE and thread. There is also only one ksegroup per proc in this model. Since the kernel knows about all threads it handles all scheduling decisions and all signal delivery. I have followed the POSIX spec while implementing the signal code. I would really appreciate review from anyone who is intimately familiar with signals and threads. Included in

this is an implementation of sigwait(), sigtimedwait(), and sigwaitinfo().

The user land mutexes are supported by kernel code. Uncontested acquires and releases are done entirely in application space using atomic instructions. Once there is contention the library falls back to system calls to handle the locks. There are no per lock kernel resources allocated. There is a user space safe atomic cmpset function that has been defined for x86 only at the moment. New architectures require only this function and the *context apis to run this threading package. There is no arch specific code in user space.

The condition variables and other blocking situations are handled with sig*wait*() and a new signal, SIGTHR. There are many reasons that we went with a signal here. If anyone cares to know them, you may ask.

There are only 4 system calls for threading. thr_create, thr_self, thr_exit, and thr_kill. The rest of the functionality is implemented in a library that has been heavily hacked up from the original libc_r.

The reason we're doing this in parallel with the M:N effort is so that we can have reasonable threading sooner. As I stated before, this project is complimentary to KSE and does not prohibit it from working. I also think that the performance will be better or comparable in the majority of real applications.

The kernel bits are available at

http://www.chesapeake.net/~jroberson/thr.diff

I'd like to get the signal code commited asap. It's the majority of the patch and I often have to resolve conflicts. There have been no regressions in KSE or non threaded applications with this signal code.

Cheers,

Jeff

Pyun YongHyeon bejelentése szerint portolta az OpenBSD-s pf-et (packet filter) a FreeBSD 5.0-hoz. A jelenlegi állapotában is szépen működik, bár több funkcióját még nem tesztelték. Pyun munkája lehetővé teszi a FreeBSD felhasználók számára, hogy egy másik állapottartó csomagszűrőt is használhassanak, amely szintén BSD licensszel rendelkezik.

A pf portot letöltheted innen.