Archive:GSOC ideas 2012

Jump to: navigation, search
Community> Google Summer of Code
[Guidelines] · [Project Ideas] · Proposal Template · Organization Application


GSOC 2012 Idea list

This is a list of ideas for projects which could be done for openSUSE as part of the Google Summer of Code program. If you have an idea and want to mentor it, please add it it to the list. You might also find inspiration on the GSoC 2011 Ideas page. The openSUSE GSOC 2012 page is here

If you are a student and want to work on an idea, please submit a proposal. You are not limited to the ideas listed here. If you have an own idea or want to approach an idea in a completely different way, feel free to submit this as proposal as well. Sometimes these are the best projects. Creativity and initiative are highly appreciated.

A great source for openSUSE related ideas is openFATE.

There have been a couple of ideas about more openSUSE derivates but it was decided that they are not good GSOC ideas as the coding part is not primal.



General ideas

  • Limited GUI support in text mode for multimedia & browsers.
  • develop a way for GTK apps to use a KDE file dialog in a Plasma Desktop
  • develop a way for KDE apps to use a GTK filedialog in a GTK desktop (GNOME, XFCE, LXDE)
  • Zypper to be able to talk to the 'osc' world so we can do zypper se on osc packages and trivially add repos, and install packages.
  • LTSP-GSOC Ideas
  • GRUB2 yast module
  • Remastersys or mylivecd for openSUSE
  • WebPin
  • owncloud
    • Integration in GNOME Online Acconts with automatic configuration of Evolution and Nautilus to use ownCloud
    • Integration in Dolphin to access sharing and version of files from within the context menu.
    • Integration of ownCloud Gallery with Digikam
    • Integration of ownCloud Apps into GNOME as GNOME Web Apps
  • Integrate Ksplice for reboot less kernel upgrades
  • FATE: Work on the KDE 4 client

FATE is the feature tracking framework of Novell/openSUSE. The user visible part of this is openFATE, the place where different projects of openSUSE track their feature requests. There also exists a KDE3 client, which should get ported to QT4.

Ideas coming from openFATE

Overview: Features on openFATE tagged with 'gsoc_2011'

openSUSE Connect

openSUSE Karma plugin for openSUSE Connect

Implement Karma concept in openSUSE Connect that will collect points from wiki edits, bugzilla entries, planet.opensuse.org posts, distribution changelogs and possibly other sources and store them in the Connect. Also implement some UI to make it possible to send points. Create per group badget that will grow according of the number of skilled members automatically. Karma points should have some categorie - developer karma/marketing karma/... And it it would be also great to make it accessible though connect API (to trustworthy external applications (log transactions so in case of security breach it can be reverted)).

Required knowledge: PHP basics

Skill level: Basic

Mentor: Michal Hrušecký

Student: 2 candidates available

Blog post about karma idea

GSoC blog post about karma idea

Ambassador/Event plugin for openSUSE Connect

openSUSE Connect is the social network of the project. It is based on Elgg, a social networking platform based on php/sql. Elgg has an event calender plugin that is used by various groups to organize meetings. The ambassadors use this too, but for their planing of events they attend they have to use the wiki which is too much for many of them. In this project you either adapt the event plugin of Elgg or create a new one that allows planing of events in connect.


Required knowledge: PHP, HTML, CSS

Skill level: Medium

Mentor: Henne Vogelsang

Student:

Related Features in openFATE

Make openSUSE Connect more engaging

openSUSE Connect is the social network of the project. It is based on Elgg, a social networking platform based on php/sql. There are various features people miss about the network to have it more engaging. In this project you will work on connect to implement these missing features.


Required knowledge: PHP, HTML, CSS

Skill level: Medium

Mentor: Henne Vogelsang

Student:

openSUSE Build Service

Support for Gentoo in OBS

Gentoo is a source based Linux distribution. It uses bash scripts called ebuilds, along with eclasses, to build and install packages. Portage, the Gentoo package manager, is very powerful. The Gentoo Prefix Project allows us to run Portage in other distributions as well. Gentoo support in OBS will make it easy to produce binaries with different USE flag variations, plus it will be perfect for testing/tinderboxing.

Required knowledge:

Skill level: Advanced

Mentor: Theo Chatzimichos

Student: 2 candidates available

Support for Bitbake in OBS

Bitbake is class based build system. It uses .bb recipes and it is able to create rpm, deb and other formats. All from one recipe. openSUSE Build Service supports building packages on variety of distributions. Support for Bitbake would make it easier to package software and hopefully later to make it possible to build it for all distributions from one recipe. Among other tasks student would need to add support for .bb in obs, get list of dependencies from Bitbake to provide it to Build Service and create staging tree using binary packages provided by obs.

Required knowledge:

  • Python (Bitbake is written in it)
  • Shell, Perl (obs use these)
  • Basic packaging knowledge
  • Good orientation in ugly code
  • Ability to create creative hacks

Skill level: Advanced

Mentor: Michal Hrušecký (feel free to replace me)

Student: 2 candidates available

Blog post about this idea

End user oriented obs web interface

The web interface of the Build Service is currently focused on developers. End users could benefit from exposing the work of individuals more. Displaying recent changes, a global history, activity and rating overview. Also a new user home page (similar to what Facebook or GitHub has) are ideas worth thinking about. Currently the ability to visually inspect the work of others is limited (mostly) to user's membership in projects/groups, their recent requests and what info they provide about themselves. The user's home page could be expanded by interests, external URL links (to an ohloh.net profile or blog).

  • Required skills: Ruby and Ruby on Rails, to integrate the new features into the web user interface
  • Student: one candidate available

Capability-based build scheduling

In particular ARM devices often have limited RAM whereas some packages fail to build without adequate memory. So far we have refrained from adding low-end boards to the build farm. It would be nice to add more build nodes to the farm by being able to manage scheduling more fine-grained on criteria such as RAM size, storage size, CPU features, network access, virtualization capabilities. With regards to ARM it might be an option to build certain packages under QEMU system emulation on x86/ppc rather than QEMU linux-user emulation or native. Individual packages would need to be able to specify required build node capabilities, and these would need to be evaluated and matched to available nodes by the build scheduler.

  • Mentor: Adrian Schröter

Appliances/SUSE Studio

SUSE Studio Command Line Client (ssc)

With SUSE Studio users can easily create openSUSE based systems in their web browser. But when running such a system, there is still missing a convenient way how to feed back changes in the system to Studio, so that with the next build on the Studio web site these changes are incorporated.

The idea of this project is to extend the Studio command line client ssc by this functionality. This could be modeled similar to how the openSUSE Build Service command line client osc works, with commands to list packages, and overlay files, to show diffs, and to commit changes back to Studio. Think git for SUSE Studio. You checkout an appliance, make some changes for it (locally) and once you are happy with the appliance you commit the changes to SUSE Studio.

Example use case 

$ ssc appliance create web_server --source-id=SOURCE_APPLIANCE_ID --username=USERNAME --password=PASSWORD
$ cd web_server
$ ssc package list
$ ssc package add apache
$ ssc file add /etc/apache2/apache2.conf
$ ssc commit


Goal: get some workflow going, which can be used to track changes within an appliance and selectively apply them back to Studio.

Essential: Community involvement, introduce yourself on the opensuse-project mailing list. (this probably applies to all other projects as well)

Find more details on the SUSE Studio command line client page.

Required knowledge: Ruby

Skill level: intermediate

Mentor: Cristian Mircea Messel

Student: STUDENT NEEDED.

SUSE Studio Java Client SDK

SUSE Studio Java Client is a Java based library to interact with the SUSE Studio image store and appliances toolkit. The library is supposed to enable developers to easily implement SUSE Studio client applications in Java, even for mobile platforms like Android. The implementation however is at the moment still a work in progress and only very basic parts of the REST API are currently covered.

The project goal is therefore to bring on the development of this library as much as possible, while ideally the whole API functionality should be covered by the implementation. The interface should be designed in a way so that developers will be able to write beautiful code using this library. Further it would be nice to have a suite of unit tests, so we can automatically ensure the overall functionality of the code and data model at any time using continuous integration tools like Jenkins.

It would be a big plus for your application, if you propose to implement new software based on this SDK instead of just working on the library itself. This might be a mobile app for Android, a new web application or anything else, as far as it makes sense. Feel free to come up with your own ideas!

Please find the existing code and documentation here and the SUSE Studio API documentation here.

Required knowledge: Java, HTTP and REST, unit testing and continuous integration

Skill level: beginner - intermediate

Mentor: Johannes Renner

Student: STUDENT NEEDED.

SUSE Studio Amazon EC2 scripts

SUSE Studio allows you to easily build customized Amazon EC2 AMIs (Amazon Machine Images). While you can directly push and launch them from Studio to Amazon EC2, it is sometimes preferred to download the raw images and do this yourself. For example, you can automate a deployment workflow with Studio's WebHook API to download a new AMI when it is available, and then automatically push it to all EC2 regions, launch, test and swap them out for production use.

The project at https://github.com/susestudio/susestudio-ec2 allows one to easily upload and create these AMIs from the downloaded Studio images. This project is to extend the existing code.

Required knowledge: Bash/Shell scripting, Amazon EC2 knowledge preferred.

Skill level: beginner - intermediate

Mentor: James Tan

Student: STUDENT NEEDED.

SUSE StudioCheck

[| See entry in section QA]

Cross-distribution topics

The openSUSE project is proudly pushing cross-distribution collaboration.

AppStream: Reviews in software center

AppStream aims to solve the topic of how to deal with installing applications in a cross-distribution way.

A core part of the Software Center story we want to build in AppStream is the social features: ratings, comments, etc. Ubuntu is using the https://reviews.ubuntu.com/reviews/ server (investigation needed: is the code for this free? If yes, this project is already fixed). We need a similar server that each distribution can install and, if possible, that could talk to other instances to use the data from other distributions.

Required knowledge: web services, python

Skill level: intermediate

Mentor: Vincent Untz

Student: STUDENT NEEDED.

Upstream/downstream tracker

Many distributions have some custom tools to track upstream, and to help determine, for example, what is the latest version of an application. However, all those tools have some limitations and none is available as a service that everybody could use.

The goal of this project is to bootstrap a common tracker that could be then used to know the status of a module upstream, but also in various distributions. Information about the versions, but also what patches distro use and opened bugs are the first metadata we'd want to cover.

Examples:

Required knowledge: preferably python

Skill level: advanced

Mentor: Vincent Untz

Student: STUDENT NEEDED.

Popularity contest for RPM (popcorn)

OBS has a lot of repositories and a lot of packages. People continually contribute new packages and maintain them for the greater good. But who uses these packages?

It would be great to have a way for people to tell us (voluntarily) what packages/repos they use. This way we could have a way of knowing what to concentrate on and what's not needed.

Popcorn aims to track the collection of packages and repositories that users have installed on their systems in a central place. The aim of the project is to be distribution neutral, but we will start with RPM (and openSUSE) first.

You can learn: python, Flask, SQLAlchemy, PostgreSQL, rpm, YaST (YCP) and others.

You can see the WIP popcorn sources at github. Check out the TODO and don't hesitate to come up with your own ideas!

Required knowledge: python, beautiful code

Skill level: intermediate

Mentor: Ionuț Arțăriși

Potential students: Akshit Khurana, Gaurav Sood.

Compositor Colour Management

Colour Management has to be easy for casual developers and automatic for users. To get there it is an good idea to have all applications colour corrected inside the window manager. On the other side graphics applications, want to do own colour management and should be able to say a window shall not be colour managed. To do so easily exists the X Color Management spec and the implementation of this protocol in libXcm.

The ICC based colour correction is easy for compositing window managers, as they support mostly shaders. Shaders run on the GPU and allow for a very fast and efficient colour correction.

The project targets at providing colour management inside a compositing window manager of your choice. The protocol part to be implemented is the Baseline spec with _ICC_COLOR_OUTPUTS and additional the _ICC_COLOR_PROFILES atom.

This implementation prepared a easy transition into Wayland compositor colour management, which will as well be window based.

A good and very fast start is the update the CompICC plug for Compiz-0.8, to use the _ICC_COLOR_OUTPUTS atom.

Required knowledge: OpenGL, GPU shaders, Oyranos, C

Skill level: intermediate

Mentor: Kai-Uwe Behrmann

Student: STUDENT NEEDED.

Gtk Front End to Oyranos

The Oyranos project is a cross desktop and cross OS colour management system (CMS) to provide easy to use and while robust colour management services to applications. The main goal of Oyranos is to provide colour management without user interaction. But in some situations and especially experts might want to configure and tweak the various settings manually.

Front ends exist in Qt and for KDE. For Gtk based Desktop Environments it is currently only possible to use the Qt front end. For a better appearance and integration it makes sense to provide a native Gtk GUI for settings and configuration.

Required knowledge: Gtk, Oyranos, C, good communication

Skill level: intermediate

Mentor: Kai-Uwe Behrmann

Student: STUDENT NEEDED.

OpenICC Colour Configuration Data Base

Users, who configure their colour management system (CMS) behaviour and devices, want to share these settings on one host without any intervention among installed CMSes. The project will introduce the OpenICC data base into CMSes like ArgyllCMS, Oyranos and colord and replaces existing own DB access code.

device DB example: http://www.freedesktop.org/wiki/Specifications/icc_meta_tag_for_monitor_profiles

existing code: http://openicc.git.sourceforge.net/git/gitweb.cgi?p=openicc/openicc;a=tree

Required knowledge: C, good communication

Skill level: intermediate

Mentor: Kai-Uwe Behrmann

Student: STUDENT NEEDED.

Links:

Redesign fdisk to be more extensible and implement GPT support

The fdisk (and family) partitioning utility is a popular and widely used tool in Linux, among other operating systems. The current code, dating from 20 years ago - since 1992, is messy, without standards, and a result of years of hacky patching. The util-linux project has been developing traditional Linux tools and updating them for the 21st century, in an organized and unified way.

Cleaning up the fdisk-family tools will allow refactoring, unification, clarity and abstraction across all fdisk-like programs (fdisk, sfdisk and cfdisk). This makes bug fixing and future contributions easier, with clearer, better organized code. A longer time goal, which comes naturally afterwards is to implement a libfdisk library - something like what libmount is to mount/umount.

This work should include, at least:

  • move all label-specific code to separate files
  • add GPT (GUID Partition Table) support
  • remove obsolete code - for example, around CHS addressing
  • use libblkid for partition tables parsing
  • create any interface for dialogs (fdisk is about dialogs)
  • write regression tests
  • data type standardization (ie: off_t instead of long long)
  • documentation


Required knowledge: C, partitioning, writing clean code, autotools, git

Skill level: intermediate

Mentor: Petr Uzel

Student: Davidlohr Bueso

On-demand Symbolic Memory

There are free symbolic execution tools like klee which perform symbolic execution on a code to find bugs. The problem is that often the input to a program (or its part) is unknown in advance. So checkers use a hack that they pass large symbolic buffer as input and hope that it is large enough.

This is slow, inconvenient and does not help in cases where the buffer is a structure or an array of them. The members of the structure, especially pointers, are uninitialized and point to NULL.

Instead, an on-demand symbolic buffer should be created. That ensures that NULL members are allocated on-the-fly and input arrays extended as needed. This was described in a paper called "Practical, low-effort equivalence verification of real code". Unfortunately the source code is not available. So the task of the student here is to implement this to klee, present that it works on examples provided by the mentor (parts of the Linux kernel code) and make the tool available to wide public.

Required knowledge: C, static analysis (symbolic execution), writing clean code

Skill level: advanced

Mentor: Jiri Slaby

Student: STUDENT NEEDED.

Concolic Symbolic Execution

There are free symbolic execution tools like klee which perform symbolic execution on a code to find bugs. The problem with symbolic execution is that it gets lost very early if the code uses non-linear computations like comparing integers to hashes of other inputs or finding a number 'x' where x^3 == ~0.

The cure for this is a parallel symbolic and concrete execution. If the symbolic execution cannot reason about some input, it asks the concrete one and vice versa. It is well-described in some papers.

The student should implement this technique to klee and demonstrate how it improves performance of the symbolic execution.

Required knowledge: C, static analysis (symbolic execution), writing clean code

Skill level: advanced

Mentor: Jiri Slaby

Student: STUDENT NEEDED.

Scanny — Ruby on Rails Security Scanner

Web developers working with Ruby on Rails framework often write insecure code — either by mistake or because thay don't know better. However many of the insecure code patterns can be detected statically and could be easily avoided. Scanny is a tool in early stage of development that parses Ruby files and aims to report such insecure patterns.

The goal of this project is to develop Scanny further so it would become a usesful tool for all Ruby on Rails developers. This consists of:

  • Porting all useful checks from an older Perl-based tool with a similar purpose.
  • Researching what other checks would be useful (based on common Ruby on Rails security problems) and adding them to the tool.
  • Ensuring that Scanny is usable with production-level Rails applications. This mainly means testing on real-world code and improving usability and performance of the tool as necessary.

Note that Scanny is based on a code pattern-matching library Machete. Work on Scanny will probably also involve improving it.

Required knowledge: Ruby, Ruby on Rails, web security basics, idea how parsing works

Skill level: intermediate

Mentor: David Majda

Student: STUDENT NEEDED.

MirrorBrain: buffer-cache-friendly mirror selection

MirrorBrain is the framework that openSUSE uses to redirect downloads to mirror servers.

It would be possible to select mirrors intelligently with the purpose of optimizing the usage of the buffer caches of the mirrors. Right now, if openSUSE is released, all CD/DVD images are downloaded from all mirror servers. It would need many GB of buffer cache on the mirrors to keep the images in memory, usually more than physically available. Now, it would be very clever if the redirector could send redirects for DVD 1 to a certain mirror (group of mirrors), and send requests to DVD 2 to another mirror (group of mirrors). The question is how to recognize situations where this is possible, and how make this happen without administrative effort. A solution has been proposed (http://postr.poeml.de/a-buffer-cache-friendly-mirror-selection-algo) and it seems to work by proof-of-concept testing.

To implement this, some hacking on mod_mirrorbrain.c is needed. A prerequisite is to understand how the current mirror selection works and how to add the further algorithm to it.

Mirrors (and thereby, indirectly, its users, i.e. all of us) should benefit from this selection algorithm, because they would need to read less data from their disks.

Required knowledge: C programming, HTTP and networking

Skill level: intermediate (high?)

Mentor: Peter Poeml

Student: STUDENT NEEDED.


QA

SUSE Studio: StudioCheck automated test framework

This project is a abstraction of the Studio API to have the ability of creating test cases using a gherkin syntax. A prototype of the core system was created and is working, now the remaining items are the creation of abstraction steps and some reporting interface to get more than just a list of results for easier consumption.

Required knowledge: Ruby, Rails, gherkin/BDL based tests

Skill level: Depending on task Easy to Intermediate

Mentor: Balazs Kutil / Christian Hueller

Student: Shyukri Shyukriev

LTP:Fix/Implement automated kernel/glibc tests

The Linux Test Project is huge collection of testcases aiming to test stability and correctness of kernel/glibc implementation and as the time goes by, some of the testcases needs polishing and testcases for newly introduced features should be written.

Required knowledge: C, low level Linux/POSIX interface

Skill level: Intermediate

Mentor: Cyril Hrubis

Student: STUDENT NEEDED.

openQA:Implement alternative backends

The openQA/OS-autoinst testing framework provides reliable continuous quality feedback about current openSUSE-Factory, Debian (and potentially other distributions). Currently the service relies on kvm for the testing (an alternative VirtualBox backend exists), but to test things, that need real hardware such as NVidia/ATI drivers, it needs a different backend. One idea is to use Net::VNC to interact with the machine-under-test and another is to use HDMI-capturing hardware (e.g. from Blackmagic for 200€) and hardware that can generate keystrokes to emulate user-input.

Required knowledge: perl

Skill level: Intermediate

Mentor: Bernhard M. Wiedemann / Dominik Heidler

Student: STUDENT NEEDED.

openQA:Implement web-based test creator

(for description of openQA see above) Creating/modifying test modules currently requires people to use a text-editor to create/change perl module files. Having an interactive web-based test-module editor/creator (could be similar to a user-input recorder) would allow easier creation of test-modules.

Required knowledge: perl, AJAX

Skill level: Advanced

Mentor: Bernhard M. Wiedemann / Dominik Heidler

Student: STUDENT NEEDED.

openSUSE System Management

Automatic resizing of LVM volumes and filesystems

openSUSE currently provides good support for creating LVM volumes and installing the OS on these volumes. However, if the filesystem becomes full, the user/administrator has to increase the volume size and contained filesystem capacity manually.

The goal of this project would be to implement automatic resizing of LVM volumes and contained filesystems. This resizing would be triggered e.g. by the package manager before installing the packages, if the free space drops before certain threshold etc. The installer should be modified to compute the necessary space needed for installing the selected set of packages and allocate the LVM volumes 'just big enough' for the installation. With future automatic resizing of the LVM/FS, this would save storage capacity in the volume group which would otherwise be unnecessarily allocated for /, /usr etc.

Required knowledge: At least basic experience with C/C++, RPM, scripting (Python, bash). Understanding of LVM is a plus, but not necessary. Willingness to learn and investigate is a must.

Skill level: Intermediate

Mentor: Petr Uzel

Student: Praful Johari

ownCloud Related Ideas

  • ownCloud Apps as GNOME Web Apps
  • Background: ownCloud can show Apps as standalone Web Apps. They should automatically appear in GNOME when you connect ownCloud with GNOME via the Online Accounts Panel.'
  • Mentor: Frank Karlitschek
  • Skill Level: Medium
  • Student:


  • Project Title: ownCloud Dolphin integration
  • Background: Integration in Dolphin to access sharing and version of files from within the context menu.

The idea is that users can click on a folder with right mouse button and get a possibility to add that directory as syncing directory to ownCloud or "desync" it. Another idea is to display a special icon in dolphin if a folder is a synced folder.

Together with ownClouds versioning feature, it moreover would be great if the user could have access to previous versions of the file.

  • Mentor: Frank Karlitschek
  • Skill Level:
  • Student:

Beautiful one-click-install

  • Project Title: Beautiful one-click-install
  • Background: Garrett made a great mockup for a much more beautiful one click installer some time ago. It would be great to get this implemented. I think it could be done with a small Qt application which uses libzypp or PackageKit or something like that as the backend to do the actual installation. Some more information in FATE #309503.

Implementing Accurate XML Code Formatting

  • Create Readable Source Code Formatting for XML
  • Background:

There are some tools which can format XML/HTML sourcecode (tidy, xmlformat, ...). For example, xmlformat splits elements in an inline, block, and verbatim (=code) category. In most cases this works fine, but sometimes it fails.

This tool could be improved by, for example using XPath expressions or by reading schemas (DTD, RNG, ...) to know more about the structure and how to format it. This would (hopefully) lead to a more exact formatting (think of mixed contents)


  • Skill Level: Intermediate

Perl or C experience. Knowledge of XML and/or XPath is desirable. Depending on the project plan, DTD would also be useful.

  • Student: STUDENT NEEDED

Virtualization

Upstream Xen Support for Libvirt

The libvirt project provide a common and stable layer for different virtualization technology, including Xen, KVM, qemu and other hypervisors. Xen is one of the most important virtualization technology supported by openSUSE. But there are lots of changes from Xen-unstable, which lead to libvirt unused in lots of occasion.

The gual of this project is to update libvirt for the xen-unstable. Most of the work may be update for the latest xenlight driver in libvirt.

Mentor: Bamvor Jian Zhang

Required knowledge: C

Skill Level: Intermediate

Student: STUDENT NEEDED


Code review for projects on GitHub

The goal of this project is to extend git-review to make code review from the command line interface even simpler.

A lot of our projects have moved their code to GitHub. Using pull requests is a comfortable way to collaborate on projects hosted there and if done in a browser there is also a nice UI for it. However, since most developers use the command line for all of their git operations anyways, git-review was created to add some commands to git and thus enable developers to handle code review from the command line, too.

For productive use git-review needs code coverage and added functionality that allows developers to work on different forks of a project. For further information please take a look at the project's list of open issues.

Mentor: Dominik Bamberger

Required knowledge: Ruby, Git, RSpec

Skill Level: Medium

Student: STUDENT NEEDED

syslog-ng

Improve the MongoDB destination of syslog-ng

syslog-ng, the leading logging platform has had support for storing messages in MongoDB for a good while now, but the technical details of how this is accomplished are a bit arcane, and the functionality and speed suffers because of this.

The idea behind this project is to enhance the driver, to make it more robust, scalable and performant.

There are already plans on how this can be accomplished, touching multiple parts of syslog-ng, deep in its core. These plans need to be explored further, and a suitable implementation needs to be developed.

Basically - for those who are a bit familiar with mongodb - we want to go from using dot-notation and upserts to building structured BSON objects and using (bulk) inserts instead.

Mentor

  • Confirmed Mentor: Gergely Nagy, who is available at algernon@balabit.hu, or algernon on IRC (irc.oftc.net or irc.freenode.org)
  • Co-mentor: Viktor Juhasz, who is available at jviktor@balabit.hu

Deliverables of the project

  • Modify syslog-ng's internal value pairs subsystem to be able to emit a tree of values, not just a flat name=value list.
  • Teach the mongodb driver to walk the tree, and construct BSON objects out of it, and use insert instead of upsert.
  • Add support for inserting messages into a MongoDB database in batches, instead of inserting one by one.

Desirable skills

  • A reasonable knowledge of the C programming language. glib experience is a great help, but not strictly neccessary.
  • Interest in working with a modern non-relational database, and hacking on a mature code-base.
  • Interested students who wish to apply should attach a log of a successful syslog-ng 3.3 compilation from source.

What the student will learn

  • The student will learn about the MongoDB wire protocol, and the BSON serialization format.
  • The student will be able to learn how to refactor code, and make it much more efficient.
  • The student can learn about lex and yacc, and see and modify a complex parser built using these.

Student: Eun Kyung

libdbi-less SQL destination for syslog-ng

syslog-ng has long supported storing log messages in various SQL databases, through the libdbi library. However, development of that library has stalled, and the code is old, inefficient and generally not suitable for high performance situations.

For this reason, the goal of this project would be to develop a destination driver for syslog-ng that is able to store logs in selected SQL databases (mysql or postgres at first, with the promise that it'll be reasonably easy to add support for others) without using libdbi, and directly using the libraries or protocols provided by the databases.

With this, not only would the performance of storing logs in SQL increase, but we'd be able to add features that are not possible with libdbi.

Mentor

  • Confirmed Mentor: Viktor Juhasz, who is available at jviktor@balabit.hu
  • Co-mentor: Gergely Nagy, who is available at: algernon@balabit.hu, or algernon on IRC (irc.oftc.net or irc.freenode.org)

Deliverables of the project

  • A working destination driver, able to store messages in an SQL database of the student's choice, without the use of libdbi.
  • The driver should support using prepared statements
  • The driver should be mostly backwards compatible with the existing SQL driver, if possible.
  • The result should be faster than the existing solution.

Desirable skills

  • A reasonable knowledge of the C programming language
  • Basic SQL knowledge (INSERT, transactions, prepared statements, etc..)
  • Experience with, or willingness to learn to use the native libraries provided by the database.
  • Interested students who wish to apply should attach a log of a successful syslog-ng 3.3 compilation from source.

What the student will learn

  • The student will be able to learn communicating with an SQL database from C.
  • The student will be able to learn how to make database access fast, and still robust.
  • The student will be able to learn from past mistakes of other developers, and improve upon their design.

Student: Azri Bin Mohamed Yasin

Asynchronous communication support for libmongo-client

In order to talk to the MongoDB server, syslog-ng uses the libmongo-client library developed at BalaBit. This library uses synchronous communication with the server, meaning that it will block until an operation is in progress.

We would like to change that, and for performance and other reasons, make it asynchronous. This demands a lot of internal changes within the library, that have been started, but isn't complete yet.

The goal of this project is to finish the low-level transition that have been started, then design and implement asynchronous, non-blocking communication with the MongoDB server.

Mentor

  • Confirmed Mentor: Gergely Nagy, who is available at algernon@balabit.hu, or algernon on IRC (irc.oftc.net or irc.freenode.org)
  • Co-mentor: Viktor Tusa, who is available at tusa@balabit.hu

Deliverables of the project:

  • The libmongo-client library split into two: a small one to work with BSON, and another to work with MongoDB.
  • A workable design of how to communicate with MongoDB in a non-blocking way, while still preserving most - if not all - of the convenience features the library now provides (such as safe-mode, automatic failover and replica-set support).
  • An implementation of said design, with test coverage.

Desired skills:

  • A good knowledge of the C programming language
  • A reasonable amount of experience and knowledge about writing network programs or libraries.
  • Familiarity with the BSON format, and the MongoDB wire protocol (both of which can be picked up in a single afternoon).
  • The applicant is expected to show his knowledge of either the BSON format, or the MongoDB wire protocol in his application, or shortly after (the exact method of that is left up to the student).

What the student will learn:

  • Best practices while developing a library
  • Test-driver development, with periodic reviews
  • Unit testing a network library written in C
  • How to write portable, efficient C code

Student: STUDENT NEEDED

Zorp

MongoDB proxy for the Zorp application level firewall

Zorp is an application level firewall: something that sees inside protocols, can understand and modify them.

The goal of this project is to write a completely new proxy module for it, that is able to parse and reassemble the MongoDB wire protocol, and provide hooks for the firewall user to influence the traffic (by, for example, restricting access to read-only operations).

Mentor

  • Confirmed Mentor: Szilard Pfeiffer, who is available at coroner@balabit.hu
  • Co-mentor: Gergely Nagy, who is available at: algernon@balabit.hu, or algernon on IRC (irc.oftc.net or irc.freenode.org)

Deliverables of the project

  • A functional proxy, that is able to parse and reassemble the MongoDB wire protocol.
  • Ability to hook into the protocol, and influence it, by restricting the usable set of commands to read-only operation only (or to a selected list of commands).

Desirable skills

  • A reasonable knowledge of the C and Python programming languages
  • Basic knowledge of network protocols
  • Interested students who wish to apply should attach a log of a successful Zorp 3.9.5 compilation from source. An even more interesting thing would be if applicants already tried the Zorp virtual machines in advance, to get familiar with the software.

What the student will learn

  • The student will learn about the MongoDB wire protocol, and the BSON serialization format.
  • The student will be able to learn how to call Python from C, and vice versa.
  • The student will learn how to influence network traffic using an application level firewall

Student: STUDENT NEEDED

XMPP proxy for the Zorp application level firewall

Zorp, being an application level firewall, that sees inside protocols, and can even modify the traffic between peers is the perfect place to audit or filter instant-messaging protocols, such as XMPP (used by, among other things, Jabber and Google Talk).

The goal of this project would be to implement an XMPP proxy, that is not only able to parse and reassemble the protocol, but also suitable to disable parts of it, such as file transfer or video chat, or restrict the traffic in any other way the student finds interesting or useful.

Mentor

  • Confirmed Mentor: Szilard Pfeiffer, who is available at coroner@balabit.hu
  • Co-mentor: Attila Szalay, who is available at: sasa@balabit.hu

Deliverables of the project:

  • A functional proxy, that can parse and reassemble XMPP traffic
  • Ability to hook into the protocol, and disable parts of it (such as file transfer or video chat)
  • Ability to restrict XMPP to certain users, or to user-specifiable time-frames (thus making it possible to disable XMPP during the day, but enable it outside of working hours).

Desirable skills:

  • A reasonable knowledge of the C and Python programming languages
  • A solid knowledge of instant messaging protocols, XMPP in particular.
  • Interested students who wish to apply should attach a log of a successful Zorp 3.9.5 compilation from source. An even more interesting thing would be if applicants already tried the Zorp virtual machines in advance, to get familiar with the software.

What the student will learn:

  • The student will be able to learn a lot about application level firewalls.
  • The student will be able to learn how to call Python from C, and vice versa.

Student: STUDENT NEEDED

Facebook chat restrictions with Zorp

The goal of the project would be to figure out a way to either enhance the existing HTTP proxy, or write a new one, that can be stacked inside it, to be able to restrict Facebook chat.

This involves a reasonable amount of research along with the coding. The expected outcome is a way to enable users to use facebook, but forbid chatting during work hours (where work hours are, of course, configurable).

Mentor

  • Confirmed Mentor: Attila Szalay, who is available at sasa@balabit.hu
  • Co-mentor: Szilard Pfeiffer, who is available at coroner@balabit.hu

Deliverables of the project:

  • An analysis of how one could restrict facebook chat.
  • Either an enhancement of the existing HTTP proxy, or a new one, that can be stacked inside it that makes the restriction possible.

Desirable skills

  • A reasonable knowledge of the C and Python programming languages
  • A solid knowledge of the HTTP protocol and HTML.
  • A reasonable knowledge of JavaScript, and debugging tools.
  • Interested students who wish to apply should attach a log of a successful Zorp 3.9.5 compilation from source. An even more interesting thing would be if applicants already tried the Zorp virtual machines in advance, to get familiar with the software.

What the student will learn:

  • The student will be able to learn a lot about application level firewalls.
  • The student will be able to learn how to call Python from C, and vice versa.


Student: STUDENT NEEDED

Retrieved from "https://en.opensuse.org/index.php?title=Archive:GSOC_ideas_2012&oldid=66374"