This week we prepared another ownCloud sync client (oCC) release for you. oCC is released together with csync 0.50.5, the underlying library on which shoulders oCC stands. Find packages for your distribution.

Only a couple of weeks after the first release we could come up with a quite long changelog, larger than for a maintainance release.

First and foremost, oCC now supports SSL connections and does not store passwords any more, well, in clear text in a config file. Still there is no strong encryption for the password in (as that’s a non trivial if not impossible thing) but its not clear text any more, so accidents should not longer happen. For those who really care and put security over convenience there now is the option to not store the password at all but provide it at startup. The whole password storage will get more attention soon, I did some work on that already, also using kwallet, more on that in another post.

The whole start process of oCC, which is more complex as it might seem as libcsync expects a nice environment with a verified connection to the ownCloud, was cleaned and matured. I had to learn about QNAM but now we seem to be friends.

Efforts also went into the following areas:

• Error handling: People got confused about error messages from oCC which were not accurate here and than. I added more fine granular error reporting to libcsync so that oCC now can give even more helpful error messages.
• MacOSX: On the sprint weekend in Stuttgart, we made good progress on that platform, will also soon get a release. Domme got the most out of cmake to get dmg image building going, thanks, you rock!
• Qt 4.6: As usual one has to learn that current distributions ship not so current Qt versions. Thanks to Thomas, he put quite some effort in porting back to Qt 4.6 - so that Debians friends can also use oCC now.
• Packages: Check out the community repo on OBS: We now can provide packages for way more platforms including Ubuntu and Debian. Still your help would be appreciated in maintaining.

Speaking about the recent sprint in Stuttgart: It was great to be there, ownCloud has an open, friendly and welcoming community in which you really feel the spirit of working on something new and interesting with cool potential. I really enjoy being here,. Thanks guys for all your work and feedback :-)

• User Interface Designer
• Front-End Web Developer
• Web Designer openSUSE Boosters
• and more...

Google announced today the accepted students for Google Summer of Code 2011.

The students working on LibreOffice will be:

Let the summer start immediately and let quality code fall like a spring rain!

I work on automatic testing of one of our products that creates other projects.
And because there is a lot of clouds everywhere I want to use them too. We
have internally an OpenStack cloud (still Diablo release). So I need to solve
automatic uploading of images built in the Build Service. Below I describe my working version.

At first, for other cloud related tasks we are using the nova command (which
e.g. has also image-delete, but not add). For uploading we use
glance. I found a few obstacles which I separately describe and also provide
a solution.

Authentication

The first chalenge is authentication, as glance doesn`t use NOVA_*
environment variables. But it allows to use an authentication token. So we
just need to get such a token. With help of Martin Vidner we have this script,
that returns a valid token.

# cloud_auth_token.sh
OS_AUTH_URL="http://cloud.example.com:5000/v2.0"
OS_TENANT_NAME=$NOVA_USERNAME
OS_USERNAME=$NOVA_USERNAME
OS_PASSWORD=$NOVA_API_KEY
AUTH_JSON="{\"auth\":{\"passwordCredentials\":{\"username\": \"$OS_USERNAME\", \"password\":\"$OS_PASSWORD\"}, \"tenantName\":\"$OS_TENANT_NAME\"}}"
curl -s \
    -d "$AUTH_JSON" -H "Content-type: application/json" \
    $OS_AUTH_URL/tokens \
    | python -c "import sys; import json; tok = json.loads(sys.stdin.read()); print tok['access']['token']['id'];"

What does it do? It calls OpenStack Identity API, passes credentials encoded
as JSON. The response is also JSON, so we use python that is already on the
system to parse the response and get the token.

Compressing the Image

The next challenge is compression of the image. We get a raw disk from the
build service and we extend it to have more than 15GB (we mirror there rpms
so we need this space). For resizing we use qemu-img from
virt-utils. If we simply upload this image it means that we send the whole
15GB over the network. Which is fine for one-time tasks, but for regular
testing it is a problem. Thanks to Christoph Thiel we solved it with the
conversion to qcow2. Qcow2 is also supported in OpenStack and qcow2 allows
compression. The final script for conversion:

qemu-img convert -c -f raw -O qcow2 img.raw img.qcow2
qemu-img resize img.qcow2 +10G

Using it Together

Now we have prepared an image and a helper script to get a cloud auth
token. So let’s upload the image.

cat img.qcow2 | glance -H cloud.example.com -A `sh cloud_auth_token.sh` add name='testing_img' is_public=False disk_format=qcow2 container_format=bare

Cleaning Up After Testing

We use it for testing and release new versions of the testing appliance often,
therefore we need cleaning up. It is quite simple with unix text utils:

for i in `nova image-list | grep "image_name" | sed "s/^|[[:space:]]\+\([[:xdigit:]-]\+\).*$/\1/"`; do nova image-delete $i; done

I hope that it helps you with automatic uploading of images to
OpenStack. It works for me with the Diablo release and there is no guarantee that it is the best way