start9labs / cln-startos Goto Github PK

https://github.com/ZmnSCPxj/clboss

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

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

• Umbrel
• Raspiblitz
• myNode

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

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

• #17
• #30

Edit: these too

• #24
• #29

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

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.

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

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.

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)

Placeholder, as Peerswap is considered fairly early at this time

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

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

Prism plugin

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

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

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

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?

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

Prerequisites

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

Device

Laptop/Desktop

Device OS

Other

Device OS Version

startos

Browser

Firefox

Browser Version

127

Current Behavior

Installed CLN from scratch and now it is stuck in

Waiting for system cert key file...

I did a search and found that I am hitting this line:

I have no idea what's going on. My start9 /mnt dir does not have anything.
Shouldn't CLN generate a system cert key file?

Cc @chrisguida since 48e6bbb introduce these lines.

Expected Behavior

CLN should start from a fresh install in StartOS and not be stuck in a infinite loop.

Steps to Reproduce

1. Install CLN from scratch
2. Run and see the logs

Anything else?

Prerequisites

• I have searched for existing issues that already suggest this feature.

Describe the Feature Request

Expose CLNRest url, rune, and port in properties

Describe the Use Case

Connecting to clients that use CLNRest

Describe Preferred Solution

No response

Describe Alternatives

No response

Anything else?

No response

In experimental features

update to new package format for 0.3.0

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

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

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

See lnd and bitcoind for examples of sync health checks

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

Optional healthcheck (if a watchtower client has been added) to let user know if (and perhaps how many) clients are online.

May also be desirable to have a watchtower server healthcheck to verify that your server can be reached by remote clients.

This may start to crowd the service page. Perhaps this real estate is being reconsidered for 036/040

#50

Should be easy since clboss-status already outputs yaml

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.

Ideally this should be the system-generated cert from eOS

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

For example, you may wish to label a watchtower as "Uncle Jim's WT" - so that you know who to contact if it goes offline

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

Namely for better performance