Project Title : Testing SSSD using the cwrap libraries
|
Contact Information |
|
|
About Myself |
I found it really appealing that Fedora provides a complete desktop operating system, including productivity applications, Internet utilities, and desktop tools. Playing around with user friendly GUI was fun. Recently I have worked on fedora:Unit Test SSSD project for twelve weeks. It was a great learning experience. I found my mentor Jakub Hrozek as well as complete fedora team to be really helpful and approachable. What I really liked was: fedora team is always ready to help you irrespective of your background knowledge, whether you are at zero level or have sound knowledge, they guide you with the same enthusiasm. The internship period helped me get familiar with many ways SSSD project works as well as gave me an opportunity to get in contact with many fedora folks. I found a vibrant working environment in fedora community. I wish to continue the same and contribute more and more to the organization.
Yes, I have contributed to [1] project and some of my work can be found here [2].
I have sound knowledge of C, cmocka unit test framework and basic development skills (how to build a program) which is basic requirement of the project. Project "Testing SSSD using the cwrap libraries" is a fair extension of OPW project I worked for fedora. As I have already worked on many basic modules of SSSD project I have better understanding of it and I am ready to work on more intricate modules with are a part currently proposed project . Thus I believe this makes me a strong candidate for this project.
No.
Yes, I wish to work with Fedora-SSSD team. I like the kind of work they have. It best suits my interest and knowledge. One factor could surely be my previous participation in SSSD project. I was working on Unit testing of SSSD which focused on the core SSSD features that are enabled in most of SSSD deployments. Thus this project will be my second contribution to fedora team and I wish to work for many more as well.
My final year exam will get over near 15th of May 2014. I do not have commitments thereafter. As the internship period starts from June 19th I can devote my complete concentration to the project itself. I assure a commitment of at least 40-45 hours per week to the project. |
|
Experience with any other FOSS projects |
|
I started my contribution with launchpad.net where I learned how to use bazaar, creating ssh key, cloning, pushing, pulling and merging code to mail repository. Next, I worked with Mozilla Firefox organization. Resolving some of the initial bugs made me comfortable using various version control system. The process helped me to excel in various computer languages such as C++, C, Python, HTML, XML, Mallard. I had good experience in interacting with FOSS folks through IRC and mailing list. It was a good exposure for me. It has been really exciting and fun while coding, discussing and getting involved in the open source community. The feeling of being a part of organization has been my ever encouraging source. Link to some of the contributions I made: I am a member of AmFoss club of our college. There we encourage each other to participate in open source. We conduct seminars, lectures, coding events, trips and have our mailing list too. It is a very active and enthusiastic group. |
|
OPW internship: Fedora-Unit Test SSSD |
1 retrieving user information. 2 authenticating users.
Links: |
|
Abstract |
|
The project is about testing SSSD without having either network or root access. Normally SSSD requires both -- you need to be root to run it, several client libraries must be put into well-known system paths and also there needs to be access to a server (such as an OpenLDAP instance) over a network. But unfortunately build systems provide neither network nor root access. This GSoC project to uses the cwrap libraries to resolve the same. The cwrap project aims to help client/server software development teams willing to gain full functional test coverage to complete the task. It makes it possible to run several instances of the full software stack on the same machine and perform locally functional testing of complex network configurations. Daemons often require privilege separation and local user and group accounts, irrespective to the hosting system. We will show how cwrap will help you and developers interested in your project to easily test your software stack. The cwrap project does not require virtualization and can be used to build environments on different operating systems. |
|
Project Details |
|
The project can be explained as following.
|
|
Introduction |
|
Testing network applications correctly is hard. The biggest challenge is often to setup the environment to test a client/server application. One option is to setup several virtual machines or containers and run a full client/server interaction between several machines. But building this environment might not always be possible, as an example build systems typically have no network at all and run as a non privileged user. It is often a hard and time consuming task to setup the development environment. Reading and running the test cases is normally a good entry point to understand a project as you learn how it is set up and how you need to use the API to achieve your goal. For these reasons, it would be preferable if there was a way to run the tests locally using a non-root user, while still being able to run in an environment as close to real world as possible. Not testing code that requires elevated privileges or networking is usually not an option, because many projects have a test driven development model. This means to submit new code or to fix issues a test case is required so regression are avoided in future. |
|
The cwrap project |
|
cwrap is a new project but the ideas and the origin of this new project is the Samba code-base. It presents the internals of one of the most advanced Free and Open Source Software testing systems which has successfully helped Samba developers for many years to test their protocol implementations. The cwrap project aims to help client/server software development teams willing to gain full functional test coverage to complete the task. It makes it possible to run several instances of the full software stack on the same machine and perform locally functional testing of complex network configurations. |
|
Testing client/server issues |
|
If you want to test your server then you can run into some problems. Your server might need to open privileged ports, which requires superuser access. If you have not only one server component but need to run several instances of daemons for different tasks, then the setup becomes more complex. An example would be you want to test a SSH client with Kerberos. So you need a KDC and an SSH server. If you provide login or authentication functionality, user and group accounts on the system are required. This means each machine you run the tests on needs to have the same users. To be able to switch to a user after authentication, you have to be root in the first place. All these things make testing harder and the setup more complex. |
|
socket_wrapper |
|
This library makes it possible to run several instances of the full networking stack on the same machine and perform locally functional testing of complex network configurations. socket_wrapper redirects all network communication to happen over Unix sockets, supporting IPv4 and IPv6 socket and addressing emulation. This allows you to start several daemons of a server component on the same machine without any conflicts. You are able to bind privileged ports below port 1024 without root privileges. |
|
nss_wrapper |
|
There are projects which provide daemons needing to be able to create, modify and delete unix users. Or just switch user IDs to interact with the system on behalf of another user, e.g. a user space file server. To be able to test that, you need the privilege to modify the passwd and groups file. With nss_wrapper it is possible to define your own passwd and groups file which will be used by software to act correctly while under test. If you have a client and server under test they normally use functions to resolve network names to addresses (DNS) or vice versa. The nss_wrappers allow you to create a hosts file to setup name resolution for the addresses you use with socket_wrapper. |
|
uid-wrapper |
|
Some projects like a file server need privilege separation to be able to switch to the user who owns the files and do file operations on his behalf. uid_wrapper convincingly lies to the application letting it believe it is operating as root and even switching betwen uids and gids as needed. You can start any application making it believe it is running as root. |
|
Deriverables |
|
|
Timeline | ||||||||||||
Yes, I have communicated with Jakub Hrozek(Jhrozek at #sssd) and am in touch with him for quite long. |