diff --git a/contrib/development.conf b/contrib/development.conf
index ff57223..4bda3ca 100644
--- a/contrib/development.conf
+++ b/contrib/development.conf
@@ -1,9 +1,13 @@
-server-name "example.com";
-chroot "/var/telodendria";
+#
+# Telodendria development configuration file.
+#
+
+server-name "localhost";
+chroot ".";
id "_telodendria" "_telodendria";
data-dir "./data";
federation "true";
-registration "false";
+registration "true";
log "stdout" {
level "debug";
timestampFormat "none";
diff --git a/contrib/production.conf b/contrib/production.conf
index 973aec9..45f65aa 100644
--- a/contrib/production.conf
+++ b/contrib/production.conf
@@ -1,131 +1,25 @@
#
-# Telodendria configuration file
+# Telodendria production configuration file.
#
-# This example configuration file serves as the authoritative
-# configuration documentation for the version of Telodendria it
-# ships with.
+# See the following URL for the official documentation on the
+# options here:
+#
+# https://telodendria.io/#configure
+#
+# Alternatively, see site/index.html in the source code.
#
-#
-# Basic configuration
-#
-# This section contains the most common configuration items that you
-# should go through and check.
-#
-
-# The address to listen on. It is recommended to listen on localhost,
-# and then configure a reverse proxy # such as relayd(8) in front of
-# it, because the server does not implement TLS.
-#
-# Also note that Telodendria doesn't provide multiple ports for
-# different things. All APIs are made available over the same port.
-# This works because Matrix allows the port configuration to be
-# shared via .well-known/matrix/, which this server does properly
-# serve.
-#
-# The first parameter is the host name or IP address to listen on,
-# and the second parameter is the port name or number. See the
-# getaddrinfo() manual page for more information.
listen "localhost" "8008";
-
-# Configure the domain name of your homeserver. Note that Matrix
-# servers cannot be migrated to other domains, so once this is set,
-# it should never change, unless you want to start over.
server-name "example.com";
-
-# Chroot to the specified directory immediately upon starting. Note that all
-# other paths and files must be specified relative to the chroot.
-#
-# This only works if Telodendria is being run as root. If it isn't, then a
-# warning is printed to the log, and no chroot is done. In that case, this
-# path is prepended to all the other paths and files, to create a sort of
-# soft chroot.
chroot "/var/telodendria";
-
-# Set the effective user and group to run as, immediately after making the
-# chroot and socket binding calls.
-#
-# Note that this only works if Telodendria is being run as root. If it isn't,
-# then a warning is printed to the log if the current user and group are not
-# equal to what's specified here.
-#
-# The first parameter is the user, and the second is the group. If the second
-# is not specified, then it is assumed to be the same as the first.
id "_telodendria" "_telodendria";
-
-# The data directory in which Telodendria will store all user and
-# event information. Telodendria doesn't use a database; it uses a
-# flat-file directory structure, sort of like how most SMTP servers
-# use Maildirs or mbox files.
data-dir "./data";
-
-# Whether to enable federation or not. Matrix is by default
-# a federated protocol, but if you just want your own internal chat
-# system with no contact to the outside, then you can disable
-# federation.
federation "true";
-
-# Whether to enable new user registration or not. For security and
-# anti-spam reasons, this is set to false. You can add users via the
-# command-line tool.
-#
-# Generally, everyone should run their own homeserver, but that isn't
-# always possible with the waning number of available public IP
-# addresses, so if you'd like to provide a public service and allow
-# others to register for accounts on your homeserver, feel free to
-# enable registration. Telodendria should be able to handle a large
-# amount of users without difficulty.
registration "false";
-
-#
-# Advanced options
-#
-# This section contains options for system administrators that need
-# more control over their Telodendria instance.
-#
-
-# Log to a file. If this directive is omitted, logging is done to
-# the system standard output. It may be redirected to the syslog from
-# there, but it may not.
-#
-# Telodendria manages its own log file format, so it manually
-# configures the log file. If you're going to be running Telodendria
-# in a chroot, the log file will have to live inside the chroot.
-#
-# Acceptable values here are "stdout" or a log file.
log "./telodendria.log" {
- # The level to log. This can be one of "error", "warning",
- # "task", "message", or "debug", with each level showing all
- # the levels above it as well. For example, "error" shows
- # only errors, "warning" shows warnings and errors, "task"
- # shows tasks, warnings, and errors, and so on.
level "message";
-
- # If you want to customize the timestamp format, you may do so
- # here. Acceptable values are "none", "default", or a formatter
- # string as described by your system's strftime(3).
timestampFormat "default";
-
- # Whether or not to enable colored output on TTYs. Note that
- # color sequences will not be written to a log file, so this
- # only applies if the log is being written to a real terminal.
color "true";
};
-
-# How many worker threads to spin up and pull from the request queue.
-# This should generally be less than your total CPU core count, to
-# prevent overloading your system, but if you have a multithreaded
-# system, feel free to set this to as many threads as you feel
-# comfortable with Telodendria managing.
-#
-# Note that if you have a single-threaded machine with only 1 CPU
-# core (as is typical with low-tier virtual machines), you may want
-# to set this to a lower number, or even set it to zero to disable
-# threading altogether, and run everything in a main thread,
-# processing requests one at a time.
-#
-# Ultimately, it depends on what your machine is capable of. You may
-# just have to play around with this value to see which configuration
-# gives you the best performance.
threads "4";
diff --git a/site/index.html b/site/index.html
index 2be6a76..a74938f 100644
--- a/site/index.html
+++ b/site/index.html
@@ -264,11 +264,181 @@ what the td
script can do.
-Once you get Telodendria built, you will have to write a
-configuration file for it. The configuration file is a simple
-OpenBSD-style configuration file, which should be called
-telodendria.conf
.
+Telodendria is designed to be extremely configurable. As such, it has
+a fairly extensive configuration file. The configuration file is passed to
+the Telodendria binary with the -c
option, and is
+typically called /etc/telodendria.conf
. It uses OpenBSD-style
+syntax, and consists of the following options.
+There are example configuration files in the contrib
folder of
+every source tarball, and in the CVS repository.
+
listen [hostname] [port]
+
+The address to listen on. It is recommended to only listen on
+localhost
, and then configure a reverse proxy such as
+relayd(8)
in front of it, because Telodendria does
+not implement TLS. Note that Telodendria doesn't provide multiple
+ports for the various services it offers. All APIs are made available over
+the same port.
+
+[hostname]
should be a host name, an IPv4 address, or
+an IPv6 address, if your operating system supports IPv6. [port]
+should be a decimal port number or a service name. Refer to your system's
+getaddrinfo()
manual page for acceptable values for both of
+these parameters.
+
+The listen
directive is entirely optional; if it is omitted,
+then Telodendria will listen on localhost
, port
+8008
by default.
+
server-name [name]
++Configure the domain name of your homeserver. Note that Matrix servers +cannot be migrated to other domains, so once this is set, it should never +change, unless you want unexpected things to happen, or you want to start +over. +
+
+[name]
should be a DNS name that everyone on the network
+can resolve. This directive is required.
+
chroot [directory]
+
+Change the root to the specified directory as soon as possible. Note that
+all other paths and files specified in the configuration file must be
+accessible from this directory. This only works if Telodendria is
+running as root
. If it isn't, then a warning is printed to the
+log, and no chroot
call is made. In that case, Telodendria
+will still change into the specified directory, so that other paths can be
+made relative to this one.
+
+This directive is required. It is expected that the server data and logs +will live here. +
+id [uid] [gid]
+
+The effective UNIX user and group to drop to after binding to the socket and
+changing the filesystem root. This only works if Telodendria is running as
+root
, and is used as a security mechanism. If Telodendria is
+started as a non-privileged user, then a warning is printed to the log if that
+user does not match what's specified here.
+
+This directive is required, even if Telodendria is unable to switch to +this user. It can be used as a sanity check to make sure the permissions are +working properly. +
+data-dir [directory]
++The data directory in which Telodendria will write all user and event +information. Telodendria doesn't use a database like other Matrix +homeserver implementations; it uses a flat-file directory structure, similar to +how an SMTP server uses Maildirs to deliver email. +
+
+This directive is required. [directory]
should be a path relative
+to the chroot
directory. Don't depend on the chroot
+option working, because there are many legitimate cases when Telodendria
+will not be started as root
, thus causing the chroot to fail.
+
federation [true|false]
+
+Whether to enable federation with other Matrix homeservers or not. Matrix by
+its very nature is a federated protocol, but if you just want your own internal
+chat server with no contact with the outside, then you can use this option to
+disable federation. It is highly recommended to set this to true
,
+however, if you wish to be able to communicate with users on other Matrix
+servers.
+
+This directive is required, though it may be made optional at some point in +the future. +
+registration [true|false]
+
+Whether or not to enable new user registration or not. For security and anti-spam
+reasons, you can set this to false
. If you do, you can still add users
+via the administrator API.
+
+In an ideal world, everyone would run their own homeserver, so no public
+registration would ever be required. But unfortunately, not everyone has the means
+to run their own homeserver, especially because of the fact that public IPv4 addresses
+are becoming increasingly harder to come by. If you would like to provide a service
+for those that are unable to run their own homeserver, you can set this to true
,
+which will allow anyone to create an account.
+
+Telodendria should be capable of handling a large amount of users without +difficulty or security issues. This directive is required. +
+log [file|stdout]
++The log configuration. Telodendria uses its own logging facility, which can +output to either standard output or a file. A number of child directives can be +added to this directive to customize the log output: +
+level [error|warning|task|message|debug]
+
+The level of messages to log at. Each level shows all the levels above it. For
+example, setting the level to error
will show only errors, while
+setting the level to warning
will show warnings and errors.
+task
shows tasks, warnings, and errors, and so on.
+
timestampFormat [format|none|default]
+
+If you want to custom ize the timestamp format shown in the log, or disable
+the timestamp functionality altogether, you do so via this option. Acceptable
+values are none
, default
, or a formatter string as
+described by your system's strftime()
manual.
+
color [true|false]
++Whether or not to enable colored output on TTYs. Note that ANSI color sequences +will not be written to a log file, only a real terminal, so this option +only applies if the log is being written to a standard output which is connected +to a terminal. +
+threads [count]
++How many worker threads to sping up to handle requests. This should generally be +less than the total CPU core count, to prevent overloading the system. The most +efficient number of threads ultimately depends on the configuration of the machine +running Telodendria, so you may just have to play around with different +values here to see which gives the best performance. +
+Telodendria is a very ambitious project. There's a lot that needs @@ -325,7 +495,7 @@ can get involved.