+1 for more restrictions on DNS API tokens. Ways to mitigate the riscs:
- Separate account per domain .. which is a lot of work, see acceptation process in other comments
- Use a NS record for _acme-challenge.domain.tld when having the DNS hosted elsewhere and point this to the Hetzner DNS servers
$ apt install unattended-upgrades
# /etc/apt/apt.conf.d/99unattended-upgrades-custom
Unattended-Upgrade::Sender "Root at servername.domain.tld <servername.domain.tld@servicesdomain.tld>";
Unattended-Upgrade::Mail "services@servicesdomain.tld";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "05:00";
$ sudo systemctl edit apt-daily.timer
# Opens a new file /etc/systemd/system/apt-daily.timer.d/override.conf, paste this content:
[Timer]
# Reset the system calendar config first
OnCalendar=
# Set a new calendar timer with a 60 minute threshold
OnCalendar=*-*-* 03:00
RandomizedDelaySec=30m
$ sudo systemctl edit apt-daily-upgrade.timer
# Opens a new file /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf, paste this content:
[Timer]
# Reset the system calendar config first
OnCalendar=
# Set a new calendar timer with a 60 minute threshold
OnCalendar=*-*-* 04:00
RandomizedDelaySec=30m
.. and are auto-updated. When a reboot is needed after an update, it gets rebooted automatically.
In theory you are right. In practice this part of the system is having problems too:
- people who used to move on to a larger house stay because of the increased costs
- older houses are broken down and are replaced by newer ones … but due to building regulations fewer are build at the same place
- due to stagnation in outflow and decreased number of houses the waiting time for getting a “social house” is increased by a ridiculous amount. In Eindhoven it is more than 10 years - in theory. But due to rules about preferred placement it’s often way more.
We use TailwindUI - combined with Django gives a really nice kickstart on new projects. Just made a Proof of Concept last two weeks for an internal business app for a new customer and did impress them easy with a working app + login + responsive nice looking layout. Used VUEjs for menu's, keyboard events and a location picker.
For multi tenant deployments. Each tenant gets its own docker-compose in a directory on prod and voila: 100% same code base (same Docker image) and good separation between tenants
Multi-tenant deployments with Docker make sense _only_ if you trust all of the tenants, since it is trivial to take control of the host if you have write access to Docker socket.
You may say that it can be mitigated with some wrapper scripts with limited commands, but then you have to maintain them and we can all agree that homebrew security is very hard to do correctly.
Slightly of topic. About BrickLink. Just the other day I tried to order pieces for 7 MOCs on BrickLink. This works quite well but ...
- Don’t ever leave the store selection screen. You will loose your selection.
- When created your carts and then facing store restrictions like minimum avg lot price you might have to go back to square one
- After making some orders then and wanting to go to store selection ... you have the challenge to apply orders to wanted lists. You really should not use multiple wanted lists because you cannot easily apply multiple orders to multiple wanted lists
- Upgraded to seller to be able to use the API. Why this restriction?
- Had to create some scripts to combine orders and wanted lists to be able to create a new wanted list for ordering batch #2
But that’s BrickLink. Cool site BTW combining all those stores.