- Please welcome to the german translation of the developers-handbook.
- This work was done by the FreeBSD German Documentation Project. A list of people involved in this translation can be found under https://doc.bsdgroup.de/status/developers-handbook.html
This commit is contained in:
Martin Wilke
parent
863ce6a488
commit
8c3cd27b1b
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=33829
18 changed files with 15715 additions and 1 deletions
de_DE.ISO8859-1/books
Makefile
developers-handbook
Makefilebook.sgmlchapters.ent
dma
introduction
ipv6
kernelbuild
kerneldebug
l10n
policies
secure
sockets
testing
tools
x86
|
|
@ -6,7 +6,8 @@
|
|||
# $FreeBSDde: de-docproj/books/Makefile,v 1.6 2007/08/20 19:11:15 jkois Exp $
|
||||
#
|
||||
|
||||
SUBDIR = faq
|
||||
SUBDIR = developers-handbook
|
||||
SUBDIR+= faq
|
||||
SUBDIR+= fdp-primer
|
||||
SUBDIR+= handbook
|
||||
SUBDIR+= porters-handbook
|
||||
|
|
|
|||
50
de_DE.ISO8859-1/books/developers-handbook/Makefile
Normal file
50
de_DE.ISO8859-1/books/developers-handbook/Makefile
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
# The FreeBSD Documentation Project
|
||||
# The FreeBSD German Documentation Project
|
||||
#
|
||||
# $FreeBSD$
|
||||
# $FreeBSDde: de-docproj/books/developers-handbook/Makefile,v 1.2 2007/08/31 01:42:15 as Exp $
|
||||
# basiert auf: 1.23
|
||||
#
|
||||
# Build the FreeBSD Developers' Handbook.
|
||||
#
|
||||
|
||||
MAINTAINER=doc@FreeBSD.org
|
||||
|
||||
DOC?= book
|
||||
|
||||
FORMATS?= html-split
|
||||
|
||||
HAS_INDEX= true
|
||||
|
||||
INSTALL_COMPRESSED?= gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
# Images
|
||||
IMAGES_EN= sockets/layers.eps sockets/sain.eps sockets/sainfill.eps sockets/sainlsb.eps sockets/sainmsb.eps sockets/sainserv.eps sockets/serv.eps sockets/serv2.eps sockets/slayers.eps
|
||||
|
||||
#
|
||||
# SRCS lists the individual SGML files that make up the document. Changes
|
||||
# to any of these files will force a rebuild
|
||||
#
|
||||
|
||||
# SGML content
|
||||
SRCS= book.sgml
|
||||
SRCS+= dma/chapter.sgml
|
||||
SRCS+= introduction/chapter.sgml
|
||||
SRCS+= ipv6/chapter.sgml
|
||||
SRCS+= kernelbuild/chapter.sgml
|
||||
SRCS+= kerneldebug/chapter.sgml
|
||||
SRCS+= l10n/chapter.sgml
|
||||
SRCS+= policies/chapter.sgml
|
||||
SRCS+= secure/chapter.sgml
|
||||
SRCS+= sockets/chapter.sgml
|
||||
SRCS+= testing/chapter.sgml
|
||||
SRCS+= tools/chapter.sgml
|
||||
SRCS+= x86/chapter.sgml
|
||||
|
||||
# Entities
|
||||
|
||||
URL_RELPREFIX?= ../../../..
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
238
de_DE.ISO8859-1/books/developers-handbook/book.sgml
Normal file
238
de_DE.ISO8859-1/books/developers-handbook/book.sgml
Normal file
|
|
@ -0,0 +1,238 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/book.sgml,v 1.10 2009/02/10 12:55:14 jkois Exp $
|
||||
basiert auf: 1.55
|
||||
-->
|
||||
|
||||
<!DOCTYPE BOOK PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
<!ENTITY % books.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Books Entity Set//DE">
|
||||
%books.ent;
|
||||
<!ENTITY % chapters SYSTEM "chapters.ent"> %chapters;
|
||||
<!ENTITY % chap.index "IGNORE">
|
||||
]>
|
||||
|
||||
<book lang="de">
|
||||
<bookinfo>
|
||||
<title>FreeBSD Developers' Handbook</title>
|
||||
|
||||
<corpauthor>The FreeBSD Documentation Project</corpauthor>
|
||||
|
||||
<pubdate>August 2000</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2000</year>
|
||||
<year>2001</year>
|
||||
<year>2002</year>
|
||||
<year>2003</year>
|
||||
<year>2004</year>
|
||||
<year>2005</year>
|
||||
<year>2006</year>
|
||||
<holder>The FreeBSD Documentation Project</holder>
|
||||
</copyright>
|
||||
|
||||
<copyright>
|
||||
<year>2008</year>
|
||||
<year>2009</year>
|
||||
<holder>The FreeBSD German Documentation Project</holder>
|
||||
</copyright>
|
||||
|
||||
&bookinfo.legalnotice;
|
||||
|
||||
<legalnotice id="trademarks" role="trademarks">
|
||||
&tm-attrib.freebsd;
|
||||
&tm-attrib.apple;
|
||||
&tm-attrib.ibm;
|
||||
&tm-attrib.ieee;
|
||||
&tm-attrib.intel;
|
||||
&tm-attrib.linux;
|
||||
&tm-attrib.microsoft;
|
||||
&tm-attrib.opengroup;
|
||||
&tm-attrib.sun;
|
||||
&tm-attrib.general;
|
||||
</legalnotice>
|
||||
|
||||
<abstract>
|
||||
<para>Willkommen zum Entwickler-Handbuch. Dieses Handbuch ist
|
||||
<emphasis>jederzeit unter Bearbeitung</emphasis> und das
|
||||
Ergebnis der Arbeit vieler Einzelpersonen. Dies kann
|
||||
dazu führen, dass bestimmte Bereiche nicht mehr aktuell
|
||||
sind und auf den neuesten Stand gebracht werden müssen.
|
||||
Bei Unklarheiten empfiehlt es sich daher stets, auch die
|
||||
<ulink
|
||||
url="&url.base;/doc/en_US.ISO8859-1/books/developers-handbook/index.html">
|
||||
englische Originalversion</ulink> des Handbuchs zu lesen.</para>
|
||||
|
||||
<para>Wenn Sie bei der Übersetzung dieses Handbuchs mithelfen
|
||||
möchten, senden Sie bitte eine E-Mail an die Mailingliste
|
||||
&a.de.translators;.</para>
|
||||
|
||||
<para>Die aktuelle Version dieses Handbuchs ist immer auf dem
|
||||
<ulink url="http://www.FreeBSD.org/">&os;-Webserver</ulink>
|
||||
verfügbar und kann in verschiedenen Formaten und in
|
||||
komprimierter Form vom <ulink
|
||||
url="ftp://ftp.FreeBSD.org/pub/FreeBSD/doc">&os;-FTP-Server</ulink>
|
||||
oder einem der zahlreichen <ulink
|
||||
url="&url.base;/doc/de_DE.ISO8859-1/books/handbook/mirrors-ftp.html">Spiegel</ulink>
|
||||
herunter geladen werden (ältere Versionen finden Sie hingegen
|
||||
unter <ulink url="http://docs.FreeBSD.org/doc/"></ulink>).</para>
|
||||
</abstract>
|
||||
</bookinfo>
|
||||
|
||||
<part id="Basics">
|
||||
<title>Grundlagen</title>
|
||||
|
||||
&chap.introduction;
|
||||
&chap.tools;
|
||||
&chap.secure;
|
||||
&chap.l10n;
|
||||
&chap.policies;
|
||||
&chap.testing;
|
||||
</part>
|
||||
|
||||
<part id="ipc">
|
||||
<title>Interprozess-Kommunikation</title>
|
||||
|
||||
&chap.sockets;
|
||||
&chap.ipv6;
|
||||
|
||||
</part>
|
||||
|
||||
<part id="kernel">
|
||||
<title>Kernel</title>
|
||||
|
||||
&chap.dma;
|
||||
&chap.kernelbuild;
|
||||
&chap.kerneldebug;
|
||||
|
||||
</part>
|
||||
|
||||
<part id="architectures">
|
||||
<title>Architekturen</title>
|
||||
|
||||
&chap.x86;
|
||||
|
||||
</part>
|
||||
|
||||
<part id="appendices">
|
||||
<title>Anhang</title>
|
||||
|
||||
<bibliography>
|
||||
|
||||
<biblioentry id="COD" xreflabel="1">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Dave</firstname>
|
||||
<othername role="MI">A</othername>
|
||||
<surname>Patterson</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>John</firstname>
|
||||
<othername role="MI">L</othername>
|
||||
<surname>Hennessy</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright><year>1998</year><holder>Morgan Kaufmann Publishers,
|
||||
Inc.</holder></copyright>
|
||||
<isbn>1-55860-428-6</isbn>
|
||||
<publisher>
|
||||
<publishername>Morgan Kaufmann Publishers, Inc.</publishername>
|
||||
</publisher>
|
||||
<title>Computer Organization and Design</title>
|
||||
<subtitle>The Hardware / Software Interface</subtitle>
|
||||
<pagenums>1-2</pagenums>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="2">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>W.</firstname>
|
||||
<othername role="Middle">Richard</othername>
|
||||
<surname>Stevens</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright><year>1993</year><holder>Addison Wesley Longman,
|
||||
Inc.</holder></copyright>
|
||||
<isbn>0-201-56317-7</isbn>
|
||||
<publisher>
|
||||
<publishername>Addison Wesley Longman, Inc.</publishername>
|
||||
</publisher>
|
||||
<title>Advanced Programming in the Unix Environment</title>
|
||||
<pagenums>1-2</pagenums>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="3">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Marshall</firstname>
|
||||
<othername role="Middle">Kirk</othername>
|
||||
<surname>McKusick</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>George</firstname>
|
||||
<surname>Neville-Neil</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright><year>2004</year><holder>Addison-Wesley Publishing Company,
|
||||
Inc.</holder></copyright>
|
||||
<isbn>0-201-70245-2</isbn>
|
||||
<publisher>
|
||||
<publishername>Addison-Wesley</publishername>
|
||||
</publisher>
|
||||
<title>The Design and Implementation of the FreeBSD Operating System</title>
|
||||
<pagenums>1-2</pagenums>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="Phrack" xreflabel="4">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Aleph</firstname>
|
||||
<surname>One</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<title>Phrack 49; "Smashing the Stack for Fun and Profit"</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="StackGuard" xreflabel="5">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Chrispin</firstname>
|
||||
<surname>Cowan</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Calton</firstname>
|
||||
<surname>Pu</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Dave</firstname>
|
||||
<surname>Maier</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<title>StackGuard; Automatic Adaptive Detection and Prevention of
|
||||
Buffer-Overflow Attacks</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="OpenBSD" xreflabel="6">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Todd</firstname>
|
||||
<surname>Miller</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Theo</firstname>
|
||||
<surname>de Raadt</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<title>strlcpy and strlcat -- consistent, safe string copy and
|
||||
concatenation.</title>
|
||||
</biblioentry>
|
||||
|
||||
</bibliography>
|
||||
|
||||
</part>
|
||||
|
||||
<![ %chap.index; [ &chap.index; ]]>
|
||||
|
||||
</book>
|
||||
37
de_DE.ISO8859-1/books/developers-handbook/chapters.ent
Normal file
37
de_DE.ISO8859-1/books/developers-handbook/chapters.ent
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
Creates entities for each chapter in the FreeBSD Developer's
|
||||
Handbook. Each entity is named chap.foo, where foo is the value
|
||||
of the id attribute on that chapter, and corresponds to the name of
|
||||
the directory in which that chapter's .sgml file is stored.
|
||||
|
||||
Chapters should be listed in the order in which they are referenced.
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/chapters.ent,v 1.2 2007/08/31 01:42:15 as Exp $
|
||||
-->
|
||||
|
||||
<!-- Part one -->
|
||||
<!ENTITY chap.introduction SYSTEM "introduction/chapter.sgml">
|
||||
<!ENTITY chap.tools SYSTEM "tools/chapter.sgml">
|
||||
<!ENTITY chap.secure SYSTEM "secure/chapter.sgml">
|
||||
<!ENTITY chap.l10n SYSTEM "l10n/chapter.sgml">
|
||||
<!ENTITY chap.policies SYSTEM "policies/chapter.sgml">
|
||||
<!ENTITY chap.testing SYSTEM "testing/chapter.sgml">
|
||||
|
||||
<!-- Part two - IPC -->
|
||||
<!ENTITY chap.sockets SYSTEM "sockets/chapter.sgml">
|
||||
<!ENTITY chap.ipv6 SYSTEM "ipv6/chapter.sgml">
|
||||
|
||||
<!-- Part three - Kernel -->
|
||||
<!ENTITY chap.dma SYSTEM "dma/chapter.sgml">
|
||||
<!ENTITY chap.kernelbuild SYSTEM "kernelbuild/chapter.sgml">
|
||||
<!ENTITY chap.kerneldebug SYSTEM "kerneldebug/chapter.sgml">
|
||||
|
||||
<!-- Part five - Architectures -->
|
||||
<!ENTITY chap.x86 SYSTEM "x86/chapter.sgml">
|
||||
|
||||
<!-- Part six - Appendices -->
|
||||
<!ENTITY chap.index SYSTEM "index.sgml">
|
||||
1477
de_DE.ISO8859-1/books/developers-handbook/dma/chapter.sgml
Normal file
1477
de_DE.ISO8859-1/books/developers-handbook/dma/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,275 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/introduction/chapter.sgml,v 1.10 2008/01/24 19:34:49 seirei Exp $
|
||||
basiert auf: 1.18
|
||||
-->
|
||||
|
||||
<chapter id="introduction">
|
||||
<chapterinfo>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Murray</firstname>
|
||||
<surname>Stokely</surname>
|
||||
<contrib>Beigetragen von </contrib>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Jeroen</firstname>
|
||||
<surname>Ruigrok van der Werven</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Fabian</firstname>
|
||||
<surname>Borschel</surname>
|
||||
<contrib>Übersetzt von </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</chapterinfo>
|
||||
|
||||
<title>Einführung</title>
|
||||
|
||||
<sect1 id="introduction-devel">
|
||||
<title>Unter FreeBSD entwickeln</title>
|
||||
|
||||
<para>Hier sind wir also. Ihr System ist vollständig
|
||||
installiert und Sie wollen mit dem Programmieren beginnen.
|
||||
Aber womit sollen Sie anfangen? Was bietet Ihnen FreeBSD?
|
||||
Was kann es für einen Programmierer tun?</para>
|
||||
|
||||
<para>Dies sind einige der Fragen, welche dieses Handbuch
|
||||
zu beantworten versucht. Natürlich gibt es, analog zu
|
||||
anderen Berufen, auch bei Programmierern unterschiedliche
|
||||
Leistungsniveaus. Für die einen ist es ein Hobby,
|
||||
für die anderen ist es der Beruf. Die Informationen
|
||||
in diesem Kapitel dürften eher für den
|
||||
Programmieranfänger geeignet sein; allerdings könnte
|
||||
es auch für Programmierer, die bisher nichts mit der
|
||||
&os;-Plattform zu tun hatten, interessante Informationen
|
||||
enthalten.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="introduction-bsdvision">
|
||||
<title>Die Vision von BSD</title>
|
||||
|
||||
<para>Ziel ist es, das bestmögliche &unix;-artige
|
||||
Betriebssystempaket zu erstellen, mit dem gebührenden
|
||||
Respekt gegenüber der Ideologie der ursprünglichen
|
||||
Software, sowie der Bedienbarkeit, Leistungsfähigkeit und
|
||||
Stabilität.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="introduction-archguide">
|
||||
<title>Grundlegende Richtlinien</title>
|
||||
|
||||
<para>Unsere Ideologie kann durch die folgenden Leitfäden
|
||||
beschrieben werden.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Füge keine neue Funktionalität hinzu, solange
|
||||
ein Programmierer diese nicht zur Fertigstellung einer
|
||||
realen Anwendung benötigt.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Zu entscheiden, was ein System ist, ist genauso
|
||||
wichtig wie zu entscheiden, was ein System nicht ist.
|
||||
Versuchen Sie nicht, alle möglichen Wünsche zu
|
||||
erfüllen; machen Sie lieber das System erweiterbar, so
|
||||
dass zusätzliche Bedürfnisse in einer
|
||||
aufwärtskompatiblen Weise bedient werden
|
||||
können.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Das Einzige, das schlimmer ist, als von einem Beispiel
|
||||
auf die Allgemeinheit zu schließen, ist, von
|
||||
überhaupt keinem Beispiel auf die Allgemeinheit zu
|
||||
schließen.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Solange ein Problem nicht vollständig verstanden
|
||||
wurde, ist es besser, keine Lösung
|
||||
bereitzustellen.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wenn Sie 90% des gewünschten Effektes bei nur 10%
|
||||
des Aufwands erreichen können, sollten Sie besser die
|
||||
einfachere Lösung verwenden.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Grenzen Sie Komplexität so gut wie möglich
|
||||
ein.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stellen Sie Mechanismen anstelle von Strategien bereit.
|
||||
Überlassen Sie insbesondere Strategien für die
|
||||
Benutzerschnittstelle dem Benutzerprogramm.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Aus Scheifler & Gettys: "X Window System"</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="introduction-layout">
|
||||
<title>Der Aufbau von
|
||||
<filename class="directory">/usr/src</filename></title>
|
||||
|
||||
<para>Der vollständige Quelltext von FreeBSD ist über
|
||||
das öffentliche CVS-Repository verfügbar. Der
|
||||
Quelltext wird normalerweise in <filename
|
||||
class="directory">/usr/src</filename> abgelegt und enthält
|
||||
die folgenden Unterverzeichnisse:</para>
|
||||
|
||||
<para>
|
||||
<informaltable frame="none" pgwide="1">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Verzeichnis</entry>
|
||||
<entry>Beschreibung</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">bin/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in
|
||||
<filename>/bin</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">contrib/</filename></entry>
|
||||
<entry>Quelldateien für Dateien von beigesteuerter
|
||||
Software</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">crypto/</filename></entry>
|
||||
<entry>Quelldateien für die Kryptographie</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">etc/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in <filename
|
||||
class="directory">/etc</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">games/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in <filename
|
||||
class="directory">/usr/games</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">gnu/</filename></entry>
|
||||
<entry>Programme, die unter der GNU Public License
|
||||
stehen</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">include/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in <filename
|
||||
class="directory">/usr/include</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">kerberos5/</filename></entry>
|
||||
<entry>Quelldateien für Kerberos Version 5</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">lib/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in <filename
|
||||
class="directory">/usr/lib</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">libexec/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in <filename
|
||||
class="directory">/usr/libexec</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">release/</filename></entry>
|
||||
<entry>Dateien, die für die Erstellung eines
|
||||
FreeBSD-Releases nötig sind</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">rescue/</filename></entry>
|
||||
<entry>Bausystem für die <filename
|
||||
class="directory">/rescue</filename>-Programme</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">sbin/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in <filename
|
||||
class="directory">/sbin</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">secure/</filename></entry>
|
||||
<entry>Quelldateien für FreeSec</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">share/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in <filename
|
||||
class="directory">/usr/share</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">sys/</filename></entry>
|
||||
<entry>Kernel-Quelldateien</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">tools/</filename></entry>
|
||||
<entry>Programme zum Verwalten und Testen von
|
||||
FreeBSD</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">usr.bin/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in <filename
|
||||
class="directory">/usr/bin</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class="directory">usr.sbin/</filename></entry>
|
||||
<entry>Quelldateien für Dateien in <filename
|
||||
class="directory">/usr/sbin</filename></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
1914
de_DE.ISO8859-1/books/developers-handbook/ipv6/chapter.sgml
Normal file
1914
de_DE.ISO8859-1/books/developers-handbook/ipv6/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,107 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/kernelbuild/chapter.sgml,v 1.4 2007/09/04 13:24:23 as Exp $
|
||||
basiert auf: 1.1
|
||||
-->
|
||||
|
||||
<chapter id="kernelbuild">
|
||||
<chapterinfo>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Johann</firstname>
|
||||
<surname>Kois</surname>
|
||||
<contrib>Übersetzt von </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</chapterinfo>
|
||||
|
||||
<title>Einen &os;-Kernel bauen und installieren</title>
|
||||
|
||||
<para>Ein Kernelentwickler muss wissen, wie der Bau eines angepassten
|
||||
Kernels funktioniert, da das Debuggen des &os;-Kernels nur durch den
|
||||
Bau eines neuen Kernels möglich ist. Es gibt zwei Wege, einen
|
||||
angepassten Kernel zu bauen:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Den <quote>traditionellen</quote> Weg</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Den <quote>neuen</quote> Weg</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<note>
|
||||
<para>Die folgenden Ausführungen setzen voraus, dass Sie
|
||||
den Abschnitt <ulink
|
||||
url="../handbook/kernelconfig-building.html">
|
||||
Erstellen und Installation eines angepassten Kernels</ulink> des
|
||||
FreeBSD-Handbuchs gelesen haben und daher wissen, wie man einen
|
||||
FreeBSD-Kernel baut.</para>
|
||||
</note>
|
||||
|
||||
<sect1 id="kernelbuild-traditional">
|
||||
<title>Einen Kernel auf die <quote>traditionelle</quote> Art und
|
||||
Weise bauen</title>
|
||||
|
||||
<para>Bis &os; 4.X wurde dieser Weg zum Bau eines angepassten
|
||||
Kernels empfohlen. Sie können Ihren Kernel nach wie vor
|
||||
auf diese Art und Weise bauen (anstatt das Target
|
||||
<quote>buildkernel</quote> der Makefiles im Verzeichnis
|
||||
<filename role="directory">/usr/src/</filename> zu verwenden).
|
||||
Dies kann beispielsweise sinnvoll sein, wenn Sie am
|
||||
Kernel-Quellcode arbeiten. Haben Sie nur ein oder zwei Optionen
|
||||
der Kernelkonfigurationsdatei geändert, ist dieser Weg in
|
||||
der Regel schneller als der <quote>neue</quote> Weg.
|
||||
Andererseits kann es aber auch zu unerwarteten Fehlern beim
|
||||
Bau des Kernels kommen, wenn Sie Ihren Kernel unter aktuellen
|
||||
&os;-Versionen auf diese Art und Weise bauen.</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<para>Erzeugen Sie den Kernel-Quellcode mit
|
||||
&man.config.8;:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/usr/sbin/config <replaceable>MYKERNEL</replaceable></userinput></screen>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Wechseln Sie in das Build-Verzeichnis. &man.config.8;
|
||||
gibt den Namen dieses Verzeichnisses aus, wenn die Erzeugung
|
||||
des Kernel-Quellcodes im vorherigen Schritt erfolgreich
|
||||
abgeschlossen wurde.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd ../compile/<replaceable>MYKERNEL</replaceable></userinput></screen>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Kompilieren Sie den neuen Kernel:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>make depend</userinput>
|
||||
&prompt.root; <userinput>make</userinput></screen>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Installieren Sie den neuen Kernel:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>make install</userinput></screen>
|
||||
</step>
|
||||
</procedure>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="kernelbuild-new">
|
||||
<title>Einen Kernel auf die <quote>neue</quote> Art und Weise
|
||||
bauen</title>
|
||||
|
||||
<para>Dieser Weg wird für alle aktuellen &os;-Versionen
|
||||
empfohlen. Lesen Sie bitte den Abschnitt <ulink
|
||||
url="../handbook/kernelconfig-building.html">Erstellen und
|
||||
Installation eines angepassten Kernels</ulink> des
|
||||
&os;-Handbuchs, wenn Sie Ihren Kernel auf diese Art und Weise
|
||||
bauen wollen.</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
# The FreeBSD Documentation Project
|
||||
# The FreeBSD German Documentation Project
|
||||
#
|
||||
# Build the Handbook with just the content from this chapter.
|
||||
#
|
||||
# $FreeBSD$
|
||||
# $FreeBSDde: de-docproj/books/developers-handbook/kerneldebug/Makefile,v 1.2 2007/08/31 06:13:09 as Exp $
|
||||
# basiert auf: 1.1
|
||||
#
|
||||
|
||||
CHAPTERS= kerneldebug/chapter.sgml
|
||||
|
||||
VPATH= ..
|
||||
|
||||
MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX}
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../../..
|
||||
|
||||
.include "../Makefile"
|
||||
1245
de_DE.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
Normal file
1245
de_DE.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
104
de_DE.ISO8859-1/books/developers-handbook/l10n/chapter.sgml
Normal file
104
de_DE.ISO8859-1/books/developers-handbook/l10n/chapter.sgml
Normal file
|
|
@ -0,0 +1,104 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/l10n/chapter.sgml,v 1.9 2007/09/28 16:25:36 jkois Exp $
|
||||
basiert auf: 1.10
|
||||
-->
|
||||
|
||||
<chapter id="l10n">
|
||||
<chapterinfo>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Jochen</firstname>
|
||||
<surname>Neumeister</surname>
|
||||
<contrib>Übersetzt von </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</chapterinfo>
|
||||
|
||||
<title>Lokalisierung und Internationalisierung - L10N und
|
||||
I18N</title>
|
||||
|
||||
<sect1 id="l10n-programming">
|
||||
<title>I18N-konforme Anwendungen programmieren</title>
|
||||
|
||||
<indexterm><primary>Qt</primary></indexterm>
|
||||
<indexterm><primary>GTK</primary></indexterm>
|
||||
|
||||
<para>Um Ihre Anwendung verwendbarer für andere
|
||||
Sprachen zu machen, hoffen wir, dass Sie I18N-konform
|
||||
programmieren. Der GNU gcc-Compiler und Bibliotheken
|
||||
für grafische Benutzeroberflächen wie QT und GTK
|
||||
unterstützen I18N durch eine spezielle Verarbeitung von
|
||||
Zeichenketten. Das Erstellen eines I18N-konformen Programms
|
||||
ist sehr einfach und erlaubt anderen Mitwirkenden, Ihre
|
||||
Programme leichter in andere Sprachen zu übersetzen.
|
||||
Lesen Sie die Bibliothek-spezifischen I18N-Dokumentationen
|
||||
für weitere Details.</para>
|
||||
|
||||
<para>Im Gegensatz zur allgemeinen Meinung ist I18N-konformer
|
||||
Code einfach zu programmieren. Üblicherweise umfasst
|
||||
dies nur das Einbetten Ihrer Zeichenketten in
|
||||
Bibliothek-spezifische Funktionen. Stellen Sie außerdem
|
||||
bitte sicher, dass Sie Unterstützung für Unicode- und
|
||||
Multibyte-Zeichen vorsehen.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Ein Aufruf, die I18N-Bemühungen zu
|
||||
vereinheitlichen</title>
|
||||
|
||||
<para>Wir sind darauf aufmerksam geworden, dass die
|
||||
einzelnen I18N-/L10N-Bemühungen für jedes Land
|
||||
wiederholt wurden. Viele von uns haben somit unproduktiverweise
|
||||
das Rad immer wieder neu erfunden. Wir hoffen, dass die
|
||||
verschiedenen großen Gruppen für I18N Ihre
|
||||
Bemühungen in einer Gruppe vereinen können,
|
||||
ähnlich der Zuständigkeit des Core-Teams.</para>
|
||||
|
||||
<para>Derzeit hoffen wir, dass wenn Sie I18N-konforme
|
||||
Programme schreiben oder portieren, diese an die
|
||||
betreffenden FreeBSD-Mailinglisten jedes Landes schicken, um
|
||||
sie testen zu lassen. Wir hoffen in Zukunft, Anwendungen zu
|
||||
entwickeln, die in allen Sprachen direkt und ohne unsaubere
|
||||
Änderungen funktionieren.</para>
|
||||
|
||||
<para>Die &a.i18n;-Mailingliste ist eingerichtet worden. Wenn
|
||||
Sie I18N-/L10N-Entwickler sind, schicken Sie bitte Ihre
|
||||
Kommentare, Ideen, Fragen und alles, das Sie mit dem Thema in
|
||||
Verbindung bringen, dorthin.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Perl und Python</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>Perl</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>Python</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Perl und Python bieten Bibliotheken für I18N und zur
|
||||
Behandlung von Unicode-Zeichen. Bitte nutzen Sie diese
|
||||
für I18N-Konformität.</para>
|
||||
|
||||
<para>Auf älteren FreeBSD-Versionen erzeugt Perl
|
||||
möglicherweise Warnmeldungen wegen nicht installierter
|
||||
Unterstützung für Unicode-Zeichen auf Ihrem System.
|
||||
Sie können hierfür die Umgebungsvariable
|
||||
<envar>LD_PRELOAD</envar> in ihrer Shell auf
|
||||
<filename>/usr/lib/libxpg4.so</filename> setzen.</para>
|
||||
|
||||
<para>In <literal>sh</literal>-basierten Shells:</para>
|
||||
|
||||
<programlisting><envar>LD_PRELOAD=/usr/lib/libxpg4.so</envar></programlisting>
|
||||
|
||||
<para>In <literal>C</literal>-basierten Shells:</para>
|
||||
|
||||
<programlisting><envar>setenv LD_PRELOAD /usr/lib/libxpg4.so</envar></programlisting>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
17
de_DE.ISO8859-1/books/developers-handbook/policies/Makefile
Normal file
17
de_DE.ISO8859-1/books/developers-handbook/policies/Makefile
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
#
|
||||
# Build the Handbook with just the content from this chapter.
|
||||
#
|
||||
# $FreeBSD$
|
||||
# $FreeBSDde: de-docproj/books/developers-handbook/policies/Makefile,v 1.1.1.1 2007/08/01 19:18:33 as Exp $
|
||||
# basiert auf: 1.1
|
||||
#
|
||||
|
||||
CHAPTERS= policies/chapter.sgml
|
||||
|
||||
VPATH= ..
|
||||
|
||||
MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX}
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../../..
|
||||
|
||||
.include "../Makefile"
|
||||
522
de_DE.ISO8859-1/books/developers-handbook/policies/chapter.sgml
Normal file
522
de_DE.ISO8859-1/books/developers-handbook/policies/chapter.sgml
Normal file
|
|
@ -0,0 +1,522 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/policies/chapter.sgml,v 1.8 2007/09/21 20:30:41 as Exp $
|
||||
basiert auf: 1.33
|
||||
-->
|
||||
|
||||
<chapter id="policies">
|
||||
<chapterinfo>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Poul-Henning</firstname>
|
||||
<surname>Kamp</surname>
|
||||
<contrib>Beigesteuert von </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<!-- June 1996 -->
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Axel</firstname>
|
||||
<surname>Gruner</surname>
|
||||
<contrib>Übersetzt von </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</chapterinfo>
|
||||
|
||||
<title>Vorgaben und Richtlinien für das
|
||||
Quelltextverzeichnis</title>
|
||||
|
||||
<para>Dieses Kapitel dokumentiert verschiedene Vorgaben und
|
||||
Richtlinien für das FreeBSD-Quelltextverzeichnis.</para>
|
||||
|
||||
<sect1 id="policies-maintainer">
|
||||
<title><makevar>MAINTAINER</makevar> eines Makefiles</title>
|
||||
<indexterm><primary>Ports-Maintainer</primary></indexterm>
|
||||
|
||||
<para>Wenn ein bestimmter Bereich der FreeBSD-Distribution von
|
||||
einer Person oder Gruppe gepflegt wird, kann dies durch
|
||||
Hinzufügen der Zeile
|
||||
|
||||
<programlisting>MAINTAINER= email-addresses</programlisting>
|
||||
|
||||
im <filename>Makefile</filename> der Öffentlichkeit
|
||||
mitgeteilt werden.</para>
|
||||
|
||||
<para>Dies bedeutet folgendes:</para>
|
||||
|
||||
<para>Der Maintainer ist verantwortlich für diesen Code.
|
||||
Er muss einerseits für die Behebung von
|
||||
Fehlern und das Beantworten von Problemberichten für diesen
|
||||
Code die Verantwortung tragen und andererseits, falls es sich
|
||||
um beigesteuerte Software handelt, neue Versionen verfolgen
|
||||
und bereitstellen.</para>
|
||||
|
||||
<para>Änderungen an Verzeichnissen, die ein Maintainer
|
||||
definiert hat, sollten an den Maintainer für eine
|
||||
Überprüfung gesendet werden, bevor diese committet
|
||||
werden. Nur wenn der Maintainer in einer inakzeptablen
|
||||
Zeitspanne auf mehrere E-Mails nicht antwortet, können die
|
||||
Änderungen, die mit dem Commit in Kraft treten, auch ohne
|
||||
Überprüfung durch den Maintainer vollzogen werden.
|
||||
Dennoch wird empfohlen, dass die Änderungen, falls
|
||||
möglich, von jemand anderem überprüft
|
||||
werden.</para>
|
||||
|
||||
<para>Es ist natürlich nicht akzeptabel, einer Person oder
|
||||
Gruppe den Status eines Maintainers zu geben, so lange sie nicht
|
||||
zustimmt, diese Pflicht auf sich zu nehmen. Andererseits muss es
|
||||
kein einzelner Mensch sein. Eine Gruppe von Menschen ist genauso
|
||||
in Ordnung.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-contributed">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Poul-Henning</firstname>
|
||||
<surname>Kamp</surname>
|
||||
<contrib>Beigesteuert von </contrib>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>David</firstname>
|
||||
<surname>O'Brien</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<!-- June 1996 -->
|
||||
</sect1info>
|
||||
|
||||
<title>Beigesteuerte Software</title>
|
||||
|
||||
<indexterm><primary>Beigesteuerte Software</primary></indexterm>
|
||||
|
||||
<para>Einige Teile der FreeBSD-Distribution enthalten Software,
|
||||
die aktiv außerhalb des FreeBSD-Projektes gepflegt wird.
|
||||
Aus historischen Gründen nennen wir dies
|
||||
<emphasis>contributed</emphasis> Software. Beispiele dafür
|
||||
sind <application>sendmail</application>,
|
||||
<application>gcc</application> und
|
||||
<application>patch</application>.</para>
|
||||
|
||||
<para>Über die Jahre wurden verschiedene Methoden genutzt,
|
||||
um solche Software zu verwalten, und jede hat Vor-
|
||||
wie auch Nachteile. So hat sich kein eindeutiger Gewinner
|
||||
herauskristallisiert.</para>
|
||||
|
||||
<para>Es wurde viel über diesen Umstand diskutiert und
|
||||
eine Methode als die <quote>offizielle</quote>
|
||||
vorgestellt, um in Zukunft diese Art der Software zu
|
||||
importieren. Ferner wird dringend geraten, dass sich
|
||||
existierende, beigesteuerte Software diesem Modell
|
||||
annähert, da es signifikante Vorteile gegenüber der
|
||||
alten Methode gibt. Dazu gehört auch, dass jeder
|
||||
einfach Diffs bezüglich der
|
||||
<quote>offiziellen</quote> Quelltext-Versionen erzeugen kann
|
||||
(auch ohne CVS-Zugang). Dies wird es deutlich vereinfachen,
|
||||
Änderungen an die Hauptentwickler zurückfließen zu
|
||||
lassen.</para>
|
||||
|
||||
<para>Letztendlich kommt es jedoch auf die Menschen an, welche die
|
||||
Arbeit leisten. Wenn die Durchführung dieses Modells bei
|
||||
einem Paket mal nicht möglich ist, können Ausnahmen
|
||||
dieser Regeln nur mit Genehmigung des Core-Teams und der
|
||||
Übereinstimmung der anderen Entwickler gewährt werden.
|
||||
Die Fähigkeit, dieses Paket auch in Zukunft pflegen zu
|
||||
können, ist eine der Schlüsselfragen bei dieser
|
||||
Entscheidung.</para>
|
||||
|
||||
<note>
|
||||
<para>Durch einige bedauernswerte Einschränkungen
|
||||
des RCS-Dateiformats und die Handhabung von Herstellerzweigen
|
||||
im CVS ist von unwesentlichen, trivialen und/oder kosmetischen
|
||||
Änderungen an Dateien <emphasis>dringend
|
||||
abzuraten</emphasis>, die dem Herstellerzweig folgen.
|
||||
<quote>Grammatikalische oder sprachliche
|
||||
Fehlerbehebungen</quote> sind explizit unter der
|
||||
<quote>Kosmetik</quote>-Kategorie einzuordnen und sollten bei
|
||||
Dateien mit einer 1.1.x.x-Revision vermieden werden. Das
|
||||
Repository kann sich durch Änderungen einzelner Zeichen
|
||||
dramatisch aufblähen.</para>
|
||||
</note>
|
||||
|
||||
<para>Die eingebettete
|
||||
<application>Tcl</application>-Programmiersprache soll als
|
||||
Beispiel dienen, wie dieses Modell funktioniert:</para>
|
||||
|
||||
<para><filename>src/contrib/tcl</filename> enthält den
|
||||
Quelltext so, wie vom Maintainer dieses Pakets bereitgestellt.
|
||||
Teile, die unter FreeBSD gänzlich unnutzbar sind,
|
||||
können entfernt werden. Im Fall von Tcl wurden die
|
||||
Unterverzeichnisse <filename>mac</filename>,
|
||||
<filename>win</filename> und <filename>compat</filename>
|
||||
vor dem Import entfernt.</para>
|
||||
|
||||
<para><filename>src/lib/libtcl</filename> enthält ein
|
||||
<filename>Makefile</filename> im
|
||||
<application>bmake</application>-Stil, das die Regeln des
|
||||
Standard-Makefiles <filename>bsd.lib.mk</filename> nutzt, um
|
||||
die Bibliothek zu erstellen und die Dokumentation zu
|
||||
installieren.</para>
|
||||
|
||||
<para><filename>src/usr.bin/tclsh</filename> enthält ein
|
||||
<filename>Makefile</filename> im
|
||||
<application>bmake</application>-Stil, welches das
|
||||
<command>tclsh</command>-Programm erstellt und installiert,
|
||||
ebenso die dazugehörigen Manualpages, welche die Regeln von
|
||||
<filename>bsd.prog.mk</filename> nutzen.</para>
|
||||
|
||||
<para><filename>src/tools/tools/tcl_bmake</filename> enthält
|
||||
einige Shell-Skripten, die hilfreich sein können, wenn die
|
||||
Tcl-Software aktualisiert werden soll. Diese sind nicht Teil
|
||||
des Erstellens und der Installation der Software.</para>
|
||||
|
||||
<para>Das Entscheidende ist hier das
|
||||
<filename>src/contrib/tcl</filename>-Verzeichnis, welches nach
|
||||
den folgenden Regeln erstellt wird: Es muss den
|
||||
Quelltext aus dem Original enthalten (ohne
|
||||
RCS-Schlüsselworte und im korrekten CVS-Herstellerzweig)
|
||||
mit so wenig FreeBSD-spezifischen Änderungen wie
|
||||
möglich. Sollte es Zweifel geben, wie hier zu verfahren
|
||||
ist, unbedingt zuerst nachfragen und
|
||||
nicht auf gut Glück etwas probieren in der vagen
|
||||
Hoffnung, dass es <quote>irgendwie tut</quote>. CVS verzeiht
|
||||
keine Fehler beim Importieren und ein hoher Arbeitsaufwand
|
||||
wäre die Folge, um diesen großen Fehler wieder
|
||||
wettzumachen.</para>
|
||||
|
||||
<para>Aufgrund der eingangs schon erwähnten Einschränkungen
|
||||
bei CVS-Herstellerzweigen ist es erforderlich,
|
||||
dass <quote>offizielle</quote> Fehlerbehebungen vom Hersteller
|
||||
in die Originalquellen der Distribution einfließen und als
|
||||
Resultat wieder in den Herstellerzweig importiert werden.
|
||||
Offizielle Fehlerbehebungen sollten nie direkt in FreeBSD
|
||||
eingepflegt und <quote>committet</quote> werden, da dies
|
||||
den Herstellerzweig zerstören würde und der Import
|
||||
von zukünftigen Versionen wäre um ein Vielfaches
|
||||
schwerer, da es zu Konflikten kommen würde.</para>
|
||||
|
||||
<para>Da einige Pakete Dateien enthalten, die zur
|
||||
Kompatibilität mit anderen Architekturen und Umgebungen
|
||||
als FreeBSD gedacht sind, ist es zulässig, diese Teile zu
|
||||
löschen, wenn sie für FreeBSD nicht von Interesse
|
||||
sind, und so Speicherplatz zu sparen. Dateien, die ein
|
||||
Copyright und Release-artige Informationen zu den vorhandenen
|
||||
Dateien enthalten, sollten <emphasis>nicht</emphasis>
|
||||
gelöscht werden.</para>
|
||||
|
||||
<para>Falls es einfacher erscheint, können die
|
||||
<command>bmake</command>-<filename>Makefile</filename>s vom
|
||||
Verzeichnisbaum durch einige Dienstprogramme automatisch
|
||||
erstellt werden, was es hoffentlich sogar noch einfacher macht,
|
||||
eine Version zu aktualisieren. Ist dies geschehen, so stellen
|
||||
Sie bitte sicher, diese Werkzeuge in das Verzeichnis
|
||||
<filename>src/tools</filename> gleich mit dem Port an sich
|
||||
einzuchecken, sodass es für zukünftige Maintainer
|
||||
verfügbar ist.</para>
|
||||
|
||||
<para>Im Verzeichnis <filename>src/contrib/tcl</filename> sollte
|
||||
eine Datei mit dem Namen <filename>FREEBSD-upgrade</filename>
|
||||
hinzugefügt werden und sie sollte den Stand wie folgt
|
||||
anzeigen:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Welche Dateien ausgelassen wurden.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Von wo die Original-Distribution stammt und/oder wo die
|
||||
offizielle Hauptseite zu finden ist.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wohin Fehlerbehebungen an den Originalautor gesendet
|
||||
werden können.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Möglicherweise eine Übersicht, welche
|
||||
FreeBSD-spezifischen Änderungen vorgenommen
|
||||
wurden.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Importieren Sie jedoch <filename>FREEBSD-upgrade</filename>
|
||||
nicht mit den beigesteuerten Quelldateien. Stattdessen sollten
|
||||
Sie <command>cvs add FREEBSD-upgrade ; cvs ci</command> nach
|
||||
dem initialen Import nutzen. Ein Beispiel von
|
||||
<filename>src/contrib/cpio</filename> sehen Sie hier:</para>
|
||||
|
||||
<programlisting>
|
||||
This directory contains virgin sources of the original distribution files
|
||||
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
|
||||
the files in this directory via patches and a cvs commit. New versions or
|
||||
official-patch versions must be imported. Please remember to import with
|
||||
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
|
||||
|
||||
For the import of GNU cpio 2.4.2, the following files were removed:
|
||||
|
||||
INSTALL cpio.info mkdir.c
|
||||
Makefile.in cpio.texi mkinstalldirs
|
||||
|
||||
To upgrade to a newer version of cpio, when it is available:
|
||||
1. Unpack the new version into an empty directory.
|
||||
[Do not make ANY changes to the files.]
|
||||
|
||||
2. Remove the files listed above and any others that don't apply to
|
||||
FreeBSD.
|
||||
|
||||
3. Use the command:
|
||||
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
|
||||
src/contrib/cpio GNU cpio_<version>
|
||||
|
||||
For example, to do the import of version 2.4.2, I typed:
|
||||
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
|
||||
src/contrib/cpio GNU cpio_2_4_2
|
||||
|
||||
4. Follow the instructions printed out in step 3 to resolve any
|
||||
conflicts between local FreeBSD changes and the newer version.
|
||||
|
||||
Do not, under any circumstances, deviate from this procedure.
|
||||
|
||||
To make local changes to cpio, simply patch and commit to the main
|
||||
branch (aka HEAD). Never make local changes on the GNU branch.
|
||||
|
||||
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
|
||||
inclusion in the next vendor release.
|
||||
|
||||
obrien@FreeBSD.org - 30 March 1997</programlisting>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-encumbered">
|
||||
<title>Belastende Dateien</title>
|
||||
|
||||
<para>Es kann gelegentlich notwendig sein, belastende Dateien
|
||||
in den FreeBSD-Quelltextbaum zu integrieren. Braucht ein
|
||||
Gerät zum Beispiel ein Stück binären Code, der
|
||||
zuerst geladen werden muss, bevor das Gerät funktioniert,
|
||||
und wir haben keine Quellen zu diesem Code, dann wird die
|
||||
binäre Datei als belastend bezeichnet. Die folgenden
|
||||
Richtlinien sind beim Aufnehmen von belastenden Dateien in den
|
||||
FreeBSD-Quelltextbaum zu beachten.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Jede Datei, die durch die System-CPU(s) ausgeführt
|
||||
wird und nicht als Quelltext vorliegt, ist belastend.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Jede Datei, deren Lizenz restriktiver ist als die BSD-
|
||||
oder GNU-Lizenz, ist belastend.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Eine Datei, die herunterladbare Binär-Daten
|
||||
enthält, ist nur belastend, wenn (1) oder (2)
|
||||
zutreffen. Sie muss in einem ASCII-Format
|
||||
gespeichert werden, das Architektur-neutral ist (file2c
|
||||
oder uuencoding wird empfohlen).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Jede belastende Datei braucht eine spezielle
|
||||
Genehmigung vom <ulink
|
||||
url="&url.articles.contributors;/staff-core.html">Core-Team</ulink>,
|
||||
bevor diese in das CVS-Repository aufgenommen
|
||||
werden darf.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Belastende Dateien liegen unter
|
||||
<filename>src/contrib</filename> oder
|
||||
<filename>src/sys/contrib</filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Das komplette Modul sollte auch am Stück
|
||||
aufbewahrt werden. Es gibt keinen Grund, dieses zu teilen,
|
||||
außer es gibt einen Code-Austausch mit Quelltext, der
|
||||
nicht belastend ist.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Objekt-Dateien werden wie folgt benannt:
|
||||
<filename><replaceable>arch</replaceable>/<replaceable>filename</replaceable>.o.uu></filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Kernel-Dateien:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Sollten immer nach
|
||||
<filename>conf/files.*</filename> verweisen (um den Bau
|
||||
einfach zu halten).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Sollten sich immer in <filename>LINT</filename>
|
||||
befinden, jedoch entscheidet das <ulink
|
||||
url="&url.articles.contributors;/staff-core.html">Core-Team</ulink>
|
||||
je nach Fall, ob es
|
||||
auskommentiert wird oder nicht. Das <ulink
|
||||
url="&url.articles.contributors;/staff-core.html">Core-Team</ulink>
|
||||
kann sich zu einem späteren Zeitpunkt
|
||||
immer noch anders entscheiden.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Der <firstterm>Release-Engineer</firstterm>
|
||||
entscheidet, ob es in ein Release aufgenommen wird oder
|
||||
nicht.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Userland-Dateien:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<indexterm><primary>Core-Team</primary></indexterm>
|
||||
|
||||
<para>Das <ulink
|
||||
url="&url.articles.contributors;/staff-core.html">Core-Team</ulink>
|
||||
entscheidet, ob der Code von
|
||||
<command>make world</command> gebaut wird oder nicht.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<indexterm><primary>Release-Engineer</primary></indexterm>
|
||||
|
||||
<para>Der <ulink
|
||||
url="&url.articles.contributors;/staff-who.html">Release-Engineer</ulink>
|
||||
entscheidet, ob es in das Release
|
||||
aufgenommen wird oder nicht.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-shlib">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Satoshi</firstname>
|
||||
<surname>Asami</surname>
|
||||
<contrib>Beigesteuert von </contrib>
|
||||
</author>
|
||||
|
||||
<author>
|
||||
<firstname>Peter</firstname>
|
||||
<surname>Wemm</surname>
|
||||
</author>
|
||||
|
||||
<author>
|
||||
<firstname>David</firstname>
|
||||
<surname>O'Brien</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<!-- 9 Dec 1996 -->
|
||||
</sect1info>
|
||||
|
||||
<title>Shared-Libraries</title>
|
||||
|
||||
<para>Sollten Sie die Unterstützung für
|
||||
Shared-Libraries bei einem Port oder einem Stück Software,
|
||||
das dies nicht hat, hinzufügen, sollten die Versionsnummern
|
||||
dessen Regeln folgen. Im Allgemeinen hat die sich daraus
|
||||
resultierende Nummer nichts mit der Release-Version der Software
|
||||
zu tun.</para>
|
||||
|
||||
<para>Die drei Grundsätze zum Erstellen von Shared-Libraries
|
||||
sind:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Sie beginnen mit <literal>1.0</literal>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Gibt es eine Änderung, die
|
||||
abwärtskompatibel ist, so springen Sie zur
|
||||
nächsten Minor-Version (beachten Sie, dass ELF-Systeme
|
||||
die Minor-Version ignorieren).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Gibt es eine inkompatible Änderung, so springen
|
||||
Sie bitte zur nächsten Major-Version.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Zum Beispiel wird beim Hinzufügen von Funktionen und
|
||||
oder Fehlerbehebungen zur nächsten Minor-Version
|
||||
gesprungen, beim Löschen einer Funktion, Ändern
|
||||
von Funktionsaufrufen usw. ändert sich die Major-Version.</para>
|
||||
|
||||
<para>Bleiben Sie bei Versionsnummern in der Form major.minor
|
||||
(<replaceable>x</replaceable>.<replaceable>y</replaceable>).
|
||||
Unser dynamischer Linker a.out kann mit Versionsnummern
|
||||
in der Form
|
||||
<replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
|
||||
nicht gut umgehen.
|
||||
Jede Versionsnummer nach dem <replaceable>y</replaceable>
|
||||
(die dritte Zahl) wird völlig ignoriert, wenn
|
||||
Versionsnummern der Shared-Libraries verglichen werden, um
|
||||
zu bestimmen, mit welcher Bibliothek eine Anwendung verlinkt wird.
|
||||
Sind zwei Shared-Libraries vorhanden, die sich nur in der
|
||||
<quote>micro</quote>-Revision unterscheiden, so wird
|
||||
<command>ld.so</command> zu der höheren verlinken.
|
||||
Dies bedeutet, dass wenn Sie mit <filename>libfoo.so.3.3.3</filename>
|
||||
verlinken, der Linker nur <literal>3.3</literal> in den
|
||||
Header aufnimmt und alles linkt, was mit
|
||||
<replaceable>libfoo.so.3</replaceable>
|
||||
.<replaceable>(irgendetwas
|
||||
>= 3)</replaceable>.<replaceable>(höchste
|
||||
verfügbare Nummer)</replaceable> beginnt.</para>
|
||||
|
||||
<note>
|
||||
<para><command>ld.so</command> wird immer die höchste
|
||||
<quote>Minor</quote>-Revision benutzen. Beispielsweise wird
|
||||
es die <filename>libc.so.2.2</filename> bevorzugen
|
||||
gegenüber der <filename>libc.so.2.0</filename>, auch
|
||||
dann, wenn das Programm ursprünglich mit
|
||||
<filename>libc.so.2.0</filename> verlinkt war.</para>
|
||||
</note>
|
||||
|
||||
<para>Unser dynamischer ELF-Linker kann keine Minor-Versionen
|
||||
handhaben. Dennoch sollten die Major- und Minor-Versionen genutzt
|
||||
werden, da unsere <filename>Makefile</filename>s <quote>das
|
||||
Richtige machen</quote> bezogen auf den Systemtyp.</para>
|
||||
|
||||
<para>Für nicht-Port-Bibliotheken lautet die Richtlinie,
|
||||
die Shared-Library-Versionsnummer nur einmal zwischen den
|
||||
Releases zu ändern. Weiterhin ist es vorgeschrieben, die
|
||||
Major-Version der Shared-Libraries nur bei Major-OS-Releases zu
|
||||
ändern (beispielsweise von 3.0 auf 4.0). Wenn Sie also eine
|
||||
Änderung an einer Systembibliothek vornehmen, die eine neue
|
||||
Versionsnummer benötigt, überprüfen Sie die
|
||||
Commit-Logs des <filename>Makefile</filename>s. Es liegt in der
|
||||
Verantwortung des Committers, dass sich eine erste solche
|
||||
Änderung seit dem letzten Release in der aktualisierten
|
||||
Versionsnummer der Shared-Library im
|
||||
<filename>Makefile</filename> äußert, folgende
|
||||
Änderungen werden nicht berücksichtigt.</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../chapter.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||||
End:
|
||||
-->
|
||||
667
de_DE.ISO8859-1/books/developers-handbook/secure/chapter.sgml
Normal file
667
de_DE.ISO8859-1/books/developers-handbook/secure/chapter.sgml
Normal file
|
|
@ -0,0 +1,667 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/secure/chapter.sgml,v 1.11 2009/02/02 22:24:42 miwi Exp $
|
||||
basiert auf: 1.27
|
||||
-->
|
||||
|
||||
<chapter id="secure">
|
||||
<chapterinfo>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Murray</firstname>
|
||||
<surname>Stokely</surname>
|
||||
<contrib>Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Hagen</firstname>
|
||||
<surname>Kühl</surname>
|
||||
<contrib>Übersetzt von </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</chapterinfo>
|
||||
|
||||
<title>Sicheres Programmieren</title>
|
||||
|
||||
<sect1 id="secure-synopsis">
|
||||
<title>Zusammenfassung</title>
|
||||
|
||||
<para>Dieses Kapitel beschreibt einige Sicherheitsprobleme, die
|
||||
&unix;-Programmierer seit Jahrzehnten quälen, und
|
||||
inzwischen verfügbare Werkzeuge, die Programmierern helfen,
|
||||
Sicherheitslücken in ihrem Quelltext zu vermeiden.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="secure-philosophy">
|
||||
<title>Methoden des sicheren Entwurfs</title>
|
||||
|
||||
<para>Sichere Anwendungen zu schreiben erfordert eine sehr
|
||||
skeptische und pessimistische Lebenseinstellung. Anwendungen
|
||||
sollten nach dem Prinzip der <quote>geringsten
|
||||
Privilegien</quote> ausgeführt werden, sodass kein Prozess
|
||||
mit mehr als dem absoluten Minimum an Zugriffsrechten arbeitet,
|
||||
die er zum Erfüllen seiner Aufgabe benötigt. Wo es
|
||||
möglich ist, sollte Quelltext, der bereits
|
||||
überprüft wurde, wiederverwendet werden, um
|
||||
häufige Fehler, die andere schon korrigiert haben, zu
|
||||
vermeiden.</para>
|
||||
|
||||
<para>Eine der Stolperfallen der &unix;-Umgebung ist, dass es
|
||||
sehr einfach ist Annahmen über die Konsistenz der Umgebung
|
||||
zu machen. Anwendungen sollten Nutzereingaben (in allen Formen)
|
||||
niemals trauen, genausowenig wie den System-Ressourcen,
|
||||
der Inter-Prozess-Kommunikation oder dem zeitlichen Ablauf von
|
||||
Ereignissen. &unix;-Prozesse arbeiten nicht synchron. Daher sind
|
||||
logische Operationen selten atomar.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="secure-bufferov">
|
||||
<title>Puffer-Überläufe</title>
|
||||
|
||||
<para>Puffer-Überläufe gibt es schon seit den
|
||||
Anfängen der Von-Neuman-Architektur <xref linkend="COD">.
|
||||
|
||||
<indexterm><primary>Puffer-Überlauf</primary></indexterm>
|
||||
<indexterm><primary>Von-Neuman</primary></indexterm>
|
||||
|
||||
Sie erlangten zum ersten Mal durch den Internetwurm Morris im
|
||||
Jahre 1988 öffentliche Bekanntheit. Unglücklicherweise
|
||||
|
||||
<indexterm><primary>Morris Internetwurm</primary></indexterm>
|
||||
|
||||
funktioniert der gleiche grundlegende Angriff noch heute. Von
|
||||
den 17 CERT-Sicherheitsmeldungen wurden 1999 zehn
|
||||
|
||||
<indexterm>
|
||||
<primary>CERT</primary>
|
||||
<secondary>Sicheitshinweise</secondary>
|
||||
</indexterm>
|
||||
|
||||
direkt durch Puffer-Überläufe in der Software
|
||||
verursacht. Die bei weitem häufigste Form eines
|
||||
Puffer-Überlauf-Angriffs basiert darauf, den Stack
|
||||
zu korrumpieren.</para>
|
||||
|
||||
<indexterm><primary>Stack</primary></indexterm>
|
||||
<indexterm><primary>Arguments</primary></indexterm>
|
||||
|
||||
<para>Die meisten modernen Computer-Systeme verwenden einen
|
||||
Stack, um Argumente an Prozeduren zu übergeben und
|
||||
lokale Variablen zu speichern. Ein Stack ist ein
|
||||
last-in-first-out-Puffer (LIFO) im hohen Speicherbereich
|
||||
eines Prozesses. Wenn ein Programm eine Funktion
|
||||
|
||||
<indexterm><primary>LIFO</primary></indexterm>
|
||||
<indexterm>
|
||||
<primary>Prozessabbild</primary>
|
||||
<secondary>Stack-Pointer</secondary>
|
||||
</indexterm>
|
||||
|
||||
aufruft wird ein neuer "Stackframe" erzeugt. Dieser besteht aus
|
||||
den Argumenten, die der Funktion übergeben wurden und
|
||||
einem variabel grossem Bereich für lokale Variablen. Der
|
||||
"Stack-Pointer" ist ein Register, dass die
|
||||
|
||||
<indexterm><primary>Stack-Frame</primary></indexterm>
|
||||
<indexterm><primary>Stack-Pointer</primary></indexterm>
|
||||
|
||||
aktuelle Adresse der Stack-Spitze enthält.
|
||||
Da sich dieser Wert oft ändert, wenn neue Werte
|
||||
auf dem Stack abgelegt werden, bieten viele Implementierungen
|
||||
einen "Frame-Pointer", der nahe am Anfang des Stack-Frames
|
||||
liegt und es so leichter macht lokale Variablen relativ zum
|
||||
aktuellen Stackframe zu adressieren. <xref linkend="COD">
|
||||
Die Rücksprungadresse
|
||||
|
||||
<indexterm><primary>Frame-Pointer</primary></indexterm>
|
||||
<indexterm>
|
||||
<primary>Prozessabbild</primary>
|
||||
<secondary>Frame-Pointer</secondary>
|
||||
</indexterm>
|
||||
<indexterm><primary>Rücksprungadresse</primary></indexterm>
|
||||
<indexterm><primary>Stack-Überlauf</primary></indexterm>
|
||||
|
||||
der Funktionen werden ebenfalls auf dem Stack
|
||||
gespeichert und das ist der Grund für
|
||||
Stack-Überlauf-Exploits. Denn ein böswilliger Nutzer
|
||||
kann die Rücksprungadresse der Funktion überschreiben
|
||||
indem er eine lokale Variable in der Funktion
|
||||
überlaufen lässt, wodurch es ihm möglich ist
|
||||
beliebigen Code auszuführen.</para>
|
||||
|
||||
<para>Obwohl Stack-basierte Angriffe bei weitem die
|
||||
Häufigsten sind, ist es auch möglich den Stack mit
|
||||
einem Heap-basierten (malloc/free) Angriff zu
|
||||
überschreiben.</para>
|
||||
|
||||
<para>Die C-Programmiersprache führt keine automatischen
|
||||
Bereichsüprüfungen bei Feldern oder Zeigern durch, wie
|
||||
viele andere Sprachen das tun. Außerdem enthält
|
||||
die C-Standardbibliothek eine Handvoll sehr
|
||||
gefährlicher Funktionen.</para>
|
||||
|
||||
<informaltable frame="none" pgwide="1">
|
||||
<tgroup cols="2">
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><function>strcpy</function>(char *dest, const
|
||||
char *src)</entry>
|
||||
<entry><simpara>Kann den Puffer dest überlaufen
|
||||
lassen</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><function>strcat</function>(char *dest, const
|
||||
char *src)</entry>
|
||||
<entry><simpara>Kann den Puffer dest überlaufen
|
||||
lassen</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><function>getwd</function>(char *buf)</entry>
|
||||
<entry><simpara>Kann den Puffer buf überlaufen
|
||||
lassen</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><function>gets</function>(char *s)</entry>
|
||||
<entry><simpara>Kann den Puffer s überlaufen
|
||||
lassen</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><function>[vf]scanf</function>(const char
|
||||
*format, ...)</entry>
|
||||
<entry><simpara>Kann sein Argument überlaufen
|
||||
lassen</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><function>realpath</function>(char *path,
|
||||
char resolved_path[])</entry>
|
||||
<entry><simpara>Kann den Puffer path überlaufen
|
||||
lassen</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><function>[v]sprintf</function>(char *str,
|
||||
const char *format, ...)</entry>
|
||||
<entry><simpara>Kann den Puffer str überlaufen
|
||||
lassen</simpara></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<sect2>
|
||||
<title>Puffer-Überlauf Beispiel</title>
|
||||
|
||||
<para>Das folgende Quellcode-Beispiel enthält einen
|
||||
Puffer-Überlauf, der darauf ausgelegt ist die
|
||||
Rücksprungadresse zu überschreiben und die
|
||||
Anweisung direkt nach dem Funktionsaufruf zu
|
||||
überspringen. (Inspiriert durch
|
||||
<xref linkend="Phrack">)</para>
|
||||
|
||||
<programlisting>#include <sgmltag>stdio.h</sgmltag>
|
||||
|
||||
void manipulate(char *buffer) {
|
||||
char newbuffer[80];
|
||||
strcpy(newbuffer,buffer);
|
||||
}
|
||||
|
||||
int main() {
|
||||
char ch,buffer[4096];
|
||||
int i=0;
|
||||
|
||||
while ((buffer[i++] = getchar()) != '\n') {};
|
||||
|
||||
i=1;
|
||||
manipulate(buffer);
|
||||
i=2;
|
||||
printf("The value of i is : %d\n",i);
|
||||
return 0;
|
||||
}</programlisting>
|
||||
|
||||
<para>Betrachten wir nun, wie das Speicherabbild dieses
|
||||
Prozesses aussehen würde, wenn wir 160 Leerzeichen
|
||||
in unser kleines Programm eingeben, bevor wir Enter
|
||||
drücken.</para>
|
||||
|
||||
<para>[XXX figure here!]</para>
|
||||
|
||||
<para>Offensichtlich kann man durch böswilligere Eingaben
|
||||
bereits kompilierten Programmtext ausführen (wie z.B.
|
||||
exec(/bin/sh)).</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Puffer-Überläufe vermeiden</title>
|
||||
|
||||
<para>Die direkteste Lösung, um
|
||||
Stack-Überläufe zu vermeiden, ist immer
|
||||
grössenbegrenzten Speicher und String-Copy-Funktionen
|
||||
zu verwenden.
|
||||
<function>strncpy</function> und <function>strncat</function>
|
||||
sind Teil der C-Standardbibliothek.
|
||||
|
||||
<indexterm>
|
||||
<primary>Zeichenketten-Kopierfunktioen</primary>
|
||||
<secondary>strncpy</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>Zeichenketten-Kopierfunktionen</primary>
|
||||
<secondary>strncat</secondary>
|
||||
</indexterm>
|
||||
|
||||
Diese Funktionen akzeptieren einen Längen-Parameter. Dieser
|
||||
Wert sollte nicht größer sein als die Länge
|
||||
des Zielpuffers. Die Funktionen kopieren dann bis zu
|
||||
`length' Bytes von der Quelle zum Ziel. Allerdings gibt es
|
||||
einige Probleme. Keine der Funktionen garantiert, dass
|
||||
die Zeichenkette NUL-terminiert ist, wenn die
|
||||
Größe
|
||||
|
||||
<indexterm><primary>NUL-Terminierung</primary></indexterm>
|
||||
|
||||
des Eingabepuffers so groß ist wie das Ziel.
|
||||
Außerdem wird der Parameter length zwischen strncpy
|
||||
und strncat inkonsistent definiert, weshalb Programmierer
|
||||
leicht bezüglich der korrekten Verwendung durcheinander
|
||||
kommen können. Weiterhin gibt es einen spürbaren
|
||||
Leistungsverlust im Vergleich zu
|
||||
<function>strcpy</function>, wenn eine kurze Zeichenkette in
|
||||
einen großen Puffer kopiert wird. Denn
|
||||
<function>strncpy</function> fült den Puffer bis zur
|
||||
angegebenen Länge mit NUL auf.
|
||||
</para>
|
||||
|
||||
<para>In OpenBSD wurde eine weitere Möglichkeit zum
|
||||
|
||||
<indexterm><primary>OpenBSD</primary></indexterm>
|
||||
|
||||
kopieren von Speicherbereichen implementiert, die dieses
|
||||
Problem umgeht. Die Funktionen <function>strlcpy</function>
|
||||
und <function>strlcat</function> garantieren, dass das Ziel
|
||||
immer NUL-terminiert wird, wenn das Argument length ungleich
|
||||
null ist. Für weitere Informationen über diese
|
||||
Funktionen lesen Sie bitte <xref linkend="OpenBSD">. Die
|
||||
OpenBSD-Funktionen <function>strlcpy</function> und
|
||||
<function>strlcat</function> sind seit Version 3.3 auch in
|
||||
FreeBSD verfügbar.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>Zeichenketten-Kopierfunktionen</primary>
|
||||
<secondary>strlcpy</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>Zeichenketten-Kopierfunktionen</primary>
|
||||
<secondary>strlcat</secondary>
|
||||
</indexterm>
|
||||
|
||||
<sect3>
|
||||
<title>Compiler-basierte Laufzeitüberprüfung
|
||||
von Grenzen</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>Prüfung von Grenzen</primary>
|
||||
<secondary>Compiler-basiert</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Unglücklicherweise gibt es immer noch sehr viel
|
||||
Quelltext, der allgemein verwendet wird und blind Speicher
|
||||
umherkopiert, ohne eine der gerade besprochenen Funktionen,
|
||||
die Begrenzungen unterstützen, zu verwenden.
|
||||
Glücklicherweise gibt es eine weitere Lösung.
|
||||
Verschiedene Compiler-Erweiterungen und Bibliotheken
|
||||
überprüfen die Grenzen in C/C++ zur
|
||||
Laufzeit.</para>
|
||||
|
||||
<indexterm><primary>StackGuard</primary></indexterm>
|
||||
<indexterm><primary>GCC</primary></indexterm>
|
||||
|
||||
<para>StackGuard ist eine solche Erweiterung, die als
|
||||
kleiner Patch für den GCC-Code-Generator
|
||||
implementiert ist. Von der <ulink
|
||||
url="http://immunix.org/stackguard.html">StackGuard
|
||||
Webseite</ulink> (übersetzt):
|
||||
|
||||
<blockquote>
|
||||
<para>"StackGuard erkennt und verhindert
|
||||
Stack-Smashing-Angriffe, indem es die
|
||||
Rücksprungadresse auf dem Stack davor
|
||||
schützt, geändert zu werden. StackGuard
|
||||
platziert ein "Canary"-Wort (Anmerkung des
|
||||
Übersetzers: Kanarienvogel, nach einer
|
||||
Sicherheitsvorkehrung von Bergleuten, um Gas
|
||||
frühzeitig zu erkennen, ein Wort ist hier
|
||||
ein 32-Bit-Speicherblock) neben der
|
||||
Rücksprungadresse, wenn eine Funktion aufgerufen
|
||||
wird. Wenn das Canary bei der Rückkehr der
|
||||
Funktion geändert wurde, reagiert das Programm
|
||||
auf den Versuch eines Stack-Smashing-Angriffs,
|
||||
schickt eine Benachrichtigung an Syslog und
|
||||
hält dann an."</para>
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<para>"StackGuard ist als ein kleiner Patch für
|
||||
den GCC-Code-Generator implementiert, um genau zu
|
||||
sein, für die Routinen function_prolog() und
|
||||
function_epilog().
|
||||
function_prolog() wurde erweitert, um Canaries beim
|
||||
Start einer Funktion auf den Stack zu legen und
|
||||
function_epilog() überprüft die
|
||||
Integrität des Canaries beim Beenden der
|
||||
Funktion. Jeder Versuch, die Rücksprungadresse
|
||||
zu ändern, wird daher erkannt, bevor die
|
||||
Funktion zurückkehrt."</para>
|
||||
</blockquote>
|
||||
</para>
|
||||
|
||||
<indexterm><primary>Puffer-Überlauf</primary></indexterm>
|
||||
|
||||
<para>Ihre Anwendungen mit StackGuard neu zu kompilieren ist
|
||||
eine effektive Maßnahme, um sie vor den meisten
|
||||
Puffer-Überlauf-Angriffen zu schützen, aber die
|
||||
Programme können noch immer kompromittiert werden.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Bibliotheks-basierte Laufzeitüberprüfung
|
||||
von Grenzen</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>Prüfung von Grenzen</primary>
|
||||
<secondary>Bibliotheks-basiert</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Compiler-basierte Mechanismen sind bei Software,
|
||||
die nur im Binärformat vertrieben wird, und die somit
|
||||
nicht neu kompiliert werden kann völlig nutzlos.
|
||||
Für diesen Fall gibt es einige Bibliotheken, welche
|
||||
die unsicheren Funktionen der C-Bibliothek
|
||||
(<function>strcpy</function>, <function>fscanf</function>,
|
||||
<function>getwd</function>, etc..) neu implementieren und
|
||||
sicherstellen, dass nicht hinter den Stack-Pointer
|
||||
geschrieben werden kann.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><simpara>libsafe</simpara></listitem>
|
||||
<listitem><simpara>libverify</simpara></listitem>
|
||||
<listitem><simpara>libparanoia</simpara></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Leider haben diese Bibliotheks-basierten
|
||||
Verteidigungen mehrere Schwächen. Diese Bibliotheken
|
||||
schützen nur vor einer kleinen Gruppe von
|
||||
Sicherheitslücken und sie können das
|
||||
eigentliche Problem nicht lösen. Diese
|
||||
Maßnahmen können versagen, wenn die Anwendung
|
||||
mit -fomit-frame-pointer kompiliert wurde.
|
||||
Außerdem kann der Nutzer die Umgebungsvariablen
|
||||
LD_PRELOAD und LD_LIBRARY_PATH überschreiben oder
|
||||
löschen.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="secure-setuid">
|
||||
<title>SetUID-Themen</title>
|
||||
|
||||
<indexterm><primary>seteuid</primary></indexterm>
|
||||
|
||||
<para>Es gibt zu jedem Prozess mindestens sechs verschiedene
|
||||
IDs, die diesem zugeordnet sind. Deshalb müssen Sie
|
||||
sehr vorsichtig mit den Zugriffsrechten sein, die Ihr Prozess
|
||||
zu jedem Zeitpunkt besitzt. Konkret bedeutet dass, das alle
|
||||
seteuid-Anwendungen ihre Privilegien abgeben sollten, sobald
|
||||
sie diese nicht mehr benötigen.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>Benutzer-IDs</primary>
|
||||
<secondary>reale Benutzer-ID</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>Benutzer-IDs</primary>
|
||||
<secondary>effective Benutzer-ID</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Die reale Benutzer-ID kann nur von einem
|
||||
Superuser-Prozess geändert werden. Das Programm
|
||||
<application>login</application> setzt sie, wenn sich ein
|
||||
Benutzer am System anmeldet, und sie wird nur selten
|
||||
geändert.</para>
|
||||
|
||||
<para>Die effektive Benutzer-ID wird von der Funktion
|
||||
<function>exec()</function> gesetzt, wenn ein Programm
|
||||
das seteuid-Bit gesetzt hat. Eine Anwendung kann
|
||||
<function>seteuid()</function> jederzeit aufrufen, um die
|
||||
effektive Benutzer-ID entweder auf die reale Benutzer-ID oder
|
||||
die gespeicherte set-user-ID zu setzen. Wenn eine der
|
||||
<function>exec()</function>-Funktionen die effektive
|
||||
Benutzer-ID setzt, wird der vorherige Wert als
|
||||
gespeicherte set-user-ID abgelegt.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="secure-chroot">
|
||||
<title>Die Umgebung ihres Programme einschränken</title>
|
||||
|
||||
<indexterm><primary>chroot()</primary></indexterm>
|
||||
|
||||
<para>Die herkömmliche Methode, um einen Prozess
|
||||
einzuschränken, besteht in dem Systemaufruf
|
||||
<function>chroot()</function>. Dieser Aufruf
|
||||
ändert das Wurzelverzeichnis, auf das sich alle
|
||||
Pfadangaben des Prozesses und jegliche Kind-Prozesse beziehen.
|
||||
Damit dieser Systemaufruf gelingt, muss der Prozess
|
||||
Ausführungsrechte (Durchsuchungsrechte) für das
|
||||
Verzeichnis haben, auf das er sich bezieht. Die neue Umgebung
|
||||
wird erst wirksam, wenn Sie mittels
|
||||
<function>chdir()</function> in Ihre neue Umgebung wechseln.
|
||||
Es sollte erwähnt werden, dass ein Prozess recht einfach
|
||||
aus der chroot-Umgebung ausbrechen kann, wenn er root-Rechte
|
||||
besitzt. Das kann man erreichen, indem man Gerätedateien
|
||||
anlegt, um Kernel-Speicher zu lesen, oder indem man einen
|
||||
Debugger mit einem Prozess außerhalb seines
|
||||
Gefängnisses verbindet, oder auf viele andere
|
||||
kreative Wege.</para>
|
||||
|
||||
<para>Das Verhalten des Systemaufrufs
|
||||
<function>chroot()</function> kann durch die
|
||||
kern.chroot.allow_open_directories
|
||||
<command>sysctl</command>-Variable beeinflusst werden. Wenn
|
||||
diese auf 0 gesetzt ist, wird <function>chroot()</function>
|
||||
mit EPERM fehlschlagen, wenn irgendwelche Verzeichnisse
|
||||
geöffnet sind. Wenn die Variable auf den Standardwert 1
|
||||
gesetzt ist, wird <function>chroot()</function> mit EPERM
|
||||
fehlschlagen, wenn irgendwelche Verzeichnisse geöffnet
|
||||
sind und sich der Prozess bereits in einer
|
||||
<function>chroot()</function>-Umgebung befindet. Bei jedem
|
||||
anderen Wert wird die Überprüfung auf
|
||||
geöffnete Verzeichnisse komplett umgangen.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Die Jail-Funktionalität in FreeBSD</title>
|
||||
|
||||
<indexterm><primary>Jail</primary></indexterm>
|
||||
|
||||
<para>Das Konzept einer Jail (Gefängnis) erweitert
|
||||
<function>chroot()</function>, indem es die Macht des
|
||||
Superusers einschränkt, um einen echten 'virtuellen
|
||||
Server' zu erzeugen. Wenn ein solches Gefängnis einmal
|
||||
eingerichtet ist, muss die gesamte Netzwerkkommunikation
|
||||
über eine bestimmte IP-Adresse erfolgen und die
|
||||
"root-Privilegien" innerhalb der Jail sind sehr stark
|
||||
eingeschränkt.</para>
|
||||
|
||||
<para>Solange Sie sich in einer Jail befinden, werden alle
|
||||
Tests auf Superuser-Rechte durch den Aufruf von
|
||||
<function>suser()</function> fehlschlagen. Allerdings wurden
|
||||
einige Aufrufe von <function>suser()</function>
|
||||
abgeändert, um die neue
|
||||
<function>suser_xxx()</function>-Schnittstelle zu
|
||||
implementieren. Diese Funktion ist dafür verantwortlich,
|
||||
festzustellen, ob bestimmte Superuser-Rechte einem
|
||||
eingesperrten Prozess zur Verfügung stehen.</para>
|
||||
|
||||
<para>Ein Superuser-Prozess innerhalb einer Jail darf
|
||||
folgendes:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<simpara>Berechtigungen verändern mittels:
|
||||
<function>setuid</function>,
|
||||
<function>seteuid</function>,
|
||||
<function>setgid</function>,
|
||||
<function>setegid</function>,
|
||||
<function>setgroups</function>,
|
||||
<function>setreuid</function>,
|
||||
<function>setregid</function>,
|
||||
<function>setlogin</function></simpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<simpara>Ressourcenbegrenzungen setzen mittels
|
||||
<function>setrlimit</function></simpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<simpara>Einige sysctl-Variablen (kern.hostname)
|
||||
verändern</simpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<simpara><function>chroot()</function></simpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<simpara>Ein Flag einer vnode setzen:
|
||||
<function>chflags</function>,
|
||||
<function>fchflags</function></simpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<simpara>Attribute einer vnode setzen wie Dateiberechtigungen,
|
||||
Eigentümer, Gruppe, Größe, Zugriffszeit
|
||||
und Modifikationszeit</simpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<simpara>Binden eines Prozesses an einen öffentlichen
|
||||
privilegierten Port (ports < 1024)</simpara>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><function>Jail</function>s sind ein mächtiges
|
||||
Werkzeug, um Anwendungen in einer sicheren Umgebung
|
||||
auszuführen, aber sie haben auch ihre Nachteile.
|
||||
Derzeit wurden die IPC-Mechanismen noch nicht an
|
||||
<function>suser_xxx</function> angepasst, so dass Anwendungen
|
||||
wie MySQL nicht innerhalb einer Jail ausgeführt werden
|
||||
können. Der Superuser-Zugriff hat in einer Jail nur eine
|
||||
sehr eingeschränkte Bedeutung, aber es gibt keine
|
||||
Möglichkeit zu definieren was
|
||||
"sehr eingeschränkt" heißt.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&posix;.1e Prozess Capabilities</title>
|
||||
|
||||
<indexterm><primary>POSIX.1e Process
|
||||
Capabilities</primary></indexterm>
|
||||
<indexterm><primary>TrustedBSD</primary></indexterm>
|
||||
|
||||
<para>&posix; hat einen funktionalen Entwurf (Working Draft)
|
||||
herausgegeben, der Ereignisüberprüfung,
|
||||
Zugriffskontrolllisten, feiner einstellbare Privilegien,
|
||||
Informationsmarkierung und verbindliche Zugriffskontrolle
|
||||
enthält.</para>
|
||||
|
||||
<para>Dies ist im Moment in Arbeit und das Hauptziel des <ulink
|
||||
url="http://www.trustedbsd.org/">TrustedBSD</ulink>-Projekts.
|
||||
Ein Teil der bisherigen Arbeit wurde in &os.current;
|
||||
übernommen (cap_set_proc(3)).</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="secure-trust">
|
||||
<title>Vertrauen</title>
|
||||
|
||||
<para>Eine Anwendung sollte niemals davon ausgehen, dass
|
||||
irgendetwas in der Nutzerumgebung vernünftig ist.
|
||||
Das beinhaltet (ist aber sicher nicht darauf
|
||||
beschränkt): Nutzereingaben, Signale,
|
||||
Umgebungsvariablen, Ressourcen, IPC, mmaps, das
|
||||
Arbeitsverzeichnis im Dateisystem, Dateideskriptoren,
|
||||
die Anzahl geöffneter Dateien, etc..</para>
|
||||
|
||||
<indexterm><primary>positive Filterung</primary></indexterm>
|
||||
<indexterm><primary>Datenvalidierung</primary></indexterm>
|
||||
|
||||
<para>Sie sollten niemals annehmen, dass Sie jede Art von
|
||||
inkorrekten Eingaben abfangen können, die ein Nutzer
|
||||
machen kann. Stattdessen sollte Ihre Anwendung positive
|
||||
Filterung verwenden, um nur eine bestimmte Teilmenge an
|
||||
Eingaben zuzulassen, die Sie für sicher halten.
|
||||
Ungeeignete Datenüberprüfung ist die Ursache
|
||||
vieler Exploits, besonders für CGI-Skripte im Internet.
|
||||
Bei Dateinamen müssen Sie besonders vorsichtig sein,
|
||||
wenn es sich um Pfade ("../", "/"), symbolische
|
||||
Verknüpfungen und Shell-Escape-Sequenzen handelt.</para>
|
||||
|
||||
<indexterm><primary>Perl Taint-Modus</primary></indexterm>
|
||||
|
||||
<para>Perl bietet eine wirklich coole Funktion, den sogenannten
|
||||
"Taint"-Modus, der verwendet werden kann, um zu verhindern,
|
||||
dass Skripte Daten, die von außerhalb des Programmes
|
||||
stammen, auf unsichere Art und Weise verwenden. Dieser
|
||||
Modus überprüft Kommandozeilenargumente,
|
||||
Umgebungsvariablen, Lokalisierungsinformationen, die
|
||||
Ergebnisse von Systemaufrufen
|
||||
(<function>readdir()</function>,
|
||||
<function>readlink()</function>,
|
||||
<function>getpwxxx()</function>)
|
||||
und alle Dateieingaben.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="secure-race-conditions">
|
||||
<title>Race-Conditions</title>
|
||||
|
||||
<para>Eine Race-Condition ist ein unnormales Verhalten, das von
|
||||
einer unerwarteten Abhängigkeit beim Timing von Ereignissen
|
||||
verursacht wird. Mit anderen Worten heißt das, ein
|
||||
Programmierer nimmt irrtümlicher Weise an, dass ein
|
||||
bestimmtes Ereignis immer vor einem anderen stattfindet.</para>
|
||||
|
||||
<indexterm><primary>Race-Conditions</primary>
|
||||
<secondary>Signale</secondary></indexterm>
|
||||
|
||||
<indexterm><primary>Race-Conditions</primary>
|
||||
<secondary>Zugriffsprüfungen</secondary></indexterm>
|
||||
|
||||
<indexterm><primary>Race-Conditions</primary>
|
||||
<secondary>Öffnen von Dateien</secondary></indexterm>
|
||||
|
||||
<para>Einige der häufigsten Ursachen für
|
||||
Race-Conditions sind Signale, Zugriffsprüfungen und das
|
||||
Öffnen von Dateien. Signale sind von Natur aus
|
||||
asynchrone Ereignisse, deshalb ist besondere Vorsicht im
|
||||
Umgang damit geboten. Das Prüfen des Zugriffs mittels
|
||||
der Aufrufe <function>access(2)</function> gefolgt von
|
||||
<function>open(2)</function> ist offensichtlich nicht atomar.
|
||||
Benutzer können zwischen den beiden Aufrufen Dateien
|
||||
verschieben. Stattdessen sollten privilegierte Anwendungen
|
||||
<function>seteuid()</function> direkt gefolgt von
|
||||
<function>open()</function> aufrufen. Auf die gleiche Art
|
||||
sollte eine Anwendung immer eine korrekte Umask vor dem
|
||||
Aufruf von <function>open()</function> setzen, um
|
||||
störende Aufrufe von <function>chmod()</function> zu
|
||||
umgehen.</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/sockets/chapter.sgml,v 1.4 2009/02/10 11:20:38 jkois Exp $
|
||||
basiert auf: 1.15
|
||||
-->
|
||||
|
||||
<chapter id="sockets">
|
||||
<title>Sockets</title>
|
||||
|
||||
<para>Dieses Kapitel ist noch nicht übersetzt.
|
||||
Lesen Sie bitte <ulink
|
||||
url="&url.books.developers-handbook.en;/sockets.html">
|
||||
das Original in englischer Sprache</ulink>. Wenn Sie helfen
|
||||
wollen, dieses Kapitel zu übersetzen, senden Sie bitte
|
||||
eine E-Mail an die Mailingliste &a.de.translators;.</para>
|
||||
</chapter>
|
||||
277
de_DE.ISO8859-1/books/developers-handbook/testing/chapter.sgml
Normal file
277
de_DE.ISO8859-1/books/developers-handbook/testing/chapter.sgml
Normal file
|
|
@ -0,0 +1,277 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/testing/chapter.sgml,v 1.7 2007/11/15 11:02:51 as Exp $
|
||||
basiert auf: 1.2
|
||||
-->
|
||||
|
||||
<chapter id="testing">
|
||||
<chapterinfo>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Jürgen</firstname>
|
||||
<surname>Lock</surname>
|
||||
<contrib>Übersetzt von </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</chapterinfo>
|
||||
|
||||
<title>Regressions- und Performance-Tests</title>
|
||||
|
||||
<para>Regressions-Tests werden durchgeführt, um zu überprüfen,
|
||||
ob ein bestimmter Teil des Systems wie erwartet funktioniert, und
|
||||
um sicherzustellen, dass bereits beseitigte Fehler nicht wieder eingebaut
|
||||
werden.</para>
|
||||
|
||||
<para>Die &os;-Regressions-Testwerkzeuge finden Sie im
|
||||
&os;-Quelltextbaum unter <filename
|
||||
class="directory">src/tools/regression</filename>.</para>
|
||||
|
||||
<section id="testing-micro-benchmark">
|
||||
<title>Mikro-Benchmark-Checkliste</title>
|
||||
|
||||
<para>Dieser Abschnitt enthält Tipps, wie
|
||||
ordnungsgemäße Mikro-Benchmarks unter &os; oder für
|
||||
&os; selbst erstellt werden.</para>
|
||||
|
||||
<para>Es ist nicht möglich, immer alle der folgenden
|
||||
Vorschläge zu berücksichtigen, aber je mehr davon,
|
||||
desto besser wird der Benchmark kleine
|
||||
Unterschiede nachweisen können.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Schalten Sie <acronym>APM</acronym> und alles andere,
|
||||
das den Systemtakt beeinflusst, ab
|
||||
(<acronym>ACPI</acronym>?).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Starten Sie in den Single-User-Modus. &man.cron.8;
|
||||
und andere Systemdienste verursachen nur Störungen.
|
||||
Genauso der &man.sshd.8;-Systemdienst.
|
||||
Falls während des Tests
|
||||
SSH-Zugriff benötigt wird, schalten Sie entweder die
|
||||
Neuerstellung des SSHv1-Schlüssels ab oder beenden Sie
|
||||
den <command>sshd</command>-Elternprozess während der
|
||||
Tests.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Beenden Sie &man.ntpd.8;.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Falls &man.syslog.3;-Ereignisse erzeugt werden,
|
||||
starten Sie &man.syslogd.8; mit leerer
|
||||
<filename>/etc/syslogd.conf</filename> oder beenden Sie
|
||||
es.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Sorgen Sie für möglichst wenig Disk-I/O;
|
||||
vermeiden Sie es ganz wenn möglich.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Hängen Sie keine Dateisysteme ein, die Sie nicht
|
||||
benötigen.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Hängen Sie <filename
|
||||
class="directory">/</filename>, <filename
|
||||
class="directory">/usr</filename> und die anderen
|
||||
Dateisysteme nur lesbar ein wenn möglich. Dies
|
||||
verhindert, dass atime-Aktualisierungen auf der Festplatte (usw.) das
|
||||
Ergebnis verfälschen.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Initialisieren Sie das beschreibbare
|
||||
Test-Dateisystem mit &man.newfs.8; neu und füllen Sie es
|
||||
aus einer &man.tar.1;- oder &man.dump.8;-Datei vor jedem
|
||||
Lauf. Hängen Sie es aus und wieder ein, bevor Sie den
|
||||
Test starten. Dies sorgt für einen konsistenten
|
||||
Dateisystemaufbau. Bei einem <quote>worldstone</quote>-Test
|
||||
bezieht sich dies auf <filename
|
||||
class="directory">/usr/obj</filename> (Initialisieren Sie
|
||||
es einfach mit <command>newfs</command> neu und hängen Sie
|
||||
es ein). Um absolut reproduzierbare Ergebnisse zu bekommen,
|
||||
füllen Sie das Dateisystem aus einer &man.dd.1;-Datei
|
||||
(d.h. <command>dd
|
||||
if=<filename>myimage</filename> of=<filename
|
||||
class="devicefile">/dev/ad0s1h</filename>
|
||||
bs=1m</command>).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Benutzen Sie malloc-gestützte oder vorbelastete
|
||||
&man.md.4;-Partitionen.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Starten Sie zwischen den einzelnen
|
||||
Durchläufen neu, dies sichert einen konsistenteren
|
||||
Zustand.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Entfernen Sie alle nicht unbedingt benötigten
|
||||
Gerätetreiber aus dem Kernel. Wenn z.B. USB für
|
||||
den Test nicht benötigt wird, entfernen Sie es aus dem
|
||||
Kernel. Gerätetreiber, die sich Hardware zuteilen, haben
|
||||
oft <quote>tickende</quote> Timeouts.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Konfigurieren Sie nicht Hardware, die
|
||||
nicht benutzt wird. Entfernen Sie Festplatten
|
||||
mit &man.atacontrol.8; und &man.camcontrol.8;, wenn diese
|
||||
für den Test nicht gebraucht werden.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Konfigurieren Sie nicht das Netzwerk, es sei denn es
|
||||
wird getestet, oder warten Sie, bis der Test fertig ist, wenn
|
||||
Sie das Ergebnis auf einen anderen Rechner übertragen
|
||||
wollen.</para>
|
||||
|
||||
<para>Falls das System an ein öffentliches Netzwerk
|
||||
angeschlossen sein muss, achten Sie auf Spitzen im
|
||||
Broadcast-Verkehr. Obwohl dieser kaum auffällt, wird
|
||||
er CPU-Zyklen brauchen. Ähnliches gilt für
|
||||
Multicast.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Legen Sie jedes Dateisystem auf eine eigene Festplatte.
|
||||
Dies minimiert Jitter durch Optimierungen von
|
||||
Lesekopfbewegungen.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Minimieren Sie Ausgaben auf serielle oder VGA-Konsolen.
|
||||
Ausgabenumleitung in Dateien ergibt weniger Jitter
|
||||
(serielle Konsolen werden leicht zum Flaschenhals).
|
||||
Benutzen Sie die Tastatur nicht, während der Test
|
||||
läuft, sogar <keycap>space</keycap> oder
|
||||
<keycap>back-space</keycap> wirken sich auf die
|
||||
Ergebnisse aus.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stellen Sie sicher, dass der Test lang genug
|
||||
läuft, aber nicht zu lange. Wenn er zu kurz ist, sind
|
||||
Zeitstempel ein Problem. Wenn er zu lang ist, werden
|
||||
Temperaturänderungen und Drift die Frequenz von
|
||||
Quarzkristallen im Rechner beeinflussen. Daumenregel: mehr
|
||||
als eine Minute, weniger als eine Stunde.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Versuchen Sie, die Temparatur in der Umgebung des
|
||||
Rechners so stabil wie möglich zu halten. Diese beeinflusst
|
||||
sowohl Quarzkristalle als auch Festplatten-Algorithmen.
|
||||
Um einen wirklich stabilen Takt zu erhalten, wäre es auch
|
||||
möglich, einen stabilisierten Takt anzuschließen.
|
||||
D.h. besorgen Sie sich einen OCXO + PLL und koppeln Sie das
|
||||
Ausgangssignal mit den Taktgeberschaltkreisen anstelle des
|
||||
Quarzkristalls der Hauptplatine. Wenden Sie sich an
|
||||
&a.phk;, wenn Sie mehr Informationen hierüber
|
||||
benötigen.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Lassen Sie den Test mindestens drei Mal laufen, besser
|
||||
mehr als 20 Mal, sowohl
|
||||
für <quote>vor</quote> als auch für
|
||||
<quote>nach</quote> dem Code. Versuchen Sie abzuwechseln
|
||||
(d.h. nicht erst 20 Mal <quote>vorher</quote> und dann 20
|
||||
Mal <quote>nachher</quote>), dies ermöglicht,
|
||||
umgebungsbedingte Effekte zu erkennen. Wechseln Sie nicht
|
||||
1:1 ab, sondern 3:3; dies erlaubt,
|
||||
Wechselwirkungseffekte zu erkennen.</para>
|
||||
|
||||
<para>Ein gutes Muster ist:
|
||||
<literal>bababa{bbbaaa}*</literal>. Dies gibt Hinweise nach
|
||||
den ersten 1+1-Läufen (sodass Sie den Test stoppen
|
||||
können, falls er völlig daneben geht), Sie
|
||||
können die Standardabweichung nach den ersten 3+3-Läufen
|
||||
überprüfen (zeigt an, ob sich ein
|
||||
längerer Lauf lohnt), später
|
||||
Trends und Wechselwirkungen.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Benutzen Sie <filename
|
||||
class="directory">usr/src/tools/tools/ministat</filename>, um
|
||||
festzustellen, ob Ihre Ergebnisse signifikant sind.
|
||||
Überlegen Sie sich, das Buch <quote>Cartoon guide to
|
||||
statistics</quote> ISBN: 0062731025 zu kaufen. Es ist sehr
|
||||
empfehlenswert, falls Sie Dinge wie Standardabweichung und
|
||||
Studentsche t-Verteilung vergessen oder nie gelernt
|
||||
haben.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Benutzen Sie keinen Hintergrund-&man.fsck.8;, wenn Sie
|
||||
ihn nicht selbst testen
|
||||
wollen. Schalten Sie auch <varname>background_fsck</varname>
|
||||
in <filename>/etc/rc.conf</filename> aus, es sei denn der
|
||||
Benchmark wird nicht mindestens 60+<quote>Laufzeit von
|
||||
<command>fsck</command></quote> Sekunden nach Systemstart
|
||||
gestartet, da &man.rc.8; startet und prüft, ob
|
||||
<command>fsck</command> auf irgendeinem der Dateisysteme
|
||||
laufen muss, wenn Hintergrund-<command>fsck</command>
|
||||
eingeschaltet ist. Stellen Sie ebenfalls sicher, dass keine
|
||||
Snapshots herumliegen, falls der Benchmark nicht ein Test
|
||||
mit Snapshots ist.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Falls der Benchmark unerwartet schlechte Performance
|
||||
zeigt, überprüfen Sie Dinge wie große Mengen
|
||||
Interrupts von unerwarteten Quellen. Es gibt Berichte, dass
|
||||
einige <acronym>ACPI</acronym>-Versionen sich <quote>daneben
|
||||
benehmen</quote> und ein Übermaß an Interrupts
|
||||
erzeugen. Um zu helfen, ungewöhnliche Testergebnisse zu
|
||||
diagnostizieren, machen Sie ein paar Momentaufnahmen von
|
||||
<command>vmstat -i</command> und suchen Sie nach
|
||||
Ungewöhnlichem.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Gehen Sie mit Parametern zur Optimierung
|
||||
von Kernel, Userland und Fehlersuche vorsichtig um.
|
||||
Es passiert schnell, irgendetwas durchrutschen zu
|
||||
lassen und dann später festzustellen, dass der Test
|
||||
nicht das gleiche verglichen hat.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Erstellen Sie nie Benchmarks unter Verwendung der Kernel-Optionen
|
||||
<literal>WITNESS</literal> und <literal>INVARIANTS</literal>,
|
||||
wenn der Test nicht diese Merkmale selbst
|
||||
untersuchen soll. <literal>WITNESS</literal> kann zu 400% und
|
||||
mehr Performance-Abnahme führen. Ähnliches gilt
|
||||
für Userland-&man.malloc.3;-Parameter, Voreinstellungen
|
||||
hierbei unterscheiden sich bei -CURRENT von denen bei
|
||||
Production-Releases.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../chapter.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||||
End:
|
||||
-->
|
||||
2647
de_DE.ISO8859-1/books/developers-handbook/tools/chapter.sgml
Normal file
2647
de_DE.ISO8859-1/books/developers-handbook/tools/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
6098
de_DE.ISO8859-1/books/developers-handbook/x86/chapter.sgml
Normal file
6098
de_DE.ISO8859-1/books/developers-handbook/x86/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
Loading…
Reference in a new issue