Extend swap space with LVM

Need more swap space for your applications to use? Here's how to extend a swap setup as a logical volume:

1) Determine the name of the swap logical volume using the "lvs" command:
$ lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
root_lv volgroup0 -wi-ao 7.00G
swap_lv1 volgroup0 -wi-ao 30.00G
tmp_lv volgroup0 -wi-ao 3.00G
usr_lv volgroup0 -wi-ao 7.00G
var_lv volgroup0 -wi-ao 4.00G

2) Turn off the swap partition:
$ swapoff /dev/volgroup0/swap_lv1

3) Resize the swap partition, adding 15GB more space to it:
$ lvresize -L+15G /dev/volgroup0/swap_lv1
Extending logical volume swap_lv1 to 30.00 GB
Logical volume swap_lv1 successfully resized

4) Format the new swap space to make it usable:
$ mkswap /dev/volgroup0/swap_lv1
Setting up swapspace version 1, size = 41875927 kB

5) Turn the swap volume back on:
$ swapon /dev/volgroup0/swap_lv1

6) Use the free command to show your new swap space:
$ free -tom| grep -i swap
Swap: 30719 0 30719

View RPM's by architecture

#r pm -qa --queryformat "%{NAME}-%{VERSION}-%{ARCH} \\n" | grep expat

# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{ARCH} \\n" | grep expat
expat-1.95.7-x86_64
expat-1.95.7-i386

Speed up your browsing with dd-wrt

Have you changed the firmware on your Linksys router to dd-wrt? If you did, you can make a simple configuration change to the dnsmasq service that provides DNS and DHCP services. Login to the router, and browse to the Administration/Services tab, and add the following entry:


This tells the DNSMasq service to cache 2000 DNS entries. The result is that any DNS request (one is made for EVERY website request) will be served up by the local Linksys router, rather than obtaining the request from a DNS server on the Internet.

By caching DNS requests locally, you will see faster browser response times. While this DNS lookup time savings may only be milliseconds, for sites you visit multiple times in a session you will see a large boost in performance. Such sites will feel more responsive.

Here is an example of a Linux server (also behind the Linksys router) performing "dig" lookup against Google:

# dig www.google.com | grep "Query time"
Query time: 16 msec

# dig www.google.com | grep "Query time"
Query time: 1 msec

For the first request, google.com’s details were not in the Linksys cache, and the query took 16ms. The second time, the cache speeds up the lookup, and the time is reduced to 1ms.

If you login via SSH to the Linksys router and send a sigusr1 to the DNSMasq service, you can obtain a listing of the entries it is caching:
# killall -sigusr1 dnsmasq
dnsmasq: time 259374, cache size 2000, 0/16 cache insertions re-used unexpired cache entries.
dnsmasq: Host Address Flags Expires
dnsmasq: del.icio.us 206.190.56.150 4F 31
dnsmasq: www.boingboing.net 204.11.50.136 4F 281
dnsmasq: bloglines.com 65.214.39.152 4F 4294967282
dnsmasq: WRT54G 192.168.1.1 4FRI H 0
dnsmasq: pageflakes.com 69.5.89.127 4F 501127
dnsmasq: www.bloglines.com bloglines.com CF 633
dnsmasq: feeds.feedburner.com 66.150.96.111 4F 42

HP RAM information from CLI

Need to know the specific of the RAM in your server? If you have the Proliant Support Pack installed:

$ hpasmcli -s 'show dimm'

DIMM Configuration
------------------
Cartridge #: 0
Module #: 1
Present: Yes
Form Factor: 9h
Memory Type: 12h
Size: 1024 MB
Speed: 400 MHz
Status: Ok

Cartridge #: 0
Module #: 2
Present: Yes
Form Factor: 9h
Memory Type: 12h
Size: 1024 MB
Speed: 400 MHz
Status: Ok

Cartridge #: 0
Module #: 3
Present: Yes
Form Factor: 9h
Memory Type: 12h
Size: 512 MB
Speed: 400 MHz
Status: Ok

Cartridge #: 0
Module #: 4
Present: Yes
Form Factor: 9h
Memory Type: 12h
Size: 512 MB
Speed: 400 MHz
Status: Ok

Cartridge #: 0
Module #: 7
Present: Yes
Form Factor: 9h
Memory Type: 12h
Size: 512 MB
Speed: 400 MHz
Status: Ok

Cartridge #: 0
Module #: 8
Present: Yes
Form Factor: 9h
Memory Type: 12h
Size: 512 MB
Speed: 400 MHz
Status: Ok

HP server information from CLI

Want to know about the hardware in your HP Linux server? Assuming you have the Proliant Support Pack installed:

$ hpasmcli -s 'show server'

System : ProLiant DL385 G1
Serial No. : USE518A6FN
ROM version : A05 04/22/2005
iLo present : Yes
Embedded NICs : 2
NIC1 MAC: 00:13:21:b3:e0:5a
NIC2 MAC: 00:13:21:b3:e0:59

Processor: 0
Name : AMD Opteron
Stepping : 1
Speed : 2400 MHz
Bus : 0 MHz
Socket : 2
Level2 Cache : 1024 KBytes
Status : Ok

Processor: 1
Name : AMD Opteron
Stepping : 1
Speed : 2400 MHz
Bus : 0 MHz
Socket : 1
Level2 Cache : 1024 KBytes
Status : Ok

Processor total : 2

Memory installed : 4096 MBytes
ECC supported : Yes

How to find the number of physical processors

The cat /proc/cpuinfo | egrep "processor|core|model name|physical id command will tell you what you need to know.

Here is what the command looks like when run on an Opteron server with 2-dual core CPU's:

$ cat /proc/cpuinfo | egrep "processor|core|model name|physical id"
processor : 0
model name : AMD Opteron (tm) Processor 880
physical id : 0
core id : 0
cpu cores : 2
processor : 1
model name : AMD Opteron (tm) Processor 880
physical id : 0
core id : 1
cpu cores : 2
processor : 2
model name : AMD Opteron (tm) Processor 880
physical id : 1
core id : 0
cpu cores : 2
processor : 3
model name : AMD Opteron (tm) Processor 880
physical id : 1
core id : 1
cpu cores : 2

Notice that each listed dual-core processor will have the SAME physical ID, but a DIFFERENT core ID (0,1). A single- core hyper threaded CPU will list as two processors, but have the same physical ID and the same core ID.

Finally, four physical processors will list with different physical ID, like this:

processor : 0
model name : Intel(R) Xeon(TM) MP CPU 2.80GHz
physical id : 0

processor : 1
model name : Intel(R) Xeon(TM) MP CPU 2.80GHz
physical id : 1

processor : 2
model name : Intel(R) Xeon(TM) MP CPU 2.80GHz
physical id : 2

processor : 3
model name : Intel(R) Xeon(TM) MP CPU 2.80GHz
physical id : 3

Need a 32-bit package on 64-bit RHEL?

If you need to install a 32-bit package on a 64-bit version of RHEL, you simply pass up2date the "-arch=i386" parameter. For example, many Oracle products still depend on the presence of 32-bit libraries on the server. One such package is the "xorg-x11-deprecated-libs" package.

A normal 64-bit RHEL install places the 64-bit libraries for this package in the /usr/X11R6/lib64 directory. However, the Oracle installer looks for the 32-bit version of the packages in the /usr/X11R6/lib directory, and they are absent from the directory. To install these 32-bit versions, use the architecture parameter to up2date, like this:

$ up2date --arch=i386 xorg-x11-deprecated-libs

This will install the 32-bit version of xorg-x11-deprecated-libs and any dependencies.

NOTE: You can also direct a 64-bit package to install with this command: up2date --arch=x86_64 xorg-x11-deprecated-libs

RPM rollbacks

Ever use up2date to upgrade a Red Hat server, only to have a newly-upgraded package cause a problem? You have to uninstall the offending package, find the old version, download it, and install it. These time-consuming activities can be avoided by using a little-known feature of RPM called "rollbacks."

RPM rollbacks give you the ability to roll-back an upgrade to the previous (last-known good?) version. Here's how it works: RPM packages, whether installed individually or in a group, are given a unique Transaction ID (TID) in the RPM database. This allows RPM to track which transaction installed or upgraded a specific RPM. These TID's are what the rollback mechanism uses to work its magic.

The other element needed is the RPM (or set of RPM's) that were on the system prior to the upgrade/install. The rollback mechanism solves this problem by repackaging the existing RPM's before they get erased. These "repackaged" packages are stored in the /var/spool/repackage directory.

To enable rollbacks, get into the up2date management console with the "u2pdate --configure" command, and change the "enableRollbacks" option to "Yes."

The next time there are packages to be updated, here is what it will look like:

# up2date -u

Fetching Obsoletes list for channel: rhel-x86_64-as-4...
########################################

Fetching rpm headers...
########################################

Name Version Rel
----------------------------------------------------------
nss_ldap 226 17 x86_64
openssh 3.9p1 8.RHEL4.17.1 x86_64
openssh-clients 3.9p1 8.RHEL4.17.1 x86_64
openssh-server 3.9p1 8.RHEL4.17.1 x86_64
sysreport 1.3.15 8 noarch
tzdata 2006m 3.el4 noarch

Testing package set / solving RPM inter-dependencies...
########################################
nss_ldap-226-17.x86_64.rpm: ########################## Done.
openssh-3.9p1-8.RHEL4.17.1. ########################## Done.
openssh-clients-3.9p1-8.RHE ########################## Done.
openssh-server-3.9p1-8.RHEL ########################## Done.
sysreport-1.3.15-8.noarch.r ########################## Done.
tzdata-2006m-3.el4.noarch.r ########################## Done.
Preparing ########################################### [100%]

Repackaging...
nss_ldap ########################################### [100%]
openssh ########################################### [100%]
openssh-clients ########################################### [100%]
openssh-server ########################################### [100%]
sysreport ########################################### [100%]
tzdata ########################################### [100%]

Installing...
1:openssh ########################################### [100%]
2:nss_ldap ########################################### [100%]
3:openssh-clients ########################################### [100%]
4:openssh-server ########################################### [100%]
5:sysreport ########################################### [100%]
6:tzdata ########################################### [100%]

If you then list the /var/spool/repackage directory, you see the old versions of the RPM's that have been "repackaged."

$ ls
nss_ldap-226-13.x86_64.rpm
openssh-3.9p1-8.RHEL4.17.x86_64.rpm
openssh-clients-3.9p1-8.RHEL4.17.x86_64.rpm
openssh-server-3.9p1-8.RHEL4.17.x86_64.rpm
sysreport-1.3.15-6.noarch.rpm
tzdata-2006m-2.el4.noarch.rpm

To list the known rollback targets:

$ up2date --list-rollbacks
install time: Sat Dec 2 05:22:49 2006 tid:1164997369
[-] nss_ldap-226-13:
[-] openssh-3.9p1-8.RHEL4.17:
[-] openssh-clients-3.9p1-8.RHEL4.17:
[-] openssh-server-3.9p1-8.RHEL4.17:
[-] sysreport-1.3.15-6:
[-] tzdata-2006m-2.el4:
[+] openssh-clients-3.9p1-8.RHEL4.17.1:
[+] nss_ldap-226-17:
[+] openssh-server-3.9p1-8.RHEL4.17.1:
[+] tzdata-2006m-3.el4:
[+] openssh-3.9p1-8.RHEL4.17.1:
[+] sysreport-1.3.15-8:

The entries with plus signs are the currently-installed versions. The entries with negative signs are the older versions that were just replaced. Note that the tid is also displayed.

To roll back this RPM transaction, use the --rollback option followed by the rollback target. The rollback target can be an actual date or a tid.