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
+
+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]
+
+Interactive disk creator
+------------------------
+
+An interactive disk creator program.
+
+Attach method for disconnected operation
+----------------------------------------
+
+http://libguestfs.org/guestfs.3.html#guestfs_set_attach_method
+
+"Librarian" has an idea that he should be able to attach to a regular
+appliance, but disconnect from it and reconnect to it later. This
+would be some sort of modified attach method (see link above).
+
+The complexity here is that we would no longer have access to
+stdin/stdout (or we'd have to direct that somewhere else).
+
+GObject Introspection
+---------------------
+
+We periodically get asked to implement gobject-introspection (it's a
+GNOME thing):
+
+http://live.gnome.org/GObjectIntrospection
+
+This would require a separate Gtk C API since the main guestfs handle
+would have to be encapsulated in a GObject. However the main
+difficulty is that the annotations supported to define types are not
+very rich. Notably missing are support for optional arguments
+(defined but not implemented), support for structs (unless mapped to
+other objects).
+
+Also note that the libguestfs API is not "object oriented".
+
+libosinfo mappings for virt-inspector
+-------------------------------------
+
+Return libosinfo mappings from inspection API.
+
+virt-sysprep ideas
+------------------
+
+ - touch /.unconfigured ?
+ - other Spacewalk / RHN IDs (?)
+ - Kerberos keys
+ - Puppet registration
+ - user accounts
+ - Windows sysprep
+ (see: https://github.com/clalancette/oz/blob/e74ce83283d468fd987583d6837b441608e5f8f0/oz/Windows.py )
+ - blue skies: change the background image
+ - (librarian suggests ...)
+ . install a firstboot script virt-sysprep --script=/tmp/foo.sh
+ . run an external shell script
+ . run external guestfish script virt-sysprep --fish=/tmp/foo.fish
+ . rm /var/cache/apt/archives/*
+ - /var/run/* and pam_faillock's data files
+ - homedirs/.ssh directory, especially /root/.ssh (Steve Grubb)
+ - if drives are encrypted, then dm-crypt key should be changed
+ and drives all re-encrypted
+ - /etc/pki
+ (Steve says ...)
+ Rpm uses nss. Nss sets up its crypto database in
+ /etc/pki. Depending on how long the machine ran before cloning, you
+ may have picked up some certificates or things. This is an area
+ that you would want to look into.
+ - secure erase of inodes etc using scrub (Steve Grubb)
+ - other directories that could require cleaning include:
+ /var/cache/gdm/*
+ /var/lib/fprint/*
+ /var/run/*
+ /var/lib/AccountService/users/*
+ /var/lib/sss/db/*
+ /var/lib/samba/*
+ /var/lib/samba/*/*
+ (thanks Marko Myllynen, James Antill)
+
+Launch remote sessions over ssh
+-------------------------------
+
+We had an idea you could add a launch method that uses ssh, ie. all
+febootstrap and qemu commands happen the same as now, but prefixed by
+ssh so it happens on a remote machine.
+
+Note that proper remote support and integration with libvirt is
+different from this, and people are working on that. ssh would just
+be "remote-lite".
+
+virt-make-fs and virt-win-reg need to not be in Perl
+----------------------------------------------------
+
+Probably they should be in C or OCaml.
+
+Integrate snap-type functionality in inspection tools
+-----------------------------------------------------
+
+Mo Morsi's "snap" program lets you describe a guest as the list of
+packages (eg. RPMs) installed + changes made to those RPMs + files
+added.
+
+http://projects.morsi.org/wiki/Snap
+
+This results in a compact description of the guest. He even managed
+to do a kind of migration of guests by simply recreating the guest
+from the description on the target machine.
+
+It would be ideal to integrate this and/or use inspection to do this.
git.annexia.org / libguestfs.git / blobdiff