Re: [Evergreen] Continuing evergreen with Leap42.2

[Rüdiger Meier]

On 02/23/2017 06:00 PM, Christian Boltz wrote:

Hello,

Am Donnerstag, 23. Februar 2017, 13:46:51 CET schrieb Ruediger Meier:

On Thursday 23 February 2017, Carlos E. R. wrote:

What worries me is that we got 2 kernel updates in a month. Several
updates this month that require a reboot (systemd, apparmor...). Not
good for server uptime.


You DO NOT NEED to reboot after kernel update. Nowadays the old kernel
should be still installed in parallel so module loading still works
without reboot.


Yes, you can always choose to ignore a security update - but that means
that you stay vulnerable. Given that, I prefer a secure system over a
big uptime ;-)


You SHOULD reboot as soon as possible if the kernel update fixes
security bugs _and_ if you have local users which you can't trust. For
example if you run 100 workstations with 1000 users.


"Local" users is relative ;-)

For example, if you run a webserver, and one of the pages allows remote
code execution [1], a local root exploit can easily become a remote root
exploit via that exploitable page.



[1] Are you 100% sure _all_ webhosting customers always run the latest
version of Wordpress, Typo3, Joomla, $whatever, and instantly
upgrade when a security update gets released?
If so, please tell me where I can find such customers ;-)



Of course you are right except that I would call the customers already 
local users. One of them would try out dirty cow for sure even without 
being hacked by someone else :)


cu,
Rudi
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen

Re: [Evergreen] Continuing evergreen with Leap42.2

[Per Jessen]

Ruediger Meier wrote:

> On Tuesday 31 January 2017, Ruediger Meier wrote:
>> On Monday 30 January 2017, Greg Freemyer wrote:
>> > On Mon, Jan 30, 2017 at 11:28 AM, reinhard hennig
>> >
>> >  wrote:
>> > > my administration providing 12.000 Linux clients would appreciate
>> > > continueing evergreen with Leap42.2, because it is planned
>> > > to switch to leap 42.2 (13.2 at the moment) in a couple of
>> > > months.
>> > >
>> > > That would be great.
>> >
>> > I don't know if it is working out, but the fundamental concept of
>> > Leap is that the 42.x series is easy to upgrade between.  In
>> > theory, 42.2 is 42.1 with a major service pack.
>> >
>> > Major changes will be held back until 43.x.
>>
>> That's the theory. In practice seems that any packager/maintainer
>> changes their packages however they want.
>>
>> For example one of my packages (sbcl) was even not building anymore
>> for 42,2 although it was fine for 42.1. I've asked to revert the
>> other incompatible change which broke my package but no chance ...
>> I've had to change my package too otherwise they would have even
>> removed my package from 42.2! Even this was a known issue, avoiding
>> or reverting incompatible changes is obviously not important for
>> Leap.
> 
> ... and it happened again. They upgraded 42.3 to texlive-2016 and it
> breaks again. Evergreen is still needed.

Upgrading 42.1 the other day broke a customer system for me.  


-- 
Per Jessen, Zürich (7.2°C)
http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland.

___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen

Re: [Evergreen] Continuing evergreen with Leap42.2

[Christian Boltz]

Hello,

Am Donnerstag, 23. Februar 2017, 13:46:51 CET schrieb Ruediger Meier:
> On Thursday 23 February 2017, Carlos E. R. wrote:
> > What worries me is that we got 2 kernel updates in a month. Several
> > updates this month that require a reboot (systemd, apparmor...). Not
> > good for server uptime.
> 
> You DO NOT NEED to reboot after kernel update. Nowadays the old kernel
> should be still installed in parallel so module loading still works
> without reboot.

Yes, you can always choose to ignore a security update - but that means 
that you stay vulnerable. Given that, I prefer a secure system over a 
big uptime ;-)

> You SHOULD reboot as soon as possible if the kernel update fixes
> security bugs _and_ if you have local users which you can't trust. For
> example if you run 100 workstations with 1000 users.

"Local" users is relative ;-)

For example, if you run a webserver, and one of the pages allows remote 
code execution [1], a local root exploit can easily become a remote root 
exploit via that exploitable page.


Regards,

Christian Boltz

[1] Are you 100% sure _all_ webhosting customers always run the latest 
version of Wordpress, Typo3, Joomla, $whatever, and instantly 
upgrade when a security update gets released?
If so, please tell me where I can find such customers ;-)

-- 
Es könnte zum Beispiel sein, daß Du inzwischen besser bist als
95% der anderen Teilnehmer hier. Das ist für mindestens 45% der
Leute, die das von sich glauben jedoch nicht der Fall. :-)
[Kristian Koehntopp in suse-linux]

___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen

Re: [Evergreen] Continuing evergreen with Leap42.2

[Christian]

Am 23.02.2017 um 17:13 schrieb Carlos E. R.:
> The point is, one does not expect that many updates in a stable release.
We should not complain about getting updates and sec fixes ... such fast
and without any specific 'Patchday' ...

... or do you prefer to sit and wait for fixes for weeks to get them.
And finally when they should be released the release date is moved to
the next months ... like windows just did.
I think that is a more severe point to complain about.

I am happy the way it is ... and my systems are about 20 to 30 secs
offline on a reboot. That is OK. (for me)

If you need more uptime then you should build cluster ...

-- 

Christian

   https://join.worldcommunitygrid.org?recruiterId=177038

   http://www.sc24.de - Sportbekleidung




signature.asc
Description: OpenPGP digital signature
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen

Re: [Evergreen] Continuing evergreen with Leap42.2

[Steven Caron]

The number of kernel updates depends on the number of significant security 
patches being released.
Dirty Cow, for example, cannot be fixed without a kernel upgrade.

Cheers,


From: Evergreen [mailto:evergreen-boun...@lists.rosenauer.org] On Behalf Of 
Carlos E. R.
Sent: Thursday, February 23, 2017 11:13 AM
To: evergreen@lists.rosenauer.org
Subject: Re: [Evergreen] Continuing evergreen with Leap42.2


NOTICE: This email was received from an EXTERNAL sender


___
Evergreen mailing list
Evergreen@lists.rosenauer.org<mailto:Evergreen@lists.rosenauer.org>
http://lists.rosenauer.org/mailman/listinfo/evergreen
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen

Re: [Evergreen] Continuing evergreen with Leap42.2

[Ruediger Meier]

On Thursday 23 February 2017, Carlos E. R. wrote:
> On 2017-02-23 13:46, Ruediger Meier wrote:
> > On Thursday 23 February 2017, Carlos E. R. wrote:
> >> El 2017-02-22 a las 11:37 +0100, Ruediger Meier escribió:
> >>> ... and it happened again. They upgraded 42.3 to texlive-2016 and
> >>> it breaks again. Evergreen is still needed.
> >>
> >> That will be solved eventually, I hope.
> >>
> >> What worries me is that we got 2 kernel updates in a month.
> >> Several updates this month that require a reboot (systemd,
> >> apparmor...). Not good for server uptime.
> >
> > You DO NOT NEED to reboot after kernel update. Nowadays the old
> > kernel should be still installed in parallel so module loading
> > still works without reboot.
>
> If I do that, then I would simply not apply the update at all. Far
> easier and more stable.


Hm, I never care about updates. I get them automatically everyday and
reboot whenever I want. I think that's more simple. Regarding stability
I don't think it makes any difference whether you install a kernel
update 5 minutes or 5 months before reboot.

BTW very often even the "non-reboot" updates require manually
restarting affected programs. Otherwise you would still use the
old versions too.

For example, below you see all the programs which are still using
vulnerable openssl. The fact that it's still running the old kernel
is my smallest problem ;)

glaukos:~ # uptime
 14:10pm  up 14 days 20:26,  1 user,  load average: 3.34, 3.32, 3.32

glaukos:~ # rpm -qa --last | head
mariadb-10.0.29-18.1.x86_64   Tue 21 Feb 2017 01:00:13 AM CET
mariadb-errormessages-10.0.29-18.1.x86_64 Tue 21 Feb 2017 01:00:11 AM CET
mariadb-client-10.0.29-18.1.x86_64Tue 21 Feb 2017 01:00:11 AM CET
openssl-1.0.2j-4.1.x86_64 Tue 21 Feb 2017 01:00:10 AM CET
libmysqlclient18-10.0.29-18.1.x86_64  Tue 21 Feb 2017 01:00:10 AM CET
expat-2.1.0-19.1.x86_64   Tue 21 Feb 2017 01:00:10 AM CET
libseccomp2-2.3.1-3.1.x86_64  Tue 21 Feb 2017 01:00:09 AM CET
libopenssl1_0_0-1.0.2j-4.1.x86_64 Tue 21 Feb 2017 01:00:09 AM CET
libexpat1-2.1.0-19.1.x86_64   Tue 21 Feb 2017 01:00:09 AM CET
kernel-default-4.4.46-11.1.x86_64 Wed 15 Feb 2017 01:00:13 AM CET

glaukos:~ # uname -r
4.4.36-8-default

glaukos:~ # zypper ps
The following running processes use deleted files:

PID   | PPID | UID  | User   | Command | Service | Files
--+--+--++-+-+
1 | 0| 0| root   | systemd | | 
/usr/lib64/libseccomp.so.2.3.0
  |  |  || | | 
/lib64/libapparmor.so.1.3.0
1077  | 0| 0| root   | systemd | | 
/usr/lib64/libseccomp.so.2.3.0
  |  |  || | | 
/lib64/libapparmor.so.1.3.0
1152  | 1| 499  | messagebus | dbus-daemon | dbus| 
/usr/lib64/libexpat.so.1.6.0
1635  | 1| 492  | nagios | nrpe| nrpe| 
/lib64/libssl.so.1.0.0
  |  |  || | | 
/lib64/libcrypto.so.1.0.0
1636  | 1| 0| root   | sshd| sshd| 
/lib64/libcrypto.so.1.0.0
1721  | 1| 44   | named  | named   | named   | 
/lib64/libcrypto.so.1.0.0
  |  |  || | | 
/usr/lib64/libmysqlclient.so.18.0.0
  |  |  || | | 
/usr/lib64/libxml2.so.2.9.4
  |  |  || | | 
/lib64/libssl.so.1.0.0
1743  | 1| 0| root   | nmbd| nmb | 
/lib64/libssl.so.1.0.0
  |  |  || | | 
/lib64/libcrypto.so.1.0.0
1807  | 1| 0| root   | smbd| smb | 
/lib64/libssl.so.1.0.0
  |  |  || | | 
/lib64/libcrypto.so.1.0.0
1808  | 1807 | 0| root   | smbd| smb | 
/lib64/libssl.so.1.0.0
  |  |  || | | 
/lib64/libcrypto.so.1.0.0
1809  | 1807 | 0| root   | smbd| smb | 
/lib64/libssl.so.1.0.0
  |  |  || | | 
/lib64/libcrypto.so.1.0.0
1855  | 1807 | 0| root   | smbd| smb | 
/lib64/libssl.so.1.0.0
  |  |  || | | 
/lib64/libcrypto.so.1.0.0
2889  | 1| 1000 | rudi   | systemd | | 
/usr/lib64/libseccomp.so.2.3.0
  |  |  || | | 
/lib64/libapparmor.so.1.3.0
2893  | 0| 1000 | rudi   | systemd | | 
/usr/lib64/libseccomp.so.2.3.0
  |  |  || | | 
/lib64/libapparmor.so.1.3.0
14248 | 1807 | 0| root   | smbd| smb | 
/lib64/libssl.so.1.0.0
  |  |  || | | 
/lib64/libcrypto.so.1.0.0

Re: [Evergreen] Continuing evergreen with Leap42.2

[Ruediger Meier]

On Thursday 23 February 2017, Carlos E. R. wrote:
> El 2017-02-22 a las 11:37 +0100, Ruediger Meier escribió:
> >> For example one of my packages (sbcl) was even not building
> >> anymore for 42,2 although it was fine for 42.1. I've asked to
> >> revert the other incompatible change which broke my package but no
> >> chance ... I've had to change my package too otherwise they would
> >> have even removed my package from 42.2! Even this was a known
> >> issue, avoiding or reverting incompatible changes is obviously not
> >> important for Leap.
> >
> > ... and it happened again. They upgraded 42.3 to texlive-2016 and
> > it breaks again. Evergreen is still needed.
>
> That will be solved eventually, I hope.
>
> What worries me is that we got 2 kernel updates in a month. Several
> updates this month that require a reboot (systemd, apparmor...). Not
> good for server uptime.


You DO NOT NEED to reboot after kernel update. Nowadays the old kernel 
should be still installed in parallel so module loading still works 
without reboot.

You SHOULD reboot as soon as possible if the kernel update fixes 
security bugs _and_ if you have local users which you can't trust. For 
example if you run 100 workstations with 1000 users.

cu,
Rudi
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen

Re: [Evergreen] Continuing evergreen with Leap42.2

[Ruediger Meier]

On Monday 30 January 2017, Greg Freemyer wrote:
> On Mon, Jan 30, 2017 at 11:28 AM, reinhard hennig
>
>  wrote:
> > my administration providing 12.000 Linux clients would appreciate
> > continueing evergreen with Leap42.2, because it is planned
> > to switch to leap 42.2 (13.2 at the moment) in a couple of months.
> >
> > That would be great.
>
> I don't know if it is working out, but the fundamental concept of
> Leap is that the 42.x series is easy to upgrade between.  In theory,
> 42.2 is 42.1 with a major service pack.
>
> Major changes will be held back until 43.x.

That's the theory. In practice seems that any packager/maintainer 
changes their packages however they want.

For example one of my packages (sbcl) was even not building anymore for 
42,2 although it was fine for 42.1. I've asked to revert the other 
incompatible change which broke my package but no chance ... I've had 
to change my package too otherwise they would have even removed my 
package from 42.2! Even this was a known issue, avoiding or reverting 
incompatible changes is obviously not important for Leap.

42.2 got a lot upgrades for no reason. Ok, the desktop stuff is always 
f**ked up anyways and I gave up to complain about that, But even things 
like texlive (about 6000 packages) got an update from version 2013 to 
2015. Why? Because just one user asked about that on mailing list ...

> So the need for Evergreen is much reduced with Leap.  Maybe you can
> ask on the main lists if that desire is working out for people.  I
> never had a Leap 42.1 machine and I only have one 42.2 machine, so I
> can't speak to how the concept is working.
>
> I can say I heard very few complaints from people seeing regressions
> when moving from 42.1 to 42.2

Yes it worked quiet good and I have to admit that this time I even liked 
the kernel upgrade, etc. because our hardware (Skylake desktop and 
laptops with intel graphics) was "too new" for 42.1. But I've had 
expected it and had 42,1 only running on a few test machines. The other 
13.1 machines are re-installed directly with 42.2. My users will not 
have to deal with annoying upgrades once per year ...

In general I don't see a major advantage for leap vs the old release 
model. I would be happy to stick with 42.2 for the next years (unless 
somebody stops these random package upgrades in the leap series.)

cu,
Rudi
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen