This article provides some useful technical information for BitFolk VPS customers.

Network settings

Network - London, UK

• Address: 212.13.194.x or 212.13.195.x
• Gateway: 212.13.194.1
• Netmask: 255.255.254.0

In CIDR notation the network is 212.13.194.0/23

Nameservers

You can run your own nameserver, but resolvers are supplied. See Shared resources.

Standard facilities

BitFolk customers have access to a number of free services.

Xen console

Xen console (actually Steve Kemp's Xen Shell) is provided so that you may start, stop and access the console of your VPS even when it is not running or has no networking capability. Access details are provided in /root/PASSWORDS when your VPS is provisioned.

To connect to your Xen console, ssh to:

username@username.console.bitfolk.com

If you wish to authenticate via SSH key, please contact support to get it added.

Cacti bandwidth/CPU monitoring

Cacti is used to gather and display real-time stats of your VPS's bandwidth and CPU usage. There are two ways to access Cacti:

• Authenticated interface – username and password were given to you in /root/PASSWORDS when your VPS was set up.
• Public interface – only updates every 30 minutes, small images, no ability to view custom time ranges.

Nagios monitoring

A Nagios instance is available to monitor most normal services you run and alert you via email if they become unavailable.

Please note that no guarantees are made of the accuracy of this service; if you have anything critical you may wish to monitor it yourself!

Please contact support with the details of any service you would like monitored.

Shared resources

DNS

Recursive resolvers are supplied for use in your /etc/resolv.conf or as forwarders for your own resolver.

DNS - London, UK

212.13.194.71
212.13.194.96

NTP

NTP - London, UK

There are publically-available NTP servers on ntp0.lon.bitfolk.com and ntp1.lon.bitfolk.com. They only use nearby public servers themselves, but using these servers will reduce load on public servers, save you bandwidth and ensure some redundancy. Our upstream also has NTP servers for customer use, at ntp-sup-tfm1.jump.net.uk and ntp-sup-tfm4.jump.net.uk.

We recommend that you use at least the following NTP servers:

ntp0.lon.bitfolk.com
ntp1.lon.bitfolk.com
ntp-sup-tfm1.jump.net.uk
ntp-sup-tfm4.jump.net.uk
0.uk.pool.ntp.org
1.uk.pool.ntp.org
2.uk.pool.ntp.org

Also if you wish, ntp0 and ntp1 are available over IPv6:

ntp0-ipv6.lon.bitfolk.com
ntp1-ipv6.lon.bitfolk.com

apt cache

BitFolk provides an apt-cacher service so that users of Debian-based distributions can benefit from the packages already downloaded by other customers. See the apt-cacher page for more details.

Centos 5 mirror

A local Centos 5 mirror is provided. To use it, add a file /etc/yum.repos.d/bitfolk.repo that contains:

[base]
name=CentOS-$releasever-Base
baseurl=http://mirror.bitfolk.com/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

[updates]
name=CentOS-$releasever-Updates
baseurl=http://mirror.bitfolk.com/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

You may then wish to comment out the "[base]" and "[updates]" sections of any other .repo file in there.

You should then run "yum clean all" before updating, to clear the cache and force an update of the repository xml files.

Traffic from this mirror will not count against your monthly quotas.

SpamAssassin

You will not be able to influence the settings of the spamd servers, but you may find them useful as running your own spamd tends to eat up a lot of RAM. To use these spamd servers please use the username Debian-exim.

SpamAssassin - London, UK

There are multiple SpamAssassin spamd servers accessible from the hostname spamd.lon.bitfolk.com, which you can connect to with spamc or any other spamd client. If you need to connect by IP address then please use 212.13.194.5.

Other services

DNS secondaries

If you're a VPS customer then we are happy to provide a free DNS secondary service provided your DNS traffic is "reasonable" (below several hundred thousand requests per month for all your domains).

This free service is intended for customers with just a couple of domains who do not wish to go to the trouble of providing their own DNS infrastructure. As such it is limited to 50 domains per customer. If you need DNS for more domains then we suggest you purchase another VPS; alternatively we can recommend some companies specialising in these services.

You will need to run your own DNS server and our servers will do zone transfers from it. Any DNS server which supports the AXFR protocol is fine, for example BIND or PowerDNS.

We currently have 5 DNS servers; London, Southampton, San Francisco, Philadelphia and San Jose. We have sole use of the ones in London and San Francisco whereas the other three are part of a DNS collective.

Please see Setting up secondary DNS for more information.

Backup mail MX

If your primary MX is hosted by us then we are happy to offer a backup MX in the US, with antispam and antivirus setup. This will be free of charge provided you do not receive hundreds of thousands of emails per month across all your domains.

This free service is intended for customers with just a couple of domains who do not wish to go to the trouble of providing their own backup mail infrastructure. As such it is limited to 10 domains per customer. If you need backup MX and/or antispam/antivirus for more domains then we suggest you purchase another VPS; alternatively we can recommend some companies specialising in these services.

Please also bear in mind that you will not be able to affect the antispam or antivirus settings of BitFolk's mail servers.

Local backups

6 times daily incremental rsync backups to a local server (in same facility but different hardware, no bandwidth charge) are available for free. You will need to dedicate some of your normal disk space to this, or else purchase more disk space.

Please note that no guarantees are made of the integrity or availability of backups made; they are provided on a best-effort basis.

You will need to allow SSH access to your domain from root@212.13.194.71, by adding the rsnapshot SSH public key to your root user's .ssh/authorized_keys file. Please note that this file is PGP signed by key ID 0xBF15490B and the only line from the file that you should use is the one that starts with 'ssh-rsa'. If you wish you can restrict this key's command to rsync.

Once you have installed this command, please contact support with a list of the paths you want backed up, starting from the root of your filesystem, plus any directories within those that you want excluded. e.g. "Please back up /data except for /data/www/logs."

Backups will then take place every four hours. You will not be charged for the bandwidth this uses, although it will show up on your Cacti graphs.

You may access your backup space as a set of read-only NFSv3 mounts.

Referral scheme

There is a referral scheme in operation to encourage you to bring in new customers. Make sure to get them to quote your VPS name when they make their first payment.

Frequently asked questions

Billing

If I'm paying by bank transfer, what reference should I use?

Either the account name of your VPS or else the invoice number you are paying are best.

If you don't or can't put either of these then we will have to guess at the identity of the payee when the payment comes in. If we can't guess then we may have to wait until you contact us to tell us you have paid.

General OS Issues

Are my bandwidth limits outbound or inbound or both?

For our UK network there is currently an excess of inbound bandwidth, therefore you can have twice as much inbound as outbound. e.g. if your plan allows 50GB data transfer then this corresponds to 50GB out (people downloading from your VPS) and 100GB in (people uploading to your VPS). Excess data transfer is still charged the same.

Does my local traffic get counted towards my allowance?

No. Only traffic destined for or coming from outside of the local network (212.13.194.0/23) will be counted. This is great incentive for you to make use of the shared resources on offer such as an APT cache and recursive DNS.

Why do my Cacti bandwidth graphs seem to be backwards (i.e. inbound traffic shows as outbound and vice versa)?

The graphs are plotted from the point of view of the host machine where each VPS has a network interface going to it. Therefore traffic going to your server is going out from the host, and data coming from your server is coming in to the host.

Just reverse the directions if you want to think about from the point of view of your own server.

Why is my Cacti graph empty and the figures read "nan"?

"nan" stands for "not a number" i.e. "no results". If your VPS has only just been provisioned then this is completely normal - 3 readings are necessary to draw the initial graph, and as readings are done every 5 minutes the daily graph will remain empty for at least the first 15 minutes.

The weekly, monthly and yearly graphs are built from the daily one and will stay empty until the daily graph has the required amount of data: 30 minutes, 2 hours and one day respectively.

If your VPS has been in use for some time and the graphs are empty then there is possibly a problem; please contact support.

Do I need to synchronise my clock like I would on a normal server?

Yes. In theory each domain's clock is supposed to be locked to that of the real host but in practice this seems not to be very reliable. Therefore you should arrange for the following to be executed at each boot:

# echo 1 > /proc/sys/xen/independent_wallclock

or put:

xen.independent_wallclock = 1

into /etc/sysctl.conf, and then set up some means of keeping your clock in sync, such as NTP.

A list of recommended NTP servers appears above.

Is 240MiB of RAM really enough to do anything useful?

Sure. It's not a great deal, but it's not like trying to run an entire machine in 240MiB either. A Xen VPS kernel is very stripped-down and you probably don't need to run many daemons. However please don't expect to be able to run heavy daemons like spamd or clamd in less than a few 100MiB of RAM; it is possible to run both of these in 240MiB with some tuning.

If you find you're running out then you can purchase more RAM and it will be quickly provisioned.

Can/should I run my own firewall?

You can, and you probably should. Whatever you normally use should work. iptables works fine for Linux, for example.

Why don't I see a change in my VPS's RAM when I reboot like you told me to?

What you will have been told to do is shutdown and then boot from your VPS console. If you only do reboot (either from your VPS or in the console) then the VPS will never be destroyed and so will never read the new settings from its config.

I've been told I have an open recursive nameserver. What's the problem?

Please see the Open recursive nameservers article.

How do I restrict rsync-over-ssh connections from BitFolk so they can only do rsync?

If BitFolk is rsyncing your files for backup or DNS purposes then you may wish to restrict these connections so that they may only use rsync, rather than allow them to have a complete interactive login. Please do not try to set this up until after the service in question is known to be working properly, as this makes debugging SSH key logins much more difficult.

For an overview on the subject please read Using Rsync and SSH, particularly the section on restricting to rsync.

When updating libc, the update fails and I get messages regarding /lib/tls

/lib/tls is a directory of libraries (usually owned by the libc package) which are incompatible with Xen.

When your VPS is provisioned these will be moved to /lib/tls.disabled, an empty file created at /lib/tls and then made unreadable and immutable. This is what probably causes your upgrade procedure to fail, but it is necessary because otherwise an update to libc would replace the incompatible TLS libraries.

The easiest way to deal with this is probably to remove everything to do with /lib/tls:

$ sudo chattr -i /lib/tls
$ sudo rm -fr /lib/tls /lib/tls.disabled

Now do your update as normal, and then take care to disable the TLS libraries afterwards:

$ sudo mv /lib/tls /lib/tls.disabled
$ sudo touch /lib/tls
$ sudo chmod 0 /lib/tls
$ sudo chattr +i /lib/tls

Fortunately libc updates are rare, and newer releases such as Debian Etch and Ubuntu Edgy contain a libc6-xen package which is compatible.

Can I compile my own kernel?

Yes; the kernel in use on boot is determined by your grub configuration, so as long as you can put a corrctly-configuredkernel with Xen support in there it should work. You may find it easiest to adapt your distribution's existing Xen kernel package. Typical reasons for compiling ones own kernel are to change the HZ value for example.

BitFolk however cannot support this sort of advanced usage so you should be very sure of what you are doing.

I rebooted my VPS and now it seems to have no networking. What's gone wrong?

At the moment there appears to be an occasional problem with networking when a VPS is rebooted. The network interface does not get deleted quickly enough and prevents its creation when the VPS starts again, resulting in no networking. While we are investigating this, the simplest workaround is to always shutdown and then boot from the VPS console.

I'm getting alerts from Nagios. How do I access the web interface?

There is a slightly experimental web interface at https://nagios.bitfolk.com/nagios/. You log in with your console username and password. This may change in future.

My VPS is not responding, is there anything I can do?

Most likely yes! If you can't access your VPS over the network then the first thing you should do is connect to your Xen console. Most of the time this turns out to be a misconfiguration or some other problem local to your VPS such as you using up all your RAM and swap. Your best chance of recovering from that is with the console command.

If you can't even log in over the console then the next thing to try is probably the usual Linux SysRq commands, using ctrl-o and then the command character. e.g. ctrl-o h will show the SysRq help. Your goal will be to try to get the kernel to cleanly unmount its filesystem(s) before you reboot.

If you have no luck with this approach then as a last resort you can use the destroy command. Please be aware that as the name implies this will instantly kill your VPS, will not cleanly unmount any filesystems, and so you would expect to see a fsck on next boot and may experience data corruption. If the VPS will not shutdown or reboot normally then it would be our only option anyway, so this at least will save you having to contact support.

Once your VPS is shutdown or destroyed you will be able to boot it again. Xen Shell runs inside GNU Screen so you may find it convenient to create a new screen (ctrl-a c) to run the console command in. That way you can watch your VPS shutdown/boot while issuing Xen Shell commands in the other window.

If none of this helped, or if you cannot even connect to the Xen console, please contact support and we'll do our very best to help you.

Can I upgrade or downgrade my plan part way through the payment period?

Yes! Here's the technical details of how it works:

Upgrading or downgrading a VPS plan basically means altering the amount of RAM and disk you are allocated. To alter your RAM we just edit a configuration and then the next time you boot from the Xen Shell you will see this new amount of RAM.

Changing the size of your disk allocation is a little more complicated. You disk space is provided by one or more block devices, e.g. /dev/xvda1. We can add and take away more block devices without having to shut down your VPS. Most people instead prefer to have their first block device grown or shrunk though, and this does require you to shut down and then boot your VPS again for the change in block device size to be noticed. If shrinking you would also of course need to ensure there is enough free space to take away!

Upgrades are subject to there being resources available on the host where your VPS currently resides. This is generally not a problem as hosts are overspecified with regard to RAM and disk. In the rare cases where it is an issue, we can almost certainly relocate your VPS to a host with more available RAM/disk. This would add a further 15 minutes or so onto the downtime required.

Once you have booted your VPS again you will be able to online resize your ext3 filesystem using something like:

$ sudo resize2fs -p /dev/xvda1

If shrinking, however, you'll need us to do it for you with your VPS offline.

We are happy to coordinate a mutually-agreed time with you for any disruptive work to occur. If you are confident that your VPS shuts down and boots cleanly then there's no need for you to be available during the work.

Now for the financial details:

Upgrading part way through a payment period is not a problem. After the upgrade has taken place, an invoice will be raised for the pro-rata difference between the two plans. This invoice will be due immediately unless it is very small, in which case it will be added on to your next scheduled payment.

For example, let's say you are currently on a quarterly payment plan for £22 per quarter. You're 30 days in to this 90 day period and you decide that you want to upgrade to the £44 per quarter plan. The upgrade takes place and then an invoice is raised for (£44 - £22) / 90 * 60 == £14.67. In that 90-day period you would have been charged £22 + £14.67 == £36.67. Once the next payment period starts you would be invoiced for £44 as normal.

Where downgrades are concerned, we are happy to do them at any time, but we won't be giving you a pro-rata refund. Therefore you will most likely want to time the downgrade to coincide with the end of your current payment period.

Does BitFolk support IPv6?

Native IPv6 connectivity is available by default but is currently not officially supported until we work out the best way to manage it.

Please note that most Linux distributions will automatically configure IPv6 addresses and many daemons already support IPv6; those customers firewalling IPv4 will also want to firewall (or disable) IPv6.

An auto-configured IPv6 interface will look something like this:

$ /sbin/ip -6 addr show dev eth0
2: eth0:  mtu 1500 qlen 1000
    inet6 2001:ba8:1f1:f004:a800:ff:fe6a:380c/64 scope global dynamic
       valid_lft 2591934sec preferred_lft 604734sec
    inet6 fe80::a800:ff:fe6a:380c/64 scope link
       valid_lft forever preferred_lft forever

This indicates that the customer has been assigned 2001:ba8:1f1:f004::/64. All initial BitFolk IPv6 assignments are one /64 per customer; if this is insufficent then a further /56 can be routed to you.

If auto-configuration is not desired then you can configure your operating system to not listen to router advertisements and then statically configure any address(es) in the range, except ...::1/64. For example the above customer can use any address between 2001:ba8:1f1:f004::2/64 and 2001:ba8:1f1:f004:ffff:ffff:ffff:ffff/64.

Debian-specific

(Mostly applicable to Ubuntu and other Debian-based distributions also.)

What should I put in my /etc/apt/sources.list file?

We've set up a local apt-cacher so that packages only need to be downloaded once. See the apt-cacher page for more information.

Keeping your VPS up to date

Your VPS is effectively its own separate server system and as such it is important that you keep all software running on it patched and up to date. For Debian Sarge-based servers with all software installed from Debian packages this is very simple.

First you need to make sure that you have the sarge/updates line from above in your /etc/apt/sources.list. Now all you need to do is arrange for the following commands to be run as root however often you wish to check for updates (we suggest daily):

# apt-get update
# apt-get upgrade

There are a few methods for automating this; you can probably come up with some yourself. If you like though you can use the same script that we use which can be found at https://svn.bitfolk.com/repos/local-apt/trunk/. Copy local-apt.pl to /usr/local/sbin/ and make it executable. Copy local-apt.sh to /etc/cron.daily/local-apt. You will now get a nicely-formatted email each day telling you what needs upgrading. You still need to do the apt-get upgrade manually.

You may also find it useful to install apt-listchanges which will mail you regarding the changes introduced by each upgrade.

The above method also works for "testing" although you may find you have updates almost every day.

When doing an apt-get or aptitude update I see an error like /dev/mem: mmap: Bad address; is this a cause for concern?

This message is an error output of dmidecode which is called from within one of the scripts for a package you just installed or upgraded. dmidecode is trying to access low-level hardware information in order to pick some suitable default configuration. It will never work under Xen but it can be safely ignored.