When installing RHEL 5, it doesn’t matter if you deselect all the packages during the installation. You’ll still end with the @dialup and @java groups.
If you do a kickstart installation, you can set your %packages to
This also might save you the disks changes (all or some). This will result with about 900+ MB for / (not including /boot). If you want something even more minimal (e.g. only for firewall) you can choose the “%packages –nobase” option.
Mark J Cox, the Director of the Red Hat Security Response Team, published an update to RHEL 4 risk report:
Red Hat® Enterprise Linux® 4 was released on February 15th, 2005. This report takes a look at the state of security for the first three years from
Two of the lines in the conclusion are:
A default installation of Enterprise Linux 4 AS was vulnerable to seven critical security issues over the first three years.
A customised installation of Enterprise Linux 4, selecting every package, would have been vulnerable to 76 critical browser security issues, and 11 in non-browser packages in the three years.
But I doubt how many people use the default installation “as is” or are fulish enough in install everything. I would like to know the security effect of RHEL4 minimal installation, as this my way to install RHEL.
It will also be interesting to see similar reports from other distributions, especially on the response times, as I guess most security issues are common anyway due to shared applications.
I decided to test RHEL 5.1 to check what changed since RHEL 4. As I usually do a network installation, I had a few surprises.
The installation was done with qemu (with kqemu module) on an AMD Athlon(tm) XP 1800+ processor. The virtual ram was set to 256MB. The installation was done an an LVM LV, and took 25 minutes (pretty good I believe).
I tried to do a minimal installation, so I deselected all the available packages from the list. I ended up with 366 rpms and 935 MB on the disk (excluding /boot).
Look back in the anaconda-ks.cfg seems like that not the minimal installation as this is the %packages section:
I couldn’t find on the CDs a file to explain each of the groups here. The manuals talk about comps.xml for this info, but there is no such file on the 5 CDs. Such files are available for the extra software on the CDs like the cluster / virtualization software.
I also was surprised to see that I needed 3 CDs for the minimal installation. Although cd #2 was needed only for:
and cd #3 only for:
I guess these could easily be moved to the first CD and save people the CD changes which wastes time while babysitting the installation instead of doing it completely unattended. Also, seems like by removed the @dialup and @java groups we can be satisfied with only the #1 CD.
This also brought to my attention the method red hat choose on which CD each RPM will be placed. I’m sure doing a popularity contest like Debian is hard for a commercial distribution, but still knowing the method behind the CDs will be useful.
Generaly speaking, the installation went fine. I can start testing the system itself. about testing the
Yesterday I wanted to extend an existing LVM VG with some central storage disks. In the process, I notice the VG is built upon local & external disk, which isn’t according to my standards.
So I decided to extend the VG with the external disks, and then use pvmove command to move all the PE from the internal disk before reducing the VG. The problem is, that on RHEL 4.4, the pvmove command hangs during it’s work, never returns to the prompt, and locks all the other LVM commands.
Seems that for little amounts of PEs the command works, but for 10G disks it hangs. As nothing else helped, I was forced to hard boot the server using to power button. Running the command in single user also doesn’t effect the result, although non other user/services are running.
RHEL 4.4 has LVM2 version 2.02.06, RHEL 4.5 has version 2.02.21 and RHEL 4.6 has version 2.02.27. Reading upstream’s changelog seems there isn’t any change regarding pvmove, although it’s still worth testing if upgrade helps.
Version 2.02.29 has “Refactor pvmove allocation code” in its changelog, but it will take time before this version will be officially available for RHEL (fedora 8 only has 2.02.28). Hoepfully it will solve the problem, as my HP-UX colleagues are laughing on my expense… And that I have to invest more time in mimicking pvmove work manually.