Solution to scp missing on Minimal RHEL6 Install

If you choose the minimal installation of Red Hat Enterprise Linux 6, you do indeed get a minimal install. It's so minimal that things like wget and scp are missing. It's pretty obvious that yum install wget will get you wget but if you want scp:

yum install openssh-clients

Red Hat Enterprise Linux 5 on Dell OptiPlex 990 Initial Impressions

I received a Dell OptiPlex 990 and installed RHEL5 on it. Some preliminary observations:

  • I wanted a RAID 1, so I reached for a trusty 3ware 8006-2LP, which is a 64-bit-capable SATA RAID PCI card that I typically run in a 32-bit PCI slot. But the OptiPlex 990 has placed a heatsink directly behind the PCI slot. The card can't physically fit in the slot because the heatsink is in the way. That led to my next adventure.

  • I've tried several times over the years to run software RAID on OptiPlex systems both with FreeBSD and Linux. Everything would set up fine but under load the computer would reboot and rebuild. I suspect that the SATA controllers on the motherboard were to blame. But I thought hey, this whole Sandy Bridge thing might have improved things -- let's try again. So I put in the Red Hat installer. That led to my next adventure.
  • The onboard Sandy Bridge video is not compatible with the installer. After X tries to start the result is a black screen. Not too surprising, really. Fortunately the installer offers a handy VNC option which worked fine.
  • I created two RAID partitions, mirrored them, and assigned the /boot mountpoint to the mirror. Then I created a large LVM volume group and created logical volumes for the rest of my mountpoints. A brief summary of operations:
Create RAID partition of 100MB on /dev/sda
Create RAID partition of 100MB on /dev/sdb
Create RAID device on /dev/md0 using the above two partitions in RAID1. Mount point is /boot.

Create RAID partition of 80G on /dev/sda2
Create RAID partition of 80G on /dev/sdb2
Create RAID device on /dev/md1 of type LVM physical volume

Click LVM button and create logical volumes for swap, /var/log, and /. Results:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
                       65G  2.3G   59G   4% /
                      9.5G  152M  8.9G   2% /var/log
/dev/md0               99M   13M   82M  14% /boot
tmpfs                 902M     0  902M   0% /dev/shm

Now on to test whether the onboard SATA controllers would fall down. I ran two simultaneous instances of bonnie++, one in /var/bonnie and one in /var/log/bonnie (separate logical volumes, if you've been paying attention and haven't fallen asleep yet). No rebooting. I was impressed.

My final observation: the onboard NIC is an Intel 82579LM which does not seem to have an onboard TCP offload engine. Though the 82577LM does in this matrix so I'm not sure. Let's see what ethtool has to say:

# ethtool -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off

Update 2011-06-15: The 990 is definitely noisier than the 980 or the 7xx series due to fan placement and lack of hooded airflow internally. Also, with RHEL6 and BIOS A03 the OptiPlex 990 will shut down but will hang when restarted. In order for it to reboot cleanly it is necessary to add reboot=pci to the kernel options in /etc/grub.conf.

Nonparsing Apache Log Messages Solved

I set up a new Red Hat Enterprise Linux 5 webserver but the nightly emails from logwatch were complaining about logs not being parsed correctly:

--------------------- httpd Begin ------------------------

This is a listing of log lines that were not parsed correctly.
Perhaps the variable $LogFormat in file conf/services/http.conf
is not correct?

(Only the first ten are printed; there were a total of 188)
   " - - [30/Mar/2011:01:49:18 -0500] "GET /foo/bar/modules/node/node.css HTTP/1.1" 200 678 ""

I looked in /etc/logwatch/conf/services but there was no httpd.conf in there. In fact, there was nothing there, so the speculation by logwatch as to what the problem was was appreciated but not helpful.

Looking more carefully at the log entries, it became apparent that they were all from referrers that were requests over SSL. When I pored over the logging configuration for the virtual hosts on this box, I discovered that the CustomLog directive for the host listening on 443 was very slightly different than the default host; yet they were writing to the same log file.

Making the two CustomLog directives identical fixed the problem. (I also changed the configuration so that https requests were written to a separate file.)


Uptrendhits review

Not really a review, just a statement that I am unlikely to do business with companies that send unsolicited email to my work address, especially if I appear to be subscribed to their "newsletter." Like Uptrendhits did. I also take off a reputation point for each use of multiple exclamation marks!!!



Subscribe to SysArchitects RSS