Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Distro upgrades #74

Open
trickeydan opened this issue May 31, 2020 · 7 comments
Open

Distro upgrades #74

trickeydan opened this issue May 31, 2020 · 7 comments
Assignees
@drn05r @TimStallard
Labels
systems administration Administation of servers and the systems running on them

Comments

@trickeydan
Copy link

trickeydan commented May 31, 2020 •
edited
Loading

We could update to 20.04 now that it has been out for a while.

We really need to update the 16.04 boxes too.
@drn05r
Copy link
Member

drn05r commented May 31, 2020

My general rule is to wait on the next non-LTS version of Ubuntu (e.g. 20.10) to come out before upgrading to the latest LTS. 20.04 does not look as problematic as previous LTS. However, upgrading need not be rushed unless functionality is required from the LTS.

Ubuntu 16.04 -> 18.04 should be started ASAP save a last minute panic.

@TimStallard
Copy link
Member

TimStallard commented May 31, 2020 •
edited by drn05r
Loading

We'll need to hold off upgrading GW/GW2 for a while, as Ubuntu removed the python2 version of ifupdown2, and the ifupdown2 people haven't got python3 packages sorted out yet.

16.04 machines to sort:

  • auth2
  • www
  • marconi
  • vpn-test
  • monitor
  • admin-dev

That list may not be exhaustive, just things that came to mind. Once we've got the server attributes check we should at least have a proper and up to date list of versions in netbox :)

@trickeydan
Copy link
Author

My general rule is to wait on the next non-LTS version of Ubuntu (e.g. 20.10) to come out before upgrading to the latest LTS. 20.04 does not look as problematic as previous LTS. However, upgrading need not be rushed unless functionality is required from the LTS.

I feel like we should document this somewhere.

Let's keep this ticket for primarily tracking 16.04 upgrades.

@TimStallard
Copy link
Member

FWIW, something along those lines is enforced on the Ubuntu side - it won't allow you to upgrade from one LTS to the next until the .1 release is out (ie 20.04.1 in this case), unless you explicitly say you want to upgrade to a dev release.

@drn05r drn05r added the systems administration Administation of servers and the systems running on them label Sep 19, 2021
@drn05r
Copy link
Member

drn05r commented Sep 19, 2021 •
edited
Loading

We now have all servers (including auth2 upgraded to 18.04). We should try to make progress on upgrading servers to 20.04, focusing on those that are most straightforward and least critical first. Some have already been done. I have put a risk score next to each server (1-3 scale for how critical the server is, 1-3 for how complex/liable to the break stuff the upgrade would likely be):

  • auth2 (3 x 3 = 9)
  • backup-b53-1 (2 x 1 = 2)
  • backup-b32-1 (2 x 1 = 2)
  • backup-test (0 x 1 = 0)
  • buildroot (2 x 1 = 2)
  • buildroot-dev (1 x 1 = 1)
  • data1 (0 x 1 = 0)
  • external-monitor (2 x 1 = 2)
  • gw-b53-1 (3 x 3 = 9) - Replaced with new server running 22.04.
  • gw-b32-1 (3 x 3 = 9) - Replaced with new server running 22.04.
  • jumpbox (1 x 1 = 1)
  • marconi (3 x 2 = 6)
  • monitor (2 x 2 = 4) - Hopefully remove and just use monitor2 when all checks moved.
  • monitor2 (2 x 2 = 4)
  • netbox (2 x 1 = 2)
  • tunnelbroker (2 x 2 = 4)
  • vms-b32-1 (3 x 3 =9) - Plan to shift VMs to vms-b53-1, so wok can be replaced with lxd and upgrade OS at same time.
  • vms-b53-1 (1 x 3 = 3)
  • vpn (1 x 2 = 4)
  • www (2 x 2 = 4) - Not enough space for /boot/. Rebuild as our own VM. This iSolutions VM has been renamed to dev and containers-2 VM on vms-b53-1 now hosts www.sown.org.uk.
  • zepler-websdr (1 x 2 = 2)

@drn05r
Copy link
Member

drn05r commented Mar 9, 2024 •
edited
Loading

We probably should now sort out making sure VMs are upgraded to Ubuntu 22.04 LTS. I have put a risk score next to each server (1-3 scale for how critical the server is, 1-3 for how complex/liable to the break stuff the upgrade would likely be):

  • auth2 (3 x 3 = 9)
  • backup-b32-1 (2 x 1 = 2)
  • backup-b53-1 (2 x 1 = 2)
  • buildroot (2 x 1 = 2)
  • buildroot-dev (1 x 1 = 1)
  • containers-1 (1 x 2 = 2) - New VM installed with Ubuntu 22.04
  • containers-2 (2 x 2 = 4) - New VM installed with Ubuntu 22.04
  • containers-3 (3 x 2 = 6) - New VM installed with Ubuntu 22.04
  • data1 (0 x 1 = 0) - Not currently being used for anything
  • external-monitor (2 x 1 = 2)
  • gw-b53 (3 x 3 = 9) - New server installed with Ubuntu 22.04
  • gw-b32 (3 x 3 = 9) - New server installed with Ubuntu 22.04
  • login (2 x 1 = 2)
  • login2 (2 x 1 = 2)
  • marconi (0 x 1 = 0) - Not currently being used for anything.
  • monitor2 (2 x 2 = 4)
  • netbox (2 x 1 = 2)
  • vms-b32-1 (1 x 2 = 2) - Still on 18.04 but all VMs migrated to vms-b53-1 so server can be reinstalled from scratch.
  • vms-b53-1 (3 x 3 = 9)
  • vpn (1 x 2 = 2)
  • zepler-websdr (1 x 2 = 2)

@drn05r
Copy link
Member

drn05r commented Jul 14, 2024

netbox upgraded to 22.04 and vms-b32-1 reinstalled with 22.04 but likely to be re-installed again when we have SSDs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@drn05r drn05r

@TimStallard TimStallard

Labels
systems administration Administation of servers and the systems running on them
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@drn05r @TimStallard @trickeydan