Home Home > Build-service
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 the ‘Build Service’ Category

GSoC – summary of this week’s meeting

June 5th, 2009 by

The last week I mainly worked on integrating the oauth rails plugin into the frontend. So far the current integration is more or less a quick hack but it is working (of course the final version won’t contain these quick hacks etc. 😉 ) and I was able to authenticate with oauth or basic auth.

Additionally I also played with the python module for oauth. At the moment there seems to be a small problem with the hmac-sha5 signature but I’m working on it (but this is most-likey “pebkac”). Anyway plaintext signatures are working.

Action items for this week:

  • integrate oauth into osc
  • investigate how to add something like a ttl for access tokens (so that an access token is only valid n hours/minutes/etc.)

Netbeans 6.5 is going to Factory

June 4th, 2009 by

As you might know, the netbeans package was a part of openSUSE, but for some historical reason, it was a monolithic package in non-oss repository. Last weeks I have worked on import 29 new packages to Factory, which allows us to build netbeans from source and include it to regular free repository. Fortunately thanks for hard work of guys from jpackage project it was easy to adapt their spec files for SUSE and push them into the Factory.

Majority of those packages was reviewed and included into Factory during last weeks, but five (including netbeans) itself are currently in review process, so they would be available later. Following graph shows netbeans and it’s build dependencies. Green color means – package is in Factory, yellow means package is in review process.

Netbeans and build requires

In a meanwhile the netbeans for openSUSE Factory and 11.1 is available in Java:packages BuildService repository, so feel free to install and test it.

Hermes Hack Session

June 2nd, 2009 by

Last week Cornelius and me spent two days in the office in Prague to practice two days Ruby on Rails with our czech colleagues.
It was not only fun as usual but we had chosen Hermes as a trainings project. Hermes, our openSUSE notification system where the user decides how she wants to be notified definetely can make use of work so it were great to discuss with ten developers about it, hear their opinions and get some patches finished which will improve the system.

All went to a branch in svn and I hope to find time soon to merge it back and put it into production.
Thanks to our colleagues for hosting us and work with us. Maybe YOU also want to train on something real? Hermes is your friend – send me a note and get a free svn account 🙂

openSUSE@ARM/GSoC: weekly status

May 30th, 2009 by

Hi everyone!

This week was exciting – we deployed a first prototype of a minimal ARM environment on build.opensuse.org in the repository Base:build:arm. It’s a set of packages which is capable of bootstrapping itself and still in an early stage as it’s using full emulation. Next station: speed-up !

I submitted also some patches for inclusion into the openSUSE Build Service. One of these patches will help us to a address an issue with rpmbuild when doing builds for the ARM architecture.

In progress / todo:

* tools for speed-up

* submission of needed patches to factory

* cross-compiler integration

GSoC – summary of this week’s meeting

May 29th, 2009 by

In the last days I had a closer look at the oauth rails plugin which requires some methods from the restful_authentification module. As the obs frontend doesn’t use this module we need to provide our own implementations of these methods. Fortunately it only uses a handful of methods (like authorized?, login_required, logged_in?, current_user etc.) so it shouldn’t be too hard to get it working without the restful_authentication module.

Another thing on my todo list was to look for possible workarounds for the session fixation attack. According to this thread it’ll be fixed in a new revision of the oauth spec. So after the user grants access to a specific application the oauth provider redirects the user to a callback url (if it’s specified by the consumer). Additionally it adds a parameter to this url (called oauth_verifier) which has an unpredictable value – so an attacker has no chance to “take over the session” (this is just a short summary – for more details have a look at the spec).

Last but not least I finished the test application and played around with it.

TODO:

  • start integrating oauth into the frontend
  • play around with the python library

Btw. my mentor pointed me to an interesting railscast about authlogic – it gives a great overview about this module.

GSoC – summary of this week’s meeting

May 21st, 2009 by

My mentor suggested to do a weekly meeting in order to discuss the current state of the project. I’m going to post a small summary after each meeting.

in progress:

  • build small rails test application in order to simulate a small environment to test the ruby libraries
  • used the “restful_authentication” module because it is required by the rails plugin generator

The test application is more or less working and it’s already possible to get an access token.

TODO:

  • find more information and possible workarounds for the session fixation attack
  • finish the test application
  • find out which method’s from the “restful_authentication” module are required by the oauth rails plugin. The plan is to “fake” this methods so that the rails plugin can be used.

Additionally we talked a bit about authlogic – we decided that we won’t use authlogic for this project but it might be useful for the future.

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
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  :

#!/bin/bash

/usr/bin/osc “$@”

if [ -e .osc/_files ]; then

if [ ! -d .git ] ; then  git init ; echo “.osc” > .gitignore ; echo “.gitignore” >> .gitignore ; fi
mydate=$(date)

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

git commit -a -m”$mydate”

fi

GSoC introduction – openSUSE@ARM

May 4th, 2009 by

Hi openSUSE community!

I’m glad my proposal was accepted and today I want to introduce myself and my GSoC project.

/me , thats Jan-Simon Möller and I’m just finishing my Diploma in electrical engineering at the Leibniz Universität Hannover. I’m coordinator of the openSUSE Weekly Newsletter and contribute also to the hamradio repository, the iFolder project and the openSUSE Build Service. See also my “People of openSUSE” interview.

My Project in short:  openSUSE@ARM
My aim during GSoC 2009 is to port first the base to the ARM platform. Then KIWI needs also some attention when it comes to imaging and after that the tools, Kernel and X11.

I’ll heavily use the capabilities of the openSUSE Build Service, which is now ready for ARM.

During the last few days, I’ve done many little preparations to get it all flying when GSoC coding period starts.

Stay tuned !

Factory USB Images

May 4th, 2009 by

If you’re interested in USB images, I’m publishing factory USB images built in the build service. They are completely fresh and see no testing at all, so if you find a problem, send me a patch 🙂

They are compressed .bz2, so the download is roughly the same as a CD ISO, but they are actually .raw images. So you can deploy them on a USB stick and carry around your personal linux hard drive. But you will need something > 3G. Installing them is pretty easy.

Put your USB stick in your computer, then check /dev/disk/by-id/usb* for the name of your stick. Mine is named /dev/disk/by-id/usb-Kingston_DataTraveler_II+_5B751D8C1994-0:0. You can double check by looking if it points to the same sdX that you see last in dmesg. Like this:

sd 29:0:0:0: [sde] Assuming drive cache: write through
sde: sde2
sd 29:0:0:0: [sde] Attached SCSI removable disk


desdemona:~ # ls -l /dev/disk/by-id/usb-Kingston_DataTraveler_II+_5B751D8C1994-0:0
lrwxrwxrwx 1 root root 9 4. Mai 15:47 /dev/disk/by-id/usb-Kingston_DataTraveler_II+_5B751D8C1994-0:0 -> ../../sde

Bot are sde – fine. What partitions are on it, doesn’t matter – all data will be erased by this.

Now the command (for gnome.x86_64 – there are 3 other choices):

wget -O - http://download.opensuse.org/repositories/openSUSE:/Factory:/Live/images/openSUSE-11.2-usb-gnome.x86_64-2.8.0-Build18.1.raw.bz2 | bzcat | dd of=/dev/disk/by-id/usb-Kingston_DataTraveler_II+_5B751D8C1994-0:0 bs=4M

Depending on the speed of your USB stick, this can take a while, but the good thing is that this command doesn’t require any temporary space. My stick is a very fast one and it takes around 10 minutes to download and “burn”. After that, either reboot or put the stick in the computer you like to boot. On first boot, it will expand to the size of your USB stick, creating another partition.

Note that this images come without live installer, but you can of course zypper in yast2-live-installer and xdg-su -c /sbin/yast2 live-installer.