The ByteSized Blog Peek inside our brains

25Mar/10Off

ByteSized Setup – The Website and Daemon

Previously we gave you an overview of our setup, this time we will go over all the website functionality for both the user and admin users.
We wanted to have a unique feeling without using a generic template and spending money on a real designer ;)

This is one of the early sketches we made, you can see some parallels with the current design although not much survived. As you can see we were pretty nameless back then.

After this inspiration-shot the actual building started it took two weeks to get the first version live that had user registration and a simple payment system.

After this small history lesson let's continue to the main feature as of this date, this part might not be so interesting for current members as they should have access to everything explained here, feel free to skip it. (Allmost) all data you will see in the screenshots, which can be clicked to enlarge, is fake, so don't bother trying to login with it ;)

One thing that might be new to current mebers is the second menu-bar, but more on that later. What you are seeing here is the main-screen of the website; The Dashboard. All the important information is on there, from box information till your latest tickets. If everything goes well this is the only screen you would really need. The first connection with the bytesized-daemon is made here, when the dashboard loads it will try to get your quota information from the server you are placed on, hekatonkheires in this example. Ff it somehow fails it will fallback on the latest quota it got from cache. The same goes for the service status, only there is no cache mechanize for that yet, so if that fails you will just see a message explaining that the server did not respond in time. The reboot box option runs your startup and stop scripts. These reside in your home folder and tell the server what to do on reboot. By default it just kills are your processes gracefully an starts them again, but you could do all kind of stuff with it if you are a little apt with linux.

The "Balance" item takes you to a page where you can see all kind of financial information, how much money is on your bytesized-account, when you need to add money again, and when your next invoice is due. Next in line is the "Tickets" page. This is the place where people can go to for their questions. We make the difference between private and public tickets. Public tickets are viewable by everyone, this enables members to help each other out, or discuss certain topics. Private tickets are only viewable by admins and are primarily used for payment issues.

The "Wiki" page is just that, a wiki filled with information on general website usage, building a custom version of your favorite client or on setting up a FTP client. Everybody can add new/edit pages and so far it only got wiped once! At the "Account" page you are able to change your password, email and other account related details. "News" is an archive for news that isn't visible on your dashboard anymore, since that only displays the last three items. "Blog" is a simple link to, well you guessed it, our Blog.

Now the admins got a dashboard as well, and this is what's on there. It's not easy on the eyes, but as only two users have access to it, it doesn't matter much, for now...

Free spots gives us the intel on which harddisk have potential space left. You can see that Apate has 160gb left, which is enough for one Lunchbox.

After the free spots is a list of users who are over due. Usually we give them one "free" day to come up with the money, but if they don't we can delete them with a press of a button. This is where the daemon kicks in again. When we press delete we mark the user as "beign deleted",that's why there is a option for those on the dashboard as well,a request gets send to the server the user is one and the daemon calls the slicer and tells it to delete the user. Since it does a global search on the server for the users data this can take a while. When it's done it sends a message back to the website that the user is deleted from the server, the only thing left to do for the website at that point is delete the user from the database.

Since we allow users to prepay it's important to keep track of that money, folding open the "Top pre-paid" will show us who has what kind of money on his account. Slice breakdown shows us which plans are most popular, the lunchbox plans win, and how much turnover each plan has.

Users being deleted are users that are flagged for deletion but that the server did not delete yet. This is a safety measure so we don't "forget" about users if the deletion tool fails, which it luckily hasn't done yet.

If a new user signups up for our service a new box pops up on our dashboard. Once that user turns to "paid" we are ready for deployment. We are able to choose a server and harddisk for deployment. Once we found a suitable server, and selected the right harddisk it's deploy time. The website contacts the daemon on the Erato (in this example) and relays all the information to the slicer. Which client should be the default one for this user, how much space is allocated to this plan and which harddisk should this user be created on. Once it's done, just like the deletion, it posts back all the data it created for the user so it can be stored in the database.

Next up is the user database of the website. This gives us quick access to all the data we need to help out with support. Viewing a user gives us the dashboard information of that user plus extra information, all the tickets this user created, and admin-visible notes. It also gives us the ability to redeploy users, if they feel they messed up their configs, or want to start out fresh we can redeploy

them, deleting everything and rolling out a new box.

News is pretty much just that, the ability for us to create news item. Nothing to tell about that one.

Now the server overview gives us some handy information. How much usage it today and yesterday, what the average turnover/profit per server is and how much theoretical space is left. To calculate those things we need to specify a few things when adding a new server to the website. How much harddisks it has and how large they are and how much a server costs on a monthly basis.

When viewing a server we get more specifics. What the current server-load is like, how much space is left, who are deployed on said box and on which plans they are. This info is especially handy when we are looking for suitable servers to deploy users on. It gives you everything you need in an overview.

The "Finance" page gives us some really rough numbers, like how much turnover we have on a monthly basis, how much profit we have per server or user we make on average. I say really rough because it doesn't account for specials or time a box is empty etc. It's just a momentary snapshot.

"Plans" is where all our plan information lives, although there are a only three plans active by default we have loads more. A plan is fairly simple. It just needs a few details; How much space does this plan have, how much does it cost and should we display it on the frontpage/sign-up page. The space is important when deploying a user because this defines the quota set on the servers and price is used when creating invoices.

That's all for today, I hope you enjoyed reading and if you have any questions/suggestions please leave them in the comments.

14Mar/10Off

ByteSized Setup: The Overview

As an opening article for this blog, we want to talk about our software and our whole setup. This will be first article in a whole series on the topic.

As for why we're writing this: We want to provide as much transparency as possible and help our (potential) members understand how the gears and cogs under the hood work. While this is the main goal, it would also be great to provide ideas for other people and their own setups. As we've encountered alot of interesting challenges along the way, it also might spare some people the trouble of reinventing the wheel. One of the best possible outcomes though would be to start a discussion on how we could improve our setup, so we're welcoming all constructive criticism and suggestions as well.

This first post should provide a a bird's eye view of the whole system, omitting the details to illustrate the general idea. Other articles will try and give an in-depth explanation of each of the separate parts.

The Servers

We have chosen to not give out VPS's but to use normal unix user accounts to share the servers. This way we feel like we can give better support and have some control over the servers, while still giving the user a certain amount of freedom. A box is simply a user account on a linux server with preconfigured software.

The Website

All things begin and end on the website. The website, written from scratch, running on Ruby on Rails uses a mysql backend for the user database. To communicate with the servers (e.g. deploy users to a server or get the harddisk usage) it connects to a daemon running on each server. For example: After a user is registered we, as admins, can choose a harddisk and server to deploy the user on through the admin-interface, when this happens the website sends a request from the website to the chosen server to the "byte-daemon".

The Daemon

The byte-daemon has several purposes one of them is creating new users, but disk usage and service status are a few other things it handles for the website as well. It acts as a man in the middle if you will. The byte-daemon is running as a dedicated account on the boxes, which has a few sudoers entries to allow it to do things that are usually reserved for root (adding/deleting users, etc.)

The Tools

The byte-daemon runs an other program called the "slicer". This slicer tool actually does the hard work, creates a new user account, creates a random secure password, selects ports for all the services, sets up quota and configures the torrent clients for the new user. When it is done it sends a request back to the website with the data it created. The website saves the data in the database and notifies the new user that his account is ready.

A picture says more than 494 words

Even the people who skipped most of the text should now be able to understand the first parts of our setup. Next week we will try and go a bit deeper into our software-stack.