BitFolk Users

users@mailman.bitfolk.com

1117 discussions

Ready now for volunteers to test new /48 assignments

by Andy Smith

Hi, I think we're ready now for people to try out the new IPv6 /48 assignments so if there's any of you that have a little time to play around with that please contact me off-list. I expect everything¹ to work. You won't need to reboot. The /48 you are assigned will not change later on. Your legacy IPv6 assignments will not be affected. Everyone else will get their /48s assigned and routed to them after a short period of these volunteers trying theirs out. Thanks, Andy ¹ I have not yet been through all of BitFolk's firewall rules so there will be some services that are meant for only customers that will be unreachable from these IP blocks until I get around to that. We also need to update all of the IPv6 documentation on the wiki as it is now out of date. -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 months, 2 weeks

Quick question about IPv6 assignments

by Andy Smith

Hi, Very nearly ready to start assigning /48s from the BitFolk net block. At present each VM has a /64 of the form: 2001:ba8:1f1:fxxx::/64 We are going to start assigning /48s to customers from 2a0a:1100:1000::/48 onwards. That means that the first one is 2a0a:1100:1000::/48 and then the next is 2a0a:1100:1001::/48 and they continue to increment like 2a0a:1100:1002::/48 2a0a:1100:1003::/48 2a0a:1100:1004::/48 and so on. My question is, do you feel there is any value whatsoever in matching the customer-specific part of an existing customer's /64 assignment with their new /48 assignment? For example, if you currently had 2001:ba8:1f1:f1d7::/64 then you could ALSO have 2a0a:1100:11d7::/48. Or, we could just assign them incrementally from the bottom up if it's felt there is no value in that. Personally I kind of feel like there isn't really any value here. By the time we have explained how you mentally map from one to the other I think you could have just looked at https://panel.bitfolk.com/dns/ and seen what your new /48 is. I'm not even convinced that there are very many people who remember the last part of their current /64 off by heart anyway. But it was put to me by a non-customer that we "should" do this, so I thought I would ask! If there's even one person that would like that then I guess we can do it. Either way, new customers would just get the first available from the bottom. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 months, 2 weeks

Help with testing some IPv6 stuff

by Andy Smith

Hi, If there's any of you who are actively using an IPv6 /56 that we've routed to you, and you don't overly mind rebooting your VM to test something (maybe a couple of times) could you get in touch off-list please? Our records say there's only 19 of you so it's a bit of a long shot. I'd rather not try this with someone who doesn't normally make use of a /56 as you may not immediately spot the difference between working and not. Also I've already tested as many setups as I can think of so I'd only be suggesting things I already tested! I can add a little bit of free service for the inconvenience. (Trying to set reply-to on this but Mailman will probably override it so be careful not to reply on-list if that wasn't your intention.) Thanks! Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 months, 2 weeks

Phishing emails

by Andy Smith

Hi, I do hope that none of you would be taken in by this sort of thing but just to warn you there have been a few phishing emails directed at various BitFolk addresses pretending to be from us, for example this one today which was directed at the "users" mailing list (and was caught by spam filters): https://ibb.co/MZh7p7K All emails that come from BitFolk should have SPF, DKIM and DMARC. If you notice any that don't then please let us know. And of course, we wouldn't send out emails asking for passwords. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 months, 3 weeks

Hardware refresh and rolling migrations starting soon

by Andy Smith

Hi, ## TL;DR: Migrations between servers coming in the near future for the purposes of a hardware refresh, with an upgrade to VM specs, a bit like in 2015–2016. ## Hardware refresh In the coming weeks we hope to get started with a long overdue hardware refresh. This will include some sort of upgrade to the base VM specification, the exact details of which haven't yet been decided. The last time we did this was in 2015–2016 and I expect things to go in much the same way, although slightly less complex as we also did some changes to VM disk layout that time. Here's more info on how that went: https://tools.bitfolk.com/wiki/Hardware_refresh,_2015-2016 Three of the existing servers have some life left in them but they do not currently have 25GE network interfaces, so it's going to be a priority to clear customers off of those first so they can be taken out of service for that to happen. Those servers are "elephant", "limoncello" and "talisker". I anticipate sending a direct email to the main tech contact for each VM on the candidate server asking if they would like to have their VM migrated to new hardware and get the upgraded specs at the same time. Past experience has shown that the majority of people won't be interested in the upgrade and would rather not have to do anything, so this communication is going to have to say something like, "if we don't hear back from you to schedule this within 15 days, we will schedule it ourselves for a date no sooner than 30 days from now". Since eventually all servers do require at least an OS upgrade even if they are not being decommissioned, it is I am afraid inevitable that all customer services will have to be migrated between servers. This is going to take many months. We will try to be as flexible as possible with people who need that. For those who have never experienced their VM being migrated between servers, it is not a big deal. We shut it down and boot it a few seconds later on its new server. At your option¹ we can also do a live migration which works most of the time² and results in no actual shutdown. Nothing about the VM changes, except that its specs will be upgraded. ## IPv6 changes We also need to change how we do IPv6 and there's no reason why we can't start doing that at the same time so unless things are getting overwhelming you might see something soon about that also. Basically we need to start assigning customer VMs IPv6 address space out of BitFolk's 2a0a:1100::/29 rather than the /48 of Jump's that we've been using since 2005. I expect to be reserving a /48 for each VM but as the majority of people use either zero or one IPv6 address, only one IPv6 address from the new assignment will initially be routed to your VM. For those wanting more we will add a feature to the Panel and/or Xen Shell to expand the routing to a /64 or the full /48 (and maybe something in between there also). The goal is for that to not require a support ticket. This sort of thing is desirable to prevent neighbour table exhaustion attacks, where someone cycles through many addresses in a /64 (or larger). I do not expect to take away the legacy assignments from out of the 2001:ba8:1f1::/48 provided by Jump from existing VMs, but after we begin rolling this out new VPS orders and new self-installs will not have the legacy IPv6 space. At some point in the fairly distant future a retirement date will be announce for that range. ## Feedback? So that's what's coming up. If you have any feedback or questions we're keen to hear them. There is no need to volunteer now to be first for upgrades or anything as you will be contacted and that will be your chance to do that! Thanks, Andy ¹ https://panel.bitfolk.com/account/config/#prefs ² There have been some rare problems with this in the past which resulted in disk corruption but in the case of migration between servers we do always have a copy of your disk on the source server, so it's pretty safe. All of BitFolk's own VMs live migrate. -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 months, 3 weeks

2024-05-23 ~20:25Z – ~20:50Z: Networking issue on host "jack"

by Andy Smith

Hi, Between about 20:25Z and ~20:50Z today host "Jack" lost all networking. All of the VMs on it became unreachable. It seems to have been some sort of kernel driver bug in the Ethernet module as it was "stuck" not passing traffic but the interface still showed as up. The hosts have bonded network interfaces to protect against switch failure, but as the interface stayed up this was not considered failed. Also they are in active-backup mode and the currently-active interface was the one that was stuck, so all traffic was trying to go that way. Networking was restored by setting the link down and up again. Traffic started to flow again, BGP sessions re-established and all was fine again. We could look into some sort of link keepalive method on the bonded interfaces as opposed to just relying on link state, but we have already decided to move away from bonded networking in favour of separate BGP sessions on each interface, That is how the next new servers will be deployed; they will not have network bonding. We have not yet tackled moving existing servers to this setup. If we had been in the situation without bonding I think we would have fared better here: there would have been a short blip while one BGP session went down, but the other would remain and we'd be left with some alerting and me scratching my head wondering why an interface that is up doesn't pass traffic. I will do some more investigation of this failure mode but in light of doing away with bonding being the direction we are already going, I don't think I want to alter how bonding is done on what will soon be a legacy setup. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 months, 4 weeks

No more 32-bit x86 kernels in Debian

by Andy Smith

Hi, This should have limited effect on anyone here as if you are still running 32-bit Debian it is long out of support so you won't be getting upgrades anyway. No more 32-bit x86 kernels in Debian: https://lists.debian.org/debian-kernel/2024/09/msg00138.html What it does mean is that there are even fewer people who are going to find and fix any bug in 32-bit x86 Linux. In practical terms for Debian it means that the next release, Debian 13 (trixie) will be the first one to not have an i686 kernel or installer, but as I say, for BitFolk purposes amd64 has been required since Debian 11. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

3 months

Freexian ELTS repository added to apt-cacher

by Andy Smith

Hi, I've enabled deb.freexian.com on our apt-cacher. This is used for the Freexian Extended LTS project which provides security backports for selected Debian packages currently back as far as Debian 8 (jessie). This is a public repository, so nothing really special here, but you are supposed to cache or mirror it yourself so now we do that for you. More info: https://www.freexian.com/lts/extended/docs/how-to-use-extended-lts/ https://tools.bitfolk.com/wiki/Apt-cacher Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

3 months, 3 weeks

Installer now available for Ubuntu 24.04 (Noble Numbat)

by Andy Smith

Hi, Self-install of Ubuntu 24.04 (Noble Numbat) is now available from the Xen Shell. Thanks for your patience on this; I'm sorry it's taken so long. More info: https://tools.bitfolk.com/wiki/Using_the_self-serve_net_installer https://tools.bitfolk.com/wiki/Xen_Shell It remains possible of course to upgrade in place from Ubuntu 22.04 with the "do-release-upgrade" command. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

3 months, 4 weeks

BitFolk now listed in the JSfree.org directory of all things that work without JavaScript :-D

by James R. Haigh (+BitFolk subaddress)

Hey all, Good news for BitFolk here -- I have submitted 7 additions to the new JSfree directory in the past few days, and... today, Brad there has accepted and added 5 of them into his directory -- including BitFolk! :-D My other suggestions that have been added are W3M, Lynx, Links, and Wttr.in . :-D As of yet, the Viewable With Any Browser Campaign (which now links to JSfree.org since I suggested it to Cari there earlier this month) and Andrews & Arnold (which works without JavaScript except for its ordering pages, which can be bypassed by email or phone) have not yet been added but also not been rejected or commented on either by Brad, so we'll have to wait and see what happens. :-/ Brad also announced to me today JSfree's new mailing list over at SourceHut! :-D So if you are interested in the JSfree directory, you may like to join us over at: https://lists.sr.ht/~bt/jsfree-devel I think that this is great news! :-D Kind regards, James R. Haigh. -- Wealth doesn't bring happiness, but poverty brings sadness. Sent from Debian with Claws Mail, using email subaddressing as an alternative to error-prone heuristical spam filtering. POTS/SMS: tel:+447402916784 (UK 07402916784) VoIP: sip:+447402916784@voiceless.AA.net.uk Instant messaging (XMPP/Jabber): (currently broken) Postal: James R. Haigh, Middle Farm, Vennington, nr. Westbury, nr. Shrewsbury, Salop, SY5 9RG, Britain

4 months, 1 week

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

BitFolk Users