Home Home > 2009 > 05 > 15
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for May 15th, 2009

NetworkManager and keyring

May 15th, 2009 by

Tonight I stumbled upon the solution to a irritating little problem I have had for a long time. I use autologin and every time I log in I get prompted for my keyring password in order to access the wireless network. I have googled for this problem numerous times in the past without any luck. All the suggested solutions had to do with Ubuntu and a tool called libpam-keyring. This does not seem to work the same on openSuSE as on Ubuntu and did not help me much. Then I found this post. Towards the bottom of the thread is the instructions that have been evading me for so long. Hope this helps someone else.

GSoC – Integrating oauth into the openSUSE BuildService

May 15th, 2009 by

This year I’m going to participate in the Google Summer of Code and my goal for this summer is to add support for oauth to the openSUSE BuildService. My mentor is darix. In the following I’m going to describe the project and its planned implementation a bit further.

oauth is an open protocol which describes the required steps for a client to
authorize with an API. In traditional protocols the client asks for the user’s
credentials (most-likely a pair of an username and password) and uses these
credentials to authenticate with the API. One drawback of this approach is that
the user has to trust the client that it stores the credentials in a secure way
and that it doesn’t misuse it.
oauth tries to solve these issues in a more elegant and secure way.

Small overview about oauth:
Every API (in oauth terminology “Service Provider”) has a list of known clients
which have a unique id (in oauth terminology “Consumer Key” and
“Consumer Secret”). In order to authorize the client and the API exchange so
called “tokens”.
First the client sends its unique id to the API which verifies the id to make
sure that this client is allowed to use the API. If everything is ok the API
sends back a so called Request Token (which isn’t authorized yet).
In the next step the client redirects the user to the API’s login (this request
also includes the formerly received Request Token). This is the most important
point because the user logs into the API with his/her credentials and the
client _never_ gets in touch with the username and password. After the user
logged in he/she has to approve to grant the client access. If the access is
granted the API sends back the authorized Request Token and redirects the user
back to the webclient.
In the last step the webclient exchanges the authorized Request Token for a
so called Access Token. Now the webclient will use the Access Token for all
requests it sends to the API.
The major advantage is that the webclient only knows about the Access Token
and doesn’t have to fool around with the a username and password. So in case
the webclient gets compromised the attacker can just access the API but not
the other services.

The best is to describe the oauth workflow with a small example.
Note: this example is very idealized and its sole purpose is to visualize the rough workflow of the protocol.

Let’s say the BuildService webclient and the BuildService api use the oauth protocol and the
webclient wants to fetch the projectlist:

request projectlist
webclient ——————————————————> API
API realizes that the webclient isn’t authenticated yet and it returns a 401
webclient <—————————————————— API
request Request Token
webclient ——————————————————> API
verify client id, send back unauthorized Request Token
webclient <—————————————————— API
redirect user to the API login
webclient ——————————————————> API
user logs in
API    <—————————————————–> API
user grant client access
API    <—————————————————–> API
send back authorized Request Token
webclient <—————————————————— API
exchange Request Token for Access Token
webclient ——————————————————> API
verify request and send back Access Token
webclient <—————————————————— API

All consecutive webclient requests contain the Access Token

request packagelist (request contains the Access Token)
webclient ——————————————————> API
verify Access Token and send back packagelist
webclient <—————————————————— API

Within the scope of this project my plan is to add basic oauth support to the following components

  • frontend (API)
  • osc (CLI)

To do so I might use the following libraries:

So the next step is to investigate how these libraries work and how they can be used for this project. I’ll blog about my investigations – stay tuned 🙂

Ps. feedback, comments etc. are welcome.

cat /usr/local/bin/osc

May 15th, 2009 by

Until the Build Service supports git natively (see the GSoC project) , here is what I use to track my changes locally:

#cat /usr/local/bin/osc  :


/usr/bin/osc “$@”

if [ -e .osc/_files ]; then

if [ ! -d .git ] ; then  git init ; echo “.osc” > .gitignore ; echo “.gitignore” >> .gitignore ; fi

git add `find -maxdepth 1 -type f | grep -v “.git”`
for i in $( git status | grep “deleted:” | cut -d” ” -f7 ) ; do
git rm $i;

git commit -a -m”$mydate”


LiveCD Performance (clicfs vs. SquashFS)

May 15th, 2009 by

When Coolo looked into how to get rid of (Another) UnionFS for Live CDs and came up with the DoenerFS (now clicfs) idea, I remembered that my friend Arnd has workded on fake write support for cramfs. So I took his code and ported it to SquashFS to see how that goes. My expectation was that it might be faster than Coolo’s clicfs using FUSE. Here are some results using openSUSE-KDE4-LiveCD-i586-i686-Build0098 booting into runlevel 3:

  • clicfs: 637MB ISO Image booting in 1:28 min (0:24 min from RAM)
  • squashfs-rw: 751M ISO Image booting in 1:50 min (0:28 min from RAM)

The difference in the sizes of the ISO images are due to the fact that clicfs is using LZMA compression while SquashFS is still using the in-kernel GZIP implementation. Surprisingly the clicfs image isn’t only smaller but is also faster booting on real media and from RAM (using KVM). So even if we ignore the fact that clicfs is optimized for limiting the number of seeks on disk the SquashFS implementation is still slower. It would be interesting to see if it is just the LZMA compression that is making the difference or something completely different.

The patches for the SquashFS fake write support are here: http://git.infradead.org/users/jblunck/linux-2.6.git?a=shortlog;h=refs/heads/squashfs-rw-v1.