I am responsible for several VPSes, here and elsewhere. Five of them are
running Ubuntu 22.04, three Debians.
The script I use to update them checks, at the end, for the existence of
/var/run/reboot-required
If it finds it, it offers to reboot the VPS.
It does this happily on all but one VPS, one of the Ubuntu ones here. The
Ubuntu version of apt-get on all of the Ubuntu ones recognises that a
reboot is required after a kernel update etc and will popup a message
saying so, but it looks like only on this single machine, that file doesn't
exist afterwards.
I have no idea why not. Anyone got any ideas?
Ian
Andy said on the announce list:
"As usual with this sort of thing though, all the complexity is in the
packages you have installed, so that is no promise that it would be plain
sailing for you."
Having just tried, I am left with a VPS with no external networking.
Looking at the launchpad bug tracker, there have been problems with this.
I have tried one of the solutions there via logging in through the xen
console without getting it to work, but it is complicated by trying this on
my phone in terms of sorting it out.
Fortunately, it wasn't doing anything much - almost no additional packages
were installed - so at the moment, I have turned it off and will wait for
the installer to do a fresh install.
Ian
Hi,
As you may be aware, the next LTS release of Ubuntu is supposed to
be ready in a couple of days.
I've tested a do-release-upgrade from a basic 22.04 cloud image
(what you get when you install 22.04 at BitFolk) and it seemed to go
fine. As usual with this sort of thing though, all the complexity is
in the packages you have installed, so that is no promise that it
would be plain sailing for you.
We will try to get a Xen Shell installer option added for 24.04 as
soon after release as we can, but in the mean time just installing
22.04 and then typing "sudo do-release-upgrade -d" should get you
there.
I *think* it is the case that you need the "-d" as
do-release-upgrade normally doesn't like doing it until the first
point release.
Thanks,
Andy
Ubuntu 24.04 LTS debtest1.vps.bitfolk.space hvc0
debtest1 login: ubuntu
Password:
Welcome to Ubuntu 24.04 LTS (GNU/Linux 6.8.0-31-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/pro
System information as of Tue Apr 23 13:31:00 UTC 2024
System load: 0.07 Memory usage: 6% Processes: 131
Usage of /: 14.6% of 19.20GB Swap usage: 0% Users logged in: 0
Expanded Security Maintenance for Applications is not enabled.
0 updates can be applied immediately.
Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
ubuntu@debtest1:~$ uname -a
Linux debtest1.vps.bitfolk.space 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat
Apr 20 00:40:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
In light of the recent XZ/lzma backdoor we should perhaps think
harder about how complex sshd is and the wisdom of exposing that to
the entire Internet.
At BitFolk, this currently needs to be exposed to the Internet so
that you can connect to your Xen Shell (console).
More info on the Xen Shell for those new to it:
https://tools.bitfolk.com/wiki/Xen_Shell
When thinking about ways to tighten this up, they are all going to
involve taking away your ability to just SSH to
you(a)you.console.bitfolk.com.
There's a couple of ways this could go:
1. Remove direct SSH capability, replace with web
All current Xen Shell features to be put on a web interface.
Console to be used from a web interface.
I don't relish this, but I have seen some pretty nifty web
terminals so maybe it wouldn't be that bad.
2. Firewall off SSH from the Internet, poke holes temporarily
You'd have to supply to the Panel some list of net blocks that
you will SSH from and then there'd be a button to punch holes in
the firewall for SSH from those net blocks for 6 hours (for
example).
There would have to be a limit on the size of the net blocks.
Let's say a /16 for IPv4 and a /32 for IPv6.
Option (2) is lots easier to implement so could happen fairly
quickly, but it is more fiddly to use: You're in an arbitrary place
and you suddenly need to connect to your Xen Shell; you've then got
to log in to Panel, work out your IP address¹, add it to the allow
list, then hit the button. Finally you can SSH.
Option (1) will require a lot of work but maybe it's less friction
to use a web-based terminal if you have to visit a web site anyway?
Option (2) does not preclude option (1). Providing a web-based
terminal that doesn't need the "allow SSH" button to be pressed can
be implemented after option (2) is done, as a sort of stretch goal.
Or maybe the web terminal is such an attractive and required feature
that it should be done first, before option (2) would be enacted?
I am disregarding the idea of flipping the default to having
password auth disabled. It is currently by default enabled but you
can disable it on a per-VM basis. I do recommend that you do that,
but what I am really more concerned about is an(other) exploit in
sshd, and that doesn't really have to be anything to do with
authentication (the XZ thing wasn't). Yes it would be a very bad day
for you if someone got in to your Xen Shell, but that's as far as
that goes, so I am still okay with leaving that determination up to
the customer.
I can't see a way of avoiding there having to be a list of net
blocks. With 50+ VMs on a host, if SSH is opened up from anywhere
for any one of them then it is open for all so really even with a
timeout it would be open a lot of the time.
I guess something interesting could be done for those not on legacy
Internet: assign unique IPv6 console address that can only be used
for connecting to that VM's Xen Shell. 😀
I'd be interested in hearing your thoughts on this.
Thanks,
Andy
¹ Which you may not know because you might be behind one or more
layers of NAT.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
We had a customer ask about backups of images of their VM disk. This
is not currently a service that we offer.
It has some advantages, so it could be a service that we offer.
The main advantage being:
- High degree of confidence that the VM is just able to be one-click
restored and is then bootable and working, as it's an exact image
of the disk
It does of course also have a heap of disadvantages such as:
- Granularity of backup is "the entire disk". No way to pick and
choose what is backed up except by putting things on different OS
disks.
- It's based off a disk snapshot so nothing in memory gets
preserved; a restore event will be similar to a "boot after
unexpected power cut" event to the restored VM. Though doing the
snapshot while the VM is powered off for a few seconds would be
an option.
- This obviously uses a lot of disk space which we'd charge for at
our archive storage rate: £0.40+VAT/50GB/month. If preferred this
could go onto third party cloud storage but bear in mind that
Amazon S3 is about 3 times the cost of BitFolk's archive storage.
- Limited differential backups are possible though I'm yet to fully
understand how well that works. All I can say right now is that
a differential would use less, but I'm not sure really how much
less.
So, there would be "some charge" for the service itself and
definitely a charge at archive storage rates for the actual amount
of storage involved.
If this sounds like a service that you think you'd actually want,
please get in touch off-list and we'll see if we can develop it.
As it's more the BitFolk way for customers to do this sort of thing
themselves I don't really expect this to be widely desired, but I am
working on it for one customer anyway so if I can make it more
generally applicable then I will.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
