![](https://lemmy.world/pictrs/image/f9957653-c5f6-4b0f-8b76-9113a227152c.jpeg)
![](https://lemmy.world/pictrs/image/8286e071-7449-4413-a084-1eb5242e2cf4.png)
- ansible playbook for automated/self-documenting setup
- for one-off bugs or ongoing/long-term problems, open an issue on my gitea instnce and track the investigations and solutions there.
I would never recommend Odoo anymore, given how painful it is to upgrade from a major version to another. Their answer to it is basically “yeah, some complex migrations need to be done, just send us a copy of your database with highly sensitive company data, pay us to do the migration and we’ll send it back to you”. Yeah, lol, no.
example preseed file which I use to provision new servers (VMs)
I use netdata (the FOSS agent only, not the cloud offering) on all my servers (physical, VMs…) and stream all metrics to a parent netdata instance. It works extremely well for me.
Other solutions are too cumbersome and heavy on maintenance for me. You can query netdata from prometheus/grafana [1] if you really need custom dashboards.
I guess you wouldn’t be able to install it on the router/switch but there is a SNMP collector which should be able to query bandwidth info from the network appliances.
I agree that desktop/ATX tower PCs are the most useful form factor, you can stuff all your old junk hardware in there and offer it a second life without much investment.
However with current electricity prices buying more power efficient hardware can be a better medium-term investment. 1kWh bills at 0.2516€ currently where I’m at (~EU average price), assuming an average power consumption of 50W this gives you (50×24×365)/1000×0.2516=110€/year. At this rate a 200€ investment in hardware would pay for itself in 2-3 years.
Buying a <100€ setup is not worth it for general purpose servers in my opinion, it will either be underpowered or power hungry.
My current solution is to to run all my services in KVM (libvirt) VMs on my beefy desktop computer which is already on most of the time anyway. Best of both worlds.
If I had to redo everything I would probably buy a NUC/mini-PC with a good CPU, 64GB RAM and low power consumption, stash a single huge SSD in there, migrate my VMs there and call it a day. But this is not a cheap setup.
Netdata can also expose metrics to prometheus which you can then use in Grafana for more advanced/customizable dashboards https://learn.netdata.cloud/docs/exporting-metrics/prometheus
I just don’t have that much time to spend on initial implementation and upkeep
Well k8s is a poor choice of platform for you :D
lsblk
also show block devices and is prettier than looking directly at /sys/class/block
https://github.com/chriswayg/ansible-msmtp-mailer/issues/14 While msmtp has features to alter the envelope sender and recipient, it doesn’t alter the “To:” or “From:” message itself. When the Envelope doesn’t match these details, it can be considered spam
Oh I didn’t know that, good to know!
The proposed one-line wrapper looks like a nice solution
You can definitely replace senders with correct mail addresses for relaying through SMTP servers that expect them (this is what I do):
# /etc/msmtprc
account default
...
host smtp.gmail.com
auto_from on
auth on
user myaddress
password hunter2
# Replace local recipients with addresses in the aliases file
aliases /etc/aliases
# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: default
www-data: root
default: myaddress@gmail.com
(the only thing I changed from the defaults in the aliases file is adding the last line)
This makes it so all/most system accounts susceptible to send mail are aliased to root, and root in turn is aliased to my email address (which is the one configured in host/user/password
in msmtprc)
Edit: I think it’s actually the auto_from
option which interests you. Check the msmtp manpage
Don’t mind him. He’s always there ranting about who knows what whenever software he dislikes is mentioned. Lookup his comment history for more of the same.
Easiest method to summon him is to mention Nextcloud and Proxmox in the same sentence.
Usually you would have a second DNS resolver configured in /etc/resolv.conf (or whatever name resolution config system you are using, resolvconf, systemd-networkd, etc). The system will fall back to this resolver if the first resolver fails to respond (and/or replies NXDOMAIN, I’m not sure. The exact order and fallback conditions may vary depending on which system you use). This can be another dnsmasq instance, a public DNS resolver, your ISP’s resolver, etc. This allows at least basic DNS resolution to work before your dnsmasq instance comes back up.
I would also add automatic monitoring for dnsmasq (either check that the service/container is running, or check the TCP connection to port 53, or check that DNS resolution is working for a known domain, etc)
msmtp
never failed me
Not an answer but still relevant: I actively avoid enabling unattended-upgrades for third-party repositories like Docker (or anything that is not an official Debian repository) because they don’t have the same stability guarantees, and rely on other upgrade notification methods instead.
how bad of an idea is this to run a DNS in docker and use it for the host and other containers?
Personally I would simply install dnsmasq directly on the host because it is one apt install
and a configuration file away. Keep it simple.
See you back on Debian in a few months
How does this compare to https://awesome-selfhosted.net/ ?
“buggy as fuck” because there’s a bug that makes it so you can’t easily run it if your locate is different than English?
It sends pretty bad signals when it causes a crash on the first lxd init
(sure I could make the case that there are workarounds, switch locales, create the bridge, but it doesn’t help make it appear as a better solution than proxmox). Whatever you call it, it’s a bad looking bug, and the fact that it was not patched in debian stable or backports makes me think there might be further hacks needed down the road for other stupid bugs like this one, so for now, hard pass on the Debian package (might file a bug on the bts later).
About the link, Proxmox kernel is based on Ubuntu, not Debian…
Thanks for the link mate, Proxmox kernels are based on Ubuntu’s, which are in turn based on Debian’s, not arguing about that - but I was specifically referring to this comment
having to wait months for fixes already available upstream or so they would fix their own shit
any example/link to bug reports for such fixes not being applied to proxmox kernels? Asking so I can raise an orange flag before it gets adopted without due consideration.