Migrating from 20.04 -> 22.04 -> 24.04 on headless Ubuntu server? + hardware upgrade

Sun Dec 8 01:20:10 UTC 2024

At Sun, 08 Dec 2024 01:15:12 +0100 bo.berglund at gmail.com, "Ubuntu user technical support,? not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:

> 
> On Sat, 7 Dec 2024 17:46:25 -0500, Jeffrey Walton <noloader at gmail.com> wrote:
> 
> > I would back up the critical application data. You can always stand up
> > a new server right now with the NUC, configure it and load the data.
> > If you make a mistake, then no harm. Do it again with a modified
> > process. Once the NUC is setup properly, cut it into production.
> > 
> Might be the safest way to install Linux from scratch....
> 
> >>
> >> 2) Upgrade it to 22.04 and then to 24.04 using the do-release-upgrade command
> >> Once I have the backup done as above and somehow can make it use the latest
> >> kernel, then I want to do the transfer to 24.22.4 via 22.04.4
> >
> > One caveat that comes to mind since the machine is mission critical...
> > If you migrate to 24.04, then you will have to deal with Snaps. I
> > avoided 24.04 precisely due to Snap, and migrated my machines to
> > Debian and Fedora instead.
> 
> Yes, I have seen a lot of snap stuff when I do df -h....
> 
> What should I choose? Probably Debian since I am used to Ubuntu server command
> line?

Yes.  Using Ubuntu as a server is somewhat silly.  If you are not going to 
install any desktop environment and only use the "black console" or ssh, then 
plain Debian is probably the best choise.

> 
> After all this is a server version without using a desktop.
> Debian is what Ubuntu is based on so I guess I could install it as a server
> using the same download as with a Desktop?
> 
> Or should I install Debian *with* Desktop as a server that I never log on to?
> Then I would have the future option to do some GUI stuff if need be.

Debian (unlike Ubuntu) does not bother with "desktop" and "server" editions.
There is just one install image. During the install process you can select
which desktop (eg Gnome, KDE, etc.) or no desktop (no desktop = "headless"
server).

> 
> But if setting it to Desktop means tons of software being installed than perhaps
> not....
> 
> >> Or else - how can I make the move to new hardware?
> >
> >Just move the application data to a properly configured new server.
> 
> I have partitioned the existing server disk such that /home is on a separate
> partition so that it won't be part of the system functions.
> Likewise the Subversion data are on another partition.
> 
> So the server uses the following partition layout:
> 
> Partition       Mount point   Description
> -----------------------------------------------------------
> /dev/nvme0n1p1  /boot/efi     Windows/UEFI/Grub stuff....
> /dev/nvme0n1p6  /             Ubuntu proper
> /dev/nvme0n1p7  /var/lib/svn  Subversion data
> /dev/nvme0n1p8  /home         Big partition for user data
> 
> 
> >
> >> I cannot install a fresh system on the NUC because I have no idea how to then
> >> install all of the already configured services on the new hardware platform
> >> fresh from start...
> >>
> >> I simply do not now remember what I have done over the years to
> >> install/configure these since 2017 when it was originally built...
> >
> >Yeah, I know the feeling. I usually find my notes are incomplete, and
> >have to solve some of the problems all over again.
> >
> 
> What I have on this server is:
> - Apache server
>   Here I use LetsEncrypt certs and I do not remember how I set that up.
> 
> - Subversion plugged into Apache
>   This is a backup server which receives nightly synchronization
>   data from my company's Subversion server. 

OK, I've *actually* done similar stuff fairly recently.

First, I moved from a CentOS 7.x VPS to a Debian 12 VPS -- the CentOS 7.x VPS 
was at/near EOL and I did not want to go down the CentOS 8/9 rabbit hole.  
While CentOS 7.x Apache install is rather different from Debian Apache 
install, it was fairly painless: copied the virtual host .conf files to the 
new server and copied the php (or whatever) files from /var/www/whatever and 
copy the DB (mysqldump => mysql ...).

LetsEncrypt was even simplier, I just copied /etc/letsencrypt to
/etc/letsencrypt on the new server after installing certbot from the debian
repo. And everything just workeed, once I suitablly diddled the DNS (new
server, new public IP).

Also, my long term x86_64 home desktop/LAN server died (motherboard died after
10 years of 24/7 service). The disk was still working and is now on a USB SATA
dock jacked into a RaspPi5 [no not as something bootable] -- I mount its FS's
readonly to go after old data as needed. I moved the subversion data partition
to the RaspPi5's SSD, installed the Apache modules Subversion uses, along with
Subversions various bits and pieces. Hacked a suitable virtual host .conf file
(based on the old .conf file, with some obsolete bits removed and some bits
updated as needed), diddled with my LAN's DNS (I have Bind9 installed on a
couple of RaspPis: the RaspPi5 and a RaspPi3). And presto, all of my
Subversion working directories work as if nothing happened. Note this is an
even more extreme migration: from a long term x86_64 machine (CentOS 5=>CentOS
6=>Ubuntu and then to arm64 Debian 12.

> 
> - OpenVPN server with multiple services for connection to my home LAN
> 
> - Video utility that runs downloads at regular intervals using ffmpeg
> 
> When looking at the above it seems like the problem is finding the "application
> data", maybe /etc should also be on a separate partition?

No, you can't do that :-( -- it is a chicken/egg situation.  You need 
/etc/fstab during the early boot stages in order to mount other file 
systems... But a selective selective backup of /etc (eg backup the conf and 
data files of specific services (Apache, LetsEncrypt [see above], etc.) and 
restoring those files on the new server.  Eg:

sudo tar czf - -C /etc LetsEncrypt|ssh newserver dd of=oldLetsEncrypt.tar.gz
slogin newserver
sudo tar xf oldLetsEncrypt.tar.gz -C /etc

Or something like that.

> But I don't know how /etc works, it looks like a lot of system data I am not
> knowing about is stored there as well in addition to configs for applications I
> have installed...

Yes, you don't want to copy /etc/ wholesale that can break stuff.

But most services are "self-contained", in that the config and data are nicely 
contained in a specific directory and can be copied as a backup of the 
corresponding directory.  Going from CentOS 7 Apache to Debian Apache 
required a little care -- CentOS 7 Apache just has a catchall conf.d 
directory, where Debian has separate directories for virtual hosts, modules, 
and module confs, and has things divided up as available and enabled (contains 
symlinks to available).  But individual .conf files don't change from one 
system to the other and can be copied one by one.  OTOH, letsencrypt just has 
its own directory tree under /etc and that tree can just be migrated as is.

I don't know about OpenVPN, but it might compairable to either Apache or 
letsencrypt. 

> 
> I guess I will try to migrate by following your advice and build a fresh server,
> probably using Debian.
> I have to get the NUC first, though. Did not purchase one yet.
> 

-- 
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller at deepsoft.com       -- Webhosting Services