Slashdot Mirror

I wish I had a spare partition to install this on. The Beta and Preview releases were good, and they seem to be interested in trying a few new things.

The release announcement makes we wonder, though.

Fedora provides an SELinux restricted account that doesn't need a password when running SELinux in enforcing mode. See:
http://magazine.redhat.com/2008/04/17/fedora-9-and-summit-preview-confining-the-user-with-selinux/
http://magazine.redhat.com/2008/07/02/writing-policy-for-confined-selinux-users/
http://danwalsh.livejournal.com/11913.html

Fedora provides an SELinux restricted account that doesn't need a password when running SELinux in enforcing mode. See:
http://magazine.redhat.com/2008/04/17/fedora-9-and-summit-preview-confining-the-user-with-selinux/
http://magazine.redhat.com/2008/07/02/writing-policy-for-confined-selinux-users/
http://danwalsh.livejournal.com/11913.html

It still needs more time. I have played under both ubuntu and rhel 5.3 and run into strange behavior that makes me uncomfortable.

1) Bonnie++ throws errors even on server class hardware that something is wrong when creating and deleting a large number of random files. This is with no errors in the filesystem and everything operating normally. https://www.redhat.com/archives/ext4-beta-list/2009-February/msg00000.html

2) A crash of ubuntu ended up removing *ALL* group and other permission on a laptop drive. Not just those altered within 2 minutes of the crash, but of every single file in the system leading to a system that non-root users could not log into.

Neither of those are acceptable. For now it's still ext3 only until ext4 has had some more time to mature.

Funny you mention Drepper, I just recently read of his altercation with rms..

http://sources.redhat.com/ml/libc-announce/2001/msg00000.html

Specifically, the part starting with "And now for some not so nice things."

"On linux, there is not one note app that can deal with a tree of documents or even import it"

Konqueror, Using Konqueror

Maybe, as odd as it seems, being free hurts Linux. If you invest your hard earned money into something, you're easier convinced to add a little of your spare time on top of it. If it was free and you can't figure it out, throw it away, no loss...

OK. http://www.redhat.com/rhel/desktop/ - Costs from $80 to $339, enjoy!

You have to love his replacement example:

*((char *) mempcpy (dst, src, n)) = '\0';

This bug I haven't seen linked to in the comments in this story yet, but it's another gem.

The ABI is compatible with glibc, this doesn't preclude them from including new functions like strlcpy and strlcat - which again looks like something that Ulrich Drepper doesn't think is a good idea. In fact, the man went so far as to reject the patch, stating that:

This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).

Beside, those who are using strcat or variants deserved to be punished

Fork couldn't have come soon enough!

The ABI is compatible with glibc, this doesn't preclude them from including new functions like strlcpy and strlcat - which again looks like something that Ulrich Drepper doesn't think is a good idea. In fact, the man went so far as to reject the patch, stating that:

This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).

Beside, those who are using strcat or variants deserved to be punished

Fork couldn't have come soon enough!

The ABI is compatible with glibc, this doesn't preclude them from including new functions like strlcpy and strlcat - which again looks like something that Ulrich Drepper doesn't think is a good idea. In fact, the man went so far as to reject the patch, stating that:

This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).

Beside, those who are using strcat or variants deserved to be punished

Fork couldn't have come soon enough!

The guy knows what he is doing, too. If you haven't, I suggest reading his paper:

http://people.redhat.com/drepper/cpumemory.pdf

It's horribly inefficient BSD crap. Get your Drepper quotes right!

I personally enjoy this old classic:

http://sources.redhat.com/ml/libc-announce/2001/msg00000.html

Scroll down to the thanks list, and read below. Not saying who is right or wrong here, but it makes for some funny reading.

If your looking for something similar to Red Hat Network why don't you use the open source version of Red Hat Network, Spacewalk? All the goodness without all the mess.

http://www.redhat.com/spacewalk/

Regarding the CentOS side, you could try func or if you have an oracle installation lying around, spacewalk.

I'd say that it depends on a lot of factors really.

First of all it depends on how mission critical the services that run on that system are considered and what kind of chances you're willing to take that a particular package might break something. The experience and available time of your system administrator also plays a significant role.

There's also the very highly unlikely scenario that a certain update might include "something bad", for example when the update servers are compromised. See Debian's compromises at Debian Investigation Report after Server Compromises from 2003, Debian Server restored after Compromise from 2006, and Fedora's at Infrastructure report, 2008-08-22 UTC 1200.

I currently manage just a single box (combination of a public web server and internal supporting infrastructure) for the company I work at and have it automatically install both security and normal updates.

I personally trust the distro maintainers to properly QA everything that is packaged. Also, I don't think any single system administrator has the experience or knowledge to be able to actually verify whether or not an update is going to be installed without any problems. The best effort one can make is determine whether or not an update is really needed and then keep an eye on the server while the update is being applied.

In the case of security updates it's a no-brainer for me, they need to be applied ASAP. I haven't had the energy to setup a proper monitoring solution and I've never even seen Red Hat Network in action. So if I had to manually verify available updates (or even setup some shell scripts to help me here) it would be just too much effort considering the low mission criticality of the server. If there does happen to be a problem with the server I'll find out about it fast enough then I'll take a peak at the APT log and take it from there.

The .so name of a shared library under Linux encodes not only whether the library has been revised, but also indicates ABI compatibility.

If the library authors know what they are doing, when they release a new version of a library they will set the .so version number (different from the human-targeted source-code version number) to reflect which previous versions of the library the new release is compatible with. As a result, ABI-compatible software does not need to be recompiled.

See, for example, the shared-lib versioning documentation for GNU libtool.

Firefox 3 runs just great on RHEL4. RHEL4 is looking pretty old these days.

In a sense, RHEL4 is not old. Update 7 came out in July 2008 and includes Firefox 3. According to Red Hat's support schedule, RHEL4 left "Production 1" phase just two weeks ago, meaning it will no longer recieve "Software Enhancements".

Red Hat has the resources to make the latest things things work on their distribution without replacing everything. And Firefox 3 didn't work easily in RHEL 4 until Red Hat provided support...

Firefox 3 runs just great on RHEL4. RHEL4 is looking pretty old these days.

In a sense, RHEL4 is not old. Update 7 came out in July 2008 and includes Firefox 3. According to Red Hat's support schedule, RHEL4 left "Production 1" phase just two weeks ago, meaning it will no longer recieve "Software Enhancements".

Red Hat has the resources to make the latest things things work on their distribution without replacing everything. And Firefox 3 didn't work easily in RHEL 4 until Red Hat provided support...

I'd like to set the record straight on your comments about the "other high profile distro" that "let attackers actually sign some rogue packages with their private key". This is verifiably false on all points.

The full description of how this attack took place is available here: https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html

No software vulnerability was exploited. It was a classic case of social engineering. A hacker was able to gain access to an ssh key providing access to the build infrastructure and uploaded a set of modified packages. They were designed to snoop for the passwords necessary to use the signing server. The intrusion was detected and repaired before any infected packages were signed.

Please do at least a trivial amount of homework before throwing about accusations.

The failing of the first distribution was in their insistence upon forking a private copy of the crypto libraries that the community at large refused to even look at, which is why the error went undiscovered for so long. This was a failure of the developers to follow the core tenets of collaborative development, and should serve to prove the effectiveness of community development rather than imply that open-source is somehow less secure.

For the record that high profile distro that let attackers sign some rogue packages recently made a full disclosure of this issue and it seems it wasn't the result of a software vulnerability.

Really, what would Linux skills be? The only things that are really uniform between different Linux distributions are the same elements that are already present in Windows anyway.

Any Linux training would be for a specific distro such as the training provided by Red Hat or Canonical which could encompass a whole wide variety of topics. Here's a list of the courses from Red Hat's training course site: https://www.redhat.com/courses/

Yep, RHEL is 7 years total with 4 years general support and 3 years of extended support, SUSE is 5 years general and 2 years extended.

OSS on Linux often did NOT work. Try playing sound with the original Quake 3 on Linux with a driver that didn't support mmap. Free drivers for hardware often didn't seem to exist or were very fiddly to get going.

For some reason which I have yet to understand, they picked option 2 and ALSA was born.

And that is why your comment was poor criticism and comes off as a rant. Good criticism looks up the reasons WHY people did stuff and then gives feedback on those rather than just guessing. You could have answered back against each of the points mentioned in Cleaning up the Linux Desktop Audio Mess Linux Symposium paper rather than just saying "don't know".

Starting with FreeBSD 4, the kernel did mixing in software if the sound card didn't support it.

Doing audio software mixing in the kernel has been frowned upon in the Linux land for years (to do it really well you want to use floating point). I could be wrong but I believe that Microsoft have moved most of audio mixing out of the kernel with Vista so I do not think this view is as extreme as it used to be.

It may be the old OSS 3 version, that stayed in the kernel for a long time but wasn't really maintained after ALSA became new and exciting.

When you have two implementations people can choose which to maintain. I hear that support for devfs was lower after udev went in...

a lot of systems started shipping with userspace sound daemons

Userspace mixing daemons were happening long before ALSA was shipped by default. esound was definitely shipped back in 1999. Userspace daemons also add support for things like network audio...

There is real, detailed critism of ALSA's flaws on an OSS developer's blog. This is far more useful than what you've posted here.

Now don't get me wrong - there are definite issues with Linux audio and these issues have driven some people away from Linux entirely. However those issues are not the ones you are talking about (my hope is that things are slowly improving too). Most users don't care about program portability (OSX and Windows have different audio APIs after all) - they just want working sound on their system. I don't see OSS being the solution to that...

I am biased here, as I have worked with SELinux for years now, but Red Hat actually have a 4-day training course on SELinux: https://www.redhat.com/courses/rhs429_red_hat_enterprise_selinux_policy_administration/

I am doubly biased as I wrote the first incarnation of the course. (Yes, I am a Red Hat employee. Over 9 years now.)

One of the reasons I like PostgreSQL is it is more like Oracle.

If you're doing a migration from Oracle, especially one that has a lot of pl/sql functions. Here's some good advice for converting pl/sql to pl/pgsql.

Also, going from PostgreSQL to Oracle seems easier as well. With PostgreSQL you can use more Oracle like features so if you need to move to Oracle, you can take advantage of some of it's advanced features instead of migrating simple tables and sql statements.

Sun was actively involved with PostgreSQL before they bought MySQL. I was really dissapointed with their decision, especially at the price.

My guess is they weren't really buying MySQL for the technology, they were buying it for the community. Overnight, a ton of MySQL users and developers were part of Sun's open source community. Building communities takes time and Sun was having a hard time doing it with some of their projects.

All it seems they did though is fund MySQL forks. Kinda messed up for the MySQL developers to do that but we don't know all the details.

$1 billion dollars could have funded a lot of improvements to PostgreSQL better clustering, replication, visual tools, and more. A better PostgreSQL could hurt Oracle more than buying MySQL. After Ellison announced he'd be moving his developers from Solaris workstations to Linux workstations, it could have been a nice comeback.

It also seems that the switch form solaris to linux might not have been developer driven. Even MS knows you have to keep your developers, developers, developers happy.

Memtest86 will find some memory issues, but not all. I find that you have to really stress the memory interface, itself (i.e.: not just typical reads/writes) in order to see truly "interesting" failures...ones that could easily cause "unexplained" lockups, etc. For this sort of thing, I recommend this. This will slam the memory i/f much more than just reads/writes...which is what you really ought to be doing anyway.

2) A prerequisite (and an expensive and hard-to-find one) for ECC memory is having a motherboard/chipset that *supports* ECC memory. Usually this means a server-class motherboard, but Intel usually has at least one high-end desktop motherboard on their line-up with ECC capability.

3) I always buy machines with support for ECC memory on the motherboard/chipset (except notebooks, where it doesn't seem to be an option), and always used ECC memory on them.

That can't possibly be expected behavior. File a bug with your distribution if it's not already known (see the following; I don't know what distro you're using).

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135
http://bugs.debian.org/505097
https://bugzilla.redhat.com/474745
http://pulseaudio.org/wiki/BrokenSoundDrivers

The developers can't possibly have all of the relevant hardware; they need users who run into problems to help them out. Please try to help if you can; it might help the bug get fixed quicker.

Nope, it hasn't changed yet, but they are working on it.

Either RedHat's Marketing department is seriously misleading, or you're seriously mistaken.

. Again, the question isn't whether old existing installations will be supported. It's about RedHat dropping Xen for future installations.

Let me give you this Marketing blurb, since you don't seem to be aware of it: Red Hat Sets Its Virtualization Agenda "Red Hat's strategic direction for the future development of its virtualization product portfolio is based on KVM,

and

"Existing Xen-based deployments will continue to be supported for the full lifetime of Red Hat Enterprise Linux 5, and Red Hat will provide a variety of tools and services to enable customers to migrate from their Red Hat Enterprise Linux 5 Xen deployment to KVM."

Note the words "existing" and RHEL5. No mention about the future except for migrating to KVM.

It's pretty clear that, going forward, if you want to stay with RedHat, you need to move away from Xen.

Sorry, but many people are going to stay with Xen over RedHat. Fortunately there are companies who are willing to accomodate them.

If you have some official news to the contrary, I'd appreciate hearing about. Because right now, people are looking at (and finding) alternatives to Redhat.

Software patents are bad, yet they still exist, and you have to live with that reality. Red Hat is not just filing for defensive patents, it is also pouring resources into patent reform. In an ideal world, software patents would be a non-issue, and Red Hat is at the forefront of making that a reality.

In the current reality, it's impossible for OSS to infringe on Red Hat's patents because of the patent promise which is legally binding and irrevocable. I have no idea what Red Hat's strategy for infringement from non-OSS software is, but it sounds like it's a 'live and let live' attitude. As long as you don't attack Red Hat with your patents, Red Hat won't come after you with theirs. Given reality, that seems an entirely sensible and prudent stance.

http://www.redhat.com/legal/patent_policy.html

These are defensive patents. You have to file them if you're in the US software business, or else risk getting sued for $billions. Read how Red Hat licenses their patent portfolio to all open source projects.

Given the Microsoft-Red Hat deal in February, are we seeing Red Hat's 'Novell Moment?

Quite the contrary, At the time of Novell's "deal" Microsoft also came to Red Hat, who turned it down.

The "deal" you refer to above is simply an open agreement to validate each other's OS's in their respective virtualization environments.

The push for this seemed to come from Red Hat customers who wanted to run Windows Server variants virtualized inside of RHEL.

"Red Hat will validate Windows Server 2003 SP2, Windows 2000 Server SP42, and Windows Server 2008 guests on Red Hat Enterprise virtualization technologies.

Microsoft will validate Red Hat Enterprise Linux 5.2 and 5.3 guests on Windows Server 2008 Hyper-V (all editions) and Microsoft Hyper-V Server 2008."

source: http://truthhappens.redhat.com/2009/02/16/red-hat-and-microsoft-expand-server-virtualization-interoperability/

Novell agreed that Microsoft had a valid claim that Linux infringed Microsoft patents and paid Microsoft for the use of said (unspecified, undisclosed, vaporware) patents.

Red Hat by contrast did not sign a joint agreement with microsoft but set up co-ordinated support for customers who use either Red Hat guest instances on Microsoft servers or Microsoft guests on Red Hat servers. They explicitly " ... have nothing to do with patents, and there are no patent rights or other open source licensing rights implications provided under these agreements. The agreements contain no financial clauses other than test fees for industry-standard certification and validation."

Microsoft realized that they would be frustrating customers if they did not do this. Red Hat realizes the same thing. Neither Microsoft nor Red Hat conceded anything about patents in this relationship.

The difference between the Novell-Microsoft pact and the current story is so vast that the original post is either a troll or a very confused person.

Red Hat's public promise to never use their patents against Free or Open Source Software surely nullifies any such worry? As Red Hat are one of the main contributors to the Open Invention Network I would hope that they will add this patent to the other ones currently mutually held by OIN to defend FLOSS against patent attacks. That would make this worry completely invalid.

Acrobat Reader is the only PDF reader that works with all PDF files. I don't like that fact either.

Here is an example that renders properly only with acroread:

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

you mean spacewalk/satellite http://www.redhat.com/spacewalk/screenshots.html or perhaps func https://fedorahosted.org/func/

Didn't Red Hat put this behind them with this settlement? http://www.press.redhat.com/2008/07/15/a-readers-guide-to-the-firestar-settlement/

What is the good of making a settlement like this that was suppose to protect everybody when the next troll comes along? Red Hat should have not just given in and settled the previous case, because now every other joker with a patent related to ORM will come after them.

The only way data is leaving off that private network is...

And thus there is no way for the worms to get in. Oh, wait. The base was full of worms.

If they can get in, they can get out. An encrypted network is a nice extra, if it is set up correctly and separately. And it can be a useful component in layered security. But it's still just sending around encrypted Windows worms.

I'm not a fan of certification. However, military suppliers are. And here we have at least one wormless system available.

How the worms got onto the military base are only part of the question and only a symptom. They would only be harmless data without a system designed to run the code on sight. At the bottom of it all, someone or group allowed Windows machines to be deployed on the base. There's almost certainly a paper trail that can be followed. When the culprits are found, double-tap to be sure.

Others have already covered the "1000 users isn't much" aspect. Benchmark, and verify what each server can handle of your anticipated load, but they're probably right.

Option 1: Don't do it yourself. Look into renting servers from a hosting company. They will often provide HA and load balancing for free if you get a couple servers. Also, having rented servers makes it much easier to scale. If you find that you have 100,000 uniques per day, you can order up a bunch more servers and meet the load within minutes to hours. If you overbought, you can scale back down just as fast.

Option 2: http://www.linuxvirtualserver.org/ plus http://www.linux-ha.org/ . You use LVS to load balance out to a cluster (including removing failed servers from the pool). You use HA so that two LVS machines can fail over to each other. Note that you can run LVS on the same machines as your load, for a small environment. This is much more DIY than the Windows setup, of course... But honestly, if the setup requirements of this scare you away, then you're not ready to run a fault-tolerant network, regardless of OS.

Option 3: http://www.redhat.com/cluster_suite/ . Less DIY, more money. Perhaps that's better for you.

Option 4: Buy a commercial solution. Every major network vendor sells a HA/LB product. I've used them from most of the big players... I'm not going to write a review here, but it'll suffice to say that while they each have their good and bad points, any of them will get the job you've outlined done.

As for the network: The general rule is to reduce your single points of failures to the minimum you can afford. Common ones are: The ISP (BGP is a pain); the routers (Each ISP goes to its own router); the switches between (you need to full-mesh links from the two routers to two switches, down through the line as many layers as it goes; your switches need to run STP or be layer 3 switches running OSPF or another routing protocol; don't forget to plug the load balancers into different switches); the power (Servers, switches, and routers on separate UPSes such that losing one will leave a fully functioning path); and depending on how far you want to take this, the data center itself (in case of fire/meteor/EPO mishaps).

Note that all of this is required even for your Windows solution. Are you sure you don't want option 1? :)

OSX can only realistically come from one over priced manufactuer

OS X is $106.99.

Vista is $235.95.

Redhat RHEL is $179

Based on fully-featured offerings with cheapest support package.

A lot of non-technical people want to be able to call their vendor when something breaks and have them fix it. This a different market from where Debian, Gentoo, at al fit in.

A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.

Apart from if you want to run the most popular scripting language.

Yeah, you would never have such problems using HP UX or Solaris. Okay, but you won't have problems runnig RedHat

Acrobat Reader is the only PDF reader that works with all PDF files. I don't like that fact either.

Here is an example that renders properly only with acroread:

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

under RHEL that might easily screw up your RH support contract

It's unfortunate that the package was broken, though compiling your own version will not void any service contracts.

See: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-filesystem-fhs.html
/usr/local/, its taken from fhs, which redhat honors.

Also, the standard redhat PATH contains /usr/local/bin before /usr/bin, or even /bin.

A bit of time with the Google reveals Red Hat Enterprise Healthcare Platform which likely is the reason for this being included.

A quick review of the literature shows that several hospital software vendors have been converting their offering to run on a RHL backend.

That's likely where the main open source offerings will appear, replacing mainframes with cheap linux server solutions, and some database apps.

OSS lacks QA - show me a OSS project that government is likely to use that has any quality assurances. the big font stating "use at own risk" is a massive turn off for government and rightly so.

on your home version yes. a customer as big as the uk government? they have bulk licensing terms that ensure security fixes (provided they stay on the upgrade tread mill of course).

funny, because if you wern't trolling you might be aware of these guys:
http://www.redhat.com/products/
http://www.canonical.com/services/support
http://www.novell.com/support/microsites/microsite.do ...

such security fixes could dry up overnight on a OSS project. that's the whole point i'm trying to get through to people, start thinking like you've got 100 million dollar projects relying on this stuff. who are you going to trust this to, some guy called bob on sourceforge, or a multi billion dollar company with resources to get you out of the shit?

Well i know for a fact that a lot of the software government departments use is home* rolled, so if the OSS support for a project did dry up, and for whatver reason there was no major vendor supporting it, they could support it themselves.

*by home rolled i ofc mean they get the lowest bidder to build it.

start thinking like you've got 100 million dollar projects relying on this stuff. who are you going to trust this to, some guy called bob on sourceforge,

hummor me troll, why is a closed patch from some guy at microsoft better than an open patch by some guy at redhat/canonical/novell/sun/etc