BitFolk Announcements

announce@mailman.bitfolk.com

265 discussions

There are currently problems with host "talisker"

by Andy Smith

Hi, We are experiencing some problems with host "talisker" and I'm currently looking into it. We are likely going to have to do an emergency reboot in a monent. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years

If running CentOS, check your grub.cfg as your VM may not boot otherwise

by Andy Smith

Hi, I held off posting this to the "announce" list because I don't understand the problem nor fully how to avoid/fix it, but another CentOS-using customer has today ended up unbootable through not getting the warning so I think I better had. Have a read of this: https://mailman.bitfolk.com/mailman/hyperkitty/list/users@mailman.bitfolk.c… Basically it seems at some point some CentOS update without notice converts your grub.cfg to use "BLS" which is a thing that's Red Hat specific and not available in upstream Grub. Since BitFolk uses upstream Grub to boot your VMs, this leaves your VM unbootable. There's info in that post on how to discover if this has been enabled, and how to disable it, but it's unclear to me: - what does it - if it can actually be reverted once it's happened So if you know more, please do let us know. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years, 5 months

BitFolk's mailing lists have migrated to Mailman 3

by Andy Smith

Hi, == TL;DR: == The BitFolk mailing lists changed address, but important stuff got copied over. You don't need to do anything. The new list archives are at: https://mailman.bitfolk.com/mailman/hyperkitty/ and if you DO want to change any of your settings the main interface is at: https://mailman.bitfolk.com/mailman/postorius/lists/ But you'll have to do a Mailman password reset before you can log in to it and change settings. You can stop reading now unless you are particularly interested in the details. == What == BitFolk's announce@ and users@ mailing lists which used to be at lists.bitfolk.com have now been migrated to <listname>@mailman.bitfolk.com, which is Mailman 3. == Why == The VM which runs lists.bitfolk.com needs to be upgraded. It runs Mailman 2, which is a strictly Python 2 application. Python 2 was EOL in 2020 sometime and is not available in newer releases of Debian, and so neither is Mailman 2. An upgrade will leave Mailman 2 non-functional. Running Mailman 3, which is a complete rewrite, is a major undertaking that I have little experience of and I'm not entirely happy about it. However, unless we either want to outsource the mailing lists to another provider or switch to something like Discourse¹, it seems to be still the best option. While it may have been possible to install Python 2 and Mailman 2 from source on an otherwise upgraded host, that is a lot of work for what seems like a dead end. == Your subscriptions == All subscribed addresses have been copied over, which is why you are seeing this email. You don't need to do anything, but if you do want to adjust your settings you'll need to do a password reset in Mailman as your passwords have not been copied over. The web interface for the lists is at: https://mailman.bitfolk.com/mailman/postorius/lists/ In the footer of messages to the "users" list it will have a link and tell you which address you are subscribed with. The "announce" list does not have a footer so if you're unsure what your subscribed address is there you'll need to look at the email headers. == Functional changes == === Headers === I'm tired of list postings being rejected or going to spam folders. We can't keep sending emails on your behalf, i.e. with a From: address that is yours, because that breaks DKIM. So over on the "users" list all posts will appear to come from: From: Your Name via BitFolk Users <users(a)mailman.bitfolk.com> Cc: Your Name <you(a)example.com> The Cc header is so that people can still contact you off-list if they want. Obviously the List-Id: headers have changed so if you're filtering email based upon those you will need to update your filters. Sorry about that. === Reply-To: added, no more "users-replyto" === We used to have a separate mailing list "users-replyto" which got all the same emails as the "users" list, but added: Reply-To: users(a)lists.bitfolk.com to them for people who preferred to explicitly have replies directed back to the list. The main "users" list is going to have an explicit Reply-To: added now, making "users-replyto" redundant. Anyone who was subscribed to "users-replyto" has been added to "users". The reason for this is that I got feedback that despite it being a long held belief that forcing Reply-To: is bad², these days most people do prefer it. I'm happy to revisit that decision if people don't like it, but the "users-replyto" hack won't be coming back. === List addresses === Obviously the list addresses have both changed from @lists.bitfolk.com to @mailman.bitfolk.com. This was necessary so that the older Mailman could continue working while the new one was set up. No doubt through muscle memory and address books the occasional email will still end up being sent to whatever(a)lists.bitfolk.com. These emails are being redirected to the correct place and I anticipate keeping that redirection in place forever. === List archives === The public archives of the "announce" and "users" lists have been imported into Mailman3's archiver, HyperKitty, at: https://mailman.bitfolk.com/mailman/hyperkitty/ I tried to port over the existing Lurker archives but I just couldn't get it to work. Lurker is mostly undocumented and hasn't seen any development since 2007. This unfortunately means that all the old archive links that are out there in previous emails and in the wiki, etc. will break if and when I turn off Lurker on the old host. I hope to be able to transplant a static copy of https://lists.bitfolk.com/lurker/ over to https://mailman.bitfolk.com/lurker/ so that old links will still work, with automatic redirection. There doesn't appear to be any way to map an individual Lurker message link to a HyperKitty link, sadly. The new HyperKitty archives are fully searchable, so if you do happen to see a Lurker link in a wiki article please do feel free to find the same message in HyperKitty and update the article. If you find it in some other place that you can't edit please do just let me know and I'll update it. The same goes for any other references to lists.bitfolk.com. == Let us know about any issues or suggestions for the lists == As I say I'm not very experienced in running Mailman 3 so it's possibly it might break or be misconfigured in some way that I haven't yet found. So if you spot anything that you think looks broken, please do let us know. Also if you have suggestions for how it might work differently or look differently, I am interested to hear and try to implement, though I cannot promise that it is possible. Certainly I am not in love with the default appearance of the HyperKitty archives or the colour scheme of Mailman 3's web interface in general, and it may be possible to improve those. Thanks, Andy ¹ Discourse: https://www.discourse.org/ ² https://marc.merlins.org/netrants/reply-to-harmful.html and its counter-argument https://marc.merlins.org/netrants/reply-to-useful.html Both of these are over 20 years old so I'm not sure how relevant they are (or that mailing lists are) for the modern Internet. It should also be noted that one of the objections to Reply-To: munging is that it can remove all information about where the author wants replies to go. In Mailman3's case, if you supply Reply-To: headers of your own then it adds them, so that objection doesn't hold. -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years, 6 months

Another reminder that Debian 11 (bullseye) and beyond WILL NOT WORK in 32-bit PV mode

by Andy Smith

Hi, TL;DR: If you're running in 32-bit PV mode you should not try to update your kernel to version 5.9 or beyond, which means not to Debian 11. Take some action first, like switching to PVH mode. Otherwise it will not boot and you'll have to boot into the older kernel again. During this week's maintenance a worrying number of customer VMs didn't boot because they were 32-bit PV and had been updated to a kernel version of 5.9 or beyond. Debian 11 (bullseye) has kernel version 5.10. It's been mentioned a number of times here over the years that support for 32-bit PV in the Linux kernel was going away at version 5.9, but it looks like we haven't been able to communicate that as well as we would have liked. The most recent attempt was here: https://lists.bitfolk.com/lurker/message/20210930.104643.2ab5f9c0.en.html If 32-bit PV is you then probably what you want to do is just switch to PVH mode as mentioned at the top of that email. Possibly the remaining people who need to see this just aren't on the announce@ list. We could email every customer who is running 32-bit PV mode, but it would probably just serve to annoy those of you who are never planning to update your kernels. Finally, although switching to PVH should allow you to continue for many years to come, nobody should be running 32-bit. We strongly advise you to be planning your switch to amd64 as soon as possible [advice since 2015]. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years, 6 months

Reboots will be necessary to address security issues, probably early hours 7/8/9 June

by Andy Smith

Hello, Unfortunately some serious security bugs have been discovered in the Xen hypervisor and fixes for these have now been pre-disclosed, with an embargo that ends at 1200Z on 9 June 2022. As a result we will need to apply these fixes and reboot everything before that time. We are likely to do this in the early hours of the morning UK time, on 7, 8 and 9 June. In the next few days individual emails will be sent out confirming to you which hour long maintenance window your services are in. The times will be in UTC; please note that UK is currently observing daylight savings and as such is currently at UTC+1. We expect the work to take between 15 and 30 minutes per bare metal host. If you have opted in to suspend and restore¹ then your VM will be suspended to storage and restored again after the host it is on is rebooted. Otherwise your VM will be cleanly shut down and booted again later. If you cannot tolerate the downtime then please contact support(a)bitfolk.com. We may be able to migrate² you to already-patched hardware before the maintenance is scheduled for your host. You can expect a few tens of seconds of pausing in that case. This process uses suspend&restore so has the same caveats. Cheers, Andy ¹ https://tools.bitfolk.com/wiki/Suspend_and_restore ² https://tools.bitfolk.com/wiki/Suspend_and_restore#Migration -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years, 6 months

DNS secondary zone serial consistency check is now enabled

by Andy Smith

Hi, As requested this check is now enabled for all customer DNS zones in the secondary DNS service. The alert will look like this: https://tools.bitfolk.com/wiki/Secondary_DNS_service#Zone_serials_match If you receive it then the first thing to do is to check your nameserver's logs as it will normally be due to an issue that (only) you can fix yourself. Cheers, Andy ----- Forwarded message from Mike Zanker via users <users(a)lists.bitfolk.com> ----- […] >> Maybe we should add some serial number monitoring, so if your zone >> serial number changes but ours doesn't (because AXFR failed) then >> that difference would be an alert. I do like the sound of that, Andy (Smith). ----- End forwarded message ----- -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years, 7 months

Ubuntu 22.04 (Jammy Jellyfish) now available for new installs and self-installs

by Andy Smith

Hi, Ubuntu 22.04 (Jammy Jellyfish) is now available for new installs and self-installs using our Xen Shell: https://tools.bitfolk.com/wiki/Using_the_self-serve_net_installer In a change to previous releases, Ubuntu has switched away from the Debian installer and recommends that the official Ubuntu Cloud Image is used for installs on public clouds. So, when you kick off an install of Ubuntu 22.04 it will: - ask you for your chosen hostname and password - overwrite your disk with the image for Ubuntu 22.04 - boot it and customise it automatically using the hostname and password you provided and information held in your BitFolk account. For more information please see the article about Ubuntu at BitFolk: https://tools.bitfolk.com/wiki/Ubuntu#22.04_.28Jammy_Jellyfish.29_and_beyond Upgrades from 20.04 to 22.04 can be done as usual using "do-release-upgrade", although do note that it's normal Ubuntu policy to not offer an upgrade until the first point release of the LTS, so at the moment you would need to force that with "do-release-upgrade -d". We are not aware of any particular issues with upgrading to or installing Ubuntu 22.04 at BitFolk. As always you should read Ubuntu's own release notes for general things to be aware of. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years, 7 months

A reminder that CentOS 8 is now EOL and they are not kidding about that

by Andy Smith

Hi, For those using CentOS 8, a reminder that it went EOL on 31 December 2021 and as of 31 January 2022 they removed all the public mirrors as well, so you can't get updates or install anything any more. This apparently took a number of projects by surprise… including some Red Hat ones! https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/Y4HU5BQHZNGVLXLUUA… If you are using CentOS 8 I think we would recommend that you switch it to CentOS Stream 8 at least in the short term, because that is the only way you get security updates. I understand that there is a simple script to do this without reinstall and at least 1 BitFolk customer has done it. In terms of BitFolk supporting CentOS Stream 9, we're waiting for ELRepo to gain an EL9 kernel-ml package, then that should be viable. I asked you all about your plans post-CentOS 8 and didn't get a huge response. Some interest was expressed in Rocky Linux and Oracle Linux. So, those will likely be available soon. A customer also put together instructions for installing OpenSUSE Leap, which I have run through and seems to work fine: https://tools.bitfolk.com/wiki/User:Moggers87/Installing_Opensuse Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years, 10 months

Remaining 32-bit PV guests will be switched to pvshim on Tuesday 18 January

by Andy Smith

Hi, TL;DR: The ~30% of you still running 32-bit PV guests are going to have your config changed in a month. We've tested that on many different configurations and haven't had a problem yet but it's always possible something could go wrong, and if so you'll only find out at the next boot. If affected we recommend you instead make the change yourself at a time convenient to you. This email is only relevant to you if you're still running in 32-bit PV mode. Most customers run 64-bit. If you type "uname -m" in your VM then it will say "amd64" for 64-bit and "i686" for 32-bit. It also says it on the summary page of: https://panel.bitfolk.com/account/ You can stop reading if you're already running as 64-bit, or in PVH mode. We haven't got a simple way to check if you are PVH mode because the intention is that eventually will be a detail you don't have to care about (all VMs will be PVH and that has been the default for over a year now). You can for now log in to the Xen Shell and type "virtmode" and it will tell you. So if that says "PVH" you can also stop reading. For several years now we have been trying to encourage customers running 32-bit PV mode guests to switch to 64-bit and / or PVH mode. There are many reasons for this but the most pressing one is that it's not possible to fully protect 32-bit PV guests against the various already known speculation attacks (nor probably new ones that will be discovered). About 30% of the customer base still runs 32-bit PV mode guests even though the default has been 64-bit since about 2012. We are clearly not going to be able to force everyone to switch in a timely manner so we have been testing a different way of running legacy 32-bit PV mode guests. That testing has gone well - there haven't been any issues - so we're going to convert all remaining 32-bit PV mode guests to that configuration on Tuesday 18 January 2022. Since it's not possible to test every permutation of installed guest though, we can't rule out there being a problem, and that problem will only manifest at your next boot. If you'd like to make the config change ahead of time here is how: 1. Log in to your Xen Shell. More info: https://tools.bitfolk.com/wiki/Xen_Shell 2. Make sure the version in the "help" command is at least this: xen-shell> help xen-shell v1.48bitfolk66 The Xen Shell stays running after you disconnect so it is possible to be running an older version. If it is older, "exit" out of every window until it logs you out, then log in again. 3. Use the "arch" and "virtmode" commands to confirm that you are currently running in 32-bit PV mode: xen-shell> arch Your current install architecture is: i686 xen-shell> virtmode Your current virtualisation mode is: PV 4. Use the "arch i686" command to force a switch to i686 (32-bit) architecture again. This will update your config to use pvshim. 5. Use the "shutdown" command to shut your guest down. 6. Use the "boot" command to boot it again. It should boot pretty much the same as before. If it does not, then you will likely not be able to get it to boot again yourself and will need to put in a support ticket. This change will be made for all remaining 32-bit PV mode guests on Tuesday 18 January, without further testing, as that would involve forcible reboot. If you do want to take some action about this here are some things you could do, in order of best choices to worst choices: a) Ask for a new "migration VPS" which would be an empty account that you can do a new install into (which would be 64-bit PVH as that's the default): https://tools.bitfolk.com/wiki/Migrating_to_a_new_VPS b) Upgrade your kernel past 4.19.0 and make sure you're running grub-pc (not legacy Grub) as bootloader, with a /boot/grub/grub.cfg file, then switch to PVH mode. c) If running at least Debian 7 (wheezy) or comparable age Ubuntu you can install an amd64 (64-bit) kernel even while everything else is 32-bit. That turns your VM into a 64-bit PV guest. Follow these CrossGrading instructions only as far as installing and booting into the new kernel: https://wiki.debian.org/CrossGrading d) Do nothing and let us switch you to using pvshim. Your guest is still insecure and running with reduced performance compared to 64-bit but this only then affects you. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years, 11 months

Automated card payments now available

by Andy Smith

Hello, There is now support for saving payment card details for future automated charging. To save card details please see: https://panel.bitfolk.com/account/billing/ If you already have automated payments set up through Direct Debit or PayPal and want to switch to card payment, you will need to cancel that arrangement first, which you can also do from the above page. We have accepted one-off card payments through Stripe since October 2013, and it has been a regular request to enable the saving of card details so that they don't have to be input each time there is an invoice. This has finally now been done. This is a minimally working implementation. I expect once it sees greater use there will be some suggestions for improvement. Please make these on our feature tracker at: https://tools.bitfolk.com/redmine/issues/202 One-off card payments will remain available for those who prefer to pay that way. More about supported payment methods: https://tools.bitfolk.com/wiki/Payment_methods Thanks, Andy BitFolk Ltd -- https://bitfolk.com/ -- No-nonsense VPS hosting

2 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

BitFolk Announcements