Thursday, August 14, 2014
There is a tool called 'mount-image-callback' in cloud-utils that takes care of mounting and unmounting a disk image. It allows you to focus on exactly what you need to do. It supports mounting partitioned or unpartitioned images in any format that qemu can read (thanks to qemu-nbd).
Heres how you can use it interactively:
$ mount-image-callback disk1.img -- chroot _MOUNTPOINT_
% echo "I'm chrooted inside the image here"
% echo "192.168.1.1 www.example.com" >> /etc/hosts
% exit 0
mount-image-callback disk1.img -- \
sh -c 'rm -Rf $MOUNTPOINT/var/cache/apt'
or one of my typical use cases, to add a package to an image.
mount-image-callback --system-mounts --resolv-conf --
chroot _MOUNTPOINT_ apt-get install --assume-yes pastebinit
Above, mount-image-callback handled setting up the loopback or qemu-nbd devices required to mount the image and then mounted it to a temporary directory. It then runs the command you provide, unmounts the image, and exits with the return code of the provided command.
If the command you provide has the literal argument '_MOUNTPOINT_' then it will substitute the path to the mount. It also makes that path available in the environment variable MOUNTPOINT. Adding '--system-mounts' and '--resolv-conf' address the common need to mount proc, dev or sys, and to modify and replace /etc/resolv.conf in the filesystem so that networking will work in a chroot.
mount-image-callback supports mounting either an unpartitioned image (ie, dd if=/dev/sda1 of=my.img) or the first partition of a partitioned image (dd if=/dev/sda of=my.img). Two improvements I'd like to make are to allow the user to tell it which partition to mount (rather than expecting the first) and also to do so automatically by finding an /etc/fstab and mounting other relevant mounts as well.
Why not libguestfs?
libguestfs is a great tool for doing this. It operates essentially by launching a qemu (or kvm) guest, and attaching disk images to the guest and then letting the guest's linux kernel and qemu to do the heavy lifting. Doing this provides security benefits, as mounting untrusted filesystems could cause kernel crash. However, it also has performance costs and limitations, and also doesn't provide "direct" access as you'd get via just mounting a filesystem.
Much of my work is done inside a cloud instance, and done by automation. As a result, the security benefits of using a layer of virtualization to access disk images are less important. Also, I'm likely operating on an official Ubuntu cloud image or other vendor provided image where trust is assumed.
In short, mounting an image and changing files or chrooting is acceptable in many cases and offers more "direct" path to doing so.
Wednesday, August 14, 2013
- user namespaces, which will bring us secure containers in 14.04 and the ability to safely run containers without root.
- a library with bindings for C, go and python3.
- cloning with overlayfs
- hooks executed at clone time.
Previously the ubuntu cloud template (which downloads a cloud image to create a container) allowed the user to specify userdata or public keys at container creation time. The change was really just to move the container customization code to a clone hook.
Thanks to the daily build ppa, you can do this on any release from 12.04 to 13.10.
Hopefully the example below explains this better. The times reported are from my Thinkpad X120e, which is a netbook class cpu and slow disk. Times clearly will vary, and these are not meant to be scientific results. If you do not see the embedded file below, please read the remainder of this post in the gist on github.
Tuesday, July 23, 2013
I used 'virtualboxmanage' and 'virtualbox' here, but I'm sure the same can be accomplished via the virtuabox gui, and probably similar commands to do the same thing on Mac/OSX or windows.
So, below is roughly the same thing as the kvm post but with virtualbox. Also to verify function, I did this on Ubuntu 12.04 host with Ubuntu 12.04 guest, but later versions should also work.
Monday, February 11, 2013
A "Data Source" to cloud-init provides 2 essential bits of information that turn a generic cloud-image into a cloud instance that is actually usable to its creator. Those are:
- public ssh key
Very early on it felt like we should have a way to use these images outside of a cloud. They were essentially ready-to-use installations of Ubuntu Server that allow you to bypass installation. In 11.04 we added the OVF as a data source and a tool in cloud-init's source tree for creating a OVF ISO Transport that cloud-init would read data from. It wasn't until 12.04 that we improved the "NoCloud" data source to make this even easier.
Available in cloud-utils, and packaged in Ubuntu 12.10 is a utility named 'cloud-localds'. This makes it trivial to create a "local datasource" that the cloud-images will then use to get the ssh key and/or user-data described above.
After boot, you should see a login prompt that you can log into with 'ubuntu' and 'passw0rd' as specified by the user-data provided.
Some notes about the above:
- None of the commands other than 'apt-get install' require root.
- The 2 qemu-img commands are not strictly necessary.
- The 'convert' converts the compressed qcow2 disk image as downloaded to an uncompressed version. If you don't do this the image will still boot, but reads will go decompression.
- The 'create' creates a new qcow2 delta image backed by 'disk1.img.orig'. It is not necessary, but useful to keep the '.orig' file pristine. All writes in the kvm instance will go to the disk.img file.
- libvirt, different kvm networking or disk could have been used. The kvm command above is just the simplest for demonstration. (I'm a big fan of the '-curses' option to kvm.)
- In the kvm command above, you'll need to hit 'ctrl-alt-3' to see kernel boot messages and boot progress. That is because the cloud images by default send console output to the first serial device, that a cloud provider is likely to log.
- There is no default password in the Ubuntu images. The password was set by the user-data provided.
Wednesday, January 4, 2012
For almost 4 years I have used a mp3 player from Creative Labs named "ZEN Stone Plus with built-in speaker". It was used it to play music for our toddler all night long, nearly every night.
It was an absolutely wonderful product. Battery life via rechargeable battery was excellent, it was small enough to forget about in your pocket, and the speaker was sufficient for what we needed
The only deficiency in my opinion was that it could not play music while plugged into AC power. That meant that a.) the battery would have to last the 10+ hours every night and b.) we had to plug it into AC power every morning to charge it. In the end, it was the latter that caused me to need to replace it. After probably 1000+ plug-in and remove (many by a child under 5 years old) the pins in the USB connection eventually failed.
If you're looking for a portable MP3 player with a built-in speaker, your options are very few. The Ipod Touch (and Iphone) are perfectly good solutions, but come a hefty price tag even used. So, I had to get creative.
I'd seen the Palm Pixi appear on a couple "deal-a-day" websites at the $30 price range, and that lead me to consider the Palm Pixi Plus. The Pixi Plus has the following features that made it look *very* tempting:
- 8GB storage
- Internal Speaker
- web browser
- Touch screen and physical keyboard
- can play music while charging
- runs linux! (just geeky)
- open development platform
However, I googling left me unsure about a couple things:
- Could I use the pixi's wifi without first activating it with some carrier? I had no interest in a phone, or a monthly bill. It did seem that worst case, I could activate on a pay-as-you-go provider and get going for probably less than $10 total.
- If I could manage to avoid activation, could I still have access to the Palm WebOS Store? Having an "App Store" was an unnecessary upgrade from the zen stone we had before, but sure would be nice.
In the end, the answer to each of the above questions was 'Yes'. I now have a MP3 player with a builtin speaker, that also has all the functions generally associated with a smart phone (see above). I'm really happy with it. It cost me $40 shipped in 2 days (I do have amazon prime, so total cost may be a little bit more). The only two issues at the moment are:
- Getting it plugged in for charge is a bit of a pain, and it seems to me that likely the thing that will end up failing is that connection, because its not 100% trivial (and remember, toddlers/young kids are using it). There is, however, a $15 solution for that. I've not purchased it yet, so I'm not 100% certain, but it looks like I can get a Touchstone Palm Pixi Charging Dock and Palm Pixi Touchstone Cover shipped for under $10.
- The music player stops somewhere after 2 hours or so when its on repeat of a single song. Obviously this is not an issue for many people, but it affects my use case.
In Summary, if you think an 8GB mp3 player with GPS, speaker, camera would be a generally cool toy for $40, then buy one today. I'm really happy with this one. I'll try to write another article soon that describes how to use Meta Doctor to flash with activation disabled and then run the first use program to set up a profile.
Thursday, November 17, 2011
Monday, August 29, 2011
If you are using the OVF files or VMDK files, please respond.
Date: Fri, 26 Aug 2011 16:34:41 From: Scott Moser Subject: Anyone using the .ovf and/or .vmdk files on cloud-images? Hey all, Is anyone using the .vmdk or .ovf files on http://cloud-images.ubuntu.com  ? In the 11.04 cycle, I started building .ovf files with corresponding .vmdk images. The goal of this was to make Ubuntu available for use via software that supported importing OVF. I chose to to create the disk as VMDK formated images rather than a more open-source friendly format such as qcow. The OVF file and associated disk image is consumable by both vmware tools and by VirtualBox. There are no OVF consumers that I'm aware of that would function with a qcow (or even 'raw') disk image. I feel compelled to also mention that this format of vmdk (compressed) is not supported by qemu-img or kvm. Since having an OVF that could not be used by any software is not significantly more useful than not having an OVF, we went with vmdk. Largely prompted by the interest in providing a download format that is ideal for OpenStack users , I am re-considering my decision. I would like to avoid adding another full disk image format to the output of the build scripts. As a result I'm thinking about replacing the .vmdk images with compressed qcow images and updating the OVF files to reference those. The reason behind not wanting to just add yet another deliverable is that more downloads are confusing, and disk space is not necessarily free. If I can drop a deliverable not used by anyone, then I'd like to do that. So, would anyone object to the removal of .vmdk files from cloud-images? Is anyone using these that could not just as easily use qcow2 formated images? Thanks, Scott --  http://cloud-images.ubuntu.com/server/oneiric/current/  https://bugs.launchpad.net/ubuntu/+bug/833265