“The wait is almost over. It may have taken two weeks longer than Red Hat would have liked, but Red Hat Enterprise Linux 5, the updated version of the company’s commercial Linux platform, will be launched along with a bevy of new products and services on March 14. The delivery of RHEL 5, the fourth major commercial server release for Red Hat, will better position its Linux against Novell’s SUSE Linux Enterprise Server 10 as well as Windows, Unix, and proprietary platforms.”
It will really be released on the 21st. 😉
Speaking of predications, and as per our exchange from a couple days ago…
It will be released before Etch.
Yes, but Etch will be better.
Yes, but Etch will be better.
Not in the security area. RHEL5 will have all the security features used in Fedora Core 6 -> http://www.awe.com/mark/blog/200701041544.html
I looked at build logs from Debian packages and they do not use FORTIFY_SOURCE, Stack Smashing Protector, network services are not compiled as PIE, etc. Feel free to prove me wrong
PS That wasn’t who voted you down.
I don’t worry about buffer_overflows or PIE compiled network issues. I have a Windows box for that.
I’m sorry for my bias comment, but I have used Debian and other Debian based distos for 5 years now and I am comfortable with the level of security that I have for my network.
Since I don’t run a major computer network for a billion dollar business, maybe I don’t really need RHEL 5. (I couldn’t afford a copy anyway)
Eitherway, Etch will be perfect for me at least when it (someday) is released.
PS. To help your self esteem, I voted you up one.
I honestly don’t know why anyone would run Debian or any derivative on a server *ever*. Note that I am saying this while running an Ubuntu desktop.
Back many years ago, we used to joke and call Redhat “Roothat” because several consecutive releases had some sort of remote root in the default (or close to default) installation. Since then, Redhat has taken security seriously.
Redhat takes security proactively and here are a few examples:
– SELinux Mandatory Access Control Targetted policy by default
– Execshield kernel module to use the hardware NX bit in newer cpus AND help prevent some classes of buffer overflows
– Compiling applications with a special version of gcc using an extension called FORTIFY_SOURCE along with using -fstack-protector
– Hardening the c library its self with canary based stack protection (to prevent buffer overflows)
– PIE aka Position Independent Executables
– ELF data hardening
Redhat devotes some very brilliant people to do nothing more than improve the security of their enterprise distribution. People like Russell Coker, who are trying to include proactive security like SELinux into Debian Etch+1 by default get flamed off of the mailinglists.
It is pretty sad that people don’t care as much about proactive security as Redhat. This is why no personal server of mine will ever run Debian. However, for a nice easy to use “Just Works TM” desktop, Debian derivatives like Ubuntu work great.
Seriously, SeLinux is not the only option on earth to protect your system. Please take a look at RSBAC (used by Mandriva for instance): http://www.rsbac.org/
It’s not like not supporting SeLinux is a proof of unsecure distribution.
I’m not a big fan of Selinux for most common purposes. Unnecessary complexity is not the friend of good security, and Selinux has complexity in abundance.
Just look at how long it took the smart folks developing Fedora to get the policies right. Arguably, they *still* don’t have them quite right.
Of course, for those specialized cases where such fine grained complexity is really needed, it may be a great fit.
But Selinux reminds me of a half joking remark I read about sendmail.cf somewhere a long time ago:
“Most people get their sendmail.cf from God (their distro)… and pray that it just works.”
Edited 2007-03-07 15:21
Agreed. I think SElinux is a very important step in the right direction, but a) so far I haven’t been entirely happy with it, and b) there are a few contenders out there. Hopefully it will continue to mature into something truly usable, much like ipchains did (iptables is very functional, if slightly anti-human in its syntax).
Personally, I’ve been playing with GRSec on a few testing boxen, and so far like it quite a bit – and yes, I understand that GRSec vs. SElinux is apples and oranges…
It would be nice if, by default, up2date didn’t move existing and working configs to rpmsaves, replacing the configs with blank ones. There needs to be a new paradigm descriptor that isn’t “security” which describes the ability for things to break your box. It isn’t a security “issue” for an update to break existing installs silently, but it is a major fscking pain in the ass, and is very, very bad behavior.
Other than that, I’m very happy with red hat.
It would be nice if, by default, up2date didn’t move existing and working configs to rpmsaves, replacing the configs with blank ones.
In up2date –configure –nox, option 18:
Attribute Name: noReplaceConfig
Comment: When selected, no packages that would change configuration data are automatically installed
I think that’s what you’re looking for. Also, most of the time, packages create an ‘.rpmnew’ file with the new config next to the existing config. This is on RHEL4.
I’m aware of the option, but I still don’t think it’s correct behavior, especially when a) the package isn’t upgraded if there is a change planned to a config file, and b) so far I haven’t seen many incremental updates that actually required config files to be changed. No matter what the case is, silently replacing an existing config file with an empty default config is bad behavior. I don’t think this is open to dispute.
However, my main complaint is that it’s the default behavior to allow the system to bork your install rather than to *always* have rpmnew files added to the directory the current running config is in. The fact that this is done silently rather than having a post install “Hi, I had to change this file – please take a look at the changes and make necessary adjustments before restarting the service” message. I have spoken to Red Hat support, and according to two different people I’ve spoken to this is a shortcoming of rpm, not up2date. I don’t care where the shortcoming is, actually, I just think it’s bad behavior, and behavior that should be changed.
In any case, thanks for the heads-up – it is much appreciated.
This seems to be a packaging bug then?
The config files should be tagged %config(noreplace), then you don’t get rpmsaves only rpmnews.
Since I don’t run a major computer network for a billion dollar business, maybe I don’t really need RHEL 5. (I couldn’t afford a copy anyway)
You should give CentOS a shot. It’s RHEL without the the trademark. Most webhosting companies use CentOS these days because it’s arguably the most secure Linux.
hmmmm…..
maybe I will try it on in another month or so. I looked at their website and it does look interesting.
Thanks:)
After almost a year of debating what OS to put on my servers, I finally decided on CentOS. I’m happy with it so far. I also considered FreeBSD, OpenBSD, Debian, Solaris and Unbuntu Server.
The only installation hiccup I’ve had to work with is setting the BIOS properly on the server machines.
One server (Tyan Transport GT24 using the 2891 mobo) has a BIOS setting for OS Type which defaults to Windows and caused CentOS installer to not find the network. My other servers (also Tyan Transport GT24 but using the newer 3992 mobo) all defaulted to P-ATA instead of S-ATA which caused CentOS to not find any harddrives.
Edited 2007-03-08 20:48
“””
It will be released before Etch.
“””
I’ll forego the (nearly) obligatory Duke Nukem Forever remark. 😉
Edit: And just to be clear, I do respect RedHat for holding off a full six months longer than they would have liked in order to get Xen right.
Edited 2007-03-06 17:14
On Dell’s high end workstations you can have RHEL preconfigured and installed.
What I would like to see a comparison between SLED & RHEL releases when it is ready (latest versions) on server/workstation settings.
SLED is designed for Desktops, hence the D (SUSE Linux Enterprise Desktop). For the servers, you install SLES (SUSE Linux Enterprise Server).
Redhat also has a workstation version of RHEL. Since RHEL5 is based off of FC6 with more bugfixes and some stabilization, it will probably make a really good desktop.
Note that Redhat is including software developed by Novell (compiz) by default and have a little applet (desktop-effects) to enable or disable it.
This is what makes open source amazing. Company A, who is a competitor of Company B develops software. Company B decides that it is good and include it in their own products along with improving it. Because of that, Company A (Novell) and Company B (Redhat) have better products.
This is what makes open source amazing. Company A, who is a competitor of Company B develops software. Company B decides that it is good and include it in their own products along with improving it. Because of that, Company A (Novell) and Company B (Redhat) have better products.
Thus demonstrating why yesterday’s rehash of the “Linux is too fractured” argument is still baloney.
“””Thus demonstrating why yesterday’s rehash of the “Linux is too fractured” argument is still baloney.”””
It also exposes all those complaint threads about how Company/Distro/Person X copies from Company/Distro/Person Y as being silly.
So what does that leave, that we talk about regularly here on OSNews, that isn’t silly? 😉
“It may have taken two weeks longer than Red Hat would have liked”
Someone is being ironic here (after the Vista launch).
As Shakespeare might perhaps have said: “Methinks thou does protest too MUCH”!
As Shakespeare might perhaps have said: “Methinks thou does protest too MUCH”!
[archaic english grammar nazi]
Actually, he would have said, “Methinks thou dost protest too much.”
[/archaic]
I’ve been looking forward to this. It’s getting harder to install esp. CentOS onto newer hardware in my experience. A newer kernel will come in handy.
You should not have any trouble installing CentOS on newer hardware. RedHat backports the majority of drivers and support for newer hardware. In fact, RedHat is just about to release RHEL 4.5, which would mean you would be able to install CentOS on the latest hardware when it shortly follows.