no-nonsense vps hosting
This article provides some useful technical information for BitFolk VPS customers.
Sometimes the best help can be found in the community of BitFolk users. If you can't find the information you need in this document then here are some other places you could try asking.
We have a wiki which allows customers to edit any page. This is ideal for sharing guides and other contributed documentation. Over time more of this page will be migrated to wiki articles.
The preferred place for discussion amongst BitFolk customers is the users mailing list. The list has a public, searchable archive.
Please note that emails sent to the list are deemed to be for publication without condition, and the information will be available in perpetuity. We are not responsible for removing or otherwise concealing your communication after you caused it to become public.
We will usually edit or remove information from the list archives only in the event of an inadvertent disclosure of confidential information; however, a sender's contact information (name, email address, phone number, etc.) does not fall into that category.
The users list is also the primary place that any important notices, planned downtime and outage post-mortems will be posted, so it's recommended that all customers be subscribed to it.
There is a vibrant user community on IRC, although this is an unofficial, largely unmoderated environment recommended only for those with a thick skin, and probably not suited for minors. Or possibly anyone.
The channel #BitFolk can be found on irc.bitfolk.com. You can find more information about this IRC channel on our wiki.
There's a few other bits and pieces of social media such as Twitter, Facebook and Last.fm. You'll find the details listed on the contacts page.
In CIDR notation the network is 85.119.80.0/21
You can run your own nameserver, but resolvers are supplied. See Shared resources.
BitFolk customers have access to a number of free services.
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.
Documentation for this feature is now maintained in our customer wiki.
Our Cacti installation was retired in November 2020 in favour of a more advanced system based upon Prometheus and Grafana.
More information about the statistics available to customers is available on our wiki.
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:
Information about our free monitoring service has now moved to our wiki.
Our Nagios instance was decommissioned in December 2018 and was replaced with a different system. This entry remains only so that links do not break.
The BitFolk Panel is still under development, but contains a lot of useful information about your BitFolk account, including your VPS configuration, backup settings, and your invoice history. If you have any feature requests we'd love to hear about them, either directly to support or discussed on the users mailing list.
The login credentials for the BitFolk Panel are the same ones used for the console, Cacti and Nagios, and can be found in /root/PASSWORDS when your VPS is set up.
Information about shared resources has now moved to an article on our wiki.
Information about DNS has now moved to an article on our wiki.
Information about NTP has now moved to an article on our wiki.
Information about our apt cache has now moved to an article on our wiki.
Information about our software mirrors has now moved to an article on our wiki.
Information about our SpamAssassin has now moved to an article on our wiki.
Information about the DNS secondary service has now moved to an article on our wiki.
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.
Information about our backups service has been moved to an article on our wiki.
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.
Yes, it is located on our wiki.
Most BitFolk services that have a login are using centralized authentication. There's an email password reset feature linked from the Panel's login screen. It will ask you for your account name and then send an authorization link by email to the address we have on file for you. Once you follow the link, your password will be reset to a random string which it will tell you.
If you don't have access to the email address that we have on record for you, e.g. because it's out of date or because it's hosted on your VPS which is currently down, you're going to have to submit a support ticket by email. If your service is down and not knowing your password is preventing you from fixing it, please feel free to send an SMS to the emergency contact telephone number.
There's several ways to tell.
$ host ruminant.console.bitfolk.com ruminant.console.bitfolk.com is an alias for console.barbar.bitfolk.com. console.barbar.bitfolk.com is an alias for barbar.bitfolk.com. barbar.bitfolk.com has address 212.13.195.134 barbar.bitfolk.com has IPv6 address 2001:ba8:0:1f1:230:48ff:feb9:e632Indicates that this VPS is on barbar.
Documentation for this answer is now maintained in our customer wiki.
The Billing section of our Panel has a unique reference you can use so that we can recognise your bank payment.
If you don't or can't use this reference 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.
Documentation for this answer is now maintained in our customer wiki.
Documentation for this answer is now maintained in our customer wiki.
Documentation for this answer is now maintained in our customer wiki.
Documentation for this answer is now maintained in our customer wiki.
Documentation for this answer is now maintained in our customer wiki.
Documentation for this answer is now maintained in our customer wiki.
Documentation for this answer is now maintained in our customer wiki.
This service has now been decomissioned and replaced with a new monitoring service, which is documented on our wiki. This and the sections below only remain to prevent links from breaking.
Documentation for this answer is now maintained in our customer wiki.
Documentation for this answer is now maintained in our customer wiki.
Documentation for this answer is now maintained in our customer wiki.
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 1,000GB data transfer then this corresponds to 1,000GB out (people downloading from your VPS) and 2,000GB in (people uploading to your VPS). Excess data transfer is still charged the same.
No. Only traffic destined for or coming from outside of the local network (85.119.80.0/21, 2a0a:1100::/32, 2001:ba8:1f1::/48) 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.
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.
"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.
Yes. Installs that we provide are set up to use NTP to sync the clock.
A list of recommended NTP servers appears above.
You can, and you probably should. Whatever you normally use should work. iptables works fine for Linux, for example. Don't forget to firewall IPv6 as well!
We can now reduce your memory without you needing to reboot your VPS, and are able to set the memory at next boot for increases, so this question is obsolete, This entry emails only so that links do not break.
Rebooting does now run a new bootloader and will show whatever kernel entries the bootloader is aware of, so this question is obsolete. This entry emails only so that links do not break.
Please see the Open recursive nameservers article.
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.
There is no longer any supported Linux distribution which is affected by this issue, so this entry remains only for historical purposes.
/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.
Yes; the kernel in use on boot is determined by your grub configuration, so as long as you can put a correctly-configured kernel 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.
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.
Documentation for this answer has now been moved to our customer wiki.
Yes. Native IPv6 connectivity is available by default.
It is not currently possible (without some gross hacks) to run an IPv6-only VPS at BitFolk as some BitFolk services are still only available via IPv4, but it is a goal to remedy this.
Please note that your VPS will be provided with already working IPv6; those customers firewalling IPv4 will also want to firewall (or disable) IPv6.
Your network interface as initially provided will look something like this:
$ ip -6 address show dev enX0
2: enX0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2a0a:1100:1018::/128 scope global dynamic
valid_lft forever preferred_lft forever
inet6 fe80::a800:ff:fe6a:380c/64 scope link
valid_lft forever preferred_lft forever
This indicates that the customer has been assigned 2a0a:1100:1018::/48 and a single address (the first, all zeroes address) has been configured. All initial BitFolk IPv6 assignments are one /48 per VPS.
A /48 is approximately 1.2 septillion addresses between (in this example) 2a0a:1100:1018:0000:0000:0000:0000:0000 and 2a0a:1100:1018:ffff:ffff:ffff:ffff:ffff.
We now provide a standard 1GiB dedicated swap disk, so this answer is obsolete. The text below is of historical interest only.
We used to give swap as a separate device, but people kept asking for it to be bigger or smaller than we provided. In Linux, swap files in the 2.6.x kernel have identical performance to swap devices, and having one fewer block device is simpler, so we switched to providing VPSes with swap files instead.
The ext4 filesystem (which is in use by default at BitFolk) is traditionally set to require a fsck at boot time based on both elapsed time since last fsck and the number of mounts since last fsck. Since late April 2010 we have been disabling the time-based fsck for new VPS installs. Our rationale for this is as follows.
When one of BitFolk's host servers is rebooted, either for scheduled maintenance or because of some problem, most of the customer VPSes on it will not have been rebooted in a long time. With a typical check interval of 6 months, almost all of the customer VPSes will decide to do a fsck all at once on next boot. The IO load from 40-50 virtual machines all doing fsck at once is considerable.
With time-based fsck disabled, the fsck on boot will only happen if the mount count goes above the maximum. You can see the values like this:
$ sudo tune2fs -l /dev/xvda | grep -i 'check\|mount count' Mount count: 2 Maximum mount count: 34 Last checked: Sat Oct 17 09:10:33 2009 Check interval: 0 ()
(replace /dev/xvda with whatever your partitions are – see /proc/partitions)
If you weren't planning to reboot every 6 or so months anyway then the time-based fsck probably wasn't doing anything for you. You may like to consider using:
$ sudo shutdown -r -F
to do a reboot and force a filesystem check on boot, at times that are convenient to you.
Another trick is to do a fsck in read-only mode on an online, mounted filesystem:
$ sudo fsck.ext4 -fvn /dev/xvda
This will tell you if the filesystem requires a modification to fix it, without actually doing anything. You can then decide whether to reboot to do a normal fsck.
If you really don't like the idea of disabling time-based fsck then it's easy to turn it back on, and we don't mind you doing so if you feel strongly about it. Here's how:
$ sudo tune2fs -i 6m /dev/xvda
This sets the interval to 6 months. You can also use a postfix of w for weeks or d (or no postfix at all) for days.
(Mostly applicable to Ubuntu and other Debian-based distributions also.)
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.
