Slashdot Mirror

Curious enough it were not Linux server systems like RedHat Enterprise who have been vulnerable for almost 5 years, but the popular Linux desktop distro's like Ubuntu.

Wrong. RHEL 5 isn't affected, it uses an old kernel. RHEL 6 is affected: https://bugzilla.redhat.com/sh...

This issue does not affect the versions of the Linux kernel packages as shipped
with Red Hat Enterprise Linux 5.

This issue does affect the versions of the Linux kernel packages as shipped
with Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG 2

Simple, to fully test and develop the patch (see: https://bugzilla.redhat.com/at... ). It's much better if someone who knows of both a problem and has the ability to fix it to sit on the announcement to keep from wider exposure. This helps keep the common knowledge exploitation period to a minimum.

RHEL updates are available:

https://rhn.redhat.com/errata/RHSA-2014-0376.html

CentOS updates are available:

http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html

Fedora updates are available, hitting the mirrors, but you can get it earlier, instructions here:

https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html

https://lists.fedoraproject.org/pipermail/announce/2014-April/003206.html

That's a great way to lose your ACLs and xattrs including SELinux contexts and exe capabilities. The strings "attr" and "selinux" are not present in "man cpio" in RHEL6.

I used cpio on advice to move my installation from an HD to an SSD in Arch and it tossed all my capabilities attributes. Suddenly, ping would only work for root. It also reset the mod times on all my directories (files were preserved).

tar and rsync will do it right, though. In the version of tar from RHEL6, creating an archive:
        --selinux save the SElinux context
        --acl save the ACLs
        --xattrs saves all user/root extended attributes including ACLs and SELinux context
You can output the data from tar to stdout, piping it into another tar command to extract it to a different desitnation. For the extraction, no special switches are necessary to include the extra stuff archived.

In the version of rsync included with RHEL6:
        -A preserves ACLs
        -X preserves extended attributes including SELinux context

Note: I haven't personally verified the results in detail, but I sure as hell know from experience that cpio sucks donkey balls at this point.

Back in ancient history, cpio could copy stuff nothing else could (notably "special" files such as device nodes), but now the opposite is the case. The special files don't really matter any more, with udev and the like building them on demand.

Reference

Bug report for longstanding brain dead state of cpio, completely languishing unacted upon

they plan on moving to something unsupported all the time

Pretty sure Linux isn't unsupported. If you're so inclined, you can pay for support if you want it

Unlike with Windows, you get your pick of providers (and yes, that includes big-name, management-friendly corporations), for any particular aspect/application of Linux.

A bit ungainly, but that's necessary. Redhat tried to make it look neater and ended up with https://bugzilla.redhat.com/sh...

Well CentOS is effectively a RedHat owned project project now http://www.redhat.com/about/ne.... And RedHat has screwed with their source code in order to cause pain to commercial derivatives: http://linux.slashdot.org/stor... so while there is a difference you can't exactly say either company likes 3rd party derivatives.

So why don't NTP servers limit their responses to, say, 1 per 10 seconds per IP address?

You couldn't bother spending 5 minutes reading to learn that the issue only exists on NTP implementations that allow administrative queries, and on modern NTP implementations that's off by default?

By the way, NTP servers CAN be configured with 'discard' and 'restrict limited' statements, to restrict the rate at which clients can query, and send KOD packets if a client is querying too often..

But that's not the DoS amplification issue. The NTP servers need to be configured with NOQUERY by default.

Or the older ancient BSD implementations need to be upgraded to modern ones.

Then please comment on the RHEL bug and emphasize on the need of the original plugins team being provided natively with the 'nagios-plugins' package (and make it a transitional package to 'monitoring-plugins'). https://bugzilla.redhat.com/show_bug.cgi?id=1054340

Except that OSes dont have near that long of a lifespan.

2001 was Linux kernel 2.4 2000 was 2.2. Both have long since been EOL'd If you want to look at a full OS, I think Red Hat Linux 7.2 would be right about the same age as XP; it was EOL'd in December 31, 2003 (source).

Microsoft has gone way beyond what any other OS vendor has ever done, excepting perhaps IBM with some of their ancient AIX boxes.

Repeated from above in case you missed it. Red Hat now offers Python 2.7 and 3.3 via a new mechanism called Software Collections. Other languages (Ruby, PHP, Perl, Node.js) and databases (MySQL, MariaDB, PostgreSQL) too. Read an introduction here: http://developerblog.redhat.com/2013/09/12/rhscl1-ga/ [redhat.com] With Software Collections, you can install different versions of Python (e.g 2.6, 2.7, 3.3) along side each other and avoid collision.

Since you asked. :) Red Hat now offers Python 2.7 and 3.3 via a new mechanism called Software Collections. Other languages (Ruby, PHP, Perl, Node.js) and databases (MySQL, MariaDB, PostgreSQL) too. Read an introduction here: http://developerblog.redhat.com/2013/09/12/rhscl1-ga/ With Software Collections, you can install different versions of Python (e.g 2.6, 2.7, 3.3) along side each other and avoid collision.

Huh? How do you leak their SRPMs which they make available to everyone anyway?

And certainly, you can refuse to take anyone's money... But you can't impose restrictions on them exercising the rights which you are barred from restricting...

Originally, Red Hat Linux was free.

Red Hat Linux is *still* free - just download and install it.

Red Hat charges for *support*.

RHEL is only free as long as all you want is the source. The binary costs money, even if you go with the cheaper "self support" option.

Originally, Red Hat Linux was free.

Red Hat Linux is *still* free - just download and install it.

Red Hat charges for *support*.

Hopefully, from the FAQ

Will this new relationship change the way CentOS obtains Red Hat Enterprise Linux source code?

Yes. Going forward, the source code repository at git.centos.org will replace and obsolete the Red Hat Enterprise Linux source rpms on ftp.redhat.com. Git provides an attractive alternative to ftp because it saves time, reduces human error, and makes it easier for CentOS users to collaborate on and build their own distributions, including those of SIGs.

It looks like yes, from the FAQ

Red Hat has worked with the CentOS Project to establish a merit-based open governance model for the CentOS Project, allowing for greater contribution and participation through increased transparency and access.

I mean interpreting power events twice or having a mysterious corner tap click or breaking simple AT keyboard of various notebooks. I come across glitches like this all the time.

Doesn't CentOS get patches 10 years after release?

Don't be a tool. CentOS "gets" patches by recompiling and redistributing a product whose said patches are delivered via PAID subscription -- exactly the model that would probably need to be used by Microsoft if they continue support. CentOS is a free lunch riding on RedHat. That's part and parcel for the open source movement, but you can't expect a closed source, enterprise company to do the same thing.

Furthermore, even RHEL didn't decide on a 10-year cycle until relatively recently... and for EL3 and EL4, the final 3 years (Extended Life Cycle Support) are an additional charge, and only supported hardware-wise in Virtualized environments.

https://access.redhat.com/site/support/policy/updates/errata/

Citation needed.

I assume you mean about RHEL using systemd.

The RHEL 7 beta is out, and it uses systemd:
https://access.redhat.com/site/discussions/644203

Fedora is an excellent platform for learning systemd, but a beta evaluation of RHEL 7 can be had here:
https://access.redhat.com/site/products/Red_Hat_Enterprise_Linux/Get-Beta

Citation needed.

I assume you mean about RHEL using systemd.

The RHEL 7 beta is out, and it uses systemd:
https://access.redhat.com/site/discussions/644203

Fedora is an excellent platform for learning systemd, but a beta evaluation of RHEL 7 can be had here:
https://access.redhat.com/site/products/Red_Hat_Enterprise_Linux/Get-Beta

hardware fails eventually

Not since Iaas

If my car...

Really? lol

Microsoft should continue to fix their dangerous defects

Dangerous? not really.

dangerously irresponsible.

XP's life time has been extended far beyond what MS originally promised. In the OS world they deserve a a Purple Heart. If a company needed support on an OS, longer than the one MS promised ahead of time, they should have negotiated that directly, or chosen another platform to develop on.

As a Linux reference, see how this is quite explicit: https://access.redhat.com/site/support/policy/updates/errata/
Note: at 13 years, Rhel and windows xp have the same EOL support time.

Passing in registers is not a standard C parameter passing method

There's no such thing as "a standard C parameter passing method". Passing in registers is a perfectly legitimate C parameter passing method, used on several RISC architectures, such as SPARC, MIPS, 32-bit ARM, 64-bit ARM, and 64-bit {PowerPC/Power Architecture} (and probably most other RISC architectures), as well as x86-64 and z/Architecture.

If there are more parameters than fit in the registers available for parameter passing, or if the parameters are in the variable-length portion of the argument list, they might be passed on the stack, and if the called function has no prototype in scope, the compiler might be forced to pass everything on the stack, but, in all other cases, if the ABI supports it, parameters can and will be passed on the stack.

Ask them

You have that exactly backwards. Doing more than one thing is what causes the problem; you have whole packages of related things that have to be turned on just to use the simplest feature. If it was more spread out, then simple things would only need simple services.

What I meant was function X and Y that are needed are in services A and B, so hypothetically them being organized in just one service meant only the overhead of one service. The idea that doing more than one thing as the cause of the problem I think is backwards because, as I was saying, each background service has its own overhead. Many smaller services would just mean that many processes and that much more overhead.

So yeah, if you just shift code around, if you're shifting it into its own service, you change the architecture in a way that makes optimization even possible. Compared to these giant bundles of tightly coupled features.

Except the size of the code per se is not the issue. 99% of the code isn't executed most the time anyways. It's the 1% that every background service needs to function that's sucking up all the CPU time--and more importantly preventing a deep sleep. Shifting code around could possibly move most common functions together (ie a monolithic design), but simply encapsulating more wouldn't help things much because there's still a heavy hierarchy of services which does nothing to cut down on the number of context switches or I/O transfers on tasks.

They aren't going to code their way out of a broken architectural ideology, though.

I wouldn't call it broken, exactly. It's simply not designed with power management in mind. The only way I'd say it's broken is in that tending towards a more user land collection of services to provide basic functions--be it in a microkernel or hybrid design--can tend towards a lot more processes that are vulnerable to timing attacks or authentication attacks. Most of that may be fixable through consistent macro use and boilerplate code. But clearly there's enough debate on the subject to not have a clear consensus on what's best.

pulseaudio is feature-rich. Perhaps a poor choice for some/most people.

I don't think it's merely about being feature-rich. I think it's also a factor that the designers behind it take what might be considered poor choices for the average user. For example, pavucontrol uses low latency monitoring for volume levels. The problem there isn't that low latency is an option but that it's the hard-baked default and recompiling is the only seeming answer around it. In the name of "sensible defaults" and "just works", pulseaudio is obviously in the same sort of boat as Windows designers. But that still seems a poor excuse for the atrocious performance of pulseaudio. :(

A lot of SSDs support SATA Aggessive Link Power Management (ie. SATA powersaving), but has stability issues when it is enabled. To fix this under Linux -

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Power_Management_Guide/ALPM.html

I have no idea how to disable this under Windows, but having turned off ALPM, all of my Sandforce SSDs have been rock solid. Even my Crucial M500 has problems with ALPM on max, I had to turn it down to medium to prevent it from crashing regularly and taking the filesystem with it.

I am genuinely excited at the idea of BTRFs becoming production ready.

Don't hold your breath. I've been watching the btrfs development and it's simply not there yet. A good clue for when it will be considered "production ready" would be when RHEL advertises it as something other then a technical preview. And it's still labeled as experimental in Fedora 19 (released July 2013), even after it was slated to become the default in Fedora 16 (which didn't happen).

So, maybe it makes it in time to be included in RHEL7 as "ready".

Although Red Hat is already talking about RHEL7 since 2012 of last year, and they'll probably be using one of the Fedora releases as their base. So unless btrfs makes it into FC20 or FC21 as "ready", I think they might miss the RHEL7 release.

Trying to sell something that can be got for free is unlikely to be highly profitable.

http://www.redhat.com/ - A $1 billion a year revenue company

Why wouldn't you buy their unlimited guests license at $2k/yr, for your nodes?

http://www.redhat.com/resourcelibrary/articles/articles-red-hat-enterprise-linux-purchasing-guide

You mean like having this :
http://developerblog.redhat.com/2013/01/28/software-collections-on-red-hat-enterprise-linux/
( also, something that Fedora refused to have, so the whole idea of "fedora is a redhat product" is proved a bit wrong )

This might not be a completely fair comparison (I don't know much about RHEL licensing, post corrections as comments), but I believe Windows Server 2012 R2 Datacenter comes with all the bells and whistles up-front. So from here we will configure a RHEL subscription for unlimited virtualization with extra things like load balancing.

The Windows license is perpetual, so we'll use RHEL's 3-year subscription pricing. You'll probably upgrade Windows every 3-5 years.

• Red Hat Enterprise Linux Server Premium (unlimited guests) $9,260/socket pair
• High Availability $1,137/socket pair
• Load Balancing $567/socket pair
• Resilient Storage $2,277/socket pair
• Scalable File System $567/socket pair
• High Performance Network $567/socket pair

Smart Management is $1,642 (without any reference to whether it's per socket pair, so presumably per machine). Let's leave this out because this seems like Microsoft SCCM, which is a different product.

So to cover two sockets with unlimited virtualization rights for three years you're looking at $14,375.

https://www.redhat.com/apps/store/server/

For a 4 socket system, unlimited guests is $4k/year for standard. RHEL guests on top of this host are free.

http://www.redhat.com/products/enterprise-linux/for-ibm-power/

Impressive. You are wrong on just about *everything* you wrote:

>>POWER support is dead on all enterprise Linux distributions, Red Hat dropped support with EL5.
Nope and nope and nope

>>Furthermore OpenPower boxes are contractually prohibited from running AIX.
You are confusing this announcement with a previous attempt at the Linux market that was also called OpenPower. Those systems only ran Linux and could not run AIX. This announcement is about opening up the entire platform and licencing out parts or whole cores of the actual high end chips to companies like Google, who recognize that the single most expensive component in servers is the CPU - and they want choice and customization.

>>You've got a box of hardware with nothing to run on it and it can only deliver half the performance of comparatively priced Intel equipment.
The recently released Power7+ chip running Linux is the fastest thing on the market right now.

>> If you outsource support to IBM, their support specialists in the delivery centers will accidentally nuke your whole frame during routine maintenance, and you could be down for days
Umm..ok I'm stopping now

All patents related to IEEE standards are listed on the IEEE website:

http://standards.ieee.org/about/sasb/patcom/patents.html

Any companies that have essential patents for an IEEE standard are required to disclose them and give letters of assurances that they will license them to users under FRAND conditions. Samsung did do this.

In my opinion, the terms that Samsung offered were not "Reasonable" and were completely out of line compared to all other license fees associated with IEEE standards. Typically these fees are "one time fees per company, often less than $1000.00 USD". I feel that this causes a "chilling effect" with all existing IEEE standards until IEEE defines what exactly "Reasonable" means. (disclaimer: I am technical editor for two IEEE standards)

Of course that in itself can be a huge problem for GPL and any open source implementations - for instance see the patents that Samsung has on Precision Time Protocol ( http://standards.ieee.org/about/sasb/patcom/loa-1588-samsung-12apr2007.pdf ) which were blocking RedHat from releasing ptpd: https://bugzilla.redhat.com/show_bug.cgi?id=556611 - It looks like in this ptpd case, Samsung was reasonable and allows people to do time stamping of packets for free as in GPL.

Regardless of my opinions, ITC said the fees to Apple were reasonable. I guess here the government steps in and says that the fees still stand but the ruling can't block the shipment of devices.

Disclaimer: I work for Red Hat on the Security Response Team and I'm one of the cloud guys so I'm biased (but I also work with OpenStack upstream). I'm also the CVE guy (plug: remember kids, get your CVEs early and life is better for everyone! http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html).

Adding support for this into OpenStack for AWS EC2 is really the wrong layer, this makes a lot more sense in the Orchestration layer. We already have a product that supports this: CloudForms, it can manage systems via OpenStack, RHEV, AWS EC2, etc. referred to as Open Hybrid Cloud/. Another aspect of this is that many customers already have significant investments in virtualization infrastructure, asking them to throw it all out for OpenStack (so all the software, training, backup software, etc.) won't always happen (although many are quite happy to add OpenStack to the mix).

Disclaimer: I work for Red Hat on the Security Response Team and I'm one of the cloud guys so I'm biased (but I also work with OpenStack upstream). I'm also the CVE guy (plug: remember kids, get your CVEs early and life is better for everyone! http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html).

Adding support for this into OpenStack for AWS EC2 is really the wrong layer, this makes a lot more sense in the Orchestration layer. We already have a product that supports this: CloudForms, it can manage systems via OpenStack, RHEV, AWS EC2, etc. referred to as Open Hybrid Cloud/. Another aspect of this is that many customers already have significant investments in virtualization infrastructure, asking them to throw it all out for OpenStack (so all the software, training, backup software, etc.) won't always happen (although many are quite happy to add OpenStack to the mix).

Disclaimer: I work for Red Hat on the Security Response Team and I'm one of the cloud guys so I'm biased (but I also work with OpenStack upstream). I'm also the CVE guy (plug: remember kids, get your CVEs early and life is better for everyone! http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html).

Adding support for this into OpenStack for AWS EC2 is really the wrong layer, this makes a lot more sense in the Orchestration layer. We already have a product that supports this: CloudForms, it can manage systems via OpenStack, RHEV, AWS EC2, etc. referred to as Open Hybrid Cloud/. Another aspect of this is that many customers already have significant investments in virtualization infrastructure, asking them to throw it all out for OpenStack (so all the software, training, backup software, etc.) won't always happen (although many are quite happy to add OpenStack to the mix).

Oh, sorry, I thought we were just talking about the display resolution, didn't realize we were discussing the MBP Retina specifically in terms of that whole system. We do try reasonably hard to make Fedora run as well as possible on Macs, though there is unfortunately a bug in F19 which makes the install a bit harder than it needs to be on Macs:

https://bugzilla.redhat.com/show_bug.cgi?id=979205

It needs a bit more testing to confirm, but it looks like a late change we put in to re-use existing EFI system partitions instead of always creating a new one rather screwed up Macs, and you'll have to use custom partitioning to get a working install on one :/

But aside from that bug we do try to have all the right stuff in place for Mac support, and Fedora is probably one of the better distros for installing on Macs. Nowhere near perfect, but probably one of the better choices.

I haven't looked at this yet, but it seems Redhat has their own spin on things:

http://spacewalk.redhat.com/

It doesn't look as flexible or powerful as puppet, cfengine, etc., but it looks like a start at least.

I think it was a good decision to continue using that name when bugs started to appear, like this bug Fedora 19 bugs cannot be reported because the server side cannot handle the release name "Schrödinger's Cat"

What are activation keys?

Here's a quick reference to activation keys: RHEL Registering with activation keys

Windows XP was released in October of 2001. That's also the same month Red Hat 7.2 was released. I guess you could say that was a good month for operating systems.

You know when Red Hat 7.2 was end-of-lifed? December 2003. Ten years ago.

Oracle still support Java 6 - if you pay through the nose. They just no longer provide free of charge updates to the non-paying public.

Or you can rely on Red Hat doing the same support for free: http://www.theregister.co.uk/2013/03/08/red_hat_openjdk_6_leadership/ http://www.redhat.com/about/news/press-archive/2013/3/red-hat-reinforces-java-commitment
OpenJDK though, but still.

The pacemaker packages have been upgraded to upstream version 1.1.8, which provides a number of bug fixes and enhancements over the previous version. (BZ#768522)

To minimize the difference between the supported cluster stack, Pacemaker should be used in combination with the CMAN manager. Previous versions of Pacemaker allowed to use the Pacemaker plug-in for the Corosync engine. The plug-in is not supported in this environment and will be removed very soon.

They at least warn that Corosync won't start Pacemaker in a future release--that's normal; we have the pacemaker init.d script running it, not the Corosync plug-in. Removing it during release would be a mistake, though.

They don't mention that they've removed crmsh and added PCS. They do give this warning:

With this update, Pacemaker provides a simpler XML output, which allows the users easier parsing and querying of the status of cluster resources.

Status, but not configuration. Nothing about configuration input, which was previosuly handled by crmsh but now is handled by pcs. pcs isn't even installed by default; you have to figure out that you need it, then install it. crmsh is removed by default when you upgrade.

How wonderful that they've been so clear.

"RedHat on the other hand released RHEL 6.4 and removed crmsh, the configuration system for Pacemaker, to be replaced with PCS. This wasn't documented in the release notes, either. Suddenly things that configure high-availability fail-over on RHEL 6 don't work. Running the same tools/scripts/whatnot breaks. This is still RHEL 6 stable, and under Debian policy that's not supposed to happen. RedHat doesn't have such a policy, so it happens."

Well, that's not entirely accurate. Pacemaker is a Technology Preview in RHEL 6. This is a term with a very precise meaning (documented in your support contract and whatknot): https://access.redhat.com/site/solutions/21101 .

"Technology Preview features are currently unsupported, may not be functionally complete, and are not suitable for deployment in production. However, these features are provided to the customer as a courtesy and the primary goal is for the feature to gain wider exposure with the goal of full support in the future."

Given those attributes, it's not generally considered a big deal to change TPs in non-compatible ways in point releases. A change to an actual supported RHEL feature would be a much bigger deal.

You can try openstack on Fedora, or look at RDO ( http://openstack.redhat.com/Main_Page ).

And Fedora is as broken as the community make it broken. If there is no one to make bug reports, triage them, make QA, then yeah, this slip. There is lots of way to help on this part, from giving karma to update testing and testing prerelease.

https://access.redhat.com/support/offerings/techpreview/

What part of "no garantee" is hard to understand ?Seriously, if you cannot spare a system to test, that's not a reason to test it on production when the vendor explictely say "do not do it".

Red Hat and Oracle provide indemnification clauses for their software: http://www.redhat.com/promo/believe/ http://www.oracle.com/us/technologies/linux/ubl-indemnify-066152.pdf I'm sure other vendors do as well.

So, let me rephrase, for mission critical stuff, you install stuff marked as "technology preview" ?
( cf https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.1_Technical_Notes/ar01s03.html ).

You know, the whole TP that is explicitely written as "not to be used in production" from the same documentation :
https://access.redhat.com/support/offerings/techpreview/

So in the end, the vendor say in the release note "do not do this, this may break", and when it break, you just rant because you forgot that part ?