Hi,
I am a (delighted!) relatively new BF user and run two dozen websites under Centos and Virtualmin, with no email as I keep email off my webserver.
I am fed up with Cpanel in multiple ways and want to drop the server where I currently have all my email and mail forwarders.
Is another VPS on Centos with Virtualmin a good route to manage my and my clients’ email?
Or is there a better solution for a mail server?
Cheers
Hugh
Hi,
I’m trying and failing to get overlay network traffic working between Docker containers on different VPS hosts. The issue seems to be that neither host is sending VXLAN data on port 4789. I’ve been getting help on Docker’s IRC channel and the suggestion there is that issues have been seen before with this and interaction with other virtualisation technologies (VMware, for example) which also use VXLAN. Does anyone know if there are issues using swarm/overlay networking between Xen VPS hosts?
Regards,
Chris
—
Chris Smith <space.dandy(a)icloud.com>
Hi,
At around 00:15Z we started receiving alerts regarding some servers
on host "elephant". Looking at the machine's console it was
reporting errors with its SAS controller, and was generally
unresponsive to anything requiring block IO, so I had no choice but
to power cycle it.
On boot I couldn't find any issue with its SAS controller, and it
was able to find all its storage devices and seemingly boot
normally. The last few customer VPSes have finished booting as I
type this.
I will keep an eye on things for the next few hours and let you know
about further actions. Please accept my apologies for the
disruption.
This is unrelated to the problems with "elephant" last month which
were tracked down to a kernel bug.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
A few days ago someone asked if we would match a 5% discount that
another hosting company offered to developers of significant open
source projects. After thinking about it for a bit I decided we
would.
So, if you are a registered Debian/Ubuntu Developer, Fedora
maintainer, BSD committer etc etc please feel free to email
support(a)bitfolk.com and ask if you qualify. When you do, please
provide some sort of link to your work so we can verify it.
More information here:
https://tools.bitfolk.com/wiki/Developer_discount
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,
This email doesn't discuss anything that you need to change (or in
fact CAN change, at the moment), it's mostly a status update and
fishing for feedback so can be safely ignored.
As you may know, all BitFolk VPSes currently run under Xen PV
(paravirtual) mode. We would like to switch to PVH mode instead.
Here's some notes about our investigations of PVH mode:
https://tools.bitfolk.com/wiki/PVH
On the one hand we can get started right away: BitFolk's hypervisors
support it, the newer stable releases of Debian and Ubuntu support
it, the mainline kernel supports it, the rescue VM will work, etc
etc. All new customers can be run in PVH mode as long as they don't
choose an older release.
On the other hand, it's not quite that simple as there's still a
huge amount of existing customers whose kernels won't support it.
I think it probably makes sense to immediately switch the Rescue VM
to PVH mode, and make all installers also use it where the chosen
install is known to support it. i.e. make it so that if you go and
install Debian buster or testing or Ubuntu 20.04 right now, it
silently switches you to PVH mode, because it's known to work.
At the same time, we can add a Xen Shell command to toggle you
between PV and PVH so you can try it out. If it doesn't work you
could switch back, try again later at your own leisure etc. We don't
know what Linux distribution you are running and can't tell without
snooping on your console, so we can't make a good enough guess on
your behalf.
I don't really want to make a big thing of this because it's too
complicated, so I'm thinking of hiding it away unless you need it.
New customers / installs shouldn't have to think about it. It's only
a concern for those of you with older, possibly 32-bit installs. For
that reason I don't think I want to expose any of these details on
the web panel or allow switching of the guest type there.
On the subject of 32-bit PV support the deadlines are fairly laid
back as — assuming you have no need of running a 5.9+ kernel —
32-bit PV booting could possibly¹ continue to work until 2023, which
is the security support EOL for the last version of Xen that will
support it.
We're currently using Xen 4.10 and 4.12, and with the release of
Debian 11 (bullseye) I will probably be looking to rolling upgrade
to that with Xen 4.14.
Any questions or thoughts on this?
Cheers,
Andy
¹ It is conceivable that some new CPU side channel attack lands and
it's found that there is no way to stop a PV guest from snooping
on the memory of the hypervisor or other PV guests. In that case
there will be a sudden scramble to switch everyone.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
