When a company makes it impossible to correct their stupidity, it's a malicious act. The behavior speaks loud and clear: "We don't care what damage we do to developers or users. And we don't want to hear about it."
Yes, I see that AWS Route53 can limit credential scope. That kind of thing helps a lot.
I've never heard of that CNAME approach for changing the validation domain. That looks like a viable solution since it requires a one-time setup on the main domain and ongoing access to the second (validation) domain.
Moving subdomains to separate zones can make sense for a small set of subdomains and all your certificates would be for names under those subdomains. It gets unwieldy if you have to create a separate zone for each certificate because the certificates don't share a subdomain. But this can be a solution in some circumstances. Thanks.
Some of this might have been "because I want to see if I can". Another reason is "It bothers me to keep seeing this browser tell me my connection is insecure".
As for putting it on a separate VLAN and securing traffic with firewall rules, that may be as much or more trouble than setting up the automated certificate renewal. At least with the automated certificates there may not be any further maintenance required. With firewall rules, you'll need to open up the firewall each time you want a new device to access the printer.
I read a lot about people running things like Caddy which will automatically retrieve Lets Encrypt certificates. And I think it makes sense for publicly accessible web sites since you can use an HTTP challenge with Let's Encrypt.
For internal-use certificates, you'll have to make use of a DNS challenge with Let's Encrypt. I've been hesitant to set that up because I'm concerned about the potential compromise of a token that has permissions to edit my DNS zone. I see that the author creates exactly that kind of token and has permanently accessible to his script. For a home lab where he's the only person accessing his hardware, that's less of a concern. But what about at a company where multiple people may have access to a system?
Am I being too paranoid here? Or is there a better way to allow DNS challenges without a token that allows too much power in editing a DNS zone?
For me it's usually related to modifying partitions, changing disks, OS upgrades going wrong, or some minor disk corruption.
It's not common, but if you manage enough systems then even rare things happen enough that you'll need tools like this in your tool belt.
I usually reach for a live-OS booted off a USB drive (Ventoy is good for having lots of OS options on a single USB drive) but I'd be interested in giving this a try.
And this is the difference between competence and incompetence in tech. We can argue about whether 10x developers exist, but one thing I hope we can agree on is this: Certain problems can't be solved no matter how many incompetent people we throw at the problem.
I would definitely be interested in reading more about this.
I love the idea of being able to prevent an application from writing all over my disk to random places. If I can't prevent it, I can at least remedy it by having all those changes go away with a reboot.
One of the things I love about Docker containers is that they can be ephemeral or persistent, short or long term, have full network access or no access, allowed to write to the host system or stuck writing to its own file system only.
I remember a previous employer sending out a survey to several customers to get feedback on the product. The boss who had the survey sent never bothered read the survey results, and he never sent them to anyone else either.
I'm sure he's not alone in ignoring important feedback. I'm sure feedback from people leaving the company is generally ignored too.
If you have important concerns to bring up in the exit interview, then why didn't you bring it up previously?
When I left a previous job, I didn't say any of the reasons why I was leaving. All the problems in the company had been previously expressed by me or other people MULTIPLE TIMES. The problems were always ignored. I didn't want to bring them up again just to have someone argue that those problems "aren't that big of a deal" or "must not be the real reason you're leaving" so I kept my mouth shut.
I'm not the one you're replying to, but I one problem I've had with Ansible directory copying is that it's terribly slow.
Using the "state" parameter for files and directories is also rather odd. You specify "state: absent" to delete, "state: directory" to create a directory. It makes sense considering the declarative nature of Ansible, but it's unfamiliar to those used to writing shell scripts.