rpm -i for installing packages -e for removing packages -V for verifying packages installed on the system (-Va verifies all) -q for querying what packages belong to what files (-qf allows you to specify a file to see what package it belongs in) -b for building a package -p to print/display information ===== update RH systems pup (GUI) yum update ----- older systems (RHEL 2.1, 3, or 4) up2date up2date-nox --update (non-interactively) ===== add more disk space to a virtual guest using LVM on RHEL http://kbase.redhat.com/faq/docs/DOC-16811 lvs|grep rhel5.guest rhel5u3.guest vg0 -wi-a- 4.00G lvcreate -L 4G -n rhel5.backup vg0 Logical volume "rhel5.backup" created dd if=/dev/vg0/rhel5.guest of=/dev/vg0/rhel5.backup ----- add 2GB virt. disk lvextend -L +2G /dev/vg0/rhel5.guest Extending logical volume rhel5.guest to 6.00 GB Logical volume rhel5.guest successfully resized start the guest and wait for it to boot. After it boots, remove the old partition and create a new one that starts in the same place as the old one and spans to the new end of the disk: fdisk /dev/xvda Command (m for help): p <---(type "p") Disk /dev/xvda: 6442 MB, 6442450944 bytes 255 heads, 63 sectors/track, 783 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/xvda1 * 1 13 104391 83 Linux /dev/xvda2 14 522 4088542+ 8e Linux LVM Notice that "783 cylinders" is the new end of the disk but the original partition for the physical volume only goes to 522 on /dev/xvda2. The second partition will need be be deleted then recreated from the cylinders 14 to 783. Command (m for help): d <---(type "d") Partition number (1-4): 2 <---(type "2") Command (m for help): n <---(type "n") Command action e extended p primary partition (1-4) p <---(type "p") Partition number (1-4): 2 <---(type "2") First cylinder (14-783, default 14): 14 <---(type "14") Last cylinder or +size or +sizeM or +sizeK (14-783, default 783): 783 <---(type "783") Command (m for help): t <---(type "t") Partition number (1-4): 2 <---(type "2") Hex code (type L to list codes): 8e <---(type "8e") Changed system type of partition 2 to 8e (Linux LVM) Command (m for help): p <---(type "p") Disk /dev/xvda: 6442 MB, 6442450944 bytes 255 heads, 63 sectors/track, 783 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/xvda1 * 1 13 104391 83 Linux /dev/xvda2 14 783 6185025 8e Linux LVM Command (m for help): w <---(type "w") The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 16: Device or resource busy. The kernel still uses the old table. The new table will be used at the next reboot. Syncing disks. guest system will need to be rebooted so the new partition table is read by the kernel. After this the pvresize command will set the new size of the physical volume in LVM. pvresize /dev/xvda2 Physical volume "/dev/xvda2" changed 1 physical volume(s) resized / 0 physical volume(s) not resized You should now see the free space in the volume group using the vgs command under the field VFree: [root@rhel5-guest ~]# vgs VG #PV #LV #SN Attr VSize VFree vg0 1 2 0 wz--n- 5.88G 2.00G Determine what logical volume your root filesystem is located on: [root@rhel5-guest ~]# lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert root vg0 -wi-ao 3.62G swap vg0 -wi-ao 256.00M blkid /dev/mapper/vg0-swap: TYPE="swap" /dev/mapper/vg0-root: UUID="d9623f07-975e-4628-acd8-f6ec67d7afa4" TYPE="ext3" /dev/xvda1: LABEL="/boot" UUID="8d2d783c-b782-409c-b157-40f4f95220b3" TYPE="ext3" /dev/vg0/root: UUID="d9623f07-975e-4628-acd8-f6ec67d7afa4" TYPE="ext3" /dev/vg0/swap: TYPE="swap" The next step will be to extend the logical volume in the guest itself: lvextend -L +2G /dev/vg0/root Extending logical volume root to 5.62 GB Logical volume root successfully resized lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert root vg0 -wi-ao 5.62G swap vg0 -wi-ao 256.00M The final step will be resizing the ext3 filesystem on the logical volume that was just extended: resize2fs /dev/vg0/root resize2fs 1.39 (29-May-2006) Filesystem at /dev/vg0/root is mounted on /; on-line resizing required Performing an on-line resize of /dev/vg0/root to 4558848 (4k) blocks. The filesystem on /dev/vg0/root is now 4558848 blocks long. You should now be able to confirm the new space with the df command: df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg0-root 5.5G 1.9G 3.4G 36% / /dev/xvda1 99M 13M 81M 14% /boot tmpfs 513M 0 513M 0% /dev/shm ===== SCSI rescan the SCSI bus to add or remove a SCSI device without rebooting the computer ----- RHEL 4 and 5 For fibre attached storage, it is necessary to issue a LIP (loop initialization primitive) on the fabric: echo "1" > /sys/class/fc_host/host#/issue_lip Issueing a LIP (above) on Red Hat Enterprise Linux 5 is all that is needed to rescan fibre attached storage. Once the LIP is issued, the bus scan may take a few seconds to complete. For other SCSI attached storage, a rescan should be issued: echo "- - -" > /sys/class/scsi_host/host#/scan Replace the # with the number of the SCSI bus to be rescanned. In addition to re-scanning the entire bus, a specific device can be added or deleted for some ----- RHEL 4 or 5 To remove a single existing device explicitly echo 1 > /sys/block//device/delete ----- RHEL 3 or 4 to add a single device explicitly: echo "scsi add-single-device " > /proc/scsi/scsi to remove a device explicitly: echo "scsi remove-single-device " > /proc/scsi/scsi where are the host, bus, target, and LUN numbers for the device,as reported in /sys (2.6 kernels only) or /proc/scsi/scsi or dmesg. These numbers are sometimes refered to as "Host", "Channel", "Id", and "Lun" in Linux tool output and documentation. ===== software iSCSI target can I use with RHEL 4 http://kbase.redhat.com/faq/docs/DOC-4131 assumptions Updating to a newer version of Red Hat Enterprise Linux is not an option. If it is, refer to the release notes of the newer version for details on iSCSI target support. Limitation: This has only been tested in Red Hat Enterprise Linux 4 and the iscsitarget version 0.4.5. Please note that 0.4.13 will not work with kernels lower than 2.6.10 at the time of writing. Red Hat Enterprise Linux 4 currently does not have any official iSCSI target packages yet. There are third-party software that are known to work although your mileage may vary. One such package is from http://iscsitarget.sourceforge.net . Version 0.4.5 compiles with Red Hat Enterprise Linux 4 kernel 2.6.9-11 without problems. To install, execute the following commands as root: # tar zxvf iscsitarget-0.4.5.tar.gz # cd iscsitarget-0.4.5 # export KERNELSRC=/usr/src/kernels/ # make && make install # cp etc/ietd.conf /etc The configuration file /etc/ietd.conf is a template that you can use. Targets definitions start with "Target" and the target name. The target name must be a globally unique name, the iSCSI standard defines the "iSCSI Qualified Name" as follows: iqn.yyyy-mm.[:identifier] where "yyyy-mm" is the date at which the domain is valid and the identifier is freely selectable. For further details please check the iSCSI spec. Below is a sample: Target iqn.2008-08.com.example:storage.disk2.sys1.xyz IncomingUser joe secret Lun 0 /dev/hdc fileio Alias Test To start the iSCSI target service, execute /etc/init.d/iscsi-target start. The command dmesg should output something similar to this: iSCSI Enterprise Target Software - version 0.4.5 iotype_init(91) register fileio target_param(109) d 1 8192 262144 65536 2 20 8 0 ===== kernel http://kbase.redhat.com/faq/docs/DOC-6039 Kexec is a fastboot mechanism that allows booting a Linux kernel from the context of an already running kernel without going through the BIOS. The BIOS can be very time consuming, especially on big servers with numerous peripherals. This can save a lot of time for developers who end up booting a machine numerous times. Kdump is a new kernel crash dumping mechanism and is very reliable. The crash dump is captured from the context of a freshly booted kernel and not from the context of the crashed kernel. Kdump uses kexec to boot into a second kernel whenever the system crashes. This second kernel, often called a capture kernel, boots with very little memory and captures the dump image. The first kernel reserves a section of memory that the second kernel uses to boot. Be aware that the kdump reserves a significant amount of memory at the boot time, which changes the actual minimum memory requirements of Red Hat Enterprise Linux 5. To compute the actual minimum memory requirements for a system, refer to http://www.redhat.com/rhel/details/limits/ for the listed minimum memory requirements and add the amount of memory used by kdump to determine the actual minimum memory requirements. Kexec enables booting the capture kernel without going through BIOS hence the contents of the first kernel's memory are preserved, which is essentially the kernel crash dump. rpm -q kexec-tools yum install kexec-tools You can configure Kdump to dump directly to a device by using the raw directive in kdump.conf raw devicename raw /dev/sda1 ----- dumping to a file on Disk Kdump can be configured to mount a partition and dump to a file on disk. This is done by specifying the filesystem type, followed by the partition in kdump.conf. The partition may be specified as a device name, a filesystem label, or UUID in the same manner as /etc/fstab. The default directory in which the core will be dumped is /var/crash/%DATE/ where %DATE is the current date at the time of the cash dump. For example: ext3 /dev/sda1 will mount /dev/sda1 as an ext3 device and dump the core to /var/crash/, whereas ext3 LABEL=/boot will mount the device that is ext3 with the label /boot. On most Red Hat Enterprise Linux installations, this will be the /boot directory. The easiest way to find how to specify the device is to look at what you're currently using in /etc/fstab. The default directory in which the core will be dumped is /var/crash/%DATE/ where %DATE is the current date at the time of the crash dump. This can be changed by using the path directive in kdump.conf. For example: ext3 UUID=f15759be-89d4-46c4-9e1d-1b67e5b5da82 path /usr/local/cores will dump the vmcore to /usr/local/cores/ instead of the default /var/crash/ location. ----- dumping to a Network Device using NFS To configure kdump to dump to an NFS mount, edit /etc/kdump.conf and add a line with the following format: net :/nfs/mount net nfs.example.com:/export/vmcores This will dump the vmcore to /export/vmcores/var/crash/[hostname]-[date] on the server nfs.example.com. The client system must have access to write to this mount point. ----- dumping to a Network Device using SSH SSH has the advantage of encrypting network communications while dumping. For this reason this is the best solution when you're required to dump a vmcore across a publicly accessible network such as the Internet or a corporate WAN. net user@ net kdump@crash.example.com In this case, kdump will use scp to connect to the crash.example.com server using the kdump user. It will copy the vmcore to the /var/crash/[host]-[date]/ directory. The kdump user will need the necessary write permissions on the remote server. To make this change take effect, run service kdump propagate which should result in output similar to the following: Generating new ssh keys... done, kdump@crash.example.com's password: /root/.ssh/kdump_id_rsa.pub has been added to ~kdump/.ssh/authorized_keys2 on crash.example.com ----- specifying Page Selection and Compression On large memory systems, it is advisable to both discard pages that are not needed and to compress remaining pages. This is done in kdump.conf with the core_collector command. At this point in them the only fully supported core collector is makedumpfile. The options can be viewed with makedumpfile --help. The -d option specifies which types of pages should be left out. The option is a bit mask, having each page type specified like so: zero pages = 1 cache pages = 2 cache private = 4 user pages = 8 free pages = 16 In general, these pages don't contain relevent information. To set all these flags and leave out these pages, use a value of -d 31. The -c tells makedumpfile to compress the remaining data pages. #core_collector makedumpfile -d 1 # throw out zero pages (containing no data) #core_collector makedumpfile -d 31 # throw out all trival pages #core_collector makedumpfile -c # compress all pages, but leave them all core_collector makedumpfile -d 31 -c # throw out trival pages and compress (recommended) Keep in mind that using the -d and -c options will marginally increase the ammount of time required to gather a cores. ----- adding Boot Parameters Modify some boot parameters to reserve a chunk of memory for the capture kernel. For i386 and x86_64 architectures, edit /etc/grub.conf, and append crashkernel=128M@16M to the end of the kernel line. Note: It may be possible to use less than 128M, but testing with only 64M has proven unreliable. This is an example of /etc/grub.conf with the kdump options added: default=0 timeout=5 splashimage=(hd0,0)/boot/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Client (2.6.17-1.2519.4.21.el5) root (hd0,0) kernel /boot/vmlinuz-2.6.17-1.2519.4.21.el5 ro root=LABEL=/ rhgb quiet crashkernel=128M@16M initrd /boot/initrd-2.6.17-1.2519.4.21.el5.img ----- testing After making the above changes, reboot the system. The 128M of memory (starting 16M into the memory) is left untouched by the normal system, reserved for the capture kernel. Take note that the output of free -m shows 128M less memory than without this parameter, which is expected. Now that the reserved memory region is set up, turn on the kdump init script and start the service: chkconfig kdump on service kdump start This should load the kernel image image via kexec, leaving the system ready to capture a vmcore upon crashing. To test this, force-crash the system using sysrq: echo "c" > /proc/sysrq-trigger This causes the kernel to panic, followed by the system restarting into the kdump kernel. When the boot process gets to the point where it starts the kdump service, the vmcore should be copied out to disk to the location you specified in the /etc/kdump.conf file. NOTE: Console frame-buffers and X are not properly supported. On a system typically run with something like "vga=791" in the kernel config line or with X running, console video will be garbled when a kernel is booted via kexec. Note that the kdump kernel should still be able to create a dump, and when the system reboots, video should be restored to normal. =====