On 05/06/2015 03:04 AM, Jatin Davey wrote:

On 5/6/2015 1:18 PM, Leon Fauster wrote:

...

Am 06.05.2015 um 09:33 schrieb Jatin Davey jashokda@cisco.com:

...

My guest is a CentOS 5.4 VM:

Best practice: update to the latest OS version:

# cat /etc/redhat-release CentOS release 5.11 (Final)

...

[root@localhost ~]# uname -a Linux localhost 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# cat /etc/*release CentOS release 5.4 (Final)

I wanted to know if the virtio drivers on this guest are stable.

Latest kernel package is stable:

# rpm -q kernel kernel-2.6.18-404.el5

...

The reason for asking this question is that i found this link:

http://wiki.libvirt.org/page/Virtio

which states that in order to use the virtio drivers i need to be using the kernel >=2.6.25 , but i am using the kernel version 2.6.18 in my guest VM. I am actually able to use the virtio drivers in my VM even with this kernel version and hence i wanted to know if they are stable to be used.

Did red hat backport these drivers to CentOS 5.4 ? If yes , Can you please point me to any bug to track this backport activity or any announcement of this backport task ? I need that to show to my team so that we can release note this information as part of releasing our product.

Appreciate your help in this regard.

# rpm -q kernel --changelog | grep -i virtio | grep -i backp

• [virtio] console: Backport driver for RHEL 5.6 (Amit Shah) [620037]

-- LF

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Thanks Leon,

I cannot upgrade the OS in the guest as it is being used in production environments and customers would not be comfortable with the entire OS upgrade.

This is the output that i get when i check about the backporting of the virtio drivers.

---

[root@localhost ~]# rpm -q kernel --changelog | grep virtio

• [xen] virtio: do not statically allocate root device (Mark McLoughlin

) [501468]

• [xen] virtio: add PCI device release function (Mark McLoughlin ) [501468]
• [net] virtio_net: mergeable receive buffers (Mark McLoughlin ) [473120]
• [net] virtio_net: jumbo frame support (Mark McLoughlin ) [473114]
• [xen] virtio_net: some relatively minor fixes (Mark McLoughlin ) [468034]
• [xen] virtio: include headers in kernel-headers package (Eduardo

Pereira Habkost ) [446214]

• [xen] virtio: add PV network and block drivers for KVM (Mark

McLoughlin ) [446214]

---

Do you think if i am safe to keep using the virtio drivers within the same kernel ?

Thanks Jatin

So they are comfortable not maintaining security?

If you look at this page .. that install is susceptible to every issue on that page since page 75 (if the other components are also at the same level as that kernel):

https://rhn.redhat.com/errata/rhel-server-errata.html

There are literally 75 pages of updates at 25 updates per page or about 1875 updates to CentOS-5 that are unapplied.

Of those updates, 23 pages (or 575 updates) are security updates.

Just these two alone are worth upgrading for:

https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt

https://isc.sans.edu/forums/diary/Samba+vulnerability+Remote+Code+Execution+...

You have several hundred more Critical or Important security updates outstanding. If that box touches the Internet in any way, it is likely compromised. Just in the last 6 months there are 21 Important or Critical updates.

Thanks, Johnny Hughes

On 05/06/2015 06:04 AM, lhecking@users.sourceforge.net wrote:

...

You have several hundred more Critical or Important security updates outstanding. If that box touches the Internet in any way, it is likely compromised. Just in the last 6 months there are 21 Important or Critical updates.

That is an important qualifier: *If* that box touches the Internet in any way. Although one might add that attacks on the LAN can be nastier since there usually is local access.

While I'm all for keeping machines current, there are production environments where upgrading is a huge pain or outright impossible. Where any upgrades need to undergo a rigorous QA process. Where an outdated environment including equally outdated production tools needs to be maintained, on the chance e.g. that a customer return requires reworking an old part. I would consider it part of list etiquette to not second-guess those who for one reason or another make a conscious decision to stick to a particular environent.

I will no doubt be told that CentOS 5.4 = CentOS 5.11 = CentOS 5, ie. the same OS, but this is not strictly true. For example, it would appear that autofs breakage and performance loss is at a minimum in 5.4.

There :)

Its your box and your job ... so :)

Leon Fauster wrote:

Am 06.05.2015 um 13:04 schrieb lhecking@users.sourceforge.net:

...

...

You have several hundred more Critical or Important security updates outstanding. If that box touches the Internet in any way, it is likely compromised. Just in the last 6 months there are 21 Important or Critical updates.

<snip>

...

While I'm all for keeping machines current, there are production environments where upgrading is a huge pain or outright impossible.

updating vs upgrading?

and such "impossible" cases are rare compared to the majority of EL OS installations. Saying that because the implicitness should be systems in a current state and not contrariwise.

...

Where any upgrades need to undergo a rigorous QA process.

the solution: automation

And a) the manager who made the decision to not upgrade needs to be made aware of a) the dangers of *not* upgrading; b) the minimal risks up an upgrade (security & bugfixes), and c) needs to stop coming up with impossible schedules and put time into that least sexy thing of all, maintenance of infrastructure.

And I, personally, would want an email from aforesaid manager telling me not to do any upgrades, which I would print out in several copies and put in a secure place.... <snip>

mark "CYA"

On Wed, May 6, 2015 9:28 am, lhecking@users.sourceforge.net wrote:

...

And I, personally, would want an email from aforesaid manager telling me not to do any upgrades, which I would print out in several copies and put in a secure place....

<snip>

You do not understand the situation I presented. This is about avoiding a situation where in a highly complex envirnoment, due to a quirk in one of the dozens of tools involved in designing your product, the product suddenly changes because libc was updated to a newer rev. So you keep your design environment static - all parts of it. We're talking business process here, not some stand-alone, uninformed PHB decision.

I can understand you - on a smaller scale...

<rant>

I have a couple of boxes with NVIDIA cards and fancy screen setup. I have to use NVIDIA proprietary driver, open source driver does not support configuration. Darn Nvidia never released enough information about their chip's internals for open source developers to be able to write more versatile driver. I hate Nvidia for that. I love their competitor ATI: not only open source driver is way better, their proprietary drivers are consistently less buggy, and the same can be said about chips, at least I've never seen artifacts on ATI cards, I've seen artifacts on NVIDIA based cards a few times.

Now, back to my boxes. NVIDIA declared these fancy cards obsolete (the are only about 6 years old, and hardware still does appropriate job for what we need). There is no proprietary NVIDIA driver which you can install with latest kernels (latest speaking CentOS 6 kernels). You know you have to compile kernel interface for their binary driver. No way: no updated binary driver for these my obsoleted by NVIDIA cards. So, NVIDIA locked me on these boxes to older kernel.

So, how would you like this company after that!?

</rant>

Valeri

++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

On Wed, May 6, 2015 at 8:20 AM, m.roth@5-cent.us wrote:

Valeri Galtsev wrote:

...

Now, back to my boxes. NVIDIA declared these fancy cards obsolete (the are only about 6 years old, and hardware still does appropriate job for what we need). There is no proprietary NVIDIA driver which you can install with latest kernels (latest speaking CentOS 6 kernels). You know you have to compile kernel interface for their binary driver. No way: no updated binary driver for these my obsoleted by NVIDIA cards. So, NVIDIA locked me on these boxes to older kernel.

There is a proprietary driver package that you can build that will support them. I have a Guadro 4000 aka GL100GL on my workstation, and am running 6.6 current, and NVIDIA-Linux-x86_64-310.40.run, which you can still d/l from NVida's site, for it (I need the proprietary for two screens).

I highly recommend that you install nvidia-detect [1] from ELRepo and run it.

Akemi

[1] http://elrepo.org/tiki/nvidia-detect

Thanks, Akemi, that's really useful, and I'd never heard of it. I suppose that as it gets updated, it'll tell me the most current legacy to use (in my case, the 310.40 worked, but the 340.58 did not... and that was trial and error.

It's all in the README that comes with the driver ... once upon a time, I wrote a script to extract driver info for the installed card (not on CentOS), but nvidia-detect is arguably better.

Am 06.05.2015 um 16:28 schrieb lhecking@users.sourceforge.net:

...

And I, personally, would want an email from aforesaid manager telling me not to do any upgrades, which I would print out in several copies and put in a secure place....

<snip>

You do not understand the situation I presented. This is about avoiding a situation where in a highly complex envirnoment, due to a quirk in one of the dozens of tools involved in designing your product, the product suddenly changes because libc was updated to a newer rev. So you keep your design environment static - all parts of it. We're talking business process here, not some stand-alone, uninformed PHB decision.

I am on your site - but this approach (your word, static) is also a goal of an enterprise operation system. So, your argument is valid but rare in the above example (libc breakage, enterprise context).

-- LF