These two calls wrap up the /sbin/findfs command, allowing you
to find a filesystem by only knowing its label or UUID.
This is especially useful when resolving LABEL=... or UUID=...
entries in /etc/fstab.
Sample guestfish session:
><fs> vfs-uuid /dev/vda1
277dd61c-bf34-4253-a8dc-df500a05e7df
><fs> findfs-uuid 277dd61c-bf34-4253-a8dc-df500a05e7df
/dev/vda1
><fs> vfs-label /dev/vda1
/boot
><fs> findfs-label /boot
/dev/vda1
><fs> vfs-uuid /dev/VolGroup00/LogVol00
40ce7c36-82ce-4a12-a99d-48f5e054162c
><fs> findfs-uuid 40ce7c36-82ce-4a12-a99d-48f5e054162c
/dev/mapper/VolGroup00-LogVol00
><fs> findfs-uuid 12345678
libguestfs: error: findfs_uuid: findfs: unable to resolve 'UUID=12345678'
This commit adds four APIs for creating new LUKS devices
and key management. These are:
luks_format Format a LUKS device with the default cipher.
luks_format_cipher Format with a chosen cipher.
luks_add_key Add another key to an existing device.
luks_kill_slot Delete a key from an existing device.
This enables all the significant functionality of the
cryptsetup luks* commands.
Note that you can obtain the UUID of a LUKS device already
by using vfs-uuid.
This also includes a regression test covering all the LUKS
functions.
This adds support for opening LUKS-encrypted disks, via
three new APIs:
luks_open: Create a mapping for an encrypted disk.
luks_open_ro: Same, but read-only mapping.
luks_close: Close a mapping.
A typical guestfish session using this functionality looks
like this:
$ guestfish --ro -a encrypted.img
><fs> run
><fs> list-devices
/dev/vda
><fs> list-partitions
/dev/vda1
/dev/vda2
><fs> vfs-type /dev/vda2
crypto_LUKS
><fs> luks-open /dev/vda2 luksdev
Enter key or passphrase ("key"):
><fs> vgscan
><fs> vg-activate-all true
><fs> pvs
/dev/dm-0
><fs> vgs
vg_f13x64encrypted
><fs> lvs
/dev/vg_f13x64encrypted/lv_root
/dev/vg_f13x64encrypted/lv_swap
><fs> mount /dev/vg_f13x64encrypted/lv_root /
><fs> ll /
total 132
dr-xr-xr-x. 24 root root 4096 Jul 21 12:01 .
dr-xr-xr-x 20 root root 0 Jul 21 20:06 ..
drwx------. 3 root root 4096 Jul 21 11:59 .dbus
drwx------. 2 root root 4096 Jul 21 12:00 .pulse
-rw-------. 1 root root 256 Jul 21 12:00 .pulse-cookie
dr-xr-xr-x. 2 root root 4096 May 13 03:03 bin
NOT included in this patch:
- An easier way to use this from guestfish.
- Ability to create LUKS devices.
- Ability to change LUKS keys on existing devices.
- Direct access to the /dev/mapper device (eg. if it contains
anything apart from VGs).
These APIs allow you to change the device filter, the list of
block devices that LVM "sees". Either you can set it to a fixed
list of devices / partitions, or you can clear it so that LVM sees
everything.
Previous commit 4df593496e broke the
"file" command on logical volume paths, since these are symbolic
links. We *should* follow these (only).
This inadvertantly broke virt-inspector too, which indicates that
we need more regression testing in this area. Since carrying whole
Fedora images around could make the distribution even larger than
now, I'm not sure at the moment how to do this.
Thanks to Matt Booth for diagnosing this bug.
The file call can hang if called on char devices (because we are
using the file -s option).
This is hard to solve cleanly without adding another file API.
However this restricts file to regular files, unless called explicitly
with a /dev/ path. For non-regular files, it will now return a
string like "directory".
There is a small semantic change for symbolic links. Previously
it would not have worked at all on absolute links (or rather, the
results would have been undefined). It would have treated relative
symlinks to regular files as the regular file itself. Now it will
return the string "symbolic link" in both cases.
This commit also makes the API safe when called on untrusted
filesystems. Previously a filesystem might have been set up so
that (eg) /etc/redhat-release was a char device, which would have
caused virt-inspector and virt-v2v to hang. Now it will not hang.
path = path to access file (/sysroot/.. or /dev/..)
display_path = original path, saved so we can display it
buf = optional buffer which is freed along return codepaths
There should be no change to the semantics of the code.
On RHEL 5 you have to specify the -i option to get the
external 'base64' command to ignore \n characters. (The
Fedora version seems to ignore these characters anyway).
Add this option so the tests can pass on RHEL 5.
Fix these calls (see description in RHBZ#597112), but also
deprecate them since the new calls vfs_label and vfs_uuid can
work on any filesystem type.
This also adds a regression test for the original bug reported
in RHBZ#597112.
These APIs generalize the existing 'get-e2label' and 'get-e2uuid'
calls, to provide calls which should be able to get the label
and UUID for most filesystem types. These use 'blkid' to do the
work.
I have tested that the blkid commands themselves work on RHEL 5.
(Suggested by Yufang Zhang).
guestfs_fallocate takes an integer for the length, effectively
limiting it to creating 1GB files. This new call takes an int64_t
for the length, but is otherwise identical.
On Ubuntu <= Karmic, xz-utils was not packaged, and therefore
any xz-related tests would fail. Thus make this an optional
group so that we can test for this and avoid running the tests
if xz utils are not present.
The guestfs_write call can be used to create small files with
arbitrary 8 bit content, including \0 bytes.
This replaces and deprecates write-file, which cannot be modified
to use BufferIn because of an unfortunate choice in the ABI: the
size parameter to write-file, if zero, means that the daemon tries
to calculate the length of the buffer using strlen. However this
fails if we pass a zero-length buffer using BufferIn because then
the daemon tries to do strlen on a (really) zero length buffer, not
even containing a terminating \0 character, thus segfaulting.
This commit improves the error messages from the tar-in, tgz-in (etc)
commands by capturing the stderr from the tar command in a file and
sending that back in the error message.
The method used for the error file is primitive, and there is a case
for a more generic error file mechanism, but this will do for now.
Sample error messages after this change:
$ virt-tar -u /tmp/test1.img /tmp/not.tar /
tar_in: tar subcommand failed on directory: /: tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors at /home/rjones/d/libguestfs/tools/virt-tar line 247.
$ virt-tar -u /tmp/test1.img /tmp/test.tar /
tar_in: tar subcommand failed on directory: /: tar: access.log: Cannot open: Read-only file system
tar: Exiting with failure status due to previous errors at /home/rjones/d/libguestfs/tools/virt-tar line 247.
During a FileIn command (eg. upload, tar-in) if both sides
experience errors, then both sides could send cancel messages,
the result being lost synchronization.
The reason for the lost synch was because the daemon was ignoring
this case and sending an error message back which the library side
(which had cancelled) was not expecting.
Fix this by checking in the daemon for the case where the library
also cancels during daemon cancellation, and not sending an error
messages.
This also includes an enhanced regression test which checks for this
case.
This extends the original fix in
commit 5922d7084d.
More details can be found here:
https://bugzilla.redhat.com/show_bug.cgi?id=576879#c5
Pengzhen Cao noticed that read-file would fail for files
larger than the protocol size; this is *not* the bug. However
it would also lose protocol synchronization after this.
The reason was that functions which return RBufferOut in the
generator must not 'touch' the *size_r parameter along error
return paths.
I fixed read-file and initrd-cat, and I checked that pread was
doing the right thing.
This also adds regression tests for read-file with various categories
of large file.
The original idea (suggested by Al Viro) was to fork and chroot
into the sysroot and read the file from there. Because of the
separate process being chrooted, absolute links would be resolved
correctly. The slightly modified idea is to open the file in the
daemon process (but temporarily chrooted, so symlinks resolve
correctly), fork, and have the subprocess just be responsible for
copying the file. (Strictly speaking we don't need to fork, but
this implementation is simpler).
This commit just includes the changes needed to the command*()
functions in daemon/guestfsd.c and adds an absolute symlink to
the test ISO for testing it. Later commits will fix the broken
daemon commands themselves.
The comment in the code describes it thus:
/* Note: abort is used in a few places along the error paths early
* in this function. This is because (a) cleaning up correctly is
* very complex at these places and (b) abort is used when a
* resource problem is indicated which would be due to much more
* serious issues - eg. memory or file descriptor leaks. We
* wouldn't expect fork(2) or pipe(2) to fail in normal
* circumstances.
*/
Change the network configuration so everything is set using
some macros at the top of src/guestfs.c.
Also, rename the macros used in the daemon so they are not the
same. It was a very long time since these sets of macros had to
match the ones defined in src/guestfs.c, despite what the comment
said.
Note that this commit should not change the semantics of the
program at all.
