6.9 KiB
So, You Wanna Make A Tilde?
author: ubergeek
So, you want to make a Tilde server (aka a pubnix server)? You've got time on your hands. You want to make a new and cool thing, right? Awesome! This article is going to step you through some of the pitfalls, so you can try to ensure it's going to be fun.
Why?
Before you start down the road, ask yourself "Why?" Why do you want to make a tilde server? To be ultimate lord over a domain? To have a cool art project to play with? Any reason is a valid reason, but the "Why" answer will help you build your tilde, and cultivate it's community.
How?
Yep. "How?" Running a tilde server is not free, money-wise, or time-wise. It's work, and money.
Are you cash-strapped, but have an old machine and somewhat stable internet connection? Maybe home-hosted is the way to go. But, where you save on money, you generally spend more time on it. Self-hosted can be fun, but you're going to spend more time on administering it, since you'll be responsible for all of the hardware and software up to your internet connection. If the hard drive dies, or a RAM module gives up the ghost, it's on you to replace it, and your tilde will be down until you do so.
Are you time-strapped, but extra cash? A VPS is a fine choice for a small tilde, and can be relativeley cheap. You can get a small VPS for $2.50/month US, and it'd be suitable for at least a dozen users, who aren't hammering on the machine. There's also dedicated servers (You manage the whole machine, hardware and software, your provider manages power and network, but you don't own the hardware, and they replace bad hardware), or you could co-locate them (You are responsible for everything but power, and a internet drop). Each option has it's own pitfalls and benefits. It boils down to the more you pay more for resources, the less you are responsible for.
What OS? Lots of tildes run Ubuntu, so help is plentiful there. There's some BSDs, as well, and at least one Redhat-based tilde. The more unique your distro/OS, the more you'll be on your own. Something to keep in mind there as well.
One thing to keep in mind, though: If you're going to do the same thing every other pubnix operator does (Most commonly used distro, most common web server, most common forum software, most common set of service, etc) then what will make your pubnix different? The "Why?" answer will fill this part in, which is the reason why it's the most important question, and comes first.
What?
I know. You're saying right now,"What does he mean 'what?' A tilde you daft bastid!"
The "what" defines what kind of community you want to build. Are you just building a clubhouse for close friends? A living digital art community? A community of arduino hobbyists? This is a key thing to figure out BEFORE you decide to launch your tilde. This also guides your technical decisions, and things to install, services to provide, etc etc
So, who actually did this?
I can tell you from personal experience with thunix, that I went through these same steps. Some questions were pre-answered since I essentially took the reins from an already existing project.
Why? I felt I had a lot of experience to lend to the community. My professional job is running, managing, deploying, and maintaining linux servers. Some of them are internally pubnix boxes. Users use them for building code, doing git work, etc etc. Some things are missing, like chat, but there are other tools for that sort of thing. But, nonetheless, experience I have, and decentralization is what I wanted to bring. I also wanted to give users a place to play with what a CI/CD environment is like, and as such, we designed thunix to be built and maintained in a devops manner: users and administrators work hand in hand to build the system.
How? My job pays well enough that I have some disposable income, on a regular basis. Not a starving artist, or a contractor wandering from job to job. Also, I had some cloud stuff already, and this seemed like a good enough reason to get some dedicated hardware, and consolidate, and save some money. Also, the project I took over for suffered from Bus Factor of 1. The users already lost everything once, and I endeavored to ensure that would not happen again. I settled on git-controlled system configs, and distributed backups (Machine backs home up, and admins are responsible for copying that backup off regularly). Anyone from the admin team can get everything running in a new place, in short order. Any one user can replicate what we've done, shy of the backups restoration (Access to the backups is a root-only job).
What? While old-thunix was big, and offered lots of services, to me, it seemed like it lacked a community. So, I decided to turn it into not just a service provider, but a provider for those who are technically inclined, or willing to at least put in sweat equity. ie, I'll never reject a pull request unless it endangers stability, or security. I'll also step people through contributing, if they need.
What Not To Do
Mostly, the one thing you want to avoid is overextending yourself. Taking on a community is a big deal, and not to be taken lightly. Your community members put their trust in you, and if you cannot sustain the community from your own resources for a period of time, you need to be upfront, and scale down your expectations appropriately.
There is nothing wrong with NOT making your own pubnix, and just using the resources freely offered by other folks.
Don't jump foot first into it, without planning a little. Many people have done this before you (They used to be called "free shell providers"), and many will happily lend a hand, or let you bounce ideas off of them. And, popping up a monstrous server, expecting thousand of people to swarm into your clubhouse right away is probably not so great an idea, either.
Don't be afraid to start small. Most pubnixes offer a shell + some public webspace. Don't feel like you need to start off right away with more than that. You can incrementally add things. For most things? 2 cores, and 4GB of RAM is plenty for a user or two, offering only that. With cloud providers these days, it's usually pretty easy to scale up. Not so much to scale back down.
Don't ask people how you should implement something. I'm not talking about troubleshooting tips, we all need that from time to time. But asking,"What should the default shell be?", "Which web server should I use?", "Which Minecraft server should I deploy for users?" are bad questions, in some contexts. You're in charge of the community's resources. You should be deciding how to offer what. A big part of starting a pubnix is architecting it.
Conclusion
I guess to conclude, you may not agree with these steps. That's fine. The great thing about these sorts of projects is that you can do you. It's a big job, or as big as you want to make it, but very fulfilling. Don't bite off more than you can chew, and don't worry about making mistakes (Even ignoring this doc), and have fun doing it!