From: Mike Snitzer <snitzer@redhat.com>
To: chris procter <chris-procter@talk21.com>
Cc: linux-lvm@redhat.com
Subject: [linux-lvm] Re: Script to import hardware snapshoted VGs
Date: Fri, 8 May 2009 16:53:13 -0400 [thread overview]
Message-ID: <20090508205312.GA7838@redhat.com> (raw)
In-Reply-To: <461677.62017.qm@web87108.mail.ird.yahoo.com>
Hi Chris,
I actually worked on such a script a little over a month ago but haven't
had a chance to get back to it. I've reviewed your script and have
inlined some comments/suggestions below.
On Thu, May 07 2009 at 6:05pm -0400,
chris procter <chris-procter@talk21.com> wrote:
> If your VG is called myvg you should now also have a new vg called
> myvg.1 with different uuids. It will ignore incomplete volume groups,
> or exported volume groups unless the -i flag is used.
I applaud your support of volume groups that are either imported or
exported. Not strictly needed but thorough.
> function appenddisk {
> ### add a blockdevice path (/dev/sda etc) to a list if its valid
> LIST=$1
> DISK=$2
>
> if [ ! -b "${DISK}" ]
> then
> echo " ${DISK} not a valid block device - ignoring" >&2
> echo "${LIST}"
> return
> fi
>
> if [ -z "${LIST}" ]
> then
> LIST="${DISK}"
> else
> LIST="${LIST} ${DISK}"
> fi
> echo ${LIST}
> }
One use-case that was off my radar until others pointed it out is when
obscure PV names exist in the system. Using shell and not explicitly
checking for such awkward PV names can cause the script to fail. Names
might exclude any of the following (taken from the LVM2 source's
test/t-mdata-strings.sh): "__\"!@#\$%^&*,()|@||'\\\""
The lvm tools can handle such names as long as the user takes care to
properly escape the special characters because once passed in as an arg
the C-code won't interpret the characters at all; unfortunately shell
will.
So we likely need to at least detect that the supplied PV name(s)
contain "unsupported" (by this script) characters and error out
accordingly. This is the part that caused me to put my script stall.
...
> SHOW=0
> DISKS=""
> LVMCONF="/etc/lvm/lvm.conf"
> TMPDIR="/tmp/lvm"
...
>
> #####################################################################
> ### Prepare the temporay lvm environment
> #####################################################################
> if [ ! -d "${TMPDIR}" ]
> then
> mkdir "${TMPDIR}"
> checkvalue $? "Unable to create ${TMPDIR}"
> fi
...
> awk -v var="${FILTER}" '/^[[:space:]]*filter/{print var;next};{print $0}' < ${LVMCONF} > ${TMPDIR}/lvm.conf
You have a security hole here because some user _could_ create /tmp/lvm
in advance and symlink /tmp/lvm/lvm.conf to some random file they want
overwritten by root.
Also, TMPDIR is a standard name used by other tools; likley best to
side-step it by using something like "TMP_LVM_SYSTEM_DIR".
Using the following would be best:
TMP_LVM_SYSTEM_DIR=$(mktemp -d --tmpdir snap.XXXXXXXX)
There really isn't any need to expose which TMPDIR to use with -t; just
allow the user to set TMPDIR in their environment and mktemp will "just
work" with it.
Quick side-bar: you should probably add something like the following
early on:
if test "$UID" != "0" && test "$EUID" != "0"; then
echo "WARNING: Running as a non-root user. Functionality may be unavailable."
fi
...
> OLDVGS=`pvs --noheadings --trustcache 2>/dev/null | awk '(NF==6){printf("%s ",$2)}'`
Existing LVM2 scripts (e.g. LVM2/script/lvm_dump.sh) allow the user to
override which lvm binary is used for all command by doing the
following:
# user may override lvm location by setting LVM_BINARY
LVM=${LVM_BINARY-lvm}
die() {
code=$1; shift
echo "$@" 1>&2
exit $code
}
"$LVM" version >& /dev/null || die 2 "Could not run lvm binary '$LVM'"
> #####################################################################
> ### Change the uuids.
> #####################################################################
> PVSCAN=`pvscan`
The above would become:
PVSCAN=`"$LVM" pvscan`
Once these things are cleaned up we should get it committed to the LVM2
tree; in the scripts/ dir.
But these things aside, the script looks pretty good.
BTW, it should probably get renamed to have to a more standard lvm
prefix, e.g.: vgimportclone
Regards,
Mike
next prev parent reply other threads:[~2009-05-08 20:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-07 22:05 [linux-lvm] Script to import hardware snapshoted VGs chris procter
2009-05-08 20:53 ` Mike Snitzer [this message]
2009-05-09 19:34 ` [linux-lvm] " chris procter
2009-05-10 17:03 ` Eric Brunson
2009-05-11 18:39 ` chris procter
2009-05-11 20:26 ` Eric Brunson
2009-05-11 21:15 ` Stuart D. Gathman
2009-05-11 21:35 ` Eric Brunson
2009-05-12 15:38 ` Mike Snitzer
2009-05-12 23:15 ` chris procter
2009-05-13 12:44 ` Mike Snitzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090508205312.GA7838@redhat.com \
--to=snitzer@redhat.com \
--cc=chris-procter@talk21.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).