LNbits – Die Plattform für die dritte Ebene

Wer sich schon etwas mehr mit Bitcoin und vor allem mit Lightning auseinander gesetzt hat, der wird sicherlich auch schon mal auf LNbits gestoßen sein. Während man Bitcoin als das härteste Fundament für digitales Geld bezeichnen kann, ist das Lightning ⚡ Network die skalierende Transportschicht auf Bitcoin. Auf der Lightning Ebene können die Bitcoin Sats (Satoshis) schnell und effizient er als im ersten Layer (Bitcoin onchain) zur Zahlung verwendet werden. Die Weiterentwicklung auf der zweiten Ebene ist entkoppelt von der maximalen Sicherheit auf der Basisschicht und deshalb haben wir dort auch mehr Freiheiten. Wir binden Bitcoin der ersten Ebene, durch Lightning Channels (Zahlungskanäle zwischen zwei Nodes), an die zweite Ebene, dem Lightning ⚡ Network (offchain). Damit haben wir den Wert des Bitcoin in die zweite Ebene gehoben, sind aber freier und flexibler in der Weiterentwicklung, da wir die erste Ebene nicht mehr direkt verwenden und auch nicht stören. Erst wenn wir den Zahlungskanal zwischen den Nodes wieder auflösen, wird der Wert aufgeteilt und als zwei separate unverbrauchte Transaktionsausgaben (UTXOs) in die Blockchain (onchain) geschrieben.

LNbits baut auf der Lightning Technologie auf und nutzt das Lightning ⚡ Network. Man kann LNbits als Plattform für eine weitere Ebene sehen, der Applikations- oder Anwendungsschicht. LNbits selbst ist ein Wallet und Account System mit einer Finanzierungsquelle im Hintergrund, wie zum Beispiel einen Lightning ⚡ Node. Was LNbits aber wirklich besonders macht, es ist auch eine Plattform für kleine Applikationen, die Erweiterungen genannt werden. Das sind kleine Programme, die mit LNbits Konten verküpft werden und darüber hinaus, über Schnittstellen, mit anderen Systemen interagieren, um damit bestimmt Funktionen zu erfüllen.

Während man Bitcoin in der Blockchain als Gold bezeichnen kann, um darin Werte wie Arbeitszeit zu speichern, kann man Bitcoin in der zweiten Ebene als ein digitales Bargeld verstehen. Und LNbits ist dann die Plattform für den Marktplatz, wo man das digitale Bargeld verwenden kann. Mit LNbits erzeugt man dedizierte Konten, die eine direkter Anbindung zu Shops, Automaten, Tauschplattformen, Servicefunktionen, Voucher, etc. haben können.

Man kann LNbits auch als ein Schweizer Taschenmesser oder ein Multitool mit der Option von Plugins für Lightning ⚡ Anwendungen sehen. Es kann unzählige Werkzeuge und damit Funktionsmöglichkeiten haben. Alles verpackt in kleine Apps/Plugins wie elektronischer Schalter, online/offline Kassenterminal, Paywalls, Split Payments, Event Tickets, Marktplatz, NFC Karten Wallets und Voucher, Ecash Mint, usw. Wir können damit jetzt das volle Potential von Bitcoin ⚡ Lightning nutzen und damit auf die nächste Ebene heben, um ganz neue Anwendungen zu ermöglichen.

"Be your own bank" war gestern, jetzt heißt es "Be a bank AND marketplace for your family & friends" . Denn LNbits ist ein Technik Hub für Lightning ⚡ Anwendungen. Solche, die mit dem bestehenden Fiat Geldsystem so nicht möglich sind und schon gar nicht ohne Vertrauen und Mittelsmann. Und genau das ändert sich mit LNbits, denn wir haben jetzt erstmals die Möglichkeit, technische Finanzdienstleistungen souverän zu kontrollieren.

Wer hätte denn gedacht, was aus dem Internet einmal hervorgeht und was alles darauf aufsetzt? Wir haben jetzt die Möglichkeit das Leistungsvermögen von Bitcoin ⚡ Lightning erst so richtig auszuschöpfen und damit das Potential für unser Zukunft zu heben. Denn Zahlungen werden günstiger, schneller, wir können es selbst kontrollieren und recht einfach in unsere digitale Welt einbinden. Die Entwicklung wird schnell und letztendlich exponentiell voranschreiten. Wer nicht nur zuschauen sondern auch mitmachen möchte, dem zeige ich in diesem Tutorial wie dieses mit LNbits geht.

1. Über dieses Tutorial

Schön das ihr interssiert seid und einen tieferen Blick auf LNbits werfen möchtet. Ich werde euch hier allerdings nicht zeigen wie LNbits funktioniert oder was man mit den Erweiterung alles so machen kann, denn dafür gibt es schon viele gute Tutorials. Seht euch dazu einfach mal auf der LNbits Wiki Seite um. Oder ihr könnt euch auch ein Video von mir anschauen, siehe unten. Das Erstellen dieses Videos hat mir damals sehr geholfen LNbits und das verwendete Protokoll LNURL (Lightning URL) besser zu verstehen. Da es aber auch schon eine ganze Weile her ist, ist es im Detail auch nicht mehr up to date. Es hat sich in der Zwischenzeit viel getan und die in den Video genannten Weblinks sind nicht mehr aktuell. Aber man bekommt eine ganz gute Übersicht darüber, was LNbits und das LNURL ist. Kleiner Hinweis, der Donation QR-Code Link am Ende des Videos funktioniert nicht mehr, da es den Server nicht mehr gibt. „Nichts ist so beständig wie der Wandel.“ (Heraklit)

Ich werde in diesem Tutorial nur aufzeigen was LNbits ist, wie ihr es verwenden könnt und dann dazu übergehen, welche Optionen ihr habt, um LNbits selbst zu betreiben. Denn es gibt eine ganze Reihe von Möglichkeiten. Vom Full Custody Service (die Funds und LNbits sind unter Gewahrsam eines Anderen), über halb custody, so das zumindest LNbits in Eigenverantwortung liegt, bis hin zum selbstsouveränen hosten und betreiben von LNbits und der benötigten Finanzierungsquelle.

Das Tutorial richtet sich an alle Interessierten und solche die LNbits selbst betreiben möchten. Es ist sehr technisch und die Umsetzung braucht Zeit und Sorgfalt, aber ihr werdet an die Hand genommen und jeder Schritt ist ausführlich erklärt. Aus eigenen Erfahrung weiß ich wie schwierig es ist, wenn Teile der Dokumentation fehlen und man nicht weiß wo es weiter geht, deswegen habe ich genau darauf geachtet und jeden Schritt erklärt.

2. Was ist LNbits und wo fang ich an?

LNbits ist eine Free and Open Source Software (FOSS). LNbits ist damit freier und kann flexibler und schneller wachsen, als proprietäres System. Es wird sich immer die effizientere Lösungen durchsetzten. Und weil LNbits eine FOSS ist, habt ihr die Möglichkeit eure eigene Version eines LNbits Server zu bauen und zu betreiben. LNbits selbst ist "nur" ein kleines (Python) Programm mit einer Datenbank, dass die Funktion eines Kontensystem für Lightning ⚡ Wallets erfüllt. Dazu benötigt LNbits immer eine Finanzierungsquelle (Funding Source), also ein Wallet. Das besondere an LNbits ist die Vielzahl an Erweiterungen, die häufig auch das Lightning Protokoll LNURL verwenden. Dieses ermöglicht Anwendungen, die mit der reinen standardisierten Lightning Netzwork Technology (Basis Of Lightning Technology (BOLT)) so nicht möglich wären und das Verknüpfen unterschiedlicher Anwendungen mit Lightning Zahlungen erst ermöglichen.

Der erste und einfachste Weg LNbits zu verwenden ist ein Custody Service, wie z.B. der freie und kostenlose Demo Server demo.lnbits.com. Der ist gut geeignet, um erste Erfahrungen mit LNbits zu sammeln. Probiert es aus, spiel damit herum. Der Server ist immer auf dem neuesten Stand. Hilfe bei Fragen kannst du in English in der LNbits Telegram Gruppe erhalten. Bitte bedenke, dass der Demo-Server ein Custody (Gewahrsam) Service ist und von den Entwicklern hin und wieder auch experimentell genutzt wird, da hier Aktualisierungen getestet werden. Es wird also nicht empfohlen den Server als "produktive" Instanz anzusehen, denn es ist ein Demonstrations-Server mit vollem Funktionsumfang, bei dem es aber keine Garantie auf die Funktion oder die Gelder gibt. Wenn ihr etwas "verlässlicheres" suchst, kannst Du entweder das System eines Freundes verwenden, oder gleich eine eigenen LNbits Server mit Finanzierungsquelle hosten. Erst dann seid ihr wirklich souverän und habt die volle Kontrolle über LNbits und der Finanzierungsquelle. Aber es muss nicht unbedingt nur schwarz oder weiß sein, manchmal gibt es auch ein Spektrum.

3. Die Optionen um LNbits zu betreiben

Voll Custody habt ihr gerade kennen gelernt, es gibt aber noch verschiedene anderes Varianten LNbits aufzusetzen. Wir brauchten immer ein Wallet und eine Plattform auf der LNbits läuft. Das kann zum Beispiel euer Lightning ⚡ Node auf einem Raspberry PI sein, ein separater PC oder ein Server in der Cloud.

Die meisten Nodes wie Raspiblitz und Umbrel unterstützen LNbits und sie haben die Finanzierungsquelle ja auch gleich schon an Bord. Zum Testen und für die reine Nutzung im Heimnetzwerk ist das auch vollkommen ausreichend. Doch wenn man sein LNbits oder Funktionen von LNbits von außerhalb des lokalen Netzwerks nutzen möchte, also innerhalb es Internets, dann wird es schon schwieriger. Die meisten werden keine fest IP vom Internet Service Provider bekommen oder die Kosten scheuen. Doch du würdest damit dein Standort doxen, was nicht zu empfehlen ist, wenn man bedenkt, dass es sich hier um eine private Bank handelt.

Dafür gibt es zwar Lösungen, wie das Nutzen eines dynamische DNS-Dienstes, aber auch dafür muss man wieder eingehenden Datenverkehr an seinem Router freischalten und der DNS-Dienst sollte zudem immer zeitnah aktualisiert werden. Über die reine Tor Verbindung funktioniert zwar der Zugriff auf die LNbits Seite, allerdings hat Tor eine sehr hohe Latenz, ist unzuverlässig und ihr benötigt immer einen Tor-fähigen Browser und die meisten Wallets der Anwender (Clients) werden damit nicht umgehen können.

Eine elegante Lösung scheint die Verwendung von Diensten wie z.B. Cloudflare als Tunnel Supporter zu sein. Es ist überschaubar einzurichten und sogar kostenlos. Aber dann macht ihr euch wieder von Dritten abhängig und Cloudflare kann euren gesamten Datenverkehr einsehen oder gar ändern, da es als Vermittler zwischen dem Browser des Clients und deinem lokalen Server fungiert.

Eine grundsätzlich gute Lösung ist die Einrichtung eines Reverse Proxy. Da schaltet man zwischen seinem Node und dem Internet einen Server, zu dem sich der Node per Clearnet (normales Internet) oder Tor (allg. als Darknet bekannt) mit dem Reverse Proxy Server verbindet. Anfragen an den Node werden über den Proxy Server zu dem Node weiterleitet. Zumindest die Clearnet Variante ist schon mal gar nicht so schlecht, es ist aber auch technisch anspruchsvoll. Sämtliche Kommunikation des Node läuft in diesem Fall weiter über Tor.

Dann gibt es noch Kombinationen, bei denen man den Node bzw. das Wallet und die LNbits Anwendung voneinander separiert. Persönlich finde ich das die attraktivste Lösung, damit kann ich mein LNbits unabhängig von der Finanzierungsquelle betreiben und im Fehlerfalle sogar einfach zwischen verschiedenen Instanzen switchen. Dadurch wird das Ganze etwas dezentraler und resilienter. Es ist nicht unbedingt die einfachste und günstiges Lösung, aber eine, die die größtmögliche Kontrolle, Sicherheit, Flexibilität und Skalierbarkeit bietet. Einen eigenen Virtual Private Server (VPS) zu betreiben, auf dem LNbits läuft und ich mir auswählen kann, mit welchen Wallet bzw. Node ich mein LNbits verbinde, ist schon sehr faszinierend.

Hier wurden jetzt sicherlich nicht alle Möglichkeiten und Optionen betrachtet, sondern lediglich die Gängigsten und mir bis dahin bekannten.

4. Die Wahl des LNbits Server

Nach langem Suchen bin ich auf die GitHub Seite vom TrezorHannes gestoßen. Er hat aus mehreren einzelnen Puzzle Stücke (Tutorials) ein Großes Tutorial (vps-lnbits) erstellt. Der Kernpunkt des Tutorial ist ein Virutal Privat Server (VPS) auf dem eine LNbits Instanz ausgeführt wird. Als Finanzierungsquelle wird ein Lightning ⚡ Node verwendet, genauer ein LND Node. Der VPS baut ein Virtual Privat Network (VPN) mit dem Node auf und schleust den gesamten Datenverkehr des Node über den VPN Tunnel zum VPS und weiter ins Internet und auch wieder zurück. Der Node hat damit einen Hybrid Modus bekommen. Er ist damit sowohl über Tor als auch über Clearnet erreichbar. 🤩

Der VPS hat eine eigene öffentliche IP-Adresse und damit auch der Node, der über den VPS getunnelt wird. Dieses optimiert die Konnektivität des Node, denn über das Internet ist die Verbindung stabiler und schneller als nur über Tor. Der Standort ist trotzdem geschützt, weil man aus dem Internet nur die IP-Adresse des VPS sieht.

Die Verbindung zwischen Node und VPS nenne sich Virtual Private Network (VPN), weil die Kommunikation verschlüsselt ist. Man nennt die Verbindung auch einen VPN Tunnel. Über den gleichen Tunnel kann die LNbits Instanz in diesem Szenario mit dem Node kommunizieren. Und schon haben wir ein sicheres, flexibles und skalierbares System, das wir vollständig selbst kontrollieren.

Der Cloud Service Provider ist nur ein Anbieter von Vielen, der sich schnell wechseln lässt. Die Trennung von Node und LNbits erlaubt es die Funding Source schnell auszutauschen, falls der Node mal ausfällt oder die zugrundeliegende Funding-Source gewechselt werden soll. LNbits erlaubt die Nutzung von z.B. LightningTipBot oder einem Custody LNbits Wallet. Man muss in der Konfigurationsdatei von LNbits nur die Schnittstellen Daten der Finanzierungsquelle anpassen. Das erhöht die Verfügbarkeit enorm.

Es ist auch skalierbarer, da man beim Cloud Service Provider einfach CPU, RAM, Festplatte oder Bandbreite für seinen VPS dazu buchen kann. Es ist ausfallsicher, weil die Server auf dem unser VPS läuft, professionell betreut wird und man einfach Snapshots / Backups des VPS machen kann. Für mich sprachen all diese Gründe dafür, diese Variante zu wählen. Und mit $6 / Monat, hat sie wie ich finde, auch einen akzeptablen Preis.

Noch ein Hinweis: Wer keinen eigenen Node hat, oder wem das Ganze Zuviel Technik auf einmal ist, der kann auch eine abgespeckt Version probieren. Ihr könnt auch nur den Virtual Private Server mit LNbits einrichtet und dann mit einem Custody Wallet wie z.B. dem LightningTipBot verknüpfen. Dann habt ihr auch eine eigene LNbits Webseite, nur die Finanzierungsquelle ist in Gewahrsam. Das macht die ganze Installation viel einfacher. Ihr braucht dazu nur noch die Kapitel 7.1 bis 7.2. und 7.9 bis 7.12. Der wirklich komplizierte Part ist damit ausgeklammert.

5. Ein paar allgemeine Informationen

Die Vorlage vom TrezorHannes ist wirklich sehr gut, allerdings ist das ganze auch sehr anspruchsvoll, da man teilweise die Hintergründe verstehen muss. Viele Disziplinen kommen hier zusammen. Man liest in unser beider Tutorials von Ubuntu, VPS, VPN-Tunnel, Firewall, Port Weiterleitung, API, Macaroon, Domain Hosting, Webserver, Datenbank und so weiter. Das kann einen ganz schön ins Schwitzen bringen und hält viele Stolpersteine bereit, bei denen man schnell machtlos erscheint. Aber mit ein bisschen Neugier, Willen und den richtigen Hinweisen, kann das eigentlich jeder hinbekommen.

Wenn ihr der Anleitung Schritte für Schritt folgt und ein bisschen aufpasst, dass ihr die Befehle richtig kopiert und ggf. anpasst, dann kommt ihr zum Ziel. Um den Umfang möglichst klein zu halten, werde ich hier die Technik hinter den Funktion nur grundlegend andeuten. Wer genauer verstehen möchte warum und wieso, dem empfehle ich im Anhang bei den Referenzen nachzuschauen. Diese Anleitung könnt ihr als eine Art Skript sehen, das ihr nur abarbeiten müsst.

6. Allgemeiner Haftungsausschluss

Es gibt immer ein Risiko sobald man auf seinem Node zusätzlich Software installiert oder Anpassungen vornimmt. Die Funktion des Node kann gestört werden oder schlimmer noch, man baut sich Türen und Tore in seinen Schutzwall, die von Angreifern ausgenutzt werden können.

LNbits benötigt den Admin Macaroon des Nodes oder Wallets, also den Zugangsschlüssel zu euren Gelder, um Zahlungen senden und empfangen zu können. Der VPS könnte beispielsweise gehackt werden und jemand bekommt Zugriff auf den Macaroon. Auch ist euer Node ein Hot- bzw. ein Softwallet. Umso mehr ihr den Node exponiert, umso höher das Risiko. In diesem Tutorial werden einige Sicherheitsfeatures mit aufgenommen, das Risiko wird möglichst minimiert, es ist aber eben nicht Null. Also überlegt gut, ob ihr euren Node diesem Risiko aussetzen wollt. Überlegt, welche Optionen ihr habt, um das System zu härten und das Risiko weiter zu minimieren oder den möglichen Schaden zu begrenzen.

Auch habe ich diese Anleitung nach besten Wissen und Gewissen geschrieben. Ich habe sie mehrfach getestet und bei mir hat sie funktioniert. Ich kann aber nicht garantieren, dass ich keine Fehler übersehen habe oder bei euren Systemen sich nicht doch etwas unvorhergesehenes einstellt. Bitte seht mir nach, dass ich dafür keine Garantie oder Gewähr übernehmen kann

Noch ein Hinweis zur Lizenz & Copyright. Alles wird unter der MIT Lizenz veröffentlicht. Wer möchte, kann Teile oder den gesamten Artikel kopieren, ändern und weiter verbreiten, auch unter seinem Name. Ich übernehme aber keine Haftung oder Garantie. Und ich würde mich natürlich freuen, wenn ihr auf dieses Tutorial verweist.

7. Der Aufbau eines LNbits Server

Das Tutorial verwendet als Grundlage einen Raspiblitz v1.8.x mit LND Node v0.15.5. Mit einem Umbrel v0.5.x hist dies ebenfalls möglich, im Anhang findet ihr dafür eine "Pfad und Befehle Referenztabelle". Mit einem Citadel und einem Core Lightning Node sollte dies bei entsprechender Anpassung ebenfalls funktionieren.

Tipps und Hinweise zur Verwendung des Tutorial:

• Wer mit Linux noch nicht so 100% vertraut ist, dem empfehle ich sich das "The Linux command line for beginners" Tutorial einmal anzuschauen. Ein wirklich gut geschriebenes Tutorial, um die Grundlagen einmal aufzufrischen.
• Üblicherweise wird vor einem Befehl ein $ Zeichen geschrieben. Damit die Befehle besser kopiert werden können, habe ich hier meistens drauf verzichtet. Allerdings habe ich in der Befehlszeile teilweise Kommentare mit eingebracht. Die sind dann mit der Raute # gekennzeichnet. Alles was dahinter steht, ist nur Information und kein Teil des Befehls.
• Die IP-Adresse eures VPS wird in diesem Dokument mit 111.111.111.111 dargestellt. Tauscht sie mit eurer Eigenen aus.
• Ich empfehle jedem, sich an ein Mehrfenster System zu gewöhnen, da man doch viel zwischen den Fenstern wechselt muss um etwas nachzusehen oder zu kopieren. Am besten zwei Monitore verwenden und/oder das Fenster aufteilen. Bei Windows wird dies ermöglicht durch Drücken der Windows Taste und gleichzeitiger Verwendung der Pfeiltasten.
• Gute Praxis ist es bei Virtual Private Server (VPS) die Verwendung von Authentifizierungen per SSH-Schlüssel mit Passphrasen. Einfache Logins mit einem Passwort können prinzipiell per Brute-Force geknackt werden. Die Handhabung der SSH-Schlüssel ist nicht immer ganz einfach, deswegen verwende ich für dieses Tutorial den Login per Passwort. Wenn ihr nicht geübt seid, in der Verwendung mit SSH-Schlüssel, dann verwendet für diese Tutorial lieber ein langes und wildes Passwort mit vielen Sonderzeichen. Das Passwort solltet ihr euch nicht merken können und ihr müsst es immer per copy & paste oder Passwortmanager einfügen. Wer aber die gut Praxis erlernen möchte, dem kann ich diesen Artikel empfehlen. Ansonsten habe ich auch im Anhang unter 9.9.10 Den Server mit SSH Keys absichern noch ein Kapitel angehängt, in dem ich beschreibe, wie man das auch nachträglich einrichten kann.
• Ich kann ebenfalls nur empfehlen, für dieses Tutorial ein digitales Notizbuch anzulegen, wo ihr eure Bemerkungen, Shortcuts und vor allem Passwört ablegen könnt. Ihr braucht den Login, die IP und vor allem die Passwörter mehrmals im Verlauf. Bitte verwendet keine klassischen Dienstleister wie Google oder Apple für euer digitales Notizbuch, sondern einen anderen Anbieter, der Open Source ist, eure Daten mit starker Kryptographie Ende-zu-Ende verschlüsselt und damit sichert ist. Wie z.B. standardnotes.com. Die kostenlose Version ist auch vollkommen ausreichend. Beispielhaft hier mal eine digitale Notiz, wie sie aussehen könnte. Daraus könnt ihr dann recht komfortabel mit copy & paste arbeiten.

  Und jetzt wünsche ich viel Spaß und vor allem Erfolg!

7.1 – Allgemein – Einrichten eines Virtual Private Server (VPS)

Das erste was ihr braucht, ist ein Virtual Private Servers (VPS). Es muss kein sehr leistungsstarker sein. Jedoch mindestens 1 GB RAM und die Linux-Distribution Ubuntu (LTS) v22.04 als Betriebssystem verwenden. Der kostet ca. $6 im Monat und alles Weitere könnte ihr später bei Bedarf aufrüsten, wenn ihr es braucht. Gegebenfalls habt ihr auch schon einen Anbieter für Managed Server bzw. Cloud Hosting. Er sollte nur Ubuntu v22.04 anbieten, für volle Kompatibilität mit dieser Anleitung.

Wenn ihr noch keine Präferenz habt, dann schaut euch ruhig mal digitalocean.com (Affiliate-Link) an. Ich bin damit ganz zufrieden. Fairer Preis, technisch einwandfrei und sie haben sehr gute Tutorials. Aktuell haben sie auch ein Angebot, dass uns beiden ein kleinen Bonus bringt. Du bekommst $200 Guthaben für die ersten 60 Tage und kannst alles ausprobieren. Und wenn du am Ball bleibst und sich deinen Zahlungen irgendwann mal auf $25 angehäuft haben, dann bekomme ich einmalig $25 für meinen Account gutgeschrieben. Du kannst aber natürlich auch jede andere Alternative verwenden.

Die Einrichtung und Installation beschreibe ich am besten anhand ein paar Bildern die hoffentlich selbsterklärend sind. Im ersten Augenblick ist die Oberfläche etwas gewöhnungsbedürftig. Ihr müsst zuerst ein neues Projekt anlegen und dann bei Welcome to DigitalOcean! auf Spin up Droplet klicken, um ein Droplet, also einen Virtual Private Server (VPS), einzurichten. Alles weitere zeigen die Bilder. Wählt die Region die euch am nächsten kommt, Ubuntu als Betriebssystem, Shared CPU Basic, die reguläre CPU und bei der Authentifizierungsmethode habt ihr die Wahl. Wenn ihr euch mit SSH Keys auskennt, wählt euch dies aus. Es ist die sicherste, aber nicht unbedingt einfachst Methode. Wenn ihr euch nicht sicher seid, wählt lieber ein sehr starkes Passwort. Das kostenlose Monitoring aktiveren, denn es verschafft später eine gute Übersicht über den Zustand und die verwendeten Ressourcen des VPS. Dann noch einen Hostname eurer Wahl vergeben und Create Droplet anwählen. Das war es schon. Jetzt habt ihr einen eingenen Virtual Private Server.

Das letzte Bild zeigt wie ihr ein Snapshot eures VPS, also ein Backup des aktuellen Zustands machen könnt. Fahrt hierzu zuvor euren VPS herunter, damit ihr einen sauberen Backup eines ruhenden Systems bekommt.

7.2 – VPS – Grundeinstellungen des Virtual Private Server

Jetzt gehts los! Als erstes meldet ihr euch an und führt ein paar grundlegende Einstellungen durch. Da man in diesem Tutorial oft von dem VPS und dann wieder auf den Node springen muss, habe ich in der Überschrift immer als erstes vermerkt, wo die Anpassungen gemacht werden müssen. VPS, Node oder eben Allgemein.

Meldet Euch auf dem VPS mit eurem "root" Nutzer an

ssh root@111.111.111.111

Update und Upgrade durchführen

apt update && apt upgrade -y

-> Wenn ihr mal beim Update gefragt werden, ENTER drücken

UncomplicatedFirewall (UFW) installieren und einrichten

apt install ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22 comment 'OpenSSH'
ufw allow 80 comment 'Standard Webserver'
ufw allow 443 comment 'SSL Webserver'
ufw allow 9735 comment 'Node1' 
ufw enable   # -> y
ufw status   # -> Kontrollieren ob OpenSSH bzw. 22/tcp drin ist!

SWAP (Swap Speicher für den Fall eines RAM-Speicher Überlaufs einrichten)

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
swapon -s

Sicherstellen das der SWAP Speicher auch nach einem Neustart gestartet wird

sudo nano /etc/fstab

• -> In dem sich öffnenden Editor, an das Ende, folgende Zeilen anfügen

# For persist SWAP through reboot
/swapfile swap swap defaults 0 0

• -> Speichern und schließen mit STRG+x -> y -> ENTER

Mit HTOP prüfen ob eine 2GB SWAP eingerichtet wurde

htop

• -> Prüfen ob under CPU/Mem/Swp ein 2GB Swap eingerichtet wurde
• -> htop mit F10 verlassen
• -> Falls htop noch nicht installiert war: $ sudo apt install htop

Fail2ban (Schützt vor Brute-Force-Angriffe)

apt install fail2ban -y   # 2x ENTER drücken
systemctl enable fail2ban
systemctl start fail2ban
systemctl status fail2ban

Zur Info, die Standard Einstellung sind:

bantime  = 10m   ("bantime" is the number of minutes that a host is banned.)
findtime  = 10m   (A host is banned if it has generated "maxretry" during the last "findtime")
maxretry = 5   ("maxretry" is the number of failures before a host get banned.)

Den neuen Benutzer synonym anlegen und root-Rechte vergeben

adduser synonym   # -> sehr gutes Passwort vergeben, 5x ENTER, y
usermod -aG sudo synonym

Hinweis: Ihr könnt den Benutzer natürlich anpassen. Er wird in diesem Tutorial aber sehr oft und auch in Pfaden verwendet. Das Anpassen ist dadurch viel Arbeit und führt ggf. zu Fehlerquellen, passt also auf.

Empfehlung: Jetzt ein Snapshot des VPS machen

systemctl poweroff

• Snapshot erstellen in DigitalOceans unter: Projects/my-project/droplet/Snapshots.
• Wenn der Snapshot erstellt wurde, den Turn on Button des VPS drücken.
• Damit für habt ihr eine sehr gute Grundlage für einen späteren Neuanfang.

Ab jetzt loggt euch nur noch mit eurem neuen Benutzer ein!

ssh synonym@111.111.111.111

Ab jetzt werdet wir oft den Befehl sudo vorschreiben, um unserem User Administrator Rechte zu vergeben. Ihr werdet dann auch oft nach dem User Passwort gefragt.

7.3 – VPS – Docker installieren und einrichten

Docker installieren

sudo apt-get install docker.io tmux -y
sudo systemctl status docker.service

-> Quit -> q

Einen Namen für den Datenvolumencontainer vergeben

export OVPN_DATA="ovpn-data" 

-> Weist der Globalen Variable OVPN_DATA den Inhalt ovpn-data zu

Um den Name auch nach einen Neustart verfügbar zu machen

nano .bashrc

-> An das Ende export OVPN_DATA="ovpn-data" anhängen. -> STRG+x -> y -> Enter zum speichern und schließen des Editors

Docker Container erschaffen

sudo docker volume create --name $OVPN_DATA 

Initialisieren des Container

Achtung: IP anpassen!

sudo docker run -v $OVPN_DATA:/etc/openvpn --rm kylemanna/openvpn ovpn_genconfig -u udp://111.111.111.111
sudo docker run -v $OVPN_DATA:/etc/openvpn --rm -it kylemanna/openvpn ovpn_initpki 

Der Container fordert zur Eingabe einer CA Key Passphrase auf, um den privaten Schlüssel zu schützen, der von der neu generierten Zertifizierungsstelle verwendet wird. Zusätzlich muss noch einen Common Name (z.B. "myvps") vergeben und anschließend zwei mal mit der CA Key Passphrase bestätigt werden.

Hinweis: Der Container enthält die Konfigurationsdateien und Zertifikate. Die Zertifikate haben einen Gültigkeit von 825 Tage.

Starten des OpenVPN-Serverprozess

sudo docker run -v $OVPN_DATA:/etc/openvpn -d -p 1194:1194/udp -p 9735:9735 -p 8080:8080 --cap-add=NET_ADMIN --restart unless-stopped kylemanna/openvpn

Hinweis: Der Port 8080 ist für die LNbits REST API von Node 1. Wenn ihr zwei Nodes mit einem VPS tunneln wollt, so könnte ihr die Zeile oben mit Port 9736 (LND) und Port 8081 (REST) für einen zweiten Node erweitern. Eine genauere Beschreibung im Anhang unter Sonstiges, Kapitel "Mehrere Nodes auf einem Virtual Privat Server".

Generieren eines Client-Zertifikat ohne Passphrase für node1

sudo docker run -v $OVPN_DATA:/etc/openvpn --rm -it kylemanna/openvpn easyrsa build-client-full node1 nopass

-> Einmal mit der CA Key Passphrase bestätigen

Hinweis: Für einen zweiten Node müsste diese und nachfolgend Zeile anpassen und wiederholen.

Client Konfiguration mit eingebetteten Zertifikaten für node1abrufen__

sudo docker run -v $OVPN_DATA:/etc/openvpn --rm kylemanna/openvpn ovpn_getclient node1 > node1.ovpn  

Dem VPN Tunnel eine fest IP zuweisen

sudo su
nano /var/lib/docker/volumes/ovpn-data/_data/ccd/node1

• mit folgendem Inhalt füllen: ifconfig-push 192.168.255.6 192.168.255.5
• STRG-x -> y -> ENTER
• Server jetzt am besten einmal neu Starten $ reboot und neu einloggen.
• Jetzt hat die Node immer die 192.168.255.6 und der Server diesen Tunnel die .5

Hinweis: Nach dem ihr auf der Node OpenVPN installiert und eingerichtet habt, könnt ihr dort mit dem Befehl $ ip add show tun0 prüfen, ob ihr auch die richtige IP vergeben bekommen habt.

Den Pfad zur node1.ovpn Datei anzeigen lassen und merken

ls   # -> Sollte jetzt die Datei node1.ovpn anzeigen
pwd   # -> Zeigt den aktuellen Pfad

Die Container ID anzeigen lassen und merken

sudo docker ps   # -> zeigt den Status, die ID des Container und die Ports

Einmal die Docker Shell aufrufen

Achtung: Vorher die Docker ID anpassen

sudo docker exec -it b7a78bb8b394 sh

Die Netzwerk Adapter des Docker anzeigen lassen

ifconfig

Unter eth0 sollte ihr die IP = 172.17.0.2 sehen, das ist die IP des Docker Anschluss

Docker Shell verlassen

exit

Docker Einstellungen einmal kontrollieren

sudo systemctl status docker.service   # -> q

7.4 – Node – OpenVPN einrichten

Auf den Node einloggen

ssh admin@192.168.x.x

-> Auf dem Raspiblitz im Menü auf Exit um in die Kommandozeile zu gelangen

VPNcert Ordner erstellen

pwd   # -> Zeigt den aktuellen Pfad an
mkdir VPNcert   # -> Ein VPNcert Verzeichnis anlegen

Das OpenVPN Zertifikat von dem VPS herunterladen

Achtung: IP und ggf. die Pfade anpassen

scp synonym@111.111.111.111:/home/synonym/node1.ovpn /home/admin/VPNcert/

Ihr müsst den neuen "Fingerprint" einmal bestätigen und dann euer User Passwort eingeben

Schreib- und Leserechte auf den aktuellen Benutzer einschränken

sudo chmod 600 /home/admin/VPNcert/node1.ovpn

OpenVPN installieren und einrichten

Achtung: Auch hier ggf. den Pfad und Datei Name anpassen

sudo apt-get install openvpn -y
sudo cp -p /home/admin/VPNcert/node1.ovpn /etc/openvpn/CERT.conf
sudo systemctl enable openvpn@CERT
sudo systemctl start openvpn@CERT
sudo systemctl status openvpn@CERT 

Achtet auf auf folgende Zeilen:

..
net_iface_up: set tun0 up
net_addr_ptp_v4_add: 192.168.255.6 peer 192.168.255.5 dev tun0
..

• Exit mit q
• Die IP = 192.168.255.6 ist die vom Tunnel bereit gestellt Client IP für den ersten Node. Wenn ihr einen weiteren Node hinzufügt, kann das z.B. die IP 192.168.255.10 sein. Mehr dazu im Anhang unter Sonstiges, Kapitel "Mehrere Nodes auf einem Virtual Privat Server".

Hinweis: Mit dem Befehl $ ip add show tun0 könnt ihr euch auch nachträglich die IP anzeigen lassen.

Verbindungstest

ip route get 8.8.8.8

-> Ihr sollte 8.8.8.8 via 192.168.255.5 dev tun0 src 192.168.255.6 zurück bekommen

Prüfung ob ihr Google durch den Tunnel erreichen könnt

ping -c 3 google.com

Abfrage der Log Dateien, zur Anzeige der letzten Meldungen

sudo journalctl -u openvpn@CERT -f --since "1 hour ago" 

-> STRG+c

7.5 – VPS – Paketregeln für den Docker festlegen

Docker Shell aufrufen

sudo docker ps   # -> nochmal die ID anzeigen lassen
sudo docker exec -it 8c5c4bf6c634 sh   # -> Shell starten

Info: Ein alternativer Befehl ist $ sudo docker container ls. Mit dem leicht erweiterten Befehl $ sudo docker ps -a, könnt ihr auch nicht gestartet Container und deren Status einsehen.

Im Docker die Paketregeln für die Firewall festlegen

Achtung: Denk daran die IP (siehe voriges Kapitel) und die Ports zu prüfen

iptables -A PREROUTING -t nat -i eth0 -p tcp -m tcp --dport 9735 -j DNAT --to 192.168.255.6:9735
iptables -A PREROUTING -t nat -i eth0 -p tcp -m tcp --dport 8080 -j DNAT --to 192.168.255.6:8080
iptables -t nat -A POSTROUTING -d 192.168.255.0/24 -o tun0 -j MASQUERADE

Hinweis: Wenn ihr mehr als nur einen Node über den gleichen VPS laufenlassen möchtet, müsst ihr erst für jeden Node eine feste IP vergeben und iptables um die Zeilen erweitern. Ein Beispiel Auszug für z.B. drei Nodes findet ihr im Anhang unter Sonstiges.

Die Regel dauerhaft speichern

Damit die Paketregeln auch nach dem nächsten Neustart geladen werden, bleiben wir in der Docker Shell und müssen noch die Skript Datei ovpn_env.sh editieren.

cd /etc/openvpn
vi ovpn_env.sh   # -> Editor öffnet

Es wurde jetzt der vi-Editor geöffnet. Die Befehle und Bedienung ist etwas ungewöhnlich, aber wenn ihr genau die Schritte befolgt, solltet ihr zum Ziel kommen. Ein Befehlsübersicht findet ihr sonst hier.

Zur Übung, verlasst den Editor gleich wieder:

• ESC -> :q! -> ENTER -> Exit ohne speichern
• Das :q! müsst ihr wirklich so eingeben

Jetzt öffnet den Editor erneut:

• vi ovpn_env.sh
• setzte den Cursor zur letzten Linie -> G (=> großes "G" -> Shift+g)
• geht in den Editiermodus -> a (kleines "a")
• eine Zeile umschlagen -> ENTER
• jetzt die drei "iptabels" Zeile von oben hineinkopieren
• ESC -> Editiermodus verlassen
• :wq -> Änderungen speichern und schließen

Wenn ihr fertig seid, verlasst auch die Docker Shell wieder:

exit

7.6 – Node – Die lnd.conf anpassen

Achtung: Die Datei lnd.conf ist das Herzstück eures Lightning Node. Wenn ihr da Fehler macht, könnt ihr euren Node lahm legen. Passt also auf was ihr tut und macht vorher ein Backup. Verlasst den Editor lieber mal mit STRG-x -> n -> ENTER, als das ihr etwas falsches abspeichert.

Backup der LND.conf erstellen

cd /mnt/hdd/lnd/
sudo cp lnd.conf lnd.conf.backup
ls -l   # -> Backup Datum prüfen

LND.conf editieren

sudo nano lnd.conf
# direkt: sudo nano /mnt/hdd/lnd/lnd.conf

Folgende Zeilen überprüfen und ggf. anpassen:

[Application Options]
..
nat=false   # -> prüfen und auf "false" stellen
listen=0.0.0.0:9735   # -> prüfen
restlisten=0.0.0.0:8080   # -> prüfen
externalip=111.111.111.111:9735
tlsextraip=172.17.0.2
..
[tor]
..
tor.streamisolation=false
tor.skip-proxy-for-clearnet-targets=true

• Passt auf das ihr keine Doppelbelegung mit widersprüchlichen Werten habt
• Funfact: Im Anhang zeige ich euch wie ihr hier den Alias Namen noch etwas "tunen" könntet. 😉
• STRG+x -> y -> ENTER

Hinweis: Wer die Einstellungen noch etwas genauer verstehen möchte, der schaue hier.

Besonderheit: NUR beim Raspiblitz

Das lnd_check.sh Skript überprüft die lnd.conf und kann beim Start des LND eure Einstellungen überschreiben. Deswegen müsste ihr hier ein paar Zeile auskommentieren, damit das nicht passiert.

Ruft in dem Skript die Zeilen ab 184 auf:

sudo nano +184 /home/admin/config.scripts/lnd.check.sh

Kommentiert folgende Zeile mit # aus:

#  # enforce PublicIP if (if not running Tor)
#  if [ "${runBehindTor}" != "on" ]; then
#    setting ${lndConfFile} ${insertLine} "externalip" "${publicIP}:${lndPort}"
#  else
#    # when running Tor a public ip can make startup problems - so remove
#    sed -i '/^externalip=*/d' ${lndConfFile}
#  fi

-> Speichern und schließen mit STRG+x -> y -> ENTER

Hinweis 1: Etwas weiter oben steht auch # enforce LND port is set correctly. Falls ihr einen anderen Port als 9735 für LND verwendet, muss diese Zeilen auch deaktivieren bzw. angepasst werden. Das gleiche gilt für den REST API Port 8080, den findet ihr noch einen weiter drüber bei # make sure API ports are set to standard.

Hinweis 2: Ihr könnt Bitcoin Core, LND und andere Applikationen manuell updaten, aber ein komplettes Update eures Node, auf eine neue Version, wird wahrscheinlich genau diese Datei überschrieben und euer Node läuft dann nur noch über TOR! Und wenn ihr mehrere Nodes über den VPS laufen habt, oder generell induviduelle Ports vergeben habt, wird bei den Nodes, die einen anderen LND-Port als 9735 bzw. REST-Port als 8080 haben, die LND.conf automatisch überschrieben. Der Node funktioniert zwar noch, aber nur über TOR und die LNbits Logs zeigen Retrying connection to backend in 5 seconds... | The backend for LndRestWallet isn't working properly. Behaltet das also im Hinterkopf, das ist ein heimtückischer Fehler. Ob die Port frei sind, könnte ihr z.B. hiermit testen.

Den LND einmal neu starten

sudo systemctl restart lnd.service 

-> Beide Befehle können etwas dauern, habt Geduld

Prüfen ob sich das Zertifikat und der Schlüssel geändert hat

ls -l 

-> Datum und Uhrzeit (GTM) der tls.cert und tls.key prüfen. Die Dateien müss sich aktualisiert haben, sofern ihr eine Änderung an tlsextraip oder tlsextradomain vorgenommen habt.

Verbindungstest

Testet mal ob ihr den Google Server erreichen könnt:

ip route get 8.8.8.8

-> Ihr sollte 8.8.8.8 via 192.168.255.5 dev tun0 src 192.168.255.6 zurück bekommen

Jetzt nochmal den VPS Docker anpingen:

ping 172.17.0.1

-> Abbruch mit STRG-c

Wenn alles gut aussieht, dann ist euer Node ab jetzt im Clearnet erreichbar! 🎉

7.7 – Allgemein – Überprüfen der Verbindung

Hier zeige ich jetzt verschiedenen Möglichkeiten auf, wie ihr nachprüfen könnt, ob euer Node auch wirklich aus dem Clearnet erreichbar ist.

Beim Raspiblitz ist es ganz einfach, schaut im Status Screen

Unten hinter der Node ID sollte jetzt die IP-Adresse des VPS anstatt der ".onion" angezeigt werden. Keine Sorge, die Onion Verbindung funktionieren weiterhin.

LND Informationen anzeigen lassen

lncli getinfo

• Unter uris: seht ihr jetzt beide Verbindungsöglichkeiten eures Node
• Einmal die Tor Onion und jetzt neue die Clearnet IP Adresse

Überprüfung mit externen Dienste

Durch das Gossip Protocol des Lightning Netzwerks werden eure neuen Verbindungsdaten geteilt. Die Verbreitung der neuen Verbindung kann aber ein paar Stunden beanspruchen, je nachdem wie gut euer Node vernetzt ist. Habt also Geduld! Nutzt folgende Dienste und sucht nach eurem Node Alias Namen oder der Node ID.

https://1ml.com/

https://amboss.space/

https://lightningnetwork.plus/

https://lnrouter.app/

Dort solltet ihr als Server Standort z.B. Frankfurt am Main und/oder die IP Adresse eures Virtual Privat Server.

Info: Eine weitere Möglichkeit zum Testen der Verbindung ist die Nutzung des “Telegram Ping Bot”. Schaut dazu mal im Anhang unter Sonstiges.

7.8 – Node – LND Zertfikat und Macaroon für LNbits bereitstellen

Das LND Zertifikat zum VPS übertragen

Achtung: Prüft den Pfade, die IP und den Username

scp /mnt/hdd/lnd/tls.cert synonym@111.111.111.111:/home/synonym

-> Den Transfer mit dem Passwort der VPS bestätigen

Als nächste den Admin Macaroon des LND auslesen

Achtung: Das ist euer Admin API Key für das LND Wallet, bitte sehr vertraulich behandeln!

xxd -ps -u -C ~/.lnd/data/chain/bitcoin/mainnet/admin.macaroon

Ihr solltet jetzt eine langen Code sehen, den ihr nachher in die Setup Datei ".env" auf eurem VPS im LNbits Ordner kopiert. Achtung:, der Macaroon ist der Schlüssel zu eurem LND und damit zu euren Geldern. Passt gut drauf auf!

Tipp1: Kopiert euch den HexString in ein temporäres Notepad Fenster und nehmt vorsichtig die Zeilenumbrüche raus. Wenn ihr das nicht tut, kann das Macaroon von LNbits evtl. falsch interpretiert werden und ihr bekommt keine Verbindung zum LND.

Tipp2: Alternativ, könnt ihr auch den ganzen Macaroon zum VPS kopieren und in der .envDatei einfach nur verlinkt. Bei Umbrel ist das sogar notwendig.

scp ~/.lnd/data/chain/bitcoin/mainnet/admin.macaroon synonym@111.111.111.111:/home/synonym

7.9 – VPS – LNbits installieren und einrichten

Prüfen ob das Zertifikat und der Macaroon übertragen wurde

ls -l

Prüfen ob die SSL Verbindung zum Node steht

curl https://172.17.0.2:8080 -v --cacert /home/synonym/tls.cert 

Wenn alles geklappt hat, sollte ihr in der Ausgabe folgende Zeilen finden:

 ..
 subjectAltName: host "172.17.0.2" matched cert's IP address!
 ..
 SSL certificate verify ok.
 ..
 Connection #0 to host 172.17.0.2 left intact
 ..

LNbits clonen und Voraussetzungen installieren

cd   
git clone https://github.com/lnbits/lnbits.git
cd lnbits
sudo apt update
sudo apt install software-properties-common  
sudo add-apt-repository ppa:deadsnakes/ppa   # -> ENTER
sudo apt install python3.10
sudo apt-get -y install python3-distutils 
curl -sSL https://install.python-poetry.org | python3 -

Wichtig: Bei der Installation wird euch der "Poetry Pfad" (z.B. /home/synonym/.local/bin) angezeigt. Und darauf folgt nach "Add" ein ganzer Befehl. Das ist der Pfad für die "Poetry Umgebungsvariablen" und den müsst ihr zum bekanntgeben der globalen Variable auch einmal in das Terminal Fenster kopieren und ENTER drücken.

export PATH="/home/synonym/.local/bin:$PATH"

Die Kennzeichnung als globale Variable dauerhaft verfügbar machen

Dazu einmal die .bashrc öffnen

nano /home/synonym/.bashrc 

Und ganz am Ende folgende Zeile einfügen

export PATH="/home/synonym/.local/bin:$PATH"

-> STRG+x -> y -> ENTER

Poetry in einer virtuelle Umgebung installieren und starten

poetry env use python3.10 
poetry install --only main   # -> Das kann jetzt etwas dauert 
mkdir ~/lnbits/data  # Das wird der Ordner für die LNbits Datenbank

Hinweis: Ich hatte mal einen VPS mit 0,5 GB RAM ausprobiert. Da wurde die Installation mittendrin abgebrochen. Ich empfehle also mindestens 1 GB RAM.

Die LNbits Setup Datei .env erzeugen und bearbeiten

cd ~/lnbits  # -> Das LNbits Verzeichnis aufrufen
ls -la  # -> Zeigt euch alle Dateien an
cp .env.example .env   # -> Die .env aus dem Example erstellen
nano .env   # -> Datei zum editieren öffnen

Vorzunehmende Einstellungen in der .env Datei:

..
# Choose from LN..
LNBITS_BACKEND_WALLET_CLASS=LndRestWallet
..
# LndRestWallet
LND_REST_ENDPOINT=https://172.17.0.2:8080/
LND_REST_CERT=/home/synonym/tls.cert
LND_REST_MACAROON=0201036C6E6...
# Alternativ: LND_REST_MACAROON=/home/synonym/admin.macaroon
..

• Hier müsst ihr wirklich sehr vorsichtig sein, kontrolliert besser alles zwei mal!
• STRG+x -> y -> ENTER

Tipp 1: Die Ausrufezeichen "" hinter den Einträgen LND_REST_CERT= und LND_REST_MACAROON= sind zwar in der .env.example drin, die haben bei mir aber immer Ärger gemacht. Lasst sie also besser weg.

Tipp 2: Falls ihr noch keine Node habt, oder eure Node mal ausfällt, könnt ihr hier auch schnell mal eine andere Finanzierungsquelle hinterlegen, damit euer LNbits weiter liquide ist. Dazu einfach in der .env unter LNBITS_BACKEND_WALLET_CLASS das passende Wallet eintragen. Und etwas weiter unten, den Admin Key und den Endpoint eintragen. Beim LightningTipBot (LnTipsWallet) bekommt ihr den API Key z.B. mit dem Befehl /api und der Endpoint ist https://ln.tips. Und bei einem Custody LNbits Wallet vom z.B. dem legend-lnbits.com Demo Server (LnbitsWallet) ist LNBITS_ENDPOINT = https://legend.lnbits.com und LNBITS_KEY = LNBITS_ADMIN_KEY = im Wallet der Admin key unter API Info.

Ein Testlauf durchführen

Stellt sicher das im ihm Verzeichnis lnbits seit und dann startet eine LNbits Instanz

poetry run lnbits   # Exit -> STRG-c

Wenn euch Backend LndRestWallet connected und eure Wallet Balance angezeigt wird, Glückwunsch, habt ihr gewonnen! 🔥

Falls Ihr Retrying connection to backend in 5 seconds... seht, stimmt etwas mit der Verbindung zu eurem Funding Source (LND Wallet) nicht. Prüft die .env Konfigurationsdatei und speziell die LND_REST_MACAROON, LND_REST_CERT und den LND_REST_ENDPOINT.

Tipp: Wenn ihr meint dass alles stimmt und es trotzdem nicht geht und ihr den "Macaroon HexString" verwendet habt, dann probiert mal den admin.macaroon direkt zu verwenden, in dem ihr in der .env nur ein Link auf die Datei setzt. Beim Umbrel hatte ich mal das Problem, der "Macaroon HexString" wollte partout nicht funktionieren. Erst als ich den Macaroon direkt verwendet habe, wurde die Verbindung herstellt. Wie ihr den admin.macaroon zu eurem VPS kopiert, das habe ich am Ende des vorherigen Kapitel beschrieben. In der .env Datei verlinken könnt ihr ihn dann z.B. mit LND_REST_MACAROON=/home/synonym/admin.macaroon.

Option: Die LNbits Seite temporär anzeigen lassen

Wollt ihr Eure LNbits Webserver schon einmal sehen, müsst ihr jetzt erstmal den Port 9000 temporär freigeben.

sudo ufw allow 9000 comment 'LNbits Test' 

Jetzt könnt ihr LNbits eure Standard-Route 0.0.0.0 auf Port 9000 zuweisen:

poetry run lnbits --port 9000 --host 0.0.0.0

Hinweis: Der Befehl funktioniert nur aus dem LNbits Verzeichnis lnbits

Und jetzt öffnet einem Webbrowser und gebt die IP eurer VPS mit dem Port 9000 ein:

111.111.111.111:9000

-> Et volia, euer LNbits! 👀

Die Anfrage IP:Port wurde auf die Standard-Route 0.0.0.0 des VPS verwiesen. Dort lag die Webseite der LNbits Instanz. Euer Browser hat euch sicherlich gewarnt, dass die Seite nicht sicher sei. Das ist aber normal, da die Seite kein gültiges SSL/TLS-Zertifikat hat. Der Punkt kommt später beim Webserver, nachdem wir eine Domain eingerichtet haben und die dann durch einen Domain-Namen-System (DNS) Eintrag auf die IP-Adresse unserer VPS zeigt. Dann können wir für die Verbindung ein Zertifikat für HTTPS (Hyper Text Transfer Protocol Secure) beantragen.

-> Beendet LNbits wieder mit STRG+c

Schließt den temporären Port 9000 wieder und prüft die Einstellung der UFW einmal

sudo ufw deny 9000
sudo ufw status

Empfehlung: OpenSSL Anpassung für die Erweiterung Onchain Wallets

LNbits verwendet in der Erweiterung Onchain Wallets einen bestimmen Hash Algorithmus (ripemd160). In der hier verwendeten Python Version 3.10 verwendet der Befehl "Hashlib" die Softwarebibliothek Open SSL. Die Bibliothek wurde Nov. 2021 aktualisiert und unterstützt den verwendeten Hash Algorithmus ripemd160 nicht standardmäßig. Es ist aber möglich diese Funktion in einer Konfigurationsdatei für OpenSSL wieder zu aktivieren. Das müssen wir jetzt einmal machen, damit wir die Erweiterung Onchain Wallets auch verwenden können. Ruft als erste die Datei openssl.cnf auf.

sudo nano /usr/lib/ssl/openssl.cnf

Kontrolliert das Vorhandensein und erweitert ggf. folgende Zeilen:

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

-> STRG+x -> y -> ENTER

Weiter Infos zu diesem Problem und der Lösung findet ihr hier.

Hinweis: LNbits Debug Modus aktiveren

Solltet ihr einen Fehler beim Starten von LNbits bekommen, den ihr so nicht lösen könnt, dann könnt ihr mal Debug einschalten. Dazu öffnet die .env Datei und -> setzt DEBUG=true und dann startet LNbits im Debug Modus.

$ poetry run lnbits --debug

7.10 – VPS – LNbits Autostart einrichten

Den "Poetry Pfad" einmal prüfen

which poetry

-> Wenn ihr den gleichen User verwendet habt: /home/synonym/.local/bin/poetry

Kontrolliert nachfolgend in der lnbits.service Datei, dass der Pfad auch stimmt.

Die lnbits.service Datei erstellen

sudo nano /etc/systemd/system/lnbits.service

Die lnbits.service Datei befüllen mit:

# Systemd unit for lnbits
# /etc/systemd/system/lnbits.service 

[Unit]
Description=LNbits

[Service]
# replace with the absolute path of your lnbits installation
WorkingDirectory=/home/synonym/lnbits
ExecStart=/home/synonym/.local/bin/poetry run lnbits --port 5000
User=synonym
Restart=always
TimeoutSec=120
RestartSec=30
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

-> Kontrolliert den Poetry Pfad (ExecStart), User und WorkingDirectory

-> Dann STRG+x -> y -> ENTER

Service starten und prüfen

sudo systemctl enable lnbits.service
sudo systemctl start lnbits.service
sudo systemctl status lnbits.service  # -> q

-> Ihr solltet ein active (running) und ein Backend LndRestWallet connected als Rückmeldung bekommen

Tipp: Mit den Befehl $ sudo systemctl restart lnbits.service könnt ihr LNbits neu starten, falls ihr mal eine Änderung in der LNbits Konfigurationsdatei .env vorgenommen habt und die übernommen werden soll.

7.11 – Allgemein – Eine Domain für euren LNbits Server

Glückwunsch, dass ihr es bis hier hin geschafft habt, das ist schon mal eine gute Leistung. Ihr habt jetzt einen eigenen Virtual Privat Server mit VPN Tunnel zum Node aufzusetzen, damit euer Node vom Clearnet aus erreichbar ist. Ihr habt auch LNbits über den VPN Tunnel mit euren Lightning Node verbunden, das schon mal echt klasse! 🤜🤛

Was jetzt aber noch fehlt, ist der Schritt euer LNbits auch aus dem Clearnet erreichbar zu machen und das ist schon wieder eine kleine eigene Welt, die Welt des Webhosting, der Domains, der Zertifikate und die der Webserver.

Wer schon eine eigene Webdomain hat, der kann für die Domain (oder Subdomain) unter DNS / Nameservers einen DNS Eintrag Typ A auf die IP-Adresse des VPS einstellen. Damit werden alle Anfragen an die (Sub)Domain direkt auf den LNbits Server weitergeleitet. Hinweis, evtl. müsst ihr die automatische SSL Zertifizierung für die (Sub)Domain eures Hostanbieter abschalten. Das machen wir nachher selbst.

Wer noch keine eigenen Domain hat, der kann eine kostenlosen Subdomain von z.B. DuckDNS.org bekommen. Das Einrichten ist nicht sehr schwer:

• Geht dazu auf die Seite duckdns.org
• Registriert euch mit einer der vielen Möglichkeiten
• Wählt eine subdomain.duckdsn.org
• Stellt die IP-Adresse eurer VPS für die Weiterleitung ein

Ab jetzt werden alle Anfragen die ihr an die Domain schickt automatisch an euren VPS weitergeleitet.

7.12 – VPS – Caddy Webserver einrichten

Caddy ist ein Open-Source-Webserver mit automatischer HTTPS Zertifizierung und beamt das Web Interface deiner LNbits Instanz ins Clearnet. Es kümmert sich wirklich sehr effizient um alles, auch um die Zertifikate und Aktualisierung. Man muss nur den DNS Eintrag der (Sub)Domain auf die IP-Adresse der VPS zeigen lassen, das wurde im vorherigen Abschnitt ja als DNS Eintrag Typ A beschrieben, den Rest übernimmt Caddy.

Vorab: DNS Eintrag prüfen

Prüft vorher mal ob der DNS Eintrag auch funktioniert und die Webdomain direkt zur IP-Adresse eures VPS weiterleitet wird. Mit DNS Lookup oder whatsmydns.net. Denkt daran, dass die Aktualisierung ein paar Stunden dauern kann und dann installiert Caddy.

Caddy installieren

cd ~
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Den Caddyfile anlegen

sudo caddy stop
sudo nano /etc/caddy/Caddyfile

Hinweis: Die Datei ist mit default Werte gefüllt, die könnt ihr löschen

Den Caddyfile jetzt mit diesen Abschnitt füllen

Achtung: Die Domain Adresse lnbitshero.duckdns.org vorher für euch anpassen

lnbitshero.duckdns.org {
  handle /api/v1/payments/sse* {
    reverse_proxy 0.0.0.0:5000 {
      header_up X-Forwarded-Host lnbitshero.duckdns.org
      transport http {
         keepalive off
         compression off
      }
    }
  }
  reverse_proxy 0.0.0.0:5000 {
    header_up X-Forwarded-Host lnbitshero.duckdns.org
  }
}

-> STRG+x -> y -> ENTER

Hinweis: Caddy beschafft das Zertifikat in diesem Beispiel nur für die Domain lnbitshero.duckdns.org und nicht für Subdomain www, also z.B. www.lnbitshero.duckdns.org. Wenn ihr eure Seite darüber aber auch erreichbar machen möchtet, müsst ihr einfach nur den Caddyfile mit den gleichen Zeilen erweitern und die Domain an den drei Stellen mit "www." erweiteren.

Caddy wieder starten

sudo caddy start

Et voilà, das war es! 🙂

Euer LNbits Server sollte jetzt unter eurer Webdomain erreichbar sein und hoffentlich auch funktionieren. 🚀

Falls etwas noch nicht klappt, eine Hilfe zur Fehlersuche findet ihr im Anhang.

Ansonsten noch ein letzter wichtiger Hinweis -> Die Admin UI mit dem Super User einrichten

Eure LNbits Instanz könnte ihr bequem über auch über das Web Interface bedienen. Das müsst ihr das aber zuvor aktivieren und euch den Link zu eurem Super User Account generieren. Wie das geht, das zeige ich euch im Anhang, unter Kapitel 9.9.6 Admin UI & Super User.

F e r t i g !!! 😄

8. Abschluss und Zusammenfassung

Wenn ihr hier angekommen seid, seid ihr jetzt hoffentlich stolzer Eigentümer einer weltweit erreichbaren kleinen privaten Bank, mit aufgesetztem Lightning ⚡ Technologie Hub und könnt die Zukunft mitgestalten. 🥂 Wenn man das erste mal seine eigenen LNbits Webseite im Browser sieht, ist das ein unglaublich tolles Gefühl. Die Lightning ⚡ Technologie macht uns unabhängig und wir können dank LNbits Menschen die uns Nahe stehen eine vertrauliche Umgebung für Finanztechnologien bieten und ihre Bank sein, so dass sie keinem Fremden vertrauen müssen.

"Be a bank AND marketplace for your family & friends"

Bitcoin ⚡ Lightning Netzwerk und die darauf aufbauenden Funktionen werden zweifellos die Welt revolutionieren. Es funktioniert einfach. Sicherlich gibt es noch genügend Probleme die zu lösen sind und keiner weiß wirklich wo die Reise hingeht, aber es wird vielfältig und quelloffen auf allen Ebenen daran gearbeitet. Wenn man mal über den Tellerrand hinweg schaut, dann sieht man dass Bitcoin ⚡ Lightning nicht nur ein einfaches Zahlungssystem ist, sondern es ist etwas ganz Neues. Bitcoin ⚡ Lightning ist nativ digital und der ihm innewohnende Wert, in Form von Bitcoin Satoshis, kann unglaublich gut digital verarbeitet und Prozesse hiermit automatisiert werden. Wir brauchen nicht einmal mehr einen Mittelsmann und können das beste Geld was wir haben, direkt, günstig, schnell, grenzüberschreitend und jederzeit einem anderen Menschen zukommen lassen. Das hebt uns auf ein ganz neues Level der Finanztechnologie, welches vorher so nicht möglich war.

Am 31. Oktober 2008 veröffentlichte Satoshi Nakamotor mit dem Whitepaper die Idee von Bitcoin. Am 3. Januar 2009 ließ er das Herz von Bitcoin das erste mal schlagen. 2018 kam dann das Lightning ⚡ Network hinzu und die Entwicklung nahm weiter Fahrt auf. Jetzt kommt die dritten Ebene mit LNbits als Plattform für Anwendungen. Und wahrscheinlich, wird es irgendwann auch die vierte oder fünfte Ebene geben, wer weiß das schon. Es wird sehr disruptiv, aber nicht radikal. Jeder kann mit machen, niemand muss. Aber viele monetäre Dinge werden dadurch einfacher, schneller, billiger, skalierbarer, globaler, unabhängiger, widerstandsfähiger und flexibler.

Vergesst Shitcoins und CBDC, vergesst DeFi, Web3, NFTs oder Ordinals und vergesst Metaverse. Noch leben wir in der echten Welt. Wir haben jetzt digitales Bargeld und eine Arbeitsplattform um darauf alles Mögliche zu bauen. Unser ist Geld im 21. Jahrhundert angekommen.

Mein Dank gilt natürlich wieder Ben Arc der LNbits aus der Taufe gehoben hat. Aber auch all den anderen Entwicklern die mitgeholfen haben und stetig daran arbeiten LNbits weiter wachsen zu lassen und durch die wir immer neue Funktionen dazubekommen. Da LNbits ein freies und quelloffenes Projekt ist, kann jeder hierbei mitwirken. Sei es um Code zu schreiben, einen Fehler zu melden, etwas zu testen oder vielleicht auch nur etwas Dokumention schreiben.

Insbesondere möchte ich mich natürlich auch nochmal beim TrezorHannes aka HODLmeTight bedanken, der die Grundlage für dieses Tutorial geschaffen hat. Auch er hatte sein Quellen, die wiederum den Gedanken von Free and Open Souce Software leben. Software ist Information, Information ist Wissen und Wissen muss frei sein, damit die Gesellschaft den bestmöglichen Mehrwert für alle daraus schöpfen kann.

Weitere Informationen oder Hilfe bekommt ihr hier:

• Dokumentation: LNbits Wiki
• GitHub: LNbits Github
• Telegram Chat: https://t.me/lnbits

Vielen Dank für eure Aufmerksamkeit! Ich hoffe meine Tutorial hat euch gefallen und ich konnte euch damit helfen euer eigenes LNbits zu hosten, damit ihr für die Zukunft gewappnet seid. Denn mit Bitcoin, Lightning ⚡ und LNbits, wird die Zukunft garantiert spannend!

Wenn dir mein Artikel bzw. das Tutorials gefallen hat oder es dir sogar einen Mehrwert bieten konnte, dann würde ich mich freuen, wenn du Bitcoin ⚡ Lightning nutzt und mir ein paar Satoshis als Dankeschön zukommen lässt. Möglichkeiten dazu findest du auf meiner Kontakt Seite.

Bleibt neugierig und bis zum nächsten Tutorial

Axel

9. Anhang

9.1 Tipps zur Fehlersuche

• Prüft das Zertifikat eure Domain: https://www.ssllabs.com/ssltest/. Ihr könnte auch die Seite https://www.experte.de/ssl-check verwenden. Die ist auf Deutsch und zeigt die einzelnen Sicherheitsprüfungen. Dort findet ihr auchen eine Pagespeed Check: https://www.experte.de/pagespeed.

• Falls am Zertifikat etwas faul ist, überprüft nochmal euer Caddyfile und ob die Weiterleitung eures DNS Eintrag funktioniert: whatsmydns.net

• Wenn ihr beim Start von LNbits per Poetry Befehl im Terminalfenster die Meldung Retrying connection to backend in 5 seconds... seht, dann stimmt vermutlich etwas in der .env Datei nicht. Prüft den Macaroon, das Cert und den Endpoint.

• Wenn ihr die Meldung HTTP ERROR 502 bekommt, dann ist evtl. eure LNbits Instanz nicht gestartet. Das könnt ihr prüfen, in dem Ihr den Status des lnbits.service abfragt: $ sudo systemctl status lnbits.service oder sudo journalctl -u lnbits -f --since "2 hour ago". Dort seht ihr auch, wenn es einen Fehler mit der Verbindung zu eurem Node gibt. Ursache dafür kann ein Fehler in Konfigurationsdatei .env sein. Prüft welches LNBITS_BACKEND_WALLET ihr eingestellt habt und die dazugehörigen Daten wie z.B. LND_REST_MACAROON, LND_REST_CERT und LND_REST_ENDPOINT. Was auch noch möglich ist, vielleicht stimmt etwas mit eurer PostgreSQL Datenbank oder der LNBITS_DATABASE_URL Verknüpfung in der .env nicht.

• Der Aufruf mit der Subdomain www. funktioniert nicht. Dafür müsste man noch etwas extra Arbeit reinstecken. Gebt eure Webadresse also immer ohne das www davor ein.

• Die Meldung ERR_CONNECTION_REFUSED kommt, wenn euer Caddy Server ausgefallen ist. Überprüft ob der Service gestartet ist: $ sudo systemctl status caddy.service

• Seht ihr auf der LNbits Seite die Meldung 500, dann kann die Verbindung zu eurem Node unterbrochen sein. Ist er vielleicht ausgefallen oder hat er aktuell kein Internet Zugang?

• Wenn ihr auf der LNbits Seite die Fehlermeldung All connection attempts failed 500 bekommt, dann kann euer Docker für den Tunnel zur Node ausgefallen zu sein.

  • Prüft ob die Docker Application "active (running)" ist: $ sudo systemctl status docker
  • Pürft ob euer Docker Container auch aktiv ist: $ sudo docker ps -a
  • Falls ihr STATUS / Exited seht, dann scheint der Container ausgefallen zu sein. Startet ihn wieder neu: $ sudo docker start < Docker ID >
  • Falls nicht schon geschehen, fügt den Autostart Service hinzugefügt: $ sudo docker update --restart unless-stopped < Docker ID >

• Solltet ihr beim Aufrufen der Seite die Meldung ERR_FAILED bekommen, dann ist vermutlich euer VPS Droplet down.

• Die Meldung 520 deutet darauf hin, das euer LNbits Server auf Voidwallet umgestellt hat. Wenn etwas mit der eingestellten Finanzierungsquelle, also z.B. mit dem Node, nicht stimmt, dann wird automatisch auf das Voidwallet umgeschaltet. Das ist kein richtiges Wallet, es ist eher ein Schutzfunktion. LNbits kann dann noch ganz normal starten, es sind dann aber keine Ein- oder Auszahlungen möglich. Kontrolliert in diesem Fall die Finanzierungsquelle. Und wenn ihr den Grund für die Umstellungen wissen wollt, dann solltet ihr das in den Logs finden.

• Wenn ihr in der Extention Onchain Wallet die Fehlermeldung 400 unspported hash type ripemd160 bekommt, dann liegt das an einem Kompatibilitätsfehler. Eine Lösung findet ihr hier.

• Wenn ein Lightning-Wallet die Meldung "Payment failed, use a different wallet" anzeigt, kann es daran liegen, dass euer Server auf "void wallet" umgeschaltet hat. Überprüft eure Instanz, indem ihr eine Zahlung durchführt, oder geht als Superuser unter "Server" und schaut nach, ob noch die richtige Funding Source eingestellt ist.

9.2 LNbits Update durchführen

LNbits stoppen und Update durchführen

sudo systemctl stop lnbits.service
cd ~/lnbits
git pull
[Optional: "git tag" und dann "git checkout .."]
poetry self update
poetry install --only main

Version prüfen: git describe --tags

LNbits wieder starten und Logs lesen

sudo systemctl start lnbits.service
sudo journalctl -u lnbits -f --since "2 hour ago"

Prüft ob einmal in den Logs (journal) und auf der Webseite ob euer LNbits Server auch korrekt gestartet wurde.

Möglichkeiten zur Versionsprüfung

Ob das Update gelappt hat, sehr ihr auf der LNbits Webseite unten links. Dort seht z.B.

LNbits🕳️🐇, LNbits Instanz von ereignishorizont.xyz LNbits version: 0.10.10, Commit version: fb98576431cb4096d92e2691c1dcb5ea5201befb

Ihr könnt prüfen welche "Version" gerade aktuell ist. Führt dazu den Befehl $ git show aus. Als Ergebnis bekommt ihr Merge pull request #1234 .. angezeigt. Das ist die Nummer des letzten Pull Request der verschmolzen wurde. Wenn ihr jetzt auf die GitHub Seite von LNbits geht, dann seht ihr dort welcher PR der letzte Merge war. Daran kann man gut erkennen, wie weit man hinterher hinkt. Raus kommt ihr aus "git show" mit q.

Sind neue Funktionen hinzugekommen? Dann die .env Datei einmal prüfen

Bei einem Update wird immer nur der Code von LNbits aktualisiert, nicht aber eure Datenbank oder Konfigurationsdatei .env. Ob es da Änderungen / Erweiterungen gab, müsst ihr selbständig prüfen oder die Datei von der .env.example als Vorlage nehmen und die .env neu erstellen. Vergleichen könnte ihr den Inhalt sehr gut, in dem Ihr die .env Datei einmal mit $ sudo nano ~/lnbits/.env öffnet und in einem zweiten Fester euch den letzten .env.example Stand auf GitHub anschaut.

Alternativ könnt könnte ihr das auch manuell machen:

cd ~/lnbits
ls -la
cat .env   # -> alte aktive Datei
cat .env.example   # -> neue mit ggf. Änderungen
cp .env .env.bak   # -> Backup machen
sudo nano .env   # -> Änderungen einpflegen

LNbits neu starten mit $ sudo systemctl restart lnbits.service

9.3 LNbits Option – PostgreSQL Datenbank

Die standardmäßig installiert SQLite Datenbank ist für den Einstieg gut und ausreichend. Möchte man LNbits aber skalieren, sollte man auf die leistungsfähigere PostgreSQL Datenbank umsteigen. Die Daten der SQLite Datenbank können dabei recht einfach in die neu PostgreSQL Datenbank überführt werden. Um sicher zu gehen, macht aber trotzdem lieber vorher ein Snapshot eures Droplet.

Bevor wir loslegen, hier noch zwei Einträge für die Passwortliste:

PostgreSQL User: postgres (Ändert ihn nur, wenn ihr nachfolgend auch den Überlick behalten könnt) Passwort für User "postgres": myStrongPasswort (Wählt ein starkes Passwort)

Voraussetzungen installieren

sudo apt-get update
sudo apt install python3-pip -y
pip install psycopg2-binary

Info: "pip" ist ein Packprogramm und "Psycopg" ist ein PostgreSQL Datenbank Adapter für Python

PostgreSQL Installation und Einrichtung

sudo apt-get -y install postgresql
sudo -i -u postgres
psql
ALTER USER postgres PASSWORD 'myStrongPassword'; # -> Set a strong password!
\q
createdb lnbits
exit

Einstellung in der LNbits Konfigurationsdatei .env

cd ~/lnbits
sudo nano .env

-> # LNBITS_DATABASE_URL=.. Eintrag suchen und durch folgende Zeile ersetzten

..
LNBITS_DATABASE_URL="postgres://postgres:myStrongPassword@localhost:5432/lnbits"
..

• Syntax: "postgres://user:password@host:port/databasename"
• Mindestens myStrongPassword anpassen.
• STRG-x -> y -> ENTER

LNbits einmal stoppen, starten und testen

sudo systemctl stop lnbits.service
cd ~/lnbits
poetry run lnbits   # -> STRG+c

-> Hier sollte jetzt keine Fehlermeldung angezeigt werden, unter Info "Database: PostgreSQL" stehen und die LNbits Seite wieder verfügbar sein.

Hinweis: LNbits funktioniert jetzt zwar wieder, aber alle Accounts und Wallets sind noch in der alten Datenbank. Deswegen müsst ihr die Daten erst noch in die neue Datenbank überführen.

Die Daten der alten SQLite Datenbank zur neuen PostgreSQL migrieren

Achtung: Deaktiviert für die Migration den Super User in der .env mit # SUPER_USER=... Sonst kann es bei der Migration zu Konflikte kommen.

sudo systemctl stop lnbits.service
poetry run python tools/conv.py

Hinweis: Sollte die Migration mit der Fehlermeldung _"psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "accountspkey" DETAIL: Key (id)=(####) already exists. " fehlschlagen, ist ein Lösung das löschen der jetzt fehlerhaften PostgreSQL Datenbank dropdb <lnbits> und erzeugen einer neuen leeren createdb <lnbits>. Danach in der .env den SUPER_USER=.. mit der # deaktivieren und die Migration noch einmal versuchen.

LNbits neu starten und testen

sudo systemctl start lnbits.service
sudo systemctl status lnbits.service

-> Jetzt sollte LNbits wie gewohnt laufen und alle Konten, Wallets und Erweiterungen wieder vorhanden sein.

Info: Status von PostgreSQL anzeigen lassen

sudo systemctl status postgresql.service

9.4 LNbits – Datenbanken Backup & Restore

9.4.1 Einfache Datensicherung einer SQLite Datenbank

Für gelegentlichen Sicherungen kann man bei SQLite einfach den ganzen Ordner ./lnbits/data sichern. Dazu in den LNbits Ordner wechseln, dort liegt der Ordner ./data. Am besten ein sprechenden Name, mit Datum im Format "jj/mm/dd" angeben, dann sortieren sich die Backups in der Ansicht besser.

cd ~/lnbits
tar cfv data_backup_jjmmdd.tar ./data

Es wurden jetzt in dem Verzeichns ./lnbits TAR Archivdateien angelegt. Kontrollieren könnt ihr das mit $ ls -la.

Hinweis: Wenn ihr euch die Datei auf eure PC herunterladen möchtet, könnte ihr diese Befehl verwenden:

scp synonym@111.111.111.111:/home/synonym/lnbits/data_backup_jjmmdd.tar ./

9.4.2 Wiederherstellung einer SQLite Datenbank

Vor dem entpacken LNbits einmal stoppen. Er entpackt dann in den gleichen Ordner ./data. Alle Dateien werden überschrieben.

sudo systemctl stop lnbits.service
cd ~/lnbits
tar -xvf data_backup_jjmmdd.tar
sudo systemctl start lnbits.service

Hinweis: Um eine Backup Datei vom PC zu eurem VPS zu kopieren, könnt ihr diesen Befehl verwenden:

scp data_backup_jjmmdd.tar synonym@111.111.111.111:/home/synonym/lnbits/

9.4.3 Einfache Datensicherung einer PostgreSQL Datenbank

Um ein Backup der Datenbank zu machen, müsst ihr euch erst mit dem vergebene User z.B. postgres anmelden, mit dem ihr die Datenbank lnbits angelegt habt. Es wird in dem Ordner dann die Datei lnbits_jjmmdd angelegt.

# LOGIN AS USER POSTGRES
sudo -i -u postgres
# BACKUP LNBITS DATABASE
pg_dump lnbits > lnbits_jjmmdd.sql
# CHECK BACKUP
ls -la
# EXIT USER POSTGRES
exit

9.4.4 Wiederherstellung einer PostgreSQL Datenbank aus einer Datensicherung

Um das Backup wiederherzustellen, müsst ihr ein paar Zwischenschritte machen.

# STOP LNBITS
sudo systemctl stop lnbits.service
# LOGIN AS USER POSTGRES
sudo -i -u postgres
# LOGIN POSTGRES FRONTEND
psql
# SHOW LIST OF DATABASES
\l
# CONNECT FROM LNBITS TO POSTGRES DUMMY DATABASE
\c postgres
# DROP LNBITS DATABASE
DROP DATABASE IF EXISTS lnbits;
# QUIT POSTGRES FRONTEND
\q
# CREATE LNBITS DATABASE FROM TEMPLATE
createdb -T template0 lnbits
# RESTORE LNBITS DATABASE 
psql --set ON_ERROR_STOP=on lnbits < lnbits_jjmmdd.sql
# LOGIN POSTGRES FRONTEND
psql
# CONNECT FROM POSTGRES DUMMY TO LNBITS DATABASE
\c lnbits
# QUIT POSTGRES FRONTEND
\q
# EXIT USER POSTGRES
exit
# START LNBITS
sudo systemctl start lnbits.service
# CHECK JOURNALCTL
sudo journalctl -u lnbits -f --since "2 hour ago"

-> STRG+c

Hinweis: Wenn ihr die Datenbank von einem System zum anderen übertragt, kann es Komplikationen mit der Finanzierungsquelle geben und eure Admin_UI funktioniert nicht richtig. Leider kann man das im Nachhinein nicht so einfach ändern, weil man kein Zugriff mehr auf die Admin_UI hat. Deswegen muss man das direkt in der PostgreSQL Datenbank ändern. Wie man das macht, dass zeige ich im Kapitel 9.9.6 Admin UI.

Hinweis: Wird die Datenbank auf ein neues System installiert, kann es sein, dass gewisse Komponenten, wie z.B. der BoltzClient zwar in der neuen Datenbank aufgerufen wird, aber noch nicht installiert wurde. Deswegen sollte man danach, ein poetry install im lnbits Verzeichnis machen, um alle benötigen Komponenten nachzuinstallieren.

9.4.5 Auto Backup PostgreSQL Database mit Cron Job

Vorbereitung: md5 Hashfunktion für die Passwortabfrage aktivieren

Für den Cron Job müsst ihr vorher den Message-Digest Algorithm 5 (MD5) als Hashfunktion für die PostgreSQL Passwortabfrage einstellen. Ohne dem bekommt ihr ein Peer authentication failed wenn ihr bereichsübergreifend (Ubuntu/Unix) etwas schreiben wollt oder das Passwort für euren postgres wird als Fehlerhaft angezeigt. Dazu müsst ihr in der pg_hba.conf zwei Zeile editieren und den PostgreSQL Service einmal neu starten. Danach müsst ihr den Passwort Hash erneuern, in dem ihr ein neues Passwort (kann auch das gleiche sein) generiert. Aber vorher einmal die Version von PostgreSQL prüfen und ggf. den Pfad, hier Version 14 = ./14/., für eurer Version anpassen.

psql -V
sudo nano /etc/postgresql/14/main/pg_hba.conf

An zwei Stellen peer gegen md5 tauschen. Hier steht wie es aussehen muss.

..
# Database administrative login by Unix domain socket
local   all             postgres                                md5 

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     md5 
..

PostgreSQL einmal neu starten

sudo service postgresql restart

Passwort Hash erneuern

sudo passwd postgres
exit

-> Einfach das gleiche Passwort (myStrongPassword) erneut eingeben.

Einmal das neue Passwort testen, mit einem Login zum PostgreSQL Frontend

# DIRECT LOGIN TO THE FRONTEND (PSQL) OF POSTGRESQL
sudo psql -U postgres -W postgres
# LIST DATABASES
\l
# LOGOUT FROM FRONTEND (PSQL) AND FROM USER POSTGRES 
\q

Option: Passwort für die PostgreSQL Datenbank ändern

Für den User postgres gibt es zwei Passworter. Eins für den Ubuntu User und eins für den User der PostgreSQL Datenbank. Falls ihr das Passwort für die Datenbank ändern möchtet, geht wie folgt vor. Aber Achtung, das kann Auswirkungen auf die Datenbank haben. Macht sicherheitshalber vorher ein Snapshot vom Droplet und denke auch daran, das Passwort in der .env Datei unter LNBITS_DATABASE_URL="postgres.. zu ändern. Wenn ihr das vergesst, dann hat euer LNbits keinen Zugriff mehr auf die Datenbank.

# LOGIN LOGIN TO THE FRONTEND (PSQL) (USE OLD PASSWORD)
sudo -i -u postgres psql
# CHANGE PASSWORD
\password postgres
# LOGOUT FROM FRONTEND
exit

Das Passwort File .pgpass für den automatischen CronJob anlegen

# LOGIN AS USER POSTGRES
sudo -i -u postgres
# CREATE PASSWORD FILE
nano .pgpass

-> Befülle mit hostname:port:database:username:password

localhost:5432:lnbits:postgres:myStrongPassword

.pgpass Dateirechte "read/write" auf den aktiven Benutzer postgres einschränken:

chmod 0600 ~/.pgpass
exit

Cron Job einrichten

# LOGIN AS USER POSTGRES
sudo -i -u postgres
# CREATE FOLDER BACKUPS
mkdir backups
# CREATE CRONJOB
crontab -e
# LOGOUT FROM USER POSTGRES
exit

-> Im crontap Editor beispielhaft folgendende Zeilen anfügen:

*/5 * * * * pg_dump -U postgres lnbits > ~/backups/lnbits.bak 
0   0 * * * pg_dump -U postgres lnbits > ~/backups/lnbits_$(date +\%Y\%m\%d).bak
0 */1 * * * pg_dump -U postgres lnbits > ~/backups/lnbits_$(date +\%H\%M).bak
0 */6 * * * pg_dump -U postgres lnbits > ~/backups/lnbits_$(date +\%Y\%m\%d_\%H\%M).bak

-> Mit STRG+x -> y -> ENTER und dann $ cd backups und $ ls -la. Nach 5 Minuten müsste das erste Backup erscheinen. Dann $ exit.

• Der erste Eintrag ist zum Testen des Cronjobs. Er sichert die Datenbank alle 5 Minuten in die Datei lnbits.bak
• Der zweite Eintrag schreibt jeden Tag um 00:00 Uhr die Datenbank in die Datei Namens lnbits_JJJJMMDD.bak
• Der dritte Eintrag schreibt die Datenbank jede Stunden rekursive in die Datei nach dem Format lnbits_HHMM.bak.

• Der vierte Eintrag schreibt die Datenbank alle 6 Stunden in die Datei nach dem Format lnbits_JJJJMMDD_HHMM.bak

  Empfehlung: Zwei und drei für den Dauerbetrieb

Zeitintervalle, von links nach rechts bedeuten die Sternchen/Zahlen:

• Minuten , angegeben als Zahl von 0 bis 59.
• Stunden , angegeben als Zahlen von 0 bis 23.
• Tage des Monats , angegeben als Zahlen von 1 bis 31.
• Monate als Zahlen von 1 bis 12 angegeben.
• Wochentage , angegeben als Zahlen von 0 bis 7, wobei Sonntag entweder als 0 oder als 7 dargestellt wird.

Sonstiges: = Ausführung immer (zu jeder…) und /n = Ausführung aller n

Welchen Backup Version ihr bevorzugt und wie ihr die Pflege managt, dass müsst ihr selbst entscheiden. Auch macht sicherlich ein CronJob für das Kopieren auf ein ein andere Laufwerk Sinn. Soweit bin ich aber selber noch nicht. Aber um einmal eine einfache Sicherung auf den PC zu ziehen und wieder herzustellen, kann man folgende Befehle vom Terminal des PCs aus verwenden:

# COPY BACKUP TO PC
scp postgres@111.111.111.111:/var/lib/postgresql/backups/lnbits.bak C:\Users\User
# COPY BACKUP TO VPS
scp C:\Users\User\lnbits.bak postgres@111.111.111.111:/var/lib/postgresql/

Zur Wiederherstellung siehe: "9.4.4 Wiederherstellung einer PostgreSQL Datenbank aus einer Datensicherung". Die Datei ist bewusst nicht in den Ordner "backups" kopiert, da die Anleitung 9.4.4 vom Ordner "postgresql" ausgeht.

Hinweis: Weil es möglich ist von außerhalb auf die PostgreSQL Dateien zuzugreifen, macht es auch Sinn, den User postgres zu ändern, wenn ihr damit klar kommt. Aber noch wichtiger ist ein sehr starkes Passwort!

Mögliche Quicklinks aus dem Stammverzeichnis:

• Inhalt des Ordner Backups anzeigen: sudo -i -u postgres ls -la backups
• Den Crontab einmal anzeigen: sudo -i -u postgres crontab -l
• Den Crontab editieren: sudo -i -u postgres crontab -e

Weiter Infos zu Cron findet ihr hier oder hier .

9.4.6 Datensicherung auf ein externes Laufwerk per CronJob

Vorbereitungen auf dem Ziel (dem externen Speicher, hier eine weitere VPS)

Auf der exteren Maschine einloggen und dort einen neuen User z.B. "userbackup" anlegen, ein Passwort vergeben und den Ordner "backups" anlegen. Der User braucht keine Admin Rechte.

adduser userbackup
passwd userbackup
mkdir backups
cd backups
ls -la
pwd

Jetzt ausloggen und mit dem neuen User wieder einloggen, um später im Ordner "backups" mit ls -la zu prüfen, ob die Backups dort auch ankommen.

Vorbereitung auf der Quelle (dem VPS mit den Daten)

sshpass für das automatische SSH Login installieren. Bitte darauf, ihr müsst es mit dem User root installieren, sonst funktioniert es für den CronJob nicht.

sudo apt install sshpass

Vorhandene Backups prüfen und Pfad abfragen

sudo -i -u postgres
cd backups
ls -la
pwd
exit

Ein Secure Copy (scp) Befehl erstellen und testen

Format: scp <Quelle> <Ziel>

Beispiel:

scp /var/lib/postgresql/backups/lnbits.bak userbackup@222.222.222.222:/home/userbackup/backups/lnbits_$(date +\%Y\%m\%d_\%H\%M).bak 

• Den Kopierbefehlt jetzt bitte einmal ausführen und mit dem Passwort des User userbackup bestätigen. Beim ersten mal aufrufen werdet ihr noch die Speicherung des SSH Key als vertrauenswürdig Schlüssel bestätigen müssen. Ohne dem funktioniert später die Automatik nicht.
• Die Backup Datei lnbits.bak wird damit einmal zum entfernten Ziel, hier eine andere VM mit der IP: 222.222.222.222, kopiert. Auf dem Ziel wird die Datei umbenannt und bekommt das aktuelles Datum und die Uhrzeit hinzugefügt.

Den Secure Copy (scp) mit sshpass ergänzen

Format: sshpass -p "password" scp <Quelle> <Ziel>

Beispiel:

sshpass -v -p 'yourPassw0rd' scp /var/lib/postgresql/backups/lnbits.bak userbackup@222.222.222.222:/home/userbackup/backups/lnbits_$(date +\%Y\%m\%d_\%H\%M).bak 

• Das ist der Befehl den ihr für den CroneJob verwenden könnte. Ab jetzt solltet ihr nicht mehr nach dem Passwort des userbackup (hier "yourPassw0rd") gefragt werden. Die Befehlserweiterung -vzeigt euch noch weitere Infos zum Vorgang. Das ist ganz nützlich bei der Fehlersuche, aber nicht notwendig.

Ein CronJob für den automatischen Transfer einrichten

Richtet als erste mal den täglichen Datenbank Backup für den User postgres ein.

sudo -i -u postgres crontab -e

Fügt folgende Zeile an:

0 0 * * * pg_dump -U postgres lnbits > ~/backups/lnbits.bak

Damit wir täglich rekursiv um 00:00 Uhr die Datenbank in die Datei lnbits.bak gesichert.

Als nächste ist wichtig, dass ihr den CronJob zum kopieren mit dem User synonym einrichtet. Der Befehl funktioniert mit dem User postgres leider nicht. Öffnet also CronTab mit dem User synonym.

crontab -e

Fügt folgende Zeile an:

5 0 * * * sshpass -p 'yourPassw0rd' scp /var/lib/postgresql/backups/lnbits.bak userbackup@222.222.222.222:/home/userbackup/backups/lnbits_$(date +\%Y\%m\%d_\%H\%M).bak 

Um 00:05 Uhr wird damit die lnbits.bak zu dem VPS kopiert und mit aktuellem Datum und Uhrzeit versehen. Fertig ist die Datensicherung auf ein externes Laufwerk.

Die Logs der CronJobs könnt ihr mit diesem Befehl prüfen:

sudo grep CRON /var/log/syslog

9.4.7 Die Pflege des Backup-Archivs / Alte Dateien löschen

Backup Dateien Anzeigen

sudo -i -u postgres
cd backups
ls -la
pwd

Alle Backup Datein, die mit lnbits* beginnen und älter als 3 Tage sind, auflisten

find /var/lib/postgresql/backups/lnbits* -type f -mtime +3

Hinweis: Das * ist ein Wildcard und steht für "beliebig"

Ihr könnt die Dateien auch gleich löschen, in dem ihr dem Befehl -delete anhängt

find /var/lib/postgresql/backups/lnbits* -type f -mtime +3 -delete

Mit einem CronJob könnt ihr den Löschprozess automatisieren. Öffnet dazu CronTab mit dem User postgres:

sudo -i -u postgres crontab -e

Und fügt folgenden Zeil an:

0 1 * * * find /var/lib/postgresql/backups/lnbits* -type f -mtime +14 -delete

Jeden Tag um 01:00 Uhr wird in dem Ordner backups nach lnbits* Dateien gesucht und alle, die älter als 14 Tage sind, werden gelöscht.

9.5 Nützliche Shortcut Beispiele

# Allgemein
ls -la
pwd
du -sh file.bak
sudo systemctl poweroff
sudo systemctl reboot
sudo find /mnt/hdd/ -iname "RTL-Config.json"

# Firewall
sudo ufw allow 9735 comment 'Node1' 
sudo ufw enable
sudo ufw status 

# Docker
sudo systemctl status docker
sudo docker ps -a 
sudo docker start 8c5c4bf6c634
sudo docker stop 8c5c4bf6c634
sudo docker exec -it 8c5c4bf6c634 sh

# Kommunikation von dem VPS zum Node prüfen
curl https://172.17.0.2:8080 -v --cacert /home/synonym/tls.cert  

# LND 
sudo nano /mnt/hdd/lnd/lnd.conf
sudo systemctl restart lnd.service
sudo systemctl status lnd.service 
lncli getinfo
sudo tail -n 30 /mnt/hdd/lnd/logs/bitcoin/mainnet/lnd.log
sudo journalctl -u lnd.service -f --since "1 hour ago"

# OpenVPN
sudo systemctl status openvpn@CERT
sudo journalctl -u openvpn@CERT -f --since "1 hour ago"
ip route get 8.8.8.8

# Übertagen
scp synonym@111.111.111.111:/home/synonym/lnbits/lnbits.bak ./
scp lnbits.bak synonym@111.111.111.111:/home/synonym/lnbits/
scp root@111.111.111.111:/home/synonym/node1.ovpn /home/admin/VPNcert/
scp /mnt/hdd/lnd/tls.cert synonym@111.111.111.111:/home/synonym

# PostgreSQL & Cronjob
sudo -i -u postgres
sudo -i -u postgres ls -la backups
sudo -i -u postgres crontab -e
sudo systemctl status postgresql.service
sudo grep CRON /var/log/syslog

# LNbits
cd ~/lnbits
sudo nano ~/lnbits/.env
sudo systemctl restart lnbits.service
sudo systemctl status lnbits.service
sudo systemctl stop lnbits.service
sudo systemctl start lnbits.service
poetry run lnbits
sudo journalctl -u lnbits -f --since "2 hour ago"

# Verbindungstest und Netzwerk Diagnose/Info
ping -c 3 google.com
ip add show tun0
ifconfig
nslookup google.com
dig google.com
sudo netstat -tulnp
sudo lsof -i :8081
curl https://api.ipify.org
ip route get 8.8.8.8 
debug -l 

9.6 Referenztabelle für Umbrel Pfade und Befehle

9.7 Deinstallationen / Rückbau

Anleitungen zum deinstallieren von Software findet ich fast genauso wichtig wie die für Installationen. Denn man sich entscheidet die Software nicht zu verwenden oder ein Problem auftaucht, dann muss es einen Weg geben, dass Gerät möglichst wieder in den Ursprungszustand zu versetzen, gerade wenn es um ein Lightning Node handelt. Daher hier ein paar Hinweise.

OpenVPN vom Node deinstallieren

sudo apt-get remove --purge openvpn
sudo rm -r /etc/openvpn
sudo rm -r /home/admin/VPNcert

Das Backup der lnd.conf wieder herstellen

cd /mnt/hdd/lnd/
sudo cp lnd.conf.backup lnd.conf 

Alternative, manuelle Wiederherstellung der Einstellungen

sudo nano /mnt/hdd/lnd/lnd.conf

Die entsprechenden Zeile ändern (true -> false) oder auskommentieren mit "#"

[Application Options]
..
nat=true  # true = dynamische IP (NAT) 

# externalip=111.111.111.111:9735   # für OpenVPN
# tlsextraip=111.11.0.2    # für Wireguard

[tor]
..
# tor.streamisolation=false
# tor.skip-proxy-for-clearnet-targets=true

Besonderheit, NUR beim Raspiblitz

Das lnd_check.sh Skript bei Zeile 184 aufrufen

sudo nano +184 /home/admin/config.scripts/lnd.check.sh

Und folgende Zeile wieder auskommentieren

  # enforce PublicIP if (if not running Tor)
  if [ "${runBehindTor}" != "on" ]; then
    setting ${lndConfFile} ${insertLine} "externalip" "${publicIP}:${lndPort}"
  else
    # when running Tor a public ip can make startup problems - so remove
    sed -i '/^externalip=*/d' ${lndConfFile}
  fi

Hinweis: Etwas weiter oben steht auch # enforce LND port is set correctly. Falls ihr die Zeilen auch auskommentiert habt, weil ihr einen anderen Port als 9735 verwendet habt.

Den ganze Node einmal neu starten

sudo systemctl reboot

Jetzt sollte alles wieder wie vorher funktionieren. Zum Überprüfen, schaut euch nochmal das Kapitel "7.7 – Allgemein – Überprüfen der Verbindung" an

Rückbau Droplet

Das Droplet (den VPS) könnt ihr einfach auf DigitalOcean "zerstören" (löschen)

9.8 Quellen und weiterführende Dokumentation

9.9 Sonstiges

Hier kommt alles das rein, was nicht primär wichtig ist, aber das Tutorial erweitern kann.

9.9.1 Node Alias Name

In der lnd.conf könnt ihr eurem Node auch einen Klarnamen (Alias) geben, falls er noch keinen hat. Die erscheint dann bei bestimmten Diensten. Fügt es einfach zu "Application Options" hinzu. Wenn ihr wollt könnte ihr im Node Alias sogar ein Emoji einfügen. Hier findet ihr eine gute Übersicht an Emojis. Die Emojis werden aber nicht von allen Diensten unterstützt und das kann das etwas komisch aussehen.

Beispiel für ein Alias Name:

[Application Options]
..
alias=FunnyName⚡

9.9.2 LNbits personalisieren

-> Vorzunehmende Einstellungen in der .env Datei:

# Change theme
LNBITS_SITE_TITLE="LNbits🐣"   # Icon siehe Anhang "Alias Name für den Node"

Mögliche Emojis findet ihr hier.

Hinweis: Wenn ihr den LNBITS_SITE_TITLE verändert, zeigt euch LNbits auf der Startseite nicht mehr die letzte Commit version an!

9.9.3 "Telegram Ping Bot" zum testen der Verbindung

Sucht in Telegram den Tunnel⚡️Bot:

https://t.me/TunnelSatsBot

Den Bot starten und dann den Befehl /ping eingeben, gefolgt von der Node ID, einem "@", der IP und dem Port für den LND

/ping <Node-ID>@<your-node-ip>:port

Z.B.:

/ping 292f947f27220d327817f0dd3931898661a33a527ecd6242e34af2c4839956bf0@38.242.135.150:24438

Es funktioniert auch für die Tor Verbindung:

/ping <Node-ID>@<tor-node.onion>:port

Hinweis:Manchmal kann es etwas dauern bis der Bot reagiert, gerade bei Tor anfragen kann es auch schon mal bis zu 1 oder 2 Minuten dauern, habt also Geduld.

9.9.4 Ein privater VPN Tunnel

Die Tunnel Technologie die ihr jetzt kennen gelernt habt, könnt ihr natürlich auch für andere Funktionen verwenden. Z.B. eure eigene VPN Verbindung herstellen. Entweder um von eurem Desktop PC über einen VPS im Internet surfen, so das euer Internet Provider nicht mit bekommt, mit wem ihr euch verbinden und von außen niemand euren echten Standort sieht. Wenn ihr mit eurem Handy unterwegs seid oder in einem öffentlichen WiFi, kann es auch Sinn machen VPN zu verwenden. Niemand muss mitbekommen wo ihr gerade seid oder welche Seiten ihr besucht. Auch könnt ihr im Prinzip über den VPS per zweiten VPN Tunnel zu eurem Handy/Compouter sicher auf euer Heim Netz zugreifen. Die Anwendungsmöglichkeiten sind vielfältig und es gibt mittlerweile viele Clients für Desktop und Mobil Geräte. Siehe openvpn.net.

9.9.5 Anbinden einer Wallet App wie z.B. Zeus

Wenn ihr in der UFW (uncomplicated firewall) des VPS den Port 8080 freischaltet, dann könnt ihr mit ein Lightning Wallet App, wie z.B. Zeus, mit euer Node verbinden. Ihr braucht nur die Daten Host = Die IP des VPS / LND Port = 8080 / Macaroon = den habt ihr in diesem Tutorial aus eurem Node ausgelesen. Bei dem einrichten werdet ihr nach einen Zertifikat gefragt. Das is das Zertifikat für die Verschlüsselung der Verbindung. Während ihr dieses bei einer Verbindung zu eurem Node in eurem heimischen WLAN / LAN Netz ohne weiteres ignorieren könnt, sollte ihr eine unverschlüsselte Kommunikation im offen Internet geht vermeiden. Ich sollte also entweder das Zertifikat verwenden oder einen VPN Tunnel aufbauen. Ich bin da selbst noch nicht tiefer eingestiegen, werde das aber zu gegebener Zeit tun und dann hier ergänzen.

9.9.6 Admin UI & Super User

Admin UI aktivieren und Super User Account erhalten

Das Admin UI ist praktisch und notwendig, da man viele Einstellungen über das Web UI machen kann und Extensions darüber überhaupt erst aktivieren. Ihr bekommt dafür ein Super User Account, beim ersten Start mit den neuen Einstellungen in der .env, wenn ihr das aktiviert. Den Account müsst ihr euch wie ein Wallet Account abspeichern. Hier die Anleitung wie ihr den Account aktiviert.

sudo systemctl stop lnbits.service
cd ~/lnbits
sudo nano .env

-> Setze: LNBITS_ADMIN_UI=true

Jetzt startet LNbits wieder

sudo systemctl start lnbits.service

Im Hintergrund wurde jetzt der Super User aktiviert und dessen ID könnt ihr mit folgendem Befehl einsehen

cat ~/lnbits/.super_user

Alternativ:

cd lnbits
poetry run lnbits-cli superuser

Es wird euch jetzt ein Zeichenkette von 32 Zeichen angezeigt, das ist die ID

Diese hängt ihr dann einfach hinter dem Link zu eurer LNbits Seite an, z.B.

https://lnbits.meineseite.org/wallet?usr=5216fc241448acb2344f32245

Jetzt sollte sich die Seite des Super User öffnen. Ihr seht das auch links oben angezeigt und ihr habt zu dem Menü Extensions auch noch das Menü Manage Server bekommen. Bewahrt diesen Link gut auf. Öffnet die Seite auch am beste nur wenn ihr vorher im Browser ein Inkognitofenster geöffnet habt. Wer diesen Link hat, hat auch die volle Kontrolle über eure LNbits Instanz, samt Zugangsdaten zum den Funding Wallets.

Ansonsten könnt ihr hier die Gestaltung der Oberfläche vornehmen, es hat TOPUP um Wallets zu füllen und man kann hier jetzt auch die Extensions für die Nutzer freigeben oder die Zugriffsrechte auf Extensions einschränken. Ihr könnt User zu Admins machen oder Allowed User einstellen, wenn ihr den Zugriff beschränken möchtet. Und natürlich auch die klassischen Einstellungen, die man sonst unter der .env Datei gemacht hätte, z.B. das Funding Source Wallet ändern oder ein Charge Fee einzustellen.

Wichtiger Hinweis: Wenn ihr einmal LNBITS_ADMIN_UI=true gesetzt habt, kommt ihr nicht mehr zurück zu der Verwendung der .env Datei. Die Wert sind in der Datenbank gespeichert und können von der .env Datei nicht mehr überschrieben werden. Solltet doch nochmal zurück müssen, dann siehe den nachfolgend Expertentipp.

Weiterer Hinweis: Wenn ihr RESET TO DEFAULTS setzt, dann wird ein neuer Super User Account angelegt. Der Alte ist dann nicht mehr gültig.

Expertentipp, nur für den Notfall: PostgreSQL Datenbank Eintrag für Admin UI löschen

Ein einmal gesetztes Admin_UI=true schreibt die Werte der .env Datei einmalig in die Datenbank. Danach kann man zwar immer wieder mit Admin_UI=false zurück zu den .env Einstellungen, allerdings werden sie beim nächsten mal Admin_UI=true nicht noch einmal von der .env in die Datenbank übertragen. Kopiert man jetzt z.B. eine Datenbank von einem Gerät / VPS zu einem anderen, kann es sein, dass die Finanzierungsquelle auf dem neuen System nicht passt und LNbits startet nicht mit der Admin_UI. Nachträglich kann man das leider nicht mehr ändern. Man kann also nur noch mit den Daten in der .env LNbits starten. Um auch wieder mit der Admin_UI arbeiten zu können, muss man die Datenbank direkt editieren. Genau gesagt den Inhalt des Table "settings" löschen. Hier eine Beschreibung wie ihr das machen könnt. Ihr könnt in der .env den Parameter Admin_UI=true belassen und führt dann folgende Befehle aus.

# STOP LNBITS
sudo systemctl stop lnbits.service
# LOGIN AS USER POSTGRES
sudo -i -u postgres
# LOGIN POSTGRES FRONTEND
psql
# SHOW LIST OF DATABASES
\l
# CONNECT TO LNBITS
\c lnbits
# LIST TABLES FROM LNBITS DATABASE
\dt
# REMOVE ALL ROWS FROM TABLE "SETTINGS"
TRUNCATE TABLE settings;
# QUIT POSTGRES FRONTEND
\q
# EXIT USER POSTGRES
exit
# LNBITS TEST START TO VERIFY WALLET SPECIFIED IN THE .ENV
cd ~/lnbits
poetry run lnbits
# -> IT SHOULD SEE THE ADMIN SUPER USER ACCOUNT AND NEW FUNDING SOURCE
# FINALLY START LNBITS SERVICE
sudo systemctl start lnbits.service

9.9.7 Mehrere Nodes auf einem Virtual Privat Server

Man kann auch mit einer VPS mehrere Node Clearnet Internet Zugänge verwalten. Entweder für die Familien oder Freunde, oder wenn man selbst einen zweite oder gar dritten Node hat. Sollte ein Node mal ausfallen, kann man LNbits recht einfach auf einen andern Node zeigen lassen, damit die neue Finanzierungsquelle verwendet wird. Um den Rahmen dieses Tutorials nicht zu überstrapazieren, habe ich dafür einen extra Seite erstellt. Ihr findet sie hier: Multi Node VPS

9.9.8 VPS Ubuntu Update

Beim Login auf euren VPS seht ihr im Terminal Fenster ob neue Updates für Ubuntu verfügbar sind. Ein Update kann leider nicht direkt mit dem User Synonym durchgeführt werden, selbst mit dem Befehl sudo nicht. Ihr müsst euch also entweder mit dem root User anmelden oder zum root User wechseln. Hier ein mögliche Reihenfolge für die Anmeldung vom User Synonym.

sudo systemctl stop lnbits.service
sudo su -
apt update && apt upgrade -y
reboot

Wenn du vorher / nacher die Version prüfen möchtest: lsb_release -a oder cat /etc/*release

9.9.9 Achtung, Pfadänderung von "lnbits-legend" auf "lnbits"

Mit der LNbits Version 0.10 ist auch der Github Pfad von "lnbits-legend" auf "lnbits" umgezogen. Um das ganz einheitlich zu machen, habe ich dieses Tutorial auch angepasst. Alle Befehle wurden auf den neuen Pfand geändert. Nur die Bilder sind noch nach dem alten Pfad. Wer einen LNbits Server noch nach dem alten Tutorial erstellt hat, dem zeige ich hier wie er für seine Instanz den Pfad auch umziehen kann. Bei mir hat das gut funktioniert, macht aber trotzdem vorher lieber eine Snapshot, nur um sicher zu gehen.

# STOP LNBITS
sudo systemctl stop lnbits.service
# CHANGE LNBITS PATH
cd
mv -v lnbits-legend/ lnbits/
# REINSTALL / CREATE NEW ENV
cd lnbits
poetry install --only main
# OPTION: CHECK ENV
poetry env list
# CHECK LNBITS FUNCTION
poetry run lnbits
# EDIT PATH IN FOR WorkingDirectory
sudo nano /etc/systemd/system/lnbits.service
# RELOAD LNBITS.SERVICE
sudo systemctl daemon-reload
# START SERVICE AGAIN
sudo systemctl start lnbits.service
# CHECK SERVICE
sudo journalctl -u lnbits -f --since "2 hour ago"
# OPTION: EDIT URL FOR GIT PULL
vi .git/config
# -> :q! (leave without changes)
# -> a (edit modus)
# -> edit: "url = https://github.com/lnbits/lnbits.git"
# -> ESC (escape edit modus)
# -> :wq (save and exit)

9.9.10 Den Server mit SSH Keys absichern

SSH Keys bestehen aus einem Privat und Public Key Schlüsselpaar. Dieses Schlüsselpaar wird auf dem Cliente Computer erzeugt und ist nur für diesen Computer gültig. Man kann ihn nicht einfach auf einen anderen Computer kopieren und verwenden. Der Private Key kann nochmal zusätzlich mit einer Passphrase verschlüsselt werden. So dass, beim Aufrufen der SSH Verbindung, der private Schlüssel erste entschlüsselt werden muss. Das gibt eine zusätzliche Sicherheit, ist das aber nicht unbedingt erforderlich. Die Sicherheit wird dadurch gewährleistet, dass nur der Computer/Client Zugang zum Server hat, für den auf dem Server der Public Key hinterlegt wurde. Auf dem Server können mehrer Public Schlüssel hinterlegen werden. Dann haben auch mehrer Computer Zugriff auf den Server. Das Schlüsselpaar für den Client und die Datei zum Verwalten der Public Keys auf dem Server, finden wir jeweils im Home Verzeichnis in dem Ordner .ssh. z.B. /home/user/.ssh oder C:\Users\User\.ssh. Die Datei mit dem Privaten Schlüssel heißt meistens "id_rsa", mit dem Public Key "id_rsa.pub". Die Datei in der die Public Keys auf dem Server verwaltet wird, heißt "authorized_keys".

Um den Public Key des Clients auf den Server zu transferieren, gibt es verschieden Optionen. Die einfachst wie ich finde ist das übertragen das Public Key mit Hilfe der Zwischenablage. Dazu muss man ein Terminalfenster mit Zugang zum Server aufmachen, also noch bevor man die Passwortanmeldung deaktiviert hat. Der Public Key ist nur ein Text String und der muss in die Datei "authorized_keys" kopiert werden. Ab dann kann man sich auch mit dem Public Key anmelden. Bedenken muss man hier, dass für jede SSH Verbindung auch ein Public Key auf dem Server liegen muss. Will man vom Node, z.B. einem Raspiblitz, eine Datei vom Server anfordern, um diese auf den Node zu kopieren, dann muss der Node auch einen Schüsselpaar besitzen und der Public Key vom Client auf dem Server hinterlegt sein.

Hier mal ein möglicher Weg, wir man nachträglich die SSH-Key Funktion einrichten kann:

# Auf dem Client Schüsselpaar generieren
ssh-keygen
# -> ENTER um den Standard Pfad und Dateinamen zu übernehmen
# -> mal ein Passphrase zum verschlüsseln des Private Key eingeben, wenn gewünscht
# -> Erzeugte Dateien privat key / public key (.pub)
/Users/User/.ssh/id_rsa     
/Users/User/.ssh/id_rsa.pub     

# Die Passphrase kann man auch nachträglich ändern
ssh-keygen -p

# Das Verzeichnis .ssh aufrufen
cd \Users\User\.ssh
# Inhalt des Public Key auslesen
notepad id_rsa.pub
# Den Inhalt in die Zwischenablage kopieren

# Auf dem Server einloggen (noch ohne SSH-Key Abfrage)
ssh synonym@111.111.111.111
# Verzeichnis .ssh im Hauptverzeichnis des User aufrufen
cd .ssh
# Datei "authorized_keys" öffnen
nano authorized_keys
# -> Inhalt des Private Key ans Ende hineinkopieren
# Speichern und schließen
# Ausloggen und neu einloggen um die Funktion zu testen
# Es sollte jetzt nur noch die Passphrase aber nicht mehr der Login abgefragt werden
# Drückt man einfach nur ENTER ohne die Passphrase einzugeben, dann kommt die Login Abfrage

# Deaktivieren der Passwort-Authentifizierung und des Root Zugriffs
sudo nano /etc/ssh/sshd_config
# Auskommentieren von:
PasswordAuthentication no
# Optional, wenn keine Root Login gewünscht ist:
PermitRootLogin no
# Server neu starten
sudo service ssh restart

# Steht die PasswordAuthentication schon auf "no" und man kann sich troztdem noch per User Login anmelden,
# dann muss man eine übergeordnete ".conf" Datei bearbeiten. Den Pfad zu der Datei. findet man wieder in der "sshd_config"
# Er kann so aussehen: "Include /etc/ssh/sshd_config.d/*.conf". Es werden also weitere Einstellungen aus der .conf übernommen.
# Um die Datei zu betrachten, gehen wir erst in den Ordner
cd /etc/ssh/sshd_config.d/
# Die Dateien Listen
ls -la
# Die Datei öffnen
sudo nano 50-cloud-init.conf
# PasswordAuthentication von "yes" auf "no" stellen
# Dann den Server einmal neu starten
sudo service ssh restart
# Jetzt sollte keine Passwortabfrage mehr kommen und ihr könnt euch nur noch über den SSH Key anmelden

# Hinweis, falls das Verzeichnis .ssh bei einem neuen User noch nicht existiert könnt ihr es hiermit einrichten
mkdir -p ~/.ssh
# Und hiermit die Datei "authorized_keys"
nano ~/.ssh/authorized_keys

Hinweis: Eine gute Anleitung findet ihr sonst auch hier.

Noch ein Tipp, wenn ihr einem neuen User anglegt und das Passwort Login bereits deaktiviert habt, müsst ihr dem neuen User erst über den Root User eure Public SSH-Key übergeben, sonst wir euch der Zugang verweigert. Dazu meldet euch per Root User an. Führt die Befehle $ su synonym und $ cd /home/synonym aus. Danach seid ihr auf der User Ebene und könnt die Datei "authorized_keys" wie oben beschrieben, mit eurem öffentlichen SSH-Key erweitern. Danach sollte die Anmeldung auch mit dem neuen User funktionieren.

9.9.11 Cronjob zum automatischen Restart des LNbits Server

Einige Zeit lang gab es einen Bug, der dazu führte, dass LNbits hängenblieb. Der Fehler konnte nur durch einen Neustart behoben werden. Um sicherzustellen, dass dieser Fehler proaktiv behoben wird, hatte ich den Server alle 30 Minuten neu starten lassen. Im Anhang der entsprechende Cronjob. Diese Funktion ist jetzt nicht mehr notwendig, aber ich lasse sie der Vollständigkeit halber einfach drin.

# Cronjob mit root Rechte erstellen
sudo crontab -e
# Folgenden Eintrag ans Ende machen
*/30 * * * * systemctl restart lnbits.service
# Speichern und schließen mit STRG+x -> y -> ENTER
# Logs prüfen
sudo grep CRON /var/log/syslog

-> Jeweils zu vollen Stunden bei Minute 0 und 30 wird der lnbits.service einmal neu gestartet

Weiter Infos zu Cron siehe hier.