Wie gestern schon geschrieben, scheint die Firewall (eigentlich der Paketfilter) etwas buggy zu sein. Für die einen ist es ein Bug, anscheinend gibt es das Problem auch schon in beim Apple BugReport unter ID#5567648, für die anderen ist es ein Features welche von Apple genau so gewollt ist. Da kann auch mal Apple selbst zitiert werden:

Einige Programme können über die Firewall zugreifen, obwohl sie
nicht in der Liste angezeigt werden. Hierzu zählen u. U.
Systemprogramme, Dienste und Prozesse (z. B. als "root" ausgeführte
Komponenten). Auch digital signierte Programme, die automatisch von
anderen Programmen geöffnet werden, können zu dieser Gruppe gehören.
Sie können ggf. den Zugriff dieser Programme über die Firewall
blockieren, indem Sie sie zur Liste hinzufügen.

Dies würde auch das Verhalten der Firewall erklären. Erklären ja, gut kann man es allerdings nicht heissen. Man stellt die Firewall unter der GUI, nur darum ging es im gestrigen Beitrag folgendermaßen ein:

Die hilfe sagt dabei auch das aus was man erwartet:

Allerdings ist der NTPD immer noch erreichbar, und auch andere Dienste können weiterhin erreicht werden.

Die Verwunderung war gross, zumal IPFW, egal was man in der GUI der FW einstellte, keine Änderungen an den eigenen Rules vornahm. Ausser der Filterung von ICMP wird hier keine Rule (ok, eine die alles erlaubt) geladen.

Einfach Erklärung, es gibt unter MacOSX 10.5 eine Application Firewall. Nun hat man also neben IPFW, welches stiefmütterlich behandelt wird, noch eine Applicationfirewall. Und genau diese ist von Apple so konzipiert wie es im Verhalten ersichtlich ist. Es ist also ein Feature, kein Bug. Wirklich anfreunden kann ich mich damit nicht, da mir die GUI (und Hilfe) etwas anderes sagt als dann wirklich geschieht. Designfehler? Schlicht übersehen? Doch ein Bug? Man kann es sich zur Zeit aussuchen.

Die Applicationfirewall von MacOSX 10.5 liegt unter

/usr/libexec/ApplicationFirewall

Leider kann hierzu keine manpage gefunden werden, auch fehlt es an einer entsprechenden Dokumentation die sich mir bisher verschliesst.

Um das ganze aber auch wieder zu relativieren, MacOSX 10.5 hat mit IPFW eine anständige Firewall dabei, welche sich nutzen lässt. Allerdings kann der User da nicht auf die GUI setzen, sondern muss entsprechende Änderungen im Terminal vornehmen. Die manpage zu IPFW hilft dabei weiter. Auch gibt es hierzu auf den Diskussionsseiten von Apple schon einige, einfache, Vorschläge, mit welchen der unerfahrene Benutzer seinen Mac "dicht" machen kann.

Und nein, der Mac ist nun nicht gleich offen wie ein Scheunentor, er wird nicht zu einer Viren- und Spamschleuder, das Bedrohungsszenario ist sehr gering und der User muss nun keine Angst haben. Der Punkt ist, das Apple die neue Application Firewall besser beschreiben sollte. Dinge die in der GUI versprochen werden, und dann nicht eingehalten wirken mehr als komisch, es ist einfach inkonsitent. Und gerade auf die Konsistenz legt Apple mit seiner GUI doch wert, warum dann nicht auch bei der Beschreibung und dem wirklichen geschehen der Firewall?

Unter MacOSX ist man nicht bei Windows und daher braucht man (noch) keinen Virenscanner und die Firewall, nun, ein nettes Schmuckstück IPFW von FreeBSD im System zu haben, mehr allerdings auch nicht. Denn, diese Firewall macht nicht wirklich das was sie machen sollte. Heise Security berichtete schon darüber.

Nun denn, wollen wir auch mal schnell mit nmap die Firewall testen.

1. MacOSX 10.5 Firewall - Zugriff auf bestimmte Dienste und Programme festlegen -> SSH

65535 allow ip from any to any

Interesting ports on cojote.suedfac.com (10.10.11.230):

Not shown: 1484 closed ports

PORT     STATE         SERVICE

123/udp  open|filtered ntp

631/udp  open|filtered unknown

1900/udp open|filtered UPnP

5353/udp open|filtered zeroconf

Interesting ports on cojote.suedfac.com (10.10.11.230):

Not shown: 1695 closed ports

PORT     STATE SERVICE

22/tcp   open  ssh

9090/tcp open  zeus-admin

Sollte da nicht nur der Port 22 frei sein? Auch lässt sich der NTPD abfragen. MacOSX scheint dabei die Ports einfach freizuschalten die ein laufendes Programm nutzen möchte. Eine schöne Variante für Trojaner. Man fühlt sich sicher, und der Trojaner kann einfach die Firewall nach belieben öffnen...

2. MacOSX 10.5 Firewall - Alle eingehenden Verbindungen blockieren

#ipfw list

65535 allow ip from any to any

#nmap -sU 10.10.11.230

Interesting ports on cojote.suedfac.com (10.10.11.230):

Not shown: 1484 closed ports

PORT     STATE         SERVICE

123/udp  open|filtered ntp

631/udp  open|filtered unknown

1900/udp open|filtered UPnP

5353/udp open|filtered zeroconf

#nmap -sT 10.10.11.230

Interesting ports on cojote.suedfac.com (10.10.11.230):

Not shown: 1695 closed ports

PORT     STATE    SERVICE

22/tcp   filtered ssh

9090/tcp filtered zeus-admin

Ok, nun scheinen alle Verbindungen blockiert zu werden. Wirklich? NTPD lässt sich immer noch abfragen:

ntpdate[1864]: adjust time server 10.10.11.230 offset 0.249411 sec

00001 deny log tcp from any to any

00002 deny log udp from any to any

65535 allow ip from any to any

All 1488 scanned ports on cojote.suedfac.com (10.10.11.230) are open|filtered

All 1697 scanned ports on cojote.suedfac.com (10.10.11.230) are filtered

Ahh, ok, so will ich es haben. Nun geht auch der Zugriff auf den NTPD nicht mehr.

Die Frage ist nun, wo ist die Konfigurationsdatei von IPFW? Warum wird mir, egal was ich in der Firewall einstelle, immer nur eine Regel mit "ipfw list" angezeigt? Die Ausnahme ist wenn man in der MacOSX FW ICMP verbietet, dann wird eine weitere Regel hinzugefügt.

Kann es sein das IPFW von MacOSX irgendwie umgangen wird? Oder haben da die Entwickler einfach IPFW (fast) vergessen?

Wer also eine sichere FW unter MacOSX 10.5 will, der muss zum Terminal greifen und seine Regeln selbst schreiben. Mit einem entsprechenden Automator Script können diese bei jeder Anmeldung geladen werden, oder je nach Umgebung entladen und dafür andere geladen. Es hat also einen Vorteil, der gemeine Macuser muss sich auch mal mit der Firewall beschäftigen...

Da war es am Freitag nun also endlich soweit. MacOSX 10.5, aka Leopard, wurde ab 18:00 offiziell verkauft. Einen Tag später klingelte schon der UPS-Mann an der Tür und brachte das neue MacOSX 10.5 nach Hause.

Die Installation (komplett neu - man kann aber auch problemlos über den Tiger installieren) lief wie immer, schnell und ohne Probleme ab. Aber kaum war das System installiert, gab es auch schon den ersten Fix zu MacOSX 10.5.

Die meisten Programme welche unter MacOSX 10.4 liefen, können auch wieder unter 10.5 eingesetzt werden. Leider gehören dabei beispielsweise VirtualBox und MacIRSSI nicht dazu. Nun, man kann dank Parallels 2.5 darauf verzichten. In diversen Foren (wie beispielsweise macuser.de) und MacOSX News-Seiten (mactechnews) werden hierüber schon Listen geführt. 

Kommen wir zu der kurzen Kritik, oder den Lobpreisungen, von MacOSX 10.5.

Was gefällt?

Der einheitliche Look gefällt, wenngleich das grau der Fenster etwas deprimierend ist, dennoch ist es schön schlicht. Auch TimeMachine macht einen guten Eindruck, wobei man hier sicherlich vorsichtig sein muss, wie gut TimeMachine wirklich ist wird sich erst dann herausstellen wenn man es wirklich benötigt. Die CoverFlow Funktion im neuen Finder ist nett anzusehen, das war es dann aber auch. iChat bietet die Möglichkeit nun Hintergründe einzufügen. So kann man ein Photo seines Büros machen und bei einer Korrespondenz mit seiner Ehefrau via iChat Video, es so aussehen lassen wie wenn man im Büro ist (dabei könnte man gemütlich mit den Jungs bei einem Bier sitzen oder anderes machen, aber nicht im Büro sitzen). Der "neue" Finder ist besser geworden, ohne Frage, wenngleich User die den Finder noch nie sonderlich mochten auch mit dieser neuen Version wahrscheinlich nicht grün werden.

Was gefällt nicht?

Tja, evtl. waren die Erwartungen zu gross, aber das was Apple als ein Major Release verkauft, nunja, ist es das auch Wert? Nur mit grafischen gimmicks ist das nicht zu vertreten, aber darauf läuft es fast hinaus. Die "Stapel" im Dock sind doch sehr gewöhnungsbedürftig, da war die einfache Liste im Tiger besser wenn man einen Ordner im Dock anklickte. Alles in allem ist es etwas wenig was einem als User auffällt was ein Major Release rechtfertigt. Sicherlich, unter der sogenannten Haube hat sich wohl einiges getan, daher bin ich schon jetzt auf die Minor Releases gespannt und auf ein 10.6. Für mih wirkt 10.5, so hoffe ich, als Zwischenschritt zu etwas grossem. Wenn dem nicht so ist, dann ist die Entwicklungsabteilung von Apple langsam etwas müde bezüglich neuen Features. Wer bei dem Adressbuch die Möglichkeit von GoogleMaps als neues Feature anpreist, in Foren liest man da gar von Killerfeature, es so etwas aber schon gab, nur wurde da nicht google maps aufgerufen sondern ein anderer Anbieter, dann hat das den Eindruck das die Luft gerade etwas raus ist.

ArsTechnica hat einen langen ausführlichen Bericht zu MacOSX 10.5 herausgebracht. Hier gibt es eine Umfrage wie zufrieden man mit dem Leoparden ist.

Das die Beta schneller war als der Tiger machte Mut, nun kommt aber raus das der Leopard doch etwas langsamer ist als der Tiger, wie man hier nachlesen kann.

Ich habe in diesem Artikel absichtlich auf Bilder und dergleichen verzichtet, es gibt mittlerweile dutzende von Gallerien mit Leopard screenshots, beispielsweise diese hier.

Die 300 Features von Leopard sind hier zu finden. Eine Videotour von Apple gibt es hier.

Als letztes sei noch erwähnt, es gibt eine Lösung für alle die das 3-D Dock nicht mögen:

defaults write com.apple.dock no-glass -boolean YES

killall Dock

EDIT: Was auch noch sauert aufstösst ist Mail.app. Über das AddOn GPGMail konnte man unter 10.4 Mail.app dazu bringen mit PGP/GPG umzugehen. Leider funktioniert dieses Programm nicht mehr unter MacOSX 10.5 und dem neuen mail.app. Ich hatte erwartet das Apple dies endlich in mail.app selbst integriert, stattdessen kommt das unnütze Feature dazu, wie man dicke HMTL-Mails erstellt, mit bunten Hintergrund und dergleichen. Unverständlich. Und noch einmal mehr der "Beweis" das es beim Leopard auf das Aussehen ankommt und weniger auf sinnvolle Erweiterungen. 

Heute war es soweit, um 18:00 Uhr wurde MacOSX 10.5, aka Leopard, offiziell zum Verkauf freigegeben. Apple spricht dabei vollmundig von 300 neuen Features, aber sind das wirklich 300 neue Features? 

Schaut man sich das Adressbuch an, welches es auch schon in den Vorgängerversionen gab, so kann man sich nun über Google map die Adresse visuell anzeigen lassen. Schön und gut, aber das ist nicht neu, das gab es schon davor. Nur nicht über Google Maps sondern über mapquest.

BootCamp, bisher immer als Beta deklariert, wird nun nicht mehr zum Download angeboten und hat nun Einzug Einzug in das "Base System" gefunden. Auch nichts wirklich neues.

Alles in allem lässt sich sagen, dass 10.5 eine generalüberholte 10.4 ist die nun einheitlicher, bezgl. Look & Feel daherkommt. Mit den Features wie "TimeMachine" und dem "QuickLook" gibt es sicherlich ansprechendes was MacOSX 10.5 sicherlich wertvoll macht. Ob es die 129 Euro Wert ist, wird man sehen.

Eine Übersicht der Features von Leopard gibt es hier.

Da hat sich der Fehlerteufel bei Ken Smith eingeschlichen, welcher FreeBSD 7.0-BETA1 also ISO erstellt und bereitgestellt hatte:

Sorry, I had a bit of a false start with 7.0-BETA1. I've got sets ofbuild machines used for the Monthly Snapshots and procedures in place to try and minimize the mistakes I could make while doing those Snapshots (previously one set for HEAD, one set for RELENG_6). The set of machines I'll be using for the 7.0-RELEASE build are the ones that had previously been doing the HEAD snapshots and I missed doing one very important adjustment to the build routine while doing the BETA1 builds, which resulted in the builds being based on HEAD. I didn't notice during the tests I do before uploading it because the build procedure makes most things (e.g. uname) say what you told it to build, you need to look harder to discover that sort of mistake. So, 7.0-BETA1 actually should have been called something more like 8.0-SURPRISE...

Daher sollte man sich, so man BETA1 testen will, die neue BETA, diesmal BETA1.5, von den bekannten FreeBSD FTP-Servern, wie beispielsweise ftp.freebsd.org, herunterladen.

Das freie Projekte auch auf finanzielle Mittel angewiesen sind ist ja nichts neues. So hat jedes grössere OpenSource Projekt eine Foundation welche sich um das Beschaffen von finanziellen Mitteln kümmert. Die FreeBSD Foundation gibt es nun schon einigen Jahren. Zur Zeit steht das Barometer der Spenden auf rund 175.000 US$, das Ziel ist es bis Ende des Jahres 250.000 US$ zu erreichen. 

Um dies etwas anzukurbeln, bedient sich die FreeBSD Foundation nun des Auktionshaus ebay. Hier wird die erste Kopie von "Absolute FreeBSD/ 2nd Edition" von Michael Lucas versteigert welcher auch auf dem Cover des Buches unterschrieben hat. Desweiteren wird noch ein Zertifikat beigelegt.

Interessierte können bei ebay mitsteigern. Zur Zeit (Mittwoch, 08:15) steht der Preis bei 300 US$ und es sind noch 9 Tage bis zum Auktionsende.

Ok, gestern stank FreeBSD auf dem Blade noch, heute müffelt es nur noch. Nachdem mir als einzige Option noch SuSE Linux blieb um dort alles aufzusetzen (ja, die SuSE rennt auf de, Blade ohne Probleme), habe ich noch nach weiteren Strohhalmen gesucht und mich an diese geklammert.

Um es kurz zu machen, das Blade rennt wieder mit FreeBSD. Welche Version? Ja, hmm, da bin ich mir nicht so sicher. Warum? Nun, fange ich lieber an der Stelle an die mich auf den Weg der "Erleuchtung" geführt hat.

Man nehmen ein weiteres, freies, konfiguriertes Blade. Teile diesem eine LUN zu und installiere in diese LUN dann FreeBSD. Ja, tatsächlich, das ging. Nein, nicht FreeBSD 6.2, auch nicht Current, sondern FreeBSD 6.1-RELEASE. Nachdem dieses installiert ist so füge man die LUNs des nicht mehr startenden Blades dem laufen Blade zu und mounte dann das dort vorhandene System. Soweit so gut. Gibt es einen alten Kernel? Nein, sonst hätte mir das FreeBSD ja schon beim loader prompt mit

boot kernel.old

gebootet.

Was also tun? FreeBSD 6.1 scheint zu laufen. Man nehme den Kernel von 6.1 und kopieren diesen auf die LUN des nicht mehr funktionierenden FreeBSD. Am besten als kernel.61.

LUNs wieder zurück, Blade booten, im loader dann

boot kernel.61

angegeben. Was soll ich sagen, die Kiste bootet wieder. Ok, der Spiegel von gmirror war irgendwo, aber nicht mehr bei uns.

gmirror insert gm0 /dev/da1

hilft da und der Spiegel wird wieder aufgebaut.

Nun rennt mein Userland als was weiss ich, und der Kernel sagt mir er sei ein FreeBSD 6.1-PRERELEASE. Muss ich nicht verstehen, aber es rennt wieder.

Nun werde ich einen cvsup von RELENG_6_1 machen, danach alles neue bauen, und hoffen das die Kiste dann wieder normal hochkommt.

Man wird sehen...

UPDATE: Siehe da, nun habe ich 6.1 neue gebaut, und tatsächlich, 6.1-RELEASE-p20 bootet ohne Probleme. Gut, kann ich mich den anderen Problemen widmen die zwischenzeitlich noch aufgetaucht sind. Ich liebe solche Wochenenden (zumal das Kind krank ist )

Arbeit am Wochenende ist nichts aussergewöhnliches für einen Admin, und so nimmt dieser das gelassen hin, zumal die unbekannte Ruhe in den sonst so geschäftigen Räumen der Arbeitsanstalt meditativen Charakter hat der zu Höchstleistungen antreibt. 

Nun, zumindest fast. Das Brötchen auf das Hemdn gekleckert, den Kaffee hinterher, hetzt man so schnell zur Arbeit. Man kann es ja kaum erwarten. Oder, man will schnell fertig sein.

Kaum ist man da, eröffnet sich das erste Problem, der Kaffeeautomat ist defekt. "Mal wieder" denkt man sich, und rennt schnell zur Tankstelle um sich Pulverkaffee zu holen, der Wasserkocher röchelt in dieser Zeit schon munter vor sich hin.

Dann geht es los, lapidare, nein, triviale, nein, banale, oder laptriba Dinge sind zu erldigen. Update eines IBM HS-20 Blade. Die Switche, Cisco, QLOGICs, die Blades selber (das BIOS) und zu guter letzt müssen noch die neuen Platten in das bestehende RAID aufgenommen werden. Nebenher macht man noch schnell das Update der OpenBSD Firewall. Alles läuft rund. Die updates zeigen keine Fehler.

"Heureka" mag es einem da schon in der Kehle stecken, doch oh weh, man sollte evtl. die Blades erst booten. Haben sie die Trennung des Spiegels überlebt? Was sagen sie zu der ganzen neuen Firmware.

"Das wird schon" sagt man sich mit einem wissenden lächeln das es eben nie so wird. Willkommen in der Welt von Murphy. Sobald man in dieser ist, wünscht man sich gleichnamiges Bier. Stattdessen, Schokolade gegen den Stress und Kaffee gegen die Müdigkeit.

Es wurde dann auch. Blade 1,3 und 4 starteten brav und rennen. Alles SuSE Linux 9 Enterprise. Keine Probleme. Bleibt die Nummer 2. Hier war es schon ein Abenteuer überhaupt das System zu installieren. Sprich, FreeBSD 6.1. Damals, lange her. Kein Problem. Auch hat der gmirror bei diversen Tests, bei denen man den Spiegel auftrennte und foo und bar, keine Probleme gemacht. Warum dann heute.

Server bootet. Ethernet wird erkannt, RAM, Video, dann kommt isp. ISP? Ja, Qlogic 2312 Adapter. Die HBAs. "Was soll da schon schiefgehen".

da254, da1234, da768,....

WTF?

Jawoll, ich habe also 1234 da's bei mir im System. etwas viel. Was das System dann auch gleich bemerkt und sich kurzerhand, schmollend und zutiefst gekränkt das ich dies bemerkt habe, mit einem PANIC aus dem Staub macht.

Nun denn, nochmals booten und gmirror im loader deaktivieren. Evtl. liegt es ja daran. So was nennt man dann auch "Strohhalm". Naja, und so stabil wie ein Strohhalm ist die Idee dann auch, knickt ein, PANIC.

WTF?

Nun denn, starten wir eben von einer Rescue CD. Also eine 7.0 rein, danach eine 6.2, danach eine 6.1. Der geneigte Leser, so es diesen gibt, kann sich schon denken was passiert. Genau.

WTF!

Die Kiste bleibt wieder beim ISP hängen. Diesmal wird mir da ein da516 angezeigt. Doll. Wenn ich so viele der FC-Platten hätte, ich wäre reich. Heureka.

Nun, es sind einige Stunden vergangen. Man hat auch versucht das BIOS update vom Blade, wieder so ein Strohhalm, rückgängig zu machen. Resultat? Nun verweigert das Blade, solidarisch mit FreeBSD, den Dienst. Ich warte schon auf einen Anruf von Herrn Schell der sonstwas von mir fordert. Kommt aber nicht, wobei ich geneigt wäre darauf sofort einzugehen.

Tjaja, nun stehe ich hier und ringe mit mir.

Eigentlich nicht. Es ist klar was zu tun ist. Weiter probieren bis Montag früh!

Nein, eher nicht. Ich greife langsam zu einem Stapel SuSE Linux Enterprise CDs und werde diese morgen installieren und den SAMBA PDC, DHPC und DNS Server dort neu aufsetzen. 

Sorry, FreeBSD stinkt auf dem Blade. Traurig aber wahr.

Es lief gut, bis zu diesem Update wo andere Systeme kein Problem mit haben, aber in der Liga der Blades scheint FreeBSD nichts verloren zu haben.

Traurig, nun rennt es noch auf solch gammeligen HP Desktop Kisten mit ein paar Diensten, da rennt es, aber wehe es kommt nen dickes Blade, da wird das FreeBSD leider so klein, das es vor Ehrfurcht nen Panic bekommt.

Ja, ich bin etwas angepisst. Aber auch das ist nichts neues für einen Admin.

Das Warten hat für viele nun endlich ein Ende. Nachdem die Fertigstellung von MacOSX 10.5 (Leopard) durch das iPhone aufgehalten wurde, steht der Termin nun fest. Der, schon vermutetet, 26. Oktober 2007 wird im Apple Store als Versanddatum angegeben. Vorbestellungen sind ab sofort möglich. 

Über die "grossartigen" Features kann man sicherlich diskutieren. Interessant dürfte allerdings sicherlich TimeMachine sein, welches ein Backup und Restore sehr vereinfachen dürfte (und niemand mehr einen Grund haben dürfte kein Backup zu machen). In wie weit bei der neusten MacOSX Version auch weiter Teile von FreeBSD eingeflossen sind, kann man bis dato nicht sagen.

Immerhin ist MacOSX Leopard ein registriertes Open Brand UNIX 03 Produkt wie man hier nachlesen kann.

Am 11. Oktober wurde RELENG_7 in das CVS aufgenommen und auch die Release Informationen zeigen mittlerweile RELENG_7 als frozen an. Neben ZFS ist eine der grössten Neuerungen sicherlich auch der Scheduler sched_ule. 

In letzter Zeit hat man immer wieder gutes von diesem gelesen und so wurde ULE von Jeff Roberson durchaus als der Default Scheduler für FreeBSD 7.0 gesehen. Dem ist nun aber, laut einer Nachricht von Ken Smith an freebsd-current@, leider nicht so.

ULE sei noch etwas zu neu als das man diesen Scheduler gleich zum Default Scheduler machen wollte. Daher wird auch unter FreeBSD 7.0-RELEASE noch sched_4BSD der Standard-Scheduler sein. Wer dennoch ULE nutzen möchte, kann dies durch den Eintrag von

options SCHED_ULE

in seiner Kernelkonfiguration und dem anschliessenden build und install tun.

ULE ist aber unter CURRENT nun der Default-Scheduler und es wird erwartet, dass dies auch unter FreeBSD 7.1-RELEASE der Fall sein wird.

Pawel Jakub Dawidek, die Code-Maschine von FreeBSD, welcher ZFS von Solaris auf FreeBSD portiert hat, ruft auf freebsd-current@ und freebsd-fs@ dazu auf ZFS ausgiebig zu testen. 

Hintergrund ist, ZFS soll auf dem kommenden FreeBSD 7.0-RELEASE rock-stable sein, und das auch unter i386. Gerade hier kommt es bei einigen immer wieder, meist bei 1GB RAM und FreeBSD i386, zu panic:

kmem_map too small

So berichtet Pawel das er immer wieder versucht hat den panic auch bei sich auszulösen, aber ohne Erfolg. Dazu hat er 200 FreeBSD src-trees auf einem ZFS Dateisystem in einen anderen Ordner, auf dem gleichen ZFS-Dateisystem mittels rsync gesynct.

Einzig in /boot/loader.conf hat er zwei weitere Einträge stehen:

vm.kmem_size=629145600

vm.kmem_size_max=629145600

Wer immer solche Panics sieht, sollte bitte Pawel benachrichtigen, am besten auf freebsd-fs@ oder freebsd-current@ und dabei beschreiben was er gemacht hat und wie hoch der workload war.

Helft also mit ZFS unter FreeBSD 7.0-RELEASE rock-stable zu machen.

Pawels Nachricht auf freebsd-fs@ kann hier nachgelesen werden.

...http://wwwfe.freebsd.org/, dies ist die FreeBSD Seite welche auf sky.freebsd.org läuft.

In letzter Zeit wurde von Usern desöftern berichtet das http://www.freebsd.org/ nicht erreichbar ist. Zum einen waren Hardwareschäden die Ursache, zum anderen ist die Umstellung wohl nicht nicht vollkommen abgeschlossen, wie man aus dem Blog von Simon L. Nielsen entnehmen kann.

So gibt es noch das eine oder andere Problem mit Jails, was aber in nächster Zeit sicherlich behoben sein wird.

Mittlerweile gibt es bsdtats schon einige Zeit und wird von Benutzern auch gerne genutzt. Im letzten Monat nahm, laut bsdstat, die Nutzung von FreeBSD deutlich ab, die von PC-BSD hingegen steigerte sich um mehr ls 30%. 

Der Grund hierzu ist relativ einfach: Muss man bei den grossen freien BSDs wie FreeBSD, OpenBSD, NetBSD und DragonFlyBSD die Nutzung von bsdstats manuell einschalten (wie dies geht ist hier beschrieben), so ist dies bei PC-BSD per default aktiviert. Jeder der also PC-BSD, austestet, und es ist erst eine neue Version erschienen, pusht damit die Statistik für PC-BSD.

Bisher war es bei BSDCertification nur möglich via PayPal eine BSDCertification DVD zu kaufen, oder hierüber eine Spende dem Verein zukommen zu lassen. Ab sofort kann dies auch über Kreditkarten geschehen.

Gerade in Europa ist die Nutzung von Paypal von vielen Usern nicht gern gesehen, weswegen es nicht sehr oft genutzt wird. Leider sieht dies bei der Nutzung von Kreditkarten nicht anders aus, weswegen die neue Bezahlmethode sicherlich auch hier auf wenig Gegenliebe treffen dürfte. 

Wer dennoch eine Spende dem Verein zukommen lassen möchte, sei es durch den Kauf der DVD oder einfach weil der Geldbeutel locker sitzt, kann dies auch via Banküberweisung tun. Dazu schreibt mir bitte eine E-Mail, ich lasse Euch die Bankdaten zukommen. Euer Geld wird dann direkt via PayPal an die BSDCertification Group überwiesen.

Neben kleinen Spenden ist die BSDCertification Group auch immer auf der Suche nach neuen Sponsoren. Möglicherweise findet sich ja hierüber ein Sponsor der sich gerne in die Liste der schon vorhandenen Sponsoren einreihen möchte.

Nicht nur am Code wird fleissig gewerkelt, auch wenn man sich fragt wie denn nun der Status von 7.0 ist, mehr als einen Code freeze gibt es seit geraumer Zeit nicht, auch am auftreten des Projektes wird gearbeitet. 

Neben dem neuen Logo, welches es seit geraumer Zeit gibt, ist es auch das wiki, welches immer häufiger und intensiver genutzt wird.

Liest man dort etwas genauer, so stösst man schnell auf die Idee, und wohl auch die baldige Umsetzung, eines eigenen FreeBSD.org Project Forums. Dabei gibt es schon die WebForumNotes, das Layout und auch eine wiki Seite über die Moderatoren (noch nicht viel vorhanden).

Sind nun bald Foren wie bsdforums.org oder auch das deutschsprachigen forum.bsdgroup.de und bsdforen.de obsolet? Oder anders gefragt, was halten die BSDler dort draussen über die Idee eines eigenen Forums eines BSD Projects? 

Wahrscheinlich wird es vbulletin werden als Board, interessant dürfte auch die gestalterische Umsetzung werden. Bleibt zu hoffen das diese konsequenter wird als die eigentliche FreeBSD Seite, welche immer noch halb fertig wirkt, trotz, oder gerade wegen, des neuen Logos.