devuan_chimaera_4.0.0_i386_desktop.iso is an installer iso for an i386 architecture installation, plus a package pool that includes all packages including dependencies for a number of desktop installations.

devuan_chimaera_4.1_0_amd64_pool1.iso is a package pool only iso that doesn't contain the installer software. It contains the 5000 "most popular" packages for amd64 architecture installations according to popcon.debian.org at the date of the creation of the iso, plus their "depends" and "recommends".

@deepforest, why do you waste your time here?

By the looks of it, your devuan experience still leaves you so tremendously emotionally stressed that you end up with nonsense posts seemingly without purpose. Surely you have better things to do?

But maybe your purpose is really to ball-plank ideas on how to overcome whatever technical barrier you are currently at?

Indeed, there may well be people with knowledge and experience on that at this forum!

And to tap into that you simply just tune your manners more towards showing purpose and respect.

Currently I have duplicity at the top of my list of timeline backup methods as it's both fast and compact, and it's trivially easy to set up a cron job script that makes an incremental delta as often as I like.

I know of the front-end duply but only by name. (It's so rare that I need to peep into the backup)

Or you may need something like

        ip protocol icmp accept
        ip6 nexthdr ipv6-icmp accept
        ip protocol igmp accept

in the output filtering as well for ping responses.

Well I prefer the iptables rule syntax myself but if you prefer nftables then that's of course fine with me. Afaik, it's just a matter of syntax; either way it uses the kernel's network filtering rules, so I wouldn't be surprised if you can view the rules with iptables syntax or nftables syntax regardless of how you make the rules.

Whichever way, you need the input/output holes for 443 traffic similar to the current 80 or 22 traffic.

That's good; nginx does listen on port 443.

What do you get from

# iptables-save

EDIT: I reduced to the generic prompt "#"

Your last wget test some posts ago looked all fine. I wold not suggest that you start from the top.

Yes all configuration looks fine, although some ssl settings can probably be tuned. But it should connect and allow access. One thing missing is the ssl_dhparam setting which according to doc is required when/if DH ciphers are used. But I would have thought nginx would issue an error message when started/restarted if that would stop it from opening the ssl listener. Try with stopping nginx, then starting it, and check the error log.

Does that host have any local firewall?

Ok. hmm 203.220.142.95 would be me, yes.

Right. with wget -H http://www.realupnow.com I get that it connects on port 80, responds with redirect (301) to https, and then fails connection on port 443.

That is an indication that the ssl setup is wrong in some way. Perhaps you could show the log again, following your last entry.

Hmm nginx is running but not serving pages...

Where did those "managed by certbot" lines come from? That configuration file of post #89 is a bit different from the one you showed at post #57 and it confuses me... where did "default_server" comd from, and where did that ssl setup come from? And why is it "root /var/www" ? Is that really the right file? Did you (also:)) get tired yesterday?

The nginx log files are still in /var/log/nginx where it has error.log and access.log

mmm no the ssl-params.conf needs to be included outside of the location block... But it also seems you have at some time let certbot mess with the configuration and it has then given you a mix of stuff you may and may not want.

It's ok to use /etc/letsencrypt/options-ssl-nginx.conf instead of the currently non-existing /etc/nginx/snippets/ssl-params.conf although you of course will need to review that instead.

Just make sure to remove the "# managed by certbot" comment on that include line.

And in the future, do not ever, never, never run certbot with --nginx argument again as it will then want to mess with the configuration again. certbot might also have dropped a cron action (/etc/cron.d/certbot) to "do helpful things" that you may and might not want. That's another thing to review and clean up. (sometimes I wish that those "we must do it all" hats were much smaller)

Further certbot added stuff at the bottom of that service block, which amounts to enforcing a redirect response when the incoming request is not https. That's an ok function, but again I think you should remove the "# managed by certbot" comment.

So: what's in /etc/letsencrypt/options-ssl-nginx.conf ?

EDIT: I meant that file of course.