[SOLVED] Automate Pacman Updates on LTS Kernel?

doctorzeus · 2017-08-14 11:08:16

Hello All,

We currently run our office server on Arch and I recently shifted into booting into the lts kernel so we don't really have to risk a reboot when we upgrade (although we still keep the regular kernel installed just in case!).

Now I usually do a full system upgrade on Friday night but I would idearly want to create an automatic update cron job with pacman.

Obviously this carries some risks (although hopefully somewhat mitigated by the lts kernel) due to the usual reasons and was wondering what people's thoughts on this were on anything like this and if anyone has a process of doing this safely?

I have read the wiki (i.e. https://wiki.archlinux.org/index.php/Up … om_crontab ) but was wanting more to find out if anyone had any personal experience on it?

Many Thanks!

Last edited by doctorzeus (2017-08-14 13:12:29)

Slithery · 2017-08-14 11:32:04

doctorzeus wrote:

...and I recently shifted into booting into the lts kernel so we don't really have to risk a reboot when we upgrade (although we still keep the regular kernel installed just in case!).

Obviously this carries some risks (although hopefully somewhat mitigated by the lts kernel)

These sentences don't make any sense to me, why would running the LTS kernel prevent you from having to reboot every time it is upgraded? -- The LTS kernel package still receives regular updates.

You should never run automated updates on a server - especially if it is a production machine.

I'm currently writing a script to use on my personal server (non-production) that uses systemd-nspawn to copy the running machine into a container and run the updates there first so I can get an advance copy of any .pacnew files to examine before running the upgrade.

Edit - In my history of using Arch on a server the biggest breakage hasn't come from the kernel anyway, it was a major version postfix update that required me to rewrite all of the config files for my mailserver.

Last edited by Slithery (2017-08-14 11:34:19)

ugjka · 2017-08-14 11:34:28

Things will break... Simply don't use arch in production unless you really depend on bleeding edge technologies

doctorzeus · 2017-08-14 11:56:11

Thanks for the reply.

These sentences don't make any sense to me, why would running the LTS kernel prevent you from having to reboot every time it is upgraded? -- The LTS kernel package still receives regular updates.

Our idea was that LTS major kernel releases are released a lot less so less likely of getting a package breaking from a kernel update even though patches occur regularly.

You should never run automated updates on a server - especially if it is a production machine.

Why we have been doing this manually at the end of the week when our staff are out-of-office. We have other non-major windows servers running an automated update over the weekend and then rebooting hence the post wondering how feasable this was. The server running arch currently handles our routing and networking needs so although is very important (our phone lines are voip on one of it's subnets) it is not instant death if it did go down as we do have fallbacks.

I'm currently writing a script to use on my personal server (non-production) that uses systemd-nspawn to copy the running machine into a container and run the updates there first so I can get an advance copy of any .pacnew files to examine before running the upgrade.

We do daily borg updates of the entire system, we could maybe use this as an additional fallback if we carry out the backup before any automated updates. Of course sounding like this is not a good idea but nothing wrong with blue skying!

Edit - In my history of using Arch on a server the biggest breakage hasn't come from the kernel anyway, it was a major version postfix update that required me to rewrite all of the config files for my mailserver.

The only break we have had was with a BIND update which meant we had to fallback on our main gateway's DNS: We downgraded as soon as we found this had occured. We were planning on additionally logging the pacman config in an off-server nas if we did do anything automated so we can access the log in case of problems.

doctorzeus · 2017-08-14 12:01:06

ugjka wrote:

Things will break... Simply don't use arch in production unless you really depend on bleeding edge technologies

From the brief googling I did, I found quite a few people using arch on a prod server with the advice of "as long as your careful" being the most common advice.

Although looking from that it might be best to stick with manual updates, again was wondering how feasable it was from people.

ayekat · 2017-08-14 12:15:21

doctorzeus wrote:

From the brief googling I did, I found quite a few people using arch on a prod server with the advice of "as long as your careful" being the most common advice.

It's perfectly fine to run Arch Linux on private servers (because it's likely to be the distribution one feels most confident with for for solving problems), or environments where you are sure that everyone involved is fine with it.

But when it comes to a company's server or something alike, you also have to take into account that the "industry standard"—you may like it or not—is rather Debian or some flavour of RedHat (CentOS, RHEL, ...); if someone new has to start managing a server, they might not be very happy to find a distribution that is found less often in the wild.
So in cases where I'm not sure I will be there to maintain the server forever (or where I co-maintain with/for other users), I usually go with Debian (or maybe CentOS), to create some "common ground" with potential successors.

2ManyDogs · 2017-08-14 12:51:15

doctorzeus wrote:

Our idea was that LTS major kernel releases are released a lot less so less likely of getting a package breaking from a kernel update even though patches occur regularly.

This has not been my experience using the LTS kernel, and if you look at the package changelogs you will see that the LTS kernel is updated quite regularly. Maybe a little less often than the mainline kernel, but definitely not "a lot less".

slithery wrote:

You should never run automated updates on a server - especially if it is a production machine.

ugjka wrote:

Things will break... Simply don't use arch in production unless you really depend on bleeding edge technologies

Both very good points. I don't think you will be convinced, but I would also never use Arch on a production server, especially one that does routing and networking, and would never run automated updates on any Arch machine. For your use case I'd cast another vote for Debian stable.

doctorzeus · 2017-08-14 13:04:27

ayekat wrote:

doctorzeus wrote:
From the brief googling I did, I found quite a few people using arch on a prod server with the advice of "as long as your careful" being the most common advice.
It's perfectly fine to run Arch Linux on private servers (because it's likely to be the distribution one feels most confident with for for solving problems), or environments where you are sure that everyone involved is fine with it.
But when it comes to a company's server or something alike, you also have to take into account that the "industry standard"—you may like it or not—is rather Debian or some flavour of RedHat (CentOS, RHEL, ...); if someone new has to start managing a server, they might not be very happy to find a distribution that is found less often in the wild.
So in cases where I'm not sure I will be there to maintain the server forever (or where I co-maintain with/for other users), I usually go with Debian (or maybe CentOS), to create some "common ground" with potential successors.

Ok that would make sense , although other members of the team might struggle anyway as most of them are Windows users anyhow!

We had windows server on our old server but it broke so often and was such a pain to change the routing tables that we decided to switch over and Arch was the most familiar Linux distro.

Sounding like it might be a good idea to switch to Debian if we ever upgrade the system though!

doctorzeus · 2017-08-14 13:10:00

2ManyDogs wrote:

doctorzeus wrote:
Our idea was that LTS major kernel releases are released a lot less so less likely of getting a package breaking from a kernel update even though patches occur regularly.
This has not been my experience using the LTS kernel, and if you look at the package changelogs you will see that the LTS kernel is updated quite regularly. Maybe a little less often than the mainline kernel, but definitely not "a lot less".
slithery wrote:
You should never run automated updates on a server - especially if it is a production machine.
ugjka wrote:
Things will break... Simply don't use arch in production unless you really depend on bleeding edge technologies
Both very good points. I don't think you will be convinced, but I would also never use Arch on a production server, especially one that does routing and networking, and would never run automated updates on any Arch machine. For your use case I'd cast another vote for Debian stable.

That's interesting.

Well I don't think we will be moving over from Arch simply due to the migration time however from the comments i'm definately convinced moving over to Debian if we ever change server or something similar we will definately be using Debian by the sounds of things!

Might be good to possibly get a note in the wiki under (https://wiki.archlinux.org/index.php/Server) to advise uses as when we read it intially we got the green light impression.

eschwartz · 2017-08-14 14:28:54

FWIW: FS#16702 is the main reason kernel releases, LTS or otherwise, are somewhat annoying. You don't actually need to reboot just because your kernel updated... unless you actually want to take advantage of the updates it brings. You do, however, have to reboot if you want to modprobe any currently-unloaded modules after a kernel update deletes the ones for the running kernel...

Personally, I just stuck `IgnorePkg = linux linux-ck linux-lts` into my pacman.conf and explicitly update the kernel on my laptop right before a planned shutdown/reboot.

Last edited by eschwartz (2017-08-14 14:29:13)

ugjka · 2017-08-14 16:11:24

Eschwartz wrote:

FWIW: FS#16702 is the main reason kernel releases, LTS or otherwise, are somewhat annoying. You don't actually need to reboot just because your kernel updated... unless you actually want to take advantage of the updates it brings. You do, however, have to reboot if you want to modprobe any currently-unloaded modules after a kernel update deletes the ones for the running kernel...
Personally, I just stuck `IgnorePkg = linux linux-ck linux-lts` into my pacman.conf and explicitly update the kernel on my laptop right before a planned shutdown/reboot.

also loopback devices stop working after kernel updates, this has hit me personally when I couldn't mount iso files after kernel updates

Arch Linux

#1 2017-08-14 11:08:16

[SOLVED] Automate Pacman Updates on LTS Kernel?

#2 2017-08-14 11:32:04

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

#3 2017-08-14 11:34:28

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

#4 2017-08-14 11:56:11

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

#5 2017-08-14 12:01:06

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

#6 2017-08-14 12:15:21

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

#7 2017-08-14 12:51:15

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

#8 2017-08-14 13:04:27

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

#9 2017-08-14 13:10:00

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

#10 2017-08-14 14:28:54

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

#11 2017-08-14 16:11:24

Re: [SOLVED] Automate Pacman Updates on LTS Kernel?

Board footer