Thanks :D

(ironically) oyster meal 💀

off for a few days and then this honker popped up. So next round I’m doing only 10-15 minutes of fan per day. Maybe even less Good to know! I have some blocks almost fully colonized. I wonder if putting them to fruit in an open room (my living room) is already too much air flow for them.

We need /c/infuratingasfuck

So, how is the situation with the white spots? Did they end up being benign?

After lots of testing I found a configuration that works for me! In the end it is very simple, but I am quite a newbie at this so it took some effort to figure out what works. ChatGPT helped a bit too - and also confused me a lot - but it helped.

What I do now is:

I set up a wireguard tunnel. The VPS in this example has the ‘wireguard’ ip of 10.222.0.1, and my home network is 10.222.0.2. These are my configs (/etc/wireguard/wg0.conf):

VPS wireguard config:

[Interface]
Address = 10.222.0.1/24
ListenPort = 51820
PrivateKey = <VPS Private key>

[Peer]
PublicKey = <Home network public key>
AllowedIPs = 10.222.0.2/32
PersistentKeepalive = 25

Home network (Respberry pi) config :

[Interface]
Address = 10.222.0.2/32
PrivateKey = <Home network private key>

[Peer]
PublicKey = <VPS Public Key>
Endpoint = <VPS_IP>:51820
AllowedIPs = 10.222.0.0/16
PersistentKeepalive = 25

Then, I use the following iptables commands in the VPS to map requests to port 80 and 443 to the ports 80 and 443 of the tunnel. What really confused me for a while was that I did not know that I needed to include the “POSTROUTING” step so that the packets get sent back the correct way:

IP tables in VPS:

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.222.0.2:443
iptables -t nat -A POSTROUTING -p tcp -d 10.222.0.2 --dport 443 -j SNAT --to-source 10.222.0.1
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.222.0.2:80
iptables -t nat -A POSTROUTING -p tcp -d 10.222.0.2 --dport 80 -j SNAT --to-source 10.222.0.1

Then, in my home network I use the standard nginx config:

server {
  server_name website.com;
  listen 80;
  location / {
        return 301 https://$host$request_uri;
  }
}

server {
  server_name website.com;
    listen 443;
    location / {
        proxy_set_header Host $host;
        proxy_pass http://0.0.0.0:<Website Port>;
    }
    # certificate management here
    ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/website.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

This configuration seems to work, and since both ports 80 and 433 are mapped you can use certbot to generate and renew the SSL certificates automatically.

I am still learning, and this is the first thing that worked - so there might be a better way! But a lot of things I tried would not complete the SSL handshake correctly.

In that case, you’re better off just using the VPS machine as port forwarding port 443 to your home machine’s wireguard IP address and handle the SSL/TLS termination on the home machine.

This is what I would like to do! I was trying to handle the SSL termination ‘automatically’ by simply forwarding the connections to 443 of my machine’s wireguard IP using nginx, but I did not manage to get it to work. That’s when I found that I need to use something like ‘stunnel’ to handle the SSL termination. But I think that you may be suggesting an even simpler method of using port-forwarding instead of the reverse proxy. I am not sure how to achieve that, I will look into it using these terms.

ssh tunnels

There are so many concepts to learn about! But if the SSH tunnel improves the the available useful bandwidth compared nginx/wireguard, it might be worth looking into it too. Thanks!

Thanks a lot! This is kind of the configuration that I have converged to, with nginx and WireGuard. The last thing I need to set up correctly is for the SSL handshake to occur between the client and my home server, and not between the client and the internet-facing VPS, such that the information remains encrypted and unreadable to the VPS. The two strategies that I have seen can do this is SNI routing with nginx or to use stunnel. I still have not been able to set up either!

Wow! What is the substrate? Do you have any special tips for making them grow this large?

What you can do is buy 2 plants and rotate them every week

What a good idea! I have a few potted sanseverias and I might experiment with a rotation like this one. I will feel a bit bad bringing one into the darkness while the others stay in the sun… But I have often thought that a plant would look nice in the bathroom.

That’s the next topic then. Thank you

Oh, cool! I have managed to do it with the Wireguard tunnel! I set up a tunnel and use the nginx proxy_pass to redirect through the tunnel. It is pretty nifty that I don’t even need to port-forward!

My next step is: in my current configuration, the SSL handshake occurs between the VPS and connecting client. So the VPS has access to everything that goes through… I need to figure out how to hand-shake through the tunnel such that the VPS does not get the SSL keys.

Thanks a lot for your suggestion!

Sanseverias are quite resilient to low light and erratic watering, but I don’t think any plant will “thrive” with little light. It will survive for a long time.

Thanks! Wireguard was suggested as a VPN, and I am currently playing with that.

From what I have learned today, I think that Wireguard Tunnel is what I want!

First I was able to use nginx as a reverse proxy to route the information from my home network through the VPS. But with this approach the client would do the SSL handshake with the VPS, and then the VPS fetches information from my home network via HTTP. Since there is no encryption layer between my VPS and my home network, I suppose that the flow of information between my home server and the VPS is insecure.

Then, I need to establish some form of encrypted connection between my home server and the VPS… And that is where the Wireguard Tunnel comes in! This tunnel allows me to transfer the information with encryption.

I am still reading and setting it up, but yeah, I’m liking this, thanks!

You may be seeing pics faster that I expected!

Great!!

That one has little white dots all over the kernels throughout the jar

Hmm, that is suspicious. Did you inoculate using a liquid culture? If you spread the liquid culture throughout the grains, it could look like that… But if your inoculant is more localized (spawn, agar, or tissue) and the whit spots appeared all over the grain, you might not be so lucky 😰

Thanks! That seems to come with even more protections than simply hiding the IP, so it is worth definitely worth considering!

Thank you!

By using the VPN connection, you wouldn’t even need to open a port on your home network which is a great starting point for security as well.

Hmm, what do you mean with this? I would need to at least open one port to route the connection to the nextcloud instance in my home network - right?

Reverse SSH… I’ll look into it. What I am thinking is that I may be able to run the reverse proxy on the VPS directly, and then direct it towards the nextcloud port in my home network.

Well you learn through experience!! I find it useful to write observations like this in my electronic notes. In the short term it might feel like you will remember how much the popcorn expanded forever, but you might not use popcorn again for a year or two and then choose to try it out again - and then it can be helpful to look back at your popcorn notes and remember what you experienced!

Good luck transferring the mycelium to the grains!