From: Etienne Goyer <[EMAIL PROTECTED]> > For what it is worth, Ubuntu also ship with filesystem > encryption available out-of-the-box in the 8.04 installer, > using the latest cryptsetup (the one based on LUKS). > I understand LUKS is the standard, official, way of doing > filesystem encryption at the kernel level, and that most > distribution will converge to it eventually.
I just got into the office, so I could look things up. I'll re-quote someone ... From: http://list.lpi.org/cgi-bin/mailman/private/lpi-examdev/2008-October/001270.html "So it really should be covered, even if RedHat doesn't support it. Debian, Ubuintu and probably Suse (See Peters post) support it out of the box and pretty much any Linux can be made to support it with (almost) whole disk encryption (except for a small boot partition unless you want to boot from CD or other removable media)." People call me a Red Hat apologist and, more recently, a biased Red Hat cronie. But I think my previous responses on my Blackberry really go a long way to the fact that, by default, I do _not_ assume anything about Red Hat. Or, looking at it the other way, a lot of people assume things about Red Hat, negatively, when Red Hat is in the thicket of something. E.g., I know there are FUSE efforts out there as well and -- based on the comment about Red Hat "doesn't support it" -- had assumed Red Hat didn't have the same thing because FUSE isn't in RHEL 5 (or RHEL 4) for that matter. Red Hat has long been behind LVM2-DeviceMapper and bought Sistina when they started to "close up" LVM. I was somewhat familiar with the work, but couldn't remember how it worked with DM off the top-of-my-head. There are a lot of people involved with various Red Hat work, even non-Red Hat employees (or more incognito for various reasons), just like other distros. But, again and by default, I didn't want to assume a poster was incorrect, and wanted to verify this first. Now it goes beyond just ... FROM: http://luks.endorphin.org/staff "My work has not been created in "the void". Kudos to Christophe Saout for creating dm-crypt and the original cryptsetup. Because I not only just checked RHEL 5 (2.6.18 base), GA in 2007: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ But I also noted the pre-LUKS dm-crypt/setup in RHEL 4 (2.6.9 base), GA way back in 2005: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/ Again, it's more than Red Hat not just not something different, but what is even more common, Red Hat provides the underlying facilities in many cases. Indeed I just checked Red Hat's own, Corporate Standard Build (CSB) and several standard client builds and they are using the stock dm-crypt/setup in not just RHEL 5, but RHEL 4, for out-of-the-box setup. Just a few weeks back I made a poor assumption regarding Canonical's release of Ubuntu LTS Server binaries more than 3 years. It was not my place to do so and, while various marketing details are always debatable, that was a direct, incorrect fact I proliferated. We must watch what we say when there is a technical/factual reality at work, and this was a good example as well. Virtually 9 times out of 10, when people say Red Hat does something "different," it actually becomes the standard approach, or the project itself is heavily developed by Red Hat employees (or possibly Fedora associates that are not employees). Heck, a perfect example now is Upstart, even though Red Hat had no less than three (3) other init projects that had been going on for years, Fedora 9 decided that it's best to do what another distro has moved on, as long as it satisfies most (if not all) of the requirements. -- Bryan J Smith Professional, Technical Annoyance [EMAIL PROTECTED] http://www.linkedin.com/in/bjsmith ------------------------------------------------------ I'm a PC, but Linux -- Windows: Life Without Firewalls _______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
