dr_robot

joined 1 year ago
[–] [email protected] 22 points 5 months ago (3 children)

It does not seem like you heard the arguments presented in the article. It isn't about being offended by any left or right wing politics, but because women engineers and scientists were uncomfortable about it for a variety of reasons. In a field which struggles to attract and keep female talent, this is a pretty big thing. The model herself spoke out and asked to be "retired from tech".

[–] [email protected] 44 points 7 months ago (1 children)

Logcheck. It took ages to make sure innocent logs are ignored, but now I get an email as soon as anything non-routine happens on my servers. I get emails with logs from every update, every time I log in, etc. This has given me the most confidence that nothing unexpected is happening on my servers. Of course, one needs to make sure that the firewall is configured well, and that you use ssh keys etc., but logcheck is how I know I'm doing enough.

[–] [email protected] 2 points 8 months ago

How do you upload a snapshot?

Basically, as you said. Mount the data somewhere and back up its contents.

I back up snapshots rather than current data, because I don't want to stop the running containers that read and write from that data. I'd rather avoid the situation where the container is writing data while it's being backed up. The back up happens shortly after the daily snapshot is made so the difference between current and snapshot data is small.

[–] [email protected] 4 points 8 months ago* (last edited 8 months ago) (2 children)

As others have said, with an incremental filesystem level mechanism, the backup process won't be too taxing for the CPU. I have ZFS set up which makes this easy and I make hourly snapshots using sanoid which also get sent to another mirrored pair of connected drives using syncoid. Then, once a day, I upload encrypted daily snapshots to a bucket in the cloud using restic. Sounds complicated, but actually sanoid/syncoid and restic do all the heavy lifting. All I did is automate their schedules using systemd timers and some scripts to backup the right directories.

[–] [email protected] 5 points 10 months ago (1 children)

Very interesting project! However, I can't help shake the feeling that whilst you pitch it as a platform for sharing DRM-free games, it will get used for sharing games against the licenses and wishes of publishers. I don't really care about the publishers, but do you not think there is a great risk that once your app gets enough attention, it will draw their ire and force you to shut down? Perhaps not directly, but e.g., removing you from the windows store etc.

[–] [email protected] 1 points 10 months ago

For caching, are you sure you're generating enough traffic to benefit from it? Plus, CDN caching's strength only really comes into play when the users are geographically distributed which isn't really the case for most self hosters.

For DDoS check if your VPS host does DDoS protection. Some do and include it for free. I've been monitoring my server traffic lately. Since I've ditched Cloudflare, I haven't needed DDoS protection.

You can still use Cloudflare DNS without redirecting traffic via their CDN. I do that.

The point about not revealing the IP address is a personal one it seems. I think it indeed does matter if that IP address is if your home, but not so much of it's of a VPS in some data center. But anyway, this point seems personal.

However, everything is a trade off and everybody has a personal take on which trade off they want to take. When I was in a similar situation, I ditched CDN proxying via Cloudflare though I still kept them for DNS.

[–] [email protected] 10 points 10 months ago (1 children)

My configuration and deployment is managed entirely via an Ansible playbook repository. In case of absolute disaster, I just have to redeploy the playbook. I do run all my stuff on top of mirrored drives so a single failure isn't disastrous if I replace the drive quickly enough.

For when that's not enough, the data itself is backed up hourly (via ZFS snapshots) to a spare pair of drives and nightly to S3 buckets in the cloud (via restic). Everything automated with systemd timers and some scripts. The configuration for these backups is part of the playbooks of course. I test the backups every 6 months by trying to reproduce all the services in a test VM. This has identified issues with my restoration procedure (mostly due to potential UID mismatches).

And yes, I have once been forced to reinstall from scratch and I managed to do that rather quickly through a combination of playbooks and well tested backups.

[–] [email protected] 2 points 10 months ago (2 children)

What benefit do you get from running a Cloudflare proxy if you're directing it to a VPS? I used to run with a Cloudflare proxy when my reverse proxy was hosted at home. Since then, I've moved it to a VPS and I no longer use the Cloudflare proxy, because I only expose the IP address of the VPS which is fine. Arguably Cloudflare provides you with DDoS protection, but that's so far never been a problem for me.

 

Does anybody have experience with both systems enough to compare them?

I'm currently using ifupdown on my Debian server as that's the default, but it seems that the modern way of managing the local network is via systemd-networkd so I'm contemplating putting the effort in to migrate.

Would those of you who have experience with it, recommend it?

In my short investigation, I have made the following observations:

  • using networkd means you can use networkctl to manually control the interfaces which is quite convenient
  • networkd aims to be fully declarative
  • networkd separates the creation of virtual interfaces (netdev files) from their configuration (network files)
  • networkd doesn't support all networking features (e.g. namespaces)
  • networkd is systemd, but surprisingly I can't find information on how to create other unit files that depend on the individual network files going up or down, other than networkd-dispatcher. I don't like dispatcher because just like ifupdown it triggers all the scripts and you need if tests to exclude all interfaces you don't need to be affected. I'd like to write unit files that can be targeted to activate and deactivate when a particular interface goes up or down.
  • networkd, other than via dispatcher, does not seem to support adding arbitrary commands to run like ifupdown supports via e.g. pre-down, post-up, etc.
 

Note: It seems my original post from last week didn't get posted on lemmy.world from kbin (I can't seem to find it) so I'm reposting it. Apologies to those who may have already seen this.

I'm looking to deploy some form of monitoring across my selhosted servers and I'm a bit confused about the different options.

I have a small network of three machines that I would like to monitor. I am not looking for a solution that lets me monitor tens, hundreds, or thousands of nodes. Furthermore, I am more interested in being able to observe metrics for each node individually rather than in aggregate. Each of these machines performs a different task so aggregate metrics from these machines are not particularly meaningful. However, collecting all the metrics centrally so that I can have a single dashboard to view them all in one convenient place is definitely something I would like.

With that said, I have been trying to understand the different (popular) options that are available and I would like to hear what the community's experience is with these options and if anybody has any advice on any of these in light of my requirements above.

Prometheus seems like the default go-to for monitoring. This would require deploying a node_exporter on each node, a prometheus service, and a grafana dashboard. That's all fine, I can do that. However, from all that I'm reading it doesn't seem like Prometheus is optimised for my use case of monitoring each node individually. I'm sure it's possible, but I'm concerned that because this is not what it's meant for, it would take me ages to set it up such that I'm happy with it.

Netdata seems like a comprehensive single-device monitoring solution. It also appears that it is possible to run your own registry to help with distributed monitoring. Not gonna lie, the netdata dashboard looks slick. An important additional advantage is that it comes packaged on Debian (all my machines run Debian). However, it looks like it does not store the metrics for very long. To solve that I could also set up InfluxDB and Grafana for long-term metrics. I could use Prometheus instead of InfluxDB in this arrangement, but I'm more likely to deploy a bunch of IoT devices than I am to deploy servers needing monitoring which means InfluxDB is a bit more future-proof for me as it could be reused for IoT data.

Cockpit is another single-device solution which additionally provides direct control of the system. The direct control is probably not so much of a plus as then I would never let Cockpit be accessible from outside my home network whereas I wouldn't mind that so much for dashboards with read-only data (still behind some authentication of course). It's also probably not built for monitoring specifically, but I included this in the list in case somebody has something interesting to say about it.

What's everybody's experience with the above solutions and does anybody have advice specific to my situation? I'm currently leaning to netdata with my own registry at first and later add InfluxDB and Grafana for long-term metrics.