Avatar
bellsov
187857f50e00e066e411766b476ba84710a6fb53f51a4d17390f533b6eee5ccc
Fastest #OpenSource sovereign #DevOps individual on Nostr đź’¨

What's an all natural and effective way to reduce/eliminate a #tick population?

Glinet could be a good place to start.

You could put them behind a small pfsense-capable router if the wifi network is public or semi-public.

But still anyone who is on that router's wifi would be able to access the Bitaxes.

You could probably use the firewall in the router to only open the Bitaxe ports to specific IP addresses.

You could also isolate the Bitaxes via the router by using Tailscale and only allow access to the Bitaxes to IPs on the same Tailnet.

The other benefit to using the pfsense firewall is the ability to use a VPN to mask the Bitaxe IP.

I've found the most important thing is to keep it cool enough. I had issues with this early on, however figuring out the proper placement made all the difference.

Parents are the worst part of youth sports

Why #archlinux over #ubuntu?

I used to rely on keybase to pass around docs among devices. I don't believe keybase has been maintained for some time now and the file transfer seems to have stopped working.

In comes #Syncthing, which I've used for various things over the years. I now have multiple devices syncing through an encrypted and self-hosted server and passing docs around works really well.

One thing I don't like to rely on are the shared Syncthing discovery servers, so I configured Syncthing to run without using them.

Also, the docs weren't quite clear on how to config encryption so all docs are stored encrypted on the central server, while being decrypted by the remote devices. I finally figured it out. While not intuitive it is quite easy to do now that I understand how to do it.

Would anyone be interested in me further documenting this use case?

#foss #opensource

Replying to Avatar Tim Bouma

It all works seamlessly.

Yesterday, I fired up a completely separate instance of #nostr #safebox at https://openproof.org

Credential issuance, presentation and verification all worked seamlessly - as it was all one system. Better yet, zero https/rest/api calls between the two instances. Initial invocation was a visual channel (QR code) and the rest gift wrapped nostr events.

This is the future of inter-app coordination!

Is this similar to Hashicorp vault?

Ships frozen is unfortunately a non-starter for me.

Replying to Avatar Dr. Hax

OK, I'm looking for some help from a fellow lnd node runner.

Problem 1: My comnection to my peer keeps dropping about every 3.5 minutes

Logs say "pong response failure" and "timeout while waiting for pong response -- disconnecting".

The error in the peer's log says the same. That it also had a timeout while waiting for pong reaponse.

I can reconnect with no problem at all.

There is not any network issues such as packet loss (see notes on the pcap below for the evidence to back this up). Tor is not in the mix for this test.

I am able to sends sats if I do so quickly after connecting to the peer. So it seems like things can work properly if the connection issue can be sorted out.

I took a pcap of a connection, transaction and disconnection. Near the end, I see the client (node which initiated the connection) just absolutely slamming PSH,ACKs to the tune of 37 of them in just under 0.001 seconds. Then it sends a TCP Retransmission 0.006 seconds later and gets an ACK 0.036 seconds later, which is a perfectly reasonable response time.

The next batch is some TCP keepalives and keepalice ACKs. Some PSH,ACKs and ACKs in sub ms response time, followed by a retransmit and and ACK from the other side.

Finally 2 more keepalives and Keepalive ACKs in 0.012 seconds and then we get the FIN,ACK from the client followed by the RST,ACK from the server (remote peer to which we connected).

The FIN,ACK did come 5 seconds after the last ACK, so I feel like the server should have responded sooner, but at the same time I don't feel like a 5 second lag should cause a connection to be dropped and no attempt to ever be made to connect to it again. Also, these blitzkreigs of packets within 1ms is absurd.

Any ideas on where I should look next? I guess take pcaps on both sides and compare them?

This is absolutely brutal. I wouldn't expect most sysadmins to go through this much trouble to track down this issue, let alone any normal human be expected to do so.

No firewalls configured to drop packets or something like fail2ban that may be mis-characterizing and dropping packets?

Thanks, I forgot it was possible to download F-droid directly and install from the APK.