This one’s a two-fer! Dan Walsh covers the evolution of SELinux from Fedora 2 all the way to the upcoming Fedora 9 launch. Find out how it started and how user access controls will grow in the newest release. As a bonus, this is also a preview of Walsh’s scheduled talk at the upcoming Red Hat Summit. Want more? Check out the schedule of talks and register–and we’ll see you in Boston.
When SELinux was first developed, the goal was to confine as many system processes as possible to the least amount of privilege required. Fedora 2 was released with SELinux policy that confined users as well as system processes. We quickly realized that SELinux policy was not mature enough to handle a modern mainstream desktop operating system. After a quick redesign of the policy, we created “targeted” policy, replacing the previously named “strict” policy. The goal of targeted policy was to “target” certain processes in the operating system for confinement and leave the rest of the processes “unconfined.” » Read more
Meet Bela Ban, a developer who began the JGroups and JBoss Cache projects. He’s now the technical lead of the JBoss clustering team, continuing the work he began as an college instructor.
Ban talks about the background of both projects, as well as upcoming developments, including increased throughput, persistence, security, remote accessibility, and other features. He also discusses the business needs that can be solved with these tools–just a small sample from his talk at JBoss World.
Note: This article assumes that you are already familiar with Red Hat® Network (RHN) Satellite server and its applications.
Red Hat Network Satellite server allows users to locally host subscribed content from Red Hat Network and custom content in user-managed channels. An example configuration could include a server syncing content updates directly from RHN, while another mission-critical server could be disconnected from the external network, yet still receive updates via manual syncing. In the latter case, these offline servers must be manually updated regularly. Since content updates cannot be synced directly from rhn.redhat.com, RHN Satellite provides two options for our users:
1. Channel dump ISOs hosted on RHN, per Satellite release.
2. RHN-Satellite-Exporter tool running locally on a RHN Satellite server » Read more
No, hardware must meet certain requirements to support full virtualization in Red Hat Enterprise Linux 5. For x86_64-based systems, the processor must support Intel VT-x or AMD-V technology. For Itanium2-based systems, the system must use a Montecito (or newer) processor.
In addition to CPU support, the system BIOS must also support full virtualization. Please contact the system vendor to determine if the BIOS supports full virtualization.
(Note that if this Knowledgebase article was linked from a system listing on the Red Hat Hardware Catalog, the system in question does not support full virtualization.) » Read more
Release Found: Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 4 Update 5
Contributing author: Jonathan Robie
You may have read our background article about ODF and OOXML and why Red Hat believes OOXML should not be approved as an ISO standard. This time, we focus on how the standardization process has been compromised at ISO.
ISO’s JTC-1 directives were designed to provide a fair, consensus-based way to design standards that are portable, interoperable, and adaptable to all languages and cultures. The OOXML proposal has suffered from two basic problems: (1) voting irregularities, and (2) the use of a fast-track process for a complex, new, large specification that has not received adequate industry review. The resulting specification was driven almost exclusively by one vendor, has not achieved industry consensus, and has had thousands of issues logged against it, largely due to issues involving implementability, portability, and interoperability. Although resolutions have been proposed for many of the issues that have been raised, there is virtually no time to review these resolutions to determine whether they fix the problems. And the voting irregularities have raised serious issues with the fairness of the process. » Read more
This is a new feature that has been requested in the Red Hat Enterprise Linux product line. The supported algorithms are DES, MD5, and SHA-256/512. They will be available after the upcoming updates releases as well as in Rawhide. The new algorithms will be configurable via Kickstart only. Here is the correct code. » Read more
In Red Hat Enterprise Linux 5, device-mapper-multipath is installed by default. This is a change from Red Hat Enterprise Linux 4. If a third party multipathing solution is in use, device-mapper-multipath should be disabled to avoid any conflict between multiple multipathing technologies. To disable device-mapper-multipath, turn it off with the following command:
chkconfig multipathd off
In addition, make sure the /etc/sysconfig/mkinitrd/multipath file has the following line:
MULTIPATH=NO
By default, /etc/multipath.conf has all devices blacklisted. If this default configuration has been changed, the change should be reverted. If the devices are not blacklisted, then running the multipath command could cause a conflict with other multipathing software. The /etc/multipath.conf file should contain the following:
# Blacklist all devices by default. Remove this to enable multipathing
# on the default devices.
blacklist {
devnode "*"
}
These steps will ensure that device-mapper-multipath does not conflict with any other multipathing solution in use.