A server box is a full-blown UNIX (FreeBSD) server, living on top of a
UNIX base system, alongside with several other, initially identical
boxes of the same kind. Each box has its own email, news, name, web
server etc., in short, its own everything. There are no commonly used
services in this setup. Each box is self-sufficient. There is a
central accounting of some basic server resources that is, however,
mostly invisible to the box user. The only place where it shows up is
in the hourly updated usage diagrams built into each box's web server.
These diagrams are part of the "Server Box Information Area", a small
information center about features availble in each box, like resource
usage diagrams, web statistics, a webmail and a SSH Java applet for
those equipped only with a web browser, and of course lots of
documentation. This area resides under
https://mydomain.tld/box/
Just log in as user 'bigboss' with the password we gave you. In this
area we will also keep you posted about changes we make to the system,
be it security fixes or functional enhancements.
|
|
|
We do an hourly accounting of some resources a user, or rather his
server box, can consume. There are network volume, CPU time, disk
I/O operations and disk space. Each of those are available only in
limited supply on a real-world server. Therefore, in an attempt to
exert some fairness, and as an incentive to use resources efficiently,
we may charge customers according to their resource usage, depending on
the billing plan. This way, choosing the right tools and algorithms,
and possibly going an extra mile or two pays off with us, in the literal
sense.
In order to not keep you in the dark until after the fact there
are resource usage diagrams available in the "Server Box Information
Area", spanning different periods of time, up to a year. These diagrams
get updated once per hour and additionally show average values you
can use to predict what you will have to pay at the end of the month
(see below).
Do not let peaks in these diagrams worry you, though. This happens from time
to time because processes get accounted for only when they terminate.
Since most daemons are long-running, when they finally terminate they
release all their accumulated resource usage at once. This is where
the peaks come from. For billing purposes, however, only the averages
over the whole month are relevant.
Note that in order to get at the accounting data of daemons that never
terminate all server boxes reboot themselves automatically once a week,
usually beginning in the 4th hour (of the timezone the
box lives in) in the night between Sunday and Monday.
If you are logged in at this time you get notifications about the
imminent reboot, beginning five minutes ahead of time.
This automatic reboot is done by
an entry in '/etc/crontab'. You can change the entry for the event
to take place at a more convenient time. It has to be at least
once a week, though. If a box fails to reboot itself for more than
7 days, it gets rebooted by the base system in order to take the
necessary accounting readings.
Note also that, since a UNIX system is in some sense like a living, breathing
organism, there is some internal resource usage even when the box is idle
otherwise. Daemons wake up from time to time to check things and do
some maintenance, cron jobs run at certain intervals etc. Also, there
is a minimum amount of disk space (about 25 MB) a box allocates in the
user data filesystem in order to work. However, this minor usage is
negligible compared to what an active box consumes, and is already
priced into our rates.
In case the resource usage diagrams show a recurrent
pattern, that is, there is little long-term fluctuation, you can actually
use these diagrams for a sufficiently accurate forecast of the monthly
costs. The 1-Month diagrams are suited best, and for shorter term
predictions the 1-Week diagrams will do. The 1-Day diagrams, however, are
too inaccurate (too little data) for a reasonable forecast.
Just take the four average values of the first
three diagrams, multiply them by 720 (a month has roughly 24*30=720 hours)
and then by the respective rate from the price list. Watch the
units, though, that is, the position of the decimal point. For the last
diagram, use the value displayed as the background-like dark blue bar,
which corresponds to the size of your user container (200 MB by default).
Multiply that directly by the rate from the price list. Now add up all
five results, and what you end up with is the raw monthly amount to expect.
Of course, for actual billing purposes this amount may be subjected to
adjustments and modifications like rebates, minimum and maximum amounts
etc., in accordance with our billing model.
|
|
|
In order to make our unique setup resource efficient, and therefore affordable
to the customer, the filesystem is comprised of two sections. The actual
user filesystem contains only data owned by an individual box while
the major part of the UNIX system resides in a system container shared
by all boxes. The user container is mounted as an overlay to this
system container. Here is an illustration of how this works:
From the user's perspective this separation is invisible. As long as
he keeps accessing files in read-only mode (executing programs implies
read-only access) he (unknowingly) shares them with all other box
users. As soon as the box user opens a shared file for writing,
though, the system copies it into the user container, and from thereon
the user works on his personal copy of the file. This mechanism is
common in UNIX and is called "lazy-copy", or just "copy-on-write".
Note that timestamp, permission and ownership changes qualify as
writing to the file too.
In order to get rid of the personal copy again (after all it now costs
precious user disk space) the user can remove it. This does not mean,
however, that the original file shows up again automatically.
Instead, a so called 'whiteout' gets installed in place of the deleted
personal file, obscuring the view onto the original file. This is
done in order to not break filesystem semantics since programs and
humans do not exactly expect a new file to pop up under the same name
they just deleted.
You can actually see the whiteout by doing an 'ls -lW' in the
respective directory. It stands out by its unusual file type 'w'.
Do not use any arguments with 'ls' here since filename globbing is done
by the shell, and the shell cannot see the whiteouts. Also, with the
'-type w' option of the 'find' command you can deal with whiteouts
recursively.
To get rid of the whiteout too, use 'rm -W <filename>', where
'<filename>' is to be replaced with the whiteout's name. Now you can
see and use the underlying original file again.
In order for you to find out which of the files are actually yours,
you can use the '-O' option of the 'ls' command (the letter 'O', not
the number zero). For instance, 'ls -lO /etc' displays something
like this:
p -rw-r--r-- 1 root wheel 1329 Jul 9 20:15 adduser.conf
p -rw-r--r-- 1 root wheel 1327 Jul 9 20:15 adduser.conf.bak
s -rw-r--r-- 1 root wheel 301 Feb 24 23:26 adduser.message
s lrwxrwxrwx 1 root wheel 12 Aug 1 21:51 aliases -> mail/aliases
s -rw-r--r-- 1 root wheel 208 Feb 12 2002 amd.map
s -rw-r--r-- 1 root wheel 1167 Feb 12 2002 apmd.conf
s -rw-r--r-- 1 root wheel 272 Feb 12 2002 auth.conf
p -rw-r--r-- 1 root wheel 962 May 31 06:15 crontab
s -rw-r--r-- 1 root wheel 108 Feb 12 2002 csh.cshrc
s -rw-r--r-- 1 root wheel 486 Feb 12 2002 csh.login
The first column denotes whether the file is private ('p') or shared
('s'). In our example the files 'adduser.conf', 'adduser.conf.bak'
and 'crontab' have been written to from inside the user container
and are therefore private copies, overriding any shared files in
this directory with the same name. Note that directories are
always private.
There is also a utility 'ismine' installed that detects whether the file
you give it as an argument belongs to you or the system container.
In best UNIX tradition it does not print out anything but instead
sets its exit status to 0 (true) if the file belongs to you, or
a value != 0 (false) if it does not. So you can use it in shell
scripts to take decisions based on the file's ownership.
Here is an example:
ismine /path/to/file && echo is mine
prints 'is mine' if the file belongs to you. On the other hand, if
you would like to recursively find files residing in your user container,
there is 'findmine'. It works like this:
findmine /usr/local/bin /usr/local/lib ...
That is, it recursively lists all of your own files
in the directory hierarchies '/usr/local/bin' and '/usr/local/lib'. You
can, of course, give any number of arguments, but you may want to use this
sparsely since scanning whole directory hierarchies can
generate much disk I/O load. Note that the list of files is not sorted,
which is in line with what you would expect from the normal 'find'
command.
Finally, if you just want to look at how things are
done by default, there is a copy of the system container mounted under
'/system/sd' in its pristine form, that is, not overlayed by the user
container. Although you cannot change anything there since it is mounted
read-only, you have access to all the files in their original form, so
you can use the 'diff' command to find differences, even between
whole directory hierarchies.
Note: As far as disk usage is concerned, you should always leave some
headroom (at least 30 MB) in the user filesystem. UNIX systems need
some wiggle room, or things start going wrong.
|
|
|
Due to the shared nature of the system area we can afford to
preinstall a liberal amount of software for the most common needs.
Use 'pkg_info' to get a list with one line comments. Also, 'pkg_log' informs
you about the time of last modification of each preinstalled (shared)
package, while 'pkg_logpriv' does the same for locally installed (private)
packages.
We would like to point out that the majority of our preinstalled
Internet services additionally provides encrypted access, namely
via SSL. And all of it works out of the box (pun intended :-).
So in the interest of security, with our setup there is
no need to do anything over unprotected data connections.
Here is a list of the main services:
| Web server/accelerator | http, https |
| Mailer daemon | smtp (SSL via STARTTLS command) |
| Email retrieval | imap, imaps, pop3, pop3s |
| News retrieval | nntp, nntps |
| Shell access | telnet, ssh |
| File transfer | ftp, sftp |
| MySQL database | SSL via stunnel |
| Your services | SSL via stunnel |
As far as secure logins into your server box are concerned, if you do not
have an SSH terminal program available you can use the SSH Java applet
which you can select in the "Server Box Information Area" that you are
probably currently reading this documentation in. Just make sure that
Java is enabled in your web browser, click on the respective link in
the menu to the left and wait for the SSH window to pop up. All you
need to do then is log into the address it gives you by default, either
as superuser 'root' or any existing unprivileged user.
This feature also comes in handy if you are away from your usual
computer(s) but have to act quickly because of an emergency, for
instance. You can then log in from any browser worldwide that has
SSL and Java.
While secure transmission protocols protect your data while it travels
over the Internet, there is another important aspect with regard to
security. All preinstalled software in our boxes is compiled with gcc
versions that generate stack smash protector code. So while vulnerable
programs and daemons still might crash when someone tries to exploit
a stack based buffer overflow bug (the most common form of security
flaw in software), the potential intruder at least cannot gain root
access anymore in most cases. You can use this feature for your own
software as well. Just compile it in your box. It will then be
protected automatically.
|
|
|
Users can customize the preinstalled software,
since modified config and data files automatically become private copies,
as outlined above. In order to avoid "collateral damage" when we upgrade
centrally maintained software packages we employ a number of strategies:
-
If the differences between software revisions are minor we tweak
the config and data files for those users who happen to have private
copies of them, in order to retain compatibility. Most of the time
this is not even necessary, though.
-
In case of more sweeping changes we install the new version in
parallel, if this is possible, and make the new version the default
for newly generated boxes.
-
If installing the new version in parallel is not possible we move
the entire current application into its own directory hierarchy and
deploy path redirections in all affected boxes, by means of symlinks.
Then we install the new revision. This way the upgraded version
becomes the default for newly generated boxes, while already existing
boxes keep using the old version. We provide upgrade docs and also a
script that effectively removes the symlinks, so each user can upgrade
at his convenience.
This methodology is key to years of undisrupted
server operation, without having to compromise on software maintenance.
The vast majority of upgrades takes place in the background and without
noticeable downtimes.
|
|
|
|
