Fixes#5936.
This commit makes sure every error that causes the Main() function to
return is logged to the log file in addition to being printed to stderr.
With this commit we standardize the error messages in the config parsing
section of the main package. We only print to stdout/stderr in a single
place and also make sure the same error is printed to the log (which
might or might not yet be initialized at that point).
To make it possible to supply our own implementation of a secret key
ring, we extract that part from the chain control and split the whole
chain control creation into two parts.
With this commit we extract the wallet creation/unlocking and
initialization completely out of the main function. This will allow us
to use custom implementations in the future.
We move some of the wallet related functions into the new file that
houses the new customizable implementations for some of our interfaces.
Since the next customizable interface will be the wallet, we move those
wallet and chain backend related helper functions.
NOTE: This is a pure code move.
As a preparation for making more and more implementation details
configurable, we add a new ImplementationCfg struct that houses all the
interfaces that can be defined externally.
As a preparation for extracting the wallet related initialization code,
we first need to separate the purely configuration related chain control
initialization from the wallet related code. We do that by splitting the
chain control into a partial and full struct that is initialized in two
parts. This also allows us to create the wallet configuration itself
outside of the chain control package and we need to thread through fewer
parameters through the chain control config.
To remove one more direct dependency to a variable in our main function,
we pass in the required parameter to the autopilot only instead of the
whole chain configuration.
We'll refactor the wallet creation and unlock process in a following
commit and want to make it possible to not need a direct reference to
the macaroon service in our main function. Since we store it in the
interceptor chain anyway (if we're using macaroons in the first place),
we might as well use the instance there directly.
The block cache size in the chainreg.Config previously wasn't used but
instead the block cache was passed in as a separate parameter. We
replace the cache size with the actual cache in the config to streamline
things somewhat.
To avoid the channel map needing to be re-grown while we fill the cache
initially, we might as well pre-allocate it with a somewhat sane value
to decrease the number of grow events.
With the middleware handler in place, we now need to add a new gRPC
interceptor to the interceptor chain that will send messages to the
registered middlewares for each event that could be of interest to them.
Fixes#4383 by adding a new SafeCopyMacaroon function that correctly
clones all caveats and prevents modifications on the copy from affecting
the original.
In addition to creating a new wallet from an aezeed, we allow specifying
an exteded master root key as the main wallet key directly.
Because an exteded key (xprv) doesn't contain any information about the
creation time of the wallet, we must assume a birthday to start scanning
the chain from (if the user doesn't provide an explicit value). Since
lnd only uses SegWit addresses, it makes sense to
choose the date that corresponds to the first mainnet block that
contained SegWit transactions.
Restoring a wallet from an extended master root key will result in a
significantly longer initial wallet rescan time if the default value is
used.
This adds support for notifying systemd about the state of LND. It
notifies systemd just before waiting for wallet password or, if
`wallet-password-file` was specified, right after unlocking the wallet.
This means that "ready" represents RPC being available for intended use.
It's intentional, so that client services can use `After=` in `systemd`
configuration to avoid misleading error messages about missing files or
refused connections.
Part of #4470
To have all the database backend related code in one place, we finally
also move the initialization of the wallet DB loader option into the
GetBackends() method.
The final database that needs to be made remote compatible is the
watchtower server and client database.
They are handled a bit differently because both of them are not always
active, only when specifically turned on in the config.
Even though the sphinx router's persistent replay log is not crucial in
the operation of lnd as its state can be re-created by creating a new
brontide connection, we want to make lnd fully stateless and therefore
have the option of not storing any state on disk.
The macaroon root keys should also be stored to the remote database if a
replicated backend such as etcd is used.
This commit refactors the macaroons service and wallet unlocker to
accept a kvdb backend directly instead of creating the bolt instance
automatically.
This commit gets rid of the concept of a local and remote database when
etcd is used. Instead the same backend is now used for both the
(previously renamed from local and remote DB) graph and channel state
databases.
This will make path finding extremely slow on etcd and will require
further optimizations and possibly a write-through cache for the graph
DB. But this is a requirement for making lnd itself fully stateless.
In order to separate our databases more clearly, we refactor the height
hint cache DB to use a kvdb backend instead of the channel DB instance
directly.
As a preparation to not have a local and remote version of the database
around anymore, we rename the variables into what their actual function
is. In case of the RPC server we even directly use the channel graph
instead of the DB instance. This should allow us to extract the channel
graph into its own, separate database (perhaps with better access
characteristics) in the future.
As a preparation to initialize more than just the channel database on
startup we introduce a new struct that holds a reference to each of our
database instances.
This changes file reation mode on admin macaroon from 0600 to 0640. The
reason is to make permission management easier.
Closes#4385
**Is this safe?**
Yes, it is. Assuming a reasonably secure Linux system, it will have a
separate group for each user. E.g. a new user `lnd` gets assigned group
`lnd` which nothing else belongs to. A system that does not do this is
inherently broken already.
Since there is no other user in the group, no other user can read admin
macaroon unless the administrator explicitly allowed it. Thus there's no
harm allowing group read.
As requested by users of node bundle software. They want to use the
wallet-unlock-password-file configuration option in their
default/template config file. This makes the first-time lnd setup a bit
more tricky since lnd will fail with an error if no wallet exists yet
while that config option is used.
The new wallet-unlock-allow-create option instructs lnd to not fail if
no wallet exists yet but instead spin up its unlocker RPC as it would
without the wallet-unlock-password-file being present.
This is not recommended for auto-provisioned or high-security systems
because the wallet creation RPC is unauthenticated and an attacker could
inject a seed while lnd is in that state.
In automated or unattended setups such as cluster/container
environments, unlocking the wallet through RPC presents a set of
challenges. Usually the password is present as a file somewhere in the
container already anyway so we might also just read it from there.
This commit adds a new "waiting to start" state which may be used to
query if we're still waiting to become the cluster leader. Once leader
we advance the state to "wallet not exist" or "wallet locked" given
wallet availablity.
This commit also changes the order of DB init to be run after the RPC
server is up. This will allow us to later add an RPC endpoint to be used
to query leadership status.
