diff --git a/de_DE.ISO8859-1/books/faq/book.sgml b/de_DE.ISO8859-1/books/faq/book.sgml index fbced24971..f849991c09 100644 --- a/de_DE.ISO8859-1/books/faq/book.sgml +++ b/de_DE.ISO8859-1/books/faq/book.sgml @@ -1,12711 +1,12724 @@ %books.ent; ]> Häufig gestellte Fragen zu &os; - 6.<replaceable>X</replaceable> und - 7.<replaceable>X</replaceable> + 6.X, 7.X und + 8.X Frequently Asked Questions zu &os; - 6.X und 7.X + 6.X, 7.X und + 8.X The &os; German Documentation Project Deutsche Übersetzung von Robert S. F. Drehmel, Dirk Gouders, Udo Erdelhoff, Johann Kois und Benedict Reuschling - $FreeBSDde: de-docproj/books/faq/book.sgml,v 1.751 2010/01/20 12:56:44 bcr Exp $ + $FreeBSDde: de-docproj/books/faq/book.sgml,v 1.752 2010/05/13 11:46:48 fboerner Exp $ 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 The &os; Documentation Project 2000 2001 2002 2003 2004 2005 2006 2007 2007 2008 2009 2010 The &os; German Documentation Project &bookinfo.legalnotice; &tm-attrib.freebsd; &tm-attrib.3com; &tm-attrib.adobe; &tm-attrib.creative; &tm-attrib.cvsup; &tm-attrib.ibm; &tm-attrib.ieee; &tm-attrib.intel; &tm-attrib.iomega; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.mips; &tm-attrib.netscape; &tm-attrib.opengroup; &tm-attrib.oracle; &tm-attrib.sgi; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.usrobotics; &tm-attrib.xfree86; &tm-attrib.general; Dies ist die FAQ für die &os;-Versionen - 6.X und - 7.X. Alle Einträge sollten für + 6.X 7.X und + 8.X. Alle Einträge sollten für &os; ab Version 6.X relevant sein, andernfalls wird darauf explizit hingewiesen. Falls Sie daran interessiert sein sollten, an diesem Projekt mitzuarbeiten, senden Sie eine Mail an die Mailingliste &a.de.translators;. Die aktuelle Version dieses Dokuments ist ständig auf dem &os; World-Wide-Web-Server verfügbar. Sie kann aber auch als eine einzige große HTML-Datei, als Textdatei, als &postscript;- oder PDF-Datei sowie in verschiedenen anderen Formaten vom &os; FTP-Server heruntergeladen werden. Alternativ können Sie die FAQ auch durchsuchen. Einleitung Willkommen zur &os; - 6.X-7.X - FAQ! + 6.X-7.X- und + 8.X FAQ! Wie auch bei den Usenet FAQs üblich, wird mit diesem Dokument beabsichtigt, die am häufigsten gestellten Fragen bezüglich des Betriebssystems &os; zu erfassen und sie natürlich auch zu beantworten. Obwohl FAQs ursprünglich lediglich dazu dienen sollten, die Netzbelastung zu reduzieren und das ständige Wiederholen derselben Fragen zu vermeiden, haben sie sich als wertvolle Informationsquellen etabliert. Wir haben uns die größte Mühe gegeben, diese FAQ so lehrreich wie möglich zu gestalten; falls Sie irgendwelche Vorschläge haben, wie sie verbessert werden kann, senden Sie diese bitte an die Mailingliste des &a.de.translators;. Was ist &os;? &os; ist, kurz gesagt, ein &unix; ähnliches Betriebssystem für die Plattformen AMD64 sowie &intel; EM64T, &i386;, IA-64, &arm;, &powerpc;, PC-98 und &ultrasparc;, das auf der 4.4BSD-Lite-Release der University of California at Berkeley (UCB) basiert; außerdem flossen einige Erweiterungen aus der 4.4BSD-Lite2-Release mit ein. Es basiert außerdem indirekt auf der von William Jolitz unter dem Namen 386BSD herausgebrachten Portierung der Net/2-Release der UCB auf die &i386;-Plattform - allerdings ist nur wenig vom 386BSD-Code übriggeblieben. Eine umfassendere Beschreibung darüber, was &os; ist und wie Sie es für Ihre Zwecke verwenden können, finden Sie auf den Internetseiten des &os; Projects. Unternehmen, Internet Service Provider, Forscher, Computerfachleute, Studenten und Privatnutzer auf der ganzen Welt benutzen &os; für die Arbeit, die Ausbildung oder zur Freizeitgestaltung. Ausführlichere Informationen zu &os;, finden Sie im &os; Handbuch. Welches Ziel hat das &os; Project? Die Ziel von &os; ist es, Software zur Nutzung für beliebige Zwecke, bedingungslos zur Verfügung zu stellen. Viele von uns haben erheblich zur Erstellung des Codes (und zum Projekt) beigetragen und hätten jetzt oder in Zukunft sicherlich nichts gegen einen geringen finanziellen Ausgleich einzuwenden, aber wir beabsichtigen definitiv nicht, darauf zu bestehen. Wir sind der Meinung, dass unsere Mission zuerst und vorderst darin besteht, allen und jedem Kommenden Code für welchen Zweck auch immer zur Verfügung zu stellen, damit der Code möglichst weit eingesetzt wird und den größtmöglichen Nutzen liefert. Das ist, so glauben wir, eines der fundamentalsten Ziele von freier Software und eines, das wir enthusiastisch unterstützen. Der Code in unserem Quellbaum, der der GNU General Public License (GPL) oder der GNU Library General Public License (LGPL) unterliegt, ist mit zusätzlichen, geringfügigen Bedingungen verknüpft, jedoch handelt es sich dabei lediglich um erzwungene Bereitstellung statt des sonst üblichen Gegenteils. Auf Grund der zusätzlichen Komplexität, die durch den kommerziellen Einsatz von GPL Software entstehen kann, bemühen wir uns jedoch, solche Software, wo möglich, durch solche, die der etwas lockereren &os; Lizenz unterliegt, zu ersetzen. Beinhaltet das &os;-Copyright irgendwelche Einschränkungen? Ja. Diese Einschränkungen regeln aber nicht, wie Sie mit dem Sourcecode umgehen, sondern betreffen nur den Umgang mit dem &os; Project an sich. Wenn Sie sich ernsthaft damit auseinandersetzen wollen, lesen Sie einfach die &os;-Lizenz. Wenn Sie einfach nur neugierig sind, sollte diese Zusammenfassung ausreichen: Behaupten Sie nicht, Sie hätten es geschrieben. Verklagen Sie uns nicht, wenn irgend etwas nicht funktioniert. Kann &os; mein bisher verwendetes Betriebssystem ersetzen? In den meisten Fällen lautet die Antwort ja. Allerdings ist diese Frage nicht ganz so einfach, wie sie scheint. Die meisten Anwender benutzen kein Betriebssystem, sondern Anwendungen. Die Anwendungen sind es, die das Betriebssystem benutzen. &os; ist dazu gedacht, eine stabile und vielfältige Umgebung für Anwendungen bereitzustellen. Es unterstützt viele unterschiedliche Web-Browser, Büroanwendungen, E-Mail-Programme, Grafik-Programme, Entwicklungsumgebungen, Netzwerk-Server, und so ziemlich alles andere, was Sie sich wünschen können. Die meisten dieser Anwendungen sind in der Ports-Sammlung verfügbar. Wenn Sie Anwendung benutzen müssen, die es nur für ein bestimmtes Betriebssystem gibt, dann kommen Sie an diesem Betriebssystem nicht vorbei. Allerdings stehen die Chancen nicht schlecht, dass es eine vergleichbare Anwendung für &os; gibt. Wenn Sie einen verläßlichen Server für ihr Büro oder das Internet brauchen, oder eine stabilen Arbeitsplatz, oder einfach nur die Fähigkeit, ihre Arbeit ohne dauernde Abstürze machen zu können, dann kann &os; genau das sein. Viele Anwender auf der ganzen Welt, vom Anfänger bis zum erfahrenen Administrator, benutzen an Ihren Arbeitsplätzen ausschließlich &os;. Wenn Sie von einem anderen &unix; System zu &os; wechseln, dürfte Ihnen vieles bekannt vorkommen. Wenn Ihr Hintergrund ein Grafik-orientiertes Betriebssystem wie &windows; oder ein älteres &macos; ist, werden Sie zusätzliche Zeit investieren müssen, um den &unix; Stil zu verstehen. Dieser FAQ und das &os; Handbuch sind die besten Startpunkte. Warum heißt es &os;? Es darf kostenlos genutzt werden - sogar von kommerziellen Benutzern. Der komplette Quellcode für das Betriebssystem ist frei verfügbar und die Benutzung, Verbreitung und Einbindung in andere (kommerzielle und nicht-kommerzielle) Arbeiten sind mit den geringstmöglichen Einschränkungen versehen worden. Jedem ist es freigestellt, Code für Verbesserungen oder die Behebung von Fehlern einzusenden und ihn zum Quellbaum hinzufügen zu lassen (dies ist natürlich Gegenstand von ein oder zwei offensichtlichen Klauseln). Es wird darauf hingewiesen, dass das englische Wort free hier in den Bedeutungen umsonst und Sie können tun, was immer Sie möchten genutzt wird. Abgesehen von ein oder zwei Dingen, die Sie mit dem &os;-Code nicht tun können (z.B. vorgeben, ihn geschrieben zu haben), können Sie damit tatsächlich tun, was auch immer Sie möchten. Wie unterschieden sich &os;, NetBSD, OpenBSD und andere Open-Source BSD-Systeme? James Howards Artikel, genannt The BSD Family Tree, beschreibt sehr gut die Geschichte und die Unterschiede der BSD-Varianten. Welches ist die aktuelle &os;-Version? Momentan gibt es zwei Entwicklungszweige, die für die Erstellung von Releases verwendet werden. - Die 6.X-RELEASEs werden auf dem - 6-STABLE-Zweig erstellt, die - 7.X-RELEASEs auf dem - 7-STABLE-Zweig. + Die 7.X-RELEASEs werden auf dem + 7-STABLE-Zweig erstellt, die + 8.X-RELEASEs auf dem + 8-STABLE-Zweig. - Bis zur Veröffentlichung von &os; 7.0 galt - die 6.X-Serie als + Bis zur Veröffentlichung von &os; 8.0 galt + die 7.X-Serie als -STABLE. Seither - gibt es für den Zweig 6.X nur mehr + gibt es für den Zweig 7.X nur mehr eine erweiterte Unterstützung in der Form von Korrekturen von größeren Problemen, wie neu entdeckten Sicherheitsheitslücken. Aus dem Zweig - 6-STABLE werden zwar noch + 7-STABLE werden zwar noch RELEASEs erzeugt, er gilt aber als ausgereift. Aktive Weiterentwicklungen konzentrieren sich daher auf den - Zweig 7-STABLE. + Zweig 8-STABLE. Version &rel.current; ist das aktuelle Release des - 7-STABLE-Zweigs und ist im + 8-STABLE-Zweigs und ist im Januar 2009 erschienen. Version &rel2.current; ist das aktuelle Release aus dem - 6-STABLE-Zweig und ist im + 7-STABLE-Zweig und ist im November 2008 erschienen. Kurz gesagt, -STABLE ist für ISPs und andere Benutzer gedacht, die mehr Wert auf Stabilität und eine niedrige Änderungsfrequenz als auf die neuesten und möglicherweise unstabilen Features im aktuellen -CURRENT Snapshot legen. Releases können aus jedem Zweig entstehen, Sie sollten -CURRENT allerdings nur dann benutzen, wenn Sie auf ein erhöhtes Fehlverhalten im Vergleich zu -STABLE auch vorbereitet sind. Releases entstehen nur alle paar Monate. Viele Leute halten ihre Systeme aktueller (lesen Sie die Fragen zu &os;-CURRENT und &os;-STABLE), aber das erfordert ein erhöhtes Engagement, da die Sourcen sich ständig verändern. Weitere Informationen über &os;-Releases entnehmen Sie der Seite Release Engineering des &os; Webauftritts. Was ist &os;-CURRENT? &os;-CURRENT ist die Entwicklungsversion des Betriebssystems, aus der zu gegebener Zeit &os.stable; werden wird. Als solche ist sie lediglich für Entwickler, die am System mitarbeiten und für unentwegte Bastler von Interesse. Details zum Betrieb von -CURRENT finden Sie im entsprechenden Abschnitt des Handbuchs. Falls Sie nicht mit dem Betriebssystem vertraut sind oder nicht in der Lage sein sollten, den Unterschied zwischen einen echten und einem temporären Problem zu erkennen, sollten Sie &os.current; nicht verwenden. Dieser Zweig entwickelt sich manchmal sehr schnell weiter und kann gelegentlich nicht installierbar sein. Von Personen, die &os.current; verwenden, wird erwartet, dass Sie dazu in der Lage sind, Probleme zu analysieren und nur dann von ihnen berichten, wenn es sich um Fehler und nicht um kurzzeitige Störungen handelt. Fragen wie make world produziert Fehlermeldungen bezüglich Gruppen werden in der &a.current; Mailingliste manchmal nicht beachtet. Jeden Monat wird der aktuelle Entwicklungsstand in den Zweigen -CURRENT und -STABLE in einer Snapshot Release festgehalten. Die Ziele dieser Snapshot Releases sind: Die aktuelle Version der Installationssoftware zu testen. Personen, die -CURRENT oder -STABLE benutzen möchten, aber nicht über die nötige Zeit oder Bandbreite verfügen, um tagesaktuell zu bleiben, soll eine bequeme Möglichkeit geboten werden, es auf ihr System zu bringen. Die Erhaltung von Referenzpunkten des fraglichen Codes, für den Fall, dass wir später einmal ernsthaften Schaden anrichten sollten - obwohl CVS verhindern sollte, dass solche Situationen entstehen. Sicherzustellen, dass alle zu testenden, neuen Merkmale und Fehlerbehebungen zu möglichst vielen potentiellen Testern gelangen. Von keinem -CURRENT Snapshot kann Produktionsqualität für beliebige Zwecke erwartet werden. Wenn Sie eine stabile und ausgetestete Version benötigen, sollten Sie eine vollständige Release oder einen -STABLE Snapshot verwenden. Snapshot-Releases sind auf der Snapshots-Seite verfügbar. Offizielle Snapshots werden in der Regel jeden Monat für jeden aktiven Zweig erstellt. Es gibt auch täglich erstellte Snapshots der populären &arch.i386; und &arch.amd64; Zweige, die auf bereitliegen. Was ist das Konzept von &os;-STABLE? Zur der Zeit, als &os; 2.0.5 herausgegeben wurde, wurde entschieden, die Entwicklung von &os; zweizuteilen. Ein Zweig wurde -STABLE, der andere -CURRENT genannt. &os;-STABLE ist für Anbieter von Internetdiensten und andere kommerzielle Unternehmen gedacht, für die plötzliche Veränderungen und experimentelle Features unerwünscht sind. In diesem Zweige werden nur ausgetestete Fehlerbehebungen und kleine, inkrementelle Änderungen aufgenommen. &os;-CURRENT ist eine ununterbrochene Linie seitdem die Version 2.0 herausgegeben worden ist. Sie führt zu &rel.current;-RELEASE (und darüber hinaus). Weitere Informationen zu diesen Zweigen finden Sie unter &os; Release Engineering: Creating the Release Branch, der Status der Zweige und der Zeitplan zur anstehenden Veröffentlichung kann unter der Seite Release Engineering Information gefunden werden. Der Zweig 2.2-STABLE wurde mit der Veröffentlichung der Version 2.2.8 eingestellt. Der Zweig 3-STABLE endete mit Version 3.5.1, der letzten 3.X-Version, der Zweig 4.X endete mit der Version 4.11, der letzten 4.X-Version. Änderungen in diesen Zweigen beschränken sich im allgemeinen auf die Korrektur von sicherheitsrelevanten Fehlern. Der Zweig 5-STABLE wurde mit 5.5, der letzten 5.X Version, beendet. 6-STABLE wird noch unterstützt, die Unterstützung beschränkt sich allerdings auf das Schließen von neu entdeckten Sicherheitslücken und die Behebung von anderen ernsten Problemen. &rel.current;-STABLE ist der Zweig, auf den sich die Entwicklung von -STABLE zur Zeit konzentriert. Das neueste Release aus dem &rel.current;-STABLE-Zweig ist &rel.current;-RELEASE und ist im Januar 2007 erschienen. - Aus dem 8-CURRENT-Zweig entsteht die nächste + Aus dem 9-CURRENT-Zweig entsteht die nächste &os;-Generation. Weitere Informationen über diesen Zweig finden Sie unter Was ist &os;-CURRENT?. Wann werden &os;-Versionen erstellt? Im Schnitt gibt das &a.re; alle 18 Monate eine neue Haupt-Version und etwa alle 8 Monate eine Unter-Version frei. Das Erscheinungsdatum einer neuer Version wird frühzeitig bekanntgegeben, damit die am System arbeitenden Personen wissen, bis wann ihre Projekte abgeschlossen und ausgetestet sein müssen. Vor jedem Release gibt es eine Testperiode um sicherzustellen, dass die neu hinzugefügten Features nicht die Stabilität des Releases beeinträchtigen. Viele Benutzer halten dies für einen großen Vorteil von &os;, obwohl es manchmal frustrierend sein kann, so lange auf die Verfügbarkeit der aktuellsten Leckerbissen zu warten. Weitere Informationen über die Entwicklung von Releases, sowie eine Übersicht über kommende Releases, erhalten Sie auf den Release Engineering Seiten der &os; Webseite. Für diejenigen, die ein wenig mehr Spannung brauchen (oder möchten), werden täglich Snapshots herausgegeben, wie oben beschrieben. Wer ist für &os; verantwortlich? Schlüsseldiskussionen, die das &os; Project betreffen, wie z.B. über die generelle Ausrichtung des Projekts und darüber, wem es erlaubt sein soll, Code zum Quellbaum hinzuzufügen, werden innerhalb eines Core Teams von 9 Personen geführt. Es gibt ein weitaus größeres Team von über 350 Committern, die dazu autorisiert sind, Änderungen am &os; Quellbaum durchzuführen. Jedoch werden die meisten nicht-trivialen Änderungen zuvor in den Mailinglisten diskutiert und es bestehen keinerlei Einschränkungen darüber, wer sich an diesen Diskussionen beteiligen darf. Wie kann ich &os; beziehen? Jede bedeutende Ausgabe von &os; ist per Anonymous-FTP vom &os; FTP Server erhältlich: - Das aktuelle 7-STABLE-Release, &rel.current;-RELEASE, + Das aktuelle 8-STABLE-Release, &rel.current;-RELEASE, finden Sie im Verzeichnis &rel.current;-RELEASE. Snapshots-Releases werden monatlich aus dem -CURRENT-Zweig sowie aus dem -STABLE-Zweig erzeugt. Sie sollten aber nur von Entwicklern und sehr erfahrenen Testern verwendet werden. - Das aktuelle Release von 6-STABLE, + Das aktuelle Release von 7-STABLE, &rel2.current;-RELEASE finden Sie im Verzeichnis &rel2.current;-RELEASE. Wo und wie Sie &os; auf CD, DVD, und anderen Medien beziehen können, erfahren Sie im Handbuch. Wie greife ich auf die Datenbank mit Problemberichten zu? Die Datenbank mit Problemberichten (PR, problem report) und Änderungsanfragen von Benutzern kann über die webbasierte PR-Abfrage-Schnittstelle abgefragt werden. Mit dem Programm &man.send-pr.1; können Sie Problemberichte oder Änderungsanträge per E-Mail einsenden. Alternativ können Sie Problemberichte auch über Ihren Browser und die webbasierte PR-Eingabe-Schnittstelle erstellen. Bevor Sie einen Fehler melden, sollten Sie sich zuerst den Artikel Writing &os; Problem Reports durchlesen, damit Sie wissen, wie Sie eine gute Fehlermeldung verfassen. Gibt es weitere Informationsquellen? Sie finden eine umfassende Liste unter Documentation auf der &os;-Webseite. Dokumentation und Support Gibt es gute Bücher über &os;? Im Zuge des &os; Projekts sind diverse gute Dokumente entstanden, die unter der folgenden URL abgerufen werden können: . Zusätzlich enthält die Bibliographie am Ende dieser FAQ und diejenige im Handbuch Verweise auf weitere empfohlene Bücher. Ist die Dokumentation auch in anderen Formaten verfügbar? Zum Beispiel als einfacher Text (ASCII) oder als &postscript;? Ja. Werfen Sie einen Blick auf das Verzeichnis /pub/FreeBSD/doc/ auf dem &os; FTP-Server. Dort finden sie Dokumentation in vielen verschiedenen Format. Die Dokumentation wurde nach vielen verschiedenen Kriterien sortiert. Die Kriterien sind: Der Name des Dokumentes, z.B. FAQ oder Handbuch. Die Sprache und der Zeichensatz, die in dem Dokument verwendet werden. Diese entsprechen den Anpassungen, die Sie auf Ihrem &os;-System im Verzeichnis /usr/share/locale finden. Zurzeit werden die folgenden Sprachen und Zeichensätze benutzt: Name Bedeutung bn_BD.ISO10646-1 Bengalisch oder Bangla (Bangladesh) da_DK.ISO8859-1 Dänisch (Dänemark) de_DE.ISO8859-1 Deutsch (Deutschland) en_US.ISO8859-1 Englisch (Vereinigte Staaten) el_GR.ISO8859-7 Griechisch (Griechenland) es_ES.ISO8859-1 Spanisch (Spanien) fr_FR.ISO8859-1 Französisch (Frankreich) it_IT.ISO8859-15 Italienisch (Italien) hu_HU.ISO8859-2 Ungarisch (Ungarn) ja_JP.eucJP Japanisch (Japan, EUC-kodiert) mn_MN.UTF-8 Mongolisch (Mongolei, UTF-8-kodiert) nl_NL.ISO8859-1 Niederländisch (Holland) no_NO.ISO8859-1 Norwegisch (Norwegen) pl_PL.ISO8859-2 Polnisch (Polen) pt_BR.ISO8859-1 Brasilianisches Portugiesisch (Brasilien) ru_RU.KOI8-R Russisch (Russland, KOI8-R-kodiert) sr_YU.ISO8859-2 Serbisch (Serbien) tr_TR.ISO8859-9 Türkisch (Türkei) zh_CN.GB2312 Vereinfachtes Chinesisch (China, GB2312-kodiert) zh_TW.Big5 Chinesisch (Taiwan, Big5-kodiert) Einige Dokumente sind nicht in allen Sprachen verfügbar. Das Format des Dokumentes. Die Dokumentation wird in verschiedenen Formaten erzeugt, von denen jedes seine eigenen Vor- und Nachteile hat. Einige Formate lassen sich gut an einem Bildschirm lesen, während andere Formate dafür gedacht sind, ein ansprechendes Druckbild zu erzeugen. Das die Dokumentation in verschiedenen Formaten verfügbar ist, stellt sicher, dass unsere Leser die für sie relevanten Teile unabhängig vom Ausgabemedium (Bildschirm oder Papier) lesen können. Derzeit werden die folgenden Formate unterstützt: Format Erklärung html-split Viele kleine HTML-Dateien, die sich gegenseitig referenzieren. html Eine große HTML-Datei, die das komplette Dokument enthält. pdb Palm Pilot Datenbank für das Programm iSilo. pdf Adobe's Portable Document Format ps &postscript; rtf Microsoft's Rich Text Format txt Ganz normaler Text Die Seitennummern werden nicht automatisch aktualisiert, wenn Sie das Rich Text Format in Word laden. Wenn Sie das Dokument geladen haben, müssen Sie Sie CtrlA, CtrlEnd, F9 eingeben, um die Seitennummern aktualisieren zu lassen. Das zur Komprimierung verwendete Programm. Zur Zeit werden drei verschiedene Methoden benutzt. Wenn die Dokumentation im Format html-split vorliegt, werden die Dateien mit &man.tar.1; zusammengefasst. Die so entstandene .tar Datei wird dann mit einer der unten genannten Methoden komprimiert. Bei allen anderen Formaten existiert nur eine Datei mit dem Namen type.format (z.B. article.pdf, book.html, und so weiter). Diese Dateien werden mit zwei verschiedenen Programmen komprimiert. Programm Beschreibung zip Das zip-Format. Wenn Sie diese Dateien unter &os; entpacken wollen, müssen sie vorher den Port archivers/unzip installieren. bz2 Das bzip2-Format. Es wird seltener als das zip-Format benutzt, erzeugt aber normalerweise kleinere Archive. Sie müssen den Port archivers/bzip2 installieren, um diese Dateien entpacken zu können. Ein Beispiel: Die mit bzip2 gepackte Version des Handbuchs im &postscript;-Format hat den Namen book.ps.bz2 und ist im Verzeichnis handbook/ zu finden. Nachdem Sie das Format und das Kompressionsverfahren ausgewählt haben, müssen Sie die komprimierten Dateien selber herunterladen, entpacken und an die richtigen Stellen kopieren. Wenn Sie zum Beispiel die mit &man.bzip2.1; gepackte split HTMLVersion der englischen FAQ herunterladen und installieren wollten, bräuchten Sie die Datei doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2. Um diese Datei herunterzuladen und auszupacken, wären die folgenden Schritte notwendig. &prompt.root; fetch ftp://ftp.de.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 &prompt.root; gzip -d book.html-split.tar.bz2 &prompt.root; tar xvf book.html-split.tar Danach haben Sie eine Sammlung vieler kleiner .html Datei. Die wichtigste Datei hat Namen index.html und enthält das Inhaltsverzeichnis, eine Einleitung und Verweise auf die anderen Teile des Dokumentes. Falls notwendig, können Sie die diversen Dateien jetzt an ihren endgültigen Bestimmungsort verschieben oder kopieren. Woher bekomme ich Informationen zu den &os; Mailinglisten? Vollständige Informationen finden Sie im Handbucheintrag über Mailinglisten. Welche Newsgruppen existieren zu &os;? Sie finden alle Informationen hierzu im Handbucheintrag zu Newsgruppen. Gibt es &os; IRC (Internet Relay Chat) Kanäle? Ja, die meisten großen IRC Netze bieten einen &os; Chat-Channel: Channel FreeBSD im EFNet ist ein &os;-Forum, aber gehen Sie nicht dorthin, um technische Unterstützung zu suchen, oder, um zu versuchen, die Leute dort dazu zu bringen, Ihnen dabei zu helfen, das mühselige Lesen von Manuals zu ersparen oder eigene Nachforschungen zu betreiben. Es ist in erster Linie ein Chat-Channel und die Themen dort umfassen Sex, Sport oder Kernwaffen ebensogut, wie &os;. Sie wurden gewarnt! Der Channel ist auf dem Server irc.efnet.org verfügbar. Der Channel #FreeBSDhelp im EFNet hat sich dagegen auf die Unterstützung der Benutzer von &os; spezialisiert. In diesem Channel sind Fragen deutlich willkommener als im Channel #FreeBSD. Der Channel ##FreeBSD auf Freenode bietet allgemeine Hilfe zu &os;-Themen. Es sind immer viele Benutzer online. Zwar werden auch nicht-&os;-spezifische Themen diskutiert, den Hauptteil der Diskussionen dreht sich aber um die Lösung der Probleme von &os;-Anwendern. Die Teilnehmer dieses Channels helfen Ihnen auch bei Fragen zu elementaren Dingen und zeigen Ihnen auch, wo Sie die entsprechenden Erklärungen im &os;-Handbuch oder anderen Ressourcen finden können. Obwohl die Teilnehmer des Channels über die ganze Welt verstreut sind, werden alle Diskussionen auf Englisch geführt. Wollen Sie die Diskussion in Ihrer Sprache führen, sollten Sie Ihre Frage trotzdem auf Englisch stellen und danach gegebenenfalls einen neuen Channel in der Form ##freebsd-Ihre_Sprache eröffnen. Der Channel #FreeBSD im DALNET ist in den USA unter irc.dal.net und in Europa unter irc.eu.dal.net verfügbar. Der Channel #FreeBSDHelp im DALNET ist in den USA unter irc.dal.net sowie in Europa unter irc.eu.dal.net verfügbar. Der Channel #FreeBSD im UNDERNET ist in den USA unter us.undernet.org und in Europa unter eu.undernet.org verfügbar. Es handelt sich hierbei um einen Hilfe-Channel, man wird Sie daher auf Dokumente verweisen, die Sie selbst lesen müssen. Der Channel #FreeBSD im RUSNET ist ein russischsprachiger Channel, der sich der Unterstützung von &os;-Anwendern verschrieben hat. Er ist auch ein guter Startpunkt für nichttechnische Diskussionen. Der Channel #bsdchat auf Freenode (Sprache: traditionelles Chinesisch, UTF-8-kodiert) hat sich der Unterstützung von &os;-Anwendern verschrieben. Er ist auch ein guter Startpunkt für nichttechnische Diskussionen. Alle diese Kanäle unterscheiden sich voneinander und sind nicht miteinander verbunden. Ebenso unterscheiden sich Ihre Chat-Stile, weshalb es sein kann, dass Sie zunächst alle Kanäle ausprobieren müssen, um den zu Ihrem Chat-Stil passenden zu finden. Hier gilt, was für jeden IRC-Verkehr gilt: falls sie sich leicht angegriffen fühlen oder nicht mit vielen jungen (und einigen älteren) Leuten, verbunden mit dem nutzlosen Gezanke umgehen können, dann ziehen Sie es gar nicht erst in Erwägung. Gibt es Firmen, die Training und Support für &os; anbieten? DaemonNews bietet Training und Support für &os; an. Weitergehende Informationen finden Sie in der BSD Mall. Die &os; Mall bietet ebenfalls professionellen &os; Support an. Weitergehende Informationen finden Sie auf ihrer Webseite. Die BSD Certification Group, Inc. bietet Zertifizierungen zur Systemadministration für DragonFly BSD, &os;, NetBSD und OpenBSD. Wenn Sie daran interessiert sind, besuchen Sie deren Webseite. Wenn Ihre Firma oder Organisation ebenfalls Training und Support anbietet und hier genannt werden möchte, wenden Sie sich bitte an das &os; Project. Nik Clayton
nik@FreeBSD.org
Installation Welche Dateien muss ich herunterladen, um &os; zu bekommen? Sie benötigen drei Floppy-Images: floppies/boot.flp, floppies/kern1.flp sowie floppies/kern2.flp. Diese Images müssen mit Hilfe von Werkzeugen wie fdimage oder &man.dd.1; auf Disketten kopiert werden. Falls Sie selbst die einzelnen Distributionen herunterladen müssen (um z.B. von einem DOS-Dateisystem aus zu installieren), empfehlen wir, sich die folgenden Distributionen zu besorgen: base/ manpages compat* doc src/ssys.* Vollständige Instruktionen für dieses Vorgehen und ein wenig mehr zur Installation generell finden Sie im Handbucheintrag zur Installation von &os;. Was soll ich tun, wenn das Floppy-Image nicht auf eine Diskette passt? Eine 3,5-Zoll (1,44 MB) Diskette kann 1.474.560 Byte an Daten fassen und das Boot-Image ist exakt 1.474.560 Byte groß. Häufige Fehler bei der Erstellung der Boot-Diskette sind: Bei der Benutzung von FTP das Floppy-Image nicht im Binär-Modus herunterzuladen. Einige FTP-Clients benutzen als Voreinstellung den ASCII-Modus und versuchen, alle Zeilenendezeichen an das Zielsystem anzupassen. Dadurch wird das Boot-Image in jedem Fall unbrauchbar. Überprüfen Sie die Größe des heruntergeladenen Boot-Images: falls sie nicht exakt mit der auf dem Server übereinstimmt, hat das Herunterladen nicht richtig funktioniert. Abhilfe: geben Sie binary an der FTP-Eingabeaufforderung ein, nach dem Sie mit dem Server verbunden sind und bevor Sie das Image herunterladen. Die Benutzung des DOS-Befehls copy (oder eines entsprechendes Werkzeugs der grafischen Benutzeroberfläche), um das Boot-Image auf die Diskette zu übertragen. Programme wie copy sind hier unbrauchbar, weil das Image zur direkten Übertragung erstellt wurde. Das Image stellt den gesamten Disketteninhalt dar, Spur für Spur, und nicht eine gewöhnliche Datei. Sie müssen es roh mit speziellen Werkzeugen (z.B. fdimage oder rawrite) übertragen, wie es in der Installationsanleitung zu &os; beschrieben ist. Wo befinden sich die Instruktionen zur Installation von &os;? Installationsanleitungen finden Sie im Handbucheintrag zur Installation von &os;. Was benötige ich zum Betrieb von &os;? Der Betrieb von &os; und neuer erfordert mindestens einen 486er Prozessor mit mindestens 24 MB RAM sowie mindestens 150 MB an Festplattenspeicher. Alle &os;-Versionen laufen mit einer einfachen MDA-Grafikkarte, für &xorg; benötigen Sie allerdings eine VGA- oder eine bessere Videokarte. Lesen Sie auch den Abschnitt Hardwarekompatibilität. Wie kann ich eine angepasste Installationsdiskette erstellen? Zurzeit gibt es keine Möglichkeit, nur die angepassten Installationsdisketten zu erstellen. Sie müssen sich eine ganz neues Release erstellen, das Ihre Installationsdiskette enthält. Wenn Sie eine modifizierte Ausgabe erstellen wollen, finden Sie eine Anleitung im Artikel &os; Release Engineering. Kann ich mehr als ein Betriebssystem auf meinem PC unterbringen? Sehen Sie sich Die Multi-OS-Seite an. Kann &windows; neben &os; existieren? Installieren Sie zuerst &windows;, dann &os;. Der Bootmanager von &os; kann dann entweder &windows; oder &os; booten. Falls Sie &windows; nach &os; installieren, wird es, ohne zu fragen, Ihren Bootmanager überschreiben. Lesen Sie den nächsten Abschnitt, falls das passieren sollte. &windows; hat meinen Bootmanager zerstört! Wie stelle ich ihn wieder her? Es gibt drei Möglichkeiten, den &os;-Bootmanager neu zu installieren: Unter DOS wechseln Sie in das Verzeichnis tools/ Ihrer &os;-Distribution und suchen nach bootinst.exe. Rufen sie es so auf: ...\TOOLS> bootinst.exe boot.bin und der Bootmanager wird neu installiert. Booten Sie &os; wieder mit der Bootdiskette und wählen Sie den Menüeintrag Custom Installation. Wählen Sie Partition. Wählen Sie das Laufwerk, auf dem sich der Bootmanager befand (wahrscheinlich der erste Eintrag) und wenn Sie in den Partitioneditor gelangen, drücken Sie als aller erstes (nehmen Sie z.B. keine Änderungen vor) (W)rite. Sie werden nach einer Bestätigung gefragt, wählen Sie &gui.yes; und vergessen Sie nicht, in der Bootmanager-Auswahl den &os; Boot Manager auszuwählen. Hierdurch wird der Bootmanager wieder auf die Festplatte geschrieben. Verlassen Sie nun das Installationsmenü und rebooten wie gewöhnlich von der Festplatte. Booten Sie &os; wieder mit der Bootdiskette (oder der CD-ROM) und wählen Sie den Menüpunkt Fixit. Wählen Sie die für Sie passende Option, entweder die Fixit-Diskette oder die CD-ROM Nummer 2 (die Option live Filesystem). Wechseln Sie zur Fixit-Shell und geben Sie den folgenden Befehl ein: Fixit# fdisk -B -b /boot/boot0 bootdevice Als bootdevice müssen Sie das von Ihrem System verwendete Gerät angeben, z.B. ad0 (erste IDE-Platte), ad4 (erste IDE-Platte an einem zusätzlichen Controller), da0 (erste SCSI-Platte), usw. Mein IBM Thinkpad Modell A, T oder X, hängt sich auf, wenn ich &os; zum ersten Mal starte. Was soll ich machen? Ein Fehler in den ersten BIOS-Versionen dieser Geräte führt dazu, dass sie die von &os; genutzte Partition für eine Suspend-To-Disk-Partition halten. Wenn das BIOS dann versucht, diese Partition auszuwerten, hängt sich das System auf. Laut IBM In einer Mail von Keith Frechette kfrechet@us.ibm.com. wurde der Fehler wurde in den folgenden BIOS-Versionen behoben: Gerät BIOS Version T20 IYET49WW oder neuer T21 KZET22WW oder neuer A20p IVET62WW oder neuer A20m IWET54WW oder neuer A21p KYET27WW oder neuer A21m KXET24WW oder neuer A21e KUET30WW Es ist möglich, dass neuere Version des IBM BIOS den Fehler wieder enthalten. Dieser Beitrag von &a.nectar; auf der Mailingliste &a.mobile; beschreibt eine Technik, die Ihnen weiterhelfen könnte, wenn Ihr IBM Laptop mit &os; nicht bootet und Sie eine neuere oder ältere BIOS-Version einspielen können. Wenn Ihr Thinkpad über eine ältere BIOS-Version verfügt und Sie das BIOS nicht aktualisieren können, ist eine der möglichen Lösungen, &os; zu installieren, die Partitions-ID zu ändern und danach neue Bootblocks zu installieren, die mit der geänderten ID umgehen können. Zunächst müssen Sie die Maschine so weit wiederherstellen, dass sie über den Selbst-Test hinauskommt. Dazu ist es erforderlich, dass das System beim Start keine Partitions-ID auf seiner primären Festplatte findet. Eine Variante ist, die Platte auszubauen und vorübergehend in einem älteren Thinkpad (z.B. dem Thinkpad 600) oder (mit einem passenden Adapter) in einen normalen PC einzubauen. Sobald dies erfolgt ist, können Sie die &os;-Partition löschen und die Festplatte wieder in das Thinkpad einbauen. Das Thinkpad sollte jetzt wieder starten können. Danach können Sie mit der nachfolgend beschriebenen Anleitung eine funktionsfähige &os;-Installation erhalten. Beschaffen Sie sich boot1 und boot2 von . Legen Sie diese Dateien so ab, dass Sie während der Installation darauf zugreifen können. Installieren Sie ganz wie gewohnt &os; auf dem Thinkpad. Allerdings dürfen Sie den Dangerously Dedicated-Modus nicht benutzen. Nach dem Abschluss der Installation dürfen Sie die Maschine nicht neu starten. Wechseln Sie zur Emergency Holographic Shell ( Alt F4 ) oder starten Sie eine fixit Shell. Benutzen Sie &man.fdisk.8;, um die Partitions-ID von &os; von 165 in 166 zu ändern (dieser Wert wird von OpenBSD benutzt). Kopieren Sie die Dateien boot1 und boot2 auf die lokale Festplatte. Installieren Sie boot1 und boot2 mit &man.disklabel.8; auf die &os;-Slice. &prompt.root; disklabel -B -b boot1 -s boot2 ad0sn Setzen Sie für n die Nummer der Slice ein, auf der sie FreeBSD installiert haben. Starten Sie das System neu. Am Boot-Prompt sollten Sie die Auswahl OpenBSD erhalten. Damit wird in Wirklichkeit &os; gestartet. Was Sie machen müssen, wenn Sie &os; und OpenBSD parallel installieren wollen, sollten Sie zu Übungszwecken einfach einmal selbst herausfinden. Kann ich &os; auf einer Festplatte mit beschädigten Blöcken installieren? Prinzipiell ja. Allerdings ist das keine gute Idee. Wenn Ihnen bei einer modernen IDE-Platte defekte Sektoren gemeldet werden, wird die Platte mit großer Wahrscheinlichkeit innerhalb kurzer Zeit vollständig ausfallen, da die Meldung ein Zeichen dafür ist, dass die für die Korrektur reservierten Sektoren bereits verbraucht wurden. Wir raten Ihnen, die Platte auszutauschen. Falls Sie ein SCSI-Laufwerk mit beschädigten Blöcken besitzen, lesen Sie diese Antwort. Wenn ich von der Installationsdiskette boote, geschehen merkwürdige Dinge! Was sollte ich tun? Falls Sie beobachten, dass ihr Rechner sich bis zum Stillstand abmüht oder spontan rebootet, während Sie versuchen, von der Installationsdiskette zu booten, sollten Sie sich drei Fragen stellen: Haben Sie eine brandneue, frisch formatierte, fehlerfreie Diskette benutzt (günstigerweise eine brandneue, direkt aus dem Karton und nicht eine Diskette aus einem Magazin, das schon seit drei Jahren unter Ihrem Bett lag)? Haben Sie das Floppy-Image im Binär- (oder Image) Modus heruntergeladen? (Schämen Sie sich nicht. Sogar die besten unter uns haben wenigstens einmal Binärdateien versehentlich im ASCII-Modus heruntergeladen!) Falls Sie &windows; 95 oder &windows; 98 benutzen, haben Sie es heruntergefahren und fdimage bzw. rawrite in einfachem, reinem DOS neu gestartet? Es scheint, dass diese Betriebssysteme Programme stören, die direkt auf Hardware schreiben, wie es das Erstellungsprogramm für die Diskette tut; selbst bei der Ausführung des Programms in einem DOS-Fenster in der grafischen Benutzeroberfläche kann dieses Problem auftreten. Es wurde auch darüber berichtet, dass &netscape; Probleme beim Herunterladen der Bootdisketten verursacht. Es ist also wahrscheinlich besser, einen anderen FTP-Client zu benutzen. Ich habe zur Installation von meinem ATAPI CD-ROM gebootet, aber das Installationsprogramm sagt mir, dass es kein CD-ROM gefunden hat. Was geht hier ab? Dieses Problem wird üblicherweise durch ein falsch konfiguriertes CD-ROM verursacht. Bei vielen PCs ist das CD-ROM der Slave am zweiten IDE-Controller, ein Master ist nicht vorhanden. Laut Spezifikation ist diese Konfiguration ungültig, aber &windows; verletzt die Spezifikation und das BIOS ignoriert sie, wenn es von einem CD-ROM booten soll. Daher konnten Sie zwar vom CD-ROM booten, während &os; es nicht für die Installation benutzen kann. Um dieses Problem zu lösen, müssen Sie entweder das CD-ROM als Master an den IDE-Controller anschließen oder dafür sorgen, dass an dem vom CD-ROM genutzten IDE-Controller das CD-ROM als Slave und ein anderes Gerät als Master angeschlossen ist. Kann ich auf meinem Laptop per PLIP (Parallel Line IP) installieren? Ja, Sie brauchen dazu nur ein ganz normales Laplink-Kabel. Weitere Informationen zum Thema Netzwerke am Druckerport finden sie im Kapitel PLIP des Handbuchs. Welche Geometrie sollte ich für ein Festplattenlaufwerk verwenden? Unter der Geometrie einer Festplatte verstehen wir die Anzahl Zylinder, Schreib-/Leseköpfen und Sektoren/Spur auf einer Festplatte. Im folgenden wird dafür der Übersichtlichkeit halber der Begriff C/H/S verwendet. Das BIOS des PCs berechnet mit diesen Angaben, auf welche Bereiche der Festplatte es für Schreib-/Lesezugriffe zugreifen muss). Aus einigen Gründen scheint dies gerade bei frischgebackenen Systemadministratoren für sehr viel Verwirrung zu sorgen. Zunächst einmal ist die physikalische Geometrie eines SCSI-Laufwerks vollkommen irrelevant, da &os; mit Blöcken arbeitet. Tatsächlich gibt es die physikalische Geometrie nicht, da die Sektordichte auf einer Festplatte variiert. Was die Hersteller als die wahre physikalische Geometrie bezeichnen, ist im allgemeinen die Geometrie, die aufgrund ihrer Ergebnisse im geringsten ungenutzten Speicher resultiert. Bei IDE-Platten arbeitet &os; mit C/H/S-Angaben, aber alle modernen Laufwerke wandeln diese intern ebenfalls in Blocknummern um. Wichtig ist nur die logische Geometrie. Das BIOS kann die logische Geometrie der Festplatte abfragen; die erhaltenen Daten werden dann vom BIOS bei Zugriffen auf die Festplatte genutzt. Da &os; das BIOS benutzt, während es bootet, ist es sehr wichtig, dass diese Angaben richtig sind. Insbesondere müssen alle Betriebssysteme mit derselben Geometrie arbeiten, falls Sie mehr als ein Betriebssystem auf einer Festplatte haben. Andernfalls werden Sie ernsthafte Bootprobleme bekommen! Bei SCSI-Festplatten hängt die zu verwendende Geometrie davon ab, ob der Extended Translation Support auf Ihrem Controller eingeschaltet ist (oft auch als Unterstützung für DOS-Platten >1GB oder ähnlich bezeichnet). Falls sie ausgeschaltet ist, benutzen Sie N Zylinder, 64 Köpfe und 32 Sektoren/Spur, wobei N die Kapazität der Festplatte in MB ist. Zum Beispiel sollten für eine 2 GB Festplatte 2048 Zylinder, 64 Köpfe und 32 Sektoren/Spur angegeben werden. Falls sie eingeschaltet ist (was oft der Fall ist, um bestimmte Einschränkungen von &ms-dos; zu umgehen) und die Plattenkapazität mehr als 1 GB beträgt, benutzen Sie M Zylinder, 63 Sektoren/Spur (nicht 64) und 255 Köpfe, wobei M der Plattenkapazität in MB, dividiert durch 7,844238 entspricht (!). Also würde unsere 2 GB Beispielplatte 261 Zylinder, 63 Sektoren/Spur und 255 Köpfe haben. Falls Sie sich hier nicht sicher sind oder &os; während der Installation die Geometrie nicht richtig erkennt, hilft es normalerweise, eine kleine DOS-Partition auf der Festplatte anzulegen. Das BIOS sollte dann in der Lage sein, die richtige Geometrie zu erkennen. Sie können die Partition jederzeit im Partitioneditor entfernen, falls Sie sie nicht behalten möchten. Allerdings kann Sie ganz nützlich sein, um Netzwerkkarten zu programmieren und ähnliches. Alternativ können Sie das frei verfügbare Programm pfdisk.exe verwenden. Sie finden es im Unterverzeichnis tools auf der &os; CD-ROM und allen &os; FTP-Servern). Mit diesem Programm können Sie herausfinden, welche Geometrie die anderen Betriebssysteme auf der Festplatte verwenden. Diese Geometrie können Sie im Partitioneditor eingeben. Gibt es irgendwelche Einschränkungen, wie ich die Festplatte aufteilen darf? Ja. Sie müssen sicherstellen, dass Ihre Rootpartition innerhalb der ersten 1024 Zylinder liegt, damit das BIOS den Kernel von Ihr booten kann. (Beachten Sie, dass es sich um eine Einschränkung durch das BIOS des PCs handelt und nicht durch &os;). Für ein SCSI-Laufwerk bedeutet dies normalerweise, dass sich die Rootpartition in den ersten 1024 MB befindet (oder in den ersten 4096 MB, falls die Extended Translation eingeschaltet ist - siehe die vorherige Frage). Der entsprechende Wert für IDE ist 504 MB. Verträgt sich &os; mit Plattenmanagern? &os; erkennt den Ontrack Disk Manager und berücksichtigt ihn. Andere Plattenmanager werden nicht unterstützt. Falls Sie die Festplatte nur mit &os; benutzen wollen, brauchen Sie keinen Plattenmanager. Wenn Sie Sie die Platte einfach in der vom BIOS maximal unterstützten Größe (normalerweise 504 Megabyte) konfigurieren, sollte &os; erkennen, wie viel Platz Sie tatsächlich haben. Falls Sie eine alte Festplatte mit einem MFM-Controller verwenden, könnte es sein, dass Sie &os; explizit angeben müssen, wie viele Zylinder es benutzen soll. Falls Sie die Festplatte mit &os; und einem anderen Betriebssystem benutzen wollen, sollten Sie auch in der Lage sein, ohne einen Plattenmanager auszukommen: stellen sie einfach sicher, dass sich die Bootpartition von &os; und der Bereich für das andere Betriebssystem in den ersten 1024 Zylindern befinden. Eine 20 Megabyte Bootpartition sollte völlig genügen, wenn Sie einigermaßen sorgfältig arbeiten. Beim ersten Booten von &os; erscheint Missing Operating System. Was ist passiert? Dies ist ein klassischer Fall von Konflikten bei den verwendeten Plattengeometrien von &os; und DOS oder anderen Betriebssystemen. Sie werden &os; neu installieren müssen. Bei Beachtung obiger Instruktionen wird in den meisten Fällen alles funktionieren. Wieso komme ich nicht weiter als bis zum F?-Prompt des Bootmanagers? Dies ist ein weiteres Symptom für das bereits in der vorherigen Frage beschriebene Problem. Ihre Einstellungen zur Geometrie im BIOS und in &os; stimmen nicht überein! Falls Ihr Controller oder BIOS Zylinderumsetzung (oft als >1GB drive support bezeichnet), probieren Sie eine Umsetzung dieser Einstellung und Neuinstallation von &os;. Muss ich den vollständigen Quellcode installieren? Im allgemeinen nicht. Wir empfehlen jedoch dringend die Installation des base Source-Kit, das viele der hier erwähnten Dateien enthält und des sys (Kernel) Source-Kit, das den Quellcode für den Kernel enthält. Außer dem Programm zur Konfiguration des Kernels (&man.config.8;) gibt es im System nichts, zu dessen Funktion der Quellcode erforderlich ist. Mit Ausnahme der Kernelquellen ist unsere Build-Struktur so aufgebaut, dass Sie den Quellcode von überall her per NFS read-only mounten und dennoch neue Binaries erstellen können. (Wegen der Einschränkung bezüglich der Kernelquellen empfehlen wir, diese nicht direkt nach /usr/src zu mounten, sondern irgendwo anders hin mit passenden symbolischen Links, um die Toplevel-Struktur des Quellbaumes zu duplizieren.) Die Quellen verfügbar zu haben und zu wissen, wie man ein System mit ihnen erstellt, wird es Ihnen wesentlich einfacher machen, zu zukünftigen Ausgaben von &os; zu wechseln. Um einen Teil der Quellen auszuwählen, verwenden Sie den Menüpunkt Custom, wenn Sie sich im Menü Distributions des Systeminstallationstools befinden. Muss ich einen Kernel erstellen? Ursprünglich war die Erstellung eines neuen Kernels bei fast jeder Installation von &os; erforderlich, aber neuere Ausgaben haben von der Einführung weitaus benutzerfreundlicherer Kernelkonfigurationswerkzeuge profitiert. Die Kernelkonfiguration erfolgt in der Regel durch die die deutlich flexibleren hints, die am Loader-Prompt eingegeben werden können. Es kann dennoch sinnvoll sein, einen neuen Kernel zu erstellen, der nur die benötigten Treiber enthält, um ein wenig Hauptspeicher zu sparen, für die meisten Systeme ist dies aber nicht mehr länger erforderlich. Soll ich DES, Blowfish oder MD5 zur Verschlüsselung der Passwörter benutzen? &os; benutzt standardmäßig MD5 zur Verschlüsselung der Passwörter. Es wird angenommen, dass diese Methode sicherer ist als das traditionell benutzte Verfahren, das auf dem DES Algorithmus basierte. Es ist immer noch möglich, DES-Passwörter zu benutzen, wenn Sie die Datei mit den Passwörtern mit älteren System austauschen müssen. &os; erlaubt es Ihnen, auch das sichere Blowfish-Verfahren für die Verschlüsselung der Passwörter einzusetzen. Das für neue Passwörter benutzte Verschlüsselungsverfahren wird über die Einstellung passwd_format in /etc/login festgelegt. Die möglichen Werte sind entweder des, blf (falls sie zur Verfügung stehen) oder md5. Weitere Informationen über die Einstellungen für den Login erhalten Sie in &man.login.conf.5;. Woran kann es liegen, dass ich zwar von der Diskette booten kann, aber nicht weiter als bis zur Meldung Probing Devices... komme? Falls Sie ein IDE &iomegazip;- oder &jaz;-Laufwerk eingebaut haben, entfernen Sie es und versuchen Sie es erneut. Solche Laufwerke könnten dem Bootvorgang stören. Nach der Installation des Systems können Sie das Laufwerk wieder einbauen. Dieser Fehler wird hoffentlich in einer späteren Version behoben werden. Wieso wird mit der Fehler panic: cant mount root gemeldet, wenn ich das System nach der Installation reboote? Dieser Fehler beruht auf Unstimmigkeiten zwischen den Festplatteninformationen im Bootblock und denen im Kernel. Der Fehler tritt normalerweise auf IDE-Systemen mit zwei Festplatten auf, bei denen die Festplatten als Master- oder Single-Device auf separaten IDE-Controllern angeschlossen sind und &os; auf der Platte am zweiten Controller installiert wurde. Der Bootblock vermutet, dass das System auf ad0 (der zweiten BIOS-Platte) installiert ist, während der Kernel der ersten Platte auf dem zweiten Controller die Gerätekennung ad2 zuteilt. Der Kernel versucht nach der Geräteüberprüfung die vom Bootblock angenommene Bootdisk ad0 zu mounten, obwohl sie in Wirklichkeit ad2 heißt - und scheitert. Tun Sie folgendes, um dieses Problem zu beheben: Rebooten Sie das System und drücken Sie Enter, wenn die Meldung Booting kernel in 10 seconds; hit [Enter] to interrupt erscheint. Dadurch gelangen Sie in den Boot Loader. Geben Sie nun set root_disk_unit="disk_number" ein. disk_number hat den Wert 0, wenn &os; auf dem Master des ersten IDE-Controllers installiert wurde; 1, wenn &os; auf dem Slave des ersten IDE-Controllers installiert wurde; 2, wenn &os; auf dem Master des zweiten IDE-Controllers installiert wurde; und 3, wenn &os; auf dem Slave des zweiten IDE-Controllers installiert wurde. Nach der Eingabe von boot sollte Ihr System jetzt korrekt starten. Damit Sie dieses Ritual nicht bei jedem Start des Systems durchführen müssen, sollten Sie die Zeile root_disk_unit="disk_number" in die Datei /boot/loader.conf.local eintragen. Stellen Sie eine ununterbrochene Folge der Festplatten her, indem Sie die &os;-Platte am ersten IDE-Controller anschließen. Gibt es eine Hauptspeicherbegrenzung? Hauptspeicherbegrenzung sind von der verwendeten Plattform abhängig. Bei einer &i386;-Standardinstallation werden maximal 4 GB Hauptspeicher unterstützt, mehr Speicher ist mittels &man.pae.4; verfügbar. Lesen Sie dazu die Anleitung, um 4 GB oder mehr Speicher auf &i386; zu verwenden. &os;/pc98 unterstützt maximal 4 GB Hauptspeicher, daher kann PAE auf diesen Systemen nicht verwendet werden. Sonstige von &os; unterstützte Architekturen haben ein sehr viel höheres theoretisches Speicherlimit (viele Terabytes). Wo liegen die Grenzen für FFS-Dateisysteme? Theoretisch liegt das Limit für FFS-Dateisysteme bei 8 Terabyte (2 G-Blöcke) oder 16 TB für die Standard-Blockgröße von 8 KB. In der Praxis setzt die Software das Limit auf 1 TB herab, aber durch Modifikationen sind auch Dateisysteme mit 4 TB möglich (und existieren auch). Die maximale Größe einer einzelnen FFS-Datei liegt bei ungefähr 1 G Blöcken (4 TB, falls die Blockgröße 4 KB beträgt). Maximale Dateigröße Blockgröße Geht Sollte Gehen 4 KB > 4 GB 4 TB - 1 8 KB > 32 GB 32 TB - 1 16 KB > 128 GB 32 TB - 1 32 KB > 512 GB 64 TB - 1 64 KB > 2048 GB 128 TB - 1
Wenn die im Dateisystem verwendete Blockgröße 4 KB beträgt, wird mit dreifacher Indirektion gearbeitet und die Limitierung sollte durch die höchste Blocknummer erfolgen, die mit dreifacher Indirektion dargestellt werden kann (ungefähr 10243 + 10242 + 1024). In Wirklichkeit liegt das Limit aber bei der (falschen) Anzahl von 1 G - 1 Blocknummern im Dateisystem. Die maximale Anzahl der Blocknummern müsste 2 G - 1 sein. Es gibt einige Fehler für Blocknummern nahe 2 G - 1, aber solche Blocknummern sind bei einer Blockgröße von 4 KB unerreichbar. Bei Blocknummern von 8 KB und größer sollte das Limit bei 2 G - 1 Blocknummern liegen, tatsächlich liegt es aber bei 1 G - 1 Blocknummern. Die Verwendung der korrekten Grenze von 2 G - 1 verursacht Probleme.
Wieso erhalte ich die Fehlermeldung archsw.readin.failed beim Start des Systems, nachdem ich einen neuen Kernel erstellt habe? Ihr System und Ihr Kernel sind nicht synchron - dies ist nicht erlaubt. Sie müssen Ihren Kernel mit make buildworld und make buildkernel aktualisieren. Sie können den zu bootenden Kernel direkt im zweiten Schritt angeben, indem Sie eine beliebige Taste drücken, wenn das | erscheint und bevor der Loader startet. Mein System stürzt beim Booten ab! Was kann ich tun? Deaktivieren Sie die ACPI-Unterstützung. Dazu drücken Sie beim Start des Bootloaders die Leertaste. Das System zeigt folgendes an: OK Geben Sie nun unset acpi_load und danach boot ein.
Hardware-Kompatibilität Allgemeines Ich will mir neue Hardware für mein &os;-System zulegen, was soll ich kaufen? Diese Frage wird ständig auf den &os;-Mailinglisten diskutiert. Da sich die Hardware ständig ändert, ist das allerdings keine Überraschung. Trotzdem sollten Sie unbedingt die Hardware-Informationen von &os; (&rel.current; oder &rel2.current;) und die Archive der Mailinglisten durchsehen, bevor Sie nach der neuesten/besten Hardware fragen. Normalerweise gab es kurz zuvor eine Diskussion über genau die Hardware, die Sie sich zulegen wollen. Wenn Sie sich einen Laptop zulegen wollen, sollten Sie einen Blick in das Archiv der Mailingliste &a.mobile; werfen. Ansonsten empfiehlt sich ein Blick in das Archiv von &a.questions; oder auch einer spezialisierte Mailingliste für diese Art von Hardware. Hauptspeicher Unterstützt &os; mehr als 4 GB Speicher (RAM)? Mehr als 16 GB? Mehr als 48 GB? Ja. Generell unterstützt &os; als Betriebssystem so viel physischen Speicher (RAM), wie die Plattform auf der es läuft. Achten Sie darauf, dass verschiedene Plattformen unterschiedliche Speichergrenzen besitzen. So wird z.B. &i386; ohne PAE höchstens 4 GB Speicher (normalerweise weniger als das wegen des PCI-Addressraums), dagegen wird &i386; mit PAE höchstens 64 GB Speicher bereitstellen. Momentan erhältliche AMD64 Plattformen können bis zu 1 TB physischen Speicher ansprechen. Warum zeigt &os; weniger als 4 GB Speicher an, wenn es auf einer &i386; Maschine installiert wird? Der Gesamtadressraum beträgt auf &i386; Maschinen 32-Bit, was bedeutet, dass maximal 4 GB Speicher addressiert (verwaltet) werden kann. Weiterhin sind viele Adressen in diesem Bereich von der Hardware für bestimmte Aufgaben reserviert, um z.B. PCI-Geräte zu benutzen und zu steuern, auf Videospeicher zuzugreifen und so weiter. Aus diesem Grund ist die Gesamtmenge an Speicher, die vom Betriebssystem für den Kernel und Anwendungen verwendet werden kann, auf wesentlich weniger als 4 GB begrenzt. Normalerweise sind 3.2 GB bis 3.7 GB das Maximum an verfügbarem Speicher in dieser Konfiguration. Um auf mehr als 3.2 GB bis 3.7 GB des installierten Speichers (was bis zu 4 GB, aber aber auch mehr als 4 GB bedeuten kann) zuzugreifen, muss eine spezielle Manipulation, genannt PAE, benutzt werden. PAE steht für Physical Address Extension und ist eine Möglichkeit für 32-Bit x86-CPUs mehr als 4 GB Speicher zu addressieren. Es organisiert den Speicher, der andererseits wegen Addressreservierungen für Hardwaregeräte oberhalb der 4 GB Grenze liegt, um und benutzt diesen als zusätzlichen physischen Speicher (lesen Sie dazu &man.pae.4;). Der Einsatz von PAE ist mit ein paar Nachteilen verbunden: diese Speicherzugriffsmethode ist ein bisschen langsamer als die normale Methode (ohne PAE) und ladbare Module (beschrieben in &man.kld.4;) werden nicht unterstützt. Das bedeutet, dass alle Treiber in den Kernel eingebaut sein müssen. Die am häufigsten verwendete Vorgehensweise, PAE zu aktivieren ist die, einen neuen Kernel mit der speziell dafür vorgesehenen Kernelkonfigurationsdatei, PAE genannt, zu bauen, die bereits so eingestellt ist, dass ein funktionierender Kernel erstellt wird. Beachten Sie, dass manche Einträge in dieser Kernelkonfigurationsdatei zu konservativ eingestellt sind und dass manche Treiber, die nicht für den Einsatz mit PAE vorgesehen sind, trotzdem funktionieren. Als Faustregel kann man sagen, dass wenn der Treiber auf 64-Bit Architekturen (like AMD64) läuft, er auch mit PAE lauffähig ist. Wenn Sie ihre eigene Kernelkonfigurationsdatei erstellen möchten, können Sie PAE aktivieren, indem Sie die folgende Zeile zu ihrer Konfiguration hinzufügen: options PAE PAE wird heutzutage nicht sehr häufig angewendet, da die Mehrzahl an neuer x86-Hardware auch den Betrieb im 64-Bit Modus erlaubt, auch als AMD64 oder &intel; 64 bekannt. Es hat viel mehr Adressraum und benötigt solche Manipulationen nicht. &os; unterstützt AMD64 und es wird empfohlen, diese &os; Version anstatt der &i386; Version einzusetzen, wenn 4 GB oder mehr Speicher gebraucht werden. Architekturen und Prozessoren Unterstützt &os; neben x86 auch andere Architekturen? Ja. &os; ist zurzeit für die Intel x86 und AMD64 Architekturen verfügbar. Intel EM64T, IA-64, &arm;, &powerpc;, sun4v und &sparc64; werden ebenfalls unterstützt. Die Neuzugänge auf der Liste der in Zukunft unterstützten Plattformen sind &mips; und &s390;. Abonnieren Sie die Mailingliste &a.mips;, wenn Sie mehr über den Stand der Entwicklung erfahren wollen. Schließen Sie sich der Mailingliste &a.platforms; an, wenn Sie an grundsätzlichen Diskussionen über neue Architekturen interessiert sind. Falls Ihre Maschine eine andere Architektur aufweist und Sie unbedingt sofort etwas benötigen, schlagen wir vor, dass Sie sich einmal NetBSD oder OpenBSD ansehen. Unterstützt &os; Symmetric-Multiproccessing (SMP)? Symmetric-Multiproccessing (SMP) Systeme werden generell von &os; unterstützt, obwohl in manchen Fällen durch Fehler im BIOS oder Mainboard Probleme auftreten. Lesen Sie die Mailingliste &a.smp;, wenn Sie weitere Hinweise benötigen. &os; nutzt die Vorteile von HyperThreading (HTT) Unterstützung von Intel-Prozessoren, die diese Eigenschaft besitzen. Ein Kernel mit der options SMP Zeile wird automatisch die zusätzlichen logischen Prozessoren erkennen. Der Standard &os;-Scheduler behandelt die logischen Prozessoren auf die gleiche Weise wie zusätzliche physische Prozessoren. Mit anderen Worten, es wird nicht der Versuch unternommen, die Entscheidungen des Schedulers zu optimieren, da sich die logischen Prozessoren innerhalb der gleichen CPU die Ressourcen teilen. Weil diese naive Planung in schlechterer Leistung resultieren kann, ist es unter Umständen hilfreich, die logischen Prozessoren über die sysctl Variable machdep.hlt_logical_cpus zu deaktivieren. Es ist auch möglich, jede CPU in der Warteschleife mit der sysctl Variable machdep.hlt_cpus anzuhalten. Weitere Informationen finden Sie in der Manualpage &man.smp.4;. Festplatten, Bandlaufwerke, sowie CD- und DVD-Laufwerke Welche Arten von Festplatten werden von &os; unterstützt? &os; unterstützt EIDE-, SATA-, SCSI- und SAS-Laufwerke (mit kompatiblen Controllern - siehe folgenden Abschnitt), sowie alle Laufwerke, die die original Western Digital-Schnittstelle (MFM, RLL, ESDI und natürlich IDE) benutzen. Ein paar Controller mit proprietären Schnittstellen könnten nicht laufen: halten Sie sich an WD1002/3/6/7-Schnittstellen und Clones. Welche SCSI- oder SAS-Controller werden unterstützt? Sie finden eine vollständige und aktuelle Liste in den Hardware-Informationen zu &os; (&rel.current; oder &rel2.current;). Welche Arten von Bandlaufwerken werden unterstützt? &os; unterstützt SCSI-, QIC-36- (mit QIC-02-Schnittstelle) und QIC-40/80-Bandlaufwerke (diskettenbasiert). Hierzu gehören auch 8-mm (aka Exabyte) und DAT-Laufwerke. Die QIC-40/80-Laufwerke sind bekanntlich sehr langsam. Einige der frühen 8-mm-Laufwerke sind nicht besonders kompatibel zu SCSI-2 und könnten unter &os; nicht einwandfrei funktionieren. Unterstützt &os; Bandwechsler? Das Gerät &man.ch.4; und das Kommando chio unterstützen Bandwechsler. Details zum Betrieb des Wechslers finden Sie in der Hilfeseite &man.chio.1;. Falls Sie nicht AMANDA oder ein anderes Produkt benutzen, das den Wechsler bereits kennt, bedenken Sie, dass die Programme nur wissen, wie sie ein Band von einem Punkt zu einem anderen bewegen müssen. Sie selbst müssen sich also merken, in welchem Einschub sich ein Band befindet und zu welchem Einschub das Band, das sich gerade im Laufwerk befindet, zurück muss. Welche CD-ROM-Laufwerke werden von &os; unterstützt? Jedes an einem unterstützten Controller angeschlossene SCSI-Laufwerk wird unterstützt. Die folgenden proprietären CD-ROM-Schnittstellen werden ebenfalls unterstützt: Mitsumi LU002 (8-Bit), LU005 (16-Bit) und FX001D (16-Bit 2x Speed). Sony CDU 31/33A Sound Blaster Non-SCSI CD-ROM Matsushita/Panasonic CD-ROM ATAPI compatible IDE CD-ROMs Von allen Nicht-SCSI-Laufwerken ist bekannt, dass sie im Vergleich zu SCSI-Laufwerken extrem langsam sind. Einige ATAPI-CD-ROMs könnten nicht funktionieren. &os; kann direkt von der offiziellen &os; CD-ROM, sowie den CD-ROMs von Daemon News und &os; Mall, gebootet werden. Welche CD-Brenner werden von &os; unterstützt? &os; unterstützt alle ATAPI-kompatiblen IDE CD-R und CD-RW Brenner. Lesen Sie dazu auch &man.burncd.8;. &os; unterstützt ebenfalls SCSI CD-R und CD-RW Brenner. Installieren und benutzen Sie das Paket cdrecord aus der Ports-Sammlung. Dazu müssen Sie allerdings das Gerät pass mit in Ihren Kernel aufnehmen. Unterstützt &os; &iomegazip;-Laufwerke? &os; unterstützt alle gängigen SCSI- und ATAPI-&iomegazip;-Laufwerke. Ihr SCSI-ZIP-Laufwerk darf nur mit den SCSI-Ziel-IDs 5 oder 6 laufen, aber Sie können sogar davon booten, falls das BIOS Ihres Hostadapters dies unterstützt. Es ist nicht bekannt, welche Hostadapter das Booten von anderen Zielen als 0 oder 1 erlauben; daher werden Sie in ihren Handbüchern nachsehen müssen, wenn Sie dieses Merkmal benutzen möchten. &os; unterstützt ZIP-Laufwerke, die an der parallelen Schnittstelle angeschlossen sind. Der Kernel sollte die folgenden Treiber enthalten: scbus0, da0, ppbus0 und vp0 (der GENERIC-Kernel enthält alle, außer vp0). Wenn diese Treiber vorhanden sind, sollte das Laufwerk an der parallelen Schnittstelle als /dev/da0s4 verfügbar sein. Zip-Datenträger können mit mount /dev/da0s4 /mnt ODER (DOS-formatierte) mount -t msdosfs /dev/da0s4 /mnt gemountet werden. Lesen Sie auch den FAQ-Eintrag zu Wechseldatenträgern und die Anmerkungen zum Thema Formatierung im Kapitel Administration. Unterstützt &os; &jaz;, EZ und andere Wechsellaufwerke? Ja. Bei den meisten dieser Geräte handelt es sich um SCSI-Geräte, die von &os; auch als solche angesprochen werden. Lediglich das IDE-EZ-Laufwerk wird als IDE-Laufwerk angesprochen. Schalten Sie die Laufwerke ein, bevor Sie Ihr System booten. Müssen Sie Medien im laufenden Betrieb wechseln, sollten Sie zuvor &man.mount.8;, &man.umount.8;, sowie &man.camcontrol.8; (für SCSI-Laufwerke) oder &man.atacontrol.8; (für IDE-Laufwerke), sowie den Abschnitt zur Nutzung von Wechsellaufwerken dieser FAQ lesen. Tastaturen und Mäuse Unterstützt &os; meine Tastatur mit USB-Anschluss? Ja. &os; unterstützt USB-Tastaturen. Wenn Sie die Unterstützung für USB-Tastaturen konfiguriert haben, ist die AT-Tastatur als /dev/kbd0 und die USB-Tastatur als /dev/kbd1 verfügbar. Dies gilt natürlich nur, wenn beide Tastaturen angeschlossen sind; falls nur die USB-Tastatur angeschlossen ist, ist diese als /dev/ukbd0 verfügbar. Wenn Sie die USB-Tastatur an der Systemkonsole benutzen wollen, müssen Sie dies dem System explizit mitteilen. Dazu muss das folgende Kommando während des Systemstarts ausgeführt werden: &prompt.root; kbdcontrol -k /dev/kbd1 < /dev/console > /dev/null Wenn Sie nur die USB-Tastatur angeschlossen haben, ist diese als /dev/ukbd0 verfügbar; daher muss in diesem Fall das folgende Kommando benutzt werden: &prompt.root; kbdcontrol -k /dev/ukbd0 < /dev/console > /dev/null Um diese Änderung auch noch nach dem Neustarten verfügbar zu haben, tragen Sie dieses Kommando in die Datei /etc/rc.conf ein. Sobald Sie diese Schritte durchgeführt haben, sollte die USB-Tastatur ohne weitere Änderungen auch unter X benutzbar sei. Benutzen Sie dieses Kommando, wenn Sie wieder zur Standardtastatur wechseln wollen: &prompt.root; kbdcontrol -k /dev/kbd0 > /dev/null Um die gleichzeitige Verwendung der zweiten USB-Tastatur und der AT-Tastatur auf der selben Konsole mittels des &man.kbdmux.4; Treibers zu ermöglichen, geben Sie folgendes ein: &prompt.root; kbdcontrol -K < /dev/console > /dev/null &prompt.root; kbdcontrol -a atkbd0 < /dev/kbdmux0 > /dev/null &prompt.root; kbdcontrol -a ukbd1 < /dev/kbdmux0 > /dev/null &prompt.root; kbdcontrol -k /dev/kbdmux0 < /dev/console > /dev/null Lesen Sie die &man.ukbd.4;, &man.kbdcontrol.1; und &man.kbdmux.4; Manualpages, um weitere Informationen zu erhalten. Zurzeit kann es noch Probleme geben, wenn Sie eine USB-Tastatur im laufenden Betrieb einstecken oder abziehen. Um Probleme zu vermeiden, sollten Sie die Tastatur anschließen, bevor Sie das System anschalten und die Tastatur nicht abziehen, solange das System noch läuft. Ich habe eine unübliche Busmaus. Wie muss ich sie konfigurieren? &os; unterstützt die Busmaus und InPort-Busmaus von Herstellern wie Microsoft, Logitech und ATI. Der Gerätetreiber ist im GENERIC-Kernel allerdings nicht eingebunden. Wenn Sie den Bus-Gerätetreiber benötigen, müssen Sie daher einen angepassten Kernel erstellen. Dazu fügen Sie die folgende Zeile in Ihre Kernelkonfigurationsdatei ein: device mse0 at isa? port 0x23c irq5 Die Busmaus wird üblicherweise zusammen mit einer speziellen Karte ausgeliefert. Sie könnte es Ihnen ermöglichen, andere Werte für die Port-Adresse und den Interrupt zu setzen. Weitere Informationen finden Sie in Handbuch zu Ihrer Maus und in der &man.mse.4; Manualpage. Wie benutze ich meine PS/2 (Mouse-Port oder Tastatur)-Maus? PS/2 Mäuse werden von &os; unterstützt. Der notwendige Gerätetreiber, psm, ist bereits im GENERIC-Kernel enthalten. Wenn Sie einen angepassten Kernel ohne diesen Treiber benutzen, müssen Sie folgende Zeile in Ihre Kernelkonfigurationsdatei einfügen und den Kernel neu kompilieren: device psm0 at atkbdc? irq 12 Wenn der Kernel das Gerät psm0 beim Booten korrekt erkennt, stellen Sie sicher, dass sich im Verzeichnis /dev ein Eintrag für psm0 befindet. Kann man die Maus irgendwie außerhalb des X Window Systems benutzen? Falls Sie den normalen Konsolentreiber &man.syscons.4; benutzen, können Sie den Mauszeiger auf Textkonsolen zum Kopieren und Einfügen von Text verwenden. Starten Sie den Mausdämon &man.moused.8; und schalten Sie den Mauszeiger auf der virtuellen Konsole ein: &prompt.root; moused -p /dev/xxxx -t yyyy &prompt.root; vidcontrol -m on xxxx ist der Gerätename der Maus und yyyy ist das Protokoll. Der Mausdämon erkennt die Protokolle der meisten Mäuse (mit Ausnahme alter serieller Mäuse) automatisch, wenn Sie auto für das Protokoll angeben. Falls das Protokoll nicht automatisch erkannt wird, finden Sie die unterstützten Protokolle in der &man.moused.8; Manualpage. Wenn Sie eine PS/2-Maus besitzen und diese beim Systemstart aktivieren wollen, tragen Sie die Zeile moused_enable="YES" in die Datei /etc/rc.conf ein. Falls Sie den Mausdämon auf allen virtuellen Bildschirmen anstatt nur auf der Konsole benutzen wollen, tragen Sie außerdem allscreens_flags="-m on" in /etc/rc.conf ein. Während der Mausdämon läuft, muss der Zugriff auf die Maus zwischen dem Mausdämon und anderen Programmen, wie X Windows, koordiniert werden. Die FAQ Warum funktioniert meine meine Maus unter X nicht? enthält weitere Details. Wie funktioniert das Kopieren und Einfügen von Text mit der Maus auf einer Textkonsole? Wenn Sie es geschafft haben, den Mausdämon zu starten (wie im vorherigen Abschnitt gezeigt), halten Sie die linke Maustaste gedrückt und bewegen Sie die Maus, um einen Textabschnitt zu markieren. Dann drücken Sie die mittlere Maustaste, um den Text an der Cursorposition einzufügen. Wenn Sie keine 3-Tasten-Maus besitzen, können Sie die mittlere Maustaste mit einer Tastenkombination emulieren oder die Funktion der mittleren Taste auf eine andere Taste legen. Einzelheiten dazu enthält die Hilfeseite &man.moused.8;. Meine Maus hat ein neumodisches Rad und mehr Knöpfe. Kann ich sie in &os; benutzen? Unglücklicherweise lautet die Antwort: Vielleicht. Solche Mäuse mit zusätzlichen Extras erfordern in den meisten Fällen spezielle Treiber. Wenn der Gerätetreiber für die Maus oder das Anwendungsprogramm keine spezielle Unterstützung für die Maus bietet, wird sie sich wie eine gewöhnliche Maus mit zwei oder drei Knöpfen verhalten. Ob und wie Sie das Rad unter X benutzen können, können Sie im passenden Abschnitt der FAQ erfahren. Wie benutze ich Maus/Trackball/Touchpad auf meinem Laptop? Bitte lesen Sie die Antwort zur vorherigen Frage. Wie kann ich die Delete-Taste in der sh und csh einsetzen? Für die Bourne Shell fügen Sie die folgende Zeile in die Datei .shrc ein (lesen Sie dazu auch die Manualpages &man.sh.1; sowie &man.editrc.5;). bind ^? ed-delete-next-char # for console bind ^[[3~ ed-delete-next-char # for xterm Für die C Shell nehmen Sie hingegen die folgende Zeile in die Datei .cshrc auf (lesen Sie dazu auch die Manualpage &man.csh.1;). bindkey ^? delete-char # for console bindkey ^[[3~ delete-char # for xterm Weitere Informationen zu diesem Thema finden sich auch hier. Netzkarten und serielle Geräte Welche Netzwerkkarten unterstützt &os;? In den Hardware Informationen zu jedem &os; Release werden die unterstützten Karten aufgezählt. Unterstützt &os; Software Modems, wie die Winmodems? &os; unterstützt viele Software-Modems, wenn Sie zusätzliche Software installieren. Der Port comms/ltmdm bietet zum Beispiel Unterstützung für Modems, die auf dem oft verwendeten Lucent LT Chipsatz basieren. Sie können &os; nicht über ein Software-Modem installieren, diese Software kann nur installiert werden, nachdem das Betriebssystem installiert wurde. Gibt es einen &os;-Treiber für die Karten der Serie 43xx von Broadcom? Nein, und es wird wohl auch nie einen geben. Broadcom weigert sich, Informationen zu ihren drahtlosen Chipsätzen zu veröffentlichen. Wahrscheinlich liegt dies daran, dass Broadcom auch softwaregesteuerte Radios herstellt. Damit ihre Produkte von der FCC zugelassen werden, muss sichergestellt sein, dass Benutzer nicht in der Lage sind, Betriebsfrequenzen, Modulationsparameter, Ausgangsleistung und andere Werte nach Belieben einzustellen. Ohne solche Informationen ist es aber nahezu unmöglich, einen Treiber zu programmieren. Welche seriellen Multi-Port-Karten werden von &os; unterstützt? Es existiert eine Liste der unterstützten Karten im Abschnitt Serielle Datenübertragung des Handbuchs. Von einigen NoName-Nachbauten ist ebenfalls bekannt, dass sie funktionieren, speziell von den AST-kompatiblen. In &man.sio.4; finden Sie weitere Informationen zur Konfiguration solcher Karten. Wie kann ich den boot:-Prompt auf einer seriellen Konsole erscheinen lassen? Lesen Sie diesen Abschnitt des Handbuchs. Soundkarten Welche Soundkarten werden von &os; unterstützt? &os; unterstützt verschiedene Soundkarten. Lesen Sie die &os; Release Informationen sowie &man.snd.4;, wenn Sie genauere Informationen benötigen. MPU-401 und kompatible MIDI-Karten werden begrenzt unterstützt. Ebenso unterstützt werden Karten, die der µsoft; Sound System-Spezifikation entsprechen. Das gilt nur für Sound! Dieser Treiber unterstützt keine CD-ROMs, SCSI oder Joysticks auf diesen Karten, außer der &soundblaster;. Die &soundblaster;-SCSI-Schnittstelle und einige Nicht-SCSI-CD-ROMs werden unterstützt, Sie können von diesen Geräten aber nicht booten. Abhilfen für fehlenden Sound bei Verwendung des &man.pcm.4;-Treibers? Einige Soundkarten setzen die Lautstärke bei jedem Systemstart auf 0. In diesem Fall müssen Sie nach jedem Bootvorgang den folgenden Befehl ausführen: &prompt.root; mixer pcm 100 vol 100 cd 100 Sonstige Hardware Unterstützt &os; Power-Management auf meinem Laptop? &os; unterstützt APM auf einigen Systemen. Lesen Sie dazu auch &man.apm.4;. &os; unterstützt einen Großteil der ACPI-Funktionen moderner Hardware. Lesen Sie dazu auch &man.acpi.4;. Unterstützt Ihr System sowohl APM als auch ACPI, können Sie beide Systeme testen und sich für das System entscheiden, das Ihren Anforderungen am besten entspricht. Wie kann ich ACPI deaktivieren? Fügen Sie die Zeile hint.acpi.0.disabled="1" in die Datei /boot/device.hints ein. Wieso hängt sich mein Micron-System beim Booten auf? Lesen Sie die vorherige Antwort. Wenn ich ein System mit einem ASUS K7V Mainboard von der Bootdiskette starte, hängt sich das System auf. Wie kann ich dieses Problem lösen? Schalten Sie im BIOS die Option boot virus protection aus. Warum arbeitet meine &tm.3com; PCI-Netzwerkkarte in meinem Micron-Computer nicht? Einige Micron Motherboards besitzen eine nicht-konforme PCI-BIOS-Implementierung, die die PCI-Geräte nicht an den angegebenen Adressen konfiguriert. Hierdurch entstehen Probleme, wenn &os; bootet. Deaktivieren Sie die Option Plug and Play Operating System im BIOS, um das Problem zu umgehen. Fehlerbehebung Warum zeigt &os; eine falsche Speichergröße auf &i386; Hardware an? Das liegt sehr wahrscheinlich an den Unterschieden zwischen physikalischen und virtuellen Speicheraddressen. Bei moderner PC-Hardware ist es üblich, den Speicherbereich zwischen 3,5 und 4 Gigabyte für spezielle Aufgaben (normalerweise für PCI) zu reservieren. Dieser Adressbereich wird dabei dazu verwendet, um auf PCI-Hardware zuzugreifen. Dadurch kann in diesem Speicherbereich kein physikalischer Speicher verwaltet werden. Was mit dem in diesen Bereich gehörenden physikalischen Speicher passiert, hängt von der von Ihnen eingesetzten Hardware ab. Unglücklicherweise gibt es noch immer Hardware, die hier gar nichts macht. In diesem Fall ist Ihr System nicht in der Lage, auf diese 500 Megabyte des RAMs zuzugreifen. Ein Großteil der heute existierenden Hardware ist aber inzwischen in der Lage, diesen Speicherbereich in einen höheren Speicherbereich umzulenken, damit Sie weiterhin darauf zugreifen können. Allerdings kann es durch dieses Umlenken zu verwirrende Meldungen während des Systemstarts kommen. Unter 32-Bit-Versionen von &os; scheint dieser Speicherbereich nicht verfügbar zu sein, da er in einen Bereich oberhalb von 4 Gigabyte übertragen wurde, auf den ein 32-Bit-Kernel allerdings nicht zugreifen kann. Ist dies bei Ihnen der Fall, müssen Sie die PAE-Unterstützung in Ihren Kernel kompilieren. Lesen Sie dazu auch die entsprechenden Einträge über Speicherbegrenzungen und unterschiedliche Speicherbegrenzungen auf verschiedenen Plattformen. Verwenden Sie hingegen eine 64-Bit-Version von &os; oder einen 32-Bit-Kernel mit aktivierter PAE-Unterstützung, ist &os; in der Lage, diesen Speicherbereich korrekt zu erkennen und umzulenken, damit Sie weiterhin darauf zugreifen können. Allerdings wird, aufgrund der beschriebenen Umbelegung, in diesem Fall beim Systemstart mehr Speicher angezeigt, als tatsächlich auf Ihrem System vorhanden ist. Dies ist aber normal und wird nach dem Ende des Systemstarts automatisch korrigiert. Was sollte ich tun, wenn auf meiner Festplatte fehlerhafte Blöcke sind? SCSI-Laufwerke sollten in der Lage sein, diese automatisch zu verlagern. Bei einigen Laufwerken ist diese Eigenschaft jedoch aus unerfindlichen Gründen bei der Auslieferung ausgeschaltet... Um sie einzuschalten, müssen Sie den Page-Mode des ersten Gerätes editieren. Unter &os; können Sie das (als root) mit folgendem Befehl tun &prompt.root; camcontrol modepage sd0 -m 1 -e -P 3 und die Werte für AWRE und ARRE von 0 auf 1 ändern: AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 Moderne IDE-Controller sind in der Lage, fehlerhafte Blöcke automatisch zu verlagern. Diese Funktionen sind bereits ab Werk aktiviert. Werden dennoch fehlerhafte Blöcke gemeldet (egal auf welchem Laufwerk), sollten Sie über den Kauf einer neuen Platte nachdenken. Zwar könnte es Ihnen mit Diagnoseprogrammen des Plattenherstellers gelingen, diese fehlerhaften Blöcke zu sperren. Allerdings können Sie damit den endgültigen Ausfall der Platte bestenfalls hinauszögern. Wieso wird der SCSI-Controller meines HP Netserver nicht erkannt? Hierbei handelt es sich um ein bekanntes Problem. Der auf dem Board befindliche EISA-SCSI-Controller auf dem HP Netserver belegt die EISA-Slotnummer 11, wodurch sich alle wirklichen EISA-Slots vor ihm befinden. Leider kollidiert der Adressraum von EISA-Slots >=10 mit dem Adressraum, der PCI zugeordnet ist und die Autokonfiguration von &os; kann mit dieser Situation derzeit nicht besonders gut umgehen. Die einfachste Alternative ist, diese Kollision einfach zu leugnen. Setzen Sie dazu die Kerneloption EISA_SLOTS auf den Wert 12. Konfigurieren und kompilieren Sie den Kernel, wie im Handbucheintrag zur Kernelkonfiguration beschrieben. Dies bringt Ihnen natürlich das klassische Huhn-Ei-Problem, wenn Sie auf einer solchen Maschine installieren wollen. Um dieses Problem zu umgehen, existiert ein spezieller Hack in UserConfig. Benutzen Sie nicht die visuelle Schnittstelle, sondern die rohe Kommandozeilenschnittstelle. Geben Sie einfach den folgenden Befehl am Prompt ein und Sie können Ihr System ganz normal installieren: eisa 12 quit Sie sollten auf jeden Fall einen angepassten Kernel zu kompilieren und installieren. Zukünftige Versionen werden hoffentlich eine passende Lösung für dieses Problem beinhalten. Sie können keine dangerously dedicated Platte auf einem HP Netserver verwenden. Lesen Sie weitere Informationen finden Sie in diesem Hinweis. Was bedeuten die ständigen Meldungen ed1: timeout? Dies wird meistens durch einen Interruptkonflikt verursacht (z.B., wenn zwei Karten den selben Interrupt benutzen). Booten Sie mit der Option und ändern Sie die Einträge zu ed0/de0/... (d.h. Ihrem Board entsprechend). Wenn Sie den BNC-Anschluss Ihrer Netzwerkkarte benutzen, könnte es auch sein, dass es sich Geräte-Timeouts aufgrund fehlerhafter Terminierung handelt. Um dies zu überprüfen, verbinden Sie einen Terminator direkt mit der Netzwerkkarte (ohne Kabel) und beobachten Sie, ob die Fehlermeldungen verschwinden. Einige NE2000 kompatible Karten melden diesen Fehler, wenn keine Verbindung am UTP-Eingang existiert oder wenn das Kabel nicht eingesteckt ist. Warum funktioniert meine &tm.3com; 3C509 plötzlich nicht mehr? Diese Karte ist dafür berüchtigt, ihre Konfiguration zu vergessen. Sie müssen die Karte mit dem DOS-Programm 3c5x9.exe neu konfigurieren. Mein an der parallel Schnittstelle angeschlossener Drucker ist unglaublich langsam. Was kann ich tun? Falls das einzige Problem ist, dass er schrecklich langsam ist, dann sollte Sie versuchen, die Kommunikationseinstellungen der parallelen Schnittstellen zu ändern, wie es im Kapitel Drucken des Handbuchs beschrieben ist. Wieso brechen meine Programme gelegentlich mit Signal 11-Fehlern ab? Das Signal 11 wird generiert, wenn ein Prozess versucht, auf Speicher zuzugreifen, obwohl er vom Betriebssystem dazu nicht befugt wurde. Wenn Ihnen das scheinbar zufällig immer wieder passiert, sollten Sie der Sache einmal auf der Grund gehen. Das Problem hat in der Regel eine der folgenden Ursachen: Wenn das Problem nur in einer bestimmten Anwendung auftritt, die Sie selbst entwickeln, dann ist es wahrscheinlich ein Fehler in Ihren Sourcen. Wenn das Problem in einem Teil von &os; auftritt, könnte es natürlich auch ein Fehler sein; aber in den meisten Fällen werden diese Probleme gefunden und behoben, bevor die typischen Leser der FAQ (wir) diese Teile der Sourcen benutzen können (dafür gibt es schließlich -CURRENT). Wenn der Fehler auftritt, wenn Sie ein Programm compilieren aber dabei immer wieder an anderer Stelle auftritt, dann ist das ein ganz eindeutiger Hinweis, dass das Problem nicht bei &os; liegt. Nehmen wir zum Beispiel an, dass Sie make buildworld ausführen und die Compilierung von ls.c in ls.o abbricht. Wenn Sie nochmal make buildworld durchführen und die Compilierung an der gleichen Stelle abbricht, handelt es sich um einen Fehler in den Sourcen. Aktualisieren Sie Ihre Sourcen und versuchen Sie es noch einmal. Wenn der Fehler jedoch an einer anderen Stelle auftritt, liegt das Problem mit an Sicherheit grenzender Wahrscheinlichkeit bei Ihrer Hardware. Was Sie tun sollten: Im ersten Fall können Sie einen Debugger wie z.B. &man.gdb.1; benutzen, um die Stelle im Programm zu finden, an der auf eine falsche Adresse zugegriffen wird und danach den Fehler beheben. Im zweiten Fall müssen Sie sicherstellen, dass das Problem nicht von Ihrer Hardware verursacht wird. Typische Ursachen dafür sind unter anderem: Es könnte sein, dass Ihren Festplatten zu warm werden: Überprüfen Sie, ob die Lüfter in Ihrem Gehäuse noch funktionieren, damit Ihre Festplatten (und andere Hardware) nicht heißlaufen. Der Prozessor überhitzt, weil Sie Ihn übertaktet haben oder der CPU-Kühler ausgefallen ist. Sie müssen sicherstellen, dass Sie Ihre Hardware unter den Bedingungen betreiben, für die sie spezifiziert ist, zumindest während Sie versuchen, das Problem zu lösen. Mit anderen Worten: Betreiben Sie Ihre CPU mit der normalen Taktfrequenz. Wenn Sie übertakten, sollten Sie daran denken, dass ein langsames System deutlich billiger ist als ein defektes System. Die große Masse hat nicht sehr häufig Mitgefühl mit Problemen bei übertakteten System, auch wenn Sie es für ungefährlich halten. Unzuverlässiger Speicher: Wenn Sie mehr als ein SIMM/DIMM installiert haben, sollten Sie sie alle ausbauen und die Maschine testweise mit jedem SIMM oder DIMM einzeln betreiben. So können Sie feststellen, ob die Ursache ein einzelnes SIMM/DIMM oder auch eine Kombination von Modulen ist. Zu optimistische Einstellung des Mainboards: In Ihrem BIOS und mit den Jumpern auf dem Mainboard können Sie diverse Timings ändern. In den meisten Fällen reichen die Defaults aus, aber manchmal kann es durch zu wenig wait states, die Einstellung RAM Speed: Turbo oder ähnliches zu merkwürdigen Problemen kommen. Ein möglicher Ansatz ist, die BIOS defaults zu laden, allerdings könnte es sinnvoll sein, die aktuellen Einstellungen vorher zu notieren. Schlechte oder fehlerhafte Stromversorgung des Mainboards: Wenn Sie unbenutzte Steckkarten, Platten oder CD-ROMs in Ihrem System haben, sollten Sie sie testweise ausbauen oder die Stromversorgung abziehen. Dadurch können Sie prüfen, ob Ihr Netzteil eventuell mit einer geringeren Last besser zurechtkommt. Sie können auch testweise ein anderes, am besten ein leistungsfähigeres, Netzteil ausprobieren. Wenn Sie zurzeit ein 250 W-Netzteil benutzen, sollten Sie testweise ein 300 W-Netzteil einbauen. Die sollten ebenfalls die SIG11 FAQ (unten aufgeführt) lesen, da sie gute Erklärungen für alle diese Probleme enthält (allerdings aus &linux;-Sicht). Sie erklärt ebenfalls, warum sowohl Programme als auch Geräte zur Speicherprüfung fehlerhaften Speicher teilweise nicht erkennen. Wenn alle diese Schritte nicht helfen, ist es möglich, dass Sie einen Fehler in &os; gefunden haben. Folgen Sie einfach den Anweisungen für die Erstellung eines Problem Reports. Es existiert eine ausführliche FAQ hierzu unter der SIG11-Problem-FAQ. Mein System stürzt mit der Meldung Fatal trap 12: page fault in kernel mode oder panic: ab und gibt eine Menge zusätzlicher Informationen aus. Was kann ich tun? Die Entwickler von &os; interessieren sich für solchen Meldungen, allerdings brauchen Sie deutlich mehr Informationen als die, die Ihnen angezeigt werden. Kopieren Sie die komplette Meldungen und lesen Sie nun den FAQ-Eintrag über kernel panics. Erzeugen sie einen Kernel mit den zusätzlichen Daten zur Fehlersuche, und dann einen backtrace. Das hört sich komplizierter an, als es ist. Sie brauchen keine Programmier-Erfahrung, Sie müssen einfach nur den Anweisungen folgen. Wieso wird beim Booten der Bildschirm schwarz und reagiert nicht mehr? Dies ist ein bekanntes Problem mit der ATI Mach64 Videokarte. Das Problem besteht darin, dass diese Karte die Adresse 2e8 benutzt und die vierte serielle Schnittstelle ebenfalls. Aufgrund eines Fehlers (einer Besonderheit?) im &man.sio.4;-Treiber wird diese Schnittstelle angesprochen, auch wenn Sie gar keine vierte serielle Schnittstelle besitzen und sogar, wenn Sie sio3 (die vierte Schnittstelle), die normalerweise diese Adresse verwendet, deaktivieren. Bis der Fehler behoben ist, können Sie folgende Abhilfe verwenden: Geben Sie am Bootprompt ein. (Dies bringt den Kernel in den Konfigurationsmodus). Deaktivieren Sie sio0, sio1, sio2 und sio3 (alle). Auf diese Weise wird der &man.sio.4;-Treiber nicht aktiviert und das Problem tritt nicht mehr auf. Geben Sie exit ein, um den Bootvorgang fortzusetzen. Falls sie in der Lage sein wollen Ihre seriellen Schnittstellen zu benutzen, müssen Sie einen neuen Kernel mit folgenden Modifikationen erstellen: suchen Sie in /usr/src/sys/sio/sio.c (oder in /usr/src/sys/pc98/cbus/sio.c für pc98) nach der Zeichenkette 0x2e8 und löschen Sie sie und das vorhergehende Komma (nicht das folgende Komma). Nun folgen Sie der normalen Prozedur zur Erstellung eines neuen Kernels. Wieso verwendet &os; nur 64 MB Hauptspeicher, obwohl in meinem Rechner 128 MB sind? Aufgrund der Art und Weise, wie &os; die Hauptspeichergröße vom BIOS mitgeteilt bekommt, kann es lediglich 16-Bit Werte in kByte-Größe (65535 kByte = 64 MB) erkennen (oder weniger... einige BIOSe setzen die Hauptspeichergröße auf 16 MB). Falls Sie mehr als 64 MB besitzen, wird &os; versuchen, das zu erkennen, was aber nicht immer funktioniert. Um dieses Problem zu umgehen, müssen Sie die untenstehende Kerneloption verwenden. Es gibt einen Weg, vollständige Hauptspeicherinformationen vom BIOS zu erhalten, aber in den Bootblöcken ist nicht genügend Platz dafür vorhanden. Wenn der Platzmangel in den Bootblöcken eins Tages behoben ist, werden wir die erweiterten BIOS-Funktionen dazu nutzen, die vollständigen Hauptspeicherinformationen zu erhalten... aber zurzeit sind wir auf die Kerneloption angewiesen. options MAXMEM=n Hierbei ist n Ihre Hauptspeichergröße in Kilobyte. Bei einer 128 MB-Maschine müßten Sie 131072 benutzen. Ich habe mehr als 1 GB RAM. Trotzdem stürzt mein System mit der Meldung kmem_map too small ab. Was läuft hier schief? Im Normalfall bestimmt &os; einige Kernelparameter, darunter die maximale Anzahl der Dateien, die gleichzeitig geöffnet sein können, aus der Größe des im System installierten Hauptspeichers. Auf Systemen mit mindestens 1 GB Hauptspeicher kann dieser auto sizing-Mechanismus diese Werte fälschlicherweise zu hoch ansetzen: Beim Systemstart fordert der Kernel dann verschiedene Tabellen und andere Strukturen an, die den Großteil des verfügbaren Kernelspeichers verbrauchen. Dies führt dazu, dass der Kernel während des Betriebs keine dynamischen Speicheranforderungen mehr ausführen kann und mit einer Kernelpanik abstürzt. Bauen Sie in diesem Fall Ihren eigenen Kernel. Dazu setzen Sie in Ihrer Kernelkonfigurationsdatei auf 400 MB (). 400 MB sollten für Maschinen bis 6 GB Hauptspeicher ausreichend sein. Ich habe weniger als 1 GB Hauptspeicher. Dennoch stürzt mein System mit der Meldung kmem_map too small ab! Diese Meldung zeigt an, dass der virtuelle Speicher für Netzwerkpuffer (spezieller mbuf-Cluster) aufgebraucht ist. Sie können die für mbuf verfügbare Größe an VM erhöhen, indem Sie den Anweisungen des Abschnitts Netzwerk-Limits des Handbuchs folgen. Wieso erhalte ich die Meldung kernel: proc: table is full? Der &os;-Kernel beschränkt die Anzahl der gleichzeitig laufenden Prozesse. Die Anzahl errechnet sich aus dem Wert der Variablen MAXUSERS in der Konfigurationsdatei des Kernels. Auch andere Einstellungen wie die Anzahl der Puffer für Netzwerkoperationen (Details dazu finden Sie in diesem Abschnitt). werden durch MAXUSERS beeinflusst. Wenn Ihr System stark belastet ist, sollten Sie den Wert von MAXUSERS erhöhen. Dadurch werden diverse Einstellung des Systems angepasst und die maximale Anzahl gleichzeitig laufender Prozesse erhöht. Um den Wert von MAXUSERS anzupassen, folgen Sie den Anweisungen des Abschnitts Datei- und Prozesslimits des Handbuchs. Dieser Abschnitt spricht zwar nur von Dateien, für Prozesse gelten aber die gleichen Beschränkungen. Wenn Ihr System nicht besonders stark ausgelastet ist und Sie einfach nur mehr gleichzeitig laufende Prozesse erlauben wollen, können Sie den Wert der Variable kern.maxproc in der Datei /boot/loader.conf anpassen. Um die Änderung zu aktivieren, müssen Sie Ihr System neu starten. Wollen Sie Ihr System zusätzlich optimieren, sollten Sie &man.loader.conf.5; und &man.sysctl.conf.5; lesen. Wenn diese Prozesse von einem einzigen Benutzer ausgeführt werden, müssen Sie den Wert von kern.maxprocperuid ebenfalls erhöhen. Dieser Wert muss immer mindestens um eins geringer sein als der Wert von kern.maxproc (der Grund für diese Einschränkung ist, dass ein Systemprogramm, &man.init.8;, immer ausgeführt werden muss). Damit Änderungen einer sysctl-Variable dauerhaft erhalten bleiben, nehmen Sie diese in /etc/sysctl.conf auf. Weitere Informationen zur Optimierung Ihres Systems finden Sie im Abschnitt Einstellungen mit sysctl des Handbuchs. Wieso erhalte ich die Meldung CMAP busy panic, wenn ich mein System mit einem neuen Kernel starte? Die Logik, die versucht, veraltete /var/db/kvm_*.db-Dateien zu erkennen, versagt manchmal und die Benutzung einer unpassenden Datei kann zu Paniksituationen führen. Falls das passiert, rebooten Sie in den Single-User-Modus und löschen Sie die Dateien: &prompt.root; rm /var/db/kvm_*.db Was soll mir die Meldung ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 sagen? Dies ist ein Konflikt mit einem Ultrastor SCSI Hostadapter. Rufen Sie während des Bootprozesses das Kernelkonfigurationsmenü auf und deaktivieren Sie uha0, welches das Problem verursacht. Wenn ich mein System starte, erhalte ich die Meldung ahc0: illegal cable configuration, obwohl die Verkabelung korrekt ist. Woran liegt das? Auf Ihrem Mainboard fehlen ein paar Logikbausteine, die für die Unterstützung der automatischen Terminierung notwendig sind. Stellen Sie in Ihrem SCSI-BIOS manuell die korrekte Terminierung für Ihr System ein, anstatt sich auf die automatische Terminierung zu verlassen. Der &man.ahc.4;-Treiber kann nicht erkennen, ob die externen Logikbausteine für die Erkennung der Kabel (und damit automatische Terminierung) vorhanden sind. Der Treiber muss sich darauf verlassen, dass diese vorhanden sind, wenn in der Konfiguration automatische Terminierung eingestellt ist. Ohne die externen Bausteine ist es sehr wahrscheinlich, dass der Treiber die Terminierung falsch einstellt, was die Zuverlässigkeit des SCSI-Busses herabsetzen kann. Wieso meldet sendmail mail loops back to myself? Sie finden eine detaillierte Antwort auf diese Frage im Handbuch. Wieso funktionieren bildschirmorientierte Anwendungen beim Zugriff über ein Netzwerk nicht richtig? Die entfernte Maschine scheint den Terminaltyp auf etwas anderes als den Typ cons25, der von &os; verlangt wird, zu setzen. Es gibt mehrere mögliche Abhilfen für dieses Problem: Setzen Sie die Shell-Variable TERM nach dem Einloggen auf der entfernten Maschine auf ansi oder sco, sofern die entfernte Maschine diese Terminaltypen kennt. Benutzen Sie einen VT100-Emulator wie screen auf der &os;-Konsole. screen bietet Ihnen die Möglichkeit, mehrere gleichzeitige Sitzungen von einem Bildschirm aus laufen zu lassen. Es ist ein sehr nettes Programm. Jedes screen-Fenster verhält sich, wie ein VT100-Terminal, weshalb die Variable TERM am entfernten Ende auf vt100 gesetzt werden sollte. Installieren Sie den Eintrag cons25 in der Bildschirmdatenbank der entfernten Maschine. Wie das zu geschehen hat, hängt vom Betriebssystem der entfernten Maschine ab. Das Systemadministrationshandbuch für das entfernte System sollte Ihnen hierbei helfen können. Starten Sie einen X-Server auf der &os;-Seite und benutzen Sie einen X-basierten Terminalemulator wie xterm oder rxvt, um sich auf der entfernten Maschine einzuloggen. Die Variable TERM auf dem entfernten Host sollte auf xterm oder vt100 gesetzt werden. Warum wird meine PnP-Karte nicht (oder nur noch als unknown) erkannt? Die Gründe für dieses Verhalten werden in der unten zitierten Mail von &a.peter; erklärt. Diese Mail stammt von der Mailingliste &a.questions; und war eine Antwort auf eine Frage bezüglich eines internen Modem, das nach dem Update auf &os; 4.X nicht mehr erkannt wurde. Die mit [] gekennzeichneten Kommentare wurden eingefügt, um an einigen Stellen die Bezüge klarzustellen.
Das PnP-BIOS hat es [das Modem] vorkonfiguriert und es dann im Adressraum liegenlassen, daher haben es die alten ISA-Erkennungsroutinen [in 3.X] gefunden. In 4.0 sind die ISA-Routinen deutlich PnP-orientierter. Es war möglich [in 3.X], dass eine ISA-Erkennungsroutine ein zugelaufenes Gerät fand; während die PnP-Treiber zwar die ID erkannten, das Gerät aber wegen des Ressourcekonfliktes nicht benutzen konnten. Daher werden die programmierbaren Karten zunächst einmal abgeschaltet, um diese doppelte Erkennung vermeiden zu können. Das bedeutet allerdings auch, dass die Treiber die PnP-ID kennen muss, um PnP-Hardware unterstützen zu können. Wir haben uns vorgenommen, den Benutzern eine einfachere Möglichkeit zur Manipulation dieser Informationen zur Verfügung zu stellen.
Damit Ihr Gerät wieder funktioniert, müssen Sie seine PnP-ID herausfinden und die ID in die Listen eintragen, die zur Erkennung von PnP-Geräten genutzten werden. Zu diesem Zweck wird das Gerät mit &man.pnpinfo.8; analysiert. Das Beispiel zeigt die Ausgaben von &man.pnpinfo.8; für ein internes Modem: &prompt.root; pnpinfo Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff PnP Version 1.0, Vendor Version 0 Device Description: Pace 56 Voice Internal Plug & Play Modem Logical Device ID: PMC2430 0x3024a341 #0 Device supports I/O Range Check TAG Start DF I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8 [16-bit addr] IRQ: 4 - only one type (true/edge) [weitere TAG Zeilen gestrichen] TAG End DF End Tag Successfully got 31 resources, 1 logical fdevs -- card select # 0x0001 CSN PMC2430 (0x3024a341), Serial Number 0xffffffff Logical device #0 IO: 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 IRQ 5 0 DMA 4 0 IO range check 0x00 activate 0x01 Sie benötigen die Information aus der Zeile Vendor ID ganz am Anfang. Die in Klammern ausgegebene hexadezimale Zahl (0x3024a341 in diesem Beispiel) ist die PnP ID und die unmittelbar davor stehende Zeichenkette (PMC2430) ist eine eindeutige Herstellerkennung. Benutzen Sie &man.pciconf.8; wenn &man.pnpinfo.8; die Karte nicht anzeigt. Der Teil der Ausgabe von pciconf -vl für eine auf dem Motherboard integrierte Soundkarte sieht zum Beispiel so aus: &prompt.root; pciconf -vl chip1@pci0:31:5: class=0x040100 card=0x00931028 chip=0x24158086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801AA 8xx Chipset AC'97 Audio Controller' class = multimedia subclass = audio Sie benötigen die Chip-ID 0x24158086, die hinter chip aufgeführt ist. Die Vendor ID oder chip-ID müssen in die Datei /usr/src/sys/dev/sio/sio_isa.c eingetragen werden. Sie sollten zunächst ein Backup von sio_isa.c anlegen, falls etwas schief gehen sollte. Sie werden auch einen Patch erzeugen müssen, um ihn zusammen mit Ihrem PR einzusenden. (Sie wollten doch einen PR schreiben, oder etwa nicht?) Öffnen Sie nun sio_isa.c mit einem Editor und suchen Sie nach der Zeile: static struct isa_pnp_id sio_ids[] = { Blättern Sie dann nach unten, um die passende Stelle für Ihr Gerät zu finden. Unten finden Sie Beispiel für die Einträge, diese sind nach der Herstellerkennung sortiert. Diese sollte in dem Kommentar auf der rechten Seite aufgenommen werden, dazu kommt die Gerätebeschreibung (Device Description) aus der Ausgabe von &man.pnpinfo.8;: {0x0f804f3f, NULL}, /* OZO800f - Zoom 2812 (56k Modem) */ {0x39804f3f, NULL}, /* OZO8039 - Zoom 56k flex */ {0x3024a341, NULL}, /* PMC2430 - Pace 56 Voice Internal Modem */ {0x1000eb49, NULL}, /* ROK0010 - Rockwell ? */ {0x5002734a, NULL}, /* RSS0250 - 5614Jx3(G) Internal Modem */ Fügen Sie die hexadezimale Gerätekennung an der richtigen Stelle ein, speichern Sie die Datei ab, erzeugen Sie einen neuen Kernel und starten Sie Ihr System neu. Ihr Gerät sollte nun als sio Gerät erkannt werden.
Warum erhalte ich die Meldung nlist failed, wenn ich Programme wie top oder systat benutze? Das Programm sucht nach einem speziellen Symbol im Kernel, kann es aber aus irgendeinem Grunde nicht finden. Dieser Fehler wird von einem dieser Probleme verursacht: Ihr Kernel und die sonstigen Programme (das Userland) sind nicht mehr auf dem gleichen Stand. Mit anderen Worten, Sie haben zwar einen neuen Kernel erzeugt, aber kein installworld (oder umgekehrt); darum weicht die Symboltabelle von dem ab, was die Anwendung erwartet. Wenn dies der Fall ist, müssen Sie lediglich die noch fehlenden Schritte des Upgrades durchführen. Die richtige Vorgehensweise kann /usr/src/UPDATING entnommen werden. Um Ihren Kernel zu laden, benutzen Sie nicht /boot/loader, sondern laden ihn direkt mit boot2 (siehe &man.boot.8;). Es ist zwar nicht immer ein Fehler, /boot/loader zu umgehen; allerdings ist er in der Regel besser dazu geeignet, die Symbole des Kernels für normale Anwendungen verfügbar zu machen. Wieso dauert es so lange, bis eine Verbindung (&man.ssh.1; oder &man.telnet.1;) aufgebaut wird? Das Symptom: Nach dem Aufbau des TCP-Verbindung vergeht einige Zeit, bis endlich die Abfrage des Passwortes (bzw. der Login-Prompt bei Telnet) erscheint. Das Problem: In den meisten Fällen versucht der Server in der Zwischenzeit, die IP-Adresse des Clients in einen Rechnernamen zu übersetzen. Viele Server (darunter die Telnet- und SSH-Server von &os;) machen das, um den Hostnamen z.B. für spätere Verwendung durch den Systemadministrator in eine Protokolldatei schreiben zu können. Die Lösung: wenn das Problem bei jedem Server auftritt, den Sie von Ihrem Computer (dem Client) ansprechen, dann wird das Problem vom Client verursacht. Wenn das Problem aber nur auftritt, wenn jemand Ihren Rechner (den Server) anspricht, dann liegt die Ursache beim Server. Wenn das Problem vom Client verursacht wird, müsssen Sie die Einträge im DNS korrigieren, damit der Server Ihre IP-Adresse übersetzen kann. Wenn das Problem in Ihrem lokalen Netzwerk auftritt, sollten Sie es als Problem des Servers behandeln und weiterlesen; wenn es allerdings im Internet auftritt, werden Sie sich wahrscheinlich an Ihrem ISP wenden müssen, damit dieser das Problem für Sie korrigiert. Wenn das Problem vom Server verursacht wird und Sie sich in einem lokalen Netzwerk befinden, dann müssen Sie Ihren Server so konfigurieren, dass er die lokal genutzten IP-Adressen in Rechnernamen übersetzen kann. Weitere Informationen erhalten Sie in den Onlinehilfen zu &man.hosts.5; und &man.named.8;. Wenn dieses Problem im Internet auftritt, könnte die Ursache auch darin liegen, dass die Namensauflösung auf dem Server nicht funktioniert. Versuchen Sie, einen anderen Hostnamen wie z.B. www.yahoo.com aufzulösen. Wenn das nicht funktioniert, liegt das Problem bei Ihrem System. Haben Sie &os; gerade erst installiert, kann es auch sein, dass die Domänen- und Nameserverinformationen noch nicht in /etc/resolv.conf vorhanden sind. Dadurch kommt es häufig zu Verzögerungen beim Einsatz von SSH, weil die Option UseDNS in der Voreinstellung auf yes gesetzt ist (in der Datei sshd_config im Verzeichnis /etc/ssh). Ist dies bei Ihnen der Fall, müssen Sie entweder die fehlenden Informationen in /etc/resolv.conf eintragen oder als temporäre Maßnahme UseDNS auf no setzen. Was bedeutet stray IRQ? Stray IRQs sind ein Zeichen für Probleme bei der Behandlung von Hardware-IRQs. Sie werden meistens von Geräten verursacht, die ihren Interrupt Request zurückziehen, obwohl gerade der interrupt request acknowledge-Zyklus läuft. Sie können drei Dinge tun: Ertragen Sie die Warnungen. Sie erhalten nur die ersten 5 für jeden IRQ, alle anderen werden unterdrückt. Eliminieren Sie die Meldungen, indem Sie den Wert von MAX_STRAY_LOG von 5 auf 0 in der für ihre Plattform (z.B. &i386;) zuständigen Datei intr_machdep.c ändern. Bauen Sie anschliessend den Kernel neu, um alle Meldungen zu unterdrücken. Eliminieren Sie die Meldungen, indem Sie Hardware für den Parallelport installieren, die IRQ 7 nutzt und vom PPP Treiber verwendet wird (das passiert auf den meisten Systemen), und installieren Sie eine IDE-Platte oder andere Hardware sowie einen dazu passenden Treiber, um IRQ 15 zu nutzen. Warum sehe ich in der Ausgabe von &man.dmesg.8; häufig die Meldung file: table is full? Diese Fehlermeldung besagt, dass Sie die zur Verfügung stehenden File-Handles des Systems verbraucht haben. Was das genau bedeutet und wie Sie dieses Problem lösen können, steht im Abschnitt kern.maxfiles im Kapitel Anpassung der Kernelkonfiguration des Handbuchs. Warum werden ständig Meldungen wie calcru: negative runtime oder calcru: runtime went backwards auf die Konsole geschrieben? Es existiert ein bekanntes Problem wenn &intel; Enhanced SpeedStep im BIOS aktiviert wird. Das führt dazu, dass der Kernel calcru-Nachrichten wie die folgende ausgibt: calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero) calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon) calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon) calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: task queue) calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event) calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net) calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init) calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init) calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper) Der Grund dafür besteht darin, dass &intel; SpeedStep (EIST) in manchen Mainboards inkompatibel ist. Abhilfe: Deaktivieren Sie die EIST-Eigenschaft im BIOS. Sie können trotzdem noch ihre Prozessorfrequenz ACPI-basiert mittels &man.powerd.8; drosseln. Warum ist die Uhrzeit auf meinem Computer immer falsch? Ihr Computer verfügt über mehr als eine Uhr und &os; benutzt leider die falsche. Starten Sie &man.dmesg.8; und achten Sie auf die Zeilen, in denen das Wort Timecounter vorkommt. Die von &os; benutzte Uhr findet sich in der Zeile mit dem höchsten quality-Wert. &prompt.root; dmesg | grep Timecounter Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "TSC" frequency 2998570050 Hz quality 800 Timecounters tick every 1.000 msec Sie können das überprüfen, indem Sie den Wert der Systemvariablen kern.timecounter.hardware abfragen. &prompt.root; sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast Es kann sich um einen defekten ACPI Timer handeln. Die einfachste Lösung besteht darin, den ACPI Timer in /etc/loader.conf zu deaktivieren: debug.acpi.disabled="timer" Es ist aber auch durchaus möglich, dass das BIOS die TSC Uhr ändert, um beispielsweise den CPU-Takt zu während des Batteriebetrieb zu ändern, oder im Stromsparmodus; leider bemerkt &os; diese Änderungen nicht und daher scheint die Uhr falsch zu gehen. In diesem Beispiel ist die Uhr i8254 ebenfalls verfügbar; um sie auszuwählen, muss ihr Name in die Systemvariable kern.timecounter.hardware geschrieben werden. &prompt.root; sysctl -w kern.timecounter.hardware=i8254 kern.timecounter.hardware: TSC -> i8254 Die Uhrzeit Ihres Computers sollte nun genauer funktionieren. Damit diese Änderung automatisch beim Start des Systems durchgeführt wird, müssen Sie die folgende Zeile in die /etc/sysctl.conf eintragen. kern.timecounter.hardware=i8254 Warum erkennt mein Laptop PC-Cards nicht? Dieses Problem tritt häufig auf Laptops mit mehreren Betriebssystemen auf. Einige nicht-BSD Betriebssysteme lassen die Hardware in einem inkonsistenten Zustand. Die Karte wird dann von &man.pccardd.8; als "(null)""(null)" anstelle des tatsächlichen Modells gefunden. Um dies zu beheben, müssen Sie die Hardware zurücksetzen, das heißt der PC-Card Einschub muss stromlos sein. Gehen Sie dazu nicht in den Standby- oder Suspend-Modus und stellen Sie sicher, dass der Laptop wirklich ausgeschaltet ist. Warten Sie einen Moment und booten dann, Ihre PC-Card sollte jetzt funktionieren. Einige Laptops schalten sich nicht wirklich aus. Wenn der obige Vorschlag nichts genutzt hat, entfernen Sie bitte die Batterie, warten einen Moment und booten erneut. Wieso hängt sich &os; nach dem BIOS-Bildschirm mit der Meldung Read error auf? Der Bootloader von &os; erkennt die Geometrie Ihrer Festplatte nicht richtig. Sie müssen die Geometrie manuell festlegen, wenn sie mit &man.fdisk.8; &os;-Bereiche erzeugen oder ändern. Die richtigen Werte für die Geometrie können Sie im BIOS des Rechners ablesen. Achten Sie auf die Anzahl der Zylinder, Köpfe und Sektoren für Ihre Festplatte. Im fdisk von &man.sysinstall.8; müssen Sie G eingeben, um die Geometrie zu definieren. Sie erhalten eine Dialogbox, in der Sie die Anzahl der Zylinder, Köpfe und Sektoren eingeben können. Verwenden Sie die Angaben des BIOS und setzen Sie Schrägstriche zwischen die Zahlen. 5000 Zylinder, 250 Köpfe und 60 Sektoren würden also als 5000/250/60 eingegeben. Schließen Sie die Eingabe mit Enter ab und drücken Sie W, um die neue Partitionstabelle auf die Festplatte schreiben zu lassen. Ein anderes Betriebssystem hat meinen Bootmanager zerstört. Wie kann ich ihn wiederherstellen? Starten Sie &man.sysinstall.8; und wählen Sie Configure, dann Fdisk. Wählen Sie die Platte, auf der sich der Boot Manager befand, mit der Leertaste aus. Drücken Sie W, um die Änderungen auf die Platten schreiben zu lassen. Nun erscheint eine Abfrage, welcher Bootmanager installiert werden soll. Wählen Sie diesen an und er wird wieder installiert. Was soll mir die Meldung swap_pager: indefinite wait buffer: sagen? Ein Programm wollte Speicher auf Platte auslagern, und dieser Vorgang konnte nicht innerhalb von 20 Sekunden durchgeführt werden. Mögliche Gründe sind defekte Blöcke auf der Platte, falsche oder fehlerhafte Verkabelung sowie Probleme mit anderen Komponenten, die am Zugriff auf die Festplatte beteiligt sind. Wenn die Festplatte selbst fehlerhaft sind, sollten Sie entsprechende Meldungen in /var/log/messages und den Ausgaben von dmesg finden. Andernfalls sollten Sie die Kabel und Verbindungen überprüfen. Was sind UDMA ICRC Fehler und wie behebe ich sie? Der &man.ata.4;-Treiber meldet UDMA ICRC Fehler wenn eine DMA-Übertragung zu oder von einem Laufwerk fehlgeschlagen ist. Der Treiber versucht die Übertragung mehrmals durchzuführen und schaltet, wenn die Versuche fehlschlagen, vom DMA-Modus auf den langsameren PIO-Modus um. Der Fehler kann viele Ursachen haben, häufig ist ein Kabel kaputt oder die Geräte sind falsch verkabelt. Prüfen Sie, ob die ATA-Kabel unbeschädigt sind und für den verwendeten Ultra-DMA-Modus tauglich sind. Ebenso müssen Wechselrahmen für den verwendeten Modus geeignet sein. Stellen Sie sicher, dass alle Kabel fest angeschlossen sind. Es gab auch schon Probleme, wenn ein altes Laufwerk zusammen mit einem Ultra-DMA-66 oder einem schnelleren Laufwerk auf einem Kanal betrieben wurde. Es kann aber auch sein, dass das Laufwerk kaputt ist. Die meisten Hersteller stellen Test-Programme für ihre Laufwerke zur Verfügung. Überprüfen Sie damit Ihr Laufwerk und wenn nötig, sichern Sie Ihre Daten und ersetzen das Laufwerk. &man.atacontrol.8; zeigt für jedes ATA-Gerät den verwendeten DMA- oder PIO-Modus an. Das Kommando atacontrol mode Kanal zeigt die auf einem Kanal verwendeten Modi (die Kanäle werden von 0 an nummeriert). Was ist ein lock order reversal? Eine Antwort auf diese Frage findet sich im &os;-Glossar unter LOR. Warum erhalte ich die Meldung Called ... with the following non-sleepable locks held? Diese Meldung erscheint, wenn eine Funktion, die sich im Ruhemodus befindet, aufgerufen wird, während ein Mutex oder eine andere (nicht in den Ruhemodus versetzbare) Sperre aktiv war. Der Grund dafür ist, dass ein Mutex nicht für längere Zeitspannen aktiv sein soll, sondern nur für die Synchronisation von Gerätetreibern mit dem Rest des Kernels während eines Interrupts. Unter &os; dürfen Interrupts nicht in den Ruhemodus versetzt werden. Daher ist es von entscheidender Bedeutung, dass während des Bestehens eines Mutex kein Kernelsubsystem für einen längeren Zeitraum blockiert ist. Um solche Fehler abzufangen, können Sicherungen (Assertions) in den Kernel eingebaut werden, die danach mit dem &man.witness.4;-Subsystem interagieren. Dadurch wird (in Abhängigkeit von Ihrer Systemkonfiguration) eine Warnung oder eine Fehlermeldung ausgegeben, falls der Aufruf einer Funktion während des Bestehens eines Mutex zu einer Blockierung führen kann. Zusammenfassend kann man sagen, dass diese Warnungen in der Regel zwar nicht bedrohlich sind. Unter bestimmten Umständen kann es aber dennoch zu unerwünschten Nebenwirkungen, angefangen von einer Erhöhung der Reaktionszeit bis hin zu einem kompletten Einfrieren des Systems kommen. Warum bricht buildworld/installworld mit der Meldung touch: not found ab? Dieser Fehler bedeutet nicht, dass &man.touch.1; nicht auf Ihrem System vorhanden ist. Vielmehr sind Dateien die Ursache, deren Erzeugungsdatum in der Zukunft liegt. Wenn Ihre CMOS-Uhr auf Ihre lokale Zeit eingestellt ist, müssen Sie adjkerntz -i verwenden, um die Kerneluhr anzupassen, wenn Sie in den Single-User-Modus booten.
Kommerzielle Anwendungen Dieser Abschnitt ist immer noch sehr dürftig, aber wir hoffen natürlich, dass Unternehmen einen Beitrag leisten werden! :) Die &os;-Gruppe hat keinerlei finanzielle Interessen an einem der hier aufgelisteten Unternehmen, sondern listet sie lediglich als öffentlichen Service auf (und ist der Meinung, dass ein kommerzielles Interesse an &os; sehr positiven Einfluss auf ein langfristiges Bestehen von &os; haben kann). Wir möchten Anbieter kommerzieller Software dazu aufrufen, ihren Eintrag hier aufnehmen zu lassen. Auf der Anbieter-Seite finden Sie eine längere Liste. Wo bekomme ich &os;-Versionen der klassischen Büro-Anwendungen? Das als Open Source verfügbare Office-Paket OpenOffice.org läuft nativ unter &os;. Die um zusätzliche Funktionen erweiterte kommerzielle OpenOffice.org-Version StarOffice läuft in der &linux;-Version ebenfalls problemlos unter &os;. In der Ports-Sammlung sind weitere Textbearbeitungsprogramme, Tabellenkalkulationen und Zeichenprogramme enthalten. Woher kann ich &motif; für &os; bekommen? Der Quelltext für &motif; 2.2.2 wurde von der Open Group herausgegeben. Sie können entweder das Package x11-toolkits/open-motif installieren oder es mit dem entsprechenden Port selbst compilieren. Weitere Informationen über die Benutzung der Ports erhalten Sie im Kapitel Ports des Handbuchs. Die Open &motif; Distribution darf nur weitergegeben werden, wenn sie auf einem Open Source Betriebssystem benutzt wird. Weiterhin gibt es auch kommerzielle &motif;-Pakete, die zwar nicht kostenlos sind, aber dafür auch mit closed source Software benutzt werden dürfen. Um die günstigste ELF-&motif; 2.1.20 Distribution für &os; (&i386;) zu bekommen, wenden Sie sich bitte an Apps2go. Es gibt zwei Distributionen, die development edition und die runtime edition (wesentlich günstiger). Diese Distributionen enthalten: OSF/&motif; manager, xmbind, panner, wsm. Development-Kit mit uil, mrm, xm, xmcxx, Include- und Imake-Dateien. Statische und dynamische ELF-Bibliotheken. Demonstrations-Applets. Achten Sie darauf, dass Sie bei der Bestellung angeben, dass Sie die &os;-Version von &motif; möchten (vergessen Sie auch nicht, die Architektur anzugeben)! Von Apps2go werden auch Versionen für NetBSD und OpenBSD verkauft. Dieses Produkt ist zurzeit nur zum Download per FTP verfügbar. Weitere Informationen Apps2go Web-Seite oder sales@apps2go.com oder support@apps2go.com oder Telefon (817) 431 8775 oder +1 817 431-8775 Woher kann ich CDE für &os; bekommen? Xi Graphics hat einmal CDE für &os; verkauft, tut es aber nicht mehr. KDE ist ein Open-Source X11-Desktop, der CDE in vielen Punkten ähnelt. Eventuell gefällt Ihnen auch das "Look and Feel" von xfce. KDE und xfce sind über die Ports-Sammlung von &os; verfügbar. Gibt es irgendwelche Datenbanksysteme für &os;? Ja! Lesen Sie den Abschnitt kommerzielle Anbieter auf der &os;-Web-Seite. Schauen Sie auch im Abschnitt Datenbanken der Ports-Sammlung nach. Kann ich &oracle; unter &os; laufen lassen? Ja. Die folgenden Seiten beschreiben genau, wie sich &linux;-&oracle; unter &os; installieren lässt: http://www.unixcities.com/oracle/index.html http://www.shadowcom.net/freebsd-oracle9i/ Benutzerprogramme Nun, wo sind die ganzen Benutzerprogramme? Werfen Sie bitte einen Blick auf die Ports-Seite, um Informationen über die nach &os; portierten Softwarepakete zu erhalten. Die Liste enthält zurzeit &os.numports; Einträge und wächst täglich. Informieren Sie sich daher regelmäßig auf dieser Seite oder abonnieren Sie die Mailingliste &a.announce;, um sich über Änderungen zu informieren. Die meisten Ports sollten auf den 6.X, 7.X und 8.X-Systemen laufen. Jedes Mal, wenn ein &os;-Release erstellt wird, wird auch ein Snapshot des Port-Baumes vom Zeitpunkt des Releases in das Verzeichnis ports/ eingefügt. Wir unterstützen auch das Konzept von Packages - im Grunde genommen nicht mehr als komprimierte Binärdistributionen mit ein wenig zusätzlicher Intelligenz zur Ermöglichung angepasster Installationen. Ein Package kann leicht installiert und wieder deinstalliert werden, ohne, dass man etwas über wissen muss, welche Dateien es enthält. Benutzen Sie das Packages Menü in &man.sysinstall.8; (unter dem Menüpunkt post-configuration) oder führen Sie den Befehl &man.pkg.add.1; mit den speziellen Paketdateien aus, die Sie installieren möchten. Paketdateien können für gewöhnlich an der Endung .tgz oder .tbz erkannt werden und diejenigen, die über eine CD-ROM-Distribution verfügen, haben auf ihrer CD ein Verzeichnis packages/All, das solche Dateien enthält. Für verschiedene &os;-Versionen können sie von folgenden Adressen auch über das Netz heruntergeladen werden: für 6.X-RELEASE/6-STABLE ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6-stable für 7.X-RELEASE/7-STABLE ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7-stable - für 8-CURRENT + für 8.X-RELEASE/8-STABLE - ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ports/i386/packages-8-current + url="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-8-stable/"> + ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-8-stable + + + + + für 9-CURRENT + + + + ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-9-current + + oder von Ihrem nächstgelegenen Mirror. Beachten Sie, dass nicht alle Ports als Package verfügbar sind, da ständig neue hinzugefügt werden. Es ist immer eine gute Idee, sich regelmäßig auf der ftp.de.FreeBSD.org Masterseite darüber zu informieren, welche Packages verfügbar sind. Wie konfiguriere ich INN (Internet News) für meine Maschine? Ein idealer Startpunkt nach der Installation des Packages oder Ports news/inn ist Dave Barr's INN-Seite, wo Sie die INN-FAQ finden. Unterstützt &os; &java;? Ja. Informieren Sie sich bitte unter http://www.de.FreeBSD.org/java/. Warum kann ich manche Ports auf meiner - 6.X oder - 7.X-STABLE-Maschine nicht erstellen? + 6.X, 7.X oder + 8.X-STABLE-Maschine nicht erstellen? Wenn Sie eine &os;-Version benutzen, die deutlich älter als das aktuelle -CURRENT oder -STABLE ist, könnte es sein, dass Sie vorher Ihre Ports-Sammlung aktualisieren müssen. Lesen Sie dazu den Abschnitt Keeping Up des Porters-Handbuch. Ist Ihre Ports-Sammlung aktuell, könnte es sein, dass jemand eine Änderung am Port durchgeführt hat, die für -CURRENT funktioniert, den Port für -STABLE aber unbrauchbar gemacht hat. Bitte senden Sie einen Fehlerbericht mit dem Befehl &man.send-pr.1;. Von der Ports-Sammlung wird nämlich erwartet, dass sie sowohl auf -CURRENT als auch auf -STABLE funktioniert. Ich habe gerade versucht, INDEX mit make index zu bauen, und es hat nicht geklappt. Woran liegt das? Stellen Sie zuerst sicher, dass Ihre Ports-Sammlung aktuell ist. Fehler, die einen Bau von INDEX aus einer aktuellen Ports-Sammlung verhindern, sind sofort sichtbar und werden daher fast immer umgehend behoben. Ist Ihre Ports-Sammlung jedoch aktuell, haben Sie vielleicht ein anderes Problem. make index hat einen Bug im Umgang mit unvollständigen Kopien der Ports-Sammlung. Es nimmt an, dass Sie über eine lokale Kopie aller Ports verfügen, von denen jeder lokale Port abhängt. Wenn Sie also beispielsweise eine Kopie von foo/bar auf Ihrem System haben, und foo/bar ist von baz/quux abhängig, dann muss auch eine Kopie von baz/quux auf Ihrem System vorhanden sein, sowie eine Kopie aller Ports, von denen baz/quux abhängt. Anderenfalls ist make index aufgrund fehlender Informationen nicht in der Lage, den Abhängigkeitsbaum zu erzeugen. Dieses Problem tritt vor allem dann auf, wenn &os;-Benutzer &man.cvsup.1; (oder &man.csup.1;) verwenden, um die Ports-Sammlung zu aktualisieren und dabei verschiedene Kategorien durch die Datei refuse von der Aktualisierung ausschließen. Theoretisch ist es zwar möglich, Kategorien auszuschließen, in der Praxis gibt es aber zu viele Ports, die von Ports in anderen Kategorien abhängen. Wenn Sie also INDEX bauen wollen, müssen Sie über eine komplette Kopie der Ports-Sammlung verfügen. Es gibt seltene Fälle, in denen INDEX nicht gebaut werden kann, wenn bestimmte WITH_* oder WITHOUT_* Variablen in make.conf gesetzt sind. Wenn Sie dieses Problem haben, sollten Sie diese make-Variablen deaktivieren und INDEX erneut bauen, bevor Sie das Problem an &a.ports; melden. Warum ist CVSup nicht im &os;-Basisquellbaum enthalten? Das Basissystem von &os; soll selbstverwaltend sein. Es soll also möglich sein, das komplette Betriebssystem mit einer beschränkten Anzahl von Werkzeugen zu starten. Daher werden die zum Bau von &os; nötigen Werkzeuge mit dem Quelltext gekoppelt. Zu diesen Werkzeugen gehören ein C-Compiler (&man.gcc.1;), &man.make.1;, &man.awk.1; und andere. Da CVSup in Modula-3 geschrieben wurde, müsste ein Modula-3-Compiler ins Basissystem aufgenommen und auch gewartet werden. Dies würde einen gestiegenen Speicherbedarf für die &os;-Quellen sowie einen erhöhten Wartungsaufwand verursachen. Daher ist es sowohl für Entwickler als auch Benutzer einfacher, CVSup bei Bedarf als Port oder als Paket von einer Installations-CD zu installieren. Wie dem auch sei, &os;-Benutzer müssen seit &os; 6.2-RELEASE nicht mehr ohne einen kompatiblen CVSup-Client auskommen. Dank &a.mux; wurde CVSup als &man.csup.1; in C neu geschrieben und ist mittlerweile Teil des Basissystems. Obwohl zur Zeit noch nicht alle Eigenschaften von CVSup implementiert sind, ist es gut genug (und sehr schnell!) darin, ihre Quellen zu synchronisieren. Für &os;-Systeme vor 6.2 kann es als Port oder Paket (siehe net/csup) installiert werden. Ich habe die Sourcen aktualisiert, wie aktualisiere ich jetzt die installierten Ports? &os; enthält zwar kein Programm, das die installierten Ports aktualisiert, allerdings existieren diverse Programme, die diesen Prozess etwas vereinfachen. Weiterhin können Sie zusätzliche Programme installieren, die Sie dabei unterstützen, siehe Ports aktualisieren im &os; Handbuch. Muss ich nach der Aktualisierung einer &os;-Hauptversionsnummer jedes Mal alle Ports neu erstellen lassen? Auf jeden Fall! Während ein aktuelles System mit Software für eine ältere Version funktionieren wird, werden Sie mit zufälligen Abstürzen und nicht funktionierenden Ports zurückbleiben, sobald Sie anfangen, andere Ports zu installieren oder diejenigen, die Sie bereits haben, aktualisieren möchten. Wenn das System aktualisiert wird, werden verschiedene Shared-Libraries, ladbare Module und andere Systembestandteile mit neueren Versionen ersetzt. Anwendungen, die gegen die älteren Versionen gelinkt sind, werden nicht starten oder in anderen Fällen nicht korrekt funktionieren. Für weitere Informationen, lesen Sie den Abschnitt über Betriebssystemupgrades im &os; Handbuch. Muss ich nach der Aktualisierung einer &os;-Unterversionsnummer jedes Mal alle Ports neu erstellen lassen? Generell nicht. Die &os;-Entwickler tun ihr möglichstes, um die Binärkompatibilität über alle Veröffentlichungen mit der gleichen Hauptversionsnummer zu garantieren. Ausnahmen werden in den Release Notes dokumentiert und die darin enthaltenen Hinweise sollten befolgt werden. Warum ist /bin/sh so spartanisch? Warum benutzt &os; nicht die bash oder eine ähnliche Shell? Weil der &posix;-Standard definiert, dass es so eine Shell geben muss. Die ausführlichere Antwort: Viele Leute müssen Shell-Programme schreiben, die auf vielen verschiedenen Systemen nutzbar sein müssen. Aus diesem Grund enthält der &posix;-Standard eine sehr detaillierte Definition der Shell und der Hilfsprogramme. Die meisten Programme werden für die Bourne Shell geschrieben; außerdem nutzen mehrere wichtige Schnittstellen (&man.make.1;, &man.system.3;, &man.popen.3; und ihre Entsprechungen in höheren Programmiersprachen wie Perl und Tcl) die Bourne Shell, um Befehle auszuführen. Da die Bourne Shell an so vielen Stellen und so häufig genutzt wird, muss sie die folgenden Anforderungen erfüllen: Schneller Start, ein klar definiertes Verhalten und ein möglichst geringer Speicherverbrauch. Wir haben bei der vorliegenden Implementierung versucht, möglichst viele dieser Anforderungen zu erfüllen. Um /bin/sh nicht zu groß werden zu lassen, haben wir viele der Annehmlichkeiten der anderen Shells weggelassen. Aus diesem Grund gibt es in den Ports die luxuriöseren Shells wie bash, scsh, tcsh und zsh. Vergleichen Sie einfach mal den Speicherverbrauch der verschiedenen Shells, indem Sie ps aufrufen und sich die Angaben in den Spalten VSZ und RSS ansehen. Wieso dauert es so lange, bis &netscape; und Opera starten? In den meisten Fällen liegt es daran, dass Ihre DNS-Einstellungen fehlerhaft sind. Sowohl &netscape; als auch Opera stellen Anfragen an DNS, wenn Sie gestartet werden. Das Fenster des Browsers erscheint erst, wenn das Programm eine Antwort erhalten hat oder es festgestellt hat, dass Ihr System nicht an ein Netzwerk angeschlossen ist. Ich habe die Ports-Sammlung mit CVSup aktualisiert. Viele Ports lassen sich danach nicht mehr bauen und geben seltsame Fehlermeldungen aus. Was ist passiert? Ist die Ports-Sammlung kaputt? Sie sollten immer die Teilsammlung ports-base aktualisieren, wenn Sie nur Teile der Ports-Sammlung mit Hilfe der CVSup-Teilsammlungen aktualisieren. Die Erklärung dazu finden Sie im Handbuch. Wie erzeuge ich Audio-CDs aus MIDI-Dateien? Installieren Sie zuerst den Port audio/timidity++. Danach müssen Sie manuell die GUS-Patche von Eric A. Welsh von installieren. Wenn TiMidity++ richtig installiert wurde, können Sie mit dem folgenden Kommando MIDI-Dateien in das WAV-Format konvertieren: &prompt.user; timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid Die WAV-Dateien können dann in andere Formate konvertiert werden oder (wie im &os;-Handbuch beschrieben) auf Audio-CDs gebrannt werden. Kernelkonfiguration Ich möchte meinen Kernel anpassen. Ist das schwierig? Überhaupt nicht! Lesen Sie den Abschnitt zur Kernelkonfiguration im Handbuch. Der neue kernel wird zusammen mit seinen Modulen im Verzeichnis /boot/kernel installiert werden. Der alte Kernel und dessen Module wird in das Verzeichnis /boot/kernel.old verschoben, damit Sie, wenn Sie einen Fehler beim herumexperimentieren mit Ihrer Konfiguration gemacht haben, die vorherige Version Ihres Kernels starten können. Was kann ich machen, wenn meine Kernel-Kompilierungen fehlschlagen, weil _hw_float fehlt? Sie haben wahrscheinlich npx0 aus Ihrer Kernelkonfigurationsdatei entfernt, weil Sie keinen mathematischen Co-Prozessor besitzen. Die Gerätedatei npx0 ist allerdings VERPFLICHTEND. Ihre Hardware unterstützt Gleitkommaoperationen, selbst wenn dafür kein eigenes Bauteil (wie bei den 386er-Prozessoren) mehr verwendet wird. Daher müssen Sie die Gerätedatei npx0 einbinden. Selbst wenn es Ihnen gelingen sollte, einen Kernel ohne npx0-Unterstützung zu bauen, werden Sie diesen nicht booten können. Warum ist mein Kernel so groß (über 10 MByte)? Sie haben Ihren Kernel wahrscheinlich im Debug Modus erstellt. Ein Debug-Kernel enthält viele zusätzliche Informationen für die Fehlersuche, daher ist er so groß. Bitte beachten Sie, dass die Verwendung eines Debug-Kernels die Performance des Systems nicht oder nur minimal reduziert; außerdem ist es für den Fall einer system panic sehr praktisch, einen Debug-Kernel zur Hand zu haben. Wenn Ihnen allerdings der Plattenplatz ausgeht oder Sie einfach rein prinzipiell keinen Debug-Kernel benutzen wollen, müssen die beiden folgenden Bedingungen erfüllt sein: Die Konfigurationsdatei für Ihren Kernel darf die folgende Zeile nicht enthalten: makeoptions DEBUG=-g Sie dürfen &man.config.8; nicht mit dem Parameter starten. Sollten Sie sich nicht an diese Einschränkungen halten, wird Ihr Kernel im Debug-Modus erstellt. Solange Sie sich an diese Einschränkungen halten, können Sie Ihren Kernel ganz normal erstellen und die Größe des Kernels sollte deutlich sinken. Ein normaler Kernel ist nur 1.5 MByte bis 2 MByte groß. Wieso erhalte ich Meldungen über Interrupt-Konflikte, wenn ich eine Karte mit mehreren seriellen Schnittstellen einsetzen will? Wenn ich einen Kernel mit Unterstützung für serielle Multi-Port-Schnittstellen kompiliere, bekomme ich den Hinweis, dass nur der erste Port geprüft wird und die restlichen auf Grund von Interrupt-Konflikten übersprungen werden. Wie kann ich das Beheben? Das Problem besteht darin, dass in &os; Code integriert ist, um den Kernel vor Abstürzen aufgrund von Hardware- oder Software-Konflikten zu bewahren. Behoben wird es, indem die IRQ-Angaben für alle Ports, bis auf einen ausgelassen werden. Hier ist ein Beispiel: # # Multiport high-speed serial line - 16550 UARTS # device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr Wieso kann ich nicht einmal den Standard-Kernel (GENERIC) bauen? Es gibt eine Reihe von möglichen Ursachen für dieses Problem: Sie benutzen die neuen Kommandos make buildkernel und make installkernel nicht, obwohl die Sourcen auf Ihrem System nicht zum laufenden System passen (z.B. benutzen Sie die Sourcen von &rel.current;-RELEASE auf einem System mit &rel2.current;-RELEASE). Wenn Sie ein Upgrade durchführen wollen, sollten Sie /usr/src/UPDATING lesen, beachten Sie insbesondere den Abschnitt COMMON ITEMS gegen Ende des Dokuments. Sie benutzen zwar make buildkernel und make installkernel, aber Sie haben nicht darauf geachtet, dass vorher ein komplettes make buildworld durchgelaufen sein muss. Um seine Arbeit erledigen zu können, benötigt make buildkernel Dateien, die von make buildworld erzeugt werden. Auch wenn Sie &os;-STABLE verwenden, ist es durchaus möglich, dass Sie die Sourcen genau zum falschen Zeitpunkt aktualisiert haben: Während Sie gerade modifiziert wurden oder kurzzeitig fehlerhaft waren. Eine absolute und vollständige Garantie, dass Sie die Sourcen compilieren können, gibt es nur für die Releases, bei &os;-STABLE ist das nicht immer so. Wenn Sie es noch nicht versucht haben, sollten Sie ihre Source nochmals aktualisieren. Es ist denkbar, dass der von Ihnen genutzte Server zurzeit Probleme hat, benutzen Sie daher testweise auch einmal einen anderen Server. Wie kann ich prüfen, welchen Scheduler das System benutzt? Überprüfen Sie dazu, ob auf Ihrem System die sysctl-Variable kern.sched.quantum existiert. Ist dies bei Ihnen der Fall, werden Sie eine Ausgabe ähnlich der folgenden sehen: &prompt.user; sysctl kern.sched.quantum kern.sched.quantum: 99960 Wenn die sysctl-Variable kern.sched.quantum existiert, dann verwenden Sie den 4BSD-Scheduler (&man.sched.4bsd.4;). Existiert sie nicht, erzeugt &man.sysctl.8; eine Fehlermeldung (die Sie aber ignorieren können): &prompt.user; sysctl kern.sched.quantum sysctl: unknown oid 'kern.sched.quantum' Seit &os; 5.3-RELEASE wird der Name des verwendeten Schedulers direkt als Wert der sysctl-Variable kern.sched.name ausgegeben: &prompt.user; sysctl kern.sched.name kern.sched.name: 4BSD Was bedeutet kern.sched.quantum? kern.sched.quantum ist die maximale Anzahl Ticks, die ein Prozess ununterbrochen laufen kann. Die Variable ist charakteristisch für den 4BSD Scheduler, somit kann der verwendete Scheduler über die Existenz dieser Variablen bestimmt werden. Platten, Dateisysteme und Boot Loader Wie kann ich meine neue Festplatte in mein &os;-System einbinden? Lesen Sie den Abschnitt Hinzufügen von Laufwerken im Handbuch. Wie verschiebe ich mein System auf meine neue, große Platte? Die beste Methode ist, das Betriebssystem auf der neuen Platte neu zu installieren und danach die Daten zu verschieben. Wenn Sie -STABLE über eine Release hinaus genutzt haben oder eine Release aktualisiert haben, ist das sehr empfehlenswert. Sie können auf beiden Platten &man.boot0cfg.8; installieren und die beiden Versionen so lange parallel betreiben, bis Ihnen die neue Konfiguration gefällt. Wenn Sie dies tun wollen, können Sie im übernächsten Absatz erfahren, wie sie Ihre Daten verschieben können. Falls Sie sich entscheiden, das nicht zu tun, müssen Sie Ihre neue Platte partitionieren und labeln. Benutzen Sie dafür entweder &man.sysinstall.8; oder &man.fdisk.8; und &man.disklabel.8;. Weiterhin sollten Sie mit &man.boot0cfg.8; auf beiden Platten booteasy installieren, damit Sie in der Lage sind, das alte und das neue System abwechselnd zu starten, nachdem der Kopiervorgang abgeschlossen ist. Im Formatting-Media Tutorial finden Sie weitere Informationen zu diesen Schritten. Nachdem Sie die neue Platte eingerichtet haben, können Sie Ihre Daten verschieben. Dummerweise können Sie die Daten nicht einfach kopieren. Dinge wie Gerätedateien (in /dev), erweiterte Dateiattribute und symbolische Links führen dazu, dass das in die Hose geht. Sie müssen ein Programm benutzen, das damit umgehen kann, und das ist &man.dump.8;. Es wird oft empfohlen, die Daten im Single-User-Modus zu verschieben, aber das ist nicht unbedingt notwendig. Sie sollten auf gar keinen Fall etwas anderes als &man.dump.8; und &man.restore.8; benutzen, um Ihr Root-Filesystem zu verschieben. Es könnte auch mit &man.tar.1; funktionieren - oder auch nicht. Sie sollten ebenfalls &man.dump.8; und &man.restore.8; benutzen, wenn Sie eine komplette Partition auf eine andere, leere Partition verschieben wollen. Um die Daten einer Partition mit dump auf eine andere Partition zu verschieben, müssen Sie die folgenden Schritte ausführen: Richten Sie in der neuen Partition mit newfs ein Dateisystem ein. Mounten Sie die Partition temporär an einer geeigneten Stelle. Wechseln Sie mit cd in dieses Verzeichnis. Lesen Sie die alte Partition mit dump aus und lenken Sie die Ausgabe auf die neue Partition um. Wenn Sie zum Beispiel root auf /dev/ad1s1a verschieben wollen und diese derzeit auf /mnt gemountet ist, bedeutet das: &prompt.root; newfs /dev/ad1s1a &prompt.root; mount /dev/ad1s1a /mnt &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore rf - Wenn Sie Ihre Partitionen mit &man.dump.8; umorganisieren wollen, steht Ihnen etwas mehr Arbeit bevor. Wenn Sie eine Partition wie /var in die übergeordnete Partition verschieben wollen, müssen Sie zunächst eine neue Partition erzeugen, die die beiden alten Partitionen aufnehmen kann. Der zweite Schritt ist, wie oben beschrieben die übergeordnete Partition in die neue Partition zu verschieben. Im dritten und letzten Schritt verschieben Sie dann die untergeordnete Partition in das leere Verzeichnis, das im zweiten Schritt entstanden ist: &prompt.root; newfs /dev/ad1s1a &prompt.root; mount /dev/ad1s1a /mnt &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore rf - &prompt.root; cd var &prompt.root; dump 0af - /var | restore rf - Wenn Sie ein Verzeichnis aus einer Partition herauslösen wollen, also z.B. /var auf eine eigene Partition verlegen wollen, dann müssen Sie zunächst beide Partitionen anlegen. Danach müssen Sie die untergeordnete Partition im passenden Verzeichnis unterhalb des temporären mount points mounten und zum Abschluß die alte Partition verschieben: &prompt.root; newfs /dev/ad1s1a &prompt.root; newfs /dev/ad1s1d &prompt.root; mount /dev/ad1s1a /mnt &prompt.root; mkdir /mnt/var &prompt.root; mount /dev/ad1s1d /mnt/var &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore rf - Eventuell sagen Ihnen für Benutzerdaten &man.cpio.1;, &man.pax.1; oder &man.tar.1; eher zu als &man.dump.8;. Allerdings haben alle diese Programme den Nachteil, dass sie die erweiterten Dateiattribute nicht verstehen, daher sollten Sie bei ihrem Einsatz aufpassen. Gefährdet eine dangerously dedicated Festplatte meine Gesundheit? Die Installationsprozedur bietet Ihnen zwei verschiedene Methoden, Ihre Festplatte(n) zu partitionieren. Die Standardmethode macht sie kompatibel zu anderen Betriebssystemen auf derselben Maschine, indem &man.fdisk.8;-Tabelleneinträge (unter &os; slices genannt) mit einem &os;-Eintrag, in dem eigene Partitionen untergebracht werden, benutzt werden. Optional kann ausgewählt werden, ob ein Boot-Selektor installiert werden soll, um zwischen den möglichen Betriebssystemen auf der/den Platte(n) wechseln zu können. Bei der zweiten Methode wird die gesamte Platte für &os; genutzt und nicht versucht, kompatibel zu anderen Betriebssystemen zu sein. Nun, warum wird es gefährlich genannt? Eine Platte in diesem Modus enthält nichts, was von normalen PC-Hilfsprogrammen als gültige &man.fdisk.8;-Tabelle betrachtet werden würde. Abhängig von der Qualität ihres Designs werden sie sich bei Ihnen beschweren, sobald sie mit einer solchen Platte in Kontakt kommen, oder noch schlimmer, sie könnten den Bootstrap von &os; beschädigen, ohne Sie zu fragen oder darauf hinzuweisen. Hinzu kommt, dass vom Layout von dangerously dedicated Platten bekannt ist, dass es viele BIOSe verwirrt, einschließlich solcher von AWARD (wie es z.B. im HP Netserver oder Micronics-Systemen, sowie vielen anderen zu finden ist) und Symbios/NCR (für die bekannte 53C8xx-Reihe von SCSI-Controllern). Dies ist keine vollständige Liste - es gibt weitere. Symptome für diese Verwirrung sind read error-Meldungen, die vom &os;-Bootstrap ausgegeben werden, wenn es sich selbst nicht finden kann, sowie Systemabstürze beim Booten. Warum gibt es diesen Modus dann überhaupt? Es spart ein paar kByte an Plattenplatz und kann echte Probleme verursachen, die zu einer Neuinstallation führen. Die Ursprünge des Dangerously dedicated Modus liegen in der Absicht, eines der häufigsten Probleme, das Erstinstallierer von &os; plagt, zu verhindern - die BIOS-Werte für die Geometrie einer Festplatte auf der Festplatte selbst anzupassen. Geometrie ist ein veraltetes Konzept, das aber immer noch die Grundlage für die Interaktion zwischen dem PC-BIOS und den Festplatten ist. Wenn das Installationsprogramm von &os; Slices erstellt, muss es sich die Lage dieser Slices auf der Festplatte in einer Art merken, die damit übereinstimmt, wie das BIOS erwartet, sie zu finden. Wenn das falsch geschieht, werden Sie nicht in der Lage sein, zu booten. Durch den Dangerously dedicated Modus wird versucht, dies zu umgehen, indem das Problem vereinfacht wird. In einigen Fällen klappt das zwar, aber er ist eher als allerletzter Ausweg gedacht - in 99 von 100 Fällen gibt es bessere Möglichkeiten, das Problem zu lösen. Wie vermeiden Sie also die Notwendigkeit zum DD Modus, wenn Sie installieren? Beginnen Sie, indem Sie sich notieren, welche Geometrie das BIOS für Ihre Platten benutzt. Sie können erreichen, dass der Kernel sie beim Booten ausgibt, indem Sie an der Eingabeaufforderung boot: angeben, oder boot -v im Loader verwenden. Kurz bevor das Installationsprogramm startet, wird der Kernel eine Liste mit den BIOS-Geometrien ausgeben. Keine Panik - warten Sie, bis das Installationsprogramm gestartet wurde und benutzen Sie Scrollback, um die Zahlen zu lesen. Typischerweise befinden sich die BIOS-Platten in derselben Reihenfolge, wie &os; Ihre Platten auflistet - zuerst IDE, dann SCSI. Wenn Sie Ihre Festplatte in Slices unterteilen, überprüfen Sie, ob die Plattengeometrie, die im FDISK-Menü angegeben ist, korrekt ist (das heißt mit den Einstellungen im BIOS übereinstimmen). Falls die Werte nicht stimmen, benutzen Sie G, um sie zu korrigieren. Diese Schritte sind nötig, wenn sich absolut nichts auf der Festplatte befindet, oder, wenn die Festplatte vorher in einem anderen System benutzt worden ist. Beachten Sie, dass dies nur für die Festplatte nötig ist, von der Sie booten wollen. Mit weiteren vorhandenen Platten wird &os; sich problemlos zurechtfinden. Wenn Sie es geschafft haben, dass das BIOS und &os; in der Festplattengeometrie übereinstimmen, dann sind Ihre Probleme ziemlich sicher vorüber - ohne, dass es nötig gewesen wäre, den DD-Modus zu benutzen. Falls sie jedoch immer noch mit der gefürchteten read error-Meldung begrüßt werden sollten, wenn Sie versuchen, zu booten, wird es Zeit, dass Sie Ihre Finger kreuzen und es einfach versuchen - es gibt nichts mehr zu verlieren. Um eine dangerously dedicated Festplatte wieder für einen normalen PC brauchbar zu machen, gibt es zwei Möglichkeiten. Die erste ist, ausreichend viele NULL-Bytes in den MBR zu schreiben, um irgendwelche nachfolgenden Installation glauben zu machen, dass es sich um eine leere Festplatte handelt. Sie können das zum Beispiel mit diesem Befehl tun: &prompt.root; dd if=/dev/zero of=/dev/rda0 count=15 Alternativ installiert der undokumentierte DOS-Befehl C:\> fdisk /mbr einen neuen Master-Boot-Record, das heißt der BSD-Bootstrap wird zerstört. Auf welchen Partitionen kann ich problemlos Soft Updates einsetzen? Ich habe gehört, das der Einsatz von Soft Updates auf / Probleme verursachen kann. Die schnelle Antwort: Sie können Soft Updates bedenkenlos auf alle Partitionen benutzen. Die ausführliche Antwort: Es gab lange Zeit Bedenken, was den Einsatz von Soft Updates auf der root-Partition betrifft. Der Grund sind zwei Charakteristika der Soft Updates: Zum einen kann es bei einem Absturz des System auf einer Partition mit Soft Updates zum Datenverlust kommen. Die Partition ist zwar noch brauchbar, aber einige Daten können verloren gehen. Weiterhin kann es durch Soft Updates zu einem zeitweisen Mangel an Plattenplatz kommen. Bei der Benutzung von Soft Updates kann es bis zu dreißig Sekunden dauern, bis der Kernel Änderungen auf das physikalische Speichermedium schreibt. Wenn Sie eine große Datei löschen, ist diese Datei noch auf der Platte vorhanden, bis der Kernel die Löschoperation tatsächlich durchführt. Das kann zu einem sehr einfachen Problem führen: Stellen Sie sich vor, Sie löschen eine große Datei und legen gleich darauf eine andere große Datei an. Da die erste Datei noch nicht wirklich gelöscht wurde, ist eventuell nicht genug Platz für die zweite große Datei. Sie erhalten die Fehlermeldung, dass nicht genug freier Platz vorhanden ist, obwohl Sie ganz genau wissen, dass Sie gerade eben Platz geschaffen haben. Wenn Sie die Operation ein paar Sekunden später wiederholen, funktioniert alles wie von Geisterhand. Dieser Effekt hat mehr als einen Benutzer verwirrt und Zweifel an seiner geistigen Stabilität oder dem &os;-Dateisystem aufkommen lassen. Wenn der Kernel ein Datenpaket annimmt und das System abstürzt, bevor er dies Daten auf die Platte geschrieben hat, kann es zum Verlust oder zur Zerstörung von Daten kommen. Dieses Risiko ist nur sehr gering und normalerweise tragbar. Wenn Sie allerdings einen IDE-Write-Cache verwenden, steigt das Risiko; daher wird normalerweise empfohlen, auf den Einsatz dieser Technik zu verzichten, wenn Sie Soft Updates benutzen. Diese beiden Probleme betreffen alle Partitionen, die Soft Updates verwenden. Was bedeutet das für die Root-Partition? Die wichtigen Daten auf der Root-Partition ändern sich nur sehr selten. Dateien wie /boot/kernel/kernel und der Inhalt /etc werden nur bei der Wartung des Systems geändert, oder wenn Benutzer ihre Passwörter ändern. Wenn das System in den 30 Sekunden nach einer solchen Änderung abstürzt, ist es möglich, das Daten verloren gehen. Dieses Risiko ist in den meisten Fällen unerheblich, aber es ist vorhanden. Wenn das zu viel Risiko ist, dann sollten Sie Soft Updates nicht auf der Root-Partition einsetzen. / war schon immer eine der kleinsten Partitionen. Wenn Sie das Verzeichnis /tmp direkt auf / und in Ihrem /tmp viel Betrieb ist, kann es gelegentlich zu den oben beschriebenen Platzproblemen kommen. Um das Problem zu lösen, sollten sie einen symbolischen Link von /tmp nach /var/tmp legen. Was stimmt mit meinem &man.ccd.4; nicht? Das Symptom hierfür ist: &prompt.root; ccdconfig -C ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format Das geschieht für gewöhnlich, wenn Sie versuchen, die c Partitionen, die standardmäßig vom Typ unbenutzt sind, zu verbinden. Der &man.ccd.4;-Treiber verlangt Partitionen vom Typ FS_BSDFFS. Editieren Sie den Plattenlabel der Platten, die Sie zu verknüpfen versuchen und ändern Sie die Typen der Partitionen in 4.2BSD. Warum kann ich den Plattenlabel meines &man.ccd.4; nicht editieren? Das Symptom hierfür ist: &prompt.root; disklabel ccd0 (hier wird etwas vernünftiges ausgegeben; versuchen wir nun, es zu editieren) &prompt.root; disklabel -e ccd0 (editieren, speichern, beenden) disklabel: ioctl DIOCWDINFO: No disk label on disk; use "disklabel -r" to install initial label Der Grund ist, dass der von &man.ccd.4; zurückgelieferte Plattenlabel ein vorgetäuschter ist, der sich nicht wirklich auf der Platte befindet. Sie können das Problem beheben, indem Sie ihn explizit zurückschreiben, wie z.B. hier: &prompt.root; disklabel ccd0 > /tmp/disklabel.tmp &prompt.root; disklabel -Rr ccd0 /tmp/disklabel.tmp &prompt.root; disklabel -e ccd0 (nun wird es funktionieren) Kann ich andere fremde Dateisysteme unter &os; mounten? &os; unterstützt verschiedene fremde Dateisysteme. UFS UFS-CD-ROMs können unter &os; direkt gemountet werden. Das Mounten von Partitionen von Digital &unix; und anderen Systemen, die UFS unterstützen, könnte schwieriger sein, abhängig von den Details der Plattenpartitionierung des betreffenden Betriebssystems. ext2/ext3 &os; unterstützt ext2fs und ext3fs-Partitionen. Unter &man.mount.ext2fs.8; finden Sie weitere Informationen. NTFS Ein NTFS-Treiber, der nur Lesezugriffe gestattet, ist Teil von &os;. Weitere Informationen entnehmen Sie bitte der Hilfeseite &man.mount.ntfs.8;. Ein Port von ntfs-3g unterstützt Schreiboperationen auf NTFS (siehe sysutils/fusefs-ntfs). FAT &os; enthält ein FAT-Treiber, der Lese- und Schreibzugriffe ermöglicht. Weitere Informationen entnehmen Sie bitte der Hilfeseite &man.mount.msdosfs.8;. ReiserFS &os; enthält einen Treiber, der Lesezugriffe auf ReiserFS-Partitionen erlaubt. Weitere Informationen dazu finden Sie in der Manualpage &man.mount.reiserfs.8;. ZFS Zum jetzigen Zeitpunkt enthält &os; eine Portierung von &sun;s ZFS Treiber. Die aktuelle Empfehlung ist, es nur auf &arch.amd64; Plattformen mit ausreichend Hauptspeicher zu verwenden. Mehr Informationen finden Sie in der Manualpage &man.zfs.8;. &os; unterstützt auch verschiedene Netzwerk-Dateisysteme, wie NFS (&man.mount.nfs.8;), NetWare (&man.mount.nwfs.8;), sowie die SMB-Dateisysteme von Microsoft (&man.mount.smbfs.8;). In Ports die auf FUSE (sysutils/fusefs-kmod) basieren, können Sie viele weitere Dateisysteme finden. Wie mounte ich eine erweiterte DOS-Partition? Die erweiterten DOS-Partitionen befinden sich hinter allen primären Partitionen. Wenn sich zum Beispiel eine Partition E als sekundäre DOS-Partition auf Ihrem zweiten SCSI-Laufwerk befindet, wird eine Gerätedatei für Slice 5 im Verzeichnis /dev erstellt, also mounten Sie diese einfach: &prompt.root; mount -t msdosfs /dev/da1s5 /dos/e Gibt es ein verschlüsselndes Dateisystem für &os;? Ja. Sie können entweder &man.gbde.8; oder &man.geli.8; einsetzen. Lesen Sie dazu auch den Abschnitt Partitionen verschlüsseln des Handbuchs. Wie kann ich den &windowsnt;-Loader zum Booten von &os; verwenden? Das grundsätzliche Vorgehen besteht darin, dass Sie den ersten Sektor Ihrer eigentlichen &os;-Rootpartition in eine Datei auf der DOS/&windowsnt;-Partition kopieren. Angenommen, sie nennen die Datei etwa c:\bootsect.bsd (durch c:\bootsect.dos inspiriert), dann können Sie die Datei c:\boot.ini etwa wie folgt editieren: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" C:\BOOTSECT.BSD="&os;" C:\="DOS" Falls &os; auf derselben Platte, wie die &windowsnt;-Bootpartition installiert ist, kopieren Sie einfach /boot/boot1 nach C:\BOOTSECT.BSD. Falls &os; auf einer anderen Platte installiert ist, wird /boot/boot1 nicht funktionieren; Sie brauchen in diesem Fall /boot/boot0. /boot/boot0 muss mit &man.sysinstall.8; installiert werden. Wählen Sie dazu den &os;-Bootmanager aus, wenn Sie gefragt werden, ob sie einen Bootmanager installieren wollen. Dieser Schritt ist notwendig, weil /boot/boot0 eine leere Partitionstabelle enthält, die von &man.sysinstall.8; mit NULL-Zeichen ausgefüllt wird, bevor /boot/boot0 in den MBR kopiert wird. Sie dürfen auf gar keinen Fall einfach /boot/boot0 statt /boot/boot1 kopieren. Wenn Sie das doch tun sollten, wird Ihre Partitionstabelle überschrieben und Ihr Rechner wird nicht mehr starten! Wenn der Bootmanager von &os; gestartet wird, merkt er sich das zuletzt gestartet Betriebssystem, indem er dessen Partition als aktiv markiert. Danach kopiert er sich selbst (alle 512 Bytes) in den MBR. Wenn Sie also einfach /boot/boot0 nach C:\BOOTSECT.BSD kopieren, würde der Bootmanager eine leere Partitionstabelle (mit einem als aktiv markiertem Eintrag) in den MBR kopieren. Wie boote ich &os; und &linux; mit LILO? Falls sich &os; und &linux; auf derselben Platte befinden, folgen Sie einfach den Installationsanweisungen von LILO zum Booten eines Nicht-&linux;-Betriebssystems. Ganz knapp sind dies: Booten Sie &linux; und fügen Sie die folgenden Zeilen in die Datei /etc/lilo.conf ein: other=/dev/hda2 table=/dev/hda label=&os; (hierbei wird angenommen, dass Ihre &os;-Partition &linux; unter /dev/hda2 bekannt ist; ändern Sie dies entsprechend Ihren Einstellungen). Führen Sie nun als root den Befehl lilo aus und Sie sind fertig. Falls &os; sich auf einer anderen Platte befindet, müssen Sie loader=/boot/chain.b zu den LILO-Angaben hinzufügen. Zum Beispiel: other=/dev/dab4 table=/dev/dab loader=/boot/chain.b label=&os; In einigen Fällen könnte es sein, dass Sie beim &os;-Bootloader die BIOS-Laufwerksnummer angeben müssen, um von der zweiten Platte booten zu können. Wenn Ihre &os;-SCSI-Platte vom BIOS zum Beispiel als BIOS-Platte 1 erkannt wird, müssen Sie am Prompt des &os;-Bootloaders eingeben: Boot: 1:da(0,a)/boot/kernel/kernel Sie können &man.boot.8; so konfigurieren, dass das beim Booten automatisch geschieht. Das &linux;+FreeBSD mini-HOWTO ist ein guter Ratgeber bei Fragen zur Interaktion von &os; und &linux;. Wie boote ich &os; und &linux; mit GRUB? Es ist sehr einfach, GRUB zum Starten von &os; einzusetzen. Dazu müssen Sie lediglich die folgenden Zeilen in die Konfigurationsdatei /boot/grub/menu.lst (oder /boot/grub/grub.conf bei manchen Systemen wie z.B. Red Hat Linux und dessen Abkömmlinge) aufnehmen. title &os; 6.1 root (hd0,a) kernel /boot/loader Dabei steht hd0,a für die root-Partition Ihrer ersten Festplatte. Benötigen Sie auch die Slice-Nummer, so verwenden Sie einen Eintrag der Form (hd0,2,a). In der Voreinstellung ist die Angabe der Slice-Nummer aber nicht nötig, da GRUB automatisch das erste Slice (das die Bezeichnung a hat) nutzt. Wie boote ich &os; und &linux; mit BootEasy? Installieren Sie LILO am Anfang Ihrer &linux;-Bootpartition, anstatt im Master Boot Record. Sie können LILO dann von BootEasy aus booten. Wenn Sie &windows; und &linux; benutzen, wird das ohnehin empfohlen, um es einfacher zu machen, &linux; wieder zu booten, wenn es nötig werden sollte, dass Sie &windows; neu installieren (&windows; ist ein eifersüchtiges Betriebssystem, das kein anderes Betriebssystem im Master Boot Sektor duldet). Wie kann ich das ??? des Boot-Managers durch etwas Sinnvolles ersetzen? Solange Sie den Boot-Manager nicht komplett neu schreiben, gar nicht. Allerdings gibt es in der Kategorie sysutils der Ports diverse Boot-Manager, die diese Funktionalität bieten. Ich habe ein Wechsellaufwerk. Wie benutze ich es? Ob es sich um ein Wechsellaufwerk handelt, um ein &iomegazip; oder ein EZ-Laufwerk (oder sogar ein Diskettenlaufwerk, wenn Sie es auf diese Weise benutzen möchten), oder um eine neue Festplatte - wenn es einmal installiert und vom System erkannt ist und Sie Ihre Kassette/Diskette/was_auch_immer eingelegt haben, ist das Vorgehen bei allen Geräten ziemlich ähnlich. (dieser Abschnitt basiert auf Mark Mayo's ZIP-FAQ) Wenn es sich um ein ZIP- oder Diskettenlaufwerk handelt, und sich bereits ein DOS-Dateisystem darauf befindet, können Sie einen Befehl wie diesen für eine Diskette benutzen: &prompt.root; mount -t msdosfs /dev/fd0c /floppy oder diesen: &prompt.root; mount -t msdosfs /dev/da2s4 /zip für eine ZIP-Disk mit der Herstellerkonfiguration. Benutzen Sie bei anderen Platten &man.fdisk.8; oder &man.sysinstall.8;, um herauszufinden, wie sie konfiguriert sind. Die restlichen Beispiele sind für ein ZIP-Laufwerk unter da2, der dritten SCSI-Platte. Wenn es sich nicht um eine Diskette oder eine Wechselplatte handelt, die Sie mit anderen Leuten austauschen wollen, ist es wahrscheinlich besser, ein BSD-Dateisystem darauf zu installieren. Hierdurch bekommen Sie Unterstützung für lange Dateinamen, eine mindestens doppelt so hohe Leistungsausnutzung und wesentlich höhere Stabilität. Zunächst müssen Sie die Partitionen/Dateisysteme auf DOS-Ebene nochmals erstellen. Sie können entweder &man.fdisk.8; oder &man.sysinstall.8; benutzen, oder, bei einem kleinen Laufwerk, dem Sie eine Unterstützung für mehrere Betriebssysteme nicht zumuten wollen, entfernen Sie einfach die komplette FAT Partitionstabelle (Slices) und benutzen Sie einfach die BSD-Partitionierung: &prompt.root; dd if=/dev/zero of=/dev/rda2 count=2 &prompt.root; disklabel -Brw da2 auto Sie können &man.disklabel.8; oder &man.sysinstall.8; benutzen, um mehrere BSD-Partitionen zu erstellen. Dies werden Sie sicherlich bei einer fest eingebauten Platte wollen, aber bei einem Wechsellaufwerk wie einem ZIP ist das wahrscheinlich irrelevant. Zum Schluß erstellen Sie ein neues Dateisystem - dieses befindet sich auf unserem ZIP-Laufwerk und belegt die gesamte Platte: &prompt.root; newfs /dev/rda2c anschließend mounten Sie es: &prompt.root; mount /dev/da2c /zip Und sicherlich ist es keine schlechte Idee, eine Zeile ähnlich der folgenden in die Datei /etc/fstab einzufügen, damit Sie in Zukunft nur mount /zip einzugeben brauchen: /dev/da2c /zip ffs rw,noauto 0 0 Wieso erhalte ich die Meldung Incorrect super block beim Mounten einer CD-ROM? Sie müssen &man.mount.8; mitteilen, was für ein Gerät Sie mounten wollen. Genauere Informationen dazu finden Sie im Kapitel Optische Speichermedien des Handbuch, genauer gesagt im Abschnitt Benutzung von Daten-CDs. Wieso erhalte ich die Meldung Device not configured, wenn ich eine CD-ROM mounte? Das bedeutet im allgemeinen, dass sich keine CD-ROM im Laufwerk befindet, oder, dass das Laufwerk auf dem Bus nicht sichtbar ist. Dieses Problem wird im Kapitel Benutzung von Daten-CDs des Handbuchs ausführlich diskutiert. Wieso werden alle Sonderzeichen in den Dateinamen auf meinen CDs durch ? ersetzt, wenn ich die CD unter &os; benutze? Wahrscheinlich werden auf der CD-ROM die Joliet Erweiterungen für die Speicherung von Datei- und Verzeichnisnamen benutzt. Werfen Sie einen Blick in das Kapitel Erzeugung von CD-ROMs im Handbuch, speziell in den Abschnitt über Benutzung von Daten-CDs. [Anmerkung des Übersetzers: Es geht hier nicht um die deutschen Sonderzeichen, da diese schon im normalen ISO8859-1 enthalten sind. Die Probleme treten auf, wenn man z.B. russische CDs (ISO8859-5) verwendet.] Ich habe eine CD mit &os; gebrannt und kann sie nicht mit anderen Betriebssystemen lesen. Warum? Sie haben wahrscheinlichste eine Datei direkt auf CD geschrieben, statt ein ISO 9660-Dateisystem erzeugt zu haben. Werfen Sie einen Blick in das Kapitel Erzeugung von CD-ROMs im Handbuch, speziell in den Abschnitt über reine Daten-CDs. Wie kann ich ein Image einer Daten-CD erzeugen? Diese Information finden Sie im Abschnitt Kopieren von CD-ROMs des Handbuchs. Weitere Informationen über die Arbeit mit CD-ROMs finden Sie im Abschnitt Erzeugen von CD-ROMs im Kapitel Speichermedien des Handbuchs. Wieso kommt mount nicht meiner Audio-CD zurecht? Wenn Sie versuchen sollten, eine Audio-CD zu mounten, erhalten Sie die Meldung cd9660: /dev/acd0c: Invalid argument. Der Grund dafür ist, dass mount nur für Dateisysteme vorgehen ist. Audio CDs habe kein Dateisystem, sondern nur Daten. Wenn Sie eine Audio CD auslesen wollen, brauchen Sie ein entsprechendes Programm wie z.B. audio/xmcd aus den Ports. Wie nutze ich mount für eine Multi-Session CD? Standardmäßig benutzt &man.mount.8; den letzten (aktuellsten) Daten-Track der CD. Wenn Sie eine ältere Session benutzen wollen, müssen Sie diese mit der Option definieren. Weitere Informationen finden Sie in der Onlinehilfe zu &man.mount.cd9660.8; Wie lasse ich normale Benutzer Disketten, CD-ROMs und andere Wechseldatenträger mounten? Normale Benutzer können dazu berechtigt werden, Geräte zu mounten. Das geht so: Setzen Sie als root die sysctl-Variable vfs.usermount auf 1: &prompt.root; sysctl -w vfs.usermount=1 Ordnen Sie als root den Block-Geräten, die den Wechsellaufwerken zugeordnet sind, die entsprechenden Zugriffsrechte zu. Wenn Sie zum Beispiel den Benutzer den Zugriff auf das erste Diskettenlaufwerk zu erlauben wollen: &prompt.root; chmod 666 /dev/fd0 Um den Mitgliedern der Gruppe operator den Zugriff auf das CD-ROM zu gestatten: &prompt.root; chgrp operator /dev/acd0c &prompt.root; chmod 640 /dev/acd0c Sie müssen zusätzlich /etc/devfs.conf anpassen, weil diese Einstellungen ansonsten beim Systemneustart verloren gehen. Damit normale Benutzer beispielsweise das erste Diskettenlaufwerk mounten können, fügen Sie als root folgende Zeilen in /etc/devfs.conf ein: # Allen Benutzern erlauben, das erste Diskettenlaufwerk zu mounten. own /dev/fd0 root:operator perm /dev/fd0 0666 Damit alle Mitglieder der Gruppe operator das CD-ROM-Laufwerk mounten können, die folgenden Zeilen: # Alle Mitglieder der Gruppe operator dürfen CD-ROMs mounten. own /dev/acd0 root:operator perm /dev/acd0 0660 Fügen Sie zum Abschluss die Zeile vfs.usermount=1 in die Datei /etc/sysctl.conf ein, damit die Einstellung bei einem Neustart des Systems automatisch erhalten bleibt. Alle Benutzer können nun /dev/fd0 auf ein Verzeichnis, das ihnen gehört, mounten: &prompt.user; mkdir ~/my-mount-point &prompt.user; mount -t msdosfs /dev/fd0 ~/my-mount-point Die zur Gruppe operator gehörenden Benutzer können nun /dev/acd0c auf ein Verzeichnis, das ihnen gehört, mounten: &prompt.user; mkdir ~/my-mount-point &prompt.user; mount -t cd9660 /dev/acd0c ~/my-mount-point Das Unmounten des Gerätes ist simpel: &prompt.user; umount ~/my-mount-point Die Aktivierung von vfs.usermount hat jedoch negative Auswirkungen auf Sicherheitsaspekte. Ein besserer Weg, um auf &ms-dos;-formatierte Datenträger zuzugreifen, ist die Benutzung des Packages emulators/mtools. Denken Sie daran, dass Sie die Gerätenamen in diesen Beispielen an Ihre Konfiguration anpassen müssen. Wieso geben die Befehle du und df unterschiedliche Werte für den freien Plattenplatz aus? Der Grund ist die Funktionsweise von du und df. du geht durch einen Dateibaum, ermittelt die Größe jeder einzelnen Datei, und gibt die Summe aus. df fragt lediglich das Dateisystem wie viel Platz noch frei ist. Das scheint zwar auf den ersten Blick sehr ähnlich zu sein; allerdings wird sich ein leeres Verzeichnis auf die Ausgabe von df auswirken, während es auf das Ergebnis von du keinen Einfluss hat. Wenn Sie eine Datei löschen, während sie von einem Programm genutzt wird, wird diese Datei erst gelöscht, wenn sie vom Programm freigegeben wird. Allerdings wird die Datei sofort aus dem Verzeichnis entfernt. Sie können dieses Verhalten mit einem Programm wie more sehr einfach nachvollziehen. Dazu brauchen Sie nur eine Datei, die groß genug ist, um die Ausgabe von du und df zu beeinflussen. Bei der Größe aktueller Platten muss diese Datei schon sehr groß sein! Wenn Sie diese Datei löschen, während Sie sie sich in more anzeigen lassen, hat more kein Problem. Der Eintrag für die Datei wird lediglich aus dem Verzeichnis entfernt, damit kein anderes Programm mehr darauf zugreifen kann. Laut du ist die Datei verschwunden – es hat das Verzeichnis untersucht und die Datei nicht gefunden. Laut df ist die Datei aber vorhanden, da sie im Dateisystem immer noch Platz belegt. Sobald Sie more beenden, werden die Ergebnisse von du und df wieder übereinstimmen. Bitte beachten Sie, dass die Freigabe des Plattenplatzes durch die Soft Updates um bis zu 30 Sekunden verzögert werden kann. Die oben beschriebene Situation tritt sehr häufig auf Web-Servern auf. Viele Anwender installieren einen &os; Web-Server und vergessen die Rotation der Logfiles, bis irgendwann die Partition /var überläuft. Der Administrator löscht die Datei, aber das System beschwert sich immer noch über fehlenden Plattenplatz. Die Datei wird erst freigegeben, wenn der Web-Server beendet und neu gestartet wird; dadurch kann das System den Plattenplatz freigeben. Um solche und ähnliche Unfälle zu verhindern, sollten Sie &man.newsyslog.8; einsetzen. Wie kann ich den Swap-Bereich vergrößern? Im Kapitel Konfiguration und Tuning des Handbuches gibt es einen Abschnitt mit einer Schritt-für-Schritt Anleitung. Warum ist meine Festplatte unter &os; kleiner, als sie laut Hersteller sein soll? Festplattenhersteller definieren ein Gigabyte als eine Milliarde Bytes, für &os; ist ein Gigabyte hingegen 1.073.741.824 Bytes groß. Aus diesem Grund wird für eine Platte, die laut Herstellerangaben 80 GB groß ist, während des Bootvorgangs eine Größe von 76.319 MB angezeigt. Beachten Sie auch, dass &os; (in der Voreinstellung) 8 % des Plattenplatzes für sich reserviert. Warum kann eine Partition zu mehr als 100% gefüllt sein? Ein Teil jeder UFS Partition, in der Vorgabe sind das 8%, ist für das Betriebssystem und den Benutzer root reserviert. &man.df.1; rechnet diesen Teil bei der Ausgabe der Capacity Spalte nicht ein, so dass dort Werte über 100% angezeigt werden können. Die Anzahl der Blöcke in der blocks Spalte ist ebenfalls um 8% größer als die Summe der benutzten und verfügbaren Blöcke (die Spalten Used und Avail). Wie viel Platz reserviert wird, können Sie mit der Option von &man.tunefs.8; einstellen. Systemadministration Wo befinden sich die Konfigurationsdateien für den Systemstart? /etc/defaults/rc.conf (siehe &man.rc.conf.5;) ist die primäre Konfigurationsdatei. Die Startskripten des Systems, wie /etc/rc und /etc/rc.d (siehe &man.rc.8;) inkludieren diese Datei. Ändern Sie diese Datei nicht! Wenn Sie den Wert einer der in /etc/defaults/rc.conf gesetzten Variablen ändern wollen, fügen Sie die entsprechende Zeile in die Datei /etc/rc.conf ein und ändern die Zeile dort. Wenn Sie zum Beispiel den mitgelieferten DNS-Server &man.named.8 aktivieren wollen, müssen Sie lediglich das folgende Kommando eingeben: &prompt.root; echo named_enable="YES" >> /etc/rc.conf Wenn Sie lokale Server starten wollen, müssen Sie passende Shellskripten im Verzeichnis /usr/local/etc/rc.d/ ablegen. Die Dateien müssen als ausführbar markiert sein und die Dateiberechtigungen 555 besitzen. Wie kann ich am Einfachsten einen Benutzer hinzufügen? Benutzen Sie den Befehl &man.adduser.8; und für kompliziertere Fälle den Befehl &man.pw.8;. Benutzen Sie den Befehl &man.rmuser.8;, um einen Benutzer wieder zu löschen. Sie können, wenn nötig. auch &man.pw.8; benutzen. Warum erhalte ich Meldungen wie root: not found, nachdem ich meine crontab geändert habe? Die übliche Ursache dieses Problems ist, dass Sie die crontab des Systems (/etc/crontab) geändert und dann mit &man.crontab.1; installiert haben: &prompt.root; crontab /etc/crontab Diese Vorgehensweise ist falsch. Die crontab des Systems hat ein anderes Format als die crontabs für die einzelnen Benutzer, die mit &man.crontab.1; aktualisiert werden (genauere Informationen über die Unterschiede erhalten Sie in &man.crontab.5;). Wenn Sie so vorgegangen sind, ist die zweite crontab einfach nur eine Kopie von /etc/crontab, allerdings im falschen Format. Löschen Sie sie mit dem folgenden Befehl: &prompt.root; crontab -r Wenn Sie /etc/crontab wieder ändern müssen, sollten Sie einfach gar nichts tun, um &man.cron.8; über die Änderung zu informieren, er erkennt die Änderung automatisch. Wenn Sie ein Kommando jeden Tag, jede Woche oder jeden Monat ausführen lassen wollen, ist es wahrscheinlich einfacher, wenn Sie entsprechende Shell-Scripte in /usr/local/etc/periodic ablegen. Diese werden dann von &man.periodic.8; zusammen mit den anderen regelmäßigen cron Tätigkeiten ausgeführt. Der eigentliche Grund für den Fehler ist die Tatsache, dass die crontab des Systems ein zusätzliches Feld enthält; dieses Feld gibt an, mit welcher Benutzerkennung der Befehl ausgeführt werden soll. In der mitgelieferten crontab ist das bei allen Einträgen die Benutzerkennung root. Wenn diese Datei als die crontab des Benutzers username (die nicht mit der crontab des Systems identisch ist) verwendet wird, hält &man.cron.8; die Zeichenkette root für den Namen des zu startenden Programmes, aber dieses Programm gibt es nicht. Wieso meldet mir &man.su.1; you are not in the correct group to su root, wenn ich mit su root werden will? Das ist ein Sicherheits-Feature. Wenn Sie mit su zum Account root (oder jedem anderen Account mit Super-User-Privilegien) wechseln wollen, müssen Sie ein Mitglied der Gruppe wheel sein. Wenn es dieses Feature nicht gäbe, könnte jeder, der einen Account auf dem System hat und zufällig das Passwort für root erfährt, mit Super-User-Rechten auf das System zugreifen. Durch dieses Feature ist die Lage anders, wenn Sie nicht Mitglied von wheel sind, können Sie nicht einmal versuchen, dass Passwort einzugeben. Um einem Benutzer zu erlauben, mit su root zu werden, müssen Sie ihn nur in die Gruppe wheel eintragen. Ich habe einen Fehler in der rc.conf oder einer der anderen Dateien für den Systemstart und jetzt kann ich sie nicht ändern, weil das Dateisystem read-only ist. Was kann ich tun? Starten Sie das System mittels boot -s an der Loader-Eingabeaufforderung neu, um in den Single-User-Modus zu gelangen. Wenn Sie aufgefordert werden, den Pfadnamen der Shell einzugeben, drücken Sie einfach Enter. Geben Sie danach mount -urw / ein, um das Root-Dateisystem im Schreib/Lese-Modus zu mounten. Sie werden wahrscheinlich auch mount -a -t ufs ausführen müssen, um das Dateisystem mit Ihrem Lieblingseditor zu mounten. Wenn Ihr Lieblingseditor auf einem Netzwerklaufwerk liegt, müssen Sie entweder das Netzwerk von Hand konfigurieren oder einen Editor benutzen, der auf einem lokalen Laufwerk vorhanden ist, z.B. &man.ed.1;. Wenn Sie einen bildschirmorientierten Editor wie zum Beispiel &man.vi.1; oder &man.emacs.1; benutzen wollen, werden Sie auch den Befehl export TERM=cons25 ausführen müssen, damit diese Editoren die richtigen Einstellungen aus der Datenbank &man.termcap.5; übernehmen. Sobald Sie diese Schritte ausgeführt, können Sie den Fehler in der /etc/rc.conf ganz normal beheben. Die Fehlermeldungen, die Ihnen unmittelbar nach den Startmeldungen des Kernels angezeigt wurden, sollten Ihnen die Nummer der Zeile mit dem Fehler melden. Wieso habe ich habe Probleme, meinen Drucker einzurichten? Lesen sie den Handbucheintrag über Drucker. Es sollte die meisten Ihrer Probleme behandeln. Einige Drucker benötigen einen auf dem Rechner laufenden Treiber, um drucken zu können. Diese so genannten WinPrinter oder GDI-Drucker werden von &os; nicht unterstützt und an diesem Zustand wird sich wohl auch nichts ändern. Wenn Ihr Drucker nicht unter DOS oder &windows; verwendet werden kann, handelt es sich um einen WinPrinter und wird in der Regel auch nicht unter &os; funktionieren. Ihre einzige Chance, einen dieser Drucker benutzen können, ist der Port ports/print/pnm2ppa. Wie kann ich die Tastaturbelegung meines Systems korrigieren? Informationen dazu finden Sie im Kapitel länderspezifische Einstellungen des Handbuchs, insbesondere im Abschnitt Konfiguration der Konsole. Wieso erhalte ich beim Start des Systems Meldungen wie unknown: <PNP0303> can't assign resources? Die nachfolgende Erklärung stammt aus einer Mail auf der Mailingliste &a.current;.
&a.wollman;, 24 April 2001 Die Geräte, für die can't assign resources-Meldungen ausgegeben werden, sind Legacy ISAGeräte, für die ein nicht PNP-fähiger Treiber in den Kernel eingebunden wurde. Dabei handelt es sich um Geräte wie den Tastaturkontroller, den programmierbaren Interrupt-Kontroller und diverse andere Standardkomponenten. Die Ressourcen können nicht zugewiesen werden, weil es schon einen Treiber gibt, der diese Ressourcen benutzt.
Wieso funktionieren die Benutzer-Quotas nicht richtig? Es kann sein, dass Ihr Kernel nicht für den Einsatz von Quotas konfiguriert ist. Damit Sie mit Quotas arbeiten können, müssen Sie folgende Zeile in Ihre Kernelkonfigurationsdatei aufnehmen und den Kernel neu bauen: options QUOTA Weitere Informationen zum Einsatz von Quotas finden Sie im entsprechenden Abschnitt des Handbuchs. Benutzen Sie keine Quotas für /. Erstellen Sie die Quotas-Datei in dem Dateisystem, für das die Quotas gelten sollen, z.B.: File System Quota file /usr /usr/admin/quotas /home /home/admin/quotas Unterstützt &os; IPC-Grundfunktionen von System V? Ja, &os; unterstützt IPC im Stil von System V einschließlich gemeinsamen Speicher, Nachrichten und Semaphoren bereits mit dem GENERIC-Kernel. Wenn Sie einen angepassten Kernel verwenden, müssen Sie die folgenden Zeilen in Ihre Kernelkonfigurationsdatei einfügen: options SYSVSHM options SYSVSHM # enable shared memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging Danach kompilieren und installieren Sie den neuen Kernel. Welchen Mail-Server kann ich an Stelle von sendmail benutzen? sendmail ist zwar der Mail-Server, der bei &os; standardmäßig installiert wird, aber Sie können Ihn problemlos durch einen anderen MTA (z.B. aus den Ports) ersetzen. In der Port-Sammlung gibt es bereits viele verschiedene MTAs, mail/exim, mail/postfix, mail/qmail, sowie mail/zmailer sind einige der beliebteren Alternativen. Konkurrenz belebt das Geschäft und die Tatsache, dass Sie die Qual der Wahl haben, ist ein Vorteil. Daher sollten Sie Fragen wie Ist sendmail besser als qmail? besser nicht auf den Mailinglisten stellen. Wenn Sie dieses Thema interessiert, sollten sie zunächst die Archive durchsehen. Die Vorteile und Nachteile jedes einzelnen der verfügbaren MTAs sind schon mehrere Male bis zur Erschöpfung diskutiert worden. Was kann ich machen, wenn ich das Rootpasswort vergessen habe? Keine Panik! Starten Sie Ihr System neu und geben Sie boot -s an der Eingabeaufforderung Boot: ein, um in den Single-User-Modus zu gelangen. Bei der Frage danach, welche Shell benutzt werden soll, drücken Sie einfach Enter. Nun erscheint die Eingabeaufforderung &prompt.root;. Geben Sie mount -urw / ein, um Ihr Root-Dateisystem für Lese- und Schreibzugriffe zu remounten und dann mount -a, um alle Dateisysteme zu remounten. Mit passwd root können Sie das Rootpasswort ändern und mit &man.exit.1; können Sie mit dem Booten fortfahren. Wenn Sie immer noch dazu aufgefordert werden, das root Passwort beim Betreten des Single-User-Modus einzugeben, bedeutet das, dass die Konsole als insecure in /etc/ttys markiert wurde. In diesem Fall ist es notwendig, von einem &os; Installationsmedium zu booten, die Fixit-Shell auszuwählen und die oben beschriebenen Befehle einzugeben. Wenn Sie ihre root Partition im Single-User-Modus nicht mounten können, liegt es möglicherweise daran, dass die Partionen verschlüsselt sind und es damit unmöglich ist, sie ohne die dazugehörigen Schlüssel zu mounten. Ihre Chancen hängen von der jeweiligen Implementierung ab. Für weitere Informationen lesen Sie den Abschnittt über verschlüsselte Partitionen im &os; Handbuch. Wie verhindere ich, dass das System mit Ctrl Alt Delete rebootet werden kann? Falls Sie &man.syscons.4; (der Standard-Treiber für die Konsole) benutzen, fügen Sie folgende Zeile in Ihre Kernelkonfigurationsdatei ein: options SC_DISABLE_REBOOT Alternativ können Sie auch die folgende &man.sysctl.8;-Variable setzen (die aktiviert wird, ohne dass Sie Ihr System dazu neu starten oder einen angepassten Kernel erstellen müssen): &prompt.root; sysctl hw.syscons.kbd_reboot=0 Die beiden oben genannten Methoden schliessen sich gegenseitig aus: &man.sysctl.8; existiert nicht, wenn Sie ihren Kernel mit der Option SC_DISABLE_REBOOT bauen. Falls Sie den &man.pcvt.4; Konsolentreiber verwenden, fügen Sie die folgende Zeile in die Kernelkonfigurationsdatei hinzu und bauen Sie einen neuen Kernel: options PCVT_CTRL_ALT_DEL Wie kann ich Textdateien von DOS Systemen auf &unix; Systemen verwenden? Benutzen Sie diesen Perl-Befehl: &prompt.user; perl -i.bak -npe 's/\r\n/\n/g' file(s) Wobei file(s) eine oder mehrere zu verarbeitende(n) Datei(en) ist/sind. Die Änderungen erfolgen in der Originaldatei, die zuvor mit der Erweiterung .bak gesichert wird. Alternativ können Sie den Befehl &man.tr.1; benutzen: &prompt.user; tr -d '\r' < dos-text-file > unix-file dos-text-file ist die Datei, die den Text im DOS-Format enthält und unix-file wird die konvertierte Ausgabe enthalten. Diese Möglichkeit könnte etwas schneller sein, als die Benutzung von perl. Die Verwendung des Ports converters/dosunix aus der Ports-Sammlung stellt eine weitere Möglichkeit dar, DOS-Textdateien neu zu formatieren. Konsultieren Sie die Dokumentation für weitere Informationen. Wie beende ich Prozesse namentlich? Benutzen Sie &man.killall.1;. Warum nervt &man.su.1; mich damit, dass ich nicht in der ACL von root bin? Der Fehler stammt vom verteilten Authentifizierungssystem Kerberos. Das Problem ist nicht ernsthaft, aber störend. Sie können entweder su mit der Option benutzen, oder Kerberos deinstallieren, wie in der nächsten Frage beschrieben. Wie deinstalliere ich Kerberos? Um Kerberos aus dem System zu entfernen, müssen Sie die base-Distribution der von Ihnen benutzten RELEASE neu installieren. Wenn Sie die CD-ROM besitzen, können Sie sie mounten (wir nehmen an, unter /cdrom) und folgende Befehle ausführen: &prompt.root; cd /cdrom/base &prompt.root; ./install.sh Alternativ können Sie mit der Option NO_KERBEROS in der /etc/make.conf ein make world durchführen. Wo ist /dev/MAKEDEV hin? Ab &os; 5.X werden Geräte automatisch von &man.devfs.8; zur Verfügung gestellt. Die Gerätetreiber erstellen die Gerätedateien, wenn diese benötigt werden. Das Skript /dev/MAKEDEV wird nicht mehr gebraucht. Wie füge ich Pseudo-Terminals zum System hinzu? Wenn Sie viele Benutzer von telnet, ssh, X oder screen haben, werden Ihnen eventuell die Pseudo-Terminals ausgehen. Standardmässig unterstützt &os; 6.2 und vorherige Versionen 256 Pseudo-Terminals, während &os; 6.3 und höher 512 Pseudo-Terminals zur Verfügung stellt. Wenn nötig, können mehr Pseudo-Terminals hinzugefügt werden. Allerdings muss dafür die C-Blibliothek, der Kernel und /etc/ttys erweitert werden. Zum Beispiel erhöht die Anzahl an Pseudo-Terminals auf 1152. Beachten Sie, dass die Erweiterung nur für &os; 6.3 oder höher problemlos funktioniert. Wie lade ich /etc/rc.conf und starte /etc/rc neu, ohne zu rebooten? Gehen Sie in den Single-User-Modus und dann zurück in den Multi-User-Modus. Geben Sie auf der Konsole folgendes ein: &prompt.root; shutdown now (Hinweis: ohne -r oder -h) &prompt.root; return &prompt.root; exit Ich wollte auf das aktuelle -STABLE updaten, und plötzlich läuft hier ein -BETAx, -RC oder -PRERELEASE! Was ist passiert? Kurze Antwort: Das ist nur ein anderer Name. RC ist die Abkürzung für Release Candidate. Es bedeutet, dass eine neue Release bevorsteht. Und -PRERELEASE bedeutet bei &os; normalerweise, dass die Sourcen zur Vorbereitung auf eine Release eingefroren wurden (in einigen Releases wurde -BETA anstelle von -PRERELEASE verwendet). Ausführliche Antwort: Bei &os; gibt es zwei Quellen für Releases. Die Major Releases wie - 6.0-RELEASE und 7.0-RELEASE werden aus dem aktuellen Stand + 7.0-RELEASE und 8.0-RELEASE werden aus dem aktuellen Stand des Hauptzweiges der Entwicklung (besser und kürzer als -CURRENT bekannt) erzeugt. Minor Releases wie 6.3-RELEASE oder 5.2-RELEASE stammen aus dem aktiven -STABLE Zweig. Seit 4.3-RELEASE gibt es es nun auch einen eigenen Zweig für jede Release, der für die Leute gedacht ist, die ein sehr konservativ weiterentwickeltes System benötigen (im Normalfall also nur Updates aus dem Bereich Sicherheit). Bevor in einem Zweig eine Release erfolgt, muss in diesem Zweig ein bestimmter Prozess ablaufen. Ein Teil dieses Prozesses ist der code freeze, der Stop der Weiterentwicklung. Sobald dieser Schritt erfolgt ist, wird der Name des Zweiges geändert, um anzuzeigen, dass demnächst eine Release erfolgen wird. Wenn der Zweig zum Beispiel 6.2-STABLE genannt wurde, wird der Name in 6.3-PRERELEASE geändert, um dies zu verdeutlichen. Weiterhin ist das ein Zeichen, dass jetzt besonders intensiv getestet werden sollte. In dieser Phase können Fehler im Sourcecode noch korrigiert werden. Wenn der Sourcecode so weit gereift ist, dass eine Release erstellt werden kann, wird der Name in 6.3-RC geändert, um genau dies anzuzeigen. In dieser Phase können nur noch extrem wichtige Korrekturen aufgenommen werden. Sobald die Release (in diesem Beispiel 6.3-RELEASE) erfolgt ist, wird der Zweig in 6.3-STABLE umbenannt. Weitere Informationen über Versionsnummern und die verschiedenen Entwicklungszweige enthält der Artikel Release Engineering. Als ich versucht habe, einen neuen Kernel zu installieren, ist das &man.chflags.1; fehlgeschlagen. Was mache ich jetzt? Kurze Antwort: Ihre Sicherheitseinstellung (der securelevel) ist wahrscheinlich größer als 0. Sie müssen das System neu starten und den Kernel im Single-User-Modus installieren. Ausführliche Antwort: Wenn die Sicherheitseinstellung größer als 0 ist, erlaubt Ihnen &os; nicht, die Systemflags zu ändern. Um den aktuellen Securelevel zu ermitteln, können Sie das folgende Kommando benutzen: &prompt.root; sysctl kern.securelevel Sie können die Sicherheitseinstellung nicht verringern. Sie müssen das System neu starten und den Kernel im Single-User-Modus installieren oder die Sicherheitseinstellung in /etc/rc.conf ändern und dann das System neu starten. Weitere Details zu securelevel erhalten Sie in &man.init.8;, weitere Informationen zur rc.conf erhalten Sie in /etc/defaults/rc.conf und &man.rc.conf.5;. Ich kann die Systemzeit nicht um mehr als eine Sekunde verstellen. Was mache ich jetzt? Kurze Antwort: Ihre Sicherheitseinstellung (der securelevel) ist wahrscheinlich größer als 1. Sie müssen das System neu starten und die Systemzeit im Single-User-Modus verstellen. Ausführliche Antwort: Wenn die Sicherheitseinstellung größer als 1 ist, erlaubt Ihnen &os; nicht, die Systemzeit zu ändern. Um den aktuellen Securelevel zu ermitteln, können Sie das folgende Kommando benutzen: &prompt.root; sysctl kern.securelevel Sie können die Sicherheitseinstellung nicht verringern, Sie müssen das System neu starten und die Systemzeit im Single-User-Modus ändern oder die Sicherheitseinstellung in /etc/rc.conf ändern und dann das System neu starten. Weitere Details zu securelevel erhalten Sie in &man.init.8;, weitere Informationen zur rc.conf erhalten Sie in /etc/defaults/rc.conf und &man.rc.conf.5;. Warum braucht &man.rpc.statd.8; 256 MB Speicher? Nein, das Programm hat keinen Fehler und es verbraucht auch nicht 256 MB Speicher. rpc.statd projiziert nur einen übertrieben großen Speicherbereich in seinen eigenen Adressraum. Von einem rein technischen Standpunkt aus ist das nichts verwerfliches, allerdings verwirrt es Programme wie &man.top.1; und &man.ps.1;. &man.rpc.statd.8; projiziert seine Statusdatei (die in /var liegt) in seinen Adressraum. Um die Probleme zu vermeiden, die bei einer Vergrößerung dieser Projektion entstehen könnten, wird gleich ein möglichst großer Speicherbereich benutzt. Dies kann man sehr schön im Sourcecode sehen: Die Längenangabe beim Aufruf von &man.mmap.2; ist 0x10000000, ein sechzehntel des Adressraums bei IA32, oder genau 256 MByte. Warum kann ich das Dateiattribut schg nicht löschen? Sie betreiben Ihr System mit einer erhöhten Sicherheitsstufe. Senken Sie die Sicherheitsstufe und versuchen Sie es dann noch einmal. Weitere Informationen erhalten Sie im FAQ Eintrag über Sicherheitsstufen und in der Online-Hilfe &man.init.8;. Warum funktioniert die .shosts Authentifizierung von SSH in neueren Versionen von &os; nicht mehr? Die .shosts Authentifizierung funktioniert nicht mehr, weil &man.ssh.1; in neueren Versionen von &os; nicht mehr SUID-root installiert wird. Um dieses Problem zu lösen, gibt es die folgenden Möglichkeiten: Um das Problem für immer zu lösen, müssen Sie in /etc/make.conf die Variable ENABLE_SUID_SSH auf true setzen und danach &man.ssh.1; neu übersetzen (oder make world) ausführen. Übergangsweise können Sie auch die Dateirechte von /usr/bin/ssh auf 4555 setzen, indem Sie den Befehl chmod 4555 /usr/bin/ssh als root ausführen. Fügen Sie anschließend ENABLE_SUID_SSH =true in die Datei /etc/make.conf ein, damit diese Änderung erhalten bleibt, wenn Sie das nächste Mal make world ausführen. Was ist vnlru? vnlru schreibt vnodes auf Platte und gibt sie wieder frei, falls das System die Grenzwert kern.maxvnodes erreicht. Dieser Thread des Kernel tut meistens gar nichts und wird nur aktiv, wenn Sie extrem viel RAM haben und gleichzeitig auf viele zehntausende kleine Dateien zugreifen. Was bedeuten die Zustände, die top für Speicherseiten ausgibt? Speicherseiten werden vom Kernel in verschiedenen Listen verwaltet: Active: Seiten, die vor Kurzem benutzt wurden. Inactive: Seiten, die länger nicht benutzt wurden. Cache: Meistens Seiten, die vorher im Zustand Inactive waren und noch gültige Daten enthalten. Diese Seiten können sofort in ihrem alten Kontext oder in einem neuen Kontext verwendet werden. Wenn eine Seite unverändert (clean) ist, kann ein Zustandswechsel direkt von Active nach Cache erfolgen. Ob dieser Zustandswechsel möglich ist, wird durch die Seitenersetzungsstrategie bestimmt, die der Entwickler des VM-Systems festgelegt hat. Free: Seiten, die keine Daten enthalten. Diese Seiten können sofort benutzt werden, wenn Seiten im Zustand Cache nicht benutzt werden können. Seiten im Zustand Free können auch während eines Interrupts angefordert werden. Wired: Seiten, die fest im Speicher liegen und nicht ausgelagert werden können. Normalerweise werden solche Seiten vom Kernel benutzt, manchmal werden Sie aber auch für spezielle Zwecke von Prozessen verwendet. Seiten im Zustand Inactive werden oft auf Plattenspeicher geschrieben (sozusagen ein sync des VM-Systems). Wenn die CPU erkennen kann, das eine Seite unmodifiziert (clean) ist, kann auch eine Active-Seite auf den Plattenspeicher ausgeschrieben werden. In bestimmten Situationen ist es von Vorteil, wenn ein Block von VM-Seiten, unabhängig von seinem Zustand, ausgeschrieben werden kann. Die Inactive-Liste enthält wenig benutzte Seiten, die ausgeschrieben werden könnten. Seiten im Zustand Cached sind schon ausgeschrieben und stehen Prozessen für die Verwendung im alten oder in einem neuen Kontext zur Verfügung. Seiten im Zustand Cache sind nicht ausreichend geschützt und können während Unterbrechungen nicht benutzt werden. Die eben beschriebene Behandlung von Speicherseiten kann durch weitere Zustände (wie das das Busy-Flag) verändert werden. Wie viel freien Speicher hat mein System? Es gibt verschiedene Arten von freiem Speicher. Eine Art ist die Speichermenge, die sofort, ohne etwas auszulagern, zur Verfügung steht. Der gesamte VM-Bereich ist eine weitere Art des freien Speichers. Die Betrachtung ist komplex, hängt aber von der Größe des Swap-Bereichs und der Größe des Arbeitsspeichers ab. Es gibt weitere Definitionen für freien Speicher, die aber alle relativ nutzlos sind. Wichtig ist hingegen, dass wenig Seiten ausgelagert werden (paging) und der Swap-Bereich ausreichend groß ist. Ich kann /var/empty nicht löschen! Das Verzeichnis /var/empty wird von &man.sshd.8; benötigt, wenn es mit Privilege Separation läuft. Das Verzeichnis /var/empty ist leer, gehört root und ist durch das Dateiattribut schg geschützt. Wir empfehlen Ihnen, das Verzeichnis zu belassen. Sollten Sie es aber trotzdem löschen wollen, müssen Sie zuerst das schg-Attribut entfernen. Schauen Sie sich dazu die Hilfeseite &man.chflags.1; an und beachten Sie die Antwort auf die Frage wie das schg-Attribut entfernt wird.
Das X Window System und virtuelle Konsolen Was ist das X Window System? Das X Window System (oder auch nur X11) ist das am häufigsten verwendete Window System für &unix;- und &unix;-ähnliche Systeme, zu denen auch &os; gehört. Der X  Protokollstandard wird von der X.org Foundation definiert und liegt aktuell in Version 11 Release &xorg.version; vor und wird häufig auch nur als X11 bezeichnet. Das X Window System wurde für viele verschiedene Architekturen und Betriebssysteme implementiert. Eine serverseitige Implementierung wird dabei als X-Server bezeichnet. Welche X-Implementierungen sind für &os; verfügbar? Früher war &xfree86;, die X-Implementierung des XFree86 Projects, Inc., der Standard unter &os;. Dieser X-Server wurde bis einschließlich &os; Version 4.10 und 5.2 als Standard-X-Server installiert. Die von &xorg; veröffentlichte Implementierung diente nur als Referenzplattform, weil der verwendete Code über die Jahre sehr ineffizient geworden war. Anfang 2004 verließen einige Entwickler das XFree86 Project, um fortan &xorg; direkt zu unterstützen. Der Grund dafür waren Meinungsverschiedenheiten über die Geschwindigkeit der Weiterentwicklung, die zukünftige Ausrichtung des Projekts sowie persönliche Differenzen. Zur gleichen Zeit aktualisierte &xorg; ihren Quellcodebaum auf die &xfree86;-Version 4.3.99.903, brachte viele Änderungen, die bisher getrennt verwaltet worden waren, in das Projekt ein und veröffentlichte das Paket als X11R6.7.0, bevor &xfree86; die Lizenz änderte. Ein separates, aber mit &xorg; verbundenes Projekt, freedesktop.org (oder fd.o), arbeitet an einer Überarbeitung des ursprünglichen &xfree86;-Codes, um einerseits mehr Rechenarbeit an die Grafikkarten zu übertragen (mit dem Ziel einer deutlich erhöhten Geschwindigkeit) und andererseits den Code zu modularisieren (mit dem Ziel einer verbesserten Wartung, einer schnelleren Entwicklung sowie einer vereinfachten Konfiguration). &xorg; plant, die Weiterentwicklungen von freedesktop.org in seine zukünftigen Versionen zu integrieren. Seit Juli 2004 ist &xorg; der Standard-X-Server für &os;. Seitdem ist &xorg; in &os; als Standard-X11 implementiert. Weitere Informationen zum X Window System finden Sie im X11-Kapitel des &os;-Handbuchs. Warum hat sich das X Project überhaupt aufgespalten? Diese Frage ist nicht &os;-spezifisch. Es gibt zu diesem Thema umfangreiche Postings in diversen Mailinglist-Archiven. Suchen Sie daher über eine Suchmaschine danach, statt diese Frage auf einer &os;-Mailingliste zu stellen. Warum hat sich &os; für &xorg; als Standard-X-Server entschieden? Die Entwickler von &xorg; gaben an, dass sie neue Versionen rascher veröffentlichen und neue Eigenschaften schneller implementieren wollen. Außerdem verwenden sie nach wie vor die traditionelle X-Lizenz, während &xfree86; eine veränderte Version benutzt. Ich möchte X benutzen, was muss ich tun? Wenn Sie X auf einem existierenden System installieren wollen, sollten Sie entweder den Meta-Port x11/xorg verwenden, der alle benötigen Komponenten baut und installiert, oder Sie installieren die &os; &xorg;-Pakete: &prompt.root; pkg_add -r xorg Es ist auch möglich, &xorg; aus &man.sysinstall.8; heraus zu installieren, indem Sie Configure, dann Distributions und anschliessend The X.Org Distribution aufrufen. Lesen Sie nach erfolgreicher Installation von &xorg; den Abschnitt X11 konfigurieren im &os; Handbuch. Ich habe versucht, X zu starten, aber wenn ich startx eingebe, erhalte ich die Fehlermeldung KDENABIO failed (Operation not permitted). Was soll ich jetzt machen? Das System läuft auf einer erhöhten Sicherheitsstufe (securelevel). X kann auf einer erhöhten Sicherheitsstufe nicht gestartet werden, weil X dazu Schreibzugriff auf &man.io.4; benötigt. Lesen Sie dazu auch &man.init.8;. Die Frage ist also eigentlich, was Sie anders machen sollten. Sie haben zwei Möglichkeiten: Setzen Sie die Sicherheitsstufe wieder zurück auf 0 (die Einstellung erfolgt in der Regel in /etc/rc.conf) oder starten Sie &man.xdm.1; während des Starts des Systems, bevor die Sicherheitsstufe erhöht wird. Der Abschnitt enthält Informationen darüber, wie Sie &man.xdm.1; beim Start des Systems starten können. Warum funktioniert meine Maus unter X nicht? Wenn Sie &man.syscons.4; (den Standard-Konsolentreiber) benutzen, können Sie &os; so konfigurieren, dass auf jedem virtuellen Bildschirm ein Mauszeiger unterstützt wird. Um Konflikte mit X zu vermeiden, unterstützt &man.syscons.4; ein virtuelles Gerät mit dem Namen /dev/sysmouse. Alle Mausbewegungen und Mausklicks werden in das &man.sysmouse.4; Gerät über &man.moused.8; geschrieben. Falls Sie Ihre Maus auf einer oder mehreren virtuellen Konsolen und X benutzen wollen, sollten Sie zunächst lesen und dann &man.moused.8; installieren. Die Datei /etc/X11/xorg.conf sollte die folgenden Einträge enthalten: Section "InputDevice" Option "Protocol" "SysMouse" Option "Device" "/dev/sysmouse" ..... Einige Leute ziehen es vor, unter X /dev/mouse zu benutzen. Hierzu sollte /dev/mouse nach /dev/sysmouse (lesen Sie &man.sysmouse.4;) gelinkt werden, indem Sie die folgende Zeile in /etc/devfs.conf (siehe auch &man.devfs.conf.5;) hinzufügen: link sysmouse mouse Die Verknüpfung kann durch Neustart von &man.devfs.5; über das folgende Kommando (als root) erzeugt werden: &prompt.root; /etc/rc.d/devfs restart Kann ich meine Rad-Maus auch unter X benutzen? Ja. Dazu müssen Sie X nur mitteilen, dass Sie eine Maus mit 5 Tasten haben. Dazu fügen Sie die Zeilen Buttons 5 sowie ZAxisMapping 4 5 in den Abschnitt InputDevice der Datei /etc/X11/xorg.conf ein. Das Beispiel zeigt, wie ein solcher Abschnitt aussehen könnte. Abschnitt <quote>InputDevice</quote> für Rad-Mäuse in der Konfigurationsdatei von &xorg; Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection <quote>.emacs</quote> Beispiel für seitenweises Blättern mit einer Rad-Maus (optional) ;; wheel mouse (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) X verbietet Verbindungen von entfernten Systemen! Aus Sicherheitsgründen verbietet der X-Server in der Voreinstellung Verbindungen von entfernten Systemen. Starten Sie den X-Server mit der Option , wenn Sie Verbindungen von entfernten Systemen erlauben wollen: &prompt.user; startx -listen_tcp Was ist eine virtuelle Konsole und wie erstelle ich mehr? Mit virtuellen Konsolen können Sie mehrere simultane Sitzungen auf einer Maschine laufen lassen, ohne so komplizierte Dinge wie die Einrichtung eines Netzwerkes oder die Benutzung von X zu benötigen. Wenn das System startet, wird es nach der Anzeige aller Bootmeldungen eine Eingabeaufforderung auf dem Bildschirm anzeigen. Sie können dann auf der ersten virtuellen Konsole Ihren Benutzernamen und das Passwort eingeben und anfangen, zu arbeiten (oder zu spielen!). Gelegentlich möchten Sie möglicherweise eine weitere Sitzung starten wollen, vielleicht, um die Dokumentation zu einem Programm, das Sie gerade benutzen, einzusehen, oder, um Ihre Mails zu lesen, während Sie auf das Ende einer FTP-Übertragung warten. Drücken Sie einfach AltF2 (halten Sie die Alt-Taste gedrückt und drücken Sie die Taste F2) und Sie gelangen zur Anmelde-Aufforderung auf der zweiten virtuellen Konsole! Wenn Sie zurück zur ersten Sitzung möchten, drücken Sie AltF1 . Die Standardinstallation von &os; bietet acht aktivierte virtuelle Konsolen. Mit AltF1, AltF2, AltF3 und so weiter wechseln Sie zwischen diesen virtuellen Konsolen. Um mehr von ihnen zu aktivieren, editieren Sie /etc/ttys (siehe &man.ttys.5;) und fügen Einträge für ttyv8 bis zu ttyvc nach dem Kommentar zu virtuellen Terminals ein: # Edit the existing entry for ttyv8 in /etc/ttys and change # "off" to "on". ttyv8 "/usr/libexec/getty Pc" cons25 on secure ttyv9 "/usr/libexec/getty Pc" cons25 on secure ttyva "/usr/libexec/getty Pc" cons25 on secure ttyvb "/usr/libexec/getty Pc" cons25 on secure Benutzen Sie so wenig oder so viele, wie Sie möchten. Je mehr virtuelle Terminals Sie benutzen, desto mehr Ressourcen werden gebraucht; das kann wichtig sein, wenn Sie 8 MB RAM oder weniger besitzen. Sie können auch secure in insecure ändern. Wenn Sie einen X-Server benutzen möchten, müssen Sie mindestens ein virtuelles Terminal unbenutzt (oder ausgeschaltet) lassen damit der Server es benutzen kann. Das heißt, dass Sie Pech haben, wenn Sie für jede Ihrer 12 Alt-Funktionstasten eine Anmeldeaufforderung haben möchten - Sie können das nur für elf von ihnen tun, wenn Sie einen X-Server auf derselben Maschine laufen lassen möchten. Der einfachste Weg, eine Konsole zu deaktivieren, ist, sie auszuschalten. Wenn Sie zum Beispiel die oben erwähnte volle Zuordnung aller 12 Terminals hätten, müssten Sie die Einstellung für das virtuelle Terminal 12 von: ttyvb "/usr/libexec/getty Pc" cons25 on secure in: ttyvb "/usr/libexec/getty Pc" cons25 off secure ändern. Wenn Ihre Tastatur nur über zehn Funktionstasten verfügt, bedeutet das: ttyv9 "/usr/libexec/getty Pc" cons25 off secure ttyva "/usr/libexec/getty Pc" cons25 off secure ttyvb "/usr/libexec/getty Pc" cons25 off secure (Sie können diese Zeilen auch einfach löschen.) Die einfachste (und sauberste) Möglichkeit, die virtuellen Konsolen zu aktivieren, ist, zu rebooten. Wenn Sie jedoch auf keinen Fall rebooten möchten, können Sie auch einfach das X Window System herunterfahren und als root &prompt.root; kill -HUP 1 ausführen. Es ist unbedingt erforderlich, dass Sie das X Window System vollständig herunterfahren, falls es läuft. Falls Sie es nicht tun, könnte es sein, dass sich ihr System nach der Eingabe des kill-Befehls aufhängt. Wie greife ich von X aus auf virtuelle Konsolen zu? Benutzen Sie CtrlAlt Fn um auf eine virtuelle Konsole umzuschalten. Mit CtrlAlt F1 würden Sie zur ersten virtuellen Konsole umschalten. Sobald Sie auf eine virtuelle Konsole umgeschaltet haben, können Sie ganz normal Alt Fn benutzen, um zwischen den einzelnen virtuellen Konsolen umzuschalten. Um zu Ihrer X-Sitzung zurückzukehren, müssen Sie auf die virtuelle Konsole umschalten, auf der X läuft. Wenn Sie X über der Eingabeaufforderung gestartet haben (z.B. mit startx), benutzt X die nächste freie virtuelle Konsole und nicht die Konsole, von der es gestartet wurde. Wenn Sie acht aktive virtuelle Konsole haben, dann wird X die neunte benutzen und Sie können mit AltF9 umschalten. Wie starte ich XDM beim Booten? Es gibt zwei Denkansätze, wie &man.xdm.1; zu starten ist. Bei dem einen wird xdm unter Nutzung des mitgelieferten Beispiels über /etc/ttys (&man.ttys.5;) gestartet, während beim zweiten Ansatz rc.local (&man.rc.8;) oder das Skript X im Verzeichnis /usr/local/etc/rc.d verwendet wird. Beide Ansätze sind gleichwertig und der eine wird in Situationen funktionieren, in denen der andere es nicht tut. In beiden Fällen ist das Ergebnis das gleiche: X liefert eine graphische Anmeldeaufforderung. Die &man.ttys.5;-Methode hat den Vorteil, dass dokumentiert ist, auf welchem vty X gestartet wird und der Neustart des X-Servers beim Abmelden an &man.init.8; übergeben wird. Die &man.rc.8;-Methode erleichtert den Aufruf von kill xdm, falls Probleme beim Start des X-Servers auftreten sollten. Beim Laden von &man.rc.8; sollte xdm ohne irgendwelche Argumente (das heißt als Daemon) gestartet werden. Das Kommando xdm muss gestartet werden nachdem &man.getty.8; läuft, andernfalls entsteht ein Konflikt zwischen getty und xdm und die Konsole bleibt gesperrt. Der beste Weg, um dies zu vermeiden, ist, das Skript für etwa zehn Sekunden anzuhalten und dann xdm zu starten. Wenn Sie xdm durch einen Eintrag in /etc/ttys starten lassen, kann es zu einem Konflikt zwischen xdm und &man.getty.8; kommen. Um dieses Problem zu vermeiden, sollten Sie die Nummer des vt in die Datei /usr/local/lib/X11/xdm/Xservers eintragen: :0 local /usr/local/bin/X vt4 Diese Zeile führt dazu, dass der X Server /dev/ttyv3 nutzt. Die beiden Zahlen weichen voneinander ab: Der X-Server beginnt die Zählung der vty bei 1, während der &os;-Kernel bei 0 beginnt. Wieso erhalte ich die Meldung Couldn't open console, wenn ich xconsole benutze? Wenn Sie X mit startx starten, werden die Zugriffsrechte für /dev/console leider nicht geändert, was dazu führt, dass Dinge wie xterm -C und xconsole nicht funktionieren. Das hängt damit zusammen, wie die Zugriffsrechte für die Konsole standardmäßig gesetzt sind. Auf einem Mehrbenutzersystem möchte man nicht unbedingt, dass jeder Benutzer einfach auf die Systemkonsole schreiben kann. Für Benutzer, die sich auf einer Maschine direkt mit einem VTY anmelden, existiert die Datei &man.fbtab.5;, um derartige Probleme zu lösen. In Kürze: sorgen Sie dafür, dass sich in der Datei /etc/fbtab eine nicht auskommentierte Zeile der folgenden Art befindet: /dev/ttyv0 0600 /dev/console Das sorgt dafür, dass wer auch immer sich auf /dev/ttyv0 anmeldet, auch die Konsole besitzt. Früher konnte ich &xfree86; als normaler User starten. Warum sagt mir das System jetzt, dass ich root sein muss? Alle X-Server müssen mit der ID root laufen, um direkt auf die Videohardware zuzugreifen. Die älteren Versionen von &xfree86; (bis einschließlich 3.3.6) installierten alle mitgelieferten Server so, dass sie automatisch unter ID root ausgeführt werden (setuid to root). Dies stellt natürlich eine Gefahrenquelle dar, da die X-Server große, komplexe Programme sind. Alle neueren Versionen von &xfree86; installieren die Server aus genau diesem Grund nicht mehr "setuid root". Es ist natürlich nicht tragbar, den X-Server immer mit der ID root laufen zu lassen; auch aus Gründen der Sicherheit ist es keine gute Idee. Es gibt zwei Möglichkeiten, um X auch als normaler Benutzer starten zu können. Die erste ist die Verwendung von xdm oder eines ähnlichen Programms; die zweite ist die Benutzer von Xwrapper. xdm ist ein ständig laufendes Programm, mit dem Logins über eine graphische Benutzeroberfläche sind. Es wird normalerweise beim Systemstart initialisiert und für die Authentifizierung der Benutzer und den Start ihrer Sitzungen verantwortlich. Es ist also die graphische Entsprechung von &man.getty.8; und &man.login.1;. Weitere Informationen zum Thema xdm finden Sie in der &xfree86; Dokumentation und dem entsprechenden FAQ-Eintrag. Xwrapper ist eine Hülle für den X-Server. Mit diesem kleinen Utility ist es möglich, manuell den X-Server zu starten und weiterhin eine annehmbare Sicherheit zu haben. Das Tools prüft, ob die per Kommandozeile übergebenen Argumente halbwegs sinnvoll sind. Wenn dies der Fall ist, startet es den entsprechenden X-Server. Wenn Sie (aus welchem Grund auch immer) keine graphische Anmeldung wollen, ist Xwrapper die optimale Lösung. Wenn Sie die vollständige Ports-Sammlung installiert haben, finden Sie das Tool im Verzeichnis x11/wrapper. Warum funktioniert meine PS/2-Maus nicht richtig? Ihre Maus und der Maustreiber sind etwas aus der Synchronisation geraten. In seltenen Fällen kann es jedoch sein, dass der Treiber fälschlicherweise Synchronisationsprobleme meldet und Sie in den Kernelmeldungen folgendes sehen: psmintr: out of sync (xxxx != yyyy) und Ihre Maus nicht richtig zu funktionieren scheint. Falls das passiert, deaktivieren Sie den Code zur Überprüfung der Synchronisation, indem Sie die Treiberangaben für den PS/2-Maustreiber auf 0x100 setzen. Rufen Sie UserConfig durch Angabe der Option am Boot-Prompt auf: boot: -c Geben sie dann in der Kommandozeile von UserConfig folgendes ein: UserConfig> flags psm0 0x100 UserConfig> quit Meine PS/2-Maus von MouseSystems scheint nicht zu funktionieren. Es wurde berichtet, dass einige Modelle der PS/2-Mäuse von MouseSystems nur funktionieren, wenn sie im hochauflösenden Modus betrieben werden. Andernfalls springt der Mauszeiger sehr oft in die linke obere Ecke des Bildschirms. Das Flag 0x04 des Maustreibers bringt die Maus in den hochauflösenden Modus. Rufen Sie UserConfig durch Angabe der Option am Boot-Prompt auf: boot: -c Geben sie dann in der Kommandozeile von UserConfig folgendes ein: UserConfig> flags psm0 0x04 UserConfig> quit Lesen Sie den vorigen Abschnitt über eine andere mögliche Ursache für Probleme mit der Maus. Wie vertausche ich die Maustasten? Benutzen Sie den Befehl xmodmap -e "pointer = 3 2 1" in Ihrer .xinitrc oder .xsession. Wie installiere ich einen Splash-Screen und wo finde ich sie? Die detaillierte Antwort auf diese Frage können Sie im Abschnitt Splash-Screens während des Systemstarts des Handbuchs nachlesen. Kann ich die Windows-Tasten unter X benutzen? Ja, Sie müssen lediglich mit &man.xmodmap.1; festlegen, welche Aktion diese Tasten auslösen sollen. Unter der Annahme, dass alle Windows Tastaturen dem Standard entsprechen, lauten die Keycodes für die drei Tasten wie folgt: 115 - Windows-Taste zwischen den Ctrl- und Alt-Tasten auf der linken Seite 116 - Windows-Taste rechts von der AltGr-Taste 117 - Menü-Taste, links von der rechten Strg-Taste Nach der folgenden Anweisung erzeugt die linke Windows-Taste ein Komma. &prompt.root; xmodmap -e "keycode 115 = comma" Sie werden Ihren Window Manager wahrscheinlich neu starten müssen, damit diese Einstellung wirksam wird. Um die neue Belegung der Windows-Tasten automatisch beim Start von X zu erhalten, könnten Sie entsprechende xmodmap Anweisungen in ihre ~/.xinitrc einfügen. Die bevorzugte Variante ist aber, eine Datei mit dem Namen ~/.xmodmaprc zu erzeugen, die nur die Parameter für den Aufruf von xmodmap enthält. Wenn Sie mehrere Tasten umdefinieren wollen, muss jede Definition in eine eigene Zeile gesetzt werden. Weiterhin müssen Sie in Ihrer ~/.xinitrc noch die folgende Zeile einfügen: xmodmap $HOME/.xmodmaprc Sie könnten die drei Tasten zum Beispiel mit den Funktionen F13, F14 und F15 belegen. Dadurch ist es sehr einfach, diese Tasten mit nützlichen Funktionen eines Programmes oder Desktops zu verknüpfen. Falls Sie das auch tun wollen, sollten in Ihrer ~/.xmodmaprc die folgenden Anweisungen stehen. keycode 115 = F13 keycode 116 = F14 keycode 117 = F15 Falls Sie zum Beispiel den x11-wm/fvwm2 Port benutzen, können Sie ihn so einstellen, dass F13 das Fenster unter dem Mauszeiger minimiert bzw. maximiert. F14 holt das Fenster unter dem Mauszeiger in den Vordergrund bzw. ganz nach hinten, wenn es bereits im Vordergrund ist. F15 öffnet das Arbeitsplatz (Programme) Menü, auch wenn der Cursor nicht auf den Hintergrund zeigt. Dies ist extrem praktisch, wenn der gesamte Bildschirm von Fenster belegt wird; als kleiner Bonus gibt es sogar einen Zusammenhang zwischen dem Symbol auf der Taste und der durchgeführten Aktion. Dieses Verhalten kann man mit den folgenden Einträgen in der Datei ~/.fvwmrc erhalten: Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop Wird 3D Hardware Beschleunigung für &opengl; unterstützt? Dies hängt davon ab, welche Version von &xorg; und welche Grafikkarte Sie verwenden. Wenn Sie eine Karte mit NVIDIA-Chipsatz besitzen, benutzen Sie die binären Treiber für &os;, indem Sie einen der folgenden Ports installieren: Die aktuelle Version von NVIDIA-Karten wird durch den Port x11/nvidia-driver unterstützt. NVIDIA Karten wie die GeForce2 MX/3/4 Serie wird durch die 96XX Treiber unterstützt, die im x11/nvidia-driver-96xx Port bereitgestellt werden. Sogar ältere Karten wie die GeForce und RIVA TNT sind durch die 71XX Treiberserie verfügbar, die im Port x11/nvidia-driver-71xx enthalten ist. Tatsächlich liefert NVIDIA detaillierte Informationen darüber, welche Karte von welchem Treiber unterstützt wird. Diese Information finden Sie auf der Website von NVIDIA: . Für Matrox G200/400 sehen Sie sich den Port x11-servers/mga_hal an. Bei ATI Rage 128 und Radeon lesen Sie die Anleitungen &man.ati.4x;, &man.r128.4x; und &man.radeon.4x;. Fü 3dfx Vodoo 3, 4, 5 und Banshee Karten gibt es einen x11-servers/driglide Port. Netzwerke Woher kann ich Informationen über Diskless Booting bekommen? Diskless Booting bedeutet, dass die &os;-Maschine über ein Netzwerk gebootet wird und die notwendigen Dateien von einem Server anstatt von der Festplatte liest. Vollständige Details finden Sie im Handbucheintrag über den plattenlosen Betrieb. Kann eine &os;-Maschine als Netzwerkrouter genutzt werden? Ja. Genaue Informationen zu diesem Thema finden Sie im Abschnitt Gateways und Routen des Handbuchkapitels Weiterführende Netzwerkthemen. Kann ich meine &windows;-Maschine über &os; ans Internet anbinden? Personen, die diese Frage stellen, haben typischerweise zwei PCs zu Hause: einen mit &os; und einen mit einer &windows;-Variante. Die Idee ist, die &os;-Maschine an das Internet anzubinden, um in der Lage zu sein, von der &windows;-Maschine über die &os;-Maschine auf das Internet zuzugreifen. Das ist tatsächlich nur ein Spezialfall der vorherigen Frage. Das User-Mode &man.ppp.8; von &os; kennt die Option . Wenn Sie &man.ppp.8; mit der Option starten, in /etc/rc.conf die Variable gateway_enable auf YES setzen und Ihre &windows;-Maschine korrekt konfigurieren, sollte das hervorragend funktionieren. Weitere Informationen erhalten Sie in der Hilfeseite &man.ppp.8; oder im Abschnitt User-PPP des Handbuchs. Wenn Sie Kernel-Mode PPP verwenden oder ihre Verbindung zum Internet über Ethernet erstellt wurde, müssen Sie &man.natd.8; verwenden. Weitere Informationen dazu finden Sie im natd-Abschnitt des Handbuchs. Unterstützt &os; SLIP und PPP? Ja. Lesen Sie die Manualpages &man.slattach.8;, &man.sliplogin.8;, &man.pppd.8; und &man.ppp.8;. &man.ppp.8; und &man.pppd.8; liefern Unterstützung sowohl für eingehende, als auch ausgehende Verbindungen. &man.sliplogin.8; behandelt ausschließlich eingehende Verbindungen und &man.slattach.8; behandelt ausschließlich ausgehende Verbindungen. Diese Programme werden im Abschnitt PPP und SLIP des Handbuchs beschrieben. Falls Sie nur durch einen Shell-Account Zugang zum Internet haben, sehen Sie sich einmal das Package net/slirp an. Es kann Ihnen (eingeschränkten) Zugang zu Diensten wie ftp und http direkt von Ihrer lokalen Maschine aus ermöglichen. Unterstützt &os; NAT oder Masquerading? Ja. Wenn Sie NAT über eine User-PPP-Verbindung einsetzen wollen, lesen Sie bitte den User-PPP Abschnitt des Handbuchs. Wollen Sie NAT über eine andere Verbindung einsetzen, lesen Sie bitte den NATD-Abschnitt des Handbuchs. Wie verbinde ich zwei &os;-Maschinen mit PLIP über die parallele Schnittstelle? Dieses Thema wird im Handbuch-Kapitel PLIP behandelt. Wie kann ich Ethernet-Aliase einrichten? Wenn sich die zweite Adresse im gleichen Subnetz befindet wie eine der Adressen, die bereits auf dem Interface konfiguriert sind, benutzen Sie netmask 0xffffffff in Ihrer &man.ifconfig.8; Befehlszeile, wie z.B.: &prompt.root; ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff Andernfalls geben sie die Adresse und die Netzmaske so an, wie sie es bei einem normalen Interface auch tun würden: &prompt.root; ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00 Sie können mehr darüber im &os; Handbuch nachlesen. Wie bringe ich meine 3C503 dazu, den anderen Anschluss zu benutzen? Wenn Sie die anderen Anschlüsse benutzen möchten, müssen Sie einen zusätzlichen Parameter in der &man.ifconfig.8;-Befehlszeile spezifizieren. Der Standard-Anschluss ist link0. Um den AUI-Anschluss anstelle des BNC-Anschlusses zu verwenden, benutzen Sie link2. Diese Angaben sollten durch Benutzung der Variablen ifconfig_* in der Datei /etc/rc.conf spezifiziert werden. Warum habe ich Probleme mit NFS und &os;? Gewisse PC-Netzwerkkarten sind (um es gelinde auszudrücken) besser als andere und können manchmal Probleme mit netzwerkintensiven Anwendungen wie NFS verursachen. Weitere Informationen zu diesem Thema finden Sie im Handbucheintrag zu NFS. Warum kann ich per NFS nicht von einer &linux;-Maschine mounten? Einige Versionen des NFS-Codes von &linux; akzeptieren Mount-Requests nur von einem privilegierten Port. Versuchen Sie den folgenden Befehl: &prompt.root; mount -o -P linuxbox:/blah /mnt Warum kann ich per NFS nicht von einer &sun;-Maschine mounten? Sun Workstations mit &sunos; 4.X akzeptieren Mount-Requests nur von einem privilegierten Port. Versuchen Sie dieses Kommando: &prompt.root; mount -o -P sunbox:/blah /mnt Warum meldet mir mountd auf meinem &os; NFS-Server ständig can't change attributes und bad exports list? Die häufigste Ursache für dieses Problem ist, dass Sie den Aufbau der &man.exports.5; nicht oder nicht richtig verstanden haben. Überprüfen Sie Ihre &man.exports.5; und lesen das Kapitel NFS im Handbuch, speziell den Abschnitt Konfiguration. Warum habe ich Probleme, per PPP mit NeXTStep-Maschinen zu kommunizieren? Versuchen Sie, die TCP-Erweiterung in /etc/rc.conf zu deaktivieren, indem Sie die folgende Variable auf NO setzen: tcp_extensions=NO Xylogic's Annex-Maschinen arbeiten hier auch fehlerhaft und Sie müssen die obige Änderung benutzen, um über Sie Verbindungen herzustellen. Wie aktiviere ich die Unterstützung für IP-Multicast? Multicast-Host-Funktionen werden standardmäßig von &os; unterstützt. Wenn Sie Ihre Maschine als Multicast-Router betreiben wollen, müssen Sie Ihren Kernel mit der Option MROUTING neu kompilieren und &man.mrouted.8; starten. Wenn Sie die Variable mrouted_enable in der Datei /etc/rc.conf auf YES setzen, wird &man.mrouted.8; während des &os;-Systemstarts automatisch gestartet. In aktuellen Versionen von &os; sind die Programme &man.mrouted.8;, der Multicast Routing Dienst, &man.map-mbone.8; und &man.mrinfo.8; nicht mehr im Basissystem enthalten. In der &os; Ports-Sammlung sind diese Programme unter net/mrouted erhältlich. MBONE-Tools sind in ihrer eigenen Ports-Kategorie mbone verfügbar. Schauen Sie dort nach, wenn Sie die Konferenztools vic und vat suchen! Welche Netzwerkkarten basieren auf dem DEC-PCI-Chipsatz? Hier ist eine von Glen Foster gfoster@driver.nsta.org zusammengetragene Liste mit einigen aktuellen Ergänzungen: Netzwerkkarten mit DEC-PCI-Chipsatz Vendor Model ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435, DE450 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Modell 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Znyx (2.2.X) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 Znyx (3.X) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442, ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd)
Warum muss ich für Hosts auf meiner Site den FQDN benutzen? Lesen Sie die Antwort im &os; Handbook. Wieso erhalte ich bei allen Netzwerkoperationen die Meldung Permission denied? Dieses Problem kann auftreten, wenn Sie einen Kernel mit der Option IPFIREWALL erstellt haben. In der Voreinstellung werden alle Pakete, die nicht explizit erlaubt wurden, blockiert. Falls sie Ihr System unbeabsichtigt als Firewall konfiguriert haben, können Sie die Netzwerkfunktionalität wiederherstellen, indem Sie als root folgendes eingeben: &prompt.root; ipfw add 65534 allow all from any to any Sie können in /etc/rc.conf auch firewall_type="open" setzen. Weitere Informationen über die Konfiguration einer &os;-Firewall finden Sie im Kapitel Firewalls des Handbuchs. Warum kann ich bei &man.ipfw.8; einen Dienst nicht mit fwd auf eine andere Maschine umlenken? Der wahrscheinlichste Grund ist, dass Sie Network Address Translation (NAT) brauchen und nicht die einfache Weiterleitung von Pakete. Die fwd Anweisung macht genau das, was da steht: Sie leitet Pakete weiter; die Daten in den Paketen werden aber nicht verändert. Ein Beispiel: 01000 fwd 10.0.0.1 from any to foo 21 Wenn ein Paket mit dem Ziel foo die Maschine mit dieser Regel erreicht, wird das Paket an 10.0.0.1 weitergeleitet; die Zieladresse im Paket lautet aber immer noch foo! Die Zieladresse wird nicht in 10.0.0.1 geändert. Die meisten Rechner werden allerdings Pakete verwerfen, wenn die Zieladresse des Paketes nicht mit der Adresse des Rechners übereinstimmt. Das ist der Grund, warum eine fwd Regel oft nicht den Effekt hat, den der Benutzer wollte. Dieses Verhalten ist aber kein Fehler, sondern erwünscht. Wenn Sie einen Dienst auf eine andere Maschine umleiten wollen, sollten Sie sich den FAQ-Eintrag über die Umleitung von Diensten oder die Online-Hilfe zu &man.natd.8; durchlesen. Auch in der Ports Sammlung sind diverse Hilfsprogramme für diesen Zweck enthalten. Wie kann ich Service-Requests von einer Maschine auf eine andere umleiten? Sie können FTP-Requests (und andere Dienste) mit dem Port sysutils/socket umleiten. Ersetzen sie die Befehlszeile für den Dienst einfach so, dass stattdessen socket aufgerufen wird, zum Beispiel so: ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp wobei ftp.example.com und ftp entsprechend der Host und der Port sind, wohin umgeleitet werden soll. Woher kann ich ein Bandbreiten-Managementtool bekommen? Für &os; gibt es drei Bandbreiten-Managementtools. &man.dummynet.4; ist als Teil von &man.ipfw.4; in &os; integriert. ALTQ ist in &os; Bestandteil von &man.pf.4;. Bei Bandwidth Manager von Emerging Technologies handelt es sich hingegen um ein kommerzielles Produkt. Warum erhalte ich die Meldung /dev/bpf0: device not configured? Der Berkeley-Paket-Filter (&man.bpf.4;) muss in den Kernel eingebunden werden, bevor er von einem Programme aus genutzt werden kann. Fügen Sie folgendes zu Ihrer Kernelkonfigurationsdatei hinzu und erstellen Sie einen neuen Kernel: device bpf # Berkeley Packet Filter Habe ich, analog zum smbmount von &linux;, eine Möglichkeit, auf ein freigegebenes Laufwerk einer &windows;-Maschine in meinem Netzwerk zuzugreifen? Benutzen Sie die Kernel-Erweiterungen und Benutzerprogramme aus dem Programmpaket SMBFS. Das Paket und weitergehende Informationen sind unter &man.mount.smbfs.8; im Basissystem verfügbar. Was bedeutet die Meldung Limiting icmp/open port/closed port response in meinen Logfiles? Mit dieser Meldung teilt Ihnen der Kernel mit, dass irgend jemand versucht, ihn zur Generierung von zu vielen ICMP oder TCP reset (RST) Antworten zu provozieren. ICMP Antworten sind oft das Ergebnis von Verbindungsversuchen zu unbenutzten UDP Ports. TCP Resets werden generiert, wenn jemand versucht, eine Verbindung zu einem ungenutzten TCP Port aufzubauen. Die Meldungen können unter anderem durch die folgenden Ereignisse ausgelöst werden: Denial of Service (DoS) Angriffe mit der Brechstange (und nicht durch Angriffe mit einzelnen Paketen, die gezielt eine Schwachstelle des Systems ausnutzen sollen). Port Scans, bei denen versucht wird, Verbindungen zu einer großen Anzahl von Ports (und nicht nur einigen bekannten Ports) herzustellen. Die erste Zahl gibt an, wie viele Pakete vom Kernel ohne das Limit versendet worden wären; die zweite Zahl gibt das Limit an. Sie können das Limit mit Hilfe der sysctl-Variable net.inet.icmp.icmplim einstellen. Im Beispiel wird das Limit auf 300 Pakete pro Sekunde gesetzt: &prompt.root; sysctl -w net.inet.icmp.icmplim=300 Wenn Sie zwar die Begrenzung benutzen möchten, aber die Meldungen nicht in Ihren Logfiles sehen möchten, können Sie die Meldungen mit der sysctl-Variable net.inet.icmp.icmplim_output abschalten: &prompt.root; sysctl -w net.inet.icmp.icmplim_output=0 Falls Sie die Begrenzung ganz abschalten wollen, können Sie die Sysctl-Variable net.inet.icmp.icmplim auf 0. Wir raten Ihnen aus den oben genannten Gründen dringend von diesem Schritt ab. Was bedeutet die Meldung arp: unknown hardware address format? Ein Gerät im lokalen Ethernet verwendet eine MAC-Adresse in einem Format, das &os; nicht kennt. Der wahrscheinlichste Grund ist, dass jemand Experimente mit einer Ethernet-Karte anstellt. Die Meldung tritt sehr häufig in Netzwerken mit Cable Modems auf. Die Meldung ist harmlos und sollte die Performance Ihres Systems nicht negativ beeinflussen. Warum sehe ich ständig Nachrichten wie: 192.168.0.10 is on fxp1 but got reply from 00:15:17:67:cf:82 on rl0 und wie stelle ich das ab? Weil ein Paket unerwartet von ausserhalb des Netzwerks empfangen wurde. Um die Nachrichten abzustellen, ändern Sie net.link.ether.inet.log_arp_wrong_iface auf 0. Ich habe gerade CVSup installiert, aber das Programm bricht mit Fehlermeldungen ab. Was ist da schief gelaufen? Schauen Sie bitte zuerst nach, ob Sie eine Fehlermeldung wie die unten gezeigte erhalten. /usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found Solche Fehlermeldungen erhalten Sie, wenn Sie den net/cvsup Port auf einer Maschine installieren, die kein &xorg;-System besitzt. Wenn Sie das GUI von CVSup benutzen wollen, müssen Sie &xorg; installieren. Wenn Sie CVSup nur auf der Kommandozeile benutzen wollen, entfernen Sie bitte den Port, den Sie gerade installiert haben. Installieren Sie stattdessen den Port net/cvsup-without-gui oder den net/csup Port. Falls Sie ein aktuelles &os; Release besitzen, können Sie &man.csup.1; verwenden. Genauere Informationen finden Sie im CVSup Abschnitt des Handbuchs.
Sicherheit Was ist ein Sandkasten (sandbox)? Sandkasten (sandbox) ist ein Ausdruck aus dem Bereich Sicherheit. Er hat zwei Bedeutungen: Ein Programm, das innerhalb virtueller Wände ausgeführt wird. Wenn ein Angreifer über eine Sicherheitslücke in diesen Programm einbricht, verhindern diese Wände ein tieferes Vordringen in das System. Man sagt: Der Prozess kann innerhalb der Wände spielen, das heißt nichts, was der Prozess in Bezug auf die Ausführung von Code tut, kann die Wände durchbrechen. Es ist also keine detaillierte Revision des Codes erforderlich, um gewisse Aussagen über seine Sicherheit machen zu können. Die Wände könnten z.B. eine Benutzerkennung sein. Dies ist die Definition, die in den Hilfeseiten &man.security.7; und &man.named.8; benutzt wird. Nehmen Sie zum Beispiel den Dienst ntalk (siehe auch &man.inetd.8;). Dieser Dienst ist früher mit der Benutzerkennung root gelaufen; nun läuft er mit der Benutzerkennung tty. Der Benutzer tty ist ein Sandkasten, der dazu gedacht ist, es jemandem, der über ntalk erfolgreich in das System eingebrochen ist, schwer zu machen, über diese Benutzerkennung hinaus vorzudringen. Ein Prozess, der sich innerhalb einer simulierten Maschine befindet. Dies ist etwas fortgeschrittener; grundsätzlich bedeutet es, dass jemand, der in der Lage ist, in einen Prozess einzudringen, annehmen könnte, er könnte weiter in die Maschine eindringen, tatsächlich aber nur in eine Simulation der Maschine einbricht und keine echten Daten verändert. Der gängigste Weg, dies zu erreichen, ist, in einem Unterverzeichnis eine simulierte Umgebung zu erstellen und den Prozess in diesem Verzeichnis mit chroot auszuführen (für diesen Prozess ist / dieses Verzeichnis und nicht das echte / des Systems). Eine weitere gebräuchliche Anwendung ist, ein untergeordnetes Dateisystem nur mit Leserechten zu mounten, und dann darüber eine Dateisystemebene zu erstellen, die einem Prozess einen scheinbar schreibberechtigten Blick in das Dateisystem gibt. Der Prozess mag glauben, dass er in der Lage ist, diese Dateien zu verändern, aber nur der Prozess sieht diesen Effekt - andere Prozess im System natürlich nicht. Es wird versucht, diese Art von Sandkasten so transparent zu gestalten, dass der Benutzer (oder Hacker) nicht merkt, dass er sich in ihm befindet. Ein &unix; System implementiert zwei Arten von Sandkästen - eine auf Prozessebene und die andere auf der Ebene der Benutzerkennung. Jeder Prozess auf einem &unix; System ist komplett von allen anderen Prozessen abgeschirmt. Ein Prozess kann den Adressraum eines anderen Prozesses nicht modifizieren. Das ist anders als bei &windows;, wo ein Prozess leicht den Adressraum eines anderen überschreiben kann, was zu einem Absturz führt. Ein Prozess gehört einer bestimmten Benutzerkennung. Falls die Benutzerkennung nicht die von root ist, dient sie dazu, den Prozess von Prozessen anderer Benutzer abzuschirmen. Die Benutzerkennung wird außerdem dazu genutzt, Daten auf der Festplatte abzuschirmen. Was sind die Sicherheitsstufen? Die Sicherheitsstufen sind ein Sicherheitsmechanismus, der im Kernel angesiedelt ist. Wenn die Sicherheitsstufe einen positiven Wert hat, verhindert der Kernel die Ausführung bestimmter Tätigkeiten; nicht einmal der Super-User (also root) darf sie durchführen. Zurzeit können über die Sicherheitsstufen unter anderem die folgenden Tätigkeiten geblockt werden: Zurücksetzen bestimmter Dateiattribute, wie zum Beispiel schg (das "system immutable" Attribut). Schreibender Zugriff auf die Speicherbereiche des Kernels mittels /dev/mem und /dev/kmem. Laden von Kernel-Modulen. Änderungen an den Firewall-Regeln. Um die eingestellte Sicherheitsstufe eines aktiven Systems abzufragen, reicht das folgende einfache Kommando: &prompt.root; sysctl kern.securelevel Die Ausgaben wird den Namen der &man.sysctl.8;-Variablen (in diesem Fall kern.securelevel) und eine Zahl enthalten. Die Zahl ist der aktuelle Wert der Sicherheitsstufe. Wenn die Zahl positiv (größer als Null) ist, sind zumindest einige der Schutzmaßnahmen aktiviert. Sie können die Sicherheitsstufe eines laufenden Systems nicht verringern, da dies den Mechanismus wertlos machen würden. Wenn Sie eine Tätigkeit ausführen müssen, bei der die Sicherheitsstufe nicht-positiv sein muss (z.B. ein installworld oder eine Änderung der Systemzeit), dann müssen Sie die entsprechende Einstellung in /etc/rc.conf ändern (suchen Sie nach den Variablen kern_securelevel und kern_securelevel_enable) und das System rebooten. Weitere Informationen über die Sicherheitsstufen und genaue Informationen, was die Einstellungen bewirken, können Sie der Online-Hilfe &man.init.8; entnehmen. Die Sicherheitsstufen sind kein magischer Zauberstab, der alle Ihre Problem löst; es gibt viele bekannte Probleme. Und in der Mehrzahl der Fälle vermitteln sie ein falsches Gefühl der Sicherheit. Eines der größten Probleme ist, dass alle für den Start des Systems benötigten Dateien geschützt sein müssen, damit die Sicherheitsstufe effektiv sein können. Wenn es ein Angreifer schafft, seine eigenen Programme ausführen zu lassen, bevor die Sicherheitsstufe gesetzt wird (was leider erst gegen Ende des Startvorgangs erfolgen kann, da viele der notwendigen Tätigkeiten für den Systemstart nicht mit einer gesetzten Sicherheitsstufe möglich wären), werden die Schutzmechanismen ausgehebelt. Es ist zwar nicht technisch unmöglich, alle beim Systemstart genutzten Dateien zu schützen; allerdings würde in einem so geschützten System die Administration zu einem Alptraum, da man das System neu starten oder in den Single-User-Modus bringen müsste, um eine Konfigurationsdatei ändern zu können. Dieses und andere Probleme werden häufig auf den Mailinglisten diskutiert, speziell auf auf der Mailingliste &a.security;. Das verfügbare Archiv enthält ausgiebige Diskussionen. Einige Benutzer sind guter Hoffnung, dass das System der Sicherheitsstufen bald durch ein besser konfigurierbares System ersetzt wird, aber es gibt noch keine definitiven Aussagen. Fühlen Sie sich gewarnt. Wieso wartet BIND (named) auf hohen Ports auf Anfragen? &os; benutzt eine Version von BIND, die einen Port mit einer hohen, zufälligen Nummer für den Versand von Anfragen nutzt. Aktuelle Versionen wählen einen neuen, zufälligen UDP-Port für jeden Query. Das kann für manche Netzwerkkonfigurationen Probleme verursachen, besonders wenn eine Firewall eingehende UDP-Pakete auf bestimmten Ports blockiert. Wenn Sie durch eine solche Firewall wollen, können Sie die avoid-v4-udp-ports und avoid-v6-udp-ports Optionen ausprobieren, um ein zufälliges Auswählen von Portnummern innerhalb eines blockierten Bereiches zu verhindern. Wenn eine Portnummer (wie 53) über die Optionen query-source oder query-source-v6 in /etc/namedb/named.conf spezifiziert ist, wird zufällige Portauswahl nicht verwendet. Es wird dringend empfohlen, dass diese Optionen nicht für die Spezifikation von festen Portnummern verwendet wird. Ach übrigens, herzlichen Glückwunsch. Es ist eine sehr gute Angewohnheit, die Ausgaben von &man.sockstat.1; durchzusehen und auf merkwürdige Dinge zu achten. Wieso wartet der sendmail-Dienst neuerdings sowohl auf Port 587 als auch auf dem Standard-Port 25 auf Anfragen? Aktuelle sendmail-Versionen unterstützen eine neue Technik zur Einlieferung von Mails, die Port 587 nutzt. Diese Technik wird zwar noch nicht oft angewendet, erfreut sich aber ständig steigender Popularität. Woher kommt dieser Benutzer toor mit UID 0? Ist mein System gehackt worden? Keine Panik. toor ist ein alternativer Account für den Super-User (wenn man root rückwärts schreibt, erhält man toor). Früher wurde er nur erzeugt, wenn die Shell &man.bash.1; installiert wurde, heute wird er auf jeden Fall erzeugt. Dieser Account ist für die Verwendung mit einer alternativen Shell vorgesehen; damit ist es nicht mehr erforderlich, die Shell von root zu ändern. Dies ist wichtig, wenn eine Shell verwendet wird, die nicht zum Lieferumfang von &os; gehört, zum Beispiel aus einem Port oder einem Package. Diese Shells werden in der Regel in /usr/local/bin installiert und dieses Verzeichnis liegt standardmäßig auf einem anderem Filesystem. Wenn die Shell von root in /usr/local/bin liegt und /usr (oder das Filesystem, auf dem /usr/local/bin liegt) nicht gemountet werden kann, kann sich root nicht mehr einloggen, um das Problem zu beheben. Es ist allerdings möglich, das System zu rebooten und das Problem im Single-User-Modus zu lösen, da man hier gefragt wird, welche Shell benutzt werden soll. Einige Anwender benutzen toor mit einer alternativen Shell für die tägliche Arbeit und benutzen root (mit der Standard-Shell) für den Single-User-Modus und für Notfälle. Standardmäßig kann man sich nicht als toor anmelden, da der Account kein gültiges Passwort hat; Sie müssen sich also als root anmelden und ein Passwort für toor setzen, wenn Sie diesen Account benutzen wollen. Warum funktioniert suidperl nicht richtig? Aus Sicherheitsgründen wird suidperl standardmäßig nicht installiert. Wenn Sie wollen, dass suidperl auch beim Update via Sourcecode das SUID-Bit erhält, müssen Sie in /etc/make.conf die Zeile ENABLE_SUIDPERL=true einfügen, bevor Sie perl bauen. PPP Ich bekomme &man.ppp.8; nicht zum Laufen. Was mache ich falsch? Sie sollten zuerst &man.ppp.8; (die Manualpage zu ppp) und den Abschnitt zu PPP im Handbuch lesen. Aktivieren Sie das Logging mit folgendem Befehl: set log Phase Chat Connect Carrier lcp ipcp ccp command Dieser Befehl kann an der Eingabeaufforderung von &man.ppp.8; eingegeben oder in die Konfigurationsdatei /etc/ppp/ppp.conf eingetragen werden (der beste Ort hierfür ist der Anfang des Abschnitts default. Stellen Sie sicher, dass die Datei /etc/syslog.conf die folgenden Zeilen enthält und die Datei /var/log/ppp.log existiert: !ppp *.* /var/log/ppp.log Sie können nun über die Logfiles eine Menge darüber herausfinden, was geschieht. Es macht nichts, wenn die Einträge in den Logfiles Ihnen gar nichts sagen. Wenn Sie jemandem um Hilfe bitten müssen, könnten sie für ihn von Nutzen sein. Warum hängt sich ppp auf, wenn ich es benutze? Das liegt meistens daran, dass Ihr Rechnername nicht aufgelöst werden kann. Um dieses Problem zu lösen, müssen Sie sicherstellen, dass die Datei /etc/hosts von Ihrem Resolver zuerst genutzt wird. Dazu muss in der Datei /etc/host.conf der Eintrag hosts an die erste Stelle gesetzt werden. Erstellen Sie dann einfach für Ihren lokalen Rechner einen Eintrag in der Datei /etc/hosts. Falls Sie kein lokales Netzwerk besitzen, ändern Sie die localhost-Zeile: 127.0.0.1 foo.example.com foo localhost Andernfalls fügen Sie einfach einen weiteren Eintrag für Ihren lokalen Rechner hinzu. Weitere Details finden Sie in den betreffenden Manualpages. Wenn Sie fertig sind sollten Sie ping -c1 `hostname` erfolgreich ausführen können. Warum wählt &man.ppp.8; im -auto-Modus nicht? Überprüfen Sie zunächst, ob Sie einen Standard-Gateway eingestellt haben. Wenn Sie netstat -rn ausführen, sollten Sie zwei Einträge ähnlich den folgenden sehen: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 Hier wird angenommen, dass Sie die Adressen aus dem Handbuch, der Manualpage oder aus der Datei ppp.conf.sample benutzt haben. Falls Sie keine Standardroute haben, kann es daran liegen, dass Sie vergessen haben, die Zeile HISADDR in der Datei ppp.conf hinzuzufügen. Ein weiterer Grund dafür, dass die Zeile für die Standardroute fehlt, könnte der sein, dass Sie fälschlicherweise eine Standardroute in der Datei /etc/rc.conf eingetragen und die folgende Zeile in ppp.conf ausgelassen haben: delete ALL Lesen Sie in diesem Fall den Abschnitt Abschließende Systemkonfiguration des Handbuchs. Was bedeutet No route to host? Dieser Fehler beruht für gewöhnlich auf einem fehlenden Abschnitt in Ihrer Datei /etc/ppp/ppp.linkup: MYADDR: delete ALL add 0 0 HISADDR Er ist nur notwendig, wenn Sie eine dynamische IP-Adresse besitzen oder die Adresse Ihres Gateways nicht kennen. Wenn Sie den interaktiven Modus benutzen, können Sie folgendes eingeben, nachdem Sie in den packet mode gelangt sind (den Paket Modus erkennen Sie an PPP im Prompt): delete ALL add 0 0 HISADDR Weitere Details finden Sie im Abschnitt PPP und Dynamische IP-Adressen des Handbuchs. Wieso werden meine Verbindungen nach ca. drei Minuten beendet? Der Standardtimeout für &man.ppp.8; beträgt drei Minuten. Er kann durch die folgende Zeile eingestellt werden, wobei NNN die Inaktivität in Sekunden angibt, bevor die Verbindung geschlossen wird: set timeout NNN Falls NNN Null ist, wird die Verbindung niemals aufgrund eines Timeouts geschlossen. Es ist möglich, diesen Befehl in die Datei ppp.conf einzubinden, oder ihn an der Eingabeaufforderung im interaktiven Modus einzugeben. Durch eine Verbindung zum Server-Socket von ppp über &man.telnet.1; oder &man.pppctl.8; ist es auch möglich, den Timeout bei aktiver Verbindung anzupassen. Weitere Details finden Sie in der Manualpage &man.ppp.8;. Wieso bricht meine Verbindung bei hoher Auslastung ab? Falls Sie Link-Quality-Reporting (LQR) konfiguriert haben, ist es möglich, dass zu viele LQR-Pakete zwischen Ihrer Maschine und dem verbundenen Rechner verloren gehen. Das &man.ppp.8;-Programm folgert daraus, dass die Verbindung nicht in Ordnung ist und schließt sie. Vor &os; Version 2.2.5 war LQR standardmäßig aktiviert; nun ist es standardmäßig deaktiviert. Es kann durch die folgende Zeile deaktiviert werden: disable lqr Warum brechen meine Verbindungen nach unbestimmter Zeit zusammen? Wenn die Qualität Ihrer Telefonleitung zu schlecht oder bei Ihrem Anschluss die Option (Telekomdeutsch: das Leistungsmerkmal) Anklopfen aktiviert ist, kann es manchmal vorkommen, dass Ihr Modem auflegt, weil es (fälschlicherweise) annimmt, dass es das Trägersignal verloren hat. Bei den meisten Modems gibt es eine Einstellmöglichkeit, um anzugeben, wie tolerant es gegenüber vorübergehenden Verlusten des Trägersignals sein soll. Bei einem &usrobotics; &sportster; wird dies zum Beispiel im Register S10 in Zehntelsekunden angegeben. Um Ihr Modem toleranter zu machen, können Sie zu Ihrem Wählbefehl die folgende Sende-Empfangs-Sequenz hinzufügen: set dial "...... ATS10=10 OK ......" Weitere Information sollten Sie dem Handbuch Ihres Modems entnehmen können. Warum hängen meine Verbindung nach einer unbestimmten Zeit? Viele Leute machen Erfahrungen mit hängenden Verbindungen ohne erkennbaren Grund. Als erstes muss festgestellt werden, welche Seite der Verbindung hängt. Wenn Sie ein externes Modem benutzen, können Sie einfach versuchen, &man.ping.8; zu benutzen, um zu sehen, ob die TD-Anzeige aufleuchtet, wenn Sie Daten übertragen. Falls sie aufleuchtet (und die RD-Anzeige nicht), liegt das Problem am anderen Ende. Falls TD nicht aufleuchtet, handelt es sich um ein lokales Problem. Bei einem internen Modem müssen Sie den Befehl set server in Ihrer Datei ppp.conf benutzen. Stellen Sie über &man.pppctl.8; eine Verbindung zu &man.ppp.8; her, wenn die Verbindung hängt. Falls Ihre Netzwerkverbindung plötzlich wieder funktioniert (ppp wurde durch die Aktivität auf dem Diagnose-Socket wiederbelebt) oder Sie keine Verbindung bekommen (vorausgesetzt, der Befehl set socket wurde beim Start erfolgreich ausgeführt), handelt es sich um ein lokales Problem. Falls Sie eine Verbindung bekommen und die externe Verbindung weiterhin hängt, aktivieren Sie lokales asynchrones Logging mit set log local async und benutzen Sie &man.ping.8; von einem anderen Fenster oder Bildschirm aus, um die externe Verbindung zu benutzen. Das asynchrone Logging zeigt Ihnen, welche Daten über die Verbindung gesendet und empfangen werden. Falls Daten hinausgehen, aber nicht zurückkommen, handelt es sich um ein externes Problem. Wenn Sie festgestellt haben, ob es sich um ein lokales oder um ein externes Problem handelt, haben Sie zwei Möglichkeiten: Wenn es ein externes Problem ist, lesen Sie bitte bei weiter. Handelt es sich um ein lokales Problem, lesen Sie bitte . Was kann ich machen, wenn die Gegenstelle nicht antwortet? Hier können Sie wenig tun. Die meisten ISPs werden ablehnen, Ihnen zu helfen, wenn Sie kein Betriebssystem von µsoft; benutzen. Sie können enable lqr in Ihrer Datei ppp.conf angeben, wodurch &man.ppp.8; ermöglicht wird, ein externes Versagen zu erkennen und aufzulegen, aber diese Erkennung ist relativ langsam und deshalb nicht besonders nützlich. Evtl. sagen Sie Ihrem ISP nicht, dass Sie user-PPP benutzen. Versuchen Sie zunächst, jegliche Datenkompression auszuschalten, indem Sie folgendes zu Ihrer Konfiguration hinzufügen: disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Stellen Sie nun wieder eine Verbindung her, um festzustellen, ob sich etwas geändert hat. Falls es nun besser läuft oder falls das Problem vollständig behoben ist, versuchen Sie durch schrittweises Ändern der Einstellungen festzustellen, welche Einstellung den Unterschied bewirkt. Hierdurch erhalten Sie schlüssige Fakten für ein Gespräch mit Ihrem ISP (andererseits wird hierdurch offensichtlich, dass Sie kein µsoft;-Produkt benutzen). Aktivieren Sie asynchrones Logging und warten Sie, bis die Verbindung wieder hängt, bevor Sie sich an Ihren ISP wenden. Hierzu kann einiges an Plattenplatz nötig sein. Die Daten, die als letztes von dem Port gelesen wurden, könnten von Interesse sein. Für gewöhnlich handelt es sich um ASCII-Text, der sogar den Fehler beschreiben kann (Memory fault, Core dumped). Falls Ihr ISP hilfsbereit ist, sollte er in der Lage sein, an seinem Ende das Logging zu aktivieren und wenn das nächste Mal die Verbindung abbricht, könnte er Ihnen mitteilen, worin das Problem auf seiner Seite besteht. Gerne können Sie Details auch an &a.brian; schicken, oder Ihren ISP bitten, sich direkt an ihn zu wenden. Was kann ich tun, wenn sich &man.ppp.8; aufhängt? In diesem Fall erstellen Sie am besten &man.ppp.8; mit Debugging-Informationen neu und benutzen dann &man.gdb.1;, um von dem hängenden ppp Prozess eine Aufzeichnung des Stacks zu erstellen. Um die ppp Anwendung mit Debugging-Informationen zu übersetzen, geben Sie folgendes ein: &prompt.root; cd /usr/src/usr.sbin/ppp&prompt.root; env DEBUG_FLAGS='-g' make clean &prompt.root; env DEBUG_FLAGS='-g' make install Anschliessend sollten Sie ppp neu starten und darauf warten, dass es wieder hängt. Wenn die Debug-Version von ppp hängt, starten Sie gdb für den steckengebliebenen Prozess, indem Sie folgendes eingeben: &prompt.root; gdb ppp `pgrep ppp` An der Eingabeaufforderung von gdb können Sie die Befehle bt oder where benutzen, um eine Aufzeichnung des Stacks zu erhalten. Speichern Sie die Ausgabe der gdb-Sitzung und trennen Sie den laufenden Prozess über den quit Befehl von gdb. Schicken Sie zum Schluss das Log der gdb-Sitzung an &a.brian;. Warum passiert nach der Nachricht Login OK! nichts? Bei &os;-Versionen vor 2.2.5 wartete &man.ppp.8; darauf, dass der Partner das Line Control Protocol (LCP) initiiert. Viele ISPs starten nicht mit der Initiierung, sondern erwarten dies vom Client. Benutzen Sie die folgende Zeile, um &man.ppp.8; zu veranlassen, LCP zu initiieren: set openmode active Für gewöhnlich schadet es nicht, wenn beide Seiten versuchen, Verhandlungen einzuleiten. Deshalb ist openmode nun standardmäßig aktiv. Im nächsten Abschnitt wird allerdings erklärt, in welchen Fällen es doch schadet. Ich sehe ständig Fehlermeldungen über gleiche Magic Numbers Was heißt das? Nach dem Aufbau einer Verbindung kann es sein, dass Sie in der Logdatei gelegentlich Meldungen mit dem Hinweis magic is the same sehen. Manchmal sind diese Meldungen harmlos und manchmal bricht die eine oder andere Seite die Verbindung ab. Die meisten Implementationen von PPP können dieses Problem nicht handhaben und Sie werden wiederholte Konfigurationsanforderungen und -bestätigungen in der Logdatei finden, bis &man.ppp.8; schließlich aufgibt und die Verbindung beendet. Dies geschieht normalerweise auf Servern mit langsamen Festplatten, bei denen ein getty auf dem Port ausgeführt und &man.ppp.8; nach dem Einloggen von einem Login-Skript oder einem Programm aus gestartet wird. Es wurde auch schon berichtet, dass dies bei der Benutzung von slirp regelmäßig auftritt. Der Grund hierfür ist, dass das &man.ppp.8; auf der Client-Seite in der Zeit, die benötigt wird, &man.getty.8; zu beenden und &man.ppp.8; zu starten, bereits beginnt, Line Control Protocol (LCP) Pakete zu senden. Da ECHO auf dem Serverport weiterhin eingeschaltet ist, werden diese Pakete zum &man.ppp.8; auf der Client-Seite reflektiert. Ein Teil der LCP-Verhandlungen ist die Einrichtung einer Magic Number für jede Seite der Verbindung, damit Echos erkannt werden können. Das Protokoll besagt, dass, wenn der Partner versucht, die gleiche Magic Number auszuhandeln, ein NAK zurückgesendet und eine neue "Magic Number" gewählt werden soll. Während der Server das ECHO eingeschaltet hat, sendet der Client LCP Pakete, sieht die gleiche Magic Number im reflektierten Paket und erzeugt ein NAK. Er sieht auch das reflektierte NAK (was bedeutet, dass &man.ppp.8; seine "Magic Number" ändern muss). Hierdurch wird eine Vielzahl von Änderungen der Magic Number hervorgerufen, die sich allesamt im tty-Puffer des Servers ansammeln. Sobald &man.ppp.8; auf dem Server startet, wird es mit Änderungen der Magic Number überflutet und entscheidet, dass es sich zur Genüge mit den LCP-Verhandlungen beschäftigt hat und gibt auf. Und während sich der Client noch darüber freut, dass er keine weiteren Reflexionen sieht, wird ihm gemeldet, dass der Server auflegt. Dies kann verhindert werden, indem dem Partner durch die folgende Zeile in der Datei ppp.conf erlaubt wird, mit der Verhandlung zu beginnen: set openmode passive Hierdurch wird &man.ppp.8; mitgeteilt, darauf zu warten, dass der Server mit den LCP-Verhandlungen beginnt. Einige Server starten jedoch nie mit der Verhandlungen; falls dies der Fall ist, können Sie folgendes tun: set openmode active 3 Hierdurch bleibt &man.ppp.8; für drei Sekunden passiv und fängt dann erst an, LCP-Anforderungen zu senden. Falls der Partner während dieser Zeit beginnt, Anforderungen zu senden, wird &man.ppp.8; direkt antworten und nicht erst, nachdem die drei Sekunden abgelaufen sind. Die LCP-Verhandlungen dauern an, bis die Verbindung geschlossen wird. Was mache ich falsch? Es gibt eine Fehlfunktion in der Implementierung von &man.ppp.8;, die darin besteht, dass LCP-, CCP- & IPCP-Antworten nicht mit den ursprünglichen Anforderungen assoziiert werden. Für den Fall, dass eine Implementation von PPP mehr als sechs Sekunden langsamer ist, als die andere Seite, resultiert das darin, dass die andere Seite zwei weitere LCP-Konfigurationsanforderungen sendet, was fatale Auswirkungen hat. Stellen Sie sich vor, wir hätten es mit zwei Implementierungen A und B zu tun. A beginnt unmittelbar nach der Verbindung, LCP-Anforderungen zu senden und B benötigt sieben Sekunden, zu starten. Wenn B startet, hat A bereits drei LCP-Anforderungen gesendet. Wir nehmen an, dass ECHO ausgeschaltet ist; andernfalls würden wir Probleme mit der "Magic Number" beobachten, wie bereits im vorherigen Abschnitt beschrieben. B sendet eine Anforderung und anschließend eine Bestätigung der ersten Anforderung von A. Dies führt dazu, dass A in den Zustand OPENED übergeht und eine Bestätigung (die erste) zurück an B sendet. In der Zwischenzeit sendet B zwei weitere Bestätigungen als Antwort auf die zusätzlichen Anforderungen, die von A gesendet worden sind, bevor B gestartet ist. B empfängt dann die erste Bestätigung von A und geht in den Zustand OPENED über. A empfängt die zweite Bestätigung von B, geht zurück in den Zustand REQ-SENT und sendet eine weitere (vierte) Anforderung entsprechend dem RFC. A empfängt dann die dritte Bestätigung und geht in den Zustand OPENED über. In der Zwischenzeit empfängt B die vierte Anforderung von A, wechselt in den Zustand ACK-SENT und sendet eine weitere (zweite) Anforderung und (vierte) Bestätigung entsprechend dem RFC. A erhält die Anforderung, geht in den Zustand REQ-SENT über, sendet eine weitere Anforderung, erhält unverzüglich die nächste Bestätigung und geht in OPENED über. Das geht so weiter, bis eine Seite erkennt, dass man zu keinem Ergebnis gelangt und aufgibt. Am besten verhindert man solche Situationen, indem man eine Seite als passiv konfiguriert, also dafür sorgt, dass eine Seite darauf wartet, dass die andere mit den Verhandlungen beginnt. Das kann durch den folgenden Befehl geschehen: set openmode passive Diese Option sollten Sie mit Vorsicht genießen. Folgenden Befehl sollten Sie benutzen, um die Wartezeit auf den Beginn der Verhandlungen des Partners von &man.ppp.8; zu begrenzen: set stopped N Alternativ kann der folgende Befehl (wobei N die Wartezeit in Sekunden vor Beginn der Verhandlungen angibt) benutzt werden: set openmode active N Weitere Details finden Sie in den Manualpages. Warum reagiert &man.ppp.8; nicht mehr, wenn ich es mit shell verlassen habe? Wenn Sie den Befehl shell oder ! benutzen, führt &man.ppp.8; eine Shell aus (falls Sie Argumente übergeben haben, führt &man.ppp.8; diese Argumente aus). Das Programm ppp wartet auf die Beendigung des Befehls, bevor es seine Arbeit fortsetzt. Falls Sie versuchen, die PPP-Verbindung während der Programmausführung zu benutzen, wird es so aussehen, als wäre die Verbindung eingefroren. Das liegt daran, dass &man.ppp.8; auf die Beendigung des Befehls wartet. Falls Sie solche Befehle verwenden möchten, benutzen Sie stattdessen den Befehl !bg. Hierdurch wird der angegebene Befehl im Hintergrund ausgeführt und &man.ppp.8; kann fortfahren, die Verbindung zu bedienen. Warum wird &man.ppp.8; niemals beendet, wenn ich es über ein Nullmodem-Kabel benutze? Es gibt keine Möglichkeit für &man.ppp.8;, automatisch festzustellen, ob eine direkte Verbindung beendet worden ist. Das liegt an den Leitungen, die bei einem seriellen Nullmodem-Kabel benutzt werden. Wenn Sie diese Art der Verbindung verwenden, sollte LQR immer mit der folgenden Zeile aktiviert werden: enable lqr LQR wird standardmäßig akzeptiert, wenn es vom Partner ausgehandelt wird. Warum wählt &man.ppp.8; im Modus ohne Grund? Falls &man.ppp.8; unerwarteterweise wählt, müssen Sie den Grund herausfinden und Wählfilter (dfilters) einsetzen, um dies zu verhindern. Benutzen Sie die folgende Zeile, um den Grund herauszufinden: set log +tcp/ip Dadurch wird jeglicher Verkehr über die Verbindung geloggt. Wenn das nächste mal unerwartet eine Verbindung hergestellt wird, werden Sie den Grund zusammen mit einer hilfreichen Zeitangabe in der Logdatei finden. Sie können nun das Wählen aufgrund dieser Bedingungen verhindern. Normalerweise wird diese Art von Problemen durch Anfragen an den DNS verursacht. Um zu verhindern, dass DNS-Anfragen den Aufbau der Verbindung hervorrufen (das verhindert nicht, dass Pakete über eine bestehende Verbindung gesendet werden), benutzen Sie die folgenden Zeilen: set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 Dies ist nicht immer brauchbar, weil es effektiv Ihre Fähigkeit, auf Anforderung wählen zu können einschränkt - die meisten Programme müssen eine DNS-Anfrage durchführen, bevor Sie andere, das Netzwerk betreffenden Dinge tun können. Im Fall von DNS sollten Sie versuchen, herauszufinden, welches Programm tatsächlich versucht, einen Hostnamen aufzulösen. Sehr oft handelt es sich hier um &man.sendmail.8;. Sie sollten sicherstellen, dass Sie sendmail in der Konfigurationsdatei sagen, dass keine DNS-Anfragen durchführen soll. Weitere Details enthält der Abschnitt E-Mail über Einwahl-Verbindungen des Handbuchs. Sie könnten z.B. die folgende Zeile in Ihre .mc-Datei einfügen: define(`confDELIVERY_MODE', `d')dnl Das veranlasst sendmail dazu, alles in eine Warteschlange einzureihen, bis die Warteschlange verarbeitet wird (normalerweise wird sendmail mit aufgerufen, was besagt, dass die Warteschlange alle 30 Minuten abgearbeitet wird) oder, bis ein sendmail ausgeführt wird (z.B. aus Ihrer Datei ppp.linkup heraus). Was bedeuten diese CCP-Fehler? Ich sehe ständig folgende Fehler in meiner Logdatei: CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) Das liegt daran, dass &man.ppp.8; versucht, die Komprimierung Predictor1 auszuhandeln und der Partner über keinerlei Komprimierung verhandeln will. Die Meldungen sind harmlos, aber wenn Sie sie beseitigen möchten, können Sie die Komprimierung Predictor1 auch lokal ausschalten: disable pred1 Warum loggt ppp die Geschwindigkeit meiner Verbindung nicht? Um alle Zeilen Ihrer Modemkonversation mitzuloggen, müssen Sie folgendes einstellen: set log +connect Dies veranlasst &man.ppp.8; dazu, alles bis zur letzten angeforderten expect-Zeile mitzuloggen. Falls Sie die Geschwindigkeit Ihrer Verbindung erfahren möchten und PAP oder CHAP (und deshalb nach dem CONNECT im Wählskript nichts mehr zu chatten haben - kein set login-Skript), müssen Sie sicherstellen, dass Sie &man.ppp.8; anweisen, die gesamte CONNECT-Zeile zu erwarten, etwa so: set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" Hier bekommen wir unser CONNECT, senden nichts, erwarten dann einen Line-Feed, der &man.ppp.8; zwingt, die gesamte CONNECT-Antwort zu lesen. Warum ignoriert &man.ppp.8; das Zeichen \ in meinem Chat-Skript? Das Programm ppp analysiert jede Zeile in Ihrer Konfigurationsdatei, damit es Zeichenketten wie z.B. set phone "123 456 789" korrekt interpretieren kann (und erkennen, dass es sich bei der Nummer tatsächlich nur um ein Argument handelt). Um das Zeichen " anzugeben, müssen Sie ihm einen Backslash (\) voranstellen. Wenn der Chat-Interpreter jedes Argument analysiert, reinterpretiert er die Argumente, um irgendwelche speziellen Escape-Sequenzen wie z.B. \P oder \T (sehen Sie in die Manualpage) zu finden. Das Ergebnis dieser Doppelanalyse ist, dass Sie daran denken müssen, die richtige Anzahl an Escape-Zeichen zu verwenden. Falls Sie tatsächlich das Zeichen \ z.B. zu Ihrem Modem senden möchten, brauchen Sie etwas ähnliches, wie: set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" Woraus sich folgende Zeichen ergeben: ATZ OK AT\X OK Oder: set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" Was folgende Zeichen ergibt: ATZ OK ATDT1234567 Warum gibt es die Datei ppp.core nicht, wenn &man.ppp.8; einen Segmentation fault erzeugt hat? Weder ppp noch andere Programme sollten Core-Dumps erzeugen. Da &man.ppp.8; mit der effektiven Benutzerkennung 0 ausgeführt wird, wird das Betriebssystem das Coreimage von &man.ppp.8; nicht auf die Festplatte schreiben, bevor es &man.ppp.8; beendet hat. Falls &man.ppp.8; jedoch tatsächlich aufgrund einer Speicherverletzung abbricht und Sie die aktuellste Version (siehe Anfang dieses Kapitels) benutzen, dann sollten Sie die Systemquellen installieren und folgendes tun: &prompt.root; cd /usr/src/usr.sbin/ppp &prompt.root; echo STRIP= >> /etc/make.conf &prompt.root; echo CFLAGS+= >> /etc/make.conf &prompt.root; make install clean Nun ist die installierte Version von &man.ppp.8; mit einem Debugger ausführbar. Sie können &man.ppp.8; nun nur noch als root ausführen, da alle vorherigen Zugriffsrechte aufgehoben worden sind. Achten Sie darauf, in welchem Verzeichnis Sie sich gerade befinden, wenn Sie &man.ppp.8; starten. Wenn nun wieder eine Speicherverletzung auftreten sollte, wird &man.ppp.8; einen Speicherauszug erzeugen, den Sie in der Datei ppp.core finden. Sie sollten dann folgendes tun: &prompt.user; su &prompt.root; gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 .... (gdb) i args .... (gdb) l ..... Mit Hilfe all dieser Informationen sollte es möglich sein, das Problem zu diagnostizieren. Falls Sie mit &man.gdb.1; vertraut sind, könnten Sie weitere Einzelheiten herausfinden, z.B. wodurch der Fehler tatsächlich hervorgerufen wurde oder die Adressen und Werte der betreffenden Variablen. Warum bekommt das Programm, das eine Anwahl im Modus ausgelöst hat, keine Verbindung? Dies war ein bekanntes Problem bei &man.ppp.8;-Konfigurationen, bei denen im Modus dynamische, lokale IP-Adressen mit dem Partner ausgehandelt werden. Das Problem ist bereits seit einiger Zeit behoben - suchen Sie in den Manualpages nach iface. Das Problem bestand darin, dass, wenn das erste Programm &man.connect.2; aufruft, die IP-Adresse der &man.tun.4;-Schnittstelle dem Socketendpunkt zugeordnet wird. Der Kernel erstellt das erste ausgehende Paket und schreibt es in das &man.tun.4;-Gerät. &man.ppp.8; liest dann das Paket und baut eine Verbindung auf. Falls die Schnittstellenadresse sich nun aufgrund &man.ppp.8;s dynamischer Adresszuordnung ändert, wird der originale Socketendpunkt ungültig. Alle weiteren Pakete, die zum Partner gesendet werden, werden für gewöhnlich verworfen. Selbst wenn sie nicht verworfen werden würden, würden alle Antworten nicht an den betreffenden Rechner gelangen, weil die IP-Adresse nicht mehr zu diesem Rechner gehört. Theoretisch gibt es mehrere Möglichkeiten, dieses Problem anzugehen. Am schönsten wäre es, wenn der Partner die gleiche IP-Adresse wieder zuordnen würde, wenn möglich. Die derzeitige Version von &man.ppp.8; tut das, aber die meisten anderen Implementierungen nicht. Die einfachste Maßnahme von unserer Seite wäre die, niemals die IP-Adresse der &man.tun.4;-Schnittstelle zu ändern, sondern stattdessen alle ausgehenden Pakete so zu ändern, dass als Absender-IP-Adresse anstelle der IP-Adresse der Schnittstelle die ausgehandelte IP-Adresse gesetzt wird. Das ist im wesentlichen das, was durch die Option iface-alias in der aktuellsten Version von &man.ppp.8; bewirkt wird (mit Unterstützung von &man.libalias.3; und &man.ppp.8;'s Schalter) - alle Schnittstellenadressen werden beibehalten und auf die letzte ausgehandelte Adresse umgesetzt. Eine andere Alternative (und wahrscheinlich die zuverlässigste) wäre die, einen Systemaufruf zu implementieren der die IP-Adressen aller verbundenen Sockets von einer Adresse in eine andere ändert. &man.ppp.8; würde diesen Aufruf benutzen, um die Sockets aller laufenden Programme zu ändern, nachdem eine neue IP-Adresse ausgehandelt worden ist. Der gleiche Systemaufruf könnte von DHCP-Clients benutzt werden, wenn sie gezwungen werden, die bind()-Funktion auf ihren Sockets auszuführen. Noch eine andere Möglichkeit wäre die, das Aktivieren von Schnittstellen ohne IP-Adresse zu erlauben. Ausgehende Paketen würde die IP-Adresse 255.255.255.255 gegeben, bis der erste &man.ioctl.2; mit SIOCAIFADDR erfolgt. Dies würde in der vollständigen Verbindung des Sockets resultieren. Es wäre die Aufgabe von &man.ppp.8;, die Absender-IP-Adresse zu ändern, allerdings nur dann, wenn sie 255.255.255.255 lautet und nur die IP-Adresse und IP-Prüfsumme müssten geändert werden. Dies wäre allerdings keine besonders elegante Lösung, da der Kernel fehlerhafte Pakete an eine unzureichend konfigurierte Schnittstelle senden würde, in der Annahme, dass andere Mechanismen in der Lage sind, diese Dinge rückwirkend zu beheben. Warum laufen die meisten Spiele mit dem Schalter nicht? Der Grund dafür, dass Spiele und andere Programme nicht funktionieren, wenn &man.libalias.3; benutzt wird, ist der, dass der Rechner außerhalb des lokalen Netzes versucht, eine Verbindung aufzubauen und (unaufgefordert) UDP-Pakete an den Rechner innerhalb des lokalen Netzes zu senden. Die Software, die für die NAT zuständig ist, weiß nicht, dass sie diese Pakete an den internen Rechner weiterleiten soll. Um dies zu beheben, stellen Sie zunächst sicher, dass die Software, mit der Sie Probleme haben, die einzige ist, die gerade läuft. Benutzen Sie dann entweder &man.tcpdump.1; auf der &man.tun.4;-Schnittstelle des Gateways oder aktivieren Sie auf dem Gateway das Logging von TCP/IP (set log +tcp/ip) unter &man.ppp.8;. Wenn Sie nun das betreffende Programm starten, sollten Sie sehen, wie Pakete den Gateway-Rechner passieren. Wenn von außen etwas zurückkommt, wird es ignoriert (das ist das Problem). Merken Sie sich die Portnummer dieser Pakete und beenden Sie das betreffende Programm. Wiederholen Sie diesen Schritt einige Male, um festzustellen, ob die Portnummern konsistent sind. Falls dem so ist, wird die folgende Zeile im entsprechenden Abschnitt von /etc/ppp/ppp.conf dafür sorgen, dass das Programm funktioniert: nat port proto internalmachine:port port wobei für proto entweder tcp oder udp zu setzen ist, internalmachine den Rechner bezeichnet, an den die Pakete geschickt werden sollen und port die betreffende Portnummer. Sie können das Programm nicht auf einem anderen Rechner benutzen, ohne die obige Zeile abzuändern und die Benutzung des Programms auf zwei internen Rechnern steht außer Frage - schließlich sieht die Außenwelt Ihr gesamtes internes Netz so, als wäre es ein einzelner Rechner. Falls die Portnummern nicht konsistent sind, gibt es drei weitere Optionen: Ermöglichen Sie die Unterstützung durch &man.libalias.3;. Beispiele für spezielle Fälle finden Sie in /usr/src/sys/netinet/libalias/alias_*.c (alias_ftp.c ist ein schöner Prototyp). Hierzu gehört für gewöhnlich das Lesen bestimmter, erkannter, ausgehender Pakete, die Identifizierung der Instruktion, die den entfernten Rechner dazu veranlasst, auf einem bestimmten (wahlfreien) Port eine Verbindung zurück zum lokalen Rechner herzustellen, sowie das Erstellen einer Route in der Aliastabelle, so dass nachfolgende Pakete wissen, wohin sie gehören. Dieses ist zwar die komplizierteste Lösung, aber die beste, die auch dafür sorgt, dass die Software auf mehreren Rechnern funktioniert. Benutzen Sie einen Proxy. Die Anwendung könnte z.B. socks5 unterstützen, oder (wie im Fall von cvsup) eine Option passiv besitzen, die stets verhindert, dass verlangt wird, dass der Partner eine Verbindung zurück zur lokalen Maschine aufbaut. Leiten Sie mit nat addr alles zur lokalen Maschine um. Dieses Vorgehen ähnelt dem mit einem Vorschlaghammer. Hat jemand eine Liste mit nützlichen Portnummern erstellt? Noch nicht, aber hieraus könnte eine solche entstehen (falls Interesse besteht). In jedem Beispiel sollte internal durch die IP-Adresse der Maschine ersetzt werden, auf der das Spiel laufen soll. Asheron's Call nat port udp internal:65000 65000 Konfigurieren Sie das Spiel manuell auf Port 65000 um. Wenn Sie von mehreren Rechner aus spielen wollen, weisen Sie jedem eine eindeutige Portnummer zu (also 65001, 65002, u.s.w.) und fügen Sie für jede Maschine eine eigene nat port Zeile ein. Half Life nat port udp internal:27005 27015 PCAnywhere 8.0 nat port udp internal:5632 5632 nat port tcp internal:5631 5631 Quake nat port udp internal:6112 6112 Quake 2 nat port udp internal:27901 27910 nat port udp internal:60021 60021 nat port udp internal:60040 60040 Red Alert nat port udp internal:8675 8675 nat port udp internal:5009 5009 Was sind FCS-Fehler? FCS steht für Frame Check Sequence. Jedes PPP-Paket besitzt eine Checksumme, um sicherzustellen, dass die empfangenen Daten dieselben sind, wie die versendeten. Falls die FCS eines ankommenden Paketes fehlerhaft ist, wird das Paket verworfen und der Zähler HDLC FCS wird erhöht. Der HDLC-Fehlerwert kann durch den Befehl show hdlc angezeigt werden. Falls Ihre Leitung schlecht ist (oder falls Ihr serieller Treiber Pakete verwirft), werden sie gelegentliche FCS-Fehler sehen. Normalerweise lohnt es sich nicht, sich hierüber Gedanken zu machen, obwohl das Kompressionsprotokoll hierdurch wesentlich langsamer wird. Wenn Sie ein externes Modem besitzen, stellen Sie sicher, dass Ihr Kabel ausreichend gegen Interferenzen abgeschirmt ist - das könnte das Problem beseitigen. Falls Ihre Leitung einfriert, sobald die Verbindung steht, und viele FCS-Fehler auftreten, könnte das daran liegen, dass Ihre Leitung nicht 8-Bit-rein ist. Stellen Sie sicher, dass Ihr Modem keinen Software-Flow-Control (XON/XOFF) verwendet. Falls Ihre Datenschnittstelle Software-Flow-Control verwenden muss, benutzen Sie den Befehl set accmap 0x000a0000, um &man.ppp.8; zu sagen, dass es die Zeichen ^Q und ^S maskieren soll. Ein weiterer Grund dafür, dass zu viele FCS-Fehler auftreten, könnte der sein, dass das andere Ende aufgehört hat, ppp zu sprechen. Aktivieren Sie async Logging, um festzustellen, ob es sich bei den eingehenden Daten tatsächlich um einen login- oder Shell-Prompt handelt. Wenn Sie am anderen Ende einen Shell-Prompt haben, ist es möglich, durch den Befehl close lcp &man.ppp.8; zu beenden, ohne die Verbindung zu beenden (ein folgender term-Befehl wird Sie wieder mit der Shell auf dem entfernten Rechner verbinden. Falls nichts in Ihrer Logdatei darauf hindeutet, warum die Verbindung beendet wurde, sollten Sie den Administrator des externen Rechners (Ihren ISP?) fragen, warum die Sitzung beendet worden ist. Wieso hängen die Verbindungen meiner &macos;- und &windows; 98-Maschinen (und eventuell auch andere µsoft; Betriebssysteme), wenn auf meinem Gateway PPPoE läuft? Vielen Dank an Michael Wozniak mwozniak@netcom.ca für die Erklärung und an Dan Flemming danflemming@mac.com für die Lösung für &macos;. Die Ursache des Problems ist ein so genannter Black Hole Router. &macos; und &windows; 98 (und wahrscheinlich auch die anderen Betriebssysteme von µsoft;) senden TCP Pakete, bei denen zum einen die angeforderte Segmentgröße zu groß für einen PPPoE-Rahmen ist (die Default-MTU für Ethernet beträgt 1500 Byte) und bei denen das don't fragment Bit gesetzt ist (das ist bei TCP allerdings Standard). Außerdem sendet der Router beim Provider nicht die eigentlich notwendigen must fragment-Meldungen zu dem Webserver, von dem Sie gerade eine Seite laden wollen. Es ist auch möglich, dass diese Meldung zwar erzeugt, aber danach von einem Firewall vor dem Webserver abgefangen wird. Wenn Ihnen dieser Webserver nun ein Paket schickt, das nicht in einen PPPoE-Rahmen passt, dann verwirft der Router dieses Paket und die Seite wird nicht geladen (einige Seiten/Grafiken werden geladen, weil ihre Größe kleiner ist als die MSS). Dies scheint leider der Normalfall zu sein. Eine der möglichen Lösungen für dieses Problem ist die Erzeugung des folgenden Schlüssels in der Registry des Windows-Clients mit regedit: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU Der Schlüssels sollte vom Typ String sein und den Wert 1436 haben, da einige ADSL-Router nicht mit größeren Paketen umgehen können. Wenn Sie &windows; 2000 verwenden, müssen Sie hingegen den Schlüssel Tcpip\Parameters\Interfaces\ID der Netzwerkkarte\MTU benutzen, außerdem müssen Sie als Typ DWORD verwenden. Die Knowledge Base von µsoft; enthält weitere Informationen darüber, wie sie die MTU einer &windows;-Maschine ändern, damit diese mit einem NAT-Router korrekt zusammenarbeitet. Vom besonderen Interesse sind die Artikel Q158474 - &windows; TCPIP Registry Entries und Q120642 - TCPIP & NBT Configuration Parameters for &windowsnt;. Bei &windows; 2000 können Sie alternativ auch, wie im Artikel 120642 beschrieben, mit regedit das DWORD Tcpip\Parameters\Interfaces\ID der Netzwerkkarte\EnablePMTUBHDetect auf 1 setzen. Mit den Bordmitteln von &macos; ist es leider nicht möglich, die TCP/IP-Einstellungen zu verändern. Es gibt jedoch kommerzielle Lösungen, mit denen man die TCP/IP-Einstellungen bearbeiten kann. Wenn Sie als &macos;-Anwender NAT benutzen, suchen Sie ihre MTU-Einstellungen und geben Sie dort 1450 statt 1500 ein. &man.ppp.8; kennt seit Version 2.3 den Befehl enable tcpmssfixup, mit dem die MSS automatisch korrigiert wird. Wenn Sie einen ältere Version von &man.ppp.8; benutzen müssen, könnte der Port net/tcpmssd für Sie interessant sein. Nichts von alledem hilft - ich bin verzweifelt! Was soll ich machen? Falls alles andere fehlschlägt, senden Sie möglichst umfangreiche Informationen, einschließlich Ihrer Konfigurationsdateien, wie Sie &man.ppp.8; starten, die relevanten Teile Ihrer Logdateien und die Ausgabe des Befehls netstat -rn (vor und nach Aufbau der Verbindung) an die Mailingliste &a.de.questions; oder die Newsgroup de.comp.os.unix.bsd. Irgend jemand sollte Ihnen dann weiterhelfen. Serielle Verbindungen Dieses Kapitel beantwortet häufig gestellte Fragen zu seriellen Verbindungen mit &os;. PPP und SLIP werden im Abschnitt Netzwerke behandelt. Wie kann ich feststellen, ob &os; meine seriellen Schnittstellen gefunden hat? Wenn der &os; Kernel bootet, testet er die seriellen Schnittstellen, für die er konfiguriert wurde. Sie können entweder Ihrem System aufmerksam beim Booten zusehen und die angezeigten Nachrichten lesen, oder Sie führen den folgenden Befehl aus, nachdem Ihr System hochgefahren ist und läuft: &prompt.user; dmesg | grep -E "^sio[0-9]" Hier ist ein Beispiel einer Ausgabe nach dem oben genannten Befehl: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A Es zeigt zwei serielle Schnittstellen. Die erste verwendet Port-Adresse 0x3f8, IRQ 4 und hat einen 16550A UART Chip. Die zweite benutzt ebenfalls einen 16550A UART, jedoch Port-Adresse 0x2f8 und IRQ 3. Modemkarten werden wie serielle Schnittstellen behandelt. Der einzige Unterschied ist, dass an diesen Schnittstellen immer ein Modem angeschlossen ist. Der GENERIC Kernel beinhaltet Unterstützung für zwei serielle Schnittstellen, die den im Beispiel genannten Port und IRQ verwenden. Wenn diese Einstellungen nicht richtig für Ihr System sind, Sie Modemkarten hinzugefügt oder mehr serielle Schnittstellen haben als Ihre Kernelkonfiguration zulässt, konfigurieren Sie Ihren Kernel einfach neu. In dem Kapitel über die Kernelkonfiguration finden Sie mehr Details. Wie kann ich feststellen, ob &os; meine Modemkarten gefunden hat? Die vorherige Frage sollte darauf eine Antwort geben. Wie kann ich auf die seriellen Schnittstellen in &os; zugreifen? Die in &man.sio.4; beschriebene serielle Schnittstelle sio2 (COM3 unter &ms-dos;/&windows;), ist /dev/cuad2 für Geräte mit abgehenden Verbindungen und /dev/ttyd2 für Geräte mit eingehenden Verbindungen. Was ist der Unterschied zwischen den beiden Geräteklassen? Sie benutzen ttydX für eingehende Verbindungen. Wird /dev/ttydX im blockierenden Modus geöffnet, wartet ein Prozess darauf, dass das entsprechende cuadX Gerät inaktiv und der Empfangssignalpegel Mit Empfangssignalpegel oder Trägersignalerkennung wird hier die carrier detect Leitung bezeichnet. aktiv ist. Wird das cuadX Gerät geöffnet, vergewissert es sich, dass die serielle Schnittstelle nicht bereits von dem ttydX Gerät in Gebrauch ist. Sollte die Schnittstelle verfügbar sein, stiehlt es sie von dem ttydX Gerät. Das cuadX Gerät kümmert sich nicht um Trägersignalerkennung. Mit diesem Schema und einem automatisch antwortenden Modem, können sich Benutzer von aussen einloggen, Sie können weiterhin mit demselben Modem wählen und das System kümmert sich um die Konflikte. Wie kann ich die Unterstützung für eine Karte mit mehreren seriellen Schnittstellen aktivieren? Die Sektion über die Kernelkonfiguration bietet Informationen darüber, wie Sie Ihren Kernel konfigurieren. Für eine Karte mit mehreren seriellen Schnittstellen, schreiben Sie eine &man.sio.4; Zeile für jede serielle Schnittstelle auf der Karte in die Datei &man.device.hints.5;. Aber achten Sie darauf, den IRQ nur in einem der Einträge zu platzieren. Alle seriellen Schnittstellen auf der Karte sollten sich einen IRQ teilen. Daher sollten Sie den IRQ nur beim letzten Eintrag angeben. Aktivieren Sie auch die folgende Option in der Kernelkonfigurationsdatei: options COM_MULTIPORT Das folgende /boot/device.hints Beispiel ist geeignet für eine AST Karte mit 4 seriellen Schnittstellen, die IRQ 12 benutzt: hint.sio.4.at="isa" hint.sio.4.port="0x2a0" hint.sio.4.flags="0x701" hint.sio.5.at="isa" hint.sio.5.port="0x2a8" hint.sio.5.flags="0x701" hint.sio.6.at="isa" hint.sio.6.port="0x2b0" hint.sio.6.flags="0x701" hint.sio.7.at="isa" hint.sio.7.port="0x2b8" hint.sio.7.flags="0x701" hint.sio.7.irq="12" Die Flags zeigen an, dass die Master-Schnittstelle die Minor-Nummer 7 (0x700) hat und dass sich alle Schnittstellen einen IRQ teilen (0x001). Kann &os; mehrere Karten mit mehreren seriellen Schnittstellen mit den gleichen IRQs verwalten? Noch nicht. Sie müssen für jede Karte einen anderen IRQ verwenden. Kann ich die vorgegebenen seriellen Parameter für eine Schnittstelle einstellen? Lesen Sie den Abschnitt Serielle Datenübertragung im &os; Handbuch. Wie kann ich Einwahl-Logins über mein Modem aktivieren? Lesen Sie dazu bitte den Abschnitt über Einwählverbindungen im &os; Handbuch. Wie kann ich ein Hardware-Terminal mit meiner &os; Box verbinden? Diese Information können Sie im Abschnitt Terminals im &os; Handbuch finden. Warum kann ich tip oder cu nicht laufen lassen? Auf Ihrem System können die Programme &man.tip.1; und &man.cu.1; auf das Verzeichnis /var/spool/lock nur über den Benutzer uucp und die Gruppe dialer zugreifen. Sie können die Gruppe dialer verwenden, um zu kontrollieren wer Zugriff auf Ihr Modem oder entfernte Systeme hat. Fügen Sie sich einfach selbst zur Gruppe dialer hinzu. Als Alternative können Sie jeden Benutzer auf Ihrem System &man.tip.1; und &man.cu.1; verwenden lassen, dazu müssen Sie das folgende eingeben: &prompt.root; chmod 4511 /usr/bin/cu &prompt.root; chmod 4511 /usr/bin/tip Mein Hayes Modem wird nicht unterstützt – was kann ich tun? Lesen Sie diese Antwort im &os; Handbuch. Wie soll ich die AT Befehle eingeben? Im &os; Handbuch finden Sie dazu diese Antwort. Wieso funktioniert das @ Zeichen für die pn Fähigkeit nicht? Lesen Sie dazu diese Antwort im &os; Handbuch. Wie kann ich von der Kommandozeile eine Telefonnummer wählen? Lesen Sie diese Antwort im &os; Handbuch. Muss ich dabei jedes Mal die bps Rate angeben? Im &os; Handbuch finden Sie dazu diese Antwort. Wie kann ich möglichst komfortabel über einen Terminal-Server auf verschiedene Rechner zugreifen? Lesen Sie im &os; Handbuch diese Antwort. Kann tip mehr als eine Verbindung für jede Seite ausprobieren? Lesen Sie diese Antwort im &os; Handbuch. Warum muss ich zweimal CtrlP tippen, um ein CtrlP zu senden? Im &os; Handbuch finden Sie dazu diese Antwort. Warum ist auf einmal alles was ich schreibe in GROSSBUCHSTABEN?? Lesen Sie im &os; Handbuch diese Antwort. Wie kann ich Dateien mit tip übertragen? Lesen Sie diese Antwort im &os; Handbuch. Wie kann ich zmodem mit tip laufen lassen? Sie finden dazu diese Antwort im &os; Handbuch. Verschiedene Fragen &os; benutzt viel mehr Swap-Speicher als &linux;. Warum? Es sieht nur so aus, als ob &os; mehr Swap benutzt, als &linux;. Tatsächlich ist dies nicht der Fall. In dieser Hinsicht besteht der Hauptunterschied zwischen &os; und &linux; darin, dass &os; vorbeugend vollkommen untätige, unbenutzte Seiten aus dem Hauptspeicher in den Swap-Bereich auslagert, um mehr Hauptspeicher für die aktive Nutzung zur Verfügung zu stellen. &linux; tendiert dazu, nur als letzten Ausweg Seiten in den Swap-Bereich auszulagern. Die spürbar höhere Nutzung des Swap-Speichers wird durch die effizientere Nutzung des Hauptspeichers wieder ausgeglichen. Beachten Sie, dass &os; in dieser Hinsicht zwar vorbeugend arbeitet, es entscheidet jedoch nicht willkürlich, Seiten auszulagern, wenn das System vollkommen untätig ist. Deshalb werden Sie feststellen, dass nicht alle Seiten Ihres Systems ausgelagert wurden, wenn Sie morgens aufstehen, nachdem das System eine Nacht lang nicht benutzt worden ist. Warum zeigt mir &man.top.1; so wenig freien Speicher an, obwohl nur wenige Programme laufen? Die Antwort ist ganz einfach: Freier Speicher ist verschwendeter Speicher. Der &os; Kernel verwendet den von den Programmen nicht genutzten Speicher automatisch für den Plattencache. Die in &man.top.1; für Inact, Cache und Buf gemeldeten Werte stehen alle für zwischengespeicherte Daten mit unterschiedlichem Alter. Wenn das System wiederholt auf Daten zugreifen muss, braucht es nicht auf die langsame Platte zuzugreifen, da die Daten noch zwischengespeichert sind. Dadurch erhöht sich die Performance. Ganz generell ist es ein gutes Zeichen, wenn &man.top.1; einen kleinen Wert bei Free anzeigt, solange der Wert nicht extrem klein ist. Anmerkung des Übersetzers: Mit extrem klein sind hier Werte unterhalb 512 KByte gemeint. Warum ändert chmod die Zugriffsrechte auf symbolische Links nicht? Für symbolische Links gibt es keine separaten Zugriffsrechte und standardmäßig folgt &man.chmod.1; dem Link nicht; die Zugriffsrechte für die Datei, auf die der symbolische Link zeigt, werden also nicht verändert. Wenn Sie eine Datei mit dem Namen foo und einen auf diese Datei zeigenden symbolischen Link mit dem Namen bar haben, wird das folgende Kommando niemals einen Fehler melden. &prompt.user; chmod g-w bar Trotzdem werden die Zugriffsrechte für foo nicht geändert. Hierzu müssen Sie entweder oder zusammen mit der Option benutzen. Weitere Informationen finden Sie in den Manualpages &man.chmod.1; und &man.symlink.7;. Die Option bewirkt ein rekursives &man.chmod.1;. Seien Sie vorsichtig, wenn Sie bei &man.chmod.1; Verzeichnisse oder symbolische Links zu Verzeichnissen angeben. Wenn Sie die Zugriffsrechte eines Verzeichnisses ändern möchten, das durch einen symbolischen Link referenziert wird, benutzen Sie &man.chmod.1; ohne irgendwelche Optionen und folgen dem symbolischen Link durch einen abschließenden Schrägstrich (/). Falls z.B. foo ein symbolischer Link zum Verzeichnis bar ist und Sie die Zugriffsrechte von foo (tatsächlich bar) ändern möchten, dann benutzen Sie etwas ähnliches wie: &prompt.user; chmod 555 foo/ Durch den abschließenden Schrägstrich folgt &man.chmod.1; dem symbolischen Link foo, um die Zugriffsrechte für das Verzeichnis bar zu ändern. Kann ich DOS-Programme unter &os; ausführen? Ja. Sie können emulators/doscmd verwenden, das über die Ports-Sammlung verfügbar ist. Falls doscmd nicht ausreicht, können Sie den Port emulators/pcemu verwenden, der einen 8088 und genug BIOS-Funktionen emuliert, um DOS-Textanwendungen laufen zu lassen. Der Port benötigt das X-Window-System. Sie können auch emulators/dosbox aus der &os; Ports Sammlung ausprobieren. Der Hauptaugenmerk liegt bei dieser Anwendung auf der Emulation alter DOS Spiele, deren Dateien sich im lokalen Dateisystem befinden. Was muss ich tun, um die &os;-Dokumentation in meine Muttersprache zu übersetzen? Informationen zu diesem Thema finden Sie auf der Webseite des &os; German Documentation Project. Warum kommen alle meine Mails, die ich an @FreeBSD.org schicke, wieder zurück? Das Mailsystem von FreeBSD.org verwendet einige der strengeren Überprüfungen von Postfix für eingehende Mails. Mails, bei denen es Anzeichen für Konfigurationsprobleme oder Spam gibt, werden nicht akzeptiert. Dies kann aus einem der folgenden Gründe geschehen: Die Mail kommt von einem System oder Netzwerk, dass für Spam-Aktivitäten bekannt ist. Die Mailserver von &os; akzeptierten keine Mails von bekannten Spam-Quellen. Wenn Sie eine Firma oder Domain benutzen, die Spam erzeugt oder verteilt, sollten Sie sich einen anderen ISP suchen. Der Mailtext enthält HTML. Mail sollte immer im Klartext gesendet werden, Sie sollten ihr Mailprogramm entsprechend einstellen. Das Mailsystem kann die IP-Adresse des einliefernden Systems nicht in einen symbolischen Namen umwandeln. Funktionierendes reverse DNS ist eine Vorbedingung, damit ihre Mails angenommen wird. Sorgen Sie dafür, dass der reverse DNS für Ihren Mailserver korrekt konfiguriert wird. Viele Anbieter für Privatkunden geben Ihnen diese Möglichkeit nicht. In diesem Fall sollten Sie Ihre Mails über den Mailserver Ihres Providers versenden. Der Rechnername, der im EHLO/HELO Teil der SMTP Kommunikation übergeben wird, kann nicht zu einer IP-Adresse aufgelöst werden. Damit die E-Mail akzeptiert wird, brauchen Sie einen voll qualifizierten Rechnernamen, der im DNS eingetragen ist. Wenn Sie diesen nicht besitzen, benutzen Sie bitte den Mailserver Ihres Providers, um E-Mails zu verschicken. Die Message-ID Ihrer Mail endet in localhost. Einige Mail-Clients generieren eine Message-ID, die nicht akzeptiert wird. Sie müssen Ihren Mail-Client so konfigurieren, dass er eine gültige Message-ID generiert. Alternativ können Sie die Message-ID von Ihrem Mailserver umschreiben lassen. Wo kann ich einen freien &os;-Account bekommen? Das &os; Project bietet zwar keinen freien Zugang zu seinen Servern an; andere Firmen bieten jedoch frei zugängliche &unix; Systeme. Die Kosten variieren und es kann sein, dass nicht alle Dienste zur Verfügung stehen. Arbornet, Inc, auch als M-Net bekannt, bietet seit 1983 uneingeschränkten Zugang zu &unix; Systemen. Zunächst wurde eine Altos-Maschine mit System III benutzt, 1991 erfolgte dann der Wechsel zu BSD/OS. Im Juni 2000 erfolgte ein erneuter Wechsel, diesmal zu &os;. M-Net bietet Zugang mit Telnet und SSH und den Zugang zur gesamten Software von &os;. Allerdings ist der Zugriff auf das Netzwerk auf Mitglieder und Gönner beschränkt, die eine Spende an die nicht-kommerzielle Organisation geleistet haben. M-Net stellt zusätzlich ein Mailbox-System und einen interaktiven Chat zur Verfügung. Grex bietet ein ganz ähnlichen Dienst wie M-Net an, dazu gehören auch das Mailbox-System und der interaktive Chat. Allerdings wird eine SUN 4M mit &sunos; benutzt. Was ist sup und wie benutze ich es? Der Name SUP steht für Software Update Protocol und wurde von der CMU (Carnegie Mellon University) entwickelt, um ihre Entwicklungszweige zu synchronisieren. Es wurde benutzt, um entfernte Sites mit den zentralen Quellcodeentwicklungen des Projekts zu synchronisieren. SUP ist nicht sehr bandbreitenfreundlich und wurde abgelöst. Die derzeit empfohlene Methode, um Ihren Quellcode auf dem neuesten Stand zu halten ist CVSup. Wie heißt das niedliche rote Kerlchen? Er ist namenlos, es ist einfach der der BSD Daemon. Wenn Sie ihm unbedingt einen Namen geben wollen, rufen Sie ihn beastie. Beachten Sie aber, dass beastie wie BSD ausgesprochen wird. Weitere Informationen über den BSD daemon finden Sie auf seiner Homepage. Kann ich Bilder des BSD Daemon verwenden? Eventuell. Der BSD Daemon unterliegt dem Copyright von Marshall Kirk McKusick. Wenn Sie genaue Informationen über die Einschränkungen bei der Nutzung brauchen, sollten Sie sein Statement on the Use of the BSD Daemon Figure lesen. Kurz gesagt, können Sie den BSD Daemon benutzen, solange es für einen privaten Zweck ist und die Nutzung geschmackvoll bleibt. Für den kommerziellen Einsatz brauchen Sie die Zustimmung von &a.mckusick;. Weitere Informationen erhalten Sie auf der Webseite BSD Daemon's home page. Woher kann ich Bilder des BSD Daemon bekommen? Einige Bilder in den Format xfig und eps sind unter /usr/share/examples/BSD_daemon/ zu finden. Ich habe in den Mailinglisten eine Abkürzung oder einen Begriff gesehen, den ich nicht kenne. Wo erhalte ich eine Erklärung dazu? Sehen Sie bitte im &os;-Glossar nach. Warum sollte mich die Farbe des Fahrradschuppens interessieren? Die ganz, ganz kurze Antwort ist: Überhaupt nicht. Die etwas längere Antwort lautet: Nur weil Sie in der Lage sind, einen Fahrradschuppen zu bauen, müssen Sie noch lange nicht andere davon abhalten, nur weil Ihnen die Farbe nicht gefällt. Dies ist natürlich eine Metapher dafür, dass Sie nicht eine Diskussion über jede kleine Änderung beginnen sollen, nur weil Sie das können. Einige Leute behaupten sogar, dass die Anzahl der (nutzlosen) Kommentare über eine Änderung umgekehrt proportional zur Komplexität der Änderung ist. Die noch längere und vollständigere Antwort ist, dass &a.phk; nach einen langen Diskussion über das Thema "Soll &man.sleep.1; Sekundenbruchteile als Parameter akzeptieren?" eine lange Mail mit dem Titel A bike shed (any colour will do) on greener grass... schrieb. Die einschlägigen Teile der Nachricht lauteten:
&a.phk; in &a.hackers.name;, 2.10.1999 Einige von Euch haben mich gefragt, Was meinst Du mit dem Fahrradschuppen? Es ist eine lange oder eigentlich eher eine sehr alte und doch sehr kurze Geschichte. C. Northcote Parkinson schrieb in den frühen Sechzigern ein Buch mit dem Namen Parkinson's Law, das viele Einblick in die Beziehungen innerhalb des Managements gibt. [ein paar Kommentare zum Buch gestrichen] In dem Beispiel mit dem Fahrradschuppen ist die andere wichtige Komponente ein Kernkraftwerk. Ich glaube, dass zeigt schon, wie alt dieses Buch ist. Parkinson zeigte, dass man zum Vorstand gehen kann und die Genehmigung für ein mehrere Millionen oder sogar Milliarden Dollar teures Kernkraftwerk bekommt; wenn man aber einen Fahrradschuppen bauen will, wird man in endlose Diskussionen verwickelt. Laut Parkinson liegt das daran, dass ein Kernkraftwerk so groß, so teuer und so kompliziert ist, dass die Leute es nicht verstehen. Und bevor sie versuchen, es zu verstehen, verlassen Sie sich lieber darauf, dass irgend jemand sicherlich die ganzen Details geprüft hat, bevor das Projekt bis zum Vorstand gekommen ist. Im Buch von Richard P. Feynmann finden sich einige interessante und sehr passende Beispiele aus dem Gebiet von Los Alamos. Ein Fahrradschuppen ist was anderes. Jeder kann an seinem freien Wochenende einen bauen und hat trotzdem noch genug Zeit für die Sportschau. Daher ist es unwichtig, wie gut man sich vorbereitet und wie sinnvoll der eigene Vorschlag ist. Irgend jemand wird die Möglichkeit nutzen und zeigen, dass er seine Arbeit tut, dass er aufmerksam ist, dass er da ist. In Dänemark nennen wir dieses Verhalten Seine Fingerabdrücke hinterlassen. Es geht um persönlichen Stolz und Prestige; die Chance, auf irgend etwas zu zeigen und zu sagen zu können: Da! Das habe Ich getan. Politiker leiden sehr stark darunter, aber viele Leute verhalten sich so, wenn sie die Chance haben. Denkt einfach mal an Fußabdrücke in feuchtem Zement.
Nicht ganz ernstgemeinte Fragen Wie cool ist &os;? Q. Hat irgend jemand Temperaturmessungen durchgeführt, während &os; läuft? Ich weiss, dass &linux; cooler läuft, als DOS, habe aber niemals gesehen, dass &os; erwähnt wurde. Es scheint sehr heiß zu laufen. A. Nein, aber wir haben zahlreiche Geschmackstests mit verblendeten Freiwilligen durchgeführt, denen außerdem zuvor 250 Mikrogramm LSD-25 verabreicht wurden. 35% der Freiwilligen sagte, dass &os; nach Orange schmeckte, &linux; hingegen schmecke wie purple haze (Anm. d. Übersetzers: Song von Jimmy Hendrix und LSD-Marke). Keine der Gruppen hat besondere Abweichungen der Temperatur erwähnt. Eventuell hätten wir sämtliche Ergebnisse dieser Untersuchung fortwerfen sollen, als wir festgestellt haben, dass zu viele der Freiwilligen den Raum während der Tests verlassen haben und dadurch die Ergebnisse verfälscht haben. Wir glauben, dass die meisten der Freiwilligen nun bei Apple sind und an ihrer neuen scratch and sniff Oberfläche arbeiten. Es ist ein lustiges, altes Geschäft, in dem wir uns befinden! Ernsthaft, &os; und &linux; benutzen beide die Instruktion HLT (halt), wenn das System untätig ist, wodurch der Energieverbrauch und dadurch die produzierte Wärme reduziert wird. Falls Sie auch noch APM (Advanced Power Management) konfiguriert haben, kann &os; Ihre CPU auch in einen Low-Power-Modus bringen. Wer kratzt in meinen Speicherbänken?? Q. Gibt es irgend etwas seltsames, das &os; tut, wenn ich den Kernel kompiliere, das dazu führt, dass der Speicher ein kratzendes Geräusch macht? Bei der Kompilierung (und auch für einen kurzen Moment nach der Erkennung des Floppy-Laufwerks beim Hochfahren), kommt ein seltsames kratzendes Geräusch von etwas das die Speicherbänke zu sein scheinen. A. Ja! In der BSD-Dokumentation finden Sie häufige Verweise auf Daemons und was die meisten Leute nicht wissen, ist, dass diese sich auf echte, nicht-körperlichen Wesen beziehen, die Besitz von Ihrem Computer ergriffen haben. Das kratzende Geräusch, das von Ihrem Speicher kommt, ist in Wirklichkeit hochtöniges Flüstern, das unter den Daemons ausgetauscht wird, während Sie entscheiden, wie Sie die verschiedenen Systemadministrationsaufgaben, am besten erledigen. Wenn Sie das Geräusch stört, wird ein fdisk /mbr sie vertreiben, aber wundern Sie sich nicht, wenn sie feindlich reagieren und versuchen, Sie aufzuhalten. Wenn Sie während der Ausführung zu irgendeinem Zeitpunkt die teuflische Stimme von Bill Gates aus dem eingebauten Lautsprecher kommen hören, laufen Sie weg und sehen Sie sich auf keinen Fall um! Befreit von dem ausgleichenden Einfluss der BSD Dämonen sind die beiden Dämonen von DOS und &windows; oft dazu in der Lage, die totale Kontrolle über Ihre Maschine für die ewige Verdammung Ihrer Seele zurückzuerlangen. Da Sie jetzt die Wahrheit kennen, würden Sie es vorziehen, sich an die Geräusche zu gewöhnen, wenn Sie die Wahl hätten. Wie viele &os;-Hacker braucht man, um eine Glühbirne auszuwechseln? Eintausendeinhundertundneunundsechzig: Dreiundzwanzig, die sich bei -CURRENT beschweren, dass das Licht aus ist; Vier, die behaupten, dass es sich um ein Konfigurationsproblem handelt und dass solche Dinge wirklich nach -questions gehören; Drei, die PRs hierzu einreichen, einer von ihnen wird falsch unter DOC abgelegt und fristet sein Dasein im Dunkeln; Einen, der eine ungetestete Glühbirne einreicht, wonach buildworld nicht mehr funktioniert, und sie dann fünf Minuten später wieder herausnimmt; Acht, die die PR-Erzeuger beschimpfen, weil sie zu ihren PRs keine Patche hinzugefügt haben; Fünf, die sich darüber beschweren, dass buildworld nicht mehr funktioniert; Einunddreißig, die antworten, dass es bei ihnen funktioniert und dass sie cvsup wohl zu einigem ungünstigen Zeitpunkt durchgeführt haben; Einen, der einen Patch für eine neue Glühbirne an -hackers schickt; Einen, der sich beschwert, dass es vor drei Jahren Patches hierfür hatte, aber als er sie nach -CURRENT schickte, sind sie einfach ignoriert worden und er hatte schlechte Erfahrungen mit dem PR-System; nebenbei ist die vorgeschlagene Glühbirne nicht reflexiv; Siebenunddreißig, die schreien, dass Glühbirnen nicht in das Basissystem gehören, dass Committer nicht das Recht haben, solche Dinge durchzuführen, ohne die Gemeinschaft zu konsultieren und WAS GEDENKT -CORE HIER ZU TUN!? Zweihundert, die sich über die Farbe des Fahrradschuppens beschweren; Drei, die darauf hinweisen, dass der Patch nicht mit &man.style.9; übereinstimmt; Siebzehn, die sich beschweren, dass die vorgeschlagene neue Glühbirne der GPL unterliegt; Fünfhundertundsechsundachtzig, die sich in einen Streit über die vergleichbaren Vorteile der GPL, der BSD-Lizenz, der MIT-Lizenz, der NPL und der persönlichen Hygiene nichtgenannter FSF-Gründer verwickeln; Sieben, die unterschiedliche Teile des Threads nach -chat und -advocacy weiterleiten; Einer, der die vorgeschlagene Glühbirne einbaut, obwohl sie dunkler leuchtet, als die alte; Zwei, die sie wieder ausbauen, und in einer wütenden Nachricht argumentieren, dass &os; besser ganz im Dunkeln dasteht, als mit einer dämmerigen Glühbirne; Sechsundvierzig, die sich lärmend wegen des Wiederausbaus der dämmerigen Glühbirne streiten und eine Erklärung von -core verlangen; Elf, die eine kleinere Glühbirne beantragen, damit sie in ihr Tamagotchi passt, falls wir irgendwann beschließen, &os; auf diese Plattform zu portieren; Dreiundsiebzig, die sich über die SNR auf -hackers und -chat beschweren und aus Protest abmelden; Dreizehn, die unsubscribe, How do I unsubscribe? oder Please remove me from the list gefolgt von der üblichen Fußzeile abschicken; Einen, der eine funktionierende Glühbirne einbaut, während alle zu beschäftigt damit sind, mit jedem zu streiten, um es zu bemerken; Einunddreißig, die herausstellen, dass die neue Glühbirne 0,364% heller leuchten würde, wenn sie mit TenDRA kompiliert werden würde (obwohl sie in einen Würfel umgeformt werden müsste) und dass &os; deshalb nach TenDRA, anstatt nach GCC wechseln sollte; Einen, der sich beschwert, dass bei der neuen Glühbirne die Verkleidung fehlt; Neun (einschließlich der PR-Ersteller), die fragen Was ist MFC? Siebenundfünfzig, die sich zwei Wochen, nachdem die Birne gewechselt worden ist, darüber beschweren, dass das Licht aus war. &a.nik; hat hinzugefügt: Ich habe ziemlich hierüber gelacht. Und dann dachte ich: "Halt, sollte in dieser Liste nicht irgendwo 'Einer, der es dokumentiert' sein?" Und dann wurde ich erleuchtet :-) &a.tabthorpe; sagt: Keine, echte &os; Hacker fürchten sich nicht vor der Dunkelheit! Was passiert mit den Daten, die nach /dev/null geschrieben werden? Sie werden in einer speziellen Datensenke der CPU in Wärme umgewandelt, die dann über den Kühlkörper und den Lüfter abgeführt wird. Dies ist einer der Gründe für die Kühlung von CPUs; die Anwender gewöhnen sich an die schnelleren Prozessoren, gehen nicht mehr so sorgfältig mit Ihren Daten um und so landen immer mehr Daten in /dev/null, was zur Überhitzung der CPU führt. Wenn Sie /dev/null löschen (was die Datensenke ziemlich sicher abschaltet), wird Ihre CPU zwar nicht mehr so heiß, dafür wird Ihr System aber sehr schnell von den überzähligen Daten überladen und merkwürdige Effekte zeigen. Wenn Sie eine sehr schnell Netzwerkverbindung haben, können Sie Ihre CPU kühlen, indem sie Daten aus /dev/random lesen und in die Weite des Netzwerkes schicken; allerdings besteht hier die Gefahr der Überhitzung von Netzwerk und /. Außerdem dürfte Ihr ISP ziemlich wütend werden, da der größte Teil der Daten von seinen Geräten in Hitze umgewandelt werden wird; da ISPs aber über Klimaanlagen verfügen, sollte das kein großes Problem sein, solange Sie es nicht übertreiben. Nachtrag Paul Robinson: Es gibt andere Mittel und Wege. Wie jeder gute Systemadministrator weiss, gehört es zum guten Ton, einigen Daten zum Bildschirm zu senden, damit die Leuchtkäferchen, die das Bild anzeigen, glücklich sind. Die Leuchtkäferchen werden nach der Farbe Ihrer Hüte (Rot, Grün, oder Blau) unterschieden und sie verstecken bzw. zeigen sich (wobei man die Farbe ihrer Hüte erkennen kann) bei jeder Nahrungsaufnahme. Grafikkarten wandeln Daten in Leuchkäfer-Nahrung um und schicken sie dann zu den Leuchtkäfern - teure Karten erzeugen bessere Nahrung und sorgen so für besseres Verhalten der Leuchtkäfer. Diese brauchen allerdings einen konstanten Stimulus - darum gibt es Bildschirmschoner. Darum lautet mein Vorschlag, die zufälligen Daten einfach zum Bildschirm zu schicken, damit sie von den Leuchtkäfern verzehrt werden. Dabei entsteht keine Hitze, die Leuchtkäfer bleiben glücklich und man wird seine überflüssigen Daten sehr schnell los, auch wenn der Bildschirm etwas merkwürdig aussieht. Übrigens: Als Ex-Admin eines großen ISPs, der so seine Probleme mit der Kühlung seines Rechenzentrums hatte, kann ich nur davon abraten, überflüssige Daten einfach in das Netzwerk zu schicken. Die Heinzelmännchen, die die Pakete verteilen und versenden, regen sich darüber ganz furchtbar auf. Weiterführende Themen Wie kann ich mehr über die Interna von &os; erfahren? Zurzeit gibt es nur ein Buch über die Interna von &os;, The Design and Implementation of the &os; Operating System von Marshall Kirk McKusick und George V. Neville-Neil, ISBN 0-201-70245-2, das sich auf &os; 5.X konzentriert. Allgemeines Wissen über &unix; kann allerdings in den meisten Fällen auf &os; angewendet werden. Eine Liste finden Sie im entsprechenden Abschnitt der Bibliographie. Wie kann ich bei der Entwicklung von &os; mitarbeiten? Genauere Informationen finden Sie im Artikel &os; unterstützen. Wir können Hilfe immer gut gebrauchen! Was sind Snapshots und RELEASEs? Derzeit existieren drei aktive/halbaktive Zweige im &os;-CVS-Repository. In früheren Zweigen ändert sich wenig, daher gibt es nur drei aktive Entwicklungszweige: - RELENG_6 bzw. + RELENG_7 bzw. 6-STABLE - RELENG_7 bzw. + RELENG_8 bzw. 7-STABLE HEAD bzw. -CURRENT oder - 8-CURRENT + 9-CURRENT HEAD ist keine wirkliche Bezeichnung für einen Zweig, wie die anderen beiden. Es ist lediglich eine symbolische Konstante für den aktuellen, nicht verzweigten Entwicklungsstrom, auf den wir uns einfach als -CURRENT beziehen. Derzeit steht -CURRENT für den - 8.X-Entwicklungsstrom. Der - 6-STABLE-Zweig (RELENG_6) - wurde von -CURRENT im November 2005 und der - 7-STABLE-Zweig (RELENG_7) im - Februar 2008 von -CURRENT abgespalten. + 9.X-Entwicklungsstrom. Der + 7-STABLE-Zweig (RELENG_7) + wurde von -CURRENT im Februar 2008 und der + 8-STABLE-Zweig (RELENG_7) im + November 2009 von -CURRENT abgespalten. Wie kann ich meine eigene, angepasstes Release erstellen? Eine Anleitung dazu finden Sie im Artikel &os; Release Engineering. Wieso überschreibt make world das installierte System? Das ist beabsichtigt. Wie der Name schon andeutet, erstellt make world alle Systemdateien von Grund auf neu. Sie können also sicher sein, am Ende eine saubere, konsistente Umgebung zu haben (das ist der Grund, warum es so lange dauert). Falls die Umgebungsvariable DESTDIR während der Ausführung von make world oder make install definiert ist, werden die neu erstellten Binaries unter ${DESTDIR} in einem zum installierten identischen Verzeichnisbaum abgelegt. Einige zufällige Kombinationen von Änderungen von Shared Libraries und Neuerstellungen von Programmen können hierbei jedoch ein Scheitern von make world verursachen. Warum ist cvsup.FreeBSD.org kein Round-Robin-Eintrag im DNS, so dass Anfragen auf alle CVsup-Server verteilt werden? Die CVsup-Server gleichen sich stündlich mit dem Hauptserver ab. Allerdings findet der Abgleich nicht zur gleichen Zeit statt, daher können einige Server neuere Quellen bereitstellen als andere Server. Alle Server stellen jedoch Quellen bereit, die maximal eine Stunde alt sind. Wäre cvsup.FreeBSD.org ein Round-Robin-Eintrag im DNS, der Benutzern einen zufälligen Server zuteilt, könnten beim zweiten Lauf von CVsup ältere Quellen als beim ersten Lauf heruntergeladen werden. Kann ich -CURRENT mit begrenztem Internetzugang folgen? Ja, Sie können das tun, ohne den gesamten Quellbaum herunterzuladen, indem Sie die Einrichtung CTM benutzen. Wie haben Sie die Distribution in 1392 KB-Dateien aufgespalten? Bei neueren BSD-basierten Systemen gibt es eine Option zu &man.split.1;, die das Splitten von Dateien an willkürlichen Bytegrenzen erlaubt. Hier ist ein Beispiel aus /usr/src/release/Makefile. ZIPNSPLIT= gzip --no-name -9 -c | split -b 1392k - Ich habe eine Kernelerweiterung geschrieben. An wen sende ich sie? Lesen Sie bitte den Artikel &os; unterstützen. Und Danke, dass Sie darüber nachdenken! Wie werden Plug&Play ISA-Karten erkannt und initialisiert? Von: Frank Durda IV uhclem@nemesis.lonestar.org Kurz gesagt gibt es nur wenige I/O-Ports über die PnP-Karten antworten, wenn der Host fragt, ob jemand da ist. Wenn die PnP-Erkennungsroutine startet, fragt sie, ob irgendwelche PnP-Karten vorhanden sind und alle PnP-Karten antworten mit ihrer Modellnummer auf demselben Port, von dem sie auch gelesen haben. Die Erkennungsroutine erhält also ein geodertes Ja auf diese Frage. Mindestens ein Bit wird bei dieser Antwort gesetzt sein. Die Erkennungsroutine ist dann in der Lage, dafür zu sorgen, dass Karten mit Modellnummern (zugeordnet von µsoft;/&intel;) kleiner als X off-line gesetzt werden. Sie prüft dann, ob immer noch Karten da sind, die auf die Frage antworten. Falls die Antwort 0 war, sind keine Karten mit IDs größer X vorhanden. Die Erkennungsroutine wird daraufhin anfragen, ob Karten unterhalb X vorhanden sind. Schließlich setzt die Erkennungsroutine alle Karten größer als X - (limit / 4) off-line und wiederholt die Frage. Wenn diese halbbinäre Suche nach IDs in Folge genügend oft wiederholt worden ist, wird die Erkennungsroutine schließlich alle in einem Rechner befindlichen PnP-Karten identifiziert haben und das mit einer Iterationszahl sehr viel kleiner als 264. Die IDs bestehen aus zwei 32-Bit-Feldern (daher 264) + acht Bit Prüfsumme. Die ersten 32 Bit sind die Herstellerkennung. Es wurde zwar nicht bestätigt, aber es wird angenommen, dass unterschiedliche Kartentypen desselben Herstellers unterschiedliche 32-Bit Herstellerkennungen besitzen können. 32 Bit nur für eindeutige Hersteller zu benötigen, scheint etwas übertrieben. Die niedrigen 32 Bit sind eine Seriennummer oder etwas anderes, das die betreffende Karte einzigartig macht. Die Hersteller dürfen niemals eine zweite Karte mit denselben niedrigen 32 Bit herstellen, es sei denn, die höheren 32 Bit sind unterschiedlich. Sie können also mehrere Karten des selben Typs im Rechner haben und die gesamten 64 Bit bleiben stets eindeutig. Die 32-Bit-Gruppen können niemals nur aus Nullen bestehen. Das erlaubt es, bei der binären Suche zu Beginn nur auf von Null verschiedene Bits zu achten. Wenn das System alle vorhandenen Karten-IDs identifiziert hat, reaktiviert es jede Karte - eine nach der anderen (über dieselben I/O-Ports) und ermittelt, welche Ressourcen von der jeweiligen Karte benötigt werden, welche Wahlmöglichkeiten für Interrupts bestehen usw. Alle Karten werden abgefragt, um diese Informationen zusammenzustellen. Diese Informationen werden dann mit Informationen aus allen ECU-Dateien auf der Festplatte oder mit im MLB-BIOS verdrahteten Informationen verknüpft. Die ECU- und BIOS-PnP-Unterstützung für Hardware auf dem MLB ist für gewöhnlich künstlich und was die Peripheriegeräte tun ist nicht wirklich echtes PnP. Durch die Untersuchung der BIOS-Informationen und der ECU-Informationen können die Erkennungsroutinen jedoch die von PnP-Geräten benutzten Ressourcen so ändern, dass vermieden wird, dass bereits von anderen Geräten benutzte Ressourcen verwendet werden. Dann werden die PnP-Geräte nochmals besucht und ihre I/O, DMA, IRQ und Memory-Map-Adressen werden zugeordnet. Die Geräte werden an diesen Stellen sichtbar werden und dort bis zum nächsten Reboot verbleiben. Allerdings hindert Sie auch nichts daran, sie zu verschieben, wohin Sie wollen. Im obigen Teil wurde sehr viel vereinfacht, aber die grundlegende Idee sollte klar geworden sein. µsoft; hat einige der primären Druckerstatusports für PnP übernommen, da keine Karte diese Adressen für die entgegengesetzten I/O-Zyklen decodiert. Ich habe während der frühen Überprüfungsperiode des PnP-Vorschlags eine echte IBM Druckerkarte gefunden, die Schreibzugriffe auf dem Statusport decodiert hat, aber µsoft; hat nur tough gesagt. Also schreiben sie auf den Druckerstatusport, um Adressen zu setzen, benutzen zusätzlich diese Adresse + 0x800 und einen dritten I/O-Port zum Lesen, der irgendwo zwischen 0x200 und 0x3ff liegen kann. Wie bekomme ich eine Major-Number für einen Gerätetreiber, den ich geschrieben habe? &os; Versionen stellen seit Februar 2003 Major-Numbers für Geräte automatisch zur Laufzeit bereit (lesen Sie &man.devfs.5;), damit ist das nicht mehr nötig. Gibt es alternative Layoutverfahren für Verzeichnisse? Als Antwort auf die Frage nach alternativen Layoutverfahren für Verzeichnisse ist das Schema, das derzeit benutzt wird, unverändert von dem, das ich 1983 geschrieben habe. Ich habe das Vorgehen für das originale Fast-Filesystem geschrieben und es niemals überarbeitet. Es funktioniert gut, wenn es darum geht, zu verhindern, dass Zylindergruppen volllaufen. Wie viele von Ihnen angemerkt haben, funktioniert es schlecht für find. Die meisten Dateisysteme werden von Archiven erstellt, die mit einer Tiefensuche (also ftw) erstellt wurden. Diese Verzeichnisse werden über die Zylindergruppen hinweg entfaltet und erzeugen denkbar ungünstigste Voraussetzungen für zukünftige Tiefensuchen. Falls man die Gesamtzahl der zu erstellenden Verzeichnisse wüsste, wäre die Lösung die, (gesamt / fs_ncg) pro Zylindergruppe zu erstellen, bevor fortgefahren wird. Offensichtlich müsste man eine Heuristik erstellen, um die Zahl zu schätzen. Sogar die Benutzung einer kleinen, fixen Zahl, z.B. 10, würde eine Verbesserung um Größenordnungen ausmachen. Um Wiederherstellungen von normalem Betrieb (wo der derzeitige Algorithmus vermutlich sinnvoller ist) zu unterscheiden, könnten Sie die Clusterung von bis zu 10 benutzen, wenn sie alle innerhalb eines 10-Sekunden-Fensters durchgeführt würden. Jedenfalls ist mein Schluss, dass dies ein fruchtbares Gebiet für Experimente ist. &a.mckusick;, September 1998 Wie kann ich optimalen Nutzen aus einer kernel panic ziehen? Hier ist eine typische Kernel-Panic Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault Wenn Sie eine Meldung wie diese sehen, reicht es nicht, sie einfach zu reproduzieren und sie einzusenden. Der Wert des Instruktionszeigers ist wichtig; leider ist er auch konfigurationsabhängig. Mit anderen Worten variieren die Werte abhängig von dem Kernel-Image, das Sie tatsächlich benutzen. Wenn Sie ein GENERIC Kernelimage von einem der Snapshots benutzen, dann ist es für jemand anderen möglich, die fehlerhafte Instruktion herauszufinden, aber wenn Sie einen angepassten Kernel benutzen, können nur Sie uns sagen, wo der Fehler auftrat. Was Sie tun sollten, ist folgendes: Notieren Sie sich den Wert des Instruktionszeigers. Beachten Sie, dass der Teil 0x8: am Anfang in diesem Fall nicht von Bedeutung ist; der Teil 0xf0xxxxxx ist der, den wir wollen. Tun Sie folgendes, wenn das System rebootet: &prompt.user; nm /kernel.that.caused.the.panic | grep f0xxxxxx wobei 0xf0xxxxxx der Wert des Instruktionszeigers ist. Es besteht die Möglichkeit, dass Sie keinen exakten Treffer erzielen, weil die Symbole in der Symboltabelle des Kernels Funktionseinstiegspunkte sind und die Adresse des Instruktionszeigers irgendwo innerhalb einer Funktion liegen wird und nicht am Anfang. Falls sie keinen exakten Treffer erzielen, lassen Sie den letzten Teil des Werts des Instruktionszeigers weg und versuchen es noch einmal, z.B.: &prompt.user; nm /kernel.that.caused.the.panic | grep f0xxxxx Falls das kein Ergebnis liefert, hacken Sie eine weitere Ziffer ab. Wiederholen Sie die Schritte, bis Sie irgendeine Ausgabe erhalten. Das Ergebnis wird eine Liste möglicher Funktionen sein, die die Panik verursacht haben. Das ist zwar kein absolut genauer Mechanismus, um die Fehlerursache ausfindig zu machen, aber es ist besser als gar nichts. Wie dem auch sei, der beste Weg, den Grund für eine Panik herauszufinden, ist der, einen Crash-Dump festzuhalten und dann &man.kgdb.1; zu benutzen, um den Stack im Crash-Dump zurückzuverfolgen. Jedenfalls ist die Methode, die ich normalerweise benutze, folgende: Sorgen Sie dafür, dass die folgende Zeile in der Kernelkonfigurationsdatei (/usr/src/sys/arch/conf/MYKERNEL) enthalten ist: makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols Wechseln Sie in das Verzeichnis usr/src: &prompt.root; cd /usr/src Erstellen Sie den Kernel: &prompt.root; make buildkernel KERNCONF=MYKERNEL Warten Sie, bis &man.make.1; den Kernel fertig kompiliert hat. &prompt.root; make installkernel KERNCONF=MYKERNEL Starten Sie das System neu. Falls Sie die make-Variable KERNCONF nicht verwenden, wird ein GENERIC Kernel gebaut und installiert. Der &man.make.1;-Prozess wird zwei Kernel erstellt haben: /usr/obj/usr/src/sys/MYKERNEL/kernel und /usr/obj/usr/src/sys/MYKERNEL/kernel.debug. kernel wurde als /boot/kernel installiert, während kernel.debug als Quelle für Debuggersymbole für &man.kgdb.1; benutzt werden kann. Um sicherzustellen, dass ein Crash-Dump erhalten bleibt, müssen Sie /etc/rc.config editieren und dumpdev so setzen, dass es auf Ihre Swap-Partition zeigt. Das bewirkt, dass die &man.rc.8;-Skripte den Befehl &man.dumpon.8; benutzen, um Crash-Dumps zu ermöglichen. Sie können &man.dumpon.8; auch manuell ausführen. Nach einer Panik kann der Crash-Dump mit &man.savecore.8; wiederhergestellt werden; wenn dumpdev in /etc/rc.conf gesetzt ist, werden die &man.rc.8;-Skripte &man.savecore.8; automatisch ausführen und den Crash-Dump unter /var/crash ablegen. Crash-Dumps von &os; sind für gewöhnlich genauso groß wie der physikalische Hauptspeicher Ihres Rechners. Das heißt, wenn Sie 512MB RAM haben, werden sie einen 512MB Crash-Dump erhalten. Deshalb müssen Sie dafür sorgen, dass genügend Speicherplatz in /var/crash zur Verfügung steht, um den Dump aufnehmen zu können. Alternativ führen Sie &man.savecore.8; manuell aus und lassen es den Crash-Dump in einem anderen Verzeichnis wiederherstellen, in dem Sie mehr Platz haben. Es ist möglich, die Größe des Crash-Dumps zu begrenzen, indem options MAXMEM=N, wobei N die Größe des verwendeten Kernelspeichers in KBs ist. Wenn Sie z.B. 1 GB RAM haben, können Sie die Speicherbenutzung des Kernels damit auf 128 MB begrenzen, so dass die Größe Ihres Crash-Dumps 128 MB anstatt 1 GB betragen wird. Wenn Sie den Crash-Dump wiederhergestellt haben, können Sie den Stack mit &man.kgdb.1; so zurückverfolgen: &prompt.user; kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0 (kgdb) backtrace Beachten Sie, dass es mehrere Seiten mit wertvollen Informationen geben könnte; idealerweise sollten Sie &man.script.1; benutzen, um sie alle festzuhalten. Wenn Sie das vollständige Kernelimage mit allen Debugginginformationen benutzen, müssten Sie exakt die Zeile des Kernel-Sourcecodes finden, wo die Panik aufgetreten ist. Für gewöhnlich müssen Sie den Stack von unten an zurückverfolgen, um die genaue Ereignisabfolge, die zum Crash führte, zurückzuverfolgen. Sie können &man.kgdb.1; auch zum Ausdrucken der Inhalte verschiedener Variablen oder Strukturen benutzen, um den Systemstatus zum Zeitpunkt des Absturzes zu untersuchen. Wenn Sie nun wirklich verrückt sind und einen zweiten Computer haben, können Sie &man.kgdb.1; auch für entferntes Debugging konfigurieren, so dass Sie &man.kgdb.1; auf einem System benutzen können, um den Kernel auf einem anderen System zu debuggen, einschließlich dem Setzen von Haltepunkten und dem Bewegen in Einzelschritten durch den Kernelcode, genauso, wie Sie es mit einem normalen Benutzerprogramm tun können. Wenn Sie DDB aktiviert haben und der Kernel im Debugger landet, können Sie eine Panik (und einen Crash-Dump) erzwingen, indem Sie einfach panic am ddb-Prompt eingeben. Er könnte während der Panikphase wieder im Debugger stoppen. Falls er das tut, geben Sie continue ein, dann wird er den Crash-Dump beenden. Wieso funktioniert dlsym() nicht mehr für ELF-Executables? Die ELF-Werkzeuge machen die in einem Executable definierten Symbole dem dynamischen Linker nicht standardmäßig sichtbar. Konsequenterweise werden dlsym()-Suchen nach Handlern aus Aufrufen von dlopen(NULL, flags) diese Symbole nicht finden können. Wenn Sie mit dlsym() nach im Hauptexecutable eines Prozesses vorhandenen Symbolen suchen wollen, müssen Sie das Executable mit der Option von &man.ld.1; linken. Wie kann ich den Adressraum des Kernels auf i386 vergrössern oder verkleinern? Standardmäßig beträgt der Adressraum des Kernels 1 GB (2 GB für PAE) auf i386. Wenn Sie einen netzwerkintensiven Server (z.B. einen großen FTP- oder HTTP-Server) betreiben, oder ZFS verwenden möchten, kann es sein, dass Sie der Meinung sind, dass das nicht ausreichen. Fügen Sie die folgende Zeile zu ihrer Kernelkonfigurationsdatei hinzu, um den verfügbaren Speicher zu erhöhen und erstellen Sie dann einen neuen Kernel: options KVA_PAGES=N Um den richtigen Wert von N zu bestimmen, teilen Sie den gewünschte Größe des Addressraumes (in Megabyte) durch vier (z.B. beträgt er 512 für 2 GB). Danksagung Dieses kleine unschuldige Dokument mit Häufig gestellten Fragen wurde in den letzten 10 Jahren von Hunderten, wenn nicht Tausenden, geschrieben, neu geschrieben, überarbeitet, gefaltet, verdreht, durcheinander gebracht, wieder aufgebaut, verstümmelt, seziert, durchgekaut, überdacht, und wiederbelebt. Und das nicht nur einmal. Wir möchten allen dafür Verantwortlichen danken und wir fordern auch Sie auf, dieser Gruppe beizutreten, um diese FAQ noch besser zu machen. Folgende Personen haben durch die Beantwortung von Fragen, sowie durch Hinweise und Kommentare an der Entstehung der deutschen Übersetzung mitgewirkt: Ross Alexander &a.jhb; &a.nik; Glen Foster Oliver Fromme Frank Gruender Chris Hill James Howard &a.jkh; &a.alex; &a.jmas; Mike Meyer Dan O'Connor Eric Ogren &a.de.pierau; Oliver Schneider Christoph Sold Und an alle anderen, an die wir nicht gedacht haben. Entschuldigung und herzlichen Dank! &bibliography;
diff --git a/de_DE.ISO8859-1/books/handbook/desktop/chapter.sgml b/de_DE.ISO8859-1/books/handbook/desktop/chapter.sgml index 899c15f5c0..12ef826664 100644 --- a/de_DE.ISO8859-1/books/handbook/desktop/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/desktop/chapter.sgml @@ -1,1213 +1,1213 @@ Christophe Juniet Beigetragen von Martin Heinen Übersetzt von Desktop-Anwendungen Übersicht FreeBSD bietet eine reiche Auswahl an Desktop-Anwendungen, wie Browser und Textverarbeitungen, die als Pakete oder mit der Ports-Sammlung installiert werden. Gerade neue Benutzer erwarten Anwendungen mit einer grafischen Benutzeroberfläche an ihrem Arbeitsplatz. Dieses Kapitel zeigt Ihnen, wie Sie einige der beliebtesten Desktop-Anwendungen mühelos installieren. Wenn Sie Ports installieren, beachten Sie, dass dabei die Quelltexte der Programme übersetzt werden. Abhängig von dem Programm und der Geschwindigkeit Ihrer Maschinen kann das sehr lange dauern. Wenn Ihnen das Übersetzen zu lange dauert, können Sie die meisten Programme der Ports-Sammlung auch als fertige Pakete installieren. Da FreeBSD binär kompatibel zu Linux ist, können Sie zahlreiche für Linux entwickelte Desktop-Anwendungen einsetzen. Bevor Sie allerdings Linux-Anwendungen installieren, sollten Sie das lesen. Wenn Sie nach einem bestimmten Port suchen, zum Beispiel mit &man.whereis.1;, beachten Sie, dass die Namen vieler Programme, die die Linux-Binärkompatibilität benutzen, mit linux- anfangen. Wir gehen im Folgenden davon aus, dass Sie die Linux-Binärkompatibilität aktiviert haben, bevor Sie Linux-Anwendungen installieren. Dieses Kapitel behandelt Anwendungen aus den Bereichen: Browser (Firefox, Opera, Konqueror) Büroanwendungen (KOffice, AbiWord, The GIMP, OpenOffice.org) Dokumentformate(&acrobat.reader;, gv, Xpdf, GQview) Finanzsoftware ( GnuCash, Gnumeric, Abacus) Bevor Sie dieses Kapitel lesen, sollten Sie Software Dritter installieren können () und Linux-Anwendungen installieren können (). Wie Sie Multimedia-Anwendungen einrichten, wird in einem gesonderten Kapitel erklärt. Wie Sie E-Mail einrichten und benutzen, wird in beschrieben. Browser Browser Web FreeBSD besitzt keinen vorinstallierten Browser, stattdessen enthält das www-Verzeichnis der Ports-Sammlung Browser, die Sie installieren können. Wenn Ihnen das Übersetzen der Browser zu lange dauert, bei einigen Browsern dauert das wirklich lange, installieren Sie die Pakete, die es für viele Browser gibt. KDE und GNOME enthalten schon HTML-Browser. Das Einrichten dieser grafischen Benutzeroberflächen ist in beschrieben. Wenn Sie besonders schlanke Browser benötigen, suchen Sie in der Ports-Sammlung nach www/dillo2, www/links oder www/w3m. Dieser Abschnitt behandelt die nachstehenden Anwendungen: Anwendung Ressourcenbedarf Installationsaufwand aus den Ports wichtige Abhängigkeiten Firefox mittel hoch Gtk+ Opera niedrig niedrig Es gibt eine &os;- und eine Linux-Version. Die Linux-Version hängt von der Linux-Kompatibilität (Linux Binary Compatibility) und linux-openmotif ab. Konqueror mittel hoch KDE-Biliotheken Firefox Firefox Firefox ist ein moderner, freier und stabiler Open-Source Browser, der vollständig auf &os; portiert wurde. Er bietet eine dem HTML-Standard konforme Anzeige, Browserfenster als Tabs, Blockierung von Werbefenstern, Erweiterungen, verbesserte Sicherheit und mehr. Firefox basiert auf der Mozilla Codebasis. Das Paket können Sie mit dem nachstehenden Befehl installieren: &prompt.root; pkg_add -r firefox Damit installieren Sie Firefox 2.X, wenn Sie stattdessen Firefox 3.X einsetzen möchten, geben Sie folgenden Befehl ein: &prompt.root; pkg_add -r firefox3 Alternativ können Sie auch die Ports-Sammlung verwenden, um das Programm aus dem Quellcode zu installieren: &prompt.root; cd /usr/ports/www/firefox &prompt.root; make install clean Ersetzen Sie im vorherigen Kommando firefox durch firefox3 für Firefox 3.X. Firefox und das &java;-Plugin Dieser und der nächste Abschnitt gehen davon aus, dass Sie Firefox bereits installiert haben. Die &os; Foundation hat von Sun Microsystems eine Lizenz erworben, die es erlaubt, &os;-Binärpakete des Java Runtime Environment (&jre;) und des Java Development Kit (&jdk;) zu verteilen. Diese Binärpakete sind auf der Webseite der &os; Foundation erhältlich. Damit Firefox &java; unterstützt, müssen Sie zuerst den Port java/javavmwrapper installieren. Anschließend laden Sie das Diablo &jre;-Paket von herunter und installieren es mit &man.pkg.add.1;. Danach starten Sie Ihren Browser und geben in der Adresszeile about:plugins ein und bestätigen die Eingabe mit der Enter-Taste. Dadurch wird eine Seite geladen, auf der alle installierten Plugins aufgelistet werden. Auch das &java;-Plugin sollte nun in dieser Liste aufgeführt sein. Sollte dies bei Ihnen nicht der Fall sein, muss jeder Benutzer noch das folgende Kommando ausführen: &prompt.user; ln -s /usr/local/diablo-jre1.6.0/plugin/i386/ns7/libjavaplugin_oji.so \ $HOME/.mozilla/plugins/ Oder, falls Sie das Diablo &jdk;-Paket installiert haben: &prompt.user; ln -s /usr/local/diablo-jdk1.6.0/jre/plugin/i386/ns7/libjavaplugin_oji.so \ $HOME/.mozilla/plugins/ Danach starten Sie Ihren Browser neu, um das Plugin zu aktivieren. Firefox und das ¯omedia; &flash;-Plugin Flash Das ¯omedia; &flash;-Plugin ist für &os; nicht verfügbar. Es existiert jedoch ein Software-Layer (ein sogenannter Wrapper), der es erlaubt, die Linux-Version des Plugins unter &os; einzusetzen. Dieser Wrapper unterstützt außerdem das &adobe; &acrobat;-Plugin, das &realplayer;-Plugin und andere mehr. Je nachdem, welche Version von &os; Sie verwenden, sind unterschiedliche Schritte notwendig: Für &os; 7.X Installieren Sie den Port www/nspluginwrapper. Dieser Port setzt voraus, dass Sie den Port emulators/linux_base-fc4 bereits installiert haben, der sehr gross ist. Anschließend installieren Sie den Port www/linux-flashplugin9. Dadurch wird &flash; 9.X installiert, denn diese Version läuft zuverlässig auf &os; 7.X. Bei &os; Versionen, die älter sind als &os; 7.1-RELEASE müssen Sie www/linux-flashplugin7 installieren und den &man.linprocfs.5; Abschnitt übergehen. Für &os; 8.X Installieren Sie den Port www/nspluginwrapper. Dieser Port benötigt den emulators/linux_base-f10 Port, der sehr gross ist. Als nächstes installieren Sie den Port www/linux-f10-flashplugin10. Dadurch wird &flash; 10.X installiert, das in dieser Version unter &os; 8.X stabil läuft. Für diese Version muss der folgende symbolische Link angelegt werden: &prompt.root; ln -s /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so \ /usr/local/lib/browser_plugins/ Sobald der richtige &flash;-Port passend zu ihrer &os; Version installiert ist, muss das Plugin von jedem Benutzer mittels nspluginwrapper installiert werden: &prompt.user; nspluginwrapper -v -a -i Das &linux; Prozessdateisystem, &man.linprocfs.5;, muss unter /usr/compat/linux/proc eingehängt werden, wenn Sie &flash;-Animationen abspielen möchten. Dies kann mittels des folgenden Kommandos geschehen: &prompt.root; mount -t linprocfs linproc /usr/compat/linux/proc Dieser Schritt kann automatisiert zur Bootzeit ablaufen, indem Sie die passende Zeile in /etc/fstab eintragen: linproc /usr/compat/linux/proc linprocfs rw 0 0 Rufen Sie dann Ihren Browser auf und geben in der Adresszeile about:plugins ein. Diese Eingabe muss mit der Enter-Taste bestätigt werden. Danach wird eine Seite geladen, auf der alle installierten Plugins aufgelistet werden. Firefox und das Swfdec &flash;-Plugin Swfdec ist die Bibliothek zum Dekodieren und Rendern von &flash; Animationen. Swfdec-Mozilla ist ein Plugin für Firefox-Browser, welches die Swfdec-Bibliothek zum Abspielen von SWF-Dateien benutzt. Momentan befindet sie sich noch in der Entwicklung. Wenn Sie diese nicht übersetzen können oder wollen, dann installieren Sie einfach das Paket aus dem Netz: &prompt.root; pkg_add -r swfdec-plugin Wenn das Paket nicht verfügbar ist, können Sie es auch über die Ports-Sammlung bauen und installieren: &prompt.root; cd /usr/ports/www/swfdec-plugin &prompt.root; make install clean Starten Sie anschliessend ihren Browser neu, damit dieses Plugin aktiviert wird. Opera Opera Opera ist ein schneller, vollwertiger und standardkonformer Browser, der wie Mozilla über einen eingebauten E-Mail- und Newsreader verfügt. Zusätzlich sind ein IRC-Client, ein RSS/Atom-Feeds-Reader sowie weitere Programme enthalten. Dennoch handelt es sich bei Opera weiterhin um ein relativ kleines und sehr schnelles Programmpaket. Sie haben die Wahl zwei Versionen dieses Browsers: Der nativen FreeBSD-Version und der Linux-Version. Wenn Sie das Web mit der FreeBSD-Version von Opera erkunden wollen, installieren Sie das Paket: &prompt.root; pkg_add -r opera Einige FTP-Server haben nicht alle Pakete, Sie können Opera aber über die Ports-Sammlung installieren: &prompt.root; cd /usr/ports/www/opera &prompt.root; make install clean Wenn Sie die Linux-Version des Browsers verwenden wollen, ersetzen Sie in den Beispielen opera durch linux-opera. Wenn Sie Plugins einsetzen wollen, die nur für Linux erhältlich sind, wie das Adobe &acrobat.reader; Plugin, benötigen Sie die Linux-Version. Ansonsten sind die FreeBSD- und Linux-Versionen des Browsers äquivalent. Konqueror Konqueror Konqueror ist Teil von KDE, kann aber außerhalb von KDE benutzt werden, wenn der Port x11/kdebase3 installiert ist. Konqueror ist mehr als nur ein Browser. Sie können das Programm weiters zur Dateiverwaltung und zum Abspielen von Multimedia-Dateien benutzen. Der Port misc/konq-plugins installiert verschiedene Plugins für Konqueror. Konqueror kann &flash;-Seiten darstellen. Wie Sie die &flash;-Unterstützung aktiviern, können Sie unter nachlesen. Büroanwendungen Neue Benutzer suchen oft ein komplettes Office-Paket oder eine leicht zu bedienende Textverarbeitung. Einige Benutzeroberflächen wie KDE enthalten zwar ein Office-Paket, diese werden in der Standardeinstellung unter FreeBSD aber nicht installiert. Unabhängig von der verwendeten Benutzeroberfläche können Sie diverse Office-Pakete aber jederzeit über die Ports-Sammlung installlieren. Dieser Abschnitt behandelt die nachstehenden Anwendungen: Anwendung Ressourcenbedarf Installationsaufwand aus den Ports wichtige Abhängigkeiten KOffice niedrig hoch KDE AbiWord niedrig niedrig Gtk+ oder GNOME The Gimp niedrig hoch Gtk+ OpenOffice.org hoch enorm - &jdk; 1.4, + &jdk;, Mozilla KOffice KOffice Office-Pakete KOffice Die KDE-Gemeinschaft stellt ein Office-Paket bereit, das auch außerhalb von KDE eingesetzt werden kann. Es besteht aus vier, von anderen Office-Paketen bekannten, Komponenten: KWord ist die Textverarbeitung, KSpread die Tabellenkalkulation, mit KPresenter werden Präsentationen erstellt und Kontour ist ein Zeichenprogramm. Stellen Sie vor der Installation des neusten KOffice sicher, dass Sie eine aktuelle Version von KDE besitzen. Mit dem folgenden Kommando installieren Sie das KOffice-Paket: &prompt.root; pkg_add -r koffice Wenn das Paket nicht zur Verfügung steht, benutzen Sie bitte die Ports-Sammlung. Wenn Sie beispielsweise KOffice für KDE3 installieren wollen, setzen Sie die nachstehendenen Befehle ab: &prompt.root; cd /usr/ports/editors/koffice-kde3 &prompt.root; make install clean AbiWord AbiWord AbiWord ist eine freie Textverarbeitung, die ähnlich wie µsoft; Word ist. Sie können damit Artikel, Briefe, Berichte, Notizen usw. verfassen. Das Programm ist sehr schnell, besitzt viele Funktionen und ist sehr benutzerfreundlich. AbiWord kann viele Dateiformate, unter anderem nicht offene wie .doc von µsoft;, importieren und exportieren. Das AbiWord-Paket installieren Sie wie folgt: &prompt.root; pkg_add -r AbiWord Sollte das Paket nicht zur Verfügung stehen, können Sie das Programm mit der Ports-Sammlung, die zudem aktueller als die Pakete ist, übersetzen. Gehen Sie dazu folgendermaßen vor: &prompt.root; cd /usr/ports/editors/AbiWord &prompt.root; make install clean The GIMP The GIMP The GIMP ist ein sehr ausgereiftes Bildverarbeitungsprogramm mit dem Sie Bilder erstellen oder retuschieren können. Sie können es sowohl als einfaches Zeichenprogramm als auch zum retuschieren von Fotografien benutzen. Das Programm besitzt eine eingebaute Skriptsprache und es existieren sehr viele Plug-Ins. The GIMP kann Bilder in zahlreichen Formaten lesen und speichern und stellt Schnittstellen zu Scannern und grafischen Tabletts zur Verfügung. Sie installieren das Paket mit dem nachstehenden Befehl: &prompt.root; pkg_add -r gimp Benutzen Sie die Ports-Sammlung, wenn Ihr FTP-Server das Paket nicht bereitstellt. Im Verzeichnis graphics finden Sie das Handbuch The Gimp Manual. Sie können alles mit den folgenden Befehlen installieren: &prompt.root; cd /usr/ports/graphics/gimp &prompt.root; make install clean &prompt.root; cd /usr/ports/graphics/gimp-manual-pdf &prompt.root; make install clean Die Entwickler-Version von The GIMP finden Sie im Verzeichnis graphics der Ports-Sammlung. Das Handbuch ist im HTML-Format (graphics/gimp-manual-html) erhältlich. OpenOffice.org OpenOffice.org Office-Pakete OpenOffice.org OpenOffice.org enthält alles, was von einem Office-Paket erwartet wird: Textverarbeitung, Tabellenkalkulation, Präsentation und ein Zeichenprogramm. Die Bedienung gleicht anderen Office-Paketen und das Programm kann zahlreiche Dateiformate importieren und exportieren. Es gibt lokalisierte Versionen mit angepassten Menüs, Rechtschreibkontrollen und Wörterbüchern. Die Textverarbeitung von OpenOffice.org speichert Dateien im XML-Format. Dadurch wird die Verwendbarkeit der Dateien auf anderen Systemen erhöht und die Handhabung der Daten vereinfacht. Die Tabellenkalkulation besitzt eine Makrosprache und eine Schnittstelle zu Datenbanken. OpenOffice.org läuft auf &windows;, &solaris;, Linux, FreeBSD und &macos; X. Weitere Informationen über OpenOffice.org finden Sie auf der OpenOffice.org Website. Spezifische Informationen für FreeBSD finden Sie auf der Webseite FreeBSD OpenOffice.org Porting Team. Von dort können Sie auch direkt das OpenOffice-Paket herunterladen. OpenOffice.org installieren Sie wie folgt: &prompt.root; pkg_add -r openoffice.org Diese Art der Installation sollte mit einer -RELEASE-Version funktionieren. Verwenden Sie eine andere Version, sollten Sie die Internetseite des &os; OpenOffice.org Porting Teams besuchen und das entsprechende Paket herunterladen und über &man.pkg.add.1; installieren, wobei Sie zwischen der aktuellen Version und der Entwicklerversion wählen können. Nachdem das Paket installiert ist, müssen Sie lediglich folgenden Befehl eingeben, um OpenOffice.org zu starten: &prompt.user; openoffice.org Nach dem ersten Start werden Ihnen einige Fragen gestellt. Außerdem wird in Ihrem Heimatverzeichnis der neue - Unterordner .openoffice.org2 + Unterordner .openoffice.org angelegt. Falls die OpenOffice.org-Pakete nicht zur Verfügung stehen, können Sie immer noch die Ports-Sammlung benutzen. Beachten Sie aber bitte, dass Sie sehr viel Plattenplatz und Zeit benötigen, um die Quellen zu übersetzen. - &prompt.root; cd /usr/ports/editors/openoffice-2 + &prompt.root; cd /usr/ports/editors/openoffice-3 &prompt.root; make install clean Wenn Sie ein lokalisierte Version bauen wollen, ersetzen Sie den letzten Befehl durch die folgende Zeile: &prompt.root; make LOCALIZED_LANG=Ihre_Sprache install clean Dabei ersetzen Sie Ihre_Sprache durch den korrekten ISO-Code. Eine Liste der unterstützten Codes enthält die Datei files/Makefile.localized, die sich im Portsverzeichnis befindet. Nachdem die Installation abgeschlossen ist, können Sie OpenOffice.org durch folgenden Befehl starten: &prompt.user; openoffice.org Anzeigen von Dokumenten Einige neuere Dokumentformate, die sich aktuell großer Beliebtheit erfreuen, können Sie sich mit den im Basissystem enthaltenen Programmen und Werkzeugen nicht ansehen. Dieser Abschnitt behandelt Programme, mit denen Sie sich Dokumente in unterschiedlichsten Formaten ansehen können. Die nachstehenden Anwendungen werden behandelt: Anwendung Ressourcenbedarf Installationsaufwand aus den Ports wichtige Abhängigkeiten &acrobat.reader; niedrig niedrig Linux Binary Compatibility gv niedrig niedrig Xaw3d Xpdf niedrig niedrig FreeType GQview niedrig niedrig Gtk+ oder GNOME &acrobat.reader; Acrobat Reader PDF anzeigen Viele Dokumente werden heute im Portable Document Format (PDF) zur Verfügung gestellt. PDF-Dokumente schauen Sie sich am Besten mit dem Programm &acrobat.reader; an, das von Adobe für Linux freigegeben wurde. Da Linux-Programme unter FreeBSD laufen, steht Ihnen das Programm auch hier zur Verfügung. - Um &acrobat.reader; 7 über + Um &acrobat.reader; 8 über die Ports-Sammlung zu installieren, geben Sie Folgendes ein: - &prompt.root; cd /usr/ports/print/acroread7 + &prompt.root; cd /usr/ports/print/acroread8 &prompt.root; make install clean Aufgrund der Lizenzbedinungen ist eine Paketversion leider nicht verfügbar. gv gv PDF anzeigen PostScript anzeigen gv kann &postscript;- und PDF-Dokumente anzeigen. Es stammt von ghostview ab, besitzt aber wegen der Xaw3d-Bibliothek eine schönere Benutzeroberfläche. In gv können Sie viele Operationen durchführen: Sie können die Ausrichtung und die Papiergröße eines Dokuments ändern, das Dokument skalieren oder die Kantenglättung (Anti-Aliasing) aktivieren. Fast jede Operation kann sowohl mit der Tastatur als auch mit der Maus durchgeführt werden. Installieren Sie das gv-Paket wie folgt: &prompt.root; pkg_add -r gv Benutzen Sie die Ports-Sammlung, wenn das Paket nicht zur Verfügung steht: &prompt.root; cd /usr/ports/print/gv &prompt.root; make install clean Xpdf Xpdf PDF anzeigen Ein schlankes und effizientes Programm zum Betrachten von PDF-Dateien ist Xpdf. Es benötigt wenige Ressourcen und ist sehr stabil. Da das Programm die Standard X-Zeichensätze benutzt, ist es nicht auf &motif; oder ein anderes X-Toolkit angewiesen. Das Xpdf-Paket können Sie mit dem folgenden Kommando installieren: &prompt.root; pkg_add -r xpdf Wenn das Paket nicht verfügbar ist, oder Sie lieber die Ports-Sammlung benutzen möchten, gehen Sie wie folgt vor: &prompt.root; cd /usr/ports/graphics/xpdf &prompt.root; make install clean Wenn Sie nach Abschluss der Installation Xpdf starten, öffnen Sie das Menü mit der rechten Maustaste. GQview GQview Mit GQview lassen sich Bilder verwalten. Unter anderem können Sie sich Bilder (auch auf dem ganzen Bildschirm) anschauen, ein externes Werkzeug aufrufen und eine Vorschau (thumbnail) erzeugen. Weiterhin können Sie automatisch ablaufende Präsentationen erstellen und grundlegende Dateioperationen durchführen, Bildersammlungen verwalten und doppelte Bilder aufspüren. GQview ist internationalisiert, das heißt es berücksichtigt die Spracheinstellungen des Systems. Wenn Sie das GQview-Paket installieren wollen, geben Sie das folgende Kommando ein: &prompt.root; pkg_add -r gqview Ist das Paket nicht erhältlich, oder wenn Sie die Ports-Sammlung bevorzugen, setzen Sie die folgenden Kommandos ab: &prompt.root; cd /usr/ports/graphics/gqview &prompt.root; make install clean Finanzsoftware Wenn Sie, warum auch immer, Ihre Finanzen mit einem FreeBSD Arbeitsplatz verwalten wollen, stehen Ihnen verschiedene Anwendungen zur Verfügung. Einige von ihnen unterstützen verbreitete Formate, darunter Dateiformate, die von Quicken oder Excel verwendet werden. Dieser Abschnitt behandelt die folgenden Anwendungen: Anwendung Ressourcenbedarf Installationsaufwand aus den Ports wichtige Abhängigkeiten GnuCash niedrig hoch GNOME Gnumeric niedrig hoch GNOME Abacus niedrig niedrig Tcl/Tk KMyMoney niedrig hoch KDE GnuCash GnuCash GnuCash ist Teil des GNOME-Projekts, dessen Ziel es ist, leicht zu bedienende und doch leistungsfähige Anwendungen zu erstellen. Mit GnuCash können Sie Ihre Einnahmen und Ausgaben, Ihre Bankkonten und Wertpapiere verwalten. Das Programm ist leicht zu bedienen und genügt dennoch hohen Ansprüchen. GnuCash stellt ein Register, ähnlich dem in einem Scheckheft und ein hierarchisches System von Konten zur Verfügung. Eine Transaktion kann in einzelne Teile aufgespaltet werden. GnuCash kann Quicken-Dateien (QIF) importieren und einbinden. Weiterhin unterstützt das Programm die meisten internationalen Formate für Zeitangaben und Währungen. Die Bedienung des Programms kann durch zahlreiche Tastenkombinationen und dem automatischen Vervollständigen von Eingaben beschleunigt werden. Das GnuCash-Paket installieren Sie wie folgt: &prompt.root; pkg_add -r gnucash Wenn das Paket nicht zur Verfügung steht, benutzen Sie die Ports-Sammlung: &prompt.root; cd /usr/ports/finance/gnucash &prompt.root; make install clean Gnumeric Gnumeric Tabellenkalkulation Gnumeric Gnumeric ist eine Tabellenkalkulation, die Teil der GNOME Benutzeroberfläche ist. Das Programm kann Eingaben anhand des Zellenformats oder einer Folge von Eingaben vervollständigen. Dateien verbreiteter Formate, wie die von Excel, Lotus 1-2-3 oder Quattro Pro lassen sich importieren. Grafiken erstellt Gnumeric mit dem Programm math/guppi. Gnumeric besitzt viele eingebaute Funktionen und Zellenformate (zum Beispiel die üblich verwendeten, wie Zahl, Währung, Datum oder Zeit). Installieren Sie das Gnumeric-Paket mit dem folgenden Kommando: &prompt.root; pkg_add -r gnumeric Wenn das Paket nicht zur Verfügung steht, benutzen Sie die Ports-Sammlung: &prompt.root; cd /usr/ports/math/gnumeric &prompt.root; make install clean Abacus Abacus Tabellenkalkulation Abacus Abacus ist eine kleine und leicht zu bedienende Tabellenkalkulation. Die vordefinierten Funktionen stammen aus verschiedenen Bereichen wie der Statistik, der Wirtschaft und der Mathematik. Das Programm kann Dateien im Excel Dateiformat importieren und exportieren sowie Ausgaben in &postscript; erzeugen. Installieren Sie das Abacus-Paket mit dem folgenden Kommando: &prompt.root; pkg_add -r abacus Wenn das Paket nicht zur Verfügung steht, benutzen Sie die Ports-Sammlung: &prompt.root; cd /usr/ports/deskutils/abacus &prompt.root; make install clean KMyMoney KMyMoney Tabellenkalkulation KMyMoney Bei KMyMoney handelt es sich ein Programm zur Verwaltung der persönlichen Finanzen, das unter KDE entwickelt wird. KMyMoney hat das Ziel, alle wichtigen Funktionen zu bieten, die auch von kommerziellen Programmen zur Verwaltung der persönlichen Finanzen unterstützt werden. Weiters zählen einfache Benutzung sowie korrekte doppelte Buchführung zu den herausragenden Fähigkeiten dieses Programms. KMyMoney unterstützt den Import von Datendateien im Format Quicken Interchange Format (QIF), kann Investionen verfolgen, unterstützt verschiedene Währungen und bietet umfangreiche Reportmöglichkeiten. OFX-Import wird über ein separates Plugin realisiert. Um KMyMoney über das &os;-Paketsystem zu installieren, geben Sie Folgendes ein: &prompt.root; pkg_add -r kmymoney2 Sollte das Paket nicht verfügbar sein, können Sie das Programm auch über die Ports-Sammlung installieren: &prompt.root; cd /usr/ports/finance/kmymoney2 &prompt.root; make install clean Zusammenfassung FreeBSD wird von Internet Service Providern wegen seiner Schnelligkeit und Stabilität eingesetzt, es ist aber auch zum Einrichten eines Arbeitsplatzes geeignet. Mit tausenden Anwendungen, die als Pakete oder Ports zur Verfügung stehen, können Sie sich einen Arbeitsplatz nach Ihren Wünschen einrichten. Die folgende Aufstellung fasst die in diesem Kapitel besprochenen Anwendungen zusammen: Anwendung Paket-Name Port-Name Opera opera www/opera Firefox firefox www/firefox KOffice koffice-kde3 editors/koffice-kde3 AbiWord abiword editors/abiword The GIMP gimp graphics/gimp OpenOffice.org openoffice - editors/openoffice-1.1 + editors/openoffice.org-3 &acrobat.reader; acroread - print/acroread7 + print/acroread8 gv gv print/gv Xpdf xpdf graphics/xpdf GQview gqview graphics/gqview GnuCash gnucash finance/gnucash Gnumeric gnumeric math/gnumeric Abacus abacus deskutils/abacus KMyMoney kmymoney2 finance/kmymoney2 diff --git a/de_DE.ISO8859-1/books/handbook/eresources/chapter.sgml b/de_DE.ISO8859-1/books/handbook/eresources/chapter.sgml index d4bc2de6e7..bdaf89038b 100644 --- a/de_DE.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -1,2151 +1,2156 @@ Ressourcen im Internet Gedruckte Medien können mit der schnellen Entwicklung von FreeBSD nicht Schritt halten. Elektronische Medien sind häufig die einzige Möglichkeit, über aktuelle Entwicklungen informiert zu sein. Da FreeBSD ein Projekt von Freiwilligen ist, gibt die Benutzergemeinde selbst auch technische Unterstützung. Die Benutzergemeinde erreichen Sie am besten über E-Mail, Internetforen oder Usenet-News. Die wichtigsten Wege, auf denen Sie die FreeBSD-Benutzergemeinde erreichen können, sind unten dargestellt. Wenn Sie weitere Ressourcen kennen, die hier fehlen, schicken Sie diese bitte an die Mailingliste des &a.doc;, damit sie hier aufgenommen werden können. Mailinglisten Die Mailinglisten sind der direkteste Weg, um Fragen an das gesamte &os; Publikum zu stellen oder eine technische Diskussion zu beginnen. Es existiert eine grosse Vielfalt von Listen mit einer Reihe von verschiedenen FreeBSD Themen. Wenn Sie ihre Fragen an die richtige Mailingliste richten können Sie viel eher mit einer passenden Antwort darauf rechnen. Die Chartas der verschiedenen Listen sind unten wiedergegeben. Bevor Sie sich einer Mailingliste anschließen oder E-Mails an eine Liste senden, lesen Sie bitte die Charta der Liste. Die meisten Mitglieder unserer Mailinglisten erhalten Hunderte E-Mails zum Thema FreeBSD pro Tag. Die Chartas und Regeln, die den Gebrauch der Listen beschreiben, garantieren die hohe Qualität der Listen. Die Listen würden ihren hohen Wert für das Projekt verlieren, wenn wir weniger Regeln aufstellen würden. Um zu testen, ob Sie eine Nachricht an eine &os;-Liste senden können, verwenden Sie bitte Die Liste &a.test.name;. Schicken Sie derartige Nachrichten bitte nicht an eine der anderen Listen. Wenn Sie Sich nicht sicher sind, auf welcher Liste Sie Ihre Frage stellen sollen, sollten Sie den Artikel How to get best results from the FreeBSD-questions mailing list lesen. Bevor Sie eine Nachricht an eine Mailingliste senden, sollten Sie die korrekte Nutzung der Mailinglisten erlernen. Dazu gehört auch das Vermeiden von sich häufig wiederholenden Diskussionen (lesen Sie deshalb zuerst die Mailing List Frequently Asked Questions). Alle Mailinglisten werden archiviert und können auf dem FreeBSD World Wide Web Server durchsucht werden. Das nach Schlüsselwörtern durchsuchbare Archiv bietet die hervorragende Möglichkeit, Antworten auf häufig gestellte Fragen zu finden. Nutzen Sie bitte diese Möglichkeit, bevor Sie Fragen auf einer Liste stellen. Beachten Sie auch, dass das zur Folge hat, dass die Nachrichten an die &os; Mailinglisten für die Ewigkeit erhalten bleiben. Wenn Sie am Schutz ihrer Privatsphähre interessiert sind, ziehen Sie die Verwendung einer Wegwerf-E-Mail-Adresse in Betracht und schreiben Sie nur solche Nachrichten, die für die Öffentlichkeit bestimmt sind. Beschreibung der Mailinglisten Allgemeine Listen: Jeder kann die folgenden allgemeinen Listen abonnieren (und ist dazu aufgefordert): Mailingliste Zweck &a.advocacy.name; Verbreitung von FreeBSD &a.announce.name; Wichtige Ereignisse und Meilensteine des Projekts &a.arch.name; Architektur und Design von FreeBSD &a.bugbusters.name; Diskussionen über die Pflege der FreeBSD Fehlerberichte-Datenbank und die dazu benutzten Werkzeuge &a.bugs.name; Fehlerberichte &a.chat.name; Nicht technische Themen, die die FreeBSD-Gemeinschaft betreffen &a.current.name; Gebrauch von &os.current; &a.isp.name; Für Internet-Service-Provider, die FreeBSD benutzen &a.jobs.name; Anstellung und Beratung im FreeBSD-Umfeld &a.policy.name; Grundsatzentscheidungen des FreeBSD-Core-Teams. Wenig Verkehr und nur zum Lesen &a.questions.name; Benutzerfragen und technische Unterstützung &a.security-notifications.name; Ankündigungen zum Thema Sicherheit &a.stable.name; Gebrauch von &os.stable; &a.test.name; Schicken Sie Testnachrichten an diese Liste anstelle der wirklichen Listen Technische Listen: Auf den folgenden Listen werden technische Diskussionen geführt. Bevor Sie eine der Listen abonnieren oder Nachrichten an sie schicken, lesen Sie sich bitte die Charta der Liste durch, da der Inhalt und Zweck dieser Listen genau festgelegt ist. Mailingliste Zweck &a.acpi.name; Entwicklung von ACPI &a.afs.name; Portierung von AFS nach FreeBSD &a.aic7xxx.name; Entwicklung von &adaptec; AIC 7xxx Treibern &a.alpha.name; Portierung von FreeBSD auf Alpha-Maschinen &a.amd64.name; Portierung von FreeBSD auf AMD64-Systeme &a.apache.name; Diskussion über Ports, die mit Apache zusammenhängen. &a.arm.name; Portierung von FreeBSD auf &arm;-Prozessoren &a.atm.name; Benutzung von ATM-Netzen mit FreeBSD &a.audit.name; Audit der FreeBSD-Quellen &a.binup.name; Design und Entwicklung eines Systems, das es erlaubt, ein FreeBSD-System mit binären Paketen zu aktualisieren &a.bluetooth.name; &bluetooth; unter FreeBSD verwenden &a.cluster.name; Benutzung von FreeBSD in einem Cluster &a.cvsweb.name; Pflege von CVSweb &a.database.name; Diskussion über Datenbanken und Datenbankprogrammierung unter FreeBSD &a.doc.name; Erstellen der FreeBSD-Dokumentation &a.drivers.name; Gerätetreiber für &os; schreiben &a.eclipse.name; Für FreeBSD-Anwender, die die Eclipse IDE, deren Werkzeuge, Anwendungen und Ports einsetzen &a.embedded.name; FreeBSD in eingebetteten Anwendungen einsetzen &a.emulation.name; Emulation anderer Systeme wie Linux, &ms-dos; oder &windows; &a.eol.name; Support für FreeBSD-bezogene Software, die vom FreeBSD Project offiziell nicht mehr unterstützt wird. &a.firewire.name; Technische Diskussion über &firewire; (iLink, IEEE 1394) &a.fs.name; Dateisysteme &a.gecko.name; Angelegenheiten zur Gecko Rendering Engine &a.geom.name; Diskussion über GEOM &a.gnome.name; Portierung von GNOME und GNOME-Anwendungen &a.hackers.name; Allgemeine technische Diskussionen &a.hardware.name; Allgemeine Diskussion über Hardware, auf der FreeBSD läuft &a.i18n.name; Internationalisierung von FreeBSD &a.ia32.name; FreeBSD für die IA-32 (&intel; x86) Plattform &a.ia64.name; Portierung von FreeBSD auf &intel;s neue IA64-Systeme &a.ipfw.name; Technische Diskussion über die Neubearbeitung der IP-Firewall Quellen &a.isdn.name; Für Entwickler des ISDN-Systems &a.java.name; Für &java; Entwickler und Leute, die &jdk;s nach FreeBSD portieren &a.kde.name; Portierung von KDE und KDE-Anwendungen &a.lfs.name; Portierung von LFS nach FreeBSD &a.libh.name; Das nächste Installations- und Paketsystem &a.mips.name; Portierung von FreeBSD zu &mips; &a.mobile.name; Diskussionen über mobiles Rechnen &a.mono.name; Mono und C# Anwendungen auf FreeBSD &a.mozilla.name; Portierung von Mozilla nach FreeBSD &a.multimedia.name; Multimedia Anwendungen &a.newbus.name; Technische Diskussionen über die Architektur von Bussen &a.net.name; Diskussion über Netzwerke und den TCP/IP Quellcode &a.openoffice.name; Portierung von OpenOffice.org und &staroffice; nach FreeBSD &a.performance.name; Fragen zur Optimierung der Leistung stark ausgelasteter Systeme &a.perl.name; Pflege der portierten Perl-Anwendungen. &a.pf.name; Diskussionen und Fragen zu packet filter als Firewallsystem. &a.platforms.name; Portierungen von FreeBSD auf nicht-&intel; Architekturen &a.ports.name; Diskussion über die Ports-Sammlung &a.ports-bugs.name; Diskussion über Fehler und PRs der Ports &a.ppc.name; Portierung von FreeBSD auf den &powerpc; &a.proliant.name; Technische Diskussionen zum Einsatz von FreeBSD auf der ProLiant-Serverplattform von HP. &a.python.name; FreeBSD-spezifische Diskussionen zu Python &a.qa.name; Diskussion über Qualitätssicherung, normalerweise kurz vor einem Release &a.rc.name; Diskussion über das rc.d-System sowie dessen Weiterentwicklung &a.realtime.name; Entwicklung von Echtzeiterweiterungen für FreeBSD &a.ruby.name; FreeBSD-spezifische Diskussionen zu Ruby &a.scsi.name; Diskussion über das SCSI-Subsystem &a.security.name; Sicherheitsthemen &a.small.name; Gebrauch von FreeBSD in eingebetteten Systemen (obsolet; verwenden Sie stattdessen &a.embedded.name;) &a.smp.name; Diskussionen über das Design von asymmetrischen und symmetrischen Mehrprozessor-Programmen &a.sparc.name; Portierung von FreeBSD auf &sparc; Systeme &a.standards.name; Konformität von FreeBSD mit den C99- und POSIX-Standards &a.sun4v.name; Portierung von FreeBSD auf &ultrasparc;-T1-basierte Systeme + + + &a.sysinstall.name; + &man.sysinstall.8; Entwicklung + &a.threads.name; Leichgewichtige Prozesse (Threads) in FreeBSD &a.testing.name; Leistungs- und Stabilitätstests von FreeBSD &a.tokenring.name; Token-Ring Unterstützung in FreeBSD &a.usb.name; USB-Unterstützung in FreeBSD &a.virtualization.name; Diskussion über verschiedene Virtualisierungsverfahren, die von &os; unterstützt werden &a.vuxml.name; Diskussion über die Infratruktur von VuXML &a.x11.name; Wartung und Unterstützung von X11 auf FreeBSD &a.xen.name; Diskussionen über die &os; Portierung auf &xen; - Implementierung und Verwendung Eingeschränkte Listen: Die folgenden Listen wenden sich an Zielgruppen mit speziellen Anforderungen und sind nicht für die Öffentlichkeit gedacht. Bevor Sie eine dieser Listen abonnieren, sollten Sie einige der technischen Listen abonniert haben, um mit den Umgangsformen vertraut zu sein. Mailingliste Zweck &a.hubs.name; Betrieb von FreeBSD-Spiegeln &a.usergroups.name; Koordination von Benutzergruppen &a.vendors.name; Koordination von Händlern vor einem Release &a.wip-status.name; Status von in Arbeit befindlichen &os;-Tätigkeiten &a.www.name; Betreuer von www.FreeBSD.org Zusammenfassungen: Alle eben aufgezählten Listen sind auch in zusammengefasster Form (digest) erhältlich. In den Einstellungen Ihres Accounts legen Sie fest, in welcher Form Sie die Listen empfangen. CVS & SVN Listen: Die folgenden Listen versenden die Log-Einträge zu Änderungen an verschiedenen Teilen des Quellbaums. Diese Listen sollen nur gelesen werden, schicken Sie bitte keine Nachrichten an eine der Listen. Mailingliste Teil des Quellbaums Beschreibung &a.cvsall.name; /usr/(CVSROOT|doc|ports) Alle Änderungen im Quellbaum (Obermenge der anderen Commit-Listen) &a.cvs-doc.name; /usr/(doc|www) Änderungen in den doc- und www Bäumen &a.cvs-ports.name; /usr/ports Änderungen im ports-Baum &a.cvs-projects.name; /usr/projects Änderungen im projects-Baum &a.cvs-src.name; /usr/src Änderungen im src-Baum (generiert aus den svn-zu-cvs Import-Commits &a.svn-src-all.name; /usr/src Änderungen im Subversion Repository (ausser für user und projects) &a.svn-src-head.name; /usr/src Änderungen im head Zweig des Subversion Repository (der &os;-CURRENT Zweig) &a.svn-src-projects.name; /usr/projects Änderungen im projects Bereich des src Subversion Repository &a.svn-src-release.name; /usr/src Änderungen im releases Bereich des src Subversion Repository &a.svn-src-releng.name; /usr/src Änderungen im releng Zweig des src Subversion Repository (der security / release engineering Zweige) &a.svn-src-stable.name; /usr/src Änderungen an allen stable Zweigen des src Subversion Repository &a.svn-src-stable-6.name; /usr/src Änderungen im stable/6 Zweig des src Subversion Repository &a.svn-src-stable-7.name; /usr/src Änderungen im stable/7 Zweig des src Subversion Repository &a.svn-src-stable-8.name; /usr/src Änderungen im stable/8 Zweig des src Subversion Repository &a.svn-src-stable-other.name; /usr/src Änderungen an älteren stable Zweigen des src Subversion Repository &a.svn-src-svnadmin.name; /usr/src Änderungen an den administrativen Skripten, hooks, and anderen Daten zur Konfiguration des src Subversion Repository &a.svn-src-user.name; /usr/src Änderungen am experimentellen user Bereich des src Subversion Repository &a.svn-src-vendor.name; /usr/src Änderungen am Herstellerbereich des src Subversion Repository Mailinglisten abonnieren Um eine Liste zu abonnieren, folgen Sie dem oben angegebenen Hyperlink der Liste oder Sie besuchen die Webseite &a.mailman.lists.link; und klicken dort auf die Liste, die Sie abonnieren wollen. Sie gelangen dann auf die Webseite der Liste, die weitere Anweisungen enthält. Um eine Nachricht an eine Mailingliste zu schicken, schreiben Sie einfach eine E-Mail an Liste@FreeBSD.org. Die E-Mail wird dann an alle Mitglieder der Mailingliste verteilt. Wenn Sie das Abonnement aufheben wollen, folgen Sie der URL, die am Ende jeder Mail der Liste angegeben ist. Sie können das Abonnement auch mit einer E-Mail an Liste-unsubscribe@FreeBSD.org aufheben. Verwenden Sie bitte die technischen Listen ausschließlich für technische Diskussionen. Wenn Sie nur an wichtigen Ankündigungen interessiert sind, abonnieren Sie die Mailingliste &a.announce;, auf der nur wenige Nachrichten versendet werden. Chartas der Mailinglisten Alle FreeBSD-Mailinglisten besitzen Grundregeln, die von jedem beachtet werden müssen. Für die ersten beiden Male, in denen ein Absender gegen diese Regeln verstößt, erhält er jeweils eine Warnung vom FreeBSD-Postmaster postmaster@FreeBSD.org. Ein dritter Verstoß gegen die Regeln führt dazu, dass der Absender in allen FreeBSD-Mailinglisten gesperrt wird und weitere Nachrichten von ihm nicht mehr angenommen werden. Wir bedauern sehr, dass wir solche Maßnahmen ergreifen müssen, aber heutzutage ist das Internet eine recht rauhe Umgebung, in der immer weniger Leute Rücksicht aufeinander nehmen. Die Regeln: Das Thema einer Nachricht soll der Charta der Liste, an die sie gesendet wird, entsprechen. Wenn Sie eine Nachricht an eine technische Liste schicken, sollte die Nachricht auch technische Inhalte haben. Fortwährendes Geschwätz oder Streit mindern den Wert der Liste für alle Mitglieder und wird nicht toleriert. Benutzen Sie &a.chat; für allgemeine Diskussionen über FreeBSD. Eine Nachricht sollte an nicht mehr als zwei Mailinglisten gesendet werden. Schicken Sie eine Nachricht nur dann an zwei Listen, wenn das wirklich notwendig ist. Viele Leute haben mehrere Mailinglisten abonniert und Nachrichten sollten nur zu ungewöhnlichen Kombinationen der Listen, wie -stable und -scsi, gesendet werden. Wenn Sie eine Nachricht erhalten, die im Cc-Feld mehrere Listen enthält, sollten Sie das Feld kürzen, bevor Sie eine Antwort darauf verschicken. Unabhängig von dem ursprünglichen Verteiler sind Sie für Ihre eigenen Mehrfach-Sendungen selbst verantwortlich. Persönliche Angriffe und Beschimpfungen sind in einer Diskussion nicht erlaubt. Dies gilt gleichermaßen für Benutzer wie Entwickler. Grobe Verletzungen der Netiquette, wie das Verschicken oder Zitieren von privater E-Mail ohne eine entsprechende Genehmigung, werden nicht gebilligt. Die Nachrichten werden aber nicht besonders auf Verletzungen der Netiquette untersucht. Es kann sein, dass eine Verletzung der Netiquette durchaus zu der Charta einer Liste passt, aber der Absender aufgrund der Verletzung eine Warnung erhält oder gesperrt wird. Werbung für Produkte oder Dienstleistungen, die nichts mit FreeBSD zu tun haben, sind verboten. Ist die Werbung als Spam verschickt worden, wird der Absender sofort gesperrt. Chartas einzelner Listen: &a.acpi.name; Die Entwicklung von ACPI und Energieverwaltungsfunktionen. &a.afs.name; Andrew File System Auf dieser Liste wird die Portierung des AFS von CMU/Transarc diskutiert. &a.announce.name; Wichtige Ereignisse und Meilensteine Diese Liste ist für Personen, die nur an den wenigen Ankündigungen wichtiger Ereignisse interessiert sind. Die Ankündigungen betreffen Schnappschüsse und Releases, neue Merkmale von FreeBSD und die Suche nach freiwilligen Mitarbeitern. Auf der Liste herrscht wenig Verkehr und sie wird streng moderiert. &a.arch.name; Architektur und Design von FreeBSD Auf dieser technischen Liste wird die FreeBSD-Architektur diskutiert. Beispiele für angemessene Themen sind: Wie das Bausystem zu verändern ist, damit verschiedene Läufe gleichzeitig möglich sind. Was am VFS geändert werden muss, damit Heidemann Schichten eingesetzt werden können. Wie die Schnittstelle der Gerätetreiber angepasst werden muss, damit derselbe Treiber auf verschiedenen Bussen und Architekturen eingesetzt werden kann. Wie ein Netzwerktreiber geschrieben wird. &a.audit.name; Source Code Audit Project Dies ist die Liste des FreeBSD-Source Code Audit Projects. Ursprünglich war vorgesehen, hier nur sicherheitsrelevante Änderungen zu diskutieren, doch ist die Charta auf alle Änderungen ausgedehnt worden. Zu dieser Liste werden viele Korrekturen gesandt, so dass sie für den normalen FreeBSD-Benutzer von wenig Wert ist. Diskussionen über Sicherheit, die sich nicht auf die Änderung von Quellcode beziehen, finden auf der Mailingliste &a.security; statt. Auf der anderen Seite sind aber alle Entwickler aufgefordert, ihre Korrekturen zur Überprüfung an diese Liste zu senden. Dies trifft besonders auf Änderungen zu, in denen ein Fehler die Integrität des Gesamtsystems gefährdet. &a.binup.name; FreeBSD Binary Update Project Auf dieser Liste wird das Design und die Implementierung von binup diskutiert. Weitere Themen sind Fehlerbehebungen, Fehlerberichte und Anfragen nach Neuerungen. Die CVS-Logmeldungen des Projekts werden ebenfalls auf diese Liste gesendet. &a.bluetooth.name; &bluetooth; unter FreeBSD Diese Liste diskutiert Probleme der Verwendung von &bluetooth; unter FreeBSD. Designprobleme, Implementierungsdetails, Patches, Fehler- und Statusberichte, Verbesserungsvorschläge sowie alle anderen mit &bluetooth; zusammenhängenden Themen werden hier behandelt. &a.bugbusters.name; Bearbeitung der Fehlerberichte Auf dieser Liste wird die Bearbeitung der Fehlerberichte (PR, engl. problem report) koordiniert. Sie dient dem Bugmeister und allen Leuten, die ein Interesse an der Datenbank der Fehlerberichte haben, als Diskussionsforum. Auf dieser Liste werden keine spezifischen Fehler, Fehlerbehebungen oder PRs diskutiert. &a.bugs.name; Fehlerberichte Auf dieser Liste werden Fehlerberichte gesammelt. Fehlerberichte sollten immer mit &man.send-pr.1; oder dem Web Formular erstellt werden. &a.chat.name; Nicht technische Themen, die die FreeBSD Gemeinschaft betreffen Auf dieser Liste werden nicht-technische soziale Themen diskutiert, die nicht auf die anderen Listen passen. Hier kann diskutiert werden, ob Jordan wie ein Frettchen aus einem Zeichentrickfilm aussieht oder nicht, ob grundsätzlich in Großbuchstaben geschrieben werden soll, wer zuviel Kaffee trinkt, wo das beste Bier gebraut wird und wer Bier in seinem Keller braut. Gelegentlich können auf den technischen Listen wichtige Ereignisse wie Feste, Hochzeiten oder Geburten angekündigt werden, aber nachfolgende Nachrichten sollten auf die Liste &a.chat; gesendet werden. &a.core.name; FreeBSD Core Team Dies ist eine interne Mailingliste des FreeBSD Core Teams. Wenn in einer wichtigen Angelegenheit, die FreeBSD betrifft, entschieden werden muss oder die Angelegenheit einer genauen Prüfung unterzogen werden muss, können Nachrichten an diese Liste gesendet werden. &a.current.name; Gebrauch von &os.current; Diese Mailingliste ist für die Benutzer von &os.current; eingerichtet. Auf ihr finden sich Ankündigungen über Besonderheiten von -CURRENT, von denen Benutzer betroffen sind. Sie enthält weiterhin Anweisungen, wie man ein System auf -CURRENT hält. Jeder, der ein -CURRENT System besitzt, muss diese Liste lesen. Die Liste ist nur für technische Inhalte bestimmt. &a.cvsweb.name; FreeBSD CVSweb Project Technische Diskussion über den Gebrauch, die Entwicklung und die Pflege von FreeBSD-CVSweb. &a.doc.name; Documentation Project Auf dieser Mailingliste werden Themen und Projekte diskutiert, die im Zusammenhang mit der Erstellung der FreeBSD Dokumentation stehen. The FreeBSD Documentation Project besteht aus den Mitgliedern dieser Liste. Diese Liste steht jedem offen, Sie sind herzlich eingeladen teilzunehmen und mitzuhelfen. &a.drivers.name; Gerätetreiber für &os; schreiben Ein Forum für technische Diskussionen über das Schreiben von Gerätetreibern für &os;. Daher werden hier vor allem Fragen behandelt, die sich um das Schreiben von Treibern, die die APIs des Kernels nutzen, drehen. &a.eclipse.name; Für FreeBSD-Anwender, die die Eclipse IDE deren Werkzeuge, Anwendungen und Ports einsetzen Das Ziel dieser Liste ist es, Unterstützung für all jene zu bieten, die mit der Installation, Verwendung, Entwicklung und Wartung der Eclipse-IDE sowie deren Werkzeugen und Anwendungen unter &os; zu tun haben. Außerdem wird Hilfe bei der Portierung der IDE und deren Plugins auf &os; geboten. Zusätzlich soll diese Liste einen Informationsaustausch zwischen der Eclipse- und der &os;-Gemeinde ermöglichen, von dem beide Seiten profitieren können. Obwohl sich diese Liste auf die Anforderungen von Anwendern konzentriert, möchte sie auch Entwickler unterstützen, die an der Entwicklung von &os;-spezifischen Anwendungen unter Nutzung des Eclipse-Frameworks arbeiten. &a.embedded.name; FreeBSD in eingebetteten Anwendungen einsetzen Diese Liste diskutiert Themen im Zusammenhang mit dem Einsatz von ungewöhnlich kleinen und eingebettenen FreeBSD-Installationen. Auf dieser Liste werden ausschließlich technische Diskussionen geführt. Unter eingebetteten Systemen versteht diese Liste Systeme, bei denen es sich nicht um Desktopsysteme handelt, und die in der Regel nur einem einzigen Zweck dienen (im Gegensatz zu Desktopsystemen, die für die Bewältigung verschiedenster Aufgaben geeignet sind). In die Gruppe der eingebetteten Systeme gehören beispielsweise Telephone, Netzwerkgeräte wie Router, Switche oder PBX-Systeme, PDAs, Verkaufsautomaten und andere mehr. &a.emulation.name; Emulation anderer Systeme wie Linux, &ms-dos; oder &windows; Hier werden technische Diskussionen zum Einsatz von Programmen, die für andere Betriebssysteme geschrieben wurden, geführt. &a.eol.name; Support für FreeBSD-bezogene Software, die vom FreeBSD Project offiziell nicht mehr unterstützt wird. Diese Liste ist für all jene interessant, die Unterstützung für vom FreeBSD Project offiziell nicht mehr (in Form von Security Advisories oder Patches) unterstützte Programme benötigen oder anbieten wollen. &a.firewire.name; &firewire; (iLink, IEEE 1394) Auf dieser Liste wird das Design und die Implementierung eines &firewire;-Subsystems (auch IEEE 1394 oder iLink) für FreeBSD diskutiert. Relevante Themen sind die Standards, Busse und ihre Protokolle, sowie Adapter, Karten und Chipsätze. Des Weiteren die Architektur und der Quellcode, die nötig sind, diese Geräte zu unterstützen. &a.fs.name; Dateisysteme Diskussionen über FreeBSD-Dateisysteme. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.gecko.name; Angelegenheiten zur Gecko Rendering Engine Dies ist ein Forum über Gecko-Anwendungen, die &os; verwenden. Die Diskussion dreht sich um die Portierung von Gecko-Anwendungen, deren Installation, die Entwicklung sowie deren Unterstützung innerhalb von &os;. &a.geom.name; GEOM Diskussion über GEOM und verwandte Implementierungen. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.gnome.name; GNOME Diskussionen über die grafische Benutzeroberfläche GNOME. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.ipfw.name; IP Firewall Diskussionen über eine Neubearbeitung des IP-Firewall Quelltexts in FreeBSD. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.ia64.name; Portierung von FreeBSD auf die IA64-Plattform Dies ist eine technische Liste für diejenigen, die FreeBSD auf die IA-64 Plattform von &intel; portieren. Themen sind die Probleme bei der Portierung und deren Lösung. Interessierte, die der Diskussion folgen wollen, sind ebenfalls willkommen. &a.isdn.name; ISDN Subsystem Mailingliste für die Entwickler des ISDN Subsystems von FreeBSD. &a.java.name; &java; Entwicklung Mailingliste, auf der die Entwicklung von &java; Anwendungen für FreeBSD sowie die Portierung und Pflege von &jdk;s diskutiert wird. &a.jobs.name; Stellenangebote und Stellengesuche In diesem Forum können Sie Stellenangebote und Stellengesuche, die mit &os; zu tun haben, aufgeben. Wenn Sie beispielsweise eine Beschäftigung im &os;-Umfeld suchen oder eine freie Stelle haben, die mit &os; zu tun hat, ist dies der richtige Ort. Diese Mailingliste ist nicht der Ort, um über allgemeine Beschäftigungsprobleme zu diskutieren; dazu gibt es anderswo geeignete Foren. Beachten Sie bitte, dass diese Liste, wie die anderen FreeBSD.org-Listen, weltweit gelesen wird. Geben Sie daher bitte den Arbeitsort genau an. Geben Sie bitte auch an, ob Telearbeit möglich ist und ob Hilfen für einen Umzug angeboten werden. Benutzen Sie in der E-Mail bitte nur offene Formate – vorzugsweise nur das Textformat. Andere Formate, wie PDF oder HTML, werden von den Lesern akzeptiert. Nicht offene Formate wie µsoft; Word (.doc) werden vom Server der Liste abgelehnt. &a.hackers.name; Technische Diskussionen Dies ist ein Forum für technische Diskussionen über FreeBSD. Leute, die aktiv an FreeBSD arbeiten, können hier Probleme und deren Lösungen diskutieren. Interessierte, die den Diskussionen folgen wollen, steht die Liste ebenfalls offen. Auf dieser Liste finden nur technische Diskussionen statt. &a.hardware.name; Allgemeine Diskussionen über Hardware Allgemeine Diskussionen über die Hardware, auf der FreeBSD läuft: Probleme und Ratschläge welche Hardware man kaufen sollte und welche nicht. &a.hubs.name; FreeBSD-Spiegel Ankündigungen und Diskussionsforum für Leute, die FreeBSD-Spiegel betreiben. &a.isp.name; Themen für Internet Service Provider Diese Liste ist für Internet Service Provider (ISP), die FreeBSD benutzen. Auf dieser Liste finden nur technische Diskussionen statt. &a.mono.name; Mono und C# Anwendungen auf FreeBSD Diese Liste beinhaltet Diskussionen über das Mono Entwicklungsframework auf &os;. Dies ist eine technische Mailingliste. Es ist für Personen gedacht, die aktiv an der Portierung von Mono oder C# Anwendungen auf &os; sind, um Probleme oder alternative Lösungen zu beratschlagen. Personen die der technischen Diskussion folgen möchten sind ebenso willkommen. &a.kde.name; KDE Diskussionen über KDE auf FreeBSD-Systemen. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.openoffice.name; OpenOffice.org Portierung und Pflege von OpenOffice.org und &staroffice;. &a.performance.name; Diskussionsforum mit dem Ziel, die Leistung von FreeBSD zu verbessern. Auf dieser Liste diskutieren Hacker, Systemadministratoren und andere Interessierte die Leistung von FreeBSD. Zulässige Themen sind beispielsweise Systeme unter hoher Last, Systeme mit Leistungsproblemen oder Systeme, die Leistungsgrenzen von FreeBSD überwinden. Jeder, der mithelfen will, die Leistung von FreeBSD zu verbessern, sollte diese Liste abonnieren. Die Liste ist technisch anspruchsvoll und geeignet für erfahrene FreeBSD-Benutzer, Hacker oder Administratoren, die FreeBSD schnell, robust und skalierbar halten wollen. Auf der Liste werden Beiträge gesammelt oder Fragen nach ungelösten Problemen beantwortet. Sie ist kein Ersatz für das gründliche Studium der Dokumentation. &a.pf.name; Diskussionen und Fragen zu packet filter als Firewallsystem. FreeBSD-spezische Diskussionen zur Benutzung von packet filter (pf) als Firewallsystem. Sowohl technische Diskussionen als auch Anwenderfragen sind auf dieser Liste willkommen. Fragen zum ALTQ QoS Framework können ebenfalls gestellt werden. &a.platforms.name; Portierung auf nicht-&intel; Plattformen Plattformübergreifende Themen und Vorschläge für die Portierung auf nicht-&intel; Plattformen. Auf dieser Liste finden nur technische Diskussionen statt. &a.policy.name; Grundsatzentscheidungen des Core Teams Diese Mailingliste ist für Grundsatzentscheidungen des FreeBSD-Core-Teams. Sie trägt wenige Nachrichten und ist nur zum Lesen gedacht. &a.ports.name; Diskussion über die Ports-Sammlung Diskussionen über die FreeBSD-Ports-Sammlung und die Infrastruktur der Sammlung. Die Liste dient auch der allgemeinen Koordination der Dinge, die die Ports-Sammlung betreffen. Auf dieser Liste finden nur technische Diskussionen statt. &a.ports-bugs.name; Diskussion über Fehler in den Ports Diskussion über Fehler in der Ports-Sammlung (/usr/ports), neue Ports oder Änderungen an bestehenden Ports. Auf dieser Liste finden nur technische Diskussionen statt. &a.proliant.name; Technische Diskussionen zum Einsatz von FreeBSD auf der ProLiant-Serverplattform von HP Diese Mailingliste bietet technische Diskussionen zum Einsatz von FreeBSD auf der ProLiant-Serverplattform von HP, darunter Fragen zu ProLiant-spezifischen Treibern, Konfigurationswerkzeugen sowie BIOS-Aktualisierungen. Daher ist sie die erste Anlaufstelle, um die Module hpasmd, hpasmcli, sowie hpacucli zu diskutieren. &a.python.name; Python unter FreeBSD Diese technische Liste dient der Verbesserung der Python-Unterstützung unter FreeBSD. Sie wird von Personen gelesen, die an der Portierung von Python, von Python-Modulen Dritter und von Zope nach FreeBSD arbeiten. Personen, die diese technischen Diskussion verfolgen wollen, sind ebenfalls willkommen. &a.questions.name; Benutzerfragen Auf dieser Mailingliste können Fragen zu FreeBSD gestellt werden. Fragen Sie bitte nicht nach Anleitungen, wenn Sie nicht sicher sind, dass Ihre Frage wirklich technischer Natur ist. &a.ruby.name; Ruby unter FreeBSD Diese technische Liste dient der Verbesserung der Ruby-Unterstützung unter FreeBSD. Sie wird von Personen gelesen, die an der Portierung von Ruby, von Bibliotheken Dritter und Frameworks arbeiten. Personen, die diese technischen Diskussionen verfolgen wollen, sind ebenfalls willkommen. &a.scsi.name; SCSI Subsystem Diese Mailingliste ist für die Entwickler des SCSI Subsystems von FreeBSD. Auf dieser Liste finden nur technische Diskussionen statt. &a.security.name; Sicherheitsthemen Sicherheitsthemen, die FreeBSD betreffen, wie DES, Kerberos, bekannte Sicherheitslöcher und Fehlerbehebungen. Stellen Sie bitte auf dieser Liste keine allgemeinen Fragen zum Thema Sicherheit. Willkommen sind allerdings Beiträge zur FAQ, das heißt eine Frage mit der passenden Antwort. Auf dieser Liste finden nur technische Diskussionen statt. &a.security-notifications.name; Ankündigungen zum Thema Sicherheit Ankündigungen über Sicherheitsprobleme von FreeBSD und deren Behebungen. Diese Liste ist kein Diskussionsforum, benutzen Sie &a.security;, um Sicherheitsthemen zu diskutieren. &a.small.name; Gebrauch von FreeBSD in eingebetteten Systemen. Diese Liste für ungewöhnlich kleine FreeBSD Installation oder den Einsatz von FreeBSD in eingebetteten Systemen gedacht. Auf dieser Liste finden nur technische Diskussionen statt. Diese Liste wurde durch &a.embedded.name; ersetzt. &a.stable.name; Gebrauch von &os.stable;. Diese Mailingliste ist für die Benutzer von &os.stable; eingerichtet. Auf ihr finden sich Ankündigungen über Besonderheiten von -STABLE, von denen Benutzer betroffen sind. Sie enthält weiterhin Anweisungen, wie man ein System auf -STABLE hält. Jeder, der ein -STABLE System besitzt, muss diese Liste lesen. Die Liste ist nur für technische Inhalte bestimmt. &a.standards.name; Konformität von FreeBSD mit den C99- und &posix; Standards Dieses Forum ist für technische Diskussionen über die Konformität von FreeBSD mit den C99- und POSIX-Standards. &a.usb.name; USB-Unterstützung in &os;. Auf dieser Liste finden nur technische Diskussionen statt. &a.usergroups.name; Koordination von Benutzergruppen Diese Liste ist für Koordinatoren lokaler Benutzergruppen und einem ausgesuchten Mitglied des Core Teams eingerichtet worden. Der Inhalt sollte Inhalte von Treffen und die Koordination von Projekten mehrerer Benutzergruppen beschränkt sein. &a.vendors.name; Koordination von Händlern Koordination zwischen dem FreeBSD Project und Händlern, die Soft- und Hardware für FreeBSD verkaufen. &a.virtualization.name; Diskussion über verschiedene Virtualisierungsverfahren, die von &os; unterstützt werden Eine Liste, auf der die verschiedenen Virtualisierungsverfahren, die von &os; unterstützt werden, diskutiert werden. Auf der einen Seite liegt der Fokus auf der Implementierung der zugrundeliegenden Funktionalitäten, ebenso wie das Hinzufügen neuer Eigenschaften. Auf der anderen Seite haben die Benutzer ein Forum, um Fragen bei Problemen zu stellen oder um ihre Anwendungsfälle zu besprechen. &a.wip-status.name; Status von in Arbeit befindlichen &os;-Tätigkeiten Diese Mailingliste kann dazu verwendet werden, eigene Kreationen und deren Fortschritt von &os;-verwandten Tätigkeiten anzukündigen. Die Nachrichten werden moderiert. Es wird vorgeschlagen, die Nachricht "An:" eine mehr themenverwandte &os;-Liste zu senden und diese Liste nur in Blindkopie zu setzen. Auf diese Weise kann ihre in Arbeit befindliche Tätigkeit auch auf der themenverwandten Liste diskutiert werden, da auf dieser Liste keine Diskussionen erlaubt sind. Sehen Sie sich das Archiv der Liste für passende Nachrichten an. Redaktionelle Auszüge der Nachrichten an diese Liste werden eventuell alle paar Monate auf die &os; Webseite als Teil der Statusberichte gestellt. Weitere Beispiele und zurückliegende Berichte können Sie auch dort finden. &a.xen.name; Diskussionen über die &os; Portierung auf &xen; - Implementierung und Verwendung Eine Liste, die die &os; Portierung auf &xen; behandelt. Das erwartete Nachrichtenaufkommen ist klein genug, so dass es als Forum für sowohl technische Diskussionen über die Implementierung und Entwurfsdetails, als auch administrative Verteilaspekte ausgelegt ist. Filter der Mailinglisten Um die Verbreitung von Spam, Viren und anderen nicht erwünschten E-Mails zu verhindern, werden auf den &os;-Mailinglisten Filter eingesetzt. Dieser Abschnitt beschreibt nur einen Teil der zum Schutz der Listen eingesetzten Filter. Auf den Mailinglisten sind nur die unten aufgeführten Anhänge erlaubt. Anhänge mit einem anderen MIME-Typ werden entfernt, bevor eine E-Mail an eine Liste verteilt wird. application/octet-stream application/pdf application/pgp-signature application/x-pkcs7-signature message/rfc822 multipart/alternative multipart/related multipart/signed text/html text/plain text/x-diff text/x-patch Einige Mailinglisten erlauben vielleicht Anhänge mit anderem MIME-Typ. Für die meisten Mailinglisten sollte die obige Aufzählung aber richtig sein. Wenn eine E-Mail sowohl aus einer HTML-Version wie auch aus einer Text-Version besteht, wird die HTML-Version entfernt. Wenn eine E-Mail nur im HTML-Format versendet wurde, wird sie in reinen Text umgewandelt. Usenet-News Neben den Gruppen, die sich ausschließlich mit BSD beschäftigen, gibt es viele weitere in denen über FreeBSD diskutiert wird, oder die für FreeBSD-Benutzer wichtig sind. Warren Toomey wkt@cs.adfa.edu.au stellte großzügig suchbare Archive einiger dieser Gruppen bereit. BSD spezifische Gruppen comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (deutsch) fr.comp.os.bsd (französisch) it.comp.os.bsd (italienisch) tw.bbs.comp.386bsd (Traditionelles Chinesisch) Weitere UNIX Gruppen comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World Wide Web Server Foren, Blogs und soziale Netzwerke Die &os; Foren dienen als webbasiertes Diskussionsforum für Fragen und technische Diskussionen zu &os;. Planet FreeBSD bietet einen gesammelten Feed aus dutzenden von Blogs, die von den &os; Entwicklern geschrieben werden. Viele Entwickler nutzen dies, um schnell Aufzeichnungen darüber zu veröffentlichen, woran sie gerade arbeiten, welche neuen Erweiterungen es gibt und andere Arbeiten, die gerade im Gange sind. Der BSDConferences YouTube-Kanal beinhaltet eine Sammlung von qualitativ hochwertigen Videos von BSD Konferenzen aus der ganzen Welt. Dies ist eine ausgezeichnete Art und Weise, den Entwicklern beim Präsentieren von neuen Arbeiten an FreeBSD zuzuschauen. Official Mirrors &chap.eresources.www.inc; E-Mail Adressen Die folgenden Benutzergruppen stellen ihren Mitgliedern für die Arbeit an FreeBSD E-Mail-Adressen zur Verfügung. Der aufgeführte Administrator behält sich das Recht vor, die Adresse zu sperren, wenn sie missbraucht wird. Domain Angebot Benutzergruppe Administrator ukug.uk.FreeBSD.org nur zum Weiterleiten ukfreebsd@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org diff --git a/de_DE.ISO8859-1/books/handbook/mac/chapter.sgml b/de_DE.ISO8859-1/books/handbook/mac/chapter.sgml index 73e1815a9c..71d73ad6a6 100644 --- a/de_DE.ISO8859-1/books/handbook/mac/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/mac/chapter.sgml @@ -1,31 +1,2206 @@ + + + + Tom + Rhodes + Written by + + + + + Benjamin + Lukas + Übersetzt von + + + - Mandatory Access Control (noch nicht übersetzt) + Verbindliche Zugriffskontrolle - Dieses Kapitel ist noch nicht übersetzt. - Lesen Sie bitte - das Original in englischer Sprache. Wenn Sie helfen - wollen, dieses Kapitel zu übersetzen, senden Sie bitte - eine E-Mail an die Mailingliste &a.de.translators;. + + Übersicht + MAC + + Mandatory Access Control + MAC + + + In &os; 5.X wurden neue Sicherheits-Erweiterungen + verfügbar, die aus dem TrustedBSD-Projekt übernommen wurden + und auf dem Entwurf &posix;.1e basieren. Die beiden + bedeutendsten neuen Sicherheits-Mechanismen sind Berechtigungslisten + (Access Control Lists, ACL) und die verbindliche + Zugriffskontrolle (Mandatory Access Control, MAC). + Durch die MAC können Module geladen werden, die neue + Sicherheitsrichtlinien bereitstellen. Mit Hilfe einiger Module kann + beispielsweise ein eng umgrenzter Bereich des Betriebssystems gesichert + werden, indem die Sicherheitsfunktionen spezieller Dienste + unterstützt bzw. verstärkt werden. Andere Module wiederum + betreffen in ihrer Funktion das gesamte System - alle vorhandenen + Subjekte und Objekte. Das "Verbindliche" in der Namensgebung + erwächst aus dem Fakt, dass die Kontrolle allein Administratoren + und dem System obliegt und nicht dem Ermessen der Nutzer, wie es mit + Hilfe der benutzerbestimmbaren Zugriffskontrolle (Discrectionary Access + Control / DAC), dem Zugriffstandard für Dateien, + gar der System V IPC in &os;, normalerweise umgesetzt + wird. + + Dieses Kapitel wird sich auf die Grundstruktur der Verbindlichen + Zugriffskontrolle und eine Auswahl der Module, die verschiedenste + Sicherheitsfunktionen zur Verfügung stellen, konzentrieren. + + Beim Durcharbeiten dieses Kapitels erfahren Sie: + + + + Welche MAC Module für + Sicherheitsrichtlinien derzeit in &os; eingebettet sind und wie die + entsprechenden Mechanismen funktionieren. + + + + Was die einzelnen MAC Module an Funktionen + realisieren und auch, was der Unterschied zwischen einer Richtlinie, + die mit Labels arbeitet, und einer, die + ohne Labels arbeitet, ist. + + + + Wie Sie die MAC in ein System einbetten und + effizient einrichten. + + + + Wie die verschiedenen Richtlinienmodule einer MAC konfiguriert + werden. + + + + Wie mit einer MAC und den gezeigten Beispielen + eine sicherere Umgebung erstellt werden kann. + + + + Wie die Konfiguration einer MAC auf korrekte + Einrichtung getestet wird. + + + + Vor dem Lesen dieses Kapitels sollten Sie bereits: + + + + Grundzüge von &unix; und &os; verstanden haben. + (). + + + Mit den Grundzügen der Kernelkonfiguration und -kompilierung + vertraut sein (). + + + + Einige Vorkenntnisse über Sicherheitskonzepte im Allgemeinen + und deren Umsetzung in &os; im Besonderen mitbringen (). + + + + + Der unsachgemäße Gebrauch der in diesem Kapitel + enthaltenen Informationen kann den Verlust des Systemzugriffs, + Ärger mit Nutzern oder die Unfähigkeit, grundlegende + Funktionen des X-Windows-Systems zu nutzen, verursachen. Wichtiger + noch ist, dass man sich nicht allein auf die MAC + verlassen sollte, um ein System zu sichern. Die MAC + verbessert und ergänzt lediglich die schon existierenden + Sicherheits-Richtlinien - ohne eine gründliche und fundierte + Sicherheitspraxis und regelmäßige Sicherheitsprüfungen + wird Ihr System nie vollständig sicher sein. + + Außerdem sollte angemerkt werden, dass die Beispiele + in diesem Kapitel auch genau dasselbe sein sollen, nämlich + Beispiele. Es wird nicht empfohlen, diese bestimmten Beispiele + auf einem Arbeitssystem umzusetzen. Das Einarbeiten der + verschiedenen Sicherheitsmodule erfordert eine Menge Denkarbeit + und viele Tests. Jemand, der nicht versteht, wie diese Module + funktionieren, kann sich schnell darin wiederfinden, dass er + (oder sie) das ganze System durchforsten und viele Dateien und + Verzeichnisse neu konfigurieren muß. + + + + Was in diesem Kapitel nicht behandelt wird + + Dieses Kapitel behandelt einen großen Teil + sicherheitsrelevanter Themen, bezogen auf die Verbindliche + Zugriffskontrolle (MAC). Die gegenwärtige + Entwicklung neuer MAC Module ist nicht + abgedeckt. Einige weitere Module, die im MAC Framework enthalten sind, + haben besondere Charakteristika, die zum Testen und Entwickeln neuer + Module gedacht sind. Dies sind unter anderem &man.mac.test.4;, + &man.mac.stub.4; und &man.mac.none.4;. Für weitere Informationen + zu diesen Modulen und den entsprechend angebotenen Funktionen lesen Sie + bitte die Manpages. + + + + + Schlüsselbegriffe + + Bevor Sie weiterlesen, müssen noch einige Schlüsselbegriffe + geklärt werden. Dadurch soll jegliche auftretende Verwirrung von + vornherein beseitigt und die plötzliche Einführung neuer + Begriffe und Informationen vermieden werden. + + + + Verbund: Ein Verbund ist ist ein Satz von + Programmen und Daten, die speziell und zusammen abgeschottet wurden, + um Nutzern Zugriff auf diese ausgewiesenen Systembereiche zu + gewähren. Man kann sagen, ein solcher Verbund ist eine + Gruppierung, ähnlich einer Arbeitsgruppe, einer Abteilung, einem + Projekt oder einem Thema. Durch die Nutzung von Verbünden + (compartments) kann man Sicherheitsrichtlinien + erstellen, die alles notwendige Wissen und alle Werkzeuge + zusammenfassen. + + + + Hochwassermarkierung: Eine solche Richtlinie + erlaubt die Erhöhung der Sicherheitsstufe in Abhängigkeit + der Klassifikation der gesuchten bzw. bereitzustellenden Information. + Normalerweise wird nach Abschluss des Prozesses die + ursprüngliche Sicherheitsstufe wieder hergestellt. Derzeit + enthält die MAC Grundstruktur keine + Möglichkeit, eine solche Richtlinie umzusetzen, der + Vollständigkeit halber ist die Definition hier jedoch + aufgeführt. + + + + Integrität: Das Schlüsselkonzept + zur Klassifizierung der Vertraulichkeit von Daten nennt man + Integrität. Je weiter die Integrität erhöht wird, umso + mehr kann man den entsprechenden Daten vertrauen. + + + + Label: Ein Label ist ein Sicherheitsmerkmal, + welches mit Dateien, Verzeichnissen oder anderen Elementen im System + verbunden wird. Man sollte es wie einen Vertraulichkeitsstempel + auffassen, der Dateien angehört wie beispielsweise die + Zugriffszeit, das Erstellungsdatum oder auch der Name; sobald Dateien + derart gekennzeichnet werden, bezeichnen diese Label die + sicherheitsrelevanten Eigenschaften. Zugriff ist nur noch dann + möglich, wenn das zugreifende Subjekt eine korrespondierende + Kennzeichnung trägt. Die Bedeutung und Verarbeitung der + Label-Werte ist von der Einrichtung der Richtlinie abhängig: + Während einige Richtlinien das Label zum Kennzeichnen der + Vertraulichkeit oder Geheimhaltungsstufe eines Objekts nutzen, + können andere Richtlinien an derselben Stelle Zugriffsregeln + festschreiben. + + + + Level: Eine erhöhte oder verminderte + Einstellung eines Sicherheitsmerkmals. Wenn das Level erhöht + wird, wird auch die ensprechende Sicherheitsstufe angehoben. + + + + Niedrigwassermarkierung: Eine solche + Richtlinie erlaubt das Herabstufen des Sicherheitslevels, um weniger + sensible Daten verfügbar zu machen. In die meisten Fällen + wird das ursprüngliche Sicherheitslevel des Nutzers + wiederhergestellt, sobald der Vorgang abgeschlossen ist. Das einzige + Modul in &os;, welches von dieser Richtlinie Gebrauch macht, ist + &man.mac.lomac.4;. + + + + Multilabel: Die Eigenschaft + ist eine Dateisystemoption, die entweder + im Einzelbenutzermodus mit Hilfe des Werkzeugs &man.tunefs.8;, + während des Bootvorgangs in der Datei &man.fstab.5; oder aber + beim Erstellen einen neues Dateisystems aktiviert werden kann. Diese + Option erlaubt einem Administrator, verschiedenen Objekten + unterschiedliche Labels zuzuordnen - kann jedoch nur zusammen mit + Modulen angewendet werden, die auch tatsächlich mit Labels + arbeiten. + + + + Objekt: Ein Objekt oder auch Systemobjekt + ist theoretisch eine Einheit, durch welche Information fließt, + und zwar unter der Lenkung eines Subjektes. + Praktisch schliesst diese Definition Verzeichnisse, Dateien, Felder, + Bildschirme, Tastaturen, Speicher, Bandlaufwerke, Drucker und + jegliche anderen Datenspeicher- oder -verarbeitungsgeräte ein. + Im Prinzip ist ein Objekt ein Datenkontainer oder eine + Systemressource - Zugriff auf ein Objekt + bedeutet, auf Daten zuzugreifen. + + + + Richtlinie: Eine Sammlung von Regeln, die + definiert, wie Zielvorgaben umgesetzt werden, nennt man Richtlinie. + Eine Richtlinie dokumentiert normalerweise, wie + mit bestimmten Elementen umgegangen wird. Dieses Kapitel faßt + den Begriff in diesem Kontext als + Sicherheitsrichtlinie auf; als eine Sammlung von + Regeln, die den Fluß von Daten und Informationen kontrolliert + und die gleichzeitig definiert, wer auf diese Daten und Informationen + zugreifen darf. + + + + Anfälligkeit: Dieser Begriff wird + normalerweise verwendet, wenn man über MLS + (Multi Level Security) spricht. Das Anfälligkeits-Level + beschreibt, wie wichtig oder geheim die Daten sein sollen. Um so + höher das Anfälligkeits-Level, um so wichtiger die + Geheimhaltung bzw. Vertraulichkeit der Daten. + + + + Einzel-Label: Von einem Einzel-Label spricht + man, wenn für ein ganzes Dateisystem lediglich ein einziges + Label verwendet wird, um Zugriffskontrolle über den gesamten + Datenfluss zu erzwingen. Sobald diese Option verwendet wird - und das + ist zu jeder Zeit, wenn die Option + nicht explizit gesetzt wurde - sind alle Dateien und Verzeichnisse + mit dem gleichen Label gekennzeichnet. + + + + Subjekt: Ein Subjekt ist jedwede Einheit, + die Information in Fluss zwischen Objekten bringt: Zum Beispiel ein + Nutzer, ein Nutzerprozessor, ein Systemprozeß usw. In &os; + handelt es sich meistens um einen Thread, der als Prozeß im + Namen eines Nutzers arbeitet. + + + + + + Erläuterung + + Mit all diesen neuen Begriffen im Kopf können wir nun + überlegen, wie die Möglichkeiten der verbindlichen + Zugriffskontrolle (MAC) die Sicherheit eines + Betriebssystems als Ganzes erweitern. Die verschiedenen Module, die + durch die MAC bereitgestellt werden, können + verwendet werden, um das Netzwerk oder Dateisysteme zu schützen, + Nutzern den Zugang zu bestimmten Ports oder Sockets zu verbieten und + vieles mehr. Die vielleicht beste Weise, die Module zu verwenden, ist, + sie miteinander zu kombinieren, indem mehrere + Sicherheitsrichtlinienmodule gleichzeitig eine mehrschichtige + Sicherheitsumgebung schaffen. Das ist etwas anderes als singuläre + Richtlinien wie zum Beispiel die Firewall, die typischerweise Elemente + eines Systems stabilisiert, das nur für einen speziellen Zweck + verwendet wird. Der Verwaltungsmehraufwand ist jedoch von Nachteil, zum + Beispiel durch die Verwendung von mehreren Labels oder dem + eigenhändigen Erlauben von Netzwerkzugriffen für jeden + einzelnen Nutzer. + + Solche Nachteile sind allerdings gering im Vergleich zum bleibenden + Effekt der erstellten Struktur. Die Möglichkeit zum Beispiel, + für konkrete Anwendungen genau die passenden Richtlinien + auszuwählen und einzurichten, senkt gleichzeitig die Arbeitskosten. + Wenn man unnötige Richtlinien aussortiert, kann man die + Gesamtleistung des Systems genauso steigern wie auch eine höhere + Anpassungsfähigkeit gewährleisten. Eine gute Umsetzung der + MAC beinhaltet eine Prüfung der gesamten + Sicherheitsanforderungen und einen wirksamen Einsatz der verschiedenen + Module. + + Ein System, auf dem eine MAC verwendet wird, + muß zumindest garantieren, dass einem Nutzer nicht gestattet wird, + Sicherheitsmerkmale nach eigenem Ermessen zu verändern; dass + Arbeitswerkzeuge, Programme und Skripte, innerhalb der + Beschränkungen arbeiten können, welche die Zugriffsregeln der + ausgewählten Module dem System auferlegen; und dass die volle + Kontrolle über die Regeln der MAC beim + Administrator ist und bleibt. + + Es ist die einsame Pflicht des zuständigen Administrators, die + richtigen Module sorgfältig auszuwählen. Einige Umgebungen + könnten eine Beschränkung der Zugriffe über die + Netzwerkschnittstellen benötigen - hier wären die Module + &man.mac.portacl.4;, &man.mac.ifoff.4; und sogar &man.mac.biba.4; ein + guter Anfang. In anderen Fällen muß man sehr strenge + Vertraulichkeit von Dateisystemobjekten gewährleisten - dafür + könnte man &man.mac.bsdextended.4; oder &man.mac.mls.4; + einsetzen. + + Die Entscheidung, welche Richtlinien angewandt werden, kann auch + anhand der Netzwerk-Konfiguration getroffen werden. Nur bestimmten + Benutzern soll erlaubt werden, via &man.ssh.1; auf das Netzwerk oder + Internet zuzugreifen - &man.mac.portacl.4; wäre eine gute Wahl. + Aber für was entscheidet man sich im Falle eines Dateisystems? + Soll der Zugriff auf bestimmte Verzeichnisse von spezifischen Nutzern + oder Nutzergruppen separiert werden? Oder wollen wir den Zugriff durch + Nutzer oder Programme auf spezielle Dateien einschränken, indem wir + gewisse Objekte als geheim einstufen? + + Der Zugriff auf Objekte kann einigen vertraulichen Nutzern gestattet + werden, anderen wiederum verwehrt. Als Beispiel sei hierzu ein + großes Entwicklerteam angeführt, das in kleine Gruppen von + Mitarbeitern aufgeteilt wurde. Die Entwickler von Projekt A dürfen + nicht auf Objekte zugreifen, die von den Entwicklern von Projekt B + geschrieben wurden. Sie müssen aber trotzdem auf Objekte + zugreifen können, die von einem dritten Entwicklerteam geschaffen + wurden - alles in allem eine verzwickte Situation. Wenn man die + verschiedenen Module der MAC richtig verwendet, + können Anwender in solche Gruppen getrennt und ihnen der Zugriff zu + den gewünschten Systemobjekten gestattet werden - ohne Angst haben + zu müssen, dass Informationen in die falschen Hände + geraten. + + So hat jedes Modul, das eine Sicherheitsrichtlinie verfügbar + macht, einen eigenen Weg, die Sicherheit des Systems zu verstärken. + Die Auswahl der Module sollte auf einem gut durchdachten + Sicherheitskonzept gründen. In vielen Fällen muß das + gesamte Konzept eines Systems überarbeitet und neu eingepflegt + werden. Ein guter Überblick über die Möglichkeiten der + verschiedenen von der MAC angebotenen Module + hilft einem Administrator, die besten Richtlinien für seine + spezielle Situation auszuwählen. + + Im &os;-Standardkernel ist die Option zur Verwendung der + MAC nicht enthalten. Daher muß die + Zeile + + + options MAC + + der Kernelkonfiguration hinzugefügt und der Kernel neu + übersetzt und installiert werden. + + + Verschiedenen Anleitungen für die MAC + empfehlen, die einzelnen Module direkt in den Kernel einzuarbeiten. + Dabei ist es jedoch möglich, das System aus dem Netzwerk + auszusperren oder gar schlimmeres. Die Arbeit mit der + MAC ist ähnlich der Arbeit mit einer Firewall - + man muß, wenn man sich nicht selbst aus dem System aussperren + will, genau aufpassen. Man sollte sich eine Möglichkeit + zurechtlegen, wie man eine Implementation einer MAC + rückgängig machen kann - genauso wie eine Ferninstallation + über das Netzwerk nur mit äußerster Vorsicht + vorgenommen werden sollte. Es wird daher empfohlen, + die Module nicht in den Kernel einzubinden, sondern sie beim + Systemstart via /boot/loader.conf zu + laden. + + + + + MAC Labels verstehen + + MAC Label sind Sicherheitsmerkmale, die, wenn sie zum Einsatz kommen, + allen Subjekten und Objekten im System zugeordnet werden. + + Wenn ein Administrator ein solches Merkmal bzw. Attribut setzen will, + muß er/sie verstehen können, was da genau passiert. Die + Attribute, die im speziellen Fall zu vergeben sind, hängen vom + geladenen Modul und den darin jeweils implementierten Richtlinien ab. + Jedes dieser Richtlinienmodule setzt die Arbeit mit seinen entsprechenden + Attributen in individueller Weise um. Falls der Nutzer nicht versteht, + was er da konfiguriert, oder auch, was seine Konfiguration für + Begleiterscheinungen mit sich bringt, ergibt sich meist als Resultat ein + unerwartetes, ja sogar unerwünschtes Verhalten des gesamten + Systems. + + Ein Label, einem Objekt verliehen, wird verwendet, um anhand einer + Richtlinie eine sicherheitsrelevante Entscheidung über + Zugriffsrechte zu fällen. In einigen Richtlinien enthält + bereits das Label selbst alle dafür nötigen Informationen. + Andere Richtlinien verwenden diese Informationen, um zunächst ein + komplexes Regelwerk abzuarbeiten. + + Wenn man zum Beispiel einer Datei das Attribut + biba/low zuordnet, wird dieses durch das Biba + Sicherheitsrichtlinienmodul, und zwar mit dem Wert low, + verarbeitet. + + Einige der Richtlinienmodule, die die Möglichkeit zum Vergeben + von Labels unter &os; unterstützen, bieten drei vordefinierte + Labels an. Dieses nennen sich high, low + und equal. Obwohl die verschiedenen Module die + Zugriffskontrolle auf verschiedene Weisen regeln, kann man sich sicher + sein, das das low-Label der untersten, unsichersten + Einstellung entspricht, das equal-Label die Verwendung des + Moduls für das jeweilige Objekt oder Subjekt deaktiviert - und das + high-Label die höchstmögliche Einstellung + erzwingt. Im Speziellen gilt diese Aussage für die + Richtlinien(-module) MLS und Biba. + + In den meisten Umgebungen, sogenannten Single Label Environments, + wird Objekten nur ein einzelnes Label zugewiesen. Dadurch wird nur ein + Regelsatz für die Zugriffskontrolle auf das gesamte System verwendet + - und das ist meistens auch tatsächlich ausreichend. Es gibt wenige + Fälle, in denen mehrere Labels auf Dateisystemobjekte oder -subjekte + verwendet werden. In einem solchen Fall muß das Dateisystem mit + der &man.tunefs.8;-Option angepaßt + werden, da die Standardeinstellung + ist. + + Bei der Verwendung von Biba oder MLS kann man + numerische Labels vergeben, die genau das Level angeben, an welcher + Stelle in der Hierarchie das Subjekt oder Objekt einzuordnen ist. Dieses + numerische Level wird verwendet, um Informationen in verschiedene Gruppen + aufzuteilen oder zu sortieren - damit zum Beispiel nur Subjekte, die zu + einer gewissen Vertraulichkeitsstufe gehören, Zugang zu einer Gruppe + von Objekten erhalten. + + In den meisten Fällen wird ein Administrator nur ein einzelnes + Label für das gesamte Dateisystem verwenden. + + Moment mal, dass ist doch dasselbe wie + DAC! Ich dachte, MAC würde die + Kontrolle strengstens an den Administrator binden! Diese + Aussage hält immer noch stand  - root ist + derjenige, der die Kontrolle ausübt und die Richtlinie konfiguriert, + so dass Nutzer in die entsprechenden, angemessenen Kategorien / + Zugriffsklassen eingeordnet werden. Nunja, einige Module schränken + root selbst ein. Die Kontrolle über Objekte + wird dann einer Gruppe zugewiesen, jedoch hat root + die Möglichkeit, die Einstellungen jederzeit zu widerrufen oder zu + ändern. Dies ist das Hierarchie/Freigabe-Modell, das durch + Richtlinien wie MLS oder Biba bereitgestellt wird. + + + Konfigurieren der Labels + + Gewissermaßen alle Aspekte der Labelkonfiguration + werden durch Werkzeuge das Basissystems umgesetzt. Die entsprechenden + Kommandos bieten eine einfache Schnittstelle zum Konfigurieren, + Manipulieren und auch Verifizieren der gekennzeichneten Objekte. + + Mit den beiden Kommandos &man.setfmac.8; und &man.setpmac.8; kann + man eigentlich schon alles machen. Das Kommando + setfmac wird verwendet, um ein MAC-Label auf einem + Systemobjekt zu setzen, setpmac hingegen zum Setzen + von Labels auf Systemsubjekte. Als Beispiel soll hier dienen: + + &prompt.root; setfmac biba/high test + + Wenn bei der Ausführung dieses Kommandos keine Fehler + aufgetreten sind, gelangt man zur Eingabeaufforderung zurück. Nur + wenn ein Fehler auftritt, verhalten sich diese Kommandos nicht still, + ganz wie auch die Kommandos &man.chmod.1; und &man.chown.8;. In + einigen Fällen wird dieser Fehler Permission + denied lauten und gewöhnlich dann auftreten, wenn ein + Label an einem Objekt angebracht oder verändert werden soll, das + bereits (Zugriffs-)Beschränkungen + unterliegt.Andere Vorbedingungen führen + natürlich zu anderen Fehlern. Zum Beispiel wenn das Objekt nicht + dem Nutzer gehört, der das Label ändern möchte, das + Objekt vielleicht gar nicht existiert oder es sich um ein nur lesbares + Objekt handelt. Oder eine verbindliche Richtlinie erlaubt dem + Prozeß die Veränderung des Labels nicht, weil die + Eigenschaften der Datei, die Eigenschaften des Prozesses oder der + Inhalt des neuen Labels nicht akzeptiert werden. Beispiel: Ein + Anwender mit geringer Vertraulichkeit versucht, das Label einer Datei + mit hoher Vertraulichkeit zu ändern. Oder er versucht, eine Datei + mit geringer Vertraulichkeit zu einer Datei mit hoher Vertraulichkeit + zu machen. Der Systemadministrator kann so eine + Situation mit Hilfe der folgenden Kommandos überwinden: + + &prompt.root; setfmac biba/high test +Permission denied +&prompt.root; setpmac biba/low setfmac biba/high test +&prompt.root; getfmac test +test: biba/high + + Wie wir hier sehen, kann setpmac verwendet + werden, um die vorhandene Einstellungen zu umgehen, indem dem + gestarteten Prozeß ein anderes, valides Label zugeordnet wird. + Das Werkzeug getpmac wird normalerweise auf gerade + laufende Prozesse angewendet. Ähnlich + sendmail: Als Argument wird statt eines + Kommandos eine eine Prozeß-ID übergeben, es verbirgt sich + doch dieselbe Logik dahinter. Wenn ein Nutzer versucht, eine Datei zu + verändern, auf die er keinen Zugriff hat, entsprechend der Regeln + eines geladenen Richtlinienmoduls, wird der Fehler Operation + not permitted durch die Funktion + mac_set_link angezeigt. + + + Übliche Typen von Labeln + + Wenn man die Module &man.mac.biba.4;, &man.mac.mls.4; und + &man.mac.lomac.4; verwendet, hat man die Möglichkeit, einfache + Label zu vergeben. Diese nennen sich high, + low und equal. Es folgt eine + kurze Beschreibung, was diese Labels bedeuten: + + + + Das Label low ist + definitionsgemäß das niedrigeste Label, das einem + Objekt oder Subjekt verliehen werden kann. Wird es gesetzt, kann + die entsprechende Entität nicht mehr auf Entitäten + zugreifen, die das Label high tragen. + + + + Das Label equal wird Entitäten + verliehen, die von der Richtlinie ausgenommen sein sollen. + + + + Das Label high verleiht einer Entität + die höchstmögliche Einstellung. + + + + Unter Beachtung jedes einzelnen Richtlinienmoduls moduliert und + beschränkt jede dieser Einstellungen den Informationsfluß + unterschiedlich. Genaue Erklärungen zu den Charakteristika der + einfachen Labels in den verschiedenen Modulen finden sich im + entsprechenden Unterabschnitt dieses Kapitels oder in den + Manpages. + + + Fortgeschrittene Label-Konfiguration + + Numerische klassifizierte Labels werden verwendet in der Form + Klasse:Verbund+Verbund. Demnach ist das + Label + + biba/10:2+3+6(5:2+3-15:2+3+4+5+6) + + folgendermaßen zu lesen: + + Biba Policy Label/effektive Klasse + 10 + :Verbund 2,3 und 6: + (Low-Klasse 5:...- + High-Klasse 15:...) + + In diesem Beispiel ist die erstgenannte Klasse als + effektive Klasse zu bezeichnen. Ihr werden die + effektiven Verbünde zugeordnet. Die zweite + Klasse ist die Low-Klasse und die letzte die + high-Klasse. Die allermeisten Konfigurationen kommen + ohne die Verwendungen von solchen Klassen aus, nichtsdestotrotz kann + man sie für erweiterte Konfigurationen verwenden. + + Sobald sie auf Systemsubjekte angewendet + werden, haben diese eine gegenwärtige Klasse/Verbund- + Konfiguration und diese muß im definierten Rahmen + gegebenenfalls angepaßt (erhöht oder gesenkt) werden. Im + Gegensatz dazu haben Systemobjekte alle + eingestellten (effektive, High- und Low-Klasse) gleichzeitig. Dies + ist notwendig, damit auf Sie von den + Systemsubjekten in den verschiedenen Klassen + gleichzeitig zugegriffen werden kann. + + Die Klasse und und die Verbünde in einem Subjekt-Objekt-Paar + werden zum Erstellen einer sogenannten Dominanz-Relation verwendet, + in welcher entweder das Subjekt das Objekt, das Objekt das Subjekt, + keines das andere dominiert oder sich beide gegenseitig dominieren. + Der Fall, dass sich beide dominieren, tritt dann ein, wenn die beiden + Labels gleich sind. Wegen der Natur des Informationsflusses in Biba + kann man einem Nutzer Rechte für einen Reihe von Abteilungen + zuordnen, die zum Beispiel mit entsprechenden Projekten + korrespondieren. Genauso können aber auch Objekten mehrere + Abteilungen zugeordnet sein. Die Nutzer müssen eventuell ihre + gegenwärtigen Rechte mithilfe von su or + setpmac anpassen um auf Objekte in einer Abteilung + zuzugreifen, zu der sie laut ihrer effektiven Klasse nicht berechtigt + sind. + + + + + Nutzer- und Label-Einstellungen + Nutzer selbst brauchen Labels damit ihre Dateien und Prozesse + korrekt mit der Sicherheitsrichtlinie zusammenarbeitet, die für + das System definiert wurde. Diese werden in der Datei + login.conf durch die Verwendung von Login- + Klassen zugeordnet. Jedes Richtlinienmodul, das Label verwendet, + arbeitet mit diesen Login-Klassen. + + Beispielhaft wird der folgende Eintrag, der für jede + Richtlinie eine Einstellung enthält, gezeigt: + + default:\ +:copyright=/etc/COPYRIGHT:\ +:welcome=/etc/motd:\ +:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ +:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ +:manpath=/usr/share/man /usr/local/man:\ +:nologin=/usr/sbin/nologin:\ +:cputime=1h30m:\ +:datasize=8M:\ +:vmemoryuse=100M:\ +:stacksize=2M:\ +:memorylocked=4M:\ +:memoryuse=8M:\ +:filesize=8M:\ +:coredumpsize=8M:\ +:openfiles=24:\ +:maxproc=32:\ +:priority=0:\ +:requirehome:\ +:passwordtime=91d:\ +:umask=022:\ +:ignoretime@:\ +:label=partition/13,mls/5,biba/10(5-15),lomac/10[2]: + + Die Label-Option in der letzten Zeile legt fest, welches + Standard-Label für einen Nutzer erzwungen wird. Nutzern darf + niemals gestattet werden, diese Werte selbst zu verändern, + demnach haben Nutzer in dieser Beziehung auch keine Wahlfreiheit. In + einer richtigen Konfiguration jedoch wird kein Administrator alle + Richtlinienmodule aktivieren wollen. Es wird an dieser Stelle + ausdrücklich empfohlen, dieses Kapitel zu Ende zu lesen, bevor + irgendein Teil dieser Konfiguration ausprobiert wird. + + + Nutzer können ihr eigenes Label nach dem Loginvorgang + durchaus ändern. Jedoch kann diese Änderung nur unter den + Auflagen der gerade gültigen Richtlinie geschehen. Im + Beispiel oben wird für die Biba-Richtlinie eine minimale + Prozeßintegrität von 5, eine maximale von 15 angegeben, + aber die Voreinstellung des tatsächlichen Labels ist 10. Der + Nutzerprozeß läuft also mit einer Integrität von 10 + bis das Label verändert wird, zum Beispiel durch eine + Anwendung des Kommandos setpmac, welches jedoch + auf den Bereich eingeschränkt wird, der zum Zeitpunkt des + Logins angegeben wurde, in diesem Fall von 5 bis 15. + + + Nach einer Änderung der Datei + login.conf muß in jedem Fall die + Befähigungsdatenbank mit dem Kommando + cap_mkdb neu erstellt werden - und das gilt + für alle im weiteren Verlauf gezeigten Beispiele und + Diskussionspunkte. + + Es ist nützlich anzumerken, dass viele Einsatzorte eine + große Anzahl von Nutzern haben, die wiederum viele + verschiedenen Nutzerklassen angehören sollen. Hier ist eine + Menge Planungsarbeit notwendig, da die Verwaltung sehr + unübersichtlich und schwierig ist. + + Zukünftige Versionen von &os; sollen neue Möglichkeiten + erhalten, Nutzern Labels zuzuordnen, die Umsetzung wird jedoch nach + dem Release von 5.3 noch einige Zeit in Anspruch nehmen. + + + + Netzwerkschnittstellen und die zugehörigen Label + + Labels können auch, wenn man sie an Netzwerkschittstellen + vergibt, helfen, den Datenfluß durch das Netzwerk zu + kontrollieren. Das funktioniert in allen Fällen genau so wie mit + Objekten. Nutzer, die in der Biba-Richtlinie das Label + high tragen, dürfen nicht auf Schnittstellen + zugreifen, die low markiert sind usw. + + Die Option wird via + ifconfig übergeben. Zum Beispiel + + &prompt.root; ifconfig bge0 maclabel biba/equal + + belegt die Schnittstelle &man.bge.4; mit dem + MAC Label biba/equal. Wenn eine + komplexe Einstellung wie biba/high(low-high) + verwendet wird, muß das gesamte Label in Anführungszeichen + geschrieben werden, da sonst eine Fehlermeldung zurückgegeben + wird. + + Jedes Richtlinienmodul, das die Vergabe von Labels + unterstützt, stellt einen Parameter bereit, mit dem das + MAC Label für Netzwerkschnittstellen + deaktiviert werden kann. Das Label der Netzwerkschnittstelle auf + equal zu setzen, führt zum selben Ergebnis. + Beachten Sie die Ausgabe von sysctl, die Manpages + der verschiedenen Richtlinien oder eben die Informationen, die im + weiteren Verlauf dieses Kapitels angeboten werden, um mehr zu diesen + Parametern zu erfahren. + + + + + Single- oder Multilabel? + Als Standardeinstellung verwendet das System die Option + . Was bedeutet das für den + Administrator? Es gibt einige Unterschiede zwischen und . In ihrer ureigenen + Weise bieten beide Vor- und Nachteile bezogen auf die Flexibilität + bei der Modellierung der Systemsicherheit. + + Die Option gibt jedem Subjekt oder + Objekt genau ein einziges Label, zum Beispiel + biba/high. Mit dieser Option hat man einen + geringeren Verwaltungsaufwand, aber die Flexibilität beim + Einsatzes von Richtlinien ist ebenso gering. Viele Administratoren + wählen daher auch die Option im + Sicherheitsmodell, wenn die Umstände es erfordern. + + Die Option gestattet, jedem einzelnen + Subjekt oder Objekt seine eigenen unabhängigen Label zu + zuzuordnen. Die Optionen und betreffen jedoch nur die Richtlinien, die Labels + als Leistungsmerkmal verwenden, einschließlich der Richtlinien + Biba, Lomac, MLS und + SEBSD. + + + + Wenn Richtlinien benutzt werden sollen, die ohne Labels auskommen, + wird die Option nicht benötigt. Dies + betrifft die Richtlinien seeotheruids, + portacl und partition. + + Man sollte sich dessen bewußt sein, dass die Verwendung der + Option auf einer Partition und die + Erstellung eines Sicherheitsmodells auf der Basis der &os; + Funktionalität einen hohen + Verwaltungsaufwand bedeutet, da alles im Dateisystem ein Label bekommt. + Jedes Verzeichnis, jede Datei und genauso jede Schnittstelle. + + Das folgende Kommando aktiviert + für ein Dateisystem. Dies funktioniert nur im + Einzelbenutzermodus: + + &prompt.root; tunefs -l enable / + + In einer Swap-Partition wird dies nicht benötigt. + + + Falls Sie Probleme beim Setzen der Option + auf der Root-Partition bemerken, lesen + Sie bitte dieses Kapitels. + + + + + + Planung eines Sicherheitsmodells + + Wann immer eine neue Technologie eingepflegt werden soll, ist es + wichtig, vorher einen Plan zu erstellen. In den verschiedenen Etappen + der Planung sollte der Administrator nie das + Große Ganze aus den Augen verlieren und mindestens + die folgenden Punkte beachten: + + + + Die Anforderungen + + + + Die Ziele + + + + Wenn Sie MAC verwenden möchten, sind das im + Besonderen folgende Punkte: + + + + Wie werden Informationen und Ressourcen auf den Zielsystemen + klassifiziert? + + + + Welche Arten von Informationen bzw. Ressourcen sollen im Zugang + beschränkt sein und welche Art Einschränkung soll + verwendet werden? + + + + Welche(s) MAC Modul(e) wählt man, um sein + Ziel zu erreichen? + + + + Es ist immer möglich, die Einstellungen des Systems und der + Systemressourcen im Nachhinein zu optimieren. Es ist aber + wirklich lästig, das gesamte Dateisystem zu durchsuchen, um Dateien + oder Benutzerkonten zu reparieren. Eine gute Planung hilft dem + Administrator, sich einer sorgenfreien und effizienten Umsetzung eines + Sicherheitsmodells zu versichern. Testlauf des Sicherheitsmodells + vor dem Einsatz in seiner richtigen Arbeitsumgebung + ist auf jeden Fall empfehlenswert. Die Idee, ein System mit einer + MAC einfach loslaufen zu lassen, ist wie direkt auf + einen Fehlschlag hinzuarbeiten. + + Jede Umgebung hat ihre eigenen Anforderungen. Ein tiefgreifendes und + vollständiges Sicherheitsprofil zu erstellen spart weitere + Änderungen, nachdem das System in Betrieb genommen wurde. Also + werden die folgenden Abschnitte die verschiedenen Module vorstellen, die + den Administratoren zur Verfügung gestellt werden, die Nutzung und + Konfiguration der einzelnen Module beschreiben; und in einigen + Fällen Einblicke gewähren, für welche Situationen welche + Module besonders geeignet sind. Zum Beispiel ein Webserver kann von der + Verwendung der &man.mac.biba.4; oder der &man.mac.bsdextended.4; + Richtlinie profitieren. In anderen Fällen, an einem Rechner mit nur + wenigen lokalen Benutzern, ist die &man.mac.partition.4; die Richtlinie + der Wahl. + + + + Modulkonfiguration + + Jedes Modul, das in der MAC enthalten ist, kann + entweder direkt in den Kernel eingefügt werden oder als Kernelmodul + in der Laufzeit des Systems geladen werden. Empfohlen wird, den + Modulnamen in der Datei /boot/loader.conf + anzufügen, so dass das Modul am Anfang des Bootvorgangs eingebunden + wird. + + Die folgenden Abschnitte werden verschiedene MAC + Module und ihre jeweiligen Vor- und Nachteile vorstellen. Außerdem + wird erklärt, wie sie in bestimmte Umgebungen eingearbeitet werden + können. Einige Module unterstützen die Verwendung von + Labels, das heißt Zugriffskontrolle durch + hinzufügen einer Kennzeichnung in der Art von dieses ist + erlaubt, jenes aber nicht. Eine Label-Konfigurationdatei + kontrolliert unter anderem, wie auf Dateien zugegriffen oder wie + über das Netzwerk kommuniziert werden darf. Im vorangehenden + Abschnitt wurde bereits erläutert, wie die Option + auf Dateisysteme angewendet wird, um eine + Zugriffskontrolle auf einzelne Dateien oder ganze Dateisysteme zu + konfigurieren. + + Eine Konfiguration erzwingt ein + einzelnes Label für das gesamte System. Daher wird die + tunefs-Option genannt. + + + + + Das MAC Modul seeotheruids + + + MAC See Other UIDs Policy + + + Modulename: mac_seeotheruids.ko + + Parameter in der Kernelkonfiguration: + options MAC_SEEOTHERUIDS + + Bootparameter: + mac_seeotheruids_load="YES" + + Das Modul &man.mac.seeotheruids.4; erweitert die + sysctl-Variablen + security.bsd.see_other_uids und + security.bsd.see_other_gids. Diese Optionen + benötigen keine im Vorhinein zu setzenden Labels und können + leicht durchschaubar mit den anderen MAC-Modulen zusammenarbeiten. + + Nachdem das Modul geladen wurde, können die folgenden + sysctl Variablen verwendet werden. + + + + security.mac.seeotheruids.enabled dient zur + Aktivierung des Moduls, zunächst mit den Standardeinstellungen. + Diese verhindern, dass Nutzer Prozesse und Sockets sehen können, + die ihnen nicht selbst gehöen. + + + + + security.mac.seeotheruids.specificgid_enabled kann + eine spezifizierte Nutzergruppe von dieser Richtlinie ausnehmen. Die + entsprechende Gruppe muß an den Parameter + security.mac.seeotheruids.specificgid=XXX + übergeben werden, wobei XXX die ID + der Gruppe ist, die von der Richtlinie ausgenommen werden + soll. + + + + + security.mac.seeotheruids.primarygroup_enabled + kann verwendet werden, um eine spezifische, + primäre Nutzergruppe von der Richtlinie + auszuschliessen. Dieser Parameter und + security.mac.seeotheruids.specificgid_enabled + schließen einander aus. + + + + + + Das MAC Modul bsdextended + + + MAC + File System Firewall Policy + + + Modulname: mac_bsdextended.ko + + Parameter in der Kernelkonfiguration: + options MAC_BSDEXTENDED + + Bootparameter: mac_bsdextended_load="YES" + + Das Modul &man.mac.bsdextended.4; erstellt eine Firewall für + das Dateisystem und ist eine Erweiterung des sonst üblichen + Rechtemodells. Es erlaubt einem Administrator einen Regelsatz zum + Schutz von Dateien, Werkzeugen und Verzeichnissen in der + Dateisystemhierarchie zu erstellen, der einer Firewall ähnelt. + Sobald auf ein Objekt im Dateisystem zugegriffen werden soll, wird eine + Liste von Regel abgearbeitet, bis eine passende Regel gefunden wird + oder die Liste zu Ende ist. Das Verhalten kann durch die Änderung + des &man.sysctl.8; Parameters + security.mac.bsdextended.firstmatch_enabled + eingestellt werden. Ähnlich wie bei den anderen Firewallmodulen + in &os; wird eine Datei erstellt, welche die Zugriffsregeln + enthält. Diese wird beim Systemstart durch eine Variable in + &man.rc.conf.5; eingebunden. + + Der Regelsatz kann mit dem Programm &man.ugidfw.8; eingepflegt + werden, welches eine Syntax bereitstellt, die der von &man.ipfw.8; + gleicht. Weitere Werkzeuge können auch selbst erstellt werden, + indem die Funktionen der Bibliothek &man.libugidfw.3; verwendet + werden. + + Bei der Arbeit mit diesem Modul ist äußerste Vorsicht + geboten - falscher Gebrauch kann den Zugriff auf Teile des Dateisystems + komplett unterbinden. + + + Beispiele + + Nachdem das Modul &man.mac.bsdextended.4; erfolgreich geladen + wurde, zeigt das folgende Kommando die gegenwärtig aktiven Regeln + an: + + &prompt.root; ugidfw list 0 slots, 0 rules + + Wie erwartet, sind keine Regeln definiert. Das bedeutet, das auf + alle Teile des Dateisystems zugegriffen werden kann. Um eine Regel zu + definieren, die jeden Zugriff durch Nutzer blockiert und nur die Rechte + von root unangetastet läßt, muß + lediglich dieses Kommando ausgeführt werden: + + &prompt.root; ugidfw add subject not uid root new object not uid root mode n + + Das ist allerdings keine gute Idee, da nun allen Nutzern der + Zugriff auf selbst die einfachsten Programme wie ls + untersagt wird. Angemessener wäre etwas wie: + + + &prompt.root; ugidfw set 2 subject uid user1 object uid user2 mode n +&prompt.root; ugidfw set 3 subject uid user1 object gid user2 mode n + + Diese Befehle bewirken, dass user1 keinen + Zugriff mehr auf Dateien und Programme hat, die + user2 gehören. + Dies schließt das Auslesen von Verzeichniseinträgen ein. + + + Anstelle user1 + könnte auch als Parameter übergeben + werden. Dies würde diesselben Einschränkungen für alle + Nutzer bewirken anstatt nur einen einzigen. + + + root ist von diesen Einstellungen nicht + betroffen. + + + Dies sollte als Überblick ausreichen, um zu verstehen, wie das + Modul &man.mac.bsdextended.4; helfen kann, das Dateisystem + abzuschotten. Weitere Informationen bieten die Manpages + &man.mac.bsdextended.4; und &man.ugidfw.8;. + + + + + Das MAC Modul ifoff + + + MAC Interface Silencing Policy + + + Modulname: mac_ifoff.ko + + Parameter für die Kernelkonfiguration: + options MAC_IFOFF + + + Bootparameter: mac_ifoff_load="YES" + + Das Modul &man.mac.ifoff.4; ist einzig dazu da, + Netzwerkschnittstellen im laufenden Betrieb zu deaktivieren oder zu + verhindern, das Netzwerkschnittstellen während der Bootphase + gestartet werden. Dieses Modul benötigt für seinen Betrieb + weder Labels, die auf dem System eingerichtet werden müssen, noch + hat es Abhängigkeiten zu anderen MAC Modulen. + + Der größte Teil der Kontrolle geschieht über die im + folgenden aufgelisteten sysctl-Parameter: + + + + security.mac.ifoff.lo_enabled schaltet den + gesamten Netzwerkverkehr auf der Loopback-Schnittstelle &man.lo.4; an + bzw. aus. + + + + security.mac.ifoff.bpfrecv_enabled macht das + Gleiche für den Berkeley Paket Filter &man.bpf.4;. + + + + security.mac.ifoff.other_enabled + schaltet den Verkehr für alle anderen + Netzwerkschnittstellen. + + + + Die wahrscheinlich häufigste Nutzung von &man.mac.ifoff.4; ist + die Überwachung des Netzwerks in einer Umgebung, in der kein + Netzwerkverkehr während des Bootvorgangs erlaubt werden soll. Eine + andere mögliche Anwendung wäre ein Script, das mit Hilfe von + security/aide automatisch alle + Schnittstellen blockiert, sobald Dateien in geschützten + Verzeichnissen angelegt oder verändert werden. + + + + Das MAC Modul portacl + + + MAC Port Access Control List Policy + + + Modulname: mac_portacl.ko + + Parameter für die Kernelkonfiguration: + options MAC_PORTACL + + Bootparameter: mac_portacl_load="YES" + + Mit Hilfe des Moduls &man.mac.portacl.4; können die Anbindungen + an die lokalen TCP und UDP Ports + durch eine Vielzahl von sysctl Variablen + beschränkt werden. Genauer gesagt ermöglicht + &man.mac.portacl.4; Nutzern ohne root-Rechten den + Zugriff auf zu bestimmende privilegierte Ports, also denen innerhalb der + ersten 1024. + + Sobald das Modul geladen wurde, ist die Richtlinie für alle + Sockets verfügbar. Die folgenden Variablen können für die + Konfiguration verwendet werden: + + + + security.mac.portacl.enabled schaltet die + Anwendung der Richtlinie ein oder aus. + + + + security.mac.portacl.port_high gibt den + höchsten Port an, der von der Richtlinie &man.mac.portacl.4; + betroffen sein soll. + + + + security.mac.portacl.suser_exempt nimmt, wenn + es einen Wert ungleich Null zugewiesen bekommt, + root von der Richtlinie aus. + + + + security.mac.portacl.rules enthält als + Wert die eigentliche mac_portacl + Richtlinie. + + + + Die eigentliche Konfiguration der mac_portacl + Richtlinie wird der sysctl-Variablen + security.mac.portacl.rules als Zeichenkette der Form + rule[,rule,...] übergeben. Jede einzelne Regel + hat die Form idtype:id:protocol:port. Der Parameter + idtype ist entweder uid oder + gid und wird verwendet, um den Parameter + id als Nutzer-ID oder Gruppen-ID zu kennzeichnen. + Der Parameter protocol gibt an, ob die Regel + ür TCP oder UDP gelten soll + (indem man den Wert auf tcp oder + udp setzt). Und der letzte Parameter, + port, enthält die Nummer des Ports, auf den + der angegebene Nutzer bzw. die angegebene Gruppe Zugriff erhalten + soll. + + + Da der Regelsatz direkt vom Kernel ausgewertet wird, können + nur Zahlenwerte übergeben werden. Das heißt, Namen von + Nutzern, Gruppen oder Dienstnamen aus der Datei + /etc/services funktionieren nicht. + + + Auf &unix;-artigen Betriebssystemen sind die Ports kleiner 1024 + privilegierten Prozessen vorbehalten, müssen also mit als/von + root gestartet werden und weiterhin laufen. Damit + &man.mac.portacl.4; die Vergabe von Ports kleiner als 1024 an nicht + privilegierte Prozesse übernehmen kann, muß die &unix; + Standardeinstellung deaktiviert werden. Dazu ändert man die + &man.sysctl.8; Variablen + net.inet.ip.portrange.reservedlow und + net.inet.ip.portrange.reservedhigh auf den Wert + 0. + + Weiterführende Informationen entnehmen Sie bitte den unten aufgeführten Beispielen oder der Man-Page &man.mac.portacl.4;! + + + Beispiele + Die folgenden Beispiele sollten ein wenig Licht in die obige + Diskussion bringen: + + &prompt.root; sysctl security.mac.portacl.port_high=1023 +&prompt.root; sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0 + + Zunächst bestimmen wir, dass &man.mac.portacl.4; für alle + privilegierten Ports gelten soll und deaktivieren die normale + &unix;-Beschränkung. + + &prompt.root; sysctl security.mac.portacl.suser_exempt=1 + + Da root von dieser Richtlinie nicht + beeinträchtigt werden soll, setzen wir hier + security.mac.portacl.suser_exempt auf einen Wert + ungleich Null. Das Modul &man.mac.portacl.4; ist nun so eingerichtet, + wie es &unix;-artige Betriebssysteme normal ebenfalls tun. + + &prompt.root; sysctl security.mac.portacl.rules=uid:80:tcp:80 + + Nun erlauben wir dem Nutzer mit der UID 80, + normalerweise dem Nutzer www, den Port 80 zu verwenden. Dadurch kann der Nutzer www einen Webserver + betreiben, ohne dafür mit root-Privilegien + ausgestattet zu sein. + + &prompt.root; sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995 + + Hier wird dem Nutzer mit der UID 1001 erlaubt, + die TCP Ports 110 (pop3) und 995 + (pop3s) zu verwenden. Dadurch kann dieser Nutzer einen + Server starten, der Verbindungen an diesen beiden Ports annehmen + kann. + + + + + Das MAC Modul partition + + + MAC Process Partition Policy + + + Modulname: mac_partition.ko + + Parameter für die Kernelkonfiguration: + options MAC_PARTITION + + + Bootparameter mac_partition_load="YES" + + Die Richtlinie &man.mac.partition.4; setzt Prozesse in spezielle + Partitionen, entsprechend dem zugewiesenen + MAC Label. Man kann sich das vorstellen wie eine + spezielle Art &man.jail.8;, auch wenn das noch kein wirklich guter + Vergleich ist. + + Es wird empfohlen, dieses Modul durch einen Eintrag in + &man.loader.conf.5; zu aktivieren, so dass die Richtlinie während + des Bootvorganges eingebunden wird. + + Der Großteil der Konfiguration geschieht mit dem Kommando + &man.setpmac.8;, wie gleich erklärt wird. Außerdem gibt es folgenden sysctl Parameter für diese Richtlinie. + + + + security.mac.partition.enabled erzwingt die + Verwendung von MAC + Prozeß-Partitionen. + + + + Sobald diese Richtlinie aktiv ist, sehen Nutzer nur noch ihre eigenen + Prozesse, und alle anderen Prozesse, die ebenfalls derselben + Prozeß-Partition zugeordnet sind. Sie können jedoch nicht auf + Prozesse oder Werkzeuge außerhalb des Anwendungsbereich dieser + Partition zugreifen. Das bedeutet unter anderem, das ein Nutzer, der + einer Klasse insecure zugeordnet ist, nicht auf das + Kommando top zugreifen kann - wie auch auf viele + anderen Befehle, die einen eigenen Prozeß erzeugen. + + Um einen Befehl einer Prozeß-Partition zuzuordnen, muß + dieser durch das Kommando setpmac mit einem Label + versehen werden: + + &prompt.root; setpmac partition/13 top + + Diese Zeile fügt das Kommando top dem + Labelsatz für Nutzer der Klasse insecure hinzu, + sofern die Partition 13 mit der Klasse insecure + übereinstimmt. Beachten Sie, dass alle Prozesse, die von Nutzern + dieser Klasse erzeugt werden, das Label partition/13 + erhalten, und dieses auch nicht durch den Nutzer geändert werden + kann. + + + Beispiele + + Der folgende Befehl listet die vergebenen Label für + Prozeß-Partitionen und die laufenden Prozesse auf. + + &prompt.root; ps Zax + + Das nächste Kommando liefert das Label der + Prozeß-Partition eines anderen Nutzers + trhodes und dessen gegenwärtig laufenden + Prozesse zurück. + + &prompt.root; ps -ZU trhodes + + + Jeder Nutzer kann die Prozesse in der Prozeß-Partition von + root betrachten, solange nicht die Richtlinie + &man.mac.seeotheruids.4; geladen wurde. + + + Eine ausgefeilte Umsetzung dieser Richtlinie deaktiviert alle + Dienste in /etc/rc.conf und startet diese dann + später durch ein Skript, das jedem Dienst das passende Label + zuordnet. + + + Die folgenden Richtlinien verwenden Zahlenwerte anstatt der drei + Standardlabels. Diese Optionen, und ihre Grenzen, werden in den + zugehörigen Manpages genauer erklärt. + + + + + + Das MAC Modul Multi-Level Security + + + MAC Multi-Level Security Policy + + + Modulname: mac_mls.ko + + Parameter für die Kernelkonfiguration: options + MAC_MLS + + Bootparameter: mac_mls_load="YES" + + Die Richtlinie &man.mac.mls.4; kontrolliert die Zugriffe zwischen + Subjekten und Objekten, indem sie den Informationsfluß strengen + Regeln unterwirft. + + In MLS Umgebungen wird jedem Subjekt oder Objekt + ein Freigabe-Level zugeordnet, und diese werden wiederum + zu einzelnen Verbünden zusammengefaßt. Da diese Freigabe- + oder Anfälligkeits-Level Zahlen größer 6000 erreichen + können, ist es für jeden Systemadministrator eine undankbare + Aufgabe, jede Entität von Grund auf zu konfigurieren. Zum + Glück gibt es 3 instant Labels, die in der Richtlinie + zur Anwendung bereit stehen. + + Diese drei Labels heißen mls/low, + mls/equal und mls/high. Da sie in + den Manpages &man.mac.mls.4; ausführlich beschrieben werden, gibt + es hier nur einen kurzen Abriß: + + + + Das Label mls/low ist eine niedrige + Einstellung, die von allen anderen dominiert werden darf. Alles, was + mit mls/low versehen wird, hat ein niedriges + Freigabe-Level und darf auf keine Informationen zugreifen, denen ein + höheres Freigabe-Level zugeordnet wurde. Einem Objekt mit + diesem Label kann außerdem keine Information durch ein Objekt + höherer Freigabe übergeben werden, es kann also auch nicht + durch solche Objekte editiert oder überschrieben werden. + + + + Das Label mls/equal wird an Objekte vergeben, + die von dieser Richtlinie ausgenommen werden sollen. + + + + Das Label mls/high verkörpert das + höchstmögliche Freigabe-Level. Objekte, denen dieses Label + zugeordnet wird, dominieren alle anderen Objekte des Systems. + Trotzdem können sie Objekten mit einem niedrigeren + Freigabe-Level keine Informationen zuspielen. + + + + MLS bietet: + + + + Eine hierarchische Sicherheitsschicht und Zuordnung + nichthierarchischer Kategorien; + + + + Feste Regeln: kein Read-Up, kein + Write-Down (ein Subjekt kann nur Objekte gleicher oder + niedrigerer Stufe lesen, und es kann nur Objekte + gleicher oder höherer Stufe + schreiben); + + + + Geheimhaltung (indem unangemessene Offenlegung von Daten + verhindert wird); + + + + Eine Basis zum Entwerfen von Systemen, die Daten verschiedener + Vertraulichkeitsebenen gleichzeitig handhaben sollen (ohne das + geheime und vertrauliche Informationen untereinander ausgetauscht + werden können). + + + + Nachfolgend werden die sysctl-Variablen + vorgestellt, die für die Einrichtung spezieller Dienste und + Schnittstellen vorhanden sind. + + + + security.mac.mls.enabled schaltet die + Richtlinie MLS ein (oder aus). + + + + security.mac.mls.ptys_equal sorgt dafür, + dass während der Initialisierung alle &man.pty.4;-Geräte + als mls/equal gekennzeichnet werden. + + + + security.mac.mls.revocation_enabled sorgt + dafür, dass die Zugriffsrechte von Objekten wieder + zurückgesetzt werden, nachdem deren Label vorübergehend auf + ein niedrigeres Freigabe-Level geändert wurde. + + + + security.mac.mls.max_compartments gibt die + maximale Anzahl von Verbünden an. Im Prinzip ist es die + höchste Nummer eines Verbundes auf dem System. + + + + Um die Labels der MLS Richtlinie zu bearbeiten + verwendet man &man.setfmac.8;. Um ein Objekt zu kennzeichnen, benutzen + Sie folgendes Kommando: + + &prompt.root; setfmac mls/5 test + + Um das MLS-Label der Datei + test auszulesen, verwenden Sie dieses + Kommando: + + &prompt.root; getfmac test + + Dies ist eine Zusammenstellung der Merkmale von + test. Ein anderer Ansatz ist, für diese + Richtlinie eine Konfigurationsdatei in /etc abzulegen, die alle Informationen + enthält und mit der dann das Kommando setfmac + gefüttert wird. Diese Vorgehensweise wird erklärt, nachdem + alle Richtlinien vorgestellt wurden. + + + Verbindlicher Vertraulichkeit in der Planungsphase + + Mit dem Richtlinienmodul Multi-Level Security + bereitet sich ein Administrator darauf vor, den Fluß + vertraulicher Informationen zu kontrollieren. Beim Starten der + Richtlinie ist immer mls/low voreingestellt - + alles kann auf alles zugreifen. Der Administrator ändert dies + während der eigentlichen Konfiguration, indem er die + Vertraulichkeit bestimmter Objekte erhöht. + + Jenseits der drei Grundeinstellungen des Labels kann der + Administrator einzelne Nutzer oder Nutzergruppen nach Bedarf + zusammenschließen und den Informationsaustausch zwischen diesen + gestatten oder unterbinden. Es ist sicher eine Vereinfachung, die + Freigabe-Level mit Begriffen wie vertraulich, + geheim oder streng geheim zu + bezeichnen. Einige Administratoren erstellen einfach verschiedene + Gruppen auf der Ebene von gegenwärtigen Projekten. Ungeachtet der + Herangehensweise bei der Klassifizierung muß ein gut durchdachter + Plan existieren, bevor eine derart einengende Richtlinie umgesetzt + wird. + + Exemplarisch für die Anwendung dieses Moduls bzw. dieser + Richtlinie seien angeführt: + + + + Ein E-Commerce Webserver + + + + Ein Dateiserver, der vertrauliche Informationen einer Firma + oder eines Konzerns speichert + + + + Umgebungen in Finanzeinrichtungen + + + + Der unsinnigste Einsatzort für diese Richtlinie wäre ein + Arbeitsplatzrechner mit nur zwei oder drei Benutzern. + + + + + Das MAC Modul Biba + + + MAC Biba Integrity Policy + + + Modulname: mac_biba.ko + + Parameter für die Kernelkonfiguration: + options MAC_BIBA + + Bootparameter: mac_biba_load="YES" + + Das Modul &man.mac.biba.4; lädt die MAC Biba + Richtlinie. Diese ähnelt stark der MLS + Richtlinie, nur das die Regeln für den Informationsfluß ein + wenig vertauscht sind. Es wird in diesem Fall der absteigende Fluß + sicherheitskritischer Information geregelt, während die + MLS Richtlinie den aufsteigenden Fluß regelt. + In gewissen Sinne treffen dieses und das vorangegangene Unterkapitel also + auf beide Richtlinien zu. + + In einer Biba-Umgebung wird jedem Subjekt und jedem Objekt ein + Integritäts-Label zugeordnet. Diese Labels sind in + hierarchischen Klassen und nicht-hierarchischen Komponenten geordnet. Je + höher die Klasse, um so höher die Integrität. + + Die unterstützten Labels heißen + biba/low, biba/equal und + biba/high. Sie werden im Folgenden + erklärt: + + + + biba/low ist die niedrigste Stufe der + Integrität, die einem Objekt verliehen werden kann. Wenn sie + einem Objekt oder Subjekt zugeordnet wird, kann dieses auf Objekte + oder Subjekte, die biba/high markiert wurden, zwar lesend zugreifen, + nicht jedoch schreibend. + + + + Das Label biba/equal ist, wie der aufmerksame + Leser sicherlich schon ahnt, für die Ausnahmen dieser Richtlinie + gedacht und sollte nur diesen Ausnahmen entsprechenden Objekten + verliehen werden. + + + + biba/high markierte Subjekte und Objekte + können Objekte niedrigerer Stufe schreiben , nicht jedoch lesen. + Es wird empfohlen, dass dieses Label an Objekte vergeben wird, die + sich auf Integrität des gesamten Systems auswirken. + + + + Biba stellt bereit: + + + + Hierarchische Integritätsstufen mit einem Satz + nichthierarchischer Integritätskategorien; + + + + Festgeschriebene Regeln: kein Write-Up, kein + Read-Down (der Gegensatz zu MLS - ein Subjekt + erhält schreibenden Zugriff auf Objekte gleicher oder geringerer + Stufe, aber nicht bei höherer, und lesenden Zugriff bei gleicher + Stufe oder höerer, aber nicht bei niedrigerer); + + + + Integrität (es wird die Echtheit der Daten + gewährleistet, indem unangemessene Veränderungen verhindert + werden); + + + + Eine Abstufung der Gewährleistung (im Gegensatz zu MLS, bei + der eine Abstufung der Vertraulichkeit vorgenommen wird). + + + + Folgende sysctl Parameter werden zur Nutzung der + Biba-Richtlinie angeboten: + + + + security.mac.biba.enabled zum + Aktivieren/Deaktivieren der Richtlinie auf dem Zielsystem. + + + + security.mac.biba.ptys_equal wird verwendet, + um die Biba-Richtlinie auf der &man.pty.4;-Schnittstelle zu + deaktivieren. + + + + security.mac.biba.revocation_enabled + erzwingt das Zurücksetzen des Labels, falls dieses zeitweise + geändert wurde um ein Subjekt zu dominieren. + + + + Um Einstellungen der Biba Richtlinie für Systemobjekte zu + verändern werden die Befehle setfmac und + getfmac verwendet: + + &prompt.root; setfmac biba/low test +&prompt.root; getfmac test +test: biba/low + + + Verbindliche Integrität in der Planungsphase + + Integrität garantiert, im Unterschied zu Sensitivität, + dass Informationen nur durch vertraute Parteien verändert werden + können. Dies schließt Informationen ein, die zwischen + Subjekten ausgetauscht werden, zwischen Objekt, oder auch zwischen den + beiden. Durch Integrität wird gesichert, das Nutzer nur + Informationen verändern, oder gar nur lesen können, die sie + explizit benötigen. + + Das Modul &man.mac.biba.4; eröffnet einem Administrator die + Möglichkeit zu bestimmen, welche Dateien oder Programme ein Nutzer + oder eine Nutzergruppe sehen bzw. aufrufen darf. Gleichzeitig kann er + zusichern, dass dieselben Programme und Dateien frei von Bedrohungen + sind und das System die Echtheit gewährleistet - für diesen + Nutzer oder die Nutzergruppe. + + Während der anfänglichen Phase der Planung muß der + Administrator vorbereitet sein, Nutzer in Klassen, Stufen und Bereiche + einzuteilen. Der Zugriff auf Dateien und insbesondere auch Programme + wird verhindert sowohl vor als auch nachdem sie gestartet wurden. Das + System selbst erhält als Voreinstellung das Label + biba/high sobald das Modul aktiviert wird - und + es liegt allein am Administrator, die verschiedenen Klassen und Stufen + für die einzelnen Nutzer zu konfigurieren. Anstatt mit Freigaben + zu arbeiten, wie weiter oben gezeigt wurde, könnte man auch + Überbegriffe für Projekte oder Systemkomponenten entwerfen. + Zum Beispiel, ausschließlich Entwicklern den Vollzugriff auf + Quellcode, Compiler und Entwicklungswerkzeuge gewähren, + während man andere Nutzer in Kategorien wie Tester, Designer oder + einfach nur allgemeiner Nutzer zusammenfaßt, die + für diese Bereiche lediglich lesenden Zugriff erhalten + sollen. + + Mit seinem ursprünglichen Sicherheits-Standpunkt ist ein + Subjekt niedrigerer Integrität unfähig, ein Subjekt + höherer Integrität zu verändern. Ein Subjekt + höherer Integrität kann ein Subjekt niedrigerer + Integrität weder beobachten noch lesen. Wenn man ein Label + für die niedrigstmögliche Klasse erstellt, kann man diese + allen Subjekten verwehren. Einige weitsichtig eingerichtete + Umgebungen, die diese Richtlinie verwenden, sind eingeschränkte + Webserver, Entwicklungs- oder Test-Rechner oder Quellcode-Sammlungen. + Wenig sinnvoll ist diese Richtlinie auf einer Arbeitsstation, oder auf + Rechnern die als Router oder Firewall verwendet werden. + + + + + Das MAC Modul LOMAC + + + MAC LOMAC + + Modulname: mac_lomac.ko + + Parameter für die Kernelkonfiguration: + options MAC_LOMAC + + Bootparameter: mac_lomac_load="YES" + + Anders als die Biba Richtlinie erlaubt die &man.mac.lomac.4; + Richtlinie den Zugriff auf Objekte niedrigerer Integrität nur, + nachdem das Integritätslevel gesenkt wurde. Dadurch wird eine + Störung derIntegritätsregeln verhindert. + + Die MAC Version der Low-Watermark + Richtlinie, die nicht mit der älteren &man.lomac.4;-Implementierung + verwechselt werden darf, arbeitet fast genauso wie Biba. Anders ist, + dass hier schwebende Label verwendet werden, die ein + Herunterstufen von Subjekten durch Hilfsverbünde ermöglichen. + Dieser zweite Verbund wird in der Form [auxgrade] + angegeben und sollte in etwa aussehen wie lomac/10[2], + wobei die Ziffer zwei (2) hier den Hilfsverbund abbildet. + + Die MAC Richtlinie LOMAC + beruht auf einer durchgängigen Etikettierung aller Systemobjekte mit + Integritätslabeln, die Subjekten das Lesen von Objekten niedriger + Integrität gestatten und dann das Label des Subjektes herunterstufen + - um zukünftige Schreibvorgänge auf Objekte hoher + Integrität zu unterbinden. Dies ist die Funktion der Option + [auxgrade], die eben vorgestellt wurde. Durch sie + erhält diese Richtlinie eine bessere Kompatibilität und die + Initialisierung ist weniger aufwändig als bei der Richtlinie + Biba. + + + Beispiele + + Wie schon bei den Richtlinien Biba und MLS + werden die Befehle setfmac und + setpmac verwendet, um die Labels an den + Systemobjekten zu setzen: + + &prompt.root; setfmac /usr/home/trhodes lomac/high[low] +&prompt.root; getfmac /usr/home/trhodes lomac/high[low] + + Beachten Sie, dass hier der Hilfswert auf low + gesetzt wurde - dieses Leistungsmerkmal ist nur in der + MAC LOMAC Richtlinie + enthalten. + + + + + Beispiel 1: Nagios in einer MAC Jail + + + Nagios in a MAC Jail + + + Die folgende Demonstration setzt eine sichere Umgebung mithilfe + verschiedener MAC Module und sorgfältig + konfigurierter Richtlinien um. Es handelt sich jedoch nur um einen Test + und sollte nicht als Antwort auf jedes Problem in Fragen Sicherheit + gesehen werden. Eine Richtlinie nur umzusetzen und dann einfach laufen + zu lassen, funktioniert nie und kann eine echte Arbeitsumgebung in eine + Katastrophe stürzen. + + Bevor es losgeht, muß jedes Dateisystem mit der Option + , wie weiter oben beschrieben, markiert + werden. Dies nicht zu tun, führt zu Fehlern. Außerdem + müssen die Ports net-mngt/nagios-plugins, net-mngt/nagios und www/apache13 installiert und konfiguriert sein, + so dass sie ordentlich laufen. + + + Erstellen einer Nutzerklasse <literal>insecure</literal> + + Beginnen wir die Prozedur mit dem Hinzufügen einer + Nutzerklasse in der Datei /etc/login.conf: + + insecure:\ +:copyright=/etc/COPYRIGHT:\ +:welcome=/etc/motd:\ +:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ +:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin-- +:manpath=/usr/share/man /usr/local/man:\ +:nologin=/usr/sbin/nologin:\ +:cputime=1h30m:\ +:datasize=8M:\ +:vmemoryuse=100M:\ +:stacksize=2M:\ +:memorylocked=4M:\ +:memoryuse=8M:\ +:filesize=8M:\ +:coredumpsize=8M:\ +:openfiles=24:\ +:maxproc=32:\ +:priority=0:\ +:requirehome:\ +:passwordtime=91d:\ +:umask=022:\ +:ignoretime@:\ +:label=biba/10(10-10): + + Zusätzlich fügen wir beim Standardnutzer folgende Zeile + hinzu: + + :label=biba/high: + + Anschließend muß die Datenbank neu erstellt + werden: + + &prompt.root; cap_mkdb /etc/login.conf + + + + Boot-Konfiguration + + Starten Sie den Rechner noch nicht neu. Fügen Sie + zunächst noch die folgenden Zeilen in die Datei + /boot/loader.conf ein, damit die benötigten + Module während des Systemstarts geladen werden: + + mac_biba_load="YES" +mac_seeotheruids_load="YES" + + + + Nutzer einrichten + Ordnen Sie den Superuser root der Klasse + default zu: + + &prompt.root; pw usermod root -L default + + Alle Nutzerkonten, die weder root noch + Systemkonten sind, brauchen nun eine Loginklasse, da sie sonst keinen + Zugriff auf sonst übliche Befehle erhalten, wie bspw. &man.vi.1;. + Das folgende sh Skript wird diese Aufgabe + erledigen: + + &prompt.root; for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \ + /etc/passwd`; do pw usermod $x -L default; done; + + Verschieben Sie die Nutzer nagios und + www in die insecure + Klasse: + + &prompt.root; pw usermod nagios -L insecure + &prompt.root; pw usermod www -L insecure + + + + Die Kontextdatei erstellen + + Nun muß eine Kontextdatei erstellt werden. Die folgende + Beispieldatei soll dazu in /etc/policy.contexts + gespeichert werden: + + # This is the default BIBA policy for this system. + +# System: +/var/run biba/equal +/var/run/* biba/equal + +/dev biba/equal +/dev/* biba/equal + +/var biba/equal +/var/spool biba/equal +/var/spool/* biba/equal + +/var/log biba/equal +/var/log/* biba/equal + +/tmp biba/equal +/tmp/* biba/equal +/var/tmp biba/equal +/var/tmp/* biba/equal + +/var/spool/mqueue biba/equal +/var/spool/clientmqueue biba/equal + +# For Nagios: +/usr/local/etc/nagios +/usr/local/etc/nagios/* biba/10 + +/var/spool/nagios biba/10 +/var/spool/nagios/* biba/10 + +# For apache +/usr/local/etc/apache biba/10 +/usr/local/etc/apache/* biba/10 + + + Die Richtlinie erzwingt Sicherheit, indem der + Informationsfluß Einschränkungen unterworfen wird. In der + vorliegenden Konfiguration kann kein Nutzer, weder + root noch andere, auf + Nagios zugreifen. Konfigurationsdateien und + die Prozesse, die Teil von Nagios sind, + werden durch unsere MAC vollständig + abgegrenzt. + + Die Kontextdatei kann nun vom System eingelesen werden, indem + folgender Befehl ausgeführt wird: + + &prompt.root; setfmac -ef /etc/policy.contexts / +&prompt.root; setfmac -ef /etc/policy.contexts / + + + Das obenstehende Dateisystem-Layout kann, je nach Umgebung, sehr + unterschiedlich aussehen. Außerdem muß es auf jedem + einzelnen Dateisystem ausgeführt werden. + + + In die Datei /etc/mac.conf müssen nun + noch diese Änderungen eingetragen werden: + + default_labels file ?biba +default_labels ifnet ?biba +default_labels process ?biba +default_labels socket ?biba + + + + + Netzwerke einbinden + + Tragen Sie die folgende Zeile in die Datei + /boot/loader.conf ein: + + security.mac.biba.trust_all_interfaces=1 + + Und das Folgende gehört in Datei rc.conf + zu den Optionen für die Netzwerkkarte. Falls die + Netzwerkverbindung(-en) via DHCP + konfiguriert werden, muß man dies nach jedem Systemstart + eigenhändig nachtragen: + + maclabel biba/equal + + + + Testen der Konfiguration + + + MAC Configuration Testing + + + Versichern Sie sich, dass der Webserver und + Nagios nicht automatisch geladen werden und + starten Sie den Rechner neu. Prüfen Sie nun, ob + root wirklich keinen Zugriff auf die Dateien im + Konfigurationsverzeichnis von Nagios hat. + Wenn root den Befehl &man.ls.1; auf + /var/spool/nagios ausführen kann, ist + irgendwas schief gelaufen. Es sollte ein permission + denied Fehler ausgegeben werden. + + Wenn alles gut aussieht, können + Nagios, + Apache und + Sendmail gestartet werden - allerdings auf + eine Weise, die unserer Richtlinie gerecht wird. Zum Beispiel durch die + folgenden Kommandos: + + &prompt.root; cd /etc/mail && make stop && \ +setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \ +setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart + + Versichern Sie sich lieber doppelt, dass alles ordentlich + läuft. Wenn nicht, prüfen Sie die Logs und Fehlermeldungen. + Verwenden Sie das &man.sysctl.8; Werkzeug um die Sicherheitsrichtlinie + &man.sysctl.8; zu deaktivieren und versuchen Sie dann alles noch einmal + zu starten. + + + Der Superuser kann den Vollzug der Richtlinie schalten und die + Konfiguration ohne Furcht verändern. Folgender Befehl stuft + eine neu gestartete Shell herunter: + + &prompt.root; setpmac biba/10 csh + + Um dies zu vermeiden, werden die Nutzer durch &man.login.conf.5; + eingeschränkt. Wenn &man.setpmac.8; einen Befehl + außerhalb der definierten Schranken ausführen soll, wird + ein Fehler zurückgeliefert. In so einem Fall muß + root auf biba/high(high-high) + gesetzt werden. + + + + + + Beispiel 2: User Lock Down + + Grundlage dieses Beispiels ist ein relativ kleines System zur + Datenspeicherung mit weniger als 50 Benutzern. Diese haben die + Möglichkeit, sich einzuloggen und dürfen nicht nur Daten + speichern, sondern auch auf andere Ressourcen zugreifen. + + Die Richtlinien &man.mac.bsdextended.4; und &man.mac.seeotheruids.4; + können gleichzeitig eingesetzt werden. Zusammen kann man mit ihnen + nicht nur den Zugriff auf Systemobjekte einschränken, sondern auch + Nutzerprozesse verstecken. + + Beginnen Sie, indem Sie die folgende Zeile in die Datei + /boot/loader.conf eintragen: + + mac_seeotheruids_load="YES" + + Die Richtlinie &man.mac.bsdextended.4; wird durch den + anschließenden Eintrag in /etc/rc.conf + hinzugefügt: + + ugidfw_enable="YES" + + Die Standardregeln, welche in + /etc/rc.bsdextended gespeichert sind, werden zum + Systemstart geladen. Sie müssen aber noch angepaßt werden. + Da dieser Computer nur Nutzern dienen soll und weitere Dienste gestartet + werden, kann alles bis auf die beiden letzten Zeilen auskommentiert + werden. Das sorgt dafür dass jeder Nutzer seine eigenen + Systemobjekte erhält. + + Nun fügen wir alle benötigten Nutzer auf der Maschine hinzu + und starten neu. Zum Testen der Einstellungen loggen Sie sich parallel + zwei mal mit unterschiedlichen Nutzernamen ein und starten Sie das + Kommando ps aux. Dort sehen Sie, dass Sie die + Prozesse des anderen Nutzers nicht sehen können. Versuchen Sie, + &man.ls.1; auf das Heimatverzeichnis eines anderen Nutzers + auszuführen. Auch dieser Versuch wird fehlschlagen. + + Solange nicht die speziellen sysctl-Variablen + geändert wurden, hat der Superuser noch vollen Zugriff. Sobald auch + diese Einstellungen angepaßt wurden, führen Sie ruhig auch + den obigen Test als root aus. + + + Wenn ein neuer Benutzer hinzugefügt wird, ist für diesen + zunächst keine &man.mac.bsdextended.4; Regel im Regelsatz + vorhanden. Schnelle Abhilfe schafft hier, einfach das Kernelmodul mit + &man.kldunload.8; zu entladen und mit &man.kldload.8; erneut + einzubinden. + + + + + Fehler im MAC beheben + + + MAC Troubleshooting + + + Während der Entwicklung des Frameworks haben einige Nutzer auf + Probleme hingewiesen. Einige davon werden hier aufgeführt: + + + Die Option <option>multilabel</option> greift nicht auf der + <filename>/</filename>-Partition + + Es scheint, dass etwa jedem fünfzigsten Nutzer dieses Problem + widerfährt. Und in der Tat - auch wir kennen es aus der + Entwicklung. Genauere Untersuchungen dieses Bugs + machten uns glauben, dass es sich entweder um einen Fehler in oder eine + fehlerhafte Interpretation der Dokumentation handelt. Warum auch immer + dieser Fehler auftritt - er kann mit folgender Prozedur behoben + werden: + + + + Öffnen Sie die Datei /etc/fstab und + setzen Sie die Rootpartition auf wie + read-only. + + + + Starten Sie in den Einzelnutzermodus. + + + + Rufen Sie tunefs + für / auf. + + + + Starten Sie in den Mehrbenutzermodus. + + + + Führen Sie mount + / aus und ändern + Sie anschließend in der Datei /etc/fstab + die Option zurück in . + Starten Sie das System noch einmal neu. + + + + Achten Sie besonders auf die Ausgabe von + mount um sich zu versichern, dass die + korrekt für das root-Dateisystem + gesetzt wurde. + + + + + + + Mit der aktivierten MAC kann ich keinen X11 Server starten + + Dies kann durch die Richtlinie partition + oder einer fehlerhaften Verwendung einer Richtlinie, die mit Labels + arbeitet, auftreten. Zum debuggen versuchen Sie folgendes: + + + + Schauen Sie sich die Fehlermeldungen genau an. Wenn der Nutzer + einer insecure Klasse angehört, ist + wahrscheinlich die Richtlinie partition die + Ursache. Versuchen Sie, die Nutzerklasse auf + default zu stellen und danach die Datenbank mit + cap_mkdb zu erneuern. Wenn das Problem dadurch + nicht gelöst wird, gehen Sie weiter zu Schritt 2. + + + + Gehen Sie die Label-Richtlinien Schritt für Schritt + nocheinmal durch. Achten Sie darauf, dass für den Nutzer, bei + dem das Problem auftritt, für X11 und das Verzeichnis + /dev alle Einstellungen + korrekt sind. + + + + Falls all dies nicht helfen sollte, senden Sie die + Fehlermeldung und eine Beschreibung ihrer Arbeitsumgebung an die + (englisch-sprachige) TrustedBSD Diskussionsliste auf der TrustedBSD Webseite oder an + die &a.questions; Mailingliste./para> + + + + + + Error: &man..secure.path.3; cannot stat + <filename>.login_conf</filename> + + Wenn ich versuche, von root zu einem anderen + Nutzer des Systems zu wechseln, erhalte ich die Fehlermeldung + _secure_path: unable to state .login_conf. + + + Diese Meldung wird gewöhnlich ausgegeben, wenn der Nutzer ein + höhere Label-Einstellung hat als der, dessen Identität man + annehmen möchte. Ausführlich: Wenn ein Nutzer + joe als gelabelt wurde, + kann root, der als + Voreinstellung trägt, das Heimatverzeichnis von + joe nicht einsehen. Das passiert unabhänig + davon, ob root vorher mit su + die Identität von joe angenommen hat oder + nicht, da das Label sich nicht ändert. Hier haben wir also einen + Fall, in dem das Gewährleistungsmodell von Biba verhindert, das + der Superuser Objekte einer niedrigeren Integrität betrachten + kann. + + + + Der Nutzer <username>root</username> ist kaputt! + + Im normalen oder sogar im Einzelbenutzermodus wird + root nicht anerkannt. Das Kommando + whoami liefert 0 (null) und su + liefert who are you? zurück. Was geht da + vor? + + Das kann passieren, wenn eine Label-Richtlinie ausgeschaltet wird - + entweder durch &man.sysctl.8; oder wenn das Richtlinienmodul entladen + wurde. Wenn eine Richtlinie deaktiviert oder auch nur + vorübergehen deaktiviert wird, muß die + Befähigungsdatenbank neu konfiguriert werden, d.h. die + Option muß entfernt werden. + Überprüfen Sie, ob alle Einträge + aus der Datei /etc/login.conf entfernt wurden und + bauen Sie die Datenbank mit cap_mkdb neu. + + Dieser Fehler kann auch auftreten, wenn eine Richtlinie den Zugriff + auf die Datei master.passwd einschränkt. + Normalerweise passiert das nur, wenn ein Administrator ein Label an + diese Datei vergibt, das mit der allgemeingültigen Richtlinie, die + das System verwendet, in Konflikt steht. In solchen Fällen werden + die Nutzerinformationen vom System ausgelesen und jeder weitere Zugriff + wird blockiert, sobald das neue Label greift. Wenn man die Richtlinie + via &man.sysctl.8; ausschaltet, sollte es erstmal wieder gehen. + + diff --git a/de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml b/de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml index 53b9a869d6..d71617e67c 100644 --- a/de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,3341 +1,3338 @@ Bezugsquellen für &os; CD-ROM und DVD Verleger &os;-Pakete &os;-Pakete (&os;-CDs, zusätzliche Software und gedruckte Dokumentation) erhalten Sie von mehreren Händlern:
CompUSA WWW:
Frys Electronics WWW:
&os;-CDs und -DVDs Die &os;-CDs und -DVDs werden von vielen Online-Händlern angeboten:
&os; Mall, Inc. 700 Harvest Park Ste F Brentwood, CA 94513 USA Telefon: +1 925 240-6652 Fax: +1 925 674-0821 E-Mail: info@freebsdmall.com WWW:
Dr. Hinner EDV St. Augustinus-Str. 10 D-81825 München Germany Telefon: (089) 428 419 WWW:
Ikarios 22-24 rue Voltaire 92000 Nanterre France WWW:
JMC Software Ireland Telefon: 353 1 6291282 WWW:
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA United Kingdom Telefon: +44 1491 837010 Fax: +44 1491 837016 WWW:
Linux+ DVD Magazine Lewartowskiego 6 Warsaw 00-190 Poland Telefon: +48 22 860 18 18 E-Mail: editors@lpmagazine.org WWW:
Linux System Labs Australia 21 Ray Drive Balwyn North VIC - 3104 Australia Telefon: +61 3 9857 5918 Fax: +61 3 9857 8974 WWW:
LinuxCenter.Ru Galernaya Street, 55 Saint-Petersburg 190000 Russia Telefon: +7-812-3125208 E-Mail: info@linuxcenter.ru WWW:
Lieferanten Wenn Sie &os;-CD-ROM-Produkte weiterverkaufen möchten, kontaktieren Sie einen der folgenden Lieferanten:
Cylogistics 809B Cuesta Dr., #2149 Mountain View, CA 94040 USA Telefon: +1 650 694-4949 Fax: +1 650 694-4953 E-Mail: sales@cylogistics.com WWW:
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 USA Telefon: 1 (800) 456-8000 WWW:
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 USA Telefon: +1 952 947-0822 Fax: +1 952 947-0876 E-Mail: sales@kudzuenterprises.com
LinuxCenter.Kz Ust-Kamenogorsk Kazakhstan Telefon: +7-705-501-6001 E-Mail: info@linuxcenter.kz WWW:
LinuxCenter.Ru Galernaya Street, 55 Saint-Petersburg 190000 Russia Telefon: +7-812-3125208 E-Mail: info@linuxcenter.ru WWW:
Navarre Corp 7400 49th Ave South New Hope, MN 55428 USA Telefon: +1 763 535-8333 Fax: +1 763 535-0341 WWW:
FTP-Server Die offiziellen Quellen von &os; sind mit anonymous FTP über ein weltweites Netz von FTP-Spiegeln erhältlich. Obwohl über eine gute Anbindung verfügt, sollten Sie einen Spiegel in Ihrer Nähe verwenden (insbesondere, wenn Sie selber einen Spiegel einrichten wollen). Die Datenbank der &os;-Spiegel ist aktueller als die folgende Liste, da sie im Gegensatz zu einer statischen Liste die Informationen aus dem DNS erhält. Sie können &os; auch über anonymous FTP von den folgenden Spiegeln beziehen. Wenn Sie &os; über anonymous FTP beziehen wollen, wählen Sie bitte einen Spiegel in Ihrer Nähe. Die unter Haupt-Spiegel aufgeführten Spiegel stellen normalerweise das komplette &os;-Archiv (alle momentan erhältlichen Versionen für jede unterstützte Architektur) zur Verfügung. Wahrscheinlich geht es aber schneller, wenn Sie einen Spiegel in Ihrer Nähe benutzen. Die Länder-Spiegel stellen die neusten Versionen für die beliebtesten Architekturen bereit, sie stellen aber unter Umständen nicht das komplette &os;-Archiv bereit. Auf alle Server kann mit anonymous FTP zugegriffen werden, einige Server bieten auch andere Zugriffsmethoden an. Die zur Verfügung stehenden Zugriffsmethoden sind bei jedem Server in Klammern angegeben. &chap.mirrors.ftp.inc; BitTorrent BitTorrent Die ISO-Images für die Release-CDs sind via BitTorrent abrufbar. Eine Sammlung von Torrent-Dateien zum Herunterladen der Images ist unter http://torrents.freebsd.org:8080 verfügbar. Die BitTorrent Client-Software ist als Port net-p2p/py-bittorrent oder als vorkompiliertes Paket erhältlich. Nach dem Herunterladen der ISO-Images mit BitTorrent können Sie diese auf CD oder DVD brennen, so wie im burncd- beschrieben. Anonymous CVS <anchor id="anoncvs-intro">Einführung CVS anonymous Anonymous CVS (oder anoncvs) dient zum Synchronisieren mit entfernten Repositories und steht mit den CVS Werkzeugen, die im &os; Basissystem enthalten sind, zur Verfügung. Benutzer von &os; können damit unter anderem lesende Operationen auf den Anoncvs Servern des &os; Projects durchführen, ohne über besondere Berechtigungen zu verfügen. Um es zu benutzen, setzen Sie einfach die CVSROOT Umgebungsvariable auf einen Anoncvs Server und geben beim Login mit cvs login das Passwort anoncvs an. Danach können Sie mit &man.cvs.1; wie auf jedes lokale Repository (allerdings nur lesend) zugreifen. cvs login speichert Passwörter zur Authentifizierung an einem CVS Server in der Datei .cvspass in Ihrem HOME-Verzeichnis. Wenn diese Datei beim ersten Benutzen von cvs login nicht existiert, erhalten Sie vielleicht eine Fehlermeldung. In diesem Fall legen Sie einfach eine leere .cvspass Datei an und melden sich erneut an. CVSup und Anoncvs bieten dieselbe Funktionalität, die folgenden Kriterien helfen Ihnen zu entscheiden, welche Methode Sie benutzen sollen. CVSup geht wesentlich effizienter mit Netzwerk-Ressourcen um und ist auch technisch ausgereifter. Allerdings müssen Sie zuerst einen speziellen Client installieren und konfigurieren, bevor Sie CVSup benutzen können. Weiterhin können Sie mit CVSup nur relativ große Teile der Quellen, die Sammlungen genannt werden, synchronisieren. Im Gegensatz dazu können Sie mit Anoncvs jede beliebige Datei oder indem Sie einfach den CVS Namen des Moduls angeben, ein beliebiges Programm, wie ls oder grep, bearbeiten. Natürlich können Sie mit Anoncvs nur lesend auf ein CVS Repository zugreifen. Wenn Sie lokal mit dem &os;-Repository entwickeln wollen, dann ist CVSup die einzige Wahl. <anchor id="anoncvs-usage">Benutzen von Anonymous CVS Setzen Sie einfach die CVSROOT Umgebungsvariable, um &man.cvs.1; das CVS Repository eines &os; Anoncvs-Servers bekannt zu geben. Zurzeit stehen folgende Server zur Verfügung: Frankreich: :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs (Das Passwort für pserver ist anoncvs, ssh-Zugriffe verwenden kein Passwort.) Japan: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs (Benutzen Sie cvs login und das Passwort anoncvs.) Taiwan: :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs (pserver: Benutzen Sie cvs login und ein beliebiges Passwort. ssh: kein Passwort.) SSH2 HostKey: 1024 02:ed:1b:17:d6:97:2b:58:5e:5c:e2:da:3b:89:88:26 /etc/ssh/ssh_host_rsa_key.pub SSH2 HostKey: 1024 e8:3b:29:7b:ca:9f:ac:e9:45:cb:c8:17:ae:9b:eb:55 /etc/ssh/ssh_host_dsa_key.pub USA: freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs (nur ssh ohne Passwort). SSH HostKey: 1024 a1:e7:46:de:fb:56:ef:05:bc:73:aa:91:09:da:f7:f4 root@sanmateo.ecn.purdue.edu SSH2 HostKey: 1024 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65 ssh_host_dsa_key.pub USA: anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (nur ssh ohne Passwort). SSH2 HostKey: 2048 53:1f:15:a3:72:5c:43:f6:44:0e:6a:e9:bb:f8:01:62 /etc/ssh/ssh_host_dsa_key.pub Mit CVS können Sie praktisch jede Version von &os;, die schon einmal existiert hat (oder in manchen Fällen existieren wird) auschecken. Sie sollten daher damit vertraut sein, wie Sie mit Tags unter &man.cvs.1; arbeiten (die Option). Zudem müssen Sie die Namen der Tags im &os;-Repository kennen. Es gibt zwei verschiedene TagsTags sind symbolische Namen, die im Repository vergeben werden. : Tags, die Revisionen bezeichnen und Tags, die Zweige bezeichnen. Die Ersten sind statisch und fest an eine Revision gebunden. Ein Tag, das einen Zweig bezeichnet, bezieht sich dagegen zu einem gegebenen Zeitpunkt immer auf die aktuellste Revision. Da ein Tag eines Zweiges nicht an eine bestimmte Revision gebunden ist, kann sich dessen Bedeutung von heute auf morgen ändern. In finden Sie eine Liste der gültigen Tags. Beachten Sie bitte, dass keines der Tags auf die Ports-Sammlung anwendbar ist, da diese nicht über Zweige verfügt. Wenn Sie ein Tag eines Zweiges verwenden, erhalten Sie die aktuellsten Dateien dieses Entwicklungszweiges. Wenn Sie eine frühere Revision erhalten möchten, können Sie zum Beispiel einen Zeitpunkt mit der Option angeben. Weitere Informationen dazu entnehmen Sie bitte &man.cvs.1;. Beispiele Im Folgenden finden Sie einige Beispiele für den Umgang mit Anonymous CVS. Sie sollten sich aber die Manualpage von &man.cvs.1; sorgfältig durchlesen, bevor Sie anfangen. &man.ls.1; von -CURRENT auschecken &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Wenn Sie dazu aufgefordert werden, benutzen Sie ein beliebiges Passwort. &prompt.user; cvs co ls Den <filename>src/</filename>-Baum über SSH auschecken &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be establiestablished. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. &man.ls.1; aus dem 6-STABLE-Zweig auschecken &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Wenn Sie dazu aufgefordert werden, benutzen Sie ein beliebiges Passwort. &prompt.user; cvs co -rRELENG_6 ls Änderungen in &man.ls.1; zwischen 5.3 RELEASE und 5.4 RELEASE (als unified diff) &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Wenn Sie dazu aufgefordert werden, benutzen Sie ein beliebiges Passwort. &prompt.user; cvs rdiff -u -rRELENG_5_3_0_RELEASE -rRELENG_5_4_0_RELEASE ls Gültige Modulnamen herausfinden &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Wenn Sie dazu aufgefordert werden, benutzen Sie ein beliebiges Passwort. &prompt.user; cvs co modules &prompt.user; more modules/modules Weitere Ressourcen Die folgenden Ressourcen sind nützlich, um den Umgang mit CVS zu lernen: CVS Tutorial von der California Polytechnic State University. CVS Home, die Homepage des CVS-Projekts. CVSweb das Web Interface zu CVS des &os; Projekts. CTM CTM Mit CTM Abkürzung für CVS Through eMail können Sie einen entfernten Verzeichnisbaum mit einem zentralen Baum synchronisieren. Es wurde extra zum Synchronisieren der &os; Quellen entwickelt, obwohl es mit der Zeit vielleicht auch andere Anwendungen geben wird. Zurzeit existiert leider so gut wie keine Dokumentation zum Erstellen der Deltas. Wenn Sie Hilfe benötigen oder CTM für andere Zwecke einsetzen wollen, wenden Sie sich bitte an die Mailingliste &a.ctm-users.name;. Warum soll ich <application>CTM</application> benutzen? Mit CTM erhalten Sie eine lokale Kopie des &os;-Quellbaums, den es in mehreren Varianten gibt. Sie können das ganze Repository oder nur einen Zweig spiegeln. Wenn Sie ein aktiver &os;-Entwickler mit einer schlechten oder gar keiner TCP/IP Verbindung sind, oder die Änderungen einfach automatisch zugesandt bekommen wollen, dann ist CTM das Richtige für Sie. Für die Zweige mit der meisten Aktivität müssen Sie sich täglich bis zu drei Deltas beschaffen, Sie sollten allerdings erwägen, die Deltas automatisch über E-Mail zu beziehen. Die Größe der Updates wird so klein wie möglich gehalten. Normalerweise sind sie kleiner als 5 kB, manchmal sind sie 10-50 kB groß (etwa jedes 10. Update) und ab und an werden Sie auch einmal ein Update mit 100 kB oder mehr erhalten. Sie sollten sich über die Vorbehalte gegen die Verwendung der Quellen anstelle eines offiziellen Releases bewusst sein. Das trifft besonders auf &os.current; zu, lesen Sie dazu bitte den Abschnitt &os.current;. Was brauche ich, um <application>CTM</application> zu benutzen? Zwei Sachen: Das CTM Programm und die initialen Deltas, von denen aus Sie auf die aktuellen Stände kommen. CTM ist schon seit der Version 2.0 Teil des &os;-Basissystems. Sie finden es in /usr/src/usr.sbin/ctm, wenn Sie eine Kopie der Quellen besitzen. Die Deltas, die CTM verarbeitet, können Sie über FTP oder E-Mail beziehen. Wenn Sie über einen FTP Zugang zum Internet verfügen, erhalten Sie die Deltas unter der folgenden URL: Die Deltas werden auch von CTM Spiegeln bereitgehalten. Wechseln Sie in das passende Verzeichnisse zum Beispiel src-cur für &os.current; und laden Sie sich von dort die Deltas herunter. Sie können die Deltas auch über E-Mail beziehen. Abonnieren Sie dazu eine der CTM-Verteilerlisten. Über &a.ctm-cvs-cur.name; erhalten Sie den kompletten CVS-Baum, über &a.ctm-src-cur.name; erhalten Sie &os.current; und über &a.ctm-src-4.name; erhalten Sie den &os; 4.X-Zweig. Wenn Sie nicht wissen, wie Sie eine der Mailinglisten abonnieren, folgen Sie einem der Verweise von oben oder besuchen Sie die Seite &a.mailman.lists.link;. Weitere Informationen erhalten Sie, wenn Sie dort auf die gewünschte Liste klicken. Benutzen Sie ctm_rmail, um die CTM Updates, die Sie per E-Mail empfangen, auszupacken und anzuwenden. Wenn Sie diesen Prozess automatisiert ablaufen lassen möchten, können Sie dazu einen Eintrag in /etc/aliases verwenden. Genauere Informationen finden Sie in der Manualpage von ctm_rmail. Sie sollten die Mailingliste &a.ctm-announce.name; abonnieren, egal wie Sie die CTM-Deltas erhalten. Ankündigungen, die den Betrieb des CTM-Systems betreffen, werden nur auf dieser Liste bekannt gegeben. Klicken Sie auf den Namen der Liste oder besuchen Sie die Seite &a.mailman.lists.link;, um diese Liste zu abonnieren. Initialisieren von <application>CTM</application> Bevor Sie die CTM Deltas benutzen können, brauchen Sie einen Startpunkt, auf den die nachfolgenden Deltas angewendet werden. Sie können natürlich mit einem leeren Verzeichnis beginnen. In diesem Fall benötigen Sie ein XEmpty-Delta, mit dem Sie den CTM-Verzeichnisbaum initialisieren. Wenn Sie Glück haben, finden Sie ein XEmpty-Delta, mit dem sie beginnen können, auf einer der CDs Ihrer Distribution. Da die Verzeichnisbäume mehrere Megabyte groß sind, sollten Sie nach Möglichkeit etwas schon vorhandenes benutzen. Wenn Sie eine -RELEASE CD besitzen, können Sie die Quellen von dieser CD benutzen. Sie ersparen sich damit das Übertragen großer Datenmengen. Die Deltas, mit denen Sie beginnen können, enthalten ein X in ihrem Namen, wie in src-cur.3210XEmpty.gz. Hinter dem X wird der Startpunkt der Deltas angegeben, in diesem Fall steht Empty für ein leeres Verzeichnis. Nach etwa 100 Deltas wird ein neues XEmpty-Delta erstellt. Mit ungefähr 75 Megabyte komprimierter Daten sind diese XEmpty-Deltas übrigens sehr groß. Nachdem Sie Ihren Startpunkt festgelegt haben, benötigen Sie alle Deltas mit einer höheren Nummer. Benutzen von <application>CTM</application> Um ein Delta einzuspielen, benutzen Sie das folgende Kommando: &prompt.root; cd /Pfad/zu/den/Quellen &prompt.root; ctm -v -v /Pfad/zu/den/Deltas/src-xxx.* CTM kann mit Deltas arbeiten, die mit gzip komprimiert wurden. Sie brauchen die Deltas vorher nicht mit gunzip zu dekomprimieren und sparen damit Plattenplatz. Ihr Quellbaum wird erst dann verändert, wenn CTM die Deltas sauber verarbeiten kann. Die Integrität der Deltas und ihre Anwendbarkeit auf den Quellbaum lassen sich durch die Angabe des Schalters -c überprüfen, CTM ändert in diesem Fall Ihren Quellbaum nicht. CTM verfügt über weitere Kommandozeilenoptionen, Informationen dazu finden Sie in der Manualpage oder dem Quellcode. Das war schon alles. Um Ihre Quellen aktuell zu halten, verwenden Sie CTM jedes Mal, wenn Sie neue Deltas bekommen. Löschen Sie die Deltas nicht, wenn Sie diese nur schwer wieder beschaffen können. Behalten Sie sie für den Fall, das etwas passiert. Auch wenn Sie nur Disketten besitzen, sollten Sie erwägen, die Deltas mit fdwrite zu sichern. Umgang mit lokalen Änderungen Entwickler wollen mit den Dateien im Quellbaum experimentieren und diese verändern. In beschränkter Weise werden lokale Änderungen von CTM unterstützt. Wenn CTM die Datei foo bearbeiten will, überprüft es zuerst ob die Datei foo.ctm existiert. Wenn diese Datei existiert, werden Änderungen in ihr anstatt in foo vorgenommen. Mit diesem Verfahren ist eine leichte Handhabung lokaler Änderungen möglich. Kopieren Sie die Dateien, die Sie ändern möchten, in Dateien, die das Suffix .ctm tragen. Sie können dann ungestört mit dem Quellcode arbeiten, während CTM die .ctm Dateien aktualisiert. Weitere <application>CTM</application>-Optionen Was wird aktualisiert? Eine Liste der Änderungen, die CTM an Ihrem Quellbaum vornehmen wird, erhalten Sie, wenn Sie die Option angeben. Das ist nützlich, wenn Sie Logs über die Änderungen führen wollen, geänderte Dateien vor- oder nachbearbeiten wollen, oder einfach ein bisschen paranoid sind. Sicherungen vor einer Aktualisierung erstellen Sie wollen vielleicht die Dateien, die durch eine CTM Aktualisierung verändert werden, sichern. Mit weisen Sie CTM an, alle Dateien, die durch ein CTM Delta verändert würden, nach backup-file zu sichern. Dateien ausschließen Manchmal wollen Sie nur bestimmte Teile aktualisieren oder nur bestimmte Dateien aus einer Folge von Deltas extrahieren. Sie können die Liste der Dateien, mit denen CTM arbeitet, einschränken, indem Sie reguläre Ausdrücke mit den Optionen und angeben. Wenn Sie eine aktuelle Kopie von lib/libc/Makefile aus den gesicherten CTM Deltas erhalten wollen, setzen Sie das folgende Kommando ab: &prompt.root; cd /wo/Sie/es/auspacken/wollen/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* Die Optionen und werden in der Reihenfolge angewandt, in der sie auf der Kommandozeile angegeben wurden. Eine Datei wird nur dann von CTM verarbeitet, wenn dies nach der Anwendung der Optionen und noch erlaubt ist. Pläne für <application>CTM</application> Mehrere: Hinzufügen eines Authentifizierungsmechanismus, damit gefälschte CTM-Deltas erkannt werden können. Aufräumen der CTM-Optionen, die mit der Zeit unübersichtlich und irreführend wurden. Verschiedenes Es gibt Deltas für die Ports-Sammlung, die aber nicht intensiv genutzt werden. CTM-Spiegel Die CTM-Deltas können Sie mit anonymous FTP von den folgenden Spiegeln beziehen. Versuchen Sie bitte einen Spiegel in Ihrer Nähe zu benutzen. Bei Problemen wenden Sie sich bitte an die Mailingliste &a.ctm-users.name;. Kalifornien, Bay Area, Offizieller Server Südafrika, Backup-Server für alte Deltas Taiwan/R.O.C. Wenn die Liste keinen Spiegel in Ihrer Nähe enthält oder Sie Probleme mit dem ausgewählten Spiegel haben, versuchen Sie einen Spiegel mit einer Suchmaschine, wie alltheweb, zu finden. Benutzen von CVSup Einführung CVSup ist eine Anwendung, die Verzeichnisbäume von einem entfernten CVS-Server bereitstellt und aktualisiert. Die Quellen von &os; werden in einem CVS-Repository auf einer Entwicklungsmaschine in Kalifornien gepflegt. Mit CVSup können sich &os;-Benutzer den eigenen Quellbaum auf aktuellem Stand halten. Zum Aktualisieren benutzt CVSup die Pull-Methode, bei der die Aktualisierungen vom Client angefragt werden. Der Server wartet dabei passiv auf Anfragen von Clients, das heißt er verschickt nicht unaufgefordert Aktualisierungen. Somit gehen alle Anfragen vom Client aus und die Benutzer müssen CVSup entweder manuell starten oder einen cron Job einrichten, um regelmäßig Aktualisierungen zu erhalten. CVSup in genau dieser Schreibweise bezeichnet die Anwendung, die aus dem Client cvsup und dem Server cvsupd besteht. cvsup läuft auf den Maschinen der Benutzer, cvsupd läuft auf jedem der &os;-Spiegel. Wenn Sie die &os;-Dokumentation und die Mailinglisten lesen, werden Sie oft auf Sup, dem Vorgänger von CVSup stoßen. CVSup wird in gleicher Weise wie Sup benutzt und verfügt sogar über Konfigurationsdateien, die kompatibel zu denen von Sup sind. Da CVSup schneller und flexibler als Sup ist, wird Sup vom &os; Project nicht mehr benutzt. Mit csup gibt es in inzwischen auch eine in C geschriebene Neuimplementierung von CVSup. Der größte Vorteil dieser neuen Version ist neben einer höheren Geschwindigkeit der, dass dieses Programm nicht von der Sprache Modula-3 abhängig ist und Sie daher dieses Paket nicht mitinstallieren müssen. Ab &os; 6.2 ist csup bereits im Basissystem enthalten und kann sofort verwendet werden. Verwenden Sie hingegen eine ältere &os;-Version, können Sie &man.csup.1; über den Port net/csup installieren. Alternativ können Sie zur Installation auch ein vorkompiliertes - Paket (Package) verwenden. csup - unterstützt allerdings keinen CVS-Modus. Wollen Sie - komplette Repositories spiegeln, müssen Sie also - weiterhin CVSup einsetzen. + Paket (Package) verwenden. Wollen Sie künftig csup einsetzen, überspringen Sie in den folgenden Ausführungen einfach den Abschnitt zur Installation von CVSup und ersetzen alle Vorkommen von CVSup durch csup. Installation von <application>CVSup</application> CVSup können Sie leicht installieren, wenn Sie das vorkompilierte Paket net/cvsup aus der Ports-Sammlung benutzen. Alternativ können Sie net/cvsup auch ausgehend von den Quellen bauen, doch seien Sie gewarnt: net/cvsup hängt vom Modula-3 System ab, das viel Zeit und Platz zum Herunterladen und Bauen braucht. Wenn Sie CVSup auf einer Maschine ohne &xfree86; oder &xorg;, beispielsweise einem Server, benutzen, stellen Sie sicher, dass Sie den Port ohne das CVSup-GUI, net/cvsup-without-gui verwenden. Wollen Sie csup unter &os; 6.1 oder älter installieren, können Sie dazu das vorkompilierte Paket net/csup oder den Port net/csup (zur Installation aus den Quellen) verwenden. Konfiguration von CVSup Das Verhalten von CVSup wird mit einer Konfigurationsdatei gesteuert, die supfile genannt wird. Beispiele für Konfigurationsdateien finden Sie in dem Verzeichnis . Ein supfile enthält die folgenden Informationen: Welche Dateien Sie erhalten wollen. Welche Versionen der Dateien Sie benötigen. Woher Sie die Dateien beziehen wollen. Wo Sie die erhaltenen Dateien speichern. Wo Sie die Status-Dateien aufbewahren wollen. In den folgenden Abschnitten erstellen wir ein typisches supfile indem wir nach und nach diese Punkte klären. Zuerst beschreiben wir aber den Aufbau dieser Konfigurationsdatei. Ein supfile ist eine Textdatei. Kommentare beginnen mit einem # und gelten bis zum Zeilenende. Leerzeilen und Zeilen, die nur Kommentare enthalten, werden ignoriert. Die anderen Zeilen legen die Dateien fest, die ein Benutzer erhalten will. Der Server organisiert verschiedene Dateien in einer Sammlung, deren Name auf einer Zeile angegeben wird. Nach dem Namen der Sammlung können mehrere durch Leerzeichen getrennte Felder folgen, die die oben angesprochenen Informationen festlegen. Es gibt zwei Arten von Feldern: Felder, die Optionen festlegen und Felder mit Parametern. Optionen bestehen aus einem Schlüsselwort, wie oder und stehen alleine. Ein Parameterfeld beginnt mit einem Schlüsselwort, dem = und ein Parameter, wie in , folgt. Dieses Feld darf keine Leerzeichen enthalten. In einem supfile werden normalerweise mehrere Sammlungen angefordert. Die erforderlichen Felder können explizit für jede Sammlung angegeben werden, dann werden jedoch die Zeilen ziemlich lang. Außerdem ist dieses Vorgehen sehr unhandlich, da die meisten Felder für alle Sammlungen gleich sind. CVSup bietet die Möglichkeit, Vorgaben für die Felder der Sammlungen festzulegen. Zeilen, die mit der Pseudo-Sammlung *default beginnen, legen Optionen und Parameter für nachfolgende Sammlungen im supfile fest. Der Vorgabewert kann in der Zeile einer bestimmten Sammlung überschrieben werden. Durch Hinzufügen weiterer *default Zeilen können die Vorgaben auch mitten im supfile überschrieben oder erweitert werden. Mit diesem Wissen können wir nun ein supfile erstellen, das den Quellbaum von &os;-CURRENT anfordert und aktualisiert. Welche Dateien wollen Sie empfangen? Dateien werden von CVSup in Sammlungen organisiert. Die erhältlichen Sammlungen werden später beschrieben. Wir wollen den Quellbaum von &os; empfangen, der in der Sammlung src-all enthalten ist. Das supfile enthält pro Zeile eine Sammlung, in diesem Fall also nur eine einzige Zeile: src-all Welche Versionen der Dateien werden benötigt? Mit CVSup können Sie jede Version der Quellen bekommen, da der cvsupd-Server seine Daten direkt aus dem CVS-Repository bezieht. Sie können die benötigten Versionen in den Parameterfeldern tag= und angeben. Achten Sie darauf, dass Sie das richtige tag=-Feld angeben. Einige Tags sind nur für spezielle Sammlungen gültig. Wenn Sie ein falsches Tag angeben oder sich verschreiben, wird CVSup Dateien löschen, die Sie wahrscheinlich gar nicht löschen wollten. Achten Sie insbesondere bei den ports-*-Sammlungen darauf, ausschließlich tag=. zu verwenden. Mit tag= wird ein symbolischer Name aus dem Repository angegeben. Es gibt zwei verschiedene Tags: Tags, die Revisionen bezeichnen und Tags, die Zweige bezeichnen. Die ersteren sind statisch und fest an eine Revision gebunden. Ein Tag, das einen Zweig bezeichnet, bezieht sich dagegen zu einem gegebenen Zeitpunkt immer auf die aktuellste Revision. Da ein Tag eines Zweiges nicht an eine bestimmte Revision gebunden ist, kann sich dessen Bedeutung von heute auf morgen ändern. zählt für Benutzer relevante Tags auf. Wenn Sie in der Konfigurationsdatei ein Tag, wie RELENG_4, angeben, müssen Sie diesem tag= vorstellen: tag=RELENG_4. Denken Sie daran, dass es für die Ports-Sammlung nur tag=. gibt. Achten Sie darauf, dass Sie den Namen eines Tags richtig angeben. CVSup kann nicht zwischen richtigen und falschen Tags unterscheiden. Wenn Sie sich bei der Angabe eines Tags vertippen, nimmt CVSup an, Sie hätten ein gültiges Tag angegeben, dem nur keine Dateien zugeordnet sind. Die Folge davon ist, dass Ihre vorhandenen Quellen gelöscht werden. Wenn Sie ein Tag angeben, das sich auf einen Zweig bezieht, erhalten Sie die aktuellsten Revisionen der Dateien auf diesem Zweig. Wenn Sie eine frühere Revision erhalten möchten, können Sie diese im Feld angeben. Einzelheiten dazu finden Sie in der Manualpage von cvsup. Wir möchten gerne &os;-CURRENT beziehen und fügen die folgende Zeile am Anfang der Konfigurationsdatei ein: *default tag=. Eine wichtige Ausnahme ist wenn Sie weder ein tag=-Feld noch ein date=-Feld angeben. In diesem Fall erhalten Sie anstelle einer speziellen Revision die wirklichen RCS-Dateien aus dem CVS-Repository des Servers. Diese Vorgehensweise wird von Entwicklern bevorzugt, da sie mit einem eigenen Repository leicht die Entwicklungsgeschichte und Veränderungen von Dateien verfolgen können. Dieser Vorteil muss allerdings mit sehr viel Plattenplatz bezahlt werden. Woher sollen die Dateien bezogen werden? Im host=-Feld wird angegeben, woher cvsup die Dateien holen soll. Sie können hier jeden der CVSup-Spiegel angeben, doch sollten Sie einen Server in Ihrer Nähe auswählen. Für dieses Beispiel wollen wir den erfundenen Server cvsup99.FreeBSD.org verwenden: *default host=cvsup99.FreeBSD.org Bevor Sie CVSup laufen lassen, sollten Sie hier einen existierenden Server einsetzen. Den zu verwendenden Server können Sie auf der Kommandozeile mit überschreiben. Wo sollen die Dateien gespeichert werden? Im prefix=-Feld teilen Sie cvsup mit, wo die Dateien gespeichert werden sollen. In diesem Beispiel werden wir die Quelldateien direkt im Verzeichnisbaum für Quellen /usr/src ablegen. Das Verzeichnis src ist schon in der Sammlung, die wir beziehen enthalten, so dass wir die folgende Zeile angeben: *default prefix=/usr Wo sollen die Statusinformationen von cvsup gespeichert werden? cvsup legt in einem Verzeichnis Statusinformationen ab, die festhalten, welche Versionen schon empfangen wurden. Wir verwenden das Verzeichnis /var/db: *default base=/var/db Wenn das Verzeichnis für die Statusinformationen nicht existiert, sollten Sie es jetzt anlegen, da cvsup ohne dieses Verzeichnis nicht startet. Verschiedene Einstellungen: Eine weitere Zeile sollte normalerweise in jedem supfile sein: *default release=cvs delete use-rel-suffix compress Mit release=cvs wird angegeben, dass der Server das &os;-Haupt-Repository abfragen soll, was praktisch immer der Fall ist (die Ausnahmen werden in diesem Text nicht diskutiert). delete erlaubt es CVSup, Dateien zu löschen. Diese Option sollten Sie immer angeben, damit CVSup Ihren Quellbaum auch wirklich aktuell halten kann. CVSup löscht nur Dateien für die es auch verantwortlich ist. Andere Dateien, die sich in einem Baum unter Kontrolle von CVSup befinden, werden nicht verändert. Wenn Sie wirklich etwas über das obskure use-rel-suffix erfahren wollen, lesen Sie bitte in der Manualpage nach, ansonsten geben Sie es einfach an und vergessen es. Wenn Sie compress angeben, werden Daten auf dem Kommunikationskanal komprimiert. Wenn Sie über eine T1-Leitung oder eine schnellere Netzanbindung verfügen, brauchen Sie diese Option vielleicht nicht. In allen anderen Fällen beschleunigt sie aber den Ablauf. Zusammenfassung: Das vollständige supfile unseres Beispiels sieht nun so aus: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all Die <filename>refuse</filename> Datei CVSup benutzt die Pull-Methode, das heißt wenn sich ein Client mit einem Server verbindet, erhält er eine Liste der verfügbaren Sammlungen und wählt aus diesen die herunterzuladenden Dateien aus. In der Voreinstellung wählt der Client alle Dateien aus, die zu einer gegebenen Sammlung und zu einem gegebenen Tag passen. Dieses Verhalten ist aber nicht immer erwünscht, besonders wenn Sie die doc, ports oder www Verzeichnisbäume synchronisieren. Die wenigsten Leute beherrschen vier oder fünf Sprachen und benötigen Dateien mit speziellen Anpassungen für eine Sprache. Wenn Sie die Ports-Sammlung synchronisieren, können Sie anstelle von ports-all einzelne Ports, wie ports-astrology oder ports-biology angeben. Die doc und www Verzeichnisbäume verfügen aber nicht über Sammlungen für spezielle Sprachen. In diesem Fall müssen Sie eines der vielen eleganten Merkmale von CVSup benutzen: Die refuse Datei. Mit einer refuse Datei können Sie bestimmte Dateien einer Sammlung von der Übertragung ausschließen. Der Ort der refuse ist base/sup/refuse, wobei base in Ihrem supfile festgelegt wurde. Wir verwenden das Verzeichnis /var/db, der Ort der refuse Datei ist daher /var/db/sup/refuse. Das Format der refuse Datei ist einfach: Sie enthält eine Liste der Dateien und Verzeichnisse, die Sie nicht herunterladen wollen. Wenn Sie zum Beispiel die Dokumentation nicht in anderen Sprachen als Englisch lesen wollen, könnte Ihre refuse-Datei wie folgt aussehen: doc/bn_* doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/hu_* doc/it_* doc/ja_* doc_mn_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/tr_* doc/zh_* Die Aufzählung setzt sich für andere Sprachen fort. Eine vollständige Liste finden Sie im &os; CVS Repository. Die refuse Datei spart Anwendern von CVSup, die über eine langsame Internetanbindung verfügen oder deren Internetverbindung zeitlich abgerechnet wird, wertvolle Zeit, da sie Dateien, die sie nicht benötigen, nicht mehr herunterladen müssen. Weitere Informationen zu refuse Dateien und anderen Eigenschaften von CVSup entnehmen Sie bitte der Manualpage. Ausführen von <application>CVSup</application> Wir können nun eine Aktualisierung mit der folgenden Kommandozeile starten: &prompt.root; cvsup supfile supfile gibt dabei das eben erstelle supfile an. Wenn Sie X11 benutzen, wird cvsup ein GUI starten. Drücken Sie go und schauen Sie zu. Das Beispiel aktualisiert die Dateien im Verzeichnisbaum /usr/src. Sie müssen cvsup als root starten, damit Sie die nötigen Rechte haben, die Dateien zu aktualisieren. Sie sind vielleicht ein bisschen nervös weil Sie das Programm zum ersten Mal anwenden und möchten zuerst einmal einen Testlauf durchführen. Legen Sie dazu ein temporäres Verzeichnis an und übergeben es auf der Kommandozeile von cvsup: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest Aktualisierungen werden dann nur in dem angegebenen Verzeichnis vorgenommen. CVSup untersucht die Dateien in /usr/src, wird aber keine dieser Dateien verändern. Die veränderten Dateien finden Sie stattdessen in /var/tmp/dest/usr/src. Die Statusdateien von CVSup werden ebenfalls nicht geändert, sondern in dem angegebenen Verzeichnis abgelegt. Wenn Sie Leseberechtigung in /usr/src haben, brauchen Sie das Programm noch nicht einmal unter root laufen zu lassen. Wenn Sie X11 nicht benutzen wollen oder keine GUIs mögen, sollten Sie cvsup wie folgt aufrufen: &prompt.root; cvsup -g -L 2 supfile verhindert den Start des GUIs. Wenn Sie kein X11 laufen haben, passiert das automatisch, ansonsten müssen Sie diesen Schalter angeben. Mit gibt CVSup Einzelheiten zu jeder Aktualisierung aus. Die Wortfülle der Meldungen können Sie von bis einstellen. In der Voreinstellung werden nur Fehlermeldungen ausgegeben. Eine Zusammenfassung der Optionen von CVSup erhalten Sie mit cvsup -H. Genauere Informationen finden Sie in der Manualpage von CVSup. Wenn Sie mit dem Ablauf der Aktualisierung zufrieden sind, können Sie CVSup regelmäßig aus &man.cron.8; ausführen. In diesem Fall sollten Sie natürlich nicht das GUI benutzen. <application>CVSup</application> Sammlungen Die CVSup Sammlungen sind hierarchisch organisiert. Es gibt wenige große Sammlungen, die in kleinere Teilsammlungen unterteilt sind. Wenn Sie eine große Sammlung beziehen, entspricht das dem Beziehen aller Teilsammlungen. Der Hierarchie der Sammlung wird in der folgenden Aufzählung durch Einrückungen dargestellt. Die am häufigsten benutzen Sammlungen sind src-all und ports-all. Die anderen Sammlungen werden von wenigen Leuten zu speziellen Zwecken benutzt und es kann sein, dass diese nicht auf allen Spiegeln zur Verfügung stehen. cvs-all release=cvs Das &os;-Haupt-Repository einschließlich der Kryptographie-Module. distrib release=cvs Dateien, die zum Verteilen und Spiegeln von &os; benötigt werden. doc-all release=cvs Quellen des &os;-Handbuchs und weiterer Dokumentation. Diese Sammlung enthält nicht die &os;-Webseite. ports-all release=cvs Die &os;-Ports-Sammlung. Wenn Sie nicht die gesamte Ports-Sammlung (ports-all) aktualisieren wollen, sondern nur eine der nachstehend aufgeführten Teilsammlungen, aktualisieren Sie immer die Teilsammlung ports-base. Diese Teilsammlung enthält das Bausystem der Ports. Immer wenn ports-base geändert wird, ist es so gut wie sicher, dass diese Änderung auch tatsächlich von einem Port benutzt wird. Der Bau eines Ports, der auf Änderungen im Bausystem angewiesen wird, wird fehlschlagen, wenn das Bausystem noch auf einem alten Stand ist. Aktualisieren Sie vor allen Dingen ports-base, wenn Sie bei einem Bau merkwürdige Fehlermeldungen erhalten und kein aktuelles Bausystem benutzen. Wenn Sie die Datei ports/INDEX selbst erzeugen, brauchen Sie unbedingt die Sammlung ports-all (den ganzen Ports-Baum). Es ist nicht möglich, ports/INDEX nur mit einem Teilbaum zu erstellen. Lesen Sie dazu bitte die FAQ. ports-accessibility release=cvs Werkzeuge für behinderte Benutzer. ports-arabic release=cvs Arabische Sprachunterstützung. ports-archivers release=cvs Werkzeuge zum Archivieren. ports-astro release=cvs Astronomie-Programme. ports-audio release=cvs Audio-Programme. ports-base release=cvs Das Bausystem der Ports-Sammlung. Dazu gehören verschiedene Dateien in den Unterverzeichnissen Mk/ und Tools/ von /usr/ports. Aktualisieren Sie diese Teilsammlung jedes Mal, wenn Sie einen Teil der Ports-Sammlung aktualisieren. Lesen Sie dazu auch den obigen Hinweis zur Ports-Sammlung. ports-benchmarks release=cvs Benchmarks. ports-biology release=cvs Biologie. ports-cad release=cvs Computer Aided Design Werkzeuge. ports-chinese release=cvs Chinesische Sprachunterstützung. ports-comms release=cvs Programme zur Datenkommunikation. ports-converters release=cvs Zeichensatz Konvertierer. ports-databases release=cvs Datenbanken. ports-deskutils release=cvs Sachen, die sich vor dem Computer-Zeitalter auf dem Schreibtisch befanden. ports-devel release=cvs Werkzeuge für Entwickler. ports-dns release=cvs Software für DNS. ports-editors release=cvs Editoren. ports-emulators release=cvs Programme, die andere Betriebssysteme emulieren. ports-finance release=cvs Finanz-Anwendungen. ports-ftp release=cvs Werkzeuge für FTP Clients und Server. ports-games release=cvs Spiele. ports-german release=cvs Deutsche Sprachunterstützung. ports-graphics release=cvs Graphik-Programme. ports-hebrew release=cvs Hebräische Sprachunterstützung. ports-hungarian release=cvs Ungarische Sprachunterstützung. ports-irc release=cvs Internet Relay Chat Werkzeuge. ports-japanese release=cvs Japanische Sprachunterstützung. ports-java release=cvs &java; Werkzeuge. ports-korean release=cvs Koreanische Sprachunterstützung. ports-lang release=cvs Programmiersprachen. ports-mail release=cvs E-Mail Programme. ports-math release=cvs Programme zur numerischen Mathematik. ports-mbone release=cvs MBone Anwendungen. ports-misc release=cvs Verschiedene Werkzeuge. ports-multimedia release=cvs Multimedia-Anwendungen. ports-net release=cvs Netzwerk-Programme. ports-net-im release=cvs Diverse Instant-Messenger. ports-net-mgmt release=cvs Software zum Verwalten von Netzwerken. ports-net-p2p release=cvs Software für die Nutzung von Peer-to-Peer-Netzwerken. ports-news release=cvs USENET News Werkzeuge. ports-palm release=cvs Programme für den Palm. ports-polish release=cvs Polnische Sprachunterstützung. ports-ports-mgmt release=cvs Werkzeuge zum Management von Ports und Paketen. ports-portuguese release=cvs Portugiesische Sprachunterstützung. ports-print release=cvs Druckprogramme. ports-russian release=cvs Russische Sprachunterstützung. ports-science release=cvs Wissenschaft. ports-security release=cvs Werkzeuge zum Thema Sicherheit. ports-shells release=cvs Kommandozeilen-Shells. ports-sysutils release=cvs System-Werkzeuge. ports-textproc release=cvs Programme zur Textverarbeitung (ohne Desktop Publishing). ports-ukrainian release=cvs Ukrainische Sprachunterstützung. ports-vietnamese release=cvs Vietnamesische Sprachunterstützung. ports-www release=cvs Software rund um das World Wide Web. ports-x11 release=cvs X-Window Programme. ports-x11-clocks release=cvs X11-Uhren. ports-x11-drivers release=cvs X11-Treiber. ports-x11-fm release=cvs X11-Dateiverwalter. ports-x11-fonts release=cvs X11-Zeichensätze und Werkzeuge dazu. ports-x11-toolkits release=cvs X11-Werkzeuge. ports-x11-servers release=cvs X11-Server. ports-x11-themes release=cvs X11-Themes. ports-x11-wm release=cvs X11-Fensterverwalter. projects-all release=cvs Quelltexte der verschiedenen &os;-Projekte. src-all release=cvs Die &os;-Quellen einschließlich der Kryptographie-Module. src-base release=cvs Verschiedene Dateien unter /usr/src. src-bin release=cvs Benutzer-Werkzeuge die im Einzelbenutzermodus gebraucht werden (/usr/src/bin). src-cddl release=cvs Werkzeuge und Bibliotheken, die der CDDL-Lizenz unterliegen (/usr/src/cddl). src-contrib release=cvs Werkzeuge und Bibliotheken, die nicht aus dem &os; Project stammen und wenig verändert übernommen werden. (/usr/src/contrib). src-crypto release=cvs Kryptographische Werkzeuge und Bibliotheken, die nicht aus dem &os; Project stammen und wenig verändert übernommen werden. (/usr/src/crypto). src-eBones release=cvs Kerberos und DES (/usr/src/eBones). Wird in aktuellen Releases von &os; nicht benutzt. src-etc release=cvs Konfigurationsdateien des Systems (/usr/src/etc). src-games release=cvs Spiele (/usr/src/games). src-gnu release=cvs Werkzeuge, die unter der GNU Public License stehen (/usr/src/gnu). src-include release=cvs Header Dateien (/usr/src/include). src-kerberos5 release=cvs Kerberos5 (/usr/src/kerberos5). src-kerberosIV release=cvs KerberosIV (/usr/src/kerberosIV). src-lib release=cvs Bibliotheken (/usr/src/lib). src-libexec release=cvs Systemprogramme, die von anderen Programmen ausgeführt werden (/usr/src/libexec). src-release release=cvs Dateien, die zum Erstellen eines &os; Releases notwendig sind (/usr/src/release). src-rescue release=cvs Statisch gelinkte Programme zur Wiederherstellung eines defekten Systems. Lesen Sie dazu auch die Manualpage &man.rescue.8; (/usr/src/rescue). src-sbin release=cvs Werkzeuge für den Einzelbenutzermodus (/usr/src/sbin). src-secure release=cvs Kryptographische Bibliotheken und Befehle (/usr/src/secure). src-share release=cvs Dateien, die von mehreren Systemen gemeinsam benutzt werden können (/usr/src/share). src-sys release=cvs Der Kernel (/usr/src/sys). src-sys-crypto release=cvs Kryptographie Quellen des Kernels (/usr/src/sys/crypto). src-tools release=cvs Verschiedene Werkzeuge zur Pflege von &os; (/usr/src/tools). src-usrbin release=cvs Benutzer-Werkzeuge (/usr/src/usr.bin). src-usrsbin release=cvs System-Werkzeuge (/usr/src/usr.sbin). www release=cvs Die Quellen der &os;-WWW-Seite. distrib release=self Die Konfigurationsdateien des CVSup Servers. Diese werden von den CVSup benutzt. gnats release=current Die GNATS Datenbank, in der Problemberichte verwaltet werden. mail-archive release=current Das Archiv der &os;-Mailinglisten. www release=current Die formatierten Dateien der &os;-WWW-Seite (nicht die Quellen). Diese werden von den WWW-Spiegeln benutzt. Weiterführende Informationen Die CVSup FAQ und weitere Informationen über CVSup finden Sie auf The CVSup Home Page. &os; spezifische Diskussionen über CVSup finden auf der Mailingliste &a.hackers; statt. Dort und auf der Liste &a.announce; werden neue Versionen von CVSup angekündigt. Bei Fragen und Problemberichten zu CVSup lesen Sie bitte die CVSup FAQ. CVSup-Server Die folgende Aufzählung enthält CVSup Server für &os;: &chap.mirrors.cvsup.inc; CVS-Tags Wenn Sie Quellen mit CVS oder CVSup erhalten oder aktualisieren wollen, müssen Sie ein Tag angeben. Ein Tag kann einen bestimmten &os;-Zweig oder einen bestimmten Zeitpunkt (Release-Tag) bestimmen. Tags für Zweige Mit Ausnahme von HEAD (das immer ein gültiges Tag ist), können die folgenden Tags nur im src/-Quellbaum verwendet werden. Die Quellbäume ports/, doc/ und www/ sind nicht verzweigt. HEAD Symbolischer Name für den Hauptzweig, auch &os.current; genannt. Dies ist die Vorgabe, wenn keine Revision angegeben wird. In CVSup wird dieses Tag mit einem . (Punkt) bezeichnet. In CVS ist das die Vorgabe, wenn Sie kein Tag oder eine Revision angeben. Außer Sie wollen einen -STABLE Rechner auf -CURRENT aktualisieren, ist es nicht ratsam, die -CURRENT Quellen auf einem -STABLE Rechner einzuspielen. RELENG_8 Der Entwicklungszweig für &os;-8.X, auch bekannt als &os; 8-STABLE. RELENG_8_0 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 8.0 durchgeführt werden. RELENG_7 Der Entwicklungszweig für &os;-7.X, auch als &os; 7-STABLE bekannt. RELENG_7_3 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 7.3 durchgeführt werden. RELENG_7_2 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 7.2 durchgeführt werden. RELENG_7_1 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 7.1 durchgeführt werden. RELENG_7_0 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 7.0 durchgeführt werden. RELENG_6 Der Entwicklungszweig für &os;-6.X, auch als &os; 6-STABLE bekannt. RELENG_6_4 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 6.4 durchgeführt werden. RELENG_6_3 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 6.3 durchgeführt werden. RELENG_6_2 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 6.2 durchgeführt werden. RELENG_6_1 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 6.1 durchgeführt werden. RELENG_6_0 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 6.0 durchgeführt werden. RELENG_5 Der &os; 5.X Entwicklungszweig, der auch &os; 5-STABLE genannt wird. RELENG_5_5 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 5.5 durchgeführt werden. RELENG_5_4 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 5.4 durchgeführt werden. RELENG_5_3 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 5.3 durchgeführt werden. RELENG_5_2 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 5.2 und &os; 5.2.1 durchgeführt werden. RELENG_5_1 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 5.1 durchgeführt werden. RELENG_5_0 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 5.0 durchgeführt werden. RELENG_4 Der &os; 4.X Entwicklungszweig, der auch &os; 4-STABLE genannt wird. RELENG_4_11 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 4.11 durchgeführt werden. RELENG_4_10 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 4.10 durchgeführt werden. RELENG_4_9 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 4.9 durchgeführt werden. RELENG_4_8 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 4.8 durchgeführt werden. RELENG_4_7 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 4.7 durchgeführt werden. RELENG_4_6 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 4.6 und &os; 4.6.2 durchgeführt werden. RELENG_4_5 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 4.5 durchgeführt werden. RELENG_4_4 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 4.4 durchgeführt werden. RELENG_4_3 Der Zweig, auf dem sicherheitsrelevante oder kritische Fehlerbehebungen für &os; 4.3 durchgeführt werden. RELENG_3 Der &os;-3.X Entwicklungszweig, der auch 3.X-STABLE genannt wird. RELENG_2_2 Der &os;-2.2.X Entwicklungszweig, der auch 2.2-STABLE genannt wird. Release-Tags Diese Tags geben den Zeitpunkt an, an dem eine bestimme &os;-Version veröffentlicht wurde. Das Erstellen einer Release ist in den Dokumenten Release Engineering Information und Release Process beschrieben. Der src-Baum benutzt Tags, deren Namen mit RELENG_ anfangen. Die Bäume ports und doc benutzen Tags, deren Namen mit RELEASE anfangen. Im Baum www werden keine Release-Tags verwendet. RELENG_8_0_0_RELEASE &os; 8.0 - RELENG_7_3_0_RELEASE - - - &os; 7.3 - - - + RELENG_7_3_0_RELEASE + + + &os; 7.3 + + + RELENG_7_2_0_RELEASE &os; 7.2 RELENG_7_1_0_RELEASE &os; 7.1 RELENG_7_0_0_RELEASE &os; 7.0 RELENG_6_4_0_RELEASE &os; 6.4 RELENG_6_3_0_RELEASE &os; 6.3 RELENG_6_2_0_RELEASE &os; 6.2 RELENG_6_1_0_RELEASE &os; 6.1 RELENG_6_0_0_RELEASE &os; 6.0 RELENG_5_5_0_RELEASE &os; 5.5 RELENG_5_4_0_RELEASE &os; 5.4 RELENG_4_11_0_RELEASE &os; 4.11 RELENG_5_3_0_RELEASE &os; 5.3 RELENG_4_10_0_RELEASE &os; 4.10 RELENG_5_2_1_RELEASE &os; 5.2.1 RELENG_5_2_0_RELEASE &os; 5.2 RELENG_4_9_0_RELEASE &os; 4.9 RELENG_5_1_0_RELEASE &os; 5.1 RELENG_4_8_0_RELEASE &os; 4.8 RELENG_5_0_0_RELEASE &os; 5.0 RELENG_4_7_0_RELEASE &os; 4.7 RELENG_4_6_2_RELEASE &os; 4.6.2 RELENG_4_6_1_RELEASE &os; 4.6.1 RELENG_4_6_0_RELEASE &os; 4.6 RELENG_4_5_0_RELEASE &os; 4.5 RELENG_4_4_0_RELEASE &os; 4.4 RELENG_4_3_0_RELEASE &os; 4.3 RELENG_4_2_0_RELEASE &os; 4.2 RELENG_4_1_1_RELEASE &os; 4.1.1 RELENG_4_1_0_RELEASE &os; 4.1 RELENG_4_0_0_RELEASE &os; 4.0 RELENG_3_5_0_RELEASE &os;-3.5 RELENG_3_4_0_RELEASE &os;-3.4 RELENG_3_3_0_RELEASE &os;-3.3 RELENG_3_2_0_RELEASE &os;-3.2 RELENG_3_1_0_RELEASE &os;-3.1 RELENG_3_0_0_RELEASE &os;-3.0 RELENG_2_2_8_RELEASE &os;-2.2.8 RELENG_2_2_7_RELEASE &os;-2.2.7 RELENG_2_2_6_RELEASE &os;-2.2.6 RELENG_2_2_5_RELEASE &os;-2.2.5 RELENG_2_2_2_RELEASE &os;-2.2.2 RELENG_2_2_1_RELEASE &os;-2.2.1 RELENG_2_2_0_RELEASE &os;-2.2.0 AFS-Server Die folgende Aufzählung enthält AFS Server für &os;: Schweden Die Dateien sind unter dem Pfad /afs/stacken.kth.se/ftp/pub/FreeBSD/ erreichbar. stacken.kth.se # Stacken Computer Club, KTH, Sweden 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Betreuer ftp@stacken.kth.se rsync-Server rsync wird ähnlich wie &man.rcp.1; verwendet, besitzt aber mehr Optionen und verwendet das rsync remote-update Protokoll, das nur geänderte Dateien überträgt und damit viel schneller als ein normaler Kopiervorgang ist. rsync ist sehr nützlich, wenn Sie einen &os;-FTP-Spiegel oder einen CVS-Spiegel betreiben. Das Programm ist für viele Betriebssysteme erhältlich, mit &os; können Sie den Port net/rsync oder das fertige Paket benutzen. Die folgenden Server stellen &os; über das rsync Protokoll zur Verfügung: Großbritannien rsync://rsync.mirrorservice.org/ Verfügbare Sammlungen: sites/ftp.freebsd.org: Kompletter Spiegel des &os;-FTP-Servers. Niederlande rsync://ftp.nl.FreeBSD.org/ Verfügbare Sammlungen: &os;: Kompletter Spiegel des &os;-FTP-Servers. Russland rsync://ftp.mtu.ru/ Verfügbare Sammlungen: &os;: Kompletter Spiegel des &os;-FTP-Servers. &os;-gnats: Die GNATS-Datenbank zur Verwaltung von Problemberichten. &os;-Archive: Ein Spiegel des &os;-Archive-FTP-Servers. Taiwan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Verfügbare Sammlungen: &os;: Kompletter Spiegel des &os;-FTP-Servers. Tschechische Republik rsync://ftp.cz.FreeBSD.org/ Verfügbare Sammlungen: ftp: Unvollständiger Spiegel des &os;-FTP-Servers. &os;: Vollständiger Spiegel des &os;-FTP-Servers. USA rsync://ftp-master.FreeBSD.org/ Dieser Server darf nur von primären Spiegeln benutzt werden. Verfügbare Sammlungen: &os;: Das Hauptarchiv des &os; FTP Servers. acl: Die primäre ACL-Liste. rsync://ftp13.FreeBSD.org/ Verfügbare Sammlungen: &os;: Kompletter Spiegel des &os;-FTP-Servers.
diff --git a/de_DE.ISO8859-1/books/porters-handbook/book.sgml b/de_DE.ISO8859-1/books/porters-handbook/book.sgml index d0ae8a4cb0..43480cf5b9 100644 --- a/de_DE.ISO8859-1/books/porters-handbook/book.sgml +++ b/de_DE.ISO8859-1/books/porters-handbook/book.sgml @@ -1,15509 +1,15936 @@ %books.ent; ]> Das FreeBSD Porter-Handbuch The FreeBSD German Documentation Project April 2000 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 + 2010 The FreeBSD German Documentation Project &bookinfo.trademarks; &bookinfo.legalnotice; Einführung Die Ports-Sammlung von FreeBSD ist der gebräuchlichste Weg, um Anwendungen ("Ports") unter FreeBSD zu installieren. Wie alles andere in FreeBSD auch, ist sie hauptsächlich das Ergebnis der Arbeit von Freiwilligen. Es ist wichtig, diesen Aspekt beim Lesen im Hinterkopf zu behalten. In FreeBSD kann jeder einen neuen Port einsenden oder sich dazu bereit erklären, einen bereits vorhandenen Port zu pflegen, sofern der Port derzeit keinen Maintainer hat – dazu sind keine besonderen Rechte nötig. Einen neuen Port erstellen Sie sind also daran interessiert, einen neuen Port zu erstellen oder einen vorhandenen zu aktualisieren? Großartig! Die folgenden Kapitel beinhalten einige Richtlinien, um einen neuen Port für FreeBSD zu erstellen. Wenn Sie einen vorhandenen Port auf den neuesten Stand bringen wollen, sollten Sie mit fortfahren. Wenn Ihnen dieses Dokument nicht detailliert genug ist, sollten Sie einen Blick in /usr/ports/Mk/bsd.port.mk werfen. Das Makefile jedes Ports bindet diese Datei ein. Auch wenn Sie nicht täglich mit Makefiles arbeiten, sollten Sie gut damit zurecht kommen, da die Datei gut dokumentiert ist und Sie eine Menge Wissen daraus erlangen können. Zusätzlich können Sie speziellere Fragen an die &a.ports;-Mailingliste stellen. Nur ein Bruchteil der Variablen (VAR), die von Ihnen gesetzt werden können, finden hier Erwähnung. Die meisten von ihnen (wenn nicht sogar alle) sind am Anfang von /usr/ports/Mk/bsd.port.mk erläutert. Beachten Sie bitte, dass diese Datei eine nicht standardkonforme Tabulator-Einstellung verwendet. Emacs und Vim sollten diese Einstellung jedoch automatisch beim Öffnen der Datei setzen. Sowohl &man.vi.1; als auch &man.ex.1; können mit dem Befehl :set tabstop=4 dazu gebracht werden, die Datei richtig anzuzeigen, wenn sie geöffnet wird. Port erstellen auf die Schnelle Dieser Abschnitt beschreibt, wie Sie schnell einen Port erstellen können. In vielen Fällen ist dies allerdings nicht ausreichend, dann werden Sie in diesem Buch weiterlesen müssen. Als Erstes besorgen Sie sich das Original-Tarball (komprimiertes Archiv) und legen es im DISTDIR ab, welches standardmäßig /usr/ports/distfiles ist. Im Folgenden wird angenommen, dass die Software unverändert kompiliert werden konnte, dass also keinerlei Änderungen nötig waren, um den Port auf Ihrem FreeBSD-Rechner zum Laufen zu bringen. Falls Sie Änderungen vornehmen mussten, werden Sie auch den nächsten Abschnitt beachten müssen. Das <filename>Makefile</filename> schreiben Ein minimales Makefile sieht in etwa so aus: # New ports collection makefile for: oneko # Date created: 5 December 1994 # Whom: asami # # $FreeBSD$ # PORTNAME= oneko PORTVERSION= 1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.org COMMENT= A cat chasing a mouse all over the screen MAN1= oneko.1 MANCOMPRESSED= yes USE_IMAKE= yes .include <bsd.port.mk> Versuchen Sie es zu verstehen. Machen Sie sich keine Gedanken um die $FreeBSD$-Zeile, diese wird automatisch vom CVS eingefügt, wenn der Port in den Haupt-Ports-Tree importiert wird. Ein detailliertes Beispiel finden Sie im Abschnitt sample Makefile. Die Beschreibungsdateien erstellen Es gibt zwei Beschreibungsdateien, die für jeden Port benötigt werden, ob sie tatsächlich im Paket enthalten sind oder nicht. Dies sind pkg-descr und pkg-plist. Der pkg- Präfix unterscheidet sie von anderen Dateien. <filename>pkg-descr</filename> Diese enthält eine längere Beschreibung des Ports. Einer oder mehrere Absätze, die kurz und prägnant erklären, was der Port macht, sind ausreichend. pkg-descr enthält keine Anleitung oder detaillierte Beschreibung wie der Port benutzt oder kompiliert wird! Bitte seien Sie vorsichtig, wenn Sie aus dem README oder der Manualpage kopieren ; Diese sind oft keine prägnanten Beschreibungen des Ports oder sie sind in einem ungünstigen Format (Manualpages haben z.B. bündige Zwischenräume). Wenn es für die portierte Software eine offizielle Webseite gibt, sollten Sie diese hier angeben. Fügen Sie hierzu eine der Webseiten mit dem Präfix WWW: ein, damit automatische Werkzeuge korrekt arbeiten. Das folgende Beispiel zeigt wie Ihre pkg-descr aussehen sollte: This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (etc.) WWW: http://www.oneko.org/ <filename>pkg-plist</filename> Diese Datei enthält eine Liste aller Dateien, die von diesem Port installiert werden. Sie wird auch die Packliste genannt, da das Paket durch die hier aufgeführten Dateien erstellt wird. Die Pfadangaben sind relativ zum Installationspräfix (für gewöhnlich /usr/local oder /usr/X11R6). Wenn Sie die MANn-Variablen verwenden (was Sie auch machen sollten), führen Sie hier keine Manualpages auf. Wenn der Port während der Installation Verzeichnisse erstellt, stellen Sie sicher entsprechende @dirrm-Zeilen einzufügen, um die Verzeichnisse zu entfernen, wenn das Paket gelöscht wird. Hier ist ein kleines Beispiel: bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko Für weitere Details zur Packliste lesen Sie in der &man.pkg.create.1; Manualpage nach. Es wird empfohlen alle Dateinamen in dieser Datei alphabetisch sortiert zu halten. Das erlaubt Ihnen die Änderungen bei einem Upgrade Ihres Ports deutlich einfacher zu Überprüfen. Eine Packlist von Hand zu erzeugen kann eine sehr mühsame Aufgabe sein. Wenn der Port eine große Anzahl Dateien installiert, kann es Zeit sparen, eine Packliste automatisch zu erstellen. Es gibt nur einen Fall, in dem pkg-plist weggelassen werden kann. Wenn der Port nur eine handvoll Dateien und Verzeichnisse installiert, können diese in den Variablen PLIST_FILES und PLIST_DIRS im Makefile aufgelistet werden. Zum Beispiel könnten wir im obigen Beispiel ohne pkg-plist für den oneko-Port auskommen, indem wir die folgenden Zeilen ins Makefile einfügen: PLIST_FILES= bin/oneko \ lib/X11/app-defaults/Oneko \ lib/X11/oneko/cat1.xpm \ lib/X11/oneko/cat2.xpm \ lib/X11/oneko/mouse.xpm PLIST_DIRS= lib/X11/oneko Natürlich sollte PLIST_DIRS ungesetzt bleiben, wenn der Port keine eigenen Verzeichnisse installiert. Der Preis für diese Art die Dateien eines Ports anzugeben ist, dass man keine Befehlsfolgen wie in &man.pkg.create.1; nutzen kann. Deshalb ist es nur für einfache Ports geeignet und macht diese noch einfacher. Gleichzeitig bringt es den Vorteil die Anzahl der Dateien in der Ports-Sammlung zu reduzieren. Deshalb ziehen Sie bitte diese Vorgehensweise in Erwägung, bevor Sie pkg-plist benutzen. Später werden wir uns ansehen, wie pkg-plist und PLIST_FILES benutzt werden können, um anspruchsvollere Aufgaben zu erfüllen. Die Checksummendatei erzeugen Geben Sie einfach make makesum ein. Die Regeln von Make sorgen dafür, dass die Datei distinfo automatisch erstellt wird. Wenn sich die Checksumme einer heruntergeladenen Datei regelmäßig ändert und Sie sicher sind, dass Sie der Quelle trauen können (weil sie z.B. von einer Hersteller-CD oder täglich erstellter Dokumentation stammt), sollten Sie diese Dateien in der Variable IGNOREFILES angeben. Dann wird die Checksumme für diese Datei bei make makesum nicht berechnet, sondern auf IGNORE gesetzt. Den Port testen Sie sollten sicherstellen, dass die Port-Regeln genau das einhalten, was Sie von ihnen erwarten, auch beim Erzeugen eines Pakets aus dem Port. Dies sind die wichtigen Punkte, die Sie überprüfen sollten. pkg-plist enthält nichts, das nicht von Ihrem Port installiert wurde. pkg-plist enthält alles, was von Ihrem Port installiert wurde. Ihr Port kann mit Hilfe von make reinstall mehrmals installiert werden. Ihr Port räumt bei der Deinstallation hinter sich auf. Empfohlene Testreihenfolge make install make package make deinstall pkg_add Paket-Name make deinstall make reinstall make package Stellen Sie bitte sicher, dass während make package und make deinstall keine Warnungen ausgegeben werden. Nach Schritt 3 überprüfen Sie bitte, ob alle neuen Verzeichnisse korrekt entfernt wurden. Und versuchen Sie die Software nach Schritt 4 zu benutzen, um sicherzustellen, dass sie korrekt funktioniert, wenn diese aus einem Paket installiert wird. Der gründlichste Weg diese Schritte zu automatisieren ist eine Tinderbox zu installieren. Diese verwaltet Jails, in denen Sie alle oben genannten Schritte durchführen können, ohne den Zustand Ihres laufenden Systems zu verändern. Mehr Informationen hierzu entält ports/ports-mgmt/tinderbox Ihren Port mit <command>portlint</command> überprüfen Bitte verwenden Sie portlint, um festzustellen, ob Ihr Port unseren Richtlinien entspricht. Das Programm ports-mgmt/portlint ist Teil der Ports-Sammlung. Stellen Sie vor allem sicher, dass das Makefile in der richtigen Form und das Paket passend benannt ist. Den Port einreichen Als Erstes sorgen Sie bitte dafür, dass Sie den Abschnitt DOs and DON'Ts gelesen haben. Nun, da Sie mit Ihrem Port zufrieden sind, müssen Sie ihn nur noch in den Haupt-Ports-Tree von FreeBSD einbringen, damit alle daran teilhaben können. Wir benötigen nicht Ihr work-Verzeichnis oder Ihr pkgname.tgz-Paket – diese können Sie nun löschen. Als Nächstes fügen Sie bitte einfach die Ausgabe von shar `find port_dir` in einen Fehlerbericht (PR - Problem Report) und senden diesen mittels &man.send-pr.1; (unter Bug Reports and General Commentary finden Sie weitere Informationen über &man.send-pr.1;). Ordnen Sie den Fehlerbericht bitte in die Kategorie Ports mit der Klasse Change-Request ein (Markieren Sie den Bericht nicht als vertraulich (confidential)!). Fügen Sie bitte eine kurze Beschreibung des Programms, das Sie portiert haben, in das Beschreibungs-Feld des Problemberichts und das Shar (Shell-Archiv) in das Fix-Feld ein. Sie können uns die Arbeit um einiges vereinfachen, wenn Sie eine gute Beschreibung in der Zusammenfassung des Problemberichtes verwenden. Wir bevorzugen etwas wie Neuer Port: <Kategorie>/<Portname><Kurzbeschreibung des Ports> für neue Ports und Update Port: <Kategorie>/<Portname> <Kurzbeschreibung des Updates> für Portupdates. Wenn Sie sich an dieses Schema halten, ist die Chance, dass sich jemand bald Ihren Bericht ansieht, deutlich besser. Noch einmal: Bitte fügen Sie nicht das distfile der Originalquelle, das work-Verzeichnis oder das Paket, das Sie mit make package erstellt haben, ein. Haben Sie bitte etwas Geduld, nachdem Sie den Port eingereicht haben. Manchmal kann es einige Monate dauern, bevor ein Port in FreeBSD eingefügt wird, obwohl es wahrscheinlich nur ein paar Tage dauert. Sie können sich die Liste der Ports, die darauf warten in FreeBSD committet zu werden, ansehen. Nachdem wir einen Blick auf Ihren Port geworfen haben, werden wir, wenn nötig, bei Ihnen nachfragen und ihn in die Ports-Sammlung übernehmen. Ihr Name taucht dann auch in der Liste der Additional FreeBSD Contributors und in anderen Dateien auf. Ist das nicht toll?! :-) Einen Port in aller Ruhe erstellen Ok, das war nicht ganz einfach und der Port hat einige Veränderungen erfordert, um funktionieren zu können. In diesem Abschnitt werden wir Schritt für Schritt erklären, wie man den funktionierenden Port den Vorgaben der Ports entsprechend anpasst. Die Funktionsweise Beginnen wir mit der Abfolge der Ereignisse, die eintreten, wenn der Nutzer das erste make in Ihrem Portsverzeichnis ausführt. Sie empfinden es für das Verständnis vielleicht hilfreich bsd.port.mk in einem anderen Fenster offen zu haben, während Sie diesen Abschnitt lesen. Aber machen Sie sich keine Sorgen, falls Sie nicht wirklich verstehen, was bsd.port.mk macht, die Wenigsten begreifen dies... :> Das Target fetch wird aufgerufen. Es ist dafür verantwortlich sicherzustellen, dass der Tarball lokal im DISTDIR verfügbar ist. Falls fetch die benötigten Dateien in DISTDIR nicht finden kann, durchsucht es die URL MASTER_SITES, welche im Makefile gesetzt ist, ebenso wie unsere Haupt-FTP-Seite unter ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/ , wo wir genehmigte Distfiles als Backup aufbewahren. Danach wird versucht, so eine direkte Internetverbindung besteht, dass genannte Distfile mit FETCH herunterzuladen. Falls dies gelingt, wird die Datei in DISTDIR für weitere Nutzung abgelegt und fährt fort. Das Target extract wird aufgerufen. Es sucht nach den Distfiles Ihres Ports (normalerweise ein gzip-komprimierter Tarball) in DISTDIR und entpackt diese in ein temporäres Unterverzeichnis, welches von WRKDIR festgelegt wird (standardmäßig work). Das Target patch wird aufgerufen. Zuerst werden alle in PATCHFILES festgelegten Patches eingespielt. Anschließend werden, falls Patches der Form patch-* in PATCHDIR (standardmäßig das files-Unterverzeichnis) gefunden werden, diese in alphabetischer Reihenfolge eingespielt. Das Target configure wird aufgerufen. Dieses kann viele verschiedene Dinge machen. Existiert scripts/configure, so wird es aufgerufen. Falls HAS_CONFIGURE oder GNU_CONFIGURE gesetzt sind, wird WRKSRC/configure ausgeführt. Falls USE_IMAKE gesetzt ist, wird XMKMF (standardmäßig xmkmf -a) ausgeführt. Das Target build wird aufgerufen. Es ist für das Wechseln in das private Arbeitsverzeichnis (WRKSRC) und das Bauen des Ports zuständig. Ist USE_GMAKE gesetzt, so wird GNU make verwendet, sonst das System-make. Die oben genannten Schritte sind die Standardaktionen. Zusätzlich können Sie pre- irgendwas oder post-irgendwas als Targets definieren oder Skripten mit diesen Namen in das scripts-Unterverzeichnis legen. Sie werden dann vor bzw. nach den Standardaktionen aufgerufen. Angenommen Sie haben das Target post-extract in Ihrem Makefile definiert und eine Datei pre-build im scripts Unterverzeichnis, so wird das Target post-extract nach dem normalen Entpacken aufgerufen und das Skript pre-build ausgeführt, bevor die vordefinierten Bau-Regeln abgearbeitet sind. Es wird empfohlen, dass Sie Makefile-Targets verwenden, falls die Aktionen es erlauben, da es so für jemanden einfacher sein wird herauszufinden, was für eine nicht-standardmäßige Aktion der Port benötigt. Die Standardaktionen werden aus den Targets bsd.port.mk do-irgendwas übernommen. Zum Beispiel sind die Befehle zum Entpacken eines Ports im Target do-extract zu finden. Falls Sie mit einem vorgegebenen Target nicht zufrieden sind, können Sie es verändern, indem Sie das Target do-irgendwas in Ihrem Makefile neu definieren. Die Haupt-Targets (z.B. extract, configure usw.) machen nicht mehr als sicherzustellen, dass bis hierhin alle Abschnitte abgeschlossen sind, um danach die eigentlichen Targets oder Skripte aufzurufen. Und es ist nicht beabsichtigt, dass diese geändert werden. Falls Sie das Entpacken verändern wollen, verändern Sie do-extract, aber niemals die Art, wie extract arbeitet! Jetzt, da Sie verstehen, was geschieht, wenn der Benutzer make eingibt, lassen Sie uns durch die empfohlenen Schritte gehen, um den perfekten Port zu erstellen. Den originalen Quelltext besorgen Normalerweise liegt der original Quelltext als gepackte Datei (foo.tar.gz oder foo.tar.Z) vor. Kopieren Sie diese nach DISTDIR. Nutzen Sie, soweit möglich, immer die Quellen aus dem Hauptzweig. Es ist notwendig die Variable MASTER_SITES anzupassen, um anzugeben, wo sich der originale Quelltext befindet. In bsd.sites.mk finden sich hilfreiche Definitionen für die gebräuchlichsten Seiten. Bitte nutzen Sie diese Seiten und die zugehörigen Definitionen, soweit dies möglich ist. Damit wird vermieden, immer und immer wieder dieselben Informationen zu wiederholen. Da die Hauptseiten regelmäßig angepasst werden müssen, vereinfacht dieses Vorgehen die Pflege der Dateien für jeden Beteiligten. Falls keine zuverlässige und gut erreichbare FTP/HTTP-Seite zu finden ist, oder nur Seiten auffindbar sind, die keinen Standards entsprechen, sollte eine Kopie des Quelltextes auf einer zuverlässigen Seite abgelegt werden. Dies könnte z.B. die eigene Internetseite sein. Ist kein geeigneter Ort zum Ablegen des Quelltextes auffindbar, ist es möglich diesen intern auf ftp.FreeBSD.org abzulegen; dies sollte jedoch als letzte Möglichkeit angesehen werden. Das Distfile muss in diesem Fall in ~/public_distfiles/ eines freefall-Accounts abgelegt werden. Bitten Sie den Committer Ihres Ports dies zu erledigen. Er wird außerdem MASTER_SITES nach MASTER_SITE_LOCAL und MASTER_SITE_SUBDIR auf den freefall-Benutzernamen angepasst. Sollte sich das Distfile des Ports regelmäßig ohne Versionsanpassungen des Autors ändern, sollte überlegt werden, das Disfile auf der eigenen Internetseite abzulegen und diese in der Liste der MASTER_SITES an die erste Stelle zu setzen. Falls möglich, sollte der Autor des Ports gebeten werden, dies zu erledigen; hierüber wird die Kontrolle des Quelltextes verbessert. Wird eine eigene Version des Quelltextes auf eigenen Internetseiten verfügbar gemacht, verhindert dies Warnungen von checksum mismatch und reduziert den Arbeitsaufwand der Maintainer der FTP-Seiten. Auch wenn nur eine Quelle für den Quelltext des Ports zur Verfügung steht, ist es empfohlen, ein Backup auf einer weiteren Seite abzulegen und diese als zweiten Eintrag in MASTER_SITES aufzunehmen. Sind für den Port zusätzlich aus dem Internet verfügbare Patches erforderlich, sollten diese ebenfalls in DISTDIR abgelegt werden. Sollten diese Patches von anderer Quelle als der Hauptseite des Ports stammen, ist das kein Grund zur Sorge. Es gibt Wege diesem Umstand gerecht zu werden (beachten Sie die unten stehende Beschreibung zu PATCHFILES ). Den Port bearbeiten Entpacken Sie eine Kopie des Tarballs in ein privates Verzeichnis und nehmen Sie alle Änderungen vor, die nötig sind, um den Port unter einer aktuellen FreeBSD-Version kompilieren zu können. Protokollieren Sie sorgfältig alle Schritte, die Sie vornehmen, da Sie den Prozess in Kürze automatisieren werden. Alles, auch das Entfernen, Hinzufügen oder Bearbeiten von Dateien, sollte von einem automatisierten Skript oder einer Patch-Datei machbar sein, wenn Ihr Port fertig ist. Falls Ihr Port bedeutende Interaktionen/Veränderungen durch den Benutzer benötigt, um ihn zu Kompilieren oder zu Installieren, sollten Sie einen Blick auf Larry Walls klassische Configure-Skripte werfen oder vielleicht etwas Ähnliches selbst erstellen. Das Ziel der Ports-Sammlung ist es, jeden Port so plug-and-play-fähig wie möglich für den Endbenutzer zu machen, während ein Minimum an Speicherplatz gebraucht wird. Solange nicht anders angegeben wird von Patch-Dateien, Skripten und anderen Dateien, die Sie erstellt und der FreeBSD Ports-Sammlung hinzugefügt haben, angenommen, dass Sie unter den standardmäßigen BSD-Copyright-Bedingungen stehen. Fehlerbehebung (Patches) Bei der Vorbereitung eines Ports können die Dateien, die hinzugefügt oder verändert wurden, mittels &man.diff.1; abgefangen werden, um Sie später an &man.patch.1; zu übergeben. Jeder Patch, der dem Quelltext übergeben werden soll, sollte in einer Datei patch-* abgelegt werden, wobei * dem Pfadnamen der zu korrigierenden Datei entspricht, wie er auch in patch-Imakefile oder im patch-src-config.h erscheint. Diese Dateien sollten in PATCHDIR (normalerweise files) abgelegt sein, von wo sie automatisch übernommen werden. Alle Patches müssen sich relativ zur WRKSRC-Variable (normalerweise dem Verzeichnis, in dem sich der Quelltext des Ports entpackt und wo auch der Bau stattfindet) befinden. Um Korrekturen und Updates zu vereinfachen, sollte es vermieden werden, mehr als einen Patch für eine Datei zu nutzen (z.B. patch-file und patch-file2, welche beide WRKSRC/foobar.c verändern). Für die Benennung der Patches sollten nur die Zeichen [-+._a-zA-Z0-9] genutzt werden. Bitte verwenden Sie keine weiteren Zeichen als die angegebenen. Die Namensvergabe sollte nicht patch-aa oder patch-ab etc. entsprechen, erwähnen Sie immer den Pfad und Dateinamen. RCS-Zeichenketten sollten vermieden werden, da CVS diese verstümmeln würde, sobald wir diese Dateien in die Ports-Sammlung einpflegen. Wenn wir die Dateien wieder abrufen wären diese verändert und der Patch würde fehlschlagen. RCS-Zeichenketten sind in Dollar-Zeichen ($) eingefügte Zeichen und beginnen üblicherweise mit $Id oder $RCS. Die Option rekursiv () zu nutzen &man.diff.1;, um Patches zu erstellen, ist zulässig, jedoch sollte der Patch anschließend geprüft werden, um Unnötiges aus dem Patch zu entfernen. Im Einzelnen bedeutet dies, dass Diffs zwischen zwei Backup-Dateien, Makefiles oder wenn der Port Imake oder GNU configure usw. nutzt, überflüssig sind und entfernt werden sollten. Falls es es notwendig war, configure.in zu bearbeiten und es soll autoconf zum Neuerstellen von configure genutzt werden, sollten die Diffs aus configure nicht genutzt werden (diese werden oft einige tausend Zeilen groß!); – hier sollte USE_AUTOTOOLS=autoconf:261 definiert und das Diff aus configure.in genutzt werden. Zusätzlich sollte man unnötige Markup-Änderungen in Patches/Änderungen möglichst vermeiden. In der Open Source-Welt teilen sich Projekte häufig große Teile des Quellcodes. Allerdings verwenden die einzelnen Projekte oft unterschiedliche Programmierstile und Vorgaben für Einrückungen. Wenn man also einen funktionierenden Teil einer Funktion aus einem Projekt verwendet, um ein ähnliches Problem in einem anderen Projekt zu lösen, sollte man besonders vorsichtig sein, weil sich ansonsten die CVS-Änderungseinträge mit überflüssigen Einträgen füllen, die nur das Markup des Quellcodes betreffen, ohne dass sich an der Funktion des eigentlichen Quellcode etwas ändert (withspace-only changes). Solche Änderungen vergrößern nicht nur das CVS-Repository, sondern erschweren es auch die Ursache für eventuell auftretende Probleme zu finden. War es notwendig eine Datei zu entfernen, wird dies besser mittels des post-extract-Targets als über den Patch selbst realisiert. Ein einfacher Austausch kann direkt über das Makefile des Ports umgesetzt werden, indem der in-place-Modus von &man.sed.1; genutzt wird. Dies ist sehr hilfreich, wenn variable Werte korrigiert werden sollen. Beispiel: post-patch: @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README @${REINPLACE_CMD} -e 's|-pthread|${PTHREAD_LIBS}|' ${WRKSRC}/configure Relativ häufig ergibt sich die Situation, in der die portierte Software die CR/LF-Konventionen für Zeilenenden nutzt (dies ist bei unter &windows; entwickelter Software häufig der Fall). Dies kann bei weiteren Patches Probleme (Compiler-Warnungen, Fehlermeldungen bei der Ausführung von Skripten wie z.B. /bin/sh^M not found) und anderes ergeben. Um schnell alle Dateien von CR/LF nach LF zu konvertieren, kann USE_DOS2UNIX=yes in das Makefile des Ports geschrieben werden. Hierzu kann eine Liste der zu konvertierenden Dateien erstellt werden: USE_DOS2UNIX= util.c util.h Sollen Gruppen von Dateien über verschiedene Unterverzeichnisse konvertiert werden, kann DOS2UNIX_REGEX genutzt werden, dessen Argumente find-kompatible, reguläre Ausdrücke sind. Mehr zur Formatierung findet sich in &man.re.format.7;. Diese Option ist beim Konvertieren aller Dateien mit definierter Endung, z.B. aller Dateien im Quellcode, wobei binäre Dateien unberührt bleiben, sinnvoll: USE_DOS2UNIX= yes DOS2UNIX_REGEX= .*\.(c|cpp|h) Konfigurieren Fügen Sie alle zusätzlichen Veränderungsbefehle Ihrem Skript configure hinzu und speichern Sie es im scripts-Unterverzeichnis. Wie vorstehend schon erwähnt, können Sie dies auch mit den Targets Makefile und/oder Skripte mit dem Namen pre-configure oder post-configure erledigen. Handhabung von Benutzereingaben Sollte der Port Eingaben vom Benutzer benötigen, muss IS_INTERACTIVE im Makefile des Ports gesetzt werden. Dies erlaubt overnight builds Ihren Port zu überspringen, falls der Nutzer die Variable BATCH setzt (setzt der Nutzer hingegen die Variable INTERACTIVE, werden nur Ports gebaut, die Interaktion vom Nutzer erwarten). Dies erspart den Rechnern, welche kontinuierlich Ports bauen, eine Menge Zeit (siehe unten). Zudem ist es empfohlen, falls sinnvolle Vorgaben für interaktive Optionen gesetzt sind, die PACKAGE_BUILDING-Variable zu prüfen und das interaktive Skript abzuschalten. Dies macht es uns möglich, Pakete für CDROMs und FTP-Server zu bauen. Die Konfiguration des Makefile Das Konfigurieren des Makefile ist sehr einfach und wir schlagen vor, dass Sie zunächst einen Blick auf vorhandene Beispiele werfen. Zusätzlich gibt es ein Beispiel eines Makefile in diesem Handbuch. Schauen Sie es sich an und verfolgen Sie bitte die Abfolge der Variablen und Abschnitte in dieser Vorlage. Damit erleichtern Sie es anderen, Ihren Port zu lesen. Bedenken Sie bitte die folgenden Probleme in der hier vorgegebenen Abfolge der Unterabschnitte dieses Kapitels, wenn Sie Ihr neues Makefile erstellen: Der originale Quelltext Liegt der Quelltext in DISTDIR als eine standardisierte und mit gzip gepackte Datei in der Art foozolix-1.2.tar.gz? Falls ja, können Sie zum nächsten Schritt übergehen. Falls nicht, sollten Sie versuchen, die Variablen DISTVERSION, DISTNAME, EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, oder DISTFILES zu ändern. Das hängt davon ab, wie fremdartig das Distributionsfile Ihres Ports ist (der häufigste Fall ist EXTRACT_SUFX=.tar.Z, wenn der Tarball durch ein normales compress und nicht durch gzip gepackt wurde). Im schlimmsten Fall können Sie einfach Ihre eigene Vorgabe mittels do-extract erzeugen und die Standardvorgabe überschreiben; aber dies sollte in den wenigsten Fällen, wenn überhaupt, notwendig sein. Bezeichnungen Der erste Teil des Makefile beschreibt die Versionsnummer des Ports und führt ihn in der richtigen Kategorie auf. <makevar>PORTNAME</makevar> und <makevar>PORTVERSION</makevar> Setzen Sie bitte die Variable PORTNAME auf den Basisnamen Ihres Ports und die Variable PORTVERSION auf dessen Versionsnummer. <makevar>PORTREVISION</makevar> und <makevar>PORTEPOCH</makevar> <makevar>PORTREVISION</makevar> Die PORTREVISION-Variable ist ein streng monoton wachsender Wert, welcher auf 0 zurückgesetzt wird, nachdem PORTVERSION erhöht wurde (d.h. jedes Mal, wenn ein offizielles Release erfolgt). Sie wird an den Namen des Pakets angehängt, wenn sie ungleich 0 ist. Änderungen an PORTREVISION werden von automatisierten Werkzeugen (z.B. &man.pkg.version.1;) genutzt, um anzuzeigen, dass ein neues Paket verfügbar ist. PORTREVISION sollte jedes Mal erhöht werden, wenn eine Änderung am Port erfolgt, die beträchtliche Auswirkungen auf den Inhalt oder Struktur des aus dem Port erzeugten Pakets zur Folge hat. Beispiele dafür, wann PORTREVISION erhöht werden sollte: Hinzufügen von Patches, welche Sicherheitslücken schließen, Fehler beseitigen oder neue Funktionalität zum Port hinzufügen. Änderungen am Makefile des Ports, welche compile-time-Optionen hinzufügen oder entfernen. Änderungen bezüglich Packliste oder am Verhalten während der Installation des Pakets (d.h. Änderungen an einem Skript, welches Ausgangsdaten für das Paket erzeugt, wie z.B. SSH-Hostschlüssel). Versionssprung einer Shared-Library, welche eine Abhängigkeit dieses Ports ist (In diesem Fall würde ein Anwender bei der Installation des alten Pakets scheitern, falls er eine neue Version der Abhängigkeit bereits installiert hat, weil nach der alten Bibliothek libfoo.x anstatt nach libfoo.(x+1)) gesucht wird). Schleichende Änderungen am Distfile, welche bedeutende funktionale Änderungen verursachen, d.h. Änderungen des Distfile erfordern eine Korrektur an distinfo, ohne dass damit zusammenhängend die PORTVERSION verändert wird, obwohl ein diff -ru zwischen der alten und der neuen Version bedeutende Veränderungen am Code nachweist. Beispiele für Änderungen, welche keine Erhöhung von PORTREVISION erfordern: Stilistische Änderungen am Grundgerüst des Ports ohne funktionale Änderungen am daraus resultierenden Paket. Änderungen an der Variable MASTER_SITES oder andere funktionale Änderungen, welche das resultierende Paket nicht verändern. Marginale Patches am Distfile wie die Korrektur von Tippfehlern, welche nicht wichtig genug sind, um dem Benutzer die Bürde eines Upgrades aufzuerlegen. Build fixes, die ein Paket erst kompilierbar machen, welches ohne diese Änderungen vorher nicht erzeugt werden konnte (solange die Änderungen keine funktionale Differenz bringen auf Plattformen, auf denen dieses Paket schon vorher gebaut werden konnte). Da PORTREVISION den Inhalt des Pakets wiederspiegelt, ist es nicht notwendig PORTREVISION zu erhöhen, wenn das Paket vorher nicht erstellt werden konnte. Als Faustregel gilt: Stellen Sie sich die Frage, ob die durchgeführte Änderung am Port jedem hilft (entweder aufgrund einer Verbesserung, Beseitigung eines Fehlers, oder der Annahme, dass das neue Paket überhaupt erst funktioniert) und wägen Sie es gegen den Umstand ab, dass jedermann, der seine Ports-Sammlung regelmässig auf dem neuesten Stand hält, zu einer Aktualisierung gezwungen wird. Falls Sie die Frage positiv beantworten sollten, erhöhen Sie die Variable PORTREVISION. <makevar>PORTEPOCH</makevar> Von Zeit zu Zeit geschieht es, dass irgendjemand (Drittanbieter von Software oder FreeBSD Ports Committer) etwas Dummes tut und eine Version einer Software veröffentlicht, deren Versionsnummer niedriger ist als die der vorherigen. Ein Beispiel hierfür ist ein Port, der von foo-20000801 auf foo-1.0 geändert wird (der Erstere wird fälschlicherweise als neue Version behandelt, weil 2000801 ein numerisch größerer Wert ist als 1). In Situationen wie diesen sollte die Variable PORTEPOCH erhöht werden. Wenn PORTEPOCH größer als 0 ist, wird sie an den Namen des Pakets angehängt, wie in Abschnitt 0 oberhalb bereits beschrieben. PORTEPOCH darf niemals verringert oder auf 0 gesetzt werden, weil der Vergleich des Pakets mit einem früheren Zeitpunkt scheitern würde (d.h. das Paket würde niemals als veraltet erkannt werden): Die neue Versionsnummer (1.0,1 im obigen Beispiel) ist immer noch numerisch kleiner als die vorherige Version (2000801), aber das Suffix ,1 wird von automatisierten Werkzeugen gesondert behandelt und wird als größer erkannt, als das implizit angenommene Suffix ,0 im früheren Paket. Das Entfernen oder Zurücksetzen von PORTEPOCH führt zu unendlichem Ärger. Wenn Sie die obigen Ausführungen nicht vollständig verstanden haben, lesen Sie es bitte unbedingt nochmals bis Sie es vollständig verinnerlicht haben, oder fragen Sie vor jeder Änderung auf den Mailinglisten nach! Es wird erwartet, dass PORTEPOCH für die weitaus überwiegende Zahl der Ports nicht verwendet wird und der verantwortungsvolle und vorausschauende Umgang mit PORTVERSION macht es meist überflüssig, falls ein späteres Release die Versionsstruktur ändern sollte. Vorsicht ist geboten, wenn ein Release einer Drittanbieter-Software ohne eine offizielle Versionsnummer veröffentlicht wird, wie z.B. bei Snapshot-Versionen. Man ist versucht, das Release mit dem jeweiligen Datum zu bezeichnen, was unweigerlich zu den oben beschriebenen Problemen führt, wenn das nächste offizielle Release erscheint. Wenn z.B. ein Snapshot zum Datum 20000917 veröffentlicht wird und die vorherige Version der Software war 1.2, dann sollte der Snapshot die PORTVERSION 1.2.20000917 oder ähnlich erhalten und nicht 20000917, damit das nachfolgende Release, angenommen 1.3, immer noch einen größeren numerischen Wert aufweist. Beispiel für den Gebrauch von <makevar>PORTREVISION</makevar> und <makevar>PORTEPOCH</makevar> Der gtkmumble-Port, Version 0.10, befindet sich in der Ports-Sammlung: PORTNAME= gtkmumble PORTVERSION= 0.10 PKGNAME wird zu gtkmumble-0.10. Ein Sicherheitsloch wurde entdeckt, das einen lokalen Patch von FreeBSD erforderlich macht. PORTREVISION wird entsprechend erhöht. PORTNAME= gtkmumble PORTVERSION= 0.10 PORTREVISION= 1 PKGNAME wird zu gtkmumble-0.10_1 Eine neue Version wird vom Software-Drittanbieter veröffentlicht, bezeichnet mit der Version 0.2 (es stellt sich heraus, dass der Autor beabsichtigte, dass 0.10 eigentlich 0.1.0 bedeuten sollte, nicht was kommt nach 0.9  – Hoppla, aber nun ist es zu spät). Da die neue Unterversion 2 numerisch kleiner ist als die vorherige Version 10, muss PORTEPOCH erhöht werden, um sicherzustellen, dass das neue Paket auch als neuer erkannt wird. Da es ein neues Release des Drittanbieters ist, wird PORTREVISION auf 0 zurückgesetzt (oder aus dem Makefile entfernt). PORTNAME= gtkmumble PORTVERSION= 0.2 PORTEPOCH= 1 PKGNAME wird zu gtkmumble-0.2,1 Das nächste Release ist 0.3. Da PORTEPOCH niemals verringert wird, sind die Versionsvariablen nun wie folgt: PORTNAME= gtkmumble PORTVERSION= 0.3 PORTEPOCH= 1 PKGNAME wird zu gtkmumble-0.3,1 Falls PORTEPOCH mit diesem Upgrade auf 0 zurückgesetzt worden wäre, dann würde jemand, der das Paket gtkmumble-0.10_1 installiert hätte, das Paket gtkmumble-0.3 nicht als neuer erkennen, da 3 immer noch numerisch kleiner ist als 10. Bedenken Sie, dass genau dies der springende Punkt an PORTEPOCH ist. <makevar>PKGNAMEPREFIX</makevar> und <makevar>PKGNAMESUFFIX</makevar> Zwei optionale Variablen, PKGNAMEPREFIX und PKGNAMESUFFIX, werden verknüpft mit PORTNAME und PORTVERSION, um PKGNAME zu bilden als ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} . Stellen Sie bitte unbedingt sicher, dass diese Variablen den Richtlinien für einen guten Paketnamen entsprechen. Insbesondere dürfen Sie keinesfalls einen Bindestrich (-) in PORTVERSION verwenden. Falls das Paket den language- oder -compiled.specifics-Teil aufweist (siehe unten) benutzen Sie PKGNAMEPREFIX oder PKGNAMESUFFIX respektive. Machen Sie diese Variablen nicht zum Bestandteil von PORTNAME! <makevar>LATEST_LINK</makevar> In einigen Fällen können mehrere Versionen einer Applikation gleichzeitig in der Ports-Sammlung sein. Das index build- und das package build-System müssen nun in der Lage sein, diese als unterschiedliche Ports zu erkennen, obwohl diese Versionen alle die gleichen Variablen PORTNAME, PKGNAMEPREFIX und sogar PKGNAMESUFFIX aufweisen. In solchen Fällen sollte die optionale Variable LATEST_LINK auf einen unterschiedlichen Wert für alle Ports gesetzt werden mit Ausnahme des Haupt-Ports. Beispiele hierfür sind die editors/vim5 und editors/vim-Ports und die www/apache*-Familie. Beachten Sie bitte, dass die Frage der Auswahl der wichtigsten Version (am populärsten, am besten Unterstützt, zuletzt gepatcht usw.) ausserhalb der Möglichkeiten dieses Handbuches liegt. Wir sagen Ihnen nur, wie Sie die anderen Ports spezifizieren, nachdem Sie den Haupt-Port erkoren haben. Namensregeln für Pakete Im Folgenden finden Sie die Regeln für die Benennung Ihrer Pakete. Diese sollen gewährleisten, dass das Paketverzeichnis leicht zu durchsuchen ist, da es bereits abertausende Pakete gibt und die Nutzer sich mit Schauder abwenden, wenn Ihre Augen überstrapaziert werden! Der Paketname soll aussehen wie language_region-name-compiled.specifics-version.numbers. Der Paketname ist definiert als ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} . Stellen Sie bitte sicher, dass die Variablen Ihres Ports diesem Format entsprechen. FreeBSD bemüht sich ausserordentlich, die Landessprachen seiner Nutzer zu unterstützen. Die language-Variable soll eine Abkürzung mit 2 Buchstaben sein der Sprachen gemäß ISO-639, falls der Port für eine bestimmte Sprache spezifisch ist. Beispiele hierfür sind ja für Japanisch, ru für Russisch, vi für Vietnamesisch, zh für Chinesisch, ko für Koreanisch und de für Deutsch. Sollte der Port spezifisch sein für eine gewisse Region innerhalb eines Sprachraumes, dann fügen Sie bitte auch den Ländercode mit 2 Buchstaben hinzu. Beispiele sind en_US für nordamerikanisches Englisch und fr_CH für schweizerisches Französisch. Der language-Teil muss in der PKGNAMEPREFIX-Variable gesetzt werden. Der erste Buchstabe des name-Teils muss kleingeschrieben werden (der Rest des Namens kann Großbuchstaben enthalten. Daher seien Sie bitte umsichtig, wenn Sie den Namen einer Software konvertieren, welche Grossbuchstaben enthält). Es ist Tradition, Perl 5-Module durch ein vorstehendes p5- und durch Umwandlung des doppelten Doppelpunktes in Bindestriche zu bezeichnen. So wird z.B. aus dem Data::Dumper-Modul der p5-Data-Dumper-Port. Vergewissern Sie sich, dass der Name des Ports und seine Versionsnummer klar getrennt sind und in den Variablen PORTNAME und PORTVERSION stehen. Der einzige Grund, um in PORTNAME einen Versionsteil aufzunehmen ist der, dass die Software wirklich so bezeichnet wird, wie z.B. die Ports textproc/libxml2 oder japanese/kinput2-freewnn. Ansonsten sollte PORTNAME keine versionsspezifischen Bestandteile aufweisen. Es ist vollkommen normal, dass viele Ports den gleichen PORTNAME aufweisen wie z.B. die www/apache*-Ports. In diesem Falle werden unterschiedliche Versionen (und unterschiedliche Indexeinträge) unterschieden durch die Werte von PKGNAMEPREFIX, PKGNAMESUFFIX und LATEST_LINK. Falls der Port mit verschiedenen, fest kodierten Vorgaben (üblicherweise Teil des Verzeichnisnamens in einer Familie von Ports) gebaut werden kann, dann soll der -compiled.specifics-Teil die einkompilierten Vorgaben anzeigen (der Bindestrich ist optional). Beispiele hierfür sind Papiergrößen und Font-Einheiten. Der -compiled.specifics-Teil muss in der Variablen PKGNAMESUFFIX gesetzt werden. Die Versionszeichenfolge sollte einen Bindestrich (-) am Schluss haben und eine von Punkten getrennte Liste von Integer-Zahlen und kleingeschriebenen Buchstaben sein. Es ist nicht zulässig, einen weiteren Bindestrich innerhalb des Versionsstrings zu verwenden! Die einzige Ausnahme hiervon ist die Zeichenfolge pl (bedeutet patchlevel), welche nur dann gebraucht werden darf, wenn die Applikation über keine Haupt– oder Unterversionsnummern verfügt. Wenn die Versionsbezeichnung der Software Zeichenketten wie alpha, beta, rc oder pre enthält, dann nehmen Sie bitte den ersten Buchstaben daraus und setzen ihn unmittelbar hinter einen Punkt. Falls die Versionszeichenfolge nach diesem Punkt fortgesetzt wird, sollen die Zahlen ohne einen Punkt zwischen den einzelnen Buchstaben folgen. Das Ziel ist es, die Ports anhand der Versionszeichenfolge zu sortieren. Stellen Sie bitte unbedingt sicher, dass die Bestandteile der Versionsnummer immer durch einen Punkt getrennt sind und falls Datumsangaben verwandt werden diese im Format yyyy.mm.dd und nicht dd.mm.yyyy oder gar dem nicht Y2K-kompatiblen Format yy.mm.dd vorliegen. Hier sind einige reale Beispiele, die aufzeigen, wie man den Namen einer Applikation zu einem vernünftigen Paketnamen umwandelt: Softwarename PKGNAMEPREFIX PORTNAME PKGNAMESUFFIX PORTVERSION Grund mule-2.2.2 (leer) mule (leer) 2.2.2 Keine Änderung erforderlich EmiClock-1.0.2 (leer) emiclock (leer) 1.0.2 keine Großbuchstaben für einzelne Applikationen rdist-1.3alpha (leer) rdist (leer) 1.3.a Keine Zeichenketten wie alpha erlaubt es-0.9-beta1 (leer) es (leer) 0.9.b1 keine Zeichenketten wie beta erlaubt mailman-2.0rc3 (leer) mailman (leer) 2.0.r3 keine Zeichenketten wie rc erlaubt v3.3beta021.src (leer) tiff (leer) 3.3 Was sollte denn das eigentlich sein? tvtwm (leer) tvtwm (leer) pl11 Versionsstring zwingend erforderlich piewm (leer) piewm (leer) 1.0 Versionsstring zwingend erforderlich xvgr-2.10pl1 (leer) xvgr (leer) 2.10.1 pl nur erlaubt, wenn keine Versionsnummer vorhanden gawk-2.15.6 ja- gawk (leer) 2.15.6 Japanische Sprachversion psutils-1.13 (leer) psutils -letter 1.13 Papergröße beim Paketbau fix kodiert pkfonts (leer) pkfonts 300 1.0 Paket für 300 DPI Schriftarten Falls es in der Originalquelle überhaupt keinen Anhaltspunkt für irgendeine Versionsbezeichnung gibt und es unwahrscheinlich ist, dass der Autor jemals eine neue Version veröffentlichen wird, dann setzen Sie bitte die Version einfach auf 1.0 (wie im obigen Beispiel piewm). Sie können auch den Autor fragen oder eine Datumszeichenfolge (yyyy.mm.dd) als Version verwenden. Kategorisierung <makevar>CATEGORIES</makevar> Wenn ein Paket erzeugt wird, dann wird es unter /usr/ports/packages/All abgelegt und von einem oder mehreren Unterverzeichnissen werden auf /usr/ports/packages Links erstellt. Die Namen dieser Unterverzeichnisse werden durch die Variable CATEGORIES festgelegt. Dies geschieht, um dem Nutzer zu helfen, eine große Zahl von Paketen auf einer FTP-Webseite oder einer CD/DVD zu durchsuchen. Bitte werfen Sie einen Blick auf die Aktuelle Liste der Kategorien und suchen Sie die beste Kategorie für Ihren Port aus. Diese Liste legt auch fest, an welcher Stelle in der Ports-Sammlung der Port eingefügt wird. Falls Sie mehrere Kategorien angeben wird angenommen, dass die Dateien des Ports im Unterverzeichnis mit dem Namen der ersten angegebenen Kategorie liegen. Schauen Sie bitte unten für weitere Informationen darüber, wie man die richtige Kategorie bestimmt. Aktuelle Liste der Kategorien Hier ist die aktuelle Liste der Kategorien. Die mit einem Asterisk (*) bezeichneten sind virtuelle Kategorien, also solche, welche über kein eigenes Unterverzeichnis in der Ports-Sammlung verfügen. Sie werden nur als Sekundärkategorien benutzt und sind nur für Suchzwecke eingerichtet worden. Für nicht-virtuelle Kategorien finden Sie eine einzeilige Beschreibung in der Variable COMMENT im Makefile des jeweiligen Unterverzeichnisses. Kategorie Beschreibung Anmerkung accessibility Ports für behinderte Menschen. afterstep* Ports für den AfterStep Window Manager. arabic Arabische Sprachunterstützung. archivers Archivierungswerkzeuge. astro Ports für Astronomie. audio Sound-Unterstützung. benchmarks Benchmarking-Werkzeuge. biology Software für Biologie. cad CAD-Werkzeuge. chinese Chinesische Sprachunterstützung. comms Kommunikationsprogramme. Hauptsächlich Software für serielle Schnittstellen. converters Zeichensatz-Konverter. databases Datenbanken. deskutils Dinge, die vor der Erfindung des Computers auf dem Schreibtisch waren. devel Entwicklungs-Werkzeuge. Legen Sie keine Bibliotheken hier ab, nur weil es Bibliotheken sind, es sei denn, sie gehören wirklich nirgendwo anders hin. dns DNS-bezogene Software. docs* Meta-Ports für die FreeBSD-Dokumentation. editors allgemeine Editoren. Spezielle Editoren gehören in Ihre jeweilige Kategorie, (z.B. gehört ein mathematischer Formeleditor in math). elisp* Emacs-lisp-Ports. emulators Emulatoren für andere Betriebssysteme. Terminal-Emulatoren gehören nicht hierher; X-basierende gehören zu x11 und text-basierende zu comms oder misc, abhängig von deren genauer Funktionalität. finance Finanz-Software und ähnliches. french Französische Sprachunterstützung. ftp FTP Client- und Server-Werkzeuge. Falls Ihr Port sowohl FTP als auch HTTP unterstützt, stellen Sie ihn in ftp mit der Zweitkategorie www. games Spiele. geography* geografische Software. german Deutsche Sprachunterstützung. gnome* Ports für GNOME gnustep* Software für GNUstep. graphics grafische Werkzeuge. hamradio* Software für Amateurfunk. haskell* Software für die Haskell-Programmiersprache. hebrew Hebräische Sprachunterstützung. hungarian Ungarische Sprachunterstützung. ipv6* IPv6-bezogene Software. irc Internet Relay Chat (IRC)-Werkzeuge. japanese Japanische Sprachunterstützung. java - Software für die Java-Programmiersprache. + Software für die Java™-Programmiersprache. Die java-Kategorie sollte nicht die Einzige für einen Port sein mit Ausnahme der direkt nur mit der Programmiersprache zusammenhängenden Applikationen. Porter sollten java nicht als Hauptkategorie eines Ports wählen. kde* Ports für das K Desktop Environment (KDE)-Projekt. kld* Kernelmodule. korean Koreanische Sprachunterstützung. lang Programmiersprachen. linux* Linux-Applikationen und -Werkzeuge. lisp* Software für die Lisp-Programmiersprache. mail Mail-Software. math Numerische Berechnungen und andere mathematische Werkzeuge. mbone MBone-Applikationen. misc Verschiedene Werkzeuge. Hauptsächlich Werkzeuge, die nicht anderswo hingehören. Versuchen Sie, falls irgend möglich, eine bessere Kategorie für Ihren Port zu finden als misc, weil Ports hier leicht untergehen. multimedia Multimedia-Software. net Verschiedene Netzwerk-Software. net-im Instant Messaging-Software. net-mgmt Netzwerk-Management-Software. net-p2p Peer to peer-Netzwerkprogramme. news USENET News-Software. palm Software für Palm™. parallel* Applikationen für paralleles Rechnen. pear* Ports für das Pear PHP-Framework. perl5* Ports, welche Perl Version 5 benötigen. plan9* Verschiedene Programme von Plan9. polish Polnische Sprachunterstützung. ports-mgmt Hilfsprogramme für das Installieren und Entwickeln von FreeBSD Ports und Paketen. portuguese Portugiesische Sprachunterstützung. print Drucker-Software. Desktop Veröffentlichungs-Werkzeuge (DTP, Betrachter etc.) gehören auch hierher. python* Software für Python. ruby* Software für Ruby. rubygems* Ports für RubyGems-Pakete. russian Russische Sprachunterstützung. scheme* Software für die Scheme-Programmiersprache. science Wissenschaftliche Programme, die in keine andere Kategorie passen wie z.B. astro, biology und math. security Security-Werkzeuge. shells Shells. spanish* Spanische Sprachunterstützung. sysutils System-Werkzeuge. tcl* Ports, welche Tcl benötigen. textproc Textverarbeitungsprogramme. Dies beinhaltet nicht DTP-Werkzeuge, diese gehören in print. tk* Ports, welche Tk benötigen. ukrainian Ukrainische Sprachunterstützung. vietnamese Vietnamesische Sprachunterstützung. windowmaker* Ports für den WindowMaker Window-Manager. www Software für das World Wide Web (WWW). HTML-Werkzeuge gehören auch hierher. x11 X-Window-System und dergleichen. Diese Kategorie ist nur für Software, welche direkt X unterstützt. Fügen Sie keine normalen X-Applikationen hinzu. Die meisten davon gehören in eine andere x11-*-Kategorie (siehe unten). Falls Ihr Port eine X-Applikation ist, dann definieren Sie bitte USE_XLIB (impliziert durch USE_IMAKE) und fügen ihn der entsprechenden Kategorie hinzu. x11-clocks X11-Uhren. x11-drivers X11-Treiber. x11-fm X11-Dateimanager. x11-fonts X11-Schriftarten und Werkzeuge. x11-servers X11-Server. x11-themes X11-Themes. x11-toolkits X11-Toolkits. x11-wm X11-Window-Manager. xfce* Ports in Zusammenhang mit Xfce. zope* Zope-Unterstützung. Wählen der richtigen Kategorie Da viele der Kategorien sich überlappen, müssen Sie oft festlegen, welches die primäre Kategorie Ihres Ports ist. Hierzu gibt es einige Regeln, welche diese Auswahl bestimmen. Hier ist die Liste der Regeln mit abnehmender Wichtigkeit: Die erste (primäre) Kategorie muss eine physische (keine virtuelle, siehe oben) sein. Dies ist notwendig damit Pakete erstellt werden können. Die nachfolgenden Kategorien können wahllos virtuelle oder physische Kategorien sein. Sprachspezifische Kategorien kommen immer zuerst. Wenn Ihr Port z.B. Japanische X11-Schriftarten installiert, dann muss Ihre CATEGORIES-Zeile japanese x11-fonts enthalten. Spezifische Kategorien werden vor weniger spezifischen Kategorien aufgelistet. Ein HTML-Editor sollte z.B. als www editors aufgeführt werden und nicht umgekehrt. Genauso sollten Sie keinen Port unter net aufführen, wenn er zu irc, mail, mbone, news, security oder www passt, da net stillschweigend eingeschlossen ist in diesen Kategorien. x11 wird nur als sekundäre Kategorie benutzt, wenn die primäre Kategorie eine sprachspezifische ist. Keinesfalls sollten Sie x11 in die Kategorie-Zeile einer X-Applikation setzen. Emacs modes gehören in die gleiche Kategorie wie die vom jeweiligen mode unterstützte Applikation und nicht in editors. Ein Emacs mode z.B. für das Editieren von Quelltext einer bestimmten Programmiersprache gehört zur Kategorie lang. Für Ports, die vom Benutzer ladbare Kernelmodule installieren, sollte die virtuelle Kategorie kld in die CATEGORIES-Zeile aufgenommen werden. misc sollte nicht zusammen mit irgendeiner anderen nicht-virtuellen Kategorie auftreten. Falls Sie misc mit einer anderen Kategorie in CATEGORIES haben bedeutet dies, dass Sie gefahrlos misc streichen und die andere Kategorie alleine verwenden können! Falls Ihr Port wirklich in keine andere Kategorie passt, verwenden Sie bitte misc. Falls Sie sich über die Kategorie im Unklaren sind, hinterlassen Sie bitte einen Kommentar in Ihrem per &man.send-pr.1; eingereichten Bericht, damit wir diese Frage vor dem Import diskutieren können. Falls Sie ein Committer sind, schicken Sie bitte eine Nachricht an &a.ports;, damit die Frage im Vorhinein erörtert werden kann. Neue Ports werden zu häufig falsch kategorisiert und werden sofort wieder verschoben. Das bläht das Master Source Repository unnötig auf. Eine neue Kategorie vorschlagen Da die Ports-Sammlung über viele Jahre gewachsen ist, wurden viele neue Kategorien hinzugefügt. Neue Kategorien können virtuell (ohne eigenes Unterverzeichnis in der Ports-Sammlung) oder physisch sein. Der nachfolgende Text führt einige Punkte auf, welche bei der Neueinführung einer physischen Kategorie beachtet werden müssen, damit Sie dies bei einem eventuellen Vorschlag Ihrerseits berücksichtigen können. Unsere bestehende Maxime ist die Vermeidung der Neuanlage von physischen Kategorien, solange nicht eine große Zahl von Ports zugeordnet werden können oder falls ihr nicht Ports zugehören würden, welche eine logisch abgegrenzte Gruppe von limitiertem öffentlichem Interesse zugehören würden (zum Beispiel neue Sprachkategorien) oder vorzugsweise beides. Die Erklärung dafür ist, dass eine Neuanlage einer physischen Kategorie einen erheblichen Arbeitsaufwand sowohl für die Committer als auch diejenigen Nutzer bedeutet, welche die Änderungen der Ports-Sammlung nachvollziehen. Zusätzlich verursachen Vorschläge für neue Kategorien oftmals Kontroversen (natürlich deswegen, weil es keinen klaren Konsens darüber gibt, welche Kategorie als zu groß betrachtet werden muss noch ob sich bestimmte Kategorien zur einfachen Suche eignen (und wie viele Kategorien überhaupt ideal wären) und so weiter). Hier ist das Prozedere: Schlagen Sie die neue Kategorie auf &a.ports; vor. Sie sollten eine detaillierte Begründung für die neue Kategorie beifügen einschließlich einer Erklärung, warum Sie meinen, die existierenden Kategorien seien nicht ausreichend. Zeigen Sie außerdem eine Liste der zu verschiebenden Ports (falls neue Ports in GNATS auf ihren commit warten, die in diese Kategorie passen würden. Listen Sie diese bitte auch mit auf). Sind Sie der Maintainer oder Einreicher dieser Ports, erwähnen Sie es bitte. Es verleiht Ihrem Vorschlag mehr Gewicht. Nehmen Sie an der Diskussion teil. Falls es Unterstützung für Ihren Vorschlag geben sollte, reichen Sie bitte einen PR ein, welcher die Begründung und die Liste der betroffenen Ports enthält, die verschoben werden müssen. Idealerweise sollte der PR Patches für Folgendes enthalten: Makefiles für die neuen Ports nach dem Repocopy Makefile für die neue Kategorie Makefile für die alten Kategorien der betroffenen Ports Makefiles für Ports, welche von den alten Ports abhängen Für zusätzliches Ansehen sorgen Sie, wenn Sie die anderen Dateien, die geändert werden müssen, beifügen wie in der Direktive des Committer's Guide beschrieben. Da es die Ports-Infrastruktur beeinflusst und nicht nur die Durchführung von Repocopies und möglicherweise sogar Regressionstests auf dem Build Cluster durchgeführt werden müssen, sollte der PR dem Ports Management Team &a.portmgr; zugeordnet werden. Sobald der PR bestätigt wurde muss ein Committer den Rest der Prozedur durchführen, welche im Committers Guide beschrieben ist. Das Vorschlagen einer neuen virtuellen Kategorie ist ähnlich, aber wesentlich weniger aufwendig, weil keine Ports verschoben werden müssen. In diesem Falle müssen nur die Patches an den PR beigefügt werden, welche die neue Kategorie zur Variable CATEGORIES der betroffenen Ports hinzufügen. Vorschlagen einer Neuorganisation aller Kategorien Von Zeit zu Zeit schlägt jemand eine komplette Neuorganisation aller Ports, entweder mit einer zweistufigen Struktur oder irgendeiner Art von Schlüsselwörtern, vor. Bis heute wurde keiner dieser Vorschläge umgesetzt, weil sie zwar einfach zu machen sind, aber der Aufwand zur Umsetzung und Reorganisation der kompletten Ports-Sammlung schlichtweg mörderisch wäre. Bitte lesen Sie die Geschichte dieser Vorschläge in den Archiven der Mailinglisten nach, bevor Sie diese Ideen nochmals unterbreiten. Zudem sollten Sie gewappnet sein, dass man Sie auffordert, einen arbeitsfähigen Prototyp vorzulegen. Die Distributionsdateien Der zweite Teil des Makefile beschreibt die Dateien, welche heruntergeladen werden müssen, um den Port zu bauen und wo diese Dateien zu finden sind. <makevar>DISTVERSION/DISTNAME</makevar> DISTNAME ist der Name der Applikation wie er von den Autoren vergeben wurde. DISTNAME hat als Vorgabe ${PORTNAME}-${PORTVERSION} also überschreiben Sie diese Vorgabe nur, wenn es notwendig ist. DISTNAME wird nur an zwei Stellen genutzt. Erstens: (DISTFILES) hat als Vorgabe ${DISTNAME}${EXTRACT_SUFX}. Zweitens: Die Distributionsdatei soll in einem Unterverzeichnis namens WRKSRC extrahiert werden, dessen Vorgabe work/${DISTNAME} ist. Manche Drittanbieter-Namen, welche nicht in das Schema ${PORTNAME}-${PORTVERSION} passen, können durch Setzen von DISTVERSION automatisch behandelt werden. PORTVERSION und DISTNAME werden automatisch abgeleitet, können aber natürlich manuell überschrieben werden. Die folgende Tabelle führt einige Beispiele auf: DISTVERSION PORTVERSION 0.7.1d 0.7.1.d 10Alpha3 10.a3 3Beta7-pre2 3.b7.p2 8:f_17 8f.17 PKGNAMEPREFIX und PKGNAMESUFFIX beeinflussen DISTNAME nicht. Beachten Sie bitte auch, dass Sie DISTNAME unverändert lassen sollten, falls WRKSRC denselben Wert hat wie work/${PORTNAME}-${PORTVERSION} und gleichzeitig dass Archiv des originalen Quelltextes anders benannt ist als ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}. Es ist einfacher DISTFILES zu definieren, als DISTNAME und WRKSRC (und möglicherweise EXTRACT_SUFX) zu setzen. <makevar>MASTER_SITES</makevar> Dokumentieren Sie das Verzeichnis der FTP/HTTP-URL, welche auf den originalen Tarball zeigt, in der Variable MASTER_SITES. Bitte vergessen Sie niemals den Schrägstrich (/) am Ende! Die make-Makros werden versuchen, diese Festlegung für die Aufbereitung der Distributionsdateien mittels FETCH zu benutzen, falls sie diese nicht schon auf dem System finden. Es wird empfohlen, mehrere Webseiten in dieser Liste aufzuführen, vorzugsweise auf verschiedenen Kontinenten. Dies ist ein Schutz gegen Probleme bei größeren Ausfällen im Internet. Wir planen sogar Unterstützung einzubauen, die automatisch einen Server in der Nähe zum Herunterladen bestimmt. Die Verfügbarkeit von vielen Webseiten wird dieses Vorhaben beträchtlich erleichtern. Falls der originale Tarball Teil eines populären Archivs ist, wie X-contrib, GNU oder Perl CPAN, können Sie möglicherweise auf diese Seiten in einer einfachen und kompakten Form mittels MASTER_SITE_* (d.h., MASTER_SITE_XCONTRIB, MASTER_SITE_GNU und MASTER_SITE_PERL_CPAN) referenzieren. Setzen Sie einfach MASTER_SITES auf eine dieser Variablen und MASTER_SITE_SUBDIR auf den Pfad innerhalb des Archivs. Hier ist ein Beispiel: MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications Diese Variablen werden in /usr/ports/Mk/bsd.sites.mk definiert. Es werden ständig neue Einträge hinzugefügt, daher stellen Sie bitte unbedingt sicher, dass Sie die neueste Version verwenden, bevor Sie einen Port einschicken. Der Nutzer kann ebenfalls die Variable MASTER_SITE_* in der /etc/make.conf setzen. Dadurch werden unsere Vorgaben überschrieben und stattdessen werden die Spiegel-Server seiner Wahl für die populären Archive genutzt. <makevar>EXTRACT_SUFX</makevar> Falls Sie eine Distributionsdatei haben, die ein eigentümliches Suffix nutzt, um die Art der Kompression anzuzeigen, dann setzen Sie EXTRACT_SUFX. Ist die Distributionsdatei zum Beispiel im Stil von foo.tgz anstatt des normalen foo.tar.gz benannt, würden Sie schreiben: DISTNAME= foo EXTRACT_SUFX= .tgz Falls erforderlich, setzen die Variablen USE_BZIP2 und USE_ZIP automatisch EXTRACT_SUFX auf .tar.bz2 oder .zip. Falls keine der beiden gesetzt ist, dann verwendet EXTRACT_SUFX die Vorgabe .tar.gz. Sie müssen niemals beide Variablen EXTRACT_SUFX und DISTFILES setzen. <makevar>DISTFILES</makevar> Manchmal haben die zu ladenden Dateien keinerlei Ähnlichkeit mit dem Namen des Ports. Es könnte z.B. source.tar.gz oder ähnlich heißen. In anderen Fällen könnte der Quelltext in mehreren Archiven sein und alle müssen heruntergeladen werden. Falls dies der Fall ist, setzen Sie DISTFILES als eine durch Leerzeichen getrennte Liste aller Dateien, die geladen werden müssen. DISTFILES= source1.tar.gz source2.tar.gz Wenn nicht ausdrücklich gesetzt, verwendet DISTFILES als Vorgabe ${DISTNAME}${EXTRACT_SUFX}. <makevar>EXTRACT_ONLY</makevar> Falls nur einige der DISTFILES extrahiert werden müssen (z.B. eine Datei ist der Quelltext und eine andere ist ein unkomprimiertes Dokument), dann listen Sie die zu extrahierenden Dateien in EXTRACT_ONLY auf. DISTFILES= source.tar.gz manual.html EXTRACT_ONLY= source.tar.gz Falls keine der DISTFILES unkomprimiert sein sollte, dann setzen Sie EXTRACT_ONLY auf einen leeren String. EXTRACT_ONLY= <makevar>PATCHFILES</makevar> Falls Ihr Port zusätzliche Patches benötigt, welche per FTP oder HTTP verfügbar sind, dann setzen Sie PATCHFILES auf den Namen der Dateien und PATCH_SITES auf die URL des Verzeichnisses, das diese Patches enthält (das Format ist das gleiche wie MASTER_SITES). Falls ein Patch wegen einiger zusätzlicher Pfadnamen nicht relativ zum Anfang des Quelltextbaumes (d.h., WRKSRC) liegt, dann setzen Sie bitte PATCH_DIST_STRIP entsprechend. Wenn z.B. alle Pfadnamen in diesem Patch ein zusätzliches foozolix-1.0/ vor ihren Dateinamen aufweisen, dann setzen Sie bitte PATCH_DIST_STRIP=-p1. Kümmern Sie sich nicht darum, ob die Patches komprimiert sind. Sie werden automatisch dekomprimiert, wenn die Dateinamen auf .gz oder .Z enden. Falls der Patch zusammen mit anderen Dateien in einem gezippten Tarball verteilt wird (z.B. mit Dokumentation), dann können Sie nicht PATCHFILES verwenden. In diesem Fall fügen Sie den Namen und den Ort dieses Tarballs zu DISTFILES und MASTER_SITES. Benutzen Sie dann die EXTRA_PATCHES-Variable, um auf diese Dateien zu zeigen und bsd.port.mk wird automatisch diese Dateien nutzen. Kopieren Sie niemals Patch-Dateien in das PATCHDIR-Verzeichnis, weil es möglicherweise nicht beschreibbar ist. Der Tarball wird zusammen mit dem anderen Quelltext extrahiert werden. Eine ausdrückliche Dekomprimierung eines mit gzip oder compress erzeugten Tarball ist nicht notwendig. Sollten Sie dies dennoch vorgeben, so beachten Sie bitte peinlich genau, dass Sie nichts überschreiben, was bereits im Verzeichnis vorhanden ist. Vergessen Sie auch nicht den kopierten Patch im Target von pre-clean zu entfernen. Verschiedene Distributionsdateien oder Patches von verschiedenen Seiten und Verzeichnissen (<literal>MASTER_SITES:n</literal>) (Betrachten Sie es als in irgendeiner Form fortgeschrittenes Thema. Neulinge sollten möglicherweise diesen Abschnitt beim ersten Lesen überspringen). Dieser Abschnitt stellt Informationen über die Mechanismen zum Herunterladen von Dateien zur Verfügung und behandelt die Variablen MASTER_SITES:n und MASTER_SITES_NN. Wir beziehen uns im weiteren Text auf diese Variablen als MASTER_SITES:n. Etwas Hintergrundinformation zu Beginn: OpenBSD verfügt über eine sehr elegante Option innerhalb der Variablen DISTFILES und PATCHFILES. Sowohl Dateien als auch Patches können mit angehängten :n-Bezeichnern versehen werden wobei n in beiden Fällen [0-9] sein kann und eine Gruppenzugehörigkeit anzeigt. Ein Beispiel hierfür ist: DISTFILES= alpha:0 beta:1 In OpenBSD wird die Datei alpha mit der Variable MASTER_SITES0 verknüpft anstatt dem in FreeBSD gebräuchlichen MASTER_SITES und beta mit MASTER_SITES1. Das ist eine sehr interessante Möglichkeit, die endlose Suche nach der richtigen Download-Seite zu verkürzen. Stellen Sie sich zwei Dateien in DISTFILES und 20 Webseiten in der Variable MASTER_SITES vor. Alle Seiten sind erschreckend langsam, beta findet sich auf allen Seiten in MASTER_SITES und alpha kann nur auf der zwanzigsten Seite gefunden werden. Wäre es nicht reine Verschwendung, wenn der Maintainer alle Seiten zuvor überprüfen müsste? Kein guter Start für das wundervolle Wochenende! Übertragen Sie diesen Umstand auf noch mehr DISTFILES und mehr MASTER_SITES. Ganz sicher würde unser distfiles survey master die Erleichterung sehr zu schätzen wissen, die eine solche Verringerung der Netzwerkbelastung bringen würde. In den nächsten Abschnitten sehen Sie die Implementierung dieser Idee durch FreeBSD. Dabei wurde das Konzept von OpenBSD ein wenig verbessert. Prinzipielle Information Dieser Abschnitt informiert Sie, wie Sie schnell ein fein granuliertes Herunterladen von vielen Dateien und Fehlerbereinigungen von verschiedenen Webseiten und Unterverzeichnissen bewerkstelligen. Wir beschreiben hier den Fall der vereinfachten Nutzung von MASTER_SITES:n. Das ist für die meisten Szenarien ausreichend. Falls Sie weitere Informationen benötigen, sollten Sie den nächsten Abschnitt lesen. Einige Programme bestehen aus mehreren Dateien, welche von verschiedenen Webseiten heruntergeladen werden müssen. Zum Beispiel besteht Ghostscript aus dem Kern des Programms und einer großen Zahl von Treiberdateien, die vom Drucker des Benutzers abhängen. Einige dieser Treiberdateien werden mit der Kernapplikation mitgeliefert aber viele müssen von verschiedenen Webseiten heruntergeladen werden. Um das zu unterstützen, muss jeder Eintrag in DISTFILES mit einem Komma und einem tag name abgeschlossen werden. Jeder in MASTER_SITES aufgeführte Webseite folgt ein Komma und eine Marke (tag), die anzeigt, welche Datei von dieser Webseite heruntergeladen werden kann. Stellen Sie sich bitte eine Applikation vor, deren Quelltext in zwei Teile aufgeteilt ist, source1.tar.gz und source2.tar.gz, welche von zwei verschiedenen Webseiten heruntergeladen werden müssen. Das Makefile des Port würde Zeilen enthalten wie in . Vereinfachtes Beispiel für den Gebrauch von <literal>MASTER_SITES:n</literal> mit einer Datei pro Webseite MASTER_SITES= ftp://ftp.example1.com/:source1 \ ftp://ftp.example2.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 Verschiedene Dateien können die gleiche Marke aufweisen. Ausgehend vom vorherigen Beispiel nehmen wir an, dass es noch eine dritte Datei gibt (source3.tar.gz), welche von ftp.example2.com heruntergeladen werden soll. Das Makefile würde dann aussehen wie . Vereinfachtes Beispiel für den Gebrauch von <literal>MASTER_SITES:n</literal> mit mehr als einer Datei pro Webseite MASTER_SITES= ftp://ftp.example1.com/:source1 \ ftp://ftp.example2.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 \ source3.tar.gz:source2 Ausführliche Information In Ordnung, das vorherige Beispiel reicht nicht für Ihre Bedürfnisse? In diesem Abschnitt werden wir im Detail erklären, wie der fein granulierte Mechanismus zum Herunterladen (MASTER_SITES:n) funktioniert und wie Sie Ihre Ports modifizieren, um ihn zu nutzen. Elemente können nachstehend bezeichnet werden mit :n wobei n in diesem Falle [^:,]+ ist. Das heißt n könnte theoretisch jede alphanumerische Zeichenkette sein, aber wir beschränken sie auf [a-zA-Z_][0-9a-zA-Z_]+ für diesen Moment. Zudem ist die Zeichenkette case sensitive; d.h. n unterscheidet sich von N. Allerdings dürfen die folgenden Wörter nicht gebraucht werden, da sie spezielle Bedeutungen haben: default, all und ALL (diese Wörter werden intern genutzt in Punkt ). Ausserdem ist DEFAULT ein reserviertes Wort (beachten Sie ). Elemente mit angehängtem :n gehören zur Gruppe n, :m gehört zur Gruppe m und so weiter. Elemente ohne Anhängsel sind gruppenlos, d.h. sie gehören alle zu der speziellen Gruppe DEFAULT. Falls sie an irgendeinem Element DEFAULT hängen, ist dies überflüssig, es sei denn Sie wollen, dass ein Element sowohl zu DEFAULT als auch anderen Gruppen gleichzeitig gehört (beachten Sie ). Die folgenden Beispiele sind gleichwertig, aber das erste Beispiel ist vorzuziehen: MASTER_SITES= alpha MASTER_SITES= alpha:DEFAULT Gruppen sind nicht ausschliessend, d.h. ein Element kann mehreren Gruppen gleichzeitig angehören und eine Gruppe wiederum kann entweder mehrere Elemente oder überhaupt keine aufweisen. Wiederholte Elemente sind schlicht nur wiederholte Elemente. Wenn Sie wollen, dass ein Element gleichzeitig zu mehreren Gruppen gehört, dann können Sie diese durch ein Komma (,) trennen. Anstatt jedes Mal ein anderes Anhängsel zu verwenden und Wiederholungen aufzuführen, können Sie mehrere Gruppen auf einmal in einem einzigen Anhängsel bestimmen. Zum Beispiel markiert :m,n,o ein Element, welches zu den Gruppen m, n und o gehört. Alle folgenden Beispiele sind gleichwertig, aber das erste Beispiel ist vorzuziehen: MASTER_SITES= alpha alpha:SOME_SITE MASTER_SITES= alpha:DEFAULT alpha:SOME_SITE MASTER_SITES= alpha:SOME_SITE,DEFAULT MASTER_SITES= alpha:DEFAULT,SOME_SITE Alle Webseiten in einer Gruppe werden gemäß MASTER_SORT_AWK sortiert. Alle Gruppen innerhalb von MASTER_SITES und PATCH_SITES werden genauso sortiert. Gruppensemantik kann benutzt werden in den folgenden Variablen: MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR, PATCH_SITE_SUBDIR, DISTFILES und PATCHFILES entsprechend der folgenden Syntax: Elemente mit MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR und PATCH_SITE_SUBDIR müssen mit einem Schrägstrich beendet werden ( /). Falls Elemente zu irgendwelchen Gruppen gehören, muss :n direkt nach dem Trenner / stehen. Der MASTER_SITES:n-Mechanismus verlässt sich auf das Vorhandensein des Trennzeichens /, um verwirrende Elemente zu vermeiden in denen :n ein zulässiger Bestandteil des Elementes ist und das Auftreten von :n die Gruppe n anzeigt. Aus Kompatibilitätsgründen (da der /-Trenner sowohl in MASTER_SITE_SUBDIR als auch PATCH_SITE_SUBDIR-Elementen nicht erforderlich ist) wird, falls das auf das Anhängsel folgende nächste Zeichen kein / ist, auch :n als gültiger Teil des Elementes behandelt anstatt als Gruppenzusatz, selbst wenn ein Element ein angehängtes :n aufweist. Beachten Sie sowohl als auch . Ausführliches Beispiel von <literal>MASTER_SITES:n</literal> in <makevar>MASTER_SITE_SUBDIR</makevar> MASTER_SITE_SUBDIR= old:n new/:NEW Verzeichnisse innerhalb der Gruppe DEFAULT -> old:n Verzeichnisse innerhalb der Gruppe NEW -> new Ausführliches Beispiel von <literal>MASTER_SITES:n</literal> mit Komma-Operator, mehreren Dateien, mehreren Webseiten und mehreren Unterverzeichnissen MASTER_SITES= http://site1/%SUBDIR%/ http://site2/:DEFAULT \ http://site3/:group3 http://site4/:group4 \ http://site5/:group5 http://site6/:group6 \ http://site7/:DEFAULT,group6 \ http://site8/%SUBDIR%/:group6,group7 \ http://site9/:group8 DISTFILES= file1 file2:DEFAULT file3:group3 \ file4:group4,group5,group6 file5:grouping \ file6:group7 MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ directory-one/:group6,DEFAULT \ directory Das vorstehende Beispiel führt zu einem fein granulierten Herunterladen. Die Webseiten werden in der exakten Reihenfolge ihrer Nutzung aufgelistet. file1 wird heruntergeladen von MASTER_SITE_OVERRIDE http://site1/directory-trial:1/ http://site1/directory-one/ http://site1/directory/ http://site2/ http://site7/ MASTER_SITE_BACKUP file2 wird genauso heruntergeladen wie file1, da sie zur gleichen Gruppe gehören MASTER_SITE_OVERRIDE http://site1/directory-trial:1/ http://site1/directory-one/ http://site1/directory/ http://site2/ http://site7/ MASTER_SITE_BACKUP file3 wird heruntergeladen von MASTER_SITE_OVERRIDE http://site3/ MASTER_SITE_BACKUP file4 wird heruntergeladen von MASTER_SITE_OVERRIDE http://site4/ http://site5/ http://site6/ http://site7/ http://site8/directory-one/ MASTER_SITE_BACKUP file5 wird heruntergeladen von MASTER_SITE_OVERRIDE MASTER_SITE_BACKUP file6 wird heruntergeladen von MASTER_SITE_OVERRIDE http://site8/ MASTER_SITE_BACKUP Wie gruppiere ich eine der speziellen Variablen aus bsd.sites.mk, d.h. MASTER_SITE_SOURCEFORGE? Lesen Sie . Ausführliches Beispiel von <literal>MASTER_SITES:n</literal> mit <makevar>MASTER_SITE_SOURCEFORGE</makevar> MASTER_SITES= http://site1/ ${MASTER_SITE_SOURCEFORGE:S/$/:sourceforge,TEST/} DISTFILES= something.tar.gz:sourceforge something.tar.gz wird von allen Webseiten innerhalb von MASTER_SITE_SOURCEFORGE heruntergeladen. Wie nutze ich dies mit PATCH*-Variablen. In allen Beispielen wurden MASTER*-Variablen genutzt, aber sie funktionieren exakt genauso mit PATCH*-Variablen, wie Sie an . sehen können. Vereinfachte Nutzung von <literal>MASTER_SITES:n</literal> mit <makevar>PATCH_SITES</makevar>. PATCH_SITES= http://site1/ http://site2/:test PATCHFILES= patch1:test Was ändert sich für die Ports? Was ändert sich nicht? Alle bestehenden Ports bleiben gleich. Der Code für MASTER_SITES:n wird nur aktiviert, falls es Elemente mit angehängtem :n entsprechend den zuvor erwähnten Syntax-Regeln wie in gezeigt gibt. Das Target des Port bleibt gleich: checksum, makesum, patch, configure, build etc. Mit der offensichtlichen Ausnahme von do-fetch, fetch-list, master-sites und patch-sites. do-fetch: nutzt die neue Gruppierung DISTFILES und PATCHFILES mit ihren darauf zutreffenden Gruppenelementen in MASTER_SITES und PATCH_SITES welche zutreffende Gruppenelemente sowohl in MASTER_SITE_SUBDIR als auch PATCH_SITE_SUBDIR aufweisen. Sehen Sie hierzu . fetch-list: arbeitet wie das alte fetch-list mit der Ausnahme, dass es nur wie do-fetch gruppiert. master-sites und patch-sites: (inkompatibel zu älteren Versionen) geben nur die Elemente der Gruppe DEFAULT zurück. Beziehungsweise sie führen genau genommen die Targets von master-sites-default und patch-sites-default aus. Weiterhin ist der Gebrauch des Target entweder von master-sites-all oder patch-sites-all der direkten Überprüfung von MASTER_SITES oder PATCH_SITES vorzuziehen. Zudem ist nicht garantiert, dass das direkte Überprüfen in zukünftigen Versionen funktionieren wird. Sehen Sie für weitere Informationen zu diesen neuen Port-Targets. Neue Port-Targets Es gibt master-sites-n und patch-sites-n-Targets, welche die Elemente der jeweiligen Gruppe n innerhalb von MASTER_SITES und PATCH_SITES auflisten. Beispielweise werden sowohl master-sites-DEFAULT als auch patch-sites-DEFAULT die Elemente der Gruppe DEFAULT, master-sites-test und patch-sites-test der Gruppe test usw. zurückgeben. Es gibt das neue Target master-sites-all und patch-sites-all, welche die Arbeit der alten Targets master-sites und patch-sites übernehmen. Sie geben die Elemente aller Gruppen zurück,als würden sie zur gleichen Gruppe gehören - mit dem Vorbehalt, dass sie so viele MASTER_SITE_BACKUP und MASTER_SITE_OVERRIDE auflisten wie Gruppen mittels DISTFILES oder PATCHFILES definiert sind. Das gleiche gilt entsprechend für master-sites-all und patch-sites-all. <makevar>DIST_SUBDIR</makevar> Verhindern Sie, dass Ihr Port das Verzeichnis /usr/ports/distfiles in Unordnung bringt. Falls Ihr Port eine ganze Reihe von Dateien herunterladen muss oder eine Datei enthält, die einen Namen hat, der möglicherweise mit anderen Ports in Konflikt stehen könnte (d.h.Makefile), dann setzen Sie die Variable DIST_SUBDIR auf den Namen des Ports (${PORTNAME} oder ${PKGNAMEPREFIX}${PORTNAME} sollte hervorragend funktionieren). Dies wird DISTDIR von der Vorgabe /usr/ports/distfiles auf /usr/ports/distfiles/DIST_SUBDIR ändern und stellt tatsächlich alle für Ihren Port benötigten Dateien in dieses Unterverzeichnis. Es wird zusätzlich nach dem Unterverzeichnis mit dem gleichen Namen auf der Sicherung der Hauptseite auf ftp.FreeBSD.org suchen (das ausdrückliche Setzen von DISTDIR in Ihrem Makefile wird dies nicht gewährleisten, also nutzen Sie bitte DIST_SUBDIR). Dies hat keine Auswirkungen auf die Variable MASTER_SITES, die Sie in Ihrem Makefile definieren. <makevar>ALWAYS_KEEP_DISTFILES</makevar> Falls Ihr Port binäre Distfiles benutzt und eine Lizenz aufweist, die verlangt, dass das der Quelltext in Form binärer Pakete verteilt werden muss, z.B. GPL, dann wird ALWAYS_KEEP_DISTFILES den &os; Build Cluster anweisen eine Kopie der Dateien in DISTFILES vorzuhalten. Nutzer dieser Ports benötigen generell diese Dateien nicht, daher ist es ein gutes Konzept, nur dann die Distfiles zu DISTFILES hinzuzufügen, wenn PACKAGE_BUILDING definiert ist. Nutzung von <makevar>ALWAYS_KEEP_DISTFILES</makevar>. .if defined(PACKAGE_BUILDING) DISTFILES+= foo.tar.gz ALWAYS_KEEP_DISTFILES= yes .endif Wenn Sie zusätzliche Dateien zu DISTFILES hinzufügen, dann beachten Sie bitte, dass Sie diese auch in distinfo aufführen. Zudem werden die zusätzlichen Dateien normalerweise ebenso in WRKDIR extrahiert, was für einige Ports zu unbeabsichtigten Seiteneffekten führen mag und spezielle Behandlung erfordert. <makevar>MAINTAINER</makevar> Fügen Sie hier Ihre E-Mailadresse ein. Bitte. :-) Beachten Sie bitte, dass nur eine einzelne E-Mailadresse ohne Kommentar in der Variable MAINTAINER zulässig ist. Das Format sollte user@hostname.domain sein. Bitte fügen Sie keinen beschreibenden Text wie z.B. Ihren wirklichen Namen ein, dies verwirrt lediglich bsd.port.mk. Der Maintainer ist dafür verantwortlich, dass der Port aktuell gehalten wird und er sorgt dafür, dass der Port korrekt arbeitet. Für eine detaillierte Beschreibung der Verantwortlichkeiten eines Maintainers beachten Sie bitte den Abschnitt Die Herausforderung für einen Port-Maintainer. Änderungen am Port werden dem Maintainer zur Begutachtung und Zustimmung vorgelegt, bevor sie committed werden. Falls der Maintainer einem Aktualisierungs-Wunsch nicht binnen 2 Wochen (ausgenommen wichtige öffentliche Feiertage) zustimmt, dann wird dies als Maintainer-Timeout betrachtet und eine Aktualisierung kann ohne ausdrückliche Zustimmung des Maintainers erfolgen. Falls der Maintainer nicht binnen 3 Monaten zustimmt, wird er als abwesend ohne Grund betrachtet und kann als Maintainer des fraglichen Ports durch eine andere Person ersetzt werden. Ausgenommen davon ist alles, was durch das &a.portmgr; oder das &a.security-officer; betreut wird. Es dürfen niemals committs ohne vorherige Zustimmung an solchen Ports vorgenommen werden! Wir behalten uns das Recht vor, die Einreichungen eines Maintainers ohne ausdrückliche Zustimmung zu ändern, falls wir der Auffassung sind, dass dadurch die Einhaltung von Richtlinien und stilistischen Vorgaben für die Ports-Sammlung besser erfüllt wird. Zudem können größere Änderungen an der Infrastruktur der Ports zu Änderungen an einem bestimmten Port ohne Zustimmung des Maintainers führen. Diese Änderungen beeinflussen niemals die Funktionalität eines Ports. Das &a.portmgr; behält sich das Recht vor, die Maintainerschaft jedem aus irgendeinem Grund zu entziehen oder ausser Kraft zu setzen, und das Security Officer Team &a.security-officer; behält sich das Recht vor, jede Maintainerschaft aus Sicherheitsgründen aufzuheben oder ausser Kraft zu setzen. <makevar>COMMENT</makevar> Dies ist eine einzeilige Beschreibung des Ports. Bitte fügen Sie nicht den Paketnamen (oder die Version der Software) in den Kommentar ein. Der Kommentar soll mit einem Großbuchstaben beginnen und ohne Punkt enden. Hier ist ein Beispiel: COMMENT= A cat chasing a mouse all over the screen Die COMMENT-Variable soll unmittelbar nach der MAINTAINER-Variable im Makefile stehen. Bitte versuchen Sie die COMMENT-Zeile auf weniger als 70 Zeichen zu begrenzen, da sie den Nutzern als einzeilige Zusammenfassung des Ports angezeigt wird. Abhängigkeiten (dependencies) Viele Ports hängen von anderen Ports ab. Es gibt sieben Variablen, welche Sie benutzen können, um sicherzustellen, dass alle benötigten Teile auf dem Rechner des Nutzers sind. Zusätzlich gibt es einige vordefinierte Variablen für Abhängigkeiten in häufigen Fällen und einige, welche das Verhalten der Abhängigkeiten bestimmen. <makevar>LIB_DEPENDS</makevar> Diese Variable spezifiziert die Shared-Libraries, von denen der Port abhängt. Es ist eine Liste von lib:dir:target-Tupeln wobei lib den Name der gemeinsam genutzten Bibliothek, dir das Verzeichnis, in welchem sie zu finden ist, falls nicht verfügbar, und target das Target in diesem Verzeichnis angeben. Zum Beispiel wird LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg auf eine jpeg-Bibliothek mit der Hauptversionsnummer 9 prüfen, in das graphics/jpeg-Unterverzeichnis Ihrer Ports-Sammlung wechseln, es bauen und installieren, falls es nicht gefunden wird. Der target-Teil kann weggelassen werden, falls er identisch mit DEPENDS_TARGET ist (Vorgabe hierfür ist install). Der lib-Teil ist ein regulärer Ausdruck, welcher die Ausgabe von ldconfig -r ausgewertet. Werte wie intl.[5-7] und intl sind zulässig. Das erste Muster, intl.[5-7], stimmt überein mit: intl.5, intl.6 oder intl.7. Das zweite Muster, intl, stimmt überein mit jeder Version der intl-Bibliothek. Die Abhängigkeit wird zwei Mal überprüft, einmal innerhalb des extract-Target und dann innerhalb des install-Target. Zudem wird der Name der Abhängigkeit in das Paket eingefügt, damit &man.pkg.add.1; es automatisch installiert, falls es nicht auf dem Rechner des Nutzers ist. <makevar>RUN_DEPENDS</makevar> Diese Variable legt Binärdateien oder Dateien, von denen der Port abhängt, für die Laufzeit fest. Es ist eine Liste von path:dir:target-Tupeln, wobei path der Name der Binärdatei oder Datei, dir das Verzeichnis, in welchem sie gefunden werden kann, falls nicht vorhanden, und target das Target in diesem Verzeichnis angeben. Falls path mit einem Slash (/) beginnt, wird es als Datei behandelt und deren Vorhandensein wird mit test -e; überprüft. Andernfalls wird angenommen, dass es eine Binärdatei ist und which -s wird benutzt, um zu überprüfen, ob das Programm im Pfad vorhanden ist. Zum Beispiel wird RUN_DEPENDS= ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \ xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr überprüfen, ob die Datei oder das Verzeichnis /usr/local/etc/innd existiert und es erstellen und installieren aus dem news/inn-Unterverzeichnis der Ports-Sammlung, falls es nicht gefunden wird. Es wird zudem überprüft, ob die Binärdatei namens xmlcatmgr im Suchpfad vorhanden ist und danach zum Unterverzeichnis textproc/xmlcatmgr in Ihrer Ports-Sammlung wechseln, es bauen und installieren, falls es nicht gefunden wird. In diesem Fall ist innd eine Binärdatei. Falls sich eine Binärdatei an einem ungewöhnlichen Platz befindet, der nicht im Suchpfad ist, dann sollten Sie die volle Pfadangabe verwenden. Der offizielle Suchpfad PATH, welcher im Ports Cluster benutzt wird, ist /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin Die Abhängigkeit wird innerhalb des install-Target überprüft. Zudem wird der Name der Abhängigkeit in das Paket übernommen, damit &man.pkg.add.1; es automatisch installieren wird, falls es auf dem System des Nutzers nicht vorhanden ist. Der target-Teil kann weggelassen werden, wenn er der gleiche ist wie in der Variable DEPENDS_TARGET. <makevar>BUILD_DEPENDS</makevar> Diese Variable legt Binärdateien oder Dateien fest, die dieser Port zur Erstellung benötigt. Wie RUN_DEPENDS ist es eine Liste von path:dir:target-Tupeln. Zum Beispiel wird BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip überprüfen, ob eine Binärdatei unzip vorhanden ist und in das Unterverzeichnis archivers/unzip Ihrer Ports-Sammlung wechseln und sie erstellen und installieren, falls sie nicht gefunden wird. Erstellen bedeutet hier alles von der Extraktion bis zur Kompilierung. Die Abhängigkeit wird im extract-Target überprüft. Der target-Teil kann weggelassen werden, falls er identisch mit der Variable DEPENDS_TARGET ist. <makevar>FETCH_DEPENDS</makevar> Diese Variable legt eine Binärdatei oder Datei fest, welche der Port benötigt, um heruntergeladen werden zu können. Wie die vorherigen beiden Variablen ist er eine Liste von path:dir:target-Tupeln. Zum Beispiel wird FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 überprüfen, ob eine Binärdatei namens ncftp2 vorhanden ist, in das Unterverzeichnis net/ncftp2 Ihrer Ports-Sammlung wechseln, sie erstellen und installieren, falls sie nicht gefunden wird. Die Abhängigkeit wird innerhalb des fetch-Target überprüft. Der target-Teil kann weggelassen werden, falls er identisch mit der Variable DEPENDS_TARGET ist. <makevar>EXTRACT_DEPENDS</makevar> Diese Variable spezifiziert eine Binärdatei oder eine Datei, welche dieser Port für die Extraktion benötigt. Wie die vorherigen Variablen ist er eine Liste von path:dir:target-Tupeln. Zum Beispiel wird EXTRACT_DEPENDS= unzip:${PORTSDIR}/archivers/unzip überprüfen, ob eine Binärdatei namens unzip vorhanden ist, in das Unterverzeichnis archivers/unzip Ihrer Ports-Sammlung wechseln, sie erstellen und installieren, falls sie nicht gefunden wird. Die Abhängigkeit wird innerhalb des extract-Target überprüft. Der target-Teil kann weggelassen werden, falls er identisch mit der Variable DEPENDS_TARGET ist. Nutzen Sie diese Variable nur, wenn die Extraktion nicht funktioniert (die Vorgabe nimmt gzip an) und nicht mit USE_ZIP oder USE_BZIP2 wie in beschrieben zum Laufen gebracht werden kann. <makevar>PATCH_DEPENDS</makevar> Diese Variable legt eine Binärdatei oder eine Datei fest, welche dieser Port zum Patchen benötigt. Wie die vorhergehenden Variablen ist diese eine Liste von path:dir:target-Tupeln. Zum Beispiel wird PATCH_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract in das Unterverzeichnis java/jfc Ihrer Ports-Sammlung wechseln, um es zu entpacken. Die Abhängigkeit wird innerhalb des patch-Target überprüft. Der target-Teil kann entfallen, falls er identisch mit der Variable DEPENDS_TARGET ist. <makevar>USE_<replaceable>*</replaceable></makevar> Es gibt eine Reihe von Variablen, um gebräuchliche Abhängigkeiten einzukapseln, die viele Ports aufweisen. Obwohl Ihre Verwendung optional ist, können sie helfen die Übersichtlichkeit des Makefile eines Ports zu erhöhen. Jede von ihnen ist im Stil von USE_*. Der Gebrauch dieser Variablen ist beschränkt auf das Makefile eines Ports und ports/Mk/bsd.*.mk. Es ist nicht entworfen worden, um durch den Nutzer setzbare Optionen einzukapseln; benutzen Sie WITH_* und WITHOUT_* für diese Zwecke. Es ist immer falsch, irgendeine USE_*-Variable in der /etc/make.conf zu setzen. Zum Beispiel würde das Setzen von - USE_GCC=3.2 + USE_GCC=3.4 - eine Abhängigkeit für GCC32 für jeden Port - einschliesslich GCC32 selbst hinzufügen! + eine Abhängigkeit für GCC34 für jeden Port + einschliesslich GCC34 selbst hinzufügen! Die <makevar>USE_<replaceable>*</replaceable></makevar>-Varibalen Variable Bedeutung USE_BZIP2 Der Tarball dieses Ports wird mit bzip2 komprimiert. USE_ZIP Der Tarball des Ports wird mit zip komprimiert. USE_BISON Der Port benutzt bison für die Erstellung. USE_CDRTOOLS Der Port erfordert cdrecord entweder von sysutils/cdrtools oder sysutils/cdrtools-cjk, abhängig davon, was der Nutzer vorgibt. USE_GCC Dieser Port benötigt eine bestimmte Version von gcc zur Erstellung. Die genaue Version kann festgelegt werden mit - Werten wie 3.2. - Mit 3.2+ kann die mindestens + Werten wie 3.4. + Mit 3.4+ kann die mindestens erforderliche Version spezifiziert werden. Der gcc aus dem Basissystem wird genutzt, wenn er die erforderliche Version erfüllt, andernfalls wird eine geeignete Version des gcc aus den Ports kompiliert und die Variablen CC und CXX werden angepasst.
Variablen zugehörig zu gmake und dem configure-Skript werden in beschrieben, währenddessen autoconf, automake und libtool in beschrieben sind. Perl-spezifische Variablen werden in behandelt. X11-Variablen sind aufgelistet in . behandelt GNOME-bezogene Variablen und KDE-bezogene Variablen. dokumentiert Java-Variablen, während Informationen zu Apache, PHP und PEAR-Modulen enthält. Python wird in und Ruby in erörtert. stellt Variablen für SDL-Programme zur Verfügung und enthält schliesslich Variablen für Xfce.
Minimale Version einer Abhängigkeit Eine minimale Version einer Abhängigkeit kann in jeder *_DEPENDS-Variable festgelegt werden mit Ausnahme von LIB_DEPENDS durch Anwendung folgender Syntax: p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy Das erste Feld enthält einen abhängigen Paketnamen, welcher einem Eintrag in der Paketdatenbank entsprechen muss und einen Vergleich mit einer Paketversion. Die Abhängigkeit wird erfüllt, wenn p5-Spiffy-0.26 oder eine neuere Version auf dem System installiert ist. Anmerkungen zu Abhängigkeiten Wie vorstehend beschrieben ist das Vorgabe-Target DEPENDS_TARGET, wenn eine Abhängigkeit benötigt wird. Die Vorgabe hierfür ist install. Dies ist eine Nutzer-Variable; sie wird niemals im Makefile eines Ports definiert. Falls Ihr Port einen besonderen Weg benötigt, um mit einer Abhängigkeit umzugehen, dann benutzen Sie bitte den :target-Teil der *_DEPENDS-Variablen, anstatt DEPENDS_TARGET zu ändern. Falls Sie make clean schreiben, werden dessen Abhängigkeiten auch gesäubert. Falls Sie dies nicht wollen, definieren Sie die Variable NOCLEANDEPENDS in Ihrer Umgebung. Dies kann besonders erstrebenswert sein, wenn der Port etwas in seiner Liste von Abhängigkeiten hat, das sehr viel Zeit für einen rebuild benötigt wie KDE, GNOME oder Mozilla. Um von einem anderen Port bedingungslos abhängig zu sein, benutzen Sie bitte die Variable ${NONEXISTENT} als erstes Feld von BUILD_DEPENDS oder RUN_DEPENDS. Benutzen Sie dies nur, wenn Sie den Quelltext eines anderen Port benötigen. Sie können auch oft Kompilierzeit sparen, wenn Sie das Target festlegen. Zum Beispiel wird BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract immer zum jpeg-Port wechseln und ihn extrahieren. Zirkuläre Abhängigkeiten sind fatal Führen Sie niemals irgendwelche zirkulären Abhängigkeiten in der Ports-Sammlung ein! Die Struktur für die Erstellung von Ports dulde keinerlei zirkuläre Abhängigkeiten. Falls Sie dennoch eine verwenden, wird es irgendjemanden irgendwo auf der Welt geben, dessen FreeBSD-Installation nahezu sofort zusammenbricht und vielen anderen wird es sehr schnell genauso ergehen. So etwas kann extrem schwer festzustellen sein. Falls Sie Zweifel haben vor einer Änderung, dann vergewissern Sie sich, dass Sie folgendes getan haben: cd /usr/ports; make index. Dieser Prozess kann auf alten Maschinen sehr langsam sein, aber Sie ersparen sich und einer Vielzahl von Menschen möglicherweise eine Menge Ärger.
<makevar>MASTERDIR</makevar> Falls Ihr Port wegen einer Variable, die verschiedene Werte annimmt (z.B. Auflösung oder Papiergröße), leicht unterschiedliche Versione von Paketen erzeugen muss, dann legen Sie bitte ein Unterverzeichnis pro Paket an, um es für den Nutzer einfacher begreiflich zu machen, was zu machen ist. Aber versuchen Sie dabei so viele Dateien wie möglich zwischen diesen Ports gemeinsam zu nutzen. Normalerweise benötigen Sie nur ein sehr kurzes Makefile in allen ausser einem Unterverzeichnis, wenn Sie Variablen intelligent nutzen. In diesem einzigen Makefile können Sie MASTERDIR verwenden, um anzugeben, wo der Rest der Dateien liegt. Benutzen Sie bitte auch eine Variable für PKGNAMESUFFIX, damit die Pakete unterschiedliche Namen haben werden. Wir demonstrieren dies am Besten an einem Beispiel. Es ist Teil von japanese/xdvi300/Makefile; PORTNAME= xdvi PORTVERSION= 17 PKGNAMEPREFIX= ja- PKGNAMESUFFIX= ${RESOLUTION} : # default RESOLUTION?= 300 .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ ${RESOLUTION} != 300 && ${RESOLUTION} != 400 @${ECHO_MSG} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" @${ECHO_MSG} "Possible values are: 118, 240, 300 (default) and 400." @${FALSE} .endif japanese/xdvi300 verfügt ebenfalls über alle Patches, Paket-Dateien usw. Wenn Sie make eintippen, wird der Port die Standardvorgabe für die Auflösung nehmen (300) und den Port ganz normal erstellen. Genauso wie für alle anderen Auflösungen ist dies das vollständige xdvi118/Makefile: RESOLUTION= 118 MASTERDIR= ${.CURDIR}/../xdvi300 .include "${MASTERDIR}/Makefile" (xdvi240/Makefile und xdvi400/Makefile sind ähnlich). Die MASTERDIR-Definition teilt dem bsd.port.mk mit, dass die normalen Unterverzeichnisse wie FILESDIR und SCRIPTDIR unter xdvi300 gefunden werden können. Die RESOLUTION=118-Zeile wird die RESOLUTION=300-Zeile in xdvi300/Makefile überschreiben und der Port wird mit einer Auflösung von 118 erstellt. Manualpages Die Variablen MAN[1-9LN] werden automatisch jede Manualpage zur pkg-plist hinzufügen (dies bedeutet, dass Sie Manualpages nicht in der pkg-plist auflisten dürfen, lesen Sie bitte Erstellung der PLIST für weitere Details). Sie veranlassen zudem den Installationsabschnitt dazu, die Manualpages zu Komprimieren oder zu Dekomprimieren abhängig vom gesetzten Wert der Variable - NOMANCOMPRESS in + NO_MANCOMPRESS in /etc/make.conf. Falls Ihr Port versucht verschiedene Namen für Manualpages unter Zuhilfenahme von Symlinks oder Hardlinks zu installieren, müssen Sie die Variable MLINKS nutzen, um diese zu identifizieren. Der von Ihrem Port installierte Link wird von bsd.port.mk gelöscht und wieder eingefügt, um sicherzustellen, dass er auf die korrekte Datei zeigt. Jede Manualpage, welche in MLINKS aufgeführt ist, darf nicht in der pkg-plist aufgenommen werden. Falls die Manualpages während der Installation komprimiert werden sollen, müssen Sie die Variable MANCOMPRESSED setzen. Diese Variable kann drei Werte annehmen, yes, no und maybe. yes bedeutet, dass Manualpages bereits komprimiert installiert sind, bei no sind sie es nicht und maybe bedeutet, dass die - Software bereits den Wert von NOMANCOMPRESS + Software bereits den Wert von NO_MANCOMPRESS beachtet, damit bsd.port.mk nichts Besonderes auszuführen hat. MANCOMPRESSED wird automatisch auf yes gesetzt, wenn USE_IMAKE vorgegeben ist und gleichzeitig NO_INSTALL_MANPAGES nicht. Im umgekehrten Falle ist MANCOMPRESSED auf no gesetzt. Sie müssen es nicht explizit angeben, außer die Standardvorgabe ist für Ihren Port nicht passend. Wenn Ihr Port den man tree irgendwo anders als in der Variable MANPREFIX verankert, können Sie ihn mit MANPREFIX bestimmen. Sollten zudem Manualpages nur in bestimmten Abschnitten an einem nicht-standardkonformen Platz liegen, wie z.B. bestimmte Perl-Modul-Ports, dann können Sie mittels der Variable MANsectPREFIX (wobei sect ein Wert aus 1-9, L oder N ist) individuelle Pfade zu den Manualpages festlegen. Wenn Ihre Manualpages in sprachspezifische Unterverzeichnisse installiert werden, dann bestimmen Sie bitte den Namen der Sprache mit der Variable MANLANG. Der Wert dieser Variable ist mit "" vorgegeben (das bedeutet nur Englisch). Hier ist ein Beispiel, welches alles zusammenfasst. MAN1= foo.1 MAN3= bar.3 MAN4= baz.4 MLINKS= foo.1 alt-name.8 MANLANG= "" ja MAN3PREFIX= ${PREFIX}/share/foobar MANCOMPRESSED= yes Dies zeigt an, dass sechs Dateien von diesem Port installiert werden; ${MANPREFIX}/man/man1/foo.1.gz ${MANPREFIX}/man/ja/man1/foo.1.gz ${PREFIX}/share/foobar/man/man3/bar.3.gz ${PREFIX}/share/foobar/man/ja/man3/bar.3.gz ${MANPREFIX}/man/man4/baz.4.gz ${MANPREFIX}/man/ja/man4/baz.4.gz ${MANPREFIX}/man/man8/alt-name.8.gz kann zusätzlich von Ihrem Port installiert werden, oder auch nicht. Unabhängig davon wird ein Symlink erstellt, welcher die Manualpages foo(1) und alt-name(8) einbindet. Falls nur manche Manualpages übersetzt sind, können Sie einige dynamisch vom MANLANG-Inhalt erzeugte Variablen nutzen: MANLANG= "" de ja MAN1= foo.1 MAN1_EN= bar.1 MAN3_DE= baz.3 Dies führt zu folgender Liste von Dateien: ${MANPREFIX}/man/man1/foo.1.gz ${MANPREFIX}/man/de/man1/foo.1.gz ${MANPREFIX}/man/ja/man1/foo.1.gz ${MANPREFIX}/man/man1/bar.1.gz ${MANPREFIX}/man/de/man3/baz.3.gz Info-Dateien Falls Ihr Paket GNU-Info-Dateien installiert, sollten diese in der INFO-Variablen augelistet sein (ohne das angehängte .info) mit einem Eintrag für jedes Dokument. Von diesen Dateien wird angenommen, dass sie nach PREFIX/INFO_PATH installiert werden. Sie können INFO_PATH ändern, falls Ihr Paket einen anderen Ort vorsieht. Jedoch wird dies nicht empfohlen. Die Einträge enthalten nur den relativen Pfad zu PREFIX/INFO_PATH. Zum Beispiel installiert lang/gcc33 Info-Dateien nach - PREFIX/INFO_PATH/gcc33, + role="package">lang/gcc34 Info-Dateien nach + PREFIX/INFO_PATH/gcc34, wobei INFO etwa so aussieht: - INFO= gcc33/cpp gcc33/cppinternals gcc33/g77 ... + INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ... Entsprechende Installations-/Deinstalltions-Codes werden vor der Paket-Registrierung automatisch der vorläufigen pkg-plist hinzugefügt. Makefile-Optionen Einige größere Applikationen können mit einer Reihe von Konfigurationen, die zusätzliche Funktionalitäten hinzufügen, erstellt werden, falls eine oder mehrere Bibliotheken oder Applikationen verfügbar sind. Dazu gehören die Auswahl von natürlichen Sprachen, GUI versus Kommandozeilen-Versionen oder die Auswahl aus mehreren Datenbank-Programmen. Da nicht alle Nutzer diese Bibliotheken oder Applikationen wollen, stellt das Ports-System hooks (Haken) zur Verfügung, damit der Autor des Ports bestimmen kann, welche Konfiguration erstellt werden soll. KNOBS (Einstellungen) <makevar>WITH_<replaceable>*</replaceable></makevar> und <makevar>WITHOUT_<replaceable>*</replaceable></makevar> Diese Variablen sind entworfen worden, um vom System-Administrator gesetzt zu werden. Es gibt viele, die in ports/KNOBS standardisiert sind. Benennen Sie Schalter bei der Erstellung eines Ports nicht programmspezifisch. Verwenden Sie zum Beispiel im Avahi-Port WITHOUT_MDNS anstelle von WITHOUT_AVAHI_MDNS. Sie sollten nicht annehmen, dass ein WITH_* notwendigerweise eine korrespondierende WITHOUT_*-Variable hat oder umgekehrt. Im Allgemeinen wird diese Vorgabe einfach unterstellt. Falls nicht anderweitig festgelegt, werden diese Variablen nur dahingehend überprüft, ob sie gesetzt sind oder nicht – nicht darauf, ob sie auf bestimmte Werte wie YES oder NO gesetzt sind. Häufige <makevar>WITH_<replaceable>*</replaceable></makevar> und <makevar> WITHOUT_<replaceable>*</replaceable></makevar>-Variablen Variable Bedeutung WITHOUT_NLS Falls gesetzt, bedeutet sie, dass eine Internationalisierung nicht benötigt wird, was Kompilierzeit sparen kann. Als Vorgabe wird Internationalisierung gebraucht. WITH_OPENSSL_BASE Nutze die Version von OpenSSL aus dem Basissystem. WITH_OPENSSL_PORT Installiert die Version von OpenSSL aus security/openssl, auch wenn das Basissystem auf aktuellem Stand ist. WITHOUT_X11 Falls der Port mit oder ohne Unterstützung für X erstellt werden kann, dann sollte normalerweise mit X-Unterstützung erstellt werden. Falls die Variable gesetzt ist, soll die Version ohne X-Unterstützung erstellt werden.
Benennung von Knobs (Einstellungen) Um die Anzahl der Knobs niedrig zu halten und zum Vorteil des Anwenders, wird empfohlen, dass Porter ähnliche Namen für Knobs verwenden. Eine Liste der beliebtesten Knobs kann in der KNOBS-Datei eingesehen werden. Knob-Namen sollten wiederspiegeln, was der Knob bedeutet und was er bewirkt. Wenn ein Port einen lib-Präfix im PORTNAME hat, dann soll das lib-Präfix im Knob-Namen entfallen.
<makevar>OPTIONS</makevar> Hintergrund Die OPTIONS-Variable gibt dem Nutzer, der diesen Port installiert, einen Dialog mit auswählbaren Optionen und speichert diese in /var/db/ports/portname/options. Bei der nächsten Neuerstellung des Ports werden diese Einstellungen wieder verwandt. Sie werden sich niemals mehr an all die zwanzig WITH_* und WITHOUT_*-Optionen erinnern müssen, die Sie benutzt haben, um diesen Port zu erstellen! Wenn der Anwender make config benutzt (oder ein make build das erste Mal laufen lässt) wird das Framework auf /var/db/ports/portname/options die Einstellungen prüfen. Falls die Datei nicht existiert, werden die Werte von OPTIONS genutzt, um eine Dialogbox zu erzeugen, in welcher die Optionen an- oder abgeschaltet werden können. Dann wird die options-Datei gespeichert und die ausgewählten Variablen werden bei der Erstellung des Ports benutzt. Falls eine neue Version des Ports OPTIONS hinzufügt, wird der Dialog mit den gespeicherten Werten dem Nutzer angezeigt. Benutzen Sie make showconfig, um die gespeicherte Konfiguration zu betrachten. Benutzen Sie make rmconfig, um die gespeicherte Konfiguration zu Löschen. Syntax Die Syntax für die OPTIONS-Variable lautet: OPTIONS= OPTION "descriptive text" default ... Der Wert als Vorgabe ist entweder ON oder OFF. Wiederholungen dieser drei Felder sind erlaubt. OPTIONS-Definitionen müssen vor der Einbindung von bsd.port.options.mk erscheinen. Die WITH_* und WITHOUT_*-Variablen können nur nach der Einbindung von bsd.port.options.mk getestet werden. bsd.port.pre.mk kann auch stattdessen eingebunden werden und wird immer noch von vielen Ports eingebunden, die vor der Einführung von bsd.port.options.mk erstellt wurden. Jedoch wirken manche Variablen nicht wie gewohnt nach der Einbindung von bsd.port.pre.mk, typischerweise USE_*-Optionen. Einfache Anwendung von <makevar>OPTIONS</makevar> OPTIONS= FOO "Enable option foo" On \ BAR "Support feature bar" Off .include <bsd.port.options.mk> .if defined(WITHOUT_FOO) CONFIGURE_ARGS+= --without-foo .else CONFIGURE_ARGS+= --with-foo .endif .if defined(WITH_BAR) RUN_DEPENDS+= bar:${PORTSDIR}/bar/bar .endif .include <bsd.port.mk> Veraltete Anwendung von <makevar>OPTIONS</makevar> OPTIONS= FOO "Enable option foo" On .include <bsd.port.pre.mk> .if defined(WITHOUT_FOO) CONFIGURE_ARGS+= --without-foo .else CONFIGURE_ARGS+= --with-foo .endif .include <bsd.port.post.mk> Automatische Aktivierung von Funktionen Wenn Sie ein GNU-Konfigurationsskript benutzen, sollten Sie ein Auge darauf werfen, welche Funktionen durch die automatische Erkennung aktiviert werden. Schalten Sie Funktionen, die Sie nicht möchten, ausdrücklich durch Verwendung von --without-xxx oder --disable-xxx in der Variable CONFIGURE_ARGS einzeln ab. Falsche Behandlung einer Option .if defined(WITH_FOO) LIB_DEPENDS+= foo.0:${PORTSDIR}/devel/foo CONFIGURE_ARGS+= --enable-foo .endif Stellen Sie sich vor im obigen Beispiel ist eine Bibliothek libfoo auf dem System installiert. Der Nutzer will nicht, dass diese Applikation libfoo benutzt, also hat er die Option auf "off" im make config-Dialog umgestellt. Aber das Konfigurationsskript der Applikation hat erkannt, dass die Bibliothek auf dem System vorhanden ist und fügt ihre Funktionen in die Binärdatei ein. Falls der Nutzer sich nun entschliesst libfoo von seinem System zu entfernen, dann wird das Ports-System nicht protestieren (es wurde keine Abhängigkeit von libfoo eingetragen), aber die Applikation bricht ab. Korrekte Behandlung einer Option .if defined(WITH_FOO) LIB_DEPENDS+= foo.0:${PORTSDIR}/devel/foo CONFIGURE_ARGS+= --enable-foo .else CONFIGURE_ARGS+= --disable-foo .endif Im zweiten Beispiel wird die Bibliothek libfoo explizit abgeschaltet. Das Konfigurationsskript aktiviert die entsprechenden Funktionen nicht in der Applikation trotz der Anwesenheit der Bibliothek auf dem System.
Die Festlegung des Arbeitsverzeichnisses Jeder Port wird extrahiert in ein Arbeitsverzeichnis, welches beschreibbar sein muss. Das Ports-System gibt als Standard vor, dass die DISTFILES in einem Verzeichnis namens ${DISTNAME} entpackt werden. Mit anderen Worten, wenn Sie: PORTNAME= foo PORTVERSION= 1.0 festgelegt haben, dann enthalten die Distributions-Dateien des Ports ein Verzeichnis auf oberster Ebene, foo-1.0, und der Rest der Dateien befindet sich unter diesem Verzeichnis. Es gibt eine Reihe von Variablen, die Sie überschreiben können, falls dies nicht der Fall sein sollte. <makevar>WRKSRC</makevar> Diese Variable listet den Namen des Verzeichnisses, welches erstellt wird, wenn die Distfiles der Applikation extrahiert werden. Wenn unser vorheriges Beispiel in einem Verzeichnis namens foo (und nicht foo-1.0) extrahiert wurde, würden Sie schreiben: WRKSRC= ${WRKDIR}/foo oder möglicherweise WRKSRC= ${WRKDIR}/${PORTNAME} <makevar>NO_WRKSUBDIR</makevar> Wenn der Port überhaupt nicht in einem Unterverzeichnis extrahiert wird, sollten Sie dies mit dem Setzen von NO_WRKSUBDIR anzeigen. NO_WRKSUBDIR= yes <makevar>CONFLICTS</makevar> Falls Ihr Paket nicht mit anderen Paketen koexistieren kann (wegen Dateikonflikten, Laufzeit-Inkompatibilitäten usw.), führen Sie bitte die anderen Paketnamen in der Variable CONFLICTS auf. Sie können hier Shell-Globs wie * und ? verwenden. Paketnamen sollten in der gleichen Weise aufgezählt werden, wie sie in /var/db/pkg auftauchen. Bitte stellen Sie sicher, dass CONFLICTS nicht mit dem Paket des Ports selbst übereinstimmt, da ansonsten das Erzwingen der Installation durch FORCE_PKG_REGISTER nicht länger funktionieren wird. CONFLICTS setzt automatisch die Variable IGNORE, welche ausführlicher in dokumentiert ist. Beim Entfernen eines von mehreren in Konflikt stehenden Ports ist es ratsam, die CONFLICTS-Einträge in den anderen Ports für einige Monate beizubehalten, um Nutzer zu unterstützen, die ihre Ports nur sporadisch aktualisieren. Installation von Dateien INSTALL_* macros Nutzen Sie die Makros in bsd.port.mk, um korrekte Modi und Eigentümer von Dateien in Ihren *-install-Targets sicherzustellen. INSTALL_PROGRAM ist ein Befehl, um binäre Binärdateien zu installieren. INSTALL_SCRIPT ist ein Befehl, um ausführbare Skripte zu installieren. INSTALL_KLD ist ein Befehl, mit dem Kernelmodule installiert werden können. Einige Architekturen haben Probleme mit stripped-Modulen. Daher sollten Sie diesen Befehl anstelle von INSTALL_PROGRAM verwenden. INSTALL_DATA ist ein Befehl, um gemeinsam nutzbare Daten zu installieren. INSTALL_MAN ist ein Befehl, um Manualpages oder andere Dokumentation zu installieren (es wird nichts komprimiert). Das sind grundsätzlich alle install-Befehle mit ihren passenden Flags. Zerlegen von Binärdateien Zerlegen Sie keine Binärdateien manuell, wenn Sie es nicht müssen. Alle Binaries sollten gestripped werden; allerdings vermag das INSTALL_PROGRAM-Makro gleichzeitig eine Binärdatei zu installieren und zu strippen (beachten Sie den nächsten Abschnitt). Wenn Sie eine Datei strippen müssen, aber nicht das INSTALL_PROGRAM-Makro nutzen wollen, dann kann ${STRIP_CMD} Ihr Programm strippen. Dies wird typischerweise innerhalb des post-install-Targets gemacht. Zum Beispiel: post-install: ${STRIP_CMD} ${PREFIX}/bin/xdl Nutzen Sie &man.file.1; für die installierte Applikation, um zu überprüfen, ob eine Binärdatei gestripped ist oder nicht. Wenn es nicht meldet not stripped, dann ist es bereits gestripped. Zudem wird &man.strip.1; nicht ein bereits gestripptes Programm nochmals versuchen zu strippen, sondern wird stattdessen einfach sauber beenden. Installation eines ganzen Verzeichnisbaums inklusive Dateien Manchmal muss man eine große Zahl von Dateien unter Erhalt ihrer hierarchischen Struktur installieren, d.h. Kopieraktionen über einen ganzen Verzeichnisbaum von WRKSRC zu einem Zielverzeichnis unter PREFIX. Für diesen Fall gibt es zwei Makros. Der Vorteil der Nutzung dieser Makros anstatt cp ist, dass sie korrekte Besitzer und Berechtigungen auf den Zieldateien garantieren. Das erste Makro, COPYTREE_BIN, wird alle installierten Dateien ausführbar markieren und damit passend für die Installation in PREFIX/bin vorbereiten. Das zweite Makro, COPYTREE_SHARE, setzt keine Ausführungsberechtigungen auf Dateien und ist daher geeignet für die Installation von Dateien im Target von PREFIX/share. post-install: ${MKDIR} ${EXAMPLESDIR} (cd ${WRKSRC}/examples/ && ${COPYTREE_SHARE} \* ${EXAMPLESDIR}) Dieses Beispiel wird den Inhalt des examples-Verzeichnisses im Distfile des Drittanbieters in das Beispielverzeichnis Ihres Ports kopieren. post-install: ${MKDIR} ${DATADIR}/summer (cd ${WRKSRC}/temperatures/ && ${COPYTREE_SHARE} "June July August" ${DATADIR}/summer/) Und dieses Beispiel wird die Daten der Sommermonate in das summer-Unterverzeichnis eines DATADIR installieren. Zusätzliche find-Argumente können mit dem dritten Argument an die COPYTREE_*-Makros übergeben werden. Um zum Beispiel alle Dateien aus dem 1. Beispiel ohne die Makefiles zu installieren, kann man folgenden Befehl benutzen. post-install: ${MKDIR} ${EXAMPLESDIR} (cd ${WRKSRC}/examples/ && \ ${COPYTREE_SHARE} \* ${EXAMPLESDIR} "! -name Makefile") Beachten Sie bitte, dass diese Makros die installierten Dateien nicht zur pkg-plist hinzufügen, Sie müssen sie immer noch selbst auflisten. Installation zusätzlicher Dokumentation Falls Ihre Software zusätzlich zu den üblichen Manualpages und Info-Seiten weitere Dokumentation hat und Sie diese für nützlich halten, dann installieren Sie sie unter PREFIX/share/doc. Dies kann wie vorstehend im Target des post-install geschehen. Legen Sie ein neues Verzeichnis für Ihren Port an. Das Verzeichnis sollte wiederspiegeln, was der Port ist. Das bedeutet normalerweise PORTNAME. Wie auch immer, wenn Sie meinen, der Nutzer möchte verschiedene Versionen des Ports zur gleichen Zeit installiert haben, dann können Sie die gesamte Variable PKGNAME nutzen. Machen Sie die Installation von der Variablen NOPORTDOCS abhängig, damit die Nutzer sie in /etc/make.conf abschalten können: post-install: .if !defined(NOPORTDOCS) ${MKDIR} ${DOCSDIR} ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR} .endif Hier einige praktische Variablen und wie sie standardmässig bei Verwendung im Makefile expandiert werden: DATADIR wird expandiert zu PREFIX/share/PORTNAME. DATADIR_REL wird expandiert zu share/PORTNAME. DOCSDIR wird expandiert zu PREFIX/share/doc/PORTNAME. DOCSDIR_REL wird expandiert zu share/doc/PORTNAME. EXAMPLESDIR wird expandiert zu PREFIX/share/examples/PORTNAME. EXAMPLESDIR_REL wird expandiert zu share/examples/PORTNAME. NOPORTDOCS behandelt nur zusätzliche Dokumentation, die in DOCSDIR installiert ist. Für normale Manualpages und Info-Seiten wird die Variable benutzt. Dinge, welche in DATADIR und EXAMPLESDIR installiert werden, legen die Variablen NOPORTDATA und NOPORTEXAMPLES fest. Die Variablen werden nach PLIST_SUB exportiert. Ihre Werte erscheinen dort als Pfadnamen relativ zu PREFIX, falls möglich. Das bedeutet, dass share/doc/PORTNAME standardmässig ersetzt wird durch %%DOCSDIR%% in der Packliste usw. (mehr zur Ersetzung durch die pkg-plist finden Sie hier). Alle installierten Dokumentationsdateien und –Verzeichnisse sollten in der pkg-plist dem %%PORTDOCS%%-Präfix enthalten sein, zum Beispiel: %%PORTDOCS%%%%DOCSDIR%%/AUTHORS %%PORTDOCS%%%%DOCSDIR%%/CONTACT %%PORTDOCS%%@dirrm %%DOCSDIR%% Alternativ zur Auflistung der Dokumentationsdateien in der pkg-plist kann in einem Port auch die Variable PORTDOCS gesetzt werden für eine Liste von Dateien und Shell-Globs, um diese zur endgültigen Packliste hinzuzufügen. Die Namen werden relativ zur Variable DOCSDIR sein. Wenn Sie also einen Port haben, welcher PORTDOCS benutzt, und Sie haben eine vom Standard abweichenden Platz für seine Dokumentation, dann müssen Sie die Variable DOCSDIR entsprechend setzen. Wenn ein Verzeichnis in PORTDOCS aufgeführt ist, oder von einem Shell-Glob dieser Variable abgebildet wird, dann wird der komplette Verzeichnisbaum inklusive Dateien und Verzeichnissen in der endgültigen Packliste aufgenommen. Wenn die Variable NOPORTDOCS gesetzt ist, dann werden die Dateien und Verzeichnisse, die in PORTDOCS aufgelistet sind, nicht installiert und werden auch nicht zur Packliste des Ports hinzugefügt. Wie oben gezeigt bleibt es dem Port selbst überlassen, die Dokumentation in PORTDOCS zu installieren. Ein typisches Beispiel für den Gebrauch von PORTDOCS sieht wie folgt aus: PORTDOCS= README.* ChangeLog docs/* Die Äquivalente zu PORTDOCS für unter DATADIR und EXAMPLESDIR installierte Dateien sind PORTDATA beziehungsweise PORTEXAMPLES. Sie können auch pkg-message benutzen, um Meldungen während der Installation anzuzeigen. Lesen Sie diesen Abschnitt über den Gebrauch von pkg-message für weitere Details. Die pkg-message-Datei muss nicht zur pkg-plist hinzugefügt werden. Unterverzeichnisse mit PREFIX Lassen Sie den Port die Dateien in die richtigen Unterverzeichnisse von PREFIX verteilen. Einige Ports werfen alles in einen Topf und legen es im Unterverzeichnis mit dem Namen des Ports ab, was falsch ist. Ausserdem legen viele Ports alles ausser Binaries, Header-Dateien und Manualpages in ein Unterverzeichnis von lib, was natürlich auch nicht der BSD-Philosophie entspricht und nicht gut funktioniert. Viele der Dateien sollten in eines der folgenden Verzeichnisse geschoben werden: etc (Konfigurationsdateien), libexec (intern gestartete Binärdateien), sbin (Binärdateien für Superuser/Manager), info (Dokumentation für Info-Browser) oder share (Architektur-unabhängige Dateien). Lesen Sie hierzu &man.hier.7;; weitestgehend greifen die Regeln für /usr auch für /usr/local. Die Ausnahme sind Ports, welche mit news aus dem USENET arbeiten. In diesem Falle sollte PREFIX/news als Zielort für die Dateien benutzt werden.
Besonderheiten Es gibt einige Dinge mehr, die zu beachten sind, wenn man einen Port erstellt. Dieser Abschnitt erklärt die wichtigsten. Shared-Libraries Wenn Ihr Port eine oder mehrere Shared-Libraries installiert, dann definieren Sie bitte eine USE_LDCONFIG make-Variable, die bsd.port.mk anweisen wird, ${LDCONFIG} -m auf das Verzeichnis, in das die neue Library installiert wird (normalerweise PREFIX/lib), während des post-install-Targets anzuwenden, um sie im Shared-Library-Cache zu registrieren. Diese Variable, wenn definiert, wird auch dafür sorgen, dass ein entsprechendes @exec /sbin/ldconfig -m und @unexec /sbin/ldconfig -R-Paar zu Ihrer pkg-plist-Datei hinzugefügt wird, sodass ein Benutzer, der das Paket installiert, die Bibliothek danach sofort benutzen kann und das System nach deren Deinstallation nicht glaubt, die Bibliothek wäre noch da. USE_LDCONFIG= yes Wenn nötig, können Sie das Standardverzeichnis außer Kraft setzen, indem Sie den USE_LDCONFIG Wert auf eine Liste von Verzeichnissen setzen, in die Shared Libraries installiert werden sollen. Wenn Ihr Port z.B. diese Bibliotheken nach PREFIX/lib/foo und PREFIX/lib/bar installiert, könnten Sie folgendes in Ihrem Makefile benutzen: USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar Bitte überprüfen Sie dies genau. Oft ist das überhaupt nicht nötig oder kann durch -rpath oder das Setzen von LD_RUN_PATH während des Linkens umgangen werden (s. lang/moscow_ml für ein Beispiel), oder durch einen Shell-Wrapper, der LD_LIBRARY_PATH setzt, bevor er die Binärdatei ausführt, wie es www/mozilla tut. Wenn Sie 32-Bit Libraries auf 64-Bit Systemen installieren, benutzen Sie stattdessen USE_LDCONFIG32. Versuchen Sie Shared-Library-Versionsnummern im libfoo.so.0 Format zu halten. Unser Runtime-Linker kümmert sich nur um die Major (erste) Nummer. Wenn sich die Major-Library-Versionsnummer während der Aktualisierung zu einer neuen Portversion erhöht, sollte auch die PORTREVISION aller Ports, die die Shared-Library linken, erhöht werden, damit diese mit der neuen Version der Bibliothek neu kompiliert werden. Ports mit beschränkter Verbreitung Lizenzen variieren und manche geben Restriktionen vor, wie die Applikation gepackt werden oder ob sie gewinnorientiert verkauft werden kann, usw. Es liegt in Ihrer Verantwortung als Porter die Lizenzbestimmungen der Software zu lesen und sicherzustellen, dass das FreeBSD-Projekt nicht haftbar gemacht wird für Lizenzverletzungen durch Weiterverbreitung des Quelltextes oder kompilierter Binaries über FTP/HTTP oder CD-ROM. Im Zweifelsfall kontaktieren Sie bitte die &a.ports;. In solchen Situationen können die in den folgenden Abschnitten beschriebenen Variablen gesetzt werden. <makevar>NO_PACKAGE</makevar> Diese Variable zeigt an, dass wir keine binären Pakete dieser Applikation erzeugen dürfen - z.B. wenn die Lizenz die Weiterverteilung von binären Paketen oder Paketen verbietet, die aus verändertem Quelltext erzeugt wurden. Die DISTFILES des Ports dürfen allerdings frei über FTP/HTTP Mirrors weiterverbreitet werden. Sie dürfen auch auf CD-ROM (oder ähnlichen Medien) weiterverbreitet werden - es sei denn, NO_CDROM ist ebenfalls gesetzt. NO_PACKAGE sollte auch benutzt werden, wenn das binäre Paket nicht allgemein brauchbar ist und die Applikation immer aus dem Quelltext kompiliert werden sollte. Zum Beispiel, wenn die Applikation konfigurierte Informationen über den Rechner/Installationsort bei der Installation einkompiliert bekommt, setzen Sie NO_PACKAGE. NO_PACKAGE sollte auf eine Zeichenkette gesetzt werden, die den Grund beschreibt, warum kein Paket erzeugt werden soll. <makevar>NO_CDROM</makevar> Diese Variable gibt an, dassobwohl wir binäre Pakete erzeugen dürfen – wir weder diese Pakete noch die DISTFILES des Ports auf einer CD-ROM (oder ähnlichen Medien) verkaufen dürfen. Die DISTFILES des Ports dürfen allerdings immer noch auf FTP/HTTP Mirrors. Wenn diese Variable und auch NO_PACKAGE gesetzt ist, dann werden nur die DISTFILES des Ports erhältlich sein – und das nur mittels FTP/HTTP. NO_CDROM sollte auf eine Zeichenkette gesetzt werden, die den Grund beschreibt, warum der Port nicht auf CD-ROM weiterverbreitet werden kann. Das sollte z.B. gemacht werden, wenn die Lizenz des Ports nur für nichtkommerzielle Zwecke gilt. <makevar>NOFETCHFILES</makevar> Dateien, die in der Variable NOFETCHFILES aufgelistet sind, sind von keiner der MASTER_SITES abrufbar. Ein Beispiel solch einer Datei ist eine selbige, welche vom Anbieter auf CD-ROM bereitgestellt wird. Werkzeuge, die das Vorhandensein dieser Dateien auf den MASTER_SITES überprüfen, sollten diese Dateien ignorieren und sie nicht melden. <makevar>RESTRICTED</makevar> Setzen Sie diese Variable, wenn die Lizenz der Applikation weder das Spiegeln der DISTFILES der Applikation noch das Weiterverbreiten von binären Paketen in jedweder Art erlaubt. NO_CDROM oder NO_PACKAGE sollten nicht zusammen mit RESTRICTED gesetzt werden, weil letztere Variable die anderen beiden impliziert. RESTRICTED sollte auf eine Zeichenkette gesetzt werden, die den Grund beschreibt, warum der Port nicht weiterverbreitet werden kann. Typischerweise besagt dies, dass der Port proprietäre Software enthält und der Benutzer die DISTFILES manuell herunterladen muss – möglicherweise erst nachdem er sich für die Software registriert oder die Bedingungen eines Endbenutzer-Lizenzvertrags (EULA) akzeptiert hat. <makevar>RESTRICTED_FILES</makevar> Wenn RESTRICTED oder NO_CDROM gesetzt ist, ist diese Variable auf ${DISTFILES} ${PATCHFILES} voreingestellt, sonst ist sie leer. Wenn nicht jede dieser Dateien beschränkt ist, dann führen Sie die betroffenen Dateien in dieser Variable auf. Beachten Sie, dass der Porter für jede aufgeführte Distributionsdatei einen Eintrag zu /usr/ports/LEGAL hinzufügen sollte, der genau beschreibt, was die Beschränkung mit sich bringt. Build-Mechanismen Paralleles Bauen von Ports Das Ports-Framework von &os; unterstützt das parallele Bauen von Ports, indem es mehrere make-Instanzen ausführt, damit SMP-Systeme ihre gesamte CPU-Rechenleistung ausnützen können und so das Bauen von Ports schneller und effektiver werden kann. Dies ermöglicht der Parameter -jX an &man.make.1;, wenn Code von Drittanbietern kompiliert wird. Leider können nicht alle Ports wirklich gut mit dem Parallelbau umgehen. Deshalb ist es erforderlich, dass dieses Feature explizit durch MAKE_JOBS_SAFE=yes irgendwo unterhalb des Abschnitts für Abhängigkeiten im Makefile aktiviert wird. Eine weitere Möglichkeit im Umgang mit dieser Option besteht für den Maintainer darin, MAKE_JOBS_UNSAFE=yes zu setzen. Diese Variable wird dann verwendet, wenn ein Port bekannterweise mit -jX nicht gebaut werden kann, der Benutzer jedoch für alle Ports den Mehrprozessorbau durch FORCE_MAKE_JOBS=yes in /etc/make.conf erzwingt. <command>make</command>, <command>gmake</command> und <command>imake</command> Wenn Ihr Port GNU make benutzt, dann setzen Sie bitte USE_GMAKE=yes. Port-Variablen im Zusammenhang mit gmake Variable Bedeutung USE_GMAKE Der Port benötigt gmake für den Build. GMAKE Der ganze Pfad zu gmake, wenn es nicht im PATH ist.
Wenn Ihr Port eine X-Applikation ist, die Makefile-Dateien aus Imakefile-Dateien mit imake erzeugt, dann setzen Sie USE_IMAKE=yes. Das sorgt dafür, dass die Konfigurationsphase automatisch ein xmkmf -a ausführt. Wenn das Flag ein Problem für Ihren Port darstellt, setzen Sie XMKMF=xmkmf. Wenn der Port imake benutzt, aber das install.man-Target nicht versteht, dann sollte NO_INSTALL_MANPAGES=yes gesetzt werden. Wenn das Makefile im Quelltext Ihres Ports etwas anderes als all als Haupt-Build-Target hat, setzen Sie ALL_TARGET entsprechend. Das Gleiche gilt für install und INSTALL_TARGET.
<command>configure</command> Skript Wenn Ihr Port ein configure-Skript benutzt, um Makefile-Dateien aus Makefile.in-Dateien zu erzeugen, setzen Sie GNU_CONFIGURE=yes. Wenn Sie dem configure-Skript zusätzliche Argumente übergeben wollen (das Vorgabeargument ist --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET}), setzen Sie diese zusätzlichen Argumente in CONFIGURE_ARGS. Zusätzliche Umgebungsvariablen können überdie Variable CONFIGURE_ENV übergeben werden. Variablen für Ports, die configure benutzen Variable Bedeutung GNU_CONFIGURE Der Port benutzt ein configure-Skript, um das Bauen vorzubereiten. HAS_CONFIGURE Wie GNU_CONFIGURE, nur dass kein Standard-Konfigurations-Target zu CONFIGURE_ARGS hinzugefügt wird. CONFIGURE_ARGS Zusätzliche Argumente für das configure-Skript. CONFIGURE_ENV Zusätzliche Umgebungsvariablen für die Abarbeitung des configure-Skriptes. CONFIGURE_TARGET Ersetzt das Standard-Konfigurations-Target. Vorgabewert ist ${MACHINE_ARCH}-portbld-freebsd${OSREL}.
Benutzung von <command>scons</command> Wenn Ihr Port SCons benutzt, definieren Sie USE_SCONS=yes. Variablen für Ports, die <command>scons</command> benutzen Variable Bedeutung SCONS_ARGS Port-spezifische SCons-Argumente, die der SCons-Umgebung übergeben werden. SCONS_BUILDENV Variablen, die in der System-Umgebung gesetzt werden sollen. SCONS_ENV Variablen, die in der SCons-Umgebung gesetzt werden sollen. SCONS_TARGET Letztes Argument, das SCons übergeben wird – ähnlich MAKE_TARGET.
Um SConstruct im Quelltext alles, was SCons in SCONS_ENV übergeben wird, respektieren zu lassen (das ist hauptsächlich CC/CXX/CFLAGS/CXXFLAGS), patchen Sie SConstruct, sodass das Build Environment wie folgt konstruiert wird: env = Environment(**ARGUMENTS) Es kann dann mit env.Append und env.Replace modifiziert werden.
Benutzung von GNU autotools Einführung Die verschiedenen GNU autotools stellen einen Abstraktionsmechanismus bereit für das Kompilieren von Software für eine Vielfalt von Betriebssystemen und Maschinenarchitekturen. Innerhalb der Ports-Sammlung kann ein einzelner Port diese Werkzeuge mit Hilfe eines einfachen Konstrukts benutzen: USE_AUTOTOOLS= tool:version[:operation] ... Als dies geschrieben wurde konnte tool eins von libtool, libltdl, autoconf, autoheader, automake oder aclocal sein. version gibt die einzelne Werkzeug-Revision an, die benutzt werden soll (siehe devel/{automake,autoconf,libtool}[0-9]+ für mögliche Versionen). operation ist eine optionale Angabe, die modifiziert, wie das Werkzeug benutzt wird. Es können auch mehrere Werkzeuge angegeben werden – entweder durch Angabe aller in einer einzigen Zeile oder durch Benutzung des += Makefile-Konstrukts. Schliesslich gibt es das spezielle Tool, genannt autotools, das der Einfachheit dient indem es von alle verfügbaren Versionen der Autotools abhängt, was sinnvoll für Cross-Development ist. Dies kann auch erreicht werden, indem man den Port devel/autotools installiert. <command>libtool</command> Shared-Libraries, die das GNU Build-System benutzen, verwenden normalerweise libtool, um die Kompilierung und Installation solcher Bibliotheken anzupassen. Die übliche Praxis ist, eine Kopie von libtool, die mit dem Quelltext geliefert wird, zu benutzen. Falls Sie ein externes libtool benötigen, können Sie die Version, die von der Ports-Sammlung bereitgestellt wird, benutzen: USE_AUTOTOOLS= libtool:version[:env] Ohne zusätzliche Angaben sagt libtool:version dem Build-System, dass es das Konfigurationsskript mit der auf dem System installierten Kopie von libtool patchen soll. Die Variable GNU_CONFIGURE ist impliziert. Außerdem werden einige make– und shell-Variablen zur weiteren Benutzung durch den Port gesetzt. Für Genaueres siehe bsd.autotools.mk. Mit der Angabe :env wird nur die Umgebung vorbereitet. Schließlich können optional LIBTOOLFLAGS und LIBTOOLFILES gesetzt werden, um die häufigsten Argumente und durch libtool gepatchten Dateien außer Kraft zu setzen. Die meisten Ports werden das aber nicht brauchen. Für Weiteres siehe bsd.autotools.mk. <command>libltdl</command> Einige Ports benutzen das libltdl-Bibliothekspaket, welches Teil der libtool-Suite ist. Der Gebrauch dieser Bibliothek macht nicht automatisch den Gebrauch von libtool selbst nötig, deshalb wird ein separates Konstrukt zur Verfügung gestellt. USE_AUTOTOOLS= libltdl:version Im Moment sorgt dies nur für eine LIB_DEPENDS-Abhängigkeit von dem entsprechenden libltdl-Port und wird zur Vereinfachung zur Verfügung gestellt, um Abhängigkeiten von den Autotools-Ports ausserhalb des USE_AUTOTOOLS-Systems zu eliminieren. Es gibt keine weiteren Angaben für dieses Werkzeug. <command>autoconf</command> und <command>autoheader</command> Manche Ports enthalten kein Konfigurationsskript, sondern eine autoconf-Vorlage in der configure.ac-Datei. Sie können die folgenden Zuweisungen benutzen, um autoconf das Konfigurationsskript erzeugen zu lassen, und auch autoheader Header-Vorlagen zur Benutzung durch das Konfigurationsskript erzeugen zu lassen. USE_AUTOTOOLS= autoconf:version[:env] und USE_AUTOTOOLS= autoheader:version welches auch die Benutzung von autoconf:version impliziert. Ähnlich wie bei libtool, bereitet die Angabe des optionalen :env nur die Umgebung für weitere Benutzung vor. Ohne dieses wird der Port auch gepatched und erneut konfiguriert. Die zusätzlichen optionalen Variablen AUTOCONF_ARGS und AUTOHEADER_ARGS können durch das Makefile des Ports ausser Kraft gesetzt werden, wenn erforderlich. Wie bei den libtool-Äquivalenten werden die meisten Ports dies aber nicht benötigen. <command>automake</command> und <command>aclocal</command> Manche Pakete enthalten nur Makefile.am-Dateien. Diese müssen durch automake in Makefile.in-Dateien konvertiert und dann durch configure weiterbearbeitet werden, um schließlich ein Makefile zu erzeugen. Ähnliches gilt für Pakete, die gelegentlich keine aclocal.m4-Dateien mitliefern, welche ebenfalls zum Erstellen der Software benötigt werden. Diese können durch aclocal erzeugt werden, welches configure.ac oder configure.in durchsucht. aclocal hat eine ähnliche Beziehung zu automake wie autoheader zu autoconf – beschrieben im vorherigen Abschnitt. aclocal impliziert die Benutzung von automake, also haben wir: USE_AUTOTOOLS= automake:version[:env] und USE_AUTOTOOLS= aclocal:version was auch die Benutzung von automake:version impliziert. Ähnlich wie bei libtool und autoconf, bereitet die optionale Angabe :env nur die Umgebung zur weiteren Benutzung vor. Ohne sie wird der Port erneut konfiguriert. Wie schon autoconf und autoheader, hat sowohl automake als auch aclocal eine optionale Argument-Variable AUTOMAKE_ARGS bzw. ACLOCAL_ARGS, die durch das Makefile des Ports, falls nötig, außer Kraft gesetzt werden kann. Benutzung von GNU <literal>gettext</literal> Grundlegende Benutzung Wenn Ihr Port gettext benötigt, setzen Sie einfach USE_GETTEXT auf yes, und Ihr Port bekommt die Abhängigkeit von devel/gettext. Der Wert von USE_GETTEXT kann auch die benötigte Version der libintl-Bibliothek angeben, der grundlegenden Teil von gettext – jedoch wird von der Benutzung dieser Funktion dringend abgeraten: Ihr Port sollte einfach nur mit der aktuellen Version von devel/gettext funktionieren. Ein ziemlich häufiger Fall ist, dass ein Port gettext und configure benutzt. Normalerweise sollte GNU configure gettext automatisch finden können. Sollte das einmal nicht funktionieren, können Hinweise über den Ort von gettext in CPPFLAGS und LDFLAGS wie folgt übergeben werden: USE_GETTEXT= yes CPPFLAGS+= -I${LOCALBASE}/include LDFLAGS+= -L${LOCALBASE}/lib GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS}" \ LDFLAGS="${LDFLAGS}" Natürlich kann der Code kompakter sein, wenn es keine weiteren Flags gibt, die configure übergeben werden müssen: USE_GETTEXT= yes GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \ LDFLAGS="-L${LOCALBASE}/lib" Optionale Benutzung Manche Softwareprodukte erlauben die Deaktivierung von NLS - z.B. durch Übergeben von an configure. In diesem Fall sollte Ihr Port gettext abhängig vom Status von WITHOUT_NLS benutzen. Für Ports mit niedriger bis mittlerer Komplexität können Sie sich auf das folgende Idiom verlassen: GNU_CONFIGURE= yes .if !defined(WITHOUT_NLS) USE_GETTEXT= yes PLIST_SUB+= NLS="" .else CONFIGURE_ARGS+= --disable-nls PLIST_SUB+= NLS="@comment " .endif Der nächste Punkt auf Ihrer Todo-Liste ist dafür zu sorgen, dass die Message-Catalog-Dateien nur bedingt in der Packliste aufgeführt werden. Der Makefile-Teil dieser Aufgabe ist schon durch obiges Idiom erledigt. Das wird im Abschnitt über Fortgeschrittene pkg-plist-Methoden erklärt. Kurz gesagt, jedes Vorkommen von %%NLS%% in pkg-plist wird durch @comment , wenn NLS abgeschaltet ist, oder durch eine leere Zeichenkette, wenn NLS aktiviert ist, ersetzt. Folglich werden die Zeilen, denen %%NLS%% vorangestellt ist, zu reinen Kommentaren in der endgültigen Packliste, wenn NLS abgeschaltet ist; andernfalls wird der Prefix einfach nur ausgelassen. Alles, was Sie jetzt noch machen müssen, ist %%NLS%% vor jedem Pfad zu einer Message-Catalog-Datei in pkg-plist einzufügen. Zum Beispiel: %%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo In sehr komplexen Fällen müssen Sie eventuell fortgeschrittenere Techniken als die hier vorgestellte benutzen - wie z.B. Dynamische Packlistenerzeugung. Behandlung von Message-Catalog-Verzeichnissen Bei der Installation von Message-Catalog-Dateien gibt es einen Punkt zu beachten. Ihr Zielverzeichnis, das unter LOCALBASE/share/locale liegt, sollte nur selten von Ihrem Port erzeugt und gelöscht werden. Die Verzeichnisse für die gebräuchlichsten Sprachen sind in /etc/mtree/BSD.local.dist aufgelistet; das heisst, sie sind Teil des Systems. Die Verzeichnisse für viele andere Sprachen sind Teil des Ports devel/gettext. Sie wollen vielleicht dessen pkg-plist zur Hand nehmen, um festzustellen, ob Ihr Port eine Message-Catalog-Datei für eine seltene Sprache installiert. Die Benutzung von <literal>perl</literal> Wenn MASTER_SITES auf MASTER_SITE_PERL_CPAN gesetzt ist, dann ist der bevorzugte Wert von MASTER_SITE_SUBDIR der Top-Level-Name der Hierarchie. Zum Beispiel ist der empfohlene Wert für p5-Module-Name-Module. Die Top-Level-Hierarchie kann unter cpan.org angeschaut werden. Dies sorgt dafür, dass der Port weiter funktioniert, wenn sich der Autor des Moduls ändert. Die Ausnahme dieser Regel ist, dass das entsprechende Verzeichnis selber oder das Distfile in diesem Verzeichnis nicht existiert. In solchen Fällen ist die Benutzung der Id des Autors als MASTER_SITE_SUBDIR erlaubt. Jede der Einstellungen unten kann sowohl auf YES als auch auf eine Versionszeichenkette wie 5.8.0+ gesetzt werden. Wenn YES benutzt wird, bedeutet das, dass der Port mit jeder der unterstützten Perl-Versionen funktioniert. Falls ein Port nur mit einer bestimmten Perl-Version funktioniert, kann darauf mit einer Versionszeichenkette hingewiesen werden, die entweder eine Mindest- (z.B. 5.7.3+), Maximal- (z.B. 5.8.0-) oder Absolutversion (z.B. 5.8.3) festlegt. Variablen für Ports, die <literal>perl</literal> benutzen Variable Bedeutung USE_PERL5 Bedeutet, dass der Port perl 5 zum Erstellen und zum Ausführen benutzt. USE_PERL5_BUILD Bedeutet, dass der Port perl 5 zum Erstellen benutzt. USE_PERL5_RUN Bedeutet, dass der Port perl 5 zur Laufzeit benutzt. PERL Der gesamte Pfad zu perl 5 – entweder im Basissystem oder nachinstalliert über einen Port – ohne die Versionsnummer. Benutzen Sie diese Variable, wenn Sie #!-Zeilen in Skripten ersetzen müssen. PERL_CONFIGURE Perls MakeMaker für die Konfiguration benutzen. Dies impliziert USE_PERL5. PERL_MODBUILD Module::Build für configure, build und install benutzen. Dies impliziert PERL_CONFIGURE. Nur lesbare Variablen PERL_VERSION Die volle Version des installierten perl (z.B. 5.8.9). PERL_LEVEL Die installierte perl-Version als ein Integer der Form MNNNPP (z.B. 500809). PERL_ARCH Wo perl architektur abhängige Bibliotheken ablegt. Vorgabe ist ${ARCH}-freebsd. PERL_PORT Name des perl-Ports, der installiert ist (z.B. perl5). SITE_PERL Verzeichnis, in das die Site-spezifischen perl-Pakete kommen. Dieser Wert wird zu PLIST_SUB hinzugefügt.
Ports von Perl-Modulen, die keine offizielle Webseite haben, sollen in der WWW-Zeile ihrer pkg-descr-Datei auf cpan.org verlinken. Die bevorzugte URL-Form ist http://search.cpan.org/dist/Module-Name/ (inklusive des Slash am Ende).
Benutzung von X11 X.Org-Komponenten Die X11-Implementierung, welche die Ports-Sammlung bereitstellt, ist X.Org. Wenn Ihre Applikation von X-Komponenten abhängt, listen Sie die benötigten Komponenten in USE_XORG auf. Als dies geschrieben wurde, wurden die folgenden Komponenten bereitgestellt: bigreqsproto compositeproto damageproto dmx dmxproto evieproto fixesproto fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto libfs oldx printproto randrproto recordproto renderproto resourceproto scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xaw8 xbitmaps xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext xextproto xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont xfontcache xft xi xinerama xineramaproto xkbfile xkbui xmu xmuu xorg-server xp xpm xprintapputil xprintutil xpr oto xproxymngproto xrandr xrender xres xscrnsaver xt xtrans xtrap xtst xv xvmc xxf86dga xxf86misc xxf86vm. Die aktuelle Liste finden Sie immer in /usr/ports/Mk/bsd.xorg.mk. Das Mesa Projekt ist ein Versuch, eine freie OpenGL Implementierung bereitzustellen. Sie können eine Abhängigkeit von verschiedenen Komponenten diese Projektes in der Variable USE_GL spezifizieren. ouml;gliche Optionen sind: glut, - glu, glw, gl und linux. + glu, glw, glew, gl und linux. Für Abwärtskompatibilität gilt der Wert yes als glu. Beispiel für USE_XORG USE_XORG= xrender xft xkbfile xt xaw USE_GL= glu Viele Ports definieren USE_XLIB, was dafür sorgt, dass der Port von allen (rund 50) Bibliotheken abhängt. Diese Variable existiert, um Abwärtskompatibilität sicherzustellen (sie stammt noch aus der Zeit vor dem modularem X.Org), und sollte bei neuen Ports nicht mehr benutzt werden. Variablen für Ports, die X benutzen USE_XLIB Der Port benutzt die X-Bibliotheken. Soll nicht mehr verwendet werden - benutzen Sie stattdessen eine Liste von Komponenten in USE_XORG. USE_X_PREFIX Soll nicht mehr benutzt werden, ist jetzt äquivalent zu USE_XLIB und kann einfach durch letzteres ersetzt werden. USE_IMAKE Der Port benutzt imake. Impliziert USE_X_PREFIX. XMKMF Ist auf den Pfad zu xmkmf gesetzt, wenn nicht in PATH. Vorgabe ist xmkmf -a.
Variablen bei Abhängigkeit von einzelnen Teilen von X11 X_IMAKE_PORT Ein Port, der imake und einige andere Werkzeuge, die zum Erstellen von X11 benutzt werden, bereitstellt. X_LIBRARIES_PORT Ein Port, der die X11-Bibliotheken bereitstellt. X_CLIENTS_PORT Ein Port, der X11-Clients bereitstellt. X_SERVER_PORT Ein Port, der den X11-Server bereitstellt. X_FONTSERVER_PORT Ein Port, der den Fontserver bereitstellt. X_PRINTSERVER_PORT Ein Port, der den Printserver bereitstellt. X_VFBSERVER_PORT Ein Port, der den virtuellen Framebuffer-Server bereitstellt. X_NESTSERVER_PORT Ein Port, der einen nested X-Server bereitstellt. X_FONTS_ENCODINGS_PORT Ein Port, der Kodierungen für Schriftarten bereitstellt. X_FONTS_MISC_PORT Ein Port, der verschiedene Bitmap-Schriftarten bereitstellt. X_FONTS_100DPI_PORT Ein Port, der 100dpi Bitmap-Schriftarten bereitstellt. X_FONTS_75DPI_PORT Ein Port, der 75dpi Bitmap-Schriftarten bereitstellt. X_FONTS_CYRILLIC_PORT Ein Port, der kyrillische Bitmap-Schriftarten bereitstellt. X_FONTS_TTF_PORT Ein Port, der &truetype;-Schriftarten bereitstellt. X_FONTS_TYPE1_PORT Ein Port, der Type1-Schriftarten bereitstellt. X_MANUALS_PORT Ein Port, der entwicklerorientierte Manualpages bereitstellt.
Benutzung von X11-bezogenen Variablen in einem Port # Port benutzt X11-Bibliotheken und hängt vom Font-Server sowie # von kyrillischen Schriftarten ab. RUN_DEPENDS= ${LOCALBASE}/bin/xfs:${X_FONTSERVER_PORT} \ ${LOCALBASE}/lib/X11/fonts/cyrillic/crox1c.pcf.gz:${X_FONTS_CYRILLIC_PORT} USE_XORG= x11 xpm
Ports, die Motif benötigen Wenn Ihr Port eine Motif-Bibliothek benötigt, definieren Sie USE_MOTIF im Makefile. Die Standard-Motif-Implementierung ist x11-toolkits/open-motif. Benutzer können stattdessen x11-toolkits/lesstif wählen, indem Sie die WANT_LESSTIF-Variable setzen. Die Variable MOTIFLIB wird von bsd.port.mk auf die entsprechende Motif-Bibliothek gesetzt. Bitte patchen Sie den Quelltext Ihres Ports, sodass er überall ${MOTIFLIB} benutzt, wo die Motif-Bibliothek im Original Makefile oder Imakefile referenziert wird. Es gibt zwei verbreitete Fälle: Wenn sich der Port in seinem Makefile oder Imakefile auf die Motif-Bibliothek als -lXm bezieht, ersetzen Sie das einfach durch ${MOTIFLIB}. Wenn der Port in seinem Imakefile XmClientLibs benutzt, ersetzen Sie das durch ${MOTIFLIB} ${XTOOLLIB} ${XLIB}. Anmerkung: MOTIFLIB expandiert (normalerweise) zu -L/usr/X11R6/lib -lXm oder /usr/X11R6/lib/libXm.a - d.h. Sie müssen kein -L oder -l davor einfügen. X11 Schriftarten Wenn Ihr Port Schriftarten für das X-Window-System installiert, legen Sie diese nach LOCALBASE/lib/X11/fonts/local. Erzeugen eines künstlichen <envar>DISPLAY</envar> durch Xvfb Manche Applikationen benötigen ein funktionierendes X11-Display, damit die Kompilierung funktioniert. Das stellt für Systeme, die ohne Display laufen, ein Problem dar. Wenn die folgende Variable benutzt wird, startet die Bauumgebung den virtuellen Framebuffer-X-Server, und ein funktionierendes DISPLAY wird dem Build übergeben. USE_DISPLAY= yes Desktop-Einträge Desktop-Einträge (Freedesktop Standard) können in Ihrem Port einfach über die DESKTOP_ENTRIES-Variable erzeugt werden. Diese Einträge erscheinen dann im Applikationsmenü von standardkonformen Desktop-Umgebungen wie GNOME oder KDE. Die .desktop-Datei wird dann automatisch erzeugt, installiert und der pkg-plist hinzugefügt. Die Syntax ist: DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify Die Liste der möglichen Kategorien ist auf der Freedesktop Webseite abrufbar. StartupNotify zeigt an, ob die Applikation den Status in Umgebungen, die Startup-Notifications kennen, löschen wird. Beispiel: DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \ "${DATADIR}/xtra/graf/tome-128.png" \ "tome -v -g" "Application;Game;RolePlaying" \ false
Benutzung von GNOME Das FreeBSD/GNOME-Projekt benutzt seine eigene Gruppe von Variablen, um zu definieren, welche GNOME-Komponenten ein bestimmter Port benutzt. Eine umfassende Liste dieser Variablen existiert innerhalb der Webseite des FreeBSD/GNOME-Projektes. - - Benutzung von KDE - - - Variablen-Definitionen - - - Variablen für Ports, die KDE benutzen - - - - - USE_KDELIBS_VER - Der Port benutzt KDE-Bibliotheken. Die Variable - spezifiziert die Major Version von KDE, die benutzt - werden soll, und impliziert - USE_QT_VER der entsprechenden - Version. Der einzig mögliche Wert ist - 3. - + + Benutzung von Qt - - USE_KDEBASE_VER - Der Port benutzt die KDE-Base. Die Variable - spezifiziert die Major Version von KDE, die benutzt - werden soll, und impliziert - USE_QT_VER der entsprechenden - Version. Der einzig mögliche Wert ist - 3. - - - -
-
- - + Ports, die Qt benötigen Variablen für Ports, die Qt benötigen USE_QT_VER Der Port benutzt das Qt-Toolkit. Mögliche Werte sind 3 und 4; diese spezifizieren die Major Version von Qt, die benutzt werden soll. Entsprechende Parameter werden an das configure-Skript und make übergeben. QT_PREFIX Enthält den Pfad, wohin Qt installiert ist (nur lesbare Variable). MOC Enthält den Pfad von moc (nur lesbare Variable). Voreingestellt entsprechend des USE_QT_VER-Werts. QTCPPFLAGS Zusätzliche Compiler-Flags, die über CONFIGURE_ENV an das Qt-Toolkit übergeben werden. Voreingestellt entsprechend des USE_QT_VER-Wertes. QTCFGLIBS Zusätzliche Bibliotheken, die über CONFIGURE_ENV für das Qt-Toolkit gelinkt werden sollen. Voreingestellt entsprechend des USE_QT_VER-Wertes. QTNONSTANDARD Änderungen von CONFIGURE_ENV, CONFIGURE_ARGS und MAKE_ENV sollen unterdrückt werden.
Zusätzliche Variablen für Ports, die Qt 4.xi benutzen QT_COMPONENTS Spezifiziert Tool– und Bibliothek-Abhängigkeiten für Qt4. Siehe unten für Details. UIC Enthält den Pfad von uic (nur lesbare Variable). Voreingestellt entsprechend des USE_QT_VER-Wertes. QMAKE Enthält den Pfad von qmake (nur lesbare Variable). Voreingestellt entsprechend des USE_QT_VER-Wertes. QMAKESPEC Enthält den Pfad der Konfigurationsdatei für qmake (nur lesbare Variable). Voreingestellt entsprechend des USE_QT_VER-Wertes.
Wenn USE_QT_VER gesetzt ist, werden dem configure-Skript einige nützliche Einstellungen übergeben: CONFIGURE_ARGS+= --with-qt-includes=${QT_PREFIX}/include \ --with-qt-libraries=${QT_PREFIX}/lib \ --with-extra-libs=${LOCALBASE}/lib \ --with-extra-includes=${LOCALBASE}/include CONFIGURE_ENV+= MOC="${MOC}" CPPFLAGS="${CPPFLAGS} ${QTCPPFLAGS}" LIBS="${QTCFGLIBS}" \ QTDIR="${QT_PREFIX}" KDEDIR="${KDE_PREFIX}" Wenn USE_QT_VER auf 4 gesetzt ist, werden auch die folgenden Einstellungen übergeben: CONFIGURE_ENV+= UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}" MAKE_ENV+= QMAKESPEC="${QMAKESPEC}"
Komponentenauswahl (nur bei Qt 4.x) Wenn USE_QT_VER auf 4 gesetzt ist, können individuelle Qt4-Tool- und Bibliotheksabhängigkeiten in der Variable QT_COMPONENTS angegeben werden. An jede Komponente kann _build oder _run als Suffix angehängt werden, was eine Abhängigkeit zur Build- bzw. Laufzeit angibt. Ohne Suffix gilt die Abhängigkeit sowohl zur Build- als auch zur Laufzeit. Bibliothekskomponenten sollten normalerweise ohne Suffix angegeben werden, Tool-Komponenten mit _build und Plugin-Komponenten mit _run. Die gebräuchlichsten Komponenten werden im Folgenden angegeben (alle verfügbaren Komponenten sind in _QT_COMPONENTS_ALL in /usr/ports/Mk/bsd.qt.mk aufgelistet): Verfügbare Qt4-Bibliothekskomponenten Name Beschreibung corelib Kern-Bibliothek (kann weggelassen werden– es sei denn, der Port benutzt nichts außer corelib) gui Graphische Benutzeroberflächen-Bibliothek network Netzwerk-Bibliothek opengl OpenGL-Bibliothek qt3support Qt3-Kompatibilitäts-Bibliothek qtestlib Modultest-Bibliothek script Skript-Bibliothek sql SQL-Bibliothek xml XML-Bibliothek
Sie können herausfinden, welche Bibliotheken die Applikation benötigt, indem Sie nach erfolgreicher Kompilierung ldd auf die Hauptbinärdatei anwenden. Verfügbare Qt4-Tool-Komponenten Name Beschreibung moc meta object compiler (wird zum Build fast jeder Qt-Applikation benötigt) qmake Makefile-Generator / Build-Werkzeug rcc Resource-Compiler (wird benötigt, falls die Applikation *.rc oder *.qrc Dateien enthält) uic User-Interface-Compiler (wird benötigt, falls die Applikation von Qt-Designer erzeugte *.ui Dateien enthält - gilt für praktisch jede Qt-Applikation mit einer GUI)
Verfügbare Qt4-Plugin-Komponenten Name Beschreibung iconengines SVG-Icon-Engine Plugin (wenn die Applikation SVG-Icons mitliefert) imageformats Bildformatplugins für GIF, JPEG, MNG und SVG (wenn die Applikation Bilddateien mitliefert)
Qt4-Komponenten auswählen In diesem Beispiel benutzt die portierte Applikation die Qt4 GUI-Bibliothek, die Qt4-Core-Bibliothek, alle Qt4-Codeerzeugungstools und Qt4's Makefile Generator. Da die GUI-Bibliothek eine Abhängigkeit von der Core-Bibliothek impliziert, muss corelib nicht angegeben werden. Die Qt4-Codeerzeugungstools moc, uic und rcc, sowie der Makefile Generator qmake werden nur für den Build benötigt, deshalb bekommen die den Suffix _build: USE_QT_VER= 4 QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build
Zusätzliche Besonderheiten Wenn die Applikation keine configure Datei, sondern eine .pro Datei hat, können Sie das Folgende benutzen: HAS_CONFIGURE= yes do-configure: @cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \ ${QMAKE} -unix PREFIX=${PREFIX} texmaker.pro Beachten Sie die Ähnlichkeit mit der qmake-Zeile im mitgelieferten BUILD.sh-Skript. Die Übergabe von CONFIGURE_ENV stellt sicher, dass qmake die QMAKESPEC-Variable übergeben bekommt, ohne die es nicht funktioniert. qmake erzeugt Standard-Makefiles, sodass es nicht nötig ist ein eigenes neues build-Target zu schreiben. Qt-Applikationen sind oft so geschrieben, dass sie plattformübergreifend sind, und oft ist X11/Unix nicht die Plattform, auf der sie entwickelt werden. Das sorgt oft für bestimmte fehlende Kleinigkeiten wie z.B.: Fehlende zusätzliche Include-Pfade. Viele Applikationen kommen mit System-Tray-Icon Support– unterlassen es aber Includes oder Bibliotheken in den X11 Verzeichnissen zu suchen. Sie können qmake über die Kommandozeile sagen, es soll Verzeichnisse zu den Include- und Bibliotheks-Suchpfaden hinzufügen - z.B.: ${QMAKE} -unix PREFIX=${PREFIX} INCLUDEPATH+=${LOCALBASE}/include \ LIBS+=-L${LOCALBASE}/lib sillyapp.pro Falsche Installations-Pfade. Manchmal werden Daten wie Icons oder .desktop-Dateien per Vorgabe in Verzeichnisse installiert, die nicht von XDG-kompatiblen Applikationen durchsucht werden. editors/texmaker ist hierfür ein Beispiel– siehe patch-texmaker.pro im files-Verzeichnis dieses Ports als eine Vorlage, die zeigt, wie man dies direkt in der Qmake Projektdatei löst.
+ + Benutzung von KDE + + + Variablen-Definitionen (KDE 3) + + + Variablen für Ports, die KDE 3 benutzen + + + + + USE_KDELIBS_VER + Der Port benutzt KDE-Bibliotheken. Die Variable + spezifiziert die Major Version von KDE, die benutzt + werden soll, und impliziert + USE_QT_VER der entsprechenden + Version. Der einzig mögliche Wert ist + 3. + + + + USE_KDEBASE_VER + Der Port benutzt die KDE-Base. Die Variable + spezifiziert die Major Version von KDE, die benutzt + werden soll, und impliziert + USE_QT_VER der entsprechenden + Version. Der einzig mögliche Wert ist + 3. + + + +
+
+ + + Variablen-Definitionen (KDE 4) + + Falls Ihre Anwendung von KDE 4 abhängt, weisen Sie + USE_KDE4 eine Liste mit benötigten + Komponenten zu. Die am häufigsten gebrauchten sind + unten aufgelistet (_USE_KDE4_ALL in + /usr/ports/Mk/bsd.kde4.mk enthält + stets die aktuelle Liste): + + + Verfügbare KDE 4-Komponenten + + + + + Name + Beschreibung + + + + + + akonadi + Personal Information Management + (PIM)-Speicherdienst + + + + automoc4 + Lässt den Port das Bauwerkzeug automoc4 + verwenden. + + + + kdebase + Grundlegende KDE-Anwendungen (Konqueror, + Dolphin, Konsole) + + + + kdeexp + Experimentelle KDE-Bibliotheken (mit einer API, + die als non-stable eingestuft ist) + + + + kdehier + Stellt allgemeine KDE-Verzeichnisse + bereit + + + + kdelibs + Die grundlegenden KDE-Bibliotheken + + + + kdeprefix + Falls in der Liste vorhanden, wird der Port + unter ${KDE4_PREFIX} statt + ${LOCALBASE} + installiert + + + + pimlibs + PIM-Bibliotheken + + + + workspace + Anwendungen und Bibliotheken, welche die + Desktopumgebung gestalten (Plasma, KWin) + + + +
+ + KDE 4-Ports werden unter + ${KDE4_PREFIX}, zur Zeit + /usr/local/kde4, installiert, um + Konflikte mit KDE 3-Ports zu verhindern. Dies wird durch + Auflisten der Komponente kdeprefix + erreicht, welche die standardmäßig gesetzte + Variable PREFIX überschreibt. Die + Ports übernehmen jedoch, jeden über die + Umgebungsvariable MAKEFLAGS oder + make-Parameter festgelegten Wert + für PREFIX. + + Es könnte bei der Installation von KDE 4-Ports zu + Konflikten mit KDE 3-Ports kommen, sodass diese bei + aktivierter kdeprefix-Komponente unter + ${KDE4_PREFIX} installiert werden. + Der Standardwert von KDE4_PREFIX ist zur + Zeit /usr/local/kde4. Es ist auch + möglich, KDE 4-Ports unter einem angepassten + PREFIX zu installieren. Wenn + PREFIX als + MAKEFLAGS-Umgebungsvariable oder als + make-Parameter gesetzt wird, + überschreibt dies den von kdeprefix + festgelegten Wert. + + + <makevar>USE_KDE4</makevar>-Beispiel + + Dies ist ein einfaches Beispiel für einen KDE + 4-Port. USE_CMAKE weist den Port an, + CMake, ein unter KDE + 4-Projekten weit verbreitetes Konfigurationswerkzeug, zu + verwenden. USE_KDE4 legt die + Abhängigkeit von KDE-Bibliotheken und die Verwendung + von automoc4 während der + Kompilierung fest. Mit Hilfe des configure-Protokolls + können die KDE-Komponenten und andere + Abhängigkeiten festgestellt werden. + USE_KDE4 impliziert + USE_QT_VER nicht. Falls der Port Qt + 4-Komponenten benötigt, sollten + USE_QT_VER gesetzt und verlangte + Komponenten festgelegt werden. + + USE_CMAKE= yes +USE_KDE4= automoc4 kdelibs kdeprefix +USE_QT_VER= 4 +QT_COMPONENTS= qmake_build moc_build rcc_build uic_build + +
+
+ Benutzung von Java Variablen-Definitionen - Wenn Ihr Port ein Java™ Development Kit (JDK) + Wenn Ihr Port ein Java™ Development Kit (JDK™) benötigt, entweder zum Bauen, zur Laufzeit oder sogar, um das Distfile auszupacken, dann sollten Sie USE_JAVA setzen. Es gibt mehrere JDKs in der Ports-Sammlung– von verschiedenen Anbietern und in verschiedenen Versionen. Wenn Ihr Port eine bestimmte dieser Versionen benötigt, können Sie definieren welche. Die aktuelle Version ist java/jdk15. + role="package">java/jdk16. Variablen, die von Ports, die Java benutzen, gesetzt werden müssen Variable Bedeutung USE_JAVA Sollte definiert sein, damit die übrigen Variablen irgendeinen Effekt haben. JAVA_VERSION Durch Leerzeichen getrennte Liste von geeigneten Java-Versionen für den Port. Ein optionales "+" ermöglicht die Angabe eines Bereiches von Versionen (mögliche Werte: 1.1[+] 1.2[+] 1.3[+] 1.4[+]). JAVA_OS Durch Leerzeichen getrennte Liste von geeigneten JDK-Port-Betriebssystemen für den Port. (erlaubte Werte: native linux). JAVA_VENDOR Durch Leerzeichen getrennte Liste von geeigneten JDK-Port-Anbietern für den Port. (erlaubte Werte: freebsd bsdjava sun ibm blackdown). JAVA_BUILD Bedeutet, falls gesetzt, dass der ausgewählte JDK-Port zu den Build-Abhängigkeiten des Ports hinzugefügt werden soll. JAVA_RUN Bedeutet, falls gesetzt, dass der ausgewählte JDK-Port zu den Laufzeit-Abhängigkeiten des Ports hinzugefügt werden soll. JAVA_EXTRACT Bedeutet, falls gesetzt, dass der ausgewählte JDK-Port zu den Extract-Abhängigkeiten des Ports hinzugefügt werden soll. USE_JIKES Legt fest, ob der Port den jikes Bytecode-Compiler zum Kompilieren benutzen soll. Wenn kein Wert für diese Variable gesetzt ist, wird der Port jikes für die Kompilierung benutzen– falls vorhanden. Sie können die Benutzung von jikes auch ausdrücklich verbieten oder erzwingen (durch Setzen auf 'no' oder 'yes'). Im letzteren Fall wird devel/jikes zu den Build-Abhängigkeiten des Ports hinzugefügt. In jedem Fall wird, wenn jikes tatsächlich statt javac zur Kompilierung benutzt wird, die Variable HAVE_JIKES von bsd.java.mk definiert.
Das Folgende ist eine Liste aller Variablen, die ein Port bekommt, nachdem er USE_JAVA gesetzt hat: Bereitgestellte Variablen für Ports, die Java benutzen Variable Wert JAVA_PORT Der Name des JDK-Ports (z.B. 'java/jdk14'). JAVA_PORT_VERSION Die volle Version des JDK Ports (z.B. '1.4.2'). Wenn Sie nur die ersten beiden Stellen dieser Versionsnummer benötigen, benutzen Sie ${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}. JAVA_PORT_OS Das vom JDK-Port benutzte Betriebssystem (z.B. 'linux'). JAVA_PORT_VENDOR Der Anbieter des JDK-Ports (z.B. 'sun'). JAVA_PORT_OS_DESCRIPTION Beschreibung des vom JDK-Port benutzten Betriebssystems (z.B. 'Linux'). JAVA_PORT_VENDOR_DESCRIPTION Beschreibung des Anbieters des JDK-Ports (z.B. 'FreeBSD Foundation'). JAVA_HOME Pfad zum Installationsverzeichnis des JDK (z.B. '/usr/local/jdk1.3.1'). JAVAC Pfad zum Java-Compiler, der benutzt werden soll (z.B. - '/usr/local/jdk1.1.8/bin/javac' oder + '/usr/local/jdk1.3.1/bin/javac' oder '/usr/local/bin/jikes'). JAR Pfad zum jar-Werkzeug, das benutzt werden soll (z.B. - '/usr/local/jdk1.2.2/bin/jar' oder + '/usr/local/jdk1.3.1/bin/jar' oder '/usr/local/bin/fastjar'). APPLETVIEWER Pfad zum appletviewer-Werkzeug (z.B. - '/usr/local/linux-jdk1.2.2/bin/appletviewer'). + '/usr/local/linux-jdk1.3.1/bin/appletviewer'). JAVA Pfad zur java Binärdatei. Benutzen Sie dies, um Java-Programme auszuführen (z.B. '/usr/local/jdk1.3.1/bin/java'). JAVADOC Pfad zum javadoc-Werkzeug. JAVAH Pfad zum javah-Programm. JAVAP Pfad zum javap-Programm. JAVA_KEYTOOL - Pfad zum keytool-Werkzeug. - Diese Variable ist nur verfügbar, wenn das JDK Java - 1.2 oder höher ist. + Pfad zum keytool-Werkzeug. JAVA_N2A Pfad zum native2ascii-Werkzeug. JAVA_POLICYTOOL - Pfad zum policytool Programm. - Diese Variable ist nur verfügbar, wenn das JDK - Java 1.2 oder höher ist. + Pfad zum policytool Programm. JAVA_SERIALVER Pfad zum serialver-Werkzeug. RMIC Pfad zum RMI Stub/Skeleton-Generator, rmic. RMIREGISTRY Pfad zum RMI Registry-Werkzeug, rmiregistry. RMID - Pfad zum RMI Daemon rmid. - Diese Variable ist nur verfügbar, wenn das JDK - Java 1.2 oder höher unterstützt. + Pfad zum RMI Daemon rmid. JAVA_CLASSES Pfad zum Archiv, das die JDK-Klassendateien - enthält. Für das JDK 1.2 oder später - ist dies - ${JAVA_HOME}/jre/lib/rt.jar. - Frühere JDKs benutzten - ${JAVA_HOME}/lib/classes.zip. + enthält, ${JAVA_HOME}/jre/lib/rt.jar. HAVE_JIKES Ist dann gesetzt, wenn jikes vom Port benutzt wird (s. USE_JIKES oben).
Sie können das java-debug make-Target benutzen, um Information zum Debuggen Ihres Ports zu erhalten. Es wird die Werte vieler der obenangegebenen Variablen anzeigen. Zusätzlich sind die folgenden Konstanten definiert, damit alle Java-Ports auf eine konsistente Art installiert werden können: Konstanten, die für Ports, welche Java benutzen, definiert sind Konstante Wert JAVASHAREDIR Das Basis-Verzeichnis für alles, was mit Java zusammenhängt. Standardmäßig ${PREFIX}/share/java. JAVAJARDIR Das Verzeichnis, wohin JAR-Dateien installiert werden sollen. Standardmäßig ${JAVASHAREDIR}/classes. JAVALIBDIR Das Verzeichnis, in dem JAR-Dateien, die von anderen Ports installiert wurden, liegen. Standardmäßig ${LOCALBASE}/share/java/classes.
Die entsprechenden Einträge sind sowohl in PLIST_SUB (dokumentiert in ) als auch in SUB_LIST definiert.
Kompilieren mit Ant Wenn der Port mit Apache Ant kompiliert werden soll, muss er USE_ANT setzen. Ant wird dann als das sub-make-Kommando betrachtet. Wenn kein do-build-Target vom Port definiert ist, wird eine Standardvorgabe benutzt, die einfach Ant entsprechend MAKE_ENV, MAKE_ARGS und - ALL_TARGETS aufruft. Das ähnelt dem + ALL_TARGET aufruft. Das ähnelt dem USE_GMAKE-Mechanismus, der in dokumentiert ist. Wenn jikes anstelle von javac benutzt wird (siehe USE_JIKES in ), dann wird Ant es automatisch benutzen, um den Port zu kompilieren. Optimales Verfahren Wenn Sie eine Java-Bibliothek portieren, sollte Ihr Port die JAR-Datei(en) in ${JAVAJARDIR} installieren, und alles andere unter ${JAVASHAREDIR}/${PORTNAME} (ausgenommen die Dokumentation - siehe unten). Um die Größe der Packlistendatei zu reduzieren, können die JAR-Datei(en) direkt im Makefile angegeben werden. Benutzen Sie einfach die folgende Anweisung (wobei myport.jar der Name der JAR-Datei ist, die als Teil des Ports installiert wird): PLIST_FILES+= %%JAVAJARDIR%%/myport.jar Beim Portieren einer Java-Applikation installiert der Port normalerweise alles unter einem einzigen Verzeichnis (inklusive seiner JAR-Abhängigkeiten). Die Benutzung von ${JAVASHAREDIR}/${PORTNAME} wird in dieser Beziehung dringend empfohlen. Es liegt im Entscheidungsbereich des Portierenden, ob der Port die zusätzlichen JAR-Abhängigkeiten unter diesem Verzeichnis installieren oder direkt die schon installierten (aus ${JAVAJARDIR}) benutzen soll. Unabhängig von der Art Ihres Ports (Bibliothek oder Applikation), sollte die zusätzliche Dokumentation an die gleiche Stelle installiert werden wie bei jedem anderen Port auch. Das JavaDoc-Werkzeug ist dafür bekannt einen unterschiedlichen Satz von Dateien abhängig von der Version des benutzten JDKs zu erstellen. Für Ports, die nicht die Benutzung eines bestimmten JDKs vorgeben, ist es deshalb eine komplexe Aufgabe die Packliste (pkg-plist) festzulegen. Dies ist ein Grund, warum dringend angeraten wird, das PORTDOCS-Makro zu benutzen. Außerdem, selbst wenn Sie den Satz von Dateien, den javadoc erzeugen wird, voraussagen können, die Größe der resultierenden pkg-plist befürwortet die Benutzung von PORTDOCS. Der Vorgabewert für DATADIR ist ${PREFIX}/share/${PORTNAME}. Es ist eine gute Idee, DATADIR für Java-Ports stattdessen auf ${JAVASHAREDIR}/${PORTNAME} zu setzen. In der Tat wird DATADIR automatisch zu PLIST_SUB (dokumentiert in ) hinzugefügt, d.h. Sie können %%DATADIR%% direkt in pkg-plist benutzen. Zu der Frage, ob Java-Ports aus dem Quelltext gebaut werden, oder direkt bereitgestellte binäre Distributionen benutzt werden sollten, gab es, als dies geschrieben wurde, keine definierte Richtlinie. Allerdings ermutigen Mitglieder des &os; Java-Projekts Porter dazu, Ihre Ports aus dem Quelltext kompilieren zu lassen, wann immer dies kein Problem darstellt. Alle Eigenschaften, die in diesem Abschnitt präsentiert wurden sind in bsd.java.mk implementiert. Sollten Sie jemals der Meinung sein, dass Ihr Port ausgefeiltere Java-Unterstützung benötigt, schauen Sie bitte erst in das bsd.java.mk CVS Log, weil es normalerweise immer etwas Zeit braucht bis die neuesten Eigenschaften dokumentiert sind. Wenn Sie glauben, dass der fehlende Support auch für viele andere Java Ports nützlich sein könnte, wenden Sie sich bitte an die &a.java;. Obwohl es eine java-Kategorie für Fehlerberichte gibt, bezieht sich diese auf die JDK-Portierungsbemühungen des &os; Java-Projektes. Deshalb sollten Sie Ihren Java-Port in der ports-Kategorie einreichen wie bei jeden anderen Port auch - es sei denn, die Angelegenheit, die Sie zu klären versuchen, steht in Zusammenhang entweder mit einer JDK-Implementierung oder bsd.java.mk. Gleichermaßen gibt es eine definierte Richtlinie für die CATEGORIES eines Java-Ports, die in erklärt wird.
Webanwendungen, Apache und PHP Apache Variablen für Ports, die Apache verwenden USE_APACHE Der Port benötigt Apache. Mögliche Werte: yes (beliebige Version), 1.3, 2.0, 2.2, 2.0+, etc. – Standard ist Version 1.3. WITH_APACHE2 Der Port benötigt Apache 2.0. Ist diese Variable nicht gesetzt, so benötigt der Port Apache 1.3. Diese Variable ist veraltet und sollte nicht mehr verwendet werden. APXS Vollständiger Pfad zu der apxs Binärdatei. Die Variable kann neu gesetzt werden. HTTPD Vollständiger Pfad zu der httpd Binärdatei. Die Variable kann neu gesetzt werden. APACHE_VERSION Beinhaltet die Versionsnummer des aktuell installierten Apache (nur lesbare Variable). Diese Variable ist nach Einbinden der Datei bsd.port.pre.mk verfügbar. Mögliche Werte: 13, 20, 22. APACHEMODDIR Verzeichnis der Apache-Module. Diese Variable wird automatisch in pkg-plist ersetzt. APACHEINCLUDEDIR Verzeichnis der Apache Header-Dateien. Diese Variable wird automatisch in pkg-plist ersetzt. APACHEETCDIR Verzeichnis der Apache-Konfigurationsdateien. Diese Variable wird automatisch in pkg-plist ersetzt.
Nützliche Variablen für Ports von Apache-Modulen MODULENAME Name des Moduls. Standardwert ist PORTNAME. Beispiel: mod_hello SHORTMODNAME Der gekürzte Name des Moduls. Standardmäßig wird der Wert von MODULENAME übernommen. Beispiel: hello AP_FAST_BUILD Verwende apxs zum Kompilieren und Installieren des Moduls. AP_GENPLIST Eine pkg-plist wird automatisch erzeugt. AP_INC Verzeichnis für zusätzliche Header-Dateien, die beim Kompilieren mitverwendet werden. AP_LIB Verzeichnis für zusätzliche Bibliothek-Dateien, welche beim Kompilieren mitverwendet werden. AP_EXTRAS Zusätzliche Flags für apxs.
Webanwendungen Webanwendungen sollten nach PREFIX/www/programmname installiert werden. Der Einfachheit halber ist dieser Pfad sowohl im Makefile als auch in pkg-plist als WWWDIR verfügbar. Der relative Pfad PREFIX ist hingegen im Makefile durch die Variable WWWDIR_REL festgelegt. Der Benutzername und die Benutzergruppe, mit deren Rechte Webanwendungen laufen, sind in WWWOWN und WWWGRP festgelegt. Standardwert ist bei beiden www. Falls ein Port mit anderen Rechten gestartet werden soll, so sollte die Anweisung WWWOWN?= myuser verwendet werden. Dies vereinfacht dem Benutzer eine Anpassung dieser Werte. Falls die Webanwendung nicht explizit Apache benötigt, so sollte dieser auch nicht als Abhängigkeit des Ports aufgeführt werden. Dadurch bleibt es dem Benutzer überlassen Apache oder einen anderen Webserver zu verwenden. PHP Variablen für Ports, die PHP verwenden USE_PHP Der Port benötigt PHP. Der Wert yes bewirkt eine Abhängigkeit des Ports von PHP. Es kann auch eine Liste der benötigten PHP-Erweiterungen angegeben werden. Beispiel: pcre xml gettext DEFAULT_PHP_VER Legt die Version von PHP fest, die standardmäßig installiert wird, falls noch kein PHP vorhanden ist. Standardwert ist 4. Mögliche Werte sind: 4,5 IGNORE_WITH_PHP Der Port funktioniert nicht mit der angegebenen Version von PHP. Mögliche Werte: 4, 5 USE_PHPIZE Der Port wird als PHP-Erweiterung gebaut. USE_PHPEXT Der Port wird wie eine PHP-Erweiterung behandelt – Installation und Eintragung in die PHP-Registry für Erweiterungen. USE_PHP_BUILD Setzt PHP als build-Anhängigkeit. WANT_PHP_CLI Benötigt die Kommandozeilen-Version von PHP. WANT_PHP_CGI Benötigt die CGI-Version von PHP. WANT_PHP_MOD Benötigt das Apache-Modul von PHP. WANT_PHP_SCR Benötigt die Kommandozeilen- oder die CGI-Version von PHP. WANT_PHP_WEB Benötigt das Apache-Modul oder die CGI-Version von PHP.
PEAR Module Das Portieren von PEAR-Modulen ist sehr einfach. Mit Hilfe der Variablen FILES, TESTS, DATA, SQLS, SCRIPTFILES, DOCS und EXAMPLES können die zu installierenden Dateien angegeben werden. Alle aufgeführten Dateien werden automatisch in die jeweiligen Verzeichnisse installiert und der Datei pkg-plist hinzugefügt. Die Datei ${PORTSDIR}/devel/pear/bsd.pear.mk muss am Ende des Makefiles eingebunden werden. Beispiel eines Makefiles für eine PEAR Klasse PORTNAME= Date PORTVERSION= 1.4.3 CATEGORIES= devel www pear MAINTAINER= example@domain.com COMMENT= PEAR Date and Time Zone Classes BUILD_DEPENDS= ${PEARDIR}/PEAR.php:${PORTSDIR}/devel/pear-PEAR RUN_DEPENDS= ${BUILD_DEPENDS} FILES= Date.php Date/Calc.php Date/Human.php Date/Span.php \ Date/TimeZone.php TESTS= test_calc.php test_date_methods_span.php testunit.php \ testunit_date.php testunit_date_span.php wknotest.txt \ bug674.php bug727_1.php bug727_2.php bug727_3.php \ bug727_4.php bug967.php weeksinmonth_4_monday.txt \ weeksinmonth_4_sunday.txt weeksinmonth_rdm_monday.txt \ weeksinmonth_rdm_sunday.txt DOCS= TODO _DOCSDIR= . .include <bsd.port.pre.mk> .include "${PORTSDIR}/devel/pear/bsd.pear.mk" .include <bsd.port.post.mk>
Python benutzen Die Ports unterstützen parallele Installationen mehrerer Python-Versionen. Ports sollten sicherstellen, dass der richtige python-Interpreter verwendet wird – entsprechend der durch den Benutzer definierbaren Variable PYTHON_VERSION. Häufig bedeutet dies, dass der Pfad zum python-Interpreter durch den Wert der Variablen PYTHON_CMD ersetzt werden muss. Ports, die Dateien unter PYTHON_SITELIBDIR installieren, sollten pyXY- als Präfix des Paketnamens haben, sodass in deren Paketname die zugehörige Python Version aufgeführt wird. PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} Nützliche Variablen für Ports, die Python verwenden USE_PYTHON Der Port benötigt Python. Die minimal benötigte Version kann durch Werte wie 2.3+ angegeben werden. Bereiche von Versionsnummern können durch Angabe der minimalen und maximalen Versionsnummer, getrennt durch einen Gedankenstrich, festgelegt werden, z.B.: 2.1-2.3 USE_PYDISTUTILS Verwende Python-distutils zum Konfigurieren, Kompilieren und Installieren. Dies ist erforderlich, falls der Port eine setup.py-Datei beinhaltet. Dadurch werden die do-build und do-install-Ziele und eventuell auch das do-configure-Ziel übergangen, falls GNU_CONFIGURE nicht definiert ist. PYTHON_PKGNAMEPREFIX Wird als PKGNAMEPREFIX verwendet, um Pakete für unterschiedliche Python-Versionen zu trennen. Beispiel: py24- PYTHON_SITELIBDIR Verzeichnis des site-Pakete Baums, der das Installationsverzeichnis von Python (üblicherweise LOCALBASE) beinhaltet. Die PYTHON_SITELIBDIR-Variable kann sehr nützlich bei der Installation von Python-Modulen sein. PYTHONPREFIX_SITELIBDIR Die präfix-freie Variante von PYTHON_SITELIBDIR. Benutzen Sie immer %%PYTHON_SITELIBDIR%% in pkg-plist, wenn möglich. Der Standardwert von %%PYTHON_SITELIBDIR%% ist lib/python%%PYTHON_VERSION%%/site-packages PYTHON_CMD Kommandozeilen-Interpreter für Python mit Versionsnummer. PYNUMERIC Liste der Abhängigkeiten für numerische Erweiterungen. PYNUMPY Liste der Abhängigkeiten für die neue numerische Erweiterung numpy. (PYNUMERIC ist vom Anbieter als veraltet deklariert) PYXML Liste der Abhängigkeiten für XML-Erweiterungen (wird ab Python 2.0 nicht mehr benötigt, da im Basispaket enthalten). USE_TWISTED Setzt die Abhängigkeit des Ports von twistedCore. Die Liste der erforderlichen Komponenten kann als Wert spezifiziert werden. Beispiel: web lore pair flow USE_ZOPE Setzt Zope, eine Plattform für Webanwendungen, als Abhängigkeit des Ports. Setzt die Versionsabhängigkeit von Python auf 2.3. Setzt ZOPEBASEDIR auf das Verzeichnis, in welches Zope installiert wurde.
Eine vollständige Liste aller verfügbaren Variablen ist in /usr/ports/Mk/bsd.python.mk zu finden.
Benutzung von <application>Tcl/Tk</application> Die Ports-Sammlung unterstützt die parallele Installation mehrerer Tcl/Tk-Versionen. Ports sollten mindestens die vorgegebene Tcl/Tk-Version oder höher zu unterstützen versuchen anhand der Variablen USE_TCL und USE_TK. Es ist möglich, die gewünschte Version von tcl mit der Variable WITH_TCL_VER vorzuschreiben. Äußerst nützliche Variablen für Ports, die <application>Tcl/Tk</application> benutzen USE_TCL Der Port benötigt die Tcl-Bibliothek (nicht die Shell). Eine notwendige Mindestversion kann mit Werten wie 84+ angegeben werden. Einzelne nicht unterstützte Versionen können mit der Variable INVALID_TCL_VER festgelegt werden. USE_TCL_BUILD Der Port benötigt Tcl nur während der Zeit, in der er gebaut wird. USE_TCL_WRAPPER Ports, welche zwar die Tcl-Shell, aber nicht eine bestimmte Version von tclsh verlangen, sollten diese neue Variable verwenden. Ein Wrapperskript für tclsh wird auf dem System installiert. Der Benutzer kann festlegen, welche tcl-Shell gewünscht ist bzw. verwendet werden soll. WITH_TCL_VER Benutzerdefinierte Variable, welche die gewünschte Tcl-Version bestimmt. PORTNAME_WITH_TCL_VER Gleich wie WITH_TCL_VER, nur portspezifisch. USE_TCL_THREADS Fordere threadfähiges Tcl/Tk. USE_TK Der Port benötigt die Tk-Bibliothek (nicht die Wish-Shell). Impliziert USE_TCL mit dem gleichen Wert. Für weitere Informationen siehe die Beschreibung der Variable USE_TCL. USE_TK_BUILD Analog zur Variable USE_TCL_BUILD. USE_TK_WRAPPER Analog zur Variable USE_TCL_WRAPPER. WITH_TK_VER Analog zur Variable WITH_TCL_VER und impliziert WITH_TCL_VER mit dem gleichen Wert.
Eine vollständige Liste der zur Verfügung stehenden Variablen befindet sich in /usr/ports/Mk/bsd.tcl.mk.
Emacs benutzen Dieser Abschnitt muss noch geschrieben werden. Ruby benutzen Nützliche Variablen für Ports, die Ruby verwenden Variable Description USE_RUBY Der Port benötigt Ruby. USE_RUBY_EXTCONF Der Port verwendet extconf.rb für die Konfiguration. USE_RUBY_SETUP Der Port verwendet setup.rb für die Konfiguration. RUBY_SETUP Legt den alternativen Namen von setup.rb fest. Üblich ist der Wert install.rb.
Die folgende Tabelle listet ausgewählte Variablen auf, die Portautoren über die Port-Infrastruktur zur Verfügung stehen. Diese Variablen sollten für die Installation von Dateien in die entsprechenden Verzeichnisse verwendet werden. Sie sollten in pkg-plist so häufig wie möglich verwendet und in einem Port nicht neu definiert werden. Ausgewählte read-only-Variablen für Ports, die Ruby verwenden Variable Beschreibung Beispiel RUBY_PKGNAMEPREFIX Wird als PKGNAMEPREFIX verwendet, um Pakete für verschiedene Versionen von Ruby zu unterscheiden. ruby18- RUBY_VERSION Vollständige Version von Ruby in der Form x.y.z. 1.8.2 RUBY_SITELIBDIR Installationsverzeichnis der von der Rechnerarchitektur unabhängigen Bibliotheken. /usr/local/lib/ruby/site_ruby/1.8 RUBY_SITEARCHLIBDIR Installationsverzeichnis der von der Rechnerarchitektur abhängigen Bibliotheken. /usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6 RUBY_MODDOCDIR Installationsverzeichnis für die Dokumentation der Module. /usr/local/share/doc/ruby18/patsy RUBY_MODEXAMPLESDIR Installationsverzeichnis für die Beispiele der Module. /usr/local/share/examples/ruby18/patsy
Eine vollständige Liste der verfügbarenVariablen kann in /usr/ports/Mk/bsd.ruby.mk eingesehen werden.
SDL verwenden Die Variable USE_SDL wird für die automatische Konfiguration der Abhängigkeiten für Ports benutzt, die auf SDL basierende Bibliotheken wie devel/sdl12 und x11-toolkits/sdl_gui verwenden. Die folgenden SDL-Bibliotheken sind derzeit bekannt: sdl: devel/sdl12 gfx: graphics/sdl_gfx gui: x11-toolkits/sdl_gui image: graphics/sdl_image ldbad: devel/sdl_ldbad mixer: audio/sdl_mixer mm: devel/sdlmm net: net/sdl_net sound: audio/sdl_sound ttf: graphics/sdl_ttf Falls ein Port z.B. von net/sdl_net und audio/sdl_mixer abhängt, so wäre die Syntax: USE_SDL= net mixer Die Abhängigkeit von devel/sdl12, die durch net/sdl_net und audio/sdl_mixer entsteht, wird automatisch zum Port hinzugefügt. Falls USE_SDL im Port verwendet wird, so wird automatisch: die Abhängigkeit von sdl12-config zu BUILD_DEPENDS hinzugefügt die Variable SDL_CONFIG zu CONFIGURE_ENV hinzugefügt die Abhängigkeit der ausgewählten Bibliotheken zu LIB_DEPENDS hinzugefügt Um zu überprüfen, ob die SDL-Bibliotheken verfügbar sind, kann die Variable WANT_SDL verwendet werden: WANT_SDL=yes .include <bsd.port.pre.mk> .if ${HAVE_SDL:Mmixer}!="" USE_SDL+= mixer .endif .include <bsd.port.post.mk> <application>wxWidgets</application> verwenden Dieser Abschnitt beschreibt den Status der wxWidgets-Bibliotheken in den Ports und deren Einbindung in das Ports-System. Einführung Es gibt viele Probleme bei der gleichzeitigen Verwendung unterschiedlicher Versionen von wxWidgets-Bibliotheken (Dateien unterschiedlicher wxWidgets-Versionen haben denselben Dateinamen). In den Ports wurde das Problem dadurch gelöst, dass jede Version unter einem eigenen Namen installiert wird, der die Versionsnummer als Suffix beinhaltet. Der offensichtliche Nachteil dabei ist, dass jede Anwendung so verändert werden muss, dass sie die erwartete Version vorfindet. Die meisten solcher Anwendungen benutzen das wx-config-Skript, um die benötigten Compiler- und Linkerflags zu erhalten. Dieses Skript hat für jede verfügbare Version einen anderen Namen. Die meisten Anwendungen beachten eine Umgebungsvariable oder ein Argument beim configure-Skript, um das gewünschte wx-config-Skript festzulegen. Ansonsten müssen sie gepatcht werden. Auswahl der Version Um festzulegen, welche Version der wxWidgets verwendet werden soll, gibt es zwei Variablen (falls nur eine der beiden definiert wird, so wird die andere auf einen Standardwert gesetzt): Variablen, um die <application>wxWidgets</application>-Version festzulegen Variable Beschreibung Standardwert USE_WX Liste der Versionen, die der Port verwenden kann Alle verfügbaren Versionen USE_WX_NOT Liste der Versionen, die der Port nicht verwenden kann Nichts
Es folgt eine Liste an möglichen wxWidgets-Versionen und deren zugehöriger Port: Verfügbare <application>wxWidgets</application>-Versionen Version Port 2.4 x11-toolkits/wxgtk24 2.6 x11-toolkits/wxgtk26 2.8 x11-toolkits/wxgtk28
Ab Version 2.5 werden auch Versionen in Unicode unterstützt und über einen Unterport mit dem Suffix -unicode installiert. Dies kann aber auch über Variablen gehandhabt werden (siehe ). Die Variablen in können auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden: Spezifikationen der <application>wxWidgets</application>-Versionen Beschreibung Beispiel Einzelne Version 2.4 Aufsteigende Versionsnummern 2.4+ Absteigende Versionsnummern 2.6- Versionsinterval (muss aufsteigend sein) 2.4-2.6
Desweiteren gibt es Variablen, über die eine bevorzugte Version festgelegt werden kann. Die Versionen können als Liste angegeben werden, wobei die Reihenfolge der Priorisierung entspricht. Variablen zur Festlegung der bevorzugten <application>wxWidgets</application>-Version Name Bestimmt für WANT_WX_VER den Port WITH_WX_VER den Benutzer
Komponentenauswahl Desweiteren gibt es Anwendungen, die nicht direkt wxWidgets-Bibliotheken sind, aber trotzdem mit diesen zusammenhängen. Diese Anwendungen können über die Variable WX_COMPS festgelegt werden. Die folgenden Komponenten sind verfügbar: Verfügbare <application>wxWidgets</application>-Komponenten Name Beschreibung Versionsbeschränkungen wx Hauptbibliothek Nichts contrib Beigesteuerte Bibliothek Nichts python wxPython (Python-Bindungen) 2.4-2.6 mozilla wxMozilla 2.4 svg wxSVG 2.6
Der Typ der Abhängigkeit kann für jede Komponente durch hinzufügen eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ nicht angegeben wird, wird ein Standardwert verwendet (siehe ). Die folgenden Typen sind verfügbar: Verfügbare Typen von <application>wxWidgets</application>-Abhängigkeiten Name Beschreibung build Komponente wird zum Bau benötigt – äquivalent zu BUILD_DEPENDS run Komponente wird zum Ausführen benötigt – äquivalent zu RUN_DEPENDS lib Komponente wird zum Bau und Ausführen benötigt – äquivalent zu LIB_DEPENDS
Die Standardwerte für die einzelnen Komponenten sind in der folgenden Tabelle aufgeführt: Standardtypen der <application>wxWidgets</application>-Abhängigkeiten Komponente Typ der Abhängigkeit wx lib contrib lib python run mozilla lib svg lib
Auswahl von <application>wxWidgets</application>-Komponenten Der folgende Ausschnitt entspricht einem Port, der die wxWidgets-Version 2.4 und die zugehörigen Bibliotheken verwendet. USE_WX= 2.4 WX_COMPS= wx contrib
Unicode Die wxWidgets-Bibliotheken unterstützen Unicode seit der Version 2.5. In den Ports sind beide Versionen verfügbar und können über die folgenden Variablen ausgewählt werden: Variablen, um Unicode in den <application>wxWidgets</application>-Versionen auszuwählen Variable Beschreibung Bestimmt für WX_UNICODE Der Port funktioniert ausschließlich mit der Unicode-Version den Port WANT_UNICODE Der Port funktioniert in beiden Versionen – bevorzugt wird jedoch Unicode den Port WITH_UNICODE Der Port verwendet die Unicode-Version den Benutzer WITHOUT_UNICODE Der Port verwendet, falls unterstützt, die normale Version (falls WX_UNICODE nicht definiert ist) den Benutzer
Die Variable WX_UNICODE darf nicht bei Ports benutzt werden, die sowohl die Version mit als auch ohne Unterstützung für Unicode verwenden können. Falls der Port standardmäßig Unterstützung für Unicode bieten soll, verwenden Sie WANT_UNICODE stattdessen.
Feststellen der installierten Version Um eine bereits installierte Version zu finden, muss WANT_WX definiert werden. Falls diese Variable nicht auf eine bestimmte Versionsnummer gesetzt wird, werden die Komponenten einen Suffix mit der Versionsnummer tragen. Die Variable HAVE_WX wird gesetzt, falls eine installierte Version vorgefunden wurde. Installierte <application>wxWidgets</application>-Versionen und –Komponenten feststellen Der folgende Ausschnitt kann in einem Port verwendet werden, der wxWidgets verwendet, falls es installiert ist, oder falls eine Option dafür ausgewählt wurde. WANT_WX= yes .include <bsd.port.pre.mk> .if defined(WITH_WX) || ${HAVE_WX:Mwx-2.4} != "" USE_WX= 2.4 CONFIGURE_ARGS+=--enable-wx .endif Der folgende Ausschnitt kann verwendet werden, um die Unterstützung für wxPython zusätzlich zu der von wxWidgets zu aktivieren (beide in Version 2.6), wenn das installiert ist, oder die Option ausgewählt wurde. USE_WX= 2.6 WX_COMPS= wx WANT_WX= 2.6 .include <bsd.port.pre.mk> .if defined(WITH_WXPYTHON) || ${HAVE_WX:Mpython} != "" WX_COMPS+= python CONFIGURE_ARGS+=--enable-wxpython .endif Vordefinierte Variablen Die folgenden Variablen sind in den Ports verfügbar (nachdem sie entsprechend definiert wurden). Vordefinierte Variablen für Ports, die <application>wxWidgets</application> verwenden Name Beschreibung WX_CONFIG Pfad zum wxWidgets wx-config-Skript (mit unterschiedlichem Namen) WXRC_CMD Pfad zum wxWidgets wxrc-Programm (mit unterschiedlichem Namen) WX_VERSION Version der wxWidgets, die verwendet werden soll (z.B. 2.6) WX_UNICODE Falls Unterstützung für Unicode nicht explizit definiert, jedoch verwendet wird, dann wird die Unterstützung automatisch aktiviert.
Verarbeitung in <filename>bsd.port.pre.mk</filename> Falls die Variablen gleich nach dem Importieren von bsd.port.pre.mk benutzt werden sollen, so muss die Variable WX_PREMK definiert werden. Falls WX_PREMK definiert ist, so werden Version, Abhängigkeiten, Komponenten und vordefinierte Variablen nicht geändert, wenn die Variablen des wxWidgets-Ports nach dem Einbinden von bsd.port.pre.mk geändert werden. Verwendung von <application>wxWidgets</application>-Variablen in Kommandos Der folgende Ausschnitt zeigt die Verwendung von WX_PREMK durch Ausführen des wx-config-Skriptes, um die vollständige Version als Zeichenkette zu erhalten, diese dann einer Variablen zuzuweisen und die Variable anschließend einem Programm zu übergeben. USE_WX= 2.4 WX_PREMK= yes .include <bsd.port.pre.mk> .if exists(${WX_CONFIG}) VER_STR!= ${WX_CONFIG} --release PLIST_SUB+= VERSION="${VER_STR}" .endif Die wxWidgets-Variablen können problemlos in Kommandos benutzt werden, falls diese in Targets ohne gesetztes WX_PREMK verwendet werden. Weitere <command>configure</command>-Argumente Einige GNU configure-Skripte können wxWidgets nicht auffinden, falls nur die Umgebungsvariable WX_CONFIG gesetzt ist, sondern benötigen zusätzliche Argumente. Dafür kann die Variable WX_CONF_ARGS benutzt werden. Zulässige Werte für <makevar>WX_CONF_ARGS</makevar> Möglicher Wert Resultierendes Argument absolute --with-wx-config=${WX_CONFIG} relative --with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T}
Verwendung von <application>Lua</application> Dieser Abschnitt beschreibt den Status der Lua-Bibliotheken in den Ports und deren Einbindung in das Ports System. Einführung Es gibt viele Probleme bei der gleichzeitigen Verwendung unterschiedlicher Versionen von Lua-Bibliotheken (Dateien unterschiedlicher Versionen haben denselben Dateinamen). In den Ports wurde das Problem gelöst, indem jede Version unter einem eigenen Namen mit der Versionsnummer als Suffix installiert wird. Der offensichtliche Nachteil dabei ist, dass jede Anwendung so verändert werden muss, dass sie die erwartete Version vorfindet. Dies kann jedoch durch zusätzliche Flags für Compiler und Linker gelöst werden. Auswahl der Version Um festzulegen, welche Version von Lua verwendet werden soll, gibt es zwei Variablen (falls nur eine der beiden definiert ist, so wird die andere auf einen Standardwert gesetzt): Variablen, um die <application>Lua</application>-Version festzulegen Variable Beschreibung Standardwert USE_LUA Liste der Versionen, welche der Port verwenden kann Alle verfügbaren Versionen USE_LUA_NOT Liste der Versionen, die der Port nicht verwenden kann Nichts
Es folgt eine Liste an möglichen Lua-Versionen und deren zugehöriger Port: Verfügbare <application>Lua</application>-Versionen Version Port 4.0 lang/lua4 5.0 lang/lua50 5.1 lang/lua
Die Variablen in können auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden: Spezifikationen der <application>Lua</application>-Versionen Beschreibung Beispiel Spezielle Version 4.0 Aufsteigende Versionen 5.0+ Absteigende Versionen 5.0- Versionenintervall (muss aufsteigend sein) 5.0-5.1
Desweiteren gibt es Variablen, über die eine bevorzugte Version festgelegt werden kann. Die Versionen können als Liste angegeben werden, wobei die Reihenfolge der Priorisierung entspricht. Variablen zur Festlegung der bevorzugten <application>Lua</application>-Version Name Bestimmt für WANT_LUA_VER den Port WITH_LUA_VER den Benutzer
Auswahl der <application>Lua</application>-Version Der folgende Ausschnitt entspricht einem Port, der Lua in den Versionen 5.0 oder 5.1 verwenden kann und standardmäßig 5.0 verwendet. Diese Einstellung kann durch die benutzerdefinierte Variable WITH_LUA_VER überschrieben werden. USE_LUA= 5.0-5.1 WANT_LUA_VER= 5.0
Komponentenauswahl Desweiteren gibt es Anwendungen, die nicht direkt Lua-Bibliotheken sind, aber trotzdem mit diesen zusammenhängen. Diese Anwendungen können über die Variable LUA_COMPS festgelegt werden. Die folgenden Komponenten sind verfügbar: Verfügbare <application>Lua</application>-Komponenten Name Beschreibung Versionseinschränkungen lua Hauptbibliothek Keine tolua Bibliothek für die Unterstützung von C/C++-Code 4.0-5.0 ruby Ruby-Bindungen 4.0-5.0
Es gibt weitere Komponenten, die jedoch Module für den Interpreter sind und nicht von Anwendungen benutzt werden (nur von anderen Modulen). Der Typ der Abhängigkeit kann für jede Komponente durch Hinzufügen eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ nicht angegeben wird, wird ein Standardwert verwendet (siehe ). Die folgenden Typen sind verfügbar: Verfügbare Typen von <application>Lua</application>-Abhängigkeiten Name Beschreibung build Komponente wird zum Bau benötigt – äquivalent zu BUILD_DEPENDS run Komponente wird zum Ausführen benötigt – äquivalent zu RUN_DEPENDS lib Komponente wird zum Bau und zum Ausführen benötigt – äquivalent zu LIB_DEPENDS
Die Standardwerte für die einzelnen Komponenten sind in der folgenden Tabelle aufgeführt: Standardtypen für <application>Lua</application>-Abhängigkeiten Komponente Typ der Abhängigkeit lua lib für 4.0-5.0 (shared) und build für 5.1 (static) tolua build (static) ruby lib (shared)
Auswahl von <application>Lua</application>-Komponenten Der folgende Ausschnitt entspricht einem Port, welcher die Lua-Version 4.0 und die zugehörigen Ruby-Bindungen verwendet. USE_LUA= 4.0 LUA_COMPS= lua ruby
Feststellen der installierten Version Um eine bereits installierte Version zu finden, muss WANT_LUA definiert werden. Falls diese Variable nicht auf eine bestimmte Versionsnummer gesetzt wird, werden die Komponenten einen Suffix mit der Versionsnummer tragen. Die Variable HAVE_LUA wird gesetzt, falls eine installierte Version vorgefunden wurde. Installierte <application>Lua</application>-Versionen und– Komponenten feststellen Der folgende Ausschnitt kann in einem Port verwendet werden, der Lua benutzt, falls es installiert ist oder eine Option dafür ausgewählt wurde. WANT_LUA= yes .include <bsd.port.pre.mk> .if defined(WITH_LUA5) || ${HAVE_LUA:Mlua-5.[01]} != "" USE_LUA= 5.0-5.1 CONFIGURE_ARGS+=--enable-lua5 .endif Der folgende Ausschnitt kann verwendet werden, um die Unterstützung für tolua zusätzlich zu der von Lua zu aktivieren (beide in Version 4.0), wenn dies installiert ist oder die Option ausgewählt wurde. USE_LUA= 4.0 LUA_COMPS= lua WANT_LUA= 4.0 .include <bsd.port.pre.mk> .if defined(WITH_TOLUA) || ${HAVE_LUA:Mtolua} != "" LUA_COMPS+= tolua CONFIGURE_ARGS+=--enable-tolua .endif Vordefinierte Variablen Die folgenden Variablen sind in den Ports verfügbar (nachdem sie entsprechend definiert wurden). Vordefinierte Variablen für Ports, die <application>Lua</application> verwenden Name Beschreibung LUA_VER Die Lua-Version, die verwendet wird (z.B. 5.1) LUA_VER_SH Die Hauptversion für shared-Lua-Bibliotheken (z.B. 1) LUA_VER_STR Die Lua-Version ohne die Punkte (z.B. 51) LUA_PREFIX Der Präfix, unter dem Lua (und Komponenten) installiert ist LUA_SUBDIR Das Verzeichnis unter ${PREFIX}/bin, ${PREFIX}/share und ${PREFIX}/lib, in welchem Lua installiert ist LUA_INCDIR Das Verzeichnis, in dem Lua- und tolua-Header-Dateien installiert sind LUA_LIBDIR Das Verzeichnis, in dem Lua– und tolua-Bibliotheken installiert sind LUA_MODLIBDIR Das Verzeichnis, in dem Lua Modul-Bibliotheken (.so) installiert sind LUA_MODSHAREDIR Das Verzeichnis, in dem Lua-Module (.lua) installiert sind LUA_PKGNAMEPREFIX Der Paketnamen-Präfix, der von Lua-Modulen verwendet wird LUA_CMD Das Verzeichnis, in dem der Lua-Interpreter liegt LUAC_CMD Das Verzeichnis, in dem der Lua-Compiler liegt TOLUA_CMD Das Verzeichnis, in dem das tolua-Programm liegt
Einem Port mitteilen, in welchem Verzeichnis <application>Lua</application> liegt Der folgende Ausschnitt zeigt, wie einem Port, welcher ein configure-Skript verwendet, mitgeteilt werden kann, wo die Lua-Header-Dateien und Bibliotheken liegen. USE_LUA= 4.0 GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}"
Verarbeitung in <filename>bsd.port.pre.mk</filename> Falls die Variablen gleich nach dem Einbinden von bsd.port.pre.mk benutzt werden sollen, so muss die Variable LUA_PREMK definiert werden. Falls LUA_PREMK definiert ist, so werden Version, Abhängigkeiten, Komponenten und vordefinierte Variablen nicht geändert, wenn die Variablen des Lua-Ports nach dem Einbinden von bsd.port.pre.mk geändert werden. Verwendung von <application>Lua</application>-Variablen in Kommandos Der folgende Ausschnitt zeigt die Verwendung von LUA_PREMK durch Ausführen des Lua-Interpreters, um die vollständige Version als Zeichenkette zu erhalten, diese dann einer Variablen zuzuweisen und die Variable schließlich einem Programm zu übergeben. USE_LUA= 5.0 LUA_PREMK= yes .include <bsd.port.pre.mk> .if exists(${LUA_CMD}) VER_STR!= ${LUA_CMD} -v CFLAGS+= -DLUA_VERSION_STRING="${VER_STR}" .endif Die Lua-Variablen können problemlos in Befehlen benutzt werden, falls diese in Targets ohne gesetztes LUA_PREMK verwendet werden.
Xfce verwenden Die USE_XFCE-Variable wird für die automatische Konfiguration der Abhängigkeiten eingesetzt, welche die Xfce-Basisbibliotheken oder Anwendungen wie x11-toolkits/libxfce4gui und x11-wm/xfce4-panel verwenden. Die folgenden Xfce-Bibliotheken und -Anwendungen werden derzeit unterstützt: libexo: x11/libexo libgui: x11-toolkits/libxfce4gui libutil: x11/libxfce4util libmcs: x11/libxfce4mcs mcsmanager: sysutils/xfce4-mcs-manager panel: x11-wm/xfce4-panel thunar: x11-fm/thunar wm: x11-wm/xfce4-wm xfdev: dev/xfce4-dev-tools Die folgenden zusätzlichen Parameter werden unterstützt: configenv: Benutzen Sie dies, wenn Ihr Port eine speziell angepasste CONFIGURE_ENV-Variable benötigt, um seine erforderlichen Bibliotheken zu finden. -I${LOCALBASE}/include -L${LOCALBASE}/lib wird CPPFLAGS hinzugefügt und ergibt CONFIGURE_ENV. Wenn also ein Port von sysutils/xfce4-mcs-manager abhängt und die speziellen CPPFLAGS in seiner configure-Umgebung verlangt, dann würde die Syntax wie folgt aussehen: USE_XFCE= mcsmanager configenv Benutzung von Datenbanken Variablen für Ports, die Datenbanken benutzen Variable Bedeutung USE_BDB Falls die Variable auf yes gesetzt ist, füge eine Abhängigkeit von databases/db41 hinzu. Die Variable kann auch folgende Werte annehmen: 2, 3, 40, 41, 42, 43, 44, 45, 46 oder 47. Sie können eine Folge akzeptierter Werte angeben - USE_BDB=42+ stellt die höchste installierte Version fest und greift auf 42 zurück, falls sonst nichts installiert ist. USE_MYSQL Falls die Variable auf yes gesetzt ist, füge databases/mysql50-server als Abhängigkeit hinzu. Die damit verknüpfte Variable WANT_MYSQL_VER kann Werte wie 323, 40, 41, 50, 51 oder 60 annehmen. USE_PGSQL Falls die Variable auf yes gesetzt ist, füge eine Abhängigkeit von databases/postgresql82 hinzu. Die damit verknüpfte Variable WANT_MYSQL_VER kann Werte wie 73, 74, 80, 81, 82 oder 83 annehmen.
Starten und Anhalten von Diensten (rc Skripten) rc.d-Skripten werden zum Starten von Diensten während des Systemstarts verwendet und um den Administratoren einen Standardweg zum Anhalten und Starten von Diensten zu bieten. Ports halten sich an dieses systemweite rc.d-Framework. Details zu deren Benutzung können im rc.d Kapitel des Handbuchs nachgelesen werden. Ausführliche Beschreibungen der verfügbaren Befehle stehen in &man.rc.8; und &man.rc.subr.8;. Desweiteren gibt es einen Artikel zu praktischen Aspekten bezüglich rc.d-Skripten. - Ein oder mehrere rc-Skripten können installiert + Ein oder mehrere rc.d-Skripten können installiert werden mittels: USE_RC_SUBR= doormand Skripten müssen im Unterverzeichnis files abgelegt und jeder Skript-Datei muss ein .in-Suffix hinzugefügt - werden. Der einzige Unterschied zu einem - rc.d-Skript aus dem Basissystem ist, dass - die Zeile . /etc/rc.subr in - . %%RC_SUBR%% umbenannt werden muss, - da ältere Versionen von &os; die Datei - /etc/rc.subr nicht besitzen. - Standarderweiterungen wie SUB_LIST werden - ebenfalls unterstützt. Die Verwendung von + werden. Standardmäßige + SUB_LIST-Ersetzungen werden für diese + Dateien unterstützt. Die Verwendung von %%PREFIX%% und %%LOCALBASE%% wird dringend empfohlen. Näheres zu SUB_LIST kann im zugehörigen Kapitel nachgelesen werden. Für &os;-Versionen, die älter als 6.1-RELEASE sind, ist die Integration mittels &man.rcorder.8; möglich, indem USE_RCORDER anstatt USE_RC_SUBR verwendet wird. Die Verwendung - dieser Methode wird aber nicht mehr empfohlen. + dieser Methode ist jedoch nur notwendig, wenn der Port in die + Verzeichnisstruktur des Basissystems installiert werden kann + oder der Dienst vor den + FILESYSTEMS-Skripten in + rc.d des Basissystems gestartet sein + muss. Seit &os; 6.1-RELEASE sind lokale rc.d-Skripten (inklusive der durch Ports installierten) im allgemeinen &man.rcorder.8; des Basissystems. Beispiel eines einfachen rc.d-Skripts: #!/bin/sh +# $FreeBSD$ +# # PROVIDE: doormand # REQUIRE: LOGIN +# KEYWORD: shutdown # # Add the following lines to /etc/rc.conf.local or /etc/rc.conf # to enable this service: # # doormand_enable (bool): Set to NO by default. # Set it to YES to enable doormand. # doormand_config (path): Set to %%PREFIX%%/etc/doormand/doormand.cf # by default. # -. %%RC_SUBR%% +. /etc/rc.subr name="doormand" rcvar=${name}_enable command=%%PREFIX%%/sbin/${name} pidfile=/var/run/${name}.pid load_rc_config $name : ${doormand_enable="NO"} : ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"} command_args="-p $pidfile -f $doormand_config" run_rc_command "$1" + Solange kein guter Grund dafür besteht, einen Dienst + früher starten zu lassen, sollten alle Ports-Skripten + REQUIRE: LOGIN verwenden. + Falls der Port von einem bestimmten Benutzer (außer + root) ausgeführt wird, ist dies zwingend. + KEYWORD: shutdown ist im + Skript oben deswegen vorhanden, weil der frei erfundene + Beispiel-Port einen Dienst startet und dieser beim + Herunterfahren des Systems sauber beendet werden sollte. + Startete das Skript keinen persistenten Dienst, wäre dies + nicht notwendig. + Für die Wertzuweisung von Variablen sollte "=" anstatt ":=" verwendet werden, da bei Ersterem nur auf einen Standardwert gesetzt wird, wenn die Variable vorher noch nicht gesetzt war, und bei Letzterem dieser gesetzt wird, auch wenn der Wert vorher Null gewesen ist. Ein Benutzer kann durchaus einen Ausdruck wie doormand_flags="" in seiner rc.conf.local-Datei stehen haben, und eine Variablenzuweisung mittels ":=" würde in diesem Fall die Benutzerdefinition überschreiben. - Der Suffix des rc-Skriptes wird durch - RC_SUBR_SUFFIX für die weitere - Verwendung im Makefile des Ports - bereitgestellt. Aktuelle Versionen von &os; fügen keinen - Suffix den Skriptnamen hinzu im Gegensatz zu ältere - Versionen, die dies mit dem Suffix .sh - taten. - Es sollten keine weiteren Skripten mit der .sh-Endung hinzugefügt werden. Irgendwann wird es ein Massenumbenennen aller Skripten im Repository geben, die immer noch diese Endung haben. Anhalten und Deinstallieren von Diensten Es ist möglich, dass ein Dienst während der Deinstallation automatisch angehalten wird. Es wird empfohlen dieses Verhalten nur zu implementieren, wenn es unbedingt erforderlich ist zuerst den Dienst anzuhalten und dann die Dateien zu entfernen. Normalerweise sollte es dem Administrator überlassen werden, ob ein Dienst durch Deinstallieren angehalten werden soll. Dies betrifft auch den Vorgang des Aktualisierens. Der Datei pkg-plist sollte eine Zeile wie folgt zugefügt werden: @stopdaemon doormand Das Argument muss dabei mit dem Inhalt der USE_RC_SUBR-Variablen übereinstimmen. + + + Hinzufügen von Benutzern und Gruppen + + Manche Ports setzen voraus, dass ein bestimmter Benutzer + auf dem System angelegt ist. Wählen Sie in einem solchen + Fall eine freie Kennnummer zwischen 50 und 999 aus und tragen + Sie diese in ports/UIDs (für + Benutzer) oder ports/GIDs (für + Gruppen) ein. Stellen Sie dabei sicher, dass Sie keine + Kennnummer auswählen, die bereits vom System oder von + anderen Ports verwendet wird. + + Erstellen Sie bitte eine entsprechende Patch-Datei + für diese beiden Dateien, wenn für Ihren Port ein + neuer Benutzer oder eine neue Gruppe angelegt werden + muss. + + Sie können dann die Variablen + USERS und GROUPS im + Makefile benutzen, um bei der + Port-Installation das automatische Anlegen des Benutzers zu + veranlassen. + + USERS= pulse +GROUPS= pulse pulse-access pulse-rt + + Die Liste mit den momentan belegten UIDs (GIDs) befindet + sich in ports/UIDs + (ports/GIDs). +
Fortgeschrittene <filename>pkg-plist</filename>-Methoden Änderungen an <filename>pkg-plist</filename> mit Hilfe von make-Variablen Einige Ports, insbesondere die p5--Ports, müssen, abhängig von ihren Konfigurationsoptionen (oder im Falle der p5-Ports von der perl-Version), die pkg-plist verändern. Um dies zu vereinfachen, werden für jeden Eintrag in pkg-plist die Variablen %%OSREL%%, %%PERL_VER%% und %%PERL_VERSION%% durch die jeweiligen Werte ersetzt. Der Wert von %%OSREL%% ist die Revisionsnummer des Betriebssystems (z.B. 4.9). %%PERL_VERSION%% und %%PERL_VER%% geben die vollständige Versionsnummer von perl (z.B. 5.8.9) an. Weitere, die Dokumentationsdateien des Ports betreffende %%VARS%%, werden im entsprechenden Abschnitt erläutert. Falls Sie weitere Ersetzungen von Variablen durchführen müssen, können Sie in der Variable PLIST_SUB eine Liste von VAR=VALUE-Paaren angeben, wobei in der pkg-plist %%VAR%% durch VALUE ersetzt wird. Wenn Sie z.B. einen Port haben, der viele Dateien in ein versionsspezifisches Unterverzeichnis installiert, dann können Sie etwas wie OCTAVE_VERSION= 2.0.13 PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} in das Makefile schreiben und %%OCTAVE_VERSION%% verwenden, unabhängig davon, wo die Variable in pkg-plist verwendet wird. In diesem Fall müssen Sie bei einem Upgrade des Ports nicht dutzende (oder manchmal sogar hunderte) Zeilen in pkg-plist anpassen. + Falls Ihr Port in Abhängigkeit von den + ausgewählten Optionen Dateien installiert, ist es + üblich, den entsprechenden Zeilen in der + pkg-plist eine Zeichenfolge + %%TAG%% voranzustellen, wobei der + Platzhalter TAG der Variablen + PLIST_SUB im Makefile + bei gleichzeitiger Zuweisung des speziellen Werts + @comment hinzugefügt wird, der die + Paket-Werkzeuge die Zeile ignorieren lässt: + + .if defined(WITH_X11) +PLIST_SUB+= X11="" +.else +PLIST_SUB+= X11="@comment " +.endif + + und in der pkg-plist: + + %%X11%%bin/foo-gui + Diese Ersetzung (ebenso wie das Hinzufügen weiterer Manualpages) wird zwischen den pre-install- und do-install-Targets ausgeführt, indem aus PLIST gelesen und in TMPPLIST geschrieben wird (Standard: WRKDIR/.PLIST.mktmp). Falls Ihr Port also PLIST während dem Erstellen generiert, so sollte dies vor oder in pre-install geschehen. Muss Ihr Port die resultierende Datei verändern, so sollte dies in post-install mit der Ausgabedatei TMPPLIST erfolgen. Eine weitere Möglichkeit, die Paketliste eines Ports zu verändern, besteht darin die Variablen PLIST_FILES und PLIST_DIRS zu setzen. Der Wert jeder der beiden Variablen stellt eine Liste von Pfadnamen dar, die zusammen mit dem Inhalt von PLIST in TMPPLIST geschrieben wird. Dabei unterliegen die Namen in PLIST_FILES und PLIST_DIRS der weiter oben beschriebenen Substitution von %%VAR%%. Die Namen aus PLIST_FILES werden ansonsten unverändert in die endgültige Paketliste übernommen, während den Namen aus PLIST_DIRS noch der Wert von @dirrm vorangestellt wird. Damit die Verwendung von PLIST_FILES und PLIST_DIRS überhaupt möglich ist, müssen diese gesetzt werden, bevor TMPPLIST geschrieben wird – z.B. in pre-install oder vorher. Leere Verzeichnisse Aufräumen leerer Verzeichnisse Bitte sorgen Sie dafür, dass ihre Ports bei der Deinstallation leere Verzeichnisse löschen. Dazu wird für jedes Verzeichnis, das der Port erzeugt hat, eine @dirrm-Zeile angegeben. Um ein Verzeichnis zu löschen müssen Sie zuerst dessen Unterverzeichnisse entfernen. : lib/X11/oneko/pixmaps/cat.xpm lib/X11/oneko/sounds/cat.au : @dirrm lib/X11/oneko/pixmaps @dirrm lib/X11/oneko/sounds @dirrm lib/X11/oneko Es kann allerdings auch vorkommen, dass @dirrm Fehler ausgibt, da andere Ports ein Verzeichnis ebenfalls nutzen. Deshalb können Sie @dirrmtry verwenden, um nur Verzeichnisse zu löschen, die wirklich leer sind, und damit Warnhinweise vermeiden. @dirrmtry share/doc/gimp Dadurch wird es weder eine Fehlermeldung geben noch wird &man.pkg.delete.1; abnormal beendet werden - auch dann nicht, wenn ${PREFIX}/share/doc/gimp nicht leer ist, da andere Ports hier ebenfalls Dateien installiert haben. Erstellen leerer Verzeichnisse Um leere Verzeichnisse während der Installation eines Ports zu erstellen, bedarf es etwas Aufmerksamkeit. Diese Verzeichnisse werden nicht erstellt, wenn das Paket installiert wird, da Pakete nur die Dateien speichern und &man.pkg.add.1; nur die Verzeichnisse erstellt, die dafür benötigt werden. Um sicher zu gehen, dass das leere Verzeichnis erstellt wird, wenn ein Paket installiert wird, muss die folgende Zeile in pkg-plist über der entsprechenden @dirrm Zeile eingetragen werden: @exec mkdir -p %D/share/foo/templates Konfigurationsdateien Sollte Ihr Port Konfigurationsdateien in PREFIX/etc benötigen, so sollten Sie diese nicht einfach installieren und in pkg-plist auflisten. Dies würde &man.pkg.delete.1; veranlassen, diese Dateien zu löschen, selbst wenn wenn sie vom Benutzer editiert wurden. Stattdessen sollten Beispieldateien mit einem entsprechenden Suffix (beispielsweise filename.sample) versehen werden. Ist die Konfigurationsdatei nicht vorhanden, so sollte die Beispieldatei an deren Platz kopiert werden. Bei der Deinstallation sollte die Konfigurationsdatei gelöscht werden, aber nur, wenn sie nicht vom Benutzer verändert wurde. Das alles muss sowohl im Makefile des Ports als auch in der pkg-plist (für die Installation aus einem Paket) sichergestellt werden. Beispiel aus einem Makefile: post-install: @if [ ! -f ${PREFIX}/etc/orbit.conf ]; then \ ${CP} -p ${PREFIX}/etc/orbit.conf.sample ${PREFIX}/etc/orbit.conf ; \ fi Beispiel aus einer pkg-plist: @unexec if cmp -s %D/etc/orbit.conf.sample %D/etc/orbit.conf; then rm -f %D/etc/orbit.conf; fi etc/orbit.conf.sample @exec if [ ! -f %D/etc/orbit.conf ] ; then cp -p %D/%F %B/orbit.conf; fi Wahlweise können Sie auch eine Nachricht ausgegeben lassen, in der Sie den Nutzer auffordern, die Datei an die richtige Stelle zu kopieren und zu bearbeiten, bevor das Programm ausgeführt werden kann. Dynamische oder statische Paketliste Eine statische Paketliste ist eine Paketliste, die in der Ports-Sammlung, entweder in Form der pkg-plist (mit oder ohne der Ersetzung von Variablen) oder durch PLIST_FILES und PLIST_DIRS im Makefile eingebettet, verfügbar ist. Selbst wenn der Inhalt durch ein Werkzeug oder ein Target im Makefile automatisch erzeugt wird, bevor die Datei von einem Committer in die Ports-Sammlung aufgenommen wird, so ist dies immer noch eine statische Liste, da es möglich ist den Dateiinhalt zu betrachten ohne ein Distfile Herunterladen oder Kompilieren zu müssen. Eine dynamische Paketliste ist eine Paketliste, die beim Kompilieren des Ports erstellt wird, abhängig davon, welche Dateien und Verzeichnisse installiert werden. Es ist nicht möglich diese Liste zu betrachten, bevor der Quelltext heruntergeladen und kompiliert oder nachdem ein make clean ausgeführt wurde. Der Einsatz dynamischer Paketlisten ist zwar nicht untersagt, aber Sie sollten, wann immer das möglich ist, statische Paketlisten verwenden, da die Nutzer dann &man.grep.1; auf alle verfügbaren Ports anwenden können, um z.B. herauszufinden, von welchem eine bestimmte Datei installiert wurde. Dynamische Paketlisten sollten für komplexe Ports verwendet werden, bei denen sich die Liste abhängig von den gewählten Funktionen sehr stark ändern kann (wodurch die Pflege von statischen Listen unmöglich wird), oder Ports, welche die Paketliste abhängig von den Versionen verwendeter Abhängigkeiten verändern (z.B. Ports, die Ihre Dokumentation mit Javadoc erzeugen). Maintainer, die dynamische Paketlisten bevorzugen, werden dazu aufgefordert, neue Targets zu Ihren Ports hinzuzufügen, welche die pkg-plist-Datei erzeugen, sodass Benutzer den Inhalt überprüfen können. Automatisiertes Erstellen von Paketlisten Als Erstes sollten Sie sich vergewissern, dass der Port bis auf pkg-plist vollständig ist. Als Nächstes erstellen Sie einen temporären Verzeichnisbaum, in welchem Ihr Port installiert werden kann, und installieren Sie alle Abhängigkeiten. &prompt.root; mkdir /var/tmp/$(make -V PORTNAME) &prompt.root; mtree -U -f $(make -V MTREE_FILE) -d -e -p /var/tmp/$(make -V PORTNAME) &prompt.root; make depends PREFIX=/var/tmp/$(make -V PORTNAME) Speichern Sie die Verzeichnisstruktur in einer neuen Datei. &prompt.root; (cd /var/tmp/$(make -V PORTNAME) && find -d * -type d) | sort > OLD-DIRS Erstellen Sie eine leere pkg-plist-Datei: &prompt.root; :>pkg-plist Wenn Ihr Port auf PREFIX achtet (was er machen sollte), so kann der Port nun installiert und die Paketliste erstellt werden. &prompt.root; make install PREFIX=/var/tmp/$(make -V PORTNAME) &prompt.root; (cd /var/tmp/$(make -V PORTNAME) && find -d * \! -type d) | sort > pkg-plist Sie müssen auch alle neu erstellten Verzeichnisse in die Paketliste aufnehmen. &prompt.root; (cd /var/tmp/$(make -V PORTNAME) && find -d * -type d) | sort | comm -13 OLD-DIRS - | sort -r | sed -e 's#^#@dirrm #' >> pkg-plist Zu guter Letzt muss die Paketliste noch manuell aufgeräumt werden - es funktioniert eben nicht alles automatisch. Manualpages sollten im Makefile des Ports unter MANn aufgeführt sein und nicht in der Paketliste. Konfigurationsdateien des Benutzers sollten entfernt oder als filename.sample installiert werden. Die info/dir-Datei sollte nicht aufgeführt sein und die zugehörigen install-info-Zeilen sollten hinzugefügt werden, wie im info files-Abschnitt beschrieben. Alle Bibliotheken, die der Port installiert, sollten aufgelistet werden, wie es im Shared Libraries-Abschnitt festgelegt ist. Alternativ dazu können Sie das plist-Skript in /usr/ports/Tools/scripts/ verwenden, um die Paketliste automatisch zu erstellen. Das plist-Skript ist ein Ruby-Skript, das die meisten der in den vorangehenden Absätzen kurz dargestellten manuellen Schritte automatisiert. Der erste Schritt ist derselbe wie oben: Nehmen Sie die ersten drei Zeilen, also mkdir, mtree und make depends. Installieren und bauen Sie dann den Port: &prompt.root; make install PREFIX=/var/tmp/$(make -V PORTNAME) Und lassen Sie plist die pkg-plist-Datei erstellen: &prompt.root; /usr/ports/Tools/scripts/plist -Md -m $(make -V MTREE_FILE) /var/tmp/$(make -V PORTNAME) > pkg-plist Die Paketliste muss immer noch von Hand aufgeräumt werden, wie es oben erklärt wurde. Ein weiteres Werkzeug zur Erzeugung einer ersten pkg-plist-Datei ist ports-mgmt/genplist. Wie bei jedem automatisierten Hilfswerkzeug, sollte die erzeugte pkg-plist-Datei überprüft und bei Bedarf von Hand nachbearbeitet werden. Die <filename>pkg-<replaceable>*</replaceable></filename> Dateien Es gibt noch einige Tricks mit pkg-*, die wir noch nicht erwähnt haben, die aber oft sehr praktisch sind. <filename>pkg-message</filename> Wenn Sie dem Anwender bei der Installation weitere Informationen anzeigen wollen, so können Sie diese Nachricht in pkg-message speichern. Diese Vorgehensweise ist oft nützlich, um zusätzliche Schritte anzuzeigen, die nach &man.pkg.add.1; durchgeführt werden müssen. Dadurch können Sie auch Lizenzinformationen darstellen. Wollen Sie nur ein paar Zeilen über die Einstellungen zum Erstellen des Ports oder Warnungen ausgeben, benutzen Sie ECHO_MSG. pkg-message ist nur für Schritte nach der Installation vorgesehen. Sie sollten den Unterschied zwischen ECHO_MSG und ECHO_CMD beachten: Ersteres wird benutzt, um Informationen auf dem Bildschirm auszugeben, während Letzteres für Kommando-Pipelining bestimmt ist. Ein gutes Beispiel für die Benutzung der beiden Befehle ist in shells/bash2/Makefile zu finden: update-etc-shells: @${ECHO_MSG} "updating /etc/shells" @${CP} /etc/shells /etc/shells.bak @( ${GREP} -v ${PREFIX}/bin/bash /etc/shells.bak; \ ${ECHO_CMD} ${PREFIX}/bin/bash) >/etc/shells @${RM} /etc/shells.bak Die pkg-message wird nicht zur pkg-plist hinzugefügt. Sie wird auch nicht automatisch angezeigt, falls ein Anwender den Port installiert. Sie müssen also die Ausgabe selbst im post-install-Ziel des Make-Vorgangs veranlassen. <filename>pkg-install</filename> Sollte es nötig sein, dass Ihr Port bei der Installation des Binärpakets mit &man.pkg.add.1; Befehle ausführt, können Sie das Skript pkg-install benutzen. Dieses Skript wird automatisch dem Paket hinzugefügt und zweimal von &man.pkg.add.1; ausgeführt: Zuerst als ${SH} pkg-install ${PKGNAME} PRE-INSTALL und beim zweiten Mal als ${SH} pkg-install ${PKGNAME} POST-INSTALL. $2 kann also getestet werden, um festzustellen, in welchem Modus das Skript ausgeführt wird. Die Umgebungsvariable PKG_PREFIX wird auf das Verzeichnis gesetzt, in welches das Paket installiert wird. Siehe &man.pkg.add.1; für weiterführende Informationen. Das Skript wird nicht automatisch ausgeführt, wenn Sie den Port mit make install installieren. Wenn Sie es ausführen lassen wollen, dann müssen Sie es im Makefile aufrufen: PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL. <filename>pkg-deinstall</filename> Dieses Skript wird ausgeführt, wenn ein Paket deinstalliert wird. Es wird zweimal von &man.pkg.delete.1; aufgerufen. Das erste Mal als ${SH} pkg-deinstall ${PKGNAME} DEINSTALL und dann als ${SH} pkg-deinstall ${PKGNAME} POST-DEINSTALL. <filename>pkg-req</filename> Muss Ihr Port entscheiden, ob er installiert werden soll oder nicht, können Sie ein pkg-req-Bedingungsskript verwenden. Dieses wird automatisch bei der Installation/ Deinstallation aufgerufen, um zu entscheiden, ob die Installation/ Deinstallation fortgesetzt werden soll. Das Skript wird während der Installation von &man.pkg.add.1; als pkg-req ${PKGNAME} INSTALL aufgerufen. Bei der Deinstallation wird es von &man.pkg.delete.1; als pkg-req ${PKGNAME} DEINSTALL ausgeführt. Ändern der Namen der <filename>pkg-<replaceable>*</replaceable></filename> Dateien Alle Namen der pkg-* Dateien werden durch Variablen festgelegt. Sie können sie bei Bedarf also im Makefile des Ports ändern. Das ist besonders nützlich, wenn Sie die gleichen pkg-* Dateien in mehreren Ports nutzen oder in eine der oben genannten Dateien schreiben wollen. Schreiben Sie niemals außerhalb des Unterverzeichnisses WRKDIR pkg-*, eine Erklärung hierzu finden Sie in Schreiben ausserhalb von WRKDIR. Hier ist eine Liste von Variablennamen und ihren Standardwerten (PKGDIR ist standardmäßig ${MASTERDIR}). Variable Standardwert DESCR ${PKGDIR}/pkg-descr PLIST ${PKGDIR}/pkg-plist PKGINSTALL ${PKGDIR}/pkg-install PKGDEINSTALL ${PKGDIR}/pkg-deinstall PKGREQ ${PKGDIR}/pkg-req PKGMESSAGE ${PKGDIR}/pkg-message Bitte benutzen Sie diese Variablen anstatt PKG_ARGS zu ändern. Wenn Sie PKG_ARGS modifizieren, werden diese Dateien bei der Installation des Ports nicht korrekt in /var/db/pkg installiert. Nutzung von <makevar>SUB_FILES</makevar> und <makevar>SUB_LIST</makevar> Die Variablen SUB_FILES und SUB_LIST sind nützlich, um dynamische Werte in Port-Dateien zu verwenden, wie beispielsweise der Installations-PREFIX in pkg-message. Die Variable SUB_FILES enthält eine Liste von Dateien, die automatisch verändert werden. Jede Datei in SUB_FILES muss ein entsprechendes Pendant datei.in im Verzeichnis FILESDIR haben. Die modifizierte Version wird in WRKDIR angelegt. Dateien, die als Werte von USE_RC_SUBR (oder veraltet in USE_RCORDER) gespeichert werden, werden automatisch zu SUB_FILES hinzugefügt. Für die Dateien pkg-message, pkg-install, pkg-deinstall und pkg-req werden die jeweiligen Makefile-Variablen selbsttätig auf die geänderte Version der Datei gesetzt. Die Variable SUB_LIST ist eine Liste von VAR=WERT-Paaren. Jedes Paar %%VAR%% in den Dateien von SUB_FILES wird mit WERT ersetzt. Einige gebräuchliche Paare werden automatisch definiert: PREFIX, LOCALBASE, DATADIR, DOCSDIR, EXAMPLESDIR. Jede Zeile, die mit @comment beginnt, wird nach der Variablen-Ersetzung aus der neu erstellten Datei gelöscht. Im folgenden Beispiel wird %%ARCH%% mit der Systemarchitektur in pkg-message ersetzt: SUB_FILES= pkg-message SUB_LIST= ARCH=${ARCH} Beachten Sie bitte, dass in diesem Beispiel die Datei pkg-message.in im Verzeichnis FILESDIR vorhanden sein muss. Hier ein Beispiel für eine gute pkg-message.in: Now it is time to configure this package. Copy %%PREFIX%%/share/examples/putsy/%%ARCH%%.conf into your home directory as .putsy.conf and edit it. Ihren Port testen <command>make describe</command> ausführen Einige der &os;-Werkzeuge zur Pflege von Ports, wie zum Beispiel &man.portupgrade.1;, verwenden eine Datenbank names /usr/ports/INDEX, welche Eigenschaften, wie z.B. Port-Abhängigkeiten, verfolgt. INDEX wird vom Makefile der höchsten Ebene, ports/Makefile, mittels make index erstellt, welches in das Unterverzeichnis jedes Ports wechselt und dort make describe ausführt. Wenn also make describe bei einem Port fehlschlägt, kann INDEX nicht generiert werden und schnell werden viele Leute darüber unzufrieden sein. Es ist wichtig diese Datei erzeugen zu können, unabhängig davon, welche Optionen in make.conf vorhanden sind. Bitte vermeiden Sie es daher beispielsweise .error-Anweisungen zu benutzen, wenn zum Beispiel eine Abhängigkeit nicht erfüllt wird (Lesen Sie dazu bitte ). Wenn make describe eine Zeichenkette anstatt einer Fehlermeldung erzeugt, sind Sie wahrscheinlich auf der sicheren Seite. Vergleichen Sie die erzeugte Zeichenkette mit bsd.port.mk, um mehr über deren Bedeutung zu erfahren. Beachten Sie bitte außerdem, dass die Benutzung einer aktuellen Version von portlint (wie im nächsten Abschnitt beschrieben) automatisch make describe startet. Portlint Bitte überprüfen Sie Ihre Arbeit stets mit portlint, bevor Sie diese einreichen oder committen. portlint warnt Sie bei häufigen Fehlern, sowohl funktionaler als auch stilistischer Natur. Für einen neuen (oder repokopierten) Port ist portlint -A die gründlichste Variante; für einen bereits existierenden Port ist portlint -C ausreichend. Da portlint heuristische Methoden zur Fehlersuche benutzt, kann es vorkommen, dass Warnungen für Fehler erzeugt werden, die keine sind. Gelegentlich kann etwas, das als Problem angezeigt wird, aufgrund von Einschränkungen im Port-System nicht anders gelöst werden. Wenn es Zweifel gibt, fragen Sie am besten auf &a.ports; nach. Port Tools Das Programm ports-mgmt/porttools ist Teil der Ports-Sammlung. port ist das Front-End-Skript, das Ihnen dabei behilflich sein kann Ihre Arbeit als Tester zu vereinfachen. Um einen neuen Port zu testen oder einen bereits bestehenden Port zu aktualisieren, können Sie port test verwenden, damit die Tests, inklusive der portlint-Überprüfung, durchgeführt werden. Dieser Befehl spürt ausserdem alle nicht in pkg-plist enthaltenen Dateien auf und gibt eine Liste dieser aus. Hier ein Beispiel: &prompt.root; port test /usr/ports/net/csup <makevar>PREFIX</makevar> und <makevar>DESTDIR</makevar> PREFIX bestimmt, an welche Stelle der Port installiert werden soll. In der Regel ist dies/usr/local oder - /opt. Benutzer können - PREFIX setzen, wie sie wollen. Ihr Port + /opt, was jedoch anpassbar ist. Ihr Port muss sich an diese Variable halten. DESTDIR, wenn es vom Benutzer gesetzt wird, bestimmt die alternative Umgebung (in der Regel eine Jail oder ein installiertes System, welches an anderer Stelle als / eingehängt ist). Ein Port wird unter DESTDIR/PREFIX installiert und registriert sich in der Paket-Datenbank unter DESTDIR/var/db/pkg. Da DESTDIR mittels eines &man.chroot.8;-Aufrufs vom Ports-System automatisch gesetzt wird, brauchen Sie keine Änderungen oder besondere Pflege für DESTDIR-konforme Ports. Der Wert von PREFIX wird auf LOCALBASE gesetzt (Standard ist /usr/local). Falls USE_LINUX_PREFIX gesetzt ist, wird PREFIX LINUXBASE annehmen (Standard ist /compat/linux). Die Vermeidung der hart kodierten Angaben von /usr/local oder /usr/X11R6 im Quelltext wird den Port viel flexibler machen und erleichtert es die Anforderungen anderer Einsatzorte zu erfüllen. Für X-Ports, die imake benutzen, geschieht dies automatisch; andernfalls kann dies erreicht werden, indem alle Angaben von /usr/local (oder /usr/X11R6 für X-Ports, die nicht imake benutzen) in den verschiedenen Makefiles im Port ersetzt werden, um ${PREFIX} zu lesen, da diese Variable automatisch an jede Stufe des Build- und Install-Prozesses übergeben wird. Vergewissern Sie sich bitte, dass Ihre Anwendung nichts unter /usr/local an Stelle von PREFIX installiert. Um dies festzustellen, können Sie folgendes machen: &prompt.root; make clean; make package PREFIX=/var/tmp/$(make -V PORTNAME) Wenn etwas außerhalb von PREFIX installiert wird, so gibt der Prozess der Paketerstellung eine Meldung aus, dass es die Dateien nicht finden kann. Dies prüft nicht das Vorhandensein eines internen Verweises oder die richtige Verwendung von LOCALBASE für Verweise auf Dateien anderer Ports. Das Testen der Installation in /var/tmp/$(make -V PORTNAME) würde dies erledigen. Die Variable PREFIX kann in Ihrem Makefile oder der Umgebung des Benutzers neu gesetzt werden. Allerdings wird für einzelne Ports dringend davon abgeraten diese Variable in den Makefiles direkt zu setzen. Verweisen Sie bitte außerdem auf Programme/Dateien von anderen Ports durch die oben erwähnten Variablen und nicht mit den eindeutigen Pfadnamen. Wenn Ihr Port zum Beispiel vom Makro PAGER erwartet, dass es den vollständigen Pfadnamen von less enthält, benutzen Sie folgendes Compiler-Flag: -DPAGER=\"${LOCALBASE}/bin/less\" anstatt -DPAGER=\"/usr/local/bin/less\". Somit ist die Wahrscheinlichkeit höher, dass es auch funktioniert, wenn der Administrator den ganzen /usr/local-Baum an eine andere Stelle verschoben hat. Die Tinderbox Wenn Sie ein begeisterter Ports-Entwickler sind möchten Sie vielleicht einen Blick auf die Tinderbox werfen. Es ist ein leistungsstarkes System zur Erstellung und zum Testen von Ports, welches auf Skripten basiert, die auf Pointyhat verwendet werden. Sie können Tinderbox installieren, indem Sie den Port ports-mgmt/tinderbox benutzen. Bitte lesen Sie die mitgelieferte Dokumentation gründlich, da die Konfiguration nicht einfach ist. Um Näheres darüber zu erfahren, besuchen Sie bitte die Tinderbox Homepage. Einen Port aktualisieren Wenn Sie feststellen, dass ein Port verglichen mit der neuesten Version des Originalautors nicht mehr auf dem aktuellen Stand ist, sollten Sie als Erstes sicherstellen, dass Sie die aktuellste Version des Ports haben. Diese finden Sie im Verzeichnis ports/ports-current der FreeBSD FTP-Spiegelseiten. Wenn Sie allerdings mit mehr als ein paar Ports arbeiten, werden Sie es wahrscheinlich einfacher finden CVSup zu benutzen, um Ihre gesamte Ports-Sammlung aktuell zu halten, wie es im Handbuch beschrieben wird. Das hat zusätzlich den Vorteil, dass Sie so auch alle Abhängigkeiten des Ports aktuell halten. Der nächste Schritt besteht darin festzustellen, ob bereits eine Aktualisierung des Ports darauf wartet committet zu werden. Um das sicherzustellen haben Sie folgende Möglichkeiten. Es gibt eine durchsuchbare Schnittstelle zur FreeBSD Problembericht Datenbank (PR - Problem Report) (auch bekannt als GNATS). Wählen Sie dazu Ports im Drop-Down-Menü und geben Sie den Namen des Ports ein. Allerdings wird manchmal vergessen den Namen des Ports eindeutig im Feld für die Zusammenfassung anzugeben. In diesem Fall können Sie das FreeBSD Ports Monitoring System (auch bekannt als portsmon) nutzen. Dieses versucht PRs von Ports nach Portname zu sortieren. Um PRs nach einem bestimmten Port zu durchsuchen können Sie die Übersicht eines Ports verwenden. Wenn es keine wartenden PRs gibt, ist der nächste Schritt eine E-Mail an den Maintainer des Ports zu schicken, wie von make maintainer gezeigt wird. Diese Person arbeitet vielleicht schon an einer Aktualisierung, oder hat einen guten Grund den Port im Moment nicht zu aktualisieren (z.B. wegen Stabilitätsproblemen der neuen Version). Sie wollen sicher nicht die Arbeit des Maintainers doppelt machen. Beachten Sie bitte, dass für Ports ohne Maintainer ports@FreeBSD.org eingetragen ist. Das ist nur die allgemeine &a.ports;-Mailingliste, deshalb wird es in diesem Fall wahrscheinlich nicht helfen eine E-Mail dorthin zu schicken. Wenn Sie der Maintainer bittet die Aktualisierung zu erledigen, oder falls es keinen Maintainer gibt, haben Sie Gelegenheit FreeBSD zu helfen, indem Sie die Aktualisierung selbst bereitstellen. Bitte führen Sie die Änderungen durch und speichern Sie die Ausgabe des rekursiven diff des neuen und alten Portverzeichnisses (wenn Ihr verändertes Portverzeichnis z.B. superedit und das Original superedit.bak heißt, dann speichern Sie bitte die Ergebnisse von diff -ruN superedit.bak superedit). Sowohl vereinheitlichendes als auch kontextabhängiges diff (Auflistung der Unterschiede zweier Dateien) sind akzeptabel, aber im Allgemeinen bevorzugen Port-Committer vereinheitlichende diffs. Bitte beachten Sie die Verwendung der -N-Option. Dies ist der gebräuchliche Weg diff dazu zu bewegen korrekt damit umzugehen, neue Dateien anzulegen und alte zu löschen. Bevor Sie das diff einsenden überprüfen Sie bitte die Ausgabe, um sicherzugehen, dass die Änderungen sinnvoll sind. Um gängige Operationen mit Korrekturdateien zu vereinfachen, können Sie /usr/ports/Tools/scripts/patchtool.py benutzen. Aber lesen Sie bitte vorher /usr/ports/Tools/scripts/README.patchtool. Falls der Port keinen Maintainer hat und Sie ihn selbst aktiv benutzen, ziehen Sie bitte in Erwägung sich als Maintainer zu melden. &os; hat mehr als 2000 Ports ohne Maintainer und in diesem Bereich werden immer zusätzliche Freiwillige benötigt (Für eine ausführliche Beschreibung der Verantwortlichkeiten eines Maintainers lesen Sie bitte im Developer's Handbook nach). Der beste Weg uns das diff zu schicken ist mittels &man.send-pr.1; (Kategorie Ports). Wenn Sie der Maintainer des Ports sind, fügen Sie bitte [maintainer update] an den Anfang Ihrer Zusammenfassung und setzen Sie die Klasse des PR auf maintainer-update. Ansonsten sollte die Klasse des PR change-request sein. Bitte erwähnen Sie alle hinzugefügten oder gelöschten Dateien in der Nachricht, da diese beim Commit ausdrücklich an &man.cvs.1; übergeben werden müssen. Wenn das diff größer ist als 20 Kilobyte komprimieren und uuencoden Sie es bitte. Ansonsten können Sie es in den PR einfügen wie es ist. Bevor Sie den PR mit &man.send-pr.1; abschicken, sollten Sie den Abschnitt Den Problembericht schreiben im Artikel über Problemberichte lesen. Dieser enthält sehr viel mehr Informationen darüber, wie man nützliche Problemberichte verfasst. Wenn Sie Ihre Aktualisierung aufgrund von Sicherheitsbedenken oder eines schwerwiegenden Fehlers bereitstellen wollen, informieren Sie bitte das &a.portmgr;, um einen sofortigen Rebuild und eine Neuverteilung des Pakets Ihres Ports durchzuführen. Sonst werden ahnungslose Nutzer von &man.pkg.add.1; über mehrere Wochen die alte Version durch pkg_add -r installieren. Noch einmal: Bitte verwenden Sie &man.diff.1; und nicht &man.shar.1;, um Aktualisierungen existierender Ports zu senden. Nun, da Sie all das geschafft haben, werden Sie in nachlesen können, wie Sie den Port aktuell halten. Sicherheit der Ports Warum Sicherheit so wichtig ist Es finden sich immer wieder Fehler in Software. Die gefährlichsten davon sind wohl jene, die Sicherheitslücken öffnen. Technisch gesehen müssen diese Lücken geschlossen werden, indem die Fehler, die Sie verursacht haben, beseitigt werden. Aber die Vorgehensweisen, wie mit bloßen Fehlern und Sicherheitslücken umgegangen wird, sind sehr unterschiedlich. Ein typischer kleiner Fehler betrifft nur Nutzer, die eine bestimmte Kombination von Optionen aktiviert haben, die den Fehler auslöst. Der Entwickler wird letztendlich einen Patch herausgeben, gefolgt von einer neuen Version des Programms, die den Fehler nicht mehr enthält – jedoch wird die Mehrheit der Nutzer nicht sofort aktualisieren, da sie von diesem Fehler nicht betroffen sind. Ein kritischer Fehler, der zu Datenverlust führen kann, stellt ein schwerwiegendes Problem dar. Dennoch sind sich umsichtige Nutzer bewusst, dass Datenverlust verschiedene Ursachen – neben Softwarefehlern – haben kann, und machen deshalb Sicherungskopien wichtiger Daten. Zumal ein kritischer Fehler sehr schnell entdeckt wird. Bei einer Sicherheitslücke ist dies ganz anders. Erstens wird sie vielleicht jahrelang nicht entdeckt, da dies oftmals keine Fehlfunktion im Programm verursacht. Zweitens kann eine böswillige Person unerlaubten Zugriff auf ein unsicheres System erlangen, um empfindliche Daten zu verändern oder zu zerstören; im schlimmsten Fall findet der Nutzer nicht einmal die Ursache des Schadens. Drittens hilft der Zugriff auf ein unsicheres System dem Angreifer oft in ein anderes System einzudringen, welches ansonsten nicht gefährdet wäre. Deshalb reicht es nicht aus eine Sicherheitslücke nur zu schließen: Die Zielgruppe sollte möglichst genau und umfassend darüber informiert werden, damit sie die Gefahr einschätzen und passende Maßnahmen ergreifen können. Sicherheitslücken schliessen Bei Ports und Paketen kann eine Sicherheitslücke im ursprünglichen Programm oder in den Port-Dateien verursacht werden. Im ersten Fall wird der ursprüngliche Entwickler den Fehler wahrscheinlich umgehend korrigieren oder eine neue Version herausgeben und Sie müssen den Port nur aktualisieren und die Korrekturen des Autors beachten. Falls sich die Korrektur aus irgendeinem Grund verzögert, sollten Sie den Port als FORBIDDEN markieren oder selbst den Fehler für den Port korrigieren. Falls die Sicherheitslücke im Port verursacht wird, sollten Sie ihn sobald wie möglich berichtigen. In jedem Fall sollte die Standardvorgehensweise zum Einreichen von Änderungen beachtet werden – es sei denn, Sie haben das Recht diese direkt in den Ports-Baum zu committen. Ports-Committer zu sein ist nicht genug, um Änderungen an einem beliebigen Port zu committen. Bitte denken Sie daran, dass Ports üblicherweise Maintainer haben, die Sie respektieren sollten. Bitte stellen Sie sicher, dass die Revision des Ports erhöht wird, sobald die Sicherheitslücke geschlossen wurde. Dadurch sehen die Nutzer, die installierte Pakete regelmäßig aktualisieren, dass es an der Zeit ist eine Aktualisierung durchzuführen. Außerdem wird ein neues Paket gebaut, über FTP– und WWW-Spiegel verteilt und die unsichere Version damit verdrängt. PORTREVISION sollte erhöht werden – es sei denn, PORTREVISION hat sich im Laufe der Korrektur des Fehlers geändert. Das heißt, Sie sollten PORTREVISION erhöhen, wenn Sie eine Korrektur hinzugefügt haben. Sie sollten diese aber nicht erhöhen, wenn Sie den Port auf die neueste Version des Programms gebracht haben und PORTREVISION somit schon verändert wurde. Bitte beachten Sie den betreffenden Abschnitt für weitere Informationen. Die Community informiert halten Die VuXML-Datenbank Ein sehr wichtiger und dringender Schritt, den man unternehmen muss, sobald eine Sicherheitslücke entdeckt wurde, ist die Gemeinschaft der Anwender des Ports über die Gefahr zu informieren. Diese Benachrichtigung hat zwei Gründe. Erstens wird es sinnvoll sein, wenn die Gefahr wirklich so groß ist, sofort Abhilfe zu schaffen, indem man z.B. den betreffenden Netzwerkdienst beendet oder den Port komplett deinstalliert, bis die Lücke geschlossen wurde. Und Zweitens pflegen viele Nutzer installierte Pakete nur gelegentlich zu aktualisieren. Sie werden aus der Mitteilung erfahren, dass Sie das Paket, sobald eine Korrektur verfügbar ist, sofort aktualisieren müssen. Angesichts der riesigen Zahl an Ports kann nicht für jeden Vorfall ein Sicherheitshinweis erstellt werden, ohne durch die Flut an Nachrichten die Aufmerksamkeit der Empfänger zu verlieren, im Laufe der Zeit kommt es so zu ernsten Problemen. Deshalb werden Sicherheitslücken von Ports in der FreeBSD VuXML-Datenbank aufgezeichnet. Das Team der Sicherheitsverantwortlichen beobachtet diese wegen Angelegenheiten, die Ihr Eingreifen erfordern. Wenn Sie Committerrechte haben, können Sie die VuXML-Datenbank selbst aktualisieren. Auf diese Weise helfen Sie den Sicherheitsverantwortlichen und liefern die kritischen Informationen frühzeitig an die Community. Aber auch wenn Sie kein Committer sind und glauben, Sie haben eine außergewöhnlich schwerwiegende Lücke gefunden – egal welche – zögern Sie bitte nicht die Sicherheitsverantwortlichen zu kontaktieren, wie es in den FreeBSD Sicherheitsinformationen beschrieben wird. In Ordnung, Sie haben sich also für den schwierigen Weg entschieden. Wie vielleicht aus dem Titel hervorgeht, ist die VuXMl-Datenbank hauptsächlich ein XML-Dokument. Die Quelldatei vuln.xml können Sie im Port security/vuxml finden. Deshalb wird der komplette Pfadname PORTSDIR/security/vuxml/vuln.xml lauten. Jedes Mal, wenn Sie eine Sicherheitslücke in einem Port entdecken, fügen Sie bitte einen Eintrag dafür in diese Datei ein. Solange Sie nicht mit VuXML vertraut sind, ist es das Beste, was Sie machen können, einen vorhandenen Eintrag, der zu Ihrem Fall passt, zu kopieren und als Vorlage zu verwenden. Eine kurze Einführung in VuXML Das komplette XML ist komplex und würde den Rahmen dieses Buches sprengen. Allerdings benötigen Sie für einen grundlegenden Einblick in die Struktur eines VuXML-Eintrags nur eine Vorstellung der Tags. XML-Tags bestehen aus Namen, die in spitzen Klammern eingeschlossen sind. Zu jedem öffnenden <Tag> muss ein passendes </Tag> existieren. Tags können geschachtelt werden. Wenn sie geschachtelt werden müssen die inneren Tags vor den Äußeren geschlossen werden. Es gibt eine Hierarchie von Tags – das heißt komplexere Regeln zur Schachtelung. Klingt so ähnlich wie HTML, oder? Der größte Unterschied ist: XML ist erweiterbar (eXtensible) – das heißt es basiert darauf maßgeschneiderte Tags zu definieren. Aufgrund seiner wesentlichen Struktur bringt XML ansonsten formlose Daten in eine bestimmte Form. VuXML ist speziell darauf zugeschnitten Beschreibungen von Sicherheitslücken zu verwalten. Lassen Sie uns nun einen realistischen VuXML-Eintrag betrachten: <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <topic>Several vulnerabilities found in Foo</topic> <affects> <package> <name>foo</name> <name>foo-devel</name> <name>ja-foo</name> <range><ge>1.6</ge><lt>1.9</lt></range> <range><ge>2.*</ge><lt>2.4_1</lt></range> <range><eq>3.0b1</eq></range> </package> <package> <name>openfoo</name> <range><lt>1.10_7</lt></range> <range><ge>1.2,1</ge><lt>1.3_1,1</lt></range> </package> </affects> <description> <body xmlns="http://www.w3.org/1999/xhtml"> <p>J. Random Hacker reports:</p> <blockquote cite="http://j.r.hacker.com/advisories/1"> <p>Several issues in the Foo software may be exploited via carefully crafted QUUX requests. These requests will permit the injection of Bar code, mumble theft, and the readability of the Foo administrator account.</p> </blockquote> </body> </description> <references> <freebsdsa>SA-10:75.foo</freebsdsa> <freebsdpr>ports/987654</freebsdpr> <cvename>CAN-2010-0201</cvename> <cvename>CAN-2010-0466</cvename> <bid>96298</bid> <certsa>CA-2010-99</certsa> <certvu>740169</certvu> <uscertsa>SA10-99A</uscertsa> <uscertta>SA10-99A</uscertta> <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> <url>http://j.r.hacker.com/advisories/1</url> </references> <dates> <discovery>2010-05-25</discovery> <entry>2010-07-13</entry> - <modified>2010-09-17</entry> + <modified>2010-09-17</modified> </dates> </vuln> Die Namen der Tags sollten selbsterklärend sein  – also werfen wir einen genaueren Blick auf die Felder, die Sie selbst ausfüllen müssen: Dies ist die höchste Tag-Ebene eines VuXML-Eintrags. Es ist ein vorgeschriebenes Attribut vid, welches eine allgemein einzigartige Kennung (universally unique identifier, UUID) in Anführungszeichen für diesen Eintrag festlegt. Sie sollten eine UUID für jeden neuen VuXML-Eintrag erzeugen (und vergessen Sie nicht die UUID der Vorlage zu ersetzen, es sei denn, Sie schreiben den Eintrag von Grund auf selbst). Sie können &man.uuidgen.1; verwenden, um eine VuXML UUID zu erzeugen. Wahlweise können Sie, wenn Sie FreeBSD 4.x verwenden, den Port devel/p5-Data-UUID verwenden und folgenden Befehl aufrufen: perl -MData::UUID -le 'print lc new Data::UUID->create_str' Dies ist eine einzeilige Beschreibung des gefundenen Fehlers. Hier werden die Namen betroffener Pakete aufgeführt. Es können mehrere Namen angegeben werden, da mehrere Pakete von einem einzigen Master-Port oder Software-Produkt abhängen können. Das schließt Stable– und Developement-Zweige, lokalisierte Versionen und Slave-Ports ein, die verschiedene Auswahlmöglichkeiten wichtiger Kompilierungszeit-Optionen bieten. Es liegt in Ihrer Verantwortung all diese betroffenen Pakete zu finden, wenn Sie den VuXML-Eintrag schreiben.Behalten Sie im Hinterkopf, dass make search name=foo Ihr Freund ist. Die wichtigsten Punkte, auf die Sie achten sollten, sind die folgenden: die foo-devel Variante eines foo Ports; andere Varianten mit einem Suffix wie -a4 (für Druck-betreffende Pakete), -without-gui (für Pakete mit deaktivierter X-Unterstützung) oder ähnliche jp-, ru-, zh- und andere, eventuell lokalisierte, Varianten in den entsprechenden Länderkategorien der Ports-Sammlung Betroffene Versionen der Pakete werden hier als ein Bereich oder mehrere durch eine Kombination aus <lt>, <le> , <eq>, <ge>, und <gt>-Elementen ausgegeben. Die angegebenen Bereiche sollten sich nicht überschneiden. In einer Bereichsangabe steht * (Asterisk) für die kleinste Versionsnummer. Insbesondere ist 2.* kleiner als 2.a. Deshalb kann ein Stern benutzt werden, um auf alle möglichen Alpha -, Beta– und RC -Versionen zuzutreffen. Zum Beispiel passt <ge>2.*</ge><lt>3.* </lt> auf alle Versionen der Form 2.x, während <ge> 2.0</ge><lt>3.0</lt> das nicht erfüllt, da es nicht auf 2.r3 passt, auf 3.b aber schon. Das obige Beispiel legt fest, dass Versionen von 1.6 bis 1.9 betroffen sind – außerdem Versionen 2.x vor 2.4_1 und Version 3.0b1. Mehrere zusammenhängende Gruppen von Paketen (im wesentlichen Ports) können im Abschnitt <affected> aufgeführt werden. Das kann man benutzen, wenn sich Programme (sagen wir FooBar, FreeBar und OpenBar) denselben Quelltext als Grundlage haben und sich noch dessen Fehler und Sicherheitslücken teilen. Beachten Sie den Unterschied zum Anführen mehrerer Namen innerhalb eines <package> Abschnittes. Die Versionsbereiche sollten, wenn möglich, sowohl PORTEPOCH als auch PORTREVISION erlauben. Bitte denken Sie daran, dass gemäß der Vergleichsregeln eine Version mit einer PORTEPOCH, die nicht Null ist, größer ist als jede Version ohne PORTEPOCH. Das heißt, 3.0,1 ist größer als 3.1 oder sogar 8.9. Das ist die Zusammenfassung des Problems. In diesem Feld wird XHTML verwendet. Zumindest umschließende <p> und </p> sollten auftauchen. Komplexere Tags sind zwar möglich, aber sollten nur um der Genauigkeit und Klarheit willen verwendet werden: Bitte verwenden Sie hier kein Eye-Candy. Dieser Abschnitt enthält Verweise auf relevante Dokumente. Es wird empfohlen so viele Referenzen wie nötig aufzuführen. Das ist ein FreeBSD Sicherheitshinweis. Das ist ein FreeBSD Problembericht. Das ist eine Mitre CVE Kennung. Das ist eine SecurityFocus Fehler-Kennung. Das ist ein Sicherheitshinweis von US-CERT. Das ist eine Mitteilung über eine Schwachstelle von US-CERT. Das ist ein Cyber-Sicherheitsalarm von US-CERT. Das ist ein technischer Cyber-Sicherheitsalarm von US-CERT. Das ist eine URL zu einem archivierten Posting auf einer Mailingliste. Das Attribut msgid ist optional und gibt die Nachrichtenkennung des Postings an. Das ist eine gewöhnliche URL. Sie sollte nur verwendet werden, wenn keine der anderen Referenzkategorien verfügbar ist. Das ist das Datum, an dem die Sicherheitslücke bekannt wurde (JJJJ-MM-TT). Das ist das Datum, an dem der Eintrag hinzugefügt wurde (JJJJ-MM-TT). Das ist das Datum, an dem zuletzt irgendeine Information des Eintrags verändert wurde (JJJJ-MM-TT). Neue Einträge dürfen dieses Feld nicht enthalten. Es sollte beim Editieren eines existierenden Eintrags eingefügt werden. Ihre Änderungen an der VuXML-Datenbank testen Nehmen wir an, Sie haben gerade einen Eintrag für eine Sicherheitslücke in dem Paket clamav geschrieben oder ausgefüllt, die in der Version 0.65_7 korrigiert wurde. Als Voraussetzung sollten Sie eine neue Version der Ports ports-mgmt/portaudit und ports-mgmt/portaudit-db installieren. Zuerst überprüfen Sie bitte, ob bereits ein Eintrag für diese Schwachstelle existiert. Wenn es einen solchen Eintrag gibt, sollte er auf die vorige Version 0.65_6 zutreffen: &prompt.user; packaudit &prompt.user; portaudit clamav-0.65_6 Um packaudit auszuführen, müssen Sie die Berechtigung haben DATABASEDIR zu schreiben – üblicherweise ist das /var/db/portaudit. Wenn keine vorhandenen Einträge gefunden werden haben Sie grünes Licht einen neuen Eintrag für diese Sicherheitslücke anzulegen. Sie können nun eine neue UUID erzeugen (wir nehmen an, diese lautet 74a9541d-5d6c-11d8-80e3-0020ed76ef5a) und einen neuen Eintrag in der VuXML-Datenbank anlegen. Bitte überprüfen Sie danach die Syntax mit folgendem Befehl: &prompt.user; cd ${PORTSDIR}/security/vuxml && make validate Sie werden zumindest eines der folgenden Pakete benötigen: textproc/libxml2, textproc/jade. Jetzt bauen Sie bitte die portaudit-Datenbank aus der VuXML-Datei neu: &prompt.user; packaudit Um sicherzustellen, dass der Abschnitt <affected> Ihres Eintrags die richtigen Pakete betrifft, verwenden Sie bitte den folgenden Befehl: &prompt.user; portaudit -f /usr/ports/INDEX -r 74a9541d-5d6c-11d8-80e3-0020ed76ef5a Bitte lesen Sie in &man.portaudit.1; nach, um ein besseres Verständnis der Befehlssyntax zu entwickeln. Bitte stellen Sie sicher, dass Ihr Eintrag keine falschen Treffer in der Ausgabe erzeugt. Jetzt überprüfen Sie bitte, dass Ihr Eintrag die richtigen Versionen des Pakets angibt: &prompt.user; portaudit clamav-0.65_6 clamav-0.65_7 Affected package: clamav-0.65_6 (matched by clamav<0.65_7) Type of problem: clamav remote denial-of-service. Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html> 1 problem(s) found. Offensichtlich sollte die erste Version ausgegeben werden – die zweite jedoch nicht. Abschließend überprüfen Sie bitte, ob die Webseite, die aus der VuXML-Datenbank erzeugt wird, wie erwartet aussieht: &prompt.user; mkdir -p ~/public_html/portaudit &prompt.user; packaudit &prompt.user; lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html Was man machen respektive vermeiden sollte Einführung Hier ist eine Liste von gebräuchlichen Dos and Don'ts (Dinge, die man machen oder vermeiden sollte), welchen Sie während des Portierungsprozesses begegnen werden. Sie sollten Ihren Port anhand dieser Liste überprüfen. Sie können auch Ports in der PR Datenbank, welche andere Menschen eingereicht haben, kontrollieren. Senden Sie bitte Kommentare zu Ports, die Sie verifizieren wie unter Bug Reports and General Commentary beschrieben. Der Abgleich von Ports aus der PR-Datenbank hilft uns diese schneller zu committen, und zeigt auch, dass Sie wissen, worum es geht. <makevar>WRKDIR</makevar> Schreiben Sie in keine Dateien außerhalb von WRKDIR. WRKDIR ist der einzige Ort, welcher während des Erstellen des Ports garantiert beschreibbar ist (siehe Ports Installieren von CDROM für ein Beispiel, um Ports in einem schreibgeschützen Zweig zu erstellen). Wenn Sie eine der pkg-* Dateien modifizieren müssen, sollten Sie eine Variable erneut definieren, anstatt die Datei zu überschreiben. <makevar>WRKDIRPREFIX</makevar> Vergewissern Sie sich, dass Ihr Port WRKDIRPREFIX beachtet. Die meisten Ports sollten sich darüber keine Sorgen machen. Beachten Sie bitte, falls auf WRKDIR eines anderen Ports verwiesen wird, dass die korrekte Position WRKDIRPREFIXPORTSDIR/subdir/name/work, und nicht etwa PORTSDIR/subdir/name/work, .CURDIR/../../subdir/name/work oder ähnliches ist. Falls Sie WRKDIR selbst definieren, sollten Sie sicherstellen, dass Sie ${WRKDIRPREFIX}${.CURDIR} am Anfang anfügen. Unterschiedliche Betriebssysteme und Betriebssystemversionen Sie können auf Quelltext treffen, welcher Modifizierungen oder bedingtes Kompilieren, abhängig davon, unter welcher Unix-Version er läuft, benötigt. Falls Sie Änderungen an solch einem Quelltext vornehmen müssen, stellen Sie bitte sicher, dass Sie Ihre Änderungen so allgemein wie möglich halten, damit wir den Quelltext auf ältere FreeBSD-Systeme portieren und zur Quer-Portierung auf andere BSD-Systeme, wie etwa 4.4BSD von CSRG, BSD/386, 386BSD, NetBSD und OpenBSD verwenden können. Der bevorzugte Weg, um 4.3BSD/Reno (1990) und neuere Versionen des BSD-Quelltextes zu unterscheiden, ist das BSD-Makro zu nutzen, welches in sys/param.h definiert ist. Hoffentlich ist diese Datei schon enthalten – falls nicht, so fügen Sie folgenden Quelltext: #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif an der richtigen Stelle in der .c Datei hinzu. Wir glauben, dass jedes System, welches diese beiden Symbole definiert, die Datei sys/param.h besitzt. Wenn Sie auf Systeme stoßen, wo dies nicht so ist, würden wir gerne davon erfahren. Bitte senden Sie eine E-Mail an &a.ports;. Eine andere Möglichkeit zur Unterscheidung ist der GNU Autoconf-Stil: #ifdef HAVE_SYS_PARAM_H #include <sys/param.h> #endif Vergessen Sie nicht -DHAVE_SYS_PARAM_H zu den CFLAGS im Makefile hinzuzufügen, falls Sie diese Methode benutzen sollten. Sobald Sie sys/param.h hinzugefügt haben, können Sie mit Hilfe von #if (defined(BSD) && (BSD >= 199103)) unterscheiden, ob der Quelltext auf einer 4.3 Net2 Code-Basis oder neuer (z.B. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 und niedriger) kompiliert werden wird. Benutzen Sie: #if (defined(BSD) && (BSD >= 199306)) um zu differenzieren, ob der Quelltext auf der Basis von 4.4 Code oder neuer (z.B. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 oder höher) kompiliert werden wird. Der Wert des BSD-Makros ist 199506 für die 4.4BSD-Lite2 Codebasis. Beachten Sie bitte, dass dies hier nur der Information wegen angegeben ist. Das Makro sollte nicht dazu benutzt werden, um zwischen Versionen von FreeBSD, welche auf 4.4-Lite basieren, und Versionen, welche Änderungen von 4.4-Lite2 übernommen haben, zu unterscheiden. Das __FreeBSD__ Makro sollte stattdessen verwandt werden. Sparsam sollte eingesetzt werden: __FreeBSD__ ist in allen Versionen von FreeBSD definiert. Benutzen Sie dieses Makro, falls die Änderung(en), die Sie machen, nur FreeBSD betrifft. Portierungsfallen, wie der Gebrauch von sys_errlist[] gegenüber strerror() sind Berkeley-Eigenheiten, keine FreeBSD Änderungen. In FreeBSD 2.x, ist __FreeBSD__ auf 2 definiert. In älteren Versionen, ist es 1. Alle späteren Versionen erhöhen es, damit es mit der Haupt-Versionsnummer übereinstimmt. Falls Sie zwischen einem FreeBSD 1.x und einem FreeBSD 2.x (oder höher) System unterscheiden müssen, ist es normalerweise richtig, die BSD-Makros (wie oben beschrieben) zu benutzen. Gibt es tatsächlich eine FreeBSD-spezifische Änderung (wie z.B. spezielle Optionen von Shared-Libraries für ld), ist es nicht zu beanstanden __FreeBSD__ und #if __FreeBSD__ > 1 zu nutzen, um FreeBSD 2.x und spätere Systeme zu erkennen. Falls Sie eine höhere Genauigkeit benötigen, um FreeBSD Systeme seit 2.0-RELEASE zu erkennen, können Sie folgendes nutzen: #if __FreeBSD__ >= 2 #include <osreldate.h> # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif In den Tausenden von Ports, die bis jetzt erstellt wurden, gab es nur ein oder zwei Fälle, in denen __FreeBSD__ hätte benutzt werden sollen. Nur weil ein früherer Port es an der falschen Stelle benutzt hatte, bedeutet das nicht, dass Sie dies auch machen sollten. __FreeBSD_version Werte Hier ist eine praktische Liste von __FreeBSD_version-Werten wie in sys/param.h definiert: __FreeBSD_version-Werte Wert Datum Release 119411 2.0-RELEASE 199501, 199503 19. März 1995 2.1-CURRENT 199504 9. April 1995 2.0.5-RELEASE 199508 26. August 1995 2.2-CURRENT vor 2.1 199511 10. November 1995 2.1.0-RELEASE 199512 10. November 1995 2.2-CURRENT vor 2.1.5 199607 10. Juli 1996 2.1.5-RELEASE 199608 12. Juli 1996 2.2-CURRENT vor 2.1.6 199612 15. November 1996 2.1.6-RELEASE 199612 2.1.7-RELEASE 220000 19. Februar 1997 2.2-RELEASE (nicht geändert) 2.2.1-RELEASE (nicht geändert) 2.2-STABLE nach 2.2.1-RELEASE 221001 15. April 1997 2.2-STABLE nach texinfo-3.9 221002 30. April 1997 2.2-STABLE nach top 222000 16. Mai 1997 2.2.2-RELEASE 222001 19. Mai 1997 2.2-STABLE nach 2.2.2-RELEASE 225000 2. Oktober 1997 2.2.5-RELEASE 225001 20. November 1997 2.2-STABLE nach 2.2.5-RELEASE 225002 27. Dezember 1997 2.2-STABLE nach der Aufnahme von ldconfig -R 226000 24. März 1998 2.2.6-RELEASE 227000 21. Juli 1998 2.2.7-RELEASE 227001 21. Juli 1998 2.2-STABLE nach 2.2.7-RELEASE 227002 19. September 1998 2.2-STABLE nach &man.semctl.2; Änderung 228000 29. November 1998 2.2.8-RELEASE 228001 29. November 1998 2.2-STABLE nach 2.2.8-RELEASE 300000 19. Februar 1996 3.0-CURRENT vor &man.mount.2; Änderung 300001 24. September 1997 3.0-CURRENT nach &man.mount.2; Änderung 300002 2. Juni 1998 3.0-CURRENT nach &man.semctl.2; Änderung 300003 7. Juni 1998 3.0-CURRENT nach ioctl arg Änderungen 300004 3. September 1998 3.0-CURRENT nach ELF-Konvertierung 300005 16. Oktober 1998 3.0-RELEASE 300006 16. Oktober 1998 3.0-CURRENT nach 3.0-RELEASE 300007 22. Januar 1999 3.0-STABLE nach 3/4 Zweig 310000 9. Februar 1999 3.1-RELEASE 310001 27. März 1999 3.1-STABLE nach 3.1-RELEASE 310002 14. April 1999 3.1-STABLE nach Änderung der C++ Konstruktor/Destruktor-Reihenfolge 320000 3.2-RELEASE 320001 8. Mai 1999 3.2-STABLE 320002 29. August 1999 3.2-STABLE nach binär-inkompatibler IPFW und Socket-Änderungen 330000 2. September 1999 3.3-RELEASE 330001 16. September 1999 3.3-STABLE 330002 24. November 1999 3.3-STABLE nach Hinzufügen von &man.mkstemp.3; zur libc 340000 5. Dezember 1999 3.4-RELEASE 340001 17. Dezember 1999 3.4-STABLE 350000 20. Juni 2000 3.5-RELEASE 350001 12. Juli 2000 3.5-STABLE 400000 22. Januar 1999 4.0-CURRENT nach 3.4 Zweig 400001 20. Februar 1999 4.0-CURRENT nach der Änderung im Verhalten des dynamischen Linkers. 400002 13. März 1999 4.0-CURRENT nach Änderung der C++ Konstruktor/Destruktor Reihenfolge. 400003 27. März 1999 4.0-CURRENT nach funktionierendem &man.dladdr.3;. 400004 5. April 1999 4.0-CURRENT nach der __deregister_frame_info Fehlerbehebung für den dynamischen Linker (auch 4.0-CURRENT nach EGCS 1.1.2 Integration). 400005 27. April 1999 4.0-CURRENT nach &man.suser.9; API Änderung (auch 4.0-CURRENT nach newbus). 400006 31. Mai 1999 4.0-CURRENT nach Änderung der cdevsw-Registrierung. 400007 17. Juni 1999 4.0-CURRENT nach Hinzufügen von so_cred für Zugangsberechtigungen auf Socket-Ebene. 400008 20. Juni 1999 4.0-CURRENT nach Hinzufügen eines poll Syscall-Wrappers zur libc_r. 400009 20. Juli 1999 4.0-CURRENT nach der Änderung des Kernel dev_t-Typs zum struct specinfo-Zeiger. 400010 25. September 1999 4.0-CURRENT nach dem Beseitigen eines Fehlers in &man.jail.2;. 400011 29. September 1999 4.0-CURRENT nach der sigset_t Datentyp Änderung. 400012 15. November 1999 4.0-CURRENT nach dem Wechsel zum GCC 2.95.2-Compiler. 400013 4. Dezember 1999 4.0-CURRENT nach Hinzufügen der erweiterbaren Linux Mode ioctl-Routinen. 400014 18. Januar 2000 4.0-CURRENT nach dem OpenSSL-Import. 400015 27. Januar 2000 4.0-CURRENT nach der C++ ABI Änderung in GCC 2.95.2 von -fvtable-thunks zu -fno-vtable-thunks als Standard. 400016 27. Februar 2000 4.0-CURRENT nach OpenSSH-Import. 400017 13. März 2000 4.0-RELEASE 400018 17. März 2000 4.0-STABLE nach 4.0-RELEASE 400019 5. Mai 2000 4.0-STABLE nach der Einführung von verzögerten Prüfsummen. 400020 4. Juni 2000 4.0-STABLE nach dem Einpflegen des libxpg4-Quelltextes in die libc. 400021 8. Juli 2000 4.0-STABLE nach der Aktualisierung von Binutils auf 2.10.0, Änderungen der binären ELF-Markierungen, Aufnahme von tcsh ins Basissystem. 410000 14. Juli 2000 4.1-RELEASE 410001 29. Juli 2000 4.1-STABLE nach 4.1-RELEASE 410002 16. September 2000 4.1-STABLE nachdem &man.setproctitle.3; von der libutil in die libc verschoben wurde. 411000 25. September 2000 4.1.1-RELEASE 411001 4.1.1-STABLE nach 4.1.1-RELEASE 420000 31. Oktober 2000 4.2-RELEASE 420001 10. Januar 2001 4.2-STABLE nach Kombinaion von libgcc.a und libgcc_r.a und zugehörigen Änderungen der GCC-Bindungen. 430000 6. März 2001 4.3-RELEASE 430001 18. Mai 2001 4.3-STABLE nach der Einführung von wint_t. 430002 22. Juli 2001 4.3-STABLE nach dem Einpflegen der PCI Stromstatus-API. 440000 1. August 2001 4.4-RELEASE 440001 23. Oktober 2001 4.4-STABLE nach der Einführung von d_thread_t. 440002 4. November 2001 4.4-STABLE nach den Änderungen der mount-Struktur (betrifft Dateisystem-Kernelmodule). 440003 18. Dezember 2001 4.4-STABLE nachdem die Userland-Komponenten von smbfs importiert worden sind. 450000 20. Dezember 2001 4.5-RELEASE 450001 24. Februar 2002 4.5-STABLE nach der Umbenennung von Elementen der USB-Struktur. 450004 16. April 2002 4.5-STABLE nachdem die sendmail_enable &man.rc.conf.5; Variable geändert worden ist, um den Wert NONE zu akzeptieren. 450005 27. April 2002 4.5-STABLE nachdem XFree86 4 als Standard zum Bauen der Pakete benutzt wird. 450006 1. Mai 2002 4.5-STABLE nach dem Reparieren des Empfangsfilters, welcher anfällig für einfache DoS-Attacken war. 460000 21. Juni 2002 4.6-RELEASE 460001 21. Juni 2002 4.6-STABLE &man.sendfile.2; repariert, um mit der Dokumentation übereinzustimmen, und nicht mehr die Anzahl der gesendeten Header mit der Anzahl der Daten, welche aus der Datei geschickt werden, gegenzurechnen. 460002 19. Juli 2002 4.6.2-RELEASE 460100 26. Juni 2002 4.6-STABLE 460101 26. Juni 2002 4.6-STABLE nach dem Einfließen von `sed -i' aus CURRENT. 460102 1. September 2002 4.6-STABLE nach dem Einfließen von vielen neuen pkg_install-Funktionen aus HEAD (HEAD = die aktuellste und letzte Version des Quellverzeichnisbaumes). 470000 8. Oktober 2002 4.7-RELEASE 470100 9. Oktober 2002 4.7-STABLE 470101 10. November 2002 Beginn von generierten __std{in,out,err}p Referenzen statt __sF. Dies ändert std{in,out,err} von einem Ausdruck während des Kompilierens zu einem Laufzeitausdruck. 470102 23. Januar 2003 4.7-STABLE nach dem Einfliessen von mbuf-Änderungen, um m_aux mbufs mit denen von m_tag zu ersetzen 470103 14. Februar 2003 4.7-STABLE erhält OpenSSL 0.9.7 480000 30. März 2003 4.8-RELEASE 480100 5. April 2003 4.8-STABLE 480101 22. Mai 2003 4.8-STABLE nachdem &man.realpath.3; Thread-sicher gemacht wurde. 480102 10. August 2003 4.8-STABLE Änderung der 3ware-API in twe. 490000 27. Oktober 2003 4.9-RELEASE 490100 27. Oktober 2003 4.9-STABLE 490101 8. Januar 2004 4.9-STABLE nachdem e_sid zu der Struktur kinfo_eproc hinzugefügt wurde. 490102 4. Februar 2004 4.9-STABLE nach dem Einfliessen der libmap-Funktionalität für rtld. 491000 25. Mai 2004 4.10-RELEASE 491100 1. Juni 2004 4.10-STABLE 491101 11. August 2004 4.10-STABLE nach dem Einfliessen von Revision 20040629 der Paket-Werkzeuge aus CURRENT. 491102 16. November 2004 4.10-STABLE nach der Fehlerbehebung in der VM, um das Freigeben von fiktiven Speicherseiten korrekt zu handhaben. 492000 17. Dezember 2004 4.11-RELEASE 492100 17. Dezember 2004 4.11-STABLE 492101 18. April 2006 4.11-STABLE nach dem Hinzufügen von libdata/ldconfig Verzeichnissen zu den mtree-Dateien. 500000 13. März 2000 5.0-CURRENT 500001 18. April 2000 5.0-CURRENT nach Hinzufügen von zusätzlichen Feldern in den ELF-Headern und Ändern der Methode zur ELF-Markierung von Binärdateien. 500002 2. Mai 2000 5.0-CURRENT nach kld-Metadaten Änderungen. 500003 18. Mai 2000 5.0-CURRENT nach buf/bio Änderungen. 500004 26. Mai 2000 5.0-CURRENT nach binutils Aktualisierung. 500005 3. Juni 2000 5.0-CURRENT nach dem Einfliessen des libxpg4 Quelltextes in die libc und der Einführung der TASKQ-Schnittstelle. 500006 10. Juni 2000 5.0-CURRENT nach dem Hinzufügen der AGP-Schnittstellen. 500007 29. Juni 2000 5.0-CURRENT nach der Aktualisierung von Perl auf Version 5.6.0. 500008 7. Juli 2000 5.0-CURRENT nach der Aktualisierung des KAME-Quelltextes zu den 2000/07-Quellen. 500009 14. Juli 2000 5.0-CURRENT nach ether_ifattach() und ether_ifdetach() Änderungen. 500010 16. Juli 2000 5.0-CURRENT nachdem die mtree-Standards zurück zur ursprünglichen Variante geändert wurden; -L hinzugefügt, um Symlinks zu folgen. 500011 18. Juli 2000 5.0-CURRENT nachdem die kqueue-API geändert worden ist. 500012 2. September 2000 5.0-CURRENT nachdem &man.setproctitle.3; von libutil nach libc verschoben worden ist. 500013 10. September 2000 5.0-CURRENT nach dem ersten SMPng-Commit. 500014 4. Januar 2001 5.0-CURRENT nachdem <sys/select.h> nach <sys/selinfo.h> verschoben worden ist. 500015 10. Januar 2001 5.0-CURRENT nach dem Kombinieren von libgcc.a und libgcc_r.a und damit verbundene Änderungen an GCC-Bindungen. 500016 24. Januar 2001 5.0-CURRENT nach der Änderung das Zusammenbinden von libc und libc_r zu erlauben, womit die -pthread Option veraltet ist. 500017 18. Februar 2001 5.0-CURRENT nach dem Umschalten von struct ucred zu struct xucred, um die vom Kernel exportierte API für mount u.a.zu stabilisieren. 500018 24. Februar 2001 5.0-CURRENT nach dem Hinzufügen der CPUTYPE make Variable zum Kontrollieren von CPU-spezifischen Optimierungen. 500019 9. Juni 2001 5.0-CURRENT nach dem Verschieben von machine/ioctl_fd.h nach sys/fdcio.h 500020 15. Juni 2001 5.0-CURRENT nach der Umbenennung der locale-Namen. 500021 22. Juni 2001 5.0-CURRENT nach dem Bzip2-Import. Kennzeichnet auch, dass S/Key entfernt wurde. 500022 12. Juli 2001 5.0-CURRENT nach SSE Unterstützung. 500023 14. September 2001 5.0-CURRENT nach KSE-Meilenstein 2. 500024 1. Oktober 2001 5.0-CURRENT nach d_thread_t, und nachdem UUCP in die Ports verschoben worden ist. 500025 4. Oktober 2001 5.0-CURRENT nach Änderungen in der ABI bei der Weitergabe von Deskriptoren und Berechtigungen auf 64 Bit Plattformen. 500026 9. Oktober 2001 5.0-CURRENT nachdem XFree86 4 als Standard zum Erstellen der Pakete benutzt wird und die neue libc strnstr()-Funktion hinzugefügt wurde. 500027 10. Oktober 2001 5.0-CURRENT nachdem die neue libc strcasestr()-Funktion hinzugefügt wurde. 500028 14. Dezember 2001 5.0-CURRENT nachdem die Userland-Komponenten von smbfs importiert wurden. (nicht geändert) 5.0-CURRENT nachdem die neuen C99-Ganzzahlen mit spezifischer Breite hinzugefügt wurden. 500029 29. Januar 2002 5.0-CURRENT nachdem eine Änderung im Rückgabewert von &man.sendfile.2; gemacht wurde. 500030 15. Februar 2002 5.0-CURRENT nach der Einführung des Types fflags_t, welches die passende Größe für Dateiflags hat. 500031 24. Februar 2002 5.0-CURRENT nach der Umbenennung der USB elements-Struktur. 500032 16. März 2002 5.0-CURRENT nach der Einführung von Perl 5.6.1. 500033 3. April 2002 5.0-CURRENT nachdem die sendmail_enable &man.rc.conf.5; Variable geändert worden ist, um den Wert NONE zu akzeptieren. 500034 30. April 2002 5.0-CURRENT nachdem mtx_init() einen dritten Parameter entgegen nimmt. 500035 13. Mai 2002 5.0-CURRENT mit GCC 3.1. 500036 17. Mai 2002 5.0-CURRENT ohne Perl in /usr/src 500037 29. Mai 2002 5.0-CURRENT nach dem Hinzufügen von &man.dlfunc.3; 500038 24. Juli 2002 5.0-CURRENT nachdem die Typen von einigen Elementen der sockbuf-Struktur geändert wurden und nachdem die Struktur neu geordnet wurde. 500039 1. September 2002 5.0-CURRENT nach dem GCC 3.2.1 Import. Und auch nachdem die Header nicht mehr _BSD_FOO_T_ sondern _FOO_T_DECLARED benutzen. Dieser Wert kann auch als konservative Schätzung für den Beginn der Unterstützung des &man.bzip2.1; Pakets verwendet werden. 500040 20. September 2002 5.0-CURRENT nachdem verschiedene Änderungen an Plattenfunktionen gemacht wurden, um die Anhängigkeit von Interna der disklabel-Struktur zu entfernen. 500041 1. Oktober 2002 5.0-CURRENT nach dem Hinzufügen von &man.getopt.long.3; zur libc. 500042 15. Oktober 2002 5.0-CURRENT nach der Aktualisierung von Binutils auf 2.13, bei denen die FreeBSD-Emulation, vec und das Ausgabeformat geändert wurden. 500043 1. November 2002 5.0-CURRENT nach dem Hinzufügen schwacher pthread_XXX Stubs zur libc, womit libXThrStub.so veraltet ist. 5.0-RELEASE. 500100 17. Januar 2003 5.0-CURRENT nach dem Erstellen des RELENG_5_0-Zweiges 500101 19. Februar 2003 <sys/dkstat.h> ist leer und sollte nicht inkludiert werden. 500102 25. Februar 2003 5.0-CURRENT nach der Änderung in der d_mmap_t-Schnittstelle. 500103 26. Februar 2003 5.0-CURRENT nachdem taskqueue_swi geädert wurde, um ohne Giant zu arbeiten, und taskqueue_swi_giant hinzugefügt wurde, um Giant zu verwenden. 500104 27. Februar 2003 cdevsw_add() und cdevsw_remove() gibt es nicht länger. Auftauchen der MAJOR_AUTO-Allokationsmöglichkeit. 500105 4. März 2003 5.0-CURRENT nach der neuen cdevsw-Initialisierungsmethode. 500106 8. März 2003 devstat_add_entry() wurde durch devstat_new_entry() ersetzt. 500107 15. März 2003 Devstat Schnittstellenänderung; siehe sys/sys/param.h 1.149. 500108 15. März 2003 Token-Ring Schnittstellenänderungen. 500109 25. März 2003 Hinzufügen von vm_paddr_t. 500110 28. März 2003 5.0-CURRENT nachdem &man.realpath.3; Thread-sicher gemacht wurde. 500111 9. April 2003 5.0-CURRENT nachdem &man.usbhid.3; mit NetBSD synchronisiert wurde. 500112 17. April 2003 5.0-CURRENT nach der neuen NSS Implementierung und Hinzufügen der POSIX.1 getpw*_r, getgr*_r Funktionen. 500113 2. Mai 2003 5.0-CURRENT nach Entfernen des alten rc-Systems. 501000 4. Juni 2003 5.1-RELEASE. 501100 2. Juni 2003 5.1-CURRENT nach dem Erstellen des RELENG_5_1 Zweiges. 501101 29. Juni 2003 5.1-CURRENT nachdem die Semantik von sigtimedwait(2) and sigwaitinfo(2) korrigiert wurden. 501102 3. Juli 2003 5.1-CURRENT nach dem Hinzufügen der lockfunc und lockfuncarg-Felder zu &man.bus.dma.tag.create.9;. 501103 31. Juli 2003 5.1-CURRENT nach der Integration des GCC 3.3.1-pre 20030711 Snapshots. 501104 5. August 2003 5.1-CURRENT 3ware-API Änderungen in twe. 501105 17. August 2003 5.1-CURRENT Unterstützung von dynamisch gebundenen /bin und /sbin und Verschieben von Bibliotheken nach /lib. 501106 8. September 2003 5.1-CURRENT nachdem im Kernel Unterstützung für Coda 6.x hinzugefügt wurden. 501107 17. September 2003 5.1-CURRENT nachdem die 16550 UART-Konstanten von <dev/sio/sioreg.h> nach <dev/ic/ns16550.h> verschoben wurden. Und nachdem die libmap Funktionalität vorbehaltlos vom rtld unterstützt wurde. 501108 23. September 2003 5.1-CURRENT nach Aktualisierung der PFIL_HOOKS API. 501109 27. September 2003 5.1-CURRENT nachdem kiconv(3) hinzugefügt wurde. 501110 28. September 2003 5.1-CURRENT nachdem der standardmäßige Ablauf von open und close in cdevsw geändert wurde. 501111 16. Oktober 2003 5.1-CURRENT nachdem das Layout von cdevsw geändert wurde. 501112 16. Oktober 2003 5.1-CURRENT nach dem Hinzufügen von Mehrfachvererbung in kobj. 501113 31. Oktober 2003 5.1-CURRENT nach der if_xname Änderung in der Struktur ifnet 501114 16. November 2003 5.1-CURRENT nachdem /bin und /sbin geändert wurden, um sie dynamisch zu binden. 502000 7. Dezember 2003 5.2-RELEASE 502010 23. Februar 2004 5.2.1-RELEASE 502100 7. Dezember 2003 5.2-CURRENT nach dem Erstellen des RELENG_5_2-Zweiges. 502101 19. Dezember 2003 5.2-CURRENT nachdem die __cxa_atexit/__cxa_finalize Funktionen zur libc hinzugefügt wurden. 502102 30. Januar 2004 5.2-CURRENT nachdem die Standard-Thread Bibliothek von libc_r zu libpthread geändert wurde. 502103 21. Februar 2004 5.2-CURRENT nach dem Gerätetreiber API Megapatch. 502104 25. Februar 2004 5.2-CURRENT nachdem getopt_long_only() hinzugefügt wurde. 502105 5. März 2004 5.2-CURRENT nachdem NULL für C in ((void *)0) geändert wurde, was mehr Warnungen erzeugt. 502106 8. März 2004 5.2-CURRENT nachdem pf beim Bauen und Installieren mit eingebunden wird. 502107 10. März 2004 5.2-CURRENT nachdem time_t auf der sparc64-Plattform in einen 64-bit Wert geändert wurde. 502108 12. März 2004 5.2-CURRENT nachdem sich die Unterstützung für den Intel C/C++-Compiler in einigen Headern und execve(2) geändert hat, um sich strikter an POSIX zu halten. 502109 22. März 2004 5.2-CURRENT nach der Einführung der bus_alloc_resource_any API 502110 27. März 2004 5.2-CURRENT nach dem Hinzufügen von UTF-8 locales 502111 11. April 2004 5.2-CURRENT nach dem Entfernen der getvfsent(3) API 502112 13. April 2004 5.2-CURRENT nach dem Hinzufügen der .warning Directive für make. 502113 4. Juni 2004 5.2-CURRENT nachdem ttyioctl() zwingend erforderlich für serielle Treiber gemacht wurde. 502114 13. Juni 2004 5.2-CURRENT nach dem Import des ALTQ-Frameworks. 502115 14. Juni 2004 5.2-CURRENT nachdem sema_timedwait(9) geändert wurde, 0 bei Erfolg und einen von 0 verschiedenen Fehlercode im Falle eines Fehlers zurückzuliefern. 502116 16. Juni 2004 5.2-CURRENT nach dem Ändern der Kernel Struktur dev_t, in ein Zeiger auf die Struktur cdev * 502117 17. Juni 2004 5.2-CURRENT nach dem Ändern der Kernelstruktur udev_t in dev_t. 502118 17. Juni 2004 5.2-CURRENT nachdem Unterstützung für CLOCK_VIRTUAL und CLOCK_PROF zu clock_gettime(2) und clock_getres(2) hinzugefügt wurde. 502119 22. Juni 2004 5.2-CURRENT nachdem die Überprüfung des Klonens von Netzwerk-Schnittstellen geändert wurde. 502120 2. Juli 2004 5.2-CURRENT nach dem Einfliessen von Revision 20040629 der Paket-Werkzeuge. 502121 9. Juli 2004 5.2-CURRENT nachdem Bluetooth-Quelltext als nicht i386-spezifisch markiert wurde. 502122 11. Juli 2004 5.2-CURRENT nach der Einführung des KDB Debugger Frameworks, der Umwandlung des DDB in ein Backend und der Einführung des GDB-Backends. 502123 12. Juli 2004 5.2-CURRENT nachdem VFS_ROOT geändert wurde, eine Struktur thread als Argument zu aktzeptieren, wie vflush. Die Struktur kinfo_proc enthält nun einen Zeiger auf Benutzer Daten. Der Umstieg auf xorg als standardmäßige X Implementierung wurde auch zu dieser Zeit durchgeführt. 502124 24. Juli 2004 5.2-CURRENT nachdem die Art und Weise, wie rc.d-Skripte von Ports und Altlasten gestartet werden, getrennt wurde. 502125 28. Juli 2004 5.2-CURRENT nachdem die vorherige Änderung rückgängig gemacht wurde. 502126 31. Juli 2004 5.2-CURRENT nach dem Entfernen von kmem_alloc_pageable() und dem Import von GCC 3.4.2. 502127 2. August 2004 5.2-CURRENT nachdem die UMA Kernel API geändert wurde, um Konstruktoren und Initialisierungsmethoden zu erlauben fehlzuschlagen. 502128 8. August 2004 5.2-CURRENT nach der Änderung in der vfs_mount Signatur sowie allgemeines Ersetzen von PRISON_ROOT durch SUSER_ALLOWJAIL in der suser(9) API. 503000 23. August 2004 5.3-BETA/RC vor der Änderung der pfil-API. 503001 22. September 2004 5.3-RELEASE 503100 16. Oktober 2004 5.3-STABLE nach dem Erstellen des RELENG_5_3-Zweiges. 503101 3. Dezember 2004 5.3-STABLE nach dem Hinzufügen von Fülloptionen im Stile der libc zu &man.strftime.3;. 503102 13. Februar 2005 5.3-STABLE nachdem OpenBSD's nc(1) von CURRENT importiert wurde. 503103 27. Februar 2005 5.4-PRERELEASE nach dem Einfliessen der Reparaturen aus CURRENT, in <src/include/stdbool.h> und <src/sys/i386/include/_types.h>, um die GCC-Kompatibilität des Intel C/C++-Compilers zu benutzen. 503104 28. Februar 2005 5.4-PRERELEASE nach dem Einfliessen der Änderung aus CURRENT in ifi_epoch statt der lokalen Zeit die Betriebszeit des Systems zu benutzen. 503105 2. März 2005 5.4-PRERELEASE nach dem Einfliessen der Reparaturen von EOVERFLOW in vswprintf(3) aus CURRENT. 504000 3. April 2005 5.4-RELEASE. 504100 3. April 2005 5.4-STABLE nach dem Erstellen des RELENG_5_4-Zweiges. 504101 11. Mai 2005 5.4-STABLE nach dem Vergrößern der standardmäßigen Stackgröße für Threads. 504102 24. Juni 2005 5.4-STABLE nach dem Hinzufügen von sha256. 504103 3. Oktober 2005 5.4-STABLE nach dem Einfliessen von if_bridge aus CURRENT. 504104 13. November 2005 5.4-STABLE nach dem Einfliessen von bsdiff und portsnap aus CURRENT. 504105 17. Januar 2006 5.4-STABLE nach dem Einfliessen der Änderung von ldconfig_local_dirs aus CURRENT. 505000 12. Mai 2006 5.5-RELEASE. 505100 12. Mai 2006 5.5-STABLE nach dem Erstellen des RELENG_5_5-Zweiges. 600000 18. August 2004 6.0-CURRENT 600001 27. August 2004 6.0-CURRENT nach der festen Aktivierung von PFIL_HOOKS im Kernel. 600002 30. August 2004 6.0-CURRENT nach der anfänglichen Einführung von ifi_epoch zur Struktur if_data. Wurde nach ein paar Tagen wieder rückgängig gemacht. Benutzen Sie diesen Wert bitte nicht. 600003 8. September 2004 6.0-CURRENT nach dem erneuten Hinzufügen des Elements ifi_epoch zur Struktur if_data. 600004 29. September 2004 6.0-CURRENT nach dem Hinzufügen der Struktur inpcb als Argument in der pfil API. 600005 5. Oktober 2004 6.0-CURRENT nach dem Hinzufügen des "-d DESTDIR" Schalters zu newsyslog. 600006 4. November 2004 6.0-CURRENT nach dem Hinzufügen von Fülloptionen im Style der libc zu &man.strftime.3;. 600007 12. Dezember 2004 6.0-CURRENT nach dem Hinzufügen von 802.11 Framework Neuerungen. 600008 25. Januar 2005 6.0-CURRENT Änderung an den VOP_*VOBJECT() Funktionen und Einführung des MNTK_MPSAFE Schalters für Dateisysteme, welche ohne Giant arbeiten. 600009 4. Februar 2005 6.0-CURRENT nach dem Hinzufügen von cpufreq Framework und Treibern. 600010 6. Februar 2005 6.0-CURRENT nachdem OpenBSD's nc(1) importiert wurde. 600011 12. Februar 2005 6.0-CURRENT nachdem der Anschein von matherr() Unterstützung in SVID2 entfernt wurde. 600012 15. Februar 2005 6.0-CURRENT nach dem Vergrößern der standardmäßigen Stackgröße für Threads. 600013 19. Februar 2005 6.0-CURRENT nach dem Einfliessen der Reparaturen in <src/include/stdbool.h> und <src/sys/i386/include/_types.h>, um die GCC-Kompatibilität des Intel C/C++-Compilers zu benutzen. 600014 21. Februar 2005 6.0-CURRENT nachdem die Überprüfungen auf EOVERFLOW in vswprintf(3) korrigiert wurden. 600015 25. Februar 2005 6.0-CURRENT nach dem Einfliessen der Änderung, in ifi_epoch, statt der lokalen Zeit, die Betriebzeit des Systems zu benutzen. 600016 26. Februar 2005 6.0-CURRENT nachdem das Format von LC_CTYPE auf der Festplatte verändert wurde. 600017 27. Februar 2005 6.0-CURRENT nachdem das Format der NLS-Kataloge auf der Festplatte verändert wurde. 600018 27. Februar 2005 6.0-CURRENT nachdem das Format von LC_COLLATE auf der Festplatte verändert wurde. 600019 28. Februar 2005 Installation der acpica Include-Dateien in /usr/include. 600020 9. März 2005 Hinzufügen des MSG_NOSIGNAL Schalters zur send(2) API. 600021 17. März 2005 Hinzufügen von Feldern zu cdevsw 600022 21. März 2005 gtar wurde aus dem Basissystem entfernt. 600023 13. April 2005 Die Optionen LOCAL_CREDS, LOCAL_CONNWAIT für Sockets wurde zu unix(4) hinzugefügt. 600024 19. April 2005 &man.hwpmc.4; und zugehörige Werkzeuge wurden zu 6.0-CURRENT hinzugefügt. 600025 26. April 2005 Die Struktur icmphdr wurden zu 6.0-CURRENT hinzugefügt. 600026 3. Mai 2005 pf Aktualisierung auf 3.7. 600027 6. Mai 2005 Kernel libalias und ng_nat wurden eingeführt. 600028 13. Mai 2005 POSIX ttyname_r(3) wurde über unistd.h und libc zur Verfügung gestellt. 600029 29. Mai 2005 6.0-CURRENT nachdem libpcap zu Version v0.9.1 alpha 096 aktualisiert wurde. 600030 5. Juni 2005 6.0-CURRENT nach dem Import von NetBSDs if_bridge(4). 600031 10. Juni 2005 6.0-CURRENT nachdem die Struktur ifnet aus dem Treiber softcs herausgelöst wurde. 600032 11. Juli 2005 6.0-CURRENT nach dem Import von libpcap v0.9.1. 600033 25. Juli 2005 6.0-STABLE nachdem die Versionen aller gemeinsam genutzten Bibliotheken, welche seit RELENG_5 nicht geändert wurden, erhöht wurden. 600034 13. August 2005 6.0-STABLE nachdem das Argument credential zu der dev_clone-Ereignisbehandlung hinzugefügt wurde. 6.0-RELEASE. 600100 1. November 2005 6.0-STABLE nach dem Erstellen des 6.0-RELEASE-Zweiges. 600101 21. Dezember 2005 6.0-STABLE nach dem Aufnehmen von Skripten aus den local_startup-Verzeichnissen in &man.rcorder.8; des Basissystems. 600102 30. Dezember 2005 6.0-STABLE nach dem Aktualisieren der ELF-Typen und Konstanten. 600103 15. Januar 2006 6.0-STABLE nach dem Einfliessen der pidfile(3)-API aus CURRENT. 600104 17. Januar 2006 6.0-STABLE nach dem Einfliessen der Änderung von ldconfig_local_dirs aus CURRENT. 600105 26. Februar 2006 6.0-STABLE nach der NLS-Katalogunterstützung von csh(1). 601000 6. Mai 2006 6.1-RELEASE 601100 6. Mai 2006 6.1-STABLE nach 6.1-RELEASE. 601101 22. Juni 2006 6.1-STABLE nach dem Import von csup. 601102 11. Juli 2006 6.1-STABLE nach der iwi(4)-Aktualisierung. 601103 17. Juli 2006 6.1-STABLE nach der Aktualisierung der Namensauflösung zu BIND9 und Aufnahme der ablaufinvarianten Versionen der netdb-Funktionen. 601104 8. August 2006 6.1-STABLE nachdem Unterstützung für DSO (dynamic shared objects - gemeinsam genutzte, dynamische Objekte) in OpenSSL aktiviert wurde. 601105 2. September 2006 6.1-STABLE nachdem 802.11 Reparaturen die API der IEEE80211_IOC_STA_INFO ioctl geändert haben. 602000 15. November 2006 6.2-RELEASE 602100 15. September 2006 6.2-STABLE nach 6.2-RELEASE. 602101 12. Dezember 2006 6.2-STABLE nach dem Hinzufügen der Wi-Spy Eigenart. 602102 28. Dezember 2006 6.2-STABLE nachdem pci_find_extcap() hinzugefügt wurde. 602103 16. Januar 2007 6.2-STABLE nach dem Einpflegen der dlsym Änderung aus CURRENT, ein angefordertes Symbol sowohl in der spezifizierten dso, als auch in den impliziten Abhängigkeiten nachzuschlagen. 602104 28. Januar 2007 6.2-STABLE nach dem Einpflegen von ng_deflate(4) und ng_pred1(4) netgraph Knoten und neuen Kompressions- und -Verschlüsselungmodi für den ng_ppp(4) Knoten aus CURRENT. 602105 20. Februar 2007 6.2-STABLE nach dem Einpflegen der BSD lizensierten Version von &man.gzip.1;, welche von NetBSD portiert wurde aus CURRENT. 602106 31. März 2007 6.2-STABLE nach dem Einpflegen der PCI MSI und MSI-X Unterstützung aus CURRENT. 602107 6. April 2007 6.2-STABLE nach dem Einpflegen von ncurses 5.6 und Unterstützung für Multibyte-Zeichen aus CURRENT. 602108 11. April 2007 6.2-STABLE nach dem Einpflegen des 'SG' Peripheriegerätes aus CURRENT in CAM, welches einen Teil der SCSI SG passthrough Geräte API von Linux enthält. 602109 17. April 2007 6.2-STABLE nach dem Einpflegen von readline 5.2 Patchset 002 aus CURRENT. 602110 2. Mai 2007 6.2-STABLE nach dem Einpflegen von pmap_invalidate_cache(), pmap_change_attr(), pmap_mapbios(), pmap_mapdev_attr(), und pmap_unmapbios() für amd64 und i386 aus CURRENT. 602111 11. Juni 2007 6.2-STABLE nach dem Einpflegen von BOP_BDFLUSH aus CURRENT und dem daraus resultierendem Bruch mit dem Dateisystemmodul KBI. 602112 21. September 2007 6.2-STABLE nach dem Einpflegen von libutil(3) aus CURRENT. 602113 25. Oktober 2007 6.2-STABLE, nach der Trennung in "wide und single byte ctype". Neu kompilierte Binärdateien, die ctype.h referenzieren, erfordern möglicherweise ein neues Symbol, __mb_sb_limit, das auf älteren Systemen nicht verfügbar ist. 602114 30. Oktober 2007 6.2-STABLE, nachdem die ctype ABI-Aufwärtskompatibilität wiederhergestellt wurde. 602115 21. November 2007 FreeBSD 6.2-STABLE nach der Entfernung/Eliminierung der wide und single Byte ctype-Trennung 603000 25. November 2007 6.3-RELEASE 603100 25. November 2007 6.3-STABLE nach 6.3-RELEASE. 603101 7. Dezember 2007 6.3-STABLE, nachdem der Support für den Multibyte-Datentyp im Bit-Makro gefixt wurde. 603102 24. April 2008 6.3-STABLE nach Hinzufügen von l_sysid zu struct flock. 603103 27. Mai 2008 6.3-STABLE nach Einfließen der memrchr-Funktion. 603104 15. Juni 2008 6.3-STABLE nach Übernahme der Unterstützung von :u als Variablenwandler in make(1). 604000 4. Oktober 2008 6.4-RELEASE 604100 4. Oktober 2008 6.4-STABLE nach 6.4-RELEASE. 700000 11. Juli 2005 7.0-CURRENT. 700001 23. Juli 2005 7.0-CURRENT nachdem die Versionen aller gemeinsam genutzten Bibliotheken, welche seit RELENG_5 nicht geändert wurden, erhöht wurden. 700002 13. August 2005 7.0-CURRENT nachdem ein Berechtigungs-Argument zur dev_clone-Ereignisroutine hinzugefügt wurde. 700003 25. August 2005 7.0-CURRENT nachdem memmem(3) zur libc hinzugefügt wurde. 700004 30. Oktober 2005 7.0-CURRENT nachdem die Argumente der Kernelfunktion solisten(9) modifiziert wurden, um einen Backlog-Parameter (Anzahl der maximalen wartenden Verbindungen) zu akzeptieren. 700005 11. November 2005 7.0-CURRENT nachdem IFP2ENADDR() geändert wurde, einen Zeiger auf IF_LLADDR() zurückzugeben. 700006 11. November 2005 7.0-CURRENT nach dem Hinzufügen des if_addr-Elements zur Struktur ifnet und dem Entfernen von IFP2ENADDR(). 700007 2. Dezember 2005 7.0-CURRENT nach dem Aufnehmen von Skripten aus den local_startup Verzeichnissen in &man.rcorder.8; des Basissystems. 700008 5. Dezember 2005 7.0-CURRENT nach dem Entfernen der MNT_NODEV mount-Option. 700009 19. Dezember 2005 7.0-CURRENT nach ELF-64 Typen Änderungen und Symbol Versionierung. 700010 20. Dezember 2005 7.0-CURRENT nach Hinzufügen der hostb und vgapci Treiber, Hinzufügen von pci_find_extcap() und Änderung der AGP Treiber die Apertur nicht länger abzubilden. 700011 31. Dezember 2005 7.0-CURRENT nachdem auf allen Plattformen außer Alpha tv_sec in time_t umgewandelt wurde. 700012 8. Januar 2006 7.0-CURRENT nach Änderung von ldconfig_local_dirs. 700013 12. Januar 2006 7.0-CURRENT nach Änderung in /etc/rc.d/abi um /compat/linux/etc/ld.so.cache als Symlink in ein schreibgeschütztes Dateisystem zu unterstützen. 700014 26. Januar 2006 7.0-CURRENT nach pts Import. 700015 26. März 2006 7.0-CURRENT nach Einführung von Version 2 der &man.hwpmc.4;'s ABI. 700016 22. April 2006 7.0-CURRENT nach dem Hinzufügen von &man.fcloseall.3; zur libc. 700017 13. Mai 2006 7.0-CURRENT nach dem Entfernen von ip6fw. 700018 15. Juli 2006 7.0-CURRENT nach dem Import von snd_emu10kx. 700019 29. Juli 2006 7.0-CURRENT nach dem Import von OpenSSL 0.9.8b. 700020 3. September 2006 7.0-CURRENT nach dem Hinzufügen der bus_dma_get_tag-Funktion 700021 4. September 2006 7.0-CURRENT nach dem Import von libpcap 0.9.4 und tcpdump 3.9.4. 700022 9. September 2006 7.0-CURRENT nach der dlsym Änderung, ein angefordertes Symbol sowohl in der spezifizierten dso, als auch in den impliziten Abhängigkeiten nachzuschlagen. 700023 23. September 2006 7.0-CURRENT nach dem Hinzufügen neuer Sound-IOCTLs für die OSSv4-Mixer-API. 700024 28. September 2006 7.0-CURRENT nach dem Import von OpenSSL 0.9.8d. 700025 11. November 2006 7.0-CURRENT nach dem Hinzufügen der libelf. 700026 26. November 2006 7.0-CURRENT nach größeren Änderungen an den Sound sysctls. 700027 30. November 2006 7.0-CURRENT nach dem Hinzufügen der Wi-Spy-Eigenart. 700028 15. Dezember 2006 7.0-CURRENT nach dem Hinzufügen von sctp-Aufrufen zur libc. 700029 26. Januar 2007 7.0-CURRENT nach dem Ersetzen von GNU &man.gzip.1; durch eine von NetBSD portierte Version, die unter BSD-Lizenz steht. 700030 7. Februar 2007 7.0-CURRENT nach dem Entfernen der IPIP Tunnelkapselung (VIFF_TUNNEL) aus dem IPv4 Multicast-Forwarding-Quelltext. 700031 23. Februar 2007 7.0-CURRENT nach den Modifizierungen an bus_setup_intr() (newbus). 700032 2. März 2007 7.0-CURRENT nach der Aufnahme der Firmware für ipw(4) und iwi(4). 700033 9. März 2007 7.0-CURRENT nach Unterstützung für Multibyte-Zeichen. 700034 19. März 2007 7.0-CURRENT nach Änderungen, wie insmntque(), getnewvnode() und vfs_hash_insert() arbeiten. 700035 26. März 2007 7.0-CURRENT nach Hinzufügen eines Benachrichtigungsmechanismus für CPU Frequenzänderungen. 700036 6. April 2007 7.0-CURRENT nach dem Import des ZFS Dateisystemes. 700037 8. April 2007 7.0-CURRENT nach dem Einpflegen des 'SG' Peripheriegerätes in CAM, welches einen Teil der SCSI SG passthrough Geräte API von Linux enthält. 700038 30. April 2007 7.0-CURRENT nachdem &man.getenv.3;, &man.putenv.3;, &man.setenv.3; und &man.unsetenv.3; geändert wurden, um POSIX konform zu sein. 700039 1. Mai 2007 7.0-CURRENT nachdem die Änderungen von 700038 rückgängig gemacht wurden. 700040 10. Mai 2007 7.0-CURRENT nach dem Hinzufügen von &man.flopen.3; zur libutil. 700041 13. Mai 2007 7.0-CURRENT nachdem Symbol Versionierung aktiviert und die standardmäßige Thread-Bibliothek zu libthr geändert wurde. 700042 19. Mai 2007 7.0-CURRENT nach dem Import von GCC 4.2.0. 700043 21. Mai 2007 7.0-CURRENT nachdem die Versionen aller Shared-Libraries, welche seit RELENG_6 nicht geändert wurden, erhöht worden sind. 700044 7. Juni 2007 7.0-CURRENT nachdem das Argument für vn_open()/VOP_OPEN() vom Dateideskriptorindex zur Struktur file * geädert wurde. 700045 10. Juni 2007 7.0-CURRENT nachdem &man.pam.nologin.8; geädert wurde, eine Kontoverwaltungs-Funktion statt einer Authentifizierungsfunktion für das PAM-Framework zur Verfügung zu stellen. 700046 11. Juni 2007 7.0-CURRENT nach aktualisierter 802.11 wireless Unterstützung. 700047 11. Juni 2007 7.0-CURRENT, nachdem TCP-LRO-Schnittstellen-Ressourcen hinzugefügt wurden. 700048 12. Juni 2007 7.0-CURRENT, nachdem die RFC 3678 API-Unterstützung zum IPv4-Stack hinzugefügt wurde. Veraltetes RFC 1724-Verhalten des IP_MULTICAST_IF ioctl wurde entfernt; 0.0.0.0/8 darf nicht länger als Schnittstellen-Index benutzt werden. Stattdessen sollte die Struktur ipmreqn verwendet werden. 700049 3. Juli 2007 7.0-CURRENT, nachdem pf von OpenBSD 4.1 importiert wurde (nicht geändert) 7.0-CURRENT, nachdem die IPv6-Unterstützung um FAST_IPSEC erweitert, KAME IPSEC entfernt und FAST_IPSEC in IPSEC umbenannt wurde. 700050 4. Juli 2007 7.0-CURRENT, nachdem Aufrufe von setenv/putenv/usw. von der traditionellen BSD-Art und Weise nach POSIX konvertiert wurden. 700051 4. Juli 2007 7.0-CURRENT, nachdem neue Systemaufrufe (mmap/lseek/usw.) implementiert wurden. 700052 6. Juli 2007 7.0-CURRENT, nachdem die I4B-Header nach include/i4b verschoben wurden. 700053 30. September 2007 7.0-CURRENT, nachdem die Unterstützung für PCI Domänen hinzugefügt wurde. 700054 25. Oktober 2007 7.0-CURRENT, nach der Trennung in "wide und single byte ctype". 700055 28. Oktober 2007 7.0-RELEASE sowie 7.0-CURRENT, nachdem die ABI-Abwärtskompatibilität für die FreeBSD 4/5/6-Versionen der PCIOCGETCONF-, PCIOCREAD- sowie PCIOCWRITE IOCTLs hinzugefügt wurde. Damit verbunden war, dass die ABI der PCIOCGETCONF IOCTL erneut deaktiviert werden musste. 700100 22. Dezember 2007 7.0-STABLE nach 7.0-RELEASE. 700101 8. Februar 2008 7.0-STABLE nach Einführung von m_collapse(). 700102 30. März 2008 7.0-STABLE nach Einfließen von kdb_enter_why(). 700103 10. April 2008 7.0-STABLE nach Hinzufügen von l_sysid zu struct flock. 700104 11. April 2008 7.0-STABLE nach Übernahme von procstat(1). 700105 11. April 2008 7.0-STABLE nach Einführung von umtx-Features. 700106 15. April 2008 7.0-STABLE nach Hinzufügen der Unterstützung von &man.write.2; zu &man.psm.4;. 700107 20. April 2008 7.0-STABLE nach Hinzufügen des Befehls F_DUP2FD zu &man.fcntl.2;. 700108 5. Mai 2008 7.0-STABLE nach einigen Änderungen an &man.lockmgr.9;, welche die Einbindung von sys/lock.h zur Verwendung von &man.lockmgr.9; voraussetzen. 700109 27. Mai 2008 7.0-STABLE nach Einfließen der memrchr-Funktion. 700110 5. August 2008 7.0-STABLE nach Einführung eines Clients für den Kernel NFS lockd. 700111 20. August 2008 7.0-STABLE nach Hinzufügen einer Unterstützung von physisch fortlaufender Jumbo Frames. 700112 27. August 2008 7.0-STABLE nach Einfließen einer Kernelunterstützung für DTrace. 701000 25. November 2008 7.1-RELEASE 701100 25. November 2008 7.1-STABLE nach 7.1-RELEASE. 701101 10. Januar 2009 7.1-STABLE nach Übernahme von strndup. 701102 17. Januar 2009 7.1-STABLE nach Hinzufügen einer Unterstützung von cpuctl(4). 701103 7. Februar 2009 7.1-STABLE nach Einfließen der Unterstützung von Jails mit keinen oder mehreren IPv4-/IPv6-Adressen. 701104 14. Februar 2009 7.1-STABLE, nachdem der Besitzer des Suspend in struct mount gespeichert wird und die Funktion vfs_susp_clean in struct vfsops aufgenommen ist. 701105 12. März 2009 7.1-STABLE nach der inkompatiblen Änderung am sysctl kern.ipc.shmsegs, um die Anforderung größerer Segmente von gemeinsam genutzten SysV-Speicher auf 64bit-Architekturen zu erlauben. 701106 14. März 2009 7.1-STABLE nach der Übernahme einer Fehlerbehebung für Warteoperationen, die POSIX-Semaphore verwenden. 702000 15. April 2009 7.2-RELEASE 702100 15. April 2009 7.2-STABLE nach 7.2-RELEASE. 702101 15. Mai 2009 7.2-STABLE, nachdem ichsmb(4) dahingehend geändert wurde, dass es links-ausgerichtete Adressierung von Slaves verwendet, um anderen SMBus-Kontrollertreibern zu entsprechen. 702102 28. Mai 2009 7.2-STABLE nach dem Einfließen der Funktion fdopendir. 702103 06. Juni 2009 7.2-STABLE nach dem Einfließen von PmcTools. - + + 702104 + 14. Juli 2009 + 7.2-STABLE nach dem Einfließen des + Systemaufrufs closefrom. + + + + 702105 + 31. Juli 2009 + 7.2-STABLE nach dem Einfließen der + Änderung an der SYSVIPC-ABI. + + + + 702106 + 14. September 2009 + 7.2-STABLE nach dem Einfließen der + PAT-Verbesserungen für x86-Prozessoren sowie dem + Hinzufügen von d_mmap_single() und des + VM-Objekttyps für scatter/gather-Listen. + + + + 703000 + 9. Februar 2010 + 7.3-RELEASE + + + + 703100 + 9. Februar 2010 + 7.3-STABLE nach 7.3-RELEASE. + + + 800000 11. Oktober 2007 8.0-CURRENT. Nach der Trennung in "wide und single byte ctype". 800001 16. Oktober 2007 8.0-CURRENT, nachdem libpcap 0.9.8 und tcpdump 3.9.8 importiert wurden. 800002 21. Oktober 2007 8.0-CURRENT, nachdem kthread_create() und Konsorten in kproc_create() usw. umbenannt wurden. 800003 24. Oktober 2007 8.0-CURRENT, nachdem die ABI-Abwärtskompatibilität für die FreeBSD 4/5/6-Versionen der PCIOCGETCONF-, PCIOCREAD- sowie PCIOCWRITE IOCTLs hinzugefügt wurde. Damit verbunden war, dass die ABI der PCIOCGETCONF IOCTL erneut deaktiviert werden musste. 800004 12. November 2007 8.0-CURRENT, nachdem der agp(4) Treiber verschoben wurde von src/sys/pci nach src/sys/dev/agp. 800005 4. Dezember 2007 8.0-CURRENT nach Änderungen am Jumbo Frame Allocator. 800006 7. Dezember 2007 8.0-CURRENT, nach dem Hinzufügen der callgraph capture Funktionalität zu &man.hwpmc.4;. 800007 25. Dezember 2007 8.0-CURRENT nach dem Hinzufügen von "why" als Argument in kdb_enter(). 800008 28. Dezember 2007 8.0-CURRENT nach Entfernen der Option LK_EXCLUPGRADE. 800009 9. Januar 2008 8.0-CURRENT nach Einführung von &man.lockmgr.disown.9; 800010 10. Januar 2008 8.0-CURRENT nach Änderungen am &man.vn.lock.9;-Prototyp. 800011 13. Januar 2008 8.0-CURRENT nach Änderungen an den Prototypen von &man.VOP.LOCK.9; und &man.VOP.UNLOCK.9;. 800012 19. Januar 2008 8.0-CURRENT nach Einführung von &man.lockmgr.recursed.9;, &man.BUF.RECURSED.9; und &man.BUF.ISLOCKED.9; sowie Entfernung von BUF_REFCNT(). 800013 23. Januar 2008 8.0-CURRENT nach Einführung der ASCII-Kodierung. 800014 24. Januar 2008 8.0-CURRENT nach Änderungen am &man.lockmgr.9;-Prototyp und Entfernung von lockcount() sowie LOCKMGR_ASSERT(). 800015 26. Januar 2008 8.0-CURRENT nach Erweiterung der Datentypen der &man.fts.3;-Strukturen. 800016 1. Februar 2008 8.0-CURRENT nach Hinzufügen eines neuen Parameters zu MEXTADD(9). 800017 6. Februar 2008 8.0-CURRENT nach Einführung der Optionen LK_NODUP und LK_NOWITNESS in die &man.lockmgr.9;-Umgebung. 800018 8. Februar 2008 8.0-CURRENT nach Hinzufügen von m_collapse. 800019 9. Februar 2008 8.0-CURRENT nach Hinzufügen einer Arbeits-, Wurzel- und Jailverzeichnisunterstützung zur sysctl-Variable kern.proc.filedesc. 800020 13. Februar 2008 8.0-CURRENT nach Einführung der Funktionen &man.lockmgr.assert.9; und BUF_ASSERT. 800021 15. Februar 2008 8.0-CURRENT nach Einführung von &man.lockmgr.args.9; und Entfernung der Option LK_INTERNAL. 800022 (zurückgezogen) 8.0-CURRENT nach Setzen von BSD &man.ar.1; als Systemstandard. 800023 25. Februar 2008 8.0-CURRENT nach Prototypenänderungen an &man.lockstatus.9; und &man.VOP.ISLOCKED.9;, eigens zur Abschaffung des Parameters struct thread. 800024 1. März 2008 8.0-CURRENT nach Beseitigung der Funktionen lockwaiters und BUF_LOCKWAITERS, Änderung des Rückgabewerts der Funktion brelvp von void nach int sowie Einführung neuer Optionen für &man.lockinit.9;. 800025 8. März 2008 8.0-CURRENT nach Hinzufügen des Kommandos F_DUP2FD zu &man.fcntl.2;. 800026 12. März 2008 8.0-CURRENT nach Änderung des Parameters für die Priorität an cv_broadcastpri, sodass 0 für keine Priorität steht. 800027 24. März 2008 8.0-CURRENT nach Änderung der Monitoring ABI von BPF, als Zero-Copy Puffer hinzugefügt wurden. 800028 26. März 2008 8.0-CURRENT nach Hinzufügen von l_sysid zu struct flock. 800029 28. März 2008 8.0-CURRENT nach Wiedereingliederung der Funktion BUF_LOCKWAITERS und Hinzufügen von &man.lockmgr.waiters.9;. 800030 1. April 2008 8.0-CURRENT nach Einführung der Funktionen &man.rw.try.rlock.9; und &man.rw.try.wlock.9;. 800031 6. April 2008 8.0-CURRENT nach Einführung der Funktionen lockmgr_rw und lockmgr_args_rw. 800032 8. April 2008 8.0-CURRENT nach Implementierung des Systemaufrufs openat und seiner Verwandten, Einführung der Option O_EXEC in &man.open.2; und Bereitstellung der entsprechenden Systemaufrufe innerhalb der &linux;-Kompatibilitätsumgebung. 800033 8. April 2008 8.0-CURRENT nach Hinzufügen der Unterstützung von &man.write.2; in der nativen Operationsebene von &man.psm.4;. Es können nun beliebig Kommandos nach /dev/psm%d geschrieben und der Status dann von dort gelesen werden. 800034 10. April 2008 8.0-CURRENT nach Einführung der Funktion memrchr. 800035 16. April 2008 8.0-CURRENT nach Einführung der Funktion fdopendir. 800036 20. April 2008 8.0-CURRENT nach Umstellung des Standards 802.11 auf Unterstützung von Multi-BSS (auch vaps). 800037 9. Mai 2008 8.0-CURRENT nach Hinzufügen einer Unterstützung für Multi Routing-Tabellen (siehe setfib(1), setfib(2)). 800038 26. Mai 2008 8.0-CURRENT nach Entfernen von netatm und ISDN4BSD. 800039 14. Juni 2008 8.0-CURRENT nach Entfernen von sgtty. 800040 26. Juni 2008 8.0-CURRENT nach Einführung eines Clients für den Kernel NFS lockd. 800041 22. Juli 2008 8.0-CURRENT nach Hinzufügen von arc4random_buf(3) und arc4random_uniform(3). 800042 8. August 2008 8.0-CURRENT nach Hinzufügen von cpuctl(4). 800043 13. August 2008 8.0-CURRENT nach Änderung von bpf(4) zur Verwendung einer einzelnen Gerätedatei anstatt von Klonierung. 800044 17. August 2008 8.0-CURRENT nach Übernahme des ersten Teils aus dem vimage-Projekt durch Erweitern globaler Variablen um den Präfix V_. Zukünftig werden die virtualisierten Variablen dann mit Hilfe von Makros in ihre globalen Namen aufgelöst. 800045 20. August 2008 8.0-CURRENT nach Eingliederung des MPSAFE TTY-Layers, einschließlich Änderungen an diversen Treibern und Werkzeugen, die mit ihm kommunizieren. 800046 8. September 2008 8.0-CURRENT nach Abschottung der GDT pro CPU auf der AMD64-Architektur. 800047 10. September 2008 8.0-CURRENT nach Entfernen von VSVTX, VSGID und VSUID. 800048 16. September 2008 8.0-CURRENT nach Anpassung des Codes für Kernel NFS mount, sodass einzelne Mountoptionen im Parameter struct iovec an nmount() akzeptiert werden und nicht nur ein großes struct nfs_args. 800049 17. September 2008 8.0-CURRENT nach Entfernen von &man.suser.9; und &man.suser.cred.9;. 800050 20. Oktober 2008 8.0-CURRENT nach API-Änderungen im Umgang mit dem Buffer Cache. 800051 23. Oktober 2008 8.0-CURRENT nach Entfernen der Makros &man.MALLOC.9; und &man.FREE.9;. 800052 28. Oktober 2008 8.0-CURRENT nach Einführung von accmode_t und Umbennung des Parameters a_mode an VOP_ACCESS nach a_accmode. 800053 2. November 2008 8.0-CURRENT nach Änderung des Prototyps von &man.vfs.busy.9; und Einführung der Optionen MBF_NOWAIT sowie MBF_MNTLSTLOCK. 800054 22. November 2008 8.0-CURRENT nach Hinzufügen von Funktionen im Bereich buf_ring, Memory Barriers und ifnet, um mehrere Sendeschlangen auf Hardwareebene für Karten zu ermöglichen, die dies unterstützen, sowie einer Ring Buffer-Implementierung ohne Lock, um Treibern zu ermöglichen, Paketschlangen effizienter zu verwalten. 800055 27. November 2008 8.0-CURRENT nach Hinzufügen einer Unterstützung für &intel; Core, Core2 und Atom zu &man.hwpmc.4;. 800056 29. November 2008 8.0-CURRENT nach Einführung von Jails mit mehreren oder gar keinen IPv4-/IPv6-Adressen. 800057 1. Dezember 2008 8.0-CURRENT nach Wechsel zum ath_hal Quellcode. 800058 12. Dezember 2008 8.0-CURRENT nach Einführung der Funktion VOP_VPTOCNP. 800059 15. Dezember 2008 8.0-CURRENT gliedert das neue ARPv2 ein. 800060 19. Dezember 2008 8.0-CURRENT nach Hinzufügen von makefs. 800061 15. Januar 2009 8.0-CURRENT nach Umsetzung von TCP Appropriate Byte Counting. 800062 28. Januar 2009 8.0-CURRENT nach Entfernen von minor(), minor2unit(), unit2minor() usw. 800063 18. Februar 2009 8.0-CURRENT nach Änderung der GENERIC-Konfiguration zur Verwendung des USB2-Stack und Hinzufügen von fdevname(3). 800064 23. Februar 2009 8.0-CURRENT, nachdem der USB2-Stack nach dev/usb verschoben wurde, um es zu ersetzen. 800065 26. Februar 2009 8.0-CURRENT nach Umbenennen aller Funktionen in libmp(3). 800066 27. Februar 2009 8.0-CURRENT nach Anpassung des devfs-Verhaltens im Zusammenhang mit USB. 800067 28. Februar 2009 8.0-CURRENT nach Hinzufügen von getdelim(), getline(), stpncpy(), strnlen(), wcsnlen(), wcscasecmp() und wcsncasecmp(). 800068 2. März 2009 8.0-CURRENT nach Umbenennen der Geräteklasse ushub in uhub. 800069 9. März 2009 8.0-CURRENT nach Umbenennen von libusb20.so.1 in libusb.so.1. 800070 9. März 2009 8.0-CURRENT nach der Einführung von IGMPv3 und Source-Specific-Multicast (SSM) in den IPv4-Stack. 800071 14. März 2009 8.0-CURRENT nach der Anpassung von gcc zur Verwendung der C99-Inline-Semantik in den Modi c99 und gnu99. 800072 15. März 2009 8.0-CURRENT, nachdem die Option IFF_NEEDSGIANT entfernt wurde; Netzwerktreiber, die nicht MPSAFE sind, werden nicht mehr unterstützt. 800073 18. März 2009 8.0-CURRENT, nachdem die dynamische Ersetzung von Zeichenkettenkürzeln für rpath und benötigte Pfade implementiert wurde. 800074 24. März 2009 8.0-CURRENT nach dem Einfließen von tcpdump 4.0.0 und libpcap 1.0.0. 800075 6. April 2009 8.0-CURRENT, nachdem die Deklarationen von struct vnet_net, struct vnet_inet und struct vnet_ipfw geändert wurden. 800076 9. April 2009 8.0-CURRENT nach dem Hinzufügen von Laufzeitprofilen in dummynet. 800077 14. April 2009 8.0-CURRENT nach dem Entfernen von VOP_LEASE() und vop_vector.vop_lease. 800078 15. April 2009 8.0-CURRENT, nachdem die Felder aus struct rt_weight zu struct rt_metrics und struct rt_metrics_lite hinzugefügt wurden, wobei die Deklaration von struct rt_metrics_lite geändert wurde. RTM_VERSION wurde hochgezählt (zurückgezogen). 800079 15. April 2009 8.0-CURRENT, nachdem Pointer auf struct llentry zu struct route und struct route_in6 hinzugefügt wurden. 800080 15. April 2009 8.0-CURRENT nach Änderung der Deklaration von struct inpcb. 800081 19. April 2009 8.0-CURRENT nach Änderung der Deklaration von struct malloc_type. 800082 21. April 2009 8.0-CURRENT nach Änderung der Deklaration von struct ifnet und Hinzufügen von if_ref() und if_rele() zur Verwaltung von Referenzen auf ifnet. 800083 22. April 2009 8.0-CURRENT nach der Implementierung einer systemnahen Bluetooth-HCI-API. 800084 29. April 2009 8.0-CURRENT nach Änderungen an IPv6-SSM und MLDv2. 800085 30. April 2009 8.0-CURRENT, nachdem der Bau von VIMAGE-Kernel mit einem aktiven Image unterstützt wird. 800086 8. Mai 2009 8.0-CURRENT nach Hinzufügen der Unterstützung für Eingabezeilen mit beliebiger Länge durch patch(1). 800087 11. Mai 2009 8.0-CURRENT nach einigen Änderungen im Zusammenhang mit dem VFS-KPI. Der Thread-Parameter wurde von den FSD-Teilen des VFS entfernt. VFS_*-Funktionen benötigen den Kontext nicht mehr, da er sich immer auf curthread bezieht. In wenigen Sonderfällen ist das bisherige Verhalten nicht geändert worden. 800088 20. Mai 2009 8.0-CURRENT nach Änderungen am net80211-Monitormodus. 800089 23. Mai 2009 8.0-CURRENT nach dem Hinzufügen der Unterstützung von UDP-Kontrollblocks. 800090 23. Mai 2009 8.0-CURRENT nach der Virtualisierung der Schnittstellenklonierung. 800091 27. Mai 2009 8.0-CURRENT nach dem Hinzufügen von hierarchischen Jails und dem Entfernen des globalen securelevel. 800092 29. Mai 2009 8.0-CURRENT nach der Änderung des sx_init_flags()-KPI. SX_ADAPTIVESPIN wurde zurückgezogen und eine neue Option SX_NOADAPTIVE wurde eingeführt, um die umgekehrte Logik zu behandeln. 800093 29. Mai 2009 8.0-CURRENT nach dem Hinzufügen von mnt_xflag zu struct mount. 800094 30. Mai 2009 8.0-CURRENT nach dem Hinzufügen von &man.VOP.ACCESSX.9;. 800095 30. Mai 2009 8.0-CURRENT nach der Änderung des Polling-KPI. Die Polling-Handler liefern nun die Zahl der verarbeiteten Pakete zurück. Die neue Option IFCAP_POLLING_NOCOUNT wurde weiter eingeführt, um anzugeben, dass der Rückgabewert nicht von Bedeutung ist und das Zählen der Pakete ausgelassen werden soll. 800096 1. Juni 2009 8.0-CURRENT nach der Aktualisierung der netisr-Implementierung und nachdem die Weise, wie FIBs gespeichert werden und wie auf sie zugegriffen wird, geändert wurde. - + + + 800097 + 8. Juni 2009 + 8.0-CURRENT nach Einführung der + Destruktor-Infrastruktur für vnet + einschließlich Hooks. + + + + 800097 + 11. Juni 2009 + 8.0-CURRENT nach Einführung eines + Erkennungssystems für ausgehende Pakete, die + direkt wieder in netgraph gelangen und deswegen + eingereiht werden. Dabei wurde auch die Definition von + struct thread geändert. + + + + 800098 + 14. Juni 2009 + 8.0-CURRENT nach dem Einfließen von OpenSSL + 0.9.8k. + + + + 800099 + 22. Juni 2009 + 8.0-CURRENT nach der Aktualisierung von NGROUPS + und dem Verschieben der Routing-Virtualisierung in ein + eigenes VImage-Modul. + + + + 800100 + 24. Juni 2009 + 8.0-CURRENT nach Änderung der + SYSVIPC-ABI. + + + + 800101 + 29. Juni 2009 + 8.0-CURRENT nach dem Entfernen der + zeichenorientierten Geräte aus /dev/net, von + denen für jede Schnittstelle eines + existiert. + + + + 800102 + 12. Juli 2009 + 8.0-CURRENT, nachdem struct sackhint, struct + tcpcb und struct tcpstat mit Padding-Bytes + aufgefüllt wurden. + + + + 800103 + 13. Juli 2009 + 8.0-CURRENT, nachdem struct tcpopt durch struct + toeopt in der Schnittstelle zwischen dem TOE-Treiber + und dem TCP-SYN-Cache ersetzt wurde. + + + + 800104 + 19. Juli 2009 + 8.0-CURRENT nach dem Hinzufügen einer + vnet-spezifischen Speicherzuweisung, die auf dem + Linker-Set-Verfahren basiert. + + + + 800105 + 19. Juli 2009 + 8.0-CURRENT nach der Inkrementierung der + Versionsnummer aller Shared-Libraries, die + Symbol-Versioning nicht aktiviert haben. + + + + 800106 + 24. Juli 2009 + 8.0-CURRENT nach Einführung des + VM-Objekttyps OBJT_SG. + + + + 800107 + 2. August 2009 + 8.0-CURRENT nach Befreiung des Newbus-Subsystems + von Giant durch Hinzufügen von sxlock und 8.0-RELEASE. + + + + 800108 + 21. November 2009 + 8.0-CURRENT nach Implementierung des + kevent-Filters EVFILT_USER. + + + + 800500 + 7. Januar 2010 + 8.0-STABLE nach Erhöhung von + __FreeBSD_version, damit + pkg_add -r packages-8-stable + verwendet. + + + + 800501 + 24. Januar 2010 + 8.0-STABLE, nachdem die Prototypen von + scandir(3) und + alphasort(3) geändert + wurden, um der SUSv4 zu entsprechen. + + + + 800502 + 31. Januar 2010 + 8.0-STABLE nach Hinzufügen von + sigpause(3). + + + + 800503 + 25. Februar 2010 + 8.0-STABLE nach dem Hinzufügen der ioctls + SIOCGIFDESCR und SIOCSIFDESCR für + Netzwerk-Schnittstellen. Diese ioctls können, + nach dem Vorbild von OpenBSD, dazu verwendet werden, + Schnittstellenbeschreibungen zu bearbeiten und + auszulesen. + + + + 800504 + 1. März 2010 + 8.0-STABLE, nachdem x86emu, ein Software-Emulator + von OpenBSD für x86-Prozessoren im Real-Mode, von + CURRENT übernommen wurde. + + + + 900000 + 22. August 2009 + 9.0-CURRENT. + + + + 900001 + 8. September 2009 + 9.0-CURRENT nach dem Import von x86emu, einem + Software-Emulator von OpenBSD für x86-Prozessoren + im Real-Mode. + + + + 900002 + 23. September 2009 + 9.0-CURRENT nach Implementierung des + kevent-Filters EVFILT_USER. + +
Beachten Sie, dass 2.2-STABLE sich nach dem 2.2.5-RELEASE manchmal als 2.2.5-STABLE identifiziert. Das Muster war früher das Jahr gefolgt von dem Monat, aber wir haben uns entschieden, ab 2.2. einen geradlinigeren Ansatz mit major/minor-Nummern zu benutzen. Dies liegt daran, dass gleichzeitiges Entwickeln an mehreren Zweigen es unmöglich macht, die Versionen nur mit Hilfe des Datums des Releases zu unterteilen. Wenn Sie jetzt einen Port erstellen brauchen Sie sich nicht um alte -CURRENTs zu kümmern; diese sind hier nur als Referenz augeführt.
Etwas hinter die <filename>bsd.port.mk</filename>-Anweisung schreiben Schreiben Sie bitte nichts hinter die .include <bsd.port.mk>-Zeile. Normalerweise kann dies vermieden werden, indem Sie die Datei bsd.port.pre.mk irgendwo in der Mitte Ihres Makefiles und bsd.port.post.mk am Ende einfügen. Sie dürfen entweder nur das bsd.port.pre.mk/bsd.port.post.mk-Paar oder bsd.port.mk alleine hinzufügen; vermischen Sie diese Verwendungen nicht! bsd.port.pre.mk definiert nur einige Variablen, welche in Tests im Makefile benutzt werden können, bsd.port.post.mk definiert den Rest. Hier sind einige wichtige Variablen, welche in bsd.port.pre.mk definiert sind (dies ist keine vollständige Liste, lesen Sie bitte bsd.port.mk für eine vollständige Auflistung). Variable Beschreibung ARCH Die Architektur, wie von uname -m zurückgegeben (z.B. i386) OPSYS Der Typ des Betriebsystems, wie von uname -s zurückgegeben (z.B. FreeBSD) OSREL Die Release Version des Betriebssystems (z.B., 2.1.5 oder 2.2.7) OSVERSION Die numerische Version des Betriebssystems; gleichbedeutend mit __FreeBSD_version. PORTOBJFORMAT Das Objektformat des Systems (elf oder aout; beachten Sie, dass für moderne Versionen von FreeBSD aout veraltet ist). LOCALBASE Die Basis des local Verzeichnisbaumes (z.B. /usr/local/) PREFIX Wo der Port sich selbst installiert (siehe Mehr Informationen über PREFIX). + + + 900003 + 2. Dezember 2009 + 9.0-CURRENT nach Hinzufügen von + sigpause(3) und der + PIE-Unterstützung zu csu. + + + + 900004 + 6. Dezember 2009 + 9.0-CURRENT nach Hinzufügen von libulog und + dessen + libutempter-Kompatibilitätsschnittstelle. + + + + 900005 + 12. Dezember 2009 + 9.0-CURRENT nach Hinzufügen von + sleepq_sleepcnt(), das dazu + verwendet werden kann, die Anzahl der in einer + bestimmten Warteschlange eingereihten Threads + abzufragen. + + + + 900006 + 4. Januar 2010 + 9.0-CURRENT, nachdem die Prototypen von + scandir(3) und + alphasort(3) geändert + wurden, um der SUSv4 zu entsprechen. + + + + 900007 + 13. Januar 2010 + 9.0-CURRENT nach dem Entfernen von utmp(5) und + dem Hinzufügen von utmpx (siehe + getutxent(3)) zur besseren + Erfassung von Benutzeranmeldungen und + Systemereignissen. + + + + 900008 + 20. Januar 2010 + 9.0-CURRENT nach der Einführung von BSDL + bc/dc zur Ersetzung von GNU bc/dc. + + + + 900009 + 26. Januar 2010 + 9.0-CURRENT nach dem Hinzufügen der ioctls + SIOCGIFDESCR und SIOCSIFDESCR für + Netzwerk-Schnittstellen. Diese ioctls können, + nach dem Vorbild von OpenBSD, dazu verwendet werden, + Schnittstellenbemerkungen zu bearbeiten und + auszulesen. + + + + 900010 + 22. März 2010 + 9.0-CURRENT nach dem Import von zlib + 1.2.4. + Falls Sie die Variablen USE_IMAKE, USE_X_PREFIX, oder MASTERDIR definieren müssen, sollten Sie dies vor dem Einfügen von bsd.port.pre.mk machen. Hier sind ein paar Beispiele von Dingen, die Sie hinter die Anweisung bsd.port.pre.mk schreiben können: # lang/perl5 muss nicht kompliliert werden, falls perl5 schon auf dem System ist .if ${OSVERSION} > 300003 BROKEN= perl ist im System .endif # nur eine Versionsnummer für die ELF Version der shlib .if ${PORTOBJFORMAT} == "elf" TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR} .else TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR} .endif # die Software erstellt schon eine Verknüpfung fü ELF, aber nicht fü a.out post-install: .if ${PORTOBJFORMAT} == "aout" ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so .endif Sie haben sich daran erinnert Tabulator statt Leerzeichen nach BROKEN= und TCL_LIB_FILE= zu benutzen, oder? :-). Benutzen Sie die <function>exec</function>-Anweisung in Wrapper-Skripten Falls der Port ein Shellskript installiert, dessen Zweck es ist ein anderes Programm zu starten, und falls das Starten des Programmes die letzte Aktion des Skripts ist, sollten Sie sicherstellen, dass Sie die Funktion exec dafür benutzen; zum Beispiel: #!/bin/sh exec %%LOCALBASE%%/bin/java -jar %%DATADIR%%/foo.jar "$@" Die Funktion exec ersetzt den Shell-Prozess mit dem angegebenen Programm. Falls exec ausgelassen wird, verbleibt der Shell-Prozess im Speicher während das Programm ausgefährt wird und verbraucht unnötig Systemressourcen. - - UIDs und GIDs - - Die aktuellen Listen von reservierten UIDs und GIDs sind - in ports/UIDs und - ports/GIDs zu finden. - - Falls Ihr Port einen bestimmten Benutzer auf dem zu - installierendem System benötigt, lassen Sie das - pkg-install-Skript den Aufruf von - pw machen, um ihn automatisch anzulegen. - Schauen Sie sich für ein Beispiel sysutils/symon an. - Ihr Port muss eine feste Benutzer/Gruppen-ID verwenden. - Sie müssen eine nicht benutzte UID - zwischen 50 und 999 benutzen und entweder in - ports/UIDs (für Benutzer) oder in - ports/GIDs (für Gruppen) - registrieren. - - Stellen Sie sicher, dass Sie keine UIDs verwenden, - welche schon vom System oder von einem anderen Port gebraucht - werden. - - Bitte fügen Sie einen Patch für diese beiden - Datei hinzu, falls für Ihren Port ein neuer Benutzer oder - Gruppe angelegt werden muss. - - Aufgaben vernünftig lösen Das Makefile sollte die nötigen Schritte einfach und vernünftig durchführen. Wenn Sie ein einige Zeilen einsparen oder die Lesbarkeit verbessern können, dann machen Sie dies bitte. Beispiele sind: Ein make-Konstrukt .if anstatt eines Shellkonstrukt if zu verwenden, anstatt do-extract neu zu definieren, dies mit EXTRACT* machen, oder GNU_CONFIGURE anstelle von CONFIGURE_ARGS += --prefix=${PREFIX} zu verwenden. Falls Sie sich in einer Situation wiederfinden, in der Sie viel Code neu schreiben müssen, um etwas zu testen, sollten Sie zuerst bsd.port.mk erneut konsultieren und nachprüfen ob es nicht bereits eine Lösung für Ihr Problem enthält. Es ist zwar schwer zu lesen, beinhaltet jedoch eine Menge kurzer Lösungen für viele scheinbar schwierige Probleme. Berücksichtigen Sie sowohl <makevar>CC</makevar> als auch <makevar>CXX</makevar> Der Port sollte sowohl die CC- wie auch die CXX-Variable berücksichtigen. Damit ist gemeint, dass der Port diese Variablen nicht ohne Rücksicht auf eventuell schon gesetzte Werte einfach überschreiben sollte; stattdessen sollten neue Werte an schon existierende angehängt werden. Dadurch können Build-Optionen, die alle Ports betreffen, global definiert werden. Falls der Port diese Variablen nicht berücksichtigt, sollte NO_PACKAGE=ignores either cc or cxx ins Makefile eingefügt werden. Im Folgenden wird ein Beispiel eines Makefiles gezeigt, welches die beiden Variablen CC und CXX berücksichtigt. Beachten Sie das ?=: CC?= gcc CXX?= g++ Nachfolgend ein Beispiel, welches weder CC noch CXX berücksichtigt: CC= gcc CXX= g++ Die Variablen CC und CXX können auf FreeBSD-Systemen in /etc/make.conf definiert werden. Im ersten Beispiel wird ein Wert nur dann gesetzt, falls dieser vorher noch nicht gesetzt war, um so systemweite Definitionen zu berücksichtigen. Im zweiten Beispiel werden die Variablen ohne Rücksicht überschrieben. Berücksichtigen Sie <makevar>CFLAGS</makevar> Der Port sollte die Variable CFLAGS berücksichtigen. Damit ist gemeint, dass der Port den Wert dieser Variablen nicht absolut setzen und damit existierende Werte überschreiben sollte; stattdessen sollte er weitere Werte der Variablen durch Anhängen hinzufügen. Dadurch können Build-Optionen, die alle Ports betreffen, global definiert werden. Falls der Port diese Variablen nicht berücksichtigt, sollte NO_PACKAGE=ignores cflags ins Makefile eingefügt werden. Im Folgenden wird ein Beispiel eines Makefiles gezeigt, welches die Variable CFLAGS berücksichtigt. Beachten Sie das +=: CFLAGS+= -Wall -Werror Nachfolgend finden Sie ein Beispiel, welches die CFLAGS-Variable nicht berücksichtigt: CFLAGS= -Wall -Werror Die Variable CFLAGS wird auf FreeBSD-Systemen in /etc/make.conf definiert. Im ersten Beispiel werden weitere Flags an die Variable CFLAGS angehängt und somit der bestehende Wert nicht gelöscht. Im zweiten Beispiel wird die Variable ohne Rücksicht überschrieben. Sie sollten Optimierungsflags aus Makefiles Dritter entfernen. Die CFLAGS des Systems beinhalten systemweite Optimierungsflags. Ein Beispiel eines unveränderten Makefiles: CFLAGS= -O3 -funroll-loops -DHAVE_SOUND Werden nun systemweite Optimierungsflags verwendet so würde das Makefile in etwa folgendermaßen aussehen: CFLAGS+= -DHAVE_SOUND Threading-Bibliotheken Die Threading-Bibliothek muss mit Hilfe eines speziellen Linker-Flags -pthread in die Binärdateien unter &os; gebunden werden. Falls ein Port auf ein direktes Verlinken gegen -lpthread oder -lc_r besteht, passen Sie den Port bitte so an, dass er die durch das Port-Framework bereitgestellte Variable PTHREAD_LIBS verwendet. Diese Variable hat üblicherweise den Wert -pthread, kann aber auf einigen Architekturen und &os;-Versionen abweichende Werte haben und daher sollte nie -pthread direkt in Patches geschrieben werden, sondern immer PTHREAD_LIBS. Falls durch das Setzen von PTHREAD_LIBS der Bau des Ports mit der Fehlermeldung unrecognized option '-pthread' abbricht, kann die Verwendung des gcc als Linker durch setzen von CONFIGURE_ENV auf LD=${CC} helfen. Die Option -pthread wird nicht direkt von ld unterstützt. Rückmeldungen Brauchbare Änderungen/Patches sollten an den ursprünglichen Autor/Maintainer der Software geschickt werden, damit diese in der nächsten Version der Software mit aufgenommen werden können. Dadurch wird Ihre Aufgabe für die nächste Version der Software deutlich einfacher. <filename>README.html</filename> Nehmen Sie bitte keine README.html in den Port auf. Diese Datei ist kein Bestandteil der CVS-Sammlung sondern wird durch make readme erzeugt. Einen Port durch <makevar>BROKEN</makevar>, <makevar>FORBIDDEN</makevar> oder <makevar>IGNORE</makevar> als nicht installierbar markieren In manchen Fällen sollten Benutzer davon abgehalten werden einen Port zu installieren. Um einem Benutzer mitzuteilen, dass ein Port nicht installiert werden sollte, gibt es mehrere Variablen für make, die im Makefile des Ports genutzt werden können. Der Wert der folgenden make-Variablen wird dem Benutzer als Grund für die Ablehnung der Installation des Ports zurückgegeben. Bitte benutzen Sie die richtige make-Variable, denn jede enthält eine völlig andere Bedeutung für den Benutzer und das automatische System, das von dem Makefile abhängt, wie der Ports-Build-Custer, FreshPorts und portsmon. Variablen BROKEN ist reserviert für Ports, welche momentan nicht korrekt kompiliert, installiert oder deinstalliert werden. Es sollte für Ports benutzt werden, von denen man annimmt, dass dies ein temporäres Problem ist. Falls angegeben, wird der Build-Cluster dennoch versuchen den Port zu bauen, um zu sehen, ob das zugrunde liegende Problem behoben wurde (das ist jedoch im Allgemeinen nicht der Fall). Benutzen Sie BROKEN zum Beispiel, wenn ein Port: nicht kompiliert beim Konfiguration- oder Installation-Prozess scheitert Dateien außerhalb von ${LOCALBASE} installiert beim Deinstallieren nicht alle seine Dateien sauber entfernt (jedoch kann es akzeptable und wünschenswert sein, Dateien, die vom Nutzer verändert wurden, nicht zu entfernen) FORBIDDEN wird für Ports verwendet, die Sicherheitslücken enthalten oder die ernste Sicherheitsbedenken für das FreeBSD-System aufwerfen, wenn sie installiert sind (z.B. ein als unsicher bekanntes Programm, oder ein Programm, das einen Dienst zur Verfügung stellt, der leicht kompromittiert werden kann). Ports sollten als FORBIDDEN gekennzeichnet werden, sobald ein Programm eine Schwachstelle hat und kein Update veröffentlicht wurde. Idealerweise sollten Ports so bald wie möglich aktualisiert werden wenn eine Sicherheitslücke entdeckt wurde, um die Zahl verwundbarer FreeBSD-Hosts zu verringern (wir schätzen es für unsere Sicherheit bekannt zu sein), obwohl es manchmal einen beachtlichen Zeitabstand zwischen der Bekanntmachung einer Schwachstelle und dem entsprechenden Update gibt. Bitte kennzeichnen Sie einen Port nicht aus irgendeinem Grund außer Sicherheit als FORBIDDEN. IGNORE ist für Ports reserviert, die aus anderen Gründen nicht gebaut werden sollten. Es sollte für Ports verwendet werden, in denen ein strukturelles Problem vermutet wird. Der Build-Cluster wird unter keinen Umständen Ports, die mit IGNORE markiert sind, erstellen. Verwenden Sie IGNORE zum Beispiel, wenn ein Port: kompiliert, aber nicht richtig läuft nicht auf der installierten Version von &os; läuft &os; Kernelquelltext zum Bauen benötigt, aber der Benutzer diese nicht installiert hat ein Distfile benötigt, welches aufgrund von Lizenzbeschränkungen nicht automatisch abgerufen werden kann nicht korrekt mit einem momentan installiertem Port arbeitet (der Port hängt zum Beispiel von www/apache21 ab, aber www/apache13 ist installiert) Wenn ein Port mit einem momentan installiertem Port kollidiert (zum Beispiel, wenn beide eine Datei an die selbe Stelle installieren, diese aber eine andere Funktion hat), benutzen Sie stattdessen CONFLICTS. CONFLICTS setzt IGNORE dann selbstständig. Um einen Port nur auf bestimmte Systemarchitekturen mit IGNORE zu markieren, gibt es zwei Variablen, die automatisch IGNORE für Sie setzen: ONLY_FOR_ARCHS und NOT_FOR_ARCHS. Beispiele: ONLY_FOR_ARCHS= i386 amd64 NOT_FOR_ARCHS= alpha ia64 sparc64 Eine eigene IGNORE-Ausgabe kann mit ONLY_FOR_ARCHS_REASON und NOT_FOR_ARCHS_REASON festgelegt werden. Für eine bestimmte Architektur sind Angaben durch ONLY_FOR_ARCHS_REASON_ARCH und NOT_FOR_ARCHS_REASON_ARCH möglich. Wenn ein Port i386-Binärdateien herunterlädt und installiert, sollte IA32_BINARY_PORT gesetzt werden. Wenn die Variable gesetzt ist, wird überprüft, ob das Verzeichnis /usr/lib32 für IA32-Versionen der Bibliotheken vorhanden ist, und ob der Kernel mit IA32-Kompatibilität gebaut wurde. Wenn eine dieser zwei Voraussetzungen nicht erfüllt ist, wird IGNORE automatisch gesetzt. Anmerkungen zur Implementierung Zeichenketten sollten nicht in Anführungszeichen gesetzt werden. Auch die Wortwahl der Zeichenketten sollte die Art und Weise beachten, wie die Informationen dem Nutzer angezeigt werden. Beispiele: BROKEN= this port is unsupported on FreeBSD 5.x IGNORE= is unsupported on FreeBSD 5.x resultieren in den folgenden Ausgaben von make describe: ===> foobar-0.1 is marked as broken: this port is unsupported on FreeBSD 5.x. ===> foobar-0.1 is unsupported on FreeBSD 5.x. Kennzeichnen eines Ports zur Entfernung durch <makevar>DEPRECATED</makevar> oder <makevar>EXPIRATION_DATE</makevar> Denken Sie bitte daran, dass BROKEN und FORBIDDEN nur als temporärer Ausweg verwendet werden sollten, wenn ein Port nicht funktioniert. Dauerhaft defekte Ports sollten komplett aus der Ports-Sammlung entfernt werden. Wenn es sinnvoll ist, können Benutzer vor der anstehenden Entfernung eines Ports mit DEPRECATED und EXPIRATION_DATE gewarnt werden. Ersteres ist einfach eine Zeichenkette, die angibt, warum der Port entfernt werden soll. Letzteres ist eine Zeichenkette im ISO 8601-Format (JJJJ-MM-TT). Beides wird dem Benutzer gezeigt. Es ist möglich DEPRECATED ohne EXPIRATION_DATE zu setzen (zum Beispiel, um eine neuere Version des Ports zu empfehlen), aber das Gegenteil ist sinnlos. Es gibt keine Vorschrift wie lange die Vorwarnzeit sein muss. Gegenwärtig ist es üblich einen Monat für sicherheitsrelevante Probleme und zwei Monate für Build-Probleme anzusetzen. Dies gibt allen interessierten Committern ein wenig Zeit die Probleme zu beheben. Vermeiden Sie den Gebrauch des <literal>.error</literal>-Konstruktes Der korrekte Weg eines Makefile anzuzeigen, dass der Port aufgrund eines externen Grundes nicht installiert werden kann (zum Beispiel, weil der Benutzer eine ungültige Kombination von Build-Optionen angegeben hat), ist IGNORE auf einen nicht leeren Wert zu setzen. Dieser wird dann formatiert und dem Benutzer von make install ausgegeben. Es ist ein verbreiteter Fehler .error für diesem Zweck zu verwenden. Das Problem dabei ist, dass viele automatisierte Werkzeuge, die mit dem Ports-Baum arbeiten, in dieser Situation fehlschlagen. Am Häufigsten tritt das Problem beim Versuch /usr/ports/INDEX zu bauen auf (siehe ). Jedoch schlagen auch - trivialere Befehle wie make -V maintainer + trivialere Befehle wie make maintainer in diesem Fall fehl. Dies ist nicht akzeptabel! Wie vermeidet man die Verwendung von <literal>.error</literal> Nehmen Sie an, dass die Zeile USE_POINTYHAT=yes in make.conf enthalten ist. Der erste der folgenden zwei Makefile-Schnipsel lässt make index fehlschlagen, während der zweite dies nicht tut. .if USE_POINTYHAT .error "POINTYHAT is not supported" .endif .if USE_POINTYHAT IGNORE=POINTYHAT is not supported .endif Verwendung von <filename>sysctl</filename> Vom Gebrauch von sysctl wird, außer in Targets, abgeraten. Das liegt daran, dass die Auswertung aller makevars, wie sie während make index verwendet werden, dann den Befehl ausführen muss, welches den Prozess weiter verlangsamt. Die Verwendung von &man.sysctl.8; sollte immer durch die Variable SYSCTL erfolgen, da diese den vollständigen Pfad enthält und überschrieben werden kann, so dies als notwendig erachtet wird. Erneutes Ausliefern von Distfiles Manchmal ändern die Autoren der Software den Inhalt veröffentlichter Distfiles, ohne den Dateinamen zu ändern. Sie müssen überprüfen, ob die Änderungen offizell sind und vom Autor durchgeführt wurden. Es ist in der Vergangenheit vorgekommen, dass Distfiles still und heimlich auf dem Download-Server geändert wurden, um Schaden zu verursachen oder die Sicherheit der Nutzer zu kompromittieren. Verschieben Sie das alte Distfile und laden Sie das neue herunter. Entpacken Sie es und vergleichen Sie den Inhalt mittels &man.diff.1;. Wenn Sie nichts Verdächtiges sehen können Sie distinfo aktualisieren. Stellen Sie sicher, dass die Änderungen in Ihrem PR oder Commit-Protokoll zusammengefasst sind, um zu Gewährleisten, dass nichts Negatives passiert ist. Sie können auch mit den Autoren der Software in Verbindung treten und sich die Änderungen bestätigen lassen. Notwendige Abhilfen (Workarounds) Manchmal ist es nötig Fehler in Programmen, die mit älteren Versionen von &os; ausgeliefert werden, zu umgehen. Einige Versionen von &man.make.1; waren zumindest auf &os; 4.8 und 5.0 in Bezug auf die Behandlung von Vergleichen mit OSVERSION defekt. Dies führte häufig zu Fehlern während make describe (und damit auch während des make index für alle Ports). Abhilfe schafft hier, den bedingten Vergleich in Leerzeichen einzuschließen, z.B.: if ( ${OSVERSION} > 500023 ) Beachten Sie, dass eine Test-Installation eines Ports auf 4.9 oder 5.2 dieses Problem nicht aufspürt. Verschiedenes Die Dateien pkg-descr und pkg-plist sollten beide doppelt kontrolliert werden. Wenn Sie einen Port nachprüfen und glauben, dass man es besser machen kann, dann verbessern Sie ihn bitte. Bitte kopieren Sie nicht noch mehr Exemplare der GNU General Public License in unser System. Bitte überprüfen Sie alle gesetzlichen Punkte gründlich! Lassen Sie uns bitte keine illegale Software verbreiten!
Beispiel eines <filename>Makefile</filename> Hier ein Beispiel für ein Makefile, welches als Vorlage für einen neuen Port dienen kann. Alle zusätzlichen Kommentare in eckigen Klammern müssen entfernt werden! Es wird empfohlen, die hier gezeigte Formatierung zu übernehmen (Reihenfolge der Variablen, Leerzeichen zwischen einzelnen Abschnitten, usw.). Dadurch werden die wichtigen Informationen sofort ersichtlich. Zur Überprüfung Ihres Makefiles sollten Sie portlint verwenden. [the header...just to make it easier for us to identify the ports.] # New ports collection makefile for: xdvi [the "version required" line is only needed when the PORTVERSION variable is not specific enough to describe the port.] # Date created: 26 May 1995 [this is the person who did the original port to FreeBSD, in particular, the person who wrote the first version of this Makefile. Remember, this should not be changed when upgrading the port later.] # Whom: Satoshi Asami <asami@FreeBSD.org> # # $FreeBSD$ [ ^^^^^^^^^ This will be automatically replaced with RCS ID string by CVS when it is committed to our repository. If upgrading a port, do not alter this line back to "$FreeBSD$". CVS deals with it automatically.] # [section to describe the port itself and the master site - PORTNAME and PORTVERSION are always first, followed by CATEGORIES, and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR. PKGNAMEPREFIX and PKGNAMESUFFIX, if needed, will be after that. Then comes DISTNAME, EXTRACT_SUFX and/or DISTFILES, and then EXTRACT_ONLY, as necessary.] PORTNAME= xdvi PORTVERSION= 18.2 CATEGORIES= print [do not forget the trailing slash ("/")! if you are not using MASTER_SITE_* macros] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications PKGNAMEPREFIX= ja- DISTNAME= xdvi-pl18 [set this if the source is not in the standard ".tar.gz" form] EXTRACT_SUFX= .tar.Z [section for distributed patches -- can be empty] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [maintainer; *mandatory*! This is the person who is volunteering to handle port updates, build breakages, and to whom a users can direct questions and bug reports. To keep the quality of the Ports Collection as high as possible, we no longer accept new ports that are assigned to "ports@FreeBSD.org".] MAINTAINER= asami@FreeBSD.org COMMENT= A DVI Previewer for the X Window System [dependencies -- can be empty] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm [this section is for other standard bsd.port.mk variables that do not belong to any of the above] [If it asks questions during configure, build, install...] IS_INTERACTIVE= yes [If it extracts to a directory other than ${DISTNAME}...] WRKSRC= ${WRKDIR}/xdvi-new [If the distributed patches were not made relative to ${WRKSRC}, you may need to tweak this] PATCH_DIST_STRIP= -p1 [If it requires a "configure" script generated by GNU autoconf to be run] GNU_CONFIGURE= yes [If it requires GNU make, not /usr/bin/make, to build...] USE_GMAKE= yes [If it is an X application and requires "xmkmf -a" to be run...] USE_IMAKE= yes [et cetera.] [non-standard variables to be used in the rules below] MY_FAVORITE_RESPONSE= "yeah, right" [then the special rules, in the order they are called] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [and then the epilogue] .include <bsd.port.mk> Auf dem Laufenden bleiben Die &os; Ports-Sammlung verändert sich ständig. Hier finden Sie einige Informationen, wie Sie auf dem Laufenden bleiben. FreshPorts Einer der einfachsten Wege, um sich über Aktualisierungen, die bereits durchgeführt wurden, zu informieren, ist sich bei FreshPorts anzumelden. Sie können dort beliebige Ports auswählen, die Sie beobachten möchten. Maintainern wird ausdrücklich empfohlen sich anzumelden, da Sie nicht nur über Ihre eigenen Änderungen informiert werden, sondern auch über die aller anderen Committer (Diese sind oft nötig, um über Änderungen des zugrunde liegenden Frameworks informiert zu bleiben. Obwohl es höflich wäre, vorher über solche Änderungen benachrichtigt zu werden, wird es manchmal vergessen oder ist einfach nicht möglich. Außerdem sind die Änderungen manchmal nur sehr klein. Wir erwarten von jedem in solchen Fällen nach bestem Gewissen zu urteilen). Wenn Sie Fresh-Ports benutzen möchten, benötigen Sie nur einen Account. Falls Sie sich mit einer @FreeBSD.org E-Mailadresse registriert haben, werden Sie den Anmeldelink am rechten Rand der Seite finden. Diejenigen, die bereits einen FeshPorts-Account haben, aber nicht Ihre @FreeBSD.org E-Mailadresse benutzen, können einfach Ihre E-Mailadresse auf @FreeBSD.org ändern, sich anmelden, und dann die Änderung rückgängig machen. FreshPorts bietet auch eine Überprüfungsfunktion, die automatisch alle Committs zum &os; Ports-Baum testet. Wenn Sie sich für diesen Dienst anmelden, werden Sie über alle Fehler, die bei der Überprüfung Ihres Committs auftreten, informiert. Die Webschnittstelle zum Quelltext-Repository Es ist möglich die Dateien des Quellen-Repositories mit Hilfe einer Webschnittstelle durchzusehen. Änderungen, die das gesamte Ports-System betreffen, werden jetzt in der Datei CHANGES dokumentiert. Solche, die nur bestimmte Ports betreffen, in der Datei UPDATING. Aber die maßgebliche Antwort auf alle Fragen liegt zweifellos darin, den Quelltext von bsd.port.mk und dazugehörige Dateien zu lesen. Die &os; Ports-Mailingliste Wenn Sie Maintainer sind, sollten Sie in Erwägung ziehen die &a.ports;-Mailingliste zu verfolgen. Wichtige Änderungen an der grundlegenden Funktionsweise von Ports werden dort angekündigt und dann in CHANGES committet. Der Cluster zum Bauen von &os;-Ports auf <hostid role="hostname">pointyhat.FreeBSD.org</hostid> Eine der weniger bekannten Stärken von &os; ist es, dass ein ganzer Cluster von Maschinen nur dafür reserviert ist, andauernd die Ports-Sammlung zu bauen, und zwar für jedes große &os; Release und jede Tier-1-Architektur. Die Ergebnisse können Sie unter package building logs and errors finden. Alle Ports ausser denjenigen, die als IGNORE markiert sind, werden gebaut. Ports, die als BROKEN markiert sind, werden dennoch ausprobiert, um zu sehen, ob das zugrunde liegende Problem gelöst wurde (Dies wird erreicht, indem TRYBROKEN an das Makefile des Ports übergeben wird). - Die &os; Port-Distfile-Prüfung + Der &os; Ports-Distfile-Scanner Der Build-Cluster ist dazu bestimmt, das neueste Release jedes Ports aus bereits heruntergeladenden Distfiles zu bauen. Da sich das Internet aber ständig verändert, - können Distfiles schnell verloren gehen. Die FreeBSD - Ports Distfiles Prüfung versucht jeden + können Distfiles schnell verloren gehen. Der FreeBSD + Ports-Distfile-Scanner versucht jeden Download-Standort für jeden Port anzufragen, um herauszufinden, ob jedes Distfile noch verfügbar ist. Maintainer werden gebeten diesen Bericht regelmäßig durchzusehen, nicht nur, um den Build-Prozess für die Nutzer zu beschleunigen, sondern auch um zu vermeiden, dass auf den Maschinen, die freiwillig zur Verfügung gestellt werden, um all diese Dateien anzubieten, Ressourcen verschwendet werden. Das &os; Ports-Monitoring-System Eine weitere praktische Ressource ist das FreeBSD Ports-Monitoring-System (auch bekannt als portsmon). Dieses System besteht aus einer Datenbank, die Informationen von mehreren Quellen bezieht und es erlaubt diese über ein Webinterface abzufragen. Momentan werden die Ports-Problemberichte (PRs), die Fehlerprotokolle des Build-Clusters und die einzelnen Dateien der Ports-Sammlung verwendet. In Zukunft soll das auf die Distfile-Prüfung und weitere Informationsquellen ausgedehnt werden. Als Ausgangspunkt können Sie alle Informationen eines Ports mit Hilfe der Übersicht eines Ports betrachten. Zum Zeitpunkt des Schreibens ist dies die einzige Quelle, die GNATS PR-Einträge auf Portnamen abbildet (PR-Einreicher geben den Portnamen nicht immer in der Zusammenfassung an, obwohl wir uns das wünschen würden). Also ist portsmon ein guter Anlaufpunkt, wenn Sie herausfinden wollen, ob zu einem existierenden Port PRs oder Buildfehler eingetragen sind. Oder um herauszufinden, ob ein neuer Port, den Sie erstellen wollen, bereits eingereicht wurde.
diff --git a/de_DE.ISO8859-1/share/sgml/mailing-lists.ent b/de_DE.ISO8859-1/share/sgml/mailing-lists.ent index fc05aeb3a8..8ac36d96a1 100644 --- a/de_DE.ISO8859-1/share/sgml/mailing-lists.ent +++ b/de_DE.ISO8859-1/share/sgml/mailing-lists.ent @@ -1,639 +1,645 @@ FreeBSD list server"> &a.mailman.listinfo;"> de-bsd-translators@de.FreeBSD.org"> de-bsd-questions@de.FreeBSD.org"> FreeBSD ACPI"> freebsd-acpi"> FreeBSD advocacy"> freebsd-advocacy"> FreeBSD AFS porting"> freebsd-afs"> FreeBSD Adapteci AIC7xxx discussions"> freebsd-aic7xxx"> FreeBSD Alpha porting"> freebsd-alpha"> Porting FreeBSD to AMD64 systems"> freebsd-amd64"> FreeBSD announcements"> freebsd-announce"> FreeBSD Apache"> freebsd-apache"> FreeBSD architecture and design"> freebsd-arch"> FreeBSD ARM porting"> freebsd-arm"> FreeBSD ATM networking"> freebsd-atm"> FreeBSD source code audit"> freebsd-audit"> FreeBSD binary update system"> freebsd-binup"> FreeBSD Bluetooth mailing list"> freebsd-bluetooth"> FreeBSD bugbusters"> freebsd-bugbusters"> FreeBSD problem reports"> freebsd-bugs"> FreeBSD chat"> freebsd-chat"> FreeBSD clustering"> freebsd-cluster"> FreeBSD committers"> FreeBSD core team"> &os.current;"> freebsd-current"> CTM announcements"> ctm-announce"> CTM distribution of CVS files"> ctm-cvs-cur"> CTM 4-STABLE src branch distribution"> ctm-src-4"> CTM -CURRENT src branch distribution"> ctm-src-cur"> CTM user discussion"> ctm-users"> FreeBSD CVS commit message"> cvs-all"> FreeBSD CVS doc commit"> cvs-doc"> FreeBSD CVS ports commit"> cvs-ports"> FreeBSD CVS projects commit"> cvs-projects"> FreeBSD CVS src commit"> cvs-src"> FreeBSD CVSweb maintenance"> freebsd-cvsweb"> FreeBSD based Databases"> freebsd-database"> FreeBSD developers"> Writing device drivers for FreeBSD"> freebsd-drivers"> FreeBSD documentation project"> freebsd-doc"> FreeBSD doc/ Committer"> FreeBSD doc/ developers"> FreeBSD users of Eclipse EDI, tools, rich client apps and ports."> freebsd-eclipse"> FreeBSD-embedded mailing list"> freebsd-embedded"> FreeBSD-emulation"> freebsd-emulation"> FreeBSD-eol mailing list"> freebsd-eol"> FreeBSD FireWire (IEEE 1394) discussion"> freebsd-firewire"> FreeBSD filesystem project"> freebsd-fs"> FreeBSD gecko mailing list"> freebsd-gecko"> FreeBSD GEOM"> freebsd-geom"> FreeBSD GNOME and GNOME applications"> freebsd-gnome"> FreeBSD technical discussions"> freebsd-hackers"> FreeBSD hardware and equipment"> freebsd-hardware"> FreeBSD mirror sites"> freebsd-hubs"> FreeBSD internationalization"> freebsd-i18n"> FreeBSD i386-specific issues"> freebsd-i386"> FreeBSD IA32 porting"> freebsd-ia32"> FreeBSD IA64 porting"> freebsd-ia64"> FreeBSD IPFW code"> freebsd-ipfw"> FreeBSD ISDN"> freebsd-isdn"> FreeBSD Internet service providers"> freebsd-isp"> FreeBSD jails mailing list"> freebsd-jail"> FreeBSD Java Language"> freebsd-java"> FreeBSD related employment"> freebsd-jobs"> FreeBSD KDE/Qt and KDE applications"> freebsd-kde"> FreeBSD LFS porting"> freebsd-lfs"> FreeBSD libh installation and packaging system"> freebsd-libh"> FreeBSD MIPS porting"> freebsd-mips"> FreeBSD mirror site administrators"> mirror-announce"> FreeBSD laptop computer"> freebsd-mobile"> Mono and C# applications on FreeBSD"> freebsd-mono"> FreeBSD port of the Mozilla browser"> freebsd-mozilla"> FreeBSD multimedia"> freebsd-multimedia"> FreeBSD networking"> freebsd-net"> FreeBSD new users"> freebsd-newbies"> New Bus Architecture"> freebsd-new-bus"> FreeBSD OpenOffice"> freebsd-openoffice"> FreeBSD performance"> freebsd-performance"> FreeBSD Perl"> freebsd-perl"> FreeBSD packet filter mailing list"> freebsd-pf"> FreeBSD non-Intel platforms porting"> freebsd-platforms"> FreeBSD core team policy decisions"> freebsd-policy"> FreeBSD ports"> freebsd-ports"> FreeBSD ports/ developers"> FreeBSD ports bugs"> freebsd-ports-bugs"> FreeBSD ports/ Committer"> FreeBSD PowerPC porting"> freebsd-ppc"> Technical discussion of FreeBSD on HP ProLiant server platforms"> freebsd-proliant"> FreeBSD Python mailing list"> freebsd-python"> FreeBSD Quality Assurance"> freebsd-qa"> FreeBSD general questions"> freebsd-questions"> FreeBSD boot script system mailing list"> freebsd-rc"> FreeBSD realtime extensions"> freebsd-realtime"> FreeBSD Ruby mailing list"> freebsd-ruby"> FreeBSD SCSI subsystem"> freebsd-scsi"> FreeBSD security"> freebsd-security"> FreeBSD security notifications"> freebsd-security-notifications"> FreeBSD-small"> freebsd-small"> FreeBSD symmetric multiprocessing"> freebsd-smp"> FreeBSD SPARC porting"> freebsd-sparc64"> FreeBSD src/ Committer"> FreeBSD src/ developers"> &os.stable;"> freebsd-stable"> FreeBSD C99 and POSIX compliance"> freebsd-standards"> FreeBSD sun4v porting mailing list"> freebsd-sun4v"> SVN commit messages for the entire src tree (except for user and projects)"> svn-src-all"> SVN commit messages for the src tree for head/-current"> svn-src-head"> SVN commit messages for the src projects tree"> svn-src-projects"> SVN commit messages for releases in the src tree"> svn-src-release"> SVN commit messages for the release engineering / security commits to the src tree"> svn-src-releng"> SVN commit messages for all the -stable branches of the src tree"> svn-src-stable"> SVN commit messages for only the 6-stable src tree"> svn-src-stable-6"> SVN commit messages for only the 7-stable src tree"> svn-src-stable-7"> SVN commit messages for only the 8-stable src tree"> svn-src stable-8"> SVN commit messages for the old stable src trees"> svn-src-stable-other"> SVN commit messages for the admin / configuration tree"> svn-src-svnadmin"> SVN commit messages for the experimental user src tree"> svn-src-user"> SVN commit messages for the vendor work area tree"> svn-src-vendor"> + + +Sysinstall + development mailing list"> +freebsd-sysinstall"> FreeBSD test"> freebsd-test"> FreeBSD performance and stability testing"> freebsd-testing"> FreeBSD threads"> freebsd-threads"> FreeBSD tokenring"> freebsd-tokenring"> FreeBSD USB"> freebsd-usb"> FreeBSD user group coordination"> freebsd-user-groups"> FreeBSD vendors pre-release coordination"> freebsd-vendors"> Discussion of various virtualization techniques supported by FreeBSD"> freebsd-virtualization"> Diskussion über die Infrastruktur von VuXML"> freebsd-vuxml"> FreeBSD Work-In-Progress Status"> freebsd-wip-status"> FreeBSD Webmaster"> freebsd-www"> FreeBSD X11 mailing list"> freebsd-x11"> FreeBSD port to Xen mailing list"> freebsd-xen"> bug-followup@FreeBSD.org"> majordomo@FreeBSD.org">