echo $EDITOR # or %{EDITOR}
edit /etc/resolv.conf
-live CD inspection
-------------------
-
- virt-inspector livecd.iso
-
-Could this be done through the core API and existing calls?
-
-There is a soft requirement for this in virt-manager, where it would
-be nice to be able to prepopulate the operating system hints based on
-what sort of ISO the user is trying to install from.
-
-Several sorts of CDs:
-
- - live CD
- - install-only CD
- - network install CD
- - supplemental CDs with additional packages but not bootable
- on its own
-
-Some CDs are formatted as ISO9660 and larger ones as UDF (DVD format),
-but they all are unpartitioned.
-
-Bootable Linux CDs have an /isolinux directory.
-
-Bootable EFI CDs have an /EFI/BOOT directory.
-
-Fedora live CDs have /images/install.img which is a squashfs
-containing an ext4 root. We could consider mounting this and
-inspecting it separately, but it would be simple to get everything we
-need from other files in the CD directory.
-
-More recent Fedora install DVD has /.discinfo and /.treeinfo with some
-easy to parse information in it.
-
-Debian and Ubuntu CDs have a /.disk/info file which is the product
-string. There are other interesting files in /.disk. They also have
-a characteristic directory structure (eg. /dists, /pool/main) which
-looks like a Debian archive.
-
-Windows 2003 install CDs have some characteristic stamp files in the
-root directory, like: /win51 /win51ia /win51ia.sp2. The main
-installation files (CAB files) are in /i386 directory. The following
-files contain a lot of interesting information:
-
- /i386/hivesft.inf
- /i386/layout.inf
- /i386/sis.inf
- /i386/txtsetup.sif
+live CD inspection for Windows 7
+--------------------------------
Windows 7 install CDs are quite different and pretty impenetrable.
There are no obvious files to parse.
ntfs streams: extract alternate streams from NTFS files
+ntfsck: checker for NTFS filesystems
+
Undelete files
--------------
This could be used instead of current hairy code to parse the output
of the 'mount' command. We could add new APIs to return kernel mount
options, type of filesystem at a mountpoint etc.
+
+guestfish drive letters
+-----------------------
+
+There should be an option to mount all Windows drives as separate
+paths, like C: => /c/, D: => /d/ etc.
+
+More inspection features
+------------------------
+
+- last shutdown time
+- DHCP address
+- last time the software was updated
+- last user who logged in
+- lastlog, last, who
+
+Get the guest icon
+------------------
+
+- For Linux guests, use /etc/favicon.png if available, else get it in
+ a distro-specific manner.
+- For Windows guests, parse it out of c:\windows\explorer.exe
+
+Integrate virt-inspector with CMDBs
+-----------------------------------
+
+Either integrate virt-inspector with Configuration Management
+Databases (CMDBs) or at least check that virt-inspector produces the
+right range of data so that integration would be possible. The
+standards for CMDBs come from the DMTF, see eg:
+
+http://dmtf.org/news/pr/2009/7/dmtf-releases-cmdbf-standard-federating-configuration-management-data
+
+Efficient way to visit all files
+--------------------------------
+
+https://rwmj.wordpress.com/2010/12/15/tip-audit-virtual-machine-for-setuid-files/#content
+
+A naive method would look like:
+
+ g#visit ~return_stats:true "/" (
+ fun pathname stat ->
+ ...
+ )
+
+However this has two disadvantages:
+
+ - requires hand-written custom bindings in each language
+ - unclear about locking, thread-safety and re-entrancy of handle g
+
+A better way would be to have some sort of explicit "download all
+filenames and stat structures", which could then be iterated over:
+
+ let files = g#find_opts ~return_stats:true "/" in
+ List.iter (
+ fun pathname stat ->
+ ...
+ )
+
+The problem with this is that 'files' is going to be larger than a
+protocol buffer.
+
+This leads to thinking about changes to the protocol / generator to
+make this simpler. The proposal would be to add RBigStringList,
+RBigStructList [or RBig (Ranytype ...)]. These would work like
+FileOut, in that they would use file streaming to stream XDR
+structures (probably written to a file on the library side).
+Generated code would hide most of the implementation.
+
+We also need to think about security issues: is it possible for the
+daemon to keep sending back data forever, and if so what happens on
+the library side.
+
+[Users can now use virt-ls to solve some of these problems, but it is
+not a general solution at the API level]
\ No newline at end of file
git.annexia.org / libguestfs.git / blobdiff