Hello,
As you may have seen in the other thread, it's become evident that
we need to embrace cloud-init for installs of Ubuntu 22.04 and
beyond.
I've got that working now, in that I can boot an unmodified Ubuntu
22.04 VM image with an attached disk of custom data, and it
automatically configures itself from that. What remains is to make
our Xen Shell do that bit.
My proposal for how that will work is here:
https://tools.bitfolk.com/redmine/issues/207
Please give feedback, preferably in redmine (your usual bitfolk
credentials) about that, otherwise that is how it's going to be
done.
I would hope that a later development would be to allow customers to
supply their own cloud-init user-data.
Also feasible later would be to support more distributions that have
gone with cloud-init¹ as, though I do not like working with it, it
is at least a standard and probably supported in more things than
debian-installer and Red Hat Kickstart.
Some people have expressed dislike for using the Debian/Ubuntu text
mode installer in the past, saying that they would prefer something
closer to a "one-click" fully-automated install even if it wasn't as
flexible as something produced by the Debian installer. They will
now have their wish for Ubuntu, and maybe others, though I do not
plan to move away from preseed/kickstart as an option.
Cheers,
Andy
¹ They do still have to have left Xen enabled in their kernel,
unlike RHEL/CentOS, Rocky etc.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
I had emails returned due to no reverse address. My email server is running
on one of my VPS and I have had all my VPS DNS delegated to me as well. I
have been using the email server since the dawn of time, this hasn't
happened before.
Now after a lot of digging, these servers that rejected said no rDNS on the
IPv4 address (There were infact 2 of them UKmail and BTInternet.) I think
it is because they are querying the Bitfolk servers, because, of course, I
only have the one IPv4 address delegated to me and they are looking for the
IPv4 reverse address of Keynesmail.com at theBitfolk server. It doesn't
know about that domain name - no reason it should really.
So should I ask Andy for secondary DNS for that domain name, would that
solve the problem? Or is there another way out of this. I have a number of
very low traffic domains on that VPS, but this one domain, that of the
email server is causing this heartache.
I guess those 2 are the only ones we have come across using IPv4, all other
addresses sent to just work fine, including Gmail and Yahoo mail. The email
address having problems with the sending is one used by a small local
cancer support group and both the user of it and the intended recipients
are total technophobes as well as being, like me, rather advanced in years.
Keith
Hi,
TL;DR version:
The next Ubuntu LTS release, 22.04, is scheduled for 21 April.
They've made some changes which mean that we likely won't have it
ready in time for new installs and self-installs from the Xen Shell.
It will probably be fine for an upgrade using do-release-upgrade,
but you should wait a while for us to test it.
Full version:
In their wisdom Ubuntu have decided that Debian Installer and
preseeding are no longer for them, and have gone with something else
of their own devising¹ for 22.04. As a result our Xen Shell will
need quite a bit of work to support that (if it is possible), and I
don't expect that to get done in time for the release of 22.04.
I do expect that a do-release-up[grade from 20.04 will work, but I
haven't tried it yet. Unless you are prepared for potential
disaster I suggest you do not be a pioneer for that.
We will soon have a go with that and let you know about any issues,
so I advise waiting.
Cheers,
Andy
¹ https://ubuntu.com/server/docs/install/netboot-amd64
This appears to involve extracting a vmlinuz+initrd from the iso
file, booting those and pointing them to the iso which they
download, mount and use as a live media for install.
By contrast debian-installer is just in the netinstall initrd that
you download, you point it at a Debian mirror and off it goes.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hello,
The version of udev that will come with the next Debian stable and
Ubuntu LTS releases has learned about Xen network interfaces and as
a result they will be subjected to "predictable network interface
naming":
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfa…
That is, you won't have an eth0 any more, it will be en123abc or
whatever, based on MAC address.
For new installs, either when ordered or when the customer does an
install via Xen Shell, we could force this to not happen by using
net.ifnames=0 on the kernel command line. The single network
interface will then always be eth0.
Arguments in favour of doing this:
- It makes life simpler for BitFolk's post-installation scripts
because they won't have to work out what the network interface
will be called.
- "predictable network interface names" are arguably pointless in
the scenario of a BitFolk VM because the only way to get extra
network interfaces is by explicit configuration either within the
VM by its admin or outside the VM by BitFolk, which would include
what its name is.
Arguments against:
- It's not the default behaviour of the Linux distribution any more.
- If you upgraded a previous release with dist-upgrade /
do-release-upgrade it would get these "predictable names", which
is maybe just an extension of the above point.
Would you have any concerns if you made a new order or did a new
install and it came with net.ifnames=0?
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
BitFolk's IRC channel has now been relocated to #BitFolk at
irc.libera.chat.
Those of you who were playing a game of Perpetually Against
Humanity¹ in there (has been running for just over 7 years!) can
continue doing so but if your nickname is different on Libera then
please ask me (grifferz) to change it for you in the game's
database. The scores and history have been retained. If you start
playing again under a new nickname it will make fixing that
difficult, so please don't!
The other regular IRC bots are still there too. The channel stats
web page has been broken for a while, but I hope to fix it at some
point.
If you are new to Libera Chat (or IRC in general), you can get
started here:
https://libera.chat/guides/
Cheers,
Andy
¹ https://github.com/grifferz/pah-irc
--
https://bitfolk.com/ -- No-nonsense VPS hosting
I've just had a brief interchange with a small charity that uses
DigitalOcean for some of their systems. A password-change mail from
their website was binned by my exim instance, for a score of 8.8 given
to it by the Bitfolk SpamAssassin (5.0 of that for coming from Digital
Ocean).
Can anyone suggest how, if at all, I can whitelist mail from that
particular domain in my (Debian) exim4 config, given that I'm using
the Bitfolk SpamAssassin and therefore have no control over it?
Thanks,
Hugo.
--
Hugo Mills | No names... I want to remain anomalous.
hugo@... carfax.org.uk |
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
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
