User:Rabisg/GSOC 2014 Proposal

=netifrc on Systemd=

Abstract
The goal of this project is to abstract away the tight dependence of netifrc on OpenRC and write a compatibility layer for netifrc to work with other init systems like Systemd

Background
netifrc is a system of modules which provides an way to configure the network via interface specific init scripts. However its tight interdependence on OpenRC limits its usage to systems booting with OpenRC only. This project aims at writing an compatibility layer for netifrc thus making it a general purpose network configuration manager which can be used with other init systems as well.

Objective
The objective of the project is divided into two parts:

Compatibility layer for OpenRC
Currently most of the netifrc modules use commands provided by the openrc package (more specifically the commands provided by runscript) for purposes like setting and getting service specific values (service_set_value / service_get_value), marking service status (mark_service_{active,inactive,stopped,..}), etc. (The list of functions are provided at man 8 runscript)

The first part of the project would be to identify and abstract away the functionality provided by OpenRC (runscript) into a standalone interface so that the actual backend (init system) can be configured at compile-time which would enable netifrc to work with multiple backends

Recently, a new package sys-apps/gentoo-functions has been added to portage, with the aim of removing OpenRC dependency from projects which need to use /etc/init.d/functions.sh. A new script /lib/gentoo/functions.sh has been added in its place and scripts are expected to try to source this file before /etc/init.d/functions.sh. This would handle all the functions earlier provided in /etc/init.d/functions.sh which was supplied by OpenRC. However, since one of the goals of this project is also to be able to run netifrc on non-Gentoo systems, a backup will also be provided in case RC_GOT_FUNCTIONS is not set.

The other part of this layer which involves functions like service_{set,get}_value and mark_service_{,in}active. The former would be easier to handle since it only requires remembering and fetching some stateful variables which can be done by storing it in a file and reading from it (which afaik is the way OpenRC does it too [openrc : src/librc/librc.c Line 806 and 821]). The later would not be as straightforward as it would require understanding the semantics of systemd in greater depth before adding functions to mark services and checking service state. By the end of the Community-Bonding period I plan to finalize this design.

Porting netifrc to Systemd
After the first part, the next objective would be to write a Systemd backend for the compatibility layer. For this I would first look in depth into systemd and its service management. This would indeed be the greater part of the project as some functions like service_{set,get}_value have no direct alternatives in systemd world and other functions like service_mark_{active,inactive,stopped} would require a thorough understanding of systemd service management.

Following this would be an extensive testing period where I would first test netifrc+systemd system on a Systemd setup. First on Gentoo with Systemd and then on a distribution which ships with systemd by default (Archlinux most probably). This phase would include rigorous testing and multiple re-iterations depending on my mentor as well as community feedback.

Timeline
21st April - 19th May : Community Bonding Period
 * Brush up Bash
 * Take a deeper dive into OpenRC and netifrc
 * Read more about the various modules supported by netifrc and their functionality
 * Learn about systemd - service management, dependency management, service script etc.
 * Discuss the initial plan with mentor, going through the design decisions for the compatibility layer's interface.

19th May - 10th June: Refactor the functions used by netifrc modules into a single source for OpenRC

11th June - 20th June: Test various aspects of the new refactor. Possibly by writing a battery of tests to match of the output of the native code block and the newly defined functions and running it on multiple platforms.

21st June - 5th July: Start porting the functions (written in the first part) in systemd world

27th June : Mid Term Evaluations

6th July - 25th July: Port the runscript into systemd startup script. As the current implementation is only intended for OpenRC systems, the runscript makes certain assumptions that may not hold in the systemd world. Therefore the environment would have to be setup accordingly.

25th July - 5th August: Adapt the build system to the new changes and test the build process on a couple of architectures and multiple platforms.

5th August - 22nd August: Rigorous testing of the systemd port. This part would involve testing not only on Gentoo+Systemd but also on other distros like Archlinux and Fedora.

22nd August : Final Evaluation

Biography
I am a senior student in the Department of Computer Science and Engineering, IIT Kanpur. I have recently moved to Gentoo as my primary OS but have been a Linux user for quite a few years now. Since then I have been closely following the Gentoo project, contributing ebuild and reporting bugs when I find them. Also I have been helping to maintain the Gentoo Mirror hosted by IIT Kanpur.

I am interested in the field of Programming Languages and Systems Software and like to experiment with various languages. Most of my work previously has been in the field of Web Development where I have tried quite a few languages and frameworks ranging from Drupal to Play(Scala) and a wide variety of JS Frameworks. But more recently I have been more interested in systems and thus wish that I would get a chance to learn and simultaneously contribute to the community (and hopefully become a Gentoo developer in the future)

I have also previously participated and successfully completed GSoC [2012]. In the past I have been the co-ordinator of my college Programming Club where I guided my fellow juniors and tried to promote OSS among other things. Simultaneously I have been an active member of Navya (local FOSS hobby group) which aims at increasing FOSS awareness among the students and provides quite a few hosted services for the community.

Contact info

 * Email : guha.rabishankar@gmail.com
 * IRC : rabisg
 * Github : github.com/rabisg
 * twitter : twitter.com/rabisg
 * Facebook : facebook.com/guha.rabishankar