start9labs / cln-startos Goto Github PK

• probing
• noise
• commando (control remote CLN nodes over the lightning protocol)
• sparko

This package (which used to be ~30MB) has ballooned to over 200MB in size, mostly due to adding a bunch of python stuff to deal with build errors. We need to trim the fat.

Possibly break out plugins into their own docker images

since c-lightning-REST cannot listen on https and http at the same time, and because zeus does not allow cleartext http over tor, we need to add a reverse proxy to do this. 443 for tor, 80 for lan (already uses reverse proxy)

also make sure the macaroon is correct

steps to reproduce:

1. open a channel with Start9 HQ
2. change wait time from 3 to 2 confirmations
3. channel never activates
4. restart CLN, now it activates

Prerequisites

• I have searched for existing issues that already report this problem.

Device

Laptop/Desktop

Device OS

Linux

Device OS Version

5

Browser

Firefox

Browser Version

108

Current Behavior

When the c-lightning REST API is enabled in CLN's Config,

And one goes to view CLN's Interfaces page,

We should be able to get some information from the REST api, yet curling the /v1/getinfo endpoint that should be available at that URL results in a 503 error:

$ curl -sk https://lskixqnpsc2cmj34tnm6mnesk5x3z65bp2dnv4jeelw3zl2q3y66qzid.local/v1/getinfo
503 Service Unavailable

It seems as though this is because 9735 and 8080 are the only ports exposed by the Dockerfile:
https://github.com/Start9Labs/c-lightning-wrapper/blob/v0.12.0.1/Dockerfile#L241

If you netstat -tap or ss -tap inside the container you can see that a node process is listening on port 3001 (api) and 4001 (docs) - but only using ipv6.

So it seems we're just not forwarding the .local from embassy's reverse proxy to the container's port 3001 listener. We may also need to do something in the CLN package about it not listening on ipv4 0.0.0.0:3001 if the embassy reverse proxy can't do ipv4 to ipv6 forwarding.

Additionally, I noticed I also get a 503 error when querying the json-rpc endpoint (under CLN's Interfaces page). Not sure if this is related or even an actualy problem, because I"m not sure what endpoint I should be able to hit and if it requires a special json query in the body, but its URL also seems to not work.

Expected Behavior

Expect curls to api endpoints to result in http 200's and return information.

Steps to Reproduce

Enable C-Lightning's Plugins CLN Rest API under Config.
Get the REST API URL from the Interfaces page
curl it as depicted above:
curl -svk https://clnrestrpcaddress.local

Anything else?

This might be related to #51 but I'm not sure.

See lnd and bitcoind for examples of sync health checks

https://docs.corelightning.org/docs/recovery

• Umbrel
• Raspiblitz
• myNode

https://github.com/ZmnSCPxj/clboss

1. Either disable clboss by default, or present a prominent notice before install saying that any funds deposited to this CLN node will automatically be used by clboss to open channels
2. Add some extra config options for the main clboss preferences: --clboss-min-onchain=, --clboss-auto-close=<true|false>, --clboss-zerobasefee=<require|allow|disallow>, --clboss-min-channel= / --clboss-max-channel=
   3. Add a page that shows the output of "clboss-status" command
   4. Add an "action" for "clboss-unmanage" and similar commands like "clboss-ignore-onchain"
   5. Update instructions with a CLBOSS section

Edit: 3, 4, and 5 moved, see this comment

Need these values to be user configurable so users don't need to ssh in to use the funder.

Also putting them in the config allows them to be persisted across restarts.

https://medium.com/blockstream/setting-up-liquidity-ads-in-c-lightning-54e4c59c091d

I've identified an issue where changes to the bitcoind RPC's user or password disrupt the operation of CLN. This issue is not related to Bitcoin v26, but rather to the services that depend on it.

When the password policy changes (as it did in Bitcoin v26), users are forced to update their passwords. This change seems to disrupt their CLN service.

The current behavior is that CLN reads RPC credentials only during configuration changes/saves. The expected behavior is for CLN to read RPC credentials on each service restart, regardless of configuration changes.

This issue needs to be addressed to prevent service disruption for old bitcoind users updating their passwords.

This is technically a browser interface but isn't the "main" interface for c-lightning. But it shows up in the UI as a button.

Perhaps we should just disable?

Currently only Core is available. LND allows Proxy, CL should as well

And probably default it to longer than 60s (upstream default).

This is because bitcoin's rpc is often slow to respond

https://lightning.readthedocs.io/lightningd-config.5.html#general-options

This is useful for replacing the protectionless in-place substitution we're currently doing in the migration to convert booleans to objects and vice versa.

See: #54 (comment)

Ideally this should be the system-generated cert from eOS

https://github.com/Ride-The-Lightning/c-lightning-REST#security

see https://github.com/ZmnSCPxj/clboss#operating for all commands

clboss-status: taken care of here, but could also be its own action: #56
clboss-externpay, clboss-ignore-onchain, clboss-notice-onchain, clboss-unmanage can all be actions
clboss-swaps: could be an action or a section in properties

https://github.com/talaia-labs/rust-teos

• #17
• #30

Edit: these too

• #24
• #29

Todo:
fix rest plugin cert
rename to Core Lightning in copy

#50

Should be easy since clboss-status already outputs yaml

C-Lightning reported crashing with the following:

The service c-lightning has crashed with the following exit code: 134 Details: Serving RPC on 0.0.0.0:8080 Generating a RSA private key ............+++++ ...................+++++ writing new private key to './certs/key.tmp.pem' ----- writing RSA key bitcoin-cli -rpcconnect=btc-rpc-proxy.embassy -rpcport=8332 -rpcuser=... -rpcpassword=... getblockhash 682356 exited 1 (after 99 other errors) 'error: server returned HTTP error 503 '; we have been retrying command for --bitcoin-retry-timeout=60 seconds; bitcoind setup or our --bitcoin-* configs broken? The Bitcoin backend died. lightningd: FATAL SIGNAL 6 (version v0.10.2-modded) 0x559487feb7 send_backtrace common/daemon.c:33 0x559487ff57 crashdump common/daemon.c:46 0x7fb4419a6b ??? ???:0 0x7fb4419af4 ??? ???:0 Log dumped in crash.log.20220419001924 Lost connection to the RPC socket. Lost connection to the RPC socket. Lost connection to the RPC socket. Lost connection to the RPC socket. Lost connection to the RPC socket. Lost connection to the RPC socket.Lost connection to the RPC socket. Lost connection to the RPC socket.

We need a comprehensive user's guide to CLBOSS in instructions. CLBOSS is complicated. Probably should wait until CLBOSS properties and actions are implemented

update to new package format for 0.3.0

• backup create
• backup restore
• configure
• actions
• health checks
• dependency configure
• start
• stop

c-lightning appears (and plugins) appear to be blocking smooth shutdown

This is so bitcoind will be enforced as a dependency of c-lightning only if bitcoind is in full archival mode

https://github.com/lightningd/plugins/tree/master/backup
https://youtu.be/_oaJc4ISzTE