- introduction subsection created

Petr Špaček authored 5 years ago and Vladimír Čunát committed 5 years ago

These files did not have GNU GPL v3 boilderplate in them so
I've added machine readable tag with appropriate license.

Older versions of sphinx detected "operation" ref as duplicit.

- mention process management
- describe privileges and capabilities which have to be configured
- move garbage collector to this section, as is it enabled by default

Petr Špaček authored 5 years ago and Tomas Krizek committed 5 years ago

Also remove extra headers for trust anchors and mode(), this is an
implementation detail not important for users.

Petr Špaček authored 5 years ago and Tomas Krizek committed 5 years ago

It logically belongs here and it will make high-level structure less
crowded.

Petr Špaček authored 5 years ago and Tomas Krizek committed 5 years ago

Content from the proposed Operator's guide was split into sections and
main chapters were restructured. New structure follows "purposes":
- quick start - installation, startup
- configuration
- operation - performance, monitoring, etc.
- documentatino for developers

- rename tuning guide to operator's guide
- refactor multiple instances section
- add instance-specific configuration section with examples

Petr Špaček authored 6 years ago and Tomas Krizek committed 6 years ago

We might eventually have section "migrating from other resolvers".

Previously we were using names "Knot DNS Resolver" and "Knot Resolver"
interchangibly and the prefix "Knot DNS" was somehow confusing users.
Let's see if this rebranding actually helps or not.

I don't think it's good to write that we "provide a library",
as it currently doesn't seem suitable for usage outside kresd.

The manual page discusses basic usage of kresd, but completely lacks
configuration description. Users are pointed to
https://knot-resolver.readthedocs.io for reference. When visiting this
page, the most important information they don't have yet, is how to
configure kresd. This should be the first chapter in the documentation
to make it easier to find.

The engine is responsible for central managemento of resources and work
distribution. This allows to spawn multiple loops.

The engine configuration / interface is based on Lua 5.1-5.2, including
a RPC and a simple CLI interface. This is going to be the core of configuration
later on.