Hi,
Debian 10.0 (buster) was released on Sunday. You can now use the
self-installer to install it. From the Xen Shell type:
xen shell> install debian_buster
If this is not your first install you may wish to check that your
architecture is set to x86_64 (64-bit). If it's 32-bit then you can
change it with:
xen shell> arch x86_64
I recommend that you do switch to 64-bit if you haven't already.
The new Debian testing (bullseye) is also present but is still a
work in progress. We'd still be interested in hearing about any
problems with it.
More info:
https://tools.bitfolk.com/wiki/Using_the_self-serve_net_installerhttps://tools.bitfolk.com/wiki/Xen_Shell
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hello,
Debian 10 (buster) is supposed to be released later today. Those who
wish to upgrade to it in the usual Debian way should be able to do
so after reading the release notes for any gotchas:
https://www.debian.org/releases/testing/amd64/release-notes/
I am not aware of any gotchas that are specific to the BitFolk
environment, but if you think you have found one please do let us
know.
If planning a clean install, the "buster" release has been available
for some time in our Xen Shell, but under the code name
"debian_testing", because right now it still is technically the
testing release.
If you issue the command:
xen shell> install debian_testing
now or at any time after the release of Debian 10 then I believe
this should result in a working install of Debian 10. I just tested
it with a minimal install (base system + openssh) and it seems to
(still) work.
It may be several days after the release before we can get around to
updating the labels in the Xen Shell so that "debian_buster" is there
and "debian_testing" gets you "bullseye". It does tell you what it's
going to install so there should be no confusion.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
Today there were some periods of intermittent packet loss on both
IPv4 and IPv6 between 21:04Z and 21:23Z. For IPv6 it was more severe
(not all customers, but if you were affected it was 100% loss)
between 21:04Z and 21:13Z. Then there was a further period of
intermittent IPv4 packet loss between 21:19Z and 21:22Z.
This happened during some scheduled network reconfiguration on the
part of our colo provider. It was intended to be
non-service-impacting, but unfortunately multiple different problems
were encountered.
I took no part in what was going on (it was solely on their
equipment) but I made sure I was online so that if there were any
problems I could spot them and help diagnose them promptly. That
helped things get resolved faster.
The problems encountered were unanticipated and the colo provider
apologises for the disruption, but I should also apologise because I
admit I did not ask for a detailed plan of what exactly they were
doing as beyond looking out for problems I had no involvement.
Had I asked for a detailed plan, in hindsight I think I'd have
decided it was pretty complicated and would have announced an
"at-risk" window. The problems would still have happened, because as
I say they were unanticipated, but at least you'd have been able to
connect what you were seeing with the maintenance window.
If you care for the details of exactly what went wrong let me know
and I'll send them to you but they seem like a bit too much detail
for this email.
The initial work was completed at 21:22:48Z, and a second bit of
work was carried out without incident at around 22:00Z. No more work
is planned so no more problems are expected.
Apologies again for the disruption.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hello,
Unfortunately some security flaws have been discovered in the hypervisor
software we use (Xen) so we will need to patch and reboot everything
before the public release of the details on 5 March.
We will do this work in the early hours of the morning (UK time) between
Saturday 2 March and Monday 4 March. You should already have received an
individual email confirming the hour-long maintenance window specific to
your server(s). The actual work for each server is expected to take
10–30 minutes within that window.
As before we should be able to do a suspend/restore of your guest if you
have enabled that at:
<https://panel.bitfolk.com/account/config/>
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
Every VPS now includes 2GiB of backup space for use with our local
backups service, for free. More info on the local backups service:
https://tools.bitfolk.com/wiki/Backups
You still need to let us know what to back up before any backups
will take place, so if you are not currently a user of the backups
service and wish to enable it please follow the procedure here:
https://tools.bitfolk.com/wiki/Backups#Setup
If you are already a user of the backups service then 2GiB has
simply been added to your quota.
There is now no excuse for important configs and data to not be
backed up. ☺
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
A Billing role has now been added to the address book in the Panel:
https://panel.bitfolk.com/account/contacts/#toc-roles
You might use this if you want invoices (and other emails about
invoices) to go to different people, multiple people, and so on.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
Host snaps unexpectedly rebooted approximately 15 minutes ago. I'm
not in front of a computer at the moment so will have to investigate
later. I believe it will be the same bug that has plaguedusers of
"hen". If so then at least snaps has now booted with the settings
that are hoped will avoid the issue in future.
Apologies for the disruption.
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
You can now add contacts to the "Data Transfer" role of the address
book:
https://panel.bitfolk.com/account/contacts/#toc-roles
If you do that then these will be the only addresses that receive
emails about your weekly data transfer stats, predicted overage,
actual overage etc.
I am also going through and rewriting documentation to reflect the
new policy that no overage will be allowed without prior
confirmation, i.e. we'll turn off your network rather than allow you
to run up a bill, unless you indicate otherwise. If you spot any
that's out of date after a few days from now, please do let me know.
(Those handful of customers that regularly incur overage bills
should assume that this will continue to be the case. I'm talking
about for people we haven't spoken to about overage before.)
I hope to get on to splitting out the billing functions into a
billing role next.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Oops, I've just noticed that this only went to users@, not announce@. Sorry about the extra copy some of you are now getting. :(
Cheers,
Andy
----- Forwarded message from Andy Smith <andy(a)bitfolk.com> -----
Date: Fri, 21 Dec 2018 14:49:34 +0000
From: Andy Smith <andy(a)bitfolk.com>
To: users(a)lists.bitfolk.com
Subject: Re: [bitfolk] Host "hen" crashed again (Was: Re: Host "hen" unexpectedly rebooted 2018-11-26 22:24)
User-Agent: Mutt/1.5.23 (2014-03-12)
Reply-To: users(a)lists.bitfolk.com
Hi,
This happened again a few minutes ago.
IPv6 failover appears to have happened correctly due to some fixes
since last time - hence no v6 outage until manual intervention.
hen has now booted with some settings which it is hoped will avoid
the problem in future.
I'm not in front of a computer at the moment so later today I'll
review what was logged.
Apologies for the ongoing hassle.
Cheers,
Andy
Hi,
There's a long-standing request to implement a way for customers to
disable password authentication on their Xen Shell SSH accounts
(i.e. ssh username(a)username.console.bitfolk.com):
https://tools.bitfolk.com/redmine/issues/116
This has now been implemented¹, so if you go to:
https://panel.bitfolk.com/account/security/#toc-allow-xen-shell-ssh-access-…
you can set that if you wish. You will first need to have added at
least one SSH public key, as that is the only way you'll be able to
log in to the Xen Shell after that.
I don't anticipate many people using this or it changing frequently,
so I haven't bothered to implement immediate update of our SSH
config. Instead you might have to wait up to 30 minutes for the
sshd_config on the host machine to actually be updated.
The other already existing way to further secure your Xen Shell
login is to use 2 factor authentication, as described on the same
page. Enabling that will require you to supply a code from a TOTP
app such as Google Authenticator, 1Password, etc.
Cheers,
Andy
¹ 11 days short of 5 years since it was requested, woohoo!
--
https://bitfolk.com/ -- No-nonsense VPS hosting