Jamie Fargen's Weblog

The post is from the stand point of RHEL hypervisor with a KVM CentOS Linux guest using a raw image file as a backing store and the openssl package, but it could easily be applied to different distros, backing stores, or even booting a Linux livecd as long as you can get the necessary packages. Some steps may vary depending on what kind of backing store you are using for the image and the partitions your OS is installed. This process could also be used to do many other things like increasing the time for password expirations.

 

First mount the image as a loopback device:

$ sudo losetup /dev/loop0 /var/lib/libvirt/images/virtcort011ccxra.img       # note that is a zero at the end of /dev/loop

Next add the partition mappings:

$ sudo kpartx -av /dev/loop0

In my CentOS installation I was using LVM and the next few steps are LVM specific:

Use vgscan to find the LVM volume

$ sudo vgscan

This located the new LVM volume group VolGroup00   # again note that is zero zer at the end of VolGroup. You will use this group in the next step.

Activate LVM Volume Group:

$ sudo vgchange -ay VolGroup00

You can use lvs to find the Volume where your / (root) file system is mounted:

$ sudo lvs

Next mount the volume:

$ sudo mount /dev/VolGroup00/LogVol00 /mnt/linuxrescue

You should be able to see directories in the volume:

$ ls /mnt/linuxrescue

Now generate the new password for the guest:

$ openssl passwd -1 -salt ranNum    # for the salt substitute random numbers and letters for ranNum.

Password:

$1$ranNum$N6s5hhYltlYQPnMDdxYy1   # you can see your salt + hash

Now copy this string into /etc/shadow:

$ sudo vi /mnt/linuxrescue/etc/shadow

In editing your shadow file you will see something like below your salt+hash should be  substituted as below for the user password you would like to reset.

root:$1$ranNum$N6s5hhYltlYQPnMDdxYy1:15492:1:90:7:::

If you want to change the length of time for password expirations the next step will show you how.

$ sudo vi /etc/login.defs     # find the value PASS_MAX_DAYS and edit it to your needs

Now unmount the file system:

$ sudo umount /mnt/linuxrescue

Unactivate the LVM vol group:

$ sudo vgchange -an VolGroup00

Delete the partition mappings:

$ sudo kpartx -dv /dev/loop0

Unmount the loopback device:

$ sudo kpartx -dv /dev/loop0

 

A lot of people do backups with rsync and 99% of the time it works pretty well. There is one file type that rsync handles rather poorly and that is sparse files, even though rsyncs documentation indicates that sparse files are handled efficiently it is simply not true. These sparse files are becoming more prominent because they are used to store VM images, like KVM, Xen, even VMWare. So what is a good way to copy them? It turns out that tar is much better at handling sparse files than rsync, it has had support for sparse files for over two decades, and can represent the holes in sparse files more efficiently.

In my testing using Tar instead of Rsync has resulted in cutting the time to backup a sparse file by 8-10 times.

Just pipe tar over ssh and compare your results to rsync:
tar cvzSpf – sparse.file | ssh user@hostname ‘(cd /tmp; tar xzSpf -)’