This should have been a simple task. But like everything else with Linux, there are always many things that can go wrong.
First of all, the DVD drive in the HP Proliant DL380 G5 only liked certain types of DVD+R media. I spent a day trying to boot up CentOS 5.5 installation DVD using different DVD+R media with various options, and finally succeeded on one.
Because we use a RAID controller, we needed to install an HP driver. This was easy. I copied the “cpq_cciss-3.6.26-5.rhel5.x86_64.dd” driver onto an USB drive, and plugged it into an USB port on the server once we got to the CentOS 5.5 setup screen.
I then hit F2 to get to the Options screen, entered “linux dd”, and then hit enter to continue. At some point the CentOS 5.5 setup program prompted me for a driver disk. I selected “yes”, and then selected “sda” for the USB drive. I then browsed for the RAID controller driver on the USB drive. I select the driver file, and then continued.
When the time comes for you to select drives for installation, the USB drive is selected by default. Unselect it, unless you really want to use it for your installation.
I cleared the check box in front of the USB drive “sda”, then continued. It was eventless until I got to the step for application selections.
First Problem
If you check the “Extra” applications check box, you will have to start all over again because the setup program just panics and reboots the machine. If you leave it unchecked, you get to finish the installation.
Success? Not yet.
Second Problem
After the installation, I had GRUB problems. I tried updating it with the USB drive unplugged, that did not fix the problem. Someone on the internet suggested that we should unplug the USB drive after language selection. That did not work for me, as the setup complained that the USB drive was missing. You can unplug it later and see if that helps, but I would rather not spend the time. I booted up the CentOS 5.5 Setup DVD, and entered “linux rescue”.
Once I got to the command prompt, I entered “chroot /mnt/sysimage”. Then I ran “mount” to see where the root “/” was. It was at /dev/VolGroup01/LogVol00. On the two different installation attempts, this path was set to different values.
I opened /boot/grub/grub.conf with vi, and it had /dev/VolGroup01/LogVol00 listed under “title CentOS (2.6.18-194.el5)”. But it started with “root (hd1,0). That was wrong. So I changed it to (hd0,0). The splash image was set under (hd1,0) as well. I corrected that. I then opened /boot/grub/device.map, and changed it so that there was only one device in it: (hd0) /dev/VolGroup01/LogVol00.
Reboot. You will see the message “Memory for crash kernel (0x to 0x) not within permissible range!” when it first comes up. Ignore it. It is mentioned in CentOS 5.1 (not 5.5) release note. It will go away on its own next time.
Third Problem
We needed to install the HP PSP. I following instructions at
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1436465
The instructions on this page are great. However, it does not cover any errors that one may encounter. On the first install, I installed all CentOS 5.5 updates and then proceed with the HP PSP install. The server would reboot itself every time “hp-health” started. On the second attempt, I installed HP PSP before the CentOS 5.5 updates. First I ran into the problem that the links to the kernel build source directory were going nowhere. Apparently one of the links was a typo since the link was off from the right target by a “../”. So I corrected it. Then every time when “hp-health” started, I got the error “insmod: error inserting ‘/opt/hp/hp-OpenIPMI/bin/2.6.18-194.el5/impi_devintf.ko’: –1 Unknown symbol in module”, “hp-OpenIPMI: Not able to start ipmi_devintf.ko”.
My solution to this problem was to install all of the CentOS 5.5 updates, and then install HP PSP 8.25. Before restarting the server, I renamed the directory "/opt/hp/hp-OpenIPMI/bin/2.6.18-194.32.1.el5" to "/opt/hp/hp-OpenIPMI/bin/2.6.18-194.32.1.el5.bak". Then I created a link "2.6.18-194.32.1.el5" in "/opt/hp/hp-OpenIPMI/bin" that pointed to "/lib/modules/2.6.18-194.32.1.el5"/kernel/drivers/char/ipmi". This is a little less efficient than the HP IPMI driver if it worked, but it does everything the HP IPMI driver does. A visit to the "HP System Mamangement Homepage at "http://localhost:2381" proves that.
Wait, there was one more thing. The array configuration utility did not come up automatically. On the "HP System Mamangement Homepage" when I clicked on the "Array Configuration Utility" link it showed a blank page.
To fix that, I created a startup script for the "Array Configuration Utility" called "cpqacuxed" in "/etc/init.d":
#!/bin/sh
# HP Array Configuration Utility
#
# chkconfig: 2 99 99
# description: HP Array Configuration Utility for remote access
#
case "$1" in
start)
echo -n "Starting cpqacuxed"
/usr/sbin/cpqacuxe -R
echo "."
;;
stop)
echo -n "Stopping cpqacuxed"
/usr/sbin/cpqacuxe -stop
echo "."
;;
*)
echo "Usage: /sbin/service cpqacuxed {startstop}"
exit 1
esac
exit 0
I then installed the script by running "chkconfig --add cpqacuxed".
After a restart, everything on the "HP System Mamangement Homepage at "http://localhost:2381" works.
Forth Problem
Step 8a says that after running "audit2allow -a -M mysemanage", we should run "semodule -i mysemanage.pp". I ran it, and it returned errors: " libsepol.link_modules: Tried to link in a non-MLS module with an MLS base.", "libsemanage.semanage_link_sandbox: Link packages failed", and just in case I had doubts, "semodule: Failed!"
A little googling around yielded the following solution: run "checkmodule -m -M -o mysemanage.mod *.te", "semodule_package -o mysemanage.pp -m *.mod", and then "semodule -i mysemodule.pp". That did not return any errors.
Fifth Problem
Enabling Samba. The information provided at
http://wiki.samba.org/index.php/Samba_&_Active_Directory is excellent. But it had problems, too. I got to the step for "net ads testjoin", and it returned "ads_connect: No logon server". This is ridiculous since the "kinit" command succeeded just fine. So I tried "net ads join -S
-U Administrator". That prompted me for a password, and it worked. Then the "wbinfo -u" command did not work. A restart of the "winbind" service fixed that. By the way, the "winbind" service on CentOS 5.5 does not have a letter "d" at the end of its name. The article mentioned that "libnss_winbind.*" must be present in the system /lib directory. But my CentOS 5.5 is 64 bit, and the directory name is /lib64, and it does not have all of the libraries. Some of the library files are in /usr/lib64. But that did not really matter, as it turned out.
So now our Windows domain users can all login to this CentOS box.
Sixth Problem
Enabling XDMCP remote access. This server is behind a firewall, so I wanted to give internal users remote desktop access. Enabling XDMCP is never easy, and on CentOS 5.5 is even more so. The information provided on CentOS' website for setting up gdm is no longer valid. The configuration file is not at its usual place, nor with its usual name. Instead of placing it inside "/etc/X11/gdm", it is now in just "/etc/gdm". Instead of using the name "gdm.conf", CentOS now calls it "custom.conf". Instead of uncommenting "DisplayManager.requestPort" and changing it to 177, it is now in the security section, and the setting is "DisallowTCP=true". I changed it to "DisallowTCP=false". Enabling XDMCP now also requires that we set "Enable=true" in the "xdmcp" section.
XDMCP is a pain even without these problems. I opened a bunch of ports on the CentOS 5.5 box: UDP 177, and TCP 7100 for the X font server. Not only that, the remote user's machine needs to be opened up as well, such as TCP ports 6000-6005. But after that, remote X servers work fine.