|
Here are my notes on what is different when you move from Red Hat Enterprise Linux (or its clone CentOS) version 5.* to 6.
The order and the logic are completely different.
The network configuration, now near the beginning of the installation, is rather complicated. This reflects Red Hat's rather complicated IP configuration, which includes some oversights (see the IP networking section later). Be careful to de-select Require addressing for this connection to complete for IPv4 and also IPv6 if you use it.
There are more choices about storage, some of it a bit exotic for typical users, but this really adds no additional complexity unless you select the exotic hardware.
If you customize the package selection, watch out! It is very tempting to click the Next button prematurely. That immediately starts an installation process, and the only way to abort it is to power-cycle the machine and start over. If you are using VMware:
The distribution has grown to the point that it no longer fits onto one single-layer DVD. DVD1 is the main installation media, it's 4.0 GB for the RHEL 6 workstation and the single CentOS image. DVD2 is the "optional" media, it's just 1.2 GB. DVD2 for the most part contains the -doc and -devel packages, but it also contains some of the server packages. For example, samba-swat and lpd-cups.
There is no choice about the use of SELinux or the iptables and ip6tables firewall rules. You get them, no matter what.
The Kdump setup seems to always fail unless you have more than 4 GB of RAM. I read that this is a bug, fixed in RHEL 6.1.
The firstboot program that runs on the first boot after the installation insists that you create a user. However, the user creation tool is poorly designed and it does not let you fully control all the attributes of this user. Workaround: Create a dummy user to make it happy, create your real users, and then delete the dummy user.
Red Hat has included drivers that give you the benefits of VMware's VMtools, such as the ability to simply move the mouse out of the VM window without first pressing <Ctrl><Alt>. Do not install VMtools, as that makes things worse instead of better. My experience was that VMtools took away my control of the display settings and recreated the mouse and keyboard focus problem. Just install RHEL or CentOS and enjoy.
The old SVR4 init has been replaced by Upstart. Yes, /sbin/init is still started by the kernel as PID 1 at boot, but its configuration is different. The file /etc/inittab is almost empty and it does very little, instead see the contents of the files /etc/sysconfig/init and all of /etc/init/*.
Due to an error in Red Hat's SELinux policy (faithfully
recreated in CentOS...), while you can boot to single user
mode just fine and become root, you cannot run
the passwd command in that state!
Workaround: Do your single-user rescue boot by
adding this to the kernel parameters in GRUB:
single enabled=no
I read that this has been fixed in RHEL 6.1.
GRUB has a kernel line about twice the length of that in RHEL/CentOS 5.*, many more parameters are passed to the kernel at boot time.
Syslog has been replaced by Rsyslog, now configured by /etc/rsyslog.conf. It seems to be exactly the same configuration as in RHEL/CentOS 5.*, once you get past the new Rsyslog clutter of library specification and so on.
See the complaints in the Installation section above about the insistence on creating a user but not allowing you to fully control all its attributes.
Ext4 is now the default file system, replacing Ext3. Of course, the continuing discussion is that Ext4 is just an interim waypoint on the road to Btrfs.
IDE/PATA disks now appear as /dev/sd?, unlike the /dev/hd? seen in RHEL/CentOS 5.*. And the vmplayer/RHEL combination still requires IDE disks for the initial installation, you cannot install onto VMware SCSI disks.
I saw some instability in the naming of a mixture of IDE/PATA and SCSI disks, at least in my environment of VMware vmplayer with two IDE disks at installation time and three SCSI disks added later. Usually the original two would be sda and sdb, but on occasion they would be sdd and sde. This relates to:
The file system media in /etc/fstab are now defined in terms of UUID, at least for the media you specify during the installation. Of course, you are allowed to do whatever you want for your added storage media. Given the instability of device names that I saw, coupled with the unwieldiness of UUID, I stuck to labeling both file systems and swap areas for anything I added.
Unlike RHEL/CentOS 5.*, you no longer get a double load of IA32 and IA64 binaries and libraries for most packages when you install onto 64-bit hardware. Put another way, you no longer get two lines of output when you type:
rpm -q firefox
and so you no longer have to type this to figure it out:
rpm -q --qf '%{name}.%{arch}\n' firefox
rpmbuild and related tools no longer use /usr/src/redhat/ or similar as their working area. They instead use ~/rpmbuild, meaning that things like building a kernel as root requires an unusually large amount of space on the / partition. That is, unless you do this:
mkdir /usr/src/rpmbuild ln -s /usr/src/rpmbuild ~/rpmbuild
At the lowest level, /etc/modprobe.conf has gone away (see the Kernel section below). The result is that the kernel will detect all your Ethernet interfaces, but you can't easily control which one gets which name.
In more detail, /etc/udev/rules.d/70-persistent-net.rules specifies which device gets called eth0, eth1, and so on, based on the MAC addresses observed and UUIDs assigned during the installation. The problem is that if you use Ghost or simply copy a virtual machine image, you will no longer get any eth0 and the first Ethernet will be called eth1. The system was looking for a very specific device to call eth0, not simply the first one found. Workaround: Remove the definition of eth0 and any other network cards in that file just before the final shutdown before the copy.
At a higher level, Red Hat's new configuration does a very good job of handling what a few people want — situations where wired and wireless networks appear, disappear, and change. But.... Is an operating system costing hundreds to thousands of dollars per CPU socket pair per year going to be used in a notebook carried from coffeeshop to coffeeshop?
Red Hat's NetworkManager service slows down the process to
the point that restarting the networking takes at least
30 seconds.
And while I applaud their attempt to use a netmask length
instead of a literal netmask pattern (e.g., 24
instead of 255.255.255.0), their script logic
bungles the attempt.
You end up with network or broadcast addresses that make
no sense.
Here's what really works.
First:
/etc/init.d/NetworkManager stop
chkconfig NetworkManager off
Then, move /etc/sysconfig/network-scripts/ifcfg-eth0
to /root or similar for archiving, and put what
is really needed, no more and no less, into that file:
IPv4 only:
DEVICE=eth0 ONBOOT=yes BOOTPROTO=none IPADDR=192.168.1.12 NETMASK=255.255.255.0 IPV6INIT=no
IPv4 plus IPv6 autoconfiguration:
DEVICE=eth0 ONBOOT=yes BOOTPROTO=none IPADDR=192.168.1.12 NETMASK=255.255.255.0 IPV6INIT=yes IPV6AUTOCONF=yes
IPv4 plus IPv6 with an explicit IPv6 configuration:
DEVICE=eth0 ONBOOT=yes BOOTPROTO=none IPADDR=192.168.1.12 NETMASK=255.255.255.0 IPV6INIT=yes IPV6AUTOCONF=no IPV6ADDR=2001:1800:1234:90::c8/64 IPV6DEFROUTE=yes
Keep in mind that an IPv6 address is laid out like the following, using my example address above for illustration. Remember that leading zeros can be deleted in each 16-bit block, and one string of consecutive zeros can be collapsed into "::", so the final "::c8" really represents 64 bits:
| 3 bits | 45 bits | 16 bits | 64 bits |
| 001 | global routing prefix | subnet ID | interface ID |
| 2001:1800:1234 | 0090 | 0000:0000:0000:00c8 | |
Meanwhile, the default gateway belongs in the file /etc/sysconfig/network:
NETWORKING=yes HOSTNAME=host.domain.com GATEWAY=192.168.1.254
Recall that you got default packet filtering rules with iptables and ip6tables. The iptables rules are:
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination
The ip6tables rules are:
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all anywhere anywhere state RELATED,ESTABLISHED ACCEPT ipv6-icmp anywhere anywhere ACCEPT all anywhere anywhere ACCEPT tcp anywhere anywhere state NEW tcp dpt:ssh REJECT all anywhere anywhere reject-with icmp6-adm-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all anywhere anywhere reject-with icmp6-adm-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination
See the earlier discussion of the media split into DVD1 and DVD2. If you want samba-swat, lpd-cups, and several other network servers, you will need to get the packages from DVD2.
The file /etc/modprobe.conf has disappeared, the kernel can (supposedly) now detect every device on its own. This means that the Udev daemon is involved in some of the device naming.
In response to the question:
So what should I do if I decide to change SCSI
controllers?
I would suggest backing up all the data, re-installing onto
the new platform, and restoring the data.
If you instead just change the single Ethernet device,
I would suggest editing the file:
/etc/udev/rules.d/70-persistent-net.rules
and removing the eth0 line,
shutting down, swapping the hardware, and bringing it
back up.
If you have multiple Ethernet cards, do the above. If you have two Ethernet devices, you have a 50/50 chance that it will happen to name them the way you prefer. If not, take it down to single-user mode, change the labels of eth0 and eth1 (and possibly more) in that file, and bring it back up.
One mystery took more time and some assistance (thanks, Yves!) to solve. The module files you get at the installation time are about 10% the size of the ones you create when you build your own kernel. Yes, there's an option Optimize for size, but it results in modules about 90%, not 10% the usual size. The answer is that Red Hat and thus CentOS have used strip to discard the symbols. You can get this effect for the loadable module files with this:
find /lib/modules/3.0.0 -name '*.ko' -exec strip -g {} \;
The file command reports those module files as "not stripped". Your initrd file will still be enormous, of course.
I haven't looked into how to do this for building the kernel as a package, but I suppose you might be able to do this:
cd /usr/src/linux
make gconfig
make all
find * -name '*.ko' -exec strip -g {} \;
make modules_install
make install
The script /usr/lib/rpm/brp-strip can be involved, it removes the "not stripped" string from the header. But that doesn't seem like a clean solution.
I don't know why, but Red Hat named their initial ramdisk image file initramfs-release instead of initrd-release. The name doesn't matter, so long as you told GRUB you could name this file anything you wanted. Go ahead, build your own kernel, you'll get a (rather large) initrd-3.* file.
Red Hat has become more ambitious in their use of the NSA Security-Enhanced Linux mechanisms. If you install their product and use it as they direct, it works fine.
However, let's say you add storage, create a file system
there, and move an existing hierarchy into the new
storage area.
This may fail or at least cause trouble.
For example, if you move /var/log, you will find
that root now receives an e-mail message every five
minutes reporting a mysterious failure to access some file.
Or, maybe you copy over a replacement Apache configuration file.
You will find that the Apache httpd process,
even though it runs as root initially,
cannot read its own configuration file.
The fix is something like this:
find /var/www /var/log -exec restorecon -v {} \;
Below are the results of running seinfo on both CentOS 5.6 and RHEL 6:
From CentOS 5.6:
Statistics for policy file: /etc/selinux/targeted/policy/policy.21 Policy Version & Type: v.21 (binary, MLS) Classes: 61 Permissions: 220 Types: 1868 Attributes: 217 Users: 3 Roles: 6 Booleans: 271 Cond. Expr.: 254 Sensitivities: 1 Categories: 1024 Allow: 130713 Neverallow: 0 Auditallow: 42 Dontaudit: 7348 Role allow: 5 Role trans: 0 Type_trans: 2309 Type_change: 0 Type_member: 0 Range_trans: 578 Constraints: 47 Validatetrans: 0 Fs_use: 19 Genfscon: 74 Portcon: 337 Netifcon: 0 Nodecon: 8 Initial SIDs: 27
From RHEL 6:
Statistics for policy file: /etc/selinux/targeted/policy/policy.24 Policy Version & Type: v.24 (binary, mls) Classes: 77 Permissions: 229 Sensitivities: 1 Categories: 1024 Types: 3073 Attributes: 250 Users: 9 Roles: 13 Booleans: 168 Cond. Expr.: 203 Allow: 269649 Neverallow: 0 Auditallow: 44 Dontaudit: 162489 Type_trans: 10914 Type_change: 38 Type_member: 44 Role allow: 20 Role_trans: 241 Range_trans: 2590 Constraints: 64 Validatetrans: 0 Initial SIDs: 27 Fs_use: 22 Genfscon: 82 Portcon: 378 Netifcon: 0 Nodecon: 0 Permissives: 21 Polcap: 2
Finally, you will find that the output of ls -l looks a little different now. There will be a "." after the permission mask, indicating that an SELinux ACL exists for the object:
[root@hostname ~]# ls -l /etc/rsyslog.conf /sbin/rsyslogd -rw-r--r--. 1 root root 2741 May 20 2009 /etc/rsyslog.conf -rwxr-xr-x. 1 root root 344528 Jun 8 2010 /sbin/rsyslogd
|
|
|
|||||||||
|
|||||||||
|
| © Bob Cromwell May 2012. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache. Root password available here, privacy policy here. |
