screaming in digital

combine your VMs with a little layered LXC garnish for that special touch :-)

are you able to give additional info on the DNS issue you had?

dont discount the utility of running containers in an abstracted Hardware Virtual Machine (HVM) away from your physical hardware. it expands your testing surfaces and sandboxes immeasurably.

honestly, I have always had pretty decent experiences with non-oem lead-acid batteries. my local battery place has a decent supply and longevity is roughly the same as the oem ones (3-4 years). I have never had any issues (type or frequency) that were not also an issue with oem batteries.

almost no UPS mfcr makes their own batteries, so if you strip off the labeling from the oem ones, you may even find an exact replacement.

edit: another advantage of a local place is the core-return rebate and disposal of your old batteries.

spaghetti is delicious for a reason.

in-line all your code and avoid the linker :-)

agreed. you are using DNS-01 challenges. so the workflow is…

your local certbot machine initiates an https connection to the letsencrypt servers to start the DNS-01 challenge. during this HTTPS dialog, your local certbot is informed of the key material to insert into your DNS records. your local certbot then modifies your netcup DNS server (hosted remotely, not on your local network) with the keying material and the letsencrypt servers verify that the keys are actually there, proving that you control the domain. the letsencrypt serves then issue you the certificate (again, via HTTPS) and your local certbot stores it in your local host.

the issue is most likely stems from the initial HTTPS connection that certbot tries to make to the let’s encrypt servers. while your firewall allows this traffic out, it does not allow return traffic back in because of your explicit blocking of US (and perhaps other) based addresses.

even through your are using DNS for your domain autentocation, your local host - the machine running certbot - is unable to initiate the certificate transfer because of the firewall blocking return traffic.

the two external networks (and, therefore IP ranges/subnets/etc) that are important here are the let’s encrypt servers and the netcup DNS servers. certbot will have to talk to both of these in order to function.

not sure what you mean by external DNS

not hosting your own DNS server. specifically it sounds like your DNS server is hosted on your domain provider, not your own local network. you have set up certbot to automatically configure your remotely hosted DNS server for the DNS based renewal.

if DNS based recert was working before then it should be working now.

as I said in my edit, you are likely blocking the return https traffic from the US based let’s encrypt acme servers - so your initial diagnostic is correct. your local firewall is likely stopping the acme servers from talking back to your local host.

you are right back where you started, asking for info in how to allow-list the acme IP ranges. but at least we may now know why it is not working and you are seeing an https timeout even though you are using DNS based certificate renewals.

edit: typos

The DNS server/root isn’t in my home network

are you using external DNS hosting? is it in a (now) blocked country? if so, then your local certbot is unable to update the DNS server records (return traffic from your DNS host is being blocked by your iptables/nftables config).

error: HTTPSConnectionPool(host=‘acme-v02.api.letsencrypt.org’, port=443): Read timed out. (read timeout=45)

yeah, that would suggest an https renewal method. had you previously configured web server renewal at all before switching over to DNS? any other suspicious notifications in the logs?

edit: in thinking about this a little more… the renewal has to be initiated by your host, and that is likely done via https (you talk https to the acme server and tell it you want a renewal by DNS). so, if you are blocking the acme servers then the same issue applies - no return traffic.

not only is noscript your general browsing prophylactic, but it will often render js paywalls climbable. I have no other plugin as loved and as useful as noscript - immediate install on any firefox instance.

dammit! where can I send you my “spat coffee on keyboard” cleaning bill, huh?!

depending on specs it will be a little power hungry, but a good virtualization platform.

yes, the power supplies are likely redundant and the server will complain if they are not both powered.

it will use a VGA connection, but you should be ale to find cheap VGA monitors or cheap adapters.

RAID controllerfor those drives? how many processors and cores? how much RAM? what OS are you planning on running on it? iDRAC included? (if so, likely idrac6, but still usable)

this hardware is very well supported by linux - I have used these older servers extensively. your boss was right to be excited for you. its a great exploration platform that you will be able to do lots of things with.

fire up a live linux distro and get detailed specs on the box - that will guide what you can play with right away.

indeed. it will serve you well in many, many… situations.

or, if you are really lucky, you can poke the right locations and release the magic blue smoke from the chips. super fun and all the cool kids are doing it.

seeing it now on fdroid.

quassel and quasseldroid. its client-server, always on irc connectivity but does require a little setup.

you can access irc servers (if acceptable) and the quassel daemon via Tor. might just change the way you think about irc.

edit: word

…that wireless mac is looking suspiciously shopped and non-existent.

AROS (Amiga) Research Operating System

Wikipedia

Official Page

would run in an emulator or bare metal boot from separate media.

ERROR: Attempted to parse HTML with regular expression; system returned Cthulhu.

classic.

heh, forgot about the standalone web server in certbot. thats a good ephemeral option.