All of this user’s content is licensed under CC BY 4.0.
But it doesnt really ‘nuke’ existing ones.
How come I don’t see my previous rules when I dump the ruleset, then? I have my rules written in /etc/nftables.conf, and they were previously applied by running nft -f /etc/nftables.conf. Now, when I dump the current ruleset with # nft list ruleset, those previous rules aren’t there — all I see are Docker’s rules.
How come I don’t see my previous rules when I dump the ruleset, then? I have my rules written in /etc/nftables.conf, and they were previously applied by running nft -f /etc/nftables.conf. Now, when I dump the current ruleset with # nft list ruleset, those previous rules aren’t there — all I see are Docker’s rules.
As long as it’s faster than the snap, it’s worth it to me 😜
Which docker image do you use? AIO?
Which docker did you use, out of curiosity?
Which docker are you using? Is it the AIO docker?
Did you do anything special configuration-wise, or did you, more or less, just deploy the AIO docker as-is?
Thank you for sharing this! I hadn’t heard of this before.
Possibly some old configuration on your backend from the letsencrypt beforehand?
Are you referring to the original HTTPS configuration for Let’s Encrypt for domain.com? I haven’t disabled that yet. Should I entirely disable HTTPS for the Nextcloud server?
Have a look at your next cloud backend http logs to see what requests are arriving there and what HOST( http header ) it’s trying to connect to on that IP.
I’m not entriely sure where to find what you are referring to. I checked the Apache logs for Nextcloud, and I didn’t find anything.
Your first configuration results in the following when I access nextcluod.domain.com from both within and outside the LAN:
400 Bad Request
Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
This is an interesting response, because it’s what I see when I try to access the server from 192.168.1.182:443 from within the LAN. Which, I assume, is to be expected when a port has TLS enabled – one should access it from 192.168.1.182:80 instead; however, when I modify your suggestion to be from port 80, rather than port 443, it results in the usual
301 Moved Permanently
Moved Permanently
The document has moved https://nextcloud.domain.com:443/
Your second configuration results in the following when I access nextcloud.domain.com from both within and outside the LAN:
Client sent an HTTP request to an HTTPS server.
Side note: I do still have the original HTTPS setup with Let’s Encrypt enabled on the Nextcloud server for domain.com. Is that causing the issue? I’d rather not disable that unless I need to, at the moment.
Here is the output of wget --spider https://nextcloud.domain.com:
Spider mode enabled. Check if remote file exists.
--2024-02-21 09:20:41-- https://nextcloud.domain.com/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving nextcloud.domain.com (nextcloud.domain.com)... public-ip
Connecting to nextcloud.domain.com (nextcloud.domain.com)|public-ip|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://nextcloud.domain.com:443/ [following]
Spider mode enabled. Check if remote file exists.
--2024-02-21 09:20:46-- https://nextcloud.domain.com/
Connecting to nextcloud.domain.com (nextcloud.domain.com)|public-ip|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://nextcloud.domain.com:443/ [following]
Spider mode enabled. Check if remote file exists.
--2024-02-21 09:20:46-- https://nextcloud.domain.com/
Connecting to nextcloud.domain.com (nextcloud.domain.com)|public-ip|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://nextcloud.domain.com:443/ [following]
Spider mode enabled. Check if remote file exists.
[...]
[I deleted a bunch of repetitions]
[...]
--2024-02-21 09:20:48-- https://nextcloud.domain.com/
Connecting to nextcloud.domain.com (nextcloud.domain.com)|public-ip|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://nextcloud.domain.com:443/ [following]
20 redirections exceeded.
And here is the contents of the cookie file (it is empty):
# Netscape HTTP Cookie File
# https://curl.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.
Running curl --location https://nextcloud.domain.com results in
curl: (47) Maximum (50) redirects followed
I’m not exactly sure what the previous issue was, but it appears that, possibly, the previous bridge that was in use was broken in some way. I have since switched the primary router to one that supports WDS, and created a WDS bridge between the two, and now everything is working as expected.
Fair points! I hadn’t considered these nuances.
Did you forget to complete your reply, or did it perhaps glitch out?
Indeed it is not. Do you, by chance, have any suggestions – troubleshooting, alternatives, etc.?
[…] so there are other possibilities than a standard desktop computer.
Would you mind elaborating? I’m curious to know what you’re referring to.
The fact that it’s a “single board” computer, specifically, is mildly irrelevant, imo; just follow standard backup practices. The only way the type of computer really comes into question is whether or not it has adequate resources to run whatever backup solution that you choose. For my usecase, Borg works great, but choose whatever solution fits your requirements. The “simplest”, and lightest solution is probably rsync, but that may leave a lot to be desired.
What issues did you have with the AIO docker?
How come I don’t see my previous rules when I dump the ruleset, then? I have my rules written in
/etc/nftables.conf, and they were previously applied by running# nft -f /etc/nftables.conf. Now, when I dump the current ruleset with# nft list ruleset, those previous rules aren’t there — all I see are Docker’s rules.