given the recent news about vultr, i’d suggest shopping for a different VPS provider.
for context, this was recently added to the vultr service agreement:
You hereby grant to Vultr a non-exclusive, perpetual, irrevocable, royalty-free, fully paid-up, worldwide license (including the right to sublicense through multiple tiers) to use, reproduce, process, adapt, publicly perform, publicly display, modify, prepare derivative works, publish, transmit and distribute each of your User Content, or any portion thereof, in any form, medium or distribution method now known or hereafter existing, known or developed, and otherwise use and commercialize the User Content in any way that Vultr deems appropriate, without any further consent, notice and/or compensation to you or to any third parties, for purposes of providing the Services to you.
tl;dr: vultr will harvest your data and sell it to AI companies, probably.
Necessary additional context – this was the terms of service for their forum. They have now forked the TOS for their VPS business and removed those particular sections there.
Came here to say this. It’s even worse than that, because they also added a clause earlier that said that you implicitly agree to automatically accept future changes to the agreement, or something like that (use of the service implies consent to any changes in the agreement that they have done up to that point).
p.s. it’s not like the site name didn’t warn you that they were going to eat your body or something equally sinister …
Further FWIW, that section appears to be gone as of yesterday/today (see section 12, User Content, part 1, Content; it used to be tacked onto the end of paragraph (a).)
Author (and fellow Lobster) here. Surprised to see this posted here. Open to critique.
I tried to make the intention clear in the first “What?” section of that page.
The mission is to show people - who have never had a server - that it’s something they can do - that they don’t have to rely on all the “we’ll do it for you” services.
The whole idea was to give newbies a single walk-through “JUST DO THIS AND IT WILL WORK” type tutorial so that they could see what it’s like to have a Web/Email/CalDAV/CardDAV/file server up and running within an hour.
Tim Ferriss requested that I create this for his audience, since I was on his podcast, and he was asking about how people can not depend on the big tech cloud services: https://tim.blog/2023/04/21/derek-sivers/
I picked some choices I know and trust: Porkbun, Vultr, OpenBSD, its built-in httpd+relayd+opensmtpd and filesystem encryption, Dovecot, and Radicale for CalDAV/CardDAV hosting. If instead I had given a big choice of “well you could do this or that or this or that”, then people wouldn’t do it at all. It’d be too overwhelming, and they’d say “oh nevermind I’ll just stick with Google and Apple and Dropbox to manage everything”.
I’ve also provided about 200+ hours of tech support by email for the hundreds of people who have set this up, learned what DNS is, how rsync and SSH works, etc. Walking them through everything.
The hope is that this is a stepping stone for them. Get a server working first, then learn more about it afterwards.
FUTURE CHANGES:
At first I liked the simplicity of using OpenBSD’s built-in stuff, but yeah that does bind them to OpenBSD and the few VPS hosts that offer it.
So instead I’m considering making it OS-agnostic somehow and using Caddy webserver but then filesystem encryption will have to be OS-dependent, so some kind of “if Linux then this if OpenBSD then that” switch in a shell script? Not sure.
Also considering Charm.sh Go scripts for a more pretty UI.
Don’t fall prey to second system syndrome! This seems perfectly reasonable for what it is, a set piece of “this is how you learn enough to get past your fears.” OpenBSD is easier to recommend than any other provider, partly for the easy setup, partly for the security, and definitely for the man pages. So it locks people in a bit, that’s OK, this is a recommendation sheet and the further off-road you go, the more off-road decisions you will have to be comfortable making.
You could recommend they drop a file in /var/local/ or something with a link to the webarchive site that would give them the instructions they had when the system got built, introduce the idea of a configuration breadcrumb (that would later be ansible facts, salt grains, whatever).
This seems like pretty bad advice. I don’t think we should be teaching people to run systems like this. Use something like Puppet or Nix or (it’s not to my taste but) Ansible, learn it properly, and you get to live in a world where not only are you “independent”, you can also change your config without running the whole install script again, keep multiple machines in sync, rebuild effortlessly if you lose one, and undo changes that didn’t work out. As well as just… knowing what your configuration is. It’s enormously valuable to me that I can just look at the code in one repo to see how my server deviates from the default install, rather than having to go and look at every individual thing that could have changed.
Also there’s this:
You honestly don’t have to do anything to maintain your server. It will just work as-is for decades!
Telling people to bet the farm on OpenBSD’s (and all the other software their script installs) not having a remote exploit in the next several decades is not just a weird take; it’s either maliciously reckless or just malicious.
I actually think this is pretty great advice for somebody starting out and who is intimidated by setup.
I liken this article to “Growing stuff is easy–here, buy a succulent, put it near a window, occasionally water it, and it’ll basically never die”–by contrast, you seem to be concerned that the author isn’t telling folks to get the Farmer’s Almanac, a support contract with John Deere, and do soil sample testing.
It’s okay for folks starting out to not have configuration as code and to not run a FIPS-compliant system.
As well as just… knowing what your configuration is.
If I’m the only person administering my server, and I haven’t been too crazy in setup, I can look at my server and figure out what the configuration is. Sure, there are tools that make this easier–I run Nix for years now for this purpose–but for somebody that’s just trying to backup some movies and serve a webpage about their cat, this is fine.
~
Freaking engineers, I swear–for normies starting out, or experimenting, it’s more important to have easy-to-follow and hard-to-fuck-up steps than to have industry best practices.
I agree, and this tracks with my personal experience when I first started running my own VPS many years ago. Eventually I got up to speed with the intricacies of the underlying system, doing automation, etc.
The author of this article was on Tim Ferris’ podcast a few months back and they spent approximately 20 minutes talking about this subject. I imagine more than one person is going to attempt running their own server with varied degrees of success. I fret at the thought of newcomers getting pwned but as you point out, you don’t have to run critical infrastructure. Start with a website, leave some slack in the system, and keep learning.
We need more people taking ownership of their digital lives!
It’s okay for folks starting out […] to not run a FIPS-compliant system.
Sure, but it’s one thing to tell people “here’s a reasonable default configuration that should be fairly low-maintenance.” It’s something else entirely to say “You honestly don’t have to do anything to maintain your server. It will just work as-is for decades!” To an experienced person, that is an obvious exaggeration. To a newbie, it’s a recipe for running a system that will slowly but surely become insecure over time.
I think the OpenBSD server I set up for my parents to handle on-demand dialup and file sharing on the LAN ran for a decade with basically nothing. When I was at gradschool my father had to call me up once and I used him as a teletype to fix some minor thing that had changed with the network configuration.
It’s actually quite reasonable advice. People have just forgotten that it’s reasonable.
the advice isn’t bad, it’s just not aimed at folks with experience. for someone just starting out, using nix/puppet is bad advice - how could a person know how to use nix or puppet when they don’t know how to configure a system in the first place?
besides, managing a system by hand is just fine for personal use - it’s low overhead and understandable - i know nix & chef & puppet & all the rest, and still prefer managing my personal systems by hand simply because i find it more enjoyable.
I would agree. While I tend to be skeptical of step-by-step guides without talking about alternatives in the space or going in depth on how do things in a ‘nicer’ way later, the introduction was clear that it’s meant to be about as simplified as it can taking all of the choices out. I’m not the target, but maybe this style of guide is how some prefer to gain their understanding & intuition–& with the broad goal of taking back ownership of one’s data, having more styles of guides for different kinds of folks is good.
Sorry for replying so much later; I went on a wild camping holiday for Easter but I wanted to respond to some of the pushback here.
Basically, I think learning good habits is much easier than learning bad habits and then trying to replace them with better ones. Empirically hardly anyone does replace them. I think one of the reasons Nix has done so well is it forces people to do things right from the beginning, and once people have experienced doing things right, they like it.
I can’t really argue with your enjoying managing your system by hand, but this article isn’t encouraging people to pick up system administration as a hobby—it’s encouraging them to do the bare minimum sysadmin as a means to an end. I believe that using config management will is ultimately somewhat lower-maintenance than doing everything by hand. I also think it’s much safer in that if your server mysteriously disappears or whatever you have a greater chance of setting up its replacement in a timely fashion. (Note the author wants us to self-host email, and missing emails can occasionally have serious consequences).
how could a person know how to use nix or puppet when they don’t know how to configure a system in the first place?
I’ve configured things with Nix and Puppet that I’ve never configured without. I have a friend who self-hosts email with Nix and doesn’t even know which software they’re using to do it. I’m not sure that I’d personally recommend taking such a zoomed-out view of a computer you’re responsible for, but I think this is pretty strong evidence that using configuration management is easier than not.
using nix/puppet does not automatically mean you’re “doing things right” - that’s a big assumption and depends on a ton of context.
i used nix to manage my systems in 2016, and ultimately fell out of love with it because i didn’t think the level of abstraction was worth it - it’s nice when it works, but when something inevitably goes wrong it turns into hell pretty quickly.
first, nix works differently than “normal” routes of managing systems, so you’ve locked yourself out of the utility of generic online resources. is that “doing things right”?
i’ve worked in the config management space for years, and can say with certainty that it’s more work to code, maintain, and update a system like puppet than it is to manage systems by hand.
there’s a tipping point where the complexity starts to be “worth it”, and imo it’s somewhere around 10 systems.
sometimes all you need to do is apt install a single package and start a single service and update the thing once a year - no abstraction, direct management with obvious patterns when things go wrong - there’s a lot of value in doing things simply.
imo, everyone should learn the fundamentals before they learn the abstraction layer, especially if they’re planning on being responsible for the uptime of the thing.
your insistence that beginners learn nix because it’s unequivocally “correct” is what i take issue with. it is not always correct, and imo beginners are just gonna be frustrated by it.
you shouldn’t learn javascript by starting with React, and you shouldn’t learn Linux Administration by starting with nix.
using nix/puppet does not automatically mean you’re “doing things right” - that’s a big assumption and depends on a ton of context
I singled Nix out because it pretty much forces you into doing things declaratively while less absolutist tools require more discipline. Obviously nothing can make you do everything right, but Nix makes a very good effort at stopping you from having configuration that is not code, which is the “do things right” I was talking about here.
first, nix works differently than “normal” routes of managing systems, so you’ve locked yourself out of the utility of generic online resources. is that “doing things right”?
I don’t think I would claim it as an advantage but I don’t think it’s that bad. I find it very difficult to find useful information about sysadmin stuff from generic online resources anyway, just because there’s so much SEO content farm stuff.
there’s a tipping point where the complexity starts to be “worth it”, and imo it’s somewhere around 10 systems
I have one server now, and I think it’s worth it. I don’t really know what to say to your assertion that it’s more work. It’s not for me. I especially like how easy updates and reinstallations are.
your insistence that beginners learn nix because it’s unequivocally “correct” is what i take issue with. it is not always correct, and imo beginners are just gonna be frustrated by it
I don’t think they should always use Nix, I just think they should use something reproducible.
and you shouldn’t learn Linux Administration by starting with nix
But, again, this isn’t a primer on How To Become A Sysadmin (definitely not a Linux one since OP wants you to use OpenBSD…). It’s aimed—I think—at people who were quite happy not doing any of this. I’m also a professional sysadmin and I believe I know the value of being familiar with the basics. But I (a) don’t think that implies one has to start with them, any more than one needs to start programming in assembly language; and (b) don’t think you have to understand everything you use to such a high standard. If you see a server as something akin to a kitchen appliance, your choices are:
Do it all yourself (you can’t, you don’t know how computers work)
Do the things this article says, install a weird OS and then run some random script you don’t understand and type a bunch of stuff into it
Follow a hypothetical config-as-code version of this: copy someone’s random code you don’t understand and type a bunch of stuff into it, run a weird program/install a differently weird OS
If that’s where you get off, they look pretty similar to me. But I really think you’re on a better footing with config management if you ever want to make any changes or reinstall your system or whatever.
I was kind of taken aback by how many people disagreed with me about this one. I think the main thing that surprised me was that folks think config management is more work or only appropriate for hardened professionals or huge fleets of servers. And I just don’t see it that way. I feel like managing a computer manually is akin to bonsai or maintaining a vintage car or something—it’s a respectable pursuit and I can understand why people want to opt into doing it, but to the non-enthusiast it’s just a chore.
If this is the “SSH into root”, if password authentication if disabled it doesn’t seem to be an issue for me. Using a custom user with sudo permissions doesn’t bring much more in terms of security.
If this is the “and get my script” part, then OK. You shouldn’t executing a script form an untrusted source without reviewing it.
There is no operational difference between executing a script from an untrusted source on a VPS and having your services managed entirely by an untrusted source. Is there?
Telling people to bet the farm on OpenBSD’s (and all the other software their script installs) not having a remote exploit in the next several decades is not just a weird take; it’s either maliciously reckless or just malicious.
That’s hard to take seriously without an argument for why betting the farm on something else is better.
I see, you would prefer if they advised people to update their server rather than just saying to do it “if you like.” but a lot of people won’t want to take the time either way.
It’s a shame that an article advocating for tech independence starts out (and has to start out) with the requirement of buying a domain name from some specific company. Or really leasing, since the current Domain Name System provides no way to actually buy a domain name without having an ongoing legal and financial relationship with a DNS provider. The fact that there is no self-sovereign way to own a domain name or reasonable equivalent is a big and underreported problem of the contemporary internet.
It’s not just DNS. There’s no way to actually buy a publicly routed IP address (v4 or v6) without having an ongoing legal and financial relationship with an ISP.
I would be enthusiastic about this message, except it encourages people to rely on Vultr! It defeats the whole point if you are in fact telling people to use a specific provider without explaining how to find alternatives. In fact, it kind of reads like marketing material for Vultr.
The section mentioning vultr explicitly states that it is just on particular VPS provider the author has used before and likes; and also states that you can do something similar on any other VPS provider or on used hardware you physically own, and also switch between different providers if “a company turns evil or goes out of business”. This is not the sort of thing you’d say if you were doing marketing for vultr specifically.
How any of this is independent? It’s mainly a collection of links to arbitrarily chosen paid services (for DNS, VPS, storage, e-mail), and an advice of running as root a script that you won’t read/understand if you’re a noob. Doesn’t sound very independent to me.
If you wanna talk independence and if your scope if personal/family computing (contacts/calendar/memories/documents), a VPS seems less useful to me than a Raspberry Pi with a big SSD attached: maintenance would be the same (OS and software updates), but at least it’s yours.
One more thing: backup is missing. Talking about rclone would help on that matter, since it can encrypt your data locally before sending it to a bunch of external services.
so the criteria for independence is buying a computer rather than renting one somewhere else? your “independent” suggestion still depends on plenty of code that a noob won’t read/understand as well as paid services such as their Internet connection.
if someone says a child is independent that doesn’t mean they grow their own food and have no connection to society.
My definition of “being independent” is not “having zero dependency” (which is not desirable for many aspects of life, like you say for food, and which is technically impossible when it comes to setup personal/family computing).
I would prefer “knowing when to accept a dependency and how to chose on the dependencies market”. And this is why I say that:
The post does not help being independent, because listed dependencies are arbitrarily chosen ; the commodity of quickly getting to a result is preferred to pointing to benchmarks for registrars, DNS, etc., and I feel like this is like giving fish to people against teaching them how to fish
On each aspect of a project, if you have “independence” in mind, you should ask yourself whether or not you accept a dependency, i.e. what tradeoff you make with one option or the other. For example, personally:
For e-mailing I prefer depending on an external solution because I don’t feel confident on hosting e-mailing by myself ; someone else might choose hosting their e-mail by themselves
But for computing/storage, I don’t see what an external VPS/storage solutions brings, because the complexity of maintenance is on the software side anyway ; it’s one dependency off, the easy way.
In the context of web, email, and data hosting, what matters a lot more than independence is portability, at least for longevity. And, indeed, I suspect this Sivers guide is more about achieving portability. That is, though it’s true that Porkbun is the company suggested for buying a domain name, once you buy a domain name, it is portable to any registrar (*that supports your TLD and domain type). Likewise, once you rent a *nix host from a cloud company, it (or the services it provides, or the data it stores) is usually portable to another cloud company’s equivalent VM. In the email section, for example, he suggested Fastmail as an alternative, but only if you use their custom domain feature. This is because the big issue with gmail.com and fastmail.com email addresses is that they are not portable to other email providers, and once you start using them regularly, you build up a dependency on them. But a custom domain email address is easily ported between email providers.
So, I suspect that what he’s really going for is a setup that (a) won’t be data-harvested; (b) uses relatively stable dependencies (thus OpenBSD); and (c) is portable, if push comes to shove. Altogether, that makes the setup pretty independent, especially compared to going all-in on one or another platform (e.g. Google or Apple).
It’s also clear Sivers likes the idea of users embracing open standards. So he’s sending users in the direction of embracing DNS, plain HTTP/HTML web hosting, IMAP email access, CalDAV/CardDAV for calendars/contacts, and then things like rsync and ssh. It resonates with me, but I’ve been a long-time open web enthusiast and Linux user, so it’s preaching to the choir. I don’t think everyday users actually care about this as much as we wish they would. (I struggle enough with getting “normie” friends off iMessage and onto Signal.)
This is because the big issue with gmail.com and fastmail.com email addresses is that they are not portable to other email providers, and once you start using them regularly, you build up a dependency on them.
So this is about avoiding a dependency on any particular service. I think the word “independence” is perfectly fine here. “Portability” is fine too but non-technical people might be not be familiar with this notion of porting, and might think you are talking about things that can be packed into a backpack.
You cite your choice to outsource your email as compatible with “independence,” but if someone outsources general purpose computing/storage you’re saying that can’t be considered independent? What if they want something reliable and don’t feel confident in the reliability of their home Internet or electricity?
Not at all. I personally outsource Linux server hosting (to DigitalOcean, not Vultr), at least for the server I need to have a stable public IP. And I outsource storage to Backblaze B2, because I don’t trust my ability to run a personal NAS (I’ve tried, and failed) but I do trust my ability to run restic (Linux) and Arq (macOS) regularly. Personally, I am in 100% agreement that choosing a vendor to handle reliability concerns is completely rational and not at odds with supporting independent/portable technology.
You cite your choice to outsource your email as compatible with “independence,” but if someone outsources general purpose computing/storage you’re saying that can’t be considered independent?
No that’s not at all what I’m saying. I’m saying that independence, as many other things, is all about making tradeoffs, and knowing the reasons behind each tradeoff. As I am living in France where electricity supply is reliable and where FTTH gives me a stable IP address, having a Raspberry Pi at home was no different than renting a VPS somewhere, and I think the post we’re discussing here could have mentioned that instead of just dropping another vendor name where the reader is told to give up one more bit of independence.
But having a home server increases your dependence on your Internet and electricity providers.
Anyway, your original comment certainly made it seem like your issue was with the recommendations and not with the lack of discussion about the reasoning behind the recommendations, so I guess it could have been more clear if this was your position all along. For what it’s worth I think there is value in brevity, and there is no limit to the number of tradeoffs that could be discussed pertaining to each recommendation.
For the record he does explain some of the reasoning on this point:
Instead of drowning you in options, it uses an operating system called OpenBSD and a hosting company called Vultr because I’ve used them for years and I know they are good and trustworthy. But you could do this same setup with any free Linux or BSD operating system, with any hosting company that gives you “root” access to your own private server. You could even do it on an old laptop in your closet.
I think this is a nice curated list of manual steps and suggestions for tools. To me, it’s like an early design doc. The problem with manual steps and long READMEs is that they have no version. Let’s say I do all of this and this advice changes, am I on “Mar 2024 as written tech independence stack”? How do I get to the new thing when mutt is replaced by neomutt or whatever?
If this was called tech_independence-v0.deb then it could have a version and there would be a name for it, a diff, a migration something, updates, improvements, replacements and other changes as the world changes. As it stands, I think it’s like a design doc for a meta-something. Unfortunately, it’s really hard to ship compositions. :( If you look at some homelab bootstrap repos, it kind of reads the same but they attempt to have scripts. They still don’t have a way to name a meta-version but at least there is a git ref and each component’s version is known usually.
Yea, there’s a company called “Federated Computer” which is essentially that. They run a VPS (on Hertzner) for you with a lot of open source software, focused around personal data and personal hosting, and they keep it patched and up to date. No SSH access, only access via open protocols (e.g. IMAP) or web logins (which they’ve helpfully unified using LDAP). The entry plan is just Postfix email server, Nextcloud (for files), and Vaultwarden (for passwords), all running off your custom domain. I only learned about them because they took over Synapse / Matrix hosting for tiny teams from Element EMS, who decided to go up-market to enterprises. Not sure how big the market is for this sort of thing, it also does mean you’re putting all your eggs in one basket.
One of my favorite providers at least in the United States is wholesale internet. If you get a custom instance they respond within minutes and email. For 50 bucks a month. I get 24 gigs memory, 24 processors and four terabytes of disc and 100 terabytes a month of bandwidth. I also get six IP addresses and a:: 64 ipv6. Gigabit up and down. It’s plenty to do anything that I need for all my stuff.
given the recent news about vultr, i’d suggest shopping for a different VPS provider.
for context, this was recently added to the vultr service agreement:
tl;dr: vultr will harvest your data and sell it to AI companies, probably.
Necessary additional context – this was the terms of service for their forum. They have now forked the TOS for their VPS business and removed those particular sections there.
Came here to say this. It’s even worse than that, because they also added a clause earlier that said that you implicitly agree to automatically accept future changes to the agreement, or something like that (use of the service implies consent to any changes in the agreement that they have done up to that point).
p.s. it’s not like the site name didn’t warn you that they were going to eat your body or something equally sinister …
FWIW, it’s not actually new: https://old.reddit.com/r/selfhosted/comments/1bouuv7/comment/kwua6k8/
Further FWIW, that section appears to be gone as of yesterday/today (see section 12, User Content, part 1, Content; it used to be tacked onto the end of paragraph (a).)
Author (and fellow Lobster) here. Surprised to see this posted here. Open to critique.
I tried to make the intention clear in the first “What?” section of that page.
The mission is to show people - who have never had a server - that it’s something they can do - that they don’t have to rely on all the “we’ll do it for you” services.
The whole idea was to give newbies a single walk-through “JUST DO THIS AND IT WILL WORK” type tutorial so that they could see what it’s like to have a Web/Email/CalDAV/CardDAV/file server up and running within an hour.
Tim Ferriss requested that I create this for his audience, since I was on his podcast, and he was asking about how people can not depend on the big tech cloud services: https://tim.blog/2023/04/21/derek-sivers/
I picked some choices I know and trust: Porkbun, Vultr, OpenBSD, its built-in httpd+relayd+opensmtpd and filesystem encryption, Dovecot, and Radicale for CalDAV/CardDAV hosting. If instead I had given a big choice of “well you could do this or that or this or that”, then people wouldn’t do it at all. It’d be too overwhelming, and they’d say “oh nevermind I’ll just stick with Google and Apple and Dropbox to manage everything”.
I’ve also provided about 200+ hours of tech support by email for the hundreds of people who have set this up, learned what DNS is, how rsync and SSH works, etc. Walking them through everything.
The hope is that this is a stepping stone for them. Get a server working first, then learn more about it afterwards.
FUTURE CHANGES:
At first I liked the simplicity of using OpenBSD’s built-in stuff, but yeah that does bind them to OpenBSD and the few VPS hosts that offer it.
So instead I’m considering making it OS-agnostic somehow and using Caddy webserver but then filesystem encryption will have to be OS-dependent, so some kind of “if Linux then this if OpenBSD then that” switch in a shell script? Not sure.
Also considering Charm.sh Go scripts for a more pretty UI.
Any suggestions appreciated.
Don’t fall prey to second system syndrome! This seems perfectly reasonable for what it is, a set piece of “this is how you learn enough to get past your fears.” OpenBSD is easier to recommend than any other provider, partly for the easy setup, partly for the security, and definitely for the man pages. So it locks people in a bit, that’s OK, this is a recommendation sheet and the further off-road you go, the more off-road decisions you will have to be comfortable making.
You could recommend they drop a file in
/var/local/or something with a link to the webarchive site that would give them the instructions they had when the system got built, introduce the idea of a configuration breadcrumb (that would later be ansible facts, salt grains, whatever).This seems like pretty bad advice. I don’t think we should be teaching people to run systems like this. Use something like Puppet or Nix or (it’s not to my taste but) Ansible, learn it properly, and you get to live in a world where not only are you “independent”, you can also change your config without running the whole install script again, keep multiple machines in sync, rebuild effortlessly if you lose one, and undo changes that didn’t work out. As well as just… knowing what your configuration is. It’s enormously valuable to me that I can just look at the code in one repo to see how my server deviates from the default install, rather than having to go and look at every individual thing that could have changed.
Also there’s this:
Telling people to bet the farm on OpenBSD’s (and all the other software their script installs) not having a remote exploit in the next several decades is not just a weird take; it’s either maliciously reckless or just malicious.
I actually think this is pretty great advice for somebody starting out and who is intimidated by setup.
I liken this article to “Growing stuff is easy–here, buy a succulent, put it near a window, occasionally water it, and it’ll basically never die”–by contrast, you seem to be concerned that the author isn’t telling folks to get the Farmer’s Almanac, a support contract with John Deere, and do soil sample testing.
It’s okay for folks starting out to not have configuration as code and to not run a FIPS-compliant system.
If I’m the only person administering my server, and I haven’t been too crazy in setup, I can look at my server and figure out what the configuration is. Sure, there are tools that make this easier–I run Nix for years now for this purpose–but for somebody that’s just trying to backup some movies and serve a webpage about their cat, this is fine.
~
Freaking engineers, I swear–for normies starting out, or experimenting, it’s more important to have easy-to-follow and hard-to-fuck-up steps than to have industry best practices.
I agree, and this tracks with my personal experience when I first started running my own VPS many years ago. Eventually I got up to speed with the intricacies of the underlying system, doing automation, etc.
The author of this article was on Tim Ferris’ podcast a few months back and they spent approximately 20 minutes talking about this subject. I imagine more than one person is going to attempt running their own server with varied degrees of success. I fret at the thought of newcomers getting pwned but as you point out, you don’t have to run critical infrastructure. Start with a website, leave some slack in the system, and keep learning.
We need more people taking ownership of their digital lives!
Sure, but it’s one thing to tell people “here’s a reasonable default configuration that should be fairly low-maintenance.” It’s something else entirely to say “You honestly don’t have to do anything to maintain your server. It will just work as-is for decades!” To an experienced person, that is an obvious exaggeration. To a newbie, it’s a recipe for running a system that will slowly but surely become insecure over time.
I think the OpenBSD server I set up for my parents to handle on-demand dialup and file sharing on the LAN ran for a decade with basically nothing. When I was at gradschool my father had to call me up once and I used him as a teletype to fix some minor thing that had changed with the network configuration.
It’s actually quite reasonable advice. People have just forgotten that it’s reasonable.
Not being FIPS-compliant is a plus.
the advice isn’t bad, it’s just not aimed at folks with experience. for someone just starting out, using nix/puppet is bad advice - how could a person know how to use nix or puppet when they don’t know how to configure a system in the first place?
besides, managing a system by hand is just fine for personal use - it’s low overhead and understandable - i know nix & chef & puppet & all the rest, and still prefer managing my personal systems by hand simply because i find it more enjoyable.
I would agree. While I tend to be skeptical of step-by-step guides without talking about alternatives in the space or going in depth on how do things in a ‘nicer’ way later, the introduction was clear that it’s meant to be about as simplified as it can taking all of the choices out. I’m not the target, but maybe this style of guide is how some prefer to gain their understanding & intuition–& with the broad goal of taking back ownership of one’s data, having more styles of guides for different kinds of folks is good.
Sorry for replying so much later; I went on a wild camping holiday for Easter but I wanted to respond to some of the pushback here.
Basically, I think learning good habits is much easier than learning bad habits and then trying to replace them with better ones. Empirically hardly anyone does replace them. I think one of the reasons Nix has done so well is it forces people to do things right from the beginning, and once people have experienced doing things right, they like it.
I can’t really argue with your enjoying managing your system by hand, but this article isn’t encouraging people to pick up system administration as a hobby—it’s encouraging them to do the bare minimum sysadmin as a means to an end. I believe that using config management will is ultimately somewhat lower-maintenance than doing everything by hand. I also think it’s much safer in that if your server mysteriously disappears or whatever you have a greater chance of setting up its replacement in a timely fashion. (Note the author wants us to self-host email, and missing emails can occasionally have serious consequences).
I’ve configured things with Nix and Puppet that I’ve never configured without. I have a friend who self-hosts email with Nix and doesn’t even know which software they’re using to do it. I’m not sure that I’d personally recommend taking such a zoomed-out view of a computer you’re responsible for, but I think this is pretty strong evidence that using configuration management is easier than not.
using nix/puppet does not automatically mean you’re “doing things right” - that’s a big assumption and depends on a ton of context.
i used nix to manage my systems in 2016, and ultimately fell out of love with it because i didn’t think the level of abstraction was worth it - it’s nice when it works, but when something inevitably goes wrong it turns into hell pretty quickly.
first, nix works differently than “normal” routes of managing systems, so you’ve locked yourself out of the utility of generic online resources. is that “doing things right”?
i’ve worked in the config management space for years, and can say with certainty that it’s more work to code, maintain, and update a system like puppet than it is to manage systems by hand.
there’s a tipping point where the complexity starts to be “worth it”, and imo it’s somewhere around 10 systems.
sometimes all you need to do is apt install a single package and start a single service and update the thing once a year - no abstraction, direct management with obvious patterns when things go wrong - there’s a lot of value in doing things simply.
imo, everyone should learn the fundamentals before they learn the abstraction layer, especially if they’re planning on being responsible for the uptime of the thing.
your insistence that beginners learn nix because it’s unequivocally “correct” is what i take issue with. it is not always correct, and imo beginners are just gonna be frustrated by it.
you shouldn’t learn javascript by starting with React, and you shouldn’t learn Linux Administration by starting with nix.
I singled Nix out because it pretty much forces you into doing things declaratively while less absolutist tools require more discipline. Obviously nothing can make you do everything right, but Nix makes a very good effort at stopping you from having configuration that is not code, which is the “do things right” I was talking about here.
I don’t think I would claim it as an advantage but I don’t think it’s that bad. I find it very difficult to find useful information about sysadmin stuff from generic online resources anyway, just because there’s so much SEO content farm stuff.
I have one server now, and I think it’s worth it. I don’t really know what to say to your assertion that it’s more work. It’s not for me. I especially like how easy updates and reinstallations are.
I don’t think they should always use Nix, I just think they should use something reproducible.
But, again, this isn’t a primer on How To Become A Sysadmin (definitely not a Linux one since OP wants you to use OpenBSD…). It’s aimed—I think—at people who were quite happy not doing any of this. I’m also a professional sysadmin and I believe I know the value of being familiar with the basics. But I (a) don’t think that implies one has to start with them, any more than one needs to start programming in assembly language; and (b) don’t think you have to understand everything you use to such a high standard. If you see a server as something akin to a kitchen appliance, your choices are:
Do it all yourself(you can’t, you don’t know how computers work)If that’s where you get off, they look pretty similar to me. But I really think you’re on a better footing with config management if you ever want to make any changes or reinstall your system or whatever.
I was kind of taken aback by how many people disagreed with me about this one. I think the main thing that surprised me was that folks think config management is more work or only appropriate for hardened professionals or huge fleets of servers. And I just don’t see it that way. I feel like managing a computer manually is akin to bonsai or maintaining a vintage car or something—it’s a respectable pursuit and I can understand why people want to opt into doing it, but to the non-enthusiast it’s just a chore.
Not to mention the massive red flag in the form of
right after making some SSH keys
What exactly is a red flag in this for you ?
If this is the “SSH into root”, if password authentication if disabled it doesn’t seem to be an issue for me. Using a custom user with sudo permissions doesn’t bring much more in terms of security.
If this is the “and get my script” part, then OK. You shouldn’t executing a script form an untrusted source without reviewing it.
From the step
It seems that your intended audience for this is nontechnical people. If so, is it reasonable to ask them to review a long bash script?
Agreed, it is not. And overall i don’t think it is good idea to ask non-technical people to self-host.
There is no operational difference between executing a script from an untrusted source on a VPS and having your services managed entirely by an untrusted source. Is there?
That’s hard to take seriously without an argument for why betting the farm on something else is better.
I mean, you could just… update your server? I thought we had pretty much everyone convinced on this point, to be honest.
I see, you would prefer if they advised people to update their server rather than just saying to do it “if you like.” but a lot of people won’t want to take the time either way.
It’s a shame that an article advocating for tech independence starts out (and has to start out) with the requirement of buying a domain name from some specific company. Or really leasing, since the current Domain Name System provides no way to actually buy a domain name without having an ongoing legal and financial relationship with a DNS provider. The fact that there is no self-sovereign way to own a domain name or reasonable equivalent is a big and underreported problem of the contemporary internet.
It’s not just DNS. There’s no way to actually buy a publicly routed IP address (v4 or v6) without having an ongoing legal and financial relationship with an ISP.
I would be enthusiastic about this message, except it encourages people to rely on Vultr! It defeats the whole point if you are in fact telling people to use a specific provider without explaining how to find alternatives. In fact, it kind of reads like marketing material for Vultr.
The section mentioning vultr explicitly states that it is just on particular VPS provider the author has used before and likes; and also states that you can do something similar on any other VPS provider or on used hardware you physically own, and also switch between different providers if “a company turns evil or goes out of business”. This is not the sort of thing you’d say if you were doing marketing for vultr specifically.
Counterpoint: anybody who cares enough to find an alternative to Vultr is probably motivated enough to Google “vultr alternatives”.
How any of this is independent? It’s mainly a collection of links to arbitrarily chosen paid services (for DNS, VPS, storage, e-mail), and an advice of running as root a script that you won’t read/understand if you’re a noob. Doesn’t sound very independent to me.
If you wanna talk independence and if your scope if personal/family computing (contacts/calendar/memories/documents), a VPS seems less useful to me than a Raspberry Pi with a big SSD attached: maintenance would be the same (OS and software updates), but at least it’s yours.
One more thing: backup is missing. Talking about rclone would help on that matter, since it can encrypt your data locally before sending it to a bunch of external services.
so the criteria for independence is buying a computer rather than renting one somewhere else? your “independent” suggestion still depends on plenty of code that a noob won’t read/understand as well as paid services such as their Internet connection.
if someone says a child is independent that doesn’t mean they grow their own food and have no connection to society.
My definition of “being independent” is not “having zero dependency” (which is not desirable for many aspects of life, like you say for food, and which is technically impossible when it comes to setup personal/family computing).
I would prefer “knowing when to accept a dependency and how to chose on the dependencies market”. And this is why I say that:
In the context of web, email, and data hosting, what matters a lot more than independence is portability, at least for longevity. And, indeed, I suspect this Sivers guide is more about achieving portability. That is, though it’s true that Porkbun is the company suggested for buying a domain name, once you buy a domain name, it is portable to any registrar (*that supports your TLD and domain type). Likewise, once you rent a *nix host from a cloud company, it (or the services it provides, or the data it stores) is usually portable to another cloud company’s equivalent VM. In the email section, for example, he suggested Fastmail as an alternative, but only if you use their custom domain feature. This is because the big issue with gmail.com and fastmail.com email addresses is that they are not portable to other email providers, and once you start using them regularly, you build up a dependency on them. But a custom domain email address is easily ported between email providers.
So, I suspect that what he’s really going for is a setup that (a) won’t be data-harvested; (b) uses relatively stable dependencies (thus OpenBSD); and (c) is portable, if push comes to shove. Altogether, that makes the setup pretty independent, especially compared to going all-in on one or another platform (e.g. Google or Apple).
It’s also clear Sivers likes the idea of users embracing open standards. So he’s sending users in the direction of embracing DNS, plain HTTP/HTML web hosting, IMAP email access, CalDAV/CardDAV for calendars/contacts, and then things like rsync and ssh. It resonates with me, but I’ve been a long-time open web enthusiast and Linux user, so it’s preaching to the choir. I don’t think everyday users actually care about this as much as we wish they would. (I struggle enough with getting “normie” friends off iMessage and onto Signal.)
So this is about avoiding a dependency on any particular service. I think the word “independence” is perfectly fine here. “Portability” is fine too but non-technical people might be not be familiar with this notion of porting, and might think you are talking about things that can be packed into a backpack.
You cite your choice to outsource your email as compatible with “independence,” but if someone outsources general purpose computing/storage you’re saying that can’t be considered independent? What if they want something reliable and don’t feel confident in the reliability of their home Internet or electricity?
Not at all. I personally outsource Linux server hosting (to DigitalOcean, not Vultr), at least for the server I need to have a stable public IP. And I outsource storage to Backblaze B2, because I don’t trust my ability to run a personal NAS (I’ve tried, and failed) but I do trust my ability to run
restic(Linux) and Arq (macOS) regularly. Personally, I am in 100% agreement that choosing a vendor to handle reliability concerns is completely rational and not at odds with supporting independent/portable technology.my comment was a reply to ~David-Guillot, not you.
Ah, my mistake. I failed to parse the mobile formatting of the thread correctly.
No that’s not at all what I’m saying. I’m saying that independence, as many other things, is all about making tradeoffs, and knowing the reasons behind each tradeoff. As I am living in France where electricity supply is reliable and where FTTH gives me a stable IP address, having a Raspberry Pi at home was no different than renting a VPS somewhere, and I think the post we’re discussing here could have mentioned that instead of just dropping another vendor name where the reader is told to give up one more bit of independence.
But having a home server increases your dependence on your Internet and electricity providers.
Anyway, your original comment certainly made it seem like your issue was with the recommendations and not with the lack of discussion about the reasoning behind the recommendations, so I guess it could have been more clear if this was your position all along. For what it’s worth I think there is value in brevity, and there is no limit to the number of tradeoffs that could be discussed pertaining to each recommendation.
For the record he does explain some of the reasoning on this point:
I think this is a nice curated list of manual steps and suggestions for tools. To me, it’s like an early design doc. The problem with manual steps and long READMEs is that they have no version. Let’s say I do all of this and this advice changes, am I on “Mar 2024 as written tech independence stack”? How do I get to the new thing when
muttis replaced byneomuttor whatever?If this was called
tech_independence-v0.debthen it could have a version and there would be a name for it, a diff, a migration something, updates, improvements, replacements and other changes as the world changes. As it stands, I think it’s like a design doc for a meta-something. Unfortunately, it’s really hard to ship compositions. :( If you look at some homelab bootstrap repos, it kind of reads the same but they attempt to have scripts. They still don’t have a way to name a meta-version but at least there is a git ref and each component’s version is known usually.Working around all of this faff constitutes a business model.
look, I’m a sysadmin and the idea of all this just fills me with exhaustion.
there’s gotta be a happy medium between Impersonal Corporate Behemoth Inc. and Some Guy LLC, and I really don’t want to be Some Guy LLC myself.
Yea, there’s a company called “Federated Computer” which is essentially that. They run a VPS (on Hertzner) for you with a lot of open source software, focused around personal data and personal hosting, and they keep it patched and up to date. No SSH access, only access via open protocols (e.g. IMAP) or web logins (which they’ve helpfully unified using LDAP). The entry plan is just Postfix email server, Nextcloud (for files), and Vaultwarden (for passwords), all running off your custom domain. I only learned about them because they took over Synapse / Matrix hosting for tiny teams from Element EMS, who decided to go up-market to enterprises. Not sure how big the market is for this sort of thing, it also does mean you’re putting all your eggs in one basket.
One of my favorite providers at least in the United States is wholesale internet. If you get a custom instance they respond within minutes and email. For 50 bucks a month. I get 24 gigs memory, 24 processors and four terabytes of disc and 100 terabytes a month of bandwidth. I also get six IP addresses and a:: 64 ipv6. Gigabit up and down. It’s plenty to do anything that I need for all my stuff.