phpMyAdmin

Posted on by
Reply

(this post will also appear in our virtual private server blog)

Since phpMyAdmin, the tool to manage MySQL databases and the underlying server engine, is often the target (and one hard to miss!) of intrusion attacks, we feel it might be worth to mention some aspects and tips that could improve the security of your server, be it a dedicated server or a virtual private server (VPS).

  1. Keep your phpMyAdmin installation up to date. While this doesn’t prevent attacks per se, it makes sure that all old bugs have been fixed;
  2. Do not allow anyone to access the setup scripts, or remove them altogether;
  3. Allow access only from trusted IP addresses;
  4. Move the phpMyAdmin installation away from the default path /phpMyAdmin and outside the webserver root;
  5. Possibly even add another authentication on top of the phpMyAdmin authentication to prevent robots and brute force attackers obtaining valid user credentials directly;

(1) and (2) should be mandatory for every phpMyAdmin installation;

(3) is a good idea, but might not be feasible for you, or the range of allowed IPs is so large that it won’t matter anyway. It also requires some minor webserver configuration changes;

(4) and (5) require additional meddling with the webserver configuration, something that might be hard to do if you are running a control panel on top of your dedicated server or virtual private server.

Please note that intrusions into servers via a phpMyAdmin attack vector are very common, if you care to have a look at your webserver logfile, you will inevitably find a lot of random accesses to /phpmyadmin in several variations, and hopefully they are all followed by denied or unauthorised response codes from your webserver. phpMyAdmin is not the only way to break in of course, but an outdated or open phpMyAdmin version on a server is like a red cloth for a bull…

phpMyAdmin is not being updated that frequently, but if a security issue arises, you should be fast to close that door – consider going for the managed option with your contract, it will take this load off your shoulders and give you peace of mind as such options typically cover security updates.

Memory consumption

Posted on by
Reply

(this post will also appear in our virtual private server blog)

Nowadays, CPU performance is something that is pretty easy to achieve with comparably little investment. Intel’s L/X34xx, E/L/X56xx, or the latest E3 12xx(L) CPUs as well as AMD’s new Opteron 41xx series will cover most requirements one could come up with for a startup site, even with a considerable number of users online at the same time.

A fact, however, that is often neglected, is memory consumption. Memory is key and crucial to your website performing well and supporting a large number of users online at the same time.

Let us consider a typical LAMP environment, i.e. you are running Linux, Apache, MySQL, and PHP. The operating system will not need much overhead, typically a couple hundred MB should be enough, MySQL will need what you give to it (large buffers, high number of connections, etc. increase memory usage, naturally), and PHP is a double-edged sword in many cases anyway. One of the largest memory hog in moderately busy machines is the webserver itself – most often Apache. Even if carefully tuned, and going to extreme setups with either prefork or worker, you can end up anywhere between 5 to 15 MB per connection. Depending on the number and sort of modules you need, this will vary a lot – lightweight servers will be closer to the lower end, but an Apache having everything enabled is more likely to end up with 15MB of RAM per connection – there are alternatives to Apache, and most control panels using Apache will go for the prefork MPM, and unless you want to recompile and configure on your own, this is basically what you have to live with.

Let’s assume 10MB per connection, an average value. Imagine you want to be able to serve 500 simultaneous connections – with 10MB per connection, you are going to need 5GB of RAM for the webserver alone! If a lot of these connections are database intensive, then you might be coming close to 8GB of RAM usage already: so in order to have some safety margin, you should be going for 12GB or 16GB of RAM in your dedicated server (depending on CPU architecture and memory channels) or virtual private server.

Even on a site that is not really busy, with maybe 50 connections at the same time, you should be aware of overall memory consumption: 50 x 10MB, plus OS overhead, MySQL, and PHP will most likely add up to 2GB of memory as well, so here you should be going for 4GB already to have some growth potential.

What happens if the machine runs out of connections and/or memory, and eventually also out of swap space?

  • your site will respond more slowly;
  • your site may stop processing requests altogether;
  • your site may throw errors;
  • your site might become inconsistent: nothing is worse than an partially processed request that gets through to the database backend at random only;
  • your site may become unreachable;

A dedicated server will be able to handle such problems somewhat better than a virtual private server – due to its architecture and swap space available. The latter often does not have any swap space (there are virtualisation architectures where this is not true, however, such as KVM, for example) and will be hit full swing instead of being able to mitigate the crisis arising from low memory.

You want to avoid such scenarios – for the sake of your business and your customers. Do not save on memory – better have some spare than have none left.

Linux flavours

Posted on by
Reply

(this post will appear in our virtual private server blog as well)

Abstract/Summary – basics only

These days, the most prominent Linux flavours are Red Hat, CentOS, Debian, Fedora, SUSE/SLES, and Ubuntu. The number of variants of these flavours is legion, the main distinction here, however, is that Red Hat is a fully commercial branch, whereas the others are available free of charge.

Red Hat is closely related to CentOS and Fedora, and while avoiding too technical an explanation, in layman terms CentOS can be seen as the “free” version of Red Hat, Fedora as the “next generation Red Hat”. There are a lot of caveats with these metaphors, but they help to get an overall idea. Debian and Ubuntu are independent (similar to some extent) flavours with their own community. Ubuntu has gained a lot of popularity recently due to its cloud abilities. SUSE was originally independent and started off in Germany, but has been bought by Novell and has seen a decline in community lately.

Red Hat and CentOS are more conservative in their application of packages and in their approach of going for the latest in everything. This is not necessarily a bad appoach at all – a huge number of commercial, high performance, and mission critical applications are specifically tuned for Red Hat, based on our own Linux experience since 1992, starting with Slackware, we identified Red Hat and CentOS as the leading Linux flavours for our own server environment (this is not a strictly objective judgement per se, as we of course need to evaluate our own needs first, and we encourage digressing opinions).

Red Hat and CentOS are ideal solutions for virtualisation, too. Both offer similar technologies, though we tend to go for KVM with Red Hat, and openVZ with CentOS (openvz will also run on Fedora, by the way). KVM (kernel based virtual machine) employs a different concept than openVZ, and allows running guests in a way such that the guest does not really know it is a guest only. That gives you a chance to, say, run a Windows server as a guest system on a Red Hat (or, rather, KVM) host – openVZ will only support Linux guests, and the ones we have best experience with are CentOS, Debian, Fedora, Ubuntu, and to some extent SUSE.

When it comes to control panels, we have excellent experience with CentOS + cPanel/Plesk, and Debian + Plesk. These setups pretty much work out of the box, and wont give you any hassles in a live environment.

Oversubscription or not? Contention – the good and the bad

Posted on by
Reply

(this post will also appear in the virtual private server blog with additional content)

The terms oversubscription and contention are often heard when it comes to providing services as an ISP, for example regarding CPU resources, memory, bandwidth, etc. Generally speaking, it means selling/providing services or advertising them to more people than there are effective simultaneous resources available. Let us look at bandwidth, an often cited example, first:

Let us assume your VPS is on a Gig link to the host, and that there are 3 more guest systems on the same physical host, also with their own Gig link to the host, but the host only having a single GigE connection to its switch. In that case, we have a contention ratio of 4:1 since we have 4 VPS with Gig links, but only one effective Gig uplink to the outside world available. Here, oversubscription is rarely an issue – a typical VPS going at a sustained gbps isn’t feasible and would be better sold as a dedicated machine anyway, so such rates are only seen during spikes, with the other VPS rarely competing for the available host bandwidth. This example continues from the host to the switch it is connected to – how many other physical interfaces there are that are competing with the respective uplink. A trivial contention ratio here might be 8:1, 16:1, 24:1, or similar – i.e. your typical GigE switch with a gbps fibre uplink has to serve 8, 16, or 24 machines that, in theory, could also use the entire bandwidth of 1 gbps available. Here it is already trickier to judge whether contention might be an issue – a customer with rather evenly shaped traffic curves is more predictable than a customer seeing a lot of spikes during the day, spikes that can take valuable bandwidth away from other customers.

How do ISPs do it? Most ISPs accept contention ratios based on the traffic they see on the switches, routers, throughout the entire backbone. This is a legit practice, and as long as it doesn’t handicap one group of users against another, no one will probably see that is in effect being done at all. Some ISPs sell bandwidth at dumping prices, fully aware that their traffic/cost/revenue model is anything from risky to shady – when you encounter a bandwidth deal that sounds too good to be true, it probably is – like anything in life. Traffic cost patterns have evolved in various regions of the globe, and comparing several providers on a single continent or within a large geographic region (US, UK, continental Europe, etc.) can help you a lot to find out the truth behind the myths of “unlimited traffic” – it also helps asking questions such as “unlimited traffic – I have a website generating 100TB of traffic each month – still unlimited?”. Often the smallprint of providers will tell you things like “irregular use is due to caps”, “bandwidth in excess of…is subject to approval/surcharge”, etc. Make sure you get your ISP to give you the facts straight, ask until you are sure that what you need and want is going to be provided without hidden costs.

How do we do it? In terms of bandwidth, we have a contention ratio of 1:1. Yes, that’s correct. Bandwidth we sell is dedicated, and we make sure that you won’t share it with any other customer even in case all of them are requesting their share at the very same moment. This model has its disadvantage: our traffic is more expensive than oversubscribed traffic. The advantage: you get what you pay for, no matter what, no hidden costs, no caps.

Control panel or not?

Posted on by
Reply

(a similar post will appear in our virtual private server blog, with some adaptions, though)

When you finally have your dedicated server up and running, you will have to decide whether you want it “bare” or with a control panel on top of it.

The advantages of a control panel are obvious:

  • easy administration of trivial tasks, such as adding domains, accounts, email addresses, etc.;
  • graphical interface instead of having to go through a console or plain windows administration tools;
  • easy update mechanisms;

The disadvantages, however:

  • generates memory and CPU overhead;
  • once you go for a control panel, you are stuck with it;
  • difficult to next to impossible to make changes to the underlying operating system without potentially critical repercussions on the entire system;
  • features offered by the operating system and needed by you might not work with the control panel;

Control panels are moderately expensive (although you can always go for one of the free ones) – for dedicated environments prices vary around USD 20-50 per month, inside a container / virtualised environment, they are usually considerably cheaper.

So what, then, are the decisive factors whether to go for a control panel or not? We believe that even for experienced administrators, a control panel makes sense if you want to offer webhosting or want to act as a reseller, if you have a large number of standardised services or packages (domains, hosting & email accounts, a run of the mill LAMP environment, etc.).

A control panel might not be the best solution if you only run a single application or site, especially if there is no hosting associated with it, for example running an eCommerce site such as a webshop on one server and keeping your emails on a separate hosting account wouldn’t require you to have your own control panel – if you are familiar with system administration, you can find your way around your application and server anyway, and if you are not, the person or company hired to maintain your system for you isn’t going to benefit from the control panel either, quite the opposite: it might even make their task more complex and difficult because they will have to make sure that the underlying operating system and the control panel are always in sync – unnecessary overhead in every aspect.

 

Why managed?

Posted on by
Reply

When you order a dedicated server, it usually comes naked with its operating system of your choice (usually a Linux flavour or Windows Server edition), but without any system administrator support beyond what ISPs usually call 24/7 remote hands support.

If anything goes wrong with your machine, support will typically only do what you tell them: reboot the machine, restart this or that service, read off the screen, etc. Unless you are a sysadmin, this is not going to help you much.

Ideally, you should go for the complete package, i.e. you make sure you get the hardware from a reliable ISP, you make sure that they have system administrator staff at hand who are able to dive into your needs and individual setup in order to be able to actually do something about the issues you might be facing. That often implies that your developers and your sysadmin staff must cooperate very closely. Your developers need to be aware of the capabilities and limitations of your machine, and your sysadmin(s) need/s to understand what your applications do, how they react to spikes, how many resources they are using on average, how subsets of applications (such as DB service, webservice, etc.) interact with each other, and so on.

Our advice: do not save on sysadmin money. 24/7 availability of a system administrator for your applications and server, someone who knows his way around your machine and applications, is an invaluable asset. It might add to your monthly cost, but if you want to be sure that you are not on your own when push comes to shove, having someone experienced to handle the problems for you is, in fact, a must.

Dedicated Servers – the basics

Posted on by
Reply

Nowadays, with virtualisation and cloud computing being nearly omnipresent, it is important to understand the advantages of having a dedicated server. At the same time, one should be aware when resources on demand or a virtual private server (VPS) are the better solution.

A dedicated server has the advantage of not sharing physical/machine resources with anyone else, i.e. you do not face contention over I/O, network/bandwidth, CPU, or memory usage. The entire machine is yours, and all its resources are at your disposal.

This is also where the problems start:  if your website is fairly idle most of the time and only utilises a lot of CPU, memory, etc. during occasional spikes, you are wasting a lot of resources – which you need to pay for nevertheless of course. On the other hand, your site may require physical separation from other customers for security and compliance reasons – in that case you cannot escape a dedicated server anyway.

What, then, are the main aspects to consider when you rent your dedicated machine:

  • evaluate memory needs;
  • evaluate CPU needs;
  • evaluate disk space needed;
  • evaluate bandwidth needed;
  • evaluate management needs;

In this blog, we will be covering all these and more aspects, and we hope that you will be benefitting at least a little from what we have to say here.