The kvdb-to-SQL data migration polls lnd's ListMacaroonIDs RPC, which
only becomes available once lnd reaches its "RPC active" state. On
nodes with a large channel/graph state, lnd can take well over a
minute to get there after the wallet is unlocked, which exceeded the
previous fixed 60-second (120 x 500ms) poll budget and caused the
migration - and therefore litd startup - to fail permanently,
requiring a manual restart.
Replace the fixed attempt cap with a wait bounded by the new
--lndreadytimeout config option, defaulting to a generous 10 minutes,
while still aborting early if the daemon is shutting down. The wait
happens inside the migration's SQL write transaction, so it is kept
bounded rather than unbounded as a safety backstop.
Introduce configuration flags to enable baking a super macaroon on
startup. Add --bake-super-macaroon (none, read-only, read-write) and
--super-macaroon-path.
Also add validation logic to ensure that the configured super macaroon
path ends with the expected '.macaroon' suffix, rejecting startup early
otherwise.
The `-V` flag inherited from lnd printed the integrated lnd version
(`build.Version()`) instead of litd's own version, while litd's own
`--version` flag already reported the correct value via RichVersion().
Consolidate both flags so either one prints litd's version.
Fixes#1091
Signed-off-by: 0xfandom <kashyapshivank01@gmail.com>
Reject `litd` startup when another SQL database exists than the selected
SQL `databasebackend` choice.
When starting with the `databasebackend` config flag set to `postgres`,
we check whether an `sqlite` database file exists at the default path
and fail startup if it does. When starting with `sqlite`, we instead
check whether `postgres` database configuration has been provided and,
if so, whether a database exists at the configured `postgres`
connection parameters.
This prevents accidental switches between SQL backends. This is
especially important because allowing such a switch would retrigger the
KVDB-to-SQL migration for the newly configured SQL backend. In that
scenario, the data would already have been migrated previously, meaning
the migration source would be stale and could result in outdated data
being imported. Additionally, it would create two divergent copies of
the data across separate SQL backends. Since we do not support
migrations between SQL backends, recovering from such a situation would
not be possible.
Add a config option and env variable which allows users to skip the
migration confirmation prompt. This is useful for users who which are
running in a non-interactive environment, and does not have access to
pass input to stdin.
The kvdb accounts db is specifically set to be created in the same
folder as the macaroon path, while the sessions and rules db are created
in the network folder.
That means that users which have set a custom macaroon path, can have
an accounts db in a separate folder than the sessions and rules db.
In order to ensure that the migration from kvdb to SQL uses the correct
db folders, we need to make sure that the migration code uses the same
logic as the creation of the db logic.
Create the SQLite database directory from
c.Sqlite.DatabaseFileName instead of the generic network directory.
This ensures startup uses the final validated SQLite path, including
cases where loadAndValidateConfig has already overridden the
database file location to point at the correct network-specific
directory.
Move the SQLite and Postgres BaseDB close handlers to immediately
after the SQL store is created.
This ensures the cleanup function is registered even if the
subsequent migration or store initialization steps fail, avoiding
leaked SQL handles on early returns.
Make the `NewStores` function into a struct member of the `Config`
struct, as the choice of database backend is now part of the production
configuration.
As the SQL migrations prior to the kvdb to SQL migration was never live
in production, we can safely assume that the sql database is empty prior
to the kvdb to sql migration.
Therefore, it is not necessary that we create an backup of the sqlite
database for every migration that exists for the time being.
As the sqldb/v2 intentionally doesn't delete the backup file when a
migration has been completed (as this is intentional behaviour for tapd)
and the package so far doesn't support any option to delete the backup
file, this otherwise creates multiple unnecessary backup files for
users.
Once the sqldb/v2 does support making deletion of the backup file
possible, or once we add another sql migration, we need to toggle the
backup behaviour for the sql migrations on again.
Change the default database backend from bbolt to SQLite now that SQL
backends are exposed through the main configuration path.
This will trigger the kvdb to SQL migration automatically for users who
have not specifically set their database backend to bbolt.
Note that once the kvdb to sql migration is complete, the user's bbolt
database will be tombstoned.
Move the database backend selection from the `dev` config file into the
main `Config` struct, i.e. into production.
This will enable an sql database backend to be used in production.
This introduces a new firewall.request-logger.disable config option to
completely disable request logging. When disabled, the request logger
interceptor is not instantiated, avoiding all logging overhead including
database writes and request processing.
This is implemented as a separate disable flag rather than adding a new
log level because the goal is to bypass the logging system entirely for
performance reasons, not just filter events. A log level would still
process and filter each request through the interceptor.
The change also adds validation to ensure autopilot remains enabled only
when request logging is active, since autopilot relies on action logs
for rule enforcement and auditing.
- Replace occurrences of `// nolint:lll` with `// nolint:ll` across
files for consistency.
- Reformat multiline strings, comments, and function parameters to
improve clarity and adhere to style guidelines.
- Add `// nolint:ll` comments where necessary to prevent linter
warnings.
Add the `commit_hash` field to the GetInfoResponse. The `commit_hash`
field will contain the most recent commit_hash that the build was based
on. If the build had uncommitted changes, this field will contain the
most recent commit hash, suffixed by "-dirty".
The semantics of the `version` field is also updated to always contain
the most recent semantic version of the litd node, following the
semantic versioning 2.0.0 spec (http://semver.org/).
This commit updates:
- LND
- pool
- loop
- taproot-assets
- faraday
- lighting-node-connect
- aperture
- lndclient
- btclog
We start using the new btclog v2 library and the associated breaking
changes in the lnd/build package.
With this commit, we deprecate the `--remote.lit-maxlogfiles` and
`--remote.lit-maxlogfilesize` options and introduce new logging options
under the `--remote.lit-logging` namespace.
Finally, the LND update introduced a new `MaxBlocksMinedPerTest`
variable in the `lntest` package that we now need to override in order
for our itests to pass.
In this commit, we introduce a DevConfig struct which is embedded in the
main lit Config struct. It is defined in two separate files that are
made mutually exclusive using the `dev` build tag. The idea of this
struct is that it allows us to expose additional config options to LiT
if we build in a development environment such as our itests. In other
words, we will be able to start developing features and testing them
before making them available to users via the production build.
As of this commit, both implementations of the struct are the same.
The GRPC connection logger is very verbose and normally not very useful.
So it leads to more confusion and unnecessary log bloat than it actually
helps to debug things.
So we disable it by default, meaning that if GRPC=<level> doesn't appear
in the log level config string, we add GRPC=off.
That means we can still manually turn it on by adding ,GRPC=info to the
log config (e.g. --lnd.debuglevel=debug,GRPC=info).
This commit adds the `tlsextraip` and `tlsextradomain` config fields to
the LiT config. This allows users to specify additional IPs and domains
to be included in the TLS certificate.
Fix the macaroon path construction so that even if the network is not
mainnet, the path gets constructed correctly from a user specified
"--lit.dir" flag.
By default the taproot assets subserver will start in integrated mode
like the rest of subservers. An execption is if we are running in
"mainnet" where we want it disabled because it is not yet supported.
Users won't be able to start the sub-server in "mainnet" even if they
set the `--taproot-assets-mode=` flag.
Enable to start litd with taproot asset subserver disabled.
The default mode for the new sub-server is "Disabled"
Add coverage in itests for flows with some subservers disabled (based on
Elle's #537)
Ensure that all of Lit's subserver loggers have been registered _before_
the config is validated. This will allow users to use the
`--lnd.debuglevel` flag to set Lit specific subserever logger levels.
Add a new `disableui` config option. If this option is set then the user
no longer needs to set the `uipassword` config option. This also means
that the user will no longer be able to interact with the local UI.
In this commit, we remove Lit's dependency on LND's tls cert in
integrated mode. With this commit, even if Lit is started in integrated
mode, it will create its own tls cert to use for serving the webserver.
This commit fixes an issue with file system paths on Windows. The path
package is only intended to be used with URIs or non file system paths.
For anything OS dependent, filepath should be used instead.
