kgess-mirror/debian-handbook
1
0
Fork 0
mirror of https://salsa.debian.org/hertzog/debian-handbook.git synced 2026-01-16 23:01:01 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Initial import

Browse source
This commit is contained in:
Raphaël Hertzog 2012-05-07 13:21:53 +02:00
commit 7cfead3365
141 changed files with 61652 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

45
en-US/00a_preface.xml Normal file
View file

@ -0,0 +1,45 @@
<?xml version="1.0"?>
<preface id="preface">
<title>Preface</title>
<para>Many professionals are increasingly embracing Debian GNU/Linux,
whose goal to create a rich and flexible distribution that does not
require too much maintenance fits their expectations. They generally
appreciate its robustness and reliability, its automation of secondary
tasks, as well as the coherence brought by the strict application of
specifications and therefore the durability of achievements and
skills.</para>
<para>At the same time, many influential actors in the computing industry
have now come to understand the strategic interest of using an elaborate
distribution that is not managed by a commercial entity. Some of their
customers also understand — following the same logic — that a
software platform that does not depend on agreements between suppliers
reduces the constraints they will have after the purchase.</para>
<para>Finally, many beginners discover Debian through the Knoppix and
Ubuntu projects, while others “look under the hood” because they want
to avoid empiricism.</para>
<para>Debian — which used to be low-profile — was first adopted by
passionate users, who were often attracted by the spirit it embodies.
They found a project with clear goals and visible achievements, whose
developers focus on creating a good design <emphasis>before</emphasis>
building — thereby rejecting the deadlines that often compromise the
quality of so many other software projects. Debian is led by its very
actors. In other words, Debian users join a project that fully benefits
from the advantages of free software… so as to produce free software
themselves.</para>
<para>The <citetitle>Debian Administrator's Handbook</citetitle> will
guide you on your way to autonomy. It could only be written by authors
who master both the technical aspects and the inner workings of the
Debian project, and who know the needs of seasoned professionals as well
as enthusiasts. Raphaël Hertzog and Roland Mas had the required
qualities and managed to create and update this book. I thank them very
much for their work and have no doubt that reading this book will be both
helpful and pleasant.</para>
<para>Nat Makarevitch (PGP/GPG fingerprint: <literal>2010 4A02 9C0E 7D1F
5631 ADF0 453C 4549 0230 D602</literal>)</para>
</preface>

501
en-US/00b_foreword.xml Normal file
View file

@ -0,0 +1,501 @@
<?xml version="1.0"?>
<preface id="foreword">
<title>Foreword</title>
<para>Linux has been garnering strength for the last few years, and its
growing popularity drives more and more users to make the jump. The first
step on that path is to pick a distribution. This is an important
decision, because each distribution has its own peculiarities, and future
migration costs can be avoided if the right choice is made from the
start.</para>
<sidebar>
<title><emphasis>BACK TO BASICS</emphasis> Linux distribution, Linux kernel</title>
<indexterm><primary>Linux</primary><secondary>kernel</secondary></indexterm>
<indexterm><primary>Linux</primary><secondary>distribution</secondary></indexterm>
<indexterm><primary>distribution</primary><secondary>Linux distribution</secondary></indexterm>
<para>Strictly speaking, Linux is only a kernel, the core piece of
software sitting between the hardware and the applications.</para>
<para>A “Linux distribution” is a full operating system; it usually
includes the Linux kernel, an installer program, and most importantly
applications and other software required to turn a computer into an
actually useful tool.</para>
</sidebar>
<para>Debian GNU/Linux is a “generic” Linux distribution that fits
most users. The purpose of this book is to show its many aspects so you
can make an informed decision when choosing.</para>
<section id="sect.why-this-book">
<title>Why This Book?</title>
<sidebar>
<title><emphasis>CULTURE</emphasis> Commercial distributions</title>
<indexterm><primary>distribution</primary><secondary>commercial distribution</secondary></indexterm>
<para>Most Linux distributions are backed by a for-profit company
that develops them and sells them under some kind of commercial
scheme. Examples include <emphasis>Ubuntu</emphasis>, mainly
developed by <emphasis>Canonical Ltd.</emphasis>; <emphasis>Mandriva
Linux</emphasis>, by French company <emphasis>Mandriva SA</emphasis>;
and <emphasis>Suse Linux</emphasis>, maintained and made commercially
available by <emphasis>Novell</emphasis>.</para>
<para>At the other end of the spectrum lie the likes of Debian and
the Apache Software Foundation (which hosts the development for the
Apache web server). Debian is above all a project in the Free
Software world, implemented by volunteers working together through
the Internet.</para>
</sidebar>
<para>Linux has gathered a fair amount of media coverage, which mostly
benefits the distributions supported by a real marketing department —
in other words, to company-backed distributions (Ubuntu, Red Hat,
Suse, Mandriva, and so on). But Debian is far from being a marginal
distribution; according to a German study made in early 2009, Debian is
the most widely used distribution on servers (with nearly half of the
responding companies having at least one Debian server), and the second
most widely deployed on desktops (right behind Ubuntu, which is a
Debian derivative). <ulink type="block"
url="http://www.heise.de/open/artikel/Eingesetzte-Produkte-224518.html"/></para>
<para>The purpose of this book is to help you discover this
distribution. We hope to share the experience we've gathered since we
joined the project as developers and contributors in 1998 (Raphaël)
and 2000 (Roland). With any luck, our enthusiasm will be communicative,
and maybe you'll join us sometime…</para>
<para>The first edition of this book (in 2004) served to fill a gaping
hole: it was the first French-language book that focused exclusively on
Debian. At that time, many other books were written on the topic both
for French-speaking and English-speaking readers. Unfortunately almost
none of them got updated, and today we again find ourselves in a
situation where there are very few good books on Debian. We truly hope
that this first English edition will fill this gap and help many
users.</para>
</section>
<section id="sect.who-is-this-book-for">
<title>Who Is this Book For?</title>
<para>We tried to make this book useful for many categories of readers.
First, systems administrators (both beginners and experienced) will
find explanations about the installation and deployment of Debian on
many computers. They will also get a glimpse of most of the services
available on Debian, along with matching configuration instructions and
a description of the specifics coming from the distribution.
Understanding the mechanisms involved in Debian's development will
enable them to deal with unforeseen problems, knowing that they can
always find help within the community.</para>
<para>Users of another Linux distribution, or of another Unix variant,
will discover the specifics of Debian, and should become operational
very quickly while benefitting fully from the unique advantages of this
distribution.</para>
<para>Finally, readers who already have some knowledge of Debian and
want to know more about the community behind it should see their
expectations fulfilled. This book should make them much closer to
joining us as contributors.</para>
</section>
<section id="sect.selected-approach">
<title>Chosen Approach</title>
<para>All of the generic documentation you can find about GNU/Linux
also applies to Debian, since Debian includes most common free
software. However, the distribution brings many enhancements, which is
why we chose to primarily describe the “Debian way” of doing
things.</para>
<para>It is interesting to follow the Debian recommendations, but it is
even better to understand their rationale. Therefore, we won't restrict
ourselves to practical explanations only; we will also describe the
project's workings, so as to provide you with comprehensive and
consistent knowledge.</para>
</section>
<section id="sect.book-structure">
<title>Book Structure</title>
<para>Following the structure and aims of Eyrolles' “Administrator's
Handbook” collection, this book revolves around a case study
providing both support and illustration for all topics being
addressed.</para>
<sidebar>
<title><emphasis>NOTE</emphasis> Web site, authors' email</title>
<para>This book has its own website, which hosts whatever elements
that can make it more useful. In particular, it includes an online
version of the book with clickable links, and possible errata. Feel
free to browse it and to leave us some feedback. We will be happy to
read your comments or support messages. Send them by email to
<email>hertzog@debian.org</email> (Raphaël) and
<email>lolando@debian.org</email> (Roland). <ulink type="block"
url="http://debian-handbook.info/"/></para>
</sidebar>
<para><emphasis role="strong">Chapter 1</emphasis> focuses on a
non-technical presentation of the Debian project and describes its
goals and organization. These aspects are important because they define
a general framework that others chapters will complete with more
concrete information.</para>
<para><emphasis role="strong">Chapters 2 and 3</emphasis> provide a
broad outline of the case study. At this point, novice readers can take
the time to read <emphasis role="strong">appendix B</emphasis>, where
they'll find a short remedial course explaining a number of basic
computing notions, as well as concepts inherent to any Unix
system.</para>
<para>To get on with our real subject matter, we will quite naturally
start with the installation process (<emphasis role="strong">chapter
4</emphasis>); <emphasis role="strong">chapters 5 and 6</emphasis> will
unveil basic tools that any Debian administrator will use, such as
those of the <emphasis role="strong">APT</emphasis> family, which is
largely responsible for the distribution's excellent reputation. These
chapters are in no way reserved to professionals, since everyone is
their own administrator at home.</para>
<para><emphasis role="strong">Chapter 7</emphasis> will be an important
parenthesis; it describes workflows to efficiently use documentation
and to quickly gain an understanding of problems in order to solve
them.</para>
<para>The next chapters will be a more detailed tour of the system,
starting with basic infrastructure and services (<emphasis
role="strong">chapters 8 to 10</emphasis>) and going progressively up
the stack to reach the user applications in <emphasis>chapter
13</emphasis>. <emphasis role="strong">Chapter 12</emphasis> deals with
more advanced subjects that will most directly concern administrators
of large sets of computers (including servers), while <emphasis
role="strong">chapter 14</emphasis> is a brief introduction to the
wider subject of computer security and gives a few keys to avoid most
problems.</para>
<para><emphasis role="strong">Chapter 15</emphasis> is for
administrators who want to go further and create their own Debian
packages.</para>
<sidebar>
<title><emphasis>VOCABULARY</emphasis> Debian package</title>
<indexterm><primary>package</primary><secondary>Debian package</secondary></indexterm>
<indexterm><primary>package</primary><secondary>binary package</secondary></indexterm>
<indexterm><primary>package</primary><secondary>source package</secondary></indexterm>
<indexterm><primary>source package</primary></indexterm>
<para>A Debian package is an archive containing all the files
required to install a piece of software. It is generally a file with
a <filename>.deb</filename> extension, and it can be handled with the
<command>dpkg</command> command. Also called <emphasis>binary
package</emphasis>, it contains files that can be directly used (such
as programs or documentation). On the other hand, a <emphasis>source
package</emphasis> contains the source code for the software and the
instructions required for building the binary package.</para>
</sidebar>
<para>The present English version is based on the fifth edition of the
French book. This fifth edition was an important update, covering
version 6.0 of Debian, code-named <emphasis
role="distribution">Squeeze</emphasis>. Among the changes, Debian now
sports two new architectures — <emphasis>kfreebsd-i386</emphasis> and
<emphasis>kfreebsd-amd64</emphasis> — based on the FreeBSD kernel and
supporting the associated technologies (<emphasis>jails</emphasis>,
<emphasis>packet filter</emphasis> and so on). On Linux-based
architectures, the 2.6.32 kernel extends support to all the main
virtualization technologies (Xen/OpenVZ/LXC/KVM, see <xref
linkend="sect.virtualization"/>). All included packages have obviously
been updated. Many improvements specifically target package
maintainers, who can now use a simplified
<filename>debian/rules</filename> (with debhelper's
<command>dh</command> command); they also benefit from a standard patch
management system integrated to <command>dpkg-source</command> (by
using the <literal>3.0 (quilt)</literal> source package format).</para>
<para>We have added some notes and remarks in sidebars. They have a
variety of roles: they can draw attention to a difficult point,
complete a notion of the case study, define some terms, or serve as
reminders. Here is a list of the most common of these sidebars:</para>
<itemizedlist>
<listitem>
<para>BACK TO BASICS: a reminder for some information that is
supposed to be known;</para>
</listitem>
<listitem>
<para>VOCABULARY: defines a technical term, sometimes Debian
specific;</para>
</listitem>
<listitem>
<para>COMMUNITY: highlights important persons or roles within the
project;</para>
</listitem>
<listitem>
<para>POLICY: a rule or recommendation from the Debian Policy. This
document is essential within the project, and describes how to
package software. The parts of policy highlighted in this book
bring direct benefits to users (for example, knowing that the
policy standardizes the location of documentation and examples
makes it easy to find them even in a new package).</para>
</listitem>
<listitem>
<para>TOOL: presents a relevant tool or service;</para>
</listitem>
<listitem>
<para>IN PRACTICE: theory and practice do not always match; these
sidebars contain advice resulting from our experience. They can
also give detailed and concrete examples;</para>
</listitem>
<listitem>
<para>other more or less frequent sidebars are rather explicit:
CULTURE, TIP, CAUTION, GOING FURTHER, SECURITY, and so on.</para>
</listitem>
</itemizedlist>
</section>
<section condition="librement" id="sect.acknowledgments" lang="en-US">
<title>Acknowledgments</title>
<section>
<title>A Bit of History</title>
<para>In 2003, Nat Makarevitch contacted me (Raphaël) because he
wanted to publish a book on Debian in the <foreignphrase>Cahier de
l'Admin</foreignphrase> (Admin's Handbook) collection that he was
managing for Eyrolles, a leading French editor of technical books. I
immediately accepted to write it. The first edition came out on 14th
October 2004 and was a huge success — it was sold out barely four
months later.</para>
<para>Since then, we have released 4 other editions of the French
book, one for each subsequent Debian release. Roland Mas, who started
working on the book as my proofreader, gradually became its
co-author.</para>
<para>While we were obviously satisfied with the book's success, we
always hoped that Eyrolles would convince an international editor to
translate it into English. We had received numerous comments
explaining how the book helped people to get started with Debian, and
we were keen to have the book benefit more people in the same
way.</para>
<para>Alas, no English-speaking editor that we contacted was willing
to take the risk of translating and publishing the book. Not put off
by this small setback, we decided to negotiate with our French editor
Eyrolles to recuperate the necessary rights to translate the book
into English and to try to publish it ourselves.</para>
</section>
<section>
<title>A Crowd-Funded Translation</title>
<para>Translating a book of 450 pages is a considerable effort that
requires several months of work. For self-employed people like Roland
and me, we had to ensure a minimum income to mobilize the time
necessary to complete the project. So we set up a crowd-funding
campaign on Ulule and asked people to pledge money towards the
project. <ulink type="block"
url="http://www.ulule.com/debian-handbook/"/></para>
<para>The campaign had two goals: raising €15,000 for the
translation and completing a €25,000 liberation fund to get the
resulting book published under a free license — that is, a license
that fully follows the Debian Free Software Guidelines.</para>
<para>When the Ulule campaign ended, the first goal had been achieved
with €24,345 raised. The liberation fund was not complete however,
with only €14,935 raised. As initially announced, the liberation
campaign continued independently from Ulule on the book's official
website.</para>
<para>While we were busy translating the book, donations towards the
liberation continued to flow in… And in April 2012, the liberation
fund was completed. You can thus benefit from this book under the
terms of a free license.</para>
<para>We would like to thank everybody who contributed to these
fundraising campaigns, either by pledging some money or by passing
the word around. We couldn't have done it without you.</para>
<section>
<title>Supportive Companies and Organizations</title>
<para>We had the pleasure of getting significant contributions from
many free software-friendly companies and organizations. Thank you
to <ulink url="http://www.codelutin.com">Code Lutin</ulink>, <ulink
url="http://eof.eu.org">École Ouverte Francophone</ulink>, <ulink
url="http://www.evolix.fr">Evolix</ulink>, <ulink
url="http://www.fantinibakery.com">Fantini Bakery</ulink>, <ulink
url="http://fsffrance.org">FSF France</ulink>, <ulink
url="http://www.offensive-security.com">Offensive Security</ulink>
(the company behind <ulink
url="http://www.backtrack-linux.org">BackTrack Linux</ulink>),
<ulink url="http://www.opensides.be">Opensides</ulink>, <ulink
url="http://www.proxmox.com">Proxmox Server Solutions Gmbh</ulink>,
SSIELL (Société Solidaire d'Informatique En Logiciels Libres),
and <ulink url="http://www.syminet.com">Syminet</ulink>.</para>
<para>We would also like to thank <ulink
url="http://www.omgubuntu.co.uk">OMG! Ubuntu</ulink> and <ulink
url="http://www.april.org">April</ulink> for their help in
promoting the operation.</para>
</section>
<section>
<title>Individual Supporters</title>
<para>With over 650 supporters in the initial fundraising, and
several hundred more in the continued liberation campaign, it is
thanks to people like you that this project has been possible.
Thank you!</para>
<para>We want to address our special thanks to those who
contributed at least €35 (sometimes much more!) to the liberation
fund. We are glad that there are so many people who share our
values about freedom and yet recognize that we deserved a
compensation for the work that we have put into this
project.</para>
<para>So thank you Alain Coron, Alain Thabaud, Alan Milnes,
Alastair Sherringham, Alban Dumerain, Alessio Spadaro, Alex King,
Alexandre Dupas, Ambrose Andrews, Andre Klärner, Andreas Olsson,
Andrej Ricnik, Andrew Alderwick, Anselm Lingnau, Antoine Emerit,
Armin F. Gnosa, Avétis Kazarian, Bdale Garbee, Benoit Barthelet,
Bernard Zijlstra, Carles Guadall Blancafort, Carlos Horowicz —
Planisys S.A., Charles Brisset, Charlie Orford, Chris Sykes,
Christian Bayle, Christian Leutloff, Christian Maier, Christian
Perrier, Christophe Drevet, Christophe Schockaert (R3vLibre),
Christopher Allan Webber, Colin Ameigh, Damien Dubédat, Dan
Pettersson, Dave Lozier, David Bercot, David James, David Schmitt,
David Tran Quang Ty, Elizabeth Young, Fabian Rodriguez, Ferenc
Kiraly, Frédéric Perrenot — Intelligence Service 001, Fumihito
Yoshida, Gian-Maria Daffré, Gilles Meier, Giorgio Cittadini,
Héctor Orón Martínez, Henry, Herbert Kaminski, Hideki Yamane,
Hoffmann Information Services GmbH, Holger Burkhardt, Horia
Ardelean, Ivo Ugrina, Jan Dittberner, Jim Salter, Johannes
Obermüller, Jonas Bofjäll, Jordi Fernandez Moledo, Jorg
Willekens, Joshua, Kastrolis Imanta, Keisuke Nakao, Kévin
Audebrand, Korbinian Preisler, Kristian Tizzard, Laurent
Bruguière, Laurent Hamel, Leurent Sylvain, Loïc Revest, Luca
Scarabello, Lukas Bai, Marc Singer, Marcelo Nicolas Manso, Marilyne
et Thomas, Mark Janssen — Sig-I/O Automatisering, Mark Sheppard,
Mark Symonds, Mathias Bocquet, Matteo Fulgheri, Michael Schaffner,
Michele Baldessari, Mike Chaberski, Mike Linksvayer, Minh Ha Duong,
Moreau Frédéric, Morphium, Nathael Pajani, Nathan Paul Simons,
Nicholas Davidson, Nicola Chiapolini, Ole-Morten, Olivier
Mondoloni, Paolo Innocenti, Pascal Cuoq, Patrick Camelin, Per
Carlson, Philip Bolting, Philippe Gauthier, Philippe Teuwen, PJ
King, Praveen Arimbrathodiyil (j4v4m4n), Ralf Zimmermann, Ray
McCarthy, Rich, Rikard Westman, Robert Kosch, Sander Scheepens,
Sébastien Picard, Stappers, Stavros Giannouris, Steve-David
Marguet, T. Gerigk, Tanguy Ortolo, Thomas Hochstein, Thomas
Müller, Thomas Pierson, Tigran Zakoyan, Tobias Gruetzmacher,
Tournier Simon, Trans-IP Internet Services, Viktor Ekmark, Vincent
Demeester, Vincent van Adrighem, Volker Schlecht, Werner Kuballa,
Xavier Neys, and Yazid Cassam Sulliman.</para>
</section>
</section>
<section>
<title>Special Thanks to Contributors</title>
<para>This book would not be what it is without the contributions of
several persons who each played an important role. We would like to
thank Marilyne Brun, who helped us to translate the sample chapter
and who worked with us to define some common translation rules. She
also revised several chapters which were desperately in need of
supplementary work. Thank you to Anthony Baldwin (of Baldwin Linguas)
who translated several chapters for us.</para>
<para>We benefited from the generous help of proofreaders: Daniel
Phillips, Gerold Rupprecht, Gordon Dey, Jacob Owens, and Tom Syroid.
They each reviewed many chapters. Thank you very much!</para>
<para>If you have the pleasure to read these lines in a paperback
copy of the book, then you should join us to thank Benoît Guillon,
Jean-Côme Charpentier, and Sébastien Mengin who worked on the
interior book design. Benoît is the upstream author of <ulink
url="http://dblatex.sourceforge.net">dblatex</ulink> — the tool we
used to convert DocBook into LaTeX (and then PDF). Sébastien is the
designer who created this nice book layout and Jean-Côme is the
LaTeX expert who implemented it as a stylesheet usable with dblatex.
Thank you guys for all the hard work!</para>
<para>Finally, thank you to Thierry Stempfel for the nice pictures
introducing each chapter, and thank you to Doru Patrascu for the
beautiful book cover.</para>
</section>
<section>
<title>Personal Acknowledgments from Raphaël</title>
<para>First off, I would like to thank Nat Makarevitch, who offered
me the possibility to write this book and who provided strong
guidance during the year it took to get it done. Thank you also to
the fine team at Eyrolles, and Muriel Shan Sei Fan in particular. She
has been very patient with me and I learned a lot with her.</para>
<para>The period of the Ulule campaign was very demanding for me but
I would like to thank everybody who helped to make it a success, and
in particular the Ulule team who reacted very quickly to my many
requests. Thank you also to everybody who promoted the operation. I
don't have any exhaustive list (and if I had it would probably be too
long) but I would like to thank a few people who were in touch with
me: Joey-Elijah Sneddon and Benjamin Humphrey of OMG! Ubuntu,
Frédéric Couchet of April.org, Jake Edge of Linux Weekly News,
Clement Lefebvre of Linux Mint, Ladislav Bodnar of Distrowatch, Steve
Kemp of Debian-Administration.org, Christian Pfeiffer Jensen of
Debian-News.net, Artem Nosulchik of LinuxScrew.com, Stephan Ramoin of
Gandi.net, Matthew Bloch of Bytemark.co.uk, the team at Divergence
FM, Rikki Kite of Linux New Media, Jono Bacon, the marketing team at
Eyrolles, and numerous others that I have forgotten (sorry about
that).</para>
<para>I would like to address a special thanks to Roland Mas, my
co-author. We have been collaborating on this book since the start
and he has always been up to the challenge. And I must say that
completing the Debian Administrator's Handbook has been a lot of
work…</para>
<para>Last but not least, thank you to my wife, Sophie. She has been
very supportive of my work on this book and on Debian in general.
There have been too many days (and nights) when I left her alone with
our 2-year-old son to make some progress on the book. I am grateful
for her support and know how lucky I am to have her.</para>
</section>
<section>
<title>Personal Acknowledgments from Roland</title>
<para>Well, Raphaël preempted most of my “external” thank-yous
already. I am still going to emphasize my personal gratitude to the
good folks at Eyrolles, with whom collaboration has always been
pleasant and smooth. Hopefully the results of their excellent advice
hasn't been lost in translation.</para>
<para>I am extremely grateful to Raphaël for taking on the
administrative part of this English edition. From organizing the
funding campaign to the last details of the book layout, producing a
translated book is so much more than just translating and
proofreading, and Raphaël did (or delegated and supervised) it all.
So thanks.</para>
<para>Thanks also to all who more or less directly contributed to
this book, by providing clarifications or explanations, or
translating advice. They are too many to mention, but most of them
can usually be found on various #debian-* IRC channels.</para>
<para>There is of course some overlap with the previous set of
people, but specific thanks are still in order for the people who
actually do Debian. There wouldn't be much of a book without them,
and I am still amazed at what the Debian project as a whole produces
and makes available to any and all.</para>
<para>More personal thanks go to my friends and my clients, for their
understanding when I was less responsive because I was working on
this book, and also for their constant support, encouragement and
egging on. You know who you are; thanks.</para>
<para>And finally; I am sure they would be surprised by being
mentioned here, but I would like to extend my gratitude to Terry
Pratchett, Jasper Fforde, Tom Holt, William Gibson, Neal Stephenson,
and of course the late Douglas Adams. The countless hours I spent
enjoying their books are directly responsible for my being able to
take part in translating this one.</para>
</section>
</section>
</preface>

1960
en-US/01_the-debian-project.xml Normal file
View file

File diff suppressed because it is too large Load diff

323
en-US/02_case-study.xml Normal file
View file

@ -0,0 +1,323 @@
<?xml version="1.0"?>
<chapter id="case-study">
<chapterinfo>
<mediaobject>
<imageobject>
<imagedata fileref="images/chap-etude-cas.png" scalefit="1"/>
</imageobject>
</mediaobject>
<keywordset>
<keyword>Falcot Corp</keyword>
<keyword>SMB</keyword>
<keyword>Strong Growth</keyword>
<keyword>Master Plan</keyword>
<keyword>Migration</keyword>
<keyword>Cost Reduction</keyword>
</keywordset>
</chapterinfo>
<title>Presenting the Case Study</title>
<highlights>
<para>You are the system administrator of a growing small business. In
collaboration with your directors, you come to redefine the information
systems master plan for the coming year, and you choose to
progressively migrate to Debian for reasons as much practical as
economic. Let's see into more detail what's ahead of you...</para>
</highlights>
<para>We have envisioned this case study to approach all modern
information system services currently used in a medium sized company.
After reading this book, you will have all of the elements necessary to
install Debian on your servers and fly on your own wings. You will also
learn how to effectively find information in the event of
difficulties.</para>
<section id="sect.fast-growing-it-needs">
<title>Fast Growing IT Needs</title>
<para>Falcot Corp is a manufacturer of high quality audio equipment.
The company is growing strongly, and has two facilities, one in
Saint-Étienne, and another in Pau. The first has around 150 employees;
it hosts a factory for the manufacturing of speakers, a design lab, and
all administrative office. The Pau site, which is smaller, only has
about 50 workers, and produces amplifiers.</para>
<sidebar>
<title><emphasis>NOTE</emphasis> Fictional company created for case study</title>
<para>The company, Falcot Corp, studied here, is completely
fictional. Any resemblance to an existing company is purely
coincidental. Likewise, certain example data throughout this book may
be fictional.</para>
</sidebar>
<para>The computer system has had difficulty keeping up with the
company's growth, so they are now determined to completely redefine it
to meet various goals established by management:</para>
<itemizedlist>
<listitem>
<para>modern, easily scalable infrastructure;</para>
</listitem>
<listitem>
<para>reducing cost of software licenses thanks to use of Open
Source software;</para>
</listitem>
<listitem>
<para>installation of an e-commerce website, possibly B2B (business
to business, i.e. linking of information systems between different
companies, such as a supplier and its clients);</para>
</listitem>
<listitem>
<para>significant improvement in security to better protect
industrial secrets related to new products.</para>
</listitem>
</itemizedlist>
<para>Underlying these goals, the entire information system will be
overhauled.</para>
</section>
<section id="sect.master-plan">
<title>Master Plan</title>
<indexterm><primary>master plan</primary></indexterm>
<indexterm><primary>migration</primary></indexterm>
<para>With your collaboration, IT management has conducted a slightly
more extensive study, identifying some constraints and defining a plan
for migration to the chosen Open Source system, Debian.</para>
<para>A significant constraint identified is that the accounting
department uses specific software, which only runs on
<trademark>Microsoft Windows</trademark>. The laboratory, for its part,
uses computer aided design software that runs on
<trademark>MacOS X</trademark>.</para>
<figure>
<title>Overview of the Falcot Corp network</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/etude-cas.png" scalefit="1" width="75%"/>
</imageobject>
</mediaobject>
</figure>
<para>The switch to Debian will be gradual; a small business, with
limited means, can not change everything overnight. For starters, the
IT staff must be trained in Debian administration. The servers will
then be converted, starting with the network infrastructure (routers,
firewalls, etc.) followed by the user services (file sharing, Web,
SMTP, etc.). Then the office computers will be gradually migrated to
Debian, for each department to be trained (internally) during the
deployment of the new system.</para>
</section>
<section id="sect.why-gnu-linux">
<title>Why a GNU/Linux Distribution?</title>
<sidebar>
<title><emphasis>BACK TO BASICS</emphasis> Linux or GNU/Linux?</title>
<indexterm><primary>GNU/Linux</primary></indexterm>
<indexterm><primary>Linux</primary></indexterm>
<para>Linux, as you already know, is only a kernel. The expressions,
“Linux distribution” and “Linux system” are, thus, incorrect:
they are, in reality, distributions or systems <emphasis>based
on</emphasis> Linux. These expressions fail to mention the software
that always complete this kernel, among with are the programs
developed by the GNU Project. Dr. Richard Stallman, founder of this
project, insists that the expression “GNU/Linux” be
systematically used, in order to better recognize the important
contributions made by the GNU Project and the principles of freedom
upon which they are founded.</para>
<para>Debian has chosen to follow this recommendation, and, thus,
name its distributions accordingly (thus, the latest stable release
is Debian GNU/Linux 6.0).</para>
</sidebar>
<para>Several factors have dictated this choice. The system
administrator, who was familiar with this distribution, ensured it was
listed among the candidates for the computer system overhaul. Difficult
economic conditions and ferocious competition have limited the budget
for this operation, despite its critical importance for the future of
the company. This is why Open Source solutions were swiftly chosen:
several recent studies indicate they are less expensive than
proprietary solutions, despite quality of service that is equal or
better, so long as personnel qualified to run them are
available.</para>
<sidebar>
<title><emphasis>IN PRACTICE</emphasis> Total cost of ownership (TCO)</title>
<indexterm><primary>TCO</primary></indexterm>
<indexterm><primary>Total Cost of Ownership</primary></indexterm>
<para>The Total Cost of Ownership is the total of all money expended
for the possession or acquisition of an item, in this case referring
to the operating system. This price includes any possible license,
costs for training personnel to work with the new software,
replacement of machines that are too slow, additional repairs, etc.
Everything arising directly from the initial choice is taken into
account.</para>
<para>This TCO, which varies according to the criteria chosen in the
assessment thereof, is rarely significant, in itself. However, it is
very interesting to compare the TCO calculated according to the same
rules. This assessment table is, thus, of paramount importance, and
it is easy to manipulate it in order to draw a predefined conclusion.
Thus, the TCO for a single machine doesn't make sense, since the cost
of an administrator is also reflected in the total number of machines
they manage, a number which obviously depend on the operating system
and tools proposed.</para>
</sidebar>
<para>Among free operating systems, the IT department looked at the
free BSD systems (OpenBSD, FreeBSD, and NetBSD), GNU Hurd, and Linux
distributions. GNU Hurd, which has not yet released a stable version,
was immediately rejected. The choice is simpler between BSD and Linux.
The former have many merits, especially on servers. Pragmatism
indicates, however, the choice of a Linux system since, its installed
base and popularity are both very significant and have numerous
positive consequences. Consequent to this popularity, it is easier to
find qualified personnel to administer Linux machines than technicians
experienced with BSD. Furthermore, Linux adapts to newer hardware
faster than BSD (although they are often neck and neck in this race).
Finally, Linux distributions are often more adapted to user-friendly
graphical user interfaces, indispensable for beginners during migration
of all office machines to a new system.</para>
<sidebar>
<title><emphasis>ALTERNATIVE</emphasis> Debian GNU/kFreeBSD</title>
<indexterm><primary>kFreeBSD</primary></indexterm>
<indexterm><primary>FreeBSD</primary></indexterm>
<indexterm><primary>BSD</primary></indexterm>
<para>Since Debian <emphasis role="distribution">Squeeze</emphasis>,
it is possible to use Debian with a FreeBSD kernel on 32 and 64 bit
computers; this is what the architectures,
<literal>kfreebsd-i386</literal> and
<literal>kfreebsd-amd64</literal> mean. While these architectures are
labeled “experimental” (Technology Preview), already 70 to 80% of
software packaged by Debian is available for them.</para>
<para>These architectures may be an appropriate choice for Falcot
Corp administrators, especially for a firewall (the kernel supports
three different firewalls: IPF, IPFW, PF) or for a NAS (network
attached storage system, for which the ZFS filesystem has been tested
and approved).</para>
</sidebar>
</section>
<section id="sect.why-debian">
<title>Why the Debian Distribution?</title>
<para>Once Linux has been endorsed, a more specific option must be
chosen. Again, the criteria to consider abound. The distribution chosen
must be able to operate for several years, since the migration from one
to another would entail additional costs (although less than if the
migration were between two totally different operating systems, such as
Windows or Mac OS).</para>
<para>Sustainability is, thus, essential, and it must guarantee regular
updates and security patches over several years. The timing of updates
is also significant, since, with so many machines to manage, Falcot
Corp can not handle this complex operation too frequently. The IT
department, therefore, insists on running the latest stable version of
the distribution, benefiting from the best technical assistance, and
guaranteed security patches. In effect, security updates are generally
only guaranteed for a limited duration on older versions of a
distribution.</para>
<para>Finally, for reasons of homogeneity and ease of administration,
the same distribution must run on all the servers (some of which are
Sparc machines, currently running Solaris) and office computers.</para>
<section>
<title>Commercial and Community Driven Distributions</title>
<para>There are two main categories of Linux distributions:
commercial and community driven. The former, developed by companies,
are sold with commercial support services. The latter are developed
according to the same open development model as the free software of
which they are comprised.</para>
<para>A commercial distribution will have, thus, a tendency to
release new versions more frequently, in order to better market
updates and associated services. Their future is directly connected
to the commercial success of their company, and many have already
disappeared (Caldera Linux, StormLinux, etc.).</para>
<para>A community distribution doesn't follow any schedule but its
own. Like the Linux kernel, new versions are released when they are
stable, never before. Its survival is guaranteed, as long as it has
enough individual developers or third party companies to support
it.</para>
<indexterm><primary>distribution</primary><secondary>community Linux distribution</secondary></indexterm>
<indexterm><primary>distribution</primary><secondary>commercial Linux distribution</secondary></indexterm>
<para>A comparison of various Linux distributions led to the choice
of Debian for various reasons:</para>
<itemizedlist>
<listitem>
<para>It is a community distribution, with development ensured
independently from any commercial constraints; its objectives
are, thus, essentially of a technical nature, which seem to favor
the overall quality of the product.</para>
</listitem>
<listitem>
<para>Of all community distributions, it is the most significant
from any perspective: in number of contributors, number of
software packages available, and years of continuous existence.
The size of its community is an incontestable witness to its
continuity.</para>
</listitem>
<listitem>
<para>Statistically, new versions are released every 18 to 24
months, a schedule which is agreeable to administrators.</para>
</listitem>
<listitem>
<para>A survey of several French service companies specialized in
free software has shown that all of them provide technical
assistance for Debian; it is also, for many of them, their chosen
distribution, internally. This diversity of potential providers
is a major asset for Falcot Corp's independence.</para>
</listitem>
<listitem>
<para>Finally, Debian is available on a multitude of
architectures, including Sparc; it will, thus, be possible to
install it on Falcot Corp's several Sun servers.</para>
</listitem>
</itemizedlist>
<para>Once Debian has been chosen, the matter of which version to use
must be decided. Let's see why the administrators have picked Debian
Squeeze.</para>
</section>
</section>
<section id="section.why-debian-stable">
<title>Why Debian Squeeze?</title>
<para>At the time of this writing, Debian Squeeze was still the
“<emphasis role="distribution">Testing</emphasis>” distribution,
but now, while you are reading, it will be the new “<emphasis
role="distribution">Stable</emphasis>” version of Debian. This is
also the reason for which we speak of “Debian Squeeze”, rather than
“Debian 6.0”, since the version number is not used prior to its
effective release.</para>
<para>You may note a few minor differences between what is written here
and what you observe in practice, even though we have limited these
discrepancies as much as possible.</para>
<sidebar>
<title>
<emphasis>PARTICIPATE</emphasis>
</title>
<para>Do not hesitate to indicate any error herein to us by e-mail;
You can reach Raphaël at <email>hertzog@debian.org</email>, and
Roland at <email>lolando@debian.org</email>.</para>
</sidebar>
<para>The choice of Debian Squeeze is well justified based on the fact
that any administrator concerned about the quality of their servers
will naturally gravitate towards the stable version of Debian.
Furthermore, this distribution introduces numerous interesting changes:
support for the latest virtualization technologies (KVM), simplified
PAM configuration, an improved installer supporting BTRFS, all bringing
improvements that directly affect administrators.</para>
</section>
</chapter>

400
en-US/03_existing-setup.xml Normal file
View file

@ -0,0 +1,400 @@
<?xml version="1.0"?>
<chapter id="existing-setup">
<chapterinfo>
<mediaobject>
<imageobject>
<imagedata fileref="images/chap-existant.png" scalefit="1"/>
</imageobject>
</mediaobject>
<keywordset>
<keyword>Existing Setup</keyword>
<keyword>Reuse</keyword>
<keyword>Migration</keyword>
</keywordset>
</chapterinfo>
<title>Analyzing the Existing Setup and Migrating</title>
<highlights>
<para>Any computer system overhaul should take the existing system into
account. This allows reuse of available resources as much as possible
and guarantees interoperability of the various elements comprising the
system. This study will introduce a generic framework to follow in any
migration of a computing infrastructure to Linux.</para>
</highlights>
<section id="sect.heterogeneous-environments">
<title>Coexistence in Heterogeneous Environments</title>
<indexterm><primary>environment</primary><secondary>heterogeneous environment</secondary></indexterm>
<para>Debian integrates very well in all types of existing environments
and plays well with any other operating system. This near-perfect
harmony comes from market pressure which demands that software
publishers develop programs that follow standards. Compliance with
standards allow administrators to switch out programs: clients or
servers, whether free or not.</para>
<section>
<title>Integration with Windows Machines</title>
<para>Samba's SMB/CIFS support ensures excellent communication within
a Windows context. It shares files and print queues to Windows
clients and includes software that allow a Linux machine to use
resources available on Windows servers.</para>
<sidebar>
<title><emphasis>TOOL</emphasis> Samba</title>
<indexterm><primary>Samba</primary></indexterm>
<para>Samba version 2 behaves like a Windows NT server
(authentication, files, print queues, downloading printer drivers,
DFS, etc.) Version 3 works with Active Directory, brings
interoperability with NT4 domain controllers, and supports RPCs
(Remote Procedure Calls). Version 4 is a rewrite (still
experimental), the purpose of which is to provide functionality of
a domain controller compatible with Active Directory.</para>
</sidebar>
</section>
<section>
<title>Integration with Mac OS machines</title>
<para>Netatalk is a program which uses the Appletalk protocol
(running on a Linux kernel) and allows Debian to interface with a Mac
OS network. It ensures the operation of the file server and print
queues, as well as time server (clock synchronization). Its router
function allows interconnection with Appletalk networks.</para>
</section>
<section>
<title>Integration with Other Linux/Unix Machines</title>
<para>Finally, NFS and NIS, both included, guarantee interaction with
Unix systems. NFS ensures file server functionality, while NIS
creates user directories. The BSD printing layer, used by most Unix
systems, also allows sharing of print queues.</para>
<figure>
<title>Coexistence of Debian with MacOS, Windows and Unix systems</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/existant-1.png" width="25%"/>
</imageobject>
</mediaobject>
</figure>
</section>
</section>
<section id="sect.how-to-migrate">
<title>How To Migrate</title>
<indexterm><primary>migration</primary></indexterm>
<para>In order to guarantee continuity of the services, each computer
migration must be planned and executed according to the plan. Whatever
the operating system used, this principle never changes.</para>
<section>
<title>Survey and Identify Services</title>
<para>As simple as it seems, this step is essential. A serious
administrator truly knows the principal roles of each server, but
such roles can change, and sometimes experienced users may have
installed “wild” services. Knowing that they exist will at least
allow you to decide what to do with them, rather than delete them
haphazardly.</para>
<para>For this purpose, it is wise to inform your users of the
project before migrating the server. To involve them in the project,
it may be useful to install the most common free software programs on
their desktops prior to migration, which they will come across again
after the migration to Debian; OpenOffice.org and the Mozilla suite
are the best examples here.</para>
<section>
<title>Network and Processes</title>
<para><indexterm><primary><command>nmap</command></primary></indexterm>
The <command>nmap</command> tool (in the package with the same
name) will quickly identify Internet services hosted by a network
connected machine without even requiring to log in to it. Simply
call the following command on another machine connected to the same
network:</para>
<screen>
<computeroutput>$ </computeroutput><userinput>nmap mirlaine</userinput>
<computeroutput>Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-29 16:36 CET
Interesting ports on mirlaine (192.168.1.99):
Not shown: 1694 closed ports
PORT STATE SERVICE
22/tcp open ssh
79/tcp open finger
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds</computeroutput>
</screen>
<sidebar>
<title><emphasis>ALTERNATIVE</emphasis> Use <command>netstat</command> to find the list of available services</title>
<para>On a Linux machine, the <command>netstat -tupan</command>
command will show the list of active or pending TCP sessions, as
well UDP ports on which running programs are listening. This
facilitates identification of services offered on the
network.</para>
</sidebar>
<sidebar>
<title><emphasis>GOING FURTHER</emphasis> IPv6</title>
<para>Some network commands may work either with IPv4 (the
default usually) or with IPv6. This is especially the case with
the <command>nmap</command> and <command>netstat</command>
commands, but also others, such as <command>route</command> or
<command>ip</command>. The convention is that this behavior is
enabled by the <parameter>-6</parameter> command-line
option.</para>
</sidebar>
<para>If the server is a Unix machine offering shell accounts to
users, it is interesting to determine if processes are executed in
the background in the absence of their owner. The command
<command>ps auxw</command> displays a list of all processes with
their user identity. By checking this information against the
output of the <command>who</command> command, which gives a list of
logged in users, it is possible to identify wild servers or
programs running in the background. Looking at
<filename>crontabs</filename> (tables listing automatic actions
scheduled by users) will often provide interesting information on
functions fulfilled by the server (a complete explanation of
<command>cron</command> is available in <xref
linkend="sect.task-scheduling-cron-atd"/>).</para>
<para>In any case, it is essential to backup your servers: this
allows recovery of information after the fact, when users will
report specific problems due to the migration.</para>
</section>
</section>
<section>
<title>Backing up the Configuration</title>
<para>It is wise to retain the configuration of every service
identified in order to be able to install the equivalent on the
updated server. The strict minimum is to print the configuration
files and make a backup copy of them.</para>
<para>For Unix machines, the configuration files are usually found in
<filename>/etc/</filename>, but they may be located in a
sub-directory of <filename>/usr/local/</filename>. This is the case
if a program has been installed from sources, rather than with a
package. One may also find them, in some cases, under
<filename>/opt/</filename>.</para>
<para>For data managing services (such as databases), it is strongly
recommended to export them to a standard format that will be easily
imported by the new software. Such a format is usually in text mode
and documented; it may be, for example, an SQL dump for a database,
or an LDIF file for an LDAP server.</para>
<figure>
<title>Database backups</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/existant-2.png" width="50%"/>
</imageobject>
</mediaobject>
</figure>
<para>Each server software is different, and it is impossible to
detail all existing cases. See the new and current software
documentation to identify the exportable (thus, re-importable)
portions and those which will require manual manipulation. Reading
this book will clarify the configuration of the main Linux server
programs.</para>
</section>
<section>
<title>Taking Over an Existing Debian Server</title>
<indexterm><primary>recovering a Debian machine</primary></indexterm>
<indexterm><primary>exploring a Debian machine</primary></indexterm>
<indexterm><primary>taking over a Debian server</primary></indexterm>
<para>To effectively take over its maintenance, one may analyze a
machine already running with Debian.</para>
<para>The first file to check is
<filename>/etc/debian_version</filename>, which usually contains the
version number for the installed Debian system (it is part of the
<emphasis>base-files</emphasis> package). If it indicates
<literal>testing/unstable</literal>, it means that the system was
updated with packages coming from one of these two development
distributions.</para>
<para>The <command>apt-show-versions</command> program (from the
Debian package of the same name) checks the list of packages
installed and identifies the versions available.
<command>aptitude</command> can also be used for these tasks, albeit
in a less systematic manner.</para>
<para>A glance at the <filename>/etc/apt/sources.list</filename> file
will show where the installed Debian packages likely came from. If
many unknown sources appear, the administrator may choose to
completely reinstall the computer's system to ensure optimal
compatibility with the software provided by Debian.</para>
<para>The <filename>sources.list</filename> file is often a good
indicator: the majority of administrators keep, at least in comments,
the list of prior APT sources used. But you should not forget that
sources used in the past might have been deleted, and that some
random packages grabbed on the Internet might have been manually
installed (with the <command>dpkg</command> command). In this case,
the machine is misleading in its appearance of “standard” Debian.
This is why you should pay attention to any indication that will give
away the presence of external packages (appearance of
<filename>deb</filename> files in unusual directories, package
version numbers with a special suffix indicating that it originated
from outside the Debian project, such as <literal>ubuntu</literal> or
<literal>ximian</literal>, etc.)</para>
<para>Likewise, it is interesting to analyze the contents of the
directory <filename>/usr/local/</filename>, intended to contain
programs compiled and installed manually. Listing software installed
in this manner is instructive, since this raises questions on the
reasons for not using the corresponding Debian package, if such a
package exists.</para>
<sidebar>
<title><emphasis>QUICK LOOK</emphasis> <emphasis role="pkg">cruft</emphasis></title>
<para>The <emphasis role="pkg">cruft</emphasis> package proposes to
list the available files that are not owned by any package. It has
some filters (more or less effective, and more or less up to date)
to avoid reporting some legitimate files (files generated by Debian
packages, or generated configuration files not managed by
<command>dpkg</command>, etc.).</para>
<para>Be careful to not blindly delete everything that
<command>cruft</command> might list!</para>
</sidebar>
</section>
<section>
<title>Installing Debian</title>
<para>All information on the current server being now known, we can
shut it down and begin to install Debian on it.</para>
<indexterm><primary>architecture</primary></indexterm>
<para>To choose the appropriate version, we must know the computer's
architecture. If it is a PC, it is most likely to be i386. In other
cases, we can narrow down the possibilities according to the
previously used system.</para>
<figure condition="final">
<title>Installing the appropriate Debian version</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/existant-3.png" width="50%"/>
</imageobject>
</mediaobject>
</figure>
<para>The <xref linkend="tab-corresp" xrefstyle="nopage"/> is not
intended to be exhaustive, but may be helpful. In any case, the
original documentation for the computer is the most reliable source
to find this information.</para>
<sidebar>
<title><emphasis>HARDWARE</emphasis> Next-generation PC</title>
<indexterm><primary>Itanium</primary></indexterm>
<indexterm><primary>amd64</primary></indexterm>
<indexterm><primary>ia64</primary></indexterm>
<para>Most recent computers have 64 bit Intel or AMD processors,
compatible with older 32 bit processors; the software compiled for
“i386” architecture thus works. On the other hand, this
compatibility mode does not fully exploit the capabilities of these
new processors. This is why Debian provides software for “ia64”
architecture for Intel Itanium chips and “amd64” for AMD chips.
This last also works with Intel “em64t” processors, which are
very similar to AMD64 processors.</para>
</sidebar>
<table colsep="1" id="tab-corresp">
<title>Matching operating system and architecture</title>
<tgroup cols="2">
<thead>
<row>
<entry>Operating System</entry>
<entry>Architecture(s)</entry>
</row>
</thead>
<tbody>
<row>
<entry>DEC Unix (OSF/1)</entry>
<entry>alpha, mipsel</entry>
</row>
<row>
<entry>HP Unix</entry>
<entry>hppa</entry>
</row>
<row>
<entry>IBM AIX</entry>
<entry>powerpc</entry>
</row>
<row>
<entry>Irix</entry>
<entry>mips</entry>
</row>
<row>
<entry>MacOS</entry>
<entry>powerpc, m68k, i386</entry>
</row>
<row>
<entry>MVS</entry>
<entry>s390</entry>
</row>
<row>
<entry>Solaris, SunOS</entry>
<entry>sparc, m68k, i386</entry>
</row>
<row>
<entry>Ultrix</entry>
<entry>mips</entry>
</row>
<row>
<entry>VMS</entry>
<entry>alpha</entry>
</row>
<row>
<entry>Windows NT</entry>
<entry>i386, alpha, mipsel</entry>
</row>
<row>
<entry>Windows XP / Windows Server 2008</entry>
<entry>i386, ia64, amd64</entry>
</row>
<row>
<entry>Windows Vista / Windows 7</entry>
<entry>i386, amd64</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section>
<title>Installing and Configuring the Selected Services</title>
<para>Once Debian is installed, we must install and configure one by
one all of the services that this computer must host. The new
configuration must take into consideration the prior one in order to
ensure a smooth transition. All the information collected in the
first two steps are useful to successfully complete this part.</para>
<figure>
<title>Install the selected services</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/existant-4.png" width="66%"/>
</imageobject>
</mediaobject>
</figure>
<para>Prior to jumping in to this exercise with both feet, it is
strongly recommended that you read the remainder of this book. After
that you will have a more precise understanding of how to configure
the expected services.</para>
<para/>
</section>
</section>
</chapter>

1352
en-US/04_installation.xml Normal file
View file

File diff suppressed because it is too large Load diff

1657
en-US/05_packaging-system.xml Normal file
View file

File diff suppressed because it is too large Load diff

2080
en-US/06_apt.xml Normal file
View file

File diff suppressed because it is too large Load diff

636
en-US/07_solving-problems.xml Normal file
View file

@ -0,0 +1,636 @@
<?xml version="1.0"?>
<chapter id="solving-problems">
<chapterinfo>
<mediaobject>
<imageobject>
<imagedata fileref="images/chap-src-info.png" scalefit="1"/>
</imageobject>
</mediaobject>
<keywordset>
<keyword>Documentation</keyword>
<keyword>Solving problems</keyword>
<keyword>Log files</keyword>
<keyword>README.Debian</keyword>
<keyword>Manual</keyword>
<keyword>info</keyword>
</keywordset>
</chapterinfo>
<title>Solving Problems and Finding Relevant Information</title>
<highlights>
<para>For an administrator, the most important skill is to be able to
cope with any situation, known or unknown. This chapter gives a number
of methods that will — hopefully — allow you to isolate the cause
of any problem that you will encounter, so that you may be able to
resolve them.</para>
</highlights>
<section id="sect.documation-sources">
<title>Documentation Sources</title>
<indexterm><primary>documentation</primary></indexterm>
<para>Before you can understand what is really going on when there is a
problem, you need to know the theoretical role played by each program
involved in the problem. To do this, the best reflex to have is consult
their documentation; but since these documentations are many and widely
dispersed, you should know all the places where they can be
found.</para>
<section id="section.manuel">
<title>Manual Pages</title>
<indexterm><primary><command>man</command></primary></indexterm>
<indexterm><primary><command>apropos</command></primary></indexterm>
<indexterm><primary>manual pages</primary></indexterm>
<indexterm><primary>manual pages</primary></indexterm>
<sidebar>
<title><emphasis>CULTURE</emphasis> <acronym>RTFM</acronym></title>
<indexterm><primary><acronym>RTFM</acronym></primary></indexterm>
<para>This acronym stands for “Read the F**king Manual”, but
can also be expanded in a friendlier variant, “Read the Fine
Manual”. This phrase is sometimes used in (terse) responses to
questions from newbies. It is rather abrupt, and betrays a certain
annoyance at a question asked by someone who has not even bothered
to read the documentation. Some say that this classic response is
better than no response at all (since it indicates that the
documentation contains the information sought), or than a more
verbose and angry answer.</para>
<para>In any case, if someone responds “RTFM” to you, it is
often wise not to take offense. Since this answer may be perceived
as vexing, you might want to try and avoid receiving it. If the
information that you need is not in the manual, which can happen,
you might want to say so, preferably in your initial question. You
should also describe the various steps that you have personally
taken to find information before you raised a question on a forum.
You can, before using forums, follow a few common sense
recommendations, which have been listed by Eric Raymond. <ulink
type="block"
url="http://catb.org/~esr/faqs/smart-questions.html"/></para>
</sidebar>
<para>Manual pages, while relatively terse, contain a great deal of
essential information. We will quickly go over the command for
viewing them. Simply type <command>man
<replaceable>manual-page</replaceable></command> — the manual page
usually goes by the same name as the command whose documentation is
sought. For example, to learn about the possible options for the
<command>cp</command> command, you would type the <command>man
cp</command> command at the shell prompt (see sidebar).</para>
<sidebar>
<title><emphasis>BACK TO BASICS</emphasis> The shell, a command line interpreter</title>
<indexterm><primary>command line interpreter</primary></indexterm>
<indexterm><primary>shell</primary></indexterm>
<para>A command line interpreter, also called a “shell”, is a
program that executes commands that are either entered by the user
or stored in a script. In interactive mode, it displays a prompt
(usually ending in <literal>$</literal> for a normal user, or by
<literal>#</literal> for an administrator) indicating that it is
ready to read a new command. <xref
linkend="short-remedial-course"/> describes the basics of using the
shell.</para>
<para>The default and most commonly used shell is
<command>bash</command> (Bourne Again SHell), but there are others,
including <command>dash</command>, <command>csh</command>,
<command>tcsh</command> and <command>zsh</command>.</para>
<para>Among other things, most shells offer help during input at
the prompt, such as the completion of command or file names (which
you can generally activate by pressing the tab key), or recalling
previous commands (history management).</para>
</sidebar>
<para>Man pages not only document programs accessible from the
command line, but also configuration files, system calls, C library
functions, and so forth. Sometimes names can collide. For example,
the shell's <command>read</command> command has the same name as the
system call <function>read</function>. This is why manual pages are
organized in numbered sections:</para>
<orderedlist>
<listitem>
<para>commands that can be executed from the command line;</para>
</listitem>
<listitem>
<para>system calls (functions provided by the kernel);</para>
</listitem>
<listitem>
<para>library functions (provided by system libraries);</para>
</listitem>
<listitem>
<para>devices (under Unix, these are special files, usually
placed in the <filename>/dev/</filename> directory);</para>
</listitem>
<listitem>
<para>config files (formats and conventions);</para>
</listitem>
<listitem>
<para>games;</para>
</listitem>
<listitem>
<para>sets of macros and standards;</para>
</listitem>
<listitem>
<para>system administration commands;</para>
</listitem>
<listitem>
<para>kernel routines.</para>
</listitem>
</orderedlist>
<para>It is possible to specify the section of the manual page that
you are looking for: to view the documentation for the
<function>read</function> system call, you would type <command>man 2
read</command>. When no section is explicitly specified, the first
section that has a manual page with the requested name will be shown.
Thus, <command>man shadow</command> returns
<citerefentry><refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum></citerefentry>
because there are no manual pages for
<foreignphrase>shadow</foreignphrase> in sections 1 to 4.</para>
<sidebar>
<title><emphasis>TIP</emphasis> <command>whatis</command></title>
<indexterm><primary><command>whatis</command></primary></indexterm>
<para>If you do not want to look at the full manual page, but only
a short description to confirm that it is what you are looking for,
simply enter <command>whatis
<replaceable>command</replaceable></command>.</para>
<screen>
<computeroutput>$ </computeroutput><userinput>whatis scp</userinput>
<computeroutput>scp (1) - secure copy (remote file copy program)</computeroutput>
</screen>
<para>This short description is included in the
<emphasis>NAME</emphasis> section at the beginning of all manual
pages.</para>
</sidebar>
<para>Of course, if you do not know the names of the commands, the
manual is not going to be of much use to you. This is the purpose of
the <command>apropos</command> command, which helps you conduct a
search in the manual pages, or more specifically in their short
descriptions. Each manual page begins essentially with a one line
summary. <command>apropos</command> returns a list of manual pages
that mention the keyword(s) requested. If you choose them well, you
will find the name of the command that you need.</para>
<example>
<title>Finding <command>cp</command> with <command>apropos</command></title>
<screen>
<computeroutput>$ </computeroutput><userinput>apropos "copy file"</userinput>
<computeroutput>cp (1) - copy files and directories
cpio (1) - copy files to and from archives
hcopy (1) - copy files from or to an HFS volume
install (1) - copy files and set attributes
</computeroutput>
</screen>
</example>
<sidebar>
<title><emphasis>TIP</emphasis> Browsing by following links</title>
<para>Many manual pages have a “SEE ALSO” section, usually at
the end. It refers to other manual pages relevant to similar
commands, or to external documentation. In this way, it is possible
to find relevant documentation even when the first choice is not
optimal.</para>
</sidebar>
<para>The <command>man</command> command is not the only means of
consulting the manual pages, since <command>konqueror</command> (in
KDE) and <command>yelp</command> (under GNOME) programs also offer
this possibility. There is also a web interface, provided by the
<command>man2html</command> package, which allows you to view manual
pages in a web browser. On a computer where this package is
installed, use this URL: <ulink type="block"
url="http://localhost/cgi-bin/man/man2html"/></para>
<para>This utility requires a web server. This is why you should
choose to install this package on one of your servers: all users of
the local network could benefit from this service (including
non-Linux machines), and this will allow you not to set up an HTTP
server on each workstation. If your server is also accessible from
other networks, it may be desirable to restrict access to this
service only to users of the local network.</para>
<indexterm><primary><command>man2html</command></primary></indexterm>
<sidebar>
<title><emphasis>DEBIAN POLICY</emphasis> Required man pages</title>
<para>Debian requires each program to have a manual page. If the
upstream author does not provide one, the Debian package maintainer
will usually write a minimal page that will at the very least
direct the reader to the location of the original
documentation.</para>
</sidebar>
</section>
<section>
<title><emphasis>info</emphasis> Documents</title>
<indexterm><primary><emphasis>info</emphasis></primary></indexterm>
<indexterm><primary>GNU</primary><secondary>Info</secondary></indexterm>
<para>The GNU project has written manuals for most of its programs in
the <emphasis>info</emphasis> format; this is why many manual pages
refer to the corresponding <emphasis>info</emphasis> documentation.
This format offers some advantages, but the program to view these
documents is also slightly more complex.</para>
<para>It is of course called <command>info</command>, and it takes
the name of the “node” to be consulted as argument. The
<emphasis>info</emphasis> documentation has a hierarchical structure,
and if you invoke <command>info</command> without parameters, it will
display a list of the nodes available at the first level. Usually,
nodes bear the name of the corresponding commands.</para>
<para>The navigation controls in the documentation are not
particularly intuitive. The best method to familiarize yourself with
the program is probably to invoke it, then enter
<userinput>h</userinput> (for “help”), and then follow the
instructions to learn through practice. Alternatively, you could also
use a graphical browser, which is a lot more user-friendly. Again,
<command>konqueror</command> and <command>yelp</command> work; the
<command>info2www</command> also provides a web interface. <ulink
type="block" url="http://localhost/cgi-bin/info2www"/></para>
<indexterm><primary><command>info2www</command></primary></indexterm>
<para>Note that the <emphasis>info</emphasis> system does not allow
translation, unlike the <command>man</command> page system.
<emphasis>info</emphasis> documents are thus always in English.
However, when you ask the <command>info</command> program to display
a non-existing <emphasis>info</emphasis> page, it will fall back on
the <emphasis>man</emphasis> page by the same name (if it exists),
which might be translated.</para>
</section>
<section>
<title>Specific Documentation</title>
<indexterm><primary>documentation</primary></indexterm>
<para>Each package includes its own documentation. Even the least
well documented programs generally have a <filename>README</filename>
file containing some interesting and/or important information. This
documentation is installed in the
<filename>/usr/share/doc/<replaceable>package</replaceable>/</filename>
directory (where <replaceable>package</replaceable> represents the
name of the package). If the documentation is particularly large, it
may not be included in the program's main package, but might be
offloaded to a dedicated package which is usually named
<literal><replaceable>package</replaceable>-doc</literal>. The main
package generally recommends the documentation package so that you
can easily find it.</para>
<indexterm><primary><filename>README.Debian</filename></primary></indexterm>
<indexterm><primary><filename>changelog.Debian.gz</filename></primary></indexterm>
<indexterm><primary><filename>NEWS.Debian.gz</filename></primary></indexterm>
<para>In the
<filename>/usr/share/doc/<replaceable>package</replaceable>/</filename>
directory there are also some files provided by Debian and which
complete the documentation by specifying the package's
particularities or improvements compared to a traditional
installation of the software. The <filename>README.Debian</filename>
file also indicates all of the adaptations that were made to comply
with the Debian Policy. The <filename>changelog.Debian.gz</filename>
file allows the user to follow the modifications made to the package
over time: it is very useful to try to understand what has changed
between two installed versions that do not have the same behavior.
Finally, there is sometimes a <filename>NEWS.Debian.gz</filename>
file which documents the major changes in the program that may
directly concern the administrator.</para>
</section>
<section>
<title>Websites</title>
<para>In most cases, free software programs have websites that are
used to distribute it and to unite the community of its developers
and users. These sites are frequently loaded with relevant
information in various forms: official documentation, FAQ (Frequently
Asked Questions), mailing list archives, etc. Often, problems that
you may have have already been the subject of many questions; the FAQ
or mailing list archives may have a solution for it. A good mastery
of search engines will prove immensely valuable to find relevant
pages quickly (by restricting the search to the Internet domain or
sub-domain dedicated to the program). If the search returns too many
pages or if the results do not match what you seek, you can add the
keyword <userinput>debian</userinput> to limit results and target
relevant information.</para>
<sidebar>
<title><emphasis>TIPS</emphasis> From error to solution</title>
<para>If the software returns a very specific error message, enter
it into the search engine (between double quotes,
<literal>"</literal>, in order to search not for individual
keywords, but for the complete phrase). In most cases, the first
links returned will contain the answer that you need.</para>
<para>In other cases, you will get very general errors, such as
“Permission denied”. In this case, it is best to check the
permissions of the elements involved (files, user ID, groups,
etc.).</para>
</sidebar>
<para>If you do not know the address for the software's website,
there are various means of getting it. First, check if there is a
<literal>Homepage</literal> field in the package's meta-information
(<command>apt-cache show
<replaceable>package</replaceable></command>). Alternately, the
package description may contain a link to the program's official
website. If no URL is indicated, look at
<filename>/usr/share/doc/<replaceable>package</replaceable>/copyright</filename>.
The Debian maintainer generally indicates in this file where they got
the program's source code, and this is likely to be the website that
you need to find. If at this stage your search is still unfruitful,
consult a free software directory, such as Freshmeat.net or
Framasoft, or search directly with a search engine, such as Google or
Yahoo. <ulink type="block" url="http://freshmeat.net/"/> <ulink
type="block" url="http://framasoft.org/"/></para>
<indexterm><primary><filename>copyright</filename></primary></indexterm>
<indexterm><primary><foreignphrase>Freshmeat</foreignphrase></primary></indexterm>
<indexterm><primary><emphasis>wiki.debian.org</emphasis></primary></indexterm>
<para>You might also want to check the Debian wiki, a collaborative
website where anybody, even simple visitors, can make suggestions
directly from their browsers. It is used as much by developers so as
to design and specify their projects, as by users who share their
knowledge by writing documents collaboratively. <ulink type="block"
url="http://wiki.debian.org/"/></para>
</section>
<section>
<title>Tutorials (<emphasis>HOWTO</emphasis>)</title>
<indexterm><primary><emphasis>HOWTO</emphasis></primary></indexterm>
<para>A howto is a documentation that describes, in concrete terms
and step by step, how to reach a predefined goal. The covered goals
are relatively varied, but often technical in nature: for example,
setting up IP Masquerading, configuring software RAID, installing a
Samba server, etc. These documents often attempt to cover all of the
potential problems likely to occur during the implementation of a
given technology.</para>
<para>Many such tutorials are managed by the Linux Documentation
Project (LDP), whose website hosts all of these documents:<ulink
type="block" url="http://www.tldp.org/"/> </para>
<para>To view them locally, just install the <emphasis
role="pkg">doc-linux-html</emphasis> package. Local HTML versions
will then be available in the
<filename>/usr/share/doc/HOWTO/</filename> directory.</para>
<indexterm><primary><emphasis>doc-linux-html</emphasis></primary></indexterm>
<indexterm><primary><emphasis>doc-linux-fr-html</emphasis></primary></indexterm>
<indexterm><primary>LDP</primary></indexterm>
<indexterm><primary>Linux Documentation Project</primary></indexterm>
<para>Take these documents with a grain of salt. They are often
several years old; the information they contain is sometimes
obsolete. This phenomenon is even more frequent for their
translations, since updates are neither systematic nor instant after
the publication of a new version of the original documents. This is
part of the joys of working in a volunteer environment and without
constraints...</para>
</section>
</section>
<section id="sect.common-procedures">
<title>Common Procedures</title>
<indexterm><primary>standard procedure</primary></indexterm>
<para>The purpose of this section is to present some general tips on
certain operations that an administrator will frequently have to
perform. These procedures will of course not cover every possible case
in an exhaustive way, but they may serve as starting points for the
more difficult cases.</para>
<sidebar>
<title><emphasis>DISCOVERY</emphasis> Documentation in French</title>
<para>Often, documentation translated into a non-English language is
available in a separate package with the name of the corresponding
package, followed by
<literal>-<replaceable>lang</replaceable></literal> (where
<replaceable>lang</replaceable> is the two-letter ISO code for the
language).</para>
<para>Thus, the <emphasis>apt-howto-fr</emphasis> package contains
the French translation of the howto for <emphasis>APT</emphasis>.
Likewise, the packages <emphasis>quick-reference-fr</emphasis> and
<emphasis>debian-reference-fr</emphasis> (Debian reference) are the
French versions of the references guides for Debian (initially
written in English by Osamu Aoki).</para>
</sidebar>
<section>
<title>Configuring a Program</title>
<indexterm><primary>configuration</primary><secondary>program configuration</secondary></indexterm>
<indexterm><primary>program</primary><secondary>configuration</secondary></indexterm>
<para>When you want to configure an unknown package, you must proceed
in stages. First, you should read what the package maintainer has
documented. Reading
<filename>/usr/share/doc/<replaceable>package</replaceable>/README.Debian</filename>
will indeed allow you to learn of specific provisions made to
simplify the use of the software. It is sometimes essential in order
to understand the differences from the original behavior of the
program, as described in the general documentation, such as howtos.
Sometimes this file also details the most common errors in order for
you to avoid wasting time on common problems.</para>
<para>Then, you should look at the software's official documentation
— refer to the previous section to identify the various existing
documentation sources. The command <command>dpkg -L
<replaceable>package</replaceable></command> gives a list of files
included in the package; you can therefore quickly identify the
available documentation (as well as the configuration files, located
in <filename>/etc/</filename>). <command>dpkg -s
<replaceable>package</replaceable></command> produces the package
headers and shows any possible recommended or suggested packages; in
there, you can find documentation or a utility that will ease the
configuration of the software.</para>
<para>Finally, the configuration files are often self-documented by
many explanatory comments detailing the various possible values for
each configuration setting. So much so that it is sometimes enough to
just choose a line to activate from among those available. In some
cases, examples of configuration files are provided in the
<filename>/usr/share/doc/<replaceable>package</replaceable>/examples/</filename>
directory. They may serve as a basis for your own configuration
file.</para>
<sidebar role="fil">
<title><emphasis>DEBIAN POLICY</emphasis> Location of examples</title>
<indexterm><primary>examples, location</primary></indexterm>
<para>All examples must be installed in the
<filename>/usr/share/doc/<replaceable>package</replaceable>/examples/</filename>
directory. This may be a configuration file, program source code
(an example of the use of a library), or a data conversion script
that the administrator can use in certain cases (such as to
initialize a database). If the example is specific to a particular
architecture, it should be installed in
<filename>/usr/lib/<replaceable>package</replaceable>/examples/</filename>
and you should create a link pointing to that file in the
<filename>/usr/share/doc/<replaceable>package</replaceable>/examples/</filename>
directory.</para>
</sidebar>
</section>
<section>
<title>Monitoring What Daemons Are Doing</title>
<para>A daemon somewhat complicates one's understanding of a
situation, since it does not interact directly with the
administrator. To check that a daemon is actually working, you need
to test it. For example, to check the Apache (web server) daemon,
test it with an HTTP request.</para>
<para>To allow such tests, each daemon generally records everything
that it does, as well as any errors that it encounters, in what are
called “log files” or “system logs”. Logs are stored in
<filename>/var/log/</filename> or one of its subdirectories. To know
the precise name of a log file for each daemon, see its
documentation. Note: a single test is not always sufficient if it
does not cover all the possible usage cases; some problems only occur
in particular circumstances.</para>
<sidebar role="fil">
<title><emphasis>TOOL</emphasis> The <command>rsyslogd</command> daemon</title>
<indexterm><primary><command>syslogd</command></primary></indexterm>
<indexterm><primary>logs</primary><secondary>files</secondary></indexterm>
<indexterm><primary>files</primary><secondary>logs</secondary></indexterm>
<para><command>rsyslogd</command> is special: it collects logs
(internal system messages) that are sent to it by other programs.
Each log entry is associated with a subsystem (e-mail, kernel,
authentication, etc.) and a priority, two bits of information that
<command>rsyslogd</command> processes to decide on what to do. The
log message may be recorded in various log files, and/or sent to an
administration console. The details are defined in the
<filename>/etc/rsyslog.conf</filename> configuration file
(documented in the manual page of the same name).</para>
<para>Certain C functions, which are specialized in sending logs,
simplify the use of the <command>rsyslogd</command> daemon. However
some daemons manage their own log files (this is the case, for
example, of <command>samba</command>, that implements Windows
shares on Linux).</para>
</sidebar>
<sidebar>
<title><emphasis>BACK TO BASICS</emphasis> Daemon</title>
<indexterm><primary>daemon</primary></indexterm>
<para>A daemon is a program that is not explicitly invoked by the
user and that stays in the background, waiting for a certain
condition to be met before performing a task. Many server programs
are daemons, a term that explains that the letter “d” is
frequently present at the end of their name
(<command>sshd</command>, <command>smtpd</command>,
<command>httpd</command>, etc.).</para>
</sidebar>
<para>Any preventive operation begins by regularly consulting the
most relevant server logs. You can thus diagnose problems before they
are even reported by disgruntled users. Indeed users may sometimes
wait for a problem to reoccur over several days before reporting it.
You can use a specific tool to analyze the content of the larger log
files. You can find such utilities for web servers (such as
<command>analog</command>, <command>awstats</command>,
<command>webalizer</command> for Apache), for FTP servers, for
proxy/cache servers, for firewalls, for e-mail servers, for DNS
servers, and even for print servers. Some of these utilities operate
in a modular manner and allow analysis of several types of log files.
This is the case of <command>lire</command> or also
<command>modlogan</command>. Other tools, such as
<command>logcheck</command> (a software discussed in <xref
linkend="security"/>), scan these files to search for alerts to be
dealt with.</para>
<indexterm><primary><command>analog</command></primary></indexterm>
<indexterm><primary><command>awtats</command></primary></indexterm>
<indexterm><primary><command>webalizer</command></primary></indexterm>
<indexterm><primary><command>logcheck</command></primary></indexterm>
<indexterm><primary><command>lire</command></primary></indexterm>
<indexterm><primary><command>modlogan</command></primary></indexterm>
</section>
<section>
<title>Asking for Help on a Mailing List</title>
<para>If your various searches haven't helped you to get to the root
of a problem, it is possible to get help from other, perhaps more
experienced people. This is indeed the purpose of the
<email>debian-user@lists.debian.org</email> mailing list. As with any
community, it has rules that need to be followed. Before asking any
question, you should check that your problem isn't already covered by
recent discussions on the list or by any official documentation.
<ulink type="block" url="http://wiki.debian.org/DebianMailingLists"/>
<ulink type="block"
url="http://lists.debian.org/debian-user/"/></para>
<indexterm><primary><email>debian-user</email></primary></indexterm>
<indexterm><primary>mailing lists</primary></indexterm>
<sidebar>
<title><emphasis>TIP</emphasis> Reading a list on the Web</title>
<para>For high volume mailing lists, such as
<email>debian-user@lists.debian.org</email>, it may be worthwhile
to go through them as a discussion forum (or newsgroup). Gmane.org
allows consultation of the Debian lists in this format. The list
mentioned above is available at: <ulink type="block"
url="http://dir.gmane.org/gmane.linux.debian.user"/></para>
</sidebar>
<sidebar>
<title><emphasis>BACK TO BASICS</emphasis> Netiquette applies</title>
<para>In general, for all correspondence on e-mail lists, the rules
of Netiquette should be followed. This term refers to a set of
common sense rules, from common courtesy to mistakes that should be
avoided. <ulink type="block"
url="http://tools.ietf.org/html/rfc1855"/>
<indexterm><primary>Netiquette</primary></indexterm></para>
</sidebar>
<para>Once you have met those two conditions, you can think of
describing your problem to the mailing list. Include as much relevant
information as possible: various tests conducted, documentation
consulted, how you attempted to diagnose the problem, the packages
concerned or those that may be involved, etc. Check the Debian Bug
Tracking System (BTS, described in sidebar <xref
linkend="cadre.bts"/>) for similar problems, and mention the results
of that search, providing links to bugs found. BTS starts on: <ulink
type="block" url="http://www.debian.org/Bugs/index.html"/></para>
<para>The more courteous and precise you have been, the greater your
chances are of getting an answer, or, at least, some elements of
response. If you receive relevant information by private e-mail,
think of summarizing this information publicly so that others can
benefit. Allow the list's archives, searched through various search
engines, to show the resolution for others who may have the same
question.</para>
</section>
<section>
<title>Reporting a Bug When a Problem Is Too Difficult</title>
<indexterm><primary>report a bug</primary></indexterm>
<indexterm><primary>bug report</primary></indexterm>
<para>If all of your efforts to resolve a problem fail, it is
possible that a resolution is not your responsibility, and that the
problem is due to a bug in the program. In this case, the proper
procedure is to report the bug to Debian or directly to the upstream
developers. To do this, isolate the problem as much as possible and
create a minimal test situation in which it can be reproduced. If you
know which program is the apparent cause of the problem, you can find
its corresponding package using the command, <command>dpkg -S
<replaceable>file_in_question</replaceable></command>. Check the Bug
Tracking System
(<literal>http://bugs.debian.org/<replaceable>package</replaceable></literal>)
to ensure that the bug has not already been reported. You can then
send your own bug report, using the <command>reportbug</command>
command, including as much information as possible, especially a
complete description of those minimal test cases that will allow
anyone to recreate the bug.</para>
<para>The elements of this chapter are a means of effectively
resolving issues that the following chapters may bring about. Use
them as often as necessary!</para>
</section>
</section>
</chapter>

2898
en-US/08_basic-configuration.xml Normal file
View file

File diff suppressed because it is too large Load diff

2803
en-US/09_unix-services.xml Normal file
View file

File diff suppressed because it is too large Load diff

1903
en-US/10_network-infrastructure.xml Normal file
View file

File diff suppressed because it is too large Load diff

3127
en-US/11_network-services.xml Normal file
View file

File diff suppressed because it is too large Load diff

3530
en-US/12_advanced-administration.xml Normal file
View file

File diff suppressed because it is too large Load diff

1119
en-US/13_workstation.xml Normal file
View file

File diff suppressed because it is too large Load diff

2457
en-US/14_security.xml Normal file
View file

File diff suppressed because it is too large Load diff

1155
en-US/15_debian-packaging.xml Normal file
View file

File diff suppressed because it is too large Load diff

114
en-US/70_conclusion.xml Normal file
View file

@ -0,0 +1,114 @@
<?xml version="1.0"?>
<chapter id="conclusion">
<chapterinfo>
<mediaobject>
<imageobject>
<imagedata fileref="images/chap-conclusion.png" scalefit="1"/>
</imageobject>
</mediaobject>
<keywordset>
<keyword>Future</keyword>
<keyword>Improvements</keyword>
<keyword>Opinions</keyword>
</keywordset>
</chapterinfo>
<title>Conclusion: Debian's Future</title>
<highlights>
<para>The story of Falcot Corp ends with this last chapter; but Debian
lives on, and the future will certainly bring many interesting
surprises.</para>
</highlights>
<section id="sect.upcoming-developments">
<title>Upcoming Developments</title>
<para>Weeks (or months) before a new version of Debian is released, the
Release Manager picks the codename for the next version. Now that
Debian version 6.0 is out, the developers are already busy working on
the next version, codenamed <emphasis
role="distribution">Wheezy</emphasis>…</para>
<para>There's no official list of planned changes, and Debian never
makes promises relating to technical goals of the coming versions.
However, a few development trends can already be noted, and there are
many reasons to believe they will turn into concrete results in the new
version.</para>
<para>The package management system will be able to install packages
for several different architectures on the same system (this is known
as “multi-arch support”). This will allow installing 32 bit
applications on a 64 bit system, and vice-versa. Another project worth
mentioning is <emphasis>Constantly Usable Testing</emphasis>, which
aims at labeling <emphasis role="distribution">Testing</emphasis> as an
officially supported distribution that can be recommended to the
general public. The default “init” process
(<command>sysvinit</command>) may also be replaced by more modern
systems such as <command>upstart</command> or
<command>systemd</command>.</para>
<para>Of course, all the main software suites will have had a major
release. For instance, <emphasis role="distribution">Wheezy</emphasis>
will include a 3.x version of GNOME, which brings a deep and promising
change in the usual graphical desktop paradigm.</para>
</section>
<section id="sect.future-of-debian">
<title>Debian's Future</title>
<para>In addition to these internal developments, one can reasonably
expect new Debian-based distributions to come to light, thanks to the
growing popularity of <emphasis>debian-installer</emphasis> and its
flexibility. New specialized subprojects will also be started, in order
to widen Debian's reach to new horizons.</para>
<para>The Debian user community will increase, and new contributors
will join the project… including, maybe, you!</para>
<para>The Debian project is stronger than ever, and well on its way
towards its goal of an universal distribution; the inside joke within
the Debian community is about <foreignphrase>World
Domination</foreignphrase>.</para>
<para>In spite of its old age and its respectable size, Debian keeps on
growing in all kinds of (sometimes unexpected) directions. Contributors
are teeming with ideas, and discussions on development mailing lists,
even when they look like bickerings, keep increasing the momentum.
Debian is sometimes compared to a black hole, of such density that any
new free software project is attracted.</para>
<para>Beyond the apparent satisfaction of most Debian users, a deep
trend is becoming more and more undisputable: people are increasingly
realising that collaborating, rather than doing business solo, leads to
better results for everyone. Such is the rationale used by
distributions merging into Debian by way of subprojects.</para>
<para>The Debian project is therefore not threatened by
extinction…</para>
</section>
<section id="sect.future-of-this-book">
<title>Future of this Book</title>
<para>We would like this book to evolve in the spirit of free software.
We therefore welcome contributions, remarks, suggestions, and
criticism. Please direct them to Raphaël
(<email>hertzog@debian.org</email>) or Roland
(<email>lolando@debian.org</email>). The website will be used to gather
all information relevant to its evolution. <ulink type="block"
url="http://debian-handbook.info/"/></para>
<para>We tried to integrate most of what our experience at Debian
taught us, so that anyone can use this distribution and take the best
advantage of it as soon as possible. We hope this book contributes to
making Debian less confusing and more popular, and we welcome publicity
around it!</para>
<para>We'd like to conclude on a personal note. Writing (and
translating) this book took a considerable amount of time out of our
usual professional activity. Since we're both freelance consultants,
any new source of income grants us the freedom to spend more time
improving Debian; we hope this book to be successful and to contribute
to this. In the meantime, feel free to retain our services! <ulink
type="block" url="http://www.freexian.com"/><ulink type="block"
url="http://www.gnurandal.com"/></para>
<para>See you soon!</para>
</section>
</chapter>

204
en-US/90_derivative-distributions.xml Normal file
View file

@ -0,0 +1,204 @@
<?xml version="1.0"?>
<appendix id="derivative-distributions">
<appendixinfo>
<mediaobject>
<imageobject>
<imagedata fileref="images/chap-station-travail.png" scalefit="1"/>
</imageobject>
</mediaobject>
<keywordset>
<keyword>Live CD</keyword>
<keyword>Specificities</keyword>
<keyword>Particular Choices</keyword>
</keywordset>
</appendixinfo>
<title>Derivative Distributions</title>
<highlights>
<para><indexterm><primary>derivative distribution</primary></indexterm>
<indexterm><primary>distribution, derivative</primary></indexterm> Many
Linux distributions are derivatives of Debian and reuse Debian's
package management tools. They all have their own interesting
properties, and it is possible one of them will fulfill your needs
better than Debian itself.</para>
</highlights>
<section id="sect.derivative-census">
<title>Census and Cooperation</title>
<para>The Debian project fully acknowledges the importance of
derivative distributions and actively supports collaboration between
all involved parties. This usually involves merging back the
improvements initially developed by derivative distributions so that
everyone can benefit and long-term maintenance work is reduced.</para>
<para>This explains why derivative distributions are invited to become
involved in discussions on the
<literal>debian-derivatives@lists.debian.org</literal> mailing-list,
and to participate in the derivative census. This census aims at
collecting information on work happening in a derivative so that
official Debian maintainers can better track the state of their package
in Debian variants. <ulink type="block"
url="http://wiki.debian.org/DerivativesFrontDesk"/><ulink type="block"
url="http://wiki.debian.org/Derivatives/Census"/></para>
<para>Let us now briefly describe the most interesting and popular
derivative distributions.</para>
</section>
<section id="sect.ubuntu">
<title>Ubuntu</title>
<para><indexterm><primary>Ubuntu</primary></indexterm> Ubuntu made
quite a splash when it came on the Free Software scene, and for good
reason: Canonical Ltd., the company that created this distribution,
started by hiring thirty-odd Debian developers and publicly stating the
far-reaching objective of providing a distribution for the general
public with a new release twice a year. They also committed to
maintaining each version for a year and a half for both core and
security-related components.</para>
<para>These objectives necessarily involve a reduction in scope; Ubuntu
focuses on a smaller number of packages than Debian, and relies
primarily on the GNOME desktop (although an official Ubuntu derivative,
called “Kubuntu”<indexterm><primary>Kubuntu</primary></indexterm>,
relies on KDE). Everything is internationalized and made available in a
great many languages.</para>
<para>So far, Ubuntu has managed to keep this release rhythm. They also
publish <emphasis>Long Term Support</emphasis> (LTS) releases, with a
5-year maintenance promise. As of April 2012, the current LTS version
is version 12.04, nicknamed Precise Pangolin. The latest non-LTS
version is 11.10, nicknamed Oneiric Ocelot. Version numbers describe
the release date: 11.10, for example, was released in October
2011.</para>
<para>Ubuntu has reached a wide audience in the general public.
Millions of users were impressed by its ease of installation, and the
work that went into making the desktop simpler to use.</para>
<para>However, not everything is fine and dandy, especially for Debian
developers who placed great hopes in Ubuntu contributing directly to
Debian. Even though this situation has improved over the years, many
have been irked by the Canonical marketing, which implied Ubuntu were
good citizens in the Free Software world simply because they made
public the changes they applied to Debian packages. Free Software
proponents understand that an automatically-generated patch is of
little use to the upstream contribution process. Getting one's work
integrated requires direct interaction with the other party.</para>
<para>This interaction is becoming more common over time, thanks in
part to the Ubuntu community and the efforts it makes in educating its
new contributors. But this policy is still not enforced by Canonical on
its employees. Some kept true to their roots, and do make the required
effort (Colin Watson, Martin Pitt and Matthias Klose are noteworthy in
this regard), but others — often overworked — can no longer find it
in them. <ulink type="block" url="http://www.ubuntu.com/"/></para>
</section>
<section id="sect.knoppix">
<title>Knoppix</title>
<para><indexterm><primary><foreignphrase>LiveCD</foreignphrase></primary></indexterm>
<indexterm><primary>Knoppix</primary></indexterm>
<indexterm><primary>bootable CD-ROM</primary></indexterm>
<indexterm><primary>CD-ROM</primary><secondary>bootable</secondary></indexterm>
The Knoppix distribution barely needs an introduction. It was the first
popular distribution to provide a <emphasis>LiveCD</emphasis>; in other
words, a bootable CD-ROM that runs a turn-key Linux system with no
requirement for a hard-disk — any system already installed on the
machine will be left untouched. Automatic detection of available
devices allows this distribution to work in most hardware
configurations. The CD-ROM includes almost 2 GB of (compressed)
software.</para>
<para>Combining this CD-ROM and a USB stick allows carrying your files
with you, and to work on any computer without leaving a trace —
remember that the distribution doesn't use the hard-disk at all.
Knoppix is mostly based on LXDE (a lightweight graphical desktop), but
many other distributions provide other combinations of desktops and
software. This is, in part, made possible thanks to the <emphasis
role="pkg">live-build</emphasis> Debian package that makes it
relatively easy to create a LiveCD. <ulink type="block"
url="http://live.debian.net/"/></para>
<para>Note that Knoppix also provides an installer: you can first try
the distribution as a LiveCD, then install it on a hard-disk to get
better performance. <ulink type="block"
url="http://www.knopper.net/knoppix/index-en.html"/></para>
</section>
<section id="sect.linux-mint">
<title>Linux Mint</title>
<para><indexterm><primary>Linux Mint</primary></indexterm> Linux Mint
is a (partly) community-maintained distribution, supported by donations
and advertisements. Their flagship product is based on Ubuntu, but they
also provide a “Linux Mint Debian Edition” variant that evolves
continuously (as it's based on Debian Testing). In both cases, the
initial installation involves booting a LiveDVD.</para>
<para>The distribution aims at simplifying access to advanced
technologies, and provides specific graphical user interfaces on top of
the usual software. For instance, even though Linux Mint relies on
GNOME, it provides a different menu system; similarly, the package
management interface, although based on APT, provides a specific
interface with an evaluation of the risk from each package
update.</para>
<para>Linux Mint includes a large amount of proprietary software so as
to ensure the best possible user experience. For example: Adobe Flash
and multimedia codecs. <ulink type="block"
url="http://www.linuxmint.com/"/></para>
</section>
<section id="sect.simplymepis">
<title>SimplyMEPIS</title>
<para><indexterm><primary>SimplyMEPIS</primary></indexterm> SimplyMEPIS
is a commercial distribution very similar to Knoppix. It provides a
turn-key Linux system from a LiveCD, and includes a number of non-free
software packages: device drivers for nVidia video cards, Flash for
animations embedded in many websites, RealPlayer, Sun's Java, and so
on. The goal is to provide a 100 % working system out of the box.
Mepis is internationalized and handles many languages. <ulink
type="block" url="http://www.mepis.org/"/></para>
<para>This distribution was originally based on Debian; it went to
Ubuntu for a while, then came back to Debian, which allows its
developers to focus on adding features without having to stabilize
packages coming from Debian's <emphasis
role="distribution">Unstable</emphasis> distribution.</para>
</section>
<section id="sect.aptosid">
<title>Aptosid (Formerly Sidux)</title>
<para><indexterm><primary>Sidux</primary></indexterm>
<indexterm><primary>Aptosid</primary></indexterm> This community-based
distribution tracks the changes in Debian <emphasis
role="distribution">Sid</emphasis> (<emphasis
role="distribution">Unstable</emphasis>) — hence its name — and
tries to release 4 new versions each year. The modifications are
limited in scope: the goal is to provide the most recent software and
to update drivers for the most recent hardware, while still allowing
users to switch back to the official Debian distribution at any time.
<ulink type="block" url="http://aptosid.com"/></para>
</section>
<section id="sect.damn-small-linux">
<title>Damn Small Linux</title>
<para>This distribution provides a tiny LiveCD, weighing only 50 MB,
so that it can fit on a CD-ROM with the shape and size of a business
card. This can be useful for using Debian on an aging computer. <ulink
type="block" url="http://www.damnsmalllinux.org/"/></para>
</section>
<section id="sect.other-derivatives">
<title>And Many More</title>
<indexterm><primary>Distrowatch</primary></indexterm>
<para>The Distrowatch website references a huge number of Linux
distributions, many of which are based on Debian. Browsing this site is
a great way to get a sense of the diversity in the Free Software world.
<ulink type="block" url="http://distrowatch.com"/></para>
<para>The search form can help track down a distribution based on its
ancestry. In January 2012, selecting Debian led to 141 active
distributions! <ulink type="block"
url="http://distrowatch.com/search.php"/></para>
</section>
</appendix>

950
en-US/92_short-remedial-course.xml Normal file
View file

@ -0,0 +1,950 @@
<?xml version="1.0"?>
<appendix id="short-remedial-course">
<appendixinfo>
<mediaobject>
<imageobject>
<imagedata fileref="images/chap-rattrapage.png" scalefit="1"/>
</imageobject>
</mediaobject>
<keywordset>
<keyword>BIOS</keyword>
<keyword>Kernel</keyword>
<keyword>Unix</keyword>
<keyword>Process</keyword>
<keyword>Hierarchy</keyword>
<keyword>Basic Commands</keyword>
</keywordset>
</appendixinfo>
<title>Short Remedial Course</title>
<highlights>
<para>Even though this book primarily targets administrators and
“power-users”, we wouldn't like to exclude motivated beginners.
This appendix will therefore be a crash-course describing the
fundamental concepts involved in handling a Unix computer.</para>
</highlights>
<section id="sect.shell-and-basic-commands">
<title>Shell and Basic Commands</title>
<para>In the Unix world, every administrator has to use the command
line sooner or later; for example, when the system fails to start
properly and only provides a command-line rescue mode. Being able to
handle such an interface, therefore, is a basic survival skill for
these circumstances.</para>
<sidebar>
<title><emphasis>QUICK LOOK</emphasis> Starting the command interpreter</title>
<para>A command-line environment can be run from the graphical
desktop, by an application known as a “terminal”, such as those
found under the <menuchoice><guimenu>Applications</guimenu>
<guisubmenu>Accessories</guisubmenu></menuchoice> menu for GNOME, and
in <menuchoice><guimenu>K</guimenu>
<guisubmenu>Applications</guisubmenu>
<guisubmenu>System</guisubmenu></menuchoice> for KDE.</para>
</sidebar>
<para>This section only gives a quick peek at the commands. They all
have many options not described here; accordingly, they also have
abundant documentation in their respective manual pages.</para>
<section>
<title>Browsing the Directory Tree and Managing Files</title>
<para>Once a session is open, the <command>pwd</command> command
(<emphasis>print working directory</emphasis>) displays the current
location in the filesystem. The current directory is changed with the
<command>cd <replaceable>directory</replaceable></command> command
(<command>cd</command> is for <emphasis>change directory</emphasis>).
The parent directory is always called <literal>..</literal> (two
dots), whereas the current directory is also known as
<literal>.</literal> (one dot). The <command>ls</command> command
allows <emphasis>listing</emphasis> the contents of a directory. If
no parameters are given, it operates on the current directory.</para>
<screen>
<computeroutput>$ </computeroutput><userinput>pwd</userinput>
<computeroutput>/home/rhertzog
$ </computeroutput><userinput>cd Desktop</userinput>
<computeroutput>$ </computeroutput><userinput>pwd</userinput>
<computeroutput>/home/rhertzog/Desktop
$ </computeroutput><userinput>cd .</userinput>
<computeroutput>$ </computeroutput><userinput>pwd</userinput>
<computeroutput>/home/rhertzog/Desktop
$ </computeroutput><userinput>cd ..</userinput>
<computeroutput>$ </computeroutput><userinput>pwd</userinput>
<computeroutput>/home/rhertzog
$ </computeroutput><userinput>ls</userinput>
<computeroutput>Desktop Downloads Pictures Templates
Documents Music Public Videos</computeroutput>
</screen>
<para>A new directory can be created with <command>mkdir
<replaceable>directory</replaceable></command>, and an existing
(empty) directory can be removed with <command>rmdir
<replaceable>directory</replaceable></command>. The
<command>mv</command> command allows <emphasis>moving</emphasis>
and/or renaming files and directories; <emphasis>removing</emphasis>
a file involves <command>rm
<replaceable>file</replaceable></command>.</para>
<screen>
<computeroutput>$ </computeroutput><userinput>mkdir test</userinput>
<computeroutput>$ </computeroutput><userinput>ls</userinput>
<computeroutput>Desktop Downloads Pictures Templates Videos
Documents Music Public test
$ </computeroutput><userinput>mv test new</userinput>
<computeroutput>$ </computeroutput><userinput>ls</userinput>
<computeroutput>Desktop Downloads new Public Videos
Documents Music Pictures Templates
$ </computeroutput><userinput>rmdir new</userinput>
<computeroutput>$ </computeroutput><userinput>ls</userinput>
<computeroutput>Desktop Downloads Pictures Templates Videos
Documents Music Public test</computeroutput>
</screen>
</section>
<section>
<title>Displaying and Modifying Text Files</title>
<para>The <command>cat <replaceable>file</replaceable></command>
command (intended to <emphasis>concatenate</emphasis> files on its
standard output) reads a file and displays its contents in the
terminal. If the file is too big to fit on a screen, use a pager such
as <command>less</command> (or <command>more</command>) to display it
page by page.</para>
<para>The <command>editor</command> command always points at a text
editor (such as <command>vi</command> or <command>nano</command>) and
allows creating, modifying and reading text files. The simplest files
can sometimes be created directly from the command interpreter thanks
to redirection: <command>echo "<replaceable>text</replaceable>"
&gt;<replaceable>file</replaceable></command> creates a file named
<replaceable>file</replaceable> with
“<replaceable>text</replaceable>” as its contents. Adding a line
at the end of this file is possible too, with a command such as
<command>echo "<replaceable>line</replaceable>"
&gt;&gt;<replaceable>file</replaceable></command>.</para>
</section>
<section>
<title>Searching for Files and within Files</title>
<para>The <command>find <replaceable>directory</replaceable>
<replaceable>criteria</replaceable></command> command looks for files
in the hierarchy under <replaceable>directory</replaceable> according
to several criteria. The most commonly used criterion is
<literal>-name <replaceable>name</replaceable></literal>: it allows
looking for a file by its name.</para>
<para>The <command>grep <replaceable>expression</replaceable>
<replaceable>files</replaceable></command> command searches the
contents of the files and extracts the lines matching the regular
expression (see sidebar <xref
linkend="encadre.expression-rationnelle"/>). Adding the
<literal>-r</literal> option enables a recursive search on all files
contained in the directory passed as a parameter. This allows looking
for a file when only a part of the contents are known.</para>
</section>
<section>
<title>Managing Processes</title>
<para>The <command>ps aux</command> command lists the processes
currently running and allows identifying them by their
<emphasis>pid</emphasis> (process id). Once the
<emphasis>pid</emphasis> of a process is known, the <command>kill
-<replaceable>signal</replaceable>
<replaceable>pid</replaceable></command> command allows sending it a
signal (if the process belongs to the current user). Several signals
exist; most commonly used are <literal>TERM</literal> (a request to
terminate) and <literal>KILL</literal> (a heavy-handed kill).</para>
<para>The command interpreter can also run programs in the background
if the command ends with “&amp;”. By using the ampersand, the
user resumes control of the shell immediately even though the command
is still running (hidden from the user; as a background process). The
<command>jobs</command> command lists the processes running in the
background; running <command>fg
%<replaceable>job-number</replaceable></command> (for
<emphasis>foreground</emphasis>) restores a job to the foreground.
When a command is running in the foreground (either because it was
started normally, or brought back to the foreground with
<command>fg</command>), the <keycombo
action="simul"><keycap>Control</keycap><keycap>Z</keycap></keycombo>
key pair pauses the process and resumes control of the command-line.
The process can then be restarted in the background with <command>bg
%<replaceable>job-number</replaceable></command> (for
<foreignphrase>background</foreignphrase>).</para>
</section>
<section>
<title>System Information: Memory, Disk Space, Identity</title>
<para>The <command>free</command> command displays information on
memory; <command>df</command> (<emphasis>disk free</emphasis>)
reports on the available disk space on each of the disks mounted in
the filesystem. Its <literal>-h</literal> option (for <emphasis>human
readable</emphasis>) converts the sizes into a more legible unit
(usually megabytes or gigabytes). In a similar fashion, the
<command>free</command> command understands the <literal>-m</literal>
and <literal>-g</literal> options, and displays its data either in
megabytes or in gigabytes, respectively.</para>
<screen>
<computeroutput>$ </computeroutput><userinput>free</userinput>
<computeroutput> total used free shared buffers cached
Mem: 1028420 1009624 18796 0 47404 391804
-/+ buffers/cache: 570416 458004
Swap: 2771172 404588 2366584
$ </computeroutput><userinput>df</userinput>
<computeroutput>Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 9614084 4737916 4387796 52% /
tmpfs 514208 0 514208 0% /lib/init/rw
udev 10240 100 10140 1% /dev
tmpfs 514208 269136 245072 53% /dev/shm
/dev/sda5 44552904 36315896 7784380 83% /home
</computeroutput>
</screen>
<para>The <command>id</command> command displays the identity of the
user running the session, along with the list of groups they belong
to. Since access to some files or devices may be limited to group
members, checking available group membership may be useful.</para>
<screen>
<computeroutput>$ </computeroutput><userinput>id</userinput>
<computeroutput>uid=1000(rhertzog) gid=1000(rhertzog) groups=1000(rhertzog),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),109(bluetooth),115(scanner)</computeroutput>
</screen>
</section>
</section>
<section id="sect.filesystem-hierarchy">
<title>Organization of the Filesystem Hierarchy</title>
<indexterm><primary>Filesystem Hierarchy</primary></indexterm>
<section>
<title>The Root Directory</title>
<para>A Debian system is organized along the <emphasis>File Hierarchy
Standard</emphasis> (FHS). This standard defines the purpose of each
directory. For instance, the top-level directories are described as
follows:</para>
<itemizedlist>
<listitem>
<para><filename>/bin/</filename>: basic programs;</para>
</listitem>
<listitem>
<para><filename>/boot/</filename>: Linux kernel and other files
required for its early boot process;</para>
</listitem>
<listitem>
<para><filename>/dev/</filename>: device files;</para>
</listitem>
<listitem>
<para><filename>/etc/</filename>: configuration files;</para>
</listitem>
<listitem>
<para><filename>/home/</filename>: user's personal files;</para>
</listitem>
<listitem>
<para><filename>/lib/</filename>: basic libraries;</para>
</listitem>
<listitem>
<para><filename>/media/*</filename>: mount points for removable
devices (CD-ROM, USB keys and so on);</para>
</listitem>
<listitem>
<para><filename>/mnt/</filename>: temporary mount point;</para>
</listitem>
<listitem>
<para><filename>/opt/</filename>: extra applications provided by
third parties;</para>
</listitem>
<listitem>
<para><filename>/root/</filename>: administrator's (root's)
personal files;</para>
</listitem>
<listitem>
<para><filename>/sbin/</filename>: system programs;</para>
</listitem>
<listitem>
<para><filename>/srv/</filename>: data used by servers hosted on
this system;</para>
</listitem>
<listitem>
<para><filename>/tmp/</filename>: temporary files; this directory
is often emptied at boot;</para>
</listitem>
<listitem>
<para><filename>/usr/</filename>: applications; this directory is
further subdivided into <filename>bin</filename>,
<filename>sbin</filename>, <filename>lib</filename> (according to
the same logic as in the root directory). Furthermore,
<filename>/usr/share/</filename> contains
architecture-independent data. <filename>/usr/local/</filename>
is meant to be used by the administrator for installing
applications manually without overwriting files handled by the
packaging system (<command>dpkg</command>).</para>
</listitem>
<listitem>
<para><filename>/var/</filename>: variable data handled by
daemons. This includes log files, queues, spools, caches and so
on.</para>
</listitem>
<listitem>
<para><filename>/proc/</filename> and <filename>/sys/</filename>
are specific to the Linux kernel (and not part of the FHS). They
are used by the kernel for exporting data to user-space.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>The User's Home Directory</title>
<para>The contents of a user's home directory is not standardized,
but there are still a few noteworthy conventions. One is that a
user's home directory is often referred to by a tilde (“~”). That
is useful to know because command interpreters automatically replace
a tilde with the correct directory (usually
<filename>/home/<replaceable>user</replaceable>/</filename>).</para>
<para>Application configuration files are often stored directly under
the user's home directory, but their names usually start with a dot
(for instance, the <command>mutt</command> email client stores its
configuration in <filename>~/.muttrc</filename>). Filenames that
start with a dot are hidden by default, and <command>ls</command>
only lists them when the <literal>-a</literal> option is used.</para>
<para>Some programs use multiple configuration files organized in one
directory (for instance, <filename>~/.evolution/</filename>). Some
applications (such as the Iceweasel web browser) also use their
directory to store a cache of downloaded data. This means that those
directories can end up using a lot of disk space.</para>
<para>Graphical desktops usually display the contents of the
<filename>~/Desktop/</filename> directory (or
<filename>~/Bureau/</filename> or whatever the appropriate
translation is for systems not configured in English) on the desktop
(ie, what's visible on screen once all applications are closed or
iconized).</para>
<para>Finally, the email system sometimes stores incoming emails into
a <filename>~/Mail/</filename> directory.</para>
</section>
</section>
<section id="sect.computer-layers">
<title>Inner Workings of a Computer: the Different Layers Involved</title>
<para>A computer is often considered as something rather abstract, and
the externally visible interface is much simpler than its internal
complexity. Such complexity comes in part from the number of pieces
involved. However, these pieces can be viewed in layers, where a layer
only interacts with those immediately above or below.</para>
<para>An end-user can get by without knowing these details… as long
as everything works. When confronting a problem such as, “The
internet doesn't work!”, the first thing to do is to identify in
which layer the problem originates. Is the network card (hardware)
working? Is it recognized by the computer? Does the Linux kernel see
it? Are the network parameters properly configured? All these questions
isolate an appropriate layer and focus on a potential source of the
problem.</para>
<section id="section.materiel">
<title>The Deepest Layer: the Hardware</title>
<indexterm><primary>IDE</primary></indexterm>
<indexterm><primary>SCSI</primary></indexterm>
<indexterm><primary>Serial ATA</primary></indexterm>
<indexterm><primary>Parallel ATA</primary></indexterm>
<indexterm><primary>ATA</primary></indexterm>
<indexterm><primary>IEEE 1394</primary></indexterm>
<indexterm><primary>Firewire</primary></indexterm>
<indexterm><primary>USB</primary></indexterm>
<para>Let us start with a basic reminder that a computer is, first
and foremost, a set of hardware elements. There is generally a main
board, with one (or more) processor(s), some RAM, device controllers,
and extension slots for option boards (for other device controllers).
Most noteworthy among these controllers are IDE (Parallel ATA), SCSI
and Serial ATA, for connecting to storage devices such as hard disks.
Other controllers include USB, which is able to host a great variety
of devices (ranging from webcams to thermometers, from keyboards to
home automation systems) and IEEE_1394 (Firewire). These controllers
often allow connecting several devices so the complete subsystem
handled by a controller is therefore usually known as a “bus”.
Option boards include graphics cards (where monitor screens will be
plugged in to), sound cards, network interface cards, and so on. Some
main boards are pre-built with these features, and don't need option
boards.</para>
<sidebar>
<title><emphasis>IN PRACTICE</emphasis> Checking that the hardware works</title>
<para>Checking that a piece of hardware works can be tricky. On the
other hand, proving that it doesn't work is sometimes quite
simple.</para>
<para>A hard disk drive is made of spinning platters and moving
magnetic heads. When a hard disk is powered up, the platter motor
makes a characteristic whir. It also dissipates energy as heat.
Consequently, a hard disk drive that stays cold and silent when
powered up is broken.</para>
<para>Network cards often include LEDs displaying the state of the
link. If a cable is plugged in and leads to a working network hub
or switch, at least one LED will be on. If no LEDs lights, either
the card itself, the network device, or the cable between them, is
faulty. The next step is therefore testing each component
individually.</para>
<para>Some option boards — especially 3D video cards — include
cooling devices, such as heat sinks and/or fans. If the fan does
not spin even though the card is powered up, a plausible
explanation is the card overheated. This also applies to the main
processor(s) located on the main board.</para>
</sidebar>
</section>
<section id="section.bios">
<title>The Starter: the BIOS</title>
<indexterm><primary>BIOS</primary></indexterm>
<para>Hardware, on its own, is unable to perform useful tasks without
a corresponding piece of software driving it. Controlling and
interacting with the hardware is the purpose of the operating system
and applications. These, in turn, require functional hardware to
run.</para>
<para>This symbiosis between hardware and software does not happen on
its own. When the computer is first powered up, some initial setup is
required. This role is assumed by the BIOS, a tiny piece of software
embedded into the main board that runs automatically upon power-up.
Its primary task is searching for software it can hand over control
to. Usually, this involves looking for the first hard disk with a
boot sector (also known as the <emphasis>master boot
record</emphasis> or <acronym>MBR</acronym>), loading that boot
sector, and running it. From then on, the BIOS is usually not
involved (until the next boot).</para>
<sidebar>
<title><emphasis>TOOL</emphasis> Setup, the BIOS configuration tool</title>
<indexterm><primary><emphasis>Setup</emphasis></primary></indexterm>
<para>The BIOS also contains a piece of software called Setup,
designed to allow configuring aspects of the computer. In
particular, it allows choosing which boot device is preferred (for
instance, the floppy disk or CD-ROM drive), setting the system
clock, and so on. Starting Setup usually involves pressing a key
very soon after the computer is powered on. This key is often
<keycap>Del</keycap> or <keycap>Esc</keycap>, sometimes
<keycap>F2</keycap> or <keycap>F10</keycap>. Most of the time, the
choice is flashed on screen while booting.</para>
</sidebar>
<para>The boot sector, in turn, contains another tiny piece of
software, called the bootloader, whose purpose is to find and run an
operating system. Since this bootloader is not embedded in the main
board but loaded from disk, it can be smarter than the BIOS, which
explains why the BIOS does not load the operating system by itself.
For instance, the bootloader (often GRUB on Linux systems) can list
the available operating systems and ask the user to choose one.
Usually, a time-out and default choice is provided. Sometimes the
user can also choose to add parameters to pass to the kernel, and so
on. Eventually, a kernel is found, loaded into memory, and
executed.</para>
<para>The BIOS is also in charge of detecting and initializing a
number of devices. Obviously, this includes the IDE/SATA devices
(usually hard disk(s) and CD/DVD-ROM drives), but also PCI devices.
Detected devices are often listed on screen during the boot process.
If this list goes by too fast, use the <keycap>Pause</keycap> key to
freeze it for long enough to read. Installed PCI devices that don't
appear, are a bad omen. At worst, the device is faulty. At best, it
is merely incompatible with the current version of the BIOS or main
board. PCI specifications evolve, and old main boards are not
guaranteed to handle newer PCI devices.</para>
</section>
<section id="section.noyau">
<title>The Kernel</title>
<para>Both the BIOS and the bootloader only run for a few seconds
each; now we're getting to the first piece of software that runs for
a longer time, the operating system kernel. This kernel assumes the
role of a conductor in an orchestra, and ensures coordination between
hardware and software. This role involves several tasks including:
driving hardware, managing processes, users and permissions, the
filesystem, and so on. The kernel provides a common base to all other
programs on the system.</para>
</section>
<section id="section.userspace-presentation">
<title>The User Space</title>
<para>Although everything that happens outside of the kernel can be
lumped together under “user-space”, we can still separate it into
software layers. However, their interactions are more complex than
before, and the classifications may not be as simple. An application
commonly uses libraries, which in turn involve the kernel, but the
communications can also involve other programs, or even many
libraries calling each other.</para>
</section>
</section>
<section id="sect.kernel-role-and-tasks">
<title>Some Tasks Handled by the Kernel</title>
<section id="section.pilotage-materiel">
<title>Driving the Hardware</title>
<para>The kernel is, first and foremost, tasked with controlling the
hardware parts, detecting them, switching them on when the computer
is powered on, and so on. It also makes them available to
higher-level software with a simplified programming interface, so
applications can take advantage of devices without having to worry
about details such as which extension slot the option board is
plugged into. The programming interface also provides an abstraction
layer; this allows video-conferencing software, for example, to use a
webcam independently of its make and model. The software can just use
the <emphasis>Video for Linux</emphasis> (V4L) interface, and the
kernel translates the function calls of this interface into the
actual hardware commands needed by the specific webcam in use.</para>
<para><indexterm><primary><command>lspci</command></primary></indexterm>
<indexterm><primary><command>lsusb</command></primary></indexterm>
<indexterm><primary><command>lsdev</command></primary></indexterm>
<indexterm><primary><command>lspcmcia</command></primary></indexterm>
The kernel exports many details about detected hardware through the
<filename>/proc/</filename> and <filename>/sys/</filename> virtual
filesystems. Several tools summarize those details. Among them,
<command>lspci</command> (in the <emphasis
role="pkg">pciutils</emphasis> package) lists PCI devices,
<command>lsusb</command> (in the <emphasis
role="pkg">usbutils</emphasis> package) lists USB devices, and
<command>lspcmcia</command> (in the <emphasis
role="pkg">pcmciautils</emphasis> package) lists PCMCIA cards. These
tools are very useful for identifying the exact model of a device.
This identification also allows more precise searches on the web,
which in turn, lead to more relevant documents.</para>
<example>
<title>Example of information provided by <command>lspci</command> and <command>lsusb</command></title>
<screen>
<computeroutput>$ </computeroutput><userinput>lspci</userinput>
<computeroutput>[...]
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)
[...]
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
02:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)
$ </computeroutput><userinput>lsusb</userinput>
<computeroutput>Bus 005 Device 004: ID 413c:a005 Dell Computer Corp.
Bus 005 Device 008: ID 413c:9001 Dell Computer Corp.
Bus 005 Device 007: ID 045e:00dd Microsoft Corp.
Bus 005 Device 006: ID 046d:c03d Logitech, Inc.
[...]
Bus 002 Device 004: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth
</computeroutput>
</screen>
</example>
<para>These programs have a <literal>-v</literal> option, that lists
much more detailed (but usually not necessary) information. Finally,
the <command>lsdev</command> command (in the <emphasis
role="pkg">procinfo</emphasis> package) lists communication resources
used by devices.</para>
<para>Applications often access devices by way of special files
created within <filename>/dev/</filename> (see the sidebar <xref
linkend="cadre.fichiers-speciaux"/>). These are special files that
represent disk drives (for instance, <filename>/dev/hda</filename>
and <filename>/dev/sdc</filename>), partitions
(<filename>/dev/hda1</filename> or <filename>/dev/sdc3</filename>),
mice (<filename>/dev/input/mouse0</filename>), keyboards
(<filename>/dev/input/event0</filename>), soundcards
(<filename>/dev/snd/*</filename>), serial ports
(<filename>/dev/ttyS*</filename>), and so on.</para>
</section>
<section id="section.systemes-fichiers">
<title>Filesystems</title>
<indexterm><primary>filesystem</primary></indexterm>
<indexterm><primary>system, filesystem</primary></indexterm>
<para>Filesystems are one of the most prominent aspects of the
kernel. Unix systems merge all the file storages into a single
hierarchy, which allows users (and applications) to access data
simply by knowing its location within that hierarchy.</para>
<para>The starting point of this hierarchical tree is called the
root, <filename>/</filename>. This directory can contain named
subdirectories. For instance, the <literal>home</literal>
subdirectory of <filename>/</filename> is called
<filename>/home/</filename>. This subdirectory can, in turn, contain
other subdirectories, and so on. Each directory can also contain
files, where the actual data will be stored. Thus, the
<filename>/home/rmas/Desktop/hello.txt</filename> name refers to a
file named <literal>hello.txt</literal> stored in the
<literal>Desktop</literal> subdirectory of the
<literal>rmas</literal> subdirectory of the <literal>home</literal>
directory present in the root. The kernel translates between this
naming system and the actual, physical storage on a disk.</para>
<para>Unlike other systems, there's only one such hierarchy, and it
can integrate data from several disks. One of these disks is used as
the root, and the others are “mounted” on directories in the
hierarchy (the Unix command is called <command>mount</command>);
these other disks are then available under these “mount points”.
This allows storing users' home directories (traditionally stored
within <filename>/home/</filename>) on a second hard disk, which will
contain <literal>rhertzog</literal> and <literal>rmas</literal>
directories. Once the disk is mounted on <filename>/home/</filename>,
these directories become accessible at their usual locations, and
paths such as <filename>/home/rmas/Desktop/hello.txt</filename> keep
working.</para>
<indexterm><primary><command>mkfs</command></primary></indexterm>
<para>There are many filesystems, corresponding to many ways of
physically storing data on disks. The most widely known are
<emphasis>ext2</emphasis>, <emphasis>ext3</emphasis> and
<emphasis>ext4</emphasis>, but others exist. For instance,
<emphasis>vfat</emphasis> is the system that was historically used by
DOS and Windows operating systems, which allows using hard disks
under Debian as well as under Windows. In any case, a filesystem must
be prepared on a disk before it can be mounted and this operation is
known as “formatting”. Commands such as
<command>mkfs.ext3</command> (where <command>mkfs</command> stands
for <emphasis>MaKe FileSystem</emphasis>) handle formatting. These
commands require, as a parameter, a device file representing the
partition to be formatted (for instance,
<filename>/dev/sda1</filename>). This operation is destructive and
should only be run once, except if one deliberately wishes to wipe a
filesystem and start afresh.</para>
<para>There are even network filesystems, such as
<acronym>NFS</acronym>, where data is not stored on a local disk.
Instead, data is transmitted through the network to a server that
stores and retrieves them on demand. The filesystem abstraction
shields users from having to care: files remain accessible in their
usual hierarchical way.</para>
</section>
<section id="section.fonctions-partagees">
<title>Shared Functions</title>
<para>Since a number of the same functions are used by all software,
it makes sense to centralize them in the kernel. For instance, shared
filesystem handling allow any application to simply open a file by
name, without needing to worry where the file is stored physically.
The file can be stored in several different slices on a hard disk, or
split across several hard disks, or even stored on a remote file
server. Shared communication functions, are used by applications to
exchange data independently of the way the data is transported. For
instance, transport could be over any combination of local or
wireless networks, or over a telephone landline.</para>
</section>
<section id="section.gestion-processus">
<title>Managing Processes</title>
<indexterm><primary><emphasis>pid</emphasis></primary></indexterm>
<para>A process is a running instance of a program. This requires
memory to store both the program itself and its operating data. The
kernel is in charge of creating and tracking them. When a program
runs, first the kernel sets aside memory, then loads the executable
code from the filesystem into it, and then starts the code running.
It keeps information about this process, the most visible of which,
is an identification number known as <emphasis>pid</emphasis>
(<emphasis>process identifier</emphasis>).</para>
<para>Unix-like kernels (including Linux), and like most other modern
operating systems, are able of “multi-tasking”. In other words,
they allow running many processes “at the same time”. There's
actually only one running process at any one time, but the kernel
cuts time into small slices and runs each process in turn. Since
these time slices are very short (in the millisecond range), they
create the illusion of processes running in parallel, although
they're actually only active during some time intervals and idle the
rest of the time. The kernel's job is to adjust its scheduling
mechanisms to keep that illusion, while maximizing the global system
performance. If the time slices are too long, the application may
lack in snappiness and user interactivity. Too short, and the system
loses time switching tasks too frequently. These decisions can be
tweaked with process priorities. High-priority processes will run for
longer and more frequent time slices than low-priority
processes.</para>
<sidebar>
<title><emphasis>NOTE</emphasis> Multi-processor systems (and variants)</title>
<para>The restriction described here is only a corner case. The
actual restriction is that there can only be one running process
<emphasis>per processor core</emphasis> at a time. Multi-processor,
multi-core or “hyper-threaded” systems allow several processes
to run in parallel. The same time-slicing system is still used,
though, so as to handle cases where there are more active processes
than available processor cores. This is the usual case: a basic
system, even a mostly idle one, almost always has tens of running
processes.</para>
</sidebar>
<para>Of course, the kernel allows running several independent
instances of the same program. But each can only access its own time
slices and memory. Their data thus remain independent.</para>
</section>
<section id="section.permissions">
<title>Rights Management</title>
<para>Unix-like systems are also multi-user. They provide a rights
management system that allows separate groups and users, and for
choosing to permit or block actions based on permissions. The kernel
manages, for each process, data allowing permission checking. Most of
the time, this means the process' “identity” is the same as the
user that started it. And, the process is only able to take user
permitted actions. For instance, trying to open a file requires the
kernel to check the process identity against access permissions (for
more details on this particular example, see <xref
linkend="sect.rights-management"/>).</para>
</section>
</section>
<section id="sect.user-space">
<title>The User Space</title>
<indexterm><primary>user space</primary></indexterm>
<indexterm><primary>kernel space</primary></indexterm>
<para>“User-space” refers to the runtime environment of normal (as
opposed to kernel) processes. This does not necessarily mean these
processes are actually started by users because a standard system
routinely has several “daemon” processes running before the user
even opens a session. Daemon processes are user-space processes.</para>
<section id="section.rappels-processus">
<title>Process</title>
<indexterm><primary><command>init</command></primary></indexterm>
<para>When the kernel gets past its initialization phase, it starts
the very first process, <command>init</command>. Process #1 alone is
very rarely useful by itself, and Unix-like systems run with a whole
lifecycle of processes.</para>
<indexterm><primary><emphasis>fork</emphasis></primary></indexterm>
<para>First of all, a process can clone itself (this is known as a
<emphasis>fork</emphasis>). The kernel allocates a new, but
identical, process memory space, and another process to use it. At
this point in time, the only difference between these two processes
is their <emphasis>pid</emphasis>. The new process is customarily
called a child process, and the process whose
<emphasis>pid</emphasis> doesn't change, is called the parent
process.</para>
<para>Sometimes, the child process continues to lead its own life
independently from its parent, with its own data copied from the the
parent process. In many cases, though, this child process executes
another program. With a few exceptions, its memory is simply replaced
by that of the new program, and execution of this new program begins.
One of the very first actions of process number 1 thus is to
duplicate itself (which means there are, for a tiny amount of time,
two running copies of the same <command>init</command> process), but
the child process is then replaced by the first system initialization
script, usually <filename>/etc/init.d/rcS</filename>. This script, in
turn, clones itself and runs several other programs. At some point,
one process among <command>init</command>'s offspring starts a
graphical interface for users to log in to (the actual sequence of
events is described in more details in <xref
linkend="sect.system-boot"/>).</para>
<para>When a process finishes the task for which it was started, it
terminates. The kernel then recovers the memory assigned to this
process, and stops giving it slices of running time. The parent
process is told about its child process being terminated, which
allows a process to wait for the completion of a task it delegated to
a child process. This behaviour is plainly visible in command-line
interpreters (known as <emphasis>shells</emphasis>). When a command
is typed into a shell, the prompt only comes back when the execution
of the command is over. Most shells allow for running the command in
the background, it is a simple matter of adding an
<userinput>&amp;</userinput> to the end of the command. The prompt is
displayed again right away, which can lead to problems if the command
needs to display data of its own.</para>
</section>
<section id="section.daemons">
<title>Daemons</title>
<indexterm><primary>daemon</primary></indexterm>
<indexterm><primary>daemon</primary></indexterm>
<para>A “daemon” is a process started automatically by the boot
sequence. It keeps running (in the background) to perform maintenance
tasks or provide services to other processes. This “background
task” is actually arbitrary, and does not match anything particular
from the system's point of view. They are simply processes, quite
similar to other processes, which run in turn when their time slice
comes. The distinction is only in the human language: a process that
runs with no interaction with a user (in particular, without any
graphical interface) is said to be running “in the background” or
“as a daemon”.</para>
<sidebar>
<title><emphasis>VOCABULARY</emphasis> Daemon, demon, a derogatory term?</title>
<para>Although <emphasis>daemon</emphasis> term shares its Greek
etymology with <emphasis>demon</emphasis>, the former does not
imply diabolical evil, instead, it should be understood as a
kind-of helper spirit. This distinction is subtle enough in
English, but it's even worse in other languages where the same word
is used for both meanings.</para>
</sidebar>
<para>Several such daemons are described in detail in <xref
linkend="unix-services"/>.</para>
</section>
<section id="section.ipc">
<title>Inter-Process Communications</title>
<indexterm><primary>IPC</primary></indexterm>
<indexterm><primary>Inter-Process Communications</primary></indexterm>
<para>An isolated process, whether a daemon or an interactive
application, is rarely useful on its own, which is why there are
several methods allowing separate processes to communicate together,
either to exchange data or to control one another. The generic term
referring to this is <emphasis>inter-process
communication</emphasis>, or IPC for short.</para>
<para>The simplest IPC system is to use files. The process that
wishes to send data writes it into a file (with a name known in
advance), while the recipient only has to open the file and read its
contents.</para>
<indexterm><primary><emphasis>pipe</emphasis></primary></indexterm>
<indexterm><primary><emphasis>pipe</emphasis></primary></indexterm>
<para>In the case where one does not wish to store data on disk, one
can use a <emphasis>pipe</emphasis>, which is simply an object with
two ends; bytes written in one end, are readable at the other. If the
ends are controlled by separate processes, this leads to a simple and
convenient inter-process communication channel. Pipes can be
classified into two categories: named pipes, and anonymous pipes. A
named pipe is represented by an entry on the filesystem (although the
transmitted data is not stored there), so both processes can open it
independently if the location of the named pipe is known beforehand.
In cases where the communicating processes are related (for instance,
a parent and its child process), the parent process can also create
an anonymous pipe before forking, and the child inherits it. Both
processes will then be able to exchange data through the pipe without
needing the filesystem.</para>
<sidebar>
<title><emphasis>IN PRACTICE</emphasis> A concrete example</title>
<para>Let's describe in some detail what happens when a complex
command (a <emphasis>pipeline</emphasis>) is run from a shell. We
assume we have a <command>bash</command> process (the standard user
shell on Debian), with <emphasis>pid</emphasis> 4374; into this
shell, we type the command: <command>ls | sort</command> .</para>
<para>The shell first interprets the command typed in. In our case,
it understands there are two programs (<command>ls</command> and
<command>sort</command>), with a data stream flowing from one to
the other (denoted by the <userinput>|</userinput> character, known
as <emphasis>pipe</emphasis>). <command>bash</command> first
creates an unnamed pipe (which initially exists only within the
<command>bash</command> process itself).</para>
<para>Then the shell clones itself; this leads to a new
<command>bash</command> process, with
<emphasis>pid</emphasis> #4521 (<emphasis>pids</emphasis> are
abstract numbers, and generally have no particular meaning).
Process #4521 inherits the pipe, which means it is able to write in
its “input” side; <command>bash</command> redirects its
standard output stream to this pipe's input. Then it executes (and
replaces itself with) the <command>ls</command> program, which
lists the contents of the current directory. Since
<command>ls</command> writes on its standard output, and this
output has previously been redirected, the results are effectively
sent into the pipe.</para>
<para>A similar operation happens for the second command:
<command>bash</command> clones itself again, leading to a new
<command>bash</command> process with pid #4522. Since it is also a
child process of #4374, it also inherits the pipe;
<command>bash</command> then connects its standard input to the
pipe output, then executes (and replaces itself with) the
<command>sort</command> command, which sorts its input and displays
the results.</para>
<para>All the pieces of the puzzle are now set up:
<command>ls</command> writes the list of files in the current
directory into the pipe; <command>sort</command> reads this list,
sorts it alphabetically, and displays the results. Processes
numbers #4521 and #4522 then terminate, and #4374 (which was
waiting for them during the operation), resumes control and
displays the prompt to allow the user to type in a new
command.</para>
</sidebar>
<para>Not all inter-process communications are used to move data
around though. In many situations, the only information that needs to
be transmitted are control messages such as “pause execution” or
“resume execution”. Unix (and Linux) provides a mechanism known
as <emphasis>signals</emphasis>, through which a process can simply
send a signal (chosen within a fixed list of a few tens of predefined
signals) to another process. The only requirement is to know the
<emphasis>pid</emphasis> of the target.</para>
<para>For more complex communications, there are also mechanisms
allowing a process to open access, or share, part of its allocated
memory to other processes. Memory then shared between them, allows
moving data across.</para>
<para>Finally, network connections can also help processes
communicate; these processes can even be running on different
computers, possibly thousands of kilometers apart.</para>
<para>It is quite standard for a typical Unix-like system to make use
of all these mechanisms to various degrees.</para>
</section>
<section id="section.bibliotheques">
<title>Libraries</title>
<indexterm><primary>library (of functions)</primary></indexterm>
<para>Function libraries play a crucial role in a Unix-like operating
system. They are not proper programs, since they cannot be executed
on their own, but collections of code fragments that can be used by
standard programs. Among the common libraries, the most noteworthy
include:</para>
<itemizedlist>
<listitem>
<para>the standard C library (<emphasis>glibc</emphasis>), which
contains basic functions such as ones to open files or network
connections, and others facilitating interactions with the
kernel;</para>
</listitem>
<listitem>
<para>graphical toolkits, Gtk+ and Qt, allowing many programs to
reuse the graphical objects they provide;</para>
</listitem>
<listitem>
<para>the <emphasis>libpng</emphasis> library, that allows
loading, interpreting and saving images in the PNG format.</para>
</listitem>
</itemizedlist>
<para>Thanks to those libraries, applications can reuse existing
code. Their development is thus correspondingly simplified, in
particular when many applications reuse the same functions. Since
libraries are often developed by different persons, the global
development of the system is closer to Unix's historical
philosophy.</para>
<sidebar>
<title><emphasis>CULTURE</emphasis> The Unix Way: one thing at a time</title>
<para>One of the fundamental concepts that underlies the Unix
family of operating systems is that each tool should only do one
thing, and do it well; applications can then reuse these tools to
build more advanced logic on top. This Way can be seen in many
incarnations. Shell scripts may be the best example: they assemple
complex sequences of very simple tools (such as
<command>grep</command>, <command>wc</command>,
<command>sort</command>, <command>uniq</command> and so on).
Another implementation of this philosophy can be seen in code
libraries: the <emphasis>libpng</emphasis> library allows reading
and writing PNG images, with different options and in different
ways, but it does only that; no question of including functions
that display or edit images.</para>
</sidebar>
<para>Moreover, these libraries are often referred to as “shared
libraries”, since the kernel is able to only load them into memory
once, even if several processes use the same library at the same
time. This allows saving memory, when compared with the opposite
(hypothetical) situation where the code for a library would be loaded
as many times as there are processes using it.</para>
</section>
</section>
</appendix>

13
en-US/Author_Group.xml Normal file
View file

@ -0,0 +1,13 @@
<?xml version="1.0"?>
<authorgroup>
<author>
<firstname>Raphaël</firstname>
<surname>Hertzog</surname>
<email>hertzog@debian.org</email>
</author>
<author>
<firstname>Roland</firstname>
<surname>Mas</surname>
<email>lolando@debian.org</email>
</author>
</authorgroup>

89
en-US/Book_Info.xml Normal file
View file

@ -0,0 +1,89 @@
<?xml version="1.0"?>
<bookinfo id="book-cahier-admin-debian-cahier_admin_debian">
<title>The Debian Administrator's Handbook</title>
<subtitle>Debian Squeeze from Discovery to Mastery</subtitle>
<productname>Debian</productname>
<productnumber>6.0</productnumber>
<edition>1</edition>
<pubsnumber>0</pubsnumber>
<abstract>
<para>A reference book presenting the Debian distribution, from initial
installation to configuration of services.</para>
</abstract>
<legalnotice condition="librement" lang="en-US">
<para>ISBN: 979-10-91414-00-5 (paperback)</para>
<para>ISBN: 979-10-91414-01-2 (ebook)</para>
<para>This book is available under the terms of two licenses compatible
with the Debian Free Software Guidelines.</para>
<formalpara>
<title>Creative Commons License Notice:</title>
<para>This book is licensed under a Creative Commons
Attribution-ShareAlike 3.0 Unported License. <ulink type="block"
url="http://creativecommons.org/licenses/by-sa/3.0/"/></para>
</formalpara>
<formalpara>
<title>GNU General Public License Notice:</title>
<para>This book is free documentation: you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 2 of the
License, or (at your option) any later version.</para>
</formalpara>
<para>This book is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.</para>
<para>You should have received a copy of the GNU General Public License
along with this program. If not, see <ulink
url="http://www.gnu.org/licenses/"/>.</para>
<important>
<title>Show your appreciation</title>
<para>This book is published under a free license because we want
everybody to benefit from it. That said maintaining it takes time and
lots of efforts, and we appreciate being thanked for this. If you
find this book valuable, please consider contributing to its
continued maintenance either by buying a paperback copy or by making
a donation through the book's official website: <ulink type="block"
url="http://debian-handbook.info"/></para>
</important>
</legalnotice>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="Author_Group.xml"/>
<copyright>
<year>2003</year>
<year>2004</year>
<year>2005</year>
<year>2006</year>
<year>2007</year>
<year>2008</year>
<year>2009</year>
<year>2010</year>
<year>2011</year>
<year>2012</year>
<holder>Raphaël Hertzog</holder>
</copyright>
<copyright>
<year>2006</year>
<year>2007</year>
<year>2008</year>
<year>2009</year>
<year>2010</year>
<year>2011</year>
<year>2012</year>
<holder>Roland Mas</holder>
</copyright>
<copyright condition="librement">
<year>2012</year>
<holder>Freexian SARL</holder>
</copyright>
<mediaobject lang="en-US" role="cover">
<imageobject>
<imagedata fileref="images/cover.png"/>
</imageobject>
</mediaobject>
</bookinfo>

17
en-US/Revision_History.xml Normal file
View file

@ -0,0 +1,17 @@
<?xml version="1.0"?>
<appendix>
<title>Revision History</title>
<simpara>
<revhistory>
<revision>
<revnumber>1.0-1</revnumber>
<date>2012-04-01</date>
<author>
<firstname>Raphaël</firstname>
<surname>Hertzog</surname>
<email>hertzog@debian.org</email>
</author>
</revision>
</revhistory>
</simpara>
</appendix>

24
en-US/debian-handbook.xml Normal file
View file

@ -0,0 +1,24 @@
<?xml version="1.0"?>
<book>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="Book_Info.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="00a_preface.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="00b_foreword.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="01_the-debian-project.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="02_case-study.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="03_existing-setup.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="04_installation.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="05_packaging-system.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="06_apt.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="07_solving-problems.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="08_basic-configuration.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="09_unix-services.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="10_network-infrastructure.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="11_network-services.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="12_advanced-administration.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="13_workstation.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="14_security.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="15_debian-packaging.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="70_conclusion.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="90_derivative-distributions.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="92_short-remedial-course.xml"/>
</book>

17
en-US/images/Makefile Normal file
View file

@ -0,0 +1,17 @@
dia = $(wildcard *.dia)
all: png
png: $(patsubst %.dia,%.png,$(dia))
eps: $(patsubst %.jpg,%.eps,$(wildcard *.jpg)) $(patsubst %.png,%.eps,$(wildcard *.png)) $(patsubst %.dia,%.eps,$(dia))
define DIA_template
$(1).png: $(1).dia
dia -t png -s 1024 $$<
endef
$(foreach d,$(patsubst %.dia,%,$(dia)),$(eval $(call DIA_template,$(d))))
.PHONY: png all

34
en-US/images/apple.xpm Normal file
View file

@ -0,0 +1,34 @@
/* XPM */
static char * apple_xpm[] = {
"28 24 7 1",
" c #ff9ebe",
". c #3c9e3c",
"X c #ffff00",
"o c #ffbe7d",
"O c #ff0000",
"+ c #7d3cbe",
"@ c #0000ff",
" .... ",
" .... ",
" .... ",
" ... ",
" .. . .. ",
" ...... ...... ",
" .................. ",
" .................. ",
" XXXXXXXXXXXXXXXXX ",
" XXXXXXXXXXXXXXXX ",
" XXXXXXXXXXXXXXXX ",
" oooooooooooooooo ",
" oooooooooooooooo ",
" oooooooooooooooo ",
" OOOOOOOOOOOOOOOOO ",
" OOOOOOOOOOOOOOOOO ",
" OOOOOOOOOOOOOOOOOO ",
" +++++++++++++++++ ",
" ++++++++++++++++ ",
" +++++++++++++++ ",
" @@@@@@@@@@@@@@ ",
" @@@@@@@@@@@@ ",
" @@ @@ ",
" "};

BIN
en-US/images/aptitude.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 76 KiB

BIN
en-US/images/autobuilder.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/autobuilder.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 83 KiB

60
en-US/images/bsdcpu.xpm Normal file
View file

@ -0,0 +1,60 @@
/* XPM */
static char * bsdcpu_xpm[] = {
"55 45 11 1",
" c #888888",
". c None",
"X c #cccccc",
"o c #bbbbbb",
"O c #000000",
"+ c #eeeeee",
"@ c #cd5c5c",
"# c #32cd32",
"$ c #999999",
"% c #666666",
"& c #555555",
" ...................",
" XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ...................",
" XooooooooooooooooooooooooooooooooX ...................",
" Xo oX ...................",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ...................",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ...................",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +@@+###+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +@O+##O+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +oooooo+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +oOoooo+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +oOoooo+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +oooooo+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +oOoooo+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +oOoooo+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +$$$$$$+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... +$$$$$$+ ....",
" Xo OOOOOOOOOOOOOOOOOOOOOOOOOOOO oX ..... ++++++++ ....",
" Xo oX ..... +$$$$$$+ ....",
" XooooooooooooooooooooooooooooooooX ..... ++++++++ ....",
" XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ..... ....",
" ..... oooooooo ....",
"... % % % % % % % % % % % % % % %........ oooooooo ....",
"... % % % % % % % % % % % % % % %........ ....",
"......&&%%%%%%%%%%%%%%%%%%%%&&............ .....",
"......&&&&&%%%%%%%%%%%%%%&&&&&.........................",
" ...... .........",
" XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX . ... ... ........",
" Xo+++++++++++++++++++oooXXXXXooooX ... . .....",
" Xoo+++++++++++++++++++ooXXoXX+++oX ....... X X X .....",
" Xoooo+++++++++++++++ooooXoooX+++oX ....... X X X .....",
" X$$$$$$$$$$$$$$$$$$$$$$$X$$$X$$$$X ....... .....",
" XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ....... XXXXX .....",
" oooooooooooooooooooooooooooooooooo ....... XXXXX .....",
" ....... ....."};

BIN
en-US/images/chap-admin-avancee.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 546 KiB

BIN
en-US/images/chap-apt.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 458 KiB

BIN
en-US/images/chap-conclusion.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 1.1 MiB

BIN
en-US/images/chap-config-base.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 964 KiB

BIN
en-US/images/chap-etude-cas.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 1 MiB

BIN
en-US/images/chap-existant.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 782 KiB

BIN
en-US/images/chap-infrastructure.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 969 KiB

BIN
en-US/images/chap-installation.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 746 KiB

BIN
en-US/images/chap-paquetage.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 480 KiB

BIN
en-US/images/chap-plus-loin.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 589 KiB

BIN
en-US/images/chap-pres-debian.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 1.2 MiB

BIN
en-US/images/chap-rattrapage.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 827 KiB

BIN
en-US/images/chap-securite.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 747 KiB

BIN
en-US/images/chap-services-reseau.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 629 KiB

BIN
en-US/images/chap-services-unix.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 634 KiB

BIN
en-US/images/chap-src-info.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.1 MiB

BIN
en-US/images/chap-station-travail-2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 656 KiB

BIN
en-US/images/chap-station-travail.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 660 KiB

BIN
en-US/images/cover.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 797 KiB

BIN
en-US/images/cycle-complet-paquet.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/cycle-complet-paquet.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 196 KiB

BIN
en-US/images/cycle-release.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/cycle-release.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 53 KiB

BIN
en-US/images/debian.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 38 KiB

44
en-US/images/debian.xpm Normal file
View file

@ -0,0 +1,44 @@
/* XPM */
static char * debian_xpm[] = {
"28 24 17 1",
" c None",
". c #BE073B",
"+ c #C43761",
"@ c #D26486",
"# c #DC92A9",
"$ c #E3AEBF",
"% c #E9BFCD",
"& c #EECFDA",
"* c #F4DEE5",
"= c #F6E6ED",
"- c #F7EDF1",
"; c #C12855",
"> c #C63E66",
", c #FEFEFE",
"' c #D37895",
") c #BE1C4A",
"! c #CB5276",
",,,,,,,,,,,,,,,,,,,,,,,,,,,,",
",,,,,,,,,,,%@!'#$-,,,,,,,,,,",
",,,,,,,,,&>......)>$,,,,,,,,",
",,,,,,,,#...!#$$#+..@,,,,,,,",
",,,,,,,#..!%,,,,,,'..',,,,,,",
",,,,,-=))#,,,,,,,,,'..%,,,,,",
",,,,,-@.%,,,,,,,,,,-;+$,,,,,",
",,,,,%.#,,,,,$@'$*,,'.&,,,,,",
",,,,,'.*,,,,$#,,,-,,$.&,,,,,",
",,,,,!!,,,,,',,,,,,,%.%,,,,,",
",,,,,!',,,,*',,,,,-,$)=,,,,,",
",,,,,!#,,,,*!,,,,&-,#!-,,,,,",
",,,,,!#,,,,,+-,-*-,=)%,,,,,,",
",,,,,@!,,,,*#!-,,,&+$,,,,,,,",
",,,,,#;,,,,,&'+'#!>%,,,,,,,,",
",,,,,&.',,,,,-$##*,,,,,,,,,,",
",,,,,,>.*,,,,,,,,,,,,,,,,,,,",
",,,,,,%.#,,,,,,,,,,,,,,,,,,,",
",,,,,,,@;-,,,,,,,,,,,,,,,,,,",
",,,,,,,-+!,,,,,,,,,,,,,,,,,,",
",,,,,,,,-+!-,,,,,,,,,,,,,,,,",
",,,,,,,,,-'!%,,,,,,,,,,,,,,,",
",,,,,,,,,,,&'$%,,,,,,,,,,,,,",
",,,,,,,,,,,,,,,,,,,,,,,,,,,,"};

BIN
en-US/images/demarrage.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/demarrage.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 42 KiB

BIN
en-US/images/developers-map.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 568 KiB

BIN
en-US/images/etude-cas.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/etude-cas.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 87 KiB

BIN
en-US/images/evolution.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 88 KiB

BIN
en-US/images/existant-1.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/existant-1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
en-US/images/existant-2.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/existant-2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
en-US/images/existant-3.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/existant-3.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
en-US/images/existant-4.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/existant-4.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
en-US/images/fwbuilder.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 109 KiB

BIN
en-US/images/gnome-mime-application-x-deb.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 4.1 KiB

BIN
en-US/images/gnome.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 181 KiB

BIN
en-US/images/icedove.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
en-US/images/iceweasel.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 135 KiB

BIN
en-US/images/inst-autopartman-mode.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 38 KiB

BIN
en-US/images/inst-basesystem.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
en-US/images/inst-boot.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
en-US/images/inst-choix-miroir.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 45 KiB

BIN
en-US/images/inst-clavier-txt.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 10 KiB

BIN
en-US/images/inst-clavier.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
en-US/images/inst-gdm1024.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 190 KiB

BIN
en-US/images/inst-lang-txt.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
en-US/images/inst-lang.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 45 KiB

BIN
en-US/images/inst-partman-choix-disque.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 34 KiB

BIN
en-US/images/inst-partman-validation.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
en-US/images/inst-partman.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 39 KiB

BIN
en-US/images/inst-pays-txt.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 9.3 KiB

BIN
en-US/images/inst-pays.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 42 KiB

BIN
en-US/images/inst-rootpw.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
en-US/images/inst-tasksel.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
en-US/images/inst-username.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
en-US/images/kde.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 213 KiB

BIN
en-US/images/kmail.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 266 KiB

BIN
en-US/images/microsoft-windows-logo-2.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
en-US/images/netfilter.dia Normal file
View file

Binary file not shown.

BIN
en-US/images/netfilter.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 17 KiB

36
en-US/images/next.xpm Normal file
View file

@ -0,0 +1,36 @@
/* XPM */
static char * next_xpm[] = {
"28 24 9 1",
" c #c3c3c3",
". c #828282",
"X c #000000",
"o c #ffff9e",
"O c #ffbe5d",
"+ c #ffbe7d",
"@ c #ff0000",
"# c #00ff00",
"$ c #3c9e3c",
" .XXX ",
" .XXXXXX. ",
" .XXXXXoooXX ",
" .XXXOXXXoXXoXX. ",
" .XXXXXXXOXXoooXXXX ",
" .X+OOXXXOXXoXXXoXX. ",
" X.X+X+OOXOXXoooXXXX ",
" X.XXOXXXOOOXXXXX@@@. ",
" XX.X+XXXXX+XX@@@XXXX ",
" .XX.XX+XXXXX#@XXX@XXX. ",
" XXXX.X$#XXX#$XXXX@XXXX ",
" XXXX.XX$#$$#XXXXXX@XXX. ",
" XXXXX.XXXX#$#XXXXX@XXX. ",
" XXXXX.XXXX#$X$#$XXXX. ",
" .XXXXX.XX#$XXXXXX. .XX. ",
" XXXXX.XX#XXXX. .XXXXX ",
" .XXXXX.XXX. .XXXXXXXX ",
" XXXXX.X..XXXXXXXXXXX ",
" .XXXXX.XXXXXXXXXXXX. ",
" XXXXX XXXXXXXXXXXX ",
" .XXXX.XXXXXXXXXXXX ",
" XXX.XXXXXXXXXX. ",
" .XX XXXXXXX. ",
" XX XXXX. "};

BIN
en-US/images/openlogo-nd.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.3 KiB

BIN
en-US/images/package.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.7 KiB

BIN
en-US/images/paquet-virtuel.dia Normal file
View file

Binary file not shown.

Some files were not shown because too many files have changed in this diff Show more