Slashdot Mirror

No, you can't use it all for free. You don't get RHN

Well, you can use the software for free, right? But not the RHN servers, so you are paying for that service along with the support contract? I never really understood what RHN was for when I used RH9 and I've never used a real RHEL box, so it's still a bit mysterious to me. But I'd be surprised if you couldn't get the RHN client software for free, even if you don't get access to the servers at the other end.

, you don't get ZFS,

Do you mean XFS? ZFS is the Solaris FS. AFAIK you can use XFS under CentOS, at least if you enable the extras repo: http://www.pantz.org/software/xfsfilesystem/centos5xfskernelmodule.html You can also use XFS with most other Linux distros, using the same free software.

you don't get RedHat trademarks,

Not really part of the software though ... it shouldn't make a functional difference to what you can do? The trademarks seem to be the main stick that prevents people simply putting RHEL up for free download.

and you don't get built-in compatibility with VMWare and various commercial installers.

If you want / need that couldn't you use CentOS, which is binary compatible with RHEL?

You *can* run more than 4 VM's, supported, with the "server" licenses, not the desktop licenses.

You can use CentOS for many purposes quite effectively, and switch to RHEL when needed. I've done that, and used CentOS for testing setups on non-standard hardware. That's difficult to do with Windows, you need the registered licenses.

The point the RH guy was making to me was that even if you have an unsupported configuration they'll just make you shut down your surplus VMs, rather than just saying "Sorry, not our problem" or crippling the software to limit how many VMs you can start. I think that's an improvement over a number of enterprise suppliers out there! *cough* MS *cough*

On the topic of switching between RHEL and CentOS, I did once read that (for the perverse) it is possible to use yum to crossgrade from one to the other. I wouldn't want to try it, put it like that ;-)

DNS already has this functionality in the form of SRV records, see, e.g. http://www.pantz.org/software/bind/srvdnsrecords.html The problem is, the client software maintainers/vendors have yet to incorporate SRV support into their packages/products.

I believe you'll find this interesting:

http://www.pantz.org/blog/blog-08-2005.shtml

Just follow the instructions to create the big disk.

If you don't like 'wasting' a CD for only 5MB, you can make your own install CD, it isn't that hard. There are a lot of instructions out there, and I've even done it from Windows using Nero (just use the floppy image to make a bootable CD, then add in the rest of the files from the ftp site on the disk, burn, and boot!)

This time, however, I decided to buy the release. I meant to for the past several releases, but this time I got off my ass and actually did it.

OK, I'll indulge you. Why sendmail sucks, in a nutshell:

It was designed before Internet e-mail standards were established. As a result, it contains a general purpose rewriting engine that's Turing complete--the idea was it would be able to be configured to translate addresses between BITNET, UUCP, JANET, ARPAnet, CompuServe, FidoNet, and so on, without recompiling the sendmail binary. This was important because back in the 80s, those networks all had different address formats.

Nowadays the ability to arbitrarily rewrite addresses is completely unnecessary, but Sendmail keeps the old design. This leads to a number of major misfeatures.

1. Sendmail is a pig to configure. The "new improved" sendmail.mc is slightly better than the old sendmail.cf, but still awful compared to the alternatives because it's layered on top of M4, an ancient macro processor. Compare an example postfix config and an example sendmail config. And remember, that's the new .mc file that's compiled into the actual sendmail.cf; if you ever need to do something complex that requires editing the sendmail.cf itself, you'll be faced with something much nastier.

2. Sendmail has a continuing history of poor security. 16 vulnerabilities between 2000 and mid-2006, according to nvd.nist.gov. By comparison, Exim has had 9, Postfix has had 4, Qmail 3.

3. Sendmail has lousy performance. Postfix is 2-4x faster. Take a look at some benchmarks.

4. Sendmail was designed to parse and reconstruct the header of every e-mail going through it. This makes it brittle--give it something it isn't expecting, and the results are unpredictable. This has resulted in Bcc:ed recipients being revealed to each other, unknown header fields being destroyed, and so on. It also makes e-mail forensics difficult--just because the message looked like it had the right addresses when it arrived, didn't mean it had the right addresses when it was sent, if it has passed through sendmail. MTAs should not rewrite e-mail going through them; only e-mail being passed to them directly by a client.

5. It has broken behavior when sending to multiple recipients. For example, if the To: field is missing a comma between two addresses, sendmail will send copies of the e-mail to all the addresses that it can parse, then barf on the broken ones. This is unhelpful, because if the user then re-sends the mail, most people end up getting 2 copies.

So in short: it's broken, it's slow, it's insecure, and it's awkward to configure. There are other open source mailers that have a few of those defects, but sendmail is the only one that has them all. Do a search for "sendmail sucks" and you'll find plenty of people with the same opinion as me.

You really DO need to look harder! Just go to the to the arch directory of your choice under the OpenBSD download directory e.g. http://downloads.planetmirror.com/pub/openbsd/3.8/ i386 Notice the floopy*.fs files? They are floppy images. Looky here: http://www.openbsd.org/faq/faq4.html#MkInsMedia http://www.pantz.org/os/openbsd/makingaopenbsdcd.s html (and I don't even use BSD... well, does OS X count?)

Two ways:

1. Make your own ISO (http://www.pantz.org/os/openbsd/makingaopenbsdcd. shtml)

2. Download an inofficial ISO (http://www.hup.hu/modules.php?name=News&file=arti cle&sid=9953)

Both of these steps should of course be followed by buying at least something from the OpenBSD store at http://www.openbsd.org/orders.html

I've used instructions similar to this to make my own bootable CD for OpenBSD before. These instructions were for OpenBSD 3.4 but they've worked for me for both OpenBSD 3.5 and 3.7. The package names for OpenBSD 3.8 will have a "38" in them rather than 34.

http://www.pantz.org/os/openbsd/makingaopenbsdcd.s html

If you don't like these instructions do a quick Google search or something and you'll probably find a few more URLs showing the same thing.

noexec can be easily circumvented. Read here for more information.

Relevant example:


              alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
              alex@joker:/tmp# ./date
              bash: ./date: Permission denied
              alex@joker:/tmp# /lib/ld-linux.so.2 ./date
              Sun Dec 3 17:49:23 CET 2000