init crashed because it couldn’t load a shared library, but init isn’t allowed to be killed so the kernel panicked

Take a look for yourself:

https://www.pbtech.co.nz/ https://www.trademe.co.nz/a/

He says, forgetting what community he is in.

Bring your existing gear, remembering that we use 240v here. Getting used server bits is pretty difficult and expensive because we don’t have anywhere near the density of data centers selling off old stuff. Enterprise switches in particular seem to be hard to get, I’ve previously had to buy on eBay and pay absurd shipping

• https://github.com/prometheus/node_exporter?tab=readme-ov-file#textfile-collector - which makes node exporter watch a specific directory for files that contain metrics, then re-export them back to the central Prometheus server
• Some systems have their own metrics endpoints - instead of getting Prometheus to scrape these directly I set up a Cron job to curl these into files for node exporter - this means I don’t need extra config in Prometheus to find the endpoints, and don’t need to mess with firewall rules
• Other systems don’t directly expose metrics in a format Prometheus can use - in this case I will write/find a script that can do the conversation, then either set it up to write the metrics file directly and run it on a Cron, or run it as a service and another Cron job to do the scrape

• Base ansible role installs Prometheus node exporter, configured with the text file collector
• VM automations push DNS records so that the Prometheus dns-sd automatically discovers them
• Ansible roles for add Cron jobs that generate metrics for specific systems and dump them for the text file collector
• Grafana for dashboards
• Karma as a UI in front of Prometheus alert manager

• Back up your data now
• Reseat the cables for the drive
• Run a self test on the drive - smartctl -t long - if it doesn’t pass, then the drive is trash. If it does, then it might limp along a bit longer before catastrophically failing

Yup, this - batteries are consumables. They have a service life of ~2-5 years depending on load. If the manual doesn’t tell you how to replace them then it’s basically ewaste already

Depends on what you need:

• As cheap as possible, but actually want a VM: OCI free tier will be way bigger than you will probably need
• Happy paying money but still want to learn about Linux things: I’ve had good experiences with Scaleway
• I just want something I can set up and not think about: don’t use a VPS. Architect your site as a pure-static site, stick it in an S3 bucket. You’ll probably be within the free tier unless you do absolutely bonkers traffic, and once it’s running you can leave it alone for literal years without worrying about patches or upgrades

Good thing there hasn’t been any remotely exploitable security bugs in any of the mail system components in the 6 years since Debian 7 went EoL

If a project is hosted on sourceforge then its a pretty good sign that the developer hasn’t progressed their craft since about 2005, which is a pretty big red flag for anything

Running web services on a device that hasn’t seen a security patch in 3 years seems like a bad idea.

Also, unless you can mount a real hard drive, you are going to very quickly run into I/O bandwidth issues and flash longevity limits

Then don’t run a discord instance?

“Hey, the server is getting pretty toxic and I can’t be bothered moderating it - this is no longer an official communication channel, I’m not going to be hanging out here anymore, if you need help ask in the GitHub discussion forum”

Personally, if you can’t tell me if you are running Windows or MacOS, I don’t really want you downloading my software