docs: Rename from c-lightning to core-lightning for local plugins

This commit is contained in:
Christian Decker
2022-05-13 18:07:13 +02:00
parent dc035f0e50
commit 7ef9e6c172
12 changed files with 32 additions and 32 deletions

View File

@@ -6,7 +6,7 @@ from typing import Iterator
import sqlite3
from tqdm import tqdm
# A 'transaction' that was proposed by c-lightning and that needs saving to the
# A 'transaction' that was proposed by Core-Lightning and that needs saving to the
# backup. `version` is the `data_version` of the database **after** `transaction`
# has been applied. A 'snapshot' represents a complete copy of the database.
# This is used by the plugin from time to time to allow the backend to compress
@@ -81,7 +81,7 @@ class Backend(object):
self.db = self._db_open(dest)
def _rewrite_stmt(self, stmt: str) -> str:
"""We had a stmt expansion bug in c-lightning, this replicates the fix.
"""We had a stmt expansion bug in Core-Lightning, this replicates the fix.
We were expanding statements incorrectly, missing some
whitespace between a param and the `WHERE` keyword. This

View File

@@ -57,7 +57,7 @@ def init(lightning_dir, backend_url):
else:
print("Database does not exist yet, created an empty backup file")
print("Initialized backup backend {destination}, you can now start c-lightning".format(
print("Initialized backup backend {destination}, you can now start Core-Lightning".format(
destination=destination,
))

View File

@@ -23,16 +23,16 @@ root.addHandler(handler)
def check_first_write(plugin, data_version):
"""Verify that we are up-to-date and c-lightning didn't forget writes.
"""Verify that we are up-to-date and Core-Lightning didn't forget writes.
We may be at most 1 write off:
- c-lightning and backup are at the same version (happy case)
- c-lightning is 1 write behind: it must've crashed inbetween calling the
- Core-Lightning and backup are at the same version (happy case)
- Core-Lightning is 1 write behind: it must've crashed inbetween calling the
hook and committing the DB transaction.
- c-lightning is one or more writes ahead: either we lost some writes, or
c-lightning was running without the plugin at some point -> crash!
- c-lighning is more than 1 write behind: c-lightning had a lobotomy, or
- Core-Lightning is one or more writes ahead: either we lost some writes, or
Core-Lightning was running without the plugin at some point -> crash!
- c-lighning is more than 1 write behind: Core-Lightning had a lobotomy, or
was restored from an old backup -> crash!
"""
backend = plugin.backend
@@ -50,7 +50,7 @@ def check_first_write(plugin, data_version):
return True
elif backend.prev_version > data_version - 1:
kill("c-lightning seems to have lost some state (failed restore?). Emergency shutdown.")
kill("Core-Lightning seems to have lost some state (failed restore?). Emergency shutdown.")
else:
kill("Backup is out of date, we cannot continue safely. Emergency shutdown.")

View File

@@ -157,7 +157,7 @@ class FileBackend(Backend):
# If this assertion fails we are in a degenerate state: we
# have less than two changes in the backup (starting
# c-lightning alone produces 6 changes), and compacting an
# Core-Lightning alone produces 6 changes), and compacting an
# almost empty backup is not useful.
assert change is not None

View File

@@ -1,7 +1,7 @@
[tool.poetry]
name = "cln-backup"
version = "0.1.0"
description = "Keep your c-lightning node save by backing it up, in real-time (allows recovering without channel closures)."
description = "Keep your Core-Lightning node save by backing it up, in real-time (allows recovering without channel closures)."
authors = ["Christian Decker <decker@blockstream.com>"]
[tool.poetry.dependencies]

View File

@@ -1,19 +1,19 @@
Remote backup backend for c-lightning
Remote backup backend for Core-Lightning
=====================================
Introduction
------------
The purpose of this backend is to allow hassle-free incremental remote backups of a c-lightning
The purpose of this backend is to allow hassle-free incremental remote backups of a Core-Lightning
daemon's state.
The remote backup system consists of two parts:
- A `backup.py` plugin backend that listens for changes to c-lightning's database and communicates them
- A `backup.py` plugin backend that listens for changes to Core-Lightning's database and communicates them
to a remote server.
- A server daemon that receives changes from the backup backend and communicates with a local backup backend
to store them. The server side does not need to be running c-lightning, nor have it installed.
to store them. The server side does not need to be running Core-Lightning, nor have it installed.
### URL scheme
@@ -35,7 +35,7 @@ backup-cli server file:///path/to/backup 127.0.0.1:8700
On the client side:
```bash
# Make sure c-lightning is not running
# Make sure Core-Lightning is not running
lightning-cli stop
# Initialize the socket backend (this makes an initial snapshot, and creates a configuration file for the plugin)
backup-cli init socket:127.0.0.1:8700 --lightning-dir "$HOME/.lightning/bitcoin"
@@ -48,7 +48,7 @@ Usage with SSH
--------------
The easiest way to connect the server and client if they are not running on the same host is with a ssh
forward. For example, when connecting from another machine to the one running c-lightning use:
forward. For example, when connecting from another machine to the one running Core-Lightning use:
```bash
ssh mylightninghost -R 8700:127.0.0.1:8700
@@ -82,9 +82,9 @@ HiddenServicePort 8700 127.0.0.1:8700
Goals
-----
- Hassle-free incremental remote backup of c-lightning's database over a simple TCP protocol.
- Hassle-free incremental remote backup of Core-Lightning's database over a simple TCP protocol.
- Safety. c-lightningd will only proceed when the remote backend has acknowledged storing a change, and will halt when there is no connection to the backup server.
- Safety. Core-Lightning will only proceed when the remote backend has acknowledged storing a change, and will halt when there is no connection to the backup server.
- Bandwidth efficiency. Updates can be really large, and SQL statements ought to be well compressible, so bandwidth is saved by performing zlib compression on the changes and snapshots.