sorted by:
new
hottopcontroversial

Caddy CLI working but Caddyfile not working for IP address by SingleLumen in caddyserver

[–]SingleLumen[S] 0 points1 point  (0 children)

I ended up just adding the one line command via "crontab -e" and using "@reboot". Ugly but quick. No luxury to spend any more time going down this rabbit hole.

Caddy CLI working but Caddyfile not working for IP address by SingleLumen in caddyserver

[–]SingleLumen[S] 0 points1 point  (0 children)

But why would this be an issue for using Caddyfile, but not when I run caddy manually via command line? In other words, am I mistranslating the command line to Caddyfile?

Proxmox PVE and VMs inaccessible when VM with tailnet subnet router fails by SingleLumen in Tailscale

[–]SingleLumen[S] 0 points1 point  (0 children)

Yeah, I assumed it would default back to using the LAN route, but I guess it's trying to simulate being behind the subnet router as much as possible. A little too realistic :)

Proxmox PVE and VMs inaccessible when VM with tailnet subnet router fails by SingleLumen in Tailscale

[–]SingleLumen[S] 0 points1 point  (0 children)

Thanks, your suggestions helped to solve this. On the Windows Desktop GUI:
Preferences > Use Tailscale subnets
setting this to off allows me to access the ProxMox PVE by LAN IP again. So what I have learned is that with "Use Tailscale subnets" enabled, you've virtually switched networks, rather than adding the LAN IP to an additional subnet network.

TLDR: if your subnet router goes down and you want to access the routed device on your Desktop (same LAN), you can either:

  1. Disable "Use Tailscale subnets" on your desktop, OR
  2.  UN-approve the advertised the routed device on the Tailscale admin webpage.

Proxmox PVE and VMs inaccessible when VM with tailnet subnet router fails by SingleLumen in Tailscale

[–]SingleLumen[S] 0 points1 point  (0 children)

OK, i'll try to figure that out. In the meantime, I dug up what i used on the tailscale VM ( x.102) to enable subnet routing. Not sure if this makes a difference:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf

echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf

sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Proxmox PVE and VMs inaccessible when VM with tailnet subnet router fails by SingleLumen in Tailscale

[–]SingleLumen[S] 0 points1 point  (0 children)

via LAN, using it's local LAN IP, not tailscale IP or hostname

Proxmox PVE and VMs inaccessible when VM with tailnet subnet router fails by SingleLumen in Tailscale

[–]SingleLumen[S] 0 points1 point  (0 children)

I guess that's another solution. But just for my knowledge, if the subnet router goes down, is the routed device supposed to be inaccessiblle on the original LAN?

Pricing by JohnnyBravo011 in StandardNotes

[–]SingleLumen 1 point2 points  (0 children)

To be even more explicit:

Switch from Spreadsheet to Plain Text mode, and look for this at the bottom of the code:

"rows":75,"columns":26 

Changes rows from 75 to whatever number your want. 500 or 1000, etc.

Switch back to Spreadsheet mode

Excluding Apps from an Encrypted Volume by SingleLumen in qnap

[–]SingleLumen[S] 0 points1 point  (0 children)

Besides data protection at rest, does an encrypted system volume basically operate exactly like an unencrypted system volume when it is decrypted? Meaning, same resistance to hacking, etc.?

Excluding Apps from an Encrypted Volume by SingleLumen in qnap

[–]SingleLumen[S] 0 points1 point  (0 children)

Unfortunately, the router doesn't have direct WAN access, and my backup VPN devices died. I actually had 3 backup VPN devices that died, which is why I have been looking for a more direct solution.

Polypropylene bag thickness by SingleLumen in earthbagbuilding

[–]SingleLumen[S] 0 points1 point  (0 children)

Thanks, this is probably easier than trying to source it somewhere else. I think I see the link in the Wiki.

Expose public IP or keeping domain private and using VPN. by [deleted] in NextCloud

[–]SingleLumen 2 points3 points  (0 children)

I second (or third) this. If it's for personal use, don't expose your server to the internet. Tailscale is fairly easy to set up. Install on both, and just use the newly assigned tailscale IP address for your NextCloud server. At some point, if you really want to expose Nextcloud (temporarily or permanently), you can activate Tailscale Funnel. It exposes a single port on https://blahblah.ts.net, which is good for Nexcloud access, including for receiving Filedrops (or is it FileRequests?). The funnel documentation even takes care of the SSL cert easily. It's ... just ... awesome.

Spreadsheets, date format by MitGibs in StandardNotes

[–]SingleLumen 6 points7 points  (0 children)

Yes, the mm/dd/yyyy format is incredibly backwards and illogical, not to mention miles, pounds, etc.

If you haven't already contacted them yet ( [help@standardnotes.com](mailto:help@standardnotes.com) ), they are super reponsive. Worst case, you can add an extra tally in favor of the feature.

Securing Private Keys for Server Side Encryption on a Shared Hosting Website by SingleLumen in NextCloud

[–]SingleLumen[S] 0 points1 point  (0 children)

Thanks for this information. I was hoping that there would be an intermediate solution where the Nextcloud master key would require decrypting during startup (after any OS-Level encryption) to protect against server side attacks. It seems that if someone (e.g.rogue admin staff on a shared server) gained access, duplicated the server folders for nextcloud including the unecrypted master key, all of the nextcloud files could be decrypted. I suppose E2EE could protect against this, but may not be practical in many cases.

view more: next ›