BitFolk Users

users@mailman.bitfolk.com

1117 discussions

Re: [bitfolk] routing problems, or is it me?

by Samuel Bächler

Dear All Below you will find the output of my playing around - using my mobile phone with EE sim card (EE mobile) to access the internet. $ tracert bitfolk.com Routenverfolgung zu bitfolk.com [85.119.80.223] ▒ber maximal 30 Abschnitte: 1 <1 ms <1 ms <1 ms 192.168.42.129 2 * * * Zeit▒berschreitung der Anforderung. 3 50 ms 49 ms 49 ms 10.248.28.225 4 1220 ms 409 ms 479 ms 10.247.86.25 5 52 ms 50 ms 48 ms 10.247.86.6 6 946 ms 459 ms 469 ms 10.247.86.9 7 54 ms 50 ms 51 ms 10.247.86.18 8 1101 ms 1429 ms 47 ms 87.237.20.232 9 1900 ms 539 ms 499 ms 87.237.20.81 10 2173 ms 376 ms 431 ms 80.150.171.93 11 160 ms 155 ms 149 ms 80.150.170.106 12 149 ms 150 ms 155 ms ae-1.r00.londen10.uk.bb.gin.ntt.net [129.250.3.31] 13 * * * Zeit▒berschreitung der Anforderung. 14 411 ms 631 ms 1155 ms jack.bitfolk.com [85.119.80.20] 15 59 ms 59 ms 59 ms bitfolk.com [85.119.80.223] Ablaufverfolgung beendet. And $ tracert boeser.ch Routenverfolgung zu boeser.ch [85.119.84.22] ▒ber maximal 30 Abschnitte: 1 <1 ms <1 ms <1 ms 192.168.42.129 2 * * * Zeit▒berschreitung der Anforderung. 3 54 ms 61 ms 56 ms 10.248.28.233 4 58 ms 61 ms 57 ms 10.247.86.27 5 48 ms 49 ms 99 ms 10.247.86.6 6 1656 ms 58 ms 49 ms 10.247.86.9 7 1037 ms 1008 ms 467 ms 10.247.86.18 8 102 ms 49 ms 49 ms 87.237.20.232 9 1078 ms 499 ms 1227 ms 87.237.20.81 10 59 ms 71 ms 85 ms 80.157.131.33 11 147 ms 163 ms 149 ms 80.150.170.106 12 153 ms 155 ms 151 ms ae-1.r00.londen10.uk.bb.gin.ntt.net [129.250.3.31] 13 * * * Zeit▒berschreitung der Anforderung. 14 963 ms 806 ms 59 ms macallan.bitfolk.com [85.119.80.25] 15 * * * Zeit▒berschreitung der Anforderung. 16 * * * Zeit▒berschreitung der Anforderung. 17 * * * Zeit▒berschreitung der Anforderung. 18 * * * Zeit▒berschreitung der Anforderung. 19 * * * Zeit▒berschreitung der Anforderung. 20 * * * Zeit▒berschreitung der Anforderung. 21 * * * Zeit▒berschreitung der Anforderung. 22 * * * Zeit▒berschreitung der Anforderung. 23 * * * Zeit▒berschreitung der Anforderung. 24 * * * Zeit▒berschreitung der Anforderung. 25 * * * Zeit▒berschreitung der Anforderung. 26 * * * Zeit▒berschreitung der Anforderung. 27 * * * Zeit▒berschreitung der Anforderung. 28 * * * Zeit▒berschreitung der Anforderung. 29 * * * Zeit▒berschreitung der Anforderung. 30 * * * Zeit▒berschreitung der Anforderung. Ablaufverfolgung beendet. Regards, Sam

8 years, 8 months

Ubuntu 16.04 LTS (Xenial Xerus) installer now available

by Andy Smith

Hi, I've now added support for installing Ubuntu 16.04 to the Xen Shell. Your instance of the Xen Shell will need to be version 1.48bitfolk36. If you have an old copy hanging around, log out of it completely and SSH to it again. I would not recommend attempting to use ZFS unless you have a lot more than the default 1GiB memory (and then you'll still need a separate ext4 /boot). Here's an Asciinema of me installing a 64-bit encrypted storage version of it in real time. I skipped the swap device for speed but you may not necessarily want to do that. https://asciinema.org/a/8n7onshwzaziqhz7ewqmxcbcv Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

8 years, 8 months

ekey-egd-linux messages

by Andy Smith

Hi, Between about 06:46 and 07:09 UTC today I was doing some work to move the entropy service behind a VRRP IP and so users of it will have seen some messages like: ekey-egd-linux: Reconnecting to EGD server in their logs. As long as they do not continue in past 07:09 there is nothing to be concerned about. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

8 years, 8 months

Planned maintenance for snaps.bitfolk.com on Saturday 16th April, ~30 mins between 12:00Z and 16:00Z

by Andy Smith

Hi, If your VPS lives on snaps.bitfolk.com then you should have by now received direct email notifying you of planned maintenance on this server on Saturday 16th April. If you don't know what host your VPS is on, please see: https://panel.bitfolk.com/account/ which lists it. If it's on snaps.bitfolk.com and you haven't received the notification you should check your spam folders etc. If your VPS is not on snaps.bitfolk.com then you will be unaffected and should not notice any disruption. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

8 years, 8 months

Base data transfer quota increased to 1TB

by Andy Smith

Hi, Effective immediately the monthly data transfer quota has been increased to 1,000GB. For those of you on 95th percentile it's been increased to 2Mbps. Those of you that pay for additional monthly data transfer may not now need to do so. If that is the case please contact support(a)bitfolk.com about dropping back down to the new default. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

8 years, 8 months

Hardware upgrades complete, on to other improvements

by Andy Smith

Hello, I'm pleased to say that the hardware upgrades were completed on 1st April 2016. That means every single BitFolk customer was moved from an older piece of hardware to a new one, and in the process gained some extra memory and an extra virtual CPU core. The swap provision was standardised to a 1GiB xvdb device with a single swap partition on it. If you previously had a smaller swap device (480M customers had 480M swap) or no swap device at all (older accounts had a swap *file* on their root filesystem) then you may wish to check if there is some extra swap space you could be using: https://tools.bitfolk.com/wiki/Hardware_refresh,_2015-2016#Making_use_of_th… The higher specs of the new hardware allowed the total server count to reduce to 64% of what it was. Also, more importantly, the power usage is now at approximately 24% of what it was before. This should result in a big saving in hosting fees which are entirely scaled by power consumption, and represent BitFolk's biggest outgoing. I will be taking a couple of months to see how things balance out financially and to allow for some other developments out of my control¹, but then I will be seeing if I can reduce prices a little and/or introduce a cheaper 512M memory VPS package. I am now able to focus on some other areas that need attention. Those of you who have experienced refused connections to the apt-cacher² will be pleased to know that this has now been put behind a high availability proxy so those should be a thing of the past. Additionally I have moved the spamd³ service behind there and will soon do the same with the entropy⁴ service. These services had previously either not been redundant at all (apt-cacher) or had merely been multiple hosts behind one proxy (spamd, entropy) thus having the proxy as a single point of failure. I've put some work into deploying a new pair of proxies with a VRRP floating IP (and IPv6) so these services should also now withstand the loss of one of the proxies. As a side benefit that now means that we could sell you a floating IP service, where you could run a command (or, more realistically, have keepalived or some other monitoring software run a command) to float an IPv4 and an IPv6 /64 between two or more of your VPSes. Let me know if you would be interested in that. Other areas I know are desperately in need of attention: - Need to look into moving to pvgrub as a booting method. Current use of pygrub really mandates GRUB 1.x-style /boot/grub/menu.lst while most distributions are moving to GRUB 2.x /boot/grub/grub.cfg. The lengths we need to go to in order to force support of older GRUB are getting to be too much, but I would rather skip over pygrub enhancements that support GRUB 2.x and move straight to pvgrub. For those unaware of the difference, pygrub is a Python script that runs as root in BitFolk's host machines in order to parse boot instructions from your block devices. This has security implications as you can probably imagine. pvgrub on the other hand is a Xen-compatible build of the actual GRUB that is booted as a virtual machine as you, and then that tries to boot. This is much safer, and much more reliable since it actually *is* the real GRUB bootloader rather than a script that tries to mimim its behaviour. - Need to modernise Nagios monitoring. BitFolk's Nagios is now really too long in the tooth, is starting to have problems doing modern TLS connections for example. I am looking at replacing it with Icinga, and also hope for slightly more customer control over what is monitored (i.e. giving you access to some form of interface that can make changes, instead of requesting all changes by support ticket). Initially it just has to work though, because I rely on it for my own monitoring. - Support for European bank accounts in GoCardless (Direct Debit). I know there are few customers with Euro bank accounts who are grudgingly using PayPal subscription only because BitFolk's GoCardless integration doesn't yet support them, event hough GoCardless itself does. - Support for recurring payments with Stripe (credit/debit cards). BitFolk payments through Stripe are currently only possible as one-off payments and I know there are some who would prefer to have Stripe store their card details and let BitFolk just take a regular scheduled payment. - Everything else that is in https://tools.bitfolk.com/tracker/ :) There's far more things to work on than there is time to do it in, but there should be some progress at least. Thanks for your patience! Comments and insight on future direction are welcome. Cheers, Andy ¹ Our colo provider is soon going to be changing their method of power monitoring and will likely put prices up at the same time ² https://tools.bitfolk.com/wiki/Apt-cacher ³ https://bitfolk.com/customer_information.html#toc_2_SpamAssassin ⁴ https://tools.bitfolk.com/wiki/Entropy#BitFolk.27s_entropy_service -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

8 years, 8 months

Routing issues anyone?

by Tony Andersson

Hi you clever people, Is there anyone else experiencing any routing issues at the moment? Two of my sites have been very hard to reach during the evening (or possibly longer, haven't checked earlier) 22:20:21$ ping 85.119.83.157 PING 85.119.83.157 (85.119.83.157) 56(84) bytes of data. From jack.bitfolk.com (85.119.80.20) icmp_seq=1 Destination Host Unreachable C:\Users\Tony>ping 85.119.83.157 Pinging 85.119.83.157 with 32 bytes of data: Reply from 85.119.83.157: bytes=32 time=420ms TTL=59 Reply from 85.119.80.20: Destination host unreachable. 22:47:10$ ping 85.119.83.157 PING 85.119.83.157 (85.119.83.157) 56(84) bytes of data. 64 bytes from 85.119.83.157: icmp_seq=1 ttl=62 time=0.180 ms (and so on) 22:54:44$ ping 85.119.83.157 PING 85.119.83.157 (85.119.83.157) 56(84) bytes of data. From 85.119.80.20 icmp_seq=1 Destination Host Unreachable No changes to any routing tables or some such has happened, and the two machines I am trying with are in two completely different locations. Linux machine is in the Bitfolk network, just like the intermittently unreachable machine. Another IP, 188.40.132.132, is unreachable tonight too. Seems like a bit of too much a coincidence for this to happen at the same time, so I thought I'd better ask the vast expertise here if it's just me. Probably is! :-P Cheers, __ /ony

8 years, 9 months

We will be charging for additional IPv4 addresses on a recurring basis from Monday 14th March 2016

by Andy Smith

Hi, If you just have the one IPv4 address on your VPS then you can safely stop reading as nothing is going to change for you. As for the 11% of paying customers who do have more than one IPv4 address, read on… For a long time now I have been unsatisfied with our policies for granting requests for additional IPv4 addresses. For the last 9 years we've done what was considered the proper thing in a world where available IPv4 addresses were running low: we haven't charged for additional IPv4 addresses, we've only asked customers to technically justify their requests. That had a number of problems: - It's often very difficult to pin a customer down on what exactly it is they're doing. The ideal scenario where one network engineer talks to another about requirements is rarely the case here. This very often left me in a position where I wasn't convinced that use of extra IPv4 addresses was technically required, but it's what the customer wanted and the sale depended upon it. There is no sane administrative fee that could be charged that would cover that amount of work. - Once a request was granted it has been very difficult to audit. There has been no incentive for customers to return IPv4 addresses that they are no longer using. - I don't know of another company in this same space that is bothering to require technical justification for IPv4 use. - We're no longer in a world where IPv4 is running out. IPv4 has already run out. The point of recording why any given IPv4 address was in use was for the case where BitFolk had to go back to RIPE to ask for more IPv4. Those records would have been used to prove that the IPv4 allocation that BitFolk already has really is all used up. BitFolk won't be going back to RIPE because there's no IPv4 left to go back for. We just have to manage what we have. So, from Monday 14th March we're going to start charging for each IPv4 address after the first one. The charge will be £0.50+VAT per IPv4 per month (£1.40+VAT per quarter or £5.00+VAT per year). This will take effect immediately for new signups, but existing customers will only see it on invoices falling due on or after 14th March. Those with PayPal subscriptions will have the subscriptions altered, and those with Direct Debit authorisation will see the authorisation cancelled (they're for a fixed amount) so will need to re-authorise. If you're paying monthly or quarterly and your next bill falls due some time between now and March 14th you could consider switching to yearly, as you then won't be charged for this until that year runs out. You'd therefore save £6.00+VAT per IPv4 per year (£0.50 x 12 monthly payments). I should point out that (under either this or the previous regime) BitFolk is not in any realistic danger of running out of IPv4 addresses; this is just about managing what we already have in a better, fairer and more transparent way which is also more in line with customer expectations. IPv6 /64s and /56s remain entirely free and there are no plans to change that. If there is something I have forgotten to cover, please do let us know, either by replying here to to support(a)bitfolk.com. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting "It is I, Simon Quinlank. The chief conductor on the bus that is called hobby." — Simon Quinlank _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

8 years, 9 months

CoreOS at BitFolk

by Andy Smith

Hi, For those completely committing to containers, I thought I'd just point out that CoreOS appears to work fine at BitFolk. Here's some instructions based on a successful test of mine: https://tools.bitfolk.com/wiki/Installing_CoreOS If you go further with it then please feel free to edit. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

8 years, 10 months

Tor exit node policy updated

by Andy Smith

Hi, If you do not operate a Tor exit node at BitFolk then this email will be of little interest to you. If you do, then read on… A number of BitFolk customers operate Tor exit nodes. These generate a constant stream of abuse reports because quite a lot of abusive activity is conducted through Tor. Most of the reports are automated and are informational in nature. They expect no reply and are therefore ignored on the basis that "it's a Tor exit node ¯\_(ツ)_/¯". A minority are real people and in this case BitFolk points out that the host is a Tor exit node and so neither BitFolk nor BitFolk's customer has much control of the traffic that goes through it. A minority of this minority of complainants are for one reason or another not satisfied with that answer and in those rare cases we expect the customer to correspond with the complainant. A recent case was like this and has prompted some updates to our Tor exit node policy. The updated policy can be found here: https://tools.bitfolk.com/wiki/Running_a_Tor_node The changes: https://tools.bitfolk.com/w/index.php?title=Running_a_Tor_node&action=histo… Briefly: - We state clearly that you must use a dedicated IP for your Tor node. Previously we've insisted customers use a dedicated IP from the first time an abuse report came in, so this is just formalising that. - The correct Tor exit IP must appear in the Tor project list of exit nodes, for the benefit of remote sites that are using those lists to construct filters. One reason why this recent abuse report escalated was because the customer's exit node was misconfigured to list the VPS's *other* IP address, so the complainant was seeing abusive activity (Wordpress brute force in this case) coming from something that wasn't listed as a Tor node. - Clarify that when we ask for a response to an abuse report we expect it within 72 hours. - Warn that although we prefer correspondence with the complainant to go through our ticket tracker, if the complainant insists then you must give them a direct email address that reaches you. I know that sucks, but it is unfortunately the price that must be paid for running an abuse magnet like a Tor node: the abuse reports *must* be answered. In 8 years of having Tor exit nodes at BitFolk this is the first time that a complainant has insisted upon corresponding directly with the node operator. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

8 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

BitFolk Users