1. IM-pack: Software Installation Using Disk Images
Irena Lanc and Peter Sempolinski

2. The Problem with Installation
Traditional methods of software installation are time-consuming, especially for software with many small files.
MS office can take up to 1 hour
Most existing packaging systems require a user to be root for installation, un-installation, and updates.
This can avoided by downloading and compiling source code, or manually placing bin, usr, lib files. However, these solutions are fiddly and difficult in comparison to package managers.

3. Idealized Installation
Users should be able to install their own software locally for anything not really needing root privileges:
Avoid dealing with system administrators
Be able to carry a preferred batch of software packages with them from machine to machine
Often, user demands on administrators for software produces redundancies

4. Our Idea Disk images are a potential way of solving these problems.
Loop-mounting disk images is much faster than copying files
Easier to unmount a disk image than remove files
Non-root users can own image files
RAM disk images already used in liveCD setups like Knoppix
However, many OS components are not designed for this sort of thing.

5. Our Goal
The goal of our project was to quantify the feasibility of such an approach by implementing a basic framework for disk-image software.
Will such software, so mounted, work transparently and correctly?
What are the current limitations of the OS components needed to build such a system?
Of those limitations, which are inherent to the idea and which can be overcome?

6. The IM-pack System
This system involves 3 file locations: 3) 1) 2)

7. Underlying ext2 filesystem
Software components:
Virtual File System
Image
un-installation
script
Unionfs
Image-installation
script X X
Loop-mounted Device
Loop-mounted Device
Loop- mounted Device
Loop- mounted Device
Underlying ext2 filesystem

8. Usability Our first main metric was qualitative.
Can we build a system, using the tools we have now, that is transparent to the user?
Recall our last presentation . . .

9. Install:

10. Use:

11. Remove:

12. Current Limitations
Most OS components were not really designed for what we were doing:
Component:
Issue:
Our Workaround:
Ideal fix for future work:
Unionfs-kernel module
Not available in all kernels
YES: Ubuntu 9.04 NO: Ubuntu 9.10
HIDDEN limit: about 150 branches
Tested performance of both kernel and fuse versions.
A final production version configured to run with a Linux distribution
Unionfs-fuse
Often unwilling to be unmounted. Danger of self-referential file system deadlock.
Effectively limited to about 1000 branches
Did not mount over top of /usr (Security forbids this as well.)
Ideal system would merge functions of Unionfs and loop devices and be only one module. This removes need for many devices and unmounting
Loop Devices
Limited in kernel to 8
If bypassed, slows virtual machines on boot
In 9.10: each device has desktop icon
Adjusted GRUB boot flags.
Virtual File System
Often unaware when devices are no longer busy.
Uninstall used backoff and retry when unmounting.
Include function to detect what program is locking a filesystem.
dpkg – software source
Bizarre file corruption causing some packages to mangle file sizes when extracted.
Did not use those packages.
Images for a production level system would be compiled specifically for it.
Ubuntu Update Notifier
For some bizarre reason tended to lock all loop devices as busy when appearing.
Removed update notifier.
Fix that bug in update notifier

13. Security Limitations Security was the major inherent limit:
1) Our executable had to use both a large number of string buffers and the suid bit.
2) If users allowed to mount images, one could provide an image containing a root shell.
Therefore, suid must be disabled on all IM-pack mounts
This means NO root level programs allowed
3) Mounting over /usr and similar means one can “replace” files read by root programs.
For multiple users, only secure way is to have unioned directory in an alternate location, such as: ~/unionroot/

14. Performance Metrics
Though adding up to 1000 loop devices does slow down the system, it does not render it unusable – it remains functional and responsive.
Note: One of us attempted to find every single package that they had ever used which was not part of the core system and barely found 300.

15. Results: Average Speed of installation:
Unionfs-fuse: pkg/sec
Unionfs-kernel: 1.39 pkg/sec
Regular .deb package extraction: 5.1 Mb/sec
For smaller packages, the speed is about the same. However, as packages get larger, our system benefits.

16. Time to Install an image vs. Number of Already Installed Images
Time (s)
Number of images installed

17. Time for ls /usr/bin of the union mount vs
Time for ls /usr/bin of the union mount vs. Number of Installed Disk Images
Time (s)
Number of images installed

18. Time vs. Number of disk images remounted
Time (s)
Number of images to be remounted

19. Conclusion
Though IM-pack incorporates existing OS system components and tools not designed for our specific goal, it nevertheless exhibits good performance, especially within reasonable usage bounds.
The only major limitation is security, but this only means root level components and direct placement on directories expecting root files cannot be done.
Other components can optimized to yield greater performance
Unionfs
Loop devices