Hi All,
On https://boeser.ch/files/sys-arch.svg I published our sketches on
different system architectures. On the various sketches you see
node-1, node-2, node-A and node-B. In all sketches node-1 and 2 are
always considered to be containers (lxc-1, lxc-2). node-A and B are in
some sketches containers (LXC-A, LXC-B) and VMs in others (VM-A,
VM-B).
We have in mind two different admins for the red and the white parts
in the sketches. Obviously red admin has more power than white admin.
It is our primary goal to achieve a good trade off between strong
isolation/security and performance.
We consider the advantages of virtual machines as follows:
- a VMM (Xen, KVM) is considered to be more secure than a random linux
distribution that hosts containerization (LXD, Docker)
- isolation between virtual machines is stronger compared to
containers
- probably better support to run other OS (e.g. Windows, BSD etc.)
We consider the advantages of containers as follows:
- efficient in both resources and performance since kernel is shared
- faster startup then VMs
- "build once run everywhere"
Are there any reports you know of about how performance is reduced in
a VMM setup compared to a container setup? Or, do you have some
experience yourself?
Do you have any other thoughts when looking at the sketches?
Regards,
Sam
Hi,
Sometimes some of my services misbehave in weird and wonderful ways.
If that happens, they can use an awful lot of bandwidth.
Whilst there is some monitoring that I can do (and do), I prefer to use
the data "closer to source".
There seems to be some data, that triggers pretty quickly and sends out
an email from "xfer a_t bitfolk.com" with the heading "Predicted to
exceed transfer quota".
However, rather than email I'd like an API, so that I can route it to
my alerting system. I do overlook emails sometimes, especially computer
generated ones.
My brain sometimes scans and classifies them too quickly as "deal with
it later" and incorrectly flags the email as 'not important'.
Having the information in my alerting system means I can route them so
that they remind me/trigger me again etc.
My questions are:
1. How often is that prediction calculated?
2. Is there an API I could query which gives me the data from the
email?
2.1 I'd settle for a binary API (predicted overusage == true|false)
2.2 otherwise an api that gives me the following values:
- predicted usage in
- contracted usage in
- predicted usage out
- contracted usage out
- Actual out
- Actual in
Nothing fancy required - a simple 'get' request or so would do just
fine ;)
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
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hello,
Owing to some fine work by a customer, we will soon be able to list
OpenSUSE Leap as supported:
https://tools.bitfolk.com/wiki/User:Moggers87/Installing_Opensuse
This prompts a perhaps somewhat philosophical question:
In the context of our supported distros bit:
https://bitfolk.com/techspec.html#toc_2_Available_Linux_distributions
what would you consider the supported lifetime of OpenSUSE Leap to be?
I don't know very much about OpenSUSE. From what I have been able to
gather:
- The current release is 15.3
- This was released 2021-06-30
- Support lasts for 6 months after the next minor release
- "Support" means no major updates to packages, just security fixes or
serious bugs fixed
- A minor release roughly every year
- So 15.3 support ends around December 2022, as 15.4 will be
released around 2022-06
- In-place upgrade is supported to next minor release (or even
through major releases?)
- The last 15.x minor version is expected to be 15.5 in 2023
supported until some time in 2024
Do you consider that EOL 2022-12, or EOL 2024-XX?
Since you HAVE to do an update or else don't get security fixes, I
think that is EOL 2022-12. That does make OpenSUSE Leap look like a
little worse option though unless you fully understand this.
On the other hand, I'm not sure I can truthfully state that its EOL
would be 2024-XX as that may lead someone who does not do the
research to think they can only do package upgrades all the way out
to 2024.
So, erring on the side of caution, it should be listed as 2022-12,
right?
(The other entries are also complicated by the different tiers of
support, and I continue to remain conflicted over listing Ubuntu's
ESM which is free but requires registration.)
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
The Rescue VM needed updating as its 4.19.x kernel was getting too
old, e.g. not able to mount XFS filesystems as created by CentOS
Stream 8 and Fedora:
https://tools.bitfolk.com/redmine/issues/206
It has now been updated to a Debian 11 (bullseye) system with
bullseye-backports (5.15.x) kernel.
I've done basic testing but please do let us know if you encounter
any difficulties using it.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
We decided to make our Debian installers use the mirror host of
deb.debian.org instead of ftp.uk.debian.org.
This was done initially just to make the /etc/apt/sources.list look
the same as the many examples in Debian's documentation.
However I did then notice that at some point in the last 15 years
(!) ftp.uk.debian.org has moved from London to Manchester and is now
about 12ms away from BitFolk. The nearest Fastly instance for
deb.debian.org is about 0.9ms away, so it's also faster to use that
one.
By default we do set it up to use our apt-cacher, so every URL in
there is prepended with:
http://apt-cacher.lon.bitfolk.com/debian/
These days it maybe has questionable benefit, when package updates
will only be a small fraction of your data transfer quota, but we'll
carry on using it for now.
Anyway, whether or not you use the apt-cacher, you can make this
switch by just doing a substitution of "ftp.uk.debian.org" with
"deb.debian.org".
There are still some pages on the wiki that will refer to
ftp.uk.debian.org; if you spot any please feel free to update them
to say deb.debian.org.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
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
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
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
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
I am working on Stripe continuous credit card authority at the
moment, i.e. you give your card details to Stripe and they let
BitFolk charge what it wants, when it wants, so as to enable
automated card payments.
I will soon need some volunteers to help test it out more
thoroughly. There will also be UI aspects I need feedback on.
If you would be interested in helping out, please could you contact
me off-list? Ideally you would:
- be on a monthly contract
- not mind being charged a bit early - it will renew your service
early (once it works properly)
- not be using any other automated method like Direct Debit or
PayPal subscription, as those would have to be cancelled first.
In the event of any incorrect charge I will just refund it to your
card again.
There might be some form of free service bonus for helping out,
though we will not talk about that for some weeks as I'll want to
get it all working first.
After it's initially working in its most primitive form we will
discuss improvements to it on the tracker at:
https://tools.bitfolk.com/redmine/issues/202
If you are interested in the progress of it, whether or not you are
able/willing to help, you may wish to add yourself as a watcher of
that issue to receive email updates. Stuff from there also ends up
here:
https://tools.bitfolk.com/redmine/issues/202
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Dear all,
I need to buy NVMe disks for a HP DL365 server. [1] They will be used as
storage for lxd (linuxcontainer)?
Can anyone recommend any?
Or do you know any trustworthy site with reviews?
Regards,
Sam
[1]
https://www.hpe.com/psnow/doc/a50002558enw.html