[arch-general] How often kernel26-lts updated?

newer
[arch-general] [signoff] kernel26...

older
[arch-general] Xorg-server 1.10...

David Rosenstrauch

25 Mar 2011 25 Mar '11

3:22 p.m.

Just wondering: what's the general policy about how often (and why) kernel26-lts gets updated? I know it's supposed to be a "long-term supported" kernel, making it more appropriate for servers and such. But it seems like it gets updated almost as often as the main kernel26 package. Also, I saw today that it's currently flagged as out of date. What would be the criteria for it being out of date? Is there some upstream release that the lts kernel follows along with? Thanks, DR

Show replies by date

Cédric Girard

25 Mar 25 Mar

3:38 p.m.

On Fri, Mar 25, 2011 at 4:22 PM, David Rosenstrauch wrote:

...

Just wondering: what's the general policy about how often (and why) kernel26-lts gets updated? I know it's supposed to be a "long-term supported" kernel, making it more appropriate for servers and such. But it seems like it gets updated almost as often as the main kernel26 package. Also, I saw today that it's currently flagged as out of date. What would be the criteria for it being out of date? Is there some upstream release that the lts kernel follows along with?

Thanks,

DR

There are kernel releases marked upstream as "longterm"[1]. The 2.6.32 version currently being used in Arch as lts has been updated on the 24th of March. (2.6.32.35). [1] http://kernel.org/ -- Cédric Girard

Thomas S Hatch

3:42 p.m.

2011/3/25 Cédric Girard

...

On Fri, Mar 25, 2011 at 4:22 PM, David Rosenstrauch
...
wrote:

...
Just wondering: what's the general policy about how often (and why) kernel26-lts gets updated? I know it's supposed to be a "long-term supported" kernel, making it more appropriate for servers and such. But it seems like it gets updated almost as often as the main kernel26 package. Also, I saw today that it's currently flagged as out of date. What would be the criteria for it being out of date? Is there some upstream release that the lts kernel follows along with?

Thanks,

DR

There are kernel releases marked upstream as "longterm"[1]. The 2.6.32 version currently being used in Arch as lts has been updated on the 24th of March. (2.6.32.35).

[1] http://kernel.org/

-- Cédric Girard

So the idea is not that there is a kernel that doesn't get updated, the kernel MUST be updated to reflect security issues, the concept is that there is an older mostly feature frozen kernel available for server use. The reality is that, if you can't reboot your server on a regular basis then you have an architecture issue, which is why I use the latest kernel on my servers and reboot them a lot because using frozen state systems that can't reboot is a high security risk.

David Rosenstrauch

3:48 p.m.

On 03/25/2011 11:42 AM, Thomas S Hatch wrote:

...

2011/3/25 Cédric Girard

...
On Fri, Mar 25, 2011 at 4:22 PM, David Rosenstrauch
...
wrote:

...
Just wondering: what's the general policy about how often (and why) kernel26-lts gets updated? I know it's supposed to be a "long-term supported" kernel, making it more appropriate for servers and such. But it seems like it gets updated almost as often as the main kernel26 package. Also, I saw today that it's currently flagged as out of date. What would be the criteria for it being out of date? Is there some upstream release that the lts kernel follows along with?

Thanks,

DR

There are kernel releases marked upstream as "longterm"[1]. The 2.6.32 version currently being used in Arch as lts has been updated on the 24th of March. (2.6.32.35).

[1] http://kernel.org/

-- Cédric Girard

So the idea is not that there is a kernel that doesn't get updated, the kernel MUST be updated to reflect security issues, the concept is that there is an older mostly feature frozen kernel available for server use. The reality is that, if you can't reboot your server on a regular basis then you have an architecture issue, which is why I use the latest kernel on my servers and reboot them a lot because using frozen state systems that can't reboot is a high security risk.

Thanks for the info Cedric and Thomas. I can (and do) upgrade my kernel and reboot my server, though it would be nice to keep that to a minimum. I guess I had been thinking that an older, LTS kernel would need to get upgraded less frequently, but perhaps this is not realistic. Thanks, DR

Karol Babioch

4:07 p.m.

Am 25.03.2011 16:42, schrieb Thomas S Hatch:

...

which is why I use the latest kernel on my servers and reboot them a lot becaus

As I'm about to set up some new servers I was thinking about this in the past few days. How does it work out for you? Because I don't think that rebooting is an option on servers. If there are running http, mail, dns, etc. service(s) its not that great to reboot the system. Could you elaborate on the point you tried to make? Why is a feature frozen kernel/software a potential security issue? As far as I know major security issues get updated, so you just need to reload the modules, don't you? Or am I missing a point here? Because this is what most long term distributions do. As you don't expect a server to be in desperate need of new features and new supported hardware I personally don't think that the latest kernel is needed. What do the others think about it? Best regards, Karol Babioch

Milos Negovanovic

4:23 p.m.

On Fri, Mar 25, 2011 at 05:07:19PM +0100, Karol Babioch wrote:

...

Am 25.03.2011 16:42, schrieb Thomas S Hatch:

...
which is why I use the latest kernel on my servers and reboot them a lot becaus

As I'm about to set up some new servers I was thinking about this in the past few days. How does it work out for you?

Because I don't think that rebooting is an option on servers. If there are running http, mail, dns, etc. service(s) its not that great to reboot the system.

Could you elaborate on the point you tried to make? Why is a feature frozen kernel/software a potential security issue? As far as I know major security issues get updated, so you just need to reload the modules, don't you? Or am I missing a point here? Because this is what most long term distributions do.

As you don't expect a server to be in desperate need of new features and new supported hardware I personally don't think that the latest kernel is needed.

What do the others think about it?

minimize the reboots++ Regards -- Milos Negovanovic milos.negovanovic@gmail.com

Cédric Girard

4:24 p.m.

On Fri, Mar 25, 2011 at 5:07 PM, Karol Babioch wrote:

...

Am 25.03.2011 16:42, schrieb Thomas S Hatch:

...
which is why I use the latest kernel on my servers and reboot them a lot becaus

As I'm about to set up some new servers I was thinking about this in the past few days. How does it work out for you?

Because I don't think that rebooting is an option on servers. If there are running http, mail, dns, etc. service(s) its not that great to reboot the system.

If your services are only running on one server with no failover (either manual or automatic), you are already vulnerable to such downtimes.

...

Could you elaborate on the point you tried to make? Why is a feature frozen kernel/software a potential security issue? As far as I know major security issues get updated, so you just need to reload the modules, don't you? Or am I missing a point here? Because this is what most long term distributions do.

I'm not sure it was implied by Thomas that frozen features kernel are a security issue. But as new vulnerabilities are being discovered, even on a feature freeze you need to do security updates.

...

As you don't expect a server to be in desperate need of new features and new supported hardware I personally don't think that the latest kernel is needed.

What do the others think about it?

No. But what I understood from what Thomas said is: as you need to reboot your server anyway from time to time to apply security updates, you may decide to switch to an even more often updated kernel, if your architecture permit it (reboot != service interruption). -- Cédric Girard

Milos Negovanovic

4:28 p.m.

On Fri, Mar 25, 2011 at 05:24:37PM +0100, Cédric Girard wrote:

...

No. But what I understood from what Thomas said is: as you need to reboot your server anyway from time to time to apply security updates, you may decide to switch to an even more often updated kernel, if your architecture permit it (reboot != service interruption).

For most people running arch on their servers reboot == service interruption Am I wrong here? -- Milos Negovanovic milos.negovanovic@gmail.com

Cédric Girard

4:34 p.m.

On Fri, Mar 25, 2011 at 5:28 PM, Milos Negovanovic < milos.negovanovic@gmail.com> wrote:

...

On Fri, Mar 25, 2011 at 05:24:37PM +0100, Cédric Girard wrote:

...
No. But what I understood from what Thomas said is: as you need to reboot your server anyway from time to time to apply security updates, you may decide to switch to an even more often updated kernel, if your architecture permit it (reboot != service interruption).

For most people running arch on their servers reboot == service interruption

Am I wrong here?

As I stated in my previous mail, you may have a resilient architecture with a failover for your services. Howerver I can easily understand how this may sound unrealistic in a home server context. -- Cédric Girard

Thomas S Hatch

4:40 p.m.

On Fri, Mar 25, 2011 at 10:28 AM, Milos Negovanovic < milos.negovanovic@gmail.com> wrote:

...

On Fri, Mar 25, 2011 at 05:24:37PM +0100, Cédric Girard wrote:

...
No. But what I understood from what Thomas said is: as you need to reboot your server anyway from time to time to apply security updates, you may decide to switch to an even more often updated kernel, if your architecture permit it (reboot != service interruption).

For most people running arch on their servers reboot == service interruption

Am I wrong here?

-- Milos Negovanovic milos.negovanovic@gmail.com

Arch on a server is a tricky thing, of course creating a viable long term infrastructure architecture is also a tricky thing, the problem is that MANY sys admins adhere to the idea from the 80s, that you set up a server once and then leave it be for years on end. This is no longer possible, and this idea about system management is not only outdated, but very dangerous. So a viable infrastructure requires %100 failover capacity for all services, so that reboots are routine, and never dangerous, in my deployments we reboot systems VERY frequently, often not even into new kernels, but just to continually verify the failover viability. As for a home server, I generally set up a cron job on those to do a pacman -Syu every night, detect if the kernel has changed, and then reboot automatically. No problems with it so for (This is also how my main company build servers work)

C Anthony Risinger

5:05 p.m.

2011/3/25 Cédric Girard :

...

On Fri, Mar 25, 2011 at 5:07 PM, Karol Babioch wrote:

...
As you don't expect a server to be in desperate need of new features and new supported hardware I personally don't think that the latest kernel is needed.

What do the others think about it?

No. But what I understood from what Thomas said is: as you need to reboot your server anyway from time to time to apply security updates, you may decide to switch to an even more often updated kernel, if your architecture permit it (reboot != service interruption).

you could try the ksplice route as it's enterprise level quality at this point -- though for arch you'd have to create/apply the splices yourself. i'll be soon attempting this with our gentoo servers (as much as i like arch ... nope :-) manually; for other distros like redhat/ubuntu there is a tool that can apply them from ksplice.com (only the desktop editions are free ... albeit $3-$5/mo/server is pretty decent) the idea is you compile the running kernel and the destination kernel (the patched version w/security updates/etc), then (IIRC) ksplice analyzes the resultant objects, generating a special module that applies a reversible update to the running kernel in real time. pretty neat :-) C Anthony

4788

Age (days ago)

4788

Last active (days ago)

List overview

Download

10 comments

6 participants

participants (6)

C Anthony Risinger
Cédric Girard
David Rosenstrauch
Karol Babioch
Milos Negovanovic
Thomas S Hatch