
Debian Handbook for Debian 10 Buster - rlsph
https://debian-handbook.info/browse/stable/
======
walrus01
In terms of linux documentation, generally, I have two recommendations. One,
install Arch Linux in a VM and mess around with it a bit. Not because I
particularly like it, or use it for any production purposes. But because the
Arch wiki is such a wealth of information on individual daemons and
subsystems.

Secondly, make use of the Arch wiki. By knowing at least the basics of how
Arch is organized, you can better discern what technical reference material is
unique to specific quirks of arch, and what is general to the same daemons
running on debian or centos (postfix or dovecot, for instance).

examples of generically useful reference:

[https://wiki.archlinux.org/index.php/Network_Time_Protocol_d...](https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon)

[https://wiki.archlinux.org/index.php/Postfix](https://wiki.archlinux.org/index.php/Postfix)

[https://wiki.archlinux.org/index.php/Systemd](https://wiki.archlinux.org/index.php/Systemd)

~~~
m463
I installed arch, and it was so much faster that it is now my favorite
distribution.

Ubuntu by comparison is a slow intrusive distribution.

I do use debian-ish by way of raspbian.

~~~
Mediterraneo10
Whether a distro will seem "slow" or "fast" is almost entirely down to which
desktop is installed by default on that distro. But users should know that
they are not limited to that default desktop, and they can just type a few
commands and switch to some lighter desktop if their hardware doesn’t smoothly
run the default. Therefore, it is rather a waste of time to completely switch
to a different distro just for the sake of speedups.

~~~
m463
i had gnome on ubuntu and gnome on arch, and arch was _significantly_ faster.
I should try a debian install.

~~~
snazz
Probably the background services and the fact that Arch doesn't come with
AppArmor or SELinux running OOTB.

------
gorgoiler
Debian used to be a necessity. The informational complexity of an OS
installation was defined by the skill of the package managers. You would rely
on them to make smart decisions, which would be codified in the _debian /_
directory alongside the original source, in the dpkg sources themselves.

All that feels by the wayside nowadays. The _information_ about my site
installation is all in a set of ansible playbooks. They could blast their way
through an installation of any modern Linux OS and the result would look like
an horrendous mess to a sysadmin from the 90s, but who cares? It’s still as
reproducible as the carefully tended garden that was a Debian installation of
the old days, but with the advantage that whenever the install drifts into
instability you can just nuke everything and rebuild from scratch.

In fact, it’s all so automated, if you aren’t regularly blasting everything
away and reinstalling, you’re doing it wrong.

No longer do I have a gigabyte or more of backups representing my ossified
Debian install as a fallback. Instead I have a few kB of YAML and ansible to
build everything.

Case in point. Debian 10 ships with LXC 3. If I want LXC 4 I just script the
build and installation. The script is what needs backing up. The OS is
disposable. In the past I might have taken care to ./configure to install in
/opt but why bother? It’s more work (LD_LIBRARY_PATH needs setting) so just
blast it into /use/bin and don’t lose sleep over treading on Debian’s
carefully pedicured toes. If it doesn’t work out, reimage and try something
else. It’s wonderfully transient.

I miss the old days, but I embrace the controlled chaos, volatility, and
dynamism of the future. I can do what I want instead of what, in the last, was
carefully curated for me by expert Debian maintainers. A bazaar to their
cathedral, sort of.

~~~
dsr_
Debian adds a lot of value in tracking and patching security issues.

Debian adds a lot of value in dependency management.

Debian adds a lot of value in community.

All of these things can and are done by other organizations, but Debian is
definitely doing it.

~~~
lmm
Debian adds negative value on security issues. The Debian ssh key
vulnerability was among the worst vulnerabilities ever seen in general-purpose
computing, and also a predictable result of Debian policies which remain in
place to this day. It will happen again sooner or later.

~~~
jcranmer
The ssh key vulnerability was as much a fault of the upstream as it was
Debian: the Debian maintainer who made the patch explicitly asked the OpenSSL
mailing list if it was okay, and they indicated at least acquiescence in the
change.

Given that upstream OpenSSL itself would have the Heartbleed bug revealed a
decade later, with all the revelations of its source code quality made more
notable as a result, I'm willing to place more blame on OpenSSL than Debian
here.

~~~
lmm
> The ssh key vulnerability was as much a fault of the upstream as it was
> Debian: the Debian maintainer who made the patch explicitly asked the
> OpenSSL mailing list if it was okay, and they indicated at least
> acquiescence in the change.

IIRC they asked a list that was not the main project list and not intended for
security-critical questions. Code that actually goes in to OpenSSL gets a lot
more scrutiny from the OpenSSL side, and other big-name distributions either
have dedicated security teams that review changes to security-critical
packages, or don't modify upstream sources for them. Debian is both unusually
aggressive in its patching (not just for OpenSSL; look at e.g. the cdrecord
drama) and unusually lax in its security review.

> Given that upstream OpenSSL itself would have the Heartbleed bug revealed a
> decade later, with all the revelations of its source code quality made more
> notable as a result, I'm willing to place more blame on OpenSSL than Debian
> here.

Heartbleed was a much more "normal"/defensible bug IMO. Buffer overflows are a
normal/expected part of using memory-unsafe languages; every major C/C++
project has had them. Not using random numbers to generate your cryptographic
key is just hilariously awful.

------
caiobegotti
Direct link to online version (as I had to click on three different links to
get to it): [https://debian-handbook.info/browse/stable/](https://debian-
handbook.info/browse/stable/)

~~~
zucker42
That's probably on purpose so you make a donation.

~~~
panpanna
I can live with that.

I think of you are benefiting from a FOSS project day on and day out, donating
"one cappuccino" once in a while would not be a major spending decision.

~~~
diffeomorphism
How many "cappuccinos" do you spend on closed software? Why do you spend less
on software that gives you additional rights?

~~~
panpanna
Cappuccinos are not the upper limit.

It's just a good start.

------
chungy
I thought the effort behind this book died, given the lack of one for Debian
9. This was always an excellent resource for me in the Debian 6-8 days, and
I'm glad to see it back!

Nitpick: the cover still says "Debian Jessie"

------
joppy
I tried to use this handbook yesterday to answer the question: “how do I start
the SSH server on Debian?” and I couldn’t answer it. Compare this to something
like the FreeBSD handbook [1], where the information is very easy to find.

[1]:
[https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/](https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/)

~~~
stephenr
I’d imagine it doesn’t cover that specifically because almost all services
start automatically when they’re installed on Debian.

~~~
JdeBP
It doesn't cover it generally, either. What you have just stated appears
nowhere in the headlined _Handbook_.

------
atum47
I've been using Debian for about 4 years now. Before that I was a Ubuntu user.
Before that, Windows. Never looked back. Great distro. Highly recommend it.

~~~
panpanna
What are your thoughts on Ubuntu vs Debian with respect to functionality and
he support (laptops in particular)?

I have used Ubuntu at work and in home for a while now and things have been
surprisingly free from hassles. I don't mind moving to Debian if things work
as smooth as now.

~~~
markosaric
From my experience, as long as you choose the "nonfree" ISO [1] to install
Debian from, you should be fine. On the default "free" iso my Wi-Fi didn't
work while on the nonfree ISO everything was fine out of the box. Debian these
days also has the "live and nonfree" ISO so you can test everything out before
installing.

[1]: [https://cdimage.debian.org/images/unofficial/non-
free/images...](https://cdimage.debian.org/images/unofficial/non-free/images-
including-firmware/)

~~~
atum47
This! Some computer have proprietary parts like modens and graphics card. Non-
free takes care of all that.

~~~
panpanna
How much non-free would one need on something like a Thinkpad? I guess the
wifi chip, what else?

~~~
atum47
I've been owing Dell for quite some time now, and on Dell machine you need it
for the wi-fi and graphics cards (if they have a nvidia, for instance). Don't
know much about thinkpads, sorry. But, people lots of people from /g/ use it,
and they usually use Gentoo, meaning they compile it from source (almost).

You can use the free version of Debian and install what you need later. But as
I was saying, if you're installing on a laptop with no ethernet cable, non-
free is the way to go.

------
shoo
Complementary to this handbook, if you maintain one or more debian servers it
is useful to learn and adopt a configuration management tool -- assuming you
are not already using another state management technique that gives you even
more control.

The time invested to learn and automate repetitive configuration or admin
tasks (upgrades, installing dependencies, deploying a new version of your app,
etc) through ansible and ansible-playbook pays for itself pretty fast. For
common tasks there are often high level modules that provide a simple
declarative interface to non-interactively configure the desired state
compared to using the underlying command line tools directly. E.g..
installing/upgrading packages with apt:
[https://docs.ansible.com/ansible/latest/modules/apt_module.h...](https://docs.ansible.com/ansible/latest/modules/apt_module.html#examples)

------
unlimit
I got curious to know how it was published. I see that it has been published
using publican.

I looks like the source is all in xml. Are these hand written in xml or there
is some kind of UI to write? Writing everything in xml looks painful.

~~~
JdeBP
It isn't painful. I do doco in DocBook XML myself. I write it with a text
editor and view it with a WWW browser or (when I am using a terminal) a TUI
DocBook XML viewer that I wrote.

Too-little known fact: with a small amount of CSS, mainstream WWW browsers can
view most DocBook XML directly. Witness:

* [http://jdebp.uk./Softwares/nosh/guide/commands/linux-vt.xml](http://jdebp.uk./Softwares/nosh/guide/commands/linux-vt.xml)

* [http://jdebp.uk./Softwares/nosh/guide/commands/linux-console...](http://jdebp.uk./Softwares/nosh/guide/commands/linux-console.xml)

* [http://jdebp.uk./Softwares/nosh/guide/commands/console-docbo...](http://jdebp.uk./Softwares/nosh/guide/commands/console-docbook-xml-viewer.xml)

------
eitland
This seems really useful!

Related question for all debian people I guess will visit this page: Is there
a version of this for all the small stuff in debian?

Background: A few days ago I installed debian under WSL. Normally I used to
install Ubuntu.

I've set it up to be comfortable (bash completion etc,) but I think someone
here mentioned some other guide or something for setting up debian machines,
this handbook seems to be more about large systems administration and less
about configuring it as a developer workstation.

(I also did some cursory searching on this to see if I could find something
about vadh completion in this handbook, but couldn't find it.)

~~~
chungy
Debian has ~60,000 packages and it'd be pretty impractical-to-impossible to
cover them all in a single book. This handbook is about the really common
tasks--even most of the specifics it goes into, such as with mail servers,
LDAP, etc, they have alternative packages and implementations in Debian that
aren't covered.

Thankfully, most packages are very well-documented, you can usually browse
around /usr/share/doc/$PACKAGE to see the upstream documentation and possibly
any Debian-specific information. HTML and PDF versions of documentation tend
to be in an independent $PACKAGE-doc package, so as to keep the main package
rather small.

~~~
mistrial9
odd, I find the docs to be routinely missing, often substituted by a some kind
of shell text file with a gz compression on it (?)

first look on an old system:

    
    
      /usr/share/doc/amd64-microcode
      /usr/share/doc/anacron
      /usr/share/doc/apache2
      /usr/share/doc/apache2-bin
      /usr/share/doc/apache2-data
    

all fit that pattern

~~~
bayindirh
gzipping documents is a long tradition. Most common text reading tools (cat,
more, less, grep, diff, and some more) has "z" variants which work on gzipped
files directly, without ungzipping them.

Most of the tools bigger documentations come in man and info files. If there's
an even bigger, additional documentation, it comes with -doc package (like
apache2-doc).

Otherwise every package comes with some basic documentation and Debian
specific changes file, most of the time.

Debian's specifics on packaging is very strict. You just cannot package
something and publish in the main repo.

~~~
rleigh
It was always somewhat annoying though, particularly when it broke inter-
document links, and it was a legacy of older times. Today, it's way past time
to drop individual file compression. I mean, we have transparent compression
with systems like ZFS, so there's no penalty to pay by half-assing it with
gzip.

~~~
bayindirh
If Linux was a big-iron only OS, I could happily agree but, this stubborn
thing works from Raspberries to mainframes and everything in between. So it's
not always possible to run it on a CPU which can drive an ZFS on a multi-disk
enclosure.

I'd rather have individually compressed files instead of running a heavier FS
layer with smaller/less powerful systems.

------
rlsph
If you (like me) enjoyed the previous version, which discussed Debian 8
Jessie, and are mostly interested in checking out what's new, the commit
history might be a good place to start:
[https://salsa.debian.org/hertzog/debian-
handbook/-/commits/b...](https://salsa.debian.org/hertzog/debian-
handbook/-/commits/buster/master/en-US)

------
dalu
so, does anyone even use Debian anymore? And if you do, what for (no, rPIs
don't count)

------
einpoklum
1st order of business if you're looking into Debian Buster:

Install Devuan (www.devuan.org) Beowulf instead. It's Debian Buster without
systemd. Almost all of the administrator's handbook applies verbatim.

If enough of the Debian usersbase chooses Devuan, its minor diffs will
probably be implemented in Debian mainline and we can get past this sad
affair.

~~~
stephenr
Couldn’t you just install Debian, choose sysvinit and uninstall systemd?

Also, I personally won’t be dropping systemd any time soon because the
alternatives on Debian are:

Go back to Sysvinit and have to write sysvinit scripts myself; or

Use some even less common init system and have no package provided init
scripts/units/what have you.

~~~
JdeBP
One system has, at last count, over 600 provided service bundles in a Debian
package. (It's somewhere around 670 in the development version.) These range
from "accounting" through "keepalived" and "swift@container-auditor" to
"ypbind".

* [http://jdebp.uk./Softwares/nosh/debian-binary-packages.html#...](http://jdebp.uk./Softwares/nosh/debian-binary-packages.html#Bundles)

One can also pull in other people's run program collections, of which the
world has several.

* [http://jdebp.uk./Softwares/nosh/guide/creating-bundles.html](http://jdebp.uk./Softwares/nosh/guide/creating-bundles.html)

And there's a handy tool for what's left.

* [http://jdebp.uk./Softwares/nosh/guide/commands/convert-syste...](http://jdebp.uk./Softwares/nosh/guide/commands/convert-systemd-units.xml)

* [http://jdebp.uk./Softwares/nosh/worked-example.html](http://jdebp.uk./Softwares/nosh/worked-example.html)

Note, for the sake of completeness, that van Smoorenburg rc scripts changed
format on Debian back in 2014. Most of the boilerplate has been eliminated,
and writing them is a lot closer to how would would write a Mewburn rc script
on FreeBSD/NetBSD or an OpenRC script.

* [https://manpages.debian.org/buster/sysvinit-utils/init-d-scr...](https://manpages.debian.org/buster/sysvinit-utils/init-d-script.5.en.html)

~~~
stephenr
Sorry but a slightly better script based init system maintained by one person
just isn't gonna cut it.

~~~
JdeBP
It is fortunate, then, that neither of the ones that I referenced are that.
The several run program collections are, as we can see, provided by a range of
different people from Wayne Marshall to Glenn Strauss; and van Smoorenburg rc
on Debian is maintained by several people, including Petter Reinholdtsen who
introduced the aforementioned 2014 change.

