LVM in rescue mode

e2fsck:

• Boot into rescue mode (in RHEL/Fedora this means putting in CD 1 and typing "linux rescue" at the boot prompt -- but it's essentially any minimal live CD). Rescue mode does not do anything with LVM by defualt: to activiate the volume groups, you need to issue these:
  

  #lvm vgscan
  #lvm vgchange -ay
  #lvm lvs
  

• lvs will simply display your volume group and logical volume names, use this output to issue the e2fsck command: e2fsck /dev/volumegroupname/logicalvolumename. Of course, pass what ever options ot e2fsck you normally would (like -y or -c).

Re-name the / volume group:

I never thought I'd have a legitimate reason to do this, until I found myself wanting to back up data from one disc (from a dead system) on to another system. I always choose the default names for VGs and LVs, so when I put my extra disc into my live system it choked finding two volume groups named "VolumeGroup00".

Take out that second disc, then boot into rescue mode (do not mount anything and do not run the lvm commands from the previous example):

#vgrename VolumeGroup00 newname

Where VolumeGroup00 is the old name, and "newname" is the newname. If this was not the root filesystem we would be done and could happily reboot as normal. But, since this IS the root file system, we need to remake the initial ramdisk first (if you don't have one of those, you're off the hook):

#mount /dev/newname/LogVol00 /mnt/sysimage
#mount /dev/sda1 /mnt/sysimage/boot
#chroot /mnt/sysimage
#cp /boot/initrd-kernelversion.img /boot/kernelversion.img.old
#mkinitrd -v -f /boot/initrd-kernelversion.img kernelversion

Don't forget to change all references to the old VG name. Typically this would be in grub.conf and fstab. After that, reboot with that second disc added and you should be fine

Reference: http://samfw.blogspot.com/2005/12/lvm-in-rescue-mode.html

How to change the listening port for Remote Desktop

Warning! The Remote Assistance feature in Microsoft Windows XP may not work correctly if you change the listening port.

1. Start Registry Editor.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
3. On the Edit menu, click Modify, and then click Decimal.
4. Type the new port number, and then click OK.
5. Quit Registry Editor.

How to uninstall Parallels Virtuozzo for Linux

1. stop Virtuozzo services
service vz stop

2. uninstall all Virtuozzo packages
rpm -qa|grep swsoft|grep vz|xargs yum remove -y
rpm -qa|grep swsoft|grep -E "virtu|-ez-|-tmpl-"|xargs yum remove -y

3. remove /vz contents (directories: actionlog, backups, lock, private, root, template, vzup2date)
cd /vz/ && mkdir _before_reinstall && mv * _before_reinstall

4. remove configs from /etc
mkdir -p /vz/_before_reinstall/etc && find /etc -name vz\* -exec mv {} /vz/_before_reinstall/etc \;

5. check /etc/grub.conf if it has a proper configuration (no Virtuozzo kernel, Red Hat kernel is default)

6. check /etc/sysctl.conf for tuned parameters which you might not need

7. reboot the server

Reference: http://forum.parallels.com/showthread.php?t=72613 by Alec@sw

Viewing a Name Server's Cache

You want to view a name server's cached data.

Solution
Use rndc dumpdb (BIND 9) or ndc dumpdb (BIND 8) to dump the cache to disk, then look through the dump file.

Discussion
BIND 9 name servers only dump the contents of the cache to disk by default, but BIND 8 name servers dump both the contents of cache and authoritative zone data to disk, so you'll have to find the cached records in the file.

To determine which records in a BIND 8 database dump were cached, look at the TTLs and the contents of the comment field. Authoritative zone data will have the nice, round TTLs you configured, while cached records will have had their TTLs decremented by the number of seconds they've been in the cache. Cached records will also have "Cr=" as a comment at the end of the record, giving the credibility level of the record (an indication of the quality of the cached record). For example, these records were cached from an authoritative response from the name server at 128.9.0.107:

. 518380 IN NS I.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS E.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS D.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS A.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS H.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS C.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS G.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS F.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS B.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS J.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS K.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS L.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
518380 IN NS M.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]

Remember that dumping the cache to disk has no effect on the contents of the cache. If you want to flush (clear) the cache, see Flushing (Clearing) a Name Server's Cache.

Flushing (Clearing) a Name Server's Cache
Problem
You want to flush bad records from a name server's cache.

Solution
If you run a BIND 9.2.0 or newer name server, you can flush the cache with rndc flush. With older name servers, you need to kill the name server and restart it to flush the cache. You can do that in one fell swoop with rndc restart or rndc exec.

Discussion
Clearing the cache is really a side effect of killing the name server, since BIND name servers only store cached data in memory. Since restarting the name server takes time, especially if the name server is authoritative for many zones, rndc flush is a better option.

If you run multiple views on your BIND 9.2.0 or newer name server, you can flush the cache in only one view using rndc flush viewname. For example:

# rndc flush internal
BIND 9.3.0 will support flushing all of the records attached to a particular domain name with rndc flushname. For example:

# rndc flushname cnn.com

Modifying Zone Data Without Restarting the Name Server
Problem
You want to modify your zone data without restarting the name server.

Solution
Make the change to the zone data file. For BIND 9, run:

# rndc reload domain-name-of-zone
For BIND 8, run:

# ndc reload domain-name-of-zone
If you've modified multiple zones, just list them after reload. For example:

# rndc reload foo.example bar.example
Discussion
Remember to increment the serial number in your zone's SOA record after changing the zone data. The primary master reloads the zone regardless of whether you've incremented the serial number, since the file's modification time has changed, but your zone's slaves only have the serial number to tell them whether the zone has been updated.

Reloading individual zones, as shown above, was introduced in BIND 8.2.1 and again in 9.1.0. With older versions of BIND, just use rndc reload or ndc reload, as appropriate. That takes a little more time, since the name server checks all zone data files to see which have changed.

If you're reloading a zone that exists in multiple views on a BIND 9 name server, specify the view with rndc reload domain-name-of-zone class view. For example:

# rndc reload foo.example in external
Unfortunately, you can't leave out the class, even though you're unlikely ever to reload a non-Internet class zone.

Telling a BIND 9 name server to reload a dynamically updated zone has no effect, since the name server doesn't expect you to update the zone manually. Telling a BIND 8 name server to reload a dynamically updated zone may work--or you may lose your manual changes.

Dynamic update is, of course, another way to update zone data without restarting the name server