[-] dr_robot@kbin.social 22 points 7 months ago

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".

[-] dr_robot@kbin.social 11 points 8 months ago

Many open source projects are not developed by unpaid volunteers. The Linux kernel, for example, is primarily developed by professionals on paid time. I'm not convinced the Linux kernel development would continue without business contribution. I'm not convinced all open source projects could just continue without any payment.

[-] dr_robot@kbin.social 44 points 9 months ago

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.

54
submitted 11 months ago* (last edited 11 months ago) by dr_robot@kbin.social to c/linux@lemmy.ml

I'm looking to organise my paper mail with the help of a scanner and some document management system for Linux.

Does anybody have any suggestions?

The paperless-ngx project is sort of what I'm looking for, but I don't really want or need to run it in a selfhosted manner. I have a selfhosted server on which I could easily add it, but since I don't really need or want this to be available online in any way (even on my local home network) I don't really want that overhead.

I would prefer an application in the manner of what Calibre is for ebooks. That is, it operates on a locally stored library and that's it. No web server.

[-] dr_robot@kbin.social 10 points 11 months ago

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.

[-] dr_robot@kbin.social 25 points 1 year ago

I wish :( The city centers are very walkable and there's plenty of safe bicycle infrastructure, but cars are still very clearly the dominant mode of transport. Every weekend there's queues to the parking garages in every part of the city.

299

To build a fully climate-neutral transport system in the Netherlands, many citizens will have to give up their cars, Jan Willem Eirsman, the government’s new chief climate adviser as chairman of the Scientific Climate Council, told the AD.

[-] dr_robot@kbin.social 6 points 1 year ago

Wireguard easily supports dual stack configuration on a single interface, but the VPN server must also have IPv6 enabled. I use AirVPN and I get both IPv6 and IPv4 with a single wireguard tunnel. In addition to the ::/0 route you also need a static IPv6 address for the wireguard interface. This address must be provided to you by ProtonVPN.

If that's not possible, the only solution is to entirely disable IPv6.

[-] dr_robot@kbin.social 21 points 1 year ago

Most open source vpn protocols, afaik, do not obfuscate what they are, because they're not designed to work in the presence of a hostile operator. They only encrypt the user data. That is, they will carry information in their header that they are such and such vpn protocol, but the data payload will be encrypted.

You can open up wireshark and see for yourself. Wireshark can very easily recognize and even filter wireguard packets regardless of port number. I've used it to debug my firewall setups.

In the past when I needed a VPN in such a situation, I had to resort to a paid option where the VPN provider had their own protocol which did try to obfuscate the nature of the protocol.

12

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.
50

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.

[-] dr_robot@kbin.social 45 points 1 year ago

Maintaining legacy options is always maintenance overhead or things you need to work around when implementing new features. I suspect that they've concluded that not enough people use it anymore to justify the overhead.

[-] dr_robot@kbin.social 33 points 1 year ago

Plasma is amazing. It has been my DE of choice for years now. So happy I'm donating to the project.

[-] dr_robot@kbin.social 19 points 1 year ago

I recommend fastmail.com though they do have done shortcomings that you need to consider such as the fact that they're based in Australia (five eyes country) and have servers in the USA. Their advantage is a slick interface, fantastic app based on JMAP, and just generally being super convenient. They allow catch all addresses, masked emails, custom domain etc. I find them super convenient.

[-] dr_robot@kbin.social 6 points 1 year ago

If it was just storage/RAM scraping then that could be solved with SSL pass-through though. That way the reverse proxy would not decrypt the traffic and would forward the encrypted traffic further to the home server. I was actually setting that up a few hours ago. However, since the VPS provider owns the IP address of the VPS, they can simply obtain their own certificate for the domain. After all, Let's Encrypt verifies your ownership of the domain by your ability to control the DNS entries. Therefore, even if the certificates weren't on the VPS, the fact that I am redirecting traffic via their IP address makes me vulnerable to a malicious provider.

The "hobby exercise" was just to indicate that this is not for work and that I'm interested in an answer beyond "you need to trust your provider" which I do :) I agree, these are important questions! And they're also interesting!

37

I run a self-hosted server at home on which I have run a bunch of personal stuff (like nextcloud etc.). To prevent pointing DNS servers at my home router, I run a reverse proxy on a VPS that I rent (from Scaleway FWIW).

Today I was trying to figure to what extent that exposes my data to my VPS provider and whether I can do something about it. Disclaimer: this is just a hobby exercise. I'm not paranoid, I just want to learn for my own self how to improve security of my setup.

My reverse proxy terminates the SSL connection and then proxies the connection over a wireguard connection to my home server. This means that (a) data is decrypted in the RAM of the VPS and (b) the certificates live unencrypted in the storage of the VPS. This means that the VPS provider, if they want to, can read all the traffic unencrypted to and from my home server.

I was thinking that I can solve both problems by using Nginx's SSL pass-through feature. This would allow me to not terminate SSL on the VPS solving (a) and to move the certificates to my home server solving (b).

But just as I was playing around with it, I realised that SSL pass-through would not solve the problem of trying to protect my data from the VPS provider. As long as my DNS records point at the VPS provider's servers, the VPS provider can always get their own certificates for my domains and do a MitM attack. Therefore, I might as well keep the certificates on the VPS since I still have to trust them not to make their own behind my back.

In the end I concluded that as long as I use a VPS provider to route my traffic to my home server, there is no fool-proof way to secure my data from them. Intuitively it makes sense, the data crosses their hardware physically and thus they will have access to it. The only way to stop it would be to update the DNS records to point directly at my home server which I don't want to do.

Is this correct thinking or is there some way to prevent the VPS provider from seeing my data?

Again, I'm trying to solve this problem as a hobby exercise. The most sensitive data that I have is stored encrypted at the filesystem level and I only decrypt it locally on my own machine to work on it. Therefore, the actually sensitive data that would be cost me a lot if compromised is never available unencrypted on the VPS. Due to the overhead of this encryption and other complications, I don't do this for all my files.

view more: next ›

dr_robot

joined 1 year ago